JP5260369B2 - 分散システム - Google Patents

Description

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

近年、自動車の運転快適性や安全性の向上を目指して、機械的な操作力の伝達ではなく、電子制御により、運転者のアクセル，ステアリング，ブレーキなどの操作を車両の駆動力，操舵力，制動力発生機構などに反映させる車両制御システムの開発が行われている。建機など他の機器でも同様な電子制御の適用が進められている。これらシステムでは、機器に分散配置した複数の電子制御装置（ＥＣＵ、Electronic Control Unit）がネットワークを介してデータを送受信し協調動作を行う。この際、同一ネットワーク内のあるＥＣＵに障害が発生した際に、各ＥＣＵが障害発生箇所を正確に特定し、障害内容に応じた適切なバックアップ制御を行うことが、フェールセーフ上必要不可欠となる。上記課題を解決するために、ＥＣＵが相互に各ノードの状態（障害有無など）を監視して判定し、その判定結果を交換した上で、多数決などにより各ノード状態を特定し、ノード間で状態認識を高信頼に一致化する技術がある（特許文献１参照）。ノードの障害有無は各ノードの属性の１つであるが、ノードに属さないシステムとしての状態に関する認識一致化も、同様にして行うことができる。

特開２００７−１２６１２７号公報

特許文献１では、ノード状態の認識および認識一致化機能を、ミドルウェアに実装することにより、当該機能を汎用化するとしている。しかし、ノードやシステムの状態遷移はシステムにより多種多様であり、状態遷移が複雑なシステムで詳細なノード状態やシステム状態の認識一致化を図ろうとすると、ノード状態の判定方法をシステムごとに適合させる必要が生じる場合が考えられ、その際の当該ミドルウェアのソフトウェア変更量が大きくなる可能性もある。

また、ノードの取りうる状態は複数あり、各ノードはその中から真の状態を１つ抽出して正しく認識しなければならない。例えばあるノードがデータを送信してこないときの当該ノードの状態として、一旦正常に起動したがその後故障した場合、未起動であるがこれから起動する予定である場合、起動不可である場合、仕様通りスリープ状態に入っている場合などがある。これらのうちどれが真の状態であるかは自動的には決まらず、他ノードがあるルールを持って判断する必要がある。しかし各ノードの置かれた条件は同じではないので、同じルールに従ってもノード間で判断に差が出る可能性がある。つまりあるノードに関する状態認識には、各ノードの主観的な判断が入る場合があるといえる。このような場合でもノード間で状態認識を一致化させる仕組みが必要である。また、ノード状態が主要な決定要因となるシステムとしての状態についても、同様のことがいえる。

詳細なノード状態やシステム状態は、各ノードの障害有無（正常または異常）といった基本的なノード状態を入力として判定される場合が多い。このような基本的なノード状態は、システムの種類に依らず幅広く有効な概念であり、その認識方法は、データ受信時における異常検出や、自己診断ならびにその通知など、多様なシステムにて共通的な手法である。

このため、基本的なノード状態認識に関わる機能と、詳細なノード状態やシステム状態の認識に関わる機能とを分離して備え、機能間のインターフェースを定義することにより、システムに応じて変更が必要な部分は後者の一部に限定することが可能である。これにより、システムごとに変更する機能を少なくし、変更の不要な機能を多くすることでシステム間で機能の共有化ができ、当該ミドルウェア（もしくはハードウェア回路）の再利用性が向上する。また、詳細なノード状態やシステム状態の認識に関わる機能を柔軟に設定できるので、ノードの主観的な判断の余地を含む、複雑な状態遷移を取り扱うことができる。

請求項および以降の説明では、上記の基本的なノード状態を単に「ノード状態」と呼び、ノード詳細状態やシステム状態のことを合わせて「システム状態」と呼ぶ。

多様で複雑な遷移を取りうるシステム状態に関して、ノード間の状態認識を高信頼に一致化することができる。また、システム状態の認識および認識一致化機能を提供するミドルウェアやハードウェアの再利用性を高めつつ、柔軟で拡張性のある構成とすることができる。

ノード状態とシステム状態とは各々で認識一致化されるが、システム状態の判定にノード間で認識一致化された後のノード状態を入力として利用する方法では、システム状態の認識一致化がロバストになり、より高信頼化される。

分散システムの構成。 ステアバイワイヤのシステム構成概略。 システム状態特定の処理フロー（１）。 システム状態特定のデータフロー（１）。 システム状態特定の各処理と通信サイクルとの関係（１）。 システム開始時に関するノードとシステムの状態遷移図（１）。 システム開始時に関するノードとシステムの状態遷移図（２）。 システム状態特定の処理フロー（２）。 システム状態特定のデータフロー（２）。 システム状態特定の各処理と通信サイクルとの関係（２）。 システム終了時に関するノードとシステムの状態遷移図。 ノード途中参加時に関するノードとシステムの状態遷移図。 電気自動車のシステム構成概略。 ノード途中離脱時に関するノードとシステムの状態遷移図。

本発明の実施形態を図面を用いて説明する。

図１は、本発明の一実施例をなす分散システムの一般化された構成図である。分散システムは、複数のノード１０（１０−１，１０―２，…，１０−ｎ）からなり、これらのノードはネットワーク１００を介して接続される。ここで、ノードとは、ネットワークを介して情報通信可能な処理装置であり、ＣＰＵを含む各種の電子制御装置，アクチュエータとその制御部，センサなどが含まれる。ＥＣＵはノードの一種である。ネットワーク１００は多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して、同一内容を同時に送信するブロードキャスト送信が可能である。通信プロトコルとしては、ＦｌｅｘＲａｙやＴＴＣＡＮ（time-triggered CAN）などを用いることができる。

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

記憶装置１４−ｘは、ノード状態判定部１５−ｘ，ノード状態交換部１６−ｘ，ノード状態特定部１７−ｘ，システム状態判定部１８−ｘ，システム状態交換部１９−ｘ及び、システム状態特定部２０−ｘなどのプログラムを格納する。

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

ノード状態判定部１５−ｘは、各ノードに対しノード状態を監視し判定する（以下、ＭＯＮ１）。ノード状態交換部１６−ｘは、ネットワーク１００を介し、ノード状態判定部１５−ｘが判定したノード状態をノード間で送受信し、ノード状態に関する各ノードの判定結果を集約する（以下、ＥＸＤ１）。ノード状態特定部１７−ｘは、ノード状態交換部１６−ｘが集約したノード状態判定結果に基づき、多数決処理などによりノード状態特定（以下、ＩＤ１）を行い、ノード間でノード状態の認識を一致化する。本発明では、各ノードにより判定され集約された判定結果から１つの結論を確定し、ノード間で一致した結果を得ることを「特定」と表す。

ノード状態判定（ＭＯＮ１）の具体的な手段の例としては、データ受信時にプロトコル異常を検出したとき、送信ノードの異常と判定する方法がある。また、受信データの誤り検出符合やシリアル番号の未更新によりエラーが検出された際に、送信ノードの異常と判定する方法がある。また自ノードの異常に関しては、自己診断機能により検出可能である。自己診断結果を他ノードに送信した場合には、受信ノードが送信ノードの異常を検出できる。

システム状態判定部１８−ｘは、システム状態判定（以下、ＭＯＮ２）を行う。ここで「システム状態」とは前述の通り、ノードに属さないシステムとしての状態であるが、ノードの詳細状態も含むとする。システム状態交換部１９−ｘは、ネットワーク１００を介し、システム状態判定部１８−ｘが判定したシステム状態をノード間で送受信し、システム状態に関する各ノードの判定結果を集約する（以下、ＥＸＤ２）。システム状態特定部２０−ｘは、システム状態交換部１９−ｘが集約したシステム状態判定結果に基づき、多数決処理などによりシステム状態特定（以下、ＩＤ２）を行い、ノード間でシステム状態の認識を一致化する。

