JP2010027062A

JP2010027062A - 分散制御システム

Info

Publication number: JP2010027062A
Application number: JP2009191718A
Authority: JP
Inventors: Naoki Kato; 直樹加藤; Fumio Arakawa; 文男荒川
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2009-08-21
Filing date: 2009-08-21
Publication date: 2010-02-04

Abstract

【課題】複数の制御装置がネットワークで接続された分散制御システムにおいて、リアルタイム性を保証した上で各制御装置を効率よく稼動させること、リアルタイム性を保証した上で耐故障性の向上を達成した負荷分散システムの提供。
【解決手段】各タスクには、タスク終了までの要求時間であるデッドラインまたはタスクが起動される周期の情報を付与し、前記デッドラインまたはタスク周期に応じて、タスクを実行する制御装置を選択する。高速な応答時間を保証し易い専用パスで第一の制御回路とセンサ及びアクチュエータとを接続し、更に他の制御回路とセンサ及びアクチュエータとをネットワークで接続する。第一の制御回路が正常動作、且つ、処理能力が十分な場合は第一の制御回路を制御に使用し、第一の制御回路が故障、あるいは、処理能力が不足の場合は他の制御回路を使用する。
【選択図】図１

Description

本発明は、複数の制御対象機器を制御するためのプログラムを実行する複数の制御装置をネットワークで接続した分散制御システムに関するものであり、特に車両制御に代表されるリアルタイム性の要求の高い分散制御システムに関する。

自動車等の電子制御装置（ＥＣＵ）では、制御回路（ＣＰＵ）が、センサ等から入力された情報に基づいて制御信号を生成してアクチュエータに出力し、アクチュエータが前記制御信号に基づいて動作する。近年、自動車内では、このような電子制御装置が増加している。また、各制御装置間で、連係動作若しくはデータを共有化の通信を行うために互いに接続して、ネットワークを構築している。

このように複数の制御装置をネットワークで接続した分散制御システムにおいては、個々の制御装置は、制御装置固有の制御プログラムのみを実行するように構成されているために、最大の負荷に対応できる処理性能の制御装置が選択される。しかし、対象とする機器が動作しない場合や、複雑な制御を必要としない場合には、制御装置の処理能力を十分に利用していないために、全体としての動作効率が低いという問題がある。

一方、ビジネス利用や学術研究などに用いられる計算機システムでは、複数のコンピュータで負荷を分散して処理を行わせることで、一台一台の性能は低くとも高速に大量の処理を実行できるようにする試みが行われている。例えば、特許文献１（特開平７−３２８４４２号公報）では、計算機群を構成する複数の計算機に複数の種類の業務を負荷分散することが可能な方法が提案されている。車両内の分散制御システムにおいても、複数の制御装置で負荷分散を行う技術が提案されている。例えば、特許文献２（特開平７−９８８７号公報）では、制御装置を通信線で接続して自動車各部の制御を実行するものにおいて、少なくとも１つの制御装置は制御負荷の高い他の制御装置の制御項目の少なくとも１つを実行可能にするようにし、制御装置間でバックアップを可能にするとともに、処理量の平均化を計るものとしている。

また、特許文献３（特開２００４−３８７６６号公報）では、ネットワークに接続された制御装置毎に実行する必要のある固有タスクと、任意の制御装置にて実行可能なフロートタスクとに分け、そのフロートタスク実行用のプログラムを、ネットワークに接続されたマネージャ制御装置にて管理する。そして、マネージャ制御装置は、車両の運転状態や乗員からの指示に応じて、そのとき実行すべきフロートタスクを特定し、そのフロートタスクを、処理負荷が低く、フロートタスクを実行可能な制御装置に実行させる。

制御回路とセンサ及びアクチュエータとは専用パスで接続されるのが一般的である。また、特許文献４（特開平７−０７８００４号公報）記載の制御装置では、制御回路、セン
サ、及びアクチュエータを全てネットワークで接続し、専用パスを用いない方式が開示されている。この方式の利点は、専用パスの代わりにネットワークを使うことにより、センサ情報によるアクチュエータのための制御処理を、特定の制御回路に限定せずにネットワークに接続された、どの制御回路でも行えることである。この結果、ある制御回路が故障しても、他の制御回路で容易にバックアップでき、信頼性が向上する。また、公報では開示されていないが、適切な分散制御技術と組み合わせれば、制御を複数の制御回路に分散処理させることも、専用パス方式より容易であると考えられる。

また、公報にも開示されているように、ネットワークの故障に備えてネットワークを二重化することも良く知られている。

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

特許文献１で開示された技術は、主にビジネス利用の分散計算機環境での負荷分散方法に関するものであり、タスクのリアルタイム性の保証に関する考慮はなされていない。また、特許文献２で開示された技術は、自動車用の分散制御システムであり、複数の制御装置間での負荷分散を行うものであるが、自動車の制御では特に重要であるタスクのリアルタイム性の保証に関する考慮はなされていない。特許文献３では、個々の制御装置固有のタスクと、どの制御装置で実行してよいフロートタスクとに予めタスクを分け、任意の制御装置で実行可能なフロートタスクのみを負荷分散に利用している。この場合には、予めシステムを構築する際に固有タスクとフロートタスクとに分けておく必要がある。実際は動作状況によって他の制御装置で実行可能かどうかは変化する。また、自動車制御においては、一般的には、個々の制御装置での処理が負荷の大半を占めており、特許文献３のように局所性のあるタスクを負荷分散の対象から除外すると、負荷分散に用いることができるタスクが少ないために、うまく負荷を分散することが出来なくなってしまう。

本発明の第１の課題は、複数の制御装置がネットワークで接続された分散制御システムにおいて、リアルタイム性を保証した上で各制御装置を効率よく稼動させる負荷分散方法を提供することにある。

本発明が解決しようとする第２の課題は、リアルタイム性を保証した上で耐故障性の向上を達成することにある。制御回路とセンサ及び制御回路とアクチュエータが専用パスで接続され、個々の制御装置上で個々の制御プログラムを動作させる従来からの一般的な電子制御装置の場合は、十分なリアルタイム性を保証できるが、個々の制御装置が故障した場合に、その動作が停止することになる。つまり、耐故障性が低いことになる。全ての制御装置を２重化する方法も考えられるが、システムコストの上昇が避けられない。

一方、特許文献４では、全てのセンサ情報及びアクチュエータ制御情報がネットワークを介して遣り取りされる構成をとっている。この場合、１つの制御回路が故障した場合でも、センサ情報やアクチェータ制御信号は、ネットワークを通じて別の制御回路とやり取りでき、継続動作が可能となる。しかし、自動車等の電子制御装置では、センサ情報取得からアクチュエータ制御までを数ｍｓから数十ｍｓで処理する必要がある。このため、前記ネットワークは十分なスループットを持っているだけでなく、高速な応答時間を保証しなければならない。しかしながら、多数の制御回路、センサ及びアクチュエータが同時に情報を遣り取りする状況では、全てのアクセスの高速な応答時間を保証することは困難で
ある。

さらに、第３の課題は、複数の制御回路を仮想化し、分散処理を容易化することである。すなわち、ユーザープログラムから見たシステムの均一性を実現し、特定の制御回路と特定のセンサ又はアクチュエータとの組み合わせを意識してプログラミングする必要をなくし、あたかも一つの高性能な制御回路があるかのように扱えるようにすることである。

本発明の第４の課題は、回路の冗長性を最小限に抑えつつ、自動車のようなコストに敏感なシステムにも適用可能な、耐故障性の向上や分散処理の容易化を達成することである。

前記第１の課題を達成するために本発明は、ネットワークで接続された複数の制御装置で複数のタスクを実行する分散制御システムにおいて、各タスクには、タスク終了までの要求時間であるデッドラインまたはタスクが起動される周期の情報を付与し、前記デッドラインまたはタスク周期に応じて、タスクを実行する制御装置を選択するようにする。さらに、タスクに処理完了に要する時間と、起動された制御装置以外の他の制御装置で実行した場合の往復の通信レイテンシ情報を付与することで、ネットワークで接続された他の制御装置で実行した際にリアルタイム性を保証可能か判断できるようにし、タスクを実行する制御装置を選択するようにする。

また、通信レイテンシは、通信時にどれだけのデータを転送する必要があるかによって決まる点に鑑み、タスク実行においてアクセスする個々の制御装置の記憶装置内のデータ量およびアクセスする個々の制御装置の入力装置からの入力信号のデータ量の情報が付与されており、前記データ量を元に通信レイテンシを算出する手段を備える。さらにネットワークのトラフィック量を観測する手段を設け、トラフィック量に応じて通信レイテンシを補正する。

個々の制御装置の演算能力や記憶装置の構成などのタスク処理能力が制御装置毎に異なる場合には、タスク処理時間を、タスク処理能力に応じて補正する手段を設ける。さらに、タスク処理時間および通信レイテンシ情報を、過去に実際にタスクが実行された際の実行時間により、更新する手段を設ける。また、制御装置は実行待ちタスクをタスク管理リストに格納し、新たなタスクの起動要求が発生した際に、前記タスク管理リストを参照し、前記新たなタスクのデッドライン以内での実行完了が可能かどうかを検証し、デッドライン以内の実行が不可能な場合に、タスク管理リストに含まれるタスクおよび新たな起動タスクの中から他の制御装置に実行を依頼する少なくとも１つのタスクを選択し、選択したタスクの起動要求コマンドを他の制御装置にネットワークを通じて送信する。

また、要求コマンドを送信する際に、タスクのデッドラインおよび処理時間の情報を合わせて送信する。タスク実行を依頼する他の制御装置を決定するための手段の１つは、前記タスクの起動要求コマンドを送信する前に、少なくとも１つの他の制御装置に対して、前記タスクのデッドライン、処理時間、通信レイテンシ情報を送信することで、前記デッドライン以内でタスクを完了できるかを問い合わせる通信を行い、可能であるとの返信があった他の制御装置の中から実際にタスクの起動要求コマンドを送信する制御装置を選択する。

タスク実行を依頼する他の制御装置を決定するための別の手段は、前記タスクの起動要求コマンドを送信する前に、少なくとも１つの他の制御装置に対して、前記タスクのデッドライン時刻までの負荷状況を問い合わせ、前記タスクのデッドライン、処理時間、通信レイテンシ情報、および、返信された負荷状況から、他の制御装置で、前記デッドライン
以内でタスクを完了できるかを検証し、検証の結果タスクの実行が可能であった他の制御装置の中から実際にタスクの起動要求コマンドを送信する制御装置を選択する。

第２の課題を解決するための構成手段は、まず高速な応答時間を保証し易い専用パスで第一の制御回路とセンサ及びアクチュエータとを接続し、更に他の制御回路とセンサ及びアクチュエータとをネットワークで接続する。そして、第一の制御回路が正常動作しており、処理能力が十分な場合は第一の制御回路を制御に使用し、第一の制御回路が故障したり、処理能力が足りなかったりした場合は他の制御回路を使用するようにする。

さらに、ユーザープログラムが特定のタスクを特定の制御装置に限定して実行させるように意識するのでなく、上記タスクの分配は、ＯＳやミドルウェアにより実現するために、ユーザープログラム開発を複雑化することなく、分散処理の恩恵を受けられるようにして、第３の課題を解決する。

更に、専用パスとネットワークの二系統のパスを備えることで、ネットワークを二重化しなくても、一つの制御回路の故障時に他の制御回路でバックアップできる構成とする。そのため、個々の制御回路の二重化も不要とでき、回路の冗長性が押さえられ、第４の課題を解決する。

本発明によれば、リアルタイム性の保証、耐故障性の向上、又は、複数の制御回路の仮想化が実現できる。

Ｎ個の制御装置ＥＣＵ１〜ＥＣＵＮがネットワークＮＷ１に接続された構成の概略を示す図である。ａ）−（ｄ）は、横軸に現在時刻を０としたときの時間をとって、各タスクが制御回路で処理される実施例１のスケジュールの態様を示す図である。各制御装置がデッドラインを守った処理を行うための負荷分散の他の実施例を説明するための図である。各制御装置のタスク管理リストＴＬに登録されているタスク処理時間ＰＴを過去の実績の履歴で更新する構成の概略を示す図である。各制御装置のタスク管理リストＴＬに登録されている通信レイテンシＣＬを過去の履歴で更新する構成の概略を示す図である。各制御装置のタスク管理リストＴＬに登録されている通信レイテンシＣＬをタスクのデータアクセス量と通信の待ち時間から更新する構成の概略を示す図である。横軸に現在時刻を０としたときの時間をとって、各タスクが制御回路で処理される実施例６のスケジュールの態様を示す図である。制御装置ＥＣＵ間でタスクの実行依頼を行う通信パケットの例を説明する図である。タスクの起動要求が発生してから、負荷分散によるタスク実行を行う一連のフローの例を説明する図である。タスクの起動要求が発生してから、負荷分散によるタスク実行を行う一連の他のフローの例を説明する図である。直結信号線とネットワークを併用した制御システムを示す図である。図１１の構成のネットワークを二重化した例を示す図である。実施例１０の変形例として、図１１のシステムのネットワークを分割した例を示す図である。図１１のシステムのネットワークを図１３とは異なる方式で分割した実施例を示す図である。図１１のシステムのネットワーク接続を削減した本実施例を示す図である。図１５のシステムのネットワーク接続を二重化した実施例を示す図である。図１１のシステムのネットワークに記憶ユニットＭＥＭＵを接続した例を示す図である。無線によるネットワークの構成例を示す図である。自動車内のＬＡＮで接続された制御装置とさらに無線で接続される車外のサーバによって構成されるネットワークの例を示す図である。

（実施例１）
図１および図２を用いて本発明の実施例１を説明する。図１は、Ｎ個の制御装置ＥＣＵ１〜ＥＣＵＮがネットワークＮＷ１に接続された構成の概略を示す図である。ただし、図１では、制御装置ＥＣＵ１〜ＥＣＵ３およびＥＣＵＮのみが表示され、他の制御装置は省略されている。また、内部構成は説明に必要な制御装置ＥＣＵ１およびＥＣＵ２についてのみ示している。制御装置ＥＣＵ１の内部には、ネットワークＮＷ１に接続してデータの通信を担当する通信装置ＣＯＭ１、タスクを処理する制御回路ＣＰＵ１、センサ群ＳＮ１及びアクチュエータ群ＡＣ１とデータ信号のやりとりを行う入出力制御回路ＩＯ１からなる。また、図中にタスク管理リストＴＬ１を示している。タスク管理リストは、起動要求があり、実行を待つタスクを管理するためのリストであり、記憶領域上に保存され、例えばオペレーティングシステムなどによって管理されている。制御装置ＥＣＵは、いわゆる計算機であるから、図に示されない、計算機としての機能を果たすために必要なものを備えることは言うまでもない。制御装置ＥＣＵ２およびその他の制御装置の内部構成も、同様である。

実施例１のタスク管理リストＴＬは、少なくとも、その制御装置が実行すべきタスクについての、タスクＩＤ、デッドラインＤＬ、処理時間ＰＴ、通信レイテンシＣＬなどの情報がテーブルとして管理されている。以下の説明で用いないその他の情報は、ここでは省略されている。デッドラインＤＬは、タスクの実行が完了する要求時刻であるが、多くのタスクが周期性をもつため、タスクの周期をデッドラインとして扱っても良い。

同様に、制御装置ＥＣＵ２の内部には、ネットワークＮＷ１に接続してデータの通信を担当する通信装置ＣＯＭ２、タスクを処理する制御回路ＣＰＵ２、センサ群ＳＮ２及びアクチュエータ群ＡＣ２とデータ信号のやりとりを行う入出力制御回路ＩＯ２からなり、管理リストＴＬ２を記憶領域上に有する。

今、制御装置ＥＣＵ１の、タスク管理リストＴＬ１に、タスクＴ１、タスクＴ２、タスクＴ３の３つのタスクが管理され実行待ちにあったときに、タスクＴ４の起動要求が発生したとする。タスク管理リストＴＬ１における、デッドラインＤＬ、処理時間ＰＴ、通信レイテンシＣＬは、一定の時間幅を単位時間としてあらわしたもので、例えば制御回路ＣＰＵ１の１００クロック分の時間を１単位時間として用いることができる。また、デッドラインＤＬは、通常、タスクが起動された時刻からの時間で表されるが、実施例１では、理解しやすいように、現在の時刻を０と考えた値にすべて変換して表現している。

図２（ａ）−（ｄ）は、横軸に現在時刻を０としたときの時間をとって、各タスクが制御回路で処理される実施例１のスケジュールの態様を示す図である。（ａ）は、タスクＴ４の起動要求が発生する前のタスクＴ１，Ｔ２，Ｔ３のスケジュールを示している。スケジュールの連続する四角い箱の一つが１単位時間を示す。すなわち、タスクＴ１は３単位時間で、タスクＴ２は４単位時間で、そして、タスクＴ３は１０単位時間で、それぞれ、処理が完了すること、タスクＴ１，Ｔ２，Ｔ３の順にタスクが実行されることを示している。さらに、各タスクの処理時間の上辺に付した矢印は各タスクのデッドラインを示しており、タスクの連続する四角い箱が矢印より左で終わっていれば、そのタスクはデッドラインを守った実行が可能となることを意味する。図２（ａ）の３つのタスクは、全てデッドライン以内での実行が可能な状況である。タスクの実行順序を決める、いくつかの公知の技術があるが、ここでは、デッドラインが近いものから順に実行するアーリエスト・デッドライン・ファースト（ＥＤＦ）法を用いてスケジューリングを行っている。

実施例１では、実行中のタスクを中断して、他のタスクを実行するプリエンプトを許可する方法もあるが、以下の説明では実行中のタスクの中断を行わないノンプリテンプトを前提とするが、本発明はノンプリエンプトスケジュールに限定されるものではない。

次に、図２（ｂ）は、この状況の下で、新たにタスクＴ４の起動要求が発生したため、タスクＴ４を含めてＥＤＦ法でスケジューリングを行った状態を示す図である。タスクＴ４のデッドラインはＴ３より早いため、タスクＴ４を先に実行するようにスケジューリングされる。この結果、タスクＴ１，Ｔ２，Ｔ４はデッドライン以内に処理が完了するが、タスクＴ３は２０単位時間後のデッドライン時刻を守れなくなってしまう。

一方、図２（ｃ）は、同時点での制御装置ＥＣＵ２のタスクのスケジューリングを示す図である。制御装置ＥＣＵ２のタスクＴ５，Ｔ６，Ｔ７は十分余裕がある。そこで、新たに発生したタスクＴ４を制御装置ＥＣＵ２で実行させることを考える。タスクＴ４の処理に必要な時間は４単位時間であるので、処理時間のみに着目すれば、制御装置ＥＣＵ２で実行するのには、十分な余裕がある。しかし、図１のタスク管理リストＴＬ１を参照して明らかなように、タスクＴ４をネットワークで実行依頼を行い、結果を得るための通信のレイテンシは１０単位時間である。すなわち、処理時間ＰＴと通信レイテンシＣＬを合計すると１４単位時間となり、デッドラインＤＬの１２単位時間をオーバーしてしまう。したがって、タスクＴ４を制御装置ＥＣＵ２で実行させるとデッドラインを守れない。

この方法で、他の制御装置で実行可能なタスを調べると、タスクＴ３のみであることがわかる。図２（ｄ）は、制御装置ＥＣＵ２でタスクＴ３を実行することとしたときのタスクのスケジューリングを示す図である。制御装置ＥＣＵ２でタスクＴ５、Ｔ６を実行した後、Ｔ３を実行し、次いで、Ｔ７を実行すれば、全てのタスクをデッドラインを満足するように、タスクの処理ができる。すなわち、制御装置ＥＣＵ２でタスクＴ３を実行した後に、４単位時間の余裕があるから、タスクＴ３の実行結果をレイテンシの４単位時間を費やして制御装置ＥＣＵ１に転送し、アクチュエータＡＣ１を動作させても、デッドラインを満足できる。このとき、制御装置ＥＣＵ１は、タスクＴ１，Ｔ２およびＴ４を実行すれば良い。そこで、制御装置ＥＣＵ１に発生したタスクＴ４の起動要求に対応して、タスクＴ３を制御装置ＥＣＵ２で処理するため、制御装置ＥＣＵ１から制御装置ＥＣＵ２に、タスクＴ３を制御装置ＥＣＵ２で起動させる要求をネットワークのコマンドとして送信する。実施例１では、通信レイテンシは送信時のレイテンシと返信時のレイテンシの合計を示しているとする。また、実際は送信レイテンシと返信レイテンシは異なるが、説明を簡単化するために、どちらも等しいとした。この結果、制御装置ＥＣＵ１、制御装置ＥＣＵ２の全てのタスクがデッドラインを守り、リアルタイム性を保証したタスクの負荷分散が可能となる。

（実施例２）
図３は、各制御装置がデッドラインを守った処理を行うための負荷分散の他の実施例を説明するための図である。実施例２は、他の制御装置に処理を依頼するタスクの決定にデッドラインのみを用いる。実施例１に比べて、単純なしくみで判断を行う例である。各制御装置のタスク管理リストＴＬには、図１で説明したと同様にタスクＩＤごとに必要な情報が管理されているが、ここでは、デッドラインＤＬがタスクについての情報として管理されていれば足りるので、デッドラインＤＬが小さい順に並べられているとして表示した。また、別に、デッドラインＤＬのしきい値時間ＴＨ１が設定されている。しきい値時間は、メモリ、レジスタなどの記憶領域に保存されている。

実施例２では、各制御装置は、しきい値時間ＴＨ１より小さいデッドラインＤＬのタスクは、起動された制御装置で実行し、しきい値時間ＴＨ１より大きいデッドラインＤＬのタスクに対しては、起動された制御装置とは別の制御装置に実行を依頼することを可能とする。すなわち、デッドラインＤＬの小さいタスクは、無条件に起動された制御装置で実行することにし、デッドラインＤＬの大きいタスクに対しては、デッドラインＤＬが守れないと判断されたとき、起動された制御装置とは別の制御装置に実行を依頼する。これにより、図の例では、タスクＴ１およびタスクＴ２は起動制御装置のみで実行し、タスクＴ３以降は他の制御装置での実行が許可され、負荷分散のために利用することができる。個々のタスクで通信レイテンシやタスク処理時間は異なるが、例えば、通信レイテンシとタスク処理時間の和の最大値をしきい値時間とすることで、デッドラインを守った負荷分散が可能になる。

実際は、他の制御装置に実行依頼したタスクが、他の制御装置でデッドラインを守った処理が実行不可能と判断されることもあるが、構成が簡単で、他の制御装置に実行依頼するタスクの決定のためのオーバヘッドが小さいことが利点である。

通信レイテンシＣＬやタスク処理時間ＰＴは、ネットワークの負荷や制御回路の構成や使用状況、或いは実行フローが一定でないことなどで変化し、厳密に推定することは困難な場合がある。このような場合、ある程度のマージンを見込んだしきい値時間ＴＨ１を設定しておけば良いので、実施例２は実現が容易である。また、しきい値時間ＴＨ１は、予め設定して固定的に用いることもできるが、動的に変化させることも可能である。例えば、通信トラフィックを観測する手段を設け、ネットワーク負荷が大きく通信レイテンシが増大するときはしきい値時間を大きくし、逆の場合は、しきい値時間を小さくすることもできる。

（実施例３）
図４は、各制御装置のタスク管理リストＴＬに登録されているタスク処理時間ＰＴを過去の実績の履歴で更新する構成の概略を示す図である。タスク処理時間ＰＴは、考え方としては、タスクの実行フローを予測し、そのフローを実行するための実行命令サイクル数とすることができる。しかし、実施例２の説明で触れたように、状況に応じて変化するために厳密に推定することは困難な場合がある。そこで、実施例３では、タスク処理時間計測手段ＣＴ１を設け、タスクが実行される際の時間を計測し、実績に応じて更新するもの
とする。

タスク処理時間計測手段ＣＴ１には、タスクの開始時を知らせる信号Ｓｔ１が入力されると同時に、タスク処理時間計測手段ＣＴ１内部のカウンター（図示しない）のカウントを開始し、タスクの終了を知らせる信号Ｅｎ１が入力されるとカウンターを停止する。また、割り込みなどによりタスクの中断が発生した場合にカウンターを一時停止するために、一時停止信号Ｐａと再開信号Ｒｅが入力されている。タスク実行に費やした正味のサイクル数を計測し、タスクの処理時間ＰＴとして、タスク管理リストＴＬに登録されているタスク処理時間ＰＴを更新して、記憶領域ＭＥＭに保管する。これにより、例えば、過去の最大処理時間や平均処理時間をタスク情報として用いることが可能になる。

（実施例４）
図５は、各制御装置のタスク管理リストＴＬに登録されている通信レイテンシＣＬを過去の履歴で更新する構成の概略を示す図である。通信レイテンシＣＬは、転送データ量などから静的に推定することも可能であるが、実施例２の説明で触れたように、通信トラフィックの混雑状況に応じて変化するために厳密に推定することは困難な場合がある。

そこで、実施例４では、通信レイテンシ計測手段ＣＴ２を設け、通信装置ＣＯＭ１により、他の制御装置にタスクの実行を依頼し、実行された結果の返信を受信する際の、通信コマンド投入から結果の受信までの時間を計測する。通信レイテンシ計測手段ＣＴ２は、通信装置ＣＯＭ１から通信コマンド投入を知らせる信号Ｓｔ２が入力されると同時に、通信レイテンシ計測手段ＣＴ２内部のカウンターのカウントを開始し、結果の返信があったことを知らせる信号Ｅｎ２が入力されるとカウンターを停止する。これにより、通信を用いた他の制御装置でのタスク実行に費やした正味のサイクル数を計測し、その時刻からタスクの処理時間を減じた値を通信レイテンシＣＬとして管理リストＴＬに登録されている通信レイテンシＣＬを更新し、記憶領域ＭＥＭに保管する。これにより、例えば、過去の最大通信レイテンシや平均通信レイテンシをタスク情報として用いることが可能になる。

（実施例５）
図６は、各制御装置のタスク管理リストＴＬに登録されている通信レイテンシＣＬをタスクのデータアクセス量と通信の待ち時間から更新する構成の概略を示す図である。通信装置ＣＯＭ１が通信の要求コマンドを投入した際には、すでに他の通信パケットがネットワークを使用中である、あるいは、より優先度の高い他の通信要求が待機している場合など、必ずしも通信が即時実行されるわけではない。通信の要求コマンドに応じて通信が開始されるまでには待ち時間が存在するのが通常である。

実施例５では、タスク管理リストＴＬは、図１で説明したデータの他に、メモリアクセス量ＭＡおよび入力装置を通じてアクセスする入力データ量ＩＡが情報として備えられるものとしている。ここで、メモリアクセス量ＭＡおよび入力データ量ＩＡは、他のデータが単位時間であったのに対し、扱うデータの大きさを示すものとしている。例えば、タスクＴ１はメモリアクセス量ＭＡは８Ｂｙｔｅ、入力データ量ＩＡは１６ｂｉｔをアクセスして処理を行うことを示している。

通信待ち時間計測手段ＣＴ３は、通信装置ＣＯＭ１から通信要求コマンドが投入されたことを示す信号Ｓｔ３が入力されてから内部のカウンターを開始し、通信が開始したことを示す信号Ｅｎ３が入力されるとカウンターを停止する。これにより通信の待ち時間ＷＴ１を求め、通信レイテンシ計算手段ＣＣＬ１に入力する。これに合わせ、通信レイテンシ計算手段ＣＣＬ１はメモリアクセス量ＭＡおよび入力データ量ＩＡから、タスクの起動依頼に伴って転送すべきデータ量を求め、それに要する転送時間を計算する。さらに、通信待ち時間ＷＴ１を加算することで通信レイテンシを計算し、タスク管理リストＴＬ４の通
信レイテンシＣＬに新しい値を書き込む。

通信待ち時間ＷＴ１は、常に計測することも可能であるし、定期的な計測でも構わない。これにより、通信待ち時間と転送データ量を反映した通信レイテンシを用いることができる。実施例５ではデータアクセス量と通信の待ち時間をどちらも考慮に入れた通信レイテンシ計算をおこなっているが、どちらかが大きく支配的な場合は、片方のみを利用する構成でもよい。

（実施例６）
次に、各制御装置の処理能力が同一でない場合の実施例について説明する。実施例１の状況で仮に制御装置ＥＣＵ２が制御装置ＥＣＵ１の倍の動作周波数で動作すると仮定する。図７は、横軸に現在時刻を０としたときの時間をとって、各タスクが制御回路で処理される実施例６のスケジュールの態様を示す図である。

実施例６の場合は、制御装置ＥＣＵ１でのタスク処理時間が制御装置ＥＣＵ２では半分になる。例えば、タスク依頼元である制御装置ＥＣＵ１で、依頼先が制御装置ＥＣＵ２であると決定した際に、依頼先の制御装置と自己の性能比からタスクＴ３の処理時間を半分の５単位時間として制御装置ＥＣＵ２に伝える方法や、逆に制御装置ＥＣＵ１はタスク処理時間をそのまま１０単位時間であるとして、依頼先の制御装置ＥＣＵ２に伝え、制御装置ＥＣＵ２で、依頼元の制御装置と自己の性能比からタスク処理時間を半分の５単位時間として扱う方法が取りうる。いずれの結果においても、制御装置ＥＣＵ２においては、タスクＴ３の処理時間は５単位時間として扱われ、図７に示すスケジューリングとなる。

図８は、制御装置ＥＣＵ間でタスクの実行依頼を行う通信パケットの例を説明する図である。通信パケットは、パケット開始を示すＳＯＰ、送信元のノード、つまり、どの制御装置から送信されたかを示すＮＯＤＥ−ＩＤ、実行を依頼するタスクを示すＴＡＳＫ−ＩＤ、さらにタスクのデッドラインＤＬ、処理時間ＰＴ、実行に必要なデータ、パケットの終了を示すＥＯＰからなる。デッドラインＤＬは依頼元制御装置と依頼先制御装置に共通の絶対時刻で表現するか、または、パケットが依頼先制御装置に到着する時間を基準に相対時刻で表現する。また、前述したように、返信に要する時間を差し引いてデッドラインは変更されている。データ量はタスクによって異なるために、パケットの長さが固定されており、１つのパケットで送信できない場合は、データが継続することを知らせるフラグをパケットに挿入し、複数のパケットを使用することで対応できる。

（実施例７）
図９は、タスクの起動要求が発生してから、負荷分散によるタスク実行を行う一連のフローの例を説明する図である。図９では新規タスクが起動された制御装置１の処理（ステップＰ９００〜Ｐ９１２）と、これに対応した他の制御装置の処理（ステップＰ１００１〜ステップＰ１００９）が示されている。また、制御装置間の通信（ＢＣ９１、ＢＣ９２、ＭＳ９１、ＭＳ９２）を太い矢印で示している。

制御装置ＥＣＵ１でタスク起動要求が発生（ステップＰ９０１）したら、タスク管理リストに新規タスクを追加（ステップＰ９０２）し、全てのタスクがデッドラインを守って実行を完了できるかを判定する（ステップＰ９０３）。もし、可能であればタスク管理リストに従い、タスクを実行する（ステップＰ９００）。不可能であると判定された場合、タスク管理リストで管理されているタスクの中から他の制御装置ＥＣＵに実行依頼するものが存在するかを調べる（ステップＰ９０４）。ここでは、例えば実施例１や実施例２に示したようにタスク実行時間と通信レイテンシ、タスクのデッドラインを考慮して他の制御装置で実行可能なタスクを選択する。選択されたタスクは管理リストから削除される（ステップＰ９０５）。他の制御装置ＥＣＵで実行可能なタスクが存在しない場合には、タ
スク実行放棄処理（ステップＰ９０６）を行う。タスク実行放棄処理は、例えば、予め決められたタスクの重要度に従い、最も重要度の低いタスクを管理リストから削除するなどの方法がある。タスク実行放棄処理では、さらに、放棄するタスクを管理リストから削除する。

次に、更新された管理リストで残り全てのタスクがデッドラインを守って実行を完了できるかを判定する（ステップＰ９０７）。Ｎｏなら、可能と判定されるまで、ステップＰ９０４に戻り、他の制御装置ＥＣＵに実行依頼するタスクを選択し続ける。ステップＰ９０７がＹｅｓなら、タスク管理リストに従い、タスクを実行する（ステップＰ９００）とともに、他の制御装置ＥＣＵに実行依頼するタスクとして選択したタスクについて、以下の処理を行う。

タスクがデッドライン以内で実行可能であるかどうか他の制御装置ＥＣＵに問い合わせを行う（ステップＰ９０８）。ここで、予め定められた制御装置ＥＣＵの順に１つずつ問い合わせる方法やブロードキャストを用いて一度に全ての制御装置に問い合わせる方法が選択できるが、実施例７では、図中太い矢印で示したブロードキャストＢＣ９１により、他の制御装置ＥＣＵに問い合わせるものとする。問い合わせの方法は、例えば図８に示したパケットを送ってもよいが、問い合わせの段階では、データは送信する必要がないために、図８のパケット構成からデータを除いた情報を送信するものとするのが良い。

