JP4177099B2 - システムレベルのシミュレーションにおけるスケジューリングの階層仕様方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、民生用組込み（consumer embedded）システムのシステムレベルのシミュレーションにおけるスケジューリングの階層仕様とモデリングに関する。
【０００２】
【従来の技術】
今日、民生用組込みシステムの設計は、製品を市場に投入するまでの期間及び製品の寿命サイクルが短くなり、また通信と演算処理（computing）を融合させたいという製品に対する要求が高まっており、劇的に変貌している。ソフトウェアは、かつては設計のほんの一部にすぎなかったが、今や支配的になり始めている。どの会社も単独では、通信と演算処理を統合した明日の製品（tomorrow's converging products）を製作するのに必要な全ての専門的知識を持っていないので、知的財産（intellectual property）を再利用しなければならない。
【０００３】
本発明の出願人であるケイデンスデザインシステムズ（Candence Design Systems）から入手可能な仮想コンポーネント協調設計法（virtual component codesign methodology：以下、ＶＣＣという）は、これらの問題にシステムレベルで対応するために設計された方法である。ＶＣＣは、組込みシステム設計用の仮想コンポーネント（知的財産）の評価、選択、統合（integration）及び仕様（specification）に関するツールとライブラリのセットを組み合わせた方法である。この意味における仮想コンポーネントは、ハードウェア及びソフトウェアの動作（behavior）を含むとともに、ハードウェア及びソフトウェアのアーキテクチャも含んでいる。
【０００４】
主要な３つのタスクがＶＣＣにおける設計フローを構成している。すなわち、動作の作成（composing behavior）、アーキテクチャの取得（capturing architecture）及びアーキテクチャ上への動作のマッピング（mapping behavior onto architecture）である。ＶＣＣにおける動作は、高レベルのトークン（tokens）を渡すブロックの個々のイベントのネットワークとして表現される。ＶＣＣにおけるアーキテクチャは、ハードウェア及びソフトウェアの構造のトポロジーとして表現される。ＶＣＣにおけるマッピングは、動作をアーキテクチャ構造に割り当てることである。
【０００５】
マッピングにおける割当は、どの動作ブロックをハードウェアとするか、どの動作ブロックをソフトウェアにするか、動作ブロック間の通信をどのように行うかを決定することである。多数の動作ブロックを１つのアーキテクチャリソースに割り当てることができ、共有（sharing）と呼ばれる。例えば、殆どの民生用組込みシステムにおいては、１個のマイクロプロセッサが全てのソフトウェアで共有されることはごく普通のことである。
【０００６】
ＶＣＣ環境は、システムが何をするかを確認する動作モデルと、システムがどのように実行されるかを確認するアーキテクチャモデルとの区別をユーザが明らかにすることができる包括的なシステムレベルの設計環境を提供する。このシステム機能とアーキテクチャとを明確に区別することにより、システム設計者は、設計サイクルの初期の段階において、異なる複数のアーキテクチャ上で動作を実行して、性能への影響（performance effects）をシミュレーションすることができる。
【０００７】
ＶＣＣ環境は、システム設計者が仮想コンポーネントの図形的な表現（graphical representations）を用いて、機能的及びアーキテクチャ的に作業を行う環境である。ＶＣＣの動作ダイアグラムエディタ（behavior diagram editor）では、動作ダイアグラム、すなわち互いに結線された機能モデルを集めたダイアグラムを作成することによって、システムの機能を取得することができる。
【０００８】
ＶＣＣ環境を用いたトップダウン方式の設計フローにおいて、設計者は、動作モデルを生成する場合には、ａ）未定義のブロックを置き、ｂ）インタフェースと設計パラメータを定義し、ｃ）このブロックのシンボル（symbol）を生成する。ユーザが、このブロックがどのように実行されるかを一旦定義すると、モデルの動作用のデフォルトのテンプレートを有するウィンドウが生成される。ＶＣＣ環境を用いたボトムアップ方式の設計フローでは、設計者は、階層的な動作ダイアグラムエディタを用いて、既存の動作モデルを表す図形シンボルを作成し、そして、これらのシンボル間の相互接続を生成する。
【０００９】
ＶＣＣは、多種多様なソースから機能的なＩＰをＶＣＣシミュレーション環境にインポートする（import）能力を提供し、これにより、設計者は、多様なＩＰが混在した（heterogeneous）システムの機能を完全にシミュレーションすることができる。このシミュレーションは、実行可能な機能仕様（executable functional specification）として使用することができる。
【００１０】
ＶＣＣアーキテクチャダイアグラムエディタを用いて、設計者は、システム機能がマッピングされる抽象的なターゲットアーキテクチャを取得することができる。ＶＣＣ環境は、完全な協調設計環境であるので、ＣＰＵ、ＤＳＰ、ＲＴＯＳ、バス、メモリ、専用のハードウェア及びソフトウェア等のアーキテクチャの基本的な構成要素（essential architectual element）をサポートしている。これらのアーキテクチャの構成要素は、設計を短期間で評価するために、実行レベルのＣやＨＤＬに比べ、より高い抽象度でモデリングされる。
【００１１】
ＶＣＣマッピングダイアグラムエディタによって、設計者は、システムの機能をターゲットアーキテクチャのプラットホームにマッピングすることができる。このマッピングは、ハードウェアとソフトウェアの切り分け（partition）の候補を定義し、システム設計を完成させるためにはカスタムハードウェアの開発が必要かどうかを見極める手助けとなる。また、設計者は、通信線（communication wires）を詳細化するのにもマッピングダイアグラムエディタを利用する。
【００１２】
一旦マッピングダイアグラムが完成すると、システム設計者は、ソフトウェア評価及び性能パラメータをタイミングフリーな機能モデル内にアノテートすることによって可能（enabled）となる性能シミュレーションを用いて、マッピングした設計を評価することができる。
【００１３】
ＶＣＣにおいて、性能シミュレーションは、特定のマッピングした設計について、システムのタイミングがユーザ仕様に合うかを判定する。ユーザ仕様に合わないときは、ユーザは、動作ブロックの一部を別のアーキテクチャブロックにマッピングすることができ、これにより、それらの動作ブロックをハードウェアとソフトウェアとの間で移動して実行することができる。設計は、プロセッサ、メモリ及びカスタムハードウェアが組み込まれたシステムオンチップ（system-on-a-chip）の設計であり、あるいはディスクリートのプロセッサ、メモリ及び多機能コンポーネントチップ（chips）から構成されるシステムの設計である。
【００１４】
ＶＣＣでの設計が十分に詳細化のレベルに達し、その性能がシステム仕様に合うようになると、ユーザは、それをソフトウェアとハードウェアの実施としてエクスポートすることができる。そして、ハードウェア設計は、ＨＤＬシミュレーション、フロアープランニング（floor planning）及び論理合成（logic synthesis）に用いられる。そして、ソフトウェアモデルは、ＲＴＯＳ（real time operating system）にリンクする（linking）ために用いられる。
【００１５】
ユーザアプリケーションのソフトウェアエクスポートは、特定のプロセッサ用に選択されたＲＴＯＳを定義（configure）することを含んでいる。また、ソフトウェアエクスポートには、タスクの生成、タスク間及びタスク内通信のための適切なメカニズムの追加、同じタスクにマッピングされる多数の動作の静的（static）スケジューラの合成、ＲＴＯＳスケジューラの定義（configuring）、割込みハンドラの設定、及びカウンタとタイマの設定が含まれる。
【００１６】
１つのＲＴＯＳ上で多くのタスクが実行される状態（高コンテキストのスイッチングオーバヘッドが生じ、許容できない可能性がある状態）を回避するために、ＶＣＣ環境では、ユーザは多数の動作ブロックを同じタスクにマッピングすることができる。この状態において、ＶＣＣは、静的スケジューラ、すなわち動作のラン機能（run function）を単純に順次実行させるスケジューラを合成する。
【００１７】
また、ＶＣＣでは、シミュレーションを使用することにより、設計者は、マッピングを評価することができる。マッピング評価のためにシミュレーションを使用するには、共有アーキテクチャリソースのスケジューリングを仕様化し、モデル化する必要がある。スケジューリングは、設計の実現可能性、品質、信頼性及びコストに重大な影響を与えるので、設計においてスケジューリングを適切に決めることが非常に重要である。
【００１８】
【発明が解決しようとする課題】
したがって、本発明の目的は、スケジューリングの仕様をシステムレベルでどのように決め、また、そのような仕様をシミュレーションとソフトウェアの実行においてどのように利用するかという問題を解決するものである。
【００１９】
【課題を解決するための手段】
本発明の目的は、スケジューリングの仕様を決めるフレームワーク（framework）を提供するものであり、このフレームワークは、
シミュレーションと実装の両方にとって有効であり、
抽象的であり、したがって、システムレベルのシミュレーションに適しており、モデルの記述が直接的であり、
柔軟性があり、設計者が多様なスケジューリング規定（scheduling policｙ）とシステムモデル等の関連した問題を特定し、調査することができ、
階層的であり、複雑なスケジューリング規定を簡単なものから合成することができ、
動作の性能をモデル化する技術に対して直交する（orthogonal）ものである。
【００２０】
本発明は、システムの一部として設計されなければならないスケジューラについての明白な概念（explicit notion）を直接的に導入することにより、問題の仕様の側面（specification aspect）に対処するものである。スケジューラは、アーキテクチャリソースに関するスケジューリング規定を有効に表す。スケジューリング規定は、どのように動作をリソースに割り当て、リソースにアクセスし、リソースを共有するかを定める（govern）。本発明は、スケジューリング規定をモデル化する汎用的なフレームワークを提供し、このフレームワークは、多くの普通の事例をカバーする単純なメカニズムを含んでいる。本発明は、階層を介してスケジューリング規定を構成（composition）することができ、１つのスケジューラは別のスケジューラに割り当てることができる。
【００２１】
問題の関連するシミュレーションの側面は以下の通りである。システムにおける動作ブロックをＶＣＣにおけるアーキテクチャリソースに一旦マッピングすると、ブロックは、入力イベントに反応（react）するために、アーキテクチャリソースを求めて競合する抽象的なプロセスを表す。更に、マッピングされたブロックは、反応を行う有限量の時間を必要とする。
【００２２】
ディスクリートなイベントモデルは処理演算の所望の動作モデルに最も近いので、ＶＣＣにおいて、ディスクリートなイベントシミュレータを使用することが望まれる。従来のディスクリートイベントモデルにおいて、ブロックは、タイムスタンプ（timestamp）が付されたスケジューリングイベントをスケジューリングすることによって、通信を行う。シミュレータは、これらのタイムスタンプによってソートされた（sorted）、システムの全イベントのリストを保持し、最小のタイムスタンプのイベントを（すなわち時刻順に）繰り返して処理する。ブロックのイベントが処理されるときに、そのブロックは反応し、すなわち「点火（fire）」し、新しいイベントをスケジューリングすることが可能になる。ある時刻にスケジューリングされた全てのブロックは、あたかも無限に高速で無数の並列マシン上において、ゼロ「時間」で同時（concurrently）に実行される。通信ネットワークやデジタル回路設計のような多くの問題がある分野において、この抽象化は、大抵の場合、適切である。しかしながら、ＶＣＣ環境に関しては、反応が有限時間を要し、有限の計算リソースを求めて競合するので、このモデルは、マッピングされた設計をシミュレーションするのには適していない。したがって、本発明は、従来のディスクリートイベントモデルを変更して、
従来のディスクリートイベントモデルの結果として発生する起動の明示的モデル、
アーキテクチャリソースのスケジューリングを反映した競合の明示的モデル、
反応に時間がかかることを許容する動作の反応の明示的モデル
を含める。
【００２３】
ここで扱う関連した実行の問題は、どのように仕様を用いて実行の構造を合成するかである。ここに、本発明は、仕様から、特定されたスケジューリング規定を実施する民生機器用のワーキングソフトウェアコード（Ｃ、Ｃ＋＋、アセンブリ言語）を生成する。更に、本発明は、このようなスケジューリング規定を実施するために、商業的に利用可能な実時間オペレーティングシステムのような既存のソフトウェアと組み合わせて定義（configure）することができ、インタフェースをとることができる。
【００２４】
【発明の実施の形態】
直交した（orthogonal）２つのモデル、すなわちスケジューラ（scheduler）の１つと、スケジュール可能（schedulable）の１つは、本発明におけるスケジューリング（scheduling）の全体的なモデリング（modeling）を構成する。これらの２つのモデルは、単純なプロトコルを介して互いにメッセージを送ることにより相互作用する。プロトコル自体は、１対の抽象的インタフェースにより実現され、抽象的インタフェースは、シミュレータにおいて具体的なスケジュール可能なオブジェクト及びスケジューラオブジェクトの中で実現される。
【００２５】
図１は、ＶＣＣにおける設計フローを説明するための図であり、設計フローは、ａ）動作の作成、ｂ）アーキテクチャの取得、ｃ）動作のアーキテクチャへのマッピングからなる。図１の破線より上の領域は、スケジューラのコンポーネントであり、コンポーネントのうちのＣＰＵ、ＡＳＩＣ及びクロック（ＣＬＫ）は、物理的要素であり、残りのＩＲＱ（割込み要求）、ＲＴＯＳ（実時間オペレーティングシステム）及び静的（static）スケジューラは、ソフトウェア要素である。静的スケジューラは、ＶＣＣによって合成され、動作のラン機能（run function）の単純な順次実行を構成する。図１の破線より下の動作は、文字Ａ〜Ｆが付された楕円のブロックで示される。動作Ａ、Ｂ、Ｄは、静的スケジューラによって参照番号１、２、３で示す固有の順番でスケジューリングされるスケジュール可能な動作（schedulables）である。スケジュール可能な動作Ｃは、ＩＲＱによってスケジューリングされ、スケジュール可能な動作Ｅは、動作Ａ、Ｂ、Ｃ、Ｄから入力が供給された後、ＲＴＯＳによってスケジューリングされ、スケジュール可能な動作Ｆは、動作Ａ、Ｄから入力が供給された後、クロックによってスケジューリングされる。
【００２６】
スケジュール可能（schedulable）は、任意のスケジューラがスケジューリングする単位を表す。スケジュール可能は、
起動（activation）、すなわちスケジューリングされることを要求し、
反応（reaction）、すなわちスケジューリングされたときに開始し、（通常は）終了する
という独特の概念（notion）を有する必要がある。このモデルは、図２に示すように、１対のコンカレントな有限状態マシン（finite state machines）として表される。
【００２７】
スケジュール可能は、それ自体では動作という意味を持たないが、このフレームワーク（framework）では動作を表している。したがって、スケジュール可能は、常に単一のスケジューラに割り当てられる動作である。
【００２８】
起動（activation）の具体的な意味（semantic）は、このフレームワークの一部でもなく、スケジュール可能なオブジェクトでもなく、起動は基本的な動作（underlying behavior）から生じる。個々のイベントの動作に対する起動の概念は、シミュレータからイベントを受け取ることと等価である。しかしながら、このことは普遍的（universal）ではない。データフロー（dataflow）という意味の動作は、シミュレータから「十分な」イベントを受け取った後にのみ、起動される。同様に、反応（reaction）の具体的な意味は、スケジュール可能及びこのフレームワークの一部ではない。フレームワークは、動作がその反応を開始（ディスクリートイベントの用語でいえば「点火（fire）」）する時を制御できるように、及び反応が終了する時を通知するように、スケジュール可能に対して単に要求する。反応に要する時間は、動作モデル自体あるいは他のメカニズムによって決定される。本発明のフレームワーク（framework）におけるスケジュール可能は、殆どの場合、ソフトウェアの処理又はタスクを表す動作である。しかしながら、このモデルは、スケジュール可能を他のもの、例えばクロックによって動作するハードウェアプロセスとすることができるほど、汎用的なものである。
【００２９】
図３は、このモデルを、モデルソフトウェアスケジューリングに要求される横取り（preemption）をサポートするように拡張されたモデルとして示す図である。本発明における横取りのサポートは、スケジュール可能によりフレームワークが動作の反応の一時停止（suspend）、再開（resume）及び打切り（abort）を行うことができることを要求する。幾つかの動作に対して、これらの概念が十分に定義されておらず、したがって、全てのスケジュール可能が一時停止、再開及び打切りを実行する必要はない。
【００３０】
上述したように、本発明は、起動のメカニズムと反応のメカニズムを分離している。スケジューラは、それに割り当てられたスケジュール可能についてのこれらのメカニズム間の関係を表す。この関係は、スケジュール可能に対して課せられるスケジューリング規定（scheduling policｙ）である。一般的なフレームワークは、この関係に対して、普通のシミュレーションにおける因果関係（causality）の制約以外には、殆ど制約を設けない。
【００３１】
両極端の具体例を示して説明する。デジタルハードウェア用のクロックをモデリングするスケジューラは、起動の概念を完全に無視し、それに割り当てられた全てのスケジュール可能の反応を一定周波数で開始するように選択することができる。これとは対照的に、実時間オペレーティングシステム（ＲＴＯＳ）をモデリングするスケジューラは、スケジュール可能の起動（タスク（task））を、サービスに対する要求を抽象的に表す起動として追跡する。このようなスケジューラにおいて、起動と反応の関係は、殆どの場合、起動されるスケジュール可能（schedulable）と、これらのスケジュール可能に関する優先順位のセット（set of priorities）とを含む複雑な機能である。
【００３２】
スケジュールに割り当てられたスケジュール可能が横取り（preemption）をサポートするときは、スケジューラも起動と横取りとの関係を表す。サイクロスタティック（cyclo-static）、静的優先度、動的優先度、ラウンドロビン（round robin）等の代表的なソフトウェアスケジューリング規定を含む殆どのスケジューリング規定を、このフレームワークの中で実現することができる。なお、従来のディスクリートのイベントモデルさえも、スケジュール可能が活性化されると直ぐに反応することを割り当てられたスケジュール可能に強制する普通のスケジューラによって、モデリングすることができる。任意のオブジェクトは、上述の制約の下に、スケジュール可能のインタフェースを実現することができる。階層を介したスケジューラの構成（composition）は、スケジュール可能のインタフェースをも実現するスケジューラを組み立てることにより、容易に行われる。このようなスケジューラは、親スケジューラ（parent scheduler）に割り当てることができる。
【００３３】
スケジュール可能のスケジューラは、起動と反応の意味を定義しなければならない。有益な具体例において、本願発明者は、スケジューラの起動を、スケジューラに割り当てられたスケジュール可能の起動の関数として解析した。その結果、起動は、階層を上方向に伝わる（propagating up）ものとして見ることができ、これは、正にプロトコルで起きていることである。反応も、階層を下方向に伝わることを除いて、同じである。
【００３４】
プロトコルは、モデラー（modeler）が基本的なシミュレータの詳細に関わることなく、スケジューリング規定の広範囲のモデルを構築できるように、設計され、実行されてきた。本発明では、スケジューラ（scheduler）は、それに割り当てられたスケジュール可能を検出するように構成され、スケジュール可能は、それらが割り当てられたスケジューラを検出するように構成される。これは、プロトコルの初期化段階（initialization phase）である。
【００３５】
図４は、プロトコルにおける代表的な相互作用を（interaction）の具体例を示す図である。このシナリオにおいて、イベントはシミュレータによってスケジュール可能に送られる。これによって、スケジュール可能の基本的な動作が反応することはなく、むしろ、スケジュール可能の基本的な動作が反応することを望むかを決定し、これによって、スケジュール可能は、それが割り当てられたスケジューラに起動通知を送る。暫くした後に、スケジューラは、スケジュール可能にそれの動作の反応を開始するように指示するメッセージを送り、スケジュール可能がメッセージを受信したときに、動作が反応する。その後、反応が終了する前に、スケジューラは、実行中の反応を横取り（preempt）する必要があると決定し、スケジュール可能に一時停止メッセージを送る。この一時停止メッセージを受けて、スケジュール可能は、それの基本的な動作の実行を一時的に停止する（halt）。この結果、スケジューラは、このブロックをスケジューリングし直し、一時停止している反応を再開するための再開メッセージを送り、これにより、スケジュール可能は、動作の実行を再開する。最後に、反応が終了すると、スケジュール可能は、それが割り当てられたスケジューラに終了通知を送り返す。
【００３６】
【表１】

【００３７】
表１は、プロトコルに関するメッセージを示す。スケジュール可能からのメッセージは有効に送信側の識別を含み、スケジューラは、どのスケジュール可能が起動し、あるいは終了したかが分かることができる。
【００３８】
図５及び図６に示す１対のＣ＋＋クラスは、スケジュール可能及びスケジュールのオブジェクトの抽象的なインタフェースを定義することによってこのプロトコルを実行する。FxSchedulableInterfaceクラスは、直接実行されることは殆どない。これは、特定のモデリングスタイルに対して設計者により単に使用される遅延メタモデルと呼ばれるクラスによって、通常取り扱われる。FxSchedulableInterfaceクラスは、特定のスケジューリング規定のモデルを構築するために、モデラーによって直接又は間接的に使用される。
【００３９】
フレームワークは、FxBasicSchedulerと呼ばれる「基本的な」スケジューラクラスを有しており、このスケジューラクラスは、スケジューリングモデルを構築するために殆どの場合必要とされる動作及びブックキーピング（bookkeeping）を有している。モデラーは、多くの場合、このクラスをサブクラスに分け、詳細化して特定のモデルを構築することができ、この場合、モデル構築の作業はかなり簡単となる。しかしながら、基本的なクラスでは不十分な場合には、いつでもFxSchedulableInterfaceクラス全体を実行することができるが、負担及び複雑さが増大する。
【００４０】
与えられた状況におけるFxBasicSchedulerの応用性（applicability）は、クラスに組み込まれた同時性の前提条件（concurrence assumption）に大きく依存する。この前提条件は、任意の時刻においては、割り当てられたスケジュール可能（schedulables）の中のただ１つのみが反応状態にあるということである。明らかに、FxBasicSchedulerは、上述したハードウェアクロックスケジューラの具体例に対しては適切ではないが、殆どのソフトウェアスケジューリングモデルに対しては適切である。
【００４１】
FxBasicSchedulerの内部で使用されるモデルを図７に示す。ユーザは、モデルを詳細化するために、２つの比較的抽象的な（純粋に仮想的な）機能についての実行を与えるように要求される。このような第１の抽象的な機能は、「次？（next?）」の機能である。この機能は、モデルが「次の」状態を通るときは常に呼び出される。これは、スケジューラが休止（idle）中に起動通知を受けたとき、あるいは自然又は横取りによるかに拘わらず、反応が終了したときのいずれかに生じる。この機能は、ハンドル（handle）を次に実行すべきスケジュール可能に、あるいはそれが存在しないときにはニル（nil）に返すように要求される。第２の抽象的な機能は、「横取り？（preempt?）」機能である。この機能は、スケジュール可能の反応中に起動が発生したときは常に呼び出される。この機能は、横取りが起こるかを判定し、起こるときは、一時停止又は打切りのいずれかの方法を使用すべきか決定するように要求される。
【００４２】
FxBasicSchedulerを用いたスケジューリングの性能のモデリングは、開始／再開、終了、及び一時停止／打切りの状態間の遷移に要する時間をモデラーが指定できるようにすることによって、容易になる。これらの動作に一定時間を割り当てる簡単なメカニズムが存在し、代わりのメカニズムとして、必要に応じ、スケジューラ又はシステムの状態に依存した機能のセットを提供するメカニズムが存在する。
【００４３】
このフレームワークにおける仕様を用いて、実行に必要なソフトウェアの一部を自動的に生成することができる。
【００４４】
図１において、３つの動作（Ａ、Ｂ、Ｄ）を静的スケジューラに割り当てている。これは、実行のための関連した動作を含むサイクロスタティックなスケジューラを合成する指示であると解釈される。マッピング割当における優先順位（priority）は、スケジュールの順番を与える。この静的スケジューラと動作（Ｅ）は、ＲＴＯＳに割り当てられており、このことは、動作が、サイクロスタティックスケジューラと共に、ＲＴＯＳによって生成されたタスクとなることを表している。このようにして、２つのタスクを合成する。ＲＴＯＳに加え、割込み要求（ＩＲＱ）がプロセッサに割り当てられる。このことは、ＩＲＱについての動作Ｃを含む割込みハンドラを合成して、割り当てることを示している。得られた実行用の擬似コードを図８に示す。
【００４５】
本発明に基づくスケジューラは、以下の規定、すなわちサイクロスタティック、非横取りの静的優先度（non-preemptive static priority）及び横取りの静的優先（preemptive static priority）に対して構成されている。このフレームワークを使用してソフトウェアスケジューリング規定の表現が容易になることを説明するために、横取りの静的優先スケジューラを例にとると、これは僅かに１２行の実コードしか必要とせず、Ｃ＋＋カーネルでカウントすると、全１００行のオーダである。狭い範囲のサイクロスタティックスケジューラを生成するもの、ＲＴＯＳをターゲットとするものを含む幾つかのワーキングソフトウェア合成プロトタイプを構築した。
【００４６】
以上、本発明の実施の形態について説明したが、他の具体的形態も想到され、本発明の範囲は、特許請求の範囲及びその均等物によってのみ限定されると解される。
【図面の簡単な説明】
【図１】 ＶＣＣにおける設計フローを構成する動作、アーキテクチャ及びマッピングのタスクの仕様を説明するためのブロック図である、
【図２】 本発明の具体例に基づいた簡単な「スケジュール可能」の状態図である。
【図３】 拡張した「スケジュール可能」の状態図である。
【図４】 代表的なインタラクションを示すプロトコルに関する非公式のＭＳＣの概念を説明するための図である。
【図５】 基本的なスケジューラ及びスケジュール可能のインタフェースに関するＣ＋＋クラスを説明するための図である。
【図６】 基本的なスケジューラ及びスケジュール可能のインタフェースに関するＣ＋＋クラスを説明するための図である。
【図７】 ２つの抽象的な機能、すなわち「次？」と「横取り？」を説明する、FxBasicSchedulerと呼ばれる基本的なスケジューラクラスの状態図である。
【図８】 図１の仕様に関する擬似コードの具体例である。

Claims (28)

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. 更に、
    既存の商業的に利用可能なソフトウェアとインタフェースすることにより、上記スケジューリング規定を実施するステップを有する請求項２５記載のスケジューリング生成方法。

Images