JP2004502235A - スケジュール決定方法、スケジューラ及びシステム - Google Patents

Abstract

複数のリソースを有するシステムにおいて複数のタスクを実行するためのフレキシブルなスケジュールを決定する方法を実施するスケジューラである。スケジュールは、各タスクについて、開始時間、終了時間、当該タスクに対するリソースの割当て、並びに、時間及び処理速度の集まりを含む。この情報を用いて、例えば多数のタスクが同一のリソースを必要とするとき、タスクの実行の速度は変更されうる。このために、スケジューラはまずウィンドウを用いて部分的なスケジュールを決定し、次に、線形計画及び列発生を用いてウィンドウの長さ及び各ウィンドウにおける各タスクの処理速度を決定する。

Description

【０００１】
本発明は、複数のリソースを必要とする複数のタスクを実行するためのスケジュールを決定する方法に関する。
【０００２】
本発明は、更に、複数のリソースを必要とする複数のタスクを実行するためのスケジュールを決定するスケジューラに関する。
【０００３】
本発明は、更に、かかるスケジューラを有するシステムに関する。
【０００４】
多数のリソースを用いて多数のタスクを実行しようとする場合、タスクの実行についての要件や、リソースの容量の制限条件があることが多い。例えば、ディジタル伝送システムでは、ビデオストリームの伝送には、ストリームを発生させるビデオサーバ、不法な視聴を防止するためにストリームを暗号化する条件付きアクセスモジュール、伝送媒体へのゲートウエイ、及び、ストリームを受信者へ送信する衛星といった送信器を必要とする。これらのリソースは全て限られた帯域幅容量を有し、ビデオストリームには多くの要件が課されうる。ストリームは９時に開始することが要求されることがあり、又は、送信ビット速度は少なくとも２８キロビット毎秒であることが要求されることがある。例えば多数の機械で多数の製品を製造する工場や、例えば学級の生徒が教育を受けうるように教室に教師や備品を割り当てねばならない学校といった他の分野では、同様に、リソースの容量は限られ、タスクは一定の要件を有する。例えば、学校環境におかれている教師は、一度に２５人の生徒しか教えることができないという制限を有しうる。タスクを十分に行うことを確実とするために更なるリソースを追加すること、例えば工場に更なる機械又はより容量の大きい伝送線を追加することは、非常に費用がかかるため、常に可能であるわけではない。
【０００５】
従って、タスクを実行せねばならないシステムが、利用可能なリソースについての限界及びタスク自体から導出される実行のための要件を満たしつつ、いつ、どのように多数を実行するかを決定するための、スケジューリングの問題がある。タスクを実行するために出来る限り良いパフォーマンスを得るために、利用可能なリソースを最適に使用することが必要である。従って、これらのタスクの実行についてのスケジューリングは非常に重要である。
【０００６】
現在のスケジューリング技術の欠点は、実行されるべき各タスクの処理速度が通常は予め決定され当該タスクの実行中は一定に維持されることである。このように、２以上のタスクが同一のリソースを同時に占有する場合、そのリソースの処理能力は少なくとも考慮されているタスクの処理速度の和でなくてはならない。しかしながら、幾つかの種類のタスクは、実行中に処理速度が変化されることを許容している。例えば、ディジタルビデオコンテンツの伝送は、幾らかの最低ビットレートが達成されている限りは、可変ビットレートで行われうる。現在のスケジューリング技術は、この性質を利用するのに十分にフレキシブルではない。このようなスケジューリング技術によって生成されるスケジュールを用いるシステムの操作者は、負荷が高すぎる場合は手動で介入しいくらかのタスクの処理速度を変化させ、新しい状況のためのスケジュールを再び計算せねばならない。
【０００７】
本発明は、複数のリソースを必要とする複数のタスクを実行するためのフレキシブル且つ効率的なスケジュールを決定しうる冒頭の段落に記載の方法を提供することを目的とする。
【０００８】
この目的を達成するため、本発明による方法は、
（ａ）各タスクの所与の要件及び各リソースについての所与の制限条件から一組の制約条件を構築する段階と、
（ｂ）上記一組の制約条件に含まれる制約条件に基づいて、各タスクについて相対開始時間、相対終了時間、及びリソースの割当てを決定する段階と、
（ｃ）上記タスクについて決定された相対開始時間、相対終了時間、及びリソースの割当てに基づいて、上記一組の制約条件に含まれる制約条件の違反を最小限としつつ、各タスクについて絶対開始時間、絶対終了時間、並びに、時間及び関連付けられるタスク処理速度の集まりを決定する段階と、
（ｄ）各タスクについて上記決定された絶対開始時間、絶対終了時間、時間及び関連するタスク処理速度の集まり、並びに、上記タスクに対するリソースの割当てを含むスケジュールを決定する段階とを含む。
【０００９】
本発明の方法によって生成されるスケジュールは、各タスクについての絶対開始時間及び絶対終了時間を与えるだけでなく、リソースの割当て、及び、時間や関連するタスク処理速度の集まりを与える。この集まりは、各タスクの処理について所望のフレキシビリティを与える。集まりのうちの時間は、当該のタスクの処理速度がその時点に関連付けられるタスク処理速度へ変化されねばならない時点であると理解されうる。タスク処理速度は、次の時点まで少量ずつ任意に変化されうる。或いは、集まりのうちの２つの連続する時間は、タスク処理速度が、２つの時間のうちの低い方に関連付けられる所与のタスク処理速度のレベルに一定に維持されねばならない時間間隔を指すものと理解されうる。
【００１０】
タスクに対するリソースの割当ては、そのタスクの実行に使用されるべき特定のリソースを同定する。授業タスクは、例えば、教師、教室、及び、オーバーヘッドプロジェクタを必要とするという要件を有し、この場合、リソースの割当ては、教師Ｊｏｈｎｓｏｎが教室３ＢでオーバーヘッドプロジェクタＴＨＸ１１３８を使用しうることを指定する。
【００１１】
本発明の方法の実施例では、段階（ｃ）は、
ウィンドウの系列、上記系列のうちタスクの相対開始時間及び相対終了時間のうちの一つに対応するウィンドウの開始時間、及び、上記ウィンドウの終了時間であり上記系列のうちの次のウィンドウの開始時間に対応する終了時間を決定する段階と、
上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、上記系列のうちのウィンドウの絶対長さを決定する段階と、
上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、各ウィンドウについて、各タスクに対する処理速度を決定し、各タスクについて時間及びそれに基づく関連するタスク処理速度の集まりを生成する段階と、
各タスクについて、上記ウィンドウの絶対長さから絶対開始時間及び絶対終了時間を決定する段階とを含む。
【００１２】
タスクの開始時間と終了時間の間の時間期間であるウィンドウを導入すると、本実施例の方法は、制約条件に対する違反を最小限にしつつ、ウィンドウの絶対長さを計算することができる。開始時間及び終了時間に対する要件が非常に厳しい場合、可能な解はわずかである。各ウィンドウについて、各タスクについての処理速度が計算され、ウィンドウの長さが所与であれば、上述の時間と関連するタスク処理速度の集まりが容易に導出される。ウィンドウの開始時間は、そのウィンドウについてのタスク処理速度が関連付けられる時点として使用されえ、又は、ウィンドウの長さはタスク処理速度が計算されたタスク処理速度のレベルに一定とされねばならない時間期間を導出するために使用されうる。タスクについての絶対開始時間及び絶対終了時間は、ウィンドウ長さから決定される。ウィンドウの開始時間はタスクの開始時間及び終了時間に対応し、ウィンドウの絶対長さは予め計算されているため、１つの固定の時点のみが必要である。操作者によって入力されうる、又は、スケジュールが計算される場合は現在時間又は将来の特定の時間として定義されうる、この時点が所与であれば、全ての絶対窓幅はタスクについての絶対開始時間及び絶対終了時間へ容易に変換されうる。
【００１３】
更なる実施例では、上記制約条件に対する違反が生じているか否か判定する段階を更に含み、生じていれば、
タスクについての新しい相対開始時間、タスクについての新しい相対終了時間、及びタスクについての新しいリソースの割当てのうちの少なくとも一つを決定し、
上記段階（ｃ）を実行する。
【００１４】
本発明による方法によって得られるスケジュールは、理想的には制約条件を完全に満たすべきである。特定の解は、開始時間及び終了時間が特定の順序とされている場合、又は、リソースの割当てが所与である場合は、回避することが不可能な多くの違反を有しうる。その場合、タスクの順序を入れ替えること、又はリソースの割当てを変更することが有利である。すると、新しい順序又は割当て、又はその両方が与えられれば、新しいスケジュールが決定されうる。このスケジュールがやはり幾つかの制約条件に違反する場合、更に順序を入れ替えること、又は割当ての更新が行われうる。幾らかの時間に亘って方法を実行してもスケジュールが完全には制約条件を満たさない場合は、スケジュール問題に対する可能な解がない可能性がある。その場合、違反が最小限となるスケジュールが選択されるべきである。更に、制約条件は、例えば更なるリソースを追加すること又は既存のリソースに更なる容量を追加することによって緩和されうる。
【００１５】
本発明の更なる実施例では、上記系列のうちのウィンドウの絶対長さを決定する段階は、線形計画問題を解くことによって行われる。この実施例の利点は、線形計画が上述の種類の問題の解を得るために簡単且つ高速な方法であることである。
【００１６】
本発明の更なる実施例では、方法は、上記各ウィンドウについて各タスクに対するタスク処理速度を決定する段階は、線形計画問題を解くことによって行われる。この実施例の利点は、この段階をウィンドウの絶対長さを決定する段階と組み合わせて双一次計画問題とすることにより、列発生を用いた線形計画法によって解を得ることができることである。
【００１７】
本発明は、複数のリソースを必要とする複数のタスクを実行するためのフレキシブル且つ効率的なスケジュールを決定しうる冒頭の段落に記載のスケジュールを提供することを更なる目的とする。
【００１８】
この目的を達成するため、スケジューラは、
各タスクの所与の要件及び各リソースに対する所与の制限から一組の制約条件を構築する構築手段と、
上記一組の制約条件に含まれる制約条件に基づいて、各タスクについて相対開始時間、相対終了時間及びリソースの割当てを決定する順序づけ手段と、
上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、上記タスクについて決定された相対開始時間、相対終了時間、及びリソースの割当てに基づいて、各タスクについて絶対開始時間、絶対終了時間、及び時間及び関連付けられるタスク処理速度の集まりを決定するタイミング手段と、
各タスクについて上記決定された絶対開始時間、絶対終了時間、時間及び関連するタスク処理速度の集まり、並びに、上記タスクに対するリソースの割当てを含むスケジュールを決定するスケジューリング手段とを含む。
【００１９】
スケジューラの１つの実施例では、タイミング手段は、
ウィンドウの系列、上記系列のうちタスクの相対開始時間及び相対終了時間のうちの一つに対応するウィンドウの開始時間、及び、上記ウィンドウの終了時間であり上記系列のうちの次のウィンドウの開始時間に対応する終了時間を決定し、
上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、上記系列のうちのウィンドウの絶対長さを決定し、
上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、各ウィンドウについて、各タスクに対する処理速度を決定し、各タスクについて時間及びそれに基づく関連するタスク処理速度の集まりを生成し、
各タスクについて、上記ウィンドウの絶対長さから絶対開始時間及び絶対終了時間を決定するよう配置される。
【００２０】
更なる実施例では、スケジューラは、
上記制約条件に対する違反が生じているか否か判定する段階を更に含み、生じていれば、
タスクについての新しい相対開始時間、タスクについての新しい相対終了時間、及びタスクについての新しいリソースの割当てのうちの少なくとも一つを決定し、
上記タイミング手段を作動させる。
【００２１】
更なる実施例では、スケジューラは、線形計画問題を解くための線形計画手段を更に含む。
【００２２】
本発明の更なる目的は、かかるスケジューラを有するシステムを提供することである。
【００２３】
本発明の上述及び他の面は、添付の図面に示される実施例を参照して明らかとなろう。全ての図面を通じて、同一の参照番号は同様の又は対応する特徴を示す。図示される幾つかの特徴は、一般的にはソフトウエア上で実施され、それ自体として例えばソフトウエアモジュール又はオブジェクトといったソフトウエアエンティティを表わす。
【００２４】
図１は、スケジューラ１００及び複数のリソース１０１、１０２、１０３、１０９、１１０、１１１、１１２、１１３、１１４、１１５を有するシステムを示すブロック図である。図１のシステムは、ビデオサーバ１０１、カルセルサーバ１０２又はＩＰトンネル１０３といった複数のソースから受信器１１４へコンテンツを伝送しうるディジタルビデオ伝送システムである。送信の前に、コンテンツは不法なアクセスを防止するために暗号化されうる。このために、コンテンツはＩＰ暗号化器１０９を通される。その後、コンテンツは、様々なコンテンツ部分を伝送に適した１つのディジタルビデオストリームへ多重化するＩＰ−ＤＶＢゲートウエイ１１０を通される。多重化されたストリームは、従来の地上回線又は衛星接続といった様々な手段を通じて受信器１１４へ伝送される。送信器１１３は地上回線へのアクセス手段として用いられ、アップリンク１１１はストリームを衛星１１２へ伝送することができる。受信器１１４は、これらの様々な手段からストリームを受信し、要求に応じてコンテンツを多重化し、復号化し、処理する。例えば様々な受信器１１４へのコンテンツの部分に対するアクセス権を管理するために、条件付きアクセスモジュール１１５が設けられてもよい。スケジューラ１００は、これら全てのリソース上で全てのタスクを最も効率的に実行するためのスケジュールを決定する。システムは、スケジューラ１００から得られるスケジュールに従ってタスクを実行するよう配置される。
【００２５】
ここでは、スケジューラ１００はディジタルビデオ伝送システムの一部として示されているが、多様な他のシステムにも適用されうる。例えば学校では、スケジューラ１００は、様々な教室、教師、並びに、黒板、オーバーヘッドプロジェクタ、及び、テレビジョンシステムといった利用可能な備品の利用を効率的に計画するために使用されうる。工場では、スケジューラ１００から得られるスケジュールは、備品、リソース、及び労働者を効率的に用いて、利用可能な機械で様々な製造工程を実行するために使用されうる。
【００２６】
タスクの実行に必要とされる全てのリソースは、実行中全て同時に占有されると想定する。例えば工場では、製品を製造するためには、労働者と、幾つかの機器と、塗料といった幾らかの消耗品の供給とを必要としうる。学校環境では、各教師は、教室と、黒板、オーバーヘッドプロジェクタ、又は多数のコンピュータといった備品とを必要とする。これら全てのリソースは、一クラスの生徒が授業を受けているときに同時に占有される。
【００２７】
各タスクは、必要とされるリソースの種類の関連付けられたリストを有する。従って、タスクに対してリソースを割り当てるということは、必要とされる種類を有するリソースを選択することを含む。学校環境では、一つの授業タスクは、教室、教師、及び黒板を必要とするものでありうる。この授業タスクに対して、実際の割当てでは、１０番教室に、教師Ｂｏｗｍａｎと、黒板Ｈ９０００が選択されうる。他の授業タスクは、やはり教室と教師を必要とするが、黒板の代わりにオーバーヘッドプロジェクタを必要とするものでありうる。この授業タスクに対して、割当ては、１１番教室に、教師Ｌｕｃａｓと、オーバーヘッドプロジェクタＴＨＸ１１３８が選択されるものでありうる。この場合、適当なリソースが割り当てられ要件が満たされるためには、各リソースについてその種類が知られていることが必要である。
【００２８】
複数のリソースを、夫々が同様の特徴のリソースを有する幾つかの別個の組へ分割することが有利な場合がある。例えば、学校環境では、一組の教室、一組の教師、及び、一組のオーバーヘッドプロジェクタが存在しうる。このとき、各タスクに対するリソースの割当ては、各組から１つの要素を選択するように単純にされうる。これにより、割当てにおいて各リソースの種類を調べねばならないという手間が省ける。図１中、ソース１０１、１０２、１０３は、第１のグループ１０４を成す。ＩＰ暗号化器１０９は１つしかないため、第２のグループ１０５は１つの構成要素のみを有する。同様に第３のグループ１０６は、構成要素としてＩＰ−ＤＶＢゲートウエイ１１０のみを有する。第４のグループ１０７は、伝送手段１１１、１１３によって形成される。コンテンツの各部分は、各グループ１０４、１０５、１０６、１０７の様々なリソースのうちの１つで実行されねばならない。
【００２９】
図２は、スケジューラ１００について詳細に示す図である。スケジューラ１００は、構築モジュール２０１、順序づけモジュール２０２、タイミングモジュール２０３、及び、スケジューリングモジュール２０４を含む。スケジューラ１００は、更に、スケジューリング問題を解決するために用いられる線形計画モジュール２０６を含みうる。
【００３０】
構築モジュール２０１は、ソース２００から、各タスクの一連の要件及び各リソースについての制限条件を受け取り、それらに基づいて一組の制約条件を構築する。
【００３１】
タスクの集合Ａのうちのタスクａの要件は、少なくとも、リリース時間ｒ（ａ）及び締切又は期限時間ｄ（ａ）を含む。これらの時間は、タスクａの実行が開始しうる最も早い時間と、タスクａの実行が終了していなければならない時間とを夫々示す。タスクａの処理速度について更なる要件があってもよい。タスクａの最小処理速度はｐ_ｍｉｎ（ａ）で与えられ、最大処理速度はｐ_ｍａｘ（ａ）で与えられる。タスクａは、処理されているタスクの部分についての下界を有し、例えば、ディジタルビデオ伝送では伝送されるコンテンツのサイズについての下界がありうる。これは、ｃ（ａ）によって示される。タスクａは、更に、ｖ（ａ）で示される値を有しうる。タスクの値は、スケジュールされるべき異なる実行の間にトレードオフを与えるために使用されうる。以下に定義されるような第１のスケジューリングの目的は、スケジュールされた実行の加重和を最大化することであり、上述の値はそれらの重み計数である。尚、この値は、優先度の高いクラスの値を優先度の低いクラスよりもはるかに大きく選定することにより、異なる優先度のクラスを示すためにも使用されうる。
【００３２】
タスクの実行が行われる時間は、ウィンドウの系列へ分割されうる。タスクａは、その実行の時間の長さに対して下界ｔ_ｍｉｎ（ａ）及び上界ｔ_ｍｉｎ（ａ）を有しうる。ウィンドウの概念については、以下詳述する。
【００３３】
タスクは、何らかの方法で関連付けられうる。即ち、１つのタスクが他のタスクの前又は後に開始するよう要求される、２つのタスクが同時に又はその間に特定の時間をおいて開始される、又は、１つのタスクは他のタスクが完了するまで待機せねばならない、等である。このために、開始−開始を示すＴ_ｓｓ、開始−完了を示すＴ_ｓｃ、完了−開始を示すＴ_ｃｓ、完了−完了を示すＴ_ｃｃという４つのタイミング関係を定義する。これらについては、以下の説明のうち、先行制約条件についての説明において詳述する。
【００３４】
リソースｒの制限条件は、少なくとも、その処理能力についての上界ｐ（ｒ）と、同時に実行されうるタスク数についての限界ｎ（ｒ）とを含む。リソースがグループ化されるとき、各グループ中のリソースは、グループｊについてはＲ_ｊのように示される。タスクに割り当てられたリソースはρ_ｉ（ａ）と示され、これはＲ_ｊのうちの要素である。
【００３５】
タスクａ及び各グループｊに対しては、更に、リードイン時間ｌ^ｉｎ _ｊ（ａ）とリードアウト時間ｌ^ｏｕｔ _ｊ（ａ）があってもよく、これは、そのグループから選択されたリソース上でのタスクの実行の直前及び直後に、そのリソースがやはりそのタスクによって使用されることを示す。各リソースｒは、関連付けられた利用可能性ウィンドウを更に有しうる。この利用可能性ウィンドウの開始時間はｓ（ｒ）で示され、終了時間はｅ（ｒ）で示される。リソースは、使用可能性ウィンドウの持続時間に亘ってのみ利用可能である。リソースが多数回利用可能及び利用可能でない状況をモデル化するために、リソースは異なる利用可能性ウィンドウを用いて２回定義されねばならない。
【００３６】
リソースｒは、更に、幾つかの種類のオーバヘッドを有しうる。固定のオーバヘッドはｏ（ｒ）で示され、可変のオーバヘッドはｑ（ｒ）で示される。従って、ビデオ伝送の場合は、ビットレートｘの入力ストリームはビットレートｏ＋ｑｘの出力ストリームを生じさせる。
【００３７】
幾つかのリソースが共に使用されること、又は特定の組合せが禁止されることが要求されることがある。この制限条件は、グループｊのリソースｒがグループｊ’のリソースｒ’と組み合わされる場合に、要素（ｒ、ｒ’）のみを有する集合Ｃを追加することによってモデル化される。同様に、１つのグループの同じリソースを使用する２つのタスクが、他のグループの同じリソースも使用せねばならないことが要求又は禁止されることがある。これは、グループｊの同一のリソースを幾つかのタスクに割り当てることがグループｊ’の同一のリソースをこれらのタスクに割り当てることを意味する場合、（ｊ，ｊ’）のみを有する集合Ｕによってモデル化される。
【００３８】
スケジュールは、いつ実行が行われるか、及び各実行の際にどのリソースが使用されるかを決定する。更に、スケジュールは、実行中に用いられるタスク処理速度を決定する。処理速度の決定のために、実行プロファイルは時点τとタスク処理速度πの集まり（τ_０，π_１，τ_１，π_２，．．．τ_ｍ，π_ｍ）として定義され、時間間隔（τ_ｋ−１，τ_ｋ）の間はタスク処理速度がπ_ｋであることを示す。タスクａの絶対開始時間はτ_ｓｔ（ａ）で示され、絶対終了時間はτ_ｃｐ（ａ）で示される。
【００３９】
このように、スケジュールは、絶対開始時間τ_ｓｔ（ａ）、絶対終了時間τ_ｃｐ（ａ）、時間及び関連するタスク処理速度の集まり（τ_０，π_１，τ_１，π_２，．．．τ_ｍ，π_ｍ）、並びに、各グループｊに対するリソースρ_ｊ（ａ）の割当てを含む。例えば要求されるリソースが利用可能でないことにより、幾つかのタスクがスケジュールできない場合がある。それでも、これらのタスクをスケジュールに入れ、スケジュールされていないタスクとスケジュールされたタスクとの間の相互関係が保たれるようにすることが有利である。例えば、第１のスケジュールされたタスクがスケジュールされていないタスクの後に置かれ、そのスケジュールされていないタスクが第２のスケジュールされたタスクの後に置かれる場合、スケジュールされていないタスクを完全に除去することにより第２のタスクの後に置かれる第１のタスクの制約条件が失われることとなる。スケジュールされたタスクの集合はＡ^＊によって示される。完全集合Ａ又は制限された集合Ａ^＊のタスクとの差は、特筆しない限り本発明に関連性がないものとする。
【００４０】
スケジュールが満たさねばならない制約条件には、幾つかの種類がある。第１の種類の制約条件は、実行時間制約条件であり、各タスクａに対して、以下の関係、
【００４１】
【数１】

が成り立たねばならない。即ち、絶対開始時間は最小でもリリース時間であり、絶対終了時間は最大でも期限時間でなくてはならない。絶対開始時間と絶対終了時間の差として定義される実行の持続時間は、所与の最小実行時間と最大実行時間の間でなくてはならない。
【００４２】
第２の種類の制約条件は、先行制約条件である。２つのタスクａ及びｂについて、以下の制約条件、
【００４３】
【数２】

が構築され、ただし、Ｔ_ｓｓ、Ｔ_ｓｃ、Ｔ_ｃｓ、Ｔ_ｃｃは、タスクの実行間の開始−開始、開始−完了、完了−開始、完了−完了のタイミング関係を示す。ａの開始とｂの開始の間に時間ｘがなくてはならない場合は、要素（ａ，ｂ，ｘ）は集合Ｔ_ｓｓの中にある。ａの開始とｂの終了の間に時間ｘがなくてはならない場合は、要素（ａ，ｂ，ｘ）は集合Ｔ_ｓｃの中にあり、他の２つの集合Ｔ_ｃｓ、Ｔ_ｃｃについても同様である。即ち、これらの制約条件はタスクの間のタイミング関係を強制するものである。
【００４４】
第３の種類の制約条件は、実行制約条件であり、リソースｒについて、リソースｒを同時に占有するタスクａの数が限界ｎ（ｒ）を超えてはならないことを指定する。また、考慮すべきリードイン時間ｌ^ｉｎ _ｊ（ａ）とリードアウト時間ｌ^ｏｕｔ _ｊ（ａ）がある。タスクａがグループｊからのリソースを占有する時間を与える占有関数α_ｊ（ａ，ｔ）は、
【００４５】
【数３】

によって定義される。この関数より、実行制約条件は以下の式、
【００４６】
【数４】

のように定義される。
【００４７】
第４の種類の制約条件は、タスクａの各実行について実行プロファイル（τ_０，π_１，τ_１，π_２，．．．τ_ｍ，π_ｍ）が以下の関係、
【００４８】
【数５】

を満たさねばならないことを指定するものである。
【００４９】
第５の種類の制約条件は、リソース処理制約条件である。任意の時点においてタスクａ∈Ａ^＊の処理速度を与える処理速度関数は、実行プロファイル（τ_０，π_１，τ_１，π_２，．．．τ_ｍ，π_ｍ）を有するタスクａについては、以下の式、
【００５０】
【数６】

で与えられる。リソース中のオーバヘッドは、グループｊのリソースρ_ｊ（ａ）について出力タスク処理速度関数を、以下の式、
【００５１】
【数７】

、但し、全てのタスクａ及び時間ｔについてπ_０（ａ，ｔ）＝π（ａ，ｔ）、によってモデル化されうる。タスク処理速度関数を用いると、リソース処理制約条件は、各グループｋ、グループｊの全てのリソースｒ、及び全てのｔについて、以下の式、
【００５２】
【数８】

が成り立たねばならない。
【００５３】
第６の種類の制約条件は、必要であれば正しい組合せのリソースが使用されることを確実とするリソース組合せ制約条件であり、以下の式、
【００５４】
【数９】