受信した制御装置ＥＣＵはデッドラインと処理時刻および自己のタスク管理リストを参照し、依頼されたタスクがデッドライン内に実行可能かどうか判定（ステップＰ１００１）する。実行不可能な場合は返信せずに、通常処理（ステップＰ１００２）に戻る。実行可能であると判定した場合は、その旨返信することになるが、実施例７ではブロードキャストを用いて全ての制御装置ＥＣＵに問い合わせたために、複数の制御装置ＥＣＵが同時に実行可能であると判定した場合は、同時に複数の返信を行う可能性がある。ここでは、コントローラ・エリア・ネットワーク（通称ＣＡＮと表記される）を用いている例についてこの問題への対応を説明する。ＣＡＮでは同時の送信に対しては、ノードの優先度に従い通信路を与える仕組みで衝突を回避している。優先度が低いノードは、他の優先度の高いノードからの送信を検知した場合には、送信を中断し、通信路が確保できるまで待つ。そこで、他の制御装置から実行可能のメッセージが返信されたかどうか判定（ステップＰ１００３）する。他の制御装置ＥＣＵが実行可能のメッセージを返信していれば、これを受信して、通常処理（ステップＰ１００４）に戻る。メッセージの受信が無い場合に限り実行可能であるというブロードキャストＢＣ９２が全制御装置ＥＣＵに送信される（ステップＰ１００５）。実行可能の返信を送信するために、通信路が空くのを待っていた制御装置ＥＣＵは、他の制御装置ＥＣＵの実行可能のブロードキャストＢＣ９２を受信した場合、通信待ちを解除して通常処理（ステップＰ１００３，Ｐ１００４）に戻る。

実行可能の返信を送信した後、一定時間以内に実行依頼があったか否か判定（ステップＰ１００６）し、実行依頼があったときは依頼されたタスクを実行（ステップＰ１００７）し、無かったときは通常処理（ステップＰ１００８）に戻る。依頼されたタスクを実行したときは、結果のメッセージＭＳ９２を制御装置ＥＣＵ１に送信（ステップＰ１００９）し、通常処理（ステップＰ１０１０）に戻る。

制御装置ＥＣＵ１では、実行可能であるというブロードキャストＢＣ９２が所定時間内に受信できたか判定（ステップＰ９０９）し、所定時間内の受信であったときは、実行可能であると返信した制御装置ＥＣＵに対して、実行依頼のメッセージＭＳ９１を送信（ステップＰ９１０）する。依頼先から結果のデータがメッセージＭＳ９２で返信されてきたら、データをメモリに格納や、出力信号としてアクチェータの制御に用いるなどの返信データ処理（ステップＰ９１２）を行う。一方、所定時間内の受信でなかった場合は、タス
ク実行放棄処理（ステップＰ９１１）を行う。

制御装置ＥＣＵ１の処理の、他の制御装置ＥＣＵへの実行問い合わせ（ステップＰ９０８）、返信判定（ステップＰ９０９）、実行依頼（ステップＰ９１０）、実行放棄（ステップＰ９１１）、返信データ処理（ステップＰ９１２）の一連の処理は、他の制御装置ＥＣＵに実行依頼すべきタスクとして選択された全てのタスクについて実行される。

（実施例８）
図１０は、タスクの起動要求が発生してから、負荷分散によるタスク実行を行う一連の他のフローの例を説明する図である。実施例８も、実施例７と同様、更新された管理リストで残り全てのタスクがデッドラインを守って実行を完了できるかを判定する（ステップＰ９０７）し、Ｎｏなら、可能と判定されるまで、ステップＰ９０４に戻り、他の制御装置ＥＣＵに実行依頼するタスクを選択し続ける。ステップＰ９０７がＹｅｓなら、タスク管理リストに従い、タスクを実行する（ステップＰ９００）とともに、他の制御装置ＥＣＵに実行依頼するタスクとして選択したタスクについて、以下の処理を行う。

実施例７では、タスクがデッドライン以内で実行可能であるかどうかをブロードキャストで問い合わせたのに対し、実施例８では実行を依頼するタスクのデッドラインまでの時間における負荷状況を制御装置ＥＣＵを特定してメッセージＭＳ９３で問い合わせる（ステップＰ９１３）点で実施例７と相違する。例えば、ある時間までの制御装置ＥＣＵの空き時間を問い合わせる。図１の例では、タスクＴ３のデッドラインから返信レイテンシを差し引いた時刻１６までの負荷状況を問い合わせる。これに対応して、問い合わせを受けた制御装置ＥＣＵは、自分の負荷状況をブロードキャストＢＣ９４で返信（ステップＰ１０１０）する。図１の例では、制御装置ＥＣＵ２では、タスクＴ７を時刻１７から開始することにより１０単位時間の空き時間が確保できることを返信する。返信を受けた制御装置ＥＣＵ１側で、問合せ先の制御装置ＥＣＵでのタスク実行可能性を判定（ステップＰ９１４）する。図１０の例では、負荷状況の問い合わせ先は予め定められた制御装置ＥＣＵの順に決められ、実行可能な制御装置ＥＣＵが見つかるまで繰り返される。煩雑化を避けるために、図では省略したが、問い合わせる制御装置数の限度を設定しておき、限度に達するか全ての制御装置ＥＣＵに問い合わせても実行可能な制御装置ＥＣＵが見つからない場合には、タスク実行を放棄するようにするのが実用的である。負荷状況の応答から実行可能な制御装置ＥＣＵ見つかったときは、返信のあった制御装置ＥＣＵにタスクの実行を依頼（ステップＰ９１０）する。以下、依頼を受けた制御装置ＥＣＵの依頼されたタスクへの対応は、タスクの実行結果を制御装置ＥＣＵ１に報告する点も、実施例7と同様である。

また、別の方法として、各制御装置ＥＣＵが共通にアクセスできる記憶ユニットをネットワークＮＷ１に設け、各制御装置ＥＣＵが、所定の周期で負荷状況を定期的に書き込んだデータベースを構成しておくことも可能である。このようなデータベースがあれば、制御装置ＥＣＵ１は、このデータベースにアクセスして情報を入手でき、タスクの処理の依頼の可否を決定できる。したがって、実施例７のように、他の制御装置ＥＣＵに実行可否を問い合わせることや、実施例８のように、他の制御装置ＥＣＵに負荷状況を問い合わせる必要がない。

本実施例および実施例７では、全てのタスクがデッドラインを守って実行を完了できるか判定し、不可能であると判定された場合に、他の制御装置でタスクを実行する例を示している。本発明は、必ずしもデッドラインを違反する場合のみでなく、制御装置の負荷を平準化する目的で実施することが可能である。例えば、実施例７および実施例８の説明図である図９および図１０のフローにおいて、全てのタスクがデッドラインを守って実行を完了できるかを判定する（ステップＰ９０３およびステップＰ９０７）処理を、全てのタ
スクを実行した場合のＣＰＵの負荷率を計算し、例えば７０％などの予め定めた負荷率を越えるかどうかを判定する処理に置き換えることで、平準化を目的に本発明の負荷分散方法を実施することができる。ＣＰＵを平準化して負荷率のピーク値を抑えることにより、従来よりも性能が低いＣＰＵを用い、システムのコストを低減することができる。

（実施例９）
図１１は直結信号線とネットワークを併用した制御システムを示す図である。電子制御装置ＥＣＵ１は、制御回路ＣＰＵ１、入出力制御回路ＩＯ１、センサ群ＳＮ１及びアクチュエータ群ＡＣ１から成る。センサ群ＳＮ１から入出力制御回路ＩＯ１にセンサ情報が入力され、入出力制御回路ＩＯ１からアクチュエータ群ＡＣ１にアクチュエータ制御情報が出力される。制御回路ＣＰＵ１と入出力制御回路ＩＯ１は直結信号線ＤＣ１によって接続されている。更に制御回路ＣＰＵ１と入出力制御回路ＩＯ１はネットワークＮＷ１に接続されている。電子制御装置ＥＣＵ２及びＥＣＵ３も同様な構成となっている。

