JP5111482B2 - 内燃エンジンのための障害認識のシステムおよび方法 - Google Patents

Description

本発明は、内燃エンジンの動作における障害状態の認識のためのシステムおよび方法に関する。詳細には、本発明は、ある特定の障害を、他の障害が存在しているときに認識するためのそのようなシステムおよび方法に関するものである。

最新の内燃エンジン、特に車両に対するものでは、電子制御およびモニタが行われている。代表的なエンジン制御モジュール（ＥＣＭ）は、マイクロプロセッサを備え、これは、エンジンの種々の機能を制御するよう動作可能な１組のソフトウェア命令を実装している。例えば、ＥＣＭは、燃料供給アルゴリズム（これは、エンジン・シリンダへ供給する空気および液体燃料の量を制御する）、点火時間アルゴリズム等を実施する。加えて、代表的なＥＣＭは、エンジン中の種々の場所に配置した複数のセンサから信号を受ける。これらセンサは、エンジンの動作状態に関する瞬時的な情報を提供する。ＥＣＭは、これら信号をモニタし評価して、エンジン故障が発生したかどうかあるいは発生途中であるかについて判定を行うソフトウェアを含んでいる。

図１には、代表的な内燃エンジン制御システム１０を示している。このシステムは、エンジン１１を備え、これは、エンジン・クランクシャフト１３に接続された複数のピストン１２から構成されている。このエンジンは、インテーク・マニホルド１５を備え、これを通して周囲の空気を受け、そしてまた、エキゾースト・マニホルド１６を備え、そしてこれを通して燃焼の生成物を各シリンダから各燃焼サイクルの間に排出する。燃料システム１７は、それらシリンダへ供給する液体燃料の量を制御する。冷却システム１８と潤滑システム１９は、エンジンの動作温度をそのエンジン速度範囲に渡って維持する。これらコンポーネントは全て、データリンクを介して通信する１以上の制御モジュールによって制御する。図示した実施形態においては、１つのそのような制御モジュール、すなわちＥＣＭ２０を示している。

また、エンジン作動システム１０は、センサ・データバス２２を備え、これは、ＥＣＭ２０への入力と複数の状態センサ２３ａ−２３ｒとの間に接続したケーブルまたはワイヤの束を備えている。例えば、状態センサ２３ａは、周囲温度センサであり、そして２３ｂはオイル・レベル・センサ、２３ｃはオイル温度センサ、２３ｄと２３ｅとはオイル圧力センサ等である。これらセンサ２３ａ−２３ｒの各々は、車両エンジン・システム１０の本質的にすべての重要な動作ポイントにおけるデータを提供する。このデータは、このシステムの流体またはガス要素全ての温度値および圧力値、並びに、速度センサ２３ｐが提供するエンジン速度を含んでいる。

また、ＥＣＭ２０は、多数の出力ポート２４を備え、これらは、ＥＣＭが収集したデータを外部から読み取ることができるようにする。これら出力ポートは、例えばRS232，J1587またはJ1939の通信リンクを備えることができる。ＥＣＭ２０内に格納されたデータは、ダウンロードしてそしてより複雑な診断ソフトウェア・ルーチンを使用することにより評価することができる。

加えて、ＥＣＭ２０は、信号を、障害インジケータ・ディスプレイ・システム２５に提供する。このディスプレイ・システムは、指示すべき障害の性質に依存して、種々の形態をとることができる。例えば、ほとんどの車両は、低オイル圧力および高エンジン温度に対し個々のアナンシエータを備えている。他のアナンシエータは、オイルおよび冷却剤の流体レベルを示すアナログまたはデジタルのゲージを含むことができる。内燃エンジンの代表的な産業用途または輸送用途においては、一連のアナンシエータ・ライトを使用することにより、エンジンを最初に始動したとき、あるいはエンジンの動作中のユーザが選択した時点において、種々のタイプの障害を示す。１つのタイプの設置例においては、４つのアナンシエータ・ライトから成るアレイを、互いに異なった障害状態に対応するある特定のシーケンスで点灯させる。１つの用途においては、これら障害状態は、“フラッシュアウト（flash out）”する、すなわち、特定のパターンで順次点灯させることにより、ＥＣＭ２０が認識した活性の障害全てを示す。他のディスプレイは、英数字ディスプレイまたはコンピュータ・ベースのモニタを含むことができる。

現行のエンジン／車両制御システムにおいては多くの障害診断あるいは障害認識のアルゴリズムがあるが、そのほとんどは、ある特定のプロトコルに従うものである。１つのそのような障害認識システムは、図２に図式で示しており、これは、ある検知したパラメータの値対時間を示している。この特定の用途においては、その検知した値に対する特定の大きさの不活性化リミットと活性化リミットとを規定する。検知した値が不活性化リミットより下になった場合、障害状態は発生していない。しかし、この検知値が、時間Ｔ１のようなある特定の時間の間、活性化リミットを超えた場合、その障害状態を活性に移す。この検知値が活性化リミットより上に留まる限り、その特定の障害が活性のままである。他方、その検知値が、時間Ｔ２のようなある特定の時間の間、不活性化リミットより下になった場合、その障害状態は、不活性に変化させる。代表的な障害認識システムにおいては、不活性化リミットは、活性化リミットからオフセットさせることにより、検知値における通常の変動に起因する障害状態信号のサイクル動作を回避する。加えて、“偽の否定”あるいは“偽の肯定”を回避するため、ほとんどの障害検知アルゴリズムは、検知値が所定の時間の間特定のリミット値の外にあることを必要とする。

システム１０のような多くのエンジン作動システムにおいては、特定のセンサに基づいて、種々のレベルの障害状態を発生する。図２のグラフは、“タイプＡ”の障害を示しており、これにおいては、活性化および不活性化活性化リミットおよび不活性化リミットを特定のセンサ値に対して固定している。この“タイプＡ”障害状態は、例えば、冷却剤あるいは潤滑剤温度センサ出力に対応させることができる。他方、“タイプＢ”障害状態は、あるセンサであってその出力が何等かの他のエンジン作動状態の関数として受け入れ可能に変化することができるそのようなセンサに対応する。１つのこのような“タイプＢ”障害状態は、図３に示したオイル圧力対エンジン速度のグラフに示している。エンジン・オイル圧力は、エンジン動作速度と共に上昇することはもちろん知られており、したがって、特定の不活性化リミットおよび活性化リミットは、それ自体、エンジン速度の関数として変化することになる。この“タイプＢ”障害状態は、速度依存のリミットとの比較を必要とするが、ＥＣＭ診断アルゴリズムは、“タイプＡ”障害に対するのと本質的に同じ方法で動作する。

