JP2010538249A - 自動車の故障を診断するための方法およびシステム - Google Patents

Abstract

本発明は、診断ツールと、車両に搭載される計算モジュールアセンブリにより与えられるデータまたは制御命令の解析とを使用する自動車の故障を診断する方法であって、データの値または制御へのリンクを診断方法のディスプレイ内に動的に表示することによって車両の機能部材の組の動作を変換するための方法に関する。方法は、車両動作制御の濃縮ディスプレイ構造（９）を生み出すステップと、リフレッシュされるべき制御データのリスト（１０）を生み出すステップと、それぞれの計算モジュールからのリフレッシュされた制御データを回収するステップと、濃縮ディスプレイ構造とリフレッシュされた制御データとから最終表示（８）を生み出すステップとを含み、濃縮ディスプレイ構造を生み出すステップ、リフレッシュされるべきデータのリストを生み出すステップ、リフレッシュされたデータを回収するステップ、および、最終表示を生み出すステップは、監視モジュール（Ｄ）の制御下で行なわれる。

Description

本発明は、修理工場またはメンテナンス工場で使用される、航空機またはボート、より具体的には自動車などの輸送手段の故障の診断に関する。

現在、車両が障害すなわち故障または欠陥を呈すると、その原因を特定するために、例えば車両の所有者またはドライバによって明白に系統立てて説明される症状から原因を特定できるようにする故障追跡ツリー（ｆａｕｌｔ−ｔｒａｃｉｎｇ ｔｒｅｅ）の形態で診断方法が適用される。

この診断方法は、段階的に行なわれ、車両に対して行なわれるべき修理を決定するために欠陥の原因の特定に至らなければならない。

一般に、診断方法のそれぞれのステップで、または、一般に、診断方法のステップのうちの少なくとも一部で、技術者は、自動車に搭載された計算モジュールをチェックし或いは制御して、診断データを回収し或いはこれらのモジュールの内部の機能を起動させなければならない。

連続するステップによって欠陥部材を追跡できるようにするこの診断方法と並行して、技術者は、車両内の特定数の車載リソースを有する。したがって、技術者は、車両の計算モジュールから診断データを回収でき或いはこれらのモジュールの内部の診断機能を起動させることができる可能性を有する。

これらのリソースは、直接にアクセスできる情報を供給する。これらのリソースは、それらが関与する車両の部材の動作に関連している。

診断中、技術者は、一般に、診断方法を適用できるようにする或いはデータを回収できるようにする或いは計算モジュールから得る診断制御を起動させることができるようにする診断ソフトウェアを組み込む診断ツールを使用する。

この解決策は特定数の主要な欠点を有する。

実際には、診断ツールは、診断方法のステップに対応する或いは計算モジュールから得られる診断データの表示に対応する或いは計算モジュールの内部の診断機能の起動に対応するスクリーンの形態で特定数のヒューマン／マシンインタフェースを技術者に提供する。

したがって、診断方法を実行すると、技術者は、計算モジュールから得られる診断値を基準値に対してチェックすることが求められ或いは内部診断機能を起動させてその効果をいわゆる基準挙動と比較することが求められる場合がある。

このコンサルティングは、１つのスクリーンを他のスクリーンへと移動させることを伴うとともに、特定数のナビゲーション手続きを必要とし、その結果、かなりの無意味な時間の浪費をもたらす。また、この解決策は、僅かとは言えないエラーの危険を生み出し、１つのスクリーンから他のスクリーンへの移行が、コンサルティングエラー、例えば誤った診断データの取得、したがって、診断エラーを引き起こす可能性がある。

しかしながら、チェックの結果に応じて、制御データの取得は必要な段階であるため、チェックされたデータの値にしたがって診断方法が異なるその後のステップへと続けられる場合がある。

以上に照らして、欠陥または故障を追跡して特定できるようにする診断方法、および、車両に搭載された計算モジュールによってもたらされるデータまたは制御の両方をユーザが使用できるようにするとともに、１つの同じヒューマン／マシンインタフェース内でそのようにすることができるようにする診断ツールを有する必要性がある。

したがって、本発明の主題は、第１の態様によれば、診断ツールを使用することによって、また、自動車に搭載される計算モジュールの組から利用できる制御データまたは命令を解析して、車両の機能部材の組の動作を反映することにより、自動車の故障を診断する方法である。

この方法の一般的な特徴によれば、方法は、
− 制御データまたは命令で濃縮される車両で実行されるべき制御動作のシーケンスを記述する濃縮ディスプレイ構造を生成するステップと、
− リフレッシュされるべき制御データのリストを生成するステップと、
− それぞれの計算モジュールによってもたらされるリフレッシュされた制御データを回収するステップと、
− 濃縮ディスプレイ構造とリフレッシュされた制御データとから最終表示を生成するステップと、
を含む。

濃縮ディスプレイ構造を生成する前記ステップ、リフレッシュされるべきデータのリストを生成する前記ステップ、リフレッシュされたデータを回収する前記ステップ、および、最終表示を生成する前記ステップは、監視モジュールの制御下で行なわれる。

この方法の他の特徴によれば、リフレッシュされるべき制御データのリストの生成中、診断要求の記述を含む各計算モジュールのためのベースから診断要求が生成される。

また、制御データの回収中、計算モジュールによって伝えられる１つ以上の応答が例えばデコードされる。

また、回収された制御データに基づいて、リフレッシュされた制御データファイルを更新することもできる。

方法の更に他の特徴によれば、最終表示は、ディスプレイ構造から、および、最終表示が視認されるヒューマン／マシンインタフェースに対応するディスプレイデータベースより抽出される表示パラメータから生成することができる。

本発明の方法の更に他の特徴によれば、ディスプレイ構造の生成中、および、リフレッシュされるべき制御データのリストの生成中に、診断ツールのための診断命令コードの組と診断命令コードを適用するためのマーカの組とを含む診断ファイルが解析され、前記マーカが検出されるとともに、オペレータの側の行為を適用する傾向がある第１のタイプのマーカと制御データを回収する傾向がある或いは車載診断機能を制御する傾向がある第２のタイプのマーカとの間を識別するために前記マーカが解析される。

第１のタイプのマーカが検出されると、テキストデータまたは画像が濃縮ディスプレイ構造中に挿入される。

また、第２のタイプのマーカが検出されると、マーカの相補的解析が行なわれ、それにより、計算モジュールによって診断機能を適用する傾向がある第３のタイプのマーカと、制御データ値を取得する傾向がある第４のタイプのマーカとの間で識別が行なわれる。

例えば、第３のタイプのマーカの検出に応じて、制御マーカが濃縮ディスプレイ構造中に挿入される。

また、第４のタイプのマーカの検出に応じて、一方ではリフレッシュされるべきデータを含むファイル中に項目を挿入し、他方では制御データの読み取りを制御するためのソフトウェアコンポーネントを濃縮ディスプレイ構造中に挿入することもできる。

本発明の他の主題は、第２の態様によれば、自動車の故障を診断するためのシステムであって、
− 診断方法と診断ツールから得られるデータとに基づいて車両の動作を制御するための濃縮ディスプレイ構造を生成するとともに、リフレッシュされるべき制御データのリストを生成する第１のステージと、
− 自動車に搭載されるそれぞれの計算モジュールによりもたらされる制御データを動的に回収する第２のステージと、
− 濃縮ディスプレイ構造とリフレッシュされた制御データとから、最終表示を生成する第３のステージと、
を備えるシステムである。

システムは、前記第１、第２、および、第３のステージを制御するための１つ以上の監視ステージを更に含む。

本発明の他の目的、特徴、および、利点は、単なる非限定的な例として与えられ且つ添付図面に関連して与えられる以下の説明を読むことにより明らかになる。

自動車用診断設備の一般的な構成を示すブロック図である。 本発明に係る自動車用診断システムの構造を示す。 図２のシステムの第１のステージの動作の主要ステップを示すフロー図である。 図２のシステムの第２のステージの動作の主要ステップを示すフロー図である。 図２のシステムの第３のステージの動作の主要ステップを示すフロー図である。 図２のシステムの監視ステージの動作の主要ステップを示すフロー図である。

図１に示される診断設備は、自動車１の故障をチェックすることを目的としている。

この図から分かるように、診断は、車両１に搭載された計算モジュールによって供給される制御データまたは命令と組み合わせて診断方法を技術者に与えて使用できるようにする診断ツール２の使用に基づいている。

車両の診断は、最初に、修理工場またはメンテナンス工場での診断行為に必要なデータの組を構成することを伴う。

したがって、診断方法は、例えばマイクロコンピュータ３から得る或いはマイクロコンピュータ３でホストされるソフトウェアを使用して、使用されるべき診断方法を規定し且つ車載診断リソース、すなわち計算モジュールへの照会を含む特定数の例えば４のファイルを生成することによりもたらされる。

