JP2009035237A - 故障診断装置及び故障診断方法 - Google Patents

Abstract

【課題】異なる通信規格する車載ネットワークを有する車種に用いる故障診断装置において、初期化通信時間の短縮を図るとともに通信エラーの発生を回避できるようにする。
【解決手段】複数の電子制御装置３を有する車載ネットワークに多重通信線１５を介してテスタ１を接続して電子制御装置３から車両故障に関する情報を取得する故障診断装置であって、テスタ１は、複数の通信規格の車載ネットワークに対して接続可能に構成されて、テスタ１は通信の開始時には、複数の通信規格のうち第１の所定の通信規格でスタンバイして車載ネットワークＮＷ上の情報をモニタし、当該も似た情報に基づいて車載ネットワークＮＷの通信規格を判定する。
【選択図】図１

Description

本発明は、トラック、バス等の車両に搭載された各種のユニットやデバイスの電子制御装置（ＥＣＵ）に接続して故障診断を行う、故障診断装置及び故障診断方法に関するものである。

従来より、車両用電子制御系の故障診断を診断する故障診断装置が知られている（例えば、特許文献１参照）。このような故障診断装置では、図４に示すように、車両Ｖに設けられたＥＣＵ（電子制御装置）３とテスタ（マルチユーステスタ）１とが多重通信ライン（バスライン）２を介して接続されるようになっており、これによりテスタ１とＥＣＵ３との間で各種情報が送受信される。

ここで、ＥＣＵ３は自己診断機能（ダイアグノーシス機能）を有している。すなわち、ＥＣＵ３では各種センサ、アクチュエータ、スイッチからの入力信号及び各種のデバイス、アクチュエータ等への出力信号を監視し、これらの入出力信号に基づいて異常が生じているか否かを判定するとともに、異常判定した場合には、異常の内容（ダイアグノーシスコード）や異常発生時間等の情報をサービスデータとしてメモリ４に記憶するように構成されている。

そして、上記のテスタ１をＥＣＵ３に接続することでＥＣＵ３の異常発生に関する内容や時間等の情報を得ることができ、修理やトラブルシューティングに役立てることができるようになっている。
ところで、車両には通常ＥＣＵ３は複数設けられている。例えば、ＥＣＵとしてはエンジン制御用のエンジンＥＣＵ、自動変速機制御用のトランスミッションＥＣＵ、ＡＢＳ装置制御用のＡＢＳ−ＥＣＵ、空調装置（エアコンディショナー）制御用のエアコンＥＣＵなどが設けられている。これらの各ＥＣＵ３は相互通信可能にやはり多重通信ライン（バスライン）を介して接続されてネットワークを形成しており、各ＥＣＵ同士で必要な情報の送受信を行うようになっている。

このような構成により、例えばトランスミッションＥＣＵやＡＢＳ−ＥＣＵでは、エンジンＥＣＵから必要とする情報（例えば車速情報やエンジン回転数情報）等を受信して、トランスミッションやＡＢＳの制御に用いるようになっている。
一方、車戴ネットワークの通信規格としてとしては、ＣＡＮ，ＬＩＮ，Ｆｒｅｘ−Ｒａｙ，ＫＷＰ２０００等の様々なプロトコルが存在している。ここで、これらの各通信規格について簡単に説明すると、ＣＡＮはController Area Networkの略称であって、ＩＳＯにて国際的に標準化（ＩＳＯ１１８９８及びＩＳＯ１１５１９）されたシリアル通信プロトコルである。なお、ＣＡＮは現在では車載ネットワークとしても最も普及した通信規格ということができる。

また、ＬＩＮは、Local Interconnect Networkの略称であって、車載ネットワークのコストダウンを図ることを目的に主に海外の自動車メーカが提唱しているシリアル通信プロトコルである。なお、ＬＩＮはゲートウェイを介してＣＡＮネットワークと接続可能に構成されている。
また、Ｆｒｅｘ−ＲａｙはＣＡＮに対してより信頼性を高めるとともに高速で大量の情報の送受を可能とするべく策定されたプロトコルであって、予め決められたスケジューリングに基づいて情報を伝送するように規定されている。このため、耐障害性が高い、データ転送速度が速いといった特徴を有している。

また、ＫＷＰ２０００とは、Key Word Protocolの略称であり、国際規格ＩＳＯ１４２３０に準拠した自動車のダイアグノーシス用の通信規格である。なお、このＫＷＰ２０００は上述した各通信プロトコルとは異なり、複数のＥＣＵ同士で通信を行うものではなく、故障診断装置との間でダイアグノーシス情報の送受信を行うためのものである。
特開２００５−５９６７１号公報

ところで、上述したような故障診断装置では、従来より汎用性を持たせたテスタ１が開発されており、このため同一メーカの車両であれば車種を問わずに同一のテスタでダイアグノーシス診断を実行できるようになっている。
一方で、車載のＥＣＵは、ＣＡＮ通信を前提に製造されたものやＫＷＰ２０００での通信を前提に製造されたものなど、ＥＣＵのメーカ（サプライヤー）等によって通信の仕様が異なる場合があり、同一の車両であっても例えばＣＡＮでバス接続されたＥＣＵのネットワークとＫＷＰ２０００でバス接続されたＥＣＵのネットワークとが混在する場合がある。つまり、１台の車両に複数の通信規格がそれぞれ独立して混在する場合がある。

また、同一の車種であっても、車載ネットワークの規格が異なる場合も考えられる。つまり、同じ車種であっても装備の差異（例えば車間距離制御装置の有無など）に起因してＣＡＮを搭載した車両とＦｒｅｘ−Ｒａｙを搭載した車両とが混在する場合が考えられる。
このような各種の通信規格が混在する状況において、同一のテスタでダイアグノーシス診断を行うためには、ＥＣＵと通信を開始する前に対象のネットワークがどの通信規格であるのかを判別する必要がある。

このため、テスタ側では、対象となるネットワークの通信規格とは異なる通信規格も含め、全ての通信方式で通信規格判別用のテストデータを数秒送信し、このテストデータに対する返信の有無に基づいて対象となる通信規格を判定するように構成されている。なお、以下ではこのようなテストデータの送信を含む通信規格判定のための通信を初期化通信という。

この場合、本来であれば不要なテストデータまで余計に送信しなければならず、初期化通信時間が長くなるという課題があった。このため、実際に故障診断を開始するまでに無駄な時間が生じていた。
さらに、同じメーカの同じ車種、且つ同じ通信規格（例えばＣＡＮ）を採用している車両であっても、搭載している装置の有無や仕様の違いからネットワークの通信速度が異なる場合がある。例えば、同じＣＡＮを搭載していても、通信速度が５００kbpsの仕様の車両と２５０kbpsの仕様の車両とが混在する場合がある。

この場合、通信速度が５００kbpsであるバスラインに対して２５０kbpsのテストデータを送信するとＥＣＵでは送信データを理解できずにエラーフレームを出力してしまい、結果的に通信エラーが生じて故障診断や通常の情報の授受ができなくなる。また、通信速度が２５０kbpsであるバスラインに対して５００kbpsのテストデータを送信した場合も同様に通信エラーが生じるという課題がある。

本発明は、このような課題に鑑み創案されたもので、異なる通信規格や異なる通信速度が混在するようなネットワークを有する車種又は車両に用いる故障診断装置において、初期化通信時間の短縮を図るとともに、通信エラーの発生を回避できるようにすることを目的とする。

このため、請求項１に係る本願発明の故障診断装置は、複数の電子制御装置を有する車載ネットワークに多重通信線を介してテスタを接続して該電子制御装置から車両故障に関する情報を取得する故障診断装置であって、該テスタは、複数の通信規格の車載ネットワークに対して接続可能に構成されるとともに、該テスタは、通信の開始時には該複数の通信規格のうち第１の所定の通信規格でスタンバイして該車載ネットワーク上の情報をモニタし、該車載ネットワーク上から情報を受信すると該車載ネットワークの通信規格が第１の所定の通信規格であると判定するように構成されていることを特徴としている。

また、請求項２に係る本願発明の故障診断装置は、該第１の所定の通信規格で該車載ネットワーク上から情報を受信できない場合には、該第１の所定の通信規格とは異なる第２の所定の通信規格でスタンバイして該車載ネットワーク上の情報をモニタし、該車載ネットワーク上から情報を受信すると該車載ネットワークの通信規格が第２の所定の通信規格であると判定するとともに、該電子制御装置との通信を行うことを特徴としている。

