(57)【要約】【課題】車両側との通信トラブルなのか、あるいは、車両側が応答不可状態であるのかを管理センタ側で判別できるようにする。【解決手段】車両に搭載されるエンジンＥＣＵの処理負荷を判定し（ステップＳ６０５）、処理負荷が大きいと判定される場合には、管理センタに対して応答不可メッセージを送信し（ステップＳ６４０）、処理負荷が小さいと判定される場合には、ダイアグデータを管理センタに対して送信する（ステップＳ６６０）。管理センタでは、この応答不可メッセージを受信することにより、車両側との通信トラブルなのか、応答不可状態であるのかを判別することができる。【選択図】        図６
2004284408.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された機器の動作を制御するとともに、前記機器の状態を診断する制御装置と、
前記制御装置による診断結果を外部へ送信し、前記外部からデータを受信する通信装置とを備え、
前記制御装置は、前記機器の制御に要している負荷の大きさを判定する負荷判定手段と、
外部から診断結果の応答要求があったときに前記負荷判定手段によって前記負荷が所定以上の大きさであると判定した場合、前記診断結果を送信せずに所定の応答を前記通信装置を介して外部へ送信する所定応答送信手段とをさらに備えることを特徴とする車両用診断装置。
【請求項２】
前記所定応答送信手段は、前記所定の応答として前記外部に対して応答不可能である内容の応答を送信することを特徴とする請求項１記載の車両用診断装置。
【請求項３】
前記所定の応答は、前記診断結果の送信データ量よりも少ない送信データ量を有することを特徴とする請求項１又は２記載の車両用診断装置。
【請求項４】
前記所定応答送信手段は、前記所定の応答として、前記応答時間の延長を前記外部に対して要求する応答時間延長要求を送信することを特徴とする請求項１〜３のいずれかに記載の車両用診断装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、車両用診断装置に関するものである。
【０００２】
【従来の技術】
従来、車両に搭載された各種機器の状態を診断し、その診断結果を外部の管理センタへ送信する車両用診断装置がある（例えば、特許文献１参照。）。この特許文献１に開示されている車両用診断装置によれば、例えば、各種機器を制御する制御ユニットによって各種機器の状態を診断し、その診断結果を制御ユニットと通信ラインで接続された通信ユニットから管理センタへ送信する。そして、制御ユニットは、各種機器への制御に要する処理負荷が高い場合には、通信ユニットへ診断結果を出力する要求があってもその要求には応答せず、処理負荷が低くなったときに診断結果の出力要求に応じて診断結果を出力する。これにより、制御ユニットの本来実行すべき各種機器への制御が優先して行える。
【０００３】
【特許文献１】
特開平１１−２０１８７２号公報
【０００４】
【発明が解決しようとする課題】
従来の車両用診断装置は、各種機器への制御に要する処理負荷が高い場合、診断結果の出力要求に応答しないため、管理センタ側では、実際に制御ユニットが高負荷で応答できないのか、あるいは、通信ユニットとの間で通信トラブルが発生したのかを判別することができなかった。
【０００５】
本発明は、かかる問題を鑑みてなされたもので、車両側との通信トラブルなのか、あるいは、車両側が応答不可状態であるのかを管理センタ側で判別することができる車両用診断装置を提供することを目的とする。
【０００６】
【課題を解決するための手段】
請求項１に記載の車両用診断装置は、車両に搭載された機器の動作を制御するとともに、機器の状態を診断する制御装置と、制御装置による診断結果を外部へ送信し、外部からデータを受信する通信装置とを備え、制御装置は、機器の制御に要している負荷の大きさを判定する負荷判定手段と、外部から診断結果の応答要求があったときに負荷判定手段によって負荷が所定以上の大きさであると判定した場合、診断結果を送信せずに所定の応答を通信装置を介して外部へ送信する所定応答送信手段とをさらに備えることを特徴とする。
【０００７】
このように、本発明の車両用診断装置は、機器の制御に要している負荷が大きい場合、所定の応答を外部へ送信する。これにより、例えば、外部の管理センタ等では、通信装置から受信した応答を受け取ることで、通信装置との間の通信トラブルではなく、制御装置の処理負荷が大きいために診断結果が送信されないことを把握することができる。なお、請求項２に記載のように、所定応答送信手段は、所定の応答として外部に対して応答不可能である内容の応答を送信することで、外部の管理センタ等では、この応答から制御装置の処理負荷が大きいことを把握することができる。
【０００８】
請求項３に記載の車両用診断装置によれば、所定の応答は、診断結果の送信データ量よりも少ない送信データ量を有することを特徴とする。すなわち、制御装置の制御に要している処理負荷が大きい状態であるときに、診断結果と同じようなデータ量の応答を送信すると、制御の処理に影響を与えかねない。そこで、例えば、処理に影響を与えることのないデータ量の応答を送信することで、制御装置は、各種機器の制御を通常通り実行しながら応答不可能である内容の応答を外部の管理センタ等に対して行うことができる。
【０００９】
請求項４に記載の車両用診断装置では、所定応答送信手段は、所定の応答として、応答時間の延長を外部に対して要求する応答時間延長要求を送信することを特徴とする。これにより、外部の管理センタ等では、車両側との通信接続を保持したまま、車両側からの応答を待つことができるため、車両側に何度も診断結果の送信要求を出す必要がなくなる。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態における車両用診断装置に関して、図面に基づいて説明する。図１は、車両用診断装置の搭載された車両を含む診断システムの概略構成を示す図である。管理センタＣは、通信機Ｂを介して、複数の車両Ａから後述するダイアグデータを無線通信にて入手する。
【００１１】
管理センタＣは、例えば、各車両Ａから送信されたダイアグデータに基づいて不具合のある車両Ａを特定し、その車両の保有者に対して車両Ａの修理・改善を通信機Ｂを介して通知する。
【００１２】
図２は、車両Ａに搭載される車両用診断装置の概略構成を示すブロック図である。同図に示すように、車両Ａには、トランスポンダ１０、エンジンＥＣＵ３０、ナビＥＣＵ５０、及びメータＥＣＵ７０によって構成され、各々が通信ライン５によって接続されている。
【００１３】
トランスポンダ１０は、通信機Ｂからの要求を受け、エンジンＥＣＵ３０、ナビＥＣＵ５０、メータＥＣＵ７０から必要なデータを通信ライン５を介して入手し、その入手したデータからなるダイアグデータを通信機Ｂに対して送信する。
【００１４】
このダイアグデータとは、例えば、エンジンＥＣＵ３０によって生成されるエンジンのエミッションに関する異常検出結果、エンジン故障の診断結果、ナビＥＣＵ５０やメータＥＣＵ７０等によって生成される各ＥＣＵにおける異常検出結果等のデータによって構成されるものである。なお、本実施形態では、ダイアグデータを生成するＥＣＵとして、エンジンＥＣＵ３０、ナビＥＣＵ５０、及びメータＥＣＵ７０を例として取り上げているが、ドアＥＣＵやシードベルトＥＣＵ等、車両に搭載される各ＥＣＵから生成される異常検出結果をダイアグデータとして構成してもよい。
【００１５】
エンジンＥＣＵ３０は、燃料を噴射するインジェクタ等の制御を実行するとともに、エミッション異常やエンジン故障を自己診断する。この診断結果データは、エンジンＥＣＵ３０内のＲＡＭに記憶される。
【００１６】
ナビＥＣＵ５０は、道路地図表示や経路誘導等のナビゲーション制御を実行する。メータＥＣＵ７０は、図示しないメータの表示制御を実行する。また、このナビＥＣＵ５０、及びメータＥＣＵ７０は、これらの制御と共に、それぞれ自己診断にて何らかの異常を検出したときに、その異常検出結果データを各ＥＣＵ内のＲＡＭに記憶する。
【００１７】
図３にトランスポンダ１０の内部構成のブロック図を示す。同図に示すように、トランスポンダ１０は、マイコン１１、入出力回路１２、電源回路１３、ＥＥＰＲＯＭ１４によって構成される。
【００１８】
電源回路１３は、トランスポンダ１０が動作するための電力を供給する。この電源回路１３は、バッテリ３から常時電力が供給されているので、車室内の運転席付近に設けられるキーシリンダ（図示しない）に挿入されるキーの操作に関係無く動作する。
【００１９】
マイコン１１は、いずれも図示しない周知のＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等によって構成される。ＣＰＵは、ＲＯＭに記憶された制御プログラムに従って、アンテナ２０を介して外部からの要求に応じた処理を実行する。ＲＡＭには、エンジンＥＣＵ３０等からのデータ等が一時的に記憶される。
【００２０】
入出力回路１２には、アンテナ２０及び通信ライン５が接続されており、この入出力回路１２を介してデータの送受信が行われる。また、ＥＥＰＲ０Ｍ１４には、車両固有の識別番号が記憶されている。
【００２１】
図４に、エンジンＥＣＵ３０の内部構成のブロック図を示す。同図に示すように、エンジンＥＣＵ３０は、マイコン３１、入出力回路３２、メイン電源回路３３、サブ電源回路３４によって構成される。マイコン３１は、トランスポンダ１０に用いられるマイコン１１と同様に、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等によって構成される。
【００２２】
マイコン３１に接続されるメイン電源回路３３は、イグニションＳＷ４を介してバッテリ３と接続されており、キーシリンダに挿入されるキーの操作によりイグニッションＳＷ４が投入され、メイン電源回路３３に電源が供給される。これにより、マイコン３１に電源が供給される。
【００２３】
なお、メイン電源回路３３と共にマイコン３１に接続されるサブ電源回路３４は、イグニッションＳＷ４を介さずにバッテリ３と接続されている。従って、マイコン３１には常に電源供給されるため、マイコン３１のＲＡＭのデータがイグニッションＳＷ４のオフ後も保持される。
【００２４】
マイコン３１では、ＣＰＵがＲＯＭに記憶された制御プログラムに従い、入出力回路３２及びマイコン３１内のＩ／Ｏを介して入力した各種センサからの信号に基づいて、エンジンが最適な動作をするようインジェクタ４７やイグナイタ４８を制御する信号を出力する。
【００２５】
また、マイコン３１では、エンジンの動作、エミッション、及び各種センサ４１〜４６の異常等を診断し、ＤＩＡＧテスタ４９やトランスポンダ１０からの要求に応じて診断結果データを出力する。なお、ＲＡＭは、ＣＰＵでの演算処理に使うセンサデータ、演算にて求められた制御データ、あるいは上記診断にて得た種々の診断データ等を保持している。
【００２６】
図４に示すように、入出力回路３２には、空燃比（Ａ／Ｆ）センサ４１、エンジンの回転数を検出する回転センサ４２、エアフローセンサ４３、水温センサ４４、スロットルセンサ４５、スタータＳＷ４６が接続され、入出力回路３２は、これら各センサからの信号を入力する。
【００２７】
次に、トランスポンダ１０における受信割込み処理を、図５に示すフローチャートを用いて説明する。先ず、管理センタＣからのダイアグデータ要求を受信すると、受信割込みが発生し、以下の処理を実行する。
【００２８】
ステップＳ５００では、受信データがダイアグデータ要求のデータであるか否かを判定する。ここで、受信データがダイアグデータ要求である場合には、ステップＳ５１０へ処理を進め、これに該当しないデータ（例えば、ダイアグデータ要求以外のデータや不正なデータ等）の場合には、ステップＳ５２０において、受信データを破棄する。
【００２９】
ステップＳ５１０では、通信ライン５を介してダイアグ要求データが各ＥＣＵへ送信され、各ＥＣＵが受信する。なお、このダイアグ要求データには、受信先を示すデータが含まれており、該当するＥＣＵのみが応答するように構成されている。各ＥＣＵは、このダイアグ要求データを受けて、ダイアグコードやダイアグコードを検出した時の状況に関するデータをダイアグデータとしてトランスポンダ１０へ出力する。
【００３０】
続いて、エンジンＥＣＵ３０において、ダイアグ要求データを受信した場合の処理について、図６及び図７に示すフローチャートを用いて説明する。先ず、図６のステップＳ６００では、ダイアグ要求データを受信したか否かを判定する。ここで、肯定判定される場合にはステップＳ６０３へ処理を進め、否定判定される場合には本処理を終了する。
【００３１】
ステップＳ６０３では、エンジンＥＣＵ３０の処理負荷を判定する負荷判定処理を実行する。この負荷判定処理について、図７を用いて説明する。同図に示すステップＳ７００では、エンジン回転数は、所定回転数以上の高い回転数であるか否かを判定する。ここで、肯定判定される場合には、ステップＳ７０５において、変数ＦＨＴに１を加える。なお、変数ＦＨＴの初期値は「０」である。一方、否定判定される場合には、ステップＳ７１０へ処理を移行する。
【００３２】
ステップＳ７１０では、図示しないシフトレバーの操作によって変速がなされ、それに伴う変速処理の実行中であるか否かを判定する。ここで、肯定判定される場合には、ステップＳ７１５において変数ＦＨＴに１を加え、否定判定される場合には、ステップＳ７２０へ処理を移行する。
【００３３】
ステップＳ７２０では、スロットル開度の変化量が所定量以上であるか否かを判定する。ここで、肯定判定される場合には、ステップＳ７２５において変数ＦＨＴに１を加え、否定判定される場合には、ステップＳ７３０へ処理を移行する。
【００３４】
ステップＳ７３０では、他のＥＣＵ等とのデータ通信の処理中であるか否かを判定する。ここで、肯定判定される場合には、ステップＳ７３５において変数ＦＨＴに１を加え、否定判定される場合には、ステップＳ７４０へ処理を移行する。
【００３５】
ステップＳ７４０では、変数ＦＨＴが所定値よりも大きい値であるか否かを判定する。ここで、肯定判定される場合には、ステップＳ７５０において、エンジンＥＣＵ３０の処理負荷が「大」であるとする。また、否定判定される場合には、ステップＳ７６０において、エンジンＥＣＵ３０の処理負荷が「小」であるとする。
【００３６】
図６のステップＳ６０５では、図７において処理された負荷判定結果が「大」であったか否かを判定し、肯定判定される場合には、ステップＳ６１０へ処理を進め、否定判定される場合には、ステップＳ６５０へ処理を移行する。
【００３７】
ステップＳ６１０では、変数ＣＮＴの値が１０よりも大きい値であるか否かを判定する。ここで、肯定判定される場合には、ステップＳ６４０へ処理を移行し、否定判定される場合には、ステップＳ６２０へ処理を進める。なお、この変数ＣＮＴの判定に用いられる閾値は、任意に設定される値である。
【００３８】
変数ＣＮＴの値が１０以下であると判定されると、ステップＳ６２０において、変数ＣＮＴに１が加算され、ステップＳ６３０において、エンジンＥＣＵ３０の処理負荷が高く、ダイアグデータを直ぐに送信することができないため、応答時間延長要求が送信される。
【００３９】
この応答時間延長要求は、通信ライン５を介してトランスポンダ１０に送信され、トランスポンダ１０を介して管理センタＣへ送信される。管理センタＣでは、この応答時間延長要求を受信すると、トランスポンダ１０との通信接続を保持したまま、エンジンＥＣＵ３０からの応答があるまで待機状態となる。
【００４０】
その後、ステップＳ６０３以降の処理が繰り返され、ステップＳ６１０において１０回繰り返したと判定されると、ステップＳ６４０において、応答不可である内容を示す応答不可メッセージが送信される。この応答不可メッセージは、上述したように、通信ライン５を介してトランスポンダ１０に送信され、管理センタＣへ送信される。
【００４１】
この管理センタＣに対して送信される応答不可メッセージや応答時間延長要求の送信データ量は、ダイアグデータの送信データ量よりも少ないデータ量である必要がある。すなわち、エンジンＥＣＵ３０の処理負荷が大きいときに、ダイアグデータと同じようなデータ量のデータを送信すると、エンジンＥＣＵ３０の処理に影響を与えかねない。そのため、例えば、エンジンＥＣＵ３０の処理に影響を与えることのない少ないデータ量の応答不可メッセージや応答時間延長要求を送信することで、エンジンＥＣＵ３０は、通常通りの処理を行いながら、管理センタＣに対して応答することができる。
【００４２】
一方、エンジンＥＣＵ３０の処理負荷が「小」である場合、ステップＳ６５０において、変数ＣＮＴを初期化（例えば、「０」に設定する等）したのち、ステップＳ６６０にて、ダイアグデータを送信する。このダイアグデータは、トランスポンダ１０を介して管理センタＣへ送信される。
【００４３】
このように、本実施形態における車両用診断装置は、エンジンＥＣＵ３０の処理負荷が大きい場合、応答不可メッセージを管理センタＣへ送信する。これにより、管理センタＣでは、車両Ａとの間の通信トラブルではなく、エンジンＥＣＵ３０の処理負荷が大きいためにダイアグデータが送信されないことを把握することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係わる、車両用診断装置の搭載された車両Ａを含む診断システムの概略構成を示す図である。
【図２】本発明の実施形態に係わる、車両Ａに搭載される車両用診断装置の概略構成を示すブロック図である。
【図３】本発明の実施形態に係わる、トランスポンダ１０の内部構成を示すブロック図である。
【図４】本発明の実施形態に係わる、エンジンＥＣＵ３０の内部構成を示すブロック図である。
【図５】本発明の実施形態に係わる、トランスポンダ１０における受信割込み処理を示すフローチャートである。
【図６】本発明の実施形態に係わる、エンジンＥＣＵ３０においてダイアグ要求データを受信した場合の処理を示すフローチャートである。
【図７】本発明の実施形態に係わる、負荷判定処理を示すフローチャートである。
【符号の説明】
１０  トランスポンダ
３０  エンジンＥＣＵ
５０  ナビＥＣＵ
７０  メータＥＣＵ
Ａ  車両
Ｂ  通信機
Ｃ  管理センタ
【図１】
2004284408.tif 000003
【図２】
2004284408.tif 000004
【図３】
2004284408.tif 000005
【図４】
2004284408.tif 000006
【図５】
2004284408.tif 000007
【図６】
2004284408.tif 000008
【図７】
2004284408.tif 000009