JP2009037575A - 分散システム - Google Patents

Abstract

【課題】
分散制御システムでは障害を特定し、障害発生状況に応じて、ノード間で足並みを揃えて状態遷移することがシステムの安全性を保つために重要である。ノード間相互監視を行うことで、障害発生数を管理するエラーカウンタの値はノード間で一致するが、障害発生状況に応じては、カウンタ値がノード間でずれてしまう。この為、ノード間でエラーカウンタ同期の実施が必要となる。
【解決手段】
複数ノードがネットワークを介して接続される分散システムにおいて、複数ノードの各々は、他ノードに対する障害監視を行う障害監視部と、ネットワークを介して他ノードの障害を検知するデータを送受信し、障害監視結果を交換する送受信部と、交換された障害監視結果に基づいて、ノード障害を特定する障害特定部と、障害があると特定されたノードのエラーの数をカウントするカウンタ部と、エラーカウンタ値をノード間で交換し同期を取るカウンタ同期部を備える。
【選択図】図１

Description

本発明は、ネットワークにより結合された複数の装置が協調動作して、制御を行う分散システムに関する。

近年、自動車の運転快適性や安全性の向上を目指して、機械的な結合ではなく、電子制御により、運転者のアクセル，ステアリング，ブレーキなどの操作を車両の駆動力，操舵力，制動力発生機構などに反映させる車両制御システムの開発が行われている。このようなシステムでは、自動車内に分散した複数の電子制御装置（ＥＣＵ：Electronic Control Unit）がネットワークを介してデータをやり取りして協調動作を行う。この際、同一ネットワーク内のあるＥＣＵに障害が発生した際に、残りの正常なＥＣＵが、どのＥＣＵに障害が発生したかを正確に特定し、障害箇所に応じた適切なバックアップ制御を行うことが、フェールセーフ上必要不可欠となる。上記課題を解決するために、システムを構成する各ノード（ＥＣＵなどの処理主体）がネットワーク内の他ノードの状態を監視する技術がある（特許文献１参照）。

特開２０００−４７８９４号公報

特許文献１によれば、データベースアプリケーションの稼動状態などに関する監視情報を各ノードで相互に共有するための特別なノード（共有ディスク）が必要になり、この共有ディスクが故障するとシステム内の障害ノード監視を継続することができなくなってしまう。また、共有ディスクを設けることにより、システムのコストが増加することが懸念される。

その課題を解決するために、以下のような方法が考えられる。例えば、あるノードのある項目について、各ノードが単独で障害を検出するための監視を行い、その障害監視結果を、ネットワークを通してノード間で交換し、各ノードにて障害監視結果を集約し、最終的な障害の特定を行う。また、障害特定結果をネットワークで交換し、一致化を図ったり、矛盾を発見したりする方法も考えられる。障害発生数はエラーカウンタで把握し、カウンタ値が指定の閾値以上となった時点で、制御アプリケーションに障害発生の事実を通知する。障害通知を受けた制御アプリケーションは、障害発生の状況に応じてバックアップ制御への移行など、障害対策を実行する。

以上のようなノード間の相互監視を行えば、エラーカウンタ値はノード間で原則的に一致する。しかし、ノードリセットが発生した場合や、通信障害により障害監視結果や障害特定結果の交換を行えない場合に、ノード間でエラーカウンタ値がずれてしまう場合もある。

エラーカウンタ値がずれると、障害通知のタイミングがずれ、バックアップ制御への移行時機がノード間でバラバラになる。制御モードの遷移は、ノード間で足並みを揃えて行わないと、車両の安全性，安定性が確保できない恐れがある。例えばブレーキバイワイヤー（以下、ＢＢＷと称す）では、極端に不均衡な各輪のブレーキ力がスリップを引き起こす恐れがある。

このような問題を回避するために、エラーカウンタの同期を取る必要がある。その同期手段として、自ノードのカウンタがある値に到達した以降、他ノードにそのことを通知する方法がある。例えば、カウンタ値が１０で障害通知をする設定時に、自ノードのカウンタ値が９になったら、次以降の通信サイクルでは他ノードへの送信データ中に特定ビットを立てることで、障害通知寸前であることを他ノードに通知する。この特定ビットを以降では「リーチフラグ」と呼び、リーチフラグを用いるエラーカウンタ同期を「リーチフラグ同期」と呼ぶことにする。

リーチフラグを受信してカウンタ値の同期を取ったノードは、その通信サイクル以降にてノード間相互監視によりカウンタ値が障害通知寸前のノードについて障害を特定すると、エラーカウンタ値が１０になる。これにより、全ノードで同時に障害通知がなされ、バックアップ制御への移行を行うことが可能となる。

上記のように、リーチフラグ同期は簡便で使いやすい手法だが、一方でロバストでないという性質もある。障害により誤ってリーチフラグが立ってしまうと、それを受信したノードではカウンタ値が大幅に変化してしまう。これはカウンタ値が増加するので、安全サイドであると捉えることもできるが、システムのアベイラビリティを下げ、場合によっては信頼性も低下することにも繋がる。

本発明は、上記の問題を解決して、ネットワークにより結合された複数の装置が協調動作して、制御を行う分散システムを提供することにある。

これを解決するために、本発明では、相互監視を行いそれぞれのエラーカウンタを持つノード同士が、エラーカウンタにて管理するエラー発生数（以下「エラーカウンタ値」）の交換を行い、ある条件が成立した際に、他ノードのカウンタ値もしくはそれから導かれる値に、自ノードのカウンタ値を合せることにより、ノード間でカウンタ同期を取る構成を備えるものである。そして、この方法を、エラーカウンタ送信同期と呼ぶ。

そして、本発明では、エラーカウンタ送信同期を取るためのシステム構成は、複数のノードがネットワークを介して接続される分散システムであり、複数のノードの各々は、他ノードに対する障害監視を行う障害監視部と、ネットワークを介して他ノードの障害を検知するためのデータを送受信し、障害監視結果を交換する送受信部と、交換された障害監視結果に基づいて、ノード障害を特定する障害特定部と、障害があると特定されたノードのエラーの数をカウントするカウンタ部と、エラーカウンタ値をノード間で交換し同期を取るカウンタ同期部を備えるものである。

これにより、本願の発明では、リーチフラグ同期ではカウンタが特定の値のときだけしか同期をとれないが、エラーカウンタ同期では、その値でも同期が取れるため、よりロバストな分散システムを構築できる。

本発明によれば、ノード間でのエラーカウンタ同期がロバストになり、ノード間で同時機に制御アプリケーションへの障害通知を行うことができる。また不必要な障害通知とそれを受けたバックアップ制御への移行を避け、システムのアベイラビリティを向上することができ、システムの信頼性も高く保つことができる。

以下、本発明の実施例を図面を用いて説明する。

図１は、分散システムの構成図である。

分散システムは、複数のノード１０（１０−１，１０―２，…，１０−ｎ）からなり、これらは、ネットワーク１００を介して接続される。ここで、ノードとは、ネットワークを介して情報通信可能な処理装置であり、ＣＰＵを含む各種の電子制御装置，アクチュエータとそのドライバ，センサ等が含まれる。ネットワーク１００は多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して、同一内容を同時に送信するブロードキャスト送信が可能である。

各ノードｉ（ｉはノード番号，ｉ＝１〜ｎ）は、ＣＰＵ１１−ｉ，主メモリ１２−ｉ，Ｉ／Ｆ１３−ｉ、及び、記憶装置１４−ｉとからなり、これらは内部通信線等により接続されている。又、Ｉ／Ｆ１３−ｉは、ネットワーク１００と接続されている。

記憶装置１４−ｉは、送受信処理部１４１−ｉ，障害監視部１４２−ｉ，障害特定部１４３−ｉ、及び、カウンタ部１４４−ｉ，カウンタ同期部１４５−ｉ等のプログラム、並びに、障害特定結果１４６−ｉを格納する。障害特定結果１４６−ｉは、後述の監視結果集約表，障害特定結果表を含む。

ＣＰＵ１１−ｉは、これらのプログラムをメインメモリ１２−ｉに読み込み、実行することにより、処理を行う。本稿で説明するプログラムやデータは、予め記憶装置に格納しておいてもよいし、メモリカード等の記憶媒体から入力してもよいし、ネットワーク経由で他の装置からダウンロードしてもよい。又、当該プログラムにより実現される機能を、専用のハードウェアにより実現してもよい。以下では、プログラムを主体として記載するが、実際の主体はＣＰＵである。

送受信処理部１４１−ｉは、ネットワーク１００を介して、ノード障害を検知するためのデータ、並びに障害監視結果などを送受信する。障害監視部１４２−ｉは、ノードの障害を検知するためのデータに基づいて、どのノードに障害があるかの障害監視（ＭＯＮ）を行い、その結果を送受信処理部１４１−ｉを用いて他ノードに送信する。障害特定部１４３−ｉは、自ノード及び送受信処理部１４１−ｉにて受信する他ノードによる障害監視結果に基づき、障害特定を行う。カウンタ部１４４−ｉは、障害特定にて障害があると特定されたノードのエラーの数を、障害種類毎にカウントする。カウンタ同期部１４５−ｉは、自ノードのエラーカウンタ値を送受信処理部１４１−ｉを用いて他ノードへ送信し、送受信処理部１４１−ｉにて受信する他ノードのエラーカウンタ値に、後述する条件が成立するときのみ自ノードのカウンタ値を合せることにより、ノード間でエラーカウンタの同期を取る。

図２は、エラーカウンタ送信同期の処理フローを示す。これらの処理は、各ノード（具体的にはカウンタ同期部１４５−ｉ）が、ネットワーク１００を介して互いに通信しながら、通信サイクル毎などの時間的な同期を取りつつ行う。

ステップ２１０では、障害特定などの結果として判明する、ノード毎・障害種類毎の障害有無に応じて、エラーカウンタ値を変更し、仮のカウンタ値とする。カウンタ値変更の判断材料とする障害有無の判定結果として何を用いるか、またカウンタ値変更の実施時機については、相互監視の方法により異なるので後述する。カウンタ値が仮である理由は、ステップ２４０にてカウンタ値のノード間同期が済むまで、確定できないからである。

ステップ２２０では、他ノードに送信するエラーカウンタ値を選択する。すなわち、どのノードの、どのエラー種類のカウンタ値を送信データに含めるかを選択する。選択方法は相互監視方法により異なるので後述する。

ステップ２３０では、送受信処理部１４１−ｉがネットワーク１００を介して、ステップ２１０にて得る仮のエラーカウンタ値を送受信しあい、交換する。

ステップ２４０では、ステップ２３０にて他ノードから受信したカウンタ値、および自ノードのカウンタ値から、エラーカウンタ同期の条件が成立するかを判断し、条件が成立する場合には、交換したカウンタ値から導かれる値（以下「同期カウンタ値」）に自ノードのカウンタ値を合せることにより、エラーカウンタをノード間で同期させる。エラーカウンタ同期条件や同期カウンタ値の導き方は各種あるため、後述する。

図３は、図２のステップ２４０である「エラーカウンタ同期条件判定・実行」の詳細を示した処理フローである。この処理はエラーカウンタ毎、すなわちエラーカウンタが管理する対象ノード毎・通信チャンネル毎・エラー種類毎に行う。

ステップ３００では、ステップ２３０にて他ノードから受信したカウンタ値、および自ノードのカウンタ値から、同期カウンタ値を計算する。

ステップ３１０では、ステップ２３０にて他ノードから受信したカウンタ値、および自ノードのカウンタ値や、ステップ３００にて計算した同期カウンタ値から、エラーカウンタ同期条件が成立するか否かを判断する。同期条件が成立する場合にはステップ３２０へ、成立しない場合にはステップ３５０へ進む。

ステップ３２０では、自ノードのエラーカウンタ値を、ステップ３００にて計算した同期カウンタ値に修正して合わせる。同期カウンタ値と自ノードのカウンタ値とが同じであれば、修正しなくてもよい。

ステップ３３０では、自ノードのエラーカウンタ値が仮同期状態であるかを判断する。仮同期とは、同期カウンタ値に自ノードのカウンタ値を合わせているが、まだ確定していない状態のことを言う。仮同期状態であればステップ３３５へ、そうでなければ処理を終了する。

ステップ３３５では、同期処理の対象としているエラーカウンタ（以下「同期対象エラーカウンタ」）について、指定回数だけ連続してエラーカウンタ同期に成功しているか、すなわちステップ３１０の同期条件が成立したか否かを判断する。成功していれば、ステップ３４０へ進んで同期を確定し、仮同期状態を解く。その後、処理を終了する。連続同期成功回数が指定回数に到達していなければ、仮同期状態のままとし、処理を終了する。この指定回数は、ソフトウェアにて設計者が事前に設定しておく。

ステップ３５０では、同期対象エラーカウンタについて、カウンタリセット状態であるか否かを判断する。カウンタリセット状態か否かの判断方法としては、次の２つが考えられる。
（１）カウンタ値が０
（２）リセットフラグが有効（ビットが立っている）
カウンタリセット状態になるのは、ノードが自己診断や相互監視により自ノードに異常があるのを発見し、自ノードをリセットすることにより、カウンタがクリアされる場合などがある。カウンタリセット状態であればステップ３６０へ、そうでなければステップ３７０へ進む。

ステップ３６０では、自ノードのカウンタ値を同期カウンタ値に仮同期する、すなわち仮に合わせる。これにより、ノードリセット後などのカウンタリセット状態にてエラーカウンタ同期条件が成立しない状況でも、カウンタ同期を取ることができる。その後、処理を終了する。

ステップ３７０では、ステップ３３５とは逆に、指定回数だけ連続してエラーカウンタ同期に失敗しているか、すなわちステップ３１０の同期条件が成立していないかを判断する。失敗していればステップ３８０へ、失敗していなければステップ３８５へ進む。

ステップ３８０では、カウンタ同期に連続失敗しているのは自ノードのエラーカウンタに間違いがあるという理由付けのもと、自ノードのカウンタ値を修正し、同期カウンタ値に仮同期する。その後、処理を終了する。

ステップ３８５では、同期対象エラーカウンタについて、仮同期状態であるかを判断する。仮同期状態であればステップ３９０へ、そうでなければ処理を終了する。

ステップ３９０では、仮同期しているカウンタ値が間違いであるという理由付けのもと、同期対象エラーカウンタをカウンタリセット状態にする。

同期カウンタ値の計算方法としては、次のものが考えられる。１つは、あるノード・エラー種類についてのエラーカウンタ値を送信するノードが１つだけの場合、そのノードが送信するカウンタ値とする方法である。自ノードが送信ノードである場合には、自ノードのカウンタ値とする。１つは、あるノード・エラー種類についてのエラーカウンタ値を送信するノードが複数ある場合、それらノードが送信するカウンタ値から、多数決や中央値を取るとか、平均した値を四捨五入により整数化する方法である。１つは、受信したカウンタ値の最大数を取る方法である。

エラーカウンタ同期条件としては、次のものが考えられる。１つは、同期カウンタ値が自ノードのカウンタ値と比較して、差が小さいことである。具体的には、「＜エラーカウンタ同期条件１＞計算した同期カウンタ値が、自ノードのカウンタ値から＋ｋ〜−ｍ（ｋ＝１，２，３…，ｍ＝０，１，２…）の範囲内にあること」である。１つは、「＜エラーカウンタ同期条件２＞同期カウンタ値が前回の同期処理の際に計算した同期カウンタ値と比較して、差が小さい、すなわち＋ｋ’〜−ｍ’（ｋ’＝１，２，３…ｍ’＝０，１，２…）の範囲内にあること」である。ｋやｍ，ｋ’，ｍ’は、ソフトウェアにて設計者が事前に設定しておく。

１つは、同期カウンタ値の計算方法として、受信した複数のカウンタ値から多数決や中央値を取るとき、「＜エラーカウンタ同期条件３＞同期カウンタ値の計算が成立すること」である。すなわち、同期カウンタ値が計算できれば、エラーカウンタ同期条件が成立する、とする。これらエラーカウンタ同期条件は、１つでも成立すればエラーカウンタ同期可としても良いし、複数条件の成立を要求してもよい。

相互監視の障害監視（ＭＯＮ）では、自ノードや他ノードについての異常を検知するが、図２や図３のエラーカウンタ同期処理のなかでの異常を障害監視（ＭＯＮ）の監視項目としてもよい。

例えばステップ３１０にてエラーカウンタ同期条件が不成立の場合には、同期対象エラーカウンタについてカウンタ値を送信しているノードについて、障害監視部１４２−ｉは「異常あり」と判定してもよい。この障害監視結果を用いた障害特定にて「異常あり」と判定されたノードは、同期対象エラーカウンタをカウンタリセット状態にすることで、エラーカウンタの同期を取りやすくなる。

また、例えばステップ３７０にて指定回数だけ連続的に同期失敗している場合には、自ノードについて「異常あり」としてもよい。

図４は、ノード間相互監視による障害特定処理のフロー図を示す。これらの処理は、各ノードが、ネットワーク１００を介して互いに通信しながら、通信サイクル毎などの時間的な同期を取りつつ行う。

ステップ４１０にて、障害監視部１４１−ｉは、他ノードに対する障害監視（ＭＯＮとする）を行う。受信データや受信時の状況から、送信ノードについての障害有無を、自ノード単独で判断する。また、自ノードの自己診断による障害監視も行う。

障害監視（ＭＯＮ）の対象項目（以下「障害監視項目」）は、複数設定してもよい。例えば「受信異常」という項目では、未受信や誤り検出符号による誤り検出を発見するなど、データ受信関係でエラーのあるときに、送信ノードについて異常ありとする。「通番異常」という項目では、送信ノードはアプリケーションが通信サイクル毎にインクリメントする通番を送受信データに付加し、受信ノードが通番のインクリメントを確認し、インクリメントされていないときに、送信ノードに異常ありとする。通番は送信ノードのアプリケーション異常を確認するための番号である。「自己診断異常」という項目では、各ノードが自ノードの異常有無について自ら診断した結果（以下「自己診断結果」）を、他ノードに対して送信し、受信ノードが自己診断結果から、送信ノードについての異常を検知する。「自己診断異常」と「通番異常」を合わせて一つの障害監視項目に統合し、どちらかの項目で異常があれば、統合した障害監視項目にて「異常あり」としてもよい。

次にステップ４２０では、送受信処理部１４２−ｉは、ステップ４１０で得られた障害監視（ＭＯＮ）結果を、ネットワーク１００を介して送受信し合い、ノード間で交換する（ＥＸＤ１とする）。各ノードは自ノード分を含む全ノードからの障害監視結果を保持することになる。集約された障害監視結果は、障害監視結果表に書き込まれる。

次にステップ４３０では、障害特定部１４３−ｉは、ステップ４２０で各ノードに集約された障害監視（ＭＯＮ）結果から、障害特定（ＩＤ１とする）を行う。障害特定の対象とするノードは、相互監視に参加しているノードのうち自ノード以外の１つとし、これを自ノードが障害特定の責任を持つノードとして定める。また、対象ノードはノード間で重複がないようにし、さらに通信サイクル毎にローテーションする。これにより、障害特定処理の負荷をノード間で分散して低減する。

障害特定（ＩＤ１）の方法は、各障害監視項目について、集約された障害監視（ＭＯＮ）結果から異常有無の多数決を取り、「異常あり」が過半数であれば、当該ノードの当該障害監視項目に障害ありとする。多数決では閾値が過半数であるが、閾値を指定し、「異常あり」とするノード数（障害監視結果数）がその閾値以上であるかを見てもよい。

次にステップ４４０では、送受信処理部１４２−ｉは、ステップ４３０で得られた１ノードについての障害特定（ＩＤ１）結果を、ネットワーク１００を介して送受信し合い、ノード間で交換する（ＥＸＤ２とする）。これにより各ノードは、自ノード分を含む全ノードについての障害特定結果を保持することになる。

次にステップ４５０では、障害特定部１４３−ｉは、ステップ４４０で各ノードに集約された障害特定（ＩＤ１）結果から、障害特定（ＩＤ２とする）を行う。これは、特定された障害を確定するものである。障害特定結果は、障害特定結果表に書き込まれる。

次にステップ４６０では、カウンタ同期部１４５−ｉは、エラーカウンタ同期を行う。同期方法としてエラーカウンタ送信同期を用いる場合には、図２の処理フローがステップ４７０の処理内容となる。またカウンタ部１４４−ｉは、エラーカウンタ同期処理を行った後のカウンタ値を、本来のエラーカウンタに反映する。

エラーカウンタ送信同期処理では、まずエラーカウンタ仮操作（ステップ２１０）を行う。ここでは、ステップ４５０の障害特定（ＩＤ２）結果から、エラーカウンタを操作する。操作したカウンタ値は、本来のエラーカウンタとは別の領域に保存する。

エラーカウンタの操作方法として、障害特定（ＩＤ２）にて「異常あり」と判定された場合、障害特定の対象ノード・監視項目に対応するエラーカウンタ値をインクリメントする。逆に「異常なし」と判定された場合には、該当エラーカウンタ値をデクリメントしたり、リセットしたりしてもよい。異常なし時の動作として、デクリメント，リセット，何もしない、のいずれにするかは、事前にソフトウェアにて設定しておく。

次にステップ４７０では、カウンタ部１４４−ｉは、エラーカウンタ値が指定の閾値以上となった場合、障害発生の事実を制御アプリケーションに通知する。通知手段の１つには、障害特定の対象ノード・監視項目に対応するノード障害フラグを立てる方法がある。アプリケーションはノード障害フラグを参照することにより、障害発生状況を知ることができる。また、ノード障害フラグを立てた後、制御アプリケーションに対して割込みを掛けたり、コールバック関数を呼ぶことにより、通知が即座になされるようにしてもよい。

ステップ４７０で障害の通知を全て終えるか、通知が無ければ、処理を終了する。

障害特定（ＩＤ１）では、上記のような多数決型の障害特定方法を取っている。この方法では、障害ありと判断する条件（以下「障害特定条件」）として、次の２つを挙げることができる。

あるノードｊについての各ノードによる障害監視（ＭＯＮ）結果から障害特定するとき、異常を検出したノード数（障害監視結果数）が、「＜障害特定条件１＞閾値以上ならば、ノードｊに障害ありと判断」し、「＜障害特定条件２＞閾値未満ならば、障害を検出したノードに障害ありと判断」する。尚、障害ありと判断されなかったノードについては障害なしと判断する。

エラーカウンタは、障害特定条件毎に用意してもよい。その場合、障害特定結果表も障害特定条件毎に用意する。ステップ４６０では障害特定条件に対応するエラーカウンタを操作し、カウンタ同期も障害特定条件毎に取る。以下では便宜的に、障害特定条件１に対応するエラーカウンタを「多数派異常カウンタ」、障害特定条件２に対応するエラーカウンタを「少数派異常カウンタ」と呼ぶ。

同様に、ステップ４７０では制御アプリケーションへのノード障害通知時に、障害特定条件も合わせて通知する。すなわちノード障害フラグをノード番号，障害監視項目の他に、障害特定条件で分ける。以下では便宜的に、多数派異常カウンタが閾値以上になることでノード障害フラグが立つ状態を「多数派異常」といい、少数派異常カウンタが閾値以上になることでノード障害フラグが立つ状態を、「少数派異常」という。

この他の障害特定方法として、障害監視（ＭＯＮ）結果のＯＲを取る（１つでも「異常あり」という結果があれば、障害ありとする）、ＡＮＤを取る（全結果で「異常あり」という結果であれば、障害ありとする）などを用いてもよい。

図４のフロー内で行う障害特定（ＩＤ１）やカウンタ値送信対象選択では、処理対象ノードをローテーションする方が、ノード障害発生時にその影響を局所的にすることができる。

図５は対象ノードの変更スケジュールの一例を示している。スケジュール５００にて、ノード１を処理対象とするノードは、通信サイクルｉにてノード２、通信サイクルｉ＋１にてノード３と変わり、通信サイクルｉ＋ｎ−１にてノードｎ、通信サイクルｉ＋ｎにてノード２と一周し、以下繰り返す。

スケジュール５００では、ある通信サイクルにて全てのノードが障害特定（ＩＤ１）やカウンタ値送信対象選択の処理対象となるように振り分けられている。ノード２の対象は、通信サイクルｉにてノード３、通信サイクルｉ＋１にてノード４、通信サイクルｉ＋ｎ−１にてノード１と変わり、ノードｎの対象は、通信サイクルｉにてノード１、通信サイクルｉ＋１にてノード２、通信サイクルｉ＋ｎ−１にてノードｎ−１と変わる。これにより、１つのノードが障害特定（ＩＤ１）で対象とするノード数が１つだけであっても、毎通信サイクルに全てのノードについて障害特定を行うことが可能となる。

スケジュール５００は、メモリなどの記憶装置にテーブルとして保持しておいてもよいし、このように規則性のあるスケジュールは簡単な数式で計算することも可能である。数式を用いる場合、例えばスケジュール５００のノード１を処理対象とするノード番号は、通信サイクルをｎ−１で除した余りに１を加えれば求まる。

図６に、相互監視のアルゴリズムとして図４のものを用い、エラーカウンタ送信同期を併用したノード間相互監視処理の動作例を示す。

ノード１〜４は順にスロット１〜４にて送信を行い、障害監視処理（ＭＯＮ）と障害特定（ＩＤ１，ＩＤ２）処理は、各ノードの送受信終了後、通信サイクルの最後に行われるものとする。障害監視項目としては上記の「通番異常」と「受信異常」を用意している。エラーカウンタは多数派異常と少数派異常に分けている。

また、エラーカウンタ送信同期処理（ステップ４６０）において、カウンタ値送信対象選択（ステップ２２０）では、障害特定（ＩＤ１，ステップ４３０）にて対象としたノードを選択し、エラーカウンタ同期条件（ステップ２４０）としては、エラーカウンタ同期条件１、もしくはエラーカウンタ同期条件１とエラーカウンタ同期条件２のいずれかが成立すること、としている。障害特定結果交換（ＥＸＤ２，ステップ４４０）は、障害特定（ＩＤ１）の結果から操作したエラーカウンタ値を交換すること（ステップ２３０）にて代用し、障害特定（ＩＤ２，ステップ４５０）はエラーカウンタ同期（ステップ４６０）と統合している。これにより、障害特定とエラーカウンタ送信同期とを合理的に、また処理資源（ＣＰＵ能力やメモリなど）の必要量を抑え、かつ高信頼に実行できる。

通信サイクルｉでは、各ノードは前サイクル分の障害監視結果及びカウンタ仮値を送信し（６０１−０〜６０４−０，１６進数表示）、他ノードが受信して保持する（６２１−０〜６２４−０、表記は送信データと同じ）。これは障害監視結果交換（ＥＸＤ１）に該当する。送信データは、ノード１〜４についての前サイクルに実施した障害監視（ＭＯＮ）結果が順に並び、次に各通信サイクルにおける障害特定対象ノードについての、前サイクルに求めた仮のエラーカウンタ値（以下「カウンタ仮値」）が含まれる。送信データにはこの他、ヘッダや制御用データ等も含まれるが、図では省略している。障害監視結果は、通番異常を示すビット（Ｅ１）と、受信異常を示すビット（Ｅ２）からなる。但し、自ノード分の領域には、自ノードについての診断結果が入っている。カウンタ仮値は各々４ビットで表現され、通番異常に関する多数派異常のカウンタ値（ＥＣ１）、受信異常に関する多数派異常のカウンタ値（ＥＣ２）、通番異常に関する少数派異常のカウンタ値（ＦＣ１）、受信異常に関する少数派異常のカウンタ値（ＦＣ２）とからなる。

このとき、ノード３は送信前にＣＰＵ障害を起こしており、これによりノード３が送信する通番は前サイクルからインクリメントされていない。このため、ノード３以外のノードでは、障害監視（ＭＯＮ）にてノード３について通番異常を検出している（６１１−０，６１２−０，６１４−０、表記は送信データと同じ）。ノード３は自ノードについて異常を検出していない（６１３−０）。

各ノードは通信サイクルｉの最後に、通信サイクルｉ−１分（通信サイクルｉ−１の障害監視にて検出される分）の障害特定（ＩＤ１）処理を行うが、集約した通信サイクルｉ−１での障害監視結果（６２１−０〜６２４−０）に過半数を超える異常検出項目がないので、特定される障害は無い（６３１−０〜６３４−０、内容は後述のノード障害フラグ１ノード分と同じで、２進表示）。尚、通信サイクルｉにおける各ノードの処理対象ノードは、ノード１がノード４、ノード２がノード１、ノード３がノード２、ノード４がノード３である。

エラーカウンタについては、各ノードは通番異常の多数派異常カウンタＥ１＿ｊ、受信異常の多数派異常カウンタＥ２＿ｊ、通番異常の少数派異常カウンタＦ１＿ｊ、受信異常の少数派異常カウンタＦ２＿ｊ（ｊは対象ノード番号、１〜４）を持っている。各カウンタは異常が特定されないときは値が保持される。

また、送信されるカウンタ仮値を各ノードが受信すると、自ノードの保持するカウンタ値と比較し、受信したカウンタ仮値が自ノードの値に対し＋１〜−１であれば、カウンタ仮値に自ノードのカウンタ値を合わせる、と設定している（エラーカウンタ同期条件１）。また、その条件に合致しない場合も、前サイクルにて受信したカウンタ仮値と比較して、現サイクルにて受信したカウンタ仮値が＋１〜−１の範囲にあれば、現サイクルにて受信したカウンタ仮値に自ノードのカウンタ値を合わせるように設定している（エラーカウンタ同期条件２）。

各ノードの送信データにおいて、ノード１がノード２分の、ノード２がノード３分の、ノード３がノード４分の、ノード４がノード１分のカウンタ仮値を送信しており、ノード３分のＥＣ１だけが８、ほかは０となっている。このため、各ノードのエラーカウンタは、ノード３についての通番異常を管理する多数派異常カウンタＥ１＿３だけが８となり、それ以外のカウンタは０になる（６４１−０〜６４４−０，１６進表示）。

ノード障害通知の閾値は１０（１０になったら通知）としており、この時点ではノード障害フラグは立っていない（６５１−０〜６５４−０，８進表示）。

ノード障害フラグは、１ノードについて、障害特定条件１による多数派異常での通番異常を示すビット、多数派異常での受信異常を示すビット、障害特定条件２による少数派異常での通番異常を示すビット、少数派異常での受信異常を示すビットの４ビットで表され、それがノード１〜４まで順に並んでいるものとする。

通信サイクルｉ＋１では、各ノードは前サイクルの障害監視結果を送信するため、ノード１，２，４の送信データでは、ノード３についてのエラービットＥ１が立っている（６０１−１，６０２−１，６０４−１）。ノード３の送信データでは、どのエラービットも立っていない（６０３−１）。

このサイクルでもノード３は送信前にＣＰＵ障害を起こしており、これによりノード３が送信する通番は前サイクルからインクリメントされず、ノード３以外のノードでは、障害監視（ＭＯＮ）にてノード３について通番異常を検出している（６１１−１，６１２−１，６１４−１）。ノード３は自ノードについて異常を検出していない（６１３−１）。

通信サイクルｉ＋１の最後に行われる通信サイクルｉ分の障害特定（ＩＤ１）処理では、集約した障害監視結果（６２１−１〜６２４−１）にてノード３の通番異常を示すデータが過半数となるため、ノード３の多数派異常での通番異常が特定される。通信サイクルｉ＋１における各ノードの処理対象ノードは、ノード１がノード３、ノード２がノード４、ノード３がノード１、ノード４がノード２であるため、ノード１が障害を特定し（６３１−１）、それ以外のノードは障害を特定していない（６３２−１〜６３４−１）。

エラーカウンタについては、各ノードは前通信サイクルにて障害特定（ＩＤ１）の対象としたノードについてのカウンタ仮値を送信しており、特定された障害は無かったため、カウンタ仮値も、カウンタ同期処理後のカウンタ値（６４１−１〜６４４−１）も前通信サイクルと同じである。ノード障害フラグはまだ立たない（６５１−１〜６５４−１）。

通信サイクルｉ＋２では、通信サイクルｉ＋１と同様、ノード１，２，４の送信データでは、ノード３についてのエラービットＥ１が立っている（６０１−２，６０２−２，６０４−２）。ノード３の送信データでは、どのエラービットも立っていない（６０３−２）。

このサイクルでは、ノード４がスロット１にて受信障害を起こしており、ノード４のみが障害監視（ＭＯＮ）にてノード１について受信異常を検出している（６１４−２）。ノード１〜３は異常を検出していない（６１１−２，６１２−２，６１３−２）。

通信サイクルｉ＋２の最後に行われる通信サイクルｉ＋１分の障害特定（ＩＤ１）処理では、通信サイクルｉ＋１と同様、ノード３の多数派異常での通番異常が特定される。通信サイクルｉ＋１における各ノードの処理対象ノードは、ノード１がノード２、ノード２がノード３、ノード３がノード４、ノード４がノード１であるため、ノード２が障害を特定し（６３１−２）、それ以外のノードは障害を特定していない（６３２−２〜６３４−２）。

エラーカウンタについては、前通信サイクルにおける障害特定（ＩＤ１）結果から、ノード１がノード３分のＥＣ１をインクリメントして９にして送信しており（６０１−２）、それ以外のカウンタ仮値は０で送信されている（６０１−２〜６０４−２）。これにより、受信障害を起こしたノード４以外では、エラーカウンタ同期処理によってＥ１＿３が８から９に更新され（６４１−２〜６４３−２）、ノード４では８のままである（６４４−２）。ノード障害フラグはまだ立たない（６５１−２〜６５４−２）。

通信サイクルｉ＋３では、通信サイクルの最後に行われる通信サイクルｉ＋２分の障害特定（ＩＤ１）にて、集約した障害監視結果（６２１−３〜６２４−３）から、ノード４の少数派異常での受信異常を、ノード１が特定している。

またエラーカウンタについては、前通信サイクルにおける障害特定（ＩＤ１）結果から、ノード２がノード３分のＥＣ１をインクリメントして１０（０ｘａ）にして送信しており（６０２−３）、これにより、全ノードがエラーカウンタ同期処理によってＥ１＿３を９から１０（０ｘａ）に更新し（６４１−３〜６４３−３）、ノード３の多数派異常での通番異常を示すノード障害フラグが立ち、制御アプリケーションに障害通知がなされる（６５１−３〜６５４−３）。

以上により、障害監視を高信頼に行った上で、エラーカウンタ同期をロバストに行い、全ノード同時に障害通知できる。これに対しリーチフラグ同期では、通信サイクルｉ＋３にてフラグが立ち、ノード４のＥ１＿３は９になるが、その間にノード１〜３のＥ１＿３は１０になり、障害通知される。ノード４は自ノードにて障害特定するまでは、その後もカウンタが９のままとなる。

図７は、図６と同様のルールに基づいて行うノード間相互監視処理の動作例である。この例では、あるノードが自己診断により自ノードに障害を特定したことにより自ノードをリセットした、などの理由でエラーカウンタがリセット状態にある場合に、エラーカウンタを他ノードと同期させる手順を示している。尚、この例ではリセット状態を示すフラグがカウンタ毎にあるものとし、リセット状態にするとは、このフラグを有効にする（立てる）ことを、リセット状態を解くとは、このフラグを無効（降ろす）ことを意味する。

通信サイクルｉの前に、ノード４は自ノードをリセットして、エラーカウンタがリセット状態で０になっている。ノード１〜３では、Ｅ１＿３が８、それ以外のカウンタは０になっている。ノード４は通信サイクルｉから通信及び相互監視に参加する。

通信サイクルｉにて各ノードが送信する、前サイクル分の障害監視結果では、報告される障害はなく、カウンタ仮値は０になっている（７０１−０〜７０４−０）。ノード３分のＥＣ１を送信するのはノード４であるが、０になっているため、他ノードはこのカウンタ仮値に同期せず、Ｅ１＿３は８のままになっている（７４１−０〜７４３−０）。ノード４のＥ１＿３は０のままである（７４４−０）。

交換された障害監視結果に検知された障害がないため（７２１−０〜７２４−０）、障害特定（ＩＤ１）でも特定される障害はない（７３１−０〜７３４−０）。また、障害監視（ＭＯＮ）でも検知される障害はない（７１１−０〜７１４−０）。ノード障害フラグは立たない（７５１−０〜７５４−０）。

通信サイクルｉ＋１では、ノード３は送信前にＣＰＵ障害を起こしており、送信データ中の通番がインクリメントされず、ノード３以外のノードでは、障害監視（ＭＯＮ）にてノード３について通番異常を検出する（７１１−１，７１２−１，７１４−１）。ノード３は自ノードについて異常を検出していない（７１３−１）。集約した通信サイクルｉ分の障害監視結果（７２１−１〜７２４−１）に過半数を超える異常検出項目がないので、特定される障害は無い（７３１−１〜７３４−１）。

エラーカウンタについては、ノード１がノード３分のＥＣ１として８を送信しており（７０１−１）、ノード２，ノード３のＥ１＿３はもとからが８であるため、そのままとなる（７４２−１，７４３−１）。一方、ノード４のＥ１＿３はリセット状態であるため、８に更新し、リセット状態を解く（７４４−１）。この時点ではＥ１＿３は仮同期であり、それを示すものとして、仮同期フラグを用意し、有効にする。

通信サイクルｉ＋２では、ノード３以外は前サイクルの障害監視結果として、ノード３の通番異常（Ｅ１）を送信データにて報告する（７０１−２，７０２−２，７０４−２）。障害特定（ＩＤ１）処理では、集約した障害監視結果（７２１−２〜７２４−２）にてノード３の通番異常を示すデータが過半数となるため、ノード３の多数派異常での通番異常が特定される。本通信サイクルにおいてはノード４がノード３を処理対象ノードとするため、ノード４が障害を特定し（７３４−２）、それ以外のノードは障害を特定していない（７３１−２〜７３３−１）。

エラーカウンタについては、ノード２がノード３分のＥＣ１を送信している（７０２−２）。ノード１，ノード３のＥ１＿３は同期して８のままとなる。ノード４もそうなるところであるが、ノード内部でソフトエラーを起こし、ノード２から受信したノード３分のＥＣ１を４と勘違いしたとする。ノード４はＥ１＿３の連続同期に失敗するため、Ｅ１＿３をリセット状態に戻し、仮同期フラグを無効にする。カウンタ値も０にする方法を取っても良いが、本実施例では値を保留して８のままとする（７４４−２）。

通信サイクルｉ＋３では、ノード４がノード３分のＥＣ１を送信する。ノード４のＥ１＿３はリセット状態なので、無効値（例えばノード障害通知の閾値である１０より大きい０ｘＦ）を送信しても良いが、本実施例では仮の値である８をベースに、前通信サイクルの障害特定（ＩＤ１）結果から１つインクリメントした９を送信する（７０４−３）。これにより、ノード１〜３はＥ１＿３を９に同期させる（７４１−３〜７４３−３）。ノード４のＥ１＿３は、次通信サイクルにてノード３分のＥＣ１として８〜１０を受信した場合には、前回受信値である８に対してエラーカウンタ同期条件２が成立するため、受信したＥＣ１に同期する。この同期は、仮同期としても良いし、同期確定としてもよい。次通信サイクルでのノード３分のＥＣ１が上記以外の場合には、その受信値に仮同期する。

以上のようにして、リセット状態からも図２の処理フローでエラーカウンタ同期を取ることができる。

図８は、図６と同様のルールに基づいて行うノード間相互監視処理の動作例である。この例では、あるノードのエラーカウンタがソフトエラー等により誤った値になってしまった状態から、他ノードとエラーカウンタを同期させる手順を示している。

通信サイクルｉにおける各ノードの送信データでは、前サイクル分の障害監視結果に報告される障害はなく、カウンタ仮値は、ノード４が送信するノード３分のＥＣ１は８、それ以外は０になっている（７０１−０〜７０４−０）。エラーカウンタ同期処理によって、各ノードのＥ１＿３は８、それ以外のカウンタ値は０になる（８４１−０〜８４３−０）。ただしノード４ではソフトエラーを起こし、Ｅ１＿３が４になってしまうとする（８４４−０）。ノード障害フラグは立たない（８５１−０〜８５４−０）。

通信サイクルｉ＋１では、ノード３は送信前にＣＰＵ障害を起こしており、送信データ中の通番がインクリメントされず、ノード３以外のノードでは、障害監視（ＭＯＮ）にてノード３について通番異常を検出する（８１１−１，８１２−１，８１４−１）。ノード３は自ノードについて異常を検出していない（８１３−１）。集約した通信サイクルｉ分の障害監視結果（８２１−１〜８２４−１）に過半数を超える異常検出項目がないので、特定される障害は無い（８３１−１〜８３４−１）。

エラーカウンタについては、ノード３についてのＥＣ１をノード１が送信している（８０１−１）。エラーカウンタ同期処理により、ノード１〜３のＥ１＿３は８のままとなる（８４１−１〜８４３−１）。一方、ノード４のＥ１＿３はエラーカウンタ同期に失敗し、４のままとなる（８４４−１）。

通信サイクルｉ＋２では、ノード３以外は前サイクルの障害監視結果として、ノード３の通番異常（Ｅ１）を送信データにて報告する（８０１−２，８０２−２，８０４−２）。障害特定（ＩＤ１）処理では、集約した障害監視結果（８２１−２〜８２４−２）にてノード３の通番異常を示すデータが過半数となるため、ノード３の多数派異常での通番異常が特定される。本通信サイクルにおいてはノード４がノード３を処理対象ノードとするため、ノード４が障害を特定し（８３４−２）、それ以外のノードは障害を特定していない（８３１−２〜７３３−１）。

エラーカウンタについては、ノード３についてのＥＣ１をノード２が送信している（８０２−２）。エラーカウンタ同期処理により、ノード１〜３のＥ１＿３は８のままとなる（８４１−２〜８４３−２）。一方、ノード４のＥ１＿３はエラーカウンタ同期に失敗するが、連続的に同期に失敗したため、８に仮同期する（８４４−２、連続失敗回数を２回までとしたとき）。

通信サイクルｉ＋３でのエラーカウンタについては、ノード３についてのＥＣ１の送信をノード４が担当している。前通信サイクルにおける障害特定（ＩＤ１）結果から、仮同期中の値である８をインクリメントした９を送信する（８０２−３）。エラーカウンタ同期処理により、ノード１〜３のＥ１＿３は９となる（８４１−３〜８４３−３）。一方、ノード４のＥ１＿３も９になる（８４４−３）が、状態は仮同期のままであり、同期確定は次サイクル以降になされる。ただし、仮同期でもカウンタ値が閾値である１０以上になれば、障害通知を行う設定としてもよい。

以上のようにして、エラーカウンタ値が障害により誤った（他ノードと同期の取れていない）値になってしまった状態からも、図２の処理フローでエラーカウンタ同期を取ることができる。

図９は、ノード間相互監視による障害特定処理の処理フローを示す。これらの処理は、各ノードが、ネットワーク１００を介して互いに通信しながら、通信サイクル毎などの時間的な同期を取りつつ行う。

まずステップ９１０の障害監視は、ステップ４１０の障害監視と同じである。また、次のステップ９２０では、送受信処理部１４２−ｉは、ステップ４２０の障害監視結果交換と同様に、ステップ９１０の障害監視結果をネットワーク１００を介してノード間で交換する。

次に、ステップ９３０では、障害特定部１４３−ｉは、ステップ９２０で各ノードに集約された障害監視（ＭＯＮ）結果から、障害特定（ＩＤとする）を行う。障害特定方法はステップ４３０と同じである。ステップ４３０では、自ノードの担当する１ノード分の障害特定しか行わなかったが、ここでは全ノード分の障害特定を行う点が、図４の処理フローとは異なる。全ノード分行うため、処理対象ノードのローテーションも行われない。

次に、ステップ９４０では、カウンタ同期部１４５−ｉは、エラーカウンタ同期を行う。同期方法としてエラーカウンタ送信同期を用いる場合には、図２の処理フローがステップ４７０の処理内容となる。またカウンタ部１４４−ｉは、エラーカウンタ同期処理を行った後のカウンタ値を、本来のエラーカウンタに反映する。エラーカウンタは図４の処理フローと同様、多数派異常と少数派異常で分けても良い。

エラーカウンタ送信同期処理では、ますエラーカウンタ仮操作（ステップ２１０）を行う。ここでは、ステップ９３０の障害特定（ＩＤ）結果から、エラーカウンタを操作する。操作したカウンタ値は、本来のエラーカウンタとは別の領域に保存する。エラーカウンタの操作方法は、ステップ４５０と同様である。

次のステップ９５０は、ステップ４７０のノード障害通知と同様である。ノード障害通知を終えると、処理を終了する。

図９のフロー内で行うカウンタ値送信対象選択では、処理対象ノードをローテーションする方が、ノード障害発生時にその影響を局所的にすることができる。図１０は処理対象ノードの変更スケジュールの一例を示している。スケジュール１０００にて、ノード１を処理対象とするノードは、通信サイクルｉにてノード２，ノード３，ノード４，通信サイクルｉ＋１にてノード３，ノード４，ノード５と変わり、通信サイクルｉ＋ｎ−１にてノードｎ，ノード２，ノード３、通信サイクルｉ＋ｎにてノード２，ノード３，ノード４と一周し、以下繰り返す。

スケジュール１０００では、ある通信サイクルにて全てのノードが、３ノードからカウンタ値送信対象選択の処理対象となるように振り分けられている。これにより、同期カウンタ値の計算方法として、多数決を用いることができる。スケジュール１０００は、メモリなどの記憶装置にテーブルとして保持しておいてもよいし、簡単な数式で計算することも可能である。

図１１は、相互監視のアルゴリズムとして図４の処理フローを用い、エラーカウンタ送信同期を併用したノード間相互監視処理の動作例を示す。

エラーカウンタ送信同期処理（ステップ９４０）において、カウンタ値送信対象選択（ステップ２２０）では、図１０のように複数ノードを通信サイクルごとにローテーションして選択し、エラーカウンタ同期条件（ステップ２４０）としては、エラーカウンタ同期条件３が成立することとし、同期カウンタ値計算（ステップ２４０）の方法としては、受信したカウンタ値から多数決を取る、としている。これにより、障害特定とエラーカウンタ送信同期とを合理的に、また非常に高信頼に実行できる。

それ以外の障害監視項目などの設定は、特記がない限り、実施例１と同じである。ただしエラーカウンタは多数派異常と少数派異常とに分けておらず、エラーカウンタＥ１＿ｊ、Ｅ２＿ｊは多数派異常と少数派異常のどちらかが特定されれば、インクリメントされ、どちらも特定されないと、値が保持されるとする。

通信サイクルｉでは、ノード１〜４は順にスロット１〜４にて、前サイクル分の障害監視結果及びカウンタ仮値を送信し（１１０１−１〜１１０４−１，１６進数表示）、他ノードが受信して保持する（１１２１−０〜１１２４−０，１６進数表示）。カウンタ仮値に関しては、自ノード以外の３ノードを対象とし、１ノードについて通番異常の値（ＥＣ１）と受信異常の値（ＥＣ２）とを用意し、送信データにおいて障害監視結果の後ろに、ノード番号順に並べている。例えば、ノード２が送信するデータでは、ノード１分，ノード３分，ノード４分の順で並んでいる。

各ノードともノード３分のＥＣ１を９、それ以外を０としている。このため、エラーカウンタ同期処理にて、各ノードのＥ１＿３は９のままとなり、それ以外のカウンタ値は０のままとなる（１１４１−０〜１１４４−０）。

また、本通信サイクルにおいては、ノード３は送信前にＣＰＵ障害を起こしており、送信データ中の通番がインクリメントされず、ノード３以外のノードでは、障害監視（ＭＯＮ）にてノード３について通番異常を検出する（１１１１−０，１１１２−０，１１１４−０）。ノード３は自ノードについて異常を検出していない（１１１３−０）。集約した通信サイクルｉ分の障害監視結果（１１２１−０〜１１２４−０）に過半数を超える異常検出項目がないので、特定される障害は無い（１１３１−１〜１１３４−１、表記方法は障害監視結果と同じ）。ノード障害フラグは立たない（１１５１−０〜１１５４−０，３進数表記）。

ノード障害フラグは、１ノードについて、障害特定条件１による通番異常を示すビット、受信異常を示すビット、の２ビットで表され、それがノード１〜４まで順に並んでいるものとする。

通信サイクルｉ＋１では、ノード４がスロット１〜３に渡って受信障害を起こしている。ノード４は障害監視（ＭＯＮ）にてノード１〜３についての受信障害を検知する（１１１４−１）が、それ以外のノードは障害を検知していない（１１１１−１〜１１１３−１）。

本通信サイクルにおける障害特定（ＩＤ）処理については、ノード１〜３にて、集約した障害監視結果（１１２１−１〜１１２３−１）のうちノード３の通番異常を示すデータが過半数となるため、ノード３の通番異常（多数派異常）が特定される。ノード４は他ノードからデータを受信できていないため、障害特定（ＩＤ）の多数決処理が実行できず、障害を特定できていない（１１２４−１）。

エラーカウンタについては、各ノードともノード３分のＥＣ１を９、それ以外を０としている。このためエラーカウンタ同期処理にて、ノード１〜３では、Ｅ１＿３は９のままとなり、それ以外のカウンタ値は０のままとなる（１１４１−１〜１１４３−１）。ノード４ではエラーカウンタ同期が取れないので、Ｅ１＿３は９のまま、それ以外のカウンタ値は０のままとなる（１１４４−１）。

通信サイクルｉ＋２での各ノードの送信データは、障害監視結果については、ノード１〜３は障害を報告していない（１１０１−２〜１１０３−２）が、ノード４はノード１〜３の受信異常を報告している（１１０４−２）。また、送信データに含まれるカウンタ仮値については、ノード１，２ではノード３分のＥＣ１を、前通信サイクルにおける障害特定（ＩＤ）結果を反映してインクリメントした１０（０ｘａ）としている（１１０１−２，１１０２−２）。一方、ノード４ではノード３分のＥＣ１が、前通信サイクルにて障害特定（ＩＤ）ができなかったので、前通信サイクルの値である９のままとなっている（１１０４−２）。ノード３の送信データのカウンタ仮値には、ノード３分が含まれないので、すべて０となっている（１１０３−２）。

本通信サイクルにおける障害特定（ＩＤ）処理では、各ノードにて、集約した障害監視結果（１１２１−２〜１１２４−２）から、ノード４の受信異常（少数派異常）が特定される（１１３１−２〜１１３４−２）。この障害特定結果は、次通信サイクルに送信されるカウンタ仮値に反映される。

エラーカウンタについては、ノード３分のＥＣ１について、２つのノードが１０、１つのノードが９というデータが集約されるため（図１１にデータ構造の描写なし）、多数決により各ノードのＥ１＿３は１０（０ｘａ）に同期される（１１４１−２〜１１４４−２）。各ノードにてカウンタ値Ｅ１＿３が閾値である１０以上となったため、これを受けノード３の通番異常を示すノードフラグが有効となり、制御アプリケーションに障害通知がなされる（１１５１−２〜１１５４−２）。

以上により、非常にロバスト性，信頼性の高い障害特定とエラーカウンタ同期とを同時に実現することができる。

図９のフローは、各ステップの処理内容を変更して実施することも可能である。以下では本実施例における、各ステップの処理の修正内容を説明する。

ステップ９２０では、各ノードは自ノードの障害監視（ＭＯＮ）結果から、ステップ２１０のエラーカウンタ仮操作を先に行ってしまい、そのカウンタ仮値をステップ９３０にて障害監視結果として交換する。このステップ９３０は、ステップ２３０のエラーカウンタ交換を兼ねている。ステップ９３０の障害特定（ＩＤ）と、ステップ９４０のエラーカウンタ同期を、各ノードから受信するカウンタ仮値の多数決（もしくは中央値を取るなど）によって纏めて実行する。すなわち、エラーカウンタ同期によるカウンタ値のインクリメントは、障害が特定されたことを意味し、カウンタ値のデクリメントや保持は障害が特定されなかったことを意味する。ステップ９４０では、図２のフローのうち、ステップ２４０のエラーカウンタ同期条件判断・実行だけが行われることになる。

以上のような処理を行うことで、エラーカウンタ同期までのサイクルを、実施例２より１つ短くすることができる。

以下では、上記の図９の修正フローを用いたノード間相互監視処理の動作例を、図１２に示し、解説する。障害監視項目などの設定は、特記がない限り、実施例２と同じである。

通信サイクルｉでは、ノード１〜４は順にスロット１〜４にて、前サイクル分の障害監視（ＭＯＮ）結果を反映したカウンタ仮値を送信し（１２０１−１〜１２０４−１，１６進数表示）、他ノードが受信して保持する（１２２１−０〜１２２４−０，１６進数表示）。カウンタ仮値に関しては、自ノード以外の３ノードを対象とし、１ノードについて通番異常の値（ＥＣ１）と受信異常の値（ＥＣ２）とを用意し、送信データにおいてノード番号順に並べている。例えば、ノード２が送信するデータでは、ノード１分，ノード３分，ノード４分の順で並んでいる。他ノードから受信するカウンタ仮値（１２２１−０〜１２２４−０）では、これに自ノードを分を加え（ｘｘで表示）、ノード順に並べている。

各ノードともノード３分のＥＣ１を８、それ以外を０としている。このため、エラーカウンタ同期処理にて多数決を取ると（１２３１−０〜１２３４−０）、各ノードのＥ１＿３は８のままとなり、それ以外のカウンタ値は０のままとなる（１２４１−０〜１２４４−０）。ノード障害フラグは立たない（１２５１−０〜１２５４−０，３進数表記）。

また、本通信サイクルにおいては、ノード３は送信前にＣＰＵ障害を起こしており、送信データ中の通番がインクリメントされず、ノード３以外のノードでは、障害監視（ＭＯＮ）にてノード３について通番異常を検出する（１２１１−０，１２１２−０，１２１４−０）。ノード３は自ノードについて異常を検出していない（１２１３−０）。

通信サイクルｉ＋１での送信データでは、ノード１，２，４については、前通信サイクルでの障害監視（ＭＯＮ）におけるノード３に対しての通番異常検出をノード３分のＥＣ１に反映し、インクリメントして９としている（１２０１−１，１２０２−１，１２０４−１）。それ以外のカウンタ仮値は０であり、ノード３が送信するカウンタ仮値もすべて０となっている（１２０３−１）。ただしノード４はスロット１〜３にて受信障害を起こしており、ノード１〜３に対して受信異常を検出する（１２１４−１）。また、ノード３はデータ送信前再びＣＰＵ障害を起こし、ノード１，２はノード３に対して通番異常を検出する（１２１１−１，１２１２−１）。

本通信サイクルのエラーカウンタ同期処理にて多数決を取ると（１２３１−１，１２３２−１，１２３４−１）、受信障害のノード３を除いて、各ノードのＥ１＿３は９となり、それ以外のカウンタ値は０のままとなる（１２４１−１，１２４２−１，１２４４−１）。ノード３ではカウンタ仮値の多数決を取れず（１２３３−１）、Ｅ１＿３は８のままである（１２４３−１）。

通信サイクルｉ＋２での送信データでは、ノード１，２については、前通信サイクルでの障害監視（ＭＯＮ）におけるノード３に対しての通番異常検出をノード３分のＥＣ１に反映し、インクリメントして１０（０ｘａ）としている（１２０１−２，１２０２−２）。ノード４については、ノード１とノード２分のＥＣ２をインクリメントして１とし、ノード３分のＥＣ１は９のままとしている（１２０４−２）。ノード３については全カウンタ仮値が０である（１２０３−２）。障害は発生していないので、障害監視（ＭＯＮ）にて障害は検知されていない（１２１１−２〜１２１４−２）。

本通信サイクルのエラーカウンタ同期処理にて多数決を取ると（１２３１−２〜１２３４−２）、各ノードのＥ１＿３は１０（０ｘａ）となる。ノード４についてのカウンタ値は、単純な多数決では０と計算される。しかし、ノード４だけがノード１，２について受信異常を検出していることが、ノード４が送信するカウンタ仮値と多数決での０との比較から判定できるので、ノード４は少数派異常での受信異常とみなされ、Ｅ２＿４は多数決での０をベースに、インクリメントされた１となる。それ以外のカウンタ値は０のままとなる（１２４１−２〜１２４４−２）。

各ノードにてＥ１＿３が閾値である１０以上となったため、これを受けノード３の通番異常を示すノードフラグが有効となり、制御アプリケーションに障害通知がなされる（１２５１−２〜１２５４−２）。

以上により、非常にロバスト性，信頼性の高い障害特定とエラーカウンタ同期とを同時に実現することができる。また、それらを短周期にて実行可能となる。

分散システムを応用した制御システムは、自動車や建機、ＦＡ（Factory Automation）などの幅広い工業分野に関して、それらの分散型制御システムに本発明を適用することで、システムの信頼性を高く維持しつつ、可用性を高めることができるようになる。

分散システムの構成図。 エラーカウンタ送信同期のフロー図。 エラーカウンタ同期条件判定・実行処理の詳細フロー図。 ノード間相互監視による障害特定処理のフロー図。 処理対象ノードのスケジュール表。 ノード間相互監視処理の動作例。 ノード間相互監視処理の動作例。 ノード間相互監視処理の動作例。 ノード間相互監視による障害特定処理のフロー図。 処理対象ノードのスケジュール表。 ノード間相互監視処理の動作例。 ノード間相互監視処理の動作例。

符号の説明

１０ ノード
１１ ＣＰＵ
１２ メインメモリ
１３ Ｉ／Ｆ
１４ 記憶装置
１００ ネットワーク

Claims (7)

1. 複数のノードがネットワークを介して接続される分散システムにおいて、
   前記複数のノードの各々は、
   他ノードに対する障害監視を行う障害監視部と、
   前記ネットワークを介して、他ノードの障害を検知するためのデータを送受信し、障害監視結果を交換する送受信部と、
   交換された前記障害監視結果に基づいて、どのノードに障害があるかを特定する障害特定部と、
   障害があると特定されたノードのエラーの数をカウントするカウンタ部と、
   エラーカウンタ値をノード間で交換し、エラーカウンタ同期条件が成立するときに同期を取るカウンタ同期部を備えることを特徴とする分散システム。
2. 請求項１のエラーカウンタ同期条件は、
   受信したエラーカウンタ値が、自ノードのカウンタ値と比較して差が指定範囲内にあることを特徴とする分散システム。
3. 請求項２の分散システムは、
   交換するエラーカウンタ値の対象ノードを障害特定のサイクルに合わせてローテーションすることを特徴とする分散システム。
4. 請求項１の分散システムは、
   エラーカウンタがリセット状態のときに、エラーカウンタ同期条件が不成立であっても、エラーカウンタを仮同期し、その後、エラーカウンタ同期条件が指定回数連続して成功すれば同期を確定することを特徴とする分散システム。
5. 請求項１の分散システムは、
   エラーカウンタ同期条件が指定回数連続して不成立となる場合には、エラーカウンタをリセット状態にすることを特徴とする分散システム。
6. 請求項１の分散システムは、
   エラーカウンタを同期させる値として受信するカウンタ値の多数決結果とし、エラーカウンタ同期条件として前記多数決が成立することを特徴とする分散システム。
7. 請求項１の分散システムは、
   前記カウンタ同期部の交換するカウンタ値が、前記障害特定結果ではなく、前記障害監
   視結果を反映したエラーカウンタ値であることを特徴とする分散システム。

Images