また、請求項３に係る本願発明の故障診断装置は、該第１の所定の通信規格で該車載ネットワーク上から情報を受信できない場合には、該第１の所定の通信規格とは異なる第２の所定の通信規格で該電子制御装置との通信を開始することを特徴としている。
また、請求項４に係る本願発明の故障診断装置は、該モニタ時には、所定の電子制御装置の所定の情報をモニタすることを特徴としている。

また、請求項５に係る本願発明の故障診断装置は、該所定の電子制御装置とは、エンジンの作動を制御するエンジンＥＣＵであって、該所定の情報とは、エンジン回転数情報を含む特定の通信フレームであることを特徴としている。
また、請求項６に係る本願発明の故障診断装置は、該モニタ時には、該所定の情報を所定時間内で所定回数以上受信すると該車載ネットワークの通信規格がスタンバイ時の通信規格であると判定することを特徴としている。

また、請求項７に係る本願発明の故障診断方法は、複数の電子制御装置を有する車載ネットワークに多重通信線を介してテスタを接続して該電子制御装置から車両故障に関する情報を取得する故障診断方法であって、該テスタを該複数の通信規格のうち第１の所定の通信規格でスタンバイさせる第１ステップと、該第１ステップ後、該車載ネットワーク上の特定の情報をモニタする第２ステップと、該第２ステップ後、該所定の情報の受信に成功すると該車載ネットワークの通信規格が第１の所定の通信規格であると判定する第３のステップとを有することを特徴としている。

本発明の故障診断装置及び方法によれば、車載ネットワークにテスタを接続した時に不必要な初期化通信を行うことなく対象となる車載ネットワークの通信規格を判別することができるので、初期化通信に要していた通信時間を大幅に短縮することができる利点がある。また、初期化通信に起因する通信エラー等の通信不具合の発生も大幅に抑制することができる。また、新たな部品等を必要とせず、ソフトウェアの追加のみで実現可能であり、コスト増もほとんどないというという効果がある。

以下、図面を参照して本発明の第１の実施形態に係る故障診断装置について説明すると、図１はその要部構成を示す模式図である。また、この第１の実施形態では、車載ネットワークとしてＣＡＮとＫＷＰ２０００とを搭載した車両を例に用いて説明する。さらに、本第１実施形態では、同じ車種であっても搭載する装備に応じて、通信速度５００kbpsで構築されたＣＡＮを有する車両〔図１（ａ）参照〕と、通信速度２５０kbpsで構築されたＣＡＮを有する車両〔図１（ｂ）参照〕とが存在するような車両を対象としており、このような場合におけるＣＡＮの通信速度の判別手法について説明する。

図において、１１はパーソナルコンピュータ（以下、ＰＣと略称する）、１２はインタフェース機器としてのＶＣＩ（Vehicle Communication Interface）であって、これらのＰＣ１１及びＶＣＩ１２によりマルチユーステスタ（Multi Use Tester；以下、ＭＵＴ又はテスタと略称する）１が構成されている。
また、ＰＣ１１とＶＣＩ１２とは多重通信ライン（バスライン）１４を介して接続されるようになっている。また、ＶＣＩ１２は、車載ネットワークＮＷに接続可能に構成されており、ＶＣＩ１２の多重通信ライン１５の一端側のダイアグノーシスコネクタ１３ａを車両側のダイアグノーシスコネクタ１３ｂに連結することで、ＶＣＩ１２が車両側の複数の車載ネットワークＮＷと接続されるようになっている。

また、それぞれのネットワークＮＷには多重通信ライン（バスライン）を介して、所望のＥＣＵ３が接続されている。したがって、ＶＣＩ１２は通信ライン１５を介して車両の複数規格のバスラインに同時に接続することで、各種の電子制御装置（ＥＣＵ）３とＭＵＴ１とが通信可能となるように構成されている。
ここで、ＶＣＩ１２は、車載ネットワークＮＷからの情報をＰＣ１１で処理可能な信号に変換する機能を有している。また、ＰＣ１１には各種のソフトウェアが搭載されており、ＶＣＩ１２を介して取り込まれた車載ネットワークＮＷ上のＥＣＵ３の情報について各種の解析を行うとともに、その内容をディスプレイに表示するようになっている。

また、車載ネットワークＮＷとしては、通信プロトコルの異なる複数のネットワークが存在しており、本実施形態においては、上述したようにＣＡＮとＫＷＰ２０００とが設けられている。
なお、図１（ａ）は、ＣＡＮ（ここでは通信速度５００kbps）とＫＷＰ２０００とのネットワークを備えた車両にＭＵＴ１を接続した状態を示し、図１（ｂ）は、ＣＡＮ（同２５０kbps）とＫＷＰ２０００とのネットワークを備えた車両にＭＵＴ１を接続した状態を示している。

また、ＥＣＵ３としては、エンジン制御用のＥＣＵ３１やトランスミッション用ＥＣＵ３２、ＡＢＳ用ＥＣＵ３３、エアサスペンション用ＥＣＵ３４、エアコンＥＣＵ３５、パワーウィンド用ＥＣＵ３６等が存在している。そして、本実施形態においては、エンジン制御用ＥＣＵ３１，トランスミッション用ＥＣＵ３２，ＡＢＳ用ＥＣＵ３３及びエアサスペンション用ＥＣＵ３４がＣＡＮに接続されており、エアコンＥＣＵ３５及びパワーウィド用ＥＣＵ３６が第２ネットワークとしてのＫＷＰ２０００に接続されている。なお、以下では、各ＥＣＵについて特に区別する必要がない場合には単に符号３を用いる。

また、ＥＣＵ３は自己診断機能（ダイアグノーシス機能）を有しており、各種センサ，アクチュエータ及びスイッチ等を介して入出力される入力信号及びを監視し、これらの入出力信号に基づいて異常（故障）が生じているか否かを判定するとともに、異常判定した場合には、異常の内容（ダイアグノーシスコード）や異常発生時間等の情報をサービスデータとして図示しないメモリに記憶するように構成されている。

ところで、上記ＭＵＴ１（特にＶＣＩ１２）は汎用性を持たせるべく同じメーカの車両であれば車種を問わず使用可能に構成されている。しかしながら、既に説明したように、同じメーカの同じ車種で同じ通信規格（本実施形態ではＣＡＮ）を採用している車両であっても、ＥＣＵ３の仕様の違いから通信速度が異なる場合がある。例えば、同じＣＡＮを搭載していても、図１（ａ）に示すように通信速度が５００kbpsの車両もあれば、図１（ｂ）に示すように、通信速度が２５０kbpsの車両が存在する場合がある。

この場合、従来の技術では、通信速度が５００kbpsであるバスラインに対して２５０kbpsの初期化データを送信するとＥＣＵでは送信データを理解できずにエラーフレームを出力してしまい、結果的に通信エラーが生じて故障診断ができなくなる。また、通信速度が２５０kbpsであるバスラインに対して５００kbpsの初期化データを送信した場合も同様に通信エラーが生じるという課題がある。

そこで、本装置では以下のようにして通信規格（通信速度を含む）の自動判別を行うようになっている。まず、車両側のネットワークＮＷとＶＣＩ１２とを接続すると、ＶＣＩ１２では初期化情報を出力するのではなく、ネットワーク上でＥＣＵ３同士の情報をモニタする。ただし、ＶＣＩ１２側では、単にネットワーク上の情報をモニタしても、ＶＣＩ１２側で対応する通信規格で情報を受け取るように設定しておかないと、意味の有る信号として処理することができない。

このためで、ＶＣＩ１２においても、予め所定の規格（第１の所定の規格：例えばＣＡＮ，２５０kbps）で情報をモニタする準備をしておき（以下スタンバイという）、この状態でネットワーク上の情報を受信できれば、車両側のネットワークの通信規格が当該所定の規格であると判定するようになっている。なお、具体的には、ＶＣＩ１２ではスタンバイの動作として、電気的信号の１ビットの長さを２５０kbps相当となるように設定し、その後受信した信号を解析し、所定の意味のある信号（例えばエンジン回転数情報を含む信号）として受信したか否かを判定するようになっている。

一方、ＶＣＩ１２側で予め上記の所定の規格でスタンバイしておいた状態でネットワーク上の情報を受信することができなければ、このネットワークは所定の規格（例えばＣＡＮ，２５０kbps）ではないと判定し、上記所定の規格とは異なる第２の所定の規格（例えばＣＡＮ，５００kbps）でスタンバイする。この状態でネットワーク上の情報受信をリトライし、情報を受信できれば車両側のネットワークの通信規格が第２の所定の規格であると判定するようになっている。

さらに、このときに情報を受信することができなければ、第３の所定規格（例えばＬＩＮ）でスタンバイする。以降、このような処理を全ての通信規格に対して実行し、車載ネットワークの通信規格（通信速度）を判定するようになっている。なお、同一の通信規格において異なる通信速度を有するのは実用上ＣＡＮのみであり、ＣＡＮの時のみ通信速度を考慮したスタンバイを行うようになっている。

ここで、通信情報のモニタについて具体的に説明すると、この場合は、バス上の特定の通信フレーム（例えばフレーム名：ＦＬＭ０１）の信号をモニタする。この特定の通信フレームとは通信頻度の高い車両基本情報が好ましく、本実施形態ではエンジン回転数情報を含む通信フレームが適用されている。ただし、モニタする情報はエンジン回転数に限定されず、車速情報やトランスミッション変速段、シフトレンジ、冷却水温度などを用いてもよい。

そして、第１の所定規格でスタンバイした後、ＦＬＭ０１の情報を２００ｍｓ以内に２回以上受信できるか否かを判定し、上記の条件を満たすようなＦＬＭ０１を受信できれば、直ちに第１の所定規格で対象ネットワークと通信を開始するようになっている。なお、受信回数を２回以上としたのは判定精度を高めるためであり、精度上問題がなければ受信回数は１回でもよい。

また、ＦＬＭ０１を受信できなかった場合には第２の所定規格でスタンバイしてＦＬＭ０１の情報を上記の条件を満たすように受信できるか否かを判定する。受信できない場合には、以降同様にしてスタンバイ状態を他の通信規格（ＬＩＮ，Ｆｌｅｘ−Ｒａｙ等）に順次切り換えて情報の受信を行い通信規格を判別するのである。
なお、通信対象となるネットワークが第１の所定規格と第２の所定規格との２つのネットワークのみであることが明らかな場合（例えば、当該車両を製造するメーカが車載ネットワークの規格として、２種類の通信規格しか採用していない場合）には、第１の所定規格でモニタ不可の場合に、すぐに第２の所定規格で通信を開始するように設定しても良い。

そして、対象のネットワークと通信を完了したら、ＫＷＰ２０００で通信を行い、必要な情報を取り込むようになっている。
このようなネットワーク上の情報をモニタする手法では、従来の技術のような初期化データを送信することがないため、大幅に通信規格の判定及び通信開始までの時間を短縮することが可能となる。これは１つの初期化データの送信自体に数秒間オーダの時間が必要であるのに対し、ネットワーク上の情報をモニタする場合は本実施形態の場合２００ｍｓ程度でよく、たとえ５回モニタをリトライしても１秒程度で対象ネットワークの通信規格を判別することが可能となるためである。

本発明の第１の実施形態に係る故障診断装置は上述のように構成されているので、例えば図２に示すようなフローチャートに基づいて車載ネットワークの通信規格を判定するとともに故障診断を行う。
まず、ＶＣＩ１２のコネクタを車両側のコネクタに接続した状態で、システム選択を行う（ステップＳ１）。このシステム選択はオペレータにより行われる作業であって、故障診断の対象を選択するものである。例えばエンジンの故障の有無や故障履歴について知りたい場合、オペレータはＶＣＩ１２を操作して異常判定の対象としてエンジンを選択する。

次に、ＶＣＩ１２を第１の所定規格（ＣＡＮ，２５０ｋｂｐｓ）でスタンバイさせ（ステップＳ２、第１のステップに相当）、車載ネットワーク上の特定の通信フレームＦＬＭ０１をモニタする（ステップＳ３、第２のステップに相当）。なお、このようなＶＣＩ１２の作動制御はＰＣ１１にインストールされたソフトウェアにより実行される。
そして、この通信フレームＦＬＭ０１を正しく受信したか否か（つまり２００ｍｓ以内に２回以上受信したか否か）が判定され（ステップＳ４）、通信フレームＦＬＭ０１を正しく受信した場合には、第１の所定規格で通信開始を図り（ステップＳ５、以上ステップＳ４とステップＳ５とが第３のステップに相当）、通信に問題がなければ、これ以降、第１の所定規格で通信が行われる（ステップＳ６，ステップＳ７）。

また、通信開始が失敗した場合には、他の通信規格（例えばＫＷＰ２０００）に切り換えて通信する（ステップＳ８）。なお、この場合は、通信速度が異なる、通信方式が異なる、ダイアグノーシス機能の非対応ＥＣＵである等の原因が考えられる。
一方、第１の所定規格で通信フレームＦＬＭ０１を正しく受信できない場合には、第２の所定規格（ＣＡＮ，５００ｋｂｐｓ）でＶＣＩ１２をスタンバイさせ（ステップＳ９）、その後、上記の特定の通信フレームＦＬＭ０１をモニタする（ステップＳ１０）。

そして、通信フレームＦＬＭ０１を正しく受信したか否かが判定され（ステップＳ１１）、正しく受信した場合には、第２の所定規格で通信開始を図る（ステップＳ１２）。そして、通信に問題がなければ、これ以降、第２の所定規格で通信を行う（ステップＳ１３，ステップＳ１４）。また、通信開始が失敗した場合には上述したステップＳ８同様、他の通信規格に切り換えて通信する（ステップＳ１５）。

また、第２の所定規格において上記通信フレームＦＬＭ０１を正しく受信できない場合にも他の通信規格に切り換えてモニタを繰り返す（ステップＳ１６）。
以上、詳述したように、第１実施形態に係る故障診断装置によれば、車載ネットワークＮＷにＭＵＴ１を接続した時に、不必要な初期化通信を行うことなく対象となる車載ネットワークの通信規格を判別することができるので、従来よりも初期化通信に要していた通信時間を大幅に短縮することができる利点がある。また、このため通信エラー等の通信不具合の発生も大幅に抑制することができる。

また、本発明は新たな部品等を必要とせずに、ソフトウェアの追加のみで実現可能であり、コスト増もほとんどないという利点がある。
次に、本発明の第２実施形態について図３（ａ），（ｂ）を用いて説明すると、図３（ａ），（ｂ）は、それぞれ同じ車種であって、仕様の異なる２台の車両の車載ネットワークを示す図である。

具体的には、図３（ａ）に示すネットワークを備えた車両と、図３（ｂ）に示すネットワークを備えた車両とでは、居眠り防止装置及び車間距離制御装置の装備の有無が異なっている。なお、居眠り防止装置は、ドライバのステアリング操作等に基づいてドライバが居眠りしているか否かを判定するとともに、ドライバが居眠りしていると判定した場合には、音声等によりドライバに注意を促す装置であり、既に実用化されている公知の技術である。また、車間距離制御装置は、レーザレーダやミリ波レーダ等を用い先行車両を捕捉して、捕捉した先行車両に対して一定の距離を保って追従走行するようにアクセルや変速段を制御する装置である。また、先行車両との距離が所定値以下となると、音声等によりドライバに注意を促す機能やブレーキ操作を行う機能も有している。なお、この車間距離制御装置についても公知の技術である。

さて、このような居眠り防止装置及び車間距離制御装置に関しても、それぞれの装置の作動を制御するＥＣＵ、即ち居眠り防止装置用ＥＣＵ３７と車間距離制御装置用ＥＣＵ３８とが設けられている。
そして、図３（ａ）に示すように、このような居眠り防止装置及び車間距離制御装置を備えた車両では、他のＥＣＵも含めＥＣＵ３の数が多くなってしまうため、主にシャシ機能に関連するＥＣＵを接続したＣＡＮ（以下シャシＣＡＮという）と、主にエンジン等のパワートレイン系に関連するＥＣＵを接続したＣＡＮ（以下パワトレＣＡＮという）とに分割しており、これらシャシＣＡＮとパワトレＣＡＮとがＣＡＮコンバータ５を介して接続されている。なお、シャシＣＡＮ及びパワトレＣＡＮはいずれも通信速度２５０kbpsに設定されている。

そして、このようにＣＡＮを２系統に分割するとともに、ＣＡＮコンバータ５で相互に通信可能に接続することにより、ＥＣＵ３が増大した場合であっても確実にＥＣＵ同士で通信することができる。
また、ＣＡＮコンバータ５は、通信速度を変更する機能と、不要なデータのフィルタリング機能とを有している。ここで、ＣＡＮコンバータ５はＭＵＴ１に対して高速通信可能であって、本実施形態では５００ｋｂｐｓで通信可能に構成されている。一方、各ＥＣＵ３は、２５０ｋｂｐｓの仕様で設計されており、このためＣＡＮコンバータ５で通信速度を変換し、ＥＣＵ３とＭＵＴ１との間でデータの送受信を行うようになっている。

また、シャシＣＡＮとパワトレＣＡＮとの情報のやり取りはＣＡＮコンバータ５を介して行われるが、ＣＡＮコンバータ５よりも上流側（ＭＵＴ１側）では単に情報もモニタしても何ら情報を取得することができないようになっている。つまり、図３（ａ）に示すような構成では、ＣＡＮコンバータ５よりも上流側のバスラインには、ＭＵＴ１側からの要求がない限り、ＦＬＭ０１のような情報が流れないように構成されているのである。したがって、この場合にはたとえＶＣＩ１２を接続して５００kbpsでスタンバイしても、バスライン上の情報はモニタすることはできない。

一方、図３（ｂ）に示すように、居眠り防止装置及び車間距離制御装置を備えない車両では、コストダウンを図る目的でＣＡＮコンバータ５は省略される。つまり、ＥＣＵ３の数も図３（ａ）に示す場合よりは減少するので、あえてシャシＣＡＮとパワトレＣＡＮとに分けなくても十分ＥＣＵ同士で通信可能であれば、コスト増となるＣＡＮコンバータ５を用いることなく、１つのバスライン上でＣＡＮが構成される。なお、これは第１実施形態で説明した図１（ｂ）と同じである。

この場合には、ＣＡＮコンバータ５は存在しないため通信速度は２５０kbpsとなる。また、この場合は、バスライン上にＥＣＵ３が出力した各種情報が流れるので、ＶＣＩ１２ではＣＡＮ２５０ｋｂｐｓでスタンバイすることで容易に情報をモニタすることができる。
そして、本第２実施形態では、このような２種類の仕様の車両が存在する場合において、故障診断を行う際の初期化通信時間を短縮するべく、ＶＣ１１２ではまず２５０ｋｂｐｓでスタンバイするようになっており、この状態で特定の情報（フレーム名：ＦＬＭ０１）を受信することができれば、その後、２５０kbpsで通信を行うようになっている。また、情報を受信できない場合には、５００kbpsで通信を開始するようになっている。

なお、この場合、最初から５００ｋｂｐｓでスタンバイしてしまうと、上述のように、ＣＡＮコンバータ５を備えたネットワークではＣＡＮコンバータ５よりも上流側にはモニタできる情報が流れないので、ネットワークの通信速度が５００kbpsであるにもかかわらず何ら情報を得ることができない。このため、ＭＵＴ１では、接続したネットワークに対して２５０kbpsで通信を開始してしまい、通信エラーが生じてしまう。

したがって、このようなＣＡＮコンバータ５を備えた車両が存在する場合には、ＭＵＴ１としては、必ず最初に２５０kbpsスタンバイすることが必須となる。
本発明の第２実施形態に係る故障診断装置は上述のように構成されているので、第１実施形態と同様の作用効果を得ることができる。すなわち、ＣＡＮ２５０kbpsとＣＡＮ５００kbpsの通信速度の異なる車載ネットワークをそなえた車両に対して、不必要な初期化通信を行うことなく対象となる車載ネットワークの通信規格を判別することができる。

また、この場合、ＣＡＮコンバータ５を備えたネットワークでは、モニタする情報がＣＡＮコンバータ５よりも上流側では得ることができないが、先にＣＡＮコンバータ５を備えていない２５０kbpsのＣＡＮであるか否かを判定することにより、ＣＡＮ２５０kbpsとＣＡＮ５００kbpsとを容易に判別することができる。
以上、本発明の実施の形態について説明したが、本発明は上述の実施の形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々の変形例が可能である。例えば車載ネットワークの通信規格としてはＣＡＮ以外にもＬＩＮ及びＦｒｅｘ−Ｒａｙ等、種々の通信規格を適用することができる。また、第１実施形態においては、ＣＡＮ２５０kbps，ＣＡＮ５００kbps，ＬＩＮ，Ｆｌｅｘ−Ｒａｙの順でモニタするように構成されているが、第１実施形態においてはモニタの順番はどのように設定してもよい。

また、電子制御装置のとしてのＥＣＵは実施形態のものに限定されず、種々の電子制御装置を適用することができる。

本発明の第１実施形態に係る故障診断装置が適用される車載ネットワークについて示す模式図である。 本発明の第１実施形態に係る故障診断装置の作用について説明するためのフローチャートである。 本発明の第２実施形態に係る故障診断装置が適用される車載ネットワークについて示す模式図である。 従来の技術について説明するための図である。

符号の説明

１ マルチユーステスタ（ＭＵＴ又はテスタ）
３ ＥＣＵ（電子制御装置）
５ ＣＡＮコンバータ
１１ ＭＵＴを構成するパーソナルコンピュータ（ＰＣ）
１２ ＭＵＴを構成するインタフェース機器としてのＶＣＩ
１４，１５ 多重通信ライン（バスライン）
ＮＷ ネットワーク
１３ａ，１３ｂ ダイアグノーシスコネクタ

Claims (7)

1. 複数の電子制御装置を有する車載ネットワークに多重通信線を介してテスタを接続して該電子制御装置から車両故障に関する情報を取得する故障診断装置であって、
   該テスタは、複数の通信規格の車載ネットワークに対して接続可能に構成されるとともに、
   該テスタは、通信の開始時には該複数の通信規格のうち第１の所定の通信規格でスタンバイして該車載ネットワーク上の情報をモニタし、該車載ネットワーク上から情報を受信すると該車載ネットワークの通信規格が第１の所定の通信規格であると判定するように構成されている
   ことを特徴とする、故障診断装置。
2. 該第１の所定の通信規格で該車載ネットワーク上から情報を受信できない場合には、該第１の所定の通信規格とは異なる第２の所定の通信規格でスタンバイして該車載ネットワーク上の情報をモニタし、該車載ネットワーク上から情報を受信すると該車載ネットワークの通信規格が第２の所定の通信規格であると判定するとともに、該電子制御装置との通信を行う
   ことを特徴とする、請求項１記載の故障診断装置。
3. 該第１の所定の通信規格で該車載ネットワーク上から情報を受信できない場合には、該第１の所定の通信規格とは異なる第２の所定の通信規格で該電子制御装置との通信を開始する
   ことを特徴とする、請求項１記載の故障診断装置。
4. 該モニタ時には、所定の電子制御装置の所定の情報をモニタする
   ことを特徴とする、請求項１〜３のいずれか１項に記載の故障診断装置。
5. 該所定の電子制御装置とは、エンジンの作動を制御するエンジンＥＣＵであって、該所定の情報とは、エンジン回転数情報を含む特定の通信フレームである
   ことを特徴とする、請求項４記載の故障診断装置。
6. 該モニタ時には、該所定の情報を所定時間内で所定回数以上受信すると該車載ネットワークの通信規格がスタンバイ時の通信規格であると判定する
   ことを特徴とする、請求項４又は５記載の故障診断装置。
7. 複数の電子制御装置を有する車載ネットワークに多重通信線を介してテスタを接続して該電子制御装置から車両故障に関する情報を取得する故障診断方法であって、
   該テスタを該複数の通信規格のうち第１の所定の通信規格でスタンバイさせる第１ステップと、
   該第１ステップ後、該車載ネットワーク上の特定の情報をモニタする第２ステップと、
   該第２ステップ後、該所定の情報の受信に成功すると該車載ネットワークの通信規格が第１の所定の通信規格であると判定する第３のステップとを有する
   ことを特徴とする、故障診断方法。

Images