JP2009009557A - 分散システム - Google Patents

Abstract

【課題】
分散システムでは、障害を高信頼に特定し、また障害発生状況に関する認識をノード間で一致させるために、ノード間での相互監視を用いて、障害特定条件を２つ設定し、多数決型の障害特定方法を採用する。しかしながら、当該障害特定方法では、障害特定条件によらず、エラー数をカウントすることになるため、制御アプリケーションには正確かつ詳細な障害発生状況が分からず、障害発生時の対処が画一的になってしまう。
【解決手段】
複数のノードがネットワークを介して接続される分散システムは、複数のノードの各々は、他ノードに対する障害監視を行う障害監視部と、ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、データに基づいて、どのノードに障害があるかを特定する障害特定部と、障害があると特定されたノードのエラーの数を、障害特定条件毎にカウントするカウンタ部を備える。
【選択図】図１

Description

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

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

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

特許文献１によれば、データベースアプリケーションの稼動状態などに関する監視情報を各ノードで相互に共有するための特別なノード（共有ディスク）が必要になり、この共有ディスクが故障するとシステム内の障害ノード監視を継続することができなくなってしまう。また、共有ディスクを設けることにより、システムのコストが増加することが懸念される。その課題を解決するために、以下のような方法が考えられる。例えば、あるノードのある項目について、各ノードが単独で障害を検出するための監視を行い、その障害監視結果を、ネットワークを通してノード間で交換し、各ノードにて障害監視結果を集約し、最終的な障害の特定を行う。より具体的には、あるノードｊについての各ノードによる障害監視結果から障害特定するとき、各ノードは、障害を検出したノード数が、「＜障害特定条件１＞閾値以上ならば、ノードｊに障害ありと判断」し、「＜障害特定条件２＞閾値未満ならば、障害を検出したノードに障害ありと判断」する。尚、障害ありと判断されなかったノードについては障害なしと判断する。

しかし、上記のような構成とした場合、障害特定条件１に該当するときも、障害特定条件２に該当するときも、障害特定条件に関係なく、１つのカウンタでエラー発生数を管理することになる。そのため、異なる障害発生状況がアプリケーションにとっては同じに見えていた。条件１に該当する場合には送信側に異常のあることが多く、障害特定条件２では受信側に異常のあることが多いが、上記の構成では、それらを異なる障害発生状況と捕らえることができない、という課題がある。

そこで、本発明の目的は、障害の種別に応じて、障害があるノードを特定することができる分散システムを提供することにある。

複数のノードがネットワークを介して接続される分散システムは、複数のノードの各々は、他ノードに対する障害監視を行う障害監視部と、ネットワークを介して、他ノードの障害を検知するためのデータを送受信する送受信部と、データに基づいて、どのノードに障害があるかを特定する障害特定部と、障害があると特定されたノードのエラーの数を、障害特定条件毎にカウントするカウンタ部を備える。

本発明によれば、障害の種別に応じて、障害があるノードを特定することができる分散システムを提供することができる。

以下、実施例について説明する。

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

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

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

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

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

障害監視部１４１−ｉは、他ノードに対する障害監視（ＭＯＮ）を行う。送受信処理部１４２−ｉは、ネットワーク１００を介して、他ノードの障害を検知するためのデータを送受信する。障害特定部１４３−ｉは、他ノードの障害を検知するためのデータに基づいて、どのノードに障害があるかの障害特定（ＩＤ）を行う。カウンタ部１４４−ｉは、障害があると特定されたノードのエラーの数を、障害特定条件毎にカウントする。

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

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

次に、送受信処理部１４２−ｉは、ステップ２１で得られた障害監視結果を、各ノード間で交換する（ステップ２２）。各ノードは自ノード分を含む全ノードからの障害監視結果を保持することになる。

次に、障害特定部１４３−ｉは、ステップ２２で各ノードに集約された障害監視結果から、各ノード・各障害監視項目について、異常有無の多数決を取り、あるノードに対して「異常あり」が過半数であれば、当該ノードに障害があることを特定する（ステップ２３）。障害特定方法として、多数決の他、閾値を指定し、「異常あり」とするノード数がその閾値以上であるかを見てもよい。

次に、カウンタ部１４４−ｉは、ステップ２３で「異常あり」と判定された場合、障害特定の対象ノード・監視項目に対応するエラー数をインクリメントする。逆に「異常なし」と判定された場合、該当エラー数をデクリメントする（ステップ２４）。尚、デクリメントに限らず、リセットしてもよいし、何もしなくてもよい。デクリメントにするか、リセットにするか、何もしないか、の選択は、事前に設定しておく。

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

このような多数決型の障害特定方法では、「異常あり」と判断する条件には上記に挙げた２つの障害特定条件がある。障害特定条件毎にエラー数をカウントし、障害特定条件に対応するエラー数をインクリメントする。どの障害特定条件にも合致しないとき、各条件に対応するエラー数を、設定に応じてデクリメントする。ノード障害フラグは、ノード番号，障害監視項目の他に、障害特定条件で分ける。

図３は、障害特定条件に応じたエラー数のカウントの一例を示す。

監視結果集約表３１は、ある障害監視項目について、障害監視結果交換（ＥＸＤ）にて各ノードから集められた障害監視結果が入っている。このデータは、ノードｋ（ｋ＝１〜ｎ）がノードｊ（ｊ＝１〜ｎ）について、データ受信時に自ノード単独で判断した異常有無である。但し、自ノードについての判断は除外されている。○は「異常なし」を、×は「異常あり」を表している。このような監視結果集約表３１は、各ノードが、障害監視項目毎に持っている。

また、エラー数を格納するテーブルとして、上記の障害特定条件１に合致したときにインクリメントされる多数派異常表３２と、上記の障害特定条件２に合致したときにインクリメントされる少数派異常表３３とに分かれている。これらのテーブルも、各ノードが、障害監視項目毎に持っている。

各ノードにおける障害特定では、監視結果集約表３１を用いて、障害有無を特定する。例えばノード１に対する判定では、「異常あり」としているノードが過半数である。このため障害特定条件１に合致し、多数派異常表３２のノード１に対応する値が０から１にインクリメントされている。

また、ノード３に対する判定では、「異常なし」としているノードが過半数であるのに、ノード２だけが「異常あり」としている。このため障害特定条件２に合致し、少数派異常表３３のノード２に対応する値が０から１にインクリメントされている。

ノード３，４，５については、どの障害特定条件にも合致しない。このため、ノード３については、多数派異常表３２も少数派異常表３３も、もともと０なので、０のままとなっている。ノード４については、多数派異常表３２が１から０にデクリメントされている。少数派異常表３３は０のままである。ノード５については、少数派異常表３３が１から０にデクリメントされている。多数派異常表３２は０のままである。

多数派異常表が閾値以上になることでノード障害フラグが立つ状態を、以下では便宜的に「多数派異常」という。同様に、少数派異常カウンタが閾値以上になることでノード障害フラグが立つ状態を、「少数派異常」という。

図４は、障害特定条件に応じたエラー数のカウントの一例を示す。

監視結果集約表４１、及び、多数派異常表４２は、それぞれ、図３の監視結果集約表３１、及び、多数派異常表３２と同じである。一方、少数派異常表４３は、図３のものと異なり、障害特定条件２にノードｋが合致したとき、ノードｋが障害監視にて「異常あり」と判定したのがどのノードかによって、つまりノードｋの障害監視対象ノードｊのノード番号ｊ毎に、エラー数を分けている（以下、障害特定条件２に合致時の障害監視対象ノードを「少数派異常対応ノード」という）。但し、少数派異常表４３では、少数派異常対応ノードとして自ノードは除いている。

少数派異常表４３の値について、ノード１に関しては、障害特定条件１に合致するものの障害特定条件２には合致しないので、全ての少数派異常対応ノードに対して、エラー数は０のままである。ノード２に関しては、少数派異常対応ノードをノード３として障害特定条件２に合致するので、少数派異常対応ノードのノード３に対して、エラー数が０から１にインクリメントされている。ノード３，４に関しては、どの障害特定条件にも合致しないので、全ての少数派異常対応ノードに対して、エラー数は０のままである。ノード５に関しては、どの障害特定条件にも合致しないので、少数派異常対応ノードのノード１に対して、エラー数が２から１にデクリメントされ、少数派異常対応ノードのノード３に対して、エラー数が１から０にデクリメントされ、その他の少数派異常対応ノードに対しては、エラー数は０のままである。

以上の処理を繰り返すことで、障害発生を高信頼に特定し、障害発生状況に関する認識をノード間で一致化させることができる。更に、エラー数のカウントやノード障害フラグ立てを障害特定条件に応じて行うことで、アプリケーションは障害発生状況をより正確に、より詳細に知ることができる。

図５は、ノード間相互監視処理の動作例を示す。

ここでは、障害監視項目として上記の「通番異常」と「受信異常」を選定している。尚、障害監視処理と障害特定処理は、各ノードの送受信終了後、通信サイクルの最後に行われるものとする。

通信サイクルｉでは、ノード１〜４は順にスロット１〜４にて、前サイクル分の障害監視結果を送信し（５０１−１〜５０４−１、４進数表示）、他ノードが受信して保持する（５２１−１〜５２４−１、４進数表示）。送信データは、１つの監視対象ノードについて、通番異常を示すビット（Ｅ１），受信異常を示すビット（Ｅ２）からなり、それがノード１からノード４までについて並んでいる。但し、自ノード分の領域には、自ノードについての診断結果が入っている。

このとき、ノード３はスロット１にて受信障害を起こしており、ノード１からの障害監視結果を受け取れていない（５２３−１）。これにより、ノード３はノード１について、通信サイクルｉ分の障害監視結果として、「受信異常」と判定している（５１３−１、データ表記法は送信データと同じ）。受信異常により通番のインクリメントが確認されないので、「通番異常」も判定されている。ノード１，２，４は、通信サイクルｉ分の障害監視では異常を検出していない（５１１−１，５１２−１，５１４−１）。

通信サイクルｉ分の障害特定処理では、集約した障害監視結果（５２１−１〜５２４−１）に過半数を超える異常検出項目がないので、エラー数は０のままであり（５３１−１〜５３４−１）、ノード障害フラグも立たない（５４１−１〜５４４−１）。尚、ノード障害フラグは、１ノードについて、障害特定条件１による通番異常を示すビット，障害特定条件１による受信異常を示すビット，障害特定条件２による通番異常を示すビット，障害特定条件２による受信異常を示すビットの４ビット１桁によって表され、それがノード１〜４まで順に並んでいるものとする。

また、エラー数は、ノードｎについての障害監視結果のエラービットＥｍ（ｍ＝１，２）に対応する障害発生数を計数するために、障害特定条件１に合致した場合には多数派異常表としてＥｍ＿ｎを、障害特定条件２に合致した場合には少数派異常表としてＦｍ＿ｎを設定してある。

通信サイクルｉ＋１では、各ノードは前サイクルの障害監視結果を送信するため、ノード３の送信データでは、ノード１についてのエラービットＥ１，Ｅ２が立っている（５０３−２）。ノード１，２，４の送信データでは、どのエラービットも立っていない（５０１−２，５０２−２，５０４−２）。ここでもやはりノード３はスロット１にて受信障害を起こし、ノード１からの障害監視結果を受け取れていない（５２３−２）。これにより、ノード３はノード１について、通信サイクルｉ＋１分の障害監視結果として、「通番異常」と「受信異常」を判定している（５１３−２）。

通信サイクルｉ＋１における通信サイクルｉ分の障害特定処理では、集約した障害監視結果（５２１−２〜５２４−２）から、ノード３がノード１を少数派異常対応ノードとして、「通番異常」と「受信異常」のそれぞれで障害特定条件２に合致し、対応するエラー数がインクリメントされる（５３１−２〜５３４−２のうち、Ｆ１＿３とＦ２＿３）。ノード障害フラグはまだ立たない（５４１−２〜５４４−２）。

以上の処理が繰り返され、また通信サイクルｉ＋２においてもノード３はスロット１にて受信障害を起こしているため、通信サイクルｉ＋３の障害特定（ＩＤ）処理後には、エラー数Ｆ１＿３とＦ２＿３は３にまで増加する（５３１−４〜５３４−４）。エラー数の閾値を３にしている場合、Ｆ１＿３とＦ２＿３は閾値以上となるので、ノード３について障害特定条件２による「通番異常」と「受信異常」を示すノード障害フラグが立つ（５４１−４〜５４４−４）。

以上により、受信障害が少数派異常として把握され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。上記では少数派異常、即ち障害特定条件２での障害発生状況の把握を扱ったが、障害特定条件１による多数派異常についても同様である。

図６は、ノード間相互監視による障害特定処理のフロー図を示す。

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

次に、送受信処理部１４２−ｉは、各ノード間で、ステップ６１で得られた１ノードについての障害特定結果を交換する（ステップ６２）。各ノードは、自ノード分を含む全ノードについての障害特定結果を保持することになる。その後の処理は、図２と同様である。尚、障害特定条件２による判定は、ステップ６２の後に各ノードにて、全ノードを対象に行ってもよい。

図７は、ノード間相互監視処理の動作例を示す。障害監視項目と、データ交換以外の処理を通信サイクルの最後に行うことは、図５と同じである。

通信サイクルｉでは、ノード１〜４は順にスロット１〜４にて、前サイクル分の障害監視結果を送信し（７０１−１〜７０４−１）、他ノードが受信して保持する（７２１−１〜７２４−１、送信データのうち障害監視結果のみ）。また、送信データには、図５と同じ構造の障害監視結果に加え、前サイクルにて行った前々サイクル分の障害特定結果も入っている。障害特定結果は、対象ノードについて障害特定条件１による判定結果と、障害特定条件２による判定結果とが、それぞれＥ１，Ｅ２に対応する２ビットにて表されている。

このとき、ノード３はスロット１にて受信障害を起こしており、ノード１からの障害監視結果を受け取れていない（７２３−１）。これにより、ノード３はノード１について、通信サイクルｉ分の障害監視結果として、「通番異常」と「受信異常」とを判定している（７１３−１）。ノード１，２，４は、通信サイクルｉ分の障害監視では異常を検出していない（７１１−１，７１２−１，７１４−１）。

通信サイクルｉにおける障害特定処理では、集約した障害監視結果（７２１−１〜７２４−１）に過半数を超える異常検出項目がないので、全ノード・全監視項目で「異常なし」とする（７３１−１〜７３４−１、送信データの障害特定結果と同じ構造）。