電子制御装置ＥＣＵ４は、入出力制御回路ＩＯ４、センサ群ＳＮ４及びアクチュエータ群ＡＣ４から成る。センサ群ＳＮ４から入出力制御回路ＩＯ４にセンサ情報が入力され、入出力制御回路ＩＯ４からアクチュエータ群ＡＣ４にアクチュエータ制御情報が出力される。更に入出力制御回路ＩＯ４はネットワークＮＷ１に接続されている。実施例９の電子制御装置ＥＣＵ４は他の電子制御装置ＥＣＵ１、ＥＣＵ２、ＥＣＵ３とは異なり、センサ群及びアクチュエータ群から独立した制御回路を持っていない。

制御回路ＣＰＵ４はネットワークＮＷ１に接続されているどの入出力制御回路とも直結信号線によって接続されていない独立した制御回路である。

次に、実施例９の代表的な動作を説明する。センサ情報に基づいてアクチュエータ制御情報を生成する処理を制御タスクと呼ぶことにする。この時、センサ群ＳＮ１とアクチュエータ群ＡＣ１が関与する制御タスクは多数あるのが一般的である。電子制御装置ＥＣＵ１では、通常は入出力制御回路ＩＯ１がセンサ群ＳＮ１から受け取ったセンサ情報を直結信号線ＤＣ１経由で制御回路ＣＰＵ１に送る。制御回路ＣＰＵ１は送られたセンサ情報に基づいて制御タスクを実行して、生成したアクチュエータ制御情報を直結信号線ＤＣ１経由で入出力制御回路ＩＯ１に送る。入出力制御回路ＩＯ１は送られた制御情報をアクチュエータ群ＡＣ１に送る。そして、アクチュエータ群ＡＣ１は受け取った制御情報に基づいて動作する。或いは、入出力制御回路ＩＯ１が単純な入出力制御だけでなく制御タスクの処理能力があって、制御回路ＣＰＵ１の助けを必要としない制御タスクを処理する場合は、入出力制御回路ＩＯ１はセンサ群ＳＮ１から受け取ったセンサ情報に基づいて制御タスクを実行し、生成したアクチュエータ制御情報をアクチュエータ群ＡＣ１に送り、アクチュエータ群ＡＣ１は受け取った制御情報に基づいて動作する。

従来は、この多数の制御タスクを全て電子制御装置ＥＣＵ１で処理する必要があり、それに必要な能力を電子制御装置ＥＣＵ１に持たせていた。実施例９では電子制御装置ＥＣＵ１が全ての制御タスクを処理できない場合は、入出力制御回路ＩＯ１はネットワークＮＷ１経由で他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４に、センサ群ＳＮ１から受け取ったセンサ情報を送り、送られた側はそのセンサ情報に基づいてアクチュエータ制御情報を生成して、ネットワークＮＷ１経由で入出力制御回路ＩＯ１に送る。入出力制御回路ＩＯ１は送られた制御情報をアクチュエータ群ＡＣ１に送る。そして、アクチュエータ群ＡＣ１は受け取った制御情報に基づいて動作する。

電子制御装置ＥＣＵ２及びＥＣＵ３も電子制御装置ＥＣＵ１と同様な動作をする。一方、電子制御装置ＥＣＵ４では、入出力制御回路ＩＯ４はセンサ群ＳＮ４から受け取ったセンサ情報に基づいて制御タスクを実行し、生成したアクチュエータ制御情報をアクチュエ
ータ群ＡＣ４に送り、アクチュエータ群ＡＣ４は受け取った制御情報に基づいて動作する。また、入出力制御回路ＩＯ４に制御タスク処理能力がないか足りない場合は、他の電子制御装置ＥＣＵ１、ＥＣＵ２及びＥＣＵ３と同様にネットワークＮＷ１経由で他の電子制御装置ＥＣＵ１、ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４を使って制御タスクを処理する。

電子制御装置ＥＣＵ１が全ての制御タスクを処理できない場合、どの制御タスクをネットワークＮＷ１経由で他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４に振り分けるかを判断する必要がある。一般に、制御回路は複数の制御タスクに優先度を付けて優先度の高いタスクから処理する。優先度が同じであれば時間的に早く受け付けたタスクを先に処理する。したがって、処理可能な範囲で優先度の高いタスクを制御回路ＣＰＵ１で処理し、残りの優先度の低いタスクを他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４に振り分ければ、制御タスクの振り分けが可能である。また、制御タスクにはアクチュエータ群を適切なタイミングで制御するために、センサ情報を受け取ってから制御タスクを完了するまでの応答時間に制限がある。この応答時間制限は制御タスク毎に様々である。ネットワーク経由での情報の遣り取りは直結信号線による遣り取りより時間がかかる。したがって、応答時間制限によって完了すべき時刻の近い制御タスクは制御回路ＣＰＵ１で処理し、残りの完了すべき時刻の比較的遅いタスクを他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４に振り分けると、応答時間制限を守り易くなる。この考えに基づいた実施例１〜９の負荷分散方法を用いることにより、リアルタイム性を保証した負荷分散が可能になる。

また、実施例９においては、他の制御装置にタスクの実行を依頼する通信パケットは、図８の例をもちいることも出来るが、入出力制御回路がネットワークに接続しているため、タスク起動要求パケットでは、入力データの送信を行わず、タスクを実行する制御装置がネットワークを通じて、センサからの入力信号をアクセスする方法を採ることも出来る。また、ネットワーク負荷の軽減が重要な場合は、制御回路の処理負荷に比べてネットワーク負荷が重い処理、例えば制御回路内での演算量に比べてデータ転送量が多いタスクは制御回路ＣＰＵ１で処理し、残りのデータ転送量の比較的少ないタスク他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４に振り分けると、負荷分散の際のネットワーク負荷の軽減が図れる。タスクのデータ転送量は、実施例５の説明で用いた図６に示すタスク管理リストの情報から求めることが可能である。

自動車等の制御装置では、製品化前に処理すべき制御タスクが決まっている。しかし、状況に応じて各制御タスクを実行するタイミングや各制御タスクの処理量が変化する。したがって、全ての状況において制御が破綻しないように製品化前に最適化を行う。このため、状況に応じた最適な負荷分散ルールを事前に決めておくことが可能である。或いは、製品に依存しない汎用的な負荷分散ルールを作って、ＯＳに組み込んだりミドルウェアで実装したりすれば、製品化前の最適化において、負荷分散の人手最適化が不要となる。この結果、システム設計者はどの制御回路で制御タスクが実行されるかを意識しなくても制御プログラムを書くことが可能となる。システム構成は、製品化後でも機能増強や部品の故障によって変化する可能性がある。このため、システム構成に応じた負荷分散ルールの自動最適化をできるようにしておくと、負荷分散を常に最適な状態に保つことができる。また、多数の制御タスクの負荷も状況に応じて変化するので、負荷分散ルールによるオンデマンドの負荷分散と、状況の変化に応じた負荷分散ルールの自動最適化とを使い分けることにより、更に最適な負荷分散を達成できる。

次に、実施例９の耐故障性について説明する。実施例９ではアクチュエータ群ＡＣ１の制御タスクに必ず必要なのはアクチュエータ群ＡＣ１自身とセンサ群ＳＮ１及び入出力制御回路ＩＯ１であるので、これらが制御タスク処理に支障が出るほど壊れてしまった場合
はアクチュエータ群ＡＣ１の制御タスクは実行不可能になる。このため、これらの部品は耐故障性の要求レベルに応じて部品レベルでの二重化等の耐故障性向上策を施す。入出力制御回路ＩＯ１が、ある制御タスクを処理する能力を有しない場合は、通常は更に直結信号線ＤＣ１及び制御回路ＣＰＵ１を使用する。直結信号線ＤＣ１の故障時にはネットワークＮＷ１経由で入出力制御回路ＩＯ１と制御回路ＣＰＵ１を接続して処理を継続することが可能である。或いは、直結信号線ＤＣ１又は制御回路ＣＰＵ１が故障した場合、実施例９では前述の電子制御装置ＥＣＵ１が全ての制御タスクを処理できない場合と同様に、ネットワークＮＷ１経由で他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４で制御タスクを実行することにより、制御を継続することが出来る。

この時、ネットワークＮＷ１及び他の電子制御装置ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、又は制御回路ＣＰＵ４の負荷が増大するが、多数の電子制御装置が接続されたシステムでは相対的な負荷増大は許容範囲内に抑えることが可能である。システム全体に能力の余裕を持たせておけば故障前と同一の処理が継続できる。例えば、制御回路一個の故障で１０％能力が低下するならば、あらかじめ１０％高い能力を持たせておけばよい。また、効率を重視して能力に余裕を持たせない場合でも、快適性や燃費、排気ガスの清浄度といった緊急時には我慢できる項目の質を下げることによって処理量を軽減すれば処理を継続できる。尚、自動車等の制御システムでは各部品の信頼性は十分高く同時に二つ以上の部品が故障する場合を想定する必要がないことが一般的である。例えば１０万時間に一度壊れる可能性のある部品が一時間以内に二つ故障する確率は１００億時間に１回である。

従来システムでは、制御回路ＣＰＵ１と入出力制御回路ＩＯ１とが一体になっていたり、分離されていても入出力制御回路ＩＯ１が制御回路ＣＰＵ１経由でネットワークＮＷ１に接続されていたりして、耐故障性向上には直結信号線ＤＣ１及び制御回路ＣＰＵ１を含めた多重化が必要であった。同様に、他の電子制御装置ＥＣＵ２、ＥＣＵ３においても耐故障性が実現できる。また、電子制御装置ＥＣＵ４は耐故障性を要するアクチュエータ群ＡＣ４、センサ群ＳＮ４及び入出力制御回路ＩＯ４のみから成るので二重化等の耐故障性向上策が必要である。

実施例９ではネットワークＮＷ１は多重化していない。ネットワークＮＷ１が故障した場合、各電子制御装置ＥＣＵ１〜ＥＣＵ４はネットワークＮＷ１経由の負荷分散には頼らずに制御タスクを実行しなければならない。通常動作時はネットワークＮＷ１経由の負荷分散を行わず、故障時にネットワークＮＷ１経由の負荷分散によって処理を継続するシステムであれば、ネットワークＮＷ１と電子制御装置の同時故障のような確率の極めて低い多重故障以外の故障に対応できる。また、効率を重視して能力に余裕を持たせない場合は、ネットワークＮＷ１経由の負荷分散に頼っていた分だけ低い性能で実行できるように、緊急時には我慢できる項目の質を下げることによって処理量を軽減すれば処理を継続できる。

制御システムの高度化に伴い制御回路ＣＰＵ１〜ＣＰＵ４は高性能化、高機能化が必要となっており、これらと、これらを接続する直結信号線ＤＣ１〜ＤＣ４及びネットワークＮＷ１を多重化せずにシステムの耐故障性を実現できることはシステムの効率化向上に大きく寄与する。

実施例９ではアクチュエータ群ＡＣ１の制御タスクの負荷分散制御は、通常時は制御回路ＣＰＵ１又は入出力制御回路ＩＯ１が行う。入出力制御回路ＩＯ１は耐故障性向上のために二重化等が必要になる回路なので、出来るだけ能力を制限して小さな回路とすることが望ましい。負荷分散制御を制御回路ＣＰＵ１で行えば入出力制御回路ＩＯ１の小型化に寄与する。この場合、制御回路ＣＰＵ１故障時の負荷分散は、他の電子制御装置ＥＣＵ２〜ＥＣＵ４で行う必要がある。そこで、入出力制御回路ＩＯ１が制御回路ＣＰＵ１の故障
を検出できるようにして、制御回路ＣＰＵ１の故障した場合は、入出力制御回路ＩＯ１があらかじめ定められたルールで選択した他の電子制御装置ＥＣＵ２〜ＥＣＵ４に制御タスク処理を要求し、要求を受けた電子制御装置は前記制御タスク処理を自分の管理する制御タスクに加える。この負荷分散制御の移管は他の電子制御装置ＥＣＵ２〜ＥＣＵ４の一つに集中的に移管する方式と分散して移管する方式が考えられる。そして、負荷分散ルールに従って最初の制御タスク実行回路となる制御回路に移管することが望ましい。一方、入出力制御回路ＩＯ１で負荷分散制御を行った場合は入出力制御回路ＩＯ１の回路規模は増大するが、制御回路ＣＰＵ１故障時に負荷分散制御を他の電子制御装置ＥＣＵ２〜ＥＣＵ４に移管する必要がなくなる。

（実施例１０）
図１２は、図１１の構成のネットワークを二重化した例を示す図である。図１１の構成ではネットワーク経由で情報を遣り取りして複数の電子制御装置が協調して動作している場合に、ネットワークが故障すると処理を継続できない。このため、ネットワーク故障時には協調制御を必要としないレベルまで制御の質を下げる必要がある。図１２のように第二のネットワークＮＷ２を追加してネットワーク接続を二重化すれば一方のネットワークが故障してもネットワークを使用する処理を継続できる。しかしながら、単純なる二重化では耐故障性は向上するが、ハードウェア量が増えて効率が低下する。

図１３は、実施例１０の変形例として、図１１のシステムのネットワークを分割した例を示す図である。図１２の構成のネットワークと比較して、ネットワークを二重化した点では、図１２の概念と同じであるが、ネットワークＮＷ１及びＮＷ２に分割して、ネットワークＮＷ１に制御回路ＣＰＵ１及びＣＰＵ３並びに入出力制御回路ＩＯ２及びＩＯ４を接続し、ネットワークＮＷ２に制御回路ＣＰＵ２及びＣＰＵ４並びに入出力制御回路ＩＯ１及びＩＯ３を接続している。図１２の構成ではネットワークが対称であったため、ネットワーク経由の負荷分散に特に制約はなかった。図１３の構成では電子制御装置ＥＣＵ１の負荷分散先は、入出力制御回路ＩＯ１からネットワークＮＷ２経由で繋がる制御回路ＣＰＵ２及びＣＰＵ４が望ましい。しかしながら、入出力制御回路ＩＯ１から、直結信号線ＤＣ１、制御回路ＣＰＵ１、及びネットワークＮＷ１経由、又は、ネットワークＮＷ２、入出力制御回路ＩＯ３、及び直結信号線ＤＣ３経由で、制御回路ＣＰＵ３とも繋がっているので、制御回路ＣＰＵ３への負荷分散も可能である。また、入出力制御回路ＩＯ２〜ＩＯ４が単純な入出力制御だけでなく制御タスクの処理能力があって電子制御装置ＥＣＵ１の負荷分散先となる場合は、入出力制御回路ＩＯ３とはネットワークＮＷ２経由で、入出力制御回路ＩＯ２及びＩＯ４とは制御回路ＣＰＵ３と同様な経路で情報の遣り取りを行うことが出来る。

直結信号線ＤＣ１又は制御回路ＣＰＵ１が故障した場合には、これらを経由する経路は使用不能となるが、他の経路によって制御回路ＣＰＵ２〜ＣＰＵ４又は入出力制御回路ＩＯ２〜ＩＯ４による制御回路ＣＰＵ１のバックアップが可能である。ネットワークＮＷ２が故障した場合、入出力制御回路ＩＯ１は直結信号線ＤＣ１及び制御回路ＣＰＵ１経由でネットワークＮＷ１に接続できる。逆に、ネットワークＮＷ１が故障した場合、制御回路ＣＰＵ１は直結信号線ＤＣ１及び入出力制御回路ＩＯ１経由でネットワークＮＷ２に接続できる。直結信号線ＤＣ１経由の迂回路は複数のネットワークを経由する迂回路より単純かつ高速であるため、故障時のバックアップ回路としては十分である。他の電子制御装置ＥＣＵ２〜ＥＣＵ４の負荷分散及びバックアップも同様に実現できる。

（実施例１１）
図１４は、図１１のシステムのネットワークを図１３とは異なる方式で分割した実施例を示す図である。ネットワークＮＷ１及びＮＷ２に分割して、ネットワークＮＷ１には制御回路ＣＰＵ１〜ＣＰＵ４を接続し、ネットワークＮＷ２には入出力制御回路ＩＯ１〜Ｉ
Ｏ４を接続している。実施例１１では、電子制御装置ＥＣＵ１の負荷分散先が制御回路ＣＰＵ２〜ＣＰＵ４である場合は、入出力制御回路ＩＯ１から、直結信号線ＤＣ１、制御回路ＣＰＵ１、及びネットワークＮＷ１経由、又は、ネットワークＮＷ２、入出力制御回路ＩＯ２〜ＩＯ４、及び直結信号線ＤＣ２〜ＤＣ４経由で繋がっている。負荷分散先が入出力制御回路ＩＯ２〜ＩＯ４の場合はネットワークＮＷ２経由で繋がっている。また、直結信号線ＤＣ１又は制御回路ＣＰＵ１が故障した場合には、これらを経由する経路は使用不能となるが、他の経路によって制御回路ＣＰＵ２〜ＣＰＵ４又は入出力制御回路ＩＯ２〜ＩＯ４によるバックアップが可能である。他の電子制御装置ＥＣＵ２〜ＥＣＵ４の負荷分散及びバックアップも同様に実現できる。

（実施例１２）
図１５は、図１１のシステムのネットワーク接続を削減した本実施例を示す図である。図１１の構成の直結信号線ＤＣ１〜ＤＣ３を持つ制御回路ＣＰＵ１〜ＣＰＵ３のネットワークＮＷ１への接続を削減している。ネットワークＮＷ１を使用しない場合の動作は図１１のシステムと同様である。ネットワークＮＷ１経由で制御回路ＣＰＵ１〜ＣＰＵ３を使用する場合は、図１１のシステムのように制御回路ＣＰＵ１〜ＣＰＵ３を直接ネットワークＮＷ１へ接続する代わりに、入出力制御回路ＩＯ１〜ＩＯ３及び直結信号線ＤＣ１〜ＤＣ３経由でネットワークＮＷ１に接続する。図１１のシステムに比べると、直結信号線ＤＣ１〜ＤＣ３の故障時に対応する制御回路ＣＰＵ１〜ＣＰＵ３が使用できなくなるが、制御回路ＣＰＵ１〜ＣＰＵ３の故障に備えた余裕を持たせておけば問題ない。効率を重視して能力に余裕を持たせない場合には、直結信号線ＤＣ１〜ＤＣ３の故障確率分、制御の質を低下させなければならない確率が上がるが、ネットワーク接続を削減した分の効率が向上するので、効率を重視したシステムに向いている。

（実施例１３）
図１６は、図１５のシステムのネットワーク接続を二重化した実施例を示す図である。図１５の構成に第二のネットワークＮＷ２を追加して、ネットワーク接続を二重化した構成である。こうすれば、一方のネットワークが故障しても、他のネットワークを使用できるので、ネットワークを使用する処理を継続できる。また、入出力制御回路ＩＯ１〜ＩＯ４が直結信号線ＤＣ１及び制御回路ＣＰＵ１を経由せずに直接ネットワークＮＷ１及びＮＷ２に接続されているので、直結信号線ＤＣ１及び制御回路ＣＰＵ１を多重化しなくても耐故障性を実現できる。

（実施例１４）
図１７は、図１１に示す実施例９の直結信号線とネットワークを併用した制御システムのネットワークＮＷ１に、実施例８で言及した記憶ユニットＭＥＭＵを接続した例である。この記憶ユニットＭＥＭＵに、各制御装置ＥＣＵが共通にアクセスして所定の周期で負荷状況を定期的に書き込んだデータベースを構成しておけば、各制御装置ＥＣＵは、このデータベースにアクセスして他の制御装置ＥＣＵの負荷状況の情報を入手でき、タスクの処理の依頼の可否を決定できる。この記憶ユニットＭＥＭＵは、実施例１０-１３のネットワークＮＷ１、ＮＷ２にも設けることができることは当然である。

（実施例１５）
以上述べてきた実施例のネットワークの物理的な配線は電気信号を伝播する伝送線路で構成することも可能であるし、光伝送線路で構成することも可能である。さらに、無線でネットワークを構成することも可能である。

図１８は、無線によるネットワークの構成例を示す図である。無線でデータを通信する１つ１つのノードは、図中の制御装置ＥＣＵ５のように、制御回路ＣＰＵ１、入出力制御回路ＩＯ１、センサ群ＳＮ１及びアクチュエータ群ＡＣ１に加え、無線通信モジュールＲ
Ｆ１およびアンテナから成る。このような構成の複数の制御装置が無線で相互に通信し、距離が離れたノード間の通信では、間に存在するノードが中継を行うようなネットワークにおいても、実施例１〜９の負荷分散方法が適用可能である。ただし、この場合、タスクを依頼する先の制御装置によって、通信のための中継ノードの介入数が異なるために、通信レイテンシを変える必要がある。そのため、予め、または、ネットワークが構成された際に、各ノード間の中継段数による通信レイテンシを求めておき、リアルタイム性の保証可能性の判定に用いる。

（実施例１６）
図１９は、自動車内のＬＡＮで接続された制御装置とさらに無線で接続される車外のサーバによって構成されるネットワークの例を示す図である。図中の車内のネットワークＮＷ１にはこれまでの実施例と同様に複数の制御装置が接続されている。さらに、無線通信機能を有する制御装置ＲＣ１が接続され車外のサーバＳＶ１と無線通信を行う。サーバＳＶ１は例えば自動車との近距離無線通信では路側に設置される。あるいは、長距離通信を用いた場合は基地局などに設置される。サーバは自動車に搭載される制御装置と比べ、巨大な記憶装置と高速な処理性能を有する。この場合にも実施例１〜９の負荷分散方法を用いることで、計算処理能力を重視されるタスク、つまり、計算処理量が大きくサーバと車内の制御装置の性能比によるメリットが通信レイテンシによるオーバヘッドを上回り、要求デッドラインを守れる場合にはサーバへのタスクの実行依頼が行われることになる。これにより、自動車内では従来不可能であった複雑な計算が必要となる高度な情報処理が可能となる。また、自動車内の計算リソースが十分出ない場合にも、車内の制御装置や演算処理装置を交換、増強するのでなく、車外の計算リソースを利用することで対応できる。

複数の制御対象機器を制御するためのプログラムを実行する複数の制御装置をネットワークで接続した分散制御システムに関するものであり、リアルタイム性の要求の高い自動車制御、ロボット制御、工場における製造機器の制御などにおいて、リアルタイム性を保証した上で、システムコスト低減と耐故障性を向上させる分散制御を実現するものである。

ＳＮ…センサ、ＡＣ…アクチュエータ、ＩＯ…センサに接続された制御回路、ＣＰＵ…制御回路、ＮＷ…ネットワーク、ＣＯＭ…通信装置、ＭＥＭＵ…記憶ユニット。

Claims

第１センサを有する第１制御回路と、前記第１センサの第１情報を処理する第２制御回路及び第３制御回路と、第１と第２の制御回路を接続する専用第１経路と、第１と第３の制御回路を接続する第２経路を有し、前記第１情報は第１経路を介して第２制御回路に伝達される場合と、第２経路を介して第３制御回路に伝達される場合があることを特徴とする分散制御システム。
第１アクチュエータを有する第１制御回路と、前記第１アクチュエータへの第１情報を処理する第２制御回路及び第３制御回路と、第１と第２の制御回路を接続する専用第１経路と、第１と第３の制御回路を接続する第２経路を有し、前記第１情報は第１経路を介して第２制御回路から伝達される場合と、第２経路を介して第３制御回路から伝達される場合があることを特徴とする分散制御システム。
前記第２経路は３個以上の回路が関与するネットワーク型の経路である請求項１又は２記載の分散制御システム。
前記第２経路は第４の制御回路を経由する間接的な経路である請求項１から３のいずれかに記載の分散制御システム。
前記第１制御回路と前記第３制御回路を接続する第３経路を有し、該第３経路と前記第２経路の一方が故障しても、前記第１制御回路と前記第３制御回路の接続を維持する請求項１から４のいずれかに記載の分散制御システム。
前記第１情報が第２制御回路で適切に処理できない場合に、前記第３制御回路で処理される請求項１又は２記載の分散制御システム。
センサと、前記センサに接続された第１制御回路と、前記センサの情報を処理する第２制御回路及び前記第１制御回路からの信号に応答するアクチュエータと、前記第１制御回路と前記第２制御回路を接続する専用経路とを備える複数個の制御装置と、これらの電子制御装置間を連係するネットワークを備え、前記第１制御回路および前記第２制御回路が、それぞれ、前記ネットワークに接続されたことを特徴とする分散制御システム。
センサと、前記センサに接続された第１制御回路と、前記第１制御回路からの信号に応答するアクチュエータとを備える制御装置および任意の制御装置からの情報を処理する制御回路が付加された請求項７記載の分散制御システム。
任意の電子制御装置からのアクセスを受け、任意の制御装置からの情報を記憶し、およ
び、記憶した情報を提供する記憶ユニットが付加された請求項７または８記載の分散制御システム。