(57)【要約】  ハードリアルタイム条件の下で分散ソフトウェアを実行するシステムは、複数のノード及び１つの通信チャネルを含む。ノードは、通信チャネルの反復的な通信時間間隔に対する時間ウィンドウ内に通信チャネルを介してデータを送信することを許容されており、通信時間ウィンドウ内に送信されるバイト数は、通信時間ウィンドウごとに変更することができる。データは、識別するタグの表現及びデータの表現を含むメッセージとして送信することができる。それぞれのタグを表しているバイト数は、通信時間間隔ごとに変更することができる。【選択図】  図１０
2009541826.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードと、
通信チャネルと
を具備する、分散ソフトウェアを実行するシステムであって、
前記ノードが、前記通信チャネルを介した通信を許容するように構成されており、所定の一定の持続時間の反復的な通信時間間隔が定義可能であり、データ送信が、前記通信時間間隔に関する開始時刻及び終了時刻によって定義されるデータ通信時間ウィンドウ内で発生し、
前記分散ソフトウェアが、少なくとも第１タスク及び第２タスクを備え、
前記ノードが、前記第１タスク及び前記第２タスクのうちの一方だけが所与の時に実行されるように前記第１タスク及び前記第２タスクを実行するように構成され、
前記第１タスクが、第１データを生成し、前記第１データを前記通信チャネルに第１周期で繰り返し送信し、前記第１データのデータ送信が、それぞれの通信時間間隔に関する同一の開始時刻及び終了時刻を有する第１通信時間ウィンドウ内に発生し、
前記第２タスクが、第２データを生成し、前記第２データを前記通信チャネルに第２周期で繰り返し送信し、前記第２データのデータ送信が、それぞれの通信時間間隔に関する同一の開始時刻及び終了時刻を有する第２通信時間ウィンドウ内に発生し、
前記第１周期及び第２周期のそれぞれが、前記所定の一定の持続時間の整数倍であり、
前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記終了時刻より小さく、前記第２通信時間ウィンドウの前記開始時刻が、前記第１通信時間ウィンドウの前記終了時刻より小さいシステム。
【請求項２】
複数のコントローラをさらに備え、各コントローラが、１つのノードを前記通信チャネルに接続する、請求項１に記載のシステム。
【請求項３】
前記ノードのうちの少なくとも１つに入力信号を供給する少なくとも１つのセンサをさらに備える、請求項１又は２に記載のシステム。
【請求項４】
前記ノードのうちの少なくとも１つによって制御される少なくとも１つのアクチュエータをさらに備える、請求項１〜３のいずれか一項に記載のシステム。
【請求項５】
前記分散ソフトウェアが、複数のモジュールを具備し、各モジュールが、少なくとも１つのタスクを備える、請求項１〜４のいずれか一項に記載のシステム。
【請求項６】
前記第１タスク及び前記第２タスクが、同一モジュールの一部である、請求項５に記載のシステム。
【請求項７】
前記第１タスク及び前記第２タスクが、異なるモジュールの一部である、請求項５に記載のシステム。
【請求項８】
各ノードが、前記複数のモジュールのうちの少なくとも１つを実行するように構成されている、請求項５〜７のいずれか一項に記載のシステム。
【請求項９】
前記複数のモジュールのうちの少なくとも１つが第１モードと第２モードとを少なくとも有し、前記第１モードが前記第１タスクを備え、前記第２モードが前記第２タスクを備え、前記ノードは、モード切替が生じたときに、前記第１タスクの反復実行を停止して前記第２タスクの反復実行を開始するように構成されている、請求項５〜８のいずれか一項に記載のシステム。
【請求項１０】
前記モード切替が、センサの入力信号によって生じる、請求項９に記載のシステム。
【請求項１１】
前記モード切替が、前記少なくとも１つのモジュールの内部状態の変化によって生じる、請求項９に記載のシステム。
【請求項１２】
前記モジュールが、Ｔｉｍｉｎｇ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＴＤＬ）に従って定義可能である、請求項５〜１１のいずれか一項に記載のシステム。
【請求項１３】
前記第１タスク及び／又は前記第２タスクが、それらに関連した所定の論理実行時間間隔を有するように構成されており、前記タスクの呼出しの物理的実行が、前記論理実行時間間隔の開始時又は開始後に開始され、前記タスクの前記呼出しの前記物理的実行が、前記論理実行時間間隔の終了前又は終了時に完了する、請求項１〜１２のいずれか一項に記載のシステム。
【請求項１４】
前記第１タスクを実行する前記ノードが、第３タスクを実行するようにさらに構成されており、前記第１タスクに関連する論理実行時間間隔が、前記第３タスクに関連する論理実行時間間隔とオーバーラップする、請求項１３に記載のシステム。
【請求項１５】
前記第１タスクの各呼出しは、前記第１ウィンドウ内で送信用の第１データを生成する、請求項１〜１４のいずれか一項に記載のシステム。
【請求項１６】
前記システムが、１０−３よりよい相対精度、特に１０−４よりよい相対精度、特に１０−５よりよい相対精度、特に１０−６よりよい相対精度で、前記第１周期及び前記第２周期の持続時間を一定に保つように構成されている、請求項１〜１５のいずれか一項に記載のシステム。
【請求項１７】
前記所定の一定の持続時間の前記通信時間間隔が、０．０１秒未満、特に０．００１秒未満である、請求項１〜１６のいずれか一項に記載のシステム。
【請求項１８】
前記データの前記データ送信が、前記データの表現とタグとを含むメッセージの送信を含み、前記タグが、前記データを生成した前記タスクを示している、請求項１〜１７のいずれか一項に記載のシステム。
【請求項１９】
前記タグが、前記データを生成した前記タスクを含むモジュールを示している、請求項１８に記載のシステム。
【請求項２０】
前記タグが、前記データを生成した前記タスクを含む前記モジュールのモードを示している、請求項１９に記載のシステム。
【請求項２１】
前記第１データを含む第１メッセージに含まれる第１タグが、第１個数のバイトによってエンコードされ、前記第２データを含む第２メッセージに含まれる第２タグが、第２個数のバイトによってエンコードされ、前記第１個数が、前記第２個数と等しい若しくは異なる、請求項１８〜２０のいずれか一項に記載のシステム。
【請求項２２】
前記第１データの前記データ送信が、第１個数のバイトによってエンコードされた前記第１データの表現を含み、前記第２データの前記データ送信が、第２個数のバイトによってエンコードされた前記第２データの表現を含み、前記第１個数が、前記第２個数と等しい若しくは異なる、請求項１〜２１のいずれか一項に記載のシステム。
【請求項２３】
前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記開始時刻と等しい、請求項１〜２２のいずれか一項に記載のシステム。
【請求項２４】
前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記開始時刻と異なる、請求項１〜２２のいずれか一項に記載のシステム。
【請求項２５】
前記第１通信時間ウィンドウの前記終了時刻が、前記第２通信時間ウィンドウの前記終了時刻と異なる、請求項１〜２４のいずれか一項に記載のシステム。
【請求項２６】
前記第１通信時間ウィンドウの前記終了時刻が、前記第２通信時間ウィンドウの前記終了時刻と等しい、請求項１〜２４のいずれか一項に記載のシステム。
【請求項２７】
前記ノードは、第１通信時間間隔内に前記通信チャネルを介して第１個数のデータを送信するように構成されており、且つ、第２通信時間間隔内に前記通信チャネルを介してデータの前記第１個数と等しい若しくは異なる第２個数のデータを送信するように構成されている、請求項１〜２６のいずれか一項に記載のシステム。
【請求項２８】
前記第１データの前記データ送信が、第３データと一緒の前記第１データの送信を含み、データフレームが、前記第１データ及び前記第３データの組み合わされた表現として形成される、請求項１〜２７のいずれか一項に記載のシステム。
【請求項２９】
請求項１〜２８のいずれか一項に記載のシステムを含む乗物。
【請求項３０】
分散ソフトウェアを実行する方法であって、前記方法が、
複数のノード間における通信を許容する通信チャネルを動作させるステップと、
前記複数のノード上で、第１タスク及び第２タスクのうちの一方だけが所与の時に実行中であるように、前記第１タスクと前記第２タスクとを少なくとも実行するステップと、
前記第１タスクによって第１データを生成し、前記第１データを前記通信チャネルに第１周期で繰り返し送信するステップであって、前記第１データの前記送信は、所定の一定の持続時間の反復的な通信時間間隔に関する同一の開始時刻及び終了時刻を有する第１通信時間ウィンドウ内に発生するステップと、
前記第２タスクによって第２データを生成し、前記第２データを前記通信チャネルに第２周期で繰り返し送信するステップであって、前記第２データの前記送信は、前記反復的な通信時間間隔に関する同一の開始時刻及び終了時刻を有する第２通信時間ウィンドウ内に発生するステップと
を含み、
前記第１周期及び前記第２周期のそれぞれが、前記所定の一定の持続時間の整数倍であり、
前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記終了時刻より小さく、前記第２通信時間ウィンドウの前記開始時刻が、前記第１通信時間ウィンドウの前記終了時刻より小さい方法。
【請求項３１】
前記データの前記送信が、前記データの表現及びタグの表現を含むメッセージの送信を含み、前記タグが、前記データを生成した前記タスクを示している、請求項３０に記載の方法。
【請求項３２】
前記第１データを含む第１メッセージに含まれる第１タグが、第１個数のバイトによってエンコードされ、前記第２データを含む第２メッセージに含まれる第２タグが、第２個数のバイトによってエンコードされ、前記第１個数が前記第２個数と異なる、請求項３１に記載の方法。
【請求項３３】
前記第１データの前記送信が、第１個数のバイトによってエンコードされた前記第１データの表現を含み、前記第２データの前記送信が、第２個数のバイトによってエンコードされた前記第２データの表現を含み、前記第１個数が前記第２個数と異なる、請求項３０〜３２のいずれか一項に記載の方法。
【発明の詳細な説明】
【発明の分野】
【０００１】
本発明は、分散ソフトウェアを実行するシステム及び方法に関する。具体的には、本発明は、ハードリアルタイム要件に適合するそのようなシステム及び方法に関する。
【関連技術の簡単な説明】
【０００２】
分散ソフトウェアを実行する従来のシステムは、複数のノード及び１つの通信チャネルを備えることができ、このシステムは、ノードが通信チャネルを介してデータを送信することができるように構成される。そのようなシステムの例には、いわゆる組込みシステムも含まれ、組込みシステムでは、電子制御ユニット又はコンピュータとも呼ばれ得る、ソフトウェアのタスクを実行するノードが、それらが制御するデバイスによってカプセル化されている。組込みシステムの例は、自動車システム、オートメーションシステム、及びアビオニクスシステムを含む。たとえば、自動車システムは、特に、ブレーキを動作させる複数のデバイス、車輪速度を感知する複数のデバイス、車両の速度を感知するデバイスなどを含む場合があり、これらのデバイスは、通信チャネルを介して通信し、アンチブロッキングシステム（ＡＢＳ）の動作を実行するように構成される。アンチブロッキングシステムの動作は、車両及びその乗客にとって安全上クリティカルなものなので、センサの反復的読み取り、計算、及びアクチュエータの更新が、周期的に、たとえば５ミリ秒おきに実行されることが必要である。実際には、そのようなシステムは、ハードリアルタイム要件を満足しなければならず、これは、動作の正しさが、動作の論理的な正しさだけではなく、動作が実行される時刻にも依存することを意味する。システム内で定義されるデッドラインより後に実行される動作は、明らかに不適当であり、通常は価値を有しない。
【０００３】
従来の分散ソフトウェアは、通常、ソフトウェアが、システムが実行しなければならない複数のタスクに分離されるように構成され、ここで、これらのタスクは、異なるノードによって実行でき、各単一のノードが複数のタスクを実行することもできる。ソフトウェアの動作に関して、タスクがその入力としてセンサの出力信号を使用すること、タスクがアクチュエータに信号を出力すること、及び異なるタスクがデータを交換することによって互いに通信することが可能である。したがって、タスクのスケジュール及び実行は、１つ又は複数のセンサによってシステムが検出できる外部イベントに依存する可能性がある。したがって、任意のノード上の任意のシステムの動作のモードは、経時的に変化する可能性があり、帯域幅に関連する通信チャネルに対する需要も、経時的に変化する可能性がある。しかし、ハードリアルタイムシステムでは、通信チャネルによって提供される所与の帯域幅が、含まれるすべてのノードの動作モードの起こりうる組合せのそれぞれの最中に、ハードリアルタイムシステムの支障のない動作を保証するのに十分であることが担保されなければならない。
【０００４】
当技術分野では、ハードリアルタイム要件を満足するように分散ソフトウェアを設計することが、常に容易とは限らないことが周知である。
【０００５】
分散ソフトウェアの設計を改善するために、さまざまな努力が既に行われている。たとえば、米国バークレイのカリフォルニア大学での「Ｇｉｏｔｔｏ」と呼ばれるプロジェクトは、おそらくは分散プラットフォームで動作する組込み制御システムのプログラミング方法論をもたらした。この方法論は、ハードリアルタイム条件の下でタスクの実行の論理実行タイミングを定義するという概念を含む。この概念を、「ＬＥＴ」（論理実行時間、Ｌｏｇｉｃａｌ  Ｅｘｅｃｕｔｉｏｎ  Ｔｉｍｅ）と称し、Ｔ．Ａ．Ｈｅｎｚｉｎｇｅｒ他の論文、「Ｇｉｏｔｔｏ：Ａ  ｔｉｍｅ−ｔｒｉｇｇｅｒｅｄ  ｌａｎｇｕａｇｅ  ｆｏｒ  ｅｍｂｅｄｄｅｄ  ｐｒｏｇｒａｍｍｉｎｇ」、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  Ｆｉｒｓｔ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｅｍｂｅｄｄｅｄ  Ｓｏｆｔｗａｒｅ（ＥＭＳＯＦＴ）、Ｌｅｃｔｕｒｅ  Ｎｏｔｅｓ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ  ２２１１、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、２００１年、１６６〜１８４頁に、より詳細に示されている。この文書の内容全体が、参照によって本明細書に組み込まれている。
【０００６】
分散ソフトウェアのタイミング挙動を指定する言語は、オーストリア、ザルツブルグのザルツブルグ−パリス・ロドロン大学での個人的研究プロジェクトにおいて、Ｗｏｌｆｇａｎｇ  Ｐｒｅｅ及び彼のチームによって開発された。この言語は、「ＴＤＬ」（Ｔｉｍｉｎｇ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（タイミング定義言語））と称し、Ｊｏｓｅｆ  Ｔｅｍｐｌの報告、ＴＤＬ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｒｅｐｏｒｔ、Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  Ｔ００４（ｒｅｖｉｓｅｓ  Ｔ００１）、２００４年１１月、１〜２４頁で定義されている。この文書の内容全体が、参照によって本明細書に組み込まれている。
【０００７】
通信チャネルを介するデータ交換のために分散ソフトウェアシステム内で使用できるデータ交換フォーマットが、文書「ＦＩＢＥＸ−Ｆｉｅｌｄ  Ｂｕｓ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ」、ＭＣＤ−２［ＦＢＸ］  Ｖｅｒｓｉｏｎ  １．１、  Ｒｅｌｅａｓｅ  Ｖｅｒｓｉｏｎ、Ａｓｓｏｃｉａｔｉｏｎ  ｆｏｒ  Ｓｔａｎｄａｒｄｉｓａｔｉｏｎ  ｏｆ  Ａｕｔｏｍａｔｉｏｎ  ａｎｄ  Ｍｅａｓｕｒｉｎｇ  Ｓｙｓｔｅｍｓ、２００５年１月２５日、ＡＳＡＭ  ｅ．Ｖ．、１〜８２頁で定義されている。この文書の内容全体が、参照によって本明細書に組み込まれている。
【０００８】
システムに含まれる起こりうるすべての動作モードにおいて支障のない動作が保証される分散ソフトウェアを設計することが困難であることが判明している。
【発明の概要】
【０００９】
本発明は、上述の従来技術の欠点を克服するためになされた。
【００１０】
本発明の実施形態によれば、分散ソフトウェアを実行するシステムは、そのシステムの通信チャネルによって提供される帯域幅の効率的な使用を可能にする。
【００１１】
本発明の他の実施形態によれば、分散ソフトウェアを実行するシステムは、通信チャネルを介するデータ通信のタイミング要件が動作モードの起こりうるすべての組合せの下で満足されることを保証すると同時に、システムが複数の異なる動作モードで動作することを可能にする。
【００１２】
本発明の例示的実施形態によれば、分散ソフトウェアを実行するシステムは、複数のノードと通信チャネルとを含む。たとえば、このシステムは、通信チャネルによってリンクされたノードの集団である。通信チャネルは、システムのノードを物理的に相互リンクし、これは、特定のノードが、通信チャネルに接続された少なくとも１つのコントローラを含む場合に、そのノードがこのシステムの一部であることを意味する。具体的に言うと、このシステムは、一般に「バス」と称する、ブロードキャスティングセマンティクスを有するただ１つの単一通信チャネルを含むことができる。しかし、本発明は、ブロードキャスティングセマンティクスを有するシステム又は１つのみの単一通信チャネルを有するシステムに限定されるのではなく、スターやリングなどの任意のトポロジの複数の通信チャネルを有するシステム、及びポイントツーポイントセマンティクスなどの異なるセマンティクスを有するシステムをも含むことができる。
【００１３】
ノードは、一部の分野において一般に電子制御ユニットと称されるデバイスであり、そのデバイスは、アクチュエータやエンジン、若しくはセンサの出力信号をソフトウェアによって処理できるデータに変換するためにセンサとのインターフェースを提供するデバイスなどの物理的デバイスを制御するように構成された回路を含むことができる。ノードには、コンピュータとも称されるより複雑な回路をも含めることもでき、その回路は、メモリやプロセッサを含むことができ、且つ入力データに依存し出力データを供給するソフトウェアのタスクを実行するようにプログラムされ得る。
【００１４】
分散ソフトウェアは、複数のタスクを含む。タスクは、ソフトウェアによって提供される機能の一部を表す。たとえば、異なるタスクを異なるノードによって実行することができ、１つ又は複数のノードのそれぞれが、複数のタスクを実行することができる。さらに、異なる動作モードを提供するようにノードを構成又はプログラムすることができ、異なる動作モードでは異なるタスクが実行される。
【００１５】
本発明の一つの態様によれば、分散ソフトウェアは、同時には実行されない第１タスク及び第２タスクを少なくとも含む。したがって、第１タスク及び第２タスクのうちの一方だけが、所与の時に実行されている。
【００１６】
ここでの特定の実施形態によれば、第１タスクは、後に続く第１タスクの呼出しが互いにある時間間隔を有するといった第１の頻度で繰り返し実行され、その時間間隔は第１の頻度に対応する第１周期と等しい。具体的には、第１周期の持続時間は、第１の頻度分の１として計算することができる。タスクは、通信チャネルに送られるデータを生成することができ、第１データのデータ送信も、第１周期に対応する第１の頻度で繰り返して発生するようになっている。通信チャネルによる対応するデータ送信は、開始時刻及び終了時刻を有するそれぞれの時間ウィンドウ内で発生する。したがって、データ送信及び対応する時間ウィンドウは、通信チャネル上において生じる反復イベントと理解することもできる。
【００１７】
同様に、本発明のこの例示的実施形態によれば、第２タスクは、第２周期で、第２データを生成すると共に通信チャネルに第２データを送信することを繰り返し、第２データのデータ送信は、第２通信時間ウィンドウ内に発生し、第２通信時間ウィンドウのそれぞれは、開始時刻及び終了時刻を有する。また、第２データのデータ送信及び第２通信時間ウィンドウは、通信チャネル上において生じる反復イベントと理解することができる。
【００１８】
この例示的実施形態によれば、通信チャネルの動作を、所定の一定の持続時間の反復的な通信時間間隔から構成される送信スケジュールに準拠するものと理解することができ、第１周期及び第２周期のそれぞれは、所定の一定の持続時間の整数倍である。
【００１９】
特定の例示的実施形態によれば、所定の一定の持続時間は、第１周期と第２周期との最大公約数と定義される。
【００２０】
図示の例示的実施形態によれば、同時には実行されない第１タスク及び第２タスクは、それぞれ第１データ及び第２データの送信に関して通信チャネルのスケジュールの反復的な通信時間間隔の共通の時間部分を共有する。具体的に言うと、それぞれの通信時間間隔に対する第１通信時間ウィンドウの開始時刻は、それぞれの通信時間間隔に対する第２通信時間ウィンドウの終了時刻より小さい。同様に、それぞれの通信時間間隔に対する第２通信時間ウィンドウの開始時刻は、それぞれの通信時間間隔に対する第１通信時間ウィンドウの終了時刻より小さい。
【００２１】
本発明の実施態様によれば、通信チャネルの動作スケジュールに関連するそれぞれの通信時間間隔の使用可能な通信時間部分をソフトウェアの異なるタスクの間で共有することによって、分散ソフトウェアの通信帯域幅を節約することが可能である。
【００２２】
本発明の例示的実施形態によれば、このシステムは、１つ又は複数のコントローラを含み、各コントローラは、１つ又は複数のノードを通信チャネルに接続する。したがって、コントローラは、ノードとは別々の、通信チャネルとの間でのデータ送信を実行する専用ハードウェアデバイスである。
【００２３】
本発明の例示的実施形態によれば、分散ソフトウェアは、複数のソフトウェアモジュールに関して定義することができ、このソフトウェアモジュールは、アプリケーションプログラミングインターフェース（ＡＰＩ）を有する複数のソフトウェアである。具体的には、各モジュールは、少なくとも１つのタスクを含むことができる。本発明の特定の実施形態によれば、ソフトウェアの複数のモジュールは、上述のＪｏｓｅｆ  Ｔｅｍｐｌによる文書「ＴＤＬ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｒｅｐｏｒｔ」で指定されたＴｉｍｉｎｇ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ  ＴＤＬによって定義可能である。
【００２４】
例示的実施形態によれば、モジュールは、複数の異なるモードを有すると定義することができ、モード切替は、モジュールのモードをあるモードから別のモードに変更する。具体的に言うと、あるモジュールは、任意の所与の時に正確に１つのモードであることができる。したがって、システムの動作モードを、ソフトウェアのモジュールの対応するモードによって表すことが可能である。また、モジュールのモードを、Ｔｉｍｉｎｇ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ  ＴＤＬによって指定することができる。
【００２５】
本発明の実施形態によれば、タスクの動作を、論理実行時間（ＬＥＴ）によって指定することができ、タスクは、関連付けられた所定の論理実行時間間隔を有するように構成され、あるノードでのタスクの呼出しの物理的実行は、その論理実行時間間隔の開始時又は開始後に開始され、そのノードでのタスクの呼出しの物理的実行は、その論理実行時間間隔の終了前又は終了時に完了する。
【００２６】
本発明の特定の実施形態によれば、分散ソフトウェアを実行するシステムは、ハードリアルタイムアプリケーションに使用される。ハードリアルタイム要件を満たす観点から、本発明の例示的実施形態は、システムの動作中に第１周期及び第２周期の持続時間を１０−３よりよい相対精度、１０−４よりよい相対精度、又は１０−５若しくは１０−６よりよい相対精度で一定に維持するように構成されたシステムを提供する。
【００２７】
同様に、本発明の例示的実施形態は、通信チャネルのスケジュールに関連する通信時間間隔が０．０１秒未満又は０．００１秒未満の持続時間を有するように構成されたシステムを提供する。
【００２８】
それぞれの通信時間ウィンドウ内に通信チャネル上で送信されるデータは、さまざまなデータフォーマットを有することができる。本発明の例示的実施形態によれば、データのデータ送信は、送信されるデータの表現と、データを生成したタスクを示し、メッセージの受取り側がデータを生成したタスクを識別することを可能にするタグとを含むメッセージの送信を含む。したがって、メッセージの受取り側は、それぞれのメッセージ及びそれに含まれるデータが、あるタスク又は別のタスクのどちらから発したかを区別することができる。
【００２９】
ソフトウェアがモジュールに関して定義される、本発明のさらなる例示的実施形態によれば、タグは、データを生成したタスクを含むモジュールを示すものとすることができる。したがって、メッセージの受取り側は、どのモジュールが特定の受け取られたメッセージを生成する責任を負ったかをも判定することができる。
【００３０】
さらに、ソフトウェアが異なるモードを有するモジュールに関して定義される、本発明の例示的実施形態では、タグは、それぞれのメッセージに含まれるデータが生成された時のモジュールのモードを示すものとすることもできる。
【００３１】
通常、生成されたデータのデータ送信は、ある個数のバイトによってエンコードされたデータの表現を含む。本発明の例示的実施形態によれば、第１タスクによって生成された第１データを表すのに使用されるバイト数は、第２タスクによって生成された第２データを表すのに使用されるバイト数とは異なる。したがって、第１データ及び第２データは、異なるデータ長を有することができる。
【００３２】
同様に、タグのデータ送信は、ある個数のバイトによってエンコードされたタグの表現を含む。本発明の例示的実施形態によれば、第１データの表現と一緒に第１メッセージを形成する第１タグを表すのに使用されるバイト数は、第２データの表現と一緒に第２メッセージを形成する第２タグを表すのに使用されるバイト数とは異なる。したがって、第１タグ及び第２タグは、異なるデータ長を有することができる。
【００３３】
本発明の例示的実施形態によれば、分散ソフトウェアを実行する方法が、複数のノード間での通信を可能にするために通信チャネルを動作させるステップと、複数のノード上の第１タスク及び第２タスクのうちの１つだけが所与の時に実行されるように、第１タスクと第２タスクとを少なくとも実行するステップと、第１タスクによって第１データを生成し、第１データを通信チャネルに第１周期で繰り返し送信するステップであって、第１データの送信は、所定の一定の持続時間の反復的な通信時間間隔に対する同一の開始時刻及び終了時刻を有する第１通信時間ウィンドウ内に発生するステップと、第２タスクによって第２データを生成し、第２データを通信チャネルに第２周期で繰り返し送信するステップであって、第２データの送信は、反復的な通信時間間隔に対する同一の開始時刻及び終了時刻を有する第２通信時間ウィンドウ内に発生するステップとを含み、第１周期及び第２周期のそれぞれが、所定の一定の持続時間の整数倍であり、第１通信時間ウィンドウの開始時刻が、第２通信時間ウィンドウの終了時刻より小さく、第２通信時間ウィンドウの開始時刻が、第１通信時間ウィンドウの終了時刻より小さい。
【００３４】
本発明の前述並びに他の有利な特徴は、添付図面に関する本発明の例示的実施形態の次の詳細な説明からより明らかになる。本発明のあらゆる可能な実施形態が、必ずしも、本明細書で識別される利益のそれぞれ及びすべて、又はいずれかを示すわけではないことに留意されたい。
【図面の簡単な説明】
【００３５】
【図１】分散ソフトウェアを実行するシステムを示す概略図である。
【図２】図１に示されたシステムのソフトウェアの例示的モジュールを表す概略図である。
【図３】論理実行時間（ＬＥＴ）の概念を示す概略図である。
【図４】同一ノード上での異なるタスクの同時実行を示す概略図である。
【図５】異なるノードによって実行され、通信チャネルを介して通信する異なるタスクの同時実行を示す概略図である。
【図６】（ａ）〜（ｃ）は通信時間間隔内のフレームを共有するさまざまな通信時間ウィンドウを示す図である。
【図７】図１に示されたシステムでデータ送信に使用される通信スケジュールを決定する方法を示す図である。
【図８】図１に示されたシステムでデータ送信に使用される通信スケジュールを決定する方法を示すもう１つの図である。
【図９】図１に示されたシステムでデータ送信に使用される通信スケジュールを決定する方法を示すもう１つの図である。
【図１０】図１に示されたシステムでデータ送信に使用される通信スケジュールを決定する方法を示すもう１つの図である。
【発明を実施するための形態】
【００３６】
下で説明する例示的実施形態では、機能及び構造において類似するコンポーネントは、できる限り、類似する符号によって示される。したがって、特定の実施形態の個々のコンポーネントの特徴を理解するために、本発明の他の実施形態の説明及び本発明の要約を参照しなければならない。
【００３７】
分散ソフトウェアを実行する例示的システムを、図１に概略的に示す。
【００３８】
図１は、それぞれ「ノード１」、「ノード２」、及び「ノード３」としてラベルを付けられ、「バス」としてラベルを付けられた通信チャネル５に接続された３つのノード３を含むシステム１を示す。バスは、ノード３の間のデータ通信に使用される。ノードは、自動車産業などの応用のいくつかの分野で電子制御ユニット（ＥＣＵ）と称する電子デバイスである。各ノードは、そのノードを通信チャネルに接続する、一般にコントローラと称する専用のハードウェアを含む場合がある。図１に示された例では、通信チャネルは、ブロードキャスティングセマンティクスを有するバスとして実施され、これは、ノードの１つから通信チャネルに送信されるデータが、他のノードのすべてによって受け取られ得ることを意味する。しかし、本発明は、そのような通信チャネルに限定されるのではなく、他の適切なトポロジ及びセマンティクスの通信チャネルをも含む。
【００３９】
システム１は、複数のモジュールＭ１、Ｍ２、Ｍ３、及びＭ４から構成されるソフトウェアを実行するように構成される。モジュールは、複雑なソフトウェアを構成する方法の例であり、モジュールは、一般に、アプリケーションプログラミングインターフェース（ＡＰＩ）を有する１つのソフトウェアである。複数のモジュールから構成されるソフトウェアは、そのソフトウェアを実行する複数のノードにわたるそのソフトウェアの透過的分散を可能にする。図１に示された例では、ノード１は、モジュールＭ１及びＭ２を実行し、ノード２は、モジュールＭ３を実行し、ノード３は、モジュールＭ４を実行する。
【００４０】
２つのモジュールから構成されるソフトウェアのより具体的な例を、図２に示す。図２に示された例示的ソフトウェアは、「モジュールサービス」としてラベルを付けられた第１モジュール７と、「モジュールクライアント」としてラベルを付けられた第２モジュール８とを含む。各モジュールは、センサ９の組、アクチュエータ１０の組、及びモード１１の組からなるものとすることができる。モジュール７のセンサ９は、「Ｓ１」、「Ｓ２」というラベルを付けられ、モジュール８のセンサ９は、「Ｓ」というラベルを付けられている。モジュール７のアクチュエータ１０は、「Ａ１」、「Ａ２」、及び「Ａ３」としてラベルを付けられ、モジュール８のアクチュエータ１０は、「Ａ１」及び「Ａ２」としてラベルを付けられている。モジュール７は、「モード１」及び「モード２」としてラベルを付けられた２つのモード１１を有する。モジュール８は、「モード１」、「モード２」、及び「モード３」としてラベルを付けられた３つのモード１１を有する。
【００４１】
各モジュール７、８は、所与の時に１つのモードにしかなることができない。モジュール７のモード１は、「タスク１」及び「タスク２」としてラベルを付けられた２つのタスクを含み、タスク１は、「［１０ｍｓ］」によって示されるように１０ミリ秒の第１周期で繰り返して実行され、タスク２は、２０ミリ秒の周期（「［２０ｍｓ］」によって示される）で繰り返して実行される。
【００４２】
本例では、タスク呼出しは、Ｇｉｏｔｔｏプログラミングモデル（上述のＴ．Ａ．Ｈｅｎｚｉｎｇｅｒ他の論文を参照されたい）によって導入されたＬＥＴセマンティクスを厳守するものとすることができる。ＬＥＴに従うタスク呼出しを、図３の概略図に示す。タスクの入力は、ＬＥＴ周期の始めに読み取られる。ＬＥＴ周期の始めは、図３では「解放」というラベルを付けられた矢印によって示される。タスクの新たに計算された出力は、正確にＬＥＴ周期の終りに使用可能であり、ＬＥＴ周期の終りは、図３では「終了」というラベルを付けられた矢印によって示される。このノードでのタスクの物理的実行は、「開始」というラベルを付けられた矢印によって示される時刻に開始され、「停止」というラベルを付けられた矢印によって示される時刻に終了され、ここで、タスクの物理的実行は、「中断」というラベルを付けられた矢印によって示される時刻に中断され、「再開」というラベルを付けられた矢印によって示される時刻に再開される。
【００４３】
物理的実行の時刻は、ＬＥＴによって正確には定義されない。しかし、タスクの物理的実行が、ＬＥＴ周期の終りの前に終了しなければならないことが、要件である。言い換えると、タスクの物理的実行の開始は、ＬＥＴ周期の始めに又は始まった後に行うことができ、タスクの物理的実行の終了は、ＬＥＴ周期の終りの前又は終りに発生しなければならない。ＬＥＴセマンティクスによれば、タスクの計算の結果は、タスクの物理的実行の終りではなく、ＬＥＴ周期の終り又は終わった後にのみ、タスクの外部で使用可能である。これは、ＬＥＴ周期の終りの前に、タスクの以前の呼出しの結果が使用可能であることを意味する。
【００４４】
戻って図２を参照すると、モジュール７のモード１のタスク１は、１０ミリ秒の周期で繰り返して実行され、センサは、正確にその１０ミリ秒周期の始めに読み取られ、タスク１の計算の結果は、正確にその１０ミリ秒周期の終りにアクチュエータＡ１に対して利用可能となる。
【００４５】
図２には、タスクの間の通信も示されている。たとえば、モジュール８のモード１のタスク１は、その出力を入力としてタスク２及びタスク３に送達する。
【００４６】
さらに、図２には、モジュール境界にわたるタスクの通信が示されている。モジュール７のモード１のタスク２の出力は、「ｔａｓｋ２．ｏ」というラベルを付けられ、モジュール８のモード１のタスク１に入力として供給される。
【００４７】
ＬＥＴセマンティクスに従うモジュールのセットのソフトウェアの構成及びモジュールのタスクの定義は、１つ又は複数のノードにわたるソフトウェアの透過的分散を可能にし、ここで、ソフトウェアの時間的挙動が保証される。具体的に言うと、新しいモジュールの追加は、ワーストケース実行時間（ｗｃｅｔ）及び実行レートがすべてのタスクについて既知であるならば、それぞれのノードの内部スケジューリング機構がＬＥＴへの準拠を保証する限り、他のモジュールの観察可能な時間的挙動に絶対に影響しない。
【００４８】
図４は、図１に示されたノード１によるモジュールＭ１及びＭ２の実行の図である。モジュールＭ１は、ＬＥＴ１を有する１つのタスク「タスク１」を有し、モジュールＭ２は、ＬＥＴ２を有する１つのタスク「タスク２」を有する。タスク２は、タスク１の出力を入力として使用し、タスク１のＬＥＴ１は、タスク２のＬＥＴ２の２倍の長さである。図４の灰色の長方形は、タスク１及びタスク２の物理的実行時間を概略的に示す。タスク１の出力は、矢印１３によって示されるように、タスク１の論理実行時間ＬＥＴ１の終りにタスク２から使用可能にされる。これは、タスク１に関連するメモリの位置からタスク２に関連するメモリの位置へ値をコピーすることによって達成することができる。そのようなコピーは、単一ノード上では０に近い時間を要する。
【００４９】
図４に示されたタスク２の第３の呼出しと第４の呼出しとの両方が、タスク１の第１呼出しの出力を使用する。これは、タスク２の第４呼出しの物理的実行が開始される時に、タスク１の第２呼出しの物理的実行が既に完了している場合であっても、タスク２の第４呼出しが、タスク１の第２呼出しの出力を使用しないことを意味する。
【００５０】
ソフトウェアの通信するモジュールが、異なるノードによって実行される場合に、モジュールのタスクの間の通信は、かなりの時間を要する。というのは、通信が通信チャネルを介するデータの送信を含み、所与の時に１つのノードだけがデータを送信できるからである。
【００５１】
図５に、図１に示されたシステム１のノード１上のモジュールＭ１とノード３上のモジュールＭ４との間の通信の例を示す。
【００５２】
図５に示された例では、モジュールＭ４のタスク４は、タスク１の論理実行時間周期ＬＥＴ１の半分である論理実行時間周期ＬＥＴ４を有する。図５の「ｃｏｍｍ１」及び「ｃｏｍｍ３」は、それぞれノード１及びノード３の通信ポートのメモリバッファを示す。メッセージをノード１からノード２に送ることができる最も早い可能な時刻は、タスク１の物理的実行が終了した後であり、これが、メッセージ解放制約を形成する。ＬＥＴ要件に従って、メッセージは、ＬＥＴ１の終りの前にノード２に到着しなければならず、これが、メッセージデッドライン制約を形成する。
【００５３】
システム１の通信スケジュールを生成するアルゴリズムは、通信チャネルを介して通信される必要があるすべてのメッセージの、すべてのメッセージ解放制約及びすべてのメッセージデッドライン制約を考慮しなければならない。これらの制約は、通常、通信モジュールのそれぞれの特定のモードに依存して変化する。たとえば、通信スケジュールは、統計的に、たとえばテーブルとして、いつどのメッセージをどのソースノードからどの宛先ノードに送らなければならないかを記述する。通信スケジュールに記述されたメッセージ送信アクティビティは、通信時間間隔と呼ぶことができる、ある長さの時間の後に繰り返される。通信チャネルとしてバスを使用する応用例では、通信時間間隔を、一般にバス周期と称する。
【００５４】
図６の（ａ）〜（ｃ）は、本発明の実施形態に従って分散ソフトウェアを実行するシステム内で後の時刻に発生し得る３つの例示的な通信時間間隔の図である。通信時間間隔２１の各インスタンスは、開始時刻ｔ０と、通信時間間隔の次のインスタンスの開始時刻ｔ０と一致する終了時刻とを有する。
【００５５】
本例の通信スケジュールは、通信時間間隔２１内の、その通信時間間隔の開始時刻ｔ０に対して相対的に固定された持続時間及び位置を有する、フレーム２３を含む。複数のメッセージを１つのフレーム２３にバインドすることができ、そのフレーム２３は、通信時間間隔２１に対して相対的に測定された時にすべてがフレーム２３の通信時間内にあるが異なる絶対時刻にデータを送信することができる。反復的な通信時間間隔に対して相対的に測定されたメッセージ送信の絶対開始時刻及び絶対終了時刻が、そのメッセージの通信時間ウィンドウを定義する。
【００５６】
ノードからのデータの各送信は、タグの表現を含むメッセージの送信とデータの表現の送信とを含み、このそれぞれが、それぞれの通信時間ウィンドウ２５内にある。データの各表現は、１つ又は複数のタスクによって生成されたデータをエンコードするのに所定の個数のバイトを使用する。同様に、タグの各表現は、メッセージがそこから送られるノードの識別、データを生成したタスクの識別、データを生成したタスクを含むモジュールの識別、タスクがデータを生成した時のモジュールのモードの識別、及び特定のアプリケーションに有用である可能性がある他の情報などの追加情報をエンコードする所定の個数のバイトを含む。
【００５７】
図６の（ａ）〜（ｃ）から、フレーム２３の開始時刻及び終了時刻が、通信時間周期２１内で固定されていることは明らかである。それぞれの通信時間間隔２１に関する、そのフレームにバインドされた異なるメッセージに関連する異なる通信時間ウィンドウ２５の開始時刻ｔ１及び終了時刻ｔ２は、ある通信時間間隔２１と他の通信時間間隔とで異なるものとすることができる。しかし、１つのメッセージに関連する通信時間ウィンドウ２５の開始時刻ｔ１及び終了時刻ｔ２は、ある通信時間間隔２１と他の通信時間間隔とで固定されている。
【００５８】
本明細書では、タグの表現のバイト数及びデータの表現のバイト数を、あるデータ送信と次のデータ送信とで異なるものとすることができる。
【００５９】
通信スケジュールを作るアルゴリズムの例を、下で示す。
【００６０】
この例において、ソフトウェアは、ＬＥＴセマンティクスを厳守するモジュールから構成されると仮定する。さらに、通信チャネルは、あるノードによって送られたデータをすべての他のノードが同時に受け取ることができるように、ブロードキャストセマンティクスに基づくと仮定する。この例において、さらに、フレームが、送信できるデータの最小単位であることと、異なるノードによって送信されるフレームを単一のフレームに組み合わせることができないこととを仮定する。しかし、本発明は、ＥｔｈｅｒＣＡＴなど、フレームを複数のノードによって共有できるシステムにも適用可能である。
【００６１】
本例によれば、通信チャネルへのアクセスは、時分割多元接続（ＴＤＭＡ）手法を介した無衝突（ｃｏｌｌｉｓｉｏｎ  ｆｒｅｅ）である。
【００６２】
本例において、さらに、ソフトウェアを、タスク呼出しが絶対にモード切替によって割り込まれないようにモード切替を制限する、ＴＤＬなどのＬＥＴベースの記述言語によって指定できると仮定する。したがって、モード切替は、調和的（ｈａｒｍｏｎｉｃ）と言われ、これは、モード切替が、現在アクティブなモードのすべてのタスク呼出しのＬＥＴ中に発生してはならないことを意味する。
【００６３】
所望のスケジュールは、スケジュールのサイズが有限になるように、静的スケジュールでなければならない。したがって、スケジュールは、通信時間間隔と称する持続時間の周期で反復して実行され、或いは、バスを使用する本例においては、通信時間間隔をバス周期と称する。
【００６４】
バス周期は、次のように計算される。
【００６５】
通信チャネルにデータを送信するモジュールＭごとに、モジュールＭのすべてのモードにおけるモード周期とモード切替周期との最大公約数（ＧＣＤ）としてｍｓｐＧＣＤＭを定義する。Ｎ・ｍｓｐＧＣＤＭから（Ｎ＋１）・ｍｓｐＧＣＤＭまでの時間期間内に、モジュールＭ内でモード切替がないことは明らかである。言い換えると、モード切替の瞬間は、ｍｓｐＧＣＤＭの整数倍として表すことができる。
【００６６】
次に、バス周期は、通信チャネルにデータを送信する各モジュールＭのｎｍｓｐＧＣＤＭの最大公約数として計算される。
【００６７】
次に、各モード周期は、バス周期の整数倍からなり、用語「フェーズ」が、モードのこれらの相互に排他的な部分を区別するために導入される。
【００６８】
上で示したように、データは、タグ及びデータを含むメッセージの表現が送られる通信時間ウィンドウ内に通信チャネルに送信される。各メッセージは、個々のタイミング制約を有し、解放制約は、メッセージ送信を開始できる最も早い瞬間であり、メッセージのデッドライン制約は、メッセージ送信を終了しなければならない最も遅い瞬間である。解放制約に、そのメッセージを作るタスク呼出しの解放時間にそのワーストケース実行時間（ｗｃｅｔ）を加えたものをセットすることが可能である。デッドライン制約は、データを作るタスクの呼出しのＬＥＴの終りから生じる。メッセージの解放及びデッドラインは、タスク呼出しが終了するフェーズに対するものである。
【００６９】
通信チャネルを効率的に使用するために、バス周期内の１つ又は複数の予約済み通信フレームをモジュールのすべてのフェーズに使用できるように、フェーズのメッセージを、これらの通信フレームにマッピングすることができる。
【００７０】
通信スケジュールを作るためには、フレームを決定し、各メッセージを正確に１つのフレームにバインドすることが必要である。ランタイムに、ノード、タスク呼出し、及びモジュールの特定のモードのフェーズが、フレームにバインドされたメッセージのどのサブセットが実際に送られるのかを決定する。フレームの内容はランタイムに変化するので、タグは、メッセージを識別するのに有用である。
【００７１】
フレームの解放制約は、そのフレームにバインドされたメッセージの解放制約の最大値である。同様に、フレームのデッドライン制約は、そのフレームにバインドされたすべてのメッセージのデッドライン制約の最小値である。これを、３つのフェーズを有し、フェーズ１で４バイトのメッセージ１、フェーズ２で３バイトのメッセージ２、フェーズ３でそれぞれ１バイトの２つのメッセージ３及び４を作ると仮定される例示的モジュールについて、図７に概略的に示す。サイズ制約及びタイミング制約に依存して、すべてのメッセージは、４バイトのサイズを有する同一フレームにバインドされ得る。メッセージ及びフレームを表す箱の左右の境界は、それぞれ解放制約及びデッドライン制約を表す。
【００７２】
図８に、個々のメッセージの解放制約及びデッドライン制約と、それらのメッセージが３つの別個のフェーズからなるモード周期全体を通じてバインドされるフレームとを示す。
【００７３】
メッセージをフレームにバインドするアルゴリズムは、次の擬似コードによって表すことができる。
createFrames(Module M) returns Set {
let frames be an empty      set
for each mode m of module M {
for each phase p of m {
let msgs be an empty set
for each task invocation instance tthat ends in p {
add new Message(M, m, t, p) to msgs
}
bindMsgs(msgs, frames)
}
}
return frames
}
bindMsgs(Set msgs, Set frames) {
reset the available bytes of allframes to the size of
each frame
for each msg in msgs {
if (frames is empty) {
createFrame(msg, frames)
} else {
for each frame in frames {
computeMetric(msg, frame)
}
select the frame selFrame with thehighest metric
if (selFrame.metric > threshold) {
bind(msg, selFrame) 
} else {
createFrame(msg, frames)
}
}
}
}
【００７４】
メソッドｂｉｎｄＭｓｇｓは、可能な場合にメッセージを既存フレームに関連付ける。可能ではない場合には、新しいフレームが作成され、メッセージは、その新しいフレームにバインドされる。メソッドｃｒｅａｔｅＦｒａｍｅは、フレームを作成し、メッセージをそのフレームにバインドし、フレームのサイズにそのメッセージのサイズをセットし、そのフレームをフレームのセットに追加する。メソッドｃｒｅａｔｅＦｒａｍｅは、フレームを通信時間間隔すなわちバス周期内に送信できるように、フレームのサイズが通信チャネルによって許容される最大値を超えないかどうかをもチェックする。
【００７５】
メッセージをフレームにバインドする判断は、フレームのサイズから入手可能なバイト数に依存するメトリック計算の結果に依存する。したがって、インスタンス変数ａｖａｉｌａｂｌｅが、フレームごとに定義され、各フェーズの始めにフレームのサイズにリセットされる。メソッドｂｉｎｄＭｓｇｓは、メッセージをフレームにバインドし、フレームの使用可能なバイト数をメッセージサイズだけ減らす。ヒューリスティックを使用するメソッドｃｏｍｐｕｔｅＭｅｔｒｉｃの例を、本明細書で下で例示する。
【００７６】
この例では、メソッドｃｏｍｐｕｔｅＭｅｔｒｉｃは、０と１との間の実数を計算し、その数をフレームのインスタンス変数ｍｅｔｒｉｃに格納する。それぞれのメッセージについて、ｃｏｍｐｕｔｅＭｅｔｒｉｃの値は、フレームごとに計算され、そのメトリックの最大値をもたらすフレームが識別され、メッセージは、そのメトリックの値が所定のしきい値を超える場合にそのフレームにバインドされる。したがって、既存フレームへのメッセージの割り当ては、帯域幅の節約とタイミング制約を狭めることとの間のトレードオフを導入する。このために、本明細書で提示するアルゴリズム及びヒューリスティックを、有利に使用することができる。しかし、これらのアルゴリズム及びヒューリスティックは、本発明の例示的実施形態のみを表し、さらなる最適化さえもたらす可能性がある他のアルゴリズム及びヒューリスティックが考えられる。
【００７７】
本明細書で下で示す例示的メトリックは、オーバーラッピングメトリック（ｏｖｅｒｌａｐｐｉｎｇ  ｍｅｔｒｉｃ）及びエンラージメントメトリック（ｅｎｌａｒｇｅｍｅｎｔ  ｍｅｔｒｉｃ）と称する２つの部分を有し、これらのメトリックは、フレームとメッセージとの間のタイミング制約及びサイズ制約の互換性を測定するものである。オーバーラッピングメトリックは、たとえば次の式に従って、メッセージとフレームとの間のオーバーラップの度合を測定する。
【数１】
2009541826.tif 000003
ここで、
ｏｖｅｒｌａｐｐｉｎｇ＝Ｍｉｎ（ｆｒａｍｅ．ｄ，ｍｓｇ．ｄ）−Ｍａｘ（ｆｒａｍｅ．ｒ，ｍｓｇ．ｒ）
ここで、
ｆｒａｍｅ．ｒは、フレームの解放制約を表し、
ｆｒａｍｅ．ｄは、フレームのデッドライン制約を表し、
ｍｓｇ．ｒは、メッセージの解放制約を表し、
ｍｓｇ．ｄは、メッセージのデッドライン制約を表す。
【００７８】
エンラージメントメトリックは、メッセージを収めるためにフレームのサイズをどれほど拡大する必要があるかを測定する。エンラージメントメトリックは、次の式によって計算される。
【数２】
2009541826.tif 000004
ここで、
ｅｎｌａｒｇｅｍｅｎｔ＝Ｍａｘ（０，ｍｓｇ．ｓｉｚｅ−ｆｒａｍｅ．ａｖａｉｌａｂｌｅ）
ここで、
ｆｒａｍｅ．ｓｉｚｅは、フレームのサイズを表し、
ｆｒａｍｅ．ａｖａｉｌａｂｌｅは、まだ使用可能なフレームサイズの量を表し、
ｍｓｇ．ｓｉｚｅは、メッセージのサイズを表す。
【００７９】
次に、ｃｏｍｐｕｔｅＭｅｔｒｉｃの値は、次の式に従ってオーバーラッピングメトリックとエンラージメントメトリックとの平均をとることによって計算することができ、
【数３】
2009541826.tif 000005
ここで、この式は、エンラージメントメトリックとオーバーラッピングメトリックとの両方が正の値をもたらす時に限って適用される。オーバーラッピングメトリック及びエンラージメントメトリックの一方が０以下の値を生じる倍には、ｃｏｍｐｕｔｅＭｅｔｒｉｃの値も０と計算される。
【００８０】
上のアルゴリズムに従って計算スケジュールを作る例を、図１に示されたシステム１のノード２によって実行されるモジュールＭ３に関して、次で提供する。
【００８１】
この例では、モジュールＭ３は、下の表１に示されているように、２つのモードＭ１及びＭ２と３つのタスクｔ１、ｔ２、及びｔ３を有する。
【表１】
2009541826.tif 000006
【００８２】
ワーストケース実行時間（ｗｃｅｔ）及び出力データの表現のサイズなど、タスクｔ１、ｔ２、及びｔ３の詳細を、下の表２に示す。
【表２】
2009541826.tif 000007
【００８３】
モード切替が、現在アクティブなモードのタスク呼出しのＬＥＴ中に発生してはならないので、モジュールＭ３のｍｓｐＧＣＤＭは、次のように計算される。
ｍｓｐＧＣＤＭ３＝ＧＣＤ（５，１０）＝５ｍｓ
【００８４】
バス周期は、各モジュールＭのｍｓｐＧＣＤＭの最大公約数として計算される。モジュールＭ３だけが通信チャネルにデータを送ろうとしている本例では、モジュールＭ３だけをこのＧＣＤ計算に含めればよい。したがって、バス周期は、ｍｓｐＧＣＤＭ３と等しく、５ｍｓである。
【００８５】
下に示された表３に、すべてのモードでタスクが送らなければならないすべてのメッセージをリストする。解放時間及びデッドライン時間は、メッセージを送るタスクのモード周期に対するものである。解放時間は、ＬＥＴの始めにワーストケース実行時間（ｗｃｅｔ）を加えたものと等しく、デッドライン時間は、ＬＥＴの終りと等しい。
【表３】
2009541826.tif 000008
【００８６】
下に示された表４に、解放制約及びデッドライン制約が２つのモードのすべてのフェーズのバス周期に対して示された、表３のメッセージをリストする。
【表４】
2009541826.tif 000009
【００８７】
上の擬似コードによって示されるアルゴリズムによれば、反復は、すべてのモード及びフェーズにわたって実行され、評価は、メッセージが既存フレームに割り当てられるかどうか又は新しいフレームが作成されるかどうかに関して行われる。このアルゴリズムによる手順は、モードＭ１及びフェーズ１から開始され、このフェーズ１は、このモードでの唯一のフェーズである。この手順の始めに、フレームは作成されておらず、このモード用に作成されるフレームは、そのタイミング制約を最初のメッセージから継承する。次に、フレームサイズは、メッセージサイズと、本例では１バイトになるように選択されるタグサイズとの合計と等しい。
【００８８】
下の表５に、この手順の現段階によるフレーム及びバインドされるメッセージをリストする。
【表５】
2009541826.tif 000010
【００８９】
次のステップでは、モードＭ２が、フェーズ１について検討され、ここで、データの送信は、モードＭ２のフェーズ１では実行されない。したがって、フェーズ２のメッセージ２を、次に検討する。メトリックが、メッセージ２を既存フレームにバインドするか否かを決定するために評価される。この例では、０．５というしきい値が使用される。オーバーラッピングメトリックは、次のように計算される。
ｏｖｅｒｌａｐｐｉｎｇ＝Ｍｉｎ（５，５）−Ｍａｘ（１，０）＝４
【数４】
2009541826.tif 000011
【００９０】
すべてのフレームの使用可能なスペースが、すべての新しいフェーズでリセットされるので、フレームが、このフェーズでは拡大されないことは明らかであり、メッセージ２のサイズは、３バイトである（１バイトのタグを含む）。したがって、エンラージメントメトリックの値は、１である。全体的なメトリックの値は、０．９と１．０との平均をとることによって０．９５になると計算される。０．９５は、しきい値を十分に超えるので、メッセージ２はフレーム１にバインドされ、このフェーズでの使用可能なスペースが２バイトに減る。下に示された表６は、この手順のこの現段階でのフレーム及びバインドされるメッセージを表す。
【表６】
2009541826.tif 000012
【００９１】
フェーズ２のメッセージ３が、次に検討される。メッセージ３のタイミング要件は、メッセージ２のタイミング要件と同一なので、オーバーラッピングメトリックの結果は、やはり０．９０である。
【００９２】
メッセージ３のサイズは、３バイトであり、ここで、１バイトのタグが含まれる。したがって、ｍｓｇ．ｓｉｚｅ＝３、ｆｒａｍｅ．ａｖａｉｌａｂｌｅ＝２、及びｆｒａｍｅ．ｓｉｚｅ＝５である。これらの値を用いて、エンラージメントメトリックを次のように計算することができる。
ｅｎｌａｒｇｅｍｅｎｔ＝Ｍａｘ（０，（３−２））＝１
【数５】
2009541826.tif 000013
【００９３】
全体的なメトリックは、０．９０及び０．８３の平均をとることによって０．８７をもたらし、これは、０．５という選択されたしきい値を十分に超える。したがって、メッセージ３は、やはりフレーム１にバインドされ、そのサイズを６バイトに増やし、これを下の表７に示す。
【表７】
2009541826.tif 000014
【００９４】
この提示された例では、すべてのメッセージを１つの単一のフレームにバインドすることが可能である。この識別されたフレームについて、適切なバススケジュールは、解放制約及びデッドライン制約を考慮に入れながら生成されなければならない。そのようなスケジュールは、Ｊ．Ｗ．Ｓ．Ｌｉｕ、「Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ」、Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、２０００年に示されているように、最新解放時間（ｌａｔｅｓｔ  ｒｅｌｅａｓｅ  ｔｉｍｅ）スケジューリングアルゴリズムＬＲＴに従って決定することができる。これは、図９に示されたバススケジュールをもたらし、ここで、フレーム１は、その送信が５ｍｓに終わるようにスケジューリングされる。
【００９５】
図１０は、モジュールＭ３のモードｍ１及びｍ２について上で示したアルゴリズムによるメッセージのバインドから生じる動的マルチプレクシングの図である。６バイトの容量を有するフレーム１は、モードｍ１で５バイトのサイズを有するメッセージ１を充てんされ、或いは、モードｍ２で３バイトのサイズを有するメッセージ２及びやはり３バイトのサイズを有するメッセージ３を充てんされ、或いは、このフレームは空のままにされる。
【００９６】
ハードリアルタイム条件の下で分散ソフトウェアを実行するシステムの実施形態は、複数のノード及び１つの通信チャネルを含む。ノードは、通信チャネルの反復的な通信時間間隔に対する時間ウィンドウ内に通信チャネルを介してデータを送信することを許可され、この通信時間ウィンドウ内に送信されるバイト数は、通信時間ウィンドウごとに変更することができる。データは、識別するタグの表現及びデータの表現を含むメッセージとして送信することができる。また、それぞれのタグを表すバイト数を通信時間間隔ごとに変更することができる。
【００９７】
分散ソフトウェアを実行する、上で示したシステム及び方法は、任意のテクニカルアプリケーションの機能又は性能を制御するために、そのアプリケーションに含めることができる。たとえば、このシステム及び方法を、自動車、航空機、船、ミサイル、及び他などの乗物に含めることができる。
【００９８】
本発明を、本発明のある種の例示的実施形態に関して説明してきたが、多数の代替形態、修正形態、及び変形形態が当業者に明らかであることは自明である。したがって、本明細書で示された本発明の例示的実施形態は、例示的であることを意図され、いかなる形であれ限定的であることは意図されていない。さまざまな変更を、添付の特許請求の範囲で定義される本発明の趣旨及び範囲から逸脱せずに行うことができる。
【図１】
2009541826.tif 000015
【図２】
2009541826.tif 000016
【図３】
2009541826.tif 000017
【図４】
2009541826.tif 000018
【図５】
2009541826.tif 000019
【図６】
2009541826.tif 000020
【図７】
2009541826.tif 000021
【図８】
2009541826.tif 000022
【図９】
2009541826.tif 000023
【図１０】
2009541826.tif 000024
【国際調査報告】
2009541826.tif 000025
2009541826.tif 000026