(57)【要約】【課題】  リアルタイムＯＳのタスク処理において、デッドライン異常が発生した場合に負荷状態が継続して同じ異常対応処理を繰り返し実行するという事態を回避する。【解決手段】  リアルタイムＯＳ内でイベント発生からタスク側へのイベント通知までの間、優先度レベルの低いタスク実行待ちや優先度レベルの同一タスクでの競合における実行待ち、同一タスク内での待ちイベントの連続発生におけるイベントの通知待ち時間が計測され、タスク制御部でタスク側へのイベント通知時にイベント通知遅延時間を付加したイベント通知が行われる（Ｓｔ１１）。タスク側では通知されたイベント通知遅延時間によりイベント毎に持つ遅延時間のデッドラインレベルを判定し（Ｓｔ１２）、該当するレベルの継続発生回数をカウントし（Ｓｔ１３）、このカウント値に応じたイベント処理をコールし（Ｓｔ１４）、実行する（Ｓｔ２０）。【選択図】  図１２
2005250659.tif 000002
【特許請求の範囲】
【請求項１】
リアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するタスク処理方法であって、
前記リアルタイムＯＳからのイベント通知時に、イベント識別情報に加え、前記イベント発生時からの遅延時間を受け取るステップと、
前記イベント識別情報で識別されるイベント毎に前記遅延時間に基づいて予め設定されたデッドライン異常レベルを判定するレベル判定ステップと、
前記イベント毎に前記デッドライン異常レベルの継続発生回数を計数する計数ステップと、
前記イベント毎に前記デッドライン異常レベルの継続発生回数に基づいて、予め設定されたイベント処理を決定する処理決定ステップと、
決定された前記イベント処理を実行するステップとを有することを特徴とするリアルタイムＯＳを用いたタスク処理方法。
【請求項２】
前記レベル判定ステップは、
前記イベント識別情報と前記遅延時間のしきい値から前記デッドライン異常レベルを判定するレベル判定用しきい値判定テーブルを使用し、
前記計数ステップは、
前記イベント識別情報と前記デッドライン異常レベル毎に前記デッドライン異常レベルの継続発生回数を計数する継続発生回数カウントテーブルを使用し、
前記処理決定ステップは、
前記イベント識別情報、前記デッドライン異常レベル、及び前記デッドライン異常レベルの継続発生回数のしきい値に関連付けてイベント処理を決定する処理決定テーブルを使用することを特徴とする請求項１記載のタスク処理方法。
【請求項３】
前記イベント処理は、前記イベント毎に同一の前記デッドライン異常レベル内で前記継続発生回数によって割り当てられる複数段階の処理を含むことを特徴とする請求項１又は２記載のタスク処理方法。
【請求項４】
前記複数段階の処理は、複数段階の準正常処理、及び複数段階の異常処理を含むことを特徴とする請求項３記載のタスク処理方法。
【請求項５】
リアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するタスク処理装置であって、
前記リアルタイムＯＳからのイベント通知時に、イベント識別情報に加え、前記イベント発生時からの遅延時間を受け取る手段と、
前記イベント識別情報で識別されるイベント毎に前記遅延時間に基づいて予め設定されたデッドライン異常レベルを判定するレベル判定手段と、
前記イベント毎に前記デッドライン異常レベルの継続発生回数を計数する計数手段と、
前記イベント毎に前記デッドライン異常レベルの継続発生回数に基づいて、予め設定されたイベント処理を決定する処理決定手段と、
決定された前記イベント処理を実行する手段とを有することを特徴とするリアルタイムＯＳを用いたタスク処理装置。
【請求項６】
前記レベル判定手段は、
前記イベント識別情報と前記遅延時間のしきい値から前記デッドライン異常レベルを判定するレベル判定用しきい値判定テーブルを有し、
前記計数手段は、
前記イベント識別情報と前記デッドライン異常レベル毎に前記デッドライン異常レベルの継続発生回数を計数する継続発生回数カウントテーブルを有し、
前記処理決定手段は、
前記イベント識別情報、前記デッドライン異常レベル、及び前記デッドライン異常レベルの継続発生回数のしきい値に関連付けてイベント処理を決定する処理決定テーブルを有することを特徴とする請求項５記載のタスク処理装置。
【請求項７】
前記イベント処理は、前記イベント毎に同一の前記デッドライン異常レベル内で前記継続発生回数によって割り当てられる複数段階の処理を含むことを特徴とする請求項５又は６記載のタスク処理装置。
【請求項８】
前記複数段階の処理は、複数段階の準正常処理、及び複数段階の異常処理を含むことを特徴とする請求項７記載のタスク処理装置。
【請求項９】
リアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するタスク処理装置で用いる制御プログラムであって、
コンピュータに、
前記リアルタイムＯＳからのイベント通知時に、イベント識別情報に加え、前記イベント発生時からの遅延時間を受け取るステップと、
前記イベント識別情報で識別されるイベント毎に前記遅延時間に基づいて予め設定されたデッドライン異常レベルを判定するレベル判定ステップと、
前記イベント毎に前記デッドライン異常レベルの継続発生回数を計数する計数ステップと、
前記イベント毎に前記デッドライン異常レベルの継続発生回数に基づいて、予め設定されたイベント処理を決定する処理決定ステップと、
決定された前記イベント処理を実行するステップとを実行させるためのプログラム。
【請求項１０】
前記レベル判定ステップは、
前記イベント識別情報と前記遅延時間のしきい値から前記デッドライン異常レベルを判定するレベル判定用しきい値判定テーブルを使用し、
前記計数ステップは、
前記イベント識別情報と前記デッドライン異常レベル毎に前記デッドライン異常レベルの継続発生回数を計数する継続発生回数カウントテーブルを使用し、
前記処理決定ステップは、
前記イベント識別情報、前記デッドライン異常レベル、及び前記デッドライン異常レベルの継続発生回数のしきい値に関連付けてイベント処理を決定する処理決定テーブルを使用することを特徴とする請求項９記載のプログラム。
【請求項１１】
前記イベント処理は、前記イベント毎に同一の前記デッドライン異常レベル内で前記継続発生回数によって割り当てられる複数段階の処理を含むことを特徴とする請求項９又は１０記載のプログラム。
【請求項１２】
前記複数段階の処理は、複数段階の準正常処理、及び複数段階の異常処理を含むことを特徴とする請求項１１記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイムＯＳを用いたタスク処理方法、装置、及びプログラムに係り、特にリアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するためのタスク処理方法、装置、及びプログラムに関する。
【背景技術】
【０００２】
監視制御装置等のリアルタイム制御が要求されるコンピュータを用いた制御装置やシステムでは、プロセッサ（ＣＰＵ）により実行されるオペレーティングシステム(ＯＳ）として、処理効率の高いリアルタイムＯＳが望まれている。リアルタイムＯＳでは、次に実行すべきタスクを決定するための処理、即ちタスクスケジューリングの機能（アルゴリズム）が採用され、優先度が同一又は異なる複数のタスクを時分割で切り替えながら、それぞれのタスクを並列実行可能となっている。
【０００３】
このようなリアルタイムＯＳのタスクスケジューリング方法では、処理効率向上のため、採用されるアルゴリズムの改善が図られてきた。
【０００４】
例えば、特許文献１によれば、優先度の小さいタスクの実行開始を次の割り込み発生時まで遅延させることが可能な場合、現在実行中のタスクの実行を継続することにより、タスクの切替回数を低減し、優先度の小さいタスクで発生しやすいデッドライン違反（デッドライン異常）を低減するようにしたリアルタイムＯＳのタスク制御装置およびそのタスクスケジューリング方法が記載されている。
【０００５】
また、特許文献２によれば、周期的マルチメディアタスクをスケジューリングするためのソフトリアルタイムにおけるスケジューリング方法として、新しいタスク到着時点でのＣＰＵの負荷状態に応じてスケジューリング可能かどうかを判断し、スケジューリング可能である場合にスケジューリング対象のすべてのタスクを実行し、すべてのタスクを実行した結果から得られる各タスクの通信待ち時間に応じて各タスクの適応デッドラインを設定するものが記載されている。
【特許文献１】特開２００１−２３６２３６号公報
【特許文献２】特開２００１−３５０６３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述した従来技術では、タスクスケジューリング方法のアルゴリズム改善により処理効率が向上する反面、ＣＰＵが過負荷状態となった場合やその負荷状態が継続して輻輳状態となった場合、処理遅延によるデッドライン異常が一旦発生すると、このデッドライン異常をタスク側で認識した場合でも、負荷状態はすぐには解消されず、そのデッドライン異常が継続して発生し続け、同じ異常対応処理を繰り返し実行してしまうことがあった。
【０００７】
本発明は、このような従来の事情を考慮してなされたもので、リアルタイムＯＳのタスク処理において、デッドライン異常が発生した場合に負荷状態が継続して同じ異常対応処理を繰り返し実行するという事態を回避することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明に係るリアルタイムＯＳを用いたタスク処理方法は、リアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するタスク処理方法であって、前記リアルタイムＯＳからのイベント通知時に、イベント識別情報に加え、前記イベント発生時からの遅延時間を受け取るステップと、前記イベント識別情報で識別されるイベント毎に前記遅延時間に基づいて予め設定されたデッドライン異常レベルを判定するレベル判定ステップと、前記イベント毎に前記デッドライン異常レベルの継続発生回数を計数する計数ステップと、前記イベント毎に前記デッドライン異常レベルの継続発生回数に基づいて、予め設定されたイベント処理を決定する処理決定ステップと、決定された前記イベント処理を実行するステップとを有することを特徴とする。
【０００９】
本発明に係るリアルタイムＯＳを用いたタスク処理方法において、前記レベル判定ステップは、前記イベント識別情報と前記遅延時間のしきい値から前記デッドライン異常レベルを判定するレベル判定用しきい値判定テーブルを使用し、前記計数ステップは、前記イベント識別情報と前記デッドライン異常レベル毎に前記デッドライン異常レベルの継続発生回数を計数する継続発生回数カウントテーブルを使用し、前記処理決定ステップは、前記イベント識別情報、前記デッドライン異常レベル、及び前記デッドライン異常レベルの継続発生回数のしきい値に関連付けてイベント処理を決定する処理決定テーブルを使用してもよい。また、前記イベント処理は、前記イベント毎に同一の前記デッドライン異常レベル内で前記継続発生回数によって割り当てられる複数段階の処理を含み、前記複数段階の処理は、複数段階の準正常処理、及び複数段階の異常処理を含んでもよい。
【００１０】
本発明に係るタスク処理装置は、リアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するタスク処理装置であって、前記リアルタイムＯＳからのイベント通知時に、イベント識別情報に加え、前記イベント発生時からの遅延時間を受け取る手段と、前記イベント識別情報で識別されるイベント毎に前記遅延時間に基づいて予め設定されたデッドライン異常レベルを判定するレベル判定手段と、前記イベント毎に前記デッドライン異常レベルの継続発生回数を計数する計数手段と、前記イベント毎に前記デッドライン異常レベルの継続発生回数に基づいて、予め設定されたイベント処理を決定する処理決定手段と、決定された前記イベント処理を実行する手段とを有することを特徴とする。
【００１１】
本発明に係るプログラムは、リアルタイムＯＳ上で認識されるイベントに応じて該当するイベント処理を実行するタスク処理装置で用いる制御プログラムであって、コンピュータに、前記リアルタイムＯＳからのイベント通知時に、イベント識別情報に加え、前記イベント発生時からの遅延時間を受け取るステップと、前記イベント識別情報で識別されるイベント毎に前記遅延時間に基づいて予め設定されたデッドライン異常レベルを判定するレベル判定ステップと、前記イベント毎に前記デッドライン異常レベルの継続発生回数を計数する計数ステップと、前記イベント毎に前記デッドライン異常レベルの継続発生回数に基づいて、予め設定されたイベント処理を決定する処理決定ステップと、決定された前記イベント処理を実行するステップとを実行させるためのものである。
【発明の効果】
【００１２】
本発明によれば、イベント発生時刻からタスク側へのイベント実行遅延時間と、デッドライン異常の発生した回数とに応じて、正常処理、準正常処理、異常処理等のイベント処理のデッドライン異常に対する異常対応処理の段階を細かく設定して実行することができ、これによりデッドライン異常が発生した場合、タスク側で負荷状態が継続して同じ異常対応処理のタスクを繰り返し実行する事態を回避することができる。
【発明を実施するための最良の形態】
【００１３】
次に、本発明に係るリアルタイムＯＳを用いたタスク処理方法、装置、及びプログラムを実施するための最良の形態について、図面を参照して詳細に説明する。
【実施例】
【００１４】
本実施例のタスク処理装置は、例えば監視制御装置等のリアルタイム制御が要求される制御装置に適用されるものである。
【００１５】
図１は、本実施例のタスク処理装置の構成例を示す。図１に示すタスク処理装置１は、ハードウェア構成上、プログラム制御で動作するＣＰＵ（プロセッサ）１１と、ＣＰＵ１１により実行されるソフトウェア１４が格納されるメモリ（ＲＡＭ／ＲＡＭ）１２と、入力器や表示器等のＩ／Ｏ（入出力）機器２に接続されるＩ／Ｏポート１３とを有する。
【００１６】
図２は、ソフトウェア１４の構成例を概念的に示す。図２に示すソフトウェア１４には、リアルタイムＯＳ１５と、このリアルタイムＯＳ１５上で動作する制御プログラム１６と、リアルタイムＯＳ１５上で認識される各種イベント１〜ｙに応じてこれに該当するイベント１〜ｙ処理を実行するためのイベント処理用プログラム１７の実行単位として、リアルタイムＯＳ１５の管理下で起動（生成）されるタスク１８（図中の例では複数のタスク１〜ｙが起動している場合を例示している。）と、このタスク１８側で実行されるイベント実行準備処理（後述参照）時に参照される参照テーブル１９とを有する。
【００１７】
リアルタイムＯＳ１５には、機能上、タスク１８側で実行されるイベント処理を制御するタスク制御部２１が含まれる。タスク制御部２１には、タスク１８に与えられる優先度レベル（優先順位）に基づいて次に実行すべきタスク１８を決定するためのタスクスケジューリングの機能として、イベント１〜ｙの発生を認識する機能、イベント１〜ｙの発生を、そのイベントを識別可能なイベント識別情報（以下、説明の都合上、「イベント番号（イベントＩＤ）１〜ｙ」と呼ぶ）と共にタスク１８側に通知するイベント通知機能が含まれる。リアルタイムＯＳ１５では、イベント発生からタスク１８側へのイベント通知までの間、優先度レベルの低いタスク１８の実行待ち時間や、優先度レベルが同一のタスク１７間での競合における実行待ち時間、同一タスク１８内での待ちイベントの連続発生におけるイベント通知待ち時間が発生し、これら待ち時間がイベント発生時刻からイベント通知時刻の間の「イベント通知遅延時間」Ｔとなる。そこで、本実施例のイベント通知機能は、そのイベント通知遅延時間Ｔを計測し、計測されたイベント通知遅延時間Ｔをイベント番号１〜ｙに付加してイベント通知を行うようになっている。
【００１８】
イベント処理用プログラム１７は、ソフトウェア１４（リアルタイムＯＳ１５及び制御プログラム１６等）を成すプログラム部品（モジュール）で構成され、本実施例ではイベント１〜ｙに応じたイベント１〜ｙ処理用プログラムＩＶ１〜ＩＶｙから構成される。
【００１９】
図３は、イベント処理用プログラム１７の構成例を示す。図３に示すイベント１処理用プログラムＩＶ１には、後述のデッドラインレベル（デッドライン異常レベル）毎に割り当てられる複数の処理プログラム、即ちレベル１用正常処理プログラム（EV1_1）、レベル２用準正常処理１プログラム（EV1_2_1）、レベル２用準正常処理２プログラム（EV1_2_2）、レベル３用異常処理１プログラム（EV1_3_1）、レベル３用異常処理２プログラム（EV1_3_2）、レベル３用異常処理３プログラム（EV1_3_3）、レベルｘ用異常処理１プログラム（EV1_x_1）、レベルｘ用異常処理２プログラム（EV1_x_1）が含まれる。図３の例では、イベント１処理用プログラムＩＶ１のみ例示するが、その他のイベント２〜イベントｙ処理用プログラムＩＶ２〜ＩＶｙについても同様である。
【００２０】
図４は、参照テーブル１９の構成例を示す。図４に示すように、参照テーブル１９には、レベル判定用しきい値テーブル３１、同一レベル継続発生回数カウントテーブル３２、及び同一レベル継続発生回数マトリクステーブル（イベント実行処理マトリクステーブル）３３が含まれる。
【００２１】
図５は、レベル判定用しきい値テーブル３１のデータ構造を示す。図５の例では、イベントを識別するイベント番号１〜ｙと、イベント処理のタスク実行に関するデッドラインレベルのレベル１〜ｘとを互いに関連付けるマトリクステーブルのマトリクス位置に、イベント通知遅延時間Ｔのしきい値が設定される。
【００２２】
例えば、イベント１に対し、イベント通知遅延時間Ｔが「０ｍｓ（ミリ秒）から１０ｍｓ以内」の範囲を「レベル１」と定義する場合は、「イベント１」と「レベル１」とのマトリクス位置に、しきい値として「１０ｍｓ」が設定される。同様に、イベント通知遅延時間Ｔが「１１ｍｓから２０ｍｓ以内」の範囲を「レベル２」と定義する場合は、「イベント１」と「レベル２」とのマトリクス位置に、しきい値として「２０ｍｓ」が設定される。また、デッドラインレベルの最高レベルとなる「レベルｘ」については、本実施例ではイベント通知遅延時間Ｔが「１０００ｍｓ」より大きい場合全てというように上限値を設けない条件で設定する。その他、レベル２を設定せずにレベル１からレベル３と続く場合等は、該当するレベル２のしきい値は、レベル１と同値を設定する等し、レベル判定の際は、レベルの低い方から判定に用いる（図中の例では、イベント２のレベル１及び２の関係参照）。
【００２３】
これにより、イベント通知遅延時間Ｔのしきい値に基づいて、イベント１〜ｙ毎にデッドラインレベルのレベル１〜ｘが判定可能となっている。
【００２４】
図６は、同一レベル継続発生回数カウントテーブル３２のデータ構造を示す。図６の例では、イベント番号１〜ｙと、デッドラインレベルのレベル１〜ｘとを互いに関連付けるマトリクステーブルのマトリクス位置がカウンタとして設定され、そのマトリクス位置に、図５のレベル判定用しきい値テーブル３１で判定されたイベント１〜ｙ毎のデッドラインレベルのレベル１〜ｘと同一レベルが継続して発生する場合の継続発生回数Ｘが更新（カウントアップ及びリセット）可能に記憶される。これにより、同じイベントでデッドラインレベルが判定される度に該当するマトリクス位置の継続発生回数Ｘを１回カウントアップし、前回のレベルから変化があった場合は該当するマトリクス位置の継続発生回数Ｘを０回にリセットすることが可能となっている。
【００２５】
図７及び図８は、同一レベル継続発生回数マトリクステーブル３３のデータ構造を示す。図７の例では、イベント番号１〜ｙと、デッドラインレベルのレベル１〜ｘとを互いに関連付けるマトリクステーブルのマトリクス位置に、図６の同一レベル継続発生回数カウントテーブル３２でカウントされた継続発生回数Ｘに応じて「イベント処理名」を設定可能となっている。図８の例では、図７と同様の関係を、各イベント１〜ｙの各レベル１〜ｘ毎に個別に分けて示したものである。
【００２６】
例えば、各イベント１〜ｙと各レベル１〜ｘ毎に継続発生回数Ｘによって処理を分けるため、初回の場合（Ｘ＝１）、２回目以降(Ｘ＞１)の場合、ａ回目以降(Ｘ＞ａ、例えばａ＝１０又は２０等)の場合等、継続発生回数Ｘ毎に同一レベル継続発生回数マトリクステーブル３３にて該当する「イベント処理名」が設定される。イベント処理名は、前述したイベント１〜ｙ処理用プログラムＩＶ１〜ＩＶｙ（図３参照）に対応する。
【００２７】
図９及び図１０は、タスク１８側のイベント実行準備処理を説明するものである。図９及び図１０に示すイベント実行準備処理は、ＣＰＵ１１がメモリ１２上の処理プログラム（リアルタイムＯＳ１５及び制御プログラム１６の少なくとも一方）を実行することにより、行われる。
【００２８】
図９に示すように、タスク１８側では、タスク制御部２１からイベント通知を受けると、イベント実行準備処理を実行する（ステップＳｔ１０）。この処理実行に際し、イベント番号１〜ｙ及びイベント通知遅延時間Ｔを入力すると（ステップＳｔ２１）、レベル判定用しきい値テーブル３１を参照して（ステップＳｔ２２）、イベント番号１〜ｙで認識されるイベント１〜ｙ毎にイベント通知遅延時間Ｔに基づいてデッドラインレベルを判定する（ステップＳｔ２３）。
【００２９】
これにより、図１０の例に示すように、イベント１〜ｙ毎に、０≦Ｔ≦Ｔｒ１（しきい値１）の場合は遅延時間Ｔとして実質的に問題の無い「レベル１」、Ｔｒ１＜Ｔ≦Ｔｒ２（しきい値２）の場合は遅延と認識し再処理を行っても実質的に問題の無い「レベル２」、Ｔｒ２＜Ｔ≦Ｔｒ３（しきい値３）のときは処理的にデッドタイムとする「レベル３」とし、以下同様にＴｒｘ−２（しきい値ｘ−２）＜Ｔ≦Ｔｒｘ−１（しきい値ｘ−１）の場合は「レベルｘ−１」とし、最後にＴｒｘ−１（しきい値ｘ−１）＜Ｔの場合は「レベルｘ」となるよう判定される。
【００３０】
次いで、同一レベル継続発生回数カウントテーブル３２を参照して（ステップＳｔ２４）、イベント１〜ｙに応じて判定されたデッドラインレベルが前回と同一レベルの場合は（ステップＳｔ２５、ＹＥＳ）、該当するマトリクス位置の継続発生回数Ｘをカウントアップし（ステップＳｔ２６）、前回と同一レベルでなく、即ちレベルが変化した場合は（ステップＳｔ２５、ＮＯ）、前回のレベルに該当するマトリクス位置の継続発生回数Ｘをクリアし（ステップＳｔ２７）、今回判定されたレベルに該当するマトリクス位置の継続発生回数Ｘをカウントアップする（ステップＳｔ２８）。
【００３１】
次いで、カウントされた継続発生回数Ｘを入力すると（ステップＳｔ２９）、同一レベル継続発生回数マトリクステーブル３３を参照して（ステップＳｔ３０）、イベント処理名、即ち実行すべきイベント処理を決定する（ステップＳｔ３１）。
【００３２】
これにより、図１０の例に示すように、「レベル１」の場合はＸに関係なく「正常処理」、「レベル２」の場合はＸ＝１（１回目）のときに「準正常処理１」、Ｘ＞１（２回目以降）のときに「準正常処理２」、「レベル３」の場合はＸ＝１のときに「異常処理１」、Ｘ＞１のときに「異常処理２」、Ｘ＞ａ（例えば、ａ＝１０又は２０）のときに「異常処理３」、「レベルｘ」の場合はＸ＝１のときに「異常処理１」、Ｘ＞１のときに「異常処理２」となるよう決定される。具体的には、同一レベル継続発生回数マトリクステーブル３３内のイベント番号１〜ｙ、レベル１〜ｘ、及び継続発生回数Ｘで決まるマトリクス位置に設定されたイベント処理名、即ちイベント処理用プログラム１７がコールされる。
【００３３】
上記イベント処理については、使用されるシステムに応じて異なる場合もあるが、本実施例では、イベント通知遅延時間Ｔとして実質的に問題の無い「レベル１」では、通常の「正常処理」を行い、遅延と認識し再処理（リトライ処理）を行っても実質的に問題の無い「レベル２」では、継続発生回数Ｘが初回の場合は「準正常処理１」を行い、２回目以降も継続して発生する場合は「準正常処理２」を行い、処理的にデッドタイムとする「レベル３」では、継続発生回数Ｘが初回であれば異常警報を発して処理を中止する「異常処理１」を行い、発生回数が２回目以降であれば処理を行わない等の異常停止を行う「異常処理２」等、遅延時間Ｔ及び継続発生回数Ｘによって段階的に処理が区分される。
【００３４】
次いで、上記イベント実行準備処理で決定されたイベント処理、即ち正常処理、準正常処理１、２、及びレベル３以降の各レベルにおける異常処理１、２、３のいずれかに該当するイベント処理用プログラム１７が実行される（ステップＳｔ２０）。
【００３５】
これにより、例えば、デッドラインレベルが「レベル２」の場合、初回発生時の「準正常処理２」では、再処理（リトライ処理）、２回目以降の「準正常処理２」では処理中断、またデッドラインレベルがレベル３の場合、初回発生時の「異常処理２」ではＣＰＵの輻輳状態や半暴走状態が考えられ回復できない状態と判断し、他装置等の外部へ処理できなかったことを通知する処理、２回目以降の「異常処理２」では全処理を中断しアラーム（ＡＬＭ）を通知する処理など、イベント処理を分離して実行できる。また、デッドラインレベルの高い時には、ソフトウェア自ら暴走検出（ウォッチドックタイマ・タイムアウト）機能を持つこととなり、さらにどのイベントでそれが発生したのか、何回その状態を継続しているかを把握することが可能となる。
【００３６】
次に、図１１及び図１２を参照して、本実施例の全体動作を説明する。
【００３７】
まず、図１１に示すように、時刻ｔ１にて、リアルタイムＯＳ１５内でイベント１が発生したとする。このイベント発生に際し、タスク制御部２１にて、イベント発生からタスク１８側へのイベント通知までの間、優先度レベルの低いタスク１８の実行待ち、優先度レベルの同一タスク１８での競合における実行待ち、同一タスク１８内での待ちイベントの連続発生におけるイベントの通知待ち時間が計測され、タスク１８側へのイベント通知時ｔ２にイベント通知遅延時間Ｔ１（例えば、Ｔ１＝２０ｍｓ）を付加したイベント通知が行われる（ステップＳｔ１１）。
【００３８】
これにより、タスク１８側では、図１２に示すイベント実行準備処理（ステップＳｔ１０）が実行される。即ち、タスク制御部２１よりイベント通知時間Ｔ１が付加されたイベント通知を受けると（ステップＳｔ１１）、レベル判定用しきい値テーブル３１を参照して、イベント番号とイベント通知遅延時間Ｔ１とで求まるマトリクス位置によりデッドラインレベルが判定される（ステップＳｔ１２）。図１２の例では、イベント１及びＴ１＝２０ｍｓから、「レベル３」と判定された場合を示す。
【００３９】
次いで、同一レベル継続発生カウントテーブル３２を参照して、同じイベントで同じレベルが繰り返し発生する場合は、該当するマトリクス位置（カウンタ）の継続発生回数Ｘのカウント値を１回アップし、レベル変化が発生した場合には前回のレベルのカウント値をクリアする（ステップＳｔ１３）。図１２の例では、同一レベル、即ちレベル３内で、Ｘ＝６からＸ＝７にカウントアップされた場合を示す。
【００４０】
次いで、同一レベル継続発生カウントテーブル３３を参照して、判定されたレベルと、そのレベルでの継続発生回数Ｘ（カウント値）に基づいて、該当するイベント処理名のプログラムが決定され、イベント処理用プログラム１７側にコールされる（ステップＳｔ１４）。図１２の例では、イベント１、レベル３、及びＸ＝７に基づいて、イベント１処理用プログラムＥＶ１のレベル３用異常処理２プログラム（EV1_3_2）が決定された場合を示す。
【００４１】
最後に、上記イベント実行準備処理によりコールされたイベント処理名のプログラムが実行される（ステップＳｔ２０）。図１２の例では、イベント１処理用プログラムＥＶ１のレベル３用異常処理２プログラム（EV1_3_2）が実行された場合を示す。
【００４２】
以下同様に、図１１に戻り、上記イベント１処理が実行中の時刻ｔ３にてリアルタイムＯＳ１５内で発生したイベント２に対しては、イベント１処理終了後の時刻ｔ５にてイベント通知遅延時間Ｔ２が付加されたイベント通知が行われ、これにより、タスク１８側にて上記処理にて決定されるイベント２処理が実行され、このイベント２処理が実行中の時刻ｔ４にて発生したイベント３に対しては、イベント１処理終了後の時刻ｔ５にて時刻ｔ６イベント通知遅延時間Ｔ３が付加されたイベント通知が行われ、これにより、タスク１８側にて上記処理にて決定されるイベント３処理が実行される。
【００４３】
従って、本実施例によれば、実際のイベント発生時刻からタスク１８側でイベント処理を行うまでにリアルタイムＯＳ１５上のタスク制御で発生するイベント通知遅延時間Ｔを通知することで、タスク１８側にて遅延時間のデッドラインレベル判定を行いそのレベルに応じた処理を実行できる。例えば、イベント発生からのイベント通知遅延時間Ｔがしきい値２以内、即ち「レベル１」であれば、通常処理、またしきい値１より大きくしきい値２以内、即ち「レベル２」であれば、準正常処理で、同一レベルの継続発生回数Ｘが初回の場合は準正常処理１、２回目以降の場合は準正常処理２、さらにしきい値２より大きい「レベル３」であれば、異常処理等、処理を細かく分けることが可能となり、タスク側で準正常処理、異常処理、デッドライン異常処理等を行うことができる。
【００４４】
これによれば、イベント通知遅延時間に加え、同一レベルが繰り返し発生する場合の継続発生回数を考慮に入れてイベント処理を実行するため、イベント通知遅延時間のみのでデッドライン異常レベルの振り分けを行なう場合と比べ、次の利点がある。
【００４５】
即ち、イベント通知遅延時間のみを考慮に入れたイベント処理の場合は、イベントの発生から実際にタスク側で処理されるまで、優先度レベルが同一のタスクで同時にイベント発生した場合や、高優先度タスク内でイベント発生が多発した場合などにリアルタイムＯＳ上のタスク側へのイベント待ち時間が発生した場合、デッドライン異常においてデッドライン異常レベルに応じた該当イベント処理を行なっても、デッドライン異常に応じたイベント処理は発生した回数を意識しないため、負荷状態が継続した場合に同様のイベント処理が継続され何度も実行される事態が生じるが、本実施例のようにイベント通知遅延時間に加え同一レベルの継続発生回数を考慮に入れたイベント処理の場合は、このような事態を回避できる。
【００４６】
さらに、本実施例では、イベント通知遅延時間、及びデッドラインの各レベル発生回数を外部ソフトウェアや他装置に通知することにより、イベント発生からの遅延時間を考慮した処理を行え、デバッグ機能的にＣＰＵの負荷状況の把握することができる。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施例のタスク処理装置の構成を示す図である。
【図２】図１に示すタスク処理装置のソフトウェア構成を示す図である。
【図３】図２に示すイベント処理用プログラムの構成を示す図である。
【図４】図２に示す参照テーブルの構成を示す図である。
【図５】図４に示すレベル判定用しきい値テーブルのデータ構造図である。
【図６】図４に示す同一レベル継続発生回数カウントテーブルのデータ構造図である。
【図７】図４に示す同一レベル継続発生回数マトリクステーブルのデータ構造図である。
【図８】図４に示す同一レベル継続発生回数マトリクステーブルの各イベントと他レベル毎のデータ構造を示す図である。
【図９】図２に示すタスク側のイベント実行準備処理を説明するフローチャートである。
【図１０】図２に示すタスク側のイベント実行準備処理を模式的に説明する図である。
【図１１】図１に示すタスク処理装置によるイベント処理の動作タイミングを示す図。
【図１２】図１に示すタスク処理装置によるイベント処理を模式的に説明するフローチャートである。
【符号の説明】
【００４８】
１  タスク処理装置
２  Ｉ／Ｏ機器
１１  ＣＰＵ
１２  メモリ（ＲＯＭ／ＲＡＭ）
１３  Ｉ／Ｏポート
１４  ソフトウェア
１５  リアルタイムＯＳ
１６  制御プログラム
１７  イベント通知用プログラム
１８  タスク
１９  参照テーブル
３１  レベル判定用しきい値テーブル
３２  同一レベル継続発生回数カウントテーブル
３３  同一レベル継続発生回数マトリクステーブル
【図１】
2005250659.tif 000003
【図２】
2005250659.tif 000004
【図３】
2005250659.tif 000005
【図４】
2005250659.tif 000006
【図５】
2005250659.tif 000007
【図６】
2005250659.tif 000008
【図７】
2005250659.tif 000009
【図８】
2005250659.tif 000010
【図９】
2005250659.tif 000011
【図１０】
2005250659.tif 000012
【図１１】
2005250659.tif 000013
【図１２】
2005250659.tif 000014