JP3922070B2 - 分散制御方法及び装置 - Google Patents
分散制御方法及び装置 Download PDFInfo
- Publication number
- JP3922070B2 JP3922070B2 JP2002095748A JP2002095748A JP3922070B2 JP 3922070 B2 JP3922070 B2 JP 3922070B2 JP 2002095748 A JP2002095748 A JP 2002095748A JP 2002095748 A JP2002095748 A JP 2002095748A JP 3922070 B2 JP3922070 B2 JP 3922070B2
- Authority
- JP
- Japan
- Prior art keywords
- time
- message
- task
- distributed control
- margin
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
- G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/48—Indexing scheme relating to G06F9/48
- G06F2209/483—Multiproc
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Small-Scale Networks (AREA)
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
共通の多重伝送路に接続されたマルチタスキング動作が可能な複数個のノードにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことにより協調動作して分散制御を実行する分散制御方法及び装置に関する。
【０００２】
【従来の技術】
従来より、車内ＬＡＮ等の処理速度や処理時間保証に対する要求条件の厳しい分野において、共通の多重伝送路に接続された複数のノードに分散制御を実行させる分散制御システムを構成する場合、各ノードにマルチタスキング動作をさせるためのリアルタイムオペレーティングシステム（以下「リアルタイムＯＳ」という）や、ノード間の通信をリアルタイムで行うための通信方式であるＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance ）が利用されている。
【０００３】
このうちリアルタイムＯＳは、各タスクに対して予め優先度を設定し、その優先度の高いタスクからノードでの実行権（ＣＰＵでの実行権）が割り当てられるようスケジューリングを行うものである。また、ＣＳＭＡ／ＣＡは、通信に用いる各メッセージに対して予め優先度に相当するＩＤを設定し、複数のノードが同時にメッセージを送信した時は、最も優先度の高いＩＤを持つメッセージが伝送路上で破壊されることなく生き残るように調停を行う通信方式であり、優先度の高いメッセージから送信されるように通信制御を行うものである。
【０００４】
このように、リアルタイムＯＳ、ＣＳＭＡ／ＣＡを組み合わせた方法では、処理時間の厳しいタスクやメッセージほど、高い優先度を割り当てることで、システム全体としてのリアルタイム性が向上する。
また、上述の方法以外に、各ノードにて分散して実行される分散制御が、要求されたデッドラインの条件を満たすように、すべてのノードにおける個々のタスクの起動時刻、及び各ノード間のメッセージの通信時刻を予め設定し、その設定に従って動作させる、いわゆるタイムトリガー方式を用いた分散制御システムも知られている。
【０００５】
このタイムトリガー方式については、例えば以下の文献で紹介されている。
S.Poledna, et.al.,"OSEKtime: A Dependable Real-Time Fault-Tolerant Operating System and Communication layer as an Enabling Technology for By-Wire Applications", SAE2000-01-1051
Thomas Fuehrer,"The Steer-By-Wire Prototype Implementation:Realizing Time Triggered System Design, FailSilence Behavior and Active Replication withFault-Tolerance Support", SAE1999-01-0400
この方式を用いた分散制御システムでは、ノード内でのタスクの競合、ノード間の通信の競合が排除され、システムの不確定動作がなくなるため処理時間の保証が可能となる。
【０００６】
【発明が解決しようとする課題】
ところで、リアルタイムＯＳとＣＭＳＡ／ＣＡとを用いた前者の分散制御システムは、ＣＰＵの能力範囲内で優先度の高いタスクからできる限りの処理を実行するベストエフォート型の動作をするものであるため、各タスクの処理やメッセージの通信が規定時間内に終了するか否かの保証はできない。
【０００７】
このため、分散制御が、要求されたデッドラインの条件を満たすことを保証するには、実際にシステムを動作させて実証しなければならない。そして、その性能を保証することができない場合には、タスクやメッセージの優先度、ＣＰＵの動作周波数、通信の転送レート等の変更が必要となる。
【０００８】
しかし、タスクやメッセージの優先度の変更が、全体の制御にどのような影響を与えるかを明確に規定することは困難であり、結局、トライアンドエラーでの優先度の変更等を行わなければならないため、開発工数の増大を招くという問題があった。
【０００９】
また、タスクやメッセージの優先度が最適化されていない状態では、要求されたデッドラインの条件を満たそうとすると、ＣＰＵの動作周波数や伝送路上の通信レートが必要以上に高速なものに設定されることになるため、製造コストも増大するという問題もあった。
【００１０】
一方、タイムトリガー方式を用いた後者の分散制御システムでは、各ノード上で動作するタスクの起動時刻、ノード間の通信時刻をすべて設計者（ユーザ）が決定しなくてはならず、システム上で並列動作する複数の分散制御が要求する応答時間、制御周期等をすべて満たそうとすると、その設計には膨大な時間を要するため開発工数の増大を招くという問題があった。
【００１１】
また、タイムトリガー方式では、ある非同期のイベントをトリガーとして開始する分散制御に対しても、常にそのイベントが発生するものとして固定的にタスクの起動時刻、通信時刻をスケジューリングしなければならない。このため、ノード上のＣＰＵの処理や伝送路上での通信に過大なオーバヘッドが必要となり、ＣＰＵや伝送路の使用効率が低下するだけでなく、非同期イベントが入力されても、予めスケジューリングされた時刻まで待たなければ、そのイベントに対する処理を開始することができないため、そのような非同期イベントに対する処理のリアルタイム性の保証が難しくなるという問題もあった。
【００１２】
本発明は、上記問題点を解決するために、分散制御システムの設計者に過大な負担を強いることなく、分散制御が要求する応答時間やデッドラインの条件を保証できる分散制御方法及び装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
上記目的を達成するためになされた発明である請求項１記載の分散制御方法では、ＣＳＭＡ／ＣＡ方式を適用したフレームによりメッセージを伝送する共通の多重伝送路に接続されたマルチタスキング動作が可能な複数のノードにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことで協調して時系列に動作することにより分散制御を行う。
また、各ノードにおいて、実行可能なタスクのそれぞれについて、タスクがその一部を分担する分散制御についての予測終了時間と、その分散制御についてのデッドラインとの差分を表す余裕時間を設定し、その余裕時間の小さいタスクから優先的に実行権を割り当てると共に、送信可能なメッセージのそれぞれについて、メッセージが属する分散制御についての余裕時間（以下「メッセージについての余裕時間」という）に基づき、その余裕時間の小さいものから優先的にメッセージの送信権を割り当てるようにされている。
【００１４】
つまり、低優先度に設定されたタスクやメッセージが常に後回しにされてしまう従来装置とは異なり、全ての分散制御がデッドラインの条件を満たすように、タスクやメッセージの優先度が常に変化する。
従って、各タスクの処理時刻やメッセージの送信時刻を予め決定しておかなくても、デッドラインの条件を満たすような順番で効率よく処理や送信が実行されることになる。このため、実際に動作させた結果、デッドラインの条件を満たすことができない場合には、そのデッドラインからの遅れ分だけＣＰＵの処理速度やメッセージの伝送速度を高速化しさえすればよく、分散制御システムの開発工数を大幅に削減できる。
【００１５】
また、請求項１記載の分散制御方法では、メッセージを送信する際には、そのメッセージについての余裕時間を表す時間情報を、フレームのうち伝送路上での調停制御のために用いられる領域に挿入してメッセージと共に送信し、また、タスクの起動時にはそのタスクについての余裕時間として、分散制御の最初に起動される先頭タスクの場合は、予め用意された余裕時間の初期値を設定し、メッセージの受信により起動される非先頭タスクの場合は、そのメッセージに挿入された時間情報に基づく値を設定するようにされている。
【００１６】
つまり、余裕時間が小さいほど、伝送路上での優先度が高くなるように時間情報をコード化すれば、伝送路上でも、余裕時間の小さいメッセージが優先的に伝送されることになり、分散制御システムのリアルタイム性をより向上させることができる。
【００１７】
なお、時間情報としては、余裕時間をそのまま使用してもよいし、余裕時間を表すビットデータの一部のビット（例えば上位の数ビット）のみを使用してもよい。また、その余裕時間を表すデータを、例えばログスケールで変換する等した値を用いてもよい。
【００２５】
ところで、余裕時間は、タスクの実行状態に応じて更新するだけでなく、メッセージの処理状態に応じて更新する必要がある。
【００２６】
例えば、複数のメッセージの送信が要求された場合、通信権を持つ唯一のメッセージについては、その余裕時間を保持し、ノード内で他のノードへの通信権の取得待ちの状態にある他のメッセージについては、請求項２記載のように、その余裕時間を、通信権を取得するまでの間、時間の経過と共に減少させればよい。
【００２７】
また、通信権を取得したメッセージについては、請求項３記載のように、ノード内で他のノードへの通信件を獲得したメッセージについて、次の送信機会で共通伝送路での調停に勝ち、他のノードがメッセージを受信できたと仮定した時の通信終了までに要する予測通信時間が、そのメッセージについて予め設定された最悪通信時間に満たない時は、そのメッセージについての余裕時間を、最悪通信時間と予測通信時間との差分だけ増加させ、逆に、予測通信時間が最悪通信時間を越えている時は、そのメッセージについての余裕時間を、その差分だけ減少させればよい。
【００２８】
なお、実際の通信時間ではなく、予測通信時間を用いているのは、後述するように、メッセージと共にその余裕時間を送信する場合、送信終了後に余裕時間を更新しても、その更新した余裕時間をメッセージと共に送信することができないからである。
【００３３】
次に、請求項４記載の分散制御装置では、ＣＳＭＡ／ＣＡ方式を適用したフレームによりメッセージを伝送するマルチタスキング動作をする各タスクが、共通の多重伝送路に接続された他の装置上で動作する他のタスクと、互いにメッセージを通信し合うことにより協調動作して分散制御を実行する。
そして、起動時設定手段が、分散制御にて最初に実行される先頭タスクの起動時には、予め用意された余裕時間の初期値を、そのタスクについての余裕時間として設定し、一方、メッセージ送受信手段にてメッセージが受信されることよる非先頭タスクの起動時には、そのメッセージと共に受信した時間情報に基づく値を、そのタスクについての余裕時間として設定する。
【００３４】
そして、タスクスケジューリング手段は、このようにして起動され実行可能となったタスクを、各タスクに設定された余裕時間に基づいて、その余裕時間の小さいタスクから優先的に実行権を割り当てる。なお、余裕時間は、第１更新手段により、タスクスケジューリング手段による各タスクの実行状態に応じて逐次更新される。
【００３５】
また、メッセージ送受信手段は、タスクが生成するメッセージについての余裕時間を、フレームのうち伝送路上での調停制御のために用いられる領域に挿入してメッセージと共に多重伝送路を介して送信し、他の装置からのメッセージを受信した時には、該メッセージに対応するタスクの起動を前記タスクスケジューリング手段に要求する。
そして、メッセージを多重伝送路を介して受信した他の装置が、同様の処理を繰り返すことにより分散制御が実現する。
【００３６】
また、メッセージスケジューリング手段が、メッセージについての余裕時間に基づいて、その余裕時間の小さいものから優先的に、メッセージ送受信手段でのメッセージの送信権を割り当てる。なお、余裕時間は、第２更新手段により、メッセージ送受信手段による各メッセージの送信の実行状態に応じて逐次更新される。
【００３８】
即ち、請求項４記載の分散制御装置は、請求項１〜３記載の分散制御方法を実現するものであり、これと同様の効果を得ることができる。
【００３９】
【発明の実施の形態】
以下に本発明の実施形態を図面と共に説明する。
［第１実施形態］
図１は、分散制御システムを構成する分散制御装置としてのノードの内部構成を表すブロック図である。
【００４０】
図１に示すように、本実施形態の分散制御システムは、ネットワークＮＴを介して接続された複数のノードＮＤｉ（図中では一つのみ示す）により構成され、各ノードＮＤｉは互いに連係して複数の分散制御を並列に実行するようにされている。
【００４１】
ここで分散制御とは、複数のノードＮＤｉにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことで協調して時系列で動作することにより実現される一連の制御のことを意味する。つまり、時系列上で隣り合うタスクが互いに異なるノードに配置されている場合には、タスク間でメッセージの通信が行われることになる。
【００４２】
そして、各ノードＮＤｉは、いずれも同様の構成をしており、タスクの集合であるタスク群１２を管理するタスク制御部１４と、タスク群１２を構成する各タスクが生成したメッセージの集合であるメッセージ群１３を管理する通信制御部１５と、各分散制御に対応してタスクやメッセージについて設定される余裕時間（後述する）を逐次更新する第１及び第２更新手段としての余裕時間更新部１６とを備えている。
【００４３】
このうち、通信制御部１５は、各タスクが生成したメッセージをネットワークＮＴを介して送受信するメッセージ送受信手段としてのメッセージ送受信部２０と、余裕時間更新部１６が更新する余裕時間に基づいて、余裕時間の小さいものに対して優先的に、メッセージ送受信部２０でのメッセージの送信権を与えるメッセージスケジューリング手段としてのメッセージスケジューリング部１９とを備えている。
【００４４】
つまり、メッセージスケジューリング部１９では、例えば図１５（ａ）に示すように、余裕時間が１２０ｍｓのメッセージＡ、余裕時間が１８０ｍｓのメッセージＢ、余裕時間が１００ｍｓのメッセージＣが存在する場合、送信待ちメッセージの待ち行列上に、メッセージＣ、メッセージＡ、メッセージＢの順番にメッセージを整列し、先頭のメッセージＣの送信をメッセージ送受信部２０に実施させる。
【００４５】
その後、余裕時間更新部１６により各メッセージの余裕時間が更新され、その結果、メッセージＣよりメッセージＡの方が余裕時間が小さくなった場合、メッセージ送受信部２０においてメッセージＣが調停負けにより未だ送信されていない場合は、メッセージＣより先にメッセージＡの送信をメッセージ送受信部２０に実施させる。
【００４６】
ここで、図２は、メッセージ送受信部２０が、ネットワークＮＴを介して送受信するフレームの構成を示す説明図である。なお、このフレームは、ＣＳＭＡ／ＣＡ方式の通信制御を行うためのものであり、伝送路上での調停制御に使用するＩＤ領域以外は、周知の構成であるため、このＩＤ領域についてのみ説明する。即ち、メッセージ送受信部２０が送受信するフレームのＩＤ領域は、前半部分と後半部分とに分割されており、前半部分に余裕時間に応じた時間情報が挿入され、後半部分にメッセージを識別するための認識用ＩＤが挿入されている。
【００４７】
つまり、メッセージ送受信部２０が生成するフレームには、タスクが生成したメッセージと共に、そのメッセージが属する分散制御についての余裕時間を表す時間情報が挿入されることになる。そして、複数のノードＮＤｉから同時にフレームが送信された時には、時間情報（余裕時間）として挿入された値が最も小さいフレームが伝送路上で破壊されることなく生き残って送信権を取得することになり、送信権を取得できなかった他のフレームは、次の送信機会（送信中のフレームの送信終了タイミング）を待つことになる。
【００４８】
次に、タスク制御部１４は、図１に示すように、タスクの起動時に、そのタスクに対して、そのタスクがその一部を分担する分散制御についての余裕時間を設定する余裕時間初期設定部１７と、いわゆるリアルタイムＯＳからなり、各タスクに付与された優先度に従って、順次各タスクに実行権を与えるタスクスケジューリング部１８とを備えている。
【００４９】
なお、タスクスケジューリング部１８では、優先度として余裕時間を用いており、この余裕時間の小さいタスクほど、優先的に実行権が与えられる。
例えば、図１５（ｂ）に示すように、余裕時間が１００ｍｓのタスクＡ、余裕時間が５０ｍｓのタスクＢ、余裕時間が８０ｍｓのタスクＣが同時に起動している場合、タスクスケジューリング部１８は、実行待ちタスクの待ち行列上に、タスクＢ、タスクＣ、タスクＡの順番にタスクを整列し、先頭のタスクＢの処理をＣＰＵ上で実行する。そして、余裕時間更新部１６により余裕時間が更新され、その結果、タスクＢよりタスクＣの方が余裕時間が小さくなった場合には、タスクＢの実行を中断し、タスクＣの実行を開始させる。
【００５０】
また、余裕時間初期設定部１７は、管理するタスクの中に、分散制御において最初に実行される（時系列の先頭に位置する）タスクである先頭タスクがある場合に、その先頭タスクが属する分散制御についての余裕時間の初期値を記憶している。そして、タスクの起動要求が発生すると、そのタスクの余裕時間として、そのタスクが先頭タスクである場合には、予め記憶されている余裕時間の初期値を設定し、一方、そのタスクがメッセージの受信に基づく非先頭タスクである場合には、受信したメッセージに示された時間情報に基づく値を設定する。
【００５１】
ここで図３は、余裕時間の初期値の求め方を示す説明図である。ここでは、図３（ａ）に示すように、ノードＮＤ１がタスクａ〜ｃ、ノードＮＤ２がタスクｄ〜ｅ、ノードＮＤ３がタスクｇ〜ｉをそれぞれ実行し、このうちノードＮＤ１のタスクａ、ノードＮＤ２のタスクｄ、ノードＮＤ３のタスクｇが、タスクａを先頭タスクとして、タスクｄ，タスクｇの順に処理を実行することで分散制御を行うものとする。
【００５２】
この場合、各タスクａ，ｄ，ｇは、それぞれが異なるノードＮＤ１〜ＮＤ３に配置されているため、図３（ｂ）に示すように、タスクａとタスクｄの処理間ではメッセージ１の通信が、タスクｄとタスクｇの処理間ではメッセージ２の通信が生じる。また、この分散制御では、タスクａの処理開始を基点とした制御周期Ｔcyにより求まるデッドラインが存在し、時系列の末尾にあるタスクｇの処理が、このデッドラインより前に終了しなければならないものとする。
【００５３】
ここで、各タスクａ，ｄ，ｇの最悪実行時間（ＷＣＥＴ：Worst Case Execution Time ）を、それぞれWCET#a，WCET#d，WCET#gとし、各メッセージ１，２の最悪実行時間をWCET#1，WCET#2とすると、この分散制御に費やす時間（予測終了時間）Ｔspは以下の（１）式で求まる。
【００５４】
Ｔsp ＝ WCET#a ＋ WCET#d ＋ WCET#g ＋ WCET#1 ＋ WCET#2 （１）
即ち、分散制御に含まれるすべての処理のＷＣＥＴを加算したものが、その分散制御の予測終了時間Ｔspである。そして、この予測終了時間Ｔspを制御周期Ｔcyから減じたものが、余裕時間の初期値Ｍ０（＝Ｔcy−Ｔsp）となり、先頭タスクａが配置されるノードＮＤ１の余裕時間初期設定部１７に記憶される。
【００５５】
なお、余裕時間初期設定部１７がタスクの起動（休止状態→起動状態）時に設定した余裕時間は、余裕時間更新部１６にて逐次更新され、そのタスクが終了（起動状態→休止状態）すると、そのタスクについての余裕時間は、そのタスクにより生成されたメッセージが引き継ぐようにされている。
【００５６】
次に、余裕時間更新部１６が実行する処理を図４に示すフローチャートに沿って説明する。なお、この処理は、余裕時間として管理する最小時間に等しい一定時間毎に周期的に起動される。
本処理が起動すると、まず、タスク制御部１４が管理するタスク群の中に、起動状態（実行待ち、又は実行中）にあり且つ余裕時間の更新を行っていないタスクがあるか否かを判断し（Ｓ１１０）、未更新のタスクがあれば、そのタスクの状態を確認し（Ｓ１２０）、確認した状態に応じて余裕時間の更新を行う（Ｓ１３０）。
【００５７】
そして、更新の結果、余裕時間が予め設定されたしきい値（実行中止判定値）より大きいか否かを判断し（Ｓ１４０）、実行中止判定値より大きければそのままＳ１１０に戻る。一方、余裕時間が実行中止判定値以下であれば、起動状態（実行待ち又は実行中）にあるそのタスクを休止状態に遷移させ（Ｓ１５０）、タスクの終了をタスクスケジューリング部１８に通知した後（Ｓ１６０）、Ｓ１１０に戻る。
【００５８】
先のＳ１１０にて、起動状態にある全てのタスクについて余裕時間の更新が終了するか、或いは起動状態のタスクがなく、未更新のタスクがないと判定された場合には、通信制御部１５が管理するメッセージ群の中に、余裕時間の更新を行っていないメッセージがあるか否かを判断し（Ｓ１７０）、未更新のメッセージがあれば、そのメッセージの状態を確認し（Ｓ１８０）、確認した状態に応じて余裕時間の更新を行う（Ｓ１９０）。
【００５９】
そして、更新の結果、余裕時間が予め設定されたしきい値（送信中止判定値）より大きいか否かを判断し（Ｓ２００）、送信中止判定値より大きければ、そのままＳ１７０に戻る。一方、余裕時間が送信中止判定値以下であれば、送信中又は送信待ちの状態にあるそのメッセージを破棄し（Ｓ２１０）、メッセージの破棄をメッセージスケジューリング部１９に通知した後（Ｓ２２０）、Ｓ１７０に戻る。
【００６０】
また、先のＳ１７０にて、全てのメッセージについて余裕時間の更新が終了するか、或いは送信すべきメッセージがなく、未更新のメッセージがないと判定された場合には、そのまま本処理を終了する。
なお、実行中止判定値及び送信中止判定値は、例えば各タスクで一律にゼロに設定し、余裕時間がなくなった時点で、タスクの実行やメッセージの送信を中止するように設定すればよい。また、以後のタスクの実行やメッセージの送信がＷＣＥＴより早く終了し、余裕時間がゼロ以上に復帰する可能性がある場合には、その範囲内で、実行中止判定値及び中止判定値を、ゼロ以下の値に設定してもよい。
【００６１】
ここで、図５は、Ｓ１３０及びＳ１９０にて実行する余裕時間の更新方法の詳細を示す一覧表であり、監視対象がタスクの場合（Ｓ１３０）、及び監視対象がメッセージの場合（Ｓ１９０）のいずれも、タスク及びメッセージの状態により余裕時間の更新は四つのケースに分類される。
【００６２】
なお、タスクスケジューリング部１８は、実行権を取得し実行中の状態にあるタスクについて、実行権取得後の経過時間（以下「処理実行時間」という）を計測するタイマーと、起動したが実行権が得られず実行待ちの状態にあるタスクのそれぞれについて、起動後の経過時間（以下「処理待機時間」という）を計測するタイマーとを備えているものとする。
【００６３】
また同様に、メッセージスケジューリング部１９も、送信権を取得し送信中の状態にあるメッセージについて、送信権取得後の経過時間（以下「送信実行時間」という）を計測するタイマーと、メッセージが生成されたが送信権が得られず送信待ちの状態にあるメッセージのそれぞれについて、メッセージ生成後の経過時間（以下「送信待機時間」という）を計測するタイマーとを備えているものとする。
【００６４】
まず、監視対象がタスクの場合（Ｓ１３０）の四つのケースについて説明する。
即ち、第１のケースは、タスクが実行待ちの状態にある場合であり、この場合は、時間の経過に従って処理待機時間の増分を余裕時間から減じる。
【００６５】
第２のケースは、タスクが実行中の状態にあり、かつ、タスクの処理実行時間が余裕時間の初期値を求める際に用いたＷＣＥＴに満たない場合であり、この場合は、余裕時間は更新せず、そのままの値を保持する。
第３のケースは、タスクが実行中の状態にあり、かつ、タスクの処理実行時間がＷＣＥＴを超過した場合であり、この場合は、その超過時間分を余裕時間から減ずる。
【００６６】
第４のケースは、実行中の状態にあったタスクがＷＣＥＴより早く処理を終了した場合であり、この場合は、ＷＣＥＴと実行処理時間との差分を余裕時間に加算する。
以下では、これら各ケースについて、図６，７に示すグラフを用いて説明する。
【００６７】
まず、タスクが起動された時には、余裕時間の初期値（以下では「起動時の余裕時間」という）Ｍ０が設定される。このとき、他に優先度の高い（余裕時間の少ない）タスクが存在し、更新対象のタスクが実行待ちの状態になると、第１のケースに相当し、図６に示すように、実行権を取得して処理を開始するまでの間は、その処理待機時間に比例して余裕時間が減少する。そして、タスクの処理待機時間が最終的にＴ０であった場合、実行権を取得して処理を開始した時の余裕時間（以下では「処理開始時の余裕時間」という）は、Ｍ１＝Ｍ０−Ｔ０となる。但し、タスクが起動されたあと直ちに実行権を取得して処理を開始した場合には、処理待機時間はＴ０＝０であるため、処理開始時の余裕時間はＭ１＝Ｍ０となる。
【００６８】
なお、処理開始後、ＷＣＥＴが経過するまでの間は第２のケースに相当し、余裕時間はＭ１のまま保持される。
その後、タスクの処理実行時間が、そのタスクのＷＣＥＴより超過すると、第３のケースに相当し、図７（ａ）に示すように、余裕時間は、ＷＣＥＴを超過した後は、その超過時間に比例して減少し、タスクの処理実行時間が最終的にＷＣＥＴよりＴ１だけ超過した場合、タスクが終了した時点での余裕時間（以下では「処理終了時の余裕時間」という）は、Ｍ２＝Ｍ１−Ｔ１となる。
【００６９】
一方、タスクが終了した時点で、その処理実行時間がＷＣＥＴに満たない場合は、第４のケースに相当し、図７（ｂ）に示すように、ＷＣＥＴよりＴ２だけ早くタスクが終了している時には、処理終了時の余裕時間はＭ２＝Ｍ１＋Ｔ２となる。
【００７０】
なお、ここでは、第３のケースにおいて、タスクの実行中に、ＷＣＥＴからの超過分を余裕時間から逐次減じるようにされているが、タスクの実行が終了した時点で、これを余裕時間から一括して減じるようにしてもよい。
次に、監視対象がメッセージの場合（Ｓ１９０）の四つのケースについて説明する。
【００７１】
即ち、第１のケースは、メッセージが送信待ち状態にある場合であり、この場合は、時間の経過に従って、送信待機時間の増分を余裕時間から減じる。
第２のケースは、メッセージが送信中の状態にあり、かつ、実際に送信が開始されている場合であり、この場合は、余裕時間を更新する必要がないため、余裕時間は更新は行わない。
【００７２】
第３のケースは、メッセージが送信中の状態にあるが、実際には送信が開始されておらず、かつ、次の送信機会で送信に成功したとすると、メッセージの送信処理時間がＷＣＥＴを超過する場合であり、この場合は、その超過時間分を余裕時間から減ずる。
【００７３】
第４のケースは、メッセージが送信中の状態にあるが、実際には送信が開始されておらず、かつ、次の送信機会で送信に成功したとすると、メッセージの送信処理時間がＷＣＥＴに満たない場合であり、この場合は、そのＷＣＥＴと実行処理時間との差分を余裕時間に加算する。
【００７４】
以下では、これら各ケースについて、図８，９に示すグラフを用いて説明する。
まず、メッセージの送信要求がされた時には、余裕時間（以下では「送信要求時の余裕時間」という）として、メッセージを生成したタスクの処理終了時の余裕時間Ｍ２が設定される。このとき、他に優先度の高い（余裕時間の少ない）メッセージが存在し、送信待ちの状態になると、第１のケースに相当し、図８に示すように、送信権を取得して送信を開始するまでの間は、その送信待機時間に比例して余裕時間が減少する。そして、メッセージの送信待機時間が最終的にＴ３であったとすると、送信権を取得して送信中の状態となった時の余裕時間（以下では「送信開始時の余裕時間」という）はＭ３＝Ｍ２−Ｔ３となる。但し、メッセージの送信要求がされたあと直ちに送信権を取得して送信中の状態となった場合は、送信待機時間はＴ３＝０であるため、送信開始時の余裕時間はＭ３＝Ｍ２となる。
【００７５】
このようにして、送信中の状態になり、しかも実際に送信が開始されると、第２のケースに相当し、余裕時間の更新は行われない。
一方、送信中の状態にあるが、第３のケースに相当する場合は、図９（ａ）に示すように、そのメッセージのＷＣＥＴからの超過時間分がＴ４だとすると、余裕時間は、メッセージが次の送信機会で送信が成功したと仮定した時の送信終了時点での余裕時間（以下では「処理終了時の余裕時間」という）Ｍ４（＝Ｍ３−Ｔ４）に更新される。
【００７６】
また、送信中の状態にあるが、第４のケースに相当する場合は、図９（ｂ）に示すように、そのメッセージのＷＣＥＴと送信処理時間との差分がＴ５だとすると、余裕時間は、処理終了時の余裕時間Ｍ４（＝Ｍ３＋Ｔ５）に更新される。
このように構成された本実施形態の分散制御システムでは、各ノードＮＤｉでは、余裕時間の少ないタスクが優先的に実行権を取得すると共に、余裕時間の少ないメッセージが優先的に送信権を取得する。そして、伝送路上では、余裕時間の少ないメッセージを載せたフレームほど優先的に伝送されることになる。
【００７７】
ここで、本実施形態の分散制御システムにおける各ノードのタスク制御及び通信制御の動作例を、図１０に示すタイミング図に沿って説明する。
まず、システム構成として、図３（ａ）に示すように、ノードＮＤ１がタスクａ，ｂ，ｃ、ノードＮＤ２がタスクｄ，ｅ，ｆ、ノードＮＤ３がタスクｇ，ｈ，ｉをそれぞれ実行し、しかも、これら各ノードＮＤ１〜ＮＤ３において、タスクａ（ノードＮＤ１）→タスクｄ（ノードＮＤ２）→タスクｇ（ノードＮＤ３）の順に実行される分散制御１と、タスクｅ（ノードＮＤ２）→タスクｈ（ノードＮＤ２）→タスクｃ（ノードＮＤ１）の順に実行される分散制御２とを並列に実行する場合を仮定する。但し、ここでは理解を容易にするため、全てのタスク及び全てのメッセージが、いずれも余裕時間の初期値の算出に用いたＷＣＥＴ通りの時間で処理されるものとする。
【００７８】
図１０に示すように、まず、時刻Ｔ１にて、分散制御１の開始が要求されると、ノードＮＤ１上でタスクａの処理が開始される。
このタスクａの処理が、時刻Ｔ２にて終了すると、タスクａにより生成されたメッセージ１の送信が開始される。この間（Ｔ１〜Ｔ２）、タスクａは、実行待ち状態となることなく処理が実行されたため、分散制御１の余裕時間に増減はない。
【００７９】
メッセージ１はノードＮＤ２にて受信され、時刻Ｔ３にて、そのメッセージ１の通信が終了すると、ノードＮＤ２は、メッセージ１が属する分散制御１に対応したタスクｄの処理を起動する。この間（Ｔ２〜Ｔ３）、メッセージ１は送信待ち状態となることなく送信が実行されたため、分散制御１の余裕時間に増減はない。
【００８０】
その後、時刻Ｔ４にて、ノードＮＤ２上で分散制御２の開始が要求されると、タスクｅの処理が起動される。このとき、分散制御１の余裕時間と分散制御２の余裕時間とを比較すると、分散制御２の余裕時間の方が少ないため、実行中のタスクｄ（分散制御１）は中断され実行待ち状態となり、代わりにタスクｅ（分散制御２）の実行を開始する。
【００８１】
このタスクｅの処理が、時刻Ｔ５にて終了すると、タスクｅにより生成されたメッセージ２の送信が開始されると共に、中断していたタスクｄの処理が再開される。この間（Ｔ４〜Ｔ５）、タスクｅは、実行待ち状態になることなく処理が実行されたため、分散制御２の余裕時間に増減はなく、一方、実行待ち状態であったタスクｄは処理を中断していたため、分散制御１の余裕時間は、その中断時間分（Ｔ５−Ｔ４）だけ減少する。
【００８２】
再開されたタスクｄの処理が、時刻Ｔ６にて終了すると、タスクｄにより生成されたメッセージ３の送信が要求される。このとき、より余裕時間の少ない分散制御２に属するメッセージ２の送信中であるため、メッセージ３は送信待ち状態となる。
【００８３】
その後、時刻Ｔ７にて、メッセージ２の通信が終了すると、これを受信したノードＮＤ３は、メッセージ２が属する分散制御２に対応したタスクｈの処理を開始し、一方、ノードＮＤ２では、送信待ち状態にあったメッセージ３の送信を開始する。この間（Ｔ５〜Ｔ７）、メッセージ２は送信待ち状態となることなく送信が実行されたため、分散制御２の余裕時間に増減はない。一方、メッセージ３は、タスクｄの処理終了（Ｔ６）からメッセージ２の通信終了（Ｔ７）までの間、送信待ち状態となったため、分散制御１の余裕時間は、その待ち時間分（Ｔ７−Ｔ６）だけ減少する。
【００８４】
そして、時刻Ｔ８にて、メッセージ３の通信が終了すると、これを受信したノードＮＤ３は、メッセージ３が属する分散制御１に対応したタスクｇの処理を起動する。この時、より余裕時間が少ない分散制御２に属するタスクｈの処理が既に実行中であるため、タスクｇは実行待ち状態となる。
【００８５】
その後、時刻Ｔ９にて、タスクｈの処理が終了すると、タスクｈにより生成されたメッセージ４の送信が開始されると共に、実行待ち状態にあったタスクｇの処理が開始される。この間（Ｔ７〜Ｔ９）、タスクｈは実行待ち状態になることなく処理が実行されたため、分散制御２の余裕時間に増減はなく、一方、タスクｇは、メッセージ３の通信終了（Ｔ８）からタスクｈの処理終了（Ｔ９）までの間、実行待ち状態となったため、分散制御１の余裕時間は、その待ち時間分（Ｔ９−Ｔ８）だけ減少する。
【００８６】
時刻Ｔ１０にて、メッセージ４の通信が終了すると、これを受信したノードＮＤ１は、メッセージ４が属する分散制御２に対応したタスクｃの処理を開始し、このタスクｃの処理が時刻Ｔ１２にて終了することにより、分散制御２についての一連の処理が終了する。この間（Ｔ９〜Ｔ１２）、メッセージ４及びタスクｃは、いずれも通信待ち状態や実行待ち状態になることなく処理されるため、分散制御２の余裕時間に増減はなく、結局、分散制御２は、デッドラインの条件を満たした時間内で処理される。
【００８７】
また、タスクｇの処理が時刻Ｔ１１にて終了することにより、分散制御１についての一連の処理が終了する。この間（Ｔ９〜Ｔ１）、実行待ち状態になることなく処理されるため、分散制御１の余裕時間に増減はなく、結局、分散制御１は、（Ｔ５−Ｔ４）＋（Ｔ７−Ｔ６）＋（Ｔ９−Ｔ８）だけ、余裕時間が減少するが、デッドラインの条件を満たした時間内で処理される。
【００８８】
以上説明したように、本実施形態の分散制御システムでは、システム上で実行される分散制御のそれぞれについて、その分散制御の実行に必要なタスクの処理時間、及びメッセージの送信時間のＷＣＥＴを全て加算してなる予測終了時間Ｔspと、その分散制御についてのデッドラインまでの時間Ｔcyとの差分を表す余裕時間を設定し、その余裕時間の少ないタスクやメッセージから優先的に処理や送信を実行するようにされている。
【００８９】
つまり、低優先度に設定されたタスクが常に後回しにされてしまう従来装置とは異なり、全ての分散制御がデッドラインの条件を満たすように、タスクやメッセージの優先度が常に変化する。
従って、各タスクの処理時刻やメッセージの送信時刻を予め決定しておかなくても、デッドラインの条件を満たすような順番で効率よくタスクの処理やメッセージの送信を実行させることができる。
【００９０】
その結果、システムを実際に動作させた結果、デッドラインの条件を満たすことができない場合には、タスクやメッセージの優先度を考慮した設計変更を行う必要がなく、そのデッドラインからの遅れ分だけＣＰＵの処理速度やメッセージの伝送速度を高速化しさえすればよいため、分散制御システムの開発工数を大幅に削減できる。
【００９１】
また、本実施形態では、余裕時間が予め設定された実行中止判定値や送信中止判定値以下である時は、これに対応するタスクの実行やメッセージの送信を中止することで、その分散制御を中止するようにされている。
従って、デッドラインの条件を満たすことができないことが明らかな分散制御が継続して実行されることにより、他の分散制御の余裕時間が削られ、これら他の分散制御にも悪影響を与えてしまうことを確実に防止できる。
【００９２】
また、本実施形態では、余裕時間に対応した時間情報を、メッセージと共にフレームに挿入し、しかも、その時間情報を調停の際に優先度を決める情報として用いており、伝送路上でも、余裕時間の少ない分散制御についてのメッセージが優先的に送信されるため、余裕時間の少ない分散制御が、途中でデッドラインの条件を満たすことができずに、中止されてしまう可能性を大幅に削減することができる。
［第２実施形態］
次に第２実施形態について説明する。
【００９３】
本実施形態では、実行するタスクの構成、及び余裕時間更新部１６が実行する処理の一部が第１実施形態とは異なるだけであるため、この相異する部分を中心に説明する。
即ち、本実施形態においては、タスク制御部１４が管理するタスクとして、通常時に実行する通常タスクの他、通常タスクのそれぞれに対して、その通常タスクの処理を一部省略したり、その処理をより簡易なものに置き換えることにより、通常タスクより実行時間が短くなるように構成された簡易タスクが用意されている。
【００９４】
そして、余裕時間更新部１６では、第１実施形態にて説明した図４のＳ１４０にて、余裕時間が実行中止判定値より大きいと判定された場合に、その余裕時間が、予め設定されたタスク切替判定値以下であり、且つそのタスクが実行待ち状態である場合に、そのタスクが通常タスクであれば、これを簡易タスクに切り替えるように構成されている。
【００９５】
これと同様に、図４のＳ２００にて、余裕時間が送信中止判定値より大きいと判定された場合に、その余裕時間が、予め設定されたメッセージ切替判定値以下であり、且つそのメッセージが実際に送信が行われていない場合に、そのメッセージが通常メッセージであれば、これを簡易メッセージに切り替えるように構成されている。
【００９６】
なお、簡易メッセージとは、メッセージに含ませるべき情報の一部を省略したものであり、この簡易メッセージを受けたタスクは、省略された情報については、デフォルト値、前回の処理で使用した値、或いはその値からの推定値などを用いて処理を実行するように構成されている。
【００９７】
ここで、本実施形態の分散制御システムにおける各ノードのタスク制御及び通信制御の動作例を、図１２に示すタイミング図に沿って説明する。
但し、そのシステム構成は、図１１に示すように、図３（ａ）に示したものとほぼ同様であるが、ノードＮＤ２が実行するタスクｅについては、これと対になる簡易タスクｅ’が用意されていると共に、簡易メッセージも用意されている。そして、各ノードＮＤ１〜ＮＤ３において、タスクａ（ノードＮＤ１）→タスクｄ（ノードＮＤ２）の順に実行される分散制御１と、タスクｅ（ノードＮＤ２）→タスクｉ（ノードＮＤ３）の順に実行される分散制御２とを並列に実行する場合を仮定する。
【００９８】
また、ここでは理解を容易にするため、全てのタスク及びメッセージが、いずれも余裕時間の初期値の算出に用いたＷＣＥＴ通りの時間で処理されるものとする。また、タスク切替判定値及びメッセージ切替判定値はゼロに設定され、実行中止判定値及び送信中止判定値は、それ以後の処理が、全て簡易タスク及び簡易メッセージにて実行されたとして、余裕時間ゼロに復帰できる下限値に設定されているものとする。更に、タスクｉには、簡易タスクが用意されていないため、その実行中止判定値はゼロに設定されているものとする。
【００９９】
図１２に示すように、時刻Ｔ１から時刻Ｔ３までは、第１実施形態において図１０を用いて説明した場合と全く同様であるため、その説明を省略する。
そして、時刻Ｔ３にて、タスクｄの処理が開始された後、時刻Ｔ４にて、ノードＮＤ２に対する外部からの割込が発生すると、タスクｄの処理は中断され実行待ち状態となり、割込処理が開始される。
【０１００】
更に、この割込処理の実行中の時刻Ｔ５に、分散制御２の開始が要求されると、タスクｅが起動される。しかし、割り込み処理が実行されているため、タスクｅも実行待ち状態となる。
その後、時刻Ｔ６にて割込処理が終了すると、実行待ち状態にあるタスクのうち、より余裕時間の少ない分散制御２に属するタスクが選択され、そのタスクの処理が開始される。この間（Ｔ４〜Ｔ６）、分散制御２のタスクは、その起動（Ｔ５）から割込処理の終了（Ｔ６）まで、実行待ち状態となり処理を中断していたため、分散制御２の余裕時間は、その中断時間分（Ｔ６−Ｔ５）だけ減少する。これにより、分散制御２の余裕時間は、タスク切替判定値より小さくなっているため、分散制御２では、通常タスクｅに代えて、簡易タスクｅ’が実行される。
【０１０１】
この簡易タスクｅ’の処理が、時刻Ｔ７にて終了すると、タスクｅ’はタスクｅのＷＣＥＴより短い時間で処理が終了するため、分散制御２の余裕時間は、その差分だけ増加する。しかし、その余裕時間は、メッセージ切替判定値以下であるため、通常のメッセージ２に代えて簡易メッセージ２’の送信が開始される。
【０１０２】
これと共に、中断していたタスクｄの処理が再開される。この間（Ｔ４〜Ｔ７）、タスクｄは、実行待ち状態となり処理を中断していたため、分散制御１の余裕時間は、その中断時間分（Ｔ７−Ｔ４）だけ減少する。
その後、再開されたタスクｄの処理が、時刻Ｔ８にて終了することにより、分散制御１についての一連の処理が終了する。この間（Ｔ７〜Ｔ８）、タスクｄは、実行待ち状態になることなく処理されるため、分散制御１の余裕時間に増減はなく、結局、分散制御１は、（Ｔ７−Ｔ４）だけ、余裕時間が減少するが、デッドラインの条件を満たした時間内で処理される。
【０１０３】
また、メッセージ２’がノードＮＤ３で受信され、時刻Ｔ９にて、その通信が終了すると、メッセージ２’は通常のメッセージ２のＷＣＥＴより短い時間で通信が終了するため、分散制御の余裕時間は、その差分だけ増加する。これにより、その余裕時間が、実行中止判定値より大きいため、タスクｉの処理が開始される。
【０１０４】
このタスクｉの処理が時刻Ｔ１０にて終了することにより、分散制御２についての一連の処理が終了する。この間（Ｔ９〜Ｔ１０）、タスクｉは実行待ち状態になることなく処理されるため、分散制御２の余裕時間に増減はない。つまり、分散制御２は、一旦、余裕時間ゼロを下回ったにも関わらず、簡易タスク，簡易メッセージを使用することにより、最終的には、デッドラインの条件を満たした時間内で処理される。
【０１０５】
以上説明したように、本実施形態の分散制御システムによれば、システム上で実行される分散制御のそれぞれについて、余裕時間を設定し、その余裕時間の少ないタスクやメッセージから優先的に処理や送信を実行し、余裕時間が実効中止判定値や送信中止判定値以下である時は、これに対応するタスクの実行やメッセージの送信を中止するようにされているため、第１実施形態と同様の効果を得ることができる。
【０１０６】
しかも本実施形態では、余裕時間が、タスク切替判定値やメッセージ切替判定値以下である時は、これに対応するタスクやメッセージを、実行時間や通信時間の短い簡易タスクや簡易メッセージに切り替えるようにされている。
従って、余裕時間から、デッドラインの条件を満たすことが困難であることが予測される場合でも、その時点で、簡易タスクや簡易メッセージに切り替えることにより、通常のタスクやメッセージで処理を行った場合との時間差分だけ、余裕時間を余分に確保することが可能となり、分散制御が、実行の途中で中止される可能性を大幅に低減することができる。
【０１０７】
換言すれば、常に各分散制御のデッドラインに対する余裕時間を知ることができるため、デッドライン違反を予測し、デッドライン違反に基づくＱｏＳ（Quality of Service）制御が可能となり、故障、ソフトウェアのバグ等に対するシステムのフォールトトレランス性を向上させることができる。また、従来のデッドラインを考慮しないリアルタイムＯＳ，ＣＳＭＡ／ＣＡを利用した分散制御システムと比較して、システム負荷がより高い場合でも、デッドラインの保証が可能となる。
【０１０８】
ここで、図１３は、リアルタイムＯＳとＣＳＭＡ／ＣＡとを用いた従来の分散制御システムと、第１実施形態に示した分散制御システムとで、シミュレーションにより処理能力を比較した結果を表すグラフである。
なお、シミュレーションにおいては、図１４（ａ）に示すように、６つのノードから構成されるシステムを仮定し、１２の分散制御を、図１４（ｂ）に示す条件（タスク数，メッセージ数，制御周期）で並列に実行させた。
【０１０９】
図１３では、横軸が各ノードのＣＰＵの動作周波数（すべてのノードのＣＰＵが同一周波数で動作することとする）、縦軸がメッセージを送信する際の通信レートである。そして、デッドラインを保証できる範囲を、本発明を適用した分散制御システムについては平行斜線のハッチングで示し、従来の分散制御システムについてはクロス斜線のハッチングで示した。
【０１１０】
このシミュレーションにより、本発明を適用した分散制御システムでは、従来システムと比較して、より低いＣＰＵ動作周波数、および通信レートでデッドラインを保証することが可能であることが確認された。
【図面の簡単な説明】
【図１】 第１実施形態の分散制御システムを構成するノードの内部構成を示すブロック図である。
【図２】 ネットワーク上で伝送されるフレームの構成を示す説明図である。
【図３】 余裕時間の算出方法を示す説明図である。
【図４】 余裕時間更新部が実行する処理の概要を示すフローチャートである。
【図５】 余裕時間の更新方法の詳細を示す一覧表である。
【図６】 タスクが実行待ち状態の時における余裕時間の更新方法を示す説明図である。
【図７】 タスクの実行時間がＷＣＥＴより長い時及び短い時における余裕時間の更新方法を示す説明図である。
【図８】 メッセージが送信待ち状態の時における余裕時間の更新方法を示す説明図である。
【図９】 メッセージの通信時間がＷＣＥＴより長い時及び短い時における余裕時間の更新方法を示す説明図である。
【図１０】 第１実施形態の分散制御システムの動作例を示すタイミング図である。
【図１１】 第２実施形態の分散制御システムの動作例を示すタイミング図である。
【図１２】 図１１に示す動作の前提となるシステム構成を示す説明図である。
【図１３】 従来システムとの効果の差を比較するために行ったシミュレーションの結果を示すグラフである。
【図１４】 シミュレーションの条件を示す図表である。
【図１５】 メッセージスケジューリング、及びタスクスケジューリングの具体例を示す説明図である。
【符号の説明】
１２…タスク群 １３…メッセージ群 １４…タスク制御部
１５…通信制御部 １６…余裕時間更新部 １７…余裕時間初期設定部
１８…タスクスケジューリング部 １９…メッセージスケジューリング部
２０…メッセージ送受信部 ＮＤｉ…ノード ＮＴ…ネットワーク
【発明の属する技術分野】
共通の多重伝送路に接続されたマルチタスキング動作が可能な複数個のノードにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことにより協調動作して分散制御を実行する分散制御方法及び装置に関する。
【０００２】
【従来の技術】
従来より、車内ＬＡＮ等の処理速度や処理時間保証に対する要求条件の厳しい分野において、共通の多重伝送路に接続された複数のノードに分散制御を実行させる分散制御システムを構成する場合、各ノードにマルチタスキング動作をさせるためのリアルタイムオペレーティングシステム（以下「リアルタイムＯＳ」という）や、ノード間の通信をリアルタイムで行うための通信方式であるＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance ）が利用されている。
【０００３】
このうちリアルタイムＯＳは、各タスクに対して予め優先度を設定し、その優先度の高いタスクからノードでの実行権（ＣＰＵでの実行権）が割り当てられるようスケジューリングを行うものである。また、ＣＳＭＡ／ＣＡは、通信に用いる各メッセージに対して予め優先度に相当するＩＤを設定し、複数のノードが同時にメッセージを送信した時は、最も優先度の高いＩＤを持つメッセージが伝送路上で破壊されることなく生き残るように調停を行う通信方式であり、優先度の高いメッセージから送信されるように通信制御を行うものである。
【０００４】
このように、リアルタイムＯＳ、ＣＳＭＡ／ＣＡを組み合わせた方法では、処理時間の厳しいタスクやメッセージほど、高い優先度を割り当てることで、システム全体としてのリアルタイム性が向上する。
また、上述の方法以外に、各ノードにて分散して実行される分散制御が、要求されたデッドラインの条件を満たすように、すべてのノードにおける個々のタスクの起動時刻、及び各ノード間のメッセージの通信時刻を予め設定し、その設定に従って動作させる、いわゆるタイムトリガー方式を用いた分散制御システムも知られている。
【０００５】
このタイムトリガー方式については、例えば以下の文献で紹介されている。
S.Poledna, et.al.,"OSEKtime: A Dependable Real-Time Fault-Tolerant Operating System and Communication layer as an Enabling Technology for By-Wire Applications", SAE2000-01-1051
Thomas Fuehrer,"The Steer-By-Wire Prototype Implementation:Realizing Time Triggered System Design, FailSilence Behavior and Active Replication withFault-Tolerance Support", SAE1999-01-0400
この方式を用いた分散制御システムでは、ノード内でのタスクの競合、ノード間の通信の競合が排除され、システムの不確定動作がなくなるため処理時間の保証が可能となる。
【０００６】
【発明が解決しようとする課題】
ところで、リアルタイムＯＳとＣＭＳＡ／ＣＡとを用いた前者の分散制御システムは、ＣＰＵの能力範囲内で優先度の高いタスクからできる限りの処理を実行するベストエフォート型の動作をするものであるため、各タスクの処理やメッセージの通信が規定時間内に終了するか否かの保証はできない。
【０００７】
このため、分散制御が、要求されたデッドラインの条件を満たすことを保証するには、実際にシステムを動作させて実証しなければならない。そして、その性能を保証することができない場合には、タスクやメッセージの優先度、ＣＰＵの動作周波数、通信の転送レート等の変更が必要となる。
【０００８】
しかし、タスクやメッセージの優先度の変更が、全体の制御にどのような影響を与えるかを明確に規定することは困難であり、結局、トライアンドエラーでの優先度の変更等を行わなければならないため、開発工数の増大を招くという問題があった。
【０００９】
また、タスクやメッセージの優先度が最適化されていない状態では、要求されたデッドラインの条件を満たそうとすると、ＣＰＵの動作周波数や伝送路上の通信レートが必要以上に高速なものに設定されることになるため、製造コストも増大するという問題もあった。
【００１０】
一方、タイムトリガー方式を用いた後者の分散制御システムでは、各ノード上で動作するタスクの起動時刻、ノード間の通信時刻をすべて設計者（ユーザ）が決定しなくてはならず、システム上で並列動作する複数の分散制御が要求する応答時間、制御周期等をすべて満たそうとすると、その設計には膨大な時間を要するため開発工数の増大を招くという問題があった。
【００１１】
また、タイムトリガー方式では、ある非同期のイベントをトリガーとして開始する分散制御に対しても、常にそのイベントが発生するものとして固定的にタスクの起動時刻、通信時刻をスケジューリングしなければならない。このため、ノード上のＣＰＵの処理や伝送路上での通信に過大なオーバヘッドが必要となり、ＣＰＵや伝送路の使用効率が低下するだけでなく、非同期イベントが入力されても、予めスケジューリングされた時刻まで待たなければ、そのイベントに対する処理を開始することができないため、そのような非同期イベントに対する処理のリアルタイム性の保証が難しくなるという問題もあった。
【００１２】
本発明は、上記問題点を解決するために、分散制御システムの設計者に過大な負担を強いることなく、分散制御が要求する応答時間やデッドラインの条件を保証できる分散制御方法及び装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
上記目的を達成するためになされた発明である請求項１記載の分散制御方法では、ＣＳＭＡ／ＣＡ方式を適用したフレームによりメッセージを伝送する共通の多重伝送路に接続されたマルチタスキング動作が可能な複数のノードにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことで協調して時系列に動作することにより分散制御を行う。
また、各ノードにおいて、実行可能なタスクのそれぞれについて、タスクがその一部を分担する分散制御についての予測終了時間と、その分散制御についてのデッドラインとの差分を表す余裕時間を設定し、その余裕時間の小さいタスクから優先的に実行権を割り当てると共に、送信可能なメッセージのそれぞれについて、メッセージが属する分散制御についての余裕時間（以下「メッセージについての余裕時間」という）に基づき、その余裕時間の小さいものから優先的にメッセージの送信権を割り当てるようにされている。
【００１４】
つまり、低優先度に設定されたタスクやメッセージが常に後回しにされてしまう従来装置とは異なり、全ての分散制御がデッドラインの条件を満たすように、タスクやメッセージの優先度が常に変化する。
従って、各タスクの処理時刻やメッセージの送信時刻を予め決定しておかなくても、デッドラインの条件を満たすような順番で効率よく処理や送信が実行されることになる。このため、実際に動作させた結果、デッドラインの条件を満たすことができない場合には、そのデッドラインからの遅れ分だけＣＰＵの処理速度やメッセージの伝送速度を高速化しさえすればよく、分散制御システムの開発工数を大幅に削減できる。
【００１５】
また、請求項１記載の分散制御方法では、メッセージを送信する際には、そのメッセージについての余裕時間を表す時間情報を、フレームのうち伝送路上での調停制御のために用いられる領域に挿入してメッセージと共に送信し、また、タスクの起動時にはそのタスクについての余裕時間として、分散制御の最初に起動される先頭タスクの場合は、予め用意された余裕時間の初期値を設定し、メッセージの受信により起動される非先頭タスクの場合は、そのメッセージに挿入された時間情報に基づく値を設定するようにされている。
【００１６】
つまり、余裕時間が小さいほど、伝送路上での優先度が高くなるように時間情報をコード化すれば、伝送路上でも、余裕時間の小さいメッセージが優先的に伝送されることになり、分散制御システムのリアルタイム性をより向上させることができる。
【００１７】
なお、時間情報としては、余裕時間をそのまま使用してもよいし、余裕時間を表すビットデータの一部のビット（例えば上位の数ビット）のみを使用してもよい。また、その余裕時間を表すデータを、例えばログスケールで変換する等した値を用いてもよい。
【００２５】
ところで、余裕時間は、タスクの実行状態に応じて更新するだけでなく、メッセージの処理状態に応じて更新する必要がある。
【００２６】
例えば、複数のメッセージの送信が要求された場合、通信権を持つ唯一のメッセージについては、その余裕時間を保持し、ノード内で他のノードへの通信権の取得待ちの状態にある他のメッセージについては、請求項２記載のように、その余裕時間を、通信権を取得するまでの間、時間の経過と共に減少させればよい。
【００２７】
また、通信権を取得したメッセージについては、請求項３記載のように、ノード内で他のノードへの通信件を獲得したメッセージについて、次の送信機会で共通伝送路での調停に勝ち、他のノードがメッセージを受信できたと仮定した時の通信終了までに要する予測通信時間が、そのメッセージについて予め設定された最悪通信時間に満たない時は、そのメッセージについての余裕時間を、最悪通信時間と予測通信時間との差分だけ増加させ、逆に、予測通信時間が最悪通信時間を越えている時は、そのメッセージについての余裕時間を、その差分だけ減少させればよい。
【００２８】
なお、実際の通信時間ではなく、予測通信時間を用いているのは、後述するように、メッセージと共にその余裕時間を送信する場合、送信終了後に余裕時間を更新しても、その更新した余裕時間をメッセージと共に送信することができないからである。
【００３３】
次に、請求項４記載の分散制御装置では、ＣＳＭＡ／ＣＡ方式を適用したフレームによりメッセージを伝送するマルチタスキング動作をする各タスクが、共通の多重伝送路に接続された他の装置上で動作する他のタスクと、互いにメッセージを通信し合うことにより協調動作して分散制御を実行する。
そして、起動時設定手段が、分散制御にて最初に実行される先頭タスクの起動時には、予め用意された余裕時間の初期値を、そのタスクについての余裕時間として設定し、一方、メッセージ送受信手段にてメッセージが受信されることよる非先頭タスクの起動時には、そのメッセージと共に受信した時間情報に基づく値を、そのタスクについての余裕時間として設定する。
【００３４】
そして、タスクスケジューリング手段は、このようにして起動され実行可能となったタスクを、各タスクに設定された余裕時間に基づいて、その余裕時間の小さいタスクから優先的に実行権を割り当てる。なお、余裕時間は、第１更新手段により、タスクスケジューリング手段による各タスクの実行状態に応じて逐次更新される。
【００３５】
また、メッセージ送受信手段は、タスクが生成するメッセージについての余裕時間を、フレームのうち伝送路上での調停制御のために用いられる領域に挿入してメッセージと共に多重伝送路を介して送信し、他の装置からのメッセージを受信した時には、該メッセージに対応するタスクの起動を前記タスクスケジューリング手段に要求する。
そして、メッセージを多重伝送路を介して受信した他の装置が、同様の処理を繰り返すことにより分散制御が実現する。
【００３６】
また、メッセージスケジューリング手段が、メッセージについての余裕時間に基づいて、その余裕時間の小さいものから優先的に、メッセージ送受信手段でのメッセージの送信権を割り当てる。なお、余裕時間は、第２更新手段により、メッセージ送受信手段による各メッセージの送信の実行状態に応じて逐次更新される。
【００３８】
即ち、請求項４記載の分散制御装置は、請求項１〜３記載の分散制御方法を実現するものであり、これと同様の効果を得ることができる。
【００３９】
【発明の実施の形態】
以下に本発明の実施形態を図面と共に説明する。
［第１実施形態］
図１は、分散制御システムを構成する分散制御装置としてのノードの内部構成を表すブロック図である。
【００４０】
図１に示すように、本実施形態の分散制御システムは、ネットワークＮＴを介して接続された複数のノードＮＤｉ（図中では一つのみ示す）により構成され、各ノードＮＤｉは互いに連係して複数の分散制御を並列に実行するようにされている。
【００４１】
ここで分散制御とは、複数のノードＮＤｉにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことで協調して時系列で動作することにより実現される一連の制御のことを意味する。つまり、時系列上で隣り合うタスクが互いに異なるノードに配置されている場合には、タスク間でメッセージの通信が行われることになる。
【００４２】
そして、各ノードＮＤｉは、いずれも同様の構成をしており、タスクの集合であるタスク群１２を管理するタスク制御部１４と、タスク群１２を構成する各タスクが生成したメッセージの集合であるメッセージ群１３を管理する通信制御部１５と、各分散制御に対応してタスクやメッセージについて設定される余裕時間（後述する）を逐次更新する第１及び第２更新手段としての余裕時間更新部１６とを備えている。
【００４３】
このうち、通信制御部１５は、各タスクが生成したメッセージをネットワークＮＴを介して送受信するメッセージ送受信手段としてのメッセージ送受信部２０と、余裕時間更新部１６が更新する余裕時間に基づいて、余裕時間の小さいものに対して優先的に、メッセージ送受信部２０でのメッセージの送信権を与えるメッセージスケジューリング手段としてのメッセージスケジューリング部１９とを備えている。
【００４４】
つまり、メッセージスケジューリング部１９では、例えば図１５（ａ）に示すように、余裕時間が１２０ｍｓのメッセージＡ、余裕時間が１８０ｍｓのメッセージＢ、余裕時間が１００ｍｓのメッセージＣが存在する場合、送信待ちメッセージの待ち行列上に、メッセージＣ、メッセージＡ、メッセージＢの順番にメッセージを整列し、先頭のメッセージＣの送信をメッセージ送受信部２０に実施させる。
【００４５】
その後、余裕時間更新部１６により各メッセージの余裕時間が更新され、その結果、メッセージＣよりメッセージＡの方が余裕時間が小さくなった場合、メッセージ送受信部２０においてメッセージＣが調停負けにより未だ送信されていない場合は、メッセージＣより先にメッセージＡの送信をメッセージ送受信部２０に実施させる。
【００４６】
ここで、図２は、メッセージ送受信部２０が、ネットワークＮＴを介して送受信するフレームの構成を示す説明図である。なお、このフレームは、ＣＳＭＡ／ＣＡ方式の通信制御を行うためのものであり、伝送路上での調停制御に使用するＩＤ領域以外は、周知の構成であるため、このＩＤ領域についてのみ説明する。即ち、メッセージ送受信部２０が送受信するフレームのＩＤ領域は、前半部分と後半部分とに分割されており、前半部分に余裕時間に応じた時間情報が挿入され、後半部分にメッセージを識別するための認識用ＩＤが挿入されている。
【００４７】
つまり、メッセージ送受信部２０が生成するフレームには、タスクが生成したメッセージと共に、そのメッセージが属する分散制御についての余裕時間を表す時間情報が挿入されることになる。そして、複数のノードＮＤｉから同時にフレームが送信された時には、時間情報（余裕時間）として挿入された値が最も小さいフレームが伝送路上で破壊されることなく生き残って送信権を取得することになり、送信権を取得できなかった他のフレームは、次の送信機会（送信中のフレームの送信終了タイミング）を待つことになる。
【００４８】
次に、タスク制御部１４は、図１に示すように、タスクの起動時に、そのタスクに対して、そのタスクがその一部を分担する分散制御についての余裕時間を設定する余裕時間初期設定部１７と、いわゆるリアルタイムＯＳからなり、各タスクに付与された優先度に従って、順次各タスクに実行権を与えるタスクスケジューリング部１８とを備えている。
【００４９】
なお、タスクスケジューリング部１８では、優先度として余裕時間を用いており、この余裕時間の小さいタスクほど、優先的に実行権が与えられる。
例えば、図１５（ｂ）に示すように、余裕時間が１００ｍｓのタスクＡ、余裕時間が５０ｍｓのタスクＢ、余裕時間が８０ｍｓのタスクＣが同時に起動している場合、タスクスケジューリング部１８は、実行待ちタスクの待ち行列上に、タスクＢ、タスクＣ、タスクＡの順番にタスクを整列し、先頭のタスクＢの処理をＣＰＵ上で実行する。そして、余裕時間更新部１６により余裕時間が更新され、その結果、タスクＢよりタスクＣの方が余裕時間が小さくなった場合には、タスクＢの実行を中断し、タスクＣの実行を開始させる。
【００５０】
また、余裕時間初期設定部１７は、管理するタスクの中に、分散制御において最初に実行される（時系列の先頭に位置する）タスクである先頭タスクがある場合に、その先頭タスクが属する分散制御についての余裕時間の初期値を記憶している。そして、タスクの起動要求が発生すると、そのタスクの余裕時間として、そのタスクが先頭タスクである場合には、予め記憶されている余裕時間の初期値を設定し、一方、そのタスクがメッセージの受信に基づく非先頭タスクである場合には、受信したメッセージに示された時間情報に基づく値を設定する。
【００５１】
ここで図３は、余裕時間の初期値の求め方を示す説明図である。ここでは、図３（ａ）に示すように、ノードＮＤ１がタスクａ〜ｃ、ノードＮＤ２がタスクｄ〜ｅ、ノードＮＤ３がタスクｇ〜ｉをそれぞれ実行し、このうちノードＮＤ１のタスクａ、ノードＮＤ２のタスクｄ、ノードＮＤ３のタスクｇが、タスクａを先頭タスクとして、タスクｄ，タスクｇの順に処理を実行することで分散制御を行うものとする。
【００５２】
この場合、各タスクａ，ｄ，ｇは、それぞれが異なるノードＮＤ１〜ＮＤ３に配置されているため、図３（ｂ）に示すように、タスクａとタスクｄの処理間ではメッセージ１の通信が、タスクｄとタスクｇの処理間ではメッセージ２の通信が生じる。また、この分散制御では、タスクａの処理開始を基点とした制御周期Ｔcyにより求まるデッドラインが存在し、時系列の末尾にあるタスクｇの処理が、このデッドラインより前に終了しなければならないものとする。
【００５３】
ここで、各タスクａ，ｄ，ｇの最悪実行時間（ＷＣＥＴ：Worst Case Execution Time ）を、それぞれWCET#a，WCET#d，WCET#gとし、各メッセージ１，２の最悪実行時間をWCET#1，WCET#2とすると、この分散制御に費やす時間（予測終了時間）Ｔspは以下の（１）式で求まる。
【００５４】
Ｔsp ＝ WCET#a ＋ WCET#d ＋ WCET#g ＋ WCET#1 ＋ WCET#2 （１）
即ち、分散制御に含まれるすべての処理のＷＣＥＴを加算したものが、その分散制御の予測終了時間Ｔspである。そして、この予測終了時間Ｔspを制御周期Ｔcyから減じたものが、余裕時間の初期値Ｍ０（＝Ｔcy−Ｔsp）となり、先頭タスクａが配置されるノードＮＤ１の余裕時間初期設定部１７に記憶される。
【００５５】
なお、余裕時間初期設定部１７がタスクの起動（休止状態→起動状態）時に設定した余裕時間は、余裕時間更新部１６にて逐次更新され、そのタスクが終了（起動状態→休止状態）すると、そのタスクについての余裕時間は、そのタスクにより生成されたメッセージが引き継ぐようにされている。
【００５６】
次に、余裕時間更新部１６が実行する処理を図４に示すフローチャートに沿って説明する。なお、この処理は、余裕時間として管理する最小時間に等しい一定時間毎に周期的に起動される。
本処理が起動すると、まず、タスク制御部１４が管理するタスク群の中に、起動状態（実行待ち、又は実行中）にあり且つ余裕時間の更新を行っていないタスクがあるか否かを判断し（Ｓ１１０）、未更新のタスクがあれば、そのタスクの状態を確認し（Ｓ１２０）、確認した状態に応じて余裕時間の更新を行う（Ｓ１３０）。
【００５７】
そして、更新の結果、余裕時間が予め設定されたしきい値（実行中止判定値）より大きいか否かを判断し（Ｓ１４０）、実行中止判定値より大きければそのままＳ１１０に戻る。一方、余裕時間が実行中止判定値以下であれば、起動状態（実行待ち又は実行中）にあるそのタスクを休止状態に遷移させ（Ｓ１５０）、タスクの終了をタスクスケジューリング部１８に通知した後（Ｓ１６０）、Ｓ１１０に戻る。
【００５８】
先のＳ１１０にて、起動状態にある全てのタスクについて余裕時間の更新が終了するか、或いは起動状態のタスクがなく、未更新のタスクがないと判定された場合には、通信制御部１５が管理するメッセージ群の中に、余裕時間の更新を行っていないメッセージがあるか否かを判断し（Ｓ１７０）、未更新のメッセージがあれば、そのメッセージの状態を確認し（Ｓ１８０）、確認した状態に応じて余裕時間の更新を行う（Ｓ１９０）。
【００５９】
そして、更新の結果、余裕時間が予め設定されたしきい値（送信中止判定値）より大きいか否かを判断し（Ｓ２００）、送信中止判定値より大きければ、そのままＳ１７０に戻る。一方、余裕時間が送信中止判定値以下であれば、送信中又は送信待ちの状態にあるそのメッセージを破棄し（Ｓ２１０）、メッセージの破棄をメッセージスケジューリング部１９に通知した後（Ｓ２２０）、Ｓ１７０に戻る。
【００６０】
また、先のＳ１７０にて、全てのメッセージについて余裕時間の更新が終了するか、或いは送信すべきメッセージがなく、未更新のメッセージがないと判定された場合には、そのまま本処理を終了する。
なお、実行中止判定値及び送信中止判定値は、例えば各タスクで一律にゼロに設定し、余裕時間がなくなった時点で、タスクの実行やメッセージの送信を中止するように設定すればよい。また、以後のタスクの実行やメッセージの送信がＷＣＥＴより早く終了し、余裕時間がゼロ以上に復帰する可能性がある場合には、その範囲内で、実行中止判定値及び中止判定値を、ゼロ以下の値に設定してもよい。
【００６１】
ここで、図５は、Ｓ１３０及びＳ１９０にて実行する余裕時間の更新方法の詳細を示す一覧表であり、監視対象がタスクの場合（Ｓ１３０）、及び監視対象がメッセージの場合（Ｓ１９０）のいずれも、タスク及びメッセージの状態により余裕時間の更新は四つのケースに分類される。
【００６２】
なお、タスクスケジューリング部１８は、実行権を取得し実行中の状態にあるタスクについて、実行権取得後の経過時間（以下「処理実行時間」という）を計測するタイマーと、起動したが実行権が得られず実行待ちの状態にあるタスクのそれぞれについて、起動後の経過時間（以下「処理待機時間」という）を計測するタイマーとを備えているものとする。
【００６３】
また同様に、メッセージスケジューリング部１９も、送信権を取得し送信中の状態にあるメッセージについて、送信権取得後の経過時間（以下「送信実行時間」という）を計測するタイマーと、メッセージが生成されたが送信権が得られず送信待ちの状態にあるメッセージのそれぞれについて、メッセージ生成後の経過時間（以下「送信待機時間」という）を計測するタイマーとを備えているものとする。
【００６４】
まず、監視対象がタスクの場合（Ｓ１３０）の四つのケースについて説明する。
即ち、第１のケースは、タスクが実行待ちの状態にある場合であり、この場合は、時間の経過に従って処理待機時間の増分を余裕時間から減じる。
【００６５】
第２のケースは、タスクが実行中の状態にあり、かつ、タスクの処理実行時間が余裕時間の初期値を求める際に用いたＷＣＥＴに満たない場合であり、この場合は、余裕時間は更新せず、そのままの値を保持する。
第３のケースは、タスクが実行中の状態にあり、かつ、タスクの処理実行時間がＷＣＥＴを超過した場合であり、この場合は、その超過時間分を余裕時間から減ずる。
【００６６】
第４のケースは、実行中の状態にあったタスクがＷＣＥＴより早く処理を終了した場合であり、この場合は、ＷＣＥＴと実行処理時間との差分を余裕時間に加算する。
以下では、これら各ケースについて、図６，７に示すグラフを用いて説明する。
【００６７】
まず、タスクが起動された時には、余裕時間の初期値（以下では「起動時の余裕時間」という）Ｍ０が設定される。このとき、他に優先度の高い（余裕時間の少ない）タスクが存在し、更新対象のタスクが実行待ちの状態になると、第１のケースに相当し、図６に示すように、実行権を取得して処理を開始するまでの間は、その処理待機時間に比例して余裕時間が減少する。そして、タスクの処理待機時間が最終的にＴ０であった場合、実行権を取得して処理を開始した時の余裕時間（以下では「処理開始時の余裕時間」という）は、Ｍ１＝Ｍ０−Ｔ０となる。但し、タスクが起動されたあと直ちに実行権を取得して処理を開始した場合には、処理待機時間はＴ０＝０であるため、処理開始時の余裕時間はＭ１＝Ｍ０となる。
【００６８】
なお、処理開始後、ＷＣＥＴが経過するまでの間は第２のケースに相当し、余裕時間はＭ１のまま保持される。
その後、タスクの処理実行時間が、そのタスクのＷＣＥＴより超過すると、第３のケースに相当し、図７（ａ）に示すように、余裕時間は、ＷＣＥＴを超過した後は、その超過時間に比例して減少し、タスクの処理実行時間が最終的にＷＣＥＴよりＴ１だけ超過した場合、タスクが終了した時点での余裕時間（以下では「処理終了時の余裕時間」という）は、Ｍ２＝Ｍ１−Ｔ１となる。
【００６９】
一方、タスクが終了した時点で、その処理実行時間がＷＣＥＴに満たない場合は、第４のケースに相当し、図７（ｂ）に示すように、ＷＣＥＴよりＴ２だけ早くタスクが終了している時には、処理終了時の余裕時間はＭ２＝Ｍ１＋Ｔ２となる。
【００７０】
なお、ここでは、第３のケースにおいて、タスクの実行中に、ＷＣＥＴからの超過分を余裕時間から逐次減じるようにされているが、タスクの実行が終了した時点で、これを余裕時間から一括して減じるようにしてもよい。
次に、監視対象がメッセージの場合（Ｓ１９０）の四つのケースについて説明する。
【００７１】
即ち、第１のケースは、メッセージが送信待ち状態にある場合であり、この場合は、時間の経過に従って、送信待機時間の増分を余裕時間から減じる。
第２のケースは、メッセージが送信中の状態にあり、かつ、実際に送信が開始されている場合であり、この場合は、余裕時間を更新する必要がないため、余裕時間は更新は行わない。
【００７２】
第３のケースは、メッセージが送信中の状態にあるが、実際には送信が開始されておらず、かつ、次の送信機会で送信に成功したとすると、メッセージの送信処理時間がＷＣＥＴを超過する場合であり、この場合は、その超過時間分を余裕時間から減ずる。
【００７３】
第４のケースは、メッセージが送信中の状態にあるが、実際には送信が開始されておらず、かつ、次の送信機会で送信に成功したとすると、メッセージの送信処理時間がＷＣＥＴに満たない場合であり、この場合は、そのＷＣＥＴと実行処理時間との差分を余裕時間に加算する。
【００７４】
以下では、これら各ケースについて、図８，９に示すグラフを用いて説明する。
まず、メッセージの送信要求がされた時には、余裕時間（以下では「送信要求時の余裕時間」という）として、メッセージを生成したタスクの処理終了時の余裕時間Ｍ２が設定される。このとき、他に優先度の高い（余裕時間の少ない）メッセージが存在し、送信待ちの状態になると、第１のケースに相当し、図８に示すように、送信権を取得して送信を開始するまでの間は、その送信待機時間に比例して余裕時間が減少する。そして、メッセージの送信待機時間が最終的にＴ３であったとすると、送信権を取得して送信中の状態となった時の余裕時間（以下では「送信開始時の余裕時間」という）はＭ３＝Ｍ２−Ｔ３となる。但し、メッセージの送信要求がされたあと直ちに送信権を取得して送信中の状態となった場合は、送信待機時間はＴ３＝０であるため、送信開始時の余裕時間はＭ３＝Ｍ２となる。
【００７５】
このようにして、送信中の状態になり、しかも実際に送信が開始されると、第２のケースに相当し、余裕時間の更新は行われない。
一方、送信中の状態にあるが、第３のケースに相当する場合は、図９（ａ）に示すように、そのメッセージのＷＣＥＴからの超過時間分がＴ４だとすると、余裕時間は、メッセージが次の送信機会で送信が成功したと仮定した時の送信終了時点での余裕時間（以下では「処理終了時の余裕時間」という）Ｍ４（＝Ｍ３−Ｔ４）に更新される。
【００７６】
また、送信中の状態にあるが、第４のケースに相当する場合は、図９（ｂ）に示すように、そのメッセージのＷＣＥＴと送信処理時間との差分がＴ５だとすると、余裕時間は、処理終了時の余裕時間Ｍ４（＝Ｍ３＋Ｔ５）に更新される。
このように構成された本実施形態の分散制御システムでは、各ノードＮＤｉでは、余裕時間の少ないタスクが優先的に実行権を取得すると共に、余裕時間の少ないメッセージが優先的に送信権を取得する。そして、伝送路上では、余裕時間の少ないメッセージを載せたフレームほど優先的に伝送されることになる。
【００７７】
ここで、本実施形態の分散制御システムにおける各ノードのタスク制御及び通信制御の動作例を、図１０に示すタイミング図に沿って説明する。
まず、システム構成として、図３（ａ）に示すように、ノードＮＤ１がタスクａ，ｂ，ｃ、ノードＮＤ２がタスクｄ，ｅ，ｆ、ノードＮＤ３がタスクｇ，ｈ，ｉをそれぞれ実行し、しかも、これら各ノードＮＤ１〜ＮＤ３において、タスクａ（ノードＮＤ１）→タスクｄ（ノードＮＤ２）→タスクｇ（ノードＮＤ３）の順に実行される分散制御１と、タスクｅ（ノードＮＤ２）→タスクｈ（ノードＮＤ２）→タスクｃ（ノードＮＤ１）の順に実行される分散制御２とを並列に実行する場合を仮定する。但し、ここでは理解を容易にするため、全てのタスク及び全てのメッセージが、いずれも余裕時間の初期値の算出に用いたＷＣＥＴ通りの時間で処理されるものとする。
【００７８】
図１０に示すように、まず、時刻Ｔ１にて、分散制御１の開始が要求されると、ノードＮＤ１上でタスクａの処理が開始される。
このタスクａの処理が、時刻Ｔ２にて終了すると、タスクａにより生成されたメッセージ１の送信が開始される。この間（Ｔ１〜Ｔ２）、タスクａは、実行待ち状態となることなく処理が実行されたため、分散制御１の余裕時間に増減はない。
【００７９】
メッセージ１はノードＮＤ２にて受信され、時刻Ｔ３にて、そのメッセージ１の通信が終了すると、ノードＮＤ２は、メッセージ１が属する分散制御１に対応したタスクｄの処理を起動する。この間（Ｔ２〜Ｔ３）、メッセージ１は送信待ち状態となることなく送信が実行されたため、分散制御１の余裕時間に増減はない。
【００８０】
その後、時刻Ｔ４にて、ノードＮＤ２上で分散制御２の開始が要求されると、タスクｅの処理が起動される。このとき、分散制御１の余裕時間と分散制御２の余裕時間とを比較すると、分散制御２の余裕時間の方が少ないため、実行中のタスクｄ（分散制御１）は中断され実行待ち状態となり、代わりにタスクｅ（分散制御２）の実行を開始する。
【００８１】
このタスクｅの処理が、時刻Ｔ５にて終了すると、タスクｅにより生成されたメッセージ２の送信が開始されると共に、中断していたタスクｄの処理が再開される。この間（Ｔ４〜Ｔ５）、タスクｅは、実行待ち状態になることなく処理が実行されたため、分散制御２の余裕時間に増減はなく、一方、実行待ち状態であったタスクｄは処理を中断していたため、分散制御１の余裕時間は、その中断時間分（Ｔ５−Ｔ４）だけ減少する。
【００８２】
再開されたタスクｄの処理が、時刻Ｔ６にて終了すると、タスクｄにより生成されたメッセージ３の送信が要求される。このとき、より余裕時間の少ない分散制御２に属するメッセージ２の送信中であるため、メッセージ３は送信待ち状態となる。
【００８３】
その後、時刻Ｔ７にて、メッセージ２の通信が終了すると、これを受信したノードＮＤ３は、メッセージ２が属する分散制御２に対応したタスクｈの処理を開始し、一方、ノードＮＤ２では、送信待ち状態にあったメッセージ３の送信を開始する。この間（Ｔ５〜Ｔ７）、メッセージ２は送信待ち状態となることなく送信が実行されたため、分散制御２の余裕時間に増減はない。一方、メッセージ３は、タスクｄの処理終了（Ｔ６）からメッセージ２の通信終了（Ｔ７）までの間、送信待ち状態となったため、分散制御１の余裕時間は、その待ち時間分（Ｔ７−Ｔ６）だけ減少する。
【００８４】
そして、時刻Ｔ８にて、メッセージ３の通信が終了すると、これを受信したノードＮＤ３は、メッセージ３が属する分散制御１に対応したタスクｇの処理を起動する。この時、より余裕時間が少ない分散制御２に属するタスクｈの処理が既に実行中であるため、タスクｇは実行待ち状態となる。
【００８５】
その後、時刻Ｔ９にて、タスクｈの処理が終了すると、タスクｈにより生成されたメッセージ４の送信が開始されると共に、実行待ち状態にあったタスクｇの処理が開始される。この間（Ｔ７〜Ｔ９）、タスクｈは実行待ち状態になることなく処理が実行されたため、分散制御２の余裕時間に増減はなく、一方、タスクｇは、メッセージ３の通信終了（Ｔ８）からタスクｈの処理終了（Ｔ９）までの間、実行待ち状態となったため、分散制御１の余裕時間は、その待ち時間分（Ｔ９−Ｔ８）だけ減少する。
【００８６】
時刻Ｔ１０にて、メッセージ４の通信が終了すると、これを受信したノードＮＤ１は、メッセージ４が属する分散制御２に対応したタスクｃの処理を開始し、このタスクｃの処理が時刻Ｔ１２にて終了することにより、分散制御２についての一連の処理が終了する。この間（Ｔ９〜Ｔ１２）、メッセージ４及びタスクｃは、いずれも通信待ち状態や実行待ち状態になることなく処理されるため、分散制御２の余裕時間に増減はなく、結局、分散制御２は、デッドラインの条件を満たした時間内で処理される。
【００８７】
また、タスクｇの処理が時刻Ｔ１１にて終了することにより、分散制御１についての一連の処理が終了する。この間（Ｔ９〜Ｔ１）、実行待ち状態になることなく処理されるため、分散制御１の余裕時間に増減はなく、結局、分散制御１は、（Ｔ５−Ｔ４）＋（Ｔ７−Ｔ６）＋（Ｔ９−Ｔ８）だけ、余裕時間が減少するが、デッドラインの条件を満たした時間内で処理される。
【００８８】
以上説明したように、本実施形態の分散制御システムでは、システム上で実行される分散制御のそれぞれについて、その分散制御の実行に必要なタスクの処理時間、及びメッセージの送信時間のＷＣＥＴを全て加算してなる予測終了時間Ｔspと、その分散制御についてのデッドラインまでの時間Ｔcyとの差分を表す余裕時間を設定し、その余裕時間の少ないタスクやメッセージから優先的に処理や送信を実行するようにされている。
【００８９】
つまり、低優先度に設定されたタスクが常に後回しにされてしまう従来装置とは異なり、全ての分散制御がデッドラインの条件を満たすように、タスクやメッセージの優先度が常に変化する。
従って、各タスクの処理時刻やメッセージの送信時刻を予め決定しておかなくても、デッドラインの条件を満たすような順番で効率よくタスクの処理やメッセージの送信を実行させることができる。
【００９０】
その結果、システムを実際に動作させた結果、デッドラインの条件を満たすことができない場合には、タスクやメッセージの優先度を考慮した設計変更を行う必要がなく、そのデッドラインからの遅れ分だけＣＰＵの処理速度やメッセージの伝送速度を高速化しさえすればよいため、分散制御システムの開発工数を大幅に削減できる。
【００９１】
また、本実施形態では、余裕時間が予め設定された実行中止判定値や送信中止判定値以下である時は、これに対応するタスクの実行やメッセージの送信を中止することで、その分散制御を中止するようにされている。
従って、デッドラインの条件を満たすことができないことが明らかな分散制御が継続して実行されることにより、他の分散制御の余裕時間が削られ、これら他の分散制御にも悪影響を与えてしまうことを確実に防止できる。
【００９２】
また、本実施形態では、余裕時間に対応した時間情報を、メッセージと共にフレームに挿入し、しかも、その時間情報を調停の際に優先度を決める情報として用いており、伝送路上でも、余裕時間の少ない分散制御についてのメッセージが優先的に送信されるため、余裕時間の少ない分散制御が、途中でデッドラインの条件を満たすことができずに、中止されてしまう可能性を大幅に削減することができる。
［第２実施形態］
次に第２実施形態について説明する。
【００９３】
本実施形態では、実行するタスクの構成、及び余裕時間更新部１６が実行する処理の一部が第１実施形態とは異なるだけであるため、この相異する部分を中心に説明する。
即ち、本実施形態においては、タスク制御部１４が管理するタスクとして、通常時に実行する通常タスクの他、通常タスクのそれぞれに対して、その通常タスクの処理を一部省略したり、その処理をより簡易なものに置き換えることにより、通常タスクより実行時間が短くなるように構成された簡易タスクが用意されている。
【００９４】
そして、余裕時間更新部１６では、第１実施形態にて説明した図４のＳ１４０にて、余裕時間が実行中止判定値より大きいと判定された場合に、その余裕時間が、予め設定されたタスク切替判定値以下であり、且つそのタスクが実行待ち状態である場合に、そのタスクが通常タスクであれば、これを簡易タスクに切り替えるように構成されている。
【００９５】
これと同様に、図４のＳ２００にて、余裕時間が送信中止判定値より大きいと判定された場合に、その余裕時間が、予め設定されたメッセージ切替判定値以下であり、且つそのメッセージが実際に送信が行われていない場合に、そのメッセージが通常メッセージであれば、これを簡易メッセージに切り替えるように構成されている。
【００９６】
なお、簡易メッセージとは、メッセージに含ませるべき情報の一部を省略したものであり、この簡易メッセージを受けたタスクは、省略された情報については、デフォルト値、前回の処理で使用した値、或いはその値からの推定値などを用いて処理を実行するように構成されている。
【００９７】
ここで、本実施形態の分散制御システムにおける各ノードのタスク制御及び通信制御の動作例を、図１２に示すタイミング図に沿って説明する。
但し、そのシステム構成は、図１１に示すように、図３（ａ）に示したものとほぼ同様であるが、ノードＮＤ２が実行するタスクｅについては、これと対になる簡易タスクｅ’が用意されていると共に、簡易メッセージも用意されている。そして、各ノードＮＤ１〜ＮＤ３において、タスクａ（ノードＮＤ１）→タスクｄ（ノードＮＤ２）の順に実行される分散制御１と、タスクｅ（ノードＮＤ２）→タスクｉ（ノードＮＤ３）の順に実行される分散制御２とを並列に実行する場合を仮定する。
【００９８】
また、ここでは理解を容易にするため、全てのタスク及びメッセージが、いずれも余裕時間の初期値の算出に用いたＷＣＥＴ通りの時間で処理されるものとする。また、タスク切替判定値及びメッセージ切替判定値はゼロに設定され、実行中止判定値及び送信中止判定値は、それ以後の処理が、全て簡易タスク及び簡易メッセージにて実行されたとして、余裕時間ゼロに復帰できる下限値に設定されているものとする。更に、タスクｉには、簡易タスクが用意されていないため、その実行中止判定値はゼロに設定されているものとする。
【００９９】
図１２に示すように、時刻Ｔ１から時刻Ｔ３までは、第１実施形態において図１０を用いて説明した場合と全く同様であるため、その説明を省略する。
そして、時刻Ｔ３にて、タスクｄの処理が開始された後、時刻Ｔ４にて、ノードＮＤ２に対する外部からの割込が発生すると、タスクｄの処理は中断され実行待ち状態となり、割込処理が開始される。
【０１００】
更に、この割込処理の実行中の時刻Ｔ５に、分散制御２の開始が要求されると、タスクｅが起動される。しかし、割り込み処理が実行されているため、タスクｅも実行待ち状態となる。
その後、時刻Ｔ６にて割込処理が終了すると、実行待ち状態にあるタスクのうち、より余裕時間の少ない分散制御２に属するタスクが選択され、そのタスクの処理が開始される。この間（Ｔ４〜Ｔ６）、分散制御２のタスクは、その起動（Ｔ５）から割込処理の終了（Ｔ６）まで、実行待ち状態となり処理を中断していたため、分散制御２の余裕時間は、その中断時間分（Ｔ６−Ｔ５）だけ減少する。これにより、分散制御２の余裕時間は、タスク切替判定値より小さくなっているため、分散制御２では、通常タスクｅに代えて、簡易タスクｅ’が実行される。
【０１０１】
この簡易タスクｅ’の処理が、時刻Ｔ７にて終了すると、タスクｅ’はタスクｅのＷＣＥＴより短い時間で処理が終了するため、分散制御２の余裕時間は、その差分だけ増加する。しかし、その余裕時間は、メッセージ切替判定値以下であるため、通常のメッセージ２に代えて簡易メッセージ２’の送信が開始される。
【０１０２】
これと共に、中断していたタスクｄの処理が再開される。この間（Ｔ４〜Ｔ７）、タスクｄは、実行待ち状態となり処理を中断していたため、分散制御１の余裕時間は、その中断時間分（Ｔ７−Ｔ４）だけ減少する。
その後、再開されたタスクｄの処理が、時刻Ｔ８にて終了することにより、分散制御１についての一連の処理が終了する。この間（Ｔ７〜Ｔ８）、タスクｄは、実行待ち状態になることなく処理されるため、分散制御１の余裕時間に増減はなく、結局、分散制御１は、（Ｔ７−Ｔ４）だけ、余裕時間が減少するが、デッドラインの条件を満たした時間内で処理される。
【０１０３】
また、メッセージ２’がノードＮＤ３で受信され、時刻Ｔ９にて、その通信が終了すると、メッセージ２’は通常のメッセージ２のＷＣＥＴより短い時間で通信が終了するため、分散制御の余裕時間は、その差分だけ増加する。これにより、その余裕時間が、実行中止判定値より大きいため、タスクｉの処理が開始される。
【０１０４】
このタスクｉの処理が時刻Ｔ１０にて終了することにより、分散制御２についての一連の処理が終了する。この間（Ｔ９〜Ｔ１０）、タスクｉは実行待ち状態になることなく処理されるため、分散制御２の余裕時間に増減はない。つまり、分散制御２は、一旦、余裕時間ゼロを下回ったにも関わらず、簡易タスク，簡易メッセージを使用することにより、最終的には、デッドラインの条件を満たした時間内で処理される。
【０１０５】
以上説明したように、本実施形態の分散制御システムによれば、システム上で実行される分散制御のそれぞれについて、余裕時間を設定し、その余裕時間の少ないタスクやメッセージから優先的に処理や送信を実行し、余裕時間が実効中止判定値や送信中止判定値以下である時は、これに対応するタスクの実行やメッセージの送信を中止するようにされているため、第１実施形態と同様の効果を得ることができる。
【０１０６】
しかも本実施形態では、余裕時間が、タスク切替判定値やメッセージ切替判定値以下である時は、これに対応するタスクやメッセージを、実行時間や通信時間の短い簡易タスクや簡易メッセージに切り替えるようにされている。
従って、余裕時間から、デッドラインの条件を満たすことが困難であることが予測される場合でも、その時点で、簡易タスクや簡易メッセージに切り替えることにより、通常のタスクやメッセージで処理を行った場合との時間差分だけ、余裕時間を余分に確保することが可能となり、分散制御が、実行の途中で中止される可能性を大幅に低減することができる。
【０１０７】
換言すれば、常に各分散制御のデッドラインに対する余裕時間を知ることができるため、デッドライン違反を予測し、デッドライン違反に基づくＱｏＳ（Quality of Service）制御が可能となり、故障、ソフトウェアのバグ等に対するシステムのフォールトトレランス性を向上させることができる。また、従来のデッドラインを考慮しないリアルタイムＯＳ，ＣＳＭＡ／ＣＡを利用した分散制御システムと比較して、システム負荷がより高い場合でも、デッドラインの保証が可能となる。
【０１０８】
ここで、図１３は、リアルタイムＯＳとＣＳＭＡ／ＣＡとを用いた従来の分散制御システムと、第１実施形態に示した分散制御システムとで、シミュレーションにより処理能力を比較した結果を表すグラフである。
なお、シミュレーションにおいては、図１４（ａ）に示すように、６つのノードから構成されるシステムを仮定し、１２の分散制御を、図１４（ｂ）に示す条件（タスク数，メッセージ数，制御周期）で並列に実行させた。
【０１０９】
図１３では、横軸が各ノードのＣＰＵの動作周波数（すべてのノードのＣＰＵが同一周波数で動作することとする）、縦軸がメッセージを送信する際の通信レートである。そして、デッドラインを保証できる範囲を、本発明を適用した分散制御システムについては平行斜線のハッチングで示し、従来の分散制御システムについてはクロス斜線のハッチングで示した。
【０１１０】
このシミュレーションにより、本発明を適用した分散制御システムでは、従来システムと比較して、より低いＣＰＵ動作周波数、および通信レートでデッドラインを保証することが可能であることが確認された。
【図面の簡単な説明】
【図１】 第１実施形態の分散制御システムを構成するノードの内部構成を示すブロック図である。
【図２】 ネットワーク上で伝送されるフレームの構成を示す説明図である。
【図３】 余裕時間の算出方法を示す説明図である。
【図４】 余裕時間更新部が実行する処理の概要を示すフローチャートである。
【図５】 余裕時間の更新方法の詳細を示す一覧表である。
【図６】 タスクが実行待ち状態の時における余裕時間の更新方法を示す説明図である。
【図７】 タスクの実行時間がＷＣＥＴより長い時及び短い時における余裕時間の更新方法を示す説明図である。
【図８】 メッセージが送信待ち状態の時における余裕時間の更新方法を示す説明図である。
【図９】 メッセージの通信時間がＷＣＥＴより長い時及び短い時における余裕時間の更新方法を示す説明図である。
【図１０】 第１実施形態の分散制御システムの動作例を示すタイミング図である。
【図１１】 第２実施形態の分散制御システムの動作例を示すタイミング図である。
【図１２】 図１１に示す動作の前提となるシステム構成を示す説明図である。
【図１３】 従来システムとの効果の差を比較するために行ったシミュレーションの結果を示すグラフである。
【図１４】 シミュレーションの条件を示す図表である。
【図１５】 メッセージスケジューリング、及びタスクスケジューリングの具体例を示す説明図である。
【符号の説明】
１２…タスク群 １３…メッセージ群 １４…タスク制御部
１５…通信制御部 １６…余裕時間更新部 １７…余裕時間初期設定部
１８…タスクスケジューリング部 １９…メッセージスケジューリング部
２０…メッセージ送受信部 ＮＤｉ…ノード ＮＴ…ネットワーク
Claims (4)
- ＣＳＭＡ／ＣＡ方式を適用したフレームによりメッセージを伝送する共通の多重伝送路に接続されたマルチタスキング動作が可能な複数のノードにて分散して実行される複数のタスクが、互いにメッセージを通信し合うことで協調して時系列に動作することにより分散制御を行う分散制御方法において、
各ノードでは、実行可能なタスクのそれぞれについて、該タスクがその一部を分担する前記分散制御についての予測終了時間と該分散制御についてのデッドラインとの差分を表す余裕時間を設定し、その余裕時間の小さいタスクから優先的に実行権を割り当てると共に、送信可能なメッセージのそれぞれについて、該メッセージが属する前記分散制御についての前記余裕時間に基づき、該余裕時間の小さいものから優先的にメッセージの送信権を割り当て、
前記メッセージを送信する際には、該メッセージについての前記余裕時間を表す時間情報を、前記フレームのうち前記伝送路上での調停制御のために用いられる領域に挿入して前記メッセージと共に送信し、
前記タスクの起動時には該タスクについての前記余裕時間として、前記分散制御の最初に起動される先頭タスクの場合は、予め用意された前記余裕時間の初期値を設定し、前記メッセージの受信により起動される非先頭タスクの場合は、該メッセージに挿入された前記時間情報に基づく値を設定することを特徴とする分散制御方法。 - ノード内で他のノードへの通信権の取得待ちの状態にあるメッセージについての前記余裕時間を、前記通信権を取得するまでの間、時間の経過と共に減少させることを特徴とする請求項１記載の分散制御方法。
- ノード内で他のノードへの通信権を獲得したメッセージについて、次の送信機会で前記共通伝送路での調停に勝ち、前記他のノードがメッセージを受信できたと仮定した時の通信終了までに要する予測通信時間が、該メッセージについて予め設定された最悪通信時間に満たない時は、該メッセージについての前記余裕時間を、前記最悪通信時間と前記予測通信時間との差分だけ増加させ、前記予測通信時間が前記最悪通信時間を越えている時は、該メッセージについての前記余裕時間を、前記差分だけ減少させることを特徴とする請求項１または請求項２記載の分散制御方法。
- ＣＳＭＡ／ＣＡ方式を適用したフレームによりメッセージを伝送するマルチタスキング動作をする各タスクが、共通の多重伝送路に接続された他の装置上で動作する他のタスクと、互いにメッセージを通信し合うことにより協調動作して分散制御を実行する分散制御装置であって、
前記タスクがその一部を分担する前記分散制御についての予測終了時間と該分散制御についてのデッドラインとの差分を表す余裕時間に基づいて、実行可能なタスクのうち、その余裕時間の小さいタスクから優先的に実行権を割り当てるタスクスケジューリング手段と、
前記タスクが生成するメッセージについての前記余裕時間を表す時間情報を、前記フレームのうち前記伝送路上での調停制御のために用いられる領域に挿入して前記メッセージと共に前記多重伝送路を介して送信し、他の装置からのメッセージを受信した時には、該メッセージに対応するタスクの起動を前記タスクスケジューリング手段に要求するメッセージ送受信手段と、
前記メッセージについての前記余裕時間に基づいて、その余裕時間の小さいものから優先的に、前記メッセージ送受信手段でのメッセージの送信権を割り当てるメッセージスケジューリング手段と、
前記タスクスケジューリング手段によるタスクの起動時には該タスクについての前記余裕時間として、前記一連の分散制御にて最初に実行される先頭タスクの場合は、予め用意された前記余裕時間の初期値を設定し、他の装置からのメッセージの受信により起動される非先頭タスクの場合は、該メッセージに挿入された前記時間情報に基づく値を設定する起動時設定手段と、
該起動時設定手段が設定した前記余裕時間を、前記タスクスケジューリング手段による各タスクの実行状態に応じて逐次更新する第１更新手段と、
前記起動時設定手段が設定した前記余裕時間を、前記メッセージ送受信手段による各メッセージの送信の実行状態に応じて逐次更新する第２更新手段と、
を備えることを特徴とする分散制御装置。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002095748A JP3922070B2 (ja) | 2002-03-29 | 2002-03-29 | 分散制御方法及び装置 |
| US10/396,474 US7322033B2 (en) | 2002-03-29 | 2003-03-26 | Distributed control method and apparatus |
| DE10314148A DE10314148A1 (de) | 2002-03-29 | 2003-03-28 | Verfahren und Vorrichtung zum Verteilten Steuern |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002095748A JP3922070B2 (ja) | 2002-03-29 | 2002-03-29 | 分散制御方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003298599A JP2003298599A (ja) | 2003-10-17 |
| JP3922070B2 true JP3922070B2 (ja) | 2007-05-30 |
Family
ID=28449728
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002095748A Expired - Fee Related JP3922070B2 (ja) | 2002-03-29 | 2002-03-29 | 分散制御方法及び装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7322033B2 (ja) |
| JP (1) | JP3922070B2 (ja) |
| DE (1) | DE10314148A1 (ja) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2854263A1 (fr) * | 2003-04-24 | 2004-10-29 | St Microelectronics Sa | Procede d'execution de taches concurrentes par un sous-systeme gere par un processeur central |
| WO2005089239A2 (en) | 2004-03-13 | 2005-09-29 | Cluster Resources, Inc. | System and method of providing a self-optimizing reservation in space of compute resources |
| US8782654B2 (en) | 2004-03-13 | 2014-07-15 | Adaptive Computing Enterprises, Inc. | Co-allocating a reservation spanning different compute resources types |
| US9778959B2 (en) | 2004-03-13 | 2017-10-03 | Iii Holdings 12, Llc | System and method of performing a pre-reservation analysis to yield an improved fit of workload with the compute environment |
| GB2412980A (en) * | 2004-04-07 | 2005-10-12 | Hewlett Packard Development Co | A method of distributing load amongst two or more computer system resources |
| US20070266388A1 (en) | 2004-06-18 | 2007-11-15 | Cluster Resources, Inc. | System and method for providing advanced reservations in a compute environment |
| US8176490B1 (en) | 2004-08-20 | 2012-05-08 | Adaptive Computing Enterprises, Inc. | System and method of interfacing a workload manager and scheduler with an identity manager |
| WO2006053093A2 (en) | 2004-11-08 | 2006-05-18 | Cluster Resources, Inc. | System and method of providing system jobs within a compute environment |
| US20060235856A1 (en) * | 2004-12-16 | 2006-10-19 | Halcrow Michael A | Route generation for task completion by a location-aware device |
| US8863143B2 (en) | 2006-03-16 | 2014-10-14 | Adaptive Computing Enterprises, Inc. | System and method for managing a hybrid compute environment |
| US9231886B2 (en) | 2005-03-16 | 2016-01-05 | Adaptive Computing Enterprises, Inc. | Simple integration of an on-demand compute environment |
| ES2614751T3 (es) | 2005-04-07 | 2017-06-01 | Iii Holdings 12, Llc | Acceso bajo demanda a recursos informáticos |
| US7788667B2 (en) * | 2005-04-22 | 2010-08-31 | Gm Global Technology Operations, Inc. | Extensible scheduling of tasks in time-triggered distributed embedded systems |
| US8473563B2 (en) * | 2005-04-22 | 2013-06-25 | GM Global Technology Operations LLC | Extensible scheduling of messages on time-triggered busses |
| JP4580845B2 (ja) | 2005-08-24 | 2010-11-17 | パナソニック株式会社 | タスク実行装置 |
| JP2007108944A (ja) | 2005-10-12 | 2007-04-26 | Renesas Technology Corp | 半導体集積回路装置 |
| US20070098004A1 (en) * | 2005-10-31 | 2007-05-03 | Lada Henry F | Systems and methods for arbitrating multiple communications |
| JP4821270B2 (ja) * | 2005-11-02 | 2011-11-24 | Ｋｄｄｉ株式会社 | 許容遅延時間を考慮した無線アクセス制御方法、アクセスポイント、端末及びプログラム |
| JP4906317B2 (ja) * | 2005-11-10 | 2012-03-28 | キヤノン株式会社 | 情報処理装置及び方法 |
| JP4781089B2 (ja) * | 2005-11-15 | 2011-09-28 | 株式会社ソニー・コンピュータエンタテインメント | タスク割り当て方法およびタスク割り当て装置 |
| JP4815195B2 (ja) * | 2005-11-16 | 2011-11-16 | みずほ情報総研株式会社 | ジョブ実行管理方法、ジョブ実行管理システム及びジョブ実行管理プログラム |
| JP5076342B2 (ja) * | 2006-03-28 | 2012-11-21 | トヨタ自動車株式会社 | 分散制御装置 |
| JP2007295081A (ja) * | 2006-04-21 | 2007-11-08 | Auto Network Gijutsu Kenkyusho:Kk | 電子制御ユニットおよびフレーム優先度設定方法 |
| US8726282B1 (en) * | 2006-05-01 | 2014-05-13 | Open Invention Network, Llc | Job scheduler for remote maintenance of servers and workstations |
| JP4797867B2 (ja) * | 2006-07-31 | 2011-10-19 | 株式会社デンソー | 車両用制御システムのメッセージ管理装置及び車両用制御システム |
| BRPI0814233A2 (pt) * | 2007-07-13 | 2015-01-06 | Nortel Networks Ltd | Controle de qualidade de serviços em ambientes de comunicação sem-fio de múltiplos saltos |
| US8041773B2 (en) | 2007-09-24 | 2011-10-18 | The Research Foundation Of State University Of New York | Automatic clustering for self-organizing grids |
| JP5231035B2 (ja) * | 2008-01-31 | 2013-07-10 | 株式会社野村総合研究所 | ジョブ処理システムおよびジョブ処理方法 |
| JP5141422B2 (ja) * | 2008-03-14 | 2013-02-13 | 富士通株式会社 | 移動体通信無線基地局装置および移動体通信無線基地局装置におけるデータ多重処理方法 |
| JP2009266152A (ja) * | 2008-04-30 | 2009-11-12 | Toshiba Corp | コントローラ、ハードディスクドライブおよびコントロール方法 |
| EP2120143B1 (de) * | 2008-05-13 | 2011-08-31 | dspace digital signal processing and control engineering GmbH | Verfahren zur Ausführung von Tasks zur Berechnung eines zu simulierenden Signals in Echtzeit |
| US7516220B1 (en) * | 2008-05-15 | 2009-04-07 | International Business Machines Corporation | Method and system for detecting and deterring robot access of web-based interfaces by using minimum expected human response time |
| EP2128726B1 (de) * | 2008-05-29 | 2011-07-27 | dspace digital signal processing and control engineering GmbH | Verfahren und Simulator zur Echtzeitberechnung der Zustandsgrössen eines Prozessmodells |
| JP4941507B2 (ja) * | 2009-05-27 | 2012-05-30 | 沖電気工業株式会社 | 負荷分散制御装置、プログラム及び方法、並びに、負荷分散装置及び情報処理装置 |
| US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| JP5069325B2 (ja) * | 2010-03-11 | 2012-11-07 | 株式会社豊田中央研究所 | タスク実行制御装置及びプログラム |
| US8577976B2 (en) * | 2010-04-27 | 2013-11-05 | International Business Machines Corporation | Application of system level policy in message oriented middleware |
| JP2011234212A (ja) * | 2010-04-28 | 2011-11-17 | Toyota Motor Corp | タスク制御装置 |
| US8966486B2 (en) * | 2011-05-03 | 2015-02-24 | Microsoft Corporation | Distributed multi-phase batch job processing |
| US9201690B2 (en) | 2011-10-21 | 2015-12-01 | International Business Machines Corporation | Resource aware scheduling in a distributed computing environment |
| US8924977B2 (en) * | 2012-06-18 | 2014-12-30 | International Business Machines Corporation | Sequential cooperation between map and reduce phases to improve data locality |
| US9373074B2 (en) * | 2012-10-09 | 2016-06-21 | Qualcomm Incorporated | Method and apparatus for time management and scheduling for sychronous processing on a cluster of processing nodes |
| CN104781788A (zh) * | 2012-11-16 | 2015-07-15 | 日本电气株式会社 | 资源管理***、资源管理方法和程序 |
| JP2014102691A (ja) * | 2012-11-20 | 2014-06-05 | Toshiba Corp | 情報処理装置、通信機能を持つカメラ、および情報処理方法 |
| US9354938B2 (en) | 2013-04-10 | 2016-05-31 | International Business Machines Corporation | Sequential cooperation between map and reduce phases to improve data locality |
| FR3004825B1 (fr) | 2013-04-19 | 2015-04-24 | Krono Safe | Procede d'allocation temporelle de taches permettant une recuperation d'erreur deterministe en temps reel |
| JP2014225137A (ja) * | 2013-05-16 | 2014-12-04 | 株式会社デンソー | タスクスケジューラ，マイクロプロセッサ及びタスクスケジューリング方法 |
| US9342355B2 (en) | 2013-06-20 | 2016-05-17 | International Business Machines Corporation | Joint optimization of multiple phases in large data processing |
| CN104252381A (zh) * | 2013-06-30 | 2014-12-31 | 北京百度网讯科技有限公司 | 一种用于调度etl任务的方法与设备 |
| CN104102740A (zh) * | 2014-07-30 | 2014-10-15 | 精硕世纪科技（北京）有限公司 | 分布式信息获取***及方法 |
| KR102079499B1 (ko) * | 2015-10-20 | 2020-02-21 | 엘에스산전 주식회사 | Plc 위치 결정 시스템의 축별 제어주기 독립 할당 방법 |
| JP6544192B2 (ja) * | 2015-10-21 | 2019-07-17 | 株式会社デンソー | 連携システム |
| GB2545508B (en) * | 2015-12-18 | 2019-04-10 | Imagination Tech Ltd | Controlling operation of a GPU |
| US10506016B2 (en) | 2016-05-19 | 2019-12-10 | Oracle International Corporation | Graph analytic engine that implements efficient transparent remote access over representational state transfer |
| US10275287B2 (en) | 2016-06-07 | 2019-04-30 | Oracle International Corporation | Concurrent distributed graph processing system with self-balance |
| US10318355B2 (en) * | 2017-01-24 | 2019-06-11 | Oracle International Corporation | Distributed graph processing system featuring interactive remote control mechanism including task cancellation |
| US10534657B2 (en) | 2017-05-30 | 2020-01-14 | Oracle International Corporation | Distributed graph processing system that adopts a faster data loading technique that requires low degree of communication |
| US10747546B2 (en) * | 2017-06-19 | 2020-08-18 | Mitsubishi Electric Corporation | Distributed allocation device, distributed allocation system, and distributed allocation method |
| JP7114515B2 (ja) * | 2019-03-14 | 2022-08-08 | 国立大学法人東海国立大学機構 | 通信装置、通信システム及びメッセージ調停方法 |
| JP7331768B2 (ja) * | 2020-04-28 | 2023-08-23 | 株式会社デンソー | リアルタイム演算処理装置 |
| US11461130B2 (en) | 2020-05-26 | 2022-10-04 | Oracle International Corporation | Methodology for fast and seamless task cancelation and error handling in distributed processing of large graph data |
| CN112395067A (zh) * | 2020-12-04 | 2021-02-23 | 深圳前海微众银行股份有限公司 | 任务调度方法、***、设备及介质 |
| US11579959B2 (en) * | 2021-05-26 | 2023-02-14 | Honeywell International Inc. | Systems and methods for margin based diagnostic tools for priority preemptive schedulers |
| JP2023036264A (ja) | 2021-09-02 | 2023-03-14 | 日立Astemo株式会社 | 電子システム及び電子制御装置 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6368934A (ja) | 1986-09-10 | 1988-03-28 | Nec Corp | タスクスケジユ−ル方式 |
| JPH01143537A (ja) | 1987-11-30 | 1989-06-06 | Furukawa Electric Co Ltd:The | 多重伝送方式 |
| JPH0675786A (ja) | 1992-08-26 | 1994-03-18 | Hitachi Ltd | タスクスケジュリング方法 |
| JP3660376B2 (ja) | 1994-08-08 | 2005-06-15 | 株式会社日立製作所 | 分散処理システムおよび分散処理システムにおける負荷分散方法 |
| JPH08272627A (ja) | 1995-03-30 | 1996-10-18 | Ricoh Co Ltd | リアルタイムタスク制御装置 |
| JPH09319596A (ja) | 1996-05-31 | 1997-12-12 | Canon Inc | タスクスケジューリング装置およびタスクスケジューリング方法 |
| DE69703938T3 (de) * | 1996-11-22 | 2007-05-16 | (at)Road Ltd., Ipswich | Ressourcenzuordnung |
| US6112023A (en) * | 1997-02-24 | 2000-08-29 | Lucent Technologies Inc. | Scheduling-based hardware-software co-synthesis of heterogeneous distributed embedded systems |
| JPH10240548A (ja) | 1997-03-03 | 1998-09-11 | Toshiba Corp | タスクスケジューリング装置及び方法 |
| US6385638B1 (en) | 1997-09-04 | 2002-05-07 | Equator Technologies, Inc. | Processor resource distributor and method |
| JP2001236236A (ja) | 2000-02-25 | 2001-08-31 | Nec Microsystems Ltd | タスク制御装置およびそのタスクスケジューリング方法 |
-
2002
- 2002-03-29 JP JP2002095748A patent/JP3922070B2/ja not_active Expired - Fee Related
-
2003
- 2003-03-26 US US10/396,474 patent/US7322033B2/en not_active Expired - Fee Related
- 2003-03-28 DE DE10314148A patent/DE10314148A1/de not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| US20030187907A1 (en) | 2003-10-02 |
| JP2003298599A (ja) | 2003-10-17 |
| US7322033B2 (en) | 2008-01-22 |
| DE10314148A1 (de) | 2003-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3922070B2 (ja) | 分散制御方法及び装置 | |
| US8793695B2 (en) | Information processing device and information processing method | |
| US6633942B1 (en) | Distributed real-time operating system providing integrated interrupt management | |
| EP1538497B1 (en) | Distributed real time operating system | |
| JP4992408B2 (ja) | ジョブ割当プログラム、方法及び装置 | |
| JPWO2005106623A1 (ja) | Ｃｐｕクロック制御装置、ｃｐｕクロック制御方法、ｃｐｕクロック制御プログラム、記録媒体、及び伝送媒体 | |
| JP2005056067A (ja) | Ｄｍａ転送制御装置 | |
| WO2020238989A1 (zh) | 一种调度任务处理实体的方法及装置 | |
| JP2013218744A (ja) | リソースに基づいたスケジューラ | |
| Grenier et al. | Fine-tuning MAC-level protocols for optimized real-time QoS | |
| CN109766168B (zh) | 任务调度方法和装置、存储介质以及计算设备 | |
| CN114201416A (zh) | 一种控制核mcu和计算核mpu的通信调度方法 | |
| JP2003131892A (ja) | タスク実行制御装置及びタスク実行制御方法 | |
| US8423681B2 (en) | Control apparatus for process input-output device | |
| US20140366162A1 (en) | Starvationless Kernel-Aware Distributed Scheduling of Software Licenses | |
| JP2000148513A (ja) | タスク制御方法およびタスク制御装置 | |
| JP2008225641A (ja) | コンピュータシステム、割り込み制御方法及びプログラム | |
| JP2005149312A (ja) | タスク管理システム | |
| JP2001236236A (ja) | タスク制御装置およびそのタスクスケジューリング方法 | |
| JP4367167B2 (ja) | リアルタイムシステム、ＱｏＳ適応制御装置及びそれらに用いるＱｏＳ適応制御方法並びにそのプログラム | |
| JP2006215621A (ja) | Ｄｍａ制御装置 | |
| Kakkar | Scheduling techniques for operating systems for medical and IoT devices: A review | |
| JP2000259430A (ja) | コンピュータシステムの処理方法 | |
| JP2016151949A (ja) | Ｄｍａコントローラ | |
| JP2001022601A (ja) | ジョブ実行制御方法及び並列計算機システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040519 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060525 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060606 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060720 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070130 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070212 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110302 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120302 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120302 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130302 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140302 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |