JP2000293382A - リアルタイムオペレーティングシステムを用いたタスク起動制御装置 - Google Patents

Abstract

(57)【要約】 【課題】無駄な処理を無くし、タスク起動の最適化を図
ることができるリアルタイムオペレーティングシステム
を用いたタスク起動制御装置を提供する。 【解決手段】ＥＣＵ１のＣＰＵ１０は各イベントの発生
を検出して、所望の演算プログラムを実行する。演算プ
ログラムには、第１のイベントの発生で実行される第１
タスク群と、第２のイベントの発生で実行される第２タ
スク群とを備え、さらに、両タスク群には少なくとも１
つの同一タスクが含まれている。イベントの発生により
第１、第２タスク群を起動すべくタスクを待機状態にす
る前に、ステップ１０４でタスク状態を判断し、既に同
一タスクが待機状態にある時にはステップ１０５の処理
を迂回することにより待機状態への移行を禁止する。よ
って、同じタスクがつながっていたらそのタスクはリス
トにつなげない。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、リアルタイムオ
ペレーティングシステムを用いたタスク起動制御装置に
関するものである。

【０００２】

【従来の技術】従来、タスク起動をするものとして、特
開平１０−１０５４１６号公報に示すものがある。それ
は、イベントの発生（パラメータの取り込み時）から要
求時間内にデータを処理するリアルタイムオペレーティ
ングシステムを用いてタスクを起動する起動制御装置に
おいて、イベントによって起動するタスクを共通のヘッ
ダファイルにする。そうすることで、タスクの接続形態
の変更に対してタスクヘッダファイルの変更のみで済
み、変更が容易に実施できる。

【０００３】

【発明が解決しようとする課題】上記技術では、イベン
トが発生することによってタスクを起動するが（リスト
につなげるが）、同じタスクを起動するイベントが同時
に複数発生した場合には、そのタスクを同じタイミング
で何度も起動してしまう。

【０００４】具体的には、自動車用ＥＣＵ（エンジン制
御用ＥＣＵ）において、吸気圧ｐｍ、吸気温ｔｈａ、水
温ｔｈｗのいずれかが変化したら実行されるタスクの場
合、図７に示すように吸気圧ｐｍが変化した直後に吸気
温ｔｈａが変化したら、同じ処理（タスク１）が２回コ
ールされ、最終的に同じタスクが２度実行されてしま
う。

【０００５】これにより、処理負荷が増大する原因とな
りうる。この発明は、以上のような事情に鑑みなされた
ものであり、その目的は、無駄な処理を無くし、タスク
起動の最適化を図ることができるリアルタイムオペレー
ティングシステムを用いたタスク起動制御装置を提供す
ることにある。

【０００６】

【課題を解決するための手段】請求項１に記載の発明に
よれば、イベントの発生により第１、第２タスク群を起
動すべくタスクを待機状態にする前に、タスク状態が判
断され、既に同一タスクが待機状態にある時には待機状
態への移行が禁止される。

【０００７】このように、同じタスクがつながっていた
らそのタスクはリストにつなげないことで、無駄な処理
を無くし、タスク起動の最適化を図ることができる。

【０００８】

【発明の実施の形態】以下、この発明を具体化した実施
の形態を図面に従って説明する。本実施形態において
は、エンジン制御用ＥＣＵ（ＥＣＵ；Ｅlectric Ｃontr
olＵnit ）に適用している。

【０００９】図１には、ＥＣＵ１の全体構成を示す。Ｅ
ＣＵ１は自動車のエンジンを制御するためのものであ
る。ＥＣＵ１は多重伝送路２に接続され、多重伝送路２
を介して他の電子機器と接続されＬＡＮを構築したり、
修理用ツール（図示略）と接続できるようになってい
る。

【００１０】ＥＣＵ１はＭＰＵ（マイクロコンピュー
タ）３と外部ＲＡＭ（ランダムアクセスメモリ）４と入
出力（Ｉ／Ｏ）ユニット５と通信ユニット６とインター
フェース回路７にて構成されている。ＭＰＵ３は、ＲＯ
Ｍ（リードオンリメモリ）８と内部ＲＡＭ９とＣＰＵ
（中央処理装置）１０を備えている。

【００１１】ＥＣＵ１には吸気管圧力センサ１１とエン
ジン回転数センサ１２と水温センサ１３と吸気温センサ
１４が接続されている。吸気管圧力センサ１１からエン
ジンの吸気管圧力ｐｍに応じた信号が出力され、エンジ
ン回転数センサ１２からエンジン回転数Ｎｅに応じた信
号が出力される。また、水温センサ１３からエンジン冷
却水温ｔｈｗに応じた信号が出力され、吸気温センサ１
４から吸気温度ｔｈａに応じた信号が出力される。各セ
ンサ１１〜１４の信号は入出力（Ｉ／Ｏ）ユニット５を
介してＭＰＵ３に取り込まれる。

【００１２】また、ＥＣＵ１には燃料噴射弁１５が接続
され、ＭＰＵ３は入出力（Ｉ／Ｏ）ユニット５を介して
燃料噴射弁１５を駆動制御する。通信ユニット６とイン
ターフェース回路７を用いて、ＭＰＵ３からデータを多
重伝送路２に送出したり、多重伝送路２からデータを受
信する。

【００１３】ＣＰＵ１０はセンサ１１〜１４からの信号
および通信によるデータに基づいてエンジンの運転状態
に応じた最適燃料噴射量（噴射時間）を演算して燃料噴
射弁１５を駆動制御する。また、ＣＰＵ１０は自己診断
を行い、各種センサやアクチュエータの異常発生の有無
を判断する。

【００１４】ＭＰＵ３はイグニッションスイッチ１６を
介してバッテリ１７に接続されている。外部ＲＡＭ４は
直接、バッテリ１７に接続されており、スイッチオフ後
も記憶内容が保持される。この外部ＲＡＭ４には前述の
自己診断結果が記憶される。

【００１５】ＭＰＵ３にはリアルタイムオペレーティン
グシステムが搭載されており、各イベントの発生を検出
して所望の演算プログラムを実行する。つまり、ＭＰＵ
３により、第１のイベントの発生（第１の環境変化）を
検出する第１の検出手段と、第１のイベントの発生（第
１の環境変化）とは異なる第２のイベントの発生（第２
の環境変化）を検出する第２の検出手段と、第１、第２
の検出手段からの情報に基づき所望の演算プログラムを
実行する演算装置とが構成されている。また、この演算
プログラムには、第１のイベントの発生（第１の環境変
化）で実行される第１タスク群と、第２のイベントの発
生（第２の環境変化）で実行される第２タスク群とを備
え、さらに、両タスク群には少なくとも１つの同一タス
クが含まれている。

【００１６】このリアルタイムオペレーティングシステ
ムについて図２を用いて詳しく説明する。図２は、リア
ルタイムオペレーティングシステムにて、あるパラメー
タ（吸気管圧力ｐｍ、吸気温ｔｈａ、水温ｔｈｗの変
化）によって起動されるタスクを示すものである。吸気
管圧力ｐｍが変化した際のタスク群が、タスク５とタス
ク６とタスク１により構成され、吸気温ｔｈａが変化し
た際のタスク群が、タスク１とタスク２とタスク３によ
り構成され、水温ｔｈｗが変化した際のタスク群が、タ
スク１とタスク４により構成されている。このイベント
毎の各タスク群はリアルタイムオペレーティングシステ
ムのイベントハンドラによって選択される（スイッチが
切り換えられる）。

【００１７】つまり、イベントの発生（吸気管圧力ｐ
ｍ、吸気温ｔｈａ、水温ｔｈｗの変化）に伴い、そのイ
ベントの種類に対応するようにスケジューリングが行わ
れる。具体的には、吸気管圧力ｐｍが変化した場合には
タスク５とタスク６とタスク１が連結され、また、吸気
温ｔｈａが変化した場合にはタスク１とタスク２とタス
ク３が連結され、さらに、水温ｔｈｗが変化した場合に
はタスク１とタスク４が連結される。

【００１８】このように、タスク１〜タスク６は、吸気
管圧力ｐｍ、吸気温ｔｈａ、水温ｔｈｗのいずれかが変
化した時にのみ実行されるタスクであり、かつ、各タス
ク群には少なくとも１つの同一タスク（図２の場合は、
タスク１）が含まれている。

【００１９】そして、このタスク群がイベントの発生に
伴って起動され、待機状態のタスク（タスク群を構成す
る各タスク）が順に実行される。例えば、吸気管圧力ｐ
ｍが変化したら、タスク５，６，１が順に実行される。

【００２０】次に、このように構成したＥＣＵ１、つま
り、リアルタイムオペレーティングシステムを用いたタ
スク起動制御装置の作用を説明する。この作用説明で
は、入力パラメータとして、吸気管圧力ｐｍと吸気温ｔ
ｈａと水温ｔｈｗを使用し、それらをＣＰＵ１０に取り
込んで処理する場合について説明する。

【００２１】図３には、スケジューリングのフローチャ
ートを示す。この処理は４ｍｓ毎に起動する。図４に
は、起動されるタスクデータとスケジューリングの例を
示す。図４において、吸気管圧力ｐｍが変化した直後に
吸気温ｔｈａが変化し、さらにその直後に水温ｔｈｗが
変化した場合を示す。つまり、タスクが実行される前に
ｐｍ、ｔｈａ、ｔｈｗが連続して変化したときの例であ
る。

【００２２】図３において、ＣＰＵ１０はステップ１０
０でパラメータの取り込みを行う。つまり、吸気管圧力
ｐｍと吸気温ｔｈａと水温ｔｈｗを４ｍｓ毎に取り込
む。そして、ＣＰＵ１０はステップ１０１で吸気管圧力
ｐｍと吸気温ｔｈａと水温ｔｈｗに関し、前回の取り込
み値に対し変化があったか否か判定する。変化がなけれ
ば、ＣＰＵ１０は図３のフローチャートの処理を終了す
る。

【００２３】一方、ＣＰＵ１０はステップ１０１で前回
の取り込み値に対し変化があると、環境が変化してイベ
ントが発生したとして、リアルタイムオペレーティング
システムのイベントハンドラによる割り込みを行い、以
後の処理を実行する（ＯＳのスケジューリングにタスク
を追加する）。

【００２４】まず、ステップ１０２に移行して、ＣＰＵ
１０は起動するタスクリストの先頭にいく（タスクリス
トの先頭をポインタで指す）。そして、ＣＰＵ１０はス
テップ１０３で先頭タスクから順に１個ずつタスクの状
態を読み出し、ステップ１０４でタスク状態が待機状態
か否か（登録済みか否か）を判断する。例えば、吸気管
圧力ｐｍが変化したと判断されると、図２のごとく、タ
スク５、タスク６、タスク１が実行されるべきプログラ
ムであるので、その先頭タスクであるタスク５の状態が
まず判断される。

【００２５】タスクの状態は、以下のようにして判断さ
れる。各タスクは図５に示すようなプログラム文でコー
ディングされ、タスクが構成されている。そして、各タ
スクの先頭アドレスにはタスク関数名（Ｔｓｋ）やタス
クの優先度（ｐｒｉ）と共に、タスクの状態を示すフラ
グ情報（ｆｌａｇ）が配設されている。正確には、図５
のプログラム文には該当アドレスのみ記述され、図６に
示すようにフラグ状態はアドレスの示す任意のＲＡＭエ
リアに格納されている。図６の例では＄００が実行中
を、＄０１が待機中を、＄１１が休止中を示している。
ＣＰＵ１０はこのフラグ情報をみて、図６の例では＄０
１となっていないか否か判断する。

【００２６】そして、図３のステップ１０４において図
６のデータを読み出した結果、このデータが待機中を示
す＄０１でなければ、ステップ１０５で当該タスクを待
機中を示す＄０１にする（＄１１から＄０１に変更す
る）。

【００２７】ここで、図４において、吸気管圧力ｐｍが
変化した時［１］の処理として、図３のステップ１０４
において先頭のタスク５（図２参照）が待機中でないの
で、ステップ１０５で待機中にする（登録する）。

【００２８】一方、図３のステップ１０４で当該タスク
が待機状態であれば、ステップ１０５の処理は行わな
い。そして、ステップ１０５あるいは１０４の処理を行
った後に、ＣＰＵ１０はステップ１０６に移行して読み
出すタスクがないか判定し、読み出すタスクが有る場合
にはステップ１０３に戻る。よって、読み出すタスクが
有る場合にはステップ１０３〜１０５の処理が繰り返さ
れる。

【００２９】図４の場合には、前述したように吸気管圧
力ｐｍが変化した場合にタスク５を待機中にした後にお
いて、タスク６が読み出され（ステップ１０３）、待機
中でないので待機中にされ（ステップ１０５）、さら
に、タスク１が読み出され（ステップ１０３）、待機中
でないので待機中にされる（ステップ１０５）。

【００３０】そして、図３のステップ１０６において、
読み出すタスクがなくなると、図３のフローチャートの
処理を終了する。図４の場合に、次に吸気温ｔｈａが変
化した際［２］には、図３のステップ１０３で先頭のタ
スク１（図２参照）が読み出され、ステップ１０４で図
６のデータを読み出した結果、このデータが待機中を示
す＄０１であるので、ステップ１０５の処理は行わな
い。よって、吸気管圧力ｐｍの変化に伴うタスク群の末
尾のタスク１の後に、吸気温ｔｈａの変化に伴うタスク
群の先頭のタスク１をつなげないことになる。

