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