(57)【要約】【課題】親機能に従属する子機能が階層構造として形成されたノード及びそのノードを用いた分散システムにおいて、異常検知の処理負荷をより低減する。【解決手段】ソフトウェア機能において親機能−子機能の階層構造を形成する車両制御システムのノードにおいて、親機能自身の異常を検知する親機能異常検知手段（Ｓ１１）と、親機能に直接従属する子機能が存在するか否かを判定する子機能存在判定手段（Ｓ１７）と、その子機能が存在すると判定された場合に、親機能に直接従属する子機能の異常を検知する子機能異常検知手段（Ｓ１９）と、親機能異常検知手段又は子機能異常検知手段の検知結果に基づき、親機能が異常状態であるか否かを設定する異常状態設定手段（Ｓ１４、Ｓ２０、Ｓ２１）とを備える。【選択図】図３
2013239116.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの制御によって実現される機能が各ノードに少なくとも１つ以上搭載され、
当該各ノードに搭載された前記機能のうち、前記ソフトウェアの制御の主となるものを親機能としたとき、
当該親機能に直接従属する機能を子機能とする階層関係が形成された分散システムのノードであって、
前記各ノードのうち、前記親機能として機能することが可能なノードには、
前記親機能自身の異常の有無を検知する親機能異常検知手段と、
前記親機能に前記子機能が存在するか否かを判定する子機能存在判定手段と、
当該子機能存在判定手段により、前記子機能が存在すると判定された場合、前記子機能の異常の有無を検知する子機能異常検知手段と、
前記親機能異常検知手段又は前記子機能異常検知手段の検知結果に基づき、
前記親機能が異常状態であるか否かを設定する異常状態設定手段と、を備える
ことを特徴とするノード。
【請求項２】
前記親機能に直接従属する前記子機能を対応付けて予めリスト化した子機能テーブルをさらに有し、
前記子機能存在判定手段は、前記子機能テーブルに基づき、前記親機能に直接従属する前記子機能が存在するか否かを判定することを特徴とする請求項１に記載のノード。
【請求項３】
前記異常状態設定手段によって前記異常状態と設定された場合、前記親機能の制御を停止させることを特徴とする請求項１又は２に記載のノード。
【請求項４】
前記親機能がアプリケーション機能である場合、前記親機能は前記異常状態設定手段において複数の異常状態が選択可能であることを特徴とする請求項１乃至３の何れか一項に記載のノード。
【請求項５】
前記異常状態設定手段で前記異常状態と設定された場合に前記親機能として機能することが可能なノードは前記異常状態であることを報知する報知手段をさらに備えることを特徴とする請求項１乃至４の何れか一項に記載のノード。
【請求項６】
各ノードがネットワークを介してそれぞれ互いに通信可能に接続される分散システムにおいて、請求項１乃至５の何れか一項に記載の前記親機能として機能することが可能なノードを複数有することを特徴とする分散システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク線により接続された複数のノードが協調動作を行うことのできる分散システムに関し、特に分散システムのノードにおける異常検知処理に関する。
【背景技術】
【０００２】
従来、ネットワーク線により結合された電子制御装置（ノード）が複数接続され、これらのノードが協調動作して、高信頼な制御を行う分散システムが知られている（例えば特許文献１参照）。
【０００３】
この特許文献１の分散システムでは、複数のノードはそれぞれ自己診断機能を有している。例えば自己診断時に１つのノードが異常であると判断すると、その異常ノードをリセットし、再起動を図る。また他の正常ノードはその異常ノードを認識し、バックアップ制御モード（例えばその異常ノードの機能を他の正常ノードが肩代わりする）に遷移する。そして異常であったノードの再起動が完了すると、他の正常ノードは再起動したノードの再参加を許可する判断を行い、許可された場合はバックアップ制御モードから通常制御モード（再起動したノードも含め、全てのノードが同期して各機能を実行する）に遷移する。
【０００４】
このような分散システムにおいては、異常から正常になったと確認されたノードのシステムへの途中参加を許容しつつ、高信頼な制御モード選択を可能にすることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２２０１４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記特許文献１のような分散システムの技術においては、システム全体の設計を容易にするために将来的にはノードに搭載された機能（ソフトウェアの制御によって実現される機能）が、階層構造を形成してより高度化や複雑化すると予想される。
【０００７】
例えば、あるソフトウェアの機能（ここでは親機能と称する）を有する層に対し、その親機能の層の下位層に、親機能に制御される（≒従属する）機能（ここでは子機能と称する）が階層構造として形成されているとする。
【０００８】
また、その子機能の層のさらに下位層に、その子機能に従属する制御機能（すなわち親機能に間接的に制御される可能性のある機能であり、ここでは親機能に対して孫機能と称する）が形成されたとする。
【０００９】
このような互いに関係する制御機能が複数の層に渡って階層構造が形成されるものに先行文献１のような技術を用いる場合、親機能を備えるノードは、自己診断時に親機能がシステム全体として正常に機能するか否かを確認するために、親機能自身が関連する全ての階層の機能（ここでは親機能−子機能−孫機能のこと）の異常を１つ１つ確認する必要がある。
【００１０】
そのため、その親機能を備えるノードは、階層構造が深くなるほど（つまり親機能に関連する制御機能が多くなるほど）その自己診断機能による異常検知処理の負荷が多くかかってしまう。
【００１１】
また、親機能が子機能及び孫機能をそれぞれ複数従属させており、さらに親機能が複数存在する場合は、それらの自己診断の処理負荷が個々に生じる。
【００１２】
さらに分散システム全体における異常確認のためのソフトウェア設計も複雑となってしまう問題がある。
【００１３】
特許文献１の分散システムの技術では、このような階層構造に対する思想は無く、自己診断機能により異常であると判断されたノードが、単にその異常状態を回復するためにバックアップ制御や再起動などのフェールセーフ処理を行っていることが記載されているのみである。従って、特許文献１のような分散システムの技術から将来発生すると考えられる問題に対してさらに改善を図る必要がある。
【００１４】
本発明は上述のような問題に鑑みてなされたものであり、親機能に従属する子機能が階層構造として形成されたノード及びそのノードを用いた分散システムにおいて、異常検知の処理負荷をより低減することのできることを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を解決するため、請求項１のノードは、各ノードに搭載された前記機能のうち、ソフトウェアの制御の主となるものを親機能としたとき、親機能に直接従属する機能を子機能とする階層関係が形成された分散システムで用いられるものであって、親機能として機能するこのノードには、親機能自身の異常の有無を検知する親機能異常検知手段と、親機能に子機能が存在するか否かを判定する子機能存在判定手段と、子機能が存在すると判定された場合、子機能の異常の有無を検知する子機能異常検知手段と、親機能異常検知手段又は子機能異常検知手段の検知結果に基づき、親機能が異常状態であるか否かを設定する異常状態設定手段とを備えることを特徴としている。
【００１６】
この構成によれば、ノードに搭載されたある親機能自身の異常検知の他、その親機能に直接従属する子機能の異常を検知するだけで親機能の異常状態を設定することができる。そのため、親機能に関係する全ての機能の異常を検知して異常状態を設定（＝決定）する処理よりも処理負荷を低減することができる。
【００１７】
また、請求項２のノードは、親機能に直接従属する子機能を対応付けて予めリスト化した子機能テーブルをさらに有し、子機能存在判定手段は、子機能テーブルに基づき、親機能に直接従属する機能が存在するか否かを判定することを特徴としている。
【００１８】
この構成によれば、親機能の直接従属する子機能を簡単に確認することができる他、親機能の変更などで直接関連する子機能が増減しても、子機能テーブルを書き換えるだけで簡単に設計変更することができる。
【００１９】
また、請求項３のノードは、異常状態設定手段によって異常状態と設定された場合、親機能の制御を停止させることを特徴としている。
【００２０】
この構成によれば、動作の保障できない異常状態の親機能を停止することで、フェールセーフ制御を行うことができる。
【００２１】
また、請求項４のノードには、親機能がアプリケーション機能である場合は、親機能は異常状態設定手段において複数の異常状態が選択可能であることを特徴としている。
【００２２】
この構成によれば、子機能の異常検知結果を総合的に判断して最適な異常状態を選択することが可能となる。
【００２３】
また、請求項５のノードには、異常状態設定手段で異常状態と設定された場合にノードが異常状態であることを報知する報知手段をさらに備えることを特徴としている。
【００２４】
この構成によれば、親機能が異常状態と設定された場合に、警告灯や音、若しくは表示などを用いて異常状態であることを警告することができ、ひいては車両のユーザーに異常を知らせることができる。
【００２５】
さらに請求項６の分散システムは、各ノードはネットワーク線を介してそれぞれ互いに通信可能に接続されており、請求項１乃至５の何れか一項に記載の前記親機能として機能することが可能なノードを複数有することを特徴としている。
【００２６】
この構成によれば、親機能が複数存在して機能の階層構造が複雑化しても、ノードにおける親機能の直接従属する子機能の異常を検知するだけで良いため、分散システムの異常検知の設計を簡素にすることができる。
【図面の簡単な説明】
【００２７】
【図１】本発明の実施形態におけるそれぞれの機能の階層関係を示す図である。
【図２】本発明の実施形態における車両制御システム（分散システム）の構成を示す概略構成図である。
【図３】本発明の実施形態における親機能の異常検知処理を示すフローチャートである。
【図４】本発明の実施形態における各親機能の異常検知結果、その直接従属する子機能の異常検知結果、及び各親機能の最終的な異常状態の結果が記録されたテーブルである。
【発明を実施するための形態】
【００２８】
以下、本発明の実施形態について図面を用いて説明する。本発明の実施形態は、機器に分散配置した複数の電子制御装置（以下、ネットワーク線に接続された電子制御装置をノードと称する）がネットワーク線を介してデータを送受信して協調動作を行う分散システムを、自動車の車両制御システムに適用した場合の例である。
【００２９】
図１は、ネットワーク線を介してそれぞれ互いに通信可能に接続された各ノード（図２で構成を説明する）に搭載された機能（ソフトウェアの制御によって実現される機能）において、上位層の機能に下位層の機能が制御される（≒従属する）階層関係が形成されるときの一例を示す図である。
【００３０】
図１において、階層の最上位となる機能は、ＡＣＣ（アダプティブ・クルーズ・コントロール）機能、プリクラッシュセーフティ機能等があり、これらの機能は、車両のユーザーが車両で実行した操作の機能、或いはユーザーが必要とする機能を直接的に制御するアプリケーションの機能である。
【００３１】
またアプリケーションの機能のある階層より下位層にある機能はシステム機能に分類している。このシステム機能は、ユーザーが実施したい機能を直接実現する機能ではないが、各アプリケーション機能の稼動に必要となるものである。図１では、システム機能として、前方車両検知制御（遠距離、近距離）、エンジン制御、ＡＢＳ（アンチロック・ブレーキ・システム）制御、メータ制御等がある。またこれらのシステム機能の下位層の機能もシステム機能として分類しており、例えばこの前方車両検知制御（遠距離）の下位層にはミリ波レーダ制御と前方カメラ制御があり、前方車両検知制御（近距離）の下位層には前方カメラ制御とソナー制御がある。また、エンジン制御の下位層にはエアフロ制御と燃料噴射電子制御があり、ＡＢＳ制御の下位層にはブレーキ油圧制御とロックセンサ制御があり、さらにメータ制御の下位層にはスピードメータ制御と警告灯制御がある。
【００３２】
一方、図１の別の見方として、この階層関係は、あるノードに搭載されたソフトウェアの制御の主となる機能（親機能と称する）を有する層に対し、その親機能の層の下位層に、親機能に制御される（つまり親機能に従属する）ソフトウェアの機能（ここでは子機能と称する）が階層構造として形成される。また、その子機能の層のさらに下位層に、その子機能に制御される（つまり子機能に従属する）ソフトウェアの機能（すなわち親機能に間接的に制御される可能性のある機能であり、ここでは親機能に対して孫機能と称する）が形成されると見ることができる。
【００３３】
この階層関係（親機能−子機能−孫機能）は各ノードの自己診断時に考慮される機能関係である。例えば図１のＡＣＣ制御の機能が搭載されたノードが自己診断を行う際は、ＡＣＣ制御（親機能）−前方車両検知制御（遠距離）（子機能）−ミリ波レーダ制御（孫機能）のような階層関係を定義している。またこの親機能の定義は必ずアプリケーション層の機能であるとは限らない。例えば、前方車両検知制御（遠距離）の機能が搭載されたノードが自己診断を行う際は、前方車両検知制御（遠距離）（親機能）−ミリ波レーダ制御（子機能）の階層関係となるように、自己診断を行うノードに搭載されたソフトウェアの機能を親機能として階層関係（親機能−子機能−孫機能−・・・）を定義している。
【００３４】
また、車両に搭載されるアプリケーション機能はカーナビゲーション制御機能、スマートエントリー制御機能など様々存在するが、本実施形態では、自己診断が特に必要となる快適・安全制御に関係する機能に着目し、一例としてＡＣＣ制御の機能、プリクラッシュセーフティ制御の機能について以下順次説明する。
【００３５】
まずＡＣＣ制御の基本機能を説明する。ＡＣＣ制御は、車両のユーザー（特に運転手）がアクセル（非図示）を踏まなくても、前方車両検知制御（遠距離）の機能により得られる前走車や障害物などの位置（距離）や相対速度の情報に基づき、任意に設定した速度を自動で維持して走行する機能である。この前方車両検知制御（遠距離）は、車両前方の物体を検知するミリ波レーダ制御や車両前方を撮影するカメラ制御の機能により得られる車両前方情報に基づき、前走車や障害物などの位置（距離）や相対速度を検知するよう制御する。ＡＣＣ制御は、もし設定速度よりも遅い前走車などがいた場合はＡＢＳ（アンチロック・ブレーキ・システム）制御によるブレーキ制御を行って減速し、一定の車間距離を保って走行するよう制御する。また、前走車がいなくなるとエンジン制御を行って再加速し、設定車速での走行に戻るよう制御している。
【００３６】
次にプリクラッシュセーフティ制御の基本機能を説明する。プリクラッシュセーフティ制御は、前方車両検知制御（遠距離、近距離）の機能により得られる前走車や壁などの障害物などの位置（距離）や相対速度の情報に基づき、自動車が前走車や障害物などを感知して衝突に備える機能である。この前方車両検知制御（遠距離、近距離）は、車両前方の物体（特に遠方の物体）を検知するミリ波レーダ制御や車両前方を撮影するカメラ制御、車両前方の物体（特に近傍の物体）を検知するソナー制御の機能により得られる車両前方情報に基づき、前走車や障害物などの位置（距離）や相対速度を検知するよう制御する。プリクラッシュセーフティ制御は、もし衝突の危険性がある場合、運転者がブレーキ（非図示）を踏めばブレーキアシスト、踏まなければ自動ブレーキをＡＢＳ制御より掛けるように制御する。
【００３７】
上述のようなＡＣＣ制御についての基本的な構成、動作原理、及び制御方法については例えば特開２００１−３４７８５１号公報などに記載されているような周知の技術を用いて実現可能であり、ここでは詳細な説明を省略する。また同様に、プリクラッシュセーフティ制御についても、例えば特開２０１１−３７３０８号公報などに記載されているような周知の技術を用いて実現可能であり、ここでは詳細な説明を省略する。
【００３８】
図１では、上述したアプリケーション機能を実行するために、実際の車両には様々なシステム機能が従属している。以下からは発明のポイントを分かり易く説明するため、アプリケーション機能であるＡＣＣ制御に直接従属するシステム機能は前方車両検知制御（遠距離）の機能だけが従属していると仮定し、プリクラッシュセーフティ制御に直接従属するシステム機能は前方車両検知制御（遠距離、近距離）の機能だけが従属していると仮定して説明する。
【００３９】
図２は、本発明の実施形態における車両制御システム（分散システム）の構成を示す概略構成図である。各ノードにはアプリケーション機能やシステム機能が各々搭載されており、各ノードはネットワーク線１００を介して互いに通信可能に接続されている。
【００４０】
ノード１１０〜１３０のハードウェアの基本構成は、図示しないが周知のマイクロコンピュータ（以下、マイコンと称す）として構成されており、処理内容を記述したプログラムを記憶するメモリであるＲＯＭ及び一時的にデータを保存するＲＡＭを備えている。さらに図示しないが、このハードウェアはそのＲＯＭに記憶されたプログラムを実行するＣＰＵ、時間を計測するタイマカウンタを備えている。さらに図示しないが、このハードウェアは他ノードと通信するための通信ドライバや通信コントローラを有するインターフェース部や、センサ又はアクチュエータと通信するための入出力（Ｉ／Ｏ）部といった通信回路を主要とする構成部品を備えている。またノード内の各構成は図示しないがシステムバスを介してそれぞれ通信可能に接続されている。また、そのＲＯＭには各種プログラムが予め記録されており、インターフェース部やＩ／Ｏ部の通信を処理するプログラム、アプリケーション機能やシステム機能を制御するためのプログラム、各ノード自身のＣＰＵやメモリ、通信回路、ソフトウェア（ＯＳ等）などへの自己診断機能を実行するためのプログラム、フェールセーフ処理（機能を安全に停止、又はリセット後再起動する）やフォールトトレラント処理（機能縮小してもその機能を動作させる）用のプログラムなどが記録されている。またＲＡＭには、ＣＰＵで演算処理されたデータ結果や、他ノードから取得したデータを記憶する機能を備えている。さらに図示しないが、ハードウェアには不揮発性メモリ（記憶装置）をさらに備えている。この記憶装置には、ノードに搭載されたあるソフトウェア機能（親機能とする）と直接従属する機能（つまり、当該ノード又は他ノードに搭載され、親機能に制御される子機能のこと）とを対応付けてリスト化した子機能テーブル（１１２、１２２、１３４、１３５）がある。さらに、その子機能テーブルには子機能の自己診断結果などが保存される。尚、この子機能テーブルの詳細については、図４を用いて後述する。
【００４１】
ノード１１０は、ソフトウェアのアプリケーション機能であるＡＣＣ制御１１１の機能が搭載されており、ノード１２０にはアプリケーション機能であるプリクラッシュセーフティ制御１２１の機能が搭載されている。また、ノード１３０にはソフトウェアのシステム機能である車両前方検知制御１３１の機能が搭載されており、さらにこの車両前方検知制御１３１の機能は、遠距離１３２及び近距離１３３の２つの機能に分かれており、周知の仮想マシン技術によって別々に独立動作可能となっている。またこれらのノード１１０〜１３０はそれぞれ多重通信可能な通信ネットワークであるネットワーク線１００と通信可能に接続され、あるノードからこのネットワーク線１００に接続された他の全てのノードに対して同一内容を同時に送信するブロードキャスト送信が可能な構成となっている。
【００４２】
また、それぞれのノード（１１０、１２０、１３０）に搭載されたソフトウェアの機能毎に、その機能の異常診断をする自己診断機能がそれぞれ用意されている。この自己診断機能は、定期的なタイミング（例えば通信サイクルの１〜数周期毎、若しくは数分毎などの所定時間経過毎）で実行される。また、その対象となる機能（＝親機能）の自己診断を実行中に、親機能だけでなく、その親機能に従属する子機能の異常状態も確認することで、最終的にその親機能自身が異常状態であるか否かを設定（＝決定）している。
【００４３】
またこの子機能の異常検知の方法ついて、図１、２を基に、以下一例を用いて説明する。例えば上述したＡＣＣ制御１１１（親機能）に従属する車両前方検出制御１３２（子機能）が搭載されたノード１３０がある。そのノード１３０は、上記定期的なタイミングでその車両前方検出制御１３２（子機能）の自己診断を行う。そして、その自己診断を行った都度、その自己診断結果をノード１３０からネットワーク線１００に送信する。
【００４４】
そしてノード１１０はそのネットワーク線１００を介してノード１３０から車両前方検出制御１３２の自己診断結果を受信し、そのＡＣＣ制御１１１（親機能）が管理する（ノード１１０のハードウェア内に備えられた記憶装置の）子機能テーブル１１２に記憶しておく。そしてＡＣＣ制御１１１（親機能）は自身の機能に従属する車両前方検出制御１３２（子機能）の診断結果が必要になったとき（つまりＡＣＣ制御の自己診断時）に、ＡＣＣ制御１１１（親機能）が管理する子機能テーブル１１２から読み出すことで車両前方検出制御１３２（子機能）の異常検知を行っている。
【００４５】
尚、ノード１３０には、センサ類（＝センサやアクチュエータの総称）１４０が接続されている。このセンサ類１４０の各々には、ハードウェアとして、マイコンの他、各センサ又はアクチュエータ及びそのセンサ類と通信するための入出力（Ｉ／Ｏ）部といった通信回路を備えており、ノード１３０とそれぞれ通信可能に接続されている。また図２ではセンサ類１４０のソフトウェアの機能として、ミリ波レーダ制御１４１、前方カメラ制御１４２、ソナー制御１４３がそれぞれ備えられている。それらセンサ類のマイコンには、定期的なタイミングでセンサ故障を診断する自己診断機能が備えられている。尚、センサ類が自己診断を実行すると、その自己診断結果は直ぐにセンサ類からノード１３０に送信され、ノード１３０の子機能テーブル（１３４又は１３５）に記憶される。
【００４６】
つまり、ノード１３０の車両前方検知制御１３１は、これらのセンサ類から受信した各測定データの処理機能を有する他、センサ類から受信した自己診断結果を車両前方検出制御１３１が管理する（ノード１３０のハードウェア内に備えられた記憶装置の）子機能テーブル（１３４、１３５）に記憶する処理機能を有している。
【００４７】
次に図３のフローチャート及び図４の子機能テーブルを用いて本発明の実施形態におけるあるノード（例えば１１０、１２０、１３０）に搭載されたソフトウェアの機能（ここではＡＣＣ制御、プリクラッシュセーフティ制御、車両前方検出制御）のうち、それらのソフトウェアの機能が親機能となってその自己診断が各ノードのマイコンで実行されるときの異常検知処理を説明する。
【００４８】
図３は、あるノードに搭載された機能に対する自己診断機能が異常検知処理を実行するときのフローチャートである。また、異常検知処理の基本的な処理は各ノードに搭載されたそれぞれの機能とも同様であるため、ここでは共通のフローチャートとしてまとめて説明する。尚、自己診断の対象となる機能＝親機能として異常検知処理する。
【００４９】
まず図３において、車両のアクセサリスイッチがオンになったとき、又はそのオン後、定期的なタイミング時において、ノードに搭載された親機能は異常検知処理をスタートする。
【００５０】
ステップＳ１０では、まず親機能を動作させるマイコンやプログラムなどに異常が無いかの診断をそれぞれ実行し、ステップＳ１１に進む。
【００５１】
ステップＳ１１（本発明の親機能異常検知手段に相当）では、ステップＳ１０の診断実行結果を受けて、親機能自身に異常があるか否かを判定する。親機能自身に異常がある場合（ＹＥＳ）はステップＳ１２に進み、異常が無い場合はステップＳ１７に進む。
【００５２】
ステップＳ１２では、親機能自身に異常が存在するが、親機能が回復作業によって正常に戻ることができるか否か、すなわち親機能自身が継続して制御可能か否かを判定する。継続可能と判定すれば（ＹＥＳ）、ステップＳ１３に進み、フェールセーフ処理を行う。尚、このフェールセーフ処理では、親機能を一度リセットし、再起動処理を行っている。また再起動処理中は、親機能の必要性（診断中の親機能の処理データを必要とする他ノードの機能があること）に応じて例えば特許文献１に記載されたような異常と診断される前の正常データ、もしくは比例制御のような簡易制御によって得られたデータをダミーデータとして、他ノードに送信している。そして再起動が完了すると、再度ステップ１０に戻り、親機能の異常診断を再度実行する。
【００５３】
また、ステップＳ１２で、親機能の継続が不可能であると判定された（ＮＯ）場合は、ステップＳ１４に進む。
【００５４】
ステップＳ１４（本発明の異常状態設定手段に相当）では、親機能が異常状態であることを設定（ここでは、記憶装置の子機能テーブルに記憶）する。そしてステップＳ１５に進む。
【００５５】
ステップＳ１５では、親機能を停止させる処理を行う。また、ユーザーにこの親機能が異常状態である（つまり親機能が使用不可になった）ことをメータ装置（非図示）内に設けた警告灯（非図示）で警告するための処理を行う。具体的にはネットワーク線１００を介して、異常状態と判定された当ノードから警告灯制御を実行可能なメータ制御用の機能を備えるノード（非図示）に警告信号を送信し、警告信号を受信したそのノードが、警告灯を点灯制御して警告を通知する（本発明の報知手段に相当）。そして本処理を終了する（エンド）。
【００５６】
またステップＳ１１で親機能に異常が無かった（ＮＯ）場合、ステップＳ１６に進む。ステップＳ１６では、親機能が直接従属する子機能の存在を確認する。尚、この子機能の存在については図４を用いて後述する子機能テーブルを参照することによって確認している。子機能の存在を確認したら、ステップＳ１７に進む。
【００５７】
ステップＳ１７（本発明の子機能存在判定手段に相当）では、ステップＳ１６の確認結果を基に、親機能に直接従属する子機能が存在するか否かを判定する。直接従属する子機能が存在する（ＹＥＳ）場合はステップＳ１８に進み、子機能が存在しない（ＮＯ）場合は、ステップＳ２０に進む。
【００５８】
ステップＳ１８では、親機能に直接従属する子機能それぞれの自己診断結果を検知（＝子機能テーブルに記憶された子機能の診断結果を取得）し、ステップＳ１９に進む。
【００５９】
ステップＳ１９（本発明の子機能異常検知手段に相当）では、ステップＳ１８の結果を基に、親機能に直接従属する子機能に異常が検知されたか否かを判定する。子機能に異常が無い（ＮＯ）場合（正常な場合）はステップＳ２０に進み、子機能に異常があった（ＹＥＳ）場合はステップＳ２１に進む。
【００６０】
このステップＳ２０（本発明の異常状態設定手段に相当）に進んだ場合、親機能に異常がなく、かつ親機能に直接従属する子機能にも異常が無いとして、親機能は完全な正常状態であることを設定（つまり記憶装置の子機能テーブルに記憶）し、本処理を終了する（エンド）。
【００６１】
一方、ステップＳ２１（本発明の異常状態設定手段に相当）に進んだ場合、親機能自体には異常は無いが、親機能に直接従属する子機能に異常があったために親機能の性能を維持できないとして、親機能は異常状態であることを設定（記憶装置の子機能テーブルに記憶）し、ステップＳ２２へ進む。
【００６２】
ただし、図３の異常検知処理の対象となる親機能が最も上位の階層のアプリケーション機能（つまり他機能に影響を与えない機能）であり、異常と検知された子機能を切り捨てても、親機能を部分的に継続使用可能である場合は、親機能の機能を縮小して動作させる（フォールトトレラント処理を実行する）ような異常状態と設定（記憶装置の子機能テーブルに記憶）する。つまり親機能が最も上位の階層のアプリケーション機能の場合は、異常状態を複数選択可能に構成されている（尚、システム機能は様々なアプリケーション機能に利用される機会が多いため、異常があれば他機能への影響も大きい。そのためシステム機能の異常状態は一つにしている）。
【００６３】
ステップＳ２２では親機能を停止させる処理を行う。また、ユーザーにこの親機能が異常状態である（つまり親機能が使用不可となった又はフォールトトレラント処理になった）ことを警告灯で警告するための処理（上述したステップＳ１５での警告灯制御と同様の処理）を行う（本発明の報知手段に相当）。そして本処理を終了する（エンド）。
【００６４】
次に上述したステップＳ１０（親機能の異常確認）、ステップＳ１６（子機能テーブルのチェック）、ステップＳ１９（子機能異常検知）、ステップＳ１４、Ｓ２０及びＳ２１（異常状態設定）について、図４の子機能テーブルを用いて詳述する。
【００６５】
尚、図４では、親機能の一例としてここではＡＣＣ制御１１１（対応する子機能テーブル１１２）、プリクラッシュセーフティ制御１２１（対応する子機能テーブル１２２）、車両前方検出制御（遠距離）１３１（対応する子機能テーブル１３４）、車両前方検出制御（近距離）１３２（対応する子機能テーブル１３５）を用い、上記対応する各ステップを具体的に説明する（発明のポイントを分かり易く説明するため他の親機能の例は省略する）。
【００６６】
子機能テーブル１１２には、親機能のＡＣＣ制御に対し、親機能に直接従属する子機能は、車両前方検出制御（遠距離）などであると予め記録されており、子機能の存在はこのリストをチェックして判定される。
【００６７】
尚、親機能及びその子機能の自己診断による異常検知結果は、異常（×）か異常でない（○）かの２値でテーブル内に記憶される（他の子機能テーブルも同様）。
【００６８】
この子機能テーブル１１２では、「異常検知結果」は親機能及びその子機能に異常が無いとして、全て（○）が記憶されている。また、親機能または子機能の異常検知結果に基づく「異常状態」の設定も正常状態（異常状態でない）として、（○）が記憶されている。
【００６９】
子機能テーブル１２２には、親機能のプリクラッシュセーフティ制御に対し、親機能に直接従属する子機能が、車両前方検出制御（遠距離）、車両前方検出制御（近距離）などであると予め記録されており、子機能の存在はこのリストをチェックして判定される。
【００７０】
この子機能テーブル１２２では、「異常検知結果」は、親機能に異常が無いため（○）と記憶されている。しかし、子機能の「異常検知結果」は、車両前方検出制御（近距離）に異常が有るとして×が記憶されている（尚、他の子機能は異常なしとして（○）が記憶されている）。そのため、子機能の異常検知結果に基づく「異常状態」の設定では、（△）（一部異常状態）が記憶されている。ここで（△）と記憶しているのは、例えばプリクラッシュセーフティ制御が機能階層の最上位に位置するアプリケーション機能（他機能に影響を与えない機能）であり、かつ車両前方検出制御（遠距離）が代替機能（前方カメラの機能で近距離を部分的にカバーするなど）を実現できるためである。ここでは一部機能を縮小しても動作を継続（フォールトトレラント処理）させている（つまり子機能の異常検知結果を総合的に判断させて複数の異常状態を設定可能にしている）。
【００７１】
子機能テーブル１３４には、親機能の車両前方検出制御（遠距離）に対し、親機能に直接従属する子機能が、前方カメラ、ミリ波レーダであると予め記録されており、子機能の存在はこのリストをチェックして判定される。
【００７２】
この子機能テーブル１３４では、「異常検知結果」は親機能及びその子機能に異常が無いとして、全て（○）が記憶されている。また、親機能または子機能の異常検知結果に基づく「異常状態」の設定も正常状態（異常状態でない）として、（○）が記憶されている。
【００７３】
子機能テーブル１３５には、親機能の車両前方検出制御（近距離）に対し、親機能に直接従属する子機能が、前方カメラ、ソナーであると予め記録されており、子機能の存在はこのリストをチェックして判定される。
【００７４】
この子機能テーブル１３５では、「異常検知結果」は、親機能には異常が無いので（○）を記憶している。しかし、子機能の「異常検知結果」は、ソナーに異常が有るとして（×）が記憶されている（他の子機能は異常なしとして（○）が記憶されている）。そのため、子機能の異常検知結果に基づく「異常状態」の設定が異常状態であるとして、異常により機能停止状態を意味する×が記憶されている。
【００７５】
この親機能が車両前方検出制御（近距離）のような各アプリケーション機能の稼動自体に必要となるシステム機能であった場合、このシステム機能は他の異なる複数の機能に利用される。そのため、車両制御システム全体の異常処理の負荷影響を考慮すると一部の子機能が正常であっても、機能単位としてはシンプルに異常状態（×）とした方が好ましい（つまり一部異常状態（△）としてしまって上位機能毎に細かな異常通知対応が必要となる中間状態が無い方が好ましい）。
【００７６】
尚、異常状態である場合（△、×）は、車両のユーザーに警告灯を介して警告している。また、本実施形態では詳細に説明しなかったが、もし図３のステップＳ１１で自己診断により親機能自体に異常が検知された場合、子機能の異常の有無に関わらず子機能テーブルの「異常状態」は×に記憶される。
【００７７】
以上、説明した実施形態によれば、ソフトウェア機能の階層構造を有する車両制御システムにおいて、ノードに搭載されたある親機能に直接従属する子機能の異常を検知することで親機能の異常状態を設定することができる。そのため、親機能に関係する全ての機能（子機能−孫機能−・・・）の異常を検知して異常状態を設定する処理よりも簡素な方法で処理負荷を低減することができる。
【００７８】
また、車両制御システムの仕様が変更され、アプリケーション機能又はシステム機能が追加、削除された場合であっても、子機能テーブルのリストを書き換えるだけ（簡単な設計変更）で異常検知処理が対応できる。
【００７９】
以上、本発明の車両制御システム（分散システム）における実施形態を説明してきたが、本発明は上述した実施形態に限定されるものでなく、本発明は特許請求の範囲の各請求項に係る発明の要旨を逸脱しない限り適用できる。
【００８０】
例えば、子機能の異常検知については、上述した実施形態のような定期的なタイミングで診断結果を送信する方法に限ることは無く、子機能に自身の診断結果を送るよう指示する信号を親機能のノードから送信した後、子機能の診断結果信号を子機能のノードからその親機能のノードが受信することで、子機能の異常検知を行ってもよい。このような方法は、子機能に診断結果を保存するよう構成されている場合に有効である。
【００８１】
その他にも、子機能の異常検知方法としては、親機能のノードが子機能のノードに自己診断を実行するよう直接指示する信号を送信し、その実行された診断結果を子機能ノードから親機能のノードに返信するようにしていても良い。このような方法は子機能の診断結果が時間的に古くなっていると判定される場合などに特に有効である。
【００８２】
また本実施形態では、ノード１３０の親機能が直接操作するセンサ類に、それぞれ自己診断機能が搭載されていて、親機能の指示によって子機能の自己診断がそれぞれ実行され、それらの診断結果を親機能に返すようにしていたが、このようなセンサ類毎に自己診断機能が搭載された構成に限ることは無い。例えばメモリ容量の問題などで設計上、親機能が直接操作制御するセンサ類に自己診断機能を搭載しない場合は、親機能側にこれらのセンサ類の自己診断機能を有するように構成し、子機能の異常検知処理を直接制御してもよい。
【００８３】
また異常状態を警告する手段（報知手段）としてここでは、警告灯を用いたが、これに限ることはない。例えば、ネットワーク線１００を介して通信可能に接続されたカーナビゲーション（非図示）などのスピーカー（非図示）から音を出したり、液晶表示画面（非図示）から警告文字を表示させたりしても、これらの警告灯や音や表示の手段を組み合わせて警告しても良い。
【００８４】
尚、本実施形態は、分散システムを自動車の車両制御システムに適用した場合において説明してきたが、これに限ることは無い。分散システムを利用するものであれば適用でき、例えば電車、航空機、船舶などの運行制御システムにも適用可能である。
【符号の説明】
【００８５】
１００  ネットワーク線
１１０、１２０、１３０  ノード
１１１、１２１  アプリケーション機能
１３１、１３２  システム機能
１４０（１４１、１４２、１４３）  センサ類
１１２、１２２、１３４、１３５  子機能テーブル
【図１】
2013239116.tif 000003
【図２】
2013239116.tif 000004
【図３】
2013239116.tif 000005
【図４】
2013239116.tif 000006