(57)【特許請求の範囲】
【請求項１】
時間的制約が課されたタスクである実務タスクの起床を求める起床要求を発行する起床要求手段を備え、前記起床要求手段からの起床要求を、予め定められた上限数まで格納可能な記憶領域にキューイングし、該記憶領域に格納された起床要求に基づいて該起床要求の対象である実務タスクを起床させるよう構成されると共に、該記憶領域に格納された起床要求が該上限数に達しているときには、前記起床要求手段からの起床要求を却下するよう構成されたコンピュータにおいて、該コンピュータの処理負荷を測定する方法であって、
測定時間内における前記実務タスクの実際の処理時間の積算時間を求める実処理時間算出ステップと、
前記測定時間内において却下された起床要求の対象である実務タスクに対応する処理時間を、予め求めた実務タスクの処理時間を記憶する処理時間記憶手段から読み出して積算することにより、該却下された起床要求の対象である実務タスクの仮想の処理時間の積算時間を求める仮想処理時間算出ステップと、
を備えたことを特徴とする処理負荷測定方法。
【請求項２】
請求項１に記載の処理負荷測定方法において、
前記測定時間に対する、前記実際の処理時間の積算時間と前記仮想の処理時間の積算時間との和の比率を求めることを特徴とする処理負荷測定方法。
【請求項３】
時間的制約が課されたタスクである実務タスクの起床を求める起床要求を発行する起床要求手段を備え、前記起床要求手段からの起床要求を、予め定められた上限数まで格納可能な記憶領域にキューイングし、該記憶領域に格納された起床要求に基づいて該起床要求の対象である実務タスクを起床させるよう構成されると共に、該記憶領域に格納された起床要求が該上限数に達しているときには、前記起床要求手段からの起床要求を却下するよう構成されたコンピュータにおいて、該コンピュータの処理負荷を測定する装置であって、
測定時間内における前記実務タスクの実際の処理時間の積算時間を求める実処理時間算出手段と、
予め求めた実務タスクの処理時間を記憶する処理時間記憶手段と、
前記測定時間内において却下された起床要求の対象である実務タスクに対応する処理時間を前記処理時間記憶手段から読み出して積算することにより、該却下された起床要求の対象である実務タスクの仮想の処理時間の積算時間を求める仮想処理時間算出手段と、
を備えたことを特徴とする処理負荷測定装置。
【請求項４】
請求項３に記載の処理負荷測定装置において、
前記測定時間に対する、前記実際の処理時間の積算時間と前記仮想の処理時間の積算時間との和の比率である負荷率を求める負荷率算出手段を備えたことを特徴とする処理負荷測定装置。
【請求項５】
請求項３又は４に記載の処理負荷測定装置において、
前記実処理時間算出手段は、起床された実務タスクの開始時刻および終了時刻を検出可能に構成され、該検出結果に基づいて前記実際の処理時間の積算時間を求めること
を特徴とする処理負荷測定装置。
【請求項６】
請求項５に記載の処理負荷測定装置において、
前記コンピュータは、起床されている実務タスクがないとき、時間的制約のないタスクであるアイドルタスクを起床するよう構成され、
前記実処理時間算出手段は、前記開始時刻として前記アイドルタスクから前記実務タスクへの切り替わり時刻を検出すると共に、前記終了時刻として前記実務タスクから前記アイドルタスクへの切り替わり時刻を検出し、該両検出結果に基づいて前記実際の処理時間の積算時間を算出すること
を特徴とする処理負荷測定装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、コンピュータの処理負荷を測定する方法および装置に関する。
【０００２】
【従来の技術】
例えば車両に搭載される電子制御装置（以下「ＥＣＵ」という。）を構成するコンピュータなどでは、制御応答性や安全性の確保等から、処理に時間的制約が課される。そのため、優先度の設定されたタスクの単位でプログラムを記述し、ＲＴＯＳによるタスクの切り換えによって、リアルタイム性を確保するようにしている。タスクは、信号入力等のイベントに応じて発行される起床要求に応じて起床されるものであるが、その起床要求は一旦キューに格納され、その格納内容に基づいてタスクの実行が行われる。
【０００３】
こうしたＥＣＵにおいて、その処理負荷が増大すると、タスクの実行抜け（処理抜け）が生じる。即ち、複数の起床要求が短期間の間に発行された場合には、起床要求がキューにたまることになる。しかしキューの容量には上限があるため、キューに登録された起床要求の数が上限数に達した状態になると、それ以上の起床要求はキューに格納できないので却下される（即ちキューイングされない）。従って、所定数を越える起床要求が一時期に集中して発行された場合においては、発行されたはずの起床要求の対象であるタスクが実行されない、といった処理抜けが発生する可能性がある。
【０００４】
そこで、どの程度の処理負荷がかかるのかを知ることは、こうした実行抜けが生じないような適切なＥＣＵを構築する上で重要である。
従来、上記のようにリアルタイム性が要求されるコンピュータの処理負荷を測定する技術としては、例えば特開平１−１７１０４０号公報に記載のものが知られている。この技術は、リアルタイム性が課されないアイドルタスクを用意し、そのアイドルタスクの実行時間をカウンタを使用して計測するものである。
【０００５】
しかし、この技術では、アイドルタスク中にインクリメントされるカウンタを時間に換算して負荷率を算出するため、実務タスクのみが実行され、アイドルタスクが実行されない過負荷状態においては、どの程度の過負荷が生じているかを計測することができない。なお、ここで実務タスクとは、リアルタイム性が要求される（即ち時間的制約が課される）タスクである。
【０００６】
そこで、特開平１１−２３２１４８号公報に記載されている様に、過負荷状態時でも具体的な処理負荷の計測を可能とすることを目的とした技術が提案されている。この技術では、実務タスクの中で優先度が最低のタスクである”タスクＲ”の処理遅れを、上位の優先度タスクＫからモニタする事により、過負荷状態においても処理負荷の程度を検出できるようにしている。具体的には、タスクＫがモニタを行うサンプル回数（理論実行回数）と、タスクＲが処理遅れなしでモニタされた回数（実行完了回数）との比から、過負荷の程度を示す数値（過負荷率）を算出することとしている。
【０００７】
【発明が解決しようとする課題】
ところで、特開平１１−２３２１４８号公報記載の技術では、測定時間のうちの実際の処理時間の割合を「ＣＰＵ占有率」として求めつつ、タスクＲについての実際の”実行完了回数”に対する”理論実行回数”の比を「過負荷率」として求めているが、「過負荷率」はタスクＲの実行回数に対する比率である点で、「ＣＰＵ占有率」とは異なる意味を持つ数値である。そのため、上記の様に求められる「過負荷率」では、処理抜けがないコンピュータシステムを構築する上で、各実務タスクの処理の追加や削除をどの様にどの程度行えば良いか、またどの程度の性能を有するハードウェアを用いると適切であるかを推測することは困難といえる。
【０００８】
また、特開平１１−２３２１４８号公報記載の技術では、タスクＲよりも優先度が高いタスクの処理抜けについては負荷率に反映されないため、処理負荷を的確に把握することができない可能性がある。
本発明は、こうした課題を背景としてなされたものであり、コンピュータの処理負荷をより正確に把握可能とすることを目的とする。
【０００９】
【課題を解決するための手段及び発明の効果】
上記課題を解決するために成された本発明（請求項１記載）の処理負荷測定方法は、起床要求手段を備えたコンピュータの処理負荷を測定するものであり、測定時間内における前記実務タスクの実際の処理時間の積算時間を求める実処理時間算出ステップと、同測定時間内において却下された起床要求の対象である実務タスクに対応する処理時間を、予め求めた実務タスクの処理時間を記憶する処理時間記憶手段から読み出して積算することにより、該却下された起床要求の対象である実務タスクの仮想の処理時間の積算時間を求める仮想処理時間算出ステップとを備える。
【００１０】
仮想の処理時間の積算時間とは、起床要求が却下されたために実際には起床されなかった実務タスクについて、その実務タスクが仮に起床されたとするとどれだけの処理時間が必要であったかを示すものである。実務タスク単体の処理時間については、例えばステップ数等から見積もったり、単体テストの際に予め実測したりすることによって予め求めておき、これに基づいて仮想の処理時間の積算時間を求めるのである。
【００１１】
以上の様に求められる両積算時間（即ち、実際の処理時間の積算および仮想の処理時間の積算）は、測定時間内において実行されるべきであった処理量全体を示すものである。即ち本発明の処理負荷測定方法によれば、実際の処理時間の積算時間だけでなく、その仮想の処理時間の積算時間を求めることができるので、過負荷の程度についても知ることができる。
【００１２】
また、請求項１の処理負荷測定方法においては、過負荷の程度を、仮想の処理時間の積算時間から知ることができるが、これは与えられた測定時間の中で処理できなかった仕事量を、直接的に示すものである。そのため、処理抜けがないコンピュータシステムを構築する上で、各実務タスクの処理内容の追加や削除をどの様にどの程度行えば良いか、またどの程度の性能を有するハードウェアを用いると適切であるかを推測することが容易となる。
【００１３】
また、請求項１の処理負荷測定方法では、実行に移されなかった実務タスクの仮想の処理時間はすべて積算される。つまり、従来の技術とは異なり、優先度が最低の実務タスクについての処理抜けだけでなく、それよりも優先度の高い実務タスクについての処理抜けについても検出しているので、過負荷の程度をより正確に求めることができる。
【００１４】
なお、測定時間を一定に設定している場合には、上述の様に積算時間を求めるだけで処理負荷を求めることができるが、測定時間が一定でない場合には、測定時間に対する各積算時間の比率を夫々求めればよい。
また、請求項２に記載の様に、負荷率γとして、測定時間に対する、「実際の処理時間の積算時間」と「仮想の処理時間の積算時間」との和の比率を求めることとすれば、全体的に、どれだけの処理が過剰となっているかを把握することができるので、コンピュータシステムを適切に構築する上で、各実務タスクの処理内容の追加や削除をどの様にどの程度行えば良いか、またどの程度の性能を有するハードウェアを用いると適切であるかを把握することが、更に容易となる。
【００１５】
次に請求項３に記載の処理負荷測定装置は、上記処理負荷測定方法に直接使用するものである。この装置においては、実処理時間算出手段が、測定時間内における実務タスクの実際の処理時間の積算時間を求める。また、予め求めた実務タスクの処理時間を処理時間記憶手段が記憶している。そして、仮想処理時間算出手段が、上記測定時間内において却下された起床要求の対象である実務タスクに対応する処理時間を、処理時間記憶手段から読み出して積算する。これにより仮想処理時間算出手段は、却下された起床要求の対象である実務タスクの仮想の処理時間の積算時間を求める。
【００１６】
即ち、請求項３記載の処理負荷測定装置においては、測定時間内において起床された実務タスクによって実際に行われた処理の時間（即ち、実際の処理時間）の積算時間を求めると共に、却下された起床要求の対象であった実務タスクの仮想の処理時間の積算時間を求める。従って、請求項１の処理負荷測定方法を実現することができ、これと同様の効果を得ることができる。
【００１７】
また請求項４に記載の様に、測定時間に対する、「実際の処理時間の積算時間」と「仮想の処理時間の積算時間」との和の比率である負荷率を求める負荷率算出手段を設ければ、請求項２の処理負荷測定方法を実現することができ、これと同様の効果を得ることができる。
【００１８】
ところで従来の技術においては、アイドルタスクの処理時間の積算時間から間接的に実務タスクの処理時間の積算時間を算出するものであり、特開平１−１７１０４０号公報記載の技術ではアイドルタスクの実行時間が一定であることを前提とし、また特開平１１−２３２１４８号公報記載の技術においては、アイドルタスクで、それ自体の実行時間を計測する構成となっていた。ＲＡＭの誤り訂正など、必ずしも定期的に行う必要のない処理（即ち時間的制約のない処理）については、実務タスクとして実行するのではなくアイドルタスクの処理として追加した方が制御の効率化を図る上で好ましいが、従来は、それが制限されていた。
【００１９】
そこで請求項５に記載の様に、実処理時間算出手段を構成すると良い。即ち、起床された実務タスクの起床時刻および終了時刻を検出可能とし、その検出結果に基づいて、現実の処理時間の積算時間を求めるよう、実処理時間算出手段を構成するとよい。
【００２０】
つまり、請求項５記載の処理負荷測定装置においては、アイドルタスクの実行時間から間接的に実務タスクの実行時間を算出するのではなく、実務タスクの開始および終了時刻からその処理時間を直接求める構成となっている。このためアイドルタスクを敢えて設ける必要もないし、また、アイドルタスクが設けられている場合には、そのアイドルタスクへの処理（例えば、ＲＡＭの記憶内容の誤り訂正など）の追加を自由に行うことができる。
【００２１】
また、起床されている実務タスクがないとき、時間的制約のないタスクであるアイドルタスクを起床するようコンピュータが構成されているときには、請求項６に記載の様に、実処理時間算出手段を構成すると良い。
即ち、起床時刻および終了時刻として、アイドルタスクから実務タスクへの切り替わり時刻、および、実務タスクからアイドルタスクへの切り替わり時刻を検出し、その検出結果に基づいて、実務タスクの現実の処理時間の積算時間を算出するように実処理時間算出手段を構成すると良い。
【００２２】
こうすれば、全ての実務タスクの開始および終了時刻を一々検出する必要がなく、アイドルタスクから実務タスクへの切り替わり時刻、および、実務タスクからアイドルタスクへの切り替わり時刻だけを検出することで、簡便に、実務タスクの実際の処理時間の積算時間を算出することができるので好ましい。
【００２３】
【発明の実施の形態】
以下に、本発明の処理負荷測定方法および装置の一実施例を説明する。
図１は、処理負荷測定装置の一実施例として、自動車のエンジンを制御するエンジン制御装置２（以下、単に「ＥＣＵ２」という）の電気的構成を示す説明図である。本実施例では、処理負荷の測定対象はコンピュータとしてのＥＣＵ２であり、処理負荷測定装置は、当該ＥＣＵ２に組み込まれている。
【００２４】
図１に示すように、ＥＣＵ２は、エンジンの運転状態に応じた信号を出力するクランク角センサ２２などの各種センサから信号を取り込むための入力回路８と、入力回路８にて取り込まれた信号等に基づき、エンジンを制御するための処理を行うＣＰＵ１０と、一定周期でカウントアップするフリーランニングカウンタからなりＣＰＵ１０に対してカウント値を入力するタイマ１１と、ＣＰＵ１０からの制御信号を受けて、エンジンに燃料を噴射供給するインジェクタ２４などの各種アクチュエータを駆動する出力回路１２と、ＣＰＵ１０がエンジンを制御するのに必要な複数の制御プログラムや制御データなどを格納するＲＯＭ１４と、ＣＰＵ１０の演算結果等を一時的に格納するＲＡＭ１８とを備えている。
【００２５】
ＲＯＭ１４に格納された制御プログラムは、燃料噴射制御プログラム、点火時期制御プログラム、アイドル回転数制御プログラム、ダイアグノーシスプログラムなど複数のプログラムから構成されている。これらプログラムに従って行われる制御は、制御応答性、安全性等確保の観点から、リアルタイムＯＳ（ＲＴＯＳ）によるタスクの切り換え（ディスパッチ）によってリアルタイム処理方式で行われる。これらのプログラムにはそれぞれ優先度が設定されており、それらに従ってＣＰＵ１０が行う処理の実行単位である実務タスクにも、当該プログラムに対応した優先度が設定されている。
【００２６】
これら実務タスクは、時間に同期した内部的なパルスの発生、制御対象の周期的動作に同期した外部的なパルス（例えばクランクセンサ信号、車速センサ信号など）の発生など、様々なイベントの発生をトリガとして起床される。
イベントの発生はイベント管理モジュールにより検知され、イベント管理モジュールは、当該イベントに対応したタスクを起床させるべき旨の起床要求を発行する（図１（ｂ））。
【００２７】
またイベント管理モジュールからタスクの起床要求が発行されると、ＲＴＯＳは、起床すべきタスクを特定するための識別情報（以下、「ＩＤ」という）をＦＩＦＯ構造のキューにキューイングする。キューは、請求項における「記憶領域」に相当し、起床要求を予め定められた上限数まで格納可能である。またキューは、ＲＡＭ１８内において、タスクの優先度別に設けられており、ＩＤは起床要求を示すものとして、タスクの優先度に応じたキューに格納される。
【００２８】
ＲＴＯＳは、キューに格納されたＩＤから、タスクを特定して起床させる（図１（ｂ）参照）。なお、低い優先度のタスクの実行中に高い優先度のタスクの起床要求が発生した場合には、低優先度のタスクの処理が中断されて高優先度のタスクに切り替えられる。
【００２９】
また複数のＩＤがキューに格納されている場合には、上位の優先度から順に、キューからＩＤを読み出して、そのＩＤに対応するタスクを起床させる。一方、キューにＩＤが登録されていない状態、即ち起床要求がキューに格納されておらず、起床されている実務タスクがない状態においては、アイドルタスクが起床される。このアイドルタスクは最も優先度が低いタスクであり、そこでは、リアルタイム性が要求されない処理、例えばＲＡＭ１８のエラーチェックなどが行われる。
【００３０】
さて、本実施例のＥＣＵ２のＲＯＭ１４には、ＣＰＵ１０の負荷率の測定を開始させる測定開始プログラムが格納されている。この測定開始プログラムに従う処理は、ＥＣＵ２外部からの開始指令が入力されると、優先度の高いタスクに付随して実行される。
【００３１】
測定開始プログラムに従う処理（測定開始処理）では、図２に示す様に、この測定に用いるためにＲＡＭ１８に定義される各変数を初期化する（ステップ１０。以下、「ステップ」を「Ｓ」と記す）。例えば、実務タスク実行時間α、過負荷実行時間β、実務タスク終了時刻Finish#Timeのクリア、実務タスク開始時刻Start#Timeへの現在時刻の設定、当該測定の開始時刻（現在時刻）の記録などを行う。
【００３２】
なお、実務タスク実行時間αは、請求項の「実際の処理時間の積算時間」に相当し、過負荷実行時間βは請求項の「仮想の処理時間の積算時間」に相当する。また、実務タスク開始時刻Start#Timeは、請求項における「アイドルタスクから実務タスクへの切り替わり時刻」を格納する変数として機能し、また実務タスク終了時刻Finish#Timeは、請求項における「実務タスクからアイドルタスクへの切り替わり時刻」を格納する変数として機能する。
【００３３】
この様なＲＡＭ値の初期化を行った後、現在実行中のタスクのＩＤを、キューとは別個にＲＡＭ１８に設けられている記憶領域（以下「第１のＩＤ記憶領域」という。）に格納する（Ｓ２０）。その後、キューにＩＤが格納されている場合には、そのＩＤに基づいてタスクが起床され、キューにＩＤが格納されていない場合にはアイドルタスクが起床されることになる。
【００３４】
処理負荷の測定中においては、実務タスクの切り替わりの際、図３（ａ）に示す実務タスク実行時間α算出処理が起動される。この処理は、実務タスク実行時間αを測定するものである。
実務タスク実行時間α算出処理が起動されると、まず、前のタスク（即ち、ディスパッチ前に実行されていたタスク）がアイドルタスクかどうかを、第１のＩＤ記憶領域を参照して判断する（Ｓ３０）。処理負荷測定開始後の最初のディスパッチ時においては、Ｓ２０で格納されたＩＤが読み出されることになり、２回目以降のディスパッチ時においては、後述のＳ５０にて格納されるＩＤが読み出されることになる。
【００３５】
前のタスクがアイドルタスクであると判断されると（Ｓ３０：ＹＥＳ）、タイマ１１から現在時刻を読み出し、これを実務タスク開始時刻Start#Timeとして取得し（Ｓ４０）、Ｓ５０の処理に移行する。
一方、前のタスクがアイドルタスクであると判断されなかった場合は（Ｓ３０：ＮＯ）、Ｓ５０の処理に直接移行する。Ｓ５０は、次に起床されるタスクのＩＤを第１のＩＤ記憶領域に格納するステップである。
【００３６】
Ｓ５０が終わると、次に起床されるタスクがアイドルタスクかどうかを、キューに格納されているＩＤを参照することにより判断する（Ｓ６０）。ここで、次のタスクがアイドルタスクである場合には（Ｓ６０：ＹＥＳ）、実務タスクが終了したことを意味するので、タイマ１１から現在時刻を読み出し、実務タスク終了時刻Finish#Timeとして記憶する（Ｓ７０）。そして実務タスク終了時刻Finish#Timeと実務タスク開始時刻Start#Timeとの差を算出し、この算出結果を、実務タスク実行時間αに加算する（Ｓ８０）。
【００３７】
一方、次のタスクがアイドルタスクでないと判断された場合には（Ｓ６０：ＮＯ）、当該実務タスク実行時間α算出処理を直ちに終了する。
この様にして、実務タスク実行時間α算出処理においては、図３（ｂ）にも示す様に、アイドルタスクと実務タスクとの切り替わりタイミングを検出する。そしてアイドルタスクから実務タスクへの切替タイミング（Start#Time）と、実務タスクからアイドルタスクへの切替タイミング(Finish#Time)との時間差を求めることにより、実務タスクの処理時間を取得し、これを積算している。つまり、実務タスク実行時間α算出処理によって、請求項の「実処理時間算出手段」が実現されている。
【００３８】
ところで、複数の起床要求が短期間の間に発行された場合には、優先度が高く、しかも起床要求が早く発行されたタスクから順に起床されるので、比較的優先度の低いタスクのＩＤはキューに溜まりやすい傾向となる。各キューの容量には上限があるため、あるキューに登録されたＩＤの数が所定数（上限数）に達した状態になってしまうと、それ以上の起床要求が発行されても、その満杯のキューにはキューイングすることができない。即ち、所定数を越える起床要求が一時期に集中して発行された状態においては、起床要求が発行されてもタスクが実行されない、といった処理抜けが発生する可能性がある。このように起床要求が発行されたにも拘わらずＩＤがキューに登録されなかった場合には、ＲＴＯＳからイベント管理モジュールに対して、エラーを示す戻り値Errorが返される。
【００３９】
図４に示す起床要求発行処理は、処理負荷の測定中において、イベント管理モジュールがタスクの起床要求を発行するために行う処理である。
この起床要求発行処理では、まず起床要求の対象であるタスクのＩＤを上記第１のＩＤ記憶領域とは異なる第２のＩＤ記憶領域に格納する（Ｓ９０）。そして起床要求を発行した後（Ｓ１００）、ＲＴＯＳからの戻り値についての判断を行う（Ｓ１１０）。ここで、戻り値がErrorでなければ（Ｓ１１０：ＮＯ）、当該起床要求発行処理は直ちに終了するが、他方、戻り値がErrorである場合には（Ｓ１１０：ＹＥＳ）、図５に示す過負荷実行時間β算出処理で、過負荷実行時間βの算出を行った後（Ｓ１２０）、当該起床要求発行処理は終了する。過負荷実行時間βは、処理抜けによって起床されなかったタスクにより本来費やされるはずの”処理時間”の積算値を格納する変数である。なお、Ｓ１００の処理が、請求項の「起床要求手段」に相当する。
【００４０】
次に過負荷実行時間β算出処理では、図５に示す様に、Ｓ９０にて第２のＩＤ記憶領域に格納されたＩＤに基づいて所定の基本実行時間テーブルを検索することにより、実務タスクの基本実行時間を求め（Ｓ１３０）、過負荷実行時間βに加算する（Ｓ１４０）。基本実行時間は、その実務タスクが実際に実行された場合には必要であろう処理時間である。各実務タスク単体の基本実行時間は予め実測され、実務タスクのＩＤと対応させてＲＯＭ１４内の基本実行時間テーブルに記録されている。なお、基本実行時間テーブルが、請求項の「処理時間記憶手段」に相当し、基本実行時間が、請求項の「予め求めた実務タスクの処理時間」に相当する。
【００４１】
こうして、過負荷実行時間β算出処理では、処理抜けによって起床されなかったタスクにより本来費やされるはずの仮想的な処理時間の積算時間が算出される。つまり、過負荷実行時間β算出処理によって、請求項の「仮想処理時間算出手段」が実現される。
【００４２】
以上の様に、処理負荷の測定中においては、実務タスク実行時間αと過負荷実行時間βとが計算される。そして、測定開始から所定の測定予定時間（予め設定されている）が経過すると、図６に示す測定終了処理によって、実務タスク実行時間αと過負荷実行時間βとに基づき、ＣＰＵ１０の負荷率γ（後述）が算出される。
【００４３】
この測定終了処理は、処理負荷測定中において、処理抜けが起こりにくい高優先度の実務タスクとして実行されるものであり、起動されると、まずタイマ１１から現在時刻を取得し（Ｓ１５０）、測定開始時刻から測定予定時間が経過したかどうかを判断する（Ｓ１６０）。未だ測定予定時間が経過していなければ（Ｓ１６０：ＮＯ）、当該測定終了処理を直ちに終了するが、すでに測定予定時間が経過している場合には（Ｓ１６０：ＹＥＳ）、現在時刻を実務タスク終了時刻Finish#Timeに設定し（Ｓ１７０）、Ｓ８０と同様に、実務タスク終了時刻Finish#Timeと実務タスク開始時刻Start#Timeとの差を、実務タスク実行時間αに加算する（Ｓ１８０）。この様にして、実務タスク実行時間αは、図７に示す様に▲１▼〜▲６▼の処理時間の積算として求められる。そして本実施例では、以上の処理により求められた実務タスク実行時間αと過負荷実行時間βとに基づいて、次の式（Ａ）により、負荷率γ（％）を算出する（Ｓ１９０）。
【００４４】
負荷率γ（％）＝（実務タスク実行時間α＋過負荷実行時間β）÷測定時間×１００  …（Ａ）
ここで測定時間は、測定開始時刻（Ｓ１０の時刻）から測定終了時刻（Ｓ１５０の時刻）までの時間である。なお、Ｓ１９０の処理が、請求項の「負荷率算出手段」として機能する。
【００４５】
以上の様に、本実施例においては、実際の処理時間の積算として実務タスク実行時間αを求めるだけでなく、仮想の処理時間の積算として過負荷実行時間βを求めることができるので、過負荷の程度についても知ることができる。そして処理抜けがないＥＣＵを構築する上で、各実務タスクの処理内容の追加や削除をどの様にどの程度行えば良いか、また、どの程度の性能を有するハードウェアを用いると適切であるかを推測することが容易となる。
【００４６】
また、本実施例では、実行に移されなかった実務タスクの仮想の処理時間はすべて、過負荷実行時間βとして積算される。従って、従来よりも過負荷の程度をより正確に求めることができる。
また、本実施例では、アイドルタスクの実行時間から間接的に実務タスクの実行時間を算出するのではなく、アイドルタスクから実務タスクへの切り替わり時刻（Start#Time）および実務タスクからアイドルタスクへの切り替わり時刻（Finish#Time）を検出して、その検出結果から、実務タスクの処理時間を直接求める構成となっている。そのため、アイドルタスクとして行う処理の追加又は削除を自由に行うことができると共に、実務タスクの処理時間の積算値を簡便に求めることができる。
【００４７】
また、負荷率γとして、測定時間に対する実務タスク実行時間αと過負荷実行時間βとの和の比率を求めている。これにより、全体的に、どれだけの処理が過剰となっているかを把握することができるので、ＥＣＵを適切に構築する上で、各実務タスクの処理内容の追加や削除をどの様にどの程度行えば良いか、またどの程度の性能を有するハードウェアを用いると適切であるかを把握することが、更に容易となる。
【００４８】
以上、本発明の一実施例について説明したが、本発明は上記実施例に限定されるものではなく、種々の態様をとることができる。
例えば、上記実施例では、処理要求が却下されたかどうかを、イベント管理モジュールがエラー発生の有無を判断し（Ｓ１１０）、それに応じて過負荷実行時間β算出処理を起動させる（Ｓ１２０）ものとして説明したが、こうした構成に限られるものではない。例えば図８に示す様に、イベント管理モジュールを、単に起床要求の対象であるタスクのＩＤを第２のＩＤ記憶領域に格納し（Ｓ２００）、タスクの起床要求を発行する（Ｓ２１０）ように構成し、キューイングにエラーが発生した場合には、ＲＴＯＳが直接、過負荷実行時間β算出処理を起動させるようにしてもよい（Ｓ２２０）。
【００４９】
また、上記実施例では、外部指令の入力に応じて、処理負荷の測定を開始するものとして説明したが、これに限られない。例えば、ＥＣＵ２の内部にて定期的に測定開始命令を発生することによって処理負荷測定を行うように構成すれば、一時的に過負荷状態に陥った制御システムを回復させることが可能となる。例えば、制御として最低限必要なタスク群を所定のテーブルに記憶しておき、過負荷時に、そのテーブルに登録されている実務タスクだけを行うように切り替えることで、処理負荷を軽減し、制御システムを回復させることが可能である。
【００５０】
また、例えばエンジンストール後の急発進のように、一時的にＣＰＵの処理負荷が高まり、システムが過負荷状態に陥りそうな場合に、負荷の度合いに応じて低優先度のタスクを意図的に間引くようにしてもよい。そうすることで、制御システムが過負荷状態に陥ることを未然に回避することができる。
【図面の簡単な説明】
【図１】  一実施例としてのＥＣＵの電気的構成を示す説明図である。
【図２】  測定開始処理を示すフローチャートである。
【図３】  実務タスク実行時間α算出処理を示すフローチャート（ａ）と、その説明図（ｂ）である。
【図４】  起床要求発行処理を示すフローチャートである。
【図５】  過負荷実行時間β算出処理を示すフローチャートである。
【図６】  測定終了処理を示すフローチャートである。
【図７】  タスクが切り替わる様子を示す説明図である。
【図８】  変形例を示すフローチャートである。
【符号の説明】
２…エンジン制御装置（ＥＣＵ）
１０…ＣＰＵ  １４…ＲＯＭ  １８…ＲＡＭ
α…実務タスク実行時間  β…過負荷実行時間
γ…負荷率
【図１】
0004419338.tif 000002
【図２】
0004419338.tif 000003
【図３】
0004419338.tif 000004
【図４】
0004419338.tif 000005
【図５】
0004419338.tif 000006
【図６】
0004419338.tif 000007
【図７】
0004419338.tif 000008
【図８】
0004419338.tif 000009