JP2008179314A - 車両診断システム - Google Patents

Abstract

【課題】車載電子制御ユニットの記憶容量を増加させることなく、診断の完了に必要な車両操作の指示を行うことのできる車両診断システムを提供する。
【解決手段】整備者が診断用端末２１を用いて、ＥＣＵ３１の実行する車両３０の自己診断結果を要求すると、管理サーバ１０はリモート管理センタＣに車種別診断方法データベース１１からその診断の完了に必要な車両操作の指示テキストを取得して、診断用端末２１に表示させる。整備者は、その診断用端末２１に表示された指示テキストに従って車両３０の操作を行うことで、診断結果を要求した自己診断を完了させることができるようになる。
【選択図】図１

Description

本発明は、車両に接続された診断用端末を用いて車両の診断を行う車両診断システムに関するものである。

車両には、自己診断機能が備えられており、車両に設置された各種センサの検出結果をもとに車両各部の異常の有無が車両動作中、あるいは停止中に自動的にチェックされるようになっている。そして整備工場では、修理・交換した部品の動作機能の確認のため、車両自体の具備する自己診断機能を利用した診断作業が行われている。こうした車両の診断作業は、診断用端末（チェッカー）を車両に接続して行われる。車両への診断用端末の接続は、詳しくは、車載電子制御ユニットのコネクタに診断用端末のハーネスを装着することで行われる。整備者が診断用端末を操作して修理・交換した部品の診断結果を要求すると、その部品の診断結果が車載電子制御ユニットから読み込まれて診断用端末の画面に表示される。

このとき、その部品についての自己診断が未完了で、車載電子制御ユニットに診断結果が記録されていない場合には、整備者は整備マニュアルを参照して必要な車両操作を行い、その診断の実行条件を成立させてから、再び診断結果を要求することになる。整備マニュアルは、車両メーカから書籍として提供されるもので、自己診断の各項目についてその実行条件、及びその実行条件を成立するために必要な車両の操作手順が記載されている。ただし、こうした整備マニュアルを参照しての作業は、整備者にとって煩わしいものとなっている。

そこで従来、整備者の診断作業をより容易とするための技術として、特許文献１に記載のものが提案されている。この技術は、蒸発燃料処理装置のリーク診断や排気浄化装置の浄化性能診断に係る整備者の診断作業を容易とするものとなっている。

これらの診断は、予め規定された診断用走行パターンで車両が走行されたときの車載センサの検出結果に基づいて正常／異常の判定を行うものとなっている。診断用走行パターンは、車速と時間とによって規定されており、車載電子制御ユニットに予め記憶されている。車載電子制御ユニットは、その記憶された診断用走行パターンと実際の車両の走行パターンとを比較し、両者が一致していれば、上記判定を行ってその結果を記録する。そのため、診断時に整備者が上記診断を行わせようとする場合には、規定の診断用走行パターン通りに車両を実際に走行させる必要がある。

上記従来の技術では、診断用端末が車載電子制御ユニットから診断用走行パターンのデータを読み出すとともに、現状の車両の走行パターンを受信する。そして診断用端末はその画面に、受診した診断用走行パターンのデータに従って走行指示を順次出力するとともに、診断用走行パターンに沿って車両が走行されているか否かを判定して、従っていなければ、復旧指示を出力するようにしている。そのため、整備者は、診断用端末の画面に表示された指示に従って車両を走行すれば、診断用走行パターンに沿って車両を走行させることができ、上記診断をより容易に完了させることができる。
特開２０００−３３９０１８号公報

このように上記従来技術では、車載電子制御ユニットから読み出したデータをもとに、診断を完了するために必要な、すなわち診断の実行条件を満たすために必要な車両操作の指示を行うようにしている。ただしこれが可能なのは、上記蒸発燃料処理装置のリーク診断や排気浄化装置の浄化性能診断では、車速という、直接操作可能な制御パラメータのみでその実行条件が規定されており、診断の実行条件の情報がそのまま、その成立に必要な車両の操作手順を指示するための情報として利用することができるからに過ぎない。

これに対して、車両で行われる診断の多くでは、例えばエンジンの冷却水温度や空燃比などといった、整備者が直接的に操作することができない制御パラメータによってその実行条件が規定されている。こうした場合、車載電子制御ユニットに記憶された診断の実行条件の情報だけでは、その成立に必要な車両操作の具体的な指示を行うには明らかに情報が不足している。そのため、診断完了に必要な車両操作を十分に指示するには、診断の実行に本来必要な情報に加えて、指示用の情報を車載電子制御ユニットに追加記憶させることが必要となる。そして診断項目のすべてについてそうした指示を行うとすれば、車載電子制御ユニットに必要とされる記憶容量は膨大なものとなってしまうため、その実現は困難となっている。

本発明はこうした実状に鑑みてなされたものであって、その解決しようとする課題は、車載電子制御ユニットの記憶容量を増加させずとも、診断の完了に必要な車両操作の指示を行うことのできる車両診断システムを提供することにある。

上記課題を解決するため、請求項１に記載の発明では、車両に接続された診断用端末を用いて前記車両の診断を行う車両診断システムにおいて、前記診断の完了に必要な車両操作の指示情報を格納した診断方法データベースが前記車両の外部に設置されるとともに、前記指示情報を前記診断方法データベースから取得して出力する指示情報出力手段を備えるようにしている。

上記の如く構成された車両診断システムでは、診断結果を要求した診断や、実行させようとした診断の実行条件が成立していないような場合にも、その診断の完了に必要な車両操作の指示情報が出力され、その指示情報に従って車両操作を行うことで診断を完了させられるようになっている。このときに上記車両診断システムでは、そうした車両操作の指示情報を、車両外部に設置された診断方法データベースから取得するようにしている。すなわち、診断完了に必要な車両操作の指示情報、具体的には診断の実行条件成立や実行に必要な車両操作の手順についての情報を、車両内部（車載電子制御ユット）に記憶させておくのではなく、車両外部に設置されたデータベースに記憶させておくようにしている。そして診断時に、そうした車両外部のデータベースから指示情報を取得して、診断完了に必要な車両操作についての整備者への提示やその実行の指令などを行うために、診断用端末や車両に対して出力するようにしている。そのため、車載電子制御ユニットの記憶容量を増加させずとも、診断の完了に必要な車両操作の指示を行うことができる。なお、こうした車両診断システムは、請求項２によるように、車両で行われる自己診断が完了しているか否かを判定してその判定結果を出力するものとして、或いは請求項３によるように、車両で行われる自己診断の結果を車両から取得して出力するものとして構成することができる。

請求項４に記載の発明は、請求項１〜３のいずれか１項に記載の車両診断システムにおいて、その指示情報出力手段の出力する上記指示情報を、診断の完了に必要な車両操作を整備者に通知するために用いるようにしたものである。この場合、整備者は、通知された指示情報に従って車両を手動操作することで、診断を完了させることができるようになる。こうした車両操作の通知は、例えば請求項５によるように、診断方法データベースに格納される上記車両操作の指示情報として、その車両操作の手順を説明する指示テキストを備えることで行うができる。なお車両操作の通知は、例えば請求項６によるように、診断用端末での指示情報の表示を通じて行ったり、請求項７によるように、車載表示機器、すなわちカーナビゲーションシステムなどの情報表示機能を備えた車載機器での指示情報の表示を通じて行ったり、することが可能である。

一方、請求項８に記載の発明は、請求項１〜７のいずれか１項に記載の車両診断システムにおいて、その指示情報出力手段の出力する指示情報を、診断の完了に必要な車両操作の自動実行を車両に指令するために用いるようにしたものである。こうした場合、指示情報出力手段の出力された指令に従って、診断完了に必要な車両操作が車載電子制御ユニットにより自動的に行われるようになる。そのため、整備者は、より少ない作業で診断を完了させることが可能となる。こうした指令は、請求項９に記載のように、診断方法データベースに格納される上記指示情報として、診断の完了に必要な車両操作の手順を車両に指示する制御情報（プログラム、コマンドなど）を備えることで実現することができる。

なお、このように診断完了に必要な車両操作が車載電子制御ユニットに自動実行させる場合に、整備者がその進捗状況を容易に確認できるように、次のような構成を採用するとよい。すなわち、請求項１０に記載のようにその実行を許可する旨の操作がなされたことを条件に開始させるようにしたり、請求項１１に記載のようにその実行を許可する旨の操作がなされるまでその開始を保留させるようにしたりすれば、そうした車両操作の自動実行が整備者の了解のもとで行われるようになる。また請求項１２に記載のように、車両操作の自動実行により診断が完了したときにその旨通知することも、診断の進捗状況を把握し易くする上で有効である。

なお、指示情報の指示に基づく車両操作を完了した後も、診断結果が出力されるまでには、ある程度の待ち時間が必要となることがある。こうした状況は、診断の実行条件の成立にある程度の時間を要する場合や、診断そのものの実行にある程度の時間を要する場合などで発生する。こうした場合において請求項１３に記載の車両診断システムでは、診断方法データベースに指示情報の指示に基づく車両操作の完了から診断結果が出力されるまでの待ち時間の情報を併せ格納するとともに、車両操作の完了が確認されたときに上記待ち時間の情報を通知するように指示情報出力手段を構成している。そのため、整備者は、必要な待ち時間を知ることができるようになり、診断の進捗状況をより的確に把握することができる。

なお以上のような車両診断システムの診断方法データベースは、例えば請求項１４に記載のように、整備工場に各々設置されて、車両の診断時に車両に接続される診断用端末に搭載させることができる。こうした場合、車種の追加や仕様の変更などに伴い、各作業場の診断方法データベースの指示情報の追加、更新が必要となることがある。そうした指示情報の追加・更新は、診断方法データベースに格納される指示情報を、請求項１５に記載のように、診断用端末に着脱自在な記憶メディア（例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、携帯型フラッシュメモリなど）を通じて各整備工場の診断用端末にそれぞれ配信することで行うことができる。また請求項１６に記載のように、ネットワークを介して各整備工場の前記診断用端末にそれぞれ配信したりすることでも行うことができる。