また、診断リソースの定義は、例えばマイクロコンピュータ６から得る或いはマイクロコンピュータ６内でホストされる診断データを生み出すためのソフトウェアによって生成される例えば５のファイルの組の使用によって回収される。これらのファイル５は、制御データまたは命令と計算モジュールから制御データを回収するために使用されるべき通信パラメータとを供給する可能性が高い車両に搭載されるリソースを規定する。

図示のように、一方が診断方法を生み出すために使用され且つ他方が診断データを生み出すために使用されるハードウェア・ソフトウェアリソース３，６間で通信が設けられる。これらの２つのハードウェアリソースは、例えば１つの同じマイクロコンピュータで完全にうまく共存することができ、コンピュータネットワークを介してアクセス可能にされ得る。

また、ファイル４，５の内容は、例えばデータベース７の媒介を通じて或いは診断ツール２で局所的に入手できるファイルの任意の組を通じて診断ツール２が利用できるようにされ、あるいは、コンピュータネットワークを通じてこのオンラインツールが利用できるようにされる。

言い換えると、診断方法と、制御データを回収するため或いは診断方法の診断機能を起動させるために使用される計算モジュールへの照会とが、診断ツール２のデータベース７内で組み合わされ、それにより、これらの診断リソースへの照会が診断方法に直接に組み入れられ、したがって、以下で詳しく説明されるように、診断方法と制御データまたは命令とを同時に組み入れる結果がヒューマン／マシンインタフェースで動的に表示される。

ここで図２を参照すると、診断ツール２は、ここではスクリーン８によって形成されるヒューマン／マシンインタフェースでの最終表示を生成して、診断方法、制御データ、および、制御命令を組み合わせて含む情報を技術者に与えるために共同して作動するモジュールＡ，Ｂ，Ｃ，Ｄの組を含む。

第１のステージＡは、診断リソースへ照会する制御データまたは命令データと組み合わせられる濃縮ディスプレイ構造９を含む中間ファイルを生成するために使用される。

また、第１のステージは、リフレッシュされるべき制御データを記述するリスト１０の形態を成すファイルを第２のステージＢへ供給する。

第２のステージＢは、リフレッシュされるべき制御データのこのリストを回収する。また、第２のステージは、車載計算モジュールとの通信のためのパラメータＰの組、および、計算モジュールで利用できる診断リソースを規定するために使用される記述子Ｄも回収し、これらのデータ項目Ｐ，Ｄはデータベース７から回収される。

この情報から、第２のステージＢは、要求Ｒと、特に更新された制御データを含む応答Ｒ’とにより、計算モジュールとやりとりし、前記要求および前記応答は、デコードされた後に、動的データの形態で中間ファイル９に記憶される。例えば、これらの要求は、各計算モジュール毎にベースから抽出されるデータ要求のリストから生成される。

図２から分かるように、第３のステージＣは、濃縮ディスプレイ構造９を読むことによってリフレッシュされ且つステージＢによって動的に更新された制御データを回収し、したがって、使用される可能性が高い各ヒューマン／マシンインタフェース毎に必要な表示パラメータを記述する例えばデータベース７に組み込まれるベースから抽出される表示パラメータＰ’にしたがって最終表示を生成する。

診断システムの構成に関与する主要項目、特に最終表示を生成するための第３のステージＣの動作は、例えばユーザ技術者の側の行為Ａに応じて特に表示変更を得る傾向がある要求Ｒ’’を生成して第３のステージＣへ伝える第４のステージＤによって制御される。

ここで、以下、図３を参照して、中間ファイルの生成の第１のステージＡの動作の主要ステップについて説明する。

第１のステップ１１中、ステージＡは、診断データおよび命令で濃縮された診断方法を記述するデータベース７に記憶されるファイル、すなわち、制御データを回収するため或いは計算モジュールの診断機能を起動させるために使用される情報を読み取る。

特にファイルのフォーマットおよびファイルの構文に関してファイルをチェックした後（ステップ１２）、このファイルが正しいかどうかをチェックするために検査が行なわれる（ステップ１３）。

ファイルが正しくない場合には、エラーメッセージが生成される（ステップ１４）。次のステップ１５では、ファイルが正しいことが分かった場合に、チェックがヘッダで実行される。

