(57)【要約】【課題】各デバイスのリソースを最適なリソースに容易かつ迅速に調整する。【解決手段】リソース使用状況取得手段２は、コンピュータ１にて動作中のアプリケーションを動作させるデバイスのリソースの使用状況を取得する。輻輳判定手段３は、リソース使用状況取得手段２が取得したリソースの使用状況を監視し、アプリケーション間の輻輳の発生を判定する。輻輳調整手段４は、輻輳の発生時に、リソースの使用状況とデータベース６に格納されているデバイスのリソースの情報とに基づいて輻輳が解消するように調整する。データベース更新手段５は、輻輳調整手段４により調整されたデバイス毎のリソースの最適値をデータベース６に反映する。【選択図】図１
2009193206.tif 000002
【特許請求の範囲】
【請求項１】
処理対象のアプリケーションのリソースを管理するリソース管理プログラムにおいて、
コンピュータを、
動作中の前記アプリケーションを動作させるデバイスのリソースの使用状況を取得するリソース使用状況取得手段、
前記リソース使用状況取得手段が取得した前記リソースの使用状況を監視し、輻輳の発生を判定する輻輳判定手段、
輻輳の発生時に、前記リソースの使用状況とデータベースに格納されている前記デバイスの前記リソースの情報とに基づいて輻輳が解消するように調整する輻輳調整手段、
前記輻輳調整手段により調整された前記リソースの最適値を前記データベースに反映するデータベース更新手段、
として機能させることを特徴とするリソース管理プログラム。
【請求項２】
前記輻輳調整手段は、調整優先情報により定められた優先順位に基づいて、輻輳調整を行うことを特徴とする請求項１記載のリソース管理プログラム。
【請求項３】
前記リソース使用状況取得手段は、前記アプリケーションが動作中に、定期的に前記リソースの使用状況を取得することを特徴とする請求項１記載のリソース管理プログラム。
【請求項４】
処理対象のアプリケーションのリソースを管理するリソース管理方法において、
リソース使用状況取得手段が、動作中の前記アプリケーションを動作させるデバイスのリソースの使用状況を取得し、
輻輳判定手段が、前記リソース使用状況取得手段が取得した前記リソースの使用状況を監視し、輻輳の発生を判定し、
輻輳調整手段が、輻輳の発生時に、前記リソースの使用状況とデータベースに格納されている前記デバイスの前記リソースの情報とに基づいて輻輳が解消するように調整し、
データベース更新手段が、前記輻輳調整手段により調整された前記リソースの最適値を前記データベースに反映する、
ことを特徴とするリソース管理方法。
【請求項５】
処理対象のアプリケーションのリソースを管理するリソース管理装置において、
動作中の前記アプリケーションを動作させるデバイスのリソースの使用状況を取得するリソース使用状況取得手段と、
前記リソース使用状況取得手段が取得した前記リソースの使用状況を監視し、輻輳の発生を判定する輻輳判定手段と、
輻輳の発生時に、前記リソースの使用状況とデータベースに格納されている前記デバイスの前記リソースの情報とに基づいて輻輳が解消するように調整する輻輳調整手段と、
前記輻輳調整手段により調整された前記リソースの最適値を前記データベースに反映するデータベース更新手段と、
を有することを特徴とするリソース管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はリソース管理プログラム、リソース管理方法およびリソース管理装置に関し、特に、処理対象のアプリケーションのリソースを管理するリソース管理プログラム、リソース管理方法およびリソース管理装置に関する。
【背景技術】
【０００２】
昨今、ＡＶメディア情報のデータフォーマットは多岐に渡っており、そのフォーマットのデータ展開を行うに当たって、即時性、省電力、低リソースが常に求められている。
その中で、複数メディアストリームを制御する場合、様々なリソース（デコード用ハード、ドライバソフト等）を使用するため、システム全体として使用リソース量が最適かどうか把握するのが難しい。
【０００３】
このため、アプリケーション処理を機能毎に分割し、それぞれの機能が使用するリソース値をデータベース化してメディア構成変更時に参照することで輻輳制御を行う技術が知られている（例えば、特許文献１参照）。
【特許文献１】特開２００４−３４８４３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、アプリケーション処理を行う各機能で使用するリソース値のデータベースを更新する契機がないため、実際にシステムが動作した場合のリソース量との不一致が発生した場合、データベース値を手動で修正する必要がある。
【０００５】
また、リソース使用量に揺らぎが発生し、最適な値に幅が必要な場合の調整も容易ではない。
本発明はこのような点に鑑みてなされたものであり、各デバイスのリソースを最適なリソースに容易かつ迅速に調整することができるリソース管理プログラム、リソース管理方法およびリソース管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、以下のようなリソース管理プログラムが提供される。このリソース管理プログラムは、処理対象のアプリケーションのリソースを管理するものであり、コンピュータを、リソース使用状況取得手段、輻輳判定手段、輻輳調整手段、およびデータベース更新手段として機能させる。
【０００７】
リソース使用状況取得手段は、動作中のアプリケーションを動作させるデバイスのリソースの使用状況を取得する。
輻輳判定手段は、リソース使用状況取得手段が取得したリソースの使用状況を監視し、輻輳の発生を判定する。
【０００８】
輻輳調整手段は、輻輳の発生時に、リソースの使用状況とデータベースに格納されているデバイスのリソースの情報とに基づいて輻輳が解消するように調整する。
データベース更新手段は、輻輳調整手段により調整されたリソースの最適値をデータベースに反映する。
【０００９】
このようなリソース管理プログラムによれば、リソース使用状況取得手段により、デバイスのリソースの使用状況が取得される。輻輳判定手段により、リソース使用状況取得手段によって取得されたリソースの使用状況が監視され、輻輳の発生が判定される。輻輳の発生時には、輻輳調整手段により、リソースの使用状況とデータベースに格納されているデバイスのリソースの情報とに基づいて輻輳が解消するように調整される。データベース更新手段により、輻輳調整手段によって調整されたリソースの最適値がデータベースに反映される。
【発明の効果】
【００１０】
開示のリソース管理プログラム、リソース管理方法およびリソース管理装置によれば、輻輳が解消するよう調整されるため、処理の効率化を図ることができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
まず、本発明の概要について説明し、その後、実施の形態を説明する。
図１は、本発明の概要を示す図である。
【００１２】
リソース管理プログラムは、処理対象のアプリケーションのリソースを管理するものであり、コンピュータ１を、リソース使用状況取得手段２、輻輳判定手段３、輻輳調整手段４、およびデータベース更新手段５として機能させる。
【００１３】
リソース使用状況取得手段２は、コンピュータ１にて動作中のアプリケーションを動作させるデバイスのリソースの使用状況を取得する。
デバイスとしては、例えばデコード用ハードデバイスや、ドライバソフト等が挙げられる。
【００１４】
リソースの使用状況の取得のタイミングは特に限定されないが、例えばアプリケーションの動作中に不定期または周期的に行う。
輻輳判定手段３は、リソース使用状況取得手段２が取得したリソースの使用状況（具体的には、ＣＰＵ（Central Processing Unit）の負荷、使用メモリ量、消費電力、スループット等）を監視し、アプリケーション間の輻輳の発生を判定する。
【００１５】
輻輳調整手段４は、輻輳の発生時に、リソースの使用状況とデータベース６に格納されているデバイスのリソースの情報とに基づいて輻輳が解消するように調整する。例えば、一部のメモリの使用量が多すぎれば、メモリ使用量を削減したり、一部の消費電力が多すぎれば、消費電力を下げたりする。また、アプリケーションの実行優先順位等に基づいて、先または後に開始したアプリケーションの処理を停止したりする。
【００１６】
データベース更新手段５は、輻輳調整手段４により調整されたデバイス毎のリソースの最適値をデータベース６に反映する。
これにより、次の輻輳調整時には、前回の輻輳調整により調整されたリソースの値が反映されることになり、リソースの値がより最適なものへと近づく。
【００１７】
以下、本発明の実施の形態を説明する。
図２は、リソース管理装置のハードウェア構成例を示す図である。
リソース管理装置１０は、ＣＰＵ１１ａ、１１ｂによって装置全体が制御されている。ＣＰＵ１１ａ、１１ｂには、バス１６を介してキーデバイス１２、メモリ１３、内部ソフトデバイス１４、内部ハードデバイス１５が接続されている。
【００１８】
キーデバイス１２には、キーボードやマウスが接続される。キーデバイス１２は、キーボードやマウスから送られてくる信号を、バス１６を介してＣＰＵ１１ａ、１１ｂに送信する。
【００１９】
メモリ１３は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を有している。ＲＡＭには、ＣＰＵ１１ａ、１１ｂに実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭには、ＣＰＵ１１ａ、１１ｂによる処理に必要な各種データが格納される。ＲＯＭには、ＯＳやアプリケーションプログラムが格納される。また、ＲＯＭ内には、プログラムファイルが格納される。
【００２０】
内部ソフトデバイス１４は、ソフトウェアで構成される複数の機能を有している。
内部ハードデバイス１５は、ハードウェアで構成される複数の機能を有している。
ＣＰＵ１１ａ、１１ｂは、内部ソフトデバイス１４および内部ハードデバイス１５が備える機能のうち、必要な機能を使用してスピーカ２１に音声信号を出力したり、ＬＣＤ２２に画像信号を出力したり、音声出力端子２３に音声信号を出力したりする。
【００２１】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。このようなハードウェア構成のシステムにおいてリソースの管理を行うために、リソース管理装置１０内には、以下のような機能が設けられる。
【００２２】
図３は、リソース管理装置の機能を示すブロック図である。
リソース管理装置１０は、アプリケーション処理部１１０と、輻輳監視部１２０と、データベース１３０とを有している。
【００２３】
アプリケーション処理部１１０は、メインアプリケーション処理部１１１と、静止画処理アプリケーション１１２ａと、静止画処理モジュール群１１２ｂと、映像音声再生アプリケーション１１３ａと、映像音声再生モジュール群１１３ｂと音声再生アプリケーション１１４ａと音声再生モジュール群１１４ｂとデバイス制御部１１２ｃ、１１３ｃ、１１４ｃとを有している。
【００２４】
メインアプリケーション処理部１１１は、主として、使用するアプリケーションの種別に応じて使用するデバイスを決定する。また、アプリケーションの実行に必要なリソースを取得し、使用するデバイスに割り当てる。
【００２５】
静止画処理アプリケーション１１２ａと、映像音声再生アプリケーション１１３ａと、音声再生アプリケーション１１４ａとは、それぞれメインアプリケーション処理部１１１によって処理される処理対象のアプリケーションである。
【００２６】
静止画処理アプリケーション１１２ａは、静止画（ＪＰＥＧ等）の表示処理を行うアプリケーションである。映像音声再生アプリケーション１１３ａは、動画像（ＭＰＥＧ４等）の再生処理を行うアプリケーションである。音声再生アプリケーション１１４ａは、音声（ＭＰ３等）の再生処理を行うアプリケーションである。
【００２７】
静止画処理モジュール群１１２ｂと映像音声再生モジュール群１１３ｂと音声再生モジュール群１１４ｂとは、それぞれ、対応する各アプリケーションが処理を行うための各種機能を備えている。
【００２８】
デバイス制御部１１２ｃ〜１１４ｃは、それぞれ対応する外部デバイスに接続されており、これらのデバイスに制御信号を出力する。例えば、デバイス制御部１１２ｃは、ＬＣＤ２２に接続されている。
【００２９】
輻輳監視部１２０は、メインアプリケーション処理部１１１により複数のアプリケーションが処理される場合、輻輳の発生を監視する。
輻輳監視部１２０は、リソース監視部１２１と輻輳調整部１２２とデータベース更新部１２３とを有している。
【００３０】
リソース監視部１２１は、メインアプリケーション処理部１１１が処理している各アプリケーションが使用しているリソースを監視する。また、実測値から輻輳が予測される場合、例えば、処理対象のアプリケーションの変更によりデバイスの種別が変更されたときやアプリケーションの処理中等に、輻輳調整部１２２に通知し、輻輳の調整を行わせる。
【００３１】
輻輳調整部１２２は、リソース監視部１２１の指示によって輻輳が発生しているか否かを判断する。そして、輻輳の発生を検出すると、データベース１３０を参照し、最適値と安全値の範囲を調整し、より低リソースで動作するように最適なリソースの値（リソース最適値）を算出する。調整後はデータベース更新部１２３に通知し、データベース更新を行わせる。
【００３２】
データベース更新部１２３は、輻輳調整部１２２が調整したリソースの値をデータベース１３０に反映する。
データベース１３０は、メモリ１３の一機能で構成されており、アプリケーションの種別、処理種別、ＣＰＵ構成、デバイス構成、スループット等の情報が格納されている。
【００３３】
次に、メインアプリケーション処理部１１１が行うアプリケーション処理を説明する。
図４は、アプリケーション処理を示すフローチャートである。
まず、メインアプリケーション処理部１１１が、現在処理しているアプリケーション構成の変更（新たなアプリケーションの実行）を待機する（ステップＳ１のＮｏ）。そして、アプリケーション構成の変更があれば（ステップＳ１のＹｅｓ）、リソース監視部１２１が動作しているか否かを判断する（ステップＳ２）。
【００３４】
リソース監視部１２１が動作している場合（ステップＳ２のＹｅｓ）、ステップＳ４に移行する。
一方、リソース監視部１２１が動作していない場合（ステップＳ２のＮｏ）、メインアプリケーション処理部１１１がリソース監視要求を出力する（ステップＳ３）。これにより、リソース監視部１２１が各アプリケーションのリソースが足りているか否かを監視するリソース監視処理を行う。なお、リソース監視処理については後に詳述する。その後、ステップＳ４に移行する。
【００３５】
その後、メインアプリケーション処理部１１１が各アプリケーションを処理するために必要なリソースを独自に算出したリソース基準値を算出する（ステップＳ４）。なお、リソース基準値については後に詳述する。
【００３６】
次に、メインアプリケーション処理部１１１が、算出したリソース基準値を輻輳監視部１２０に送り、その結果に応じて輻輳監視部１２０から出力されるリソース最適値を取得する（ステップＳ５）。
【００３７】
次に、メインアプリケーション処理部１１１が取得したリソースを、処理対象のアプリケーションに設定する（ステップＳ６）。
次に、メインアプリケーション処理部１１１が、処理対象のアプリケーションの処理を開始する（ステップＳ７）。
【００３８】
この際、メインアプリケーション処理部１１１がリソース監視部１２１を起動する（ステップＳ８）。これにより、リソース監視部１２１がリソース監視処理を行う。
その後、メインアプリケーション処理部１１１が、アプリケーション処理が終了したか否かを判断する（ステップＳ９）。
【００３９】
アプリケーション処理が終了していない場合（ステップＳ９のＮｏ）、アプリケーション処理の終了を待機する。
一方、アプリケーション処理が終了した場合（ステップＳ９のＹｅｓ）、ステップＳ１に移行して次の処理を待機する。
【００４０】
以上でアプリケーション処理の説明を終了する。
次に、リソース監視処理を説明する。
図５は、リソース監視処理を示すフローチャートである。
【００４１】
まず、メインアプリケーション処理部１１１からのリソース監視要求があるか否かを判断する（ステップＳ１１）。リソース監視要求がない場合（ステップＳ１１のＮｏ）、リソース監視要求を待機する。
【００４２】
リソース監視要求を受け取った場合（ステップＳ１１のＹｅｓ）、各アプリケーションの実際のリソース使用状況を取得する（ステップＳ１２）。
次に、このリソース使用状況に基づいて、各アプリケーション間で輻輳が発生しているか否かを判断する（ステップＳ１３）。なお、この判断方法については輻輳判定処理として後に詳述する。
【００４３】
輻輳が発生していない場合（ステップＳ１３のＮｏ）、ステップＳ１５に移行する。
一方、輻輳が発生している場合（ステップＳ１３のＹｅｓ）、輻輳を調整する輻輳調整処理を行う（ステップＳ１４）。なお、輻輳調整処理については、後に詳述する。その後、ステップＳ１５に移行する。
【００４４】
その後、全てのアプリケーション処理が終了したか否かを判断する（ステップＳ１５）。
全てのアプリケーション処理が終了していない場合（ステップＳ１５のＮｏ）、ステップＳ１１に移行して次の処理を待機する。
【００４５】
一方、全てのアプリケーション処理が終了した場合（ステップＳ１５のＹｅｓ）、リソース監視処理を終了する。
以上でリソース監視処理の説明を終了する。
【００４６】
次に、輻輳調整処理を説明する。
図６は、輻輳調整処理を示すフローチャートである。
輻輳調整部１２２が、リソース最適値を計算するリソース最適値算出処理を行う（ステップＳ２１）。なお、この処理については、後に詳述する。
【００４７】
次に、輻輳調整部１２２は、各アプリケーションが使用しているリソースの変更要求をメインアプリケーション処理部１１１に出力する（ステップＳ２２）。
次に、輻輳調整部１２２は、データベース更新部１２３に対し、データベース１３０にリソース最適値の内容を反映させるデータベース更新要求を出力する（ステップＳ２３）。
【００４８】
以上で輻輳調整処理の説明を終了する。
次に、図４にて説明したアプリケーション処理についてさらに詳しく説明する。
図７は、アプリケーション処理の初期動作を示すシーケンス図である。なお、図７では一例として静止画処理アプリケーション１１２ａを実行する場合について説明している。
【００４９】
静止画処理アプリケーション１１２ａは、アプリ処理準備要求をメインアプリケーション処理部１１１に出力する（ステップＳ３１）。
メインアプリケーション処理部１１１は、アプリ種別に応じて使用するデバイスを決定する（ステップＳ３２）。
【００５０】
メインアプリケーション処理部１１１は、アプリケーションの種別、処理種別、ＣＰＵ構成、デバイス構成、スループット等の情報の取得要求をデータベース更新部１２３に出力する（ステップＳ３３）。
【００５１】
データベース更新部１２３は、データベース１３０を検索する（ステップＳ３４）。
データベース更新部１２３は、検索して得られたアプリケーションの種別、処理種別、ＣＰＵ構成、デバイス構成、スループット等の情報をアプリケーション処理部１１１に出力する（ステップＳ３５）。
【００５２】
アプリケーション処理部１１１は、得られた情報に基づいてリソース基準値を算出する（ステップＳ３６）。
アプリケーション処理部１１１は、算出したリソース基準値の調整が必要か否かを判断するために、リソース監視要求を輻輳監視部１２０（輻輳調整部１２２）に出力する（ステップＳ３７）。
【００５３】
輻輳調整部１２２は、輻輳調整処理（内に含まれるリソース最適値算出処理）を行ってリソース最適値を算出する（ステップＳ３８）。
輻輳調整部１２２は、算出したリソース最適値をアプリケーション処理部１１１に出力する（ステップＳ３９）。
【００５４】
メインアプリケーション処理部１１１は、取得したリソース最適値に基づいて、リソースを取得する（ステップＳ４０）。
メインアプリケーション処理部１１１は、リソースを静止画処理アプリケーション１１２ａに割り当てる（ステップＳ４１）。
【００５５】
静止画処理アプリケーション１１２ａは、アプリ処理開始要求をメインアプリケーション処理部１１１に出力する（ステップＳ４２）。
メインアプリケーション処理部１１１は、静止画処理アプリケーション１１２ａにより送られたアプリ処理開始要求に基づいて、静止画処理アプリケーション１１２ａを起動する（ステップＳ４３）。
【００５６】
以上でアプリケーション処理の説明を終了する。
次に、リソース監視処理についてさらに詳しく説明する。
図８は、輻輳が発生していない場合のリソース監視処理を示すシーケンス図である。
【００５７】
メインアプリケーション処理部１１１は、リソース監視要求をリソース監視部１２１に出力する（ステップＳ５１）。
リソース監視部１２１は、各アプリケーションリソース使用状況（ＣＰＵ使用率、全体メモリ使用量、スループット（単位時間あたりの処理能力）等）を取得する（ステップＳ５２）。
【００５８】
リソース監視部１２１は、輻輳が発生しているか否かを判定する（ステップＳ５３）。
輻輳が発生していない場合、リソース監視部１２１は、調整不要をメインアプリケーション処理部１１１に応答する（ステップＳ５４）。
【００５９】
図９は、輻輳が発生した場合のリソース監視処理を示すシーケンス図である。
図８と同様の処理については、同様のステップ番号を付してその説明を省略する。
輻輳が発生している場合、リソース監視部１２１は、調整指示を輻輳調整部１２２に出力する（ステップＳ５５）。
【００６０】
調整指示を受け取った輻輳調整部１２２は、データベース更新部１２３にリソース使用状況に対応する情報の取得を指示し（ステップＳ５６）、これらの情報を取得する（ステップＳ５７）。そして、リソース最適値算出処理を行う（ステップＳ５８）。そして、算出したリソース最適値をメインアプリケーション処理部１１１に出力する（ステップＳ５９）。具体的には、調整が可能であった場合、リソース最適値を通知する。また、調整に失敗した場合、その旨を通知する。
【００６１】
また、データベース更新要求をデータベース更新部１２３に出力する（ステップＳ６０）。
調整結果を受け取ったメインアプリケーション処理部１１１は、リソースを更新する（ステップＳ６１）。具体的には、調整が可能であった場合、得られたリソース最適値に基づいて処理中の各アプリケーションのリソースを変更する。調整に失敗した場合、輻輳を検出したメディアの処理を停止し、メインアプリケーション処理部１１１に停止原因を通知する。
【００６２】
一方、データベース更新部１２３は、データベース更新処理を行ってリソース最適値をデータベース１３０に反映させる（ステップＳ６２）。その後、メインアプリケーション処理部１１１に更新終了を通知する（ステップＳ６３）。
【００６３】
次に、輻輳調整部１２２およびデータベース更新部１２３が備える各データを説明する。
図１０は、輻輳調整部およびデータベース更新部が備える各データを示す図である。
【００６４】
輻輳調整部１２２は、使用リソース情報と動作中アプリ処理情報と調整優先情報とを有している。
使用リソース情報は、輻輳調整部１２２が予め有している情報であり、ＣＰＵ１１ａ、１１ｂの性能を示すＣＰＵ管理情報と、内部ソフトデバイス１４および内部ハードデバイス１５が備える各機能の性能を示すデバイス管理情報とで構成されている。
【００６５】
動作中アプリ処理情報は、アプリケーションの動作中にデバイスから取得する情報である。この動作中アプリ処理情報は、シナリオ条件情報と動作中アプリ情報とＣＰＵ動作情報とデバイス動作情報と調整消費電力値とで構成されている。
【００６６】
調整優先情報は、輻輳調整部１２２が予め有している情報であり、リソース調整時に使用する。
データベース更新部１２３は、データベース１３０にリソース調整後の値を蓄積するための使用リソースＤＢ（データベース）管理情報を有している。
【００６７】
次に、これらの情報の内容について詳しく説明する。
図１１は、ＣＰＵ管理情報を示す図である。
ＣＰＵ管理情報は、テーブル化されて格納されている。
【００６８】
ＣＰＵ管理情報テーブル１２０ａには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
ＣＰＵ番号の欄には、処理プロセッサを管理づける論理番号が記載されている。
【００６９】
クロック変更段階数の欄には、ＣＰＵクロック数が変更可能な段階数（変更できなければ「１」、２パターン持てれば「２」）が記載されている。
間隔の欄には、最小値、あるいは最大値から変更可能な間隔が記載されている。
【００７０】
クロック単位能力の欄には、クロックあたりの処理能力係数が記載されている。
最小値の欄には、最小クロック値が記載されている。
最小時消費電力の欄には、最小クロック時の消費電力が記載されている。
【００７１】
最大値の欄には、最大クロック値が記載されている。
最大時消費電力の欄には、最大クロック時の消費電力が記載されている。
最適値の欄には、最適クロック値が記載されている。
【００７２】
メモリ量の欄には、使用可能なメモリ量が記載されている。
図１２は、デバイス管理情報を示す図である。
デバイス管理情報は、テーブル化されて格納されている。
【００７３】
デバイス管理情報テーブル１２０ｂには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
デバイス番号の欄には、デバイスを関連づける論理番号が記載されている。
【００７４】
接続ＣＰＵの欄には、該当デバイスが使用するＣＰＵが記載されている。使用しない場合は、「０」が記載される。
消費電力の欄には、該当デバイスの消費電力が記載されている。ソフトウェアであれば「０」が記載される。
【００７５】
スループット係数の欄には、クロック単位能力と掛け合わせて処理能力を算出する係数が記載されている。
最小スループットの欄には、デバイスが処理可能な最小処理能力値が記載されている。
【００７６】
最小バッファ量の欄には、最小処理能力でのバッファ量が記載されている。
最大スループットの欄には、デバイスが処理可能な最大処理能力値が記載されている。
最大バッファ量の欄には、最大処理能力でのバッファ量が記載されている。
【００７７】
最適スループットの欄には、デバイスが処理可能な最適処理能力値が記載されている。
最適バッファ量の欄には、最適処理能力でのバッファ量が記載されている。
最適処理レベルの欄には、使用ＣＰＵでの最適処理優先レベルが記載されている。
【００７８】
処理レベル間隔の欄には、処理レベルの調整間隔が記載されている。
図１３は、シナリオ条件を示す図である。
シナリオ条件は、テーブル化されて格納されている。
【００７９】
シナリオ条件テーブル１２０ｃには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
処理シナリオ番号の欄には、処理対象のアプリケーションを処理するリソースを管理する管理番号が記載されている。
【００８０】
メディア種別の欄には、アプリケーションが処理する情報が記載されている。
アプリ処理種別の欄には、使用するアプリケーションの種別が記載されている。
構成の欄には、使用するデバイスの情報が記載されている。
【００８１】
スループットの欄には、アプリ処理種別の欄に記載されたアプリケーションを処理するために必要なスループットが記載されている。リソース基準値が、この欄に記載されたスループット未満の場合、輻輳調整処理が行われる。
【００８２】
全体消費電力の欄には、アプリ処理種別の欄に記載されたアプリケーションを処理するために必要な消費電力が記載されている。リソース基準値が、この欄に記載されたスループット未満の場合、輻輳調整処理が行われる。
【００８３】
全体使用メモリ量の欄には、アプリ処理種別の欄に記載されたアプリケーションを処理するために必要なメモリ量が記載されている。リソース基準値が、この欄に記載されたスループット未満の場合、輻輳調整処理が行われる。
【００８４】
図１４は、動作中アプリ情報を示す図である。
動作中アプリ情報は、テーブル化されて格納されている。
動作中アプリ情報テーブル１２０ｄには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００８５】
処理シナリオ番号の欄には、使用するシナリオ条件の番号が記載されている。
使用ＣＰＵ番号の欄には、処理シナリオ番号によって識別されるアプリケーションを処理するために必要なＣＰＵのＣＰＵ番号が記載されている。処理するために必要なＣＰＵが複数存在する場合、ＣＰＵ番号は複数記載される。
【００８６】
使用デバイス番号の欄には、処理シナリオ番号によって識別されるアプリケーションを処理するために必要なデバイスのデバイス番号が記載されている。処理するために必要なデバイスが複数存在する場合、デバイス番号は複数記載される。
【００８７】
図１５は、ＣＰＵ動作情報を示す図である。
ＣＰＵ動作情報は、テーブル化されて格納されている。
ＣＰＵ動作情報テーブル１２０ｅには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００８８】
ＣＰＵ番号の欄には、処理プロセッサを関連づける論理番号が記載されている。
クロック値の欄には、現在のクロック値が記載されている。
消費電力の欄には、現在の消費電力が記載されている。
【００８９】
図１６は、デバイス動作情報を示す図である。
デバイス動作情報は、テーブル化されて格納されている。
デバイス動作情報テーブル１２０ｆには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００９０】
デバイス番号の欄には、デバイスを関連づける論理番号が記載されている。
接続ＣＰＵの欄には、該当デバイスが使用するＣＰＵが記載されている。
消費電力の欄には、該当デバイスの消費電力が記載されている。ソフトウェアであれば「０」が記載される。
【００９１】
スループットの欄には、現在の処理能力値が記載されている。
バッファ量の欄には、現在のバッファ量が記載されている。
処理レベルの欄には、使用ＣＰＵでの処理優先レベルが記載されている。「０」が最も低く、「５」が最も高い。
【００９２】
図１７は、調整消費電力情報を示す図である。
調整消費電力情報は、テーブル化されて格納されている。
調整消費電力情報テーブル１２０ｇには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００９３】
消費電力値の欄には、通常モードまたは省電力モードでアプリケーションから要求される消費可能電力量が記載されている。
図１８は、調整優先情報を示す図である。
【００９４】
調整優先情報は、テーブル化されて格納されている。
調整優先情報テーブル１２０ｈには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００９５】
消費電力優先度の欄には、極力、消費電力を下げる構成を優先とするか否かが記載されている。優先度の高い順に、「最優先」、「優先」、「非優先」が記載される（他の欄についても同様）。
【００９６】
メモリ使用優先度の欄には、極力、メモリを使用しない構成を優先とするか否かが記載されている。
スループット優先度の欄には、極力、スループットが出る構成を優先とするか否かが記載されている。
【００９７】
先行処理優先度の欄には、先に動作しているアプリケーションの処理を停止しないように調整するか否かが記載されている。
図１９は、使用リソースＤＢ管理情報を示す図である。
【００９８】
使用リソースＤＢ管理情報は、テーブル化されて格納されている。
使用リソースＤＢ管理情報テーブル１２３ａには、データ名、概要の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連づけられている。
【００９９】
メディア種別の欄には、シナリオ条件テーブル１２０ｃのメディア種別の内容が記載される。
アプリ処理種別の欄には、シナリオ条件テーブル１２０ｃのアプリ処理種別の内容が記載される。
【０１００】
蓄積回数の欄には、アプリ処理種別の欄のアプリケーションの情報が、データベース１３０に書き込まれた回数が記載される。
処理シナリオ番号の欄には、シナリオ条件テーブル１２０ｃの処理シナリオ番号が記載される。
【０１０１】
ＣＰＵ動作情報の欄には、ＣＰＵ動作情報テーブル１２０ｅに記載された内容の更新値（後述）が記載される。
デバイス動作情報の欄には、アプリ種別の欄のアプリケーションを処理するために必要なデバイスの、デバイス動作情報テーブル１２０ｆに記載された内容の更新値が記載される。
【０１０２】
スループットの欄には、アプリ種別の欄のアプリケーションを処理するために必要なスループットが記載される。
次に、図４のステップＳ４および図７のステップＳ３６に示すリソース基準値算出処理について詳しく説明する。
【０１０３】
図２０は、リソース基準値算出処理を示すフローチャートである。
まず、メインアプリケーション処理部１１１からのアプリケーション処理種別（メディア再生、録画等）の情報に基づいて、必要なリソースを決定し、動作中アプリ情報テーブル１２０ｄに使用ＣＰＵ番号、使用デバイス番号を書き込む（ステップＳ７１）。
【０１０４】
次に、データベース１３０を参照して取得した、処理対象のアプリケーションのリソース基準値に基づいて各デバイスのスループットを試算する（ステップＳ７２）。
アプリケーションが要求している（シナリオ条件に示された）スループットに近くなるよう、各デバイスの処理レベルとバッファ量を変更する（ステップＳ７３）。
【０１０５】
このとき、調整優先情報テーブル１２０ｈに記載された優先順位に従い、リソース量を決定する（ステップＳ７４）。
次に、デバイスの調整でスループットを満たすか否かを判断する（ステップＳ７５）。
【０１０６】
満たさない場合（ステップＳ７５のＮｏ）、ＣＰＵのクロック数を上げ、ステップＳ７２に移行し、再度デバイスの調整を行う。
一方、満たす場合（ステップＳ７５のＹｅｓ）、リソース基準値算出処理を終了する。
【０１０７】
次に、図８および図９のステップＳ５３に示す輻輳判定処理について説明する。
図２１は、輻輳判定処理を示すフローチャートである。
まず、輻輳調整部１２２は、取得した動作中アプリ処理情報と使用リソース情報とを比較し、動作中のＣＰＵの使用率が１００％を超えているか否かを判断する（ステップＳ８１）。
【０１０８】
ＣＰＵの使用率が１００％を超えている場合（ステップＳ８１のＹｅｓ）、輻輳調整処理を行う（ステップＳ８２）。
ＣＰＵの使用率が１００％以下の場合（ステップＳ８１のＮｏ）、動作中のＣＰＵのメモリ使用率が１００％を超えているか否かを判断する（ステップＳ８３）。
【０１０９】
メモリ使用率が１００％を超えている場合（ステップＳ８３のＹｅｓ）、輻輳調整処理を行う（ステップＳ８２）。
メモリ使用率が１００％以下の場合（ステップＳ８３のＮｏ）、消費電力が動作許容範囲を超えているか否かを判断する（ステップＳ８４）。
【０１１０】
動作許容範囲を超えている場合（ステップＳ８４のＹｅｓ）、輻輳調整処理を行う（ステップＳ８２）。
動作許容範囲を超えていない場合（ステップＳ８４のＮｏ）、アプリケーション処理のスループットが不足しているか否かを判断する（ステップＳ８５）。
【０１１１】
スループットが不足している場合（ステップＳ８５のＹｅｓ）、輻輳調整処理を行う（ステップＳ８２）。
スループットが不足していない場合（ステップＳ８５のＮｏ）、輻輳が発生していないと判断し、処理を終了する。
【０１１２】
次に、図６のステップＳ２１、図７のステップＳ３８および図９のステップＳ５８に示すリソース最適値算出処理について説明する。
図２２は、リソース最適値算出処理を示すフローチャートである。
【０１１３】
まず、使用リソースＤＢ管理情報テーブル１２３ａのデータ名の欄に記載された情報のうち、アプリ種別、処理種別、ＣＰＵ動作情報、デバイス動作情報、スループットをデータベース１３０から検索し、該当する（比較対象となる）情報が存在するか否かを判断する（ステップＳ９１）。
【０１１４】
該当する情報が存在する場合（ステップＳ９１のＹｅｓ）、該当する情報を取得する（ステップＳ９２）。該当する情報が存在しない場合（ステップＳ９１のＮｏ）、リソース基準値を適用する（ステップＳ９３）。
【０１１５】
次に、データベース１３０より取得した情報と現在のリソース使用状況とを比較し、デバイス動作情報で最優先の項目を使用して調整を行う。
具体的には、輻輳原因がＣＰＵ使用率１００％であるか否かを判断する（ステップＳ９４）。
【０１１６】
輻輳原因がＣＰＵ使用率１００％である場合（ステップＳ９４のＹｅｓ）、ＣＰＵ負荷調整処理を行う（ステップＳ９５）。
輻輳原因がＣＰＵ使用率１００％でない場合（ステップＳ９４のＮｏ）、輻輳原因がメモリ使用率１００％か否かを判断する（ステップＳ９６）。
【０１１７】
輻輳原因がメモリ使用率１００％である場合（ステップＳ９６のＹｅｓ）、メモリ負荷調整処理を行う（ステップＳ９７）。
輻輳原因がメモリ使用率１００％でない場合（ステップＳ９６のＮｏ）、輻輳原因が消費電力オーバーか否かを判断する（ステップＳ９８）。
【０１１８】
輻輳原因が消費電力オーバーである場合（ステップＳ９８のＹｅｓ）、消費電力調整処理を行う（ステップＳ９９）。
輻輳原因が消費電力オーバーでない場合（ステップＳ９８のＮｏ）、輻輳原因がスループット不足か否かを判断する（ステップＳ１００）。
【０１１９】
輻輳原因がスループット不足である場合（ステップＳ１００のＹｅｓ）、スループット調整処理を行う（ステップＳ１０１）。
輻輳原因がスループット不足でない場合（ステップＳ１００のＮｏ）、最適値算出処理を終了する。
【０１２０】
また、ＣＰＵ負荷調整処理、メモリ負荷調整処理、消費電力調整処理およびスループット調整処理を行った後には、輻輳判定処理を行う（ステップＳ１０２）。なお、輻輳判定処理は、図２１に示す処理と同じ処理を行う。
【０１２１】
なお、本実施の形態では、輻輳原因をＣＰＵ使用率、メモリ使用率、消費電力、スループットの順に調べたが、本発明では、この順番は特に限定されない。
次に、ＣＰＵ負荷調整処理、メモリ負荷調整処理、消費電力調整処理およびスループット調整処理を詳しく説明する。
【０１２２】
図２３は、ＣＰＵ負荷調整処理を示すフローチャートである。
まず、輻輳調整部１２２が、調整優先情報テーブル１２０ｈを参照し、先行処理優先か否か、すなわち、先行処理優先度が最も優先されるべき処理か否かを判断する（ステップＳ１１１）。
【０１２３】
先行処理優先の場合（ステップＳ１１１のＹｅｓ）、後から起動したメディアの処理を停止する（ステップＳ１１２）。
先行処理優先ではない場合（ステップＳ１１１のＮｏ）、スループット優先か否か、すなわち、スループット優先度が最も優先されるべき処理か否かを判断する（ステップＳ１１３）。
【０１２４】
スループット優先の場合（ステップＳ１１３のＹｅｓ）、ＣＰＵクロックを上げる（ステップＳ１１４）。
スループット優先ではない場合（ステップＳ１１３のＮｏ）、他の方法により調整可能か否かを判断する（ステップＳ１１５）。
【０１２５】
調整可能な場合（ステップＳ１１５のＹｅｓ）、処理優先度を下げる（ステップＳ１１６）。
調整可能ではない場合（ステップＳ１１５のＮｏ）、輻輳を検出したアプリケーションの処理（該当アプリ処理）を停止する（ステップＳ１１７）。
【０１２６】
以上でＣＰＵ負荷調整処理を終了する。
図２４は、メモリ負荷調整処理を示すフローチャートである。
まず、調整優先情報に基づいて、輻輳調整部１２２が、先行処理優先か否かを判断する（ステップＳ１２１）。
【０１２７】
先行処理優先の場合（ステップＳ１２１のＹｅｓ）、後から追加した（これから動作させようとする）アプリケーションの処理を停止する（ステップＳ１２２）。
先行処理優先ではない場合（ステップＳ１２１のＮｏ）、調整可能か否かを判断する（ステップＳ１２３）。
【０１２８】
調整可能な場合（ステップＳ１２３のＹｅｓ）、メモリの使用量を削減する（ステップＳ１２４）。
調整可能ではない場合（ステップＳ１２３のＮｏ）、該当アプリ処理を停止する（ステップＳ１２５）。
【０１２９】
以上でメモリ負荷調整処理を終了する。
図２５は、消費電力調整処理を示すフローチャートである。
まず、調整優先情報に基づいて、輻輳調整部１２２が、先行処理優先か否かを判断する（ステップＳ１３１）。
【０１３０】
先行処理優先の場合（ステップＳ１３１のＹｅｓ）、後から追加したアプリケーションの処理を停止する（ステップＳ１３２）。
先行処理優先ではない場合（ステップＳ１３１のＮｏ）、スループット優先か否かを判断する（ステップＳ１３３）。
【０１３１】
スループット優先の場合（ステップＳ１３３のＹｅｓ）、ＣＰＵクロックを上げる（ステップＳ１３４）。
スループット優先ではない場合（ステップＳ１３３のＮｏ）、調整可能か否かを判断する（ステップＳ１３５）。
【０１３２】
調整可能な場合（ステップＳ１３５のＹｅｓ）、ＣＰＵクロックを下げる（ステップＳ１３６）。
調整可能ではない場合（ステップＳ１３５のＮｏ）、該当アプリ処理を停止する（ステップＳ１３７）。
【０１３３】
以上で消費電力調整処理を終了する。
図２６は、スループット調整処理を示すフローチャートである。
まず、調整優先情報に基づいて、輻輳調整部１２２が、先行処理優先か否かを判断する（ステップＳ１４１）。
【０１３４】
先行処理優先の場合（ステップＳ１４１のＹｅｓ）、後から追加したアプリケーションの処理を停止する（ステップＳ１４２）。
先行処理優先ではない場合（ステップＳ１４１のＮｏ）、スループット優先か否かを判断する（ステップＳ１４３）。
【０１３５】
スループット優先の場合（ステップＳ１４３のＹｅｓ）、ＣＰＵクロックおよび処理優先度を上げる（ステップＳ１４４）。
スループット優先ではない場合（ステップＳ１４３のＮｏ）、調整可能か否かを判断する（ステップＳ１４５）。
【０１３６】
調整可能な場合（ステップＳ１４５のＹｅｓ）、処理優先度を上げる（ステップＳ１４６）。
調整可能ではない場合（ステップＳ１４５のＮｏ）、該当アプリ処理を停止する（ステップＳ１４７）。
【０１３７】
以上でスループット調整処理を終了する。
次に、図９のステップＳ６２に示すデータベース更新処理について説明する。
データベース更新部１２３から取得した使用リソースＤＢ管理情報テーブル１２３ａに格納している各パラメータの値を格納値とし、リソース最適値の算出後、データベース更新処理にてデータベース１３０に格納する使用リソースＤＢ管理情報テーブル１２３ａが備える各パラメータの値を更新値とすると、以下の式により更新値が得られる。
【０１３８】
更新値＝（格納値×蓄積回数＋リソース最適値）÷（蓄積回数＋１）
蓄積回数＝蓄積回数＋１
すなわち、更新値は、輻輳調整処理により今までに取得したリソース最適値の平均値となる。
【０１３９】
以下、具体例を説明する。
具体例は、データベース１３０に初期値が設定されていない状態から映像音声再生アプリケーション１１３ａを使用する処理シナリオ番号「１」が追加され、その後、音声再生アプリケーション１１４ａを使用する処理シナリオ番号「２」が追加された場合の処理について説明する。
【０１４０】
図２７は、具体例のデバイス構成を示す図である。
内部ソフトデバイス１４は、ソフトストリーム分離（Demux）部１４１と、ソフトデコーダ１４２と、映像出力部１４３と、音声出力部１４４、１４５とを有している。
【０１４１】
内部ハードデバイス１５は、ハードストリーム分離部１５１と、ハードデコーダ１５２とを有している。
処理シナリオ番号「１」による処理を行う場合、図２７の接続線に示すように、ＣＰＵ１１ａは、映像出力部１４３と、音声出力部１４４と、ハードストリーム分離部１５１と、ハードデコーダ１５２とを用いてスピーカ２１に音声信号を出力し、ＬＣＤ２２に画像信号を出力する。
【０１４２】
図２８は、デバイス管理情報の具体例を示す図である。
図２８に示すデバイス管理情報テーブル１２０ｂのデバイス番号＃１は、ハードストリーム分離部１５１を示す情報であり、デバイス番号＃２は、ソフトストリーム分離部１４１を示す情報であり、デバイス番号＃３は、ハードデコーダ１５２を示す情報であり、デバイス番号＃４は、ソフトデコーダ１４２を示す情報であり、デバイス番号＃５は、映像出力部１４３を示す情報であり、デバイス番号＃６は、音声出力部１４４を示す情報であり、デバイス番号＃７は、音声出力部１４５を示す情報である。
【０１４３】
なお、ＣＰＵ１１ａのＣＰＵ管理情報は、図１１に示す情報を使用し、ＣＰＵ動作情報の初期値は、図１５に示す情報を使用し、調整優先情報は、図１８に示す情報を使用するものとする。
【０１４４】
また、初期状態では、動作中アプリ情報テーブル１２０ｄ、デバイス動作情報テーブル１２０ｆ、調整消費電力情報テーブル１２０ｇの各概要の欄は、空欄である。
また、デバイス管理情報テーブル１２０ｂの各デバイスのスループットは、データを加工することでデータ量が増加し、各デバイスのスループットが要求のスループットと値がずれていく部分を補正するものとして使用する。
【０１４５】
今回は、説明をわかりやすくするため、スループット係数はすべて「１」（データサイズは加工後も変わらない）として説明する。
図２９は、具体例のデバイス動作情報を示す図である。
【０１４６】
まず、初回起動時には、データベース１３０に初期値が存在しないため、リソース基準値を算出する。
ここで、図２９に示すデバイス動作情報テーブル１２０ｆを参照すると、各デバイスのスループットは、いずれも２０Ｍｂｐｓ以上（内部ソフトデバイスの各機能については、ＣＰＵ係数（／ＭＨｚ）を掛けて計算する）である。
【０１４７】
全体消費電力は、ＣＰＵ動作情報テーブル１２０ｅの消費電力が１００Ｗであり、デバイス動作情報テーブル１２０ｆの消費電力の合計が１３０Ｗであるから、合計で２３０Ｗとなり、シナリオ条件テーブル１２０ｃの全体消費電力と一致する。
【０１４８】
全体使用メモリ量は、シナリオ条件の１．８Ｇｂｙｔｅに対し、１．２Ｇｂｙｔｅであるため満たしている。
画像出力のスループットは、通常２デバイス使用で例えば最大スループット８０Ｍｂｐｓの５０％の処理で４０Ｍｂｐｓのスループットと予測し、デバイス番号＃５、＃６のスループットには４０Ｍｂｐｓが記載される。このように、ＣＰＵ１１ａは処理レベルと使用タスクにより計算式を調整する。
【０１４９】
これらの情報が、動作中アプリ情報テーブル１２０ｄに書き込まれる。
図３０は、具体例の動作中アプリ情報を示す図である。
図３０に示す動作中アプリ情報テーブル１２０ｄの処理シナリオ番号の欄には「１」が記載され、使用ＣＰＵ番号の欄には、ＣＰＵ１１ａを示す「１」が記載され、使用デバイス番号の欄には、使用する各デバイスの番号「＃１」、「＃３」、「＃５」、「＃６」が記載される。
【０１５０】
図３１は、具体例の使用リソースＤＢ管理情報を示す図である。
前述したように、データベース１３０には、初期値が存在しないため、リソース最適値としてデバイス動作情報がそのまま記載される。
【０１５１】
なお、調整消費電力情報テーブル１２０ｇには、シナリオ条件の全体消費電力の値２３０Ｗが設定される。
図３２は、処理シナリオ番号「２」追加時のデバイス構成を示す図である。
【０１５２】
ソフトデコーダ１４２、音声出力部１４５が新たに動作を開始し、音声出力端子２３に音声信号を出力する。
図３３は、処理シナリオ番号「２」のシナリオ条件を示す図である。
【０１５３】
処理シナリオ番号「２」のシナリオ条件テーブル１２０ｃは、全体消費電力が３００Ｗである。
図３４は、具体例のデバイス動作情報を示す図である。
【０１５４】
デバイス番号＃２、＃４、＃７の欄にそれぞれ対応するデバイスの動作情報が記載される。ここで、ＣＰＵ１１ａは、通常５デバイス使用で例えば４０Ｍｂｐｓの２０％の処理で８Ｍｂｐｓのスループットであると予測し、デバイス番号＃２、＃４、＃７のスループットには８Ｍｂｐｓが記載される。
【０１５５】
ここで、輻輳調整部１２２は、輻輳判定処理を行って輻輳状態を判定する。
ＣＰＵの使用率は、最大クロック値３００ＭＨｚを超えていないため、条件を満たしている。
【０１５６】
全体使用メモリ量は１４００Ｍｂｙｔｅであり、シナリオ条件に記載された全体使用メモリ量１．８Ｇｂｙｔｅ以下であるから条件を満たしている。
消費電力の合計値は、２３０Ｗであり、シナリオ条件に記載された全体消費電力３００Ｗ以下であるから条件を満たしている。
【０１５７】
デバイス番号＃２、＃４、＃７の各デバイスのスループットは、それぞれ８Ｍｂｐｓであり、シナリオ条件に記載されたスループット２０Ｍｂｐｓ以上を満たしていない。従ってスループット不足であり、輻輳が発生していると判断し、最適値算出処理を行う。
【０１５８】
最適値算出処理では、輻輳原因がスループット不足であるため、スループット調整処理を行う。
調整優先情報テーブル１２０ｈを参照すると、先行処理優先度は非優先であり、スループット優先度が最優先であるため、スループット調整処理では、デバイスの処理優先度を上げる調整およびＣＰＵクロックを上げる調整を行う。
【０１５９】
図３５は、調整後のデバイス情報を示す図である。
調整により、デバイス番号＃２、＃４、＃５、＃６、＃７のデバイス動作情報の処理レベルが、「３」から「４」に上昇している。また、スループットも８Ｍｂｐｓから２０Ｍｂｐｓに上昇している。
【０１６０】
図３６は、具体例のＣＰＵ動作情報を示す図である。
最適値算出処理を行った結果、ＣＰＵ１１ａのクロック値が「１５０」から「３００」に上昇している。なお、これに伴い消費電力も「１００」から「１５０」に上昇している。
【０１６１】
スループット調整処理が終了したので、輻輳調整処理を行う。
ＣＰＵの使用率は、最大クロック値３００ＭＨｚを超えていないため、条件を満たしている。
【０１６２】
全体使用メモリ量は１８００Ｍｂｙｔｅであり、シナリオ条件に記載された全体使用メモリ量１．８Ｇｂｙｔｅ以下であるから条件を満たしている。
各デバイスのスループットは、２０Ｍｂｐｓ以下であり、シナリオ条件のスループット２０Ｍｂｐｓ以下であるから条件を満たしている。
【０１６３】
消費電力の合計値は、「２３０」から「２８０」に上昇するが、シナリオ条件の全体消費電力３００Ｗ以下であるから条件を満たしている。
従って、調整を完了する。
【０１６４】
図３７は、調整後の動作中アプリ情報を示す図である。
新たに処理シナリオ番号「２」が追加されている。
図３８は、輻輳調整部内で暫定的に更新された調整後の使用リソースＤＢ管理情報を示す図である。
【０１６５】
ＭＰＥＧ４の蓄積回数が「１」から「２」に上書きされている。
クロック値は、２２５（＝（１５０×１＋３００）／（１＋１））に上書きされている。
【０１６６】
デバイス番号＃５およびデバイス番号＃６のスループットがそれぞれ３０Ｍｂｐｓ（＝（２０×１＋４０）／（１＋１））に上書きされている。
処理レベルがそれぞれ３．５（＝（３×１＋４）／（１＋１））に上書きされている。
【０１６７】
その後、この値で映像音声再生アプリケーション１１３ａおよび音声再生アプリケーション１１４ａの処理が開始され、図４のステップＳ８にて述べたようにリソース監視要求が出力され、図５のステップＳ１２および図８、９のステップＳ５２にて述べたように、リソース監視部１２１が使用状況を取得し、デバイス動作情報テーブル１２０ｆを上書きする。
【０１６８】
図３９は、調整後のデバイス動作情報を示す図である。
（処理シナリオ番号「１」における）デバイス番号＃５およびデバイス番号＃６のスループットが不足している。従って、リソース監視部１２１は、輻輳が発生したと判断し、輻輳調整部１２２が、輻輳調整処理を行う。
【０１６９】
ここで、調整優先情報テーブル１２０ｈを参照すると、先行処理優先度は非優先であり、スループット優先度が最優先であるため、スループット調整処理では、デバイスの処理レベルを上げる調整およびＣＰＵクロックを上げる調整を行う。本具体例では、ＣＰＵのクロックは、最大クロックであるものとし、処理優先度のみを上げている。
【０１７０】
図４０は、再調整後のデバイス動作情報を示す図である。
全てのデバイスの処理レベルが５（最速）になっている。この結果、デバイス番号＃５およびデバイス番号＃６のデバイスは、スループット優先の条件で、処理レベルを上げることによりスループット不足を確保できたので、そのまま調整している。
【０１７１】
デバイス番号＃７のデバイスは、本来調整不要だが、処理シナリオ番号「１」側の処理レベルを上げることで現在のスループットを満たさなくなる。そのため、処理レベルを上げて調整するが、予測スループットは期待値を上回る結果となる。
【０１７２】
ＣＰＵの使用率は、最大クロック値３００ＭＨｚを超えていないため、条件を満たしている。
全体使用メモリ量は１４００Ｍｂｙｔｅであり、シナリオ条件に記載された全体使用メモリ量１．８Ｇｂｙｔｅ以下であるから条件を満たしている。
【０１７３】
各デバイスのスループットは、それぞれ２０Ｍｂｐｓ以上であり、シナリオ条件のスループット２０Ｍｂｐｓ以上であるから条件を満たしている。
消費電力の合計値は、２３５Ｗであり、シナリオ条件の全体消費電力２４０Ｗ以下であるから条件を満たしている。
【０１７４】
図４１は、再調整後の使用リソースＤＢ管理情報を示す図である。
メディア種別「ＭＰＥＧ４」に関する蓄積回数が「１」から「２」に上書きされている。
【０１７５】
クロック値は、２５０（＝（２２５×２＋３００）／（２＋１））に上書きされている。
デバイス番号＃１、＃３のスループットがそれぞれ６６Ｍｂｐｓ（＝（８０×２＋４０）／（２＋１））に上書きされている。また、バッファ量がそれぞれ３３３Ｍｂｙｔｅ（＝（４００×２＋２００）／（２＋１））に上書きされている。また、デバイス番号＃５、＃６のスループットがそれぞれ２６Ｍｂｐｓ（＝（３０×２＋２０）／（２＋１））に上書きされている。
【０１７６】
デバイス番号＃５、＃６の処理レベルがそれぞれ４（＝（３．５×２＋５）／３）に上書きされている。また、デバイス番号＃２、＃４、＃７のスループットがそれぞれ２１Ｍｂｐｓ（＝（２０×１＋２２）／（１＋１））に上書きされている。また、処理レベルがそれぞれ４．５（＝（４×１＋５）／（１＋１））に上書きされている。
【０１７７】
再調整完了後、データベース１３０を更新する。
以上述べたように、本実施の形態のリソース管理装置１０によれば、アプリケーションの変更に応じて必要に応じて随時リソース最適値算出処理が施され、算出されたリソースを適用することができるため、輻輳原因に応じた調整処理を行うことができる。従って、従来に比べて処理の効率化を図ることができ、例えば、省電力タイプのＣＰＵを搭載したり、低スペックのＣＰＵ、メモリを搭載したりすることができる。
【０１７８】
また、リソース監視部１２１が、適当なタイミングでリソース監視処理を行うことで、迅速に輻輳を調整することができる。
また、動的にデータベース１３０を更新することで、算出するリソース最適値がより最適な値に近づき、処理効率を高めることができる。
【０１７９】
以上、本発明のリソース管理プログラム、リソース管理方法およびリソース管理装置を、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。
【０１８０】
また、本発明は、前述した実施の形態のうちの、任意の２以上の構成（特徴）を組み合わせたものであってもよい。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、リソース管理装置１０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。
【０１８１】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１８２】
リソース管理プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１８３】
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）  処理対象のアプリケーションのリソースを管理するリソース管理プログラムにおいて、
コンピュータを、
動作中の前記アプリケーションを動作させるデバイスのリソースの使用状況を取得するリソース使用状況取得手段、
前記リソース使用状況取得手段が取得した前記リソースの使用状況を監視し、輻輳の発生を判定する輻輳判定手段、
輻輳の発生時に、前記リソースの使用状況とデータベースに格納されている前記デバイスの前記リソースの情報とに基づいて輻輳が解消するように調整する輻輳調整手段、
前記輻輳調整手段により調整された前記リソースの最適値を前記データベースに反映するデータベース更新手段、
として機能させることを特徴とするリソース管理プログラム。
【０１８４】
（付記２）  前記輻輳調整手段は、調整優先情報により定められた優先順位に基づいて、輻輳調整を行うことを特徴とする付記１記載のリソース管理プログラム。
（付記３）  前記調整優先情報は、少なくとも前記アプリケーションの処理に必要なデバイスの消費電力、メモリ使用量およびスループットのうちの１つを含む情報であることを特徴とする付記２記載のリソース管理プログラム。
【０１８５】
（付記４）  前記リソース使用状況取得手段は、前記アプリケーションが動作中に、定期的に前記リソースの使用状況を取得することを特徴とする付記１記載のリソース管理プログラム。
【０１８６】
（付記５）  前記輻輳調整手段は、前記データベースに格納されていない情報については、前記アプリケーションが要求しているスループットに近くなるよう、前記デバイスの処理レベルおよびバッファ量を変更することを特徴とする付記１記載のリソース管理プログラム。
【０１８７】
（付記６）  前記データベース更新手段は、調整により今までに取得した前記リソースの最適値の平均値を前記データベースに格納することを特徴とする付記１記載のリソース管理プログラム。
【０１８８】
（付記７）  処理対象のアプリケーションのリソースを管理するリソース管理方法において、
リソース使用状況取得手段が、動作中の前記アプリケーションを動作させるデバイスのリソースの使用状況を取得し、
輻輳判定手段が、前記リソース使用状況取得手段が取得した前記リソースの使用状況を監視し、輻輳の発生を判定し、
輻輳調整手段が、輻輳の発生時に、前記リソースの使用状況とデータベースに格納されている前記デバイスの前記リソースの情報とに基づいて輻輳が解消するように調整し、
データベース更新手段が、前記輻輳調整手段により調整された前記リソースの最適値を前記データベースに反映する、
ことを特徴とするリソース管理方法。
【０１８９】
（付記８）  処理対象のアプリケーションのリソースを管理するリソース管理装置において、
動作中の前記アプリケーションを動作させるデバイスのリソースの使用状況を取得するリソース使用状況取得手段と、
前記リソース使用状況取得手段が取得した前記リソースの使用状況を監視し、輻輳の発生を判定する輻輳判定手段と、
輻輳の発生時に、前記リソースの使用状況とデータベースに格納されている前記デバイスの前記リソースの情報とに基づいて輻輳が解消するように調整する輻輳調整手段と、
前記輻輳調整手段により調整された前記リソースの最適値を前記データベースに反映するデータベース更新手段と、
を有することを特徴とするリソース管理装置。
【図面の簡単な説明】
【０１９０】
【図１】本発明の概要を示す図である。
【図２】リソース管理装置のハードウェア構成例を示す図である。
【図３】リソース管理装置の機能を示すブロック図である。
【図４】アプリケーション処理を示すフローチャートである。
【図５】リソース監視処理を示すフローチャートである。
【図６】輻輳調整処理を示すフローチャートである。
【図７】アプリケーション処理の初期動作を示すシーケンス図である。
【図８】輻輳が発生していない場合のリソース監視処理を示すシーケンス図である。
【図９】輻輳が発生した場合のリソース監視処理を示すシーケンス図である。
【図１０】輻輳調整部およびデータベース更新部が備える各データを示す図である。
【図１１】ＣＰＵ管理情報を示す図である。
【図１２】デバイス管理情報を示す図である。
【図１３】シナリオ条件を示す図である。
【図１４】動作中アプリ情報を示す図である。
【図１５】ＣＰＵ動作情報を示す図である。
【図１６】デバイス動作情報を示す図である。
【図１７】調整消費電力情報を示す図である。
【図１８】調整優先情報を示す図である。
【図１９】使用リソースＤＢ管理情報を示す図である。
【図２０】リソース基準値算出処理を示すフローチャートである。
【図２１】輻輳判定処理を示すフローチャートである。
【図２２】リソース最適値算出処理を示すフローチャートである。
【図２３】ＣＰＵ負荷調整処理を示すフローチャートである。
【図２４】メモリ負荷調整処理を示すフローチャートである。
【図２５】消費電力調整処理を示すフローチャートである。
【図２６】スループット調整処理を示すフローチャートである。
【図２７】具体例のデバイス構成を示す図である。
【図２８】デバイス管理情報の具体例を示す図である。
【図２９】具体例のデバイス動作情報を示す図である。
【図３０】具体例の動作中アプリ情報を示す図である。
【図３１】具体例の使用リソースＤＢ管理情報を示す図である。
【図３２】処理シナリオ番号「２」追加時のデバイス構成を示す図である。
【図３３】処理シナリオ番号「２」のシナリオ条件を示す図である。
【図３４】具体例のデバイス動作情報を示す図である。
【図３５】調整後のデバイス情報を示す図である。
【図３６】具体例のＣＰＵ動作情報を示す図である。
【図３７】調整後の動作中アプリ情報を示す図である。
【図３８】輻輳調整部内で暫定的に更新された調整後の使用リソースＤＢ管理情報を示す図である。
【図３９】調整後のデバイス動作情報を示す図である。
【図４０】再調整後のデバイス動作情報を示す図である。
【図４１】再調整後の使用リソースＤＢ管理情報を示す図である。
【符号の説明】
【０１９１】
１  コンピュータ
２  リソース使用状況取得手段
３  輻輳判定手段
４  輻輳調整手段
５  データベース更新手段
６  データベース
１０  リソース管理装置
１１ａ、１１ｂ  ＣＰＵ
１２  キーデバイス
１３  メモリ
１４  内部ソフトデバイス
１５  内部ハードデバイス
１６  バス
２１  スピーカ
２２  ＬＣＤ
２３  音声出力端子
１１０  アプリケーション処理部
１１１  メインアプリケーション処理部
１１２ａ  静止画処理アプリケーション
１１２ｂ  静止画処理モジュール群
１１２ｃ、１１３ｃ、１１４ｃ  デバイス制御部
１１３ａ  映像音声再生アプリケーション
１１３ｂ  映像音声再生モジュール群
１１４ａ  音声再生アプリケーション
１１４ｂ  音声再生モジュール群
１２０  輻輳監視部
１２０ａ  ＣＰＵ管理情報テーブル
１２０ｂ  デバイス管理情報テーブル
１２０ｃ  シナリオ条件テーブル
１２０ｄ  動作中アプリ情報テーブル
１２０ｅ  ＣＰＵ動作情報テーブル
１２０ｆ  デバイス動作情報テーブル
１２０ｇ  調整消費電力情報テーブル
１２０ｈ  調整優先情報テーブル
１２１  リソース監視部
１２２  輻輳調整部
１２３  データベース更新部
１２３ａ  使用リソースＤＢ管理情報テーブル
１３０  データベース
１４１  ソフトストリーム分離部
１４２  ソフトデコーダ
１４３  映像出力部
１４４、１４５  音声出力部
１５１  ハードストリーム分離部
１５２  ハードデコーダ
【図１】
2009193206.tif 000003
【図２】
2009193206.tif 000004
【図３】
2009193206.tif 000005
【図４】
2009193206.tif 000006
【図５】
2009193206.tif 000007
【図６】
2009193206.tif 000008
【図７】
2009193206.tif 000009
【図８】
2009193206.tif 000010
【図９】
2009193206.tif 000011
【図１０】
2009193206.tif 000012
【図１１】
2009193206.tif 000013
【図１２】
2009193206.tif 000014
【図１３】
2009193206.tif 000015
【図１４】
2009193206.tif 000016
【図１５】
2009193206.tif 000017
【図１６】
2009193206.tif 000018
【図１７】
2009193206.tif 000019
【図１８】
2009193206.tif 000020
【図１９】
2009193206.tif 000021
【図２０】
2009193206.tif 000022
【図２１】
2009193206.tif 000023
【図２２】
2009193206.tif 000024
【図２３】
2009193206.tif 000025
【図２４】
2009193206.tif 000026
【図２５】
2009193206.tif 000027
【図２６】
2009193206.tif 000028
【図２７】
2009193206.tif 000029
【図２８】
2009193206.tif 000030
【図２９】
2009193206.tif 000031
【図３０】
2009193206.tif 000032
【図３１】
2009193206.tif 000033
【図３２】
2009193206.tif 000034
【図３３】
2009193206.tif 000035
【図３４】
2009193206.tif 000036
【図３５】
2009193206.tif 000037
【図３６】
2009193206.tif 000038
【図３７】
2009193206.tif 000039
【図３８】
2009193206.tif 000040
【図３９】
2009193206.tif 000041
【図４０】
2009193206.tif 000042
【図４１】
2009193206.tif 000043