その最も単純な形態においては、エンジン故障診断は、ある限られた数の可能性のある障害発生状態のみを評価する。これら基本的な障害状態の発生は、エンジンに関する問題の性質についてほとんど情報を提供しないことが多い。例えば、車両のダッシュボードの従来のオイル温度ランプの点灯は、単に、オイル温度が受け入れ可能なしきい値を超えたことの指示を提供するに過ぎず、このオイル温度が障害レベルに達した理由についてどのような情報も提供するものではない。この結果、ＥＣＭ２０は、種々のエンジン状態センサ２３ａ−２３ｒから大量のデータを受けこれを処理する複雑な診断ツールに発展してきている。この大量のデータ入力に加え、ＥＣＭ障害認識アルゴリズム（これは、それらセンサ値を種々の固定のリミット値および可変のリミット値と比較する）もまた、より複雑なものとなってきている。さらに、代表的なＥＣＭ２０は、多数のセンサからのデータを使用して各種の計算を実行するルーチンを含んでいる。例えば、シリンダ・パワー計算は、このＥＣＭで行うことにより、ある特定のシリンダが発生している理論的なパワーを決定することができる。これらパワー計算は、エンジン・エキゾーストの温度センサおよび圧力センサ、インテーク・エアの温度および圧力値、並びにエンジン速度からのデータを使用する。

このより高度の複雑さにおいては、代表的なＥＣＭ２０により、かなり多くの数のエンジン故障値をモニタし記憶する。ある代表的な用途においては、各々の特定の障害状態には、固有の識別子コードを与える。このコードには、次に、エンジン技術者かあるいはＥＣＭの他のルーチンがアクセスすることにより、種々の診断テストを行うことができる。図４のテーブルは、障害コードとこれに関連する障害との代表的な配列を示している。例示目的として、多種多様な障害状態を代表的なＥＣＭ２０が評価しそして指示を行えることが分かり、それは、高インテーク・マニホルド圧力および低インテーク・マニホルド圧力（障害コード１と２）から、プレオイル・フィルタ・センサの故障（コード９）、番号４左バンク・シリンダ・パワー（コード１６７３）、低オイル圧力（コード２０４８）にまで渡っている。

予想されることであるが、１つのエンジン故障は、多くの障害を活性化させることにつながることが多い。単純な例では、センサ・データバスあるいはハーネス２２がＥＣＭ２０から切断された場合、各センサにおけるエラーをＥＣＭが確認することになる。この状態においては、各センサは、実際には適正に動作していることがあるが、ハーネスが切断されているため、どのセンサ・データもＥＣＭが受け取らない。ＥＣＭは、センサ障害信号の各々に対する障害コードを活性化するが、これら障害コードは、必ずしもエンジン技術者を適切な解決へ導くものとならない。

別の例として、障害状態は、ある特定のシリンダに対する低エンジン・パワー・センサだけでなく、インテーク・エア・マニホルド温度センサからの信号に生ずることがある。障害コードも、それ自身に関して十分な故障情報を提供しない。しかし、ある種の状況の下では、ある特定のシリンダに対する低パワーが伴うマニホルド温度の急激な上昇は、そのシリンダに関するバルブ・シート故障に対応する可能性がある。この２つの活性化された障害コードのソースを具体的にピンポイントで指摘できないことは、エンジン技術者がその特定の故障を診断することになるため、エンジン・ダウンタイムの上昇につながる。

したがって、エンジン作動システム内に生じた実際の問題をピンポイントで指摘するのを支援することができるエンジン故障認識／診断システムに対するニーズがある。このニーズは、“偽の否定”の発生の説明をしかつこの障害指示に至った問題のソースをピンポイントで指摘するのを助ける障害認識システムにも及ぶ。

これら満たされていないニーズには、本発明の障害認識システムおよび方法により対処する。本発明の１つの形態によれば、ある特定のエンジン故障の基礎となる障害状態のタイプについて判定を行う。言い換えれば、ある具体的なエンジンのエラーまたは故障が生じたときに、基礎となる障害状態に対応する１つのグループの障害信号を発生する。本発明は、このグループの障害状態の活性化を認識し、そしてこのハイブリッドの障害状態を示す新たな信号を発する。この新たな信号は、エンジン技術者を、その問題の本当のソースに対し、より正確に導く。

したがって、本発明の障害認識システムは、エンジンに関連した状態センサ全てを読み取りそしてそれに基づき障害状態を登録する。本発明のシステムは次に、所定のグループの障害が活性化されたかどうか判定を行う。１つのグループ内の基礎障害全てが活性化されている場合、より明確なエンジン故障または故障を示す“タイプＣ”障害信号を発生する。

本発明のさらに別の形態によれば、上記基礎障害信号のある一定のものを、エンジン技術者に対する表示からマスクあるいは阻止する。ある種の場合には、１つの基礎障害信号は、エンジンの最終的な診断をほとんど困難なものにしない。他の場合には、１つの基礎障害信号の表示は、エンジン技術者を、そのエンジン問題の診断に対し効率あるいは正確さが低い経路に導くことがある。したがって、本発明は、基礎障害を評価し、そして“タイプＣ”障害信号を提供するときであっても、それら障害の内のある一定のものをマスクする。

本発明では、既存のオンボードのエンジン・コントローラ内に容易に実装できる障害認識システムを考慮している。ほとんどのエンジン・コントローラは、エンジン全体に渡る多くの状態センサを連続的にポーリングし、そしてこのセンサ信号を所定のエラー・リミットと比較する。多くのエンジン・コントローラはまた、後続のダウンロードおよび評価のためエラー状態をログ（log）する。本発明は、従来の障害検出システムよりもより意味のある情報を提供する、即時で、オンラインの障害認識および表示のためのシステムおよび方法を考慮している。ソフトウェア・ベースのエンジン・コントローラに対しては、ソフトウェア命令のバックグラウンド・ルーチンを連続的に実行することができ、これにおいて、上記センサをモニタし、障害状態活性化をポーリングし、所定のグループの障害状態の評価を行う。

