JP4241953B2 - 車両用診断装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、車両に搭載された各種機器の状態を診断する車両用診断装置であって、特に、その診断結果を外部の管理センタ側へ送信可能にされた車両用診断装置に関する。
【０００２】
【従来の技術】
車両のメインテナンスは、例えば、日本では一定期間ごとの車検に応じてユーザーが整備工場にて検査及び修理をしてもらい陸運局に報告するようにしており、また米国では監督局からの定期的な通知に従いユーザーが整備工場で検査及び修理を受け基準を満たしていることを監督局に返信するというようにして管理されている。
【０００３】
ところがこのような方式では、特に故障や不良が無く整備の必要の無い車両まで一律に管理しているため、監督局（陸運局）での管理の工数が多くなっていると共に、ユーザにとっても煩わしいものである。
このようなことから、車両側にて検査に関わる情報（例えば、エンジン関連部品の異常に関する情報）を車両から無線通信にて監督局側に送信し、特に修理が必要な車両に対してそのユーザーに指示し報告させるようにすることが考えられる。
【０００４】
【発明が解決しようとする課題】
このようなシステムとした場合、車両側では無線通信を送受信するための装置（以下、トランスポンダという）を装備すると共に、検査に関わる情報を車載の制御ユニットで得て、制御ユニットからトランスポンダに通信するよう構成する必要が生じる。
【０００５】
しかしながら、監督局側から送信要求を受けたトランスポンダが制御ユニットに検査に関わる情報の出力要求を出す場合、その要求タイミングがエンジン始動時に重なると、通信状態が悪い状態なのでトランスポンダと制御ユニットとの間の通信ライン上にノイズが乗り、例えばトランスポンダに入力された信号が制御ユニットから出力された信号と異なり誤った情報が監督局に送られてしまう可能性がある。また、制御ユニットのマイクロコンピュータ（以下「マイコン」と略記する）が忙しい時、例えばエンジン制御ユニットであれば、エンジン高回転時や高負荷時などにおいては、トランスポンダへの出力データ量が多くなる（制御ユニットが異常を検出して記憶している場合）と、本来の制御処理に影響を与える可能性がある。
【０００６】
また、トランスポンダからの出力要求に制御ユニットが応じるのはなく、制御ユニット自身が、例えば所定の診断結果出力タイミングになった場合に診断結果を出力するよう自ら要求する場合であっても、上述したエンジン始動時や制御ユニットのマイコンが忙しい時の不都合は同様に生じる。
【０００７】
そこで、出力要求に応じて診断結果を通信ユニットに出力するには不適切な期間を判別し、その期間中は出力要求に対応しないようにした車両用診断装置を提供することを目的とする。
【０００８】
【課題を解決するための手段及び発明の効果】
上記目的を達成するためになされた請求項１記載の車両用診断装置によれば、車両に搭載されたエンジンを制御する制御ユニットがエンジンのエミッションに関連する異常を診断し、その診断結果は、制御ユニットと通信ラインで接続された通信ユニットによって外部の管理センタ側へ送信される。このような前提において、通信ユニットは、無線通信による管理センタ側からの送信要求に応じ、制御ユニットに対して診断結果を出力するよう要求し、また制御ユニットから診断結果を受信しない間は定期的に診断結果の出力を要求する。一方、制御ユニットは、通信ユニットから診断結果の出力要求を受けると、エンジンへの制御に要する処理負荷が所定以上大きいと考えられる不適期間中か否かを判断し、前記不適期間と判断したときは、通信ユニットへ診断結果を出力する要求があってもその要求には対応しない。一方、不適期間に該当しない場合には、診断結果の出力要求に応じて、診断結果を通信ユニットに出力する。
【００１０】
上述した不適期間中は、エンジンへの制御に要する処理負荷が所定以上大きい期間である。エンジンへの制御は制御ユニットの本来の仕事であり、優先度は相対的に高く、一方、診断結果の出力は相対的に見れば優先度が低い。つまり、制御ユニットが優先度の高いエンジンの制御の処理を実行するのに忙しい（つまりマイコンのエンジンの制御の処理負荷が高い）期間中においては、その優先度の高いエンジンの制御の処理を抑えてまで、あえて診断結果の出力という優先度の低い処理を実行する必要性はない。したがって、このような期間中に通信ユニットへ診断結果を出力する要求があっても、その要求には対応しない。エンジンの制御の処理負荷が大きい状態とは、例えばエンジン回転数が高い状態などである。つまり、回転数に対応した処理タイミングを設定すると、エンジン高回転状態においては単位時間当たりの処理量が多くなるからである。特にエンジンについてはリアルタイム処理が必要であり、診断結果の出力のように、緊急性が低い処理については後回しで一向に構わないのである。
【００１１】
ところで、制御ユニットは、「通信ユニットへ診断結果を出力する要求」に対応して診断結果を出力している。この診断結果の出力要求については、例えば、通信ユニットが、管理センタ側からの送信要求に応じ、制御ユニットに対して診断結果を出力するよう要求することが考えられる。このようにすれば、管理センタにおける管理に都合が良いタイミングで送信要求を出すことができるため、管理上の利点がある。一方、このように管理センタの都合に応じたタイミングで出された送信要求に応じて通信ユニットが制御ユニットに対して診断結果を出力するよう要求すると、その要求タイミングは、かならずしも制御ユニットにとって適切なタイミングとは限らない。したがって、上述したように、不適期間中には対応しなければ、不都合を解消できる。
【００１２】
そして、このように、管理センタ側からの送信要求に応じ、通信ユニットが制御ユニットに対して診断結果を出力するよう要求する場合には、制御ユニットが次のように対応することも考えられる。つまり、不適期間中において診断結果の出力要求があった場合には、その要求には対応しないが、要求があったこと自体は記憶しておき、その後、不適期間に該当しない状況となった時点で、記憶されている診断結果の出力要求に応じて、診断結果を通信ユニットに出力するのである。
【００１３】
このようにすれば出力要求へのレスポンスは向上する。なぜなら、出力要求が来た時点で不適期間中であるかどうかを判断し、不適期間中であれば対応せず、不適期間中でなければ対応するだけの場合には、不適期間が過ぎていても、その後に出力要求が来るタイミングを待たなくてはならない。つまり、必ずしも不適期間が過ぎた直後に出力要求が来るとは限らないからである。それに対して、診断結果の出力要求があったこと自体は記憶しておき、その後、不適期間に該当しない状況となった時点で出力要求に応じるようにすれば、対応して良い状態になったら即座に応じることができるため、出力要求へのレスポンスは向上する。
【００１４】
一方、不適期間中に来た診断結果の出力要求を記憶しておき、不適期間でなくなった場合に対応するのではなく、出力要求が来た時点で不適期間中であれば対応せず、不適期間中でなければ対応するタイプの場合には、通信ユニットは、制御ユニットから診断結果が出力されたことを確認するまで、定期的に制御ユニットへ要求することが考えられる。
【００１５】
また、制御ユニットから通信ユニットに出力された診断結果の正確性向上を期すためには、例えば次のようにすることも有効である。つまり、通信ユニットは、制御ユニットから診断結果が複数回出力され、かつ複数回の診断結果の内容が一致するまで、繰り返し前記制御ユニットへ要求し、診断結果が一致すると、その一致した診断結果を管理センタ側へ送信するのである。
【００１６】
また、通信ユニットに異常がある場合の制御ユニット側の対処としては、次のようにすることも有効である。つまり、通信ユニットからの要求に応じて診断結果を所定回数以上出力したにもかかわらず、さらに診断結果の出力要求が来た場合には、それ以降の要求には対応しない。
【００１７】
ところで、診断結果の出力要求については、上述したように、管理センタ側からの送信要求に応じた通信ユニットが制御ユニットに対して診断結果を出力するよう要求するのではなく、制御ユニットが、所定の診断結果出力タイミングになった場合に診断結果を出力するよう自ら要求してもよい。この所定の診断結果出力タイミングが例えば単に時間的な要因で設定されている場合には、診断結果の出力要求をした時点が、やはり上述の不適期間中であることも大いに考えられる。したがって、この場合にも同様に有効である。
【００１８】
なお、車両用診断装置は最終的には通信ユニットが管理センタ側に車両の診断結果を送信することとなるが、その診断結果に、車両固有の識別情報を含めることも考えられる。これは、診断結果がどの車両に対応するものなのかを容易に判別できる点で有効である。もちろん、これ以外にも、診断結果を送信してきた車両を特定する方法は考えられるが、診断結果に含まれていれば、特定が容易にできる。
【００１９】
また、診断結果には、診断対象の機器に関する情報だけでなく、付帯情報として、例えば診断時における車両の走行距離あるいは車両位置の少なくとも一方を含めることも有効である。つまり、その診断対象の機器が搭載された車両自体の走行距離に応じても診断結果の分析は変わる可能性があるからである。また、車両位置についても同様である。
【００２１】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り、種々の形態を採り得ることは言うまでもない。
［第１実施例］
図１は、実施例の車両用診断装置の搭載された車両を含む診断システムの概略構成を示す図である。当該システムの概略を説明する。監督局をなす管理センタＣは、レシーバＢを介して複数の車両Ａからそれぞれエミッション（排ガス）に関連するデータ、エンジンの故障に関するデータ等を無線通信にて入手する。管理センタＣは不具合のある車両Ａを特定して、その車両保有者に対して車両Ａの修理、改善を促す。なお、この車両Ａの修理、改善を促すのは、例えば書類を郵送するなど種々の方法が採用できる。
【００２２】
図２は、車両Ａ内の概略的なシステム構成を示すブロック図である。トランスポンダ１０はレシーバＢからの要求を受け、車載制御ユニットであるエンジンＥＣＵ３０、ナビＥＣＵ５０、メータＥＣＵ７０から必要な情報を通信ライン５を介して入手し、その入手した情報をレシーバＢ（図１参照）に対して送信する。
【００２３】
エンジンＥＣＵ３０は、エンジンの制御を司ると共に、エンジンのエミッションに関連する異常を自己診断し、トランスポンダ１０の要求に応じてその情報をトランスポンダ１０に送信する。
また、ナビＥＣＵ５０、メータＥＣＵ７０は、それぞれナビゲーション制御、メータ表示制御を実行すると共に、エンジンＥＣＵ３０が自己診断にて何らかの異常を検出したときに、エンジンＥＣＵ３０から出される要求に応じてそれぞれ車両の走行距離，車両位置をエンジンＥＣＵ３０に出力し、またトランスポンダ１０からの要求が来たときにそのときの走行距離，車両位置をトランスポンダ１０に出力する。
【００２４】
図３〜図６はトランスポンダ１０，及び各車載制御ユニットである各ＥＣＵ３０，５０，７０の構成を示すブロック図である。
まず、図３を参照してトランスポンダ１０について説明する。
トランスポンダ１０が動作するための電力を供給する電源回路１３には、バッテリ３から常時電力が供給されているので、車両のキーＳＷの状態に関係無く動作する。マイコン１１内のＣＰＵは、同じくマイコン１１内のＲＯＭに記憶された制御プログラムに従い、アンテナ２０を介して外部から来る要求に応じた処理を実行する。また、マイコン１１内のＲＡＭはエンジンＥＣＵ３０などからのデータ等を一時的に記憶する。なお、入出力回路１２がアンテナ２０及び通信ライン５と接続されており、この入出力回路１２を介して入出力されたデータはマイコン１１内のＩ／Ｏを介してＣＰＵなどをやりとりされる。また、マイコン１１にはＥＥＰＲ０Ｍ１４が接続されていて、車両固有の識別番号（ＶＩＮコード）が記憶されている。
【００２５】
次に、図４を参照してエンジンＥＣＵ３０について説明する。
エンジンＥＣＵ３０は、メイン電源回路３３がイグニッションＳＷ４を介してバッテリ３と接続されており、基本的には、イグニッションＳＷ４が投入されることによってメイン電源回路３３から電源が供給されて動作する。但し、イグニッションＳＷ４を介さずバッテリ３と直接つながるサブ電源回路３４からマイコン３１に電源供給されることで、マイコン３１のＲＡＭのデータがイグニッションＳＷ４のオフ後も保持されることとなる。
【００２６】
マイコン３１では、ＣＰＵがＲＯＭに記憶された制御プログラムに従い、入出力回路３２及びマイコン３１内のＩ／Ｏを介して入力したセンサ信号に基づいてエンジンが最適な動作をするようインジェクタ４７やイグナイタ４８を制御する信号を出力する。また、エンジンのエミッションに関連する異常を自己診断してエンジンの動作やセンサ４１〜４６の異常等を診断し、外部（ＤＩＡＧテスタ４９やトランスポンダ１０）からの要求に応じて診断結果のデータを出力する。また、マイコン３１内のＲＡＭは、ＣＰＵでの演算処理に使うセンサデータ、演算にて求まった制御データ、あるいは上記診断にて得た種々の診断データ等を保持している。
【００２７】
なお、入出力回路３２に接続されているセンサ４１〜４６は、空燃比（Ａ／Ｆ）センサ４１、エンジンの回転数を検出する回転センサ４２、エアフローメータ４３、水温センサ４４、スロットルセンサ４５、スタータＳＷ４６である。
次に、図５を参照してナビＥＣＵ５０について説明する。
【００２８】
ナビＥＣＵ５０は、電源回路５３がアクセサリＳＷ６を介してバッテリ３と接続されており、アクセサリＳＷ６が投入されることによってマイコン５１や入出力回路５２が動作する。この入出力回路５２には、受信機６２、地図データ入力装置６４及び表示モニタ６６が接続されている。受信機６２にはＧＰＳアンテナ６０が接続されており、これらは、ＧＰＳ衛星からの電波に基づいて車両の位置を検出するＧＰＳ（Global Positioning System ）のための構成である。また、地図データ入力装置６４は、位置検出の精度向上のためのいわゆるマップマッチング用データ、地図データを含む各種データを記憶媒体から入力するための装置である。このための記憶媒体としては、そのデータ量からＣＤ−ＲＯＭを用いるのが一般的であるが、例えばＤＶＤやメモリカード等の他の媒体を用いても良い。また、表示モニタ６６は地図や誘導経路などを表示するためのものであり、本実施例では、利用者からの指示を入力する機能も備えている。
【００２９】
マイコン５１では、ＣＰＵがＲＯＭの記憶された制御プログラムに従い、入出力回路５２及びマイコン５１内のＩ／Ｏを介して入力した地図データ入力装置６４からの地図データや受信機６２からの信号をもとに、表示モニタ６６から得られる利用者からの指示情報に対応して表示処理を実行し、表示モニタ６６に利用者が所望する情報を表示させる。また、マイコン５１は、エンジンＥＣＵ３０やトランスポンダ１０からの要求が通信ライン５を介して来たときには、受信した時点の車両位置を、要求してきたエンジンＥＣＵ３０やトランスポンダ１０に出力することができる。
【００３０】
次に、図６を参照してメータＥＣＵ７０について説明する。
メータＥＣＵ７０は、電源回路７３がアクセサリＳＷ６を介してバッテリ３と接続されており、アクセサリＳＷ６が投入されることによってマイコン７１や入出力回路７２が動作する。この入出力回路７２には、メータパネル８０や車速センサ８５などが接続されている。
【００３１】
マイコン７１では、ＣＰＵがＲＯＭに記憶された制御プログラムに従い、車速センサ８５などのセンサ信号を入力し、メータパネル８０に車速などの情報を表示させる。また、マイコン７１は、エンジンＥＣＵ３０やトランスポンダ１０からの要求が通信ライン５を介して来たときには、受信した時点の車両の累積走行距離を、要求してきたエンジンＥＣＵ３０やトランスポンダ１０に出力することができる。
【００３２】
次に、上述した構成のエンジンＥＣＵ３０にて実行される処理について、図７〜図１１を参照して説明する。
まず、エンジンＥＣＵ３０では、イグニッションＳＷ４（図４参照）が投入されることによって動作を開始すると、図７のメイン処理の最初のステップＳ１００に示すように、ＲＡＭ内の検出データやカウンタデータなどの初期化を行う。なお、後述する自己診断（ダイアグ）処理（Ｓ４００）に関連して記憶されるデータはこの初期化の対象外である。
【００３３】
このＳ１００での初期化処理後は、Ｓ２００にて燃料噴射（ＥＦＩ）、Ｓ３００にて点火時期（ＥＳＡ）の制御処理、Ｓ４００にてエンジン関連の自己診断（ダイアグ）処理、その他の処理を繰り返し実行する。
続いて、Ｓ４００でのダイアグ処理について図８及び図９を参照して詳しく説明する。
【００３４】
図８に示すダイアグ処理は、例えば６４ｍｓ毎に実行されるべース処理であるが、スロットルセンサ４５や水温センサ４４（図４参照）が異常かどうかを判断し（Ｓ４１０，Ｓ４３０）、異常を検出した場合には（Ｓ４１０：ＹＥＳ；Ｓ４３０；ＹＥＳ）、検出した異常対象を特定するコードをＲＡＭに記憶する（Ｓ４２０，Ｓ４４０）。また、エンジンの失火を検出したかどうかを判断し（Ｓ４５０）、失火を検出した場合には（Ｓ４５０：ＹＥＳ）、失火コードをＲＡＭに記憶する（Ｓ４６０）。なお、図８においては特には示していないが、エンジン関連部品、例えばインジェクタ４７や触媒などの不良状態などを判断して、異常を検出した場合には検出した異常対象を特定するコードをＲＡＭに記憶するようにしてもよい。
【００３５】
そして、これらの処理の中で新たな異常の記憶があったかを判断するために、記憶されているコード内容をチェックして変化があったかを判別し（Ｓ４７０）、変化があった場合は（Ｓ４７０：ＹＥＳ）、後述するトランスポンダ１０との通信処理にて使用される応答回数カウンタＣ（ＲＳＰ）を０にリセットする（Ｓ４８０）。なお、この応答回数カウンタＣ（ＲＳＰ）は、図７のＳ１００に示す初期化処理においても０にリセットされる。
【００３６】
また、図９に示すダイアグ処理も、例えば６４ｍｓ毎に実行されるべース処理であり、まず最初のステップＳ５１０では、図８のダイアグ処理にて異常を検出したかどうかを判断する。具体的には、Ｓ４１０，Ｓ４３０，Ｓ４５０にて肯定判断された場合には、異常があったと判断する。
【００３７】
異常がなければ（Ｓ５１０：ＮＯ）、そのまま処理ルーチンを終了するが、異常があった場合には（Ｓ５１０：ＹＥＳ）、それが検出済みの異常であるかどうかを判断する（Ｓ５２０）。つまり、検出した異常が、以前検出済みの異常であった場合には（Ｓ５２０：ＹＥＳ）、そのまま本処理ルーチンを終了する。一方、初めて検出した異常であった場合、つまりそれまではＲＡＭに異常コードが記憶されていなかった場合には（Ｓ５２０：ＮＯ）、Ｓ５３０へ移行して運転状態の記憶を行う。
【００３８】
このＳ５３０にて記憶される運転状態のデータ（フリーズフレームデー夕）は、車両を診断する際の異常解析用として使われるものであり、トランスポンダ１０からレシーバＢを介して管理センタＣ側（図１参照）に送られるデータの一部である。記憶される項目としては、エンジン回転数、吸入空気量、水温、スロットル開度、噴射量に関する制御データ、点火時期に関する制御データ、車両の走行距離、車両の位置などである。この内、走行距離及び車両の位置については、エンジンＥＣＵ３０から通信ライン５を介してメータＥＣＵ７０及びナビＥＣＵ５０に要求し、メータＥＣＵ７０からはその時点での累積走行距離、ナビＥＣＵ５０からはその時点での位置を出力してもらうことによって入手する。
【００３９】
エンジンＥＣＵ３０は、上述のようにしてダイアグに関する処理が実行されて異常の有無や異常の内容や異常発生時の運転状態が記憶されていくのであるが、さらに、通信ライン５を介してトランスポンダ１０からの要求があれば、異常情報のトランスポンダ１０への出力処理を実行する。
【００４０】
次に、図１０図及び図１１を参照してトランスポンダ１０からの要求に対する応答処理を説明する。
図１０に示す応答処理は、受信割込によって実行される処理であり、まずトランスポンダ１０からの要求であるかどうかを判断し（Ｓ６１０）、トランスポンダ１０からの要求であれば（Ｓ６１０：ＹＥＳ）、続いて、エンジン始動時か（Ｓ６２０）、エンジン高回転時か（Ｓ６３０）、エンジン高負荷時、つまりスロットル開度が所定量以上かどうか（Ｓ６４０）、をそれぞれ判断し、該当状態で無ければ順番に次のステップに進んでいく。そして、いずれかの状態に該当した場合、つまり、エンジン始動時であるか（Ｓ６２０：ＹＥＳ）、マイコン３１の動作が忙しいエンジン高回転状態（Ｓ６３０：ＹＥＳ）あるいは高負荷状態（Ｓ６４０：ＹＥＳ）である場合には、トランスポンダ１０からの要求を無視して本処理ルーチンを終了する。一方、いずれの状態でも無い場合には、次ステップのＳ６５０に移行する。
【００４１】
Ｓ６５０では、応答回数カウンタＣ（ＲＳＰ）が１０以上かどうかを判断し、応答回数カウンタＣ（ＲＳＰ）が１０以上でなければ（Ｓ６５０：ＹＥＳ）、出力要求フラグＦ（ＲＱＥ）を１にセットする（Ｓ６６０）。その後、受信割込による本応答処理ルーチンを終了する。ここでの応答回数カウンタＣ（ＲＳＰ）はトランスポンダ１０に応答した回数を計数するカウンタであって、トランスポンダ１０の異常などでトランスポンダ１０から頻繁に要求が来たときにはそれをキャンセルするために使われる。
【００４２】
一方、図１１に示す応答処理は、例えば６４ｍｓ毎に実行されるべース処理であり、まず最初のステップＳ７１０では、出力要求フラグＦ（ＲＱＥ）がセットされているかを確認し、出力要求フラグＦ（ＲＱＥ）がセットされていれば（Ｓ７１０：ＹＥＳ）、記憶されている異常情報（異常の有無、異常があれば異常対象のコード、その異常を検出した時点の運転状態データ）をトランスポンダ１０に対して出力する（Ｓ７２０）。したがって、受信割込での応答処理（図１０）のＳ６６０にて出力要求フラグＦ（ＲＱＥ）がセットされてから遅くとも６４ｍｓ以内に、異常情報の出力要求フラグＦ（ＲＱＥ）がセットされていることが判定されることとなる。
【００４３】
こうすることでノイズ環境の悪い中での通信を避けて誤データがトランスポンダ１０に送られてしまうことを防止すると共に、エンジンＥＣＵ３０の制御処理が忙しい時に異常情報のデータ出力により制御処理に遅れが生じてしまうようなことを防いでいる。特に、異常が検出されていて出力するデータが多量な場合には出力処理で他の処理が待たされる時間が長くなるが、こうすれば通常の制御に支障を与えない。また、異常情報の出力は特に急を要するものでは無いので、少しぐらい遅らせても問題とはならない。
【００４４】
Ｓ７２０での異常情報の出力後、応答回数カウンタＣ（ＲＳＰ）をカウントアップし（Ｓ７３０）、さらに出力要求フラグＦ（ＲＱＥ）をリセットして（Ｓ７４０）、６４ｍｓ毎に実行される本処理ルーチンを終了する。応答回数カウンタＣ（ＲＳＰ）は、エンジンＥＣＵ３０の初期化時と何らかの異常が検出されたときにクリアし、異常情報を出力する毎にカウントアップするので、異常状態に変化が無ければ１０回までしか出力しないようになり、トランスポンダ１０が異常となってたびたび要求してきたとしても、エンジンＥＣＵ３０への影響は無い。
【００４５】
次に、上述した構成のトランスポンダ１０にて実行される処理について、図１２〜図１５を参照して説明する。
まず、図１２に示す処理は、受信割込によって実行される処理であり、最初のステップＳ１０１０では、レシーバＢ（図１参照）からの異常情報の送信要求であるかどうかを判断する。異常情報の送信要求である場合には（Ｓ１０１０：ＹＥＳ）、前回の応答からの所定時間が経過しているかどうかを確認し（Ｓ１０２０）、経過していれば（Ｓ１０２０：ＹＥＳ）、Ｓ１０３０へ移行する。Ｓ１０３０では、各ＥＣＵ３０，５０，７０からのデータの受信完了を示す受信完了フラグＦ（ＲＳＰＥ），Ｆ（ＲＳＰＭ），Ｆ（ＲＳＰＮ）と、送信完了フラグＦ（ＲＳＰＴ）とを０にリセットする。続くＳ１０４０にて、出力要求フラグＦ（ＲＱＴ）を１にセットしてから、本処理ルーチンを終了する。
【００４６】
なお、前回の応答からの所定時間が経過していなければ（Ｓ１０２０：ＮＯ）、そのまま本処理ルーチンを終了させるが、エンジンＥＣＵ３０で検出される異常が急激に変化することは無いと想定されるので、前回の応答から所定時間経過した場合に要求に答えるようにしても特に問題はない。このようにしておけば、外部からの要求信号をたびたび受信したとしても、各ＥＣＵ３０，５０，７０との間の不要な通信を減らすことができる。なお、この所定時間としては、例えば１時間とか２時間といった程度の時間を設定すればよい。
【００４７】
一方、図１３，１４に示す出力要求処理は、例えば２５６ｍｓ毎に実行されるべース処理であり、まず最初のステップＳ１１１０では、出力要求フラグＦ（ＲＱＴ）がセットされているかどうかを判断する。上述した図１２のＳ１０４０にて出力要求フラグＦ（ＲＱＴ）がセットされるとこのＳ１１１０にて肯定判断となるため、Ｓ１１２０へ移行し、各ＥＣＵ３０，５０，７０にデータの出力要求を出す。
【００４８】
この出力要求に対して各ＥＣＵ３０，５０，７０から応答があった場合には図１５に示す受信データ格納処理が受信割込によって実行される。ここで、図１５の処理について説明する。
まず、最初のステップＳ１３１０においては、ＥＣＵからの応答であるかどうかを判断し、ＥＣＵからの応答であれば（Ｓ１３１０：ＹＥＳ）、エンジン、ナビ、メータのどのＥＣＵ３０，５０，７０からの応答であるかをＳ１３２０，Ｓ１３８０，Ｓ１４４０にて判断する。
【００４９】
エンジンＥＣＵ３０からの応答である場合には（Ｓ１３２０：ＹＥＳ）、データの受信完了を示す受信完了フラグＦ（ＲＳＰＥ）が１かどうかを判断し（Ｓ１３０）、受信完了フラグＦ（ＲＳＰＥ）が１でない場合には（Ｓ１３３０：ＮＯ）、Ｓ１３４０へ移行する。
【００５０】
Ｓ１３４０では、ＲＡＭ内の所定の記憶領域Ｄ（ＥＧ１）に受信データＤが記憶済みであるかどうかを判断し、記憶済みでなければ（Ｓ１３４０：ＮＯ）、その記憶領域Ｄ（ＥＧ１）に受信データを記憶する（Ｓ１３６０）。一方、記憶領域Ｄ（ＥＧ１）に受信データＤが記憶済みであれば（Ｓ１３４０：ＹＥＳ）、別の記憶領域Ｄ（ＥＧ２）に受信データが記憶済みであるかどうかを判断し（Ｓ１３５０）、記憶済みでなければ、その記憶領域Ｄ（ＥＧ２）に受信データを記憶する（Ｓ１３７０）。このようにして、エンジンＥＣＵ３０からの応答に応じて２回分の受信データがＲＡＭ内の記憶領域Ｄ（ＥＧ１），Ｄ（ＥＧ２）に記憶される。
【００５１】
メータＥＣＵ７０からの応答である場合にも（Ｓ１３８０：ＹＥＳ）、上述したエンジンＥＣＵ３０に対するＳ１３２０〜Ｓ１３７０の処理と同様の処理を実行する（Ｓ１３９０〜Ｓ１４３０）。その結果、メータＥＣＵ７０からの応答に応じて２回分の受信データがＲＡＭ内の記憶領域Ｄ（ＭＴ１），Ｄ（ＭＴ２）に記憶される。
【００５２】
ナビＥＣＵ５０からの応答である場合にも（Ｓ１４４０：ＹＥＳ）、上述したエンジンＥＣＵ３０に対するＳ１３２０〜Ｓ１３７０の処理と同様の処理を実行する（Ｓ１４５０〜Ｓ１４９０）。その結果、ナビＥＣＵ５０からの応答に応じて２回分の受信データがＲＡＭ内の記憶領域Ｄ（ＮＶ１），Ｄ（ＮＶ２）に記憶される。
【００５３】
なお、このときエンジンＥＣＵ３０は上述した異常に関する情報を出力し、メータＥＣＵ７０はトランスポンダ１０から要求を受けた時点での累積走行距離を出力し、ナビＥＣＵ５０はトランスポンダ１０から要求を受けた時点での車両位置を出力する。従って、レシーバＢには、異常が検出された時点の車両位置，累積走行距離と、レシーバＢが車両に異常情報の送信を要求した時点の車両位置，累積走行距離とが送られることとなるので、レシーバＢからデータを転送された管理センタＣでは、異常となってからの車両Ａの走行距離や移動状況がわかる。したがって、車両Ａのユーザーに対して適切な処置を取ることができる。この適切な処置とは、例えば警告を通知したり、場合によっては通信を介して車両Ａが安全な場所で停止した時点で強制的にエンジンを停止させるようにしたり、エンジンがユーザーにより切られた時に再度エンジンがかからなくなるようにするなどである。
【００５４】
図１５の処理は、図１３のＳ１１２０における各ＥＣＵ３０，５０，７０への出力要求に対して、各ＥＣＵ３０，５０，７０から応答があった場合に実行される受信データ格納処理に関するものであった。したがって、図１３のフローチャートの説明に戻り、Ｓ１１３０の内容から説明を再開する。
【００５５】
Ｓ１１３０では、エンジンＥＣＵ３０からの受信完了を示す受信完了フラグＦ（ＲＳＰＥ）が１であるかどうかを判断し、受信完了フラグＦ（ＲＳＰＥ）が１でない場合には（Ｓ１１３０：ＮＯ）、続くＳ１１４０にて、ＲＡＭ内の記憶領域Ｄ（ＥＧ１），Ｄ（ＥＧ２）にそれぞれ受信データが記憶されているかどうかを判断する。記憶済みである場合には（Ｓ１１４０：ＹＥＳ）、それら２つのデータが一致するかどうかを判断し、一致すれば（Ｓ１１５０：ＹＥＳ）、受信完了として受信完了フラグＦ（ＲＳＰＥ）を１にセットしてから（Ｓ１１６０）、Ｓ１１８０へ移行する。また、２つのデータが一致しない場合には（Ｓ１１５０：ＮＯ）、ＲＡＭ内の記憶領域Ｄ（ＥＧ１），Ｄ（ＥＧ２）に格納されている受信データを共にクリアしてから（Ｓ１１７０）、Ｓ１１８０へ移行する。
【００５６】
なお、受信完了フラグＦ（ＲＳＰＥ）が１である場合（Ｓ１１３０：ＹＥＳ）、または記憶領域Ｄ（ＥＧ１），Ｄ（ＥＧ２）にそれぞれ受信データが記憶されている状態ではない場合には（Ｓ１１４０：ＮＯ）、そのままＳ１１８０へ移行する。
【００５７】
Ｓ１１８０〜Ｓ１２２０はメータＥＣＵ７０からの受信データに関する処理であり、その内容は上述したエンジンＥＣＵ３０からの受信データに関するＳ１１３０〜Ｓ１１７０の処理と同様である。すなわち、メータＥＣＵ７０からの受信完了を示す受信完了フラグＦ（ＲＳＰＭ）が１でない場合には（Ｓ１１８０：ＮＯ）、続くＳ１１９０にて、記憶領域Ｄ（ＭＴ１），Ｄ（ＭＴ２）にそれぞれ受信データが記憶されているかどうかを判断する。記憶済みの場合（Ｓ１１９０：ＹＥＳ）、それら２つのデータが一致すれば（Ｓ１２００：ＹＥＳ）、受信完了フラグＦ（ＲＳＰＭ）を１にセットしてから（Ｓ１２１０）、Ｓ１２３０へ移行する。また、２つのデータが一致しない場合には（Ｓ１２００：ＮＯ）、記憶領域Ｄ（ＭＴ１），Ｄ（ＭＴ２）に格納されている受信データを共にクリアしてから（Ｓ１２２０）、図１４に示すＳ１２３０へ移行する。
【００５８】
Ｓ１２３０〜Ｓ１２７０はナビＥＣＵ５０からの受信データに関する処理であり、その内容は上述したエンジンＥＣＵ３０からの受信データに関するＳ１１３０〜Ｓ１１７０の処理と同様である。すなわち、ナビＥＣＵ５０からの受信完了を示す受信完了フラグＦ（ＲＳＰＮ）が１でない場合には（Ｓ１２３０：ＮＯ）、続くＳ１２４０にて、記憶領域Ｄ（ＮＶ１），Ｄ（ＮＶ２）にそれぞれ受信データが記憶されているかどうかを判断する。記憶済みの場合（Ｓ１２４０：ＹＥＳ）、それら２つのデータが一致すれば（Ｓ１２５０：ＹＥＳ）、受信完了フラグＦ（ＲＳＰＮ）を１にセットしてから（Ｓ１２６０）、Ｓ１２８０へ移行する。また、２つのデータが一致しない場合には（Ｓ１２５０：ＮＯ）、記憶領域Ｄ（ＮＶ１），Ｄ（ＮＶ２）に格納されている受信データを共にクリアしてから（Ｓ１２７０）、Ｓ１２８０へ移行する。
【００５９】
Ｓ１２８０では、全ての受信完了フラグＦ（ＲＳＰＥ），Ｆ（ＲＳＰＭ），Ｆ（ＲＳＰＮ）が１にセットされているかどうか判断し、セットされていれば（Ｓ１２８０：ＹＥＳ）、出力要求フラグＦ（ＲＱＴ）を０にリセットする（Ｓ１２９０）。つまり、各ＥＣＵ３０，５０，７０からの受信においては、２回分の受信データの一致を見ることで通信ライン上でノイズなどでデータが壊れること無く正常に受信できたことを判断して、データの信頼性を確保している。
【００６０】
また、いずれかの受信完了フラグＦ（ＲＳＰＥ），Ｆ（ＲＳＰＭ）,Ｆ（ＲＳＰＮ）がセットされていなければ（Ｓ１２８０：ＮＯ）、そのまま本処理ルーチンを終了するため、出力要求フラグＦ（ＲＱＴ）がセットされたままとなる。したがって、この図１３，１４に示す出力要求処理ルーチンが繰り返される毎（２５６ｍｓ毎）に各ＥＣＵ３０，５０，７０に出力要求が出される。そのため、相手側のＥＣＵ３０，５０，７０でトランスポンダ１０からの要求がエンジン状態や相手側ＥＣＵ３０，５０，７０の状況により無視されても、データの受信が完了されるまでトランスポンダ１０側から繰り返し要求するので、確実に各ＥＣＵ３０，５０，７０からデータを入手できる。
【００６１】
続いて、図１６に示す送信処理ルーチンについて説明する。この送信処理は、例えば２５６ｍｓ毎に実行されるベース処理であり、まず、最初のステップＳ１５１０ではレシーバＢへの送信完了を示す送信完了フラグＦ（ＲＳＰＴ）が１にセットされているかどうか判断する。そして、送信完了でなければ（Ｓ１５１０：ＮＯ）、続くＳ１５２０にて、全ての受信完了フラグＦ（ＲＳＰＥ），Ｆ（ＲＳＰＭ），Ｆ（ＲＳＰＮ）が１にセットされているかどうか判断する。そして、全ての受信完了フラグＦ（ＲＳＰＥ），Ｆ（ＲＳＰＭ），Ｆ（ＲＳＰＮ）が１にセットされていれば（Ｓ１５２０：ＹＥＳ）、診断データとしてＲＡＭ内の記憶領域Ｄ（ＥＧ１），Ｄ（ＭＴ１），Ｄ（ＮＶ１）に格納されている受信データを、ＥＥＰＲＯＭ１４（図３参照）に記憶しているＶＩＮコードと共に、レシーバＢに対して送信する。さらに、送信完了フラグＦ（ＲＳＰＴ）を１にセットして（Ｓ１５４０）、本処理ルーチンを終了する。
このように、本実施例の車両用診断装置によれば、車両Ａに搭載された各ＥＣＵ３０，５０，７０がそれぞれ管轄する各種機器の状態を診断し、その診断結果は、通信ライン５で接続されたトランスポンダ１０によって外部のレシーバＢに送信され、さらに管理センタＣへ転送される。このような前提において、例えばエンンジンＥＣＵ３０は、図１０に示すように、エンジン始動に起因して通信ライン５上にノイズが発生していると考えられる第１の不適期間中（Ｓ６２０：ＹＥＳ）、あるいはエンジン高回転あるいは高負荷時で制御に要する処理負荷が大きいと考えられる第２の不適期間中（Ｓ６３０：ＹＥＳ；Ｓ６４０：ＹＥＳ）においては、トランスポンダ１０へ異常情報を出力する要求があって（Ｓ６１０：ＹＥＳ）、その要求には対応しない。一方、第１あるいは第２の不適期間のいずれにも該当しない場合には（Ｓ６２０〜Ｓ６４０にていずれもＮＯ）、出力要求フラグＦ（ＲＱＥ）が１にセットされるので（Ｓ６６０）、図１１のＳ７１０において肯定判断となり、Ｓ７２０にて異常情報がトランスポンダ１０に出力される。
【００６２】
上述した第１の不適期間中は、エンジン始動に起因し、例えばスタータを回転駆動させていることなどよって通信ライン５上にノイズが発生している可能性が高い。そのため、この状態でエンジンＥＣＵ３０からトランスポンダ１０に異常情報が出力されると、通信ライン上５でデータ化けやデータ破壊が起こり、エンジンＥＣＵ３０から出力されたのとは違う誤った診断結果が管理センタＣに送信されてしまう可能性がある。したがって、このような期間中にトランスポンダ１０へ診断結果を出力する要求があっても、その要求には対応しない。
【００６３】
また、上述した第２の不適期間中は、各種機器への制御に要する処理負荷が所定以上大きい期間である。例えばエンジンＥＣＵ３０であれば、エンジンに対する各種制御が本来の仕事であり、優先度は相対的に高い。一方、異常情報の出力は相対的に見れば優先度が低い。つまり、エンジンＥＣＵ３０が優先度の高い処理を実行するのに忙しい（つまりマイコン３１の処理負荷が高い）期間中においては、その優先度の高い処理を抑えてまで、あえて異常情報の出力という優先度の低い処理を実行する必要性はない。したがって、このような期間中にトランスポンダ１０へ診断結果を出力する要求があっても、その要求には対応しない。つまり、エンジン回転数に対応した処理タイミングを設定すると、エンジン高回転状態においては単位時間当たりの処理量が多くなるからである。特にエンジンについてはリアルタイム処理が必要であり、診断結果の出力のように、緊急性が低い処理については後回しで一向に構わないのである。
【００６４】
ところで、各ＥＣＵ３０，５０，７０は、トランスポンダ１０からの出力要求に対応して異常情報を出力している。このトランスポンダ１０から各ＥＣＵ３０，５０，７０への出力要求は、管理センタＣ側、具体的にはレシーバＢからの送信要求に応じて出力要求している。このようにすれば、管理センタＣにおける管理に都合が良いタイミングで送信要求を出すことができるため、管理上の利点がある。一方、このように管理センタＣの都合に応じたタイミングで出された送信要求に応じてトランスポンダ１０が各ＥＣＵ３０，５０，７０に対して出力要求すると、その要求タイミングは、かならずしも各ＥＣＵ３０，５０，７０にとって適切なタイミングとは限らない。したがって、上述したように、第１不適期間中や第２不適期間中には対応しないようにすれば、不都合を解消できる。
［第２実施例］
次に、第２実施例について説明する。
【００６５】
基本的な構成及び基本的な処理については上述した第１実施例と全く同じであるので異なる点だけ説明する。具体的には、上記第１実施例において図１０及び図１１を参照して説明した応答処理に代えて、図１７及び図１８に示す応答処理を実行する点のみが異なっている。
【００６６】
つまり、第１実施例の場合には、図１０のフローチャートに示すように、トランスポンダ１０からの出力要求が来ると（Ｓ６１０：ＹＥＳ）、第１あるいは第２の不適期間中に該当しないかどうかの判断（Ｓ６２０〜Ｓ６４０）を必ず実行するようにしていた。そして、第１あるいは第２の不適期間のいずれにも該当しない場合には（Ｓ６２０〜Ｓ６４０にていずれもＮＯ）、出力要求フラグＦ（ＲＱＥ）が１にセットされ（Ｓ６６０）、図１１のフローチャートのＳ７１０において肯定判断となり、Ｓ７２０にて異常情報がトランスポンダ１０に出力されていた。つまり、受信割込による図１０の応答処理中において不適期間でない場合でしか出力要求フラグＦ（ＲＱＥ）が１にセットされないため、定期的に実行される図１１のＳ７１０における判断処理時に出力要求フラグＦ（ＲＱＥ）が１でないと異常情報の出力はされないこととなる。
【００６７】
それに対して、本第２実施例では、図１７のフローチャートに示すように、トランスポンダ１０から出力要求が来ると（Ｓ２６１０：ＹＥＳ）、上述の第１実施例の場合の不適期間中に該当するかどうかの判断（図１０のＳ６２０〜Ｓ６４０）は実行せず、応答回数カウンタＣ（ＲＳＰ）が１０未満であれば（Ｓ２６２０：ＮＯ）、必ず出力要求フラグＦ（ＲＱＥ）を１にセットする（Ｓ２６３０）。したがって、受信割込によってトランスポンダ１０から出力要求があれば、応答回数の条件だけを満たせば必ず出力要求フラグＦ（ＲＱＥ）が１にセットされ、その結果、図１８に示すように、定期的処理（例えば６４ｍｓ毎に実行されるベース処理）における最初のステップＳ２７１０では、必ず肯定判断となる。そして、続くＳ２７２０〜Ｓ２７４０において、第１あるいは第２の不適期間中に該当しないかどうかの判断を実行し、第１あるいは第２の不適期間のいずれにも該当しない場合には（Ｓ２７２０〜Ｓ２７４０にていずれもＮＯ）、異常情報がトランスポンダ１０に出力されることとなる（Ｓ２７５０）。
【００６８】
つまり、図１７の受信割込による処理では、第１あるいは第２の不適期間中であるかどうかの判断はせずに、出力要求があったこと自体は必ず記憶しておく。そして、定期的に実行する図１８の応答処理では、仮に第１あるいは第２の不適期間に該当しても、その後、いずれにも該当しない状況となった時点で、異常情報をトランスポンダ１０に出力する。
【００６９】
このようにすれば出力要求へのレスポンスは向上する。なぜなら、第１実施例のように、出力要求が来た時点で不適期間中であるかどうかを判断し、不適期間中であれば対応せず、不適期間中でなければ対応するだけの場合には、不適期間が過ぎていても、その後に出力要求が来るタイミングを待たなくてはならない。つまり、必ずしも不適期間が過ぎた直後に受信割込によって出力要求が来るとは限らないからである。それに対して、第２実施例の場合には、受信割込による出力要求があったこと自体は記憶しておき、定期的に実行する処理において（図１８）、第１あるいは第２の不適期間のいずれにも該当しない状況となった時点で出力要求に応じるようにしている。つまり、対応して良い状態になったら即座に応じることができ、出力要求へのレスポンスは向上する。
【００７０】
なお、上記各実施例では、第１及び第２の不適期間を設定したが、システム構成に応じて、いずれか一方の不適期間のみを設定するようにしてもよい。
【図面の簡単な説明】
【図１】 実施例の車両用診断装置の搭載された車両を含む診断システムの概略説明図である。
【図２】 実施例の車両内の概略的なシステム構成を示すブロック図である。
【図３】 実施例のトランスポンダの構成を示すブロック図である。
【図４】 実施例のエンジンＥＣＵの構成を示すブロック図である。
【図５】 実施例のナビＥＣＵの構成を示すブロック図である。
【図６】 実施例のメータＥＣＵの構成を示すブロック図である。
【図７】 実施例のエンジンＥＣＵで実行されるメイン処理を示すフローチャートである。
【図８】 実施例のエンジンＥＣＵで実行されるダイアグ処理を示すフローチャートである。
【図９】 実施例のエンジンＥＣＵで実行されるダイアグ処理を示すフローチャートである。
【図１０】 実施例のエンジンＥＣＵで受信割込にて実行される応答処理を示すフローチャートである。
【図１１】 実施例のエンジンＥＣＵでベース処理として実行される応答処理を示すフローチャートである。
【図１２】 実施例のトランスポンダで受信割込にて実行される処理を示すフローチャートである。
【図１３】 実施例のトランスポンダで実行される出力要求処理の前半を示すフローチャートである。
【図１４】 実施例のトランスポンダで実行される出力要求処理の後半を示すフローチャートである。
【図１５】 実施例のトランスポンダで受信割込にて実行される受信データ格納処理を示すフローチャートである。
【図１６】 実施例のトランスポンダで実行されるレシーバへの送信処理を示すフローチャートである。
【図１７】 第２実施例の場合のエンジンＥＣＵで実行される応答処理を示すフローチャートである。
【図１８】 第２実施例の場合のエンジンＥＣＵで実行される応答処理を示すフローチャートである。
【符号の説明】
３…バッテリ ４…イグニッションＳＷ
５…通信ライン ６…アクセサリＳＷ
１０…トランスポンダ １１…マイコン
１２…入出力回路 １３…電源回路
２０…アンテナ
３０…エンジンＥＣＵ ３１…マイコン
３２…入出力回路 ３３…メイン電源回路
３４…サブ電源回路 ４１…Ａ／Ｆセンサ
４２…回転センサ ４３…エアフローメータ
４４…水温センサ ４５…スロットルセンサ
４６…スタータＳＷ ４７…インジェクタ
４８…イグナイタ ４９…ＤＩＡＧテスタ
５０…ナビＥＣＵ ５１…マイコン
５２…入出力回路 ５３…電源回路
６０…ＧＰＳアンテナ ６２…受信機
６４…地図データ入力装置 ６６…表示モニタ
７０…メータＥＣＵ ７１…マイコン
７２…入出力回路 ７３…電源回路
８０…メータパネル ８５…車速センサ
Ａ…車両 Ｂ…レシーバ
Ｃ…管理センタ

Claims (8)

1. 車両に搭載されたエンジンを制御すると共に、前記エンジンのエミッションに関連する異常を診断し、その診断結果を記憶保持する、前記車両に搭載された制御ユニットと、
   当該制御ユニットと別のユニットとして前記車両に搭載され、前記制御ユニットと通信ラインで接続されており、前記制御ユニットに記憶保持された前記診断結果を前記制御ユニットから前記通信ラインを介して受信し、受信した前記診断結果を外部の管理センタ側へ無線通信にて送信する通信ユニットと、
   を備える車両用診断装置であって、
   前記通信ユニットは、前記無線通信による前記管理センタ側からの送信要求に応じ、前記制御ユニットに対して前記診断結果を出力するよう要求し、その後、前記制御ユニットから前記診断結果を受信するまで定期的に前記制御ユニットへ前記診断結果の出力を要求し、
   前記制御ユニットは、
   前記通信ユニットからの前記診断結果の出力要求を前記通信ラインを介して受信したときに、エンジンの制御に要する処理負荷が所定以上大きいと考えられる不適期間中か否かを判断し、前記不適期間と判断したときには、前記通信ユニットへ診断結果を出力する要求があっても当該要求には対応せず、
   一方、前記不適期間に該当しない場合には、前記診断結果の出力要求に応じて、前記診断結果を前記通信ユニットに出力するよう構成されていること、を特徴とする車両用診断装置。
2. 請求項１に記載の車両用診断装置において、前記制御ユニットは、前記不適期間中において前記診断結果の出力要求があった場合、その出力要求には対応しないが、出力要求があったこと自体は記憶しておき、その後、前記不適期間に該当しない状況となった時点で、前記記憶されている診断結果の出力要求に応じて、前記診断結果を前記通信ユニットに出力するよう構成されていること、を特徴とする車両用診断装置。
3. 請求項２に記載の車両用診断装置において、前記通信ユニットは、前記制御ユニットから前記診断結果が複数回出力され、かつ当該複数回の診断結果の内容が一致するまで、繰り返し前記制御ユニットへ出力要求し、前記診断結果が一致すると、その一致した診断結果を前記管理センタ側へ送信するよう構成されていること、を特徴とする車両用診断装置。
4. 請求項２又は３に記載の車両用診断装置において、前記制御ユニットは、前記通信ユニットからの出力要求に応じて診断結果を所定回数以上出力したにもかかわらず、さらに診断結果の出力要求が来た場合には、それ以降の出力要求には対応しないよう構成されていること、を特徴とする車両用診断装置。
5. 請求項１に記載の車両用診断装置において、前記制御ユニットは、所定の診断結果出力タイミングになった場合に、前記診断結果を出力するよう自ら要求することを特徴とする車両用診断装置。
6. 請求項１〜５のいずれかに記載の車両用診断装置において、前記通信ユニットが前記管理センタ側に送信する車両の診断結果に、当該車両固有の識別情報を含めること、を特徴とする車両用診断装置。
7. 請求項１〜６のいずれかに記載の車両用診断装置において、前記通信ユニットが前記管理センタ側に送信する車両の診断結果に、診断時における当該車両の走行距離あるいは車両位置の少なくとも一方を含めること、を特徴とする車両用診断装置。
8. 請求項１〜７のいずれかに記載の車両用診断装置において、前記制御ユニットの制御対象に少なくともエンジンが含まれていること、を特徴とする車両用診断装置。

Images