一方、上記のような車両診断システムの診断方法データベースは、請求項１７に記載のように、各整備工場の診断用端末のそれぞれに接続された管理センタに設置することもできる。この場合、指示情報が管理センタにおいて一元管理されるため、診断方法データベースに格納される指示情報の追加や更新を一括して行うことができる。すなわち、指示情報を最新のものに容易且つ確実に維持することができるようになる。更に請求項１８に記載のように、こうした車両診断システムの指示情報出力手段も管理センタに併せ設置するようにしても良い。

このように診断方法データベースを管理センタに設置する場合、請求項１９に記載のように、無線回線を通じて診断対象の車両の車載電子制御ユニットと上記管理センタとを接続するようにすれば、管理センタから直接、診断対象車両の運転状態を確認することができるようになる。そのため、車両の運転状態に逐次の変化に応じた、より高度な車両操作の指示を行うことができるようになる。なおこのときの無線回線としては、例えば請求項２０に携帯電話回線を利用することができる。

一方、請求項２１に記載の発明では、以上のような車両診断システムにおいて、診断が未完了であることを条件に指示情報の出力を行うように指示情報出力手段を構成するようにしている。こうした場合、診断が既に完了しており、更なる車両操作が不要な場合には、指示情報は出力されないため、より的確に車両操作の指示を行うことができる。なお、こうした場合の診断の完了／未完了の判定は、例えば請求項２２に記載のように車両の診断結果の記憶領域にアクセスし、そこに診断結果が記されているか否かで行うことができる。

更に請求項２３に記載の発明では、以上のような車両診断システムにおいて、診断方法データベースに、診断の実行条件の情報を併せ格納するとともに、車両から運転状態の現在値を取得して診断の実行条件の成否判定を行い、その成否判定の結果に基づいて指示情報の出力を行うように指示情報出力手段を構成するようにしている。このようにすれば、診断の実行条件の成立状況に応じた、より高度な車両操作の指示を行うことができる。

例えば請求項２４に記載の発明では、診断の実行条件が不成立であることを条件に指示情報を出力するように指示情報出力手段を構成することで、必要な場合にのみ車両操作の指示を行うこととしている。

また請求項２５に記載の発明では、診断の実行条件が成立しており、且つその診断の未完了が確認されているときには、診断完了までの待機を指示する指示情報を出力するように指示情報出力手段を構成することで、更なる車両操作が必要か不要かを分かり易く指示することができるようにしている。なお、こうした待機の指示情報の出力に際して、請求項２６に記載のように、その待ち時間の情報を併せ出力するように指示情報出力手段を構成することも、診断の進捗状況をより分かり易くする上で有効である。

更に請求項２７に記載の発明では、請求項２３〜２６のいずれか１項に記載の車両診断システムの診断方法データベースに、診断の実行手順を指示する指令情報を併せ格納するとともに、その指示情報出力手段を、診断の実行条件成立の確認に応じて、その指令情報に基づき車両に診断の実行を指令するように構成するようにしている。この場合、車両外部からの指令に基づいて車両の診断が実行されるようになる。

また請求項２８に記載の発明では、車両の運転状態の現在値に基づいて、診断の完了に必要な一連の車両操作の中から未実施の操作を確認し、その未実施の操作に限定して指示情報を出力するように指示情報出力手段を構成している。更に請求項２９に記載の発明では、車両の運転状態の現在値に基づいて、診断の完了に必要な一連の車両操作の中から未実施の操作を確認し、未実施の操作と実施済みの操作とを識別可能とした上で指示情報を出力するように指示情報出力手段を構成している。

一方、請求項３０に記載の発明では、請求項２３〜２９のいずれか１項に記載の車両診断システムにおける診断の実行条件の情報として、診断の実行条件を構成する各判定項目の成立要件の情報を備えるようにしている。ここで請求項３１によるように、診断方法データベースに、判定項目毎にその成立に必要な車両操作の指示情報を格納するようにすれば、より細密な車両操作の指示を行うことができるようになる。

また請求項３２によるように、判定項目毎の車両操作の指示情報に、その車両操作を手動、自動のいずれで行うかを指定する情報を含めるようにすれば、各判定項目の成立に必要な車両操作を手動、自動のいずれで行うかを、項目毎に予め規定しておくことができる。こうした場合、請求項３３によるように、手動、自動の指定に応じて指示情報の出力先の振り分けを行うようにすれば、そうした操作方法の指定に応じた適切な車両操作の指示を行うことができるようになる。

更に請求項３４に記載の発明では、請求項３１〜３３のいずれか１項に記載の車両診断システムにおいて、車両から取得した運転状態の現在値に基づいて、診断の実行条件を構成する判定項目のそれぞれの成否を判定し、その判定結果に応じて前記指示情報を出力するように指示情報出力手段を構成している。こうした構成によれば、実行条件の各判定項目の成立状況に応じたより細密な車両操作の指示を行うことができる。具体的には、例えば請求項３５によるように、未成立と判定された判定項目についてのものに限定して指示情報を出力したり、請求項３６によるように、成否の判定結果に基づいて各判定項目の成立状況を整備者に通知したり、することができる。

ちなみに、請求項３１〜３６のいずれか１項に記載の車両診断システムは、請求項３７によるように、診断の実行条件を構成する判定項目の種別の情報が診断項目毎にそれぞれ格納された実行条件マスタと、判定項目の種別毎にその成立要件の情報とその成立に必要な前記車両操作の指示情報とが格納された判定項目マスタとを、診断方法データベースに設ける構成として具現とすることができる。診断の実行条件は一般に、車種毎に異なっているため、請求項３８に記載のようにその実行条件マスタを車種別に設けるようにすると良い。

請求項３９に記載の発明は、こうした請求項１〜３８のいずれか１項に記載の車両診断システムにおいて、各車両の整備状態の情報（診断結果、部品交換の履歴、修理の履歴、車検結果などの情報）を格納する車両別カルテデータベースを備えるようにしたものである。こうした車両別カルテデータベースに格納される情報は、車両を診断する上で非常に有益なものとなる。また各車両の整備状態の情報を一元管理すれば、故障の種別毎の発生状況の統計が可能となり、車両の不具合の発見やその対応をより迅速且つ的確に行うことができるようにもなる。更に請求項４０によるように、こうした車両別カルテデータベースに、診断結果の出力履歴を併せ格納するようにしても良い。

本発明の車両診断システムによれば、車載電子制御ユニットの記憶容量を増加させることなく、診断の完了に必要な車両操作の指示を行うことができるようになる。

（第１実施形態）
以下、本発明を具体化した車両診断システムの第１実施形態について、図１〜図２０を参照して詳細に説明する。本実施形態の車両診断システムは、上述したような車両の診断作業において、診断の実行条件が不成立で診断が未完了のときに、その診断の完了に必要な車両操作を整備者に通知したり、必要な車両操作を車載電子制御ユニットに指令したりするための指示情報を出力する機能を提供する。ここで出力される指示情報は、車両外部に設置の診断方法データベースに格納されており、車載電子制御ユニットの記憶容量を増大させずに、診断完了に必要な車両操作の指示を実行可能となっている。

図１は、本実施形態の車両診断システムの全体構成を示している。同図に示すリモート管理センタＣは、車両メーカにより運営されており、管理下の各車両に対して運転状況の監視や各種情報の通知などのサービスを提供する。こうしたリモート管理センタＣには、そうしたサービスのための各種データ処理を行う管理サーバ１０が設置されている。この管理サーバ１０には、車種別診断方法データベース１１と車両別カルテデータベース１２との２つのデータベースが接続されている。なお本実施形態の車両診断システムでは、こうした管理サーバ１０が、診断の完了に必要な車両操作の指示情報を車種別診断方法データベース１１から取得して出力する上記指示情報出力手段としての機能を担っている。

管理サーバ１０は、携帯電話回線１３を用いた無線通信により、管理下の各車両３０の車載電子制御ユニット（ＥＣＵ）３１と接続可能とされている。車両３０には、こうした無線通信を行うための通信装置３２が組み込まれており、ＥＣＵ３１と接続されている。なお車両３０のＥＣＵ３１は、例えばエンジン（ＥＮＧ）ＥＣＵやＥＣＴＥＣＵなどの複数の制御ユニットによって構成されており、各制御ユニットは車内ＬＡＮを通じて相互接続されている。ＥＣＵ３１には、車両各部に設置された各種のセンサ３３（水温センサ、スロットルセンサ、アクセルセンサ、車速センサ、ＮＥセンサなど）やスイッチ３４（イグニッションスイッチ、シフトポジションスイッチ、エアコンスイッチなど）が接続されている。

管理サーバ１０は、インターネット１４を介して、各地の整備工場２０に設置された診断用端末２１に接続されている。診断用端末２１は、診断時に車両３０のＥＣＵ３１に接続され、整備者は、この診断用端末２１を操作して、車両３０の診断結果の出力を要求したり、車両３０の現在の運転状態（センサ、カウンタ、スイッチの現在値）を確認したりすることができるようになっている。

こうした車両診断システムでの車両３０の診断作業は、ＥＣＵ３１に接続された診断用端末２１を整備者が操作して、診断項目を指定して診断の結果読み出しや実行を要求することで行われる。ここで診断項目を指定可能な診断には、自己診断（ダイアグノーシス）結果の読み出しとアクティブテストの実行との２種類がある。

自己診断は、特に外部から指令せずとも、実行条件を満たす車両運転状態となれば、ＥＣＵ３１により自動的に実行される診断である。ＥＣＵ３１は、実行条件が成立していれば、診断を所定周期で繰り返し実施して、その都度その結果を記録更新する。自己診断の実行条件は、その項目毎にそれぞれ設定されている。例えば車速センサの動作確認のための自己診断の実行条件は、イグニッションスイッチがオンであってエンジンが稼働中であること、及びシフトレンジが「Ｐ」、「Ｎ］以外であり、且つエンジン回転速度が十分に高いこと、すなわち車両が走行状態にあること、のすべての成立となっている。こうした実行条件が車両運転中に成立するとＥＣＵ３１は車速センサからの車速パルスの入力の有無により、車速センサが正常に機能しているか否かを診断してその結果を記録する。

整備者は、部品の修理・交換後にその部品の自己診断を実行させ、その診断結果をＥＣＵ３１から読み出すことで動作確認を行っている。なお、車両の部品の修理・交換時には、ＥＣＵ３１のメモリが一旦クリアされるため、部品の修理・交換後の自己診断の実行の有無は、ＥＣＵ３１に診断結果が記録されているかどうかで確認することができる。

一方、アクティブテストは、外部（診断用端末２１など）からの指令により、ＥＣＵ３１が車両内部のアクチュエータを強制的に駆動して、必要な状況を自動設定して行われる診断である。整備者は、こうしたアクティブテストを実行して車両内部のアクチュエータを強制駆動させながら、車両運転状態をモニタして車両を診断する。こうしたアクティブテストは、たとえ実行条件が成立しても、外部からの指令がなければ実行されない点において、上記自己診断とは相違する。例えば電子制御スロットルの動作確認のためのアクティブテストは、スロットルバルブの目標開度を指定の値に設定してスロットルモータを駆動し、スロットルバルブの開度が指定の目標開度となっているか否かで、正常／異常の判定を行うものとなっている。こうしたアクティブテストは、アクティブテストの項目毎にそれぞれ設定された実行条件の成立に応じて実行可能となる。例えば上記電子制御スロットルの動作確認のアクティブテストの実行条件は、ＩＧスイッチがオンであってエンジンが稼働中であること、車速が「０」であって停車中であること、及びシフトレンジが「Ｐ」、「Ｎ］にあること、アクセルペダルが一定以上踏み込まれていること、のすべての成立となっている。

続いて、こうした車両診断システムの備える上記２つのデータベース、すなわち車種別診断方法データベース１１及び車両別カルテデータベース１２の詳細を説明する。
車種別診断方法データベース１１には、診断の完了に必要な車両操作の指示情報が格納されている。本実施形態の車両診断システムでは、車種別診断方法データベース１１は、次の４種のデータテーブル、すなわち車両ＩＤ−車種対応表Ｍ１、車種別仕様マスタＭ２、車種別実行条件マスタＭ３、及び判定項目マスタＭ４を備えて構成されている。

図２に示すように、車両ＩＤ−車種対応表Ｍ１は、車両の個体識別コードである「車両ＩＤ」をキー項目とし、車種毎に固有の「車種コード」をデータ項目とするデータテーブルであり、車両ＩＤから車種を確認するために使用される。ここでは、車両ＩＤとして、車両識別番号（ＶＩＮ：Vehicle Identification Number ）が用いられている。ＶＩＮは、車両３０のフレームなどに刻印されるとともに、ＥＣＵ３１にも記録されている。

図３に示すように、車種別仕様マスタＭ２は、「車種コード」をキー項目とし、「車両名」や車両の諸元についての各項目（「車両形式」、「エンジン形式」、「エンジン種類」、「燃料供給装置（の種類）」、「総排気量」、「燃料タンク容量」、「駆動方式」など）をデータ項目とするデータテーブルとなっている。こうした車種別仕様マスタＭ２は、車種コードからその車種の仕様を確認するために使用される。この車種別仕様マスタＭ２に格納された各車種の仕様についての情報は、診断用端末２１から参照可能とされている。

図４に示すように、車種別実行条件マスタＭ３は、自己診断の「診断コード（「DTC-0001」など）」、及びアクティブテストの「アクティブテストコード（ActiveTest-0001 」など）」をキー項目とし、各項目の自己診断及びアクティブテストの実行条件についての情報をデータ項目とするデータテーブルとなっている。こうした車種別実行条件マスタM3は、車種別にそれぞれ個別に設けられている。車種別実行条件マスタＭ３には実行条件の情報として、その実行条件を構成する各判定項目の識別コード（項目番号）と、判定に使用するクライテリア（閾値）とが示されている。なおアクティブテストの実行条件情報には、予め設定された手順に従ってアクティブテストを実行させるための制御情報が含まれている。

ここで項目番号の示された各判定項目の具体的な内容についての情報は、判定項目マスタＭ４に格納されている。具体的には、図５に示すように、判定項目マスタＭ４は、上記判定項目の「項目番号」をキー項目とし、「センサ」、「カウンタ」、「スイッチ」、「クライテリアとの関係」、「操作方法」、「指示テキスト」及び「車両への指令」をデータ項目とするデータテーブルとして構成されている。こうした判定項目マスタＭ４の各データ項目は、次の通りとなっている。

「センサ」、「カウンタ」、「スイッチ」のデータ項目は、その判定項目の成否判定に使用する制御パラメータを提供するセンサ、カウンタ、スイッチの種別を示している。
「クライテリアとの関係」のデータ項目は、判定項目が成立と判定されるときの、制御パラメータとクライテリアとの関係を示している。例えばこのデータ項目の値が「＝」であれば、上記「センサ」、「カウンタ」、「スイッチ」のデータ項目で指定された制御パラメータが、上述の車種別実行条件マスタＭ３で指定されたクライテリアと一致するときにその判定項目が成立することを示している。またこのデータ項目の値が「≧」であれば、制御パラメータがクライテリア以上のときにその判定項目が成立することを示している。具体例を挙げると、図５の判定項目マスタＭ４において項目番号「0003」の判定項目は、「水温センサの値（機関冷却水温）が『ＸＸ（クライテリア）』以上」がその成立要件であることを示している。

「操作方法」のデータ項目は、その判定項目を成立させるための車両操作を「手動」／「自動」のいずれで行うかを示している。また「指示テキスト」のデータ項目には、その判定項目を成立させるための手動による車両操作の手順を整備者に通知するための指示文のテキストデータが格納されている。なお本実施形態の車両診断システムでは、この「指示テキスト」に複数言語（例えば日本語と英語）のテキストデータを格納し、いずれの言語を使用するかを整備者が選択できるようにしている。

「車両への指令」のデータ項目には、その判定項目を成立させるための車両の自動操作をＥＣＵ３１に指令するための制御情報が格納されている。ちなみに同図では、こうした「車両への指令」のデータ項目の値が、車両操作の手順を示したテキストとして示されているが、実際にこのデータ項目に格納されるのは、そうしたテキストで示される手順での車両操作を指令するための制御情報となっている。

以上の如く構成された車種別診断方法データベース１１の情報を利用すれば、「車両ＩＤ」と「診断コード」、「アクティブテストコード」の指定により、そのコードにより指定された診断を完了するために必要な車両操作の指示情報を取得することができる。具体的には、管理サーバ１０は、次のようにして指示情報を取得している。まず管理サーバ１０は、受信した「車両ＩＤ」から、車両ＩＤ−車種対応表Ｍ１を参照して診断対象車両の「車種コード」を確認する。次に管理サーバ１０は、ここで確認した「車種コード」と受信した「診断コード」又は「アクティブテストコード」とから車種別実行条件マスタＭ３を参照して、その診断の実行条件を構成する各判定項目の「項目番号」を確認する。そして管理サーバ１０は、確認した「項目番号」のそれぞれについて、判定項目マスタＭ４を参照してその成立に必要な車両操作の指示情報を得るようにしている。

なお、以上のような車種別診断方法データベース１１のデータは、車両メーカによって管理されている。すなわち、車両メーカは、新車種の追加や既存車種の仕様変更などの必要に応じて、車種別診断方法データベース１１の各データテーブルに格納されるデータの追加・更新を行っている。

一方、車両別カルテデータベース１２は、管理下の各車両のカルテ情報を格納する。詳しくは図６に示すように、車両別カルテデータベース１２には「車種ＩＤ」毎に、「車種」、「自動車登録番号標（ナンバープレートの番号）」、各車両の「部品交換履歴」や「修理履歴」、「車検結果」などの情報が各車両のカルテ情報として格納されている。こうしたカルテ情報の内容は、車両の修理・診断時に整備者が参考とするため、診断用端末２１を用いて確認可能とされている。また車両別カルテデータベース１２は、インターネット１４を通じて車両所持者（ユーザ）のコンピュータ端末１５からもアクセス可能とされており、ユーザが自身のコンピュータ端末１５を用いて自身の車両のカルテ情報の内容を確認することができるようにもなっている。

（自己診断の結果読み出し）
続いて、以上のように構成された本実施形態の車両診断システムにおいて、自己診断結果の読み出しを要求したときの診断作業の流れについて説明する。以下では、診断完了に必要な車両操作の有無やその操作の種類のそれぞれ異なる第１ケース〜第５ケースの５つの場合における診断作業の流れを説明する。

＜第１ケース＞ 手動操作と自動操作とが必要な場合
図７−１及び図７−２は、診断の完了、すなわち自己診断の実行条件の成立に、車両３０の手動操作と自動操作との双方が必要とされる場合の診断作業シーケンスを示している。図７−１に示すように、診断作業はまず、整備者が診断用端末２１を操作して、診断コードを指定して自己診断の結果読み出しを要求することから開始される（ａ１）。この操作により、診断用端末２１から管理サーバ１０へと「診断結果の読み出し要求」が、指定された「診断コード」と共に通知される（ａ２）。また、このときの管理サーバ１０には、診断用端末２１がＥＣＵ３１から読み込んだ「車両ＩＤ」も併せて通知される。

管理サーバ１０は、この通知を受領すると、通知された「車両ＩＤ」に該当する車両３０のＥＣＵ３１にアクセスし、そのＥＣＵ３１のメモリから、通知された「診断コード」に該当する項目の自己診断結果のデータを読み込んで（ａ３）、そこに診断結果が既に記録されているか否かにより、診断の完了／未完了の判定を行う（ａ４）。

この第１ケースでは、ここで「診断未完了」と判定される。この場合、管理サーバ１０は「診断未完了」を診断用端末２１に通知し、そのモニタにその旨のメッセージを表示させる（ｂ１）。そして管理サーバ１０は、車種別診断方法データベース１１を参照して、先に通知された「車両ＩＤ」及び「診断コード」から、該当する車種、項目の自己診断の実行条件情報を取得する（ｂ２）。

ここで例として、通知された「車両ＩＤ」及び「診断コード」がそれぞれ「0001」及び「DTC-0001」であったときの上記実行条件情報の取得態様を述べる。このときの管理サーバ１０は、まず通知された「車両ＩＤ」をもとに車両ＩＤ−車種対応表Ｍ１（図２）を参照して、診断対象車両の「車種コード」が「Ａ」であることを確認する。続いて車種別実行条件マスタＭ３（図４）を参照して、車種コード「Ａ」の診断コード「DTC-0001」の診断実行条件を構成する各判定項目の項目番号が「0001」〜「0004」、「0006」、「0007」、「0009」及び「0011」であることを確認する。またこのときに管理サーバ１０は、各判定項目のクライテリアも併せ取得する。その後、管理サーバ１０は、判定項目マスタＭ４（図５）を参照して、上記項目番号の判定項目の具体的な内容を確認する。例えば項目番号「0001」は、ＩＧ（イグニッション）スイッチの値が、指定されたクライテリア（「オン」又は「オフ」）であることを成立要件とする判定項目であること、及びここではそのクライテリアが「オン（ＯＮ）」に指定されていること、が確認される。以上により、管理サーバ１０は、ここで診断結果を要求された自己診断の実行条件が、以下の判定項目ａ〜ｈのすべてが同時に成立すること、であると確認することができる。なお、図５に示した判定項目マスタＭ４を参照すると、下記判定項目ａ〜ｈのうち、判定項目ｃ、ｄは「操作方法」のデータ項目が「自動」に指定され、それ以外は「操作方法」のデータ項目が「手動」に指定されている。

＜車種Ａの診断コードDTC-0001の実行条件＞
ａ．ＩＧスイッチが「オン（ＯＮ）」である。
ｂ．ＩＧスイッチ「ＯＮ」からの経過時間が「６０秒」以上である。
ｃ．水温センサの値（機関冷却水温）が「８０℃」以上である。
ｄ．スロットルセンサの値（スロットル開度）が「80°」以上である。
ｅ．アクセルセンサの値（アクセル操作量）が「58°」以上である。
ｆ．車速センサの値（車速）が「10km/h」未満である。
ｇ．ＮＥセンサの値（機関回転速度）が「2000 rpm」未満である。
ｈ．シフトポジションが「Ｐ又はＮ」レンジ以外である。

管理サーバ１０は、こうして取得した実行条件情報より、その実行条件を構成する各判定項目がその成否判定に使用する制御パラメータ（センサやカウンタ、スイッチの値）を確認し、その現在値を取得する（ｂ３）。そして管理サーバ１０は、その取得した制御パラメータの現在値に基づいて各判定項目の成立／未成立を確認して、診断の実行条件が成立しているか否かを判定する（ｂ４）。この第１ケースでは、ここで「実行条件不成立」と判定される。そこで管理サーバ１０は、「実行条件不成立」及び「未成立の判定項目」を診断用端末２１に通知する（ｂ５）。この通知により、診断用端末２１のモニタには、図８に例示するように、「実行条件不成立」のメッセージと未成立の判定項目の一覧とが表示される。同図の画面表示例では、上述の診断コード「DTC-0001」の自己診断について、その実行条件の判定項目のうち、項目番号「0004」、「0006」、「0007」及び「0009」の判定項目が（上記項目ｄ、ｅ、ｆ及びｇ）が未成立であることが示されている。

更に管理サーバ１０は、ここで未成立が確認された判定項目のそれぞれについて、車種別診断方法データベース１１の判定項目マスタＭ４より、その成立に必要な車両操作の指示情報を取得する（ｂ６）。すなわち、判定項目マスタＭ４において「操作方法」のデータ項目が「手動」に指定された判定項目についてはその「指示テキスト」の値を、「自動」に指定された判定項目についてはその「車両への指令」の値をそれぞれ取得する。

そして管理サーバ１０は、上記「操作方法」のデータ項目が「手動」に指定された、未成立の判定項目の「指示テキスト」を診断用端末２１に通知し（ｃ１）、そのモニタに表示させる。図９は、このときの診断用端末２１の画面表示の一例を示している。同図の画面表示例では、上述の診断コード「DTC-0001」の自己診断について、その実行条件を構成する上記判定項目ａ〜ｈのうち、判定項目ｅ、ｆ及びｇについての手動操作の指示テキストが表示されている。整備者は、この表示された指示テキストに従って必要な車両３０の手動操作を実行し（ｃ３）、その操作を完了すると診断用端末２１を通じて「操作完了」を管理サーバ１０に通知する（ｃ４）。

図７−２に示すように、こうして「操作完了」が通知されると管理サーバ１０は、診断用端末２１に対して「自動操作実行の許可」を要求する（ｄ１）。この要求を受けた診断用端末２１のモニタには、図１０に例示するような、自動操作実行の許可についての可否選択画面が表示される。同図の画面表示例では、上記判定項目ｄについての自動操作（「スロットル開度が８０度以上となるようにスロットルモータを駆動した後、再判定を実行」）の実行を許可するか否かを「ＹＥＳ］／「ＮＯ」で選択することを要請するテキストが表示されている。

ここで整備者が診断用端末２１を操作して「ＹＥＳ」を選択すると、管理サーバ１０に「自動操作実行の許可」が通知される（ｄ２）。自動実行の許可が通知されると、管理サーバ１０は、上記判定項目マスタＭ４の「操作方法」のデータ項目が「自動」に指定された、未成立の判定項目の「車両への指令」のデータ項目に格納された制御情報をもとに、ＥＣＵ３１に必要な自動操作の実行を指令する（ｄ３）。例えばこのときの管理サーバ１０は、上述の診断コード「DTC-0001」の自己診断についてその実行条件の判定項目ｄ）が未成立であれば、「スロットル開度が８０度以上となるようにスロットルモータを駆動した後、再判定を実行」をＥＣＵ３１に指令する。ＥＣＵ３１は、指令に従って自動操作を実行し（ｄ４）、それが完了すると管理サーバ１０に「操作完了」を通知する（ｄ５）。

こうして診断完了に必要な車両３０の手動操作、自動操作のいずれもが完了されると、管理サーバ１０は、ＥＣＵ３１からの「診断結果」を読み込んで（ｅ１）、診断の完了／未完了を再び判定する（ｅ２）。そして診断が完了していれば、管理サーバ１０は、取得した診断結果を診断用端末２１に通知して（ｅ３）、そのモニタに表示させる。また管理サーバ１０は、その診断結果を、車両別カルテデータベース１２の該当車両のカルテ情報に追加する（ｅ４）。

なお、このときにも診断が未完了であった場合には、管理サーバ１０は「診断未完了」を診断用端末２１に通知して、そのモニタにその旨のメッセージを表示させる。この場合、整備者は、診断作業を始めからやり直すことになる。こうした診断作業のやり直しを、管理サーバ１０が自動的に行うようにすることもできる。この場合、上記診断用端末２１への「診断未完了」の通知（ｂ１）以降のシーケンスが診断完了まで繰り返されることになる。

＜第２ケース＞ 手動操作のみが必要な場合
図１１は、自己診断の完了に手動操作のみが必要とされる場合の診断作業シーケンスを示している。こうした第２ケースは、診断実行条件の各判定項目の成否判定において、自動操作に指定の判定項目はすべて成立と判定され、手動操作に指定の判定項目のみが未成立と判定された場合や、その診断の実行条件の判定項目のすべてが手動操作に指定されている場合などに該当する。この第２ケースでの診断作業は、このときには不要な自動操作の車両への指令に関するシーケンス（ｄ１〜ｄ５）が省略されること以外は、第１ケースと同様に行われる。

＜第３ケース＞ 自動操作のみが必要な場合
図１２は、自己診断の完了に自動操作のみが必要とされる場合の診断作業シーケンスを示している。こうした第３ケースは、先の第２ケースとは逆に、診断実行条件の各判定項目の成否判定において、手動操作に指定の判定項目はすべて成立と判定され、自動操作に指定の判定項目のみが未成立と判定された場合や、その診断の実行条件の判定項目のすべてが自動操作に指定されている場合などに該当する。この第３ケースでの診断作業は、このときには不要な手動操作の「指示テキスト」の通知に関するシーケンス（ｃ１〜ｃ４）が省略されること以外は、第１ケースと同様に行われる。

＜第４ケース＞ 待ち時間のみが必要な場合
図１３は、自己診断の完了に待ち時間のみが必要な場合、すなわち診断の実行条件は成立しているものの、診断自体は未完了である場合の診断作業シーケンスを示している。ダイアグ判定の中には、一定の期間におけるセンサ値の推移状況（センサ値の変化率やセンサ値の変動幅など）をもとに正常／異常の判定を行う場合などのように、実行条件が成立しても直ちには診断結果が得られないものもある。

上記のような場合には、整備者は単に、診断が完了してその結果がＥＣＵ３１に記録されるのを待つだけで診断作業を完了することができる。本実施形態の車両診断システムでは、こうした場合に、診断完了までの待ち時間を整備者に通知するようにしている。なお上述したように、診断開始（実行条件の成立）から完了（診断結果の記録）までに待ち時間が必要な診断については、車種別実行条件マスタＭ３の該当項目の実行条件情報の中に、そうした待ち時間の情報が含まれている。

こうした第４ケースでの診断作業も、実行条件の成否判定（ｂ４）までは、第１ケースと同様に行われる。なお、この第４ケースでは、診断完了／未完了の判定（ａ４）では「診断未完了」と判定され、上記実行条件の成否判定（ｂ４）では「実行条件成立」と判定される。

このときの管理サーバ１０は、上記（ｂ４）における「実行条件成立」の判定後、診断用端末２１に対して「実行条件成立」と診断完了までの待ち時間を通知する（ｆ１）。この通知を受けた診断用端末２１のモニタには、診断の完了待ちであること、及び診断完了までの待ち時間を通知する画面が表示される。図１４は、このときの診断用端末２１の画面表示の一例を示している。