本発明のある種の実施形態の別の特徴においては、“偽の肯定”または“偽の否定”を除去するための手段を設ける。１つの形態によれば、“タイプＣ”障害状態は、その状態を実際にログしそして表示するまでに、所定の時間の間存在しなければならない。同様に、“タイプＣ”障害状態が不活性となるとき、これは、本システムがその障害状態の不在を認識するまでに、所定の時間の間不活性に留まらなければならない。

本発明の１つの目的は、エンジンの問題、障害または故障の性質をより正確にピンポイントで指摘する障害認識システムを提供することである。別の目的は、そうでない場合には診断プロセスを混乱させてしまうような基礎となる障害信号の表示をマスクするかあるいは抑制する特徴により実現する。

本発明の１つの利益は、エンジン技術者が、エンジン問題の発生源をより一層容易にかつ迅速に判定できるようになることである。さらに別の利益は、本発明のシステムおよび方法を、エンジン・コントローラの障害診断ルーチン内に容易に一体化させることができることである。

本発明のこれらおよびその他の目的、利点および特徴については、添付の図面を参照して説明する本発明のシステムおよび方法により達成する。

複数のエンジン状態センサを示すエンジン作動システムの概略図。 ある特定のエンジン故障状態に対するプロトコルを示すグラフ。 別のタイプのエンジン故障状態に対するプロトコルを示すグラフ。 エンジン故障およびこれに対応する障害コードの代表的なテーブルを示すチャート。 本発明の１実施形態による、エンジン故障認識／診断ルーチンの第１の部分のフローチャート。 図５に示した障害認識ルーチンの続きのフローチャート。 図５のフローチャートに示したルーチンからのブランチ・ルーチンのフローチャート。 本発明の代替の実施形態によるエンジン故障認識／診断ルーチンのフローチャート。

本発明の原理の理解を促進する目的のため、次に図面に例示した実施形態を参照し、また特定の用語を使ってこれについて説明する。しかし理解されるべきであるが、これによって本発明の範囲のいかなる限定をも意図するものではない。本発明は、例示した装置および記述した方法における変形例や更なる変更例、並びに本発明の原理の更なる応用は、当業者に通常生ずるものと考えられるものである。

本発明では、多数の障害状態をエンジン制御モジュールが確認したときに、特定の問題、故障、または障害の状態の認識および診断の一方または両方を行うためのシステムおよび方法を考慮している。本発明は、ＥＣＭのマイクロプロセッサ内のソフトウェア・ルーチンとして実装するのが最良である。本発明の障害認識／診断ソフトウェア・プログラムは、ＥＣＭがエンジン動作を制御しかつ複数のエンジン状態センサの各々からの出力信号をモニタしている間に、バックグラウンド・ルーチンとして連続して作動することができる。代替的にはあるいは追加として、この障害認識システムは、ユーザの要求により別個に開始させることができる。

本発明の好ましい実施形態によれば、ＥＣＭが複数のエンジン障害コードであってその各々がある特定の障害状態に対応したものを保持することを考慮している。この本発明では、ある種の追加の障害コードを、既存の障害コードの所定の組合せに対応して作成する。例えば、ある特定のシリンダに対するバルブ・シート故障を示す障害コードを作成でき、この障害コードは、エア・インテーク・マニホルド温度の急激な上昇に対する障害コードと低シリンダ・パワーに対する障害コードとの受け取り時に活性化するようにする。本発明のさらに別の特徴として、ある特定の活性化された障害の基礎となる障害に対するある種の障害コードを、表示からマスクするかあるいはそれを抑制する。このようにして、エンジン技術者は、活性化された障害コードの配列が表すその特定の問題により一層容易に集中することができる。

本発明の１実施形態によれば、図５−７のフローチャートに示したソフトウェア・ルーチンは、ＥＣＭ２０のマイクロプロセッサ内に格納することができる。本発明の目的のため、このルーチンは、その開始ステップ３０において、“タイプＣ”診断ルーチンと記している。この“タイプＣ”の指示は、先に説明した“タイプＡ”および“タイプＢ”障害と区別するために用いる。詳細には、“タイプＡ”および“タイプＢ”の障害状態は、“タイプＣ”障害の活性化に対する基礎となる障害を構成するものとなる。この特定の実施形態では、“タイプＡ”および“タイプＢ”障害のある一定のもののみが、“タイプＣ”障害状態を生じさせることができる。逆に、ＥＣＭ２０が保持した複数の障害コードの内の一定のものは、“タイプＣ”障害状態を作るための基礎としては本発明のルーチンが受容しない。例えば図４を参照すると、ブロードキャスト・データの喪失（missing broadcast data）に対応する障害コード２０４７は、図示の実施形態においては、“タイプＣ”エンジン故障指示に対する基礎ではない。同様に、他の障害コード、エンジン状態障害に対応するあるものは、“タイプＣ”障害の活性化における考慮から除外することができる。

一方、多数の受容障害コードは、ＥＣＭ２０が描写（delineate）し保持する。これら受容障害コードは、例えば、以下のセンサからの障害データを含むことができる。すなわち、エンジン速度、燃料レール圧力、プレフィルタおよびポストフィルタのオイル圧力、オイル温度、オイル・レベル、冷却剤圧力、冷却剤温度、クランク・ケース圧力、周囲エア圧力、ターボチャージャ・コンプレッサ入口エア温度、ターボチャージャ入口デルタ圧力、エア・インテーク・マニホルド温度、エア・インテーク・マニホルド圧力、エキゾースト・ポート温度、ラジエータ冷却剤レベルである。加えて、計算したエンジン作動状態に対応する障害コードは、受容障害コードのリストに含めることができる。これら追加の受容障害コードは、シリンダ低パワー、マニホルド温度・インバランス、およびシリンダ・ブローバイ圧力を含むことができる。さらに、追加の受容障害コードは、障害センサ保全性および電気ハーネス連続性のようなシステム保全性情報に対応させることができる。

理解されるように、タイプＣ障害を活性化するための受容障害コードのリストには、広範囲の障害コードを組み込める。本発明によれば、受容障害コードのこのテーブルは、ステップ３２でポーリングして、何等かの障害コードがある場合に、どれが活性化されたかをＥＣＭ２０内の障害ルーチンにより判定する。ステップ３４において、受容リストの中でこの特定の障害コードが活性化されているかあるいはログされたかを判定する。もし活性化されている場合には、制御はステップ３６に進み、そしてここで、その特定の障害コードを特定の“タイプＣ”障害に対応するマップ上にログする。言い換えれば、各々の“タイプＣ”障害状態は、この“タイプＣ”障害の活性化の前に活性化されねばならない一連の基礎となる障害コードを有している。“タイプＣ”障害およびこの基礎となる障害のこの配列は、ＥＣＭのメモリ内に保持したマップとして見ることができる。したがって、１つの特定の実施形態においては、ＥＣＭが、条件ステップ３４で認識される通り、ある特定の受容障害コードを活性化した場合、その特定の基礎となる障害のためのエントリを、ステップ３６において、“タイプＣ”障害の各々に対する障害マップ上にログすることができる。

理解されるように、多くの“タイプＣ”障害状態は、共通の基礎となる障害を有することができる。例えば、低シリンダ・パワー障害は、どの他の基礎となる障害コードが活性化されるかに依存して、多くの異なった“タイプＣ”障害に対応することができる。この“マップ”アプローチを使用すると、各“タイプＣ”障害は、それ自身の基礎障害のリストを有することになり、そして各々の活性のあるいはログされた障害は、その結果として、そのマップ上の各“タイプＣ”障害エントリに対してログされることになる。

代替的には、“タイプＣ”障害は、一連の“if-then”ステートメントの形態でＥＣＭ内に存在させることができる。この状況においては、この“if-then”ステートメントは、概して、"もし基礎障害Ａが’活性’に等しく、かつ基礎となる障害Ｂが’活性’に等しいときは、“タイプＣ”障害を活性化する（If underlying fault A equals 'active' and if underlying fault B equals 'active,' then "Type C" fault is activated.）"の形態となることにある。このアプローチでは、“タイプＣ”診断ルーチン３０は、別個の“タイプＣ”障害マップを必要としないが、その代わり、“タイプＣ”障害“if-then”ステートメントの各々に対する受容障害コード全てを順次ポーリングすることができる。

再び、図５の特定の図示実施形態を参照すると、受容障害コード全てを、条件ステップ３８とリターン・ステップ３９を使用して評価する。一旦、最後の障害コードを評価することによりそれが活性かあるいはログされているかを判定すると、各“タイプＣ”障害状態に対する基礎障害の全てを、ステップ３６で障害マップ上にログしたことになる。この時点で、“タイプＣ”障害コード・エントリの各々を、ステップ４０でポーリングすることにより、“タイプＣ”障害状態が存在するかどうか判定することができる。例えば、センサ・ハーネスが切断された上述のシナリオにおいては、この故障に対応する“タイプＣ”障害コードは、ハーネスに含まれたセンサ全部に対するセンサ故障障害コードを活性化しかつ“タイプＣ”障害マップにログするのを必要とする。この状態が生じると、“ハーネス切断”コードを活性化する。同様に、説明した他の例では、バルブ・シート故障“タイプＣ”障害コードを、その２つの基礎となる“タイプＡ”および“タイプＢ”の障害コード、例えばエア・インテーク・マニホルド温度の急激な上昇と低パワー障害が活性化されかつ“タイプＣ”障害マップにログされた場合に、活性化する。再び、ステップ４０は、“if-then”ステートメントを評価してその基礎障害の全てがその特定の“タイプＣ”障害に対し活性であるかどうか判定することを構成することができる。

本発明によれば、新たに作成された“タイプＣ”コードは、診断技術者に対し、新たな情報を提供することにより、エンジンに対面してその問題の性質をより容易に判定できるようにする。したがって、切断されたセンサ・ハーネスの例では、従来の診断システムを使用すると、エンジン技術者は、複数のセンサ信号障害コードに直面していた。これら複数の障害コードは、それら個々のセンサの各々が不良であることを意味することができ、これは、技術者にその各センサの評価へと導くことになる。しかし、より現実的には、全てのセンサが障害コードを示した場合、断絶はセンサ・ハーネス内にある。本発明は、この判定をＥＣＭ内のソフトウェアを使用して行い、このソフトウェアは、“タイプＣ”障害コードを発生し、そしてこのコードは、診断技術者が読み取りそして切断されたハーネス状態として即座に理解することができる。この状況の下では、技術者は、その問題のソースに迅速に導かれ、この問題を容易に解決することができる。

ハーネス切断状態が、診断ルーチンに拘わらず、評価するには比較的単純な問題を構成することがあるが、バルブ・シート故障の問題は、そうではない。このため、本発明では、診断するのにもっと困難な障害に対応する“タイプＣ”障害状態の配列を考慮している。従来のアプローチを使用すると、エンジン技術者は、活性化された基礎障害コード全てを評価することになり、そしてそれら障害のソースとなりそうなものについて互いに独立の判定を行うことになる。バルブ・シート故障例においては、低シリンダ・パワー障害と組み合わさったエア・インテーク・マニホルド温度の急激な上昇は、最終的には、技術者が、それら両方の問題のソースがバルブ・シート故障であるとの判定に導くことになることがある。しかし、それらの基礎障害状態の内のどの１つも、その最終的な解答が決まるまで、技術者を別の診断経路に沿って導くことがある。したがって、本発明の“タイプＣ”障害診断システム３０では、エンジン技術者を、その問題のソースに対し直接かつ即座に導く。

理解できるように、“タイプＣ”障害状態の範囲は、非常に幅広くかつ広範囲に及んでいる。ある特定のＥＣＭで評価できる“タイプＣ”障害状態の数は、一般に、その評価に必要なデータを保持するのに必要なメモリ量と、各“タイプＣ”障害に対するその基礎障害コードにアクセスするのに必要な計算時間とによってのみ制限される。１つの特定の実施形態では、３２までの基礎障害コードを評価することによって、それと類似の数の“タイプＣ”障害の存在を判定することができる。

本発明による“タイプＣ”障害診断の創設は、特定のエンジン問題をピンポイントで指摘するエンジン技術者の能力の相当な向上を表している。しかし、多数の基礎障害コードがログされるかあるいは活性化されるときに、別の困難さが存在する。ここで再び、切断されたハーネス例に言及すると、各センサ・エラーに対応する活性の基礎障害コードの存在は、誤った導きを行うものであり、診断技術者の障害コード・フラッシュアウト・プロセスを遅くしてしまうことがある。それらセンサ全てをＥＣＭが障害ありと確認する場合、各センサに欠陥があるよりも、ハーネスが切断されている可能性が高い。

