(57)【要約】【課題】  分散システムでは、障害を高信頼に特定し、また障害発生状況に関する認識をノード間で一致させるために、ノード間での相互監視を用いて障害特定を行う。この処理は通信サイクルに同期して実施されるが、毎通信サイクルほど頻繁に障害特定を行う必要のないシステムでは、障害特定の頻度を下げ、単位時間あたりのＣＰＵ処理負荷や通信帯域の消費を減らしたい。【解決手段】  複数ノードがネットワークを介して接続される分散システムは、複数ノードの各々は、他ノードに対する障害監視を行う障害監視部と、ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、データに基づいて、どのノードに障害があるかを特定する障害特定部を備え、障害監視部は監視対象期間としてノード間で同期した１ないし複数の通信サイクルを取ることができる。【選択図】図１
2010011093.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードがネットワークを介して接続される分散システムにおいて、
前記複数のノードの各々は、
他ノードに対する障害監視を行う障害監視部と、
前記ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、
前記データに基づいて、どのノードに障害があるかを特定する障害特定部を備え、
前記障害監視部は、監視対象期間としてノード間で同期した通信サイクルを取ることができること特徴とする分散システム。
【請求項２】
請求項１の分散システムにおいて、
前記送受信部は、前記障害監視部の監視結果を送受信データに含め、その送受信を、前期監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とする分散システム。
【請求項３】
請求項１の分散システムにおいて、
前記障害特定部は、障害特定を、前記データに含まれる前記障害監視部の監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とする分散システム。
【請求項４】
請求項１の分散システムにおいて、前記障害監視部は稼動中に、前記監視対象期間を監視対象ノードごとに可変とすることができることを特徴とする分散システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにより結合された複数の装置が協調動作して、高信頼な制御を行う分散システムに関する。
【背景技術】
【０００２】
近年、自動車の運転快適性や安全性の向上を目指して、機械的な結合ではなく、電子制
御により、運転者のアクセル，ステアリング，ブレーキなどの操作を車両の駆動力，操舵力，制動力発生機構などに反映させる車両制御システムの開発が行われている。建機など他の機器でも同様な電子制御の適用が進められている。これらシステムでは、機器に分散配置した複数の電子制御装置（ＥＣＵ：Electronic Control Unit）がネットワークを介してデータをやり取りして協調動作を行う。この際、同一ネットワーク内のあるＥＣＵに障害が発生した際に、各ＥＣＵが障害発生箇所を正確に特定し、障害内容に応じた適切なバックアップ制御を行うことが、フェールセーフ上必要不可欠となる。上記課題を解決するために、システムを構成する各ノード（ＥＣＵなどの処理主体）がネットワーク内の他ノードの状態を監視する技術がある（特許文献１参照）。
【０００３】
【特許文献１】特開２０００−４７８９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１によれば、データベースアプリケーションの稼動状態などに関する監視情報を各ノードで相互に共有するための特別なノード（共有ディスク）が必要になり、この共有ディスクが故障するとシステム内の障害ノード監視を継続することができなくなってしまう。また、共有ディスクを設けることにより、システムのコストが増加することが懸念される。
【０００５】
その課題を解決するために、以下のような方法が考えられる。あるノードのある項目について、各ノードが単独で障害を検出するための監視を行い、その障害監視結果を、ネットワークを通してノード間で交換し、各ノードに集約された障害監視結果から多数決などにより、最終的な障害の特定を行う。これらの処理は通信サイクルに同期して実施する。また、上記の障害監視，障害監視結果交換，障害特定の各処理を、パイプライン的に実行し、毎通信サイクルにて障害特定を可能にする。
【０００６】
しかしシステムによっては、毎通信サイクルでの障害特定が頻度過剰な場合もある。そこで本発明の目的は、障害監視と通信の周期を別々に設定できるようにすることで、障害監視のためのＣＰＵ（Central Processing Unit）処理負荷や通信帯域を低減し、または障害監視の周期設定の自由度を上げることができる分散システムを提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を達成するために、本発明では複数のノードがネットワークを介して接続される分散システムにおいて、前記複数のノードの各々は、他ノードに対する障害監視を行う障害監視部と、前記ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、前記データに基づいて、どのノードに障害があるかを特定する障害特定部を備え、前記障害監視部は、監視対象期間としてノード間で同期した通信サイクルを取ることができることを特徴とするものである。
【０００８】
更に、本発明の分散システムにおいて、前記送受信部は、前記障害監視部の監視結果を送受信データに含め、その送受信を、前記監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とするものである。
【０００９】
更に、本発明の分散システムにおいて、前記障害特定部は、障害特定を、前記データに含まれる前記障害監視部の監視結果が対象とする次の監視対象期間にて分散して行うことを特徴とするものである。
【００１０】
更に、本発明の分散システムにおいて、前記障害監視部は稼動中に、前記監視対象期間を監視対象ノードごとに可変とすることができることを特徴とするものである。
【発明の効果】
【００１１】
本発明によれば、障害監視のためのＣＰＵ処理負荷や通信帯域が低く、または障害監視の周期設定の自由度が高い分散システムを提供することが実現できる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の一実施例を図面を用いて説明する。
【実施例１】
【００１３】
図１は、分散システムの構成図である。
【００１４】
分散システムは、複数のノード１０（１０−１，１０―２，…，１０−ｎ）からなり、これらは、ネットワーク１００を介して接続される。ここで、ノードとは、ネットワークを介して情報通信可能な処理装置であり、ＣＰＵを含む各種の電子制御装置，アクチュエータとそのドライバ，センサ等が含まれる。ネットワーク１００は多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して、同一内容を同時に送信するブロードキャスト送信が可能である。通信プロトコルとしては、FlexRayやＴＴＣＡＮ（time-triggered ＣＡＮ）などを用いることができる。
【００１５】
各ノードｉ（ｉはノード番号，ｉ＝１〜ｎ）は、ＣＰＵ１１−ｉ，主メモリ１２−ｉ，Ｉ／Ｆ１３−ｉ、及び、記憶装置１４−ｉとからなり、これらは内部通信線等により接続されている。又、Ｉ／Ｆ１３−ｉは、ネットワーク１００と接続されている。
【００１６】
記憶装置１４−ｉは、障害監視部１４１−ｉ，送受信処理部１４２−ｉ，障害特定部１４３−ｉ、及び、カウンタ部１４４−ｉ等のプログラム、並びに、障害特定結果１４５−ｉを格納する。障害特定結果１４５−ｉは、後述の監視結果集約表，障害特定結果表，エラーカウンタを含む。
【００１７】
ＣＰＵ１１−ｉは、これらのプログラムを主メモリ１２−ｉに読み込み、実行することにより、処理を行う。本稿で説明するプログラムやデータは、予め記憶装置に格納しておいてもよいし、ＣＤ−ＲＯＭ等の記憶媒体から入力してもよいし、ネットワーク経由で他の装置からダウンロードしてもよい。又、当該プログラムにより実現される機能を、専用のハードウェアにより実現してもよい。
【００１８】
以下では、プログラムを主体として記載するが、実際の主体はＣＰＵがプログラムに従って視処理している。
【００１９】
障害監視部１４１−ｉは、他ノードに対する障害監視（ＭＯＮ）を行う。送受信処理部１４２−ｉは、ネットワーク１００を介して、他ノードの障害を検知するためのデータを送受信する。障害特定部１４３−ｉは、他ノードの障害を検知するためのデータに基づいて、どのノードに障害があるかの障害特定（ＩＤ）を行う。カウンタ部１４４−ｉは、障害があると特定されたノードのエラーの数を、ノード毎，エラー箇所（エラー項目）毎，後述の障害特定条件毎にカウントする。
【００２０】
図２は、ノード間相互監視による障害特定処理のフロー図を示す。これらの処理は、各ノードが、ネットワーク１００を介して互いに通信しながら同期を取ることにより行う。
【００２１】
まずステップ２１にて、障害監視部１４１−ｉは、他ノードに対する障害監視を行い、受信データの内容や受信時の状況から、送信ノードについての障害有無を自ノード単独で判断する障害監視処理（以下、ＭＯＮ）を行う。障害監視の対象項目（以下、障害監視項目）は、複数設定してもよい。例えば「受信異常」という項目では、未受信や誤り検出符号による受信データ異常を発見するなど、データ受信にエラーのあるときに異常ありとする。「通番異常」という項目では、送信ノードはアプリケーションが通信サイクル毎にインクリメントする通番を送受信データに付加し、受信ノードが通番のインクリメントを確認し、インクリメントされていないときに異常ありとする。通番は送信ノードのアプリケーション異常を確認するための番号である。「自己診断異常」という項目では、各ノードが自ノードの異常有無について自ら診断した結果（以下、自己診断結果）を、他ノードに対して送信し、受信ノードが自己診断結果から、送信ノードについての異常を検知する。これら複数の障害監視項目のうち、いずれかの項目で異常があれば、それら項目を１つに統合した障害監視項目で「異常あり」としてもよい。
【００２２】
障害監視処理は、ｐ（ｐ＝１，２，３，．．）通信サイクルを対象期間の１単位として実施される。ｐ通信サイクルの障害監視期間は、ノード間で同期が取られる。同期の取り方は、あるノードが障害監視処理の開始を通信にて宣言してもよい。また、通信サイクル数から監視期間を求めてもよい。例えば最初の障害監視を通信サイクル０から開始すると決めておくならば、（通信サイクル数）÷  ｐで余りのない通信サイクル数のとき、各障害監視期間の始まりとわかる。障害監視処理期間を複数通信サイクルにすることで、以降の処理の頻度を低減することができ、１通信サイクルあたりの通信帯域や各ノードのＣＰＵ処理負荷を低減することができる。
【００２３】
次にステップ２２にて、送受信処理部１４２−ｉは、ステップ２１で得られた障害監視結果を、各ノード間で交換する、障害監視結果交換処理（以下、ＥＸＤ）を行う。各ノードは自ノードにて出した結果を含む、全ノードからの障害監視結果を保持することになる。集約した障害監視結果は、障害特定結果１４５−ｉに監視結果集約表として持つ。
【００２４】
障害監視結果交換処理は、１通信サイクルで行ってもよいし、複数の通信サイクルに分けて行ってもよい。複数の通信サイクルに分けると、１通信サイクルあたりに必要な通信帯域と、各ノードのＣＰＵによる受信データ処理負荷を低減することができる。
【００２５】
次にステップ２３にて、障害特定部１４３−ｉは、ステップ２２で各ノードに集約された障害監視結果から、各ノード・各障害監視項目について異常有無を特定する、障害特定処理（以下、ＩＤ）を行う。障害特定結果は、障害特定結果１４５−ｉに障害特定結果表として持つ。
【００２６】
障害特定方法の一つとして、多数決主体の方法がある。これは、異常有無の多数決を取り、あるノード・障害監視項目に対して障害を検出したノード数が、「＜障害特定条件１＞閾値以上ならば、被検出ノードに異常あり」と判断し、「＜障害特定条件２＞閾値未満ならば、障害を検出したノードに異常あり」と判断する。閾値は通常、集約された障害監視結果の半数である。
【００２７】
尚、障害特定条件１で障害を検出しなかったノードや、障害特定条件２の被検出ノードについては、異常なしと判断する。以下では、障害特定条件１に合致した場合には多数派異常、障害特定条件２に合致した場合には少数派異常と呼ぶ。
【００２８】
障害特定方法としてはこのほか、１ノードでも障害を検出したら、被検出ノード・障害監視項目について「異常あり」と判断する方法もある。
【００２９】
障害特定処理は、１通信サイクルのうちに行ってもよいし、複数の通信サイクルに分けて行ってもよい。複数の通信サイクルに分けると、１通信サイクルあたりの各ノードのＣＰＵ処理負荷を低減することができる。
【００３０】
次にステップ２４にて、各ノードが障害特定結果利用処理を行う。カウンタ部１４４−ｉは、ステップ２３で「異常あり」と判定された場合、障害特定の対象ノード・監視項目のエラー数を示すエラーカウンタ値をインクリメントする。逆に「異常なし」と判定された場合、当該カウンタ値をデクリメントする。尚、デクリメントに限らず、リセットしてもよいし、何もしなくてもよい。デクリメント，リセット，何もしない、の選択は事前に設定する。また、エラーカウンタは障害特定条件ごとに用意してもよい。この場合、エラーカウンタをデクリメントもしくはリセットするのは、どの障害特定条件にも合致しないときである。
【００３１】
そして、カウンタ部１４４−ｉは、エラー数が指定の閾値以上となった場合、障害発生の事実を制御アプリケーションに通知する。通知手段の１つには、障害特定の対象ノード・監視項目に対応するノード障害フラグを立てる方法がある。アプリケーションはノード障害フラグを参照することにより、障害発生状況を知ることができる。また、ノード障害フラグを立てた後、制御アプリケーションに対して割込みを掛けるか、コールバック関数を呼ぶことにより、通知が即座になされるようにしてもよい。エラーカウンタを障害特定条件で分けるとき、ノード障害フラグも障害特定条件で分ける。
【００３２】
障害特定処理を複数通信サイクルに分ける場合、障害特定結果利用処理を行う時機としては、全ての障害特定処理が終わってからでもよいし、一部の障害特定処理が終わればその結果を逐次利用してもよい。全ノードで障害発生状況に対する認識や、それに伴う状態遷移を一致させたいならば、前者を取るべきである。
【００３３】
以上の処理により、障害発生を高信頼に特定し、障害発生状況に関する認識をノード間で一致化させることができる。その際に、各処理を複数の通信サイクルに分散して実施することで、１通信サイクルあたりのＣＰＵ処理負荷や必要な通信帯域を抑えることができる。
【００３４】
そして、図２の処理を繰り返し実行する際は、各処理を並列に行ってもよい。図２の処理を１回実行する機会（以下、障害特定ラウンド）として、複数の障害特定ラウンドを平行して行うようにすればよい。
【００３５】
図３と図４は、４ノードのシステムにおける、図２の処理フローに基づいたノード間相互監視による障害特定の並列処理の一例である。
【００３６】
図３では、障害特定ラウンド１として、通信サイクルｉ〜ｉ＋１で障害監視（ＭＯＮ）を行い（ｒ＝２）、障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）は通信サイクルｉ＋２〜ｉ＋３に分散して実施している。この際、各ノードは通信サイクルｉ＋２ではノード１〜２について、通信サイクルｉ＋３ではノード３〜４について監視結果を交換（ＥＸＤ）し、その監視結果から障害特定（ＩＤ）している。このように、図３は障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）の処理を、対象ノードごとに分割し、通信サイクル間で分散している。
【００３７】
各ノードは障害特定ラウンド１を実施する一方で、障害特定ラウンド２以降を実施している。通信サイクルｉ＋２〜ｉ＋３では、障害特定ラウンド１の障害監視結果交換（ＥＸＤ）を実施すると同時に、障害監視結果交換（ＥＸＤ）の受信データ内容やデータ受信状況から、障害特定ラウンド２の障害監視（ＭＯＮ）を実施している。同様に、障害特定ラウンド２の障害監視結果交換（ＥＸＤ）と同時に、障害特定ラウンド３の障害監視（ＭＯＮ）を実施している。障害特定（ＩＤ）はその合間になされている。以下同様に、このような処理を繰り返す。障害特定（ＩＤ）結果の利用は、ノード１〜２から先に行ってもよいし、ノード３〜４の結果が出てから全ノード分を利用してもよい。
【００３８】
図４では、障害特定ラウンド１として、通信サイクルｉ〜ｉ＋１で障害監視（ＭＯＮ）を行い、障害監視結果交換（ＥＸＤ）は通信サイクルｉ＋２〜ｉ＋３に、障害特定（ＩＤ）は通信サイクルｉ＋３〜ｉ＋４に分散して実施している。この際、通信サイクルｉ＋２ではノード１〜２が、通信サイクルｉ＋３ではノード３〜４が、障害監視（ＭＯＮ）結果を送信している。障害特定（ＩＤ）は、通信サイクルｉ＋３ではノード１〜２について、通信サイクルｉ＋４ではノード３〜４について為されている。このように、図３と異なる点は、障害監視結果交換（ＥＸＤ）の処理を、送信ノードごとに分割し、通信サイクル間で分散している点である。
【００３９】
各ノードは障害特定ラウンド１を実施する一方で、障害特定ラウンド２以降を実施している。通信サイクルｉ＋２〜ｉ＋３では、障害特定ラウンド１の障害監視結果交換（ＥＸＤ）を実施すると同時に、障害監視結果交換（ＥＸＤ）の受信データ内容やデータ受信状況から、障害特定ラウンド２の障害監視（ＭＯＮ）を実施している。障害特定ラウンド２と障害特定ラウンド３の関係も同様であり、以下このような処理を繰り返す。
【００４０】
図３や図４のように、図２のノード間相互監視による障害特定処理を、パイプライン的に実施することで、すべての時間（通信サイクル）が障害監視（ＭＯＮ）の対象となり、また障害特定（ＩＤ）を一定間隔で継続的に行うことができる。
【００４１】
図３と図４ではノード数４（ｎ＝４）を想定しているが、ノード数に制限はない。また、図３と図４では障害監視（ＭＯＮ）の対象期間を２通信サイクルに、障害監視結果交換（ＥＸＤ）、障害特定（ＩＤ）の各処理を２通信サイクルに分けて行っているが、これらを１通信サイクルとしても、より長い通信サイクルとしてもよい。各処理に掛かる通信サイクル数を短くすれば、障害特定（ＩＤ）までに掛かる時間（通信サイクル数）は短くなるが、ＣＰＵ処理負荷や消費する通信帯域が相対的に増大する。逆に各処理に掛かる通信サイクル数を長くすれば、障害特定（ＩＤ）までに掛かる時間（通信サイクル数）は長くなるが、ＣＰＵ処理負荷や消費する通信帯域が相対的に減少する。
【００４２】
例えば、図３でノード数を６とする場合、最初の障害特定ラウンドでは通信サイクルｉ＋２にてノード１〜３を対象に、通信サイクルｉ＋３にてノード４〜６を対象に、障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）を実施してもよい。もしくは通信サイクルｉ＋４にてノード５〜６を対象とする障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）を追加してもよい。
【００４３】
障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）の通信サイクル間における分散（以下、時間軸処理分散）のさせ方は、各通信サイクルにてＣＰＵ処理負荷や通信量が均等になるようにするのが、ＣＰＵ処理能力や通信帯域といったリソースの面から制御アプリケーションに対する影響が相対的に小さくなり、好ましいと考えられる。図３と図４は、このような均等な分散の一例である。
【００４４】
時間軸処理分散のさせ方として、図３と図４では障害監視対象ノードごと、障害特定対象ノードごと、送信ノードごと、などのように分けているが、各ノードが各通信サイクルにて処理の一部ずつを行うのであれば、どのような分け方をしてもよい。例えば図４にて、各ノードは通信サイクルｉ＋２にてノード１とノード２から受信する障害監視結果から、多数決を取るための集計を行うなど、障害特定（ＩＤ）の一部を行い、通信サイクルｉ＋３にてノード３とノード４から受信する障害監視結果から、障害特定（ＩＤ）の残りの処理を行い、障害特定処理を完了させてもよい。このようにすれば、障害特定処理の完了までに掛かる通信サイクル数が、図４より１つ短くなる。
【００４５】
図５は、ノード間相互監視による障害特定処理の動作例を示す。処理フローは図２に基づき、時間軸処理分散や処理パイプライン化は、図３に則っており、ノード数は４とする。ここでは、障害監視項目として各種の項目を１つに統合している。尚、障害特定処理（ＩＤ）は、各ノードの送受信終了後、通信サイクルの最後に行われるものとする。
【００４６】
送信データは、１監視対象ノードについて異常有無を示すビットを２ノード分持つ。但し、自ノード分の領域には、自ノードについての診断結果が入っている。偶数サイクルではノード１〜２について、奇数サイクルではノード３〜４についての異常有無が入るとする。
【００４７】
また送信データには、各ノードが持つエラーカウンタの値が１ノード分入る。通信サイクルｉ〜ｉ＋１ではノード１がノード２について、ノード２がノード３について、ノード３がノード４について、ノード４がノード１についてのエラーカウンタ値を送信している。これが通信サイクルｉ＋２〜ｉ＋３ではノード１がノード４について、ノード２がノード１について、ノード３がノード２について、ノード４がノード２についてのエラーカウンタ値を送信するようになり、対象ノードをローテーションさせている。また、エラーカウンタは多数派異常と少数派異常とで分かれており、偶数サイクルでは多数派異常数（ＥＣ）が、奇数サイクルでは少数派異常数（ＦＣ）が送信されている。
【００４８】
エラーカウンタ値を受信したノードは、障害特定結果利用処理において、障害特定（ＩＤ）の結果をエラーカウンタに反映する前に、受信したエラーカウンタ値を利用して、エラーカウンタのノード間同期を取る。これは、ノード間相互監視による障害特定処理を行っても、ノード間でエラーカウンタ値がずれてしまう場合があるためである。その理由は、自ノード診断によるリセットや、一時的な通信不能などによる。エラーカウンタ同期の方法は例えば、受信したカウンタ値が自ノードの持つカウンタ値と異なっており、連続して受信した２つのカウンタ値の差が一定値（例えば±１）以内であれば、後に受信したカウンタ値に自ノードのカウンタ値を合わせる、とすればよい。
【００４９】
送信データは内容の一部のみが表示されている。送信データは上記データのほかに、通番や制御データなど含みうる。
【００５０】
通信サイクルｉ（ｉは偶数とする）では、ノード１〜４は順にスロット１〜４にて、障害特定ラウンドｋ−１のノード１〜２に関する障害監視結果を送信し（ＥＸＤ，５０１−０〜５０４−０）、他ノードから受信した分と自ノードで出した結果とを保持する（５２１−０〜５２４−０、２進数表示）。その中には「異常あり」とするデータがなく、各ノードも正常受信をしているため、障害特定ラウンドｋ−１のノード１〜２に関する障害特定（ＩＤ）では異常は見つからず、ノード障害フラグはどのノードについても立っていない（５５１−０〜５５４−０、２進数表示）。また、各ノードは障害特定ラウンドｋの障害監視（ＭＯＮ）にて障害を検出していない（５１１−０〜５１４−０、２進数表示）。各ノードのエラーカウンタ値は、ノード３の多数派異常について２であり、それ以外は０となっており、通信サイクルｉ−１から変化がない（５４１−０〜５４４−０）。
【００５１】
ただし、通信サイクルｉの終わりにて、ノード３がＣＰＵ障害を起こしている。これにより、ノード３が次の通信サイクルｉ＋１にて送信する通番をインクリメントできない障害が発生したとする（通番は図のデータには表記されていない）。
【００５２】
通信サイクルｉ＋１では、障害特定ラウンドｋ−１のノード３〜４に関する障害監視結果を送信し（５０１−１〜５０４−１）、各ノードが保持する（５２１−１〜５２４−１）。通信サイクルｉと同様に、障害特定ラウンドｋ−１のノード３〜４に関する障害特定（ＩＤ）では異常は見つからず、エラーカウンタ（５４１−０〜５４４−０）とノード障害フラグ（５５１−１〜５５４−１）は通信サイクルｉと変わらない。しかし、障害特定ラウンドｋのノード３〜４に関する障害監視（ＭＯＮ）にて、ノード１，２，４はノード３の通番異常から、ノード３について障害を検出する（５１１−１，５１２−１，５１４−１）。ノード３は自ノードの異常を検出できない（５１３−１）。
【００５３】
通信サイクルｉ＋２ではノード１〜２に関して、通信サイクルｉ＋３ではノード３〜４に関して、それぞれ障害特定ラウンドｋの障害特定結果交換（ＥＸＤ）と障害特定（ＩＤ）、および障害特定ラウンドｋ＋１の障害特定（ＭＯＮ）がなされる。通信サイクルｉ＋２では、通信サイクルｉと同様に異常は検出されない。それに対し通信サイクルｉ＋３では、障害特定ラウンドｋの障害特定結果交換（ＥＸＤ）で、通信サイクルｉ＋１におけるノード３の障害検出が交換され（５０１−３〜５０４−３，５２１−３〜５２４−３）、各ノードの障害特定（ＩＤ）にてノード３の多数派異常が特定される（５３１−３〜５３４−３）。これにより、各ノードが持つノード３の多数派異常に関するエラーカウンタ値がインクリメントされ、３になる（５４１−３〜５４４−３）。このシステムでは、障害のアプリケーション通知の閾値を３としており、各ノードが持つノード３の多数派異常に関するノード障害通知フラグが立つ（５５１−３〜５５４−３）。
【００５４】
以上により、各ノードにてノード３のＣＰＵ障害が特定され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。このように、図２のノード間相互監視による障害特定処理は、通信サイクルに同期してパイプライン的に実行することが可能であり、また時間軸処理分散により、通信サイクルあたりのＣＰＵ処理負荷や通信量は、時間軸処理分散をしないときより減少していることがわかる。上記では多数派異常を扱ったが、少数派異常についても同様である。
【実施例２】
【００５５】
図６は、ノード間相互監視による障害特定処理のフロー図を示す。
【００５６】
ステップ２１の障害監視処理（ＭＯＮ）とステップ２２の障害監視結果交換処理（図６ではＥＸＤ１とする）の内容は、図２と同様である。
【００５７】
次にステップ６１にて、障害特定部１４２−ｉは、相互監視に参加しているノードのうち、自ノード以外の１つを自ノードが障害特定の責任を持つノードとして、障害特定処理（以下、ＩＤ１）を行う。対象とするノードは、各ノードで重複がないようにし、通信サイクル毎にローテーションする。これにより、障害特定処理の負荷をノード間で分散して低減する。
【００５８】
次にステップ６２にて、送受信処理部１４２−ｉは、ステップ６１で得られた１ノードについての障害特定結果を、各ノード間で交換する、障害特定結果交換処理（ＥＸＤ２）を行う。これにより各ノードは、自ノードによる処理分を含む全ノードについての障害特定結果を保持することになる。この集約された障害特定結果を利用して、ステップ６３では障害特定処理（ＩＤ２）として、最終的な障害特定結果の確定を行う。
【００５９】
次のステップ２４は、図２の障害特定結果利用処理と同様である。
【００６０】
尚、障害特定条件１による判定は１ノードを対象に障害特定処理（ＩＤ１）にて行い、障害特定条件２による判定は全ノードを対象に障害特定処理（ＩＤ２）にて行えばよい。もしくは、障害特定処理（ＩＤ２）では１ノードを対象に障害特定条件２による判定を行い、その結果をノード間で交換（障害特定結果交換処理、ＥＸＤ３）してもよい。
【００６１】
また、障害特定処理（ＩＤ１）で対象とするノードは１つに限定せず、２つ以上でもよい。
【００６２】
図７と図８は、４ノードのシステムにおける、図６の処理フローに基づいたノード間相互監視による障害特定の並列処理の一例である。
【００６３】
図７では、障害特定ラウンド１として、通信サイクルｉ〜ｉ＋１で障害監視（ＭＯＮ）を行い、障害監視結果交換（ＥＸＤ１）と障害特定（ＩＤ１）は通信サイクルｉ＋２〜ｉ＋３に、障害特定結果交換（ＥＸＤ２）と障害特定（ＩＤ２）は通信サイクルｉ＋４〜ｉ＋５に分散して実施している。この際、各ノードは通信サイクルｉ＋２ではノード１〜２について、通信サイクルｉ＋３ではノード３〜４について監視結果交換（ＥＸＤ１）と障害特定（ＩＤ１）をしている。また、各ノードは通信サイクルｉ＋４では全ノードについて障害特定結果交換（ＥＸＤ２）と障害特定（ＩＤ２）をしている。このように、図７は障害監視結果交換（ＥＸＤ１），障害特定（ＩＤ１）の各処理を、対象ノードごとに分割して、通信サイクル間で分散している。
【００６４】
各ノードは障害特定ラウンド１を実施する一方で、障害特定ラウンド２以降を実施している。通信サイクルｉ＋２〜ｉ＋３では、障害特定ラウンド１の障害監視結果交換（ＥＸＤ１）を実施すると同時に、その受信データ内容やデータ受信状況から、障害特定ラウンド２の障害監視（ＭＯＮ）を実施している。また通信サイクルｉ＋４では、障害特定ラウンド１の障害特定結果交換（ＥＸＤ２）を実施すると同時に、障害特定ラウンド２のノード１〜２に関する障害監視結果交換（ＥＸＤ１）を行い、その受信データ内容やデータ受信状況から、障害特定ラウンド３の障害監視（ＭＯＮ）をも実施している。障害特定ラウンド２以降の関係も同様であり、以下このような処理を繰り返す。
【００６５】
図８では、障害特定ラウンド１として、通信サイクルｉ〜ｉ＋１で障害監視（ＭＯＮ）を行い、障害監視結果交換（ＥＸＤ１）と障害特定（ＩＤ１）は通信サイクルｉ＋２〜ｉ＋３に、障害特定結果交換（ＥＸＤ２）と障害特定（ＩＤ２）は通信サイクルｉ＋４〜ｉ＋５に分散して実施している。この際、各ノードは通信サイクルｉ＋２と通信サイクルｉ＋３では監視結果交換（ＥＸＤ１）と障害特定（ＩＤ１）の処理をそれぞれ半々行っている。半々とは、通信サイクルｉ＋２で監視結果交換（ＥＸＤ１）では障害監視結果の半分を送信し、障害特定（ＩＤ１）では多数決など障害特定のために行う障害監視結果の集計などの処理を、監視結果交換（ＥＸＤ１）で得たデータ分だけ途中まで進める。そして、通信サイクルｉ＋３で残りの処理を行う。また、各ノードは通信サイクルｉ＋４では多数派異常について、通信サイクルｉ＋５では少数派異常について、障害特定結果交換（ＥＸＤ２）と障害特定（ＩＤ２）をしている。このようにして、図７は障害監視結果交換（ＥＸＤ１），障害特定結果交換（ＥＸＤ２），障害特定（ＩＤ１，ＩＤ２）の各処理を、通信サイクル間で分散している。
【００６６】
各ノードは障害特定ラウンド１を実施する一方で、障害特定ラウンド２以降を実施している。通信サイクルｉ＋２〜ｉ＋３では、障害特定ラウンド１の障害監視結果交換（ＥＸＤ１）を実施すると同時に、障害特定ラウンド２の障害監視（ＭＯＮ）を実施している。また通信サイクルｉ＋４〜ｉ＋５では、障害特定ラウンド１の障害特定結果交換（ＥＸＤ２）を実施すると同時に、障害特定ラウンド２の障害監視結果交換（ＥＸＤ１）を行い、さらに障害特定ラウンド３の障害監視（ＭＯＮ）をも実施している。障害特定ラウンド２以降の関係も同様であり、以下このような処理を繰り返す。
【００６７】
図９−１及び図９−２は、ノード間相互監視による障害特定処理の動作例を示す。処理フローは図６に基づき、時間軸処理分散や処理パイプライン化は、図８に則っている。ノード数や障害監視項目などの諸条件は図５と同じである。
【００６８】
また障害特定（ＩＤ１）結果は、エラーカウンタ値に反映して、すなわち障害特定（ＩＤ１）結果に応じて増減して送信され、エラーカウンタ同期のためのカウンタ値送信と兼ねて、障害特定結果交換（ＥＸＤ２）としている。エラーカウンタ値を受信したノードは、エラーカウンタの同期方法として例えば、（１）受信したカウンタ値と自ノードの持つカウンタ値との差が一定値（例えば±１）であるとき、受信したカウンタ値に、（２）前記条件（（１））に合致せず、連続して受信した２つのカウンタ値の差が一定値（例えば±１）であれば、後に受信したカウンタ値に、自ノードのカウンタ値を合わせるとすればよい。
【００６９】
もちろん、このように障害特定（ＩＤ１）結果をエラーカウンタ値に反映するということをせず、送信データに障害特定（ＩＤ１）結果専用の領域を設けても良い。
【００７０】
通信サイクルｉ〜ｉ＋１（ｉは偶数とする）では、ノード１〜４は順にスロット１〜４にて、障害特定ラウンドｋ−１の障害監視結果を送信し（ＥＸＤ１，９０１−０〜９０４−０，９０１−１〜９０４−１）、他ノードから受信した分と自ノードで出した結果とを保持する（９２１−０〜９２４−０，９２１−１〜９２４−１）。通信サイクルｉでは、ノード１〜２はノード１〜２について、ノード３〜４はノード３〜４についての障害監視結果を送信し、通信サイクルｉ＋１では各ノードそれぞれの残りのデータを送信している。その中には「異常あり」とするデータがなく、各ノードも正常受信をしているため、通信サイクルｉ〜ｉ＋１で分割して実施され、通信サイクルｉ＋１で結果が得られる障害特定ラウンドｋ−１に関する障害特定（ＩＤ）では異常は見つからず（９３１−１〜９３４−１、括弧内の数値は担当ノード番号）、ノード障害フラグはどのノードについても立っていない（９５１−０〜９５４−０，９５１−１〜９５４−１）。障害特定ラウンドｋ−２の障害特定結果交換（ＥＸＤ２）と障害特定（ＩＤ２）も実施されるが、各ノードのエラーカウンタ値は、ノード３の多数派異常について２、それ以外は０となっており、通信サイクルｉ−１から変化がない（９４１−０〜９４４−０，９４１−１〜９４４−１）。
【００７１】
また、障害特定ラウンドｋ−１の障害監視結果交換（ＥＸＤ１）と平行して行われる障害特定ラウンドｋの障害監視（ＭＯＮ）にて、各ノードは通信サイクルｉでは障害を検出していない（９１１−０〜９１４−０）が、通信サイクルｉの終わりにおけるノード３のＣＰＵ障害により、ノード３は通番異常を来たし、通信サイクルｉ＋１にてノード１，２，４がノード３について障害を検出する（９１１−１〜９１４−１）。
【００７２】
通信サイクルｉ＋２〜ｉ＋３では、障害特定ラウンドｋの障害監視結果交換（ＥＸＤ１，９０１−２〜９０４−２，９０１−３〜９０４−３）を障害特定ラウンドｋ−１と同様に行う。これにより、通信サイクルｉ＋１でのノード３の障害検出を含む障害監視結果が各ノードに集約される（９２１−２〜９２４−２，９２１−３〜９２４−３）。障害特定ラウンドｋの障害特定（ＩＤ１）も障害特定ラウンドｋ−１と同様に行われ、通信サイクルｉ＋３にてノード３の多数派異常を、ノード３を担当しているノード１が特定する（９３１−３〜９３４−３）。一方、平行して行われる障害特定ラウンドｋ＋１の障害監視（ＭＯＮ）では、どのノードでも障害は検出されていない（９１１−２〜９１４−２，９１１−３〜９１４−３）。また、障害特定ラウンドｋ−１の障害特定結果交換（ＥＸＤ２），障害特定（ＩＤ２）も平行して行われるが、エラーカウンタ（９４１−２〜９４４−２，９４１−３〜９４４−３）やノード障害フラグ（９５１−２〜９５４−２，９５１−３〜９５４−３）に変化はない。
【００７３】
通信サイクルｉ＋４〜ｉ＋５では、障害特定ラウンドｋ＋２の障害監視（ＭＯＮ）や障害特定ラウンドｋ＋１の障害監視結果交換（ＥＸＤ１）と平行して、障害特定ラウンドｋの障害特定結果交換（ＥＸＤ２）、障害特定（ＩＤ２）が為される。これにより、ノード１によるノード３の多数派異常特定が他ノードに送信され（９０１−４）、各ノードがノード３の多数派異常を認識し、通信サイクルｉ＋５にて対応するエラーカウンタ値をインクリメントして３とする（９４１−５〜９４４−５）。これにより、各ノードにてノード３の多数派異常に対応するノード障害フラグが立つ（９５１−５〜９５４−５）。
【００７４】
以上により、各ノードにてノード３のＣＰＵ障害が特定され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。このように、図６のノード間相互監視による障害特定処理は、通信サイクルに同期してパイプライン的に実行することが可能であり、また時間軸処理分散により、通信サイクルあたりのＣＰＵ処理負荷や通信量は、時間軸処理分散をしないときより減少していることがわかる。上記では多数派異常を扱ったが、少数派異常についても同様である。
【実施例３】
【００７５】
上記では、障害監視処理（ＭＯＮ）の対象期間（通信サイクル）や、障害監視結果交換（ＥＸＤ，ＥＸＤ１）、障害特定（ＩＤ，ＩＤ１，ＩＤ２）を分割して実行する期間（通信サイクル）は一定であったが、これらの期間をシステム稼動中に変更することもできる。言い換えると、相互監視による障害特定の実行周期を可変とすることもできる。
【００７６】
図１０と図１１は、図３の相互監視による障害特定の並列処理について、システム稼動中に障害監視処理（ＭＯＮ）、障害監視結果交換（ＥＸＤ）、障害特定処理（ＩＤ）の実行周期を途中で変更する一例である。
【００７７】
障害特定の実行周期変更の仕方の１つとして、あるノードにて障害が発生している場合に、そのノードに対する障害特定に係る各処理の実行周期を短くするという方法を挙げることができる。障害が発生しているノードは、短周期で障害特定を行わなければならないという考えに基づく。実行周期変更の判断材料としては、エラーカウンタ値が指定値以上になること、を利用することができる。エラーカウンタは同期手段が提供されているので、実行周期変更のタイミングをノード間で一致化させることができるからである。
【００７８】
図１０は、ノード１の障害特定周期を変更する例である。通信サイクルｉ〜ｉ＋３までは図３と同じである。しかし、通信サイクルｉ＋２のノード１に対する障害特定（ＩＤ）にて、ノード１のエラーカウンタ値が指定値以上となり、ノード１に対する障害特定の実行周期を従来の２から１に短縮することに決定したとする。すると、通信サイクルｉ＋４以降は、ノード１に対する障害監視（ＭＯＮ）の対象期間（通信サイクル）を１に短縮し、ノード１についての障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）も障害監視（ＭＯＮ）の次の１サイクルにて実行されるようになる。この際も、ノード１についての障害監視結果交換（ＥＸＤ）は、全ノードについての障害監視（ＭＯＮ）と平行して実施されることになる。このように、ノード１についての障害特定（ＩＤ）は毎サイクルにてパイプライン的になされることになる。
【００７９】
図１１は、ノード３の障害特定周期を変更する例である。通信サイクルｉ〜ｉ＋３までは図３と同じである。しかし、通信サイクルｉ＋３のノード３に対する障害特定（ＩＤ）にて、ノード３のエラーカウンタ値が指定値以上となり、ノード３に対する障害特定の実行周期を従来の２から１に短縮することに決定したとする。すると、通信サイクルｉ＋４以降は、ノード３に対する障害監視（ＭＯＮ）の対象期間（通信サイクル）を１に短縮し、ノード３についての障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）も障害監視（ＭＯＮ）の次の１サイクルにて実行されるようになる。また、通信サイクルｉ＋２〜ｉ＋３におけるノード３についての障害監視（ＭＯＮ）に対応する障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）は、実行周期短縮前には通信サイクルｉ＋５にて実施される予定だったのが、繰り上がって通信サイクルｉ＋４にて実施される。代わりに通信サイクルｉ＋５では、通信サイクルｉ＋４におけるノード３についての障害監視（ＭＯＮ）に対応する障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）が実施される。通信サイクルｉ＋６以降は、同様に１つ前の通信サイクル分の障害監視（ＭＯＮ）に対応する障害監視結果交換（ＥＸＤ）と障害特定（ＩＤ）が実施され、ノード３については毎サイクルにて障害特定（ＩＤ）がなされることになる。
【００８０】
障害監視結果交換（ＥＸＤ）が３サイクル以上に渡る場合でも、障害特定の実行周期変更の際には図１１と同様に、障害監視結果交換（ＥＸＤ）や障害特定（ＩＤ）の各処理が繰り上がって実施される。
【００８１】
図１０と図１１においては、エラーカウンタ値のノード間同期が通信障害等により為されず、一部ノードで障害特定の実行周期変更がなされなくても、障害特定に係る各処理には実行周期変更前後で実効性で大きな差異がない。実行周期変更がなされず、障害監視結果を従来より短周期で送信できていないノードについては、上記の障害特定方法では異常ありと判定されることがないためである。また、当該ノードのエラーカウンタ値が他ノードとずれることがあっても、エラーカウンタ同期手段により、数通信サイクルのうちにエラーカウンタ値の同期が取れるためである。
【００８２】
図１２−１及び図１２−２は、ノード間相互監視による障害特定処理の動作例を示す。処理フローは図２に基づき、時間軸処理分散や処理パイプライン化は、図１１に則っている。障害監視項目などの諸条件は図５と同じであるが、送信データにて障害監視結果のビットはノード１〜４まで毎サイクル備えている点が異なる。ただし、障害監視結果を利用するか否かは、障害特定の実行周期に依存しており、必ず利用して障害特定（ＩＤ）を行う、というわけではない。
【００８３】
通信サイクルｉ〜ｉ＋３までは、図５と同じほぼ同じ内容である。異なるのは、ノード３の多数派異常に関するエラーカウンタ値の初期値が、全ノードで０であり（１２４１−０〜１２４４−０，１２４１−１〜１２４４−１，１２４１−２〜１２４４−２）、通信サイクルｉ＋３にてノード３の多数派異常が各ノードで特定される（１２３１−３〜１２３４−３）と、それに対応するエラーカウンタ値が１にインクリメントされる（１２４１−３〜１２４４−３）点である。また、通信サイクルｉ＋１〜ｉ＋３にてノード３はＣＰＵ異常を来たしており、これらがノード３の通番異常を招いている。これにより、通信サイクルｉ＋２〜ｉ＋４でも障害監視（ＭＯＮ）でノード３の障害をノード１，２，４が検出している（１２１１−２〜１２１４−２，１２１１−３〜１２１４−３，１２１１−４〜１２１４−４）。
【００８４】
通信サイクルｉ＋３にて、ノード３の多数派異常に関するエラーカウンタ値が１になると、各ノードで、ノード３に対する障害特定周期が２から１に変更される。これに伴い、通信サイクルｉ＋２〜ｉ＋３にて検出されたノード３の障害（両通信サイクルでＯＲが取られ、１つの障害と見なされる）（１２１１−２〜１２１４−２，１２１１−３〜１２１４−３）は、通信サイクルｉ＋４での障害監視結果交換（ＥＸＤ）に、通信サイクルｉ＋４にて検出されたノード３の障害（１２１１−４〜１２１４−４）は、通信サイクルｉ＋５での障害監視結果交換（ＥＸＤ）に利用される。通信サイクルｉ〜ｉ＋１の障害特定ラウンドを１とすると、通信サイクルｉ＋２〜ｉ＋３からはラウンド２、通信サイクルｉ＋４からはラウンド３となり、それぞれの障害特定（ＩＤ）が通信サイクルｉ＋３（１２３１−３〜１２３４−３），ｉ＋４（１２３１−４〜１２３４−４），ｉ＋５（１２３１−５〜１２３４−５）でなされ、各ノードのノード３の多数派異常に対応するエラーカウンタ値をインクリメントし（１２４１−３〜１２４４−３，１２４１−４〜１２４４−４，１２４１−５〜１２４４−５）、通信サイクルｉ＋５にてカウンタ値が３となって、ノード３の多数派異常に対応するノード障害フラグが立つ（１２４５−１〜１２４５−５）。
【００８５】
以上により、各ノードにてノード３のＣＰＵ障害が特定され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。このように、図２のノード間相互監視による障害特定処理は、障害特定の実行周期をシステム稼動中に変更することが可能であることわかる。上記では図２のフローと、多数派異常を扱ったが、図６のフローや少数派異常についても同様である。
【産業上の利用可能性】
【００８６】
分散システムを応用した制御システムは、自動車や建機、ＦＡ（Factory Automation）などの幅広い工業分野で活用されており、それらの分散型制御システムに本発明を適用することで、システムの信頼性を高く維持しつつ、かつ、バックアップ制御により可用性を高めることができる。
【００８７】
また、本発明は特別な装置の追加を行うことなく、低コストに制御システムを実施できる。
【図面の簡単な説明】
【００８８】
【図１】分散システムの構成図。
【００８９】
【図２】ノード間相互監視による障害特定処理のフロー図。
【図３】障害特定処理のパイプライン的処理例。
【図４】障害特定処理のパイプライン的処理例。
【図５】障害特定処理の動作例。
【図６】障害特定処理をノード間で分散した障害特定処理のフロー図。
【図７】障害特定処理をノード間で分散したパイプライン的処理例。
【図８】障害特定処理をノード間で分散したパイプライン的処理例。
【図９−１】障害特定処理の動作例。
【図９−２】障害特定処理の動作例。
【図１０】実行周期可変な障害特定処理のパイプライン的処理例。
【図１１】実行周期可変な障害特定処理のパイプライン的処理例。
【図１２−１】実行周期可変な障害特定処理の動作例。
【図１２−２】実行周期可変な障害特定処理の動作例。
【符号の説明】
【００９０】
１０  ノード
１１  ＣＰＵ
１２  メインメモリ
１３  Ｉ／Ｆ
１４  記憶装置
１００  ネットワーク
【図１】
2010011093.tif 000003
【図２】
2010011093.tif 000004
【図３】
2010011093.tif 000005
【図４】
2010011093.tif 000006
【図５】
2010011093.tif 000007
【図６】
2010011093.tif 000008
【図７】
2010011093.tif 000009
【図８】
2010011093.tif 000010
【図９−１】
2010011093.tif 000011
【図９−２】
2010011093.tif 000012
【図１０】
2010011093.tif 000013
【図１１】
2010011093.tif 000014
【図１２−１】
2010011093.tif 000015
【図１２−２】
2010011093.tif 000016