JP2012133789A - 分散ソフトウェアを実行するシステム及び方法 - Google Patents

分散ソフトウェアを実行するシステム及び方法 Download PDF

Info

Publication number
JP2012133789A
JP2012133789A JP2012010145A JP2012010145A JP2012133789A JP 2012133789 A JP2012133789 A JP 2012133789A JP 2012010145 A JP2012010145 A JP 2012010145A JP 2012010145 A JP2012010145 A JP 2012010145A JP 2012133789 A JP2012133789 A JP 2012133789A
Authority
JP
Japan
Prior art keywords
data
task
communication
time
communication time
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.)
Pending
Application number
JP2012010145A
Other languages
English (en)
Inventor
Pree Wolfgang
ヴォルフガング プリー，
Templ Josef
ヨセフ テンプル，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WOLFGANG PAULI GmbH
Original Assignee
WOLFGANG PAULI GmbH
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by WOLFGANG PAULI GmbH filed Critical WOLFGANG PAULI GmbH
Publication of JP2012133789A publication Critical patent/JP2012133789A/ja
Pending legal-status Critical Current

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/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/101—Collaborative creation, e.g. joint development of products or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multi Processors (AREA)
  • Small-Scale Networks (AREA)

Abstract

【課題】ハードリアルタイム要件に適合するそのようなシステム及び方法を提供する。
【解決手段】ハードリアルタイム条件の下で分散ソフトウェアを実行するシステムは、複数のノード及び１つの通信チャネルを含む。ノードは、通信チャネルの反復的な通信時間間隔に対する時間ウィンドウ内に通信チャネルを介してデータを送信することを許容されており、通
信時間ウィンドウ内に送信されるバイト数は、通信時間ウィンドウごとに変更することができる。データは、識別するタグの表現及びデータの表現を含むメッセージとして送信することができる。それぞれのタグを表しているバイト数は、通信時間間隔ごとに変更することができる。
【選択図】図１０

Description

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

bindMsgs(Set msgs, Setframes) {
reset theavailable bytes of allframes to the size of
each frame
for each msg inmsgs {
if (frames isempty) {
createFrame(msg,frames)
} else {
for each framein frames {
computeMetric(msg,frame)
}
select theframe selFrame with thehighest metric
if(selFrame.metric > threshold) {
bind(msg,selFrame)
} else {
createFrame(msg,frames)
}
}
}
}
メソッドｂｉｎｄＭｓｇｓは、可能な場合にメッセージを既存フレームに関連付ける。可能ではない場合には、新しいフレームが作成され、メッセージは、その新しいフレームにバインドされる。メソッドｃｒｅａｔｅＦｒａｍｅは、フレームを作成し、メッセージをそのフレームにバインドし、フレームのサイズにそのメッセージのサイズをセットし、そのフレームをフレームのセットに追加する。メソッドｃｒｅａｔｅＦｒａｍｅは、フレームを通信時間間隔すなわちバス周期内に送信できるように、フレームのサイズが通信チャネルによって許容される最大値を超えないかどうかをもチェックする。
メッセージをフレームにバインドする判断は、フレームのサイズから入手可能なバイト数に依存するメトリック計算の結果に依存する。したがって、インスタンス変数ａｖａｉｌａｂｌｅが、フレームごとに定義され、各フェーズの始めにフレームのサイズにリセットされる。メソッドｂｉｎｄＭｓｇｓは、メッセージをフレームにバインドし、フレームの使用可能なバイト数をメッセージサイズだけ減らす。ヒューリスティックを使用するメソッドｃｏｍｐｕｔｅＭｅｔｒｉｃの例を、本明細書で下で例示する。
この例では、メソッドｃｏｍｐｕｔｅＭｅｔｒｉｃは、０と１との間の実数を計算し、その数をフレームのインスタンス変数ｍｅｔｒｉｃに格納する。それぞれのメッセージについて、ｃｏｍｐｕｔｅＭｅｔｒｉｃの値は、フレームごとに計算され、そのメトリックの最大値をもたらすフレームが識別され、メッセージは、そのメトリックの値が所定のしきい値を超える場合にそのフレームにバインドされる。したがって、既存フレームへのメッセージの割り当ては、帯域幅の節約とタイミング制約を狭めることとの間のトレードオフを導入する。このために、本明細書で提示するアルゴリズム及びヒューリスティックを、有利に使用することができる。しかし、これらのアルゴリズム及びヒューリスティックは、本発明の例示的実施形態のみを表し、さらなる最適化さえもたらす可能性がある他のアルゴリズム及びヒューリスティックが考えられる。
本明細書で下で示す例示的メトリックは、オーバーラッピングメトリック（ｏｖｅｒｌａｐｐｉｎｇ ｍｅｔｒｉｃ）及びエンラージメントメトリック（ｅｎｌａｒｇｅｍｅｎｔ ｍｅｔｒｉｃ）と称する２つの部分を有し、これらのメトリックは、フレームとメッセージとの間のタイミング制約及びサイズ制約の互換性を測定するものである。オーバーラッピングメトリックは、たとえば次の式に従って、メッセージとフレームとの間のオーバーラップの度合を測定する。
Figure 2012133789


ここで、
ｏｖｅｒｌａｐｐｉｎｇ＝Ｍｉｎ（ｆｒａｍｅ．ｄ，ｍｓｇ．ｄ）−Ｍａｘ（ｆｒａｍｅ．ｒ，ｍｓｇ．ｒ）
ここで、
ｆｒａｍｅ．ｒは、フレームの解放制約を表し、
ｆｒａｍｅ．ｄは、フレームのデッドライン制約を表し、
ｍｓｇ．ｒは、メッセージの解放制約を表し、
ｍｓｇ．ｄは、メッセージのデッドライン制約を表す。
エンラージメントメトリックは、メッセージを収めるためにフレームのサイズをどれほど拡大する必要があるかを測定する。エンラージメントメトリックは、次の式によって計算される。
Figure 2012133789


ここで、
ｅｎｌａｒｇｅｍｅｎｔ＝Ｍａｘ（０，ｍｓｇ．ｓｉｚｅ−ｆｒａｍｅ．ａｖａｉｌａｂｌｅ）
ここで、
ｆｒａｍｅ．ｓｉｚｅは、フレームのサイズを表し、
ｆｒａｍｅ．ａｖａｉｌａｂｌｅは、まだ使用可能なフレームサイズの量を表し、
ｍｓｇ．ｓｉｚｅは、メッセージのサイズを表す。
次に、ｃｏｍｐｕｔｅＭｅｔｒｉｃの値は、次の式に従ってオーバーラッピングメトリックとエンラージメントメトリックとの平均をとることによって計算することができ、
Figure 2012133789


ここで、この式は、エンラージメントメトリックとオーバーラッピングメトリックとの両方が正の値をもたらす時に限って適用される。オーバーラッピングメトリック及びエンラージメントメトリックの一方が０以下の値を生じる倍には、ｃｏｍｐｕｔｅＭｅｔｒｉｃの値も０と計算される。
上のアルゴリズムに従って計算スケジュールを作る例を、図１に示されたシステム１のノード２によって実行されるモジュールＭ３に関して、次で提供する。
この例では、モジュールＭ３は、下の表１に示されているように、２つのモードＭ１及びＭ２と３つのタスクｔ１、ｔ２、及びｔ３を有する。
Figure 2012133789
ワーストケース実行時間（ｗｃｅｔ）及び出力データの表現のサイズなど、タスクｔ１、ｔ２、及びｔ３の詳細を、下の表２に示す。
Figure 2012133789
モード切替が、現在アクティブなモードのタスク呼出しのＬＥＴ中に発生してはならないので、モジュールＭ３のｍｓｐＧＣＤＭは、次のように計算される。
ｍｓｐＧＣＤＭ３＝ＧＣＤ（５，１０）＝５ｍｓ
バス周期は、各モジュールＭのｍｓｐＧＣＤＭの最大公約数として計算される。モジュールＭ３だけが通信チャネルにデータを送ろうとしている本例では、モジュールＭ３だけをこのＧＣＤ計算に含めればよい。したがって、バス周期は、ｍｓｐＧＣＤＭ３と等しく、５ｍｓである。
下に示された表３に、すべてのモードでタスクが送らなければならないすべてのメッセージをリストする。解放時間及びデッドライン時間は、メッセージを送るタスクのモード周期に対するものである。解放時間は、ＬＥＴの始めにワーストケース実行時間（ｗｃｅｔ）を加えたものと等しく、デッドライン時間は、ＬＥＴの終りと等しい。
Figure 2012133789
下に示された表４に、解放制約及びデッドライン制約が２つのモードのすべてのフェーズのバス周期に対して示された、表３のメッセージをリストする。
Figure 2012133789
上の擬似コードによって示されるアルゴリズムによれば、反復は、すべてのモード及びフェーズにわたって実行され、評価は、メッセージが既存フレームに割り当てられるかどうか又は新しいフレームが作成されるかどうかに関して行われる。このアルゴリズムによる手順は、モードＭ１及びフェーズ１から開始され、このフェーズ１は、このモードでの唯一のフェーズである。この手順の始めに、フレームは作成されておらず、このモード用に作成されるフレームは、そのタイミング制約を最初のメッセージから継承する。次に、フレームサイズは、メッセージサイズと、本例では１バイトになるように選択されるタグサイズとの合計と等しい。
下の表５に、この手順の現段階によるフレーム及びバインドされるメッセージをリストする。
Figure 2012133789
次のステップでは、モードＭ２が、フェーズ１について検討され、ここで、データの送信は、モードＭ２のフェーズ１では実行されない。したがって、フェーズ２のメッセージ２を、次に検討する。メトリックが、メッセージ２を既存フレームにバインドするか否かを決定するために評価される。この例では、０．５というしきい値が使用される。オーバーラッピングメトリックは、次のように計算される。
ｏｖｅｒｌａｐｐｉｎｇ＝Ｍｉｎ（５，５）−Ｍａｘ（１，０）＝４
Figure 2012133789
すべてのフレームの使用可能なスペースが、すべての新しいフェーズでリセットされるので、フレームが、このフェーズでは拡大されないことは明らかであり、メッセージ２のサイズは、３バイトである（１バイトのタグを含む）。したがって、エンラージメントメトリックの値は、１である。全体的なメトリックの値は、０．９と１．０との平均をとることによって０．９５になると計算される。０．９５は、しきい値を十分に超えるので、メッセージ２はフレーム１にバインドされ、このフェーズでの使用可能なスペースが２バイトに減る。下に示された表６は、この手順のこの現段階でのフレーム及びバインドされるメッセージを表す。
Figure 2012133789
フェーズ２のメッセージ３が、次に検討される。メッセージ３のタイミング要件は、メッセージ２のタイミング要件と同一なので、オーバーラッピングメトリックの結果は、やはり０．９０である。
メッセージ３のサイズは、３バイトであり、ここで、１バイトのタグが含まれる。したがって、ｍｓｇ．ｓｉｚｅ＝３、ｆｒａｍｅ．ａｖａｉｌａｂｌｅ＝２、及びｆｒａｍｅ．ｓｉｚｅ＝５である。これらの値を用いて、エンラージメントメトリックを次のように計算することができる。
ｅｎｌａｒｇｅｍｅｎｔ＝Ｍａｘ（０，（３−２））＝１
Figure 2012133789
全体的なメトリックは、０．９０及び０．８３の平均をとることによって０．８７をもたらし、これは、０．５という選択されたしきい値を十分に超える。したがって、メッセージ３は、やはりフレーム１にバインドされ、そのサイズを６バイトに増やし、これを下の表７に示す。
Figure 2012133789
この提示された例では、すべてのメッセージを１つの単一のフレームにバインドすることが可能である。この識別されたフレームについて、適切なバススケジュールは、解放制約及びデッドライン制約を考慮に入れながら生成されなければならない。そのようなスケジュールは、Ｊ．Ｗ．Ｓ．Ｌｉｕ、「Ｒｅａｌ−Ｔｉｍｅ Ｓｙｓｔｅｍｓ」、Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、２０００年に示されているように、最新解放時間（ｌａｔｅｓｔ ｒｅｌｅａｓｅ ｔｉｍｅ）スケジューリングアルゴリズムＬＲＴに従って決定することができる。これは、図９に示されたバススケジュールをもたらし、ここで、フレーム１は、その送信が５ｍｓに終わるようにスケジューリングされる。
図１０は、モジュールＭ３のモードｍ１及びｍ２について上で示したアルゴリズムによるメッセージのバインドから生じる動的マルチプレクシングの図である。６バイトの容量を有するフレーム１は、モードｍ１で５バイトのサイズを有するメッセージ１を充てんされ、或いは、モードｍ２で３バイトのサイズを有するメッセージ２及びやはり３バイトのサイズを有するメッセージ３を充てんされ、或いは、このフレームは空のままにされる。
ハードリアルタイム条件の下で分散ソフトウェアを実行するシステムの実施形態は、複数のノード及び１つの通信チャネルを含む。ノードは、通信チャネルの反復的な通信時間間隔に対する時間ウィンドウ内に通信チャネルを介してデータを送信することを許可され、この通信時間ウィンドウ内に送信されるバイト数は、通信時間ウィンドウごとに変更することができる。データは、識別するタグの表現及びデータの表現を含むメッセージとして送信することができる。また、それぞれのタグを表すバイト数を通信時間間隔ごとに変更することができる。
分散ソフトウェアを実行する、上で示したシステム及び方法は、任意のテクニカルアプリケーションの機能又は性能を制御するために、そのアプリケーションに含めることができる。たとえば、このシステム及び方法を、自動車、航空機、船、ミサイル、及び他などの乗物に含めることができる。
本発明を、本発明のある種の例示的実施形態に関して説明してきたが、多数の代替形態、修正形態、及び変形形態が当業者に明らかであることは自明である。したがって、本明細書で示された本発明の例示的実施形態は、例示的であることを意図され、いかなる形であれ限定的であることは意図されていない。さまざまな変更を、添付の特許請求の範囲で定義される本発明の趣旨及び範囲から逸脱せずに行うことができる。

Claims (33)

  1. 複数のノードと、
    通信チャネルと
    を具備する、分散ソフトウェアを実行するシステムであって、
    前記ノードが、前記通信チャネルを介した通信を許容するように構成されており、所定の一定の持続時間の反復的な通信時間間隔が定義可能であり、データ送信が、前記通信時間間隔に関する開始時刻及び終了時刻によって定義されるデータ通信時間ウィンドウ内で発生し、
    前記分散ソフトウェアが、少なくとも第１タスク及び第２タスクを備え、
    前記ノードが、前記第１タスク及び前記第２タスクのうちの一方だけが所与の時に実行されるように前記第１タスク及び前記第２タスクを実行するように構成され、
    前記第１タスクが、第１データを生成し、前記第１データを前記通信チャネルに第１周期で繰り返し送信し、前記第１データのデータ送信が、それぞれの通信時間間隔に関する同一の開始時刻及び終了時刻を有する第１通信時間ウィンドウ内に発生し、
    前記第２タスクが、第２データを生成し、前記第２データを前記通信チャネルに第２周期で繰り返し送信し、前記第２データのデータ送信が、それぞれの通信時間間隔に関する同一の開始時刻及び終了時刻を有する第２通信時間ウィンドウ内に発生し、
    前記第１周期及び第２周期のそれぞれが、前記所定の一定の持続時間の整数倍であり、
    前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記終了時刻より小さく、前記第２通信時間ウィンドウの前記開始時刻が、前記第１通信時間ウィンドウの前記終了時刻より小さいシステム。
  2. 複数のコントローラをさらに備え、各コントローラが、１つのノードを前記通信チャネルに接続する、請求項１に記載のシステム。
  3. 前記ノードのうちの少なくとも１つに入力信号を供給する少なくとも１つのセンサをさらに備える、請求項１又は２に記載のシステム。
  4. 前記ノードのうちの少なくとも１つによって制御される少なくとも１つのアクチュエータをさらに備える、請求項１〜３のいずれか一項に記載のシステム。
  5. 前記分散ソフトウェアが、複数のモジュールを具備し、各モジュールが、少なくとも１つのタスクを備える、請求項１〜４のいずれか一項に記載のシステム。
  6. 前記第１タスク及び前記第２タスクが、同一モジュールの一部である、請求項５に記載のシステム。
  7. 前記第１タスク及び前記第２タスクが、異なるモジュールの一部である、請求項５に記載のシステム。
  8. 各ノードが、前記複数のモジュールのうちの少なくとも１つを実行するように構成されている、請求項５〜７のいずれか一項に記載のシステム。
  9. 前記複数のモジュールのうちの少なくとも１つが第１モードと第２モードとを少なくとも有し、前記第１モードが前記第１タスクを備え、前記第２モードが前記第２タスクを備え、前記ノードは、モード切替が生じたときに、前記第１タスクの反復実行を停止して前記第２タスクの反復実行を開始するように構成されている、請求項５〜８のいずれか一項に記載のシステム。
  10. 前記モード切替が、センサの入力信号によって生じる、請求項９に記載のシステム。
  11. 前記モード切替が、前記少なくとも１つのモジュールの内部状態の変化によって生じる、請求項９に記載のシステム。
  12. 前記モジュールが、Ｔｉｍｉｎｇ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ（ＴＤＬ）に従って定義可能である、請求項５〜１１のいずれか一項に記載のシステム。
  13. 前記第１タスク及び／又は前記第２タスクが、それらに関連した所定の論理実行時間間隔を有するように構成されており、前記タスクの呼出しの物理的実行が、前記論理実行時間間隔の開始時又は開始後に開始され、前記タスクの前記呼出しの前記物理的実行が、前記論理実行時間間隔の終了前又は終了時に完了する、請求項１〜１２のいずれか一項に記載のシステム。
  14. 前記第１タスクを実行する前記ノードが、第３タスクを実行するようにさらに構成されており、前記第１タスクに関連する論理実行時間間隔が、前記第３タスクに関連する論理実行時間間隔とオーバーラップする、請求項１３に記載のシステム。
  15. 前記第１タスクの各呼出しは、前記第１ウィンドウ内で送信用の第１データを生成する、請求項１〜１４のいずれか一項に記載のシステム。
  16. 前記システムが、１０−３よりよい相対精度、特に１０−４よりよい相対精度、特に１０−５よりよい相対精度、特に１０−６よりよい相対精度で、前記第１周期及び前記第２周期の持続時間を一定に保つように構成されている、請求項１〜１５のいずれか一項に記載のシステム。
  17. 前記所定の一定の持続時間の前記通信時間間隔が、０．０１秒未満、特に０．００１秒未満である、請求項１〜１６のいずれか一項に記載のシステム。
  18. 前記データの前記データ送信が、前記データの表現とタグとを含むメッセージの送信を含み、前記タグが、前記データを生成した前記タスクを示している、請求項１〜１７のいずれか一項に記載のシステム。
  19. 前記タグが、前記データを生成した前記タスクを含むモジュールを示している、請求項１８に記載のシステム。
  20. 前記タグが、前記データを生成した前記タスクを含む前記モジュールのモードを示している、請求項１９に記載のシステム。
  21. 前記第１データを含む第１メッセージに含まれる第１タグが、第１個数のバイトによってエンコードされ、前記第２データを含む第２メッセージに含まれる第２タグが、第２個数のバイトによってエンコードされ、前記第１個数が、前記第２個数と等しい若しくは異なる、請求項１８〜２０のいずれか一項に記載のシステム。
  22. 前記第１データの前記データ送信が、第１個数のバイトによってエンコードされた前記第１データの表現を含み、前記第２データの前記データ送信が、第２個数のバイトによってエンコードされた前記第２データの表現を含み、前記第１個数が、前記第２個数と等しい若しくは異なる、請求項１〜２１のいずれか一項に記載のシステム。
  23. 前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記開始時刻と等しい、請求項１〜２２のいずれか一項に記載のシステム。
  24. 前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記開始時刻と異なる、請求項１〜２２のいずれか一項に記載のシステム。
  25. 前記第１通信時間ウィンドウの前記終了時刻が、前記第２通信時間ウィンドウの前記終了時刻と異なる、請求項１〜２４のいずれか一項に記載のシステム。
  26. 前記第１通信時間ウィンドウの前記終了時刻が、前記第２通信時間ウィンドウの前記終了時刻と等しい、請求項１〜２４のいずれか一項に記載のシステム。
  27. 前記ノードは、第１通信時間間隔内に前記通信チャネルを介して第１個数のデータを送信するように構成されており、且つ、第２通信時間間隔内に前記通信チャネルを介してデータの前記第１個数と等しい若しくは異なる第２個数のデータを送信するように構成されている、請求項１〜２６のいずれか一項に記載のシステム。
  28. 前記第１データの前記データ送信が、第３データと一緒の前記第１データの送信を含み、データフレームが、前記第１データ及び前記第３データの組み合わされた表現として形成される、請求項１〜２７のいずれか一項に記載のシステム。
  29. 請求項１〜２８のいずれか一項に記載のシステムを含む乗物。
  30. 分散ソフトウェアを実行する方法であって、前記方法が、
    複数のノード間における通信を許容する通信チャネルを動作させるステップと、
    前記複数のノード上で、第１タスク及び第２タスクのうちの一方だけが所与の時に実行中であるように、前記第１タスクと前記第２タスクとを少なくとも実行するステップと、
    前記第１タスクによって第１データを生成し、前記第１データを前記通信チャネルに第１周期で繰り返し送信するステップであって、前記第１データの前記送信は、所定の一定の持続時間の反復的な通信時間間隔に関する同一の開始時刻及び終了時刻を有する第１通信時間ウィンドウ内に発生するステップと、
    前記第２タスクによって第２データを生成し、前記第２データを前記通信チャネルに第２周期で繰り返し送信するステップであって、前記第２データの前記送信は、前記反復的な通信時間間隔に関する同一の開始時刻及び終了時刻を有する第２通信時間ウィンドウ内に発生するステップと
    を含み、
    前記第１周期及び前記第２周期のそれぞれが、前記所定の一定の持続時間の整数倍であり、
    前記第１通信時間ウィンドウの前記開始時刻が、前記第２通信時間ウィンドウの前記終了時刻より小さく、前記第２通信時間ウィンドウの前記開始時刻が、前記第１通信時間ウィンドウの前記終了時刻より小さい方法。
  31. 前記データの前記送信が、前記データの表現及びタグの表現を含むメッセージの送信を含み、前記タグが、前記データを生成した前記タスクを示している、請求項３０に記載の方法。
  32. 前記第１データを含む第１メッセージに含まれる第１タグが、第１個数のバイトによってエンコードされ、前記第２データを含む第２メッセージに含まれる第２タグが、第２個数のバイトによってエンコードされ、前記第１個数が前記第２個数と異なる、請求項３１に記載の方法。
  33. 前記第１データの前記送信が、第１個数のバイトによってエンコードされた前記第１データの表現を含み、前記第２データの前記送信が、第２個数のバイトによってエンコードされた前記第２データの表現を含み、前記第１個数が前記第２個数と異なる、請求項３０〜３２のいずれか一項に記載の方法。
JP2012010145A 2006-06-19 2012-01-20 分散ソフトウェアを実行するシステム及び方法 Pending JP2012133789A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP06012518A EP1870806A1 (en) 2006-06-19 2006-06-19 System for executing distributed sofware
EP06012518.4 2006-06-19

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2009515749A Division JP2009541826A (ja) 2006-06-19 2007-06-15 分散ソフトウェアを実行するシステム及び方法

Publications (1)

Publication Number Publication Date
JP2012133789A true JP2012133789A (ja) 2012-07-12

Family

ID=37865760

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2009515749A Pending JP2009541826A (ja) 2006-06-19 2007-06-15 分散ソフトウェアを実行するシステム及び方法
JP2012010145A Pending JP2012133789A (ja) 2006-06-19 2012-01-20 分散ソフトウェアを実行するシステム及び方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2009515749A Pending JP2009541826A (ja) 2006-06-19 2007-06-15 分散ソフトウェアを実行するシステム及び方法

Country Status (4)

Country Link
US (2) US7848359B2 (ja)
EP (1) EP1870806A1 (ja)
JP (2) JP2009541826A (ja)
WO (1) WO2007147530A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015170016A (ja) * 2014-03-05 2015-09-28 三菱電機株式会社 データ送信装置及びデータ送信方法及びプログラム
US11169795B2 (en) 2019-10-09 2021-11-09 Toyota Motor North America, Inc. Management of transport software updates
US11294662B2 (en) 2019-10-09 2022-04-05 Toyota Motor North America, Inc. Management of transport software updates
US11422792B2 (en) 2019-10-09 2022-08-23 Toyota Motor North America, Inc. Management of transport software updates
US11461087B2 (en) 2020-02-28 2022-10-04 Toyota Motor North America, Inc. Transport sensor data update
US11514729B2 (en) 2020-02-28 2022-11-29 Toyota Motor North America, Inc. Transport behavior observation

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1870806A1 (en) * 2006-06-19 2007-12-26 Wolfgang Pree GmbH System for executing distributed sofware
US20090150862A1 (en) * 2007-12-10 2009-06-11 Agilent Technologies, Inc. User-specified semantics for parallel operations with a time-explicit programming language
JP4876138B2 (ja) * 2009-03-24 2012-02-15 株式会社日立産機システム 制御用計算機および制御システム
DE102009027627B3 (de) * 2009-07-10 2011-03-17 Wolfgang Pree Gmbh Simulation von Echtzeit-Software-Komponenten auf Basis der Logischen Ausführungszeit
EP2659650B1 (en) * 2010-12-29 2022-06-22 Citrix Systems Inc. Systems and methods for multi-level tagging of encrypted items for additional security and efficient encrypted item determination
CN102833168B (zh) * 2012-08-31 2015-12-02 北京东土科技股份有限公司 一种基于时间触发机制的数据传输方法及装置
DE102016202305A1 (de) 2016-02-16 2017-08-17 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Steuergeräts
DE102018205392A1 (de) * 2018-04-10 2019-10-10 Robert Bosch Gmbh Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten
DE102018205390A1 (de) * 2018-04-10 2019-10-10 Robert Bosch Gmbh Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5825098A (en) * 1997-02-21 1998-10-20 Breed Automotive Technologies, Inc. Vehicle safety device controller
US6611755B1 (en) * 1999-12-19 2003-08-26 Trimble Navigation Ltd. Vehicle tracking, communication and fleet management system
KR100537499B1 (ko) * 2002-07-26 2005-12-19 삼성전자주식회사 전송제어 파라미터 생성방법 및 프레임 특성에 따른선택적 자동 재전송 방법
US7327310B2 (en) * 2003-11-07 2008-02-05 Global Locate, Inc. Method and apparatus for managing time in a satellite positioning system
US20070002140A1 (en) * 2005-05-03 2007-01-04 Greg Benson Trusted monitoring system and method
EP1870806A1 (en) * 2006-06-19 2007-12-26 Wolfgang Pree GmbH System for executing distributed sofware
US8087010B2 (en) * 2007-09-26 2011-12-27 International Business Machines Corporation Selective code generation optimization for an advanced dual-representation polyhedral loop transformation framework

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN7011001770; Ｆａｒｃａｓ，Ｅ: 'Ａｐｐｒｏａｃｈｅｓ　ｔｏ　ｂｕｓ　ｓｃｈｅｄｕｌｉｎｇ　ｆｏｒ　ＴＤＬ　ｃｏｍｐｏｎｅｎｔｓ' Ｔｅｃｈｎｉｃａｌ　Ｒｅｐｏｒｔ　１３，Ｄｅｐａｒｔｍｅｎｔ　ｏｆ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅ　Ｕｎｉｖ．　ｏｆ　Ｓａｌｚｂｕｒｇ， , 20050830 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015170016A (ja) * 2014-03-05 2015-09-28 三菱電機株式会社 データ送信装置及びデータ送信方法及びプログラム
US11169795B2 (en) 2019-10-09 2021-11-09 Toyota Motor North America, Inc. Management of transport software updates
US11294662B2 (en) 2019-10-09 2022-04-05 Toyota Motor North America, Inc. Management of transport software updates
US11422792B2 (en) 2019-10-09 2022-08-23 Toyota Motor North America, Inc. Management of transport software updates
US11755314B2 (en) 2019-10-09 2023-09-12 Toyota Motor North America, Inc. Management of transport software updates
US11868764B2 (en) 2019-10-09 2024-01-09 Toyota Motor North America, Inc. Management of transport software updates
US11868757B2 (en) 2019-10-09 2024-01-09 Toyota Motor North America, Inc. Management of transport software updates
US12056484B2 (en) 2019-10-09 2024-08-06 Toyota Motor North America, Inc. Management of transport software updates
US11461087B2 (en) 2020-02-28 2022-10-04 Toyota Motor North America, Inc. Transport sensor data update
US11514729B2 (en) 2020-02-28 2022-11-29 Toyota Motor North America, Inc. Transport behavior observation

Also Published As

Publication number Publication date
EP1870806A1 (en) 2007-12-26
US20110044345A1 (en) 2011-02-24
JP2009541826A (ja) 2009-11-26
WO2007147530A1 (en) 2007-12-27
US7848359B2 (en) 2010-12-07
US20080013572A1 (en) 2008-01-17

Similar Documents

Publication Publication Date Title
JP2012133789A (ja) 分散ソフトウェアを実行するシステム及び方法
Hu et al. Holistic scheduling of real-time applications in time-triggered in-vehicle networks
CN102761385A (zh) 使用Flexray全局时间的应用s/w执行的跨网络同步
Pop et al. Analysis and optimization of distributed real-time embedded systems
Pop et al. Schedulability-driven frame packing for multicluster distributed embedded systems
Gemlau et al. A platform programming paradigm for heterogeneous systems integration
US20040153859A1 (en) Communication method for the realization of event channels in a time-driven communication system
Darbandi et al. Schedule construction under precedence constraints in FlexRay in-vehicle networks
Klobedanz et al. Distributed coordination of task migration for fault-tolerant FlexRay networks
Azim et al. Generation of communication schedules for multi-mode distributed real-time applications
Lange et al. A reference model for the timing analysis of heterogeneous automotive networks
Broy et al. The impact of time-triggered communication in automotive embedded systems
Kaiser et al. A real-time event channel model for the CAN-Bus
Mishra et al. Distributed control system development for FlexRay-based systems
Farcas et al. Hyperperiod bus scheduling and optimizations for TDL components
Pop et al. Analysis and optimisation of heterogeneous real-time embedded systems
Wenninger et al. Multilevel sensor node simulation within a tlm-like network simulation framework
Armengaud et al. Automotive software architecture: Migration challenges from an event-triggered to a time-triggered communication scheme
Kim et al. FlexRay protocol: Objectives and features
Amerion et al. A survey on scheduling and optimization techniques for static segment of flexray protocol
Obermaisser Formal specification of gateways in integrated architectures
Farcas et al. Bus scheduling for TDL components
Obermaisser et al. Model-based design of the communication system in an integrated architecture
van den Heuvel et al. An experience report on the integration of ECU software using an HSF-enabled real-time kernel¦
Shokry et al. Hardware EDF scheduler implementation on controller area network controller

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130416

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130716

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130719

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130814

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130819

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20131112