JP5188468B2

JP5188468B2 - 電力制御情報生成装置および電力制御装置

Info

Publication number: JP5188468B2
Application number: JP2009159936A
Authority: JP
Inventors: 正志森; 宏明堺; 哲石坂; 竜海曽山
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2009-07-06
Filing date: 2009-07-06
Publication date: 2013-04-24
Anticipated expiration: 2029-07-06
Also published as: JP2011014089A

Description

本発明は、制御対象機器の低消費電力化実現のための電力制御情報を生成する電力制御情報生成装置およびこれを利用した制御を実施する電力制御装置に関する。

電子機器等においては、低消費電力化の実現が課題の一つとなっており、特に、電池によって駆動される機器では、非常に重要視されている。回路設計や組み込みソフトウェアの設計においては、可能な限り低消費電力化が図れるように考慮しながら作業が進められる。低消費電力化を実現するにあたっては、ハードウェアリソースの適切な制御が重要である。従来のハードウェアリソースの制御技術は、たとえば、下記特許文献１に記載されている。

特表２００６−５２３３３９号公報

しかしながら、従来の組み込システムでは、以下に示すような解決すべき課題が存在する。まず、ＯＳには電力制御を行うためのモジュールを持っているが、アプリケーションが複雑なＡＰＩを操作しているシステム、すなわち構造が複雑なシステムでは、消費電力の見積りを行うことが困難であり、きめ細かな電力制御の実現が困難である（十分な省電力化の実現が困難である）、という問題があった。

またシステム全体の制御の複雑化に伴い、ある機能を実現するのに必要最小限のリソースは何であるかが不明確となり、機能を確実に実現するためには、必要以上にリソースを使用する必要があった。すなわち、消費電力が必要以上に大きくなってしまう、という問題があった。

また、電力制御処理の制御構造自体が明確になっていないため、電力制御処理自体のメンテナンスが困難となり、省電力化が不十分なケースが発生する、という問題があった。

また、ソフトウェアは複数のプロセスから成り立っているが、プロセス内部でリソースの利用順序を固定化しているため、システム全体としてのリソース管理・スケジューリング制御の最適化が図れるようになっていない。その結果、消費電力削減の最適化が達成できない場合がある、という問題があった。

本発明は、上記に鑑みてなされたものであって、大規模なシステムなどにおいても低消費電力化が実現可能な電力制御情報を生成する電力制御情報生成装置および電力制御装置を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、複数のアプリケーションが利用可能な複数のハードウェアリソースにより構成された制御対象機器の電力制御のための情報を生成する電力制御情報生成装置であって、各アプリケーションの基本動作についての状態遷移図（第１の状態遷移図）と、前記複数のハードウェアリソースの電力制御動作における状態遷移が各状態の消費電力レベルに基づいて階層化されて記載された状態遷移図（第２の状態遷移図）と、各アプリケーションの基本動作における各状態と前記各ハードウェアリソースの電力制御動作における各状態の対応テーブル（第１のテーブル）と、に基づいて、各アプリケーションの電力制御動作における状態遷移図（第３の状態遷移図）と、各アプリケーションの基本動作における状態遷移事象と各アプリケーションの電力制御動作における状態遷移事象の対応テーブル（第２のテーブル）と、を生成する電力制御情報生成手段、を備えることを特徴とする。

本発明によれば、システムや制御が複雑化した機器における省電力化の実現が可能となる、という効果を奏する。

図１は、階層化された消費電力レベルを説明するための図である。図２は、消費電力レベルで階層化された状態遷移図を説明するための図である。図３は、本発明にかかる電力制御情報生成装置の実施の形態１の構成および全体動作を示す図である。図４は、電力制御情報生成部の動作を示す図である。図５は、電力制御情報生成部が実行する動作手順を示すフローチャートである。図６は、電力見積もり部の動作を示す図である。図７は、電力見積もり部が実行する動作手順を示すフローチャートである。図８は、電力制御情報生成装置の動作を示す図である。図９は、電力制御情報生成部の情報の入出力関係を示す図である。図１０は、電力見積もり部の情報の入出力関係を示す図である。図１１は、電力制御装置の構成および動作の一例を示す図である。図１２は、電力制御装置が実行する動作手順を示すフローチャートである。図１３は、電力制御装置の他の動作例を示す図である。図１４は、図１３の電力制御装置が実行する動作手順を示すフローチャートである。図１５は、電力制御装置の変形例および動作例を示す図である。図１６は、図１５の電力制御装置が実行する動作手順を示すフローチャートである。図１７は、実施の形態３の電力制御情報生成装置の構成例を示す図である。図１８は、消費電力調停部の動作を示す図である。図１９は、同期イベント変換部の動作を説明するための図である。図２０は、同期イベント変換部の動作を説明するための図である。図２１は、同期イベント変換部の動作を説明するための図である。図２２は、電力制御情報生成装置の他の構成例を示す図である。図２３は、リソース見積もり部の動作を説明するための図である。図２４は、電力制御装置の他の構成例を示す図である。図２５は、本発明の効果を説明するための図である。図２６は、本発明の効果を説明するための図である。

以下に、本発明にかかる電力制御情報生成装置および電力制御装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

ここでまず、以下の説明で使用する表現、言葉の定義などについて説明する。本明細書においては、アプリケーションの動作は状態遷移図を用いて表現する。

具体的には、状態遷移図ＳＴをＳＴ＝＜Ｓ，Ｅ，ｉ，ｄ＞と表現し、Ｓはとり得る状態ｓの集合、Ｅは発生しうる状態遷移事象ｅの集合、ｉはＳの要素（ｓ）の中の初期状態（動作開始時の状態）を示す。またｄは状態遷移事象を示す関数であり、（ｓ₁，ｅ₁）＝ｓ₂は、状態ｓ₁で状態遷移事象ｅ₁が発生すると状態ｓ₂となること（ｓ₁からｓ₂への遷移動作）を示している。当然、ある状態ｓで発生し得ない状態遷移事象も存在し、その場合、ｄ（ｓ，ｅ）＝＜無効＞と表現する。これは、状態ｓにおいて状態遷移事象ｅは想定していない（状態遷移事象ｅは状態ｓで発生し得ない）ことを示す。

なお、以下の説明では、状態遷移図ＳＴに対してＳＴ(Ｓ)，ＳＴ(Ｅ)，ＳＴ(ｉ)，ＳＴ(ｄ)をそれぞれ、ＳＴ(Ｓ)＝Ｓ，ＳＴ(Ｅ)＝Ｅ，ＳＴ(ｉ)＝ｉ，ＳＴ(ｄ)＝ｄを意味することとする。また、ｅ_x＝＜ｅ₀,ｅ₁,…,ｅ_n＞（ｅ₀,ｅ₁,…,ｅ_nはＥの要素）のような状態遷移事象の列に対応する状態遷移も考えられ、この場合ｄの定義を拡張して、ｄ(ｓ,ｅ_x)＝ｄ(…ｄ(ｄ(ｓ,ｅ₀),ｅ₁),…,ｅ_n)を示すものとする。

また、確率構造Ｐというときは、Ｐ：［０，∞）×Ｅ→［０，１］として、Ｐ(ｔ，ｅ)は、ある時点ｔで状態遷移事象ｅが発生する確率とする。

次に、以下の説明で必要となる概念について説明する。

＜アプリケーションがその上で動作するハードウェア（Ｈ／Ｗ）の電力制御状態（消費電力レベル）の概念＞
消費電力レベルは、アプリケーションが利用するＨ／Ｗの動作状態（動作中／動作停止中）、動作周波数（ＭＨｚ）、消費電力（ｍＷ）などの状態を示す。別の言い方をすれば、他のＨ／Ｗへのサービス提供可能性を意味している。

たとえば２つの消費電力レベルａ，ｂがある場合において、消費電力レベルａが消費電力レベルｂより「大きいか等しい」（ａ≧ｂ）とは、消費電力レベルｂで提供可能なサービスがすべて消費電力レベルａで提供可能であることを意味する。なお、便宜上、消費電力レベルの最大を‘１’，最小を‘０’で表現する。この場合、任意の消費電力レベルａについて１≧ａ≧０である。

消費電力レベルには順序づけがされているものとする。ある消費電力レベルと他の消費電力レベルが必ずしも比較できるとは限らないが、任意のレベルａ，ｂに対して、ｃ≧ａ，ｃ≧ｂとなるレベルｃとａ≧ｄ，ｂ≧ｄとなるレベルｄが存在することを仮定する。このとき、全ての消費電力レベルａ，ｂに対してａ≧ｂかｂ≧ａのどちらかが成り立つ場合を「全順序」という。多くの場合にはこの条件が当てはまる。全順序でない場合を想定するのは、Ｈ／Ｗが複数のモジュールから構成されており、それぞれのモジュール毎に動作状態（動作中／動作停止中）、動作周波数、動作電圧などが自由に変えられる場合にも対応させるためである。このようなＨ／Ｗが複数のモジュールから構成され、モジュールごとに設定が可変な条件下で消費電力レベルを表現するには「全順序」でない場合も考慮する必要がある。

通常は最低でも「モードなし（０＝１）」すなわち消費電力レベルが一定か「すべての機能をサポートするモードが‘１’(最大)、まったく動作しない状態が‘０’(最小)」になっているため、この条件は満たされている。なお、電力制御動作の任意の状態から任意の状態へ遷移させることが可能であるとする。ただし、直接、任意の状態から任意の状態に遷移させることが可能であるとは限らず、他の状態（複数の状態ということもありうる）を経由して初めて可能という場合もありうる。したがって、一般には電力制御動作の任意の状態から任意の状態への状態遷移は状態遷移事象列として表現される。

各デバイスドライバについて、消費電力レベルは下記の（１）〜（３）の観点で順序の階層を定義する。
（１）機能、サービスの種類や数で順序づけて階層化する。
（２）性能の高低、例えば、機能を実行するレスポンス時間、処理時間の長短で順序づけて階層化する。
（３）使用するリソースの大小で機能を順序づけて階層化する。

たとえば、各消費電力レベルを以下のように階層化する。なお、同一レベル内に複数の状態が存在する場合、上述したとおり‘１’が最大、‘０’が最小を示している（レベル１〜レベル３については図１参照）。
レベル１：動作電圧(V)
高性能（１）＝3.3，1.8，0.8(V)，電源OFF＝低性能（０）
レベル２：動作クロック周波数(MHz)
高性能（１）＝600，480，400，200，100(MHz)＝低性能（０）
レベル３：レベル１とレベル２に含まれる状態のうち設定可能な組み合わせ
レベル４：サポートするデータフォーマット（画像解像度、ＡＤ／ＤＡ変換精度など）
レベル５：ＤＭＡ転送（性能、機能）
レベル６：サポートする関数（複数）の包含関係
レベル７：オブジェクト指向言語でのクラスの継承関係

＜リソースの概念＞
「リソース」とは、アプリケーションが必要とする機能を提供するＨ／Ｗやデバイスドライバであり、これらは、消費電力レベルで階層化された状態遷移図が予め定義されているものとする。また、この状態遷移図には、機能提供可能性や機能維持や機能提供に必要な時間や消費電力が（場合によっては確率的に）定義されているものとする。本明細書においては、便宜的に、アプリケーションやリソースが「(別のある)リソースを確保する」とは、（ある消費電力レベルを）リソースに対して要求することを意味するものとする。また、「（別のある）リソースを解放する」とは、（ある）リソースに対する要求を取り下げることを意味するものとする。また、「（別のある）リソースを保持する」とは、ある状態遷移について、遷移前の状態や遷移に対応付けられた処理（状態遷移の発生に伴い実行される処理）でリソースを確保した場合にその要求をそのまま変更しないことを意味するものとする。

＜リソースが公開された遷移に対応付けられた処理の概念＞
「リソースが公開された遷移に対応付けられた処理」とは、状態遷移図で示した遷移が発生した場合に実行されるべき処理であって、処理を実行するために必要なリソース（一般には複数）と、必要なリソースの順番の制約条件とが外部から見えるようになっている処理である。加えて、必要なリソースの順番を制約条件の元で外部から変更することが可能な処理である。

＜消費電力レベルで階層化された状態遷移図＞
「消費電力レベルで階層化された状態遷移図」とは、以下の各条件を満たす状態遷移図である（図２参照）。
（条件１）
状態遷移図の各状態が機能提供可能性の高低で順序づけられていて、順序が束順序になっている。
（条件２）
状態遷移図の各状態に対して、状態に対応する処理を実行する場合の遷移(service)と処理を実行しないがこの状態を維持するのに必要な動作を表現する遷移(hold)が定義されている。
（条件３）
上記（条件１）に従って順序付けされている各状態のうち、隣接する２つの状態に対して消費電力レベルの低い状態から高い状態への遷移(upper)あるいはその逆の遷移(lower)が定義されている。
（条件４）
上記（条件３）で定義された遷移の中のupperに対応する低い状態（遷移前の状態）では実現できないが高い状態（遷移後の状態）では実現できる機能を実施する（holdあるいはserviceを可能にする）ために必要な最小限の初期化処理が定義されており、lowerに対してはその機能の終了処理（高い状態から低い状態へ遷移する際に実行する処理）が定義されている。少なくとも、初期化処理の定義には該当する機能を実施するために必要な最小限のリソースの情報が含まれるものとする。終了処理の定義には、該当する機能（遷移(lower)前の状態では実現可能だが遷移後の状態では実施できないため終了する機能）で必要としていたリソースの情報が含まれていてもよいし含まれていなくてもよい。含まれていない場合には、遷移前後の各状態から特定可能なupperに対応する初期化処理から同様の情報が取得可能なので、それを利用すればよい。

＜リソース確保・解放が対応付けられた消費電力レベルで階層化された状態遷移図＞
「リソース確保・解放が対応付けられた消費電力レベルで階層化された状態遷移図」とは、消費電力レベルに応じて階層化された状態遷移図である。また、この状態遷移図には、以下の各条件を満たす動作についての情報も含まれる（図２参照）。
（条件Ａ）低い状態のholdで保持しているリソースは一般には高い状態へのupperでも保持し、高い状態のserviceやholdでも保持する。
（条件Ｂ）upperで確保し、保持しているリソース（高い状態へ遷移する際に確保してそのまま保持していたリソース）は当該upperに対応するlower発生時（upperと逆方向の状態遷移時）に解放する。なお、upper発生時に確保したリソースのうち保持する必要がなくなったものはupperで解放する。
（条件Ｃ）lower（消費電力レベルが低い階層）で確保したリソースはlowerで解放する。hold，serviceで確保したリソースは一般にはそれぞれholdやserviceで解放するがそうでない場合はlowerで解放する。

＜消費電力レベル遷移のリソースが公開された状態遷移図の概念＞
「消費電力レベル遷移のリソースが公開された状態遷移図」とは、リソースの確保と解放が対応付けられた消費電力レベルで階層化された状態遷移図であって、遷移に対応付けられた処理が、リソースが公開された遷移に対応付けられた処理であるものとする。

また、本発明にかかる電力制御情報生成装置および電力制御装置の具体的な動作説明においては、以下のような略語を使用する。

＜ＡｐｐＳ＞
「ＡｐｐＳ」は「アプリケーションの基本動作の状態遷移図（アプリケーションの基本動作を表現した状態遷移図）」である。ここで、「アプリケーションの基本動作」とは、アプリケーションがＨ／Ｗを考慮せずに設計する動作であり、後述する電力制御動作は含まない。また、Ｈ／Ｗを考慮せずに設計する動作の状態遷移図であるため、消費電力レベルやリソース等に関する情報は一切含まない。ただし、この状態遷移図に記載された各状態（ＡｐｐＳの各要素）について、各状態で動作するために必要な最小限の、Ｈ／Ｗにおける電力制御動作の状態遷移図（詳細は後述する）に記載された各状態との対応付けが予め行われ、それ（対応関係）を示したテーブル（詳細は後述する）が別途用意されているものとする。すなわち、ＡｐｐＳに含まれる各状態（アプリケーションの動作状態）は、Ｈ／Ｗにおける電力制御動作の状態遷移図に含まれる状態（Ｈ／Ｗの電力制御状態）のうち、アプリケーションの動作状態を必要最小限の消費電力で実施可能な電力制御状態と予め対応付けされている。

＜ＡｐｐＰ＞
「ＡｐｐＰ」は「アプリケーションの基本動作に含まれる状態遷移事象の確率構造」である。

＜ＰｏｗＳ＞
「ＰｏｗＳ」は「アプリケーションが動作する際に利用するＨ／Ｗの電力制御動作の状態遷移図」であり、上記ＡｐｐＳの説明で示した「Ｈ／Ｗにおける電力制御動作の状態遷移図」に相当する。

＜ＡｐｐＰｏｗＭｉｎ＞
「ＡｐｐＰｏｗＭｉｎ」は「状態遷移図ＡｐｐＳに記載された各状態を、状態遷移図ＰｏｗＳに記載された状態のいずれかと対応させるテーブル」であり、このテーブル（ＡｐｐＳの各状態とＰｏｗＳの各状態との対応関係）は、ＡｐｐＳの各状態が必要最小限の消費電力で実行されるように考慮して決定されたものである。

＜ＡｐｐＰｏｗＳ＞
「ＡｐｐＰｏｗＳ」は「アプリケーションの電力制御動作の状態遷移図」であり、本発明にかかる電力制御情報生成装置により生成される。

＜ＡｐｐＰｏｗＥ＞
「ＡｐｐＰｏｗＥ」は「アプリケーションの基本動作に含まれる状態遷移事象とアプリケーションの電力制御動作に含まれる状態遷移事象とを対応させるテーブル」すなわち、上記ＡｐｐＳに記載された状態遷移事象と上記ＡｐｐＰｏｗＳに記載された状態遷移事象との対応関係を示したテーブルであり、本発明にかかる電力制御情報生成装置により生成される。

＜ＡｐｐＰＴ＞
「ＡｐｐＰＴ」は「アプリケーションの電力制御動作の状態遷移図（上記ＡｐｐＰｏｗＳ）に記載された各状態と状態保持時間見積もりとを対応させるテーブル」であり、本発明にかかる電力制御情報生成装置により生成される。

＜ＡｐｐＰＨ＞
「ＡｐｐＰＨ」は「アプリケーションの電力制御動作の状態遷移図（上記ＡｐｐＰｏｗＳ）に記載された各状態に対するある一定時間前までの状態保持時間の履歴」であり、本発明にかかる電力制御情報生成装置により生成される。この情報は、ＡｐｐＰｏｗＳに記載された各状態についての状態保持時間見積もり結果のうち、一定時間前から現在までの間に得られた見積もり結果の集合として表される。

＜ＰｏｗＳ＿ＳＰ＞
「ＰｏｗＳ＿ＳＰ」は「アプリケーションが動作する際に利用するＨ／Ｗの電力制御動作の状態遷移図（上記ＰｏｗＳ）に記載された各状態に対応する消費電力（各状態における消費電力）が記録されたテーブル」である。

＜ＰｏｗＳ＿ＥＰ＞
「ＰｏｗＳ＿ＥＰ」は「アプリケーションが動作する際に利用するＨ／Ｗの電力制御動作の状態遷移図（上記ＰｏｗＳ）に記載された各状態遷移事象に対応する消費電力が記録されたテーブル」である。

＜ＡｐｐＰｏｗＰ＞
「ＡｐｐＰｏｗＰ」は「アプリケーションの電力制御動作に含まれる状態遷移事象の確率構造」であり、本発明にかかる電力制御情報生成装置により生成される。

＜Ｅ（ＡｐｐＰｏｗＰ）＞
「Ｅ（ＡｐｐＰｏｗＰ）」は「アプリケーションの電力制御動作に対応する消費電力見積もり値」であり、本発明にかかる電力制御情報生成装置により生成される。

つづいて、本発明にかかる電力制御情報生成装置の実施の形態について説明する。

実施の形態１．
図３は、本発明にかかる電力制御情報生成装置の実施の形態１の構成および全体動作を示す図である。図示したように、本実施の形態の電力制御情報生成装置は、電力制御情報生成部１および電力見積もり部２を備える。

また、図示したように、電力制御情報生成部１は、上述したＡｐｐＳ、ＰｏｗＳおよびＡｐｐＰｏｗＭｉｎの各情報を入力として、これらの入力情報に基づき、上述したＡｐｐＰｏｗＳおよびＡｐｐＰｏｗＥを生成する。

電力見積もり部２は、上述したＡｐｐＰ、ＰｏｗＳ、ＰｏｗＳ＿ＥＰおよびＰｏｗＳ＿ＳＰの各情報と、電力制御情報生成部１の出力とを入力として、これらの入力情報に基づき、上述したＡｐｐＰｏｗＰおよびＥ（ＡｐｐＰｏｗＰ）を生成する。

図４は、電力制御情報生成部１の動作を示す図であり、図５は、電力制御情報生成部１が実行する動作手順を示すフローチャートである。また、図６は、電力見積もり部２の動作を示す図であり、図７は、電力見積もり部２が実行する動作手順を示すフローチャートである。これらのフローチャートに基づき各部における詳細動作を説明する。

図４に示したように、電力制御情報生成部１には、ＡｐｐＳ、ＰｏｗＳおよびＡｐｐＰｏｗＭｉｎが入力され、これらの入力情報に基づき生成されたＡｐｐＰｏｗＳおよびＡｐｐＰｏｗＥが出力される。すなわち、図５に示したように、電力制御情報生成部１では、まず、状態遷移図ＡｐｐＰｏｗＳを構築して出力する（ステップＳ１）。具体的には、入力された状態遷移図ＡｐｐＳに記載された各状態および状態遷移事象を、状態遷移先の違いを考慮しつつテーブルＡｐｐＰｏｗＭｉｎの値に基づき分類して同値類を作成する。ＡｐｐＳ（Ｓ），ＡｐｐＳ（Ｅ）の同値類をそれぞれＡｐｐＰｏｗＳ（Ｓ），ＡｐｐＰｏｗＳ（Ｅ）とするが、ＡｐｐＰｏｗＳ（ｄ）も、ＡｐｐＰｏｗＳ（Ｓ），ＡｐｐＰｏｗＳ（Ｅ）上に矛盾せずに自然に定めることができる。生成された状態遷移図ＡｐｐＰｏｗＳは、上述した「消費電力レベルで階層化された状態遷移図」となる（図２参照）。

ステップＳ１にてＡｐｐＰｏｗＳを構築すると、電力制御情報生成部１は、次に、テーブルＡｐｐＰｏｗＥを作成して出力する（ステップＳ２）。ここで、上述したＡｐｐＰｏｗＳを構築する処理の途中で得られるＡｐｐＳ（Ｅ）からＡｐｐＰｏｗＳ（Ｅ）への同値類の分類結果を記録したテーブルがＡｐｐＰｏｗＥとなるので、ステップＳ１を実行する際に併せて作成しておけばよい。

また、図６に示したように、電力見積もり部２には、電力制御情報生成部１から出力された情報であるＡｐｐＰｏｗＳおよびＡｐｐＰｏｗＥと、ＡｐｐＰ、ＰｏｗＳ、ＰｏｗＳ＿ＥＰおよびＰｏｗＳ＿ＳＰとが入力され、これらの入力情報に基づき生成されたＡｐｐＰｏｗＰおよびＥ（ＡｐｐＰｏｗＰ）が出力される。すなわち、図７に示したように、電力見積もり部２では、まず、確率構造ＡｐｐＰｏｗＰを構築する（ステップＳ３）。ここで、既に説明したように、電力制御情報生成部１では、ＡｐｐＳをＡｐｐＰｏｗＭｉｎの値によって分類することによってＡｐｐＰｏｗＳを作成している。そのため、ＡｐｐＰｏｗＳ（Ｅ）もＡｐｐＳ（Ｅ）を同値類に分類したものになっており、このことから、ＡｐｐＰｏｗＳ（Ｅ）を電力制御情報生成部１から受け取り、ＡｐｐＰをもとに同じ同値類に含まれる状態遷移事象の確率値の総和をとって同値類の確率値にすることによりＡｐｐＰｏｗＰを構築する。

ステップＳ３にてＡｐｐＰｏｗＰを構築すると、電力見積もり部２は、次に、消費電力見積もり値Ｅ（ＡｐｐＰｏｗＰ）を計算する（ステップＳ４）。上記ステップＳ３にてＡｐｐＰｏｗＰが構築されているので、これを測度として、ＰｏｗＳ＿ＥＰ，ＰｏｗＳ＿ＳＰの値を（時間方向およびＥ方向の両方に）積分（あるいは総和）することによりＥ（ＡｐｐＰｏｗＰ）が得られる。

このように、電力制御情報生成装置において、電力制御情報生成部１は、ＡｐｐＰｏｗＳ，ＡｐｐＰｏｗＥを生成するので、アプリケーションの基本動作において状態が変化（遷移）した場合、これに伴ってアプリケーションの電力制御動作の状態がどのように変化するか（または変化しないのか）が明確化され、電力制御処理のメンテナンスが容易化され、省電力化が実現可能となる。また、電力見積もり部２がＡｐｐＰｏｗＰ，Ｅ（ＡｐｐＰｏｗＰ）の算出すなわち消費電力の見積りを行うので、これを利用した省電力制御（省電力化）が実現可能となる。

なお、図８に示したように、電力制御情報生成装置（電力制御情報生成部１）は、上述したＡｐｐＰｏｗＳ，ＡｐｐＰｏｗＥに加えて、ＡｐｐＰＴも併せて生成するようにしてもよい。この場合、電力制御情報生成部１は、上述したステップＳ１およびＳ２の処理に加え、次の処理を実行してＡｐｐＰＴを生成する。すなわち、Ｘ（ｐ,ｓ）＝｛（ｔ,ｅ）|状態遷移事象ｅ、終了時間がｔ、状態がｓで、時間ｔ以降ｔ＋ｐまでに状態遷移は発生していない｝と定義し、ｐ，ＡｐｐＰｏｗＰを測度としてＸ（ｐ,ｓ）の測度値をＥ（ｐ,ｓ）とする。そして、ｐを動かして和（あるいは積分）をとったΣ(ｐ×Ｅ(ｐ,ｓ))をＡｐｐＰＴ（ｓ）とすることによりＡｐｐＰＴを生成する。

また、図８に示した動作を実行する場合、電力見積もり部２では、上記電力制御情報生成部１で生成されたＡｐｐＰＴを考慮しつつＡｐｐＰｏｗＰおよびＥ（ＡｐｐＰｏｗＰ）を算出する。

電力制御情報生成装置が図８に示した動作を実行する場合、電力制御情報生成部１の情報の入出力関係は図９に示したものとなり、また、電力見積もり部２の情報の入出力関係は図１０に示したものとなる。

このように、本実施の形態の電力制御情報生成装置では、アプリケーションの基本動作についての状態遷移図（ＡｐｐＳ）、アプリケーションが利用するＨ／Ｗの電力制御動作についての状態遷移図（ＰｏｗＳ）およびＡｐｐＳに記載された各状態とＰｏｗＳに記載された各状態の対応関係を示したテーブル（ＡｐｐＰｏｗＭｉｎ）に基づいて、アプリケーションの電力制御動作に対応する状態遷移図であって、各状態が、必要とする最小限の消費電力レベル毎に階層化（分類）されている状態遷移図（ＡｐｐＰｏｗＳ）およびＡｐｐＳとＡｐｐＰｏｗＳのそれぞれに含まれる状態遷移事象同士の対応関係を示したテーブル（ＡｐｐＰｏｗＥ）を生成することとした。これにより、アプリケーションの基本動作と電力制御動作との関連が明確化されるので、アプリケーションによる電力制御処理のメンテナンスの困難性を解消することができ、機器（システム）の省電力化を実現できる。

また、ＡｐｐＰｏｗＳおよびＡｐｐＰｏｗＥを利用して消費電力を見積もることとしたので、これを利用した省電力化が実現可能となる。

実施の形態２．
本実施の形態では、実施の形態１で説明した電力制御情報生成装置にて生成される電力制御情報（ＡｐｐＰｏｗＳ，ＡｐｐＰｏｗＥ，ＡｐｐＰＴ）を利用して機器の電力制御を行う電力制御装置について説明する。

図１１は、電力制御装置の構成および動作の一例を示す図であり、上記のＡｐｐＰｏｗＳおよびＡｐｐＰｏｗＥを利用した電力制御を実行する場合の例を示している。また、図１２は、図１１の電力制御装置が実行する動作手順を示すフローチャートである。

図１１の電力制御装置は、状態遷移記憶部３（状態遷移事象変換手段）、状態遷移フィルタ部４（遷移事象列変換手段）および制御実行部５を備え、アプリケーションの基本動作においてある状態遷移事象ｅが発生すると、図１２に示した処理を実行して外部のＨ／Ｗの電力制御部１００を制御する。この電力制御装置の詳細動作を以下に示す。なお、状態遷移フィルタ部４および制御実行部５が電力制御手段を構成する。

図１２に示したように、図１１の電力制御装置では、アプリケーションの基本動作においてある状態遷移事象ｅが発生すると、まず、状態遷移記憶部３が、入力情報であるＡｐｐＰｏｗＳ、ＡｐｐＰｏｗＥおよびＰｏｗＳに基づき、この状態遷移事象ｅを変換する（ステップＳ１１）。具体的には、状態遷移事象ｅを上記入力情報に基づいてＡｐｐＰｏｗＥ（ｅ）すなわち、「アプリケーションの電力制御動作における状態遷移事象」に変換する。ここで、ＰｏｗＳ（ｄ）(ｓ,（ＡｐｐＰｏｗＥ（ｅ））＝＜無効＞（なお、ｓは現在の状態を示す）であれば状態遷移は行わずにここで動作を終了する。そうでなければ現在の状態（これまで記憶していた状態）をこの値（上記変換後の状態遷移事象に対応する状態）に更新する。たとえば、アプリケーションの基本動作で状態遷移が発生してもＨ／Ｗの電力制御動作では状態遷移が発生しない場合には、ここで動作を終了する。

ステップＳ１１にて現在の状態（ｓ）を更新した場合、状態遷移図ＰｏｗＳに記載された任意の状態ｓから他の状態ｓ’へ遷移可能であるから、さらに、上記発生した状態遷移事象ｅに対応するＡｐｐＰｏｗＥ（ｅ）を、状態ｓから状態ｓ’への遷移に対応する状態遷移事象列（Ｈ／Ｗの電力制御動作における状態遷移事象列、含まれる状態遷移事象が１つの場合もある）に変換する（ステップＳ１２）。

ステップＳ１２の処理が終了すると、次に、制御実行部５が、ステップＳ１２で得られた状態遷移事象列に対応する処理を実行する（ステップＳ１３）。すなわち、制御実行部５は、状態遷移事象列の各状態遷移事象を順に実行し、Ｈ／Ｗの電力制御動作の状態を変化させてゆく。この結果、Ｈ／Ｗの電力制御動作の状態は、すべての状態遷移事象の実行が完了した時点の状態に更新される。

以上のステップＳ１１〜Ｓ１３に従った動作を実行することにより、アプリケーションの基本動作の実現に必要なＨ／Ｗを制御する際の消費電力を必要最小限に抑えることができる。

なお、上記ステップＳ１２を次に示すようなステップＳ１２ａ（テーブルＡｐｐＰＴを考慮しつつ状態遷移事象列を生成する処理）に置き換えることも可能である（図１３，図１４参照）。なお、図１３は、電力制御装置の他の動作例を示す図であり、図１４は、図１３の電力制御装置が実行する動作手順を示すフローチャートである。

図１４に示したステップＳ１２ａでは、Ｈ／Ｗの電力制御動作の状態をｐｓ0とすると、ＡｐｐＰｏｗＥ（ｅ）に対応する電力制御動作の任意の状態ｐｓ0から他の状態ｐｓ1へ遷移させることが可能である（ただし、１ステップの状態遷移とは限らず状態遷移事象列の可能性もある）ことから、状態遷移フィルタ部４は、上記発生した状態遷移事象ｅに対応するＡｐｐＰｏｗＥ（ｅ）を、状態ｐｓ0から状態ｐｓ1への遷移に対応する状態遷移事象列（Ｈ／Ｗの電力制御動作における状態遷移事象列、含まれる状態遷移事象が１つの場合もある）に変換する。この状態遷移事象列をすべて実行した後の状態がｐｓ1となる。

また、遷移後の状態ｐｓ1が「（ｐｓ0での消費電力レベル）≧（ｐｓ1での消費電力レベル）」かつｐｓ1に推移させても消費電力を小さくできる効果がないと判断できる場合（各状態での消費電力はＡｐｐＰＴ，ＰｏｗＳ＿ＥＰ，ＰｏｗＳ＿ＳＰを使用して計算する)、「（ｐｓ0での消費電力レベル）≧（ｐｓ1での消費電力レベル）」を満たすｐｓ1のうち、最後に指し示す状態（遷移後の状態）がｐｓ1になる状態遷移事象列でもっとも消費電力が小さくなるものを選択する（これもＡｐｐＰＴ，ＰｏｗＳ＿ＥＰ，ＰｏｗＳ＿ＳＰを使って消費電力を計算して判断する)。そうでない場合は、もとの状態遷移事象列を選択する。すなわち、状態ｐｓ0から状態ｐｓ1へ遷移可能な状態遷移事象列が複数存在する場合には、状態遷移事象列に含まれる各状態遷移事象に従って動作した場合の消費電力が最小となる状態遷移事象列を選択する。具体的には、「（ｐｓ0での消費電力レベル）≧（ｐｓ1での消費電力レベル）」を満たすｐｓ1と最後に指し示す状態がｐｓ1になる状態遷移事象列ｅｘとを使用し、すべてのｐｓ1とｅｘの組合せに対して、ＰｏｗＳ＿ＥＰ（ｅｘ）＋ＰｏｗＳ＿ＳＰ（ｐｓ1）を計算し、ＰｏｗＳ＿ＳＰ（ｐｓ0）より小さくなるｐｓ1とｅｘの組合せがあればそれを選択し、そうでない場合は、もとの状態遷移列を選択する。

またさらに、上記ステップＳ１１，Ｓ１２ａ，Ｓ１３を実行した後、次に示すようなステップＳ１４を実行するようにしてもよい（図１５，図１６参照）。なお、図１５は、電力制御装置の変形例および動作例を示す図であり、図１６は、図１５の電力制御装置が実行する動作手順を示すフローチャートである。この電力制御装置は、図１１や図１３で示した電力制御装置に対して、状態遷移フィルタ部４が使用するＡｐｐＰＴを更新する状態保持時間見積もり部６を追加したものである。

図１６に示したステップＳ１４では、状態保持時間見積り部６が、ＡｐｐＰＨ（ｓ）を最新の値に更新し、更新後のＡｐｐＰＨ（ｓ）に基づいて、たとえば移動平均的にＡｐｐＰＴ（ｓ）を更新する。

このように、本実施の形態の電力制御装置は、実施の形態１で示した電力制御情報生成装置にて生成された情報に基づいて、アプリケーションが基本動作で利用するＨ／Ｗの電力制御を行うこととした。これにより、必要最小限の消費電力で機器を制御することができる。

実施の形態３．
本実施の形態では実施の形態１とは異なる構成の電力制御情報生成装置について説明する。図１７は、実施の形態３の電力制御情報生成装置の構成例を示す図である。この電力制御情報生成装置は、消費電力レベル調停部７、消費電力レベル遷移変換部８、同期イベント変換部９、リソーススケジューリング部１０およびリソース見積もり部１１を備える。また、消費電力レベル調停部７に対して、複数（ｎ個）のアプリケーションそれぞれについての状態遷移図、状態と消費電力レベルの対応テーブルおよび状態遷移の確率モデルの各情報と、複数（ｍ個）のデバイスドライバそれぞれについての消費電力レベル遷移のリソースが公開された状態遷移図と、が入力される構成となっている。以下、これらの各構成要素の動作とともに電力制御情報生成装置の動作を説明する。

消費電力レベル調停部７は、複数のアプリケーションそれぞれの基本動作についての状態遷移図（前記ＡｐｐＳに相当）、状態と消費電力レベルの対応テーブル（前記ＡｐｐＰｏｗＭｉｎに相当）、状態遷移の確率モデル（前記ＡｐｐＰに相当）および複数のデバイスドライバそれぞれについての消費電力レベル遷移のリソースが公開された状態遷移図（前記ＰｏｗＳに相当）に基づいて、各アプリケーションが必要とする消費電力レベルを適宜算出し、また、アプリケーションの動作に応じて状態遷移が発生すると、消費電力レベルの変更の可能性があるかどうかを判断し、変更の可能性がある場合には、全体の消費電力レベルを見直し、デバイスドライバやＨ／Ｗが取るべき消費電力レベルを決定する。

なお、本実施の形態では、以下の（Ａ）〜（Ｄ）を前提として消費電力調停部７が消費電力レベルを決定する。
（Ａ）消費電力調停部７は、各デバイスドライバに対して消費電力レベルの上限を設定する。
（Ｂ）各アプリケーションはデバイスドライバの消費電力レベルの下限を設定することができる。
（Ｃ）各アプリケーションは特定のデバイスドライバの消費電力レベルを要求することができる。
（Ｄ）各デバイスドライバは設定された消費電力レベルの上限と下限範囲内で消費電力レベルを変更することができる。

図１８は、消費電力調停部７の動作を示す図である。すなわち、消費電力調停部７は、システム全体で必要とする消費電力レベルを下回らないように考慮しつつ、図１８に示したような動作を実行して各ドライバの消費電力レベルを可能な限り低く設定する。ただし、これがデバイスドライバに設定する最終的な消費電力レベルではない場合もある。

図１８において、アプリケーション（Application）＃ｘ（ｘ：1,2,…,n）が必要な消費電力レベルＡＬｘは、アプリケーション＃ｘが各ドライバ（Driver）に対するそれぞれの要求レベルの集合とする。すなわち、ＡＬｘは次式で表される。なお、要求がないドライバ（アプリケーションが必要としていないドライバ）については、当該ドライバに対する要求レベルを‘０’として扱う。
ＡＬｘ＝＜(ドライバ＃１への要求レベル)，…，(ドライバ＃ｍへの要求レベル)＞

ここで、ドライバへの要求レベルはすべて、０以上であるものとする。また、レベル範囲ＤＲと要求レベルＡＬｘの順序比較では各要素を比較し、すべてで「等しいかより大きい」が成立したら全体で「等しいかより大きい」が成立するものとする。また、［ｖ,ｗ］＝｛ｘ｜ｖ≦ｘ≦ｗ｝が成立するものとする。

そして各ドライバは、次式で示される許容範囲（レベル範囲）ＤＲ＃ｎ内で消費電力レベルを可能な限り小さくなるよう調節する。ここでは、便宜上、ｍａｘは束のｓｕｐ，ｍｉｎは束のｉｎｆを意味することとする。
ＤＲ＃ｎ＝（ＤＲのうち、ドライバ＃ｎに対して課せられた動作レベルの範囲）
ＤＲ＝［ｍｉｎＤＲ,ｍａｘＤＲ］
ｍｉｎＤＲ＝ｍｉｎ（ｍａｘ（ＡＬ１，…，ＡＬｎ)，ＳＬ）
：アプリケーション全体での要求レベル
ｍａｘＤＲ＝ＳＬ：システム全体での上限の要求レベル

消費電力レベル遷移変換部８は、消費電力レベル調停部７での決定結果（各デバイスドライバやＨ／Ｗが取るべき消費電力レベル）を受け取り、発生した状態遷移が各デバイスドライバやＨ／Ｗの消費電力レベルを表現している状態遷移図（ＰｏｗＳ）で定義されている状態遷移である場合はその状態遷移そのものを示す情報を消費電力レベル遷移として出力し、そうでない場合には、予め定義しておいた消費電力レベル遷移を表現するための状態遷移の列で表現しなおし（この処理ではＡｐｐＰｏｗＭｉｎを利用する）、表現しなおした状態遷移列（ＰｏｗＳで定義されている状態遷移の列）を示す情報を消費電力レベル遷移として出力する。消費電力レベルは任意のレベルからから任意のレベルへ遷移させることが可能であるが、任意のレベルから任意のレベルに直接遷移させることが可能であるとは限らない。複数の状態を経由して（状態遷移を繰り返して）目的のレベルへ遷移させる必要が発生する場合もありうる。したがって、レベル間の遷移はできるだけ短い状態遷移列として表現して、消費電力が必要以上に大きくならないようする。

同期イベント変換部９は、消費電力レベル遷移変換部８から出力された消費電力レベル遷移（列）を受け取り、各遷移をそれに対応する処理を表現している複数の同期イベントに変換して出力する。

ここで、各遷移に対応する処理は階層的に木構造で記述されており、木構造のノードを同期イベントと呼ぶ。同期イベントにはコールバック（詳細は後述する）とこのコールバックの処理に必要なドライバ（複数）とドライバの消費電力レベルが定義されている（図１９参照）。また、木構造の最も底の部分の同期イベントをリソースと呼び、このリソースが、同期イベント変換部９の後段に位置するリソーススケジューリング部１０におけるスケジューリングの対象となる。リソースには実行時間、消費電力や共有性制約などの特徴が定義されており、この特徴に基づいてリソーススケジューリング部１０がケジューリングを実施する。通常、リソースはＨ／Ｗになることが多い（図２０参照）。なお、同期イベント変換部９は、遷移を同期イベントの木構造の最下層（リソース）になるまでブレークダウンして出力する（図２１参照）。図２１の例では、太線で囲まれた４つの同期イベント（Ｈ／ＷＢＡ，Ｈ／ＷＢＢ，Ｈ／ＷＣＡ，Ｈ／ＷＤ）の情報がリソースとして出力されることとなる。

「コールバック」とは各同期イベントに対応させて定義された動作であり、この定義には、少なくとも、（i）対応する同期イベントが必要とするドライバとドライバの消費電力レベルのリスト，（ii）状態遷移動作で使用する内部データ，(iii）対応する同期イベントの状態分岐の選択肢を決定する論理とその結果に対応する値，が含まれる。状態遷移に対応する同期イベントの木構造階層やコールバックは、消費電力レベルの依存関係や状態分岐、並列実行可能などを記述するために使用するものである。

リソーススケジューリング部１０（スケジューリング手段）は、同期イベント変換部９が出力した複数の同期イベントを受け取り、これをスケジューリングして同期イベントやリソースとその同期イベントやリソースへの処理の割当や時間的順序を決定する（図２２参照）。

ここで、リソースは、共有性や消費電力の見積もりの観点からユニークな性質をもっており、次のグループＧ１〜Ｇ５に分類できる。なお、以下の説明では「実行主体(subject)」という表現を使用するが、この表現は、一般に使用されている「プロセス」、「タスク」、「スレッド」、「ジョブ」などとの総称である。システムやＯＳによって用語や位置づけが異なっているがここでは同じものとして扱う。各リソースには実行時間（s，ms）、消費電力（W，mW）が定められている。対象システムのモデリング方法によっては固定値ではなく、パラメータつき関数や確率変数になる場合もある。

（Ｇ１）複数の実行主体から無制限で同時に使用でき、消費電力は使用している実行主体の数には依存せずに一定のもの。
（Ｇ２）複数の実行主体から無制限で同時に使用でき、消費電力は使用している実行主体の数に比例するもの。
（Ｇ３）同時に実行できる主体の数に制限があるが、消費電力は使用している実行主体の数には依存せずに一定のもの。
（Ｇ４）同時に実行できる主体の数に制限があり、消費電力は使用している実行主体の数に比例するもの。
（Ｇ５）使用可能な実行主体が１つに限られるもの。

次に、リソースのスケジューリング方法について説明する。既に説明したように、同期イベントは木構造で表現されているため、状態遷移時のすべてのリソース（木構造の最下層の同期イベント）をすべてリストアップしてスケジューリングの対象にすることが可能である。したがって、システム全体として並べ替えや共有化がしやすくなり、全体として処理の最適化の自由度を高めることができる。

リソースのスケジューリングでは、上述したリソースの性質（上記の５つグループのうちどのグループに分類されたリソースか）を考慮しつつ、以下の（ａ），（ｂ），（ｃ）で示した条件を満たすようにリソースや同期イベントを条件内（時間間隔やシステムのリソース数の制約）に収まるように詰めこんで、この詰め込みかたに基づいたリソースへの処理の割当や時間的順序を出力する。

（ａ）同期イベントの縦の順番（木構造をもち、根元のほうが時間的に前と考える）にリソースがならんでいる。
（ｂ）異なるドライバの基底リソースどうしのスケジュール方法には制約はない。
（ｃ）同じドライバの基底リソースは上述したＧ１〜Ｇ５のグループ毎の制約の多重度の範囲内におさまっている。

また、同期イベントについても、同期イベントとリソースの順序関係が矛盾しないように詰め込む。ただし、同期イベントについては、後述するリソース見積もりを行う場合、実行時間と消費電力を‘０’とみなす。

リソース見積もり部１１は、リソーススケジューリング部１０が出力したスケジューリング結果（同期イベントやリソースとその同期イベントやリソースへの処理の割当や時間的順序）を受け取り、この情報に基づいて消費電力見積もりや処理時間見積もりを行う（図２３参照）。

リソーススケジューリング部１０から出力された処理の割当や時間的順序は、同期イベントの木構造の最下層（リソース）になるまでブレークダウンされたものについてのスケジューリング結果である。また、各リソースには処理時間と消費電力が割り当てられている。したがって、これらの各リソースについて定められた消費電力の総和をとれば、消費電力レベルの変化に対する消費電力を計算することができる。同様に処理時間も計算することができる。なお、総和をとるときに元の状態遷移図が確率的なモデルをもっているときはその状態や遷移に割り当てられている確率を消費電力値や処理時間に掛け合わせた上で総和をとる。消費電力レベルの変化に対する消費電力および処理時間は、以下の計算式からそれぞれ求めることができる。
（消費電力レベル変化時の消費電力）＝ Σ（リソースの消費電力）
（消費電力レベル変化時の処理時間）＝ Σ（リソースの処理時間）

各消費電力レベルの変化についての消費電力および処理時間が計算できたら、さらにすべての消費電力レベルの変化に対する消費電力および処理時間のそれぞれの和をとれば、全体の消費電力および処理時間が得られる。これらは、以下の計算式からそれぞれ求めることができる。
（全体の消費電力）＝ Σ（消費電力レベル変化時の消費電力）
（全体の処理時間）＝ Σ（消費電力レベル変化時の処理時間）

なお、既に説明したようにリソースは上記グループＧ１〜Ｇ５のいずれかに属する性質を有しているので、消費電力の総和をとる際には、各リソースの性質を考慮して調整する必要がある。たとえば、同時に実行可能でなおかつ消費電力が一定のもの（Ｇ１またはＧ３に分類されるリソース）が含まれる場合には重複分を総和から差し引く。

以上が本実施の形態の電力制御情報生成装置の動作である。なお、上記図１７の電力制御情報生成装置を変形して図２４に示した構成としてもよい。図２４は、図１７の電力制御情報生成装置のリソース見積もり部１１をリソース処理部１２に置き換えることにより得られる電力制御装置の構成図である。

リソース処理部１２は、リソーススケジューリング部１０が出力したスケジューリング結果（同期イベントやリソースとその同期イベントやリソースへの処理の割当や時間的順序）を受け取り、この情報に基づいてリソース（Ｈ／Ｗやデバイスドライバ）を制御する。すなわち、受け取ったスケジューリング結果に示された時間的順序に従って各リソースへのアクセスを実施する。同期イベントにアクセスした場合は、同期イベントに結びつけられたコールバックを実行する。

このように、本実施の形態の電力制御情報生成装置は、アプリケーションの状態遷移図、状態と消費電力レベルの対応テーブルおよび状態遷移の確率モデルに基づいて、アプリケーションが必要とする消費電力レベルを算出し、また、状態遷移に伴い消費電力レベルが変更となる可能性がある場合には、システム全体の消費電力レベルを見直してデバイスドライバやＨ／Ｗの消費電力レベルを決定する消費電力レベル調停部と、消費電力レベル調停部での決定結果に基づいて、状態遷移に伴う消費電力レベルの遷移列を生成する消費電力レベル遷移変換部と、消費電力レベル遷移変換部で生成された消費電力レベルの遷移列に含まれる各遷移をそれに対応する処理を表現している複数の同期イベントに変換する同期イベント変換部と、同期イベント変換部から出力された複数の同期イベントを各イベントの有する特性に基づいてスケジューリングするリソーススケジューリングと、を備えることとした。これにより、機能を実現するのに不要な消費電力を削減あるいは消費電力を要求範囲に収めることが可能となり、省電力化の実現が可能となる。

以上のように、上述した各実施の形態によれば、以下のような効果が得られる。
（１）システム構造が通常処理部分と省電力処理部分が分割されるとともに処理がデータ化されるため、メンテナンス（変更、追加、削除）に強い構造が実現できる（図２５参照）。
（２）機能を実現するのに不要な消費電力の削減や、消費電力を要求範囲に収めることができる。
（３）リソース確保と解放の非対応が発生し、不要なリソースを確保し続けてしまう不具合が発生するのを防止可能な構成を実現できる（図２参照）。
（４）一般に消費電力レベル遷移時にリソース消費（時間や消費電力）が発生しやすいが、本発明によれば、類似リソースがまとめやすくなり不要なレベル遷移は発生しにくくなるので消費電力の削減が図れる、すなわち、リソース消費が最も少ない手順で状態遷移を行うことができる（図２６参照）。

以上のように、本発明にかかる電力制御情報生成装置および電力制御装置は、アプリケーションが所定のハードウェアリソースを利用して各種機能を実現するシステムに有用であり、特に、リソースを効率的に利用して、より少ない消費電力レベルで動作可能なシステムにおける電力制御情報生成装置および電力制御装置に適している。

１電力制御情報生成部
２電力見積もり部
３状態遷移記憶部
４状態遷移フィルタ部
５制御実行部
６状態保持時間見積もり部
７消費電力レベル調停部
８消費電力レベル遷移変換部
９同期イベント変換部
１０リソーススケジューリング部
１１リソース見積もり部
１２リソース処理部
１００Ｈ／Ｗの電力制御部

Claims

複数のアプリケーションが利用可能な複数のハードウェアリソースにより構成された制御対象機器の電力制御のための情報を生成する電力制御情報生成装置であって、
各アプリケーションの基本動作についての状態遷移図（第１の状態遷移図）と、前記複数のハードウェアリソースの電力制御動作における状態遷移が各状態の消費電力レベルに基づいて階層化されて記載された状態遷移図（第２の状態遷移図）と、各アプリケーションの基本動作における各状態と前記各ハードウェアリソースの電力制御動作における各状態の対応テーブルと、当該状態遷移図に記載された各状態遷移事象の確率モデルと、に基づいて、アプリケーションの動作に応じた状態遷移が発生するごとに、制御対象機器全体の消費電力レベルを見直し、各ハードウェアリソースが取るべき消費電力レベルを決定する消費電力レベル調停手段と、
前記消費電力レベル調停手段における処理結果に基づき、前記アプリケーションの動作に応じた状態遷移が前記第２の状態遷移図で定義されている状態遷移である場合はその状態遷移そのものを示す情報を消費電力レベル遷移として出力し、そうでない場合には、前記アプリケーションの動作に応じた状態遷移を前記対応テーブルに基づいて、前記第２の状態遷移図で定義されている状態遷移の列で表現しなおし、表現しなおした状態遷移列を示す情報を消費電力レベル遷移として出力する消費電力レベル遷移変換手段と、
前記消費電力レベル遷移変換手段から出力された消費電力レベル遷移に含まれる各状態遷移を、予め対応付けられている所定の処理を示す複数の同期イベントに変換して出力する同期イベント変換手段と、
前記同期イベント変換手段から出力された各同期イベントの消費電力レベルに関するそれぞれの特性に基づいて、当該各同期イベントの実行順序をスケジューリングするスケジューリング手段と、
前記スケジューリング手段におけるスケジューリング結果に基づいて、前記アプリケーションの動作に応じた状態遷移における消費電力および処理時間の見積もりを行うリソース見積もり手段と、
を備えることを特徴とする電力制御情報生成装置。
複数のアプリケーションが利用可能な複数のハードウェアリソースにより構成された制御対象機器の電力制御を行う電力制御装置であって、
各アプリケーションの基本動作についての状態遷移図（第１の状態遷移図）と、前記複数のハードウェアリソースの電力制御動作における状態遷移が各状態の消費電力レベルに基づいて階層化されて記載された状態遷移図（第２の状態遷移図）と、各アプリケーションの基本動作における各状態と前記各ハードウェアリソースの電力制御動作における各状態の対応テーブルと、当該状態遷移図に記載された各状態遷移事象の確率モデルと、に基づいて、アプリケーションの動作に応じた状態遷移が発生するごとに、制御対象機器全体の消費電力レベルを見直し、各ハードウェアリソースが取るべき消費電力レベルを決定する消費電力レベル調停手段と、
前記消費電力レベル調停手段における処理結果に基づき、前記アプリケーションの動作に応じた状態遷移が前記第２の状態遷移図で定義されている状態遷移である場合はその状態遷移そのものを示す情報を消費電力レベル遷移として出力し、そうでない場合には、前記アプリケーションの動作に応じた状態遷移を前記対応テーブルに基づいて、前記第２の状態遷移図で定義されている状態遷移の列で表現しなおし、表現しなおした状態遷移列を示す情報を消費電力レベル遷移として出力する消費電力レベル遷移変換手段と、
前記消費電力レベル遷移変換手段から出力された消費電力レベル遷移に含まれる各状態遷移を、予め対応付けられている所定の処理を示す複数の同期イベントに変換して出力する同期イベント変換手段と、
前記同期イベント変換手段から出力された各同期イベントの消費電力レベルに関するそれぞれの特性に基づいて、当該各同期イベントの実行順序をスケジューリングするスケジューリング手段と、
前記スケジューリング手段におけるスケジューリング結果に基づいて、制御対象機器の電力制御を行う電力制御手段と、
を備えることを特徴とする電力制御装置。