JP2007034359A - 分散制御装置 - Google Patents

Abstract

【課題】複数の制御装置がネットワークで接続された分散制御システムにおいて、入出力処理を必要とする、もしくは固有の制御装置内に格納されているデータを利用しなければならないといった、制御装置に固有の特性を持つタスクを、他の制御装置上にて転送実行することができる分散制御システムの実現にある。
【解決手段】制御装置固有のタスクを他の制御装置上にて転送実行するために、転送元制御装置は、本来の機能に加え、記憶領域の入力データやコンテキスト情報を集め転送先制御装置に転送する機能を持たせる。転送先制御には、転送元制御装置から送信されたデータを記憶領域に格納し、演算を行い、結果を転送元制御装置に返信する機能を持たせる。演算処理を行うタスクのプログラムは、転送先制御装置と転送元制御装置の双方に存在させ、転送先制御装置はタスクの処理に適切な方法で参照アドレスを決定する。
【選択図】図１

Description

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

近年、自動車等の制御システムは、安全性、快適性の追求、環境配慮の観点において制御の高度化が進んでおり、搭載される電子制御装置（ＥＣＵ）の数は増加の一途をたどっている。車載電子制御システムでは、ＥＣＵがセンサ等から入力された情報に基づいて制御信号を生成してアクチュエータに出力し、アクチュエータがその制御信号に基づき動作する。各ＥＣＵは車載ＬＡＮで接続され通信ネットワークを構築しており、データ共有化や連係動作を行うことによって高度な協調制御を実現している。

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

そこで、複数のＥＣＵで負荷を分散して処理を行わせることによって各ＥＣＵの余剰能力を有効活用しようとする技術が提案されている。例えば、特開２００４−３８７６６号公報「車両用通信システム」（以下、特許文献１）では、各種制御対象機器を制御するのに必要な制御プログラムを、ネットワークに接続されたＥＣＵ毎に実行する必要のある固有タスクと、任意のＥＣＵにて実行可能なフロートタスクとに分け、そのフロートタスク実行用のプログラムを、ネットワークに接続されたマネージャＥＣＵにて管理することにより、制御装置全体の稼働率を高め、各制御装置の資源を有効に活用する。

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

特許文献１で開示された技術は、転送対象となるタスクを任意のＥＣＵで実行可能なフロートタスクに限定している。自動車制御においては、一般的には、個々の制御装置での処理が負荷の大半を占めており、特許文献１のように局所性のあるタスクを負荷分散の対象から除外すると、負荷分散に用いることができるタスクが少なくなってしまう。このため、非常に限定された負荷分散効果しか期待出来ない。

本発明の課題は、複数の制御装置がネットワークで接続された分散制御システムにおいて、入出力処理を含み制御装置内に格納されているデータを利用するといった、制御装置に固有の特性を持つタスクを、他の制御装置上にて転送実行することができる分散制御システムの実現にある。

前記の課題を達成するために、本発明では、各ＥＣＵに制御装置固有のタスクを転送するための新たな機能を持たせる。ここで、転送元制御装置をＥＣＵ１、転送先制御装置をＥＣＵ２とし、ＥＣＵ１に固有のタスクでありＥＣＵ１からＥＣＵ２へ転送することができるタスクをタスクＴＡとするとき、ＥＣＵ１においては以下に述べる機能を持たせる。

まず、ＥＣＵ１本来の機能として、（１）タスクＴＡの実行に必要である入力データをＥＣＵ１に接続されているセンサから取り込みランダムアクセスメモリ（ＲＡＭ）に格納する機能、（２）ＲＡＭに格納されている入力データを用いてタスクＴＡの演算処理を行う機能、（３）タスクＴＡの演算処理結果をアクチュエータに出力する機能を備えるものとする。前記（１）〜（３）の本来の機能に加えて、ＥＣＵ２にタスク処理を依頼し、処理結果を受けて利用するための機能として、（４）前記機能（１）によりＲＡＭに格納されたデータも含む、タスクＴＡの演算に必要な入力データをＲＡＭから集め、さらにＥＣＵ１内の汎用レジスタや制御レジスタなどのコンテキスト情報も必要であれば含めて、ＥＣＵ２に転送する機能、（５）ＥＣＵ２に転送したタスクの結果データが返信されてきた場合に、その結果データをＥＣＵ１に接続されたアクチュエータに出力、もしくは必要であればＥＣＵ１のＲＡＭに格納する機能、の２つの機能を新たに持たせる。

一方、前記ＥＣＵ２では、前記ＥＣＵ１と同様、ＥＣＵ２本来の機能として前記（１）〜（３）の機能を持つ他、以下に述べる機能を新たに持たせる。（６）ＥＣＵ１から送信されてきたタスクＴＡの入力データをＥＣＵ２のＲＡＭに格納する機能、（７）ＲＡＭに格納された入力データを用いてタスクＴＡの演算処理を行い、演算結果をＲＡＭに格納する機能、（８）ＲＡＭに格納された前記演算結果を集めＥＣＵ１に送信する機能、の３つの機能である。

本発明によれば、一般的に処理負荷の大部分を占める個々の制御装置に固有であるタスクを転送実行の対象とすることができるようになるため、従来にない高い負荷分散効果を得ることができる。

ＥＣＵ１、ＥＣＵ２が、ともに本来のタスクを持っていることを前提に他のＥＣＵにタスクの処理を依頼する場合、処理を依頼するタスクのデータのみならずプログラムを含めて依頼することにする方法もある。本発明では、ＥＣＵ１、ＥＣＵ２間で処理を依頼するタスクは既定とし、ＥＣＵ１、ＥＣＵ２ともに処理を依頼するタスクのプログラムを持つものとされ、処理を依頼するときは、関連データが転送されればよいものとされる。

したがって、処理を依頼されるＥＣＵ２上ではタスクＴＡの演算を実行できる形態にしたプログラムが格納されているが、細かく見れば、これは処理を依頼するＥＣＵ１に格納されているプログラムの形態とは、異なるものが格納されている場合もある。

具体的には、ＥＣＵ１内に格納されているプログラムとＥＣＵ２内に格納されているプログラムとでは記憶領域の参照先のアドレスが異なる場合がある。もしくは、ＥＣＵ１のプログラムと参照先アドレスが同一のままのプログラムをＥＣＵ２にも格納して、アドレス変換テーブルのような、中央処理装置（ＣＰＵ）のメモリアクセスのアドレスを補正するハードウェアを新たに設けて、逐次、適したデータにアクセスするようにする場合がある。

このため、ＥＣＵ２内のＣＰＵに直接メモリにアクセスするモードとアドレス変換テーブルによりアドレス補正を行うモードとを設けておき、実行中のタスクが処理を依頼されたものである場合は、アドレス補正を行うモードで実行を行うようにするのも良い。なお、処理を依頼されたタスクに関する、入力データ、出力データの送受信は、全てのデータが揃った時点で一括して送信する方法、個々のデータを逐一送信する方法、あるいは、あるまとまりで複数回送信する方法を取ることも可能である。

タスクＴＡをＥＣＵ１上で実行する場合は前記機能（１）→（２）→（３）の順に処理を行えばよく、この処理の流れを処理モード１と呼ぶ。タスクＴＡの処理を依頼して実行する場合は、前記機能（１）→（４）→（６）→（７）→（８）→（５）→（３）の順に処理を行えばよく、この処理の流れを処理モード２と呼ぶ。ＥＣＵ１はタスクＴＡの起動時に前記２つのどちらの処理モードで実行を行うか選択できるが、基本的にはタスクＴＡを処理モード１で処理する。しかし、そうすると、タスクのデッドラインが守れない場合に処理モード２で処理を行うことにして、ＥＣＵ２に処理を依頼する。これら（１）〜（８）の機能を持ち、二つの処理モードを持つことにより、各ＥＣＵに固有のタスクを、他のＥＣＵで実行することが可能となり高い負荷分散効果を得ることができる。

（実施例１）
図１は、Ｎ個の制御装置ＥＣＵ１〜ＥＣＵＮが通信路に接続された実施例１にかかる分散制御システムの全体構成を示すブロック図である。各ＥＣＵはリードオンリーメモリ（ＲＯＭ）やＲＡＭなどの記憶装置と演算を行うＣＰＵと入出力装置Ｉ／Ｏと通信器ＣＯＭから構成されている。

ＥＣＵ１のＲＯＭ１には、ＥＣＵ１でのみ実行できるタスクＴ１１と、ＥＣＵ１もしくはＥＣＵ１の依頼を受けたＥＣＵ２が実行できるタスクＴ１２が格納されている。ＥＣＵ１のＲＯＭ１には、さらにＴ１２の転送実行時の入出力データ送受信に関係するプログラムであるＴ１２ＩＳとＴ１２ＯＲが格納されている。Ｔ１２ＩＳは、Ｔ１２の演算処理に必要となる入力データをＥＣＵ１に接続されたセンサやＲＯＭ１、ＲＡＭ１から集めて通信器ＣＯＭ１へ渡す処理を行うプログラムである。Ｔ１２ＯＲは、タスク転送先ＥＣＵ２から返信されてきた演算結果データをＩ／Ｏ１に書き込む処理やＲＡＭ１に格納する処理を行うプログラムである。これらＴ１２ＩＳとＴ１２ＯＲのプログラムは、タスクとして扱ってもよいし、オペレーティングシステム（ＯＳ）が担当する処理という扱いでも特に問題はない。

ＥＣＵ２のＲＯＭ２には、ＥＣＵ２でのみ実行できるタスクＴ２１と、ＥＣＵ１から依頼を受けた場合に実行できるタスクＴ１２’が格納されている。ＥＣＵ１のＲＯＭ１に格納されているタスクＴ１２とＥＣＵ２のＲＯＭ２に格納されているタスクＴ１２’は、演算処理内容は同一であるが演算時に参照するメモリアドレスが異なっているため「’」を付け区別している。Ｔ１２とＴ１２’は、ＣＰＵ１とＣＰＵ２の間に互換性がない場合には当然異なるバイナリコードとなる。またＴ１２とＴ１２’とで異なる演算処理アルゴリズムを利用していたとしても出力結果の数値が一致していれば特に問題はない。ＥＣＵ２のＲＯＭ２には、さらにＥＣＵ１のタスクＴ１２を転送実行する場合の入出力データ送受信に関係するプログラムであるＴ１２ＩＲとＴ１２ＯＳが格納されている。Ｔ１２ＩＲは、Ｔ１２’の演算処理に必要となる入力データを、ＥＣＵ１からの送信データを受信した通信器ＣＯＭ２から受け取りＲＡＭ２に格納する処理を行うプログラムである。Ｔ１２ＯＳは、Ｔ１２’の演算処理結果データをＲＡＭ２から集めて通信器ＣＯＭ２に渡す処理を行うプログラムである。これらＴ１２ＩＲとＴ１２ＯＳのプログラムは、タスクとして扱ってもよいし、オペレーティングシステム（ＯＳ）が担当する処理という扱いでも特に問題はない。また、図示していないが、各ＥＣＵは転送可能なタスクと転送先ＥＣＵについての情報をテーブルとして保持している。以下、通常のタスク実行例としてタスクＴ１１の実行処理の流れを説明する。

まず、タイマ割り込みなどの要因によりタスクＴ１１が起動される。ＥＣＵ１は入出力装置Ｉ／Ｏ１を通じてＥＣＵ１に接続されたセンサからタスクＴ１１の演算実行に必要な入力データを受け取る。そして、タスクＴ１１に記述されたプログラム手順に基づき、上記センサからの入力データや、ＲＯＭ１、ＲＡＭ１に格納されたデータなどを用いてＣＰＵ１で演算を行い、第一制御対象を制御する信号を生成する。その際、必要であれば通信器ＣＯＭ１から通信路を通して他のＥＣＵとデータの送受信を行う。その後、ＥＣＵ１は入出力装置Ｉ／Ｏ１を通じてアクチュエータに制御信号を出力することにより、第一制御対象を制御する。

タスクＴ１２に関しては、ＥＣＵ１での実行かＥＣＵ２へ転送しての実行か選択することができるため、起動要求が発生した時にどちらの実行方法にするか選択する必要がある。選択の基準は、基本的にはタスクＴ１２をＥＣＵ１で実行した場合にタスクのデッドラインが守れるか否かである。これについては、図９を参照して、後述する。ＥＣＵ１で実行する方法を選択した場合は、先に示したタスクＴ１１の実行と同様の流れで処理が行われる。ＥＣＵ２へ転送して実行する方法を選択した場合については、以下に図２を用いて説明する。

図２は、ＥＣＵ１のＲＯＭ１に格納されているプログラムＴ１２ＩＳとＴ１２ＯＲ、ＥＣＵ２のＲＯＭ２に格納されているプログラムＴ１２ＩＲとＴ１２ＯＳについて、転送実行における入出力データのやり取りの様子を示している。タスクＴ１２が起動され、ＥＣＵ２に転送して実行する方法を選択した場合には、まずプログラムＴ１２ＩＳが実行される。プログラムＴ１２ＩＳは、タスクＴ１２の演算に必要となるセンサからの入力データやＲＯＭ１、ＲＡＭ１のデータを集めて通信器ＣＯＭ１へ渡す。入力データを集めたパケットは、通信器ＣＯＭ１から通信路を通してＥＣＵ２の通信器ＣＯＭ２へ渡される。

そして、通信割り込みの発生に起因してプログラムＴ１２ＩＲが起動される。プログラムＴ１２ＩＲは、通信器ＣＯＭ２から入力データパケットを受け取り、事前に決定もしくは実行時にＲＡＭ２の空き領域を確保した時点で決定されたアドレスに入力データを格納する。タスクＴ１２’は、入力データが全てＲＡＭ２に格納された後に起動されて演算処理を始めてもよいし、入力データパケット受信時の通信割り込みの発生に起因して起動され、入力データの格納処理と並行して演算実行処理を始めるようにしてもよい。タスクＴ１２’の演算処理が完了した後、もしくは演算処理中に一部の結果データがＲＡＭ２に格納された時点で、プログラムＴ１２ＯＳが起動される。プログラムＴ１２ＯＳは、タスクＴ１２’の演算結果のデータをＲＡＭ２から集めて通信器ＣＯＭ２に渡す。

この出力データパケットは通信器ＣＯＭ２から通信路を通してＥＣＵ１の通信器ＣＯＭ１に送信される。そして、通信割り込みの発生に起因してプログラムＴ１２ＯＲが起動される。プログラムＴ１２ＯＲは、通信器ＣＯＭ１から出力データパケットを受け取り、入出力装置Ｉ／Ｏ１を通じてアクチュエータへ制御信号を出力する。このとき必要であれば、上記出力データの一部をＲＡＭ１に格納する処理も行う。以上の手順によって、タスクＴ１２の転送実行が行われる。

図３は、図２で示した入出力データ送受信プログラムＴ１２ＩＲ、Ｔ１２ＩＳ、Ｔ１２ＯＳ、Ｔ１２ＯＲによるデータ格納例を用いた場合の、タスクＴ１２とＴ１２’の実行時のメモリ参照先のアドレスの相違を示している。タスクＴ１２’の参照アドレスは事前に絶対アドレスとして決めておく必要はなく、相対アドレスを決めておき、プログラムＴ１２ＩＲが使用するメモリ領域を実行時に決定してタスクＴ１２’に知らせるようにする方法などが考えられる。

（実施例２）
次に、本発明にかかる分散制御システムの実施例２について実施例１との相違点を中心に、図４、図５および図６を用いて説明する。

図４は、実施例１におけるＥＣＵ１でのタスクＴ１２をタスクＴ１２Ｐ、タスクＴ１２Ｍ、タスクＴ１２Ｅの３つのプログラム処理で代替している。ここではタスクＴ１２Ｐ、Ｔ１２Ｅをタスクと呼んでいるが、これらは格納されているデータをタスクＴ１２の進行に対応して新しい所定のアドレスに移す処理に過ぎないから、ＥＣＵ１のＯＳの処理に含めても問題ない。タスクＴ１２Ｐは、前記タスクＴ１２の処理に必要となるセンサなどのＩ／Ｏ領域の入力データを全てＲＡＭ領域に格納する。タスクＴ１２ＭはＲＡＭから入力データを得て演算処理を行い、出力データをＲＡＭに格納する。タスクＴ１２Ｅは、ＲＡＭ領域に格納された出力データをアクチュエータなどに出力するためにＩ／Ｏ領域に移す処理を行う。この手順によってＥＣＵ１上で前記タスクＴ１２の実行が行われる。

図５は、上記のＥＣＵ１での上記タスク実行に伴うメモリアクセスの様子と、その結果としてのＥＣＵ１のメモリ領域の記憶状況を図示したものである。ＥＣＵ１記憶状況Ａは、タスクＴ１２が起動される前のＥＣＵ１のメモリ領域の記憶状況を示す。ここでは、ＲＡＭ領域の３つのエリア入力データが格納されている状況であるとともに、Ｉ／Ｏ領域に新しい入力データが格納された状況である。タスクＴ１２の起動に応じて、タスクＴ１２ＰはＥＣＵ１記憶状況Ａに示すＩ／Ｏ領域の入力データを全てＲＡＭ領域に格納する。その結果、ＥＣＵ１記憶状況Ｂに示すように、ＲＡＭ領域には入力データが全て揃うことになる。タスクＴ１２ＭはＥＣＵ１記憶状況Ｂに示すＲＡＭ領域にあるすべての入力データを得て演算処理を行い、出力データをＲＡＭ領域の２つのエリアに格納する。このとき、ＥＣＵ１記憶状況Ｃに示すように、保存されている入力データに影響を及ぼさないエリアに保存されることは言うまでもない。タスクＴ１２Ｅは、ＲＡＭ領域に格納された２つの出力データのうち、アクチュエータなどに出力するためのデータをＩ／Ｏ領域に移す処理を行う。ＥＣＵ１記憶状況Ｄは、タスクＴ１２の処理が完了した段階でメモリ領域の記憶状況を示す。

一方、実施例２ではＥＣＵ２がＥＣＵ１のタスクＴ１２を実行する場合、タスクＴ１２に代えて、ＥＣＵ１に格納されているタスクＴ１２Ｍのみを格納しておく。ＥＣＵ１からＥＣＵ２にタスクの実行が依頼されたときは、ＥＣＵ１のＲＡＭ領域に集められた入力データは、通信器ＣＯＭ１でパケットに纏められて通信路を通してＥＣＵ２の通信器ＣＯＭ２へ渡される。図６は、ＥＣＵ２での上記タスク実行に伴うメモリアクセスの様子と、その結果としてのＥＣＵ２のメモリ領域の記憶状況を図示したものである。

ＥＣＵ２記憶状況Ａは、ＥＣＵ１のタスクＴ１２のための入力データが、ＥＣＵ２の通信器ＣＯＭ領域に格納された状態を示す。ＥＣＵ２のプログラムＴ１２ＩＲはＣＯＭ領域に格納された入力データをＲＡＭ領域に移す操作を行う。この場合、タスクＴ１２Ｍが参照するメモリアドレスが有効であるように格納する。したがって、実施例１のタスクＴ１２’のように参照メモリアドレスの補正を行う必要は無い。タスクＴ１２ＭはＥＣＵ２記憶状況Ｂに示すＲＡＭ領域にあるすべての入力データを得て演算処理を行い、出力データをＲＡＭ領域の２つのエリアに格納する。このとき、ＥＣＵ２記憶状況Ｃに示すように、保存されている入力データに影響を及ぼさないエリアに保存されることは言うまでもない。ＥＣＵ２のプログラムＴ１２ＯＳは、ＲＡＭ領域の２つのエリアに格納されている出力データを、ＥＣＵ１に転送するのに備えて、ＣＯＭ領域に格納する。ＥＣＵ２記憶状況Ｄは、タスクＴ１２の処理が完了した段階でメモリ領域の記憶状況を示す。

ＣＯＭ領域に格納された出力データはＥＣＵ２−通信路−ＥＣＵ１を通して、ＥＣＵ１の通信器ＣＯＭ１へ渡される。

実施例２においては、前記タスクＴ１２の演算処理部分Ｔ１２Ｍは、自己が参照するメモリアドレスを維持できるように、プログラムＴ１２ＩＲとＴ１２ＯＳを設定すれば良いので、複数の転送先ＥＣＵにおいて共通のタスクＴ１２のプログラムを用いてよいため、実装が容易になるという利点がある。

（実施例３）
次に、本発明にかかる分散制御システムの実施例３について実施例２との相違点を中心に、図７を用いて説明する。

実施例３においては、ＥＣＵ２のＣＰＵがＲＡＭなどの記憶領域をアクセスする際に、アドレス変換テーブル（ＡＴＴ）を経由するか、直接アクセスを行うかをセレクタ回路（ｓｅｌ）で選択できるようになっている。ＣＰＵから出力されるａｄはアドレスを示す信号、ｍｄはアクセスのモードを選択する信号を表している。

実施例２においては、転送先のＥＣＵ２においてタスクＴ１２Ｍは依頼元のＥＣＵ１がタスクＴ１２を実行するときの参照先のアドレスが使用できるものとした。そのため、ハードの実装の面では簡便で有利である反面、依頼を受けたＥＣＵ２では、その都度、タスクＴ１２Ｍの参照領域となるメモリ領域を開放する必要がある。あるいは、依頼を受けることを前提として所定のメモリ領域を空けておくことが必要となる。依頼を受ける都度、メモリ領域を開放することにすると、ＥＣＵ２本来のタスクの処理効率が悪くなるし、所定のメモリ領域を空けておく場合には、メモリの利用率が悪くなる。

したがって、ＥＣＵ２全体の処理スケジュールに余裕があり、依頼されるタスクＴ１２に備えて所定のメモリ領域を空けておける場合には、実施例２と同様に直接アクセスを行うことにする。一方、所定のメモリ領域を空けておく余裕が無い場合には、依頼されたタスクＴ１２の処理の際に、アドレス変換テーブル（ＡＴＴ）を利用して、参照先のメモリ領域のアドレスに変換して、アクセスを行うことにする。