で表せる。
【００５５】
第７の種類の制約条件は、単一性制約条件である。これらは、全てのグループ対（ｊ，ｊ’）∈Ｕ及び全てのタスクａ，ａ’に対して、以下の式、
【００５６】
【数１０】

が成り立たねばならないことを指定する。理想的には、上述の全ての制約条件を満たしつつ全てのタスクを含むスケジュールを見つけることを目的とする。しかしながら、他の制約条件に違反することなく全てのタスクが実行されうる解は存在しない可能性が高い。その場合、スケジュールされたタスクの加重和を最大化することが目的となり、即ち、スケジュールσに対して
【００５７】
【数１１】

を最大とすることが目的となる。ｆの最大値に対して１つ以上のスケジュールσが存在する場合、割り当てられたタスク処理速度は最適化されるべきである。第３の目的は、タスクの実行時間を最小化することでありうる。
【００５８】
図３は、スケジューラ１００から得ることができるスケジュールの例を示す図である。スケジュールには、複数のタスク３０１、３０２、３０３、３０４、３０５、３０６、３０７、３０８がある。垂直軸は、任意の目盛りでタスク処理速度を示す。水平軸は、時間を示す。図１に示される実施例では、これらのタスクは、例えば、第１の映画３０１、金融ファイルの伝送３０２、スポーツの生放送イベント３０３、第２の映画３０４、幾つかのニュース放送３０４、３０６、３０７、３０８である。
【００５９】
所与のリリース時間及び期限時間が非常に厳しいタスク、例えば９時に開始し１０分間放送されるニュース放送といったタスク以外は、絶対的な開始時間及び終了時間は知られていないが、開始時間及び終了時間の相対的な順序付けは可能である。順序付けモジュール２０２はこのような相対的な順序を生成し、この順序から相対的な開始時間及び相対的な終了時間を導出する。
【００６０】
これらの実行が行われる時間は、ウィンドウの系列ｗ_０，ｗ_１，．．．，ｗ_１５へ分割される。この系列ｗ_０，．．．，ｗ_１５のうちの１つのウィンドウの開始時間はタスクの相対開始時間及び相対終了時間のうちの１つに対応し、このウィンドウの終了時間はこの系列のうちの次のウィンドウの開始時間に対応する。図３中、ウィンドウｗ_０の開始時間は第１の映画３０１の相対開始時間に対応し、その終了時間はウィンドウｗ_１の開始時間に対応する。このウィンドウの開始時間は、次に、放送３０３の開始時間に対応し、ウィンドウｗ_２が始まるときに終了する。このウィンドウは、ニュース放送３０５が終了するときに開始する。第１のウィンドウｗ_０は、特別な場合である。このウィンドウの開始時間は、スケジュールされたタスクの実行が開始されねばならない時間に対応する。最も早く開始するタスクが、この時間よりも遅く開始することがある。その場合、最も早く開始するタスクが開始する前に幾らかの余分な時間が存在しうる。すると、ウィンドウｗ_０を用いてモデル化される。ウィンドウはゼロの持続時間を有しうる。１つのタスクの絶対終了時間と他のタスクの絶対開始時間が同じであると決定される場合、１つのタスクの終了時間と他のタスクの開始時間の間のウィンドウはゼロとなる。しかしながら、概念上はこのウィンドウはなお存在し考慮に入れられねばならない。
【００６１】
図３から、幾つかのタスクの処理速度は時間と共に変化することが容易にわかる。例えば、スポーツの生放送イベント３０３の放送は、ウィンドウｗ_２中はビット速度が２倍であり、ウィンドウｗ_３中はその開始ビットレートへ戻る。しかしながら、ニュース放送３０５、３０６、３０７、３０８は一定のビットレートを維持する。
【００６２】
順序付けモジュール２０２は、構築モジュール２０１によって構築される制約条件に基づいて、各タスクについて、相対開始時間、相対終了時間、及びリソースの割当てを決定する。相対的な順序付けは、スケジュール中で使用される値を計算するタイミングモジュール２０３のための入力として使用されるため、理想的には制約条件を満たさねばならない。制約条件を満たさない相対的な順序付けを用いるということは、タイミングモジュール２０３によって行われる計算から導出されるスケジュールが有用でないことを意味する。
【００６３】
各タスクに対するリソースの割当てについても同じことが言える。順序付けモジュール２０２は、この割当てを決定するために任意の方法を、例えばランダム・アルゴリズムをも使用しうるが、関係のある制約条件を満たすことを確実とするために割当てが確かめられることが望ましい。
【００６４】
タイミングモジュール２０３は、各タスクについて、絶対開始時間、絶対終了時間、並びに、時間及び関連付けられるタスク処理速度の集まりを決定するタスクを有する。タイミングモジュール２０３は、入力として、各タスクについて、相対開始時間、相対終了時間、及び、順序付けモジュール２０２０からのリソースの割当てを受け取る。スケジュール２０５を構築するために用いられる上述の情報を決定する間、タイミングモジュール２０３は構築モジュール２０１から受け取る制約条件に対する違反を最小限とするべきであり、全ての制約条件を満たす出力を生成することが理想的である。
【００６５】
タイミングモジュール２０３が上記の情報を決定した後、スケジューラ１００は制約条件に対する違反が生じたか否かを任意に判定しうる。そうであれば、例えば順序付けモジュール２０２を作動させ新しい相対的な順序又は割当てを生成させることにより、タスクについての新しい相対開始時間、タスクについての新しい相対終了時間、及びタスクに対するリソースの新しい割当てのうちの少なくとも１つを決定する。スケジューラ１００は、単純に２つの相対時点又は２つの割当てを入れ替えること、又は順序付けモジュール２０２の元の出力を変化させるために他の技術を適用することができる。これに関しては、ローカル探索アプローチが良い結果を与える。ローカル探索アプローチは、例えば、Ｅ．Ｈ．Ｌ．Ａａｒｔｓ及びＪ．Ｋ． Ｌｅｎｓｔｒａ編集のＬｏｃａｌ Ｓｅａｒｃｈ ｉｎ Ｃｏｍｂｉｎａｔｏｒｉａｌ Ｏｐｔｉｍｉｚａｔｉｏｎ， Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ， １９９７， ＩＳＢＮ ０−４７１−９４８２２−５， ｐｐ． ３６１−４１４のＥ．Ｊ． Ａｎｄｅｒｓｏｎ， Ｃ．Ａ． Ｇｌａｓｓ ａｎｄ Ｃ．Ｎ． Ｐｏｔｔｓによる”Ｍａｃｈｉｎｅ ｓｃｈｅｄｕｌｉｎｇ”に記載されている。部分的なスケジュールを変更するために１つのかかる技術を適用した後、スケジューラ１００は、スケジュール２０５を構築するために使用される新しい情報を得るためにタイミングモジュール２０３を作動させる。
【００６６】
タイミングモジュール２０３は、線形計画法を用いてスケジューリング問題を解いてもよく、そのために線形計画モジュール２０６が設けられる。線形計画法を用いると、ウィンドウｗ_０，．．．，ｗ_１５の絶対長さが決定される。各ウィンドウについて、各ウィンドウのタスク処理速度が計算され、これは各タスクに対して、時間及び関連付けられるタスク処理速度の集まりを作成するための入力となる。解は、構築モジュール２０１によって与えられる制約条件を満たすことが理想的であるが、そうでなくとも制約条件の違反が最小限となるべきである。
【００６７】
順序付けモジュール２０２は、タイミングモジュール２０３にタスクの実行についての相対的な順序を与えると共にタスクに対するリソースの割当てを与える。タイミングモジュール２０３は、タスクの開始時間及び終了時間に対応するウィンドウの系列ｗ_０，．．．，ｗ_１５を生成する。絶対開始時間及び絶対終了時間を決定するために、ウィンドウｗ_０，．．．，ｗ_１５の絶対長さが決定されねばならない。ウィンドウｗ_０，．．．，ｗ_１５の絶対長さがわかると、各タスクについての絶対開始時間及び絶対終了時間は容易に計算されうる。まず、適当な時点ゼロを定義せねばならない。これは、現在時間であっても、スケジュールが実行さえるべき所与の時間であってもよい。この時点ゼロは、ウィンドウｗ_０の開始に対応する。ウィンドウｗ_０，．．．，ｗ_１５の長さは、夫々の絶対開始時間を決定するために使用されうる。ウィンドウｗ_０，．．．，ｗ_１５の開始時間はタスクの開始時間又は終了時間に対応するため、単純にウィンドウ開始時間を適当なタスク開始時間又は終了時間に割り当てるだけで十分である。
【００６８】
順序付けモジュール２０２によって導出される制約条件は、ウィンドウを考慮に入れるために変換されねばならない。実行時間及び先行制約条件のために、ｗ変数に対する線形制約条件は、
【００６９】
【数１２】

の形である。上述の制約条件を組み合わせることにより、任意の行列Ｄと定数のベクトルｄに対してＤｗ≧ｄという系が得られる。
【００７０】
タスク処理限界及び処理能力制約条件について、ｐ変数についての線形制約条件は、
【００７１】
【数１３】

であり、ただし、Ｉ（ｒ）はリソースｒに割り当てられたスケジュールされた活動の添え字であり、活動のボックス外の最小及び最大タスク処理速度はゼロであるよう選定される。上述の制約条件は、各ウィンドウｊ＝０，．．．，１５に対して成り立たねばならない。これにより、任意の行列Ａ_ｊ及び定数のベクトルｅ_ｊについて、π_・ｊは行列πの列を示すとすると、Ａ_ｊπ_{・ ｊ}≧ｅ_ｊという系が得られる。尚、図３中、１６のウィンドウがあるため、以下では、ｊは常にゼロから１５の範囲である。ウィンドウの数が異なる場合、ｊの上限もまた調整されねばならない。
【００７２】
動作のコンテンツ全体に対する制約条件は、ｗ_ｋβ_ｉｋ＋．．．＋ｗ_ｌβ_ｉｌ≧ｃ_ｉと表わすことができ、これにより、πｗ≧ｃという系が生ずる。これは、π変数とｗ変数の間のクロス乗積を与える。
【００７３】
残る制約条件は、時間及びタスク処理速度の絶対値には依存しないため、相対的な時間順序及びリソース割当てが分かっているときに既に調べることができ、従ってこの副次的な問題からは排除されうる。概説するに、副次的な問題は以下の一組の制約条件、
【００７４】
【数１４】

によって定式化されうる。式１の問題は、列発生を伴う線形計画によって解くことができる。列発生は、例えば、Ｓｃｈｒｉｊｖｅｒ， Ｌｉｎｅａｒ ａｎｄ Ｉｎｔｅｇｅｒ Ｐｒｏｇｒａｍｍｉｎｇ， Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ， １９８６， ＩＳＮ ０−４７１−９０８５４−１， ｐｐ． １４７−１４８に記載されている。
【００７５】
問題を解くために、上述の制約条件の組は、以下の式、
【００７６】
【数１５】

と書き換えることができ、各ウィンドウｊに対して、
【００７７】
【数１６】

で表わされる一組の可能なタスク処理速度割当てが導入される。式中、数字８が用いられているのは、８つのスケジュールされたタスク３０１、３０２、３０３、３０４、３０５、３０６、３０７、３０８があるためである。１つのウィンドウにつき１つのタスク処理速度割当てπ_{・ ｊ}∈Ｐ_ｊを考慮する代わりに、全ての可能なタスク処理速度割当てが考慮される。各ウィンドウについて、ここで各ウィンドウｊ＝０，．．．，１５に対して、
【００７８】
【数１７】

を満たさねばならない変数ｗ_ｊｐと、各タスク処理速度割当てｐ∈Ｐ_ｊがある。この問題の解は、
【００７９】
【数１８】

とすることにより、式２の解を容易に決定するために使用されえ、即ち、副次的なウィンドウの幅が加算され、使用されるタスク処理速度の平均がとられる。代入により、この解が式２の第２の不等式を満たすことが明らかである。更に、構築されたπ_{・ ｊ}は凸集合Ｐ_ｊの要素の凸組合せであるため、この式の第１の不等式もまた満たされ、π_{・ ｊ}自体もまたＰ_ｊの要素である。従って、Ａ_ｊπ_{・ ｊ}≧ｅ_ｊが成り立つ。
【００８０】
式３を解くためには、各集合Ｐ_ｊが無数の要素を含むため、無数の変数ｗ_ｊｐが決定されねばならない。ポリトープＰ_ｊの端点に対して、一般性を失うことのない制約条件を課すことができるが、それでもやはり対応する線形計画表のためにあまりにも多くの変数及びあまりにも多くの列を発生させることを必要とする。これは、各ウィンドウｊに対して
【００８１】
【外１】

のみを考慮する列発生技術を用いることによって克服される。部分集合は、初期的には空であり、新しい要素が反復的に追加される。
【００８２】
従って、これにより、
【００８３】
【数１９】

という派生的な問題が与えられ、ここで、任意の時点で利用可能な系を与えるためにペナルティ変数ｘ及びｙが追加されている。初期的には、全てのウィンドウｊに対して
【００８４】
【外２】

であり、上述の系は最適化される。次に、各ウィンドウｗ_ｊは、
【００８５】
【外３】

に追加したときに全体のペナルティーを減少させうるＰ_ｊの要素、即ち上述の系の最適化された表において負の減少された費用を有するかかどうか反復的に調べられる。これは、集合Ｐ_ｊが線形制約条件によって与えられているため、線形計画問題を解くことによって調べられうる。このような要素が存在すれば、その要素は
【００８６】
【外４】

に加えられ、上述の系は再び最適化される。この処理は、全てのウィンドウｗ_ｊに対して改善する要素が存在しなくなるまで繰り返される。結果としての全体のペナルティがゼロであれば、式（３）の解が存在し、ゼロでなければ可能な解は存在しない。
【００８７】
ここで、タスクの開始時間及び終了時間の相対的な順序が、リソース割当てと共に与えられていれば、上述の技術によって、制約条件を満たすか少なくとも制約条件に対する違反を最小限とする絶対開始時間、終了時間、及びタスク処理速度が存在するかどうか判定することが可能である。順序付けモジュール２０２から得られた相対順序又はリソース割当てを、タスクについての新しい相対開始時間、タスクについての新しい終了時間、及び、タスクについての新しいリソース割当てのうちの少なくとも１つを決定することにより変更し、最小の制約条件の違反が減少されうるか、又は、一組のスケジュールされた作動を増加させることが可能であるかを調べることが可能である。これらの変更は小さく、従って副次的な問題において生ずる変更も小さく、絶対的な時間及びタスク処理速度の増分的な計算を可能とする。
【００８８】
スケジューリングモジュール２０４は、タイミングモジュール２０３の出力に基づいてスケジュール２０５を決定する。このスケジュール２０５は、各タスクａに対して決定された開始時間τ_ｓｔ（ａ）及び絶対終了時間τ_ｃｐ（ａ）、時間及び関連するタスク処理速度の集まり（τ_０，π_１，τ_１，π_２，．．．τ_ｍ，π_ｍ）、並びに、各グループｊについてのリソースの割当てρ_ｊ（ａ）を含む。
【００８９】
スケジュール２０５は、人間の監視者に提示されるか、スケジュールに従ってリソース上のタスクを実行するために図１のシステムにおいて自動的に利用されうる。
【図面の簡単な説明】
【図１】本発明によるスケジューラを有する伝送システムを示すブロック図である。
【図２】本発明によるスケジューラを示すブロック図である。
【図３】スケジュールの一例を示す図である。

Claims (10)

1. 複数のリソースを必要とする複数のタスクを実行するスケジュールを決定する方法であって、
   （ａ）各タスクの所与の要件及び各リソースについての所与の制限条件から一組の制約条件を構築する段階と、
   （ｂ）上記一組の制約条件に含まれる制約条件に基づいて、各タスクについて相対開始時間、相対終了時間、及びリソースの割当てを決定する段階と、
   （ｃ）上記タスクについて決定された相対開始時間、相対終了時間、及びリソースの割当てに基づいて、上記一組の制約条件に含まれる制約条件の違反を最小限としつつ、各タスクについて絶対開始時間、絶対終了時間、並びに、時間及び関連付けられるタスク処理速度の集まりを決定する段階と、
   （ｄ）各タスクについて上記決定された絶対開始時間、絶対終了時間、時間及び関連するタスク処理速度の集まり、並びに、上記タスクに対するリソースの割当てを含むスケジュールを決定する段階とを含む方法。
2. 上記段階（ｃ）は、
   ウィンドウの系列、上記系列のうちタスクの相対開始時間及び相対終了時間のうちの一つに対応するウィンドウの開始時間、及び、上記ウィンドウの終了時間であり上記系列のうちの次のウィンドウの開始時間に対応する終了時間を決定する段階と、
   上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、上記系列のうちのウィンドウの絶対長さを決定する段階と、
   上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、各ウィンドウについて、各タスクに対する処理速度を決定し、各タスクについて時間及びそれに基づく関連するタスク処理速度の集まりを生成する段階と、
   各タスクについて、上記ウィンドウの絶対長さから絶対開始時間及び絶対終了時間を決定する段階とを含む、請求項１記載の方法。
3. 上記制約条件に対する違反が生じているか否か判定する段階を更に含み、生じていれば、
   タスクについての新しい相対開始時間、タスクについての新しい相対終了時間、及びタスクについての新しいリソースの割当てのうちの少なくとも一つを決定し、
   上記段階（ｃ）を実行する、請求項１又は２記載の方法。
4. 上記系列のうちのウィンドウの絶対長さを決定する段階は、線形計画問題を解くことによって行われる、請求項２記載の方法。
5. 上記各ウィンドウについて各タスクに対するタスク処理速度を決定する段階は、線形計画問題を解くことによって行われる、請求項２又は４記載の方法。
6. 複数のリソースを必要とする複数のタスクを実行するスケジュールを決定するスケジューラであって、
   各タスクの所与の要件及び各リソースに対する所与の制限から一組の制約条件を構築する構築手段と、
   上記一組の制約条件に含まれる制約条件に基づいて、各タスクについて相対開始時間、相対終了時間及びリソースの割当てを決定する順序づけ手段と、
   上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、上記タスクについて決定された相対開始時間、相対終了時間、及びリソースの割当てに基づいて、各タスクについて絶対開始時間、絶対終了時間、及び時間及び関連付けられるタスク処理速度の集まりを決定するタイミング手段と、
   各タスクについて上記決定された絶対開始時間、絶対終了時間、時間及び関連するタスク処理速度の集まり、並びに、上記タスクに対するリソースの割当てを含むスケジュールを決定するスケジューリング手段とを含むスケジューラ。
7. 上記タイミング手段は、
   ウィンドウの系列、上記系列のうちタスクの相対開始時間及び相対終了時間のうちの一つに対応するウィンドウの開始時間、及び、上記ウィンドウの終了時間であり上記系列のうちの次のウィンドウの開始時間に対応する終了時間を決定し、
   上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、上記系列のうちのウィンドウの絶対長さを決定し、
   上記一組の制約条件に含まれる制約条件に対する違反を最小限としつつ、各ウィンドウについて、各タスクに対する処理速度を決定し、各タスクについて時間及びそれに基づく関連するタスク処理速度の集まりを生成し、
   各タスクについて、上記ウィンドウの絶対長さから絶対開始時間及び絶対終了時間を決定するよう配置される、請求項６記載のスケジューラ。
8. 上記制約条件に対する違反が生じているか否か判定する段階を更に含み、生じていれば、
   タスクについての新しい相対開始時間、タスクについての新しい相対終了時間、及びタスクについての新しいリソースの割当てのうちの少なくとも一つを決定し、
   上記タイミング手段を作動させる、請求項６又は７記載のスケジューラ。
9. 線形計画問題を解くための線形計画手段を更に含む、請求項７記載のスケジューラ。
10. 請求項６乃至９のうちいずれか一項記載のスケジューラと、複数のリソースとを含むシステムであって、
    上記スケジューラから得られるスケジュールに従って上記複数のリソース上でタスクを実行するよう配置されるシステム。