JPWO2011135721A1 - 情報処理装置及び消費電力管理プログラム - Google Patents

Abstract

消費電力を押さえることが可能な情報処理装置及び消費電力管理プログラムを提供することを課題とし、複数の処理を並行して行う情報処理装置が、複数の処理手段と、処理手段の処理間隔を処理手段ごとに決定して、該複数の処理手段の処理タイミングが合うように段階的に調整する調整手段とを有することを特徴とする。

Description

本発明は、複数の処理を並行して行う情報処理装置及びその情報処理装置で利用する消費電力管理プログラムに関する。

携帯電話、ＰＤＡ（Personal Digital Assistants）、ノートＰＣなどの携帯装置はバッテリにより駆動する際、消費電力によりバッテリ駆動時間が異なる。

近年、携帯装置はマルチタスクＯＳを搭載するものが増加している。マルチタスクＯＳを搭載する携帯装置には、例えば機能やユーザインタフェースの表現力や操作性、表示される内容等が豊か（rich）なクライアントソフトウェア（リッチソフトウェア）を追加可能なものがあった。

しかし、マルチタスクＯＳを搭載する携帯装置は、リッチソフトウェアの継続的な動作により無駄に電力を消費していることがあった。例えばマルチタスクＯＳを搭載する携帯装置の一例としてのスマートフォンは消費電力が大きい。

スマートフォンは通話以外の用途にも広く用いられる。スマートフォンは例えばＳＭＳ（Short Message Service）、ＭＭＳ（Multimedia Messaging Service）、インターネットメールなどのメール、Ｗｅｂ、ニュース、ブログ、地図、交通情報等の閲覧、ゲームなどに用いられている。

しかし、スマートフォンの通話以外の用途を実現する為に追加されたリッチソフトウェア等のアプリケーション（以下では単にアプリという）は、ハード設計者の想定内で動作するとは限らない。また、サードパーティなどのアプリ製作者は公開されたハードの外部仕様を頼りに実装するため、消費電力について積極的に考慮することはない。また、サードパーティなどのアプリ製作者は他のアプリ製作者によるアプリの動作を積極的に意識することはない。

さらに、スマートフォンはユーザが操作していないときでも、メール受信、ＲＳＳ（RDF Site Summary）更新、無線デバイスの探索（２Ｇ／３Ｇ／ＬＴＥ、Ｗｉｆｉ、Ｂｌｕｅｔｏｏｔｈ、赤外線など）、センサ（ＧＰＳ、モーション、地磁気、温度、光など）のため、頻繁にハードウェア・ソフトウェアが動作している。

例えば消費電力を削減する為に、タスク（プロセス）の並列動作を禁止し、待機時に、必要最低限のプロセスを動作する携帯装置は従来から知られている。従来のモバイルデバイスには、アプリケーションを含むすべての層を考慮してバッテリ電力の節約を行うものが知られている（例えば特許文献１参照）。

しかしながら、従来の携帯装置はアプリ製作者が他のアプリの動作を積極的に意識することがないため、一つのアプリについて電力を削減できたとしても、他のアプリの影響により十分な効果を出せない可能性があった。

図１は従来の携帯装置における消費電力の一例を表した模式図である。図１はアプリ１、アプリ２、ＯＳ３、デバイス４の消費電力の遷移を表している。アプリ１はポーリング間隔Ｔ１ごとに動作を行う。アプリ２はポーリング間隔Ｔ２ごとに動作を行う。つまり、アプリ１とアプリ２とは所定時間ごとに動作を行う。

しかし、アプリ１とアプリ２とは動作の関連性が無く、独立している。ここではアプリ１及びアプリ２以外に動作するプロセスがないものとする。アプリ１とアプリ２とは固有のハードウェア資源であるデバイス４を利用する。アプリ１及びアプリ２の消費電力はＣＰＵ又はメモリへのアクセス時間に応じたものとする。ＣＰＵは全プロセスの待機時に低消費電力状態に遷移する。

ＯＳ３及びデバイス４は、アプリ１及びアプリ２が動作している期間に消費電力が大きくなっている。図１の例ではアプリ１、アプリ２、ＯＳ３及びデバイス４の消費電力の合計は１２５ｍＷである。アプリ１、アプリ２、ＯＳ３及びデバイス４の消費電力の合計は、ＯＳ３及びデバイス４の消費電力が大きくなっている期間を短くすれば小さくできる。

しかしながら、従来の携帯装置のポーリング間隔Ｔ１及びＴ２は、アプリ１及びアプリ２のアプリ製作者がＯＳ３及びデバイス４の消費電力を考慮せずに決定するものである。このため従来の携帯装置は、アプリ１及びアプリ２が動作している期間を調整できず、ＯＳ３及びデバイス４の消費電力が大きくなっている期間を短くすることはできない。

特開２００２−１８５４７５号公報

本発明の一実施形態は、消費電力を押さえることが可能な情報処理装置及び消費電力管理プログラムを提供することを課題としている。

上記課題を解決するため、本発明の一実施形態は、複数の処理を並行して行う情報処理装置であって、複数の処理手段と、前記処理手段の処理間隔を前記処理手段ごとに決定して、該複数の処理手段の処理タイミングが合うように段階的に調整する調整手段とを有する。

なお、本発明の一実施形態の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

本発明の一実施形態によれば、消費電力を押さえることが可能な情報処理装置及び消費電力管理プログラムを提供可能である。

従来の携帯装置における消費電力の一例を表した模式図である。 本実施例の携帯装置１０の一例のハードウェア構成図である。 本実施例の携帯装置１０の一例のソフトウェア構成図である。 イベント管理ＡＰＩ４２が決定したポーリング間隔でアプリ３０に含まれるブラウザ３１等を動作させる処理を説明する為の説明図である。 本実施例の携帯装置１０における消費電力の一例について説明するための模式図である。 イベント管理ＡＰＩ４２が提供するｆ関数の一例の説明図である。 ＯＳ３が決定したポーリング間隔でアプリ１及び２を動作させる処理手順を表した一例のフローチャートである。

１、２ アプリ
３ ＯＳ
４ デバイス
１０ 携帯装置
１１ マルチコアのＣＰＵ
１２ ＧＰＵ（Graphics Processing Unit）
１３ ＬＣＤ（Liquid Crystal Display） Ｉ／Ｆ
１４ タッチパネルＩ／Ｆ
１５ 前面のカメラＩ／Ｆ
１６ メモリ
１７ 後面のカメラＩ／Ｆ
１８ 無線Ｉ／Ｆ
１９ ＵＳＢ（Universal Serial Bus）Ｉ／Ｆ
２０ Ｗｉ−Ｆｉ（Wireless Fidelity）Ｉ／Ｆ
２２ 記録媒体
２５ バス
３０ アプリ
３１ ブラウザ
３２ 電話アプリ
３３ ニュースアプリ
３４ メールアプリ
４０ ＡＰＩ（Application Program Interface）
４１ アプリ管理ＡＰＩ
４２ イベント管理ＡＰＩ
４３ タイマＡＰＩ
５０ ライブラリ
５１ タイミング制御ライブラリ
５２ 電力制御ライブラリ
５３ Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）
６０ カーネル
６１ デバイス制御部
６２ プロセス制御部

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例では情報処理装置の一例として携帯装置を例に説明する。実施例の携帯装置は、複数の処理を並行して行う携帯電話、ＰＤＡ、ノートＰＣなどの装置の一例である。

図２は本実施例の携帯装置１０の一例のハードウェア構成図である。携帯装置１０は、マルチコアのＣＰＵ１１、ＧＰＵ（Graphics Processing Unit）１２、ＬＣＤ（Liquid Crystal Display） Ｉ／Ｆ１３、タッチパネルＩ／Ｆ１４、前面のカメラＩ／Ｆ１５、メモリ１６、後面のカメラＩ／Ｆ１７、無線Ｉ／Ｆ１８、ＵＳＢ（Universal Serial Bus）Ｉ／Ｆ１９、Ｗｉ−Ｆｉ（Wireless Fidelity）Ｉ／Ｆ２０を有する。なお、図２はＬＣＤ Ｉ／Ｆ１３、タッチパネルＩ／Ｆ１４、カメラＩ／Ｆ１５及び１７、無線Ｉ／Ｆ１８、ＵＳＢ Ｉ／Ｆ１９、Ｗｉ−Ｆｉ Ｉ／Ｆ２０を介して接続される各装置の図示を省略している。

バス２５で相互に接続されているＧＰＵ１２、ＬＣＤ Ｉ／Ｆ１３、タッチパネルＩ／Ｆ１４、カメラＩ／Ｆ１５、メモリ１６、カメラＩ／Ｆ１７、無線Ｉ／Ｆ１８、ＵＳＢ Ｉ／Ｆ１９、Ｗｉ−Ｆｉ Ｉ／Ｆ２０は、マルチコアのＣＰＵ１１による管理下で相互にデータの送受を行うことができる。

マルチコアのＣＰＵ１１は、パッケージの中に命令発行器や演算器などを組み合わせた一つの部品として動作するプロセッサコアが複数個入っている。ＣＰＵ１１は携帯装置１０全体の動作制御を司る中央処理装置である。

ＧＰＵ１２は表示に必要な計算処理を行なう。ＬＣＤ Ｉ／Ｆ１３は液晶ディスプレイとのＩ／Ｆである。タッチパネルＩ／Ｆ１４はタッチパネルとのＩ／Ｆである。カメラＩ／Ｆ１５及び１７はカメラとのＩ／Ｆである。メモリ１６は主記憶装置及び補助記憶装置である。

無線Ｉ／Ｆ１８は無線デバイスとのＩ／Ｆである。ＵＳＢ Ｉ／Ｆ１９はＵＳＢ規格に対応した周辺機器とのＩ／Ｆである。Ｗｉ−Ｆｉ Ｉ／Ｆ２０は無線ＬＡＮの標準規格である「IEEE 802.11a/IEEE 802.11b」に対応する無線ＬＡＮデバイスとのＩ／Ｆである。

例えば携帯装置１０には本実施例の消費電力管理プログラムがインストールされている。携帯装置１０は消費電力管理プログラムを実行する。メモリ１６には携帯装置１０を動作させるプログラムの一部として、少なくとも消費電力管理プログラムが記憶されている。ＣＰＵ１１は消費電力管理プログラムをメモリ１６から読み出して実行する。

消費電力管理プログラムは携帯装置１０が読み取り可能な記録媒体２２に記録しておくことができる。携帯装置１０は例えばＵＳＢ Ｉ／Ｆ１９を介して記録媒体２２から消費電力管理プログラムを読み取り可能である。なお、記録媒体２２からの消費電力管理プログラムの読み取りはＵＳＢ Ｉ／Ｆ１９以外を介して行うことも可能である。

携帯装置１０で読み取り可能な記録媒体２２には、磁気記録媒体、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ − Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。また、光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ − Ｏｐｔｉｃａｌ ｄｉｓｋ）などがある。消費電力管理プログラムを流通させる場合には、例えば消費電力管理プログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型の記録媒体２２を販売することが考えられる。ＡｐｐＳｔｏｒｅ，Ａｎｄｒｏｉｄ Ｍａｒｋｅｔ等のインターネット上にあるアプリ配布機構を用いる事も考えられる。

そして、消費電力管理プログラムを実行する端末装置１０は、消費電力管理プログラムを記録した記録媒体２２から、消費電力管理プログラムを読み出す。ＣＰＵ１１は、読み出された消費電力管理プログラムをメモリ１６に格納する。携帯装置１０は、メモリ１６から消費電力管理プログラムを読み取り、消費電力管理プログラムに従った処理を実行する。

図３は本実施例の携帯装置１０の一例のソフトウェア構成図である。携帯装置１０は、アプリ３０、ＡＰＩ（Application Program Interface）４０、ライブラリ５０、カーネル６０を有する。

アプリ３０には、ブラウザ３１、電話アプリ３２、ニュースアプリ３３、メールアプリ３４が含まれる。ＡＰＩ４０には、アプリ管理ＡＰＩ４１、イベント管理ＡＰＩ４２、タイマＡＰＩ４３が含まれる。

また、ライブラリ５０には、タイミング制御ライブラリ５１、電力制御ライブラリ５２、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）５３が含まれる。Ｊａｖａ（登録商標）ＶＭ５３はアプリ３０がネイティブコードであれば不要である。さらに、カーネル６０にはデバイス制御部６１、プロセス制御部６２が含まれる。

アプリ３０に含まれるブラウザ３１等はＡＰＩ４０の提供するアプリ管理ＡＰＩ４１等の関数を利用して各種機能を利用することができる。関数とは、引数と呼ばれるデータを受け取り、定められた通りの処理を実行して結果を返す一連の命令群を言う。

ＡＰＩ４０のイベント管理ＡＰＩ４２は、例えばアプリ３０に含まれるブラウザ３１等から後述のｆ関数により呼び出される。イベント管理ＡＰＩ４２はｆ関数の計算に必要な各種データをライブラリ５０のタイミング制御ライブラリ５１、電力制御ライブラリ５２等から取得する。そして、イベント管理ＡＰＩ４２はｆ関数を計算することによりアプリ３０に含まれるブラウザ３１等の動作のポーリング間隔を決定する。ライブラリ５０のタイミング制御ライブラリ５１及び電力制御ライブラリ５２はカーネル６０のデバイス制御部６１からｆ関数の計算に必要な各種データを取得する。

カーネル６０のデバイス制御部６１はデバイス４からｆ関数の計算に必要な各種データを取得する。また、カーネル６０のプロセス制御部６２は動作するアプリ３０に含まれるブラウザ３１等のプロセス（タスク）の切り換え等を制御する。

図４はイベント管理ＡＰＩ４２が決定したポーリング間隔でアプリ３０に含まれるブラウザ３１等を動作させる処理を説明する為の説明図である。なお、図４は図３のソフトウェア構成図からアプリ３０、ＡＰＩ４０を抜き出したものである。

アプリ３０に含まれるニュースアプリ３３、メールアプリ３４はカーネル６０のプロセス制御部６２によりタスク切り替えが行われる。ＡＰＩ４０のイベント管理ＡＰＩ４２はアプリ３０に含まれるニュースアプリ３３、メールアプリ３４からイベントの発生をｆ関数により通知される。

イベント管理ＡＰＩ４２はｆ関数を後述のように計算し、アプリ３０に含まれるニュースアプリ３３、メールアプリ３４の動作のポーリング間隔を決定する。イベント管理ＡＰＩ４２はアプリ３０に含まれるニュースアプリ３３、メールアプリ３４に動作のポーリング間隔を通知する。タイマＡＰＩ４３は、アプリ３０に含まれるニュースアプリ３３、メールアプリ３４から呼び出されたときに時刻情報を提供する。

図５は本実施例の携帯装置１０における消費電力の一例について説明するための模式図である。図５はアプリ１、アプリ２、ＯＳ３、デバイス４の消費電力の遷移を表している。

アプリ１及び２のポーリング間隔Ｔ１及びＴ２はアプリ１及び２自身が規定するものでなく、ＡＰＩ４０のイベント管理ＡＰＩ４２がタイマＡＰＩ４３と連携してアプリ１及び２に通知する。イベント管理ＡＰＩ４２は、アプリ１及び２に対して電力効果が最大になるようなポーリング間隔Ｔ１及びＴ２をアプリ１及び２に提供する。なお、ポーリング間隔Ｔ１及びＴ２は静的に限らない。イベント管理ＡＰＩ４２が決定するポーリング間隔Ｔ１及びＴ２は電力効果が最大になるように決定される。

アプリ１はポーリング間隔Ｔ１ごとに動作を行う。アプリ２はポーリング間隔Ｔ２ごとに動作を行う。つまり、アプリ１とアプリ２とはイベント管理ＡＰＩ４２が決定するポーリング間隔Ｔ１及びＴ２ごとに動作を行う。なお、アプリ１及び２がクリティカルな動作をする為に必要な制約はアプリ１及び２からイベント管理ＡＰＩ４２に通知される。

ここでは図１と同様、アプリ１及びアプリ２以外に動作するプロセスがないものとする。アプリ１とアプリ２とは固有のハードウェア資源であるデバイス４を利用する。アプリ１及びアプリ２の消費電力はＣＰＵ１１又はメモリ１６へのアクセス時間に応じたものとする。ＣＰＵ１１は全プロセスの待機時に低消費電力状態に遷移する。

ＯＳ３及びデバイス４は、アプリ１及びアプリ２が動作している期間に消費電力が大きくなっている。図５の例ではアプリ１及びアプリ２の動作するタイミングが時間経過と共に少しずつ（段階的に）合っていく。結果として、図５の例ではＯＳ３及びデバイス４の消費電力が大きくなっている期間が短くなる。なお、図５においてアプリ１及び２は動作するタイミングが合ったとしても、デバイス４を例えば時分割により分け合って使用できるものとする。

図５の例ではアプリ１、アプリ２、ＯＳ３及びデバイス４の消費電力の合計は１０５ｍＷである。アプリ１、アプリ２、ＯＳ３及びデバイス４の消費電力の合計はＯＳ３及びデバイス４の消費電力が大きくなっている期間を短くしたことで、図１の例よりも２０ｍＷ小さくなる。

このように、本実施例の携帯装置１０はアプリ１及び２で協調して動作するようにアプリ１及び２のポーリング間隔Ｔ１及びＴ２をイベント管理ＡＰＩ４０で決定することで、アプリ１及びアプリ２が動作している期間を調整でき、ＯＳ３及びデバイス４の消費電力が大きくなっている期間を短くして、消費電力の合計を小さくできる。

図６はイベント管理ＡＰＩ４２が提供するｆ関数の一例の説明図である。図６のＰｏｗｅｒＡｐｉＬｅｖｅｌ１はアプリ１の消費電力指標であり、アプリ１が任意に指定する。ＰｏｗｅｒＡｐｉＬｅｖｅｌ２はアプリ２の消費電力指標であり、アプリ２が任意に指定する。ＰｏｗｅｒＡｐｉＬｅｖｅｌ１及びＰｏｗｅｒＡｐｉＬｅｖｅｌ２は後述のポーリング間隔Ｔ１及びＴ２の揺れの範囲を調整する。

Ｐｏｌｌｉｎｇ１はアプリ１が想定する理想的なポーリング間隔である。Ｐｏｌｌｉｎｇ２はアプリ２が想定する理想的なポーリング間隔である。Ｐｏｌｌｉｎｇ１及びＰｏｌｌｉｎｇ２はアプリ１及びアプリ２毎、ループ（スレッド）毎に設定される。

アプリ１は引数にＰｏｗｅｒＡｐｉＬｅｖｅｌ１及びＰｏｌｌｉｎｇ１を設定してイベント管理ＡＰＩ４２のｆ関数を呼び出す。イベント管理ＡＰＩ４２はｆ関数に設定された引数と、ライブラリ５０のタイミング制御ライブラリ５１、電力制御ライブラリ５２等から取得する後述のデータとに基づき、アプリ１のポーリング間隔Ｔ１を決定する。イベント管理ＡＰＩ４２は決定したアプリ１のポーリング間隔Ｔ１をｆ関数の結果として返す。

アプリ２は引数にＰｏｗｅｒＡｐｉＬｅｖｅｌ２及びＰｏｌｌｉｎｇ２を設定してイベント管理ＡＰＩ４２のｆ関数を呼び出す。イベント管理ＡＰＩ４２はｆ関数に設定された引数と、ライブラリ５０のタイミング制御ライブラリ５１、電力制御ライブラリ５２等から取得する後述のデータとに基づき、アプリ２のポーリング間隔Ｔ２を決定する。イベント管理ＡＰＩ４２は決定したアプリ２のポーリング間隔Ｔ２をｆ関数の結果として返す。

ｆ関数は例えば式（１）のように構成される。

ＬａｓｔＰｏｌｌｉｎｇＴｉｍｅは直近に発生した、他のプロセスを含むポーリングの時刻を表す。ＣｕｒｒｅｎｔＴｉｍｅは現在時刻を表す。イベント管理ＡＰＩ４２はライブラリ５０のタイミング制御ライブラリ５１からＬａｓｔＰｏｌｌｉｎｇＴｉｍｅ及びＣｕｒｒｅｎｔＴｉｍｅを取得する。

また、ＢａｔｔｅｒｙＬｉｆｅはデバイス４から得られるバッテリの使用量や残量などのバッテリの供給電力指標である。ＢａｔｔｅｒｙＬｉｆｅは０以上１以下の値であるとする。また、式（１）のＰｏｗｅｒＡｐｉＬｅｖｅｌ１は１以上の値であるとする。

式（１）の第１項目は、アプリ１が想定する理想的なポーリング間隔であるＰｏｌｌｉｎｇ１である。式（１）の第２項目は、ポーリング間隔Ｔ１の揺れの範囲である。長期的な平均を取ると、ポーリング間隔Ｔ１はアプリ１が想定する理想的なポーリング間隔であるＰｏｌｌｉｎｇ１に収束する。しかし、各ポーリングのタイミングは直近の他のポーリングのタイミングに近づくことになる。なお、アプリ１しか動作していない場合、ポーリング間隔Ｔ１は常にアプリ１が想定する理想的なポーリング間隔であるＰｏｌｌｉｎｇ１となる。

式（１）に示すように、ポーリング間隔Ｔ１はＰｏｗｅｒＡｐｉＬｅｖｅｌ１が大きい程、ＢａｔｔｅｒｙＬｉｆｅが小さい程、揺れの範囲が大きくなる。揺れの範囲が大きければ、アプリ１及びアプリ２の動作するタイミングが速く合う。揺れの範囲が大きい場合は、アプリ１が想定する理想的なポーリング間隔であるＰｏｌｌｉｎｇ１を守ることよりも消費電力を少なくすることを優先している。

また、ポーリング間隔Ｔ１はＰｏｗｅｒＡｐｉＬｅｖｅｌ１が小さい程、ＢａｔｔｅｒｙＬｉｆｅが大きい程、揺れの範囲が小さくなる。揺れの範囲が小さければアプリ１及びアプリ２の動作するタイミングが合うまで時間が掛かる。揺れの範囲が小さい場合は、消費電力を少なくすることよりも、アプリ１が想定する理想的なポーリング間隔であるＰｏｌｌｉｎｇ１を守ることを優先している。

式（１）の例において、ＰｏｗｅｒＡｐｉＬｅｖｅｌ１は値（例えばアプリ１の消費電力の大きさ）が大きい程、消費電力の削減を優先することを表す。ＢａｔｔｅｒｙＬｉｆｅは値（例えばバッテリの残量）が小さい程、消費電力の削減を優先することを表す。なお、式（１）の定数は更にポーリング間隔Ｔ１を揺らす為のパラメータである。

ｆ関数は例えば式（２）のように構成してもよい。

式（２）は式（１）の第２項目の分母を指数関数としたものである。式（２）は式（１）と比較して、ＰｏｗｅｒＡｐｉＬｅｖｅｌ１及びＢａｔｔｅｒｙＬｉｆｅの影響を小さくできる。

図７はＯＳ３が決定したポーリング間隔でアプリ１及び２を動作させる処理手順を表した一例のフローチャートである。ステップＳ１に進み、ＯＳ３は動作を開始する。ステップＳ２、Ｓ３に進み、アプリ１、２は動作を開始する。ステップＳ４に進み、ＯＳ３はデバイス４からＢａｔｔｅｒｙＬｉｆｅを取得する。

ステップＳ５に進み、アプリ１はｆ関数の引数としてＰｏｗｅｒＡｐｉＬｅｖｅｌ１及びＰｏｌｌｉｎｇ１をＯＳ３に通知する。ステップＳ６に進み、ＯＳ３はｆ関数を計算し、アプリ１のポーリング間隔Ｔ１を決定する。また、ステップＳ７に進み、ＯＳ３はアプリ１へポーリング間隔Ｔ１を通知する。

ステップＳ８に進み、アプリ１はＯＳ３からポーリング間隔Ｔ１を取得し、そのポーリング間隔Ｔ１ごとに動作を行う。

ステップＳ９に進み、アプリ２はｆ関数の引数としてＰｏｗｅｒＡｐｉＬｅｖｅｌ２及びＰｏｌｌｉｎｇ２をＯＳ３に通知する。ステップＳ１０に進み、ＯＳ３はｆ関数を計算し、アプリ２のポーリング間隔Ｔ２を決定する。ポーリング間隔Ｔ２は上記した式（１）又は式（２）によりＬａｓｔＰｏｌｌｉｎｇＴｉｍｅを直近のアプリ１のポーリングの時刻として算出される。

また、ステップＳ１１に進み、ＯＳ３はアプリ２へ算出したポーリング間隔Ｔ２を通知する。ステップＳ１２に進み、アプリ２はＯＳ３からポーリング間隔Ｔ２を取得し、そのポーリング間隔Ｔ２ごとに動作を行う。

以上、本発明の携帯装置１０によれば、バッテリの供給電力指標及びアプリ１等の消費電力指標に応じて、アプリ１等が動作している期間を調整することができるので、ＯＳ３及びデバイス４の消費電力が大きくなっている期間を短くして、消費電力の合計を小さくできる。

なお、本実施例のイベント管理ＡＰＩ４２は例えばＣＰＵ１１が消費電力管理プログラムを実行することにより実現される。請求の範囲に記載した処理手段はアプリ１、２に相当し、調整手段がイベント管理ＡＰＩ４２に相当し、制御手段がタイミング制御ライブラリ５１及び電力制御ライブラリ５に相当する。

Claims (7)

1. 複数の処理を並行して行う情報処理装置であって、
   複数の処理手段と、
   前記処理手段の処理間隔を前記処理手段ごとに決定して、該複数の処理手段の処理タイミングが合うように段階的に調整する調整手段と
   を有する情報処理装置。
2. 前記調整手段は、前記処理手段の消費電力指標及び前記情報処理装置の供給電力指標に基づいて、前記処理間隔を変更する請求項１記載の情報処理装置。
3. 前記調整手段は、前記複数の処理手段の何れかにより行われた直近の処理時刻と現在時刻との差が大きいほど、前記処理間隔を小さくする請求項２記載の情報処理装置。
4. 前記調整手段は、前記処理手段の消費電力が大きいほど、前記情報処理装置の供給電力の残量が小さいほど、前記処理間隔を大きくし、前記処理手段の消費電力が小さいほど、前記情報処理装置の供給電力の残量が大きいほど、前記処理間隔を小さくする請求項３記載の情報処理装置。
5. 前記調整手段は前記処理手段から該処理手段の消費電力指標及び前記処理間隔を取得すると共に、前記供給電力指標、前記処理時刻及び現在時刻を前記情報処理装置内の制御を行う制御手段から取得する請求項４記載の情報処理装置。
6. 前記情報処理装置は携帯装置である、請求項１乃至５の何れか一項に記載の情報処理装置。
7. 複数の処理を並行して行うコンピュータを、
   複数の処理手段と、
   前記処理手段の処理間隔を前記処理手段ごとに決定して、該複数の処理手段の処理タイミングが合うように段階的に調整する調整手段と
   として機能させる消費電力管理プログラム。

Images