JP4491479B2 - 分散制御システム - Google Patents

Description

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

制御システムの構成の１つとして、分散システムがある。分散システムは、通信ネットワークにより結合された複数のノード（計算機やコントローラ）で、メッセージの送受信を通じて協調動作をするものである。分散システムでは、その一部に故障が発生しても、正常な残りのプロセスにて故障部位の処理を引き継ぐことで、耐故障性の高いシステムとすることができる。

分散システムにて問題になることの１つが、障害検出である。各ノードが自律的に動作しているため、ノード間でシステム障害の位置，種類，時機などに関する認識に違いが発生する恐れがある。このような認識の差により、ノード間で矛盾する動作を行い、システムが危険な状態となる恐れもあるため、分散システムにて制御を行う場合には、障害に関する認識をノード間で一致させることが重要である。

ノード間で障害に関する認識を一致させる方法として、ノード間での相互監視がある。相互監視による障害検出手法では、あるノードについて、各ノードが単独で障害の監視と検出を行い、その障害検出結果を、ネットワークを通してノード間で交換し、各ノードにて障害検出結果を集約し、最終的な障害の特定を行う。障害特定方法、即ち障害検出結果の集約方法として、例えば多数決型（障害を検出したノード数がある閾値、例えば障害のないノードの半数を超えていれば、障害ありと判断するもの）がある。

ここで、相互監視により障害を特定する場合、一般に次式の制約がある。

プロセス数≧３×特定可能な障害数＋１ …（１）
つまり、１つの障害を特定するためには、４つ以上のノードを相互監視に参加させる必要がある。しかし、規模の小さなシステムや、サブシステムだけで稼動する場合には、３ノードで構成される場合もある。そこで、３ノードで構成されるシステムにおいても、障害特定を行うことができる技術についての考察がある（非特許文献１参照）。

米田，梶原，土屋：ディペンダブルシステム，共立出版（２００５−１１）

非特許文献１では、例えば、３つのノードに対して、共通の変数値を入力する。そして、各々のノードの出力を比較し、他の２つのノードと異なる値を出力したノードが故障していると分かる。しかし、そもそも、入力する変数値が共通である保障はない。当該変数値が共通でなければ、出力もばらばらとなり、実効性に欠ける、という課題がある。

そこで、本発明の目的は、ノード数が３つであっても、確実に障害特定を行うことができるシステムを提供することにある。

複数ノードがネットワークを介して接続される分散システムにおいて、複数ノードの各々は、当該複数ノードの各々が持つ一つのパラメータを一致化する入力一致化部と、パラメータを入力とする共通処理を行う共通処理部と、共通処理の結果を、ネットワークを介して各々交換する送受信部と、結果の各々を比較し、当該結果が一致しない場合に異常があると特定する障害特定部を備える。

本発明によれば、ノード数が３つであっても、確実に障害特定を行うことができるシステムを提供することができる。

以下、実施形態について図面を用いて説明する。

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

本システムは、複数のノード（１−１〜１−ｎ）からなり、これらはそれぞれネットワーク６を介して接続される。尚、ｎ≧３である。

ノードとは、ネットワークに接続され、当該ネットワークを介して情報通信可能な処理装置であり、各種の電子制御装置、アクチュエータとそのドライバ、センサ等が含まれる。

ノードは、ＣＰＵ２，主メモリ３，記憶装置４，Ｉ／Ｆ５とからなり、Ｉ／Ｆ５を介してネットワーク６へ、ネットワーク６を介して他のノードへ接続される。

記憶装置４は、入力一致化部４１，共通処理部４２，障害特定部４３，送受信部４４，及びエラーカウンタ部４５等のプログラム、並びに、障害特定結果４６等のデータを格納する。

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

ネットワーク６は、多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して、同一内容を同時に送信するブロードキャスト送信が可能な構成となっている。

図２は、障害特定のフロー図である。

各ノードは、それぞれ、同期しながら処理を行う。同期のタイミングは、ネットワーク６を介して通信により取る。

まず、入力一致化部４１は、ノード間で共通に行う共通処理（以下、ＣＰ）の入力として用いる値（以下、入力値）の一致化である入力一致化（以下、ＩＳ）を行う（ステップ２１０）。より具体的には、各ノードの送受信部４４が、各々が保持する入力値を交換し、これら複数の入力値を、ノード間で共通のルールで１つの値（以下、一致化入力値）にまとめる。例えば、全入力値が同じ値のときのみ、その値を一致化入力値とする。１つでも異なる入力値のある場合には、一致化入力値なしとするか、入力値の多数決，平均や中央値を取るなどして、一致化入力値とする。一致化入力値を得られないときには、ステップ２２０以降の処理は行わない。一致化入力値を得られない回数をエラーカウンタ部４５で管理し、カウンタ値が所定の閾値以上になったときには、システム全体即ち全ノードにてシャットダウンしてもよい。以上により、各ノードは同じ値の入力値を持つ。入力値としては、時間と共に変化するパラメータがよい。例えば、各ノードが保持する通信サイクル数を用いる。

車載通信プロトコルＦｌｅｘＲａｙでは、ハードウェアにより通信サイクル数を含むグローバルタイムの同期がノード間で取られている。ＦｌｅｘＲａｙをネットワーク６のプロトコルに適用している場合には、通信サイクルを入力値として利用すれば、ステップ２１の入力値一致化処理に掛かるＣＰＵ負荷を低減できるため、ＣＰＵ処理能力を他処理に回すことや、低処理能力ＣＰＵの採用による低コスト化を図ることが可能である。ＦｌｅｘＲａｙの時間同期のように、一致化が図れるならば入力値そのものを明示的に交換しなくてもよい。

次に、共通処理部４２は、ステップ２１０で得られた一致化入力値を入力として、ＣＰを実行する（ステップ２２０）。ＣＰの内容は特に限定されないが、例えば四則演算による簡単な計算式（例：２Ｘ＋１）に一致化入力値を代入する。

相互監視にてあるノードの特定機能を監視項目としたい場合には、ＣＰではその特定機能を用いた処理を実行する。特定機能毎に図２の処理を行えば、各ノードについて複数項目を障害特定の対象とすることもできる。但し、特定機能の一致化入力値を共用できるならば、ＩＳは１回でよい。

次に、各々のノードの送受信部４４は、各々、ＣＰ結果交換（以下、ＥＸＣ）を行う（ステップ２３０）。これにより、各ノードは自ノード分を含む全ノードからのＣＰ結果を保持する。

次に、障害特定部４３は、障害特定（以下、ＩＤ）及び通知を実行する（ステップ２４０）。より具体的には、ステップ２３０で集約した各ノードからのＣＰ結果のうち、相互監視に参加するノード数の過半数以上が一致しているか否かを確認する。過半数以上の一致がない場合には、ＩＤは無効とする。過半数以上一致したＣＰ結果がある場合、その結果とは異なる値をＣＰ結果として示しているノードについて、「異常あり」と判断する。障害特定結果４６には、ノードｉについての障害有無を示すノード障害フラグｉが備えられ、対応するノードについて「異常あり」と判定された場合に、障害発生の通知としてフラグが立つ。アプリケーションは必要なときにノード障害フラグを参照するか、「異常あり」の判断時に割り込みが発生し、それに応じてノード障害フラグを参照することで、障害発生状況を確認できる。尚、障害有無フラグは図２のフローの開始時にクリアされている。

以上の一連の処理により、ノードの異常を高信頼に特定し、またノード間で異常発生状況の共通認識を持つことができる。

図３は、通信サイクルと図２の処理との関係を示す図である。

通信サイクルａ前半のタイムスパン３１０にて、ＩＳのうち、入力値の交換がなされる。通信サイクルａ後半のタイムスパン３２０にて、ＩＳのうち一致化入力値の決定と、その一致化入力値を用いたＣＰがなされる。通信サイクルａ＋１前半のタイムスパン３３０にて、ＥＸＣがなされる。通信サイクルａ＋１後半のタイムスパン３４０にて、集約したＣＰ結果をもとに、ＩＤ・通知がなされる。ここで特定される障害は、通信サイクルａ分のものである。このように、図２の処理による障害特定には通常、２通信サイクルの時間が掛かる。

図２の処理は、図４のようにパイプライン化してもよい。即ち、通信サイクルａ＋１分のＩＳの入力値交換と、通信サイクルａ分のＥＸＣを１つの送受信処理にまとめ、また通信サイクルａ＋１分の、ＩＳの一致化入力値決定と、ＣＰと、通信サイクルａ分のＩＤを続けて行うことで、各通信サイクルでＩＤが可能になる。尚、通信サイクルａの入力値は、通信サイクルａ−１の最後に決めておいてもよい。送受信部４４は、制御データ等、ノード間相互監視に関係する以外のデータを付加してもよい。

尚、障害特定４３が「異常あり」と判断したとき、即座にノード障害フラグを立てるのではなく、該当するノード及び監視項目のエラー数をインクリメントしてもよい。エラー数が所定の閾値以上となったときに、初めて該当するノード及び監視項目のノード障害フラグを立てる。また、「異常なし」と判断したときには、該当するノード及び監視項目のエラー数をインクリメントするか、リセットしてもよい。どちらの動作を取るかは、ソフトウェアのビルド時や設定ファイル等で事前に指定しておく。該当するノードの全監視項目について異常がない場合のみ、エラー数をデクリメントもしくはリセットするように設定しておいてもよい。

図５は、ノード間相互監視処理の適用例を示す図である。

この例ではノード間相互監視関係の処理のパイプライン化を行う。又、入力値としては通信サイクル数を用い、ＣＰでは四則演算（２×通信サイクル数＋１）を行う。

通信サイクル１では、ノード１，２，３は順にスロット１，２，３にて、通信サイクル１分の入力値である通信サイクル数と、前通信サイクルにて行ったＣＰの出力値をセットにして送信し、他ノードが受信している（５０１−１，５０２−１，５０３−１）。通信サイクル数は送信時の値である１、ＣＰ結果は前サイクルの一致化入力値０を用いて計算された１となっている。

各ノードはＩＤにて得られたＣＰ結果（５１１−１，５１２−１，５１３−１）を比較して、全部一致するため、通信サイクル０にてノード障害は発生していないと判断する（５２１−１，５２２−１，５２３−１がすべて「異常なし」を意味する０）。このため、エラー数（５３１−１，５３２−１，５３３−１）やノード障害フラグ（５４１−１，５４２−１，５４３−１）に変化は無い。

次に、通信サイクル１分の一致化入力値の決定を行う。ここでは、一致数が２以上の入力値を採用することとする。今、入力値はすべて１であるので、一致化入力値も１とする。

次に、この一致化入力値を用いて通信サイクル１分のＣＰを行い、結果として３を得る。但し、通信サイクル１で各ノードの送信終了直後に、ノード３にてＣＰＵ障害が発生し、以降継続している。これにより、ノード３のＣＰに影響が出るものとする。

通信サイクル２では、通信サイクル１と同様、各ノードが順に通信サイクル数の２と、通信サイクル１分のＣＰ結果である３を合せて送信している（５０１−２，５０２−２，５０３−２）が、ノード３だけはＣＰＵ障害により、ＣＰ結果が０になっている（５０３−２）。これにより、各ノードのＩＤにて、ノード３のみ共通処理結果が合わない（５１１−２，５１２−２，５１３−２）ことから、「ノード３に通信サイクル１にて異常あり」と判断され（５２１−２，５２２−２，５２３−２の３ビット目が「異常あり」を意味する１）、ノード３に関するエラー数が０から１にインクリメントされる（５３１−２，５３２−２，５３３−２）。ここではまだノード障害フラグ（５４１−２，５４２−２，５４３−２）に変化は無い。

通信サイクル３と４でも、通信サイクル２と同様に、ＩＤにて「ノード３に異常あり」と判断され、ノード３に関するエラー数がインクリメントされ、通信サイクル４のＩＤ後にはその値が３になる（５３１−４，５３２−４，５３３−４）。障害発生通知の閾値が３に設定されている場合、エラー数が閾値以上になるので、通信サイクル４のＩＤ後に、ノード障害フラグ３の値が０から１になり（５４１−４，５４２−４，５４３−４の３ビット目）、アプリケーションに対してノード３の障害が通知される。以上により、ノード障害の高信頼な特定と、ノード間での障害発生状況の認識一致化がなされる。

ノード間相互監視による障害特定方法としては、図２の処理の他に、図６の処理も可能である。これらの処理は、図２の処理と同様、各ノードが同期しながら行う。図２の相互監視処理は、送信ノードの障害特定に有効なのに対し、図６の相互監視処理は送信ノードのみならず、受信ノードの障害特定にも有効である。以下、図６の処理を説明する。

ステップ２１０〜２３０の後、障害特定部４３がＩＤを行う（ステップ６４０）。ここでは、図２の２４０と違い、通知は行わない。ここでのＩＤ結果は、エラー数やノード障害フラグの操作には利用しない。

次に、各々の送受信部４４は、ＩＤ結果交換（以下、ＥＸＣ２）を行う（ステップ６５０）。これにより、各ノードは自ノード分を含む全ノードからのＩＤ結果を保持する。

次に、障害特定部４３は、障害特定検査（以下、ＩＤ２）及び通知を実行する。より具体的には、ステップ６５０で集約した各ノードからのＩＤ結果のうち、相互監視に参加するノード数の過半数以上が一致しているか否かを確認する。過半数以上の一致がない場合には、ＩＤ２は無効とする。過半数以上一致したＩＤ結果がある場合、その結果とは異なる値をＩＤ結果として示しているノードについて、「異常あり」と判断する。障害特定結果４５には、ノードｉについての障害有無を示すノード障害フラグｉが備えられ、対応するノードについてＩＤ２の結果「異常あり」と判定された場合に、障害発生の通知としてフラグが立つ。アプリケーションによる障害発生状況の確認方法や、障害有無フラグのクリアは、図２の処理と同様である。

ノードｉのある監視項目の障害について、上記のようにＩＤ２にてＩＤ結果が他ノードと異なる、正確には一致数が過半数を超えるＩＤ結果と異なる場合には、受信障害があると分かる。別の見方をすると、通信サイクルａのＩＤにて「異常なし」と判定されているのに、通信サイクルａ＋１のＩＤ２にて「異常あり」と判定される場合には、受信ノードに障害があると分かる。

また、ＩＤ２にてＩＤ結果が他ノードと同じ、正確には一致数が過半数を超える障害特定結果と同じで、ＩＤ結果で「異常あり」と判定されている場合には、送信ノードに障害があると分かる。この場合も、エラー数のカウントとノード障害フラグの操作を行う。以上により、送信ノード障害と受信ノード障害の両方を高信頼に特定可能であり、ノード間で障害発生状況の認識一致化を図ることができる。

図６の処理によるＩＤ（ＩＤ２含む）には、図３の２通信サイクルの他に、ＥＸＣ２とＩＤ２でもう１通信サイクル掛かるので、合せて通常、３通信サイクルの時間が掛かる。但し、障害発生時機により、ＩＤ２までに必要な時間は変化する場合がある。例えば、受信障害がＥＸＣで起きる場合には、ＩＤ２まで２通信サイクルとなる。

尚、上記では、障害原因をノードの異常にしたが、例えばネットワーク６を多重化して、各ネットワークで送受信されるデータをもとに図２又は図６のノード間相互監視処理を行い、ＩＤをして、その結果を比較してもよい。その場合、あるノードについての障害有無が一致すればノードの異常、一致しなければ通信路の異常、との判断が可能である。

図６の処理は、図７のようにパイプライン化してもよい。即ち、通信サイクルａ＋２分のＩＳの入力値交換と、通信サイクルａ＋１分のＥＸＣと、通信サイクルａ分のＥＸＣ２を１つの送受信処理にまとめ、また通信サイクルａ＋２分の、ＩＳの一致化入力値決定と、ＣＰと、通信サイクルａ＋１分のＩＤと、通信サイクルａ分のＩＤ２を続けて行うことで、各通信サイクルでＩＤ２が可能になる。

以下では、図６のフローに基づく障害特定の実際の様子を、図８で説明する。この例ではノード間相互監視関係の処理のパイプライン化を行っており、入力値やＣＰは図５と同様である。

通信サイクル１では、ノード１，２，３は順にスロット１，２，３にて、通信サイクル１分の入力値である通信サイクル数と、前通信サイクルにて行ったＣＰの出力値と、前通信サイクルにて行ったＩＤ結果をセットにして送信し、他ノードが受信している（８０１−１，８０２−１，８０３−１）。通信サイクル数は送信時の値である１、ＣＰ結果は前サイクルの一致化入力値０を用いて計算された１となっている。

各ノードはＩＤにて、得られたＣＰ結果（８１１−１，８１２−１，８１３−１）を比較するが、ノード１がスロット２にて受信障害を起こしているため、ノード１が保持するノード２からのＣＰ結果が１ではなく０になっている（８１１−１）。このため、実際は通信サイクル１での発生だが、通信サイクル０にてノード２に障害が発生していると、ノード１だけが判断する（８２１−１の２ビット目が１）。一方、ノード２，３は通信サイクル０でのノード障害はないと判断している（８２２−１，８２３−１はすべて０）。この時点では、エラー数（８５１−１，８５２−１，８５３−１）やノード障害フラグ（８６１−１，８６２−１，８６３−１）に変化は無い。

次に、通信サイクル１分の一致化入力値の決定を行う。これは図５と同様であり、一致化入力値は１とする。次に、この一致化入力値を用いて通信サイクル１分のＣＰを行い、結果として３を得る。

通信サイクル２では、通信サイクル１と同様、各ノードが順に通信サイクル数の２と、通信サイクル１分のＣＰ結果である３と、通信サイクル０分のＩＤ結果（８２１−１，８２２−１，８２３−１）を合せて送信している（８０１−２，８０２−２，８０３−２）が、ノード１だけは受信障害によりＩＤ結果が０１０に（８０１−２）、他ノードのＩＤ結果は０００になっている（８０２−２，８０３−２）。これにより、各ノードのＩＤ２にて、ノード１のみＩＤ結果が合わない（８３１−２，８３２−２，８３３−２）ことから、「ノード１に通信サイクル０にて異常あり」と判断され（８４１−２，８４２−２，８４３−２の１ビット目が「異常あり」を意味する１）、ノード１に関するエラー数が０から１にインクリメントされる（８５１−２，８５２−２，８５３−２）。ここではまだノード障害フラグ（８６１−２，８６２−２，８６３−２）に変化は無い。

通信サイクル２と３でも、通信サイクル１と同様に、ノード１のスロット２にて受信障害が発生することにより、ノード１がＩＤにて「ノード２に異常あり」と判断することで、通信サイクル３と４のＩＤ２にて「ノード１に異常あり」と判断され、ノード１に関するエラー数がインクリメントされ、通信サイクル４のＩＤ２後にはその値が３になる（８５１−４，８５２−４，８５３−４）。障害発生通知の閾値が３に設定されている場合、エラー数が閾値以上になるので、通信サイクル４のＩＤ２後に、ノード障害フラグ１の値が０から１になり（８６１−４，８６２−４，８６３−４の１ビット目）、アプリケーションに対してノード１の障害が通知される。

