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

Abstract

(57)【要約】 【課題】 管理センタ側からの送信要求がいつ来ても応
答できるように構成されていながら、バッテリ消耗を極
力少なくした車両用診断装置を提供する。 【解決手段】 バッテリからトランスポンダ１０へは電
力が常時供給されるため、管理センタ側からの送信要求
がいつ来ても、それに応じて診断結果を送信できる。一
方、バッテリからエンジンＥＣＵ３０へは、ＩＧＳＷが
オン状態で通常動作に必要な電力が供給され、オフ状態
では供給されない。そのため、車載エンジンが停止して
おりバッテリが充電されない状況では、エンジンＥＣＵ
３０への電力供給が低減され、その分のバッテリ消耗が
少なくなる。但し、車両不使用中に管理センタ側から送
信要求があった場合、その時点でエンジンＥＣＵ３０か
らの情報は取得できない。したがって、トランスポンダ
１０は、車両不使用状態になる以前の車両使用中にエン
ジンＥＣＵ３０から得た最新の情報を送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、車両に搭載された
各種機器の状態を診断する車両用診断装置であって、特
に、その診断結果を外部の管理センタ側へ送信可能にさ
れた車両用診断装置に関する。

【０００２】

【従来の技術】車両のメインテナンスは、例えば、日本
では一定期間ごとの車検に応じてユーザーが整備工場に
て検査及び修理をしてもらい陸運局に報告するようにし
ており、また米国では監督局からの定期的な通知に従い
ユーザーが整備工場で検査及び修理を受け基準を満たし
ていることを監督局に返信するというようにして管理さ
れている。

【０００３】ところがこのような方式では、特に故障や
不良が無く整備の必要の無い車両まで一律に管理してい
るため、監督局（陸運局）での管理の工数が多くなって
いると共に、ユーザにとっても煩わしいものである。こ
のようなことから、車両側にて検査に関わる情報（例え
ば、エンジン関連部品の異常に関する情報）を車両から
無線通信にて監督局側としての管理センタ側に送信し、
特に修理が必要な車両に対してそのユーザーに指示し報
告させるようにすることが考えられる。

【０００４】

【発明が解決しようとする課題】このようなシステムと
した場合、車両側では無線通信を送受信するための装置
（以下、トランスポンダという）を装備すると共に、検
査に関わる情報を車載の制御ユニットで得て、制御ユニ
ットからトランスポンダに通信するよう構成する必要が
生じる。

【０００５】しかしながら、管理センタ側から車両に対
して、検査に関わる情報の送信要求が出され、その送信
要求を受けたトランスポンダが検査に関わる情報を管理
センタ側に送信するというような、車両側が受動的なシ
ステムとした場合には、次のような不都合が生じる。つ
まり、管理センタ側からの送信要求はいつ送られてくる
か判らないため、要求がいつ来ても応答できるように車
両側にシステムを構築しておく必要がある。このために
は、例えば車載のトランスポンダや制御ユニットを常時
オン状態にしておけばよいが、一般的にエンジン停止状
態では車載バッテリに対して充電がされないため、上記
「常時オン」しておく方法では、トランスポンダや制御
ユニットによって消費される電力によって短期間でバッ
テリが消耗してしまうこととなる。

【０００６】そこで、本発明は、管理センタ側からの送
信要求がいつ来ても応答できるように構成されていなが
ら、バッテリ消耗を極力少なくした車両用診断装置を提
供することを目的とする。

【０００７】

【課題を解決するための手段及び発明の効果】上記目的
を達成するためになされた請求項１記載の車両用診断装
置によれば、車両に搭載された各種機器を制御する制御
ユニットが各種機器の状態を診断し、その診断結果は、
制御ユニットと通信ラインで接続された通信ユニットに
よって外部の管理センタ側へ送信される。これら制御ユ
ニット及び通信ユニットは、車載エンジンの駆動によっ
て充電されるバッテリから供給された電力によって動作
するが、バッテリから通信ユニットへは通常動作に必要
な電力が常時供給されるよう構成されているため、通信
ユニットは、管理センタ側からの送信要求がいつ来て
も、それに応じて診断結果を管理センタ側に送信するこ
とができる。

【０００８】一方、バッテリから制御ユニットへは通常
動作に必要な電力が供給される状態と供給されない状態
とが切り替え可能に構成されており、供給状態設定手段
は、車両の使用中は、バッテリから制御ユニットへ通常
動作に必要な電力が供給される状態に設定し、一方、車
両の不使用中は、バッテリから制御ユニットへ通常動作
に必要な電力が供給されない状態に切替設定する。した
がって、車両が不使用中で車載エンジンが停止しており
バッテリが充電されない状況では制御ユニットへの電力
供給が低減（停止も含む）されるため、その分のバッテ
リ消耗が少なくなる。

【０００９】つまり、いつ来るか判らない管理センタ側
からの送信要求に対して、いつ来てもそれに応答できる
ようにするため、通信ユニットに加えて制御ユニットま
でも通常動作できるように準備しておくのはバッテリ消
耗の点からすれば非合理的である。そこで、上記送信要
求に応答するためだけであれば最低限通信ユニットだけ
動作できればよいので、制御ユニット側への通常動作可
能な電力の供給はしないようにする。

【００１０】但し、車両が不使用中は制御ユニットへ通
常動作可能な電力が供給されないため、その車両不使用
中に管理センタ側から送信要求があった場合には、その
時点で制御ユニットから診断結果を取得することはでき
ない。したがって、通信ユニットは、その時点で制御ユ
ニットから診断結果を取得する代わりに、車両が不使用
状態になる以前の車両使用中に制御ユニットから得た最
新の診断結果を送信する。

【００１１】これによって、管理センタ側からの送信要
求がいつ来ても応答できるように構成されていながら、
バッテリ消耗を極力少なくした車両用診断装置を提供す
ることができる。なお、「通常動作に必要な電力が供給
されない状態」としたのは、次の理由からである。例え
ばマイクロコンピュータにおけるＲＡＭ内のデータを車
両不使用状態でも保持しておくためには、やはり電力供
給はされる必要がある。しかし、これは例えば制御ユニ
ットとしてのエンジンＥＣＵを考えると、通常のエンジ
ン制御を実行したりするのに必要な電力までは不要であ
る。したがって、もちろんこのようなＲＡＭ内のデータ
を保持したりする必要がなければ、電力供給を完全に停
止してもよいが、上述の事情も含め、「通常動作に必要
な電力が供給されない状態」としたのである。

【００１２】また、車両の状態として「使用中」と「不
使用中」と表現したのは次の理由からである。つまり、
エンジンが駆動していれば必ず使用中ではあるが、例え
ばエンジンが駆動していなくても、車載機器のカーナビ
ゲーションシステム等を使用することもできる。このカ
ーナビゲーションシステムは一般的な自動車においては
アクセサリスイッチがオンされていれば使用できる。し
たがって、ここではそれらも含める意味で使用中・不使
用中という語を用いた。具体的には、一般的な自動車に
おいては、ＯＦＦ・ＡＣＣ・ＯＮ・ＳＴＡＲＴの４位置
を持つキースイッチが多いので、この場合にはＯＦＦだ
けが「不使用中」であり、残りのＡＣＣ・ＯＮ・ＳＴＡ
ＲＴの場合は全て「使用中」と考えることができる。つ
まり、車両の利用者が、バッテリにて動作する車載装備
を使用する場合が使用中である。したがって、キースイ
ッチがＯＦＦの状態にて何らかの車載装備を使用したと
しても、それは使用中ではなく「不使用中」である。

【００１３】なお、上述した車両不使用中に通信ユニッ
トが送信する「最新の診断結果」については、例えば、
請求項２に示すように、車両使用中は、制御ユニットが
自発的に、あるいは通信ユニットからの出力要求に応じ
て通信ユニットへ診断結果を出力するようにし、その車
両使用中に最後に出力された診断結果を「最新の診断結
果」としてもよい。この場合、例えば、制御ユニットか
ら定期的に診断結果を出力し、通信ユニットではそれを
更新記憶しておくようにすれば、通信ユニットに記憶さ
れたものがそのまま「最新の診断結果」になる。

【００１４】あるいは、請求項３に示すように、供給状
態設定手段によって、車両が使用状態から不使用状態に
移行した場合、その移行時点から所定期間は制御ユニッ
トの通常動作に必要な電力が供給されている状態を継続
することで、その所定期間中に制御ユニットから診断結
果を出力させ、その所定期間中に出力された診断結果を
「最新の診断結果」としてもよい。この場合には、「最
新の診断結果」としてより適切なものが得られるため、
適切な診断のためには好ましい。つまり、制御ユニット
から定期的に出力される診断結果の内の最後のものを
「最新の診断結果」とする場合、出力間隔によっては、
車両が使用状態から不使用状態に切り替わる直前の状態
を反映した診断結果とはならない可能性もある。例え
ば、最後の診断結果を出力した後でも車両が走行してい
る場合もあり、その走行によって異常が発生する可能性
もある。請求項３に示すようにすれば、このような不都
合は解消される。

【００１５】ところで、制御ユニットから通信ユニット
へ出力される診断結果は、基本的には車両使用中に出力
されるものである。そのため、例えば診断結果の出力タ
イミングがエンジン始動時に重なると、通信状態が悪い
状態なので通信ユニットと制御ユニットとの間の通信ラ
イン上にノイズが乗り、例えば通信ユニットに入力され
た信号が制御ユニットから出力された信号と異なってし
まう可能性がある。その場合には、誤った情報が管理セ
ンタ側に送られてしまう。また、制御ユニットのマイク
ロコンピュータ（以下「マイコン」と略記する）が忙し
い時、例えばエンジン制御ユニットであれば、エンジン
高回転時や高負荷時などにおいては、通信ユニットへの
出力データ量が多くなると、本来の制御処理に影響を与
える可能性がある。

【００１６】したがって、上述したバッテリ消耗の低減
等の効果を得ながら、さらにこのような不都合を防止す
るためには、上述した車両用診断装置の制御ユニット
が、診断結果を通信ユニットに出力するには不適切な期
間を判別し、その期間中は出力しないようにすることが
好ましい。

【００１７】具体的には、制御ユニットが、エンジン始
動に起因して通信ライン上にノイズが発生していると考
えられる第１の不適期間中と、各種機器への制御に要す
る処理負荷が所定以上大きいと考えられる第２の不適期
間中との少なくとも一方を判断し、前記不適期間と判断
したときは、所定の通信ユニットへの出力タイミングで
あっても、診断結果を出力しないようにする。一方、不
適期間に該当しない場合には、所定の出力タイミングに
おいて診断結果を通信ユニットに出力する。

【００１８】上述した第１の不適期間中は、エンジン始
動に起因し、例えばスタータを回転駆動させていること
などよって通信ライン上にノイズが発生している可能性
が高い。そのため、この状態で制御ユニットから通信ユ
ニットに診断結果が出力されると、それらユニット間の
通信ライン上でデータ化けやデータ破壊が起こり、制御
ユニットから出力されたのとは違う誤った診断結果が管
理センタに送信されてしまう可能性がある。したがっ
て、このような不適期間中に所定の出力タイミングが来
ても診断結果は出力しない。

【００１９】また、上述した第２の不適期間中は、各種
機器への制御に要する処理負荷が所定以上大きい期間で
ある。各種機器への制御は制御ユニットの本来の仕事で
あり、優先度は相対的に高く、一方、診断結果の出力は
相対的に見れば優先度が低い。つまり、制御ユニットが
優先度の高い処理を実行するのに忙しい（つまりマイコ
ンの処理負荷が高い）期間中においては、その優先度の
高い処理を抑えてまで、あえて診断結果の出力という優
先度の低い処理を実行する必要性はない。したがって、
このような期間中に所定の出力タイミングが来ても診断
結果は出力しない。なお、処理負荷が大きい状態とは、
具体的には制御対象がエンジンであれば、そのエンジン
回転数が高い状態などである。つまり、回転数に対応し
た処理タイミングを設定すると、エンジン高回転状態に
おいては単位時間当たりの処理量が多くなるからであ
る。特にエンジンについてはリアルタイム処理が必要で
あり、診断結果の出力のように、緊急性が低い処理につ
いては後回しで一向に構わないのである。

【００２０】ところで、「所定の出力タイミング」は、
例えば通信ユニットからの出力要求を受けた制御ユニッ
トが診断結果を出力するのであれば、その通信ユニット
からの出力要求タイミングに基づくこととなる。そし
て、この方法であれば、管理センタ側からの送信要求に
応じ、通信ユニットが制御ユニットに対して診断結果を
出力するよう要求することが考えられる。このようにす
れば、管理センタにおける管理に都合が良いタイミング
で送信要求を出すことができるため、管理上の利点があ
る。

【００２１】そして、このように、管理センタ側からの
送信要求に応じ、通信ユニットが制御ユニットに対して
診断結果を出力するよう要求する場合には、制御ユニッ
トが次のように対応することも考えられる。つまり、不
適期間中において診断結果の出力要求があった場合に
は、その要求には対応しないが、要求があったこと自体
は記憶しておき、その後、不適期間に該当しない状況と
なった時点で、記憶されている診断結果の出力要求に応
じて、診断結果を通信ユニットに出力するのである。こ
のようにすれば出力要求へのレスポンスは向上する。な
ぜなら、出力要求が来た時点で不適期間中であるかどう
かを判断し、不適期間中であれば対応せず、不適期間中
でなければ対応するだけの場合には、不適期間が過ぎて
いても、その後に出力要求が来るタイミングを待たなく
てはならない。つまり、必ずしも不適期間が過ぎた直後
に出力要求が来るとは限らないからである。それに対し
て、診断結果の出力要求があったこと自体は記憶してお
き、その後、不適期間に該当しない状況となった時点で
出力要求に応じるようにすれば、対応して良い状態にな
ったら即座に応じることができるため、出力要求へのレ
スポンスは向上する。

【００２２】そして、このように、制御ユニットが、通
信ユニットからの出力要求に応じて通信ユニットへ診断
結果を出力することを前提とした場合には、通信ユニッ
トが、制御ユニットから診断結果が複数回出力され、か
つ複数回の診断結果の内容が一致するまで、繰り返し制
御ユニットへ出力要求し、診断結果が一致すると、その
一致した診断結果を管理センタ側へ送信するよう構成す
ることが考えられる。制御ユニットから通信ユニットに
出力された診断結果の正確性向上を期すためには、有効
である。

【００２３】また、通信ユニットに異常がある場合の制
御ユニット側の対処としては、次のようにすることも有
効である。つまり、通信ユニットからの要求に応じて診
断結果を所定回数以上出力したにもかかわらず、さらに
診断結果の出力要求が来た場合には、それ以降の要求に
は対応しないようにするのである。

【００２４】なお、車両用診断装置は最終的には通信ユ
ニットが管理センタ側に車両の診断結果を送信すること
となるが、その診断結果に、車両固有の識別情報を含め
ることも考えられる。これは、診断結果がどの車両に対
応するものなのかを容易に判別できる点で有効である。
もちろん、これ以外にも、診断結果を送信してきた車両
を特定する方法は考えられるが、診断結果に含まれてい
れば、特定が容易にできる。

【００２５】また、診断結果には、診断対象の機器に関
する情報だけでなく、付帯情報として、例えば診断時に
おける車両の走行距離あるいは車両位置の少なくとも一
方を含めることも有効である。つまり、その診断対象の
機器が搭載された車両自体の走行距離に応じても診断結
果の分析は変わる可能性があるからである。また、車両
位置についても同様である。

【００２６】以上説明した車両用診断装置においては、
車載の様々な機器について、制御ユニットの制御対象と
できる。