本発明は、ある種の基礎障害をマスクすることによりこの困難さを考慮する。用語“マスク”は、それら特定の基礎障害コードをエンジン診断技術者に対する表示から抑制することを意味するが、但し、そのコードは、その他の場合にはＥＣＭが記憶装置に保持することができる。このため、切断ハーネスの場合には、活性化されることになる障害コードは、“タイプＣ”障害コードのみである。その基礎センサ故障の各々に対する障害コードは、エンジン技術者が、その特定のエンジンに対する活性の障害コード全てを検査するときに、マスクするかあるいは抑制する。これら基礎障害コードは、同時期の表示からマスクすることにより、エンジン技術者を問題のソースに対し迅速に引きつけるようにすることができる。代替的には、基礎障害コードはまた、後続のダウンロードあるいはＥＣＭが保持する障害履歴ファイルからマスクすることができる。

本発明によれば、一旦、ある特定の“タイプＣ”障害に対応する基礎障害コード全てが、ステップ４２においてログされたことを判定すると、制御は続行ステップ５０にて本ルーチンの後続のステップに進む。この“タイプＣ”障害コードは、ステップ５２において表示する。ステップ５４では、基礎障害コードのいずれかあるいはその全てをマスクすべきかどうかについて判定を行う。１つのテーブルは、基礎障害コードの各々に対応して保持することができ、これは、一旦“タイプＣ”障害状態がステップ５２において表示されたとき、そのコードの表示を抑制すべきかどうか示す。場合によっては、この基礎障害コードは、エンジン技術者に対し重要な情報を提供することを考慮している。この場合、特定の基礎障害はマスクせず、ステップ５６においてその表示を行う。代替的には、この特定の障害コードをマスクすべき場合、ステップ５８においてその表示を抑制する。条件ステップ６０とリターン・ループ６２は、特定の“タイプＣ”障害に対する基礎障害コード全てを評価しそして表示をするかあるいはマスクするまで、続行する。ステップ６４においては、任意の他の“タイプＣ”障害状態が存在するかどうか判定する。無い場合、本ルーチンは、ステップ６６で終了する。存在する場合、制御は続行ステップ６８から図５のメイン・ルーチンの特にステップ４０に進み、ここで、次の“タイプＣ”障害をポーリングする。

したがって、図６のフローチャートに示した本発明の特徴では、ある種の基礎障害コードを抑制することにより診断プロセスを混乱させないようにすることができる。他方、ある種の他の基礎障害コードは、重要であると考え、したがってステップ５６において、ステップ５２における“タイプＣ”障害コードの表示と同時に表示する。この表示は、任意の既知の形態を取ることができ、例えば、単一のアナンシエータ、障害コード・シーケンスのフラッシュアウト、英数字ディスプレイあるいはＣＲＴモニタである。加えて、この表示した“タイプＣ”および基礎障害コードは、障害履歴テーブル内に保持することにより、エンジン技術者がサービス・ツールを使用してダウンロードし評価することができる。

切断ハーネス例を使用すると、エンジン・センサ全ての故障に対する基礎障害コードが活性化されることになる。全てのセンサ障害コードのこの活性化は、切断されたハーネスの指示に対応する１つの“タイプＣ”障害の発生につながる。エンジン技術者の観点からすれば、一旦、切断ハーネスに対する“タイプＣ”障害コードが活性化されると、他の障害コード情報は全く必要でない。したがって、個々のセンサ故障の各々に対応する障害コードは、表示からマスクする。この特定の“タイプＣ”障害コードが活性化されると、エンジン技術者は、センサ・ハーネスを接続し直すことにより、その問題を容易に解決することができる。

ここで、おそらく、個々のセンサ障害コード全てが不活性化され、そして対応する“タイプＣ”障害コードも活性化される。しかし、ある種の状況においては、個々のセンサの内の１つ以上が実際に故障していることもある。この場合、その特定のセンサに対する障害コードは、活性化されたままとなる一方で、残りのセンサの障害コードは不活性化されることになる。センサ障害コード全てが図６のフローチャートのステップ５８にしたがってマスクされたままであると、エンジン技術者は、この基礎障害が存在し続けることに決して気づくことはない。

このため、本発明は、この重要なことに対し、本ルーチンの図７に示した部分により対処する。一旦、その適当な“タイプＣ”障害コードまたはその基礎障害コードがマスクされるかあるいは表示され、かつ本ルーチンがステップ６６で終了すると、エンジン技術者は、この問題を正す機会を得ることになる。この問題を正した後、“タイプＣ”診断ルーチン３０は再開する。ここで、ステップ４２の条件は、“ＮＯ”回答を生じ、これは、その特定の“タイプＣ”障害に対する基礎障害コードの全てが障害マップにログされなかったことを意味する。言い換えれば、この特定の“タイプＣ”障害状態はもはや存在しない。この場合、制御は、続行ステップ７０で、図７のフローチャートに示したステップ・シーケンスに進む。

最初のステップ７２において、特定の“タイプＣ”障害コードを不活性化して、その障害が表示されないようにする。次に、基礎障害コードの任意のものが条件ステップ７４において活性化されているかどうかについて判定を行う。もし特定の障害コードが活性でない場合、制御はステップ８０に進む。一方、その基礎障害コードが依然として活性である場合、制御は条件ステップ７６に進む。このステップで、その特定の基礎障害コードが、ステップ５８（図６）においての発生のように、先に表示からマスクされているかどうか判定する。もしこの障害コードがマスクされていなかった場合、制御は通常は条件ステップ８２に進む。一方、この障害コードが、条件ステップ７６により判定された通り先にマスクされており、かつその基礎障害コードが、ステップ７４において判定された通り依然として活性である場合、この特定の障害コードは、ステップ７８において、マスクを解除（unmask）しなければならない。このとき、この基礎障害コードは、エンジン技術者による評価のため表示することができる。