以上により、受信障害の高信頼な特定と、ノード間での障害発生状況の認識一致化がなされる。尚、この例では送信ノード障害の扱いについては説明を省いたが、ＩＤ２にて特定と認識一致化をできることは前記の通りである。例えば、図５の状況に図６の処理フローを適用する場合、通信サイクル２における各ノードのＩＤ結果（５２１−２，５２２−２，５２３−２）が通信サイクル３にて送信され、通信サイクル３の各ノードでのＩＤ２において、各ノードからのＩＤ結果が全て同じ（００１）なので、ノード３に障害のあることが確実になり、ノード３に関するエラーフラグのインクリメントがなされる。

また、エラーカウンタ部４５が送信ノード障害と受信ノード障害とを分けて管理し、アプリケーションに通知すれば、アプリケーションは送信ノード障害と受信ノード障害とを分けて認識することが可能となる。

図９は、システム構成の一例を示す図である。図１との違いは、入力部９００が各ノードの入力一致化部４１と通信線９１０により接続している点のみである。通信線９１０は、シリアルケーブル等で構成されたノード毎の専用線でも、１つのネットワークでもよい。

入力部９００は、図２もしくは図６のノード間相互監視の入力値を生成し、入力一致化部４１に送信する。この入力値生成は、センサ値の計測等による。入力一致化部４１は、入力部９００から受信した値もしくはその加工値から、ＩＳを経て、一致化入力値を得る。

図９の構成を取ると、各ノードは図２もしくは図６のノード間相互監視を行える他、いずれかのノードにて障害が発生しても、正常なノードは入力部９００からのセンサ計測値等のデータを取得できる（異常ノード数が少なければ、一致化入力値も得ることができる）ため、複数ノードに制御指令値やモータ電流値の計算などを行う制御演算機能を配置されており、入力部９００からの入力値がこれら制御演算機能の入力となるならば、正常なノードに制御演算機能がある限り、ノード障害に影響されず制御機能を維持することも可能である。

上記の制御演算機能をＣＰとしてもよい。このようにした場合、各ノードが行う相互監視について、図２の処理フローを図１０のように、図６の処理フローを図１２のように変更することができる。

図１０は、ノード間相互監視のフロー図を示す。

各ノードの入力一致化部４１は、入力部９００から入力値取得（以下、ＩＲ）を行う（ステップ１０１０）。次に、共通処理部４２は、一致化入力値ではなく、ステップ１０１０で得た入力値を用いて演算を行う。演算内容はステップ２２０と同様である。次に、各々の送受信部４４は、ステップ１０１０で得た入力値と、ステップ１０２０で計算した共通処理結果をセットにして、各々交換する（ステップ１０３０）。これにより、各ノードは自ノード分を含む全ノードからの入力値及びＣＰ結果を保持する。このように、ステップ２１０のＩＳの入力値交換と、ステップ２２０のＥＸＣに該当する処理を１度に行うことで、ノード間相互監視の処理に掛かる時間を短縮することができる。

ステップ１０４０の入力値検査（以下、ＩＩ）では、ステップ１０３０で各ノードに集約された入力値から、一致化入力値を決定できるかを確認する。一致化入力値の得られる条件は、ステップ２１０と同じである。そして、ステップ２４０に進み、処理を終了する。

以上により、図２のノード間相互監視処理と同等の効果を得つつ、その処理に掛かる時間を短縮することができる。

図１１は、通信サイクルと図１０のノード間相互監視に関係する処理との関係を示している。通信サイクルａ前半のタイムスパン１１１０にて、ＩＲ、及びＣＰがなされる。尚、これらの処理は、通信サイクルの最後に、次サイクル分を行ってもよい。通信サイクルａ中間のタイムスパン１１２０にて、入力値及びＣＰ結果交換（以下、ＥＸＣ’）がなされる。通信サイクルａ後半のタイムスパン１１３０にて、ＩＩ、及び、ＩＤ・通知がなされる。このように、図１０の処理によるＩＤには通常、１通信サイクルの時間が掛かる。

図１２は、ノード間相互監視のフロー図を示す。

図１２は、図１０と図６の処理の組み合わせとなっており、まず、ステップ１０１０〜１０４０の処理がなされ、次に、ステップ６４０〜６６０の処理がなされる。これにより、図６のノード間相互監視処理と同等の効果を得つつ、図１０の処理フロー同様、その処理に掛かる時間を短縮することができる。

図１２の処理による障害特定（障害特定検査含む）には、図１１の１通信サイクルの他、ＥＸＣ２とＩＤ２でもう１通信サイクル掛かるので、合せて通常、２通信サイクルの時間が掛かる。

図１２の処理は、図１３のようにパイプライン化してもよい。即ち、通信サイクルａ＋１分のＥＸＣと、通信サイクルａ分のＥＸＣ２を１つの送受信処理にまとめ、また通信サイクルａ＋２分のＩＲと、ＣＰと、通信サイクルａ＋１分のＩＩと、ＩＤと、通信サイクルａ分のＩＤ２を続けて行うことで、各通信サイクルでＩＤ２が可能になる。

以下では、図９のシステム構成にて図１０、もしくは図１２のノード間相互監視を適用した制御システムの例として、自動車のＳＢＷ（Steer By Wire）を題材に説明する。

システム構成の詳細は次の通りである。ネットワーク６の通信プロトコルにはＦｌｅｘＲａｙが適用されており、ノード１，２，３としてＥＣＵ（Electric Control Unit）１，２，３が接続されている。ＥＣＵ１，２には転舵用モータが電流制御用のインバータを介して接続されており、この転舵用モータを用いて前輪の車軸を動かし、前輪の切れ角を変化させる。ＥＣＵ３はハンドルの操舵角や車速度から、前輪切れ角の目標値を計算し、更に現在の切れ角との差も考慮して、ＥＣＵ１，２の転舵用モータの電流値を計算する。計算された電流値はネットワーク６を介してＥＣＵ１，２に送信され、ＥＣＵ１，２はこの指令電流値に基づき、転舵用モータを制御する。

車速度は車速度センサからＣＡＮ（Controller Area Network）を介してＥＣＵ３に送信される。現在の前輪の切れ角は、ＥＣＵ１，２からＥＣＵ３へネットワーク６を介して送信され、転舵用モータの電流値計算に利用される。

ハンドルの操舵角は、ハンドルのレゾルバで計測され、通信線９１０を介して各ＥＣＵの入力一致化部４１−１〜４１−３に送信される。このハンドル操舵角が、ノード間相互監視の入力値として利用される。ＣＰは、ステアのバックアップ制御とする。このバックアップ制御は、ハンドル操舵角のみから前輪切れ角の目標値を計算し、更に現在の切れ角と目標切れ角の差のみから転舵用モータの電流値を計算する単純な制御演算である。

ノード間相互監視により、全てのＥＣＵが正常であると制御アプリケーションから確認されている間は、ＥＣＵ１，２はＥＣＵ３による指令電流値に基づき、転舵用モータを制御する。しかし、ノード間相互監視にて、ＥＣＵ３の故障が確認された（ノード障害フラグが立った）場合、ＥＣＵ１，２は自ノードで演算しているバックアップ制御により、転舵用モータの電流値を制御する。また、ノード間相互監視にて、ＥＣＵ１の故障が確認された場合には、ＥＣＵ３は、ＥＣＵ２の転舵モータのみで前輪を操作すべく、ＥＣＵ２に対する指令電流値を大きく計算して送信する。

以上により、ＥＣＵ障害発生時にもステア制御を継続することができる。ノード間相互監視とバックアップ制御を併用することで、ロバストな制御システムを構築することが可能となる。

分散システムを応用した制御システムは、自動車や建機、ＦＡ（Factory Automation）などの幅広い工業分野で活用されており、それらの分散型制御システムに本実施例を適用することで、システムの高信頼化を図ることができる。また、本稿では、監視用ノードの設置のような装置の追加を行うことなく実施できるため、高信頼化を低コストに行うことができる。

システム構成図。 障害特定のフロー図。 通信サイクルと図２の処理との関係を示す図。 ノード間相互監視処理のパイプライン化処理を示す図。 ノード間相互監視処理の適用例を示す図。 ノード間相互監視処理フロー図。 ノード間相互監視処理のパイプライン化処理を示す図。 ノード間相互監視処理の適用例を示す図。 システム構成の一例を示す図。 ノード間相互監視処理フロー図。 通信サイクルとノード間相互監視処理との関係を示す図。 ノード間相互監視処理フロー図。 ノード間相互監視処理のパイプライン化処理を示す図。

符号の説明

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

Claims (4)

1. 複数ノードがネットワークを介して接続される分散システムにおいて、
   前記複数ノードの各々は、
   当該複数ノードの各々が持つ一つのパラメータを一致化する入力一致化部と、
   前記パラメータを入力とする共通処理を行う共通処理部と、
   前記共通処理の結果を、前記ネットワークを介して各々交換する送受信部と、
   前記共通処理結果の各々を比較し、当該共通処理結果が一致しない場合に異常があると特定する障害特定部を備え、
   前記障害特定部は、前記共通処理結果のうち、一つの値を示す出力数がノード数の半数を超える場合に、当該一つの値以外の値を示す前記共通処理結果を生成したノードについて異常ありと判断し、
   前記入力一致化部，前記共通処理部，前記送受信部、及び前記障害特定部が行う各処理は、通信サイクルと同期して実施し、
   前記入力一致化部は、通信コントローラであり、前記パラメータは、通信プロトコルの規約上生成され、かつ、前記複数のノード間で共通の時間値であることを特徴とする分散システム。
2. 請求項１において、
   前記入力一致化部は、ハードウェアであることを特徴とする分散システム。
3. 複数ノードがネットワークを介して接続される分散システムにおいて、
   前記複数ノードの各々は、
   当該複数ノードの各々が持つ一つのパラメータを一致化する入力一致化部と、
   前記パラメータを入力とする共通処理を行う共通処理部と、
   前記共通処理の結果を、前記ネットワークを介して各々交換する送受信部と、
   前記共通処理結果の各々を比較し、当該共通処理結果が一致しない場合に異常があると特定する障害特定部を備え、
   前記障害特定部は、前記共通処理結果のうち、一つの値を示す出力数がノード数の半数を超える場合に、当該一つの値以外の値を示す前記共通処理結果を生成したノードについて異常ありと判断し、
   前記入力一致化部，前記共通処理部，前記送受信部、及び前記障害特定部が行う各処理は、通信サイクルと同期して実施し、前記共通処理部は、一致化される前のパラメータを入力とし、
   前記送受信部は、前記パラメータの一致化のための交換と前記共通処理結果の交換を同一のタイミングで行い、
   前記障害特定部は、前記パラメータの一致化と前記共通処理結果の比較を連続して行い、前記共通処理で用いたパラメータと、前記パラメータの一致化により得られたパラメータとが等しい場合のみ、前記共通処理結果の比較を有効とすることを特徴とする分散システム。
4. 複数ノードがネットワークを介して接続される分散システムにおいて、
   前記複数ノードの各々は、
   当該複数ノードの各々が持つ一つのパラメータを一致化する入力一致化部と、
   前記パラメータを入力とする共通処理を行う共通処理部と、
   前記共通処理の結果を、前記ネットワークを介して各々交換する送受信部と、
   前記共通処理結果の各々を比較し、当該共通処理結果が一致しない場合に異常があると特定する障害特定部を備え、
   前記障害特定部は、前記共通処理結果のうち、一つの値を示す出力数がノード数の半数を超える場合に、当該一つの値以外の値を示す前記共通処理結果を生成したノードについて異常ありと判断し、
   前記入力一致化部，前記共通処理部，前記送受信部、及び前記障害特定部が行う各処理は、通信サイクルと同期して実施し、
   前記送受信部は、前記障害特定の結果を前記ネットワークを介して各々交換し、前記障害特定部は、前記障害特定結果の各々を比較し、当該結果が一致しない場合に、当該結果を送信したノードに受信異常があると特定することを特徴とする分散システム。

Images