JP2008511821A - 自動車の制御装置のための改良されたチェック方法 - Google Patents

Abstract

本発明は、診断プログラムを用いて、自動車に搭載される制御装置とデータラインや診断インターフェースを介して情報を交換することができるコンピュータベースの診断テストに関する。自動車側の制御装置には、オンボードでの診断のためのプログラムルーチンが搭載され、識別可能なエラーがエラーコードの形で所定のメモリ領域に格納される。診断テスターに記憶された診断プログラムは、そのメモリ領域のエラーコードを読み出し、エラーコードを解釈して、その内容とともにエラーコードを表示部に表示する。実施した修理がどの程度うまく行ったかを確かめるために、診断プログラムを用いてステータスチェックが順次実施される。上記ステータスチェックでは、システムで判明した上記エラーコードのステータス情報について質疑応答が行われる。このプロセスにおいて、エラー発生条件を満たしたテストが行われている、又は上記テストを実施するためにテスト条件が満たされていないことを示す全てのエラーコードが表示される。上記診断テストによって、修理検証を改良するための方法を実施することもできる。

Description

本発明は、これまで一般的であったような故障を見つけるためだけのものではなく、実施された修理が成功したかどうかをも同様にチェックできる、自動車の制御装置をチェックするための診断システム及び診断テスターに関する。さらに、この診断テスターは、修理に関する改良されたチェックを実現するための方法を提供するためにも使用される。

近年、自動車修理工場では、自動車の制御装置を対象とした診断システム及び診断テスターは、コンピュータによるものが主流になっている。コンピュータによる診断テスターの導入において独国ＢＭＷ社は先導的な役割を果たし、１９９４年に診断システムＢＭＷ−ＤＩＳを導入した。これが自動車修理工場における最近の診断システム及び診断テスターの標準となっている。このシステムについては、例えば非特許文献１に記載されている。これに続く診断テスターも、この診断システムの基本構造にたびたび頼ってきた。例えば、ここで一例として示すボッシュ（Ｂｏｓｃｈ）による特許文献１もそうであり、この基本構造が特に簡潔及び簡略な方法で要約されている。プログラム可能な制御装置に自己診断手段が提供され、故障コードを生成及び格納するとともに、自動車に搭載された診断／テストプラグを介して前記手段を外部の診断テスターに接続することができる自動車用の診断テスト装置が記載されている。なお、前記手段では、プログラム制御によって自動車のエンジンコントローラや他のシステムを制御及び監視する。本発明でも、診断テスターに関してこのような基本構造をベースにしている。

自動車に搭載された制御装置に外部の診断テスターを接続するためのインターフェース又は診断プラグは公知の技術であるが、現在もなお標準化に向けた取り組みの余地が多少残されている。特に、米国においては、自動車に搭載された制御装置に対するアクセス（つまり、このような制御装置で診断を実施できるようにすること）を可能にするとともに、それを規制する上でのこのような標準化に向けた取り組みでは、更に立法側による対策も関わる。こうして確立された規格は、キーワードプロトコル２０００と呼ばれている。このキーワードプロトコル２０００の標準化のベースは、アプリケーション層に関連する国際規格ＩＳＯ １４ ２３０−３、及びデータリンク層と呼ばれるものに関連するＩＳＯ １４ ２３０−２に見出すことができる。キーワードプロトコル２０００のベースであり、前述した規格の１つのコンポーネントとなっている補助規格は、車両整備の規格であるＳＡＥ Ｊ１９７９である。ここに記載する本発明にとっては、特に、キーワードプロトコル２０００によって診断テスターに提供される、制御装置内のデータメモリを読み出す可能性が重要である。

公知の診断システム及び診断テスターは、自動車の制御装置から既存の故障コードを読み出し、診断プログラムを使ってこれを処理及び解釈して、この解釈結果を診断テスターの画面上に表示することに限られている。こうして表示された不具合のリストを見ながら、自動車修理工場では自動車の整備工が作業を進める。このプロセスにおいて、個々に指定した不具合に関する詳細情報を診断テスターを使用して呼び出すことができる。こうした状況から、自動車の整備工にとっては、検出された故障を解消する上で使用する、修理指示書は勿論、図面などの更なる技術情報リソースが特に重要になる。自動車の整備工は不具合のリストを見ながら作業する場合、診断テスターを使用して、自動車に搭載された制御装置及び診断テスター自体に格納及び読み出された故障コードを消去する。実施した修理がうまくいったかどうか、又は修理を実施したことで間接的な故障が発生していないかどうかに関する最終的なチェックは、自動車修理工場の作業組織ごとに、最終的な試乗によって実施される。特許出願人に知られている診断システム及び診断テスターでは、実施された修理の品質チェックはサポートされない。また、制御装置内の不具合のリスト及び故障コードは消去コマンドによって自動車の整備工が消去するため、このような診断システム及び診断テスターは修理の品質チェックに適してもいない。言うまでもなく、この結果、それ以前に発生し、検出された不具合に関する情報は失われることになる。このため、今までは、修理がうまくいったかどうかについて、診断テスターで何らかのサポートが自動車の整備工に提供されることはなかった。

こうしたことから、前述した従来技術を出発点として、本発明の目的は、診断テスターを使用した修理に関して、改良されたチェックを可能にする診断システム及び診断テスターを提供することである。

独国特許出願公開第１９９ ２１ ８４５ Ａ１号明細書 職業訓練マニュル：Ｒａｕｎｅｒ／Ｓｃｈｒｅｉｅｒ／Ｓｐｏｔｔｅｌ著「Ｄｉｅ Ｚｕｋｕｎｆｔ ｃｏｍｐｕｔｅｒｇｅｓｔｕｔｚｔｅｒ Ｋｆｚ−Ｄｉａｇｎｏｓｅ［Ｔｈｅ ｆｕｔｕｒｅ ｏｆ ｃｏｍｐｕｔｅｒ−ｓｕｐｐｏｒｔｅｄ ｍｏｔｏｒ ｖｅｈｉｃｌｅ ｄｉａｇｎｏｓｔｉｃｓ］」ビーレフェルトのベルテルスマン社発行、２００２年、ＩＳＢＮ ３−７６３９−３０２２−１

本発明の目的は、独立請求項に対応する診断システム及び診断テスターによって達成される。本発明の有利な実施形態については従属請求項に示すか、又は下記の説明の中で明らかにされる。

本願発明は、診断プログラムを使用し、診断インターフェース及びデータラインを介して、自動車に搭載された制御装置との間で情報を交換可能なコンピュータベースの診断テスターによって課題を解決する。自動車に搭載された制御装置は、制御装置を自己診断するためのプログラムルーチンを有し、識別された故障を確保されたメモリ領域に故障コードという形で記憶しておくことができる。診断テスター上で実行された診断プログラムは、確保されているメモリ領域から故障コードを読み出し、コードの内容を解釈して、その結果とともに故障コードを表示部上に表示する。実施された修理がどの程度まで正常に完了したかをチェックするために、診断テスター上で実行された診断プログラムを使用してステータスポーリングが実施される。このステータスポーリング時に、システム内で判明している全ての故障コードのステータス情報が問い合わされ、評価される。このプロセスで、故障の発生する条件で確実にテストされている全ての故障コード、又は再現テストを実施できるテスト要件を満たせなかった全ての故障コードが表示される。

ステータスポーリングは、主として、これまでに故障の発生する条件で確実にテストされている故障だけでなく、必要とされるテスト条件が満たされないために機能をチェックできない潜在的な故障についても、故障コードという形で診断テスターに表示されるという利点を有する。自動車修理工場の修理整備工を支援するため、識別された全ての故障、更に潜在的な全ての故障がテスト条件に従ってテストされ、テスト結果に故障の兆候が現れなくなるまで、不具合のリストがある間は、ステータスポーリングによって、診断テスターに表示が返される。修理対策が実施されている場合について、これは、その修理対策に必要とされるテスト条件が診断テスターで少なくとも一度は処理され、チェック対象の対策に関して不具合が存在しなくなったことが明らかになるまでは、修理対策が完了しないということを意味する。

本発明の有利な一実施形態では、診断テスターを使って故障コードを消去することと、故障コードを消去するためには少なくとも更に１回は診断を実行するということが結び付けられ、この診断の実行時に各々の故障コードをチェックするために必要とされるテスト条件が満たされ、テスト結果に故障がなくなったことが示される。これには、診断が終了した故障であっても、実施されたであろう修理が診断テスターで少なくとも一度は監視及びチェックされ、良好であることが判明するまでは、修理整備工が消去することができないという利点がある。したがって、正しく実施されなかった修理対策を、診断テスターを使用して、修理直後に識別できる。適切なチェックに必要とされるテスト条件が存在しないため、良好であるとされているだけの潜在的な故障の可能性についても、所定のステータスポーリングによって識別されることは更に重要である。これは、制御装置を完全に交換することで修理を行う場合に特に重要である。これまで知られている従来技術によれば、故障メモリに故障コードが格納されていないという理由だけで、各診断テスターでは新たに取り付けられた制御装置が良好であるとしている。これに対して、本発明によれば、制御装置に適用されるテスト条件に従い診断テスターを使って制御装置が少なくとも一度はテストされ、このプロセスで故障が見つからなくなるまでは、修理対策は完了したとみなされない。ここで記載するような診断テスターのメニュープロンプト又は画面表示によって、テストが済んでいない故障の可能性を修理整備工に知らせるとともに、そのプロセスにおいて、実施した修理対策を少なくとも一度は良好な方法でチェックするよう整備工に促す助けになる。ここで、判明している各故障コードに必要とされるテスト条件が、診断テスターの診断プログラムに適切に実現され、これによって、自動車で起こりうる各々の故障について規定のテスト条件を修理整備工が記憶しておく必要はない。

本発明の有利な一実施形態では、自動車の整備工によって診断テスターを使用してステータスチェックが開始される。このために、診断テスターのメニュープロンプティング時に、ステータスポーリングのために確保され、起動時に診断テスターによって表示された故障のステータスチェックが行われるメニュー項目を提供することができる。これは、自動車の整備工が修理のすぐ近くで診断テスターを使用でき、修理対策が完了したと思えば、その場で診断テスターを使ってこの修理対策をチェックできるという利点を有する。

本発明の他の実施形態では、診断テスターによって示された不具合を消去する場合、診断テスターのステータスチェックを自動的に開始することができる。この場合、ステータスポーリングの開始が、制御装置において故障コードをリセットするための削除機能の呼び出しと結び付けられる。

本発明の他の実施形態では、診断テスターによってステータスチェックを自動的に開始でき、例えば診断テスターが自動車の診断インターフェースに接続された後等、定期的に診断テスターによって故障コードのステータスチェックが起動及び実施される。この目的では、例えば１０分おきに自動的にトリガーする等、並行してクロックを動作させ、ステータスチェックを実施できる。

更なる一実施形態では、診断テスターにおいて、更なる診断ルーチンによってステータスチェックが実施され、各々の修理に対して規定されているテスト条件を参照して、実施した修理対策が故障なく機能するとともに、修理対策について正しいチェックが行われるまで、診断ルーチン時に自動車の制御装置の故障メモリ内に書き込まれた故障コードを消去するための機能はブロックされる。この実施形態は、自動車の整備工にとって、故障が全て取り除かれるとともに、十分にチェックされるまでは修理が完了しないという利益をもたらす。一度検出された故障コードを、個別の故障消去や全ての故障メモリの全リセットといった消去コマンドによってランダムに消去しても、良好な修理点検が行われたと誤認することはない。

以下に、本発明について、その全体像を制限することなく、図表を使用してより詳細に説明する。

図１は、自動車修理工場で今日知られている状況の略図である。自動車の診断については、標準化された診断インターフェース２を介して、自動車の制御装置４の通信ネットワーク３にコンピュータ支援による診断テスター１が接続される。公知の診断テスターは、例えば独国ダイムラークライスラー（ＤａｉｍｌｅｒＣｈｒｙｓｌｅｒ）社のＤＡＳシステム、又は本明細書の冒頭で前述したＢＭＷ−ＤＩＳシステムである。自動車に取り付けられた制御装置４は、例えばデータバスを介して、相互に通信接続する。ここで、自動車で一般に普及しているデータバスは、ＣＡＮ（Ｃｏｎｔｒｏｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）バスと呼ばれるものである。自動車に取り付けられた各々の制御装置が、通信インターフェースと自己診断機能の両方を有する。制御装置の自己診断の範囲内で、診断ルーチンを使用して制御装置で検出された故障は、制御装置のソフトウェアによって、故障コードと呼ばれるコード化された形で故障メモリと呼ばれる特別に確保されたメモリ領域内に書き込まれる。図１の略図では、このように確保されている不揮発性のメモリ領域はＦＭ（故障メモリFault Memory）によって示される。診断テスターと自動車に取り付けられた制御装置の間の通信及びデータ交換については、規格が確立されている。この規格はキーワードプロトコル２０００という名前で知られ、その仕様及び標定はＩＳＯ規格１４ ２３０−３に再現されている。本発明を理解するのに必要とされる範囲で、図２を参照しながら、このキーワードプロトコル２０００に関する詳細についても下記に示す。キーワードプロトコル２０００で同意された制御コマンド及びデータフォーマットによって、診断テスターを使用して診断インターフェースを介し個々の制御装置の故障メモリのコード化された内容を読み出し、それを診断テスターのコンピューティングシステムに送信することができる。ここで、キーワードプロトコル２０００の規格は、２つの異なるアプリケーションの可能性を有する。この規格によって、診断テスターと制御装置の間の通信をゲートウェイ５を介して行い、例えばゲートウェイで自動車のＣＡＮバスを診断インターフェース２に接続するようにするか、さもなければこれまで通例であったように、Ｋライン及びＬラインと呼ばれるもの、及び標準化された診断インターフェース２を介して制御装置の故障メモリを診断テスターに直接読み出し、記憶することができる。図１の略図では、ＣＡＮバス、つまりゲートウェイを介した最近のアクセス形態が示される。本発明にとって重要なことは、診断テスターを使用して、制御装置の故障メモリを読み出すための方法が少なくとも１つあればいいということである。このため、本発明では、診断テスターと制御装置の故障メモリとの間のアドレッシングの可能性全てが対象になる。また、使用するキーワードプロトコル２０００は、制御装置から診断テスターに故障メモリのデータ内容を特に簡単に転送するための１つの好ましい方法に過ぎない。

