JP2012086601A - 電子制御ユニット、車載システム、ノード監視方法 - Google Patents

電子制御ユニット、車載システム、ノード監視方法 Download PDF

Info

Publication number
JP2012086601A
JP2012086601A JP2010232866A JP2010232866A JP2012086601A JP 2012086601 A JP2012086601 A JP 2012086601A JP 2010232866 A JP2010232866 A JP 2010232866A JP 2010232866 A JP2010232866 A JP 2010232866A JP 2012086601 A JP2012086601 A JP 2012086601A
Authority
JP
Japan
Prior art keywords
ecu
communication
message
node
electronic control
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.)
Pending
Application number
JP2010232866A
Other languages
English (en)
Inventor
Yusuke Sato
雄介 佐藤
Tomohiko Endo
知彦 遠藤
Hiroya Ando
博哉 安藤
Katsutomo Sasakura
克友 笹倉
Maki Kaneda
真貴 金田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toyota Motor Corp
Original Assignee
Toyota Motor Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toyota Motor Corp filed Critical Toyota Motor Corp
Priority to JP2010232866A priority Critical patent/JP2012086601A/ja
Publication of JP2012086601A publication Critical patent/JP2012086601A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Small-Scale Networks (AREA)

Abstract

【課題】車載ネットワークの断線や接触不良による通信障害が生じた場合、通信障害が生じた箇所を特定可能な電子制御ユニット、車載システム及びノード監視方法を提供すること。
【解決手段】複数のノードB〜Eの故障を監視する電子制御ユニットAであって、複数のノードが1回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、ノードが検出されない順位情報と共に記録する通信途絶検出手段11を有し、前記通信途絶検出手段11は、所定期間毎に、前記略一定時間内に通信が検出されないノードと順位情報の記録を行う、ことを特徴とする。
【選択図】図3

Description

本発明は、車載ネットーワークに接続されたノードを監視する電子制御ユニットに関し、特に、ノードの通信異常を監視する電子制御ユニット等に関する。
車両の電子制御装置は各種の車載装置の動作を制御しているが、電子化の進行により数多くの電子制御装置が搭載されるようになっている。これらの電子制御装置を車載LANにより接続し互いに情報を通信可能とすることでより高度な制御が実現されている。
車載LANの1つにCAN(Controller Area Network)があるが、CANには故障したノード(各ECUのこと)を特定しにくいという性質がある。
図1(a)は、CANのネットワーク構造の一例を示す図である。CANでは各ECUが2本の電線(例えば、ツイストペア線)でCANバスに接続され、2本の電線の差動電圧がHかLによりデータを表す。このためCANでは2本の電線のうち1本でも断線や接触不良があると、CANバスと電線の間が断線したECUが送出する信号はL(ドミナント:優勢)となってしまい、正常な通信は困難になる。
例えば、図1(b)のようにECU-EとCANバスの間の電線が断線した場合、ECU-Eは正常な通信はできないが、他のECU-A〜Dも正常な通信が困難になる場合がある。これは、CANはCSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)というアクセス制御を採用しているためで、各ECUは、CANバスの状態(H又はL)を監視して、自分より優先順位の高いECUが送信を開始すると自分の送信を停止させる。しかし、ECU-Eは1本の電線が断線しているため、他のECUが通信しているかどうか分からず、ECU-Eが信号を送信することで他のECUが送信した信号を破壊してしまう。
図2を用いて説明する。図2はCANバスに流れる信号を模式的に示す図の一例である。図2の1つのブロックは、各ECUが送信した1フレーム(以下、メッセージという)である。図2(a)は図1(a)のようにECU-EとCANバスの間を含め、各ECUと電線の間に断線や接触不良(以下、断線等という)がない場合のメッセージを示す。断線等がない場合、各ECUはそれぞれ異常のないメッセージを送信することができる。
図2(b)は図1(b)のように断線等がある場合のメッセージを示す。ECU-EとCANバスの間の電線が断線等した場合、ECU-Eが通信できないだけでなく、他のECUの通信も阻害するおそれがある。これは、ECU-B,ECU-Dがメッセージを送信する際、ECU-Eはドミナント固定の信号を送信するので、他のECUによりバスが使用されることを検出できずメッセージを送信した場合、ECU-B,ECU-Dが送信したメッセージを破壊してしまうためである。
この結果、他のECUは、ECU-Eの送信するメッセージ、ECU-B、ECU-Dが送信するメッセージを受信することができない。なお、ECU-B、ECU-Dが送信するメッセージであっても、ECU-B、ECU-Dの送信中に、ECU-Eがメッセージを送信しなければ、破壊されることはない。
この場合、故障したECUの候補としてECU-E、B、Dが挙げられるが、実際に故障したのはECU-Eだけであるため、図2(b)のような通信エラーを記録できたとしても、どのECUが実際に故障したのかを特定することは容易でない。
そこで故障したECUを特定する方法が考案されている(例えば、特許文献1参照。)。特許文献1にはCANに代表ノードを接続し、代表ノードが各ECUと定期的に通信する通信方法が開示されている。各ノードは代表ノードからメッセージを受信できないと通信を停止するので、代表ノードは各ノードからメッセージ(応答確認メッセージという)を受信できないことで、複数の各ノードのうち故障が発生したノードを特定することができる。
特開2006−135375号公報
しかしながら、特許文献1に記載された方法では、代表ノードが応答確認メッセージを正常に送信できないおそれがあるという問題がある。上記のとおり、故障したECUにはメッセージの送信の調停が働かず、送信すべきメッセージがあれば送信してしまうので、代表ノードは故障したECUがメッセージを送信しないタイミングで応答確認メッセージを送信する必要がある。しかし、代表ノードにとって故障したECUがメッセージを送信しないタイミングは分からない。
また、CANプロトコルの規定で故障したECUは送信禁止になる時間がある。断線等したECUは、例えば、送信メッセージに対する応答を受信できないとエラーフラグを送出するが、この時エラーカウンタをインクリメントする。CANプロトコルでは、エラーカウンタが閾値を超えると、エラーパッシブ状態、さらにバスオフ状態になり、バスへの参加に制約が課される。
このため、故障ECUが存在すると、代表ノードは応答確認メッセージに対するフレームを受信できない理由が、断線によるものか、CANプロトコルの規定によるものか判別できない。
本発明は、上記課題に鑑み、車載ネットワークの断線や接触不良による通信障害が生じた場合、通信障害が生じた箇所を特定可能な電子制御ユニット、車載システム及びノード監視方法を提供することを目的とする。
上記課題に鑑み、本発明は、複数のノードの故障を監視する電子制御ユニットであって、複数のノードが1回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、検出されない順位情報と共に記録する通信途絶検出手段を有し、前記通信途絶検出手段は、所定期間毎に、前記略一定時間内に通信が検出されないノードと順位情報の記録を行う、ことを特徴とする。
車載ネットワークの断線や接触不良による通信障害が生じた場合、通信障害が生じた箇所を特定可能な電子制御ユニット、車載システム及びノード監視方法を提供することができる。
CANのネットワーク構造の一例を示す図である。 CANバスに流れる信号を模式的に示す図の一例である。 故障検出方法の概略を説明する図の一例である。 車両ネットワークの一例を示す図である。 ECUの機能ブロック図の一例である。 故障状態監視ECUであるECU-AによるECU-Bの監視方法を示す図の一例である。 監視時間を複数のECU間で共通にする理由を説明する図の一例である。 車載システムのネットワーク図の一例である。 通信妨害を説明する図の一例である。 通信途絶検出部がメッセージ途絶を検出する手順を示すフローチャート図の一例である。 メッセージ途絶情報の一例を示す図である。 メッセージ途絶情報の一例を示す図である。
以下、本発明を実施するための最良の形態に基づき、図面を参照しながら説明する。
図3は、本実施形態の故障検出方法の概略を説明する図の一例である。ECU-Aが他のECUの故障を監視するECUであるとする。ECU-Aは、ECU-B〜Eの全てからCAのフレーム(以下、メッセージという)を受信することができることを利用して、通信が途絶したECU-B〜Eを記録する。なお、以下では通信が途絶することを、「メッセージ途絶」又は「メッセージの途絶」という場合がある。
ECU-Aは、例えばある時間内に通信しないECUがある場合、そのECUとのメッセージが途絶したと判定する。図3では最初の一定時間内にECU-Eのメッセージが途絶している。また、次の一定時間内ではECU-Bからのメッセージが途絶している。この一定時間を、以下、「監視時間」という。
ECU-Aは図3(c)に示すように、メッセージが途絶したECUを、途絶した順に記録する。記録順がメッセージ途絶の順番となる。したがって、故障したECUが存在すれば、そのECUは早い順番に記録されると考えられる。
また、ECU-Aは、例えばIG(イグニッション)=ON毎に同様の記録を開始する。多くのケースで、ECU-B〜Eはメッセージ途絶が検出されないと考えられるが、複数回、記録することで、一次的に生じた接触不良を記録することができる。なお、IG=ONは内燃機関のみを駆動源とする車両だけを対象とする意味ではなく、ハイブリッド車や電気自動車ではシステムのスタートボタンが押下されることに相当する。
車両メーカなどがECU-Aの記録を解析する際、順位を点数化して統計的に処理することで、故障している可能性の高いECUを特定することができる。また、一度のメッセージの途絶だけでなく、複数回の順位を記録しその結果を統計処理することで、接触不良から復帰したようなECUを点数から推定することも可能になる。
なお、以下では、ECUとCANバスの間が脱線した状態、ECUとCANバスのコネクタに接触不良が生じた状態を区別せずに、単に故障という。
〔構成〕
メッセージ途絶情報は車両メーカや販売店のサービスマンが参照すべきものなので外部に提供する手段が必要になる。この手段には大きく2つの方法がある。
図4は、車載ネットワーク400の一例を示す図である。車載ネットワーク400では、車両100、サーバ200及びディーラ(実際にはディーラが運用するサーバ)300がネットワークを介して接続されている。車両100は、DCM(Data Communication Module)等の無線通信装置を搭載しており、音声通話及びデータ通信が可能になっている。DCMは、エアバッグの作動や車両100への盗難行為を検出すると、不図示のセンターに連絡するようになっている。本実施形態では、DCMを利用してメッセージ途絶情報をサーバ200に送信することができる。
サーバ200は、車両100のDCMの電話番号に基づき車両100やその販売店を特定し、販売店にメッセージ途絶情報を送信しておく。販売店のサービスマンは、車両100が持ち込まれた場合、メッセージ途絶情報を参照して、故障箇所や故障したECUを特定することができる。
また、2つめの方法としては外部ツールを接続する方法がある。次述するように、車載システムに搭載されているDLC3(Data Link Connector3)に外部ツールを接続することで、外部ツールがECUと通信し、メッセージ途絶情報を読み出すことができるようになっている。
図5は、車載システム50とECUの機能ブロック図の一例を示す。上記のように、メッセージ途絶を検出するECUはECU-Aとする。その他のECUは、各ECU独自の制御のため異なる構造やソフトウェアを搭載しているが、ECU-Aとの関係における構造は共通なので、ECU-Eのみを示した。
ECUは、CAN通信用のコントローラ、不図示のCPU、RAM、NVRAM、ROM、I/O等を備えたコンピュータである。ECU-AはCPUがソフトウェアを実行して実現された通信途絶検出部11を有し、例えばNVRAMに記憶されるメッセージ途絶情報12を有する。
通信途絶検出部11は、監視時間毎にECU-B〜Eからメッセージを受信するか否かを監視し、メッセージ途絶情報12を記録する。監視時間は、全てのECU-B〜Eからメッセージが送信される充分な時間である。メッセージ途絶情報12には、ECU-Aが監視時間内にメッセージを受信することができないECU-B〜Eが記録されている。メッセージを受信できないECUは、その順番が記録される。なお、通信途絶検出部11は、メッセージを受信すべき全てのECUのリストを予め記憶している。
ECU-EはCPUがソフトウェアを実行して実現された通信応答部21及び制御部22(以下、制御部Eという)を有する。通信応答部21は、通信途絶検出部11から応答要求に対しメッセージを返送する。したがって、通信応答部21があることで、故障していないECUは必ずメッセージを返すので、ECU-Aはメッセージ途絶を正確に記録できる。
制御部Eは、ECU-Eに接続されたセンサー25から信号を取得し、必要な演算によりアクチュエータ24の制御量を決定したり、スイッチ26のオン・オフを制御する。なお、制御部Eは、センサー25の信号、演算結果、自身の状態を他のECUに提供する処理も行う。これらの情報はECU-Aが受診することができるので、あえて通信応答部21を設けなくても、ECU-Aの通信途絶検出部11はメッセージ途絶を検出することができる。したがって、通信応答部21は必ずしも必須ではない。
なお、通信コントローラ13,23は、CANの通信プロトコルに従って、通信途絶検出部11(通信応答部21又は制御部E)が生成するデータをシリアルの送信信号に変換して不図示のトランシーバに出力する。トランシーバは通信コントローラ13,23から取得した論理レベルの送信信号を対応する差動電圧に変換してCANバスに流す。データの受信時、トランシーバは差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号を、通信コントローラ13,23に出力する。通信コントローラ13,23の受信用の端子はコンパレータを有しており、所定の閾値電圧とトランシーバからの受信信号とを比較してデジタルデータを取得する。
DLC3(31)は、車載システム50に外部ツール(テスター)32を接続するためのインタフェースである。例えば、運転席の右下の開閉部に配置される。サービスマンが外部ツール32をDLC3に接続し操作することで、ダイアグコードやその時のECUデータ(フリーズフレームデータ)、車載システム上を流れているデータのモニタ、アクティブテスト、学習値のクリア等を行うことができる。メッセージ途絶情報12はECUデータの1つとして取得することができる。
なお、本実施形態では通信コントローラ13,23がCANプロトコルに基づき通信するとして説明する。これは、CANには故障したノード(各ECUのこと)を特定しにくいという性質があるためである。しかしながら、特定しにくいのは主にCSMA/CAアクセス手順を使用するためなので、CSMA/CAのような特定のプロトコルに基づく車載システムであれば同様に適用できる。
〔故障状態監視ECUの必要性〕
故障を検出するためには、ECU-Aのように車両内に1つ以上の故障状態監視ECUが必要となる。
まず、ECUとCANバスの間の電線が断線した場合、人為的な修理なしに断線が元の状態に戻ることはない。一方、ECUとCANバスの間の接触不良の場合、人為的な修理がなくても車両100が走行しているうちに接触不良が解消して正常状態に戻る場合がある。このため、運転者がメータパネルのランプなどにより異常を認識しディーラ300に持ち込んだ場合、入庫時には接触不良が解消している場合がある。
すると、サービスマンは車両100を検査しても異常の原因を特定することができず、もう一度、接触不良の状態を再現させる等の特殊な修理が必要になり、検査に時間がかかってしまう。
したがって、CAN通信を車両100に採用する場合の課題として、接触不良の箇所を接触不良の発生中に特定する必要があることが挙げられる。また、この特定は運転者やサービスマンのいずれが行ってもよいが、運転者が特定した場合は、サービスマンに故障箇所(接触不良箇所)を正確に伝達する必要があることが挙げられる。
このような課題に対応するため、故障状態監視ECUが必要になる。故障状態監視ECU(ECU-A)は、接触不良時にメッセージ途絶情報12を記録できるので、接触不良が生じたこととそのECUを確実に記録することができる。
図6は、故障状態監視ECUであるECU-AによるECU-Bの監視方法を示す。図6(a)はCAN構成例の一例を示す。図示するようにCANバスにはECU-A〜ECU-Eの5つのECUが接続されている。
図6(b)は、ECU-Aが正常状態のECU-Bを監視する際に受信するメッセージの一例を示す。ECU-Bは監視時間よりも長い時間を空けずにメッセージを送信している。図では3つの監視時間があるが、ECU-Aは3つの監視時間の全てにおいてECU-Bからメッセージを受信している。したがって、ECU-Aは3つの監視時間の全てにおいて「ECU-Bは正常である」と判定することができる。
図6(c)はECU-Aが異常のあるECU-Bを監視する際に受信するメッセージの一例を示す。ECU-Aは3つの監視時間のうち、2つでは監視時間内にECU-Bからメッセージを受信しているが、1つの監視時間ではメッセージを受信していない。このため、ECU-Aは2つの監視時間では「ECU-Bは正常である」と判定するが、接触不良が生じた可能性のある1つの監視時間では「ECU-Bは故障」と判定することができる。ECU-Aはメッセージ途絶情報12を記録するので、時間が経過すると解消する可能性のある接触不良が生じたことを記録することができる。
なお、故障状態監視ECUを設けずに例えば各ECUが自己の異常を検出するだけでは、図1、2で説明したような問題が生じる。
ECU-Aは、故障を監視する専用のECUというわけではなく、ECU-Aに特有の電子制御を実行するECUである。こうすることでコスト増を抑制できる。ECU-AはどのようなECU(例えば、ボディECU、エンジンECU、ナビECU等)でもよく、特有の電子制御を阻害しないリソースを有していることが条件となる。
〔ECU-Aが受信するメッセージの個数、監視時間〕
通信途絶検出部11は、監視時間の開始時刻を基準に監視時間を計測し、終了時刻までにメッセージを受信したか否かを判定して、メッセージ途絶を検出する。上記のように、通信途絶検出部11は、応答要求に対する他のECUの応答をメッセージとして受信してもよいし、他のECUの各制御部22が制御の必要上、CANバスに流す情報をメッセージとして受信してもよい。
通信途絶検出部11が、監視時間内に1つもメッセージを受信できない場合にそのECUが故障したと判定するか、所定数個以上メッセージを受信できない場合にそのECUが故障したと判定するか、は設計事項である。例えば、ある車両メーカは厳格に故障を監視したいと考え、監視時間内に1つもメッセージを受信できない場合にそのECUが故障したと判定することができる。また、別のメーカは、故障の確度の高い情報だけ記録したいと考え、監視時間内に所定数個以上のメッセージを受信できない場合にそのECUが故障したと判定することができる。
また、このような故障に対するポリシー以外にECUの重要度を考慮することができる。例えば、ECU-Eが非常に重要なECU(例えば、エンジンECU、ブレーキECU)の場合、故障が生じると運転者に多大な影響が及ぼされる。したがって、厳格に故障を検出すると故障でないのに運転者が運転をできなくなるなどのおそれがあり、あまりに厳格でなくなると重大な故障に発展するなどのおそれがある。
また、通信途絶検出部11を備えた故障状態監視ECUは車載システム50に複数個存在してもよいが、監視用のECUは少ない方が低コストであるので、故障状態監視ECUと被監視対象ECUの数は、1対多であることが多い。
監視時間について説明する。ECU-Aが複数のECU-B〜Eの故障を監視する場合、ECU-B〜Eの監視時間は共通である。例えば、ECU-Bの監視時間が10秒の場合、ECU-Cの監視時間は11秒、ECU-Dの監視時間は10.5秒、ECU-Eの監視時間は9.5秒、のようにほぼ一定の時間とする。こうすることで故障したECUの誤判定を防止しやすくなる。
図7は、監視時間を複数のECU間で共通にする理由(誤判定を防止しやすい)を説明する図の一例である。図7では一例として、各ECUの監視時間が、ECU-B:1秒、ECU-C:2秒、ECU-D:3秒、ECU-E:4秒、であると仮定する。
このため、ECU-Bの監視時間を示す図7(a)では、ECU-Aが1秒間にECU-Bからメッセージを受信したか否かが故障判定の基準になり、ECU-Cの監視時間を示す図7(b)では、ECU-Aが2秒間にECU-Cからメッセージを受信したか否かが故障判定の基準になり、ECU-Dの監視時間を示す図7(c)では、ECU-Aが3秒間にECU-Cからメッセージを受信したか否かが故障判定の基準になり、ECU-Eの監視時間を示す図7(d)では、ECU-Aが4秒間にECU-Dからメッセージを受信したか否かが故障判定の基準になる。
ここで、点線で図示する時間帯(2.5秒間)にECU-Dの故障が発生したとする。ECU-Dは故障するとドミナントを送信するので、他のECUのメッセージの送信を妨害する。このため、2.5秒の間、全てのECUはメッセージを送信することができない。
しかし、ECU-BとECU-Cの監視時間は2秒以下なので、ECU-AはECU-BとECU-Cの故障を検出してしまう。一方、ECU-DとECU-Eの監視時間は3秒以上なので、メッセージの送信タイミングにもよるが、ECU-AはECU-DとECU-Eは正常であると判定してしまう。しかしながら、ECU-Dが故障したのであるから、ECU-BとECU-Cが故障であると判定すること、及び、ECU-Dが正常であると判定すること、は誤判定である。すなわち、ECU-Dが故障したのに、ECU-BとECU-Cが故障したと判定されてしまう。
これに対し、例えば、監視時間を全ECUに共通の2秒とした場合、ECU-Aは全てのECUの故障を検出することができる(実際に故障しているかどうかは統計的に突き止めるため1回の監視結果がこのような結果でも問題はない。)。しかし、正常なECUでも監視時間内にメッセージを出すか否かは不確定では、正常でも故障していると判定されるおそれがある。すなわち、監視時間は、全てのECUが少なくとも1回以上メッセージを送信する充分な時間であることが望ましい。
以上から、誤判定の防止には、監視時間を4つのECUに共通にし、かつ、監視時間は各ECUのメッセージが一度は受信されるようにある程度長くすることが好ましいことが分かる。このような時間は開発者が実験的に特定することができる。本実施形態では10秒とするが、3秒、5秒、又は、20秒などでもよい。
〔メッセージ途絶情報〕
図8(a)は、車載システム50のネットワーク図の一例を示す。これまでと同様、ECU-Aが故障状態監視ECUであり、ECU-EとCANバスの間の故障が生じたものとする。ECU-Eに故障が生じると、ECU-Eのメッセージの送信が他のECUのメッセージの送信も妨害する。
本実施形態では、IG(イグニション)・ONからOFFの間を1回の監視とする。通信途絶検出部11は、1回の監視中に、メッセージ途絶と判定したECU名とその順番を記憶する。また、次に、IG・OFFからONになると、通信途絶検出部11は監視を開始し、IG・OFFで監視を終了する。このように、IG・ON〜OFFが1回の監視となる。
通信途絶検出部11は、監視の結果である、メッセージ途絶と判定したECU名とその順番を、毎回、上書きすることなく記憶する(記憶容量が許す範囲で)。なお、メッセージ途絶が検出されない場合、すなわち、通信途絶検出部11が全てのECUが正常であると判定した場合、結果を記憶しなくてもよいし、「正常」と記憶することもできる。本実施形態では記憶しないものとする。
図8(b)はメッセージ途絶情報12の一例を示す図である。監視の回毎に、メッセージ途絶が検出されたECUが、メッセージ途絶が検出された順番に記憶されている。例えば、1回目のメッセージ途絶の検出順は、ECU-E、ECU-B、ECU-C、ECU-Dの順番である。この順番によれば、1回目のIG・ON〜OFFの間、通信途絶検出部11が例えば10秒間の監視時間で繰り返しECU-B〜Eを監視した際に、監視時間iではECU-Eのメッセージ途絶が検出され、監視時間i+aではECU-Bのメッセージ途絶が検出され、監視時間i+bではECU-Cのメッセージ途絶が検出され、監視時間i+cではECU-Dのメッセージ途絶が検出されたことになる。なお、小文字のi、a〜cは監視のサイクルを表し、a<b<cである。
また、3回目のメッセージ途絶の検出順は、ECU-E、ECU-B、なし、なしの順番である。この順番によれば、記録されていないECU-C,ECU-Dはメッセージ途絶が検出されなかったことを意味する。
ここで、故障が生じたECU(接触不良が復帰した後は除く)は一切の通信ができないので、監視の回に関係なく1番目に記録されるとことが多いと考えられる。また、その他のECUは、故障が生じたECUによりメッセージが破壊された場合にだけ、メッセージ途絶が検出されるが、多くの場合は2番目以降に記録されると考えられる(図8(b)の4回目にECU-Bが一番になっているのは、1つの監視時間内でECU-Eがメッセージ送信後に故障して、同じ監視時間内にECU-Bのメッセージが破壊されたような特殊な状況で生じる)。
したがって、1つのECUの故障が他のECUの通信を阻害するCAN通信においても、メッセージ途絶情報12を統計的に処理することで、故障したECU-Eを特定できることになる。統計処理するには、図8(b)のようなメッセージ途絶情報12を数値化すればよい。よって、サービスマン等はメッセージ途絶が早く起こるECUを特定できる。
本実施形態では数値化のため、一例として以下の規則を採用する。なお、数値化は、車内、サーバ200、又は、ディーラ300のどこでも行うことができるが、ここでは通信途絶検出部11が数値化するとして説明する。
(1)1番目にメッセージ途絶が検出されたECUに1点、2番目に2点、3番目に3点、4番目に4点、と順位と同じ点をECUに与える。
(2)メッセージ途絶が検出されなかったECUは、最も遅い順位(図8(b)の例では4位)と同じ点数をECUに与える。なお、メッセージ途絶が検出されなかったECUには、もっと大きな点、例えば、最も遅い順位と同じ点数+α(例えば、1〜4点)をECUに与えてもよい。
この規則に従うと、1回目のメッセージ途絶情報12と2回目のメッセージ途絶情報12では、各ECUの点数は、以下のようになる。
1回目:ECU-B=2点、ECU-C=3点、ECU-D=4点、ECU-E=1点、
2回目:ECU-B=4点、ECU-C=2点、ECU-D=3点、ECU-E=1点、
図8(b)ではメッセージ途絶情報12の右側に、過去の累積点が示されている。すなわち、2回目までの累積点は、以下のようになっている。
ECU-B=6点、ECU-C=5点、ECU-D=7点、ECU-E=2点、
したがって、各ECUの累積点を比較して、累積点が低いECUほど故障している可能性が高いことが分かる。ディーラ300のサービスマンは、累積点の最も小さいECUからチェックして、ECUとCANバスの間の電線の断線や接触不良を検査することができる。また、累積点の最も小さいECUから故障が見つけられない場合、サービスマンは次に累積点の小さいECUとCANバスの間の電線の断線や接触不良を検査すればよいと判断できる。
このように本実施形態では、故障しているECUは他のECUよりも早くメッセージ途絶が検出されると考えられ、その傾向はECUが故障している限り継続することを利用している。1回だけの判定では、実際に故障したのか、故障したECU-Eにメッセージが破壊されたのか不明であるが、複数回の監視結果を点数化して累積することで、故障の検出精度を向上させることができる。逆に接触不良などが生じやすいECUの点数は、メッセージ途絶が検出されるので、たまたまメッセージが破壊されたECUと比べて、統計処理により有意な差が見られることになる。
例えば、5回目までの累積点は、次のようになっている。
ECU-B=11点、ECU-C=15点、ECU-D=19点、ECU-E=6点
このように、ECU-Eと他のECUには累積点には大きな差が見られる。また、すべてのECUが正常な場合に正常であるというメッセージ途絶情報を記録した場合も、同様に判定できる。仮に、5回の監視の前、及び、後に100回の監視があり、その全てで全ECUのメッセージ途絶が検出されない場合、4点×100回=400を加えた値が各ECUの累積点となる。
ECU-B=411点、ECU-C=415点、ECU-D=419点、ECU-E=406点
接触不良が生じ、後に戻ったような場合、累積点には大きな差が見られない。しかし、これまで説明したように最も累積点が小さいECUは故障したECUと考えることが合理的であるので、例えば5点の差(411点と406点)は有意な差としてよい。
また、メッセージの途絶が検出された場合、監視のサイクルを短くしてもよい。すなわち、メッセージの途絶が検出された場合、IG=ONの間に、例えば10分〜1時間毎に次の回の監視を行うことで、接触不良が生じた場合に、監視の回数を増やすことができる。これにより、点数の有意差をさらに拡大できる。
なお、図8(b)ではメッセージ途絶が早く検出されるECUほど、小さい点数を与えたが、メッセージ途絶が早く検出されるECUほど大きな点数を与えてもよい。この場合、ディーラ300のサービスマンは、累積点の最も大きいECUからチェックすればよい。
〔故障したECUが自発的に送信を停止する場合について〕
上述したように、CANプロトコルの規定で故障ECU(断線以外のなんらかの異常が生じたECU)は送信禁止になる時間があるが、この場合も、本実施形態の故障検出方法が有効であることを説明する。
まず、原理的に次のことが言える。
(1)故障しているECUからのメッセージは必ず送信不可となる。
(2)故障していないECUは、故障しているECUからの通信妨害により送信不能となる場合がある。
しかし、CANのプロトコル上、故障しているECUは短時間だが送信停止となる期間が定義されている。したがって、この期間は通信の妨害が発生せず、正常なECUがメッセージを送信することが可能になる。このため、正常なECUはメッセージ途絶が検出されるタイミングが、異常の生じたECUよりも遅くなると期待できる。この場合、正常なECUの点数は大きくなる。また、場合によっては、正常なECUはメッセージ途絶と判定されないことも期待できる。
図9は、通信妨害を説明する図の一例である。各ECUはそれぞれの制御の必要に応じてメッセージをCANバスに出力する。図9では、正常に送信されないメッセージを点線の「送信なし」で示した。
図示する「ECU-E送信禁止期間」が、CANのプロトコルが規定する、故障したECUが送信禁止になる時間帯である。この間、ECU-Eは送信しないので、ECU-B、C、Dのメッセージは妨害されない。
ECU-Aの通信途絶検出部11は、監視時間にECU-B、C、Dのメッセージを受信することができるので、この監視時間においてはECU-B、C、Dのメッセージ途絶を検出しない。よって、ECU-EよりもECU-B、C、Dのメッセージ途絶が検出されるタイミングが遅くなる。
〔オプション扱いのECUについて〕
車両100には種々のオプションが用意されており、オプションが装着されて出荷されることもそうでないこともある。また、出荷後に脱着されることもある。この場合も本実施形態の手法は有効である。
・装着されずに出荷されたオプション用のECU
このECUも通信途絶検出部11のECUの一覧のリストに載っている場合、監視のほぼ毎回、1番目にメッセージ途絶が検出されると考えられる。したがって、累積点は最も低くなるが、サービスマンが車両100を見ればそのECUは装着されていないので、故障の判定対象としなくてよいことは容易に判断できる。出荷後に取り外されたECUについても同様であるが、次述のようにメッセージ途絶情報12を初期化することも有効である。
・装着されたオプション用のECU
出荷時に装着されていたオプション用のECUについてはオプション品でないECUと同様に扱うことができる。出荷後に装着されたECUについては、装着までは累積点が低い点数であったが、装着後に点数が増大することになる。この累積点は接触不良のECUと似た傾向となるので、出荷後にオプションが装着された時点で(ECUが故障していないことを確認した上で)、累積点は初期化することが好ましい。例えば、通信途絶検出部11は外部ツール32からの信号を受け付けてメッセージ途絶情報12を初期化できる。
〔動作手順〕
図10は、通信途絶検出部11がメッセージ途絶を検出する手順を示すフローチャート図の一例である。図10の手順は例えばIG・ONによりスタートする。
まず、通信途絶検出部11は今回のメッセージ途絶情報12を初期化する(S10)。具体的には、例えば、今回のメッセージ途絶情報12のレコードを生成し、初期値(例えば、NULL)を設定する。また、通信途絶検出部11は、メッセージを受信すべき全てのECUのリストを読み出しておく。レコードに残った初期値は、その順位でメッセージ途絶が検出されたECUはないことを意味する。全てのECUが正常であった場合は、レコードを削除するか、全ての順位を初期値のままとすればよい(図8の「なし」に相当する)。
次に、通信途絶検出部11は監視時間の計測を開始する(S20)。上記のように、監視時間は、例えば10秒程度である。
通信途絶検出部11は、受信したメッセージの送信元のECUをRAMなどに一時的に記録する(S30)。送信元のECUはメッセージのIDから特定できる。なお、通信途絶検出部11は、1つの監視時間に同じECUから複数のメッセージを受信した場合、同じECUは1つしか記録しない。
通信途絶検出部11は、監視時間が経過したか否かを判定し(S40)、監視時間が経過するまでECUの記録を継続する。
監視時間が経過すると(S40のYes)、通信途絶検出部11は、メッセージ途絶が検出されたECUがあるか否かを判定する(S50)。すなわち、通信途絶検出部11はメッセージを受信すべき全てのECUのリストと、RAMに記憶されたECUのリストを突合し、リストにあってRAMにないECUを特定する。そのECUはメッセージ途絶が検出されたECUであるので、通信途絶検出部11は該ECUのみを残してその他をRAMから消去する。
メッセージ途絶が検出されたECUがない場合(S50のNo)、通信途絶検出部11はそれを記録しないので処理はステップS70に進む。
メッセージ途絶が検出されたECUがある場合(S50のYes)、通信途絶検出部11はそのECUをメッセージ途絶情報12の今回のレコードに記録する(S60)。このため、通信途絶検出部11は、メッセージ途絶が検出されたECUを1つずつRAMから読み出し、メッセージ途絶情報12の今回のレコードにすでに登録されているECUをRAMから消去する。これによりすでに登録されたECUを排除できる。
RAMに残っているECUは、まだメッセージ途絶情報12の今回のレコードに登録されてないECUになるので、通信途絶検出部11はすでにECUが登録されている順位の次の順位に(例えば、2番目までが埋まっているなら3番目に登録する)、RAMに残っているECUを登録する。複数のECUがRAMに残っている場合、1つの監視時間内では順位付けしないので、全てのECUを同じ順位に登録する。1つの監視時間内で順位づけして、例えば、アルファベット順(識別情報順)に、メッセージ途絶のECUを順位付けしてもよい。
この後、メッセージ途絶情報12の今回のレコードに、全てのECU(リストのECU)が登録されたか否かを判定し、登録されている場合は、点数化のステップS80に進んでもよい。
次に、通信途絶検出部11は、IG=OFFか否かを判定し(S70)、IG=OFFになるまでは、ステップS20からの処理を繰り返す。なお、連続して監視する必要はなく、間隔(数秒、数分又は数十分など)空けて、繰り返してもよい。
IG=OFFになった場合(S70のYes)、通信途絶検出部11はECUの順位を点数化する(S80)。
そして、ECU毎に、それまでの累積点に今回の点数を加えて、新たな累積点を算出する(S90)。以上により、メッセージ途絶が早いECUほど低い累積点が算出される。
〔点数化の変形例1〕
これまでの点数化では、メッセージ途絶したECUとそうでないECUの点数に大きな差異がなく、故障のあるECUの特定が困難となることも予測される。そこで、正常であると判定されたECUの累積点をゼロにすることが考えらえる。
図11(a)はメッセージ途絶情報12の一例を示す。図11(a)のメッセージ途絶情報12は、5回目までの記録は図8(b)と同じであるが、6回目にECU-Eを除いてメッセージ途絶が検出されていない。通信途絶検出部11は、メッセージ途絶が検出されない(正常であると判定された)ECUの累積点をゼロにするので、ECU-B〜Dの累積点をゼロにしている。このような計算方法では、例えばサービスマンは累積点がゼロかゼロでないかにより故障の有無を判定できるので、故障したECU(この場合ECU-E)を特定しやすくなる。
CAN通信では、通信途絶検出部11が故障の生じたECU以外のECUについてもメッセージ途絶を検出するので、このようにメッセージ途絶が検出されないECUの累積点をゼロにすることで、故障したECUとそれ以外のECUを容易に差別化できる。ただし、接触不良のように故障から正常に復帰してしまうECUの特定には不向きである。
また、メッセージ途絶が検出されたECUの点数を低くするのでなく、ゼロにすることもできる。この場合、メッセージ途絶が検出されないECUには一律又は順番に応じて点数が加点される。
メッセージ途絶が検出されないECU=一律に4点
メッセージ途絶が検出されたECU = 0点
図11(b)は、メッセージ途絶情報12の一例を示す。1回目から5回目まで、メッセージ途絶が検出されなかったECU-C、ECU-Dのみに4点を記録されている。6回目と7回目では、ECU-E以外のECUでメッセージ途絶が検出されないので4点ずつ加算が開始されている。9回目以降は、ECU-Eの接触不良が解消したため、ECU-Eの累積点も4点ずつの加算が開始される。しかしながら、10回以降、ECU-Eと他のECUの点数は、最小でも8点(ECU-EとECU-Bの差)を保つので、サービスマンは故障した可能性の高いECU-Eを特定することができる。
また、メッセージ途絶が検出されたECUの点数を、検出されないECUよりも大きくすることもできる。図12は、メッセージ途絶情報12の一例を示す。図12では、メッセージ途絶が検出された順番に、1番=4点、2番=3点、3番=2点、4番=1点、検出されない=0点、として各ECUに点数が与えられている。5回目の累積点を見ると、故障のあるECU-Eの点数が最も高くなっているので、サービスマンは故障したECU-Eを特定することができる。また、この後、ECU-Eの接触不良が解消しても、累積点に有意な点差が残るので、サービスマンは接触不良が一時的に生じたECU-Eを特定することができる。
以上説明したように、本実施形態の車載システム50は、メッセージ途絶の順位を複数回に渡って点数化して記録するので、接触不良から復帰したようなECUの痕跡を点数から推定可能とすることができる。
11 通信途絶検出部
12 メッセージ途絶情報
13、23 通信コントローラ
21 通信応答部
22 制御部
31 DLC3
32 外部ツール
50 車載システム
100 車両
300 ディーラ
400 車両ネットワーク

Claims (10)

  1. 複数のノードの故障を監視する電子制御ユニットであって、
    複数のノードが1回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、通信が検出されない順位情報と共に記録する通信途絶検出手段を有し、
    前記通信途絶検出手段は、所定期間毎に、前記略一定時間内に通信が検出されないノードと前記順位情報の記録を行う、
    ことを特徴とする電子制御ユニット。
  2. 前記通信途絶検出手段は、前記順位情報を点数化してノード毎に記録する、
    請求項1記載の電子制御ユニット。
  3. 前記通信途絶検出手段は、前記順位情報の順番が早いほど小さな点又は大きな点をノードに与えて、前記順番を点数化する、
    請求項2記載の電子制御ユニット。
  4. 前記通信途絶検出手段は、前記所定期間毎に得られた、ノード毎の複数個の点数の統計値を算出する、
    請求項2又は3記載の電子制御ユニット。
  5. 前記通信途絶検出手段は、前記順位情報の順番が早いほど小さな点又は大きな点をノードに与え、ノード毎の複数個の点数を合計する、
    ことを特徴とする請求項4記載の電子制御ユニット。
  6. 前記通信途絶検出手段は、前記所定期間に通信が検出されないノードにゼロ点を与え、前記所定期間に通信が検出されたノードに1以上の点数を与え、ノード毎の複数個の点数を合計する、
    ことを特徴とする請求項4記載の電子制御ユニット。
  7. 前記通信途絶検出手段は、ノードが接続された車載システムに外部ツールが接続され、所定の制御信号を受信した場合、各ノードの過去の点数を初期化する、
    ことを特徴とする請求項2記載の電子制御ユニット。
  8. 前記所定期間は、車両の駆動システムのスタートボタンのオンからオフの間である、
    ことを特徴とする請求項1〜8いずれか1項記載の電子制御ユニット。
  9. 複数のノードの故障を監視する電子制御ユニットと該ノードがネットワークを介して接続された車載システムであって、
    各ノードは、前記ネットワークにメッセージを送信する通信手段を有し、
    前記電子制御ユニットは、複数のノードが1回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、通信が検出されない順位情報と共に記録する通信途絶検出手段を有し、
    前記通信途絶検出手段は、所定期間毎に、前記略一定時間内に通信が検出されないノードと前記順位情報の記録を行う、ことを特徴とする車載システム。
  10. 複数のノードと接続される電子制御ユニットがノードの故障を監視するノード監視方法であって、
    通信途絶検出手段が、複数のノードが1回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、検出されない順位情報と共に記録するステップと、
    前記通信途絶検出手段が、所定期間毎に、前記略一定時間内に通信が検出されないノードと前記順位情報の記録を行うステップと、
    有することを特徴とするノード監視方法。