以後、管理サーバ１０は、上記（ｂ４）での実行条件成立の判定後の経過時間に基づいて、待ち時間の終了判定を行い（ｆ２）、待ち時間が終了すると、ＥＣＵ３１から診断結果を読み出して（ｅ１）、診断の完了／未完了の再判定を行う（ｅ２）。そして診断が完了していれば、管理サーバ１０は、読み込んだ診断結果の診断用端末２１への通知（ｅ３）と、車両別カルテデータベース１２の該当車両のカルテ情報の更新（ｅ４）とを行い、今回の診断作業を終了する。

なお、上記第１〜第３ケースのように診断作業において車両操作が行われるときにも、診断完了に待ち時間が必要な場合には、実行条件の成立に必要なすべての車両操作の完了が管理サーバ１０に通知された後、上記シーケンス（ｆ１，ｆ２）が行われ、整備者に待ち時間が通知される。

＜第５ケース＞ 診断結果要求時に診断が既に完了していた場合
図１５は、診断結果の要求時に診断が完了していた場合の、すなわち診断結果が既に記録されていた場合の診断作業シーケンスを示している。こうした第５ケースでは、上記（ａ４）での診断作業開始直後の診断の完了／未完了の判定において「診断完了」と判定される。よってこの場合には、管理サーバ１０はそのまま、読み込んだ診断結果の診断用端末２１への通知（ｆ３）、及び車両別カルテデータベース１２における該当車両のカルテ情報の更新（ｆ４）を行って、今回の診断作業を終了する。

続いて、こうした本実施形態の車両診断システムでの自己診断結果の読み出しに係る管理サーバ１０、診断用端末２１、及び車両３０（ＥＣＵ３１）のそれぞれの処理の詳細を説明する。

まず、管理サーバ１０の処理を説明する。図１６は、管理サーバ１０の実行する「センタ側診断結果読出ルーチン」のフローチャートを示している。管理サーバ１０は、本ルーチンの処理を周期的に繰り返し実行し、その処理が開始される毎に診断用端末２１からの自己診断結果の読み出し要求の通知の有無を確認して（Ｓ１００）、通知があれば（ＹＥＳ）、ステップＳ１１０以降の処理を実行する。

「診断結果の読み出し要求」が通知されると管理サーバ１０は、まずステップＳ１１０において、通知された「車両ＩＤ」に該当する車両３０のＥＣＵ３１にアクセスして、通知された「診断コード」に対応する診断結果のデータを読み込む。そして管理サーバ１０は、続くステップＳ１２０において、診断結果の記録の有無に基づいて、診断の完了／未完了を判定する。ここで診断が完了していれば（Ｓ１２０：ＹＥＳ）、管理サーバ１０は、処理をステップＳ１８０に進め、このステップＳ１８０において「診断完了」及び取得した診断結果を診断用端末２１に通知する。更に管理サーバ１０は、ステップＳ１９０においてその診断結果に応じて車両別カルテデータベース１２の該当車両のカルテ情報の更新を行った後、今回の本ルーチンの処理を終了する。

一方、診断が未完了であれば（Ｓ１２０：ＮＯ）、管理サーバ１０はステップＳ１３０において、車種別実行条件マスタＭ３から、該当する車種、項目の自己診断の実行条件情報を取得する。続いて管理サーバ１０は、ステップＳ１４０においてＥＣＵ３１から現在の車両運転状態を取得し、続くステップ１５０において診断の実行条件の成否を判定する。

ここで実行条件が成立していれば（ＹＥＳ）、管理サーバ１０は、ステップＳ１６０において、「実行条件成立」及び「待ち時間（必要な場合のみ）」を診断用端末２１に通知した後、ステップＳ１１０に戻って再び診断の完了／未完了を判定する。一方、診断の実行条件が未成立であれば（Ｓ１５０：ＮＯ）、管理サーバ１０は、ステップＳ１７０において、「実行条件不成立」及び未成立の判定項目を診断用端末２１に通知し、続くステップＳ２００において「指示情報出力ルーチン」の処理を実行する。

図１７は、上記ステップＳ２００の「指示情報出力ルーチン」のフローチャートを示している。同図に示すように、本ルーチンの処理が開始されると、管理サーバ１０は、まずステップＳ２１０において、未成立の判定項目のそれぞれについて、その成立に必要な車両操作の指示情報（手動操作の「指示テキスト」、自動操作の「車両への指令」）を判定項目マスタＭ４から取得する。

手動操作が必要でない場合（Ｓ２２０：ＮＯ）、管理サーバ１０は、続くステップＳ２３０、Ｓ２４０をスキップして、処理をステップＳ２５０に進める。一方、手動操作が必要であれば（Ｓ２２０：ＹＥＳ）、管理サーバ１０は、ステップＳ２３０において手動操作の「指示テキスト」を診断用端末２１に通知し、ステップ２４０において診断用端末２１からの「操作完了」の通知を待って、処理をステップＳ２５０に進める。

処理がステップＳ２５０に進むと、管理サーバ１０は自動操作が必要か否かを判定し、不要であれば（ＮＯ）、本ルーチンの処理を終了し、必要であれば（Ｓ２５０：ＹＥＳ）、ステップＳ２６０の処理に進む。このステップＳ２６０において管理サーバ１０は、診断用端末２１に対して「自動操作実行の許可」を要求し、ステップＳ２７０において診断用端末２１からの回答を待つ。ここで診断用端末２１からの「許可」の通知があれば（Ｓ２７０：ＹＥＳ）、管理サーバ１０は続くステップＳ２８０において、自動操作の実行をＥＣＵ３１に指令する。その後、管理サーバ１０は、ステップＳ２９０にてＥＣＵ３１からの「操作完了」の通知を待った後、本ルーチンの処理を終了する。管理サーバ１０は、本ルーチンの処理を終了すると、上述のセンタ側診断結果読出ルーチン（図１６）のステップＳ１１０に戻り、診断の完了／未完了を再判定する。

次に、診断結果の読み出し要求に対する診断用端末２１の処理について説明する。図１８は、診断用端末２１の実行する「端末側診断結果読出ルーチン」のフローチャートを示している。診断用端末２１は、本ルーチンの処理を周期的に繰り返し実行し、本ルーチンが開始される毎に、整備者による診断結果の読み出し要求の操作があったか否かを確認する（Ｓ３００）。ここでそうした操作が確認されれば（ＹＥＳ）、ステップＳ３１０以降の処理を実行する。

「診断結果の読み出し要求」の操作がなされると、診断用端末２１はまず、ステップＳ３１０において、「診断結果の読み出し要求」及び指定された「診断コード」を管理サーバ１０に通知する。なお、このときの診断用端末２１は、対象となる車両３０の「車両ＩＤ」をＥＣＵ３１から取得して、管理サーバ１０に併せ通知する。

上述したように、こうした通知に対して管理サーバ１０は診断の完了／未完了を判定し（図１６：Ｓ１２０）、その結果を診断用端末２１に通知する。診断用端末２１は、続くステップＳ３２０においてその判定結果の通知を待ち、「診断完了」の通知が受領されれば（Ｓ３３０：ＹＥＳ）、ステップＳ３４０において管理サーバ１０から受領した「診断結果」を「診断完了」のメッセージと共にモニタに表示して（Ｓ３５０）、今回の本ルーチンの処理を終了する。

一方、「診断未完了」の通知が受領された場合には（Ｓ３３０：ＮＯ）、診断用端末２１はステップＳ３６０において、診断の実行条件の成否判定の結果が管理サーバ１０から通知されるのを待つ。そして診断用端末２１は、「実行条件成立」の通知が受領されれば（ＹＥＳ）、ステップ３７０にて管理サーバ１０から受領した診断完了までの待ち時間を「実行条件成立」のメッセージと共にそのモニタに表示する（Ｓ３８０）。そして診断用端末２１は、再びステップＳ３２０の処理に戻って、管理サーバ１０からの診断完了／未完了の通知を待つ。

これに対して「実行条件不成立」の通知を受領したときには（Ｓ３６０：ＮＯ）、診断用端末２１は、ステップＳ３９０にて管理サーバ１０から受領した未成立の判定項目を、「実行条件不成立」のメッセージと共に、そのモニタに表示する（Ｓ４００）。この場合には、やがて管理サーバ１０から、手動操作が必要であればその「指示テキスト」が、自動操作が必要であれば「自動操作実行の許可要求」が診断用端末２１に通知される。

手動操作が必要な場合、すなわち管理サーバ１０から手動操作の「指示テキスト」が通知された場合には（Ｓ４１０：ＹＥＳ）、診断用端末２１は、ステップＳ４２０においてその通知された手動操作の「指示テキスト」をそのモニタに表示する。このときのモニタには、操作完了の確認画面が併せ表示される。その後、整備者が操作を完了して操作完了の操作を行うと、診断用端末２１は、ステップＳ４３０において、「操作完了」を管理サーバ１０に通知する。

自動操作が必要な場合、すなわち管理サーバ１０から「自動操作実行の許可要求」が通知された場合には（Ｓ４４０：ＹＥＳ）、診断用端末２１はステップＳ４５０において、自動操作実行の可否の確認画面をそのモニタに表示する。そして続くステップＳ４６０において診断用端末２１は、ここでの整備者の選択操作の結果（自動操作実行の許可／不許可）を管理サーバ１０に通知する。

以上の処理を行った後、診断用端末２１はステップＳ３２０の処理に戻り、再び管理サーバ１０からの診断完了／未完了の通知が受領されるのを待つ。
最後に、上述したような診断作業シーケンスにおける車両３０の処理について説明する。図１９は、ＥＣＵ３１により実行される「車両側診断結果読出ルーチン」のフローチャートを示している。ＥＣＵ３１は、本ルーチンの処理を、周期的（例えば４ミリ秒毎）に繰り返し実行する。そして本ルーチンにおいてＥＣＵ３１は、次の処理を実行する。

まず本ルーチンにおいてＥＣＵ３１は、管理サーバ１０から「診断結果の読み出し」の要請があれば（Ｓ５００：ＹＥＳ）、要請された項目の診断結果を管理サーバ１０に通知する（Ｓ５１０）。このときのＥＣＵ３１は、診断結果の記録の有無に拘わらず、要請された項目の診断結果の記憶領域のデータをそのまま管理サーバ１０に送信する。

また本ルーチンにおいてＥＣＵ３１は、管理サーバ１０から「現在の車両運転状態」の通知の要請があれば（Ｓ５２０：ＹＥＳ）、要請されたセンサ、カウンタ、スイッチの現在値を管理サーバ１０に通知する（Ｓ５３０）。

更に本ルーチンにおいてＥＣＵ３１は、管理サーバ１０から車両３０の自動操作の指令を受けると（Ｓ６００：ＹＥＳ）、その指令に応じた車両３０の自動操作を実行する。このときの指令に基づく車両３０の自動操作の実行処理は、次の態様で行われる。管理サーバ１０から自動操作の指令を受けると（Ｓ６００：ＹＥＳ）、ＥＣＵ３１はまず、ステップＳ６１０において自動操作の実行フラグを「オン（ＯＮ）」にセットする。この実行フラグが「オン」であれば（Ｓ６２０：ＹＥＳ）、ＥＣＵ３１はステップＳ６３０において、先に通知された指令に基づいて車両３０の自動操作を実行する。そして指令された自動操作のすべてを完了すると（Ｓ６４０：ＹＥＳ）、ＥＣＵ３１はステップＳ６５０において「操作完了」を管理サーバ１０に通知し、ステップＳ６６０にて実行フラグを「ＯＦＦ」にリセットした上で、今回の本ルーチンの処理を終了する。

なお本ルーチンの実行中には、指令された自動操作を完了できない場合にも（Ｓ６４０：ＮＯ）、ＥＣＵ３１はステップ６７０において「操作未完了」を管理サーバ１０に通知して、今回の本ルーチンの処理をそのまま一旦終了する。こうした場合にも、自動操作の実行フラグは「オン」に維持されるため、指令された自動操作の実行は、次回に本ルーチンが実行されたときに引き継がれる。

（アクティブテストの実行）
次に、本実施形態の車両診断システムにおいて「アクティブテスト実行」を要求したときの診断作業の流れを説明する。なお本実施形態の車両診断システムでは、こうしたアクティブテスト実行の要求時にも、上述した診断結果の読み出し要求時と同様に、その実行条件が不成立であれば、未成立の判定項目を成立させるために必要な車両操作の指示情報（手動操作の指示テキスト、自動操作の車両への指令）の出力を行うようにしている。

図２０は、アクティブテスト実行の要求時における診断作業シーケンスの一例を示している。なお同図では、アクティブテストの実行、すなわちその実行条件の成立に、車両３０の手動操作と自動操作との双方が必要な場合を示している。

整備者が診断用端末２１を操作して、診断コードを指定して「アクティブテスト実行」を要求すると（ｇ１）、指定された「アクティブテストコード」、ＥＣＵ３１から読み出した「車両ＩＤ」と共に、「アクティブテスト実行要求」が管理サーバ１０に通知される（ｇ２）。この通知を受けた管理サーバ１０は、車種別診断方法データベース１１を参照し、通知された「アクティブテストコード」及び「車両ＩＤ」から、該当する車種、項目のアクティブテストの実行条件情報を取得する（ｇ３）。このとき取得される実行条件情報には、アクティブテストをＥＣＵ３１に実行させるための指令（制御情報）が含まれている。

続いて管理サーバ１０は、取得した実行条件情報より、該実行条件の成否判定に使用する制御パラメータの種別を確認するとともに、通知された「車両ＩＤ」に基づいて該当車両３０のＥＣＵ３１にアクセスして、その制御パラメータの現在値を取得する（ｇ４）。そして管理サーバ１０は、その取得した値に基づいて、アクティブテストの実行条件が成立しているか否かを判定する（ｇ５）。

同図では、ここで「実行条件不成立」と判定されており、この場合に管理サーバ１０は、「実行条件不成立」と未成立の判定項目とを診断用端末２１に通知して（ｇ６）、そのモニタに表示させる。更に管理サーバ１０は、判定項目マスタＭ４から、未成立の判定項目についての車両操作の指示情報を取得する（ｇ７）。そして管理サーバ１０は、自己診断の結果読み出しの要求時と同様に、未成立の判定項目の成立に必要な車両操作の指示情報の出力を行う。

すなわち、管理サーバ１０は、未成立の判定項目についての手動操作の指示テキストを診断用端末２１に通知して（ｇ８）、そのモニタに表示させる。整備者は、この指示テキストに従って整備者が必要な車両操作を行い（ｇ９）、その操作が完了すると、診断用端末２１を操作して「操作完了」を管理サーバ１０に通知する（ｇ１０）。

続いて管理サーバ１０は、「自動操作実行の許可要求」を診断用端末２１に通知する（ｇ１１）。これに対して診断用端末２１から「許可」の通知がなされると（ｇ１２）、管理サーバ１０は、上記判定項目マスタＭ４の「車両への指令」のデータ項目に格納された制御情報に基づいて、必要な自動操作の実行をＥＣＵ３１に指令する（ｇ１３）。ＥＣＵ３１は、この指令に従って車両３０の自動操作を実行し（ｇ１４）、それが完了すると管理サーバ１０に「操作完了」を通知する（ｇ１５）。

必要な車両操作のすべてが完了されると、管理サーバ１０は、ＥＣＵ３１から現在の車両運転状態の情報を取得して（ｇ１６）、アクティブテストの実行条件の成否を再び判定する（ｇ１７）。ここで実行条件が成立していれば、アクティブテストの実行をＥＣＵ３１に指令する（ｇ１８）。ＥＣＵ３１は、この指令の指示する実行手順に従ってアクティブテストを実行する（ｇ１９）。

以上のようにアクティブテスト実行の要求時にも、自己診断の結果読み出しの要求時と同様に、診断完了に必要な車両操作の指示が、より詳しくはアクティブテストの実行条件の成立に必要な車両操作の指示とアクティブテストの実行指令とが行われる。そのため、整備者は、診断用端末２１のモニタに表示される指示テキストに従って車両３０を操作したり、診断用端末２１を操作してＥＣＵ３１による必要な車両操作の自動実行を許可したりするだけで、実行条件を成立させてアクティブテストを開始させることができる。

本実施形態の車両診断システムによれば、以下の効果を奏することができる。
（１）本実施形態の車両診断システムでは、診断の完了に必要な車両操作の指示情報（手動操作の指示テキストや自動操作の指令）を格納する車種別診断方法データベース１１が、車両３０の外部であるリモート管理センタＣに設置されている。そして管理サーバ１０がその車種別診断方法データベース１１から指示情報を取得して、診断用端末２１や車両３０（ＥＣＵ３１）に出力するようにしている。そのため、ＥＣＵ３１の記憶容量を特に増加させなくとも、診断の完了に必要な車両操作の指示を行うことができ、車両の診断作業をより容易なものとすることができる。

（２）診断の完了に必要な車両操作の指示テキストを車種別診断方法データベース１１に格納し、必要に応じてその指示テキストを診断用端末２１に表示するようにしているため、必要な車両操作を整備者に的確に通知することができる。

（３）診断の完了に必要な車両操作の手順を指示する制御情報を車種別診断方法データベース１１に格納し、必要に応じてその制御情報に基づく車両操作の実行を車両に指令するようにしているため、必要な車両操作を的確に自動実行させることができる。なお、こうした車両操作の自動実行は、整備者の許可が無ければ実行されないようになっており、またそうした車両操作の自動実行の完了時には整備者に通知がなされるため、整備者が診断の進捗状況を的確に掌握することができるようになっている。

（４）通知された指示情報の指示に基づく車両操作の完了から診断結果の出力までに待ち時間を要する場合には、車両操作完了の確認時にその待ち時間の情報を通知するようにしているため、奏した場合にも整備者は、診断の進捗状況を的確に把握することができる。

（５）車種別診断方法データベース１１及び管理サーバ１０をリモート管理センタＣに設置し、そこから必要に応じて各整備工場２０の診断用端末２１や車両３０に指示情報を配信するようにしている。そのため、情報の集約的に管理することができ、車種の追加や仕様変更に応じた情報の更新を容易且つ迅速に行うことができる。またその結果、各整備工場２０にそれぞれ設置される診断用端末２１はその分、簡易な構成とすることができるため、整備工場２０側も含めたシステム全体としての設備費用を低く抑えることができるようにもなる。

（６）管理サーバ１０が、インターネット１４を通じて各整備工場２０の診断用端末２１に接続されているため、遠隔地の整備工場２０においても、車両操作の指示を容易に行うことができる。

（７）携帯電話回線１３を通じて管理サーバ１０が車両３０に直接に接続可能とされており、車両３０から直接その運転状態を取得することができるため、車両３０の運転状態の逐次の変化に対応して、より的確に車両操作を指示することができる。

（８）ＥＣＵ３１における診断結果の記録の有無に基づき、診断の完了／未完了を判定し、診断が未完了であることを条件に指示情報を出力するようにしているため、更なる車両操作が不要なときに、不必要な車両操作の指示情報が出力されないようにすることができる。

（９）診断の実行条件が不成立であることを条件に指示情報を出力するように、しかも、診断の実行条件を構成する判定項目のそれぞれについてその成否を判定し、未成立の判定項目についてのみ、その成立に必要な車両操作の指示情報を出力するようにしている。そのため、不要な指示の省かれた的確な車両操作の指示を行うことができる。

（１０）診断が未完了であることが確認され、且つ診断の実行条件は成立していることが確認されているときには、診断完了までの待機を指示する指示情報を出力するようにしている。しかも、そうした場合に、診断完了までの待ち時間を通知するようにもしている。そのため、上記のような状況においても、診断の進捗状況を把握可能な、的確な指示を行うことができる。