図２にて、キーワードプロトコル２０００の基本構成を簡単に示す。より詳細で完全な情報は、当業者であれば、前述したＩＳＯ規格１４ ２３０−３の中に見つけることができる。キーワードプロトコル２０００では、特に自動車の診断を目的として、キーワードプロトコル２０００に対応する場合に自動車において制御装置が少なくとも処理できなければならないデータフォーマット及び最低限のコード化された制御コマンドが規定されている。キーワードプロトコルで使用されるデータフォーマットはＩＳＯ規格１４ ２３０−２をベースとし、これはキーワードプロトコル２０００のデータリンク層と呼ばれる。このようなデータフォーマットの構造では、データフォーマットに関する情報ＦＭＴ、ターゲットアドレスに関する情報Ｔｇｔ、送信元アドレスに関する情報Ｓｒｃ、及びヘッダーバイトに続くデータバイトの長さに関する情報Ｌｅｎの最大４つの異なるヘッダーバイトが含まれる。ヘッダーバイトの後には、必ず、サービス識別子ＳＩＤと呼ばれる１６進コードの制御コマンドが続く。ここで、キーワードプロトコル２０００で指定されている制御コマンドは、製造業者固有の方法で更に細分化及び改良が可能である。したがって、有効データブロック７には、更に１６進コードの制御コマンドが取り込まれる。キーワードプロトコル２０００に対応するデータフォーマットは、常に、各々のメッセージフォーマットの全データに渡ってチェックサムＣＳが含まれるバイトで終わる。上記のメッセージフォーマットは、基本構造においては、制御装置に対する照会と制御装置の応答両方に使用される。ここで、キーワードプロトコル２０００対応の各システムに含まれ、各々のシステムで処理できなければならない＄１８要求とそれに対応する＄５８応答と呼ばれるものが、本発明にとって特に重要である。ここで、サービス識別子を決定するため、つまり転送対象となる、応答に含まれなければならない有効データを決定するために、１６進コード“１８”又は“５８”を使用して要求と応答をコード化したに過ぎない。ここで、本特許出願では、数値コード１８又は５８がキーワードプロトコル２０００に対応するコード化された制御コマンドであることを示すためにドル記号を使用したに過ぎない。制御装置は自動車において診断テスターから＄１８要求を受け取った場合、必ず＄５８応答を返す。ここで、応答の有効データは、必ず、応答メッセージのデータブロック７に含まれる。ここで、キーワードプロトコル２０００は、制御コマンドを定義するだけでなく、標準化された問い合わせに対する標準化された応答に取り込まなければならないデータ内容も指定する。例えば、＄１８要求に対応する＄５８応答のデータブロックでは、制御装置で判明している故障コードＤＴＣ１、ＤＴＣ２〜ＤＴＣｎ各々の他、その故障コードの各ステータスも転送されるよう定義されている。ここで、故障コードのステータスは、制御装置の自己診断ルーチンがその故障コードをテストしたかどうかを示す。最も単純なケースでは、ステータスを１つのビットで構成することができる。例えば、ビット値「０」はテスト条件に従い故障コードに割り当てられた機能のチェックが正常終了した状態を表し、ビット値「１」は故障コードがテストされていない状態又はテスト条件が存在しないままに該当する機能を試運転した状態を表す。当然ながら、故障コードのベースとなる機能に求められるテスト条件に従い故障コードのステータスがテストされているかどうかを判断できれば、これ以外のコード化手段を選択してもかまわない。このため、＄５８応答のデータブロック７には、制御装置で判明している全ての故障コードと追加ステータス情報のテーブルが含まれる。このようにして、＄１８要求を使用し、要求自体に該当するパラメータを設定するか、又は対応する＄５８応答のデータブロックのそれ以降の選択によって、該当する機能がその機能に求められるテスト条件に従って十分にテストされていないことを示すステータスを持つ全ての故障コードを識別し、これを選択的に読み出すことができる。異常が存在するかどうかといったこと、又は故障コードが検証され、対応する故障メモリに故障コードが記憶されているかどうかといったこととは全く関係なく、この情報を取得できる。言い換えると、異常のある状態でない故障コードについてもステータスを問い合わせることができる。キーワードプロトコル２０００は、本発明に関連して特に広く行き渡った１つの変形実施形態とみなすべきである。本発明自体はキーワードプロトコル２０００に限られることはなく、異常のある状態の故障コードだけでなくそのステータス情報も読み出し、選択することができるあらゆるタイプ又はあらゆる形態のデータ転送で実現できる。

上記した原理に従い、図３〜図６に関する本発明の核心について以下に詳述する。図３は、修理の改良されたチェックを可能にするフローチャートである。診断テスターを自動車の診断インターフェースに接続すれば、診断テスターに格納された診断プログラムを起動して診断セッションを開始できる。このために、第１のステップ３１０で、自動車の制御装置の故障メモリのデータ内容が読み出される。ここで、制御装置の自己診断ルーチンによって検証され、異常を示す状態の故障コード全てが読み出される。ただし、これまでに知られている従来技術と異なり、本発明によれば、異常を示す故障コードが読み出されるだけでなく、システムで判明している全ての故障コードについて、然るべき問い合わせでステータス情報が読み出される。このようにして読み出されたデータは、診断テスターで更に処理される。適切な選択が行われた後、異常を示す全ての故障コードが、該当する場合には更なる説明と一緒に、診断テスターの然るべき表示部に表示される。ここで、本発明によれば、異常を示す故障コードのリストに加えて、ステータスの問い合わせで制御装置の自己診断ルーチンによってテストされていないことが示されている故障コードも補足される。このため、異常ではないものの、チェックされていないために故障候補となりうる故障コードも表示される。診断プログラムでは、故障コードの選択及び表示を１つの処理ステップにまとめることが可能である。これについては、図３のプログラムステップ３２０に示す。表示された故障リストを見ながら、自動車の整備工は修理を実施するかどうかを決定する。この決定の結果は、決定ステップ３３０で、診断テスターのメニュープロンプトで問い合わせることができる。ただし、別の実施形態として、診断テスターのメニュープロンプトでこの決定ステップを省略することができる。しかし、どちらの場合でも、修理（ステップ３４０）が実施されたときには、識別された故障コードを各々の制御装置の各々の故障メモリで消去する必要がある。これまで知られている診断テスターでは、自動車の制御装置の故障メモリ内にある故障コードは全ていつでも消去することができ、更にチェックすることはできなかった。本発明では、故障コードが消去された後、又は診断テスターによって及び制御装置の自己診断ルーチンによって故障コードの消去が試行された後で修理のチェックが行われる。修理に関するこのチェックは、故障コードの消去が試みられた後で、制御装置の自己診断ルーチンが再度開始されることにより実行される。処理ステップ３１０及び３２０が再度実施される。異常状態を示す故障コードと、ステータス「未テスト」を有する故障コードのどちらも診断テスターに表示されなくなった場合に、修理は正常終了となる。このプログラムループによって、実施された修理対策が少なくとも一度は必ずテストされることになる。例えば診断を実行するために必要となるテスト条件が満たされていないためにテストを正常に実施することができなかった場合、こうして失敗したチェックは、ステータス「未テスト」を有する故障コードの問い合わせで検出されて、診断テスターの表示部に表示され、自動車の整備工に提供される。この場合、修理はチェックされず、チェックに必要とされるテスト条件が満たされていない旨が自動車の整備工に通知される。

本発明による更なる例示の実施形態について、図４のプログラムフローチャートで示す。この場合も、自動車の診断インターフェースに診断テスターが接続されると、前記診断テスターを使用して、自動車に取り付けられた制御装置の自己診断ルーチンが開始されるか、又は少なくとも制御装置の故障メモリに記憶されている故障コードが読み出される。検証され、異常を示す状態の故障コードだけでなく、故障コードに関連するステータス情報が読み出され、更に処理される。最後に、異常状態を示す全ての故障コード、及びステータス「未テスト」を有する全ての故障コードが診断テスターの表示部に表示される。ここで、処理ステップ４１０及び４２０は、図３のフローチャートによれば、処理ステップ３１０及び３２０に合致する。図４の例示的な実施形態では、修理を実施したいかどうかに関する自動車の修理工による決定を、メニュー問い合わせ（ステップ４３０）によって表示することも、表示を省略することも可能である。自動車の修理工が修理を実施すると決定した場合、図４のフローチャートに基づく修理のチェックのための例示的な実施形態に従い、各修理ステップを実施したら、その都度個別の故障チェックを開始できる（ステップ４５０）。個別の故障チェックは、診断テスターで４つの異なる故障コードが表示される場合に特に適切となる。このような場合、自動車の整備工はまずプルダウンメニューによって故障コードを選択し、関連する修理指示書を呼び出して、診断テスターに表示させた後、修理（ステップ４４０）を実施し、修理が完了した時点で、実際に個別の故障チェックを開始（ステップ４５０）することができる。個別の故障チェックを開始すると、選択した故障コードについて、診断テスターを使用して、修理チェックプロセスが実施される。修理チェックプロセスでは、各々の制御装置の自己診断ルーチンが開始され、修理したばかりの故障コードのステータスチェックが実施される。問い合わせた故障コードが制御装置の自己診断ルーチンで十分チェックされ、この故障コードが異常を示さなくなったことがこのチェックで判明した場合は、個別の故障消去プロセスによって、診断テスターの故障リストから各々の故障コードが削除される。自動車の整備工にとって、これは、修理リストを見ながら一箇所ずつ選択して、その不具合箇所を解消できたと思ったら、その場で診断テスターを使用し個別の故障チェックプロセスによりチェックすることができるという利点を有する。ここで、診断テスターの故障リストから各々の個別の故障が表示されなくなった場合に、その部分の修理は正常に行われたものとみなされる。

これらのプロセスは、図４のフローチャートのプログラムステップ４６０で示される。当然ながら、自動車の整備工は、個別の故障消去プロセスの代わりに、表示された全ての修理をまず実施し、その後それまでに問い合わせた全ての故障コードを対象として診断テスターを使用し修理チェックプロセスを実施することもできる。これは、図３のフローチャートに対応する。どちらの手順を選択するかどうかについては、自動車の整備工が自由に決定できる。本発明による診断テスターでは、修理のチェックのためのどちらの図表でも実行することができる。

図５及び図６に、診断テスターを使用して修理の改良されたチェックをどのように実行できるかを示す。診断テスターの表示部の代表的なスクリーンショットが示される。表示されているデータ内容９に関して確認済みの自動車８の関連情報に加えて、診断テスターを制御及び操作するためのオペレータ制御要素が、アイコン１０と呼ばれるものの形で診断テスターのユーザインターフェース上に表示され、診断整備工に提供される。本発明の要点は、異常のある状態の故障コードだけでなく、更に自動車の制御装置内にある診断テスターで見つけることができる未テスト状態の故障コードを全て表示することである。図示した例では、故障コード１０００、１００１、及び１００２がこれに当たる。本発明によれば、また、各故障コードについてステータス情報の問い合わせが行われ、診断テスターの表示部に表示される。例えば、表示形式は「ステータス」という名前の付いた列１１のようにすることができる。この列には、テスト終了後又はテスト終了前に各故障コードの対応するステータス情報が格納される。ただし、図５の表示部において「カレント（Aktuell）」として示されている異常のある状態の故障コードだけが表示されるのではなく、「未テスト」ステータスを有する故障コードも表示される。図５の例示的な実施形態では、故障コード１００３がこれに当たる。図５によるスクリーンショットは、診断テスターが診断インターフェースと接続された後、データ送信後、及びデータ選択後に、診断テスターに表示され、自動車の整備工に提供される表示部を例示したものである。自動車の整備工は、例えばプルダウンメニュー等、メニュープロンプトによって、オペレータ制御アイコン１０を使用して、個々の故障コードに関連する詳細情報を呼び出すことができる。例えば、各々の故障コードに関連し、更に通常診断テスターの診断プログラムに組み込まれ、記憶されている修理指示書が特に重要になる。自動車の修理工は、オペレータ制御アイコン１０の例えばＦ３を使用して特定の故障コードについて上記した個々の故障チェックを開始することも、全修理が実施された後でオペレータ制御アイコン１０の例えばＦ７を使用して修理をチェックすることもできる。

このようにして実施された修理のチェックについて考えられる結果が、図６のスクリーンショットを使用して示される。図５に従い一例として選択されている例示的な実施形態では、故障コード１０００、１００１、１００２、１００３に関連する修理が全て実施されている。ただし、続いて開始された修理のチェックにより、この４つの故障コードのうち２つについて、各々の制御装置の自己診断ルーチンを使用して各々の機能の良好な動作をテストするために必要なテスト条件が満たされていないことが示されている。こうした理由で、この旨が自動車の整備工に表示される。あらかじめ不具合が判明している故障コードの中で、修理を実施した後にどの故障コードをテストできなかったことが整備工に示される。また、特に便宜上、規定されているテスト条件が、故障コードごとに、診断テスターのデータベースシステムに格納されている。便宜上、このようなテスト条件を呼び出すために、個々の情報アイコン１２が設けられている。これらのアイコンを選択すると、選択した故障コード（例えば、故障コード１０００）について、追加情報をメニュー選択によって呼び出すことができる。このような追加情報には、テスト条件だけでなく、どのテスト条件が満たされなかったかといった情報も含まれ得る。図示されている例示的な実施形態では、車載発電機が必要最低回転速度に達していないため、未テスト状態の電力センサの故障コード１０００、１００１はテストすることができない。そして、チェックを正常に終了するためには、自動車のエンジンの回転速度を、少なくとも例えば毎分２０００回転まで上げなければならないというメッセージが自動車の整備工に提供される。

診断テスターに故障コードが表示されなくなるまでは、修理のチェックが正常終了となることはない。

自動車の制御装置に接続される診断テスターの略図である。 キーワードプロトコル２０００に合致するデータフォーマットの略図である。 診断テスターを使用した修理の改良されたチェックを示すフローチャートである。 診断テスターを使用した修理の改良されたチェックのための別の実施形態を示すフローチャートである。 診断テスターによって自動車の整備工に表示されるグラフィックユーザインターフェースを示す図である。 図５に基づき、修理自体は実施したものの、修理を十分にチェックしなかった場合に自動車の整備工に表示される、診断テスターのグラフィックユーザインターフェースを示す図である。

Claims (16)

1. 診断プログラムと、診断を実施する制御装置に接続するための診断インターフェースを有するコンピュータベースの診断テスターにおいて、
   故障コード及び故障コードに関連するステータス情報が、前記診断プログラムを使用して、制御装置から読み出されて評価され、
   故障設定条件が満たされている全ての故障コード、及び、そのステータス情報が各々の故障コードがチェックされていないことを示す全ての前記故障コードを、診断テスター上に表示することを特徴とする診断テスター。
2. 前記制御装置で消去する故障コードに対して診断が正常に実行されていることがステータスチェックで示されている場合に、前記診断テスターの表示部から故障コードが削除されることを特徴とする請求項１に記載の診断テスター。
3. 修理時に選択可能な故障コードの前記ステータス情報を問い合わせできることを特徴とする請求項１あるいは２に記載の診断テスター。
4. 前記診断テスターの表示部から故障コードが消去されると、前記ステータスチェックが実施されることを特徴とする請求項１あるいは２に記載の診断テスター。
5. 前記ステータスチェックが指定時刻に実行されることを特徴とする請求項１あるいは２に記載の診断テスター。
6. 前記制御装置のステータス情報が未テスト状態を示す故障コードについて、前記診断テスターの表示部からの故障コードの削除がブロックされることを特徴とする請求項１あるいは２に記載の診断テスター。
7. 自動車の制御装置が誤動作が発生した場合に故障メモリに故障コードを記憶するための自己診断ルーチンを有し、前記故障メモリは診断インターフェースを介し外部の診断テスターに接続でき、前記診断テスターには診断プログラムが格納されている診断システムにおいて、
   故障コード及び故障コードに関連するステータス情報が、前記診断プログラムを使用して、前記制御装置メモリから読み出されて評価され、
   故障設定条件が満たされている全ての故障コード、及び、そのステータス情報が各々の故障コードがチェックされていないことを示す全ての前記故障コードを、前記診断テスター上に表示することを特徴とする診断システム。
8. 前記制御装置で消去する故障コードに対して診断が正常に実行されていることがステータスチェックで示されている場合に、前記診断テスターの表示部上で故障コードが削除されることを特徴とする請求項７に記載の診断システム。
9. 修理時に選択可能な故障コードの前記ステータス情報を問い合わせできることを特徴とする請求項７あるいは８に記載の診断システム。
10. 前記診断テスターの表示部から故障コードが消去されると、前記ステータスチェックが実施されることを特徴とする請求項７あるいは８に記載の診断システム。
11. 前記ステータスチェックが指定時刻に実行されることを特徴とする請求項７あるいは８に記載の診断システム。
12. 前記制御装置のステータス情報が未テスト状態を示す故障コードについて、前記診断テスターの表示部からの故障コードの削除がブロックされることを特徴とする請求項７あるいは８に記載の診断システム。
13. 制御装置の自己診断ルーチンを使用して故障コードが判別され、少なくとも１つの一次故障メモリ（Ａ）に前記故障コードが記憶される、修理の改良されたチェックのための方法であって、
    判別された前記故障コードが前記診断テスターの表示部上に表示され、判別された前記故障コードによって少なくとも部分的な修理が行われ、
    更なるメソッドステップで、更なる診断実行を開始することによって、前記診断テスターを使用して、実施された前記修理対策がチェックされ、判別された前記故障コードのステータスがステータスポーリングによってチェックされることを特徴とする方法。
14. 前記判別された故障コードのうち、ステータスチェックで「未テスト」状態を示す故障コードが引き続き表示されることを特徴とする請求項１３に記載の方法。
15. 部分的な各修理後、個別の故障チェックによって修理のチェックが実施されることを特徴とする請求項１３あるいは１４に記載の方法。
16. 前記修理の終了時に修理のチェックが実施されることを特徴とする請求項１３あるいは１４に記載の方法。

Images