図２は本実施例の対象システムである、ステアバイワイヤの概略構成を示している。システムはＥＣＵ１〜４（２１−１〜４）の４ノード構成であり、各ＥＣＵはネットワーク２５で接続されている。ＥＣＵ２〜４はそれぞれインバータ２２−２〜４を持ち、モータ２３−２〜４を制御している。モータ２３−２は駆動力伝達機構２４−２を介してハンドル２６，シャフト２７に反力を与える。モータ２３−３〜４は、それぞれ駆動力伝達機構２４−３〜４を介してラック２８を制御し、車輪２９−１〜２の方向を変えることで転舵する。ＥＣＵ２は、運転手によるハンドル２６の操作量をシャフト２７に備えたセンサから検出し、ネットワーク２５に送信する。ＥＣＵ３〜４は、車輪２９−１〜２の軸に備えたセンサから転舵角を検出し、ネットワーク２５に送信する。ＥＣＵ１はネットワーク２５を介してハンドル操作量や転舵角を取得し、インバータ２２−２〜４を介するモータ２３−２〜４の制御内容を計算する。計算値は制御指令として、ネットワーク２５を介してＥＣＵ２〜４に送信する。ＥＣＵ２〜４はＥＣＵ１からの制御指令に基づき、モータ２３−２〜４を制御する。

図３はシステム状態特定の処理フローである。このフロー中の処理は、各ノードがネットワーク１００を介して相互に通信し同期を取って進められる。

まずステップ３１にてノード状態判定部１５−ｘは、各ノードについての状態を自ノード単独で判定する（ＭＯＮ１）。ノード状態判定（ＭＯＮ１）結果は、各ノードに関する障害有無である。障害の項目は複数設定してもよい。

次にステップ３２にてシステム状態判定部１８−ｘは、ステップ３１で得られたノード状態判定結果を入力すなわち判断材料の１つとし、システム状態を自ノード単独で判定する（ＭＯＮ２）。

次にステップ３３にてノード状態交換部１６−ｘは、ステップ３１で得られたノード状態判定結果を、Ｉ／Ｆ１３−ｘを利用して各ノード間で交換する（ＥＸＤ１）。各ノードは、自ノードを含む各ノードによる、各ノードに対する状態判定（ＭＯＮ１）結果を集約し保持することになる。同様に、システム状態交換部１９−ｘは、ステップ３３で得られたシステム状態判定結果を、Ｉ／Ｆ１３−ｘを利用して各ノード間で交換する（ＥＸＤ２）。各ノードは、自ノードを含む各ノードによる、システム状態判定（ＭＯＮ２）結果を集約し保持することになる。

次にステップ３４にて、ノード状態特定部１７−ｘは、ステップ３３で各ノードに集約されたノード状態判定結果から、多数決処理などにより各ノードの状態を特定する（ＩＤ１）。同様に、システム状態特定部２０−ｘは、ステップ３３で各ノードに集約されたシステム状態判定結果から、多数決処理などによりシステム状態を特定する（ＩＤ２）。

図４は、図３の処理フローを実施した場合のデータフローである。上位レイヤ４０は、制御アプリケーションなどのソフトウェアが該当する。上位レイヤ４０に対し、ノード状態特定部１７−ｘによるノード状態特定（ＩＤ１）結果と、システム状態特定部２０−ｘによるシステム状態特定（ＩＤ２）結果とは、ＡＰＩ（Application Program Interface）などのインターフェースを介して提供される。ノード状態判定部１５−ｘによるノード状態判定（ＭＯＮ１）結果や、システム状態判定部１８−ｘによるシステム状態判定（ＭＯＮ２）結果を、上位レイヤ４０に提供しても良い。

ノード状態やシステム状態の認識は、ノード状態特定結果やシステム状態特定結果をもとになされる。この状態遷移の管理は、ノード状態特定部１７−ｘやシステム状態特定部２０−ｘで行っても良いが、上位レイヤ４０にて制御アプリケーションとは分離した「状態遷移管理部」として実装することもできる。状態遷移はシステムごとに異なる部分であり、状態遷移管理部を上位レイヤ４０に実装した場合、システム状態特定を担うミドルウェアやハードウェアの汎用性が高まる。自己診断機能も上位レイヤ４０に実装し、その結果のみをノード状態判定部１５−ｘに提供すればよい。以上のように状態認識に関する機能が上位レイヤ４０との機能分担をした際には、システムに応じて変更が必要になるのはほぼ、システム状態判定部１８−ｘに限定される。逆に、システム状態判定部１８−ｘをシステムに応じて設定することで、柔軟で複雑な状態認識が可能になる。

図５は、図３の処理フローにおける各処理を、通信サイクルに合わせてノード間で同期して実行する場合の、処理進行の一例である。図３の処理フローは繰り返し実行されるが、１回の実行を１ラウンドと呼ぶことにする。通信サイクルｉ（ｉは整数）ではラウンドｒ（ｒは整数）のノード状態判定（ＭＯＮ１）とシステム状態判定（ＭＯＮ２）が実行される。通信サイクルｉ＋１では、ラウンドｒのノード状態交換（ＥＸＴ１）とシステム状態交換（ＥＸＴ２）が実行されると平行して、ラウンドｒ＋１のノード状態判定（ＭＯＮ１）とシステム状態判定（ＭＯＮ２）が実行される。また、ラウンドｒのノード状態特定（ＩＤ１）とシステム状態特定（ＩＤ２）が実行される。通信サイクルｉ＋２では、ラウンドｒ＋１のノード状態交換（ＥＸＴ１）とシステム状態交換（ＥＸＴ２）が実行されると平行して、ラウンドｒ＋２のノード状態判定（ＭＯＮ１）とシステム状態判定（ＭＯＮ２）が実行される。また、ラウンドｒ＋１のノード状態特定（ＩＤ１）とシステム状態特定（ＩＤ２）が実行される。以降の通信サイクルでも同様に処理が進行する。

このようなパイプライン的な処理実行により、各通信サイクルにて、ノード状態特定（ＩＤ１）とシステム状態特定（ＩＤ２）の結果を得ることができる。

以下では、システム状態特定の処理例として、システム開始を取り上げ説明する。具体的には、各ノードが初期診断を行った後、制御を開始するタイミングを決める処理である。

図６はシステム開始に関係する、ノードの詳細な状態遷移図とシステム状態遷移図の一部である。ノード詳細状態は対象ノードｘに対する状態認識であり、各ノード（ノード１〜ｎ）について状態が認識し管理される。ノード詳細状態もシステム状態も、各ノードがそれぞれ個別に認識し管理している。

ノード詳細状態遷移にて、全てのノードは最初に初期状態６１−ｘにある。遷移条件Ｎ１は、ノード状態特定（ＩＤ１）にて対象ノードｘの正常（異常がないこと）が確認されることである。遷移条件Ｎ１が満たされると、対象ノードｘの状態は初期状態６１−ｘから正常６２−ｘとなる。遷移条件Ｎ２は、ノード状態特定（ＩＤ１）にて対象ノードｘの異常が確認されることである。遷移条件Ｎ２が満たされると、対象ノードｘの状態は正常６２−ｘから異常６３−ｘとなる。遷移条件Ｎ３は、システム状態特定（ＩＤ２）にて対象ノードｘの起動不可についてノード間で合意が取れる（認識が一致化する）ことである。具体的には例えば、システム状態特定（ＩＤ２）にて多数決処理を実行することができ、起動不可と判定するノードが過半数となることである。各ノードはノード状態特定（ＩＤ１）にて、初期状態６１−ｘにある対象ノードｘの異常を所定回数（ラウンド）ｐの間連続して確認すると、システム状態判定（ＭＯＮ２）にて対象ノードｘを起動不可と判定する。遷移条件Ｎ３が満たされると、対象ノードｘの状態は初期状態６１−ｘから起動不可６４−ｘとなる。

システム状態は最初に初期状態６５にある。遷移条件Ｓ１は、全てのノードに関するノード詳細状態が初期状態６１−ｘでなくなることである。遷移条件Ｓ１が満たされると、システム状態は初期状態６５から正常６６となる。この遷移はシステム開始（制御開始）を意味する。システム状態に対する認識はノード間で一致化されているので、システム開始のタイミングもノード間で一致化される。システム開始後は、各ノードに対するノード詳細状態の認識に応じて、各ノードが自律的に制御モードを選択し実行する。所定回数ｐは、システム開始までの最大待ち時間を決定するため、ｐの値を変更することでシステム開始時に許容する待ち時間を調整し、一定時間以内にシステムを開始することができる。

以上の状態遷移に関する処理により、各ノードはノード詳細状態とシステム詳細状態を共有し、安定してシステムを開始できる。

図２のステアバイワイヤに上記のシステム開始処理を適用した場合の、システム挙動の例を以下に示す。電源投入により各ＥＣＵ（２１−１〜４）が起動を試みるが、ＥＣＵ１（２１−１）は故障により起動できないのに対し、ＥＣＵ２〜４（２１−２〜４）は起動成功し、初期診断を完了してそれぞれのタイミングでシステム開始の待機に入ったとする。ＥＣＵ２〜４はシステム開始待機に入った時点で、ネットワーク２５上で通信できているので、ノード詳細状態は正常（６２−２〜４）と互いに認識する。これに対し、ＥＣＵ１はＥＣＵ２〜４から所定時間後に、システム状態判定（ＭＯＮ２）により起動不可と判定され、さらにシステム状態特定（ＩＤ２）で合意が取れ、起動不可６４−１と見なされる。これにより遷移条件Ｓ１が満たされ、システム状態は正常６６となり、起動したＥＣＵ２〜４にてステアリング制御が開始される。このとき、ＥＣＵ２〜４はＥＣＵ１の起動不可を特定しているため、通常制御ではなくバックアップ制御を実施する。この場合のバックアップ制御として例えば、ＥＣＵ２が検出したハンドル２６操作量を、ＥＣＵ３〜４はネットワーク２５から直接取り込み、比例制御のような簡易制御を行う方法がある。もしＥＣＵ１がシステム開始後に起動しても、システム状態特定（ＩＤ２）により自ノードが他ノードから起動不可と認識されていることを知るので、シャットダウンし制御を乱さないようにすることもできる。

以上の結果、あるＥＣＵが故障した場合でも残りのＥＣＵは故障ＥＣＵの起動を待ち続けることなく、一定時間以内に足並みを揃えてシステム（制御）を開始することができ、適切な制御モードを選択することができる。

図７は、上記のシステム開始処理を実現するための、図６とは異なるノード詳細状態遷移とシステム状態遷移である。各ノードは初期化完了して一定時間経過した後、正常６２−ｘであるノードが所定数ある場合、システム状態判定（ＭＯＮ２）にてシステム開始可能を判定する。遷移条件Ｓ２は、システム状態特定（ＩＤ２）にてシステム開始可否について合意が取れること、である。遷移条件Ｓ２が満たされると、システム状態は初期状態６５から正常６６となる。遷移条件Ｎ４は、ノードが初期状態６１−ｘにある際に、遷移条件Ｓ２が成立すること、である。遷移条件Ｎ４が成立すると、ノード詳細状態は初期状態６１−ｘから異常７１−ｘになる。この異常７１−ｘ状態は、起動不可を含む。

システム上には、図６の状態遷移管理を行うノードと、図７の状態遷移管理を行うノードが混在しても良い。この場合、遷移条件Ｓ２は、遷移条件Ｓ１が成立すること、とすればよい。また１つのノード内で、図６のノード詳細状態管理を適用する対象ノードと、図７のノード詳細状態管理を適用する対象ノードとを分けても良い。このように柔軟なシステム構成を取る事が可能であるが、状態管理部の差異は上位レイヤ４０で吸収できる。

図８はシステム状態特定の処理フローであり、図３と異なるもう１つの処理方法である。このフロー中の処理は、各ノードがネットワーク１００を介して相互に通信し同期を取って進められる。

まずステップ８１にて、ノード状態判定部１５−ｘは、各ノードについての状態を自ノード単独で判定する（ＭＯＮ１）。次にステップ８２にて、ノード状態交換部１６−ｘは、ステップ８１で得られたノード状態判定結果を、Ｉ／Ｆ１３−ｘを利用して各ノード間で交換する（ＥＸＤ１）。次にステップ８３にて、ノード状態特定部１７−ｘは、ステップ８２で各ノードに集約されたノード状態判定結果から、多数決処理などにより各ノードの状態を特定する（ＩＤ１）。

次にステップ８４にてシステム状態判定部は、ステップ８３で得られたノード状態特定結果を入力すなわち判断材料の１つとし、システム状態を自ノード単独で判定する（ＭＯＮ２）。次にステップ８５にてシステム状態交換部１９−ｘは、ステップ８４で得られたシステム状態判定結果を、Ｉ／Ｆ１３−ｘを利用して各ノード間で交換する（ＥＸＤ２）。次にステップ８６にてシステム状態特定部２０−ｘは、ステップ８５で各ノードに集約されたシステム状態判定結果から、多数決処理などによりシステム状態を特定する（ＩＤ２）。

図９は、図８の処理フローを実施した場合のデータフローである。システム状態判定部への入力がノード状態判定（ＭＯＮ１）結果ではなく、ノード状態特定（ＩＤ１）結果である点が、図３と異なる。ノード状態特定結果は、ノード状態判定結果より信頼性が高いので、システム状態特定（ＩＤ２）結果は、図３より図８の処理フローの方が信頼性は高くなる。

図１０は、図８の処理フローにおける各処理を、通信サイクルに合わせてノード間で同期して繰り返し実行する場合の、処理進行の一例である。通信サイクルｉではラウンドｒのノード状態判定（ＭＯＮ１）が実行される。通信サイクルｉ＋１では、ラウンドｒのノード状態交換（ＥＸＴ１）が実行されると平行して、ラウンドｒ＋１のノード状態判定（ＭＯＮ１）が実行される。また、ラウンドｒのノード状態特定（ＩＤ１）とその結果を入力とするシステム状態判定（ＭＯＮ２）が実行される。通信サイクルｉ＋２では、ラウンドｒのシステム状態交換（ＥＸＴ２）と、ラウンドｒ＋１のノード状態交換（ＥＸＴ１）が実行されると平行して、ラウンドｒ＋２のノード状態判定（ＭＯＮ１）が実行される。また、ラウンドｒのシステム状態特定（ＩＤ２）と、ラウンドｒ＋１のノード状態特定（ＩＤ１）とその結果を入力とするシステム状態判定（ＭＯＮ２）が実行される。以降の通信サイクルでも同様の処理が継続される。

このようなパイプライン的な処理実行により、各通信サイクルにて、ノード状態特定（ＩＤ１）とシステム状態特定（ＩＤ２）の結果を得ることができる。

以下では、システム状態特定の処理例として、システム終了を取り上げ説明する。図１１はシステム終了に関係する、ノード詳細状態とシステム状態の遷移図の一部である。ここではシステム終了の条件として、遷移条件Ｓ３とＳ４を考慮している。遷移条件Ｓ３は、ノード詳細状態が異常６３−ｘであるノードが所定数以上になること、である。遷移条件Ｓ４は、システム終了に関してシステム状態特定（ＩＤ２）にて合意が成立すること、である。Ｓ３とＳ４のいずれかが成立すると、システム状態は正常６６から終了１２１に移り、各ノードは終了処理を行い、システムを停止する。

図２のステアバイワイヤに上記のシステム終了処理を適用した場合の、システム挙動の例を以下に示す。ＥＣＵ１（２１−１）は自己診断機能によりシステム運用をこれ以上継続するのは危険だと判断したとする。ＥＣＵ１はＩ／Ｆ１３を介し、システム終了要求をＥＣＵ２〜４（２１−２〜４）に対し送信する。各ＥＣＵはノード状態判定（ＭＯＮ１）にて、ＥＣＵ１がシステム終了要求を出していること、言い換えると、ＥＣＵ１がシステム終了要求を出す状態であることを認識する。次に各ＥＣＵは、システム状態判定（ＭＯＮ２）にて、システム終了要求に応じるか否かを決定する。この決定内容をＥＣＵ間で交換し（ＥＸＴ２）、確定する（ＩＤ２）。これによりシステム状態特定（ＩＤ２）の結果がシステム終了となる場合には、遷移条件Ｓ４が成立する。以上の結果、必要時にシステム終了を確実に実施することができる。

以下では、システム状態特定の処理例として、あるノードがシステム運用中に途中から参加するケースを取り上げ説明する。図１２はシステム終了に関係する、ノード詳細状態とシステム状態の遷移図の一部である。ここではノード詳細状態として異常６３−ｘから正常６２−ｘに戻ることを仕様上認めている。その遷移条件Ｎ５は、ノード状態特定（ＩＤ１）にて対象ノードｘの正常が確認されたこと、でよい。または、各ノードはノード状態判定（ＭＯＮ１）もしくはノード状態特定（ＩＤ１）にて対象ノードｘの正常を確認すると、対象ノードｘについてシステムへの再参加を認めるか否かをシステム状態判定（ＭＯＮ２）にて判断することとして、そのシステム再参加可否についてシステム状態特定（ＩＤ２）にて合意が取れ、その結果が再参加可のとき、としても良い。

システムの遷移条件Ｓ５は、ノード詳細状態がＥＣＵ１については異常６３−ｘとなり、ＥＣＵ２〜４については正常６２−ｘとなること、である。遷移条件Ｓ６は、ＥＣＵ１〜４すべてについてノード詳細状態が正常６２−ｘとなること、である。

ＥＣＵ１〜４の状態が正常６２−ｘであるとき、システム状態は通常制御モード１２１である。このときに、ＥＣＵ１が動作不良を起こし、リセットしたとする。このときＥＣＵ２〜４はノード状態特定（ＩＤ１）からＥＣＵ１の異常を認識し、ＥＣＵ１の状態を異常６３−ｘとする。これにより遷移条件Ｓ５が成立し、システム状態は通常制御モード１２１から、ＥＣＵ２〜４によるバックアップ制御モード１２２に遷移し、ＥＣＵ２〜４はバックアップ制御モードに切り替える。その後、ＥＣＵ１のリセットが完了し再起動すると、ＥＣＵ２〜４はノード状態特定（ＩＤ１）からＥＣＵ１の正常を認識し、ＥＣＵ１の状態を正常６２−ｘとする。さらにＥＣＵ２〜４はシステム状態判定（ＭＯＮ２）でＥＣＵ１の再参加を許可する判断を行い、システム状態特定（ＩＤ２）で合意する。これにより遷移条件Ｓ６が成立し、システム状態はバックアップ制御モード１２２から、通常制御モード１２１に遷移し、ＥＣＵ１〜４は通常制御モードを同期して実行する。以上の結果、あるノードのシステムへの途中参加を許容しつつ、高信頼な制御モード選択を可能にする。

図１３は本実施例の他の実施例をなすシステムである、電気自動車の一部の概略構成を示している。システムはＥＣＵ１〜４（１３１−１〜４）の４ノード構成であり、各ＥＣＵはネットワーク１３５で接続されている。ＥＣＵ３〜４はそれぞれインバータ１３２−３〜４を持ち、モータ１３３−３〜４を制御している。モータ１３３−３〜４はそれぞれ、駆動力伝達機構１３４−３〜４を介して車軸１３８−１〜２を回転させ、前輪１３９−１〜２と後輪１３９−３〜４を駆動する。インバータ１３２−３には電力回生が可能であり、インバータ１３２−４は回生をしないとする。ＥＣＵ１は、運転手によるアクセルペダル１３６とブレーキペダル１３７の操作量をセンサから検出し、ＥＣＵ３〜４に対する制御指令値を計算して、ネットワーク２５に送信する。ＥＣＵ２はモータ１３３−３〜４の駆動動力を発生させるためのバッテリー電源１３８に対し残量などの状態を監視し、その結果をネットワーク２５に送信する。ＥＣＵ３〜４はＥＣＵ１からの制御指令に基づき、インバータ１３２−３〜４およびモータ１３３−３〜４を制御する。

