ネットワークノード
【課題】
信頼性の高い相互監視と復旧動作を可能にするネットワークノードを提供する。
【解決手段】
複数のノードと共にネットワークに接続されるネットワークノードにおいて，通信サイクル毎にネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んでフレームを送信する一方で、受信した他ノードのアライブ情報を判定し、送信元に対し、自身の送信フレームを介して復帰要求を送信する手段、また、他のノードから自身のノード宛の復旧要求データを，あらかじめ規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有する。
信頼性の高い相互監視と復旧動作を可能にするネットワークノードを提供する。
【解決手段】
複数のノードと共にネットワークに接続されるネットワークノードにおいて，通信サイクル毎にネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んでフレームを送信する一方で、受信した他ノードのアライブ情報を判定し、送信元に対し、自身の送信フレームを介して復帰要求を送信する手段、また、他のノードから自身のノード宛の復旧要求データを，あらかじめ規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，ネットワークノード及びそのネットワークシステムに関する。
【背景技術】
【０００２】
ネットワークのノードは，例えば，車載用ネットワークなどのネットワークに設けられた通信機能を有する電子制御装置である。各ノードは，所定の通信プロトコルにしたがって，データの送受信を行い、協調制御を行う。
【０００３】
車載用ネットワークとして，従来のＣＡＮ（Controller Area Network）やＬＩＮ(Local interconnect network)が運用されてきたが、ネットワークによる通信制御の多様化、大容量化により，新規プロトコルとしてFlexRayがすでに一部のシステムでは実運用されている。FlexRayは，X-by-Wireを実現するために有望視されている車載用ネットワークであり，よりきめ細かい制御を実現するためのリアルタイム性を有し，より高速かつ信頼性の高いネットワークである。
【０００４】
このような車載用ネットワークは，ネットワーク内に複数のノードが接続され，互いに通信を行っている。各ノードであるＥＣＵ（Electric Control Unit）は通信制御機能を有する通信コントローラとマイクロプロセッサとを有し，マイクロプロセッサはそれぞれ対応する被制御装置の制御を行う。たとえば，あるノードでエンジン制御操作を検出した場合，その操作データをネットワークを経由して他のノードに送信し，他のノードはその操作データに対応して被制御装置であるエンジンを制御する。
【０００５】
FlexRayの特徴は，ＣＡＮのようなイベントドリブン方式ではなく，タイムトリガ方式であることが知られている。タイムトリガ方式では，ある一定時間内（通信サイクル）に各ノードからデータを送信するタイミング（タイムスロット）が決まっている。このため，複数のノードがネットワークにつながっている場合でも，各送信ノードは確実に決まった周期でデータを送信することができ，ノード間で送信の衝突が生じないようになっているので，リアルタイム性を確保することができる。また，FlexRayは基本的には２チャネルで構成される仕様であり, 一方のチャネルが障害を起こしても他方のチャネルで信号を送信でき，ネットワーク障害に強く，確実なデータ送信が可能な高信頼性の通信方式である。
【０００６】
FlexRayについては，例えば，以下の非特許文献に記載されている。また，ネットワーク関連の技術については，例えば，以下の特許文献に記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−２５２２０８号公報
【特許文献２】特願平８−１９５７６７号公報
【非特許文献】
【０００８】
【非特許文献１】FlexRay Communications System Protocol Specification，Version 2.1 Revision A (22-December-2005)，http://www.flexray.com/index.php
【発明の概要】
【発明が解決しようとする課題】
【０００９】
各ノードであるＥＣＵ（Electric Control Unit）は，前述の通り，被制御装置を制御するマイクロプロセッサと，ネットワークの通信制御をおこなう通信コントローラとを有する。マまた、それらの障害対策としては一般的にウオッチドッグタイマーを利用したシステム暴走の監視/復旧が施される。ただし，その方法は，ソフトウェアの暴走によるマイクロコンピュータの重度障害を監視するのみであり, ネットワークの障害や通信コントローラの障害などの検出には対応できない。
【００１０】
FlexRayの仕様によれば，フレーム内のペイロード内にネットワークマネージメントベクタ（Network Management Vector: NMV）を設けることができる。このＮＭＶを利用し、各ノードが正常に動作していることを示すアライブデータを書き込んで，他のノードに自身の正常状態を通知するECUの相互監視を行うことができ，ネットワーク内の複数のノードは，互いに正常動作しているか否かを相互に監視することができる。
【００１１】
しかし，ＮＭＶによる相互監視方式では，そのフレームを送信したノードに障害があるのか，受信したノードに障害があるのかまでは特定することはできない。そのため，信頼性の高い相互監視とそれに対応した復旧動作を担保することができない。
【００１２】
そこで，本発明の目的は，信頼性の高い相互監視と復旧動作を可能にするネットワークノードとそのネットワークシステムを提供することにある。
【課題を解決するための手段】
【００１３】
ネットワークノードの第１の側面は，複数のノードと共にネットワークに接続されるネットワークノードにおいて，通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，他のノードから前記自身のノード宛の復旧要求データを，規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有する。
【発明の効果】
【００１４】
第１の側面によれば，信頼性の高い障害復旧動作をさせることができる。
【図面の簡単な説明】
【００１５】
【図１】本実施の形態におけるネットワークの構成図である。
【図２】本実施の形態における被状態監視ノードと状態監視ノードとの関係を示す図である。
【図３】本実施の形態におけるネットワークの通信スケジュールを示す図である。
【図４】本実施の形態におけるフレームの構成図である。
【図５】本実施の形態におけるネットワークノードの構成図である。
【図６】アライブデータの例について示す図である。
【図７】プライオリティノードを有するネットワークとタイムスロットとを示す図である。
【図８】プライオリティノード以外のノードの構成図である。
【図９】プライオリティノードの構成図である。
【発明を実施するための形態】
【００１６】
以下，本実施の形態を図面を参照して説明する。
【００１７】
図１は，本実施の形態におけるネットワークの構成図である。このネットワークは，ネットワークであるバス１０に，複数のノード２１〜２４が接続されている。各ノード２１〜２４は，自身に割り当てられたタイムスロットでフレームをバス１０に送信する。また，各ノード２１〜２４は，それぞれアクチュエータなどの被制御デバイスやセンサなどの被監視デバイスに接続され，被制御デバイスへの制御や被監視デバイスからの状態検出などを行う。そして，それらに応答して必要なコマンドや検出データなどをネットワークを介して他のノードに転送する。
【００１８】
以下，本実施の形態のネットワークは，FlexRayを具体例にして説明されるが，必ずしもFlexRayに限定されるものではなく，フレームを互いに転送しあう複数のノードが接続されたネットワークに適用可能である。
【００１９】
前述のとおり，各ノード２１〜２４は，タイムトリガ方式で自身に割り当てられたタイムスロットで自身のフレームをバス１０に送信する。そして，各ノード内の通信コントローラは，どのタイムスロットのフレームを受信すべきかをコンフィギュレーションデータにより設定されており，その設定値に対応して，バス上のフレームを受信する。タイムトリガ方式の場合は，通信サイクルで必ず自身のフレームを送信することができるので，リアルタイム性を確保することができ，走行制御系の車載ネットワークとして適している。
【００２０】
図２は，本実施の形態における被状態監視ノードと状態監視ノードとの関係を示す図である。この図では，ノード２０Ａが被状態監視ノードであり，ノード２０Ｘが状態監視ノードである。被状態監視ノード２０Ａは，自身が送信するフレーム内に正常状態を示すアライブデータ（アライブ情報）を毎回書き込んでネットワーク上に送信する。それに対して，状態監視ノード２０Ｘは，被状態監視ノード２０Ａから送信されるフレームを受信し，その中のアライブデータを判定し，被状態監視ノード２０Ａが正常動作状態か否かを判定する。この判定は，受信したアライブデータがあらかじめ規定されている正常状態のパターンと一致するか否かで行われる。そして，不一致の場合は，状態監視ノード２０Ｘは，自身が送信するフレーム内にその被状態監視ノード２０Ａ宛の復旧要求データを書き込んでネットワーク上に送信する。
【００２１】
被状態監視ノード２０Ａは，状態監視ノード２０Ｘから送信されるフレームを受信し，そのフレーム内に自身宛の復旧要求データを検出したら，自身のノード内のネットワークドライバ（バスドライバ），通信コントローラ，マイクロプロセッサに対して復旧動作を実行させる。
【００２２】
本実施の形態では，復旧要求の信頼性を担保するために，被状態監視ノード２０Ａは，複数の状態監視ノード２０Ｘから送信されるフレーム内に自身への復旧要求データが含まれているか否かをチェックし，規定数以上の復旧要求データを受信した場合に，自身の復旧動作を実行する。
【００２３】
その理由は，状態監視ノード２０Ｘによるアライブデータの判定でアライブデータが規定されている正常状態パターンと一致しない場合，必ずしも被状態監視ノード２０Ａに何らかの障害が発生して正常状態をあらわすアライブデータを書き込むことができなかったとは限らない。例えば，状態監視ノード２０Ｘの通信コントローラの異常状態によってそのような不一致が発生する場合も考えられるし，ネットワークそのものの不具合により不一致が発生する場合も考えられる。
【００２４】
そこで，本実施の形態では，被状態監視ノード２０Ａは，複数の状態監視ノード２０Ｘから規定数以上（例えば全状態監視ノード数の過半数以上）の復旧要求データを受信した場合に，復旧動作を実行する。さらに，別の実施の形態では，被状態監視ノード２０Ａは，復旧要求データの数に応じて，実行する復旧動作を選択する。さらに，別の実施の形態では，状態監視ノード２０Ｘは，被状態監視ノード２０Ａ毎にアライブデータの判定結果をカウントし，比較的長い期間で検出された不一致の回数に応じて，復旧処理レベルを決定し，復旧要求データと共に復旧処理レベルの情報もフレームに書き込んで，被状態監視ノード２０Ａにネットワーク経由で送信する。被状態監視ノード２０Ａは，その復旧処理レベルに対応した復旧処理を実行する。
【００２５】
図３は，本実施の形態におけるネットワークの通信スケジュールを示す図である。本ネットワークにおける通信は，たとえば，予め決められたスケジュールに沿ってフレームデータの送受信を行う。すなわち，タイムトリガ型である。通信スケジュールは，図３に示されるとおり，０〜６３を繰り返しカウントする通信サイクル３０と，１つの通信サイクル内でフレーム送信のスケジューリングを管理するセグメント３２，３４と，スロットＳＬ１〜ＳＬ４とで構成される。
【００２６】
１つの通信サイクルは，スタティックセグメント３２と，ダイナミックセグメント３４と，アイドル時間３６とで構成される。そして，スタティックセグメント３２では，タイムトリガ方式により各ノードが送信を行う期間であり，予め決められた長さのフレームＦＬ１〜ＦＬ４がスケジュールに沿って送信される。図１のすべてのノードに同じ長さのスロットＳＬ１〜ＳＬ４が割り当てられていて，各スロットで各フレームのフレームＦＬ１〜ＦＬ４がネットワークのチャネル上に送信される。したがって，１回の通信サイクルを経過すると，すべてのノードのフレームがバス上に送信されたことになる。
【００２７】
ダイナミックセグメント３４では，任意のタイミングでフレームを送信するイベントドリブン方式により送信が行われる期間であり，図示しないが，送信データは可変長である。また，アイドル時間３６中に，全ノード間で同期をとることが行われる。このように，タイムトリガ方式により１回の通信サイクル内で全ノードが確実に送信することができ，リアルタイム性と高信頼性とを実現するとともに，イベントドリブン方式のダイナミックセグメントも持たせている。本実施の形態では，上記のダイナミックセグメントは必ずしも必要ではない。
【００２８】
図４は，本実施の形態におけるフレームの構成図である。フレームＦＬは，ヘッダ４０と，ペイロード４１と，トレーラー４２とで構成される。ヘッダ４０内には，同期ビット，フレームＩＤなどに加えて，どの通信サイクルかを示すサイクルカウンタの情報も含まれる。ペイロード４１には，ネットワーク管理ベクタ（ＮＭＶ）５０と，ペイロードデータ５１とが含まれる。そして，トレーラー４２には，フレームの誤り訂正コードＣＲＣが含まれる。
【００２９】
上記のＮＭＶ５０は，そのＮＭＶフォーマット６０に示されるとおり，各ノード２１〜２４で書き込まれるノードの正常状態を示すアライブデータ領域（図中Alive for #）と，状態監視ノードで書き込まれる各ノード２１〜２４宛の復旧要求データ領域（図中Reset for #）とを，各ノードそれぞれに対応して有する。したがって，フォーマット６０は４対の領域を有する。ＮＭＶ５０は，すべてのスロットのフレームで同じデータ長を有する。
【００３０】
今仮に，ノードNode1が自身のフレームをネットワーク上に送信し，他のノードのフレームをネットワーク上から受信する場合を想定して説明する。ノードNode1は，自身が送信するフレーム６１に，自身の状態が正常であることを示すアライブデータを「Alive for 1」に書き込み，他のノードに対する復旧要求データ「Reset for 2」「Reset for 3」「Reset for 4」を必要に応じて書き込む。
【００３１】
さらに，ノードNode１は，ノードNode2のタイムスロットのフレーム６２を受信する。このフレーム６２には，ノードNode1宛の復旧要求データ「Reset for 1」と，ノードNode2のアライブデータ「Alive for 2」と，ノードNode4, Node5宛の復旧要求データ「Reset for 4」「Reset for 5」が含まれる。同様に，ノードNode１は，ノードNode3のタイムスロットのフレーム６３と，ノードNode4のタイムスロットのフレーム６４も受信する。これらのフレーム６３，６４もフレーム６２と同様である。
【００３２】
図４の例では，ノードNode1は，フレーム６２，６３，６４で，ノードNode2,3,4すべてから復旧要求データ「Reset for 1」を受信している。また，すべてのフレームで，他のすべてのノード宛の復旧要求データが書き込まれている。この復旧要求データは，後述するアルゴリズムで，各ノードの通信コントローラによりフレームに書き込まれる。
【００３３】
上記のように，各ノードがそれぞれのスロットで送信するフレーム内に，自身の正常状態を示すアライブデータを書き込むことで，各ノードがノードの動作状態を相互監視することができる。もしノードに障害が発生しノードが正常状態でなければ，正常状態を示すアライブデータを書き込むことができないからである。さらに，各ノードは，他のノードの動作状態を相互に監視し，正常状態でないことを検出したら，そのノード宛の復旧要求データを自身のフレームに書き込む。そして，各ノードは他のノードのフレームをチェックして，自身宛の復旧要求データが出されたか否かを確認する。
【００３４】
図５は，本実施の形態におけるネットワークノードの構成図である。各ノードは，通信コントローラ７０と，ネットワークのバス１０にフレームを出力して送信し，他のノードが出力したバス１０上のフレームを受信して入力するネットワークドライバ（バスドライバ）７２と，図示しない通信コントローラの制御を行うマイクロプロセッサ７４とを有する。通信コントローラ７０とネットワークドライバ７２は，ハードウエアで構成される。通信コントローラ７０は，マイクロプロセッサ７４内にハードウエアマクロとして埋め込まれても良い。
【００３５】
通信コントローラ７０は，ネットワークドライバ７２と接続される通信制御マクロ７１０と，通信制御マクロ７１内のＮＭＶレジスタ７１２へのアクセスを行うＮＭＶアクセスユニット７３０と，他のノードからの復旧要求データに基づいて自身の復旧処理を判定する復旧制御ユニット７２０と，判定された復旧処理を行う復旧処理ユニット７５０と，他のノードのアライブデータを判定して必要に応じて他のノード宛の復旧要求データを自身のフレームに書き込むアライブ情報管理ユニット７４０とを有する。
【００３６】
まず，ノードが自身のフレームを送信する場合は，マイクロプロセッサ７４がフレーム内のデータを生成し，通信制御マクロ７１０内のメッセージバッファ７１１内に書き込む。フレームのヘッダ４０とトレーラー４２のデータは，通信制御マクロ７１０により生成されるが，ペイロード４１のペイロードデータ５１は，マイクロプロセッサ７４が生成する。
【００３７】
ＮＭＶのデータ５０は，図４のＮＭＶフォーマット６０にあるとおり，自身のアライブデータと，他のノード宛の復旧要求データとを有する。自身のアライブデータは，マイクロプロセッサ７４が通信サイクル毎に生成しメッセージバッファ７１１に書き込む。このアライブデータは，自身のノードが正常状態であることを示すビットであり，通信サイクル毎に変更することが決められたビット構成であってもよく，または，通信サイクルにかかわらず常に同じビット構成であってもよい。また，他のノード宛の復旧要求データは，アライブ情報管理ユニット７４０内の復旧要求発生器７４５が生成しメッセージバッファ７１１に書き込む。
【００３８】
通信制御マクロ７１０は，ネットワークドライバ７２が受信したフレームに含まれるメッセージと，ネットワークドライバ７２から出力するフレームに含まれるメッセージとを一次的に格納するメッセージバッファ７１１と，受信したフレームから抽出されたＮＭＶのデータを格納するＮＭＶレジスタ７１２と，受信したフレームから抽出されたサイクルカウンタのデータを格納して現在の通信サイクルの確認に使用される通信サイクルカウンタ７１３とを有する。
【００３９】
ＮＭＶアクセスユニット７３０は，ＮＭＶレジスタ７１２にアクセスして，ＮＭＶレジスタ内の自身宛の復旧要求データを復旧要求バッファ７２１に，他のノードのアライブデータをアライブデータバッファ７４１にそれぞれ格納する。
【００４０】
通信制御マクロ７１０は，初期化時に通信のコンフィギュレーションデータを設定されることで，所望の通信制御を実行する。このコンフィギュレーションデータには，どのタイムスロットのフレームを受信すべきかなどの情報が含まれていて，マイクロプロセッサによりインストールされる。
【００４１】
［復旧制御ユニット］
復旧制御ユニット７２０では，復旧要求判定器７２２は，復旧要求バッファ７２１に格納された他のノードからの復旧要求データの欄をチェックして，他のノードから自身宛の復旧要求データを受信したか否かを判定する。他のノードからの復旧要求データの欄とは，図４のフレーム６２，６３，６４の「Reset for 1」の欄であり，ここに自身宛の復旧要求データが書き込まれているか否かが判定される。そして，復旧要求カウンタ７２３は，他のノードからの自身宛の復旧要求データの数をカウントする。
【００４２】
そして，復旧処理判定器７２５は，例えば，１回の通信サイクル中の復旧要求カウンタ７２３のカウント数が，規定された値以上であれば，復旧処理すべきと判定し，復旧処理ユニット７５０に復旧処理要求を出力する。図１の例では，他のノードであるノード２２，２３，２４のうち，過半数の２以上のノードから復旧要求データを受信している場合に，その復旧要求データが高い信頼性を有していると考えられるので，復旧処理判定器７２５は，復旧処理要求を出力する。つまり，規定数，例えば過半数，の状態監視ノードから自身宛の復旧要求データを受信している場合に復旧処理が必要と判定することで，自身のノード以外の何らかの障害により正常状態を示すアライブデータが受信されないなどで他のノードから自身宛に復旧要求データを受信していた場合に，無駄に復旧処理を実行することを回避することができる。
【００４３】
復旧処理ユニット７５０は，復旧要求に応答して，（１）マイクロプロセッサ７４による自己診断処理，（２）通信コントローラ７０のリコンフィギュレーション処理，（３）マイクロプロセッサ７４によるリセット処理，（４）ネットワークドライバ７２の入出力遮断処理のうちいずれかを実行する。復旧処理（１）は，マイクロプロセッサ７４が，自己診断プログラムを実行して，ソフトウエア障害等に対する必要な復旧処理を行う処理であり，最も軽度の障害レベルのときに実行される。復旧処理（２）は，マイクロプロセッサ７４による通信コントローラ７０の初期化に対応し，コンフィギュレーションデータの再設定により，通信コントローラ７０による障害発生を抑制することができる。リコンフィギュレーションは，マイクロプロセッサ７４が生成したコンフィギュレーションデータを，主に通信制御マクロ７１０に設定する処理であるが，他のユニットに設定されても良い。
【００４４】
復旧処理（３）はマイクロプロセッサのパワーオンリセットなどに対応する処理であり，主にプログラムの暴走に伴う障害から復旧することができる。そして，復旧処理（４）は，ネットワークドライバ７２の入出力端子を遮断する処理であり，最も重度の障害レベルが発生したときの応急処理である。
【００４５】
上記の復旧処理（１）〜（３）の命令が復旧処理ユニット７５０によりマイクロプロセッサ７４に発行されると，マイクロプロセッサ７４は復旧処理中を示すモード信号を復旧処理ユニット７５０に返信する。それに応答して，復旧処理中を示すモード信号が他のノード宛のフレームに書き込まれて送信される。これにより，他のノードは，復旧処理中であることを認識することができる。
【００４６】
これら４つの復旧処理（１）〜（４）は，障害のレベルが低い順に実行されるべき処理に対応している。復旧処理判定器７２５は，いずれの復旧処理を実行すべきかを，たとえば，復旧要求カウンタ７２３のカウンタ値に応じて判定する。つまり，１回の通信サイクル中に受信した他の状態監視ノードからの復旧要求データの数に応じて，数が少なければ復旧処理（１）を判定し，数が多くなれば復旧処理（２）〜（３）を判定する。復旧処理（３）は，最も重度の障害発生時の処理であり，ネットワークドライバの遮断は，必ずしも復旧処理とは言えないが，それ以上の障害発生を抑制する処理といえる。
【００４７】
または，別の判定方法として，複数の通信サイクルを含む一定期間内に復旧処理が繰り返されるたびにその復旧処理のレベルを上げているようにしてもよい。
【００４８】
復旧処理レベルカウンタ７２４は，他の状態監視ノードから復旧要求データに加えて復旧処理レベルのデータを受信する場合に，復旧処理レベル別にその回数をカウントする。上記の例では，復旧処理（１）〜（４）別にその回数をカウントする。その場合は，復旧処理判定器７２５は，カウント数が最も多い復旧処理を選択して，復旧要求を復旧処理ユニット７５０に出力する。他の状態監視ノードによる復旧処理レベルの選定については後述する。
【００４９】
なお，復旧要求データと復旧処理レベルのデータは，送信側のノードで暗号化され，受信側のノードで復号化されることが好ましい。このようにすることで，復旧処理の起点となる受信データの信頼性を向上させて，不必要な復旧処理が行われることを抑制することができる。
【００５０】
［アライブ情報管理ユニット］
アライブ情報管理ユニットを有するノードは，状態監視ノードとしての機能を有する。
【００５１】
アライブ情報管理ユニット７４０では，状態判定器７４２が，アライブデータバッファ７４１に他のノード別に格納されている他のノードのアライブデータを正常状態を示す規定パターンと比較して，他のノードの動作状態を判定する。状態判定器７４２は，他のノードのアライブデータが正常状態の規定パターンと異なっている場合は，復旧要求発生器７４５にその結果を通知する。それに応答して，復旧要求発生器７４５は，メッセージバッファ７１１内の自身のフレームのＮＭＶ５０の欄に，他のノード宛の復旧要求データを書き込む。
【００５２】
そして，他のノードは，この復旧要求データが書き込まれたフレームを受信し，その復旧要求データに対応して必要な復旧処理を実行する。この復旧処理については，上記の復旧制御ユニット７２０のところで説明済みである。
【００５３】
アライブ情報管理ユニット７４０は，一定の長い期間においてアライブデータ判定で検出した異常状態の回数を他のノード別にカウントし，そのカウント値に応じて最適な復旧処理レベルを判定し，他のノードに復旧要求データとともに復旧処理レベルのデータも送信する。つまり，アライブデータが正常状態以外のパターンの場合は，被状態監視ノードが正常に動作していない可能性があるので，復旧要求発生器７４５がその被状態監視ノードに対して復旧要求データを送信し，復旧処理を行わせている。しかし，比較的長い期間において，前記復旧要求データの送信にもかかわらず，アライブデータが正常状態以外のパターンを示す場合は，アライブ情報管理ユニット７４０がその回数に応じて徐々に復旧処理レベルを上げるようにすることで，被状態監視ノードに適切な復旧処理を行わせることができる。
【００５４】
そのために，異常状態カウンタ７４３は，被状態監視ノード別に異常状態をカウントする。そして，復旧処理レベル判定器７４４は，そのカウント値に応じて，被状態監視ノードに対する復旧処理レベルを判定する。判定された復旧処理レベルは復旧要求発生器７４５に供給され，復旧処理要求発生器７４５は，その復旧処理レベルを，メッセージバッファ７１１内の自身が送信するフレーム内のＮＭＶの欄に書き込む。
【００５５】
そして，通信制御マクロ７１０は，自身のノードに割り当てられたタイムスロットでメッセージバッファ７１１に書き込まれたフレームをネットワークドライバ７２を介してバス１０に出力する。
【００５６】
図６は，アライブデータの例について示す図である。上記の説明では，アライブ情報管理ユニット７４０内の状態判定器７４２は，他の被状態監視ノードからのアライブデータを受信するたびに，そのアライブデータが正常状態を示すパターンと一致するか否かを判定した。FlexRay通信には，送信モードにコンティニュアスモードがあり，そのモードでは，各マイクロプロセッサが送信するデータを更新しなくても、通信コントローラが前回の送信データをそのまま送信することが可能である。かかるモードの場合，ノードに何らかの異常が発生して、アライブデータが更新されなくても前回の送信データにて正常状態を示すアライブデータが送信されている場合は，正常を示すアライブデータが送信される為、状態監視ノードは受信したアライブデータから被状態監視ノードの異常状態を検出することができない。
【００５７】
そこで，複数回の通信サイクルで受信したアライブデータを合成したデータを，正常状態を示すパターンと比較することが望ましい。そして，被状態監視ノードは，通信サイクル毎に異なるアライブデータをＮＭＶデータとして送信し，複数回の通信サイクルで１つのアライブデータ長８０のアライブデータを送信することが求められる。たとえば，各通信サイクルで送信される正常状態を示すアライブデータは，通信サイクル毎にビット反転されるようにしても良い。
【００５８】
図６において，サイクルＮでは，受信したＮＭＶデータ内のノードＸのアライブデータ８２が，アライブデータバッファ７４１の最下位ビットに格納される。さらに，次のサイクルＮ＋１では，受信したＮＭＶデータ内のノードＸのアライブデータ８４が，アライブデータバッファ７４１の最下位ビットに格納される。このとき，既に格納されていたサイクルＮでのアライブデータ８２は上位側にシフトされる。
【００５９】
そして，状態判定器７４２は，各通信サイクルで，１つのアライブデータ長８０のアライブデータを正常状態のパターンと比較判定する。ただし，Ｍ回の通信サイクルで１つのアライブデータ長のデータを送信できる場合は，Ｍ回に１回だけアライブデータが正常状態のパターンと一致することが検出される。したがって，Ｍ回の比較判定で１回も一致しなければ，何らかの障害が発生していると判定される。
【００６０】
または，通信サイクルカウンタの値に応じて，正常状態のパターンを適宜選択するようにしてもよい。その場合は，直近のＭ回のアライブデータがすべて正常状態であったか否かを，各通信サイクル毎に判定することができる。いずれの方法でも，複数の通信サイクルで生成されたアライブデータをチェックすることで，上記のコンティニュアスモードにも対応可能である。
【００６１】
［プライオリティノード］
図５に示したネットワークノードの通信コントローラ７０は，他のノードの状態監視をするアライブ情報管理ユニット７４０を有する。ただし，すべてのノードに他のノードの状態監視機能を持たせると，ネットワーク全体のコストアップになる。さらに，すべてのノードが他のノード宛の復旧要求データを送信するので，ノードによる復旧処理の必要性の検出は，すべてのノードのタイムスロットが経過した後になり，復旧処理に至るまでのレスポンス性が悪くなる。
【００６２】
そこで，ネットワーク内の全ノードのうち一部のノードをプライオリティノードとして，そのプライオリティノードにだけ他のノードの状態監視をするアライブ情報管理ユニット７４０を設ける。そして，プライオリティノードは，一部の被状態監視ノードについて状態監視を行うが，プライオリティノード以外のノードは，他のノードの状態監視は行わない。
【００６３】
図７は，プライオリティノードを有するネットワークとタイムスロットとを示す図である。ネットワークのバスに接続されたノードは，複数のグループＧ１，Ｇｎに分けられ，各グループ内には，図７の例では，３つのノード２１−２３，２７−２９と，プライオリティノード９１，９４とを有する。すべてのノードは，自身のフレームで自身のアライブデータを送信する。そして，プライオリティノード９１，９４は他のノードの状態監視機能を有するが，それ以外のノードは他のノードの状態監視機能を有していない。
【００６４】
プライオリティノード９１は，自身のグループＧ１内の他のノードと，自身のグループＧ１以外のグループ内のプライオリティノードを含むノードとについて，状態監視を行う。プライオリティノード９４も同様に，自身のグループＧｎ内の他のノードと，自身のグループＧｎ以外のグループ内のプライオリティノードを含むノードとについて，状態監視を行う。ただし，プライオリティノードがすべての被状態監視ノードを監視することはなく，全体の一部の被状態監視ノードのみ監視することで，状態判定のリアルタイムにおこなう。
【００６５】
このようにすることで，被状態監視ノード２１−２３，２７−２９は，複数のプライオリティノードにより状態監視され，それらから復旧要求データを受信する。したがって，被状態監視ノードは，前述した規定数以上の復旧要求データを受信したか否かを判定し，必要な復旧処理を実行することができる。さらに，プライオリティノード９１，９２，９４も，他のプライオリティノードにより状態監視され，規定数以上の復旧要求ノードを受信したか否かを判定し，必要な復旧処理を実行できる。
【００６６】
または別の構成としては，プライオリティノード９１は，自身のグループＧ１内の他のノードと，自身のグループＧ１以外のグループのプライオリティノードとについて，状態監視を行い，自身のグループＧ１以下のグループの被状態監視ノードの状態監視は行わないようにしてもよい。この場合は，各グループ内の被状態監視ノード２１−２３は，１つのプライオリティノード９１からしか状態監視されず，１つのプライオリティノード９１からしか復旧要求データを受信しない。しかし，被状態監視ノード２１−２３は，１回の通信サイクルで受信した復旧要求データの数ではなく，一定の複数回の通信サイクルで受信した復旧要求データの数が規定値以上かいなかで復旧処理の有無を判定するようにすることで，復旧要求データの信頼性を担保することができる。また，プライオリティノード同士は，相互に状態監視を行うことが望ましい。
【００６７】
図７（Ｂ）には，タイムスロットＳｌｏｔとそれに割り当てられた通信ノードとの関係が示されている。すべてのノードに対して，予めタイムスロットが割り当てられていて，各タイムスロットで対応するノードがフレームを送信する。このようにタイムスロットが割り当てられているので，すべてのノードが自身のフレームでアライブデータを送信する。そして，プライオリティノードだけが，他のノードに対して復旧要求データを自身のフレームで送信する。
【００６８】
図８は，プライオリティノード以外のノードの構成図である。図８のノードは，通信コントローラ７０と，ネットワークドライバ７２と，マイクロプロセッサ７４とを有する。ただし，図５のノードの構成と異なり，通信コントローラ７０は，通信制御マクロ７１０と，復旧制御ユニット７２０と，ＮＭＶアクセスユニット７３０と，復旧処理ユニット７５０とを有し，図５のアライブ情報管理ユニット７４０は有していない。つまり，他のノードの状態監視機能を有していない。それ以外は，図５のノードと同じである。
【００６９】
プライオリティノードの構成は，図５に示したノード構成と同じである。つまり，プライオリティノードの通信コントローラは，アライブ情報管理ユニット７４０により他のノードの状態を監視し，監視対象である他のノードのアライブデータが正常状態のパターンでないことを検出した場合に，そのノードに対して復旧要求データを自身のフレームに書き込んで送信する。また，プライオリティノードの通信コントローラは，必要に応じて，復旧処理レベルを判定して，復旧要求データとともに復旧処理レベルのデータも自身のフレームに書き込んで他のノードに送信する。
【００７０】
図９は，プライオリティノードの別の構成図である。このプライオリティノードは，通信コントローラ７０とネットワークドライバ７２とを有する。このプライオリティノードは，予め決められた状態監視対象のノードのスロットで送信されるフレームからアライブデータを抽出し，正常状態のパターンと一致しないことが検出された場合は，そのノードへの復旧要求データを自身のフレームに書き込んで送信することを主な機能とする。そのために，通信コントローラ７０は，通信制御マクロ７１０とＮＭＶアクセスユニット７３０とアライブ情報管理ユニット７４０を有する。通信コントローラ７０は，図５のように復旧制御ユニットは有していない。また，マイクロプロセッサも設けられていない。
【００７１】
図９のプライオリティノードを有するネットワークにおいても，図８の場合と同様に，プライオリティノード以外の被状態監視ノードは，アライブデータのチェックと，復旧要求データの出力は行わない。
【００７２】
以上の実施の形態をまとめると，次の付記のとおりである。
【００７３】
（付記１）
複数のノードと共にネットワークに接続されるネットワークノードにおいて，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，他のノードから前記自身のノード宛の復旧要求データを，規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有するネットワークノード。
【００７４】
（付記２）
付記１において，
前記復旧制御手段は，前記他のノードから受信した前記復旧要求データの数に応じて，複数の復旧動作のうち対応する復旧動作を実行させるネットワークノード。
【００７５】
（付記３）
付記２において，
前記複数の復旧動作は，通信コントローラのリコンフィギュレーション動作と，制御プロセッサのパワーオンリセット動作と，ネットワークドライバの遮断動作とを少なくとも有するネットワークノード。
【００７６】
（付記４）
付記１において，
さらに，他のノードが送信したフレーム内のアライブデータを前記他のノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークノード。
【００７７】
（付記５）
付記４において，
前記アライブデータ監視手段は，規定された複数の通信サイクルで受信した前記他のノードが送信したフレーム内のアライブデータを，前記規定の正常状態パターンと一致するか否かを判定するネットワークノード。
【００７８】
（付記６）
付記４または５において，
前記アライブデータ監視手段は，前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし，所定期間における当該不一致回数に応じて，復旧処理レベルデータを前記自身が送信するフレーム内に書き込むネットワークノード。
【００７９】
（付記７）
ネットワークと，
前記ネットワークに接続された複数のネットワークノードとを有し，
前記複数のネットワークノードは，第１及び第２のネットワークノードを有し，
前記第１のネットワークノードは，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第２のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，前記第２のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有し，
前記第２のネットワークノードは，
前記フレーム送信手段と，
他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークシステム。
【００８０】
（付記８）
付記７において，
前記アライブデータ監視手段は，規定された複数の通信サイクルで受信した前記他のノードが送信したフレーム内のアライブデータを，前記規定の正常状態パターンと一致するか否かを判定するネットワークシステム。
【００８１】
（付記９）
付記７または８において，
前記アライブデータ監視手段は，前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし，所定期間における当該不一致回数に応じて，復旧レベルデータを前記自身が送信するフレーム内に書き込むネットワークシステム。
【符号の説明】
【００８２】
１０：バス（ネットワーク） ７２：ネットワークドライバ（バスドライバ）
７０：通信コントローラ ７４：マイクロプロセッサ
７１０：通信制御手段 ７２０：復旧制御手段
７４０：アライブデータ管理手段，アライブ情報管理ユニット
【技術分野】
【０００１】
本発明は，ネットワークノード及びそのネットワークシステムに関する。
【背景技術】
【０００２】
ネットワークのノードは，例えば，車載用ネットワークなどのネットワークに設けられた通信機能を有する電子制御装置である。各ノードは，所定の通信プロトコルにしたがって，データの送受信を行い、協調制御を行う。
【０００３】
車載用ネットワークとして，従来のＣＡＮ（Controller Area Network）やＬＩＮ(Local interconnect network)が運用されてきたが、ネットワークによる通信制御の多様化、大容量化により，新規プロトコルとしてFlexRayがすでに一部のシステムでは実運用されている。FlexRayは，X-by-Wireを実現するために有望視されている車載用ネットワークであり，よりきめ細かい制御を実現するためのリアルタイム性を有し，より高速かつ信頼性の高いネットワークである。
【０００４】
このような車載用ネットワークは，ネットワーク内に複数のノードが接続され，互いに通信を行っている。各ノードであるＥＣＵ（Electric Control Unit）は通信制御機能を有する通信コントローラとマイクロプロセッサとを有し，マイクロプロセッサはそれぞれ対応する被制御装置の制御を行う。たとえば，あるノードでエンジン制御操作を検出した場合，その操作データをネットワークを経由して他のノードに送信し，他のノードはその操作データに対応して被制御装置であるエンジンを制御する。
【０００５】
FlexRayの特徴は，ＣＡＮのようなイベントドリブン方式ではなく，タイムトリガ方式であることが知られている。タイムトリガ方式では，ある一定時間内（通信サイクル）に各ノードからデータを送信するタイミング（タイムスロット）が決まっている。このため，複数のノードがネットワークにつながっている場合でも，各送信ノードは確実に決まった周期でデータを送信することができ，ノード間で送信の衝突が生じないようになっているので，リアルタイム性を確保することができる。また，FlexRayは基本的には２チャネルで構成される仕様であり, 一方のチャネルが障害を起こしても他方のチャネルで信号を送信でき，ネットワーク障害に強く，確実なデータ送信が可能な高信頼性の通信方式である。
【０００６】
FlexRayについては，例えば，以下の非特許文献に記載されている。また，ネットワーク関連の技術については，例えば，以下の特許文献に記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−２５２２０８号公報
【特許文献２】特願平８−１９５７６７号公報
【非特許文献】
【０００８】
【非特許文献１】FlexRay Communications System Protocol Specification，Version 2.1 Revision A (22-December-2005)，http://www.flexray.com/index.php
【発明の概要】
【発明が解決しようとする課題】
【０００９】
各ノードであるＥＣＵ（Electric Control Unit）は，前述の通り，被制御装置を制御するマイクロプロセッサと，ネットワークの通信制御をおこなう通信コントローラとを有する。マまた、それらの障害対策としては一般的にウオッチドッグタイマーを利用したシステム暴走の監視/復旧が施される。ただし，その方法は，ソフトウェアの暴走によるマイクロコンピュータの重度障害を監視するのみであり, ネットワークの障害や通信コントローラの障害などの検出には対応できない。
【００１０】
FlexRayの仕様によれば，フレーム内のペイロード内にネットワークマネージメントベクタ（Network Management Vector: NMV）を設けることができる。このＮＭＶを利用し、各ノードが正常に動作していることを示すアライブデータを書き込んで，他のノードに自身の正常状態を通知するECUの相互監視を行うことができ，ネットワーク内の複数のノードは，互いに正常動作しているか否かを相互に監視することができる。
【００１１】
しかし，ＮＭＶによる相互監視方式では，そのフレームを送信したノードに障害があるのか，受信したノードに障害があるのかまでは特定することはできない。そのため，信頼性の高い相互監視とそれに対応した復旧動作を担保することができない。
【００１２】
そこで，本発明の目的は，信頼性の高い相互監視と復旧動作を可能にするネットワークノードとそのネットワークシステムを提供することにある。
【課題を解決するための手段】
【００１３】
ネットワークノードの第１の側面は，複数のノードと共にネットワークに接続されるネットワークノードにおいて，通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，他のノードから前記自身のノード宛の復旧要求データを，規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有する。
【発明の効果】
【００１４】
第１の側面によれば，信頼性の高い障害復旧動作をさせることができる。
【図面の簡単な説明】
【００１５】
【図１】本実施の形態におけるネットワークの構成図である。
【図２】本実施の形態における被状態監視ノードと状態監視ノードとの関係を示す図である。
【図３】本実施の形態におけるネットワークの通信スケジュールを示す図である。
【図４】本実施の形態におけるフレームの構成図である。
【図５】本実施の形態におけるネットワークノードの構成図である。
【図６】アライブデータの例について示す図である。
【図７】プライオリティノードを有するネットワークとタイムスロットとを示す図である。
【図８】プライオリティノード以外のノードの構成図である。
【図９】プライオリティノードの構成図である。
【発明を実施するための形態】
【００１６】
以下，本実施の形態を図面を参照して説明する。
【００１７】
図１は，本実施の形態におけるネットワークの構成図である。このネットワークは，ネットワークであるバス１０に，複数のノード２１〜２４が接続されている。各ノード２１〜２４は，自身に割り当てられたタイムスロットでフレームをバス１０に送信する。また，各ノード２１〜２４は，それぞれアクチュエータなどの被制御デバイスやセンサなどの被監視デバイスに接続され，被制御デバイスへの制御や被監視デバイスからの状態検出などを行う。そして，それらに応答して必要なコマンドや検出データなどをネットワークを介して他のノードに転送する。
【００１８】
以下，本実施の形態のネットワークは，FlexRayを具体例にして説明されるが，必ずしもFlexRayに限定されるものではなく，フレームを互いに転送しあう複数のノードが接続されたネットワークに適用可能である。
【００１９】
前述のとおり，各ノード２１〜２４は，タイムトリガ方式で自身に割り当てられたタイムスロットで自身のフレームをバス１０に送信する。そして，各ノード内の通信コントローラは，どのタイムスロットのフレームを受信すべきかをコンフィギュレーションデータにより設定されており，その設定値に対応して，バス上のフレームを受信する。タイムトリガ方式の場合は，通信サイクルで必ず自身のフレームを送信することができるので，リアルタイム性を確保することができ，走行制御系の車載ネットワークとして適している。
【００２０】
図２は，本実施の形態における被状態監視ノードと状態監視ノードとの関係を示す図である。この図では，ノード２０Ａが被状態監視ノードであり，ノード２０Ｘが状態監視ノードである。被状態監視ノード２０Ａは，自身が送信するフレーム内に正常状態を示すアライブデータ（アライブ情報）を毎回書き込んでネットワーク上に送信する。それに対して，状態監視ノード２０Ｘは，被状態監視ノード２０Ａから送信されるフレームを受信し，その中のアライブデータを判定し，被状態監視ノード２０Ａが正常動作状態か否かを判定する。この判定は，受信したアライブデータがあらかじめ規定されている正常状態のパターンと一致するか否かで行われる。そして，不一致の場合は，状態監視ノード２０Ｘは，自身が送信するフレーム内にその被状態監視ノード２０Ａ宛の復旧要求データを書き込んでネットワーク上に送信する。
【００２１】
被状態監視ノード２０Ａは，状態監視ノード２０Ｘから送信されるフレームを受信し，そのフレーム内に自身宛の復旧要求データを検出したら，自身のノード内のネットワークドライバ（バスドライバ），通信コントローラ，マイクロプロセッサに対して復旧動作を実行させる。
【００２２】
本実施の形態では，復旧要求の信頼性を担保するために，被状態監視ノード２０Ａは，複数の状態監視ノード２０Ｘから送信されるフレーム内に自身への復旧要求データが含まれているか否かをチェックし，規定数以上の復旧要求データを受信した場合に，自身の復旧動作を実行する。
【００２３】
その理由は，状態監視ノード２０Ｘによるアライブデータの判定でアライブデータが規定されている正常状態パターンと一致しない場合，必ずしも被状態監視ノード２０Ａに何らかの障害が発生して正常状態をあらわすアライブデータを書き込むことができなかったとは限らない。例えば，状態監視ノード２０Ｘの通信コントローラの異常状態によってそのような不一致が発生する場合も考えられるし，ネットワークそのものの不具合により不一致が発生する場合も考えられる。
【００２４】
そこで，本実施の形態では，被状態監視ノード２０Ａは，複数の状態監視ノード２０Ｘから規定数以上（例えば全状態監視ノード数の過半数以上）の復旧要求データを受信した場合に，復旧動作を実行する。さらに，別の実施の形態では，被状態監視ノード２０Ａは，復旧要求データの数に応じて，実行する復旧動作を選択する。さらに，別の実施の形態では，状態監視ノード２０Ｘは，被状態監視ノード２０Ａ毎にアライブデータの判定結果をカウントし，比較的長い期間で検出された不一致の回数に応じて，復旧処理レベルを決定し，復旧要求データと共に復旧処理レベルの情報もフレームに書き込んで，被状態監視ノード２０Ａにネットワーク経由で送信する。被状態監視ノード２０Ａは，その復旧処理レベルに対応した復旧処理を実行する。
【００２５】
図３は，本実施の形態におけるネットワークの通信スケジュールを示す図である。本ネットワークにおける通信は，たとえば，予め決められたスケジュールに沿ってフレームデータの送受信を行う。すなわち，タイムトリガ型である。通信スケジュールは，図３に示されるとおり，０〜６３を繰り返しカウントする通信サイクル３０と，１つの通信サイクル内でフレーム送信のスケジューリングを管理するセグメント３２，３４と，スロットＳＬ１〜ＳＬ４とで構成される。
【００２６】
１つの通信サイクルは，スタティックセグメント３２と，ダイナミックセグメント３４と，アイドル時間３６とで構成される。そして，スタティックセグメント３２では，タイムトリガ方式により各ノードが送信を行う期間であり，予め決められた長さのフレームＦＬ１〜ＦＬ４がスケジュールに沿って送信される。図１のすべてのノードに同じ長さのスロットＳＬ１〜ＳＬ４が割り当てられていて，各スロットで各フレームのフレームＦＬ１〜ＦＬ４がネットワークのチャネル上に送信される。したがって，１回の通信サイクルを経過すると，すべてのノードのフレームがバス上に送信されたことになる。
【００２７】
ダイナミックセグメント３４では，任意のタイミングでフレームを送信するイベントドリブン方式により送信が行われる期間であり，図示しないが，送信データは可変長である。また，アイドル時間３６中に，全ノード間で同期をとることが行われる。このように，タイムトリガ方式により１回の通信サイクル内で全ノードが確実に送信することができ，リアルタイム性と高信頼性とを実現するとともに，イベントドリブン方式のダイナミックセグメントも持たせている。本実施の形態では，上記のダイナミックセグメントは必ずしも必要ではない。
【００２８】
図４は，本実施の形態におけるフレームの構成図である。フレームＦＬは，ヘッダ４０と，ペイロード４１と，トレーラー４２とで構成される。ヘッダ４０内には，同期ビット，フレームＩＤなどに加えて，どの通信サイクルかを示すサイクルカウンタの情報も含まれる。ペイロード４１には，ネットワーク管理ベクタ（ＮＭＶ）５０と，ペイロードデータ５１とが含まれる。そして，トレーラー４２には，フレームの誤り訂正コードＣＲＣが含まれる。
【００２９】
上記のＮＭＶ５０は，そのＮＭＶフォーマット６０に示されるとおり，各ノード２１〜２４で書き込まれるノードの正常状態を示すアライブデータ領域（図中Alive for #）と，状態監視ノードで書き込まれる各ノード２１〜２４宛の復旧要求データ領域（図中Reset for #）とを，各ノードそれぞれに対応して有する。したがって，フォーマット６０は４対の領域を有する。ＮＭＶ５０は，すべてのスロットのフレームで同じデータ長を有する。
【００３０】
今仮に，ノードNode1が自身のフレームをネットワーク上に送信し，他のノードのフレームをネットワーク上から受信する場合を想定して説明する。ノードNode1は，自身が送信するフレーム６１に，自身の状態が正常であることを示すアライブデータを「Alive for 1」に書き込み，他のノードに対する復旧要求データ「Reset for 2」「Reset for 3」「Reset for 4」を必要に応じて書き込む。
【００３１】
さらに，ノードNode１は，ノードNode2のタイムスロットのフレーム６２を受信する。このフレーム６２には，ノードNode1宛の復旧要求データ「Reset for 1」と，ノードNode2のアライブデータ「Alive for 2」と，ノードNode4, Node5宛の復旧要求データ「Reset for 4」「Reset for 5」が含まれる。同様に，ノードNode１は，ノードNode3のタイムスロットのフレーム６３と，ノードNode4のタイムスロットのフレーム６４も受信する。これらのフレーム６３，６４もフレーム６２と同様である。
【００３２】
図４の例では，ノードNode1は，フレーム６２，６３，６４で，ノードNode2,3,4すべてから復旧要求データ「Reset for 1」を受信している。また，すべてのフレームで，他のすべてのノード宛の復旧要求データが書き込まれている。この復旧要求データは，後述するアルゴリズムで，各ノードの通信コントローラによりフレームに書き込まれる。
【００３３】
上記のように，各ノードがそれぞれのスロットで送信するフレーム内に，自身の正常状態を示すアライブデータを書き込むことで，各ノードがノードの動作状態を相互監視することができる。もしノードに障害が発生しノードが正常状態でなければ，正常状態を示すアライブデータを書き込むことができないからである。さらに，各ノードは，他のノードの動作状態を相互に監視し，正常状態でないことを検出したら，そのノード宛の復旧要求データを自身のフレームに書き込む。そして，各ノードは他のノードのフレームをチェックして，自身宛の復旧要求データが出されたか否かを確認する。
【００３４】
図５は，本実施の形態におけるネットワークノードの構成図である。各ノードは，通信コントローラ７０と，ネットワークのバス１０にフレームを出力して送信し，他のノードが出力したバス１０上のフレームを受信して入力するネットワークドライバ（バスドライバ）７２と，図示しない通信コントローラの制御を行うマイクロプロセッサ７４とを有する。通信コントローラ７０とネットワークドライバ７２は，ハードウエアで構成される。通信コントローラ７０は，マイクロプロセッサ７４内にハードウエアマクロとして埋め込まれても良い。
【００３５】
通信コントローラ７０は，ネットワークドライバ７２と接続される通信制御マクロ７１０と，通信制御マクロ７１内のＮＭＶレジスタ７１２へのアクセスを行うＮＭＶアクセスユニット７３０と，他のノードからの復旧要求データに基づいて自身の復旧処理を判定する復旧制御ユニット７２０と，判定された復旧処理を行う復旧処理ユニット７５０と，他のノードのアライブデータを判定して必要に応じて他のノード宛の復旧要求データを自身のフレームに書き込むアライブ情報管理ユニット７４０とを有する。
【００３６】
まず，ノードが自身のフレームを送信する場合は，マイクロプロセッサ７４がフレーム内のデータを生成し，通信制御マクロ７１０内のメッセージバッファ７１１内に書き込む。フレームのヘッダ４０とトレーラー４２のデータは，通信制御マクロ７１０により生成されるが，ペイロード４１のペイロードデータ５１は，マイクロプロセッサ７４が生成する。
【００３７】
ＮＭＶのデータ５０は，図４のＮＭＶフォーマット６０にあるとおり，自身のアライブデータと，他のノード宛の復旧要求データとを有する。自身のアライブデータは，マイクロプロセッサ７４が通信サイクル毎に生成しメッセージバッファ７１１に書き込む。このアライブデータは，自身のノードが正常状態であることを示すビットであり，通信サイクル毎に変更することが決められたビット構成であってもよく，または，通信サイクルにかかわらず常に同じビット構成であってもよい。また，他のノード宛の復旧要求データは，アライブ情報管理ユニット７４０内の復旧要求発生器７４５が生成しメッセージバッファ７１１に書き込む。
【００３８】
通信制御マクロ７１０は，ネットワークドライバ７２が受信したフレームに含まれるメッセージと，ネットワークドライバ７２から出力するフレームに含まれるメッセージとを一次的に格納するメッセージバッファ７１１と，受信したフレームから抽出されたＮＭＶのデータを格納するＮＭＶレジスタ７１２と，受信したフレームから抽出されたサイクルカウンタのデータを格納して現在の通信サイクルの確認に使用される通信サイクルカウンタ７１３とを有する。
【００３９】
ＮＭＶアクセスユニット７３０は，ＮＭＶレジスタ７１２にアクセスして，ＮＭＶレジスタ内の自身宛の復旧要求データを復旧要求バッファ７２１に，他のノードのアライブデータをアライブデータバッファ７４１にそれぞれ格納する。
【００４０】
通信制御マクロ７１０は，初期化時に通信のコンフィギュレーションデータを設定されることで，所望の通信制御を実行する。このコンフィギュレーションデータには，どのタイムスロットのフレームを受信すべきかなどの情報が含まれていて，マイクロプロセッサによりインストールされる。
【００４１】
［復旧制御ユニット］
復旧制御ユニット７２０では，復旧要求判定器７２２は，復旧要求バッファ７２１に格納された他のノードからの復旧要求データの欄をチェックして，他のノードから自身宛の復旧要求データを受信したか否かを判定する。他のノードからの復旧要求データの欄とは，図４のフレーム６２，６３，６４の「Reset for 1」の欄であり，ここに自身宛の復旧要求データが書き込まれているか否かが判定される。そして，復旧要求カウンタ７２３は，他のノードからの自身宛の復旧要求データの数をカウントする。
【００４２】
そして，復旧処理判定器７２５は，例えば，１回の通信サイクル中の復旧要求カウンタ７２３のカウント数が，規定された値以上であれば，復旧処理すべきと判定し，復旧処理ユニット７５０に復旧処理要求を出力する。図１の例では，他のノードであるノード２２，２３，２４のうち，過半数の２以上のノードから復旧要求データを受信している場合に，その復旧要求データが高い信頼性を有していると考えられるので，復旧処理判定器７２５は，復旧処理要求を出力する。つまり，規定数，例えば過半数，の状態監視ノードから自身宛の復旧要求データを受信している場合に復旧処理が必要と判定することで，自身のノード以外の何らかの障害により正常状態を示すアライブデータが受信されないなどで他のノードから自身宛に復旧要求データを受信していた場合に，無駄に復旧処理を実行することを回避することができる。
【００４３】
復旧処理ユニット７５０は，復旧要求に応答して，（１）マイクロプロセッサ７４による自己診断処理，（２）通信コントローラ７０のリコンフィギュレーション処理，（３）マイクロプロセッサ７４によるリセット処理，（４）ネットワークドライバ７２の入出力遮断処理のうちいずれかを実行する。復旧処理（１）は，マイクロプロセッサ７４が，自己診断プログラムを実行して，ソフトウエア障害等に対する必要な復旧処理を行う処理であり，最も軽度の障害レベルのときに実行される。復旧処理（２）は，マイクロプロセッサ７４による通信コントローラ７０の初期化に対応し，コンフィギュレーションデータの再設定により，通信コントローラ７０による障害発生を抑制することができる。リコンフィギュレーションは，マイクロプロセッサ７４が生成したコンフィギュレーションデータを，主に通信制御マクロ７１０に設定する処理であるが，他のユニットに設定されても良い。
【００４４】
復旧処理（３）はマイクロプロセッサのパワーオンリセットなどに対応する処理であり，主にプログラムの暴走に伴う障害から復旧することができる。そして，復旧処理（４）は，ネットワークドライバ７２の入出力端子を遮断する処理であり，最も重度の障害レベルが発生したときの応急処理である。
【００４５】
上記の復旧処理（１）〜（３）の命令が復旧処理ユニット７５０によりマイクロプロセッサ７４に発行されると，マイクロプロセッサ７４は復旧処理中を示すモード信号を復旧処理ユニット７５０に返信する。それに応答して，復旧処理中を示すモード信号が他のノード宛のフレームに書き込まれて送信される。これにより，他のノードは，復旧処理中であることを認識することができる。
【００４６】
これら４つの復旧処理（１）〜（４）は，障害のレベルが低い順に実行されるべき処理に対応している。復旧処理判定器７２５は，いずれの復旧処理を実行すべきかを，たとえば，復旧要求カウンタ７２３のカウンタ値に応じて判定する。つまり，１回の通信サイクル中に受信した他の状態監視ノードからの復旧要求データの数に応じて，数が少なければ復旧処理（１）を判定し，数が多くなれば復旧処理（２）〜（３）を判定する。復旧処理（３）は，最も重度の障害発生時の処理であり，ネットワークドライバの遮断は，必ずしも復旧処理とは言えないが，それ以上の障害発生を抑制する処理といえる。
【００４７】
または，別の判定方法として，複数の通信サイクルを含む一定期間内に復旧処理が繰り返されるたびにその復旧処理のレベルを上げているようにしてもよい。
【００４８】
復旧処理レベルカウンタ７２４は，他の状態監視ノードから復旧要求データに加えて復旧処理レベルのデータを受信する場合に，復旧処理レベル別にその回数をカウントする。上記の例では，復旧処理（１）〜（４）別にその回数をカウントする。その場合は，復旧処理判定器７２５は，カウント数が最も多い復旧処理を選択して，復旧要求を復旧処理ユニット７５０に出力する。他の状態監視ノードによる復旧処理レベルの選定については後述する。
【００４９】
なお，復旧要求データと復旧処理レベルのデータは，送信側のノードで暗号化され，受信側のノードで復号化されることが好ましい。このようにすることで，復旧処理の起点となる受信データの信頼性を向上させて，不必要な復旧処理が行われることを抑制することができる。
【００５０】
［アライブ情報管理ユニット］
アライブ情報管理ユニットを有するノードは，状態監視ノードとしての機能を有する。
【００５１】
アライブ情報管理ユニット７４０では，状態判定器７４２が，アライブデータバッファ７４１に他のノード別に格納されている他のノードのアライブデータを正常状態を示す規定パターンと比較して，他のノードの動作状態を判定する。状態判定器７４２は，他のノードのアライブデータが正常状態の規定パターンと異なっている場合は，復旧要求発生器７４５にその結果を通知する。それに応答して，復旧要求発生器７４５は，メッセージバッファ７１１内の自身のフレームのＮＭＶ５０の欄に，他のノード宛の復旧要求データを書き込む。
【００５２】
そして，他のノードは，この復旧要求データが書き込まれたフレームを受信し，その復旧要求データに対応して必要な復旧処理を実行する。この復旧処理については，上記の復旧制御ユニット７２０のところで説明済みである。
【００５３】
アライブ情報管理ユニット７４０は，一定の長い期間においてアライブデータ判定で検出した異常状態の回数を他のノード別にカウントし，そのカウント値に応じて最適な復旧処理レベルを判定し，他のノードに復旧要求データとともに復旧処理レベルのデータも送信する。つまり，アライブデータが正常状態以外のパターンの場合は，被状態監視ノードが正常に動作していない可能性があるので，復旧要求発生器７４５がその被状態監視ノードに対して復旧要求データを送信し，復旧処理を行わせている。しかし，比較的長い期間において，前記復旧要求データの送信にもかかわらず，アライブデータが正常状態以外のパターンを示す場合は，アライブ情報管理ユニット７４０がその回数に応じて徐々に復旧処理レベルを上げるようにすることで，被状態監視ノードに適切な復旧処理を行わせることができる。
【００５４】
そのために，異常状態カウンタ７４３は，被状態監視ノード別に異常状態をカウントする。そして，復旧処理レベル判定器７４４は，そのカウント値に応じて，被状態監視ノードに対する復旧処理レベルを判定する。判定された復旧処理レベルは復旧要求発生器７４５に供給され，復旧処理要求発生器７４５は，その復旧処理レベルを，メッセージバッファ７１１内の自身が送信するフレーム内のＮＭＶの欄に書き込む。
【００５５】
そして，通信制御マクロ７１０は，自身のノードに割り当てられたタイムスロットでメッセージバッファ７１１に書き込まれたフレームをネットワークドライバ７２を介してバス１０に出力する。
【００５６】
図６は，アライブデータの例について示す図である。上記の説明では，アライブ情報管理ユニット７４０内の状態判定器７４２は，他の被状態監視ノードからのアライブデータを受信するたびに，そのアライブデータが正常状態を示すパターンと一致するか否かを判定した。FlexRay通信には，送信モードにコンティニュアスモードがあり，そのモードでは，各マイクロプロセッサが送信するデータを更新しなくても、通信コントローラが前回の送信データをそのまま送信することが可能である。かかるモードの場合，ノードに何らかの異常が発生して、アライブデータが更新されなくても前回の送信データにて正常状態を示すアライブデータが送信されている場合は，正常を示すアライブデータが送信される為、状態監視ノードは受信したアライブデータから被状態監視ノードの異常状態を検出することができない。
【００５７】
そこで，複数回の通信サイクルで受信したアライブデータを合成したデータを，正常状態を示すパターンと比較することが望ましい。そして，被状態監視ノードは，通信サイクル毎に異なるアライブデータをＮＭＶデータとして送信し，複数回の通信サイクルで１つのアライブデータ長８０のアライブデータを送信することが求められる。たとえば，各通信サイクルで送信される正常状態を示すアライブデータは，通信サイクル毎にビット反転されるようにしても良い。
【００５８】
図６において，サイクルＮでは，受信したＮＭＶデータ内のノードＸのアライブデータ８２が，アライブデータバッファ７４１の最下位ビットに格納される。さらに，次のサイクルＮ＋１では，受信したＮＭＶデータ内のノードＸのアライブデータ８４が，アライブデータバッファ７４１の最下位ビットに格納される。このとき，既に格納されていたサイクルＮでのアライブデータ８２は上位側にシフトされる。
【００５９】
そして，状態判定器７４２は，各通信サイクルで，１つのアライブデータ長８０のアライブデータを正常状態のパターンと比較判定する。ただし，Ｍ回の通信サイクルで１つのアライブデータ長のデータを送信できる場合は，Ｍ回に１回だけアライブデータが正常状態のパターンと一致することが検出される。したがって，Ｍ回の比較判定で１回も一致しなければ，何らかの障害が発生していると判定される。
【００６０】
または，通信サイクルカウンタの値に応じて，正常状態のパターンを適宜選択するようにしてもよい。その場合は，直近のＭ回のアライブデータがすべて正常状態であったか否かを，各通信サイクル毎に判定することができる。いずれの方法でも，複数の通信サイクルで生成されたアライブデータをチェックすることで，上記のコンティニュアスモードにも対応可能である。
【００６１】
［プライオリティノード］
図５に示したネットワークノードの通信コントローラ７０は，他のノードの状態監視をするアライブ情報管理ユニット７４０を有する。ただし，すべてのノードに他のノードの状態監視機能を持たせると，ネットワーク全体のコストアップになる。さらに，すべてのノードが他のノード宛の復旧要求データを送信するので，ノードによる復旧処理の必要性の検出は，すべてのノードのタイムスロットが経過した後になり，復旧処理に至るまでのレスポンス性が悪くなる。
【００６２】
そこで，ネットワーク内の全ノードのうち一部のノードをプライオリティノードとして，そのプライオリティノードにだけ他のノードの状態監視をするアライブ情報管理ユニット７４０を設ける。そして，プライオリティノードは，一部の被状態監視ノードについて状態監視を行うが，プライオリティノード以外のノードは，他のノードの状態監視は行わない。
【００６３】
図７は，プライオリティノードを有するネットワークとタイムスロットとを示す図である。ネットワークのバスに接続されたノードは，複数のグループＧ１，Ｇｎに分けられ，各グループ内には，図７の例では，３つのノード２１−２３，２７−２９と，プライオリティノード９１，９４とを有する。すべてのノードは，自身のフレームで自身のアライブデータを送信する。そして，プライオリティノード９１，９４は他のノードの状態監視機能を有するが，それ以外のノードは他のノードの状態監視機能を有していない。
【００６４】
プライオリティノード９１は，自身のグループＧ１内の他のノードと，自身のグループＧ１以外のグループ内のプライオリティノードを含むノードとについて，状態監視を行う。プライオリティノード９４も同様に，自身のグループＧｎ内の他のノードと，自身のグループＧｎ以外のグループ内のプライオリティノードを含むノードとについて，状態監視を行う。ただし，プライオリティノードがすべての被状態監視ノードを監視することはなく，全体の一部の被状態監視ノードのみ監視することで，状態判定のリアルタイムにおこなう。
【００６５】
このようにすることで，被状態監視ノード２１−２３，２７−２９は，複数のプライオリティノードにより状態監視され，それらから復旧要求データを受信する。したがって，被状態監視ノードは，前述した規定数以上の復旧要求データを受信したか否かを判定し，必要な復旧処理を実行することができる。さらに，プライオリティノード９１，９２，９４も，他のプライオリティノードにより状態監視され，規定数以上の復旧要求ノードを受信したか否かを判定し，必要な復旧処理を実行できる。
【００６６】
または別の構成としては，プライオリティノード９１は，自身のグループＧ１内の他のノードと，自身のグループＧ１以外のグループのプライオリティノードとについて，状態監視を行い，自身のグループＧ１以下のグループの被状態監視ノードの状態監視は行わないようにしてもよい。この場合は，各グループ内の被状態監視ノード２１−２３は，１つのプライオリティノード９１からしか状態監視されず，１つのプライオリティノード９１からしか復旧要求データを受信しない。しかし，被状態監視ノード２１−２３は，１回の通信サイクルで受信した復旧要求データの数ではなく，一定の複数回の通信サイクルで受信した復旧要求データの数が規定値以上かいなかで復旧処理の有無を判定するようにすることで，復旧要求データの信頼性を担保することができる。また，プライオリティノード同士は，相互に状態監視を行うことが望ましい。
【００６７】
図７（Ｂ）には，タイムスロットＳｌｏｔとそれに割り当てられた通信ノードとの関係が示されている。すべてのノードに対して，予めタイムスロットが割り当てられていて，各タイムスロットで対応するノードがフレームを送信する。このようにタイムスロットが割り当てられているので，すべてのノードが自身のフレームでアライブデータを送信する。そして，プライオリティノードだけが，他のノードに対して復旧要求データを自身のフレームで送信する。
【００６８】
図８は，プライオリティノード以外のノードの構成図である。図８のノードは，通信コントローラ７０と，ネットワークドライバ７２と，マイクロプロセッサ７４とを有する。ただし，図５のノードの構成と異なり，通信コントローラ７０は，通信制御マクロ７１０と，復旧制御ユニット７２０と，ＮＭＶアクセスユニット７３０と，復旧処理ユニット７５０とを有し，図５のアライブ情報管理ユニット７４０は有していない。つまり，他のノードの状態監視機能を有していない。それ以外は，図５のノードと同じである。
【００６９】
プライオリティノードの構成は，図５に示したノード構成と同じである。つまり，プライオリティノードの通信コントローラは，アライブ情報管理ユニット７４０により他のノードの状態を監視し，監視対象である他のノードのアライブデータが正常状態のパターンでないことを検出した場合に，そのノードに対して復旧要求データを自身のフレームに書き込んで送信する。また，プライオリティノードの通信コントローラは，必要に応じて，復旧処理レベルを判定して，復旧要求データとともに復旧処理レベルのデータも自身のフレームに書き込んで他のノードに送信する。
【００７０】
図９は，プライオリティノードの別の構成図である。このプライオリティノードは，通信コントローラ７０とネットワークドライバ７２とを有する。このプライオリティノードは，予め決められた状態監視対象のノードのスロットで送信されるフレームからアライブデータを抽出し，正常状態のパターンと一致しないことが検出された場合は，そのノードへの復旧要求データを自身のフレームに書き込んで送信することを主な機能とする。そのために，通信コントローラ７０は，通信制御マクロ７１０とＮＭＶアクセスユニット７３０とアライブ情報管理ユニット７４０を有する。通信コントローラ７０は，図５のように復旧制御ユニットは有していない。また，マイクロプロセッサも設けられていない。
【００７１】
図９のプライオリティノードを有するネットワークにおいても，図８の場合と同様に，プライオリティノード以外の被状態監視ノードは，アライブデータのチェックと，復旧要求データの出力は行わない。
【００７２】
以上の実施の形態をまとめると，次の付記のとおりである。
【００７３】
（付記１）
複数のノードと共にネットワークに接続されるネットワークノードにおいて，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，他のノードから前記自身のノード宛の復旧要求データを，規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有するネットワークノード。
【００７４】
（付記２）
付記１において，
前記復旧制御手段は，前記他のノードから受信した前記復旧要求データの数に応じて，複数の復旧動作のうち対応する復旧動作を実行させるネットワークノード。
【００７５】
（付記３）
付記２において，
前記複数の復旧動作は，通信コントローラのリコンフィギュレーション動作と，制御プロセッサのパワーオンリセット動作と，ネットワークドライバの遮断動作とを少なくとも有するネットワークノード。
【００７６】
（付記４）
付記１において，
さらに，他のノードが送信したフレーム内のアライブデータを前記他のノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークノード。
【００７７】
（付記５）
付記４において，
前記アライブデータ監視手段は，規定された複数の通信サイクルで受信した前記他のノードが送信したフレーム内のアライブデータを，前記規定の正常状態パターンと一致するか否かを判定するネットワークノード。
【００７８】
（付記６）
付記４または５において，
前記アライブデータ監視手段は，前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし，所定期間における当該不一致回数に応じて，復旧処理レベルデータを前記自身が送信するフレーム内に書き込むネットワークノード。
【００７９】
（付記７）
ネットワークと，
前記ネットワークに接続された複数のネットワークノードとを有し，
前記複数のネットワークノードは，第１及び第２のネットワークノードを有し，
前記第１のネットワークノードは，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第２のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，前記第２のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有し，
前記第２のネットワークノードは，
前記フレーム送信手段と，
他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークシステム。
【００８０】
（付記８）
付記７において，
前記アライブデータ監視手段は，規定された複数の通信サイクルで受信した前記他のノードが送信したフレーム内のアライブデータを，前記規定の正常状態パターンと一致するか否かを判定するネットワークシステム。
【００８１】
（付記９）
付記７または８において，
前記アライブデータ監視手段は，前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし，所定期間における当該不一致回数に応じて，復旧レベルデータを前記自身が送信するフレーム内に書き込むネットワークシステム。
【符号の説明】
【００８２】
１０：バス（ネットワーク） ７２：ネットワークドライバ（バスドライバ）
７０：通信コントローラ ７４：マイクロプロセッサ
７１０：通信制御手段 ７２０：復旧制御手段
７４０：アライブデータ管理手段，アライブ情報管理ユニット
【特許請求の範囲】
【請求項１】
複数のノードと共にネットワークに接続されるネットワークノードにおいて，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，他のノードから前記自身のノード宛の復旧要求データを，規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有するネットワークノード。
【請求項２】
請求項１において，
前記復旧制御手段は，前記他のノードから受信した前記復旧要求データの数に応じて，複数の復旧動作のうち対応する復旧動作を実行させるネットワークノード。
【請求項３】
請求項１において，
さらに，他のノードが送信したフレーム内のアライブデータを前記他のノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークノード。
【請求項４】
請求項３において，
前記アライブデータ監視手段は，前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし，所定期間における当該不一致回数に応じて，復旧処理レベルデータを前記自身が送信するフレーム内に書き込むネットワークノード。
【請求項５】
ネットワークと，
前記ネットワークに接続された複数のネットワークノードとを有し，
前記複数のネットワークノードは，第１及び第２のネットワークノードを有し，
前記第１のネットワークノードは，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第２のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，前記第２のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有し，
前記第２のネットワークノードは，
前記フレーム送信手段と，
他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークシステム。
【請求項１】
複数のノードと共にネットワークに接続されるネットワークノードにおいて，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて他のノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，他のノードから前記自身のノード宛の復旧要求データを，規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有するネットワークノード。
【請求項２】
請求項１において，
前記復旧制御手段は，前記他のノードから受信した前記復旧要求データの数に応じて，複数の復旧動作のうち対応する復旧動作を実行させるネットワークノード。
【請求項３】
請求項１において，
さらに，他のノードが送信したフレーム内のアライブデータを前記他のノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークノード。
【請求項４】
請求項３において，
前記アライブデータ監視手段は，前記アライブデータが前記正常状態パターンと不一致になった不一致回数をカウントし，所定期間における当該不一致回数に応じて，復旧処理レベルデータを前記自身が送信するフレーム内に書き込むネットワークノード。
【請求項５】
ネットワークと，
前記ネットワークに接続された複数のネットワークノードとを有し，
前記複数のネットワークノードは，第１及び第２のネットワークノードを有し，
前記第１のネットワークノードは，
通信サイクル毎に前記ネットワークに送信するフレームに，自身の正常状態を示すアライブデータを書き込んで送信するフレーム送信手段と，
自身のノードが送信したフレーム内の前記アライブデータに基づいて前記第２のネットワークノードが送信したフレーム内の自身のノード宛の復旧要求データをカウントし，前記第２のネットワークノードから前記自身のノード宛の復旧要求データを規定した数以上受信したときに，自身のノードに復旧動作を実行させる復旧制御手段とを有し，
前記第２のネットワークノードは，
前記フレーム送信手段と，
他のノードが送信したフレーム内のアライブデータを前記ノード別に記憶すると共に，前記アライブデータが規定の正常状態パターンと一致するか否かを判定し，不一致の場合に自身が送信するフレーム内に当該不一致を検出したノードへの復旧要求データを書き込むアライブデータ監視手段を有するネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１１−２３９８３（Ｐ２０１１−２３９８３Ａ）
【公開日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願番号】特願２００９−１６７２５３（Ｐ２００９−１６７２５３）
【出願日】平成２１年７月１５日（２００９．７．１５）
【出願人】（３０８０１４３４１）富士通セミコンダクター株式会社 (2,507)
【Ｆターム（参考）】
【公開日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願日】平成２１年７月１５日（２００９．７．１５）
【出願人】（３０８０１４３４１）富士通セミコンダクター株式会社 (2,507)
【Ｆターム（参考）】
[ Back to top ]