JP3578082B2

JP3578082B2 - 処理実行装置及び記録媒体

Info

Publication number: JP3578082B2
Application number: JP2000387120A
Authority: JP
Inventors: 忠治西村
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2000-12-20
Filing date: 2000-12-20
Publication date: 2004-10-20
Anticipated expiration: 2020-12-20
Also published as: US6968552B2; EP1217518A2; JP2002189606A; US20020078257A1; EP1217518A3

Description

【０００１】
【発明の属する技術分野】
本発明は、リアルタイムオペレーティングシステム（以下「ＲＴＯＳ」という。）を用いたタスク切り換え技術に関する。
【０００２】
【従来の技術】
例えば車両に搭載される電子制御装置（以下「ＥＣＵ」という。）に用いられる制御プログラムでは、制御応答性や安全性の確保等から所定の処理をリアルタイムに実行する必要性がある。そのため、優先度の設定されたタスクの単位で処理プログラムを記述し、ＲＴＯＳによるタスクの切り換えによって、リアルタイム性を確保している。
【０００３】
より具体的には、イベントの発生を検知して起床要求プログラムが該当タスクの起床要求を行うと、ＲＴＯＳがタスクを起床し、起床されたタスクにて、そのイベントに応じた処理（以下「イベント対応処理」という。）が実行されるようになっている。なお、タスクにはそれぞれ優先度が設定されている。これはタスク間に実行の優先順位が存在するからであり、リアルタイム性の高い処理ほど、優先度の高いタスクとして実現される。したがって、ＲＴＯＳは、起床要求のあったタスクが起床されておらず、かつ、既に起床されているタスクがあれば、そのタスクよりも起床要求のあったタスクの優先度が高い場合に、その起床要求のあったタスクを起床する。
【０００４】
従来、このＲＴＯＳによって起床されるタスクは、上述した優先度毎に、設けられていた。つまり、優先度が同じである複数のイベント対応処理が、１つのタスクに属するプログラム構造になっていた。これについて説明する。
ＲＴＯＳによって起床されるタスクの優先度が３段階に設定されていれば、図５に示すように、高優先度のＡタスク、中優先度のＢタスク、低優先度のＣタスクという具合に３つのタスクが存在する。一例として各タスクで実行されるイベント対応処理を挙げると、Ａタスクで実行される処理は、１ｍｓ毎に実行される１ｍｓ処理、クランク軸の３０°ＣＡ毎に実行される３０°ＣＡ処理などである。また、Ｂタスクで実行される処理は、４ｍｓ毎に実行される４ｍｓ処理、８ｍｓ毎に実行される８ｍｓ処理、所定気筒のピストンが上死点（ＴＤＣ）に来た時点で実行されるＴｄｃ処理、エンジンストール時に実行されるエンスト処理、自己診断を行うための故障検出処理などである。さらに、Ｃタスクで実行される処理は１６ｍｓ毎に実行される１６ｍｓ処理、３２ｍｓ毎に実行される３２ｍｓ処理などである。
【０００５】
このようにタスクを優先度毎に設けている理由は、ＲＴＯＳがタスクの切り換えを優先度で行うからであり、また、タスクの総数がそれほど多くならず、ＲＴＯＳによる管理情報が比較的少なくなるためである。管理情報が減少すれば、ＲＡＭといったメモリの記憶容量を削減できる点で有利である。
【０００６】
【発明が解決しようとする課題】
しかしながら、上述したプログラム構造では、１つのタスク内に複数のイベント対応処理が存在するため、要求されたイベント対応処理を各タスクが特定して実行する必要が生じる。
【０００７】
具体的には、起床要求プログラムが、イベントの発生を検知すると、ＲＴＯＳに対し該当タスクの起床要求を行うと共に、実行すべきイベント対応処理を特定するための識別情報（ＩＤ）を、待ち行列であるキュー（メモリ領域）に格納する。一方、タスクは、ＲＴＯＳによって起床されると、キューからＩＤを読み出し、要求されたイベント対応処理を特定して実行する。
【０００８】
ＩＤのキューへの記憶及びキューからの取得は、ＦＩＦＯと呼ばれる方式で行われる。ＦＩＦＯは、ある場所に格納したデータを、古く格納した順に取り出すようにする方式である。これは、様々なイベントが連続して発生する可能性を考慮したものである。
【０００９】
以上のように、従来のプログラム構造では、タスクが優先度毎に設けられていたため、イベントが発生する度に必ず、ＩＤの記憶及び取得（以下適宜「キューイング」という。）が必要になっていた。このキューイングでは、キューにデータがあるか否かのチェックや、キューが一杯になっているか否かのチェックも必要である。そのため、従来のプログラム構造では、各種のイベントが連続して発生する状況下において、ＣＰＵの処理負荷が大きなものになっていた。
【００１０】
そしてＣＰＵの処理負荷が大きくなると、相対的に優先度の低いタスクの起床が遅れ、結果的にそのタスク内のイベント対応処理の実行が遅れることになる。また、ＣＰＵの負荷が１００パーセントに達すると、相対的に優先度の低いイベント対応処理は間引かれて、実行されなくなってしまう。その結果、応答性が悪化するなど、制御性能への悪影響が生じる。
【００１１】
本発明は、上述した問題点を解決するためになされたものであり、上述したイベント対応処理をＲＴＯＳに管理されるタスクで実現するにあたり、ＣＰＵの処理負荷を低減させることを目的とする。
【００１２】
【課題を解決するための手段及び発明の効果】
上述した目的を達成するためになされた請求項１に記載の処理実行装置は、所定のイベントの発生を検知し、当該イベントに応じたイベント対応処理を実行するタスクスケジューリングプログラムを備えている。
【００１３】
なお、本明細書では、「プログラムが・・・する」といったプログラムを主体とした表現を適宜用いるが、詳しくは、処理実行装置のＣＰＵがプログラムに基づく処理を実行することによって各機能が実現されることは言うまでもない。
このタスクスケジューリングプログラムは、イベント対応処理を実現するためのタスクと、起床要求プログラムと、ＲＴＯＳとを有している。そして、起床要求プログラムがイベントの発生を検知して該当するタスクの起床を要求すると、ＲＴＯＳは、起床要求プログラムからの要求に応じ、設定された優先度に基づいてタスクを起床する。
【００１４】
このとき、タスクに複数のイベント対応処理が記述されている場合には、起床要求プログラムが、該当するイベント対応処理を特定するための識別情報をメモリ領域に格納し、一方、タスクは、当該メモリ領域に格納された識別情報を読み出して、該当するイベント対応処理を特定し、実行する。
【００１５】
このような基本構成を前提として、本発明では、特定イベントに対しては、当該特定イベント毎に、当該特定イベントに対応するイベント対応処理のみを実現するための専用タスクを用意することによって、識別情報によるイベント対応処理の特定を不要にした。
即ち、本発明のタスクスケジューリングプログラムは、特定イベントについては、特定イベント毎に、その特定イベントに対応するイベント対応処理を実現する専用タスクを備え、特定イベント以外のイベントについては、複数のイベント対応処理が記述された共有タスクを備える。
起床要求プログラムは、起床要求対象のタスクが共有タスクである場合にのみ、該当するイベント対応処理を特定するための識別情報をメモリ領域に格納する。また、タスクについては、共有タスクのみが、メモリ領域に格納された識別情報を読み出して、この識別情報に基づき、該当するイベント対応処理を特定するプログラムを備え、専用タスクは、これを有しない。
【００１６】
つまり、本発明の技術思想は、イベントとタスクとを１対１に対応させることによって、従来技術で説明したような識別情報のキューイングを不要にし、ＣＰＵの処理負荷を軽減するものである。
なお、特定イベントは、発生するイベントの一部とすることが考えられる。全てのイベントとタスクとを１対１に対応させてもよいが、その場合には、タスク数が膨大になり、ＲＴＯＳの管理情報が多くなってしまうからである。また、イベントによって識別情報のキューイングが連続的に生じることによってＣＰＵの処理負荷が増大するという事実を考えると、単発的に発生するイベントに対して専用タスクを割り当てる必要性は小さい。
【００１７】
そこで、特定イベントは、時間に同期して発生する周期的なイベントとすることが考えられる。例えば所定時間間隔で繰り返し発生するイベントを特定イベントにするという具合である。また、請求項２に示すように、処理実行装置が所定の制御対象を制御する制御装置として実現されている場合、特定イベントは、制御対象の運転状態に同期して発生する周期的なイベントとしてもよい。ここで制御対象の一例としては、車両のエンジンが考えられる。制御対象が車両のエンジンである場合、請求項３に示すように、エンジンの回転に同期して発生するイベントを特定イベントにするという具合である。具体的には、エンジンのクランク軸の回転に同期した回転同期イベントを特定イベントにするという具合である。
【００１８】
このように周期的に繰り返されるイベントを特定イベントとして、この特定イベントに専用タスクを対応させ、識別情報のキューイングを不要にすれば、ＣＰＵの処理負荷を大幅に削減することができる。
また、例えば制御対象が車両のエンジンなどである場合、モデルチェンジのタイミングや設計変更などで、追加／削除されるイベントもある。このようなイベントの追加／削除があると、該当するイベント対応処理の変更が必要になる。しかし、専用タスクとしてそのイベント対応処理を実現する場合、タスク構成自体を変更する必要が生じて、変更作業に手間がかかる。
【００１９】
そこで、本装置を含むシステムの変更があっても追加あるいは削除される可能性が相対的に小さなイベントを、特定イベントとすることが望ましい。このようにすれば結果的に、専用タスクを変更する必要が少なくなり、タスク構成自体の変更が少なくなって、イベントの追加／削除による変更作業が容易になるからである。
【００２０】
さらにまた、上述したイベントはイベント対応処理のトリガとなるものであるが、このようなトリガに加え処理対象のデータを含むメッセージ（イベント＋データ）が存在する。この場合には、このデータの受け渡しにおいてキューイングが必要になるため、専用タスクとしてもデータのキューイングは発生することになる。したがって、請求項４に示すように、起床要求プログラムからタスクへのデータの受け渡しを必要としないイベントを、特定イベントとすることが考えられる。
【００２１】
なお、車両のエンジンを制御対象とする場合、周期的なイベントは、一般的に追加／削除される可能性が少なく、また、データの受け渡しを要しない場合が多い。
ところで、請求項５に示すように、上述してきた発明において、特定イベント以外のイベントに対応するイベント対応処理は、従来技術と同様に、優先度毎に用意された共有タスクで実現することが考えられる。タスクの切り換えを優先度毎に行うＲＴＯＳの管理手法から見て適切だからであり、また、タスクの総数を抑えることができ、ＲＴＯＳによる管理情報を比較的少なくできるためである。管理情報が減少すれば、ＲＡＭといったメモリの記憶容量を削減できる。つまり、ＣＰＵの処理負荷低減に有効なイベントに対する処理は専用タスクとして実現し、一方、そうでないイベントに対する処理は優先度毎の共有タスクとして実現することによって、共有タスクとして実現した場合のメリットも享受できるのである。
【００２２】
なお、上述したタスクスケジューリングプログラムの場合、例えば、ＦＤ、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができる。この他、ＲＯＭやバックアップＲＡＭをコンピュータ読み取り可能な記録媒体としてプログラムを記録しておき、このＲＯＭあるいはバックアップＲＡＭをコンピュータシステムに組み込んで用いてもよい。
【００２３】
【発明の実施の形態】
以下、本発明を具体化した一実施例を図面を参照して説明する。
図１は、本発明の「処理実行装置」を具体化したエンジン制御装置（以下「ＥＣＵ」という。）１の構成を表すブロック図である。ＥＣＵ１は、車両に搭載された内燃機関型エンジンの制御を行う。
【００２４】
ＥＣＵ１は、エンジンのクランク軸が所定角度回転する毎にパルス状の信号を出力する回転角センサ、エンジンの特定の気筒のピストンが所定位置（例えば上死点：ＴＤＣ）にくる度にパルス状の信号を出力する基準位置センサ、エンジンの冷却水の温度を検出する水温センサ、及び酸素濃度を計測する酸素濃度センサ等、エンジンの運転状態を検出する様々なセンサ３０からの信号を入力して波形整形やＡ／Ｄ変換を行う入力回路２１と、入力回路２１からのセンサ信号に基づき、エンジンを制御するための様々な処理を実行するマイコン１０と、マイコン１０からの制御データに応じて、エンジンに取付けられたインジェクタ（燃料噴射装置）及びイグナイタ（点火装置）等のアクチュエータ４０を駆動する出力回路２２とを、備えている。
【００２５】
そして、マイコン１０には、プログラムを実行する周知のＣＰＵ１１と、ＣＰＵ１１によって実行されるプログラムを記憶するＲＯＭ１２と、ＣＰＵ１１による演算結果等を記憶するためのＲＡＭ１３と、入力回路２１及び出力回路２２との間で信号をやり取りするためのＩ／Ｏ１４と、各種レジスタやフリーランカウンタ等（図示省略）とが備えられている。
【００２６】
このように構成されたＥＣＵ１は、各種センサ３０から入力回路２１を介して入力される信号に基づき、出力回路２２に接続されたアクチュエータ４０を駆動する、エンジン制御処理を行う。
次に図２に基づき、ＲＯＭ１２に記憶される「タスクスケジューリングプログラム」としてのエンジン制御プログラムの構成を説明する。エンジン制御プログラムは、少なくとも、起床要求プログラム１２ａ、ＲＴＯＳ１２ｂ、及び、タスク１２ｃ，１２ｄから構成されている。
【００２７】
起床要求プログラム１２ａの実行により、イベントの発生が検知されると、起床要求プログラム１２ａ中の起床要求処理が実行される。この起床要求処理では、検知されたイベントに対応するタスク１２ｃ，１２ｄを特定し、ＲＴＯＳ１２ｂに対して、タスク１２ｃ，１２ｄの起床を要求する。なお、イベントの発生は、上述したセンサ群３０からの信号に基づいて検知することが考えられる。また、マイコン１０内部のフリーランカウンタによって検知することが考えられる。さらに、車内ＬＡＮ等のネットワーク情報によって検知することが考えられる。
【００２８】
ＲＴＯＳ１２ｂは、タスク１２ｃ，１２ｄの起床要求があると、起床要求のあったタスク１２ｃ，１２ｄが実行中でない場合で、かつ、既に起床されているタスク１２ｃ，１２ｄの優先度が起床要求のあったタスク１２ｃ，１２ｄの優先度よりも低い場合に、起床要求のあったタスク１２ｃ，１２ｄを起床する。これによって優先度に基づくタスク１２ｃ，１２ｄの起床（切り換え）が行われ、リアルタイム性の高いタスク１２ｃ，１２ｄが優先的に実行される。
【００２９】
特に本実施例では、タスク１２ｃ，１２ｄの構成を工夫しており、Ａ，Ｂ，Ｃの３つの共有タスク１２ｃと、Ｄ，Ｅ，Ｆ，Ｇ，Ｈ，Ｉ，Ｊの７つの専用タスク１２ｄを備える構成とした。
本実施例では、特定のイベントに対しては、そのイベントに対応するイベント対応処理のみを実現するＤ〜Ｊの専用タスク１２ｄを用意した。ここで特定のイベントとは、制御対象であるエンジン回転に同期して発生するイベント及び、時間に同期して発生する所定時間間隔のイベントである。すなわち、図２では、図５に示した処理の中の、１ｍｓ処理、４ｍｓ処理、８ｍｓ処理、１６ｍｓ処理、３２ｍｓ処理、３０°ＣＡ処理、及びＴｄｃ処理が、Ｄ〜Ｊのそれぞれの専用タスク１２ｄに記述されている。
【００３０】
一方、特定イベント以外のイベントに対応する処理については、優先度毎に用意されたＡ〜Ｃの共有タスク１２ｃに記述した。図２では、図５に示した処理の中の、エンスト処理、故障検出処理が、中優先度のＢ共有タスクに記述されている。
【００３１】
次に、起床要求処理及びタスク処理が共有タスク１２ｃと専用タスク１２ｄとでどのように異なるかを、図３及び図４のフローチャートを用いて説明する。ここでは最初に共有タスク１２ｃの場合を説明し、続けて専用タスク１２ｄの場合を説明する。
【００３２】
図３（ａ）は、共有タスク１２ｃの起床を要求する起床要求処理を示すフローチャートである。
まず最初のステップ（以下、ステップを単に記号Ｓで示す。）１００において、タスク１２ｃを選択する。この処理は、発生したイベントに対応する処理を特定するためのＩＤに基づいて行われる。
【００３３】
続くＳ１１０では、ＩＤをキューに記憶する。そして必要であれば、ＩＤと共にデータもキューに記憶する。このデータはイベントに関連するものであり、この処理は、共有タスク１２ｃに受け渡す必要がある場合に行われる。
続くＳ１２０では、Ｓ１００にて選択した共有タスク１２ｃの起床を、ＲＴＯＳ１２ｂに対して要求する。そして、その後、本起床要求処理を終了する。
【００３４】
このような起床要求処理によって、上述したようにＲＴＯＳ１２ｂが該当する共有タスク１２ｃを起床する。
図３（ｂ）は、ＲＴＯＳ１２ｂに起床された共有タスク１２ｃにおけるタスク処理を示すフローチャートである。
【００３５】
まず最初のＳ２００では、キューに記憶されたＩＤを読み出して取得する。そして、上述したようにイベントに関連するデータがキューに記憶されている場合には、そのデータもＩＤと共に読み出して取得する。
次のＳ２１０では、ＩＤに基づき、実行対象のイベント対応処理を特定する。
【００３６】
そして続くＳ２２０ではＩＤより特定したイベント対応処理を実行し、その後、本タスク処理を終了する。
このように共有タスク１２ｃは優先度毎に用意されており、１つの共有タスク１２ｃに複数のイベント対応処理が記述されている。そのため、共有タスク１２ｃに係る起床要求処理（図３（ａ）参照）では、イベント対応処理を特定するためのＩＤをキューに記憶する必要がある（Ｓ１１０）。一方、タスク処理（図３（ｂ）参照）では、ＩＤをキューから取得し（Ｓ２００）、さらに、ＩＤに基づいてイベント対応処理を特定する必要がある（Ｓ２１０）。
【００３７】
これに対し、専用タスク１２ｄに係る起床要求処理及びタスク処理を次に説明する。
図４（ａ）は、専用タスク１２ｄの起床を要求する起床要求処理を示すフローチャートである。
【００３８】
まず最初のＳ３００において、専用タスク１２ｄを選択する。この処理は、共有タスクに係る処理（図３（ａ）中のＳ１００）と同様のものであり、発生したイベントに対応する処理を特定するためのＩＤに基づいて行われる。
そして専用タスク１２ｄは特定イベントに１対１に対応させて用意され、そのイベントに対応するイベント対応処理のみが記述されている。したがって、Ｓ３００におけるタスク選択後、次のＳ３１０では専用タスク１２ｄの起床要求を行い、その後、本起床要求処理を終了する。
【００３９】
つまり、共有タスク１２ｃの場合と異なり、図３（ａ）の起床要求処理に示したＳ１１０に相当する処理が不要になる。
起床要求処理によって、上述したようにＲＴＯＳ１２ｂが該当する専用タスク１２ｄを起床する。
【００４０】
図４（ｂ）は、ＲＴＯＳ１２ｂに起床された専用タスク１２ｄにおけるタスク処理を示すフローチャートである。
専用タスク１２ｄには、ある特定イベントに対応するイベント対応処理のみが記述されているため、Ｓ４００にてそのイベント対応処理を実行し、その後、本タスク処理を終了する。
【００４１】
つまり、図３（ｂ）中のＳ２００及びＳ２１０に相当する処理が不要になる。以上のようにタスク１２ｃ，１２ｄを構成したことによる効果を、次に説明する。
上述したようなＩＤの記憶（図３（ａ）中のＳ１１０）及び取得（図３（ｂ）中のＳ２００）では、キューが空であるか否かのチェックやキューが情報で一杯になっているか否かのチェックも必要になるため、発生する全てのイベントに対して、これらの処理が発生することによって、ＣＰＵの処理負荷が大きくなっていた。特に、エンジン回転に同期したイベントや時間に同期したイベントといった周期的なイベント発生によるＩＤのキューイングがＣＰＵの処理負荷を増大させていた。
【００４２】
本実施例では、このような周期的なイベントを特定イベントとし、これらのイベントに関しては、イベント毎に用意される専用タスク１２ｄにて、イベント対応処理を実現する。これによって、上述したような、ＩＤの記憶（図３（ａ）中のＳ１１０）及び取得（図３（ｂ）中のＳ２００）が不要になる。これによって、周期的なイベントによるＩＤのキューイングがなくなるため、ＣＰＵの処理負荷を大幅に低減することができる。
【００４３】
また、本実施例では、周期的なイベント、すなわち、ＣＰＵの処理負荷低減に有効なイベントに対する処理は専用タスク１２ｄとして実現し、一方、そうでないイベントに対する処理は優先度毎の共有タスク１２ｃとして実現した。
例えばエンジンストールや故障検出といった単発的なイベントにおいては、ＩＤのキューイングが発生しても、その処理時間がそれほど問題にならないからである。そして、このようなイベント対応処理を優先度毎に用意された共有タスク１２ｃにて実現すれば、優先度に基づいてタスク１２ｃ，１２ｄを起床するＲＴＯＳの管理手法から見て適切であり、また、タスクの総数を抑えることができ、ＲＴＯＳによる管理情報を比較的少なくできる。管理情報が減少すれば、ＲＡＭといったメモリの記憶容量を削減できる。つまり、本実施例によれば、ＣＰＵ１１の処理負荷を低減すると共に、共有タスク１２ｃとして実現した場合のメリットも享受できるのである。
【００４４】
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
（イ）例えば、上記実施例では、特定イベントを、エンジンの回転に同期して発生するイベント及び時間に同期して発生するイベントとしていたが、ＥＣＵ１を含むエンジン制御システムの変更を考慮して特定イベントを決定することも考えられる。すなわち、システムの変更時に追加あるいは削除される可能性が相対的に小さなイベントを、特定イベントとする。このようにすればシステムの変更があっても、専用タスク１２ｄを変更する必要が少なくなり、タスク構成自体の変更が少なくなって、イベントの追加／削除に伴うプログラムの変更作業が容易になる。
【００４５】
（ロ）上述したイベントはイベント対応処理のトリガとなるものであるが、このようなトリガと共に処理対象のデータを含むメッセージ（イベント＋データ）が存在する。この場合には、このデータの受け渡しにおいてキューイングが必要になるため、専用タスク１２ｄとしてイベント対応処理を実現しても、図３（ａ）中のＳ１１０におけるデータの格納処理、及び図３（ｂ）中のＳ２００におけるデータの取得処理が必要になり、ＩＤのキューイングを不要にしてもＣＰＵの処理負荷がほとんど変わらない。したがって、起床要求プログラム１２ａからタスク１２ｃ，１２ｄへのデータの受け渡しを必要としないイベントを、特定イベントとすることが好ましい。
【００４６】
（ハ）上記実施例は、車両のエンジンを制御するＥＣＵ１として本発明を具現化したものであった。これに対し、ＲＴＯＳによるタスクスケジューリングを行う全ての処理実行装置に本発明が適用できることは言うまでもない。
【図面の簡単な説明】
【図１】実施例のエンジン制御装置の構成を表すブロック図である。
【図２】エンジン制御プログラムの構造を示す説明図である。
【図３】共有タスクに係る起床要求処理及びタスク処理を示すフローチャートである。
【図４】専用タスクに係る起床要求処理及びタスク処理を示すフローチャートである。
【図５】従来のタスクスケジューリングプログラムの構造を示す説明図である。
【符号の説明】
１…ＥＣＵ１０…マイコン
１１…ＣＰＵ１２…ＲＯＭ
１２ａ…起床要求プログラム１２ｂ…ＲＴＯＳ
１２ｃ…共有タスク１２ｄ…専用タスク
１３…ＲＡＭ１４…Ｉ／Ｏ
２１…入力回路２２…出力回路
３０…センサ４０…アクチュエータ

Claims

ＣＰＵと、そのＣＰＵに、所定のイベントの発生を検知させ、イベントに応じたイベント対応処理を実行させるためのタスクスケジューリングプログラムと、を備える処理実行装置であって、
前記タスクスケジューリングプログラムは、
前記イベント対応処理をＣＰＵに実行させるためのタスクと、
前記イベントの発生を検知し、該当するタスクの起床を要求する手順を、ＣＰＵに実行させるための起床要求プログラムと、
タスクの起床要求に対し、設定された優先度に基づいて前記タスクを起床する手順を、ＣＰＵに実行させるためのリアルタイムオペレーティングシステムと、
を有し、
前記タスクとして、時間に同期して発生する周期的なイベントを含む特定イベントについては、特定イベント毎に、その特定イベントに対応するイベント対応処理をＣＰＵに実行させるための専用タスクを有し、前記特定イベント以外のイベントについては、複数のイベント対応処理が記述された共有タスクを有し、
前記起床要求プログラムは、起床要求対象のタスクが共有タスクである場合にのみ、ＣＰＵが、そのタスクの起床要求と共に、該当するイベント対応処理を特定するための識別情報をメモリ領域に格納するように構成され、
前記タスクについては、前記共有タスクのみが、前記メモリ領域に格納された前記識別情報を読み出し、この識別情報に基づき、該当するイベント対応処理を特定する手順をＣＰＵに実行させるためのプログラムを有し、前記専用タスクは、このプログラムを有しないこと
を特徴とする処理実行装置。
ＣＰＵと、そのＣＰＵに、所定のイベントの発生を検知させ、イベントに応じたイベント対応処理を実行させるためのタスクスケジューリングプログラムと、を備え、このタスクスケジューリングプログラムを用いて、所定の制御対象を制御する構成にされた処理実行装置であって、
前記タスクスケジューリングプログラムは、
前記イベント対応処理をＣＰＵに実行させるためのタスクと、
前記イベントの発生を検知し、該当するタスクの起床を要求する手順を、ＣＰＵに実行させるための起床要求プログラムと、
タスクの起床要求に対し、設定された優先度に基づいて前記タスクを起床する手順を、ＣＰＵに実行させるためのリアルタイムオペレーティングシステムと、
を有し、
前記タスクとして、前記制御対象の運転状態に同期して発生する周期的なイベントを含む特定イベントについては、特定イベント毎に、その特定イベントに対応するイベント対応処理をＣＰＵに実行させるための専用タスクを有し、前記特定イベント以外のイベントについては、複数のイベント対応処理が記述された共有タスクを有し、
前記起床要求プログラムは、起床要求対象のタスクが共有タスクである場合にのみ、ＣＰＵが、そのタスクの起床要求と共に、該当するイベント対応処理を特定するための識別情報をメモリ領域に格納するように構成され、
前記タスクについては、前記共有タスクのみが、前記メモリ領域に格納された前記識別情報を読み出し、この識別情報に基づき、該当するイベント対応処理を特定する手順をＣＰＵに実行させるためのプログラムを有し、前記専用タスクは、このプログラムを有しないこと
を特徴とする処理実行装置。
前記制御対象の運転状態に同期して発生する周期的なイベントは、前記制御対象としてのエンジンの回転に同期して発生するイベントであることを特徴とする請求項２記載の処理実行装置。
前記特定イベントは、前記起床要求プログラムから前記タスクへのデータの受け渡しを必要としないイベントであること
を特徴とする請求項１〜３のいずれかに記載の処理実行装置。
前記共有タスクは、優先度毎に用意されており、
前記特定イベント以外のイベントに対応するイベント対応処理は、前記優先度毎に用意された共有タスクで実現されること
を特徴とする請求項１〜４のいずれかに記載の処理実行装置。
コンピュータに、所定のイベントの発生を検知させ、当該イベントに応じたイベント対応処理を実行させるためのタスクスケジューリングプログラムであって、
前記イベント対応処理をコンピュータに実行させるためのタスクと、
前記イベントの発生を検知し、該当するタスクの起床を要求する手順を、コンピュータに実行させるための起床要求プログラムと、
タスクの起床要求に対し、設定された優先度に基づいて前記タスクを起床する手順を、コンピュータに実行させるためのリアルタイムオペレーティングシステムと、
を有し、
前記タスクとして、時間に同期して発生する周期的なイベントを含む特定イベントについては、特定イベント毎に、その特定イベントに対応するイベント対応処理をコンピュータに実行させるための専用タスクを有し、前記特定イベント以外のイベントについては、複数のイベント対応処理が記述された共有タスクを有し、
前記起床要求プログラムは、起床要求対象のタスクが共有タスクである場合にのみ、コンピュータが、そのタスクの起床要求と共に、該当するイベント対応処理を特定するための識別情報をメモリ領域に格納するように構成され、
前記タスクについては、前記共有タスクのみが、前記メモリ領域に格納された前記識別情報を読み出し、この識別情報に基づき、該当するイベント対応処理を特定する手順をコンピュータに実行させるためのプログラムを有し、前記専用タスクは、このプログラムを有しないこと
を特徴とするタスクスケジューリングプログラムを記録したコンピュータ読み取り可能な記録媒体。
所定の制御対象を制御するコンピュータに、所定のイベントの発生を検知させ、当該イベントに応じたイベント対応処理を実行させるためのタスクスケジューリングプログラムであって、
前記イベント対応処理をコンピュータに実行させるためのタスクと、
前記イベントの発生を検知し、該当するタスクの起床を要求する手順を、コンピュータに実行させるための起床要求プログラムと、
タスクの起床要求に対し、設定された優先度に基づいて前記タスクを起床する手順を、コンピュータに実行させるためのリアルタイムオペレーティングシステムと、
を有し、
前記タスクとして、前記制御対象の運転状態に同期して発生する周期的なイベントを含む特定イベントについては、特定イベント毎に、その特定イベントに対応するイベント対応処理をコンピュータに実行させるための専用タスクを有し、前記特定イベント以外のイベントについては、複数のイベント対応処理が記述された共有タスクを有し、
前記起床要求プログラムは、起床要求対象のタスクが共有タスクである場合にのみ、コンピュータが、そのタスクの起床要求と共に、該当するイベント対応処理を特定するための識別情報をメモリ領域に格納するように構成され、
前記タスクについては、前記共有タスクのみが、前記メモリ領域に格納された前記識別情報を読み出し、この識別情報に基づき、該当するイベント対応処理を特定する手順をコンピュータに実行させるためのプログラムを有し、前記専用タスクは、このプログラムを有しないこと
を特徴とするタスクスケジューリングプログラムを記録したコンピュータ読み取り可能な記録媒体。