以下では、システム状態特定の処理例として、あるノードがシステム運用中に離脱するケースを取り上げ説明する。図１４はノード途中離脱に関係する、ＥＣＵ３（１３１−３）およびＥＣＵ４（１３１−４）のノード詳細状態と、システム状態の遷移図の一部である。インバータ１３２−３が発熱により温度上昇したとき、ＥＣＵ３はインバータ１３２−３の温度異常を検出し、インバータ１３２−３を一時的に休止させる必要性を判断し、インバータ休止要求をネットワーク１３５に送信する。各ＥＣＵはノード状態判定（ＭＯＮ１）にて、インバータ１３２−３の休止要求（ＥＣＵ３が休止要求を発する状態にあること）を認識する。各ＥＣＵはシステム状態判定（ＭＯＮ２）にて、インバータ１３２−３の休止可否を判断し、システム状態特定（ＩＤ２）にて合意する。ＥＣＵ３の詳細状態にて、遷移条件Ｎ６は前記のインバータ休止要求に関してシステム状態特定（ＩＤ２）にて休止可となること、である。遷移条件Ｎ６が成立すると、ＥＣＵ３の状態は正常１４１から一時休止１４２となり、ＥＣＵ３はインバータ１３２−３を休止させる。また、システム状態の遷移条件Ｓ７は、ＥＣＵ３が一時休止状態１４２となり、他ＥＣＵが正常状態であること、である。遷移条件Ｓ７が成立すると、システム状態は通常制御モード１４５からバックアップ制御モード１４６に遷移し、ＥＣＵ１，２，４は後輪駆動のみを前提として車両制御を行う。

以下ではノード途中離脱の別のケースを、図１４を用いて説明する。各ＥＣＵは、ＥＣＵ２から送信されるバッテリー電源１３８の残量を受信し、その残量が所定の閾値を下回ったとき、ノード状態判定（ＭＯＮ１）にてバッテリー電源残量低下（ＥＣＵ２が残量低下を検出していること）を認識し、ノード状態特定（ＩＤ１）により確定する。ＥＣＵ１は電力消費量を抑える必要性を判断し、低消費電力モードへの切替要求を各ＥＣＵに発する。各ノードはＥＣＵ１からの切替要求を受けて、低消費電力モードへの切替可否を判断する。このＥＣＵ１による切替要求の判断から、各ＥＣＵによる切替可否の判断までが、一連のシステム状態判定（ＭＯＮ２）と言う事ができる。各ＥＣＵはシステム状態特定（ＩＤ２）にて、低消費電力モードへの切替可否を確定する。この確定条件は、ＥＣＵ１〜４がすべて切替可と判断することとする。

ＥＣＵ４の詳細状態における遷移条件Ｎ７、およびシステム状態の遷移条件Ｓ８は、低消費電力モードへ切替可であることが、システム状態特定（ＩＤ２）にて合意されることである。このとき、ＥＣＵ４は正常状態１４３からスリープ状態１４４に遷移し、ほとんど電力を消費しなくなる。システム状態は通常制御モード１４５から低消費電力モード１４７になり、ＥＣＵ１〜３は前輪駆動のみを前提として車両制御を行う。

以上の結果、あるノードの途中離脱を許容しつつ、高信頼な制御モード選択を可能にする。

分散システムを応用した制御システムは、自動車や建設機械，ファクトリーオートメーションなどの幅広い工業分野で活用されており、今後も適用範囲の拡大が期待される。それらの分散型制御システムに本発明を適用することで、ノード間のシステム状態に関する認識不一致を防止し、安定したシステム運用が可能になる。また本発明はミドルウェアに実装することで、特別な装置の追加なしに低コストに実施できる。

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

Claims (1)

1. 複数のノードがネットワークを介して接続される分散システムにおいて、
   前記複数のノードの各々は、
   前記ネットワークの通信状態又は通信データから各ノードの障害の有無を示すノード状態を判定するノード状態判定部と、
   前記ノード状態判定部によるノード判定結果を、前記ノード間で前記ネットワークを介した送受信により交換するノード状態交換部と、
   前記ノード状態交換部が集約したノード状態判定結果から前記ノード状態を特定するノード状態特定部と、
   前記複数のノードの制御モードを示すシステム状態を判定するシステム状態判定部と、
   前記システム状態判定部によるシステム状態判定結果を、前記ノード間で前記ネットワークを介した送受信により交換するシステム状態交換部と、
   前記状態交換部が集約したシステム状態判定結果からシステム状態を特定するシステム状態特定部と、を備え、
   前記システム状態判定部は、システム状態を判定するための入力として、前記ノード状態特定部によるノード状態特定結果を利用することを特徴とする分散システム。

Images