WO2022144973A1

WO2022144973A1 - スケジュール生成装置、スケジュール生成方法及びスケジュール生成プログラム

Info

Publication number: WO2022144973A1
Application number: PCT/JP2020/049139
Authority: WO
Inventors: 知彦東山; 広章高田; 剛曾
Original assignee: 三菱電機株式会社
Priority date: 2020-12-28
Filing date: 2020-12-28
Publication date: 2022-07-07
Also published as: JPWO2022144973A1; TW202226085A; JP7012905B1

Abstract

スケジュール生成装置（１０）は、複数のコアを有するマルチコアプロセッサにおいて複数のタスクを実行するスケジュールを生成する。特性データ取得部（２１）は、複数のタスクそれぞれを実行対象のタスクとした場合のＣｏ－ｒｕｎ影響度であって、実行対象のタスクを単独で実行した場合の実行時間である単独実行時間に対して、実行対象のタスクを他のタスクと同時に実行した場合の実行時間が長くなる度合であるＣｏ－ｒｕｎ影響度を示す特性データを取得する。スケジュール生成部（２２）は、特性データが示す複数のタスクそれぞれについてのＣｏ－ｒｕｎ影響度を考慮して、複数のタスクを実行するスケジュールを生成する。

Description

スケジュール生成装置、スケジュール生成方法及びスケジュール生成プログラム

　本開示は、複数のコアを有するマルチコアプロセッサにおいて複数のタスクを実行するスケジュールを生成する技術に関する。

　リアルタイムシステムは、タスク毎に決められた制限時刻であるデッドラインまでに必ず当該タスクの処理を完了させなければならないという時間的制約を受けたコンピュータシステムである。そのため、リアルタイムシステムでは、それぞれのタスクの実行完了時刻がデッドラインを超過しないように、それぞれのタスクに適切なプロセッサの実行時間を割り当てることが必要である。つまり、デッドラインまでにタスクを完了させる制約であるデッドライン制約を満たすように、それぞれのタスクに適切なプロセッサの実行時間を割り当てることが必要である。このように、タスクに適切なプロセッサの実行時間を割り当てることをリアルタイムスケジューリングと言う。また、以下では、タスクの実行完了時刻がデッドラインを超過することをデッドラインミスと呼ぶ。

　近年リアルタイムシステムに求められる機能の高度化により、リアルタイムシステムにおいてもマルチコアプロセッサが採用されてきている。マルチコアプロセッサを用いて複数のタスクを並列に処理することにより、演算スループットの増加と処理時間の低減とが期待できる。

　従来のマルチコアプロセッサ向けリアルタイムスケジューリングの方法として、タスクの応答時間の累積値を最小にするようなタスクのコア配置を求める技術が存在する（特許文献１参照）。応答時間とはタスクの起動が指示されてから、そのタスクの実行が完了するまでの時間である。この技術では、複数の周期タスクの実行時間と、周期と、デッドラインとを入力とし、全てのタスクの応答時間の累積値を評価値として、評価値が最小となるコア割当てが探索される。

国際公開第２０１１／１０２１９号

　マルチコアプロセッサでは、他コアで同時に実行するプログラムとのコンピュータリソースの競合により、単独で対象のプログラムを実行した場合に比べて対象のプログラムの実行時間が長くなる場合がある。以下では、実行時間が長くなることを、性能劣化と呼ぶ場合がある。
　コンピュータリソースの典型的な例として、共有キャッシュ及びメモリバスが挙げられる。共有キャッシュミスを例に性能劣化のメカニズムを説明する。あるタスクが共有キャッシュを使用することにより、同時に他のコアで実行されるタスクが使用できる共有キャッシュの容量が低下し、キャッシュミスの増加による性能劣化が発生する。

　従来のマルチコアプロセッサ向けリアルタイムスケジューリングでは、他コアで同時にプログラムを実行することによる性能劣化が考慮されておらず、適切なスケジュールが生成できない恐れがあった。
　本開示は、適切なスケジュールを生成可能にすることを目的とする。

　本開示に係るスケジュール生成装置は、
　複数のコアを有するマルチコアプロセッサで複数のタスクを実行するスケジュールを生成するスケジュール生成装置であり、
　前記複数のタスクそれぞれを実行対象のタスクとした場合のＣｏ－ｒｕｎ影響度であって、前記実行対象のタスクを単独で実行した場合の実行時間である単独実行時間に対して、前記実行対象のタスクを他のタスクと同時に実行した場合の実行時間が長くなる度合であるＣｏ－ｒｕｎ影響度を示す特性データを取得する特性データ取得部と、
　前記特性データ取得部によって取得された前記特性データが示す前記複数のタスクそれぞれについての前記Ｃｏ－ｒｕｎ影響度を考慮して、前記複数のタスクを実行するスケジュールを生成するスケジュール生成部と
を備える。

　本開示では、Ｃｏ－ｒｕｎ影響度を考慮して、複数のタスクを実行するスケジュールを生成する。これにより、適切なスケジュールの生成が可能になる。

実施の形態１に係るスケジュール生成システム１００の構成図。実施の形態１に係るスケジュール生成装置１０のハードウェア構成図。実施の形態１に係る計測装置５０のハードウェア構成図。実施の形態１に係るプロセッサ５１の構成例を示す図。実施の形態１に係るスケジュール生成システム１００の動作の説明で用いる用語の説明図。実施の形態１に係る計測装置５０の動作の流れを示すフローチャート。実施の形態１に係る特性データ及びタスク設定情報を示す図。実施の形態１に係る問題生成部２３の動作の流れを示すフローチャート。実施の形態１に係る問題求解部２４の動作の流れを示すフローチャート。実施の形態１に係るスケジュールの例を示す図。実施の形態１に係る効果の説明図。実施の形態３に係るスケジュール生成システム１００の構成図。実施の形態３に係る計測装置５０の動作の流れを示すフローチャート。実施の形態３に係る特性データ及びタスク設定情報を示す図。実施の形態３に係る問題生成部２３の動作の流れを示すフローチャート。実施の形態３におけるセンシティブタスク数のカウント方法の説明図。実行システムで動作する実行時スケジューラの動作の流れを示すフローチャート。実施の形態３に係るテーブル間制約の必要性の説明図。実施の形態３に係るスケジュールの例を示す図。

　実施の形態１．
　＊＊＊構成の説明＊＊＊
　図１を参照して、実施の形態１に係るスケジュール生成システム１００の構成を説明する。
　スケジュール生成システム１００は、スケジュール生成装置１０と、計測装置５０とを備える。スケジュール生成装置１０と計測装置５０とは、伝送路９０を介して接続されている。

　スケジュール生成装置１０は、実行システムのコア数と、タスクの周期及びデッドラインといったタスク設定情報と、計測装置５０で計測された性能特性を示す特性データとを入力として、タスクを実行するスケジュールを生成するコンピュータである。
　スケジュール生成装置１０は、機能構成要素として、特性データ取得部２１と、スケジュール生成部２２とを備える。スケジュール生成部２２は、問題生成部２３と、問題求解部２４とを備える。問題生成部２３は、影響制約生成部２５と、デッドライン制約生成部２６と、コア数制約生成部２７と、目的関数生成部２８とを備える。

　計測装置５０は、スケジュール生成装置１０によってスケジュールが生成される対象のタスクが最終的に実行されるリアルタイムシステムである実行システムと同じ、又は、類似した構成のコンピュータである。計測装置５０は、タスク実行ファイル群を入力として、各タスクのリアルタイムシステムでの性能特性を計測する。
　計測装置５０は、機能構成要素として、実行時間計測部６１と、特性データ計測部６２とを備える。

　図２を参照して、実施の形態１に係るスケジュール生成装置１０のハードウェア構成を説明する。
　スケジュール生成装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信インタフェース１４とのハードウェアを備える。プロセッサ１１は、信号線１５を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

　図３を参照して、実施の形態１に係る計測装置５０のハードウェア構成を説明する。
　計測装置５０は、プロセッサ５１と、メモリ５２と、ストレージ５３と、通信インタフェース５４とのハードウェアを備える。プロセッサ５１は、信号線５５を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

　プロセッサ１１，５１は、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）である。プロセッサ１１，５１は、具体例としては、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。

　メモリ１２，５２は、データを一時的に記憶する記憶装置である。メモリ１２，５２は、具体例としては、ＳＲＡＭ（Ｓｔａｔｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。

　ストレージ１３，５３は、データを保管する記憶装置である。ストレージ１３，５３は、具体例としては、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）である。また、ストレージ１３，５３は、ＳＤ（登録商標，Ｓｅｃｕｒｅ　Ｄｉｇｉｔａｌ）メモリカード、ＣＦ（ＣｏｍｐａｃｔＦｌａｓｈ，登録商標）、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）といった可搬記録媒体であってもよい。

　通信インタフェース１４，５４は、外部の装置と通信するためのインタフェースである。通信インタフェース１４，５４は、具体例としては、Ｅｔｈｅｒｎｅｔ（登録商標）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）、ＨＤＭＩ（登録商標，Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｒｆａｃｅ）のポートである。

　スケジュール生成装置１０の各機能構成要素の機能はソフトウェアにより実現される。ストレージ１３には、スケジュール生成装置１０の各機能構成要素の機能を実現するプログラムが格納されている。このプログラムは、プロセッサ１１によりメモリ１２に読み込まれ、プロセッサ１１によって実行される。これにより、スケジュール生成装置１０の各機能構成要素の機能が実現される。

　計測装置５０の各機能構成要素の機能はソフトウェアにより実現される。ストレージ５３には、計測装置５０の各機能構成要素の機能を実現するプログラムが格納されている。このプログラムは、プロセッサ５１によりメモリ５２に読み込まれ、プロセッサ５１によって実行される。これにより、計測装置５０の各機能構成要素の機能が実現される。

　図４を参照して、実施の形態１に係るプロセッサ５１の構成例を説明する。
　プロセッサ５１は、複数のコア５１１を備える。図４では、プロセッサ５１は、コア５１１－１からコア５１１－ｎのｎ個のコア５１１を備える。また、プロセッサ５１は、各コア５１１が共通して使用する共有キャッシュ５１２を備える。

　なお、計測装置５０は、図３及び図４に示す構成に限定されるものではない。計測装置５０は、マルチコアプロセッサを備えた一般的なリアルタイムシステムの構成であってもよいし、図３及び図４に示す構成を仮想的に備えるシミュレータであってもよい。

　＊＊＊動作の説明＊＊＊
　図５から図１０を参照して、実施の形態１に係るスケジュール生成システム１００の動作を説明する。
　実施の形態１に係るスケジュール生成システム１００の動作手順は、実施の形態１に係るスケジュール生成方法に相当する。また、実施の形態１に係るスケジュール生成システム１００の動作を実現するプログラムは、実施の形態１に係るスケジュール生成プログラムに相当する。

　図５を参照して、実施の形態１に係るスケジュール生成システム１００の動作の説明で用いる用語を説明する。
　実施の形態１では、タスクは一定周期で繰り返し実行される周期タスクであるとする。
　タスクの各周期の実行単位をジョブと呼ぶ。タスクが実行可能な状態になる時刻をリリースタイムと呼ぶ。リリースタイム以降であればその周期に対応するジョブはいつでも実行開始できる。実行開始できるとは、実行システムのプロセッサで処理を開始できることを意味する。実行時間はジョブが実行開始してから、実行完了するまでの時間である。ただし、他のタスク又は割込み等に実行権が移った場合、その時間は実行時間には含まない。タスクの実行時間は各ジョブの実行時間から統計的な処理により一意の値に定められる。ここでは、ジョブの実行時間の最長の値（最悪値）を実行時間とする。各ジョブのデッドラインを示す時刻を絶対デッドラインと呼ぶ。リリースタイムから絶対デッドラインまでの時間を相対デッドラインと呼ぶ。
　なお、実行時間は、最悪値に限らず、パーセンタイル等でもよい。

　図６を参照して、実施の形態１に係る計測装置５０の動作を説明する。
　（ステップＳ１１：処理終了判定処理）
　実行時間計測部６１は、タスク実行ファイル群に含まれる全てのタスクについて計測が完了したか否かを判定する。タスク実行ファイル群は、スケジューリング対象とする全タスクの、実行可能な形式のファイルの集合である。
　実行時間計測部６１は、計測が完了していないタスクが残っている場合には、処理をステップＳ１２に進める。一方、実行時間計測部６１は、全てのタスクについて計測が完了している場合には、処理を終了する。

　（ステップＳ１２：実行時間計測処理）
　実行時間計測部６１は、計測が完了していないタスクを１つ実行対象のタスクとして選択する。実行時間計測部６１は、実行対象のタスクを単独で実行したときの実行時間を単独実行時間として計測する。つまり、実行時間計測部６１は、他のコア５１１で他のタスクを実行することなく、実行対象のタスクだけを実行したときの実行時間を単独実行時間として計測する。実行時間は、周期タスクの１回の実行時間であり、計測されたもののうち最長のもの（最悪実行時間）が用いられる。

　（ステップＳ１３：Ｃｏ－ｒｕｎ選定処理）
　実行時間計測部６１は、ステップＳ１２で選択された実行対象のタスクと、実行対象のタスク以外の１つのタスクとを別々のコア５１１で同時に実行して、実行対象のタスクの実行時間を計測する。同時に実行することを、Ｃｏ－ｒｕｎと呼ぶ。そして、特性データ計測部６２は、実行対象のタスクとＣｏ－ｒｕｎした各タスクについて、実行対象のタスクへの影響度であるＣｏ－ｒｕｎ影響度を計算する。特性データ計測部６２は、Ｃｏ－ｒｕｎ影響度が最も大きかったタスクを計測用のＣｏ－ｒｕｎタスクとして選定する。また、特性データ計測部６２は、最も大きかったＣｏ－ｒｕｎ影響度を、Ｃｏ－ｒｕｎタスク数が１の場合における計算対象のタスクのＣｏ－ｒｕｎ影響度に設定する。

　Ｘ個のタスクとのＣｏ－ｒｕｎ影響度ＲＸは、式（１）で定義される。
（式１）ＲＸ＝Ｘ個のタスクとＣｏ－ｒｕｎ時の実行時間／単独実行時間
　つまり、Ｃｏ－ｒｕｎ影響度は、実行対象のタスクを単独で実行した場合の実行時間である単独実行時間に対して、実行対象のタスクを他のタスクと同時に実行した場合の実行時間が長くなる度合である。
　なお、ステップＳ１３の処理では、Ｃｏ－ｒｕｎするタスク数が１つの場合のＣｏ－ｒｕｎ影響度Ｒ１が計算された。後述するステップＳ１６の処理では、Ｃｏ－ｒｕｎするタスク数が２からコア数－１までのそれぞれについてのＣｏ－ｒｕｎ影響度ＲＸが計算される。

　なお、タスクの特性に応じてＣｏ－ｒｕｎの影響が大きいタスクが異なるため、特性データ計測部６２はタスク毎に計測用のＣｏ－ｒｕｎタスクを選定する必要がある。

　（ステップＳ１４：センシティブタスク判定処理）
　特性データ計測部６２は、ステップＳ１３で選定されたＣｏ－ｒｕｎタスクのＣｏ－ｒｕｎ影響度が閾値以上の場合には、実行対象のタスクをセンシティブタスクと判定する。センシティブタスクは、他のタスクとＣｏ－ｒｕｎした場合に、他のタスクの実行時間が長くなり易いタスクである。センシティブタスクは、具体例としては、共有キャッシュを多く使用するタスクが考えられる。

　ここでは、特性データ計測部６２は、計測用のＣｏ－ｒｕｎタスクとのＣｏ－ｒｕｎ時におけるＣｏ－ｒｕｎ影響度からセンシティブタスクであるか否かを判定した。しかし、特性データ計測部６２は、実行対象のタスクについて、他のタスクそれぞれとのＣｏ－ｒｕｎ時におけるＣｏ－ｒｕｎ影響度の平均値又は中央値等から、実行対象のタスクがセンシティブタスクであるか否かを判定してもよい。
　また、ここでは、特性データ計測部６２は、他タスクからのＣｏ－ｒｕｎの影響を受けやすいタスクは、他タスクへ影響を与えやすいものであると仮定に基づいて、センシティブタスクであるか否かを判定した。しかし、特性データ計測部６２は、他タスクへの影響の与えやすさを改めて測定し、センシティブタスクの判定を行ってもよい。

　（ステップＳ１５：計算終了判定処理）
　実行時間計測部６１は、Ｃｏ－ｒｕｎするタスク数が２からコア数－１までの全てのタスク数について、Ｃｏ－ｒｕｎ影響度の計算が完了したか否かを判定する。
　実行時間計測部６１は、計算が完了していないタスク数が残っている場合には、処理をステップＳ１６に進める。一方、実行時間計測部６１は、全てのタスク数について計算が完了している場合には、処理をステップＳ１１に戻す。

　（ステップＳ１６：影響度計算処理）
　実行時間計測部６１は、計算が完了していないタスク数を対象タスク数として選択する。実行時間計測部６１は、実行対象のタスク以外のタスクから、対象タスク数のタスクの組合せを順に選択し、実行対象のタスクと、選択された組合せに含まれる各タスクとを別々のコア５１１で同時に実行して、実行対象のタスクの実行時間を計測する。
　特性データ計測部６２は、実行対象のタスクとＣｏ－ｒｕｎした組合せのタスクについて、実行対象のタスクへの影響度であるＣｏ－ｒｕｎ影響度を計算する。特性データ計測部６２は、各組合せについてのＣｏ－ｒｕｎ影響度のうち最も大きい影響度を、Ｃｏ－ｒｕｎタスク数が対象タスク数の場合における実行対象のタスクのＣｏ－ｒｕｎ影響度に設定する。

　図７から図１０を参照して、実施の形態１に係るスケジュール生成装置１０のスケジュール生成部２２の動作を説明する。
　以下に説明するスケジュール生成装置１０の動作が実行される前提として、特性データ取得部２１は、単独実行時間と、センシティブタスクの判定結果と、各Ｃｏ－ｒｕｎタスク数についてのＣｏ－ｒｕｎ影響度とを示す特性データを計測装置５０から取得する。また、特性データ取得部２１は、ユーザによって入力装置が操作されること等により入力された、実行システムのコア数と、タスクの周期及びデッドラインといったタスク設定情報とを取得する。
　例えば、特性データとタスク設定情報とは図７に示すような情報である。図７では、Ｐは単独実行時間、Ｄは相対デッドライン、Ｓは周期、ＲＸ（Ｘ＝１～３）はＣｏ－ｒｕｎタスク数がＸの時のＣｏ－ｒｕｎ影響度、Ｓｅｎｓはセンシティブタスク判定結果（Ｙ：センシティブタスク、Ｎ：非センシティブタスク）をそれぞれ意味する。

　スケジュール生成部２２は、特性データ取得部２１によって取得された特性データが示す複数のタスクそれぞれについてのＣｏ－ｒｕｎ影響度を考慮して、複数のタスクを実行するスケジュールを生成する。

　図８を参照して、実施の形態１に係る問題生成部２３の動作を説明する。
　（ステップＳ２１：影響制約生成処理）
　影響制約生成部２５は、最適化問題の解であるスケジューリング設計結果において、あるタスクが各周期にセンシティブタスクとＣｏ－ｒｕｎした回数を取得するための影響反映用制約を生成する。
　具体的には、影響制約生成部２５は、数１１で表される最適化変数εを定義するための影響反映用制約を生成する。制約を生成するとは、線形計画問題求解部（線形計画ソルバ）に対し制約を指定することを意味する。最適化変数とは、線形計画問題において最適化対象となる変数のことである。

　ｉ，ｊは、タスクＩＤである。ｔは、時刻である。ｎ_ｃｏは、Ｃｏ－ｒｕｎするセンシティブタスク数であり、１≦ｎ_ｃｏ≦Ｎ_ｃ－２である。Ｊｓは、センシティブタスクの集合である。Ｎ_ｃは、実行システムのコア数である。Ｚは、タスクｉが時刻ｔで実行されるならば１、実行されないならば０をとる最適化変数である。ε_{ｎｃｏ，ｉ，ｔ}は、時刻ｔでタスクｉとＣｏ－ｒｕｎするセンシティブタスク数がｎ_ｃｏであり、かつ、タスクｉが実行されるならば１、それ以外ならば０をとる最適化変数である。時刻ｔは、時刻を離散化したものであり、整数値をとるとする。時刻を離散化した際の離散化の単位をタイムステップと称する。
　なお、ε_{ｎｃｏ，ｉ，ｔ}におけるｎｃｏは、ｎ_ｃｏを意味する。以下同様に、ｎｃｏが下付き文字の場合にはｎ_ｃｏを意味する。

　数１１は非線形式である。そのため、影響制約生成部２５は、数１２の線形制約式を影響反映用制約として生成し、数１１の性質を持った最適化変数εを規定する。

　φ_{ｎｃｏ，ｉ，ｔ}は、０又は１を満たす最適化変数である。γ_{ｎｃｏ，ｉ，ｔ}は、０又は１を満たす最適化変数である。数１２の式（１）及び式（２）は、数１１における数１３の場合に、ε_{ｎｃｏ，ｉ，ｔ}＝１とする制約を線形式で表したものである。

　数１２の式（３）及び式（４）は、数１１における数１４の場合に、ε_{ｎｃｏ，ｉ，ｔ}＝０とする制約を線形式で表したものである。

　なお、否定記号≠を入力できない線形計画ソルバを使用する場合は、影響制約生成部２５は、以下のように不等号を用いた制約に変換することで、否定記号の制約を表現する。
（変換前）：Ａ≠Ｂ→（変換後）（Ａ＜Ｂ）∧（Ａ＞Ｂ）

　（ステップＳ２２：デッドライン制約生成処理）
　デッドライン制約生成部２６は、影響反映用制約で定義された最適化変数εを用いて、Ｃｏ－ｒｕｎ影響度を考慮した場合に複数のタスクそれぞれがデッドラインまでに処理を完了することを表すデッドライン制約を生成する。言い換えると、デッドライン制約は、複数のタスクそれぞれがセンシティブタスクとＣｏ－ｒｕｎした回数に応じて増加した実行時間を考慮した上で、複数のタスクそれぞれがデッドラインミスを犯さないようにする制約である。
　具体的には、デッドライン制約生成部２６は、数１５に示す線形制約式をデッドライン制約として生成する。

　ｋは、ジョブＩＤである。Ｓ_ｉ，ｋは、タスクｉのｋ番目のリリースタイムである。Ｄ_ｉ，ｋは、タスクｉのｋ番目の絶対デッドラインである。Ｐ_ｉは、タスクｉの単独実行時間である。Ｒ_{ｎｃｏ，ｉ}は、タスクｉのｎ_ｃｏ個のセンシティブタスクとＣｏ－ｒｕｎ時のＣｏ－ｒｕｎ影響度である。なお、リリースタイムＳ_ｉ，ｋ及び絶対デッドラインＤ_ｉ，ｋは、タイムステップの倍数として表われるものとし、これにより整数値となる。

　数１５の式（１）の左辺は、ある周期にタスクｉが実行される時間である。数１５の式（１）の右辺第２項はＣｏ－ｒｕｎによる実行時間増加分に相当する。したがって、数１５の式（１）は、タスクｉの単独実行時間Ｐ_ｉと、Ｃｏ－ｒｕｎ影響度を用いて計算されるＣｏ－ｒｕｎによる実行時間増加分の和以上の実行時間が、タスクｉが実行される時間として割り当てられるという式である。
　数１５の式（１）を不等式としている理由は、Ｃｏ－ｒｕｎ影響度が小数点以下を含み、右辺第２項も小数点以下を含む可能性があるのに対して、左辺は整数であるためである。

　デッドライン制約生成部２６は、必要以上にタスクに実行時間を与えないよう、数１６に示す線形制約式をデッドライン制約に追加してもよい。

　数１５の式（２）は、各周期内でデッドラインを超えた時刻にはタスクが実行されないという式である。

　（ステップＳ２３：コア数制約生成処理）
　コア数制約生成部２７は、実行システムのコア数を超えた並列度でタスクが実行されないことを表すコア数制約を生成する。
　具体的には、コア数制約生成部２７は、数１７に示す線形制約式をコア数制約として生成する。

　Ｎ_Ｔは、スケジューリング対象のタスク数である。

　（ステップＳ２４：目的関数生成処理）
　目的関数生成部２８は、数１８に示すように目的関数を生成する。

　数１８に示す目的関数は、実行時間の総和、すなわちＣＰＵ使用率を最小にする目的関数である。
　目的関数はこれに限定されるものではない。目的関数生成部２８は、例えば、デッドラインまでの余裕時間を最小化する目的関数を生成してもよいし、目的関数自体を生成しなくてもよい。

　図９を参照して、実施の形態１に係る問題求解部２４の動作を説明する。
　（Ｓ３１：求解処理）
　問題求解部２４は、ステップＳ２１で生成された影響反映用制約と、ステップＳ２２で生成されたデッドライン制約と、ステップＳ２３で生成されたコア数制約とを制約条件とし、ステップＳ２４で生成された目的関数を目的関数とする線形計画問題の解を計算する。線形計画問題の解の計算方法については既存の方法を用いればよい。

　（Ｓ３２：解判定処理）
　問題求解部２４は、ステップＳ３１で解が得られたか否かを判定する。
　問題求解部２４は、解が得られた場合には、処理をステップＳ３３に進める。一方、問題求解部２４は、解が得られなかった場合には、処理をステップＳ３４に進める。

　（Ｓ３３：スケジュール出力処理）
　問題求解部２４は、通信インタフェース１４を介して、ステップＳ３１で得られた解、つまりスケジュールを出力する。出力形態としては、コンソールに文字列として出力する形態でもよいし、ファイルに文字列として出力する形態でもよいし、その他の形態でもよい。
　具体例としては、図１０に示すように、問題求解部２４は、各タスクについて時刻毎に実行の有無を示すスケジュールテーブルを出力する。図１０では、タスクと時刻とが交差する欄に〇が示されている場合には、そのタスクがその時刻に実行されることを意味し、空欄が示されている場合には、そのタスクがその時刻に実行されないことを意味する。

　（Ｓ３４：メッセージ出力処理）
　問題求解部２４は、通信インタフェース１４を介して、対象とするタスクセットは実行システムにおいてスケジュールを組むことが不可能であるというメッセージを出力する。出力形態としては、コンソールに文字列として出力する形態でもよいし、ファイルに文字列として出力する形態でもよいし、その他の形態でもよい。

