JP3843578B2 - 車両用診断装置 - Google Patents
車両用診断装置 Download PDFInfo
- Publication number
- JP3843578B2 JP3843578B2 JP02486998A JP2486998A JP3843578B2 JP 3843578 B2 JP3843578 B2 JP 3843578B2 JP 02486998 A JP02486998 A JP 02486998A JP 2486998 A JP2486998 A JP 2486998A JP 3843578 B2 JP3843578 B2 JP 3843578B2
- Authority
- JP
- Japan
- Prior art keywords
- vehicle
- output
- control unit
- communication unit
- diagnosis result
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Combined Controls Of Internal Combustion Engines (AREA)
Description
【発明の属する技術分野】
本発明は、車両に搭載された各種機器の状態を診断する車両用診断装置であって、特に、その診断結果を外部の管理センタ側へ送信可能にされた車両用診断装置に関する。
【0002】
【従来の技術】
車両のメインテナンスは、例えば、日本では一定期間ごとの車検に応じてユーザーが整備工場にて検査及び修理をしてもらい陸運局に報告するようにしており、また米国では監督局からの定期的な通知に従いユーザーが整備工場で検査及び修理を受け基準を満たしていることを監督局に返信するというようにして管理されている。
【0003】
ところがこのような方式では、特に故障や不良が無く整備の必要の無い車両まで一律に管理しているため、監督局(陸運局)での管理の工数が多くなっていると共に、ユーザにとっても煩わしいものである。
このようなことから、車両側にて検査に関わる情報(例えば、エンジン関連部品の異常に関する情報)を車両から無線通信にて監督局側としての管理センタ側に送信し、特に修理が必要な車両に対してそのユーザーに指示し報告させるようにすることが考えられる。
【0004】
【発明が解決しようとする課題】
このようなシステムとした場合、車両側では無線通信を送受信するための装置(以下、トランスポンダという)を装備すると共に、検査に関わる情報を車載の制御ユニットで得て、制御ユニットからトランスポンダに通信するよう構成する必要が生じる。
【0005】
しかしながら、管理センタ側から車両に対して、検査に関わる情報の送信要求が出され、その送信要求を受けたトランスポンダが検査に関わる情報を管理センタ側に送信するというような、車両側が受動的なシステムとした場合には、次のような不都合が生じる。つまり、管理センタ側からの送信要求はいつ送られてくるか判らないため、要求がいつ来ても応答できるように車両側にシステムを構築しておく必要がある。このためには、例えば車載のトランスポンダや制御ユニットを常時オン状態にしておけばよいが、一般的にエンジン停止状態では車載バッテリに対して充電がされないため、上記「常時オン」しておく方法では、トランスポンダや制御ユニットによって消費される電力によって短期間でバッテリが消耗してしまうこととなる。
【0006】
そこで、本発明は、管理センタ側からの送信要求がいつ来ても応答できるように構成されていながら、バッテリ消耗を極力少なくした車両用診断装置を提供することを目的とする。
【0007】
【課題を解決するための手段及び発明の効果】
上記目的を達成するためになされた請求項1記載の車両用診断装置によれば、車両に搭載されたエンジンを制御する制御ユニットがエンジンのエミッションに関連する異常を診断し、その診断結果は、当該制御ユニットと同じく前記車両に搭載され、制御ユニットと通信ラインで接続された通信ユニットによって外部の管理センタ側へ送信される。これら制御ユニット及び通信ユニットは、車載エンジンの駆動によって充電されるバッテリから供給された電力によって動作するが、バッテリから通信ユニットへは通常動作に必要な電力が常時供給されるよう構成されているため、通信ユニットは、管理センタ側からの送信要求がいつ来ても、それに応じて診断結果を管理センタ側に送信することができる。
【0008】
一方、バッテリから制御ユニットへは通常動作に必要な電力が供給される状態と供給されない状態とが切り替え可能に構成されており、供給状態設定手段は、車両の使用中は、バッテリから制御ユニットへ通常動作に必要な電力が供給される状態に設定し、一方、車両の不使用中は、バッテリから制御ユニットへ通常動作に必要な電力が供給されない状態に切替設定する。したがって、車両が不使用中で車載エンジンが停止しておりバッテリが充電されない状況では制御ユニットへの電力供給が低減(停止も含む)されるため、その分のバッテリ消耗が少なくなる。
【0009】
つまり、いつ来るか判らない管理センタ側からの送信要求に対して、いつ来てもそれに応答できるようにするため、通信ユニットに加えて制御ユニットまでも通常動作できるように準備しておくのはバッテリ消耗の点からすれば非合理的である。そこで、上記送信要求に応答するためだけであれば最低限通信ユニットだけ動作できればよいので、制御ユニット側への通常動作可能な電力の供給はしないようにする。
【0010】
但し、車両が不使用中は制御ユニットへ通常動作可能な電力が供給されないため、その車両不使用中に管理センタ側から送信要求があった場合には、その時点で制御ユニットから診断結果を取得することはできない。したがって、制御ユニットは通常動作に必要な電力が供給される状態にあるときに通信ユニットに診断結果を送信するようになっており、通信ユニットは、その時点で制御ユニットから診断結果を取得する代わりに、車両が不使用状態になる以前の車両使用中、具体的には制御ユニットが通常動作に必要な電力が供給されているときに制御ユニットから得ていた最新の診断結果を送信する。
【0011】
これによって、管理センタ側からの送信要求がいつ来ても応答できるように構成されていながら、バッテリ消耗を極力少なくした車両用診断装置を提供することができる。
なお、「通常動作に必要な電力が供給されない状態」としたのは、次の理由からである。例えばマイクロコンピュータにおけるRAM内のデータを車両不使用状態でも保持しておくためには、やはり電力供給はされる必要がある。しかし、これは例えば制御ユニットとしてのエンジンECUを考えると、通常のエンジン制御を実行したりするのに必要な電力までは不要である。したがって、もちろんこのようなRAM内のデータを保持したりする必要がなければ、電力供給を完全に停止してもよいが、上述の事情も含め、「通常動作に必要な電力が供給されない状態」としたのである。
【0012】
また、車両の状態として「使用中」と「不使用中」と表現したのは次の理由からである。つまり、エンジンが駆動していれば必ず使用中ではあるが、例えばエンジンが駆動していなくても、車載機器のカーナビゲーションシステム等を使用することもできる。このカーナビゲーションシステムは一般的な自動車においてはアクセサリスイッチがオンされていれば使用できる。したがって、ここではそれらも含める意味で使用中・不使用中という語を用いた。具体的には、一般的な自動車においては、OFF・ACC・ON・STARTの4位置を持つキースイッチが多いので、この場合にはOFFだけが「不使用中」であり、残りのACC・ON・STARTの場合は全て「使用中」と考えることができる。つまり、車両の利用者が、バッテリにて動作する車載装備を使用する場合が使用中である。したがって、キースイッチがOFFの状態にて何らかの車載装備を使用したとしても、それは使用中ではなく「不使用中」である。
【0013】
なお、上述した車両不使用中に通信ユニットが送信する「最新の診断結果」については、例えば、請求項2に示すように、車両使用中は、制御ユニットが自発的に、あるいは通信ユニットからの出力要求に応じて通信ユニットへ診断結果を出力するようにし、その車両使用中に最後に出力された診断結果を「最新の診断結果」としてもよい。この場合、例えば、制御ユニットから定期的に診断結果を出力し、通信ユニットではそれを更新記憶しておくようにすれば、通信ユニットに記憶されたものがそのまま「最新の診断結果」になる。
【0014】
あるいは、請求項3に示すように、供給状態設定手段によって、車両が使用状態から不使用状態に移行した場合、その移行時点から所定期間は制御ユニットの通常動作に必要な電力が供給されている状態を継続することで、その所定期間中に制御ユニットから診断結果を出力させ、その所定期間中に出力された診断結果を「最新の診断結果」としてもよい。この場合には、「最新の診断結果」としてより適切なものが得られるため、適切な診断のためには好ましい。つまり、制御ユニットから定期的に出力される診断結果の内の最後のものを「最新の診断結果」とする場合、出力間隔によっては、車両が使用状態から不使用状態に切り替わる直前の状態を反映した診断結果とはならない可能性もある。例えば、最後の診断結果を出力した後でも車両が走行している場合もあり、その走行によって異常が発生する可能性もある。請求項3に示すようにすれば、このような不都合は解消される。
【0015】
ところで、制御ユニットから通信ユニットへ出力される診断結果は、基本的には車両使用中に出力されるものである。そのため、例えば診断結果の出力タイミングがエンジン始動時に重なると、通信状態が悪い状態なので通信ユニットと制御ユニットとの間の通信ライン上にノイズが乗り、例えば通信ユニットに入力された信号が制御ユニットから出力された信号と異なってしまう可能性がある。その場合には、誤った情報が管理センタ側に送られてしまう。また、制御ユニットのマイクロコンピュータ(以下「マイコン」と略記する)が忙しい時、例えばエンジン制御ユニットであれば、エンジン高回転時や高負荷時などにおいては、通信ユニットへの出力データ量が多くなると、本来の制御処理に影響を与える可能性がある。
【0016】
したがって、上述したバッテリ消耗の低減等の効果を得ながら、さらにこのような不都合を防止するためには、上述した車両用診断装置の制御ユニットが、診断結果を通信ユニットに出力するには不適切な期間を判別し、その期間中は出力しないようにすることが好ましい。
【0017】
具体的には、制御ユニットが、エンジン始動に起因して通信ライン上にノイズが発生していると考えられる第1の不適期間中と、各種機器への制御に要する処理負荷が所定以上大きいと考えられる第2の不適期間中との少なくとも一方を判断し、前記不適期間と判断したときは、所定の通信ユニットへの出力タイミングであっても、診断結果を出力しないようにする。一方、不適期間に該当しない場合には、所定の出力タイミングにおいて診断結果を通信ユニットに出力する。
【0018】
上述した第1の不適期間中は、エンジン始動に起因し、例えばスタータを回転駆動させていることなどよって通信ライン上にノイズが発生している可能性が高い。そのため、この状態で制御ユニットから通信ユニットに診断結果が出力されると、それらユニット間の通信ライン上でデータ化けやデータ破壊が起こり、制御ユニットから出力されたのとは違う誤った診断結果が管理センタに送信されてしまう可能性がある。したがって、このような不適期間中に所定の出力タイミングが来ても診断結果は出力しない。
【0019】
また、上述した第2の不適期間中は、各種機器への制御に要する処理負荷が所定以上大きい期間である。各種機器への制御は制御ユニットの本来の仕事であり、優先度は相対的に高く、一方、診断結果の出力は相対的に見れば優先度が低い。つまり、制御ユニットが優先度の高い処理を実行するのに忙しい(つまりマイコンの処理負荷が高い)期間中においては、その優先度の高い処理を抑えてまで、あえて診断結果の出力という優先度の低い処理を実行する必要性はない。したがって、このような期間中に所定の出力タイミングが来ても診断結果は出力しない。なお、処理負荷が大きい状態とは、具体的には制御対象がエンジンであれば、そのエンジン回転数が高い状態などである。つまり、回転数に対応した処理タイミングを設定すると、エンジン高回転状態においては単位時間当たりの処理量が多くなるからである。特にエンジンについてはリアルタイム処理が必要であり、診断結果の出力のように、緊急性が低い処理については後回しで一向に構わないのである。
【0020】
ところで、「所定の出力タイミング」は、例えば通信ユニットからの出力要求を受けた制御ユニットが診断結果を出力するのであれば、その通信ユニットからの出力要求タイミングに基づくこととなる。そして、この方法であれば、管理センタ側からの送信要求に応じ、通信ユニットが制御ユニットに対して診断結果を出力するよう要求することが考えられる。このようにすれば、管理センタにおける管理に都合が良いタイミングで送信要求を出すことができるため、管理上の利点がある。
【0021】
そして、このように、管理センタ側からの送信要求に応じ、通信ユニットが制御ユニットに対して診断結果を出力するよう要求する場合には、制御ユニットが次のように対応することも考えられる。つまり、不適期間中において診断結果の出力要求があった場合には、その要求には対応しないが、要求があったこと自体は記憶しておき、その後、不適期間に該当しない状況となった時点で、記憶されている診断結果の出力要求に応じて、診断結果を通信ユニットに出力するのである。このようにすれば出力要求へのレスポンスは向上する。なぜなら、出力要求が来た時点で不適期間中であるかどうかを判断し、不適期間中であれば対応せず、不適期間中でなければ対応するだけの場合には、不適期間が過ぎていても、その後に出力要求が来るタイミングを待たなくてはならない。つまり、必ずしも不適期間が過ぎた直後に出力要求が来るとは限らないからである。それに対して、診断結果の出力要求があったこと自体は記憶しておき、その後、不適期間に該当しない状況となった時点で出力要求に応じるようにすれば、対応して良い状態になったら即座に応じることができるため、出力要求へのレスポンスは向上する。
【0022】
そして、このように、制御ユニットが、通信ユニットからの出力要求に応じて通信ユニットへ診断結果を出力することを前提とした場合には、通信ユニットが、制御ユニットから診断結果が複数回出力され、かつ複数回の診断結果の内容が一致するまで、繰り返し制御ユニットへ出力要求し、診断結果が一致すると、その一致した診断結果を管理センタ側へ送信するよう構成することが考えられる。制御ユニットから通信ユニットに出力された診断結果の正確性向上を期すためには、有効である。
【0023】
また、通信ユニットに異常がある場合の制御ユニット側の対処としては、次のようにすることも有効である。つまり、通信ユニットからの要求に応じて診断結果を所定回数以上出力したにもかかわらず、さらに診断結果の出力要求が来た場合には、それ以降の要求には対応しないようにするのである。
【0024】
なお、車両用診断装置は最終的には通信ユニットが管理センタ側に車両の診断結果を送信することとなるが、その診断結果に、車両固有の識別情報を含めることも考えられる。これは、診断結果がどの車両に対応するものなのかを容易に判別できる点で有効である。もちろん、これ以外にも、診断結果を送信してきた車両を特定する方法は考えられるが、診断結果に含まれていれば、特定が容易にできる。
【0025】
また、診断結果には、診断対象の機器に関する情報だけでなく、付帯情報として、例えば診断時における車両の走行距離あるいは車両位置の少なくとも一方を含めることも有効である。つまり、その診断対象の機器が搭載された車両自体の走行距離に応じても診断結果の分析は変わる可能性があるからである。また、車両位置についても同様である。
【0026】
以上説明した車両用診断装置においては、車載の様々な機器について、制御ユニットの制御対象とできる。
【0027】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り、種々の形態を採り得ることは言うまでもない。
【0028】
図1は、実施例の車両用診断装置の搭載された車両を含む診断システムの概略構成を示す図である。当該システムの概略を説明する。監督局をなす管理センタCは、レシーバBを介して複数の車両Aからそれぞれエミッション(排ガス)に関連するデータ、エンジンの故障に関するデータ等を無線通信にて入手する。管理センタCは不具合のある車両Aを特定して、その車両保有者に対して車両Aの修理、改善を促す。なお、この車両Aの修理、改善を促すのは、例えば書類を郵送するなど種々の方法が採用できる。
【0029】
図2は、車両A内の概略的なシステム構成を示すブロック図である。トランスポンダ10はレシーバBからの要求を受け、車載制御ユニットであるエンジンECU30、ナビECU50、メータECU70から必要な情報を通信ライン5を介して入手し、その入手した情報をレシーバB(図1参照)に対して送信する。
【0030】
エンジンECU30は、エンジンの制御を司ると共に、エンジンのエミッションに関連する異常を自己診断し、トランスポンダ10の要求に応じてその情報をトランスポンダ10に送信する。
また、ナビECU50、メータECU70は、それぞれナビゲーション制御、メータ表示制御を実行すると共に、エンジンECU30が自己診断にて何らかの異常を検出したときに、エンジンECU30から出される要求に応じてそれぞれ車両の走行距離,車両位置をエンジンECU30に出力し、またトランスポンダ10からの要求が来たときにそのときの走行距離,車両位置をトランスポンダ10に出力する。
【0031】
図3〜図6はトランスポンダ10,及び各車載制御ユニットである各ECU30,50,70の構成を示すブロック図である。
まず、図3を参照してトランスポンダ10について説明する。
トランスポンダ10が動作するための電力を供給する電源回路13には、バッテリ3から常時電力が供給されているので、車両のキーSWの状態に関係なく動作する。マイコン11内のCPUは、同じくマイコン11内のROMに記憶された制御プログラムに従い、アンテナ20を介して外部から来る要求に応じた処理を実行する。また、マイコン11内のRAMはエンジンECU30などからのデータ等を一時的に記憶する。なお、入出力回路12がアンテナ20及び通信ライン5と接続されており、この入出力回路12を介して入出力されたデータはマイコン11内のI/Oを介してCPUなどをやりとりされる。また、マイコン11にはEEPR0M14が接続されていて、車両固有の識別番号(VINコード)が記憶されている。
【0032】
次に、図4を参照してエンジンECU30について説明する。
エンジンECU30は、メイン電源回路33がイグニッションSW4を介してバッテリ3と接続されており、基本的には、イグニッションSW4が投入されることによってメイン電源回路33から電源が供給されて動作する。但し、イグニッションSW4を介さずバッテリ3と直接つながるサブ電源回路34からマイコン31に電源供給されることで、マイコン31のRAMのデータがイグニッションSW4のオフ後も保持されることとなる。
【0033】
なお、バッテリ3は、エンジンが駆動することによって充電される構成となっている。具体的には、エンジンによって駆動されるオルタネータを備えており、そのオルタネータがエンジン回転数に応じた電力を発生し、発生した電力がバッテリ3に供給されるよう構成されている。この供給された電力によってバッテリ3が充電される。
【0034】
マイコン31では、CPUがROMに記憶された制御プログラムに従い、入出力回路32及びマイコン31内のI/Oを介して入力したセンサ信号に基づいてエンジンが最適な動作をするようインジェクタ47やイグナイタ48を制御する信号を出力する。また、エンジンのエミッションに関連する異常を自己診断してエンジンの動作やセンサ41〜46の異常等を診断し、外部(DIAGテスタ49やトランスポンダ10)からの要求に応じて診断結果のデータを出力する。また、マイコン31内のRAMは、CPUでの演算処理に使うセンサデータ、演算にて求まった制御データ、あるいは上記診断にて得た種々の診断データ等を保持している。
【0035】
なお、入出力回路32に接続されているセンサ41〜46は、空燃比(A/F)センサ41、エンジンの回転数を検出する回転センサ42、エアフローメータ43、水温センサ44、スロットルセンサ45、スタータSW46である。
次に、図5を参照してナビECU50について説明する。
【0036】
ナビECU50は、電源回路53がアクセサリSW6を介してバッテリ3と接続されており、アクセサリSW6が投入されることによってマイコン51や入出力回路52が動作する。この入出力回路52には、受信機62、地図データ入力装置64及び表示モニタ66が接続されている。受信機62にはGPSアンテナ60が接続されており、これらは、GPS衛星からの電波に基づいて車両の位置を検出するGPS(Global Positioning System )のための構成である。また、地図データ入力装置64は、位置検出の精度向上のためのいわゆるマップマッチング用データ、地図データを含む各種データを記憶媒体から入力するための装置である。このための記憶媒体としては、そのデータ量からCD−ROMを用いるのが一般的であるが、例えばDVDやメモリカード等の他の媒体を用いても良い。また、表示モニタ66は地図や誘導経路などを表示するためのものであり、本実施例では、利用者からの指示を入力する機能も備えている。
【0037】
マイコン51では、CPUがROMの記憶された制御プログラムに従い、入出力回路52及びマイコン51内のI/Oを介して入力した地図データ入力装置64からの地図データや受信機62からの信号をもとに、表示モニタ66から得られる利用者からの指示情報に対応して表示処理を実行し、表示モニタ66に利用者が所望する情報を表示させる。また、マイコン51は、エンジンECU30やトランスポンダ10からの要求が通信ライン5を介して来たときには、受信した時点の車両位置を、要求してきたエンジンECU30やトランスポンダ10に出力することができる。
【0038】
次に、図6を参照してメータECU70について説明する。
メータECU70は、電源回路73がアクセサリSW6を介してバッテリ3と接続されており、アクセサリSW6が投入されることによってマイコン71や入出力回路72が動作する。この入出力回路72には、メータパネル80や車速センサ85などが接続されている。
【0039】
マイコン71では、CPUがROMに記憶された制御プログラムに従い、車速センサ85などのセンサ信号を入力し、メータパネル80に車速などの情報を表示させる。また、マイコン71は、エンジンECU30やトランスポンダ10からの要求が通信ライン5を介して来たときには、受信した時点の車両の累積走行距離を、要求してきたエンジンECU30やトランスポンダ10に出力することができる。
【0040】
次に、上述した構成のエンジンECU30にて実行される処理について、図7〜図11を参照して説明する。
まず、エンジンECU30では、イグニッションSW4(図4参照)が投入されることによって動作を開始すると、図7のメイン処理の最初のステップS100に示すように、RAM内の検出データやカウンタデータなどの初期化を行う。なお、後述する自己診断(ダイアグ)処理(S400)に関連して記憶されるデータはこの初期化の対象外である。
【0041】
このS100での初期化処理後は、S200にて燃料噴射(EFI)、S300にて点火時期(ESA)の制御処理、S400にてエンジン関連の自己診断(ダイアグ)処理、その他の処理を繰り返し実行する。
続いて、S400でのダイアグ処理について図8及び図9を参照して詳しく説明する。
【0042】
図8に示すダイアグ処理は、例えば64ms毎に実行されるべース処理であるが、スロットルセンサ45や水温センサ44(図4参照)が異常かどうかを判断し(S410,S430)、異常を検出した場合には(S410:YES;S430;YES)、検出した異常対象を特定するコードをRAMに記憶する(S420,S440)。また、エンジンの失火を検出したかどうかを判断し(S450)、失火を検出した場合には(S450:YES)、失火コードをRAMに記憶する(S460)。なお、図8においては特には示していないが、エンジン関連部品、例えばインジェクタ47や触媒などの不良状態などを判断して、異常を検出した場合には検出した異常対象を特定するコードをRAMに記憶するようにしてもよい。
【0043】
また、図9に示すダイアグ処理も、例えば64ms毎に実行されるべース処理であり、まず最初のステップS510では、図8のダイアグ処理にて異常を検出したかどうかを判断する。具体的には、S410,S430,S450にて肯定判断された場合には、異常があったと判断する。
【0044】
異常がなければ(S510:NO)、そのまま処理ルーチンを終了するが、異常があった場合には(S510:YES)、それが検出済みの異常であるかどうかを判断する(S520)。つまり、検出した異常が、以前検出済みの異常であった場合には(S520:YES)、そのまま本処理ルーチンを終了する。一方、初めて検出した異常であった場合、つまりそれまではRAMに異常コードが記憶されていなかった場合には(S520:NO)、S530へ移行して運転状態の記憶を行う。
【0045】
このS530にて記憶される運転状態のデータ(フリーズフレームデー夕)は、車両を診断する際の異常解析用として使われるものであり、トランスポンダ10からレシーバBを介して管理センタC側(図1参照)に送られるデータの一部である。記憶される項目としては、エンジン回転数、吸入空気量、水温、スロットル開度、噴射量に関する制御データ、点火時期に関する制御データ、車両の走行距離、車両の位置などである。この内、走行距離及び車両の位置については、エンジンECU30から通信ライン5を介してメータECU70及びナビECU50に要求し、メータECU70からはその時点での累積走行距離、ナビECU50からはその時点での位置を出力してもらうことによって入手する。なお、エンジンECU30からの要求に応じてメータECU70がその時点での累積走行距離を出力する処理は図15、エンジンECU30からの要求に応じてナビECU50がその時点での位置情報を出力する処理は図17を参照して後述する。
【0046】
エンジンECU30は、上述のようにしてダイアグに関する処理が実行されて異常の有無や異常の内容や異常発生時の運転状態が記憶されていくのであるが、本実施例におけるエンジンECU30は、イグニッションSW4がオフされた後は上述のように動作を停止する。そのため、トランスポンダ10がレシーバBから要求をいつでも受け付けることができるよう、エンジンECU30はその動作中の所定間隔毎に、自らから記憶している異常に関する上記情報を通信ライン5を介してトランスポンダ10へ出力する。
【0047】
そのトランスポンダ10への異常情報出力処理について図10を参照して説明する。
図10に示す異常情報出力処理は、例えば1024ms毎に実行されるべース処理であり、まず送信待ちカウンタCaが60以上であるかどうかを判断している(S610)。そして、送信待ちカウンタCaが60以上であれば(S610:YES)、S620へ移行し、S620〜S640の各条件が成立すればS650にて異常情報をトランスポンダ10へ出力するが、送信待ちカウンタCaが60未満であれば(S610:NO)、その送信待ちカウンタCaをインクリメント(Ca←Ca+1)するだけで(S670)、本処理を終了する。
【0048】
このように、本異常情報出力処理では、異常に関する情報は頻繁には変化するものではないとの考えに基づき、エンジンECU30が実行する各種のエンジン制御処理よりも低い優先度の処理とするために、その実行間隔(1024ms毎)を他の処理よりも長く設定して処理負荷を低減している。さらに、通信ライン5上の通信量を減らすため、上述したS610に示すように、送信待ちカウンタCaにて60回毎に送信している。つまり、この実施例では約1分毎に異常に関する情報が通信ライン5を介してエンジンECU30からトランスポンダ10へ送信されることとなる。
【0049】
続いて、送信待ちカウンタCaが60以上である場合(S610:YES)に移行するS620以降の処理について説明する。
この場合は、エンジン高回転時か(S620)、エンジン高負荷時、つまりスロットル開度が所定量以上かどうか(S630)、エンジン始動時か(S620)をそれぞれ判断し、該当状態でなければ順番に次のステップに進んでいく。そして、いずれかの状態に該当した場合、つまり、マイコン31の動作が忙しいエンジン高回転状態(S620:YES)あるいは高負荷状態(S630:YES)である場合、またはエンジン始動時である場合(S640:YES)には、本処理ルーチンを終了する。一方、いずれの状態でもない場合には、次ステップのS650に移行する。
【0050】
S650では、記憶されている異常情報(異常の有無、異常がある場合には異常対象のコード、その異常を検出した時点の運転状態データなど)をトランスポンダ10へ出力する。その後は、S660にて送信待ちカウンタCaをクリアして本処理ルーチンを終了する。
【0051】
このように、本処理においては、送信待ちカウンタCaが60以上となった場合に初めてS620に移行し、常情報の出力に適した期間であるかどうかの判断処理(S620〜S640)を実行するようにしており、送信待ちカウンタCaが60未満の場合には、単に送信待ちカウンタCaをインクリメントするだけである(S670)。これは、エンジンが高回転や高負荷の状態ではエンジンECU30の処理負荷が極めて高いので、異常情報の出力によって本来のエンジン制御処理に遅れが生じてしまうことを防ぐためである。特に、異常が検出されていて出力するデータが多量な場合には出力処理で他の処理が待たされる時間が長くなるが、エンジンECU30の処理負荷が小さい状態を見計らって出力すれば、通常の制御に支障を与えない。さらに、異常情報の出力は特に急を要するものではないので、少しぐらい遅らせても問題とはならない。
【0052】
また、このようにエンジンECU30の処理負荷が小さい状態(S620及びS630にて共にNO)であっても、エンジン始動時であれば(S640:YES)、やはり異常情報の出力は実行しない。これは、エンジン始動時はノイズ環境が悪いと想定されるので、このような状況での通信を避けることで、誤データがトランスポンダ10に送られてしまうことを防止している。
【0053】
次に、上述した構成のトランスポンダ10にて実行される処理について、図11〜図14を参照して説明する。
まず、図11に示す処理は、受信割込によって実行される処理であり、最初のステップS1010では、レシーバB(図1参照)からの異常情報の送信要求であるかどうかを判断する。異常情報の送信要求である場合には(S1010:YES)、送信要求フラグF(rq)を1にセットした上で(S1020)、ナビECU50には現在の車両位置を出力するよう要求し(S1030)、メータECU70には現在の累積走行距離を出力するよう要求する(S1040)。このS1040にて出力要求をした後、あるいは上述のS1010にて否定判断された場合には、本処理ルーチンを終了し、以前の処理に復帰する。
【0054】
また、図12に示す処理も、受信割込によって実行されるものであり、受信データを格納する処理を示している。
最初のステップS1110では、エンジンECU30からの情報出力であるかどうかを判断し、そうであれば(S1110:YES)、S1120へ移行してRAM内の所定の記憶領域D(EG)に受信データを記憶する。ここでの受信データは、上述した図10のS650にてエンジンECU30から出力された異常情報である。
【0055】
一方、エンジンECU30からの情報出力でない場合は(S1110:NO)、メータECU70からの情報出力であるかどうかを判断し(S1130)、そうであれば(S1130:YES)、S1140へ移行してRAM内の所定の記憶領域D(MT)に受信データを記憶する。ここでの受信データは、上述した図11のS1040にて行った走行距離情報の出力要求に応じてメータECU70から応答出力されたものである。
【0056】
さらに、メータECU70からの情報出力でもない場合は(S1130:NO)、ナビECU50からの情報出力であるかどうかを判断し(S1150)、そうであれば(S1150:YES)、S1160へ移行してRAM内の所定の記憶領域D(NV)に受信データを記憶する。ここでの受信データは、上述した図11のS1030にて行った位置情報の出力要求に応じてナビECU50から応答出力されたものである。
【0057】
S1120,S1140,S1160に示すように、エンジンECU30、メータECU70、ナビECU50からの受信データをRAM内の記憶領域D(EG),D(MT),D(NV)に記憶させた後、あるいはS1150にて否定判断された場合には、本処理ルーチンを終了し、以前の処理に復帰する。
【0058】
一方、図13に示す出力許可フラグセット処理は、例えば256ms毎に実行されるべース処理である。
この処理は、次の点を考慮したものである。つまり、上述したハード構成の説明でも述べたが、ナビECU50及びメータECU70は、共にアクセサリSW6がオフとなると動作が停止するので、その動作停止中にレシーバBから要求があっても、その時点での情報取得はできない。そのため、所定期間内にナビECU50及びメータECU70から情報を受信できなかった場合には、各ECU50,70は動作停止状態にあると判断し、それぞれの情報の受信完了に応じてセットされる出力許可フラグF(nv),F(mt)をセットする。このフラグがセットされていれば、それ以前に受信し、RAM内の所定の記憶領域D(NV),C(MT)に記憶されていた受信データを、レシーバBへの送信用のデータとして用いることができる。
【0059】
具体的な処理内容を説明する。まず最初のステップS1210では、送信要求フラグF(rq)がセットされているかどうかを判断する。上述した図11のS1020にて送信要求フラグF(rq)がセットされていると、このS1210にて肯定判断となるため、S1220へ移行し、ナビECU50から位置情報を受信済みであるかどうかを判断する。この受信済みかどうかは、上述した図12の受信データ格納処理にてS1160での記憶領域D(NV)に受信データを記憶する処理が実行されたかどうかで判断する。
そして、ナビECU50からの受信データを記憶済みの場合には(S1220:YES)、S1250へ移行して、受信完了に応じてセットされる出力許可フラグF(nv)をセットする。一方、受信データを記憶済みでなければ(S1220:NO)、カウンタCnvをインクリメントした上で(S1230)、そのカウンタCnvが40以上かどうかを判断する(S1240)。そして、カウンタCnvが40以上であれば(S1240:YES)、S1250へ移行して出力許可フラグF(nv)をセットするが、カウンタCnvが40未満であれば(S1240:NO)、S1250の処理を実行することなく、S1260へ移行する。
【0060】
S1260〜S1290においては、上述したS1220〜S1250にて実行したナビECU50に関する処理と同様の処理を、メータECU70に関する処理として実行する。つまり、メータECU70から走行距離情報を受信済みであるかどうかを判断し(S1260)、受信済みである場合には(S1260:YES)、S1290へ移行して、受信完了に応じてセットされる出力許可フラグF(mt)をセットする。一方、受信データを記憶済みでなければ(S1260:NO)、カウンタCmtをインクリメントした上で(S1270)、そのカウンタCmtが40以上かどうかを判断する(S1280)。そして、カウンタCmtが40以上であれば(S1280:YES)、S1290へ移行して出力許可フラグF(mt)をセットするが、カウンタCnvが40未満であれば(S1280:NO)、S1290の処理を実行することなく、本処理ルーチンを終了する。
【0061】
続いて、図14に示す送信処理ルーチンについて説明する。この送信処理は、例えば256ms毎に実行されるベース処理であり、まず、最初のステップS1310では送信要求フラグF(rq)が1にセットされているかどうか判断する。そして、送信要求フラグF(rq)が1にセットされていれば(S1310:YES)、続くS1320にて、出力許可フラグF(nv),F(mt)が共に1にセットされているかどうか判断する。
【0062】
そして、出力許可フラグF(nv),F(mt)が共に1にセットされていれば(S1320:YES)、診断データとしてRAM内の記憶領域D(EG),D(MT),D(NV)に格納されている受信データを、EEPROM14(図3参照)に記憶しているVINコードと共に、レシーバBに対して送信する。さらに、送信要求フラグF(rq)、出力許可フラグF(nv),F(mt)を0にセット、つまりクリアして(S1340)、本処理ルーチンを終了する。
【0063】
なお、送信要求フラグF(rq)が0の場合(S1310:NO)、あるいは出力許可フラグF(nv),F(mt)のいずれか一方でも0である場合は(S1320:NO)、そのまま本処理ルーチンを終了する。
次に、メータECU70にて実行される処理について図15,16を参照して説明する。
【0064】
図15に示す処理は、例えば64ms毎に実行されるベース処理であり、まず、最初のステップS2010にて、エンジンECU30から走行距離情報の要求があったかどうか判断し、要求があれば(S2010:YES)、その時点での走行距離情報をエンジンECU30に対して出力する(S2020)。このエンジンECU30から走行距離情報の要求は、上述した図9のS530の処理中にて出されるものである。そして、S2020で出力した走行距離情報は、同じく図9のS530の処理中において記憶されることとなる。
【0065】
一方、図16に示す処理も、例えば64ms毎に実行されるベース処理であるが、上記図15の処理がエンジンECU30からの要求に応答する処理であったのに対して、この図16の処理は、トランスポンダ10からの要求に応答したり、あるいは自発的に情報を出力する処理である。
【0066】
まず、最初のステップS2110にて、トランスポンダ10から走行距離情報の要求があったかどうか判断し、要求があれば(S2110:YES)、その時点での走行距離情報をエンジンECU30に対して出力し(S2140)、さらに、送信完了フラグF(TP)を1にセットして、本処理ルーチンを終了する。
【0067】
これが応答処理としての基本であるが、トランスポンダ10から走行距離情報の要求がない場合であっても(S2110:NO)、車速が0であり(S2120:YES)、さらに送信完了フラグF(TP)が0であれば(S2130:YES)、走行距離情報をエンジンECU30に対して出力するようにしている(S2140)。つまり、メータECU70は、アクセサリSW6がオフとなると動作が停止するので、その動作停止中にトランスポンダ10から要求されても応答できない。そのため、動作中は、トランスポンダ10からの要求がなくても、車速が0、つまり車両停止を検出する毎に1回、自発的にトランスポンダ10へその時点での走行距離情報を出力するようにしている。
【0068】
なお、図16のフローチャートにおいては、S2120にて否定判断、つまり車速が0でない場合はS2160へ移行して送信完了フラグF(TP)をクリアしており、また、S2130にて否定判断、つまり車速が0であっても(S2120:YES)、送信完了フラグF(TP)が1にセットされている場合はそのまま本処理ルーチンを終了する。これらは、上述したように、基本的にはトランスポンダ10からの要求に応答し、その要求がない場合であっても車両停止を検出する毎に1回だけ自発的にトランスポンダ10へ情報出力させるための処理である。
【0069】
次に、ナビECU50にて実行される処理について図17,18を参照して説明する。
図17に示す処理は、例えば64ms毎に実行されるベース処理であり、まず、最初のステップS3010にて、エンジンECU30から位置情報の要求があったかどうか判断し、要求があれば(S3010:YES)、その時点での位置情報をエンジンECU30に対して出力する(S3020)。このエンジンECU30から位置情報の要求は、上述した図9のS530の処理中にて出されるものである。そして、S3020で出力した位置情報は、同じく図9のS530の処理中において記憶されることとなる。
【0070】
一方、図18に示す処理も、例えば64ms毎に実行されるベース処理であるが、上記図17の処理がエンジンECU30からの要求に応答する処理であったのに対して、この図16の処理は、トランスポンダ10からの要求に応答したり、あるいは自発的に情報を出力する処理である。
【0071】
まず、最初のステップS3110にて、トランスポンダ10から位置情報の要求があったかどうか判断し、要求があれば(S3110:YES)、その時点での位置情報をエンジンECU30に対して出力し(S3140)、さらに、送信完了フラグF(TP)を1にセットして、本処理ルーチンを終了する。
【0072】
これが応答処理としての基本であるが、トランスポンダ10から位置情報の要求がない場合であっても(S2110:NO)、車速が0であり(S3120:YES)、さらに送信完了フラグF(TP)が0であれば(S3130:YES)、位置情報をエンジンECU30に対して出力するようにしている(S3140)。ナビECU50も、アクセサリSW6がオフとなると動作が停止するので、その動作停止中にトランスポンダ10から要求されても応答できない。そのため、動作中は、トランスポンダ10からの要求がなくても、車速が0、つまり車両停止を検出する毎に1回、自発的にトランスポンダ10へその時点での位置情報を出力するようにしている。
【0073】
なお、図18のフローチャートにおいて、車速が0でない場合(S3120:NO)にS2160へ移行して送信完了フラグF(TP)をクリアし、また、車速が0であっても(S3120:YES)、送信完了フラグF(TP)が1にセットされている場合は(S3130:NO)、そのまま本処理ルーチンを終了する。これらは、基本的にはトランスポンダ10からの要求に応答し、その要求がない場合であっても車両停止を検出する毎に1回だけ自発的にトランスポンダ10へ情報出力させるための処理である。
【0074】
これら図16及び図18を参照して説明したように、メータECU70あるいはナビECU50の動作停止があったとしても、動作中に車速が0(車両停止)になった場合には、走行距離情報あるいは位置情報がトランスポンダ10へ出力されるので、仮に動作中にトランスポンダ10からの出力要求が全くなかったとしても、各情報はトランスポンダ10において確実に記憶される。また、アクセサリSW6がオフされるのは、基本的には車両停止時にしかあり得ないため、その状況においてのみ情報出力することで、不必要な送信をなくすことができる。さらに、車両停止中は基本的に走行距離情報や位置情報が変化することはないので、車両停止時のみに情報を出力すれば、実状に合致した適切な情報がトランスポンダ10に記憶されることとなる。
【0075】
以上説明した処理を実行することによって、トランスポンダ10からレシーバBへは、異常が検出された時点の車両位置,累積走行距離と、レシーバBが車両に異常情報の送信を要求した時点の車両位置,累積走行距離とが送られることとなるので、レシーバBからデータを転送された管理センタCでは、異常となってからの車両Aの走行距離や移動状況がわかる。したがって、車両Aのユーザーに対して適切な処置を取ることができる。この適切な処置とは、例えば警告を通知したり、場合によっては通信を介して車両Aが安全な場所で停止した時点で強制的にエンジンを停止させるようにしたり、エンジンがユーザーにより切られた時に再度エンジンがかからなくなるようにするなどである。
【0076】
このように、本実施例の車両用診断装置によれば、車両Aに搭載された「制御ユニット」としての各ECU30,50,70がそれぞれ管轄する各種機器の状態を診断し、その診断結果は、通信ライン5で接続された「通信ユニット」としてのトランスポンダ10によって外部のレシーバBに送信され、さらに管理センタCへ転送される。これら各ECU30,50,70及びトランスポンダ10は、車載エンジンの駆動によって充電されるバッテリ3から供給された電力によって動作するが、バッテリ3からトランスポンダ10へは通常動作に必要な電力が常時供給されるよう構成されているため、トランスポンダ10は、レシーバBからの送信要求がいつ来ても、それに応じて診断結果を送信することができる。
【0077】
一方、バッテリ3から各ECU30,50,70へはイグニッションSW4あるいはアクセサリSW6によって、通常動作に必要な電力が供給される状態と供給されない状態とが切り替え可能に構成されている。そして、車両使用中は、イグニッションSW4あるいはアクセサリSW6はオンされるので、通常動作に必要な電力がバッテリ3から供給される。一方、車両不使用中は、イグニッションSW4及びアクセサリSW6は共にオフされるため、通常動作に必要な電力がバッテリ3からは供給されない。この意味で、エンジンECU30に対するイグニッションSW4、ナビECU及びメータECU70に対するアクセサリSWが、それぞれ「供給状態設定手段」に相当する。
【0078】
したがって、車両不使用中で車載エンジンが停止しておりバッテリ3が充電されない状況では、各ECU30,50,70への電力供給が低減される。具体的には、エンジンECU30のサブ電源回路34(図4参照)を介してマイコン31内のRAMに格納されたデータを保持するためだけの電力供給がなされるだけであるので、バッテリ3の消耗が相当少なくなる。
【0079】
つまり、いつ来るか判らないレシーバBからの送信要求に対して、いつ来てもそれに応答できるようにするため、トランスポンダ10に加えて各ECU30,50,70までも通常動作できるように準備しておくのはバッテリ消耗の点からすれば非合理的である。そこで、上記送信要求に応答するためだけであれば最低限トランスポンダ10だけ動作できればよいので、各ECU30,50,70への通常動作可能な電力の供給はしない。
【0080】
但し、車両不使用中は各ECU30,50,70へ通常動作可能な電力が供給されないため、その車両不使用中にレシーバBから送信要求があった場合、その時点で各ECU30,50,70からの情報を取得することはできない。したがって、トランスポンダ10は、その時点で各ECU30,50,70からの情報を取得する代わりに、車両Aが不使用状態になる以前の車両使用中に各ECU30,50,70から得た最新の情報を送信する。
【0081】
これによって、レシーバBからの送信要求がいつ来ても応答できるように構成されていながら、バッテリ消耗を極力少なくすることができる。
また、本実施例では、エンジンECU30からの診断結果は、エンジンECU30が主導で出力している。つまり、トランスポンダ10からの要求ではなく、所定時間毎に異常情報を出力することを基本としている(図10参照)。但し、その出力に不適切な期間は避けるようにしている。まず、エンジン高回転あるいは高負荷時で制御に要する処理負荷が大きいと考えられる期間である。エンジンに対する各種制御が本来の仕事であり、優先度は相対的に高く、一方、異常情報の出力は相対的に見れば優先度が低い。つまり、エンジンECU30が優先度の高い処理を実行するのに忙しい期間中においては、その優先度の高い処理を抑えてまで、あえて異常情報の出力という優先度の低い処理を実行する必要性はない。したがって、このような期間中にトランスポンダ10へ診断結果を出力する要求があっても、その要求には対応しない。さらに、エンジン始動に起因して通信ライン5上にノイズが発生していると考えられる期間もトランスポンダ10へ異常情報を出力しない。エンジン始動時はスタータを回転駆動させていることなどよって通信ライン5上にノイズが発生している可能性が高い。そのため、この状態でエンジンECU30からトランスポンダ10に異常情報が出力されると、通信ライン上5でデータ化けやデータ破壊が起こり、エンジンECU30から出力されたのとは違う誤った診断結果が管理センタCに送信されてしまう可能性がある。したがって、このような期間中にトランスポンダ10へ診断結果を出力する要求があっても、その要求には対応しない。
[その他]
(1)トランスポンダ10が各ECU30,50,70から取得する情報について考えてみる。
【0082】
上記実施例においては、エンジンECU30は自己の管理するタイミングにて異常情報を出力するようにしており、またナビECU50及びメータECU70は、基本的にはトランスポンダ10からの要求に応じて情報を出力するが、車両が停止した場合には、その時点で自発的に情報を出力する。したがって、車両不使用中にレシーバBからの送信要求があった場合、トランスポンダ10には、車両使用中において各ECU30,50,70から上述のタイミングで出力された最後の情報が記憶されていることとなる。その記憶された情報を「最新の診断結果」としてレシーバBに送信する。
【0083】
これ以外に次のようにすることも考えられる。例えばエンジンECU30について考えると、イグニッションSW4がオフされた時点から所定期間はエンジンECU30の通常動作に必要な電力が供給されている状態を継続することで、その所定期間中にエンジンECU30から異常情報を出力させるのである。例えば図4に示すサブ電源回路34から供給される電力によって、その異常情報出力処理を実行する。また、ナビECU50やメータECU70の場合にも同様にサブ電源回路を追加すればよい。
【0084】
もちろん、このようなサブ電源回路によって実現するのではなく、例えば車両運転手によるキー操作にてイグニッションSW4がオフされたりアクセサリW6がオフされた場合、そのオフ操作時点から所定の遅延時間後にバッテリ3から電源回路33,53,73への実際の電力供給を遮断するようにしてもよい。例えば、バッテリ3と電源回路33,53,73との間にイグニッションSW4ヤアクセサリSW6を迂回した電源ラインを設け、そのライン上に設けたリレーを、マイコンがイグニッションSW4やアクセサリSW6の状態に応じて制御するように構成すればよい。
【0085】
つまり、車両の使用状態から不使用状態への切り替わりタイミングは、運転手のキー操作によって定まるため、実際の電力供給停止をその切り替わりタイミングから遅延させればよい。
このようにすれば、「最新の診断結果」としてより適切なものが得られる。つまり、各ECU30,50,70から自発的に出力される情報の内の最後のものを「最新の診断結果」とする場合、出力間隔によっては、車両Aが使用状態から不使用状態に切り替わる直前の状態を反映した情報とはならない可能性もある。例えば、最後の情報を出力した後でも車両が走行している場合もあり、その走行によって新たな異常が発生する可能性もある。また、新たな異常がなくても、最終的に停止した時点の位置情報や走行距離情報との誤差が生じる可能性もある。そのため、上述の手法を採用すれば、車両が実際に停止した時点での位置情報や走行距離情報が得られる点で有利である。
【0086】
(2)また、上記実施例においては、エンジンECU30は自己の管理するタイミングにて異常情報を出力するようにしていたが、例えばトランスポンダ10から定期的あるいは非定期的に要求を出し、その要求に応じてエンジンECU30から異常情報を出力するようにしてもよい。
【0087】
そして、このように、エンジンECU30がトランスポンダ10からの要求に応じて異常情報を出力する場合には、上述した処理負荷が大きい期間やエンジン始動時のように異常情報の出力に不適切な期間への対処が問題となるが、やはりそれら不適期間中には応答しない、つまり異常情報は出力しないようにする。そして、例えば、不適期間中にトランスポンダ10から出力要求があった場合には、その要求には対応しないが、要求があったこと自体は記憶しておき、その後、不適期間に該当しない状況となった時点で、記憶されている診断結果の出力要求に応じて、異常情報をトランスポンダ10へ出力することが考えられる。
【0088】
このようにすれば出力要求へのレスポンスは向上する。なぜなら、出力要求が来た時点で不適期間中であるかどうかを判断し、不適期間中であれば対応せず、不適期間中でなければ対応するだけの場合には、不適期間が過ぎていても、その後に出力要求が来るタイミングを待たなくてはならない。つまり、必ずしも不適期間が過ぎた直後に出力要求が来るとは限らないからである。それに対して、診断結果の出力要求があったこと自体は記憶しておき、その後、不適期間に該当しない状況となった時点で出力要求に応じるようにすれば、対応して良い状態になったら即座に応じることができるため、出力要求へのレスポンスは向上する。
【0089】
(3)上記(2)のようにエンジンECU30がトランスポンダ10からの出力要求に応じてトランスポンダ10へ診断結果を出力することを前提とした場合には、次のような工夫も有効である。
つまり、トランスポンダ10が、エンジンECU30から診断結果が複数回出力され、かつ複数回の診断結果の内容が一致するまで、繰り返しエンジンECU30へ出力要求し、診断結果が一致すると、その一致した診断結果を管理センタ側へ送信するよう構成することが考えられる。エンジンECU30からトランスポンダ10に出力された診断結果の正確性向上を期すためには、有効である。
【0090】
また、トランスポンダ10に異常がある場合のエンジンECU30側の対処としては、次のようにすることも有効である。つまり、トランスポンダ10からの要求に応じて診断結果を所定回数以上出力したにもかかわらず、さらに診断結果の出力要求が来た場合には、それ以降の要求には対応しないようにする。
【図面の簡単な説明】
【図1】 実施例の車両用診断装置の搭載された車両を含む診断システムの概略説明図である。
【図2】 実施例の車両内の概略的なシステム構成を示すブロック図である。
【図3】 実施例のトランスポンダの構成を示すブロック図である。
【図4】 実施例のエンジンECUの構成を示すブロック図である。
【図5】 実施例のナビECUの構成を示すブロック図である。
【図6】 実施例のメータECUの構成を示すブロック図である。
【図7】 実施例のエンジンECUで実行されるメイン処理を示すフローチャートである。
【図8】 実施例のエンジンECUで実行されるダイアグ処理を示すフローチャートである。
【図9】 実施例のエンジンECUで実行されるダイアグ処理を示すフローチャートである。
【図10】 実施例のエンジンECUで実行される異常情報出力処理を示すフローチャートである。
【図11】 実施例のトランスポンダで受信割込にて実行される処理を示すフローチャートである。
【図12】 実施例のトランスポンダで受信割込にて実行される受信データ格納処理を示すフローチャートである。
【図13】 実施例のトランスポンダで実行される出力許可フラグセット処理を示すフローチャートである。
【図14】 実施例のトランスポンダで実行される送信処理を示すフローチャートである。
【図15】 実施例のメータECUで実行されるエンジンECUへの出力処理を示すフローチャートである。
【図16】 実施例のメータECUで実行されるトランスポンダへの出力処理を示すフローチャートである。
【図17】 実施例のナビECUで実行されるエンジンECUへの出力処理を示すフローチャートである。
【図18】 実施例のナビECUで実行されるトランスポンダへの出力処理を示すフローチャートである。
【符号の説明】
3…バッテリ 4…イグニッションSW
5…通信ライン 6…アクセサリSW
10…トランスポンダ 11…マイコン
12…入出力回路 13…電源回路
20…アンテナ
30…エンジンECU 31…マイコン
32…入出力回路 33…メイン電源回路
34…サブ電源回路 41…A/Fセンサ
42…回転センサ 43…エアフローメータ
44…水温センサ 45…スロットルセンサ
46…スタータSW 47…インジェクタ
48…イグナイタ 49…DIAGテスタ
50…ナビECU 51…マイコン
52…入出力回路 53…電源回路
60…GPSアンテナ 62…受信機
64…地図データ入力装置 66…表示モニタ
70…メータECU 71…マイコン
72…入出力回路 73…電源回路
80…メータパネル 85…車速センサ
A…車両 B…レシーバ
C…管理センタ
Claims (9)
- 車両に搭載されたエンジンを制御すると共に、前記エンジンのエミッションに関連する異常を診断する制御ユニットと、
当該制御ユニットと同じく前記車両に搭載され、前記制御ユニットと通信ラインで接続されており、前記制御ユニットから得た診断結果を、外部の管理センタ側からの送信要求に応じて当該管理センタ側に送信する通信ユニットと、
車載エンジンの駆動によって充電されるバッテリと、
を備え、前記制御ユニット及び通信ユニットは、前記バッテリから供給された電力によって動作するよう構成された車両用診断装置であって、
前記バッテリから前記通信ユニットへは通常動作に必要な電力が常時供給されるよう構成されており、一方、前記バッテリから前記制御ユニットへは通常動作に必要な電力が供給される状態と供給されない状態とが切り替え可能に構成されていると共に、
前記車両の使用中は、前記バッテリから前記制御ユニットへ通常動作に必要な電力が供給される状態に設定し、一方、前記車両の不使用中は、前記バッテリから前記制御ユニットへ通常動作に必要な電力が供給されない状態に設定する供給状態設定手段とを備え、
さらに、前記制御ユニットは通常動作に必要な電力が供給されて動作している際に前記通信ユニットに前記診断結果を送信するものであり、前記通信ユニットは、前記車両の不使用中に前記管理センタ側から送信要求があった場合には、前記制御ユニットが通常動作に必要な電力が供給されているときに前記制御ユニットから得ていた最新の診断結果を送信するよう構成されていること、を特徴とする車両用診断装置。 - 請求項1に記載の車両用診断装置において、前記車両使用中は、前記制御ユニットが、自発的に、あるいは前記通信ユニットからの出力要求に応じて前記通信ユニットへ診断結果を出力するよう構成されており、当該車両使用中に最後に出力された診断結果が、前記通信ユニットの送信する前記最新の診断結果であること、を特徴とする車両用診断装置。
- 請求項1に記載の車両用診断装置において、前記供給状態設定手段は、前記車両が使用状態から不使用状態に移行した場合、その移行時点から所定期間は前記制御ユニットの通常動作に必要な電力が供給されている状態を継続し、その後、通常動作に必要な電力が供給されない状態に切替設定するよう構成されていると共に、前記制御ユニットは、前記車両不使用状態への移行時点から所定期間中に診断結果を出力するよう構成されており、その所定期間中に出力された診断結果が、前記通信ユニットの送信する前記最新の診断結果であることを特徴とする車両用診断装置。
- 請求項1〜3のいずれかに記載の車両用診断装置において、前記制御ユニットは、エンジン始動に起因して前記通信ライン上にノイズが発生していると考えられる第1の不適期間中と、各種機器への制御に要する処理負荷が所定以上大きいと考えられる第2の不適期間中との少なくとも一方を判断し、前記不適期間と判断したときには、前記通信ユニットへ診断結果を出力するタイミングであっても出力せず、一方、前記不適期間に該当しない場合には、前記診断結果の出力タイミングにおいて、前記診断結果を前記通信ユニットに出力するよう構成されていること、を特徴とする車両用診断装置。
- 請求項1〜4のいずれかに記載の車両用診断装置において、前記車両使用中は、前記制御ユニットが、前記通信ユニットからの出力要求に応じて前記通信ユニットへ診断結果を出力するよう構成されており、前記通信ユニットは、前記制御ユニットから前記診断結果が複数回出力され、かつ当該複数回の診断結果の内容が一致するまで、繰り返し前記制御ユニットへ出力要求し、前記診断結果が一致すると、その一致した診断結果を前記管理センタ側へ送信するよう構成されていること、を特徴とする車両用診断装置。
- 請求項1〜5のいずれかに記載の車両用診断装置において、前記制御ユニットは、前記通信ユニットからの出力要求に応じて診断結果を所定回数以上出力したにもかかわらず、さらに診断結果の出力要求が来た場合には、それ以降の出力要求には対応しないよう構成されていること、を特徴とする車両用診断装置。
- 請求項1〜6のいずれかに記載の車両用診断装置において、前記通信ユニットが前記管理センタ側に送信する車両の診断結果に、当該車両固有の識別情報を含めること、を特徴とする車両用診断装置。
- 請求項1〜7のいずれかに記載の車両用診断装置において、前記通信ユニットが前記管理センタ側に送信する車両の診断結果に、診断時における当該車両の走行距離あるいは車両位置の少なくとも一方を含めること、を特徴とする車両用診断装置。
- 請求項1〜8のいずれかに記載の車両用診断装置において、前記制御ユニットの制御対象に少なくともエンジンが含まれていること、を特徴とする車両用診断装置。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP02486998A JP3843578B2 (ja) | 1998-02-05 | 1998-02-05 | 車両用診断装置 |
US09/218,498 US6285931B1 (en) | 1998-02-05 | 1998-12-22 | Vehicle information communication system and method capable of communicating with external management station |
US09/885,070 US6415210B2 (en) | 1998-02-05 | 2001-06-21 | Vehicle information communication system and method capable of communicating with external management station |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP02486998A JP3843578B2 (ja) | 1998-02-05 | 1998-02-05 | 車両用診断装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH11223577A JPH11223577A (ja) | 1999-08-17 |
JP3843578B2 true JP3843578B2 (ja) | 2006-11-08 |
Family
ID=12150225
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP02486998A Expired - Fee Related JP3843578B2 (ja) | 1998-02-05 | 1998-02-05 | 車両用診断装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3843578B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4501838B2 (ja) * | 2005-10-25 | 2010-07-14 | 株式会社デンソー | 車両用異常診断装置 |
JP2018148651A (ja) * | 2017-03-03 | 2018-09-20 | 株式会社Gsユアサ | 蓄電装置および車両 |
JP7183884B2 (ja) * | 2019-03-15 | 2022-12-06 | 株式会社デンソー | 電子制御装置 |
JP7268418B2 (ja) * | 2019-03-15 | 2023-05-08 | 株式会社デンソー | 通信システム、サーバ、及び車外検出装置 |
-
1998
- 1998-02-05 JP JP02486998A patent/JP3843578B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH11223577A (ja) | 1999-08-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4241953B2 (ja) | 車両用診断装置 | |
US6415210B2 (en) | Vehicle information communication system and method capable of communicating with external management station | |
JP3758356B2 (ja) | 車両用電子制御装置、電子制御ユニット及び記録媒体 | |
US8180521B2 (en) | Electronic control system for vehicle | |
US7920944B2 (en) | Vehicle diagnostic test and reporting method | |
US7698053B2 (en) | Economy running system, economy running controller and navigation apparatus | |
JP5012719B2 (ja) | 車載装置 | |
JP3994937B2 (ja) | 自動車用交通情報通知システム及びナビゲーションシステム | |
JP4337084B2 (ja) | 遠隔故障診断システム | |
JPH01210842A (ja) | 車輌診断装置 | |
JP2003022330A (ja) | 車両の故障診断システムおよび車両故障の情報管理装置 | |
JP2011039621A (ja) | 車両操作診断装置、車両操作診断方法及びコンピュータプログラム | |
US20130096769A1 (en) | Electronic control unit | |
US20090271087A1 (en) | Control device and engine control device | |
JP3843578B2 (ja) | 車両用診断装置 | |
JP7120079B2 (ja) | 車両の制御装置 | |
JP4289696B2 (ja) | 車両用診断装置 | |
JP2001093088A (ja) | 輸送運行管理システム | |
JP3799797B2 (ja) | 車両用診断装置 | |
JP2007076402A (ja) | 車両状態解析装置および車両状態解析システム | |
JPH0666197A (ja) | 車両の自己診断装置 | |
JP2005205997A (ja) | 車載システム | |
KR20030039108A (ko) | 차량 정보 제공 시스템 및 방법 | |
JP2006161604A (ja) | 車両故障診断装置 | |
JP3606243B2 (ja) | 車両内外間通信システム及び車内通信装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040715 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051025 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051214 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060404 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060529 |
|
A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060605 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060725 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060807 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090825 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100825 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100825 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110825 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120825 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130825 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |