(57)【要約】【課題】必要以上に多くのノードに処理が分散されることによる性能低下を防止すること。【解決手段】予め定められた単位時間内に複数のアプリケーションのそれぞれが消費または供給するリソースの割り当てを入札方式で決定するリソース管理装置であって、入札方式におけるリソースの仮想的な価格を示す入札値を計算する入札値計算部１０４と、ＣＰＵの消費量が他のアプリケーションより小さいアプリケーションによって供給されるリソースに対する入札値が、他のアプリケーションより大きな値になるように、計算された入札値を調整するＣＰＵ価格調整部１０４１と、調整された入札値に基づいて、複数のアプリケーションのそれぞれにリソースを割り当てる入札管理部１０３と、を備えた。【選択図】        図４
2010165049.tif 000002
【特許請求の範囲】
【請求項１】
予め定められた単位時間内に複数のアプリケーションのそれぞれが消費または供給するリソースの割り当てを入札方式で決定するリソース管理装置であって、
前記入札方式における前記リソースの仮想的な価格を示す入札値を計算する入札値計算部と、
消費する前記リソースの消費量が他のアプリケーションの前記消費量より小さいアプリケーションによって供給される前記リソースに対する前記入札値を、前記他のアプリケーションの前記入札値より大きな値に調整する調整部と、
調整された前記入札値に基づいて、前記複数のアプリケーションのそれぞれに前記リソースを割り当てる入札管理部と、
を備えることを特徴とするリソース管理装置。
【請求項２】
前記調整部は、前記消費量が他のアプリケーションの前記消費量より小さいアプリケーションほど大きい値を前記入札値に加算することにより、計算された前記入札値を調整すること、
を特徴とする請求項１に記載のリソース管理装置。
【請求項３】
前記調整部は、前記消費量を入力して前記消費量が大きいほど小さい出力値を出力する予め定められた関数に前記消費量を入力して出力される前記出力値を前記入札値に加算することにより、計算された前記入札値を調整すること、
を特徴とする請求項１に記載のリソース管理装置。
【請求項４】
前記関数は、入力された前記消費量に反比例する前記出力値を出力すること、
を特徴とする請求項３に記載のリソース管理装置。
【請求項５】
前記調整部は、プロセッサである前記リソースの前記消費量が他のアプリケーションの前記消費量より小さいアプリケーションによって供給される前記リソースであって、前記プロセッサを用いて生成される情報に対する前記入札値を、前記他のアプリケーションの前記入札値より大きな値に調整すること、
を特徴とする請求項１に記載のリソース管理装置。
【請求項６】
予め定められた単位時間内に複数のアプリケーションのそれぞれが消費または供給するリソースの割り当てを入札方式で決定するリソース管理装置を、
前記入札方式における前記リソースの仮想的な価格を示す入札値を計算する入札値計算部と、
消費する前記リソースの消費量が他のアプリケーションの前記消費量より小さいアプリケーションによって供給される前記リソースに対する前記入札値を、前記他のアプリケーションの前記入札値より大きな値に調整する調整部と、
調整された前記入札値に基づいて、前記複数のアプリケーションのそれぞれに前記リソースを割り当てる入札管理部と、
として機能させるためのリソース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースを管理するための装置、およびプログラムに関する。
【背景技術】
【０００２】
従来より、センサを備えた、いわゆるリアルタイムシステムが広く利用されている。例えば、船舶、航空機、自動車などの輸送機械の分野では、周囲の状況を把握し、その把握した状況の情報を、画面表示などによってユーザに提示するセンサ情報システムが用いられている。船舶の場合のセンサ情報システムは、レーダー、ソナー、赤外線センサ、カメラなどの複数のセンサを備え、各局面に応じてそれらの１つあるいは複数のセンサの信号を解析して周囲の状況を認識し、その認識結果を画面などに表示する。周囲状況の情報は、船舶の安全な航行などに役立つものである。
【０００３】
輸送機械の分野におけるこれらのシステムでは、認識された周囲状況の情報をユーザに知らせるために、所定の時間内に画面表示などが更新されなければならない。それは、ユーザが周囲の状況を素早く把握できず、衝突などの事故につながる危険があるからである。そのため、それらのシステムは、リアルタイムシステムでなければならず、センサ信号に基づく信号処理は所定の時間制約を満たすリアルタイム処理で行なわれることが要求される。
【０００４】
従来、複数のセンサ信号の信号処理を行なうこのようなリアルタイムシステムでは、それぞれの信号は独立したサブシステムにおいて処理されるのが一般的であった。それは、それぞれの信号の信号処理に必要な中央処理装置（ＣＰＵ：Central Processing Unit）などの計算機リソースをサブシステムごとに個別に用意し、サブシステムごとに１つのリアルタイムのオペレーティングシステム（ＯＳ）を動かすなどの方法により、サブシステム単位でリソースの割当を行なうことによって、所定の時間制約を満たすセンサ情報システムの設計や開発が容易になるからである。
【０００５】
しかし、このような信号ごとに独立したサブシステムを個別に作成する方式では、ある信号を担当する１つのサブシステムにおいて過負荷、あるいはサブシステムの１つの要素に故障が生じると、たとえ他のサブシステムの計算機リソースに余裕があっても、そのサブシステムが、自己の担当する信号の処理の所定の時間制約を守れなかったり、処理がまったくできなくなったりするという問題点がある。
【０００６】
従って、これまでは、このような過負荷あるいは故障にサブシステム単体で対応できるようにするために、サブシステム毎に、機能、処理能力等において所定の余裕を持った構成を取る必要があった。しかし、このような余裕を持った構成にするためには、多大なハードウェア設備が必要となるため、設備の費用、容積、消費電力がそれぞれ増大する。その結果、センサ情報システムの商業的および技術的フィージビリティーが低下するという事態が生じている。
【０００７】
そのため、航空機の分野では、１つの計算機システムに複数の信号の信号処理を統合することによって、比較的少ないハードウェア設備でセンサ情報システムを構築するという要求がある。一般に、このようなシステムは、１つ以上のプロセッサとメモリと入出力機器とを持つノードを、ネットワークなどによって複数個結合した分散システムで実現される。
【０００８】
しかし、複数の信号の処理を１つのシステムに単純に統合すると、複数の信号の処理を行なう場合に、ある局面において、より重要な信号とあまり重要でない信号とが存在した場合、あまり重要でない信号の処理の負荷が上がったために、より重要な信号の処理の時間制約にまで影響が出るおそれがあった。
【０００９】
理論的には、システム全体で１つのリアルタイムＯＳを動かし、全体でリアルタイムスケジューリングを行なえばこのような問題を解決することはできる。しかし、現実的には多数のプロセッサを含むシステムを単一のＯＳで管理すると、スケジューリングが非常に複雑となる。そのため、スケジューリングの処理に時間が掛かって、所定の時間制約を満たす十分な性能を得ることが困難となる場合がある。さらに大きな問題として、ノード間が厳密なリアルタイム性が保証されていないネットワークにより接続されている場合、ノードを跨ったリアルタイムスケジューリングを行なうことはそもそもできないという問題がある。
【００１０】
ところで、従来より、一般に、分散システムにおけるリソース割当を分散して行なう方式として、入札によるリソース割り当てという方式が研究されている（例えば、非特許文献１参照）。
【００１１】
その入札によるリソース割り当て方式は、ＣＰＵ時間などのリソースの配分を、単位時間毎あるいはタスク毎に入札形式で行なうものである。すなわち、各アプリケーションプログラム（以下、単にアプリケーションともいう場合がある）が値段をつけた上でリソースの割り当てを要求し、もっとも高い値段をつけたアプリケーションがそのリソースの割り当てを受けて動作するように決定される。この入札の際に扱われる通貨は、ある局面であるアプリケーションがユーザにとってどれだけ重要なのかを定量化する指標であり、現実の通貨にはリンクさせる必要のない仮想的な通貨である。システム内の各モジュールが、自己が受け取る通貨から支払う通貨を差し引いた利益を最大化するように振る舞うことによって、システム全体の効率が改善されるというのが、この方式の特徴である。
【００１２】
この入札方式を用いれば、局面ごとのセンサの信号の重要性に対応したリソースの割り当てを、その重要なセンサの信号の処理を行なうアプリケーションに高い入札価格をつけることを許すことによって実現することができる。また、ノード毎にそのノードのリソースの入札処理を行なうことによって、入札処理を分散して行なえるため、リソース割り当ての分散処理が行ない易いというメリットがある。
【００１３】
単純なモデルのリソース割り当てでは、ＣＰＵ時間などの物理リソースのみがリソースであり、ＯＳやミドルウェアのプログラムがリソースの供給者となり、アプリケーションプログラムが消費者となる。しかし実際のシステムでは、より複雑なリソース割り当てモデルに基づいて、より高度な入札を行なう場合がある。
【００１４】
特に、分散システムにおけるリソース割り当てを入札方式で行なう場合、サプライチェーンモデルと呼ばれる、より高度なリソース割り当てモデルを用いる場合がある（例えば、非特許文献２）。
【００１５】
このモデルは、製造業・流通業におけるサプライチェーン（供給連鎖）を模したモデルである。このモデルでは、供給者・消費者に加えて「生産者」という概念を導入する。生産者は他者からリソースを買って、他者に売るリソースを生成する存在であり、物理リソースのほかに生産者が生成したデータなどもリソースとして扱われる。
【００１６】
生産者の概念を導入することによって複数ノードへの処理の分散や、他のアプリケーションが使うデータの前処理を行なうアプリケーションを入札モデルで扱うことができる。なお、供給者、消費者および生産者とは、それぞれシステム内のソフトウェアで実現されるモジュールプログラムを指すものであり、自然人、法人などを指すものではない。
【００１７】
一般にサプライチェーンモデルを用いた入札方式では、上記の単純なモデルと比べて入札価格の決め方が複雑になる（例えば、非特許文献２参照）。特に、生産者の場合、売るリソースの値段を決める際に、そのリソースを生成するために必要なリソースをいくらで買えるかを考慮し、売値が買値を下回る場合には入札を取り止めるといった動作を行なう必要がある。複雑な計算式を用いて一度に入札価格を決める方式もあるが、計算量が大きいため、仮の値段による複数ラウンドの入札を値段が収束するまで繰り返すのが一般的である。
【００１８】
このような複数ラウンド入札方式における生産者の入札方針(入札価格の決め方)の一例としては、はじめは売るリソースと買うリソースとも、適当な初期値で入札を行ない、売るリソースと買うリソースが落札できたかどうかによって、売値と買値を微少量だけ変化させるが、採算が取れない場合（すなわち売値が買値の合計を下回る場合）は、入札を断念する、といった入札方針が可能である。このようなラウンドを繰り返すことによって、リソースの売値と買値が適切な水準まで上がるか、あるいは入札を断念するかのどちらかの結果となり、入札価格が決定する。
【００１９】
以上はサプライチェーン入札の場合の入札方式であるが、サプライチェーン入札に限らず、たとえば複数のリソースの割り当てを同時あるいは並行して行なう複数財入札など、一般に複雑な入札を行なう場合は、複数ラウンド入札を行なう場合が多い。
【００２０】
なお、複数ラウンド入札によるリソース割り当てをリアルタイムシステムで行なう場合には、時間制約を満たすため、ラウンド数の上限を設けて打ち切る方法や、時間に上限を設けて打ち切る方法を用いる（例えば、特許文献１）。
【００２１】
【非特許文献１】アンドリュー・バイド、マシアス・セイル、クラウディオ・バルトリーニ著「ユーティリティデータセンタのための市場ベースリソース割り当て」,HPラボ・テクニカル・レポートHPL-2003-188,2003（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 Art ificial Intelligence, 1999.）
【特許文献１】特開２００８−００４０４６号公報
【発明の開示】
【発明が解決しようとする課題】
【００２２】
上記のようなリソース割り当てのための入札では、単純に価格だけで落札者を決定しているため、少ないデータ数量で入札している生産者の売値が安いと、多くの生産者のデータが細かく落札されるため、多くのノードへ処理が細かく割り当てられるケースがある。
【００２３】
たとえば、３つのノードで構成されるシステムで、各ノードがそれぞれ３つの生産者アプリケーションを実行している場合、３つのアプリケーションの処理がそれぞれ３つのノードに分散され、全体として９つの生産者がすべて動作する結果となる場合がある。
【００２４】
このような必要以上の分散によって、以下のオーバーヘッドが生じる。まず、各ノードで実行状態のプロセス数が増えることによって、メモリ、ＣＰＵキャッシュ、およびディスクキャッシュの使用量が増える。また、生産者と通信する消費者では、通信相手のノード数が増えることによって、通信セッション数が増え、ＣＰＵおよびメモリ使用量が増える。これらのオーバーヘッドによってアプリの実行速度が低下する。
【００２５】
ここで、１つのノードで処理が済む場合には、複数のノードに細かく分けるのではなく、１つのノードに処理を割り当てる方が、上記の性能低下を防ぐことができる。
【００２６】
たとえば上記の例では、１つのノードはアプリケーション１のみ、１つのノードはアプリケーション２のみ、１つのノードはアプリケーション３のみ、といった割り当てによる動作が可能であれば、全体として３つの生産者のみが動作するため、必要以上の分散による性能低下が防げる。
【００２７】
本発明は、上記に鑑みてなされたものであって、入札によりリソースを割り当てる方法において、必要以上に多くのノードに処理が分散されることによる性能低下を防止できる装置、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２８】
上述した課題を解決し、目的を達成するために、本発明は、予め定められた単位時間内に複数のアプリケーションのそれぞれが消費または供給するリソースの割り当てを入札方式で決定するリソース管理装置であって、前記入札方式における前記リソースの仮想的な価格を示す入札値を計算する入札値計算部と、消費する前記リソースの消費量が他のアプリケーションの前記消費量より小さいアプリケーションによって供給される前記リソースに対する前記入札値を、前記他のアプリケーションの前記入札値より大きな値に調整する調整部と、調整された前記入札値に基づいて、前記複数のアプリケーションのそれぞれに前記リソースを割り当てる入札管理部と、を備えることを特徴とする。
【００２９】
また、本発明は、上記装置を実行することができるプログラムである。
【発明の効果】
【００３０】
本発明によれば、必要以上に多くのノードに処理が分散されることによる性能低下を防止することができるという効果を奏する。
【発明を実施するための最良の形態】
【００３１】
以下に添付図面を参照して、この発明にかかるリソース管理する装置、およびプログラムの最良な実施の形態を詳細に説明する。
【００３２】
１．システムのハードウェア構成
まず図１に基づき、本実施の形態に係わるシステムのハードウェア構成を説明する。図１は、本実施の形態に係わるセンサ情報処理システム（以下、センサ情報システムという）のハードウェア構成を示す構成図である。本実施の形態に関わるセンサ情報システムは、船舶、航空機等に用いられる。センサ情報システムは、ここでは、レーダー装置とソナー装置からのセンサ信号に基づいて、周囲の状況をセンサ情報として乗組員等に知らせるシステムである。センサ情報システムは、特にかつ危険な障害物等を検知した場合に、すばやく、すなわちその検知をしてから所定の時間内に乗組員等にそのセンサ情報を画面表示等により告知する、いわゆるリアルタイムシステムである。なお、リアルタイムシステムとは、所定の時間内に所定の処理が実行される、例えば、センサ信号を検知してから所定の時間としての１秒以内に、表示装置の画面上に所定のセンサ情報を表示する処理が実行されるようなシステムをいう。
【００３３】
センサ情報システム１は、複数のノード、ここでは２つのノード２、３がネットワーク４を介して接続されて構成されている。ノード２には、レーダー装置５と端末装置６とが接続されている。ノード２は、所定の信号処理を行い、信号処理の結果を端末装置６の表示装置６ａの画面上に表示する処理を行うコンピュータ装置である。後述するように、ノード２は、レーダー装置５とソナー装置７のそれぞれの信号に基づいて所定の信号処理を行う信号処理アプリケーションプログラム（以下、アプリケーションプログラムを単にアプリケーションということもある）と、レーダー装置５の信号に関する信号処理の結果を表示装置６ａに表示するために情報表示アプリケーションプログラムとを含む。
【００３４】
ノード３には、ソナー装置７と端末装置８とが接続されている。ノード３は、所定の信号処理を行い、信号処理の結果を端末装置８の表示装置８ａの画面上に表示する処理を行うコンピュータ装置である。後述するように、ノード３は、ソナー装置７とレーダー装置５のそれぞれの信号に基づいて所定の信号処理を行う信号処理アプリケーションプログラムと、ソナー装置７の信号に関する信号処理の結果を表示装置８ａに表示するために情報表示アプリケーションプログラムとを含む。
【００３５】
また、後述するように、レーダー装置５のセンサ信号は、ネットワーク４を介して、ノード３へ送信され、ソナー装置７のセンサ信号も、ネットワーク４を介して、ノード２へ送信されるように構成されている。
【００３６】
ノード２は、端末装置６の表示装置６ａの画面上に、レーダー情報を表示し、ユーザに対してレーダー装置５のセンサ信号に関する情報を、いわゆるリアルタイムで提示することができる。同様に、ノード３は、端末装置８の表示装置８ａの画面上に、ソナー情報を表示し、ユーザに対してソナー装置７のセンサ信号に関する情報を、いわゆるリアルタイムで提示することができる。
【００３７】
従って、本実施の形態では、レーダー装置５とソナー装置７という２つのセンサ装置からのセンサ情報の情報処理は、２つのノード２、３において行なわれ、処理結果であるレーダー情報とソナー情報が、それぞれの端末装置６、８の表示装置６ａ、８ａの画面上にリアルタイムで表示される。例えば、船舶の場合であれば、障害物がレーダー装置５で検知されるとその障害物の位置情報等がセンサ情報として画面上にリアルタイムで表示される。
【００３８】
ノード２は、２つの中央処理装置（以下、ＣＰＵと略す）２１、２２、メモリ２３、ネットワークインターフェース（以下、ネットワークＩ／Ｆと略す）２４、レーダー装置インターフェース（以下、レーダー装置Ｉ／Ｆと略す）２５、および端末装置インターフェース（以下、端末装置Ｉ／Ｆと略す）２６を含んで、お互いにバス２７を介して接続されて構成されている。
【００３９】
同様に、ノード３は、２つのＣＰＵ３１、３２、メモリ３３、ネットワークＩ／Ｆ３４、ソナー装置インターフェース（以下、ソナー装置Ｉ／Ｆと略す）３５、および端末装置Ｉ／Ｆ３６を含んで、お互いにバス３７を介して接続されて構成されている。
【００４０】
なお、バス２７、３７は、各ノードの基板間あるいは基板上の配線でもよいし、チップ内部の配線であってもよい。ネットワークＩ／Ｆ２４と３４は、それぞれノード２と３とをネットワーク４と接続するためのインターフェースである。端末装置Ｉ／Ｆ２６と３６は、それぞれノード２と３とをそれぞれの端末装置６と８と接続するためのインターフェースである。レーダー装置Ｉ／Ｆ２５を介して、ノード２とレーダー装置５とは接続されている。ソナー装置Ｉ／Ｆ３５を介して、ノード３とソナー装置７とは接続されている。
【００４１】
ネットワーク４は、リアルタイム性が保証されるネットワークでも、イーサネット（登録商標）などのリアルタイム性が保証されないネットワークでもよい。
【００４２】
なお、図１では、レーダー装置５とソナー装置７は、それぞれインターフェースを介して、ノード２と３に接続されているが、ネットワークインターフェースを内蔵して、ネットワーク４に直接接続されるようにしてもよい。その場合、レーダー装置５とソナー装置７からの信号は、ネットワーク４を介して、それぞれノード２と３に伝達される。
【００４３】
さらになお、上述した説明では、端末装置６と８がそれぞれノード２と３に接続されているが、図１の一点鎖線で示すように、端末装置６と８に代えて、あるいは端末装置６と８に加えて、さらにネットワーク４に接続された別の端末装置９を設けてもよい。端末装置６と８に代えて端末装置９を設けた場合は、端末装置９の表示装置９ａ上に、レーダー情報とソナー情報を表示するようにし、あるいは端末装置６と８に加えて端末装置９を設けた場合は、端末装置９の表示装置９ａ上にのみ、あるいは端末装置９の表示装置９ａ上にも併せて、レーダー情報とソナー情報を表示するようにしてもよい。
【００４４】
また、図示はしないが、センサ情報システム１には、表示装置、キーボードなどを備えた端末装置が１つ以上存在し、ノード２と３のうち１つに接続されている。
【００４５】
２．システムのソフトウェア構成
次に、図２に基づき、ノード２と３のソフトウェア構成を説明する。図２は、本実施の形態における、ノード２と３におけるソフトウェア構成のリソース管理の部分を説明するためのブロック図である。
【００４６】
ノード２と３は、レーダー信号とソナー信号の信号処理と、レーダー情報表示あるいはソナー情報表示の表示処理とを実行するアプリケーション実行装置であるが、ＣＰＵ時間等のリソースを管理するリソース管理装置でもある。すなわち、ノード２と３は、レーダー信号とソナー信号に基づく信号処理を行い、その処理結果をレーダー情報あるいはソナー情報として、端末装置６と８の表示装置６ａと８ａにリアルタイムで表示するセンサ情報処理を行うが、そのようなリアルタイムのセンサ情報の処理のためにリソース管理も行っている。その意味で、ノード２と３は、リソース管理装置を構成し、リソース管理装置は、アプリケーションプログラムを各ノード上で実行するために動作するソフトウェアプログラムにより、主として実現されるコンピュータ装置である。
【００４７】
ノード２において、１つのＯＳ４１は、ハードウェアである２つのＣＰＵ２１、２２上で動作する。ＯＳ４１は、マルチプロセッサ対応のＯＳであり、例えば、ウインドウズ（登録商標）、リナックス（登録商標）等のＯＳである。ＯＳ４１の上には、物理リソースマネージャ４２が設けられており、リソースとしてのＣＰＵ時間を管理する。
【００４８】
物理リソースマネージャ４２を介して、レーダー信号処理部であるレーダー信号処理ＡＰ（アプリケーション）４３、ソナー信号処理部であるソナー信号処理ＡＰ（アプリケーション）４４およびレーダー情報表示部であるレーダー情報表示ＡＰ（アプリケーション）４５の、３つのアプリケーションプログラムが、ＯＳ４１上で動作する。
【００４９】
ノード３においても、１つのＯＳ５１は、ハードウェアである２つのＣＰＵ３１、３２上で動作する。ＯＳ５１も、マルチプロセッサ対応のＯＳである。ＯＳ５１の上には、物理リソースマネージャ５２が設けられており、リソースとしてのＣＰＵ時間を管理する。
【００５０】
物理リソースマネージャ５２を介して、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４およびソナー情報表示アプリケーション５５の、３つのアプリケーションプログラムが、ＯＳ５１上で動作する。
【００５１】
物理リソースマネージャ４２、５２は、各アプリケーションプログラムを実行する場合に、後述するように、各アプリケーションからの入札に対して、所定の処理を行い、各アプリケーションが落札したＣＰＵ時間だけ、各アプリケーションを実行させるように、ＣＰＵ時間を管理する。
【００５２】
リソース管理装置が動作する各ノードは、１つのＯＳ４１、５１によりソフトウェアおよびハードウェアが管理される。本実施の形態では、各ノードには２つのＣＰＵが存在するが、１つのノードに複数のＣＰＵが存在する場合でも、マルチプロセッサ対応のＯＳが１つ動作し、各ノード全体のリソースをそのＯＳが管理する。物理リソースの管理は、各ＯＳの上で動作するミドルウェアとして実現される物理リソースマネージャ４２、５２により行われる。なお、物理リソースマネージャ４２、５２は、ＯＳ内部の機能として実現されていてもよい。
【００５３】
リソース管理装置は、複数のリソース応札部と複数の入札管理部とを含んで構成される。具体的には、ノード２において、物理リソースマネージャ４２は、リソース応札部４２ａと、入札管理部４２ｂとを有する。
【００５４】
レーダー信号処理アプリケーション４３は、リソース応札部４３ａを含む。ソナー信号処理アプリケーション４４は、リソース応札部４４ａを含む。レーダー情報表示アプリケーション４５は、リソース応札部４５ａと、入札管理部４５ｂとを有する。同様に、ノード３において、物理リソースマネージャ５２は、リソース応札部５２ａと、入札管理部５２ｂとを有する。レーダー信号処理アプリケーション５３は、リソース応札部５３ａを含む。
【００５５】
ソナー信号処理アプリケーション５４は、リソース応札部５４ａを含む。ソナー情報表示アプリケーション５５は、リソース応札部５５ａと、入札管理部５５ｂとを有する。すなわち、各リソース応札部４２ａ、４３ａ、５２ａ、５３ａ等は、リソースの供給または消費を行なうモジュールである処理部（ここでは、物理リソースマネージャ４２、５２およびレーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４等）の内部に設けられている。
【００５６】
なお、一部のアプリケーションのみにリソース応札部を設けるようにしてもよい。例えば、リソースをあまり消費しないアプリケーションには、入札への参加を省略すべくリソース応札部を設けず、逆に、リソースを大量に消費するアプリケーションのみにリソース応札部を設けるようにする、といった構成でもよい。この場合、入札へ参加しないアプリケーションが消費するリソースは、ある程度余裕を持つようにするなどの方法で、別途固定的に割り当てておく必要がある。
【００５７】
一方、入札管理部は、ノード毎に、全体で１つ設けてもよいし、複数設けてもよい。また、入札管理部は、独立したミドルウェアやＯＳ内部の機能として実現してもよいし、あるいは、いずれかの処理部の内部で実現してもよい。一般に、供給者が１つで消費者が複数の場合は供給者の内部で実現し、供給者が複数で消費者が１つの場合は消費者の内部で実現すると入札の際の処理や通信が簡単になる。そこで、本実施の形態では、物理リソースマネージャ４２、５２（供給者）は、複数のアプリケーション（消費者）にＣＰＵ利用率を供給するだけであるので、物理リソースマネージャ４２、５２の内部に入札管理部４２ｂ、５２ｂを設けている。そして、センサ情報表示アプリケーション（消費者）は、複数のアプリケーション（供給者、生産者）から、ＣＰＵ利用率とセンサ情報を受けるだけであるので、センサ情報表示アプリケーション内部に入札管理部４５ｂ、５５ｂが設けられている。例えば、ノード２では、物理リソースマネージャ４２内部に入札管理部４２ｂが設けられ、そしてレーダー情報表示アプリケーション４５内部に入札管理部４５ｂが設けられている。
【００５８】
３．リソースの供給と消費
３．１  リソース
ここで、リソースについて説明する。本実施の形態は、物理リソースであるＣＰＵ利用率に加えて、アプリケーションプログラムが生成したデータもリソースとして扱う、サプライチェーンモデルに基づく例である。
【００５９】
データもリソースとして扱うのは、次の理由による。すなわち、各センサ信号の信号処理部と各センサ情報の情報表示部とが分離されているため、センサ情報をリソースとして扱わずにＣＰＵ利用率のみをリソースとして扱うと、センサ情報の供給と消費関係を無視したリソースの割り当てが生じるおそれがある。例えば、ソナー信号処理アプリケーション４４、５４にＣＰＵ利用率が割り当てられて実行されるが、ソナー情報表示アプリケーション５５にはＣＰＵ利用率が割り当てられずに実行ができないという状況があり得る。その場合、利用されないセンサ情報を生成するためにＣＰＵが浪費される、といった状態が生じる。このような状態が生じないようにしながら、各信号処理部と各情報表示部とを分離できるようにするために、ＣＰＵ利用率に加えてデータもリソースとして扱われている。
【００６０】
なお、ＣＰＵ利用率は、後述する単位処理時間当たりにおける、そのアプリケーションが使用する割合（％）である。例えば、単位処理時間が、１秒で、ＣＰＵ利用率が３０％であれば、そのアプリケーションは、３００ｍｓだけＣＰＵを使用できることを意味する。本実施の形態では、ＣＰＵ利用率（％）を用いるが、ＣＰＵ使用時間（ｍｓ等）を用いてもよい。また、データは、本実施の形態では、レーダー情報とソナー情報である。
【００６１】
図３は、本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。図３に示すように、本実施の形態のサプライチェーンモデルにおいて、物理リソースマネージャ４２、５２は、供給者に対応し、レーダー信号処理アプリケーション４３、５３とソナー信号処理アプリケーション４４、５４は、生産者に対応し、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５は消費者に対応する。
【００６２】
リソースの供給のみを行う供給者である物理リソースマネージャ４２、５２は、物理リソースであるＣＰＵ利用率の管理を行なうミドルウェアである。なお、物理リソースマネージャ４２、５２は、ＯＳの一部として、ＯＳの中に組み込まれたものであってもよい。
【００６３】
ＣＰＵ利用率は、供給者である物理リソースマネージャ４２、５２から、各アプリケーションに供給される。図３の場合、ＣＰＵ利用率は、物理リソースマネージャ４２から、レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４およびレーダー情報表示アプリケーション４５に供給される。物理リソースマネージャ５２から、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４およびソナー情報表示アプリケーション５５に供給される。
【００６４】
生産者であるレーダー信号処理アプリケーション４３、５３およびソナー信号処理アプリケーション４４、５４は、それぞれ、ＣＰＵ利用率を消費して所定のセンサ情報を生成して、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５に供給する。すなわち、アプリケーションのうちセンサ信号処理アプリケーションは、センサ情報を供給する生産者である。
【００６５】
消費者であるレーダー情報表示アプリケーション４５およびソナー情報表示アプリケーション５５は、ＣＰＵ利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない。すなわち、アプリケーションのうち情報表示アプリケーションは、ＣＰＵ利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない消費者である。
【００６６】
アプリケーションである各処理部は、自己が消費する全てのリソースが落札できた場合のみ動作する。なお、各信号処理部は、ノード２、３間の負荷分散のため両方のノードに存在するが、いずれか一方のみが実行されれば、センサ情報は生成される。例えば、レーダー情報表示アプリケーション４５は、ＣＰＵ利用率が割り当てられ、かつレーダー信号処理アプリケーション４３と５３のいずれか一方からレーダー情報の供給を受ければ、実行される。
【００６７】
３．２  リソースの供給方法
リソースの供給について説明する。リソースの供給のうち、データであるセンサ情報の供給は、信号処理アプリケーションが、実際にセンサ情報表示アプリケーションに、センサ情報を供給することによって行なわれる。例えば、レーダー信号処理アプリケーション４３が、信号処理の結果得られたレーダー情報を、レーダー情報表示アプリケーション４５に供給することが、センサ情報の供給となる。
【００６８】
一方、ＣＰＵ利用率の供給は概念上のものであって、明示的な受渡しはなく、アプリケーションプログラム作成の際に、ＣＰＵ利用率を落札できた場合のみＣＰＵを利用して実行されるようにそのプログラムを作成することによって実現される。なお、アプリケーションが第三者によって作成された場合など、アプリケーションの実際の挙動が信用できない場合には、アプリケーションが実際に落札した分のＣＰＵ利用率しか使用していないかを、物理リソースマネージャ４２、５２がＯＳの状態を監視するなどの方法でチェックするようにしてもよい。その場合、落札された以上のＣＰＵ利用率を使用していた場合は、そのアプリケーションを割り込み処理により強制終了したりすることによって、ＣＰＵ利用率の割り当てを強制的に守らせるようにすることも可能である。以上のリソースの割り当てが、リソース管理装置の入札によって行なわれる。
【００６９】
３．３  リソース割り当ての決定方法
（ａ）ＣＰＵ利用率
まず、物理リソースであるＣＰＵ利用率の消費量および供給量の決定方法について述べる。各アプリケーションは、処理単位時間ごとにそのアプリケーションが使用するＣＰＵ利用率、すなわち消費量を計算し、明示あるいは決定する。その決定は、アプリケーション作成者がアプリケーションのソースコード中に数値または計算式を明示的に記述することで行なってもよいし、コンパイラがコンパイル時に判定することで行なってもよい。さらに、各アプリケーションが、自己が実行された時に物理リソースマネージャ４２、５２やＯＳの状態を監視するなどの方法で実測し、測定履歴から今後の物理リソース使用量を推定するといった方法で行なってもよい。
【００７０】
物理リソースマネージャ４２、５２は、アプリケーションに供給できるリソースの供給量を計算する。本実施の形態では、ＣＰＵ台数分の全利用時間に対する割合を示すパーセンテージからＯＳやミドルウェアの動作や安全のためのマージンを差し引いた値がアプリケーションへの供給量である。本実施の形態では、各ノードは、ＣＰＵ２台分にあたる２００％からマージン２０％を差し引いた１８０％を供給量とする。
【００７１】
（ｂ）センサ情報
次に、センサ情報の消費量および供給量の決定方法について述べる。物理リソース以外のリソースであるセンサ情報は、アプリケーション作成者がアプリケーションのソースコード中にアプリケーションのロジックの一部として数値または計算式を明示的に記述することによって消費量および供給量が指定される。
【００７２】
例えば、ソナー信号処理アプリケーション４４は、センサ装置であるソナー装置７から所定のサンプリング周期でセンサ信号を受けるので、そのセンサ信号の量（ビットレート等）が消費量となる。また、ソナー信号処理アプリケーション４４は、所定の信号処理を行って、センサ情報をソナー情報表示アプリケーション５５に供給するので、そのセンサ情報の量（ビットレート等）が供給量となる。
【００７３】
また、後述するように、入札に基づいて消費量と供給量は変化するが、各ノードでは、各ノードに供給されるセンサ信号量に応じてＣＰＵ利用率も変化する。例えば、ノード２では、ノード２に供給されるセンサ信号量に応じてＣＰＵ利用率は変化し、同様にノード３でも、ノード３に供給されるセンサ信号量に応じてＣＰＵ利用率は変化する。従って、例えばレーダー装置５から出力されるセンサ信号の全量は、ノード２とノード３に、それぞれ分担され、各ノードは、その分担された量に対応したＣＰＵ利用率が必要となる。
【００７４】
（ｃ）リソース割り当ての通知
各処理部において、以上の手順で決定あるいは指定された消費量または供給量は、処理部の内部に実現されたリソース応札部に通知される。リソース応札部は、その消費量または供給量に対応する入札を入札管理部に対して行なう。
【００７５】
４．リソース管理装置の構成
４．１  リソース管理装置
図４は、リソース管理装置を構成するリソース応札部と入札管理部の構成を示すブロック図である。
【００７６】
本実施の形態におけるリソース管理装置１０１は、複数のリソース応札部１０２と複数の入札管理部１０３を含んで構成される。図４は、各アプリケーションのリソース応札部１０２と、対応する入札管理部１０３との関係を示すために、１つのリソース応札部１０２と、１つの入札管理部１０３との間でのデータの流れを示す。
【００７７】
例えば、ノード２の場合、ＣＰＵ利用率については、リソース応札部４２ａ、４３ａ、４４ａ、４５ａのそれぞれが、リソース応札部１０２に対応し、入札管理部４２ｂが、入札管理部１０３に対応する。レーダー情報のデータについては、レーダー信号処理アプリケーション４３のリソース応札部４３ａ（および５３ａ）、４５ａが、リソース応札部１０２に対応し、入札管理部４５ｂが、入札管理部１０３に対応する。
【００７８】
リソース応札部１０２は、入札値計算部１０４と、ＣＰＵ価格調整部１０４１と、最終入札値記憶部１０５とを含む。入札管理部１０３は、落札者決定部１０６と、ラウンド繰り返し管理部１０７とを含む。
【００７９】
次に、リソース管理装置１０１の各構成要素の詳細な動作について述べる。
【００８０】
４．２  リソース応札部
まず、リソース応札部１０２の処理について述べる。リソース応札部１０２は、前述の判定によって得られた消費量または供給量のリソースを入札管理部１０３に対して入札する、すなわち自己のリソースの情報の提供を行う。入札は、リソース応札部１０２が入札管理部１０３に対して複数回すなわち複数ラウンドにわたる入札を行なうことによって行なわれる。
【００８１】
各ラウンドでは、入札値計算部１０４が入札価格としての入札値を計算する。入札価格としての入札値の計算にあたっては、その価格でリソースを売買することによる処理部の利益が最大化するような価格をつけなければならない。
【００８２】
入札値計算部１０４の具体的動作は、処理部が供給者、生産者および消費者のいずれであるかによって異なる。以下、それぞれの場合について説明する。図１６および図１７は、ラウンドが経過するにつれて、ＣＰＵ利用率とデータの入札と落札の量と値が変化する例を示す表である。図１６では、ＣＰＵ利用率についてのノード２と３における各処理部における入札量、入札値、落札量および落札値が示され、図１７では、データについての各処理部における入札量、入札値、落札量および落札値とが示されている。図１６および図１７の各部において並んだ数字は、左から順に、入札量、入札値、落札量および落札値が示されている。以下、図１６および図１７を参照しながら説明する。
【００８３】
（ａ）供給者の場合
供給者は、自己が供給できるリソースを売り惜しむ必要はないので、どれだけ安い値段であっても最大限リソースが売れるような入札を行なえばよい。従って、供給者の入札値計算部１０４は、固定の入札値を常に返せばよい。本実施の形態では供給者である物理リソースマネージャ４２、５２はＣＰＵ利用率を常に価格０で入札するものとする。このため供給者の場合には、最終入札値記憶部１０５は省略してよい。
【００８４】
図５は、供給者の入札値計算部１０４の処理の流れの例を示すフローチャートである。入札値計算部１０４は、所定の入札価格、ここでは常に例えば固定の「０」を、入札値とする（ステップＳ１）。
【００８５】
（ｂ）生産者の場合
生産者は、高い値段でリソースが売れる場合には、そのリソースの生成のために高い値段でリソースを買ってよい一方で、どうしても売値が買値を下回る場合は、売買を止める必要がある。このため生産者の入札値計算部１０４は以下のような処理を行なう。
【００８６】
はじめのラウンドでは、入札値計算部１０４は、最終入札値記憶部１０５に記録された値を入札値として採用する。なお、最終入札値記憶部１０５には初期値として０が記録されている。２回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたか否かによって入札値の調整を行う。
【００８７】
入札値計算部１０４は、自己の供給するリソース（例えば、レーダー信号処理アプリケーション４３であれば、レーダー情報というデータ）については、自己が消費するリソース（例えば、レーダー信号処理アプリケーション４３であれば、ＣＰＵ利用率）の入札値（買値）の合計の予測値を入札値（売値）として入札を行なう。自己が消費するリソースの入札値（買値）の予測値は、たとえば前回のラウンドでの自己が消費するリソースの落札値（必ずしもその処理部が落札できた値ではなく、その処理部が落札できなかった場合には他の処理部の落札値）の合計を求めるという方法で計算される。自己が消費するリソースについては、そのリソースが前回のラウンドで十分に落札できていなければ、そのリソース入札値を所定量だけ上げる、といった方法で計算される。
【００８８】
図６は、生産者が供給するリソースについての入札値計算部１０４の処理の流れの例を示すフローチャートである。図６の処理は、入札処理における各ラウンドが開始する直前に、レーダー信号処理アプリケーション４３が実行して、ラウンド毎に入札値を決定する。その決定された入札値は、入札管理部１０３へ供給される。
【００８９】
まず、入札値計算部１０４は、ＣＰＵ利用率の前回の落札量が、レーダー情報の落札量から計算したＣＰＵ利用率の必要量未満であったか否かを判定する（ステップＳ１１）。ＣＰＵ利用率の前回の落札量が、レーダー情報の落札量から計算したＣＰＵ利用率の必要量未満であった場合は（ステップＳ１１：ＹＥＳ）、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上か否かを判定する（ステップＳ１２）。
【００９０】
なお、図１６および図１７は、レーダー情報を「１００」生成するのに、レーダー信号処理アプリケーション４３は、ＣＰＵ利用率が「１３５」必要な場合の例である。
【００９１】
ステップＳ１１でＹＥＳとなるのは、ノード２のレーダー信号処理アプリケーション４３のラウンド５において、ＣＰＵ利用率については、図１６においては落札量が「４８」であるのに対して、図１７においては、レーダー情報の落札量「９１」の場合である。この場合、レーダー情報の落札量「９１」から計算したＣＰＵ利用率が「１２３」で、ＣＰＵ利用率の落札量が「４８」以上の場合である。
【００９２】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上である場合は（ステップＳ１２：ＹＥＳ）、処理はステップＳ１３へ移行する。ステップＳ１２でＹＥＳの場合は、いわゆる採算が取れている（すなわち売値が買値を上回っている）ことを意味とする。
【００９３】
ノード２のレーダー信号処理アプリケーション４３のラウンド１９において、ＣＰＵ利用率については、図１６においては落札量が「７４」で落札値が「０」で積が「０」に対して、レーダー情報については、図１７においては落札量が「５５」で落札値が「３７」で積が「２０３５」となっているような場合である。
【００９４】
ステップＳ１２でＹＥＳの場合は、レーダー信号処理アプリケーション４３のＣＰＵ利用率を上げてもよいので、入札値計算部１０４は、ＣＰＵ利用率の入札値を、所定量である微少量（ｄ１）だけ加算する（ステップＳ１３）。加算する微少量は、ここでは「４」である。図１６においては、ノード２のレーダー信号処理アプリケーション４３のラウンド１９から２０にかけて、入札値が、「７４」から「７８」に増加されているような場合である。
【００９５】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上でない場合は（ステップＳ１２：ＮＯ）、レーダー信号処理アプリケーション４３のレーダー情報の入札量を下げるために、入札値計算部１０４は、レーダー情報の入札量を、所定量である微少量（ｄ２）だけ減算する（ステップＳ１４）。ステップＳ１２でＮＯの場合は、いわゆる採算が取れていないことを意味とする。
【００９６】
ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、ＣＰＵ利用率については、図１６に示すように落札量が「７８」で落札値が「２８」でそれらの積が「２１８４」となる。これに対して、レーダー情報については、図１７において落札量が「３０」で落札値が「３７」でそれらの積が「１１１０」となっている。そのような場合に、レーダー信号処理アプリケーション４３は、ラウンド１８から１９にかけて、レーダー情報の入札量を「５８」から「５５」に下げているような場合である。
【００９７】
そして、入札値計算部１０４は、変更されたＣＰＵ利用率の入札量を、レーダー情報の入札量から計算する（ステップＳ１５）。入札値計算部１０４からＣＰＵ価格調整部１０４１へＣＰＵ利用率の入札値が渡され、ＣＰＵ価格調整部１０４１によって調整済ＣＰＵ利用率価格が計算される（ステップＳ１６）。ＣＰＵ価格調整部１０４１による調整済ＣＰＵ利用率価格の算出方法の詳細については後述する。
【００９８】
そして、入札値計算部１０４は、調整済ＣＰＵ利用率価格と入札量との積を、レーダー情報の入札量で除算することによって、レーダー情報の入札値を計算する（ステップＳ１７）。
【００９９】
ステップＳ１１で、ＣＰＵ利用率の前回の落札量が、レーダー情報の落札量から計算したＣＰＵ利用率の必要量未満でない場合（ステップＳ１１：ＮＯ）、すなわち、レーダー情報を処理するのに必要なＣＰＵ利用率が確保できている場合は、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上か否かを判定する（ステップＳ１８）。
【０１００】
なお、ステップＳ１１でＮＯとなるのは、図１６に示すように、ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、ＣＰＵ利用率については、落札量が「７８」であるのに対して、図１７に示すようにレーダー情報の落札量が「３０」の場合である。この場合、レーダー情報の落札量「３０」に対応する必要なＣＰＵ利用率は「４１」となり、ＣＰＵ利用率の落札量が「７８」よりも小さい。
【０１０１】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上の場合（ステップＳ１８：ＹＥＳ）、すなわち、いわゆる採算が取れている場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を上げるために、レーダー情報の入札量を、所定量である微少量（ｄ３）だけ加算する（ステップＳ１９）。
【０１０２】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上でない場合（ステップＳ１８：ＮＯ）、すなわち、いわゆる採算が取れていない場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を下げるために、レーダー情報の入札量を、所定量である微少量（ｄ４）だけ減算する（ステップＳ２０）。
【０１０３】
その後、入札値計算部１０４がステップＳ１５の処理を実行し、ＣＰＵ価格調整部１０４１がステップＳ１６の処理を実行したのち、入札値計算部１０４がステップＳ１７の処理を実行する。
【０１０４】
次に、ステップＳ１６の調整済ＣＰＵ利用率価格の算出方法の詳細について図７を用いて説明する。図７は、ＣＰＵ価格調整部１０４１による調整済ＣＰＵ利用率価格の算出処理の流れの例を示すフローチャートである。
【０１０５】
まず、ＣＰＵ価格調整部１０４１は、入札値計算部１０４からＣＰＵ利用率の入札値および入札量を入力する（ステップＳ７０１）。次に、ＣＰＵ価格調整部１０４１は、定数をＣＰＵ利用率の入札量で除算した値を、ＣＰＵ利用率の入札値に加えることにより、調整済ＣＰＵ利用率価格を算出する（ステップＳ７０２）。最後に、ＣＰＵ価格調整部１０４１は、算出した調整済ＣＰＵ利用率価格を入札値計算部１０４へ送出し（ステップＳ７０３）、処理を終了する。
【０１０６】
（ｃ）消費者の場合
消費者は、その局面すなわち状況におけるそのアプリケーションの重要度に対応した買値の上限値の範囲内で、自己が消費するリソースを買って処理動作を行なう。各アプリケーションの重要度は、状況に応じて変更可能である。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、アプリケーションが局面を認識して計算してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。
【０１０７】
本実施の形態では、レーダー情報がソナー情報よりも重要であると仮定して、レーダー情報表示アプリケーション４５のリソースの買値の合計の上限値を「２０００００」、ソナー情報表示アプリケーション５５のリソースの買値の合計の上限値を「１０００００」とし、その範囲内でリソースが買えなければ単位時間のリソース購入を断念するものとする。従って、センサ信号の重要度が反映された入札が行われる。
【０１０８】
入札値計算部１０４は、はじめのラウンドでは、最終入札値記憶手段に記録された値を入札値として採用する。なお、最終入札値記憶手段には初期値として「０」が記録されている。２回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたか否かによって入札値の調整を行なう。
【０１０９】
図８は、消費者の入札値計算部１０４の処理の流れの例を示すフローチャートである。まず、入札値計算部１０４は、ＣＰＵ利用率の落札量が、ＣＰＵ利用率の必要量未満であるか否かを判定する（ステップＳ２１）。
【０１１０】
その必要量は、ここでは固定値である。例えば、図１６では、ノード２のレーダー情報表示アプリケーション４５のＣＰＵ利用率の必要量は「６０」であり、図１６では、結果として落札量が「６０」となっている。
【０１１１】
ＣＰＵ利用率の落札量が、ＣＰＵ利用率の必要量未満である場合（ステップＳ２１：ＹＥＳ）、入札値計算部１０４は、ＣＰＵ利用率の入札値を、所定量である微少量（ｄ５）だけ増加する（ステップＳ２２）。
【０１１２】
そして、入札値計算部１０４は、ＣＰＵ利用率の入札値にＣＰＵ利用率の入札量を乗算した乗算値を上限値から減算し、その減算値を、レーダー情報の入札量で除算して、レーダー情報の入札値を計算する（ステップＳ２３）。すなわち、ＣＰＵ利用率の入札値にＣＰＵ利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、レーダー情報の入札値が決定される。
【０１１３】
ＣＰＵ利用率の落札量がＣＰＵ利用率の必要量以上の場合は（ステップＳ２１：ＮＯ）、入札値計算部１０４は、レーダー情報の落札量がレーダー情報の必要量以上であるか否かを判定する（ステップＳ２４）。
【０１１４】
レーダー情報の必要量は、ここでは固定である。例えば、ノード２のレーダー情報表示アプリケーション４５のレーダー情報の必要量は「１００」であり、図１７では、結果として落札量が「１００」となっている。
【０１１５】
レーダー情報の落札量がレーダー情報の必要量以上の場合は（ステップＳ２４：ＹＥＳ）、入札値計算部１０４は、レーダー情報の入札値を、所定量の微少量（ｄ６）だけ加算して増加する（ステップＳ２５）。レーダー情報により高い入札値を付けることにより、結果として、ＣＰＵ利用率には、より低い入札値を付けるためである。
【０１１６】
すなわち、入札値計算部１０４は、レーダー情報の入札値にレーダー情報の入札量を乗算した乗算値を上限値から減算し、その減算値を、ＣＰＵ利用率の入札量で除算して、ＣＰＵ利用率の入札値を計算する（ステップＳ２６）。すなわち、ＣＰＵ利用率の入札値にＣＰＵ利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、ＣＰＵ利用率の入札値が決定される。
【０１１７】
なお、ステップＳ２４で、レーダー情報の落札量がレーダー情報の必要量以上でない場合は（ステップＳ２４：ＮＯ）、入札値計算部１０４は処理を終了する。
【０１１８】
４．３  入札管理部
次に、入札管理部１０３の処理について述べる。入札管理部１０３は、各リソース応札部１０２からの入札、すなわち応札情報に基づき、いずれの処理部がリソースを落札するかを決定し、落札結果を各処理部のリソース応札部１０２に通知する。落札結果情報には、その処理部が落札できたか否かの情報と、落札値（必ずしもその処理部が落札できた価格ではなく、その処理部が落札できなかった場合には他の処理部の落札価格となる）の情報とが含まれている。
【０１１９】
落札結果情報を受け取った各処理部のリソース応札部１０２は、その結果にもとづいて処理単位時間の動作を行なう。消費するリソースを最終的に落札できた処理部は、そのリソースを消費する動作を行なう。通常、ある処理単位時間に消費するリソースを全て落札できなかった処理部は、その処理単位時間内に処理を行なわずにいわゆる休眠状態に入る。しかし、消費するリソースの一部が落札できなくてもなんらかの動作が可能な場合は、その処理部は、その分だけの処理動作を行なう。一方、供給できるリソースが落札されなかった処理部は、次の処理単位時間ではそのリソースの供給を行なわない。
【０１２０】
物理リソースであるＣＰＵ利用率の場合、各アプリケーションは、ＣＰＵ利用率を落札したときは、次の処理単位時間においてその落札の結果得られた時間だけ、ＣＰＵを利用した所定の処理を実行する。物理リソース以外のリソースであるデータの場合は、各アプリケーションは、データを落札したときは、落札量に応じたそのデータの供給を受ける。
【０１２１】
例えば、レーダー信号処理アプリケーション４３は、その落札の結果得られたＣＰＵ時間だけ、実行される。なお、上述したように、レーダー情報表示アプリケーション４５は、ＣＰＵ利用率の落札と、データの落札（レーダー信号処理アプリケーション４３あるいは５３のいずれかからの落札）の、両方が落札されたときに、落札の結果得られたＣＰＵ時間だけ、落札の結果得られたデータを用いて、実行される。
【０１２２】
（ａ）ラウンド管理
ここで、ラウンドについて説明する。本実施の形態では、ラウンド数すなわち繰り返し回数が入札の打ち切り条件である。すなわち、所定のラウンド数を超えて、入札処理が行われないように管理されている。すなわち、入札管理部１０３のラウンド繰り返し管理部１０７が、各処理単位時間におけるラウンド数をカウントし、所定の回数だけ落札者決定が行われるように監視して管理している。
【０１２３】
図９は、ラウンド繰り返し管理部１０７により、入札処理が所定回数しか行われないことを説明するための説明図である。
【０１２４】
図９に示すように、リソース応札部１０２は、最初に、前回の最終入札値を最終入札値記憶部１０５から読み出して、その最終入札値を用いて入札値を計算し、入札を行う（入札（１））。その入札に対しては、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（１））。この落札（１）に応じて、次の（すなわち２回目の）入札値計算が行われ、入札が再度行われる（入札（２））。その入札（２）に対しても、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（２））。さらに、その落札に対しても再度入札が行われ（入札（３））、落札処理が行われる。なお、１回目と２回目のときは、ラウンド繰り返し管理部１０７から落札者決定部１０６へ、後述する打ち切り通知は出力されない。
【０１２５】
このように、１回の入札に対する落札の処理を１ラウンドとして、ラウンド繰り返し管理部１０７は、入札の入力あるいは落札結果の出力があったときには、ラウンド数をインクリメントして、ラウンド数をカウントする。
【０１２６】
ラウンド数が、所定の数になると、ラウンド繰り返し管理部１０７はラウンド数が所定の数になったことを検出する。その検出結果は、落札者決定部１０６に、打ち切り通知として通知される。落札者決定部１０６は、打ち切り通知の情報をリソース応札部１０２に通知する。打ち切り通知を受けた入札値計算部１０４は、再度、入札値計算をしないで、落札情報の最終入札値を、最終入札値記憶部１０５に書き込む。
【０１２７】
以上のようにして、ラウンド数が入札処理の打ち切り条件として、所定の数以上入札が行われないようにしたので、本実施の形態のリソース管理装置は、所定時間内に確実に入札処理が終わらせることができるように構成されている。
【０１２８】
（ｂ）処理単位時間
次に、処理単位時間について説明する。処理単位時間は、ここでは、各アプリケーションの実行時間である。図１０は、処理単位時間を説明するための説明図である。図１０は、ノード２の３つのアプリケーション（レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４、レーダー情報表示アプリケーション４５）が実行される場合を示す。図１０は、３つのアプリケーションＡＰ１、ＡＰ２、ＡＰ３が、処理単位時間毎に割り当てられたリソースであるＣＰＵ利用率に応じた時間だけ実行されることを示している。
【０１２９】
処理単位時間毎に、次の処理単位時間における各アプリケーション毎のリソースの配分が入札により決定される。時間ｔ（ｉ）から時間ｔ（ｉ＋１）までの間の処理単位時間（ＰＵＴ１）において、上述したように、所定の回数の入札を行い、最終的に落札者を決定している。本実施の形態では、所定回数は３回である。そして、その決定された落札結果に応じて、各アプリケーションは、割り当てられたＣＰＵ利用率だけ実行される。図１０では、時間ｔ（ｉ＋１）から時間ｔ（ｉ＋２）までの間の処理単位時間（ＰＵＴ２）における各アプリケーションのＣＰＵ利用率は、処理単位時間（ＰＵＴ１）内における入札処理において、決定される。
【０１３０】
図１０では、１回目の入札（Ｒ１）が行われた後、２回目の入札（Ｒ２）が行われ、その後、３回目の入札（Ｒ３）が行われる。３回の入札後において、最終的にタイミングＤにおいて、落札内容が決定される。その落札結果に応じて、次の処理単位時間において各アプリケーションが、割り当てられたＣＰＵ利用率だけ実行される。
【０１３１】
同様に、処理単位時間（ＰＵＴ３）における各アプリケーションのＣＰＵ利用率は、処理単位時間（ＰＵＴ２）内における入札処理において、決定される。以下同様にして、次の処理単位時間における、各アプリケーションに割り当てられるＣＰＵ利用率は、その処理単位時間の前の処理単位時間において入札により決定される。
【０１３２】
（ｃ）落札者決定部
入札情報を受け取った入札管理部１０３では、落札者決定部１０６が、いずれのアプリケーションがリソースを落札するかを決定する。
【０１３３】
落札者決定部１０６の動作を、ノード２の物理リソースマネージャ４２の入札管理部４２ｂが、図１１に示す内容に対して、入札を行った場合を例に説明する。図１１は、物理リソースの入札情報の例を示す説明図である。
【０１３４】
入札情報には、モジュール名、供給量または消費量、入札値、供給者と消費者の別の情報が含まれている。モジュール名は、各処理部を示し、図１１のような文字列のほか、プロセス番号などの数値で表現することもできる。供給量または消費量は、リソースをいくら消費または供給するかをリソースごとに定義された単位の数量で指定する。図１１ではＣＰＵ利用率をパーセンテージで指定している。入札価格である入札値は、リソースをいくらで消費または供給するかを仮想的な通貨で指定する。その指定は、リソースの単位ごとの単価で示してもよいし、総額（単価に数量を乗じた値）で示してもよい。図１１では単位利用率ごとの単価で示している。
【０１３５】
落札者決定部１０６の動作を説明する。まず、ＣＰＵ利用率のように、供給者が１つで消費者が複数である場合の、すなわち本実施の形態では物理リソースマネージャ４２の入札管理部４２ｂの場合の、落札者決定部１０６の動作を説明する。この場合は、消費者からの入札に対して、入札値が高い順に、供給量が存在しなくなるまで、あるいは消費者からの入札の入札値が供給者からの入札の入札値を下回るまで、リソースを割り当てることによって決定される。
【０１３６】
その際の落札値は、入札量を全て満たすだけのリソースが割り当てられなかった消費者からの入札のうち最大の入札値か、あるいは供給者からの入札の入札値かのいずれかの高い方の額となる。
【０１３７】
例として、図１１に示す入札が行なわれた場合、物理リソースマネージャ４２からの供給量である１８０％が各アプリケーションの消費量に割り当てられる。この場合、入札値の高い順に、まずレーダー情報表示アプリケーション４５に利用率８０％が割り当てられる。次に、レーダー信号処理アプリケーション４３の１６０％に対して、残りの供給量１００％が割り当てられる。また、落札値は、レーダー信号処理アプリケーション４３（入札量１６０％を全て満たすだけのリソースは割り当てられていない）の入札値「３」が物理リソースマネージャ４２の入札値「０」よりも高いので、「３」となる。
【０１３８】
次に、落札者決定部１０６の動作を、ノード２のレーダー情報表示アプリケーション４５の入札管理部４５ｂが、図１２に示す内容に対して、入札を行った場合を例に説明する。図１２は、データの入札情報の例を示す説明図である。
【０１３９】
図１２において、レーダー情報表示アプリケーション４５の消費量が「１００」となっているのは、レーダー情報表示アプリケーション４５は、１００％のデータをもらわなければ表示処理ができないことを意味している。ノード２のレーダー信号処理アプリケーション４３の供給量が「５８」となっているのでは、レーダー信号処理アプリケーション４３がレーダー情報を処理して供給できる割合（％）の最大値が「５８」であることを示している。この最大値「５８」は、ノード２においてレーダー信号処理アプリケーション４３が使えるＣＰＵ利用率から決定される値であり、レーダー情報１００％のうち５８％はレーダー信号処理アプリケーション４３によって処理してもよいとされる設定値である。同様に、ノード３のレーダー信号処理アプリケーション５３の供給量が「６４」となっているのでは、レーダー信号処理アプリケーション５３がレーダー情報を処理して供給できる割合（％）の最大値が「６４」であることを示している。この最大値「６４」は、ノード３においてレーダー信号処理アプリケーション５３が使えるＣＰＵ利用率から決定される値であり、レーダー情報１００％のうち６４％はレーダー信号処理アプリケーション５３によって処理してもよいとされる設定値である。
【０１４０】
レーダー情報表示アプリケーション４５の入札値が「１９８０」となっているのは、レーダー情報表示アプリケーション４５は、入札価格の最大値が「１９８０」であることを意味している。ノード２のレーダー信号処理アプリケーション４３とノード３のレーダー信号処理アプリケーション５３の入札値が、共に「３７」となっているのは、入札価格の最小値が共に「３７」であることを意味している。
【０１４１】
なお、ここでは入札値は、ＣＰＵ利用率の単位利用率ごとの単価としたので、入札値の大きさを比較する際にはＣＰＵ利用率を考慮する必要はないが、総額を入札値として入札を行なう場合は、落札者決定部１０６において、入札値をＣＰＵ利用率で割ることによって単価を計算し、その単価を比較して落札者を決定する必要がある。
【０１４２】
図１３は、供給者である物理リソースマネージャ４２の落札者決定部１０６の処理の流れの例を示すフローチャートである。ここでは、ノード２の場合で説明する。
【０１４３】
まず、落札者決定部１０６は、供給者の決定した供給量、すなわち供給者の入札情報における供給量を、供給量とする（ステップＳ３１）。
【０１４４】
落札者決定部１０６は、リソースの消費者からの入札情報の中で、価格が最も高い入札を選択する（ステップＳ３２）。図１１の例であれば、レーダー情報表示アプリケーション４５が選択される。
【０１４５】
落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値以上か否かの判定が行われる（ステップＳ３３）。図１１の場合、供給者である物理リソースマネージャ４２の入札値は「１」であり、消費者であるレーダー情報表示アプリケーション４５の入札値は「４」であるので（ステップＳ３３：ＹＥＳ）、ステップＳ３４へ処理は移行する。
【０１４６】
落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値未満であるときは（ステップＳ３３：ＮＯ）、処理を終了する。
【０１４７】
ステップＳ３４では、落札者決定部１０６は、その消費者からの入札のうち、残りの供給量を超えない量を落札量と決定する。図１１の場合、レーダー情報表示アプリケーション４５の消費量８０が、供給量１８０から減算できるので、供給量を超えない量である消費量８０が落札量とされる。
【０１４８】
次に、落札者決定部１０６は、残り供給量を算出する、すなわち、残り供給量から落札量を減算することによって残り供給量を算出する（ステップＳ３５）。図１１の場合、供給量１８０から落札量８０を減算して、残り供給量１００が算出される。
【０１４９】
そして、落札者決定部１０６は、残り供給量が０以下であるか否かを判定する（ステップＳ３６）。
【０１５０】
残り供給量が０を超えるとき（ステップＳ３６：ＹＥＳ）、処理はステップＳ３２に戻る。残り供給量が０以下のとき（ステップＳ３６：ＮＯ）、処理は終了する。
【０１５１】
ステップＳ３２に戻った場合、落札者以外の消費者から入札について、上述したステップＳ３２からＳ３６までの処理を繰り返す。
【０１５２】
以上のステップＳ３１からＳ３６までの処理が、所定の回数（ここでは３回）繰り返される。ステップＳ３１からＳ３６までの処理が、１ラウンドに対応する。
【０１５３】
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを消費するリソース消費プログラムが複数ある場合、複数のリソース消費プログラムの中で、入札値の大きいプログラムを優先してリソースを割り当てるようにリソース割り当て処理を行なう。
【０１５４】
一方、センサ情報のように、供給者が複数で消費者が１つである場合、すなわち本実施の形態ではレーダー情報表示アプリケーション４５の入札管理部４５ｂの場合、の落札者決定部１０６の動作は、図１３において、「供給」と「消費」を読み替え、「高い」を「低い」と読み替えればよい。図１４は、情報表示アプリケーションの落札者決定部１０６の処理の流れの例を示すフローチャートである。
【０１５５】
まず、落札者決定部１０６は、消費者の決定した消費量、すなわち消費者の入札情報における消費量を、消費量とする（ステップＳ４１）。
【０１５６】
落札者決定部１０６は、リソースの供給者からの入札情報の中で、価格が最も低い入札を選択する（ステップＳ４２）。図１２の場合、ノード２のレーダー信号処理アプリケーション４３と、ノード３のレーダー信号処理アプリケーション５３とは、同じ入札値、すなわち「３７」であるので、ここでは、例えばこれら２つのアプリケーションに優先順位を予め設定しておくことにより、２つのアプリケーションのいずれかが選択される。例えば、レーダー信号処理アプリケーション４３が選択される。
【０１５７】
落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値以下か否かの判定が行われる（ステップＳ４３）。図１２の場合、消費者であるレーダー情報表示アプリケーション４５の入札値は、「１９８０」であるので（ステップＳ４３：ＹＥＳ）、ステップＳ４４へ処理は移行する。
【０１５８】
なお、落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値を超えるとき（ステップＳ４３：ＮＯ）、処理を終了する。
【０１５９】
落札者決定部１０６は、ステップＳ４４では、その供給者からの入札のうち、残りの消費量を超えない量を落札量と決定する。図１２の場合、レーダー情報表示アプリケーション４５の消費量「１００」から供給量「５８」が減算できるので、消費量を超えない量である供給量「５８」が落札量とされる。
【０１６０】
次に、落札者決定部１０６は、残り消費量を算出する、すなわち、残り消費量から落札量を減算することによって残り消費量を算出する（ステップＳ４５）。図１２の場合、残り消費量１００から落札量５８を減算して、残り消費量４２が算出される。
【０１６１】
そして、落札者決定部１０６は、残り消費量が０以下であるか否かを判定する（ステップＳ４６）。
【０１６２】
残り消費量が０を超えるとき（ステップＳ４６：ＹＥＳ）、処理はステップＳ４２に戻る。残り消費量が０以下のとき（ステップＳ４６：ＮＯ）、処理は終了する。
【０１６３】
ステップＳ４２に戻った場合、落札者以外の供給者から入札について、上述したステップＳ４２からＳ４６までの処理を繰り返す。
【０１６４】
以上のステップＳ４１からＳ４６までの処理が、所定の回数（ここでは３回）繰り返される。ステップＳ４１からＳ４６までの処理が、１ラウンドに対応する。この繰り返し回数も、予め決められており、本実施の形態では、３である。
【０１６５】
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを供給するリソース供給プログラムが複数ある場合、複数のリソース供給プログラムの中で、入札値の小さいプログラムを優先して前記リソースを割り当てるようにリソース割り当て処理を行なう。
【０１６６】
（ｄ）ラウンド繰り返し管理部
図１３および図１４で説明した処理の実行回数は、ラウンド繰り返し管理部１０７によりカウントされ、所定回数を超えて図１３および図１４の処理が実行されないように、ラウンド繰り返し管理部１０７は、落札者決定部１０６における上述した処理の実行を制御する。
【０１６７】
図１５は、ラウンド繰り返し管理部１０７の処理の流れの例を示すフローチャートである。ラウンド繰り返し管理部１０７は、上述したラウンドの繰り返し回数をカウントする（ステップＳ５１）。ラウンド繰り返し管理部１０７は、カウントしたラウンド繰り返し回数が所定回数、本実施の形態では３回になったか否かを判定する（ステップＳ５２）。そして、カウントしたラウンド繰り返し回数が所定回数にならなければ（ステップＳ５２：ＮＯ）、ステップＳ５１に戻る。カウントしたラウンド繰り返し回数が所定回数になると（ステップＳ５２：ＹＥＳ）、ラウンド繰り返し管理部１０７は、図１２および図１３の処理を終了させる実行終了処理を行う（ステップＳ５３）。実行終了処理では、上述した打ち切り通知が、落札情報と共に、あるいは落札情報とは別に、リソース応札部１０２に出力される。
【０１６８】
このように、ラウンド繰り返し管理部１０７は、内部にラウンドの回数を記憶し、ラウンドの度に１つずつインクリメントし、カウントしたラウンドの回数が上限すなわち所定回数に達したら、それ以上のラウンドを実行しないように、処理を打ち切る、すなわち終了させる。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。この打ち切りによって、入札が一定の時間内に終了することが保証される。なお、ラウンドが終了したか否かは入札を行なった処理部への落札結果の通知の際に、付加情報として通知される。
【０１６９】
５．装置全体の動作
上述したようなリソース管理装置において、入札値計算部１０４における増減させる所定量等のパラメータを適宜設定することにより、最終的には、ノード２のレーダー情報表示アプリケーション４５が、ノード３のレーダー信号処理アプリケーション５３からレーダー情報を得て動作する、という結果に収束させることができる。
【０１７０】
図１６および図１７は、ラウンド数が「２０」までの、本実施の形態におけるリソース管理装置の入札と落札の状況を示す表である。図１６および図１７では、連続した２０回のラウンドにおける入札値等のデータの例が示されているが、上述したラウンド繰り返し回数が「３」であるので、ラウンド１から３が、１回目の入札処理を経過と結果を示し、ラウンド４から６が、２回目の入札処理の経過と結果を示す。以下、同様に、３回のラウンドで、処理単位時間における入札処理が行われている。
【０１７１】
上述したように、図１６および図１７は、リソースの供給と消費の関係において、レーダー信号処理アプリケーション４３、５３は１００％のレーダー情報を生成するためにＣＰＵ利用率１３５％を必要であり、ソナー信号処理アプリケーション４４、５４は、１００％のソナー情報を生成するためにＣＰＵ利用率９０％を必要であり、レーダー情報表示アプリケーション４５は、１００％のレーダー情報を処理するのにＣＰＵ利用率９０％を必要であり、ソナー情報表示アプリケーション５５は、１００％のソナー情報を処理するのにＣＰＵ利用率３５％を必要であるという条件で処理が行われた場合の例を示す。また、入札値の計算の際に値を増減させる微少量は、入札値では「４」で、入札量では「３」という値である場合が示されている。そして、入札では、ノード２と３のそれぞれのＣＰＵ利用率、レーダー情報およびソナー情報の４つのリソースについて、それぞれ入札参加者からの入札が行われ、落札量と落札値が決定されている。
【０１７２】
図１６および図１７では、２０回目以降のラウンドでは、リソースが適切に割り当てられている。２０回目のラウンドの結果を見ると、ノード２では、レーダー信号処理アプリケーション４３がＣＰＵ利用率７８％でレーダー情報５８％を生成し、ソナー信号処理アプリケーション４４がＣＰＵ利用率４２％でソナー情報３７％を生成している。ノード３では、レーダー信号処理アプリケーション５３がＣＰＵ利用率８６％でレーダー情報４２％を生成し、ソナー信号処理アプリケーション５４がＣＰＵ利用率５６％でソナー情報６３％を生成している。
【０１７３】
これらの割り当て結果は、レーダー信号処理アプリケーション４３、５３は、１００％のレーダー情報を生成するのに、ＣＰＵ利用率１３５％を必要とし、ソナー信号処理アプリケーション４４、５４は、１００％のソナー情報を生成するのに、ＣＰＵ利用率９０％を必要とするという条件を満たしている。また、レーダー情報表示アプリケーション４５は６０％のＣＰＵ利用率で、ソナー情報表示アプリケーション５５は３５％のＣＰＵ利用率という条件も満たしている。さらに、レーダー情報表示アプリケーション４５は１００％のレーダー情報を落札し、ソナー情報表示アプリケーション５５は１００％のソナー情報を落札しているので、それぞれ表示に必要なデータも問題なく得ている。２０回目の以前のラウンドでは、一応の動作は可能であるが、ＣＰＵ利用率が十分に割り当てられていない場合もあるので、装置全体のリアルタイム性が満足されていない状態となるおそれがある。しかし、このような状態は、入札初期の状態のときだけで生じるので、全体として問題はない。
【０１７４】
本実施の形態では、レーダー情報がソナー情報よりも重要であるので、レーダーの信号処理と情報表示がソナーの信号処理と情報表示よりも優先されて実行されるように、入札値の上限値が設定されている。上述した例では、２つのセンサ情報表示アプリケーション間で、買値の上限値を異ならせ、各センサ情報表示アプリケーションは、その上限値の範囲内で、自己が消費するリソースを買って動作を行なう。なお、この上限値は、状況に応じて設定変更可能とすれば、各アプリケーションの重要度は、状況に応じて変更可能となる。
【０１７５】
また、レーダー情報表示アプリケーション４５によってＣＰＵ利用率が落札されてＣＰＵ利用率の価格が上がっているノード２よりも、ノード３の方がＣＰＵ利用率の入札値が低いので、ノード２のレーダー情報処理アプリケーションよりもノード３のレーダー情報処理アプリケーションの方がレーダー情報のリソースとしての入札値（売値）が低いため、レーダー情報表示アプリケーション４５は、ノード３のレーダー信号処理アプリケーション５３からレーダー情報を買うことになり、ノード３のレーダー信号処理アプリケーション５３が動作している。
【０１７６】
さらに、リソース応札部１０２において、最終入札値記憶部１０５が設けられているため、次の処理単位時間における入札処理では、前回の入札結果に基づいて、入札値が計算されるので、適切な状態に収束するまでの時間が長く掛かるということが回避されている。
【０１７７】
すなわち、入札処理を単純に打ち切るのでは対応として不十分となる虞があるため、上述したように、複数のラウンドの入札処理が実行される。これは、リソースの割り当て効率を漸進的に改善するためであるが、少数のラウンドでは十分に改善が進まないこともあり得る。そのような場合、処理単位時間毎の入札でのリソース割り当てが非効率、つまりその局面での信号処理の重要度などを正しく考慮したリソース割り当てた方ができない状態が続いてしまう。そのような場合に、もし最終入札値記憶部がなければ、生産者や消費者の入札値は処理単位時間ごとに毎回０から開始することになり、適切な割り当て状態に収束するまでには多くの回数の、上述の場合であれば２０回以上のラウンドを経なければならない。そのため、上述したように、本実施の形態では、入札を一定の時間内に終了することを保証するためにラウンド繰り返し管理部１０７によってラウンドを例えば５回で打ち切っても、例えば４つの処理単位時間を経ることによって適切な割り当て状態に収束するように、最終入札値記憶部１０５によって前回の入札値が記憶されている。
【０１７８】
なお、変形例として、上述した実施の形態では、ラウンドの打ち切り条件は繰り返し回数であるが、ラウンド繰り返し管理部１０７が、ラウンドの回数ではなくラウンドの実行時間を計測して所定時間に達したらラウンドの打ち切りを行なうようにしてもよい。
【０１７９】
この所定の時間はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。あるいは、時間計測によるラウンドの打ち切りの方法としては、初回ラウンド時にＯＳが提供するタイマー機能を利用して、タイマーを設定し、その設定した時間が経過したことを通知させて打ち切りを行なうようにしてもよい。
【０１８０】
また、初回ラウンド時にＯＳのリアルタイムクロックを読み出して時刻をラウンド繰り返し管理部１０７に記憶し、ラウンドの度に現在の時刻と記憶された時刻との差を計算して一定の時間が達したかどうかを判定する、といった方法も可能である。
【０１８１】
なお、以上説明した本実施の形態では、センサ情報システム１は、説明の簡単のために、２つのノード２，３からなるシステムであるが、３以上のノードを含むものであってもよい。また、センサ信号を出力するレーダー装置２５とソナー装置３５は、それぞれノード２と３に接続されているが、それぞれがセンサ信号を出力する複数の装置が、１つのノードに接続されるように、システムが構成されていてもよい。すなわち、ノードの中には、センサ信号を出力する装置が接続されていないものがあったり、それぞれがセンサ信号を出力する複数の装置が接続されているものがあってもよい。
【０１８２】
さらになお、上述した実施の形態では、各ノードには、２つのＣＰＵが設けられているが、１つあるいは３以上のＣＰＵが設けられていてもよく、各ノード内部のバスにより、１つまたは複数のＣＰＵが他の回路とバスで接続される。
【０１８３】
なお、上述の実施の形態では、最終入札値記憶部１０５を設けて、前回の単位時間において最終的に落札された入札値を次の単位時間における最初の入札値として利用しているが、適切な状態に収束するまでの時間が長くかかってもよければ、最終入札値記憶部１０５を省略して毎回初期値から入札を行なってもよい。
【０１８４】
なお、本実施の形態のようにＣＰＵ利用率の大小に基づいて調整したＣＰＵ価格からデータ価格を計算する方法のほかに、より直接的に、データの大小に基づいた調整をデータ価格に対して行なう方法によっても、多くのＣＰＵ利用率を消費して多くのデータを生成する生産者に優先的に割り当てを行なうという目的は達成できる。
【０１８５】
しかし、アプリケーションによらずに統一的な定数で調整を行なうことができるという点では、ＣＰＵ利用率の大小に基づく本実施の形態の調整方法が優れている。
【０１８６】
また、特定のノードを優先的に使わせたり、逆に抑制したりしたい場合には、そのノードのＣＰＵ価格の調整を行なう際の定数を小さくしたり大きくしたりすることで実現できる、という副次効果も本実施の形態の調整方法には存在する。
【０１８７】
以上のように、本実施の形態によれば、消費するＣＰＵ利用率が少ない場合に、供給するデータの入札価格が上がるような調整が行なわれる。
【０１８８】
このため、多くのＣＰＵ利用率を消費して多くのデータを生成する生産者が、少ないＣＰＵ利用率を消費して少ないデータを生成する生産者よりも低い入札価格でデータ市場への入札を行なうことができる。これにより、多くのＣＰＵ利用率を消費して多くのデータを生成する少数の生産者のみで処理が可能な場合は、それらの少数の生産者のみがデータを落札して処理を行なうため、少ないＣＰＵ利用率を消費して少ないデータを生成する生産者に処理が細分化されることはない。したがって本実施の形態によれば、必要以上に多くのノードへの処理の分散を抑制することができる。
【０１８９】
本実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１９０】
また、本実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１９１】
また、本実施の形態のリソース管理プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１９２】
本実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムは、上述した各部（リソース応札部、入札管理部など）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からリソース管理プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１９３】
以上のように、本発明にかかる装置、およびプログラムは、市場メカニズムによるリソース割り当て方式によりリソースの管理を行うリソース管理装置、リソース管理プログラムに適している。
【図面の簡単な説明】
【０１９４】
【図１】本実施の形態に係わるセンサ情報システムのハードウェア構成を示す構成図である。
【図２】本実施の形態におけるソフトウェア構成のリソース管理の部分を説明するためのブロック図である。
【図３】本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。
【図４】リソース応札部と入札管理部の構成を示すブロック図である。
【図５】供給者の入札値計算部の処理の流れの例を示すフローチャートである。
【図６】生産者の入札値計算部の処理の流れの例を示すフローチャートである。
【図７】ＣＰＵ価格調整部の処理の流れの例を示すフローチャートである。
【図８】消費者の入札値計算部の処理の流れの例を示すフローチャートである。
【図９】入札処理が所定回数しか行われないことを説明するための説明図である。
【図１０】処理単位時間を説明するための説明図である。
【図１１】物理リソースの入札情報の例を示す説明図である。
【図１２】データの入札情報の例を示す説明図である。
【図１３】物理リソースマネージャの落札者決定部の処理の流れの例を示すフローチャートである。
【図１４】情報表示アプリケーションの落札者決定部の処理の流れの例を示すフローチャートである。
【図１５】ラウンド繰り返し管理部の処理の流れの例を示すフローチャートである。
【図１６】ラウンド経過に伴うＣＰＵ利用率の入札と落札の量と値が変化する例を示す図表である。
【図１７】ラウンド経過に伴うデータの入札と落札の量と値が変化する例を示す図表である。
【符号の説明】
【０１９５】
１  センサ情報システム
２、３  ノード
４  ネットワーク
５  レーダー装置
６、８、９  端末装置
６ａ、８ａ、９ａ  表示装置
７  ソナー装置
２１、２２、３１、３２  ＣＰＵ
２３、３３  メモリ
２４、３４  ネットワークＩ／Ｆ
２５  レーダー装置Ｉ／Ｆ
２６、３６  端末装置Ｉ／Ｆ
２７、３７  バス
３５  ソナー装置Ｉ／Ｆ
４２、５２  物理リソースマネージャ
４３、５３  レーダー信号処理アプリケーション
４２ａ、５２ａ、４３ａ、５３ａ、４４ａ、５４ａ、４５ａ、５５ａ  リソース応札部
４２ｂ、５２ｂ、４５ｂ、５５ｂ  入札管理部
４４、５４  ソナー信号処理アプリケーション
４５  レーダー情報表示アプリケーション
５５  ソナー情報表示アプリケーション
１０１  リソース管理装置
１０２  リソース応札部
１０３  入札管理部
１０４  入札値計算部
１０４１  ＣＰＵ価格調整部
１０５  最終入札値記憶部
１０６  落札者決定部
１０７  ラウンド繰り返し管理部
【図１】
2010165049.tif 000003
【図２】
2010165049.tif 000004
【図３】
2010165049.tif 000005
【図４】
2010165049.tif 000006
【図５】
2010165049.tif 000007
【図６】
2010165049.tif 000008
【図７】
2010165049.tif 000009
【図８】
2010165049.tif 000010
【図９】
2010165049.tif 000011
【図１０】
2010165049.tif 000012
【図１１】
2010165049.tif 000013
【図１２】
2010165049.tif 000014
【図１３】
2010165049.tif 000015
【図１４】
2010165049.tif 000016
【図１５】
2010165049.tif 000017
【図１６】
2010165049.tif 000018
【図１７】
2010165049.tif 000019