(57)【要約】【課題】ユーザ価値の低いアプリケーションであっても、あるいはユーザ価値の低いアプリケーションを消費者とする生産者のアプリケーションであっても、リソースの落札ができるリソースの割り当て行なうリソース管理装置を提供する。【解決手段】リソース管理装置１０１は、複数のアプリケーションプログラムのそれぞれに対応して設けられ、リソースの割り当ての結果、自己のアプリケーションプログラムを実行するためのリソースが必要量割り当てられないときには、リソースの品質を示す品質パラメータを下げ、必要量が割り当てられるときには、品質パラメータを上げるようにして調整された品質パラメータの情報を用いて、リソースの入札値を生成する複数のリソース応札部１０２と、複数のリソース応札部１０２において生成された入札値を用いて、リソース割り当て処理を行なう入札管理部１０３とを有する。【選択図】図４
2008077350.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションプログラムのそれぞれに対応して設定され、かつ前記複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースの品質を示す、品質パラメータを記憶する記憶部と、
前記複数のアプリケーションプログラムのそれぞれに対応して設けられ、前記消費または供給するリソースの量に応じて前記消費または供給するリソースの入札値を生成し、かつ、前記複数のアプリケーションプログラムのそれぞれが自己のアプリケーションプログラムを実行するためのリソースが必要量割り当てられないときには、前記記憶部に記憶された前記品質パラメータを第１の所定量だけ下げ、前記実行するためのリソースが前記必要量割り当てられるときには、前記品質パラメータを第２の所定量だけ上げるようにして調整された品質パラメータの情報を用いて、生成された前記消費または供給するリソースの入札値を変更する複数のリソース応札部と、
前記品質パラメータが、前記第１の所定量だけ上げられ又は前記第２の所定量だけ下げられたときには前記記憶部に記憶された前記品質パラメータを前記調整された品質パラメータに更新するパラメータ更新部と、
前記複数のアプリケーションプログラムの前記消費又は供給するリソースについて、前記複数のリソース応札部において生成された前記入札値を用いて、前記所定の単位時間における、前記複数のアプリケーションプログラムのそれぞれに割り当てる前記リソースを決定するリソース割り当て処理を行なう入札管理部と、
を有することを特徴とするリソース管理装置。
【請求項２】
前記複数のアプリケーションプログラムは、レーダー装置からのレーダー信号を処理するプログラムと、前記レーダー信号に基づくレーダー情報を表示するプログラムと、ソナー装置からのソナー信号を処理するプログラムと、前記ソナー信号に基づくソナー情報を表示するプログラムとを含み、
前記リソースの前記品質パラメータは、前記レーダー信号及び前記ソナー信号に基づく画像データの解像度であることを特徴とする請求項１に記載のリソース管理装置。
【請求項３】
前記入札管理部は、前記リソースを供給するアプリケーションからの前記入札値が前記リソースを消費するアプリケーションからの前記入札値以下であって、かつ、前記リソースを消費するアプリケーションからの前記品質パラメータが前記リソースを供給するアプリケーションからの前記品質パラメータ以下であるときに、前記リソースの割り当てを行うことを特徴とする請求項１または２に記載のリソース管理装置。
【請求項４】
入札管理部と、複数のアプリケーションプログラムのそれぞれに対応して設けられた複数のリソース応札部と、前記複数のアプリケーションプログラムのそれぞれに対応して設定され、かつ前記複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースの品質を示す、品質パラメータを記憶する記憶部と、パラメータ更新部と、を具備したコンピュータシステムに、
前記複数のリソース応札部により、前記複数のアプリケーションプログラムのそれぞれに対応して設けられ、前記消費または供給するリソースの量に応じて前記消費または供給するリソースの入札値を生成し、かつ、前記複数のアプリケーションプログラムのそれぞれが自己のアプリケーションプログラムを実行するためのリソースが必要量割り当てられないときには、前記記憶部に記憶された前記品質パラメータを第１の所定量だけ下げ、前記実行するためのリソースが前記必要量割り当てられるときには、前記品質パラメータを第２の所定量だけ上げるようにして調整された品質パラメータの情報を用いて、生成された前記消費または供給するリソースの入札値を変更する手順と、
前記パラメータ更新部により、前記品質パラメータが、前記第１の所定量だけ上げられ又は前記第２の所定量だけ下げられたときには前記記憶部に記憶された前記品質パラメータを前記調整された品質パラメータに更新する手順と、
前記入札管理部により、前記複数のアプリケーションプログラムの前記消費又は供給するリソースについて、前記複数のリソース応札部において生成された前記入札値を用いて、前記所定の単位時間における、前記複数のアプリケーションプログラムのそれぞれに割り当てる前記リソースを決定するリソース割り当て処理を行なう手順と、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース管理装置及びプログラムに関し、特に、複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースを管理するためのリソース管理装置及びプログラムに関する。
【背景技術】
【０００２】
従来より、センサを備えた、いわゆるリアルタイムシステムがある。例えば、船舶、航空機、自動車などの輸送機械の分野では、周囲の状況を把握し、その把握した状況の情報を、画面表示などによってユーザに呈示するセンサ情報システムが用いられている。船舶の場合のセンサ情報システムは、レーダー、ソナー、赤外線センサ、カメラなどの複数のセンサを備え、各局面に応じてそれらの一つあるいは複数のセンサの信号を解析して周囲の状況を認識し、その認識結果を画面などに表示する。周囲状況の情報は、船舶の安全な航行などに役立つものである。
【０００３】
輸送機械の分野におけるこれらのシステムでは、認識された周囲状況の情報をユーザに知らせるために、所定の時間内に画面表示などが更新されなければならない。それは、ユーザが周囲の状況を素早く把握できず、衝突などの事故につながる危険があるからである。そのため、それらのシステムは、リアルタイムシステムでなければならず、センサ信号に基づく信号処理は所定の時間制約を満たすリアルタイム処理で行なわれることが要求される。
【０００４】
従来、複数のセンサ信号の信号処理を行なうこのようなリアルタイムシステムでは、それぞれの信号は独立したサブシステムにおいて処理されるのが一般的であった。それは、それぞれの信号の信号処理に必要な中央処理装置（CPU）などの計算機リソースをサブシステムごとに個別に用意し、サブシステムごとに一つのリアルタイムのオペレーティングシステム（OS）を動かすなどの方法により、サブシステム単位でリソースの割当を行なうことによって、所定の時間制約を満たすセンサ情報システムの設計や開発が容易になるからである。
【０００５】
しかし、このような信号ごとに独立したサブシステムを個別に作成する方式では、ある信号を担当する１つのサブシステムにおいて過負荷、あるいはサブシステムの１つの要素に故障が生じると、たとえ他のサブシステムの計算機リソースに余裕があっても、そのサブシステムが、自己の担当する信号の処理の所定の時間制約を守れなかったり、処理がまったくできなくなったりするという問題点がある。
【０００６】
従って、これまでは、このような過負荷あるいは故障にサブシステム単体で対応できるようにするために、サブシステム毎に、機能、処理能力等において所定の余裕を持った構成を取る必要があった。しかし、このような余裕を持った構成にするためには、多大なハードウエア設備が必要となるため、設備の費用、容積、消費電力がそれぞれ増大し、センサ情報システムの商業的及び技術的フィージビリティーが低下するという事態が生じている。
【０００７】
そのため、航空機の分野では、一つの計算機システムに複数の信号の信号処理を統合することによって、比較的少ないハードウエア設備でセンサ情報システムを構築したいという要求がある。一般に、このようなシステムは、一つ以上のプロセッサとメモリと入出力機器とを持つノードを、ネットワークなどによって複数個結合した分散システムで実現される。
【０００８】
しかし、複数の信号の処理を一つのシステムに単純に統合すると、複数の信号の処理を行なう場合に、ある局面において、より重要な信号とあまり重要でない信号とがあった場合、あまり重要でない信号の処理の負荷が上がったために、より重要な信号の処理の時間制約にまで影響が出てしまうという虞れがあった。
【０００９】
理論的には、システム全体で一つのリアルタイムOSを動かし、全体でリアルタイムスケジューリングを行なえばこのような問題を解決することはできる。しかし、現実的には多数のプロセッサを含むシステムを単一のOSで管理すると、スケジューリングが非常に複雑となって、そのスケジューリングの処理に時間が掛かって、所定の時間制約を満たす十分な性能を得ることは困難な場合がある。さらに大きな問題として、ノード間が厳密なリアルタイム性が保証されていないネットワークにより接続されている場合、ノードを跨ったリアルタイムスケジューリングを行なうことはそもそもできないという問題がある。
【００１０】
ところで、従来より、一般に、分散システムにおけるリソース割当を分散して行なう方式として、入札によるリソース割り当てという方式が研究されている (例えば、非特許文献１参照)。
【００１１】
その入札によるリソース割り当て方式によれば、CPU時間などのリソースの配分を、単位時間毎あるいはタスク毎に入札形式で行なうものであり、各アプリケーションプログラム（以下、単にアプリケーションともいうことがある）が値段をつけた上でリソースの割り当てを要求し、もっとも高い値段をつけたアプリケーションがそのリソースの割り当てを受けて動作するように決定される。この入札の際に扱われる通貨は、ある局面であるアプリケーションがユーザにとってどれだけ重要なのかを定量化する指標であり、現実の通貨にはリンクさせる必要のない仮想的な通貨である。システム内の各モジュールが、自己が受け取る通貨から支払う通貨を差し引いた利益を最大化するように振る舞うことによって、システム全体の効率が改善されるというのが、この入札によるリソース割り当て方式の特徴である。
【００１２】
この入札方式を用いれば、局面ごとのセンサの信号の重要性に対応したリソースの割り当てを、その重要なセンサの信号の処理を行なうアプリケーションに高い入札価格をつけることを許すことによって実現することができる。また、ノード毎にそのノードのリソースの入札処理を行なうことによって、入札処理を分散して行なえるため、リソース割り当ての分散処理が行ない易いというメリットがある。
【００１３】
単純なモデルのリソース割り当てでは、CPU時間などの物理リソースのみがリソースで、OSやミドルウェアのプログラムがリソースの供給者となり、アプリケーションプログラムが消費者となる。しかし実際のシステムでは、より複雑なリソース割り当てモデルに基づいて、より高度な入札を行なう場合がある。特に、分散システムにおけるリソース割り当てを入札方式で行なう場合、サプライチェーンモデルと呼ばれる、より高度なリソース割り当てモデルを用いる場合がある。
【００１４】
このモデルは、製造業・流通業におけるサプライチューン(供給連鎖)を模したモデルである。このモデルでは、供給者・消費者に加えて「生産者」という概念を導入する。生産者は他者からリソースを買って、他者に売るリソースを生成する存在であり、物理リソースのほかに生産者が生成したデータなどもリソースとして扱われる。
【００１５】
生産者の概念を導入することによって複数ノードへの処理の分散や、他のアプリケーションが使うデータの前処理を行なうアプリケーションを入札モデルで扱うことができる。なお、供給者、消費者及び生産者とは、それぞれシステム内のソフトウエアで実現されるモジュールプログラムを指すものであり、自然人、法人などを指すものではない。
【００１６】
一般にサプライチェーンモデルを用いた入札方式では、上記の単純なモデルと比べて入札価格の決め方が複雑になる（例えば、非特許文献２参照）。特に、生産者の場合、売るリソースの値段を決める際に、そのリソースを生成するために必要なリソースをいくらで買えるかを考慮し、売値が買値を下回る場合には入札を取り止めるといった動作を行なう必要がある。複雑な計算式を用いて一度に入札価格を決める方式もあるが、計算量が大きいため、仮の値段による複数ラウンドの入札を値段が収束するまで繰り返すのが一般的である。
【００１７】
このような複数ラウンド入札方式における生産者の入札方針(入札価格の決め方)の一例としては、はじめは売るリソースと買うリソースとも、適当な初期値で入札を行ない、売るリソースと買うリソースが落札できたかどうかによって、売値と買値を微少量だけ変化させるが、採算が取れない場合（すなわち売値が買値の合計を下回る場合）は、入札を断念する、といった入札方針が可能である。このようなラウンドを繰り返すことによって、リソースの売値と買値が適切な水準まで上がるか、あるいは入札を断念するかのどちらかの結果となり、入札価格が決定する。
【００１８】
以上はサプライチェーン入札の場合の入札方式であるが、サプライチェーン入札に限らず、たとえば複数のリソースの割り当てを同時あるいは並行して行なう複数財入札など、一般に複雑な入札を行なう場合は、複数ラウンド入札を行なう場合が多い。
【００１９】
なお、売値と買値の差である利益のデータは、累積しなくてもよいが、累積して、その累積データを、システム管理者あるいは各アプリケーション自身による、各アプリケーションの動作改善の参考データとして利用してもよい。
【非特許文献１】アンドリュー・バイド、マシアス・セイル、クラウディオ・バルトリーニ著「ユーティリティデータセンタのための市場ベースリソース配分」、HPラボ・テクニカル・レポートHPL-2003-188、２００３（Andrew Byde, Mathias Salle, and Claudio Bartolini,  Market-Based Resource Allocation for Utility Data Centers, HP Labs Technical Report HPL-2003-188, 2003.）
【非特許文献２】ウイリアム・イー・ウォルシュ、マイケル・ピー・ウエルマン著「階層依存性を有するタスク・アロケーション・経済における効率と平衡、１９９９年人工知能に関する第１６回国際共同コンファレンス議事録（William E. Walsh and Michael P. Wellman, Efficiency and Equilibrium in Task Allocation Economies with Hierarchical Dependencies, in Proceedings of the Sixteenth International Joint Conference on Artificial Intelligence, 1999.）
【発明の開示】
【発明が解決しようとする課題】
【００２０】
しかし、システムにおいて各アプリケーションが処理すべき対象データの量が固定値であれば、各アプリケーションが利用するリソースの量も、固定値に定まる。例えば、あるアプリケーションが処理するデータ量が一定、すなわち固定値である場合、そのアプリケーションがその固定値のデータを処理するのに必要なCPU利用率も一定、すなわち固定値となる。
【００２１】
このようなシステムにおいて、複数のアプリケーションに対して入札方式によるリソース割り当てを行う場合、各アプリケーションに対してユーザが設定した価値、すなわちユーザ価値を、各アプリケーションの重要度に応じて設定することによって、システムのユーザは、自分が重要と認めた、すなわちユーザ価値の高い、アプリケーションの実行を保証することができる。このユーザ価値は、例えば、ユーザの設定する各アプリケーションの応札価格の上限値（上限価格）によって定めることができる。すなわち、上限価格の高いアプリケーションは、応札時に、他のアプリケーションよりも高い価格を提示することができるので、最終的にリソースを落札できる可能性が高くなる。よって、上限価格が高く設定されたアプリケーションは、ユーザ価値の高いアプリケーションということができる。
【００２２】
逆に、消費者であるアプリケーション（リソースを買うだけのアプリケーション）の中で、ユーザが重要と認めていないアプリケーションは、応札価格の上限値が相対的に低い（ユーザ価値が低い）ため、ある状況（例えばリソースの価格上昇時）においては、リソースを落札できず、動作できない場合が生じ得る。
【００２３】
また、生産者であるアプリケーション（リソースを買って、リソースを売るアプリケーション）の場合、消費するリソースの価格が上昇したときには、提供するリソース（提供リソース）の価格を上昇させる、という価格転嫁を行うことができる。しかし、その生産者の提供するリソースを消費する消費者の重要度が低い（ユーザ価値が低い）場合、消費するリソースの価格の上昇に応じて、提供リソースの価格の上昇ができず、結局、生産者のアプリケーションも、リソースの落札ができず、動作できない場合が生じ得る。
【００２４】
本発明は、以上の問題に鑑みてなされたもので、ユーザ価値の低いアプリケーションであっても、あるいはユーザ価値の低いアプリケーションを消費者とする生産者のアプリケーションであっても、リソースの落札ができるリソースの割り当て行なうリソース管理装置を提供することを目的とする。
【課題を解決するための手段】
【００２５】
本発明のリソース管理装置は、複数のアプリケーションプログラムのそれぞれに対応して設定され、かつ前記複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースの品質を示す、品質パラメータを記憶する記憶部と、前記複数のアプリケーションプログラムのそれぞれに対応して設けられ、前記消費または供給するリソースの量に応じて前記消費または供給するリソースの入札値を生成し、かつ、前記複数のアプリケーションプログラムのそれぞれが自己のアプリケーションプログラムを実行するためのリソースが必要量割り当てられないときには、前記記憶部に記憶された前記品質パラメータを第１の所定量だけ下げ、前記実行するためのリソースが前記必要量割り当てられるときには、前記品質パラメータを第２の所定量だけ上げるようにして調整された品質パラメータの情報を用いて、生成された前記消費または供給するリソースの入札値を変更する複数のリソース応札部と、前記品質パラメータが、前記第１の所定量だけ上げられ又は前記第２の所定量だけ下げられたときには前記記憶部に記憶された前記品質パラメータを前記調整された品質パラメータに更新するパラメータ更新部と、前記複数のアプリケーションプログラムの前記消費又は供給するリソースについて、前記複数のリソース応札部において生成された前記入札値を用いて、前記所定の単位時間における、前記複数のアプリケーションプログラムのそれぞれに割り当てる前記リソースを決定するリソース割り当て処理を行なう入札管理部と、を有する。
【発明の効果】
【００２６】
本発明のリソース管理装置によれば、ユーザ価値の低いアプリケーションであっても、あるいはユーザ価値の低いアプリケーションを消費者とする生産者のアプリケーションであっても、リソースの落札ができるリソースの割り当て行なうリソース管理装置を実現することができる。
【発明を実施するための最良の形態】
【００２７】
以下、図面を参照して本発明の実施の形態を説明する。  
１．システムのハードウエア構成  
まず図１に基づき、本実施の形態に係わるシステムのハードウエア構成を説明する。図１は、本実施の形態に係わるセンサ情報処理のためのコンピュータシステム（以下、センサ情報システムという）の構成を示す構成図である。本実施の形態に関わるセンサ情報システムは、船舶、航空機等に用いられる。センサ情報システムは、ここでは、レーダー装置とソナー装置からのセンサ信号に基づいて、周囲の状況をセンサ情報として乗組員等に知らせるシステムである。センサ情報システムは、特にかつ危険な障害物等を検知した場合に、すばやく、すなわちその検知をしてから所定の時間内に乗組員等にそのセンサ情報を画面表示等により告知する、いわゆるリアルタイムシステムである。なお、リアルタイムシステムとは、所定の時間内に所定の処理が実行される、例えば、センサ信号を検知してから所定の時間としての１秒以内に、表示装置の画面上に所定のセンサ情報を表示する処理が実行されるようなシステムをいう。
【００２８】
センサ情報システム１は、複数のノード、ここでは２つのノード２、３とがネットワーク４を介して接続されて構成されている。ノード２には、レーダー装置５と端末装置６とが接続されている。ノード２は、所定の信号処理を行い、信号処理の結果を端末装置６の表示装置６ａの画面上に表示する処理を行うコンピュータ装置である。後述するように、ノード２は、レーダー装置５とソナー装置７のそれぞれの信号に基づいて所定の信号処理を行う信号処理アプリケーションプログラム（以下、アプリケーションプログラムを単にアプリケーションということもある）と、レーダー装置５の信号に関する信号処理の結果を表示装置６ａに表示するために情報表示アプリケーションプログラムとを含む。
【００２９】
ノード３には、ソナー装置７と端末装置８とが接続されている。ノード３は、所定の信号処理を行い、信号処理の結果を端末装置８の表示装置８ａの画面上に表示する処理を行うコンピュータ装置である。後述するように、ノード３は、ソナー装置７とレーダー装置５のそれぞれの信号に基づいて所定の信号処理を行う信号処理アプリケーションプログラムと、ソナー装置７の信号に関する信号処理の結果を表示装置８ａに表示するために情報表示アプリケーションプログラムとを含む。
【００３０】
また、後述するように、レーダー装置５のセンサ信号は、ネットワーク４を介して、ノード３へ送信され、ソナー装置７のセンサ信号も、ネットワーク４を介して、ノード２へ送信されるように構成されている。
【００３１】
ノード２は、端末装置６の表示装置６ａの画面上に、レーダー情報を表示し、ユーザに対してレーダー装置５のセンサ信号に関する情報を、いわゆるリアルタイムで提示することができる。同様に、ノード３は、端末装置８の表示装置８ａの画面上に、ソナー情報を表示し、ユーザに対してソナー装置７のセンサ信号に関する情報を、いわゆるリアルタイムで提示することができる。
【００３２】
従って、本実施の形態では、レーダー装置５とソナー装置７という二つのセンサ装置からのセンサ情報の情報処理は、二つのノード２，３において行なわれ、処理結果であるレーダー情報とソナー情報が、それぞれの端末装置６，８の表示装置６ａ，８ａの画面上にリアルタイムで表示される。例えば、船舶の場合であれば、障害物がレーダー装置５で検知されるとその障害物の位置情報等がセンサ情報として画面上にリアルタイムで表示される。後述するように、ノード２，３においては、QoS(Quality of Service)に応じて、センサ情報の情報処理が行われる。レーダー装置５とソナー装置７という二つのセンサ装置からのセンサ情報の情報処理は、いずれも、QoS適応という手法が適用できる処理である。QoSについては、後で詳述する。
【００３３】
ノード２は、２つの中央処理装置（以下、CPUと略す）２１，２２、メモリ２３、ネットワークインターフェース（以下、ネットワークI/Fと略す）２４、レーダー装置インターフェース（以下、レーダー装置I/Fと略す）２５、及び端末装置インターフェース（以下、端末装置I/Fと略す）２６を含んで、お互いにバス２７を介して接続されて構成されている。
【００３４】
同様に、ノード３は、２つのCPU３１，３２、メモリ３３、ネットワークI/F３４、ソナー装置インターフェース（以下、ソナー装置I/Fと略す）３５、及び端末装置I/F３６を含んで、お互いにバス３７を介して接続されて構成されている。
【００３５】
なお、バス２７，３７は、各ノードの基板間あるいは基板上の配線でもよいし、チップ内部の配線であってもよい。  
ネットワークI/F２４と３４は、それぞれノード２と３とをネットワーク４と接続するためのインターフェースである。端末装置I/F２６と３６は、それぞれノード２と３とをそれぞれの端末装置６と８と接続するためのインターフェースである。レーダー装置I/F２５を介して、ノード２とレーダー装置５とは接続されている。ソナー装置I/F３５を介して、ノード３とソナー装置７とは接続されている。
【００３６】
ネットワーク４は、リアルタイム性が保証されるネットワークでも、イーサネット（Ethernet：登録商標）などのリアルタイム性が保証されないネットワークでもよい。
【００３７】
なお、図１では、レーダー装置５とソナー装置７は、それぞれインターフェースを介して、ノード２と３に接続されているが、ネットワークインターフェースを内蔵して、ネットワーク４に直接接続されるようにしてもよい。その場合、レーダー装置５とソナー装置７からの信号は、ネットワーク４を介して、それぞれノード２と３に伝達される。
【００３８】
さらになお、上述した説明では、端末装置６と８がそれぞれノード２と３に接続されているが、図１の一点鎖線で示すように、端末装置６と８に代えて、あるいは端末装置６と８に加えて、さらにネットワーク４に接続された別の端末装置９を設けてもよい。端末装置６と８に代えて端末装置９を設けた場合は、端末装置９の表示装置９ａ上に、レーダー情報とソナー情報を表示するようにし、あるいは端末装置６と８に加えて端末装置９を設けた場合は、端末装置９の表示装置９ａ上にのみ、あるいは端末装置９の表示装置９ａ上にも併せて、レーダー情報とソナー情報を表示するようにしてもよい。
【００３９】
また、センサ情報システム１には、表示装置、キーボードなどを備えた端末装置が一つ以上存在し、ノードのうち一つに接続されている。
【００４０】
２．システムのソフトウエア構成  
次に、図２に基づき、ノード２と３のソフトウエア構成を説明する。図２は、ノード２と３におけるソフトウエア構成のリソース管理の部分を説明するためのブロック構成図である。
【００４１】
ノード２と３は、レーダー信号とソナー信号の信号処理と、レーダー情報表示あるいはソナー情報表示の表示処理とを実行するアプリケーション実行装置であるが、CPU時間等のリソースを管理するリソース管理装置でもある。すなわち、ノード２と３は、レーダー信号とソナー信号に基づく信号処理を行い、その処理結果をレーダー情報あるいはソナー情報として、端末装置６と８の表示装置６ａと８ａにリアルタイムで表示するセンサ情報処理を行うが、そのようなリアルタイムのセンサ情報の処理のためにリソース管理も行っている。その意味で、ノード２と３は、リソース管理装置を構成し、リソース管理装置は、アプリケーションプログラムを各ノード上で実行するために動作するソフトウエアプログラムにより、主として実現されるコンピュータ装置である。
【００４２】
ノード２において、１つのOS４１は、ハードウエアである２つのCPU２１，２２上で動作する。OS４１は、マルチプロセッサ対応のOSであり、例えば、ウインドウズ（登録商標）、リナックス等のOSである。OS４１の上には、物理リソースマネージャ４２が設けられており、リソースとしてのCPU時間を管理する。
【００４３】
物理リソースマネージャ４２を介して、レーダー信号処理部であるレーダー信号処理アプリケーション４３、ソナー信号処理部であるソナー信号処理アプリケーション４４及びレーダー情報表示部であるレーダー情報表示アプリケーション４５の、３つのアプリケーションプログラムが、OS４１上で動作する。
【００４４】
ノード３においても、１つのOS５１は、ハードウエアである２つのCPU３１，３２上で動作する。OS５１も、マルチプロセッサ対応のOSである。OS５１の上には、物理リソースマネージャ５２が設けられており、リソースとしてのCPU時間を管理する。
【００４５】
物理リソースマネージャ５２を介して、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４及びレーダー情報表示アプリケーション５５の、３つのアプリケーションプログラムが、OS５１上で動作する。
【００４６】
物理リソースマネージャ４２、５２は、各アプリケーションプログラムを実行する場合に、後述するように、各アプリケーションからの入札に対して、所定の処理を行い、各アプリケーションが落札したCPU時間だけ、各アプリケーションを実行させるように、CPU時間を管理する。
【００４７】
リソース管理装置が動作する各ノードでは、一つのOS４１，５１によりソフトウエア及びハードウエアが管理される。本実施の形態では、各ノードには２つのCPUがあるが、１つのノードに複数のCPUがある場合でも、マルチプロセッサ対応のOSが一つ動作し、各ノード全体のリソースをそのOSが管理する。物理リソースの管理は、各OSの上で動作するミドルウェアとして実現される物理リソースマネージャにより行われる。なお、物理リソースマネージャは、OS内部の機能として実現されていてもよい。
【００４８】
リソース管理装置は、複数のリソース応札部と複数の入札管理部とQoS制御部とを含んで構成される。具体的には、ノード２において、物理リソースマネージャ４２は、リソース応札部４２ａと、入札管理部４２ｂとを有する。レーダー信号処理アプリケーション４３は、リソース応札部４３ａとQoS制御部４３ｂとを含む。ソナー信号処理アプリケーション４４は、リソース応札部４４ａとQoS制御部４４ｂとを含む。レーダー情報表示アプリケーション４５は、リソース応札部４５ａと、入札管理部４５ｂと、QoS制御部４５ｃとを有する。同様に、ノード３において、物理リソースマネージャ５２は、リソース応札部５２ａと、入札管理部５２ｂとを有する。レーダー信号処理アプリケーション５３は、リソース応札部５３ａとQoS制御部３３ｂを含む。ソナー信号処理アプリケーション５４は、リソース応札部５４ａとQoS制御部５４ｂを含む。ソナー情報表示アプリケーション５５は、リソース応札部５５ａと、入札管理部５５ｂと、QoS制御部５５ｃとを有する。  
すなわち、各リソース応札部４２ａ，４３ａ、５２ａ，５３ａ等は、リソースの供給または消費を行なうモジュールである処理部（ここでは、物理リソースマネージャ４２，５２および各アプリケーション４３，４４等）の内部に設けられている。
【００４９】
なお、一部のアプリケーションのみにリソース応札部を設けるようにしてもよい。例えば、リソースをあまり消費しないアプリケーションには、入札への参加を省略すべくリソース応札部を設けず、逆に、リソースを大量に消費するアプリケーションのみにリソース応札部を設けるようにする、といった構成でもよい。この場合、入札へ参加しないアプリケーションが消費するリソースは、ある程度余裕を持つようにするなどの方法で、別途固定的に割り当てておく必要がある。
【００５０】
一方、入札管理部は、ノード毎に、全体で一つ設けてもよいし、複数設けてもよい。また、入札管理部は、独立したミドルウェアやOS内部の機能として実現してもよいし、あるいは、いずれかの処理部の内部で実現してもよい。一般に、供給者が一つで消費者が複数の場合は供給者の内部で実現し、供給者が複数で消費者が一つの場合は消費者の内部で実現すると入札の際の処理や通信が簡単になる。そこで、本実施の形態では、物理リソースマネージャ（供給者）は、複数のアプリケーション（消費者）にCPU利用率を供給するだけであるので、物理リソースマネージャ４２，５２の内部に入札管理部４２ｂ、５２ｂを設けている。そして、センサ情報表示アプリケーション（消費者）は、複数のアプリケーション（供給者、生産者）から、CPU利用率とセンサ情報を受けるだけであるので、センサ情報表示アプリケーション内部に入札管理部４５b、５５bが設けられている。例えば、ノード２では、物理リソースマネージャ４２内部に入札管理部４２ｂが設けられ、そしてレーダー情報表示アプリケーション４５内部に入札管理部４５ｂが設けられている。
【００５１】
そして、QoS制御部４３ｂ、５３ｂ、４４ｂ、５４ｂ、４５ｃ、５５ｃが、それぞれレーダー信号処理アプリケーション４３，５３、ソナー信号処理アプリケーション４４，５４、レーダー情報表示アプリケーション４５及びソナー情報表示アプリケーション５５に設けられて、各アプリケーションでは、QoSに応じて、センサ情報の情報処理が行われる。QoS制御部４３ｂ、５３ｂ、４４ｂ、５４ｂ、４５ｃ、５５ｃの動作については、後述する。
【００５２】
３．リソースの供給と消費  
３．１  リソース  
ここで、リソースについて説明する。本実施の形態は、物理リソースであるCPU利用率に加えて、アプリケーションプログラムが生成したデータもリソースとして扱う、サプライチェーンモデルに基づく例である。
【００５３】
データもリソースとして扱うのは、次の理由による。すなわち、各センサ信号の信号処理部と各センサ情報の情報表示部とが分離されているため、センサ情報をリソースとして扱わずにCPU利用率のみをリソースとして扱ってしまうと、センサ情報の供給と消費関係を無視したリソースの割り当てが生じる虞がある。例えば、ソナー信号処理部４４，５４にCPU利用率が割り当てられて実行されるが、ソナー情報表示部５５にはCPU利用率が割り当てられずに実行ができないという状況があり得る。その場合、利用されないセンサ情報を生成するためにCPUが浪費される、といった状態が生じてしまう。このような状態が生じないようにしながら、各信号処理部と各情報表示部とを分離できるようにするために、CPU利用率に加えてデータもリソースとして扱われている。
【００５４】
なお、CPU利用率は、後述する単位処理時間当たりにおける、そのアプリケーションが使用する割合（％）である。例えば、単位処理時間が、１秒で、CPU利用率が３０％であれば、そのアプリケーションは、３００ｍｓだけCPUを使用できることを意味する。本実施の形態では、CPU利用率（％）を用いるが、CPU使用時間（ｍｓ等）を用いてもよい。また、データは、本実施の形態では、レーダー情報とソナー情報である。
【００５５】
図３は、本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。  
図３に示すように、本実施の形態のサプライチェーンモデルにおいて、物理リソースマネージャ４２，５２は、供給者に対応し、レーダー信号処理アプリケーション４３，５３とソナー信号処理アプリケーション４４，５４は、生産者に対応し、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５は消費者に対応する。
【００５６】
リソースの供給のみを行う供給者である物理リソースマネージャ４２，５２は、物理リソースであるCPU利用率の管理を行なうミドルウェアである。なお、物理リソースマネージャ４２，５２は、OSの一部として、OSの中に組み込まれたものであってもよい。
【００５７】
CPU利用率は、供給者である物理リソースマネージャ４２，５２から、各アプリケーションに供給される。図３の場合、CPU利用率は、物理リソースマネージャ４２から、レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４及びレーダー情報表示アプリケーション４５に供給される。物理リソースマネージャ５２から、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４及びレーダー情報表示アプリケーション５５に供給される。
【００５８】
生産者であるレーダー信号処理アプリケーション４３，５３およびソナー信号処理アプリケーション４４，５４は、それぞれ、センサ装置のセンサ信号から、CPU利用率を消費して所定のセンサ情報を生成して、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５に供給する。すなわち、アプリケーションのうちセンサ信号処理アプリケーションは、センサ情報を供給する生産者である。
【００５９】
消費者であるレーダー情報表示アプリケーション４５及びソナー情報表示アプリケーション５５は、CPU利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない。すなわち、アプリケーションのうち情報表示アプリケーションは、CPU利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない消費者である。
【００６０】
アプリケーションである各処理部は、自己が消費する全てのリソースが落札できた場合のみ動作する。なお、各信号処理部は、ノード２，３間の負荷分散のため両方のノードに存在するが、いずれか一方のみが実行されれば、センサ情報は生成される。例えば、レーダー情報表示アプリケーション４５は、CPU利用率が割り当てられ、かつレーダー信号処理部４３と５３のいずれか一方からレーダー情報の供給を受ければ、実行される。
【００６１】
３．２  QoS
ここで、本実施の形態で用いられるQoSについて説明する。  
本実施の形態では、データの品質レベルを示す指標の１つとして、データの解像度、あるいはデータの密度（以下、解像度という）を用いている。データの解像度が高ければ、データの品質レベルは高いということになる。そこで、アプリケーションが提供するデータの品質を表すパラメータを、QoSとして扱い、品質パラメータのQoSに応じて、アプリケーションが実行されるように制御される。
【００６２】
一般に、QoSは、サービスの品質の略で、サービス品質の意味であり、特に、ネットワーク技術の分野では、ある特定の通信のための帯域を予約し、一定の通信速度を保証する技術として理解されている。例えば、音声や動画などの通信では、回線が混雑した場合にビットレートを下げて、帯域を抑えることが広く行なわれており、ビットレートは、QoSの一種ということができる。
【００６３】
QoS適応とは、一般に、ある状況において、システム要素が利用できるリソースの量に応じて、サービスの品質(QoS)を上げ下げすることによって、リソースの量の増減に対応してシステム要素を動作させる手法である。従って、QoSとは、高い品質の方がユーザの利便性が向上するが、低い品質でもある程度の利便性は得られるようなパラメータを言う。
【００６４】
そこで、本実施の形態では、QoSとして、データの解像度の値を用いて、許容できる画像の品質の範囲内で、データの解像度を上げ下げすることによって、アプリケーションは、CPU利用率の増減に対応して動作する。なお、データの解像度は、具体的には空間解像度(縦横のピクセル数)及び時間解像度(単位時間あたりのフレーム数)である。
【００６５】
データの解像度が異なれば、CPU利用率も異なる。一般に、信号処理の計算時間はデータの解像度の線形値以上で増大するので、たとえばデータの解像度を半分にすれば計算時間を数分の１に減らすことができる。
【００６６】
本実施の形態では、データの解像度をQoSとして、アプリケーションの中でもデータを処理する信号処理アプリケーションと情報表示アプリケーションへのQoS適用を行って、CPU利用率を減らすことによって、画像データの品質を許容限度内に維持しながら、ユーザ価値の低いアプリケーション等であっても、リソースの落札ができるように、リソースの割り当てが行われる。
【００６７】
言い換えると、アプリケーションにおいて、利用できるリソース（CPU利用率）の量に応じて、QoSの増減を行うようにすることによって、アプリケーションは、利用できるCPU利用率の増減に適応することができる。
【００６８】
なお、アプリケーションが消費者である場合は、QoS適応のための処理は、そのアプリケーション内での閉じた処理となるが、アプリケーションが生産者である場合は、供給するリソース、すなわちデータにQoS適応のための処理結果が反映される。
【００６９】
３．３  リソースの供給方法  
次に、リソースの供給について説明する。  
リソースの供給のうち、データであるセンサ情報の供給は、信号処理アプリケーションが、実際にセンサ情報表示アプリケーションに、センサ情報を供給することによって行なわれる。例えば、レーダー信号処理アプリケーション４３が、信号処理の結果得られたレーダー情報を、レーダー情報表示アプリケーション４５に供給することが、センサ情報の供給となる。
【００７０】
一方、CPU利用率の供給は概念上のものであって、明示的な受渡しはなく、アプリケーションプログラム作成の際に、CPU利用率を落札できた場合のみCPUを利用して実行されるようにそのプログラムを作成することによって実現される。  
なお、アプリケーションが第三者によって作成された場合など、アプリケーションの実際の挙動が信用できない場合には、アプリケーションが実際に落札した分のCPU利用率しか使用していないかを、物理リソースマネージャがOSの状態を監視するなどの方法でチェックするようにしてもよい。その場合、落札された以上のCPU利用率を使用していた場合は、そのアプリケーションを割り込み処理により強制終了したりすることによって、CPU利用率の割り当てを強制的に守らせるようにすることも可能である。  
以上のリソースの割り当てが、リソース管理装置の入札によって行なわれる。
【００７１】
３．４  リソース割り当ての決定方法
（ａ）CPU利用率  
まず、物理リソースであるCPU利用率の消費量および供給量の決定方法について述べる。各アプリケーションは、処理単位時間ごとにそのアプリケーションが使用するCPU利用率、すなわち消費量を計算し、明示あるいは決定する。その決定は、アプリケーション作成者がアプリケーションのソースコード中に数値または計算式を明示的に記述することで行なってもよいし、コンパイラがコンパイル時に判定することで行なってもよい。さらに、各アプリケーションが、自己が実行された時に物理リソースマネージャやOSの状態を監視するなどの方法で実測し、測定履歴から今後の物理リソース使用量を推定するといった方法で行なってもよい。
【００７２】
なお、CPU利用率の消費量はQoSによって異なるので、CPU利用率の消費量との対応で指定あるいは推定する必要がある。例えば、後述するような、QoSを引数とする関数の形式で指定してもよいし、あるいは、QoSとCPU利用率の消費量の対の値をいくつか指定しておき、補間によってそれらの間のQoSについてのCPU利用率の消費量を算出するようにしてもよい。
【００７３】
物理リソースマネージャは、アプリケーションに供給できるリソースの供給量を計算する。本実施の形態では、CPU台数分の全利用時間に対する割合を示すパーセンテージからOSやミドルウェアの動作や安全のためのマージンを差し引いた値がアプリケーションへの供給量である。本実施の形態では、各ノードは、CPU 2台分にあたる２００%からマージン２０%を差し引いた１８０%を供給量とする。
【００７４】
（ｂ）センサ情報  
次に、センサ情報の消費量および供給量の決定方法について述べる。  
物理リソース以外のリソースであるセンサ情報は、アプリケーション作成者がアプリケーションのソースコード中にアプリケーションのロジックの一部として数値または計算式を明示的に記述することによって消費量および供給量が指定される。
【００７５】
例えば、ソナー信号処理アプリケーションは、センサ装置であるソナー装置７から所定のサンプリング周期でセンサ信号を受けるので、そのセンサ信号の量（ビットレート等）は、一定であるが、QoSに応じてセンサ情報の消費量は変化する。すなわち、センサ信号の量は一定であっても、QoSに応じてソナー信号処理アプリケーションの処理するデータ量は変化する。また、ソナー信号処理アプリケーションは、所定の信号処理を行って、センサ情報である画像データをソナー情報表示アプリケーションに供給するので、そのセンサ情報の量(ビットレート等)が供給量となる。
【００７６】
従って、入札に基づいて消費量と供給量は変化するが、各ノードでは、各ノードにおいて処理されるデータ量に応じてCPU利用率も変化する。例えば、ノード２では、QoSに応じて処理されるセンサのデータ量は変化するので、その変化したセンサのデータ量に応じてCPU利用率も変化する。同様にノード３でも、QoSに応じて処理されるセンサのデータ量は変化するので、その変化したセンサのデータ量に応じてCPU利用率も変化する。例えばレーダー装置５から出力されるセンサ信号の全量は、ノード２とノード３に、それぞれ分担され、各ノードでは、その分担された量のセンサ信号を、QoSに応じて処理するためのCPU利用率が必要となる。
【００７７】
上述したように、QoS適応が可能な信号処理アプリケーションと情報表示アプリケーションにはQoS制御手段としてのQoS制御部１０８が設けられている。そのQoS制御部１０８は、リソース応札部１０２からQoSを受信すると、実際に信号処理を行なう信号処理アプリケーション及び情報表示アプリケーション（AP）にQoS（データの解像度）を通知して、信号処理アプリケーション及び情報表示アプリケーションは、落札できたリソース（CPU利用率）に見合う以上のリソースを消費しないように、QoSに基づいて動作の制御を行う。
【００７８】
（ｃ）リソース割り当ての通知  
各処理部において、以上の手順で決定あるいは指定された消費量または供給量は、処理部の内部に実現されたリソース応札部に通知される、リソース応札部は、その消費量または供給量に対応する入札を入札管理部に対して行なう。
【００７９】
４．リソース管理装置の構成
４．１  リソース管理装置
図４は、リソース管理装置を構成するリソース応札部、入札管理部及びQoS制御部の関係を示すブロック図である。
【００８０】
本実施の形態におけるリソース管理装置１０１は、複数のリソース応札部１０２と複数の入札管理部１０３とQoS制御部１０８とを含んで構成される。図４は、各アプリケーションのリソース応札部と、対応する入札管理部と、QoS制御部１０８との関係を示すために、１つのリソース応札部１０２と、１つの入札管理部１０３と、QoS制御部１０８との間でのデータの流れを示す。
【００８１】
なお、図４におけるQoS制御部１０８は、レーダー信号処理アプリケーション４３，５３、ソナー信号処理アプリケーション４４，５４、レーダー情報表示アプリケーション４５、及びソナー情報表示アプリケーション５５に設けられている。よって、応札処理にQoS制御部が関係しない物理リソースマネージャ４２，５２の応札処理では、図４のQoS制御部１０８は無く、リソース応札部１０２と入札管理部１０３によって、応札処理が行われる。
【００８２】
例えば、ノード２の場合、CPU利用率については、リソース応札部４２ａ、４３ａ、４４ａ、４５ａのそれぞれが、リソース応札部１０２に対応し、入札管理部４２ｂが、入札管理部１０３に対応する。レーダー情報のデータについては、リソース応札部４３ａ（及び５３ａ）、４５ａが、リソース応札部１０２に対応し、入札管理部４５ｂが、入札管理部１０３に対応し、QoS制御部４３ｂ（及び５３ｂ）、４５ｃが、QoS制御部１０８に対応する。
【００８３】
リソース応札部１０２は、入札値計算部１０４と、最終入札値記憶部１０５とを含む。入札管理部１０３は、落札者決定部１０６と、ラウンド繰り返し管理部１０７とを含む。そして、入札及び落札結果の通知のときは、リソースの量、QoS及び単価の情報が提供される。  
次に、リソース管理装置１０１の各構成要素の詳細な動作について述べる。
【００８４】
４．２  リソース応札部  
まず、リソース応札部１０２の処理について述べる。  
リソース応札部１０２は、前述の判定によって得られた消費量または供給量のリソースを入札管理部１０３に対して入札する、すなわち自己のリソースの情報の提供を行う。入札は、リソース応札部が入札管理部に対して複数回すなわち複数ラウンドにわたる入札を行なうことによって行なわれる。
【００８５】
各ラウンドでは、入札値計算部１０４が入札価格としての入札値を計算する。
【００８６】
入札価格としての入札値の計算にあたっては、その価格でリソースを売買することによる処理部の利益が最大化するような価格をつけなければならない。
【００８７】
入札値計算部１０４の具体的動作は、処理部が供給者、生産者及び消費者のいずれであるかによって異なる。以下、それぞれの場合について説明する。図１５及び図１６は、ラウンドが経過するにつれて、CPU利用率とデータの入札と落札の量と値が変化する例を示す表である。図１５では、CPU利用率についてのノード２と３における各処理部における入札量、入札値、落札量及び落札値が示され、図１６では、データについての各処理部における入札量、入札値、落札量及び落札値とが示されている。図１５及び図１６の各部において並んだ数字は、左から順に、入札量、入札値、落札量及び落札値が示されている。以下、図１５及び図１６を参照しながら説明する。
【００８８】
（ａ）供給者の場合  
供給者は、自己が供給できるリソースを売り惜しむ必要はないので、どれだけ安い値段であっても最大限リソースが売れるような入札を行なえばよい。従って、供給者の入札値計算部１０４は、固定の入札値を常に返せばよい。本実施の形態では供給者である物理リソースマネージャ４２，５２はCPU利用率を常に価格0で入札するものとする。このため供給者の場合には、最終入札値記憶部は省略してよい。
【００８９】
図５は、供給者の入札値計算部１０４の処理の流れの例を示すフローチャートである。入札値計算部１０４は、所定の入札価格、ここでは常に例えば固定の「０」を、入札値とする（ステップS1）。
【００９０】
（ｂ）生産者の場合  
生産者は、高い値段でリソースが売れる場合には、そのリソースの生成のために高い値段でリソースを買ってよい一方で、どうしても売値が買値を下回る場合は、売買を止める必要がある。このため生産者の入札値計算部１０４は以下のような処理を行なう。
【００９１】
最終入札値記憶部１０５には、前回の入札の最終ラウンドにおける入札おいてアプリケーションが指定した入札値とQoSとが記憶されている。
【００９２】
はじめのラウンドでは、入札値計算部１０４は、最終入札値記憶部１０５に記録された値を入札値とQoSとして採用する。なお、最終入札値記憶部１０５には、入札値の初期値として0 が記録され、QoSの標準的な値（あるいは最大値）が記録されている。2回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたかどうかによって入札値とQoSの調整を行う。
【００９３】
入札値計算部１０４は、自己の供給するリソース（例えば、レーダー信号処理アプリケーション４３であれば、レーダー情報というデータ）については、自己が消費するリソース（例えば、レーダー信号処理部４３であれば、CPU利用率）の入札値（買値）の合計の予測値を入札値（売値）として入札を行なう。自己が消費するリソースの入札値（買値）の予測値は、たとえば前回のラウンドでの自己が消費するリソースの落札値(必ずしもその処理部が落札できた値ではなく、その処理部が落札できなかった場合には他の処理部の落札値)の合計を求めるという方法で計算される。自己が消費するリソースについては、そのリソースが前回のラウンドで十分に落札できていなければ、そのリソース入札値を所定量だけ上げる、といった方法で計算される。
【００９４】
図６は、生産者が供給するリソースについての入札値計算部１０４の処理の流れの例を示すフローチャートである。図６の処理は、入札処理における各ラウンドが開始する直前に、レーダー信号処理アプリケーション４３が実行して、ラウンド毎に入札値とQoSを決定する。その決定された入札値とQoSは、入札管理部１０３へ供給される。
【００９５】
まず、入札値計算部１０４は、CPU利用率の前回の落札量が、レーダー情報の落札量から計算したCPU利用率の必要量未満であったか否かを判定する（ステップS11）。CPU利用率の落札量が、レーダー情報の落札量から計算したCPU利用率の必要量未満であるということは、アプリケーションを実行するためのリソースが割り当てられていないことを意味する。CPU利用率の前回の落札量が、レーダー情報の落札量から計算したCPU利用率の必要量未満であった場合は、ステップS11でYESとなり、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、CPU利用率の落札値とCPU利用率の落札量との積以上か否かを判定する（ステップS12）。
【００９６】
なお、図１５及び図１６の場合は、レーダー情報を「１００」生成するのに、レーダー信号処理アプリケーション４３は、CPU利用率が「１３５」必要な場合の例である。
【００９７】
ステップS11でYESとなるのは、ノード２のレーダー信号処理アプリケーション４３のラウンド５において、CPU利用率については、図１５においては落札量が「４８」であるのに対して、図１６においては、レーダー情報の落札量「９１」の場合である。この場合、レーダー情報の落札量「９１」から計算したCPU利用率が「１２３」で、CPU利用率の落札量が「４８」以上の場合である。
【００９８】
レーダー情報の落札値とレーダー情報の落札量との積が、CPU利用率の落札値とCPU利用率の落札量との積以上である場合は、ステップS12でYESの場合となり、処理はステップS13へ移行する。ステップS12でYESの場合は、いわゆる採算が取れている（すなわち売値が買値を上回っている）ことを意味とする。ノード２のレーダー信号処理アプリケーション４３のラウンド１９において、CPU利用率については、図１５においては落札量が「７４」で落札値が「０」で積が「０」に対して、レーダー情報については、図１６においては落札量が「５５」で落札値が「３７」で積が「２０３５」となっているような場合である。
【００９９】
ステップS12でYESの場合は、レーダー信号処理アプリケーション４３のCPU利用率の入札値を上げてもよいので、入札値計算部１０４は、CPU利用率の入札値を、所定量である微少量（ｄ１）だけ加算する（ステップS13）。加算する微少量は、ここでは「４」である。図１５においては、ノード２のレーダー信号処理アプリケーション４３のラウンド１９から２０にかけて、入札値が、「７４」から「７８」に増加されているような場合である。
【０１００】
ステップS12でNOの場合は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を下げるために、入札値計算部１０４は、レーダー情報の入札量を、所定量である微少量（ｄ２）だけ減算する（ステップS14）。ステップS12でNOの場合となるのは、いわゆる採算が取れていないことを意味とする。
【０１０１】
ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、CPU利用率については、図１５に示すように落札量が「７８」で落札値が「２８」でそれらの積が「２１８４」となる。これに対して、レーダー情報については、図１６において落札量が「３０」で落札値が「３７」でそれらの積が「１１１０」となっている。そのような場合に、レーダー信号処理アプリケーション４３は、ラウンド１８から１９にかけて、レーダー情報の入札量を「５８」から「５５」に下げているような場合である。
【０１０２】
そして、入札値計算部１０４は、変更されたCPU利用率の入札量AQを、レーダー情報の入札量から計算する（ステップS15）。
【０１０３】
次に、入札値計算部１０４は、QoSを所定量だけ下げるように調整する（ステップS16）。ステップS16は、調整されたQosにQosを更新するパラメータ更新部を構成する。レーダー画像であれば、画像の解像度が最高値から所定の許容限界値の間を取り得るとした場合、その許容限界値（最低値）に向かって所定の微少量だけ、そのときのQoSから減算して、新たなQoS(new)を算出する。例えば、当初は、最高値1000であった解像度を、所定の微少値50だけ減算して、新たな値950が得られる。許容限界値は、ユーザが、画像を利用するに当たって許容できる画像の品質レベルに対応する値であり、ユーザによって設定される。
【０１０４】
入札値計算部１０４は、その新たなQoS(new)を用いて、ステップS15で計算して得られたCPU利用率の入札量を再計算する（ステップS17）。例えば、ステップS15で計算して得られたCPU利用率の入札量AQに対して所定の演算処理、例えば、(QoS(new)／最高値)の２乗を乗算する処理を行うことによって、新たなCPU利用率の入札量AQ(new)が計算されて得られる。新たなCPU利用率の入札量AQ(new)は、入札値計算部１０４に記憶される。上述の例であれば、CPU利用率の入札量AQに、(950/1000)の２乗の値（=0.9025）が乗算されて、新たなCPU利用率の入札量AQ(new)が得られる。
【０１０５】
なお、新たなQoS(new)の情報は、アプリケーション自体の処理において利用されるように、図４に示すように、アプリケーション（AP）に供給される。
【０１０６】
ステップS17の計算により得られたCPU利用率は、QoSの低いレーダー情報を生成するのに必要なCPU利用率ということになる。
【０１０７】
そして、入札値計算部１０４は、CPU利用率の入札値と入札量との積を、レーダー情報の入札量で除算することによって、レーダー情報の入札値を計算する（ステップS18）。よって、ステップS17とS18は、リソースの入札値を変更する入札値変更部を構成する。
【０１０８】
言い換えると、入札において、CPU利用率が確保できず（ステップS11でYESの場合）、かついわゆる採算が取れているとき（ステップS12でYESの場合）は、CPU利用率の入札値を上げる（ステップS13）だけでなく、画像の解像度を下げて（ステップS16）、CPU利用率の入札量を下げることによって、リソースの落札ができるように、入札処理が行われる。
【０１０９】
また、ステップS11でNOの場合、すなわち、レーダー情報を処理するのに必要なCPU利用率が確保できている場合、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、CPU利用率の落札値とCPU利用率の落札量との積以上か否かを判定する（ステップS19）。
【０１１０】
なお、ステップS11でNOとなるのは、図１５に示すように、ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、CPU利用率については、落札量が「７８」であるのに対して、図１６に示すようにレーダー情報の落札量が「３０」の場合である。この場合、レーダー情報の落札量「３０」に対応する必要なCPU利用率は「４１」となり、CPU利用率の落札量が「７８」よりも小さい。
【０１１１】
ステップS19でYESの場合、すなわち、いわゆる採算が取れている場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札値を上げるために、レーダー情報の入札値を、所定量である微少量（ｄ３）だけ加算する（ステップS20）。
【０１１２】
ステップS19でNOの場合、すなわち、いわゆる採算が取れていない場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札値を下げるために、レーダー情報の入札値を、所定量である微少量（ｄ４）だけ減算する（ステップS21）。  
その後、入札値計算部１０４は、CPU利用率の入札量AQを、レーダー情報の入札量から計算する（ステップS22）。次に、入札値計算部１０４は、QoSを所定量だけ上げるように調整する（ステップS23）。ステップS23は、調整されたQosにQosを更新するパラメータ更新部を構成する。そのときのQoSに所定の微少量だけ減算して、新たなQoS(new)を算出する。例えば、900であった解像度を、所定の微少値50だけ加算して、新たな値950が得られる。
【０１１３】
そして、処理は、ステップS17とS18へ移行する。
【０１１４】
言い換えると、入札において、CPU利用率が確保できており（ステップS11でNOの場合）、かついわゆる採算が取れているとき（ステップS12でYESの場合）は、画像の解像度を上げて（ステップS23）、CPU利用率の入札量を上げるように、入札処理が行われる。
【０１１５】
（ｃ）消費者の場合  
消費者は、その局面すなわち状況におけるそのアプリケーションの重要度に対応した買値の上限値の範囲内で、自己が消費するリソースを買って処理動作を行なう。各アプリケーションの重要度は、状況に応じて変更可能である。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、アプリケーションが局面を認識して計算してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。
【０１１６】
本実施の形態では、レーダー情報がソナー情報よりも重要であると仮定して、レーダー情報表示アプリケーションのリソースの買値の合計の上限値を「２０００００」、ソナー情報表示アプリケーションのリソースの買値の合計の上限値を「１０００００」とし、その範囲内でリソースが買えなければ単位時間のリソース購入を断念するものとする。従って、センサ信号の重要度が反映された入札が行われる。
【０１１７】
入札値計算部１０４は、はじめのラウンドでは、最終入札値記憶部１０５に記録された値を入札値とQoSとして採用する。なお、最終入札値記憶部１０５には入札値の初期値として「０」 が記録され、QoSの標準的な値（あるいは最高値）が記録されている。2回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたかどうかによって入札値とQoSの調整を行なう。
【０１１８】
図７は、消費者の入札値計算部１０４の処理の流れの例を示すフローチャートである。まず、入札値計算部１０４は、CPU利用率の落札量が、CPU利用率の必要量未満であるか否かを判定する（ステップS31）。
【０１１９】
その必要量は、例えば、図１５では、ノード２のレーダー情報表示アプリケーションのCPU利用率の必要量は「６０」であり、図１５では、結果として落札量が「６０」となっている。
【０１２０】
ステップS31でYESの場合、すなわち、CPU利用率の落札量がCPU利用率の必要量未満の場合は、入札値計算部１０４は、CPU利用率の入札値を、所定量である微少量（ｄ５）だけ増加する（ステップS32）。
【０１２１】
そして、図６のステップS16,S17と同様な処理により、入札値計算部１０４は、QoSを所定の微少量だけ下げ、その下げたQoS(new)に応じたCPU利用率の入札量を再計算する（ステップS33,S34）。入札値計算部１０４は、CPU利用率の入札値にCPU利用率の入札量を乗算した乗算値を上限値から減算し、その減算値を、レーダー情報の入札量で除算して、レーダー情報の入札値を計算する（ステップS35）。すなわち、CPU利用率の入札値にCPU利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、レーダー情報の入札値が決定される。
【０１２２】
ステップS31でNOの場合、すなわち、CPU利用率の落札量がCPU利用率の必要量以上の場合は、入札値計算部１０４は、レーダー情報の落札量がレーダー情報の必要量以上であるか否かを判定する（ステップS36）。
【０１２３】
レーダー情報の必要量は、QoSに応じて決まる値である。例えば、ノード２のレーダー情報表示アプリケーション４５のCPU利用率の必要量は「１００」であり、図１６では、結果として落札量が「１００」となっている。
【０１２４】
ステップS36でYESの場合、すなわち、レーダー情報の落札量がレーダー情報の必要量以上の場合は、入札値計算部１０４は、レーダー情報の入札値を、所定量の微少量（ｄ６）だけ加算して増加する（ステップS37）。レーダー情報により高い入札値を付けることにより、結果として、CPU利用率には、より低い入札値を付けるためである。
【０１２５】
そして、図６のステップS22,S23と同様な処理により、入札値計算部１０４は、QoSを所定の微少量だけ上げ、その上げたQoS(new)に応じたCPU利用率の入札量を再計算する（ステップS38,S39）。
【０１２６】
入札値計算部１０４は、レーダー情報の入札値にレーダー情報の入札量を乗算した乗算値を上限値から減算し、その減算値を、CPU利用率の入札量で除算して、CPU利用率の入札値を計算する（ステップS40）。すなわち、CPU利用率の入札値にCPU利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、CPU利用率の入札値が決定される。
【０１２７】
４．３  入札管理部
次に、入札管理部１０３の処理について述べる。  
入札管理部１０３は、各リソース応札部１０２からの入札、すなわち応札情報、に基づき、どの処理部がリソースを落札するかを決定し、落札結果を各処理部のリソース応札部１０２に通知する。落札結果情報には、その処理部が落札できたかどうかの情報と、落札値(必ずしもその処理部が落札できた価格ではなく、その処理部が落札できなかった場合には他の処理部の落札価格となる)の情報とが含まれている。
【０１２８】
落札結果情報を受け取った各処理部のリソース応札部１０２は、その結果にもとづいて処理単位時間の動作を行なう。消費するリソースを最終的に落札できた処理部は、そのリソースを消費する動作を行なう。通常、ある処理単位時間に消費するリソースを全て落札できなかった処理部は、その処理単位時間内に処理を行なわずにいわゆる休眠状態に入る。しかし、消費するリソースの一部が落札できなくてもなんらかの動作が可能な場合は、その処理部は、その分だけの処理動作を行なう。一方、供給できるリソースが落札されなかった処理部は、次の処理単位時間ではそのリソースの供給を行なわない。
【０１２９】
物理リソースであるCPU利用率の場合、各アプリケーションは、CPU利用率を落札したときは、次の処理単位時間においてその落札の結果得られた時間だけ、CPUを利用した所定の処理を実行する。物理リソース以外のリソースであるデータの場合は、各アプリケーションは、データを落札したときは、落札した量のデータ量の処理を行う。
【０１３０】
例えば、レーダー信号処理アプリケーション４３は、その落札結果通知情報に含まれるQoSに対応する解像度のデータを、落札の結果得られたCPU時間だけ、実行する。なお、上述したように、レーダー情報表示アプリケーション４５は、CPU利用率の落札と、データ量の落札（レーダー信号処理アプリケーション４３あるいは５３のいずれかからの落札）の、両方の落札があったときにのみ、落札の結果得られたCPU時間だけ、落札の結果得られたデータ量の処理を、QoSに応じて実行する。
【０１３１】
（ａ）ラウンド管理
ここで、ラウンドについて説明する。  
本実施の形態では、ラウンド数すなわち繰り返し回数が入札の打ち切り条件である。すなわち、所定のラウンド数を超えて、入札処理が行われないように管理されている。すなわち、入札管理部１０３のラウンド繰り返し管理部１０７が、各処理単位時間におけるラウンド数をカウントし、所定の回数だけ落札者決定が行われるように監視して管理している。
【０１３２】
図８は、ラウンド繰り返し管理部１０７により、入札処理が所定回数しか行われないことを説明するための図である。
【０１３３】
図８に示すように、リソース応札部１０２は、最初に、前回の最終入札値を最終入札値記憶部１０５から読み出して、その最終入札値を用いて入札値を計算し、入札を行う（入札（１））。その入札に対しては、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（１））。この落札（１）に応じて、次の（すなわち２回目の）入札値計算が行われ、入札が再度行われる（入札（２））。その入札（２）に対しても、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（２））。さらに、その落札に対しても再度入札が行われ（入札（３））、落札処理が行われる。なお、１回目と２回目のときは、ラウンド繰り返し管理部１０７から落札者決定部１０６へ、後述する打ち切り通知は出力されない。
【０１３４】
このように、１回の入札に対する落札の処理を１ラウンドとして、ラウンド繰り返し管理部１０７は、入札の入力あるいは落札結果の出力があったときには、ラウンド数をインクリメントして、ラウンド数をカウントする。
【０１３５】
ラウンド数が、所定の数になると、ラウンド繰り返し管理部１０７はラウンド数が所定の数になったことを検出する。その検出結果は、落札者決定部１０６に、打ち切り通知として通知される。落札者決定部１０６は、打ち切り通知の情報をリソース応札部１０２に通知する。打ち切り通知を受けた入札値計算部１０４は、再度、入札値計算をしないで、落札情報の最終入札値とQoSを、最終入札値記憶部１０５に書き込む。
【０１３６】
Qosは、Qosを記憶する記憶部でもある最終入札値記憶部１０５から最初に読み出され、その後のラウンドで変更される場合がある。そして、最後のラウンド時のQosが、最終入札値記憶部１０５に書き込まれる。
【０１３７】
以上のようにして、ラウンド数が入札処理の打ち切り条件として、所定の数以上入札が行われないようにしたので、本実施の形態のリソース管理装置は、所定時間内に確実に入札処理が終わらせることができるように構成されている。
【０１３８】
（ｂ）処理単位時間
次に、処理単位時間について説明する。処理単位時間は、ここでは、各アプリケーションの実行時間である。図９は、処理単位時間を説明するための図である。図９は、ノード２の３つのアプリケーション（レーダー信号処理アプリケーション４３，ソナー信号処理アプリケーション４４、レーダー情報表示アプリケーション４５）が実行される場合を示す。図９は、３つのアプリケーションＡＰ１，ＡＰ２，ＡＰ３が、処理単位時間毎に割り当てられたリソースであるCPU利用率に応じた時間だけ実行されることを示している。
【０１３９】
処理単位時間毎に、次の処理単位時間における各アプリケーション毎のリソースの配分が入札により決定される。時間t(i)から時間t(i+1)までの間の処理単位時間（PUT1）において、上述したように、所定の回数の入札を行い、最終的に落札者を決定している。本実施の形態では、所定回数は３回である。そして、その決定された落札結果に応じて、各アプリケーションは、割り当てられたCPU利用率だけ実行される。図９では、時間t(i+1)から時間t(i+2)までの間の処理単位時間（PUT2）における各アプリケーションのCPU利用率は、処理単位時間（PUT1）内における入札処理において、決定される。
【０１４０】
図９では、１回目の入札（R1）が行われた後、２回目の入札（R2）が行われ、その後、３回目の入札（R3）が行われる。３回の入札後において、最終的にタイミングDにおいて、落札内容が決定される。その落札結果に応じて、次の処理単位時間において各アプリケーションが、割り当てられたCPU利用率だけ実行される。
【０１４１】
同様に、処理単位時間（PUT3）における各アプリケーションのCPU利用率は、処理単位時間（PUT2）内における入札処理において、決定される。以下同様にして、次の処理単位時間における、各アプリケーションに割り当てられるCPU利用率は、その処理単位時間の前の処理単位時間において入札により決定される。
【０１４２】
（ｃ）落札者決定部  
入札情報を受け取った入札管理部１０３では、落札者決定部１０６が、どのアプリケーションがリソースを落札するかを決定する。
【０１４３】
落札者決定部１０６の動作を、ノード２の物理リソースマネージャ４２の入札管理部４２ｂが、図１０に示す内容に対して、入札を行った場合を例に説明する。図１０は、物理リソースの入札情報の例を示す図である。  
入札情報には、モジュール名、供給量又は消費量、入札値、供給者と消費者の別の情報が含まれている。モジュール名は、各処理部を示し、図１０のような文字列のほか、プロセス番号などの数値で表現することもできる。供給量又は消費量は、リソースをいくら消費または供給するかをリソースごとに定義された単位の数量で指定する。図１０ではCPU利用率をパーセンテージで指定している。入札価格である入札値は、リソースをいくらで消費または供給するかを仮想的な通貨で指定する。その指定は、リソースの単位ごとの単価で示してもよいし、総額(単価に数量を乗じた値)で示してもよい。図１０では単位利用率ごとの単価で示している。
【０１４４】
なお、本実施の形態では、QoSは、リソースとしてのデータについて適用し、CPU利用率については、適用していない。よって、物理リソースマネージャの入札管理部が扱う入札情報は、図１０に示すものであるが、図１１に示すQoSを固定値として扱うことによって、図１０は、図１１のような構成でもよい。
【０１４５】
落札者決定部１０６の動作を説明する。  
まず、CPU利用率のように、供給者が一つで消費者が複数である場合の、すなわち本実施の形態では物理リソースマネージャ４２の入札管理部４２ｂの場合の、落札者決定部１０６の動作を説明する。この場合は、消費者からの入札に対して、入札値が高い順に、供給量がなくなるまで、あるいは消費者からの入札の入札値が供給者からの入札の入札値を下回るまで、リソースを割り当てることによって決定される。
【０１４６】
その際の落札値は、入札量を全て満たすだけのリソースが割り当てられなかった消費者からの入札のうち最大の入札値か、あるいは供給者からの入札の入札値かのいずれかの高い方の額となる。
【０１４７】
例として、図１０に示す入札が行なわれた場合、物理リソースマネージャからの供給量である１８０%が各アプリケーションの消費量に割り当てられる。この場合、入札値の高い順に、まずレーダー情報表示アプリケーション４５に利用率８０%が割り当てられる。次に、レーダー信号処理アプリケーションの１６０％に対して、残りの供給量１００％が割り当てられる。また、落札値は、レーダー信号処理アプリケーション（入札量１６０％を全て満たすだけのリソースは割り当てられていない）の入札値「３」が物理リソースマネージャの入札値「０」よりも高いので、「３」となる。
【０１４８】
次に、落札者決定部１０６の動作を、ノード２のレーダー情報表示アプリケーション４５の入札管理部４５ｂが、図１１に示す内容に対して、入札を行った場合を例に説明する。図１１は、データの入札情報の例を示す図である。図１１の入札情報には、モジュール名、供給量又は消費量、入札値、供給者と消費者の別の情報に加えて、QoSの情報が含まれている。  
図１１において、レーダー情報表示アプリケーション４５の消費量が「１００」となっているのは、レーダー情報表示アプリケーション４５は、１００％のデータをもらわなければ表示処理ができないことを意味している。ノード２のレーダー信号処理アプリケーション４３の供給量が「５８」となっているのでは、レーダー信号処理アプリケーション４３がレーダー情報を処理して供給できる割合（％）の最大値が「５８」であることを示している。この最大値「５８」は、ノード２においてレーダー信号処理アプリケーション４３が使えるCPU利用率から決定される値であり、レーダー情報１００％のうち５８％はレーダー信号処理アプリケーション４３によって処理してもよいとされる設定値である。同様に、ノード３のレーダー信号処理アプリケーション５３の供給量が「６４」となっているのでは、レーダー信号処理アプリケーション５３がレーダー情報を処理して供給できる割合（％）の最大値が「６４」であることを示している。この最大値「６４」は、ノード３においてレーダー信号処理アプリケーション５３が使えるCPU利用率から決定される値であり、レーダー情報１００％のうち６４％はレーダー信号処理アプリケーション５３によって処理してもよいとされる設定値である。
【０１４９】
レーダー情報表示アプリケーション４５のQoSの「５００」は、レーダー情報表示アプリケーション４５に関しては、QoSの最小値すなわち許容限度値が「５００」であることを意味している。ノード２のレーダー信号処理アプリケーション４３とノード３のレーダー信号処理アプリケーション５３のQoSが、共に「１０００」となっているのは、QoSの最大値が共に「１０００」であることを意味している。
【０１５０】
QoSが「１０００」の最大値に対して、消費量「１００」のデータをもらわなければレーダー情報表示アプリケーション４５は、その表示処理をできないが、QoSが低くなれば、そのQoSに応じて消費量は「１００」よりも低くなり、結果として、その消費量の低下に応じてCPU利用率も低下する。
【０１５１】
レーダー情報表示アプリケーション４５の入札値が「１９８０」となっているのは、レーダー情報表示アプリケーション４５は、入札価格の最大値が「１９８０」であることを意味している。ノード２のレーダー信号処理アプリケーション４３とノード３のレーダー信号処理アプリケーション５３の入札値が、共に「３７」となっているのは、入札価格の最小値が共に「３７」であることを意味している。
【０１５２】
なお、ここでは入札値は、CPU利用率の単位利用率ごとの単価としたので、入札値の大きさを比較する際にはCPU利用率を考慮する必要はないが、総額を入札値として入札を行なう場合は、落札者決定部１０６において、入札値をCPU利用率で割ることによって単価を計算し、その単価を比較して落札者を決定する必要がある。
【０１５３】
後述するように、図１１の場合、供給者からの入札に対して、入札価格が低い順に、供給量がなくなるまで、あるいは供給者からの入札の入札価格が消費者からの入札の入札価格を上回るまで、リソースの割り当てが行われる。ただし、供給者からの入札のQoSが消費者からの入札のQoSを下回る入札は落札されない。
【０１５４】
なお、上述した通り、生産者や消費者は、自分が消費するリソースのうち一部のみを落札した場合は、落札したリソースをキャンセルする。その際は、次点の入札者が繰り上がってリソースを落札する。
【０１５５】
図１２は、供給者である物理リソースマネージャの落札者決定部１０６の処理の流れの例を示すフローチャートである。ここでは、ノード２の場合で説明する。
【０１５６】
まず、落札者決定部１０６は、供給者の決定した供給量、すなわち供給者の入札情報における供給量を、供給量とする（ステップS41）。
【０１５７】
落札者決定部１０６は、リソースの消費者からの入札情報の中で、価格が最も高い入札を選択する（ステップS42）。図１０の例であれば、レーダー情報表示アプリケーション４５が選択される。
【０１５８】
落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値以上か否かの判定が行われる（ステップS43）。図１０の場合、供給者である物理リソースマネージャ４２の入札値は「１」であり、消費者であるレーダー情報表示アプリケーション４５の入札値は「４」であるので、ステップS43でYESの場合となり、ステップS44へ処理は移行する。
【０１５９】
落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値未満であるときは、ステップS43でNOとなり、処理は終了する。
【０１６０】
ステップS44では、落札者決定部１０６は、その消費者からの入札のうち、残りの供給量を超えない量を落札量と決定する。図１０の場合、レーダー情報表示アプリケーション４５の消費量８０が、供給量１８０から減算できるので、供給量を超えない量である消費量８０が落札量とされる。
【０１６１】
次に、落札者決定部１０６は、残り供給量を算出する、すなわち、残り供給量から落札量を減算することによって残り供給量を算出する（ステップS45）。図１０の場合、供給量１８０から落札量８０を減算して、残り供給量１００が算出される。
【０１６２】
そして、落札者決定部１０６は、残り供給量が０以下であるか否かを判定する（ステップS46）。
【０１６３】
残り供給量が０を超えるときは、ステップS46でYESとなり、処理は、ステップS42に戻る。残り供給量が０以下のときは、ステップS36でNOとなり、処理は、終了する。
【０１６４】
ステップS42では、落札者以外の消費者から入札について、上述したステップS42からS46までの処理を繰り返す。
【０１６５】
以上のステップS41からS46までの処理が、所定の回数（ここでは３回）繰り返される。ステップS41からS46までの処理が、１ラウンドに対応する。  
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを消費するリソース消費プログラムが複数ある場合、複数のリソース消費プログラムの中で、入札値の大きいプログラムを優先してリソースを割り当てるようにリソース割り当て処理を行なう。
【０１６６】
一方、センサ情報のように、供給者が複数で消費者が一つである場合、すなわち本実施の形態ではレーダー情報表示アプリケーション４５の入札管理部４５ｂの場合、の落札者決定部の動作は、図１２において、「供給」と「消費」を読み替え、「高い」を「低い」と読み替えればよい。図１３は、情報表示アプリケーションの落札者決定部１０６の処理の流れの例を示すフローチャートである。
【０１６７】
まず、落札者決定部１０６は、消費者の決定した消費量、すなわち消費者の入札情報における消費量を、消費量とする（ステップS51）。
【０１６８】
落札者決定部１０６は、リソースの供給者からの入札情報の中で、価格が最も低い入札を選択する（ステップS52）。図１１の場合、ノード２のレーダー信号処理アプリケーション４３と、ノード３のレーダー信号処理アプリケーション５３とは、同じ入札値、すなわち「３７」であるので、ここでは、例えばこれら２つのアプリケーションに優先順位を予め設定しておくことにより、２つのアプリケーションのいずれかが選択される。例えば、レーダー信号処理アプリケーション４３が選択される。
【０１６９】
落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値以下か否か、かつ、供給者の入札のQoSが消費者の入札のQoS以上であるか否かの判定が行われる（ステップS53）。図１１の場合、消費者であるレーダー情報表示アプリケーション４５の入札値は、「３７以上」である「１９８０」であり、かつレーダー情報表示アプリケーション４５の入札のQoSは、「５００以上」である「１０００」であるのでステップS53でYESの場合となり、ステップS54へ処理は移行する。
【０１７０】
なお、落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値を超えるときは、ステップS53でNOとなり、処理は終了する。
【０１７１】
落札者決定部１０６は、ステップS54では、その供給者からの入札のうち、残りの消費量を超えない量を落札量と決定する。図１１の場合、レーダー情報表示アプリケーション４５の消費量「１００」から供給量「５８」が減算できるので、消費量を超えない量である供給量「５８」が落札量とされる。
【０１７２】
次に、落札者決定部１０６は、残り消費量を算出する、すなわち、残り消費量から落札量を減算することによって残り消費量を算出する（ステップS55）。図１１の場合、残り消費量１００から落札量５８を減算して、残り消費量４２が算出される。
【０１７３】
そして、落札者決定部１０６は、残り消費量が０以下であるか否かを判定する（ステップS56）。
【０１７４】
残り消費量が０を超えるときは、ステップS56でYESとなり、処理は、ステップS52に戻る。残り消費量が０以下のときは、ステップS56でNOとなり、処理は、終了する。
【０１７５】
ステップS52では、落札者以外の供給者から入札について、上述したステップS51からS56までの処理を繰り返す。
【０１７６】
以上のように、ステップS53において、入札価格が上限値を超えないで、かつQoSも許容限度値以上であることを条件に、落札者決定処理が行われる。
【０１７７】
なお、以上のステップS51からS56までの処理が、所定の回数（ここでは３回）繰り返される。ステップS51からS56までの処理が、１ラウンドに対応する。  
この繰り返し回数も、予め決められており、本実施の形態では、３である。  
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを供給するリソース供給プログラムが複数ある場合、複数のリソース供給プログラムの中で、入札値の小さいプログラムを優先して前記リソースを割り当てるようにリソース割り当て処理を行なう。
【０１７８】
（ｄ）ラウンド繰り返し管理部  
図１２及び図１３で説明した処理の実行回数は、ラウンド繰り返し管理部１０７によりカウントされ、所定回数を超えて図１２及び図１３の処理が実行されないように、ラウンド繰り返し管理部１０７は、落札者決定部１０６における上述した処理の実行を制御する。
【０１７９】
図１４は、ラウンド繰り返し管理部１０７の処理の流れの例を示すフローチャートである。ラウンド繰り返し管理部１０７は、上述したラウンドの繰り返し回数をカウントする（ステップS61）。ラウンド繰り返し管理部１０７は、カウントしたラウンド繰り返し回数が所定回数、本実施の形態では３回になったか否かを判定する（ステップS62）。そして、カウントしたラウンド繰り返し回数が所定回数にならなければ、処理は、ステップS62でNOとなり、ステップS61に戻る。カウントしたラウンド繰り返し回数が所定回数になると、ラウンド繰り返し管理部１０７は、図１１及び図１２の処理を終了させる実行終了処理を行う（ステップS63）。実行終了処理では、上述した打ち切り通知が、落札情報と共に、あるいは落札情報とは別に、リソース応札部１０２に出力される。
【０１８０】
このように、ラウンド繰り返し管理部１０７は、内部にラウンドの回数を記憶し、ラウンドの度に１つずつインクリメントし、カウントしたラウンドの回数が上限すなわち所定回数に達したら、それ以上のラウンドを実行しないように、処理を打ち切る、すなわち終了させる。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。
【０１８１】
この打ち切りによって、入札が一定の時間内に終了することが保証される。なお、ラウンドが終了したかどうかは入札を行なった処理部への落札結果の通知の際に、付加情報として通知される。
【０１８２】
なお、上述した例では、ラウンド繰り返し回数をカウントアップして所定回数になったか否かの判断がされているが、逆に所定回数からラウンドの度に１つずつカウントダウンして０（ゼロ）になったか否かの判断を行うことによって、ラウンド繰り返し回数を管理するようにしてもよい。
【０１８３】
５．装置全体の動作  
上述したようなリソース管理装置において、入札値計算部１０４における増減させる所定量等のパラメータを適宜設定することにより、最終的には、ノード２のレーダー情報表示アプリケーションが、ノード３のレーダー信号処理アプリケーションからレーダー情報を得て動作する、という結果に収束させることができる。
【０１８４】
図１５及び図１６は、ラウンド数が「２０」までの、本実施の形態におけるリソース管理装置の入札と落札の状況を示す表である。図１５及び図１６では、連続した２０回のラウンドにおける入札値等のデータの例が示されているが、上述したラウンド繰り返し回数が「３」であるので、ラウンド１から３が、１回目の入札処理を経過と結果を示し、ラウンド４から６が、２回目の入札処理の経過と結果を示す。以下、同様に、３回のラウンドで、処理単位時間における入札処理が行われている。
【０１８５】
上述したように、図１５及び図１６は、リソースの供給と消費の関係において、レーダー信号処理アプリケーションは１００％のレーダー情報を生成するためにCPU利用率１３５％を必要であり、ソナー信号処理アプリケーションは、１００％のソナー情報を生成するためにCPU利用率９０％を必要であり、レーダー情報表示アプリケーションは、１００％のレーダー情報を処理するのにCPU利用率９０％を必要であり、ソナー情報表示アプリケーションは、１００％のソナー情報を処理するのにCPU利用率３５％を必要であるという条件で処理が行われた場合の例を示す。また、入札値の計算の際に値を増減させる微少量は、入札値では「４」で、入札量では「３」という値である場合が示されている。そして、入札では、ノード２と３のそれぞれのCPU利用率、レーダー情報及びソナー情報の４つのリソースについて、それぞれ入札参加者からの入札が行われ、落札量と落札値が決定されている。
【０１８６】
図１５及び図１６では、２０回目以降のラウンドでは、リソースが適切に割り当てられている。２０回目のラウンドの結果を見ると、ノード２では、レーダー信号処理アプリケーションがCPU利用率７８％でレーダー情報５８％を生成し、ソナー信号処理アプリケーションがCPU利用率４２％でソナー情報３７％を生成している。ノード３では、レーダー信号処理アプリケーションがCPU利用率８６％でレーダー情報４２％を生成し、ソナー信号処理アプリケーションがCPU利用率５６％でソナー情報６３％を生成している。
【０１８７】
これらの割り当て結果は、レーダー信号処理アプリケーションは、１００％のレーダー情報を生成するのに、CPU利用率１３５％を必要とし、ソナー信号処理アプリケーションは、１００％のソナー情報を生成するのに、CPU利用率９０％を必要とするという条件を満たしている。また、レーダー情報表示アプリケーションは６０％のCPU利用率で、ソナー情報表示アプリケーションは３５％のCPU利用率という条件も満たしている。さらに、レーダー情報表示アプリケーションは１００％のレーダー情報を落札し、ソナー情報表示アプリケーションは１００％のソナー情報を落札しているので、それぞれ表示に必要なデータも問題なく得ている。２０回目の以前のラウンドでは、一応の動作は可能であるが、CPU利用率が十分に割り当てられていない場合もあるので、装置全体のリアルタイム性が満足されていない状態となる虞がある。しかし、このような状態は、入札初期の状態のときだけで生じるので、全体として問題はない。
【０１８８】
本実施の形態では、レーダー情報がソナー情報よりも重要であるので、レーダーの信号処理と情報表示がソナーの信号処理と情報表示よりも優先されて実行されるように、入札値の上限値が設定されている。上述した例では、２つのセンサ情報表示アプリケーション間で、買値の上限値を異ならせ、各センサ情報表示アプリケーションは、その上限値の範囲内で、自己が消費するリソースを買って動作を行なう。なお、この上限値は、状況に応じて設定変更可能とすれば、各アプリケーションの重要度は、状況に応じて変更可能となる。
【０１８９】
また、レーダー情報表示アプリケーションによってCPU利用率が落札されてCPU利用率の価格が上がっているノード２よりも、ノード３の方がCPU利用率の入札値が低いので、ノード２のレーダー情報処理アプリケーションよりもノード３のレーダー情報処理アプリケーションの方がレーダー情報のリソースとしての入札値（売値）が低いため、レーダー情報表示アプリケーション４５は、ノード３のレーダー情報処理アプリケーション５３からレーダー情報を買うことになり、ノード３のレーダー情報処理アプリケーション５３が動作している。
【０１９０】
さらに、リソース応札部１０２において、最終入札値記憶部１０５が設けられているため、次の処理単位時間における入札処理では、前回の入札結果に基づいて、入札値が計算されるので、適切な状態に収束するまでの時間が長く掛かるということが回避されている。
【０１９１】
すなわち、入札処理を単純に打ち切ってしまうのでは対応として不十分となる虞があるため、上述したように、複数のラウンドの入札処理が実行される。これは、リソースの割り当て効率を漸進的に改善するためであるが、少数のラウンドでは十分に改善が進まないこともあり得る。そのような場合、処理単位時間毎の入札でのリソース割り当てが非効率、つまりその局面での信号処理の重要度などを正しく考慮したリソース割り当てた方ができない状態が続いてしまう。そのような場合に、もし最終入札値記憶部がなければ、生産者や消費者の入札値は処理単位時間ごとに毎回0から開始することになり、適切な割り当て状態に収束するまでには多くの回数の、上述の場合であれば２０回以上のラウンドを経なければならない。そのため、上述したように、本実施の形態では、入札を一定の時間内に終了することを保証するためにラウンド繰り返し管理部によってラウンドを例えば５回で打ち切っても、例えば４つの処理単位時間を経ることによって適切な割り当て状態に収束するように、最終入札値記憶部によって前回の入札値が記憶されている。
【０１９２】
なお、変形例として、上述した実施の形態では、ラウンドの打ち切り条件は繰り返し回数であるが、ラウンド繰り返し管理部は、ラウンドの回数ではなくラウンドの実行時間を計測して所定時間に達したらラウンドの打ち切りを行なうようにしてもよい。  
この所定の時間はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。あるいは、時間計測によるラウンドの打ち切りの方法としては、初回ラウンド時にOSが提供するタイマー機能を利用して、タイマーを設定し、その設定した時間が経過したことを通知させて打ち切りを行なうようにしてもよい。  
また、初回ラウンド時にOSのリアルタイムクロックを読み出して時刻をラウンド繰り返し管理部に記憶し、ラウンドの度に現在の時刻と記憶された時刻との差を計算して一定の時間が達したかどうかを判定する、といった方法も可能である。
【０１９３】
なお、以上説明した本実施の形態では、センサ情報システム１は、説明の簡単のために、２つのノード２，３からなるシステムであるが、３以上のノードを含むものであってもよい。また、センサ信号を出力するレーダー装置２５とソナー装置３５は、それぞれノード２と３に接続されているが、それぞれがセンサ信号を出力する複数の装置が、１つのノードに接続されるように、システムが構成されていてもよい。すなわち、ノードの中には、センサ信号を出力する装置が接続されていないものがあったり、それぞれがセンサ信号を出力する複数の装置が接続されているものがあってもよい。
【０１９４】
さらになお、上述した実施の形態では、各ノードには、２つのCPUが設けられているが、１つあるいは３以上のCPUが設けられていてもよく、各ノード内部のバスにより、一つまたは複数のCPUが他の回路とバスで接続される。
【０１９５】
以上のように、上述した本発明の実施の形態によれば、センサ情報システム１において、入札方式という市場メカニズムによるリソース割り当てを行なう際に、QoS適応可能なアプリケーションである信号処理アプリケーション及び情報表示アプリケーションのデータのQoSを調整することによって、結果として、そのアプリケーションのリソースの消費量が調整される。その結果、ユーザ価値が相対的に低いアプリケーション、あるいはユーザ価値が相対的に低いアプリケーションを消費者とする生産者のアプリケーションも、できるだけ動作できるようになる。
【０１９６】
結果として、例えば、各信号処理アプリケーションはそれぞれ利用できるCPU利用率に見合ったQoSで動作を行なうことになるので、ユーザ価値の低いアプリケーション(図１０の例ではソナー信号処理アプリケーション)の実行が打ち切られるのは、ハードウエア障害や異常な過負荷等の、利用できるCPU利用率が各アプリケーションのQoS適応では対応できないほど低下した場合のみとなる。よって、入札方式においてQoS適応を考慮することによって、ユーザ価値の低いアプリケーションであっても実行される機会が増え、ユーザの利便性が向上するという効果が得られる。
【０１９７】
また、上述した本発明の実施の形態によれば、サプライチェーン入札などの高度な入札にもとづいたリアルタイムシステムにおいて、回数または時間などの条件によって複数ラウンド入札におけるラウンドを打ち切ることにより、入札のリアルタイム性を確保しながら、リソースの割り当てが実現できる。すなわち、上述した実施の形態のリソース管理装置は、データの重要性に応じて、リアルタイム性を確保しながら、対応するアプリケーションを実行させるようにすることができる。
【０１９８】
また、前回の処理単位時間の入札における最終入札値を記録して次の処理単位時間の入札の初期値に利用することにより、入札値が長期的には打ち切りのない複数ラウンド入札値に漸近するという効果がある。
【０１９９】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明する。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【０２００】
さらになお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のリソース管理装置を実現することができる。
【０２０１】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【図面の簡単な説明】
【０２０２】
【図１】本発明の実施の形態に係わるセンサ情報処理システムの構成を示す構成図である。
【図２】２つのノードのソフトウエア構成におけるリソース管理の部分を説明するためのブロック構成図である。
【図３】本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。
【図４】リソース管理装置を構成するリソース応札部と入札管理部の構成を示すブロック図である。
【図５】供給者の入札値計算部の処理の流れの例を示すフローチャートである。
【図６】生産者が供給するリソースについての入札値計算部の処理の流れの例を示すフローチャートである。
【図７】消費者の入札値計算部の処理の流れの例を示すフローチャートである。
【図８】ラウンド繰り返し管理部により、入札処理が所定回数しか行われないことを説明するための図である。
【図９】処理単位時間を説明するための図である。
【図１０】物理リソースの入札情報の例を示す図である。
【図１１】データの入札情報の例を示す図である。
【図１２】供給者である物理リソースマネージャの落札者決定部の処理の流れの例を示すフローチャートである。
【図１３】情報表示アプリケーションの落札者決定部の処理の流れの例を示すフローチャートである。
【図１４】ラウンド繰り返し管理部の処理の流れの例を示すフローチャートである。
【図１５】ラウンドが経過するにつれて、CPU利用率の入札と落札の量と値が変化する例を示す表である。
【図１６】ラウンドが経過するにつれて、データの入札と落札の量と値が変化する例を示す表である。
【符号の説明】
【０２０３】
１  センサ情報システム、２、３  ノード、４  ネットワーク、２７，３７  バス、１０１  リソース管理装置
【図１】
2008077350.tif 000003
【図２】
2008077350.tif 000004
【図３】
2008077350.tif 000005
【図４】
2008077350.tif 000006
【図５】
2008077350.tif 000007
【図６】
2008077350.tif 000008
【図７】
2008077350.tif 000009
【図８】
2008077350.tif 000010
【図９】
2008077350.tif 000011
【図１０】
2008077350.tif 000012
【図１１】
2008077350.tif 000013
【図１２】
2008077350.tif 000014
【図１３】
2008077350.tif 000015
【図１４】
2008077350.tif 000016
【図１５】
2008077350.tif 000017
【図１６】
2008077350.tif 000018