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

Description

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

Claims (9)

1. 車両に搭載されたエンジンを制御すると共に、前記エンジンのエミッションに関連する異常を診断する制御ユニットと、
   当該制御ユニットと同じく前記車両に搭載され、前記制御ユニットと通信ラインで接続されており、前記制御ユニットから得た診断結果を、外部の管理センタ側からの送信要求に応じて当該管理センタ側に送信する通信ユニットと、
   車載エンジンの駆動によって充電されるバッテリと、
   を備え、前記制御ユニット及び通信ユニットは、前記バッテリから供給された電力によって動作するよう構成された車両用診断装置であって、
   前記バッテリから前記通信ユニットへは通常動作に必要な電力が常時供給されるよう構成されており、一方、前記バッテリから前記制御ユニットへは通常動作に必要な電力が供給される状態と供給されない状態とが切り替え可能に構成されていると共に、
   前記車両の使用中は、前記バッテリから前記制御ユニットへ通常動作に必要な電力が供給される状態に設定し、一方、前記車両の不使用中は、前記バッテリから前記制御ユニットへ通常動作に必要な電力が供給されない状態に設定する供給状態設定手段とを備え、
   さらに、前記制御ユニットは通常動作に必要な電力が供給されて動作している際に前記通信ユニットに前記診断結果を送信するものであり、前記通信ユニットは、前記車両の不使用中に前記管理センタ側から送信要求があった場合には、前記制御ユニットが通常動作に必要な電力が供給されているときに前記制御ユニットから得ていた最新の診断結果を送信するよう構成されていること、を特徴とする車両用診断装置。
2. 請求項１に記載の車両用診断装置において、前記車両使用中は、前記制御ユニットが、自発的に、あるいは前記通信ユニットからの出力要求に応じて前記通信ユニットへ診断結果を出力するよう構成されており、当該車両使用中に最後に出力された診断結果が、前記通信ユニットの送信する前記最新の診断結果であること、を特徴とする車両用診断装置。
3. 請求項１に記載の車両用診断装置において、前記供給状態設定手段は、前記車両が使用状態から不使用状態に移行した場合、その移行時点から所定期間は前記制御ユニットの通常動作に必要な電力が供給されている状態を継続し、その後、通常動作に必要な電力が供給されない状態に切替設定するよう構成されていると共に、前記制御ユニットは、前記車両不使用状態への移行時点から所定期間中に診断結果を出力するよう構成されており、その所定期間中に出力された診断結果が、前記通信ユニットの送信する前記最新の診断結果であることを特徴とする車両用診断装置。
4. 請求項１〜３のいずれかに記載の車両用診断装置において、前記制御ユニットは、エンジン始動に起因して前記通信ライン上にノイズが発生していると考えられる第１の不適期間中と、各種機器への制御に要する処理負荷が所定以上大きいと考えられる第２の不適期間中との少なくとも一方を判断し、前記不適期間と判断したときには、前記通信ユニットへ診断結果を出力するタイミングであっても出力せず、一方、前記不適期間に該当しない場合には、前記診断結果の出力タイミングにおいて、前記診断結果を前記通信ユニットに出力するよう構成されていること、を特徴とする車両用診断装置。
5. 請求項１〜４のいずれかに記載の車両用診断装置において、前記車両使用中は、前記制御ユニットが、前記通信ユニットからの出力要求に応じて前記通信ユニットへ診断結果を出力するよう構成されており、前記通信ユニットは、前記制御ユニットから前記診断結果が複数回出力され、かつ当該複数回の診断結果の内容が一致するまで、繰り返し前記制御ユニットへ出力要求し、前記診断結果が一致すると、その一致した診断結果を前記管理センタ側へ送信するよう構成されていること、を特徴とする車両用診断装置。
6. 請求項１〜５のいずれかに記載の車両用診断装置において、前記制御ユニットは、前記通信ユニットからの出力要求に応じて診断結果を所定回数以上出力したにもかかわらず、さらに診断結果の出力要求が来た場合には、それ以降の出力要求には対応しないよう構成されていること、を特徴とする車両用診断装置。
7. 請求項１〜６のいずれかに記載の車両用診断装置において、前記通信ユニットが前記管理センタ側に送信する車両の診断結果に、当該車両固有の識別情報を含めること、を特徴とする車両用診断装置。
8. 請求項１〜７のいずれかに記載の車両用診断装置において、前記通信ユニットが前記管理センタ側に送信する車両の診断結果に、診断時における当該車両の走行距離あるいは車両位置の少なくとも一方を含めること、を特徴とする車両用診断装置。
9. 請求項１〜８のいずれかに記載の車両用診断装置において、前記制御ユニットの制御対象に少なくともエンジンが含まれていること、を特徴とする車両用診断装置。

Images