ステップ８２において、さらにもっと基礎障害コードを考慮すべきかどうかについて判定を行う。考慮すべき場合、制御はループ８４でリターンすることにより、次の障害コードの評価を行う。特定の“タイプＣ”障害に対する基礎障害コードの全てについての評価を完了した場合、さらに別の条件ステップ８６で、さらにもっと“タイプＣ”障害コードを検査しなければならないかどうか判定する。もしもっと“タイプＣ”障害コードを考慮すべき場合、制御は続行ステップ６８から図５のフローチャートのステップ４０に戻る。“タイプＣ”障害コードの全ての再評価を完了した場合、本ルーチンは、ステップ６６で終了する。

理解されるように、“タイプＣ”診断ルーチン３０は、好ましくは、ＥＣＭが管理する他のエンジン制御ルーチンに対するバックグラウンド・ルーチンとして継続的に実行する。この場合、終了ステップ６６は、好ましくは、リターン・ステップを構成し、これにおいては、制御はＥＣＭが制御するフォアグランドまたはスケジューリングのルーチンに移る。

図７のフローチャートに示したプロトコルの利益は、ハーネス切断“タイプＣ”障害を再び検討することにより理解することができる。一旦ハーネスが再接続されると、“タイプＣ”診断ルーチン３０は、その基礎障害コードの全てを再評価する。ハーネス切断“タイプＣ”障害コードの活性化のため、この所定の基礎センサ障害コードの全てが活性化されなければならない。これら障害コードのどの１つももはや活性化されていない場合、この特定の“タイプＣ”障害コードに対する“if-then”テストが不合格となり、したがってそのコードは、ステップ７２において不活性化する。しかし、センサの内の１つまたはそれ以上が依然として不良であることがあり、これは、それら特定のセンサに対する基礎障害コードは依然として活性化されたままとなることを意味する。このため、条件ステップ７４に対する答えは肯定となる。加えて、それら基礎センサ障害は、本ルーチンを通る先のパスにおいてステップ５８（図６）でマスクされていたため、条件ステップ６６に対する答えもまた肯定的である。ステップ７８は、次に、特定のセンサに対する障害コードをマスク解除するために必要となる。これが起きると、エンジン技術者は、さらに別のエラーを発見することになり、これは、今は、特定の“不良”センサをピンポイントで指摘することになる。

別の例では、インテーク・バルブ故障は、特定の影響を受けたシリンダに対する、エア・インテーク・マニホルド温度の急激な上昇と低パワーに対応することができる。この場合、“タイプＣ”障害は、インテーク・バルブ故障であり、その基礎障害は、インテーク・マニホルド温度の急激な上昇と低シリンダ・パワーとである。本発明のシステムに従えば、インテーク・バルブ故障の“タイプＣ”障害コードは、条件ステップ４２において査定しそしてステップ５２で表示することになる。この特定の“タイプＣ”障害コードは、上記の２つの基礎障害を含んでいる。しかし、この障害では、低パワー障害コードの表示は、エンジン技術者が、そのバルブ故障の根本的原因を判定するのに役立つことになると、考えられる。他方、インテーク・マニホルド温度の急激な上昇の障害コードは、この診断プロセスに対してほとんど何もあるいは全く何も追加するものではない。したがって、インテーク・バルブ故障“タイプＣ”障害では、条件ステップ５４には、低シリンダ・パワー障害コードに対して否定的な回答がなされ、したがってこのコードはステップ５６において表示する。一旦この“タイプＣ”障害コードをステップ７２において不活性化すると、低シリンダ・パワーの基礎障害コードが活性のままである場合、条件ステップ７４に対する回答は肯定的となる一方で、条件ステップ７６に対する回答は否定的となるが、その理由は、その障害コードが、先にマスクされていなかったからである。最終的には、低シリンダ・パワーに対するこの基礎障害コードは、両方が本ルーチンをパスした後に表示されることになる。

図２のグラフに示したように、ある種の障害コードは、この特定の障害状態が所定の時間の間存在することになるまでは、活性化しない。その上、この特定の障害は、この障害状態が解消されない限り、あるいは先の活性の障害後において所定の時間の間存在しない限り、不活性化しない。これと同様のアプローチは、本発明の“タイプＣ”診断分析に適用することができる。したがって、図８に示した本発明の代替の実施形態においては、“タイプＣ”診断ルーチン３０は、ステップ３２において、受容障害コードをポーリングすることにより開始する。ステップ３４において、活性の基礎障害は、“タイプＣ”障害マップにログする一方で、ステップ４０において、これらエントリを各“タイプＣ”障害コードに対しポーリングする。図５のルーチンにおけるのと同様に、条件ステップ４２は、各特定の“タイプＣ”障害に対する基礎障害の全てをログしたかどうかを判定する。しかし、ある種の状況の下では、特定の“タイプＣ”障害に対するある種の基礎障害コードは、例外および外部の影響により活性となった後、不活性のまま進行することがある。特定の基礎障害が真に不活性であることを確実にするため、本発明では、“タイプＣ”障害ディスエーブル・タイマを考慮している。このタイマは、ＥＣＭ１０が保持する実際のクロック・タイム、あるいはルーチン３０を通る各パスで増分するソフトウェア・カウンタを指すことができ。このため、ステップ９０において、ディスエーブル・タイマが始動されたかどうか判定する。始動されていない場合、このタイマをステップ９１において始動し、そしてそうでない場合には、制御はループ９２に進む。

条件ステップ９３において、このタイマをチェックすることにより、これが満了したかどうかみる。もし満了している場合、このタイマをステップ９４においてリセットし、そして制御は、続行ステップ７０で図７のサービス・ルーチンに進む。タイマがステップ９３において満了している場合、全ての基礎障害がログされていないとき、このときには“タイプＣ”障害は発生していない。したがって、この“タイプＣ”障害コードは、ステップ７２（図７）において不活性化し、そして本プログラムは、先に説明した通り流れる。このディスエーブル・タイマが満了していない場合、制御は、続行ステップ９９でリターンして、基礎障害コードを再度ポーリングする。

ステップ４２に戻ると、もし全ての基礎障害コードが活性である場合、この特定の“タイプＣ”障害が推定で発生している。“偽の肯定”を回避するため、障害タイマを利用する。ディスエーブル・タイマと同様に、障害タイマは、クロック・タイムあるいはソフトウェアに基づかせることができる。このタイマがステップ９５で始動されていない場合、これをステップ９６で始動させる。もしこの障害タイマがステップ９７で満了していない場合、制御は、ステップ９９でリターンして、基礎障害コードを再ポーリングする。

診断ルーチン３０を通る各パスにおいて、各“タイプＣ”に対する基礎障害を評価する。ある“タイプＣ”障害に対する状態が活性のままである限り、制御は、ステップ９５−９７を通る。このタイマが、“タイプＣ”障害状態の下でステップ９７で満了している場合、制御は、続行ステップ５０、そして図６のフローチャートの表示ステップ５２に進む。この障害タイマもまた、ステップ９８においてリセットする。

図８のフローチャートに示したルーチンは、条件ステップ４２が別の異なった結果にサイクルする度に、ディスエーブル・タイマおよび障害タイマをリセットするように変更することができる。言い換えれば、第１のパスで、ステップ４２の結果が否定的となることがあり、これは、“タイプＣ”障害がないことを意味し、そしてディスエーブル・タイマを開始させることになる。障害タイマは、条件ステップ４２が否定的に留まる限りにおいてのみ走り続けることになる。一旦、ステップ４２に対する回答が肯定的になると、“タイプＣ”障害状態が発生したことになり、ディスエーブル・タイマを停止させることができ、かつ障害タイマを始動させることができる。

さらに別の代替例として、障害タイマは、条件ステップ４２が本ルーチンを通る１つのパスの間に否定にサイクルするときでも、走り続けることができる。したがって、状態の瞬間的な変化は、所定の障害タイマ時間に渡る“タイプＣ”障害判定に影響を与えない。これと同じアプローチは、ステップ９０−９４におけるディスエーブル・タイマで取ることができる。

以上に、本発明について、図面および上記記述で詳細に図示し説明したが、これは、例示であって、限定的な性質のものではないとみなされるべきである。好ましい実施形態のみを示し説明したこと、並びに本発明の範囲内に入るあらゆる変更、修正をその保護を希望するものであることは、理解されるべきである。

例えば、上記の記述全体に渡って、障害コードは、“活性”と“不活性”のいずれかとして評価している。この障害および基礎障害に対する第３の状態を“ログ”することができ、これは、障害が、活性であったが現在は活性でないことを意味する。この“ログ”された状態は、本発明のアルゴリズムにより、“タイプＣ”障害状態を発する基礎として使用することができる。

本発明は、基礎障害コードの配列であって、活性のものがあり、ログされたものがあり、かつ不活性のものがあるような基礎障害コードの配列を考慮するように変更することができる。言い換えれば、“タイプＣ”状態は、障害１が活性であり、障害２が活性であり、障害３がログされており、障害４が不活性であるときに、生じるようにプログラムすることができる。ある種の非障害の状態も、“タイプＣ”障害判定を作るのに適用することもできる。例えば、ある特定の“タイプＣ”障害は、エンジンは回っていて（エンジン速度がアイドル速度あるいはこれより上）かつ暖まっている（オイル温度がしきい値より上）ある種の定常状態のエンジン作動状態を必要とすることがある。

これらと同じ線で、本発明のアルゴリズムは、“タイプＣ”障害の活性化における条件ステートメントを実施するように変更することができる。例えば、ある特定の“タイプＣ”障害は、条件１または条件２のいずれかが満足された場合に活性化することができる。条件１は、多数の基礎障害の状態に対応させることができる一方で、条件２は、それとは異なった多数の基礎障害の状態に対応させることができる。

さらに別の変更例として、１つの“タイプＣ”障害状態は、別の１つの“タイプＣ”障害の活性化を必要とすることができる。理解されるべきであるが、ある特定の“タイプＣ”障害に対する基礎障害マップは、診断技術者に対し最大の量の情報を提供するように確立することができる。これを１つの目的として、不活性の障害コードでさえも、診断プロセスをより迅速にかつより正確にするのに価値のある情報を提供することができる。

１０ 内燃エンジン制御システム
１３ エンジン・クランクシャフト
１１ エンジン
１２ ピストン
１５ インテーク・マニホルド
１６ エキゾースト・マニホルド
１７ 燃料システム
１８ 冷却システム
１９ 潤滑システム
２０ ＥＣＭ
２２ センサ・データバス
２３ａ−２３ｒ 状態センサ
２４ 出力ポート

Claims (14)

1. 内燃エンジンの障害認識の方法であって、前記エンジンが、複数のセンサであって対応する複数のエンジン動作状態を検知するよう動作可能な複数のセンサと、ディスプレイ・ユニットと、オンボードのエンジン・コントローラとを含み、該オンボードのエンジン・コントローラが、障害コード・テーブルを格納したメモリを含み、各障害コードが、前記複数のセンサのうちの１つに関連した特定の障害状態に対応し、各前記障害コードが、これが関連するセンサが正常に動作しているときは不活性化され、これが関連するセンサが障害状態を示すときは活性化され、前記方法が、
   受容障害コードのリストをメモリに維持するステップであって、前記受容障害コードのリストが、前記複数の障害コードのうちの所定のグループの障害コードを含む、ステップと、
   前記受容障害コードのリスト内の前記障害コードの各々が活性であるかどうかを判定するため、前記障害コード・テーブル内の前記複数の障害コードを連続的に処理するステップと、
   前記受容障害コードのリスト内の前記障害コードの各々が活性の場合、新たな障害信号を発生するステップと、
   前記新たな障害信号を処理してその視覚的指示を前記ディスプレイ・ユニットに表示するステップと、
   前記受容障害コードのリスト内の前記障害コードのうちの１つ以上の障害コードの前記ディスプレイ・ユニットにおける表示を抑制するステップと、
   前記ディスプレイ・ユニットに、前記新たな障害信号と、前記受容障害コードのリスト内の前記１つ以上の障害コード以外の障害コードとの視覚的指示を表示するステップと、
   を含む障害認識方法。
2. 請求項１記載の方法において、前記新たな障害信号を処理してその視覚的指示を前記ディスプレイ・ユニットに表示するステップは、前記新たな障害信号が、所定の時間の間、または前記新たな障害信号を発生する前記ステップの所定の数の実行の間、活性化された状態に留まる場合にのみ、前記新たな障害信号の前記視覚的指示を前記ディスプレイ・ユニットに表示するステップを含む、方法。
3. 請求項１記載の方法であって、さらに、
   関連する障害状態をもはや示さない前記複数のセンサの任意のものに対する前記障害コード・テーブル内の活性化された障害コードを不活性化するステップと、
   前記受容障害コードのリスト内の前記障害コードのうちの少なくとも１つの障害コードが不活性化されたとき、前記新たな障害信号を不活性化するステップと、
   を含む、方法。
4. 請求項３記載の方法において、前記新たな障害信号を不活性化するステップは、前記受容障害コードのリスト内の前記障害コードのうちの前記少なくとも１つの障害コードが、所定の時間の間不活性化された場合、または前記障害コード・テーブル内の複数の障害コードを連続的に処理する前記ステップの所定の数の実行後にのみ、前記新たな障害信号を不活性化するステップを含む、方法。
5. 請求項１記載の方法において、前記新たな障害信号を活性化するステップは、前記複数の障害コードの部分集合内の前記障害コードの各々が、所定の時間の間活性である場合、または障害コード・テーブル内の前記複数の障害コードを連続的に処理する前記ステップの所定の数の実行後にのみ、前記新たな障害信号を活性化するステップを含む、方法。
6. 請求項１記載の方法において、前記障害コード・テーブル内の前記複数の障害コードを連続的に処理するステップは、
   前記障害コード・テーブル内の前記複数の障害コードの各々であって活性のものを、活性障害コード・テーブルにリストするステップと、
   前記活性障害コード・テーブルを処理して、前記複数の障害コードのうちの所定のグループの障害コード内の前記障害コードの各々が前記活性障害コード・テーブル内にリストされているかどうか判定するステップと、
   を含む、方法。
7. 請求項１記載の方法において、前記障害コード・テーブル内の前記複数の障害コードを連続的に処理するステップは、前記複数の障害コードのうちの所定のグループの障害コードを形成する前記障害コード・テーブル内の障害コードのみを処理して、前記複数の障害コードの前記所定のグループの障害コード内の前記障害コードの各々が活性であるかどうかを判定するステップを含む、方法。
8. 内燃エンジンの障害認識システムであって、
   複数のセンサであって、対応する複数のエンジン動作状態を検知するよう動作可能な複数のセンサと、
   ディスプレイ・ユニットと、
   オンボードのエンジン・コントローラであって、前記オンボードのエンジン・コントローラが障害コード・テーブルを格納したメモリを含み、各障害コードが、前記複数のセンサのうちの１つに関連した特定の障害状態に対応し、各前記障害コードが、これが関連するセンサが正常に動作しているときは不活性化され、これが関連するセンサが障害状態を示すときは活性化される、エンジン・コントローラと、
   を含む障害認識システムにおいて、
   前記メモリが更に、受容障害コードのリストを格納し、該受容障害コードのリストが、前記複数の障害コードのうちの所定のグループの障害コードを含み、前記メモリが、命令を格納しており、該命令は、
   前記受容障害コードのリスト内の前記障害コードの各々が活性であるかどうかを判定するため、前記障害コード・テーブル内の前記複数の障害コードを連続的に処理し、
   前記受容障害コードのリスト内の前記障害コードの各々が活性の場合、新たな障害信号を発生し、
   前記新たな障害信号を処理してその視覚的指示を前記ディスプレイ・ユニットに表示し、
   前記受容障害コードのリスト内の前記障害コードのうちの１つ以上の障害コードの前記ディスプレイ・ユニットにおける表示を抑制し、
   前記ディスプレイ・ユニットを制御して、前記新たな障害信号と、前記受容障害コードのリスト内の前記１つ以上の障害コード以外の障害コードとの視覚的指示を表示すること、
   を行うために前記オンボードのエンジン・コントローラにより実行可能である、障害認識システム。
9. 請求項８記載のシステムにおいて、前記メモリに格納された前記命令はさらに、
   前記新たな障害信号が所定の時間の間活性化された場合、または前記新たな障害信号を活性化することの所定の数の反復の間後にのみ、前記新たな障害信号の前記視覚的指示を表示するため前記ディスプレイ・ユニットを制御すること、
   を行うため、前記エンジン・コントローラにより実行可能な命令を含む、システム。
10. 請求項８記載のシステムにおいて、前記メモリに格納された前記命令はさらに、
    障害状態をもはや示さない前記複数のセンサの各々に対する前記障害コード・テーブル内の活性化された障害コードを不活性化し、
    前記受容障害コードのリスト内の前記障害コードのうちの少なくとも１つの障害コードが不活性化されたとき、前記新たな障害信号を不活性化すること、
    を行うため前記エンジン・コントローラにより実行可能な命令を含む、システム。
11. 請求項１０記載のシステムにおいて、前記メモリに格納された前記命令はさらに、
    前記受容障害コードのリスト内の前記障害コードのうちの前記少なくとも１つの障害コードが所定の時間の間不活性化された場合、または前記障害コード・テーブル内の前記複数の障害コードを処理することの所定の数の反復後にのみ、前記新たな障害信号を不活性化すること、
    を行うため前記エンジン・コントローラにより実行可能な命令を含む、システム。
12. 請求項８記載のシステムにおいて、前記メモリに格納された前記命令はさらに、
    前記受容障害コードのリスト内の前記障害コードの各々が所定の時間の間活性である場合、または前記障害コード・テーブル内の前記複数の障害コードを処理することの所定の数の反復後にのみ、前記新たな障害信号を活性化すること、
    を行うため前記エンジン・コントローラにより実行可能な命令を含む、システム。
13. 請求項８記載のシステムにおいて、前記メモリに格納された前記命令はさらに、前記障害コード・テーブル内の前記複数の障害コードを処理することを、
    前記障害コード・テーブル内の前記複数の障害コードの各々であって活性のものを、活性障害コード・テーブルにリストし、
    前記活性障害コード・テーブルを処理して、前記複数の障害コードのうちの所定のグループの障害コード内の前記障害コードの各々が前記活性障害コード・テーブル内にリストされているかどうか判定すること、
    によって行うため前記エンジン・コントローラにより実行可能な命令を含む、システム。
14. 請求項８記載のシステムにおいて、前記メモリに格納された前記命令はさらに、前記障害コード・テーブル内の前記複数の障害コードを処理することを、
    前記複数の障害コードうちの所定のグループの障害コードを形成する前記障害コード・テーブル内の障害コードのみを処理して、前記複数の障害コードのうちの前記所定のグループの障害コード内の前記障害コードの各々が活性であるかどうかを判定すること、
    によって行うため前記エンジン・コントローラにより実行可能な命令を含む、システム。

Images