また、通信サイクルｉにおける障害特定処理では、集約した前々サイクル分の障害特定結果に「異常あり」がないので、エラー数は０のままであり（７４１−１〜７４４−１）、ノード障害フラグも立たない（７５１−１〜７５４−１）。

通信サイクルｉ＋１における通信サイクルｉ分の障害特定処理では、ノード１がノード３を、ノード２がノード４を、ノード３がノード１を、ノード４がノード２を対象にしているとする。ノード１は、集約した障害監視結果（７２１−２〜７２４−２）から、ノード３がノード１を少数派異常対応ノードとして、「通番異常」と「受信異常」のそれぞれで障害特定条件２に合致していると判定する（７３１−２）。他ノードでは、障害が特定されない（７３２−２，７３３−２，７３４−２）。

また、通信サイクルｉ＋１における障害特定処理では、集約した前々サイクル分の障害特定結果に「異常あり」がないので、エラー数は０のままであり（７４１−２〜７４４−２）、ノード障害フラグも立たない（７５１−２〜７５４−２）。

通信サイクルｉ＋２では、前サイクルにて得られた障害特定結果が、各ノードから障害監視結果と共に送信される（７０１−３〜７０４−３）。これにより、各ノードにて、前々通信サイクルにおいてノード３がノード１を少数派異常対応ノードとして、「通番異常」と「受信異常」のそれぞれで障害特定条件２に合致していることを知り、対応するエラー数をインクリメントする（７４１−３〜７４４−３のうち、Ｆ１＿３とＦ２＿３）。ノード障害フラグはまだ立たない（７５１−３〜７５４−３）。

通信サイクルｉ＋２の障害特定では、通信サイクルｉ＋１でもノード３がスロット１にて受信障害を起こしていることにより、通信サイクルｉ＋１と同様の判定がなされる（７３１−３〜７３４−３）。但し、対象ノードは、ノード１がノード４を、ノード２がノード１を、ノード３がノード２を、ノード４がノード３を、というようにローテーションする。

以上の処理が繰り返され、また通信サイクルｉ＋２においてもノード３はスロット１にて受信障害を起こしているため、通信サイクルｉ＋３の障害特定処理後には、エラー数Ｆ１＿３とＦ２＿３は２にまで増加する（７４１−４〜７４４−４）。エラー数の閾値を２にしている場合、Ｆ１＿３とＦ２＿３は閾値以上となるので、ノード３について障害特定条件２による「通番異常」と「受信異常」を示すノード障害フラグが立つ（７５１−４〜７５４−４）。

以上により、受信障害が少数派異常として把握され、対応するノード障害フラグによりアプリケーションに通知されることが分かる。上記では少数派異常、即ち障害特定条件２での障害発生状況の把握を扱ったが、障害特定条件１による多数派異常についても同様である。

以下では、ノード間相互監視による障害発生状況の通知を、制御アプリケーションが具体的にどのように利用するかについて、制御アプリケーションとしてＢＢＷ（Brake By Wire）を例に説明する。

この例では、障害監視項目として、上記の「通番異常」と「受信異常」を扱うこととする。ノード間相互監視の処理フローは、図２でも図６でもよい。エラー数は図３のものを利用する。但し、エラー数の閾値は２段階にして、対応するノード障害フラグも２種類設定する。エラー数が１段目の閾値Ｈ１（＞０）以上になると、障害レベル１として、対応するノード障害レベル１フラグが立つ。２段目の閾値Ｈ２（＞Ｈ１）以上になると、障害レベル２として、対応するノード障害レベル２フラグが立つ。

ＢＢＷのシステム構成は次の通りとする。ネットワーク１００の通信プロトコルとしてＦｌｅｘＲａｙが用いられ、ノードとしてＥＣＵ１〜５がＦｌｅｘＲａｙネットワークにより結合している。ＥＣＵ１〜４は各車輪付近に配置され、各車輪のブレーキパッドを操作してブレーキ力を出すモータの電流制御を、インバータを用いて行う。ＥＣＵ１が右前輪、ＥＣＵ２が左前輪、ＥＣＵ３が右後輪、ＥＣＵ４が左後輪を担当する。ＥＣＵ５はブレーキペダルの踏み込み量やヨーレート等のセンサ値から各車輪の目標ブレーキ力を計算し、ＦｌｅｘＲａｙネットワーク経由でＥＣＵ１〜４に送信し、ＥＣＵ１〜４はその目標ブレーキ力と実際のブレーキ力が等しくなるように、ブレーキ用モータを制御する。

ブレーキペダルの踏み込み量は、別のＥＣＵからＦｌｅｘＲａｙネットワークに周期的に送信されている。ヨーレート等のセンサ計測値は、ＣＡＮ（Controller Area Network）経由でＥＣＵ５に送信されている。

以下に、障害発生状況に応じた各ノードの制御アプリケーションの判断例を示す。

［ケース１］
ＥＣＵ５の通番異常に関する多数派異常の障害レベル１が各ノードの制御アプリケーションに通知されたら、即ちノード障害レベル１フラグが立ったら、ＥＣＵ５の制御アプリケーションに異常があるということであり、これは致命的な障害であるとして、当該監視項目の障害レベル２を待たず、ＥＣＵ１〜４はバックアップ制御に移行する。ＥＣＵ５は、可能であればシャットダウンする。

バックアップ制御は、ＥＣＵ１〜４がブレーキペダル踏み込み量をネットワークから取り込み、ペダル踏み込み量から単純な比例計算で目標ブレーキ力を求め、その目標ブレーキ力に従って自ＥＣＵのブレーキ用モータを制御するものである。

［ケース２］
ＥＣＵ５の通番異常に関する少数派異常の障害レベル１が通知されたときには、ＥＣＵ５のみが他ＥＣＵの制御アプリケーション異常を検出している状態である。このときは、各ノードは制御上の影響はないものとして、通常制御を継続する。但し、障害発生時には必ず、時機や種類などの内容が、ログとして残されるものとする。このログは、後で障害の原因をエンジニアが診断する際に利用できる。

更にその後、同障害項目の障害レベル２が通知されたときには、障害が重大なものとして、ＥＣＵ１〜４はバックアップ制御に移行し、ＥＣＵ５はシャットダウンする。

［ケース３］
ＥＣＵ１〜４のいずれかの通番異常に関する多数派異常の障害レベル１が通知されたら、異常のある（ノード障害フラグの立った）ＥＣＵのブレーキ力はあてにならないと判断し、残りのＥＣＵは３輪ブレーキ制御に移行する。これは３輪のブレーキ用モータのみでブレーキ制御を行うものであり、ＥＣＵ５は３輪で安定的にブレーキを掛けられるよう、力の配分を考慮し、ＥＣＵ１〜４のうち残りの正常なＥＣＵに対して目標ブレーキ力を指令する。異常のあるＥＣＵの目標ブレーキ力は０とする。例えば右後輪に異常が発生した場合、前両輪の目標ブレーキ力を通常より強めにする。異常のあるＥＣＵは、できればシャットダウンする。

［ケース４］
ＥＣＵ１〜４のいずれかの通番異常に関する少数派異常の障害レベル１が通知されたときには、各ノードは制御上の影響はないものとして、通常制御を継続する。

更にその後、同障害項目の障害レベル２が通知されたときには、３輪ブレーキ制御に移行する。異常のあるＥＣＵは、できればシャットダウンする。

［ケース５］
ＥＣＵ５の受信異常に関する多数派異常の障害レベル１が通知されたら、ＥＣＵ１〜４がＥＣＵ５からの目標ブレーキ力指令を受信できていないということなので、ＥＣＵ１〜４はバックアップ制御に移行する。ＥＣＵ５はできればシャットダウンする。

［ケース６］
ＥＣＵ５の受信異常に関する少数派異常の障害レベル１が通知されたら、ＥＣＵ５だけＥＣＵ１〜４の一部から受信できていないということである。これが制御上問題ない仕様となっていれば、各ノードは通常制御を継続する判断を取る。

もし制御上問題あるときには、障害レベル１もしくは障害レベル２が通知された際に、ＥＣＵ１〜４は自律的にバックアップ制御に移行する。もしくは、ＥＣＵ５はＥＣＵ１〜４に対して宣言した上で、シャットダウンしてもよい。シャットダウンの宣言は、ＥＣＵ５の送信データ内にそのことを示すフラグ領域を設けることで実現する。

ＥＣＵ１〜４は、ＥＣＵ５からのシャットダウン宣言を受信し、更にＥＣＵ５がシャットダウンすることでＥＣＵ５の通番異常と受信異常の多数派異常表のエラー数がインクリメントされることから、シャットダウン宣言と障害特定の両者を合せてＥＣＵ５のシャットダウンを確認し、ＥＣＵ５の多数派異常表のエラー数が閾値以上となるのを待たず、バックアップ制御に移行する。

［ケース７］
ＥＣＵ１〜４のいずれかの受信異常に関する多数派異常の障害レベル１が通知されたら、他ＥＣＵは異常のあるＥＣＵからのデータを受信できていないということである。これが制御上問題のない仕様であれば、各ノードは通常制御を継続する判断を取る。

もし制御上問題のあるときには、障害レベル１もしくは障害レベル２が通知された際に、各ノードは３輪ブレーキ制御に移行し、異常のあるＥＣＵはできればシャットダウンする。

［ケース８］
ＥＣＵ１〜４のいずれかの受信異常に関する少数派異常の障害レベル１が通知されたら、異常のあるＥＣＵのみが、他ＥＣＵからのデータを受信できていないということである。このとき、少数派異常対応ノードがＥＣＵ５か、ＥＣＵ１〜４のうちの他ＥＣＵかで、各ノードの取るべき対応も異なってくる。ＥＣＵ５からの目標ブレーキ力を受信できていないのは致命的なのに対し、ＥＣＵ１〜４のうち他ＥＣＵから受信できていないのは、制御上問題のない仕様となっているかもしれない、といったように、ＥＣＵ毎にその送信データの重要度が異なるからである。

この問題に対応するため、少数派異常カウンタを、少数派異常対応ノードとしてＥＣＵ５と、ＥＣＵ１〜４（の自ノード以外）と、２つに分けて設定してもよい。１通信サイクルにてＥＣＵ１〜４の１ノード以上を少数派異常対応ノードとする障害が１つ以上特定された場合には、後者のエラー数をカウントする。

この少数派異常表を用いる場合、ＥＣＵ５を少数派異常対応ノードとして少数派異常が通知された場合には、正常な残りのノードは３輪ブレーキ制御に移行し、異常のあるノードはシャットダウンする。一方、ＥＣＵ１〜４が少数派異常対応ノードである場合には、通常制御を継続するという判断もありうる。

以上のように、ノード間相互監視を制御アプリケーションが利用することで、障害発生時に制御アプリケーションが取る対処の選択肢が広がり、またその対処をより適切に選択することができ、システムの信頼性を高く維持しつつ、可用性を高めることができる。

しかしながら前記までの実施例では、次のような課題がある。障害特定条件１に合致する場合、その判定はノード間の認識（障害監視結果）の多数決であり、ノード間で判定結果が一致する。しかし障害特定条件２に合致する場合、その判定は各ノードが単独で行うものであり、ノード間で多数決が取られておらず、必ずしも判定結果が一致しない恐れがある。

例えば、ノード１〜４があり各ノードに障害がなく、各ノードは他ノードに対して障害を検出していない状況において、ノード２が送信する障害監視結果が、ノード４に受信される際にソフトエラーにより変化し、ノード２はノード１について本来「異常なし」と判定しているにも関わらず、ノード４はノード２がノード１について「異常あり」と判定していると誤認識した場合、障害特定処理において、ノード１〜３はノード２について障害なしと判定するが、ノード４は障害特定条件２により、ノード２に障害ありと判定し、ノード間で障害特定結果が一致しない。

この問題の解決には、障害特定条件２に合致した場合、障害が特定されたとしてエラーカウンタを操作するのではなく、障害検出結果としてノード間で交換し、再度多数決処理を行うことで、障害特定条件２に合致したという認識をノード間で一致化させることができる。以下では便宜上、１回目の多数決処理で障害特定条件１に合致して特定した障害を「送信側障害」と呼び、２回目の多数決処理で特定される障害を「受信側障害」と呼ぶ。

図８は、上記の問題を解決するための、ノード間相互監視による障害特定処理のフロー図を示す。

ステップ２２の後、障害特定部１４３−ｉは、ステップ２２で交換した障害監視結果のうち、「受信側異常」以外の障害監視項目について、多数決処理により障害特定を行う（ステップ８１）。この際、障害特定条件１に合致した場合のみを障害ありと判定する。これは「送信側障害」を特定していることになる。次のステップ２４ａとステップ２５ａはそれぞれステップ２４，ステップ２５と同様であるが、送信側異常のみを対象とする。つまり、エラーカウンタ操作やノード障害通知は、送信側異常と受信側異常とを区別して扱う。

次に、障害監視部１４１−ｉは、ステップ２２で交換した障害監視結果のうち、「受信側異常」以外の障害監視項目について、障害特定条件２に合致した場合、当該ノード・障害監視項目について、「受信側障害」を検出したとする（ステップ８２）。

次に、送受信処理部１４２−ｉは、ステップ８２で検出した受信側異常の検出結果を、ノード間で送受信して交換する（ステップ８３）。この際、受信側異常以外の障害監視項目、すなわち送信側障害に属する障害監視項目とはデータ領域を分けて送受信する。

次に、障害特定部１４３−ｉは、ステップ８３で交換した障害監視結果のうち、「受信側異常」に属する障害監視項目について、多数決処理により障害特定を行う（ステップ８４）。次のステップ２４ｂとステップ２５ｂはそれぞれステップ２４，ステップ２５と同様であるが、受信側異常のみを対象とする。

また、図６の処理フローと同様に、ステップ８１やステップ８４における障害特定対象ノードを１ノードに限定し、障害特定結果を他ノードに送信してもよい。

図９は、４ノードのシステムにおける、図８の処理フローに基づいたノード間相互監視による障害特定の並列処理の一例である。図９では、送信側異常の検出処理を障害監視（ＭＯＮ１），送信側異常の検出結果交換を障害監視結果交換（ＥＸＤ１），送信側異常の特定を障害特定（ＩＤ１），受信側異常の検出処理を障害監視（ＭＯＮ２），受信側異常の検出結果交換を障害監視結果交換（ＥＸＤ２），受信側異常の特定処理を障害特定（ＩＤ２）と表現している。

各ノードは障害特定ラウンド１として、通信サイクルｉで障害監視（ＭＯＮ１）を行い、障害監視結果交換（ＥＸＤ１）と障害特定（ＩＤ１）および障害監視（ＭＯＮ２）は通信サイクルｉ＋１で、障害監視結果交換（ＥＸＤ２）と障害特定（ＩＤ２）は通信サイクルｉ＋２で実施している。

各ノードは障害特定ラウンド１を実施する一方で、障害特定ラウンド２を実施している。通信サイクルｉ＋１では、障害特定ラウンド１の障害監視結果交換（ＥＸＤ１）を実施すると同時に、障害監視結果交換（ＥＸＤ１）の受信データ内容やデータ受信状況から、障害特定ラウンド２の障害監視（ＭＯＮ１）を実施している。通信サイクルｉ＋２では、障害特定ラウンド１の障害監視結果交換（ＥＸＤ２）の送受信と合わせて、障害特定ラウンド２の障害監視結果交換（ＥＸＤ１）を行う。同時に、障害特定ラウンド３の障害監視（ＭＯＮ１）を行う。また障害特定ラウンド１の障害特定（ＩＤ２）のほか、障害特定ラウンド２の障害特定（ＩＤ１）と障害監視（ＭＯＮ２）も行う。通信サイクルｉ＋３では、特定ラウンド２の障害監視結果交換（ＥＸＤ２）と障害特定ラウンド３の障害監視結果交換（ＥＸＤ１）、および障害特定ラウンド４の障害監視（ＭＯＮ１）を行っている。また、障害特定ラウンド２の障害特定（ＩＤ２）と障害特定ラウンド３の障害特定（ＩＤ１）および障害監視（ＭＯＮ２）も行う。

以下同様に、このような処理を繰り返す。これにより障害特定（ＩＤ１）および障害特定（ＩＤ２）が毎通信サイクルにて実施可能となる。

図１０は、図８の処理フローに基づくノード間相互監視処理の動作例を示す。

ここでは、障害監視項目を何らかの異常を示す１項目とし、その１項目を送信側異常と受信側異常とに分けている。また、ノード障害フラグの通知閾値は２とする。

通信サイクルｉでは、ノード１〜４は順にスロット１〜４にて、前サイクル分の障害監視（ＭＯＮ１，ＭＯＮ２）結果を送信し（１００１−０〜１００４−０、４進数表示）、他ノードが受信して保持する（１０２１−０〜１０２４−０、４進数表示）。送信データは、１監視対象ノードについて、送信側異常を示すビット（ＥＳ），受信側異常を示すビット（ＥＲ）からなり、それがノード１からノード４までについて並んでいる。但し、自ノード分の領域には、自ノードについての診断結果が入っている。

このとき、ノード４はスロット１にて受信障害を起こしており、ノード１からの障害監視結果を受け取れていない（１０２４−０）。これにより、ノード４はノード１について、障害監視（ＭＯＮ１）結果として、「送信側異常」と判定している（１０１４−０、データ表記法は送信データと同じ）。ノード１〜３は、障害監視（ＭＯＮ１）では異常を検出していない（１０１１−０〜１０１３−０）。

障害特定（ＩＤ１，ＩＤ２）処理では、集約した障害監視結果（１０２１−０〜１０２４−０）に過半数を超える異常検出項目がないので、どのノードについても送信側異常も受信側異常も特定されず（１０３１−０〜１０３４−０）、エラー数は０のままであり（１０４１−０〜１０４４−０）、ノード障害フラグも立たない（１０５１−０〜１０５４−０）。また、障害監視（ＭＯＮ２）でも受信側異常はどのノードについても検出されない。

尚、ノード障害フラグは、１ノードについて、送信側異常を示すビット，受信側異常を示すビットの２ビット１桁によって表され、それがノード１〜４まで順に並んでいるものとする。また、エラー数は、ノードｎについての障害監視結果のエラービットＥＳ，ＥＲに対応する障害発生数を計数するために、送信側異常に対しては多数派異常表ＥＳ＿ｎを、受信側異常に対しては少数派異常表ＥＲ＿ｎを設定してある。

通信サイクルｉ＋１では、各ノードは前サイクルの障害監視（ＭＯＮ１，ＭＯＮ２）結果を送信するため、ノード４の送信データでは、ノード１についてのエラービットＥＳが立っている（１００４−１）。ノード１〜３の送信データでは、どのエラービットも立っていない（１００１−１〜１００３−０）。ここでもやはりノード４はスロット１にて受信障害を起こし、ノード１からの障害監視結果を受け取れていない（１０２４−１）。これにより、ノード４はノード１について、障害監視（ＭＯＮ１）結果として「送信側異常」と判定している（１０１４−１）。

障害特定（ＩＤ１，ＩＤ２）処理および障害監視（ＭＯＮ２）処理では、集約した障害監視結果（１０２１−１〜１０２４−１）から、ノード４に受信側異常を検出する（１０１１−１〜１０１４−１）。しかし、どのノードについても送信側異常も受信側異常も特定されない（１０３１−１〜１０３４−１）ため、エラーカウンタ（１０４１−１〜１０４４−１）もノード障害フラグ（１０５１−１〜１０５４−１）も不変である。

通信サイクルｉ＋２では、ノード４の送信データでは、ノード１についてのＥＳと自ノードについてのＥＲが立っている（１００４−２）。ノード１〜３の送信データでは、ノード４のＥＲのみが立っている（１００１−２〜１００３−２）。障害監視（ＭＯＮ１）処理では、どのノードについても送信側異常は検出されない（１０１１−２〜１０１４−２）。

障害特定（ＩＤ１，ＩＤ２）処理では、集約した障害監視結果（１０２１−２〜１０２４−２）から、ノード４の受信側異常が半数以上のノードから検出されており確定する（１０３１−２〜１０３４−２）。また障害監視（ＭＯＮ２）では、通信サイクルｉ＋１と同様、ノード４の受信側異常が検出される（１０１１−２〜１０１４−２）。

各ノードのエラーカウンタは、ノード４の受信側異常に関してインクリメントされ０から１となる（１０４１−２〜１０４４−２）。ノード障害フラグは、エラーカウンタ値が通知閾値に達していないため、不変である（１０５１−２〜１０５４−２）。

通信サイクルｉ＋３では、ノード１〜４の送信データで、ノード４のＥＲが立っている（１００１−３〜１００３−３）。障害監視（ＭＯＮ１）処理では、どのノードについても送信側異常は検出されない（１０１１−３〜１０１４−３）。

障害特定（ＩＤ１，ＩＤ２）処理では、集約した障害監視結果（１０２１−３〜１０２４−３）から、通信サイクルｉ＋２と同様、ノード４の受信側異常が確定する（１０３１−３〜１０３４−３）。障害監視（ＭＯＮ２）では、受信側異常は検出されない（１０１１−３〜１０１４−３）。

各ノードのエラーカウンタは、ノード４の受信側異常に関してインクリメントされ１から２となる（１０４１−３〜１０４４−３）。これを受けて、ノード４の受信側異常に対するエラーカウンタ値が通知閾値の２に達するため、ノード４の受信側異常を示すノード障害フラグが立ち、制御アプリケーションに通知される（１０５１−３〜１０５４−３）。

以上により、受信側異常が送信側異常と同等の高い信頼性で特定され、制御アプリケーションに通知されることがわかる。

分散システムを応用した制御システムは、自動車や建機，ＦＡ（Factory Automation）などの幅広い工業分野で活用されており、それらの分散型制御システムに上記実施形態を適用することで、システムの信頼性を高く維持しつつ、可用性を高めることができる。また、上記実施形態は特別な装置の追加を行うことなく、低コストに実施できる。

分散システムの構成図。 ノード間相互監視による障害特定処理のフロー図。 障害特定条件に応じたエラー数のカウントの一例。 障害特定条件に応じたエラー数のカウントの一例。 ノード間相互監視処理の動作例。 ノード間相互監視による障害特定処理のフロー図。 ノード間相互監視処理の動作例。 ノード間相互監視による障害特定処理のフロー図。 複数の監視ラウンドの並列実行例。 ノード間相互監視処理の動作例。

符号の説明

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

Claims (3)

1. 複数のノードがネットワークを介して接続される分散システムにおいて、
   前記複数のノードの各々は、
   他ノードに対する障害監視を行う障害監視部と、
   前記ネットワークを介して、ノード間で障害監視結果を交換するためのデータを送受信する送受信部と、
   前記データに基づき各ノードの障害有無を特定する障害特定部と、
   障害ありと特定されたノードのエラー数を、前記障害特定部の障害特定条件毎にカウントするカウンタ部を備える、分散システム。
2. 前記障害特定条件は、複数のノードのうち障害特定対象とする１ノードについて、
   前記データにて障害を検出したとするノード数が閾値以上であれば前記障害特定対象ノードに障害ありと判定する第１の障害特定条件と、
   前記データにて障害を検出したとするノード数が閾値未満であれば、障害を検出したとするノードに障害ありと判定する第２の障害特定条件を含む、請求項１記載の分散システム。
3. 前記障害を非受信側異常と呼び、前記データにて障害特定対象とする１ノードに対し前記非受信側異常を検出したとするノード数が閾値未満であれば、障害を検出したとするノードについて受信側異常ありと判定し、それ以外の条件で検出する障害を受信側異常以外と判定し、
   前記送受信部は前記データにて、１障害検出項目の領域を受信側異常と受信側異常以外に分離しており、
   前記障害特定条件は、複数のノードのうちの障害特定対象とする１ノードについて、
   前記データにて障害を検出したとするノード数が閾値以上であれば前記障害特定対象ノードに障害ありと判定することを、受信側異常に対して規定する障害特定条件と、受信側異常以外に対して規定する障害特定条件を含む、請求項１記載の分散システム。

Images