　＊＊＊実施の形態１の効果＊＊＊
　以上のように、実施の形態１に係るスケジュール生成装置１０は、Ｃｏ－ｒｕｎ影響度を考慮して、複数のタスクを実行するスケジュールを生成する。これにより、適切なスケジュールの生成が可能になる。
　より具体的には、実施の形態１に係るスケジュール生成装置１０は、センシティブタスクとのＣｏ－ｒｕｎの影響を反映するための影響反映用制約と、影響反映用制約により反映された影響を考慮した上でデッドラインを守るためのデッドライン制約とを用いる。これにより、Ｃｏ－ｒｕｎタスクにより実行時間が延長してしまう場合でもデッドラインミスを起こさないようなスケジュールを生成することが可能である。

　図１１に示すように、タスクＡは常にコア０で実行され、相対デッドラインが周期と等しい、すなわち次の周期までに処理が完了する必要があるタスクであるとする。図１１では、Ｃｏ－ｒｕｎタスクがコア１で実行されることによる性能劣化により実行時間が増加し、タスクＡにデッドラインミスが生じている。従来のリアルタイムスケジューリング方法は、このようなＣｏ－ｒｕｎタスクとのコンピュータリソース競合により性能が低下することによりデッドラインミスを引き起こす可能性があった。これに対して、実施の形態１に係るスケジュール生成装置１０は、Ｃｏ－ｒｕｎ影響度を考慮するため、このようなデッドラインミスを起こさないようなスケジュールを生成することが可能である。

　＊＊＊他の構成＊＊＊
　＜変形例１＞
　実施の形態１では、スケジュール生成装置１０の各機能構成要素がソフトウェアで実現された。しかし、変形例１として、スケジュール生成装置１０の各機能構成要素はハードウェアで実現されてもよい。この変形例１について、実施の形態１と異なる点を説明する。

　各機能構成要素がハードウェアで実現される場合には、スケジュール生成装置１０は、プロセッサ１１とメモリ１２とストレージ１３とに代えて、電子回路を備える。電子回路は、各機能構成要素と、メモリ１２と、ストレージ１３との機能とを実現する専用の回路である。

　電子回路としては、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ　Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）が想定される。
　各機能構成要素を１つの電子回路で実現してもよいし、各機能構成要素を複数の電子回路に分散させて実現してもよい。

　＜変形例２＞
　変形例２として、一部の各機能構成要素がハードウェアで実現され、他の各機能構成要素がソフトウェアで実現されてもよい。

　プロセッサ１１とメモリ１２とストレージ１３と電子回路とを処理回路という。つまり、各機能構成要素の機能は、処理回路により実現される。

　実施の形態２．
　実施の形態１では、Ｃｏ－ｒｕｎ影響度を正確に反映するように制約式を生成した。実施の形態２は、実施の形態１に比べて制約条件を緩和する点が実施の形態１と異なる。実施の形態２では、この異なる点を説明し、同一の点については説明を省略する。

　＊＊＊動作の説明＊＊＊
　図８のステップＳ２１で影響制約生成部２５は、影響反映用制約として、数１２の式（１）及び式（２）を生成し、式（３）及び式（４）を生成しない。これにより最適化変数γ_{ｎｃｏ，ｉ．ｔ}を不要にすることができる。その結果、最適化問題の求解時間を求解にかかる時間を減らすことが可能である。
　式（３）及び式（４）を生成しないことは、数１１における数１３の場合にε_{ｎｃｏ，ｉ，ｔ}＝０とする制約を無くしたことに相当する。その結果、ε_{ｎｃｏ，ｉ，ｔ}が過大評価される可能性がある。ε_{ｎｃｏ，ｉ，ｔ}が過大評価されると、数１５の式（１）により、Ｃｏ－ｒｕｎの影響が過大評価されることになるが、デッドライン制約又はコア数制約を侵害することは繋がらない。

　＊＊＊実施の形態２の効果＊＊＊
　以上のように、実施の形態２に係るスケジュール生成装置１０は、制約条件を緩和して最適化変数を削減する。これにより、求解にかかる時間を減らすことが可能である。

　実施の形態３．
　実施の形態１，２では、単一のクリティカリティレベル（ＣＬと記載する場合がある）のタスクのみが存在することを想定していた。実施の形態３は、異なるクリティカリティレベルのタスクが存在する点が実施の形態１，２と異なる。実施の形態３では、この異なる点を説明し、同一の点については説明を省略する。
　実施の形態３では、実施の形態１に対して変更を加えた場合を説明する。しかし、実施の形態２に対して変更を加えることも可能である。

　タスク毎にデッドラインミス時の影響度に応じたクリティカリティレベルが設定され、システム内に異なるクリティカリティレベルを持つ複数のタスクを混在させるシステムが存在する。このようなシステムをミックスドクリティカリティシステムと呼び、ミックスドクリティカリティシステム向けのスケジューラビリティ判定手法が提案されている（例えば文献：Ｓａｎｊｏｙ　Ｂａｒｕａｈ，　Ｓｔｅｖｅ　Ｖｅｓｔａｌ，　”Ｓｃｈｅｄｕｌａｂｉｌｉｔｙ　ａｎａｌｙｓｉｓ　ｏｆ　ｓｐｏｒａｄｉｃ　ｔａｓｋｓ　ｗｉｔｈ　ｍｕｌｔｉｐｌｅ　ｃｒｉｔｉｃａｌｉｔｙ　ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）。

　この文献に記載された技術では、システム内のタスク毎に、そのタスクのクリティカリティレベルと、他のクリティカリティレベルとを含めた全てのクリティカリティレベルに対応する最悪実行時間を定義した情報を持つ。これは、各タスクの実行時間がジッタを持つことが想定されており、事前に繰り返し計測した実行時間の範囲内でクリティカリティレベル毎の最悪実行時間が定義される。実行時間はクリティカリティレベルが高いほど大きい値が定義される。つまり、クリティカリティレベルが高いほど悲観的な（長い）最悪実行時間が定義される。

　ミックスドクリティカリティシステム用のタスクスケジュールは、全タスクがあるクリティカリティレベルの実行時間で完了した場合は、そのクリティカリティレベル以上のタスクがデッドライン制約を満たすことを保証するというスケジューリングポリシーを満たす。言い換えると、対象とするタスクのクリティカリティレベルより低いクリティカリティレベルのタスクはデッドラインを満たさなくてもよいということである。

　＊＊＊構成の説明＊＊＊
　図１２を参照して、実施の形態３に係るスケジュール生成システム１００の構成を説明する。
　スケジュール生成システム１００は、スケジュール生成装置１０の問題生成部２３が、テーブル間制約生成部２９を備える点が図１に示すスケジュール生成システム１００と異なる。テーブル間制約生成部２９の機能は、他の機能構成要素と同様に、ソフトウェア又はハードウェアによって実現される。
　また、スケジュール生成装置１０及び計測装置５０に対して、複数のタスクそれぞれについてのクリティカリティレベルを示す情報が入力として与えられる点が図１に示すスケジュール生成システム１００と異なる。

　＊＊＊動作の説明＊＊＊
　図１３から図１９を参照して、実施の形態３に係るスケジュール生成システム１００の動作を説明する。
　図１３を参照して、実施の形態３に係る計測装置５０の動作を説明する。
　ステップＳ４１の処理は、図６のステップＳ１１の処理と同じである。ステップＳ４５からステップＳ４８の処理は、図６のステップＳ１３からステップＳ１６の処理と同じである。

　（ステップＳ４２：レベル判定処理）
　実行時間計測部６１は、計測が完了していないタスクを１つ実行対象のタスクとして選択する。実行時間計測部６１は、実行対象のタスクについてのクリティカリティレベル以上の全てのクリティカリティレベルについて、実行対象のタスクの補正実行時間が決定されたか否かを判定する。
　実行時間計測部６１は、補正実行時間が決定されていないクリティカリティレベルが残っている場合には、処理をステップＳ４３に進める。一方、全てのクリティカリティレベルについて補正実行時間が決定されている場合には、処理をステップＳ４４に進める。

　（ステップＳ４３：第１実行時間決定処理）
　実行時間計測部６１は、実行対象のタスクについてのクリティカリティレベル以上のクリティカリティレベルのうち、補正実行時間が決定されていないクリティカリティレベルを１つ決定対象のクリティカリティレベルとして選択する。実行時間計測部６１は、決定対象のクリティカリティレベルにおいて、実行対象のタスクを単独で実行したときの実行時間を補正実行時間として決定する。
　例えば、実行対象のタスクについてのクリティカリティレベルが２であるとする。また、ここでは、数値が大きいほどクリティカリティレベルが高いとする。この場合には、２以上のクリティカリティレベルについて補正実行時間が決定される。

　（ステップＳ４４：第２実行時間決定処理）
　実行時間計測部６１は、実行対象のタスクについてのクリティカリティレベルよりも低いクリティカリティレベルについて、補正実行時間を０に決定する。

　ここで、各クリティカリティレベルに対応する補正実行時間の決定方法は、以下の（１）（２）の２つの条件を満たせば方法は問わない。（１）補正実行時間はクリティカリティレベルが高いほど長い。つまり、クリティカリティレベルが高いほど悲観的な最悪実行時間が仮定される。（２）タスクのクリティカリティレベルより低いクリティカリティレベルに対応する補正実行時間は０とする。
　したがって、ステップＳ４３では、（１）の条件を満たすように、補正実行時間が決定される。例えば、図６のステップＳ１２のように単独実行時間を計測し、クリティカリティレベル毎の補正係数を乗じて、各クリティカリティレベルについての補正実行時間を決定することが考えられる。

　図１４から図１８を参照して、実施の形態３に係るスケジュール生成装置１０のスケジュール生成部２２の動作を説明する。
　以下に説明するスケジュール生成装置１０の動作が実行される前提として、特性データ取得部２１は、補正実行時間と、センシティブタスクの判定結果と、各Ｃｏ－ｒｕｎタスク数についてのＣｏ－ｒｕｎ影響度とを示す特性データを計測装置５０から取得する。また、特性データ取得部２１は、ユーザによって入力装置が操作されること等により入力された、実行システムのコア数と、タスクの周期とデッドラインと各タスクのクリティカリティレベルといったタスク設定情報とを取得する。
　例えば、特性データとタスク設定情報とは図１４に示すような情報である。図１４では、ＣＬはクリティカリティレベル、ＰＬ（Ｌ＝１～３）は補正実行時間、Ｄはデッドライン、Ｓは周期、ＲＸ（Ｘ＝１～３）はＣｏ－ｒｕｎタスク数がＸの時のＣｏ－ｒｕｎ影響度、Ｓｅｎｓはセンシティブタスク判定結果（Ｙ：センシティブタスク、Ｎ：非センシティブタスク）をそれぞれ意味する。

　図１５を参照して、実施の形態３に係る問題生成部２３の動作を説明する。
　（ステップＳ５１：影響制約生成処理）
　影響制約生成部２５は、数１９で表される最適化変数εを定義するための影響反映用制約を生成する。

　ｌは、クリティカリティレベルである。Ｌ_ｉは、タスクｉのクリティカリティレベルである。Ｚ_{ｉ，ｌ，ｔ}は、クリティカリティレベルがｌのスケジュールテーブルにおいて、タスクｉが時刻ｔで実行されるならば１、実行されないならば０をとる最適化変数である。ε_{ｎｃｏ，ｉ，ｌ，ｔ}は、クリティカリティレベルがｌのスケジュールテーブルにおいて、時刻ｔでタスクｉとＣｏ－ｒｕｎするセンシティブタスク数がｎ_ｃｏであり、かつ、タスクｉが実行されるならば１、それ以外ならば０をとる最適化変数である。

　図１６を参照して、実施の形態３におけるセンシティブタスク数のカウント方法を説明する。
　図１６では、実行システムのコア数は２であり、タスクａのクリティカリティレベルは３、タスクｂのクリティカリティレベルは２、タスクｃのクリティカリティレベルは１であるとする。ここでは、値が大きいほどクリティカリティレベルが高いとする。また、全てタスクはセンシティブタスクであるとする。
　後述する処理では、クリティカリティレベル毎にスケジュール（スケジュールテーブル）が生成され、各クリティカリティレベルについてのスケジュールテーブルで補正実行時間分のタスク実行時間が確保される。

　各時刻でＣｏ－ｒｕｎするセンシティブタスク数は、その時刻において、全クリティカリティレベルについてのスケジュールテーブルの中で実行される可能性があるタスク数でカウントされる。
　例えば、図１６の時刻３において、タスクｃとＣｏ－ｒｕｎするセンシティブタスク数はタスクａの１つとカウントされる。ＣＬ＝１のスケジュールテーブルではタスクｃは時刻３においてタスクａとＣｏ－ｒｕｎしないテーブルとなっている。しかし、タスクａがＣＬ＝３の実行時間を要した場合に時刻３で実行される可能性があるため、タスクａはＣｏ－ｒｕｎタスクとしてカウントされる。
　また、図１６の時刻２では、タスクｃとＣｏ－ｒｕｎする可能性があるのはタスクａとタスクｂの２つである。しかし、この場合でも、後述する実行システムで動作する実行時スケジューラの動作により、コア数以上タスクが同時刻で実行されることはない。よって、数１９の式（２）のように、各時刻でＣｏ－ｒｕｎする可能性のあるタスク数がコア数を超える場合はＣｏ－ｒｕｎするセンシティブタスク数はコア数－１となる。

　数１９の式（１）は非線形式である。そのため、影響制約生成部２５は、数２０の線形制約式を影響反映用制約として生成し、数１９の式（１）の性質を持った最適化変数εを規定する。

　φ_{ｎｃｏ，ｉ，ｌ，ｔ}は、０又は１を満たす最適化変数である。

　同様に、数１９の式（２）は非線形式である。そのため、影響制約生成部２５は、数２１の線形制約式を影響反映用制約として生成し、数１９の式（２）の性質を持った最適化変数εを規定する。

　Ｍ_ｃｏは、他の項の最大値よりも大きな任意の整数である。

　（ステップＳ５２：デッドライン制約生成処理）
　デッドライン制約生成部２６は、数２２に示す線形制約式をデッドライン制約として生成する。

　Ｐ^－ _ｉ，ｌは、タスクｉのクリティカリティレベルがｌに対応する補正実行時間である。なお、Ｐ^－ _ｉ，ｌにおける“^－”は、Ｐの上に－が引かれていることを表している。

　（ステップＳ５３：コア数制約生成処理）
　コア数制約生成部２７は、数２３に示す線形制約式をコア数制約として生成する。

　（ステップＳ５４：目的関数生成処理）
　目的関数生成部２８は、数２４に示すように目的関数を生成する。

　数２４に示す目的関数は、実行時間の総和、すなわちＣＰＵ使用率を最小にする目的関数である。
　目的関数はこれに限定されるものではない。目的関数生成部２８は、最低クリティカリティレベルのスケジュールテーブルのＣＰＵ使用率を最小化してもよい。これは最低クリティカリティレベルに対応するＣＰＵ使用率が最頻であるという仮定に基づき、実効的なＣＰＵ使用率を最大にすることを目的としている。また、目的関数生成部２８は、例えば、デッドラインまでの余裕時間を最小化する目的関数を生成してもよいし、目的関数自体を生成しなくてもよい。

　（ステップＳ５５：テーブル間制約生成処理）
　テーブル間制約生成部２９は、各クリティカリティレベルのスケジュール間の整合性をとるための制約であるテーブル間制約を生成する。
　具体的には、テーブル間制約生成部２９は、数２５に示す線形制約式をテーブル間制約として生成する。

　ｌ_１，ｌ_２は、あるクリティカリティレベルである。ｔ_１，ｔ_２は、ある時刻である。

　実行時スケジューラの動作を説明した上で、テーブル間制約の役割を説明する。
　実行時スケジューラは、スケジュール生成装置１０によって生成されたスケジュールに従い、実行システムでタスクを実行する際に動作する。図１６に示すように、各クリティカリティレベルについてのスケジュールが生成されるが、実行時スケジューラは、コア数以上タスクが同時刻で実行されないように、どのタスクを実行するかを制御する。

　図１７を参照して、実行システムで動作する実行時スケジューラの動作について説明する。
　実行時スケジューラは、タイムステップ間隔で起動し、ステップＳ６１からステップＳ６３の処理を実行する。
　（ステップＳ６１：タスク特定処理）
　実行時スケジューラは、スケジュール生成装置１０によって生成されたスケジュールを参照し、現在時刻で実行される可能性のあるタスクを特定する。
　図１６のスケジュールテーブルの場合、時刻２で実行される可能性のあるタスクは、タスクａとタスクｂとタスクｃとである。

　（ステップＳ６２：未完了タスク特定処理）
　実行時スケジューラは、ステップＳ６１で特定されたタスクのうち、現在時刻で処理が完了していないタスクを特定する。
　ここでは、タスクの実行時間は実行毎に変動することを想定している。すなわち、ＣＬ＝３又はＣＬ＝２に対応する実行時間の場合、タスクａ及びタスクｂは時刻２では処理が完了していない。また、ＣＬ＝１に対応する実行時間の場合、タスクａ及びタスクｂは時刻１で処理が完了している。

　（ステップＳ６３：実行件付与処理）
　実行時スケジューラは、ステップＳ６２で特定されたタスクのうち、クリティカリティレベルが高いタスクから順に実行権を与える。
　ステップＳ６２で特定されたタスクがコア数以上となる場合、クリティカリティレベルが低いタスクは実行されない可能性がある。しかし、これはミックスドクリティカリティスケジューリングのスケジューリングポリシーに違反しない。

　テーブル間制約の役割を説明する。
　複数のクリティカリティレベルそれぞれを対象のクリティカリティレベルとし、複数のタスクそれぞれを生成対象のタスクとする。テーブル間制約は、対象のクリティカリティレベルよりも低いクリティカリティレベルのスケジュールにおいて生成対象のタスクについての処理が完了するまでの期間に関して、生成対象のタスクについての対象のクリティカリティレベルのスケジュールが、対象のクリティカリティレベルよりも高いクリティカリティレベルのスケジュールと同一になるようにする制約である。

　図１８を参照して、テーブル間制約の必要性を説明する。
　図１８では、数２５に示すテーブル間制約を設けない場合に発生する問題の例が示されている。図１８では、あるタスクのＨｉｇｈ、Ｌｏｗの２つのクリティカリティレベルのスケジュールであるＨｉｇｈレベルテーブルとＬｏｗレベルテーブルとが示されている。
　図１８のスケジュールが生成されると、実行時スケジューラは時刻ｔでこのタスクを実行すべきかどうか判断できない。
　なぜならば、実行する場合、Ｌｏｗレベルテーブルで他のタスクが実行できない可能性がある。その結果、このタスクがＬｏｗレベルに対応する実行時間（図１８では３タイムステップ）で完了した場合でも、他のタスクがデッドラインミスする可能性がある。つまり、本来実行しなくてもよかったタスクを実行したことにより、他のタスクがデッドラインミスをする可能性がある。これはミックスドクリティカリティスケジューリングのスケジューリングポリシーに違反する。
　一方、実行しない場合、このタスクがＨｉｇｈレベルに対応する実行時間（図１８では６タイムステップ）で完了した場合には、Ｈｉｇｈレベル絶対デッドラインを超過してしまう。時刻ｔで実行しないので、Ｈｉｇｈレベル絶対デッドラインまでに６タイムステップ分の実行時間を確保できなくなるためである。これもミックスドクリティカリティスケジューリングのスケジューリングポリシーに違反する。
　そこで、数２５に示すテーブル間制約を設定し、各周期にて、Ｌｏｗレベルテーブルでの実行完了以前は、全てＨｉｇｈレベルテーブルと同一スケジュールであることを保証する。

　実施の形態１と同様に、問題求解部２４によって線形計画問題の解が計算され、スケジュールが生成される。
　具体例としては、図１９に示すように、クリティカリティレベル毎に、各タスクについて時刻毎に実行の有無を示すスケジュールテーブルを出力する。図１９では、タスクと時刻とが交差する欄に〇が示されている場合には、そのタスクがその時刻に実行されることを意味し、空欄が示されている場合には、そのタスクがその時刻に実行されないことを意味する。

　＊＊＊実施の形態３の効果＊＊＊
　以上のように、実施の形態３に係るスケジュール生成装置１０は、異なるクリティカリティレベルのタスクが存在する場合にも、Ｃｏ－ｒｕｎ影響度を考慮して、複数のタスクを実行するスケジュールを生成する。これにより、適切なスケジュールの生成が可能になる。
　より具体的には、実施の形態３に係るスケジュール生成装置１０は、テーブル間制約を用いて、クリティカリティレベル毎のスケジュールの整合性を持たせる。これにより、Ｃｏ－ｒｕｎ影響度を考慮しつつ、ミックスドクリティカリティスケジューリングのスケジューリングポリシーを満たすスケジュールを生成することが可能である。

　なお、以上の説明における「部」を、「回路」、「工程」、「手順」、「処理」又は「処理回路」に読み替えてもよい。

　以上、本開示の実施の形態及び変形例について説明した。これらの実施の形態及び変形例のうち、いくつかを組み合わせて実施してもよい。また、いずれか１つ又はいくつかを部分的に実施してもよい。なお、本開示は、以上の実施の形態及び変形例に限定されるものではなく、必要に応じて種々の変更が可能である。

　１００　スケジュール生成システム、１０　スケジュール生成装置、１１　プロセッサ、１２　メモリ、１３　ストレージ、１４　通信インタフェース、１５　信号線、２１　特性データ取得部、２２　スケジュール生成部、２３　問題生成部、２４　問題求解部、２５　影響制約生成部、２６　デッドライン制約生成部、２７　コア数制約生成部、２８　目的関数生成部、２９　テーブル間制約生成部、５０　計測装置、５１　プロセッサ、５１１　コア、５１２　共有キャッシュ、５２　メモリ、５３　ストレージ、５４　通信インタフェース、５５　信号線、６１　実行時間計測部、６２　特性データ計測部、９０　伝送路。

Claims

　複数のコアを有するマルチコアプロセッサで複数のタスクを実行するスケジュールを生成するスケジュール生成装置であり、
　前記複数のタスクそれぞれを実行対象のタスクとした場合のＣｏ－ｒｕｎ影響度であって、前記実行対象のタスクを単独で実行した場合の実行時間である単独実行時間に対して、前記実行対象のタスクを他のタスクと同時に実行した場合の実行時間が長くなる度合であるＣｏ－ｒｕｎ影響度を示す特性データを取得する特性データ取得部と、
　前記特性データ取得部によって取得された前記特性データが示す前記複数のタスクそれぞれについての前記Ｃｏ－ｒｕｎ影響度を考慮して、前記複数のタスクを実行するスケジュールを生成するスケジュール生成部と
を備えるスケジュール生成装置。
　前記特性データは、前記複数のコアにおけるコア数より少ない個数それぞれを対象の個数とした場合の前記実行対象のタスクについての前記Ｃｏ－ｒｕｎ影響度であって、前記単独実行時間に対して、前記実行対象のタスクを前記対象の個数のタスクと同時に実行した場合の実行時間が長くなる度合であるＣｏ－ｒｕｎ影響度を示す
請求項１に記載のスケジュール生成装置。
　前記スケジュール生成部は、前記Ｃｏ－ｒｕｎ影響度を考慮した場合に前記複数のタスクがデッドラインまでに処理を完了することを表すデッドライン制約を含む線形計画問題を解くことにより、前記スケジュールを生成する
請求項１又は２に記載のスケジュール生成装置。
　前記デッドライン制約は、前記複数のタスクそれぞれを制約対象のタスクとして、前記制約対象のタスクについての前記単独実行時間と、前記Ｃｏ－ｒｕｎ影響度により増加する実行時間との和以上の時間を、前記制約対象のタスクに割り当てるという制約と、デッドラインよりも後の時間を、前記制約対象のタスクに割り当てないという制約とを含む
請求項３に記載のスケジュール生成装置。
　前記デッドライン制約は、数１に示す制約である
請求項４に記載のスケジュール生成装置。
　前記デッドライン制約は、数２のように定義された最適化変数εを用いて定義された
請求項５に記載のスケジュール生成装置。
　前記デッドライン制約は、数３のように定義された最適化変数εを用いて定義された
請求項５に記載のスケジュール生成装置。
　前記複数のタスクは、タスク毎にクリティカリティレベルが設定されており、
　前記スケジュール生成部は、クリティカリティレベルが高くなるほど時間が長くなるように前記単独実行時間を補正した補正実行時間を用いて、各クリティカリティレベルを対象のクリティカリティレベルとして、前記対象のクリティカリティレベルについて、前記対象のクリティカリティレベル以上のクリティカリティレベルが設定されたタスクがデッドラインまでに処理を完了するスケジュールを生成する
請求項１又は２に記載のスケジュール生成装置。
　前記スケジュール生成部は、数４に示すデッドライン制約を含む線形計画問題を解くことにより、前記スケジュールを生成する
請求項８に記載のスケジュール生成装置。
　前記スケジュール生成部は、前記複数のタスクそれぞれを生成対象のタスクとして、前記対象のクリティカリティレベルよりも低いクリティカリティレベルのスケジュールにおいて前記生成対象のタスクについての処理が完了するまでの期間に関して、前記生成対象のタスクについての前記対象のクリティカリティレベルのスケジュールを、前記対象のクリティカリティレベルよりも高いクリティカリティレベルのスケジュールと同一に設定する
請求項８又は９に記載のスケジュール生成装置。
　複数のコアを有するマルチコアプロセッサで複数のタスクを実行するスケジュールを生成するスケジュール生成方法であり、
　特性データ取得部が、前記複数のタスクそれぞれを実行対象のタスクとした場合のＣｏ－ｒｕｎ影響度であって、前記実行対象のタスクを単独で実行した場合の実行時間である単独実行時間に対して、前記実行対象のタスクを他のタスクと同時に実行した場合の実行時間が長くなる度合であるＣｏ－ｒｕｎ影響度を示す特性データを取得し、
　スケジュール生成部が、前記特性データが示す前記複数のタスクそれぞれについての前記Ｃｏ－ｒｕｎ影響度を考慮して、前記複数のタスクを実行するスケジュールを生成するスケジュール生成方法。
　複数のコアを有するマルチコアプロセッサで複数のタスクを実行するスケジュールを生成するスケジュール生成プログラムであり、
　前記複数のタスクそれぞれを実行対象のタスクとした場合のＣｏ－ｒｕｎ影響度であって、前記実行対象のタスクを単独で実行した場合の実行時間である単独実行時間に対して、前記実行対象のタスクを他のタスクと同時に実行した場合の実行時間が長くなる度合であるＣｏ－ｒｕｎ影響度を示す特性データを取得する特性データ取得処理と、
　前記特性データ取得処理によって取得された前記特性データが示す前記複数のタスクそれぞれについての前記Ｃｏ－ｒｕｎ影響度を考慮して、前記複数のタスクを実行するスケジュールを生成するスケジュール生成処理と
を行うスケジュール生成装置としてコンピュータを機能させるスケジュール生成プログラム。