(57)【要約】【課題】  ノードの故障を、他ノードとの間で調停負けが生じたと継続して誤判定することなく確実に検出することが可能な通信ノード故障検出装置及び方法を提供することにある。【解決手段】  ＣＡＮ通信においては、データ送信時におけるＣＡＮバスの通信状態がそのデータフレームのものよりも優先度の高いものであるとき、調停負けが生じたとしてそのデータフレームのＣＡＮバスへの送信を中断する。そして、同一のデータフレームに対して調停負けが所定回数連続して生じたか否かを判別する。その結果、肯定判定がなされた場合に、そのデータフレームの調停領域における優先度を、ＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに変更する。そして、その優先度変更後のデータフレームのＣＡＮバスへの送信に対するＣＡＮバスの通信状態に基づいてノードの故障を検出する。【選択図】  図２
2006237832.tif 000002
【特許請求の範囲】
【請求項１】
優先度を示す調停領域が設けられたデータフレームをＣＡＮバスに送信するデータ送信手段と、前記データ送信手段により前記データフレームをＣＡＮバスに送信する過程で該ＣＡＮバスの通信状態を監視するモニタ手段と、前記モニタ手段による前記通信状態がＣＡＮバスに送信している前記データフレームのものよりも優先度の高いものである場合に、他ノードとの間で調停負けが生じたとして該データフレームのＣＡＮバスへの送信を中断する送信中断手段と、を備えるノードの故障を検出する装置であって、
前記調停負けが同一の前記データフレームに対して所定回数連続して生じたか否かを判別する調停負け回数判別手段と、
前記調停負け回数判別手段により前記調停負けが前記所定回数連続して生じたと判別される場合に、前記データフレームの前記調停領域における優先度を、ＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに変更する優先度変更手段と、
前記優先度変更手段による優先度変更後、前記モニタ手段による前記通信状態に基づいて、前記ノードの故障を検出する故障検出手段と、
を備えることを特徴とする通信ノード故障検出装置。
【請求項２】
前記データフレームは、１１ビットの前記調停領域を有することを特徴とする請求項１記載の通信ノード故障検出装置。
【請求項３】
前記データフレームは、２９ビットの前記調停領域を有すると共に、
前記優先度変更手段は、前記調停負け回数判別手段により前記調停負けが前記所定回数連続して生じたと判別された場合に、前記データフレームの前記調停領域を２９ビットのものから１１ビットのものに変更したうえで、該調停領域の優先度をＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに設定することを特徴とする請求項１記載の通信ノード故障検出装置。
【請求項４】
優先度を示す調停領域が設けられたデータフレームをＣＡＮバスに送信するデータ送信手段と、前記データ送信手段により前記データフレームをＣＡＮバスに送信する過程で該ＣＡＮバスの通信状態を監視するモニタ手段と、前記モニタ手段による前記通信状態がＣＡＮバスに送信している前記データフレームのものよりも優先度の高いものである場合に、他ノードとの間で調停負けが生じたとして該データフレームのＣＡＮバスへの送信を中断する送信中断手段と、を備えるノードの故障を検出する方法であって、
前記調停負けが同一の前記データフレームに対して所定回数連続して生じたか否かを判別する調停負け回数判別ステップと、
前記調停負け回数判別ステップにおいて前記調停負けが前記所定回数連続して生じたと判別される場合に、前記データフレームの前記調停領域における優先度を、ＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに変更する優先度変更ステップと、
前記優先度変更ステップにおける優先度変更後、前記モニタ手段による前記通信状態に基づいて、前記ノードの故障を検出する故障検出ステップと、
を備えることを特徴とする通信ノード故障検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ノード故障検出装置及び方法に係り、特に、優先度を示す調停領域が設けられたデータフレームをＣＡＮバスに送信すると共に、その送信過程でＣＡＮバスにその送信データフレームよりも優先度の高いものが流れる場合にそのデータフレームの送信を中断するノードの故障を検出するうえで好適な通信ノード故障検出装置及び方法に関する。
【背景技術】
【０００２】
従来から、同じバスラインに接続された複数のノード間でそのバスラインへのデータ送信が競合しないように調停が実施されるＣＡＮ通信が知られている（例えば、特許文献１や特許文献２参照）。ＣＡＮ通信において、バスラインは、ＣＡＮ−Ｈ及びＣＡＮ−Ｌの一対の通信ラインから構成されており、その状態がＣＡＮ−ＨとＣＡＮ−Ｌとの間に電位差が生じないレセッシブレベル（ビット“１”）とレセッシブレベルよりも優位なその間に電位差が生ずるドミナントレベル（ビット“０”）との何れか一に切り替わるようになっている。
【０００３】
また、ＣＡＮ通信に用いられるデータフレームは、データの先頭を示すスタートオブフレーム（ＳＯＦ；ビット“０”）の次に設けられた、送信の優先度を示す１１ビット又は２９ビットの調停領域（ＩＤフィールド）を有している。ＣＡＮ通信において、２つ以上のノードがバスラインへ同時にデータを送信するときは、それらのノード間での調停は、優先度の高いデータフレーム具体的にはＭＳＢからドミナントレベルのビットが多く継続するデータフレームを送信するノードが優先され（調停に勝ち）、優先度の低いデータフレーム具体的にはレセッシブレベルがより早く現れるデータフレームを送信するノードが調停負けするように実施される。
【０００４】
各ノードは、少なくとも自己のデータフレームの送信過程においてバスラインの通信状態を監視する。そして、その監視結果に基づいて自己の送信したデータフレームのビットが“１”であるにもかかわらずモニタ結果がビット“０”であるときは、自己のデータ送信に関し調停負けが生じたとして、その後のデータフレームの送信を一時中止（中断）し、所定時間経過後に再び同一のデータフレームの送信を繰り返す。
【特許文献１】特開２０００−１６５４１５号公報
【特許文献２】特開２００１−１１９４１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、ノードは、データフレーム送信中にＣＡＮ−ＨとＣＡＮ−Ｌとの間を電位差が生じたままに維持させる故障（バス支線の一部断線を含む）を起こすことがある。かかる故障が生じているノードがその故障を認識することなくバスラインに所望のデータフレームを送信する状況を考えると、そのデータフレームの調停領域におけるビット“１”が送信される際にもそのモニタ結果がビット“０”に維持されることとなり、送信フレームとモニタ結果とが一致しないものとなる。この場合、故障が生じているノード（特に、調停領域にＣＡＮ通信のルールに従ったスタッフビットが挿入されないほどに低優先のデータフレームを送信するノード）としては、自己の故障と認識せずに、単に他ノードとの調停に負けたと判定してしまい、即座にデータ送信を中断する。調停負け自体は故障ではないため、以後、その故障ノードは、故障に起因してモニタ結果が“０”に固定されて不一致が生ずるにもかかわらず同じデータフレームの再送信を繰り返すこととなる。その結果、バスライン上へ故障ノードから調停領域で途切れる不完全なデータフレームが乱発することとなり、故障が生じていない他の正常なノードからのデータフレームが破壊され続ける不都合が発生する。
【０００６】
本発明は、上述の点に鑑みてなされたものであり、自ノードの故障を、他ノードとの間で調停負けが生じたと継続して誤判定することなく確実に検出することが可能な通信ノード故障検出装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の目的は、優先度を示す調停領域が設けられたデータフレームをＣＡＮバスに送信するデータ送信手段と、前記データ送信手段により前記データフレームをＣＡＮバスに送信する過程で該ＣＡＮバスの通信状態を監視するモニタ手段と、前記モニタ手段による前記通信状態がＣＡＮバスに送信している前記データフレームのものよりも優先度の高いものである場合に、調停負けが生じたとして該データフレームのＣＡＮバスへの送信を中断する送信中断手段と、を備えるノードの故障を検出する装置であって、前記調停負けが同一の前記データフレームに対して所定回数連続して生じたか否かを判別する調停負け回数判別手段と、前記調停負け回数判別手段により前記調停負けが前記所定回数連続して生じたと判別される場合に、前記データフレームの前記調停領域における優先度を、ＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに変更する優先度変更手段と、前記優先度変更手段による優先度変更後、前記モニタ手段による前記通信状態に基づいて、前記ノードの故障を検出する故障検出手段と、を備える通信ノード故障検出装置により達成される。
【０００８】
また、上記の目的は、優先度を示す調停領域が設けられたデータフレームをＣＡＮバスに送信するデータ送信手段と、前記データ送信手段により前記データフレームをＣＡＮバスに送信する過程で該ＣＡＮバスの通信状態を監視するモニタ手段と、前記モニタ手段による前記通信状態がＣＡＮバスに送信している前記データフレームのものよりも優先度の高いものである場合に、調停負けが生じたとして該データフレームのＣＡＮバスへの送信を中断する送信中断手段と、を備えるノードの故障を検出する方法であって、前記調停負けが同一の前記データフレームに対して所定回数連続して生じたか否かを判別する調停負け回数判別ステップと、前記調停負け回数判別ステップにおいて前記調停負けが前記所定回数連続して生じたと判別される場合に、前記データフレームの前記調停領域における優先度を、ＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに変更する優先度変更ステップと、前記優先度変更ステップにおける優先度変更後、前記モニタ手段による前記通信状態に基づいて、前記ノードの故障を検出する故障検出ステップと、を備える通信ノード故障検出方法により達成される。
【０００９】
この態様の発明において、調停負けが同一のデータフレームに対して所定回数連続して生じたと判別されると、そのデータフレームの調停領域における優先度が、ＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに変更される。このように調停領域における優先度を所定の高優先のものに変更すれば、その変更後のデータフレームがスタッフビットが挿入された状態で送信されることとなるが、このスタッフビットは調停領域での優先度を示すものではないため、このスタッフビットが“１”であればモニタ結果もビット“１”である必要がある。すなわち、挿入されたスタッフビットに対するモニタ結果が一致すれば、ＣＡＮバスをドミナントレベルに固着させる故障はノードには生じていないと判断できる一方、そのモニタ結果が一致しなければ、その故障がノードに生じていると判断できる。従って、優先度変更後のＣＡＮバスの通信状態を監視すれば、ノードの故障を、他ノードとの間で調停負けが生じたと継続して誤判定することなく確実に検出することが可能となる。
【００１０】
この場合、上記した通信ノード故障検出装置において、前記データフレームは、１１ビットの前記調停領域を有することとしてもよい。
【００１１】
また、上記した通信ノード故障検出装置において、前記データフレームは、２９ビットの前記調停領域を有すると共に、前記優先度変更手段は、前記調停負け回数判別手段により前記調停負けが前記所定回数連続して生じたと判別された場合に、前記データフレームの前記調停領域を２９ビットのものから１１ビットのものに変更したうえで、該調停領域の優先度をＣＡＮ通信のルールに従ってスタッフビットが挿入される所定の高優先のものに設定することとしてもよい。
【００１２】
一般に、２９ビットの調停領域を有するデータフレームではそのＭＳＢから３ビットがビット“１”を有する“１１０”バイナリと固定されているため、２９ビットの調停領域のままでその優先度を高優先のものへ切り替えても、ノード故障の発生にもかかわらず他ノードとの間で調停負けが生じたとの誤判定が継続するおそれがある。これに対して、この態様の発明によれば、調停負けが同一のデータフレームに対して所定回数連続して生じたと判別された場合には、一旦、そのデータフレームの調停領域が２９ビットのものから１１ビットのものに変更されたうえで、その優先度がスタッフビットが挿入される所定の高優先のものに変更されるため、２９ビットの調停領域を有するデータフレームを送信するノードの故障でも、他ノードとの間で調停負けが生じたと継続して誤判定することなく確実に検出することが可能となる。
【発明の効果】
【００１３】
本発明によれば、ノードの故障を、他ノードとの間で調停負けが生じたと継続して誤判定することなく確実に検出することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の具体的な実施の形態について説明する。図１は、本発明の一実施例である通信ノード故障検出装置を搭載するノードを備えるネットワークシステムの要部構成図を示す。本実施例のネットワークシステムは、例えば車両に搭載されるＣＡＮ（Controller Area Network）通信ネットワークシステムである。
【００１５】
本実施例のシステムは、図１に示す如く、ノード１０を備えている。ノード１０は、車両の各種制御装置に設けられるコンピュータを主体に構成された電子制御ユニットであるＥＣＵやインテリジェントなセンサであって、複数設けられている。例えば、ステアリング舵角に応じた信号を出力する舵角センサ、車両の重心軸周りに生ずるヨーレートに応じた信号を出力するヨーレートセンサ、スロットル開度やアクセル開度，エンジン水温等に基づいてエンジン制御を行うエンジンＥＣＵ、車輪速やヨーレート，ステアリング舵角等に基づいて車両の旋回挙動を安定化させるＶＳＣ（Vehicle Stability Control）−ＥＣＵ、シフト操作位置等に基づいて車両のシフトポジションを制御するトランスミッションＥＣＵ、ブレーキ踏力やステアリング舵角等に基づいて車両の制動力を制御するブレーキＥＣＵ、ステアリング舵角等に基づいて操舵アシスト力を制御するパワーステアリングＥＣＵ、エアコン操作スイッチや車内温等に基づいて車内のエアコンディションを制御するオートエアコンＥＣＵ等である。
【００１６】
各ノード１０は、共通のＣＡＮバス１２を介して互いに接続されており、ＣＡＮバス１２によるＣＡＮ通信ネットワークを構成している。ＣＡＮバス１２は、ＣＡＮ−ＨとＣＡＮ−Ｌとのツイストペア線からなる共有バスであり、ＣＡＮ−ＨとＣＡＮ−Ｌとの間の電位差を切り替えてレベル変化する。具体的には、そのレベルがＣＡＮ−ＨとＣＡＮ−Ｌとの間に電位差が生じないレセッシブレベル（ビット“１”）とレセッシブレベルよりも優位なその間に電位差が生ずるドミナントレベル（ビット“０”）との何れか一に切り替わるようになっている。ＣＡＮバス１２は、各ノード１０から送出（送信）されるデータを後に詳述する所定の通信プロトコルに従って時分割多重で伝送（多重通信）することを可能としている。このため、各ノード１０は、他のノード１０との間でＣＡＮバス１２を介して各種のデータを送受信することが可能である。
【００１７】
各ノード１０は、中央演算処理装置であるＣＰＵ２０、及び、ＣＡＮバス１２に接続するバスインターフェース２２を備えている。ＣＰＵ２０には、ＲＡＭ２４、ＲＯＭ２６、及びコントローラ２８が内蔵されている。ＲＡＭ２４は、ＣＰＵ２０の演算中の情報や演算結果を格納する領域である。ＲＯＭ２６は、ＣＰＵ２０が使用するプログラムを格納すると共に、自ノード１０が受信すべき他ノード１０からのデータ固有の識別ＩＤを格納する領域である。コントローラ２８は、通信データを格納するレジスタを有し、設定した識別ＩＤとＣＡＮバス１２上の通信データ中の識別ＩＤとを照合して、その照合が一致する場合に、その受信データをレジスタに格納する。
【００１８】
ＣＰＵ２０は、ＣＡＮ通信の所定の通信プロトコルに準じて作成されＲＯＭ２６に格納されたプログラムに従ってコントローラ２８を制御して、ＣＡＮバス１２を介したデータフレームの送受信制御を行う。具体的には、自ノード１０の出力データをＣＡＮバス１２を介して他のノード１０へ送信すべくデジタル化し、また、他のノード１０からＣＡＮバス１２を介して受信した入力データをデコードして自身での制御を実行する。また、バスインターフェース２２は、コントローラ２８により制御され、他ノード１０にデータを送信すると共に、自ノード１０に送信されてきたデータを受信する。
【００１９】
各ノード１０がＣＡＮバス１２へ向けて送出するデータは、予め所定の構成を有するデータフレームにより構成されている。すなわち、このデータフレームは、少なくとも、先頭から順に、フレームの始まりを示すスタートオブフレーム（ＳＯＦ）と、データ種類として他の種類のデータと区別するための各データ固有の識別ＩＤを示すＩＤフィールド（複数のノード１０からの送信データが衝突した際における当該データを送信するうえでの優先順位を示す調停領域）と、から構成されている。ＳＯＦは、常にＣＡＮ−ＨとＣＡＮ−Ｌとの間に電位差が生ずるドミナントレベル（ビット“０”）の１ビットデータである。また、ＩＤフィールドは、高優先のデータほどＭＳＢからドミナントレベルのビットが多く継続し、低優先のデータほどＭＳＢにより近くにレセッシブレベルが現れる１１ビットのデータである。
【００２０】
また、データフレームは、調停領域であるＩＤフィールドの後は、例えば、当該データの長さを示すデータ長コード（ＤＬＣ）と、データ自体の内容（例えば、車輪速の情報や駆動トルクの制御指令値等）を示すフィールドと、伝送エラーをチェックするためのＣＲＣフィールドと、正常に受信が完了したことを確認するためのフィールドと、フレームの終わりを示すエンドオブフレーム（ＥＯＦ）と、から構成されている。
【００２１】
尚、本実施例のネットワークシステムは、各ノード１０がＣＡＮバス１２を介して他のノード１０へ送信すべきデータを時分割多重で送信することが可能なシステムである。各ノード１０は、それぞれ定期或いは不定期にデータをＣＡＮバス１２へ向けて送出するが、ＣＡＮバス１２に他のデータが流れていない状態ではデータ送出を開始することができる一方、他の１以上のノード１０から同時にデータ送信が開始されたときは送信優先順位に従ってデータ送信を行い、他のノード１０からのデータ送信が行われているときは一定時間待機した後にデータ送信を行う。
【００２２】
すなわち、本実施例のＣＡＮ通信システムにおいては、複数のノード１０からのデータ送信が同時に開始されるときは、それらのノード１０間でデータ送信の許可・禁止を決定する調停が行われる。具体的には、各ノード１０はそれぞれ、データフレームの１ビット目のＳＯＦ（ビット“０”）からＣＡＮバス１２への送信を開始し、次のＩＤフィールドをＭＳＢから順にＣＡＮバス１２へ送信する。各ノード１０はそれぞれ、少なくとも自己のバスインターフェース２２からＣＡＮバス１２に対してデータフレームの送信を行った場合、その送信ごとに、ＣＡＮバス１２に流れた送信結果（送信ビット）を監視（モニタ）する。詳細には、ノード１０が送信すべきであるとして生成した所望のデータフレームの各ビットと、実際にＣＡＮバス１２に流れたデータフレームの各ビットとを比較することにより、自ノード１０による所望のデータフレームがＣＡＮバス１２に送信されてその送信が成功したか否かを判別する。
【００２３】
複数のノード１０からのデータ送信が同時に開始されるときには、それらの各ノード１０は、まず、ビット“０”のＳＯＦを送信するので、自己のデータフレームのＳＯＦに関しその送信が成功したと判別する。そして、次にはＩＤフィールドの送信をそのＭＳＢから順に行うが、この送信過程で、自己の送信する所望のＩＤフィールドのビットが“０”である状況下において実際にＣＡＮバス１２に流れたデータのモニタ結果としてビット“０”を得たときは、自己のデータ送信に関し調停に勝ちその送信が成功したと判断して以後のデータフレームの送信を継続する。一方、自己の送信する所望のＩＤフィールドのビットが“１”である状況下において実際にＣＡＮバス１２に流れたデータのモニタ結果としてビット“０”を得たときは、自己のデータ送信に関し調停負けが生じその送信が失敗したと判断して以後のデータフレームの送信を一時中止（中断）する。
【００２４】
かかるＣＡＮ通信システムにおいては、複数のノード１０からのデータ送信が同時に開始されたときは、送信優先度の高いデータフレーム具体的にはＩＤフィールドのＭＳＢからドミナントレベルのビットが多く継続するデータフレームを送信するノード１０が優先され（調停勝ちし）、送信優先度の低いデータフレーム具体的にはＩＤフィールドでレセッシブレベルがより早く現れるデータフレームを送信するノード１０が調停負けするように、それらのノード１０間でのデータ送信に関する調停が実施される。尚、ノード１０は、ＣＡＮバス１２へのデータフレームの送信途中で自己の調停負けを起こした場合には、その後所定時間が経過した後に再び同一のデータフレームの送信をＳＯＦから順に開始するものとし、調停負けごとにその送信を繰り返し行う。
【００２５】
ところで、ノード１０は、データフレームの送信中にＣＡＮバス１２のＣＡＮ−ＨとＣＡＮ−Ｌとの間を電位差が生じたままのドミナントレベル（ビット“０”）に維持させる故障（ＣＡＮバス１２の支線の一部断線を含む）を起こすことがある。かかる故障を起こしているノード（以下、故障ノードと称す）１０がその故障を認識することなくＣＡＮバス１２に対するデータ送信を行うものとすると、故障が生じていない他の正常なノード（以下、正常ノードと称す）１０からＣＡＮバス１２へ送信されるデータフレームが破壊され続ける不都合が発生する。
【００２６】
すなわち、故障ノードがその故障を認識することなくＣＡＮバス１２に対してデータフレームを送信する状況を考えると、そのデータフレーム中におけるビット“０”のＳＯＦやその後の調停領域であるＩＤフィールドにおけるビット“０”のデータが送信される際には、モニタ結果がビット“０”に維持されて送信すべきデータフレームのものと一致するので、不都合は生じないが、ＩＤフィールドにおけるビット“１”のデータが送信される際にもモニタ結果がビット“０”に維持されることとなり、送信すべきデータフレームのものと一致しないこととなる。
【００２７】
このようなモニタ結果の不一致が発生すると、故障ノード（特に、調停領域にＣＡＮ通信のルールに従ったスタッフビットが挿入されないほどに低優先のデータフレームを送信するノード）１０は、自己の故障と認識せずに単に他ノード１０との間の調停に負けたと判定してしまう。このため、故障ノード１０は、自己の故障に起因して自己のデータ送信に対するモニタ結果が“０”に固定されるにもかかわらず調停負けが生じたと誤判定することに起因してそのデータフレームの送信中断と再送信とを繰り返すこととなり、その結果、ＣＡＮバス１２上へ故障ノード１０からＩＤフィールド中に途切れる不完全なデータフレームが乱発することとなり、正常ノード１０からのデータフレームが破壊され続けてしまう。
【００２８】
そこで、本実施例のシステムは、自ノード１０の故障を、他ノード１０との間で調停負けが生じていると誤判定するのを継続させることなく確実に検出することとしている。以下、本実施例のシステムにおいて行われる各ノード１０における故障を検出する手法を説明する。
【００２９】
図２は、本実施例のノード１０において通信ノード故障検出装置を構成するＣＰＵ２０のコントローラ２８が実行する制御ルーチンの一例のフローチャートを示す。図３は、本実施例の通信ノード故障検出装置においてデータフレームのＩＤフィールド（調停領域）における優先度を変更するのに適した優先度を説明するための図を示す。また、図４は、本実施例の通信ノード故障検出装置において行われるノード故障検出の手法を説明するための図を示す。
【００３０】
ＣＡＮバス１２に接続する各ノード１０はそれぞれ、データフレームの送信ごとに、その送信過程で、所望データフレームのＩＤフィールドにおけるビット“１”のデータが送信される際にモニタ結果がビット“０”に維持されることにより、実際にデータ送信に関する調停が行われて調停負けが生じたか否かを判別する（ステップ１００）。その結果、調停負けが生じたと判別された場合は、所定のカウンタＣＮＴを“１”だけインクリメントする処理を実行する（ステップ１０２）。尚、この所定のカウンタＣＮＴは、同じデータフレームの送信に関し調停負けが連続して生じた回数を計数するためのカウンタである。一方、調停負けが生じていないと判別された場合は、上記した所定のカウンタＣＮＴを“０”にリセットする処理を実行し（ステップ１０４）、上記ステップ１００の処理を繰り返す。
【００３１】
ノード１０は、上記の如く所定のカウンタＣＮＴを“１”だけインクリメントする（ステップ１０２）と、次に、その所定のカウンタＣＮＴが所定回数Ｎ０に達したか否かを判別する（ステップ１０６）。尚、この所定回数Ｎ０は、ノード１０が故障しているか否かを検出すべきタイミングとして設定された、同じデータフレームの送信に関し調停負けが連続して生ずべき回数であり、２回以上の回数（例えば５回）に設定されている。その結果、否定判定がなされた場合は、再び上記ステップ１００の処理を行い、一方、肯定判定がなされた場合は、その送信を繰り返しているデータフレームの調停領域であるＩＤフィールドが示す優先度を、所定の高優先のものに変更する（ステップ１０８）。
【００３２】
ここで、ＣＡＮ通信においては、５ビット連続して同じデータ（“０”又は“１”）の送信を行う際には６ビット目にそのデータと反転したデータ（“１”又は“０”；スタッフビット）を挿入しなければならないというルールが存在する。
【００３３】
例えば、図３（Ａ）に示す如く１１ビットのＩＤフィールドが“０８０（＝０００１０００００００バイナリ）”であるときは、データフレームのＳＯＦから４ビット連続してデータが“０”となるが、５ビット目がデータ“０”ではないため、６ビット目にスタッフビット“１”が挿入されることはない。一方、ＩＤフィールドの４ビット目がデータ“１”となった後、５ビット連続してデータが“０”となるため、その直後にはスタッフビット“１”が挿入される。尚、ＩＤフィールドが“０８０”よりも大きい値であるときは、この“０８０”のＩＤフィールドのものよりも上位にデータ“１”が現れるので、“０８０”のものと同様に、ＩＤフィールドの上位にスタッフビット“１”が挿入されることはない。
【００３４】
このように１１ビットのＩＤフィールドが、ＭＳＢからデータ“０”が４ビット以上連続しない“０８０”以上であるときは、ＩＤフィールドの上位にスタッフビット“１”が挿入されることなくデータフレームの送信が行われる。かかるデータフレームを送信するノード１０が故障ノードであるときは、ＳＯＦから数えて２ビット目から５ビット目までの何れかにビット“１”のデータが送信されることとなるが、そのモニタ結果はビット“０”に維持されるので、調停負けが発生したとしてその送信が中断されて、それが繰り返される。
【００３５】
一方、図３（Ｂ）に示す如く１１ビットのＩＤフィールドが“０７Ｆ（＝００００１１１１１１１バイナリ）”であるときは、データフレームのＳＯＦから５ビット連続してデータが“０”となるため、６ビット目にスタッフビット“１”が挿入される。尚、ＩＤフィールドが“０７Ｆ”よりも小さい値であるときも、この“０７Ｆ”のＩＤフィールドのものと同位又はそれよりも下位で初めてデータ“１”が現れるので、“０７Ｆ”のものと同様に、ＩＤフィールドの上位から５ビット目（ＳＯＦを含めれば６ビット目）にスタッフビット“１”が挿入される。
【００３６】
このように１１ビットのＩＤフィールドが、ＭＳＢからデータ“０”が４ビット以上連続する“０７Ｆ”以下であるときは、データフレームの送信がＩＤフィールドの上位にスタッフビット“１”を挿入した状態で行われる。かかるデータフレームを送信するノード１０が故障ノードであるときは、ＳＯＦから数えて６ビット目に必ずビット“１”のデータが送信されることとなるが、そのモニタ結果はビット“０”に維持されて不一致が生ずることとなる。このスタッフビットのデータは、ＩＤフィールド内に挿入されたものであるが、送信優先度を示す調停に関するものではないため、調停負けが生じたと判定することはできない一方で、モニタ結果が必ず“１”となる必要がある。従って、挿入されたスタッフビットに対するモニタ結果が一致すれば、ＣＡＮバス１２をドミナントレベル“０”に固着させる故障はノード１０には生じていないと判断できる一方、そのモニタ結果が一致しなければ、かかる故障がノード１０に生じていると判断できる。
【００３７】
このような点に鑑みて、ノード１０は、上記ステップ１０８においてＩＤフィールドの示す優先度を、ＣＡＮ通信のルールに従ってスタッフビット“１”が挿入される“０７Ｆ”以下の高優先のものへ変更する。そして、その優先度変更後のデータフレームをＳＯＦから順にＣＡＮバス１２に対して送信し（ステップ１１０）、そのデータフレームの送信過程において先頭から６ビット目のスタッフビットの状態をモニタする（ステップ１１２）。
【００３８】
その結果、ノード１０は、スタッフビットに対するモニタ結果が“１”となり一致するときは、自ノード１０が正常であるとして以後のデータフレームの送信を継続する（ステップ１１４）。一方、スタッフビットに対するモニタ結果が“０”となり不一致であるときは、自ノード１０にＣＡＮバス１２をドミナントレベル“０”に固着させる故障が生じていると判定する（ステップ１１６）。
【００３９】
例えば、故障しているノード１０が図４（Ａ）に示す如く“０８０”以上である“１２０”の１１ビットデータを有するＩＤフィールドを送信する場合、その故障ノード１０は、まず、（１）ＳＯＦからデータフレームの送信を開始し、そして次に、（２）“００１００１０００００”のバイナリデータを有するＩＤフィールドをＭＳＢから順に送信する。これらの送信過程で、故障ノード１０は、ＩＤフィールドのＭＳＢから数えて２ビット目までの送信では、モニタ結果もビット“０”となるので調停勝ちしているとして自己のデータフレームの送信を継続する一方、そのＭＳＢから数えて３ビット目のビット“１”のデータの送信では、モニタ結果がビット“０”となるので（３）調停負けが生じたと誤判定して、（４）以後のデータフレームの送信を中断する。そして、（５）所定時間経過後に上記（１）〜（４）の処理を繰り返し行う。
【００４０】
故障ノード１０は、上記（１）〜（４）の処理を繰り返し行って同一のデータフレームの送信中断が生じた回数或いは調停負けが生じた回数が所定回数連続したと判別した場合、（６）その１１ビットデータのＩＤフィールドを、“１２０”の１１ビットデータから例えば図４（Ｂ）に示す如く“０７Ｆ”以下である“０３０”の１１ビットデータへ変更する。そして次回データ送信をすべき際には、そのＩＤフィールドを有するデータフレームの送信をＳＯＦから開始し、ＳＯＦの次に、（７）“０００００１１００００”バイナリデータをＭＳＢから順に送信する。
【００４１】
故障ノード１０は、ＩＤフィールドのＭＳＢから数えて４ビット目までの送信では、モニタ結果も“０”となるので調停勝ちしているとしてその自己のデータフレームの送信を継続できる。一方、（８）ＩＤフィールドのＭＳＢから数えて５ビット目（ＳＯＦから数えて６ビット目）にはＣＡＮ通信のルールに従ってスタッフビット“１”を挿入したうえで、そのスタッフビットの送信を実行する。しかし、このスタッフビットの送信ではそのモニタ結果が“０”となり不一致となるので、（９）スタッフエラーが生じていると認識し、自ノード１０にＣＡＮバス１２をドミナントレベル“０”に固着させる故障が生じていると判定する。ノード１０は、かかる自己の故障判定を行った場合、ノード故障処理として、（１０）継続中のデータフレームの送信を以後停止し、また、後の故障診断のために、自ノード１０の故障（ＣＡＮバス１２の支線の一部断線を含む）が生じている旨を故障診断用データとして自ノード１０の有するメモリ内に記憶するなどの処理を実行する。
【００４２】
このように本実施例によれば、同一のデータフレームの送信に関し調停負けが所定回数連続したノード１０において、そのデータフレームの送信優先度を、ＣＡＮ通信のルールに従ってスタッフビットが挿入されるほどの高優先のものへ変更したうえで、そのスタッフビットのモニタ結果に基づいて、ＣＡＮバス１２をドミナントレベル“０”に固着させる故障が自ノード１０に生じたか否かを検出することができる。従って、本実施例の通信ノード故障検出装置によれば、自ノード１０に生じたＣＡＮバス１２をドミナントレベル“０”に固着させる故障を、他ノード１０とのデータ送信に関する調停負けが生じていると継続して誤判定することなく確実に検出することが可能となっている。
【００４３】
また、同一のデータフレームの送信に関して調停負けが自ノード１０の故障に起因するものではなく他ノード１０との競合に起因して偶然的に所定回数連続する場合もある。これに対して、本実施例の通信ノード故障検出装置においては、かかる事態が生じても、スタッフビットに対するモニタ結果が“１”となり一致する筈であるので、自ノード１０に故障が生じていると誤判定されるのを防止することができる。従って、本実施例によれば、正常なノード１０或いはその正常なノード１０に接続するＣＡＮバス１２の支線を誤って交換してしまう事態を防止することができる。
【００４４】
ノード１０の故障が検出されると、そのノード１０からの以後のデータフレームの送信は停止される。このため、本実施例のシステムによれば、故障ノード１０からＣＡＮバス１２上へ調停領域であるＩＤフィールドの中途で途切れる不完全なデータフレームが乱発されるのを抑制することができ、その乱発に起因した正常ノード１０からのデータフレームの破壊を大幅に低減することが可能となっている。また、ノード１０の故障が検出されると、その故障発生の旨がメモリに記憶される。この点、本実施例のシステムによれば、ノード故障診断時に、各ノード１０の有するメモリに格納されている情報それぞれからノード故障の有無を外部に抽出して読み出すことができ、これにより、その故障診断を正確に行うことができ、正常なノード１０やＣＡＮバス１２の誤交換を防止することが可能となっている。
【００４５】
尚、上記の実施例においては、ノード１０のＣＰＵ２０が、バスインターフェース２２からＣＡＮバス１２へＩＤフィールドが設けられたデータフレームを送信することにより特許請求の範囲に記載した「データ送信手段」が、少なくともデータ送信過程でＣＡＮバス１２に流れた送信結果をモニタすることにより特許請求の範囲に記載した「モニタ手段」が、モニタ結果が自己の送信中のデータフレームのものよりも優先度の高い者である場合に、他ノード１０との間で調停負けが生じたとしてそのデータフレームのＣＡＮバス１２への送信を中断することにより特許請求の範囲に記載した「送信中断手段」が、図２に示すルーチン中ステップ１０６の処理を実行することにより特許請求の範囲に記載した「調停負け回数判別手段」及び「調停負け回数判別ステップ」が、ステップ１０８の処理を実行することにより特許請求の範囲に記載した「優先度変更手段」及び「優先度変更ステップ」が、ステップ１１２〜１１６の処理を実行することにより特許請求の範囲に記載した「故障検出手段」及び「故障検出ステップ」が、それぞれ実現されている。
【００４６】
ところで、上記の実施例においては、ＩＤフィールドが１１ビットデータであるデータフレームを各ノード１０がＣＡＮバス１２に送信するものとしているが、ＩＤフィールドが２９ビットデータであるデータフレームを送信することとしてもよい。但し、ＩＤフィールドが２９ビットデータであるデータフレームをノード１０が送信する状況にあるときは、その故障検出を以下の如く行う必要がある。
【００４７】
すなわち、２９ビットのＩＤフィールドでは、一般に、ＭＳＢを含めそのＭＳＢから３ビットが“１１０”バイナリと固定されているため、２９ビットのままでその優先度を所定の高優先のものへ切り替えても、ノード故障の発生にもかかわらず他ノードとの間で調停負けが生じたとの誤判定が継続するおそれがある。そこで、この構成では、調停負けが同一のデータフレームに対して所定回数連続した場合、一旦、そのデータフレームのＩＤフィールドを２９ビットのものから１１ビットのものに変更し、そのうえでそのデータフレームのＩＤフィールドをＣＡＮ通信のルールに従ってスタッフビットが挿入されるほどの高優先のものに設定する。かかる構成によれば、送信優先度の変更後は、上記した実施例と同様の手法でスタッフビットのモニタ結果からノード故障の有無を検出できるので、２９ビットのＩＤフィールドを有するデータフレームを送信するノード１０の故障でも、他ノード１０との間で調停負けが生じたと継続して誤判定することなく確実に検出することが可能となり、上記した実施例と同様の効果を得ることが可能となる。
【００４８】
また、上記の実施例においては、ＣＡＮ通信ネットワークシステムを、車両の有する各種の電子制御装置をノード１０としてＣＡＮバス１２を介して互いに接続させたものとしたが、本発明はこれに限定されるものではなく、車両以外に搭載されて、複数のノード１０をＣＡＮバス１２を介して接続させたものであればよい。
【図面の簡単な説明】
【００４９】
【図１】本発明の一実施例である通信ノード故障検出装置を搭載するノードを備えるシステムの要部構成図である。
【図２】本実施例の通信ノード故障検出装置において実行される制御ルーチンの一例のフローチャートである。
【図３】本実施例の通信ノード故障検出装置においてデータフレームの調停領域における優先度を変更するのに適した優先度を説明するための図である。
【図４】本実施例の通信ノード故障検出装置において行われるノード故障検出の手法を説明するための図である。
【符号の説明】
【００５０】
１０  ノード
１２  ＣＡＮバス
２０  ＣＰＵ
２８  コントローラ
【図１】
2006237832.tif 000003
【図２】
2006237832.tif 000004
【図３】
2006237832.tif 000005
【図４】
2006237832.tif 000006