JP2013114604A - 情報処理装置及びその制御方法、プログラム - Google Patents

Abstract

【課題】 モジュール毎に近い将来の利用可能性を判定し、その結果をもとに通常状態、省電力状態を切替えて動作させることにより、システムの応答性と省電力を両立させる。
【解決手段】 処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する。受け付けた処理要求の処理要求種別と、処理リソース割当パターンに基づいて、受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する。処理リソース割当パターンと割当可能処理リソース情報とに基づいて、割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定する。そして、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する。
【選択図】 図１

Description

本発明は、複数のモジュールを組み合わせて１つのシステムを実現する情報処理装置に関するものであり、特に、モジュール単位で電力制御を施しシステム全体の省電力を実現する技術に関するものである。

昨今の組込機器や大規模システムは、多機種・多機能化に対応するため、それぞれ固有の基本機能を有する複数の機能ブロック（以降、これをモジュールと称す）が連携動作することにより実現される場合が多い。例えば、デジタルテレビに代表される映像出力機器は、受け付けた動画データを解読し出力するために、入力モジュール・Ｄｅｍｕｘモジュール・デコードモジュール・出力モジュール等の多くのモジュールがシステムに組み込まれる。そして、ユーザからの要求を受け付けた場合には、その要求が複数の内部命令に変換された後、上記モジュール間で分担しながら処理され、例えば、視聴・録画等の機能を実現する。

ここで、上記のモジュール化は、ソフトウェア及びハードウェアを含む形で進みつつある。例えば、上記デコードモジュールには、動画データのデコードに特化したハードウェアと、そのハードウェア上で動作するソフトウェアの双方が含まれて良い。特に、近年では、１つの組込機器に対し、それぞれ特定の機能に特化した多数のＣＰＵを搭載する傾向が顕著である。さらに昨今のクラウドコンピューティングでは、ネットワークを介してアクセスするユーザに対して多数のサーバを１つのシステムに束ねた形で見せ、サービスを提供する。このようなシステムを実現するためにも、モジュール化の技術が必須である。

一方で、環境に配慮した製品開発は、近年においては環境面とビジネス面の両面において非常に重要な視点である。特に、組込機器の消費電力については、多くの業界で待機電力の目標値が設定される等の関心が高い。

このような状況の中、従来より、モジュール単位で消費電力を制御する技術が検討されている。ここで、各モジュールがそれぞれ消費電力を抑制すれば、システム全体の省電力を実現可能である。そこで、マルチプロセッサシステムを構成する各モジュールにおいて命令実行状態を監視し、一定時間の連続した停止状態が検出されたモジュールは内部のプロセッサのクロックを停止することで消費電力の低減を図る方法が提案されている（特許文献１）。

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

しかしながら、従来の方法では、モジュール毎の近い将来の利用可能性を正確に予測していなかったため、以下の課題が存在する。すなわち、通常状態から省電力状態に遷移するタイミングは、例えば、一定時間の連続した停止状態が検出された場合であり、すぐに利用される可能性のないモジュールもある一定期間通常状態で動作するため、省電力効果が十分に得られない。

その一方で、省電力状態を持つモジュールは、通常動作を担保するために省電力状態から通常状態への復帰メカニズムを持たなければならない。ここで、省電力状態時に新たな処理要求を受け取った場合に、その処理要求の内容と自装置の状態とに基づいて、モジュール毎に通常状態に遷移させるか否かを判断する方法がある。しかしながら、この方法では省電力状態から通常状態へ遷移させるか否かを判断するタイミングは、例えば、システムが次の処理要求を受け取ったタイミングである。そのため、次の処理要求を受け取った後でないと通常状態への復帰動作を開始できないため、一旦省電力状態へ遷移した場合のシステムの応答性が低下する。

特に、多岐にわたる機能を提供するために多くのモジュールを備え、なおかつ多くのユーザによって共用されるシステムの場合、外部より受け付け可能な処理要求の種別（以降、これを処理要求種別と称す）や組み合わせが多い。そのため、モジュール単位での省電力制御を適切なタイミングで実施することが、省電力及びシステムの応答性の向上を実現する上で重要となる。

本発明は上記の課題を解決するためになされたものであり、モジュール毎に近い将来の利用可能性を判定し、その結果をもとに通常状態、省電力状態を切替えて動作させることにより、システムの応答性と省電力を両立させることである。

上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。即ち、
それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置であって、
処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する処理リソース割当パターン保持部と、
受け付けた処理要求の処理要求種別と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンに基づいて、前記受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する処理リソース割当部と、
前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する電力状態決定部と
を有する。