【００３１】その後、図２のタスク２が読み出され（ス
テップ１０３）、待機中でないので待機中にされ（ステ
ップ１０５）、さらに、タスク３が読み出され（ステッ
プ１０３）、待機中でないので待機中にされる（ステッ
プ１０５）。

【００３２】そして、図３のステップ１０６において、
読み出すタスクがなくなると、図３のフローチャートの
処理を終了する。図４の場合に、次に水温ｔｈｗが変化
した際［３］には、図３のステップ１０３で先頭のタス
ク１（図２参照）が読み出され、ステップ１０４で図６
のデータを読み出した結果、このデータが待機中を示す
＄０１であるので、ステップ１０５の処理は行わない。
よって、吸気温ｔｈａの変化に伴うタスク群の末尾のタ
スク３の後に、水温ｔｈｗの変化に伴うタスク群の先頭
のタスク１をつなげないことになる。

【００３３】その後、図２のタスク４が読み出され（ス
テップ１０３）、待機中でないので待機中にされる（ス
テップ１０５）。そして、図３のステップ１０６におい
て、読み出すタスクがなくなると、図３のフローチャー
トの処理を終了する。

【００３４】以上のように、吸気管圧力ｐｍを前回値と
比較してもし違いがあれば、ＯＳのスケジューリングに
タスクを追加するが、このときに既に登録されているタ
スクがないので全部待機中にし（登録し）、次に、吸気
温ｔｈａが変化してＯＳのスケジューリングに追加する
ときに、タスク１が既に登録されているのでそれだけ省
いて登録する。同様に、水温ｔｈｗが変化した時もタス
ク１が登録されているのでそれだけ省く。これにより、
同じタスクが実行されないので、処理の負担が減る。

【００３５】つまり、既にタスク状態が待機中（＄０
１）であるなら、図３のステップ１０４で登録済みと判
断され、ステップ１０５の処理は実行されない。よっ
て、同じタスク（図４ではタスク１）が２回実行される
ことはない。

【００３６】このように本実施の形態は、下記の特徴を
有する。 （イ）少なくとも２つのタスク群における両タスク群に
少なくとも１つの同一タスクが含まれる場合において、
図３に示すごとくステップ１０５にてイベントの発生に
より第１、第２タスク群を起動すべくタスクを待機状態
にする前に、ステップ１０４でタスク状態を判断し、既
に同一タスクが待機状態にある時にはステップ１０５の
処理を迂回することにより待機状態への移行を禁止する
ようにした。

【００３７】よって、同じタスクがつながっていたらそ
のタスクはリストにつなげないことで、無駄な処理を無
くし、タスク起動の最適化を図ることができる。つま
り、同じタスクがつながっていたらそのタスクはリスト
につなげないことで、前回の結果と同じ結果になる無駄
なタスクを起動しない構造を構築できる（無駄な処理を
省くことができる）。

【図面の簡単な説明】

【図１】 エンジン制御ＥＣＵの構成図。

【図２】 タスクリストの説明図。

【図３】 ＣＰＵの処理内容を示すフローチャート。

【図４】 スケジューリングの説明のための図。

【図５】 ＯＳのプログラムソース例を示す図。

【図６】 フラグ状態を示すデータの格納用メモリを示
す図。

【図７】 従来技術を説明するための図。

【符号の説明】

１…ＥＣＵ、３…ＭＰＵ、１０…ＣＰＵ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 第１のイベントの発生を検出する第１の
   イベント検出手段と、 前記第１のイベントとは異なる第２のイベントの発生を
   検出する第２のイベント検出手段と、 前記第１、第２のイベントの発生に基づき所望の演算プ
   ログラムを実行する演算装置とを備え、 前記演算プログラムには、前記第１のイベントの発生で
   実行される第１タスク群と、前記第２のイベントの発生
   で実行される第２タスク群とを備え、さらに、両タスク
   群には少なくとも１つの同一タスクが含まれるものであ
   って、 イベントの発生により前記第１、第２タスク群を起動す
   べくタスクを待機状態にする前に、タスク状態を判断
   し、既に同一タスクが待機状態にある時には待機状態へ
   の移行を禁止することを特徴とするリアルタイムオペレ
   ーティングシステムを用いたタスク起動制御装置。