以下、図面に基づき、本発明の車両制御システムの実施形態について説明する。
始めに、図1から図4を用いて、本発明の車両制御システムの基本構成を説明する。本発明の車両制御システムは、図1に示すように、複数のノード、すなわちノード1(N1),ノード2(N2)・・・,ノードn(Nn)から構成されており、これらのノードがネットワーク100を介して接続されている。ここで、ノードとはネットワークに接続され、当該ネットワークを介して情報通信可能な処理装置であり、具体的には、車両に搭載された各種の電子制御装置,アクチュエータドライバ,センサ等が含まれる。ネットワーク100は多重通信可能な通信ネットワークであり、あるノードから当該ネットワークに接続された他の全てのノードに対して同一内容を同時に送信するブロードキャスト送信が可能な構成となっている。
各ノードN1,N2・・・,Nn(以下Nx)は、ノード状態判定手段x1(11,21・・・,n1),状態判定結果送受信手段x2(12,22・・・,n2)及び障害ノード特定手段x3(13,23・・・,n3)を備える。ここで、xはノード番号(1,2・・・,n)であり、以下同様に記載する。
ノード状態判定手段x1(11,12・・・,n1)は、自ノードの状態を判定する自ノード状態判定手段x102(1102,2102・・・,n102)と同一ネットワーク内にある他のノードの状態を判定する他ノード状態判定手段x101(1101,2101・・・,n101)とを有する。ここで「自ノード状態」とは自ノードの自己診断結果を指すものとし、「他ノード状態」とは、判定をするノードからみて他の各ノードから送信されるデータが正しいか否かの状態を指すものとする。例えばノード1からみてノード2の「他ノード状態」が正常であると判定されるためには、ノード2のハードウェアが正常動作し、ノード2の演算処理が正常に行われ、さらにノード2からノード1への通信が誤り無く行われる必要がある。なお他ノード状態の判定方法の詳細については後述するが、例えば、全てのノードが通信サイクルごとに通番データのインクリメントを行ってブロードキャスト送信する構成とすることにより、特定のノードから受信した通番データがインクリメントされていない場合に当該ノードの「他ノード状態」が異常であると判断できる。また、以下の実施例においては、上述の「自ノード状態」と「他ノード状態」とを合わせたネットワーク全体のノードの状態を「ノード状態」と記載する。
状態判定結果送受信手段x2(12,22・・・,n2)は、前記ノード状態判定手段x1により判定されたノード状態(自ノードが判定したノード状態)を他ノードに送信する送信処理手段x203(1203,2203・・・,n203),他ノードが判定したノード状態を受信する受信処理手段x202(1202,2202・・・,n202)、及び上述の自ノードによるノード状態判定結果及び他ノードによるノード状態判定結果を格納する状態判定結果格納手段x201(1201,2201・・・,n201)を有する。
障害ノード特定手段x3(13,23・・・,n3)は、自ノードによる状態判定結果と前記状態判定結果送受信手段x2により受信した他ノードによる状態判定結果を用いて障害ノードを特定する。
図2を用いて、上述の状態判定結果送受信手段x2の機能について詳述する。図2に示すように、状態判定結果送受信手段x2は、自ノードによる状態判定結果と、受信した他ノードによる状態判定結果とを格納する状態判定結果格納手段x201を備える。例えば、ノード1の状態判定結果格納手段1201内のバッファ141に保存されたノード1による状態判定結果は、ネットワーク100を介して、同一ネットワーク内のノード1を除く全ノードに配信され、各ノードの状態判定結果格納手段x201内のバッファx41(ここでは、241,341・・・,n41)に保存される。ノード2からノードnによる状態判定結果の送受信についても同様である。
したがって、各ノードの状態判定結果格納手段x201は同一ネットワーク内のノード数分(図2ではn個)のバッファを備えている。このように構成することで、全てのノードによるノード状態の判定結果を格納し比較することが可能となり、特定のノードによる判定結果を信用してよいか否かを判断することが可能となる。例えば、ノード1がノード2を「故障」と判定している場合であっても、他のノード2〜nがノード2を「正常」と判定している場合には、ノード1の方が故障しているという判定をすることも可能となる。
図1に示す各ノード(N1,N2・・・,Nn)の基本構成を、図3を用いて説明する。図3ではノード1を例に挙げて説明しているが、本構成はネットワーク内の全てのノードで同一である。ノード1は、前述の通り、ノード状態判定手段11の構成要素である他ノード状態判定手段1101,自ノード状態判定手段1102,状態判定結果送受信手段12の構成要素である状態判定結果格納手段1201,受信処理手段1202,送信処理手段1203,障害ノード特定手段13、ネットワークアクセス手段16、および制御ロジック実行手段17を備えている。
図3においては、ノード1はネットワークアクセス手段16により、例えばノード2が送信したデータを受信している。ノード2の送信データには、ノード2による状態判定結果S2が含まれる。他ノード状態判定手段1101は状態判定結果S2のデータの合理性をチェックすることにより、ノード2の状態を判定し、判定結果E11を状態判定結果格納手段1201内の自ノードによる状態判定結果格納用バッファ141に格納する。これらのデータに異常がない場合は、ノード2による状態判定結果S2(自己診断結果+ノード1,3〜nの判定結果)はノード2による状態判定結果格納用バッファ142に保存される。他ノード状態判定手段1101は、同様に、ノード3からノードnの状態判定を行い、各々の判定結果E1nを自ノードによる状態判定結果格納用バッファ141に格納し、各ノードの状態に異常が無ければそれらのノードによる状態判定結果S3〜Snを所定のバッファ143(図示せず)〜14nに保存する。
障害ノード特定手段13は、バッファ141から14nに格納されたデータを用いて障害ノードを特定し、その結果を制御ロジック実行手段17に通知する。自ノード状態判定手段1102は、ノード1自体のCPU,メモリ,周辺入出力回路などの自己診断結果E12を自ノードによる状態判定結果格納用バッファ141に格納する。ノードがセンサ、アクチュエータを制御し、これらの状態を診断している場合は、E12にはノード自体の自己診断結果だけでなく、センサ、アクチュエータ等の診断結果を含めてもよい。本診断結果E12は、制御ロジック実行手段17にも通知される。送信処理手段1203は、自ノードによる状態判定結果S1を一つの通信データとして送信する。
状態判定結果格納バッファ141から14nに格納される状態判定結果のデータ構造を図4に示す。状態判定結果は、ノード1からノードnの各ノードの状態データから構成される。各ノードの状態は、障害1から障害mそれぞれの有無で表現されている(障害内容の具体例については後述する)。各障害の有無の判定および判定結果の所定領域への格納は他ノード状態判定手段x101が行うが、自ノード状態の領域には、前述のように、自ノード状態判定手段x102による判定結果が格納される。なお、図4では判定結果を便宜上「有」「無」と記載したが、実際には所定のビット数の数字で表現される。
図5および図6を用いて、他ノード状態判定の実施例について説明する。図5は、図3で示したノード1の基本構成に、他ノード状態判定を行うためのノード障害検出符合付加手段18を加えたものである。図6は、図5における枠R内及び枠S内の動作の詳細を、ノード2を送信側(S)、ノード1を受信側(R)として記載したものである。
図5において、ノード障害検出符号付加手段18は、自ノードによる状態判定結果S1それぞれに、これらのデータを受信する他ノードにおいてノード1の障害を検出するための符号CS1を付加する。送信処理手段1203は、自ノードによる状態判定結果S1にヘッダ部を付加し、さらにネットワーク障害検出符号付加手段1901により、この通信データが他ノードに配信される途中、ネットワーク100上で何らかの障害が発生したかどうかを検出するためのネットワーク障害検出符号CP1を付加する。
例えばノード2からの通信データを受信する場合、受信処理手段1202内のネットワーク障害判定手段1902は、ノード2のネットワーク障害検出符号付加手段2901が付加したネットワーク障害検出符号CP2とCP2以外のデータ部を用いて、通信データが配信されるときにネットワーク100上でビット反転などによるデータ変化が発生していないかを判定する。他ノード状態判定手段1101は、ノード2のノード障害検出符合付加手段28が付加した符号CS2およびS2を用いてノード2の障害発生有無を判定し、この判定結果E11およびネットワーク障害判定手段1902からの判定結果E13を、自ノードによる状態判定結果バッファ141のノード2状態の領域に格納する。ネットワーク障害判定手段1902が自ノードによる状態判定結果バッファ141に直接アクセスして結果を格納してもよい。
ノード障害検出符号付加手段,他ノード状態判定手段,送受信処理手段の詳細を図6に示す。図6では、ノード2が障害検出符号を付加したデータを送信し、これをノード1が受信し、障害を判定する実施例を示している。ノード障害検出符号付加手段28は、ノード2による状態判定結果S2に対する通番付加部283,サム値付加部284を備える。通番付加部283は、データを送信するたびにデータに付加した通番をインクリメントする。サム値付加部284は、さらに、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値をサム値として付加する。送信処理手段2203が備えるフレーム処理部2903は、障害検出符号を付加したS2に対してヘッダ付加等の通信プロトコル処理を行う。その後、ネットワーク100上で通信データがビット反転などにより破壊されていないかを検出するために、公知のCRC(巡回冗長検査)符号を付加する(29011)。
ノード1はノード2からデータを受信後、ノード2での障害検出符号付加順番とは逆の順番で障害検出を行う。ネットワーク障害判定手段1902では、フレーム未受信判定部19022およびCRC異常判定部19021により、データ未受信やデータ破壊などのデータリンク層における障害を検出する。図示していないが、同期エラー、フォーマットエラーなど通信プロトコルレベルの障害も本ネットワーク障害判定手段1902で行う。障害が検出された場合は、判定結果E13を他ノード状態判定手段1101のネットワーク障害判定結果受信部11011に送信する。一方、他ノード状態判定手段1101は、S2に対して、サム値異常判定部11015、通番異常判定部11016により、データ自体の合理性をチェックし、ノード2の状態を判定する。サム値異常判定部11015は、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値が、送信側のサム値付加部でデータに付加したサム値と一致するか否かを判定する。また、通番異常判定部11016は、今回の受信データに付加されている通番が前回の受信データの通番からインクリメントされているか否かを判定する。以上のいずれの判定部においても異常が検出されなかった場合に、S2は状態判定結果格納手段1201の所定領域に格納される。異常が検出された場合は、当該異常を検出した判定部の上位の異常判定は行わない。
本実施例の構成によれば、ノード1でサム値異常が検出された場合は、ノード2のサム値付加部以下またはノード1のサム値異常判定部以下でのデータ転送時、あるいは、ノード2の送信処理手段またはノード1の受信処理手段における処理実行時に障害が発生し、データが変化したことを示しているので、従来のネットワーク障害判定手段だけでは検出できないこれらの障害を検出することが可能となる。
また本実施例の構成によれば、ノード1で通番異常が検出された場合は、何らかの障害によりノード2で通番のインクリメントができない、あるいはノード1の通番異常判定処理実行時に障害が発生したことを示している。後述するように、制御ロジック実行手段とノード障害検出符号付加手段をソフトウェアにより実装する場合、例えば、ノード2の車両制御ソフトウェアが無限ループ等によりCPUリソースを独占してしまった場合には、ノード障害検出符号付加ソフトウェアは通番をインクリメントできなくなるため、ノード1の通番異常判定部ではノード2でソフトウェアの障害が発生したことを検出することができる。
従って、車両制御ソフトウェア障害時には、当該ソフトウェアにより生成される送信データは更新されないにもかかわらず、送信バッファに保存されているデータが送信され続けるため、受信ノードのネットワーク障害判定手段1902はデータを正常に受信できていると判断してしまうが、本実施例の構成によれば、ネットワーク障害(データリンク層での障害)は発生していないけれども特定のノード内部の処理内容が誤っているような故障状態をも正確に監視することが出来る。
以上詳述したように、本実施例における車両制御システムは、通信データが正常に受信できたか否かを判定するネットワーク障害判定手段による判定結果に加えて、ノード障害検出符号付加手段および他ノード状態判定手段を用いて通信データ自体の合理性をチェックすることにより得られる、ネットワーク障害判定手段だけでは検出できない、ソフトウェアの稼動状況などデータリンク層の上位階層の障害有無までを含んだノード状態判定結果を他ノードと相互に交換するように構成しているため、低コストで障害ノードを正確に特定することが可能となる。
図7は、ノード状態監視機能を実現するフローチャートを示している。本フローチャートの処理は、各ノードで実行される。
ステップS100で処理を開始し、ステップS110では、各種通信障害の有無をもとに、自ノードによるノードの状態判定を行う。このステップS110の処理をMONとする。ステップS120では、ステップS110の状態判定結果をグループ内の他ノードに送信(放送)する。また、他ノードによるノード状態判定結果を受信する。このステップS120の処理をEXDとする。
ステップS130では、自他ノードによる状態判定(MON)結果から、ノードごと・障害種類ごとに障害有無を確定させる。このステップS130の処理をIDとする。
ステップS180では、ステップ130で得たノード障害情報を、ノード上で動作する諸プログラムに通知する。通知の方法は、特定記憶領域の値を書き換えるなどにより行う。このノード障害情報は、ノードごと・障害種類ごとの障害有無が含まれ、ノードが異常・障害ありということだけでなく、ノードが正常・障害なしということもわかる。ノード上で動作する諸プログラムとしては、制御ロジック、ノード状態の表示、ノードの状態ロガーなどが考えられる。
ステップS180のノード障害情報通知の際には、IDの結果をそのまま通知してもよいし、後述のように障害カウンタを挟んで通知してもよい。ステップS190で処理を終了する。
図8および図9を用いて、ここまで説明してきたノード状態判定手段x1、自ノードによるノード状態判定結果送信手段および他ノードによるノード状態判定結果受信手段x2、および障害ノード特定手段x3それぞれによる処理の実行タイミングの実施例について説明する。
図8は、各ノードの送受信タイミングと上記処理の実行タイミングを示したタイムチャートである。一つの通信単位(以下通信サイクルと記載)において、ノード1からノードnまでが順番にデータを送信し、各ノードが自ノード及び他の全ノードのノード状態を判定する。この通信サイクルを繰り返すことで、各ノードが判定した全ノードのノード状態判定結果を相互に交換し、比較することが可能となる。このような通信形態は、例えば、車両制御用の時分割多重通信であるTTP通信やFlexRay通信などを用いて実現することができる。
繰り返される通信サイクルの中のあるサイクルを表示するものとして、通信サイクルiと通信サイクルi+1を例にとって説明する。
通信サイクルiでは、各ノードにおいて自ノード単独でネットワーク内ノードの状態判定処理(MON(i))を行う。まず、ノード1がsnd処理(送信処理)で前記の各種障害検出符号を付加したデータを送信後、ノード2以下のノードはこのデータをrcv処理(受信処理)Sx11(S211,S311・・・,Sn11)で受信し、前述の方法(図3〜図6参照)によりノード1の状態判定を行う。次にノード2がsnd処理で前記の各種障害検出符号を付加したデータを送信し、ノード1及びノード3〜nがこのデータをrcv処理Sx12(S112,S312・・・,Sn12)で受信し、前述の方法(図3〜図6参照)によりノード2の状態判定を行う。以下、ノード3〜nも同様に順次データを送信し、当該データを受信した他のノードが当該データを送信した送信ノードの状態判定を行う。通信サイクルiの状態判定処理(MON(i))が終了した時点では、各ノードの状態判定結果格納手段n201には、自ノード状態と他ノード状態を含むネットワーク全体のノード状態を自ノードが判定した結果が格納されている。この時点では各ノードは自ノード単独による判定結果しか保持していないため、他ノードによる判定結果と比較することが出来ない。このため、あるノードが特定の他ノードの障害を検出したとしても、検出した障害が本当に当該他ノードの障害を意味している場合と、自ノードが障害を起こして誤判定をしている場合とが考えられ、これらを判別することはできない。
そこで、次の通信サイクルi+1では、各ノードが保持している自ノードによる状態判定結果Snをノード間で相互交換し、各ノードが自ノードによる判定結果と自分以外の全ての他ノードによる判定結果を格納する。
まず、ノード1がsnd処理S141で自ノードによるノード状態判定結果S1を送信し、ノード2〜nがこのデータをrcv処理Sx41(S241,S341・・・,Sn41)で受信する、以下ノード2〜nも同様にsnd処理S242・・・,Sn4nにより、各ノードは通信サイクルiにおける自ノードによるノード状態判定結果Sn(i)を送信する。
なお、この送信データは図5に示すように、通信サイクルiにおける判定結果Snに各種障害検出符号Csn等を付加したものである。ここで受信ノードは、rcv処理Sx41,Sx42・・・,Sx4nにより送信データを受信し、障害検出符号Csnの解析により当該送信ノードの状態判定を行って、当該判定結果を通信サイクルiにおける自ノードによる判定結果として格納する。そして、上記の判定結果が正常である場合は、当該データに含まれる当該他ノードによる状態判定結果Sn(通信サイクルi)を格納する。
これにより、通信サイクルiにおけるノード状態判定結果Snの交換(EXD(i))を行うとともに、通信サイクルi+1における自ノードによるノード状態判定(MON(i+1))を行うことが出来る。
ノード状態判定結果Snの交換(EXD)が終了すると、その後、処理Sx3において、自ノードによる状態判定結果(通信サイクルi)と通信サイクルi+1で受信した他ノードによる状態判定結果Sn(通信サイクルi)を用いて最終的に障害ノードを特定する。障害ノードを特定するアルゴリズムについては後述するが(図10〜図14)、例えば多数決を用いることができる。また、ネットワークに接続されたノードのうち、所定の個数若しくは割合以上のノードによって障害発生と判定されたノードを障害ノードと判定することもできる。
すなわち各ノードは、通信サイクル1の前半では、自ノードによるノード状態判定結果送信および他ノードによるノード状態判定結果受信処理(状態判定結果交換:EXD)を行い、後半では、障害ノード特定処理(ID)を行う。以上のように、本実施例によれば、ある通信サイクルで検出された障害を次の通信サイクルで特定することができる。図9に示すように、このような通信と判定を繰り返すことで、通信サイクルiでは、通信サイクルi−1における状態判定結果の交換(EXD(i−1))と通信サイクルiにおける自ノードによるノード状態判定(MON(i))が行われ、通信サイクルi−1における障害発生ノードの特定処理(ID(i−1))が行われることになる。
なお、自ノードによる自ノード状態判定結果(例えばノードnによるノードnの状態)は、障害発生ノードの特定処理では用いないことが望ましい。すなわち、ノード1の障害判定においてはノード2乃至ノードNによる判定結果を用いて特定処理が行われ、ノード2の障害判定においては、ノード1及びノード3乃至ノードnによる判定結果を用いて特定処理が行われることが望ましい。これは、自ノードによる自ノード状態判定結果を多数決に加えると、そのノードに異常が発生している場合には、異常をきたした判定結果が多数決に加わることになり、判定精度を低下させるおそれがあるからである。
但し、多数決には使われないとしても、各ノードが自ノード状態の判定を行い、他のノードに送信(放送)することには意味がある。すなわち、各ノード上で動作するアプリケーションプログラムが、当該ノードが故障しているか否かを認識した上で制御ロジック等を選択することが出来るからである。
なお、上述の実施例では、便宜上ノード1からnまで順番に送信を行う構成としたが、一回の通信サイクルの中で各ノードが一回ずつ自ノードによる判定結果Snを送信する構成であれば、ノード1〜nがデータを送信する順番は問わない。また通信サイクルごとに送信順序が入れ替わっても問題はない。
図10から図14を用いて、障害ノード特定手段x3の実施例について詳述する。図10は障害ノード特定手段x3の構成を示したものであり、説明の便宜のためノード1の構成として記載している。他のノード2〜nの障害ノード特定手段x3(23・・・,n3)も同様の構成である。障害ノード特定手段(ノード1)13は、障害ノード特定アルゴリズム実行部131,障害カウンタ132,障害カウンタリミット値到達判定部133,障害カウンタリミット値設定部134,ノード障害フラグ格納部135から構成されている。
障害カウンタリミット値設定部134およびノード障害フラグ格納部135は、制御ロジック実行手段17からアクセスが可能である。障害ノード特定アルゴリズム実行部131は、状態判定結果格納手段1201が保持する自ノードによる状態判定結果および他ノードによる状態判定結果を用い、所定のアルゴリズム(図11,図12参照)に従って、障害ノードおよび障害の種類を特定し、障害カウンタ132の該当するカウンタをカウントアップする。障害カウンタリミット値到達判定部133は、各々のカウンタの値が、制御ロジック実行手段17が障害カウンタリミット値設定部134に設定したリミット値に達したか否かを判定し、達した場合には、ノード障害フラグ格納部135の達したカウンタに該当するノード障害フラグをセットする。制御ロジック実行手段17は、ノード障害フラグ格納部135にアクセスすることにより、各ノードの障害有無を知ることができ、この情報に応じた制御の切り替えが可能となる。また、障害カウンタリミット値設定部134を備えたことにより、制御ロジック実行手段17が設定したリミット値、すなわち制御上許容できる障害検出時間に達するまでは、当該実行手段17に対して障害をマスクしておくことができる。
図11は障害カウンタ132の動作の一例を示したものである。図11では、通信サイクルiのノード2の送信時刻よりも後の時刻でノード2に障害1が発生し、この障害が通信サイクルi+4のノード2の送信時刻よりも後の時刻まで続く場合を示している。ノード2の障害1に対する障害カウンタリミット値は3であるとする。通信サイクルi+1においてノード2以外の各ノードで検出されたノード2の障害は、通信サイクルi+2前半でのEXD処理を経て、通信サイクルi+2後半のID処理で確定し、該当する障害カウンタがインクリメントされる。同様に、通信サイクルi+2および通信サイクルi+3においてもノード2の障害が検出されるため、通信サイクルi+4のID処理の結果カウンタ値がリミット値の3に達し、該当するノード障害フラグがセットされる。障害が継続している間は、障害カウンタは3を保持し、ノード障害フラグもセットされたままである。その後、通信サイクルi+5においてノード2の障害が検出されなくなると、通信サイクルi+6のID処理によりノード2の正常状態復帰が確定し、該当する障害カウンタおよびノード障害フラグがリセットされる。以上説明した障害カウンタの動作は、他のノードでも同様であるため、全てのノードの制御ロジック実行手段x7は、あるノードの障害発生時あるいは正常復帰時に同時に制御を切り替えることができる。
図12に二種類の障害カウンタの実施例を示す。障害発生後、正常状態に復帰した際に、復帰型障害カウンタ132Aは、カウンタをデクリメントするのに対して、累積型障害カウンタ132Bは、デクリメントせずにそのまま値を保持する。復帰型障害カウンタ132Aは、ある通信サイクルにおいて正常と判断される度にカウンタの値が減算されるため、障害の発生により一時的にカウンタ値が増大したとしても、障害が解消して正常なノード状態が持続すればカウンタ値はゼロに戻る。従って、ある程度の期間にわたって障害が連続しないとノード障害フラグがセットされないため、CRC符号のエラーなど、通信回線の性質上一定確率で発生するエラーであるが低頻度であるため制御ロジックの実行に影響がないエラーを制御ロジック実行手段に対してマスクすることができる。
一方、累積型障害カウンタ132Bを用いる場合は、ノードが正常に戻ってもカウンタの値は減算されることが無いので、ノード状態が異常と判断される度に値が増大していく。従ってハーネスのコネクタの半嵌合や接触不良などに起因する間欠障害を確実に検出するのに有効である。なお、制御ロジック実行手段が制御に応じて、使用する障害カウンタの種類を選択できるようにしてもよい。
図13は障害ノード特定アルゴリズム実行部131における処理フローを示したものである。なお説明の便宜上、ノード1の障害ノード特定アルゴリズム実行部131における処理を示しているが、他のノードにおける処理も同様である。
障害ノード特定アルゴリズム実行部131は、ノード1からノードnまで順番にノード状態を判定する。ノードxに対する障害判定処理S1xを行う際には、障害ノード特定アルゴリズム実行部131は、ノードxを除く全ノードのノードxに関する状態判定結果を状態判定結果格納手段1201から読み出す。ただし、障害が検出されたノードによる状態判定結果は使用しない。ノードxに対する障害判定処理S1xは、読み出した状態判定結果を用いて、障害ごとに障害発生判定処理S1xE1,S1xE2・・・,S1xEmを実行する。
図14に障害発生判定処理フローの実施例を示す。ノード2に対する障害1発生判定処理Step12E1を例にとっているが、本図14の処理フローはすべての障害発生判定処理において同様である。ノード2に対する障害1発生判定処理Step12E1は、まず処理Step1で自ノードによる障害判定結果を参照し、ノード2で障害1が発生と判定したか否かをチェックする。障害1が発生していない、すなわち正常と判定している場合には、処理Step2において、障害1発生と判定した他ノードの数が、制御ロジック実行手段により設定された判定閾値Xよりも小さいかどうか、すなわち多数ノードが正常と判定しているかどうかを判断する。小さい場合は、ノード2で障害1は発生しておらず正常という判定Diag1になる。さらに、処理Step3において、障害1発生と誤って判定したノードがあるかどうかを判断し、そのようなノードがある場合には、ノード2に障害1発生と判定したノードに障害が発生という判定Diag2Aになる。処理Step3において、誤った判定をしたノードがない場合は、ノード2に対する障害1発生判定処理Step12E1を終了し、次のノード2に対する障害2発生判定処理Step12E2に進む。処理Step2において、障害1発生と判定した他ノードの数が判定閾値X以上の場合は、ノード2に障害1発生という判定Diag3になる。
一方、処理Step1において、自ノードがノード2で障害1発生と判定している場合には、処理Step4に進み、障害1発生と判定した他ノード数が判定閾値X以上か、すなわち自ノードの判定に賛同しているノード数が判定閾値X以上かどうかを判断する。判定閾値X以上の場合は、処理Step2におけるNoの場合と同様に、ノード2に障害1発生という判定Diag3になる。処理S4において、障害1発生と判定した他ノード数が判定閾値Xより小さい場合には、自ノードの判定に賛同しているノードが少数のため、自ノードも含め、ノード2に障害1発生と判定したノードに障害発生という判定Diag2Bになる。これは、処理Step3による、多数ノードの判定に賛同しない少数派のノードに障害発生という判定Diag2Aと対をなす判定である。障害発生ノードおよび障害種類が特定された場合、すなわち判定Diag2A,Diag2B,Diag3の場合は、処理Step5により、該当する障害カウンタをインクリメントして、ノード2に対する障害1発生判定処理Step12E1を終了する。
なお、判定Diag2A,Diag2B,Diag3ならば即、障害ありとしてノード上の諸プログラムに通知する場合には、Step5は行わなくてよい。
本実施例では、制御ロジック実行手段が、制御するシステムにおけるノードの多重障害をどこまで許容できるかに応じて判定閾値Xを設定することができる。例えばノード総数nのシステムでX=n−2と設定すれば、2ノードの障害までは残りの正常なノード間で正しく障害ノードを特定することができる。また、本実施例のアルゴリズムでは、あるノードの状態について自ノードが正常であると判定したにもかかわらず、異常であると判定したノードが多数となり自ノードの判定が少数派となった場合(処理S2のNoの場合)でも、判定Diag2Bとは異なり、自ノードに障害ありとは判定しないようにしている。
以上説明してきた本発明における個々の要素の実施例を総合した二つの実施例を図15および図16に示す。これらの図、各ノードの送信タイミングと送信データ,障害発生タイミングを表すタイムチャート、および障害発生時の各ノードの状態判定結果格納手段x201,障害カウンタx32,ノード障害フラグx35の変化を示したものである。二重線で囲ったデータは送信データであることを示す。簡単のため、送信データとしては、状態判定結果のみを図示しているが、実際には状態判定結果とともに制御データも送信しているものとする。同一ネットワーク内のノード数は4、制御ロジック実行手段が設定する障害ノード特定アルゴリズム実行部x31の判定閾値Xは3,障害カウンタリミット値は2とする。各ノードの状態は、通番異常(E1),サム値異常(E2),CRC異常(E3),フレーム未受信(E4)という4種類の障害の有無で表される。なお、本実施例において、各ノードの自ノード状態判定結果は0であり、各ノードとも自ノードは正常であると判定しているものとする。
図15では、通信サイクルi+1のスロット1の時間帯において、ノード3にCPUの障害が発生し、ソフトウェアの動作に異常が生じたことを想定している。ノード3は通信サイクルiにおける状態判定結果をスロット3で送信することになっているが、ノード障害検出符号付加手段38は、CPU障害のため、通番をインクリメントすることができない。したがって、他のノードはノード3からの状態判定結果受信時に、通番がインクリメントされていないことを検出し、ノード3に通番異常が発生したと判定する。しかし、この時点では、ノード3の障害を検出しても、自ノード単独の判定であるため、ノード3の障害なのか、自ノードの判定誤りなのかを正確に特定することはできない。そこで、次の通信サイクルi+2で、ノード1,2,4は、自ノードによる状態判定結果0080(ノード3の通番異常)を送信する。各ノードは、通信サイクルi+2の後半で、ノード1,2,4による状態判定結果を用いて、図14に示した障害ノード特定アルゴリズムを実行する。これにより、ノード3の通番異常が確定するため、ノード1、2、4は障害カウンタE1_3をカウントアップする。ノード3の障害は通信サイクルi+2以降も継続しているため、通信サイクルi+3でも同様にして障害カウンタE1_3がカウントアップされ、当該障害カウンタの値がリミット値に達したため、ノード障害フラグの該当箇所がセットされる。
図16では、通信サイクルi+1のスロット3の時間帯において、ノード2に受信部の障害が発生したことを想定している。ノード2は、通信サイクルi+1でノード3からのデータを受信できないため、ノード3に障害が発生したと判定し、通信サイクルi+2で自ノードによる状態判定結果0010(ノード3の送信データ未受信)を送信する。しかし、ノード1,4はノード3からのデータを正しく受信しているため、状態判定結果0000を送信する。したがって、ノード3の送信データ未受信障害の発生判定処理において、ノード2に障害が発生したことが確定し、障害カウンタE4_2がカウントアップされる。ノード2も他ノードの状態判定結果から自ノードに障害が発生したことが分かり、自ら自ノードの障害カウンタE4_2をカウントアップする。ノード2は通信サイクルi+2では正常復帰しているため、復帰型障害カウンタの場合は、通信サイクルi+3でカウンタ値が0に戻る。
なお、図15,図16に示す送信データ(フレーム)の構成では、各ノードの状態および障害カウンタとして、通番異常(E1),サム値異常(E2),CRC異常(E3),フレーム未受信(E4)という4種類の障害を示しているが、信頼性向上のためにネットワークを二重化しているシステムでは、ネットワーク1系でフレーム未受信(E1),ネットワーク1系でフレーム異常(E2),ネットワーク2系でフレーム未受信(E3),ネットワーク2系でフレーム異常(E4)というようにネットワークの系ごとに障害を分類する構成も考えられる。ここで、フレーム異常とは、何らかのフレームを受信したが、そのフレームに通信プロトコルで定めたフォーマットエラー,CRCエラー,通番異常,サム値異常などが含まれていることを示している。
図15,図16では、各ノードで障害カウンタのカウントアップが同時に実行されるため、同時にノード障害フラグがセットされ、制御アプリケーションに障害が通知される。しかし、ノード間で障害カウンタの値が完全に一致せずに、制御アプリケーションに障害を通知するタイミングがノードごとにずれてしまう可能性が考えられる。制御アプリケーションは障害通知に基づいてバックアップ制御処理を実行するため、この場合は、通常時制御処理からバックアップ制御処理に移行するタイミングがノードごとにずれることになり、バックアップ制御を正常に実行できない可能性がある。例えば、あるノードにおいて、障害ノード特定手段における処理中に何らかの過渡的エラーが発生した場合には、障害カウンタを正しくインクリメントあるいはデクリメントすることができなくなり、他ノードの障害カウンタ値との間にずれが生じる。また、途中でリセットされたノードでは障害カウンタが0に初期化されてしまう。
図17は、障害カウンタ値が上記のような理由によりノード間で一致していない場合においても、同時にアプリケーションに障害を通知することのできる実施例を示したものである。図17では、ノード3が障害によりフレームを送信できないときに、その他のノードは前述のように障害ノード特定アルゴリズムによりノード3からのフレーム未受信障害を特定し、ノード3未受信障害カウンタE4_3をカウントアップしているが、ノード2の障害カウンタE4_3の値がノード1,ノード4のそれと一致していない場合を想定している。本実施例では、未受信障害カウンタのリミット値は10であるとする。
ノード1およびノード4の障害カウンタE4_3は、通信サイクルi+1の障害ノード特定処理後にリミット値−1の9になる。両ノードは次の通信サイクルi+2、つまり障害カウンタがリミット値に到達する通信サイクルにおいて、障害通知同期フラグをセットしたフレーム(以下、障害通知同期フレームと記載する)を送信する。ノード2はこのフレームを受信することにより、障害ノード特定処理前に障害カウンタ値をリミット値−1の9に補正する。したがって、本実施例によれば、障害カウンタ値がノード間で一致していない場合でも、制御アプリケーションへの障害通知タイミングを正常な全ノード間で同期させることができる。
これを実現するための送信フレーム構成例(ノード1の場合)を図18に示す。送信フレームは、前述のノード状態判定結果S1、および障害通知同期フラグフィールドSync1から構成される。障害通知同期フラグフィールドSync1では、各ノードの障害カウンタについて、カウンタ値がリミット値−1になったか(1)、否か(0)を表している。図17の実施例において、ノード1およびノード4は通信サイクルi+2で、図18に示すように、障害通知同期フラグフィールドSync1のノード3未受信障害カウンタ(E4_3)のビットをセットしたフレームを送信する。
常時障害カウンタ値そのものをノード間で交換して障害カウンタ値を一致化する場合は、障害カウンタのビット数×エラー要因×ノード数分の通信データ量が必要となるが、実際には常時ノード間で障害カウンタ値を一致させる必要はなく、本実施例のように制御アプリケーションへの障害通知タイミングだけを合わせれば良い。本実施例においては、エラー要因×ノード数分だけの通信データ量で済むため、少ない通信データ量でノード間の制御アプリケーションへの障害通知タイミングを同期させることができる。
障害通知同期フレームを、障害カウンタ値がリミット値−1に達した次の通信サイクルだけでなく、リミット値に達した後も送信し続けることにより、より確実にノード間での障害通知タイミング同期を実現することが可能となる。
図19では、ノード3が障害によりフレームを送信できなくなり、ノード2,ノード4において、ノード3未受信障害カウンタE4_3がリミット値に達したため、ノード3障害時のバックアップ制御を行っているときに、通信サイクルi+1でノード1が新たに通信に加入、あるいはリセット処理等から復帰して通信に再加入した場合を想定している。ノード3未受信障害カウンタE4_3がリミット値に達した後もノード2およびノード4は障害通知同期フレームを送信し続けているため、ノード1は、障害カウンタがリミット値10に達するまでノード2およびノード4とは異なる通常時制御処理を継続することなく、通信に加入した通信サイクルで即座にリミット値を9に補正することができ、バックアップ制御に移行することが可能となる。
図20では、通信サイクルi+1でノード4がノード3未受信障害に関する障害通知同期フレームを送信し、ノード2はこの同期フレームを受信したが、ノード1は受信できなかった場合を示している。ノード2はこの通信サイクルで障害カウンタ値を9に補正し、障害ノード特定処理後に制御アプリケーションに障害を通知する。これにより、ノード2は次の通信サイクルi+2で障害通知同期フレームを送信する。ノード1はこの通信サイクルでは、ノード2あるいはノード4から障害通知同期フレームを受信することができるので、通信サイクルi+1でノード4からの障害通知同期フレームの受信に失敗しても、次の通信サイクルでは他ノードと同様にバックアップ制御に移行することができる。
図17,図19および図20に示した実施例では、障害通知同期フレームを送信するのは、障害カウンタ値がリミット値−1に達した次の通信サイクルであるが、障害カウンタがリミット値に達した、すなわち制御アプリケーションに障害を通知した次の通信サイクルでも良い。ただし、この場合にはノード間で1通信サイクル時間分の障害通知タイミングのずれが生じる可能性があるため、通信サイクル時間を車体運動の時定数に比べて十分小さくしておく必要がある。また、図20では、障害カウンタ値がリミット値−1に達したノードが一つでもあれば、他ノードはこのノードが送信する障害通知同期フレームに合わせて自ノード内の障害カウンタ値を補正するようにしているが、例えば正常ノードのうち、半数以上のノードから障害通知同期フレームを受信した場合のみ、障害カウンタ値を補正するように構成しても良い。
各ノードのソフトウェアおよびハードウェア構成の実施例を図21に示す。本実施例では、本発明の障害ノード監視機能を、車両制御ロジックを実行するための制御アプリケーションソフトウェアの下位に位置するミドルウェアにより実装している。ハードウェアは、CPU1100,通信コントローラ1200,通信トランシーバ1300から、ソフトウェアは、制御アプリケーション1400,障害ノード監視ミドルウェア1500,通信処理ミドルウェア1600,通信コントローラドライバ1700、およびリアルタイムOS1800から構成される。図6におけるパッキング処理、アンパッキング処理は通信処理ミドルウェア1600により、ネットワーク障害検出符号付加処理,ネットワーク障害判定処理,フレーム処理、およびデータの送受信処理は、通信コントローラドライバ1700と通信コントローラ1200により実行される。また、ネットワークアクセス手段x6が通信トランシーバ1300に相当する。
障害ノード監視ミドルウェア1500は、ノード障害検出符号付加処理、他ノード状態判定処理、および障害ノード特定処理を実行し、制御アプリケーション1400にノード状態情報を提供するためのAPI(アプリケーションプログラムインタフェース)を備える。また、下位側には、通信処理ミドルウェア1600と通信コントローラドライバ1700とのインタフェースを有する。本実施例によれば、障害ノード監視機能をミドルウェアで実装することにより、制御アプリケーションは所定のAPIによりノード状態情報を取得することができるようになるため、制御アプリケーションソフトウェアの開発効率を向上させることが可能となる。
以上の実施例においては、ネットワークトポロジーはバス型であったが、図22に示すようにハブを介したスター型としても良い。さらには信頼性を高めるためにはネットワークを二重系にすることが好ましい。本実施例では、ノード1からノードnは、メインのネットワーク100Aおよびバックアップのネットワーク100Bの両方のネットワークに、各々ハブHAおよびHBを介して接続されている。
バス型では、ネットワークの切断時に、切断箇所によってはシステムを構成するノードのほぼ半分ずつのグループにシステムが分断されてしまう可能性があるのに対して、スター型の場合は孤立するノードは一つだけであるため、図14に記載したような障害ノード特定アルゴリズムにより、孤立したノードを正確に特定することができる。
続いて、本発明のノード状態判定を車両制御システムに適用した実施例について説明する。
図23に車両制御システムの実施例を示す。本実施例において車両1はステアリングとブレーキのバックアップ機構を備えているが、備えない車両制御システムでも同様な構成とすることができる。
本実施例の車両制御システム901は、ステアリング951の回転角度を測定する操舵角センサSen1,ブレーキペダル952の踏み込み量を測定するブレーキペダル位置センサSen2,アクセルペダルの踏み込み量を測定するアクセルペダル位置センサSen3,前記運転者の要求を検出するセンサの信号から運転者の意図21解釈し、図示していない車両状態を検出するセンサ(例えば加速度センサ,ヨーレートセンサ,車輪速センサ)からの信号に基づいて、車両運動を統合的に制御する車両運動統合制御ECU910を備え、これらがそれぞれノードとしてメインネットワーク100Aに接続されている。
また、アクチュエータ駆動ノードとして、前輪の操舵力を発生するステアリングモータM1およびステアリングコラム軸上に取り付けられる可変ギア比(VGR)機構に作用するモータM5を制御するSBW(Steer-by-Wire) ・VGR−Driver−ECU911、後輪の操舵力を発生するステアリングモータM2を制御するSBW−Driver−ECU912,四輪のブレーキ力を生成するブレーキモータM3A〜M3Dを制御するBBW(Brake-by-Wire)−Driver−ECU913A〜913D,車両の駆動系を総合的に制御するDBW(Driver-by-Wire)系統合制御ECU920,ダンピング力を調整するサスペンションモータM4A〜M4Dを制御するEAS(Electronic Active Suspension)−Driver−ECU914A〜914Dがメインネットワーク100Aに接続されている。
さらに車両の外界の状態を検出するミリ波レーダ/カメラSen4、およびエアバッグの展開を制御するエアバッグECU915もメインネットワーク100Aに接続されている。
バックアップのネットワーク100Bには、車両の安全な走行に関わる必要最小限のノード、すなわち、操舵角センサSen1,ブレーキペダル位置センサSen2,SBW・VGR−Driver−ECU911,BBW−Driver−ECU913A〜913Dが接続されている。
DBW系統合制御ECU920には、ネットワーク101を介して、エンジン制御ECU921,変速機制御ECU922,モータ制御ECU923,バッテリー制御ECU924が接続している。また、車両運動統合制御ECU910は、ネットワーク102を介して、カーナビ等の情報系の機器を制御するネットワークへの入口となる情報系ゲートウェイ930や、ドアロック,ドアミラー,各種メータ等のボディー系の機器を制御するネットワークへの入口となるボディー系ゲートウェイ940と接続されており、これらのノードとデータのやり取りをする。図示していないが、エアバッグECU915も別の一端で、エアバッグ展開制御に必要な各種センサ、アクチュエータを統合する安全系のネットワークにつながっている。
本実施例において、車両運動統合制御ECU910は、操舵角センサSen1,ブレーキペダル位置センサSen2,アクセルペダル位置センサSen3,図示していない車両状態を検出するセンサ(例えば加速度センサ,ヨーレートセンサ,車輪速センサ)からの信号に基づいて、車両の走行制御のための舵角,制動力,駆動力などを演算し、前輪のSBW・VGR−Driver−ECU11と後輪のSBW−Driver−ECU12に舵角指令を、四輪のBBW−Driver−ECU913A〜913Dに制動力指令を、DBW系統合制御ECU920に駆動力指令を送信する。DBW系統合制御ECU920は、この駆動力指令を受けて、エネルギー効率などを考慮して、エンジン,モータなど各々の駆動力発生源が発生するべき駆動力を演算し、演算した駆動力指令を、ネットワークN2を介してエンジン制御ECU921,モータ制御ECU923などに送信する。車両運動統合制御ECU910は、運転者の要求を検出するセンサの情報だけでなく、車両の外界の状態を検出するレーダまたはカメラSen4の情報を用いることにより、先行車への追従走行、レーンキープ走行、危険回避運転等の制御を行うことができる。
図24は、図23のシステムから、ブレーキ制御システムに関連するノードを抜き出した簡略図である。本実施例のブレーキ制御システムは、運転者のブレーキペダル踏み込み量を測定するブレーキペダル位置センサの信号を処理してネットワーク100に送信するブレーキペダルセンサ2,4輪のブレーキモータを制御するBBW−Driver−ECU913A〜913D、およびブレーキペダルセンサ2の送信データや、図示していないが、車両状態を検出するセンサ(例えば加速度センサ、ヨーレートセンサ、車輪速センサなど)からの信号を用いて4輪のブレーキ力指令値を演算し、これをネットワーク100を介して4輪のBBW−Driver−ECU913A〜913Dに送信する車両運動統合制御ECU910から構成される。
ただし、本実施例で、ブレーキペダルECU2は、一つの故障でも正常動作を継続することができるように、すなわちフェールオペレーショナルに構成されているものとする。
以下、このような、制御システムにおいて本発明のような診断方法を実現する場合の実施例について説明する。実際の制御システムに適用する場合には、各ノード間で送受信されるデータには、状態判定のための情報CSn,状態判定結果S1〜Snとは別に、例えば車両運動統合制御ECU910からBBW−Driver−ECU913A〜913Dに送られるブレーキ力指令値のような制御データDが含まれる。以下、上記のようなシステムを構築する場合の各ノードの構成について、図25〜図28を用いて説明する。なお図25〜図27はそれぞれ図3,図5,図6と対応しており、特に言及しない構成要件については先に説明した実施例と同様である。
各ノードの基本構成を図25に示す。ノード1を例に挙げて説明しているが、本構成はネットワーク内の全てのノードに共通である。本実施例では、ノード1は、図3で説明した構成に加えて、他ノードから受信した制御データを格納する受信データ格納手段14、制御ロジック実行手段で演算されて他ノードに送信される制御データを格納する送信データ格納手段15を備えている。
図25においては、ノード1はネットワークアクセス手段16により、例えばノード2が送信したデータを受信している。ノード2の送信データには、ノード2による状態判定結果S2に加えて、ノード2の制御ロジック実行手段27が生成した車両制御に必要な制御データD2が付加されている。受信処理手段1202は、このデータを二つに分離して、他ノード状態判定手段1101にこれらを入力する。他ノード状態判定手段1101は、図3で説明したように、S2のデータの合理性をチェックすることにより、ノード2の状態を判定し、判定結果E11を状態判定結果格納手段1201内の自ノードによる状態判定結果格納用バッファ141に格納する。このデータに異常がない場合は、制御データD2は受信データ格納手段14に、ノード2による状態判定結果S2(自己診断結果+ノード1、3〜nの判定結果)はノード2による状態判定結果格納用バッファ142に保存される。なお、他ノード状態判定手段1101は、ノード2による状態判定結果S2だけでなく、制御データD2のデータの合理性をチェックしてノード2の状態を判定する構成としてもよい。詳細は後述するが(図26)、このようにすることで、データリンク層に留まらず、アプリケーション層での論理的なデータエラーまで検出することが可能となる。他ノード状態判定手段1101は、同様に、ノード3からノードnの状態判定を行い、各々の判定結果E1nを自ノードによる状態判定結果格納用バッファ141に格納し、それらのノードによる状態判定結果を所定のバッファ143(図示せず)〜14nに保存する。このとき、ノード3〜nの状態判定に異常が無ければ、ノード3〜nからの制御データD3〜Dnをそれぞれ受信データ格納手段14に格納する。なお障害ノード特定手段13,自ノード状態判定手段1102の処理は、図3で説明した実施例と同様である。
制御ロジック実行手段17は、受信データ格納手段14の制御データ、障害ノード特定手段13からの情報、自己診断結果E12、状態判定結果格納手段1201に格納されたノード状態判定結果等に基づき車両制御演算を行い、他ノードに送信する制御データD1を送信データ格納手段15に格納する。送信処理手段1203は、制御ロジック実行手段17が生成した制御データD1と自ノードによる状態判定結果S1を一つの通信データとして送信する。
図26および図27を用いて、他ノード状態判定の実施例について説明する。特に言及しない構成は図5で説明したものと同様である。ノード障害検出符号付加手段18は、制御データD1および自ノードによる状態判定結果S1それぞれに、これらのデータを受信する他ノードにおいてノード1の障害を検出するための符号CD1,CS1を付加する。
送信処理手段1203は、制御データD1および自ノードによる状態判定結果S1を一つの通信データにまとめてヘッダ部を付加し、さらにネットワーク障害検出符号付加手段1901により、この通信データが他ノードに配信される途中、ネットワーク100上で何らかの障害が発生したかどうかを検出するためのネットワーク障害検出符号CP1を付加する。
例えばノード2からの通信データを受信する場合、受信処理手段1202内のネットワーク障害判定手段1902は、ノード2のネットワーク障害検出符号付加手段2901が付加したネットワーク障害検出符号CP2とCP2以外のデータ部を用いて、通信データが配信されるときにネットワーク100上でビット反転などによるデータ変化が発生していないかを判定する。他ノード状態判定手段1101は、ノード2のノード障害検出符号付加手段28が付加した符号CD2,CS2およびデータD2,S2を用いてノード2の障害発生有無を判定し、この判定結果E11およびネットワーク障害判定手段1902からの判定結果E13を、自ノードによる状態判定結果バッファ141のノード2状態の領域に格納する。ネットワーク障害判定手段1902が自ノードによる状態判定結果バッファ141に直接アクセスして結果を格納してもよい。
ノード障害検出符号付加手段、他ノード状態判定手段、送受信処理手段の詳細を図27に示す。特に言及しない構成は図6と同様である。図27では、ノード2が障害検出符号を付加したデータを送信し、これをノード1が受信し、障害を判定する実施例を示している。ノード障害検出符号付加手段28は、制御データD2に対する通番付加部281,サム値付加部282、およびノード2による状態判定結果S2に対する通番付加部283,サム値付加部284を備える。通番付加部281,283は、データを送信するたびにデータに付加した通番をインクリメントする。サム値付加部282,284は、さらに、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値をサム値として付加する。送信処理手段2203が備えるパッキング・フレーム処理部2903′は、障害検出符号を付加したD2およびS2をパッキング処理して一つの通信データにまとめ、ヘッダ付加等の通信プロトコル処理を行う。その後、ネットワーク100上で通信データがビット反転などにより破壊されていないかを検出するために、公知のCRC(巡回冗長検査)符号を付加する。
ノード1はノード2からデータを受信後、ノード2での障害検出符号付加順番とは逆の順番で障害検出を行う。ネットワーク障害判定手段1902では、フレーム未受信判定部19022およびCRC異常判定部19021により、データ未受信やデータ破壊などのデータリンク層における障害を検出する。図示していないが、同期エラー,フォーマットエラーなど通信プロトコルレベルの障害も本ネットワーク障害判定手段1902で行う。障害が検出された場合は、判定結果E13を他ノード状態判定手段1101のネットワーク障害判定結果受信部11011に送信する。
一方、他ノード状態判定手段1101は、受信処理手段1202のアンパッキング・フレーム処理部1904′で分離されたデータD2およびS2それぞれに対し、D2については、サム値異常判定部11012,通番異常判定部11013、およびデータ差分異常判定部11014により、制御データD2自体の合理性をチェックし、S2については、サム値異常判定部11015,通番異常判定部11016によりチェックし、ノード2の状態を判定する。サム値異常判定部11012,11015は、通番領域およびデータ領域をバイト単位で加算し総和を求め、これをビット反転した値が、送信側のサム値付加部でデータに付加したサム値と一致するか否かを判定する。また、通番異常判定部11013,11016は、今回の受信データに付加されている通番が前回の受信データの通番からインクリメントされているか否かを判定する。
データ差分異常判定部11014は、今回と前回の受信データの変化分が、制御ロジック実行手段17が設定するある閾値以上になっていないかを判定する。
以上のいずれの判定部においても異常が検出されなかった場合に、D2とS2はそれぞれ受信データ格納手段14,状態判定結果格納手段1201の所定領域に格納される。異常が検出された場合は、当該異常を検出した判定部の上位の異常判定は行わない。また、この場合は、受信データ格納手段14および状態判定結果格納手段1201に対するデータ更新は行わず、その旨を制御ロジック実行手段17に通知する。
このように構成することで、本発明の診断処理を実行しながら、車両制御に必要な制御データを送受信することが可能となる。また、図5,図6を用いて説明した第一の実施例と同様の効果が得られるとともに、データ差分手段11014により制御データD自体の合理性がチェックされるので、アプリケーション層での異常診断をすることが可能となる。
なお、ネットワーク100,100Aの通信サイクル(周期)は、制御システムの制御周期(例えば、ブレーキ制御のフィードバック制御の制御周期)と少なくとも同じか、若しくはそれよりも短く設定される。従って、制御周期の方が通信サイクルよりも長い場合には、ある通信サイクルiにおける制御データDx(i)が、その次の通信サイクルi+1までに更新されていない場合がある。例えば、制御周期が通信サイクルの10倍である場合は、制御データDxは通信サイクル10回に一度しか更新されないことになる。
このような場合の制御データxの送信方法として、第一に、毎回の通信サイクルにおいて制御データDxが更新されているか否かを問わず、一律に全てのサイクルで制御データDxを付加して送信する方法がある。例えば、制御周期が通信サイクルの10倍である場合は、通信サイクル0〜9に付加される制御データDxは途中で障害が起きない限り同一であり、通信サイクル10で始めて制御データが更新されることになる。この方法では、各ノードの送信処理において、制御データの更新の有無を考慮する必要がないので、各ノードの送信処理が容易になる。このような特徴は、例えばブレーキ制御,ステア制御のような複数の制御システムの制御周期が異なっているような場合には、複数の制御周期の存在を考慮せずに送信処理を行うことができるので、特に有効である。
制御周期の方が通信サイクルよりも長い場合における制御データxの送信方法の第二の方法として、制御データDxが更新された通信サイクルのみ制御データDxを付加して送信し、制御データが更新されていない通信サイクルでは状態判定結果Sxのみを送信する構成が考えられる。この方法によれば、通信するデータ量を削減することができるので、第一の構成に比べてネットワーク100、100Aの通信容量を低く抑え、廉価なシステムを実現することができる。
以上の実施例では、図28(a)に示すように(図28において二重線で囲ったデータは送信データであることを示す)、制御データDxと状態判定結果Sxを一体として(同一スロットで)送受信することを前提に説明してきたが、図28(b)のように、これらのデータを別々のスロットで送受信してもよい。
図28(b)では、通信サイクルの前半で制御データDxの送受信、後半で状態判定結果Sxの送受信を行っている。このようにすることにより、(a)では通信サイクル期間全体にわたって全ノードの送信データを受信する必要があるのに対して、(b)では通信サイクル前半の制御データ送受信フェーズにおいては、自ノードで実行する制御に必要なデータのみを受信すればよい。この場合には、図26に示す構成において、状態判定結果Sxの送受信処理と制御データDxの送受信処理とを別々に行うこととなる。
続いて、図24に示すブレーキ制御システムに本発明を適用した場合の実施例を図29を用いて説明する。
右前輪(FR)ブレーキモータ制御ECU3の制御アプリケーション1400におけるFRブレーキモータ制御処理の実施例を図29に示す。FRブレーキモータ制御処理は、まず処理Step11で障害ノード監視ミドルウェア1500から自ECUの制御に関連する他ECUの状態情報を取得する。その後、処理Step12で自己診断により自ECUに障害が発生しているか否かを判定し、障害が発生している場合には、自ECUのリセット処理を行う。ECUがセンサ、アクチュエータを制御している場合は、自己診断だけでなく、センサ、アクチュエータの診断も行い、それらに異常がある場合には電源供給を停止するなどの処理を行う。
自ECUが正常な場合は、処理Step13で、処理Step11で取得した他ECUの状態情報からブレーキ制御ECU1の障害有無を判定する。ブレーキ制御ECU1が正常な場合は、処理Step14Aにおいて、通常制御である、ブレーキ制御ECUから受信したブレーキ力指令値に基づいたモータ制御を行う。ブレーキ制御ECU1に障害がある場合は、次に処理Step15でブレーキモータ制御ECUのいずれかに障害があるかどうかを判定する。いずれにも障害がない場合は、処理Step17Cに進み、ブレーキペダルECU2から受信したブレーキペダル位置に基づき、4輪ブレーキ制御時のブレーキ力指令値を演算する。ブレーキモータ制御ECUのいずれかに障害がある場合は、処理Step16で障害箇所を特定する。障害箇所が左前輪または右後輪のブレーキモータ制御ECUの場合は、処理Step17Bにより、ブレーキペダルECU2から受信したブレーキペダル位置に基づき、右前輪と左後輪を使った対角2輪ブレーキ制御時のブレーキ力指令値を演算する。障害箇所が左後輪のブレーキモータ制御ECUの場合は、処理Step17Aにより、ブレーキペダルECU2から受信したブレーキペダル位置に基づき、右前輪と左前輪を使った前輪2輪ブレーキ制御時のブレーキ力指令値を演算する。処理Step17A,Step17B,Step17Cによりブレーキ力指令値を自ECUで演算した後は、処理S14Bに進み、この指令値に基づいてモータ制御を行う。
このように、本実施例によれば、制御アプリケーションは障害ノード監視ミドルウェアの提供するAPIにより障害ECUを正確に特定することができるため、障害箇所に応じて制御を切り替えることができる。
以下、本発明の他の実施例について説明する。
上述の第一の実施例においては、同一ネットワークの全ノードからの状態判定結果を受信し、全ノードを障害監視の対象として障害ノードの特定を行っている。しかしながら、ノード数が増大するにつれて各ノードにおける受信処理や障害ノード特定アルゴリズム実行部131の演算量が増大することが予想される。従って、これらの処理をソフトウェアで行う場合はCPU処理負荷の増加につながる。
この課題を解決するために、本実施例では、ネットワーク内のノードをいくつかの相互監視グループに分け、そのグループに属するノード間で相互監視をするように構成している。このようにすることで各ノードの演算量を低減できる。以下、本実施例の詳細について説明する。
図30に示すように、本実施例では同一のネットワーク100に接続されるノードを4ノードずつグルーピングし、グループA,グループB・・・という相互監視グループを設ける。各グループではグループ内通信により、そのグループ内のノード間で、第一の実施例と同様のノード状態判定結果の交換を行い、グループ内の障害ノードを特定する。グループ間通信により、グループ内の相互監視で得られた障害ノード特定結果を他のグループに通知する。グループ内通信,グループ間通信ともに、ノード状態に関する情報だけでなく、同時に制御データの送受信も行っている。
図31は、全ノード数が8のシステムで4ノードずつグルーピングし、グループA,グループBという二つの相互監視グループを設けた場合の1通信サイクルにおける各ノード間のデータ送受信の実施形態について示したものである。グループAに属するノードはノードA1〜A4,グループBに属するノードはノードB1〜B4である。図中の黒丸は、各ノードが送信したフレームをどのノードが受信するかを示している。また、図30と同様に、点線はグループ内通信、実線はグループ間通信を表す。
通信スロット1から6では、前通信サイクルのグループ内相互監視で得られたグループ内ノード状態(障害の有無)を、グループA,グループB間で相互に交換している。このフェーズで交換するフレームをノードA1の送信フレームA1_1を例にとって図32に示す。自グループ内ノードの状態管理を自ノードの制御ロジック実行手段に行わせないようにしているのと同様に、これを他グループ内ノードにも行わせないようにするために、フレームA1_1は、図10に記載の制御ロジック実行手段17に通知するノード障害フラグ格納部135の情報を送信するためのノード障害フラグフィールドResultA1を備える。ノード障害フラグフィールドResultA1はグループAに属する全ノードの障害要因ごとの障害有無を表す。
このフェーズにおいて、図31では、グループA,グループBともに3ノードが同一データを送信しているが、これは、1つのノードに障害が発生し、フレームの送信ができない場合や、送信データに誤りが含まれる場合に、他の正常な2つのノードからの情報を使用するためである。また、図31では、全てのノードが他グループのノード状態データを受信しているが、自ノードで実行する制御ロジックに他グループのノード状態が影響しない場合は、これを受信する必要はない。
続く通信スロット7から10では、グループAのノードが、グループAに属するノードに関するノード状態結果、および必要な場合は制御データを順番に送信する。また、これらの送信フレームをモニタすることでノード状態の判定を行う。スロット7でノードA1が送信するフレームA1_2は、図33に示すように、グループAのノードのみについてのノード状態判定結果SA1,障害通知同期フラグフィールドSyncA1、および制御データDA1から構成される。ノード状態判定結果および障害通知同期フラグフィールドの詳細な構成や生成方法については第一の実施例に記載した通りである。スロット7および10では、それぞれノードB3がノードA1の、ノードB2がノードA4の送信フレームを受信しているが、この時ノードB3およびB2は、受信フレーム中のグループAのノード状態判定結果は使わずに、制御データのみを抽出して使用する。
通信スロット11から14では、同様にグループBのノード同士で、ノード状態結果の送受信、およびノード状態判定を行う。スロット12および14では、それぞれノードA1がノードB2の、ノードA3がノードB4の制御データを受信する。
グループ内でのノード状態判定結果の送受信終了後に、この情報に基づいてグループごとにそのグループに属するノードについての障害ノード特定処理を行う。本実施例では、監視対象ノード数が3になり、これらのノードの障害有無を4つのノードによるノード状態判定結果の多数決により特定すれば良くなる。従って、同一ネットワークの全てのノードによるノード状態判定結果を用いて、全てのノードの状態監視を行う第一の実施例に比べて、各ノードの演算処理量を大幅に低減することができる。なお、各ノードでの制御モードの切り替えは、自グループのノードの障害カウンタ値がリミット値に達したとき、または他グループのノードから、そのグループ内のノードに障害が発生したことを示すノード障害フラグフィールドを受信したときに、通信サイクル前半においてグループ間で前通信サイクルのグループ内ノード状態を交換し終わった時点、すなわち図31では通信スロット6の終了時点で行う。
図34は、他グループのノードの障害通知同期フラグフィールドSyncを受信することにより、図31に示した通信サイクル前半のグループ間でのグループ内ノード状態の交換をなくした実施例である。グループBのノードは、通信スロット1から3において、ノードA1からノードA3の送信フレームからSyncAx(x=1,2,3)を抽出し、同様に、グループAのノードはノードB1からノードB3の送信フレームからSyncBxを抽出する。前述したように、障害カウンタがリミット値に達する通信サイクルで、障害通知同期フラグフィールドSyncの該当するノードの障害要因のビットが1にセットされるため、これを用いて自グループ内ノードの状態を他グループのノードに通知することができる。ただし、当該通信サイクルにおいて障害が回復し、実際には障害カウンタがリミット値に到達しない、すなわち制御モードの切り替えは行われない可能性があるため、障害カウンタは復帰型を選択する必要がある。すなわち、この場合、例えばグループAのノードは、グループBのノードが送信する障害通知同期フラグフィールドSyncBxのあるビットが2通信サイクル連続してセットされたときに初めてグループBのそのビットに該当するノードの障害カウンタがリミット値に達したと判断することができる。本実施例では、図31の実施例に比べて、通信スロットを6つ削減することができ、ノード状態通知のためのグループ間通信の通信帯域を低減することが可能となる。
以上では、ネットワーク上の全てのノードが、ネットワーク上全ての、もしくはグループ内の全ての他ノードを対象に、自ノードによる状態判定結果から障害ノードを特定する処理(ID)を行っている。
このような非常に信頼性の高い手法に加えて、CPUの処理負荷をさらに減らすために、IDの実行を、ネットワーク上の他ノードと、もしくはグループ内の他ノードと分担することもできる。すなわち、nノードを有するグループ内(ネットワーク上の全ノードを1グループとする場合も含む)にて、1つのノードはm(n>m>1)ノードについてのみ自分でIDを実行して他ノードに送信し、それ例外のノードについては他ノードによるIDの結果を受信する。以下この手法を、「判定結果放送方式」と呼ぶ。なお、m=nとすると前記実施例と同じ方式になる。
図35は、判定結果放送方式によるノード状態(障害ノード)監視機能を実現するフローチャートを示している。本フローチャートの処理は、各ノードで実行される。
ステップS100で処理を開始し、ステップS110では自ノードによる状態判定を行う。これは第一実施例のMONと処理内容は同じである。ステップS120では、ステップS110の判定結果をグループ内の他ノードに送信(放送)する。また、他ノードによるノード状態判定結果を受信する。ステップS120の処理は前記実施例のEXDと処理内容は同じである。
ステップS140では、自ノードの担当するグループ内のmノードについてのみ、ステップS120で生成した自ノードおよび他ノードによるノード状態判定(MON)結果から、ノードごと・障害種類ごとに障害有無を確定させる状態判定を行う。このステップS140の処理をID1とする。これは前記実施例のIDと、判定対象がmノードに限定される点が異なる。
ステップS150では、ステップS140でのmノードについての状態判定結果を、他ノードに対して送信し、また他ノードから受信して交換する。ステップS150の処理をEXD2とする。ステップS160では、ステップS150での自他ノードによる状態判定(ID1)結果から、ノードごと・障害種類ごとに障害有無を確定させる。このステップS160の処理をID2とする。m=1の場合には特に処理を行う必要はないが、m>2のときには、複数のID1結果を多数決や優先順位付けなどにより、1つにする必要がある。
ステップS170では、ID1で担当する判定対象ノードを変更する。ステップS180では前記実施例と同様に、ノード障害情報を通知する。ステップS190で処理を終了する。
ステップS100〜S190を繰り返すことで、ノード状態監視を継続的に行う。状態判定(MON)結果のデータ受信対象ノード数が担当のmだけで良い(担当以外のノードについての自ノードによる状態判定結果は、最初から受信しないか、一旦受信してその後の処理を行わず破棄してよい)こと、また状態判定(ID1)の対象とするノード数がmだけで良いことから、前記実施例と比較してCPUや通信コントローラの処理負荷は軽減する。これにより、ECUの製造コストを安価にすることや、CPUの処理能力を他処理に割くことが可能となる。
ID1の判定対象とするmノードは、グループ内の全てのノードが判定対象となるように各ノードに担当を割り振る。またステップS170では、ID1の対象ノードを毎回もしくは定期的に変更することにより、あるノードに障害が発生し、ステップS100〜S190の一部または全部を行えない状態になっても、特定ノードについてのID1が延々と行われずその結果の送信(EXD2)も行われないという事態が継続するのを防ぐようにしている。ステップS170は必須ではないが、ノード状態監視機能の信頼性を保つ上で重要である。なお、前記実施例における障害ノード特定アルゴリズムは、ID1+EXD2+ID2に対応している。
図36および図37は、判定結果放送方式における状態判定結果格納手段および障害ノード特定手段を示している。説明を簡素化するため、ノード1を例に説明する。ここではm=1としている。またこの例では、ノード1によるID1の対象はノード2となっている。
図36では、状態判定結果(MON)の格納される領域が、ノード2を対象とした状態判定結果分のバッファである担当ノードの状態判定結果格納部1420のみであり、図4よりも限定されている。ノード2以外を対象とした状態判定結果は受信されないか、受信しても破棄される。
図37では、担当ノード状態判定部131aが、担当ノードの状態判定結果格納部1420のデータをもとに、ノード2についての状態判定(ID1)を行う。ID1の結果は、状態判定結果調整部131bに送られ、また他ノードに送信される(EXD2)。
状態判定結果調整部131bは、自ノードの状態判定(ID1)結果、および他ノード(ノード2〜ノードn)から受信(EXD2)した状態判定(ID1)結果から、障害ノード特定(ID2)を行う。ここで、他ノードが状態判定(ID1)を担当するノードは、ノード1およびノード3〜ノードnである。状態判定結果調整部131bは、状態判定ノード数mが2以上のときには、状態判定(ID1)結果を多数決などにより1つに纏める。この例のようにm=1のときには、ID1の結果をそのままID2の結果とする。また自ノード(ノード1)の状態については、他ノードによる状態判定(ID1)結果より自ノード状態判定結果を優先させるなどをして、判定結果を1つに纏める。
状態判定結果調整部131bは、ID2結果で障害ありと確定されたノード・障害種類について、障害カウンタ132の値をインクリメントする。
本実施例(図36)では、第一の実施例(図4)と比較して必要なバッファ容量が低減することで、ECUの製造コストを安価にすることが可能となる。
図38は、判定結果放送方式における通信スケジュールの一例を示している。各ノードはある通信サイクルiにて、各ノードはノード状態判定(MON)を行う。次の通信サイクルi+1にて、他ノードと自ノードによる状態判定結果の送受信(EXD)を行う。また、担当するmノードについての状態判定(ID1)を行う。次の通信サイクルi+2にて、担当するノードの状態判定結果を他ノードと送受信する(EXD2)。また、障害ノード特定(ID2)を行う。以下、この処理を繰り返す。
このように、判定結果放送方式では障害ノード特定を1回行うのに3つの通信サイクルが必要となり、前記実施例の2サイクルより1サイクル増える。しかしながらCPUの処理負荷は減るので、前記実施例よりも1サイクルの時間長を短くすることや、1サイクルに処理するステップ数を図38より増やす(例えばi+1サイクル目で、EXD・ID1・EXD2・ID2を一通り行う)ことも可能であり、前記実施例より必ずしも障害ノード特定までに時間が掛かるわけではない。
ステップS100〜S190を繰り返す際、各処理を並列に行ってもよい。図39では、通信サイクルiでMONを行い、次の通信サイクルi+1では、通信サイクルiのMONについてEXD・ID1を行う一方、新たにMONを同じサイクル内で処理している。通信サイクルi+2では、通信サイクルi+1のID1についてEXD2・ID2を行う一方、通信サイクルi+1のMONについてEXD・ID1を処理し、さらに新たなMONを処理している。以下この処理を繰り返すことで、毎通信サイクルにて障害ノード特定を行うことが可能となる。
図40は、各ノードのID1における、担当ノードの変更スケジュールの一例を示している。つまりこのスケジュールは、各通信サイクルにて、各ノードがID1でどのノードを対象に状態判定を行い、次サイクルでその状態判定結果を他ノードに送信するかを表しており、ステップS170の処理内容にあたるものである。
スケジュール2000はm=1とした例である。ノード1の状態判定担当ノードは、通信サイクルiにてノード2,通信サイクルi+1にてノード3と変わり、通信サイクルi+n−1にてノードn、通信サイクルi+nにてノード2と一周し、以下繰り返す。ノード2〜nの状態判定担当ノードは、ある通信サイクルにて全てのノードが状態判定の対象となるように振り分けられており、ノード2の対象は、通信サイクルiにてノード3,通信サイクルi+1にてノード4、通信サイクルi+n−1にてノード1と変わり、ノードnの対象は、通信サイクルiにてノード1,通信サイクルi+1にてノード2、通信サイクルi+n−1にてノードn−1と変わる。これにより、1つのノードがID1で対象とするノード数が1つだけであっても、毎通信サイクルに全てのノードについて障害ノード特定を行うことが可能となる。
スケジュール2010はm=2とした例である。m=2として全てのノードが必ず2つのノードにより状態判定(ID1)の対象となるスケジュールを組めば、グループ内の1ノードが故障によりステップS100〜S190の一部もしくは全部を行えない状態になっても、状態判定の対象とされないノードが出ることがない。スケジュール2010はこのように組まれたスケジュールであり、ノード1のID1対象ノードは、通信サイクルiにてノード2・ノード3、通信サイクルi+1にてノード3・ノード4と変わり、通信サイクルi+n−1にてノードn・ノード2、通信サイクルi+nにてノード2・ノード3と一周し、以下繰り返す。ノード2の対象は、通信サイクルiにてノード3・ノード4、通信サイクルi+1にてノード4・ノード5、通信サイクルi+n−1にてノード1・ノード3と変わり、ノードnの対象は、通信サイクルiにてノード1・ノード2、通信サイクルi+1にてノード2・ノード3、通信サイクルi+n−1にてノードn−1・ノード1と変わる。
スケジュール2000,2010は、メモリなどの記憶装置にテーブルとして保持しておいてもよいし、このように規則性のあるスケジュールは簡単な数式で計算することも可能である。数式を用いる場合、例えばスケジュール2000のノード1であれば、通信サイクルをn−1で除した余りに1を加えれば、担当ノード番号となる。
図41は、判定結果放送方式を用いたノード状態監視状況の一例を示してあり、図15,図16と同様のものである。図41では、通信サイクルi+1のスロット1の時間帯において、ノード3にCPUの障害が発生し、ソフトウェアの動作に異常が生じたことを想定している。ノード3は通信サイクルiにおける状態判定(MON)結果をスロット3で送信することになっているが、ノード障害検出符号付加手段38は、CPU障害のため、通番をインクリメントすることができない。したがって、他ノードはノード3からの状態判定結果受信(EXD。ここでは通信データに通信サイクルiのID1結果も含まれるため、EXD2を兼ねる)時に、通番がインクリメントされていないことを検出し、ノード3に通番異常が発生したと判定する(通信サイクルi+1におけるMON)。しかしこの時点では、ノード3からのデータに障害を検出しても、自ノード単独の判定であるため、障害がノード3によるものか、自ノードの判定誤りによるものかを決定することはできない。そこで次の通信サイクルi+2にて、ノード1・2・4は、自ノードによる状態判定(MON)の結果0080(ノード3の通番異常を表す)を、通信サイクルi+2における状態判定(ID1)結果と共に送信する(EXD)。各ノードは、通信サイクルi+2の後半で、ノード2は、ノード1・2・4による状態判定結果を用いて、ノード3を対象に状態判定(ID1)を行い、障害種類ごとの有無を判定し、ノード3の通番異常を確定する。さらに通信サイクルi+3にて、ノード2はノード3の状態判定(ID1)結果を、通信サイクルi+2における状態判定(MON)結果と共に送信する(EXD2)。これにより、ノード1・2・4はノード3の通番異常確定を知り、障害カウンタEx_3(x=1,2,4)をカウントアップし、当該障害カウンタの値がリミット値に達するため、ノード障害フラグの該当箇所がセットされる。このようにして、各ノードは障害発生箇所と障害種類を正確に知ることができる。
図42は、各ノードのID1における対象ノード変更方法を工夫した例について、フローを示している。この例では、障害が発生しているノードが本来行う状態判定(ID1)を、その障害を検知した他のノードが代行することで、ノード状態監視機能に支障が出ないようにしている。
ネットワーク上の各ノードは、状態判定(ID1)担当ノードのスケジュールと同様に、状態判定(ID1)代行の対象とするノードのスケジュールを持ち、そのスケジュールで代行対象とされているノードに障害発生を検知すると、この障害ノードが状態判定を担当しているノードについて、代りに状態判定(ID1)を行うものとする。
以下、図42のフローを説明する。ステップS200で処理を開始し、ステップS210では状態判定を担当するmノードのローテーションを行う。このローテーションは、スケジュール2000やスケジュール2010のような担当ノード変更を意味する。
ステップS220〜S250は、状態判定代行対象ノードそれぞれについて行う。1つの代行対象ノードをノードaとする。
ステップS230ではノードaに障害が発生しているかを確認する。障害検知は、自ノードによる状態判定(MON)の結果に基づくものである。障害があればステップS240へ、なければステップS250へ進む。
ステップS240では、状態判定代行対象ノードの1つを、ノードaが状態判定(ID1)を担当している1ノードに置き換える。もしくは、担当ノードとしてノードaの担当ノードの1つを追加する。ステップS250では、全ての状態判定代行ノードについて処理を終えていればステップS290へ進んで処理を終了し、そうでなければステップS220へ戻る。
上記では、状態判定を代行する機会を、MONにて障害を検知したときとしたが、自ノードによるID2もしくは他ノードによるID1のEXD2での受信により、障害を検知してから再び正常と判断されるまで、としてもよい。
図43は、実際のネットワーク上のノードへの、図42のフローの適用例である。タイムチャート2020は、ネットワーク上の各ノードが各通信サイクルにて状態判定(ID1)を担当するノードを、スケジュール2030は、各ノードが各通信サイクルにて状態判定(ID1)代行の対象とするノードを表している。
タイムチャート2020では、ある通信サイクルiにて、ノード1はノード2について、ノード2はノード3について、ノード3はノード4について、ノード4はノード1について状態判定(ID1)を行う。次の通信サイクルi+1では、状態判定担当ノードはローテーションし、ノード1はノード3について、ノード2はノード4について、ノード3はノード1について、ノード4はノード2について状態判定(ID1)を行う。しかし、この通信サイクルi+1の始めに行われるMONにて、ノード2・3・4はノード1の障害(CRC異常など)を検知する。すると、スケジュール2030でノード1を状態判定代行の対象としているノード4が、本来ノード1が状態判定を担当しているノード3についても、状態判定(ID1)を行う。通信サイクルi+2でも同様に、ノード2・3・4はノード1の障害を検知し、スケジュール2030でノード1を状態判定代行の対象としているノード3が、本来ノード1が状態判定を担当しているノード4についても、状態判定(ID1)を行う。
ここで各ノードは、状態判定代行対象ノードの、状態判定(ID1)担当スケジュールを持つことが必要である。スケジュール2030は、メモリなどの記憶装置にテーブルとして保持しておいてもよいし、数式で計算することも可能である。
このようにして、ID1の対象とならないノードが出現するのを防ぎながら、ノード状態の相互監視を行うことができる。
以下では、本発明のノード状態監視を持つソフトウェアを設計するツールに関して説明する。ECU上で動作し、上記の処理を行うソフトウェアを製作する場合に、一般的には設計ツールが用いられる。この設計ツールは、汎用コンピュータなどで動作するソフトウェアであり、ユーザは設計ツールを用いて、ネットワーク構成や通信スケジュール、タスクスケジュールなどの設定を行う。多くの場合にGUI(Graphical User Interface)を持ち、ユーザがキーボードやマウスなどの入力装置をもって、画面上で視覚的に設計を行うことができる。
設計ツールは、ユーザの設定を反映して、ヘッダファイル等を含むソースファイルを出力する。これらのファイルに、他のソースファイル・オブジェクトファイル・ライブラリなどを合わせ、コンパイラ・リンカを通すことで、ECU上で動作する実行プログラムが生成される。なお、本発明のノード状態監視機能の実装形態としては、1つにミドルウェアが考えられる。
ユーザがこのような設計ツール用いて、本発明のノード状態監視機能に関する設定を行うことができ、ECU上で該機能を発するソフトウェアを生成することができれば、ユーザの設計に掛かる労力を軽減しつつ、本発明を実用することができる。以下では、このような設計ツールを実現するための、設計ツールのGUIおよび機能について説明する。
図44は、設計ツールの画面例を示したものである。画面はネットワーク構成設定部2100,ネットワーク構成要素選択領域2150,ネットワーク主設定部2200からなる。ネットワーク構成設定部2100上では、通信線N10AとN10Bが配置され、それら通信線にノード1からノード5がバス型トポロジで接続するように配置されている。すなわち、このネットワークでは通信路がチャネルAとチャネルBとに2重化されている。各ノードはチャネルA・Bごとにノード状態監視を行うため、各ノードは画面上でA部(ノード1のN101Aからノード5のN105A)・B部(ノード1のN101Bからノード5のN105B)に分けられている。このネットワーク構成の設定・編集は、ネットワーク構成要素選択領域2150からノードや通信線などの要素を選択して配置(ドラッグ・アンド・ドロップ)することにより、ユーザが行うものである。このような設定・編集方法は設計ツールでは一般的に採用されており、ここでは詳細に説明しない。
ネットワーク主設定部2200には、ノード状態監視方式を指定するボタン2210,ノード状態監視方式表示2220,ノード状態監視を行うノードのグループ設定を行うボタン2230,ソースファイル等を生成し出力させるボタン2240がある。ボタン2210をユーザがマウス入力等で押下すると、画面上にノード状態監視方式のリスト2250が表示され、ユーザが選択した1方式がノード状態監視方式表示2200となる。監視方式の選択項目としては、「監視なし」・「全ノード相互監視」・「グループ内相互監視」・「判定結果放送」・「詳細指定」を用意する。
「監視なし」が選択されると、ノード状態監視機能を利用しないものとされ、本設計ツールではノード状態監視に関する設定が無効(入力不可)となり、出力されるソースファイル等にもノード状態監視に関する内容は含まれなくなる。
逆に、「全ノード相互監視」〜が「詳細指定」が選択されると、ノード状態監視機能が有効となり、本設計ツールでノード状態監視に関する設定入力が可能となり、出力されるソースファイル等にもノード状態監視に関する内容が含まれるようになる。
「全ノード相互監視」は、ネットワーク構成設定部2100のネットワーク上の各ノードは、他の全ノードについて相互監視する、すなわち自ノードによる状態判定(MON)、自ノードによる状態判定結果の交換(EXD)及びノード状態判定(ID)を行う方式を意味し、出力されるソースファイル等は該方式を反映した内容となる。「グループ内相互監視」は、ネットワーク上のノードをいくつかのグループに分けて、グループ内すべての他ノードについて相互監視を行う方式を意味する。「判定結果放送方式」は、グループ内すべての他ノードについて自ノードによる状態判定(MON)を行うが、ノード状態判定(ID1)はmノードに限定し、判定(ID1)結果を互いに送信して共有する方式を意味している。
「詳細設定」は、ノード状態監視方式をより詳細に指定するモードである。このモードでは、自ノードによる状態判定(MON)を互いに行い結果を共有(EXD)する「ノード状態監視グループ」や、状態判定(ID1)の担当ノード、状態判定(ID1)結果を他ノードへ送信(もしくはブロードキャスト)するか否か、グループ内外の他ノードについてその状態判定(ID1)結果を受信して障害ノード特定(ID2)を行うか否か、といった項目を、ノードごとに細かく指定することができる。
「詳細設定」モードのとき、ソフトウェアの設定によっては、「全ノード相互監視」・「グループ内相互監視」・「判定結果放送」などとノード状態監視機能が同等になる場合がある。例えば、ノード状態監視グループをネットワーク上の全ノード、ノード状態判定(ID1)結果の送信なし(自動的に、ノード状態判定担当ノードと障害ノード特定(ID2)有無の設定は無意味になるため、無効となる)とすれば、「全ノード相互監視」と同じになる。ノード状態監視グループをネットワーク上のnノードに限定して、ノード状態判定(ID1)結果の送信なしとすれば、「グループ内相互監視」と同じになる。すなわち、「詳細設定」モードは、「監視なし」以外の他モードを全て包含している。
ネットワーク主設定部2200のボタン2230をユーザが押下すると、ノード状態監視のグループ設定や監視条件設定を行う画面が表示される。図45はノード状態監視グループをノード主体で設定する画面例、図46はノード状態監視グループをグループ主体で設定する画面、図47はあるノード状態監視グループ(例としてチャンネルAグループ1)の詳細な条件を設定する画面例である。3つの画面はタブにより切り替え可能となっている。
図45にて、ノード状態監視グループ設定画面(ノード主体)2300は、チャネルA設定部2310,チャネルB設定部2350,ボタン2380,ボタン2390からなる。
ユーザがボタン2380を押下すると本画面で入力した内容が設定に反映され、ボタン2390を押すと入力内容は破棄される。
チャネルA設定部2310には、ノード1からノード5の各々について所属するノード状態監視グループを指定する所属ノード状態監視グループ指定部232x(x=1〜5、図では2321を例示)がある。またユーザがボタン2330を押下すると、ノード状態監視グループ数の入力欄が表示され、ノード状態監視グループ数を変更することができる。図ではチャネルAのノード状態監視グループ数は2とされており、所属ノード状態監視グループ指定部で選択できるグループ名は「グループ1」「グループ2」となっている。もしノード状態監視グループ数を少なくすることで、所属ノード状態監視グループ指定部で指定しているグループがなくなってしまった場合には、そのノードの所属ノード状態監視グループは設定なしとなる。
チャネルB設定部2350も、チャネルA設定部2310とほぼ同じである。ただし、ラジオボタン2360をユーザが設定有りにすると、チャネルBに関する入力すなわち所属ノード状態監視グループ指定部232xの内容は無効(入力不可)となり、チャネルAと同じ設定になる。
図46にて、ノード状態監視グループ設定画面(グループ主体)2400は、チャネルA設定部2410,チャネルB設定部2460,ボタン2480,ボタン2490からなる。ボタン2480はボタン2380と、ボタン2490はボタン2390と同等である。
チャネルA設定部2410には、ノード状態監視グループxに所属するノードを指定するノード状態監視グループ所属ノード指定部242x(図では2421を例示)があり、ここにユーザがノード名を入力すれば、入力されたノードは該ノード状態監視グループに所属する。もしくはユーザが、ネットワーク構成設定部2100からノードN101A〜N105Bをノード状態監視グループ所属ノード指定部242xにドラッグ・アンド・ドロップするか、所属ノード指定部242xをクリックして編集対象となるグループを決めて(このときグループ名が反転する)から、ネットワーク構成設定部2100上のノードN101A〜N105Bをクリックすることでも、ノード名を入力するのと同じ結果になるとする。あるノードをノード状態監視グループの所属から外したい場合には、ユーザがそのノード名を削除すればよい。
「全ノード相互監視」モードでは、設計ツールはノード状態監視グループ設定画面(ノード主体)2300およびノード状態監視グループ設定画面(グループ主体)2400を無効(入力不可)としてもよい。
図47にて、ノード状態監視グループ条件設定画面2500は、チャネルA設定部2510,ボタン2580,ボタン2590からなる。ボタン2580はボタン2380と、ボタン2590はボタン2390と同等である。本画面はチャネルAについてのみ表示しているが、チャネルBについても同様に表示される。
チャネルA設定部2510には、ノード1からノード5の各々について、グループ内でノード状態判定(ID1)の対象とするノードを指定する状態判定対象指定部252x(x=1〜5、図では2521を例示)がある。状態判定既対象表示253x(x=1〜5、図では2534を例示)のあるノードは、他のノード状態監視グループで状態判定(ID1)の対象となっているノードである。状態判定(ID1)が行われないノードがあれば、設計ツールがそのことをチェックし、ノード番号と共に注意を促す表示を行っても良い。また、ラジオボタン2540をユーザが設定有りにすると、チャネルAに関する入力すなわち状態判定対象指定部252xの内容は無効(入力不可)となり、同じノード状態監視グループのノードが対象になる。「全ノード相互監視」・「グループ内相互監視」・「判定結果放送」の各モードでは、この設定となる。これら各モードでは、設計ツールはノード状態監視グループ条件設定画面2500を無効(入力不可)としてもよい。
状態監視対象とするノードの指定方法によっては例えば、ノード1について、ノード2〜ノード5で自ノードによる状態判定(MON)および判定結果の共有(EXD)、状態判定(ID1)および判定結果の共有(EXD2)を行う、といった構成も可能である。
状態判定結果送信指定部2550では、状態判定(ID1)結果を他ノードに送信するか否かを指定するもので、有効すなわち「送信あり」とすると、状態判定担当ノード数指定部2560、状態判定担当スケジューリング方式指定部2570が有効になり、入力できるようになる。
状態判定担当ノード数指定部2560では、1ノードが1回の状態判定(ID1)で対象とするノード数、すなわち前記のmを指定する。mがグループ内で一定の場合には、
ネットワーク全ノード数>m>(状態判定(ID1)対象ノード数÷ノード状態監視 グループに所属するノード数)以上の整数
という制約があり、この制約から外れる入力は受け付けない。
状態判定担当スケジューリング方式指定部2570では、ノード状態判定(ID1)担当ノードのスケジューリング方法を指定することができる。図42例では、スケジュール2000やスケジュール2010のように担当ノードを変更する「ローテーション」方式を指定している。このほかに、タイムチャート2020とスケジュール2030で説明した、障害ノードが本来担当している状態判定を代行する方式を指定することもできる。
「詳細設定」モードでは、各ノードでより詳細な設定を行う必要がある。図47は、そのような詳細設定を行う画面である。この画面は、例えばネットワーク構成設定部2100のノード表示N101A〜N105Bをユーザがマウスでクリックすることで表示され、入力できるものとする。
ノード状態監視詳細設定画面2600は、簡単のためにノード1の設定画面としてあり、チャネルA設定部2610,チャネルB設定部2650,ボタン2680,ボタン2690からなる。ボタン2680はボタン2380と、ボタン2690はボタン2390と同等である。
チャネルA設定部2610にて、ノード状態監視グループ指定部2620はノード状態監視グループ設定画面2300の所属ノード状態監視グループ指定部232xと同等である。
障害特定ノード指定部263x(x=1〜5、図では2634を例示)をユーザが設定有りにしたノードについては、そのノードに対するID1結果を受信して障害特定(ID2)を行うよう、設計ツールはソフトウェアを設定する。ただし、図42例では、ユーザが状態判定(ID1)の対象としたノードについては、無条件で障害特定(ID2)を行うとしている。チャネルB設定部2650も、チャネルA設定部2610と内容は同じである。
設計ツールはあるノードのECUソフトウェアに対し、ユーザが状態判定(ID1)を行うとしたノードについて、自ノードによる状態判定(MON)を行い、結果を送信(EXD)するようにソフトウェアの通信関係のパラメタを設定する。ユーザが障害特定(ID2)を行うと設定したノードについては、障害カウンタ・障害フラグをもって管理するか否かをユーザが選択できるようにしてもよい。他ノードによる状態判定(MON)結果を受信するスロットは、同じノード状態監視グループに所属する他ノードが状態判定(MON)結果を送信するスロットである。障害特定(ID2)を行うための状態判定(ID1)結果を受信するスロットは、障害特定ノード指定部253xで指定したノードについてID1を実行するノードがID1結果を送信(EXD2)するスロットであり、設計ツールはそれらスロットにおいてノードが状態判定結果のデータを受信するようにECUソフトウェアを設定する。なお、データ送信のスケジューリング(どのノードがどのスロットで送信するか)は、設計ツールに付属する機能やユーザの手入力でなされる。
上記の例では、各ノードが所属できるノード状態監視グループは1つだけとしたが、複数グループに所属できるようにしてもよい。その場合には、所属ノード状態監視グループを指定する入力部232xを1ノードあたり複数用意する。また、所属ノード状態監視グループにしたがってノード表示N101A〜N105Bを色分け表示し、ユーザの認識性を高めても良い。また、チャンネルAとチャンネルBは独立でノード状態監視を行うようにしているが、どちらかのチャンネルで障害ありと判定されたノードは、障害を検知したチャンネルに関わらず障害ありとして諸プログラムに通知するよう、ソフトウェアの設定を行うユーザ選択肢を用意しても良い。
ECUソフトウェア設計ツールが、上記のようなGUIならびにソフトウェア生成機能を有することで、ユーザの設計労力を軽減し、設計に掛かる時間を短縮しつつ、本発明のノード状態監視機能を有するソフトウェアを製作することが可能となる。
最後に本発明の好適な実施形態を列挙する。
〔1〕通信ネットワークに接続された複数のノードが、当該通信ネットワークを介してデータの伝送を行うことにより車両の機能を実現する車両制御システムにおいて、前記複数のノードは、自らの動作状態及び前記通信ネットワークに接続された他のノードの動作状態を含むノード状態を判定するノード状態判定手段、前記ノード状態判定手段により自らが判定した前記ノード状態判定結果を他ノードに送信し、他のノードが判定したノード状態判定結果を受信する状態判定結果送受信手段、および前記自らが判定したノード状態判定結果および受信した前記他のノードによるノード状態判定結果とを用いて、前記通信ネットワーク内の障害ノードを特定する障害ノード特定手段と、を備えることを特徴とする車両制御システム。
〔2〕上記〔1〕記載の車両制御システムにおいて、前記ノード状態判定手段は、自らの動作状態及び、自らが制御するセンサ若しくはアクチュエータの動作状態の診断を行う自ノード状態判定手段と、前記通信ネットワークに接続された他のノードの状態を判定する他ノード状態判定手段とを備え、前記状態半径結果送受信手段は、前記自ノード状態判定手段による判定結果と前記他ノード状態判定手段による判定結果とをまとめて送信することを特徴とする車両制御システム。
〔3〕上記〔2〕に記載の車両制御システムにおいて、前記状態判定結果送受信手段は、送信データにノード障害を検出するための符号を付加するノード障害検出符号付加手段を備えており、前記他ノード状態判定手段は、他のノードが送信したデータを受信する際に、当該送信ノードが送信データに付加したノード障害検出符号を用いて、当該送信ノードでの障害発生有無を判定することを特徴とする車両制御システム。
〔4〕上記〔3〕に記載の車両制御システムにおいて、前記ノード障害検出符号付加手段は、データを送信するたびにインクリメントされる通し番号を前記送信データに付加する通番付加部を備え、前記他ノード状態判定手段は、他のノードから受信したデータに付加された通し番号が、前回に当該他のノードから受信したデータに付加された通し番号からインクリメントされていない場合は、当該他のノードに障害が発生したと判定することを特徴とする車両制御システム。
〔5〕上記〔3〕に記載の車両制御システムにおいて、前記ノード障害検出符号付加手段は、送信データを加算して求めたサム値を当該送信データに付加するサム値付加部を備え、前記他ノード状態判定手段は、他のノードから受信したデータを加算してサム値を求め、当該サム値が当該データに付加されたサム値と一致しない場合は、当該送信ノードに障害が発生したと判定することを特徴とする車両制御システム。
〔6〕上記2に記載の車両制御システムにおいて、前記他ノード状態判定手段は、他のノードから今回受信したデータと前回受信したデータとの差分を計算し、当該差分が所定の閾値以上である場合は、当該他のノードに障害が発生したと判定することを特徴とする車両制御システム。
〔7〕上記〔3〕または〔6〕に記載の車両制御システムにおいて、前記複数のノードは、前記通信ネットワーク上での通信の異常を検知するネットワーク障害判定手段を備え、前記他ノード状態判定手段は、前記ネットワーク障害判定手段による判定結果を含めて、他ノードの状態判定を行うことを特徴とする車両制御システム。
〔8〕上記〔1〕に記載の車両制御システムにおいて、前記複数のノードは車両制御ロジックを実行する車両制御ロジック実行部を備え、前記障害ノード特定手段は、前記自らによるノード状態判定結果と受信した前記他ノードによるノード状態判定結果とを用いて障害ノードを特定する障害ノード特定アルゴリズム実行部、特定したノードに発生した障害の回数と種類に基づいて、数値をカウントアップする障害カウンタ、および前記障害カウンタの数値が所定のリミット値に到達した場合に、前記車両制御ロジック実行部が当該ノードに障害が発生したことを認識するためのノード障害フラグをセットするノード障害フラグ格納部とを備えることを特徴とする車両制御システム。
〔9〕上記〔8〕に記載の車両制御システムにおいて、前記ノード障害フラグ格納部は、前記車両制御ロジック実行手段により読み出すことが可能であるように構成されており、前記車両制御ロジック実行手段は、前記ノード障害フラグ格納部の情報に基づき、障害ノードおよび障害要因に基づいて車両制御の内容を変更することを特徴とする車両制御システム。
〔10〕上記〔8〕に記載の車両制御システムにおいて、前記車両制御ロジック実行手段は、障害ノードが正常状態に復帰した時に、前記障害カウンタの値を正常復帰前の値からデクリメントするか、または正常復帰前の値を保持するかを選択できることを特徴とする車両制御システム。
〔11〕上記〔9〕に記載の車両制御システムにおいて、前記障害ノード特定アルゴリズム実行部は、同一のノード状態判定結果を得たノード数が、前記車両制御ロジック実行手段が設定する判定閾値以上の場合に、当該ノード状態判定結果を真であるとして、障害ノードを特定することを特徴とする車両制御システム。
〔12〕上記〔1〕に記載の車両制御システムにおいて、予め設定された一連の送受信パターンから成る通信サイクルを繰り返すことにより、各ノードが周期的にデータを送信するようにネットワークを構成し、各ノードにおいて、ある通信サイクル期間に、前記ネットワーク内ノード状態判定手段によるノード状態判定処理を行い、当該通信サイクルの次の通信サイクル期間において、前記ノード状態判定結果送受信手段を用いて前通信サイクルのノード状態判定処理により得られた判定結果をノード間で相互に交換した後、前記障害ノード特定手段により障害ノードの特定を行うことを特徴とする車両制御システム。
〔13〕上記〔1〕から〔12〕のいずれか一項に記載の車両制御システムにおいて、前記車両制御ロジック実行手段を制御アプリケーションソフトウェアとして実装し、前記ノード障害検出符号付加手段、他ノード状態判定手段、および障害ノード特定手段を、前記制御アプリケーションソフトウェアにノード状態情報を提供するアプリケーションプログラムインタフェース(API)を備えるミドルウェアとして実装することを特徴とする車両制御システム。
〔14〕上記〔13〕に記載の車両制御システムにおいて、前記制御アプリケーションソフトウェアは、前記APIを介して取得したノード状態情報に基づき、障害ノードおよび障害要因に応じた車両制御を実行することを特徴とする車両制御システム。
〔15〕上記〔1〕から〔14〕のいずれか一項に記載の車両制御システムにおいて、前記複数のノードは、センサ、アクチュエータ若しくは電子制御装置であることを特徴とする車両制御システム。