JP4871687B2 - 車両制御システム - Google Patents

Description

本発明は、ネットワークを介して複数の電子制御装置が接続された車両制御システムに関する。

近年、自動車の運転快適性や安全性の向上を目指して、機械的な結合ではなく、電子制御により、運転者のアクセル，ステアリング，ブレーキなどの操作を車両の駆動力，操舵力，制動力発生機構に反映させる車両制御システムの開発が活発になっている。このようなシステムでは、自動車内に分散した複数の電子制御装置(ＥＣＵ：Electronic Control Unit) がネットワークを介してデータをやり取りして協調動作を行うようになる。このとき、同一ネットワーク内のあるＥＣＵに障害が発生した際に、残りの正常なＥＣＵが、どのＥＣＵに障害が発生したかを正確に特定し、障害箇所に応じた適切なバックアップ制御を行うことが、フェールセーフ上必要不可欠となる。なお、本明細書では以下、ネットワークに接続されたＥＣＵをノードと記載することもある。

上記課題を解決するために、システムを構成する各ノードがネットワーク内の他ノードの状態を監視する従来技術として、特開２０００−４７８９４に記載のものがある。

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

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

本発明は、以上のような課題に鑑みてなされたものであり、システム内の監視のための特別なノードを設けることなくネットワーク内の障害ノードを正確に特定できる車両制御システムを提供することを目的とする。

前記課題を解決するために、本発明では、通信経路を介して接続された複数の車載機器を備えた車両制御システムにおいて、前記複数の車載機器は、それぞれ、自己以外の他の車載機器の状態を診断し、自己が診断した他の車載機器の状態を、他の車載機器との間で交換し、自己が診断した他の車載機器の状態と、他の車載機器から取得した他の車載機器の状態とに基づいて、他の車載機器の状態を判定する構成とした。

さらに他の発明では、通信ネットワークに接続された複数のノードが、当該通信ネットワークを介してデータの伝送を行うことにより車両の機能を実現する車両制御システムにおいて、前記複数のノードが、自らの動作状態及び前記通信ネットワークに接続された他のノードの動作状態を含むノード状態を判定するノード状態判定手段と、前記ノード状態判定手段により自らが判定した前記ノード状態判定結果を他ノードに送信し、他のノードが判定したノード状態判定結果を受信する状態判定結果送受信手段、および前記自らが判定したノード状態判定結果および受信した前記他のノードによるノード状態判定結果とを用いて、前記通信ネットワーク内の障害ノードを特定する障害ノード特定手段とを備えることとした。

本発明によれば、各ノードの状態判定を統括するマスタノード（サーバー）や共有するデータを保持するノード(共有ディスク)を設ける必要がなくなり、一般的な制御用ＥＣＵで構成されたシステムで上記のような判定が可能となるので、低コストで障害ノードを正確に特定することが可能となる。

また、ネットワークの障害判定だけでは検出できない障害。すなわち、通信は正常に実行されているが、ノード内でのソフトウェアの処理内容などに異常がある場合も含んだ障害の有無（データリンク層の上位階層までを含んだ障害の有無）を判断することができる。

さらに、このような障害ノード監視機能をミドルウェアで実装する場合には、制御アプリケーションは所定のＡＰＩ(Application Program Interface) によりノード状態情報を取得することができるようになるため、制御アプリケーションソフトウェアの開発効率を向上させることが可能となる。

以下、図面に基づき、本発明の車両制御システムの実施形態について説明する。

始めに、図１から図４を用いて、本発明の車両制御システムの基本構成を説明する。本発明の車両制御システムは、図１に示すように、複数のノード、すなわちノード１(Ｎ１)，ノード２（Ｎ２）・・・，ノードｎ（Ｎｎ）から構成されており、これらのノードがネットワーク１００を介して接続されている。ここで、ノードとはネットワークに接続され、当該ネットワークを介して情報通信可能な処理装置であり、具体的には、車両に搭載された各種の電子制御装置，アクチュエータドライバ，センサ等が含まれる。ネットワーク１００は多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して同一内容を同時に送信するブロードキャスト送信が可能な構成となっている。

各ノードＮ１，Ｎ２・・・，Ｎｎ（以下Ｎｘ）は、ノード状態判定手段ｘ１（１１，
２１・・・，ｎ１），状態判定結果送受信手段ｘ２（１２，２２・・・，ｎ２）及び障害ノード特定手段ｘ３（１３，２３・・・，ｎ３）を備える。ここで、ｘはノード番号（１，２・・・，ｎ）であり、以下同様に記載する。

ノード状態判定手段ｘ１（１１，１２・・・，ｎ１）は、自ノードの状態を判定する自ノード状態判定手段ｘ１０２（１１０２，２１０２・・・，ｎ１０２）と同一ネットワーク内にある他のノードの状態を判定する他ノード状態判定手段ｘ１０１（１１０１，2101・・・，ｎ１０１）とを有する。ここで「自ノード状態」とは自ノードの自己診断結果を指すものとし、「他ノード状態」とは、判定をするノードからみて他の各ノードから送信されるデータが正しいか否かの状態を指すものとする。例えばノード１からみてノード２の「他ノード状態」が正常であると判定されるためには、ノード２のハードウェアが正常動作し、ノード２の演算処理が正常に行われ、さらにノード２からノード１への通信が誤り無く行われる必要がある。なお他ノード状態の判定方法の詳細については後述するが、例えば、全てのノードが通信サイクルごとに通番データのインクリメントを行ってブロードキャスト送信する構成とすることにより、特定のノードから受信した通番データがインクリメントされていない場合に当該ノードの「他ノード状態」が異常であると判断できる。また、以下の実施例においては、上述の「自ノード状態」と「他ノード状態」とを合わせたネットワーク全体のノードの状態を「ノード状態」と記載する。

状態判定結果送受信手段ｘ２（１２，２２・・・，ｎ２）は、前記ノード状態判定手段ｘ１により判定されたノード状態（自ノードが判定したノード状態）を他ノードに送信する送信処理手段ｘ２０３（１２０３，２２０３・・・，ｎ２０３），他ノードが判定したノード状態を受信する受信処理手段ｘ２０２（１２０２，２２０２・・・，ｎ２０２）、及び上述の自ノードによるノード状態判定結果及び他ノードによるノード状態判定結果を格納する状態判定結果格納手段ｘ２０１（１２０１，２２０１・・・，ｎ２０１）を有する。

障害ノード特定手段ｘ３（１３，２３・・・，ｎ３）は、自ノードによる状態判定結果と前記状態判定結果送受信手段ｘ２により受信した他ノードによる状態判定結果を用いて障害ノードを特定する。

図２を用いて、上述の状態判定結果送受信手段ｘ２の機能について詳述する。図２に示すように、状態判定結果送受信手段ｘ２は、自ノードによる状態判定結果と、受信した他ノードによる状態判定結果とを格納する状態判定結果格納手段ｘ２０１を備える。例えば、ノード１の状態判定結果格納手段１２０１内のバッファ１４１に保存されたノード１による状態判定結果は、ネットワーク１００を介して、同一ネットワーク内のノード１を除く全ノードに配信され、各ノードの状態判定結果格納手段ｘ２０１内のバッファｘ４１
（ここでは、２４１，３４１・・・，ｎ４１）に保存される。ノード２からノードｎによる状態判定結果の送受信についても同様である。

したがって、各ノードの状態判定結果格納手段ｘ２０１は同一ネットワーク内のノード数分（図２ではｎ個）のバッファを備えている。このように構成することで、全てのノードによるノード状態の判定結果を格納し比較することが可能となり、特定のノードによる判定結果を信用してよいか否かを判断することが可能となる。例えば、ノード１がノード２を「故障」と判定している場合であっても、他のノード２〜ｎがノード２を「正常」と判定している場合には、ノード１の方が故障しているという判定をすることも可能となる。

図１に示す各ノード（Ｎ１，Ｎ２・・・，Ｎｎ）の基本構成を、図３を用いて説明する。図３ではノード１を例に挙げて説明しているが、本構成はネットワーク内の全てのノードで同一である。ノード１は、前述の通り、ノード状態判定手段１１の構成要素である他ノード状態判定手段１１０１，自ノード状態判定手段１１０２，状態判定結果送受信手段１２の構成要素である状態判定結果格納手段１２０１，受信処理手段１２０２，送信処理手段１２０３，障害ノード特定手段１３、ネットワークアクセス手段１６、および制御ロジック実行手段１７を備えている。

図３においては、ノード１はネットワークアクセス手段１６により、例えばノード２が送信したデータを受信している。ノード２の送信データには、ノード２による状態判定結果Ｓ２が含まれる。他ノード状態判定手段１１０１は状態判定結果Ｓ２のデータの合理性をチェックすることにより、ノード２の状態を判定し、判定結果Ｅ１１を状態判定結果格納手段１２０１内の自ノードによる状態判定結果格納用バッファ１４１に格納する。これらのデータに異常がない場合は、ノード２による状態判定結果Ｓ２（自己診断結果＋ノード１，３〜ｎの判定結果）はノード２による状態判定結果格納用バッファ１４２に保存される。他ノード状態判定手段１１０１は、同様に、ノード３からノードｎの状態判定を行い、各々の判定結果Ｅ１ｎを自ノードによる状態判定結果格納用バッファ１４１に格納し、各ノードの状態に異常が無ければそれらのノードによる状態判定結果Ｓ３〜Ｓｎを所定のバッファ１４３（図示せず）〜１４ｎに保存する。

障害ノード特定手段１３は、バッファ１４１から１４ｎに格納されたデータを用いて障害ノードを特定し、その結果を制御ロジック実行手段１７に通知する。自ノード状態判定手段１１０２は、ノード１自体のＣＰＵ，メモリ，周辺入出力回路などの自己診断結果
Ｅ１２を自ノードによる状態判定結果格納用バッファ１４１に格納する。ノードがセンサ、アクチュエータを制御し、これらの状態を診断している場合は、Ｅ１２にはノード自体の自己診断結果だけでなく、センサ、アクチュエータ等の診断結果を含めてもよい。本診断結果Ｅ１２は、制御ロジック実行手段１７にも通知される。送信処理手段１２０３は、自ノードによる状態判定結果Ｓ１を一つの通信データとして送信する。

状態判定結果格納バッファ１４１から１４ｎに格納される状態判定結果のデータ構造を図４に示す。状態判定結果は、ノード１からノードｎの各ノードの状態データから構成される。各ノードの状態は、障害１から障害ｍそれぞれの有無で表現されている（障害内容の具体例については後述する）。各障害の有無の判定および判定結果の所定領域への格納は他ノード状態判定手段ｘ１０１が行うが、自ノード状態の領域には、前述のように、自ノード状態判定手段ｘ１０２による判定結果が格納される。なお、図４では判定結果を便宜上「有」「無」と記載したが、実際には所定のビット数の数字で表現される。

図５および図６を用いて、他ノード状態判定の実施例について説明する。図５は、図３で示したノード１の基本構成に、他ノード状態判定を行うためのノード障害検出符合付加手段１８を加えたものである。図６は、図５における枠Ｒ内及び枠Ｓ内の動作の詳細を、ノード２を送信側（Ｓ）、ノード１を受信側（Ｒ）として記載したものである。

図５において、ノード障害検出符号付加手段１８は、自ノードによる状態判定結果Ｓ１それぞれに、これらのデータを受信する他ノードにおいてノード１の障害を検出するための符号ＣＳ１を付加する。送信処理手段１２０３は、自ノードによる状態判定結果Ｓ１にヘッダ部を付加し、さらにネットワーク障害検出符号付加手段１９０１により、この通信データが他ノードに配信される途中、ネットワーク１００上で何らかの障害が発生したかどうかを検出するためのネットワーク障害検出符号ＣＰ１を付加する。

例えばノード２からの通信データを受信する場合、受信処理手段１２０２内のネットワーク障害判定手段１９０２は、ノード２のネットワーク障害検出符号付加手段２９０１が付加したネットワーク障害検出符号ＣＰ２とＣＰ２以外のデータ部を用いて、通信データが配信されるときにネットワーク１００上でビット反転などによるデータ変化が発生していないかを判定する。他ノード状態判定手段１１０１は、ノード２のノード障害検出符合付加手段２８が付加した符号ＣＳ２およびＳ２を用いてノード２の障害発生有無を判定し、この判定結果Ｅ１１およびネットワーク障害判定手段１９０２からの判定結果Ｅ１３を、自ノードによる状態判定結果バッファ１４１のノード２状態の領域に格納する。ネットワーク障害判定手段１９０２が自ノードによる状態判定結果バッファ１４１に直接アクセスして結果を格納してもよい。

ノード障害検出符号付加手段，他ノード状態判定手段，送受信処理手段の詳細を図６に示す。図６では、ノード２が障害検出符号を付加したデータを送信し、これをノード１が受信し、障害を判定する実施例を示している。ノード障害検出符号付加手段２８は、ノード２による状態判定結果Ｓ２に対する通番付加部２８３，サム値付加部２８４を備える。通番付加部２８３は、データを送信するたびにデータに付加した通番をインクリメントする。サム値付加部２８４は、さらに、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値をサム値として付加する。送信処理手段２２０３が備えるフレーム処理部２９０３は、障害検出符号を付加したＳ２に対してヘッダ付加等の通信プロトコル処理を行う。その後、ネットワーク１００上で通信データがビット反転などにより破壊されていないかを検出するために、公知のＣＲＣ（巡回冗長検査）符号を付加する（２９０１１）。

ノード１はノード２からデータを受信後、ノード２での障害検出符号付加順番とは逆の順番で障害検出を行う。ネットワーク障害判定手段１９０２では、フレーム未受信判定部１９０２２およびＣＲＣ異常判定部１９０２１により、データ未受信やデータ破壊などのデータリンク層における障害を検出する。図示していないが、同期エラー、フォーマットエラーなど通信プロトコルレベルの障害も本ネットワーク障害判定手段１９０２で行う。障害が検出された場合は、判定結果Ｅ１３を他ノード状態判定手段１１０１のネットワーク障害判定結果受信部１１０１１に送信する。一方、他ノード状態判定手段１１０１は、Ｓ２に対して、サム値異常判定部１１０１５、通番異常判定部１１０１６により、データ自体の合理性をチェックし、ノード２の状態を判定する。サム値異常判定部１１０１５は、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値が、送信側のサム値付加部でデータに付加したサム値と一致するか否かを判定する。また、通番異常判定部１１０１６は、今回の受信データに付加されている通番が前回の受信データの通番からインクリメントされているか否かを判定する。以上のいずれの判定部においても異常が検出されなかった場合に、Ｓ２は状態判定結果格納手段１２０１の所定領域に格納される。異常が検出された場合は、当該異常を検出した判定部の上位の異常判定は行わない。

本実施例の構成によれば、ノード１でサム値異常が検出された場合は、ノード２のサム値付加部以下またはノード１のサム値異常判定部以下でのデータ転送時、あるいは、ノード２の送信処理手段またはノード１の受信処理手段における処理実行時に障害が発生し、データが変化したことを示しているので、従来のネットワーク障害判定手段だけでは検出できないこれらの障害を検出することが可能となる。

また本実施例の構成によれば、ノード１で通番異常が検出された場合は、何らかの障害によりノード２で通番のインクリメントができない、あるいはノード１の通番異常判定処理実行時に障害が発生したことを示している。後述するように、制御ロジック実行手段とノード障害検出符号付加手段をソフトウェアにより実装する場合、例えば、ノード２の車両制御ソフトウェアが無限ループ等によりＣＰＵリソースを独占してしまった場合には、ノード障害検出符号付加ソフトウェアは通番をインクリメントできなくなるため、ノード１の通番異常判定部ではノード２でソフトウェアの障害が発生したことを検出することができる。

従って、車両制御ソフトウェア障害時には、当該ソフトウェアにより生成される送信データは更新されないにもかかわらず、送信バッファに保存されているデータが送信され続けるため、受信ノードのネットワーク障害判定手段１９０２はデータを正常に受信できていると判断してしまうが、本実施例の構成によれば、ネットワーク障害（データリンク層での障害）は発生していないけれども特定のノード内部の処理内容が誤っているような故障状態をも正確に監視することが出来る。

以上詳述したように、本実施例における車両制御システムは、通信データが正常に受信できたか否かを判定するネットワーク障害判定手段による判定結果に加えて、ノード障害検出符号付加手段および他ノード状態判定手段を用いて通信データ自体の合理性をチェックすることにより得られる、ネットワーク障害判定手段だけでは検出できない、ソフトウェアの稼動状況などデータリンク層の上位階層の障害有無までを含んだノード状態判定結果を他ノードと相互に交換するように構成しているため、低コストで障害ノードを正確に特定することが可能となる。

図７は、ノード状態監視機能を実現するフローチャートを示している。本フローチャートの処理は、各ノードで実行される。

ステップＳ１００で処理を開始し、ステップＳ１１０では、各種通信障害の有無をもとに、自ノードによるノードの状態判定を行う。このステップＳ１１０の処理をＭＯＮとする。ステップＳ１２０では、ステップＳ１１０の状態判定結果をグループ内の他ノードに送信（放送）する。また、他ノードによるノード状態判定結果を受信する。このステップＳ１２０の処理をＥＸＤとする。

ステップＳ１３０では、自他ノードによる状態判定（ＭＯＮ）結果から、ノードごと・障害種類ごとに障害有無を確定させる。このステップＳ１３０の処理をＩＤとする。

ステップＳ１８０では、ステップ１３０で得たノード障害情報を、ノード上で動作する諸プログラムに通知する。通知の方法は、特定記憶領域の値を書き換えるなどにより行う。このノード障害情報は、ノードごと・障害種類ごとの障害有無が含まれ、ノードが異常・障害ありということだけでなく、ノードが正常・障害なしということもわかる。ノード上で動作する諸プログラムとしては、制御ロジック、ノード状態の表示、ノードの状態ロガーなどが考えられる。

ステップＳ１８０のノード障害情報通知の際には、ＩＤの結果をそのまま通知してもよいし、後述のように障害カウンタを挟んで通知してもよい。ステップＳ１９０で処理を終了する。

図８および図９を用いて、ここまで説明してきたノード状態判定手段ｘ１、自ノードによるノード状態判定結果送信手段および他ノードによるノード状態判定結果受信手段ｘ２、および障害ノード特定手段ｘ３それぞれによる処理の実行タイミングの実施例について説明する。

図８は、各ノードの送受信タイミングと上記処理の実行タイミングを示したタイムチャートである。一つの通信単位（以下通信サイクルと記載）において、ノード１からノードｎまでが順番にデータを送信し、各ノードが自ノード及び他の全ノードのノード状態を判定する。この通信サイクルを繰り返すことで、各ノードが判定した全ノードのノード状態判定結果を相互に交換し、比較することが可能となる。このような通信形態は、例えば、車両制御用の時分割多重通信であるＴＴＰ通信やＦｌｅｘＲａｙ通信などを用いて実現することができる。

繰り返される通信サイクルの中のあるサイクルを表示するものとして、通信サイクルｉと通信サイクルｉ＋１を例にとって説明する。

通信サイクルｉでは、各ノードにおいて自ノード単独でネットワーク内ノードの状態判定処理（ＭＯＮ（ｉ））を行う。まず、ノード１がｓｎｄ処理（送信処理）で前記の各種障害検出符号を付加したデータを送信後、ノード２以下のノードはこのデータをｒｃｖ処理（受信処理）Ｓｘ１１（Ｓ２１１，Ｓ３１１・・・，Ｓｎ１１）で受信し、前述の方法（図３〜図６参照）によりノード１の状態判定を行う。次にノード２がｓｎｄ処理で前記の各種障害検出符号を付加したデータを送信し、ノード１及びノード３〜ｎがこのデータをｒｃｖ処理Ｓｘ１２（Ｓ１１２，Ｓ３１２・・・，Ｓｎ１２）で受信し、前述の方法
（図３〜図６参照）によりノード２の状態判定を行う。以下、ノード３〜ｎも同様に順次データを送信し、当該データを受信した他のノードが当該データを送信した送信ノードの状態判定を行う。通信サイクルｉの状態判定処理（ＭＯＮ（ｉ））が終了した時点では、各ノードの状態判定結果格納手段ｎ２０１には、自ノード状態と他ノード状態を含むネットワーク全体のノード状態を自ノードが判定した結果が格納されている。この時点では各ノードは自ノード単独による判定結果しか保持していないため、他ノードによる判定結果と比較することが出来ない。このため、あるノードが特定の他ノードの障害を検出したとしても、検出した障害が本当に当該他ノードの障害を意味している場合と、自ノードが障害を起こして誤判定をしている場合とが考えられ、これらを判別することはできない。

そこで、次の通信サイクルｉ＋１では、各ノードが保持している自ノードによる状態判定結果Ｓｎをノード間で相互交換し、各ノードが自ノードによる判定結果と自分以外の全ての他ノードによる判定結果を格納する。

まず、ノード１がｓｎｄ処理Ｓ１４１で自ノードによるノード状態判定結果Ｓ１を送信し、ノード２〜ｎがこのデータをｒｃｖ処理Ｓｘ４１(Ｓ２４１,Ｓ３４１・・・,Ｓｎ41)で受信する、以下ノード２〜ｎも同様にｓｎｄ処理Ｓ２４２・・・，Ｓｎ４ｎにより、各ノードは通信サイクルｉにおける自ノードによるノード状態判定結果Ｓｎ（ｉ）を送信する。

なお、この送信データは図５に示すように、通信サイクルｉにおける判定結果Ｓｎに各種障害検出符号Ｃｓｎ等を付加したものである。ここで受信ノードは、ｒｃｖ処理Ｓｘ41，Ｓｘ４２・・・，Ｓｘ４ｎにより送信データを受信し、障害検出符号Ｃｓｎの解析により当該送信ノードの状態判定を行って、当該判定結果を通信サイクルｉにおける自ノードによる判定結果として格納する。そして、上記の判定結果が正常である場合は、当該データに含まれる当該他ノードによる状態判定結果Ｓｎ（通信サイクルｉ）を格納する。

これにより、通信サイクルｉにおけるノード状態判定結果Ｓｎの交換（ＥＸＤ（ｉ））を行うとともに、通信サイクルｉ＋１における自ノードによるノード状態判定（ＭＯＮ
（ｉ＋１））を行うことが出来る。

ノード状態判定結果Ｓｎの交換（ＥＸＤ）が終了すると、その後、処理Ｓｘ３において、自ノードによる状態判定結果（通信サイクルｉ）と通信サイクルｉ＋１で受信した他ノードによる状態判定結果Ｓｎ（通信サイクルｉ）を用いて最終的に障害ノードを特定する。障害ノードを特定するアルゴリズムについては後述するが（図１０〜図１４）、例えば多数決を用いることができる。また、ネットワークに接続されたノードのうち、所定の個数若しくは割合以上のノードによって障害発生と判定されたノードを障害ノードと判定することもできる。

すなわち各ノードは、通信サイクル１の前半では、自ノードによるノード状態判定結果送信および他ノードによるノード状態判定結果受信処理（状態判定結果交換：ＥＸＤ）を行い、後半では、障害ノード特定処理（ＩＤ）を行う。以上のように、本実施例によれば、ある通信サイクルで検出された障害を次の通信サイクルで特定することができる。図９に示すように、このような通信と判定を繰り返すことで、通信サイクルｉでは、通信サイクルｉ−１における状態判定結果の交換（ＥＸＤ（ｉ−１））と通信サイクルｉにおける自ノードによるノード状態判定（ＭＯＮ（ｉ））が行われ、通信サイクルｉ−１における障害発生ノードの特定処理（ＩＤ（ｉ−１））が行われることになる。

なお、自ノードによる自ノード状態判定結果（例えばノードｎによるノードｎの状態）は、障害発生ノードの特定処理では用いないことが望ましい。すなわち、ノード１の障害判定においてはノード２乃至ノードＮによる判定結果を用いて特定処理が行われ、ノード２の障害判定においては、ノード１及びノード３乃至ノードｎによる判定結果を用いて特定処理が行われることが望ましい。これは、自ノードによる自ノード状態判定結果を多数決に加えると、そのノードに異常が発生している場合には、異常をきたした判定結果が多数決に加わることになり、判定精度を低下させるおそれがあるからである。

但し、多数決には使われないとしても、各ノードが自ノード状態の判定を行い、他のノードに送信（放送）することには意味がある。すなわち、各ノード上で動作するアプリケーションプログラムが、当該ノードが故障しているか否かを認識した上で制御ロジック等を選択することが出来るからである。

なお、上述の実施例では、便宜上ノード１からｎまで順番に送信を行う構成としたが、一回の通信サイクルの中で各ノードが一回ずつ自ノードによる判定結果Ｓｎを送信する構成であれば、ノード１〜ｎがデータを送信する順番は問わない。また通信サイクルごとに送信順序が入れ替わっても問題はない。

図１０から図１４を用いて、障害ノード特定手段ｘ３の実施例について詳述する。図
１０は障害ノード特定手段ｘ３の構成を示したものであり、説明の便宜のためノード１の構成として記載している。他のノード２〜ｎの障害ノード特定手段ｘ３（２３・・・，
ｎ３）も同様の構成である。障害ノード特定手段（ノード１）１３は、障害ノード特定アルゴリズム実行部１３１，障害カウンタ１３２，障害カウンタリミット値到達判定部133，障害カウンタリミット値設定部１３４，ノード障害フラグ格納部１３５から構成されている。

障害カウンタリミット値設定部１３４およびノード障害フラグ格納部１３５は、制御ロジック実行手段１７からアクセスが可能である。障害ノード特定アルゴリズム実行部131は、状態判定結果格納手段１２０１が保持する自ノードによる状態判定結果および他ノードによる状態判定結果を用い、所定のアルゴリズム(図１１，図１２参照)に従って、障害ノードおよび障害の種類を特定し、障害カウンタ１３２の該当するカウンタをカウントアップする。障害カウンタリミット値到達判定部１３３は、各々のカウンタの値が、制御ロジック実行手段１７が障害カウンタリミット値設定部１３４に設定したリミット値に達したか否かを判定し、達した場合には、ノード障害フラグ格納部１３５の達したカウンタに該当するノード障害フラグをセットする。制御ロジック実行手段１７は、ノード障害フラグ格納部１３５にアクセスすることにより、各ノードの障害有無を知ることができ、この情報に応じた制御の切り替えが可能となる。また、障害カウンタリミット値設定部１３４を備えたことにより、制御ロジック実行手段１７が設定したリミット値、すなわち制御上許容できる障害検出時間に達するまでは、当該実行手段１７に対して障害をマスクしておくことができる。

図１１は障害カウンタ１３２の動作の一例を示したものである。図１１では、通信サイクルｉのノード２の送信時刻よりも後の時刻でノード２に障害１が発生し、この障害が通信サイクルｉ＋４のノード２の送信時刻よりも後の時刻まで続く場合を示している。ノード２の障害１に対する障害カウンタリミット値は３であるとする。通信サイクルｉ＋１においてノード２以外の各ノードで検出されたノード２の障害は、通信サイクルｉ＋２前半でのＥＸＤ処理を経て、通信サイクルｉ＋２後半のＩＤ処理で確定し、該当する障害カウンタがインクリメントされる。同様に、通信サイクルｉ＋２および通信サイクルｉ＋３においてもノード２の障害が検出されるため、通信サイクルｉ＋４のＩＤ処理の結果カウンタ値がリミット値の３に達し、該当するノード障害フラグがセットされる。障害が継続している間は、障害カウンタは３を保持し、ノード障害フラグもセットされたままである。その後、通信サイクルｉ＋５においてノード２の障害が検出されなくなると、通信サイクルｉ＋６のＩＤ処理によりノード２の正常状態復帰が確定し、該当する障害カウンタおよびノード障害フラグがリセットされる。以上説明した障害カウンタの動作は、他のノードでも同様であるため、全てのノードの制御ロジック実行手段ｘ７は、あるノードの障害発生時あるいは正常復帰時に同時に制御を切り替えることができる。

図１２に二種類の障害カウンタの実施例を示す。障害発生後、正常状態に復帰した際に、復帰型障害カウンタ１３２Ａは、カウンタをデクリメントするのに対して、累積型障害カウンタ１３２Ｂは、デクリメントせずにそのまま値を保持する。復帰型障害カウンタ
１３２Ａは、ある通信サイクルにおいて正常と判断される度にカウンタの値が減算されるため、障害の発生により一時的にカウンタ値が増大したとしても、障害が解消して正常なノード状態が持続すればカウンタ値はゼロに戻る。従って、ある程度の期間にわたって障害が連続しないとノード障害フラグがセットされないため、ＣＲＣ符号のエラーなど、通信回線の性質上一定確率で発生するエラーであるが低頻度であるため制御ロジックの実行に影響がないエラーを制御ロジック実行手段に対してマスクすることができる。

一方、累積型障害カウンタ１３２Ｂを用いる場合は、ノードが正常に戻ってもカウンタの値は減算されることが無いので、ノード状態が異常と判断される度に値が増大していく。従ってハーネスのコネクタの半嵌合や接触不良などに起因する間欠障害を確実に検出するのに有効である。なお、制御ロジック実行手段が制御に応じて、使用する障害カウンタの種類を選択できるようにしてもよい。

図１３は障害ノード特定アルゴリズム実行部１３１における処理フローを示したものである。なお説明の便宜上、ノード１の障害ノード特定アルゴリズム実行部１３１における処理を示しているが、他のノードにおける処理も同様である。

障害ノード特定アルゴリズム実行部１３１は、ノード１からノードｎまで順番にノード状態を判定する。ノードｘに対する障害判定処理Ｓ１ｘを行う際には、障害ノード特定アルゴリズム実行部１３１は、ノードｘを除く全ノードのノードｘに関する状態判定結果を状態判定結果格納手段１２０１から読み出す。ただし、障害が検出されたノードによる状態判定結果は使用しない。ノードｘに対する障害判定処理Ｓ１ｘは、読み出した状態判定結果を用いて、障害ごとに障害発生判定処理Ｓ１ｘＥ１，Ｓ１ｘＥ２・・・，Ｓ１ｘＥｍを実行する。

図１４に障害発生判定処理フローの実施例を示す。ノード２に対する障害１発生判定処理Ｓｔｅｐ１２Ｅ１を例にとっているが、本図１４の処理フローはすべての障害発生判定処理において同様である。ノード２に対する障害１発生判定処理Ｓｔｅｐ１２Ｅ１は、まず処理Ｓｔｅｐ１で自ノードによる障害判定結果を参照し、ノード２で障害１が発生と判定したか否かをチェックする。障害１が発生していない、すなわち正常と判定している場合には、処理Ｓｔｅｐ２において、障害１発生と判定した他ノードの数が、制御ロジック実行手段により設定された判定閾値Ｘよりも小さいかどうか、すなわち多数ノードが正常と判定しているかどうかを判断する。小さい場合は、ノード２で障害１は発生しておらず正常という判定Ｄｉａｇ１になる。さらに、処理Ｓｔｅｐ３において、障害１発生と誤って判定したノードがあるかどうかを判断し、そのようなノードがある場合には、ノード２に障害１発生と判定したノードに障害が発生という判定Ｄｉａｇ２Ａになる。処理Step３において、誤った判定をしたノードがない場合は、ノード２に対する障害１発生判定処理Ｓｔｅｐ１２Ｅ１を終了し、次のノード２に対する障害２発生判定処理Ｓｔｅｐ１２Ｅ２に進む。処理Ｓｔｅｐ２において、障害１発生と判定した他ノードの数が判定閾値Ｘ以上の場合は、ノード２に障害１発生という判定Ｄｉａｇ３になる。

一方、処理Ｓｔｅｐ１において、自ノードがノード２で障害１発生と判定している場合には、処理Ｓｔｅｐ４に進み、障害１発生と判定した他ノード数が判定閾値Ｘ以上か、すなわち自ノードの判定に賛同しているノード数が判定閾値Ｘ以上かどうかを判断する。判定閾値Ｘ以上の場合は、処理Ｓｔｅｐ２におけるＮｏの場合と同様に、ノード２に障害１発生という判定Ｄｉａｇ３になる。処理Ｓ４において、障害１発生と判定した他ノード数が判定閾値Ｘより小さい場合には、自ノードの判定に賛同しているノードが少数のため、自ノードも含め、ノード２に障害１発生と判定したノードに障害発生という判定Ｄｉａｇ２Ｂになる。これは、処理Ｓｔｅｐ３による、多数ノードの判定に賛同しない少数派のノードに障害発生という判定Ｄｉａｇ２Ａと対をなす判定である。障害発生ノードおよび障害種類が特定された場合、すなわち判定Ｄｉａｇ２Ａ，Ｄｉａｇ２Ｂ，Ｄｉａｇ３の場合は、処理Ｓｔｅｐ５により、該当する障害カウンタをインクリメントして、ノード２に対する障害１発生判定処理Ｓｔｅｐ１２Ｅ１を終了する。

なお、判定Ｄｉａｇ２Ａ，Ｄｉａｇ２Ｂ，Ｄｉａｇ３ならば即、障害ありとしてノード上の諸プログラムに通知する場合には、Ｓｔｅｐ５は行わなくてよい。

本実施例では、制御ロジック実行手段が、制御するシステムにおけるノードの多重障害をどこまで許容できるかに応じて判定閾値Ｘを設定することができる。例えばノード総数ｎのシステムでＸ＝ｎ−２と設定すれば、２ノードの障害までは残りの正常なノード間で正しく障害ノードを特定することができる。また、本実施例のアルゴリズムでは、あるノードの状態について自ノードが正常であると判定したにもかかわらず、異常であると判定したノードが多数となり自ノードの判定が少数派となった場合（処理Ｓ２のＮｏの場合）でも、判定Ｄｉａｇ２Ｂとは異なり、自ノードに障害ありとは判定しないようにしている。

以上説明してきた本発明における個々の要素の実施例を総合した二つの実施例を図１５および図１６に示す。これらの図、各ノードの送信タイミングと送信データ，障害発生タイミングを表すタイムチャート、および障害発生時の各ノードの状態判定結果格納手段
ｘ２０１，障害カウンタｘ３２，ノード障害フラグｘ３５の変化を示したものである。二重線で囲ったデータは送信データであることを示す。簡単のため、送信データとしては、状態判定結果のみを図示しているが、実際には状態判定結果とともに制御データも送信しているものとする。同一ネットワーク内のノード数は４、制御ロジック実行手段が設定する障害ノード特定アルゴリズム実行部ｘ３１の判定閾値Ｘは３，障害カウンタリミット値は２とする。各ノードの状態は、通番異常（Ｅ１），サム値異常（Ｅ２），ＣＲＣ異常
（Ｅ３），フレーム未受信（Ｅ４）という４種類の障害の有無で表される。なお、本実施例において、各ノードの自ノード状態判定結果は０であり、各ノードとも自ノードは正常であると判定しているものとする。

図１５では、通信サイクルｉ＋１のスロット１の時間帯において、ノード３にＣＰＵの障害が発生し、ソフトウェアの動作に異常が生じたことを想定している。ノード３は通信サイクルｉにおける状態判定結果をスロット３で送信することになっているが、ノード障害検出符号付加手段３８は、ＣＰＵ障害のため、通番をインクリメントすることができない。したがって、他のノードはノード３からの状態判定結果受信時に、通番がインクリメントされていないことを検出し、ノード３に通番異常が発生したと判定する。しかし、この時点では、ノード３の障害を検出しても、自ノード単独の判定であるため、ノード３の障害なのか、自ノードの判定誤りなのかを正確に特定することはできない。そこで、次の通信サイクルｉ＋２で、ノード１，２，４は、自ノードによる状態判定結果００８０（ノード３の通番異常）を送信する。各ノードは、通信サイクルｉ＋２の後半で、ノード１，２，４による状態判定結果を用いて、図１４に示した障害ノード特定アルゴリズムを実行する。これにより、ノード３の通番異常が確定するため、ノード１、２、４は障害カウンタＥ１＿３をカウントアップする。ノード３の障害は通信サイクルｉ＋２以降も継続しているため、通信サイクルｉ＋３でも同様にして障害カウンタＥ１＿３がカウントアップされ、当該障害カウンタの値がリミット値に達したため、ノード障害フラグの該当箇所がセットされる。

図１６では、通信サイクルｉ＋１のスロット３の時間帯において、ノード２に受信部の障害が発生したことを想定している。ノード２は、通信サイクルｉ＋１でノード３からのデータを受信できないため、ノード３に障害が発生したと判定し、通信サイクルｉ＋２で自ノードによる状態判定結果００１０（ノード３の送信データ未受信）を送信する。しかし、ノード１，４はノード３からのデータを正しく受信しているため、状態判定結果0000を送信する。したがって、ノード３の送信データ未受信障害の発生判定処理において、ノード２に障害が発生したことが確定し、障害カウンタＥ４＿２がカウントアップされる。ノード２も他ノードの状態判定結果から自ノードに障害が発生したことが分かり、自ら自ノードの障害カウンタＥ４＿２をカウントアップする。ノード２は通信サイクルｉ＋２では正常復帰しているため、復帰型障害カウンタの場合は、通信サイクルｉ＋３でカウンタ値が０に戻る。

なお、図１５，図１６に示す送信データ（フレーム）の構成では、各ノードの状態および障害カウンタとして、通番異常（Ｅ１），サム値異常（Ｅ２），ＣＲＣ異常（Ｅ３），フレーム未受信（Ｅ４）という４種類の障害を示しているが、信頼性向上のためにネットワークを二重化しているシステムでは、ネットワーク１系でフレーム未受信（Ｅ１），ネットワーク１系でフレーム異常（Ｅ２），ネットワーク２系でフレーム未受信（Ｅ３），ネットワーク２系でフレーム異常（Ｅ４）というようにネットワークの系ごとに障害を分類する構成も考えられる。ここで、フレーム異常とは、何らかのフレームを受信したが、そのフレームに通信プロトコルで定めたフォーマットエラー，ＣＲＣエラー，通番異常，サム値異常などが含まれていることを示している。

図１５，図１６では、各ノードで障害カウンタのカウントアップが同時に実行されるため、同時にノード障害フラグがセットされ、制御アプリケーションに障害が通知される。しかし、ノード間で障害カウンタの値が完全に一致せずに、制御アプリケーションに障害を通知するタイミングがノードごとにずれてしまう可能性が考えられる。制御アプリケーションは障害通知に基づいてバックアップ制御処理を実行するため、この場合は、通常時制御処理からバックアップ制御処理に移行するタイミングがノードごとにずれることになり、バックアップ制御を正常に実行できない可能性がある。例えば、あるノードにおいて、障害ノード特定手段における処理中に何らかの過渡的エラーが発生した場合には、障害カウンタを正しくインクリメントあるいはデクリメントすることができなくなり、他ノードの障害カウンタ値との間にずれが生じる。また、途中でリセットされたノードでは障害カウンタが０に初期化されてしまう。

図１７は、障害カウンタ値が上記のような理由によりノード間で一致していない場合においても、同時にアプリケーションに障害を通知することのできる実施例を示したものである。図１７では、ノード３が障害によりフレームを送信できないときに、その他のノードは前述のように障害ノード特定アルゴリズムによりノード３からのフレーム未受信障害を特定し、ノード３未受信障害カウンタＥ４＿３をカウントアップしているが、ノード２の障害カウンタＥ４＿３の値がノード１，ノード４のそれと一致していない場合を想定している。本実施例では、未受信障害カウンタのリミット値は１０であるとする。

ノード１およびノード４の障害カウンタＥ４＿３は、通信サイクルｉ＋１の障害ノード特定処理後にリミット値−１の９になる。両ノードは次の通信サイクルｉ＋２、つまり障害カウンタがリミット値に到達する通信サイクルにおいて、障害通知同期フラグをセットしたフレーム（以下、障害通知同期フレームと記載する）を送信する。ノード２はこのフレームを受信することにより、障害ノード特定処理前に障害カウンタ値をリミット値−１の９に補正する。したがって、本実施例によれば、障害カウンタ値がノード間で一致していない場合でも、制御アプリケーションへの障害通知タイミングを正常な全ノード間で同期させることができる。

これを実現するための送信フレーム構成例（ノード１の場合）を図１８に示す。送信フレームは、前述のノード状態判定結果Ｓ１、および障害通知同期フラグフィールドSync1から構成される。障害通知同期フラグフィールドＳｙｎｃ１では、各ノードの障害カウンタについて、カウンタ値がリミット値−１になったか（１）、否か（０）を表している。図１７の実施例において、ノード１およびノード４は通信サイクルｉ＋２で、図１８に示すように、障害通知同期フラグフィールドＳｙｎｃ１のノード３未受信障害カウンタ
（Ｅ４＿３）のビットをセットしたフレームを送信する。

常時障害カウンタ値そのものをノード間で交換して障害カウンタ値を一致化する場合は、障害カウンタのビット数×エラー要因×ノード数分の通信データ量が必要となるが、実際には常時ノード間で障害カウンタ値を一致させる必要はなく、本実施例のように制御アプリケーションへの障害通知タイミングだけを合わせれば良い。本実施例においては、エラー要因×ノード数分だけの通信データ量で済むため、少ない通信データ量でノード間の制御アプリケーションへの障害通知タイミングを同期させることができる。

障害通知同期フレームを、障害カウンタ値がリミット値−１に達した次の通信サイクルだけでなく、リミット値に達した後も送信し続けることにより、より確実にノード間での障害通知タイミング同期を実現することが可能となる。

図１９では、ノード３が障害によりフレームを送信できなくなり、ノード２，ノード４において、ノード３未受信障害カウンタＥ４＿３がリミット値に達したため、ノード３障害時のバックアップ制御を行っているときに、通信サイクルｉ＋１でノード１が新たに通信に加入、あるいはリセット処理等から復帰して通信に再加入した場合を想定している。ノード３未受信障害カウンタＥ４＿３がリミット値に達した後もノード２およびノード４は障害通知同期フレームを送信し続けているため、ノード１は、障害カウンタがリミット値１０に達するまでノード２およびノード４とは異なる通常時制御処理を継続することなく、通信に加入した通信サイクルで即座にリミット値を９に補正することができ、バックアップ制御に移行することが可能となる。

図２０では、通信サイクルｉ＋１でノード４がノード３未受信障害に関する障害通知同期フレームを送信し、ノード２はこの同期フレームを受信したが、ノード１は受信できなかった場合を示している。ノード２はこの通信サイクルで障害カウンタ値を９に補正し、障害ノード特定処理後に制御アプリケーションに障害を通知する。これにより、ノード２は次の通信サイクルｉ＋２で障害通知同期フレームを送信する。ノード１はこの通信サイクルでは、ノード２あるいはノード４から障害通知同期フレームを受信することができるので、通信サイクルｉ＋１でノード４からの障害通知同期フレームの受信に失敗しても、次の通信サイクルでは他ノードと同様にバックアップ制御に移行することができる。

図１７，図１９および図２０に示した実施例では、障害通知同期フレームを送信するのは、障害カウンタ値がリミット値−１に達した次の通信サイクルであるが、障害カウンタがリミット値に達した、すなわち制御アプリケーションに障害を通知した次の通信サイクルでも良い。ただし、この場合にはノード間で１通信サイクル時間分の障害通知タイミングのずれが生じる可能性があるため、通信サイクル時間を車体運動の時定数に比べて十分小さくしておく必要がある。また、図２０では、障害カウンタ値がリミット値−１に達したノードが一つでもあれば、他ノードはこのノードが送信する障害通知同期フレームに合わせて自ノード内の障害カウンタ値を補正するようにしているが、例えば正常ノードのうち、半数以上のノードから障害通知同期フレームを受信した場合のみ、障害カウンタ値を補正するように構成しても良い。

各ノードのソフトウェアおよびハードウェア構成の実施例を図２１に示す。本実施例では、本発明の障害ノード監視機能を、車両制御ロジックを実行するための制御アプリケーションソフトウェアの下位に位置するミドルウェアにより実装している。ハードウェアは、ＣＰＵ１１００，通信コントローラ１２００，通信トランシーバ１３００から、ソフトウェアは、制御アプリケーション１４００，障害ノード監視ミドルウェア１５００，通信処理ミドルウェア１６００，通信コントローラドライバ１７００、およびリアルタイム
ＯＳ１８００から構成される。図６におけるパッキング処理、アンパッキング処理は通信処理ミドルウェア１６００により、ネットワーク障害検出符号付加処理，ネットワーク障害判定処理，フレーム処理、およびデータの送受信処理は、通信コントローラドライバ
１７００と通信コントローラ１２００により実行される。また、ネットワークアクセス手段ｘ６が通信トランシーバ１３００に相当する。

障害ノード監視ミドルウェア１５００は、ノード障害検出符号付加処理、他ノード状態判定処理、および障害ノード特定処理を実行し、制御アプリケーション１４００にノード状態情報を提供するためのＡＰＩ（アプリケーションプログラムインタフェース）を備える。また、下位側には、通信処理ミドルウェア１６００と通信コントローラドライバ1700とのインタフェースを有する。本実施例によれば、障害ノード監視機能をミドルウェアで実装することにより、制御アプリケーションは所定のＡＰＩによりノード状態情報を取得することができるようになるため、制御アプリケーションソフトウェアの開発効率を向上させることが可能となる。

以上の実施例においては、ネットワークトポロジーはバス型であったが、図２２に示すようにハブを介したスター型としても良い。さらには信頼性を高めるためにはネットワークを二重系にすることが好ましい。本実施例では、ノード１からノードｎは、メインのネットワーク１００Ａおよびバックアップのネットワーク１００Ｂの両方のネットワークに、各々ハブＨＡおよびＨＢを介して接続されている。

バス型では、ネットワークの切断時に、切断箇所によってはシステムを構成するノードのほぼ半分ずつのグループにシステムが分断されてしまう可能性があるのに対して、スター型の場合は孤立するノードは一つだけであるため、図１４に記載したような障害ノード特定アルゴリズムにより、孤立したノードを正確に特定することができる。

続いて、本発明のノード状態判定を車両制御システムに適用した実施例について説明する。

図２３に車両制御システムの実施例を示す。本実施例において車両１はステアリングとブレーキのバックアップ機構を備えているが、備えない車両制御システムでも同様な構成とすることができる。

本実施例の車両制御システム９０１は、ステアリング９５１の回転角度を測定する操舵角センサＳｅｎ１，ブレーキペダル９５２の踏み込み量を測定するブレーキペダル位置センサＳｅｎ２，アクセルペダルの踏み込み量を測定するアクセルペダル位置センサＳｅｎ３，前記運転者の要求を検出するセンサの信号から運転者の意図２１解釈し、図示していない車両状態を検出するセンサ(例えば加速度センサ，ヨーレートセンサ，車輪速センサ)からの信号に基づいて、車両運動を統合的に制御する車両運動統合制御ＥＣＵ９１０を備え、これらがそれぞれノードとしてメインネットワーク１００Ａに接続されている。

また、アクチュエータ駆動ノードとして、前輪の操舵力を発生するステアリングモータＭ１およびステアリングコラム軸上に取り付けられる可変ギア比（ＶＧＲ）機構に作用するモータＭ５を制御するＳＢＷ(Steer-by-Wire) ・ＶＧＲ−Driver−ＥＣＵ９１１、後輪の操舵力を発生するステアリングモータＭ２を制御するＳＢＷ−Driver−ＥＣＵ９１２，四輪のブレーキ力を生成するブレーキモータＭ３Ａ〜Ｍ３Ｄを制御するＢＢＷ(Brake-by-Wire)−Driver−ＥＣＵ９１３Ａ〜９１３Ｄ，車両の駆動系を総合的に制御するＤＢＷ
（Driver-by-Wire）系統合制御ＥＣＵ９２０，ダンピング力を調整するサスペンションモータＭ４Ａ〜Ｍ４Ｄを制御するＥＡＳ(Electronic Active Suspension)−Driver−ＥＣＵ９１４Ａ〜９１４Ｄがメインネットワーク１００Ａに接続されている。

さらに車両の外界の状態を検出するミリ波レーダ／カメラＳｅｎ４、およびエアバッグの展開を制御するエアバッグＥＣＵ９１５もメインネットワーク１００Ａに接続されている。

バックアップのネットワーク１００Ｂには、車両の安全な走行に関わる必要最小限のノード、すなわち、操舵角センサＳｅｎ１，ブレーキペダル位置センサＳｅｎ２，ＳＢＷ・ＶＧＲ−Driver−ＥＣＵ９１１，ＢＢＷ−Driver−ＥＣＵ９１３Ａ〜９１３Ｄが接続されている。

ＤＢＷ系統合制御ＥＣＵ９２０には、ネットワーク１０１を介して、エンジン制御
ＥＣＵ９２１，変速機制御ＥＣＵ９２２，モータ制御ＥＣＵ９２３，バッテリー制御
ＥＣＵ９２４が接続している。また、車両運動統合制御ＥＣＵ９１０は、ネットワーク
１０２を介して、カーナビ等の情報系の機器を制御するネットワークへの入口となる情報系ゲートウェイ９３０や、ドアロック，ドアミラー，各種メータ等のボディー系の機器を制御するネットワークへの入口となるボディー系ゲートウェイ９４０と接続されており、これらのノードとデータのやり取りをする。図示していないが、エアバッグＥＣＵ９１５も別の一端で、エアバッグ展開制御に必要な各種センサ、アクチュエータを統合する安全系のネットワークにつながっている。

本実施例において、車両運動統合制御ＥＣＵ９１０は、操舵角センサＳｅｎ１，ブレーキペダル位置センサＳｅｎ２，アクセルペダル位置センサＳｅｎ３，図示していない車両状態を検出するセンサ（例えば加速度センサ，ヨーレートセンサ，車輪速センサ）からの信号に基づいて、車両の走行制御のための舵角，制動力，駆動力などを演算し、前輪の
ＳＢＷ・ＶＧＲ−Driver−ＥＣＵ１１と後輪のＳＢＷ−Driver−ＥＣＵ１２に舵角指令を、四輪のＢＢＷ−Driver−ＥＣＵ９１３Ａ〜９１３Ｄに制動力指令を、ＤＢＷ系統合制御ＥＣＵ９２０に駆動力指令を送信する。ＤＢＷ系統合制御ＥＣＵ９２０は、この駆動力指令を受けて、エネルギー効率などを考慮して、エンジン，モータなど各々の駆動力発生源が発生するべき駆動力を演算し、演算した駆動力指令を、ネットワークＮ２を介してエンジン制御ＥＣＵ９２１，モータ制御ＥＣＵ９２３などに送信する。車両運動統合制御
ＥＣＵ９１０は、運転者の要求を検出するセンサの情報だけでなく、車両の外界の状態を検出するレーダまたはカメラＳｅｎ４の情報を用いることにより、先行車への追従走行、レーンキープ走行、危険回避運転等の制御を行うことができる。

図２４は、図２３のシステムから、ブレーキ制御システムに関連するノードを抜き出した簡略図である。本実施例のブレーキ制御システムは、運転者のブレーキペダル踏み込み量を測定するブレーキペダル位置センサの信号を処理してネットワーク１００に送信するブレーキペダルセンサ２，４輪のブレーキモータを制御するＢＢＷ−Driver−ＥＣＵ913A〜９１３Ｄ、およびブレーキペダルセンサ２の送信データや、図示していないが、車両状態を検出するセンサ（例えば加速度センサ、ヨーレートセンサ、車輪速センサなど）からの信号を用いて４輪のブレーキ力指令値を演算し、これをネットワーク１００を介して４輪のＢＢＷ−Driver−ＥＣＵ９１３Ａ〜９１３Ｄに送信する車両運動統合制御ＥＣＵ910から構成される。

ただし、本実施例で、ブレーキペダルＥＣＵ２は、一つの故障でも正常動作を継続することができるように、すなわちフェールオペレーショナルに構成されているものとする。

以下、このような、制御システムにおいて本発明のような診断方法を実現する場合の実施例について説明する。実際の制御システムに適用する場合には、各ノード間で送受信されるデータには、状態判定のための情報ＣＳｎ，状態判定結果Ｓ１〜Ｓｎとは別に、例えば車両運動統合制御ＥＣＵ９１０からＢＢＷ−Driver−ＥＣＵ９１３Ａ〜９１３Ｄに送られるブレーキ力指令値のような制御データＤが含まれる。以下、上記のようなシステムを構築する場合の各ノードの構成について、図２５〜図２８を用いて説明する。なお図２５〜図２７はそれぞれ図３，図５，図６と対応しており、特に言及しない構成要件については先に説明した実施例と同様である。

各ノードの基本構成を図２５に示す。ノード１を例に挙げて説明しているが、本構成はネットワーク内の全てのノードに共通である。本実施例では、ノード１は、図３で説明した構成に加えて、他ノードから受信した制御データを格納する受信データ格納手段１４、制御ロジック実行手段で演算されて他ノードに送信される制御データを格納する送信データ格納手段１５を備えている。

図２５においては、ノード１はネットワークアクセス手段１６により、例えばノード２が送信したデータを受信している。ノード２の送信データには、ノード２による状態判定結果Ｓ２に加えて、ノード２の制御ロジック実行手段２７が生成した車両制御に必要な制御データＤ２が付加されている。受信処理手段１２０２は、このデータを二つに分離して、他ノード状態判定手段１１０１にこれらを入力する。他ノード状態判定手段１１０１は、図３で説明したように、Ｓ２のデータの合理性をチェックすることにより、ノード２の状態を判定し、判定結果Ｅ１１を状態判定結果格納手段１２０１内の自ノードによる状態判定結果格納用バッファ１４１に格納する。このデータに異常がない場合は、制御データＤ２は受信データ格納手段１４に、ノード２による状態判定結果Ｓ２（自己診断結果＋ノード１、３〜ｎの判定結果）はノード２による状態判定結果格納用バッファ１４２に保存される。なお、他ノード状態判定手段１１０１は、ノード２による状態判定結果Ｓ２だけでなく、制御データＤ２のデータの合理性をチェックしてノード２の状態を判定する構成としてもよい。詳細は後述するが（図２６）、このようにすることで、データリンク層に留まらず、アプリケーション層での論理的なデータエラーまで検出することが可能となる。他ノード状態判定手段１１０１は、同様に、ノード３からノードｎの状態判定を行い、各々の判定結果Ｅ１ｎを自ノードによる状態判定結果格納用バッファ１４１に格納し、それらのノードによる状態判定結果を所定のバッファ１４３（図示せず）〜１４ｎに保存する。このとき、ノード３〜ｎの状態判定に異常が無ければ、ノード３〜ｎからの制御データＤ３〜Ｄｎをそれぞれ受信データ格納手段１４に格納する。なお障害ノード特定手段
１３，自ノード状態判定手段１１０２の処理は、図３で説明した実施例と同様である。

制御ロジック実行手段１７は、受信データ格納手段１４の制御データ、障害ノード特定手段１３からの情報、自己診断結果Ｅ１２、状態判定結果格納手段１２０１に格納されたノード状態判定結果等に基づき車両制御演算を行い、他ノードに送信する制御データＤ１を送信データ格納手段１５に格納する。送信処理手段１２０３は、制御ロジック実行手段１７が生成した制御データＤ１と自ノードによる状態判定結果Ｓ１を一つの通信データとして送信する。

図２６および図２７を用いて、他ノード状態判定の実施例について説明する。特に言及しない構成は図５で説明したものと同様である。ノード障害検出符号付加手段１８は、制御データＤ１および自ノードによる状態判定結果Ｓ１それぞれに、これらのデータを受信する他ノードにおいてノード１の障害を検出するための符号ＣＤ１，ＣＳ１を付加する。

送信処理手段１２０３は、制御データＤ１および自ノードによる状態判定結果Ｓ１を一つの通信データにまとめてヘッダ部を付加し、さらにネットワーク障害検出符号付加手段１９０１により、この通信データが他ノードに配信される途中、ネットワーク１００上で何らかの障害が発生したかどうかを検出するためのネットワーク障害検出符号ＣＰ１を付加する。

例えばノード２からの通信データを受信する場合、受信処理手段１２０２内のネットワーク障害判定手段１９０２は、ノード２のネットワーク障害検出符号付加手段２９０１が付加したネットワーク障害検出符号ＣＰ２とＣＰ２以外のデータ部を用いて、通信データが配信されるときにネットワーク１００上でビット反転などによるデータ変化が発生していないかを判定する。他ノード状態判定手段１１０１は、ノード２のノード障害検出符号付加手段２８が付加した符号ＣＤ２，ＣＳ２およびデータＤ２，Ｓ２を用いてノード２の障害発生有無を判定し、この判定結果Ｅ１１およびネットワーク障害判定手段１９０２からの判定結果Ｅ１３を、自ノードによる状態判定結果バッファ１４１のノード２状態の領域に格納する。ネットワーク障害判定手段１９０２が自ノードによる状態判定結果バッファ１４１に直接アクセスして結果を格納してもよい。

ノード障害検出符号付加手段、他ノード状態判定手段、送受信処理手段の詳細を図２７に示す。特に言及しない構成は図６と同様である。図２７では、ノード２が障害検出符号を付加したデータを送信し、これをノード１が受信し、障害を判定する実施例を示している。ノード障害検出符号付加手段２８は、制御データＤ２に対する通番付加部２８１，サム値付加部２８２、およびノード２による状態判定結果Ｓ２に対する通番付加部２８３，サム値付加部２８４を備える。通番付加部２８１，２８３は、データを送信するたびにデータに付加した通番をインクリメントする。サム値付加部２８２，２８４は、さらに、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値をサム値として付加する。送信処理手段２２０３が備えるパッキング・フレーム処理部2903′は、障害検出符号を付加したＤ２およびＳ２をパッキング処理して一つの通信データにまとめ、ヘッダ付加等の通信プロトコル処理を行う。その後、ネットワーク１００上で通信データがビット反転などにより破壊されていないかを検出するために、公知のＣＲＣ（巡回冗長検査）符号を付加する。

ノード１はノード２からデータを受信後、ノード２での障害検出符号付加順番とは逆の順番で障害検出を行う。ネットワーク障害判定手段１９０２では、フレーム未受信判定部１９０２２およびＣＲＣ異常判定部１９０２１により、データ未受信やデータ破壊などのデータリンク層における障害を検出する。図示していないが、同期エラー，フォーマットエラーなど通信プロトコルレベルの障害も本ネットワーク障害判定手段１９０２で行う。
障害が検出された場合は、判定結果Ｅ１３を他ノード状態判定手段１１０１のネットワーク障害判定結果受信部１１０１１に送信する。

一方、他ノード状態判定手段１１０１は、受信処理手段１２０２のアンパッキング・フレーム処理部１９０４′で分離されたデータＤ２およびＳ２それぞれに対し、Ｄ２については、サム値異常判定部１１０１２，通番異常判定部１１０１３、およびデータ差分異常判定部１１０１４により、制御データＤ２自体の合理性をチェックし、Ｓ２については、サム値異常判定部１１０１５，通番異常判定部１１０１６によりチェックし、ノード２の状態を判定する。サム値異常判定部１１０１２，１１０１５は、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値が、送信側のサム値付加部でデータに付加したサム値と一致するか否かを判定する。また、通番異常判定部11013，１１０１６は、今回の受信データに付加されている通番が前回の受信データの通番からインクリメントされているか否かを判定する。

データ差分異常判定部１１０１４は、今回と前回の受信データの変化分が、制御ロジック実行手段１７が設定するある閾値以上になっていないかを判定する。

以上のいずれの判定部においても異常が検出されなかった場合に、Ｄ２とＳ２はそれぞれ受信データ格納手段１４，状態判定結果格納手段１２０１の所定領域に格納される。異常が検出された場合は、当該異常を検出した判定部の上位の異常判定は行わない。また、この場合は、受信データ格納手段１４および状態判定結果格納手段１２０１に対するデータ更新は行わず、その旨を制御ロジック実行手段１７に通知する。

このように構成することで、本発明の診断処理を実行しながら、車両制御に必要な制御データを送受信することが可能となる。また、図５，図６を用いて説明した第一の実施例と同様の効果が得られるとともに、データ差分手段１１０１４により制御データＤ自体の合理性がチェックされるので、アプリケーション層での異常診断をすることが可能となる。

なお、ネットワーク１００，１００Ａの通信サイクル（周期）は、制御システムの制御周期（例えば、ブレーキ制御のフィードバック制御の制御周期）と少なくとも同じか、若しくはそれよりも短く設定される。従って、制御周期の方が通信サイクルよりも長い場合には、ある通信サイクルｉにおける制御データＤｘ（ｉ）が、その次の通信サイクルｉ＋１までに更新されていない場合がある。例えば、制御周期が通信サイクルの１０倍である場合は、制御データＤｘは通信サイクル１０回に一度しか更新されないことになる。

このような場合の制御データｘの送信方法として、第一に、毎回の通信サイクルにおいて制御データＤｘが更新されているか否かを問わず、一律に全てのサイクルで制御データＤｘを付加して送信する方法がある。例えば、制御周期が通信サイクルの１０倍である場合は、通信サイクル０〜９に付加される制御データＤｘは途中で障害が起きない限り同一であり、通信サイクル１０で始めて制御データが更新されることになる。この方法では、各ノードの送信処理において、制御データの更新の有無を考慮する必要がないので、各ノードの送信処理が容易になる。このような特徴は、例えばブレーキ制御，ステア制御のような複数の制御システムの制御周期が異なっているような場合には、複数の制御周期の存在を考慮せずに送信処理を行うことができるので、特に有効である。

制御周期の方が通信サイクルよりも長い場合における制御データｘの送信方法の第二の方法として、制御データＤｘが更新された通信サイクルのみ制御データＤｘを付加して送信し、制御データが更新されていない通信サイクルでは状態判定結果Ｓｘのみを送信する構成が考えられる。この方法によれば、通信するデータ量を削減することができるので、第一の構成に比べてネットワーク１００、１００Ａの通信容量を低く抑え、廉価なシステムを実現することができる。

以上の実施例では、図２８（ａ）に示すように（図２８において二重線で囲ったデータは送信データであることを示す）、制御データＤｘと状態判定結果Ｓｘを一体として（同一スロットで）送受信することを前提に説明してきたが、図２８（ｂ）のように、これらのデータを別々のスロットで送受信してもよい。

図２８（ｂ）では、通信サイクルの前半で制御データＤｘの送受信、後半で状態判定結果Ｓｘの送受信を行っている。このようにすることにより、（ａ）では通信サイクル期間全体にわたって全ノードの送信データを受信する必要があるのに対して、（ｂ）では通信サイクル前半の制御データ送受信フェーズにおいては、自ノードで実行する制御に必要なデータのみを受信すればよい。この場合には、図２６に示す構成において、状態判定結果Ｓｘの送受信処理と制御データＤｘの送受信処理とを別々に行うこととなる。

続いて、図２４に示すブレーキ制御システムに本発明を適用した場合の実施例を図２９を用いて説明する。

右前輪（ＦＲ）ブレーキモータ制御ＥＣＵ３の制御アプリケーション１４００におけるＦＲブレーキモータ制御処理の実施例を図２９に示す。ＦＲブレーキモータ制御処理は、まず処理Ｓｔｅｐ１１で障害ノード監視ミドルウェア１５００から自ＥＣＵの制御に関連する他ＥＣＵの状態情報を取得する。その後、処理Ｓｔｅｐ１２で自己診断により自ECUに障害が発生しているか否かを判定し、障害が発生している場合には、自ＥＣＵのリセット処理を行う。ＥＣＵがセンサ、アクチュエータを制御している場合は、自己診断だけでなく、センサ、アクチュエータの診断も行い、それらに異常がある場合には電源供給を停止するなどの処理を行う。

自ＥＣＵが正常な場合は、処理Ｓｔｅｐ１３で、処理Ｓｔｅｐ１１で取得した他ＥＣＵの状態情報からブレーキ制御ＥＣＵ１の障害有無を判定する。ブレーキ制御ＥＣＵ１が正常な場合は、処理Ｓｔｅｐ１４Ａにおいて、通常制御である、ブレーキ制御ＥＣＵから受信したブレーキ力指令値に基づいたモータ制御を行う。ブレーキ制御ＥＣＵ１に障害がある場合は、次に処理Ｓｔｅｐ１５でブレーキモータ制御ＥＣＵのいずれかに障害があるかどうかを判定する。いずれにも障害がない場合は、処理Ｓｔｅｐ１７Ｃに進み、ブレーキペダルＥＣＵ２から受信したブレーキペダル位置に基づき、４輪ブレーキ制御時のブレーキ力指令値を演算する。ブレーキモータ制御ＥＣＵのいずれかに障害がある場合は、処理Ｓｔｅｐ１６で障害箇所を特定する。障害箇所が左前輪または右後輪のブレーキモータ制御ＥＣＵの場合は、処理Ｓｔｅｐ１７Ｂにより、ブレーキペダルＥＣＵ２から受信したブレーキペダル位置に基づき、右前輪と左後輪を使った対角２輪ブレーキ制御時のブレーキ力指令値を演算する。障害箇所が左後輪のブレーキモータ制御ＥＣＵの場合は、処理Step１７Ａにより、ブレーキペダルＥＣＵ２から受信したブレーキペダル位置に基づき、右前輪と左前輪を使った前輪２輪ブレーキ制御時のブレーキ力指令値を演算する。処理Step
１７Ａ，Ｓｔｅｐ１７Ｂ，Ｓｔｅｐ１７Ｃによりブレーキ力指令値を自ＥＣＵで演算した後は、処理Ｓ１４Ｂに進み、この指令値に基づいてモータ制御を行う。

このように、本実施例によれば、制御アプリケーションは障害ノード監視ミドルウェアの提供するＡＰＩにより障害ＥＣＵを正確に特定することができるため、障害箇所に応じて制御を切り替えることができる。

以下、本発明の他の実施例について説明する。

上述の第一の実施例においては、同一ネットワークの全ノードからの状態判定結果を受信し、全ノードを障害監視の対象として障害ノードの特定を行っている。しかしながら、ノード数が増大するにつれて各ノードにおける受信処理や障害ノード特定アルゴリズム実行部１３１の演算量が増大することが予想される。従って、これらの処理をソフトウェアで行う場合はＣＰＵ処理負荷の増加につながる。

この課題を解決するために、本実施例では、ネットワーク内のノードをいくつかの相互監視グループに分け、そのグループに属するノード間で相互監視をするように構成している。このようにすることで各ノードの演算量を低減できる。以下、本実施例の詳細について説明する。

図３０に示すように、本実施例では同一のネットワーク１００に接続されるノードを４ノードずつグルーピングし、グループＡ，グループＢ・・・という相互監視グループを設ける。各グループではグループ内通信により、そのグループ内のノード間で、第一の実施例と同様のノード状態判定結果の交換を行い、グループ内の障害ノードを特定する。グループ間通信により、グループ内の相互監視で得られた障害ノード特定結果を他のグループに通知する。グループ内通信，グループ間通信ともに、ノード状態に関する情報だけでなく、同時に制御データの送受信も行っている。

図３１は、全ノード数が８のシステムで４ノードずつグルーピングし、グループＡ，グループＢという二つの相互監視グループを設けた場合の１通信サイクルにおける各ノード間のデータ送受信の実施形態について示したものである。グループＡに属するノードはノードＡ１〜Ａ４，グループＢに属するノードはノードＢ１〜Ｂ４である。図中の黒丸は、各ノードが送信したフレームをどのノードが受信するかを示している。また、図３０と同様に、点線はグループ内通信、実線はグループ間通信を表す。

通信スロット１から６では、前通信サイクルのグループ内相互監視で得られたグループ内ノード状態（障害の有無）を、グループＡ，グループＢ間で相互に交換している。このフェーズで交換するフレームをノードＡ１の送信フレームＡ１＿１を例にとって図３２に示す。自グループ内ノードの状態管理を自ノードの制御ロジック実行手段に行わせないようにしているのと同様に、これを他グループ内ノードにも行わせないようにするために、フレームＡ１＿１は、図１０に記載の制御ロジック実行手段１７に通知するノード障害フラグ格納部１３５の情報を送信するためのノード障害フラグフィールドＲｅｓｕｌｔＡ１を備える。ノード障害フラグフィールドＲｅｓｕｌｔＡ１はグループＡに属する全ノードの障害要因ごとの障害有無を表す。

このフェーズにおいて、図３１では、グループＡ，グループＢともに３ノードが同一データを送信しているが、これは、１つのノードに障害が発生し、フレームの送信ができない場合や、送信データに誤りが含まれる場合に、他の正常な２つのノードからの情報を使用するためである。また、図３１では、全てのノードが他グループのノード状態データを受信しているが、自ノードで実行する制御ロジックに他グループのノード状態が影響しない場合は、これを受信する必要はない。

続く通信スロット７から１０では、グループＡのノードが、グループＡに属するノードに関するノード状態結果、および必要な場合は制御データを順番に送信する。また、これらの送信フレームをモニタすることでノード状態の判定を行う。スロット７でノードＡ１が送信するフレームＡ１＿２は、図３３に示すように、グループＡのノードのみについてのノード状態判定結果ＳＡ１，障害通知同期フラグフィールドＳｙｎｃＡ１、および制御データＤＡ１から構成される。ノード状態判定結果および障害通知同期フラグフィールドの詳細な構成や生成方法については第一の実施例に記載した通りである。スロット７および１０では、それぞれノードＢ３がノードＡ１の、ノードＢ２がノードＡ４の送信フレームを受信しているが、この時ノードＢ３およびＢ２は、受信フレーム中のグループＡのノード状態判定結果は使わずに、制御データのみを抽出して使用する。

通信スロット１１から１４では、同様にグループＢのノード同士で、ノード状態結果の送受信、およびノード状態判定を行う。スロット１２および１４では、それぞれノードＡ１がノードＢ２の、ノードＡ３がノードＢ４の制御データを受信する。

グループ内でのノード状態判定結果の送受信終了後に、この情報に基づいてグループごとにそのグループに属するノードについての障害ノード特定処理を行う。本実施例では、監視対象ノード数が３になり、これらのノードの障害有無を４つのノードによるノード状態判定結果の多数決により特定すれば良くなる。従って、同一ネットワークの全てのノードによるノード状態判定結果を用いて、全てのノードの状態監視を行う第一の実施例に比べて、各ノードの演算処理量を大幅に低減することができる。なお、各ノードでの制御モードの切り替えは、自グループのノードの障害カウンタ値がリミット値に達したとき、または他グループのノードから、そのグループ内のノードに障害が発生したことを示すノード障害フラグフィールドを受信したときに、通信サイクル前半においてグループ間で前通信サイクルのグループ内ノード状態を交換し終わった時点、すなわち図３１では通信スロット６の終了時点で行う。

図３４は、他グループのノードの障害通知同期フラグフィールドＳｙｎｃを受信することにより、図３１に示した通信サイクル前半のグループ間でのグループ内ノード状態の交換をなくした実施例である。グループＢのノードは、通信スロット１から３において、ノードＡ１からノードＡ３の送信フレームからＳｙｎｃＡｘ（ｘ＝１，２，３）を抽出し、同様に、グループＡのノードはノードＢ１からノードＢ３の送信フレームからＳｙｎｃＢｘを抽出する。前述したように、障害カウンタがリミット値に達する通信サイクルで、障害通知同期フラグフィールドＳｙｎｃの該当するノードの障害要因のビットが１にセットされるため、これを用いて自グループ内ノードの状態を他グループのノードに通知することができる。ただし、当該通信サイクルにおいて障害が回復し、実際には障害カウンタがリミット値に到達しない、すなわち制御モードの切り替えは行われない可能性があるため、障害カウンタは復帰型を選択する必要がある。すなわち、この場合、例えばグループＡのノードは、グループＢのノードが送信する障害通知同期フラグフィールドＳｙｎｃＢｘのあるビットが２通信サイクル連続してセットされたときに初めてグループＢのそのビットに該当するノードの障害カウンタがリミット値に達したと判断することができる。本実施例では、図３１の実施例に比べて、通信スロットを６つ削減することができ、ノード状態通知のためのグループ間通信の通信帯域を低減することが可能となる。

以上では、ネットワーク上の全てのノードが、ネットワーク上全ての、もしくはグループ内の全ての他ノードを対象に、自ノードによる状態判定結果から障害ノードを特定する処理（ＩＤ）を行っている。

このような非常に信頼性の高い手法に加えて、ＣＰＵの処理負荷をさらに減らすために、ＩＤの実行を、ネットワーク上の他ノードと、もしくはグループ内の他ノードと分担することもできる。すなわち、ｎノードを有するグループ内（ネットワーク上の全ノードを１グループとする場合も含む）にて、１つのノードはｍ（ｎ＞ｍ＞１）ノードについてのみ自分でＩＤを実行して他ノードに送信し、それ例外のノードについては他ノードによるＩＤの結果を受信する。以下この手法を、「判定結果放送方式」と呼ぶ。なお、ｍ＝ｎとすると前記実施例と同じ方式になる。

図３５は、判定結果放送方式によるノード状態（障害ノード）監視機能を実現するフローチャートを示している。本フローチャートの処理は、各ノードで実行される。

ステップＳ１００で処理を開始し、ステップＳ１１０では自ノードによる状態判定を行う。これは第一実施例のＭＯＮと処理内容は同じである。ステップＳ１２０では、ステップＳ１１０の判定結果をグループ内の他ノードに送信(放送)する。また、他ノードによるノード状態判定結果を受信する。ステップＳ１２０の処理は前記実施例のＥＸＤと処理内容は同じである。

ステップＳ１４０では、自ノードの担当するグループ内のｍノードについてのみ、ステップＳ１２０で生成した自ノードおよび他ノードによるノード状態判定（ＭＯＮ）結果から、ノードごと・障害種類ごとに障害有無を確定させる状態判定を行う。このステップＳ１４０の処理をＩＤ１とする。これは前記実施例のＩＤと、判定対象がｍノードに限定される点が異なる。

ステップＳ１５０では、ステップＳ１４０でのｍノードについての状態判定結果を、他ノードに対して送信し、また他ノードから受信して交換する。ステップＳ１５０の処理をＥＸＤ２とする。ステップＳ１６０では、ステップＳ１５０での自他ノードによる状態判定（ＩＤ１）結果から、ノードごと・障害種類ごとに障害有無を確定させる。このステップＳ１６０の処理をＩＤ２とする。ｍ＝１の場合には特に処理を行う必要はないが、ｍ＞２のときには、複数のＩＤ１結果を多数決や優先順位付けなどにより、１つにする必要がある。

ステップＳ１７０では、ＩＤ１で担当する判定対象ノードを変更する。ステップＳ180では前記実施例と同様に、ノード障害情報を通知する。ステップＳ１９０で処理を終了する。

ステップＳ１００〜Ｓ１９０を繰り返すことで、ノード状態監視を継続的に行う。状態判定（ＭＯＮ）結果のデータ受信対象ノード数が担当のｍだけで良い（担当以外のノードについての自ノードによる状態判定結果は、最初から受信しないか、一旦受信してその後の処理を行わず破棄してよい）こと、また状態判定（ＩＤ１）の対象とするノード数がｍだけで良いことから、前記実施例と比較してＣＰＵや通信コントローラの処理負荷は軽減する。これにより、ＥＣＵの製造コストを安価にすることや、ＣＰＵの処理能力を他処理に割くことが可能となる。

ＩＤ１の判定対象とするｍノードは、グループ内の全てのノードが判定対象となるように各ノードに担当を割り振る。またステップＳ１７０では、ＩＤ１の対象ノードを毎回もしくは定期的に変更することにより、あるノードに障害が発生し、ステップＳ１００〜
Ｓ１９０の一部または全部を行えない状態になっても、特定ノードについてのＩＤ１が延々と行われずその結果の送信（ＥＸＤ２）も行われないという事態が継続するのを防ぐようにしている。ステップＳ１７０は必須ではないが、ノード状態監視機能の信頼性を保つ上で重要である。なお、前記実施例における障害ノード特定アルゴリズムは、ＩＤ１＋
ＥＸＤ２＋ＩＤ２に対応している。

図３６および図３７は、判定結果放送方式における状態判定結果格納手段および障害ノード特定手段を示している。説明を簡素化するため、ノード１を例に説明する。ここではｍ＝１としている。またこの例では、ノード１によるＩＤ１の対象はノード２となっている。

図３６では、状態判定結果（ＭＯＮ）の格納される領域が、ノード２を対象とした状態判定結果分のバッファである担当ノードの状態判定結果格納部１４２０のみであり、図４よりも限定されている。ノード２以外を対象とした状態判定結果は受信されないか、受信しても破棄される。

図３７では、担当ノード状態判定部１３１ａが、担当ノードの状態判定結果格納部1420のデータをもとに、ノード２についての状態判定（ＩＤ１）を行う。ＩＤ１の結果は、状態判定結果調整部１３１ｂに送られ、また他ノードに送信される（ＥＸＤ２）。

状態判定結果調整部１３１ｂは、自ノードの状態判定（ＩＤ１）結果、および他ノード（ノード２〜ノードｎ）から受信（ＥＸＤ２）した状態判定（ＩＤ１）結果から、障害ノード特定（ＩＤ２）を行う。ここで、他ノードが状態判定（ＩＤ１）を担当するノードは、ノード１およびノード３〜ノードｎである。状態判定結果調整部１３１ｂは、状態判定ノード数ｍが２以上のときには、状態判定（ＩＤ１）結果を多数決などにより１つに纏める。この例のようにｍ＝１のときには、ＩＤ１の結果をそのままＩＤ２の結果とする。また自ノード（ノード１）の状態については、他ノードによる状態判定（ＩＤ１）結果より自ノード状態判定結果を優先させるなどをして、判定結果を１つに纏める。

状態判定結果調整部１３１ｂは、ＩＤ２結果で障害ありと確定されたノード・障害種類について、障害カウンタ１３２の値をインクリメントする。

本実施例（図３６）では、第一の実施例（図４）と比較して必要なバッファ容量が低減することで、ＥＣＵの製造コストを安価にすることが可能となる。

図３８は、判定結果放送方式における通信スケジュールの一例を示している。各ノードはある通信サイクルｉにて、各ノードはノード状態判定（ＭＯＮ）を行う。次の通信サイクルｉ＋１にて、他ノードと自ノードによる状態判定結果の送受信（ＥＸＤ）を行う。また、担当するｍノードについての状態判定（ＩＤ１）を行う。次の通信サイクルｉ＋２にて、担当するノードの状態判定結果を他ノードと送受信する（ＥＸＤ２）。また、障害ノード特定（ＩＤ２）を行う。以下、この処理を繰り返す。

このように、判定結果放送方式では障害ノード特定を１回行うのに３つの通信サイクルが必要となり、前記実施例の２サイクルより１サイクル増える。しかしながらＣＰＵの処理負荷は減るので、前記実施例よりも１サイクルの時間長を短くすることや、１サイクルに処理するステップ数を図３８より増やす（例えばｉ＋１サイクル目で、ＥＸＤ・ＩＤ１・ＥＸＤ２・ＩＤ２を一通り行う）ことも可能であり、前記実施例より必ずしも障害ノード特定までに時間が掛かるわけではない。

ステップＳ１００〜Ｓ１９０を繰り返す際、各処理を並列に行ってもよい。図３９では、通信サイクルｉでＭＯＮを行い、次の通信サイクルｉ＋１では、通信サイクルｉのMONについてＥＸＤ・ＩＤ１を行う一方、新たにＭＯＮを同じサイクル内で処理している。通信サイクルｉ＋２では、通信サイクルｉ＋１のＩＤ１についてＥＸＤ２・ＩＤ２を行う一方、通信サイクルｉ＋１のＭＯＮについてＥＸＤ・ＩＤ１を処理し、さらに新たなＭＯＮを処理している。以下この処理を繰り返すことで、毎通信サイクルにて障害ノード特定を行うことが可能となる。

図４０は、各ノードのＩＤ１における、担当ノードの変更スケジュールの一例を示している。つまりこのスケジュールは、各通信サイクルにて、各ノードがＩＤ１でどのノードを対象に状態判定を行い、次サイクルでその状態判定結果を他ノードに送信するかを表しており、ステップＳ１７０の処理内容にあたるものである。

スケジュール２０００はｍ＝１とした例である。ノード１の状態判定担当ノードは、通信サイクルｉにてノード２，通信サイクルｉ＋１にてノード３と変わり、通信サイクルｉ＋ｎ−１にてノードｎ、通信サイクルｉ＋ｎにてノード２と一周し、以下繰り返す。ノード２〜ｎの状態判定担当ノードは、ある通信サイクルにて全てのノードが状態判定の対象となるように振り分けられており、ノード２の対象は、通信サイクルｉにてノード３，通信サイクルｉ＋１にてノード４、通信サイクルｉ＋ｎ−１にてノード１と変わり、ノードｎの対象は、通信サイクルｉにてノード１，通信サイクルｉ＋１にてノード２、通信サイクルｉ＋ｎ−１にてノードｎ−１と変わる。これにより、１つのノードがＩＤ１で対象とするノード数が１つだけであっても、毎通信サイクルに全てのノードについて障害ノード特定を行うことが可能となる。

スケジュール２０１０はｍ＝２とした例である。ｍ＝２として全てのノードが必ず２つのノードにより状態判定（ＩＤ１）の対象となるスケジュールを組めば、グループ内の１ノードが故障によりステップＳ１００〜Ｓ１９０の一部もしくは全部を行えない状態になっても、状態判定の対象とされないノードが出ることがない。スケジュール２０１０はこのように組まれたスケジュールであり、ノード１のＩＤ１対象ノードは、通信サイクルｉにてノード２・ノード３、通信サイクルｉ＋１にてノード３・ノード４と変わり、通信サイクルｉ＋ｎ−１にてノードｎ・ノード２、通信サイクルｉ＋ｎにてノード２・ノード３と一周し、以下繰り返す。ノード２の対象は、通信サイクルｉにてノード３・ノード４、通信サイクルｉ＋１にてノード４・ノード５、通信サイクルｉ＋ｎ−１にてノード１・ノード３と変わり、ノードｎの対象は、通信サイクルｉにてノード１・ノード２、通信サイクルｉ＋１にてノード２・ノード３、通信サイクルｉ＋ｎ−１にてノードｎ−１・ノード１と変わる。

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

図４１は、判定結果放送方式を用いたノード状態監視状況の一例を示してあり、図１５，図１６と同様のものである。図４１では、通信サイクルｉ＋１のスロット１の時間帯において、ノード３にＣＰＵの障害が発生し、ソフトウェアの動作に異常が生じたことを想定している。ノード３は通信サイクルｉにおける状態判定（ＭＯＮ）結果をスロット３で送信することになっているが、ノード障害検出符号付加手段３８は、ＣＰＵ障害のため、通番をインクリメントすることができない。したがって、他ノードはノード３からの状態判定結果受信（ＥＸＤ。ここでは通信データに通信サイクルｉのＩＤ１結果も含まれるため、ＥＸＤ２を兼ねる）時に、通番がインクリメントされていないことを検出し、ノード３に通番異常が発生したと判定する（通信サイクルｉ＋１におけるＭＯＮ）。しかしこの時点では、ノード３からのデータに障害を検出しても、自ノード単独の判定であるため、障害がノード３によるものか、自ノードの判定誤りによるものかを決定することはできない。そこで次の通信サイクルｉ＋２にて、ノード１・２・４は、自ノードによる状態判定（ＭＯＮ）の結果００８０（ノード３の通番異常を表す）を、通信サイクルｉ＋２における状態判定（ＩＤ１）結果と共に送信する（ＥＸＤ）。各ノードは、通信サイクルｉ＋２の後半で、ノード２は、ノード１・２・４による状態判定結果を用いて、ノード３を対象に状態判定（ＩＤ１）を行い、障害種類ごとの有無を判定し、ノード３の通番異常を確定する。さらに通信サイクルｉ＋３にて、ノード２はノード３の状態判定（ＩＤ１）結果を、通信サイクルｉ＋２における状態判定（ＭＯＮ）結果と共に送信する（ＥＸＤ２）。これにより、ノード１・２・４はノード３の通番異常確定を知り、障害カウンタＥｘ＿３
（ｘ＝１，２，４）をカウントアップし、当該障害カウンタの値がリミット値に達するため、ノード障害フラグの該当箇所がセットされる。このようにして、各ノードは障害発生箇所と障害種類を正確に知ることができる。

図４２は、各ノードのＩＤ１における対象ノード変更方法を工夫した例について、フローを示している。この例では、障害が発生しているノードが本来行う状態判定（ＩＤ１）を、その障害を検知した他のノードが代行することで、ノード状態監視機能に支障が出ないようにしている。

ネットワーク上の各ノードは、状態判定（ＩＤ１）担当ノードのスケジュールと同様に、状態判定（ＩＤ１）代行の対象とするノードのスケジュールを持ち、そのスケジュールで代行対象とされているノードに障害発生を検知すると、この障害ノードが状態判定を担当しているノードについて、代りに状態判定（ＩＤ１）を行うものとする。

以下、図４２のフローを説明する。ステップＳ２００で処理を開始し、ステップＳ210では状態判定を担当するｍノードのローテーションを行う。このローテーションは、スケジュール２０００やスケジュール２０１０のような担当ノード変更を意味する。

ステップＳ２２０〜Ｓ２５０は、状態判定代行対象ノードそれぞれについて行う。１つの代行対象ノードをノードａとする。

ステップＳ２３０ではノードａに障害が発生しているかを確認する。障害検知は、自ノードによる状態判定(ＭＯＮ)の結果に基づくものである。障害があればステップＳ２４０へ、なければステップＳ２５０へ進む。

ステップＳ２４０では、状態判定代行対象ノードの１つを、ノードａが状態判定(ID1)を担当している１ノードに置き換える。もしくは、担当ノードとしてノードａの担当ノードの１つを追加する。ステップＳ２５０では、全ての状態判定代行ノードについて処理を終えていればステップＳ２９０へ進んで処理を終了し、そうでなければステップＳ２２０へ戻る。

上記では、状態判定を代行する機会を、ＭＯＮにて障害を検知したときとしたが、自ノードによるＩＤ２もしくは他ノードによるＩＤ１のＥＸＤ２での受信により、障害を検知してから再び正常と判断されるまで、としてもよい。

図４３は、実際のネットワーク上のノードへの、図４２のフローの適用例である。タイムチャート２０２０は、ネットワーク上の各ノードが各通信サイクルにて状態判定(ID1)を担当するノードを、スケジュール２０３０は、各ノードが各通信サイクルにて状態判定（ＩＤ１）代行の対象とするノードを表している。

タイムチャート２０２０では、ある通信サイクルｉにて、ノード１はノード２について、ノード２はノード３について、ノード３はノード４について、ノード４はノード１について状態判定（ＩＤ１）を行う。次の通信サイクルｉ＋１では、状態判定担当ノードはローテーションし、ノード１はノード３について、ノード２はノード４について、ノード３はノード１について、ノード４はノード２について状態判定（ＩＤ１）を行う。しかし、この通信サイクルｉ＋１の始めに行われるＭＯＮにて、ノード２・３・４はノード１の障害（ＣＲＣ異常など）を検知する。すると、スケジュール２０３０でノード１を状態判定代行の対象としているノード４が、本来ノード１が状態判定を担当しているノード３についても、状態判定（ＩＤ１）を行う。通信サイクルｉ＋２でも同様に、ノード２・３・４はノード１の障害を検知し、スケジュール２０３０でノード１を状態判定代行の対象としているノード３が、本来ノード１が状態判定を担当しているノード４についても、状態判定（ＩＤ１）を行う。

ここで各ノードは、状態判定代行対象ノードの、状態判定（ＩＤ１）担当スケジュールを持つことが必要である。スケジュール２０３０は、メモリなどの記憶装置にテーブルとして保持しておいてもよいし、数式で計算することも可能である。

このようにして、ＩＤ１の対象とならないノードが出現するのを防ぎながら、ノード状態の相互監視を行うことができる。

以下では、本発明のノード状態監視を持つソフトウェアを設計するツールに関して説明する。ＥＣＵ上で動作し、上記の処理を行うソフトウェアを製作する場合に、一般的には設計ツールが用いられる。この設計ツールは、汎用コンピュータなどで動作するソフトウェアであり、ユーザは設計ツールを用いて、ネットワーク構成や通信スケジュール、タスクスケジュールなどの設定を行う。多くの場合にＧＵＩ（Graphical User Interface）を持ち、ユーザがキーボードやマウスなどの入力装置をもって、画面上で視覚的に設計を行うことができる。

設計ツールは、ユーザの設定を反映して、ヘッダファイル等を含むソースファイルを出力する。これらのファイルに、他のソースファイル・オブジェクトファイル・ライブラリなどを合わせ、コンパイラ・リンカを通すことで、ＥＣＵ上で動作する実行プログラムが生成される。なお、本発明のノード状態監視機能の実装形態としては、１つにミドルウェアが考えられる。

ユーザがこのような設計ツール用いて、本発明のノード状態監視機能に関する設定を行うことができ、ＥＣＵ上で該機能を発するソフトウェアを生成することができれば、ユーザの設計に掛かる労力を軽減しつつ、本発明を実用することができる。以下では、このような設計ツールを実現するための、設計ツールのＧＵＩおよび機能について説明する。

図４４は、設計ツールの画面例を示したものである。画面はネットワーク構成設定部
２１００，ネットワーク構成要素選択領域２１５０，ネットワーク主設定部２２００からなる。ネットワーク構成設定部２１００上では、通信線Ｎ１０ＡとＮ１０Ｂが配置され、それら通信線にノード１からノード５がバス型トポロジで接続するように配置されている。すなわち、このネットワークでは通信路がチャネルＡとチャネルＢとに２重化されている。各ノードはチャネルＡ・Ｂごとにノード状態監視を行うため、各ノードは画面上でＡ部（ノード１のＮ１０１Ａからノード５のＮ１０５Ａ）・Ｂ部（ノード１のＮ１０１Ｂからノード５のＮ１０５Ｂ）に分けられている。このネットワーク構成の設定・編集は、ネットワーク構成要素選択領域２１５０からノードや通信線などの要素を選択して配置（ドラッグ・アンド・ドロップ）することにより、ユーザが行うものである。このような設定・編集方法は設計ツールでは一般的に採用されており、ここでは詳細に説明しない。

ネットワーク主設定部２２００には、ノード状態監視方式を指定するボタン２２１０，ノード状態監視方式表示２２２０，ノード状態監視を行うノードのグループ設定を行うボタン２２３０，ソースファイル等を生成し出力させるボタン２２４０がある。ボタン2210をユーザがマウス入力等で押下すると、画面上にノード状態監視方式のリスト２２５０が表示され、ユーザが選択した１方式がノード状態監視方式表示２２００となる。監視方式の選択項目としては、「監視なし」・「全ノード相互監視」・「グループ内相互監視」・「判定結果放送」・「詳細指定」を用意する。

「監視なし」が選択されると、ノード状態監視機能を利用しないものとされ、本設計ツールではノード状態監視に関する設定が無効（入力不可）となり、出力されるソースファイル等にもノード状態監視に関する内容は含まれなくなる。

逆に、「全ノード相互監視」〜が「詳細指定」が選択されると、ノード状態監視機能が有効となり、本設計ツールでノード状態監視に関する設定入力が可能となり、出力されるソースファイル等にもノード状態監視に関する内容が含まれるようになる。

「全ノード相互監視」は、ネットワーク構成設定部２１００のネットワーク上の各ノードは、他の全ノードについて相互監視する、すなわち自ノードによる状態判定（ＭＯＮ）、自ノードによる状態判定結果の交換（ＥＸＤ）及びノード状態判定（ＩＤ）を行う方式を意味し、出力されるソースファイル等は該方式を反映した内容となる。「グループ内相互監視」は、ネットワーク上のノードをいくつかのグループに分けて、グループ内すべての他ノードについて相互監視を行う方式を意味する。「判定結果放送方式」は、グループ内すべての他ノードについて自ノードによる状態判定（ＭＯＮ）を行うが、ノード状態判定（ＩＤ１）はｍノードに限定し、判定（ＩＤ１）結果を互いに送信して共有する方式を意味している。

「詳細設定」は、ノード状態監視方式をより詳細に指定するモードである。このモードでは、自ノードによる状態判定（ＭＯＮ）を互いに行い結果を共有（ＥＸＤ）する「ノード状態監視グループ」や、状態判定（ＩＤ１）の担当ノード、状態判定（ＩＤ１）結果を他ノードへ送信（もしくはブロードキャスト）するか否か、グループ内外の他ノードについてその状態判定（ＩＤ１）結果を受信して障害ノード特定（ＩＤ２）を行うか否か、といった項目を、ノードごとに細かく指定することができる。

「詳細設定」モードのとき、ソフトウェアの設定によっては、「全ノード相互監視」・「グループ内相互監視」・「判定結果放送」などとノード状態監視機能が同等になる場合がある。例えば、ノード状態監視グループをネットワーク上の全ノード、ノード状態判定（ＩＤ１）結果の送信なし（自動的に、ノード状態判定担当ノードと障害ノード特定
（ＩＤ２）有無の設定は無意味になるため、無効となる）とすれば、「全ノード相互監視」と同じになる。ノード状態監視グループをネットワーク上のｎノードに限定して、ノード状態判定（ＩＤ１）結果の送信なしとすれば、「グループ内相互監視」と同じになる。すなわち、「詳細設定」モードは、「監視なし」以外の他モードを全て包含している。

ネットワーク主設定部２２００のボタン２２３０をユーザが押下すると、ノード状態監視のグループ設定や監視条件設定を行う画面が表示される。図４５はノード状態監視グループをノード主体で設定する画面例、図４６はノード状態監視グループをグループ主体で設定する画面、図４７はあるノード状態監視グループ(例としてチャンネルＡグループ１)の詳細な条件を設定する画面例である。３つの画面はタブにより切り替え可能となっている。

図４５にて、ノード状態監視グループ設定画面(ノード主体)２３００は、チャネルＡ設定部２３１０，チャネルＢ設定部２３５０，ボタン２３８０，ボタン２３９０からなる。ユーザがボタン２３８０を押下すると本画面で入力した内容が設定に反映され、ボタン
２３９０を押すと入力内容は破棄される。

チャネルＡ設定部２３１０には、ノード１からノード５の各々について所属するノード状態監視グループを指定する所属ノード状態監視グループ指定部２３２ｘ（ｘ＝１〜５、図では２３２１を例示）がある。またユーザがボタン２３３０を押下すると、ノード状態監視グループ数の入力欄が表示され、ノード状態監視グループ数を変更することができる。図ではチャネルＡのノード状態監視グループ数は２とされており、所属ノード状態監視グループ指定部で選択できるグループ名は「グループ１」「グループ２」となっている。もしノード状態監視グループ数を少なくすることで、所属ノード状態監視グループ指定部で指定しているグループがなくなってしまった場合には、そのノードの所属ノード状態監視グループは設定なしとなる。

チャネルＢ設定部２３５０も、チャネルＡ設定部２３１０とほぼ同じである。ただし、ラジオボタン２３６０をユーザが設定有りにすると、チャネルＢに関する入力すなわち所属ノード状態監視グループ指定部２３２ｘの内容は無効（入力不可）となり、チャネルＡと同じ設定になる。

図４６にて、ノード状態監視グループ設定画面（グループ主体）２４００は、チャネルＡ設定部２４１０，チャネルＢ設定部２４６０，ボタン２４８０，ボタン２４９０からなる。ボタン２４８０はボタン２３８０と、ボタン２４９０はボタン２３９０と同等である。

チャネルＡ設定部２４１０には、ノード状態監視グループｘに所属するノードを指定するノード状態監視グループ所属ノード指定部２４２ｘ（図では２４２１を例示）があり、ここにユーザがノード名を入力すれば、入力されたノードは該ノード状態監視グループに所属する。もしくはユーザが、ネットワーク構成設定部２１００からノードＮ１０１Ａ〜Ｎ１０５Ｂをノード状態監視グループ所属ノード指定部２４２ｘにドラッグ・アンド・ドロップするか、所属ノード指定部２４２ｘをクリックして編集対象となるグループを決めて（このときグループ名が反転する）から、ネットワーク構成設定部２１００上のノードＮ１０１Ａ〜Ｎ１０５Ｂをクリックすることでも、ノード名を入力するのと同じ結果になるとする。あるノードをノード状態監視グループの所属から外したい場合には、ユーザがそのノード名を削除すればよい。

「全ノード相互監視」モードでは、設計ツールはノード状態監視グループ設定画面（ノード主体）２３００およびノード状態監視グループ設定画面（グループ主体）２４００を無効（入力不可）としてもよい。

図４７にて、ノード状態監視グループ条件設定画面２５００は、チャネルＡ設定部2510，ボタン２５８０，ボタン２５９０からなる。ボタン２５８０はボタン２３８０と、ボタン２５９０はボタン２３９０と同等である。本画面はチャネルＡについてのみ表示しているが、チャネルＢについても同様に表示される。

チャネルＡ設定部２５１０には、ノード１からノード５の各々について、グループ内でノード状態判定（ＩＤ１）の対象とするノードを指定する状態判定対象指定部２５２ｘ
（ｘ＝１〜５、図では２５２１を例示）がある。状態判定既対象表示２５３ｘ（ｘ＝１〜５、図では２５３４を例示）のあるノードは、他のノード状態監視グループで状態判定
（ＩＤ１）の対象となっているノードである。状態判定（ＩＤ１）が行われないノードがあれば、設計ツールがそのことをチェックし、ノード番号と共に注意を促す表示を行っても良い。また、ラジオボタン２５４０をユーザが設定有りにすると、チャネルＡに関する入力すなわち状態判定対象指定部２５２ｘの内容は無効（入力不可）となり、同じノード状態監視グループのノードが対象になる。「全ノード相互監視」・「グループ内相互監視」・「判定結果放送」の各モードでは、この設定となる。これら各モードでは、設計ツールはノード状態監視グループ条件設定画面２５００を無効（入力不可）としてもよい。

状態監視対象とするノードの指定方法によっては例えば、ノード１について、ノード２〜ノード５で自ノードによる状態判定（ＭＯＮ）および判定結果の共有（ＥＸＤ）、状態判定（ＩＤ１）および判定結果の共有（ＥＸＤ２）を行う、といった構成も可能である。

状態判定結果送信指定部２５５０では、状態判定（ＩＤ１）結果を他ノードに送信するか否かを指定するもので、有効すなわち「送信あり」とすると、状態判定担当ノード数指定部２５６０、状態判定担当スケジューリング方式指定部２５７０が有効になり、入力できるようになる。

状態判定担当ノード数指定部２５６０では、１ノードが１回の状態判定（ＩＤ１）で対象とするノード数、すなわち前記のｍを指定する。ｍがグループ内で一定の場合には、
ネットワーク全ノード数＞ｍ＞（状態判定（ＩＤ１）対象ノード数÷ノード状態監視 グループに所属するノード数）以上の整数
という制約があり、この制約から外れる入力は受け付けない。

状態判定担当スケジューリング方式指定部２５７０では、ノード状態判定（ＩＤ１）担当ノードのスケジューリング方法を指定することができる。図４２例では、スケジュール２０００やスケジュール２０１０のように担当ノードを変更する「ローテーション」方式を指定している。このほかに、タイムチャート２０２０とスケジュール２０３０で説明した、障害ノードが本来担当している状態判定を代行する方式を指定することもできる。

「詳細設定」モードでは、各ノードでより詳細な設定を行う必要がある。図４７は、そのような詳細設定を行う画面である。この画面は、例えばネットワーク構成設定部2100のノード表示Ｎ１０１Ａ〜Ｎ１０５Ｂをユーザがマウスでクリックすることで表示され、入力できるものとする。

ノード状態監視詳細設定画面２６００は、簡単のためにノード１の設定画面としてあり、チャネルＡ設定部２６１０，チャネルＢ設定部２６５０，ボタン２６８０，ボタン2690からなる。ボタン２６８０はボタン２３８０と、ボタン２６９０はボタン２３９０と同等である。

チャネルＡ設定部２６１０にて、ノード状態監視グループ指定部２６２０はノード状態監視グループ設定画面２３００の所属ノード状態監視グループ指定部２３２ｘと同等である。

障害特定ノード指定部２６３ｘ（ｘ＝１〜５、図では２６３４を例示）をユーザが設定有りにしたノードについては、そのノードに対するＩＤ１結果を受信して障害特定(ID2)を行うよう、設計ツールはソフトウェアを設定する。ただし、図４２例では、ユーザが状態判定（ＩＤ１）の対象としたノードについては、無条件で障害特定（ＩＤ２）を行うとしている。チャネルＢ設定部２６５０も、チャネルＡ設定部２６１０と内容は同じである。

設計ツールはあるノードのＥＣＵソフトウェアに対し、ユーザが状態判定（ＩＤ１）を行うとしたノードについて、自ノードによる状態判定（ＭＯＮ）を行い、結果を送信
（ＥＸＤ）するようにソフトウェアの通信関係のパラメタを設定する。ユーザが障害特定（ＩＤ２）を行うと設定したノードについては、障害カウンタ・障害フラグをもって管理するか否かをユーザが選択できるようにしてもよい。他ノードによる状態判定（ＭＯＮ）結果を受信するスロットは、同じノード状態監視グループに所属する他ノードが状態判定（ＭＯＮ）結果を送信するスロットである。障害特定（ＩＤ２）を行うための状態判定
（ＩＤ１）結果を受信するスロットは、障害特定ノード指定部２５３ｘで指定したノードについてＩＤ１を実行するノードがＩＤ１結果を送信（ＥＸＤ２）するスロットであり、設計ツールはそれらスロットにおいてノードが状態判定結果のデータを受信するように
ＥＣＵソフトウェアを設定する。なお、データ送信のスケジューリング（どのノードがどのスロットで送信するか）は、設計ツールに付属する機能やユーザの手入力でなされる。

上記の例では、各ノードが所属できるノード状態監視グループは１つだけとしたが、複数グループに所属できるようにしてもよい。その場合には、所属ノード状態監視グループを指定する入力部２３２ｘを１ノードあたり複数用意する。また、所属ノード状態監視グループにしたがってノード表示Ｎ１０１Ａ〜Ｎ１０５Ｂを色分け表示し、ユーザの認識性を高めても良い。また、チャンネルＡとチャンネルＢは独立でノード状態監視を行うようにしているが、どちらかのチャンネルで障害ありと判定されたノードは、障害を検知したチャンネルに関わらず障害ありとして諸プログラムに通知するよう、ソフトウェアの設定を行うユーザ選択肢を用意しても良い。

ＥＣＵソフトウェア設計ツールが、上記のようなＧＵＩならびにソフトウェア生成機能を有することで、ユーザの設計労力を軽減し、設計に掛かる時間を短縮しつつ、本発明のノード状態監視機能を有するソフトウェアを製作することが可能となる。

最後に本発明の好適な実施形態を列挙する。
〔１〕通信ネットワークに接続された複数のノードが、当該通信ネットワークを介してデータの伝送を行うことにより車両の機能を実現する車両制御システムにおいて、前記複数のノードは、自らの動作状態及び前記通信ネットワークに接続された他のノードの動作状態を含むノード状態を判定するノード状態判定手段、前記ノード状態判定手段により自らが判定した前記ノード状態判定結果を他ノードに送信し、他のノードが判定したノード状態判定結果を受信する状態判定結果送受信手段、および前記自らが判定したノード状態判定結果および受信した前記他のノードによるノード状態判定結果とを用いて、前記通信ネットワーク内の障害ノードを特定する障害ノード特定手段と、を備えることを特徴とする車両制御システム。
〔２〕上記〔１〕記載の車両制御システムにおいて、前記ノード状態判定手段は、自らの動作状態及び、自らが制御するセンサ若しくはアクチュエータの動作状態の診断を行う自ノード状態判定手段と、前記通信ネットワークに接続された他のノードの状態を判定する他ノード状態判定手段とを備え、前記状態半径結果送受信手段は、前記自ノード状態判定手段による判定結果と前記他ノード状態判定手段による判定結果とをまとめて送信することを特徴とする車両制御システム。
〔３〕上記〔２〕に記載の車両制御システムにおいて、前記状態判定結果送受信手段は、送信データにノード障害を検出するための符号を付加するノード障害検出符号付加手段を備えており、前記他ノード状態判定手段は、他のノードが送信したデータを受信する際に、当該送信ノードが送信データに付加したノード障害検出符号を用いて、当該送信ノードでの障害発生有無を判定することを特徴とする車両制御システム。
〔４〕上記〔３〕に記載の車両制御システムにおいて、前記ノード障害検出符号付加手段は、データを送信するたびにインクリメントされる通し番号を前記送信データに付加する通番付加部を備え、前記他ノード状態判定手段は、他のノードから受信したデータに付加された通し番号が、前回に当該他のノードから受信したデータに付加された通し番号からインクリメントされていない場合は、当該他のノードに障害が発生したと判定することを特徴とする車両制御システム。
〔５〕上記〔３〕に記載の車両制御システムにおいて、前記ノード障害検出符号付加手段は、送信データを加算して求めたサム値を当該送信データに付加するサム値付加部を備え、前記他ノード状態判定手段は、他のノードから受信したデータを加算してサム値を求め、当該サム値が当該データに付加されたサム値と一致しない場合は、当該送信ノードに障害が発生したと判定することを特徴とする車両制御システム。
〔６〕上記２に記載の車両制御システムにおいて、前記他ノード状態判定手段は、他のノードから今回受信したデータと前回受信したデータとの差分を計算し、当該差分が所定の閾値以上である場合は、当該他のノードに障害が発生したと判定することを特徴とする車両制御システム。
〔７〕上記〔３〕または〔６〕に記載の車両制御システムにおいて、前記複数のノードは、前記通信ネットワーク上での通信の異常を検知するネットワーク障害判定手段を備え、前記他ノード状態判定手段は、前記ネットワーク障害判定手段による判定結果を含めて、他ノードの状態判定を行うことを特徴とする車両制御システム。
〔８〕上記〔１〕に記載の車両制御システムにおいて、前記複数のノードは車両制御ロジックを実行する車両制御ロジック実行部を備え、前記障害ノード特定手段は、前記自らによるノード状態判定結果と受信した前記他ノードによるノード状態判定結果とを用いて障害ノードを特定する障害ノード特定アルゴリズム実行部、特定したノードに発生した障害の回数と種類に基づいて、数値をカウントアップする障害カウンタ、および前記障害カウンタの数値が所定のリミット値に到達した場合に、前記車両制御ロジック実行部が当該ノードに障害が発生したことを認識するためのノード障害フラグをセットするノード障害フラグ格納部とを備えることを特徴とする車両制御システム。
〔９〕上記〔８〕に記載の車両制御システムにおいて、前記ノード障害フラグ格納部は、前記車両制御ロジック実行手段により読み出すことが可能であるように構成されており、前記車両制御ロジック実行手段は、前記ノード障害フラグ格納部の情報に基づき、障害ノードおよび障害要因に基づいて車両制御の内容を変更することを特徴とする車両制御システム。
〔１０〕上記〔８〕に記載の車両制御システムにおいて、前記車両制御ロジック実行手段は、障害ノードが正常状態に復帰した時に、前記障害カウンタの値を正常復帰前の値からデクリメントするか、または正常復帰前の値を保持するかを選択できることを特徴とする車両制御システム。
〔１１〕上記〔９〕に記載の車両制御システムにおいて、前記障害ノード特定アルゴリズム実行部は、同一のノード状態判定結果を得たノード数が、前記車両制御ロジック実行手段が設定する判定閾値以上の場合に、当該ノード状態判定結果を真であるとして、障害ノードを特定することを特徴とする車両制御システム。
〔１２〕上記〔１〕に記載の車両制御システムにおいて、予め設定された一連の送受信パターンから成る通信サイクルを繰り返すことにより、各ノードが周期的にデータを送信するようにネットワークを構成し、各ノードにおいて、ある通信サイクル期間に、前記ネットワーク内ノード状態判定手段によるノード状態判定処理を行い、当該通信サイクルの次の通信サイクル期間において、前記ノード状態判定結果送受信手段を用いて前通信サイクルのノード状態判定処理により得られた判定結果をノード間で相互に交換した後、前記障害ノード特定手段により障害ノードの特定を行うことを特徴とする車両制御システム。
〔１３〕上記〔１〕から〔１２〕のいずれか一項に記載の車両制御システムにおいて、前記車両制御ロジック実行手段を制御アプリケーションソフトウェアとして実装し、前記ノード障害検出符号付加手段、他ノード状態判定手段、および障害ノード特定手段を、前記制御アプリケーションソフトウェアにノード状態情報を提供するアプリケーションプログラムインタフェース（ＡＰＩ）を備えるミドルウェアとして実装することを特徴とする車両制御システム。
〔１４〕上記〔１３〕に記載の車両制御システムにおいて、前記制御アプリケーションソフトウェアは、前記ＡＰＩを介して取得したノード状態情報に基づき、障害ノードおよび障害要因に応じた車両制御を実行することを特徴とする車両制御システム。
〔１５〕上記〔１〕から〔１４〕のいずれか一項に記載の車両制御システムにおいて、前記複数のノードは、センサ、アクチュエータ若しくは電子制御装置であることを特徴とする車両制御システム。

車両制御システムの一実施例の概要を示す説明図。 車両制御システムの基本構成の一実施例を示す説明図。 車両制御システムの基本構成の一実施例を示すブロック図。 状態判定結果格納手段の構成図。 他ノード状態判定の実施例に関するブロック図。 他ノード状態判定の実施例に関するブロック図。 障害ノード特定の実施例に関するフローチャート。 各ノードの送受信タイミングおよび障害ノード特定に関わる一連の処理の実行タイミングを示すタイムチャート。 障害ノード特定に関わる一連の処理の実行タイミングを示すタイムチャート。 障害ノード特定手段の基本構成を示すブロック図。 障害カウンタ動作の実施例の説明図。 二種類の障害カウンタの実施例に関する動作説明図。 障害ノード特定アルゴリズム実行部における処理フローチャート。 障害発生判定処理の実施例に関するフローチャート。 本発明の実施例における車両制御システムの動作説明図。 本発明の実施例における車両制御システムの動作説明図。 障害発生判定処理の他の実施例の説明図。 障害発生判定処理の他の実施例の説明図。 障害発生判定処理の他の実施例の説明図。 障害発生判定処理の他の実施例の説明図。 各ノードのソフトウェアおよびハードウェア構成図。 ネットワーク構成の一実施例を示す図。 車両制御システムの実施例に関するシステム構成図。 ブレーキ制御システムの実施例に関するシステム構成図。 車両制御システムの基本構成の一実施例を示すブロック図。 他ノード状態判定の実施例に関するブロック図。 他ノード状態判定の実施例に関するブロック図。 制御データとノード状態判定結果の送受信タイミングを説明するタイムチャート。 右前輪ブレーキモータ制御ＥＣＵの制御アプリケーションにおける処理フローチャート。 同一ネットワークに接続されるノードを４ノードずつグルーピングした実施例。 二つの相互監視グループを設けた場合の１通信サイクルにおける各ノード間のデータ送受信の実施形態。 前通信サイクルのグループ内ノード状態送信フェーズにおけるノードＡ１の送信フレームＡ１＿１の構成例。 通信スロット７におけるノードＡ１の送信フレームＡ１＿２の構成例。 他グループのノードの障害通知同期フラグフィールドを受信する場合の１通信サイクルにおける各ノード間のデータ送受信の実施形態。 判定結果放送方式によるノード状態監視処理フローチャート。 判定結果放送方式によるノード状態監視を行う機能の構成例。 判定結果放送方式によるノード状態監視を行う機能の構成例。 判定結果放送方式によるノード状態監視（単一処理）のタイムチャート。 判定結果放送方式によるノード状態監視（並列処理）のタイムチャート。 状態判定担当ノードの変更スケジュール例。 判定結果放送方式によるノード状態監視の適用例。 状態判定代行処理のフローチャート。 状態判定代行処理の適用例。 ＥＣＵソフトウェア設計ツールのＧＵＩ例。 ＥＣＵソフトウェア設計ツールのノード状態監視グループ設定画面の例。 ＥＣＵソフトウェア設計ツールのノード状態監視グループ設定画面の例。 ＥＣＵソフトウェア設計ツールのノード状態監視グループ条件設定画面の例。 ＥＣＵソフトウェア設計ツールのノード状態監視詳細設定画面の例。

符号の説明

ｘ１（ｘはノード番号）…ノード状態判定手段、ｘ２…状態判定結果送受信手段、ｘ３…障害ノード特定手段、ｘ１０１…他ノード状態判定手段、ｘ１０２…自ノード状態判定手段、ｘ１０１２，ｘ１０１５…サム値異常判定部、ｘ１０１３，ｘ１０１６…通番異常判定部、ｘ１０１４…データ差分異常判定部、ｘ２０１…状態判定結果格納手段、ｘ202…受信処理手段、ｘ２０３…送信処理手段、ｘ３…障害ノード特定手段、ｘ４…受信データ格納手段、ｘ５…送信データ格納手段、ｘ６…ネットワークアクセス手段、ｘ７…制御ロジック実行手段、ｘ８…ノード障害検出符号付加手段、ｘ８１，ｘ８３…通番付加部、ｘ８２，ｘ８４…サム値付加部、ｘ９０１…ネットワーク障害検出符号付加手段、ｘ9011…ＣＲＣ符号付加部、ｘ９０２…ネットワーク障害判定手段、ｘ９０２１…ＣＲＣ異常判定部、ｘ９０２２…フレーム未受信判定部、１００…通信ネットワーク、１３１…障害ノード特定アルゴリズム実行部、１３２…障害カウンタ、１３３…障害カウンタリミット値到達判定部、１３４…障害カウンタリミット値設定部、１３５…ノード障害フラグ格納部、１３１ａ…担当ノード状態判定部、１３１ｂ…状態判定結果調整部、１１００…ＣＰＵ、１２００…通信コントローラ、１３００…通信トランシーバ、１４００…制御アプリケーション、１５００…障害ノード監視ミドルウェア、１６００…通信処理ミドルウェア、１７００…通信コントローラドライバ、１８００…リアルタイムＯＳ、ＣＤｘ…制御データに付加されたノード障害検出符号、ＣＳｘ…状態判定結果に付加されたノード障害検出符号、ＣＰｘ…ネットワーク障害検出符号、Ｄｘ…制御データ、Ｎｘ…ノードｘ、Ｓｘ…状態判定結果、ＭＯＮ…ノード状態判定処理、ＥＸＤ…ノード状態判定結果送受信処理、ＩＤ…障害ノード特定処理、１４２０…担当ノードの状態判定結果格納部、２０００，
２０１０…状態判定担当ノード変更スケジュール、２０２０…状態判定担当ノード変更タイムチャート、２０３０…状態判定代行対象ノード変更スケジュール、Ｎ１０Ａ，Ｎ10Ｂ…通信線、Ｎ１０１Ａ〜Ｎ１０５Ｂ…ノード、２１００…ネットワーク構成設定部、2150…ネットワーク構成要素選択領域、２２００…ネットワーク主設定部、２２１０…ノード状態監視方式指定ボタン、２２２０…ノード状態監視方式表示、２２３０…グループ設定ボタン、２２４０…ソースファイル等出力ボタン、２２５０…ノード状態監視方式リスト、２３００…ノード状態監視グループ設定画面、２３１０…ノード状態監視グループ設定画面のチャネルＡ設定部、２３２１…所属ノード状態監視グループ指定部、２３３０…ノード状態監視グループ数変更ボタン、２３６０…設定同期ラジオボタン、２３５０…ノード状態監視グループ設定画面のチャネルＢ設定部、２３８０，２５８０，２６８０…実行ボタン、２３９０，２５９０，２６９０…キャンセルボタン、２５００…ノード状態監視グループ条件設定画面、２５１０…ノード状態監視グループ条件設定画面のチャネルＡ設定部、２５２１…状態監視対象指定部、２５３４…状態判定既対象表示、２５４０…設定同期ラジオボタン、２５５０…状態判定結果送信指定部、２５６０…状態判定担当ノード数指定部、２５７０…状態判定担当スケジューリング方式指定部、２６００…ノード状態監視詳細設定画面、２６１０…ノード状態監視詳細設定画面のチャネルＡ設定部、2620…所属ノード状態監視グループ指定部、２６３４…障害特定ノード指定部、２６５０…ノード状態監視詳細設定画面のチャネルＢ設定部。

Claims (14)

1. 通信経路を介して接続された複数の車載機器を備えた車両制御システムにおいて、
   前記複数の車載機器は、それぞれ、
   自己以外の他の車載機器の状態を診断し、
   自己が診断した他の車載機器の状態を、他の車載機器との間で交換し、
   自己が診断した他の車載機器の状態と、他の車載機器から取得した他の車載機器の状態
   とに基づいて、他の車載機器の状態を判定する車両制御システム。
2. 請求項１において、
   前記複数の車載機器は、所定の時間間隔で、前回の値に対して所定の法則に従って変化
   する信号を、他の車載機器に対して出力しており、
   他の車載機器は、受信した信号の値と、前回受信した値から前記所定の法則に基づいて
   予測した受信信号の値とが異なるときは、当該信号を出力した車載機器が異常であると判
   断することを特徴とする車両制御システム。
3. 請求項２において、
   前記複数の車載機器が送信する信号は、毎回所定幅ずつインクリメントされる通し番号
   であり、
   他の車載機器は、受信した通し番号の値が、前回受信した通し番号の値から増加してい
   ないときは、当該信号を出力した車載機器が異常であると判断することを特徴とする車両
   制御システム。
4. 請求項１において、
   前記複数の車載機器は、他の車載機器に対して送信するデータを加算した得サム値を当
   該送信データに付加して送信し、
   当該信号を受信した他の車載機器は、受信データを加算した値と、当該データに付加さ
   れた前記サム値とが異なる場合には、当該送信信号を出力した車載機器が異常であると判
   断することを特徴とする車両制御システム。
5. 請求項１において、
   前記複数の車載機器は、それぞれ、通信経路を介して接続された自己以外の他の車載機
   器のうち、予め割り当てられた車載機器の状態を判定することを特徴とする車両制御シス
   テム。
6. 請求項５において、
   前記複数の車載機器に対して割り当てられる判定対象の車載機器を、判定周期ごとに変
   更することを特徴とする車両制御システム。
7. 請求項１において、
   前記複数の車載機器は、相互に制御データを送受信して車両の制御機能を実現するよう
   に構成されており、当該制御データと前記送信信号とを結合して、他の車載機器に対して
   送信することを特徴とする車両制御システム。
8. 請求項７において、
   前記複数の車載機器は、他の車載機器から受信した制御データと、前回その車載機器か
   ら受信した制御データとの差分を計算し、当該差分が所定の閾値以上であるときは、その
   車載機器が異常であると判断することを特徴とする車両制御システム。
9. 請求項１において、
   前記複数の車載機器は、相互に制御データを送受信して車両の制御機能を実現するよう
   に構成されており、
   前記複数の車載機器は、判定対象とする他の車載機器ごとに異常と判定された回数を数
   えるカウンタを備え、当該カウンタの数値が所定以上となったときに当該他の車載機器を
   使用する車両の制御機能に対し、当該車載機器が異常であることを表示することを特徴と
   する車両制御システム。
10. 請求項９において、
    前記複数の車載機器は、前回に異常と判断された車載機器の状態が正常と判断された場
    合に、前記カウンタの値をデクリメントすることを特徴とする車両制御システム。
11. 請求項９において、
    前記複数の車載機器は、前回に異常と判断された車載機器の状態が正常と判断された場
    合に、前記カウンタの値を維持することを特徴とする車両制御システム。
12. 請求項９において、
    前記複数の車載機器のうち、いずれかの車載機器が特定の他の車載機器の状態を異常状
    態若しくは異常発生の直前の状態であると表示したときは、それ以外の車載機器も当該異
    常状態若しくは異常発生の直前の状態であると表示された車載機器を判定するためのカウ
    ンタ値を同様の状態に合わせることを特徴とする車両制御システム。
13. 請求項１乃至１２のいずれか一項に記載の車両制御システムに用いられる車載機器であ
    って、
    少なくとも自己以外の他の車載機器の動作状態を含むノード状態を判定するノード状態
    判定手段と、
    前記ノード状態判定手段により自らが判定した前記ノード状態判定結果を他ノードに送
    信し、他の車載機器が判定したノード状態判定結果を受信する状態判定結果送受信手段、
    および
    前記自らが判定したノード状態判定結果および受信した前記他の車載機器によるノード
    状態判定結果とを用いて、異常が発生した車載機器を特定する障害ノード特定手段と、を
    備えることを特徴とする車載機器。
14. 請求項１乃至１２のいずれか一項に記載の車両制御システムを複数備え、
    各制御システム間で、各制御システム内の複数の車載機器の状態判定結果を送受信する
    ことを特徴とする車両制御システム。

Images