JP3915672B2 - リアルタイムタスク制御装置 - Google Patents
リアルタイムタスク制御装置 Download PDFInfo
- Publication number
- JP3915672B2 JP3915672B2 JP2002334024A JP2002334024A JP3915672B2 JP 3915672 B2 JP3915672 B2 JP 3915672B2 JP 2002334024 A JP2002334024 A JP 2002334024A JP 2002334024 A JP2002334024 A JP 2002334024A JP 3915672 B2 JP3915672 B2 JP 3915672B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- processing amount
- time
- deadline
- execution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、時間的に制約のある複数のタスクのスケジューリングや実行を制御するリアルタイムマルチタスクオペレーティングシステムにおけるタスク制御装置および方法に関する。
【０００２】
【従来の技術】
リアルタイムマルチタスクオペレーティングシステムにおけるリアルタイム制御において、タスクがデッドラインまでに実行できるかを判定する方法として従来より種々の方法が知られている（例えば、特許文献１〜３参照。）。
【０００３】
特許文献１には、図１０に示す構成をとり、タスクを実行する直前において、現在時刻と実行直前のタスクの最悪実行時間（計測などにより求める実行（処理）時間の最悪値）を加算し、それがデッドラインよりも早ければそのタスクはデッドラインまでに実行できると判定する一方、デッドラインよりも遅ければデッドラインまでに実行できないと判定する方法が示されている。このように特許文献１の方法は、実行する直前のタスクのみに注目した方法である。
【０００４】
また、特許文献２には、デッドライン判定部の構成に関して図示されていないが、上述のように特許文献１においては実行する直前のタスクに対して判定するのに対し、特許文献２の方法は、現在実行可能状態のタスクの全てに対してデッドラインまでに実行できるかを判定する方法である。
【０００５】
また、特許文献３では、図１１に示す構成をとり、データベースに平均ＣＰＵ効率を記憶し、起動しているタスクの平均ＣＰＵ効率の加算結果が、ｎ（２1/n―１）（ｎ：タスク数）以下であれば全てのタスクがデッドラインまでに実行できると判定する一方、これ以上であればデッドラインまでに実行できないタスクがあると判定している。
【０００６】
【特許文献１】
特開平８−２７２６２７号公報
【特許文献２】
特開平８−５５０３６号公報
【特許文献３】
特開平１０−２４０５４８号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、これら上記３つの方式のうち特許文献１と特許文献２に記載の方法では、実行直前のタスクや、実行可能状態のタスクのみで判定が行われており、起動が予想されるタスクを考慮していないため、判定精度が落ちると考えられる。したがって、結果的にデッドラインまでに実行できないという判定がなされるタイミングが遅れる。この判定がなされるタイミングが遅れるとＱｏＳ制御の余地が狭まる（例えば重要なタスクをＱｏＳ制御しなければいけなくなる）可能性が高まり、処理内容や処理結果の品質が落ちるという問題がある。
【０００８】
また、特許文献３では、タスクが周期的に起動するタスクである周期タスクであることを前提にしており、非周期に起動するタスクである非周期タスクを扱う場合、周期的に起動しないにも関わらず周期的に起動した場合と同様にＣＰＵを使用すると計算するため大きな誤差となってしまう。そして、本来デッドラインまでに実行できるのにもかかわらず実行できないと判定されて、ＱｏＳ制御が行われることで、処理内容や処理結果の品質が落ちるという問題がある。
【０００９】
上記課題を具体例を用いて説明する。タスク数が３で、タスクＡ，タスクＢ，タスクＣがあり、タスクＡとタスクＢを周期タスク、タスクＣを非周期タスクとする。また、タスクＡは、周期＝デッドライン、タスクＢは、周期≠デッドラインである。（当然タスクＣも周期≠デッドラインである。）図５（ａ）にタスクＡの起動の様子、図５（ｂ）にタスクＢの起動の様子、図５（ｃ）にタスクＣの起動の様子を示す。
【００１０】
図６（ａ）は、これらの条件において、実際に、デッドラインの近いものから順番に実行する方法で最も効果的にCPUを使える方法であるＥＤＦ（earliest deadline first）法でスケジューリングした例を示したものであり、時刻１６においてタスクＡがデッドラインまでに実行できないというケースを示したものである。
【００１１】
特許文献１に記載の方法では、実行直前のタスクがデッドラインまでに実行できるかを判定するため、図６（ｂ）の「特許文献１の方法」の欄に▲印で示すように、時刻１６においてタスクＡを実行しようした際にデッドライン違反を検出する。そのため、デッドラインに至る時刻１６までは、デッドラインまでに実行できないタスクがあるという判定がなされない。
【００１２】
また、特許文献２に記載の方法では、現在実行可能状態のタスクの全てに対してデッドラインまでに実行できるかを判定する。すなわち、起動しているタスクのデッドラインをみて判定するので、図６（ｂ）の「特許文献２の方法」の欄に▲印で示すように、時刻１４において、タスクＡの残りの実行時間１とデッドライン時刻１６、タスクＢの残りの実行時間２とデッドライン時刻１６という状況から、ＱｏＳ制御が必要であると判定する。このように、時刻１４までは、デッドラインまでに実行できないタスクがあるという判定がなされない。時刻１４で、デッドラインまでに実行できないタスクがあると判定されたとしても、時刻１４でＱｏＳ制御できるのは、タスクＡまたはタスクＢだけである。そのためタスクＡ，タスクＢが重要なタスクであったとしても、ＱｏＳ制御せざるをえないという問題がある。
【００１３】
また、特許文献３に記載の方法では、タスクＡは、周期２、最悪実行時間１なのでタスクＡの平均使用効率は１／２であり、タスクＢは、起動からデッドラインまでの時間６、最悪実行時間３なので、タスクＢの平均使用効率は１／２であり、タスクＣは、起動からデッドラインまでの時間４、最悪実行時間１なので、タスクＣの平均使用効率は、１／４である。したがって、図６（ｂ）の「特許文献３の方法」の欄に▲印で示すように、時刻４、時刻１０において、タスクＣが起動すると、１／２＋１／２＋１／４＞１となり、能力をオーバーし、デッドラインまでに実行できないタスクがあると判定される。しかし、時刻４では、デッドラインまでに実行できないタスクがあると判定されているにも関わらず、実際は、この部分の全てのタスクについてデッドラインまでに実行できている。このように、実際はデッドラインまでに実行できないタスクがないにも関わらず、デッドラインまでに実行できないタスクがあると判定されてＱｏＳ制御がなされてしまい、タスクの処理内容や処理結果の品質が落ちてしまうという問題がある。
【００１４】
そこで、本発明は、できるだけ早い時点で、精度よく、デッドラインまでに実行できないタスクがあることを判定することが可能とすることでＱｏＳ制御できる範囲を広げることができ、重要なタスクのデッドラインを守ることが可能となるリアルタイムタスク制御装置を提供することを目的とする。
【００１５】
【課題を解決するための手段及び発明の効果】
上述した問題点を解決するためになされた請求項１に記載のリアルタイムタスク制御装置は、タスクの制御情報を記憶しており、記憶されたタスク制御情報を用いてタスクの実行順序を制御するタスクスケジューリングを行い、そのスケジューリング結果に基づいて実行するタスクの切り替えを行うことでタスクの実行を制御し、全てのタスクが終了予定時刻であるデッドラインまでに実行を完了できない場合に、負荷量を調整しサービスの品質を制御するＱｏＳ制御を行うリアルタイムタスク制御装置において、タスク制御情報を用いて、判定対象のタスクのデッドラインである判定ポイントまでの起動しているタスクと起動が予測されるタスクの実行必要処理量を見積もり、判定ポイントまでの実行可能処理量を見積もって、この見積もった実行必要処理量と実行可能処理量を比較し、実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定する。そして、この判定結果を用いてＱｏＳ制御を行う。
【００１６】
このように、実行必要処理量を見積もる際に、起動しているタスクだけでなく、起動が予測されるタスクを考慮して判定することで、従来よりも、早い時点で、精度よく、デッドラインまでに実行できないことを検知することができ、ＱｏＳ制御できる範囲を広げることができ、重要なタスクのデッドラインを守ることが可能となる。
【００１７】
この実行必要処理量を見積もる際には、各タスクが判定ポイントまでにどれだけの処理を行う必要があるのかを計算する。その際に、請求項２に示すようにして、起動部分処理量と、予測部分処理量とを分けて計算し、計算された起動部分処理量と予測部分処理量とを各タスクごとに加算して、加算結果の各タスク毎の処理量を、全てのタスク分について足し合わせて、実行必要処理量を求めることができる。
【００１８】
また、タスク制御情報としてタスクの最悪実行時間を記憶しており、起動部分処理量見積手段は、タスクの最悪実行時間からそのタスクが既に実行された時間である実行途中時間を減算することで、タスクの残りの処理量を求める減算手段と、前記判定ポイントと前記デッドラインの大小を比較する比較手段と、前記比較手段による比較の結果、前記判定ポイントよりも前記デッドラインが早い場合はタスクの残りの処理量を起動部分処理量とし、前記判定ポイントよりも前記デッドラインが遅い場合は判定ポイントまでに実行する必要がないため起動部分処理量を"０"とする処理量変換手段とを備えるようにすることができる。
【００１９】
また、請求項４に示すように、予測部分処理量見積手段は、前記判定ポイントから前記デッドラインを引いて、その差分を求める減算手段と、前記減算手段による減算結果が、正の値の場合は当該減算結果を予測時間とし、負の値の場合は予測時間を"０"とし、さらに、当該タスクの属性が非周期タスクの場合は、予測時間が正負に関わらず"０"とする予測時間変換手段と、前記予測時間変換手段によって求められた予測時間を、当該タスクの起動周期で割って周期タスクの繰り返し回数を求める除算手段と、前記除算手段によって求められた繰り返し回数と当該タスクの最悪実行時間を乗算して、当該タスクの予測部分の処理量を求める乗算手段とを備える構成とすることができる。非周期タスクは、繰り返し起動しないので予測部分処理量を"０"とすることで、非周期タスクも精度よく取り扱うことができる。
【００２０】
そして、請求項５に示すように、前記タスク制御情報記憶手段は、タスクの固定情報である最悪実行時間、起動周期、実行許容時間を記憶するタスク固定情報記憶手段と、タスクの動的情報であるデッドライン、実行途中時間を記憶するタスク動的情報記憶手段とを備えるとよい。そして、タスク動的情報記憶手段は、実行されているタスクの実行途中時間をインクリメントしながらその情報を記憶する実行途中時間記憶手段と、タスクのデッドラインをデクリメントしながらその情報を記憶するデッドライン記憶手段とを備えて構成することができる。
【００２１】
また、上述した問題点を解決するためになされたリアルタイムタスク制御方法は、アプリケーションであるタスクを実行するステップと、タスクの情報を設定更新するタスク制御情報更新ステップと、タスクの実行順序をデッドラインの近いものから順番にタスク制御情報を並べ替えるスケジューリングステップと、判定ポイントまでの処理可能処理量である実行可能処理量を見積もる実行可能処理量見積ステップと、判定ポイントまでに行うべき実行必要処理量を見積もる実行必要処理量見積ステップと、前記実行可能処理量見積ステップで見積もられた実行可能処理量と前記実行必要処理量見積ステップで見積もられた実行必要処理量とを比較し、実行可能処理量が、実行必要処理量を上回ればタスクがデッドラインまでに実行できると判定し、逆に実行可能処理量が、実行必要処理量を下回ればデッドラインまでに実行できないと判定するステップと、当該判定の結果、デッドラインまでに実行できない場合、ＱｏＳ制御内容を決定するステップと、全ての判定ポイントで判定したかを確認し、判定が出来ていなければ再度別の判定ポイントで判定をするステップと、タスクの実行順序に変化があった場合、タスクを切り替えるタスク切り替えステップとを備える。
【００２２】
そして、次に示すように、タスクが周期タスクか非周期タスクかを判定するタスク属性判定ステップを備え、タスク属性判定ステップによって周期タスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行う一方、非周期タスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行わないようにすることができる。このようにすれば、「周期タスクのみが起動しているときはデッドラインまでに実行可能で、非周期タスクが起動したときのみデッドラインまでに実行できない」という条件下で用いることで、想定した以上のタスク（非周期タスク）が起動したとき（＝CPU効率が100%を超える可能性のあるとき）のみに前記実行可能処理量見積ステップ以降に記載のステップを行うようにすることができるので、処理が削減できる。
【００２３】
また次に示すように、タスクがＱｏＳ制御可能なタスクか否かを判定するタスク属性判定ステップを備え、タスク属性判定ステップによってＱｏＳ制御可能なタスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行う一方、ＱｏＳ制御不可能なタスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行わないようにすることができる。このようにすれば「所定のタスクをＱｏＳ制御すれば全てのタスクをデッドラインまでに実行できる」という条件下において、ＱｏＳ制御可能なタスク起動時にのみ実行可能処理量見積ステップ以降に記載のステップの処理を行わせることができるので、処理が削減できる。
【００２４】
なお、上述したいずれかのリアルタイムタスク制御方法をコンピュータシステムにて実現する場合、例えば、コンピュータシステム側で起動するプログラムとして備えることができる。このようなプログラムの場合、例えば、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができ、また、ネットワークを介してロードして起動することにより用いることもできる。
【００２５】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。下記の実施例の構成は、ハードウェア、ソフトウェア（プログラム）、あるいは、これらの組み合わせのいずれによっても実現できる。
［第１実施例］
本実施例は、図１に示すように、ＣＰＵ上で動作するタスクの実行を制御するＲＴＯＳ（リアルタイムオペレーティングシステム）に適用した例である。タスクとは、アプリケーション（ソフトウェア）の処理単位である。
【００２６】
このＲＴＯＳは、図１に示すように、タスク制御手段１１と、タスク制御情報記憶手段１２と、タスクスケジューリング手段１３と、時刻カウンタ１４と、実行可能処理量見積手段１５と、実行必要処理量見積手段１６と、処理量比較手段１７と、ＱｏＳ制御手段１８とを備える。
【００２７】
タスク制御情報記憶手段１２は、タスクの起動周期（周期タスクが起動する間隔）、実行許容時間（タスクが起動してから終了しなければいけない時間幅）、最悪実行時間などのタスクの固定パラメータを記憶するタスク固定パラメータ記憶手段５０と、タスクの動的パラメータを記憶するタスク動的パラメータ記憶手段５１とを備える。そしてタスク動的パラメータ記憶手段５１は、タスクの実行中にそのタスクの実行がどこまで進んだかを示す時間であるタスク実行途中時間を記憶する実行途中時間記憶手段６０と、デッドラインを記憶するデッドライン記憶手段６１とを備える。
【００２８】
アプリケーション（タスク）によって別のタスクが起動されると、デッドライン記憶手段６１は、デッドラインに実行許容時間を設定し、実行途中時間記憶手段６０は、実行途中時間に"０"を設定する。時間が経過するにつれ、デッドライン記憶手段６１は、時刻カウンタ１４を用いて、全てのタスクのデッドラインをデクリメントしながら、その結果を記憶し、実行途中時間記憶手段６０は、時刻カウンタ１４を用いて実行中のタスクの実行途中時間をインクリメントしながらその結果を記憶する。
【００２９】
タスクスケジューリング手段１３は、タスク制御情報記憶手段１２に記憶されるデッドラインに基づいてデッドラインの近いものから順に実行されるようにタスク制御情報記憶手段１２の内容を並べ替える。
実行必要処理量見積手段１６は、図２に示すように、各タスク毎に既に起動している部分の処理量を計算する起動部分処理量見積手段２０と、各タスク毎に起動が予想できる周期タスクの処理量を計算する予測部分処理量見積手段２１と、それらを足し合わせタスクの処理量を求める加算手段２２と、全てのタスクの処理量を足し合わせる合算手段２３を備え、ある判定ポイントまでに実行する必要がある処理量である実行必要処理量を求める。起動部分処理量見積手段２０と予測部分処理量見積手段２１についての詳細な構成は、後述する。
【００３０】
実行可能処理量見積手段１５は、ある判定ポイントまでにＣＰＵの１００%の能力を使用できるものとして、判定ポイントまでの時間を実行可能処理量として求める。
処理量比較手段１７は、実行必要処理量見積手段１６で求められる実行必要処理量と、実行可能処理量見積手段１５で求められる実行可能処理量を比較する比較器で構成される。実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定をする。
【００３１】
また、ＱｏＳ制御手段１８は、処理量比較手段１７によって、デッドラインまでに実行できないと判定された時に、どのようなＱｏＳ制御を行うかを決定し、アプリケーション（タスク）１０に対してＱｏＳ制御を行うことを要求する。
タスク制御手段１１は、タスクスケジューリング手段１３がタスク制御情報の順番を並べ替えた結果、最もデッドラインの近いタスクが変わった場合、ＣＰＵがそのタスクを実行するようにタスク１０を切り替える。
【００３２】
次に、起動部分処理量見積手段２０の詳細を述べる。起動部分処理量見積手段２０は、減算手段３０と、比較手段３１と、処理量変換手段３３を備える。減算手段３０は、タスク制御情報記憶手段１２に記憶されるタスクの最悪実行時間から実行途中時間を減算することで、タスクの残りの処理量を求める。比較手段３１は、判定ポイントとデッドラインの大小を比較する。処理量変換手段３３は、上記比較手段３１による比較の結果、判定ポイントよりもデッドラインが早い場合は、タスクの残りの処理量をそのまま起動部分処理量とし、判定ポイントよりもデッドラインが遅い場合は判定ポイントまでに実行する必要のないため、起動部分処理量を"０"とする。
【００３３】
次に、予測部分処理量見積手段２１の詳細を述べる。減算手段４０と予測時間変換手段４１と除算手段４２と乗算手段４３とを備える。減算手段４０は、タスク制御情報記憶手段１２が記憶している判定ポイントからデッドラインを引いて、その差分を求める。予測時間変換手段４１では、その差分が正の値の場合はこの差分を予測時間とし、負の値の場合は判定ポイントのほうがデッドラインより近いため予測する部分は存在しないので予測時間を"０"とする。さらに、タスクの属性が非周期タスクの場合は、非周期タスクは、周期的に起動しないので、上記予測時間が正負に関わらず"０"とする。除算手段４２は、予測時間変換手段４１によって求められた予測時間を起動周期で割ることで、周期タスクが判定ポイントまでに何回繰り返し起動されるかを求める。乗算手段４３は、除算手段４２によって求められた繰り返し回数と、最悪実行時間を乗算することで各タスクの予測部分の処理量を求める。
【００３４】
次に、図３に示すフローチャートを用いて、動作説明を行う。
まず、タスク実行中に（Ｓ１１０（図中、Ｓはステップを示す、以下同じ。））、タスクの起動終了などの制御が要求される。それに伴い、タスクの制御情報の設定変更を行う（Ｓ１２０）。
【００３５】
タスクの情報の設定、更新が行われると、タスクスケジューリング手段１３において、制御情報がデッドラインの早いもの順に並べ替えられる（Ｓ１３０）。タスクのスケジューリングが終わると、実行可能処理量見積手段１５において判定ポイントまでの実行可能処理量を見積もる（Ｓ１４０）。また、起動部分処理量見積手段２０において、既に起動していて、実行状態が分かっている部分に関する処理量の見積もりと、予測部分処理量見積手段２１において予測される処理量の見積もりを行い、これを足し合わせることで実行必要処理量を見積もる（Ｓ１５０）。
【００３６】
判定ポイントまでの実行可能処理量と、実行必要処理量の見積もりが終わると、実行可能処理量と実行必要処理量を比較し、実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し（Ｓ１６０：ＹＥＳ）、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定をする（Ｓ１６０：ＮＯ）。
【００３７】
これを判定ポイントの数だけ繰り返し行う（Ｓ１７０の判定によるＳ１４０〜Ｓ１７０の繰り返し）。
デッドラインまでに実行できないタスクが存在すると判定された場合は（Ｓ１６０：ＮＯ）、ＱｏＳ制御手段１８が、重要性の低いタスクを間引いたり処理量を減らすように制御内容を決定し、その結果にもとづいてＱｏＳ制御を決定し（Ｓ２００）、決定された制御内容に基づき再度タスクの情報の設定、更新を行う（Ｓ１２０）。
【００３８】
全てのタスクがデッドラインまでに実行できると判定されると（Ｓ１７０：ＹＥＳ）、タスク制御手段１１は、最もデッドラインの近いタスクがタスクスケジューリング手段１３により並べ替えられたとき（Ｓ１８０）、そのデッドラインの近いタスクを実行するようにタスクの切り替えを行う（Ｓ１９０）。
【００３９】
以上を繰り返し行う。
また、上記のフローとは別に、タスクの情報の更新も適宜行う必要がある。この処理を図４に示すタスク情報の更新処理のフローチャートを用いて説明する。タスクが、実行されているいないに関わらず、デッドラインは近づいてくるので、時刻カウンタ１４を用いて（Ｓ３１０）、デッドラインを更新（デクリメント）する（Ｓ３２０）。
【００４０】
また、タスクがどこまで実行したのかを把握するため、時刻カウンタ１４を用いて（Ｓ３１０）、実行中のタスクの実行済み時間である実行途中時間を更新（インクリメント）する。
以上から、起動しているタスクと、起動が予測されるタスクがデッドラインを満足できるリアルタイム制御動作が出来る。
【００４１】
次に、本方式の効果を説明する。
発明が解決しようとする課題の欄で示した例（図５、図６）と同じ例で比較する。タスク数３つで、タスクＡ，タスクＢ，タスクＣがあり、タスクＡとタスクＢを周期タスク、タスクＣを非周期タスクとする。また、タスクＡは、周期＝デッドライン、タスクＢは周期≠デッドラインである。（当然タスクCも周期≠デッドラインである。）各タスクの起動の様子を図５に示す。この条件において、実際にＥＤＦ法でスケジューリングして実行した場合のタスクの実行の様子を図６（ａ）に示す。時刻１６においてタスクＡがデッドラインまでに実行できないというケースである。
【００４２】
これを従来法で判定してみると、特許文献１の方法では時刻１６で、特許文献２の方法では時刻１４でデッドラインまでに実行できないタスクがあると判定される。また、特許文献３の方法では、時刻４と時刻１０において、デッドラインまでに実行できないタスクがあると判定されることは、発明が解決しようとする課題の欄で図６（ｂ）を参照して既に示した通りである。
【００４３】
本実施例の方法を用いた場合を、図６（ｂ）の「提案方式」の欄に示す。図６（ａ）の例では、タスクは３つあるので、判定ポイントは、タスクＡの実行可能処理量とタスクＡの実行必要処理量の比較ポイントと、タスクＢの実行可能処理量とタスクＢの実行必要処理量の比較ポイントと、タスクＣの実行可能処理量とタスクＣの実行必要処理量の比較ポイントの３箇所がある。各判定ポイントにおける実行可能処理量と実行必要処理量の計算結果を図７に示す。
【００４４】
図７において「タスク Ａ可」は、実行可能処理量見積手段１５によって求められたタスクＡの実行可能処理量を示し、「タスク Ａ必」は、実行必要処理量見積手段１６によって求められたタスクＡの実行必要処理量を示している。同様に、「タスク Ｂ可」はタスクＢの実行可能処理量、「タスク Ｂ必」はタスクＢの実行必要処理量、「タスク Ｃ可」はタスクＣの実行可能処理量、「タスク
Ｃ必」はタスクＣの実行必要処理量である。
【００４５】
以下に実行必要処理量の計算式とその計算過程を、時刻１０におけるタスクＢの例で示す。
時刻１０における
実行可能処理量 ＝ ６
であり、
時刻１０における
である。
なお、
各タスクの起動部分処理量の合計＝タスクＡの起動部分処理量＋タスクＢの起動部分処理量＋タスクＣの起動部分処理量＝１＋３＋１＝５
各タスクの予測部分処理量の合計＝タスクＡの予測部分処理量＋タスクＢの予測部分処理量＋タスクＣ予測部分処理量＝ 1×(6-2) / 2 ＋ 3×(6-6) / 6 ＋ 0×(6-4) / 4 ＝ 2+0+0 ＝ 2
である。
【００４６】
処理量比較手段１７は、上述したように、タスク毎に、実行可能処理量と実行必要処理量を比較して、実行必要処理量が実行可能処理量よりも大きい場合には、デッドラインまでに実行できないと判定する。図６の処理では、図７に示すように、破線で囲む部分（時刻１０）で、タスクＢの実行必要処理量が実行可能処理量よりも大きくなり、この時刻１０でデッドラインまでに実行できないことが検出される。
【００４７】
よって、図６（ｂ）に示すように、上述した本実施例の提案方式は、従来法（例えば特許文献１、２）に比べて早期にデッドラインまでに実行ができないことが検出できており、また、従来法（例えば特許文献３）に比べ、検出する必要のない部分（時刻４）は検出していない。このように、精度よく、従来より早い時点で、デッドラインまでに実行できないタスクがあることを判定できる。したがってＱｏＳ制御できる範囲を広げることができ、重要なタスクのデッドラインを守ることが可能となる。
［第２実施例］
本実施例は、第１実施例の構成よりも判定回数を減らし、ＲＴＯＳへの負担を軽くする例である。すなわち、周期タスクのみが起動しているときにはデッドラインまでに実行可能する実施例である。本実施例では、第１実施例と同様で図３のフローチャートに代えて図８のフローチャートに示す処理を行う。
【００４８】
図８に示す処理は、基本的に、第１実施例の図３に示して説明した処理と同様であり（同様の処理には同一のステップ番号を付している）、以下では異なる点のみ説明する。図８に示す処理では、Ｓ１３０の後に、Ｓ１３５の処理を行う。Ｓ１３５では、非周期タスクか否かを判定し、非周期タスクであれば（Ｓ１３５：ＹＥＳ）、Ｓ１４０へ移行し、周期タスクであれば（Ｓ１３５：ＮＯ）、Ｓ１１０へ戻る。したがって、非周期タスクが起動したときのみ、デッドラインまでに実行できないか否かの判定を行うこととなり、周期タスクの場合の判定を行う必要がなくなるので、図３のフローと比較して判定回数が削減できる。
［第３実施例］
本実施例は、第１実施例の構成よりも判定回数を減らし、ＲＴＯＳへの負担を軽くする別の例である。
【００４９】
本実施例では、第１実施例と同様で図３のフローチャートに代えて図９のフローチャートに示す処理を行う。図８に示す処理は、基本的に、第１実施例の図３に示して説明した処理と同様であり（同様の処理には同一のステップ番号を付している）、以下では異なる点のみ説明する。本実施例では、図８に示すように、Ｓ１３０の後に、Ｓ１３６の処理を行う。
【００５０】
Ｓ１３６では、ＱｏＳ制御可能なタスクか否かを判定し、ＱｏＳ制御可能なタスクであれば（Ｓ１３７：ＹＥＳ）、Ｓ１４０へ移行し、ＱｏＳ制御可能でないタスクであれば（Ｓ１３７：ＮＯ）、Ｓ１１０へ戻る。したがって、処理を軽減できないタスクはそのまま実行させ、処理を軽減できるもののみその実行前にデッドラインまでに実行できないか否かの判定を行うこととなり、同じＱｏＳ制御の効果を得るのに、図３のフローと比較して判定回数を削減できる。
【図面の簡単な説明】
【図１】実施例のリアルタイムタスク制御装置としてのＲＴＯＳの構成を示すブロック図である。
【図２】図１のＲＴＯＳの構成の一部についてさらに詳細な構成を示すブロック図である。
【図３】第１実施例のＲＴＯＳの処理の流れを示すフローチャートである。
【図４】ＲＴＯＳにおけるタスク情報の更新処理の流れを示すフローチャートである。
【図５】タスクの起動の様子の例を示す説明図である。
【図６】タスクの実行例と、デッドラインまでに実行できないと検出される位置を示す説明図である。
【図７】各判定ポイントにおける実行可能処理量と実行必要処理量の計算結果を示す説明図である。
【図８】第２実施例のＲＴＯＳの処理の流れを示すフローチャートである。
【図９】第３実施例のＲＴＯＳの処理の流れを示すフローチャートである。
【図１０】従来のリアルタイム制御装置の構成を示すブロック図である。
【図１１】従来のリアルタイム制御装置の構成を示すブロック図である。
【符号の説明】
１０…タスク（アプリケーション）
１１…タスク制御手段
１２…タスク制御情報記憶手段
１３…タスクスケジューリング手段
１４…時刻カウンタ
１５…実行可能処理量見積手段
１６…実行必要処理量見積手段
１７…処理量比較手段
１８…ＱｏＳ制御手段
２０…起動部分処理量見積手段
２１…予測部分処理量見積手段
２３…合算手段
３０…減算手段
３１…比較手段
３３…処理量変換手段
４０…減算手段
４１…予測時間変換手段
４２…除算手段
４３…乗算手段
５０…タスク固定パラメータ記憶手段
５１…タスク動的パラメータ記憶手段
６０…実行途中時間記憶手段
６１…デッドライン記憶手段
【発明の属する技術分野】
本発明は、時間的に制約のある複数のタスクのスケジューリングや実行を制御するリアルタイムマルチタスクオペレーティングシステムにおけるタスク制御装置および方法に関する。
【０００２】
【従来の技術】
リアルタイムマルチタスクオペレーティングシステムにおけるリアルタイム制御において、タスクがデッドラインまでに実行できるかを判定する方法として従来より種々の方法が知られている（例えば、特許文献１〜３参照。）。
【０００３】
特許文献１には、図１０に示す構成をとり、タスクを実行する直前において、現在時刻と実行直前のタスクの最悪実行時間（計測などにより求める実行（処理）時間の最悪値）を加算し、それがデッドラインよりも早ければそのタスクはデッドラインまでに実行できると判定する一方、デッドラインよりも遅ければデッドラインまでに実行できないと判定する方法が示されている。このように特許文献１の方法は、実行する直前のタスクのみに注目した方法である。
【０００４】
また、特許文献２には、デッドライン判定部の構成に関して図示されていないが、上述のように特許文献１においては実行する直前のタスクに対して判定するのに対し、特許文献２の方法は、現在実行可能状態のタスクの全てに対してデッドラインまでに実行できるかを判定する方法である。
【０００５】
また、特許文献３では、図１１に示す構成をとり、データベースに平均ＣＰＵ効率を記憶し、起動しているタスクの平均ＣＰＵ効率の加算結果が、ｎ（２1/n―１）（ｎ：タスク数）以下であれば全てのタスクがデッドラインまでに実行できると判定する一方、これ以上であればデッドラインまでに実行できないタスクがあると判定している。
【０００６】
【特許文献１】
特開平８−２７２６２７号公報
【特許文献２】
特開平８−５５０３６号公報
【特許文献３】
特開平１０−２４０５４８号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、これら上記３つの方式のうち特許文献１と特許文献２に記載の方法では、実行直前のタスクや、実行可能状態のタスクのみで判定が行われており、起動が予想されるタスクを考慮していないため、判定精度が落ちると考えられる。したがって、結果的にデッドラインまでに実行できないという判定がなされるタイミングが遅れる。この判定がなされるタイミングが遅れるとＱｏＳ制御の余地が狭まる（例えば重要なタスクをＱｏＳ制御しなければいけなくなる）可能性が高まり、処理内容や処理結果の品質が落ちるという問題がある。
【０００８】
また、特許文献３では、タスクが周期的に起動するタスクである周期タスクであることを前提にしており、非周期に起動するタスクである非周期タスクを扱う場合、周期的に起動しないにも関わらず周期的に起動した場合と同様にＣＰＵを使用すると計算するため大きな誤差となってしまう。そして、本来デッドラインまでに実行できるのにもかかわらず実行できないと判定されて、ＱｏＳ制御が行われることで、処理内容や処理結果の品質が落ちるという問題がある。
【０００９】
上記課題を具体例を用いて説明する。タスク数が３で、タスクＡ，タスクＢ，タスクＣがあり、タスクＡとタスクＢを周期タスク、タスクＣを非周期タスクとする。また、タスクＡは、周期＝デッドライン、タスクＢは、周期≠デッドラインである。（当然タスクＣも周期≠デッドラインである。）図５（ａ）にタスクＡの起動の様子、図５（ｂ）にタスクＢの起動の様子、図５（ｃ）にタスクＣの起動の様子を示す。
【００１０】
図６（ａ）は、これらの条件において、実際に、デッドラインの近いものから順番に実行する方法で最も効果的にCPUを使える方法であるＥＤＦ（earliest deadline first）法でスケジューリングした例を示したものであり、時刻１６においてタスクＡがデッドラインまでに実行できないというケースを示したものである。
【００１１】
特許文献１に記載の方法では、実行直前のタスクがデッドラインまでに実行できるかを判定するため、図６（ｂ）の「特許文献１の方法」の欄に▲印で示すように、時刻１６においてタスクＡを実行しようした際にデッドライン違反を検出する。そのため、デッドラインに至る時刻１６までは、デッドラインまでに実行できないタスクがあるという判定がなされない。
【００１２】
また、特許文献２に記載の方法では、現在実行可能状態のタスクの全てに対してデッドラインまでに実行できるかを判定する。すなわち、起動しているタスクのデッドラインをみて判定するので、図６（ｂ）の「特許文献２の方法」の欄に▲印で示すように、時刻１４において、タスクＡの残りの実行時間１とデッドライン時刻１６、タスクＢの残りの実行時間２とデッドライン時刻１６という状況から、ＱｏＳ制御が必要であると判定する。このように、時刻１４までは、デッドラインまでに実行できないタスクがあるという判定がなされない。時刻１４で、デッドラインまでに実行できないタスクがあると判定されたとしても、時刻１４でＱｏＳ制御できるのは、タスクＡまたはタスクＢだけである。そのためタスクＡ，タスクＢが重要なタスクであったとしても、ＱｏＳ制御せざるをえないという問題がある。
【００１３】
また、特許文献３に記載の方法では、タスクＡは、周期２、最悪実行時間１なのでタスクＡの平均使用効率は１／２であり、タスクＢは、起動からデッドラインまでの時間６、最悪実行時間３なので、タスクＢの平均使用効率は１／２であり、タスクＣは、起動からデッドラインまでの時間４、最悪実行時間１なので、タスクＣの平均使用効率は、１／４である。したがって、図６（ｂ）の「特許文献３の方法」の欄に▲印で示すように、時刻４、時刻１０において、タスクＣが起動すると、１／２＋１／２＋１／４＞１となり、能力をオーバーし、デッドラインまでに実行できないタスクがあると判定される。しかし、時刻４では、デッドラインまでに実行できないタスクがあると判定されているにも関わらず、実際は、この部分の全てのタスクについてデッドラインまでに実行できている。このように、実際はデッドラインまでに実行できないタスクがないにも関わらず、デッドラインまでに実行できないタスクがあると判定されてＱｏＳ制御がなされてしまい、タスクの処理内容や処理結果の品質が落ちてしまうという問題がある。
【００１４】
そこで、本発明は、できるだけ早い時点で、精度よく、デッドラインまでに実行できないタスクがあることを判定することが可能とすることでＱｏＳ制御できる範囲を広げることができ、重要なタスクのデッドラインを守ることが可能となるリアルタイムタスク制御装置を提供することを目的とする。
【００１５】
【課題を解決するための手段及び発明の効果】
上述した問題点を解決するためになされた請求項１に記載のリアルタイムタスク制御装置は、タスクの制御情報を記憶しており、記憶されたタスク制御情報を用いてタスクの実行順序を制御するタスクスケジューリングを行い、そのスケジューリング結果に基づいて実行するタスクの切り替えを行うことでタスクの実行を制御し、全てのタスクが終了予定時刻であるデッドラインまでに実行を完了できない場合に、負荷量を調整しサービスの品質を制御するＱｏＳ制御を行うリアルタイムタスク制御装置において、タスク制御情報を用いて、判定対象のタスクのデッドラインである判定ポイントまでの起動しているタスクと起動が予測されるタスクの実行必要処理量を見積もり、判定ポイントまでの実行可能処理量を見積もって、この見積もった実行必要処理量と実行可能処理量を比較し、実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定する。そして、この判定結果を用いてＱｏＳ制御を行う。
【００１６】
このように、実行必要処理量を見積もる際に、起動しているタスクだけでなく、起動が予測されるタスクを考慮して判定することで、従来よりも、早い時点で、精度よく、デッドラインまでに実行できないことを検知することができ、ＱｏＳ制御できる範囲を広げることができ、重要なタスクのデッドラインを守ることが可能となる。
【００１７】
この実行必要処理量を見積もる際には、各タスクが判定ポイントまでにどれだけの処理を行う必要があるのかを計算する。その際に、請求項２に示すようにして、起動部分処理量と、予測部分処理量とを分けて計算し、計算された起動部分処理量と予測部分処理量とを各タスクごとに加算して、加算結果の各タスク毎の処理量を、全てのタスク分について足し合わせて、実行必要処理量を求めることができる。
【００１８】
また、タスク制御情報としてタスクの最悪実行時間を記憶しており、起動部分処理量見積手段は、タスクの最悪実行時間からそのタスクが既に実行された時間である実行途中時間を減算することで、タスクの残りの処理量を求める減算手段と、前記判定ポイントと前記デッドラインの大小を比較する比較手段と、前記比較手段による比較の結果、前記判定ポイントよりも前記デッドラインが早い場合はタスクの残りの処理量を起動部分処理量とし、前記判定ポイントよりも前記デッドラインが遅い場合は判定ポイントまでに実行する必要がないため起動部分処理量を"０"とする処理量変換手段とを備えるようにすることができる。
【００１９】
また、請求項４に示すように、予測部分処理量見積手段は、前記判定ポイントから前記デッドラインを引いて、その差分を求める減算手段と、前記減算手段による減算結果が、正の値の場合は当該減算結果を予測時間とし、負の値の場合は予測時間を"０"とし、さらに、当該タスクの属性が非周期タスクの場合は、予測時間が正負に関わらず"０"とする予測時間変換手段と、前記予測時間変換手段によって求められた予測時間を、当該タスクの起動周期で割って周期タスクの繰り返し回数を求める除算手段と、前記除算手段によって求められた繰り返し回数と当該タスクの最悪実行時間を乗算して、当該タスクの予測部分の処理量を求める乗算手段とを備える構成とすることができる。非周期タスクは、繰り返し起動しないので予測部分処理量を"０"とすることで、非周期タスクも精度よく取り扱うことができる。
【００２０】
そして、請求項５に示すように、前記タスク制御情報記憶手段は、タスクの固定情報である最悪実行時間、起動周期、実行許容時間を記憶するタスク固定情報記憶手段と、タスクの動的情報であるデッドライン、実行途中時間を記憶するタスク動的情報記憶手段とを備えるとよい。そして、タスク動的情報記憶手段は、実行されているタスクの実行途中時間をインクリメントしながらその情報を記憶する実行途中時間記憶手段と、タスクのデッドラインをデクリメントしながらその情報を記憶するデッドライン記憶手段とを備えて構成することができる。
【００２１】
また、上述した問題点を解決するためになされたリアルタイムタスク制御方法は、アプリケーションであるタスクを実行するステップと、タスクの情報を設定更新するタスク制御情報更新ステップと、タスクの実行順序をデッドラインの近いものから順番にタスク制御情報を並べ替えるスケジューリングステップと、判定ポイントまでの処理可能処理量である実行可能処理量を見積もる実行可能処理量見積ステップと、判定ポイントまでに行うべき実行必要処理量を見積もる実行必要処理量見積ステップと、前記実行可能処理量見積ステップで見積もられた実行可能処理量と前記実行必要処理量見積ステップで見積もられた実行必要処理量とを比較し、実行可能処理量が、実行必要処理量を上回ればタスクがデッドラインまでに実行できると判定し、逆に実行可能処理量が、実行必要処理量を下回ればデッドラインまでに実行できないと判定するステップと、当該判定の結果、デッドラインまでに実行できない場合、ＱｏＳ制御内容を決定するステップと、全ての判定ポイントで判定したかを確認し、判定が出来ていなければ再度別の判定ポイントで判定をするステップと、タスクの実行順序に変化があった場合、タスクを切り替えるタスク切り替えステップとを備える。
【００２２】
そして、次に示すように、タスクが周期タスクか非周期タスクかを判定するタスク属性判定ステップを備え、タスク属性判定ステップによって周期タスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行う一方、非周期タスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行わないようにすることができる。このようにすれば、「周期タスクのみが起動しているときはデッドラインまでに実行可能で、非周期タスクが起動したときのみデッドラインまでに実行できない」という条件下で用いることで、想定した以上のタスク（非周期タスク）が起動したとき（＝CPU効率が100%を超える可能性のあるとき）のみに前記実行可能処理量見積ステップ以降に記載のステップを行うようにすることができるので、処理が削減できる。
【００２３】
また次に示すように、タスクがＱｏＳ制御可能なタスクか否かを判定するタスク属性判定ステップを備え、タスク属性判定ステップによってＱｏＳ制御可能なタスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行う一方、ＱｏＳ制御不可能なタスクであると判定された場合には、前記実行可能処理量見積ステップ以降に記載のステップの処理を行わないようにすることができる。このようにすれば「所定のタスクをＱｏＳ制御すれば全てのタスクをデッドラインまでに実行できる」という条件下において、ＱｏＳ制御可能なタスク起動時にのみ実行可能処理量見積ステップ以降に記載のステップの処理を行わせることができるので、処理が削減できる。
【００２４】
なお、上述したいずれかのリアルタイムタスク制御方法をコンピュータシステムにて実現する場合、例えば、コンピュータシステム側で起動するプログラムとして備えることができる。このようなプログラムの場合、例えば、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができ、また、ネットワークを介してロードして起動することにより用いることもできる。
【００２５】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。下記の実施例の構成は、ハードウェア、ソフトウェア（プログラム）、あるいは、これらの組み合わせのいずれによっても実現できる。
［第１実施例］
本実施例は、図１に示すように、ＣＰＵ上で動作するタスクの実行を制御するＲＴＯＳ（リアルタイムオペレーティングシステム）に適用した例である。タスクとは、アプリケーション（ソフトウェア）の処理単位である。
【００２６】
このＲＴＯＳは、図１に示すように、タスク制御手段１１と、タスク制御情報記憶手段１２と、タスクスケジューリング手段１３と、時刻カウンタ１４と、実行可能処理量見積手段１５と、実行必要処理量見積手段１６と、処理量比較手段１７と、ＱｏＳ制御手段１８とを備える。
【００２７】
タスク制御情報記憶手段１２は、タスクの起動周期（周期タスクが起動する間隔）、実行許容時間（タスクが起動してから終了しなければいけない時間幅）、最悪実行時間などのタスクの固定パラメータを記憶するタスク固定パラメータ記憶手段５０と、タスクの動的パラメータを記憶するタスク動的パラメータ記憶手段５１とを備える。そしてタスク動的パラメータ記憶手段５１は、タスクの実行中にそのタスクの実行がどこまで進んだかを示す時間であるタスク実行途中時間を記憶する実行途中時間記憶手段６０と、デッドラインを記憶するデッドライン記憶手段６１とを備える。
【００２８】
アプリケーション（タスク）によって別のタスクが起動されると、デッドライン記憶手段６１は、デッドラインに実行許容時間を設定し、実行途中時間記憶手段６０は、実行途中時間に"０"を設定する。時間が経過するにつれ、デッドライン記憶手段６１は、時刻カウンタ１４を用いて、全てのタスクのデッドラインをデクリメントしながら、その結果を記憶し、実行途中時間記憶手段６０は、時刻カウンタ１４を用いて実行中のタスクの実行途中時間をインクリメントしながらその結果を記憶する。
【００２９】
タスクスケジューリング手段１３は、タスク制御情報記憶手段１２に記憶されるデッドラインに基づいてデッドラインの近いものから順に実行されるようにタスク制御情報記憶手段１２の内容を並べ替える。
実行必要処理量見積手段１６は、図２に示すように、各タスク毎に既に起動している部分の処理量を計算する起動部分処理量見積手段２０と、各タスク毎に起動が予想できる周期タスクの処理量を計算する予測部分処理量見積手段２１と、それらを足し合わせタスクの処理量を求める加算手段２２と、全てのタスクの処理量を足し合わせる合算手段２３を備え、ある判定ポイントまでに実行する必要がある処理量である実行必要処理量を求める。起動部分処理量見積手段２０と予測部分処理量見積手段２１についての詳細な構成は、後述する。
【００３０】
実行可能処理量見積手段１５は、ある判定ポイントまでにＣＰＵの１００%の能力を使用できるものとして、判定ポイントまでの時間を実行可能処理量として求める。
処理量比較手段１７は、実行必要処理量見積手段１６で求められる実行必要処理量と、実行可能処理量見積手段１５で求められる実行可能処理量を比較する比較器で構成される。実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定をする。
【００３１】
また、ＱｏＳ制御手段１８は、処理量比較手段１７によって、デッドラインまでに実行できないと判定された時に、どのようなＱｏＳ制御を行うかを決定し、アプリケーション（タスク）１０に対してＱｏＳ制御を行うことを要求する。
タスク制御手段１１は、タスクスケジューリング手段１３がタスク制御情報の順番を並べ替えた結果、最もデッドラインの近いタスクが変わった場合、ＣＰＵがそのタスクを実行するようにタスク１０を切り替える。
【００３２】
次に、起動部分処理量見積手段２０の詳細を述べる。起動部分処理量見積手段２０は、減算手段３０と、比較手段３１と、処理量変換手段３３を備える。減算手段３０は、タスク制御情報記憶手段１２に記憶されるタスクの最悪実行時間から実行途中時間を減算することで、タスクの残りの処理量を求める。比較手段３１は、判定ポイントとデッドラインの大小を比較する。処理量変換手段３３は、上記比較手段３１による比較の結果、判定ポイントよりもデッドラインが早い場合は、タスクの残りの処理量をそのまま起動部分処理量とし、判定ポイントよりもデッドラインが遅い場合は判定ポイントまでに実行する必要のないため、起動部分処理量を"０"とする。
【００３３】
次に、予測部分処理量見積手段２１の詳細を述べる。減算手段４０と予測時間変換手段４１と除算手段４２と乗算手段４３とを備える。減算手段４０は、タスク制御情報記憶手段１２が記憶している判定ポイントからデッドラインを引いて、その差分を求める。予測時間変換手段４１では、その差分が正の値の場合はこの差分を予測時間とし、負の値の場合は判定ポイントのほうがデッドラインより近いため予測する部分は存在しないので予測時間を"０"とする。さらに、タスクの属性が非周期タスクの場合は、非周期タスクは、周期的に起動しないので、上記予測時間が正負に関わらず"０"とする。除算手段４２は、予測時間変換手段４１によって求められた予測時間を起動周期で割ることで、周期タスクが判定ポイントまでに何回繰り返し起動されるかを求める。乗算手段４３は、除算手段４２によって求められた繰り返し回数と、最悪実行時間を乗算することで各タスクの予測部分の処理量を求める。
【００３４】
次に、図３に示すフローチャートを用いて、動作説明を行う。
まず、タスク実行中に（Ｓ１１０（図中、Ｓはステップを示す、以下同じ。））、タスクの起動終了などの制御が要求される。それに伴い、タスクの制御情報の設定変更を行う（Ｓ１２０）。
【００３５】
タスクの情報の設定、更新が行われると、タスクスケジューリング手段１３において、制御情報がデッドラインの早いもの順に並べ替えられる（Ｓ１３０）。タスクのスケジューリングが終わると、実行可能処理量見積手段１５において判定ポイントまでの実行可能処理量を見積もる（Ｓ１４０）。また、起動部分処理量見積手段２０において、既に起動していて、実行状態が分かっている部分に関する処理量の見積もりと、予測部分処理量見積手段２１において予測される処理量の見積もりを行い、これを足し合わせることで実行必要処理量を見積もる（Ｓ１５０）。
【００３６】
判定ポイントまでの実行可能処理量と、実行必要処理量の見積もりが終わると、実行可能処理量と実行必要処理量を比較し、実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し（Ｓ１６０：ＹＥＳ）、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定をする（Ｓ１６０：ＮＯ）。
【００３７】
これを判定ポイントの数だけ繰り返し行う（Ｓ１７０の判定によるＳ１４０〜Ｓ１７０の繰り返し）。
デッドラインまでに実行できないタスクが存在すると判定された場合は（Ｓ１６０：ＮＯ）、ＱｏＳ制御手段１８が、重要性の低いタスクを間引いたり処理量を減らすように制御内容を決定し、その結果にもとづいてＱｏＳ制御を決定し（Ｓ２００）、決定された制御内容に基づき再度タスクの情報の設定、更新を行う（Ｓ１２０）。
【００３８】
全てのタスクがデッドラインまでに実行できると判定されると（Ｓ１７０：ＹＥＳ）、タスク制御手段１１は、最もデッドラインの近いタスクがタスクスケジューリング手段１３により並べ替えられたとき（Ｓ１８０）、そのデッドラインの近いタスクを実行するようにタスクの切り替えを行う（Ｓ１９０）。
【００３９】
以上を繰り返し行う。
また、上記のフローとは別に、タスクの情報の更新も適宜行う必要がある。この処理を図４に示すタスク情報の更新処理のフローチャートを用いて説明する。タスクが、実行されているいないに関わらず、デッドラインは近づいてくるので、時刻カウンタ１４を用いて（Ｓ３１０）、デッドラインを更新（デクリメント）する（Ｓ３２０）。
【００４０】
また、タスクがどこまで実行したのかを把握するため、時刻カウンタ１４を用いて（Ｓ３１０）、実行中のタスクの実行済み時間である実行途中時間を更新（インクリメント）する。
以上から、起動しているタスクと、起動が予測されるタスクがデッドラインを満足できるリアルタイム制御動作が出来る。
【００４１】
次に、本方式の効果を説明する。
発明が解決しようとする課題の欄で示した例（図５、図６）と同じ例で比較する。タスク数３つで、タスクＡ，タスクＢ，タスクＣがあり、タスクＡとタスクＢを周期タスク、タスクＣを非周期タスクとする。また、タスクＡは、周期＝デッドライン、タスクＢは周期≠デッドラインである。（当然タスクCも周期≠デッドラインである。）各タスクの起動の様子を図５に示す。この条件において、実際にＥＤＦ法でスケジューリングして実行した場合のタスクの実行の様子を図６（ａ）に示す。時刻１６においてタスクＡがデッドラインまでに実行できないというケースである。
【００４２】
これを従来法で判定してみると、特許文献１の方法では時刻１６で、特許文献２の方法では時刻１４でデッドラインまでに実行できないタスクがあると判定される。また、特許文献３の方法では、時刻４と時刻１０において、デッドラインまでに実行できないタスクがあると判定されることは、発明が解決しようとする課題の欄で図６（ｂ）を参照して既に示した通りである。
【００４３】
本実施例の方法を用いた場合を、図６（ｂ）の「提案方式」の欄に示す。図６（ａ）の例では、タスクは３つあるので、判定ポイントは、タスクＡの実行可能処理量とタスクＡの実行必要処理量の比較ポイントと、タスクＢの実行可能処理量とタスクＢの実行必要処理量の比較ポイントと、タスクＣの実行可能処理量とタスクＣの実行必要処理量の比較ポイントの３箇所がある。各判定ポイントにおける実行可能処理量と実行必要処理量の計算結果を図７に示す。
【００４４】
図７において「タスク Ａ可」は、実行可能処理量見積手段１５によって求められたタスクＡの実行可能処理量を示し、「タスク Ａ必」は、実行必要処理量見積手段１６によって求められたタスクＡの実行必要処理量を示している。同様に、「タスク Ｂ可」はタスクＢの実行可能処理量、「タスク Ｂ必」はタスクＢの実行必要処理量、「タスク Ｃ可」はタスクＣの実行可能処理量、「タスク
Ｃ必」はタスクＣの実行必要処理量である。
【００４５】
以下に実行必要処理量の計算式とその計算過程を、時刻１０におけるタスクＢの例で示す。
時刻１０における
実行可能処理量 ＝ ６
であり、
時刻１０における
なお、
各タスクの起動部分処理量の合計＝タスクＡの起動部分処理量＋タスクＢの起動部分処理量＋タスクＣの起動部分処理量＝１＋３＋１＝５
各タスクの予測部分処理量の合計＝タスクＡの予測部分処理量＋タスクＢの予測部分処理量＋タスクＣ予測部分処理量＝ 1×(6-2) / 2 ＋ 3×(6-6) / 6 ＋ 0×(6-4) / 4 ＝ 2+0+0 ＝ 2
である。
【００４６】
処理量比較手段１７は、上述したように、タスク毎に、実行可能処理量と実行必要処理量を比較して、実行必要処理量が実行可能処理量よりも大きい場合には、デッドラインまでに実行できないと判定する。図６の処理では、図７に示すように、破線で囲む部分（時刻１０）で、タスクＢの実行必要処理量が実行可能処理量よりも大きくなり、この時刻１０でデッドラインまでに実行できないことが検出される。
【００４７】
よって、図６（ｂ）に示すように、上述した本実施例の提案方式は、従来法（例えば特許文献１、２）に比べて早期にデッドラインまでに実行ができないことが検出できており、また、従来法（例えば特許文献３）に比べ、検出する必要のない部分（時刻４）は検出していない。このように、精度よく、従来より早い時点で、デッドラインまでに実行できないタスクがあることを判定できる。したがってＱｏＳ制御できる範囲を広げることができ、重要なタスクのデッドラインを守ることが可能となる。
［第２実施例］
本実施例は、第１実施例の構成よりも判定回数を減らし、ＲＴＯＳへの負担を軽くする例である。すなわち、周期タスクのみが起動しているときにはデッドラインまでに実行可能する実施例である。本実施例では、第１実施例と同様で図３のフローチャートに代えて図８のフローチャートに示す処理を行う。
【００４８】
図８に示す処理は、基本的に、第１実施例の図３に示して説明した処理と同様であり（同様の処理には同一のステップ番号を付している）、以下では異なる点のみ説明する。図８に示す処理では、Ｓ１３０の後に、Ｓ１３５の処理を行う。Ｓ１３５では、非周期タスクか否かを判定し、非周期タスクであれば（Ｓ１３５：ＹＥＳ）、Ｓ１４０へ移行し、周期タスクであれば（Ｓ１３５：ＮＯ）、Ｓ１１０へ戻る。したがって、非周期タスクが起動したときのみ、デッドラインまでに実行できないか否かの判定を行うこととなり、周期タスクの場合の判定を行う必要がなくなるので、図３のフローと比較して判定回数が削減できる。
［第３実施例］
本実施例は、第１実施例の構成よりも判定回数を減らし、ＲＴＯＳへの負担を軽くする別の例である。
【００４９】
本実施例では、第１実施例と同様で図３のフローチャートに代えて図９のフローチャートに示す処理を行う。図８に示す処理は、基本的に、第１実施例の図３に示して説明した処理と同様であり（同様の処理には同一のステップ番号を付している）、以下では異なる点のみ説明する。本実施例では、図８に示すように、Ｓ１３０の後に、Ｓ１３６の処理を行う。
【００５０】
Ｓ１３６では、ＱｏＳ制御可能なタスクか否かを判定し、ＱｏＳ制御可能なタスクであれば（Ｓ１３７：ＹＥＳ）、Ｓ１４０へ移行し、ＱｏＳ制御可能でないタスクであれば（Ｓ１３７：ＮＯ）、Ｓ１１０へ戻る。したがって、処理を軽減できないタスクはそのまま実行させ、処理を軽減できるもののみその実行前にデッドラインまでに実行できないか否かの判定を行うこととなり、同じＱｏＳ制御の効果を得るのに、図３のフローと比較して判定回数を削減できる。
【図面の簡単な説明】
【図１】実施例のリアルタイムタスク制御装置としてのＲＴＯＳの構成を示すブロック図である。
【図２】図１のＲＴＯＳの構成の一部についてさらに詳細な構成を示すブロック図である。
【図３】第１実施例のＲＴＯＳの処理の流れを示すフローチャートである。
【図４】ＲＴＯＳにおけるタスク情報の更新処理の流れを示すフローチャートである。
【図５】タスクの起動の様子の例を示す説明図である。
【図６】タスクの実行例と、デッドラインまでに実行できないと検出される位置を示す説明図である。
【図７】各判定ポイントにおける実行可能処理量と実行必要処理量の計算結果を示す説明図である。
【図８】第２実施例のＲＴＯＳの処理の流れを示すフローチャートである。
【図９】第３実施例のＲＴＯＳの処理の流れを示すフローチャートである。
【図１０】従来のリアルタイム制御装置の構成を示すブロック図である。
【図１１】従来のリアルタイム制御装置の構成を示すブロック図である。
【符号の説明】
１０…タスク（アプリケーション）
１１…タスク制御手段
１２…タスク制御情報記憶手段
１３…タスクスケジューリング手段
１４…時刻カウンタ
１５…実行可能処理量見積手段
１６…実行必要処理量見積手段
１７…処理量比較手段
１８…ＱｏＳ制御手段
２０…起動部分処理量見積手段
２１…予測部分処理量見積手段
２３…合算手段
３０…減算手段
３１…比較手段
３３…処理量変換手段
４０…減算手段
４１…予測時間変換手段
４２…除算手段
４３…乗算手段
５０…タスク固定パラメータ記憶手段
５１…タスク動的パラメータ記憶手段
６０…実行途中時間記憶手段
６１…デッドライン記憶手段
Claims (6)
- タスクの制御情報を記憶するタスク制御情報記憶手段と、
前記タスク制御情報記憶手段に記憶されたタスク制御情報を用いてタスクの実行順序を制御するタスクスケジューリング手段と、
前記タスクスケジューリング手段によるスケジューリング結果に基づいて実行するタスクの切り替えを行うことでタスクの実行を制御するタスク制御手段と、
全てのタスクが終了予定時刻であるデッドラインまでに実行を完了できない場合に、負荷量を調整しサービスの品質を制御するＱｏＳ制御を行うＱｏＳ制御手段と
を備えるリアルタイムタスク制御装置において、
前記タスク制御情報記憶手段に記憶されたタスク制御情報を用いて、判定対象のタスクのデッドラインである判定ポイントまでの起動しているタスクと起動が予測されるタスクの実行必要処理量を見積もる実行必要処理量見積手段と、
前記タスク制御情報記憶手段に記憶されたタスク制御情報を用いて、判定ポイントまでの実行可能処理量を見積もる実行可能処理量見積手段と、
前記実行必要処理量見積手段で見積もった実行必要処理量と、前記実行可能処理量見積手段で見積もった実行可能処理量を比較し、実行可能処理量が実行必要処理量を上回ればタスクはデッドラインまでに実行可能であると判定し、逆に実行必要処理量が実行可能処理量を上回ればデッドラインまでに実行できないと判定をする処理量比較手段と
を備え、
前記ＱｏＳ制御手段は、前記処理量比較手段の判定結果を用いて前記ＱｏＳ制御を行うこと
を特徴とするリアルタイムタスク制御装置。 - 前記実行必要処理量見積手段は、
前記タスク制御情報記憶手段に記憶されたタスク制御情報を用いて、起動しているタスクの処理量を各タスクごとに計算する起動部分処理量見積手段と、
前記タスク制御情報記憶手段のタスク制御情報を用いて、起動が予測できるタスクの処理量を各タスクごとに計算する予測部分処理量見積手段と、
前記起動部分処理量見積手段によって計算された起動部分処理量と、前記予測部分処理量見積手段によって計算された予測部分処理量を各タスクごとに加算する加算手段と、
前記加算手段によって計算された各タスク毎の処理量を、全てのタスク分について足し合わせる合算手段と
を備えることを特徴とする請求項１に記載のリアルタイムタスク制御装置。 - 前記タスク制御情報記憶手段は、前記タスク制御情報としてタスクの最悪実行時間を記憶しており、
前記起動部分処理量見積手段は、
前記タスク制御情報記憶手段に記憶されたタスクの最悪実行時間からそのタスクが既に実行された時間である実行途中時間を減算することで、タスクの残りの処理量を求める減算手段と、
前記判定ポイントと前記デッドラインの大小を比較する比較手段と、
前記比較手段による比較の結果、前記判定ポイントよりも前記デッドラインが早い場合はタスクの残りの処理量を起動部分処理量とし、前記判定ポイントよりも前記デッドラインが遅い場合は判定ポイントまでに実行する必要がないため起動部分処理量を"０"とする処理量変換手段と
を備えることを特徴とする請求項２に記載のリアルタイムタスク制御装置。 - 前記予測部分処理量見積手段は、
前記判定ポイントから前記デッドラインを引いて、その差分を求める減算手段と、
前記減算手段による減算結果が、正の値の場合は当該減算結果を予測時間とし、負の値の場合は予測時間を"０"とし、さらに、当該タスクの属性が非周期タスクの場合は、予測時間が正負に関わらず"０"とする予測時間変換手段と、
前記予測時間変換手段によって求められた予測時間を、当該タスクの起動周期で割って周期タスクの繰り返し回数を求める除算手段と、
前記除算手段によって求められた繰り返し回数と当該タスクの最悪実行時間を乗算して、当該タスクの予測部分の処理量を求める乗算手段と、
を備えることを特徴とする請求項３に記載のリアルタイムタスク制御装置。 - 前記タスク制御情報記憶手段は、
タスクの固定情報である最悪実行時間、起動周期、実行許容時間を記憶するタスク固定情報記憶手段と、
タスクの動的情報であるデッドライン、実行途中時間を記憶するタスク動的情報記憶手段と
を備えることを特徴とする請求項１〜４のいずれかに記載のリアルタイムタスク制御装置。 - 前記タスク動的情報記憶手段は、
実行されているタスクの実行途中時間をインクリメントしながらその情報を記憶する実行途中時間記憶手段と、
タスクのデッドラインをデクリメントしながらその情報を記憶するデッドライン記憶手段と
を備えることを特徴とする請求項５に記載のリアルタイムタスク制御装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002334024A JP3915672B2 (ja) | 2002-11-18 | 2002-11-18 | リアルタイムタスク制御装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002334024A JP3915672B2 (ja) | 2002-11-18 | 2002-11-18 | リアルタイムタスク制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004171142A JP2004171142A (ja) | 2004-06-17 |
| JP3915672B2 true JP3915672B2 (ja) | 2007-05-16 |
Family
ID=32698578
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002334024A Expired - Fee Related JP3915672B2 (ja) | 2002-11-18 | 2002-11-18 | リアルタイムタスク制御装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3915672B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013030908A1 (ja) * | 2011-08-26 | 2013-03-07 | 富士通株式会社 | スケジューリングシステム、データ処理システムおよびスケジューリング方法 |
| JP5791478B2 (ja) * | 2011-11-29 | 2015-10-07 | 三菱電機株式会社 | 情報処理装置 |
| KR102114453B1 (ko) | 2013-07-19 | 2020-06-05 | 삼성전자주식회사 | 모바일 장치 및 그것의 제어 방법 |
-
2002
- 2002-11-18 JP JP2002334024A patent/JP3915672B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004171142A (ja) | 2004-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4367856B2 (ja) | プロセス制御システム及びその制御方法 | |
| US20080162965A1 (en) | Managing performance of a processor in a data processing image | |
| US20080148273A1 (en) | Dynamic voltage scaling scheduling mechanism for sporadic, hard real-time tasks with resource sharing | |
| JPWO2005106623A1 (ja) | Ｃｐｕクロック制御装置、ｃｐｕクロック制御方法、ｃｐｕクロック制御プログラム、記録媒体、及び伝送媒体 | |
| JP2012079124A (ja) | ジョブ分散処理システム、情報処理装置及びプログラム | |
| JP3828112B2 (ja) | 処理の実行を制御するスケジューリング方法およびシステム | |
| US11023245B2 (en) | Serialization floors and deadline driven control for performance optimization of asymmetric multiprocessor systems | |
| US20040039935A1 (en) | Method and device for measuring the execution time of a real task in a real time system | |
| JP3915672B2 (ja) | リアルタイムタスク制御装置 | |
| CN110380982B (zh) | 一种流量控制方法及相关装置 | |
| JPH07168726A (ja) | 電子計算機及びマルチプロセスオペレーティングシステムのスケジューリング方法 | |
| US8555285B2 (en) | Executing a general-purpose operating system as a task under the control of a real-time operating system | |
| US20050182747A1 (en) | Method and system for executing multiple tasks at adaptively controlled resource utilization rates to achieve equal QoS levels | |
| US8185900B2 (en) | Method for the real-time capability analysis of a system by selectively using approximated or actual system expenses for jobs | |
| US7293004B1 (en) | Method for tuning state-based scheduling policies | |
| JP4008699B2 (ja) | 動作中のコンピュータシステムにおけるサービスレベル推定のための方法 | |
| KR20090116184A (ko) | 정보처리장치 및 그 동작주기 변경방법 | |
| JP7263746B2 (ja) | 情報処理装置 | |
| JPH05334102A (ja) | ジョブ実行状況予測装置 | |
| US20100094827A1 (en) | Query Stream Execution Using Priority Gradient Multiprogramming | |
| JPH11259311A (ja) | タスク管理方法 | |
| JP2002318698A (ja) | プロセス制御装置および制御方法 | |
| JP2012133724A (ja) | ジョブネット組替装置、ジョブネット組替プログラム及びジョブネット組替方法 | |
| JP2006172229A (ja) | タスクの動作制御方法、タスクの動作制御システムおよびプログラム | |
| Katcher et al. | Dynamic versus fixed priority scheduling: A case study |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050113 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061107 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061208 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070116 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070129 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110216 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120216 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130216 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140216 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |