JP2007219834A

JP2007219834A - デッドライン監視システムおよびデッドライン監視方法

Info

Publication number: JP2007219834A
Application number: JP2006039595A
Authority: JP
Inventors: Takeshi Sugitani; 猛杉谷
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2006-02-16
Filing date: 2006-02-16
Publication date: 2007-08-30

Abstract

【課題】監視対象タスクのデッドラインオーバーを監視するための処理に要するＣＰＵ負荷を低減しながらデッドラインオーバーを確実に検出するデッドライン監視装置およびデッドライン監視方法を提供すること。
【解決手段】デッドライン監視システム２００は、起床命令に基づいてタスクの起床を行うタスク起床手段１０２と、タスク起床手段１０２により起床させようとするタスクが既に処理を開始している場合に所定の許容段数を有する待ち行列に起床命令を加えるキューイング手段１０３と、キューイング手段１０３により待ち行列に加えられた起床命令の数が所定の許容段数を超えた場合にタスクがデッドラインオーバーになったと判断するデッドラインオーバー判断手段１０５とを備えることを特徴とする。
【選択図】図１

Description

本発明は、デッドライン監視システムおよびデッドライン監視方法に関し、より詳細には、タスクのデッドラインオーバーを監視するための処理に要するＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）負荷を低減しながらもタスクのデッドラインオーバーを確実に検出するデッドライン監視装置およびデッドライン監視方法に関する。

従来のリアルタイムオペレーティングシステム（以下、「ＲＴＯＳ（ＲｅａｌＴｉｍｅＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ）」という。）におけるタスク（ＲＴＯＳが処理するプログラムの実行単位をいう。）のデッドライン監視システムは、監視対象となるタスクの処理に費やした時間と、当該タスクが処理を開始した時刻から処理を終了すべき時刻までの時間（以下、「デッドライン時間」という。）と、を比較して、費やした時間がデッドライン時間を超えた（以下、「デッドラインオーバー」という。）か否かを監視する。

係るデッドライン監視システムは、ＲＴＯＳが標準的に有する機能（システムコール）の他に、デッドラインオーバーを検出するために必要な情報を取得するための特別なタスクを、定期的に、或いは、タスクの切り替え（以下、「ディスパッチ」という。）が発生する度に起床させることにより行われていた。

デッドラインオーバーが発生してタスクが中止されると、それまでに費やしたＣＰＵの処理時間が無駄になり、さらには、他のタスクのデッドラインオーバーを連鎖的に引き起こしてしまう場合もあるので、デッドラインオーバーの発生を防止することは重要であるが、係るデッドラインオーバーの監視は、多大な負荷をＣＰＵに掛けてしまう。

そのため、特許文献１に記載のリアルタイムタスク制御装置は、タスクのディスパッチが発生する度に、ディスパッチされるタスクの残りの所要時間と、現時点からデッドラインまでの時間とを比較し、デッドラインオーバーとなるようならば、そのタスクを事前に終了させることで無駄な処理を防止し、他のタスクが連鎖的にデッドラインオーバーとなるのを抑制しようとする。
特開平５−２４１９０６号公報

しかしながら、特許文献１に記載のリアルタイムタスク制御装置は、デッドラインオーバーの連鎖的な発生を抑制するが、デッドラインオーバー監視のために多大な負荷がＣＰＵに掛かることに変わりはない。また、監視するタスクの数が増大すると、タスク毎に開始時刻の記録、経過時間の算出およびデッドライン時間との比較等を実行しなければならず、監視のための負荷がさらに増大し、監視対象タスクを事前に終了させ易くしてしまう。

係る問題に鑑み、本発明は、監視対象タスクのデッドラインオーバーを監視するための処理に要するＣＰＵ負荷を低減しながらもデッドラインオーバーを確実に検出するデッドライン監視装置およびデッドライン監視方法を提供することを目的とする。

上述の目的を達成するために、第１の発明に係るデッドライン監視システムは、起床命令に基づいてタスクの起床を行うタスク起床手段と、前記タスク起床手段により起床させる前記タスクが処理を開始している場合、所定の許容段数を有する待ち行列に前記起床命令を加えるキューイング手段と、前記キューイング手段により前記待ち行列に加えられた前記起床命令の数が前記所定の許容段数を超えた場合に、前記タスクがデッドラインオーバーになったと判断するデッドラインオーバー判断手段と、を備えることを特徴とする。

また、第２の発明は、第１の発明に係るデッドライン監視システムにおいて、前記起床命令は所定の周期で発せられることを特徴とする。

また、第３の発明に係るデッドライン監視方法は、起床命令に基づいてタスクの起床を行うタスク起床ステップと、前記タスク起床ステップにおいて起床させる前記タスクが処理を開始している場合、所定の許容段数を有する待ち行列に前記起床命令を加えるキューイングステップと、前記キューイングステップにおいて前記待ち行列に加えられた前記起床命令の数が前記所定の許容段数を超えた場合に、前記タスクがデッドラインオーバーになったと判断するデッドラインオーバー判断ステップと、を備えることを特徴とする。

上述の手段により、本発明は、監視対象タスクのデッドラインオーバーを監視するための処理に要するＣＰＵ負荷を低減しながらもデッドラインオーバーを確実に検出するデッドライン監視装置およびデッドライン監視方法を提供することができる。

以下、図面を参照しつつ、いくつかの実施例に分けて、本発明を実施するための最良の形態の説明を行う。

図１は、本発明に係るデッドライン監視システムの構成例を示す図である。デッドライン監視システム２００は、二次記憶装置１、ＣＰＵ２、主記憶装置３を有し、二次記憶装置１は、ＲＴＯＳ１０および監視対象タスク１１を実行するためのプログラムを格納する。

ＲＴＯＳ１０は、デッドライン監視システム２００を備える装置の電源が起動されると、主記憶装置３にロードされ、二次記憶装置１に格納された監視対象タスク１１等を主記憶装置３にロードしながら各種処理を実行する。

デッドライン監視システム２００は、デッドラインオーバーを検出してそのタスクの実行を中断または中止させるシステムであり、例えば、ＲＴＯＳ１０により更新されるＴＣＢ（ＴａｓｋＣｏｎｔｒｏｌＢｌｏｃｋ）の情報に基づいてデッドラインを監視する。

ここで、「ＴＣＢ」とは、タスクの属性情報を格納するための構造体であり、デッドライン時間、タスク状態、優先度、タスク起床周期、キューイング数、キュー段数等の情報を格納する。

タスク状態とは、ＲＴＯＳ１０がタスクの実行順序を決定する（以下、「スケジューリング」という。）際に参照するタスクの状態であり、例えば、実行状態、実行可能状態、待ち状態等がある。

タスクは生成後に起動されると実行可能状態になり、その後、ディスパッチされると、実行可能状態が実行状態に移行し、反対に、より優先度の高いタスクに実行権が奪われると（以下、「プリエンプト」という。）、実行状態が実行可能状態に移行する。また、タスクは実行が終了すると待ち状態に移行し、起床されると、待ち状態が実行可能状態に移行する。なお、デッドライン監視システム２００は、タスクが実行可能状態または実行状態の場合に同じタスクが起床されると、その起床命令を待ち行列（キュー）に格納する。

また、優先度とは、複数のタスクの処理の優先順位を決定するために用いられる値であり、この値を使用してＲＴＯＳ１０は優先度の低いタスクをプリエンプトし、優先度の高いタスクとのディスパッチを行う。

タスク起床周期は、各タスクの起床命令を出す時間間隔であり、キューイング数は、待ち行列に積まれた起床命令の数であり、キュー段数は、待ち行列の許容段数である。

なお、「中断」とは、監視対象のタスクを一旦待ち状態とし、現状のコンテキスト（タスクに関する情報をいう。）を二次記憶装置１の他の領域に待避させ、後に処理を再開できるようにしておくことをいう。また、「中止」とは、実行中のタスクを終了させ、後に処理を再開できないようにすることをいう。

監視対象タスク１１は、アプリケーション毎に準備され、ＲＴＯＳ１０によりデッドライン時間を超えたか否かが監視されるタスクであり、外部割り込みルーチンであるハンドラやＲＴＯＳ１０のタスク起床手段１０２により起床される。

また、ＲＴＯＳ１０は、標準的な機能（システムコール）としてスケジューリング手段１０１、タスク起床手段１０２、キューイング手段１０３、タスク制御情報設定手段１０４およびデッドラインオーバー判断手段１０５を有する。

スケジューリング手段１０１は、実行可能状態となっているタスクの中から次に実行させるタスクを選択するための手段であり、例えば、ＴＣＢの優先度を参照して、次に実行するタスクを選択する。

タスク起床手段１０２は、タスクを起床させるための手段であり、所定のタイミングで、或いは、周期的に、ＲＴＯＳ１０のスケジューリング手段１０１により選択されたタスクを待ち状態から実行可能状態に移行させる。

キューイング手段１０３は、タスク起床手段１０２が起床させようとしたタスクが既に実行状態または実行可能状態である場合に、その起床命令を待ち行列（キュー）に加えるための手段であり、例えば、起床させるタスク毎にキュー段数だけ起床命令を積み上げる（加える）ことができる。格納された起床命令の数がキュー段数を超えた場合、後述のデッドラインオーバー判断手段１０５は、当該タスクによる処理の経過時間がデッドライン時間を超えたとして当該タスクの処理を中止または中断させる。

タスク制御情報設定手段１０４は、ＴＣＢの設定を変更するための手段であり、例えば、ＣＰＵ２の負荷状況に応じてＴＣＢにおける優先度、タスク起床周期およびキュー段数等の設定値を変更する。タスクの起床周期を大きくしてデッドライン監視のために費やされるＣＰＵ２の負荷を小さくしたり、タスクの優先度に応じてデッドライン監視を強化したり、緩和したりすることで、デッドラインの設定を柔軟に行えるようにするためである。

デッドラインオーバー判断手段１０５は、デッドラインオーバー発生の有無を判断するための手段であり、例えば、ＴＣＢに格納されたキューイング数がＴＣＢで設定されたキュー段数を超えた場合に、監視対象タスク１１の処理時間がデッドライン時間を超えたと判断して、監視対象タスク１１の実行を中断または中止させる。

デッドラインオーバー判断手段１０５は、デッドラインオーバーとなった監視対象タスク１１のＴＣＢに格納された優先度をより低い値に変更したり、タスク状態を強制的に待ち状態若しくは終了状態に設定したりすることにより、監視対象タスク１１の実行を中断または中止させる。

また、デッドラインオーバー判断手段１０５は、タスク毎に設定されるデッドライン時間を利用しないので、監視対象タスク１１の処理開始時刻を記憶したり、処理に要した経過時間を算出したり、或いは、経過時間と所定のデッドライン時間とを比較したりする処理を省略させることができ、ＴＣＢのサイズを低減させ、かつ、ＣＰＵ２の負荷を低減させることができる。

なお、スケジューリング手段１０１、タスク起床手段１０２、キューイング手段１０３、タスク制御情報設定手段１０４は、ＲＴＯＳ１０に標準的に備えられるシステムコールであり、ＲＴＯＳ１０上で動作する監視対象タスク１１のようにアプリケーション毎に別途作成する必要が無く、また、デッドラインオーバー判断手段１０５も、既にＴＣＢが標準的に有する情報を利用してデッドラインオーバー発生の有無を判断するので、ＲＴＯＳ１０の標準的な機能として組み込まれてもよい。

次に、図２のフローチャートを参照しながら、デッドライン監視システム２００がデッドラインを監視する処理の流れについて説明する。

最初に、デッドライン監視システム２００は、監視対象のタスクが処理を開始してから、当該タスクのＴＣＢに設定されたタスク起床周期（時間）が経過したか否かを判断する（ステップＳ１）。

タスク起床周期（時間）が経過していない場合には（ステップＳ１のＮＯ）、デッドライン監視システム２００は、タスク起床周期（時間）が経過するまで待機する。タスク起床周期（時間）が経過した場合には（ステップＳ１のＹＥＳ）、タスク起床手段１０２により、監視対象タスク１１に対する起床命令を発する（ステップＳ２：タスク起床ステップ）。

次に、タスク起床手段１０２は、監視対象タスク１１のＴＣＢを参照してタスク状態を判断する（ステップＳ３）。タスク起床手段１０２によりタスク状態が実行状態または実行可能状態でないと判断された場合には（ステップＳ３のＮＯ）、処理を終了させる。

タスク起床手段１０２によりタスク状態が実行状態または実行可能状態であると判断された場合には（ステップＳ３のＹＥＳ）、キューイング手段１０３が起床命令を待ち行列に加え、ＴＣＢのキューイング数に「１」を加算する（ステップＳ４：キューイングステップ）。

その後、デッドラインオーバー判断手段１０５は、キューイング手段１０３により待ち行列に加えられた起床命令の数（キューイング数）がＴＣＢに設定されたキュー段数を超えたか否かを監視し（ステップＳ５：デッドラインオーバー判断ステップ）、キューイング数がキュー段数を超えていないことを検出した場合には（ステップＳ５のＮＯ）、処理を終了させる。

キューイング数がキュー段数を超えたことを検出した場合（ステップＳ５のＹＥＳ）、デッドラインオーバー判断手段１０５は、監視対象タスク１１がデッドラインオーバーになったと判断し監視対象タスク１１を中断または中止させる（ステップＳ６）。

この構成により、デッドライン監視システム２００は、監視対象タスク１１の処理開始時刻の記憶、経過時間の算出、経過時間とデッドライン時間との比較といった、ＲＴＯＳ１０のシステムコールにない、ＣＰＵ２の負荷を増大させてしまう機能を用いることなく、デッドラインオーバーの判断を行うことができ、監視のためのタスクが却ってＣＰＵ２の負荷を増大させてデッドラインオーバーを引き起こすのを防止することができる。

次に、本発明に係るデッドライン監視システム２００と従来のデッドライン監視システムとの違いについて説明する。

図３は、タスク起床からの経過時間に基づいてデッドラインオーバーを監視する従来のデッドライン監視システムと、キューイング手段１０３により待ち行列に格納された起床命令の数を用いてデッドラインオーバーを判断する本発明に係るデッドライン監視システム２００との違いを示す図である。

図３（Ａ）は、従来のデッドライン監視システムにおける経過時間と実行されるタスクとの関係例を示す図であり、縦軸にタスクの処理優先度を示し、横軸に経過時間を示す。処理優先度は、図面上方ほど高く、ＲＴＯＳの処理を最高に、監視タスク、監視対象タスクの順に低くなる。また、実行状態のタスクを実線のバー、実行可能状態のタスクを点線のバーで示す。

監視対象タスクの起床が行われると、監視対象タスクは、待ち状態から実行可能状態に移行し、他に優先度のより高いタスクが実行可能状態となっていない限り、実行状態となる。なお、ＲＴＯＳは、監視対象タスクの実行が開始された時刻をＴＣＢに格納する。

その後、ＲＴＯＳのシステムコールに含まれない監視タスクが所定の周期（例えば４ミリ秒）で起床され、監視タスクは、実行される毎に現在時刻を取得し、現在時刻とタスク開始時刻との差から経過時間を算出し、かつ、予めＴＣＢに設定されたデッドライン時間（例えば、１５ミリ秒）とその経過時間とを比較して、経過時間がデッドライン時間を超えたか否かを判断する。なお、所定の周期は、監視タスクのＴＣＢで予め設定される。

監視タスクは、監視対象タスクによる処理の経過時間がデッドライン時間を超えていないと判断すると、監視を終了して待ち状態となる。

一方、監視タスクは、監視対象タスクによる処理の経過時間がデッドライン時間を超えたと判断すると、監視対象タスクのＴＣＢのタスク状態を終了状態に設定し処理を中止させ、ＴＣＢに格納された監視対象タスクの開始時刻を消去する。

監視タスクによる現在時刻の取得、経過時間の算出、デッドライン時間と経過時間との比較等の処理は、ＲＴＯＳのシステムコールには含まれないので、アプリケーション毎に作成して用意する必要があり、複雑な処理を行うためにＣＰＵ２の負荷も増大する。

図３（Ｂ）は、本発明に係るデッドライン監視システム２００における経過時間と実行されるタスクとの関係例を示す図である。図３（Ａ）と同様に、縦軸にタスクの処理優先度、横軸に経過時間を示し、処理優先度は、ＲＴＯＳ１０、監視対象タスク１１の順となる。

タスク起床手段１０２により監視対象タスク１１の起床が行われると、監視対象タスク１１は、待ち状態から実行可能状態に移行し、他に優先度のより高いタスクが実行可能状態となっていない限り、実行状態となる。なお、ＲＴＯＳ１０は、監視対象タスク１１の実行が開始された時刻をＴＣＢに格納することはない。デッドライン監視に経過時間を使用しないからである。

その後、ＲＴＯＳ１０のタスク起床手段１０２により監視対象タスク１１の起床がＴＣＢのタスク起床周期に基づいて周期的（例えば、４ミリ秒）に実行され、キューイング手段１０３は、監視対象タスク１１のＴＣＢを参照してタスク状態が実行状態である場合には、待ち行列に起床命令を加える。

なお、監視対象タスク１１に対する起床命令がタスク起床周期に基づいて行われるようにすると、ＴＣＢにおける設定値をタスク起床周期のみに簡素化できるという利点があるが、他の設定値を利用し、監視対象タスク１１に対する起床命令を発するタイミングを変化させ、柔軟性を持たせるようにしてもよい。

待ち行列に格納された起床命令の数が所定のキュー段数（例えば、２）を超えた場合、ＲＴＯＳ１０は、デッドラインオーバー判断手段１０５により監視対象タスク１１がデッドラインに達したと判断し、監視対象タスク１１のＴＣＢにおけるタスク状態を終了状態とし、キューイング数をゼロにリセットして、監視対象タスク１１の処理を中止させる。

或いは、デッドラインオーバー判断手段１０５は、監視対象タスク１１がデッドラインに達したと判断した後、監視対象タスク１１のタスク状態を待ち状態とし、優先度を下げて、監視対象タスク１１の処理を中断させるようにしてもよい。

待ち行列に格納された起床命令の数が所定のキュー段数（例えば、２）を超える前に、監視対象タスク１１が終了した場合、ＲＴＯＳ１０は、監視対象タスク１１のＴＣＢにおけるタスク状態を終了状態、キューイング数をゼロとし、監視対象タスク１１の周期的な起床を中止させる。既に終了した監視対象タスク１１のデッドラインを監視する必要は無いからである。

なお、デッドラインオーバー判断手段１０５は、必ずしもＲＴＯＳ１０のシステムコールである必要はなく、ＲＴＯＳ１０上で実行される別のタスクであってもよい。その場合、アプリケーション毎に監視タスクを用意する必要があるが、従来と比べ、現在時刻の取得、経過時間の算出、デッドライン時間と経過時間との比較等の処理が省略されることに変わりはなく、係るデッドラインオーバー判断手段１０５を備えるデッドライン監視システム２００は、監視に伴うＣＰＵ２の負荷を低減させることができる。

次に、監視対象タスクを複数有する場合における、本発明に係るデッドライン監視システム２００と従来のデッドライン監視システムとの違いについて説明する。

図４は、図３と同様、タスクが処理を開始した後の経過時間からデッドラインを監視する従来のデッドライン監視システムと、キューイング手段１０３により待ち行列に格納された起床命令の数を用いてデッドラインを監視する本発明に係るデッドライン監視システム２００との違いを示す図である。

図４（Ａ）は、従来のデッドライン監視システムにおいて、経過時間と実行されるタスクとの関係例を示す図であり、縦軸にタスクの処理優先度を示し、横軸に経過時間を示す。処理優先度は、図面上方ほど高く、ＲＴＯＳの処理を最高に、監視タスク、第１監視対象タスク、第２監視対象タスク、第３監視対象タスクの順に低くなる。

最初に、第３監視対象タスクの起床が行われると、第３監視対象タスクは、待ち状態から実行可能状態に移行し、他に優先度のより高いタスクが実行可能状態となっていない限り、実行状態となる。

その後、監視タスクが所定の周期（例えば、４ミリ秒）で起床され、監視タスクは、実行される毎に現在時刻を取得し、現在時刻とタスク開始時刻との差から経過時間を算出し、かつ、予めＴＣＢに設定されたデッドライン時間（例えば、１５ミリ秒）とその経過時間とを比較して、経過時間がデッドライン時間を超えたか否かを判断する。なお、監視タスクの処理時間を示すバー内の数字は、デッドラインオーバーが監視される監視対象タスクの番号を示し、例えば、「３」は、第３監視対象タスクに対する処理であることを示す。

その後、第２監視対象タスクの起床が行われると、優先度が第２監視対象タスクより低い第３監視対象タスクがプリエンプトされ実行可能状態となり、第２監視対象タスクがディスパッチされ実行状態となる。

さらに、第１監視対象タスクの起床が行われると、第１監視対象タスクより優先度の低い第２監視対象タスクがプリエンプトされ実行可能状態となり、第１監視対象タスクがディスパッチされ実行状態となる。

その後、２回目の監視タスクが起床され、監視タスクは、起床された３つ全ての監視対象タスクに対し、それぞれの処理の経過時間がデッドライン時間を超えたか否かを判断する。この時点では、何れの監視対象タスクもデッドラインオーバーとなっていないため、監視タスクは処理を終了する。

その後、第１監視対象タスクが処理を終了し、次に優先度の高い第２監視対象タスクがディスパッチされ実行状態となる。

その後、３回目の監視タスクが起床され、監視タスクは、既に終了した第１監視対象タスクを除く２つの監視対象タスクに対し、それぞれの処理の経過時間がデッドライン時間を超えたか否かを判断する。この時点では、何れの監視対象タスクもデッドラインオーバーとなっていないため、監視タスクは処理を終了する。

その後、4回目の監視タスクが起床され、監視タスクは、２つの監視対象タスクに対し、それぞれの処理の経過時間がデッドライン時間を超えたか否かを判断する。この時点では、第２監視対象タスクの処理時間がデッドライン時間を超えたため、監視タスクは第２監視対象タスクを中止させる。

図４（Ｂ）は、本発明に係るデッドライン監視システム２００における経過時間と実行されるタスクとの関係例を示す図である。図４（Ａ）と同様に、縦軸にタスクの処理優先度、横軸に経過時間を示し、処理優先度は、ＲＴＯＳ１０、第１監視対象タスク、第２監視対象タスク、第３監視対象タスクの順となる。

その後、第２監視対象タスクの起床が行われると、第２監視対象タスクより優先度の低い第３監視対象タスクはプリエンプトされ実行可能状態となり、第２監視対象タスクがディスパッチされ実行状態となる。

さらに、第１監視対象タスクの起床が行われると、第１監視対象タスクより優先度の低い第２監視対象タスクはプリエンプトされ実行可能状態となり、第１監視対象タスクがディスパッチされ実行状態となる。

その後、第２監視対象タスクの実行が開始された時点からＴＣＢのタスク起床周期で設定された時間が経過すると、第２監視対象タスクの起床が行われる。この場合、第２監視対象タスクが実行状態となっているため、起床命令はキューイング手段１０３により待ち行列に加えられるが、キュー段数がゼロに設定されていた場合、デッドラインオーバー判断手段１０５は、キューイング数がキュー段数を超えたとして第２監視対象タスクの処理時間がデッドラインに達したと判断する。

その後、デッドラインオーバー判断手段１０５は、第２監視対象タスクのＴＣＢにおけるタスク状態を終了状態とし、第２監視対象タスクを中止させる。

以上、説明を簡略化するために、図４（Ａ）および図４（Ｂ）に示す双方のデッドライン監視システムにおいて、それぞれ同じタイミングで第１監視対象タスク、第２監視対象タスクおよび第３監視対象タスクを起床させ、かつ、第２監視対象タスクを同じデッドライン時間（例えば、１５ミリ秒）で中止させているが、本発明に係るデッドライン監視システム２００（図４（Ｂ）参照。）の第２監視対象タスクの進捗度合いが従来のデッドライン監視システム（図４（Ａ）参照。）より大きく進んでいることが分かる。

図４（Ａ）に示す従来のデッドライン監視システムは、ＣＰＵの負荷が比較的大きい監視タスクを監視対象タスク毎に実行し、かつ、実行可能状態にある全ての監視対象タスクを監視するために監視周期が比較的短いのに対し、図４（Ｂ）に示す本発明に係るデッドライン監視システム２００は、ＣＰＵ２の負荷の比較的小さいタスク起床手段１０２（システムコール）によるタスク起床を、実行可能状態にある監視対象タスク毎に設定されたタスク起床周期で実行するので、デッドラインの監視に要するＣＰＵ２の負荷が低減されるからである。

この構成により、デッドライン監視システム２００は、経過時間とデッドライン時間とを比較しながらデッドラインオーバーを監視するといった優先度の高い監視タスクを必要とせず、また、監視対象タスク毎にタスク起床周期を設定できるので不必要な監視を省略できるので、監視対象タスクの数が増大しても、監視に要するＣＰＵ２の負荷を増大させることなく、デッドラインオーバーを確実に監視することができる。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述の実施例では、待ち行列に積まれたタスク起床命令の数に基づいてデッドラインオーバーの判断を行うが、ＲＴＯＳ１０が有するタスク起動命令を利用し、タスク起動命令用の待ち行列に加えられたタスク起動命令の数とその待ち行列の許容段数とに基づいてデッドラインオーバーの判断を行ってもよい。

本発明に係るデッドライン監視システムの構成例を示す図である。デッドライン監視システムがデッドラインを監視する処理の流れを示すフローチャートである。従来のデッドライン監視システムと本発明に係るデッドライン監視システムとの違いを説明する図（その１）である。従来のデッドライン監視システムと本発明に係るデッドライン監視システムとの違いを説明する図（その２）である。

符号の説明

１二次記憶装置
２ＣＰＵ
３主記憶装置
１０ＲＴＯＳ
１１監視対象タスク
１０１スケジューリング手段
１０２タスク起床手段
１０３キューイング手段
１０４タスク制御情報設定手段
１０５デッドラインオーバー判断手段
２００デッドライン監視システム

Claims

起床命令に基づいてタスクの起床を行うタスク起床手段と、
前記タスク起床手段により起床させる前記タスクが処理を開始している場合、所定の許容段数を有する待ち行列に前記起床命令を加えるキューイング手段と、
前記キューイング手段により前記待ち行列に加えられた前記起床命令の数が前記所定の許容段数を超えた場合に、前記タスクがデッドラインオーバーになったと判断するデッドラインオーバー判断手段と、
を備えることを特徴とするデッドライン監視システム。
前記起床命令は所定の周期で発せられる、
ことを特徴とする請求項１に記載のデッドライン監視システム。
起床命令に基づいてタスクの起床を行うタスク起床ステップと、
前記タスク起床ステップにおいて起床させる前記タスクが処理を開始している場合、所定の許容段数を有する待ち行列に前記起床命令を加えるキューイングステップと、
前記キューイングステップにおいて前記待ち行列に加えられた前記起床命令の数が前記所定の許容段数を超えた場合に、前記タスクがデッドラインオーバーになったと判断するデッドラインオーバー判断ステップと、
を備えることを特徴とするデッドライン監視方法。