アドレス変換テーブル（ＡＴＴ）がどのようにアドレスを補正するかは、固定的に決定しておくこともできるし、動作時に書き換え可能としておくこともできる。アドレス変換テーブルによるアドレス補正機能を利用することで、ＥＣＵ２の制御プログラムのアドレス参照先の決定に柔軟性ができるメリットもある。

（実施例４）
次に、本発明にかかる分散制御システムの実施例４について図８と図９を用いて説明する。

図８に示すように、実施例４ではＥＣＵ１はＣＰＵモニタとタスク転送先ＥＣＵテーブルを有する。テーブルには、転送可能なタスクがリストアップされており、転送される優先度の情報や、優先度順に並んだ転送先ＥＣＵの情報が登録されている。また、ＥＣＵ１はＣＰＵモニタを具備し、自己のＣＰＵ負荷を観測しており、ＣＰＵ負荷が事前に設定した閾値を超えた場合に、ＥＣＵ１はタスクの転送を開始することができる。タスク転送先ＥＣＵテーブルを具備することによって、より効率的に負荷分散を行うことが可能となる。ＥＣＵ２はＣＰＵモニタを具備することによって、ＥＣＵ１からのタスク転送実行依頼を引き受けるか否かを自己の観測したＣＰＵ負荷に基づき決定することができる。

図９は、タスクの起動要求が発生してから負荷分散によるタスク実行を行うまでの一連のフローを示している。ＥＣＵ１でタスクの起動要求が発生したら、まずＥＣＵ１は実行可能状態にある全てのタスクがデッドラインを守って実行を完了できるかを判定する（ステップ１）。もし可能であればあらかじめ登録されている優先順位に従いタスクの実行を行う（ステップ２）。不可能であると判定された場合には、実行可能状態にあるタスクの中から他のＥＣＵに依頼して実行することが可能なタスクが存在するか調べる（ステップ３）。もし、他のＥＣＵで実行可能なタスクが存在しない場合は、タスク実行放棄処理を行う（ステップ４）。タスク実行放棄処理は、例えば、実行可能状態にある全タスクの中で最も実行優先度の低いタスクを削除するなどの方法がある。タスク実行放棄処理を終えたら、再度残りの全ての実行可能状態にあるタスクがデットラインを守って実行を完了できるかを判定する（ステップ１）。可能であると判定されるまでこの手順は続けられる。

次に、他のＥＣＵで実行可能なタスクが存在する場合について、もし、一つしか存在しない場合はそのタスクを選択し、複数存在する場合はＥＣＵ１が有するタスク転送先ＥＣＵテーブルを参照して転送の優先順位が最も高いタスクを選択する（ステップ５）。そして選択したタスクについて、ＥＣＵ２に依頼した場合にタスクのデッドライン時間を守って実行を完了できるか判定する（ステップ６）。判定は、タスクの実行時間やデータ転送時間などの事前に与えられている情報に基づき行われる。不可能であると判定された場合は選択タスクを候補から除外した（ステップ７）後、他に転送実行が可能であるタスクが存在するかを調べ（ステップ３）同様の手順を繰り返す。可能であると判定された場合は、ＥＣＵ１が有する転送先ＥＣＵテーブルを参照し、最も高い優先順位が与えられている転送先候補ＥＣＵに対して実行可否の問い合わせを行う（ステップ８）。

実行可否の問い合わせを受けたＥＣＵ２は、ＥＣＵ２が有する自己のＣＰＵ負荷モニタを参照するか、もしくは事前に与えられた問い合わせを受けているタスクの情報を基にするなどして、実行の依頼を引き受けることが可能であるか判定（ステップ９）し、判定結果を依頼元のＥＣＵに返信する（ステップ１０）。

ＥＣＵ２に実行可否の問い合わせを行ったＥＣＵ１は、事前に定めた一定時間、ＥＣＵ２からの返信を待つ（ステップ１１）。一定時間内に返信が来なかった場合、もしくは返信は来たが実行依頼が不可能であるという判定（ステップ１２）の場合は、ＥＣＵ２を転送先ＥＣＵ候補から外し（ステップ１３）、選択タスクのデッドラインが保証可能であるか再度判定（ステップ６）し、上記手順を繰り返す。依頼の引き受けが可能であるというＥＣＵ２からの返信の場合は、ＥＣＵ２にタスクの実行依頼を行い（ステップ１４）、引き続き残りのタスクの実行を行う。

依頼の引き受けが可能であると返信したＥＣＵ２は、一定時間ＥＣＵ１からの実行依頼を待つ（ステップ１５）。一定時間内に実行依頼があった場合、依頼されたタスクの実行を行い（ステップ１６）、結果のデータをＥＣＵ１に返信（ステップ１７）し通常処理に戻る（ステップ１８）。もし一定時間内にＥＣＵ１から実行依頼がなかった場合は通常処理に戻る（ステップ１９）こととする。

ＥＣＵ１は、ＥＣＵ２からの結果の返信を受け取ると返信データの処理（ステップ２０）を行う。一定時間内にＥＣＵ２からの結果の返信がない場合は返信データの処理（ステップ２０）として、依頼タスクの実行放棄処理を行う。

（実施例５）
次に、本発明にかかる分散制御システムの実施例５について図１０を用いて説明する。

実施例５においては、ＥＣＵ２は、ＥＣＵ１の制御項目について、ＥＣＵ１に格納されているタスクＴ１２のプログラムと同一のタスクＴ１２のプログラムを保有している。ＥＣＵ２は、ＥＣＵ１からタスクＴ１２の実行を依頼された場合に、自己の記憶領域に格納しているタスクＴ１２を実行する。ＥＣＵ２でタスクＴ１２を実行するためのデータは、通信起動装置（ＣＯＭＣＯＮ）によりＥＣＵ１にデータの転送要求を送り、ＥＣＵ１の記憶領域のデータを転送して入手する。さらに、演算結果の格納先もＥＣＵ１の記憶装置アドレスであるために、ＥＣＵ１の記憶領域へのデータの書き込みに対しては、通信起動装置（ＣＯＭＣＯＮ）によりＥＣＵ１へのデータ転送が行われる。実施例５では、データ参照やデータ書き込みの度に通信が起動されるというオーバーヘッドと通信起動装置（ＣＯＭＣＯＮ）という追加機能が必要であるが、ＥＣＵ１とＥＣＵ２のプログラム（Ｔ１２）は全く同一であるため、ＥＣＵ２用にプログラムを修正する必要がないという利点がある。

ＥＣＵ２にメモリ参照先を変えたタスクを格納した分散制御システムを示す図である。 実施例１のデータ送受信プログラムによる転送タスク実行時のデータの流れを示す図である。 実施例１のタスク実行時のメモリ参照アドレスの違いを示す図である。 Ｉ／Ｏへのアクセスを要する処理を分離したタスク構成でプログラムを格納している分散制御システムを示す図である。 実施例２の分散制御システムにおけるＥＣＵ１でのタスク実行に伴うメモリアクセスを示す図である。 実施例２の分散制御システムにおけるＥＣＵ２でのタスク実行に伴うメモリアクセスを示す図である。 実施例３におけるアドレス変換テーブルを参照して転送タスクの実行を行う分散制御システムを示す図である。 実施例４におけるＣＰＵ負荷モニタとタスク転送先ＥＣＵテーブルを有する分散制御システムを示す図である。 実施例４におけるタスク負荷分散フローを示す図である。 実施例５におけるプログラム実行時に通信モジュールを起動する分散制御システムを示す図である。

符号の説明

ＥＣＵ…制御装置、ＲＯＭ…リードオンリーメモリ、ＲＡＭ…ランダムアクセスメモリ、ＣＰＵ…中央処理装置、ＣＯＭ…通信器、Ｔ１１，Ｔ１２…タスク、Ｉ／Ｏ…入出力装置。

Claims (15)

1. ネットワークで接続された複数の制御装置の各制御装置が入出力装置、記憶装置、演算装置および通信器から構成され、各制御装置が複数のタスクを分散して実行する分散制御システムであって、前記ネットワークに接続された第１の制御装置と第２の制御装置との間で、
   前記第１の制御装置が、
   入力装置から記憶領域への入力機能、
   記憶装置内のデータを用いた制御タスクの演算機能、
   演算結果を出力装置に出力する機能、
   記憶装置内のデータ、汎用レジスタやステータスレジスタなどの情報を含むコンテキストを前記第２の制御装置に転送する機能、及び、
   前記第２の制御装置から転送されたデータを記憶装置に格納する機能を有し、
   前記第２の制御装置が、
   前記第１の制御装置から転送されたデータを記憶する機能、
   記憶装置のデータを用いた制御タスクの演算機能、及び、
   演算結果を第１の制御装置に転送する機能を有することを特徴とする分散制御システム。
2. 前記第１の制御装置が自己の実行すべき制御タスクの演算機能を代行可能な制御装置に関する情報を保持している請求項１記載の分散制御システム。
3. 前記第１の制御装置は、自己の実行すべき制御タスクを所定のデッドライン内に処理できないと判定したときに、該制御タスクの演算機能を代行可能な制御装置に処理の依頼をする請求項２記載の分散制御システム。
4. 前記第１の制御装置は、自己の実行すべき制御タスクを所定のデッドライン内に処理できないと判定したときに、該制御タスクの演算機能を代行可能な制御装置の設定されている優先順位にしたがって処理を依頼する請求項３記載の分散制御システム。
5. 前記第１の制御装置から制御タスクの演算機能の代行を依頼された制御装置は、実行可能性を判定して実行可否を前記第１の制御装置に通知し、前記第１の制御装置は所定時間内に実行可を通知されたときは代行を依頼した制御装置に実行依頼を送り、代行を依頼された制御装置は前記第１の制御装置からの実行依頼を待って実行する請求項４記載の分散制御システム。
6. 前記第１の制御装置は、制御タスクの演算機能の代行を依頼された制御装置から所定の時間内に返信がなくあるいは実行否を通知されたときは代行を依頼した制御装置に代わる他の制御装置に制御タスクの演算機能の代行を依頼する請求項５記載の分散制御システム。
7. 前記制御タスクの演算機能の代行を依頼された制御装置は、実行可を通知された第１の制御装置から所定の時間内に実行依頼があったときは実行し、所定の時間内に実行依頼がないときは、代行を依頼されたタスクの演算機能を無視して、自己の通常処理に戻る請求項５記載の分散制御システム。
8. 前記制御タスクの演算機能の代行を依頼された制御装置は、前記第１の制御装置から転送されたデータ、汎用レジスタやステータスレジスタなどの情報を含むコンテキストを前記第１の制御装置のデータ参照アドレスと同一の参照アドレスに格納し、前記代行を依頼された制御装置は前記同一の参照アドレスにアクセスして処理を実行する請求項５記載の分散制御システム。
9. 前記制御タスクの演算機能の代行を依頼された制御装置は、前記第１の制御装置から転送されたデータ、汎用レジスタやステータスレジスタなどの情報を含むコンテキストを前記第１の制御装置のデータ参照アドレスと異なった参照アドレスに格納し、前記代行を依頼された制御装置はアドレス変換器を介して前記異なった参照アドレスにアクセスして処理を実行する請求項５記載の分散制御システム。
10. ネットワークで接続された複数の制御装置の各制御装置が入出力装置、記憶装置、演算装置および通信器から構成され、各制御装置が複数のタスクを分散して実行する分散制御システムであって、前記ネットワークに接続された第１の制御装置と第２の制御装置との間で、前記第１の制御装置と第２の制御装置は第１の制御装置の固有の制御項目のプログラムと同一のプログラムを少なくとも１つ記憶装置に保持し、第２の制御装置は第１の制御装置からの実行依頼に従い、前記プログラムを実行するものであるとともに、前記プログラムを実行するために必要となるデータは、通信器およびネットワークを介して第１の制御装置からデータを転送して導入し、実行結果は、通信器およびネットワークを介して第１の制御装置にデータを転送することを特徴とする分散制御システム。
11. 前記第１の制御装置は、自己の実行すべき制御タスクを所定のデッドライン内に処理できないと判定したときに、該制御タスクの演算機能を代行可能な制御装置に処理の依頼をする請求項１０記載の分散制御システム。
12. 前記第１の制御装置は、自己の実行すべき制御タスクを所定のデッドライン内に処理できないと判定したときに、該制御タスクの演算機能を代行可能な制御装置の設定されている優先順位にしたがって処理を依頼する請求項１１記載の分散制御システム。
13. 前記第１の制御装置から制御タスクの演算機能の代行を依頼された制御装置は、実行可能性を判定して実行可否を前記第１の制御装置に通知し、前記第１の制御装置は所定時間内に実行可を通知されたときは代行を依頼した制御装置に実行依頼を送り、代行を依頼された制御装置は前記第１の制御装置からの実行依頼を待って実行する請求項１２記載の分散制御システム。
14. 前記第１の制御装置は、制御タスクの演算機能の代行を依頼された制御装置から所定の時間内に返信がなくあるいは実行否を通知されたときは代行を依頼した制御装置に代わる他の制御装置に制御タスクの演算機能の代行を依頼する請求項１３記載の分散制御システム。
15. 前記制御タスクの演算機能の代行を依頼された制御装置は、実行可を通知された第１の制御装置から所定の時間内に実行依頼があったときは実行し、所定の時間内に実行依頼がないときは、代行を依頼されたタスクの演算機能を無視して、自己の通常処理に戻る請求項１３記載の分散制御システム。
    

Images