(57)【要約】【課題】動作モードの最適化処理に起因して並行処理の性能がかえって低下することを避ける。【解決手段】使用リソース量情報記憶部１０５は、アプリケーションの各々の複数の動作モードにおける使用リソース量の情報を格納する。切り替わり通知手段１０２は、並列処理アプリケーション項目の情報と、現在使用可能なリソース量の情報とを出力する。定常状態確認手段１０７は、並列処理で動作されるアプリケーションのすべてが一定期間以上定常状態にある場合に動作モード切り替え許可信号を出力する。動作モード決定手段１０３は、定常状態確認手段１０７から動作モード切り替え許可信号が出力された場合に、切り替わり通知手段１０２から出力された並列処理アプリケーション項目の情報およびリソース量の情報を使用して、演算手段１０４において実行される動作モードを決定する。【選択図】図１
2016126683.tif 000002
【特許請求の範囲】
【請求項１】
各々が複数の動作モードを有する複数のアプリケーションのプログラムを格納するプログラム記憶部と、
前記プログラム記憶部に格納された前記複数のアプリケーションの少なくとも一部を並列処理で動作させることができる演算手段と、
前記アプリケーションの各々の前記複数の動作モードにおける使用リソース量の情報を格納する使用リソース量情報記憶部と、
前記複数のアプリケーションのうち前記演算手段において並列処理で動作されるものを表す並列処理アプリケーション項目の情報と、現在使用可能なリソース量の情報とを出力する切り替わり通知手段と、
前記演算手段によって並列処理で動作される前記アプリケーションのすべてが一定期間以上定常状態にある場合に動作モード切り替え許可信号を出力する定常状態確認手段と、
前記定常状態確認手段から前記動作モード切り替え許可信号が出力された場合に、前記切り替わり通知手段から出力された前記並列処理アプリケーション項目の情報および前記リソース量の情報を使用して、前記演算手段において実行される動作モードを決定する動作モード決定手段と
を備える、ソフトウエア実行装置。
【請求項２】
前記ソフトウエア実行装置は、クオリティ点数の情報を格納するクオリティ点数情報記憶部と、優先機能情報を格納する優先機能情報記憶部とをさらに備え、
前記動作モード決定手段は、前記クオリティ点数の情報および前記優先機能情報を用いて、前記演算手段において実行される前記動作モードを決定する、請求項１に記載のソフトウエア実行装置。
【請求項３】
前記ソフトウエア実行装置は、並列処理アプリケーション項目と使用可能リソース量と優先機能情報との条件に基づいて前記動作モード決定手段がこれまでに決定してきた動作モードの組み合わせを格納する動作モード履歴記憶部をさらに備え、
前記動作モード決定手段は、前記動作モード履歴記憶部に格納されている前記条件の中から、前記動作モード決定手段に入力された条件と一致するものがあるか否か検索を行う、請求項２に記載のソフトウエア実行装置。
【請求項４】
前記動作モード決定手段は、検索された前記組み合わせの中に動作させないアプリケーションが存在した場合に、動作させない前記アプリケーションが動作必須アプリケーションであるか否かを確認する、請求項３に記載のソフトウエア実行装置。
【請求項５】
前記動作モード履歴記憶部は、検索された前記組み合わせが、前記演算手段において実行されるものとして使用された回数を記憶し、
前記動作モード決定手段は前記動作モード履歴記憶部から前記組み合わせを前記回数が多い順番に呼び出す、請求項３または４に記載のソフトウエア実行装置。
【請求項６】
前記動作モード決定手段は、前記切り替わり通知手段から通知された前記並列処理アプリケーション項目のすべてを並列処理で動作せせることが不可能である場合に、どのアプリケーションの動作を取りやめるかを判断する、請求項１から５のいずれか１項に記載のソフトウエア実行装置。
【請求項７】
前記ソフトウエア実行装置は、動作必須アプリケーション情報を格納する動作必須アプリケーション情報記憶部をさらに備え、
前記動作モード決定手段は、前記動作必須アプリケーション情報を使用して、どのアプリケーションの動作を取りやめるかを決定する、請求項６に記載のソフトウエア実行装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウエア実行装置に関し、特に、並行処理を行うソフトウエア実行装置に関するものである。
【背景技術】
【０００２】
特開２００５−００４５８１号公報（特許文献１）によれば、メディア処理装置は、メディア毎にメディア処理機能を実現する複数のメディアモジュールを有するメディア処理プロセッサと、上記複数のメディアモジュールを用いてメディア処理を行うアプリケーションを有するアプリケーション処理プロセッサとを含む。上記複数のメディアモジュールのうち少なくとも１つは複数の動作モードを有している。上記メディア処理プロセッサは、上記複数のメディアモジュールの各動作モードにおける使用リソース情報と、処理データ情報に応じた必要リソース情報とを保持するメディアモジュール情報保持部と、動作時に、上記アプリケーションから上記処理データ情報を取得し、上記メディアモジュール情報保持部から、上記使用リソース情報と上記必要リソース情報とを取得し、さらに、リソースの空き情報を調査して取得した情報に基づきメディアモジュールの動作モードを選択し、選択された動作モードへの切り替えを指示する解析部とを含む。
【０００３】
上記文献が主張するところによれば、これらの構成により、ユーザの処理要求に応じて各メディアモジュールの動作モードの組み合わせを切替えることができるので、リソース配分を最適化することができ、複数のメディア処理を遅滞なく並行処理できるようになる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−００４５８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記公報に記載の技術によれば、ユーザからの処理要求のたびに、動作モードの決定のための演算と、動作モードの切り替えとが行われる。このため、処理要求の連続的な変化などによって状況のさらなる変化が短時間で生じると、上記演算および切り替えをすぐにやり直さなければならなくなる。このような非効率性のために、リソースの最適化を意図した動作モードの切り替えが、並行処理の性能をかえって低下させることがある。
【０００６】
本発明は以上のような課題を解決するためになされたものであり、その目的は、動作モードの最適化処理に起因して並行処理の性能がかえって低下することを避けることができるソフトウエア実行装置を提供することである。
【課題を解決するための手段】
【０００７】
本発明のソフトウエア実行装置は、プログラム記憶部と、演算手段と、使用リソース量情報記憶部と、切り替わり通知手段と、定常状態確認手段と、動作モード決定手段とを有する。プログラム記憶部は、各々が複数の動作モードを有する複数のアプリケーションのプログラムを格納するものである。演算手段は、プログラム記憶部に格納された複数のアプリケーションの少なくとも一部を並列処理で動作させることができるものである。使用リソース量情報記憶部は、アプリケーションの各々の複数の動作モードにおける使用リソース量の情報を格納するものである。切り替わり通知手段は、複数のアプリケーションのうち演算手段において並列処理で動作されるものを表す並列処理アプリケーション項目の情報と、現在使用可能なリソース量の情報とを出力するものである。定常状態確認手段は、演算手段によって並列処理で動作されるアプリケーションのすべてが一定期間以上定常状態にある場合に動作モード切り替え許可信号を出力するものである。動作モード決定手段は、定常状態確認手段から動作モード切り替え許可信号が出力された場合に、切り替わり通知手段から出力された並列処理アプリケーション項目の情報およびリソース量の情報を使用して、演算手段において実行される動作モードを決定するものである。
【発明の効果】
【０００８】
本発明によれば、並列処理で動作されるアプリケーションのすべてが一定期間以上定常状態にある場合に、動作モードの切り替えが許される。これにより、各アプリケーションの動作モードを切り替える、動作モードの最適化処理が、短時間でやり直しとなることを避けることができる。これにより、動作モードの最適化処理に起因して並行処理の性能がかえって低下することを避けることができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態１におけるソフトウエア実行装置の構成を概略的に示すブロック図である。
【図２】図１の定常状態確認手段の状態遷移を示す図である。
【図３】本発明の実施形態２におけるソフトウエア実行装置の構成を概略的に示すブロック図である。
【図４】図３の動作モード決定手段における処理を説明するフロー図の一部であり、図５とともに１つのフロー図を構成する図である。
【図５】図３の動作モード決定手段における処理を説明するフロー図の一部であり、図４とともに１つのフロー図を構成する図である。
【図６】図４のステップ３０５の詳細を示すフロー図である。
【図７】本発明の実施の形態２におけるアプリケーションの１つが有する複数の動作モードの各々の使用リソース情報およびクオリティ点数の例を示す図である。
【図８】本発明の実施の形態２におけるアプリケーションの１つが有する複数の動作モードの各々の使用リソース情報およびクオリティ点数の例を示す図である。
【図９】本発明の実施の形態２におけるアプリケーションの１つが有する複数の動作モードの各々の使用リソース情報およびクオリティ点数の例を示す図である。
【図１０】本発明の実施の形態２におけるアプリケーションの１つが有する複数の動作モードの各々の使用リソース情報およびクオリティ点数の例を示す図である。
【図１１】本発明の実施の形態２における優先機能情報の例を示す図である。
【図１２】本発明の実施の形態２における優先機能情報の例を示す図である。
【図１３】本発明の実施の形態２における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例を示す図である。
【図１４】本発明の実施の形態２における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例を示す図である。
【図１５】本発明の実施の形態２における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例を示す図である。
【図１６】本発明の実施の形態２における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例を示す図である。
【図１７】本発明の実施の形態２における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例を示す図である。
【図１８】本発明の実施の形態２における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例を示す図である。
【図１９】本発明の実施形態３におけるソフトウエア実行装置の構成を概略的に示すブロック図である。
【図２０】図１９の動作モード決定手段における処理を説明するフロー図の一部であり、図４および図５とともに１つのフロー図を構成する図である。
【図２１】本発明の実施の形態３における動作モードの決定方法の例を示す図である。
【図２２】本発明の実施の形態３における動作モードの決定方法の例を示す図である。
【図２３】本発明の実施の形態３における動作モードの決定方法の例を示す図である。
【図２４】本発明の実施の形態３における動作モードの決定方法の例を示す図である。
【図２５】本発明の実施の形態４における動作モード決定手段での処理を説明するフロー図の一部であり、図４とともに１つのフロー図を構成する図である。
【図２６】本発明の実施の形態４における動作モードの決定方法の例を示す図である。
【図２７】図２６の補足説明のための図である。
【図２８】本発明の実施形態５におけるソフトウエア実行装置の構成を概略的に示すブロック図である。
【図２９】図２８の動作モード決定手段における処理を説明するフロー図の一部であり、図３０とともに１つのフロー図を構成する図である。
【図３０】図２８の動作モード決定手段における処理を説明するフロー図の一部であり、図２９とともに１つのフロー図を構成する図である。
【図３１】本発明の実施の形態６における動作モード決定手段での処理を説明するフロー図の一部であり、図２９とともに１つのフロー図を構成する図である。
【図３２】本発明の実施の形態７における動作モード決定手段での処理を説明するフロー図の一部であり、図３３とともに１つのフロー図を構成する図である。
【図３３】本発明の実施の形態７における動作モード決定手段での処理を説明するフロー図の一部であり、図３２とともに１つのフロー図を構成する図である。
【図３４】アプリケーションが有する動作モードの例を示す図である。
【発明を実施するための形態】
【００１０】
＜用語解説＞
本明細書において用いられる用語の意味を以下に説明する。
アプリケーション：  ソフトウエア実行装置上で実行させたい機能群を持ったソフトウエア。
動作モード：  どの機能を実現するべく動作するかについての、各アプリケーションが有する選択肢。なお図３４の例では、アプリケーションは動作モード１〜３を有する。動作モード１は機能Ａ、ＢおよびＣを、動作モード２は機能Ａ、ＢおよびＤを、動作モード３は機能ＡおよびＢをそれぞれ実現する。
並行処理：  ソフトウエア実行装置において複数のアプリケーションが実質的に同時に実行される動作形態であって、特に、１つの演算装置が複数のアプリケーションを、処理単位を区切って少しずつ交代で実行することによって、あたかも同時に実行しているような処理を行うこと。
リソース：  コンピュータのシステムを構成するものであって、演算装置が計算を行うために使用するハードウエアの総称。なおリソースとしては、たとえば、メモリ使用領域がある。リソースは有限であるため、並行処理において、他の処理と重複しないように各処理の使用可能分をそれぞれ割りつける必要がある。
定常状態：  アプリケーションが一定のリソース消費量で動作している状態。
優先機能情報：  リソースをどのような機能に優先的に配分するかを示す情報。
クオリティ点数：  各動作モードがその機能に応じて有する評価点数。
現組み合わせ候補：  ソフトウエア実行装置で並行処理を行うにあたって動作モードの組み合わせを決定する際のフロー中におけるその時点での最適の組み合わせ。
動作必須アプリケーション：  並列処理されるアプリケーションの項目に含まれていた場合に必ず動作する必要のあるアプリケーション。
動作必須アプリケーション情報：  どのアプリケーションが動作必須アプリケーションかを示す情報。
動作モード組み合わせ履歴情報：  これまでに選択されてきた動作モードの組み合わせの情報、そのときの並列処理アプリケーション項目の情報、各リソースの使用可能量の情報、および優先機能情報。
使用回数カウント値：  ある動作モードの組み合わせが何回使用されてきたかの回数。
【００１１】
以下、図面に基づいて本発明の実施の形態について説明する。なお、以下の図面において同一または相当する部分には同一の参照番号を付しその説明は繰返さない。
【００１２】
＜実施の形態１＞
図１を参照して、はじめに本実施の形態のソフトウエア実行装置１００１の構成について概略的に説明する。ソフトウエア実行装置１００１は、プログラム記憶部１０６と、演算手段１０４と、使用リソース量情報記憶部１０５と、切り替わり通知手段１０２と、定常状態確認手段１０７と、動作モード決定手段１０３とを有する。プログラム記憶部１０６は、各々が複数の動作モードを有する複数のアプリケーションのプログラムを格納するものである。演算手段１０４は、プログラム記憶部１０６に格納された複数のアプリケーションの少なくとも一部を並列処理で動作させることができるものである。使用リソース量情報記憶部１０５は、アプリケーションの各々の複数の動作モードにおける使用リソース量の情報を格納するものである。使用リソース量の情報は、各リソースの使用量を全リソースについて表したものであってもよく、あるいは、使用されるリソースについてのみその種類および使用量を表したものであってもよい。切り替わり通知手段１０２は、複数のアプリケーションのうち演算手段において並列処理で動作されるものを表す並列処理アプリケーション項目の情報と、現在使用可能な各リソースの量の情報とを出力するものである。定常状態確認手段１０７は、演算手段１０４によって並列処理で動作されるアプリケーションのすべてが一定期間以上定常状態にある場合に動作モード切り替え許可信号を出力するものである。動作モード決定手段１０３は、定常状態確認手段１０７から動作モード切り替え許可信号が出力された場合に、切り替わり通知手段１０２から出力された並列処理アプリケーション項目の情報およびリソース量の情報を使用して、演算手段１０４において実行される動作モードを決定するものである。
【００１３】
次にソフトウエア実行装置１００１についてのより詳細な内容について、以下に説明する。
【００１４】
演算手段１０４は、複数のアプリケーションを、選定された動作モードで並行処理するものである。各アプリケーションは複数の動作モードを有している。異なる動作モードの間では、前述した図３４に示すように、実現される機能の少なくとも一部が異なっている。ここで、「機能が異なっている」場合としては、機能の種類が異なっている場合と、機能の種類は同一であってもその性能の優劣の段階が異なっている場合とがある。機能が異なれば、一般に、ＣＰＵ（Central Processing Unit：中央処理装置）演算量、メモリ使用量などのリソースの使用量も異なる。基本的に、高度な機能を有する動作モードにおいては、多くのリソースが必要とされる。
【００１５】
外部入力または演算手段１０４で実行中のプログラムの状態遷移命令などによって、並行処理されるアプリケーションの項目（並行処理アプリケーション項目とも称する）または使用可能リソース量が変化した際には、切り替わり通知手段１０２は動作モード決定手段１０３へ、切り替わり通知信号を入力する。切り替わり通知信号は、並行処理アプリケーション項目と現在使用可能なリソース量との情報とを含む。
【００１６】
動作モード決定手段１０３は、上記のように切り替わり通知手段１０２から切り替わり通知信号が入力されている状態で、定常状態確認手段１０７から動作モード切り替え許可信号が入力されると、動作モード選定のための演算を開始する。
【００１７】
具体的には、まず、切り替わり通知信号によって特定される並行処理アプリケーション項目についての全動作モードにおける使用リソース量情報を動作モード決定手段１０３は使用リソース量情報記憶部１０５から取得する。さらに動作モード決定手段１０３は情報記憶部１００から、動作モードの決定に有用な、アプリケーション毎の情報を取得する。この情報は動作モード毎の情報を含んでいてもよい。情報記憶部１００は、たとえば、後述する優先機能情報記憶部１０８（図３を参照して後述）、クオリティ点数情報記憶部１１０（図３を参照して後述）、リソース不足情報記憶部１１１（図３を参照して後述）、および動作必須アプリケーション情報記憶部１０９（図１９を参照して後述）の少なくともいずれかを含んでいてもよい。
【００１８】
上述した情報を用いて演算を行うことで動作モード決定手段１０３は、演算手段１０４が並列処理するべきアプリケーションの各々の動作モードの最適な組み合わせを決定し、それを演算手段１０４に通知する。演算手段１０４は通知された動作モードの実行プログラムを、プログラム記憶部１０６から取得する。プログラム記憶部１０６は、各アプリケーションの各動作モードプログラムを記憶している。
【００１９】
動作モード決定手段１０３で決定された動作モードが演算手段１０４に伝わった時点で、演算手段１０４は切り替わり通知手段１０２に対して動作モード決定手段１０３への切り替わり通知信号の入力を取りやめさせる。以降、外部入力または演算手段１０４で実行中のプログラムの状態遷移命令などによって再び並行処理アプリケーション項目または使用可能リソース量が変化した際に、切り替わり通知手段１０２は動作モード決定手段１０３へ、更新された切り替わり通知信号を入力する。
【００２０】
なお、上述した現在使用可能なリソース量は、変動する量である場合も固定した量である場合もあり、それは装置全体の仕様による。前者の例として、動作モード決定手段１０３で動作モードが決定されるもの以外の他のアプリケーションが演算手段１０４で並行処理されている場合がある。その場合、上記他のアプリケーションの状態が変動したときに、動作モード決定手段１０３の動作モード決定手段が決定するアプリケーションが使用可能なリソース量が変動する。
【００２１】
図２を参照して、並行処理されるすべてのアプリケーションの動作が定常状態にあるという条件が満たされない場合、言い換えれば少なくとも１つのアプリケーションの動作が定常状態にない場合、演算手段１０４は定常状態確認手段１０７へ非定常状態フラグを出力する。非定常状態フラグは、各アプリケーションがこれまでの定常状態から、状態遷移、起動/停止など何らかの変化をした場合に出力されるものである。このような場合として、たとえば、ユーザ操作があった場合、または自動バックアップ処理がスタートした場合などがある。非定常状態フラグが入力された定常状態確認手段１０７は、動作モード切り替え禁止状態２０１を取る。
【００２２】
その後、並列処理されるすべてのアプリケーションの動作が定常状態になることによって非定常状態フラグが消えると、定常状態確認手段１０７は動作モード切り替え待機状態２０２に入る。この状態のまま非定常状態フラグの入力を受けることなく一定期間以上経過すると、定常状態確認手段１０７は動作モード切り替え演算状態２０３に遷移する。なお上記一定期間としては、ソフトウエア実行装置１００１またはアプリケーションの種類に応じて予め定められた待機時間を用い得る。
【００２３】
動作モード切り替え演算状態２０３に遷移した定常状態確認手段１０７は動作モード決定手段１０３へ動作モード切り替え許可信号を入力する。動作モード決定手段１０３は、動作モード切り替え許可信号の入力を受けている場合にのみ、切り替わり通知手段１０２からの切り替わり通知信号の入力に応じて、動作モード決定のための演算を開始する。決定された動作モードは演算手段１０４に通知される。通知された内容を用いて演算手段１０４はアプリケーションの動作モードを切り替える。この際、演算手段１０４は、新たに用いられる動作モード（切り替えモード）が決定した旨を定常状態確認手段１０７へ伝達する。これを受けて定常状態確認手段１０７は、最適動作モード動作状態２０４に入る。その後、アプリケーションの動作が定常状態である間は、定常状態確認手段１０７は最適動作モード動作状態２０４のままである。定常状態が破られると、定常状態確認手段１０７は、非定常フラグの入力を受けることで、前述した動作モード切り替え禁止状態２０１に入る。つまり定常状態確認手段１０７は、動作モード切り替え待機状態２０２、動作モード切り替え演算状態２０３、および最適動作モード動作状態２０４のいずれの状態であっても、非定常状態フラグが立つと直ちに動作モード切り替え禁止状態２０１に戻る。
【００２４】
動作モード切り替え禁止状態２０１に遷移した定常状態確認手段１０７は、動作モード切り替え禁止状態２０１に遷移した旨の通知を動作モード決定手段１０３へ行う。これを受けて動作モード決定手段１０３は、各動作モードとして非定常状態専用の動作モードまたは最も使用リソースの少ない動作モードを選択し、それを演算手段１０４へ通知する。この通知を受けた演算手段１０４は、非定常状態専用の動作モードまたは最も使用リソースの少ない動作モードでの動作への切り替えを行う。
【００２５】
次に本実施の形態による効果について、以下に説明する。
【００２６】
仮に、動作モード決定手段１０３による動作モードの決定を、並行処理中のアプリケーションが何らかの状態遷移を起こすたびに無条件に行ったとすると、動作モードの切り替えのために時間およびリソースが費やされるにもかかわらず、それによる効果が得られる時間が短いことが多く、効率が悪い。
【００２７】
たとえば音楽メディアなどでユーザが連続的な入力操作などしている最中は、リソースの消費量は一定せず、短時間で状態が変化してしまう。つまりソフトウエア実行装置１００１は、まったく定常状態を取らないか、あるいは短時間しか定常状態を取らない。このような場合における動作モードの切り替えは非効率的である可能性が高い。それに対して上記操作が終わり、単純に音楽再生を継続している状態においては、アプリケーションの動作が定常状態にある。よってリソースの消費量は長期間一定値で安定する。並行処理される他のアプリケーションも同様であれば、比較的長期間にわたって、並行処理されるすべてのアプリケーションの動作が定常状態となる。このような場合にのみ動作モードの最適化が行われるのであれば、最適化に費やされた時間およびリソースに見合う効果が得られる可能性が高い。
【００２８】
そこで本実施の形態においては、定常状態確認手段１０７は、演算手段１０４において並行処理されるすべてのアプリケーションの動作が一定期間以上にわたって定常状態にある場合にのみ、動作モード決定手段１０３へ動作モード切り替え許可信号を入力する。これにより、並行処理されるすべてのアプリケーションの動作が一定期間以上にわたって定常状態にある場合にのみ、動作モード決定手段１０３は、動作モードを切り替えのための演算を始める。よって、動作モードの最適化処理に起因して並行処理の性能がかえって低下することを避けることができる。
【００２９】
＜実施の形態２＞
可能であれば、複数の動作モードのうち、より高機能または高性能な動作モードが実行されることが当然好ましい。しかしながら、並列処理で動作されるすべてのアプリケーションについて高機能または高性能な動作モードが選択されると、リソースが足りなくなる場合がある。このような場合、どのアプリケーションを優先的に高機能または高性能な動作モードで動作させるかが適切に決定されることが望ましい。
【００３０】
図３を参照して、上記決定の指標として適した情報を格納するものとして、本実施の形態のソフトウエア実行装置１００２は、前述した実施の形態１の情報記憶部１００（図１）に対応するものとして、クオリティ点数情報記憶部１１０と、優先機能情報記憶部１０８と、リソース不足情報記憶部１１１とを有する。クオリティ点数情報記憶部１１０はクオリティ点数の情報を格納するものである。優先機能情報記憶部１０８は優先機能情報を格納するものである。
【００３１】
図４および図５を参照して、本実施の形態における動作モード決定手段１０３は、上述したクオリティ点数情報記憶部１１０と、優先機能情報記憶部１０８と、リソース不足情報記憶部１１１との各々から取得した情報を用いて、動作モードを決定する処理を行う。具体的には、以下の処理が行われる。
【００３２】
ステップ３０１にて、まず、切り替わり通知手段１０２からの切り替わり通知信号が入力されている状態で、定常状態確認手段１０７からの動作モード切り替え許可信号を受ける。次にステップ３０２にて、切り替わり通知手段１０２から、並行処理アプリケーション項目の情報と、現在使用可能な各リソースの量の情報とが取得される。そしてステップ３０３にて、クオリティ点数情報記憶部１１０より、ステップ３０２にて取得した並列動作アプリケーション項目の全動作モードがそれぞれどのような機能を持つのかを点数化したクオリティ点数情報が取得され、また使用リソース量情報記憶部１０５よりそれら動作モードの使用リソース量の情報が取得される。ステップ３０４にて、全アプリケーションが最も高機能な動作モードで動作するとした場合の組み合わせが、現組み合わせ候補として設定される。そしてステップ３０５にて、リソース不足となる項目が存在するか否かが判定される。
【００３３】
図６を参照して、上記ステップ３０５は、次のように行われる。たとえばリソース項目がi個ある場合、ステップ３０５ａおよび３０５ｄ間の処理はi回繰り返される。ステップ３０５ｂにて、リソース不足が生じているか否かが各リソースについて確認される。ステップ３０５ｃにて、リソース不足が生じた項目があった場合にはその項目がリソース不足情報記憶部１１１（図３）に記憶される。
【００３４】
再び図４および図５を参照して、上記ステップ３０５の判定結果を用いて、全リソース項目が不足を起こさずに動作すると判定された場合には、ステップ３０６にて、ステップ３２０への分岐がなされ、現組み合わせ候補が動作モードとして選択される。一方、リソースに不足が生じた場合には、処理がステップ３０７へ進められる。
【００３５】
ステップ３０７にて、優先機能情報記憶部１０８（図３）より、どの機能を優先させるべきかを示した優先機能情報が取得される。
【００３６】
そしてステップ３０８にて、現組み合わせ候補の動作モードを置き換えることで、新たな動作モードの組み合わせの作成が試みられる。具体的には、現組み合わせ候補の動作モードを、より使用リソース量の少ないものに置き換えることが試みられる。この詳細は、後述の「クオリティ点数情報と演算方法について」の項において説明する。
【００３７】
ステップ３０９にて、上記ステップ３０８における新たな動作モードの組み合わせの作成が可能であったか否かが確認される。新しい動作モードの組み合わせが作成できた場合には、ステップ３１０にて、現組み合わせ候補が新しい組み合わせに置き換えられる。ステップ３１１および３１２にて、この組み合わせにおいてリソース不足を起こすリソース項目がないかが確認される。リソース不足の項目がなかった場合には、動作モードの組み合わせは現組み合わせ候補で決定される（ステップ３２０）。リソース不足の項目があった場合には、ステップ３０８に戻って、さらなる新しい組み合わせが作成される。よって必要に応じてステップ３０８〜３１２の繰り返しが行われる。ステップ３１１の処理の詳細はステップ３０５のもの（図６）と同様である。
【００３８】
すべてのアプリケーションの動作モードにおいて、クオリティ点数の高いものほど多くリソースを使用するという関係が成立している場合には、ステップ３１１にてリソース不足か否かの確認を行うリソースの項目は、ステップ３０５ｃにてリソース不足の項目として記憶されたもののみとしてもよい。なぜならば、ステップ３０８はステップ３０４による組み合わせに対し、動作モードの組み合わせを、より使用リソースの少ないものに置き換えているので、ステップ３０５にて不足と判断されなかったリソース項目は、ステップ３０８においてリソース不足と判断される可能性はないためである。このような処理を行わない場合は、リソース不足情報記憶部１１１が省略され得る。
【００３９】
どの動作モードも停止しない前提での組み合わせがすべて出尽くすまでステップ３０８〜３１２を繰り返してもリソース不足となる項目が存在する場合、すなわちステップ３０９にて「ｎｏ」の判定がなされる場合は、（本実施の形態においては図５における結合子ＣからＤへ直接処理が進み）ステップ３１６にて、動作不能エラーの通知が演算手段１０４へ送信され、処理が終了される。なお後述する実施の形態３においては、動作不能エラーの回避を試みるために、結合子Ｃ（図５）の後に、別途説明する方法での処理がなされる。
【００４０】
なお、上記以外の構成については、上述した実施の形態１の構成とほぼ同じであるため、同一または対応する要素について同一の符号を付し、その説明を繰り返さない。
【００４１】
本実施の形態によれば、クオリティ点数の情報と優先機能情報とを使用して動作モードの組み合わせが決定される。これによりリソース配分においてどの機能が優先されるべきかが考慮される。よって動作モードの最適化をより適切に行うことができる。
【００４２】
（クオリティ点数情報と演算方法について）
クオリティ点数の情報と優先機能情報とを使用して動作モードの組み合わせを作成するステップ３０８（図５）の具体例について、以下に説明する。
【００４３】
図７〜図１０のそれぞれは、カーマルチメディアにおけるアプリケーションが有する複数の動作モードの各々の使用リソース量とクオリティ点数との例を示す。
【００４４】
たとえば図７は、カーナビの画像表示に係るアプリケーションについてのものであり、上に行くほど画質が良く、それに伴って使用リソースが多い。たとえば「ＮＯ．１」の動作モードは、３Ｄ機能を有することで最も画質が良く、それに伴ってＣＰＵ使用量およびメモリ使用量が最も多い。このアプリケーションで動作モードの切り替えによって優劣に変動を生じる機能は画質であり、ゆえにこのアプリケーションの各動作モードに付けられるクオリティ点数は画質クオリティ点数である。同様に図８〜図１０においても、それぞれのアプリケーションにおいて、各動作モードに対して、機能に応じたクオリティ点数が付けられている。
【００４５】
また図８のように、アプリケーションの各動作モードが複数の機能を有し、各機能に応じてクオリティ点数が付けられている場合もある。すなわち、各動作モードに応じて複数のクオリティ点数が付けられているアプリケーションも存在する。具体的には、アプリケーション「カーナビ文字情報表示」は、情報密度（具体的には文字情報の密度）に関する機能と、画質（具体的にはアンチエイリアスの有無）に関する機能とを有する。動作モード「ＮＯ．１」〜「ＮＯ．９」の各々は、上記の情報密度に関する機能と画質に関する機能とのそれぞれに応じて、情報密度クオリティ点数と画質に関するクオリティ点数とを有する。
【００４６】
また、図１０の「ＮＯ．１」および「ＮＯ．２」の動作モードは、同じ内容を有している。ここでは、動作モードの切り替えの重み付けを他のアプリケーションとそろえるために、これらに対してあえて異なるクオリティ点数が与えられている。
【００４７】
図１１および図１２の各々は、カーマルチメディアにおける優先機能情報の例を示す。図１１においては、すべての機能に同じ順位が与えられている。これは、動作モードの決定に際して、すべての種類のクオリティ点数に対する評価が均等であることを意味する。一方、図１２においては、動作モードの決定に際して、情報密度および情報更新頻度のクオリティ点数が他の種類のクオリティ点数よりも優先されることを意味する。この結果、リソース不足が生じた場合、上記他の種類のクオリティ点数がより低い動作モードが選択される。
【００４８】
なお図７〜図１２はカーマルチメディア分野に関する複数のアプリケーションの情報であるが、複数のアプリケーションはソフトウエア実行装置によって並行処理で動作されるものであるならば、どのような分野のものであってもよい。アプリケーションの機能は、アプリケーションの分野に応じて様々なものであり得る。
【００４９】
図１３〜図１８のそれぞれは、ステップ３０８（図５）における優先機能情報とクオリティ点数とを使用した動作モードの決定方法の例である方法ａ〜ｆを示す。このようないくつかの方法から、ソフトウエア実行装置１００２または１００３の使用状況に適したものを採用し得る。
【００５０】
特に方法ａ〜ｄは、図７〜図１０に示す各アプリケーションにおける動作モードの決定を、図１２に示す優先機能の順位に基づいて、それぞれ異なる方法で行う場合の例を示す。方法ａおよびｂの例は、アプリケーションの数と、クオリティ点数の段階の数とが比較的少ないときに効果が高い。この方法は、動作モードの組み合わせの１回の置き換えに際して、優先順位を考慮して１つの機能に着目し、そのクオリティ点数が１点（より一般には１段階）低くなるような動作モードへの切り替えが行われる。
【００５１】
方法ａにおいては、ステップ３０８〜３１２（図５）のループにおいてステップ３０８にて、まず、優先順位が最も低い機能に応じたクオリティ点数に着目して、クオリティ点数が１点ずつ低くなるように動作モードが置き換えられる。この置き換えがすべて終わってもループが継続される場合は、次に優先度が低い機能に応じたクオリティ点数に着目して、クオリティ点数が１点ずつ低くなるように動作モードが置き換えられる。この置き換えがすべて終わってもループが継続される場合は、さらにその次に優先順位が低い機能に着目した処理がなされる。方法ｂにおいては、上記ループが継続する限り、まず、優先順位が最も低い機能に応じたクオリティ点数が最低点数になるまで置き換えが進められる。その後、次に優先順位が低いものに着目した処理がなされる。なお方法ａまたはｂにおいて、同じ優先順位のものの間での置き換えの順番は、たとえば、ステップ３０５で確認されている現在不足しているリソースの項目がより多いものが先とされてもよい。
【００５２】
方法ｃおよびｄは、アプリケーションの数が多い場合に、方法ａおよびｂに比して処理時間が短くなる方法である。この方法においては、優先順位の低い機能が複数存在する際に、その順位の機能に応じた複数のクオリティ点数のすべてが１度に１点ずつ低くなるように、複数のアプリケーションの動作モードが１度に置き換えられる。方法ｃにおいては、優先順位が最も低い機能の各々に応じたクオリティ点数が１点低くなる置き換えの後、優先順位が次に低い機能の各々に応じたクオリティ点数が１点低くなる置き換えが行われる。方法ｄにおいては、優先順位が最も低い機能の各々に応じたクオリティ点数が最低点数になるまで置き換えが行われた後、次に優先順位が低い機能の各々に応じたクオリティ点数を下げる置き換えが行われる。
【００５３】
方法ｅおよびｆは、動作モードが有するクオリティ点数の段階が特に多い場合に、方法ａ〜ｄに比して処理時間が短くなる方法である。ここでは、並行処理で動作させようとしているアプリケーションＡ〜Ｄの各々が１０個の動作モードを有し、この１０個の動作モードのそれぞれが１〜１０のクオリティ点数を有しているとする。またアプリケーションＡ〜Ｄのそれぞれが（同一のアルファベットＡ〜Ｄを用いて表記して）機能Ａ〜Ｄを有しており、機能Ａ〜Ｄについての優先機能情報は（順位ではなく）Ａ：Ｂ：Ｃ：Ｄ＝１０：６：３：３の比で表されるとする。
【００５４】
方法ｅでは、クオリティ点数を１点ずつ落とすのではなく、優先機能情報の比に従って一度に複数のクオリティ点数が変更される（図１７中「ステップ３０８（ループ１回目）」を参照）。その後、ループ２回目、３回目・・・とループが繰り返されるに従って、最もリソース配分の大きい機能Ａに応じたクオリティ点数を１段階ずつ下げつつ、他のクオリティ点数は、固定された上記の比に従って算出される。算出された数値に対して所定の基準を満たすクオリティ点数を有する動作モードが選択されることとなる。たとえば、算出された数値以下で最大のクオリティ点数を有する動作モードが選択されてもよく、あるいは、算出された数値に一番近いクオリティ点数を有する動作モードが選択されてもよい。この方法には、機能に対するリソースの按分を設定に従ったものとしつつ、リソースを最大限に使用することができる動作モードの組み合わせを選択することができるというメリットがある。
【００５５】
方法ｆでは、２回目以降の各ループにおいて、全アプリケーションの各々の動作モードが、クオリティ点数の１段階低いものに置き換えられる。この方法によると、組み合わせの計算が方法eの方法よりも簡単になるというメリットがある。
【００５６】
なお上記方法ａ〜ｆは例示であり、これら以外にも多くのリソース配分の仕方が存在する。
【００５７】
＜実施の形態３＞
前述した動作エラーが生じることは、リソース制限上、切り替わり通知手段１０２から通知された並列処理アプリケーション項目のすべてを並列処理で動作せせることが不可能であることを意味する。よってこの動作不能エラーの回避を試みるためには、どのアプリケーションを動作させ、どのアプリケーションの動作を取りやめるか、という判断がなされることが望ましい。本実施の形態はこのような判断を伴うものである。
【００５８】
図１９を参照して、本実施の形態のソフトウエア実行装置１００３は、動作必須アプリケーション情報を格納する動作必須アプリケーション情報記憶部１０９を有している。以下、ソフトウエア実行装置１００３の動作モード決定手段１０３において行われる処理について説明する。
【００５９】
本実施の形態においては、ステップ３０９（図５）において新しい組み合わせが作成不可能であると判定された場合、図５に示す結合子Ｃの後に、図２０に示す結合子Ｃからの処理が行われる。具体的には、まずステップ３１３にて、動作モード決定手段１０３は動作必須アプリケーション情報記憶部１０９から動作必須アプリケーション情報を取得する。
【００６０】
次にステップ３１４〜３１９の処理により、リソース確保のために動作をさせないアプリケーションが決定される。具体的には、ステップ３１４にて、動作必須アプリケーション以外のアプリケーションの少なくとも一部を停止させた、新しい動作モードの組み合わせが作成される。この詳細は、後述の「動作必須アプリケーション情報と演算方法について」の項において説明する。
【００６１】
ステップ３１５にて、ステップ３１４における作成処理が可能であったか否かが確認される。可能であった場合、ステップ３１７にて、現組み合わせ候補が置き換えられる。そしてステップ３１８および３１９にて、この組み合わせにおいてリソース不足となる項目がないかが確認される。リソース不足の項目がなかった場合には、動作モードの組み合わせは現組み合わせ候補で決定される（ステップ３２０）。リソース不足の項目があった場合には、ステップ３１４に戻って、動作必須アプリケーション以外のアプリケーションの少なくとも一部をさらに停止させた、新しい動作モードの組み合わせが作成される。
【００６２】
もしステップ３１５にて、これ以上新しい組み合わせを作成することは不可能と判断されたとするとそれは、動作をさせないアプリケーションの組み合わせとして可能なものをすべて試し尽くしてもやはりリソース不足が生じることを意味する、この場合には、動作必須アプリケーションはすべて動作させるという条件を満足することができない。よって異常状態と見なされ、（図２０の結合子Ｄから図５の結合子Ｄへ処理が進み）ステップ３１６にて、動作不能エラーが演算手段１０４へ送信される。
【００６３】
なおステップ３１８の処理内容の詳細は、ステップ３０５（図６）と同様である。またステップ３１８でリソース不足か否かの確認が行われるリソース項目は、ステップ３１１にてリソース不足と判断された項目のみとされてもよい。なぜならば、ステップ３１４にて作成される組み合わせはステップ３０８にて作成される組み合わせに対して、動作モードのいくつかを動作させないようにするものであることから、ステップ３１１にて不足と判断されなかったリソース項目は、ステップ３１８にてリソース不足と判断される可能性がないためである。
【００６４】
なお、リソース項目の例として上記ではＣＰＵ演算量およびメモリ使用量を例に挙げたが、それ以外にも、並列処理において他のアプリケーションと使用時間または使用量をシェアしあう必要のあるリソースは何であれ該当する。
【００６５】
上記以外の構成については、上述した実施の形態２の構成とほぼ同じであるため、同一または対応する要素について同一の符号を付し、その説明を繰り返さない。
【００６６】
（動作必須アプリケーション情報と演算方法について）
動作をさせないアプリケーションを考慮して動作モードの組み合わせを作成するステップ３１４（図２０）の具体例について、以下に説明する。
【００６７】
図２１は、「位置検知システム」が動作必須アプリケーションに該当している「場合ａ」を示す。場合ａにおいては、ステップ３１４〜３１９のループ１回ごとに、動作させないアプリケーション（図中「停止」と記載されたアプリケーション）を１つずつ増やした組み合わせが作成され、リソースが必要量を満たすか確認される。
【００６８】
図２２は、「位置検知システム」が動作必須アプリケーションに該当している「場合ｂ」を示す。場合ｂにおいては、ステップ３１４〜３１９のループ１回ごとに、動作必須アプリケーション以外のものについて、優先順位が最も低い機能のみを有するアプリケーションが一斉に「停止」とされる。よって、１つの機能のみを有するアプリケーションについては、その機能の優先度の低さに応じて、「停止」とされるか否かが決定される。
【００６９】
なお場合ａおよびｂの方法は、ステップ３０８（図５）において、前述した方法ａ〜ｆ（図１３〜１８）のどれが行われていても可能な方式である。
【００７０】
図２３に示す「場合ｃ」は、ステップ３０８（図５）において方法ｅ（図１７）が用いられていた際に可能な方式である。具体的には、ステップ３０８における、方法ｅによる優先機能情報の比に従った処理の後、引き続きステップ３１４（図２０）にて、上記比に従った処理が行われる。動作必須アプリケーションは、比の算出結果に拘らず停止されない。一方、動作必須アプリケーション以外のものに関しては、算出された数値に対して所定の基準を満たすクオリティ点数を有する動作モードが存在しなくなった場合に、動作しないものとされる。たとえば、算出された数値以上のクオリティ点数を有する動作モードが存在しなくなった場合、あるいは、算出された数値から所定の誤差範囲のクオリティ点数を有する動作モードが存在しなくなった場合に、上記措置が行われてもよい。
【００７１】
図２４に示す「場合ｄ」は、ステップ３０８（図５）において方法ｆ（図１８）が用いられていた際に可能な方式である。具体的には、ステップ３０８における、方法ｆによる優先機能情報の比に従った処理の後、引き続きステップ３１４（図２０）にて、全アプリケーションの各々の動作モードが、クオリティ点数の１段階低いものに置き換えられる。その際、それ以上クオリティ点数を下げることができなければ、対応するアプリケーションは動作しないものとされる。ただし動作必須アプリケーションについては、クオリティ点数が最低の動作モードが選択されている場合、それ以上クオリティ点数は引き下げられない。
【００７２】
＜実施の形態４＞
実施の形態２において説明した方法ｃ〜ｆ（図１５〜図１８）によると、現組み合わせ候補を決定する際、１回のステップ３０８で複数のアプリケーションの動作モードがクオリティ点数の低いものに切り替えられる。このことは、ステップ３０８〜３１２のループの回数を低減し得る点で有利であるが、クオリティ点数を全体として必要以上に低減する決定がなされる可能性がある。その場合、リソースの使用量が必要以上に抑えられることになるので、ソフトウエア実行装置１００２または１００３の本来の性能を引き出すことができなくなる。本実施の形態は、上述したようなクオリティ点数の過剰な低減を避けるものである。
【００７３】
図２５は、本実施の形態において動作モード決定手段１０３（図３または図１９）が行う処理を概略的に示す。なお図２５の接続子Ａより前のフローは、実施の形態２において説明した図４のフローと同じである。
【００７４】
図２５のフローは、図５のフローに対して、動作モードの微調整のフローとしてステップ４２１〜４２４を加えたものである。前述した実施の形態２においては、ステップ３１２（図５）においてリソース不足の項目が出なかった場合、動作モードの組み合わせを現組み合わせ候補により決定するステップ３２０が行われ、処理が終了する。これに対して本実施の形態においては、ステップ３１２においてリソース不足の項目が出なかった場合、動作モードの微調整のフローがステップ４２１から行われる。以下、この処理について具体的に説明する。
【００７５】
ステップ４２１にて、現組み合わせ候補に対し、いずれかのアプリケーションの動作モードをクオリティ点数の高い側に引き上げた場合の新しい組み合わせが生成される。この組み合わせを「次組み合わせ候補」と呼ぶ。ステップ４２２にて、次組み合わせ候補でリソース不足になる項目がないかが確認される。ステップ４２３にて、上記ステップ４２２においてリソース不足が起こらない場合には、ステップ４２４へ処理が進められる。ステップ４２４にて、現組み合わせ候補が次組み合わせ候補に置き換えられた後、再度ステップ４２１が行われる。すなわち、更新された現組み合わせに対し、いずれかのアプリケーションの動作モードをクオリティ点数の高い側に引き上げた組み合わせが、新たな次組み合わせ候補として生成される。そして、ステップ４２３にて次組み合わせ候補がリソース不足を起こすと判定された場合には、ステップ３２０へ処理が進められる。すなわち、現組み合わせ候補を採用する決定の後、処理が終了される。
【００７６】
さらに図２６を参照して、上記処理の例について、以下に説明する。
【００７７】
現組み合わせ候補１０ａ１は、ステップ３１２においてリソース不足の項目なしと判定されたときの現組み合わせ候補である。現組み合わせ候補１０ａ１は、ステップ３０８において方法ｃ（図１５）による組み合わせ作成を行ったときにループの３回目で作成されたものである。
【００７８】
この後、ステップ４２１にて、現組み合わせ候補におけるいずれか１つのアプリケーションの動作モードをクオリティ点数の高いものに切り替えることで、次組み合わせ候補１０ｂ１が作成される。ここではカーラジオ音質のクオリティ点数が「１」から「２」に上げられている。そしてステップ４２２にて次組み合わせ候補１０ｂ１がリソース不足になるかどうか確認が行われ、ステップ４２３でその判定が行われる。
【００７９】
上記ステップ４２３にてリソース不足の項目があると判定されれば、ステップ３２０にて、現組み合わせ候補がそのまま動作モードの組み合わせとして決定される。逆に、上記ステップ４２３にてリソース不足の項目がないと判定されれば、ステップ４２４にて、次組み合わせ候補１０ｂ１を現組み合わせ候補１０ａ２とすることで、現組み合わせ候補が置き換えられる。そしてステップ４２１にて、再び現組み合わせ候補１０ａ２に対していずれかのアプリケーションの動作モードをクオリティ点数の高いものに上げた組み合わせが、次組み合わせ候補１０ｂ２として作成される。ステップ４２２にて、次組み合わせ候補１０ｂ２においてリソースが不足する項目がないかの確認が行われる。ステップ４２３にて、その判定が行われる。以下同様に、ステップ４２３においてリソースの不足が確認されるまで、いずれかのアプリケーションの動作モードが１つずつクオリティ点数の高いものに切り替えられていく。
【００８０】
いずれのアプリケーションの動作モードを切り替えるかの順番については装置の都合に合わせて任意であるが、次組み合わせ候補は、ステップ３１２でリソース不足項目なしと判断された組み合わせ候補と、その１つ前にリソース不足項目ありと判断された組み合わせ候補との間を補完するものでなければならない。図２６の例は、方法ｃ（図１５）におけるループの２回目でステップ４１２においてリソース不足項目ありと判定され、３回目の組み合わせでリソース不足項目なしと判定された場合のものである。そのため、ステップ４２１〜４２４のループは、図１５の３回目のループにおける組み合わせである現組み合わせ候補１０ａ１と、２回目のループにおける組み合わせに対応する次組み合わせ候補１０ｂ４との差分となっている項目を１つずつ上げていき、最後まで次組み合わせ候補がリソース不足項目なしの場合には、最後の次組み合わせ候補は、次組み合わせ候補１０ｂ４のとおり、２回目のループにおける組み合わせと等しくなる。ただし、最後の次組み合わせ候補１０ｂ４の次の次組み合わせ候補は、ステップ４２３にて必ずリソース不足と判定される。なぜならステップ４２１〜４２４のループに入る前に、ステップ４１２の判定で既にリソース不足の判定がなされているためである。そして現組み合わせ候補１０ａ４が動作モード組み合わせとして決定される。
【００８１】
なお図２７は、参考に、上記の処理において生じ得ない次組み合わせ候補１０ｂ５を示す。次組み合わせ候補１０ｂ５では、カーナビ文字情報表示の情報クオリティ点数が「３」となっている。しかし、図１５の３回目のループと２回目のループとの双方でこの点数は「２」であるため、ステップ９２１において作成される次組み合わせ候補は、この場合、どれもこの点数は変わらず「２」のままでなければならない。
【００８２】
なお、上記以外の構成については、上述した実施の形態２または３の構成とほぼ同じであるため、同一または対応する要素について同一の符号を付し、その説明を繰り返さない。
【００８３】
＜実施の形態５＞
上記実施の形態２〜４において、並列処理アプリケーション項目、使用可能リソース量、および優先機能情報の各条件の使用頻度に偏りがあり、ある特定の組み合わせの条件のみが頻繁に使用される場合、同じ条件の組み合わせで動作モードの決定のための演算が頻繁に繰り返される。本実施の形態は、この繰り返しを抑えることにより演算を効率化するものである。
【００８４】
図２８を参照して、本実施の形態のソフトウエア実行装置１００５は動作モード履歴記憶部１１２を有する。動作モード履歴記憶部１１２は、並列処理アプリケーション項目と使用可能リソース量と優先機能情報との条件に基づいて動作モード決定手段１０３がこれまでに決定してきた動作モードの組み合わせを格納するものである。つまり動作モード履歴記憶部１１２は、並列処理アプリケーション項目と使用可能リソース量と優先機能情報との条件とその条件下で決定された動作モードの組み合わせとを格納するものである。本実施の形態においては、動作モード決定手段１０３は、動作モード履歴記憶部１１２に格納されている上記条件の中から、動作モード決定手段１０３に入力された条件と一致するものがあるか否か検索を行う。もし既出の条件が再び動作モード決定手段１０３に入力された場合には、動作モード決定手段１０３は、動作モード決定のための演算を行わず、代わりに動作モード履歴記憶部１１２から取得した動作モードの組み合わせをそのまま使用する。これにより、既出のアプリケーションの組み合わせでの並行処理時に、動作モード決定手段１０３が全く同じ計算を再度やり直す必要がない。よって動作モード決定手段１０３での演算時間が短縮される。
【００８５】
図２９および図３０は、本実施の形態において動作モード決定手段１０３が行う処理を概略的に示す。最初のステップ３０１および３０２は、図４のものと同じである。次にステップ５０３にて、優先機能情報記憶部１０８から優先機能情報が取得される。この処理は、ステップ３０７（図５）と同様のものである。
【００８６】
次に、ステップ５０４にて、動作モード履歴記憶部１１２から動作モード組み合わせ履歴情報が取得される。ステップ５０５にて、動作モード組み合わせ履歴情報中に、ステップ３０２で取得された並列処理アプリケーション項目および各リソースの使用可能量と、ステップ５０３で取得された優先機能情報との条件が一致するものがあるかが確認される。ステップ５０６にて、一致するものがあるか判断される。一致するものがあった場合、ステップ５０７にてその組み合わせが現組み合わせ候補に置き換えられ、ステップ５１０にてその組み合わせで動作モードが決定され、処理が終了する。
【００８７】
一方、一致するものがなかった場合には、処理がステップ５０８に進む。ステップ５０８は、ステップ３０３からの処理（図４および図５参照）であり、動作モード決定のための演算を行うものである。ただしこの処理におけるステップ３０７は、既にステップ５０３にて優先機能情報が取得されていることから、省略され得る。またこの処理がステップ３２０（図５）を経て終了する場合、すなわち動作モード決定手段１０３の演算によって動作モードの組み合わせが決定された場合には、処理終了前に、ステップ５１１にて、新たに決定された組み合わせが動作モード履歴記憶部１１２に記憶される。
【００８８】
なお本実施の形態は、動作必須アプリケーション情報記憶部１０９が設けられない場合、または、動作必須アプリケーションが変動しない項目である場合に適している。
【００８９】
＜実施の形態６＞
上記実施の形態５において仮に、動作必須アプリケーションが変動する項目である場合、動作モード履歴記憶部１１２（図２８）から検索された動作モードの組み合わせの中に動作させないアプリケーションが存在した場合に、この動作させないアプリケーションが動作必須アプリケーションである可能性がある。本実施の形態は、この可能性について確認を行い、該当する場合は必要な対処を行うものである。
【００９０】
図３１は、本実施の形態における動作モード決定手段１０３（図２８）での処理を説明するフロー図の一部である。なお接続子ＤおよびＥまでの処理は、前述した図２９のものと同じである。ステップ５０７（図２９）の後、前述した実施の形態５においてはステップ５１０（図３０）にて動作モードが現組み合わせ候補で決定されるが、本実施の形態においては処理がステップ６０８（図３１）へ進む。
【００９１】
ステップ６０８にて、現組み合わせ候補に、動作させないアプリケーションが含まれていないかが確認される。含まれていない場合、ステップ５１０にて、動作モードは現組み合わせ候補で決定される。含まれている場合、その項目が必須動作アプリケーションに該当していないかを確認する必要がある。動作必須アプリケーションが変動している場合、過去において動作させないと決定されたアプリケーションが現在の動作必須アプリケーションに該当している可能性があるためである。
【００９２】
そこで、ステップ６０９にて動作必須アプリケーション情報が取得され、ステップ６１０にて動作必須アプリケーションがすべて動作しているかが確認される。動作必須アプリケーションがすべて動作している場合、ステップ５１０にて、動作モードは現組み合わせ候補で決定される。一方、動作必須アプリケーションが動作しないという組み合わせになっていた場合には、実施の形態５において説明した、ステップ５０８からの処理が開始される。
【００９３】
＜実施の形態７＞
実施の形態５または６においては、動作モード履歴記憶部１１２にこれまで記憶された動作モードの組み合わせの履歴のすべてがステップ５０４（図２９）にて取得されかつステップ５０５にて比較される。このため、データの取得および比較に長い時間と大きなメモリ領域とを必要とすることがある。
【００９４】
これに対して本実施の形態においては、この処理をより効率化するために、動作モード履歴記憶部１１２に記憶された組み合わせの各々が、動作モード決定手段１０３による動作モードの最終的な決定に何回用いられたかの回数がカウントされる。回数が多いものほど、最終的に使用される確率の高いアプリケーションの組み合わせであると考えられる。よって動作モード決定手段１０３は、動作モード履歴記憶部１１２から上記回数が多い順番に組み合わせを呼び出し、条件の一致を確認する対象とする。
【００９５】
図３２および図３３は、本実施の形態における動作モード決定手段での処理を説明するフロー図である。なおステップ５０３までは図２９のフローと同じである。
【００９６】
その後、前述した実施の形態５または６においてはステップ５０４（図２９）にて動作モード履歴記憶部１１２（図２８）から一度に全データが呼び出され、続くステップ５０５にて現在の並列処理アプリケーション項目、各リソースの使用可能量、および優先機能情報が一致するものがないか検索される。
【００９７】
これに対して本実施の形態では、各動作モード組み合わせ履歴情報は、これまでにその組み合わせが使用された回数を示す使用回数カウント値を持つ。つまり、検索された組み合わせが、演算手段１０４において実行されるものとして使用された回数を、動作モード履歴記憶部１１２は記憶する。またステップ７０４にて、全データではなく所定の数の履歴情報が取得される。このとき取得される情報は、一度に動作モード履歴記憶部１１２から取得する動作モード組み合わせ履歴情報の数をｘとしｋを初期値０の変数として、使用回数カウント値が大きいものから順番に数えたときのｋ＋１番目からｋ＋ｘ番目までのものである。ステップ７０５にて、ｋにｘが加算される。
【００９８】
そして、図２９の場合と同様にステップ５０５〜５０７が行われる。ただし、扱われる動作モード組み合わせ履歴情報の数はより小さくなる。
【００９９】
ステップ５０６にて一致するものがあると判定された場合、以後の処理は実施の形態５または６とほぼ同じであるが、本実施の形態においてはステップ７１８（図３３）にて、今回の決定に用いられた組み合わせが呼び出された回数のカウント値が１加算される。
【０１００】
一致するものがないと判定された場合には、ステップ７０９（図３３）にて、これまでで動作モード履歴記憶部１１２のデータをすべて検索し終えたかが確認される。具体的には、動作モード履歴記憶部１１２に記憶された全動作モード履歴情報の数をｎとしたときに、nとkとが比較される。ｋ≧ｎが満たされる場合、すなわちすべてを検索し終えたと判定された場合には、実施の形態５において説明したステップ５０８へ処理が進む。
【０１０１】
ｋ≧ｎが満たされない場合、接続子Ｈに示すようにステップ７０４へ戻り、再び動作モード履歴記憶部１１２から動作モード組み合わせ履歴情報が取得される。このとき取得されるデータは、それより以前にステップ７０５にてｋにｘが加算されているため、新たに取得されるものとなる。具体的には、前回のステップ７０４にて取得された組み合わせの使用カウント値の次に大きな使用カウント値を有する組み合わせから順番にｘ個分の動作モード組み合わせ履歴情報が取得される。すなわち、ループの２回目で取得される動作モード組み合わせ履歴情報は、使用回数カウント値が大きいものから数えてｘ＋１番目から２×ｘ番目までとなる。
【０１０２】
このようにして使用回数カウント値の大きいものから順にデータを取得する処理が、上記一致が確認されない限り、動作モード履歴記憶部１１２のすべてのデータについて終了するまで、すなわちステップ７０９でｋがｎ以上になるまで行われる。ｋ≧ｎが満たされた時点で、動作モード履歴記憶部１１２のデータはすべて確認されたことになる。そして、実施の形態５において説明したステップ５０８へ処理が進む。
【０１０３】
なお、上記各実施の形態におけるソフトウエア実行装置が有する各手段は、メモリに記憶されたプログラムをプロセッサが実行することにより、当該プロセッサの機能として実現されてもよい。上記プロセッサはユニプロセッサおよびマルチプロセッサのいずれであってもよい。上記メモリおよび上記プロセッサを有するコンピュータに上記プログラムをインストールするために、上記プログラムが記憶された記録媒体が用いられ得る。上記記録媒体は、たとえばＣＤ−ＲＯＭのように、非一時的なものであってもよい。あるいは上記各手段は、ハードウエアの回路として実現されてもよい。
【０１０４】
なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。
【符号の説明】
【０１０５】
１００  情報記憶部、１０２  切り替わり通知手段、１０３  動作モード決定手段、１０４  演算手段、１０５  使用リソース量情報記憶部、１０６  プログラム記憶部、１０７  定常状態確認手段、１０８  優先機能情報記憶部、１０９  動作必須アプリケーション情報記憶部、１１０  クオリティ点数情報記憶部、１１１  リソース不足情報記憶部、１１２  動作モード履歴記憶部、１００１〜１００３，１００５  ソフトウエア実行装置。
【図１】
2016126683.tif 000003
【図２】
2016126683.tif 000004
【図３】
2016126683.tif 000005
【図４】
2016126683.tif 000006
【図５】
2016126683.tif 000007
【図６】
2016126683.tif 000008
【図７】
2016126683.tif 000009
【図８】
2016126683.tif 000010
【図９】
2016126683.tif 000011
【図１０】
2016126683.tif 000012
【図１１】
2016126683.tif 000013
【図１２】
2016126683.tif 000014
【図１３】
2016126683.tif 000015
【図１４】
2016126683.tif 000016
【図１５】
2016126683.tif 000017
【図１６】
2016126683.tif 000018
【図１７】
2016126683.tif 000019
【図１８】
2016126683.tif 000020
【図１９】
2016126683.tif 000021
【図２０】
2016126683.tif 000022
【図２１】
2016126683.tif 000023
【図２２】
2016126683.tif 000024
【図２３】
2016126683.tif 000025
【図２４】
2016126683.tif 000026
【図２５】
2016126683.tif 000027
【図２６】
2016126683.tif 000028
【図２７】
2016126683.tif 000029
【図２８】
2016126683.tif 000030
【図２９】
2016126683.tif 000031
【図３０】
2016126683.tif 000032
【図３１】
2016126683.tif 000033
【図３２】
2016126683.tif 000034
【図３３】
2016126683.tif 000035
【図３４】
2016126683.tif 000036