JP2008102830A - マイクロコンピュータ、プログラム及び車両用電子制御装置 - Google Patents

Abstract

【課題】マイコンがスリープモードに入れる状態になった時に、そのマイコンを即座にスリープモードへと移行させることができるようにして、無駄な電力消費を無くす。
【解決手段】複数のアプリケーションタスク（以下、アプリタスク）が実行されるマイコンにおいて、アプリタスクの各々では、自タスクが実行されなくても良いスリープ可能状態であると判定すると関数コールによる通知を行う。そして、アプリタスクの何れかにより上記関数がコールされると、状態管理部のプログラムが起動し、その関数をコールしたアプリタスクがスリープ可能状態であるというフラグ（Ｆｌａｇ（ｎ）：ｎはアプリタスクの識別子）をセットすると共に（Ｓ２１０）、全アプリタスクのフラグをチェックして、全アプリタスクがスリープ可能状態か否かを判定し（Ｓ２２０）、肯定判定したならば当該マイコンをスリープモードに移行させる（Ｓ２３０）。
【選択図】図４

Description

本発明は、マイクロコンピュータをスリープモードに移行させるための技術に関するものである。

従来より、例えば車両用電子制御装置に搭載されるマイクロコンピュータにおいては、ＯＳ（オペレーティングシステム）によるマルチタスクの機能を利用して、制御対象を制御するための複数のアプリケーションタスクを実行するようにしている。

そして、この種のマイクロコンピュータにおいては、処理を行わなくても良くなった場合に、例えば、ＣＰＵのクロック周波数又は電源電圧を下げたり、ＣＰＵへのクロック供給又は電源供給を停止したりして、通常動作時よりも消費電力の少ないスリープモードに移行させることが行われている（例えば、特許文献１参照）。

次に、マイクロコンピュータをスリープモードに移行させるための手法の具体例について、図７を用い説明する。尚、以下では、アプリケーションタスクを、略してアプリタスクともいう。また、本明細書においては、便宜上、「タスクが・・・する」といったプログラムを主体とした表現を適宜用いるが、その表現は、そのプログラムをコンピュータが実行することで実現される機能手段の動作内容（簡単に言えば、そのプログラムの機能の内容）を表している。

まず、図７の例では、アプリタスクとして、アプリタスク１とアプリタスク２とがあり、また、それら各アプリタスク１，２を一定時間毎に起床させるシステムタスクがある。そして例えば、システムタスクは、１ｍｓ毎に起床すると共に、アプリタスク１の起床要求を行い、また、２回起床する毎に１回の割合でアプリタスク２の起床要求を行う。よって、アプリタスク１は１ｍｓ毎に起床し、アプリタスク２は２ｍｓ毎に起床することとなる。更に、各タスクの優先順位は、「システムタスク＞アプリタスク１＞アプリタスク２」の順になっている。

ここで、アプリタスク１，２の各々は、自タスクが実行されなくても良い状態（以下、スリープ可能状態という）であるか否かを判定し、スリープ可能状態であると判定すると、各アプリタスク毎に設けられたスリープ可否フラグのうち、自タスクに対応するスリープ可否フラグをセットするための処理を行う。

そして、システムタスクは、起床すると、全アプリタスクのスリープ可否フラグをチェックし、それらが全てセットされていれば、アプリタスクの起床要求を行うことなく、マイクロコンピュータをスリープモードに移行させるための処理を行う。

このため、図７の例では、時刻ｔ３でアプリタスク１がスリープ可能状態になったと判定し、時刻ｔ４でアプリタスク２がスリープ可能状態になったと判定すると、その後の時刻ｔ５でシステムタスクが起床した場合に、そのシステムタスクがマイクロコンピュータをスリープモードに移行させることとなる。尚、図７の例において、時刻ｔ１，ｔ２，ｔ５は、システムタスクが起床する１ｍｓ毎のタイミングである。そして、アプリタスク２は、時刻ｔ１で起床したシステムタスクによって、アプリタスク１と共に起床要求されているが、システムタスク及びアプリタスク１よりも優先順位が低いため、時刻ｔ２と時刻ｔ５との間の時刻ｔ４まで実行期間が伸びてしまっている。

一方、マイクロコンピュータをスリープモードに移行させるための他の手法として、アイドルタスクを用いることも考えられる。
即ち、アイドルタスクは、優先度が最も低く、他のタスクが実行されない期間に実行されるタスクである。そして、システムタスクではなく、そのアイドルタスクが、全アプリタスクのスリープ可否フラグをチェックし、それらが全てセットされていれば、マイクロコンピュータをスリープモードに移行させるための処理を行うようにすることが考えられる。また、アイドルタスクの実行される状態が、マイクロコンピュータをスリープモードにしても良い状態と等しいのであれば、アイドルタスクが無条件にマイクロコンピュータをスリープモードに移行させるように構成することも考えられる（例えば、特許文献１参照）。
特開２００５−１８２２２３号公報

システムタスクによってスリープモードへの移行を制御する手法の場合、全てのアプリタスクがスリープ可能状態になったとしても、その後にシステムタスクが起床するまでは、マイクロコンピュータをスリープモードにすることができない。このため、図７に示しているような無駄な動作期間が発生してしまい、その分、無駄な電力を消費することとなる。

また、アイドルタスクによってスリープモードへの移行を制御する手法の場合にも、以下の理由により、同様の問題が生じる。
例えば、図７において、時刻ｔ１の前に、アプリタスク１，２のうち、アプリタスク２は既にスリープ可能状態になっていたとする。そして、この場合、時刻ｔ１でシステムタスクが起床すると、そのシステムタスクは、通常通りアプリタスク１，２の起床要求を行うこととなる。

ここで、もし、その回に起床したアプリタスク１がスリープ可能状態になったとしても、アプリタスク２は既に起床要求されているため、そのアプリタスク１の実行が終了すると、引き続きアプリタスク２が実行される。そして、そのアプリタスク２の実行が終了すると、アイドルタスクによってマイクロコンピュータがスリープモードに移行することとなる。しかし、この場合、アプリタスク１の実行が終了した時点から、アプリタスク２の実行が終了するまでの間は、やはり無駄な動作期間となり、その分、無駄な電力を消費することとなる。

また更に、アイドルタスクによってスリープモードへの移行を制御する場合、そのアイドルタスクに他の機能を組み込み難いという欠点もある。
本発明は、こうした問題に鑑みなされたものであり、マイクロコンピュータがスリープモードに入れる状態になった時に、そのマイクロコンピュータを即座にスリープモードへと移行させることができるようにして、無駄な電力消費を無くすことを目的としている。

上記目的を達成するためになされた請求項１のマイクロコンピュータでは、アプリケーションアスクが実行され、特に、スリープ移行管理手段が備えられている。
スリープ移行管理手段は、アプリケーションタスクから、そのアプリケーションタスクがスリープ可能状態（実行されなくても良い状態）であることが通知されると起動する。そして、その通知に該当するアプリケーションタスクがスリープ可能状態であるという履歴を記憶すると共に、全アプリケーションタスクについての前記履歴をチェックすることにより、全アプリケーションタスクがスリープ可能状態であるか否かを判定し、その判定で肯定判定したならば、当該マイクロコンピュータを通常動作時よりも消費電力の少ないスリープモードに移行させる。

また、アプリケーションタスクでは、そのアプリケーションタスク（自タスク）がスリープ可能状態になると上記通知を行うための通知処理が行われるようになっている。
このようなマイクロコンピュータによれば、全てのアプリケーションタスクがスリープ可能状態になった時であって、当該マイクロコンピュータがスリープモードに入れる状態になった時には、即座にスリープモードへと移行させることができる。よって、従来技術で生じていた無駄な電力消費を無くすことができる。

尚、通知処理は、請求項２に記載のように、アプリケーションタスクの末尾で行われるようにすることが好ましい。上記通知を行ったアプリケーションタスクが終了した時点で、スリープ移行管理手段により、全アプリケーションタスクがスリープ可能状態であるか否かの判定が行われることとなり、延いては、アプリケーションタスクの実行中に、スリープモードになってしまうことを確実に回避することができるからである。

一方、コンピュータをスリープ移行管理手段として機能させるためのプログラムによれば、ハードウェアを追加しなくても、請求項１，２のマイクロコンピュータを実現することができる。

また、請求項１，２のマイクロコンピュータは、様々な装置に適用可能であるが、特に、消費電力の低減が望まれる車両用電子制御装置に用いれば、その車両用電子制御装置が動作しなくても良い場合の消費電力を一層抑制することができるようになる。

以下に、本発明が適用された実施形態の車両用電子制御装置について説明する。尚、本実施形態の電子制御装置は、例えば車両のパワーウィンドウやドアロックといったボデー系の機能を制御するものである。また、以下では、電子制御装置のことをＥＣＵという。

図１に示すように、本実施形態のＥＣＵ１１は、マイコン（マイクロコンピュータ）１３と、センサ信号やスイッチ信号をマイコン１３に入力させる入力回路１５と、マイコン１３からの信号に基づきパワーウィンドウモータやドアロックモータ等の各種アクチュエータへ駆動信号を出力する出力回路１７と、車両に搭載された他のＥＣＵと通信線１８を介してマイコン１３が通信するための通信回路１９とを備えている。

また、マイコン１３には、周知のＣＰＵ２１、ＲＯＭ２３、ＲＡＭ２５、及びＩ／Ｏポート２７等が備えられている。ＲＯＭ２３には、ＣＰＵ２１によって実行されるプログラム（ソフトウェア）が予め記憶されている。また、ＲＡＭ２５には、プログラムの実行による演算結果（例えば、演算結果のデータやフラグ等）が一時的に記憶される。

そして、マイコン１３では、ＯＳによるマルチタスクの機能により、制御対象を制御するための複数のアプリタスク（アプリケーションタスク）が実行されるが、ＲＯＭ２５に格納されたソフトウェアとしては、ＯＳとアプリタスクの他にも、システムタスクＳＴと状態管理部ＳＭがある。

図２に示すように、システムタスクＳＴは、複数のアプリタスクＡＰ１〜ＡＰｘ（ｘは２以上の整数）のうち、定期的に実行されるべきアプリタスク（以下、定期アプリタスクという）の各々について、その定期アプリタスクの実行間隔毎に、その定期アプリタスクの起床要求をＯＳに対して行うタスクである。このため、システムタスクＳＴは、全定期アプリタスクの実行間隔の最小公約数の時間毎（本実施形態では、例えば１ｍｓ毎）に起床される。

また、状態管理部ＳＭは、全てのアプリタスクＡＰ１〜ＡＰｘが実行されなくても良い状態になったことを検知して、マイコン１３をスリープモードに移行させるプログラム部分である。

尚、アプリタスクのなかには、不定期なイベントの発生時（例えば、特定のスイッチがオンされたときや、他のＥＣＵから特定の信号を受信した時等）に即座に起床されるものもある。

また、図２に示すように、アプリタスクＡＰ１〜ＡＰｘの各々は、１個以上のモジュール（以下、アプリモジュールという）からなっている。例えば、アプリタスクＡＰ１は、ｙ個（ｙは１以上の整数）のアプリモジュールＡＰ１−１〜ＡＰ１−ｙからなり、アプリタスクＡＰｘは、ｚ個（ｚは１以上の整数）のアプリモジュールＡＰｘ−１〜ＡＰｘ−ｚからなっている。そして例えば、アプリモジュールとしては、ドアロック制御、トランク制御、車室内照明制御、ライト制御、パワーウィンドウ制御といった、各種制御をそれぞれ行うためのものがある。

次に、各アプリタスクの処理内容（アプリタスクによって実現される機能）を、図３のフローチャートに沿って説明する。尚、ここでは、１つのアプリタスクＡＰｎ（ｎは１〜ｘの何れか）について説明するが、他のアプリタスクについても同様である。

アプリタスクＡＰｎの実行が開始されると、そのアプリタスクＡＰｎを成す各アプリモジュールの処理が行われる（Ｓ１１０）。
そして、全アプリモジュールの処理が終了すると（Ｓ１２０：ＹＥＳ）、その全アプリモジュールの各々について、実行されなくても良いスリープ可能状態になったか否かの状態判定を行う（Ｓ１３０）。

ここで、アプリモジュールにとって、スリープ可能状態とは、そのアプリモジュールによって実現される制御が完了しており、且つ、その制御を行う必要もない状態である。
例えば、パワーウィンドウ制御を行うためのアプリモジュールであれば、そのアプリモジュールが一定時間毎に複数回実行されることにより、パワーウィンドウに関する一連の制御が実現されることとなるため、その一連の制御が完了しており、且つ、新たな制御要求もなくて制御の実施が不要になった状態である。また、アプリモジュールによっては、一連の制御がなく、そのアプリモジュールの実行が終了すると、いつでもスリープ可能状態になるものもある。

そして、全アプリモジュールの各々についてスリープ可能状態になったか否かの判定が終わると、その判定結果に基づいて、当該アプリタスクＡＰｎがスリープ可能状態であるか否かを判定する（Ｓ１４０）。具体的には、全アプリモジュールがスリープ可能状態になっているか否かを判定し、全アプリモジュールがスリープ可能状態であれば、当該アプリタスクＡＰｎがスリープ可能状態であると判定する。

ここで、当該アプリタスクＡＰｎがスリープ可能状態ではないと判定したならば（Ｓ１４０：ＮＯ）、そのまま当該アプリタスクＡＰｎが終了する。
これに対して、当該アプリタスクＡＰｎがスリープ可能状態であると判定した場合には（Ｓ１４０：ＹＥＳ）、当該アプリタスクＡＰｎがスリープ可能状態であることを状態管理部ＳＭに通知するための通知処理を行う（Ｓ１５０）。本実施形態では、通知処理として「ＳｌｅｅｐＯＫ（ｎ）」という関数（以下、スリープ可能関数という）をコールする。尚、スリープ可能関数における（）内のｎは、その関数をコールしたアプリタスクの識別子であり、その関数の引数（パラメータ）である。そして、その後、当該アプリタスクＡＰｎが終了する。

尚、「実行完了＝スリープ可能状態」というようなアプリタスクであれば、Ｓ１３０及びＳ１４０のような判定処理を省略し、そのアプリタスクの最後で、常に上記スリープ可能関数をコールするようにしても良い。

次に、状態管理部ＳＭの処理内容（状態管理部ＳＭによって実現される機能）を、図４のフローチャートに沿って説明する。
まず、マイコン１３では、アプリタスクＡＰ１〜ＡＰｘの何れかによって、上記スリープ可能関数（「ＳｌｅｅｐＯＫ（ｎ）」：ｎは１〜ｘの何れか）がコールされると、状態管理部ＳＭに該当するプログラムが即座に実行される。

そして、状態管理部ＳＭに該当するプログラムの実行が開始されると、まず、「Ｆｌａｇ（ｎ）」というフラグ（以下、スリープ可能フラグという）をセットする（Ｓ１２０）。尚、そのスリープ可能フラグにおける（）内のｎは、今回コールされたスリープ可能関数における引数であり、そのスリープ可能関数をコールしたアプリタスクの識別子である。つまり、Ｓ２１０では、スリープ可能状態であることを通知してきたアプリタスクがスリープ可能状態であるという履歴を、スリープ可能フラグというかたちで記憶する。

次に、全アプリタスクＡＰ１〜ＡＰｘのスリープ可能フラグ（Ｆｌａｇ（１）〜Ｆｌａｇ（ｘ））が全てセットされているか否かを判定する（Ｓ２２０）。
そして、全アプリタスクＡＰ１〜ＡＰｘのスリープ可能フラグがセットされていれば（Ｓ２２０：ＹＥＳ）、当該マイコン１３を通常動作時よりも消費電力の少ないスリープモードに移行させるための処理を行う（Ｓ２３０）。例えば、ＣＰＵ２１へクロックを供給している発振回路の動作を停止させたり、当該マイコン１３へ電源を供給している電源回路の動作を停止させたりする。このため、Ｓ２３０の処理が行われると、当該マイコン１３が動作を停止することとなる。また、Ｓ２３０では、ＣＰＵ２１のクロック周波数又は電源電圧を下げるような処理を行うようにしても良い。

一方、上記Ｓ２２０で否定判定した場合（即ち、何れか１つでもスリープ可能フラグがセットされていない場合）には、そのまま当該状態管理部ＳＭの処理が終了するか、或いは他の処理が行われた後、当該状態管理部ＳＭの処理が終了する。

次に、上記各処理の作用について、図５及び図６を用い説明する。尚、ここでは、前述した図７の例と同様に、アプリタスクが、アプリタスクＡＰ１とアプリタスクＡＰ２との２つであると共に、システムタスクＳＴによって、アプリタスクＡＰ１が１ｍｓ毎に起床要求され、アプリタスクＡＰ２が２ｍｓ毎に起床要求され、更に、各タスクの優先順位は、「システムタスクＳＴ＞アプリタスクＡＰ１＞アプリタスクＡＰ２」の順になっているものとする。また、図５に記載しているステップ番号（Ｓで始まる番号）は、図３，図４の処理において該当するステップ番号である。

まず図５に示すように、アプリタスクＡＰ１によってスリープ可能関数（「ＳｌｅｅｐＯＫ（１）」）がコールされると、状態管理部ＳＭが起動して、Ｆｌａｇ（１）をセットすると共に、全アプリタスクＡＰ１，ＡＰ２のスリープ可能フラグ（Ｆｌａｇ（１），Ｆｌａｇ（２））が全てセットされているか否かを判定する。

そして、この時点では、アプリタスクＡＰ２のスリープ可能フラグ（Ｆｌａｇ（２））が未セットであるため、マイコン１３はスリープモードにならず、そのまま通常動作を続ける。

その後、アプリタスクＡＰ２によってスリープ可能関数（「ＳｌｅｅｐＯＫ（２）」）がコールされると、再び状態管理部ＳＭが起動して、Ｆｌａｇ（２）をセットすると共に、全アプリタスクＡＰ１，ＡＰ２のスリープ可能フラグ（Ｆｌａｇ（１），Ｆｌａｇ（２））が全てセットされているか否かを判定する。

そして、この時点では、全アプリタスクＡＰ１，ＡＰ２のスリープ可能フラグが全てセットされているため、状態管理部ＳＭは、マイコン１３をスリープモードに移行させるための処理を行う。すると、マイコン１３が動作を停止することとなる。尚、スリープモードに移行させるための処理として、ＣＰＵ２１のクロック周波数又は電源電圧を下げるような処理を行う場合には、ＣＰＵ２１が通常時よりも低速で動作することとなる。

このようなマイコン１３によれば、図６に示すように、全てのアプリタスクがスリープ可能状態になった時（この例では、アプリタスクＡＰ２がスリープ可能状態になった時）であって、当該マイコン１３がスリープモードに入れる状態になった時に、即座にスリープモードへと移行することができる。よって、前述の従来技術で生じていた無駄な電力消費を無くすことができる。

また、本実施形態では、状態管理部ＳＭとしての機能を、プログラムによって実現しているため、ハードウェアを追加しなくても上記効果を得ることができる。また、最低優先度のタスクとして、アイドルタスクを設けた場合、そのアイドルタスクに何らかの機能（例えば、メモリの異常チェック機能等）を組み込み易いという利点もある。

そして、このようなマイコン１３を備えたＥＣＵ１１によれば、動作しなくても良い場合の消費電力を従来よりも抑制することができる。
尚、本実施形態では、状態管理部ＳＭが、スリープ移行管理手段、又はコンピュータをスリープ移行管理手段として機能させるためのプログラムに相当している。

以上、本発明の一実施形態について説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々なる態様で実施し得ることは勿論である。

例えば、システムタスクＳＴや状態管理部ＳＭの機能は、ＯＳに持たせるようにしても良い。
また、状態管理部ＳＭの処理は、システムタスクＳＴや何れかのアプリタスク内で実行されるようにしてもよい。

また、システムタスクＳＴ内でアプリケーションの処理が実施されるようにしても良い。つまり、あるアプリタスクがシステムタスクＳＴの代わりにタスク起床等の制御を行っても良い。

また、図２ではアプリタスクの数（ｘ）を２以上としたが、アプリタスクの数は１つであっても良い。
一方、本発明は、前述したようなボデー系の機能を制御するＥＣＵに限らず、例えばエンジンやトランスミッション等のパワートレイン系を制御するＥＣＵ等にも適用することができ、また、車両用以外のＥＣＵに対しても同様に適用することができる。

実施形態の車両用電子制御装置（ＥＣＵ）の構成を表す図である。 マイコンで実行されるソフトウェア構成を表す図である。 各アプリケーションタスクの処理内容を表すフローチャートである。 状態管理部ＳＭの処理内容を表すフローチャートである。 図３及び図４の処理による作用を説明する説明図である。 実施形態の効果を表すタイムチャートである。 従来技術及びその問題を説明する説明図である。

符号の説明

１１…ＥＣＵ、１３…マイコン、１５…入力回路、１７…出力回路、１８…通信線、１９…通信回路、２１…ＣＰＵ、２３…ＲＯＭ、２５…ＲＡＭ、２７…Ｉ／Ｏポート、ＡＰ１〜ＡＰｘ…アプリタスク、ＳＭ…状態管理部、ＳＴ…システムタスク

Claims (4)

1. アプリケーションタスクが実行されるマイクロコンピュータにおいて、
   前記アプリケーションタスクから、そのアプリケーションタスクが実行されなくても良い状態（以下、スリープ可能状態という）であることが通知されると起動し、その通知に該当するアプリケーションタスクがスリープ可能状態であるという履歴を記憶すると共に、全アプリケーションタスクについての前記履歴をチェックすることにより、全アプリケーションタスクがスリープ可能状態であるか否かを判定し、その判定で肯定判定したならば、当該マイクロコンピュータを通常動作時よりも消費電力の少ないスリープモードに移行させるスリープ移行管理手段を備えており、
   前記アプリケーションタスクでは、そのアプリケーションタスクがスリープ可能状態になると上記通知を行うための通知処理が行われるようになっていること、
   を特徴とするマイクロコンピュータ。
2. 請求項１に記載のマイクロコンピュータにおいて、
   前記通知処理は、前記アプリケーションタスクの末尾で行われること、
   を特徴とするマイクロコンピュータ。
3. コンピュータを請求項１に記載のスリープ移行管理手段として機能させるためのプログラム。
4. 請求項１又は請求項２に記載のマイクロコンピュータを備えた車両用電子制御装置。

Images