【００２７】

【発明の実施の形態】以下、本発明が適用された実施例
について図面を用いて説明する。なお、本発明の実施の
形態は、下記の実施例に何ら限定されることなく、本発
明の技術的範囲に属する限り、種々の形態を採り得るこ
とは言うまでもない。

【００２８】図１は、実施例の車両用診断装置の搭載さ
れた車両を含む診断システムの概略構成を示す図であ
る。当該システムの概略を説明する。監督局をなす管理
センタＣは、レシーバＢを介して複数の車両Ａからそれ
ぞれエミッション（排ガス）に関連するデータ、エンジ
ンの故障に関するデータ等を無線通信にて入手する。管
理センタＣは不具合のある車両Ａを特定して、その車両
保有者に対して車両Ａの修理、改善を促す。なお、この
車両Ａの修理、改善を促すのは、例えば書類を郵送する
など種々の方法が採用できる。

【００２９】図２は、車両Ａ内の概略的なシステム構成
を示すブロック図である。トランスポンダ１０はレシー
バＢからの要求を受け、車載制御ユニットであるエンジ
ンＥＣＵ３０、ナビＥＣＵ５０、メータＥＣＵ７０から
必要な情報を通信ライン５を介して入手し、その入手し
た情報をレシーバＢ（図１参照）に対して送信する。

【００３０】エンジンＥＣＵ３０は、エンジンの制御を
司ると共に、エンジンのエミッションに関連する異常を
自己診断し、トランスポンダ１０の要求に応じてその情
報をトランスポンダ１０に送信する。また、ナビＥＣＵ
５０、メータＥＣＵ７０は、それぞれナビゲーション制
御、メータ表示制御を実行すると共に、エンジンＥＣＵ
３０が自己診断にて何らかの異常を検出したときに、エ
ンジンＥＣＵ３０から出される要求に応じてそれぞれ車
両の走行距離，車両位置をエンジンＥＣＵ３０に出力
し、またトランスポンダ１０からの要求が来たときにそ
のときの走行距離，車両位置をトランスポンダ１０に出
力する。

【００３１】図３〜図６はトランスポンダ１０，及び各
車載制御ユニットである各ＥＣＵ３０，５０，７０の構
成を示すブロック図である。まず、図３を参照してトラ
ンスポンダ１０について説明する。トランスポンダ１０
が動作するための電力を供給する電源回路１３には、バ
ッテリ３から常時電力が供給されているので、車両のキ
ーＳＷの状態に関係なく動作する。マイコン１１内のＣ
ＰＵは、同じくマイコン１１内のＲＯＭに記憶された制
御プログラムに従い、アンテナ２０を介して外部から来
る要求に応じた処理を実行する。また、マイコン１１内
のＲＡＭはエンジンＥＣＵ３０などからのデータ等を一
時的に記憶する。なお、入出力回路１２がアンテナ２０
及び通信ライン５と接続されており、この入出力回路１
２を介して入出力されたデータはマイコン１１内のＩ／
Ｏを介してＣＰＵなどをやりとりされる。また、マイコ
ン１１にはＥＥＰＲ０Ｍ１４が接続されていて、車両固
有の識別番号（ＶＩＮコード）が記憶されている。

【００３２】次に、図４を参照してエンジンＥＣＵ３０
について説明する。エンジンＥＣＵ３０は、メイン電源
回路３３がイグニッションＳＷ４を介してバッテリ３と
接続されており、基本的には、イグニッションＳＷ４が
投入されることによってメイン電源回路３３から電源が
供給されて動作する。但し、イグニッションＳＷ４を介
さずバッテリ３と直接つながるサブ電源回路３４からマ
イコン３１に電源供給されることで、マイコン３１のＲ
ＡＭのデータがイグニッションＳＷ４のオフ後も保持さ
れることとなる。

【００３３】なお、バッテリ３は、エンジンが駆動する
ことによって充電される構成となっている。具体的に
は、エンジンによって駆動されるオルタネータを備えて
おり、そのオルタネータがエンジン回転数に応じた電力
を発生し、発生した電力がバッテリ３に供給されるよう
構成されている。この供給された電力によってバッテリ
３が充電される。

【００３４】マイコン３１では、ＣＰＵがＲＯＭに記憶
された制御プログラムに従い、入出力回路３２及びマイ
コン３１内のＩ／Ｏを介して入力したセンサ信号に基づ
いてエンジンが最適な動作をするようインジェクタ４７
やイグナイタ４８を制御する信号を出力する。また、エ
ンジンのエミッションに関連する異常を自己診断してエ
ンジンの動作やセンサ４１〜４６の異常等を診断し、外
部（ＤＩＡＧテスタ４９やトランスポンダ１０）からの
要求に応じて診断結果のデータを出力する。また、マイ
コン３１内のＲＡＭは、ＣＰＵでの演算処理に使うセン
サデータ、演算にて求まった制御データ、あるいは上記
診断にて得た種々の診断データ等を保持している。

【００３５】なお、入出力回路３２に接続されているセ
ンサ４１〜４６は、空燃比（Ａ／Ｆ）センサ４１、エン
ジンの回転数を検出する回転センサ４２、エアフローメ
ータ４３、水温センサ４４、スロットルセンサ４５、ス
タータＳＷ４６である。次に、図５を参照してナビＥＣ
Ｕ５０について説明する。

【００３６】ナビＥＣＵ５０は、電源回路５３がアクセ
サリＳＷ６を介してバッテリ３と接続されており、アク
セサリＳＷ６が投入されることによってマイコン５１や
入出力回路５２が動作する。この入出力回路５２には、
受信機６２、地図データ入力装置６４及び表示モニタ６
６が接続されている。受信機６２にはＧＰＳアンテナ６
０が接続されており、これらは、ＧＰＳ衛星からの電波
に基づいて車両の位置を検出するＧＰＳ（Global Posit
ioning System ）のための構成である。また、地図デー
タ入力装置６４は、位置検出の精度向上のためのいわゆ
るマップマッチング用データ、地図データを含む各種デ
ータを記憶媒体から入力するための装置である。このた
めの記憶媒体としては、そのデータ量からＣＤ−ＲＯＭ
を用いるのが一般的であるが、例えばＤＶＤやメモリカ
ード等の他の媒体を用いても良い。また、表示モニタ６
６は地図や誘導経路などを表示するためのものであり、
本実施例では、利用者からの指示を入力する機能も備え
ている。

【００３７】マイコン５１では、ＣＰＵがＲＯＭの記憶
された制御プログラムに従い、入出力回路５２及びマイ
コン５１内のＩ／Ｏを介して入力した地図データ入力装
置６４からの地図データや受信機６２からの信号をもと
に、表示モニタ６６から得られる利用者からの指示情報
に対応して表示処理を実行し、表示モニタ６６に利用者
が所望する情報を表示させる。また、マイコン５１は、
エンジンＥＣＵ３０やトランスポンダ１０からの要求が
通信ライン５を介して来たときには、受信した時点の車
両位置を、要求してきたエンジンＥＣＵ３０やトランス
ポンダ１０に出力することができる。

【００３８】次に、図６を参照してメータＥＣＵ７０に
ついて説明する。メータＥＣＵ７０は、電源回路７３が
アクセサリＳＷ６を介してバッテリ３と接続されてお
り、アクセサリＳＷ６が投入されることによってマイコ
ン７１や入出力回路７２が動作する。この入出力回路７
２には、メータパネル８０や車速センサ８５などが接続
されている。

【００３９】マイコン７１では、ＣＰＵがＲＯＭに記憶
された制御プログラムに従い、車速センサ８５などのセ
ンサ信号を入力し、メータパネル８０に車速などの情報
を表示させる。また、マイコン７１は、エンジンＥＣＵ
３０やトランスポンダ１０からの要求が通信ライン５を
介して来たときには、受信した時点の車両の累積走行距
離を、要求してきたエンジンＥＣＵ３０やトランスポン
ダ１０に出力することができる。

【００４０】次に、上述した構成のエンジンＥＣＵ３０
にて実行される処理について、図７〜図１１を参照して
説明する。まず、エンジンＥＣＵ３０では、イグニッシ
ョンＳＷ４（図４参照）が投入されることによって動作
を開始すると、図７のメイン処理の最初のステップＳ１
００に示すように、ＲＡＭ内の検出データやカウンタデ
ータなどの初期化を行う。なお、後述する自己診断（ダ
イアグ）処理（Ｓ４００）に関連して記憶されるデータ
はこの初期化の対象外である。

【００４１】このＳ１００での初期化処理後は、Ｓ２０
０にて燃料噴射（ＥＦＩ）、Ｓ３００にて点火時期（Ｅ
ＳＡ）の制御処理、Ｓ４００にてエンジン関連の自己診
断（ダイアグ）処理、その他の処理を繰り返し実行す
る。続いて、Ｓ４００でのダイアグ処理について図８及
び図９を参照して詳しく説明する。

【００４２】図８に示すダイアグ処理は、例えば６４ｍ
ｓ毎に実行されるべース処理であるが、スロットルセン
サ４５や水温センサ４４（図４参照）が異常かどうかを
判断し（Ｓ４１０，Ｓ４３０）、異常を検出した場合に
は（Ｓ４１０：ＹＥＳ；Ｓ４３０；ＹＥＳ）、検出した
異常対象を特定するコードをＲＡＭに記憶する（Ｓ４２
０，Ｓ４４０）。また、エンジンの失火を検出したかど
うかを判断し（Ｓ４５０）、失火を検出した場合には
（Ｓ４５０：ＹＥＳ）、失火コードをＲＡＭに記憶する
（Ｓ４６０）。なお、図８においては特には示していな
いが、エンジン関連部品、例えばインジェクタ４７や触
媒などの不良状態などを判断して、異常を検出した場合
には検出した異常対象を特定するコードをＲＡＭに記憶
するようにしてもよい。

【００４３】また、図９に示すダイアグ処理も、例えば
６４ｍｓ毎に実行されるべース処理であり、まず最初の
ステップＳ５１０では、図８のダイアグ処理にて異常を
検出したかどうかを判断する。具体的には、Ｓ４１０，
Ｓ４３０，Ｓ４５０にて肯定判断された場合には、異常
があったと判断する。

【００４４】異常がなければ（Ｓ５１０：ＮＯ）、その
まま処理ルーチンを終了するが、異常があった場合には
（Ｓ５１０：ＹＥＳ）、それが検出済みの異常であるか
どうかを判断する（Ｓ５２０）。つまり、検出した異常
が、以前検出済みの異常であった場合には（Ｓ５２０：
ＹＥＳ）、そのまま本処理ルーチンを終了する。一方、
初めて検出した異常であった場合、つまりそれまではＲ
ＡＭに異常コードが記憶されていなかった場合には（Ｓ
５２０：ＮＯ）、Ｓ５３０へ移行して運転状態の記憶を
行う。

【００４５】このＳ５３０にて記憶される運転状態のデ
ータ（フリーズフレームデー夕）は、車両を診断する際
の異常解析用として使われるものであり、トランスポン
ダ１０からレシーバＢを介して管理センタＣ側（図１参
照）に送られるデータの一部である。記憶される項目と
しては、エンジン回転数、吸入空気量、水温、スロット
ル開度、噴射量に関する制御データ、点火時期に関する
制御データ、車両の走行距離、車両の位置などである。
この内、走行距離及び車両の位置については、エンジン
ＥＣＵ３０から通信ライン５を介してメータＥＣＵ７０
及びナビＥＣＵ５０に要求し、メータＥＣＵ７０からは
その時点での累積走行距離、ナビＥＣＵ５０からはその
時点での位置を出力してもらうことによって入手する。
なお、エンジンＥＣＵ３０からの要求に応じてメータＥ
ＣＵ７０がその時点での累積走行距離を出力する処理は
図１５、エンジンＥＣＵ３０からの要求に応じてナビＥ
ＣＵ５０がその時点での位置情報を出力する処理は図１
７を参照して後述する。

【００４６】エンジンＥＣＵ３０は、上述のようにして
ダイアグに関する処理が実行されて異常の有無や異常の
内容や異常発生時の運転状態が記憶されていくのである
が、本実施例におけるエンジンＥＣＵ３０は、イグニッ
ションＳＷ４がオフされた後は上述のように動作を停止
する。そのため、トランスポンダ１０がレシーバＢから
要求をいつでも受け付けることができるよう、エンジン
ＥＣＵ３０はその動作中の所定間隔毎に、自らから記憶
している異常に関する上記情報を通信ライン５を介して
トランスポンダ１０へ出力する。

【００４７】そのトランスポンダ１０への異常情報出力
処理について図１０を参照して説明する。図１０に示す
異常情報出力処理は、例えば１０２４ｍｓ毎に実行され
るべース処理であり、まず送信待ちカウンタＣａが６０
以上であるかどうかを判断している（Ｓ６１０）。そし
て、送信待ちカウンタＣａが６０以上であれば（Ｓ６１
０：ＹＥＳ）、Ｓ６２０へ移行し、Ｓ６２０〜Ｓ６４０
の各条件が成立すればＳ６５０にて異常情報をトランス
ポンダ１０へ出力するが、送信待ちカウンタＣａが６０
未満であれば（Ｓ６１０：ＮＯ）、その送信待ちカウン
タＣａをインクリメント（Ｃａ←Ｃａ＋１）するだけで
（Ｓ６７０）、本処理を終了する。

【００４８】このように、本異常情報出力処理では、異
常に関する情報は頻繁には変化するものではないとの考
えに基づき、エンジンＥＣＵ３０が実行する各種のエン
ジン制御処理よりも低い優先度の処理とするために、そ
の実行間隔（１０２４ｍｓ毎）を他の処理よりも長く設
定して処理負荷を低減している。さらに、通信ライン５
上の通信量を減らすため、上述したＳ６１０に示すよう
に、送信待ちカウンタＣａにて６０回毎に送信してい
る。つまり、この実施例では約１分毎に異常に関する情
報が通信ライン５を介してエンジンＥＣＵ３０からトラ
ンスポンダ１０へ送信されることとなる。

【００４９】続いて、送信待ちカウンタＣａが６０以上
である場合（Ｓ６１０：ＹＥＳ）に移行するＳ６２０以
降の処理について説明する。この場合は、エンジン高回
転時か（Ｓ６２０）、エンジン高負荷時、つまりスロッ
トル開度が所定量以上かどうか（Ｓ６３０）、エンジン
始動時か（Ｓ６２０）をそれぞれ判断し、該当状態でな
ければ順番に次のステップに進んでいく。そして、いず
れかの状態に該当した場合、つまり、マイコン３１の動
作が忙しいエンジン高回転状態（Ｓ６２０：ＹＥＳ）あ
るいは高負荷状態（Ｓ６３０：ＹＥＳ）である場合、ま
たはエンジン始動時である場合（Ｓ６４０：ＹＥＳ）に
は、本処理ルーチンを終了する。一方、いずれの状態で
もない場合には、次ステップのＳ６５０に移行する。

【００５０】Ｓ６５０では、記憶されている異常情報
（異常の有無、異常がある場合には異常対象のコード、
その異常を検出した時点の運転状態データなど）をトラ
ンスポンダ１０へ出力する。その後は、Ｓ６６０にて送
信待ちカウンタＣａをクリアして本処理ルーチンを終了
する。

【００５１】このように、本処理においては、送信待ち
カウンタＣａが６０以上となった場合に初めてＳ６２０
に移行し、常情報の出力に適した期間であるかどうかの
判断処理（Ｓ６２０〜Ｓ６４０）を実行するようにして
おり、送信待ちカウンタＣａが６０未満の場合には、単
に送信待ちカウンタＣａをインクリメントするだけであ
る（Ｓ６７０）。これは、エンジンが高回転や高負荷の
状態ではエンジンＥＣＵ３０の処理負荷が極めて高いの
で、異常情報の出力によって本来のエンジン制御処理に
遅れが生じてしまうことを防ぐためである。特に、異常
が検出されていて出力するデータが多量な場合には出力
処理で他の処理が待たされる時間が長くなるが、エンジ
ンＥＣＵ３０の処理負荷が小さい状態を見計らって出力
すれば、通常の制御に支障を与えない。さらに、異常情
報の出力は特に急を要するものではないので、少しぐら
い遅らせても問題とはならない。

【００５２】また、このようにエンジンＥＣＵ３０の処
理負荷が小さい状態（Ｓ６２０及びＳ６３０にて共にＮ
Ｏ）であっても、エンジン始動時であれば（Ｓ６４０：
ＹＥＳ）、やはり異常情報の出力は実行しない。これ
は、エンジン始動時はノイズ環境が悪いと想定されるの
で、このような状況での通信を避けることで、誤データ
がトランスポンダ１０に送られてしまうことを防止して
いる。

【００５３】次に、上述した構成のトランスポンダ１０
にて実行される処理について、図１１〜図１４を参照し
て説明する。まず、図１１に示す処理は、受信割込によ
って実行される処理であり、最初のステップＳ１０１０
では、レシーバＢ（図１参照）からの異常情報の送信要
求であるかどうかを判断する。異常情報の送信要求であ
る場合には（Ｓ１０１０：ＹＥＳ）、送信要求フラグＦ
（ｒｑ）を１にセットした上で（Ｓ１０２０）、ナビＥ
ＣＵ５０には現在の車両位置を出力するよう要求し（Ｓ
１０３０）、メータＥＣＵ７０には現在の累積走行距離
を出力するよう要求する（Ｓ１０４０）。このＳ１０４
０にて出力要求をした後、あるいは上述のＳ１０１０に
て否定判断された場合には、本処理ルーチンを終了し、
以前の処理に復帰する。

【００５４】また、図１２に示す処理も、受信割込によ
って実行されるものであり、受信データを格納する処理
を示している。最初のステップＳ１１１０では、エンジ
ンＥＣＵ３０からの情報出力であるかどうかを判断し、
そうであれば（Ｓ１１１０：ＹＥＳ）、Ｓ１１２０へ移
行してＲＡＭ内の所定の記憶領域Ｄ（ＥＧ）に受信デー
タを記憶する。ここでの受信データは、上述した図１０
のＳ６５０にてエンジンＥＣＵ３０から出力された異常
情報である。

【００５５】一方、エンジンＥＣＵ３０からの情報出力
でない場合は（Ｓ１１１０：ＮＯ）、メータＥＣＵ７０
からの情報出力であるかどうかを判断し（Ｓ１１３
０）、そうであれば（Ｓ１１３０：ＹＥＳ）、Ｓ１１４
０へ移行してＲＡＭ内の所定の記憶領域Ｄ（ＭＴ）に受
信データを記憶する。ここでの受信データは、上述した
図１１のＳ１０４０にて行った走行距離情報の出力要求
に応じてメータＥＣＵ７０から応答出力されたものであ
る。

【００５６】さらに、メータＥＣＵ７０からの情報出力
でもない場合は（Ｓ１１３０：ＮＯ）、ナビＥＣＵ５０
からの情報出力であるかどうかを判断し（Ｓ１１５
０）、そうであれば（Ｓ１１５０：ＹＥＳ）、Ｓ１１６
０へ移行してＲＡＭ内の所定の記憶領域Ｄ（ＮＶ）に受
信データを記憶する。ここでの受信データは、上述した
図１１のＳ１０３０にて行った位置情報の出力要求に応
じてナビＥＣＵ５０から応答出力されたものである。

【００５７】Ｓ１１２０，Ｓ１１４０，Ｓ１１６０に示
すように、エンジンＥＣＵ３０、メータＥＣＵ７０、ナ
ビＥＣＵ５０からの受信データをＲＡＭ内の記憶領域Ｄ
（ＥＧ），Ｄ（ＭＴ），Ｄ（ＮＶ）に記憶させた後、あ
るいはＳ１１５０にて否定判断された場合には、本処理
ルーチンを終了し、以前の処理に復帰する。

【００５８】一方、図１３に示す出力許可フラグセット
処理は、例えば２５６ｍｓ毎に実行されるべース処理で
ある。この処理は、次の点を考慮したものである。つま
り、上述したハード構成の説明でも述べたが、ナビＥＣ
Ｕ５０及びメータＥＣＵ７０は、共にアクセサリＳＷ６
がオフとなると動作が停止するので、その動作停止中に
レシーバＢから要求があっても、その時点での情報取得
はできない。そのため、所定期間内にナビＥＣＵ５０及
びメータＥＣＵ７０から情報を受信できなかった場合に
は、各ＥＣＵ５０，７０は動作停止状態にあると判断
し、それぞれの情報の受信完了に応じてセットされる出
力許可フラグＦ（ｎｖ），Ｆ（ｍｔ）をセットする。こ
のフラグがセットされていれば、それ以前に受信し、Ｒ
ＡＭ内の所定の記憶領域Ｄ（ＮＶ），Ｃ（ＭＴ）に記憶
されていた受信データを、レシーバＢへの送信用のデー
タとして用いることができる。

【００５９】具体的な処理内容を説明する。まず最初の
ステップＳ１２１０では、送信要求フラグＦ（ｒｑ）が
セットされているかどうかを判断する。上述した図１１
のＳ１０２０にて送信要求フラグＦ（ｒｑ）がセットさ
れていると、このＳ１２１０にて肯定判断となるため、
Ｓ１２２０へ移行し、ナビＥＣＵ５０から位置情報を受
信済みであるかどうかを判断する。この受信済みかどう
かは、上述した図１２の受信データ格納処理にてＳ１１
６０での記憶領域Ｄ（ＮＶ）に受信データを記憶する処
理が実行されたかどうかで判断する。そして、ナビＥＣ
Ｕ５０からの受信データを記憶済みの場合には（Ｓ１２
２０：ＹＥＳ）、Ｓ１２５０へ移行して、受信完了に応
じてセットされる出力許可フラグＦ（ｎｖ）をセットす
る。一方、受信データを記憶済みでなければ（Ｓ１２２
０：ＮＯ）、カウンタＣｎｖをインクリメントした上で
（Ｓ１２３０）、そのカウンタＣｎｖが４０以上かどう
かを判断する（Ｓ１２４０）。そして、カウンタＣｎｖ
が４０以上であれば（Ｓ１２４０：ＹＥＳ）、Ｓ１２５
０へ移行して出力許可フラグＦ（ｎｖ）をセットする
が、カウンタＣｎｖが４０未満であれば（Ｓ１２４０：
ＮＯ）、Ｓ１２５０の処理を実行することなく、Ｓ１２
６０へ移行する。

【００６０】Ｓ１２６０〜Ｓ１２９０においては、上述
したＳ１２２０〜Ｓ１２５０にて実行したナビＥＣＵ５
０に関する処理と同様の処理を、メータＥＣＵ７０に関
する処理として実行する。つまり、メータＥＣＵ７０か
ら走行距離情報を受信済みであるかどうかを判断し（Ｓ
１２６０）、受信済みである場合には（Ｓ１２６０：Ｙ
ＥＳ）、Ｓ１２９０へ移行して、受信完了に応じてセッ
トされる出力許可フラグＦ（ｍｔ）をセットする。一
方、受信データを記憶済みでなければ（Ｓ１２６０：Ｎ
Ｏ）、カウンタＣｍｔをインクリメントした上で（Ｓ１
２７０）、そのカウンタＣｍｔが４０以上かどうかを判
断する（Ｓ１２８０）。そして、カウンタＣｍｔが４０
以上であれば（Ｓ１２８０：ＹＥＳ）、Ｓ１２９０へ移
行して出力許可フラグＦ（ｍｔ）をセットするが、カウ
ンタＣｎｖが４０未満であれば（Ｓ１２８０：ＮＯ）、
Ｓ１２９０の処理を実行することなく、本処理ルーチン
を終了する。

【００６１】続いて、図１４に示す送信処理ルーチンに
ついて説明する。この送信処理は、例えば２５６ｍｓ毎
に実行されるベース処理であり、まず、最初のステップ
Ｓ１３１０では送信要求フラグＦ（ｒｑ）が１にセット
されているかどうか判断する。そして、送信要求フラグ
Ｆ（ｒｑ）が１にセットされていれば（Ｓ１３１０：Ｙ
ＥＳ）、続くＳ１３２０にて、出力許可フラグＦ（ｎ
ｖ），Ｆ（ｍｔ）が共に１にセットされているかどうか
判断する。

【００６２】そして、出力許可フラグＦ（ｎｖ），Ｆ
（ｍｔ）が共に１にセットされていれば（Ｓ１３２０：
ＹＥＳ）、診断データとしてＲＡＭ内の記憶領域Ｄ（Ｅ
Ｇ），Ｄ（ＭＴ），Ｄ（ＮＶ）に格納されている受信デ
ータを、ＥＥＰＲＯＭ１４（図３参照）に記憶している
ＶＩＮコードと共に、レシーバＢに対して送信する。さ
らに、送信要求フラグＦ（ｒｑ）、出力許可フラグＦ
（ｎｖ），Ｆ（ｍｔ）を０にセット、つまりクリアして
（Ｓ１３４０）、本処理ルーチンを終了する。

【００６３】なお、送信要求フラグＦ（ｒｑ）が０の場
合（Ｓ１３１０：ＮＯ）、あるいは出力許可フラグＦ
（ｎｖ），Ｆ（ｍｔ）のいずれか一方でも０である場合
は（Ｓ１３２０：ＮＯ）、そのまま本処理ルーチンを終
了する。次に、メータＥＣＵ７０にて実行される処理に
ついて図１５，１６を参照して説明する。

【００６４】図１５に示す処理は、例えば６４ｍｓ毎に
実行されるベース処理であり、まず、最初のステップＳ
２０１０にて、エンジンＥＣＵ３０から走行距離情報の
要求があったかどうか判断し、要求があれば（Ｓ２０１
０：ＹＥＳ）、その時点での走行距離情報をエンジンＥ
ＣＵ３０に対して出力する（Ｓ２０２０）。このエンジ
ンＥＣＵ３０から走行距離情報の要求は、上述した図９
のＳ５３０の処理中にて出されるものである。そして、
Ｓ２０２０で出力した走行距離情報は、同じく図９のＳ
５３０の処理中において記憶されることとなる。

【００６５】一方、図１６に示す処理も、例えば６４ｍ
ｓ毎に実行されるベース処理であるが、上記図１５の処
理がエンジンＥＣＵ３０からの要求に応答する処理であ
ったのに対して、この図１６の処理は、トランスポンダ
１０からの要求に応答したり、あるいは自発的に情報を
出力する処理である。

【００６６】まず、最初のステップＳ２１１０にて、ト
ランスポンダ１０から走行距離情報の要求があったかど
うか判断し、要求があれば（Ｓ２１１０：ＹＥＳ）、そ
の時点での走行距離情報をエンジンＥＣＵ３０に対して
出力し（Ｓ２１４０）、さらに、送信完了フラグＦ（Ｔ
Ｐ）を１にセットして、本処理ルーチンを終了する。

【００６７】これが応答処理としての基本であるが、ト
ランスポンダ１０から走行距離情報の要求がない場合で
あっても（Ｓ２１１０：ＮＯ）、車速が０であり（Ｓ２
１２０：ＹＥＳ）、さらに送信完了フラグＦ（ＴＰ）が
０であれば（Ｓ２１３０：ＹＥＳ）、走行距離情報をエ
ンジンＥＣＵ３０に対して出力するようにしている（Ｓ
２１４０）。つまり、メータＥＣＵ７０は、アクセサリ
ＳＷ６がオフとなると動作が停止するので、その動作停
止中にトランスポンダ１０から要求されても応答できな
い。そのため、動作中は、トランスポンダ１０からの要
求がなくても、車速が０、つまり車両停止を検出する毎
に１回、自発的にトランスポンダ１０へその時点での走
行距離情報を出力するようにしている。

【００６８】なお、図１６のフローチャートにおいて
は、Ｓ２１２０にて否定判断、つまり車速が０でない場
合はＳ２１６０へ移行して送信完了フラグＦ（ＴＰ）を
クリアしており、また、Ｓ２１３０にて否定判断、つま
り車速が０であっても（Ｓ２１２０：ＹＥＳ）、送信完
了フラグＦ（ＴＰ）が１にセットされている場合はその
まま本処理ルーチンを終了する。これらは、上述したよ
うに、基本的にはトランスポンダ１０からの要求に応答
し、その要求がない場合であっても車両停止を検出する
毎に１回だけ自発的にトランスポンダ１０へ情報出力さ
せるための処理である。

【００６９】次に、ナビＥＣＵ５０にて実行される処理
について図１７，１８を参照して説明する。図１７に示
す処理は、例えば６４ｍｓ毎に実行されるベース処理で
あり、まず、最初のステップＳ３０１０にて、エンジン
ＥＣＵ３０から位置情報の要求があったかどうか判断
し、要求があれば（Ｓ３０１０：ＹＥＳ）、その時点で
の位置情報をエンジンＥＣＵ３０に対して出力する（Ｓ
３０２０）。このエンジンＥＣＵ３０から位置情報の要
求は、上述した図９のＳ５３０の処理中にて出されるも
のである。そして、Ｓ３０２０で出力した位置情報は、
同じく図９のＳ５３０の処理中において記憶されること
となる。

【００７０】一方、図１８に示す処理も、例えば６４ｍ
ｓ毎に実行されるベース処理であるが、上記図１７の処
理がエンジンＥＣＵ３０からの要求に応答する処理であ
ったのに対して、この図１６の処理は、トランスポンダ
１０からの要求に応答したり、あるいは自発的に情報を
出力する処理である。

【００７１】まず、最初のステップＳ３１１０にて、ト
ランスポンダ１０から位置情報の要求があったかどうか
判断し、要求があれば（Ｓ３１１０：ＹＥＳ）、その時
点での位置情報をエンジンＥＣＵ３０に対して出力し
（Ｓ３１４０）、さらに、送信完了フラグＦ（ＴＰ）を
１にセットして、本処理ルーチンを終了する。

【００７２】これが応答処理としての基本であるが、ト
ランスポンダ１０から位置情報の要求がない場合であっ
ても（Ｓ２１１０：ＮＯ）、車速が０であり（Ｓ３１２
０：ＹＥＳ）、さらに送信完了フラグＦ（ＴＰ）が０で
あれば（Ｓ３１３０：ＹＥＳ）、位置情報をエンジンＥ
ＣＵ３０に対して出力するようにしている（Ｓ３１４
０）。ナビＥＣＵ５０も、アクセサリＳＷ６がオフとな
ると動作が停止するので、その動作停止中にトランスポ
ンダ１０から要求されても応答できない。そのため、動
作中は、トランスポンダ１０からの要求がなくても、車
速が０、つまり車両停止を検出する毎に１回、自発的に
トランスポンダ１０へその時点での位置情報を出力する
ようにしている。

【００７３】なお、図１８のフローチャートにおいて、
車速が０でない場合（Ｓ３１２０：ＮＯ）にＳ２１６０
へ移行して送信完了フラグＦ（ＴＰ）をクリアし、ま
た、車速が０であっても（Ｓ３１２０：ＹＥＳ）、送信
完了フラグＦ（ＴＰ）が１にセットされている場合は
（Ｓ３１３０：ＮＯ）、そのまま本処理ルーチンを終了
する。これらは、基本的にはトランスポンダ１０からの
要求に応答し、その要求がない場合であっても車両停止
を検出する毎に１回だけ自発的にトランスポンダ１０へ
情報出力させるための処理である。

【００７４】これら図１６及び図１８を参照して説明し
たように、メータＥＣＵ７０あるいはナビＥＣＵ５０の
動作停止があったとしても、動作中に車速が０（車両停
止）になった場合には、走行距離情報あるいは位置情報
がトランスポンダ１０へ出力されるので、仮に動作中に
トランスポンダ１０からの出力要求が全くなかったとし
ても、各情報はトランスポンダ１０において確実に記憶
される。また、アクセサリＳＷ６がオフされるのは、基
本的には車両停止時にしかあり得ないため、その状況に
おいてのみ情報出力することで、不必要な送信をなくす
ことができる。さらに、車両停止中は基本的に走行距離
情報や位置情報が変化することはないので、車両停止時
のみに情報を出力すれば、実状に合致した適切な情報が
トランスポンダ１０に記憶されることとなる。

【００７５】以上説明した処理を実行することによっ
て、トランスポンダ１０からレシーバＢへは、異常が検
出された時点の車両位置，累積走行距離と、レシーバＢ
が車両に異常情報の送信を要求した時点の車両位置，累
積走行距離とが送られることとなるので、レシーバＢか
らデータを転送された管理センタＣでは、異常となって
からの車両Ａの走行距離や移動状況がわかる。したがっ
て、車両Ａのユーザーに対して適切な処置を取ることが
できる。この適切な処置とは、例えば警告を通知した
り、場合によっては通信を介して車両Ａが安全な場所で
停止した時点で強制的にエンジンを停止させるようにし
たり、エンジンがユーザーにより切られた時に再度エン
ジンがかからなくなるようにするなどである。

【００７６】このように、本実施例の車両用診断装置に
よれば、車両Ａに搭載された「制御ユニット」としての
各ＥＣＵ３０，５０，７０がそれぞれ管轄する各種機器
の状態を診断し、その診断結果は、通信ライン５で接続
された「通信ユニット」としてのトランスポンダ１０に
よって外部のレシーバＢに送信され、さらに管理センタ
Ｃへ転送される。これら各ＥＣＵ３０，５０，７０及び
トランスポンダ１０は、車載エンジンの駆動によって充
電されるバッテリ３から供給された電力によって動作す
るが、バッテリ３からトランスポンダ１０へは通常動作
に必要な電力が常時供給されるよう構成されているた
め、トランスポンダ１０は、レシーバＢからの送信要求
がいつ来ても、それに応じて診断結果を送信することが
できる。

【００７７】一方、バッテリ３から各ＥＣＵ３０，５
０，７０へはイグニッションＳＷ４あるいはアクセサリ
ＳＷ６によって、通常動作に必要な電力が供給される状
態と供給されない状態とが切り替え可能に構成されてい
る。そして、車両使用中は、イグニッションＳＷ４ある
いはアクセサリＳＷ６はオンされるので、通常動作に必
要な電力がバッテリ３から供給される。一方、車両不使
用中は、イグニッションＳＷ４及びアクセサリＳＷ６は
共にオフされるため、通常動作に必要な電力がバッテリ
３からは供給されない。この意味で、エンジンＥＣＵ３
０に対するイグニッションＳＷ４、ナビＥＣＵ及びメー
タＥＣＵ７０に対するアクセサリＳＷが、それぞれ「供
給状態設定手段」に相当する。

【００７８】したがって、車両不使用中で車載エンジン
が停止しておりバッテリ３が充電されない状況では、各
ＥＣＵ３０，５０，７０への電力供給が低減される。具
体的には、エンジンＥＣＵ３０のサブ電源回路３４（図
４参照）を介してマイコン３１内のＲＡＭに格納された
データを保持するためだけの電力供給がなされるだけで
あるので、バッテリ３の消耗が相当少なくなる。

【００７９】つまり、いつ来るか判らないレシーバＢか
らの送信要求に対して、いつ来てもそれに応答できるよ
うにするため、トランスポンダ１０に加えて各ＥＣＵ３
０，５０，７０までも通常動作できるように準備してお
くのはバッテリ消耗の点からすれば非合理的である。そ
こで、上記送信要求に応答するためだけであれば最低限
トランスポンダ１０だけ動作できればよいので、各ＥＣ
Ｕ３０，５０，７０への通常動作可能な電力の供給はし
ない。

【００８０】但し、車両不使用中は各ＥＣＵ３０，５
０，７０へ通常動作可能な電力が供給されないため、そ
の車両不使用中にレシーバＢから送信要求があった場
合、その時点で各ＥＣＵ３０，５０，７０からの情報を
取得することはできない。したがって、トランスポンダ
１０は、その時点で各ＥＣＵ３０，５０，７０からの情
報を取得する代わりに、車両Ａが不使用状態になる以前
の車両使用中に各ＥＣＵ３０，５０，７０から得た最新
の情報を送信する。

【００８１】これによって、レシーバＢからの送信要求
がいつ来ても応答できるように構成されていながら、バ
ッテリ消耗を極力少なくすることができる。また、本実
施例では、エンジンＥＣＵ３０からの診断結果は、エン
ジンＥＣＵ３０が主導で出力している。つまり、トラン
スポンダ１０からの要求ではなく、所定時間毎に異常情
報を出力することを基本としている（図１０参照）。但
し、その出力に不適切な期間は避けるようにしている。
まず、エンジン高回転あるいは高負荷時で制御に要する
処理負荷が大きいと考えられる期間である。エンジンに
対する各種制御が本来の仕事であり、優先度は相対的に
高く、一方、異常情報の出力は相対的に見れば優先度が
低い。つまり、エンジンＥＣＵ３０が優先度の高い処理
を実行するのに忙しい期間中においては、その優先度の
高い処理を抑えてまで、あえて異常情報の出力という優
先度の低い処理を実行する必要性はない。したがって、
このような期間中にトランスポンダ１０へ診断結果を出
力する要求があっても、その要求には対応しない。さら
に、エンジン始動に起因して通信ライン５上にノイズが
発生していると考えられる期間もトランスポンダ１０へ
異常情報を出力しない。エンジン始動時はスタータを回
転駆動させていることなどよって通信ライン５上にノイ
ズが発生している可能性が高い。そのため、この状態で
エンジンＥＣＵ３０からトランスポンダ１０に異常情報
が出力されると、通信ライン上５でデータ化けやデータ
破壊が起こり、エンジンＥＣＵ３０から出力されたのと
は違う誤った診断結果が管理センタＣに送信されてしま
う可能性がある。したがって、このような期間中にトラ
ンスポンダ１０へ診断結果を出力する要求があっても、
その要求には対応しない。 ［その他］ （１）トランスポンダ１０が各ＥＣＵ３０，５０，７０
から取得する情報について考えてみる。

【００８２】上記実施例においては、エンジンＥＣＵ３
０は自己の管理するタイミングにて異常情報を出力する
ようにしており、またナビＥＣＵ５０及びメータＥＣＵ
７０は、基本的にはトランスポンダ１０からの要求に応
じて情報を出力するが、車両が停止した場合には、その
時点で自発的に情報を出力する。したがって、車両不使
用中にレシーバＢからの送信要求があった場合、トラン
スポンダ１０には、車両使用中において各ＥＣＵ３０，
５０，７０から上述のタイミングで出力された最後の情
報が記憶されていることとなる。その記憶された情報を
「最新の診断結果」としてレシーバＢに送信する。

【００８３】これ以外に次のようにすることも考えられ
る。例えばエンジンＥＣＵ３０について考えると、イグ
ニッションＳＷ４がオフされた時点から所定期間はエン
ジンＥＣＵ３０の通常動作に必要な電力が供給されてい
る状態を継続することで、その所定期間中にエンジンＥ
ＣＵ３０から異常情報を出力させるのである。例えば図
４に示すサブ電源回路３４から供給される電力によっ
て、その異常情報出力処理を実行する。また、ナビＥＣ
Ｕ５０やメータＥＣＵ７０の場合にも同様にサブ電源回
路を追加すればよい。

【００８４】もちろん、このようなサブ電源回路によっ
て実現するのではなく、例えば車両運転手によるキー操
作にてイグニッションＳＷ４がオフされたりアクセサリ
Ｗ６がオフされた場合、そのオフ操作時点から所定の遅
延時間後にバッテリ３から電源回路３３，５３，７３へ
の実際の電力供給を遮断するようにしてもよい。例え
ば、バッテリ３と電源回路３３，５３，７３との間にイ
グニッションＳＷ４ヤアクセサリＳＷ６を迂回した電源
ラインを設け、そのライン上に設けたリレーを、マイコ
ンがイグニッションＳＷ４やアクセサリＳＷ６の状態に
応じて制御するように構成すればよい。

【００８５】つまり、車両の使用状態から不使用状態へ
の切り替わりタイミングは、運転手のキー操作によって
定まるため、実際の電力供給停止をその切り替わりタイ
ミングから遅延させればよい。このようにすれば、「最
新の診断結果」としてより適切なものが得られる。つま
り、各ＥＣＵ３０，５０，７０から自発的に出力される
情報の内の最後のものを「最新の診断結果」とする場
合、出力間隔によっては、車両Ａが使用状態から不使用
状態に切り替わる直前の状態を反映した情報とはならな
い可能性もある。例えば、最後の情報を出力した後でも
車両が走行している場合もあり、その走行によって新た
な異常が発生する可能性もある。また、新たな異常がな
くても、最終的に停止した時点の位置情報や走行距離情
報との誤差が生じる可能性もある。そのため、上述の手
法を採用すれば、車両が実際に停止した時点での位置情
報や走行距離情報が得られる点で有利である。

【００８６】（２）また、上記実施例においては、エン
ジンＥＣＵ３０は自己の管理するタイミングにて異常情
報を出力するようにしていたが、例えばトランスポンダ
１０から定期的あるいは非定期的に要求を出し、その要
求に応じてエンジンＥＣＵ３０から異常情報を出力する
ようにしてもよい。

【００８７】そして、このように、エンジンＥＣＵ３０
がトランスポンダ１０からの要求に応じて異常情報を出
力する場合には、上述した処理負荷が大きい期間やエン
ジン始動時のように異常情報の出力に不適切な期間への
対処が問題となるが、やはりそれら不適期間中には応答
しない、つまり異常情報は出力しないようにする。そし
て、例えば、不適期間中にトランスポンダ１０から出力
要求があった場合には、その要求には対応しないが、要
求があったこと自体は記憶しておき、その後、不適期間
に該当しない状況となった時点で、記憶されている診断
結果の出力要求に応じて、異常情報をトランスポンダ１
０へ出力することが考えられる。

【００８８】このようにすれば出力要求へのレスポンス
は向上する。なぜなら、出力要求が来た時点で不適期間
中であるかどうかを判断し、不適期間中であれば対応せ
ず、不適期間中でなければ対応するだけの場合には、不
適期間が過ぎていても、その後に出力要求が来るタイミ
ングを待たなくてはならない。つまり、必ずしも不適期
間が過ぎた直後に出力要求が来るとは限らないからであ
る。それに対して、診断結果の出力要求があったこと自
体は記憶しておき、その後、不適期間に該当しない状況
となった時点で出力要求に応じるようにすれば、対応し
て良い状態になったら即座に応じることができるため、
出力要求へのレスポンスは向上する。

【００８９】（３）上記（２）のようにエンジンＥＣＵ
３０がトランスポンダ１０からの出力要求に応じてトラ
ンスポンダ１０へ診断結果を出力することを前提とした
場合には、次のような工夫も有効である。つまり、トラ
ンスポンダ１０が、エンジンＥＣＵ３０から診断結果が
複数回出力され、かつ複数回の診断結果の内容が一致す
るまで、繰り返しエンジンＥＣＵ３０へ出力要求し、診
断結果が一致すると、その一致した診断結果を管理セン
タ側へ送信するよう構成することが考えられる。エンジ
ンＥＣＵ３０からトランスポンダ１０に出力された診断
結果の正確性向上を期すためには、有効である。

【００９０】また、トランスポンダ１０に異常がある場
合のエンジンＥＣＵ３０側の対処としては、次のように
することも有効である。つまり、トランスポンダ１０か
らの要求に応じて診断結果を所定回数以上出力したにも
かかわらず、さらに診断結果の出力要求が来た場合に
は、それ以降の要求には対応しないようにする。

【図面の簡単な説明】

【図１】 実施例の車両用診断装置の搭載された車両を
含む診断システムの概略説明図である。

【図２】 実施例の車両内の概略的なシステム構成を示
すブロック図である。

【図３】 実施例のトランスポンダの構成を示すブロッ
ク図である。

【図４】 実施例のエンジンＥＣＵの構成を示すブロッ
ク図である。

【図５】 実施例のナビＥＣＵの構成を示すブロック図
である。

【図６】 実施例のメータＥＣＵの構成を示すブロック
図である。

【図７】 実施例のエンジンＥＣＵで実行されるメイン
処理を示すフローチャートである。

【図８】 実施例のエンジンＥＣＵで実行されるダイア
グ処理を示すフローチャートである。

【図９】 実施例のエンジンＥＣＵで実行されるダイア
グ処理を示すフローチャートである。

【図１０】 実施例のエンジンＥＣＵで実行される異常
情報出力処理を示すフローチャートである。

【図１１】 実施例のトランスポンダで受信割込にて実
行される処理を示すフローチャートである。

【図１２】 実施例のトランスポンダで受信割込にて実
行される受信データ格納処理を示すフローチャートであ
る。

【図１３】 実施例のトランスポンダで実行される出力
許可フラグセット処理を示すフローチャートである。

【図１４】 実施例のトランスポンダで実行される送信
処理を示すフローチャートである。

【図１５】 実施例のメータＥＣＵで実行されるエンジ
ンＥＣＵへの出力処理を示すフローチャートである。

【図１６】 実施例のメータＥＣＵで実行されるトラン
スポンダへの出力処理を示すフローチャートである。

【図１７】 実施例のナビＥＣＵで実行されるエンジン
ＥＣＵへの出力処理を示すフローチャートである。

【図１８】 実施例のナビＥＣＵで実行されるトランス
ポンダへの出力処理を示すフローチャートである。

【符号の説明】

３…バッテリ ４…イグニッション
ＳＷ ５…通信ライン ６…アクセサリＳＷ １０…トランスポンダ １１…マイコン １２…入出力回路 １３…電源回路 ２０…アンテナ ３０…エンジンＥＣＵ ３１…マイコン ３２…入出力回路 ３３…メイン電源回
路 ３４…サブ電源回路 ４１…Ａ／Ｆセンサ ４２…回転センサ ４３…エアフローメ
ータ ４４…水温センサ ４５…スロットルセ
ンサ ４６…スタータＳＷ ４７…インジェクタ ４８…イグナイタ ４９…ＤＩＡＧテス
タ ５０…ナビＥＣＵ ５１…マイコン ５２…入出力回路 ５３…電源回路 ６０…ＧＰＳアンテナ ６２…受信機 ６４…地図データ入力装置 ６６…表示モニタ ７０…メータＥＣＵ ７１…マイコン ７２…入出力回路 ７３…電源回路 ８０…メータパネル ８５…車速センサ Ａ…車両 Ｂ…レシーバ Ｃ…管理センタ

Claims (9)

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