JP5405927B2 - ネットワークノード - Google Patents

ネットワークノード Download PDF

Info

Publication number
JP5405927B2
JP5405927B2 JP2009167253A JP2009167253A JP5405927B2 JP 5405927 B2 JP5405927 B2 JP 5405927B2 JP 2009167253 A JP2009167253 A JP 2009167253A JP 2009167253 A JP2009167253 A JP 2009167253A JP 5405927 B2 JP5405927 B2 JP 5405927B2
Authority
JP
Japan
Prior art keywords
node
network
data
recovery
nodes
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.)
Active
Application number
JP2009167253A
Other languages
English (en)
Other versions
JP2011023983A (ja
Inventor
卓也 寺澤
浩二 水本
淳一 松澤
幸太郎 八須
Original Assignee
スパンション エルエルシー
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 スパンション エルエルシー filed Critical スパンション エルエルシー
Priority to JP2009167253A priority Critical patent/JP5405927B2/ja
Publication of JP2011023983A publication Critical patent/JP2011023983A/ja
Application granted granted Critical
Publication of JP5405927B2 publication Critical patent/JP5405927B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)

Description

本発明は,ネットワークノード及びそのネットワークシステムに関する。
ネットワークのノードは,例えば,車載用ネットワークなどのネットワークに設けられた通信機能を有する電子制御装置である。各ノードは,所定の通信プロトコルにしたがって,データの送受信を行い、協調制御を行う。
車載用ネットワークとして,従来のCAN(Controller Area Network)やLIN(Local interconnect network)が運用されてきたが、ネットワークによる通信制御の多様化、大容量化により,新規プロトコルとしてFlexRayがすでに一部のシステムでは実運用されている。FlexRayは,X-by-Wireを実現するために有望視されている車載用ネットワークであり,よりきめ細かい制御を実現するためのリアルタイム性を有し,より高速かつ信頼性の高いネットワークである。
このような車載用ネットワークは,ネットワーク内に複数のノードが接続され,互いに通信を行っている。各ノードであるECU(Electric Control Unit)は通信制御機能を有する通信コントローラとマイクロプロセッサとを有し,マイクロプロセッサはそれぞれ対応する被制御装置の制御を行う。たとえば,あるノードでエンジン制御操作を検出した場合,その操作データをネットワークを経由して他のノードに送信し,他のノードはその操作データに対応して被制御装置であるエンジンを制御する。
FlexRayの特徴は,CANのようなイベントドリブン方式ではなく,タイムトリガ方式であることが知られている。タイムトリガ方式では,ある一定時間内(通信サイクル)に各ノードからデータを送信するタイミング(タイムスロット)が決まっている。このため,複数のノードがネットワークにつながっている場合でも,各送信ノードは確実に決まった周期でデータを送信することができ,ノード間で送信の衝突が生じないようになっているので,リアルタイム性を確保することができる。また,FlexRayは基本的には2チャネルで構成される仕様であり, 一方のチャネルが障害を起こしても他方のチャネルで信号を送信でき,ネットワーク障害に強く,確実なデータ送信が可能な高信頼性の通信方式である。
FlexRayについては,例えば,以下の非特許文献に記載されている。また,ネットワーク関連の技術については,例えば,以下の特許文献に記載されている。
特開2008−252208号公報 特願平8−195767号公報
FlexRay Communications System Protocol Specification,Version 2.1 Revision A (22-December-2005),http://www.flexray.com/index.php
各ノードであるECU(Electric Control Unit)は,前述の通り,被制御装置を制御するマイクロプロセッサと,ネットワークの通信制御をおこなう通信コントローラとを有する。マまた、それらの障害対策としては一般的にウオッチドッグタイマーを利用したシステム暴走の監視/復旧が施される。ただし,その方法は,ソフトウェアの暴走によるマイクロコンピュータの重度障害を監視するのみであり, ネットワークの障害や通信コントローラの障害などの検出には対応できない。
FlexRayの仕様によれば,フレーム内のペイロード内にネットワークマネージメントベクタ(Network Management Vector: NMV)を設けることができる。このNMVを利用し、各ノードが正常に動作していることを示すアライブデータを書き込んで,他のノードに自身の正常状態を通知するECUの相互監視を行うことができ,ネットワーク内の複数のノードは,互いに正常動作しているか否かを相互に監視することができる。
しかし,NMVによる相互監視方式では,そのフレームを送信したノードに障害があるのか,受信したノードに障害があるのかまでは特定することはできない。そのため,信頼性の高い相互監視とそれに対応した復旧動作を担保することができない。
そこで,本発明の目的は,信頼性の高い相互監視と復旧動作を可能にするネットワークノードとそのネットワークシステムを提供することにある。
ネットワークノードの第1の側面は,複数のノードと共にネットワークに接続されるネットワークノードにおいて,通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,他のノードから前記自身のノード宛の復旧要求データを,規定した数以上受信したときに,自身のノードに復旧動作を実行させる復旧制御手段とを有する。
第1の側面によれば,信頼性の高い障害復旧動作をさせることができる。
本実施の形態におけるネットワークの構成図である。 本実施の形態における被状態監視ノードと状態監視ノードとの関係を示す図である。 本実施の形態におけるネットワークの通信スケジュールを示す図である。 本実施の形態におけるフレームの構成図である。 本実施の形態におけるネットワークノードの構成図である。 アライブデータの例について示す図である。 プライオリティノードを有するネットワークとタイムスロットとを示す図である。 プライオリティノード以外のノードの構成図である。 プライオリティノードの構成図である。
以下,本実施の形態を図面を参照して説明する。
図1は,本実施の形態におけるネットワークの構成図である。このネットワークは,ネットワークであるバス10に,複数のノード21〜24が接続されている。各ノード21〜24は,自身に割り当てられたタイムスロットでフレームをバス10に送信する。また,各ノード21〜24は,それぞれアクチュエータなどの被制御デバイスやセンサなどの被監視デバイスに接続され,被制御デバイスへの制御や被監視デバイスからの状態検出などを行う。そして,それらに応答して必要なコマンドや検出データなどをネットワークを介して他のノードに転送する。
以下,本実施の形態のネットワークは,FlexRayを具体例にして説明されるが,必ずしもFlexRayに限定されるものではなく,フレームを互いに転送しあう複数のノードが接続されたネットワークに適用可能である。
前述のとおり,各ノード21〜24は,タイムトリガ方式で自身に割り当てられたタイムスロットで自身のフレームをバス10に送信する。そして,各ノード内の通信コントローラは,どのタイムスロットのフレームを受信すべきかをコンフィギュレーションデータにより設定されており,その設定値に対応して,バス上のフレームを受信する。タイムトリガ方式の場合は,通信サイクルで必ず自身のフレームを送信することができるので,リアルタイム性を確保することができ,走行制御系の車載ネットワークとして適している。
図2は,本実施の形態における被状態監視ノードと状態監視ノードとの関係を示す図である。この図では,ノード20Aが被状態監視ノードであり,ノード20Xが状態監視ノードである。被状態監視ノード20Aは,自身が送信するフレーム内に正常状態を示すアライブデータ(アライブ情報)を毎回書き込んでネットワーク上に送信する。それに対して,状態監視ノード20Xは,被状態監視ノード20Aから送信されるフレームを受信し,その中のアライブデータを判定し,被状態監視ノード20Aが正常動作状態か否かを判定する。この判定は,受信したアライブデータがあらかじめ規定されている正常状態のパターンと一致するか否かで行われる。そして,不一致の場合は,状態監視ノード20Xは,自身が送信するフレーム内にその被状態監視ノード20A宛の復旧要求データを書き込んでネットワーク上に送信する。
被状態監視ノード20Aは,状態監視ノード20Xから送信されるフレームを受信し,そのフレーム内に自身宛の復旧要求データを検出したら,自身のノード内のネットワークドライバ(バスドライバ),通信コントローラ,マイクロプロセッサに対して復旧動作を実行させる。
本実施の形態では,復旧要求の信頼性を担保するために,被状態監視ノード20Aは,複数の状態監視ノード20Xから送信されるフレーム内に自身への復旧要求データが含まれているか否かをチェックし,規定数以上の復旧要求データを受信した場合に,自身の復旧動作を実行する。
その理由は,状態監視ノード20Xによるアライブデータの判定でアライブデータが規定されている正常状態パターンと一致しない場合,必ずしも被状態監視ノード20Aに何らかの障害が発生して正常状態をあらわすアライブデータを書き込むことができなかったとは限らない。例えば,状態監視ノード20Xの通信コントローラの異常状態によってそのような不一致が発生する場合も考えられるし,ネットワークそのものの不具合により不一致が発生する場合も考えられる。
そこで,本実施の形態では,被状態監視ノード20Aは,複数の状態監視ノード20Xから規定数以上(例えば全状態監視ノード数の過半数以上)の復旧要求データを受信した場合に,復旧動作を実行する。さらに,別の実施の形態では,被状態監視ノード20Aは,復旧要求データの数に応じて,実行する復旧動作を選択する。さらに,別の実施の形態では,状態監視ノード20Xは,被状態監視ノード20A毎にアライブデータの判定結果をカウントし,比較的長い期間で検出された不一致の回数に応じて,復旧処理レベルを決定し,復旧要求データと共に復旧処理レベルの情報もフレームに書き込んで,被状態監視ノード20Aにネットワーク経由で送信する。被状態監視ノード20Aは,その復旧処理レベルに対応した復旧処理を実行する。
図3は,本実施の形態におけるネットワークの通信スケジュールを示す図である。本ネットワークにおける通信は,たとえば,予め決められたスケジュールに沿ってフレームデータの送受信を行う。すなわち,タイムトリガ型である。通信スケジュールは,図3に示されるとおり,0〜63を繰り返しカウントする通信サイクル30と,1つの通信サイクル内でフレーム送信のスケジューリングを管理するセグメント32,34と,スロットSL1〜SL4とで構成される。
1つの通信サイクルは,スタティックセグメント32と,ダイナミックセグメント34と,アイドル時間36とで構成される。そして,スタティックセグメント32では,タイムトリガ方式により各ノードが送信を行う期間であり,予め決められた長さのフレームFL1〜FL4がスケジュールに沿って送信される。図1のすべてのノードに同じ長さのスロットSL1〜SL4が割り当てられていて,各スロットで各フレームのフレームFL1〜FL4がネットワークのチャネル上に送信される。したがって,1回の通信サイクルを経過すると,すべてのノードのフレームがバス上に送信されたことになる。
ダイナミックセグメント34では,任意のタイミングでフレームを送信するイベントドリブン方式により送信が行われる期間であり,図示しないが,送信データは可変長である。また,アイドル時間36中に,全ノード間で同期をとることが行われる。このように,タイムトリガ方式により1回の通信サイクル内で全ノードが確実に送信することができ,リアルタイム性と高信頼性とを実現するとともに,イベントドリブン方式のダイナミックセグメントも持たせている。本実施の形態では,上記のダイナミックセグメントは必ずしも必要ではない。
図4は,本実施の形態におけるフレームの構成図である。フレームFLは,ヘッダ40と,ペイロード41と,トレーラー42とで構成される。ヘッダ40内には,同期ビット,フレームIDなどに加えて,どの通信サイクルかを示すサイクルカウンタの情報も含まれる。ペイロード41には,ネットワーク管理ベクタ(NMV)50と,ペイロードデータ51とが含まれる。そして,トレーラー42には,フレームの誤り訂正コードCRCが含まれる。
上記のNMV50は,そのNMVフォーマット60に示されるとおり,各ノード21〜24で書き込まれるノードの正常状態を示すアライブデータ領域(図中Alive for #)と,状態監視ノードで書き込まれる各ノード21〜24宛の復旧要求データ領域(図中Reset for #)とを,各ノードそれぞれに対応して有する。したがって,フォーマット60は4対の領域を有する。NMV50は,すべてのスロットのフレームで同じデータ長を有する。
今仮に,ノードNode1が自身のフレームをネットワーク上に送信し,他のノードのフレームをネットワーク上から受信する場合を想定して説明する。ノードNode1は,自身が送信するフレーム61に,自身の状態が正常であることを示すアライブデータを「Alive for 1」に書き込み,他のノードに対する復旧要求データ「Reset for 2」「Reset for 3」「Reset for 4」を必要に応じて書き込む。
さらに,ノードNode1は,ノードNode2のタイムスロットのフレーム62を受信する。このフレーム62には,ノードNode1宛の復旧要求データ「Reset for 1」と,ノードNode2のアライブデータ「Alive for 2」と,ノードNode4, Node5宛の復旧要求データ「Reset for 4」「Reset for 5」が含まれる。同様に,ノードNode1は,ノードNode3のタイムスロットのフレーム63と,ノードNode4のタイムスロットのフレーム64も受信する。これらのフレーム63,64もフレーム62と同様である。
図4の例では,ノードNode1は,フレーム62,63,64で,ノードNode2,3,4すべてから復旧要求データ「Reset for 1」を受信している。また,すべてのフレームで,他のすべてのノード宛の復旧要求データが書き込まれている。この復旧要求データは,後述するアルゴリズムで,各ノードの通信コントローラによりフレームに書き込まれる。
上記のように,各ノードがそれぞれのスロットで送信するフレーム内に,自身の正常状態を示すアライブデータを書き込むことで,各ノードがノードの動作状態を相互監視することができる。もしノードに障害が発生しノードが正常状態でなければ,正常状態を示すアライブデータを書き込むことができないからである。さらに,各ノードは,他のノードの動作状態を相互に監視し,正常状態でないことを検出したら,そのノード宛の復旧要求データを自身のフレームに書き込む。そして,各ノードは他のノードのフレームをチェックして,自身宛の復旧要求データが出されたか否かを確認する。
図5は,本実施の形態におけるネットワークノードの構成図である。各ノードは,通信コントローラ70と,ネットワークのバス10にフレームを出力して送信し,他のノードが出力したバス10上のフレームを受信して入力するネットワークドライバ(バスドライバ)72と,図示しない通信コントローラの制御を行うマイクロプロセッサ74とを有する。通信コントローラ70とネットワークドライバ72は,ハードウエアで構成される。通信コントローラ70は,マイクロプロセッサ74内にハードウエアマクロとして埋め込まれても良い。
通信コントローラ70は,ネットワークドライバ72と接続される通信制御マクロ710と,通信制御マクロ71内のNMVレジスタ712へのアクセスを行うNMVアクセスユニット730と,他のノードからの復旧要求データに基づいて自身の復旧処理を判定する復旧制御ユニット720と,判定された復旧処理を行う復旧処理ユニット750と,他のノードのアライブデータを判定して必要に応じて他のノード宛の復旧要求データを自身のフレームに書き込むアライブ情報管理ユニット740とを有する。
まず,ノードが自身のフレームを送信する場合は,マイクロプロセッサ74がフレーム内のデータを生成し,通信制御マクロ710内のメッセージバッファ711内に書き込む。フレームのヘッダ40とトレーラー42のデータは,通信制御マクロ710により生成されるが,ペイロード41のペイロードデータ51は,マイクロプロセッサ74が生成する。
NMVのデータ50は,図4のNMVフォーマット60にあるとおり,自身のアライブデータと,他のノード宛の復旧要求データとを有する。自身のアライブデータは,マイクロプロセッサ74が通信サイクル毎に生成しメッセージバッファ711に書き込む。このアライブデータは,自身のノードが正常状態であることを示すビットであり,通信サイクル毎に変更することが決められたビット構成であってもよく,または,通信サイクルにかかわらず常に同じビット構成であってもよい。また,他のノード宛の復旧要求データは,アライブ情報管理ユニット740内の復旧要求発生器745が生成しメッセージバッファ711に書き込む。
通信制御マクロ710は,ネットワークドライバ72が受信したフレームに含まれるメッセージと,ネットワークドライバ72から出力するフレームに含まれるメッセージとを一次的に格納するメッセージバッファ711と,受信したフレームから抽出されたNMVのデータを格納するNMVレジスタ712と,受信したフレームから抽出されたサイクルカウンタのデータを格納して現在の通信サイクルの確認に使用される通信サイクルカウンタ713とを有する。
NMVアクセスユニット730は,NMVレジスタ712にアクセスして,NMVレジスタ内の自身宛の復旧要求データを復旧要求バッファ721に,他のノードのアライブデータをアライブデータバッファ741にそれぞれ格納する。
通信制御マクロ710は,初期化時に通信のコンフィギュレーションデータを設定されることで,所望の通信制御を実行する。このコンフィギュレーションデータには,どのタイムスロットのフレームを受信すべきかなどの情報が含まれていて,マイクロプロセッサによりインストールされる。
[復旧制御ユニット]
復旧制御ユニット720では,復旧要求判定器722は,復旧要求バッファ721に格納された他のノードからの復旧要求データの欄をチェックして,他のノードから自身宛の復旧要求データを受信したか否かを判定する。他のノードからの復旧要求データの欄とは,図4のフレーム62,63,64の「Reset for 1」の欄であり,ここに自身宛の復旧要求データが書き込まれているか否かが判定される。そして,復旧要求カウンタ723は,他のノードからの自身宛の復旧要求データの数をカウントする。
そして,復旧処理判定器725は,例えば,1回の通信サイクル中の復旧要求カウンタ723のカウント数が,規定された値以上であれば,復旧処理すべきと判定し,復旧処理ユニット750に復旧処理要求を出力する。図1の例では,他のノードであるノード22,23,24のうち,過半数の2以上のノードから復旧要求データを受信している場合に,その復旧要求データが高い信頼性を有していると考えられるので,復旧処理判定器725は,復旧処理要求を出力する。つまり,規定数,例えば過半数,の状態監視ノードから自身宛の復旧要求データを受信している場合に復旧処理が必要と判定することで,自身のノード以外の何らかの障害により正常状態を示すアライブデータが受信されないなどで他のノードから自身宛に復旧要求データを受信していた場合に,無駄に復旧処理を実行することを回避することができる。
復旧処理ユニット750は,復旧要求に応答して,(1)マイクロプロセッサ74による自己診断処理,(2)通信コントローラ70のリコンフィギュレーション処理,(3)マイクロプロセッサ74によるリセット処理,(4)ネットワークドライバ72の入出力遮断処理のうちいずれかを実行する。復旧処理(1)は,マイクロプロセッサ74が,自己診断プログラムを実行して,ソフトウエア障害等に対する必要な復旧処理を行う処理であり,最も軽度の障害レベルのときに実行される。復旧処理(2)は,マイクロプロセッサ74による通信コントローラ70の初期化に対応し,コンフィギュレーションデータの再設定により,通信コントローラ70による障害発生を抑制することができる。リコンフィギュレーションは,マイクロプロセッサ74が生成したコンフィギュレーションデータを,主に通信制御マクロ710に設定する処理であるが,他のユニットに設定されても良い。
復旧処理(3)はマイクロプロセッサのパワーオンリセットなどに対応する処理であり,主にプログラムの暴走に伴う障害から復旧することができる。そして,復旧処理(4)は,ネットワークドライバ72の入出力端子を遮断する処理であり,最も重度の障害レベルが発生したときの応急処理である。
上記の復旧処理(1)〜(3)の命令が復旧処理ユニット750によりマイクロプロセッサ74に発行されると,マイクロプロセッサ74は復旧処理中を示すモード信号を復旧処理ユニット750に返信する。それに応答して,復旧処理中を示すモード信号が他のノード宛のフレームに書き込まれて送信される。これにより,他のノードは,復旧処理中であることを認識することができる。
これら4つの復旧処理(1)〜(4)は,障害のレベルが低い順に実行されるべき処理に対応している。復旧処理判定器725は,いずれの復旧処理を実行すべきかを,たとえば,復旧要求カウンタ723のカウンタ値に応じて判定する。つまり,1回の通信サイクル中に受信した他の状態監視ノードからの復旧要求データの数に応じて,数が少なければ復旧処理(1)を判定し,数が多くなれば復旧処理(2)〜(3)を判定する。復旧処理(3)は,最も重度の障害発生時の処理であり,ネットワークドライバの遮断は,必ずしも復旧処理とは言えないが,それ以上の障害発生を抑制する処理といえる。
または,別の判定方法として,複数の通信サイクルを含む一定期間内に復旧処理が繰り返されるたびにその復旧処理のレベルを上げているようにしてもよい。
復旧処理レベルカウンタ724は,他の状態監視ノードから復旧要求データに加えて復旧処理レベルのデータを受信する場合に,復旧処理レベル別にその回数をカウントする。上記の例では,復旧処理(1)〜(4)別にその回数をカウントする。その場合は,復旧処理判定器725は,カウント数が最も多い復旧処理を選択して,復旧要求を復旧処理ユニット750に出力する。他の状態監視ノードによる復旧処理レベルの選定については後述する。
なお,復旧要求データと復旧処理レベルのデータは,送信側のノードで暗号化され,受信側のノードで復号化されることが好ましい。このようにすることで,復旧処理の起点となる受信データの信頼性を向上させて,不必要な復旧処理が行われることを抑制することができる。
[アライブ情報管理ユニット]
アライブ情報管理ユニットを有するノードは,状態監視ノードとしての機能を有する。
アライブ情報管理ユニット740では,状態判定器742が,アライブデータバッファ741に他のノード別に格納されている他のノードのアライブデータを正常状態を示す規定パターンと比較して,他のノードの動作状態を判定する。状態判定器742は,他のノードのアライブデータが正常状態の規定パターンと異なっている場合は,復旧要求発生器745にその結果を通知する。それに応答して,復旧要求発生器745は,メッセージバッファ711内の自身のフレームのNMV50の欄に,他のノード宛の復旧要求データを書き込む。
そして,他のノードは,この復旧要求データが書き込まれたフレームを受信し,その復旧要求データに対応して必要な復旧処理を実行する。この復旧処理については,上記の復旧制御ユニット720のところで説明済みである。
アライブ情報管理ユニット740は,一定の長い期間においてアライブデータ判定で検出した異常状態の回数を他のノード別にカウントし,そのカウント値に応じて最適な復旧処理レベルを判定し,他のノードに復旧要求データとともに復旧処理レベルのデータも送信する。つまり,アライブデータが正常状態以外のパターンの場合は,被状態監視ノードが正常に動作していない可能性があるので,復旧要求発生器745がその被状態監視ノードに対して復旧要求データを送信し,復旧処理を行わせている。しかし,比較的長い期間において,前記復旧要求データの送信にもかかわらず,アライブデータが正常状態以外のパターンを示す場合は,アライブ情報管理ユニット740がその回数に応じて徐々に復旧処理レベルを上げるようにすることで,被状態監視ノードに適切な復旧処理を行わせることができる。
そのために,異常状態カウンタ743は,被状態監視ノード別に異常状態をカウントする。そして,復旧処理レベル判定器744は,そのカウント値に応じて,被状態監視ノードに対する復旧処理レベルを判定する。判定された復旧処理レベルは復旧要求発生器745に供給され,復旧処理要求発生器745は,その復旧処理レベルを,メッセージバッファ711内の自身が送信するフレーム内のNMVの欄に書き込む。
そして,通信制御マクロ710は,自身のノードに割り当てられたタイムスロットでメッセージバッファ711に書き込まれたフレームをネットワークドライバ72を介してバス10に出力する。
図6は,アライブデータの例について示す図である。上記の説明では,アライブ情報管理ユニット740内の状態判定器742は,他の被状態監視ノードからのアライブデータを受信するたびに,そのアライブデータが正常状態を示すパターンと一致するか否かを判定した。FlexRay通信には,送信モードにコンティニュアスモードがあり,そのモードでは,各マイクロプロセッサが送信するデータを更新しなくても、通信コントローラが前回の送信データをそのまま送信することが可能である。かかるモードの場合,ノードに何らかの異常が発生して、アライブデータが更新されなくても前回の送信データにて正常状態を示すアライブデータが送信されている場合は,正常を示すアライブデータが送信される為、状態監視ノードは受信したアライブデータから被状態監視ノードの異常状態を検出することができない。
そこで,複数回の通信サイクルで受信したアライブデータを合成したデータを,正常状態を示すパターンと比較することが望ましい。そして,被状態監視ノードは,通信サイクル毎に異なるアライブデータをNMVデータとして送信し,複数回の通信サイクルで1つのアライブデータ長80のアライブデータを送信することが求められる。たとえば,各通信サイクルで送信される正常状態を示すアライブデータは,通信サイクル毎にビット反転されるようにしても良い。
図6において,サイクルNでは,受信したNMVデータ内のノードXのアライブデータ82が,アライブデータバッファ741の最下位ビットに格納される。さらに,次のサイクルN+1では,受信したNMVデータ内のノードXのアライブデータ84が,アライブデータバッファ741の最下位ビットに格納される。このとき,既に格納されていたサイクルNでのアライブデータ82は上位側にシフトされる。
そして,状態判定器742は,各通信サイクルで,1つのアライブデータ長80のアライブデータを正常状態のパターンと比較判定する。ただし,M回の通信サイクルで1つのアライブデータ長のデータを送信できる場合は,M回に1回だけアライブデータが正常状態のパターンと一致することが検出される。したがって,M回の比較判定で1回も一致しなければ,何らかの障害が発生していると判定される。
または,通信サイクルカウンタの値に応じて,正常状態のパターンを適宜選択するようにしてもよい。その場合は,直近のM回のアライブデータがすべて正常状態であったか否かを,各通信サイクル毎に判定することができる。いずれの方法でも,複数の通信サイクルで生成されたアライブデータをチェックすることで,上記のコンティニュアスモードにも対応可能である。
[プライオリティノード]
図5に示したネットワークノードの通信コントローラ70は,他のノードの状態監視をするアライブ情報管理ユニット740を有する。ただし,すべてのノードに他のノードの状態監視機能を持たせると,ネットワーク全体のコストアップになる。さらに,すべてのノードが他のノード宛の復旧要求データを送信するので,ノードによる復旧処理の必要性の検出は,すべてのノードのタイムスロットが経過した後になり,復旧処理に至るまでのレスポンス性が悪くなる。
そこで,ネットワーク内の全ノードのうち一部のノードをプライオリティノードとして,そのプライオリティノードにだけ他のノードの状態監視をするアライブ情報管理ユニット740を設ける。そして,プライオリティノードは,一部の被状態監視ノードについて状態監視を行うが,プライオリティノード以外のノードは,他のノードの状態監視は行わない。
図7は,プライオリティノードを有するネットワークとタイムスロットとを示す図である。ネットワークのバスに接続されたノードは,複数のグループG1,Gnに分けられ,各グループ内には,図7の例では,3つのノード21−23,27−29と,プライオリティノード91,94とを有する。すべてのノードは,自身のフレームで自身のアライブデータを送信する。そして,プライオリティノード91,94は他のノードの状態監視機能を有するが,それ以外のノードは他のノードの状態監視機能を有していない。
プライオリティノード91は,自身のグループG1内の他のノードと,自身のグループG1以外のグループ内のプライオリティノードを含むノードとについて,状態監視を行う。プライオリティノード94も同様に,自身のグループGn内の他のノードと,自身のグループGn以外のグループ内のプライオリティノードを含むノードとについて,状態監視を行う。ただし,プライオリティノードがすべての被状態監視ノードを監視することはなく,全体の一部の被状態監視ノードのみ監視することで,状態判定のリアルタイムにおこなう。
このようにすることで,被状態監視ノード21−23,27−29は,複数のプライオリティノードにより状態監視され,それらから復旧要求データを受信する。したがって,被状態監視ノードは,前述した規定数以上の復旧要求データを受信したか否かを判定し,必要な復旧処理を実行することができる。さらに,プライオリティノード91,92,94も,他のプライオリティノードにより状態監視され,規定数以上の復旧要求ノードを受信したか否かを判定し,必要な復旧処理を実行できる。
または別の構成としては,プライオリティノード91は,自身のグループG1内の他のノードと,自身のグループG1以外のグループのプライオリティノードとについて,状態監視を行い,自身のグループG1以下のグループの被状態監視ノードの状態監視は行わないようにしてもよい。この場合は,各グループ内の被状態監視ノード21−23は,1つのプライオリティノード91からしか状態監視されず,1つのプライオリティノード91からしか復旧要求データを受信しない。しかし,被状態監視ノード21−23は,1回の通信サイクルで受信した復旧要求データの数ではなく,一定の複数回の通信サイクルで受信した復旧要求データの数が規定値以上かいなかで復旧処理の有無を判定するようにすることで,復旧要求データの信頼性を担保することができる。また,プライオリティノード同士は,相互に状態監視を行うことが望ましい。
図7(B)には,タイムスロットSlotとそれに割り当てられた通信ノードとの関係が示されている。すべてのノードに対して,予めタイムスロットが割り当てられていて,各タイムスロットで対応するノードがフレームを送信する。このようにタイムスロットが割り当てられているので,すべてのノードが自身のフレームでアライブデータを送信する。そして,プライオリティノードだけが,他のノードに対して復旧要求データを自身のフレームで送信する。
図8は,プライオリティノード以外のノードの構成図である。図8のノードは,通信コントローラ70と,ネットワークドライバ72と,マイクロプロセッサ74とを有する。ただし,図5のノードの構成と異なり,通信コントローラ70は,通信制御マクロ710と,復旧制御ユニット720と,NMVアクセスユニット730と,復旧処理ユニット750とを有し,図5のアライブ情報管理ユニット740は有していない。つまり,他のノードの状態監視機能を有していない。それ以外は,図5のノードと同じである。
プライオリティノードの構成は,図5に示したノード構成と同じである。つまり,プライオリティノードの通信コントローラは,アライブ情報管理ユニット740により他のノードの状態を監視し,監視対象である他のノードのアライブデータが正常状態のパターンでないことを検出した場合に,そのノードに対して復旧要求データを自身のフレームに書き込んで送信する。また,プライオリティノードの通信コントローラは,必要に応じて,復旧処理レベルを判定して,復旧要求データとともに復旧処理レベルのデータも自身のフレームに書き込んで他のノードに送信する。
図9は,プライオリティノードの別の構成図である。このプライオリティノードは,通信コントローラ70とネットワークドライバ72とを有する。このプライオリティノードは,予め決められた状態監視対象のノードのスロットで送信されるフレームからアライブデータを抽出し,正常状態のパターンと一致しないことが検出された場合は,そのノードへの復旧要求データを自身のフレームに書き込んで送信することを主な機能とする。そのために,通信コントローラ70は,通信制御マクロ710とNMVアクセスユニット730とアライブ情報管理ユニット740を有する。通信コントローラ70は,図5のように復旧制御ユニットは有していない。また,マイクロプロセッサも設けられていない。
図9のプライオリティノードを有するネットワークにおいても,図8の場合と同様に,プライオリティノード以外の被状態監視ノードは,アライブデータのチェックと,復旧要求データの出力は行わない。
以上の実施の形態をまとめると,次の付記のとおりである。
(付記1)
複数のノードと共にネットワークに接続されるネットワークノードにおいて,
通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,
自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,他のノードから前記自身のノード宛の復旧要求データを,規定した数以上受信したときに,自身のノードに復旧動作を実行させる復旧制御手段とを有するネットワークノード。
(付記2)
付記1において,
前記復旧制御手段は,前記他のノードから受信した前記復旧要求データの数に応じて,複数の復旧動作のうち対応する復旧動作を実行させるネットワークノード。
(付記3)
付記2において,
前記複数の復旧動作は,通信コントローラのリコンフィギュレーション動作と,制御プロセッサのパワーオンリセット動作と,ネットワークドライバの遮断動作とを少なくとも有するネットワークノード。
(付記4)
付記1において,
さらに,他のノードが送信したフレーム内のアライブデータを前記他のノード別に記憶すると共に,前記アライブデータが規定の正常状態パターンと一致するか否かを判定し,不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークノード。
(付記5)
付記4において,
前記アライブデータ監視手段は,規定された複数の通信サイクルで受信した前記他のノードが送信したフレーム内のアライブデータを,前記規定の正常状態パターンと一致するか否かを判定するネットワークノード。
(付記6)
付記4または5において,
前記アライブデータ監視手段は,前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし,所定期間における当該不一致回数に応じて,復旧処理レベルデータを前記自身が送信するフレーム内に書き込むネットワークノード。
(付記7)
ネットワークと,
前記ネットワークに接続された複数のネットワークノードとを有し,
前記複数のネットワークノードは,第1及び第2のネットワークノードを有し,
前記第1のネットワークノードは,
通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,
自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第2のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,前記第2のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに,自身のノードに復旧動作を実行させる復旧制御手段とを有し,
前記第2のネットワークノードは,
前記フレーム送信手段と,
他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に,前記アライブデータが規定の正常状態パターンと一致するか否かを判定し,不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークシステム。
(付記8)
付記7において,
前記アライブデータ監視手段は,規定された複数の通信サイクルで受信した前記他のノードが送信したフレーム内のアライブデータを,前記規定の正常状態パターンと一致するか否かを判定するネットワークシステム。
(付記9)
付記7または8において,
前記アライブデータ監視手段は,前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし,所定期間における当該不一致回数に応じて,復旧レベルデータを前記自身が送信するフレーム内に書き込むネットワークシステム。
10:バス(ネットワーク) 72:ネットワークドライバ(バスドライバ)
70:通信コントローラ 74:マイクロプロセッサ
710:通信制御手段 720:復旧制御手段
740:アライブデータ管理手段,アライブ情報管理ユニット

Claims (5)

  1. 複数のノードと共にネットワークに接続されるネットワークノードにおいて,
    通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,
    自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,他のノードから前記自身のノード宛の復旧要求データを,規定した数以上受信したときに,前記他のノードから受信した前記復旧要求データの数に応じて,自身のノードに複数の復旧動作のうち対応する復旧動作を実行させる復旧制御手段とを有するネットワークノード。
  2. 複数のノードと共にネットワークに接続されるネットワークノードにおいて,
    通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,
    自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,他のノードから前記自身のノード宛の復旧要求データを,規定した数以上受信したときに,自身のノードに復旧動作を実行させる復旧制御手段と
    他のノードが送信したフレーム内のアライブデータを前記他のノード別に記憶すると共に,前記アライブデータが規定の正常状態パターンと一致するか否かを判定し,不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むと共に、前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし,所定期間における当該不一致回数に応じて,復旧処理レベルデータを前記自身が送信するフレーム内に書き込むアライブデータ監視手段とを有するネットワークノード。
  3. ネットワークと,
    前記ネットワークに接続された複数のネットワークノードとを有し,
    前記複数のネットワークノードは,第1及び第2のネットワークノードを有し,
    前記第1のネットワークノードは,
    通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,
    自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第2のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,前記第2のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに,前記他のノードから受信した前記復旧要求データの数に応じて,自身のノードに複数の復旧動作のうち対応する復旧動作を実行させる復旧制御手段とを有し,
    前記第2のネットワークノードは,
    前記フレーム送信手段と,
    他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に,前記アライブデータが規定の正常状態パターンと一致するか否かを判定し,不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークシステム。
  4. ネットワークと,
    前記ネットワークに接続された複数のネットワークノードとを有し,
    前記複数のネットワークノードは,第1及び第2のネットワークノードを有し,
    前記第1のネットワークノードは,
    通信サイクル毎に前記ネットワークに送信するフレームに,自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と,
    自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第2のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし,前記第2のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに,自身のノードに復旧動作を実行させる復旧制御手段とを有し,
    前記第2のネットワークノードは,
    前記フレーム送信手段と,
    他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に,前記アライブデータが規定の正常状態パターンと一致するか否かを判定し,不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むと共に、前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし,所定期間における当該不一致回数に応じて,復旧処理レベルデータを前記自身が送信するフレーム内に書き込むアライブデータ監視手段を有するネットワークシステム。
  5. 請求項3または4において,
    前記複数のネットワークノードは,第1,第2のグループに区分され,
    前記第2のネットワークノードは,前記第1,第2のグループ内の一部のネットワークノードであって,
    前記第1のグループ内の一部のネットワークノードを示す前記第2のネットワークノードに対応する前記第1のネットワークノードは,前記第1のグループ内の前記第2のネットワークノード以外のノードと前記第2のグループ内のネットワークノードとであって、前記第2のグループ内の一部のネットワークノードを示す前記第2のネットワークノードに対応する前記第1のネットワークノードは,前記第2のグループ内の前記第2のネットワークノード以外のノードと前記第1のグループ内のネットワークノードとであるネットワークシステム。
JP2009167253A 2009-07-15 2009-07-15 ネットワークノード Active JP5405927B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009167253A JP5405927B2 (ja) 2009-07-15 2009-07-15 ネットワークノード

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009167253A JP5405927B2 (ja) 2009-07-15 2009-07-15 ネットワークノード

Publications (2)

Publication Number Publication Date
JP2011023983A JP2011023983A (ja) 2011-02-03
JP5405927B2 true JP5405927B2 (ja) 2014-02-05

Family

ID=43633662

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009167253A Active JP5405927B2 (ja) 2009-07-15 2009-07-15 ネットワークノード

Country Status (1)

Country Link
JP (1) JP5405927B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011087509A1 (de) * 2011-12-01 2013-06-06 Robert Bosch Gmbh Sensorübertragungsvorrichtung und Verfahren zur Übertragung von Nutzdaten von einer Mehrzahl von Sensoren an eine Bussteuervorrichtung für ein Fahrzeug
JP6211842B2 (ja) * 2013-07-26 2017-10-11 Necプラットフォームズ株式会社 通信システム及び通信装置、並びにファームウェア稼動異常復旧制御方法
JP6237387B2 (ja) * 2014-03-25 2017-11-29 株式会社デンソー 電子制御システム及び電子装置
WO2020021713A1 (ja) * 2018-07-27 2020-01-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正検知方法および不正検知電子制御装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06325008A (ja) * 1993-03-17 1994-11-25 Hitachi Ltd リセット機能を備えるコンピュータシステム
JP2001223743A (ja) * 2000-02-08 2001-08-17 Canon Inc 遠隔復旧機能を有する通信装置および通信方法並びに記録媒体
JP2003087286A (ja) * 2001-09-10 2003-03-20 Mitsubishi Electric Corp スイッチングhub装置
JP3864747B2 (ja) * 2001-10-09 2007-01-10 株式会社デンソー 冗長系信号処理装置
JP4172461B2 (ja) * 2005-03-29 2008-10-29 トヨタ自動車株式会社 ノード診断システム
JP2007049297A (ja) * 2005-08-08 2007-02-22 Nissan Motor Co Ltd 通信システム及びその制御方法
JP5028003B2 (ja) * 2005-10-19 2012-09-19 パナソニック株式会社 電池パック、充電器、充電システムおよび充電異常検出方法
JP2008228105A (ja) * 2007-03-14 2008-09-25 Toshiba Corp 異常監視システム及び異常監視装置

Also Published As

Publication number Publication date
JP2011023983A (ja) 2011-02-03

Similar Documents

Publication Publication Date Title
JP5033199B2 (ja) 分散通信システムのノード、分散通信システムに結合されたノード及び監視装置
JP5337022B2 (ja) フォールト・トレランス・コンピューティング・システムにおけるエラー・フィルタリング
US9524222B2 (en) Method and apparatus for fault detection in a controller area network
US9009523B2 (en) Method and apparatus for isolating a fault in a controller area network
US20100229046A1 (en) Bus Guardian of a User of a Communication System, and a User of a Communication System
JP2011526110A (ja) 故障ノードの検出方法
JP2011131762A (ja) データ中継用制御装置および車両制御システム
JP5405927B2 (ja) ネットワークノード
WO2014039031A1 (en) Method and apparatus for isolating a fault in a controller area network
WO2008010141A1 (en) Distributed communication system and corresponding communication method
US10623166B2 (en) Systems and methods for improved uptime for network devices
US9952919B2 (en) Semantic deduplication
US20130336338A1 (en) Method For Operating A Network Arrangement, Network System And Network Arrangement
US20140298076A1 (en) Processing apparatus, recording medium storing processing program, and processing method
EP2680476B1 (en) Communications apparatus, system and method with error mitigation
US9499174B2 (en) Method and apparatus for isolating a fault-active controller in a controller area network
JP2007028118A (ja) ノード装置の故障判断方法
CN114296995B (zh) 一种服务器自主修复bmc的方法、系统、设备及存储介质
CN113993752A (zh) 电子控制单元和程序
JP2009110218A (ja) 仮想化スイッチおよびそれを用いたコンピュータシステム
JP6365876B2 (ja) ノード
JP4281602B2 (ja) 2重化コントローラシステム、そのコントローラ、プログラム
US20160321149A1 (en) Computer apparatus and computer mechanism
JP2021120827A5 (ja)
US20210029061A1 (en) A control apparatus, in-vehicle communication system, monitoring method and program

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120405

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130510

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130521

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130722

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20130822

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: 20131002

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131031

R150 Certificate of patent or registration of utility model

Ref document number: 5405927

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250