JP6209042B2 - データ処理装置 - Google Patents

Description

本発明は、データ処理装置に関し、特に、低消費電力が要求されるデータ処理装置に適用して有効な技術に関する。

携帯端末やサーバー等のデータ処理装置は、所望の機能を実現するためにマイクロコントローラやメモリ、センサ、電源ＩＣ等の複数の電子部品が相互に接続されることによって構成されている。このようなデータ処理システムにおいて、例えばマイクロコントローラは、システム全体の制御を行いつつ、センサや電源ＩＣ等からの割り込み要求に応じて割り込み処理を適宜実行する。例えば特許文献１には、情報用タスクの割り込みが発生しても、周期的な制御用タスクを優先的に実行するようにスケジューリングするマイクロコントローラが開示されている。

ところで、近年、データ処理システムの省電力化の要求が高まっている。データ処理システムの省電力化を実現するためには、データ処理システムを構成する個々の半導体集積回路の消費電力を抑えることが不可欠である。半導体集積回路の省電力化の技術として、近年、パワーゲーティングと呼ばれる手法が注目されている。パワーゲーティングは、半導体集積回路内の動作しない回路ブロックへの電源供給を遮断することで当該回路ブロックのリーク電流を抑え、半導体集積回路全体の消費電力を削減する手法である。例えば、非特許文献１には、携帯端末等に適用されるモバイル用ＳＯＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ）において、携帯端末の動作モードに応じて動作しない回路ブロック（ＩＰ等）への電源供給を遮断する技術が開示されている。また、非特許文献２には、命令セットレベルやキャッシュミス動作等を条件分岐として利用することで、ＣＰＵ内部の演算器レベルで電源遮断を行う技術が開示されている。

特開２００９−１７５９７１号公報

Ｔ． Ｈａｔｔｏｒｉ， ｅｔ．ａｌ．， "Ｈｉｅｒａｒｃｈｉｃａｌ ｐｏｗｅｒ ｄｉｓｔｒｉｂｕｔｉｏｎ ａｎｄ ｐｏｗｅｒ ｍａｎａｇｅｍｅｎｔ ｓｃｈｅｍｅ ｆｏｒ ａ ｓｉｎｇｌｅ ｃｈｉｐ ｍｏｂｉｌｅ ｐｒｏｃｅｓｓｏｒ"， Ｐｒｏｃ． ｏｆ ＤＡＣ， ｐｐ．２９２−２９５， ２００６ Ｄ．Ｉｋｅｂｕｃｈｉ ａｎｄ ｅｔ．ａｌ．， "Ｇｅｙｓｅｒ−１： Ａ ｍｉｐｓ ｒ３０００ ｃｐｕ ｃｏｒｅ ｗｉｔｈ ｆｉｎｅ ｇｒａｉｎ ｒｕｎｔｉｍｅ ｐｏｗｅｒ ｇａｔｉｎｇ，" ＩＥＥＥ Ａｓｉａｎ Ｓｏｌｉｄ−Ｓｔａｔｅ Ｃｉｒｃｕｉｔｓ Ｃｏｎｆｅｒｅｎｃｅ Ｎｏｖｅｍｂｅｒ １６−１８，２００９，Ｔａｉｐｅｉ，Ｔａｉｗａｎ

本願発明者は、複数の電子部品から構成されるデータ処理システムにおいて、電子部品毎の電源遮断（パワーゲーティング）を行うことによりシステム全体の消費電力を削減することについて検討した。検討の結果、以下の問題があることが明らかとされた。

一般に、パワーゲーティングにおいて、電源供給状態から電源遮断状態への遷移時及び電源遮断状態から電源供給状態への遷移時に、エネルギー消費（オーバーヘッド）が生じることが知られている。電源遮断等のスタンバイモードに遷移することによるオーバーヘッドよりもスタンバイモードに遷移することによる消費電力の削減量が大きくなる臨界点となる時間を損益分岐時間（ＢＥＴ：Ｂｒｅａｋ−ｅｖｅｎ ｔｉｍｅ）と言い、スタンバイモードの期間が損益分岐時間ＢＥＴよりも長い場合に、消費電力の削減効果が得られる。したがって、上述の非特許文献１に開示されたモバイル用ＳｏＣのように、損益分岐時間ＢＥＴを考慮せずに、単に、動作していない電子部品の電源遮断を行うような手法ではアプリケーションに依存し、汎用的な使用方法では十分な電力削減効果が得られない場合も多く、電源供給と遮断の切り替え頻度が高い場合には、かえって消費電力の増加を招く虞がある。なお、非特許文献２の手法は、損益分岐時間ＢＥＴを考慮してＣＰＵ内部の各演算器の電源遮断の時間粒度を変更するものではあるが、命令セットレベルやキャッシュミス動作等を条件分岐とした複雑な制御によってＣＰＵ内部の各演算器のパワーゲーティングを行うための技術であり、当該文献の技術内容を上記のデータ処理システムにそのまま適用することはできない。

このような課題を解決するための手段等を以下に説明するが、その他の課題と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される実施の形態のうち代表的なものの概要を簡単に説明すれば下記のとおりである。

すなわち、本データ処理装置は、少なくとも１つのスタンバイモードを有する複数のハードウェアリソースと、所定の前記ハードウェアリソースを用いて実現されるタスクの実行と前記ハードウェアリソースの動作状態の制御を行うための制御部と、前記制御部からの指示に応じて、各ハードウェアリソースに対する電源の供給を制御する電源部とを有する。前記制御部は、前記タスクを実行するタイミングを決定するための情報に基づいて前記タスクの実行予定時刻のスケジューリングを行うとともに、前記スケジューリングの結果に基づいて前記ハードウェアリソースが次の前記タスクの実行に利用されるまでの待機時間を算出する。前記制御部は、算出した前記待機時間と予め設定された当該ハードウェアリソースの前記スタンバイモードによる損益分岐時間とを比較することによって、当該ハードウェアリソースをスタンバイモードに遷移させるか否かを、前記ハードウェアリソース毎に決定する。

本願において開示される実施の形態のうち代表的なものによって得られる効果を簡単に説明すれば下記のとおりである。

すなわち、本データ処理装置によれば、消費電力を削減することができる。

本願の一実施の形態に係るデータ処理装置を示す図である。 実施の形態１に係るデータ処理装置の構成を例示する図である。 各ハードウェアリソースの動作モードを例示する図である。 制御部１の内部構成を例示する図である。 実施の形態１に係るタスク管理情報の一例を示す図である。 実施の形態１に係るハードウェア情報の一例を示す図である。 実施の形態１に係るキューリストの一例を示す。 実施の形態１に係るタスクのスケジューリングと動作モードの決定の流れの一例を示す図である。 実施の形態１に係るデータ処理装置におけるキューリストの更新の様子を示す図である。 ＭＣＵ３の動作モードを変更するときの制御部１０とＭＵＣ３間の通信の流れを示す図である。 実施の形態１に係るデータ処理装置におけるタスクのスケジューリング結果とＭＣＵ３の動作モードの遷移状態の一例を示す図である。 実施の形態２に係るタスク管理情報の一例を示す図である。 実施の形態２に係るキューリストの一例を示す図である。 実施の形態２に係るタスクのスケジューリングと動作モードの決定の流れの一例を示す図である。 実施の形態２に係るデータ処理装置におけるキューリストの更新の様子を示す図である。 実施の形態２に係るデータ処理装置におけるタスクのスケジューリング結果とＭＣＵ３の動作モードの遷移状態の一例を示す図である。 実施の形態３に係るデータ処理装置におけるレギュレータ回路２０＿ｎの内部構成を例示する図である。 レギュレータ回路における差動増幅器ＤＡＭＰの差動増幅段の回路構成を例示する図である。 実施の形態４に係るデータ処理装置を例示する図である。 実施の形態４に係るハードウェア情報を例示する図である。

１．実施の形態の概要
先ず、本願において開示される代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面中の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。

〔１〕（タスク管理情報に基づいて算出したハードウェアリソースの待機時間と損益分岐時間とを比較することにより、各ハードウェアリソースのスタンバイモードへの遷移を決定するデータ処理装置）
本願の代表的な実施の形態に係るデータ処理装置は、図１に示されるように、少なくとも１つのスタンバイモードを有する複数のハードウェアリソース（３、４＿１、４＿２）と、所定の前記ハードウェアリソースを用いて実現されるタスクの実行と前記ハードウェアリソースの動作状態の制御を行うための制御部（１）を有する。前記データ処理装置は更に、前記制御部からの指示に応じて、各ハードウェアリソースに対する電源（ＶＩＮ＿１〜ＶＩＮ＿ｎ）の供給を制御する電源部（２）を有する。前記制御部は、前記タスクを実行するタイミングを決定するための情報（ＴＭＩ、ＴＭＩＡ）に基づいて前記タスクの実行予定時刻のスケジューリングを行うとともに、前記スケジューリングの結果に基づいて前記ハードウェアリソースが次の前記タスクの実行に利用されるまでの待機時間（Ｔｗ）を算出する。更に、前記制御部は、算出した前記待機時間と予め設定された当該ハードウェアリソースの前記スタンバイモードによる損益分岐時間（Ｔｂｅ１〜Ｔｂｅ５）とを比較することによって、当該ハードウェアリソースをスタンバイモードに遷移させるか否かを、前記ハードウェアリソース毎に決定する。

これによれば、消費電力の削減効果が得られる場合に、スタンバイモードに移行するように夫々のハードウェアリソースが制御することができるので、従来のように、ハードウェアリソースが動作不要な状態になったことを条件としてスタンバイモードに移行させるような単純な制御手法に比べて、データ処理装置全体の消費電力を効果的に削減することができる。

〔２〕（タスク管理情報に基づくスケジューリング及び待機時間の算出）
項１のデータ処理装置において、前記タスクを実行するタイミングを決定するための情報は、前記タスクを実行する周期（Ｔｃ）と、前記タスクの実行時間（Ｔｏｎ）と、前記タスクの実行に用いられる前記ハードウェアリソースを指示するリソース情報（Ｒｓ）と、を含む。前記制御部は、前記タスクを実行する周期に基づいてタスクの実行予定時刻をスケジューリングする。前記制御部は更に、前記リソース情報で指示された所定のハードウェアリソースを使用する所定のタスクの実行完了時刻と前記所定のハードウェアリソースを使用し前記所定のタスクの次に実行されるタスクの実行予定時刻との差分に基づいて前記所定のハードウェアリソースの前記待機時間を算出する。前記実行完了時刻は、前記所定のハードウェアリソースを使用するタスクの実行開始時刻に前記タスクの実行時間を加算することで算出される。

これによれば、タスクの実行予定時刻をスケジューリングすることが容易となるとともに、ハードウェアリソース毎の待機時間を容易に算出することが可能となる。

〔３〕（待機時間とＢＥＴの比較結果に基づくスタンバイモードの選択）
項２のデータ処理装置は、前記複数のハードウェアリソースとして、電源の供給が遮断されない第１スタンバイモード（ＳＴＢ１、ＳＴＢ２）と電源の供給が遮断される第２スタンバイモード（ＳＴＢ３）とを有するデバイスを含む。前記デバイスの前記損益分岐時間として、前記第１スタンバイモードによる第１損益分岐時間（Ｔｂｅ１，Ｔｂｅ２）と前記第２スタンバイモードによる第２損益分岐時間（Ｔｂｅ３）とを含む。前記第２損益分岐時間は、前記第１損益分岐時間よりも大きくされる。前記制御部は、前記デバイスをスタンバイモードに遷移させるとき、前記算出した前記デバイスの待機時間（Ｔｗ）が前記第１損益分岐時間より大きく前記第２損益分岐時間より小さい場合に、前記デバイスを前記第１スタンバイモードに遷移させる。一方、前記算出した前記デバイスの待機時間が前記第２損益分岐時間より大きい場合に、前記制御部は、前記デバイスを前記第２スタンバイモードに遷移させる。

これによれば、デバイスの待機時間に応じて最適なスタンバイモードを選択するから、当該デバイスの消費電力を効果的に削減することができ、データ処理システム全体の更なる省電力化に資する。

〔４〕（マイクロコントローラ）
項３のデータ処理装置において、前記デバイスは、マイクロコントローラである。

〔５〕（スケジューリングされたタスクを待機時間が長くなるようにリスケジュールする）
項２乃至４の何れかのデータ処理装置において、前記制御部は、前記スケジューリングされた所要のタスクの実行開始予定時刻と、その次に実行予定のタスクの実行開始予定時刻との時間間隔が短くなるように、前記所要のタスクの実行予定時刻を所定の時間範囲内で変更可能にされる。

これによれば、タスクとタスクの実行間隔が短くなるようにスケジューリング結果が見直されるから、ハードウェアリソースの待機時間をより長くすることができる。これにより、各ハードウェアリソースの状態遷移回数を減らすことで遷移に伴うエネルギーオーバーヘッドを削減し、さらにスタンバイ状態にしておくことができる期間が長くなるので、消費電力の更なる削減が期待できる。特に、電源を遮断するスタンバイモードと電源を遮断しないスタンバイモードを有するデバイス（マイコン等）を含むデータ処理装置の場合、待機時間が長くなることで電源が遮断されるスタンバイモードに遷移する確率が高くなるので、更なる電力の削減が期待できる。

〔６〕（リスケジューリングの詳細）
項５のデータ処理装置において、前記タスクを実行するタイミングを決定するための情報は、前記タスクを実行すべき周期に対してずらすことが可能な時間を示す猶予時間（Ｔｅｘ）の情報を、更に含む。前記制御部は、スケジューリングされた前記所要のタスクの実行開始予定時刻を基点として前記猶予時間の範囲内に、前記その次に実行予定のタスクの実行がスケジューリングされている場合に、前記所要のタスクに連続して前記その次に実行予定のタスクが実行されるように、前記所要のタスクの実行予定時刻を変更する。

これによれば、周期的なタスクの実行を維持しつつ、ハードウェアリソースの待機時間を長くすることが可能となる。

〔７〕（温度毎の損益分岐時間ＢＥＴ）
項２乃至６の何れかのデータ処理装置において、前記スタンバイモードによる損益分岐時間が温度情報に対応して複数（ＨＷＩ＿ＴＬ、ＨＷＩ＿ＴＭ、ＨＷＩ＿ＴＨ）設定される。前記制御部は、入力された温度情報に基づいて何れか一つの前記損益分岐時間を選択し、選択した前記損益分岐時間を用いて、前記ハードウェアリソースをスタンバイモードに遷移させるか否かの決定を行う。

一般に、電源遮断による損益分岐時間は温度によって変化することが知られている。そこで、本データ処理装置のように温度に応じて損益分岐時間を変更することで、より正確に最適なスタンバイモードを選択することができ、温度によらず、データ処理装置の消費電力を効果的に削減することが可能となる。

〔８〕（ＬＤＯの回路電流）
項３乃至７の何れかのデータ処理装置において、前記電源部は、前記ハードウェアリソースに電源電圧を供給するためのレギュレータ回路（２０＿１〜２０＿ｎ）を夫々のハードウェアリソースに対応させて複数有する。前記制御部は、前記ハードウェアリソースをスタンバイモードに遷移させるとき、当該ハードウェアリソースに対応する前記レギュレータ回路の回路電流（ＩＢＳ）が小さくなるように制御する。

これによれば、データ処理装置全体の消費電力を更に削減することが可能となる。

〔９〕（スタンバイモード毎にＬＤＯの回路電流を変化させる）
項８のデータ処理装置において、前記制御部は、前記デバイスを前記第２スタンバイモードに遷移させる場合に、前記デバイスに対応する前記レギュレータ回路の動作電流を遮断するように制御する。一方、前記制御部は、前記マイクロコントローラを前記第１スタンバイモードに遷移させる場合に、前記デバイスに対応する前記レギュレータ回路の動作電流が通常時よりも小さくなるように制御する。

これによれば、マイクロコントローラに電源を供給するレギュレータ回路に要求される応答性を担保しつつ、消費電力を効果的に抑えることができる。

〔１０〕（タスクの実行間隔を変更する）
項４乃至９の何れかのデータ処理装置において、前記タスクとして、前記マイクロコントローラが外部から周期的にデータを受信する第１タスク（タスクＡ又はＢ）を含む。前記マイクロコントローラは、前記第１タスクの実行によって所要のタイミングで受信したデータとそれ以前のタイミングで受信したデータとの変化量を算出し、その変化量が所定の閾値を超えない場合に、前記第１タスクの実行周期が長くなるように、前記タスクを実行するタイミングを決定するための情報を更新する。

これによれば、前記第１タスクの実行間隔が長くなるので、第１タスクの実行に利用されるハードウェアリソース（マイクロコントローラ等）の待機時間をより長くすることが可能となり、更なる消費電力の削減が期待できる。

〔１１〕（スケジューリングされたタスクを待機時間が長くなるようにリスケジュールするデータ処理システム）
本願の代表的な別の実施の形態に係るデータ処理装置（１００）は、少なくとも１つのスタンバイモードを有する複数のハードウェアリソース（３、４＿１、４＿２）と、所定の前記ハードウェアリソースを用いて実現されるタスクの実行と前記ハードウェアリソースの動作状態の制御を行うための制御部（１）と、を有する。前記データ処理装置は更に、前記制御部からの指示に応じて、各ハードウェアリソースに対する電源の供給を制御する電源部（２）と、を有する。前記制御部は、前記タスクを実行するタイミングを決定するための情報（ＴＭＩＡ）に基づいて、前記タスクの実行予定時刻のスケジューリングを行うとともに、前記スケジューリングの結果に基づいて、所定の前記ハードウェアリソースに対する電源の供給を指示するとともに当該ハードウェアリソースに対して前記タスクの実行を指示する。前記制御部は、前記スケジューリングを行うとき、所要のタスクの実行開始予定時刻と、その次に実行予定のタスクの実行開始予定時刻との時間間隔が短くなるように、前記所要のタスクの実行予定時刻を所定の時間範囲内で変更可能にされる。

これによれば、タスクとタスクの実行間隔が短くなるようにスケジューリング結果を見直すことが可能となるから、ハードウェアリソースの待機時間をより長くすることができる。これにより、例えばハードウェアリソースの待機中に当該ハードウェアリソースをスタンバイモードに移行させるという制御を行うことにより、消費電力の更なる削減が期待できる。

〔１２〕（リスケジューリングの詳細）
項１１のデータ処理装置において、前記タスクを実行するタイミングを決定するための情報は、前記タスクを実行する周期（Ｔｃ）と、前記タスクの実行時間（Ｔｏｎ）と、前記タスクの実行に用いられる前記ハードウェアリソースを指示する情報（Ｒｓ）と、前記タスクを実行すべき周期に対してずらすことが可能な時間を示す猶予時間（Ｔｅｘ）とを、含む。前記制御部は、前記タスクを実行する周期に基づいてタスクの実行予定時刻をスケジューリングする。前記制御部は更に、前記スケジューリングされた所定のタスクの実行開始予定時刻を基点として、前記猶予時間の範囲内に別のタスクの実行がスケジューリングされている場合に、前記所定のタスクに連続して前記別のタスクが実行されるように、前記所定のタスクの実行予定時刻を変更する。

これによれば、タスクの実行予定時刻をスケジューリングすることが容易となるとともに、周期的なタスクの実行を維持しつつ、ハードウェアリソースの待機時間を長くするように、スケジューリング結果を見直すことが容易となる。

〔１３〕（待機時間と損益分岐時間との比較結果に基づいて各ハードウェアリソースのスタンバイモードへの遷移を決定）
項１１又は１２のデータ処理装置において、前記制御部は、前記スケジューリングの結果に基づいて前記ハードウェアリソースが次の前記タスクの実行に利用されるまでの待機時間を算出する。前記制御部は更に、算出した前記待機時間と予め設定された当該ハードウェアリソースの前記スタンバイモードによる損益分岐時間とを比較することによって、当該ハードウェアリソースをスタンバイモードに遷移させるか否かを、前記ハードウェアリソース毎に決定する。

これによれば、消費電力の削減効果が得られる場合に、スタンバイモードに移行するように夫々のハードウェアリソースが制御することができるので、従来のように、ハードウェアリソースが動作不要な状態になったことを条件としてスタンバイモードに移行させるような単純な制御手法に比べて、データ処理装置全体の消費電力を効果的に削減することができる。

〔１４〕（待機時間の算出）
項１３のデータ処理装置において、前記制御部は、前記リソース情報で指示された所定のハードウェアリソースを使用する所定のタスクの実行完了時刻と前記所定のハードウェアリソースを使用し前記所定のタスクの次に実行されるタスクの実行予定時刻との差分に基づいて前記所定のハードウェアリソースの前記待機時間を算出する。前記実行完了時刻は、前記所定のハードウェアリソースを使用するタスクの実行開始時刻に前記タスクの実行時間を加算することで算出される。

これによれば、ハードウェアリソース毎の待機時間を容易に算出することが可能となる。

〔１５〕（待機時間とＢＥＴの比較結果に基づくスタンバイモードの選択）
項１４のデータ処理装置は、前記ハードウェアリソースとして、電源の供給が遮断されない第１スタンバイモード（ＳＴＢ１、ＳＴＢ２）と電源の供給が遮断される第２スタンバイモード（ＳＴＢ３）とを有するマイクロコントローラを含む。前記マイクロコントローラの前記損益分岐時間として、前記第１スタンバイモードによる第１損益分岐時間（Ｔｂｅ１，Ｔｂｅ２）と前記第２スタンバイモードによる第２損益分岐時間（Ｔｂｅ３）とを含む。前記第２損益分岐時間は、前記第１損益分岐時間よりも大きくされる。前記制御部は、前記マイクロコントローラをスタンバイモードに遷移させるとき、前記算出した前記マイクロコントローラの待機時間（Ｔｗ）が前記第１損益分岐時間より大きく前記第２損益分岐時間より小さい場合に、前記マイクロコントローラを前記第１スタンバイモードに遷移させる。一方、前記算出した前記マイクロコントローラの待機時間が前記第２損益分岐時間より大きい場合に、前記制御部は、前記マイクロコントローラを前記第２スタンバイモードに遷移させる。

これによれば、マイクロコントローラの待機時間に応じて最適なスタンバイモードを選択するから、当該デバイスの消費電力を効果的に削減することができ、データ処理システム全体の更なる省電力化に資する。

〔１６〕（温度毎の損益分岐時間ＢＥＴ）
項１４又は１５のデータ処理装置において、前記スタンバイモードによる損益分岐時間が温度情報に対応して複数（ＨＷＩ＿ＴＬ、ＨＷＩ＿ＴＭ、ＨＷＩ＿ＴＨ）設定される。前記制御部は、入力された前記温度情報に基づいて何れか一つの前記損益分岐時間を選択し、選択した前記損益分岐時間を用いて、前記ハードウェアリソースをスタンバイモードに遷移させるか否かの決定を行う。

これによれば、より正確に最適なスタンバイモードを選択することができ、温度によらず、データ処理装置の消費電力を効果的に削減することが可能となる。

〔１７〕（ＬＤＯの回路電流）
項１５又は１６の何れかのデータ処理装置において、前記電源部は、前記ハードウェアリソースに電源電圧を供給するためのレギュレータ回路（２０＿１〜２０＿ｎ）を夫々のハードウェアリソースに対応させて複数有する。前記制御部は、前記ハードウェアリソースをスタンバイモードに遷移させるとき、当該ハードウェアリソースに対応する前記レギュレータ回路の回路電流が小さくなるように制御する。

これによれば、データ処理装置全体の消費電力を更に削減することが可能となる。

〔１８〕（スタンバイモード毎にＬＤＯの回路電流を変化させる）
項１５のデータ処理装置において、前記制御部は、前記マイクロコントローラを前記第１スタンバイモードに遷移させる場合に、前記マイクロコントローラに対応する前記レギュレータ回路の動作電流を遮断するように制御する。一方、前記制御部は、前記マイクロコントローラを前記第２スタンバイモードに遷移させる場合に、前記マイクロコントローラに対応する前記レギュレータ回路の動作電流が通常時よりも小さくなるように制御する。

これによれば、マイクロコントローラに電源を供給するレギュレータ回路に要求される応答性を担保しつつ、消費電力を効果的に抑えることができる。

〔１９〕（タスクの実行間隔を変更）
項１３乃至１６の何れかのデータ処理装置は、前記タスクとして、前記マイクロコントローラが外部から周期的にデータを受信する第１タスク（タスクＡ又はＢ）を含む。前記マイクロコントローラは、前記第１タスクの実行によって所要のタイミングで受信したデータとそれ以前のタイミングで受信したデータとの変化量を算出し、その変化量が所定の閾値を超えない場合に、前記第１タスクの実行周期が長くなるように、前記タスクを実行するタイミングを決定するための情報を更新する。

これによれば、前記第１タスクの実行間隔が長くなるので、第１タスクの実行に利用されるハードウェアリソース（マイクロコントローラ等）の待機時間をより長くすることが可能となり、更なる消費電力の削減が期待できる。

２．実施の形態の詳細
実施の形態について更に詳述する。なお、発明を実施するための形態を説明するための全図において、同一の機能を有する要素には同一の符号を付して、その繰り返しの説明を省略する。

≪実施の形態１≫
図２は、実施の形態１に係るデータ処理装置の構成を例示する図である。

同図に示されるデータ処理装置１００は、例えば、複数のハードウェアリソースを用いて各種のタスクを実行することにより、所望の機能を実現する。データ処理装置１００は、例えば一つのセンサシステムを構成し、単数又は複数のセンサによって検出された情報に基づいて各種の演算を行うことにより、各種データの生成や各種の機器の制御を行う。データ処理装置１００は、例えば電池又はエネルギーハーベスティング技術による電力供給に基づいて動作可能にされるセンサシステムであって、より省電力での動作が要求される。

具体的に、データ処理装置１００は、複数のハードウェアリソースとしてのマイクロコントローラ（ＭＣＵ）３及びセンサ部４＿１、４＿２と、電源部（ＰＷ＿ＣＮＴ）２と、制御部（ＣＮＴ＿ＵＮＴ）１と、を含んで構成される。なお、図１には、代表的に上記３つのハードウェアリソースが例示されているが、これらの他に、例えば、外付けメモリ（ＲＡＭ）や無線ＩＣ等のハードウェアリソースをデータ処理装置が備えても良い。また、データ処理装置１００が備えるセンサ部の個数に特に制限はない。

センサ部４＿１は、例えば、外部から入力された情報を電気信号に変換するセンサ装置（ＳＮＳＲ）４０＿１と、センサ装置４０＿１によって変換されたアナログ信号を増幅して出力する増幅器（ＡＭＰ）４１＿１と、を含んで構成される。増幅器４１＿１によって増幅されたアナログ信号は、ＭＣＵ３に供給される。同様に、センサ部４＿２は、センサ装置４０＿２と増幅器４１＿２とを含んで構成される。特に制限されないが、例えば、センサ装置４０＿１は温度を計測し、センサ装置４０＿２は湿度を計測する。

ＭＣＵ３は、センサ部４０＿１、４０＿２から供給されたアナログ信号をＡ／Ｄ変換器によってデジタル信号に変換し、ＭＣＵ内部の演算処理部（ＣＰＵ）が前記デジタル信号に基づいて各種の演算処理を行う。その演算処理の結果は、各種の情報データ及び機器を制御するための制御データとして、外部に出力可能にされる。例えば、ＭＣＵ３がセンサ装置４０＿１、４０＿２の検出結果を温度データ及び湿度データとして無線ＩＣ（図示せず）に供給する。そして、無線ＩＣがアンテナを介して無線通信を行うことにより、温度データ及び湿度データが外部のサーバー等のホストシステムに送信される。

電源部２は、制御部１からの指示に応じて、夫々のハードウェアリソースに対する電源供給を制御する。電源部２は、例えば電池又はエネルギーハーベスティング技術によって供給された外部電圧に基づいて、所望の電圧を生成するＬＤＯ（Ｌｏｗ Ｄｒｏｐ Ｏｕｔ）やスイッチングレギュレータ等の複数のレギュレータ回路を含んで構成される。例えば、電源部２は、各種のＬＤＯやスイッチングレギュレータコントローラ等が公知のＣＭＯＳ集積回路の製造技術によって１個の単結晶シリコンのような半導体基板に形成された電源ＩＣと、キャパシタやインダクタ等の複数の電子部品とが接続された電子回路によって実現される。電源部２は、夫々のハードウェアリソースに対して、別個に、電源供給の制御が可能にされる。具体的には、電源部２は、夫々のハードウェアリソースに対応して設けられた複数のレギュレータ回路（ＬＤＯ）２０＿１〜２０＿ｎ（ｎは２以上の整数）を備え、夫々のレギュレータ回路が対応するハードウェアリソースに対する電源の供給や遮断を制御する。

ハードウェアリソースとしてのセンサ部４＿１、４＿２、及びＭＣＵ３は、動作モードとして、通常動作モードと、少なくとも１つのスタンバイモードとを有する。

図３は、各ハードウェアリソースの動作モードを例示する図である。同図の（ａ）に示されるように、センサ部４＿１は、例えば、電源が供給される非スタンバイモード（通常動作モード）と、電源の供給が遮断されるスタンバイモードＳＴＢの２つの動作モードを有する。また、同図の（ｂ）に示されるように、センサ部４＿２は、センサ部４＿１と同様に、電源が供給される非スタンバイモード（通常動作モード）と、電源の供給が遮断されるスタンバイモードＳＴＢの２つの動作モードを有する。ＭＣＵ３は、通常動作モードと複数のスタンバイモードを有する。具体的には、図３の（ｃ）に示されるように、ＭＣＵ３は、非スタンバイモード（通常動作モード）と３つのスタンバイモードＳＴＢ１、ＳＴＢ２、及びＳＴＢ３を動作モードとして有する。なお、本実施の形態ではＭＣＵ３が３つのスタンバイモードを有する場合を例に説明するが、スタンバイモードの数に特に制限はない。スタンバイモードＳＴＢ１は、例えばＭＣＵ３のクロック周波数を通常動作モードよりも低くする動作モードであり、スタンバイモードＳＴＢ２は、例えばＭＣＵ３のクロック周波数と電源電圧を通常動作モードよりも低くする動作モードであり、スタンバイモードＳＴＢ３は、例えばＭＣＵ３の電源供給を遮断する動作モードである。省電力効果は、スタンバイモードＳＴＢ１よりもスタンバイモードＳＴＢ２の方が大きく、スタンバイモードＳＴＢ２よりもスタンバイモードＳＴＢ３の方が大きい。

夫々のハードウェアリソースが何れの動作モードで動作するかは、制御部１が各ハードウェアリソースの待機時間とスタンバイモードによる損益分岐時間ＢＥＴを比較することによって決定される。例えば、図３の（ａ）に示されるように、センサ部４＿１は、待機時間Ｔｗが損益分岐時間Ｔｂｅ４以上である場合に、スタンバイモードに遷移するように制御される。同様にセンサ部４＿２は、図３の（ｂ）に示されるように、待機時間Ｔｗが損益分岐時間Ｔｂｅ５以上である場合に、スタンバイモードに遷移するように制御される。更に、ＭＣＵ３は、図３の（ｃ）に示されるように、待機時間Ｔｗが損益分岐時間Ｔｂｅ１よりも大きい場合にスタンバイモードに遷移するように制御される。この場合において、待機時間Ｔｗが損益分岐時間Ｔｂｅ１より大きく損益分岐時間Ｔｂｅ２より小さい場合には、ＭＣＵ３はスタンバイモードＳＴＢ１に遷移するように制御され、待機時間Ｔｗが損益分岐時間Ｔｂｅ２より大きく損益分岐時間Ｔｂｅ３より小さい場合には、ＭＣＵ３はスタンバイモードＳＴＢ２に遷移するように制御される。更に、待機時間Ｔｗが損益分岐時間Ｔｂｅ３より大きい場合には、ＭＣＵ３はスタンバイモードＳＴＢ３に遷移するように制御される。

次に、制御部１について詳細に説明する。

制御部１は、所定のハードウェアリソースを用いて実現されるタスクの実行とハードウェアリソースの動作状態の制御を行う。具体的には、制御部１は、タスクを実行するタイミングを決定するための情報に基づいて、タスクの実行予定時刻のスケジューリングを行う。制御部１は、そのスケジューリングの結果に従って、所定のハードウェアリソースに対する電源の供給を電源部２に指示するとともに当該ハードウェアリソースに対してタスクの実行を指示する。更に、制御部１は、スケジューリングの結果に基づいて、ハードウェアリソースが次のタスクの実行に利用されるまでの待機時間を算出し、算出した待機時間と予め設定された当該ハードウェアリソースのスタンバイモードによる損益分岐時間とを比較することによって、当該ハードウェアリソースをスタンバイモードに遷移させるか否かを、ハードウェアリソース毎に決定する。以下、制御部１による動作内容について具体的に説明する。なお、本実施の形態では、制御部１が電源部２の内部（電源ＩＣの内部）に形成される場合を例に説明する。

図４は、制御部１の内部構成を例示する図である。同図に示されるように、制御部１は、演算制御部（ＡＴＣ＿ＣＮＴ＿ＵＮＴ）１０と、通信部（ＣＭＭ＿ＵＮＴ）１１と、タイマ部（ＴＭＲ＿ＣＮＴＲ）１２と、記憶部（ＭＲＹ＿ＵＮＴ）１３〜１５と、を含んで構成される。

通信部１１は、外部装置と通信を行うための機能部であり、例えば、シリアル通信制御部（ＳＲＬ＿ＣＭＭ）１１０と、割り込み通信部（ＩＮＴＣ）１１１とを含む。シリアル通信制御部１１０は、外部装置とシリアル通信を行うための機能部である。例えば、制御部１は、シリアル通信制御部１１０を介してＭＣＵ３とシリアル通信を行う。割り込み通信部１１１は、演算制御部１０からの割り込み要求に応じてＭＣＵ３に対する割り込み信号ＳＩＮＴ＿Ｏを生成するとともに、ＭＣＵ３やその他のハードウェアリソースからの割り込み信号ＳＩＮＴ＿Ｉに応じて、演算制御部１０に対して外部割り込み要求を発行する。

タイマ部１２は、所定のクロック信号（図示せず）をカウントすることにより計時を行うタイマカウンタである。タイマ部１２は、例えば演算制御部１０によってカウント動作の開始が指示されたらクロック信号のカウント動作を開始する。そして、演算制御部１０によって設定された指定値とカウント動作によるカウント値とが一致したら、その旨を演算制御部１０に通知する。

演算制御部１０は、タスクのスケジューリングやタスクを実行させるためのシーケンス制御、及び各ハードウェアリソースの動作モードの変更等に関する各種の演算処理や統括的な制御を行うための機能部である。演算制御部１０は、例えば、専用のハードウェアロジックによって実現されても良いし、ＣＰＵやＤＳＰ等のプログラム処理装置がプログラムを実行することによって実現されても良く、特に制限されない。演算制御部１０による具体的な制御内容については、後述する。

記憶部１３〜１５は、演算制御部１０によるタスクのスケジューリングやシーケンス制御、及び各ハードウェアリソースの動作モードの変更等の制御のための各種の情報を格納する。記憶部１３〜１５は、例えば、データを記憶するための記憶領域を有するレジスタやメモリによって実現される。

記憶部１３は、タスクを実行するタイミングを決定するための情報（以下、「タスク管理情報」と称する。）ＴＭＩを格納する。図５にタスク管理情報の一例を示す。同図に示されるように、タスク管理情報ＴＭＩは、タスクの実行周期Ｔｃ、タスクの実行時間Ｔｏｎ、タスク実行の繰り返し回数Ｒｃ、及び使用するハードウェアリソースの情報Ｒｓを含む。夫々の情報は、データ処理装置１００で実行可能なタスクの種類毎にまとめられる。タスクの実行周期Ｔｃは、タスクを定期的に実行する周期を示す情報である。タスクの実行時間Ｔｏｎは、タスクが実行されてから終了するまでに要する時間を示す情報である。タスク実行の繰り返し回数Ｒｃは、周期的に実行するタスクを何回行うかを示す情報である。使用するハードウェアリソースの情報Ｒｓは、そのタスクを実行するのに必要なハードウェアリソースを指示する情報である。本実施の形態では、ＭＣＵ３をハードウェアリソース番号“０”で表し、センサ部４＿１をハードウェアリソース番号“１”で表し、センサ部４＿２をハードウェアリソース番号“２”で表す。ここで、例えば、タスクＡを“センサ部４＿１の検出結果をＭＣＵ３に取り込む処理”とし、タスクＢを“センサ部４＿２の検出結果をＭＣＵ３に取り込む処理”とする。この場合、図５のタスク管理情報ＴＭＩは、“タスクＡはセンサ部４＿１とＭＣＵ３とを用いて５０ｍｓ毎に繰り返し実行される処理であって、その処理時間が１ｍｓとされる”ことを示し、“タスクＢはセンサ部４＿２とＭＣＵ３とを用いて５５ｍｓ毎に繰り返し実行される処理であって、その処理時間が２ｍｓとされる”ことを示している。これらの情報は、例えばパワーオンリセット解除後の初期化時等において、ＭＣＵ３とのシリアル通信を介して記憶部１３に設定される。

記憶部１４は、ハードウェアリソースの情報（以下、「ハードウェア情報」と称する。）ＨＷＩを格納する。図６にハードウェア情報の一例を示す。同図に示されるように、ハードウェア情報ＨＷＩは、各ハードウェアリソースのスタンバイモード毎の損益分岐時間の情報を含む。前述したように、電源遮断等のスタンバイモードに遷移することによるオーバーヘッドよりもスタンバイモードに遷移することによる消費電力の削減量が大きくなる臨界点の時間を損益分岐時間ＢＥＴと称する。詳細は後述するが、本実施の形態によるデータ処理装置１００では、ハードウェアリソースの待機時間が損益分岐時間ＢＥＴよりも大きいと判断される場合に、ハードウェアリソースを所定のスタンバイモードに遷移させる制御を行う。

図６に示されるように、ＭＣＵ３のハードウェア情報として、スタンバイモードＳＴＢ１の損益分岐時間Ｔｂｅ１の情報、スタンバイモードＳＴＢ２の損益分岐時間Ｔｂｅ２の情報、及びスタンバイモードＳＴＢ３の損益分岐時間Ｔｂｅ３の情報が含まれる。また、センサ部４＿１のハードウェア情報としてスタンバイモードＳＴＢの損益分岐時間Ｔｂｅ４の情報が、センサ部４＿２のハードウェア情報としてスタンバイモードＳＴＢの損益分岐時間Ｔｂｅ５の情報が夫々含まれる。これらの情報は、例えばパワーオンリセット解除後の初期化時等において、ＭＣＵ３とのシリアル通信を介して記憶部１４に設定される。なお、同図に示される各損益分岐時間の値はあくまで一例であり、損益分岐時間として種々の値が設定可能である。

記憶部１５は、タスクの実行予定及び実行状況を管理するための情報（以下、「キューリスト」と称する。）ＱＵＥ＿ＬＳＴが格納される。キューリストＱＵＥ＿ＬＳＴは、タスクの種類毎に生成されたリストを含む。図７に、キューリストの一例を示す。例えば、同図に示されるように、キューリストＱＵＥ＿ＬＳＴは、タスクＡのリスト３１＿０とタスクＢのリスト３１＿１を含む。夫々のリスト３１＿０、３１＿１には、タスクＩＤ（ＴＡＳＫ ＩＤ）、タスクの実行状態（Ｓｔａｔｕｓ）、実行予定時刻（Ｓｃｈｅｄｕｌｅｄ ｔｉｍｅ）、及び使用されるハードウェアリソース（Ｒｅｓｏｕｒｃｅ［２：０］）等の情報が格納される。ここで、タスクＩＤは、同一種類のタスクの中で、実行すべき順番に応じて付与されるタスクの識別情報である。タスクの実行状態の情報は、タスクＩＤが付与されたタスクの状態を示すものである。タスクの実行状態の情報について、“Ｅｘｅ”はそのタスクが実行中であることを示し、“Ｒｅａｄｙ”は、そのタスクが“Ｅｘｅ”状態の他のタスクの実行が完了したら続けて実行可能な状態であることを示し、“Ｗａｉｔ”はそのタスクが待機中であることを示す。実行予定時刻の情報は、タスクＩＤが付与されたタスクが実行される予定時刻を示すものである。使用されるハードウェアリソースの情報は、タスクＩＤが付与されたタスクで必要となるハードウェアリソースを示すものである。特に制限されないが、使用されるハードウェアリソースの情報は、図７に示されるように、各桁が夫々のハードウェアリソースに対応しており、例えば、同図の右端の桁がＭＣＵ３を表し、真ん中の桁がセンサ部４＿１を表し、左端の桁がセンサ部４＿２を表す。桁の値が“１”の場合には、その桁に対応するハードウェアリソースがそのタスクの実行に利用されることを表し、桁の値が“０”の場合には、その桁に対応するハードウェアリソースがそのタスクの実行に利用されないことを示す。例えば、図７のリスト３１＿０は、タスクＡ＿１、Ａ＿２の実行により、ＭＣＵ３及びセンサ部４＿１が使用され、センサ部４＿２が使用されないことが示されている。同様に、図７のリスト３１＿１は、タスクＢ＿１、Ｂ＿２の実行により、ＭＣＵ３及びセンサ部４＿２が使用され、センサ部４＿１が使用されないことが示されている。なお、図７に記された具体的な数値等は、あくまで一例である。

次に、演算制御部１０による制御シーケンスについて、図８及び図９を用いて説明する。

図８は、実施の形態１に係るタスクのスケジューリングと動作モードの決定の流れの一例を示す図である。図９は、実施の形態１に係るデータ処理装置におけるキューリストの更新の様子を示す図である。例えば、実施の形態１に係るキューリストは、図８のフローに従って、図９の（ａ）、図９の（ｂ）、図９の（ｃ）、図９の（ｄ）の順に更新される。

図８において、先ず、電源投入後のパワーオンリセット等の解除後にタスク管理情報ＴＭＩ及びハードウェア情報ＨＷＩが記憶部１３、１４に初期設定されると、演算制御部１０は、タスク管理情報ＴＭＩに基づいてキューリストを作成し、キューリストにおける全ての種類のタスクの先頭タスクの実行状態を“Ｒｅａｄｙ”にする（Ｓ１０１）。なお、その他のタスクは、“Ｗａｉｔ”状態にされる。ここでは、図９の（ａ）に示されるキューリストが作成されたとする。

次に、演算制御部１０は、“Ｒｅａｄｙ”状態のタスクのうち最も優先度の高いタスクを実行させ、当該タスクの実行状態を“Ｅｘｅ”にする（Ｓ１０２）。本実施の形態では、タスクの優先度は、例えば、タスクの実行周期が短い順に決定されるものとする。ここでは、図９の（ａ）のキューリストにおけるタスクＡ＿１の実行状態が“Ｅｘｅ”にされ、図９の（ｂ）のようにキューリストが更新されたとする。タスクの実行は、演算制御部１０が、キューリストにおいて“使用するハードウェアリソース”の情報で指定されたハードウェアに対する電源の供給を電源部２に指示するとともに、当該ハードウェアリソースに対して起動トリガ（割り込み信号等）を発行することによって実現される。例えば、図９の（ｂ）の場合、演算制御部１０は、ＭＣＵ３とセンサ部４＿１に対する電源供給と動作開始の指示を行う。

次に、演算制御部１０は、キューリストにおける“Ｅｘｅ”状態のタスクと同一種類のタスクの実行予定時刻を設定する（Ｓ１０３）。具体的には、演算制御部１０は、タスク管理情報ＴＭＩにおけるタスクの実行周期Ｔｃに基づいて、タスクの実行予定時刻を設定する。例えば、図９の（ｂ）には、実行中のタスクＡ＿１と同一種類のタスクＡ＿２の実行予定時刻として“５０ｍｓ”が設定された場合が示されている。

次に、演算制御部１０は、キューリストにおいて“Ｒｅａｄｙ”状態の他のタスクが存在するか否かを判定する（Ｓ１０４）。“Ｒｅａｄｙ”状態の他のタスクが存在する場合には、演算制御部１０は、“Ｒｅａｄｙ”状態のタスクのうち最も優先度の高いタスクを選択し、選択したタスクの実行予定時刻を設定する（Ｓ１０５）。具体的には、演算制御部１０は、その時に実行されているタスクの実行予定時刻からそのタスクの実行時間分だけずらした時刻を、選択したタスクの実行予定時刻とする。例えば、図９の（ｂ）には、実行中のタスクＡ＿１の実行開始時刻（０ｍｓ）からタスクＡ＿１の実行時間（１ｍｓ）だけ経過した時刻“１ｍｓ”を“Ｒｅａｄｙ”状態のタスクＢ＿１の実行予定時刻として設定した場合が示されている。一方、ステップＳ１０４において、“Ｒｅａｄｙ”状態の他のタスクが存在しない場合には、演算制御部１０は、“Ｗａｉｔ”状態のタスクのうち最も実行予定時刻の早いタスクを選択し、選択したタスクの実行予定時刻をタイマ部１２に設定する（Ｓ１０６）。例えば、図９（ｃ）のように、“Ｒｅａｄｙ”状態の他のタスクがない場合には、“Ｗａｉｔ”状態のタスクＡ＿２、Ｂ＿２のうち実行予定時刻の最も早いタスクＡ＿２の実行予定時刻（５０ｍｓ）をタイマ部１２にセットとする。以上の処理により、タスクがキューリストにスケジューリングされる。

次に、演算制御部１０は、スケジューリング結果に基づいて、各ハードウェアリソースの待機時間の算出を行う。先ず、演算制御部１０は、現在実行中のタスク（“Ｅｘｅ”状態のタスク）で使用されているハードウェアリソースの何れか一つを選択し、選択されたハードウェアリソースを利用する次のタスクを探索する（Ｓ１０７）。具体的には、現在実行中のタスクと同一種類のタスクの中で最も実行予定時刻の早いタスク、又は現在実行中のタスクと異なる種類のタスクの中で最も実行予定時刻の早いタスクが選択される。次に、演算制御部１０は、ハードウェアリソースの待機時間を算出する（Ｓ１０８）。具体的には、現在実行されているタスクの実行予定時刻に当該タスクの実行時間を加算することで、現在実行されているタスクの終了予定時刻を算出する。次に、算出した終了予定時刻と、ステップＳ１０７で選択されたタスクの実行予定時刻との差分を算出し、算出した差時間をステップＳ１０７で選択したハードウェアリソースの待機時間とする。演算制御部１０は、ステップＳ１０８で算出した所定のハードウェアリソースの待機時間と、当該ハードウェアリソースの各スタンバイモードに係る損益分岐時間ＢＥＴとを比較し、次に遷移させるべき動作モードを決定する（Ｓ１０９）。演算制御部１０は、全てのハードウェアリソースの動作モードが決定するまで、上記Ｓ１０７〜Ｓ１０９の処理を繰り返す。

演算制御部１０は、“Ｅｘｅ”状態のタスクの実行が終了したら、各ハードウェアリソースに対して、ステップＳ１０９で決定した動作モードに遷移させる（Ｓ１１０）。具体的には、所定のハードウェアリソースをスタンバイモードに遷移させる場合、演算制御部１０は、当該ハードウェアに対する電源遮断や電源電圧の低下等を電源部２に指示するとともに、当該ハードウェアリソースに対して割り込み信号等を発行してスタンバイモードに移行することを通知する。その後、演算制御部１０は、キューリストを参照し、他に“Ｒｅａｄｙ”状態のタスクがあるか否かを判断する（Ｓ１１１）。他に“Ｒｅａｄｙ”状態のタスクがある場合には、ステップＳ１０２に戻り、上記の処理を繰り返し実行する（Ｓ１０２〜Ｓ１１０）。他に“Ｒｅａｄｙ”状態のタスクがない場合には、演算処理部１０は、起動時刻をタイマ部１２にセットし、待機状態に入る（Ｓ１１２）。例えば、図９の（ｄ）のように、全てのタスクが“Ｗａｉｔ”状態となったら、次のタスクの実行予定時刻（例えば、タスクＡ＿２の実行予定時刻５０ｍｓ）になるまで、演算処理部１０は待機状態となる。その後、ステップＳ１１２で設定した起動時刻になったら、演算処理部１０はタイマ部１２からの通知に応じて待機状態から復帰し、ステップＳ１０２から処理を再開する。

ここで、上記ステップＳ１０７〜Ｓ１０９による各ハードウェアリソースの待機時間の算出と動作モードの決定に係る処理について、図９の（ｂ）、（ｃ）を用いて具体的に説明する。

図９の（ｂ）のスケジューリング結果における各ハードウェアリソースの動作モードの決定手順は以下である。図９の（ｂ）に示されるように、実行中のタスクＡ＿１で使用されているハードウェアリソースは、センサ部４＿１とＭＣＵ３である。センサ部４＿１は、タスクＡ＿２でのみ使用が予定されていることから、演算処理部１０は、ステップＳ１０７において、センサ部４＿１の使用を予定している次のタスクとして“タスクＡ＿２”を選択する。一方、ＭＣＵ３は、タスクＡ＿２とタスクＢ＿１で使用が予定されており、タスクＡ＿２よりもタスクＢ＿１の方が実行予定時刻が早いことから、演算処理部１０は、ステップＳ１０７において、ＭＣＵ３の使用を予定している次のタスクとして“タスクＢ＿１”を選択する。次に、演算制御部１０は、ステップＳ１０８において、センサ部４＿１とＭＣＵ３の待機時間を夫々算出する。センサ部４＿１の待機時間を算出する場合、演算制御部１０が、現在実行中のタスクＡ＿１の実行予定時刻（０ｍｓ）とタスクＡ＿１の実行時間（１ｍｓ）とを加算することで、タスクＡ＿１の終了予定時刻（１ｍｓ）を算出する。そして、演算制御部１０は、算出したタスクＡ＿１の終了予定時刻（１ｍｓ）と、ステップＳ１０７で選択したタスクＡ＿２の実行予定時刻（５０ｍｓ）との差（４９ｍｓ）を算出し、その差をセンサ部４＿１の待機時間（４９ｍｓ）とする。また、ＭＣＵ３の待機時間を算出する場合、演算制御部１０は、先ほど算出したタスクＡ＿１の終了予定時刻（１ｍｓ）と、ステップＳ１０７で選択したタスクＢ＿１の実行予定時刻（１ｍｓ）との差（０ｍｓ）を算出し、その差をセンサ部４＿１の待機時間（０ｍｓ）とする。次に、演算制御部１０は、ステップＳ１０８において、算出した待機時間と損益分岐時間とを比較する。この場合、センサ部４＿１の待機時間（４９ｍｓ）が損益分岐時間Ｔｂｅ４（１０ｍｓ）より大きいので、演算制御部１０は、タスクＡ＿１の終了後にセンサ部４＿１をスタンバイモードに遷移させることを決定する。一方、ＭＣＵ３の待機時間（０ｍｓ）であり、ＭＣＵ３はタスクＡ＿１の後に連続してタスクＢ＿１で使用されるため、演算制御部１０は、ＭＣＵ３をスタンバイモードに遷移させず、通常動作モードでの動作を継続させることを決定する。

図９の（ｃ）のスケジューリング結果における各ハードウェアリソースの動作モードの決定手順は以下である。図９の（ｃ）に示されるように、実行中のタスクＢ＿１で使用されているハードウェアリソースは、センサ部４＿２とＭＣＵ３である。センサ部４＿２は、タスクＢ＿２でのみ使用が予定されていることから、演算処理部１０は、ステップＳ１０７において、センサ部４＿２の使用を予定している次のタスクとして“タスクＢ＿２”を選択する。一方、ＭＣＵ３は、タスクＡ＿２とタスクＢ＿２で使用が予定されており、タスクＢ＿２よりもタスクＡ＿２の方が実行予定時刻が早いことから、演算処理部１０は、ステップＳ１０７において、ＭＣＵ３の使用を予定している次のタスクとして“タスクＡ＿２”を選択する。次に、演算制御部１０は、ステップＳ１０８において、センサ部４＿２とＭＣＵ３の待機時間を夫々算出する。センサ部４＿２の待機時間を算出する場合、演算制御部１０が、現在実行中のタスクＢ＿１の実行予定時刻（１ｍｓ）とタスクＢ＿１の実行時間（２ｍｓ）とを加算することで、タスクＢ＿１の終了予定時刻（３ｍｓ）を算出する。そして、演算制御部１０は、算出したタスクＢ＿１の終了予定時刻（３ｍｓ）と、ステップＳ１０７で選択したタスクＢ＿２の実行予定時刻（５６ｍｓ）との差（５３ｍｓ）を算出し、その差をセンサ部４＿２の待機時間（５３ｍｓ）とする。また、ＭＣＵ３の待機時間を算出する場合、演算制御部１０は、先ほど算出したタスクＢ＿１の終了予定時刻（３ｍｓ）と、ステップＳ１０７で選択したタスクＡ＿２の実行予定時刻（５０ｍｓ）との差（４７ｍｓ）を算出し、その差をＭＣＵ３の待機時間（４７ｍｓ）とする。次に、演算制御部１０は、算出した待機時間と損益分岐時間とを比較する。この場合、センサ部４＿２の待機時間（５３ｍｓ）が損益分岐時間Ｔｂｅ５（１０ｍｓ）より大きいので、演算制御部１０は、タスクＢ＿１の終了後にセンサ部４＿２をスタンバイモードに遷移させることを決定する。一方、ＭＣＵ３の待機時間（４７ｍｓ）が損益分岐時間Ｔｂｅ３（２９ｍｓ）より大きいので、演算制御部１０は、タスクＢ＿１の終了後にＭＣＵ３をスタンバイモードＳＴＢ３（電源遮断）に遷移させることを決定する。

以上の手順で各ハードウェアリソースの待機時間が算出され、各ハードウェアリソースの動作モードが決定される。

次に、制御部１０とＭＵＣ３との間の通信について説明する。

ＭＣＵ３は、演算制御部１０の内部に設けられたタスク／モードレジスタ（ＴＡＳＫ／ＭＯＤＥ＿ＲＥＧ）１６を参照することにより、次に実行すべきタスクの種類や次に遷移すべき動作モード等を把握する。タスク／モードレジスタ１６を利用した制御部１０とＭＵＣ３との間の通信手順について、図１０を用いて具体的に説明する。

図１０は、ＭＣＵ３の動作モードを変更するときの制御部１０とＭＣＵ３間の通信の流れを示す図である。なお、同図に記されたステップ番号は、前述した図８のフロー図のステップ番号に対応する。

先ず、ステップＳ１０１において、演算制御部１０は、キューリストにおける全ての先頭タスクの実行状態を“Ｒｅａｄｙ”にした後、実行させるタスクを示す値をタスク／モードレジスタ１６に設定する。ここでは、タスクＡ＿１が実行されるものとし、タスク／モードレジスタ１６にはタスクＡ＿１を示す値が設定される。

演算制御部１０は、ステップＳ１０２において、実行させるタスクで使用されるＭＣＵ３及びセンサ部４＿１に対する電源供給開始を電源部２に指示するとともに、ＭＣＵ３に対して割り込み信号ＳＩＮＴ＿Ｏを発行してタスクの実行を指示する。ＭＣＵ３は、電源部２からの電源供給と割り込み信号ＳＩＮＴ＿Ｏに応じて待機状態から復帰すると、先ず、タスク／モードレジスタ１６に設定された情報を読み出す。そして、ＭＣＵ３は、タスク／モードレジスタ１６で指示されたタスクＡ＿１を実行する。この間、演算制御部１０は、上述したステップＳ１０３〜Ｓ１１０の処理を行うことで、タスクのスケジューリングと各ハードウェアリソースの待機時間に基づく動作モードの決定を行う。ここでは、ＭＣＵ３の次に遷移すべき動作モードとしてスタンバイモードＳＴＢ２が選択されたとする。

タスクの実行が完了すると、ＭＣＵ３が演算制御部１０に対して割り込み信号ＳＩＮＴ＿Ｉを発行する。割り込み信号ＳＩＮＴ＿Ｉを受けた演算制御部１０は、タスク／モードレジスタ１６にスタンバイモードＳＴＢ２を指示する値を設定する。そして、演算制御部１０は、ＭＣＵ３に対して割り込み信号ＳＩＮＴ＿Ｏを発行することでＭＣＵ３の動作モードが変更されることを通知する。割り込み信号ＳＩＮＴ＿Ｏを受けたＭＣＵ３は、シリアル通信により、タスク／モードレジスタ１６の値を読み出す。そして、ＭＣＵ３はスタンバイモードＳＴＢ２に遷移する前に、必要に応じて、各種のレジスタに設定されたデータ等を不揮発性のメモリ等に退避させる等の準備処理を行う。ＭＣＵ３は、上記準備処理が完了したら、演算制御部１０に対して割り込み信号ＳＩＮＣ＿Ｉを発行する。割り込み信号ＳＩＮＣ＿Ｉを受けた演算制御部１０は、ステップＳ１１０において、電源部２に対し、ＭＣＵ３の電源供給状態を変化させることを指示する。これにより、ＭＣＵ３は、スタンバイモードＳＴＢ２で動作する。

図１１に、実施の形態１に係るデータ処理装置におけるタスクのスケジューリング結果とＭＣＵ３の動作モードの遷移状態の一例を示す。前述したように、タスクＡの実行周期Ｔｃは５０ｍｓ、実行時間Ｔｏｎは１ｍｓであり、タスクＢの実行周期Ｔｃは５５ｍｓ、実行時間Ｔｏｎは１ｍｓである。また、前述したように、ＭＣＵ３はタスクＡとタスクＢの双方で使用される。なお、同図において、“１”はスタンバイモードＳＴＢ１を表し、“２”はスタンバイモードＳＴＢ２を表し、“３”はスタンバイモードＳＴＢ３を表し、斜線部は通常動作モード（非スタンバイモード）を表す。

同図に示されるように、タスクＢ＿１の実行が完了してからタスクＡ＿２が実行されるまでの期間におけるＭＣＵ３の待機時間は“４７ｍｓ”であり、ＭＣＵ３のスタンバイモードＳＴＢ３の損益分岐時間Ｔｂｅ３（２９ｍｓ）よりも大きい。そのため、当該期間において、ＭＣＵ３はスタンバイモードＳＴＢ３に遷移し、電源供給が遮断される。また、タスクＡ＿２の実行が完了してからタスクＢ＿２が実行されるまで期間におけるＭＣＵ３の待機時間は“５ｍｓ”であり、ＭＣＵ３のスタンバイモードＳＴＢ１の損益分岐時間Ｔｂｅ１（２ｍｓ）より大きいが、スタンバイモードＳＴＢ２の損益分岐時間Ｔｂｅ２（１１ｍｓ）よりも小さい。そのため、当該期間において、ＭＣＵ３は、スタンバイモードＳＴＢ１に遷移する。このように、ＭＣＵ３の待機時間に応じて最適なスタンバイモードが動的に選択される。

以上、実施の形態１に係るデータ処理装置によれば、十分な消費電力の削減効果が得られるように、夫々のハードウェアリソースの待機時間とスタンバイモードによる損益分岐時間ＢＥＴとを比較することで、ハードウェアリソース毎に最適なスタンバイモードを決定するから、データ処理装置の消費電力を削減することができる。特に、複数のスタンバイモードを有するデバイス（マイクロコントローラ等）を含むデータ処理装置の消費電力を効果的に削減する手法として、特に有効である。また、本データ処理装置によれば、従来のように、ハードウェアリソースが動作不要な状態になったことを条件としてスタンバイモードに移行させるような単純な制御手法に比べて、データ処理装置全体の消費電力を効果的に削減することができる。また、タスク管理情報ＴＭＩを用いることで、タスクのスケジューリングが容易となるとともに、ハードウェアリソースの待機時間を容易に算出することが可能となる。

≪実施の形態２≫
実施の形態２に係るデータ処理装置は、実施の形態１に係るデータ処理装置の機能に加え、ハードウェアリソースの待機時間が長くなるように、一旦スケジューリングされたタスクの実行予定時刻を変更（リスケジュール）する機能を備える。

実施の形態２に係るデータ処理装置は、実施の形態１に係るデータ処理装置１０と主なハードウェア構成は同様であり、記憶部１３に格納されるタスク管理情報及び記憶部１５に格納されるキューリストのデータ構造が相異する。

図１２は、実施の形態２に係るタスク管理情報の一例を示す図である。同図に示されるタスク管理情報ＴＭＩＡは、実施の形態１に係るタスク管理情報ＴＭＩに加えて、猶予時間Ｔｅｘの情報を更に含む。猶予時間Ｔｅｘとは、タスクを実行すべき周期に対してずらすことが可能な時間を示す情報である。例えば、図１２に示されるように、タスクＡの実行周期Ｔｃが５０ｍｓ、猶予時間ＴｅｘがＴｃ／４（１２．５ｍｓ）である場合、時刻０ｍｓにおいて実行されたタスクＡ＿１の次に実行されるタスクＡ＿２の実行予定時刻を、“５０ｍｓ＋１２．５ｍｓ”の範囲内に設定することができる。

図１３は、実施の形態２に係るキューリストの一例を示す図である。同図に示されるキューリストＱＵＥ＿ＬＳＴＡは、実施の形態１に係るキューリストＱＵＥ＿ＬＳＴと同様に、タスクの種類毎にリスト３２＿０、３２＿１が作成される。キューリストＱＵＥ＿ＬＳＴＡは、夫々のリスト３２＿０、３２＿１には、実施の形態１に係るリスト３１＿０、３１＿１の情報に加えて、“変更後の実行予定時刻（Ｒｅｓｃｈｅｄｕｌｅｄ ｔｉｍｅ）”を示す情報が含まれる。スケジューリングされた実行予定時刻（Ｓｃｈｅｄｕｌｅｄ ｔｉｍｅ）が変更された場合に、変更後の実行予定時刻の情報がキューリストに書き込まれる。

図１４は、実施の形態２に係るタスクのスケジューリングと動作モードの決定の流れの一例を示す図である。図１５は、実施の形態２に係るデータ処理装置におけるキューリストの更新の様子を示す図である。例えば、実施の形態２に係るキューリストは、図１４のフローに従って、図１５の（ａ）、図１５の（ｂ）、図１５の（ｃ）、図１５の（ｄ）の順に更新される。

図１４に示されるフロー図は、ステップＳ１０６の処理の代わりにステップＳ２０１〜Ｓ２０３の処理を含む点で図８のフロー図と相異する。なお、図８のフロー図と同一の処理ステップについては、同一の符号を付して、その詳細な説明を省略する。

先ず、電源投入後のパワーオンリセット等の解除後にタスク管理情報ＴＭＩＡ及びハードウェア情報ＨＷＩが記憶部１３、１４に初期設定されると、演算制御部１０は、タスク管理情報ＴＭＩＡに基づいてキューリストを作成し、キューリストにおける全ての種類のタスクの先頭タスクの実行状態を“Ｒｅａｄｙ”にする（Ｓ１０１）。なお、その他のタスクは、“Ｗａｉｔ”状態にされる。ここでは、図１５の（ａ）に示されるキューリストが作成されたとする。

次に、演算制御部１０は、“Ｒｅａｄｙ”状態のタスクのうち最も優先度の高いタスクを実行させるとともに当該タスクの実行状態を“Ｅｘｅ”にする（Ｓ１０２）。そして、演算制御部１０は、キューリストにおける“Ｅｘｅ”状態のタスクと同一種類のタスクの実行予定時刻を設定する（Ｓ１０３）。ここでは、図１５の（ａ）のキューリストにおけるタスクＡ＿１の実行状態が“Ｅｘｅ”にされ、図１５の（ｂ）のように、実行中のタスクＡ＿１と同一種類のタスクＡ＿２の実行予定時刻として“５０ｍｓ”が設定されたとする。

次に、演算制御部１０は、キューリストにおいて“Ｒｅａｄｙ”状態の他のタスクが存在するか否かを判定する（Ｓ１０４）。“Ｒｅａｄｙ”状態の他のタスクが存在する場合には、演算制御部１０は、“Ｒｅａｄｙ”状態のタスクのうち最も優先度の高いタスクを選択し、選択したタスクの実行予定時刻を設定する（Ｓ１０５）。例えば、図１５の（ｂ）には、実行中のタスクＡ＿１の実行開始時刻（０ｍｓ）からタスクＡ＿１の実行時間（１ｍｓ）だけ経過した時刻“１ｍｓ”を“Ｒｅａｄｙ”状態のタスクＢ＿１の実行予定時刻として設定した場合が示されている。その後の処理も、前述の図８のフロー図と同様の手順で進められる（Ｓ１０７〜Ｓ１１２）。

一方、ステップＳ１０４において、“Ｒｅａｄｙ”状態の他のタスクが存在しない場合、演算制御部１０は、“Ｗａｉｔ”状態のタスクのうち最も実行予定時刻の早いタスクを選択する（Ｓ２０１）。そして、演算制御部１０は、ステップＳ２０１で選択したタスクの実行開始予定時刻を基点とした猶予時間Ｔｅｘの範囲内に、実行が予定されている別のタスクがあるか否かを判別する（Ｓ２０２）。猶予時間Ｔｅｘの範囲内に実行予定の別のタスクがスケジューリングされている場合には、ステップＳ２０１で選択した“Ｗａｉｔ”状態のタスクと前記別のタスクとの時間間隔が短くなるように、ステップＳ２０１で選択した“Ｗａｉｔ”状態のタスクの実行予定時刻を変更する（Ｓ２０３）。なお、“Ｗａｉｔ”状態のタスクが複数ある場合には、ステップＳ２０２、Ｓ２０３を繰り返し実行し、できる限りまとめてタスクを実行できるよう再調整する。一方、猶予時間Ｔｅｘの範囲内に実行が予定されている別のタスクが存在しない場合、又はステップＳ２０２で実行予定時刻の変更が完了した場合には、ステップＳ１０７に移行し、実施の形態１と同様の処理手順で各ハードウェアリソースの動作モードが決定される（Ｓ１０７〜Ｓ１１２）。

ここで、上記ステップＳ２０１〜Ｓ２０３によるタスクの実行予定時刻の変更に係る処理について、図１５の（ｃ）を用いて具体的に説明する。

図１５の（ｃ）のスケジューリング結果におけるタスクの実行予定時刻の変更の手順は以下である。図１５の（ｃ）に示されるように、“Ｗａｉｔ”状態のタスクは、タスクＡ＿２、タスクＢ＿２、及びタスクＡ＿３であり、夫々の実行開始予定時刻は、“５０ｍｓ”、“５６ｍｓ”、及び“未定”である。ステップＳ２０１において、演算処理部１０は、“Ｗａｉｔ”状態のタスクＡ＿２、Ａ＿３、Ｂ＿２のうち最も実行予定時刻の早い“タスクＡ＿２”を選択する。次に、演算処理部１０は、ステップ２０２において、選択されたタスクＡ＿２の実行開始予定時刻から猶予時間Ｔｅｘの範囲内に、実行が予定されている別のタスクがあるか否かを判断する。具体的には、演算処理部１０は、選択されたタスクＡ＿２の実行予定時刻（５０ｍｓ）にタスクＡの猶予時間Ｔｅｘ（Ｔｃ／４＝１２．５ｍｓ）を加算した時刻（６２．５ｍｓ）までに、別のタスクがあるか否かを判断する。図１５の（ｃ）の場合、時刻６２．５ｍｓまでの間にタスクＢ＿２（実行予定時刻５６ｍｓ）の実行が予定されているため、演算制御部１０は、猶予時間内に別のタスクがあると判断する。次に、演算処理部１０は、タスクＡ＿２とタスクＢ＿２との時間間隔が短くなるようにタスクＡ＿２の実行予定時刻を変更する。具体的には、タスクＡ＿２とタスクＢ＿２が連続して実行されるようにタスクＡ＿２の実行予定時刻を変更する。例えば、図１５の（ｃ）に示されるように、タスクＢ＿２の実行予定時刻が“５６ｍｓ”であり、タスクＡ＿２の実行時間が“１ｍｓ”であることから、タスクＡ＿２とタスクＢ＿２が連続実行されるように、タスクＡ＿２の実行予定時刻を“５０ｍｓ”から“５５ｍｓ”に変更する。これにより、実行中のタスクＢ＿１の終了予定時刻からタスクＡ＿２の実行予定時刻までの時間間隔が長くなる。

図１６に、実施の形態２に係るタスクのスケジューリング結果とＭＣＵ３の動作モードの遷移状態の一例を示す。前述したように、タスクＡの実行周期Ｔｃは５０ｍｓ、実行時間Ｔｏｎは１ｍｓ、猶予時間ＴｅｘはＴｃ／４（＝１２．５ｍｓ）であり、タスクＢの実行周期Ｔｃは５５ｍｓ、実行時間Ｔｏｎは１ｍｓ、猶予時間ＴｅｘはＴｃ／２（＝２７．５ｍｓ）である。また、前述したように、ＭＣＵ３はタスクＡとタスクＢの双方で使用される。なお、同図において、“１”はスタンバイモードＳＴＢ１を表し、“２”はスタンバイモードＳＴＢ２を表し、“３”はスタンバイモードＳＴＢ３を表し、斜線部は通常動作モード（非スタンバイモード）を表す。

図１６に示されるように、前述した制御部１によるスケジューリングの変更により、タスクＢ＿１の実行中にタスクＡ＿２の実行予定時刻が“５０ｍｓ”から“５５ｍｓ”に変更される。これにより、タスクＢ＿１が完了してからタスクＡ＿２が実行されるまでのＭＣＵ３の待機時間が、“４７ｍｓ”（図１１参照）から５２ｍｓに増加する。すなわち、ＭＣＵ３の電源が遮断される期間（スタンバイモードＳＴＢ３で動作する期間）が長くなる。同様に、タスクＡ＿３の実行予定時刻が変更されることにより、タスクＢ＿２が完了してからタスクＡ＿３が実行されるまでのＭＣＵ３の待機時間が“４２ｍｓ”（図１１参照）から“５２ｍｓ”に増加し、ＭＣＵ３の電源が遮断される期間が長くなる。更に、タスクＡ＿５以降では、同様の原理でタスクＢ＿５の実行予定時刻が変更されることにより、タスクＡ＿５が完了してからタスクＢ＿５が実行されるまでの待機時間が“２０ｍｓ”（図１１参照）から“４７ｍｓ”に増加し、ＭＣＵ３の電源が遮断される期間が長くなる。

このように、実施の形態２に係るデータ処理装置によれば、タスクとタスクの実行間隔が短くなるようにスケジューリング結果が見直されるから、ハードウェアリソースの待機時間をより長くすることができる。これにより、各ハードウェアリソースをスタンバイ状態にしておくことができる期間が長くなるので、データ処理装置の消費電力を更に削減することができる。特に、本実施の形態のように、電源を遮断するスタンバイモードと電源を遮断しないスタンバイモードを有するデバイス（マイコン等）を含むデータ処理装置の場合、待機時間が長くなることで電源が遮断されるスタンバイモードに遷移する確率が高くなるので、更なる電力の削減が期待できる。

≪実施の形態３≫
実施の形態３に係るデータ処理装置は、実施の形態１に係るデータ処理装置の機能に加え、スタンバイモードに応じて電源部２のレギュレータ回路の回路電流を変更する機能を備える。

図１７は、実施の形態３に係るデータ処理装置におけるレギュレータ回路２０＿ｎの内部構成を例示する図である。同図に示されるように、各ハードウェアリソースに電源を供給するレギュレータ回路２０＿ｎは、差動増幅器ＤＡＭＰと、出力ドライバとしてのＭＯＳトランジスタＰＤとを含んで構成される。差動増幅器ＤＡＭＰが出力電圧ＶＩＮ＿ｎが一定になるようにＭＯＳトランジスタＰＤのゲート電圧を制御することで、安定した電源電圧がハードウェアリソースに供給される。

図１８は、レギュレータ回路における差動増幅器ＤＡＭＰの差動増幅段の回路構成を例示する図である。同図に示されるように、実施の形態３に係るデータ処理装置では、差動増幅器ＤＡＭＰの差動増幅段のバイアス電流（例えばテイル電流）ＩＢＳが、電源供給先のハードウェアリソースの動作モードに応じて可変にされる。例えば、ＭＣＵ３に電源電圧を供給するレギュレータ回路２０＿ｎの場合、ＭＣＵ３がスタンバイモードで動作する場合には、バイアス電流ＩＢＳが通常動作モード時よりも小さくされる。例えば、ＭＣＵ３が第１、第２スタンバイモードＳＴＢ１、ＳＴＢ２（電源供給あり）に遷移する場合には、バイアス電流ＩＢＳを通常動作モード時よりも小さくする。スタンバイモードＳＴＢ１、ＳＴＢ２では、通常動作モード時よりも高い電流のソース能力が要求されないことから、差動増幅器ＤＡＭＰのバイアス電流を減らしてレギュレータ回路の応答性を下げたとしても、十分に対応することができる。一方、ＭＣＵ３がスタンバイモードＳＴＢ３（電源遮断）に遷移する場合には、バイアス電流ＩＢＳを“０（ゼロ）”にして、レギュレータ回路２０＿ｎの差動増幅器ＤＡＭＰの回路電流を遮断する。なお、センサ部４＿１、４＿２に電源を供給するレギュレータ回路２０＿１、２０＿２についても同様に、センサ部４＿１の動作モードに応じてバイアス電流ＩＢＳが変更される。

以上のように、ハードウェアリソースの動作モードに応じて電源部２のレギュレータ回路の回路電流を変化させることにより、レギュレータ回路に要求される応答性を担保しつつ、データ処理装置の消費電流を更に削減することが可能となる。

≪実施の形態４≫
実施の形態４に係るデータ処理装置は、実施の形態１に係るデータ処理装置の機能に加え、温度に応じて損益分岐時間ＢＥＴを変更する機能を備える。具体的には、制御部１がハードウェア情報ＨＷＩを複数有し、外部から入力された温度情報に基づいて何れかのハードウェア情報を選択し、選択したハードウェア情報の損益分岐時間を用いて各ハードウェアリソースの動作モードを決定する。

図１９に、実施の形態４に係るデータ処理装置を例示する。同図に示されるデータ処理装置は、ＭＣＵ３の内部に温度センサ６を有する。制御部１は、温度センサ６によって検出された温度情報を入力する。なお、本実施の形態では温度センサ６をＭＣＵ３の内部に設けた場合を例示しているが、データ処理装置１００の内部であれば、温度センサ６の設置場所は特に限定されない。

図２０は、実施の形態４に係るハードウェア情報を例示する図である。同図に示されるように、制御部１の記憶部１４には、複数のハードウェア情報ＨＷＩ＿ＴＭ、ＨＷＩ＿ＴＨ、ＨＷＩ＿ＴＬが格納される。夫々のハードウェア情報は温度に対応して設けられる。例えば、温度範囲が−４０度から０度に対応するハードウェア情報ＨＷＩ＿ＴＬ、温度範囲が０度から４０度に対応するハードウェア情報ＨＷＩ＿ＴＭ、温度範囲が４０度から８０度に対応するハードウェア情報ＨＷＩ＿ＴＨ等のように、温度範囲に対応したハードウェア情報が記憶部１４に格納される。例えば、制御部１は、温度センサ５による温度情報を定期的に受信し、当該温度情報に基づいて、記憶部１４に格納されたハードウェア情報の何れかを選択する。例えば、温度センサ５によるセンス結果が“２５度”であった場合、制御部１は温度範囲が０度から４０度に対応するハードウェア情報ＨＷＩ＿ＴＭの損益分岐時間の情報を利用して、前述した待機時間Ｔｗとの比較を行い、各ハードウェアリソースの動作モードを決定する。なお、その他の制御内容については、実施の形態１と同様である。

前述したように、一般に、スタンバイモードによる損益分岐時間ＢＥＴは温度によって変化することが知られている。そこで、実施の形態４に係るデータ処理装置のように温度に応じて損益分岐時間を変更することで、より正確に最適なスタンバイモードを選択することができ、温度によらず、データ処理装置の消費電力を効果的に削減することが可能となる。

≪実施の形態５≫
実施の形態５に係るデータ処理装置は、実施の形態１に係るデータ処理装置の機能に加えて、タスクの実行結果に基づいてタスクの実行周期を変更する機能を備える。

例えば、“センサ部４＿１の検出結果をＭＣＵ３に取り込む処理”である“タスクＡ”を、５０ｍｓ毎に、データ処理装置１００が実行する場合を考える。この場合、ＭＣＵ３は、５０ｍｓ毎にセンサ部４＿１の検出結果を受信する。ＭＣＵ３は、タスクＡ＿ｎで受信したセンサ部４＿１の検出結果と、タスクＡ＿ｎより以前に実行されたタスク（例えば、直前のタスクＡ＿ｎ−１）によるセンサ部４＿１の検出結果とを比較し、センサ部４＿１の検出結果がどの程度変化したかを計算する。センサ部４＿１の検出結果の変化量が所定の閾値を超えない場合には、ＭＣＵ３は、タスクＡの実行周期が長くなるように、タスクＡの実行周期Ｔｃの値を更新する。具体的には、ＭＣＵ３は、制御部１の記憶部１３にアクセスし、そこに格納されたタスク管理情報ＴＭＩにおけるタスクＡの実行周期Ｔｃを初期値の“５０ｍｓ”よりも大きい値（例えば“６０ｍｓ”）に変更する。

これによれば、定期的なタスクの実行によって得られる結果（データ）があまり変化しない場合には、タスクの実行周期が長くなるようにタスクの実行スケジュールが見直されるので、そのタスクで使用されるハードウェアリソース（上記の例の場合、ＭＣＵ３及びセンサ部４＿１）の待機時間を長くすることができる。

以上のように、実施の形態５に係るデータ処理装置によれば、タスクの実行周期を見直すことで、ハードウェアリソースの待機時間を長くすることができるので、更なる電力の削減が期待できる。

以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。

例えば、実施の形態３乃至５のデータ処理装置の構成及び機能を、実施の形態１に係るデータ処理装置に適用する場合を例示したが、上記の機能及び構成を実施の形態２に係るデータ処理装置に適用することも可能である。

データ処理装置１００がセンサシステムである場合を例示したが、これに限られず、例えばバッテリ駆動される携帯端末等のその他のシステムにも適用することができる。

また、前述したように、制御部１の設置場所は電源ＩＣの内部に限られないが、制御部１は他のハードウェアリソースがスタンバイ状態である場合であっても起動している必要があることから、システムの仕様上、電源の遮断が行われる機会の少ない電源ＩＣやリアルタイムクロック（ＲＴＣ）ＩＣ等の内部に制御部１を形成することが好ましいが、ＭＣＵ３の内部に設けることも、制御部１だけで単独のＩＣとして形成することも可能である。

また、複数のスタンバイモード（ＳＴＢ１、ＳＴＢ２、ＳＴＢ３）を有するデバイスとして、ＭＣＵ３を例示したが、これに限られず、複数のスタンバイモードを有するデバイスあれば、ＤＳＰやメモリモジュール、アナログＩＣ等であっても良い。

また、電源部２におけるレギュレータ回路２０＿１〜２０＿ｎがＬＤＯである場合を例示したが、ハードウェアリソースに供給すべき電圧値の変更やハードウェアリソースに対する電源電圧の遮断等の制御ができる構成であれば、ＬＤＯに限られず、スイッチングレギュレータやチャージポンプ電源等の別の電源回路であっても良い。

１００ データ処理装置
１ 制御部
２ 電源部
２０＿１〜２０＿ｎ レギュレータ回路
ＶＩＮ＿１〜ＶＩＮ＿ｎ 各ハードウェアリソースに供給される電源電圧
３ マイクロコントローラ（ＭＣＵ）
４＿１、４＿２ センサ部
４０＿１、４０＿２ センサ装置
４１＿１、４１＿２ 増幅器
５ 温度センサ
１０ 演算制御部
１１ 通信部
１２ タイマ部
１３〜１５ 記憶部
１６ タスク／モードレジスタ
ＴＭＩ、ＴＭＩＡ タスク管理情報
ＨＷＩ、ＨＷＩ＿ＴＬ、ＨＷＩ＿ＴＭ、ＨＷＩ＿ＴＨ ハードウェア情報
ＱＵＥ＿ＬＳＴ、ＱＵＥ＿ＬＳＴＡ キューリスト
リスト３１＿０、３１＿１、３２＿０、３２＿１
ＤＡＭＰ 差動増幅器
ＰＤ ＭＯＳトランジスタ
ＩＢＳ 差動増幅器のバイアス電流

Claims (17)

1. 少なくとも１つのスタンバイモードを有する複数のハードウェアリソースと、
   所定の前記ハードウェアリソースを用いて実現されるタスクの実行と前記ハードウェアリソースの動作状態の制御を行うための制御部と、
   前記制御部からの指示に応じて、各ハードウェアリソースに対する電源の供給を制御する電源部と、を有し、
   前記制御部は、前記タスクを実行するタイミングを決定するための情報に基づいて前記タスクの実行予定時刻のスケジューリングを行うとともに、前記スケジューリングの結果に基づいて前記ハードウェアリソースが次の前記タスクの実行に利用されるまでの待機時間を算出し、算出した前記待機時間と予め設定された当該ハードウェアリソースの前記スタンバイモードによる損益分岐時間とを比較することによって、当該ハードウェアリソースをスタンバイモードに遷移させるか否かを、前記ハードウェアリソース毎に決定し、
   前記タスクを実行するタイミングを決定するための情報は、前記タスクを実行する周期を示す情報と、前記タスクの実行時間を示す情報と、前記タスクの実行に用いられる前記ハードウェアリソースを指示する情報であるリソース情報と、を含み、
   前記制御部は、前記タスクを実行する周期に基づいてタスクの実行予定時刻をスケジューリングするとともに、前記リソース情報で指示された所定のハードウェアリソースを使用する所定のタスクの実行完了時刻と前記所定のハードウェアリソースを使用し前記所定のタスクの次に実行されるタスクの実行予定時刻との差分に基づいて前記所定のハードウェアリソースの前記待機時間を算出し、
   前記実行完了時刻は、前記所定のハードウェアリソースを使用するタスクの実行開始時刻に前記タスクの実行時間を加算することで算出され、
   前記複数のハードウェアリソースとして、電源の供給が遮断されない第１スタンバイモードと電源の供給が遮断される第２スタンバイモードとを有するデバイスを含み、
   前記デバイスの前記損益分岐時間として、前記第１スタンバイモードによる第１損益分岐時間と前記第２スタンバイモードによる第２損益分岐時間とを含み、前記第２損益分岐時間は、前記第１損益分岐時間よりも大きくされ、
   前記制御部は、前記デバイスをスタンバイモードに遷移させるとき、前記算出した前記デバイスの待機時間が前記第１損益分岐時間より大きく前記第２損益分岐時間より小さい場合に、前記デバイスを前記第１スタンバイモードに遷移させ、前記算出した前記デバイスの待機時間が前記第２損益分岐時間より大きい場合に、前記デバイスを前記第２スタンバイモードに遷移させる、データ処理装置。
2. 請求項１において、
   前記デバイスは、マイクロコントローラである、データ処理装置。
3. 請求項１において、
   前記制御部は、前記スケジューリングされた所要のタスクの実行開始予定時刻と、その次に実行予定のタスクの実行開始予定時刻との時間間隔が短くなるように、前記所要のタスクの実行予定時刻を所定の時間範囲内で変更可能にされる、データ処理装置。
4. 請求項３において、
   前記タスクを実行するタイミングを決定するための情報は、前記タスクを実行すべき周期に対してずらすことが可能な時間を示す猶予時間の情報を、更に含み、
   前記制御部は、スケジューリングされた前記所要のタスクの実行開始予定時刻を基点として前記猶予時間の範囲内に前記その次に実行予定のタスクの実行がスケジューリングされている場合に、前記所要のタスクに連続して前記その次に実行予定のタスクが実行されるように、前記所要のタスクの実行予定時刻を変更する、データ処理装置。
5. 請求項１において、
   前記スタンバイモードによる損益分岐時間が温度情報に対応して複数設定され、
   前記制御部は、入力された温度情報に基づいて何れか一つの前記損益分岐時間を選択し、選択した前記損益分岐時間を用いて、前記ハードウェアリソースをスタンバイモードに遷移させるか否かの決定を行う、データ処理装置。
6. 請求項１において、
   前記電源部は、前記ハードウェアリソースに電源電圧を供給するためのレギュレータ回路を夫々のハードウェアリソースに対応させて複数有し、
   前記制御部は、前記ハードウェアリソースをスタンバイモードに遷移させるとき、当該ハードウェアリソースに対応する前記レギュレータ回路の回路電流が小さくなるように制御する、データ処理装置。
7. 請求項６において、
   前記制御部は、前記デバイスを前記第２スタンバイモードに遷移させる場合に、前記デバイスに対応する前記レギュレータ回路の動作電流を遮断するように制御し、前記デバイスを前記第１スタンバイモードに遷移させる場合に、前記デバイスに対応する前記レギュレータ回路の動作電流が通常時よりも小さくなるように制御する、データ処理装置。
8. 請求項２において、
   前記タスクとして、前記マイクロコントローラが外部から周期的にデータを受信する第１タスクを含み、
   前記マイクロコントローラは、前記第１タスクの実行によって所要のタイミングで受信したデータとそれ以前のタイミングで受信したデータとの変化量を算出し、その変化量が所定の閾値を超えない場合に、前記第１タスクの実行周期が長くなるように、前記タスクを実行するタイミングを決定するための情報を更新する、データ処理装置。
9. 少なくとも１つのスタンバイモードを有する複数のハードウェアリソースと、
   所定の前記ハードウェアリソースを用いて実現されるタスクの実行と前記ハードウェアリソースの動作状態の制御を行うための制御部と、
   前記制御部からの指示に応じて、各ハードウェアリソースに対する電源の供給を制御する電源部と、を有し、
   前記制御部は、前記タスクを実行するタイミングを決定するための情報に基づいて前記タスクの実行予定時刻のスケジューリングを行うとともに、前記スケジューリングの結果に基づいて、所定の前記ハードウェアリソースに対する電源の供給と当該ハードウェアリソースに対する前記タスクの実行を指示し、
   前記制御部は、前記タスクを実行するタイミングを決定するための情報に基づいて前記タスクの実行予定時刻のスケジューリングを行うとともに、前記スケジューリングの結果に基づいて前記ハードウェアリソースが次の前記タスクの実行に利用されるまでの待機時間を算出し、算出した前記待機時間と予め設定された当該ハードウェアリソースの前記スタンバイモードによる損益分岐時間とを比較することによって、当該ハードウェアリソースを通常動作よりも消費電力が低いスタンバイモードに遷移させるか否かを、前記ハードウェアリソース毎に決定し、
   前記制御部は、前記スケジューリングされた、所要のタスクの実行開始予定時刻と、その次に実行予定のタスクの実行開始予定時刻との時間間隔が短くなるように、前記所要のタスクの実行予定時刻を所定の時間範囲内で変更可能にされる、データ処理装置。
10. 請求項９において、
    前記タスクを実行するタイミングを決定するための情報は、前記タスクを実行する周期と、前記タスクの実行時間と、前記タスクの実行に用いられる前記ハードウェアリソースを指示するリソース情報と、前記タスクを実行すべき周期に対してずらすことが可能な時間を示す猶予時間とを、含み、
    前記制御部は、前記タスクを実行する周期に基づいてタスクの実行予定時刻をスケジューリングするとともに、前記スケジューリングされた所定のタスクの実行開始予定時刻を基点として、前記猶予時間の範囲内に別のタスクの実行がスケジューリングされている場合に、前記所定のタスクに連続して前記別のタスクが実行されるように、前記所定のタスクの実行予定時刻を変更する、データ処理装置。
11. 請求項１０において、
    前記制御部は、前記スケジューリングの結果に基づいて前記ハードウェアリソースが次の前記タスクの実行に利用されるまでの待機時間を算出するとともに、算出した前記待機時間と予め設定された当該ハードウェアリソースの前記スタンバイモードによる損益分岐時間とを比較することによって、当該ハードウェアリソースをスタンバイモードに遷移させるか否かを、前記ハードウェアリソース毎に決定する、データ処理装置。
12. 請求項１１において、
    前記制御部は、前記リソース情報で指示された所定のハードウェアリソースを使用する所定のタスクの実行完了時刻と前記所定のハードウェアリソースを使用し前記所定のタスクの次に実行されるタスクの実行予定時刻との差分に基づいて前記所定のハードウェアリソースの前記待機時間を算出し、
    前記実行完了時刻は、前記所定のハードウェアリソースを使用するタスクの実行開始時刻に前記タスクの実行時間を加算することで算出される、データ処理装置。
13. 請求項１１において、
    前記ハードウェアリソースとして、電源の供給が遮断されない第１スタンバイモードと電源の供給が遮断される第２スタンバイモードとを有するマイクロコントローラを含み、
    前記マイクロコントローラの前記損益分岐時間として、前記第１スタンバイモードによる第１損益分岐時間と前記第２スタンバイモードによる第２損益分岐時間とを含み、前記第２損益分岐時間は、前記第１損益分岐時間よりも大きくされ、
    前記制御部は、前記マイクロコントローラをスタンバイモードに遷移させるとき、前記算出した前記マイクロコントローラの待機時間が前記第１損益分岐時間より大きく前記第２損益分岐時間より小さい場合に、前記マイクロコントローラを前記第１スタンバイモードに遷移させ、前記算出した前記マイクロコントローラの待機時間が前記第２損益分岐時間より大きい場合に、前記マイクロコントローラを前記第２スタンバイモードに遷移させる、データ処理装置。
14. 請求項１１において、
    前記スタンバイモードによる損益分岐時間が温度情報に対応して複数設定され、
    前記制御部は、入力された前記温度情報に基づいて何れか一つの前記損益分岐時間を選択し、選択した前記損益分岐時間を用いて、前記ハードウェアリソースをスタンバイモードに遷移させるか否かの決定を行う、データ処理装置。
15. 請求項１３において、
    前記電源部は、前記ハードウェアリソースに電源電圧を供給するためのレギュレータ回路を夫々のハードウェアリソースに対応させて複数有し、
    前記制御部は、前記ハードウェアリソースをスタンバイモードに遷移させるとき、当該ハードウェアリソースに対応する前記レギュレータ回路の回路電流が小さくなるように制御する、データ処理装置。
16. 請求項１５において、
    前記制御部は、前記マイクロコントローラを前記第１スタンバイモードに遷移させる場合に、前記マイクロコントローラに対応する前記レギュレータ回路の動作電流を遮断するように制御し、前記マイクロコントローラを前記第２スタンバイモードに遷移させる場合に、前記マイクロコントローラに対応する前記レギュレータ回路の動作電流が通常時よりも小さくなるように制御する、データ処理装置。
17. 請求項１１において、
    前記ハードウェアリソースとして、マイクロコントローラを含み、
    前記タスクとして、前記マイクロコントローラが外部から周期的にデータを受信する第１タスクを含み、前記マイクロコントローラは、前記第１タスクの実行によって所要のタイミングで受信したデータとそれ以前のタイミングで受信したデータとの変化量を算出し、その変化量が所定の閾値を超えない場合に、前記第１タスクの実行周期が長くなるように、前記タスクを実行するタイミングを決定するための情報を更新する、データ処理装置。

Images