(57)【要約】【課題】マイクロコンピュータの無駄な処理及び電力消費を抑制する。【解決手段】複数のアプリケーションタスク（以下、アプリタスク）が実行されると共に、全てのアプリタスクが実行されなくても良い状態になると、スリープモードに移行するマイコンでは、当該マイコンがスリープモードになっている場合に、複数種類のウェイクアップ要因のうちの何れかが発生してウェイクアップすると、状態管理タスクが起床し、その状態管理タスクにより、今回発生したウェイクアップ要因を判別すると共に（Ｓ３１０）、複数のアプリタスクのうち、その判別したウェイクアップ要因が発生した場合に起床されるべきアプリタスクのみを起床させる（Ｓ３２０）。このため、処理負荷が不必要に増加してしまうことが防止され、また、不要なアプリタスクが実行されることでスリープ可能と判定されるのが遅れてしまう、という不都合を防止できる。【選択図】図４
2008107914.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションタスクが実行されると共に、全てのアプリケーションタスクが実行されなくても良い状態になったか否かを判定する判定手段を備え、その判定手段により肯定判定されると、通常動作時よりも消費電力の少ないスリープモードに移行するマイクロコンピュータにおいて、
当該マイクロコンピュータがスリープモードになっている場合に、複数種類のウェイクアップ要因のうちの何れかが発生して、当該マイクロコンピュータがスリープモードからウェイクアップすると、その発生したウェイクアップ要因を判別すると共に、前記複数のアプリケーションタスクのうち、その判別したウェイクアップ要因が発生した場合に起床されるべきアプリケーションタスクのみを起床させるウェイクアップ時タスク起床制御手段を備えていること、
を特徴とするマイクロコンピュータ。
【請求項２】
請求項１に記載のマイクロコンピュータにおいて、
前記ウェイクアップ時タスク起床制御手段は、
前記起床されるべきアプリケーションタスクが複数あると共に、その複数のアプリケーションタスクのなかに、前記判定手段による判定に関係するアプリケーションタスク（以下、第１種タスクという）と、前記判定手段による判定に関係しないアプリケーションタスク（以下、第２種タスクという）とがあり、しかも、前記第２種タスクの方が前記第１種タスクよりも実行優先順位が高い場合には、当該マイクロコンピュータのウェイクアップ直後の１回のみ、前記第１種タスクと前記第２種タスクとの実行優先順位を変更して、前記第１種タスクの方が前記第２種タスクよりも優先して実行されるようにすること、
を特徴とするマイクロコンピュータ。
【請求項３】
コンピュータを請求項１又は２に記載のウェイクアップ時タスク起床制御手段として機能させるためのプログラム。
【請求項４】
請求項１又は請求項２に記載のマイクロコンピュータを備えた車両用電子制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マイクロコンピュータの消費電力を低減するための技術に関する。
【背景技術】
【０００２】
従来より、例えば車両用電子制御装置に搭載されるマイクロコンピュータにおいては、ＯＳ（オペレーティングシステム）によるマルチタスクの機能を利用して、制御対象を制御するための複数のアプリケーションタスクを実行するようにしている。
【０００３】
そして、この種のマイクロコンピュータにおいては、処理を行わなくても良くなった場合に、例えば、ＣＰＵのクロック周波数又は電源電圧を下げたり、ＣＰＵへのクロック供給又は電源供給を停止したりして、通常動作時よりも消費電力の少ないスリープモードに移行させることが行われている（例えば、特許文献１参照）。
【０００４】
次に、マイクロコンピュータをスリープモードに移行させるための手法の一具体例について、図７を用い説明する。尚、以下では、アプリケーションタスクを、略してアプリタスクともいう。また、本明細書においては、便宜上、「タスクが・・・する」といったプログラムを主体とした表現を適宜用いるが、その表現は、そのプログラムをコンピュータが実行することで実現される機能手段の動作内容（簡単に言えば、そのプログラムの機能の内容）を表している。
【０００５】
まず、図７の例では、アプリタスクとして、アプリタスク１とアプリタスク２とがあり、また、それら各アプリタスク１，２を起床させたり、スリープ／ウェイクアップの制御等を行う状態管理タスクがある。そして、この例において、状態管理タスクは一定時間毎に起床され、図７では、時刻ｔ１，ｔ３，ｔ６が、状態管理タスクの起床タイミングである。また、各タスクの優先順位は、「状態管理タスク＞アプリタスク１＞アプリタスク２」の順になっている。そして、アプリタスク１，２は、時刻ｔ１で起床した状態管理タスクによって起床要求されており、アプリタスク１は、状態管理タスクの実行が終了するとすぐに実行が開始されるが、アプリタスク２は、状態管理タスク及びアプリタスク１よりも優先順位が低いため、アプリタスク１の実行が終了した時刻ｔ２から実行が開始される。更に、アプリタスク２は、次回の状態管理タスクの実行中（時刻ｔ３〜ｔ４）は中断され、時刻ｔ３と時刻ｔ６との間の時刻ｔ５まで実行期間が伸びている。
【０００６】
ここで、アプリタスク１，２の各々は、自タスクが実行されなくても良い状態（以下、スリープ可能状態という）であるか否かを判定し、スリープ可能状態であると判定すると、各アプリタスク毎に設けられたスリープ可否フラグのうち、自タスクに対応するスリープ可否フラグをセットするための処理を行う。
【０００７】
そして、状態管理タスクは、起床すると、全アプリタスクのスリープ可否フラグをチェックし、それらが全てセットされていれば、アプリタスクの起床要求を行うことなく、マイクロコンピュータをスリープモードに移行させるための処理を行う。
【０００８】
このため、図７の例では、時刻ｔ２でアプリタスク１がスリープ可能状態になったと判定し、時刻ｔ５でアプリタスク２がスリープ可能状態になったと判定すると、その後の時刻ｔ６で状態管理タスクが起床した際に、その状態管理タスクがマイクロコンピュータをスリープモードに移行させることとなる。
【０００９】
一方、スリープモードにあるマイクロコンピュータをウェイクアップ（通常動作に復帰）させる要因（ウェイクアップ要因）は複数種類あるのが一般的である。
そして、従来のマイクロコンピュータでは、何れかのウェイクアップ要因が発生してウェイクアップすると、全てのアプリタスクが起床されるようになっていた。
【００１０】
例えば、図７の例では、時刻ｔ１で、何らかのウェイクアップ要因が発生したことにより、マイクロコンピュータがスリープモードからウェイクアップして状態管理タスクが起床され、その初回の状態管理タスクが、アプリタスク１，２の全てを起床させている。そして、発生したウェイクアップ要因が、たとえアプリタスク１にのみ関連するものであったとしても、アプリタスク１，２の全てが起床されることとなる。
【特許文献１】特開２００５−１８２２２３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、ウェイクアップ要因が発生した場合に、常に全てのアプリタスクを起床させるように構成したのでは、マイクロコンピュータの処理負荷が不必要に増加してしまう上に、次にスリープモードへ移行するまでの時間が増加してしまい、その分、マイクロコンピュータでの消費電力が増大してしまうという問題がある。
【００１２】
例えば、図７において、時刻ｔ１で発生したウェイクアップ要因がアプリタスク１にのみ関連するものであり、時刻ｔ２でアプリタスク１がスリープ可能状態になったと判定したとすると、本当ならば、その時刻ｔ２で、マイクロコンピュータは再びスリープモードへ移行しても良い状態となる。
【００１３】
このため、その次に状態管理タスクが起床されて該状態管理タスクの実行が終了する時刻ｔ４でマイクロコンピュータをスリープモードに移行させることができれば良いのであるが、アプリタスク２も起床されていると、スリープモードへの移行タイミングが前述の時刻ｔ６まで伸びてしまうこととなる。よって、図７に示しているような無駄な動作期間が発生してしまい、その分、無駄な処理と消費電力が発生することとなる。
【００１４】
本発明は、こうした問題に鑑みなされたものであり、マイクロコンピュータの無駄な処理及び電力消費を抑制することを目的としている。
【課題を解決するための手段】
【００１５】
上記目的を達成するためになされた請求項１のマイクロコンピュータでは、複数のアプリケーションタスクが実行される。また、このマイクロコンピュータは、全てのアプリケーションタスクが実行されなくても良い状態になったか否かを判定する判定手段を備え、その判定手段により肯定判定されると、通常動作時よりも消費電力の少ないスリープモードに移行するようになっている。
【００１６】
そして特に、このマイクロコンピュータには、ウェイクアップ時タスク起床制御手段が備えられている。
そのウェイクアップ時タスク起床制御手段は、当該マイクロコンピュータがスリープモードになっている場合に、複数種類のウェイクアップ要因のうちの何れかが発生して、当該マイクロコンピュータがスリープモードからウェイクアップすると、その発生したウェイクアップ要因を判別すると共に、前記複数のアプリケーションタスクのうち、その判別したウェイクアップ要因が発生した場合に起床されるべきアプリケーションタスクのみを起床させる。
【００１７】
このようなマイクロコンピュータによれば、複数種類のウェイクアップ要因のうちの何れかが発生して、スリープモードからウェイクアップした際には、その発生したウェイクアップ要因に関連するアプリケーションタスク（そのウェイクアップ要因が発生した場合に起床されるべきアプリケーションタスク）のみが起床されることとなる。
【００１８】
よって、ウェイクアップ要因には関係のない不要なアプリケーションタスクが起床されず、処理負荷が不必要に増加してしまうことが防止される。
更に、不要なアプリケーションタスクが起床されないため、その不要なアプリケーションタスクが実行されるために判定手段によって肯定判定（全てのアプリケーションタスクが実行されなくても良い状態になったと判定）されるのが遅れてしまう、といった不都合を回避することができる。よって、当該マイクロコンピュータを適切な時にスリープモードへ移行させることができ、従来技術で生じていた無駄な電力消費を無くすことができる。
【００１９】
次に、請求項２のマイクロコンピュータでは、請求項１のマイクロコンピュータにおいて、ウェイクアップ時タスク起床制御手段は、更に、以下のように構成されている。
即ち、ウェイクアップ時タスク起床制御手段は、起床されるべきアプリケーションタスクが複数あると共に、その複数のアプリケーションタスクのなかに、判定手段による判定に関係するアプリケーションタスク（以下、第１種タスクという）と、判定手段による判定に関係しないアプリケーションタスク（以下、第２種タスクという）とがあり、しかも、第２種タスクの方が第１種タスクよりも実行優先順位が高い場合には、当該マイクロコンピュータのウェイクアップ直後の１回のみ、その第１種タスクと第２種タスクとの実行優先順位を変更して、第１種タスクの方が第２種タスクよりも優先して実行されるようにする。
【００２０】
尚、判定手段による判定に関係しないアプリケーションタスク（第２種タスク）とは、そのアプリケーションタスクが実行中であっても、他のアプリケーションタスクがスリープ可能状態（実行されなくても良い状態）になっていれば、判定手段によって肯定判定され得るタスクである。
【００２１】
この構成によれば、当該マイクロコンピュータがウェイクアップした後、もし、第１種タスクの実行が終了したならば判定手段が肯定判定することとなる、といった状況であれば、第２種タスクよりも先に第１種タスクが実行される分、判定手段は早期に肯定判定することとなる。よって、マイクロコンピュータをより早期に再びスリープモードへと移行させることができるようになり、無駄な処理及び消費電力を一層抑制することができる可能性を上げることができる。
【００２２】
一方、コンピュータをウェイクアップ時タスク起床制御手段として機能させるためのプログラムによれば、ハードウェアを追加しなくても、請求項１，２のマイクロコンピュータを実現することができる。
【００２３】
また、請求項１，２のマイクロコンピュータは、様々な装置に適用可能であるが、特に、消費電力の低減が望まれる車両用電子制御装置に用いれば、その車両用電子制御装置での無駄な消費電力を一層抑制することができるようになる。
【発明を実施するための最良の形態】
【００２４】
以下に、本発明が適用された実施形態の車両用電子制御装置について説明する。尚、本実施形態の電子制御装置は、例えば車両のランプ類やドアロック等といったボデー系機器を制御するためのものである。また、以下では、電子制御装置のことをＥＣＵという。
【００２５】
図１に示すように、本実施形態のＥＣＵ１１は、マイコン（マイクロコンピュータ）１３と、センサ信号やスイッチ信号をマイコン１３に入力させる入力回路１４と、マイコン１３からの信号に基づき各種アクチュエータへ駆動信号を出力する出力回路１５と、車両に搭載された他のＥＣＵ１６，１７と通信線１８を介してマイコン１３が通信するための通信回路１９とを備えている。
【００２６】
そして、他のＥＣＵ１６，１７のうち、例えば、ＥＣＵ１６は、車両のドアに設けられたドアロックやパワーウィンドウ用のアクチュエータをＥＣＵ１１と連携して制御するドアＥＣＵであり、ＥＣＵ１７は、車両の使用者に携帯される電子キーと照合通信を行って、その照合結果をＥＣＵ１１に通知する照合ＥＣＵである。
【００２７】
また、マイコン１３には、周知のＣＰＵ２１、ＲＯＭ２３、ＲＡＭ２５、及びＩ／Ｏポート２７等が備えられている。ＲＯＭ２３には、ＣＰＵ２１によって実行されるプログラム（ソフトウェア）が予め記憶されている。また、ＲＡＭ２５には、プログラムの実行による演算結果（例えば、演算結果のデータやフラグ等）が一時的に記憶される。
【００２８】
そして、マイコン１３では、ＯＳによるマルチタスクの機能により、制御対象を制御するための複数のアプリタスク（アプリケーションタスク）が実行される。尚、アプリタスクとしては、例えば、他のＥＣＵ１６，１７と通信するための通信処理タスクや、ボデー系の機器を制御するためのボデーメインタスクや、時間を経時するためのタイマタスク等がある。
【００２９】
そして更に、マイコン１３のＲＯＭ２５に格納されたソフトウェアとしては、ＯＳとアプリタスクの他にも、状態管理タスクＭＴがある。
図２に示すように、状態管理タスクＭＴは、複数のアプリタスクＡＰ１〜ＡＰｘ（ｘは２以上）の各々について、そのタスクが実行されるべきタイミングが到来した時に、そのタスクの起床要求をＯＳに対して行う起床制御や、全てのアプリタスクＡＰ１〜ＡＰｘが実行されなくても良い状態になったことを検知して、マイコン１３をスリープモードに移行させる制御を行うためのタスクである。
【００３０】
そして、アプリタスクのなかには、定期的に実行されるべき定期アプリタスクがある。このため、状態管理タスクＭＴは、アプリタスクＡＰ１〜ＡＰｘよりも優先順位が高く設定されており、マイコン１３が通常動作している間は、少なくとも、全定期アプリタスクの実行間隔の最小公約数の時間毎（本実施形態では、例えば１ｍｓ毎）に起床される。
【００３１】
また、アプリタスクのなかには、不定期なイベントの発生時（例えば、特定のスイッチがオンされたときや、他のＥＣＵから特定の情報を受信した時等）に実行されるべきイベントアプリタスクもある。そして、マイコン１３が通常動作している期間において、そのようなイベントアプリタスクも、該当するイベントが発生した時に状態管理タスクＭＴによって起床要求される。
【００３２】
そして更に、状態管理タスクＭＴは、マイコン１３がスリープモードからウェイクアップすると即座に起床され、その時に実行が必要なアプリタスクの起床要求を行う。尚、ウェイクアップ要因（マイコン１３をウェイクアップさせる要因）としては、例えば、特定のスイッチがオンされたことや、他のＥＣＵからの信号を受信したこと等がある。
【００３３】
次に、各アプリタスクの処理内容（アプリタスクによって実現される機能）を、図３のフローチャートに沿って説明する。尚、ここでは、１つのアプリタスクＡＰｎ（ｎは１〜ｘの何れか）について説明するが、他のアプリタスクについても同様である。
【００３４】
アプリタスクＡＰｎの実行が開始されると、そのアプリタスクＡＰｎを成す各アプリモジュールの処理が行われる（Ｓ１１０）。アプリモジュールとは、アプリタスクの役割を更に細分化したプログラムモジュールであり、アプリタスクＡＰ１〜ＡＰｘの各々は、１個以上のアプリモジュールからなっている。
【００３５】
そして、全アプリモジュールの処理が終了すると（Ｓ１２０：ＹＥＳ）、その全アプリモジュールの各々について、実行されなくても良いスリープ可能状態になったか否かの状態判定を行う（Ｓ１３０）。
【００３６】
ここで、アプリモジュールにとって、スリープ可能状態とは、そのアプリモジュールによって実現される制御が完了しており、且つ、その制御を行う必要もない状態である。
例えば、車室内照明の制御を行うためのアプリモジュールであれば、そのアプリモジュールが一定時間毎に複数回実行されることにより、車室内照明に関する一連の制御が実現されることとなるため、その一連の制御が完了しており、且つ、新たな制御要求もなくて制御の実施が不要になった状態である。また、アプリモジュールによっては、一連の制御がなく、そのアプリモジュールの実行が終了すると、いつでもスリープ可能状態になるものもある。
【００３７】
そして、全アプリモジュールの各々についてスリープ可能状態になったか否かの判定が終わると、その判定結果に基づいて、当該アプリタスクＡＰｎがスリープ可能状態であるか否かを判定する（Ｓ１４０）。具体的には、全アプリモジュールがスリープ可能状態になっているか否かを判定し、全アプリモジュールがスリープ可能状態であれば、当該アプリタスクＡＰｎがスリープ可能状態であると判定する。
【００３８】
ここで、当該アプリタスクＡＰｎがスリープ可能状態ではないと判定したならば（Ｓ１４０：ＮＯ）、そのまま当該アプリタスクＡＰｎが終了する。
これに対して、当該アプリタスクＡＰｎがスリープ可能状態であると判定した場合には（Ｓ１４０：ＹＥＳ）、当該アプリタスクＡＰｎがスリープ可能状態であることを状態管理タスクＭＴに通知するための通知処理を行い（Ｓ１５０）、その後、当該アプリタスクＡＰｎが終了する。本実施形態では、通知処理として、「Ｆｌａｇ（ｎ）」というフラグ（以下、スリープ可能フラグという）をセットするための処理を行う。尚、スリープ可能フラグにおける（）内のｎは、当該アプリタスクの識別子である。また、「実行完了＝スリープ可能状態」というようなアプリタスクであれば、Ｓ１３０及びＳ１４０のような判定処理を省略し、そのアプリタスクの最後で、常にＳ１５０の処理を行うようにしても良い。
【００３９】
次に、状態管理タスクＭＴの処理内容（状態管理タスクＭＴによって実現される機能）を、図４のフローチャートに沿って説明する。
前述したように、状態管理タスクＭＴは、マイコン１３が通常動作している間、少なくとも一定時間毎に起床される。そして、状態管理タスクＭＴでは、マイコン１３がウェイクアップしてから２回目以降の実行時毎に、図４（Ａ）のスリープ制御処理が行われる。
【００４０】
即ち、まず、全アプリタスクＡＰ１〜ＡＰｘのスリープ可能フラグ（Ｆｌａｇ（１）〜Ｆｌａｇ（ｘ））が全てセットされているか否かを判定する（Ｓ２１０）。
そして、全アプリタスクＡＰ１〜ＡＰｘのスリープ可能フラグがセットされていれば（Ｓ２１０：ＹＥＳ）、全てのアプリタスクＡＰ１〜ＡＰｘが実行されなくても良い状態になっていてスリープ可能と判断し、アプリタスクの起床要求を行うことなく、当該マイコン１３を通常動作時よりも消費電力の少ないスリープモードに移行させるための処理を行う（Ｓ２２０）。例えば、ＣＰＵ２１へクロックを供給している発振回路の動作を停止させたり、当該マイコン１３へ電源を供給している電源回路の動作を停止させたりする。このため、Ｓ２２０の処理が行われると、当該マイコン１３が動作を停止することとなる。また、Ｓ２２０では、ＣＰＵ２１のクロック周波数又は電源電圧を下げるような処理を行うようにしても良い。
【００４１】
一方、上記Ｓ２１０で否定判定した場合（即ち、何れか１つでもスリープ可能フラグがセットされていない場合）には、そのまま当該状態管理タスクＭＴの処理が終了するか、或いは他の処理が行われた後、当該状態管理タスクＭＴの処理が終了する。
【００４２】
尚、アプリタスクによっては、そのアプリタスクの実行中にマイコン１３をスリープモードに移行させても問題が無いものであって、スリープモードへ移行しても良いか否かのスリープ判定に関係しないアプリタスクもある。そして、そのスリープ判定に関係しないアプリタスクに関しては、スリープ可能フラグが常時セット状態に固定されている。また、スリープ判定に関係しないアプリタスク以外のアプリタスク（スリープ判定に関係するアプリタスク）のスリープ可能フラグは、そのアプリタスクが起床要求された際にリセットされる。
【００４３】
一方また、前述したように、状態管理タスクＭＴは、マイコン１３がスリープモードからウェイクアップすると即座に起床される。
そして、そのウェイクアップ直後の状態管理タスクＭＴでは、図４（Ｂ）のウェイクアップ時処理が行われる。
【００４４】
即ち、まず、今回のウェイクアップ要因が何であるか判別する（Ｓ３１０）。
具体的に説明すると、マイコン１３がスリープモードになっている状態で、ウェイクアップ要因が発生すると、ハードウェア的に、その要因の発生を示す情報がマイコン１３の内部レジスタ（図示省略）に記憶されると共に、マイコン１３が通常動作に復帰（即ち、ウェイクアップ）する。
【００４５】
例えば、ウェイクアップ要因となる特定のスイッチがオンして、そのスイッチ信号のレベル変化が入力回路１４を介してマイコン１３に入力されると、マイコン１３がウェイクアップすると共に、そのスイッチ信号に該当する内部レジスタのビットに１がセットされる。また例えば、他のＥＣＵ１６，１７が通信線１８に通信開始を示す通信開始信号を送出し、その通信開始信号が通信回路１９によって検知されると、そのことを示す信号が通信回路１９からマイコン１３に入力されて、マイコン１３がウェイクアップすると共に、通信開始信号に該当する内部レジスタのビットに１がセットされる。このため、Ｓ３１０では、内部レジスタの各ビットのうち、１になっているビットを調べることにより、ウェイクアップ要因を判別して特定する。
【００４６】
そして、このようにしてウェイクアップ要因を特定すると、アプリタスクＡＰ１〜ＡＰｘのうち、今回特定したウェイクアップ要因に関連したアプリタスク（即ち、その特定したウェイクアップ要因が発生した場合に起床されるべきアプリタスク）のみについて、起床要求を行う（Ｓ３２０）。そして、その後、当該状態管理タスクＭＴの処理が終了する。尚、例えば、ＲＯＭ２３には、ウェイクアップ要因の各々と、そのウェイクアップ要因に関連するアプリタスクとを示すテーブル等のデータが記憶されており、Ｓ３２０では、そのデータに基づいて、今回発生したウェイクアップ要因に関連するアプリタスク（即ち、起床要求すべきアプリタスク）を特定する。また、発生したウェイクアップ要因に関連するアプリタスクが複数ある場合、その各アプリタスクの起床要求が行われる。
【００４７】
次に、上記各処理の作用について、図５を用い説明する。尚、ここでは、アプリタスクとして、アプリタスク１とアプリタスク２とがあるものとする。
図５において、マイコン１３は、時刻ｔ１以前ではスリープモードになっている。
【００４８】
そして、時刻ｔ１で、アプリタスク１，２のうち、アプリタスク１のみが関連するウェイクアップ要因が発生したとする。
すると、マイコン１３がウェイクアップして、状態管理タスクＭＴが起床し、図４（Ｂ）の処理により、アプリタスク１，２のうち、今回発生したウェイクアップ要因に関連するアプリタスク１のみが起床要求されることとなる（Ｓ３１０，Ｓ３２０）。
【００４９】
例えば、アプリタスク１，２の一方が前述の通信処理タスクで、他方が前述のボデーメインタスクであり、発生したウェイクアップ要因が他のＥＣＵ１６，１７からの通信開始信号であったならば、通信処理タスクとボデーメインタスクとのうち、通信処理タスクのみが起床要求されることとなる。また例えば、発生したウェイクアップ要因が、車室内照明の制御開始のトリガとなるドア開検知スイッチのオンであったならば、通信処理タスクとボデーメインタスクとのうち、車室内照明を制御する方のボデーメインタスクのみが起床要求されることとなる。
【００５０】
図５に戻り、その後、状態管理タスクＭＴの実行が終了すると、アプリタスク１が実行されるが、そのアプリタスク１の最後（時刻ｔ２）で、図３におけるＳ１５０の通知処理が行われたとする。
【００５１】
この場合、時刻ｔ１から一定時間後の時刻ｔ３にて、再び状態管理タスクＭＴが起床し、図４（Ａ）のスリープ制御処理が行われるが、そのスリープ制御処理では、Ｓ２１０で「ＹＥＳ」と判定されてＳ２２０の処理が行われることとなる。よって、その回の状態管理タスクＭＴの実行が終了する時刻ｔ４にて、マイコン１３は再びスリープモードに入ることとなる。
【００５２】
以上のように本実施形態のマイコン１３では、複数種類のウェイクアップ要因のうちの何れかが発生して、スリープモードからウェイクアップした際には、その発生したウェイクアップ要因に関連するアプリタスクのみが起床される。よって、処理負荷が不必要に増加してしまうことが防止される。
【００５３】
そして更に、不要なアプリタスクが実行されるために状態管理タスクＭＴのスリープ制御処理（図４（Ａ））でスリープ可能と判定されるのが遅れてしまう、といった不都合を回避することができる。よって、当該マイコン１３を適切な時にスリープモードへ移行させることができ、図７に例示したような無駄な動作期間及び電力消費を無くすことができる。
【００５４】
また、本実施形態では、図４（Ｂ）のウェイクアップ時処理をプログラムによって実現しているため、ハードウェアを追加しなくても上記効果を得ることができる。
そして、このようなマイコン１３を備えたＥＣＵ１１によれば、動作しなくても良い場合の消費電力を従来よりも抑制することができる。
【００５５】
尚、本実施形態では、状態管理タスクＭＴの処理のうち、図４（Ａ）のＳ２１０の処理が判定手段に相当しており、図４（Ｂ）の処理がウェイクアップ時タスク起床制御手段に相当している。
【００５６】
次に、第２実施形態について説明する。尚、ここでは、先に説明した実施形態（第１実施形態）と異なる部分を説明する。
前述したように、マイコン１３では、図４（Ｂ）のＳ３２０にて、ウェイクアップ要因に関連するアプリタスクが複数あった場合、その各アプリタスクの起床要求を行うこととなるが、第１実施形態では、その各アプリタスクが通常時と同じ設定の優先順位で実行されることとなる。
【００５７】
これに対して、第２実施形態のマイコン１３では、図４（Ｂ）のＳ３２０にて、ウェイクアップ要因に関連するアプリタスク（以下、起床要求対象タスクという）が複数あった場合、更に以下の処理を行う。
【００５８】
まず、複数の起床要求対象タスクのなかに、スリープ判定に関係するアプリケーションタスクと、スリープ判定に関係しないアプリタスクとがあり、しかも、スリープ判定に関係しないアプリタスクの方が、スリープ判定に関係するアプリタスクよりも実行優先順位が高いか否かを判定する。
【００５９】
そして、その判定で肯定判定した場合には、当該マイコン１３のウェイクアップ直後の１回のみ、そのスリープ判定に関係するアプリタスクと、スリープ判定に関係しないアプリタスクとの実行優先順位を変更して、スリープ判定に関係するアプリタスクの方が、スリープ判定に関係しないアプリタスクよりも優先して実行されるように設定変更し、その上で、各アプリタスクの起床要求を行う。
【００６０】
このような第２実施形態によれば、マイコン１３がウェイクアップした後、もし、スリープ判定に関係するアプリタスクの実行が終了したならば図４（Ａ）のＳ２１０でスリープ可能と判定されることとなる、といった状況であれば、優先順位を変更しない場合よりも、スリープ判定に関係するアプリタスクが先に実行される分、早期にスリープ可能と判定されることとなる。よって、マイコン１３をより早期に再びスリープモードへと移行させることができるようになり、無駄な処理及び消費電力を一層抑制することができる可能性を上げることができる。
【００６１】
図６に具体例を示す。
図６において、アプリタスクａは、アプリタスクｂよりも優先順位が高いものの、処理の内容はアプリタスクｂに依存しており、スリープ判定には関係がないタスク（スリープ可能フラグがセット状態に固定されたタスク）である。つまり、アプリタスクａは、アプリタスクｂがスリープ可能状態ならば、実行されなくても支障がないタスクであり、この例では、アプリタスクｂからの処理依頼を受けると、他のＥＣＵ１６，１７へ情報を送信する処理を行うタスクである。
【００６２】
また、アプリタスクｂは、時間を計測するためのタイマタスクであり、マイコン１３が外部タイマ回路（図示省略）からの定期起動信号によってウェイクアップした回数をカウントして、そのカウント値が規定値Ｎになっていなければ、そのまま自タスクのスリープ可能フラグをセットするが、カウント値が規定値Ｎになったら、スリープ可能フラグをセットせずに、アプリタスクａに処理依頼を行うタスクである。
【００６３】
例えば、マイコン１３は、外部タイマ回路からの定期起動信号によって、一定時間Ｔ１（例えば１０秒）毎にウェイクアップされるようになっている。そして、その外部タイマ回路によるウェイクアップ毎にアプリタスクｂが起床され、そのアプリタスクｂにより、外部タイマ回路によるウェイクアップ回数が上記カウント値として計数される。そして更に、アプリタスクｂでは、カウント値が規定値Ｎになると、「Ｔ１×Ｎ」の時間が経過したと判断して、アプリタスクａに処理依頼を行う。すると、アプリタスクａは、他のＥＣＵ１６，１７へ情報を送信する処理を行うようになっている。
【００６４】
ここで、図６の時刻ｔ１にて、マイコン１３が外部タイマ回路からの定期起動信号によりウェイクアップし、状態管理タスクＭＴが、図４（Ｂ）の処理により、その定期起動信号というウェイクアップ要因に関連するアプリタスクａ，ｂについて、起床要求を行ったとする。また、アプリタスクｂがこの回に上記カウント値をカウントアップさせても、そのカウント値は未だ規定値Ｎに達しないものとする。
【００６５】
この場合、図６（Ａ）に示すように、もし、アプリタスクａ，ｂの優先順位を変更しないとすると、アプリタスクｂよりもアプリタスクａの方が先に実行されることとなり、その分、マイコン１３がウェイクアップしてからアプリタスクｂにてスリープ可能フラグがセットされるまでの時間が長くなり、その結果、状態管理タスクＭＴでスリープ可能と判定されるまで（即ち、マイコン１３が再びスリープモードに入るまで）の時間が長くなる。尚、図６（Ａ）の例では、アプリタスクａの後に実行されたアプリタスクｂの実行中に、次回の状態管理タスクＭＴが時刻ｔ２で割り込み、更にその次の状態管理タスクＭＴが時刻ｔ３で実行された際に、スリープ可能と判定されてマイコン１３がスリープモードに移行している。
【００６６】
これに対して、本第２実施形態では、図６（Ｂ）に示すように、ウェイクアップ直後の１回のみ、アプリタスクａ，ｂの優先順位を逆にすることとなる。このため、アプリタスクａよりもアプリタスクｂの方が先に実行され、その結果、マイコン１３がウェイクアップしてからアプリタスクｂにてスリープ可能フラグがセットされるまでの時間が短くなる。よって、マイコン１３がウェイクアップしてから状態管理タスクＭＴでスリープ可能と判定されて再びスリープモードに入るまでの時間が短くなり、消費電力が低減される。尚、図６（Ｂ）の例では、マイコン１３がウェイクアップしてから２回目の状態管理タスクＭＴが実行される時刻ｔ２よりも前に、アプリタスクｂがスリープ可能フラグをセットしたため、時刻ｔ２で状態管理タスクＭＴが実行された際に、スリープ可能と判定されてマイコン１３がスリープモードに移行している。
【００６７】
このように、本第２実施形態によれば、スリープモードへの再移行を早めることができ、無駄な処理及び消費電力を一層抑制することが可能となる。
以上、本発明の一実施形態について説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々なる態様で実施し得ることは勿論である。
【００６８】
例えば、状態管理タスクＭＴの機能は、ＯＳに持たせるようにしても良い。
また、状態管理タスクＭＴの処理は、何れかのアプリタスク内で実行されるようにしてもよい。つまり、あるアプリタスクが状態管理タスクＭＴの代わりにタスク起床等の制御を行っても良い。
【００６９】
一方、本発明は、前述したようなボデー系の機能を制御するＥＣＵに限らず、例えばエンジンやトランスミッション等のパワートレイン系を制御するＥＣＵ等にも適用することができ、また、車両用以外のＥＣＵに対しても同様に適用することができる。
【図面の簡単な説明】
【００７０】
【図１】実施形態の車両用電子制御装置（ＥＣＵ）の構成を表す図である。
【図２】マイコンで実行されるソフトウェア構成を表す図である。
【図３】各アプリケーションタスクの処理内容を表すフローチャートである。
【図４】状態管理タスクの処理内容を表すフローチャートである。
【図５】図３及び図４の処理による作用を説明する説明図である。
【図６】第２実施形態の具体例を説明する説明図である。
【図７】従来技術及びその問題を説明する説明図である。
【符号の説明】
【００７１】
１１，１６，１７…ＥＣＵ、１３…マイコン、１４…入力回路、１５…出力回路、１８…通信線、１９…通信回路、２１…ＣＰＵ、２３…ＲＯＭ、２５…ＲＡＭ、２７…Ｉ／Ｏポート、ＡＰ１〜ＡＰｘ…アプリタスク、ＭＴ…状態管理タスク
【図１】
2008107914.tif 000003
【図２】
2008107914.tif 000004
【図３】
2008107914.tif 000005
【図４】
2008107914.tif 000006
【図５】
2008107914.tif 000007
【図６】
2008107914.tif 000008
【図７】
2008107914.tif 000009