ヘッダが正しくない場合、プロセスは、エラー信号を生成するために前のステップ１４へ戻る。

さもなければ、すなわち、ヘッダが正しい場合、第１のステージＡは、続けて、診断命令を実行する傾向があるファイル中のマーカを検出する。

検出されたマーカが最後のマーカでない限り（ステップ１７）、検出されたマーカが解析されて、その性質が決定される（ステップ１８）。

特に、このステップ１８中、ユーザ技術者の側の行為の適用を引き起こすために使用されるコーディングマーカと、制御データまたは命令を回収する傾向がある第２のタイプのマーカとの間で識別が行なわれる。

このステップ１８中にマーカが第１のタイプのマーカであることが検出される場合には、ユーザ技術者によって行なわれるべき行為を記述するテキストタイプまたは画像タイプ（ステップ１９）の内容が中間ファイル９に挿入される。

一方、前のステップ１８中に、マーカが第２のタイプのマーカ、すなわち、制御データまたは命令を回収する傾向があるマーカであることが検出される場合には、次のステップ２０中に、このマーカが属するカテゴリーも検出される。

すなわち、診断機能を適用する傾向がある第３のタイプのマーカと、制御データ値を取得する傾向がある第４のタイプのマーカとの間で識別が行なわれる。

それが第３のタイプのマーカである場合には、次のステップ２１中に、制御マーカが濃縮ディスプレイ構造９のファイル内に挿入される。

一方、それが第４のタイプのマーカである場合には、次のステップ２２中に、一方ではリフレッシュされるべきデータの詳細がファイル１０内へ挿入され、他方では制御データをグラフィカルにリフレッシュできるようにするソフトウェアコンポーネント、例えば「Ａｃｔｉｖｅ Ｘ（登録商標）」タイプのコンポーネントが中間ファイル９に挿入される。

これらのステップの完了時、ファイルがもはやマーカを含んでいないと、第１のステージは、最終表示を生成するために第３のステージＣにより使用されるようになっている濃縮ディスプレイ構造と、濃縮ディスプレイ構造を動的に更新できるように第２のステージＢによって使用されるようになっているリフレッシュされるべきデータのリストとを生成する。

図４を参照すると、第２のステージＢは、第１のステップ２３中、ファイル１０、特にリフレッシュされるべきデータのリストを解析する。その後、第２のステージは、計算モジュールと通信するために使用されるべきパラメータを記述するデータＰと、計算モジュールで利用できるデータを記述するデータＤとから、計算モジュールへ送られるべき要求Ｒを構成する（ステップ２４）。

次のステップ２６中、正式に生成された要求が、一度に１つの要求として、車載計算モジュールへ伝えられる。

その後、コンピュータで利用できるデータを記述するデータＤを使用することにより、応答Ｒ’がデコードされ（ステップ２７）。その後、更新された制御データを用いて中間ファイルが更新される（ステップ２８）。

なお、第２のステージＢ内で適用される方法は、表示されるべきデータを動的にリフレッシュするために永久に行なわれ、また、これは、最良の想定し得る性能を伴って行なわれる。

ここで図５を参照すると、第３のステージＣは、使用されるＨＭＩのパラメータＰ’にしたがって、中間ファイル９をスクリーン８によってユーザに表示するようになっている最終表示へと変換することに関与する。

先に示したように、この第３のステージＣを第４のステージＤによって呼び出すことができる（要求Ｒ’’）。

第１のステップ３０中、第３のステージＣが中間ファイルをブラウズする。

パラメータＰ’から、このファイルが変換され（ステップ３１）、それにより、スクリーン８が駆動される。

最後に、図６を参照すると、第４のステージＤは、ディスプレイを再生する必要があるかどうかを第３のステージＣに知らせるために、ユーザの行為を監視する。なお、ユーザの行為は、診断ツールの動作形態に応じて、様々な種類を成すことができる。

すなわち、この監視ステージＤは、ユーザ技術者により手動で入力されるコマンドを、診断ツールを対象とするコンピュータ事象および直接的に或いは非直接的に第３のステージＣを対象とするコンピュータ事象へと変換する役目を担う。

特に、ユーザによって入力されるコマンドにしたがって、第４のステージＤは、ディスプレイの再生または置換を引き起こすことができ、特定の診断機能を起動させることができ、あるいは、例えば他の診断方法を使用したいという望みがある場合に第１のステージＡを再初期化することさえできる。

したがって、第１のステップ３３中、第４のステージＤは、ユーザによって入力されるコマンドを走査する。例えば特定の診断機能を適用する傾向がある或いは更には特に第１のステージＡを再起動させる傾向があるコマンドを反映してマーカが起動されると（ステップ３４）、診断ツール２内で使用される主要な診断アプリケーションが知らされる（ステップ３５）。そのような場合でないと、次のステップ３６中に、ユーザが表示の変更を望んだかどうかに関して決定が行なわれる。望む場合には、対応する要求Ｒ’’が第３のステージＣへ伝えられる。

Claims (11)

1. 診断ツール（２）を使用することによって、かつ、車両に搭載される計算モジュールの組から利用できる制御データまたは命令を解析して、車両の機能部材の組の動作を反映することにより、自動車の故障を診断する方法であって、
   − 制御データまたは命令で濃縮される車両で実行されるべき制御動作のシーケンスを記述する車両の動作を制御するための濃縮ディスプレイ構造（９）を生成するステップと、
   − リフレッシュされるべき制御データのリスト（１０）を生成するステップと、
   − それぞれの計算モジュールによってもたらされるリフレッシュされた制御データを動的に回収するステップと、
   − 濃縮ディスプレイ構造、リフレッシュされた制御データ、および、制御命令への直接的なアクセスから、最終表示（８）を生成するステップと、
   を含み、
   濃縮ディスプレイ構造を生成する前記ステップ、リフレッシュされるべきデータのリストを生成する前記ステップ、リフレッシュされたデータを回収する前記ステップ、および、最終表示を生成する前記ステップは、監視モジュール（Ｄ）の制御下で行なわれることを特徴とする方法。
2. リフレッシュされるべき制御データのリストの生成中、データ要求のリストを含む計算モジュールのためのベースから診断要求（Ｒ）が生成される請求項１に記載の方法。
3. 制御データの回収中、各計算モジュールによって伝えられる１つ以上の応答（Ｒ’）がデコードされる請求項１または請求項２に記載の方法。
4. 回収された制御データに基づいて、リフレッシュされた制御データファイルが更新される請求項３に記載の方法。
5. 最終表示（８）は、濃縮ディスプレイ構造から、リフレッシュされた制御データファイルから、および、最終表示が視認されるヒューマン／マシンインタフェースに対応するディスプレイデータベースより抽出される表示パラメータ（Ｐ’）から生成される請求項４に記載の方法。
6. 濃縮ディスプレイ構造の生成中、および、リフレッシュされるべき制御データのリストの生成中に、診断ツールのための診断命令コードの組と診断命令コードを適用するためのマーカの組とを含む診断ファイルが解析され、前記マーカが検出されるとともに、オペレータの側の行為を適用する傾向がある第１のタイプのマーカと制御データまたは制御命令を回収する傾向がある第２のタイプのマーカとの間を識別するために前記マーカが解析される請求項１から請求項５のいずれか１項に記載の方法。
7. 第１のタイプのマーカが検出されると、テキストデータまたは画像が濃縮ディスプレイ構造中に挿入される請求項６に記載の方法。
8. 第２のタイプのマーカが検出されると、マーカは、診断機能を制御する傾向がある第３のタイプのマーカと計算データ値を取得する傾向がある第４のタイプのマーカとの間で識別される請求項７に記載の方法。
9. 第３のタイプのマーカの検出に応じて、制御を起動させることができるようにするために制御マーカが濃縮ディスプレイ構造中（９）に挿入される請求項８に記載の方法。
10. 第４のタイプのマーカの検出に応じて、制御データの読み取りを制御するためのソフトウェアコンポーネントが、リフレッシュされるべきデータを含むファイル（１０）中に挿入される請求項９に記載の方法。
11. 自動車の故障を診断するためのシステムであって、
    − 車両の動作を制御するための濃縮ディスプレイ構造を生成するとともに、リフレッシュされるべき制御データのリスト（１０）を生成するための第１のステージ（Ａ）と、
    − 車両に搭載される計算モジュールによりもたらされるリフレッシュされた制御データを回収する第２のステージと、
    − 濃縮ディスプレイ構造とリフレッシュされた制御データとから、最終表示（８）を生成する第３のステージと、
    を備え、
    第１、第２、および、第３のステージと、ユーザ技術者の行為とを制御するための１つ以上の監視ステージ（Ｄ）を更に含むことを特徴とするシステム。

Images