JP3610930B2 - オペレーティングシステム、プログラム、車両用電子制御装置 - Google Patents
オペレーティングシステム、プログラム、車両用電子制御装置 Download PDFInfo
- Publication number
- JP3610930B2 JP3610930B2 JP2001212487A JP2001212487A JP3610930B2 JP 3610930 B2 JP3610930 B2 JP 3610930B2 JP 2001212487 A JP2001212487 A JP 2001212487A JP 2001212487 A JP2001212487 A JP 2001212487A JP 3610930 B2 JP3610930 B2 JP 3610930B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- state
- time
- operating system
- power consumption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
- G06F1/26—Power supply means, e.g. regulation thereof
- G06F1/32—Means for saving power
- G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
- G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
- G06F1/3228—Monitoring task completion, e.g. by use of idle timers, stop commands or wait commands
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
- G06F1/26—Power supply means, e.g. regulation thereof
- G06F1/32—Means for saving power
- G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
- G06F1/3234—Power saving characterised by the action undertaken
- G06F1/3237—Power saving characterised by the action undertaken by disabling clock generation or distribution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
- G06F1/26—Power supply means, e.g. regulation thereof
- G06F1/32—Means for saving power
- G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
- G06F1/3234—Power saving characterised by the action undertaken
- G06F1/324—Power saving characterised by the action undertaken by lowering clock frequency
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Power Sources (AREA)
Description
【０００１】
【発明の属する技術分野】
オペレーティングシステム等に関する。
【０００２】
【従来の技術】
従来より、マイコン等のコンピュータシステムには、例えばＣＰＵのクロック周波数を通常動作モードより下げたり、クロックの供給を停止することで、消費電力を低減させる低消費電力モードを備えるものがある。こうした低消費電力モードではプログラムの実行が停止等するため、システムの動作に支障がない時点で、通常動作モードから低消費電力モードへの投入を行う必要がある。そのため、通常動作モードから低消費電力モードへの投入時期と投入時間はプログラムによる処理で決定される。
【０００３】
例えば、マイコンを搭載したコンピュータシステムの一例として車両のドアロック制御等を行うドア電子制御装置（ＥＣＵ）の通常動作モードと低消費電力モードの切替の例を説明する。
ドア電子制御ＥＣＵは、図８に示すように、通常動作モードでは５ｍｓ毎に処理Ａの実行を開始し、その後、処理Ａ→処理Ｂ→処理Ｃ→…→処理ｎの順に処理を実行する。例えば、処理Ａはキーレスエントリーに関する処理、処理Ｂはドアロックに関する処理のように所定の機能を実現するアプリケーション処理である。各処理内では、その処理における処理結果に基づき、低消費電力モードに投入可能か否かを示すフラグをセットする。例えば、処理Ｂのドアロックに関する処理では、ドアロックがかかってドアが閉まってから１０分が経過した場合に、低消費電力モード投入可能のフラグを立てる。
【０００４】
そして、すべてのアプリケーション処理（処理Ａ〜ｎ）が完了すると状態管理処理を行う。この状態管理処理では、各アプリケーション処理内でセットされた低消費電力モードに投入可能か否かを示すフラグの値に基づき、通常動作モードにするか、間欠動作モードにするかを決定する。例えば、処理Ａ〜ｎで設定されたすべてのフラグの値が投入可能を示す場合には間欠動作モードに投入し、いずれかのフラグの値が投入不可能を示す場合には通常動作モードとする。
【０００５】
通常動作モードでは、そのまま５ｍｓ毎に処理Ａを開始させマイコンを低消費電力モードには投入しない。一方、間欠動作モードでは５ｍｓの実行開始間隔（図９のＴ１参照）を３００ｍｓ（図９のＴ２参照）に変更して、次のアプリケーション処理（処理１〜ｎ）の実行完了時からその次の実行開始時点までマイコンを低消費電力モードに投入する（図９のＴ３参照）。このようにして、通常動作モードから低消費電力モードへの切替を行い、各アプリケーションの処理に支障をきたすことなくＥＣＵの消費電力を削減している。
【０００６】
【発明が解決しようとする課題】
しかしながら、このように定期的に一連のプログラムの実行を開始する方法ではプログラムの規模が増大すると、プログラムの作成が困難になったり、プログラムの実行時間の最大値（図９のＴ０）が大きくなりシステムの応答性が悪くなる。そのため例えば、各処理をタスクとして管理し、タスクを切り替えて実行すするリアルタイムＯＳ等を利用する必要がある。こうしたリアルタイムＯＳ等のマルチタスクオペレーティングシステムでは、定期的にプログラムの実行を開始するメカニズムのみではなく、実行するジョブのあるタスクを実行するメカニズムをも採用している。
【０００７】
このようなリアルタイムＯＳのタスクの状態遷移の一例を図３に示す。
図３に示すリアルタイムＯＳはタスクを実行中の状態である実行状態（図３におけるｒｕｎｎｉｎｇ）と実行可能状態（ｒｅａｄｙ）と待ち状態（ｗａｉｔｉｎｇ）と休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させて管理する。待ち状態（ｗａｔｉｎｇ）と休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクは、条件待ち状態であり、所定の条件が成立した際に実行可能状態（ｒｅａｄｙ）に遷移させる。例えばオペレーティングシステムは所定の割込み等の休止解除条件が成立した場合には、休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクを実行可能状態（ｒｅａｄｙ）へ遷移させる。また、実行状態（ｒｕｎｎｉｎｇ）のタスクからイベントを受けた際に、対応するイベントを待つタスクを待ち状態（ｗａｔｉｎｇ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
【０００８】
実行状態（ｒｕｎｎｉｎｇ）は実行中のタスクの状態であり、同時に実行可能なタスクの数だけその状態をとりうる。すなわち、タスクを実行するＣＰＵが１個であれば、実行状態（ｒｕｎｎｉｎｇ）をとるタスクは、同時には１個となる。
実行状態（ｒｕｎｎｉｎｇ）のタスクが実行を完了するとオペレーティングシステムは、そのタスクを休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させる。また、実行状態（ｒｕｎｎｉｎｇ）のタスクからイベント待ちの指示を受けると、そのタスクを待ち状態（ｗａｔｉｎｇ）へ遷移させる。
【０００９】
このような遷移により実行状態（ｒｕｎｎｉｎｇ）へタスクの割り当てが可能となると、オペレーティングシステムは、実行可能状態（ｒｅａｄｙ）のタスクの中で最も優先度の高いタスクを実行状態（ｒｕｎｎｉｎｇ）へ遷移させて、そのタスクの実行を開始する。
【００１０】
また、実行可能状態（ｒｅａｄｙ）のタスクの中に実行状態（ｒｕｎｎｉｎｇ）のタスクよりも優先度の高いタスクがある場合には、実行状態（ｒｕｎｎｉｎｇ）のタスクを実行可能状態（ｒｅａｄｙ）へ遷移させ（「プリエンプトする」という）、その優先度の高い実行可能状態（ｒｅａｄｙ）のタスクを実行状態（ｒｕｎｎｉｎｇ）に遷移させて実行する。
【００１１】
このようにタスクの状態は、割込みの発生状況、実行中のタスクからのシステムコールの発行、優先度等の要因により随時変化する。例えば図４に示すように実行中タスク（実行状態（ｒｕｎｎｉｎｇ）のタスク）は、タスクＡ→タスクＢ→タスクｎのように連続してディスパッチされたり、その後しばらく時間を空けてタスクＢが実行されたりする。
【００１２】
このようにタスクの状態が随時変化するため、アプリケーション処理の終了後から次の実行開始までの残りの時間（図９のＴ３）も一意に定義できない。また低消費電力モードへの投入時期を従来のように処理の実行完了後に決定してしまうことができない。
【００１３】
そこで本発明はマルチタスクＯＳにおいてシステムの消費電力を低減させることのできるオペレーティングシステム等を提供することを目的とする。
【００１４】
【課題を解決するための手段及び発明の効果】
上述した問題点を解決するためになされた請求項１に記載のオペレーティングシステムは、実行状態のタスクと実行可能状態のタスクが存在しない場合にＣＰＵを低消費電力モードに投入する。よって実行状態または実行可能状態のタスクが存在する場合には低消費電力モードへの投入は行われない。したがってタスクの実行中に低消費電力モードに投入されることがない。また、実行可能状態のタスクがある状態で低消費電力モードに投入されることにより実行可能状態のタスクの実行が遅延するといったこともない。すなわち、このようなオペレーティングシステムによれば、アプリケーションの処理への影響を抑えて適切な投入時期に低消費電力モードに投入することができる。
【００１５】
そしてさらに、請求項１に記載のオペレーティングシステムでは、実行状態のタスクと実行可能状態のタスクが存在せず、かつ、実行状態のタスクと実行可能状態のタスク以外のその他の状態のタスクのうち次に実行可能状態に遷移するまでの残り時間が最も少ないタスクの残り時間（最小残り時間）を加味した時間を投入時間として設定してＣＰＵを低消費電力モードに投入する。
【００１６】
実行状態や実行可能状態以外のその他の状態のタスク（例えば、図３に示す待ち状態（ｗａｔｉｎｇ）や休止状態（ｓｕｓｐｅｎｄｅｄ）のタスク）が次に実行可能状態（図３ではｒｅａｄｙ）に遷移するまでの時間は、オペレーティングシステムが把握できるものとできないものとがある。例えば、定期的に発生するイベントや割込み等によって遷移するタスクのように遷移までの残り時間が予測可能なタスクや、遷移までの残り時間をオペレーティングシステムが管理しているタスクは、オペレーティングシステムが遷移までの残り時間を把握することができる。一方、例えば不定期な割込みなどを要因として遷移するタスクなどは遷移までの残り時間を把握することができない。
【００１７】
このうちオペレーティングシステムが残り時間を把握できないタスクに関しては、前述したように実行可能状態に遷移した時点で、低消費電力モードへの投入をパスする。一方、オペレーティングシステムが把握できるタスクに関しては、その把握した各タスクの遷移までの残り時間のうち最も少ない残り時間（最小残り時間）を加味した時間を投入時間として設定して低消費電力モードに投入する。したがって、実行可能状態に遷移するまでの残り時間が把握できるその他の状態タスクについて、これらのタスクが実行可能状態に遷移するのを妨げることなく低消費電力モードに投入することが可能となる。
【００１８】
例えば、請求項２に示すように低消費電力モードへの投入時間を最小残り時間よりも短い時間とすれば、その残り時間を待ってそのタスクをその他の状態から実行可能状態に遷移させることができる。よって、低消費電力モードへの投入時間が最小残り時間をオーバーすることがなくなり、低消費電力モードへの投入時間をさらに適切に設定することができる。したがって、低消費電力モードへの投入によるアプリケーションの実行への影響を抑えることができる。
【００１９】
そして、こうした低消費電力モードへの投入は、常に行うようにしてもよいが、請求項３に示すように所定の投入許可時間より長い場合に行うようにするとよい。この投入許可時間は、低消費電力モードを実現するハードウェアで既定される投入可能時間や実行するジョブの種類に応じて設定すればよい。また例えば、実際に複数の投入許可時間を設定して消費電力と処理能力を実測し、そのアプリケーションに最も適した時間を投入許可時間を求めて設定してもよい。
【００２０】
ところで、その他の状態としては、例えば、タスク生成中の状態や異常停止状態等を含めることができるが、一般的には請求項４に示すように条件待ち状態である。このような条件待ち状態としては、例えば、入出力待ち状態、仮想メモリ処理待ち状態、通信待ち状態、同期待ち状態、その他の条件待ち状態などを設けることができる。
【００２１】
条件待ち状態として例えばイベント待ち状態を持ち、次のイベント発生までの時間がオペレーティングシステムにおいて把握できる場合には、その把握した中で最も直近のイベント発生までの時間と所定の低消費電力モード投入可能時間とを比較して低消費電力モードに投入するか否かを判定することができる。また例えば、請求項５に示すように条件待ち状態のタスクに遷移条件としてアラームが設定されている場合には、そのアラームの設定時間と所定の低消費モード投入可能時間とを比較して低消費電力モードに投入可能か否かを判定するとよい。
【００２２】
このようにして低消費電力モードに投入すると、ＣＰＵのクロックが停止したり低下することにより、例えばオペレーティングシステムのソフトウェアで管理されているタイマ（カウンタ）が停止したり遅れたりする。このような場合には、請求項６に示すようにしてタイマの値を補正すればよい。このような補正を行うことで例えばアラームのカウント時間等がこのタイマに依存する場合であっても、正しいアラームの設定時間にタスクの状態を遷移させることが可能となる。
【００２３】
なお、補正は、例えば、低消費電力モードの投入時間満了によって低消費電力モードから通常動作モードに復帰した場合には投入時間をタイマに足し込むことで行えばよい。また例えば割込みによって低消費電力モードから通常動作モードに復帰した場合には、低消費電力モードに投入されていた時間は少なくとも投入時間以下の時間であるので、例えば投入時間の半分の時間をタイマに足し込むようにすればよい。
【００２４】
なお、低消費電力モードは、例えばスリープモードやスタンバイモードと呼ばれるものを含む。例えばＣＰＵのクロックを停止させるだけでなく、ＣＰＵの周辺装置のクロックを停止させるように構成してもよい。このようにすれば、さらに消費電力を低減できる。
【００２５】
そして、こうしたオペレーティングシステムは、ハードウェアで実現することも可能であるが、請求項７に示すようにコンピュータに実行させるためのプログラムとして構成するのが一般的である。このようなプログラムの場合、例えば、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読みとり可能な記録媒体に記録し、必要に応じてコンピュータにロードして起動することにより用いることができる。また、ネットワークを介してロードして起動することにより用いることもできる。
【００２６】
なお、請求項１〜６のいずれかに記載の内容は、それぞれＣＰＵの消費電力管理方法をオペレーティングシステムによって実現させる方法を示している。したがって、オペレーティングシステムに代えてＣＰＵの消費電力モード管理方法とすることもできる。このような消費電力モード管理方法によれば、上述した各請求項と同様の効果を得ることができ、オペレーティングシステムにおいて適切に消費電力モードを制御できる。
【００２７】
以上のようなオペレーティングシステムは、種々のコンピュータシステムに適用可能である。例えば請求項８に示すように車両用電子制御装置に適用することができる。このような車両用電子制御装置によれば、車両の制御処理に支障をきたすことなく消費電力を低減することが容易にできる。
【００２８】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００２９】
図１は、実施例としてのオペレーティングシステムを備えたボデーＥＣＵ１０を含むボデー系システム１００を示す図である。ボデー系システム１００は、車内ＬＡＮ５０に接続されたボデーＥＣＵ１０と、車内ＬＡＮ５０を介してボデーＥＣＵ１０と通信可能な通信対象ＥＣＵ２０を備える。ボデーＥＣＵ１０及び通信対象ＥＣＵ２０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等を備えたコンピュータシステムであり、それぞれのＩ／Ｏには入力装置３０、出力装置４０、車内ＬＡＮ５０等が接続されている。
【００３０】
通信対象ＥＣＵ２０は、例えば、Ｄ席ドアＥＣＵ２０ａやＰ席ドアＥＣＵ２０ｂやインパネＥＣＵ２０ｃ等であり、入力装置３０の状態を読み取ってパケットを生成し車内ＬＡＮ５０を介してボデーＥＣＵ１０へ送信する機能と、車内ＬＡＮ５０を介して入力されるボデーＥＣＵ１０からのパケットの制御情報に基づいて出力装置４０を制御する機能を備える。
【００３１】
Ｄ席ドアＥＣＵ２０ａはドライバ側のドアに設置されたＥＣＵであり、入力装置３０としてＤ席ドアコントロールスイッチ３０ａなどが接続されており、出力装置４０としてＤ席ドアロックモータ４０ａやＤ席パワーウインドウモータなどが接続されている。Ｐ席ドアＥＣＵ２０ｂは補助席側のドアに設置されたＥＣＵであり、入力装置３０としてＰ席ドアコントロールスイッチ３０ｂ等が接続され、出力装置４０としてＰ席ドアロックモータ４０ｂやＰ席パワーウインドウモータなどが接続されている。また、インパネＥＣＵは、インパネに設置されたＥＣＵであり、例えば、出力装置４０としてブザー４０ｃやランプ４０ｄ等が接続されている。
【００３２】
ボデーＥＣＵ１０は、通信対象ＥＣＵ２０から車内ＬＡＮ５０に送信されるパケットを受信し、受信したパケットの内容に応じて、各入力装置３０の状態を監視し、制御対象の通信対象ＥＣＵ２０への制御指示を含むパケットを生成して送信する制御処理等を行う。
【００３３】
こうした処理は、ＣＰＵ１２がボデーＥＣＵ１０のＲＯＭ１４に格納されたリアルタイムＯＳのプログラムを実行し、そのリアルタイムＯＳによる管理の下、ＲＯＭ１４に格納されたアプリケーションプログラムに基づくタスクを実行することによって、ＲＡＭ１６や車内ＬＡＮ５０の接続されたＩ／Ｏ１８を制御して行う。またリアルタイムＯＳは、消費電力の制御等の動作モードの管理など各種リソースの管理を行う。
【００３４】
ボデーＥＣＵ１０のＣＰＵ１２は、通常動作モードと低消費電力モード（スリープモード）の２つの動作モードを持つ。通常動作モードは、図２に示すように１６ＭＨｚ（４ＭＨｚ×４）のマシーンクロックに基づいて、ＲＯＭ１４に記憶されたプログラムを実行するモードである。一方、低消費電力モードはＣＰＵ１２へのクロックの供給を停止し、消費電力を低減させるモードである。低消費電力モードへの投入は、ＣＰＵ１２が、ＣＰＵ１２に備えたウェイクアップ用タイマに低消費電力モードへの投入時間であるスリープ時間を書き込んだ後に、スリープ命令を実行した場合に行われる。また低消費電力モードから通常動作モードへの復帰は、ウェイクアップ用タイマに書き込まれたスリープ時間が経過した場合と、スリープ状態で割込みがかかった場合に行われる。
【００３５】
アプリケーションプログラムのタスクとしては、例えば、通信対象ＥＣＵ２０から車内ＬＡＮ５０に送信されるパケットを受信し、受信したパケットの内容に応じた処理を行うタスクがある。また、例えば出力装置４０の制御が必要な場合に制御対象の通信対象ＥＣＵ２０への制御指示を含むパケットを生成して送信する制御処理などをを行う種々のタスクがある。
【００３６】
まず、リアルタイムＯＳの処理によるタスクの管理処理について説明し、次に動作モードの管理処理について説明する。
図３は、本実施例のリアルタイムＯＳによるタスクの状態遷移を示す図である。このリアルタイムＯＳは、タスクを、実行中の状態である実行状態（ｒｕｎｎｉｎｇ）と、実行待ち状態である実行可能状態（ｒｅａｄｙ）と、イベント待ち状態である待ち状態（ｗａｔｉｎｇ）と、休止状態である休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させて実行状態を管理する。
【００３７】
実行状態（ｒｕｎｎｉｎｇ）のタスクはＣＰＵが実行中のタスクであり、同時には最大で１つのタスクがこの状態をとる。なお実行状態以外の状態は、複数のタスクが同時にその状態をとりうる。
実行状態（ｒｕｎｎｉｎｇ）のタスクは、実行を終了する際にオペレーティングシステムに対してターミネートタスクシステムコールを発行する。オペレーティングシステムは実行状態（ｒｕｎｎｉｎｇ）のタスクからのターミネートタスクシステムコールを受けると、そのタスクの状態を休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させる。また、実行中のタスクが所定のイベントを待つ必要がある場合には、ウェイトイベントシステムコールを発行する。ウェイトイベントシステムコールの発行を受けたオペレーティングシステムは、そのタスクの状態を待ち状態（ｗａｔｉｎｇ）に遷移させる。
【００３８】
このようにして実行中のタスクを別の状態に遷移させると、実行状態（ｒｕｎｎｉｎｇ）のタスクが無くなるので、オペレーティングシステムは、実行可能状態（ｒｅａｄｙ）のタスクのうち優先度が最も高いタスクを実行状態（ｒｕｎｎｉｎｇ）に遷移させ、実行を開始する（ディスパッチする）。なお、実行状態（ｒｕｎｎｉｎｇ）のタスクより優先度の高いタスクが実行可能状態（ｒｅａｄｙ）になった際には、実行状態（ｒｕｎｎｉｎｇ）のタスクを実行可能状態（ｒｅａｄｙ）に遷移させ（プリエンプトさせ）、実行可能状態（ｒｅａｄｙ）の優先度の高いタスクを実行状態（ｒｕｎｎｉｎｇ）に遷移させて実行する。すなわちこのリアルタイムＯＳはプリエンプティブなマルチタスクＯＳである。
【００３９】
休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクは、休止解除条件が成立した場合に、実行可能状態に遷移させる。この休止解除条件はタスク毎に設定可能であり、▲１▼所定周期、▲２▼割込み、▲３▼チェーンタスク（連鎖実行）等がある。
「所定周期」は、アラームによって実現される。アラームは、設定された時間が経過した際にその経過を知らせるタイマであり、タスク毎に設定することができる。例えば、実行状態（ｒｕｎｎｉｎｇ）のタスクからのシステムコールによって、所定のタスクに対して１００ｍｓ後にアラームを発火させるといった設定を行うことができる。リアルタイムＯＳは、設定されたアラーム設定時間の経過を監視し、アラーム設定時間が経過した際に、そのタスクを休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
【００４０】
同様に、「割込み」は、割込み要因毎に遷移させるタスクを設定し、該当する割込み要因の発生時に遷移させるものである。
また、「チェーンタスク」は、連続して実行する必要のあるタスクの実行が完了した際に、次に実行すべきタスクを遷移させるものである。例えば、現在のドアロックの状態を得るためには、車内からのドアロックの状態をチェックした後、連続して車外のからのドアロックの状態をチェックする必要がある。このような場合には、例えば車内のロックの状態をチェックするタスクＡを実行したあと連続して、車外側のロックの状態をチェックするタスクＢを実行する必要がある。こうした場合、予めタスクＢのタスクＡに対するチェーンタスクを設定しておき、タスクＡの実行が完了した際にタスクＢを休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
【００４１】
一方、実行状態（ｒｕｎｎｉｎｇ）のタスクからセットイベントシステムコールが発行された場合には、そのシステムコールで指定されたイベントに対応するタスクを待ち状態（ｗａｔｉｎｇ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
このようにタスクの状態は、実行中のタスクからのシステムコールの発行状況やイベントや割込みの発生状況等により随時変化する。例えば図４に示すように実行中タスク（実行状態（ｒｕｎｎｉｎｇ）のタスク）は、タスクＡ→タスクＢ→タスクｎのように連続して変化した後、しばらく時間を空けてタスクＢがディスパッチされている。この最初のタスクＡ→タスクＢ→タスクｎの遷移は、タスクＡが実行状態（ｒｕｎｎｉｎｇ）から休止状態（ｓｕｓｐｅｎｄｅｄ）あるいは待ち状態（ｗａｔｉｎｇ）に遷移した際にタスクＢが実行可能状態（ｒｅａｄｙ）にあり、すぐにリアルタイムＯＳのスケジューリングによってタスクＢが実行状態（ｒｕｎｎｉｎｇ）にディスパッチされたことを示している。一方、タスクｎが実行状態（ｒｕｎｎｉｎｇ）から他の状態に遷移した際には実行可能状態（ｒｅａｄｙ）のタスクはなく、その後、タスクＢが実行可能状態（ｒｅａｄｙ）に遷移した際に実行状態（ｒｕｎｎｉｎｇ）へディスパッチされたことを示している。
【００４２】
次に、こうしたタスクの状態を変化して管理するリアルタイムＯＳによる動作モード（通常動作モードと低消費電力モード）の管理処理について図５を参照して説明する。
図５に示すように、タスクスケジューリングを行った場合には（Ｓ１１０）、実行可能状態（ｒｅａｄｙ）及び実行状態（ｒｕｎｎｉｎｇ）にタスクがあるか否かを判定する（Ｓ１２０）。実行可能状態（ｒｅａｄｙ）または実行状態（ｒｕｎｎｉｎｇ）のいずれかにタスクが存在する場合には（Ｓ１２０：あり）、低消費電力モードへは移行はせずにＳ１１０のタスクスケジューリングに戻る。一方、実行可能状態（ｒｅａｄｙ）と実行状態（ｒｕｎｎｉｎｇ）の双方にタスクが存在しない場合には（Ｓ１２０：なし）、Ｓ１３０へ移行する。
【００４３】
Ｓ１３０では、休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクが実行可能状態（ｒｅａｄｙ）に移行するまでの時間が一定時間（所定の低消費電力モード投入可能時間に相当する）以上あるか否かを判定する。この時点で休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクのうち実行可能状態（ｒｅａｄｙ）に移行する時期が把握できるのは、前述した▲１▼のアラームの発火によって休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移するタスクである。なお、これ以外の要因（前述▲２▼または▲３▼）の発生によって、休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）にタスクの状態が遷移した場合には、前述したＳ１２０の判定によって低消費電力モードへの移行は行われない。
【００４４】
アラームは、図６に示すように、タスク毎にカウンタ値が設定可能なカウンタから構成される。このカウンタの値は、リアルタイムＯＳのソフトウェアで構成されたシステムタイマの値に基づいてカウントする。例えばシステムタイマが５カウントされる毎にカウンタの値をそれぞれ１デクリメントし、最終的にカウンタの値が０になった時に、そのタスクの状態を休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移させる指示を出す。このようにアラームのカウンタの値が０になることをアラームが発火する（ｅｘｐｉｒｅ）という。例えば図６のように、タスクＡにアラーム１、タスクＢにアラーム２、タスクＣにアラーム３がそれぞれ割り当てられ、アラーム１に１００、アラーム２に１０、アラーム３に１２０がセットされているとする。リアルタイムＯＳはアラームの単位時間が経過する毎にそれぞれのアラームの値を１づつデクリメントする。これらのアラームのうちで発火までの残り時間が最も少ないもの（すなわち現時点で次に発火する予定のアラーム）の残り時間と、投入を許可する最低の時間である投入許可時間とを比較し（図５のＳ１３０）、投入許可時間より残り時間の方が大きい場合に（Ｓ１３０：あり）、Ｓ１４０へ移行する。一方、残り時間が投入許可時間以下の場合には（Ｓ１３０：なし）、Ｓ１１０へ戻る。すなわち、直近のアラームの発火までに、投入許可時間以下の時間しかない場合には、低消費電力モードへの投入は行わない。例えば、現在のアラームの状態が図６のｔ１の状態である場合には、アラーム２の値「１０」がアラームのうちで発火までの時間が最も少ないもの（最小残り時間）に相当し、そのアラームの時間は、アラーム２のカウンタの値「１０」にアラームの単位時間を掛けたものになる。したがって、例えばシステムタイマが１ｍｓ毎にカウントしておりアラームの単位時間が５ｍｓであれば、次のアラーム発火までの残り時間は、５ｍｓ×１０＝５０ｍｓとなる。ここで、低消費電力モードへの投入許可時間を例えば３００ｍｓとすると、Ｓ１３０の判定では、次のアラームまでの残り時間＜投入許可時間となるので、「Ｓ１３０：なし」となりＳ１１０へ移行し、低消費電力モードへの投入は行われない。一方、時刻ｔ３では、アラーム１が次に発火するアラームとなり、発火までの残り時間は５ｍｓ×８９＝４４５ｍｓとなって、次のアラームまでの残り時間＞投入許可時間となるので、「Ｓ１３０：あり」となりＳ１４０へ移行する。なお、低消費電力モードへの投入許可時間は、ハードウェアの制限を加味して、実際に投入許可時間を何パターンか設定して、消費電力と処理能力を実測して最も適した時間に設定する。例えば、選択可能なスリープ時間が図２に示す４パターン（２ｍｓ・８ｍｓ・３２ｍｓ・２５６ｍｓ）であれば、これらの時間のいずれかを投入許可時間として決定すればよい。
【００４５】
Ｓ１４０では、最もアラームの発火までの残り時間の少ないアラームの持つ残り時間よりも短い時間であり、かつ、ウェイクアップタイマに設定可能な時間を投入時間として設定して、低消費電力モードへ投入する。例えば、前述したｔ３時点では、次のアラームの発火まで４４５ｍｓある。したがって４４５ｍｓより短い時間の間、ＣＰＵ１２を低消費電力モードに投入する。ＣＰＵ１２は、図２に示すように２ｍｓ・８ｍｓ・３２ｍｓ・２５６ｍｓのスリープ時間（投入時間）を選択可能であるので、例えば２５６ｍｓをスリープ時間としてウェイクアップタイマのレジスタに設定する。もちろん、スリープ時間が任意に設定できるウェイクアップタイマを備えたＣＰＵであれば、例えばスリープ時間を４４０ｍｓなどに設定してもよい。このようにウェイクアップタイマの設定を行い、スリープ命令を実行して、スリープモード（低消費電力モード）に投入する。
【００４６】
すると、ＣＰＵ１２へ供給されるマシーンクロックは停止し、ウェイクアップタイマがウェイクアップまでの時間をカウントする（図５のＳ１５０の処理に相当する。）。
設定されたスリープ時間に達するか、外部割込みがかかった場合には、ＣＰＵ１２へのクロックの供給が再開され、通常動作モードに復帰してＳ１６０へ移行する。
【００４７】
Ｓ１６０では、通常動作モードへの復帰要因が外部割込みの場合には（Ｓ１６０：外部割込み）Ｓ１８０へ移行して投入時間の半分の時間に相当する値をシステムクロックに足し込んで（Ｓ１８０）、Ｓ１１０のタスクスケジューリングに戻る。一方、通常動作モードへの復帰要因が低消費電力モードへのスリープ時間（投入時間）満了の場合は（Ｓ１６０：満了）、低消費電力モードへの投入時間に相当する値をシステムクロックに足し込んで（Ｓ１７０）、Ｓ１１０へ戻る。これは基準となるシステムタイマが低消費電力モードの間停止してしまうため、補正するものである。このような補正処理により、アラームのカウンタの値もほぼ正しい値となり、処理を正常に継続することができる。
【００４８】
このような動作モードの管理処理によって、実行状態（ｒｕｎｎｉｎｇ）と実行可能状態（ｒｅａｄｙ）のタスクが存在しない状態で、かつ、アラームの発火までの残り時間が最も短いものについてその残り時間が所定の低消費電力モード投入可能時間より長い場合にＣＰＵをその残り時間より短い時間の間、低消費電力モードに投入することができる。したがって、実行状態（ｒｕｎｎｉｎｇ）や実行可能状態（ｒｅａｄｙ）のタスクやアラームの設定されているタスクの実行を妨げることなく、ボデーＥＣＵ１０の消費電力を低減することができる。また、タスクは動作モードを意識する必要がないため、アプリケーションプログラムの作成が容易にできる。
［別実施例］
（１）上記実施例においては、アラームの値は、アラームの単位時間が経過する毎にデクリメントしその値が０になった際に発火することとしたが、アラームの発火時間をシステムタイマの値の増分や絶対時間で設定するようにしてもよい。例えば、１ｍｓ毎にカウントされるシステムタイマの値が、図７（ａ）に示すように１０３００の時に発火するといった具合に設定してもよい。また、３００毎に発火するというように設定できるようにしてもよい。この場合も、図５のＳ１７０及びＳ１８０と同様の処理によって、低消費電力モードから復帰した際にシステムクロックに相当する時間を足し込む。すなわち、スリープ時間が１３０ｍｓであればスリープから復帰した際に１３０をシステムタイマに足し込む。こうすることで、図７（ｂ）に示すようなスリープによるシステムタイマの停止を原因とするアラームの発火のディレイ（遅延）を起こすことなく、図７（ｃ）に示すように正しい時間にアラームを発火させることができる。
（２）上記実施例においては、図３に示すように４つの状態でタスクを管理するオペレーティングシステムについて説明したが、もちろんこれに限定されない。例えば、待ち状態（ｗａｔｉｎｇ）を除く３つの状態をとるオペレーティングシステムや、さらに多くの状態をとるオペレーティングシステムであっても適用できる。また上記実施例では、プリエンプティブなマルチタスクＯＳとして説明したが、もちろんノンプリエンプティブなＯＳであっても適用できる。
（３）上記実施例においては、図１に示す車両のボデー系システム１００におけるボデーＥＣＵ１０のオペレーティングシステムとして説明したが、各通信対象ＥＣＵ２０のオペレーティングシステムとしても適用できる。また、その他の種々の車両用制御装置やその他の各種装置にも適用できる。特に、電池（バッテリー）駆動型の機器など、低消費電力が要求される機器のオペレーティングシステムとして処理能力と消費電力のバランスに優れた電力制御を実現することができる。
【図面の簡単な説明】
【図１】実施例のオペレーティングシステムを備えたボデーＥＣＵを含むボデー系システムの構成を示すブロック図である。
【図２】通常動作モードと低消費電力モードを実現する構成を示す説明図である。
【図３】実施例のオペレーティングシステムの管理するタスクの状態遷移に関する説明図である。
【図４】タスクの実行状態と動作モードの例を示す説明図である。
【図５】実施例のオペレーティングシステムにおける動作モードの管理処理を示すフローチャートである。
【図６】アラームの例を示す説明図である。
【図７】別実施例のアラームと実行状態を示す説明図である。
【図８】従来のスケジューラによる処理方法を示す説明図である。
【図９】図８の従来の処理方法における動作モードの切替方法を説明する図である。
【符号の説明】
１００…ボデー系システム
１０…ボデーＥＣＵ
２０…通信対象ＥＣＵ
２０ａ…Ｄ席ドアＥＣＵ
２０ｂ…Ｐ席ドアＥＣＵ
３０…入力装置
３０ａ…Ｄ席ドアコントロールスイッチ
３０ｂ…Ｐ席ドアコントロールスイッチ
４０…出力装置
４０ａ…Ｄ席ドアロックモータ
４０ｂ…Ｐ席ドアロックモータ
４０ｃ…ブザー
５０…車内ＬＡＮ
【発明の属する技術分野】
オペレーティングシステム等に関する。
【０００２】
【従来の技術】
従来より、マイコン等のコンピュータシステムには、例えばＣＰＵのクロック周波数を通常動作モードより下げたり、クロックの供給を停止することで、消費電力を低減させる低消費電力モードを備えるものがある。こうした低消費電力モードではプログラムの実行が停止等するため、システムの動作に支障がない時点で、通常動作モードから低消費電力モードへの投入を行う必要がある。そのため、通常動作モードから低消費電力モードへの投入時期と投入時間はプログラムによる処理で決定される。
【０００３】
例えば、マイコンを搭載したコンピュータシステムの一例として車両のドアロック制御等を行うドア電子制御装置（ＥＣＵ）の通常動作モードと低消費電力モードの切替の例を説明する。
ドア電子制御ＥＣＵは、図８に示すように、通常動作モードでは５ｍｓ毎に処理Ａの実行を開始し、その後、処理Ａ→処理Ｂ→処理Ｃ→…→処理ｎの順に処理を実行する。例えば、処理Ａはキーレスエントリーに関する処理、処理Ｂはドアロックに関する処理のように所定の機能を実現するアプリケーション処理である。各処理内では、その処理における処理結果に基づき、低消費電力モードに投入可能か否かを示すフラグをセットする。例えば、処理Ｂのドアロックに関する処理では、ドアロックがかかってドアが閉まってから１０分が経過した場合に、低消費電力モード投入可能のフラグを立てる。
【０００４】
そして、すべてのアプリケーション処理（処理Ａ〜ｎ）が完了すると状態管理処理を行う。この状態管理処理では、各アプリケーション処理内でセットされた低消費電力モードに投入可能か否かを示すフラグの値に基づき、通常動作モードにするか、間欠動作モードにするかを決定する。例えば、処理Ａ〜ｎで設定されたすべてのフラグの値が投入可能を示す場合には間欠動作モードに投入し、いずれかのフラグの値が投入不可能を示す場合には通常動作モードとする。
【０００５】
通常動作モードでは、そのまま５ｍｓ毎に処理Ａを開始させマイコンを低消費電力モードには投入しない。一方、間欠動作モードでは５ｍｓの実行開始間隔（図９のＴ１参照）を３００ｍｓ（図９のＴ２参照）に変更して、次のアプリケーション処理（処理１〜ｎ）の実行完了時からその次の実行開始時点までマイコンを低消費電力モードに投入する（図９のＴ３参照）。このようにして、通常動作モードから低消費電力モードへの切替を行い、各アプリケーションの処理に支障をきたすことなくＥＣＵの消費電力を削減している。
【０００６】
【発明が解決しようとする課題】
しかしながら、このように定期的に一連のプログラムの実行を開始する方法ではプログラムの規模が増大すると、プログラムの作成が困難になったり、プログラムの実行時間の最大値（図９のＴ０）が大きくなりシステムの応答性が悪くなる。そのため例えば、各処理をタスクとして管理し、タスクを切り替えて実行すするリアルタイムＯＳ等を利用する必要がある。こうしたリアルタイムＯＳ等のマルチタスクオペレーティングシステムでは、定期的にプログラムの実行を開始するメカニズムのみではなく、実行するジョブのあるタスクを実行するメカニズムをも採用している。
【０００７】
このようなリアルタイムＯＳのタスクの状態遷移の一例を図３に示す。
図３に示すリアルタイムＯＳはタスクを実行中の状態である実行状態（図３におけるｒｕｎｎｉｎｇ）と実行可能状態（ｒｅａｄｙ）と待ち状態（ｗａｉｔｉｎｇ）と休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させて管理する。待ち状態（ｗａｔｉｎｇ）と休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクは、条件待ち状態であり、所定の条件が成立した際に実行可能状態（ｒｅａｄｙ）に遷移させる。例えばオペレーティングシステムは所定の割込み等の休止解除条件が成立した場合には、休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクを実行可能状態（ｒｅａｄｙ）へ遷移させる。また、実行状態（ｒｕｎｎｉｎｇ）のタスクからイベントを受けた際に、対応するイベントを待つタスクを待ち状態（ｗａｔｉｎｇ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
【０００８】
実行状態（ｒｕｎｎｉｎｇ）は実行中のタスクの状態であり、同時に実行可能なタスクの数だけその状態をとりうる。すなわち、タスクを実行するＣＰＵが１個であれば、実行状態（ｒｕｎｎｉｎｇ）をとるタスクは、同時には１個となる。
実行状態（ｒｕｎｎｉｎｇ）のタスクが実行を完了するとオペレーティングシステムは、そのタスクを休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させる。また、実行状態（ｒｕｎｎｉｎｇ）のタスクからイベント待ちの指示を受けると、そのタスクを待ち状態（ｗａｔｉｎｇ）へ遷移させる。
【０００９】
このような遷移により実行状態（ｒｕｎｎｉｎｇ）へタスクの割り当てが可能となると、オペレーティングシステムは、実行可能状態（ｒｅａｄｙ）のタスクの中で最も優先度の高いタスクを実行状態（ｒｕｎｎｉｎｇ）へ遷移させて、そのタスクの実行を開始する。
【００１０】
また、実行可能状態（ｒｅａｄｙ）のタスクの中に実行状態（ｒｕｎｎｉｎｇ）のタスクよりも優先度の高いタスクがある場合には、実行状態（ｒｕｎｎｉｎｇ）のタスクを実行可能状態（ｒｅａｄｙ）へ遷移させ（「プリエンプトする」という）、その優先度の高い実行可能状態（ｒｅａｄｙ）のタスクを実行状態（ｒｕｎｎｉｎｇ）に遷移させて実行する。
【００１１】
このようにタスクの状態は、割込みの発生状況、実行中のタスクからのシステムコールの発行、優先度等の要因により随時変化する。例えば図４に示すように実行中タスク（実行状態（ｒｕｎｎｉｎｇ）のタスク）は、タスクＡ→タスクＢ→タスクｎのように連続してディスパッチされたり、その後しばらく時間を空けてタスクＢが実行されたりする。
【００１２】
このようにタスクの状態が随時変化するため、アプリケーション処理の終了後から次の実行開始までの残りの時間（図９のＴ３）も一意に定義できない。また低消費電力モードへの投入時期を従来のように処理の実行完了後に決定してしまうことができない。
【００１３】
そこで本発明はマルチタスクＯＳにおいてシステムの消費電力を低減させることのできるオペレーティングシステム等を提供することを目的とする。
【００１４】
【課題を解決するための手段及び発明の効果】
上述した問題点を解決するためになされた請求項１に記載のオペレーティングシステムは、実行状態のタスクと実行可能状態のタスクが存在しない場合にＣＰＵを低消費電力モードに投入する。よって実行状態または実行可能状態のタスクが存在する場合には低消費電力モードへの投入は行われない。したがってタスクの実行中に低消費電力モードに投入されることがない。また、実行可能状態のタスクがある状態で低消費電力モードに投入されることにより実行可能状態のタスクの実行が遅延するといったこともない。すなわち、このようなオペレーティングシステムによれば、アプリケーションの処理への影響を抑えて適切な投入時期に低消費電力モードに投入することができる。
【００１５】
そしてさらに、請求項１に記載のオペレーティングシステムでは、実行状態のタスクと実行可能状態のタスクが存在せず、かつ、実行状態のタスクと実行可能状態のタスク以外のその他の状態のタスクのうち次に実行可能状態に遷移するまでの残り時間が最も少ないタスクの残り時間（最小残り時間）を加味した時間を投入時間として設定してＣＰＵを低消費電力モードに投入する。
【００１６】
実行状態や実行可能状態以外のその他の状態のタスク（例えば、図３に示す待ち状態（ｗａｔｉｎｇ）や休止状態（ｓｕｓｐｅｎｄｅｄ）のタスク）が次に実行可能状態（図３ではｒｅａｄｙ）に遷移するまでの時間は、オペレーティングシステムが把握できるものとできないものとがある。例えば、定期的に発生するイベントや割込み等によって遷移するタスクのように遷移までの残り時間が予測可能なタスクや、遷移までの残り時間をオペレーティングシステムが管理しているタスクは、オペレーティングシステムが遷移までの残り時間を把握することができる。一方、例えば不定期な割込みなどを要因として遷移するタスクなどは遷移までの残り時間を把握することができない。
【００１７】
このうちオペレーティングシステムが残り時間を把握できないタスクに関しては、前述したように実行可能状態に遷移した時点で、低消費電力モードへの投入をパスする。一方、オペレーティングシステムが把握できるタスクに関しては、その把握した各タスクの遷移までの残り時間のうち最も少ない残り時間（最小残り時間）を加味した時間を投入時間として設定して低消費電力モードに投入する。したがって、実行可能状態に遷移するまでの残り時間が把握できるその他の状態タスクについて、これらのタスクが実行可能状態に遷移するのを妨げることなく低消費電力モードに投入することが可能となる。
【００１８】
例えば、請求項２に示すように低消費電力モードへの投入時間を最小残り時間よりも短い時間とすれば、その残り時間を待ってそのタスクをその他の状態から実行可能状態に遷移させることができる。よって、低消費電力モードへの投入時間が最小残り時間をオーバーすることがなくなり、低消費電力モードへの投入時間をさらに適切に設定することができる。したがって、低消費電力モードへの投入によるアプリケーションの実行への影響を抑えることができる。
【００１９】
そして、こうした低消費電力モードへの投入は、常に行うようにしてもよいが、請求項３に示すように所定の投入許可時間より長い場合に行うようにするとよい。この投入許可時間は、低消費電力モードを実現するハードウェアで既定される投入可能時間や実行するジョブの種類に応じて設定すればよい。また例えば、実際に複数の投入許可時間を設定して消費電力と処理能力を実測し、そのアプリケーションに最も適した時間を投入許可時間を求めて設定してもよい。
【００２０】
ところで、その他の状態としては、例えば、タスク生成中の状態や異常停止状態等を含めることができるが、一般的には請求項４に示すように条件待ち状態である。このような条件待ち状態としては、例えば、入出力待ち状態、仮想メモリ処理待ち状態、通信待ち状態、同期待ち状態、その他の条件待ち状態などを設けることができる。
【００２１】
条件待ち状態として例えばイベント待ち状態を持ち、次のイベント発生までの時間がオペレーティングシステムにおいて把握できる場合には、その把握した中で最も直近のイベント発生までの時間と所定の低消費電力モード投入可能時間とを比較して低消費電力モードに投入するか否かを判定することができる。また例えば、請求項５に示すように条件待ち状態のタスクに遷移条件としてアラームが設定されている場合には、そのアラームの設定時間と所定の低消費モード投入可能時間とを比較して低消費電力モードに投入可能か否かを判定するとよい。
【００２２】
このようにして低消費電力モードに投入すると、ＣＰＵのクロックが停止したり低下することにより、例えばオペレーティングシステムのソフトウェアで管理されているタイマ（カウンタ）が停止したり遅れたりする。このような場合には、請求項６に示すようにしてタイマの値を補正すればよい。このような補正を行うことで例えばアラームのカウント時間等がこのタイマに依存する場合であっても、正しいアラームの設定時間にタスクの状態を遷移させることが可能となる。
【００２３】
なお、補正は、例えば、低消費電力モードの投入時間満了によって低消費電力モードから通常動作モードに復帰した場合には投入時間をタイマに足し込むことで行えばよい。また例えば割込みによって低消費電力モードから通常動作モードに復帰した場合には、低消費電力モードに投入されていた時間は少なくとも投入時間以下の時間であるので、例えば投入時間の半分の時間をタイマに足し込むようにすればよい。
【００２４】
なお、低消費電力モードは、例えばスリープモードやスタンバイモードと呼ばれるものを含む。例えばＣＰＵのクロックを停止させるだけでなく、ＣＰＵの周辺装置のクロックを停止させるように構成してもよい。このようにすれば、さらに消費電力を低減できる。
【００２５】
そして、こうしたオペレーティングシステムは、ハードウェアで実現することも可能であるが、請求項７に示すようにコンピュータに実行させるためのプログラムとして構成するのが一般的である。このようなプログラムの場合、例えば、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読みとり可能な記録媒体に記録し、必要に応じてコンピュータにロードして起動することにより用いることができる。また、ネットワークを介してロードして起動することにより用いることもできる。
【００２６】
なお、請求項１〜６のいずれかに記載の内容は、それぞれＣＰＵの消費電力管理方法をオペレーティングシステムによって実現させる方法を示している。したがって、オペレーティングシステムに代えてＣＰＵの消費電力モード管理方法とすることもできる。このような消費電力モード管理方法によれば、上述した各請求項と同様の効果を得ることができ、オペレーティングシステムにおいて適切に消費電力モードを制御できる。
【００２７】
以上のようなオペレーティングシステムは、種々のコンピュータシステムに適用可能である。例えば請求項８に示すように車両用電子制御装置に適用することができる。このような車両用電子制御装置によれば、車両の制御処理に支障をきたすことなく消費電力を低減することが容易にできる。
【００２８】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００２９】
図１は、実施例としてのオペレーティングシステムを備えたボデーＥＣＵ１０を含むボデー系システム１００を示す図である。ボデー系システム１００は、車内ＬＡＮ５０に接続されたボデーＥＣＵ１０と、車内ＬＡＮ５０を介してボデーＥＣＵ１０と通信可能な通信対象ＥＣＵ２０を備える。ボデーＥＣＵ１０及び通信対象ＥＣＵ２０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等を備えたコンピュータシステムであり、それぞれのＩ／Ｏには入力装置３０、出力装置４０、車内ＬＡＮ５０等が接続されている。
【００３０】
通信対象ＥＣＵ２０は、例えば、Ｄ席ドアＥＣＵ２０ａやＰ席ドアＥＣＵ２０ｂやインパネＥＣＵ２０ｃ等であり、入力装置３０の状態を読み取ってパケットを生成し車内ＬＡＮ５０を介してボデーＥＣＵ１０へ送信する機能と、車内ＬＡＮ５０を介して入力されるボデーＥＣＵ１０からのパケットの制御情報に基づいて出力装置４０を制御する機能を備える。
【００３１】
Ｄ席ドアＥＣＵ２０ａはドライバ側のドアに設置されたＥＣＵであり、入力装置３０としてＤ席ドアコントロールスイッチ３０ａなどが接続されており、出力装置４０としてＤ席ドアロックモータ４０ａやＤ席パワーウインドウモータなどが接続されている。Ｐ席ドアＥＣＵ２０ｂは補助席側のドアに設置されたＥＣＵであり、入力装置３０としてＰ席ドアコントロールスイッチ３０ｂ等が接続され、出力装置４０としてＰ席ドアロックモータ４０ｂやＰ席パワーウインドウモータなどが接続されている。また、インパネＥＣＵは、インパネに設置されたＥＣＵであり、例えば、出力装置４０としてブザー４０ｃやランプ４０ｄ等が接続されている。
【００３２】
ボデーＥＣＵ１０は、通信対象ＥＣＵ２０から車内ＬＡＮ５０に送信されるパケットを受信し、受信したパケットの内容に応じて、各入力装置３０の状態を監視し、制御対象の通信対象ＥＣＵ２０への制御指示を含むパケットを生成して送信する制御処理等を行う。
【００３３】
こうした処理は、ＣＰＵ１２がボデーＥＣＵ１０のＲＯＭ１４に格納されたリアルタイムＯＳのプログラムを実行し、そのリアルタイムＯＳによる管理の下、ＲＯＭ１４に格納されたアプリケーションプログラムに基づくタスクを実行することによって、ＲＡＭ１６や車内ＬＡＮ５０の接続されたＩ／Ｏ１８を制御して行う。またリアルタイムＯＳは、消費電力の制御等の動作モードの管理など各種リソースの管理を行う。
【００３４】
ボデーＥＣＵ１０のＣＰＵ１２は、通常動作モードと低消費電力モード（スリープモード）の２つの動作モードを持つ。通常動作モードは、図２に示すように１６ＭＨｚ（４ＭＨｚ×４）のマシーンクロックに基づいて、ＲＯＭ１４に記憶されたプログラムを実行するモードである。一方、低消費電力モードはＣＰＵ１２へのクロックの供給を停止し、消費電力を低減させるモードである。低消費電力モードへの投入は、ＣＰＵ１２が、ＣＰＵ１２に備えたウェイクアップ用タイマに低消費電力モードへの投入時間であるスリープ時間を書き込んだ後に、スリープ命令を実行した場合に行われる。また低消費電力モードから通常動作モードへの復帰は、ウェイクアップ用タイマに書き込まれたスリープ時間が経過した場合と、スリープ状態で割込みがかかった場合に行われる。
【００３５】
アプリケーションプログラムのタスクとしては、例えば、通信対象ＥＣＵ２０から車内ＬＡＮ５０に送信されるパケットを受信し、受信したパケットの内容に応じた処理を行うタスクがある。また、例えば出力装置４０の制御が必要な場合に制御対象の通信対象ＥＣＵ２０への制御指示を含むパケットを生成して送信する制御処理などをを行う種々のタスクがある。
【００３６】
まず、リアルタイムＯＳの処理によるタスクの管理処理について説明し、次に動作モードの管理処理について説明する。
図３は、本実施例のリアルタイムＯＳによるタスクの状態遷移を示す図である。このリアルタイムＯＳは、タスクを、実行中の状態である実行状態（ｒｕｎｎｉｎｇ）と、実行待ち状態である実行可能状態（ｒｅａｄｙ）と、イベント待ち状態である待ち状態（ｗａｔｉｎｇ）と、休止状態である休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させて実行状態を管理する。
【００３７】
実行状態（ｒｕｎｎｉｎｇ）のタスクはＣＰＵが実行中のタスクであり、同時には最大で１つのタスクがこの状態をとる。なお実行状態以外の状態は、複数のタスクが同時にその状態をとりうる。
実行状態（ｒｕｎｎｉｎｇ）のタスクは、実行を終了する際にオペレーティングシステムに対してターミネートタスクシステムコールを発行する。オペレーティングシステムは実行状態（ｒｕｎｎｉｎｇ）のタスクからのターミネートタスクシステムコールを受けると、そのタスクの状態を休止状態（ｓｕｓｐｅｎｄｅｄ）に遷移させる。また、実行中のタスクが所定のイベントを待つ必要がある場合には、ウェイトイベントシステムコールを発行する。ウェイトイベントシステムコールの発行を受けたオペレーティングシステムは、そのタスクの状態を待ち状態（ｗａｔｉｎｇ）に遷移させる。
【００３８】
このようにして実行中のタスクを別の状態に遷移させると、実行状態（ｒｕｎｎｉｎｇ）のタスクが無くなるので、オペレーティングシステムは、実行可能状態（ｒｅａｄｙ）のタスクのうち優先度が最も高いタスクを実行状態（ｒｕｎｎｉｎｇ）に遷移させ、実行を開始する（ディスパッチする）。なお、実行状態（ｒｕｎｎｉｎｇ）のタスクより優先度の高いタスクが実行可能状態（ｒｅａｄｙ）になった際には、実行状態（ｒｕｎｎｉｎｇ）のタスクを実行可能状態（ｒｅａｄｙ）に遷移させ（プリエンプトさせ）、実行可能状態（ｒｅａｄｙ）の優先度の高いタスクを実行状態（ｒｕｎｎｉｎｇ）に遷移させて実行する。すなわちこのリアルタイムＯＳはプリエンプティブなマルチタスクＯＳである。
【００３９】
休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクは、休止解除条件が成立した場合に、実行可能状態に遷移させる。この休止解除条件はタスク毎に設定可能であり、▲１▼所定周期、▲２▼割込み、▲３▼チェーンタスク（連鎖実行）等がある。
「所定周期」は、アラームによって実現される。アラームは、設定された時間が経過した際にその経過を知らせるタイマであり、タスク毎に設定することができる。例えば、実行状態（ｒｕｎｎｉｎｇ）のタスクからのシステムコールによって、所定のタスクに対して１００ｍｓ後にアラームを発火させるといった設定を行うことができる。リアルタイムＯＳは、設定されたアラーム設定時間の経過を監視し、アラーム設定時間が経過した際に、そのタスクを休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
【００４０】
同様に、「割込み」は、割込み要因毎に遷移させるタスクを設定し、該当する割込み要因の発生時に遷移させるものである。
また、「チェーンタスク」は、連続して実行する必要のあるタスクの実行が完了した際に、次に実行すべきタスクを遷移させるものである。例えば、現在のドアロックの状態を得るためには、車内からのドアロックの状態をチェックした後、連続して車外のからのドアロックの状態をチェックする必要がある。このような場合には、例えば車内のロックの状態をチェックするタスクＡを実行したあと連続して、車外側のロックの状態をチェックするタスクＢを実行する必要がある。こうした場合、予めタスクＢのタスクＡに対するチェーンタスクを設定しておき、タスクＡの実行が完了した際にタスクＢを休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
【００４１】
一方、実行状態（ｒｕｎｎｉｎｇ）のタスクからセットイベントシステムコールが発行された場合には、そのシステムコールで指定されたイベントに対応するタスクを待ち状態（ｗａｔｉｎｇ）から実行可能状態（ｒｅａｄｙ）に遷移させる。
このようにタスクの状態は、実行中のタスクからのシステムコールの発行状況やイベントや割込みの発生状況等により随時変化する。例えば図４に示すように実行中タスク（実行状態（ｒｕｎｎｉｎｇ）のタスク）は、タスクＡ→タスクＢ→タスクｎのように連続して変化した後、しばらく時間を空けてタスクＢがディスパッチされている。この最初のタスクＡ→タスクＢ→タスクｎの遷移は、タスクＡが実行状態（ｒｕｎｎｉｎｇ）から休止状態（ｓｕｓｐｅｎｄｅｄ）あるいは待ち状態（ｗａｔｉｎｇ）に遷移した際にタスクＢが実行可能状態（ｒｅａｄｙ）にあり、すぐにリアルタイムＯＳのスケジューリングによってタスクＢが実行状態（ｒｕｎｎｉｎｇ）にディスパッチされたことを示している。一方、タスクｎが実行状態（ｒｕｎｎｉｎｇ）から他の状態に遷移した際には実行可能状態（ｒｅａｄｙ）のタスクはなく、その後、タスクＢが実行可能状態（ｒｅａｄｙ）に遷移した際に実行状態（ｒｕｎｎｉｎｇ）へディスパッチされたことを示している。
【００４２】
次に、こうしたタスクの状態を変化して管理するリアルタイムＯＳによる動作モード（通常動作モードと低消費電力モード）の管理処理について図５を参照して説明する。
図５に示すように、タスクスケジューリングを行った場合には（Ｓ１１０）、実行可能状態（ｒｅａｄｙ）及び実行状態（ｒｕｎｎｉｎｇ）にタスクがあるか否かを判定する（Ｓ１２０）。実行可能状態（ｒｅａｄｙ）または実行状態（ｒｕｎｎｉｎｇ）のいずれかにタスクが存在する場合には（Ｓ１２０：あり）、低消費電力モードへは移行はせずにＳ１１０のタスクスケジューリングに戻る。一方、実行可能状態（ｒｅａｄｙ）と実行状態（ｒｕｎｎｉｎｇ）の双方にタスクが存在しない場合には（Ｓ１２０：なし）、Ｓ１３０へ移行する。
【００４３】
Ｓ１３０では、休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクが実行可能状態（ｒｅａｄｙ）に移行するまでの時間が一定時間（所定の低消費電力モード投入可能時間に相当する）以上あるか否かを判定する。この時点で休止状態（ｓｕｓｐｅｎｄｅｄ）のタスクのうち実行可能状態（ｒｅａｄｙ）に移行する時期が把握できるのは、前述した▲１▼のアラームの発火によって休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移するタスクである。なお、これ以外の要因（前述▲２▼または▲３▼）の発生によって、休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）にタスクの状態が遷移した場合には、前述したＳ１２０の判定によって低消費電力モードへの移行は行われない。
【００４４】
アラームは、図６に示すように、タスク毎にカウンタ値が設定可能なカウンタから構成される。このカウンタの値は、リアルタイムＯＳのソフトウェアで構成されたシステムタイマの値に基づいてカウントする。例えばシステムタイマが５カウントされる毎にカウンタの値をそれぞれ１デクリメントし、最終的にカウンタの値が０になった時に、そのタスクの状態を休止状態（ｓｕｓｐｅｎｄｅｄ）から実行可能状態（ｒｅａｄｙ）に遷移させる指示を出す。このようにアラームのカウンタの値が０になることをアラームが発火する（ｅｘｐｉｒｅ）という。例えば図６のように、タスクＡにアラーム１、タスクＢにアラーム２、タスクＣにアラーム３がそれぞれ割り当てられ、アラーム１に１００、アラーム２に１０、アラーム３に１２０がセットされているとする。リアルタイムＯＳはアラームの単位時間が経過する毎にそれぞれのアラームの値を１づつデクリメントする。これらのアラームのうちで発火までの残り時間が最も少ないもの（すなわち現時点で次に発火する予定のアラーム）の残り時間と、投入を許可する最低の時間である投入許可時間とを比較し（図５のＳ１３０）、投入許可時間より残り時間の方が大きい場合に（Ｓ１３０：あり）、Ｓ１４０へ移行する。一方、残り時間が投入許可時間以下の場合には（Ｓ１３０：なし）、Ｓ１１０へ戻る。すなわち、直近のアラームの発火までに、投入許可時間以下の時間しかない場合には、低消費電力モードへの投入は行わない。例えば、現在のアラームの状態が図６のｔ１の状態である場合には、アラーム２の値「１０」がアラームのうちで発火までの時間が最も少ないもの（最小残り時間）に相当し、そのアラームの時間は、アラーム２のカウンタの値「１０」にアラームの単位時間を掛けたものになる。したがって、例えばシステムタイマが１ｍｓ毎にカウントしておりアラームの単位時間が５ｍｓであれば、次のアラーム発火までの残り時間は、５ｍｓ×１０＝５０ｍｓとなる。ここで、低消費電力モードへの投入許可時間を例えば３００ｍｓとすると、Ｓ１３０の判定では、次のアラームまでの残り時間＜投入許可時間となるので、「Ｓ１３０：なし」となりＳ１１０へ移行し、低消費電力モードへの投入は行われない。一方、時刻ｔ３では、アラーム１が次に発火するアラームとなり、発火までの残り時間は５ｍｓ×８９＝４４５ｍｓとなって、次のアラームまでの残り時間＞投入許可時間となるので、「Ｓ１３０：あり」となりＳ１４０へ移行する。なお、低消費電力モードへの投入許可時間は、ハードウェアの制限を加味して、実際に投入許可時間を何パターンか設定して、消費電力と処理能力を実測して最も適した時間に設定する。例えば、選択可能なスリープ時間が図２に示す４パターン（２ｍｓ・８ｍｓ・３２ｍｓ・２５６ｍｓ）であれば、これらの時間のいずれかを投入許可時間として決定すればよい。
【００４５】
Ｓ１４０では、最もアラームの発火までの残り時間の少ないアラームの持つ残り時間よりも短い時間であり、かつ、ウェイクアップタイマに設定可能な時間を投入時間として設定して、低消費電力モードへ投入する。例えば、前述したｔ３時点では、次のアラームの発火まで４４５ｍｓある。したがって４４５ｍｓより短い時間の間、ＣＰＵ１２を低消費電力モードに投入する。ＣＰＵ１２は、図２に示すように２ｍｓ・８ｍｓ・３２ｍｓ・２５６ｍｓのスリープ時間（投入時間）を選択可能であるので、例えば２５６ｍｓをスリープ時間としてウェイクアップタイマのレジスタに設定する。もちろん、スリープ時間が任意に設定できるウェイクアップタイマを備えたＣＰＵであれば、例えばスリープ時間を４４０ｍｓなどに設定してもよい。このようにウェイクアップタイマの設定を行い、スリープ命令を実行して、スリープモード（低消費電力モード）に投入する。
【００４６】
すると、ＣＰＵ１２へ供給されるマシーンクロックは停止し、ウェイクアップタイマがウェイクアップまでの時間をカウントする（図５のＳ１５０の処理に相当する。）。
設定されたスリープ時間に達するか、外部割込みがかかった場合には、ＣＰＵ１２へのクロックの供給が再開され、通常動作モードに復帰してＳ１６０へ移行する。
【００４７】
Ｓ１６０では、通常動作モードへの復帰要因が外部割込みの場合には（Ｓ１６０：外部割込み）Ｓ１８０へ移行して投入時間の半分の時間に相当する値をシステムクロックに足し込んで（Ｓ１８０）、Ｓ１１０のタスクスケジューリングに戻る。一方、通常動作モードへの復帰要因が低消費電力モードへのスリープ時間（投入時間）満了の場合は（Ｓ１６０：満了）、低消費電力モードへの投入時間に相当する値をシステムクロックに足し込んで（Ｓ１７０）、Ｓ１１０へ戻る。これは基準となるシステムタイマが低消費電力モードの間停止してしまうため、補正するものである。このような補正処理により、アラームのカウンタの値もほぼ正しい値となり、処理を正常に継続することができる。
【００４８】
このような動作モードの管理処理によって、実行状態（ｒｕｎｎｉｎｇ）と実行可能状態（ｒｅａｄｙ）のタスクが存在しない状態で、かつ、アラームの発火までの残り時間が最も短いものについてその残り時間が所定の低消費電力モード投入可能時間より長い場合にＣＰＵをその残り時間より短い時間の間、低消費電力モードに投入することができる。したがって、実行状態（ｒｕｎｎｉｎｇ）や実行可能状態（ｒｅａｄｙ）のタスクやアラームの設定されているタスクの実行を妨げることなく、ボデーＥＣＵ１０の消費電力を低減することができる。また、タスクは動作モードを意識する必要がないため、アプリケーションプログラムの作成が容易にできる。
［別実施例］
（１）上記実施例においては、アラームの値は、アラームの単位時間が経過する毎にデクリメントしその値が０になった際に発火することとしたが、アラームの発火時間をシステムタイマの値の増分や絶対時間で設定するようにしてもよい。例えば、１ｍｓ毎にカウントされるシステムタイマの値が、図７（ａ）に示すように１０３００の時に発火するといった具合に設定してもよい。また、３００毎に発火するというように設定できるようにしてもよい。この場合も、図５のＳ１７０及びＳ１８０と同様の処理によって、低消費電力モードから復帰した際にシステムクロックに相当する時間を足し込む。すなわち、スリープ時間が１３０ｍｓであればスリープから復帰した際に１３０をシステムタイマに足し込む。こうすることで、図７（ｂ）に示すようなスリープによるシステムタイマの停止を原因とするアラームの発火のディレイ（遅延）を起こすことなく、図７（ｃ）に示すように正しい時間にアラームを発火させることができる。
（２）上記実施例においては、図３に示すように４つの状態でタスクを管理するオペレーティングシステムについて説明したが、もちろんこれに限定されない。例えば、待ち状態（ｗａｔｉｎｇ）を除く３つの状態をとるオペレーティングシステムや、さらに多くの状態をとるオペレーティングシステムであっても適用できる。また上記実施例では、プリエンプティブなマルチタスクＯＳとして説明したが、もちろんノンプリエンプティブなＯＳであっても適用できる。
（３）上記実施例においては、図１に示す車両のボデー系システム１００におけるボデーＥＣＵ１０のオペレーティングシステムとして説明したが、各通信対象ＥＣＵ２０のオペレーティングシステムとしても適用できる。また、その他の種々の車両用制御装置やその他の各種装置にも適用できる。特に、電池（バッテリー）駆動型の機器など、低消費電力が要求される機器のオペレーティングシステムとして処理能力と消費電力のバランスに優れた電力制御を実現することができる。
【図面の簡単な説明】
【図１】実施例のオペレーティングシステムを備えたボデーＥＣＵを含むボデー系システムの構成を示すブロック図である。
【図２】通常動作モードと低消費電力モードを実現する構成を示す説明図である。
【図３】実施例のオペレーティングシステムの管理するタスクの状態遷移に関する説明図である。
【図４】タスクの実行状態と動作モードの例を示す説明図である。
【図５】実施例のオペレーティングシステムにおける動作モードの管理処理を示すフローチャートである。
【図６】アラームの例を示す説明図である。
【図７】別実施例のアラームと実行状態を示す説明図である。
【図８】従来のスケジューラによる処理方法を示す説明図である。
【図９】図８の従来の処理方法における動作モードの切替方法を説明する図である。
【符号の説明】
１００…ボデー系システム
１０…ボデーＥＣＵ
２０…通信対象ＥＣＵ
２０ａ…Ｄ席ドアＥＣＵ
２０ｂ…Ｐ席ドアＥＣＵ
３０…入力装置
３０ａ…Ｄ席ドアコントロールスイッチ
３０ｂ…Ｐ席ドアコントロールスイッチ
４０…出力装置
４０ａ…Ｄ席ドアロックモータ
４０ｂ…Ｐ席ドアロックモータ
４０ｃ…ブザー
５０…車内ＬＡＮ
Claims (8)
- タスクの状態を管理する機能を備えたオペレーティングシステムにおいて、
前記タスクの状態として実行状態と、実行可能状態と、前記実行状態及び前記実行可能状態以外の状態であるその他の状態とを備え、
前記実行状態のタスクと前記実行可能状態のタスクが存在しない場合であって、前記その他の状態のタスクの中に次に前記実行可能状態に遷移するまでの残り時間を把握可能なタスクが存在する場合には、その残り時間のうち最小のものである最小残り時間を加味した時間を投入時間として設定してＣＰＵを低消費電力モードに投入する機能を備えること
を特徴とするオペレーティングシステム。 - 請求項１に記載のオペレーティングシステムにおいて、
前記投入時間は、前記最小残り時間よりも短い時間とすること
を特徴とするオペレーティングシステム。 - 請求項１または２に記載のオペレーティングシステムにおいて、
前記低消費電力モードへの投入は、前記最小残り時間が低消費電力モードへの所定の投入許可時間より長い場合に行うこと
を特徴とするオペレーティングシステム。 - 請求項１〜３のいずれかに記載のオペレーティングシステムにおいて、
前記その他の状態は条件待ち状態であること
を特徴とするオペレーティングシステム。 - 請求項４に記載のオペレーティングシステムにおいて、
前記条件待ちの条件として前記タスクに設定したアラームを用い、
前記残り時間として、前記アラームの設定時間を利用することを
を特徴とするオペレーティングシステム。 - 請求項１〜５のいずれかに記載のオペレーティングシステムにおいて、
前記低消費電力モードから通常動作モードに復帰した場合には、前記低消費電力モードに投入した際に停止していたタイマの値を、前記投入時間を用いて補正すること
を特徴とするオペレーティングシステム。 - 請求項１〜６のいずれかに記載のオペレーティングシステムとしての機能をコンピュータに実行させるためのプログラム。
- 請求項１〜７のいずれかに記載のオペレーティングシステムを備えた車両用電子制御装置。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001212487A JP3610930B2 (ja) | 2001-07-12 | 2001-07-12 | オペレーティングシステム、プログラム、車両用電子制御装置 |
| US10/162,566 US7386853B2 (en) | 2001-07-12 | 2002-06-06 | Multitasking operating system capable of reducing power consumption and vehicle electronic control unit using same |
| DE10231668A DE10231668B4 (de) | 2001-07-12 | 2002-07-12 | Multitaskingbetriebssystem zur Verringerung des Stromverbrauchs und elektronische Steuerung im Fahrzeug, die selbiges benutzt |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001212487A JP3610930B2 (ja) | 2001-07-12 | 2001-07-12 | オペレーティングシステム、プログラム、車両用電子制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003029886A JP2003029886A (ja) | 2003-01-31 |
| JP3610930B2 true JP3610930B2 (ja) | 2005-01-19 |
Family
ID=19047640
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001212487A Expired - Fee Related JP3610930B2 (ja) | 2001-07-12 | 2001-07-12 | オペレーティングシステム、プログラム、車両用電子制御装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7386853B2 (ja) |
| JP (1) | JP3610930B2 (ja) |
| DE (1) | DE10231668B4 (ja) |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10228064B4 (de) * | 2002-06-17 | 2005-08-11 | Robert Bosch Gmbh | Verfahren, Echtzeit-Rechengerät und Initialisierungs-Programm zur Teilinitialisierung eines auf dem Rechengerät ablauffähigen Computerprogramms |
| JP2005005909A (ja) * | 2003-06-10 | 2005-01-06 | Sony Ericsson Mobilecommunications Japan Inc | 競合管理プログラム，競合管理プログラムが記憶された記憶媒体，競合管理方法及び電子機器 |
| US20050050310A1 (en) | 2003-07-15 | 2005-03-03 | Bailey Daniel W. | Method, system, and apparatus for improving multi-core processor performance |
| JP4433782B2 (ja) * | 2003-12-17 | 2010-03-17 | 株式会社日立製作所 | 情報処理装置及びオペレーティングシステム |
| US20050228967A1 (en) * | 2004-03-16 | 2005-10-13 | Sony Computer Entertainment Inc. | Methods and apparatus for reducing power dissipation in a multi-processor system |
| US8224639B2 (en) | 2004-03-29 | 2012-07-17 | Sony Computer Entertainment Inc. | Methods and apparatus for achieving thermal management using processing task scheduling |
| JP4692318B2 (ja) * | 2005-04-20 | 2011-06-01 | 株式会社デンソー | 電子制御装置 |
| JP4798445B2 (ja) * | 2006-08-14 | 2011-10-19 | 富士ゼロックス株式会社 | 省電力制御方法、画像形成装置およびプログラム |
| JP2008102830A (ja) * | 2006-10-20 | 2008-05-01 | Denso Corp | マイクロコンピュータ、プログラム及び車両用電子制御装置 |
| JP2008107914A (ja) * | 2006-10-23 | 2008-05-08 | Denso Corp | マイクロコンピュータ、プログラム及び車両用電子制御装置 |
| TWI353513B (en) * | 2007-11-02 | 2011-12-01 | Htc Corp | Main computer for vehicle and power management met |
| JP5515273B2 (ja) * | 2007-12-06 | 2014-06-11 | ミツミ電機株式会社 | 半導体集積回路装置及び電池パック |
| JP2009220459A (ja) * | 2008-03-17 | 2009-10-01 | Ricoh Co Ltd | 機器の制御装置、画像形成装置、プログラム |
| JP5294924B2 (ja) * | 2009-03-02 | 2013-09-18 | キヤノン株式会社 | 情報処理装置及びその制御方法、並びに、プログラム |
| JP5363379B2 (ja) | 2009-05-20 | 2013-12-11 | ルネサスエレクトロニクス株式会社 | 通信システム |
| JP4644747B1 (ja) * | 2009-11-02 | 2011-03-02 | パナソニック株式会社 | 情報処理装置、制御方法および制御プログラム |
| JP4965638B2 (ja) * | 2009-12-25 | 2012-07-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | タスクの切り換えを制御するシステムおよび方法 |
| US8370665B2 (en) * | 2010-01-11 | 2013-02-05 | Qualcomm Incorporated | System and method of sampling data within a central processing unit |
| TW201224754A (en) * | 2010-12-08 | 2012-06-16 | Quanta Comp Inc | Portable electronic apparatus and control method thereof |
| US20120210150A1 (en) * | 2011-02-10 | 2012-08-16 | Alcatel-Lucent Usa Inc. | Method And Apparatus Of Smart Power Management For Mobile Communication Terminals |
| JP5284401B2 (ja) * | 2011-03-24 | 2013-09-11 | 株式会社東芝 | 動作切替装置およびプログラム |
| CN103440171B (zh) * | 2013-08-25 | 2016-08-03 | 浙江大学 | 一种构件化硬件实时操作***的实现方法 |
| JP6318751B2 (ja) * | 2014-03-20 | 2018-05-09 | 富士通株式会社 | 情報処理装置、アクション切替方法、及びアクション切替プログラム |
| CN105117897B (zh) * | 2015-08-19 | 2019-08-16 | 小米科技有限责任公司 | 关机提醒方法及装置 |
| US9465664B1 (en) | 2015-09-09 | 2016-10-11 | Honeywell International Inc. | Systems and methods for allocation of environmentally regulated slack |
| CN105320561B (zh) * | 2015-11-09 | 2019-03-08 | 深圳市万普拉斯科技有限公司 | 任务管理方法和*** |
| CN105320570B (zh) * | 2015-11-09 | 2019-01-29 | 深圳市万普拉斯科技有限公司 | 资源管理方法和*** |
| CN111198607B (zh) * | 2018-11-20 | 2022-11-25 | 浙江宇视科技有限公司 | 电子设备功耗管理方法与装置 |
| US11614792B2 (en) | 2020-11-20 | 2023-03-28 | Ford Global Technologies, Llc | Coordinating vehicle controller shutdown |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS62150416A (ja) | 1985-12-24 | 1987-07-04 | Nec Corp | 低消費電力状態への移行方式 |
| JPH04257010A (ja) | 1991-02-08 | 1992-09-11 | Nec Corp | システムクロック切り替え機構 |
| JPH0776894B2 (ja) | 1991-02-25 | 1995-08-16 | インターナショナル・ビジネス・マシーンズ・コーポレイション | プロセッサ用クロック信号の制御方法及び情報処理システム |
| JPH0594313A (ja) | 1991-10-01 | 1993-04-16 | Mitsubishi Electric Corp | タイマ管理方式 |
| JP2949998B2 (ja) * | 1992-02-21 | 1999-09-20 | 日産自動車株式会社 | 通信装置 |
| JPH05282214A (ja) | 1992-04-03 | 1993-10-29 | Hitachi Ltd | システムリスタート方法及び装置 |
| JP3243849B2 (ja) | 1992-08-18 | 2002-01-07 | 富士通株式会社 | タスクスケジューリング装置 |
| US5511203A (en) * | 1994-02-02 | 1996-04-23 | Advanced Micro Devices | Power management system distinguishing between primary and secondary system activity |
| US5560021A (en) * | 1994-04-04 | 1996-09-24 | Vook; Frederick W. | Power management and packet delivery method for use in a wireless local area network (LAN) |
| JPH0876874A (ja) | 1994-09-06 | 1996-03-22 | Hitachi Ltd | 中央処理装置のクロック制御装置およびクロック制御方法 |
| US5621250A (en) * | 1995-07-31 | 1997-04-15 | Ford Motor Company | Wake-up interface and method for awakening an automotive electronics module |
| JPH09128088A (ja) | 1995-10-26 | 1997-05-16 | Hitachi Ltd | パーソナルコンピュータ |
| JP3283754B2 (ja) | 1996-03-04 | 2002-05-20 | 株式会社リコー | 電源制御装置およびそれを備えたファクシミリ装置 |
| CN1159021A (zh) | 1996-03-06 | 1997-09-10 | 三菱电机株式会社 | ***时钟确定装置 |
| JPH10143274A (ja) | 1996-11-11 | 1998-05-29 | Casio Comput Co Ltd | Ｃｐｕのクロック制御装置 |
| JPH10222402A (ja) * | 1997-02-12 | 1998-08-21 | Nissan Motor Co Ltd | 車両用制御装置 |
| JPH10341187A (ja) | 1997-06-09 | 1998-12-22 | Nippon Denki Ido Tsushin Kk | 携帯電話機 |
| US6260150B1 (en) * | 1998-03-10 | 2001-07-10 | Agere Systems Guardian Corp. | Foreground and background context controller setting processor to power saving mode when all contexts are inactive |
| JP3819166B2 (ja) * | 1998-11-27 | 2006-09-06 | ヒタチグローバルストレージテクノロジーズネザーランドビーブイ | 消費エネルギー低減方法 |
| JP2001109538A (ja) | 1999-10-08 | 2001-04-20 | Nec Eng Ltd | パワーマネジメントシステム |
| GB2360670B (en) * | 2000-03-22 | 2004-02-04 | At & T Lab Cambridge Ltd | Power management system |
| US6816977B2 (en) * | 2001-12-03 | 2004-11-09 | Hewlett-Packard Development Company, L.P. | Power reduction in computing devices using micro-sleep intervals |
-
2001
- 2001-07-12 JP JP2001212487A patent/JP3610930B2/ja not_active Expired - Fee Related
-
2002
- 2002-06-06 US US10/162,566 patent/US7386853B2/en not_active Expired - Fee Related
- 2002-07-12 DE DE10231668A patent/DE10231668B4/de not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003029886A (ja) | 2003-01-31 |
| DE10231668B4 (de) | 2009-04-09 |
| DE10231668A1 (de) | 2003-01-30 |
| US7386853B2 (en) | 2008-06-10 |
| US20030014467A1 (en) | 2003-01-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3610930B2 (ja) | オペレーティングシステム、プログラム、車両用電子制御装置 | |
| EP1677175B1 (en) | Dynamic power management in system on chips (SOC) | |
| US7007180B2 (en) | System and method for switching a computer system to a first or second power saving mode based on whether or not there exists a timer-expiration-waiting event in an event queue | |
| EP1868095B1 (en) | Program-execution monitoring method, system, and program | |
| JP5491622B2 (ja) | 電力管理型ロック最適化 | |
| TWI437434B (zh) | 直接記憶體存取控制器 | |
| EP0582391B1 (en) | Clock generator with power savings capability | |
| JPWO2005106623A1 (ja) | Ｃｐｕクロック制御装置、ｃｐｕクロック制御方法、ｃｐｕクロック制御プログラム、記録媒体、及び伝送媒体 | |
| JPH04278612A (ja) | プロセッサ用クロック信号の制御方法及び情報処理システム | |
| US7120911B1 (en) | Processor power-saving control method, storage medium, and processor power-saving control device | |
| WO2013116751A1 (en) | Dynamic power management in real-time systems | |
| US20230113657A1 (en) | Preemptive wakeup circuit for wakeup from low power modes | |
| KR20140127341A (ko) | 휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템 | |
| JP2008107914A (ja) | マイクロコンピュータ、プログラム及び車両用電子制御装置 | |
| JP5324340B2 (ja) | マイクロコンピュータ | |
| US20050160425A1 (en) | Limitation of the response time of a software process | |
| CN111813531B (zh) | 一种操作***时钟调度方法及*** | |
| JP4147087B2 (ja) | 情報処理通信装置 | |
| JPWO2018211865A1 (ja) | 車両制御装置 | |
| EP3129876B1 (en) | Scheduling of global voltage/frequency scaling switches among asynchronous dataflow dependent processors | |
| US20220382581A1 (en) | Method, arrangement, and computer program product for organizing the excitation of processing paths for testing a microelectric circuit | |
| JPH09237132A (ja) | コンピュータシステム及びそのクロック制御方法 | |
| JP3711849B2 (ja) | マイクロコンピュータ | |
| JPH10177489A (ja) | タスクのスケジュール方法 | |
| JP2003337634A (ja) | コンピュータ装置及びプロセッサ制御方法及びプロセッサ制御方法をコンピュータに実行させるためのプログラム及びプロセッサ制御方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040928 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041011 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3610930 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101029 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111029 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121029 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121029 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131029 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |