(57)【要約】【課題】本発明は、ハードウエアの追加なしに、各制御ユニットが制御対象ユニットを制御するための制御出力データ値を相互に監視し、故障を検出することを実現する制御システム、監視方法及びプログラムを提供することを課題とする。【解決手段】制御ユニット１−１上のアプリＡが制御対象ユニット２−１を制御するための制御出力を、制御ユニット１−２上のモニタＡがモニタリングする。同様に制御ユニット１−２上のアプリＢによる制御出力を、制御ユニット１−３上のモニタＢが、制御ユニット１−３上のアプリＣによる制御出力を、制御ユニット１−４上のモニタＣが、制御ユニット１−４上のアプリＤによる制御出力を、制御ユニット１−１上のモニタＤがモニタリングする。【選択図】図３
2010039628.tif 000002
【特許請求の範囲】
【請求項１】
複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおいて
前記複数の制御ユニットの内の１つである第１の制御ユニットは、
前記制御対象ユニットの１つを制御するために前記ネットワーク上に制御データを出力する少なくとも１つのアプリケーション部と、
前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックするモニタ部と、
を備え、
前記複数の制御ユニットの内の１つである第２の制御ユニットは、
前記第１のユニットが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックするモニタ部と、
を備えることを特徴とする制御システム。
【請求項２】
前記制御ユニットは、前記モニタ部による前記制御データのチェックの結果、異常が検出されたとき当該制御データを出力した制御ユニットに対して故障リカバリ処理を行う構成制御マネージャ部を更に備え、
前記構成制御マネージャ部は、前記リカバリ処理として、前記異常が検出された制御データを出力した制御ユニットそのもの若しくは当該制御ユニット上のアプリケーションプログラムを再起動することを行うことを特徴とする請求項１に記載の制御システム。
【請求項３】
前記制御ユニットは、前記モニタ部による前記制御データのチェックの結果、異常が検出されたとき当該制御データを出力した制御ユニットに対して故障リカバリ処理を行う構成制御マネージャ部を更に備え、
前記構成制御マネージャ部は、前記リカバリ処理として、前記異常が検出された制御データを出力した制御ユニットを前記制御システムから切り離すことを特徴とする請求項１に記載の制御システム。
【請求項４】
複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおける監視方法であって、
前記複数の制御ユニットの内の１つである第１の制御ユニットは、
前記制御対象ユニットを制御するために前記ネットワーク上に制御データを少なくとも１つを出力し、
前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックし、
前記複数の制御ユニットの内の１つである第２の制御ユニットは、
前記第１のユニットが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックする
ことを特徴とする監視方法。
【請求項５】
複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおける当該制御ユニットで実行されるプログラムであって、
前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックし、
前記チェックの結果異常があれば当該制御データを出力した前記制御ユニットに対してリカバリ処理を行うことを前記制御ユニットに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御対象ユニットを制御する制御システムに関し、更に詳しくは制御ユニットが制御対象ユニットの制御に用いる値（以後、これを「制御出力」と称する）を監視して、信頼性を向上させた制御システムに関する。
【背景技術】
【０００２】
自動車、航空機、鉄道車両、船舶などに組み込まれるプロセッサシステムや工場やプラントにおいて機器の制御に用いられるプロセッサシステム等、高信頼性が要求される制御システムでは、従来から２重化や、３重化といったような多重化システムが用いられている。
【０００３】
プロセッサをベースとした３重化システムでは、それぞれの出力値の比較を行い、多数決の原理によって動作を決定し、もし、特定のプロセッサのみが他の２台のプロセッサと違った値を出していることが検出された場合には、そのプロセッサは故障したものと判断して切り離すことにより、高信頼性を実現している。
【０００４】
また、２重化システムでは、どちらのプロセッサが故障であるかという判定は出力値の比較だけではできないが、システムとしての故障を検出することは可能である。
一方組込みシステムや機器制御を行うシステムにおいては、処理能力の向上の要求からマルチプロセッサ型の制御システムが必要となってきつつある。
【０００５】
しかし、高信頼性の観点から考えた場合、上述した多重化システムのようにマルチプロセッサ型システムに内蔵されるすべてのプロセッサを２重化することは、システム価格の大幅な上昇を招き、現実的ではない。
【０００６】
マルチプロセッサ型の制御システムでは、すでに複数のプロセッサを内蔵しているために、相互に各プロセッサの状態を監視させれば、各プロセッサの故障を検出することが可能である。例えば、各プロセッサからの「自己故障検出」や「生存通知の異常」の相互監視といったマルチプロセッサシステムにおける故障検出の手法は、高信頼性を要求されるサーバシステムにおいては、すでに適用されている技術である。例えば、特許文献１や特許文献２には、互いに動作確認信号を送出して相互監視を行うマルチプロセッサのシステムが開示されている。
【０００７】
また、組込みシステムにおいても、例えば特許文献３には、各プロセッサが自身の動作状況を共有メモリの特定の領域に書込み、その情報を他のプロセッサが読み出してチェックし、異常が検出された場合にはその情報を書き込んだプロセッサを故障と判断し、当該プロセッサで実行されていたアプリケーションプログラムを故障を検出したプロセッサが代替実行する、さらに故障と判定されたプロセッサに対してリセットをかけ再起動させるという手法が開示されている。
【０００８】
さらに特許文献４には、２つの独立した制御ユニットを持つ組込みシステムにおいて、それぞれの制御システムに内蔵されているマイクロコンピュータが、自身の制御出力を生成すると共に、相手側の制御出力値を制御閾値と比較することによって、２つの制御ユニットの制御出力を相互に監視する手法が開示されている。
【特許文献１】特開平７−２６２０４２号公報
【特許文献２】特開昭６３−４３６６号公報
【特許文献３】特開２００４−３１０２５２号公報
【特許文献４】特開２００６−１１６８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述したプロセッサを多重化した制御システムにおいては、システムが大規模になり、コストアップにつながるという問題点がある。また規模が大きいので実装面積を要するという問題点も持つ。
【００１０】
またプロセッサを多重化した制御システムにおいては、制御出力を監視対象とすることができるが特許文献３に開示の技術では、監視の対象となっていた値は、各プロセッサが書き込む動作状況である。この場合、監視を行う情報は各プロセッサで同一であり、したがって監視プログラムも各プロセッサで同一のプログラムを動作させれば良いというメリットがあるが、「制御出力」そのものの監視はできないという問題点を持つ。
【００１１】
このため、特許文献３に開示されている故障検出方法では、制御出力データそのものの監視ができず、かつ、実際には、故障検出に遅れが生じる場合があるため、誤った制御出力が制御対象に転送されてしまい、その結果として誤動作を起こす可能性がある。
【００１２】
また制御出力を監視しようとした場合、各アプリケーションプログラムによって「制御出力」の値、出力間隔、誤り検出のための出力レベル設定等がすべて異なることが多い。したがって、特許文献３の方法そのままでは、各制御出力を相互に監視することはできない。
【００１３】
更に特許文献４に開示されている手法を使った場合には、プロセッサが相互に出力値の異常検出を行うことは可能である。しかしながら、１本のネットワークで相互接続された複数の制御ユニットからなるシステム構成での相互監視には適用できない。さらに、故障検出後の故障リカバリ処理等により、システムの構成が再構築された場合には、対応することができない。
【００１４】
上記問題点を鑑みて本発明は、ハードウエアの追加なしに、各制御ユニットが制御対象ユニットを制御するための制御データを相互に監視し、故障を検出することを実現する制御システム、監視方法及びプログラムを提供することを課題とする。
【００１５】
また、故障検出がなされた結果、システムのリカバリ処理として、故障制御ユニットの切離しやアプリケーションプログラムの再配置がなされた場合にも、当該制御出力データの相互監視が継続できるようにすることを可能とする制御システム、監視方法及びプログラムを提供することを課題とする。
【課題を解決するための手段】
【００１６】
本発明の制御システムは、複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成を前提とする。
【００１７】
前記複数の制御ユニットの内の１つである第１の制御ユニットは、少なくとも１つのアプリケーション部及びモニタ部を備える。
アプリケーション部は、前記制御対象ユニットの１つを制御するために前記ネットワーク上に制御データを出力する。
【００１８】
モニタ部は、前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックする。
前記複数の制御ユニットの内の１つである第２の制御ユニットは、モニタ部を備える。
【００１９】
モニタ部は、前記第１のユニットが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックする。
また本発明の監視方法は、複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおける監視方法であって、前記複数の制御ユニットの内の１つである第１の制御ユニットは、前記制御対象ユニットを制御するために前記ネットワーク上に制御データ少なくとも１つを出力し、前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックし、前記複数の制御ユニットの内の１つである第２の制御ユニットは、前記第１のユニットが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックする、ことを特徴とする。
【００２０】
更に本発明によるプログラムは、複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおける当該制御ユニット実行されるプログラムであって、前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックし、前記チェックの結果異常があれば当該制御データを出力した前記制御ユニットに対してリカバリ処理を行うことを前記制御ユニットに実行させる。
【発明の効果】
【００２１】
本制御システムによれば、制御ユニットが相互に制御データをチェックすることが出来る。
また故障リカバリ等により、前記制御ユニット上で動作するアプリケーションプログラムの再配置がなされた場合でも、相互監視を継続するが可能となる。
【００２２】
さらには、制御ユニット自体の２重化等による価格上昇をまねくことなく、また該監視のための各処理ユニットの処理負荷は小さく、監視の処理が本来のアプリケーションプログラムによる処理に影響を与えることがない。
【００２３】
またネットワーク上に出力された制御データ自体をチェックすることから、ネットワーク・トラフィックの負荷を増大させることなく、制御出力データ自体の監視を高速に実施することができる。
【００２４】
さらに制御ユニットの故障等によって、システムを構成する制御ユニットの構成が変化しても、制御データの監視を継続でき、システムの信頼性を高めることが可能となる。
また、制御出力自体を監視することができるため、異常を検出した場合には制御対象への制御データ転送を抑止することが可能となり、制御対象における誤動作を回避することができる。
【発明を実施するための最良の形態】
【００２５】
以下に図面を参照しながら本発明の一実施形態について説明する。
図１は本実施形態における制御システムの構成例を示す図である。
本実施形態の制御システム１０は、プロセッサを内蔵する複数の制御ユニット１−１〜１−４と、複数の制御対象ユニット２−１〜２−４がネットワーク３で接続された構成となっている。
【００２６】
そして、ネットワーク３を介して、制御ユニット１−１〜１−４が制御対象ユニット２
−１〜２−４に対して制御出力を行うことにより、制御対象ユニット２−１〜２−４を制御する。
【００２７】
図１の構成では、制御ユニット１と制御対象ユニット２は１対１の関係にあり、制御ユニット１−１が制御対象ユニット２−１を、制御ユニット１−２が制御対象ユニット２−２を、制御ユニット１−３が制御対象ユニット２−３を、そして制御ユニット１−４が制御対象ユニット２−４を制御している。この制御対象ユニット２−１〜２−４の制御は、各制御ユニット１−１〜１−４上で稼働するアプリケーションプログラム（以下アプリという）によって行われ、制御ユニット１−１で稼働しているアプリＡが制御対象ユニット２−１の、制御ユニット１−２で稼働しているアプリＢが制御対象ユニット２−２の、制御ユニット１−３で稼働しているアプリＣが制御対象ユニット２−３の、そして制御ユニット１−４で稼働しているアプリＤが制御対象ユニット２−４の、制御データを生成し、それぞれバス３上に制御出力することによって制御を行っている。
【００２８】
なお図１では制御システム１０は、４つの制御ユニット１−１〜１−４と４つの制御対象ユニット２−１〜２−４を備える構成としてあるが、これは一例であり、制御ユニット１は複数、制御対象ユニット２は１つ以上であればいくつでも良い。また制御ユニット１と制御対象ユニット２は１対１の関係となっているが、１つの制御ユニット１が複数の制御対象ユニット２を制御する構成であっても、また逆に複数の制御ユニット１が１つの制御対象ユニット２を制御する構成でも良い。
【００２９】
各制御対象ユニット２−１〜２−４にはそれぞれネットワークアドレスが設定されており、制御ユニット１は制御を行う制御対象ユニット２のアドレスを指定して制御出力を行なう。そして制御対象ユニット２−１〜２−４は、ネットワーク３上に制御ユニット１−１〜１−４によって制御出力として送信された通信パケットの送信先アドレスを見て、自己のアドレスと同じであったらその通信パケットを取り込む。
【００３０】
図２は、各制御ユニット１−１〜１−４によって制御出力としてネットワーク３に送出される通信パケットの構成例を示す。
同図において、通信パケットは、内部に情報として制御ビット１１、送信先アドレス１２、送信元アドレス１３及び制御データ１４を有している。
【００３１】
このうち制御ビットは、この通信パケット内の制御データが有効であるか否かを示す情報であり、制御データは、この通信パケットの送信先である制御対象ユニット２に対する制御指示を行うデータである。
【００３２】
次に本実施形態の制御システム１０における各制御ユニット１−１〜１−４が出力する制御出力の監視について説明する。
図３は、本実施形態の制御システム１０による制御出力の監視を説明する図である。
【００３３】
同図に示すように、各制御対象ユニット２−１〜２−４にはそれぞれ制御出力の監視を行うプログラムであるモニタが搭載されており、このモニタを実行することによって他の制御ユニット１のアプリがネットワーク３上に送出する制御出力をチェックする。
【００３４】
同図において制御ユニット１−１〜１−４上のアプリＡ、アプリＢ、アプリＣ及びアプリＤは制御対象ユニット２−１〜２−４を送信先として、決められたタイミングでネットワーク３に制御出力を行う。制御ユニット１−２上のモニタＡは、制御ユニット１−１上のアプリＡによる制御出力をチェックし、制御ユニット１−３上のモニタＢは、制御ユニット１−２上のアプリＢによる制御出力をチェックし、制御ユニット１−４上のモニタＣは、制御ユニット１−３上のアプリＣによる制御出力をチェックし、そして制御ユニット１−１上のモニタＤは、制御ユニット１−４上のアプリＤによる制御出力をチェックする。
【００３５】
このように本実施形態の制御システム１０では、各制御ユニット１−１〜１−４がそれぞれ相互に制御出力をチェックしている。これにより、各制御ユニット１−１〜１−４による制御対象ユニット２−１〜２−４への制御出力を監視することが出来、またそのための特別なハードウエア構成を必要としない。
【００３６】
以下に図３に従って、動作例を示す。
１）制御対象ユニット２−１を制御するために制御ユニット１−１で実行されているアプリＡによる制御出力を監視するため、モニタＡを制御ユニット１−２上で動作させる。アプリＡが制御対象ユニット２−１に対して制御出力を行うと、モニタＡは、そのパケットの送信先アドレス１２をチェックし、制御対象ユニット２−１に対するものであると判断するとパケット内の制御データ１４をチェックして、アプリＡが正常に動作しているかどうかをチェックする。
２）制御対象ユニット２−２を制御するために制御ユニット１−２で実行されているアプリＢによる制御出力を監視するため、モニタＢを制御ユニット１−３上で動作させる。アプリＢが制御対象ユニット２−２に対して制御出力を行うと、モニタＢは、そのパケットの送信先アドレス１２をチェックし、制御対象ユニット２−２に対するものであると判断するとパケット内の制御データ１４をチェックして、アプリＢが正常に動作しているかどうかをチェックする。
３）制御対象ユニット２−３を制御するために制御ユニット１−３で実行されているアプリＣによる制御出力を監視するため、モニタＣを制御ユニット１−４上で動作させる。アプリＣが制御対象ユニット２−３に対して制御出力を行うと、モニタＣは、そのパケットの送信先アドレス１２をチェックし、制御対象ユニット２−３に対するものであると判断するとパケット内の制御データ１４をチェックして、アプリＣが正常に動作しているかどうかをチェックする。
４）制御対象ユニット２−４を制御するために制御ユニット１−４で実行されているアプリＤによる制御出力を監視するため、モニタＤを制御ユニット１−１上で動作させる。アプリＤが制御対象ユニット２−４に対して制御出力を行うと、モニタＤは、そのパケットの送信先アドレス１２をチェックし、制御対象ユニット２−４に対するものであると判断するとパケット内の制御データ１４をチェックして、アプリＤが正常に動作しているかどうかをチェックする。
【００３７】
制御出力監視プログラムであるモニタＡ〜Ｄを、上記のように各制御ユニット１−１〜１−４に配置することによって、アプリＡ〜Ｄのすべての制御出力データを相互に監視することが可能となる。
【００３８】
なお、各制御ユニット１−１〜１−４上で動作するモニタＡ〜Ｄは、ネットワーク上に対応するアプリから出力される通信パケットの送信先アドレス（または送信元アドレス）を監視し、自分が監視するべき制御出力データかどうかを判定する。そしてもし、自分の監視すべきアドレスであると判定した場合には、当該通信パケットを取り込み、これを例えば各アプリＡ〜Ｄによって決まっている制御出力の閾値と比較し、これを越えていれば異常値と判断するといった動作を行う。
【００３９】
そして異常を検出したモニタは、対応する制御対象ユニット２に対して指示を行い、異常な制御データによって制御対象ユニット２が誤動作するのを抑止することができる。また異常を検出したモニタは、異常な制御データを送信した制御ユニット１を故障と判断し、システムからの切離しやアプリのリセット／リブート動作等の故障リカバリ処理を行わせることもできる。
【００４０】
図４は、本実施形態の制御システム１０のネットワーク３のトポロジーの種類を示す図である。
制御システム１０のネットワーク３は、ある制御ユニット１が制御対象ユニット２に対して制御出力を行ったとき、モニタを搭載している他の制御ユニット１がその制御出力されたパケットを見ることが出来る構成、例えば各制御ユニット１−１〜１−４が直接１つのネットワーク３に接続されるような構成であれば、どのような構成のネットワーク３でも良い。
【００４１】
従ってネットワーク３のトポロジーの種類は、図１、図３に示したバス型の他に、図４（ａ）に示すようなリング型のネットワーク３や、同図（ｂ）に示すようなデイジーチェーン型のネットワーク３であっても良い。
【００４２】
次に本実施形態の制御システム１０における各タイミングについて説明する。
図５は、本実施形態の制御システム１０のタイムチャートを示す図である。
同図において、制御システム１０のネットワーク３上には、決められたタイミングにしたがって、各制御ユニット１−１〜１−４上で動作するアプリＡ〜Ｄから、各制御対象ユニット２−１〜２−４を制御するために、通信パケットが出力される。なお図４中の通信パケットに示すＡ１０〜Ａ１３は、送信先の制御対象ユニット２−１〜２−４のネットワークアドレスである。
【００４３】
以下に時間に沿って動作を説明する。
１）制御ユニット１−１上のアプリＡは、制御対象ユニット２−１を制御するための通信パケットＡ１０をネットワーク上に送信する。このパケットの送信先アドレスはＡ１０である。通信パケットを送信していない制御ユニット１−２〜１−４上のモニタＢ〜Ｄは、ネットワーク３上に制御出力された通信パケットの送信先アドレス１２をチェックする。この場合には、送信先アドレスはＡ１０であるため、制御ユニット１−２上のモニタＡが、このパケットを監視対象通信パケットと判断して取り込み、制御データ１４のチェックを行い、正常／異常の判定を行う。
２）制御ユニット１−２上のアプリＢは、制御対象ユニット２−２を制御するための通信パケットＡ１１をネットワーク３上に送信する。このパケットの送信先アドレスはＡ１１である。通信パケットを送信していない制御ユニット１−１、１−３、１−４上のモニタＤ、Ｂ、Ｃは、ネットワーク３上に制御出力された通信パケットの送信先アドレス１２をチェックする。この場合には、送信先アドレスはＡ１１であるため、制御ユニット１−３上のモニタＢが、このパケットを監視対象通信パケットと判断して取り込み、制御データ１４のチェックを行い、正常／異常の判定を行う。
３）制御ユニット１−３上のアプリＣは、制御対象ユニット２−３を制御するための通信パケットＡ１２をネットワーク３上に送信する。このパケットの送信先アドレスはＡ１２である。通信パケットを送信していない制御ユニット１−１、１−２、１−４上のモニタＤ、Ａ、Ｃは、ネットワーク３上に制御出力された通信パケットの送信先アドレス１２をチェックする。この場合には、送信先アドレスはＡ１２であるため、制御ユニット１−４上のモニタＣが、このパケットを監視対象通信パケットと判断して取り込み、制御データ１４のチェックを行い、正常／異常の判定を行う。
４）制御ユニット１−４上のアプリＤは、制御対象ユニット２−４を制御するための通信パケットＡ１３をネットワーク３上に送信する。このパケットの送信先アドレスはＡ１３である。通信パケットを送信していない制御ユニット１−１〜１−３上のモニタＤ、Ａ、Ｂは、ネットワーク３上に制御出力された通信パケットの送信先アドレス１２をチェックする。この場合には、送信先アドレスはＡ１３であるため、制御ユニット１−１上のモニタＤが、このパケットを監視対象通信パケットと判断して取り込み、制御データ１４のチェックを行い、正常／異常の判定を行う。
【００４４】
このように制御ユニット１が制御対象ユニット２を制御するために制御出力した通信パケットは、他の制御ユニット１に搭載されているモニタプログラムによってチェックされ、通信パケットを制御出力した制御ユニット１が正常に動作しているかどうかをモニタしている。
【００４５】
なお上記説明では、ネットワーク３上の通信パケットの送信先アドレス１２のチェックをモニタプログラムが行うものとした。しかしこのような方法のみ成らず、アドレス比較器を制御ユニット１内のネットワークインターフェース部に内蔵し、このアドレス比較器によって、制御出力された通信パケットの送信先アドレスと予め設定されている監視すべきアドレスと比較するようにしても良い。そしてこの比較の結果、２つのアドレスが一致した場合に、アドレス比較器が制御ユニット１内のプロセッサに対して割込み信号を入力し、これによって、モニタプログラムを起動するように構成しても良い。
【００４６】
図６は、上記したアドレス比較器を制御ユニット１内のネットワークインターフェース部に内蔵した場合の制御ユニット１の構成例を示すブロック図である。
同図において制御ユニット１は、外部メモリ２６と接続されているＣＰＵコア２１、アドレス比較器２２、モニタ対象アドレス設定レジスタ２３、出力レジスタ２４、及び入力レジスタ２５を有している。
【００４７】
ＣＰＵコア２１は、外部メモリ２６内に記憶されているアプリケーションプログラムやモニタプログラムを実行するものである。アドレス比較器２２は、モニタ対象アドレス設定レジスタ２３内のアドレス値とネットワーク３上の通信パケットの送信先アドレス１２とを比較し、両者が一致したならばＣＰＵコア２１に対して割り込み信号２７を出力するものである。モニタ対象アドレス設定レジスタ２３は、この制御ユニット１上で稼働しているモニタがモニタリングしている他の制御ユニット１上のアプリが制御している制御対象ユニット２のアドレスが設定されるレジスタである。このモニタ対象アドレス設定レジスタ２３には、制御ユニット１が起動時にＣＰＵコア２１によってモニタリング対象の制御対象ユニット２のアドレス値が設定される。出力レジスタ２４は、ＣＰＵコア２１がアプリを動作中に生成される通信パケットを格納するレジスタである。入力レジスタ２５は、ネットワーク３上に制御出力されたパケットが格納されるレジスタである。この入力レジスタ２５内の通信パケット中の送信先アドレス１２はアドレス比較器２２に入力される。
【００４８】
このような構成において、起動された制御ユニット１は、ネットワーク３上に制御出力される通信パケットを入力レジスタ２５内に格納する。そして入力レジスタ２５内の通信パケットの送信元アドレス１２とモニタ対象アドレス設定レジスタ２３内のアドレス値とをアドレス比較器２２で比較する。その結果２つのアドレス値が一致したならば、ＣＰＵコア２１に対して割り込み信号２７を出力して、ＣＰＵコア２１に割り込みをかける。割り込みがかかったＣＰＵコア２１は、外部メモリ２６内のモニタプログラムを起動する。このモニタは、入力レジスタ２５内の制御データ１４を取り込んでチェックを行い、正常／異常の判定を行う。
【００４９】
次にモニタによって行われる制御データ１４のチェックについて説明する。
図７は、モニタによって行われる制御データ１４の異常検出の例を示す図である。
図７において、縦軸は制御出力の値を表し、この数値が図２に示す各アプリがネットワーク３上に送信する通信パケット内の制御データ１４に相当する。モニタはこの数値があらかじめ設定されている最大閾値（閾値ｍａｘ）を越えた場合、または最小閾値（閾値ｍｉｎ）を下回った場合に異常出力と判断する。
【００５０】
また、各アプリによって生成される制御データは、各センサーからの値を用いて求められることが多いため、このセンサーからの入力値にノイズ等が乗っていた場合には制御データ１４の値が異常となる場合がある。このような場合に対処するため、異常値のカウント回数にも予め閾値を定めておき、異常値の検出回数がカウント回数の閾値以上になったことによって、異常と判断しても良い。あるいは異常値の回数／特定時間間隔が閾値異常となったときに異常であると判断するようにしても良い。
【００５１】
なおここでは、異常値の判定方法の一例を述べたが、当然、各アプリの特性により、判断の手法は最適な方法がとられることになる。
モニタによって制御データ１４の異常が検出されると、異常を検出した制御ユニット１は、故障リカバリ処理を行う。
【００５２】
故障リカバリ処理の代表的なものとしては、異常が検出された制御データ１４を生成したアプリを再起動する、若しくはそのアプリが起動している制御ユニット１全体を再起動することが考えられる。
【００５３】
この場合、異常を検出したモニタが、異常が検出された制御ユニット１に対して異常検出を通知し、この通知を受けた制御ユニット１は、対応するアプリを再起動する、あるいは自己に対してリセットをかける等の処理を行う。
【００５４】
このようなアプリや制御ユニット１の再起動によって異常が直った場合は、引き続き処理を行うが、異常から復帰出来ない場合には、別の故障リカバリ処理を行う。
このとき行う故障リカバリ処理の例として、図８に処理優先度による故障時の処理再割付例を示す。以下にこの処理再割付の動作を述べるが、故障リカバリ処理はこの方法に限るわけではなく、他の方法を採用しても良いことは言うまでもない。
１）制御ユニット１が故障した場合には、その制御ユニット１の切り離しを行う。
２）故障した制御ユニット１上で動作していたアプリの優先度を残った正常な制御ユニット１上で動作中のアプリの優先度と比較する。
３）２）での比較の結果、故障した制御ユニット１上で動作していたアプリの優先度が高い場合には、正常動作中のアプリの中で最も優先度の低いアプリを停止させ、その制御ユニット１で故障した制御ユニット１上で実行していた優先度の高いアプリを代替実行させる。
４）２）での比較の結果、故障した制御ユニット１上で動作していたアプリの優先度が最も低かった場合には、故障した制御ユニット１の切り離しのみを行い、アプリの再配置は行わない。
【００５５】
図８の例では、制御ユニットＵ０で起動しているアプリが処理０を、制御ユニットＵ１で起動しているアプリが処理１を、制御ユニットＵ２で起動しているアプリが処理２を、制御ユニットＵ３で起動しているアプリが処理３を行っており、各処理は処理０＞処理１＞処理２＞処理３の処理優先度を持つとする。なお以下の（１）〜（４）は図８中の（１）〜（４）に対応する。
【００５６】
このような状態において制御ユニットＵ０が故障し、それを他の制御ユニットで動作しているモニタが検出したとする。（１）
制御システム１０は、故障した制御ユニットＵ０を切り離し、次にこの制御ユニットＵ０上で動作していた処理０を、稼働中の制御ユニットのうちもっとも処理優先度が低い処理３のアプリを実行していた制御ユニットＵ３に代替実行させる。（２）
この状態で制御ユニットＵ１が更に故障し、これを他の制御ユニット上のモニタが検出したとする。（３）
制御システム１０は、故障した制御ユニットＵ１を切り離し、次にこの制御ユニットＵ
１上で動作していた処理１を、稼働中の制御ユニットのうちもっとも処理優先度が低い処理２のアプリを実行していた制御ユニットＵ２に代替実行させる。（４）
次に故障リカバリ処理として上述したアプリの再配置を行う場合の第１の例を図９に示す。
【００５７】
以下に図９に従って、本実施形態の制御システム１０によるアプリの再配置処理を説明する。なお図９において、アプリの処理優先度は、アプリＡ＞アプリＢ＞アプリＣ＞アプリＤとする。
１）制御ユニット１−２上で動作しているモニタＡが、制御ユニット１−１上で動作しているアプリＡの制御出力データの異常を検出。
２）アプリＡを再起動する等の処理を行っても異常から復帰せず制御ユニット１−１そのものが異常であると判断。
３）制御ユニット１−１を制御システム１０から切り離すと共に、アプリＡの処理優先度と他の稼働中のアプリＢ、Ｃ、Ｄの処理優先度を比較し、最も処理優先度が低いアプリＤが稼働している制御ユニット１−４にアプリＡを代替実行させる。
４）３）のアプリの再配置処理によって、各アプリは以下のように再配置される。
アプリＡ：制御ユニット１−４
アプリＢ：制御ユニット１−２  変化無し
アプリＣ：制御ユニット１−３  変化無し
アプリＤ：                    停止
制御ユニット１−１：切離し
５）アプリの再配置にしたがって、モニタも再配置を行う。（図９に示す例の場合は、故障した制御ユニット１−１で稼働していたのがモニタＤなので初期状態からの変化はない）
モニタＡ：変化無し
モニタＢ：変化無し
モニタＣ：変化無し
次に故障リカバリ処理として上述したアプリの再配置を行う場合の第２の例を図１０に示す。
【００５８】
以下に図１０に従って、本実施形態の制御システム１０によるアプリの再配置処理を説明する。なお図１０においても、アプリの処理優先度は、アプリＡ＞アプリＢ＞アプリＣ＞アプリＤとする。
１）制御ユニット１−３上で動作しているモニタＣが、制御ユニット１−２上で動作しているアプリＢの制御出力データの異常を検出。
２）アプリＢを再起動する等の処理を行っても異常から復帰せず制御ユニット１−２そのものが異常であると判断。
３）制御ユニット１−２を制御システム１０から切り離すと共に、アプリＢの処理優先度と他の稼働中のアプリＡ、Ｃ、Ｄの処理優先度を比較し、最も処理優先度が低いアプリＤが稼働している制御ユニット１−４にアプリＢを代替実行させる。
４）３）のアプリの再配置処理の結果、各アプリは以下のように再配置される。
アプリＡ：制御ユニット１−１  変化無し
アプリＢ：制御ユニット１−４
アプリＣ：制御ユニット１−３  変化無し
アプリＤ：                    停止
制御ユニット１−２：切離し
５）４）のアプリ再配置にしたがって、モニタも下記のように再配置する。
モニタＡ：制御ユニット１−４
モニタＢ：変化無し
モニタＣ：制御ユニット１−１
このように本実施形態の制御システム１０では、故障リカバリ処理として上述したアプリの再配置を行う場合、アプリだけでなくモニタも再配置される。またこの再配置によって同一の制御ユニット１にモニタとそのモニタによるモニタリングの対象のアプリとが動作しないように考慮して再配置処理が行われる。
【００５９】
図１１に各制御ユニット１−１〜１−４が故障した場合のアプリの再配置、及びアプリの再配置に伴うモニタの再配置例を示す。
同図の再配置例では、アプリとそのアプリをモニタリングするモニタが同一の制御ユニット１に配置されないように再配置が行われている。
【００６０】
この図１１に示すようにモニタの再配置を行うことによって、制御ユニット１の故障による切り離し等のリカバリ処理によりアプリの再配置が起こった場合にも、制御出力データの監視が継続して可能となる。
【００６１】
次に制御ユニット１に搭載されるソフトウエアについて説明する。
図１２に、各制御ユニット１−１〜１−４のソフトウエア動作環境を示す。
本実施形態の制御ユニット１−１〜１−４は、各制御ユニット１内のＣＰＵ＃０〜ＣＰＵ＃３で動作するリアルタイムＯＳ（ＲＴＯＳ）及び故障のときの制御を行うミドルウエアである構成制御マネージャＣ＃０〜Ｃ＃３の上に、制御ユニット１が出力する通信パケット内の制御データ１４のチェックを行うソフトウエアであるモニタＭ＃Ａ〜Ｍ＃Ｄを実装している。
【００６２】
上述したように各制御ユニット１−１〜１−４上で動作するモニタプログラムは、一般的に監視対象のアプリケーションによって動作が異なっており、その配置はアプリケーションプログラムの配置が変更された場合には、それに従って再配置される。また構成制御マネージャは、故障検出時に故障リカバリ処理を行い、かつ、アプリケーションプログラムと制御出力監視プログラムの再配置を行う。
【００６３】
次に１つの制御対象ユニット２を複数の制御ユニット１で制御する構成の制御システム１０について説明する。
これまでの例では、制御対象ユニット２と制御ユニット１は１対１の関係の関係にある場合について説明してきたが、本実施形態の制御システム１０はこのような構成に限定されるものではなく、１つの制御対象ユニット２を複数の制御ユニット１で制御する構成としても良い。
【００６４】
図１３は、１つの制御対象ユニット２を２つの制御ユニット１によって制御する構成の制御システム１０の例を示す図である。
同図において、制御対象ユニット２−１は、制御ユニット１−１及び制御ユニット１１−３によって制御され、また制御対象ユニット２−２は、制御ユニット１−２及び制御ユニット１−４によって制御される構成となっている。
【００６５】
この構成においても、制御ユニット１−１のアプリＡによる制御出力は、制御ユニット１−３のモニタＡによって、また制御ユニット１−２のアプリＢによる制御出力は、制御ユニット１−４のモニタＢによって相互にモニタリングされる。そしてまた制御ユニット１−３のアプリＣによる制御出力は、制御ユニット１−１のモニタＣによって、また制御ユニット１−４のアプリＤによる制御出力は、制御ユニット１−２のモニタＤによって相互にモニタリングされる。
【００６６】
このように１つの制御対象ユニット２を複数の制御ユニット１によって制御する構成の制御システム１０においても、各制御ユニット１−１〜１−４による制御出力は、他の制
御ユニット１−１〜１−４上のモニタによってチェックが行われる。
【００６７】
また本実施形態の制御システム１０は、１つの制御ユニット１が複数の制御対象ユニット２を制御する構成でも良い。
図１４は、１つの制御ユニット１が複数の制御対象ユニット２を制御する構成の制御システム１０の例を示す図である。
【００６８】
同図において制御ユニット１−１は、アプリＡとアプリＢの２つのアプリを稼働させており、制御対象ユニット２−１と制御対象ユニット２−２の２つの制御対象ユニット２を制御している。また制御ユニット１−２では、モニタＡとモニタＢの２つのモニタプログラムが稼働している。
【００６９】
このような構成においても、制御ユニット１−１のアプリＡとアプリＢによる制御出力は、制御ユニット１−２のモニタＡとモニタＢによってチェックされる。
図１５は、１つの制御ユニット１が複数のアプリによる制御出力をモニタリングする構成の制御システム１０を示す図である。
【００７０】
同図において、制御ユニット１−１及び制御ユニット１−３は、アプリのみ稼働しており、モニタは稼働していない。逆に制御ユニット１−２及び制御ユニット１−４は、アプリの他に２つのモニタが稼働しており、制御ユニット１−２は制御ユニット１−１及び制御ユニット１−４の制御出力をモニタリングし、制御ユニット１−４は、制御ユニット１−２及び制御ユニット１−３の制御出力をモニタリングしている。
【００７１】
このように本実施形態の制御システム１０は、１つの制御ユニット１が複数のアプリによる制御出力をチェックする構成として実現することも出来る。
次に各制御ユニット１−１〜１−４に図１２に示したような構成のソフトウエアを搭載している場合のモニタ及び構成制御マネージャによる制御出力のモニタリングと故障リカバリ処理を時の動作を説明する。
【００７２】
なお以下の例では故障リカバリ処理として故障制御ユニット１の切り離し処理を行う場合を例として示している。
図１６は、制御出力のモニタリング及び故障検出時の制御ユニット１の切り離し処理時のモニタ及び構成制御マネージャの動作を示すフローチャートである。
【００７３】
同図において、処理が開始されると、まずモニタ４０の制御出力データ値監視部４１は、ステップＳ１としてネットワーク３に制御出力された通信パケットの送信アドレスが自己がモニタリングしているアプリの制御対象の制御対象ユニット２のアドレスと一致するかどうかを調べ、一致しなければ（ステップＳａ１、Ｎｏ）、一致する通信パケットが制御出力されるまで待つ。
【００７４】
ステップＳａ１において、送信先アドレスが自己がモニタリングしているアプリの制御対象の制御対象ユニット２のアドレスと一致する通信パケットが制御出力されたならば（ステップＳａ１、Ｙｅｓ）、その通信パケットを取り込む。そして制御出力値監視部は、ステップＳａ２として通信パケットから制御データ１４を取り出すと共に、メモリから対象出力値テーブルを読出し、これらを比較する。この対象出力値テーブルは、各アプリそれぞれについての制御データ１４の異常検出に用いる閾値をテーブルとして記憶しているもので、制御出力データ値監視部４１はこの対象出力テーブル内の閾値と制御データ１４を比較することによって制御データ１４が正常かどうかを判断する。なお、比較する制御出力データの数は１つでも良いし、複数でも良い。
【００７５】
そしてステップＳａ２の比較の結果、制御データ１４が正常であると判断したならば（ステップＳａ３、Ｎｏ）、処理をステップＳａ１に戻す。
またステップＳａ２の比較の結果、制御データ１４が異常であると判断したならば（ステップＳａ３、Ｙｅｓ）、制御出力データ値監視部４１は、ステップＳａ４として、異常値回数をカウントし、異常値回数が閾値以下であったなら（ステップＳａ５、Ｎｏ）、処理をステップＳａ１に戻す。
【００７６】
ステップＳａ５において、異常値回数が閾値を超えたなら（ステップＳａ５、Ｙｅｓ）、制御出力データ値監視部４１は、処理を構成制御マネージャ５０の代替実行処理部５１に受け渡す。
【００７７】
これを受けて代替実行処理部５１は、ステップＳａ６として、異常な制御データ１４を含む通信パケットを制御出力した制御ユニット１の各制御ユニット１を識別する識別子であるＵＮＩＴ  Ｎｏ．を確認し、この制御ユニット１を故障と判定する。そして代替実行処理部５１は、ステップＳａ７としてこの制御ユニット１を制御システム１０から切り離す。
【００７８】
次に代替実行処理部５１は、ステップＳａ８として切り離した制御ユニット１で稼働していたアプリによる処理の優先度を確認する。その結果、切り離した制御ユニット１で稼働していたアプリによる処理の優先度が最低優先度でなければ（ステップＳａ９、Ｎｏ）、代替実行処理部５１は、ステップＳa１０として切り離した制御ユニット１上で稼働していたアプリを最も優先度が低いアプリを稼働させている制御ユニット１に代替実行させる。またステップＳａ９において、切り離した制御ユニット１で稼働していたアプリによる処理の優先度が最低優先度であったならば（ステップＳａ９、Ｙｅｓ）、代替実行処理部５１は、ステップＳａ１０の処理をスキップさせてアプリの再配置は行わない。
【００７９】
そして代替実行処理部５１は、ステップＳａ１１として、各制御ユニット１上で稼働しているモニタを図１１に則って再配置する。
そして代替実行処理部５１は、ステップＳ１２として、稼働中の制御ユニット１及びその制御ユニット１で稼働しているアプリとモニタを示す構成制御テーブルを書き換え、またこの新規の構成制御テーブルを現在稼働中の制御ユニット１に対してブロードキャスト通信で通知後、本処理を終了する。
【００８０】
図１７は、図１６のステップＳ１１で行われるモニタの再配置処理の詳細を示すフローチャートである。
同図においてアプリＡ０〜Ａｎは、Ａ０＞Ａ１＞Ａ２＞・・・＞Ａｎの優先度で、故障した制御ユニット１上で稼働していたアプリＡｘはＡ０≧Ａｘ≧Ａｎであるとする。またアプリＡ０、Ａ１、・・・、Ａｎに対応するモニタは、モニタＭ０、Ｍ１、・・・、Ｍｎであるとする。そしてアプリＡｎとモニタＭ０、アプリＡｎ−１とモニタＭｎ、アプリＡｎ−２とモニタＭｎ−１、・・・、アプリＡ０とモニタＭ１が同じ制御ユニット１上で稼働しているものとする。
【００８１】
同図のフローに処理が移ると、代替実行処理部５１は、まずステップＳｂ１として故障した制御ユニットＵ１上で稼働していたアプリＡｘがアプリＡｎであるかどうかを判断する。そしてＡｘ＝Ａｎであるのならば（ステップＳｂ１、Ｙｅｓ）、ステップＳｂ２、Ｓｂ３の処理をスキップする。
【００８２】
ステップＳｂ１において、Ａｘ≠Ａｎならば（ステップＳｂ１、Ｎｏ）、次にステップＳｂ２としてアプリＡｘがＡ０であるかどうかを判断する。そしてその結果Ａｘ＝Ａ０ならば、モニタの再配置は行わずに、本処理を終了して図１６のフローに戻る。
【００８３】
ステップＳｂ２において、Ａｘ≠Ａ０であるならば（ステップＳｂ２、Ｎｏ）、代替実行処理部５１はモニタの再配置処理として、ステップＳｂ３においてアプリＡｘが再割り付けされた制御ユニット１で稼働するモニタをモニタＭｘ−１に変更する。
【００８４】
そして最後にステップＳｂ４として、代替実行処理部５１は、アプリＡ０が新たに割り当てられた制御ユニット１にモニタＭｎ−１を割り当て、処理を図１６のフローに戻す。
これにより、最低優先度のアプリＡｎを実行中の制御ユニット１が故障した場合は、アプリＡ０を実行中の制御ユニット１に配置されるモニタをモニタＭｎ−１に変更する。
【００８５】
また最高優先度のアプリＡ０を実行中の制御ユニット１が故障した場合は、モニタの再配置は行わない。
そして故障アプリＡｘが、Ａｎ、Ａ０以外の場合、つまり、最低優先度のアプリまたは最高優先度のアプリを実行中以外の制御ユニットが故障した場合は、まず、アプリＡｘを再実行する制御ユニット１（上述したとおり故障した制御ユニット１で実行中のアプリは、最低優先度のアプリＡｎを実行中の制御ユニット１で代替実行されるため、これは最低優先度のアプリＡｎを実行中の制御ユニット１となる）、のモニタをモニタＭｘ−１に変更する。次に、最高優先度アプリＡ０を実行中の制御ユニット１のモニタをモニタＭｎ−１に変更する。
【００８６】
この図１６、図１７のようにモニタ４０や構成制御マネージャ５０が処理を行うことによって、制御出力される制御データ１４の異常の検出、制御ユニット１の故障リカバリ処理としての故障制御ユニット１の切り離し及びアプリとモニタの再配置が実現される。
【００８７】
次に各制御ユニット１−１〜１−４が相互に生存情報を通知し合い、制御ユニット１の故障を検出する場合について説明する。なお以下の説明では、各制御ユニット１−１〜１−４は、定周期で、自己以外の他の制御ユニット１全てに対して生存情報を通知する構成とした場合を例として挙げているが、本実施形態の制御システム１０では、複数の制御ユニット１に対して通知する構成の他、特定の制御ユニット１に対して通知する構成としても良い。
【００８８】
図１８は、モニタ４０の相互生存監視部４２による相互監視処理を示すフローチャートである。
相互生存監視部４２は、制御システム１０内の他の制御ユニット１から生存情報を受信し、この生存情報から制御システム１０内の他の制御ユニット１が正常に稼働していることを検出するものである。
【００８９】
この相互生存監視部４２は、制御出力データ値監視部４１と並列して動作する。
図１８の処理が開始されると、まずステップＳｃ１として、制御出力データ値監視部４２は、待ち時間が予め定められた生存監視間隔に達したかどうかを判断する。そして生存間隔に達していなければ（ステップＳｃ１、Ｎｏ）、ステップＳｃ１に処理を戻し待ち時間が生存監視間隔に達するのを待つ。
【００９０】
ステップＳｃ１において、待ち時間が生存監視間隔に達すると、相互生存監視部４２は、ステップＳｃ２において生存情報を読み出す。そして次に相互生存監視部４２は、ステップＳｃ２で読み出した生存情報が異常かどうかを判定する。その結果異常がなければ処理をステップＳｃ１に戻す。
【００９１】
またステップＳｃ３で生存情報に異常が検出されたならば、ステップＳｃ４として相互生存監視部４２は、生存情報を送信してきた制御ユニット１は故障であると判断し、処理
を構成制御マネージャ５０の代替実行処理部５１に受け渡す。
【００９２】
これをうけて代替実行処理部５１は、ステップＳｃ５〜Ｓｃ１１の処理を行い、故障と判定された制御ユニット１の切り離し及びアプリとモニタの再配置を行う。
この代替実行処理部５１によるステップＳｃ５〜Ｓｃ１１の処理は、図１６のステップＳａ６〜Ｓａ１２の処理と同じなので説明は省略する。
【００９３】
このように相互生存監視部４２を制御出力データ値監視部４１と並列に動作させることにより、より厳重な制御ユニット１の生存チェックを行うことが出来る。
なお図１８では、定周期で自己が正常に起動していることを通知する生存情報を送信していたが、逆に自己に故障が検出されたときに故障検出情報を他の制御ユニット１に通知し、これを受信した制御ユニット１が故障リカバリ処理を行う構成としても良い。
【００９４】
次にモニタ４０が制御データ１４の異常を検出した場合、その制御データ１４を含むパケットの出力先である制御対象ユニット１に対して指示を行うことによって、異常が検出された制御データ１４の使用を抑止するようにした場合のモニタ４０及び構成制御マネージャ５０の動作処理について説明する。
【００９５】
図１９は、異常が検出された際に、制御対象ユニット２の停止を指示する場合のモニタ４０及び構成制御マネージャ５０の動作処理を示すフローチャートである。
同図において処理が開始されると、まずモニタ４０の制御出力データ値監視部４１がステップＳｄ１〜Ｓｄ５の処理を行い、制御ユニット１の異常を検出して、処理を構成制御マネージャ５０の代替実行処理部５１に受け渡す。
【００９６】
このとき制御出力データ値監視部４１が行うステップＳｄ１〜Ｓｄ５の処理は、図１６のステップＳａ１〜Ｓａ５の処理と同じなので、説明は省略する。
代替実行処理部５１は、ステップＳｄ６として、異常な制御データ１４を含む通信パケットを制御出力した制御ユニット１のＵＮＩＴ  Ｎｏ．を確認し、この制御ユニット１を故障と判定する。そして代替実行処理部５１は、ステップＳｄ７としてこの制御ユニット１の制御対象となっている制御対象ユニット２にデータエラー信号を送る。このエラー信号を受けた制御対象ユニット２は、制御ユニット１から制御出力された通信パケット内の制御データ１４を破棄して停止する。
【００９７】
次に代替実行処理部５１は、ステップＳｄ８として、故障と判定した制御ユニット１を制御システム１０から切り離す。
そして次に代替実行処理部５１は、ステップＳｄ９として、ステップＳｄ７でデータエラー信号を送った制御対象ユニット２のステータスレジスタの内容をチェックし、制御対象ユニット２が現在どの状態で停止しているのかを確認する。そして必要ならば代替実行処理部５１は、制御対象ユニット２に対して指示を出す。
【００９８】
次に代替実行処理部５１は、ステップＳｄ１０として、ステップＳｄ８切り離した制御ユニット１で稼働していたアプリによる処理の優先度を確認する。その結果、切り離した制御ユニット１で稼働していたアプリによる処理の優先度が最低優先度でなければ（ステップＳｄ１１、Ｎｏ）、代替実行処理部５１は、ステップＳ１２として切り離した制御ユニット１上で稼働していたアプリを最も優先度が低いアプリを稼働させている制御ユニット１に代替実行させる。またステップＳｄ１１において、切り離した制御ユニット１で稼働していたアプリによる処理の優先度が最低優先度であったならば（ステップＳｄ１１、Ｙｅｓ）、代替実行処理部５１は、ステップＳｄ１２の処理をスキップさせてアプリの再配置は行わない。
【００９９】
そして代替実行処理部５１は、ステップＳｄ１３として、各制御ユニット１上で稼働しているモニタを図１１に則って再配置する。
そして代替実行処理部５１は、ステップＳｄ１４として、稼働中の制御ユニット１及びその制御ユニット１で稼働しているアプリとモニタを示す構成制御テーブルを書き換え、またこの新規の構成制御テーブルを現在稼働中の制御ユニット１に対してブロードキャスト通信で通知後、本処理を終了する。
【０１００】
このように、故障した制御ユニット１の制御対象である制御対象ユニット２に対してデータエラー信号を送信するように構成することにより、制御対象ユニット２は、エラーを含む制御データ１４によって動作してしまうことを防ぐことが出来る。
【０１０１】
次に、故障リカバリ処理として、故障した制御ユニット１を切り離すのではなく、再起動を行う構成とした場合を説明する。
図２０は、故障リカバリ処理として、再起動を行う場合のモニタ４０及び構成制御マネージャ５０の動作処理を示すフローチャートである。
【０１０２】
同図の処理が開始されると
同図において処理が開始されると、まずモニタ４０の制御出力データ値監視部４１がステップＳｅ１〜Ｓｅ５の処理を行い、制御ユニット１の異常を検出して、処理を構成制御マネージャ５０の代替実行処理部５１に受け渡す。
【０１０３】
このとき制御出力データ値監視部４１が行うステップＳｅ１〜Ｓｅ５の処理は、図１６のステップＳａ１〜Ｓａ５の処理と同じなので、説明は省略する。
代替実行処理部５１は、ステップＳｅ６として、異常な制御データ１４を含む通信パケットを制御出力した制御ユニット１のＵＮＩＴ  Ｎｏ．を確認し、この制御ユニット１を故障と判定する。そして代替実行処理部５１は、ステップＳｅ７としてこの制御ユニット１上で稼働していたアプリを確認する。
【０１０４】
次に代替実行処理部５１は、ステップＳｅ８で故障と判定した制御ユニット１は、アプリのみが異常動作をしており、ＯＳは正常に動作しているかどうかを判定する。
その結果、ＯＳは正常に動作していると判断したならば（ステップＳｅ８、Ｙｅｓ）、アプリのみが異常動作していると思われるので、代替実行処理部５１は、ステップＳｅ９としてステップＳｅ７で確認した故障アプリを一旦停止し、ステップＳｅ１０で再起動した後本処理を終了する。
【０１０５】
またステップＳｅ８の判定の結果、ＯＳも正常に動作していないと判断したならば（ステップＳｅ、Ｎｏ）、ステップＳｅ１１として故障と判定した制御ユニット１を一旦停止し、ステップＳ１２で再起動をかけた後本処理を終了する。
【０１０６】
このように本実施形態の制御システム１０は、故障リカバリ処理として、故障した制御ユニット１を切り離すのではなく、アプリや制御ユニット１を再起動することによって処理に復帰させることが出来るように構成することも出来る。
【０１０７】
なお図２０の処理を行っても、その制御ユニット１が正常に戻らない場合には、代替実行処理部５１は、図１６のステップＳａ６〜Ｓａ１２のような処理を行いその制御ユニット１を切り離すよう構成しても良い。
【０１０８】
なお上記説明では制御システム１０は、自動車等に組み込まれる組み込み向けのシステムの場合を例として挙げているが、本実施形態の制御システム１０は、組み込み向けのシステムだけでなく工場やプラントなどにおいて機器を制御する制御システムにも適用する
ことが出来る。
【０１０９】
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおいて
前記複数の制御ユニットの内の１つである第１の制御ユニットは、
前記制御対象ユニットの１つを制御するために前記ネットワーク上に制御データを出力する少なくとも１つのアプリケーション部と、
前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックするモニタ部と、
を備え、
前記複数の制御ユニットの内の１つである第２の制御ユニットは、
前記第１のユニットが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックするモニタ部と、
を備えることを特徴とする制御システム。
（付記２）
前記複数の制御ユニットは、第１の制御ユニット乃至第ｎの制御ユニット（ｎは２以上の整数）であり、
前記第１の制御ユニットのモニタ部は、前記第ｎの制御ユニットが前記ネットワーク上に出力した制御データをチェックし、前記第ｘの制御ユニット（ｘ＝２〜ｎの整数）のモニタ部は、第ｘ−１の制御ユニットが前記ネットワーク上に出力した制御データをチェックすることを特徴とする付記１に記載の制御システム。
（付記３）
前記制御ユニットは、前記モニタ部による前記制御データのチェックの結果、異常が検出されたとき当該制御データを出力した制御ユニットに対して故障リカバリ処理を行う構成制御マネージャ部を更に備え、
前記構成制御マネージャ部は、前記リカバリ処理として、前記異常が検出された制御データを出力した制御ユニットそのもの若しくは当該制御ユニット上のアプリケーションプログラムを再起動することを行うことを特徴とする付記１に記載の制御システム。
（付記４）
前記制御ユニットは、前記モニタ部による前記制御データのチェックの結果、異常が検出されたとき当該制御データを出力した制御ユニットに対して故障リカバリ処理を行う構成制御マネージャ部を更に備え、
前記構成制御マネージャ部は、前記リカバリ処理として、前記異常が検出された制御データを出力した制御ユニットを前記制御システムから切り離すことを特徴とする付記１に記載の制御システム。
（付記５）
前記構成制御マネージャ部は、前記切り離した制御ユニット上で稼働していたアプリケーションプログラムの優先度が、稼働している他のアプリケーションより優先度が高いとき、最も低い優先度のアプリケーションプログラムを停止し、当該最も低い優先度のアプリケーションプログラムが稼働していた制御ユニットに前記切り離した制御ユニット上で稼働していたアプリケーションプログラムを代替稼働させることを特徴とする付記４に記載の制御システム。
（付記６）
前記構成制御マネージャ部は、前記制御ユニットの切り離しに基づいて前記モニタ部の再配置を行うことを特徴とする付記４、付記５に記載の制御システム。
（付記７）
前記モニタ部は、自己が正常動作していることを示す生存情報を他の制御ユニットに送
信する生存情報送信部と、他の制御ユニットからの前記生存情報をチェックする相互生存監視部とを備えることを特徴とする付記１に記載の制御システム。
（付記８）
前記モニタ部によるチェックは、前記制御データが予め定められた範囲内にあるか否かをチェックし、前記制御データが予め定められた範囲を特定回数超えた場合、当該制御データの送信元の制御ユニットを異常と判定することを特徴とする付記１に記載の制御システム。
（付記９）
複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおける監視方法であって、
前記複数の制御ユニットの内の１つである第１の制御ユニットは、
前記制御対象ユニットを制御するために前記ネットワーク上に制御データ少なくとも１つを出力し、
前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックし、
前記複数の制御ユニットの内の１つである第２の制御ユニットは、
前記第１のユニットが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックする
ことを特徴とする監視方法。
（付記１０）
複数の制御ユニットと当該制御ユニット上で起動するアプリケーションプログラムによって制御される１つ以上の制御対象ユニットがネットワークで接続された構成の制御システムにおける当該制御ユニットで実行されるプログラムであって、
前記複数の制御ユニットのうちの少なくとも一つが前記制御対象ユニットの１つを制御するために前記ネットワーク上に出力した制御データをチェックし、
前記チェックの結果異常があれば当該制御データを出力した前記制御ユニットに対してリカバリ処理を行うことを前記制御ユニットに実行させるプログラム。
【図面の簡単な説明】
【０１１０】
【図１】本実施形態における制御システムの構成例を示す図である。
【図２】各制御ユニットによって制御出力としてネットワークに送出される通信パケットの構成例を示す図である。
【図３】本実施形態の制御システムによる制御出力の監視を説明する図である。
【図４】本実施形態の制御システムのネットワークのトポロジーの種類を示す図である。
【図５】本実施形態の制御システムのタイムチャートを示す図である。
【図６】アドレス比較器をネットワークインターフェース部に内蔵した場合の制御ユニットの構成例を示すブロック図である。
【図７】モニタによって行われる制御データの異常検出の例を示す図である。
【図８】処理優先度による故障時の処理再割付例を示す図である。
【図９】故障リカバリ処理としてアプリの再配置を行う場合の第１の例を示す図である。
【図１０】本実施形態の制御システムによるアプリの再配置処理を説明する図である。
【図１１】各制御ユニットが故障した場合のアプリの再配置、及びアプリの再配置に伴うモニタの再配置例を示す図である。
【図１２】各制御ユニットのソフトウエア動作環境を示す図である。
【図１３】１つの制御対象ユニットを２つの制御ユニットによって制御する構成の制御システムの例を示す図である。
【図１４】１つの制御ユニットが複数の制御対象ユニットを制御する構成の制御システムの例を示す図である。
【図１５】１つの制御ユニットが複数のアプリによる制御出力をモニタリングする構成の制御システムを示す図である。
【図１６】制御出力のモニタリング及び故障検出時の制御ユニットの切り離し処理時のモニタ及び構成制御マネージャの動作を示すフローチャートである。
【図１７】図１６のステップＳ１１で行われるモニタの再配置処理の詳細を示すフローチャートである。
【図１８】モニタの相互生存監視部による相互監視処理を示すフローチャートである。
【図１９】異常が検出された際に、制御対象ユニットの停止を指示する場合のモニタ及び構成制御マネージャの動作処理を示すフローチャートである。
【図２０】故障リカバリ処理として再起動を行う場合のモニタ及び構成制御マネージャの動作処理を示すフローチャートである。
【符号の説明】
【０１１１】
１      制御ユニット
２      制御対象ユニット
３      ネットワーク
１０      制御システム
１１      制御ビット
１２      送信先アドレス
１３      送信元アドレス
１４      制御データ
２１      ＣＰＵコア
２２      アドレス比較器
２３      モニタ対象アドレス設定レジスタ
２４      出力レジスタ
２５      入力レジスタ
【図１】
2010039628.tif 000003
【図２】
2010039628.tif 000004
【図３】
2010039628.tif 000005
【図４】
2010039628.tif 000006
【図６】
2010039628.tif 000007
【図１３】
2010039628.tif 000008
【図１４】
2010039628.tif 000009
【図１５】
2010039628.tif 000010
【図１６】
2010039628.tif 000011
【図１７】
2010039628.tif 000012
【図１８】
2010039628.tif 000013
【図１９】
2010039628.tif 000014
【図２０】
2010039628.tif 000015
【図５】
2010039628.tif 000016
【図７】
2010039628.tif 000017
【図８】
2010039628.tif 000018
【図９】
2010039628.tif 000019
【図１０】
2010039628.tif 000020
【図１１】
2010039628.tif 000021
【図１２】
2010039628.tif 000022