(57)【要約】  リアルタイムオペレーティングシステム（１１０，１７０）でマルチプルタスクを制御する方法（６０）は、プライオリティを２以上のタスク（１１４，１１５；１７４，１７５）に割り当てる。第１のタスク（１１４；１７４）は、上位タスクにアサインされる。第２のタスク（１１５；１７５）は、下位タスクにアサインされる。各タスクは、バケット割当ての情報が提供される。保証バケットマージンは、上位保証バケットに従って上位タスクに割り当てられる。下位保証バケットは、下位タスクに割り当てられる。実行中のあるポイントにおいて、高プライオリティすなわち上位タスク（１１４；１７４）は、上位タスクがもはや保証バケットマージンを必要としないことを決定することができ、この場合、条件保証バケットマージンは、下位タスク（１１５；１７５）に割り当てられる。
2007512592.tif 000002
【特許請求の範囲】
【請求項１】
マルチプルタスクを制御する方法であって、
第１のタスクを上位タスクに割り当て、
第２のタスクを下位タスクに割り当て、
上位保証バケットに従って保証バケットマージンを上位タスクに割り当てるとともに、この割当ての情報を前記上位タスクに明示的に提供し、
下位保証バケットを前記下位タスクに割り当てるとともに、この割当ての情報を前記下位タスクに明示的に提供し、
前記保証バケットマージンをもはや必要としないメッセージを前記上位タスクに送信し、
条件付保証バケットマージンを前記下位タスクに割り当てるとともに、この割当ての情報を前記下位タスクに明示的に提供することを特徴とする方法。
【請求項２】
前記上位タスクがもはや前記保証バケットマージンを必要としないことを決定することを特徴とする請求項１記載の方法。
【請求項３】
第１のタスクを起動する方法であって、前記第１のタスクが、第２のタスクより高いレベルのプライオリティが割り当てられ、
前記第１のタスクが他のバケットマージンを必要とするか否か決定し、
前記他のバケットマージンがもはや必要とされない又は前記他のバケットマージンが必要とされているというメッセージを送信することを特徴とする方法。
【請求項４】
前記第１のタスクがもはや他のバケットマージンを必要としないというメッセージを受信すると、条件付保証バケットマージンを自動的に前記第２のタスクに割り当てることを特徴とする請求項３記載の方法。
【請求項５】
マルチタスクプロセスの２以上のタスクを制御する方法であって、
上位保証バケット及び保証バケットマージンについての情報を、上位タスクである第１のタスクに明示的に提供し、
下位保証パケット及び条件付保証パケットマージンについての情報を、下位タスクである第２のタスクに明示的に提供し、
前記上位保証バケット及び前記保証バケットマージンを、最初のあり得るときに前記第１のタスクに提供し、
前記下位保証パケットを、最初のあり得るときに前記第２のタスクに提供し、
前記第１のタスクが、前記第１のタスクが前記上位保証バケットのみを用いてジョブを行うことができる実行中のあるポイントで決定すると、前記第１のタスクが保証バケットマージンを必要としないという情報をスケジューラに明示的に提供することを特徴とする方法。
【請求項６】
前記保証バケットマージンの前記第１のタスクへの提供を、最初のあり得るときに停止することを特徴とする請求項５記載の方法。
【請求項７】
前記条件付保証バケットマージンの前記第２のタスクへの提供を、最初のあり得るときに開始することを特徴とする請求項６記載の方法。
【請求項８】
前記条件付保証バケットマージンの提供についての情報を前記第２のタスクに提供することを特徴とする請求項７記載の方法。
【請求項９】
前記第１のタスクが前記保証バケットマージンを必要とすることを実行中のあるポイントで前記第１のタスクによって決定することを特徴とする請求項７記載の方法。
【請求項１０】
前記第１のタスクがその保証バケットマージンを必要とする情報を前記スケジューラに明示的に提供することを特徴とする請求項９記載の方法。
【請求項１１】
前記条件付バケットマージンを取り除くという情報を前記第２のタスクに提供することを特徴とする請求項１０記載の方法。
【請求項１２】
前記条件付保証バケットマージンの前記第２のタスクへの提供を、最初のあり得るときに停止することを特徴とする請求項１１記載の方法。
【請求項１３】
前記保証バケットマージンの前記第１のタスクへの提供を、最初のあり得るときに開始することを特徴とする請求項１１記載の方法。
【請求項１４】
第１のプライオリティレベルを有する第１のタスクと、
前記第１のプライオリティレベルより低い第２のプライオリティレベルを有する第２のタスクと、
リソースのバケットの割当てを行うアロケーションメカニズムとを具え、前記アロケーションメカニズムが、上位保証バケット及び保証バケットマージンについての情報を前記第１のタスクに明示的に提供するとともに、下位保証バケット及び条件付保証バケットマージンについての情報を前記第２のタスクに明示的に提供し、
割り当てられて量を前記第１及び第２のタスクに提供するスケジューラを更に具え、前記スケジューラが、前記上位保証バケット及び前記保証バケットマージンを最初のあり得るときに前記第１のタスクに提供するとともに、前記下位保証バケットを最初のあり得るときに前記第２のタスクに提供し、前記第１のタスクが、前記第１のタスクが前記上位保証バケットのみを適切に実行できることを実行中のあるポイントで決定すると、前記第１のタスクが、前記第１のタスクがその保証バケットマージンを必要としないことを前記スケジューラに明示的に提供することを特徴とする装置。
【請求項１５】
前記スケジューラが、前記保証バケットマージンの前記第１のタスクへの提供を最初のあり得るときに停止するとともに、前記条件付保証バケットマージンの前記第２のタスクへの提供を最初のあり得るときに開始することを特徴とする請求項１４記載の装置。
【請求項１６】
前記スケジューラが、前記条件付保証バケットマージンを提供する情報を前記第２のタスクに提供することを特徴とする請求項１５記載の装置。
【請求項１７】
前記第１のタスクが、前記第１のタスクが前記保証バケットマージンを必要とすることを実行中のあるポイントで決定し、前記第１のタスクが、前記第１のタスクがその保証バケットマージンを必要とする情報を前記スケジューラに提供することを特徴とする請求項１４記載の装置。
【請求項１８】
前記スケジューラが、前記条件付保証バケットが取り除かれる情報を前記第２のタスクに提供することを特徴とする請求項１７記載の装置。
【請求項１９】
前記スケジューラが、前記条件付保証バケットマージンの前記第２のタスクへの提供を最初のあり得るときに停止することを特徴とする請求項１８記載の装置。
【請求項２０】
前記スケジューラが、前記保証バケットマージンの前記第１のタスクへの提供を最初のあり得るときに開始することを特徴とする請求項１９記載の装置。
【請求項２１】
第１のプライオリティレベルを有する第１のタスクと、
前記第１のプライオリティレベルより低い第２のプライオリティレベルを有する第２のタスクと、
リソースのバケットの割当てを行うアロケーションメカニズムとを具え、前記第１のタスクが、上位保証バケット及び保証バケットマージンについての情報を明示的に提供し、前記第２のタスクが、下位保証バケット及び条件付保証バケットマージンについての情報を明示的に提供し、
前記条件付保証バケットマージンの利用可能性をモニタする条件付バケットモニタを更に具え、前記条件付バケットモニタが、上位タスクがもはや前記保証バケットマージンを必要としないメッセージを受信し、前記上位タスクが前記条件付バケットマージンを必要とするメッセージを受信し、前記保証バケットマージン、前記条件付保証バケットマージン、前記上位保証バケット及び前記下位保証バケットのバケット割当てを前記アロケーションメカニズムから受信し、かつ、前記バケット割当てに関するリザベーションコマンドを送信し、
割り当てられた量を前記リザベーションコマンドに基づいて前記第１及び第２のタスクに提供するスケジューラを更に具え、前記スケジューラが、前記上位保証バケット及び前記保証バケットマージンを最初のあり得るときに前記第２のタスクに提供し、前記第１のタスクが、前記第１のタスクが前記上位保証バケットのみを用いて適切に実行することができることを実行中のあるポイントで決定し、前記条件付バケットモニタが、前記第１のタスクに対する前記上位保証バケットのみを含むとともに前記第２のタスクに対する前記下位保証バケットに従った前記条件付保証バケットマージンを含むリザベーションコマンドを、前記スケジューラに送信することを特徴とする装置。
【請求項２２】
前記第１のタスクが、前記保証バケットマージンを必要とすることを決定するとともに、これを前記条件付バケットモニタに送信し、前記第１のタスクに対する前記保証バケットマージン及び前記上位保証バケット並びに前記第２のタスクに対する前記下位保証バケットを含むリザベーションコマンドを前記スケジューラに送信することを特徴とする請求項２１記載の装置。
【請求項２３】
前記条件付バケットモニタが、前記条件付保証バケットマージンの提供の情報を前記第２のタスクに提供することを特徴とする請求項２１記載の装置。
【請求項２４】
前記条件付バケットモニタが、前記条件付保証バケットマージンが取り除かれる情報を前記第２のタスクに提供することを特徴とする請求項２２記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、オペレーティングシステムのリソースを管理する方法及び装置に関し、更に詳しくは、リアルタイムで機能するオペレーティングシステムのリソースを管理する方法及び装置に関する。
【背景技術】
【０００２】
デジタルテレビジョンセットや、デジタル的に向上したアナログテレビジョンセットや、セットトップボックス（ＳＴＢ）のような大容量家電システム(High volume electronics (HVE) consumer system)は、典型的には、コスト的に有効で強固でありながらオープンかつ柔軟性になることが要求されるプロダクトファミリーの一部である。そのようなシステムは、ハードなリアルタイムドメインの特徴を持つ特性を有する。
【０００３】
オープンであること及び柔軟性があることが、典型的にはソフトウェアに基づくシステムの典型的な特徴であるので、ＨＥＶシステムにおける媒体処理に重要な部分は、制御及びサービスを現存するソフトウェアで実現するのに加えてソフトウェアで実現され始めると予測される。構成技術(component technology)は、オープンで柔軟性のあるシステムの基本的な技術であると考えられる。ＨＶＥシステムがプロダクトファミリーの典型的な部分であるので、構成技術は、現存するソフトウェアを集約したＨＥＶシステムに対して既に非常に重要である。構成技術を用いたそのようなシステムの開発は、開発に要する時間及び開発コストを大幅に減少し、それはとりわけ有利である。
【０００４】
さらに、家電は、リソースが非常に制約される。その結果、利用できるリソースを、強固さのようなＨＶＥシステムの典型的な品質を維持するとともに、例えば、高品質デジタルオーディオ及びビデオ処理によって課される厳格なタイミング要求に適合しながら、コスト的に非常に有利に用いる必要がある。強固さに関連して、例えば、テレビジョンセットにメッセージ「システムを再起動してください。」をストールすることを誰も予測しない。リソースバケット（又はリザベーション）は、アプリケーションの時間的な分離を提供する証明された概念である。
【０００５】
現在の作業は、固定プライオリティプリミティブスケジューリング(fixed-priority preemptive scheduling: FPPS)を提供する標準汎用品(commercial-off-the-shelf: COTS)リアルタイムオペレーティングシステム（ＲＴＯＳ）のトップでバケットを実現するシステムとともに存在する。
【０００６】
米国特許第５，８３８，９６８号は、リアルタイムオペレーティングシステムのタスク間でダイナミックなリソース管理を行うシステム及び方法を開示する。そのシステム及び方法は、システム特有のパフォーマンスモデルに従って、任意のセットのシステムリソースを管理し、システムタスク間でリソース割当てを全体的に最適化する。
【０００７】
米国特許公開２００２／０１３８６７９号は、優先度承継システム及び方法を開示しており、その方法は、タスクに関連した優先度承継変数をテストし、優先度承継変数のテストが、優先度承継に含まれるリソースをタスクが保持しないことを表すとき、タスクの現在のプライオリティを低下する。
【０００８】
米国特許公開２００２／０１３３５３０号は、高プライオリティタスクによって低プライオリティタスクからスチールするリソースを含むリソース制御方法を開示する。一部のケースにおいて、バケット割当ては理想で貴でなく、これによって、柔軟性のない動作又はリソースの不適切な使用となり得る。
【発明の開示】
【０００９】
したがって、本発明は、リアルタイムオペレーティングシステム及び他の同様なアプリケーションにおけるリザベーションに基づくスケジューリングでのリソースの使用を向上する方法及び装置の開発の問題に向けられたものである。
【００１０】
本発明は、マルチタスクプライオリティ化、リソースバケット化、リソース消費予測及び条件付バケット割当てを組み合わせるオペレーションシステムを制御する方法を設けることによってこれら及び他の問題を解決する。この組合せにおいて、バケットマージンは、バケットが十分でない場合に用いるために、高プライオリティタスクに割り当てられ、条件付バケットマージンが、設計された低プライオリティタスクに対して、バケットとともに条件付で割り当てられる。高プライオリティタスクは、バケットの使用をモニタし、高プライオリティタスクが、バケットマージンを不要と決定する場合、低プライオリティタスクは、条件付バケットマージンの使用が許容される。
【００１１】
本発明の一態様によれば、高プライオリティタスク（例えば、上位タスク）が、バケットの使用を、マージンのないバケットに制限し、その後、必要なときにマージンを使用することを明示的に決定する。
【００１２】
本発明の他の態様によれば、高プライオリティタスクは、決定についての情報をアロケーションメカニズムに提供し、低プライオリティタスク（例えば、下位タスク）も直接又は間接に同様な情報が提供される。これによって、アロケーションメカニズム又はスケジューラは、少なくとも高プライオリティタスクがバケットマージンを必要とすることを次に決定するまで、この未使用バケットマージンを低プライオリティタスクに提供する。本発明の他の態様は、添付図面を参照した詳細な説明から当業者に明らかである。
【発明を実施するための最良の形態】
【００１３】
「例」の任意の参照番号は、本発明の少なくとも一例に含まれる例に関連して説明した特定の形態、構造又は特徴を意味する。明細書の種々の形態の「例」の文脈の表示は、必ずしも同一例を言及する全てではない。
【００１４】
プライオリティの割当て、ＭＩＴ及びＬＩＴの表示、バケットの決定並びに他の関連の情報に関する詳細を、図面を含む全体でここに繰り返されるように、参照によってここに組み込んだ米国特許出願番号１０／１６９，３４６号及び１０／２９４，５３０号で見つけることができる。これらの特許出願において、プライオリティの表示を、オペレーションシステムのプライオリティの意味に用いており、相対的な重要性の意味に用いていない。用いられるスケジューリングアルゴリズムにおいて、先のプライオリティは、一般的にバケット周期に従って割り当てられる。時には、ＯＳプライオリティ及び相対的な重要性をひとまとめにするのが、特に全てのタスクが同一バケット周期を有する場合に便利である。しかしながら、二つのプライオリティタイプを一まとめにすることを、常に適用できるわけではない。さらに、ＯＳプライオリティを、例えば、最近の期限の最初のスケジューリングを用いるＯＳにおいてダイナミックにすることができる。その場合、二つのプライオリティのタイプを一まとめにすることができない。したがって、以下の説明では、ＭＩＴによって用いられない場合に保証バケットマージンを利用するためにＭＩＴ，ＬＩＴ、アロケーションメカニズム及び透け儒―タのインタラクションに関連する態様に焦点を当てる。図１〜５は、ここで利用できる本発明で説明する種々のエレメントを示す。
【００１５】
図１は、リアルタイムオペレーティングシステムで２タスクを制御するタスクマネージャプロセス１０の一例を示す。ここで使用しているように、タスクマネージャ及びアプリケーションマネージャ（図５の記載参照）を同時に用いることができる。実際のタスクマネージャはサイクルを有する。これは、開始直後に条件エレメント（例えば、継続？−エレメント１１）が存在することを意味する。ｙｅｓの場合、プロセス１０は、エレメント１２〜１６を実行し、条件エレメント１１に戻る（while loop）。ｎｏの場合、プロセス１０は停止する。プロセス１０によれば、第１のタスクは、上位タスク(More Important Task)１２にアサインされ、第２のタスクは、下位タスク(Less Important Task)１３にアサインされる。２以上の上位−下位タスクペアが任意の時点で存在するが、ここでの説明では単一ペアを言及する。ここで説明することを、複数ペアを通じて適用することができる。プロセスのこの時点において、タスクマネージャ（又はその等価物）は、（これら２タスクに対して）インアクティブ１４となる。その後、第１のタスクは、上位タスク１５からデアサインされ、第２のタスクは、下位タスク１６から割当てデアサインされ、プロセス１０を終了する。
【００１６】
同一の２タスクに対する（例えば、図１のエレメント１４中でアクティブであるときの）アロケーションメカニズムプロセス２０の一例を、図２に示す。アロケーションメカニズムは、上位保証バゲット(More Important Guaranteed Budget :MIGB)２１に従って保証バゲットマージン（ＧＢＭ）をＭＩＴに割り当てる。アロケーションメカニズムは、下位保証バゲット(Less Important Guaranteed Budget :LIGB)をＬＩＴ２２に割り当て、条件によっては条件保証バゲットマージン(Conditionally Guaranteed Budget Margin: CGBM)をＬＩＴ２１に割り当てる。その後、アロケーションメカニズムは、行われた割当て２３に従ってリザベーションコマンドを送信する。その後、所定のイベント２４によってトリガがかけられるまでアロケーションメカニズムは何も行わない。イベントが決定エレメント２５において継続を表す場合、バゲットが十分でない決定が２７で行われ、アロケーションメカニズム２０はエレメント２１に戻り、それ以外の場合には、ＭＩＴ及びＬＩＴの役割(role)は２７で完了し、プロセスが終了する。
【００１７】
図２（並びに後に説明する図７及び１２）において、バゲットが動的に調整可能であると仮定する。ここで説明する方法は、バゲットが動的に調整可能でないときにも実施される。この場合、図２（並びに後に説明する図７及び１２）は皿簡単になる。その理由は、割当てが１回しか行われないからである。この場合、エレメント２４，２５，２６及び２７（並びに図７及び１２の対応するもの）は必要とされない。
【００１８】
本実施の形態において、割り当てられたバゲットは、周期的に補充され、周期及び開始時間は、タスクによって決定される。周期的なバゲットのみアロケーションメカニズムによって決定される。そのような周期的なバゲットの使用は、以下の通りである。
【００１９】
タスクＹが、周期Ｔ及び開始時間ｔ０で周期的なバゲットＢを受け取る場合、瞬時ｔ０＋ｎ・Ｔ（ｎ≧０）ごとに、Ｙのバケットに単位時間Ｂが補充される。その周期中にこれら単位時間を消費できる場合のみ、Ｙは、ｔ０＋ｎ・Ｔとｔ０＋（ｎ＋１）・Ｔの間で単位時間Ｂを受信するように保証される。所定の周期で時間単位を消費するのに十分な作業を有しない場合、使用されない時間がｔ０＋ｎ・Ｔで消失される。
【００２０】
周期的なバケットは、常に分数バケット（Ｆ:fractional budget）に関連し、この場合、Ｆ＝Ｂ／Ｔであり、全ての割り当てられた分数バケットの和を１未満とする必要がある。本実施の形態は、周期的なバケットのみに適用されない。原理的には、本実施の形態を、全ての分数バケットに適用することができる。本実施の形態は、プロセッサ、ＣＰＵ又はオペレーティングシステムのみに適用されるものではなく、本実施の形態を他の時間リソース(temporal resource)（例えば、トランスポーテーションバンド幅(transportation bandwidth)）に適用することもできる。
【００２１】
スケジューラプロセス３０の例を図３に示す。スケジューラプロセスは、アロケーションマネージャのサイクルと非常に類似するサイクルを有し、すなわち、スケジューラプロセスは、条件エレメント（継続？）を評価するイベント３６を有する。ｙｅｓの場合、アロケーションマネージャからの新たなコマンドが存在し、スケジューラサイクルはエレメント３１に戻る。ｎｏの場合、スケジューラは停止する。スケジューラがループに戻ると、スケジューリングアルゴリズム３０を実行し続け、これは、（スケジュールするタスクがまだ存在しないときでも）「スケジューリングメカニズムの開始」を述べるエレメント３７により図３に示される。
【００２２】
スケジューリングプロセスは、ＭＩＴ及びＬＩＴ３１に対してアロケーションメカニズムからリザベーションコマンドを受け入れることによって開始する。スケジューラは、ＭＩＧＢ及びＧＢＭをＭＩＴに付与し、これによって、スケジューリングメカニズムは、ＭＩＧＢ及びＧＢＭの提供を、ＭＩＴ３２に対して典型的な周期で周期的に開始できるようになる。スケジューラは、ＬＩＧＢをＬＩＴに付与し、これによって、スケジューリングメカニズムは、ＬＩＧＢの提供を、ＬＩＴ３３に対して典型的な周期で周期的に開始できるようになる。スケジューラは、条件に応じてＣＧＢをＬＩＴに付与し、これによって、スケジューリングメカニズムは、ＣＧＢの提供を、ＬＩＴ３４に対して典型的な周期で周期的に開始できるようになる。スケジューリングメカニズムは、スケジューリングアルゴリズム３５の現在のセッティングに従って実行を継続する。このようにして、スケジューリングメカニズムは、付与されたバケットをタスクに提供する。外部イベントが発生する（３６）場合、スケジューラは条件３７に到達する。スケジューラプロセス３０を継続する場合、スケジューラプロセスはエレメント３１に戻り、そうでない場合、スケジューラの動作を停止し、スケジューラを終了する。
【００２３】
「ＸのＹへの付与」は、「Ｙを受信するようＸが保証されるようなスケジューリングパラメータの設定」を意味する。それに対して、「条件に応じた付与」は、例えば、ＬＩＴが未使用バケットをＭＩＴから「受け継ぐ」ことを意味する。条件提示は内在(implicit)する。ＭＩＴが、十分なＧＢＭを未使用の状態にする場合、ＬＩＴは十分なＣＧＢＭを取得する。
【００２４】
図１〜３の例に基づく上位プロセスインタラクションの例を、図４に示す。ＭＩＴプロセスは、ＭＩＧＢ及びＧＢＭ４１を用いて開始する。あるポイントにおいて、ＭＩＴはもはやＧＢＭ４２を要求しなくてもよい。したがって、ＭＩＴは、ＭＩＧＢ４３のみを用いて開始する。決定ポイント４４において、ＭＩＴは継続し又は継続しなくなる。ＭＩＴが継続する場合、あるポイントでＭＩＴはＧＢＭ４５を要求することができる。したがって、ＭＩＴは、ＭＩＧＢ及びＧＢＭ４６を用いて開始する。決定ポイント４７において、ＭＩＴプロセスは終了し又はエレメント４３で継続する。
【００２５】
図１〜３の例に基づく下位プロセスインタラクションの例を、図１９に示す。ＬＩＴプロセスは、ＬＩＧＢ４０１を用いて開始する。あるポイントにおいて、ＣＧＢＭの利用を開始する（４０２）。したがって、ＬＩＴは、ＬＩＧＢ及びＣＧＢＭを用いて開始する（４０３）。決定ポイント４０４において、ＬＩＴは継続し又は継続しなくなる。ＬＩＴが継続する場合、あるポイントにおいて、ＣＧＢＭはもはや利用できなくなる（４０５）。したがって、ＬＩＴは、ＬＩＧＢのみを用いて開始する（４０６）。決定ポイント４０７において、ＬＩＴプロセスは終了し又はエレメント４０２で継続する。
【００２６】
図１〜４及び１９のインタラクションの例５０を、図５に示す。アプリケーションマネージャ５１は、ＭＩＴの役割を所定のタスクにアサインし及びデアサインする（図１のエレメント１１〜１４）。アプリケーションマネージら５１は、ＬＩＴの役割を他の所定のタスクにアサインし及びデアサインする（エレメント１２〜１５）。アプリケーションマネージャ５１はインアクティブとなるとともに、アロケーションメカニズム５２はアクティブとなる（エレメント１３）。ＭＩＴ及びＬＩＴの役割が完了する（図２のエレメント２６）と、アプリケーションマネージャ５１は再びアクティブとなるとともに、アロケーションメカニズム５２がインアクティブとなる。アロケーションメカニズム５２は、ＭＩＧＢ及びＧＢＭをＭＩＴに割り当て（図２のエレメント２１）、ＬＩＧＢ及びＣＧＢＭをＬＩＴに割り当てる（図２のエレメント２２）。アロケーションメカニズム５２は、リザベーションをスケジューラ５５に送出し（図２のエレメント２３）、スケジューラ５５は、図３のエレメント３１を起動し、スケジューラ５５は、ＬＩＴ及びＭＩＴに対するリザベーションコマンドをアロケーションメカニズムから受け入れ（エレメント３１）、ＭＩＧＢ及びＧＢＭをＭＩＴ５３に付与し、スケジューリングメカニズムは、ＭＩＧＢ及びＧＢＭの提供をＭＩＴに対して周期的に開始する（エレメント３２）。スケジューラ５５は、ＬＩＧＢをＬＩＴ５４に付与し、ＬＩＧＢの提供をＬＩＴに対して周期的に開始する（エレメント３３）。スケジューラ５５は、条件に応じてＣＧＢＭをＬＩＴ５４に付与し、ＣＧＢＭの提供をＬＩＴ５４に対して条件に応じて開始する（エレメント３４）。スケジューラ５５は、スケジューリングアルゴリズムに従って実行する（エレメント３５）。この時間中、あるポイントでのＭＩＴはＧＢＭ４２を要求せず、ＣＧＢＭがＬＩＴ４００に対して利用できるようになる。他のあるポイントにおいて、ＭＩＴは再びＧＢＭを要求し（４５）、ＣＧＢＭはもはやＬＩＴ４０５を利用できない。このような４２−４０２から４５−４０５のシーケンスを１回以上繰り返すことができる。実際的な零繰り返しの場合、条件エレメント４７をエレメント４６と４２との間ではなくエレメント４１と４２との間にするよう図４及び１９を変更する必要があり、これによってuntil loopの代わりにwhile loopとなる。
【００２７】
上位タスク（図４）は、２タイプの動作を有することができる。同期動作として知られている第１タイプの動作は、タスクがバケット消費に同期をとって動作するときに生じる（すなわち、バケットがバケット周期内で補充され及び作業を完了するときにタスクが開始する。）。
【００２８】
同期タスクに対するタイムライン２００の例を、図２０に示す。ＭＩＧＢ及びＧＢＭの補充を伴う第１のバケット周期の開始時（２０１）に、対応するタスクの実行（例えば、第１のビデオフレームの処理）を開始する（２０２）。所定の時間後、タスクの実行を完了する（２０３）。ＭＩＧＢは完全に使い切られず、ＧＢＭは完全に使用されない。所定の時間後、第１の周期が終了する（２０４）。ＭＩＧＢ及びＧＢＭの補充を伴う第２のバケット周期２０５の開始時に、対応するタスクの実行（例えば、第１のビデオフレームの処理）を開始する（２０６）。所定の時間後、ＭＩＧＢが完全に使い切られる（２０７）。所定の時間後、タスクの実行を完了する（２０８）。ＧＢＭは完全に使い切られない。所定の時間後、第２のバケット周期は終了する（２０９）。
【００２９】
タイムラインは、バケット周期の二つの例を示す。２０１〜２０４までのの第１のバケット周期において、タスクの実行はＭＩＧＢ内で完了する。２０５〜２０９までの第２のバケット周期において、タスクの実行は、ＧＢＭの一部も要求する。
【００３０】
非同期動作として知られている第２のタイプの動作は、タスクがバケットに同期をとって動作しないときに生じる。非同期動作において、タスクは、バケット消費前後に作業することができる。非同期動作はしばしば負荷を取り除くのに用いられる。非同期タスクに対するタイムライン２１０の例を、図２１に示す。ＭＩＧＢ及びＧＢＭの補充を伴う第１のバケット周期の開始時（２１１）に、第１のタスクの実行（例えば、第１のビデオフレームの処理）を開始する（２１２）。所定の時間後、ＭＩＧＢが完全に使い切られる（２１３）。所定の時間後、第１のタスクの実行は時間通り完了し、それに対して、ＧＢＭは完全に使い切られない（２１４）。その直後に、タスクは第２の実行を開始する（２１５）。所定の時間後、ＧＢＭも使い切られ（２１６）、第２のタスクの実行が中断される（２１７）。所定の時間後、周期が終了する（２１８）。この第１のバケット周期中、１タスクの完了が生じる。換言すれば、タスクが１作業単位を完了する。
【００３１】
ＭＩＧＢ及びＧＢＭの補充を伴う第２のバケット周期の開始時（２２１）に、以前の周期で中断された第２のタスクの実行が再開される（２２２）。所定の時間後、ＭＩＧＢが完全に使い切られる（２２３）。所定の時間後、ＧＢＭも使い切られ（２２４）、第２のタスクの実行も中断される（２２５）。所定の時間後、周期が終了する（２２６）。この第２の周期中、タスクの完了が生じない。第２のタスクの実行が後になる。
【００３２】
非同期タスクに対するタイムライン２３０の他の例を、図２３に示す。ＭＩＧＢ及びＧＢＭの補充を伴う第１のバケット周期の開始時（２３１）に、第１のタスクの実行を開始する（２３２）。所定の時間後、第１のタスクの実行が時間内に完了する（２３３）。その直後に、タスクは第２の実行を開始する（２３４）。所定の時間後、ＭＩＧＢが完全に使い切られ（２３５）、その後、ＧＢＭも使い切られる（２３６）。このポイントにおいて、第２のタスクの実行が中断される（２３７）。所定の時間後、周期が終了する（２３８）。この第１の期間中、１タスクの実行が完了する。
【００３３】
ＭＩＧＢ及びＧＢＭの補充を伴う第２のバケットの周期の開始時（２３９）において、以前の周期で中断したタスクの実行が再開される（２４０）。所定の時間後、第２のタスクの実行が完了し（２４１）、第３のタスクの実行を開始する（２４２）。所定の時間後、ＭＩＧＢが完全に使い切られる（２４３）。所定の時間後、第３のタスクの実行が早く完了する（２４４）。第４のタスクの実行を開始する（２４５）。所定の時間後、ＧＢＭも使い切られ（２４６）、したがって、第４のタスクの実行が中断される（２４７）。所定の時間後、周期が終了する（２４８）。この第２の期間中、２タスクの実行が完了する。
【００３４】
二つのタイムライン２１０及び２３０は、状況がバケット周期に応じて非常に異なることを示すが、タスクを非同期で実行するときに必ずしも短いタスクがＧＢＭを解放しない。
【００３５】
本発明の一態様によれば、条件付保証バケットマージン(Conditionally Guaranteed Budget Margin)（例えば、タスクに対して分配される量より上又は下のタスクに割り当てられたリソースの量。それは、各バケット周期に対して利用できるように保証される必要はなく、その利用可能性は、他の一部の要因に依存する。）を設けることが言外に含まれる(implicit)。それに対して、割当ては常に明示的(explicit)である。周期ごとに設けることが言外に含まれる。本発明の一態様によれば、上位タスク（ＭＩＴ）が保証バケットマージンを使用しない場合、下位タスクは、ＭＩＴの保証バケットマージンを受け取る。上位保証されたバケット（ＭＩＧＢ）が平均してＭＩＴに対して十分であるとしても、ＭＩＴのバケット消費は、（同期タスクに対する過渡的な高負荷中（２０７〜２０８）のような、同期タスクに対する開始を行うために次のタスク実行の準備ができている（２１３及び２４３）ときである）所定のバケット周期中に上位保証バケットを超えることがある。これらの周期において、ＭＩＴは、保証バケットマージンの一部を使用し、ＬＩＴは、条件保証バケットマージン未満のものを受け取る。
【００３６】
非同期処理のみに生じる第２の関連の問題がある。非同期タスクは、バケットの使用を制約するよう使用することができない。その理由は、それが非同期だからである。同期動作を伴う負荷の見積り及び負荷調整ＭＩＴは時々、作業前に行われる作業量を見積り、その後、バケットが完全に使い切られる前に作業を完了するように（すなわち、そのような品質レベルで）データを処理することができる。非同期動作を伴うＭＩＴは、典型的には、行われた処理量を測定し、その後、期限の消失を回避するよう処理データの品質レベルを調整する。いずれの場合も、ＭＩＴは、常にバケットがその必要に良好に適合する方法の情報を得る。この性能を、バケットを調整するようアロケーションマネージャに要求するのに用いることができる。
【００３７】
一般に、上記エレメント及び機能に対して、本発明は、特に、関連の重要性に割り当てられたタスクに関連した条件保証バケットマージン（ＣＧＢＭ）を用いる。
【００３８】
本発明の一態様によれば、ＭＩＴ及びＬＩＴは、明示的にバケットが知らされる。したがって、ＭＩＴは、バケット使用をマージンなしのバケットに制限することができる。
【００３９】
本発明の他の態様によれば、上位タスク（ＭＩＴ）は、自発的にバケット使用をマージンなしのバケットに制限し、必要な場合にはマージンを使用するか否か明示的に決定する。上位タスクは、決定についての環境（例えば、アロケーションメカニズム、スケジューラ又はバケットモニタ）の情報を提供する。下位タスク（ＬＩＴ）は、（ＭＩＴから直接又は他のエージェントを通じて）ＣＧＢＭを受信し又は受信しない情報を得る。この決定は、必ずしもバケットごとに基づくよう意図する必要はないが、通常稀である。さらに、決定は、常にバケット境界で行われるわけではない。この決定は、典型的には新たなタスク実行の開始時に行われる。バケット使用の再開は十分でない。非同期タスクは、ＭＩＧＢが使い切られたときに実行する停止を行うために使用することができず、ＧＢＭは利用できる。非同期タスクは、この遷移を検出するのに使用することができない。したがって、本発明の第２の態様では、ＭＩＴがバケット制限を開始する間、ＭＩＴをＭＩＧＢに制限することによってスケジューラが実際に制限を行う。
【００４０】
本発明の一態様によるリアルタイムオペレーティングシステムでマルチプルタスクを制御する方法６０の例を、図６に示す。方法６０において、第１のタスクが上位タスクに割り当てられる（エレメント６１）。このタスクのプライオリティを決定することによって、システムは、プロセッサアクセスや、メモリや、ユーザインタフェースのようなリソース又は他の制限された利用可能なアイテムを割り当てることができる。
【００４１】
第２のタスクが下位タスクに割り当てられる（エレメント６２）。第２のタスクは、第１のタスクより低いプライオリティ（すなわち、相対的に低い重要性）と考えられるタスクにすぎないが、第２のタスクを、他の一部のタスクより高いプライオリティ（すなわち、相対的に高い重要性）とすることもできる。
【００４２】
保証バケットマージンは、上位保証バケットに従って上位タスクに割り当てられ、ＭＩＴにその割当てが知らされる（エレメント６３）。上位保証バケットは、第１のタスクによる使用のためにとっておくリソース又は他の制限された利用可能アイテムの量である。保証バケットマージンは、第１のタスクによって必要とされる場合の上位保証バケットより上及び下である、第１のタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。
【００４３】
下位保証バケットは、割当てが知らされる下位タスクＬＩＴにも割り当てられる（エレメント６４）。下位保証バケットは、低プライオリティの第２のタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。さらに、条件付保証バケットマージンは、割当てが知らされる第２のタスクに対して条件付で割り当てられる（エレメント６５）。
【００４４】
実行中のあるポイントにおいて、高プライオリティすなわち上位タスクは、上位タスクが次のバケット周期においてもはや保証バケットマージンを要求しないことを決定することができる（エレメント６６）。これは、高プライオリティタスクがバケットアイテムの使用をモニタするために生じることができ、所定のバケットサイクル中にその必要を予測することができる。その後、上位タスクが保証バケットマージンを要求しないというメッセージを送信する（エレメント６７）。このメッセージは、ＭＩＴともに又はスケジューラや条件付バケットモニタのような他のプロセスから生じることができる。しかしながら、このメッセージを送信できるもののみが、ＧＢＭがもはや必要とされないことを検出するものとなる。このメッセージを送信する最有力候補はＭＩＴである。非同期ＭＩＴの場合、それはスケジューラとなりうる。本例において、ＭＩＴは、事実を検出するとともにメッセージを送信するものである。他のパーティがこれを行う場合、ＭＩＴも情報提供する必要がある。
【００４５】
高プライオリティすなわち上位タスク又は他のタスクが、ＭＩＴが保証バケットマージンを必要としないことを表す場合、条件付で割り当てられたバケットマージンを下位タスクに提供することができる（エレメント６８）。条件付保証バケットマージンは、第２のタスクによって必要とされる場合に下位保証バケットより上及び下である第２のタスクによる使用のためにとっておくリソース又は他の制限された利用可能アイテムの量であるが、その量は、高プライオリティすなわち上位タスクによるように他に必要とされないときにのみ設けられる。
【００４６】
一度メッセージが送信されると、各バケットサイクルでＣＧＢＭを第２のタスクに対して保証するために、ＣＧＢＭが明示的に取り除かれるまで、上位タスクが実際に全体的又は部分的にＧＢＭを使用しないことは重要である。
【００４７】
実行中の他のポイントにおいて、高プライオリティ又は上位タスクは、上位タスクが次のバケットサイクルにおいて保証バケットマージンを再び必要とすることを決定することができる（エレメント６９）。その後、上位タスクが保証バケットマージンを必要としないメッセージが送信される（エレメント６９１）。高プライオリティ又は上位タスクが、保証バケットマージンを要求しないことを表す場合、条件付で割り当てられた保証バケットマージンは、もはや下位タスクに提供されず、したがって、ＣＧＢＭはＬＩＴから取り除かれ、ＧＢＭがＭＩＴに提供され、ＭＩＴ及びＬＩＴにこれらの割当ての情報が提供される（エレメント６９２）。ＧＢＭを要求し及び要求しないこのプロセスは、ループによって表されるように複数回繰り返される。本例において、高プライオリティタスク（例えば、ＭＩＴ）に関連する制御アルゴリズムは、制御アルゴリズムが、
（ａ）適切な場合にはＭＩＴのバケット使用を自発的に制限し（図６のエレメント６６の一部）、
（ｂ）保証バケットマージン（ＧＢＭ）が今から要求されること又は保証バケットマージンがもはや今から要求されないことの信号を送信する（図６のエレメント６７参照）
ように拡張される。ここで用いられるように、高プライオリティタスクのバケットは、高プライオリティタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量に関連する。また、ここで用いられるように、保証バケットマージンは、高プライオリティタスクに対して既に割り当てられたのより上のリソース（又は他の制限された利用可能アイテム）の割り当てられた量を言及し、それは、高プライオリティタスクのために取っておかれる。
【００４８】
同期動作を伴うＭＩＴは、各バケット周期中にそれ自体を制約することができ、その結果、保証バケットマージンは自動的に低プライオリティタスク（例えば、下位タスク）に提供される（図２０のエレメント２０１〜２０４参照）。非同期動作を伴うＭＩＴは、それを正確に行うことができない。その理由は、（図２１〜２４に示すように）その動作がバケット周期に対して非同期だからである。スケジューラの明示的な助けがない場合、非同期ＭＩＴは、バケット周期より更に前の入力の欠如のために非同期ＭＩＴがブロックを行うまで、バケットマージン（例えば、保証バケットマージン）に従ってバケット（例えば、上位保証バケット）の消費を続ける。更に一般的な場合である非同期ＭＩＴ（図２１〜２４）の場合、本発明の第２の態様は、所望のバケット転送が２方向で行われることが要求される。
【００４９】
変更された制御アルゴリズムによって適切に実行時間中にタスクが非同期で動作する場合、以下の変更されたバケット割当てプロトコルは、所望のバケット転送を２方向で満足する。
【００５０】
Ａ．バケットがアロケーションメカニズムによって割り当てられたとき、
１．アロケーションメカニズムは、上位保証バケット及び保証バケットマージンについての情報をＭＩＴに明示的に提供する（図６のエレメント６３参照）。
２．アロケーションメカニズムは、下位保証バケット及び条件付保証バケットマージンについての情報を下位タスクに明示的に提供する（図６のエレメント６４参照）。
３．スケジューラは、上位保証バケット及び保証バケットマージンを、最初のあり得るときにＭＩＴに提供する（図６のエレメント６３参照）。
４．スケジューラは、下位保証バケットを、最初のあり得るときに提供する（図６のエレメント６８参照）。
【００５１】
Ｂ．ＭＩＴがバケットマージンを要求しないとき、
１．実行中のあるポイントにおいて、ＭＩＴは、上位保証バケットのみを用いてジョブを行うことができることを観察する（図６のエレメント６６参照）。
２．ＭＩＴは、保証バケットマージンを要求しないという情報をスケジューラに提供する（図６のエレメント６７参照）。
３．スケジューラは、最初のあり得るときに保証バケットマージンをＭＩＴに提供することを停止する（図６のエレメント６７の一部）。
４．スケジューラは、アプリケーションに応じて瞬時的に又は瞬時的でなくすることができる最初のあり得るときに、条件付バケットマージンのＬＩＴへの提供を開始する（エレメント６８参照）。
５．スケジューラは、この条件付バケットの提供の情報をＬＩＴに提供する（エレメント６８）。
【００５２】
Ｃ．ＭＩＴがバケットマージンを再び要求するとき、
１．実行中のあるポイントにおいて、ＭＩＴは、保証バケットマージンを要求することを観察する（エレメント６９）。
２．ＭＩＴは、保証バケットマージンを要求する情報をスケジューラに提供する（エレメント６９１）。
３．スケジューラは、条件付保証バケットマージンが取り除かれるという情報をＬＩＴに提供する（エレメント６９２）。
４．スケジューラは、あり得る最初のときにおける条件付保証バケットマージンのＬＩＴへの供給を停止する（エレメント６９２の一部）。
５．スケジューラは、あり得る最初のときにおける保証バケットマージンのＭＩＴへの提供を開始する（エレメント６９２の一部）。
【００５３】
ＬＩＴには、減少が生じる前にバケット減少の情報が提供される。ＬＩＴには、増加が生じた後にバケット増加の情報が提供される。ＬＩＴは、いずれにしろ変化に影響を及ぼさない。
【００５４】
図１１は、図７〜１０に記載した種々のプロセスの役割及びインタラクションの例を示す。第１のタスク１１４は、第１のプライオリティレベルを有し、第１のタスク１１４は、高プライオリティタスク又は上位タスクと称される。この高プライオリティタスク１１４は、オペレーティングシステム１１０の外部又は内部のタスクを有することができる。
【００５５】
第２のタスク１１５は、第１のプライオリティレベルより低い第２のプライオリティレベルを有する。この低プライオリティタスク（すなわち下位タスク）１１５は、オペレーティングシステム１１０の外部又は内部のタスクを有することができる。さらに、第２のタスク１１５は、第１のタスク１１４より低いプライオリティにすぎないが、２番目に上位のタスクとして実行することができる。これら２段落において、全てのプライオリティは相対的な重要性である。
【００５６】
アロケーションアルゴリズム１１２は、オペレーティングシステム１１０によって実行される種々のタスク１１４，１１５間でリソースのバケットを割り当てる。本発明の一態様によれば、アロケーションメカニズム１１２は、上位保証バケット及び保証バケットマージンについての情報を明示的に第１のタスク１１４に提供する。上位保証バケットは、第１のタスク１１４による使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。保証バケットマージンは、第１のタスク１１４によって必要とされる場合における上位保証バケットより上又は下である第１のタスク１１４による使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。アロケーションアルゴリズム１１２は、下位保証バケット及び条件付保証バケットマージンについての情報を明示的に第２のタスク１１５に提供する。下位保証バケットは、第２のすなわち低プライオリティタスク１１５の使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。
【００５７】
スケジューラ１１３は、第１のタスク１１４及び第２のタスク１１５を含む、オペレーティングシステム１１０によって実行される種々のタスク１１４，１１５に対する割り当てられた量のリソースの提供を制御する。スケジューラ１１３は、最初のあり得るときに上位保証バケット及び保証バケットマージンを第１のタスク１１４に提供する。スケジューラは、最初のあり得るときに下位保証バケットを第２のタスク１１５にも提供する。
【００５８】
第１のタスクが、実行中のあるポイントにおいて、第１のタスク１１４が上位保証バケットのみを用いて適切に実行できることを決定する場合、第１のタスク１１４は、第１のタスク１１４が保証バケットマージンを必要としない情報をスケジューラ１１３に提供する。この場合、スケジューラ１１３は、最初のあり得るときに保証バケットマージンの第１のタスク１１４への供給を停止し、最初のあり得るときに条件付保証バケットマージンの第２のタスク１１５への提供を開始する。この後、スケジューラ１１２は、条件付保証バケットマージンを付与する情報を第２のタスク１１５に提供する。
【００５９】
条件付保証バケットマージンは、第２のタスク１１５によって必要とされる場合の下位保証バケットより上及び下の第２のタスク１１５による使用のために取っておくリソース又は他の制限された利用可能アイテムの量であるが、この量は、高プライオリティ又は上位タスク１１４によるような他に必要とされたいときにのみ提供される。
【００６０】
次に、第１のタスク１１４は、実行中のあるポイントにおいて第１のタスク１１４が保証バケットマージンを要求することを決定することができ、この場合、第１のタスク１１４は、第１のタスク１１４が保証バケットマージンを必要とする情報を明示的にスケジューラ１１３に提供する。その後、スケジューラ１１３は、条件付保証バケットマージンが取り除かれる情報を第２のタスク１１５に提供し、スケジューラ１１３は、最初のあり得るときに条件付保証バケットマージンの第２のタスク１１３への提供を停止し、スケジューラ１１３は、最初のあり得るときに保証バケットマージンの第１のタスク１１４への提供を開始する。
【００６１】
アプリケーションマネージャ１１１は、ＭＩＴの役割を所定のタスクにアサインし及びデアサインする（図１のエレメント１１及び１４）。アプリケーションマネージャは、ＬＩＴの役割を他の所定のタスクにアサインし及びデアサインする（エレメント１２及び１５）。その後、アプリケーションマネージャ１１１がインアクティブとなるとともに、アロケーションメカニズム１１２がアクティブになる（図１のエレメント１３）。ＭＩＴ及びＬＩＴの役割が終了する（図２のエレメント２６）と、アプリケーションマネージャ１１１が再びアクティブとなるとともに、アロケーションメカニズム１１２がインアクティブとなる。アロケーションメカニズム１１２は、ＭＩＧＢ及びＧＢＭをＭＩＴに割り当て（図７のエレメント７１）、これらの割当ての情報を明示的にＭＩＴに提供する。アロケーションメカニズム１１２は、ＬＩＧＢ及びＣＧＢＭをＬＩＴに割り当て（図７のエレメント７３）、これらの割当ての情報を明示的にＬＩＴに提供する。アロケーションメカニズム１１２は、リザベーションをスケジューラ１１３に送信し（図７のエレメント７５）、スケジューラ１１３は、実行を完了するよう図８のスケジューラプロセス８０を起動する。スケジューラ１１３は、ＬＩＴ及びＭＩＴに対するアロケーションメカニズムからのリザベーションコマンドを受け入れ（エレメント８１）、ＭＩＧＢ及びＧＢＭをＭＩＴに付与し、ＬＩＧＢをＬＩＴに付与する（エレメント８２）。その後、スケジューラは、スケジューリングアルゴリズムに従って実行を行う（エレメント８３）。スケジューラ１１３は、ＭＩＴがもはやＧＢＭを必要としないメッセージをＭＩＴから受信する（エレメント８５）。その後、スケジューラは、ＭＩＧＢのみをＭＩＴに付与し（エレメント８６）、バケット増大の情報をＬＩＴに提供し（エレメント８７）、ＬＩＧＢ及びＣＧＢＭをＬＩＴに付与する（エレメント８８）。その後、スケジューラ１１３は、ＭＩＴがＧＢＭを必要とするメッセージをＭＩＴから受け取ることができ、この場合、スケジューラ１１３は、バケット減少の情報をＬＩＴに提供する（エレメント８１２）。
【００６２】
本発明の他の態様によるアロケーションメカニズムプロセス７０の例を、図７に示す。アロケーションメカニズムプロセス７０は、ＭＩＧＢ及びＧＢＭをＭＩＴ７１に割り当てる。アロケーションメカニズムプロセス７０は、ＬＩＧＢをＬＩＴ７２に割り当てるとともに、ＣＧＢＭを条件付でＬＩＴ７２に割り当てる。アロケーションメカニズムプロセス７０は、その割当ての情報を明示的にＭＩＴに提供する（７３）。アロケーションメカニズムプロセス７０は、その割当ての情報を明示的にＬＩＴにも提供する。アロケーションメカニズムプロセス７０は、ＭＩＴ及びＬＩＴへの割当てに従ってコマンドリザベーションを送信する（７５）。その後、アロケーションメカニズムプロセス７０は、あるイベントによってトリガがかけられるまで待機する（７６）。バケットが不十分である場合、アロケーションメカニズムプロセスは、エレメント７１に戻る。バケットが十分である場合、ＭＩＴ及びＬＩＴの役割が終了し（７８）、アロケーションメカニズムプロセス７０を終了する。
【００６３】
図８は、本発明の他の態様によるスケジューラプロセス８０の他の例を示す。スケジューラプロセス８０は、（図７のエレメント７５に示すように）リザベーションコマンドを受け取り、ＭＩＧＢ及びＧＢＭをＭＩＴに付与するとともにＬＩＧＢをＬＩＴに付与する（８２）。その後、スケジューリングプロセス８０は、スケジューリングアルゴリズム８３に従って実行を行う。決定ポイント８４において、プロセス８０は継続し又は終了する。スケジューリングプロセス８０が継続する場合、あるポイントにおいて、スケジューリングプロセスは、ＭＩＴがもはやＧＢＭ８５を必要としないメッセージをＭＩＴから受け取る（８５）。その後、スケジューラは、ＭＩＧＢのみをＭＩＴに付与する（又は、ＧＢＭをＭＩＴから除去して、ＭＩＴはＭＩＣＧのみを有する。）（８６）。その後、スケジューラプロセス８０は、ｌＩＧＢ及びＣＧＢＭをＬＩＴに付与する（又は、ＣＧＢＭをＬＩＴのリソースに加える。）（８７）。その後、スケジューラプロセス８０は、バケット増大の情報をＬＩＴに提供する（８８）。その後、スケジューリングプロセス８０は、スケジューリングアルゴリズムに従って実行を行う（８９）。決定ポイント８１０において、スケジューリングプロセス８０は継続し又は終了する。スケジューリングプロセス８０が継続する場合、所定のポイントにおいて、スケジューリングプロセス８０は、ＭＩＴがＧＢＭを必要とすることを表すメッセージをＭＩＴから受け取る（８１１）。ＬＩＴは、バケット減少の情報をスケジューラ８１２から提供され、スケジューリングプロセス８０はエレメント８１に戻る。
【００６４】
他の種々のタスクによるＭＩＴプロセスのインタラクションの例９０を、図９に示す。ＭＩＴプロセス９０は、アロケーションメカニズムプロセス７０によってＭＩＧＢ及びＧＢＭの情報が提供される（９１）。ＭＩＴプロセス９０は、ＭＩＧＢ及びＧＢＭを用いながらスケジューラ９２によって開始する。ＭＩＴプロセス９０は、ＧＢＭを必要としないことを決定し（９３）、ＧＢＭが必要とされない情報をスケジューラプロセス８０に提供する（９４）。その後、ＭＩＴプロセス９０は、ＭＩＧＢのみを用いて開始する（９５）。決定ポイント９６において、ＭＩＴプロセス９０は、継続し又は終了する。ＭＩＴプロセス９０が継続する場合、ＭＩＴプロセス９０は、ＧＢＭを必要としていることを決定する（９７）ことができる。ＭＩＴプロセス９０は、ＧＢＭを必要とする情報をスケジューラプロセス８０に提供し（９８）、ＭＩＴプロセス９０は、ＭＩＧＢ及びＧＢＭを用いてスケジューラプロセス９９によって開始する（９９）。決定ポイント９１０において、ＭＩＴプロセス９０は終了し又はエレメント９３に戻る。
【００６５】
他の種々のタスクによるＬＩＴプロセスのインタラクションの例１００を、図１０に示す。ＬＩＴプロセス１００は、ＬＩＧＢ及びＣＧＢＭの情報がアロケーションメカニズムプロセス７０によって提供される（１０１）。ＬＩＴプロセス１００は、ＬＩＧＢを用いてスケジューラによって開始する（１０２）。あるポイントにおいて、ＬＩＴプロセス１００は、ＣＧＢＭが利用できるという情報がスケジューラプロセス８０によって提供される（１０３）。その後、ＬＩＴプロセス１００は、ＬＩＧＢ及びＣＧＢＭを用いて開始する（１０４）。決定ポイント１０５において、ＬＩＴプロセス１００は、継続し又は終了する。ＬＩＴプロセス１００が継続する場合、ＬＩＴプロセス１００は、ＣＧＢＭがもはや利用できないという情報が提供される（１０６）。その後、ＬＩＴプロセス１００は、ＬＩＧＢのみを用いてスケジューラ１０７によって開始する（１０７）。決定ポイント１０８において、ＬＩＴプロセス１００は、終了し又はエレメント１０３に戻る。
【００６６】
本発明の更に別の態様による、条件付バケットモニタプロセスを用いるアロケーションメカニズムの他の例を、図１２に示す。本例において、アロケーションメカニズムは、リザベーションコマンドの受取側である。アロケーションメカニズムプロセス１２０は、ＭＩＧＢ及びＧＢＭをＭＩＴに割り当てる（１２１）。アロケーションメカニズムプロセス１２０は、ＬＩＧＢをＬＩＴに割り当てるとともにＣＧＢＭを条件付でＬＩＴに割り当てる（１２２）。アロケーションメカニズムは、割当ての情報を明示的にＭＩＴに提供する。アロケーションメカニズムは、割当ての情報を明示的にＬＩＴにも提供する（１２４）。アロケーションメカニズムは、ＭＩＴ及びＬＩＴの割当てに従ってコマンドリザベーションを送信する（１２５）。その後、アロケーションメカニズムは、あるイベントによってトリガがかけられるまで待機する。決定エレメント１２７での決定でバケットが不十分である場合、アロケーションメカニズムプロセスはエレメント１２１に戻る。バケットが十分である場合、アロケーションメカニズムプロセス１２０は、エレメント１２８に進む。ＭＩＴ及びＬＩＴが１２８を完了し、プロセスが終了する。
【００６７】
本発明の他の態様による条件付バケットモニタ（ＣＢＭ）プロセス１３０の例を、図１３に示す。ＣＢＭは、ＭＩＴ及びＬＩＴに対するリザベーションコマンドを受け取り、リザベーション（ＭＩＴに対するＭＩＧＢ＋ＧＢＭ及びＬＩＴに対するＬＩＧＢ）をスケジューラに送信する（１３２）。その後、ＣＢＭはイベントを待機する。決定ポイント１３３において、ＣＢＭプロセス１３０は継続し又は終了する。ＣＢＭプロセス１３０が継続する場合、あるポイントにおいて、ＣＢＭプロセスは、ＭＩＴがもはやＧＢＭを必要としないことを表すメッセージをＭＩＴから受け取ることができる（１３４）。その後、ＣＢＭは、リザベーション（ＭＩＴに対するＭＩＧＢ及びＬＩＴに対するＬＩＧＢ＋ＣＧＢＭ）をスケジューラに送信する（１３５）。その後、ＣＢＭは承認を待機する（１３６）。その後、ＣＢＭは、バケット増大の情報をＬＩＴに提供する（１３７）。その後、ＣＢＭはイベントを待機する（１３８）。決定ポイント１３９において、プロセス１３０は継続し又は終了する。プロセス１３０が継続する場合、あるポイントにおいて、ＣＢＭは、ＭＩＴがＧＢＭを必要とするメッセージをＭＩＴから受け取ることができる（１３１０）。ＣＢＭは、バケット減少の情報をＬＩＴに提供する（１３１１）。好適には、このメッセージは、リソースが取り除かれる前にＬＩＴに到達する必要があり、その成功は、引き出された距離、クロックタイミング、処理速度等の任意の要因に依存する。
【００６８】
本発明の更に別の態様によるスケジューラプロセス１４０の他の例を、図１４に示す。スケジューラは、（例えば、図１３のＣＢＭから）一つ以上のタスクに対するリザベーションコマンドを受け取る（１４０）。エレメント１４２において、スケジューラは、エレメント１４１からリザベーション要求又は変更を付与する。その後、スケジューラは、リザベーションコマンドの送信側（例えば、図１３のＣＢＭ）に対してリザベーションコマンドを承認する。その後、スケジューリングプロセスは、スケジューリングアルゴリズムに従って実行される（１４４）。プロセス１４０は、エレメント１４１まで継続し又は決定エレメント１４５で終了する。プロセス１４０が継続する場合、エレメント１４１に進む。
【００６９】
図１２〜１４からの種々のタスクによるＭＩＴのインタラクションの例１５０を、図１５に示す。ＭＩＴは、（例えば、アロケーションメカニズムによって）ＭＩＧＢ及びＧＢＭの情報が提供される（１５１）。ＭＩＴは、ＭＩＧＢ及びＧＢＭを用いてスケジューラによって開始する（１５２）。ＭＩＴは、ＧＢＭを必要としないことを決定し（１５３）、この影響に対するメッセージを（例えば、次のスケジューラに情報を提供するＣＢＭに）送信する（１５４）。その後、ＭＩＴは、ＭＩＧＢのみを用いて開始する（１５５）。決定ポイント１５６において、プロセッサ１５０は継続し又は終了する。プロセス１５０が継続する場合、ＭＩＴは、ＧＢＭを必要とすることを決定する（１５７）。ＭＩＴは、ＧＢＭを必要とするメッセージを（例えば、次にスケジューラに情報を提供するＣＢＭに）メッセージを送信し、ＭＩＴは、ＭＩＧＢ及びＧＢＭを用いてスケジューラ１５９によって開始する。決定ポイント１５１０において、プロセス１５０は、終了し又はエレメント１５３に戻る。
【００７０】
図１２〜１５の他の種々のタスクによるＬＩＴのインタラクションの例１６０を、図１６に示す。ＬＩＴは、アロケーションメカニズムによってＬＩＧＢ及びＣＧＢＭの情報が提供される（１６１）。ＬＩＴは、ＬＩＧＢを用いてスケジューラによって開始する（１６２）。所定のポイントにおいて、ＬＩＴは、ＣＧＢＭが利用できるという情報が（例えば、ＣＢＭによって）提供される（１６３）。その後、ＬＩＴは、ＬＩＧＢ及びＣＧＢＭを用いて開始する（１６４）。決定ポイント１６５において、プロセス１６０は、継続し又は終了する。プロセス１６０が継続する場合、ＬＩＴは、ＣＧＢＭがもはや利用できないという情報が（例えば、ＣＢＭによって）提供される（１６６）。その後、ＬＩＴは、ｌＩＧＢのみを用いてスケジューラによって開始する（１６７）。決定ポイント１６８において、プロセッサ１６０は、終了し又はエレメント１６３に戻る。
【００７１】
本発明の別の態様による図１〜１６の種々のプロセスのインタラクションの例１７０を、図１７に示す。アプリケーションマネージャ１７１は、ＭＩＴの役割を所定のタスクにアサインし及びデアサインする（図１のエレメント１１及び１４）。アプリケーションマネージャは、ＬＩＴの役割を他の所定のタスクにアサインし及びデアサインする（エレメント１２及び１５）。その後、アプリケーションマネージャ１７１がインアクティブになるとともに、アロケーションメカニズム１７２がアクティブになる（図１のエレメント１３）。ＭＩＴ及びＬＩＴの役割が完了する（図５のエレメント５７）と、アプリケーションマネージャ１７１が再びアクティブになるとともに、アロケーションメカニズム１７２がインアクティブになる。アロケーションメカニズム１７２はＭＩＧＢ及びＧＢＭをＭＩＴに割り当て（エレメント１２１）、これらの割当ての情報を明示的にＭＩＴに提供する（エレメント１２３）。アロケーションメカニズム１７２は、ＬＩＧＢ及びＣＧＢＭをＬＩＴに割り当て（エレメント１２３）、これら割当ての情報をＬＩＴに提供する（エレメント１２４）。アロケーションメカニズム１７２は、リザベーションをＣＢＭ１７６に送信し（エレメント１２５）、図１３のプロセス１３０を実行する。ＣＢＭは、リザベーションを図１４のスケジューラプロセス１４０に送信し、実行を完了する。ＣＢＭは、ＭＩＴがもはやＧＢＭを必要としないというメッセージをＭＩＴから受け取る（エレメント１３４）とともに、ＭＩＴがＧＢＭを必要とするメッセージをＭＩＴから受け取る（エレメント１３１０）。その後、ＣＢＭは、ＣＧＢＭが利用できるというメッセージをＬＩＴに送信する（エレメント１３７）とともに、ＣＧＢＭがもはや利用できないというメッセージをＬＩＴに送信する（エレメント１３１１）。さらに、ＣＢＭは、リザベーション変化をスケジューラに送信し（エレメント１４２）、承認をスケジューラから受け取る（エレメント１４３）。スケジューラ１７３は、ＬＩＴ及びＭＩＴに対するＣＢＭからのリザベーションコマンドを受け入れ（エレメント１２１）、ＭＩＧＢ及びＧＢＭをＭＩＴに付与するとともに、ＬＩＧＢをＬＩＴに付与する（エレメント１４２）。その後、スケジューラは、スケジューリングアルゴリズムに従って実行する（エレメント１４３）。リザベーションの変化は、スケジューラ１７３によってＬＩＴ及びＭＩＴに送信される（エレメント１４２）。これらの変化の承認は、スケジューラ１７３によって送信側に送信される（エレメント１４３）。
【００７２】
本発明の更に別の態様による複数のプロセスを制御する方法の例１８０のタイムフローを、図１８に示す。図１８に示すプロセスの正確な順番は重要でないが、時間の順番は一部のプロセスに関して重要であり、それを、これらのプロセスを説明する際に示す。それを示さない場合、相対的な順序を変更することができる。開始１８１において、以下のプロセスが２処理システムに対して生じうる。同様なプロセスが３処理システムに対して生じ、この場合、インタラクションは、任意の２プロセス間で階層的に同様である。
【００７３】
先ず、相対的なプライオリティを確立する必要がある。アロケーションメカニズム又は他の一部のプロセスは、プライオリティのレベルを２タスクにアサインする。これらのタスクの一方は、上位タスク１８２に割り当てられ、この場合、アロケーションメカニズムは、プライオリティ指定の情報をこのプロセスに提供することができる。これらタスクの他方は、下位タスク１８４にアサインされ、この場合、アロケーションメカニズムは、プライオリティ指定の情報をこのプロセスに提供することができる。タスクにプライオリティをアサインする順序は、必ずしも重要でない。例えば、低プライオリティのタスクを最初に割り当てることができ、したがって、エレメント１８４がエレメント１８２の前に生じることができる。
【００７４】
一度プライオリティがアサインされると、タスクの各々にバケットの情報が明示的に提供される。例えば、アロケーションメカニズムは、上位保証バケット及び保証バケットマージンについての情報を明示的にＭＩＴに提供する（１８３）。アロケーションメカニズムは、下位保証バケットについての情報を明示的にＬＩＴに提供し（１８５）、条件付で保証バケットマージンをＬＩＴに提供する。プロセス１８３及び１８５の順番は、プロセスの各々が相対的なプライオリティのアサイン後に生じる必要があることに比べれば重要でない。さらに、ＭＩＴへのバケットの情報提供を、ＭＩＴのアサインの直後又は全てのプライオリティがアサインされた後に行うことができる。ＬＩＴへのバケットの情報適用を、ＭＩＴへのバケットの情報提供前後に行うことができる。要求されることは、バケットの情報提供が相対的なプライオリティのアサイン後にしか行うことができないことである。
【００７５】
バケットについての情報をＭＩＴに提供した後、スケジューラは、あり得る最初のときに上位保証バケット及び保証バケットマージンをＭＩＴに提供する（１８６）。このようなＭＩＴへのバケットの提供を、下位保証バケットについての情報のＬＩＴへの提供前後に行うことができ、そのように情報提供されたＭＩＴのバケットを用いてＭＩＴを開始できるような相対的なプライオリティの次のアサインの直後にできるだけ迅速に行うことができる。
【００７６】
ＭＩＴへのバケットの提供に続いて、スケジューラは、最初のあり得るときに下位保証パケットをＬＩＴに提供する（１８７）。これは、通常、２タスクの相対的なプライオリティに起因してバケットをＭＩＴに提供した後に生じるが、そのように情報提供されたＬＩＴのバケットを用いてＬＩＴを開始できるような相対的なプライオリティの次のアサインの直後にできるだけ迅速に行うことができる。
【００７７】
実行中のあるポイントにおいて、ＭＩＴは、上位保証バケットのみを用いてジョブを行えることを観察することができ、この場合、ＭＩＴは、この観察の情報をスケジューラに提供する（１８８）。これは、バケットをＭＩＴに提供した後にしか生じることができないが、その後のバケット周期中の任意のポイントで生じることができる。簡単のために、観察及びスケジューラの情報提供を、単一エレメントで示すが、これらを時間的に分離することができる。
【００７８】
ＭＩＴの観察についての情報が一度提供されると、スケジューラは、あり得る最初のときにおける保証バケットマージンのＭＩＴへの提供を停止する（１８９）。これは、できるだけ早く保証バケットマージンを使用できるようにするためのスケジューラによる次の情報の受信の直後に最も生じうる。一度この条件（すなわち、ＭＩＴが保証バケットマージンを必要としないこと）がＭＩＴによって存在するよう決定されると、システムは、保証バケットマージンをできるだけ迅速に利用する必要がある。その理由は、この条件が今後（少なくともバケット周期の残りの期間中に）存在しないことがあるからである。
【００７９】
放送バケットマージンのＭＩＴへの供給を停止した（１８９）後、スケジューラは、最初のあり得るときに条件付保証バケットマージンのＬＩＴへの供給を開始する（１９０）。その後、スケジューラは、この追加のバケット提供の情報をＬＩＴに提供する（１９１）。好適には、ＬＩＴが遅延なく他のバケットを用いて開始するために、この情報提供１９１を、条件付保証バケットマージン１９０の提供後に行う必要があるが、ある状況では、これら二つのエレメントを違う順番で行うことができる。
【００８０】
同一バケット周期の実行中のあるポイントにおいて、ＭＩＴは、保証バケットマージンを要求することを観察する（１９２）。これを、エレメント１８８の後に行うことができ、エレメントのいずれか（すなわち、１８９，１９０及び１９１）の後に行われるかに影響を及ぼすことができる。この新たな決定の後に、ＭＩＴは、保証バケットマージンを要求する情報をスケジューラに提供する（１９２）。既に説明したように、これら二つのサブステップを時間的に分離して行うことができるが、簡単のためにこれらを単一エレメントとして示す。この情報を受け取った後、スケジューラは、条件付保証バケットマージンが取り除かれる情報をＬＩＴに提供する（１９３）。典型的には、これを、リソースの不適切な使用を防止するとともにＬＩＴがそれに応じた調整を行って遷移を円滑にするためにこのバケットマージンのＬＩＴへの供給するのを停止する前に行う必要がある。
【００８１】
その後、スケジューラは、最初のあり得るときに条件付保証バケットマージンのＬＩＴへの提供を停止する（１９４）。その後、スケジューラは、最初のあり得るときに保証バケットマージンのＭＩＴへの供給を開始する（１９５）。スケジューラは、先ず、リソースの不適切な使用を防止するとともに円滑な遷移を可能にするために追加のバケットをＭＩＴに供給する前に追加のバケットのＬＩＴへの供給を停止する必要がある。
【００８２】
ある時点において、プロセスは終了する（１９６）が、エレメント１８８〜１９５の他の複数の繰り返しを、アプリケーション仕様に応じて行うことができる。さらに、ＭＩＴは、保証バケットマージンを必要としないことを決定することができず（１８８）、又は、ＭＩＴは、保証バケットマージンを必要としないことを決定した（１８８）後に保証バケットマージン１９２を必要とすることを決定することができない（１９２）。
【００８３】
１．条件付保証バケットマージンの明瞭な付与及び取り除きの間に、ＬＩＴは実際にＣＧＢＭを計上することができる。本発明がない場合、ＬＩＴは、実際に条件付保証バケットマージンを計上することができない。
２．構造的な負荷の増大を検出する個別のエンティティを必要としない。その理由は、ＭＩＴアプリケーション内のローカル制御アルゴリズムが通常の動作の副産物としてこの検出を行うことができるからである。
３．ＭＩＴのローカルアルゴリズムは、個別のエントリが行う場合に比べて構造的な負荷変化を検出することができる。その理由は、それがリソース使用法(resource usage means)に対して意味のある解釈を有するからである。
４．ＬＩＴが、条件付保証バケットマージンの利用可能性についての情報を明示的に提供されるので、ＬＩＴは、変化に対して更に高速かつ更に円滑に応答することができる。この利点は、既に説明している変更したバケット割当てプロトコル（ステップ（ｂ））の直接的な結果である。
５．ＭＩＴは、ＬＩＴの一致を知る必要がない。ＭＩＴは、ＬＩＴが存在することを知る必要がない。
【００８４】
（図１〜５に記載したような）基本プロセスの主な利点は有効なままである。アロケーションメカニズムは、バケット転送に含まれない。これによって、オーバヘッドが大幅に減少する。一例として、新たな状況に対する承認テスト、又は、種々のエンティティが実行される新たな品質レベルを決定する処理段階を必要としない。
【００８５】
同期ＭＩＴの場合、既に説明している変更したパケット割当てプロトコル（ステップ（ｂ））の変形により複数の利点を達成することができる。本発明の更に別の態様によれば、コンピュータ読出し可能媒体の一例は、上記プロセス及び方法を実行するプロセッサを制御する符号化プログラミング命令を有する。例えば、プロセッサは、図１〜１８で説明した方法を実行する。コンピュータ読出し可能媒体は、ＣＤ−ＲＯＭ，ＤＶＤに制約されず、磁気記憶装置、ＲＡＭ，ＲＯＭ、ハードディスク、メモリスティク、光メモリ等を含む。
【００８６】
本発明の使用を追跡することができる。その理由は、本発明の使用が明示的な他のインタフェースを要求するからである。
他のＭＩＴインタフェース
Set_budgets (in MIGB_value: budget_type; in GBM_value: budget_type);//called by AM
追加のＬＩＴインタフェース
Set_budgets (in LIGB_value: budget_type; in CGBM_value: budget_type);//called by AM
CGBM_available();/called by scheduler.
CGBM_not_available();called by scheduler.
他のスケジューラインタフェース
GBM_required (in tid, task id);//called by MIT
GBM_not_required (in tid, task id);//called by MIT
【００８７】
上記発明を、テレビジョン、受信機、オーディオ−ビデオプロセッサ、デジタルプロセッサ、セットトップボックス及び他の家電に適用できる。
【００８８】
種々の実施の形態をここで特定して説明したが、本発明の変更及び変形は、上記教示によってカバーされ、本発明の範囲を逸脱することなく添付した請求の範囲内にある。例えば、所定の用語及びプロトコルを用いたが、他の名称及びプロトコルを、本発明の範囲を逸脱することなく用いることができる。さらに、本例は、特許請求の範囲によってカバーされた発明の変更及び変形を制限するよう解釈すべきものではなく、あり得る変形を示しているにすぎない。
【図面の簡単な説明】
【００８９】
【図１】タスクに対する相対的なアサインによりマルチプルタスクを制御するタスクマネージャを示す。
【図２】種々のタスクに対するリソースの割当てによりマルチプルタスクを制御するアロケーションメカニズムを示す。
【図３】リザベーションに従ってリソースを種々のタスクに付与することによりマルチプルタスクを制御するスケジューラを示す。
【図４】リソースの割当て内で動作する上位タスクを示す。
【図５】図１〜４及び１９の種々のエレメントのインタラクションを示す。
【図６】本発明の一態様によるオペレーティングシステムの一例を示す。
【図７】本発明の他の態様によるアロケーションメカニズムの一例を示す。
【図８】本発明の更に別の態様によるスケジューラの一例を示す。
【図９】本発明の更に別の態様に従って動作する上位タスクの一例を示す。
【図１０】本発明の更に別の態様に従って動作する下位タスクの一例を示す。
【図１１】本発明の更に別の態様による図１及び７〜１０の種々のエレメントのインタラクションを示す。
【図１２】本発明の更に別の態様によるアロケーションメカニズムの他の例を示す。
【図１３】本発明の更に別の態様による条件バケットモニタの例を示す。
【図１４】本発明の更に別の態様によるスケジューラの他の例を示す。
【図１５】本発明の更に別の態様によって動作する上位タスクの他の例を示す。
【図１６】本発明の更に別の態様によって動作する上位タスクの他の例を示す。
【図１７】本発明の更に別の態様による図１及び１２〜１６の種々のエレメントのインタラクションを示す。
【図１８】本発明の更に別の態様による種々のプロセスのインタラクションを示す。
【図１９】リソースの割当て内で動作する下位タスクを示す。
【図２０】同期プロセス実行の例を示す。
【図２１】非同期プロセス実行の例を示す。
【図２２】非同期プロセス実行の例を示す。
【図２３】非同期プロセス実行の他の例を示す。
【図２４】非同期プロセス実行の他の例を示す。
【図１】
2007512592.tif 000003
【図２】
2007512592.tif 000004
【図３】
2007512592.tif 000005
【図４】
2007512592.tif 000006
【図５】
2007512592.tif 000007
【図６】
2007512592.tif 000008
【図７】
2007512592.tif 000009
【図８】
2007512592.tif 000010
【図９】
2007512592.tif 000011
【図１０】
2007512592.tif 000012
【図１１】
2007512592.tif 000013
【図１２】
2007512592.tif 000014
【図１３】
2007512592.tif 000015
【図１４】
2007512592.tif 000016
【図１５】
2007512592.tif 000017
【図１６】
2007512592.tif 000018
【図１７】
2007512592.tif 000019
【図１８】
2007512592.tif 000020
【図１９】
2007512592.tif 000021
【図２０】
2007512592.tif 000022
【図２１】
2007512592.tif 000023
【図２２】
2007512592.tif 000024
【図２３】
2007512592.tif 000025
【図２４】
2007512592.tif 000026
【国際調査報告】
2007512592.tif 000027
2007512592.tif 000028
2007512592.tif 000029