（１１）アクティブテストの実行に係る車両操作の手順を指示する指令情報をその実行条件の情報とともに車種別診断方法データベース１１に格納し、実行条件成立の確認に応じて、その指令情報に基づくアクティブテストの実行を車両３０に指令するようにしている。このときにも、アクティブテストの実行条件が不成立であれば、その成立に必要な車両操作の指示情報の出力が行われる。そのため、アクティブテストについても、必要な車両操作を指示して、より容易に実行可能とすることができる。

（１２）診断の実行条件を構成する各判定項目の成否の判定結果に基づいて、各判定項目の成立状況を整備者に通知するようにしているため、整備者の状況把握を容易とすることができる。

（１３）診断の実行条件を構成する判定項目の種別の情報が診断項目毎にそれぞれ格納された車種別実行条件マスタＭ３と、判定項目の種別毎にその成立要件の情報、及びその成立に必要な車両操作の指示情報が格納された判定項目マスタＭ４とを備えて、車種別診断方法データベース１１が構成されている。異なる診断項目においても、その診断の実行条件を構成する判定項目には共通した種別の項目が含まれていることがあるため、上記の如く車種別診断方法データベース１１を構成することで、情報を効率的に格納することができる。

（１４）各車両の整備状態の情報である車両別カルテ情報の格納された車両別カルテデータベース１２を備えるとともに、その車両別カルテデータベース１２に各車両３０の診断結果の出力履歴を格納するようにしている。そのため、車両診断に有益な情報を提供することができる。また故障の種別毎の発生状況の統計を車種別に行うことが可能となり、車両の不具合の発見やその対応をより迅速且つ的確に行うことができるようにもなる。

以上説明した本実施形態の車両診断システムは、次のように変更して実施することもできる。
・上記実施形態では、車種別診断方法データベース１１は、車両ＩＤ−車種対応表Ｍ１、車種別仕様マスタＭ２、車種別実行条件マスタＭ３及び判定項目マスタＭ４の４種のデータテーブルを備えるデータ構造としている。もっとも、診断完了に必要な車両操作の指示情報を取得可能なデータ構造となっていれば、こうした車種別診断方法データベース１１のデータ構造としてこれ以外の構造を採用することも可能である。

・診断の完了に必要な車両操作の指示を行うだけであれば、車両別カルテデータベース１２は省略するようにしても良い。また同様に、車種別診断方法データベース１１の車種別仕様マスタＭ２を省略するようにしても良い。

・車種コードを車両３０に記録し、診断用端末２１がその車種コードを読み込んで管理サーバ１０に通知するようにすれば、車両ＩＤ−車種対応表Ｍ１を省略した構成としても、診断の対象とする車種に対応した車両操作の指示を行うことはできる。

・上記実施形態では、管理サーバ１０は、車両操作の指示情報を未成立の判定項目に限って出力するようにしていたが、成立／未成立の区別無く、診断の実行条件を構成する判定項目すべてについて車両操作の指示情報を出力するようにしても良い。こうした場合、既に成立した判定項目に関しての不要な車両操作についても指示されるようにはなるが、本来不要な操作が含まれるとはいえ、その指示に従って車両操作を行うことで、診断を完了させることはできる。

・上記実施形態では、必要な車両操作のすべてを実行した後、診断の完了までに待ち時間があるときには、その待ち時間を整備者に通知するようにしていたが、こうした通知を簡略化することもできる。例えば待ち時間の長さについては特に通知せず、単に待ち時間が必要であることを通知するだけでも、整備者はそれ以上の操作を行う必要がないことを理解できるため、診断の進捗状況の把握をより容易とされてはいる。また待ち時間があまり長くない場合などのように、そうした通知の必要性があまり無いのであれば、待ち時間の通知を省略するようにしても良い。

・上記実施形態では、車種別診断方法データベース１１からの指示情報の取得及びその出力に係る処理を、リモート管理センタＣに設置された管理サーバ１０が行うようにしていたが、そうした処理を整備工場２０の診断用端末２１が行うように車両診断システムを構成することもできる。そうした場合には、診断用端末２１が上記指示情報出力手段としての機能を担うことになる。

・上記実施形態では、判定項目毎にその成立に必要な車両操作を手動で行うか、自動で行うかをそれぞれ個別に指定するようにしていた。もっとも、可能であれば、判定項目の成立に必要な車両操作のすべてを自動で行うようにしても良い。またこれとは逆に、判定項目の成立に必要な車両操作のすべてを手動で行うようにすることも可能である。

・上記実施形態では、診断完了に必要な手動操作の指示テキストを、診断用端末２１に表示するようにしていたが、カーナビゲーションシステムのような情報表示機能を備えた車載表示機器などの他のインターフェイスにその表示を行うようにしても良い。

・診断完了に必要な車両操作の整備者への通知は、指示テキストを表示すること以外にも、画像や動画、音声などの別の通知手段を用いて行うこともできる。
・上記実施形態では、管理サーバ１０は、携帯電話回線１３を経由して車両３０から各種情報（診断結果の履歴や現在の車両運転状態など）を取得するようにしていたが、診断用端末２１及びインターネット１４を経由してそうした車両情報の取得を行うようにすることもできる。

・上記実施形態では、管理サーバ１０は、携帯電話回線１３を用いて車両３０と通信し、インターネット１４を用いて診断用端末２１と通信するようにしていたが、それらの通信をそれ以外の回線を用いて行うようにすることもできる。

（第２実施形態）
次に本発明を具体化した車両診断システムの第２実施形態について、上記実施形態と異なる点を中心に説明する。なお以下の説明において、上記実施形態のものと同様の構成及び機能を備える部材については、同一の符号を付してその説明を省略する。

第１実施形態の車両診断システムでは、診断を完了するための車両操作の指示情報を格納する車種別診断方法データベース１１と、同データベース１１から指示情報を取得して出力する管理サーバ１０とをリモート管理センタＣに設置し、各地の整備工場２０のそれぞれにおける車両診断作業をリモート管理センタＣにて集約的に管理するようにしていた。これに対して本実施形態では、リモート管理センタＣにアクセスすることなく、各々の整備工場２０にて車両診断作業を自己完結的に行えるように車両診断システムを構成している。

図２１に、そうした本実施形態の車両診断システムの全体構成を示す。同図に示すように、本実施形態の車両診断システムでは、整備工場２０に設置された診断用端末１２１に、診断方法データベース１１Ｂが設置されている。この診断用端末１２１の備える診断方法データベース１１Ｂも、第１実施形態の車両診断システムにおいてリモート管理センタＣに設置された車種別診断方法データベース１１（図１）と基本的には同じものである。

こうした本実施形態の車両診断システムでは、診断用端末１２１が、第１実施形態の車両診断システムにおける管理サーバ１０（図１）に準じた態様で、指示情報の出力に係る処理を実施する。すなわち、本実施形態では、診断用端末１２１が上記指示情報出力手段として機能を担っている。具体的には、診断用端末１２１は、診断結果の記録や現在の車両運転状態についての情報をＥＣＵ３１から直接読み込んで、診断の完了／未完了の判定や診断の実行条件の成否判定を実施する。そして診断用端末１２１は、未成立の判定項目についての指示情報を診断方法データベース１１Ｂから取得して、自身の表示画面に対する指示テキストの出力や、ＥＣＵ３１に対する指令を実施する。

なお、各整備工場２０の診断方法データベース１１Ｂは、新車種の追加や既存車種の仕様変更などに応じて、格納する情報の更新が必要となることがある。本実施形態の車両診断システムでは、こうした情報の更新を以下の態様で行うようにしている。

同図に示すように、各整備工場２０に設置の診断用端末１２１はそれぞれ、インターネット１４を介してリモート管理センタＣの管理サーバ１１０に接続されている。この管理サーバ１１０には、診断方法データベース１１Ａが接続されている。この診断方法データベース１１Ａは、各診断方法データベース１１Ｂの原本（マスタ）となっており、各整備工場２０の診断方法データベース１１Ｂはそのコピーとなっている。こうしたリモート管理センタＣの診断方法データベース（マスタ）１１Ａの情報は、必要に応じて車両メーカの手により更新されている。

一方、各整備工場２０の診断用端末１２１は、定期的に管理サーバ１１０にアクセスして、自身の診断方法データベース１１Ｂの情報とリモート管理センタＣの診断方法データベース１１Ａの情報とを照合する。そして診断用端末１２１は、リモート管理センタＣ側の情報の更新を確認すると、自身の診断方法データベース１１Ｂの情報をそれに併せて更新するようにしている。すなわち、ここではネット配信により、各整備工場２０の診断方法データベース１１Ｂを最新の情報に維持するようにしている。

こうした本実施形態の車両診断システムにおいても、第１実施形態の車両診断システムと同様に、ＥＣＵ３１の記憶容量を特に増大させずとも、診断の完了に必要な車両操作の指示を行って車両の診断作業を容易とすることができる。またネット配信により、各整備工場２０の診断方法データベース１１Ｂの情報を更新しているため、整備工場２０毎に設けられる、多数の診断方法データベース１１Ｂの情報の同期を比較的容易に行うことができる。

なお、診断方法データベース１１Ａがあまり高い頻度で更新されないのであれば、診断用端末１２１に着脱自在な記録媒体（ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、携帯型フラッシュメモリなど）を用いて診断方法データベース１１Ｂの情報更新を行うようにしても良い。こうした場合、新車種の追加などに応じて車両メーカが、診断方法データベース１１Ａの更新情報を記録した記録媒体を作成して各整備工場２０に配布し、各整備工場２０において配布された記録媒体を診断用端末１２１に装着して、更新情報を読み出して診断方法データベース１１Ｂの更新を行うことになる。

本発明の車両診断システムの第１実施形態についてその全体構成を模式的に示したブロック図。 同車両診断システムの車種別診断方法データベースに設けられる車両ＩＤ−車種対応表についてそのデータ構造を模式的に示した図。 同じく車種別診断方法データベースに設けられる車種別仕様マスタについてそのデータ構造を模式的に示した図。 同じく車種別診断方法データベースの車種別実行条件マスタについてそのデータ構造を模式的に示した図。 同じく車種別診断方法データベースの判定項目マスタについてそのデータ構造を模式的に示した図。 同車両診断システムに採用される車両別カルテデータベースについてそのデータ構造を模式的に示した図。 同車両診断システムにおける自己診断結果の読み出しに係る診断作業の第１ケースについてその前半部分における作業の流れを示したシーケンス図。 同じく診断作業の第１ケースについて後半部分における作業の流れを示したシーケンス図。 同車両診断システムの診断用端末に表示される「実行条件不成立」及び未成立判定項目の表示画面の一例を示す図。 同じく診断用端末に表示される手動操作の指示テキストの表示画面の一例を示す図。 同じく診断用端末に表示される「自動操作実行許可」の表示画面の一例を示す図。 同車両診断システムの自己診断結果の読み出しに係る診断作業の第２ケースについてその作業の流れを示したシーケンス図。 同診断作業の第３ケースについてその作業の流れを示したシーケンス図。 同診断作業の第４ケースについてその作業の流れを示したシーケンス図。 同車両診断システムの診断用端末に表示される「実行条件成立」及び待ち時間の表示画面の一例を示す図。 同診断作業の第５ケースについてその作業の流れを示したシーケンス図。 同車両診断システムにおいて管理サーバの実行するセンタ側診断結果読出ルーチンのフローチャート。 同じく管理サーバの実行する指示情報出力ルーチンのフローチャート。 同じく診断用端末の実行する端末側診断結果読出ルーチンのフローチャート。 同じくＥＣＵの実行する車両側診断結果読出ルーチンのフローチャート。 同車両診断システムにおけるアクティブテストの実行に係る診断作業についてその作業の流れを示すシーケンス図。 本発明の車両診断システムの第２実施形態についてその全体構成を模式的に示したブロック図。

符号の説明

Ｃ…リモート管理センタ
１０…管理サーバ（第１実施形態の車両診断システムにおける指示情報出力手段）
１１…車種別診断方法データベース
１１Ａ…診断方法データベース（マスタ）
１１Ｂ…診断方法データベース（コピー）
１２…車両別カルテデータベース
１３…携帯電話回線
１４…インターネット
１５…ユーザのコンピュータ端末
２０…整備工場
２１…診断用端末
３０…車両
３１…車載電子制御ユニット（ＥＣＵ）
３２…通信装置
３３…各種のセンサ
３４…各種のスイッチ
１１０…管理サーバ
１２１…診断用端末（第２実施形態の車両診断システムにおける指示情報出力手段）

Claims (40)

1. 車両に接続された診断用端末を用いて前記車両の診断を行う車両診断システムにおいて、
   前記診断の完了に必要な車両操作の指示情報を格納した診断方法データベースが前記車両の外部に設置されるとともに、
   前記指示情報を前記診断方法データベースから取得して出力する指示情報出力手段を備える
   ことを特徴とする車両診断システム。
2. 当該車両診断システムは、車両で行われる自己診断が完了しているか否かを判定してその判定結果を出力する
   請求項１に記載の車両診断システム。
3. 当該車両診断システムは、車両で行われる自己診断の結果を前記車両から取得して出力する
   請求項１又は２に記載の車両診断システム。
4. 前記指示情報は、前記診断の完了に必要な車両操作を整備者に通知するために用いられる
   請求項１〜３のいずれか１項に記載の車両診断システム。
5. 前記指示情報として、車両操作の手順を説明する指示テキストを備える
   請求項４に記載の車両診断システム。
6. 前記通知は、診断用端末での前記指示情報の表示を通じて行われる
   請求項４又は５に記載の車両診断システム。
7. 前記通知は、車載表示機器での前記指示情報の表示を通じて行われる
   請求項４又は５に記載の車両診断システム。
8. 前記指示情報は、診断の完了に必要な車両操作の自動実行を前記車両に指令するために用いられる
   請求項１〜７のいずれか１項に記載の車両診断システム。
9. 前記指示情報として、診断の完了に必要な車両操作の手順を前記車両に指示する制御情報を備える
   請求項８に記載の車両診断システム。
10. 前記車両操作の自動実行は、その実行を許可する旨の操作がなされたことを条件に開始される
    請求項８又は９に記載の車両診断システム。
11. 前記車両操作の自動実行は、その実行を許可する旨の操作がなされるまでその開始が保留される
    請求項８又は９に記載の車両診断システム。
12. 前記車両操作の自動実行により診断が完了したときに整備者にその旨を通知する
    請求項８〜１１のいずれか１項に記載の車両診断システム。
13. 前記診断方法データベースには、前記指示情報の指示に基づく車両操作の完了から診断結果が出力されるまでの待ち時間の情報が併せ格納され、
    前記指示情報出力手段は、前記車両操作の完了が確認されたときに、前記待ち時間の情報を通知する
    請求項１〜１２のいずれか１項に記載の車両診断システム。
14. 前記診断方法データベースは、整備工場に各々設置されて、前記車両の診断時に前記車両に接続される診断用端末に搭載されてなる
    請求項１〜１３のいずれか１項に記載の車両診断システム。
15. 前記診断方法データベースに格納される前記指示情報は、前記診断用端末に着脱自在な記憶メディアを通じて各整備工場の前記診断用端末にそれぞれ配信される
    請求項１４に記載の車両診断システム。
16. 前記診断方法データベースに格納される前記指示情報は、ネットワークを介して各整備工場の前記診断用端末にそれぞれ配信される
    請求項１４に記載の車両診断システム。
17. 前記診断方法データベースは、各整備工場の診断用端末のそれぞれに接続された管理センタに設置されてなる
    請求項１〜１３のいずれか１項に記載の車両診断システム。
18. 前記指示情報出力手段は、前記管理センタに設置されてなる
    請求項１７に記載の車両診断システム。
19. 前記管理センタは、無線回線を通じて前記車両に接続されてなる
    請求項１７又は１８に記載の車両診断システム。
20. 前記無線回線として、携帯電話回線を用いる
    請求項１９に記載の車両診断システム。
21. 前記指示情報出力手段は、前記診断が未完了であることを条件に前記指示情報の出力を行う
    請求項１〜２０のいずれか１項に記載の車両診断システム。
22. 前記指示情報出力手段は、前記車両の前記診断結果の記憶領域にアクセスし、前記診断結果が記録されているか否かで前記診断の完了／未完了を判定する
    請求項２１に記載の車両診断システム。
23. 前記診断方法データベースには、前記診断の実行条件の情報が併せ格納され、
    前記指示情報出力手段は、前記車両から運転状態の現在値を取得して前記診断の実行条件の成否判定を行い、その成否判定の結果に基づいて前記指示情報の出力を行う
    請求項１〜２２のいずれか１項に記載の車両診断システム。
24. 前記指示情報出力手段は、前記診断の実行条件が不成立であることを条件に前記指示情報を出力する
    請求項２３に記載の車両診断システム。
25. 前記指示情報出力手段は、前記診断の実行条件が成立しており、且つその診断の未完了が確認されているときには、診断完了までの待機を指示する指示情報を出力する
    請求項２４に記載の車両診断システム。
26. 前記指示情報出力手段は、前記待機の指示情報の出力に際して、その待ち時間の情報を併せ出力する
    請求項２５に記載の車両診断システム。
27. 前記診断方法データベースには、前記診断の実行手順を指示する指令情報が併せ格納されてなり、
    前記指示情報出力手段は、前記診断の実行条件成立の確認に応じて、その指令情報に基づき前記車両に診断の実行を指令する
    請求項２３〜２６のいずれか１項に記載の車両診断システム。
28. 前記指示情報出力手段は、前記車両の運転状態の現在値に基づいて、前記診断の完了に必要な一連の車両操作の中から未実施の操作を確認し、その未実施の操作に限定して前記指示情報を出力する
    請求項２３〜２７のいずれか１項に記載の車両診断システム。
29. 前記指示情報出力手段は、前記車両の運転状態の現在値に基づいて、前記診断の完了に必要な一連の車両操作の中から未実施の操作を確認し、未実施の操作と実施済みの操作とを識別可能とした上で前記指示情報を出力する
    請求項２３〜２７のいずれか１項に記載の車両診断システム。
30. 前記実行条件の情報として、前記診断の実行条件を構成する各判定項目の成立要件の情報を備える
    請求項２３〜２９のいずれか１項に記載の車両診断システム。
31. 前記診断方法データベースには、前記判定項目毎にその成立に必要な車両操作の指示情報が格納されてなる
    請求項３０に記載の車両診断システム。
32. 前記判定項目毎の前記車両操作の指示情報には、その車両操作を手動、自動のいずれで行うかを指定する情報が含まれる
    請求項３１に記載の車両診断システム。
33. 前記指示情報出力手段は、前記手動、自動の指定に応じて前記指示情報の出力先を振り分ける
    請求項３２に記載の車両診断システム。
34. 前記指示情報出力手段は、前記車両から取得した運転状態の現在値に基づいて、前記診断の実行条件を構成する前記判定項目のそれぞれの成否を判定し、その判定結果に応じて前記指示情報を出力する
    請求項３１〜３３のいずれか１項に記載の車両診断システム。
35. 前記指示情報出力手段は、未成立と判定された判定項目についてのものに限定して前記指示情報を出力する
    請求項３４に記載の車両診断システム。
36. 前記指示情報出力手段は、前記成否の判定結果に基づいて各判定項目の成立状況を整備者に通知する
    請求項３４又は３５に記載の車両診断システム。
37. 前記診断方法データベースには、前記診断の実行条件を構成する判定項目の種別の情報が診断項目毎にそれぞれ格納された実行条件マスタと、前記判定項目の種別毎にその成立要件の情報とその成立に必要な前記車両操作の指示情報とが格納された判定項目マスタとが設けられる
    請求項３１〜３６のいずれか１項に記載の車両診断システム。
38. 前記実行条件マスタは車種別に設けられる
    請求項３７に記載の車両診断システム。
39. 各車両の整備状態の情報を格納する車両別カルテデータベースを備える
    請求項１〜３８のいずれか１項に記載の車両診断システム。
40. 前記車両別カルテデータベースに、前記診断結果の出力履歴を格納する
    請求項３９に記載の車両診断システム。