本発明によれば、モジュール毎に近い将来の利用可能性を判定し、その結果をもとに通常状態、省電力状態を切替えて動作させることにより、システムの応答性と省電力を両立させることができる。より具体的には、次の処理要求で利用される可能性のないモジュールを省電力状態で動作させることにより、システムの応答性を確保しつつも省電力を実現することができる。

実施形態１の情報処理装置の構成を示すブロック図である。 実施形態１の処理要求種別情報及び処理リソース情報の一例を示す図である。 実施形態１の処理要求種別情報及び処理リソース情報の保持例を示す図である。 実施形態１のモジュール毎の割当可能処理リソース情報の一例を示す図である。 実施形態１のモジュール毎の割当可能処理リソース情報の保持例を示す図である。 実施形態１の処理受け付け前の割当可能処理リソース数の保持例を示す図である。 実施形態１の処理受け付け後の割当可能処理リソース数の保持例を示す図である。 実施形態１の各モジュールが保持する状態図の一例を示す図である。 実施形態１の実現手順を示すフローチャートである。 実施形態１の次の処理要求として各処理要求種別の処理要求が受け付け可能か否かを判定する処理の詳細を示すフローチャートである。 実施形態１の次の処理要求として各処理要求種別の処理要求を受け付け可能か否かを判定した結果の保持例を示す図である。 実施形態１の次の処理要求受け付け時に各処理リソース種別の処理リソースを利用する可能性があるか否かを判定する処理の詳細を示すフローチャーである。 実施形態１の次の処理要求受け付け時に各処理リソースが利用される可能性があるか否かを判定した結果の保持例を示す図である。 実施形態１の次の処理要求受け付け時に各モジュールが利用される可能性があるか否かを判定する処理の詳細を示すフローチャートである。 実施形態１の次の処理要求受け付け時に各モジュールが利用される可能性があるか否かを判定した結果の保持例を示す図である。 実施形態１の次の処理要求受け付け時に各モジュールが利用される可能性があるか否かを判定した結果の概念図を示す図である。 実施形態２のモジュール毎の割当可能処理リソース情報の一例を示す図である。 実施形態２の実現手順を示すフローチャートである。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

＜実施形態１＞
以下、本発明の実施形態１について図面及びフローチャートを用いて説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。

図１は実施形態１の情報処理装置の構成を示すブロック図である。

図中、１０１は処理要求実行部であり、アプリケーションからの処理要求を受け付け、該当処理を実現するための複数の内部命令に変換した後、各モジュールに命令を送信する。ここで、処理要求とは、該当システムにて処理可能な制御命令を示しており、デジタルテレビの例ではユーザのリモコン操作等に伴い生じるストリーム処理開始要求やパラメータ変更要求等を想定する。また、これらの処理要求を実行するためには、あらかじめ利用する処理リソースを確保しておかなければならない。この処理リソースの確保処理については、処理リソース割当部１０３に説明を加える際に補足する。

１０２は処理リソース割当パターン保持部であり、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する。ここで、処理リソースとは、各モジュールが提供する単位機能を実行するために占有すべきリソースの総称であり、ハードウェア／ソフトウェアの動作やデータの１次記憶に必要なメモリ領域、モジュール間でデータや制御信号を授受する通信帯域等を含んでいる。この処理リソースは、論理的な単位であり、必ずしもハードウェアと１対１に対応する必要はなく、単一のモジュールに複数の処理リソースが入っていても良い。例えば、ダブルチューナのように単一のモジュールで複数の単位機能を提供するモジュールは、１つのモジュールの内部に２つの処理リソースを包含する構造となる。

１０３は処理リソース割当部であり、割当可能処理リソース情報を持ち、処理要求実行部１０１が受け付けた処理要求の処理要求種別と処理リソース割当パターン保持部１０２に保持されている処理リソース割当パターンを用いて処理リソースを割り当てる。必要な処理リソースが利用可能であり、割当に成功した場合は割当可能処理リソース情報を更新する。一方で、必要な処理リソースの一部もしくは全部が現在利用不可能であり、割当に失敗した場合はその旨を処理要求実行部１０１に伝え、該当処理を中断する。この場合、処理要求実行部１０１は該当処理を中止する。この処理リソースの割当及び割当可能処理リソース情報の更新は、例えば、新たなストリームに対する最初の処理要求を受け付けたタイミングで実行され、以降、該当ストリームに対する処理が続く限り、この割当可能処理リソース情報が保持される。

１０４はモジュール制御部であり、各モジュールにそれぞれ存在し、処理要求実行部１０１から命令を受け付けてモジュール固有の処理を実行する。尚、図１では、Ｎ個のモジュール１〜Ｎが存在する。

１０５は電力状態決定部であり、処理リソース割当パターン保持部１０２に保持されている処理リソース割当パターンと、処理リソース割当部１０３に保持されている割当可能処理リソース情報とから、各モジュールの電力状態を決定する。

１０６はモジュール状態管理部であり、各モジュールにそれぞれ存在する。モジュール状態管理部１０６は、少なくとも通常状態と、通常状態に比べ消費電力の少ない省電力状態とを持ち、電力状態決定部１０５が決定した各モジュールの電力状態情報を受け付けて各モジュールの電力状態を遷移させる。

尚、図１の情報処理装置は、汎用コンピュータに搭載される標準的な構成要素（例えば、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスク、外部記憶装置、ネットワークインタフェース、ディスプレイ、キーボード、マウス等）を有している。

図２は本発明の実施形態１の処理リソース割当パターン保持部１０２が保持する処理要求種別情報及び処理の実行に必要な処理リソース情報の具体例の概念図である。この具体例は、デジタルテレビのような映像ストリーム処理システムを想定しており、対象とするシステムが５つの処理要求種別を受け付け可能なシステムであることを表している。

特に、図２では、処理要求種別情報として、「デジタル放送視聴Ａ」、「デジタル放送視聴Ｂ」、「デジタル放送をＩＥＥＥ１３９４出力」、「デジタル放送をＨＤＤ録画」及び「ＮｅｔＴＶを視聴」が示されている。

また、２０１〜２０５はそれぞれの処理要求種別情報が示す処理要求を実行するために必要な処理リソース群を表している。例えば、「デジタル放送視聴Ａ」処理要求は、チューナ入力リソース２０６をはじめ、計６つの処理リソースを利用することにより実現される処理となる。

図３は本発明の実施形態１の処理リソース割当パターン保持部１０２が保持する処理要求種別情報及び処理の実行に必要な処理リソース情報の保持例を表しており、図２の概念図で表される情報と等価である。図中、表３００は保持する処理要求種別情報及び処理の実行に必要な処理リソース情報全体を表している。行３０１〜行３０５はそれぞれの処理要求種別である。各行３０１〜行３０５における処理要求種別では、処理要求種別が示す処理要求を実行するために必要な処理リソースの種類とその数が列単位で管理されており、それぞれ図２の処理リソース群２０１〜２０５に対応する。また、例えば、列３０６は処理リソース１つであり、図２のチューナ入力リソースに対応する。

図４は本発明の実施形態１の処理リソース割当部１０３が保持するモジュール毎の割当可能処理リソース情報に関する具体例の概念図である。この具体例では、デジタルテレビのような映像ストリーム処理システムを想定しており、入力ストリームに対するチューナ入力、Ｄｅｍｕｘ、ＡＶデコード、画像処理等のフィルタ処理をくり返すことによって出力ストリームに変換する処理系を想定している。

図中、表４００はシステム全体のモジュール構成を表しており、この例では全１２モジュールが連携動作することによりシステムが所定の機能を提供する。４０１はモジュール１を表し、このモジュールが２つのチューナ入力リソースを提供していることを表している。このように、モジュールと処理リソースが１対多の関係であって良いし、１つのモジュールが処理内容の大きく異なる２つ以上の処理リソースを包含していても良い。

図５は本発明の実施形態１の処理リソース割当部１０３が保持するモジュール毎の割当可能処理リソース情報の保持例を表しており、図４の概念図で表される情報と等価である。

図中、表５００はモジュール毎の割当可能処理リソース情報を表している。行５０１はモジュール１が２つのチューナ入力リソースを提供していることを表しており、これはシステム４００を構成するモジュール４０１の情報を表している。列５０２〜列５０４は、それぞれ処理リソース種別を表している。この具体例では、本システム内に全１２種の処理リソース種別が存在している。

図６は本発明の実施形態１の処理リソース割当部１０３が保持する割当可能処理リソース数の保持例を表している。

図中、表６００は割当可能な処理リソースの総数を表している。この具体例では、特にシステムが何ら処理要求を受け付けていない状態での割当可能処理リソース数が保持されている。この時点では、表６００が示す割当可能な処理リソースの総数は、モジュール毎の割当可能処理リソース情報５００より得られるシステム内に存在する処理リソースの総数と等価である。

図７は本発明の実施形態１の処理リソース割当部１０３が保持する割当可能処理リソース数の異なる一例を表している。

図中、表７００は割当可能な処理リソースの総数を表している。この具体例では、システムが特定の処理要求を受け付けた結果として、割当済の処理リソース数が、表６００が示す割当可能な処理リソースの総数から差し引かれた一例を示している。

図８（ａ）は本発明の実施形態１のモジュール状態管理部１０６が保持する各モジュールの状態図の一例を表している。図中、８０１は通常状態を表し、該当モジュールが相当量の電力を消費しながら動作している状態を表している。より具体的には、例えば、該当モジュールが利用されている、もしくは利用されていないがソフトウェアのロード・パラメータの初期化が終了し、ポーリング処理等の必要な処理を実行中の状態を想定する。また、ハードウェアは通常稼動している。

８０２は省電力状態であり、該当モジュールの消費電力が通常状態８０１に比べて少ない状態を表している。より具体的には、例えば、ソフトウェア面ではアンロードされている状態、もしくはロードされているがパラメータの初期化が終了していない状態や、タイマ起動による定期監視処理等のＣＰＵリソースを消費する処理を実施していない状態を想定する。また、ハードウェア面では、例えば、クロック周波数を低下させている状態を想定する。

８０３〜８０５は、状態間の遷移可能性を表している。８０３は、該当モジュールの起動処理が終了後すぐに、該当モジュールが通常状態８０１に遷移することを表している。８０４は、該当モジュールが通常状態８０１にある時にｅｖＳｕｓｐｅｎｄイベントを受け付けると、省電力状態８０２に遷移することを表している。このｅｖＳｕｓｐｅｎｄイベントは、電力状態決定部１０５から各モジュール状態管理部１０６に送信されることを想定するが、その送信タイミングの詳細については後述する。

８０５は、該当モジュールが省電力状態８０２にある時にｅｖＲｅｓｕｍｅイベントを受け付けると、通常状態８０１に遷移することを表している。このｅｖＲｅｓｕｍｅイベントについても、電力状態管理部１０６から各モジュール状態管理部１０６に送信されることを想定するが、その送信タイミングについては後述する。

図８（ｂ）は本発明の実施形態１のモジュール状態管理部１０６が保持する各モジュールの状態図の異なる一例を表している。図中、８０６は８０１と同様に通常状態を表し、８０７は８０２と同様に省電力状態を表している。ここで、通常状態８０６は、内部にさらに実行準備状態８０８と実行中状態８０９を持ち、該当モジュールの状態をより詳細に管理する。実行準備状態８０８は、例えば、処理を受け付け可能であるが実処理を実行していない状態、実行中状態８０９は、例えば、実処理を実行している状態を表している。このように、各モジュールが保持する状態は、通常状態８０１及び省電力状態８０２がそれぞれ内部にさらに状態を持ち、拡張されていても良い。また、システムを構成する各モジュールが、図８（ａ）に対してそれぞれ異なる拡張を適用することにより、それぞれ異なる状態図を持っていても良い。

図９は本発明の実施形態１の実現手順を示すフローチャートである。以下では、本フローチャートに沿って、図２〜図８の具体例を交えながら説明を加える。

ステップＳ９０１で、システムが起動される。ここでは、モジュール制御部１０４がシステム（処理要求実行部１０１）からの起動命令を受けて、各モジュールの初期化処理を実施する。その結果、モジュール状態管理部１０６が保持するモジュール状態が通常状態８０１に遷移する等の処理が実行される。また、初期化処理の一環として処理リソース割当部１０３対して各モジュールが保持する割当可能処理リソース情報５００を通知する等の操作が想定される。図５の具体例では、モジュール１より行５０１の情報が処理リソース割当部１０３に対して伝達され、処理リソース割当部１０３はこの情報を保持する。

尚、各モジュールが保持する割当可能処理リソース情報５００は、上記のごとくシステムの初期化時に各モジュールから伝達されても良いし、構成モジュールの変更がないシステムでは、あらかじめ処理リソース割当部１０３が静的に保持しておいても良い。

ステップＳ９０２で、以降のステップＳ９０３からステップＳ９０８までの処理を、システムが起動している間くり返す。

ステップＳ９０３で、処理要求実行部１０１は、実行中の処理要求の増減を監視する。処理要求が増加する具体例としては、ユーザからの処理開始命令やシステム内部のタイマの発火によって新たな処理要求が発生し、処理要求実行部１０１が処理を受け付けた場合がある。一方で、処理要求が減少する具体例としては、ユーザからの処理終了命令や実行中の処理が完了した場合等がある。

ここでは、処理が何ら発生していない状態から、行３０４で示される「デジタル放送をＨＤＤ録画」処理要求が投入された場合、すなわち、処理要求が増加した場合を具体例として、以降の説明を進める。上記処理要求を受け付けた場合は、処理リソース割当部１０３が保持する受け付け前の割当可能処理リソース数６００が、「デジタル放送をＨＤＤ録画」処理要求に割り当てた処理リソース分だけ減少し、割当可能処理リソース数７００に変化する。

ステップＳ９０４で、電力状態決定部１０５は、現在実行中の処理要求と並行し、次の処理要求として各処理要求種別を受け付け可能か否かを判定する。この判定は、各処理要求を実行するために必要な処理リソース情報３００と、現在の割当可能処理リソース数７００とを用いて実行される。尚、ここでの判定処理については後述する。

ステップＳ９０５で、電力状態決定部１０５は、次の処理要求で各処理リソースが利用される可能性があるか否かを判定する。この判定は、ステップＳ９０４の処理結果と、各処理要求を実行するために必要な処理リソース情報３００とを用いて実行される。尚、ここでの判定処理については後述する。

ステップＳ９０６で、電力状態決定部１０５は、次の処理要求で各モジュールが利用される可能性があるか否かを判定する。この判定は、ステップＳ９０５の処理結果と、モジュール毎の割当可能処理リソース情報５００とを用いて実行される。尚、ここでの判定処理については後述する。

ステップＳ９０７で、各モジュールのモジュール状態管理部１０６は、電力状態決定部１０５からの命令を受けて電力状態を更新する。この更新は、ステップＳ９０６の処理結果を用いて実行され、該モジュールが次の処理要求で利用される可能性があると判定された場合は通常状態に、次の処理要求で利用される可能性がないと判定された場合は省電力状態に遷移する。この状態遷移は、例えば、電力状態決定部１０５からモジュール状態管理部１０６に対してイベントを送信することによって実現される。

図８（ａ）の具体例では、電力状態決定部１０５が省電力状態に遷移させたいと判定した場合には、電力状態決定部１０５はモジュール状態管理部１０６に対してｅｖＳｕｓｐｅｎｄを発行する。これを受け付けたモジュール状態管理部１０６は、通常状態であった場合には省電力状態に遷移し、例えば、ＣＰＵのクロックを低下させる等の電力消費を抑える動作を実施する。一方、モジュール状態管理部１０６で管理する状態が既に省電力状態であった場合には、送信されたイベントであるｅｖＳｕｓｐｅｎｄを無視し、何もしない。

図１０は電力状態決定部１０５により現在、次の処理要求として各処理要求種別の処理要求を受け付け可能か否かを判定する処理の詳細を示すフローチャートであり、これは図９のステップＳ９０４に対応する。

図中、ステップＳ１００１で、電力状態決定部１０５は、以降のステップＳ１００２からステップＳ１０１０までの処理を、図３の行３０１〜３０５それぞれが示す処理要求種別のそれぞれについて実施する。

ステップＳ１００２で、電力状態決定部１０５は、新たに１つの処理要求種別を取り出し、処理要求種別Ｊａとする。図２〜図８の具体例では、「デジタル放送をＩＥＥＥ１３９４出力」処理要求が選択されたとして、以降の処理を説明する。

ステップＳ１００３で、電力状態決定部１０５は、以降のステップＳ１００４からステップＳ１００７までの処理を、図５の列５０２〜５０４それぞれが示す処理リソース種別のそれぞれについて実施する。

ステップＳ１００４で、電力状態決定部１０５は、新たに１つの処理リソース種別を取り出し、処理リソース種別Ｒａとする。図２〜図８の具体例では、「Ｒｅｍａｘリソース」が選択されたとして、以降の処理を説明する。

ステップＳ１００５で、電力状態決定部１０５は、処理要求種別Ｊａの処理要求を実行するために、処理リソース種別Ｒａの処理リソースが必要であるか否かを判定する。ここで、必要であると判定した場合（ステップＳ１００５でＹＥＳ）、ステップＳ１００６に進む。一方、必要でないと判定した場合（ステップＳ１００５でＮＯ）、ステップＳ１００７に進む。上記具体例では、処理要求種別毎の必要な処理リソース情報３０３より「デジタル放送をＩＥＥＥ１３９４出力」処理要求を実行するために「Ｒｅｍｕｘリソース」が１以上で必要であると判定されるため、ステップＳ１００６に進む。

ステップＳ１００６で、電力状態決定部１０５は、現在、処理リソース種別Ｒａの処理リソースが利用可能か否かを判定する。ここで、利用可能と判定した場合（ステップＳ１００６でＹＥＳ）、ステップＳ１００７に進む。一方、利用不可能と判定した場合（ステップＳ１００６でＮＯ）、ステップＳ１００８に進む。上記具体例では、現在の割当可能処理リソース数７００より「Ｒｅｍｕｘリソース」の残数が０であり利用不可能と判定されるため、ステップＳ１００８に進む。

ステップＳ１００８で、電力状態決定部１０５は、利用不可能な処理リソースが存在するために、現在、処理要求種別Ｊａの処理要求を受け付け不可能と判定する。上記具体例では、現在、「デジタル放送をＩＥＥＥ１３９４出力」処理要求は受け付け不可能と判定される。

ステップＳ１００９に到達する場合は、必要な処理リソースがすべて利用可能なため、現在、処理要求種別Ｊａの処理要求を受け付け可能と判定する。以上の処理をもって、すべての処理要求種別に対して現在受け付け可能か否かが判定される。

図１１はステップＳ９０４によって次の処理要求として各処理要求種別の処理要求を受け付け可能か否かを判定した結果の保持例を示しており、図２〜図８の具体例において「デジタル放送をＨＤＤ録画」処理要求を実行中の場合の判定結果である。この例では、現在、「デジタル放送をＩＥＥＥ１３９４出力」処理要求及び「デジタル放送をＨＤＤ録画」処理要求が受け付けられないことを表している。

図１２は電力状態決定部１０５により次の処理要求を受け付け時に各処理リソース種別の処理リソースを利用する可能性があるか否かを判定する処理の詳細を示すフローチャートであり、これは図９のステップＳ９０５に対応する。

図中、ステップＳ１２０１で、電力状態決定部１０５は、以降のステップＳ１２０２からステップＳ１２０９までの処理を、処理リソース種別５０２〜５０４のそれぞれについて実施する。

ステップＳ１２０２で、電力状態決定部１０５は、新たに１つの処理リソース種別を取り出し、処理リソース種別Ｒｂとする。図２〜図８の具体例では、「ＩＥＥＥ１３９４出力リソース」が選択されたとして、以降の処理を説明する。

ステップＳ１２０３で、電力状態決定部１０５は、以降のステップＳ１２０４からステップＳ１２０６までの処理を、現在受け付け可能な処理要求種別のそれぞれについて実施する。図１１の具体例では、「デジタル放送をＩＥＥＥ１３９４出力」処理要求及び「デジタル放送をＨＤＤ録画」処理要求以外の３つの処理要求について、以降の処理を実施する。

ステップＳ１２０４で、電力状態決定部１０５は、新たに、現在受け付け可能な処理要求種別を１つ取り出し、処理要求種別Ｊｂとする。図２〜図８の具体例では、「デジタル放送視聴Ａ」処理要求が選択されたとして、以降の処理を説明する。

ステップＳ１２０５で、電力状態決定部１０５は、処理要求種別Ｊｂの処理要求を実行するために処理リソース種別Ｒｂの処理リソースが必要であるか否かを判定する。ここで、必要であると判定した場合（ステップＳ１２０５でＹＥＳ）、ステップＳ１２０７に進む。一方、必要でないと判定した場合（ステップＳ１２０５でＮＯ）、ステップＳ１２０６に進む。上記具体例では、「デジタル放送視聴Ａ」処理要求の実行にあたり「ＩＥＥＥ１３９４出力リソース」を必要としないため、ステップＳ１２０６に進む。

ステップＳ１２０７に到達した場合は、処理要求種別Ｊｂの次の処理要求を実行する際に処理リソース種別Ｒｂの処理リソースを利用する可能性があると判定する。ここで、一度でもこの処理ステップに到達した処理要求種別Ｊｂは、次の処理要求を実行する際に利用される可能性がある。

ステップＳ１２０８に到達した場合は、処理要求種別Ｊｂの次の処理要求を実行する際に処理リソース種別Ｒｂの処理リソースを利用する可能性がないと判定する。

図１３はステップＳ９０５によって次の処理要求で、各処理リソースが利用される可能性があるか否かを判定した結果の保持例を示しており、図２〜図８の具体例において「デジタル放送をＨＤＤ録画」処理要求が実行中の場合の判定結果である。この例では、現在、「Ｒｅｍａｘリソース」、「ＨＤＤ出力リソース」、及び「ＩＥＥＥ１３９４出力リソース」が次の処理要求で利用される可能性がないことを表している。

図１４は電力状態決定部１０５により次の処理要求で、各モジュールが利用される可能性があるか否かを判定する処理の詳細を示すフローチャートであり、これは図９のステップＳ９０６に対応する。

図中、ステップＳ１４０１で、電力状態決定部１０５は、以降のステップＳ１４０２からステップＳ１４１０までの処理を、システムに存在するモジュールのそれぞれについて実施する。

ステップＳ１４０２で、電力状態決定部１０５は、新たに１つのモジュールを取り出し、モジュールＭとする。図２〜図８の具体例では、「モジュール１２」が選択されたとして、以降の処理を説明する。

ステップＳ１４０３で、電力状態決定部１０５は、現在モジュールＭに含まれる処理リソースが利用されているか否かを判定する。ここで、利用されていると判定した場合（ステップＳ１４０３でＹＥＳ）、ステップＳ１４０８に進む。一方、利用されていないと判定した場合（ステップＳ１４０３でＮＯ）、ステップＳ１４０４に進む。この処理ステップは、現在利用されているモジュールは、次の処理要求を受け付けても引き続き利用されつづける可能性があることを鑑み、実行される。上記具体例では、「モジュール１２」は現在利用されていないと判定されるため、ステップＳ１４０４に進む。

ステップＳ１４０４で、電力状態決定部１０５は、以降のステップＳ１４０５からステップＳ１４０７までの処理を、次の処理要求で利用する可能性のある処理リソース種別のそれぞれについて実施する。

ステップＳ１４０５で、電力状態決定部１０５は、新たに１つの次の処理要求で利用する可能性のある処理リソース種別を取り出し、処理リソース種別Ｒｃとする。上記具体例では、表１３００より「チューナ入力リソース」が選択されたとして、以降の説明を続ける。

ステップＳ１４０６で、電力状態決定部１０５は、モジュールＭが処理リソース種別Ｒｃの処理リソースを提供しているか否かを判定する。ここで、提供していると判定した場合（ステップＳ１４０６でＹＥＳ）、ステップＳ１４０８に進む。一方、提供していないと判定した場合（ステップＳ１４０６でＮＯ）、ステップＳ１４０７に進む。上記具体例では、「モジュール１２」は「チューナ入力リソース」を提供していないと判定されるため、ステップＳ１４０７に進む。

ステップＳ１４０８に到達した場合は、次の処理要求でモジュールＭを利用する可能性があると判定される。

ステップＳ１４０９に到達した場合は、次の処理要求でモジュールＭを利用する可能性がないと判定される。

図１５はステップＳ９０６によって次の処理要求で、各モジュールが利用される可能性があるか否かを判定した結果の保持例を示しており、図２〜図８の具体例において「デジタル放送をＨＤＤ録画」処理要求が実行中の場合の判定結果である。この例では、現在、「モジュール１２」が次の処理要求で利用される可能性がないことを表している。

また、図１６は、各モジュールが利用される可能性があるか否かを判定した結果の概念図を表している。図中、１６０１のように太線で囲まれたモジュールが現在利用中のモジュールを表している。また、１６０２のように通常線で囲まれたモジュールが次の処理要求で利用される可能性のあるモジュールを表している。また、１６０３のように破線で囲まれたモジュールは上記の処理によって次の処理要求で利用される可能性がないと判定されたため、省電力状態に遷移可能なモジュールを表している。上記例では、「モジュール１２」が省電力状態に遷移可能なモジュールとなる。

以上説明したように、実施形態１によれば、モジュール毎に近い将来の利用可能性を判定し、その判定結果をもとに通常状態／省電力状態を切り替えて動作させることにより、システムの応答性と省電力を両立させる。より具体的には、次回の処理ステップ（命令）で使用される可能性のあるモジュールのみを動作させ、次回の処理ステップで利用される可能性のないモジュールは省電力状態で動作させる。これにより、システムの応答性を確保しつつも省電力を実現することが可能となる。

上記具体例では、「デジタル放送をＨＤＤ録画」処理要求が実行中の場合は、この処理要求が実行されている間は次の処理要求にて「モジュール１２」が利用されないと判別でき、「モジュール１２」を省電力状態に遷移させる。これにより、システムの応答性に影響を与えないでシステムの消費電力を抑制することが可能となる。

また、実施形態１では、図４に示したシステム内のモジュール構成を例に処理の詳細を説明しているが、実施形態１は、他の構成を有する情報システムにも適用可能である。

＜実施形態２＞
以下、本発明の実施形態２について、実施形態１との差異を中心に説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。

図１７は、図４のシステム４００に、新たに１７０１で示される「モジュール１３」が追加された場合を想定し、モジュール毎の割当可能処理リソース情報の一例を表している。ここで、モジュールの追加はシステム起動前に発生しても良いし、システム起動中に動的に発生しても良い。

図１８は本発明の実施形態２の実現手順を示すフローチャートである。以下では、本フローチャートに沿って、図２〜図８の具体例を交えながら説明を加える。

ステップＳ１８０１で、以降のステップＳ１８０２からＳ８０７までの処理を、システムが起動している間くり返す。

ステップＳ１８０２で、処理要求実行部１０１は、利用可能な処理モジュールが増減を監視する。ここでは、図１７に示した通り新たに「モジュール１３」として「Ｒｅｍａｘリソース」が追加されたとする。

ステップＳ１８０３で、電力状態決定部１０５は、現在実行中の処理要求と並行し、次の処理要求として各処理要求種別を受け付け可能か否かを判定する。この判定は、各処理要求を実行するために必要な処理リソース情報と、現在の割当可能処理リソース数とを用いて実行される。尚、この処理の詳細は実施形態１に準ずる。

ステップＳ１８０４で、電力状態決定部１０５は、次の処理要求で各処理リソースが利用される可能性があるか否かを判定する。この判定は、ステップＳ１８０３の処理結果と、各処理要求を実行するために必要な処理リソース情報とを用いて実行される。尚、この処理の詳細は実施形態１に準ずる。

ステップＳ１８０５で、電力状態決定部１０５は、次の処理要求で各モジュールが利用される可能性があるか否かを判定する。この判定は、ステップＳ１８０４の処理結果と、モジュール毎の割当可能処理リソース情報とを用いて実行される。尚、この処理の詳細は実施形態１に準ずる。

ステップＳ１８０６で、各モジュールのモジュール状態管理部１０６が、電力状態決定部１０５からの命令を受けて電力状態を変更する。この変更は、ステップＳ１８０５の処理結果を用いて実行され、該モジュールが次の処理要求で利用される可能性があると判定された場合は通常状態に、次の処理要求で利用される可能性がないと判定された場合は省電力状態に遷移する。尚、この処理の詳細は実施形態１に準ずる。

以上の処理を経ることにより、例えば、「デジタル放送をＨＤＤ録画」処理要求が投入された場合でも「Ｒｅｍａｘリソース」が枯渇しない。そのため、「ＩＥＥＥ１３９４出力」処理要求が実行される可能性が残り、その結果「モジュール１２」は省電力状態に遷移しない。また、特定のモジュールの機能が停止した場合も、同様の処理フローを経ることにより各モジュールの電力状態を判定可能である。

以上説明したように、実施形態２によれば、モジュール構成の変更（例えば、追加）を検知した場合でも、各モジュールの電力状態を再判定する構成をとることで、モジュール構成の変更に柔軟に対応した省電力制御が可能となる。

尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (8)

1. それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置であって、
   処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する処理リソース割当パターン保持部と、
   受け付けた処理要求の処理要求種別と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンに基づいて、前記処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する処理リソース割当部と、
   前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する電力状態決定部と
   を有することを特徴とする情報処理装置。
2. 前記電力状態決定部は、前記処理リソース割当パターンと前記割当可能処理リソース情報とから、現在受け付け可能な処理要求の処理要求種別を判定し、前記受け付け可能な処理要求のいずれかが実行された場合に利用される処理リソースを、前記次の処理要求にて利用される可能性があると判定する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記電力状態決定部は、前記複数のモジュールの内、前記次の処理要求にて利用される可能性があると判定された前記割り当て可能処理リソースを有するモジュールの電力状態を通常状態に遷移させ、前記次の処理要求にて利用される可能性がないと判定された前記割り当て可能処理リソースを有するモジュールの電力状態を前記通常状態に比べ消費電力の少ない省電力状態に遷移させる
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記電力状態決定部は、前記処理リソース割当部が保持する前記割当可能処理リソース情報の更新に合わせて、前記複数のモジュールの各モジュールの電力状態を更新する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記処理リソース割当部は、モジュールから機能の停止を受け付けた場合には、前記割当可能処理リソース情報を更新し、
   前記電力状態決定部は、前記処理リソース割当部が保持する前記割当可能処理リソース情報の更新に合わせて、前記複数のモジュールの各モジュールの電力状態を更新する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
6. 前記処理リソース割当部は、処理リソースの追加を受け付けた場合には、前記割当可能処理リソース情報を更新し、
   前記電力状態決定部は、前記処理リソース割当部が保持する前記割当可能処理リソース情報の更新に合わせて、前記複数のモジュールの各モジュールの電力状態を更新する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
7. それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置の制御方法であって、
   処理リソース割当パターン保持部が、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを記憶媒体に保持する保持工程と、
   処理リソース割当部が、受け付けた処理要求の処理要求種別と、前記記憶媒体に保持されている前記処理リソース割当パターンに基づいて、前記受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する更新工程と、
   電力状態決定部が、前記記憶媒体に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する決定工程と
   を有することを特徴とする情報処理装置の制御方法。
8. それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置の制御をコンピュータに機能させるためのプログラムであって、
   前記コンピュータを、
   処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する処理リソース割当パターン保持部と、
   受け付けた処理要求の処理要求種別と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンに基づいて、前記受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する処理リソース割当部と、
   前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する電力状態決定部と
   して機能させることを特徴とするプログラム。

Images