JP2010232866A 2010-10-15 2010-10-15 電子制御ユニット、車載システム、ノード監視方法 Pending JP2012086601A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010232866A JP2012086601A (ja) 2010-10-15 2010-10-15 電子制御ユニット、車載システム、ノード監視方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010232866A JP2012086601A (ja) 2010-10-15 2010-10-15 電子制御ユニット、車載システム、ノード監視方法

Publications (1)

Publication Number Publication Date
JP2012086601A true JP2012086601A (ja) 2012-05-10

Family

ID=46258708

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010232866A Pending JP2012086601A (ja) 2010-10-15 2010-10-15 電子制御ユニット、車載システム、ノード監視方法

Country Status (1)

Country Link
JP (1) JP2012086601A (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103434459A (zh) * 2013-08-14 2013-12-11 黄正男 一种车载网络通信电控装置
JP2014090249A (ja) * 2012-10-29 2014-05-15 Denso Corp 中継装置
US20140309787A1 (en) * 2013-04-15 2014-10-16 Kabushiki Kaisha Yaskawa Denki Device control system and controller
JP2015107672A (ja) * 2013-12-03 2015-06-11 株式会社デンソー 車載ネットワークシステム
WO2021145116A1 (ja) * 2020-01-14 2021-07-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知方法、プログラム及び異常検知システム
CN114244747A (zh) * 2021-11-12 2022-03-25 潍柴动力股份有限公司 一种报文健康监控方法、装置及ecu

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014090249A (ja) * 2012-10-29 2014-05-15 Denso Corp 中継装置
US20140309787A1 (en) * 2013-04-15 2014-10-16 Kabushiki Kaisha Yaskawa Denki Device control system and controller
CN103434459A (zh) * 2013-08-14 2013-12-11 黄正男 一种车载网络通信电控装置
JP2015107672A (ja) * 2013-12-03 2015-06-11 株式会社デンソー 車載ネットワークシステム
WO2021145116A1 (ja) * 2020-01-14 2021-07-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知方法、プログラム及び異常検知システム
CN114244747A (zh) * 2021-11-12 2022-03-25 潍柴动力股份有限公司 一种报文健康监控方法、装置及ecu
CN114244747B (zh) * 2021-11-12 2023-11-17 潍柴动力股份有限公司 一种报文健康监控方法、装置及ecu

Similar Documents

Publication Publication Date Title
US10902109B2 (en) Misuse detection method, misuse detection electronic control unit, and misuse detection system
US9110951B2 (en) Method and apparatus for isolating a fault in a controller area network
US20190312892A1 (en) Onboard cybersecurity diagnostic system for vehicle, electronic control unit, and operating method thereof
CN101483544B (zh) 故障定位装置、通信装置及故障定位方法
JP2012086601A (ja) 電子制御ユニット、車載システム、ノード監視方法
US9417982B2 (en) Method and apparatus for isolating a fault in a controller area network
CN105700510B (zh) Can通信系统的错误分散检测方法及can通信系统
US20110035180A1 (en) Diagnostic apparatus and system adapted to diagnose occurrence of communication error
US20060271256A1 (en) Device and method for on-board diagnosis based on a model
JP2005219717A (ja) 車両・車載機器の異常診断装置
US20150312123A1 (en) Method and apparatus for isolating a fault in a controller area network
CN109005678B (zh) 非法通信检测方法、非法通信检测系统以及记录介质
JP2007326425A (ja) 通信制御ユニット,故障解析センタ,及び故障解析方法
US8024625B2 (en) Network system for diagnosing operational abnormality of nodes
CN111736030B (zh) 一种汽车的通用故障管理方法
JP2000324145A (ja) ネットワーク診断装置、ネットワーク診断方法及びネットワークシステム
US9499174B2 (en) Method and apparatus for isolating a fault-active controller in a controller area network
US11613215B2 (en) Apparatus and method for detecting a battery discharging cause for a vehicle
JP2016055673A (ja) 故障診断装置、および電子制御装置
WO2013159294A1 (en) A fast detecting and locating fault method for intercom system and a system thereof
JP7205245B2 (ja) 電子制御装置
JP2000505262A (ja) 回路網化されるシステムの使用可能性の検査及び保証方法
Dekate Prognostics and engine health management of vehicle using automotive sensor systems
WO2023218815A1 (ja) 監視装置、車両監視方法および車両監視プログラム
CN117929887A (zh) 故障检测方法、装置、存储介质和车辆