JP2008004046A - リソース管理装置及びそのためのプログラム - Google Patents

Abstract

【課題】入札処理が時間制約の範囲内で完了するようにリソースの割り当て行なうリソース管理装置を提供する。
【解決手段】リソース管理装置１０１は、複数のアプリケーションプログラムのそれぞれに対応して設けられ、複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースについて、入札値を計算して入札値の情報を生成する複数のリソース応札部１０２と、複数のリソース応札部１０２からの入札値の情報に基づいて、所定の単位時間における、複数のアプリケーションプログラムのそれぞれに割り当てるリソースを決定するリソース割り当て処理を行なう入札管理部１０３と、所定の単位時間において、入札打ち切り条件が満たされるまでリソース割り当て処理が繰り返されるように入札管理部１０３を管理する繰り返し管理部１０７とを有する。
【選択図】図４

Description

本発明は、リソース管理装置及びそのためのプログラムに関し、特に、複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースを管理するためのリソース管理装置及びそのためのプログラムに関する。

従来より、センサを備えた、いわゆるリアルタイムシステムがある。例えば、船舶、航空機、自動車などの輸送機械の分野では、周囲の状況を把握し、その把握した状況の情報を、画面表示などによってユーザに呈示するセンサ情報システムが用いられている。船舶の場合のセンサ情報システムは、レーダー、ソナー、赤外線センサ、カメラなどの複数のセンサを備え、各局面に応じてそれらの一つあるいは複数のセンサの信号を解析して周囲の状況を認識し、その認識結果を画面などに表示する。周囲状況の情報は、船舶の安全な航行などに役立つものである。

輸送機械の分野におけるこれらのシステムでは、認識された周囲状況の情報をユーザに知らせるために、所定の時間内に画面表示などが更新されなければならない。それは、ユーザが周囲の状況を素早く把握できず、衝突などの事故につながる危険があるからである。そのため、それらのシステムは、リアルタイムシステムでなければならず、センサ信号に基づく信号処理は所定の時間制約を満たすリアルタイム処理で行なわれることが要求される。

従来、複数のセンサ信号の信号処理を行なうこのようなリアルタイムシステムでは、それぞれの信号は独立したサブシステムにおいて処理されるのが一般的であった。それは、それぞれの信号の信号処理に必要な中央処理装置（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と略す）２１，２２、メモリ２３、ネットワークインターフェース（以下、ネットワーク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内部の機能として実現されていてもよい。

リソース管理装置は、複数のリソース応札部と複数の入札管理部を含んで構成される。具体的には、ノード２において、物理リソースマネージャ４２は、リソース応札部４２ａと、入札管理部４２ｂとを有する。レーダー信号処理アプリケーション４３は、リソース応札部４３ａを含む。ソナー信号処理アプリケーション４４は、リソース応札部４４ａを含む。レーダー情報表示アプリケーション４５は、リソース応札部４５ａと、入札管理部４５ｂとを有する。同様に、ノード３において、物理リソースマネージャ５２は、リソース応札部５２ａと、入札管理部４２ｂとを有する。レーダー信号処理アプリケーション５３は、リソース応札部５３ａを含む。ソナー信号処理アプリケーション５４は、リソース応札部５４ａを含む。ソナー情報表示アプリケーション５５は、リソース応札部５５ａと、入札管理部５５ｂとを有する。
すなわち、各リソース応札部４２ａ，４３ａ、５２ａ，５３ａ等は、リソースの供給または消費を行なうモジュールである処理部（ここでは、物理リソースマネージャ４２，５２および各アプリケーション４３，４４等）の内部に設けられている。

なお、一部のアプリケーションのみにリソース応札部を設けるようにしてもよい。例えば、リソースをあまり消費しないアプリケーションには、入札への参加を省略すべくリソース応札部を設けず、逆に、リソースを大量に消費するアプリケーションのみにリソース応札部を設けるようにする、といった構成でもよい。この場合、入札へ参加しないアプリケーションが消費するリソースは、ある程度余裕を持つようにするなどの方法で、別途固定的に割り当てておく必要がある。

一方、入札管理部は、ノード毎に、全体で一つ設けてもよいし、複数設けてもよい。また、入札管理部は、独立したミドルウェアやOS内部の機能として実現してもよいし、あるいは、いずれかの処理部の内部で実現してもよい。一般に、供給者が一つで消費者が複数の場合は供給者の内部で実現し、供給者が複数で消費者が一つの場合は消費者の内部で実現すると入札の際の処理や通信が簡単になる。そこで、本実施の形態では、物理リソースマネージャ（供給者）は、複数のアプリケーション（消費者）にCPU利用率を供給するだけであるので、物理リソースマネージャ４２，５２の内部に入札管理部４２ｂ、５２ｂを設けている。そして、センサ情報表示アプリケーション（消費者）は、複数のアプリケーション（供給者、生産者）から、CPU利用率とセンサ情報を受けるだけであるので、センサ情報表示アプリケーション内部に入札管理部４５b、５５bが設けられている。例えば、ノード２では、物理リソースマネージャ４２内部に入札管理部４２ｂが設けられ、そしてレーダー情報表示アプリケーション４５内部に入札管理部４５ｂが設けられている。

３．リソースの供給と消費
３．１ リソース
ここで、リソースについて説明する。本実施の形態は、物理リソースであるCPU利用率に加えて、アプリケーションプログラムが生成したデータもリソースとして扱う、サプライチェーンモデルに基づく例である。

データもリソースとして扱うのは、次の理由による。すなわち、各センサ信号の信号処理部と各センサ情報の情報表示部とが分離されているため、センサ情報をリソースとして扱わずにCPU利用率のみをリソースとして扱ってしまうと、センサ情報の供給と消費関係を無視したリソースの割り当てが生じる虞がある。例えば、ソナー信号処理部４４，５４にCPU利用率が割り当てられて実行されるが、ソナー情報表示部５５にはCPU利用率が割り当てられずに実行ができないという状況があり得る。その場合、利用されないセンサ情報を生成するためにCPUが浪費される、といった状態が生じてしまう。このような状態が生じないようにしながら、各信号処理部と各情報表示部とを分離できるようにするために、ＣＰＵ利用率に加えてデータもリソースとして扱われている。

なお、CPU利用率は、後述する単位処理時間当たりにおける、そのアプリケーションが使用する割合（％）である。例えば、単位処理時間が、１秒で、CPU利用率が３０％であれば、そのアプリケーションは、３００ｍｓだけCPUを使用できることを意味する。本実施の形態では、CPU利用率（％）を用いるが、CPU使用時間（ｍｓ等）を用いてもよい。また、データは、本実施の形態では、レーダー情報とソナー情報である。

図３は、本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。
図３に示すように、本実施の形態のサプライチェーンモデルにおいて、物理リソースマネージャ４２，５２は、供給者に対応し、レーダー信号処理アプリケーション４３，５３とソナー信号処理アプリケーション４４，５４は、生産者に対応し、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５は消費者に対応する。

リソースの供給のみを行う供給者である物理リソースマネージャ４２，５２は、物理リソースであるCPU利用率の管理を行なうミドルウェアである。なお、物理リソースマネージャ４２，５２は、OSの一部として、OSの中に組み込まれたものであってもよい。

CPU利用率は、供給者である物理リソースマネージャ４２，５２から、各アプリケーションに供給される。図３の場合、CPU利用率は、物理リソースマネージャ４２から、レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４及びレーダー情報表示アプリケーション４５に供給される。物理リソースマネージャ５２から、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４及びレーダー情報表示アプリケーション５５に供給される。

生産者であるレーダー信号処理アプリケーション４３，５３およびソナー信号処理アプリケーション４４，５４は、それぞれ、CPU利用率を消費して所定のセンサ情報を生成して、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５に供給する。すなわち、アプリケーションのうちセンサ信号処理アプリケーションは、センサ情報を供給する生産者である。

消費者であるレーダー情報表示アプリケーション４５及びソナー情報表示アプリケーション５５は、CPU利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない。すなわち、アプリケーションのうち情報表示アプリケーションは、CPU利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない消費者である。

アプリケーションである各処理部は、自己が消費する全てのリソースが落札できた場合のみ動作する。なお、各信号処理部は、ノード２，３間の負荷分散のため両方のノードに存在するが、いずれか一方のみが実行されれば、センサ情報は生成される。例えば、レーダー情報表示アプリケーション４５は、CPU利用率が割り当てられ、かつレーダー信号処理部４３と５３のいずれか一方からレーダー情報の供給を受ければ、実行される。

３．２ リソースの供給方法
リソースの供給について説明する。
リソースの供給のうち、データであるセンサ情報の供給は、信号処理アプリケーションが、実際にセンサ情報表示アプリケーションに、センサ情報を供給することによって行なわれる。例えば、レーダー信号処理アプリケーション４３が、信号処理の結果得られたレーダー情報を、レーダー情報表示アプリケーション４５に供給することが、センサ情報の供給となる。

一方、CPU利用率の供給は概念上のものであって、明示的な受渡しはなく、アプリケーションプログラム作成の際に、CPU利用率を落札できた場合のみCPUを利用して実行されるようにそのプログラムを作成することによって実現される。
なお、アプリケーションが第三者によって作成された場合など、アプリケーションの実際の挙動が信用できない場合には、アプリケーションが実際に落札した分のCPU利用率しか使用していないかを、物理リソースマネージャがOSの状態を監視するなどの方法でチェックするようにしてもよい。その場合、落札された以上のCPU利用率を使用していた場合は、そのアプリケーションを割り込み処理により強制終了したりすることによって、CPU利用率の割り当てを強制的に守らせるようにすることも可能である。
以上のリソースの割り当てが、リソース管理装置の入札によって行なわれる。

３．３ リソース割り当ての決定方法
（ａ）CPU利用率
まず、物理リソースであるCPU利用率の消費量および供給量の決定方法について述べる。各アプリケーションは、処理単位時間ごとにそのアプリケーションが使用するCPU利用率、すなわち消費量を計算し、明示あるいは決定する。その決定は、アプリケーション作成者がアプリケーションのソースコード中に数値または計算式を明示的に記述することで行なってもよいし、コンパイラがコンパイル時に判定することで行なってもよい。さらに、各アプリケーションが、自己が実行された時に物理リソースマネージャやOSの状態を監視するなどの方法で実測し、測定履歴から今後の物理リソース使用量を推定するといった方法で行なってもよい。

物理リソースマネージャは、アプリケーションに供給できるリソースの供給量を計算する。本実施の形態では、CPU台数分の全利用時間に対する割合を示すパーセンテージからOSやミドルウェアの動作や安全のためのマージンを差し引いた値がアプリケーションへの供給量である。本実施の形態では、各ノードは、CPU 2台分にあたる２００%からマージン２０%を差し引いた１８０%を供給量とする。

（ｂ）センサ情報
次に、センサ情報の消費量および供給量の決定方法について述べる。
物理リソース以外のリソースであるセンサ情報は、アプリケーション作成者がアプリケーションのソースコード中にアプリケーションのロジックの一部として数値または計算式を明示的に記述することによって消費量および供給量が指定される。

例えば、ソナー信号処理アプリケーションは、センサ装置であるソナー装置７から所定のサンプリング周期でセンサ信号を受けるので、そのセンサ信号の量（ビットレート等）が消費量となる。また、ソナー信号処理アプリケーションは、所定の信号処理を行って、センサ情報をソナー情報表示アプリケーションに供給するので、そのセンサ情報の量(ビットレート等)が供給量となる。

また、後述するように、入札に基づいて消費量と供給量は変化するが、各ノードでは、各ノードに供給されるセンサ信号量に応じてCPU利用率も変化する。例えば、ノード２では、ノード２に供給されるセンサ信号量に応じてCPU利用率は変化し、同様にノード３でも、ノード３に供給されるセンサ信号量に応じてCPU利用率は変化する。従って、例えばレーダー装置５から出力されるセンサ信号の全量は、ノード２とノード３に、それぞれ分担され、各ノードは、その分担された量に対応したCPU利用率が必要となる。

（ｃ）リソース割り当ての通知
各処理部において、以上の手順で決定あるいは指定された消費量または供給量は、処理部の内部に実現されたリソース応札部に通知される、リソース応札部は、その消費量または供給量に対応する入札を入札管理部に対して行なう。

４．リソース管理装置の構成
４．１ リソース管理装置
図４は、リソース管理装置を構成するリソース応札部と入札管理部の構成を示すブロック図である。

本実施の形態におけるリソース管理装置１０１は、複数のリソース応札部１０２と複数の入札管理部１０３を含んで構成される。図４は、各アプリケーションのリソース応札部と、対応する入札管理部との関係を示すために、１つのリソース応札部１０２と、１つの入札管理部１０３との間でのデータの流れを示す。

例えば、ノード２の場合、CPU利用率については、リソース応札部４２ａ、４３ａ、４４ａ、４５ａのそれぞれが、リソース応札部１０２に対応し、入札管理部４２ｂが、入札管理部１０３に対応する。レーダー情報のデータについては、レーダー信号処理部４３のリソース応札部４３ａ（及び５３ａ）、４５ａが、リソース応札部１０２に対応し、入札管理部４５ｂが、入札管理部１０３に対応する。

リソース応札部１０２は、入札値計算部１０４と、最終入札値記憶部１０５とを含む。入札管理部１０３は、落札者決定部１０６と、ラウンド繰り返し管理部１０７とを含む。
次に、リソース管理装置１０１の各構成要素の詳細な動作について述べる。

４．２ リソース応札部
まず、リソース応札部１０２の処理について述べる。
リソース応札部１０２は、前述の判定によって得られた消費量または供給量のリソースを入札管理部１０３に対して入札する、すなわち自己のリソースの情報の提供を行う。入札は、リソース応札部が入札管理部に対して複数回すなわち複数ラウンドにわたる入札を行なうことによって行なわれる。

各ラウンドでは、入札値計算部１０４が入札価格としての入札値を計算する。

入札価格としての入札値の計算にあたっては、その価格でリソースを売買することによる処理部の利益が最大化するような価格をつけなければならない。

入札値計算部１０４の具体的動作は、処理部が供給者、生産者及び消費者のいずれであるかによって異なる。以下、それぞれの場合について説明する。図１５及び図１６は、ラウンドが経過するにつれて、CPU利用率とデータの入札と落札の量と値が変化する例を示す表である。図１５では、CPU利用率についてのノード２と３における各処理部における入札量、入札値、落札量及び落札値が示され、図１６では、データについての各処理部における入札量、入札値、落札量及び落札値とが示されている。図１５及び図１６の各部において並んだ数字は、左から順に、入札量、入札値、落札量及び落札値が示されている。以下、図１５及び図１６を参照しながら説明する。

（ａ）供給者の場合
供給者は、自己が供給できるリソースを売り惜しむ必要はないので、どれだけ安い値段であっても最大限リソースが売れるような入札を行なえばよい。従って、供給者の入札値計算部１０４は、固定の入札値を常に返せばよい。本実施の形態では供給者である物理リソースマネージャ４２，５２はCPU利用率を常に価格0で入札するものとする。このため供給者の場合には、最終入札値記憶部は省略してよい。

図５は、供給者の入札値計算部１０４の処理の流れの例を示すフローチャートである。入札値計算部１０４は、所定の入札価格、ここでは常に例えば固定の「０」を、入札値とする（ステップS1）。

（ｂ）生産者の場合
生産者は、高い値段でリソースが売れる場合には、そのリソースの生成のために高い値段でリソースを買ってよい一方で、どうしても売値が買値を下回る場合は、売買を止める必要がある。このため生産者の入札値計算部１０４は以下のような処理を行なう。

はじめのラウンドでは、入札値計算部１０４は、最終入札値記憶部１０５に記録された値を入札値として採用する。なお、最終入札値記憶部１０５には初期値として0 が記録されている。2回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたかどうかによって入札値の調整を行う。

入札値計算部１０４は、自己の供給するリソース（例えば、レーダー信号処理アプリケーション４３であれば、レーダー情報というデータ）については、自己が消費するリソース（例えば、レーダー信号処理部４３であれば、CPU利用率）の入札値（買値）の合計の予測値を入札値（売値）として入札を行なう。自己が消費するリソースの入札値（買値）の予測値は、たとえば前回のラウンドでの自己が消費するリソースの落札値(必ずしもその処理部が落札できた値ではなく、その処理部が落札できなかった場合には他の処理部の落札値)の合計を求めるという方法で計算される。自己が消費するリソースについては、そのリソースが前回のラウンドで十分に落札できていなければ、そのリソース入札値を所定量だけ上げる、といった方法で計算される。

図６は、生産者が供給するリソースについての入札値計算部１０４の処理の流れの例を示すフローチャートである。図６の処理は、入札処理における各ラウンドが開始する直前に、レーダー信号処理アプリケーション４３が実行して、ラウンド毎に入札値を決定する。その決定された入札値は、入札管理部１０３へ供給される。

まず、入札値計算部１０４は、CPU利用率の前回の落札量が、レーダー情報の落札量から計算したCPU利用率の必要量未満であったか否かを判定する（ステップS11）。CPU利用率の前回の落札量が、レーダー情報の落札量から計算したCPU利用率の必要量未満であった場合は、ステップS11でYESとなり、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、CPU利用率の落札値とCPU利用率の落札量との積以上か否かを判定する（ステップS2）。

なお、図１５及び図１６の場合は、レーダー情報を「１００」生成するのに、レーダー信号処理アプリケーション４３は、CPU利用率が「１３５」必要な場合の例である。

ステップS11でYESとなるのは、ノード２のレーダー信号処理アプリケーション４３のラウンド５において、CPU利用率については、図１５においては落札量が「４８」であるのに対して、図１６においては、レーダー情報の落札量「９１」の場合である。この場合、レーダー情報の落札量「９１」から計算したCPU利用率が「１２３」で、CPU利用率の落札量が「４８」以上の場合である。

レーダー情報の落札値とレーダー情報の落札量との積が、CPU利用率の落札値とCPU利用率の落札量との積以上である場合は、ステップS12でYESの場合となり、処理はステップS13へ移行する。ステップS12でYESの場合は、いわゆる採算が取れている（すなわち売値が買値を上回っている）ことを意味とする。ノード２のレーダー信号処理アプリケーション４３のラウンド１９において、CPU利用率については、図１５においては落札量が「７４」で落札値が「０」で積が「０」に対して、レーダー情報については、図１６においては落札量が「５５」で落札値が「３７」で積が「２０３５」となっているような場合である。

ステップS12でYESの場合は、レーダー信号処理アプリケーション４３のCPU利用率を上げてもよいので、入札値計算部１０４は、CPU利用率の入札値を、所定量である微少量（ｄ１）だけ加算する（ステップS3）。加算する微少量は、ここでは「４」である。図１５においては、ノード２のレーダー信号処理アプリケーション４３のラウンド１９から２０にかけて、入札値が、「７４」から「７８」に増加されているような場合である。

ステップS12でNOの場合は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を下げるために、入札値計算部１０４は、レーダー情報の入札量を、所定量である微少量（ｄ２）だけ減算する（ステップS14）。ステップS12でNOの場合となるのは、いわゆる採算が取れていないことを意味とする。

ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、CPU利用率については、図１５に示すように落札量が「７８」で落札値が「２８」でそれらの積が「２１８４」となる。これに対して、レーダー情報については、図１６において落札量が「３０」で落札値が「３７」でそれらの積が「１１１０」となっている。そのような場合に、レーダー信号処理アプリケーション４３は、ラウンド１８から１９にかけて、レーダー情報の入札量を「５８」から「５５」に下げているような場合である。

そして、入札値計算部１０４は、変更されたCPU利用率の入札量を、レーダー情報の入札量から計算する（ステップS15）。ステップS5の計算により得られたCPU利用率によれば、レーダー情報を生成するのに必要なCPU利用率が確保されることになる。

そして、入札値計算部１０４は、CPU利用率の入札値と入札量との積を、レーダー情報の入札量で除算することによって、レーダー情報の入札値を計算する（ステップS1６）。

ステップS11でNOの場合、すなわち、レーダー情報を処理するのに必要なCPU利用率が確保できている場合、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、CPU利用率の落札値とCPU利用率の落札量との積以上か否かを判定する（ステップS17）。

なお、ステップS1でNOとなるのは、図１５に示すように、ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、CPU利用率については、落札量が「７８」であるのに対して、図１６に示すようにレーダー情報の落札量が「３０」の場合である。この場合、レーダー情報の落札量「３０」に対応する必要なCPU利用率は「４１」となり、CPU利用率の落札量が「７８」よりも小さい。

ステップS17でYESの場合、すなわち、いわゆる採算が取れている場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を上げるために、レーダー情報の入札量を、所定量である微少量（ｄ３）だけ加算する（ステップS18）。

ステップS17でNOの場合、すなわち、いわゆる採算が取れていない場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を上げるために、レーダー情報の入札量を、所定量である微少量（ｄ４）だけ加算する（ステップS19）。
その後、入札値計算部１０４は、ステップS15とS16の処理を実行する。

（ｃ）消費者の場合
消費者は、その局面すなわち状況におけるそのアプリケーションの重要度に対応した買値の上限値の範囲内で、自己が消費するリソースを買って処理動作を行なう。各アプリケーションの重要度は、状況に応じて変更可能である。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、アプリケーションが局面を認識して計算してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。

本実施の形態では、レーダー情報がソナー情報よりも重要であると仮定して、レーダー情報表示アプリケーションのリソースの買値の合計の上限値を「２０００００」、ソナー情報表示アプリケーションのリソースの買値の合計の上限値を「１０００００」とし、その範囲内でリソースが買えなければ単位時間のリソース購入を断念するものとする。従って、センサ信号の重要度が反映された入札が行われる。

入札値計算部１０４は、はじめのラウンドでは、最終入札値記憶手段に記録された値を入札値として採用する。なお、最終入札値記憶手段には初期値として「０」 が記録されている。2回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたかどうかによって入札値の調整を行なう。

図７は、消費者の入札値計算部１０４の処理の流れの例を示すフローチャートである。まず、入札値計算部１０４は、CPU利用率の落札量が、CPU利用率の必要量未満であるか否かを判定する（ステップS21）。

その必要量は、ここでは固定値である。例えば、図１５では、ノード２のレーダー情報表示アプリケーションのCPU利用率の必要量は「６０」であり、図１５では、結果として落札量が「６０」となっている。

ステップS21でYESの場合、すなわち、CPU利用率の落札量がCPU利用率の必要量未満の場合は、入札値計算部１０４は、CPU利用率の入札値を、所定量である微少量（ｄ５）だけ増加する（ステップS22）。

そして、入札値計算部１０４は、CPU利用率の入札値にCPU利用率の入札量を乗算した乗算値を上限値から減算し、その減算値を、レーダー情報の入札量で除算して、レーダー情報の入札値を計算する（ステップS23）。すなわち、CPU利用率の入札値にCPU利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、レーダー情報の入札値が決定される。

ステップS21でNOの場合、すなわち、CPU利用率の落札量がCPU利用率の必要量以上の場合は、入札値計算部１０４は、レーダー情報の落札量がレーダー情報の必要量以上であるか否かを判定する（ステップS24）。

レーダー情報の必要量は、ここでは固定である。例えば、ノード２のレーダー情報表示アプリケーション４５のCPU利用率の必要量は「１００」であり、図１６では、結果として落札量が「１００」となっている。

ステップS24でYESの場合、すなわち、レーダー情報の落札量がレーダー情報の必要量以上の場合は、入札値計算部１０４は、レーダー情報の入札値を、所定量の微少量（ｄ６）だけ加算して増加する（ステップS25）。レーダー情報により高い入札値を付けることにより、結果として、CPU利用率には、より低い入札値を付けるためである。

すなわち、入札値計算部１０４は、レーダー情報の入札値にレーダー情報の入札量を乗算した乗算値を上限値から減算し、その減算値を、CPU利用率の入札量で除算して、CPU利用率の入札値を計算する（ステップS26）。すなわち、CPU利用率の入札値にCPU利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、CPU利用率の入札値が決定される。

４．３ 入札管理部
次に、入札管理部１０３の処理について述べる。
入札管理部１０３は、各リソース応札部１０２からの入札、すなわち応札情報、に基づき、どの処理部がリソースを落札するかを決定し、落札結果を各処理部のリソース応札部１０２に通知する。落札結果情報には、その処理部が落札できたかどうかの情報と、落札値(必ずしもその処理部が落札できた価格ではなく、その処理部が落札できなかった場合には他の処理部の落札価格となる)の情報とが含まれている。

落札結果情報を受け取った各処理部のリソース応札部１０２は、その結果にもとづいて処理単位時間の動作を行なう。消費するリソースを最終的に落札できた処理部は、そのリソースを消費する動作を行なう。通常、ある処理単位時間に消費するリソースを全て落札できなかった処理部は、その処理単位時間内に処理を行なわずにいわゆる休眠状態に入る。しかし、消費するリソースの一部が落札できなくてもなんらかの動作が可能な場合は、その処理部は、その分だけの処理動作を行なう。一方、供給できるリソースが落札されなかった処理部は、次の処理単位時間ではそのリソースの供給を行なわない。

物理リソースであるCPU利用率の場合、各アプリケーションは、CPU利用率を落札したときは、次の処理単位時間においてその落札の結果得られた時間だけ、CPUを利用した所定の処理を実行する。物理リソース以外のリソースであるデータの場合は、各アプリケーションは、データを落札したときは、落札量に応じたそのデータの供給を受ける。

例えば、レーダー信号処理アプリケーション４３は、その落札の結果得られたCPU時間だけ、実行される。なお、上述したように、レーダー情報表示アプリケーション４５は、CPU利用率の落札と、データの落札（レーダー信号処理アプリケーション４３あるいは５３のいずれかからの落札）の、両方の落札があったときに、落札の結果得られたCPU時間だけ、落札の結果得られたデータを用いて、実行される。

（ａ）ラウンド管理
ここで、ラウンドについて説明する。
本実施の形態では、ラウンド数すなわち繰り返し回数が入札の打ち切り条件である。すなわち、所定のラウンド数を超えて、入札処理が行われないように管理されている。すなわち、入札管理部１０３のラウンド繰り返し管理部１０７が、各処理単位時間におけるラウンド数をカウントし、所定の回数だけ落札者決定が行われるように監視して管理している。

図８は、ラウンド繰り返し管理部１０７により、入札処理が所定回数しか行われないことを説明するための図である。

図８に示すように、リソース応札部１０２は、最初に、前回の最終入札値を最終入札値記憶部１０５から読み出して、その最終入札値を用いて入札値を計算し、入札を行う（入札（１））。その入札に対しては、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（１））。この落札（１）に応じて、次の（すなわち２回目の）入札値計算が行われ、入札が再度行われる（入札（２））。その入札（２）に対しても、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（２））。さらに、その落札に対しても再度入札が行われ（入札（３））、落札処理が行われる。なお、１回目と２回目のときは、ラウンド繰り返し管理部１０７から落札者決定部１０６へ、後述する打ち切り通知は出力されない。

このように、１回の入札に対する落札の処理を１ラウンドとして、ラウンド繰り返し管理部１０７は、入札の入力あるいは落札結果の出力があったときには、ラウンド数をインクリメントして、ラウンド数をカウントする。

ラウンド数が、所定の数になると、ラウンド繰り返し管理部１０７はラウンド数が所定の数になったことを検出する。その検出結果は、落札者決定部１０６に、打ち切り通知として通知される。落札者決定部１０６は、打ち切り通知の情報をリソース応札部１０２に通知する。打ち切り通知を受けた入札値計算部１０４は、再度、入札値計算をしないで、落札情報の最終入札値を、最終入札値記憶部１０５に書き込む。

以上のようにして、ラウンド数が入札処理の打ち切り条件として、所定の数以上入札が行われないようにしたので、本実施の形態のリソース管理装置は、所定時間内に確実に入札処理が終わらせることができるように構成されている。

（ｂ）処理単位時間
次に、処理単位時間について説明する。処理単位時間は、ここでは、各アプリケーションの実行時間である。図９は、処理単位時間を説明するための図である。図９は、ノード２の３つのアプリケーション（レーダー信号処理アプリケーション４３，ソナー信号処理アプリケーション４４、レーダー情報表示アプリケーション４５）が実行される場合を示す。図９は、３つのアプリケーションＡＰ１，ＡＰ２，ＡＰ３が、処理単位時間毎に割り当てられたリソースである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利用率をパーセンテージで指定している。入札価格である入札値は、リソースをいくらで消費または供給するかを仮想的な通貨で指定する。その指定は、リソースの単位ごとの単価で示してもよいし、総額(単価に数量を乗じた値)で示してもよい。図１０では単位利用率ごとの単価で示している。

落札者決定部１０６の動作を説明する。
まず、CPU利用率のように、供給者が一つで消費者が複数である場合の、すなわち本実施の形態では物理リソースマネージャ４２の入札管理部４２ｂの場合の、落札者決定部１０６の動作を説明する。この場合は、消費者からの入札に対して、入札値が高い順に、供給量がなくなるまで、あるいは消費者からの入札の入札値が供給者からの入札の入札値を下回るまで、リソースを割り当てることによって決定される。

その際の落札値は、入札量を全て満たすだけのリソースが割り当てられなかった消費者からの入札のうち最大の入札値か、あるいは供給者からの入札の入札値かのいずれかの高い方の額となる。

例として、図１０に示す入札が行なわれた場合、物理リソースマネージャからの供給量である１８０%が各アプリケーションの消費量に割り当てられる。この場合、入札値の高い順に、まずレーダー情報表示アプリケーション４５に利用率８０%が割り当てられる。次に、レーダー信号処理アプリケーションの１６０％に対して、残りの供給量１００％が割り当てられる。また、落札値は、レーダー信号処理アプリケーション（入札量１６０％を全て満たすだけのリソースは割り当てられていない）の入札値「３」が物理リソースマネージャの入札値「０」よりも高いので、「３」となる。

次に、落札者決定部１０６の動作を、ノード２のレーダー情報表示アプリケーション４５の入札管理部４５ｂが、図１１に示す内容に対して、入札を行った場合を例に説明する。図１１は、データの入札情報の例を示す図である。
図１１において、レーダー情報表示アプリケーション４５の消費量が「１００」となっているのは、レーダー情報表示アプリケーション４５は、１００％のデータをもらわなければ表示処理ができないことを意味している。ノード２のレーダー信号処理アプリケーション４３の供給量が「５８」となっているのでは、レーダー信号処理アプリケーション４３がレーダー情報を処理して供給できる割合（％）の最大値が「５８」であることを示している。この最大値「５８」は、ノード２においてレーダー信号処理アプリケーション４３が使えるCPU利用率から決定される値であり、レーダー情報１００％のうち５８％はレーダー信号処理アプリケーション４３によって処理してもよいとされる設定値である。同様に、ノード３のレーダー信号処理アプリケーション５３の供給量が「６４」となっているのでは、レーダー信号処理アプリケーション５３がレーダー情報を処理して供給できる割合（％）の最大値が「６４」であることを示している。この最大値「６４」は、ノード３においてレーダー信号処理アプリケーション５３が使えるCPU利用率から決定される値であり、レーダー情報１００％のうち６４％はレーダー信号処理アプリケーション５３によって処理してもよいとされる設定値である。

レーダー情報表示アプリケーション４５の入札値が「１９８０」となっているのは、レーダー情報表示アプリケーション４５は、入札価格の最大値が「１９８０」であることを意味している。ノード２のレーダー信号処理アプリケーション４３とノード３のレーダー信号処理アプリケーション５３の入札値が、共に「３７」となっているのは、入札価格の最小値が共に「３７」であることを意味している。

なお、ここでは入札値は、CPU利用率の単位利用率ごとの単価としたので、入札値の大きさを比較する際にはCPU利用率を考慮する必要はないが、総額を入札値として入札を行なう場合は、落札者決定部１０６において、入札値をCPU利用率で割ることによって単価を計算し、その単価を比較して落札者を決定する必要がある。

図１２は、供給者である物理リソースマネージャの落札者決定部１０６の処理の流れの例を示すフローチャートである。ここでは、ノード２の場合で説明する。

まず、落札者決定部１０６は、供給者の決定した供給量、すなわち供給者の入札情報における供給量を、供給量とする（ステップS31）。

落札者決定部１０６は、リソースの消費者からの入札情報の中で、価格が最も高い入札を選択する（ステップS32）。図１０の例であれば、レーダー情報表示アプリケーション４５が選択される。

落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値以上か否かの判定が行われる（ステップS33）。図１０の場合、供給者である物理リソースマネージャ４２の入札値は「１」であり、消費者であるレーダー情報表示アプリケーション４５の入札値は「４」であるので、ステップS33でYESの場合となり、ステップS34へ処理は移行する。

落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値未満であるときは、ステップS33でNOとなり、処理は終了する。

ステップS34では、落札者決定部１０６は、その消費者からの入札のうち、残りの供給量を超えない量を落札量と決定する。図１０の場合、レーダー情報表示アプリケーション４５の消費量８０が、供給量１８０から減算できるので、供給量を超えない量である消費量８０が落札量とされる。

次に、落札者決定部１０６は、残り供給量を算出する、すなわち、残り供給量から落札量を減算することによって残り供給量を算出する（ステップS35）。図１０の場合、供給量１８０から落札量８０を減算して、残り供給量１００が算出される。

そして、落札者決定部１０６は、残り供給量が０以下であるか否かを判定する（ステップS36）。

残り供給量が０を超えるときは、ステップS36でYESとなり、処理は、ステップS32に戻る。残り供給量が０以下のときは、ステップS36でNOとなり、処理は、終了する。

ステップS32では、落札者以外の消費者から入札について、上述したステップS32からS36までの処理を繰り返す。

以上のステップS31からS36までの処理が、所定の回数（ここでは３回）繰り返される。ステップS31からS36までの処理が、１ラウンドに対応する。
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを消費するリソース消費プログラムが複数ある場合、複数のリソース消費プログラムの中で、入札値の大きいプログラムを優先してリソースを割り当てるようにリソース割り当て処理を行なう。

一方、センサ情報のように、供給者が複数で消費者が一つである場合、すなわち本実施の形態ではレーダー情報表示アプリケーション４５の入札管理部４５ｂの場合、の落札者決定部の動作は、図１２において、「供給」と「消費」を読み替え、「高い」を「低い」と読み替えればよい。図１３は、情報表示アプリケーションの落札者決定部１０６の処理の流れの例を示すフローチャートである。

まず、落札者決定部１０６は、消費者の決定した消費量、すなわち消費者の入札情報における消費量を、消費量とする（ステップS41）。

落札者決定部１０６は、リソースの供給者からの入札情報の中で、価格が最も低い入札を選択する（ステップS42）。図１１の場合、ノード２のレーダー信号処理アプリケーション４３と、ノード３のレーダー信号処理アプリケーション５３とは、同じ入札値、すなわち「３７」であるので、ここでは、例えばこれら２つのアプリケーションに優先順位を予め設定しておくことにより、２つのアプリケーションのいずれかが選択される。例えば、レーダー信号処理アプリケーション４３が選択される。

落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値以下か否かの判定が行われる（ステップS43）。図１１の場合、消費者であるレーダー情報表示アプリケーション４５の入札値は、「１９８０」であるのでステップS43でYESの場合となり、ステップS44へ処理は移行する。

なお、落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値を超えるときは、ステップS43でNOとなり、処理は終了する。

落札者決定部１０６は、ステップS44では、その供給者からの入札のうち、残りの消費量を超えない量を落札量と決定する。図１１の場合、レーダー情報表示アプリケーション４５の消費量「１００」から供給量「５８」が減算できるので、消費量を超えない量である供給量「５８」が落札量とされる。

次に、落札者決定部１０６は、残り消費量を算出する、すなわち、残り消費量から落札量を減算することによって残り消費量を算出する（ステップS45）。図１１の場合、残り消費量１００から落札量５８を減算して、残り消費量４２が算出される。

そして、落札者決定部１０６は、残り消費量が０以下であるか否かを判定する（ステップS46）。

残り消費量が０を超えるときは、ステップS46でYESとなり、処理は、ステップS42に戻る。残り消費量が０以下のときは、ステップS46でNOとなり、処理は、終了する。

ステップS42では、落札者以外の供給者から入札について、上述したステップS41からS46までの処理を繰り返す。

以上のステップS41からS46までの処理が、所定の回数（ここでは３回）繰り返される。ステップS41からS46までの処理が、１ラウンドに対応する。
この繰り返し回数も、予め決められており、本実施の形態では、３である。
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを供給するリソース供給プログラムが複数ある場合、複数のリソース供給プログラムの中で、入札値の小さいプログラムを優先して前記リソースを割り当てるようにリソース割り当て処理を行なう。

（ｄ）ラウンド繰り返し管理部
図１２及び図１３で説明した処理の実行回数は、ラウンド繰り返し管理部１０７によりカウントされ、所定回数を超えて図１２及び図１３の処理が実行されないように、ラウンド繰り返し管理部１０７は、落札者決定部１０６における上述した処理の実行を制御する。

図１４は、ラウンド繰り返し管理部１０７の処理の流れの例を示すフローチャートである。ラウンド繰り返し管理部１０７は、上述したラウンドの繰り返し回数をカウントする（ステップS51）。ラウンド繰り返し管理部１０７は、カウントしたラウンド繰り返し回数が所定回数、本実施の形態では３回になったか否かを判定する（ステップS52）。そして、カウントしたラウンド繰り返し回数が所定回数にならなければ、処理は、ステップS52でNOとなり、ステップS51に戻る。カウントしたラウンド繰り返し回数が所定回数になると、ラウンド繰り返し管理部１０７は、図１１及び図１２の処理を終了させる実行終了処理を行う（ステップS53）。実行終了処理では、上述した打ち切り通知が、落札情報と共に、あるいは落札情報とは別に、リソース応札部１０２に出力される。

このように、ラウンド繰り返し管理部１０７は、内部にラウンドの回数を記憶し、ラウンドの度に１つずつインクリメントし、カウントしたラウンドの回数が上限すなわち所定回数に達したら、それ以上のラウンドを実行しないように、処理を打ち切る、すなわち終了させる。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。

この打ち切りによって、入札が一定の時間内に終了することが保証される。なお、ラウンドが終了したかどうかは入札を行なった処理部への落札結果の通知の際に、付加情報として通知される。

５．装置全体の動作
上述したようなリソース管理装置において、入札値計算部１０４における増減させる所定量等のパラメータを適宜設定することにより、最終的には、ノード２のレーダー情報表示アプリケーションが、ノード３のレーダー信号処理アプリケーションからレーダー情報を得て動作する、という結果に収束させることができる。

図１５及び図１６は、ラウンド数が「２０」までの、本実施の形態におけるリソース管理装置の入札と落札の状況を示す表である。図１５及び図１６では、連続した２０回のラウンドにおける入札値等のデータの例が示されているが、上述したラウンド繰り返し回数が「３」であるので、ラウンド１から３が、１回目の入札処理を経過と結果を示し、ラウンド４から６が、２回目の入札処理の経過と結果を示す。以下、同様に、３回のラウンドで、処理単位時間における入札処理が行われている。

上述したように、図１５及び図１６は、リソースの供給と消費の関係において、レーダー信号処理アプリケーションは１００％のレーダー情報を生成するためにCPU利用率１３５％を必要であり、ソナー信号処理アプリケーションは、１００％のソナー情報を生成するためにCPU利用率９０％を必要であり、レーダー情報表示アプリケーションは、１００％のレーダー情報を処理するのにCPU利用率９０％を必要であり、ソナー情報表示アプリケーションは、１００％のソナー情報を処理するのにCPU利用率３５％を必要であるという条件で処理が行われた場合の例を示す。また、入札値の計算の際に値を増減させる微少量は、入札値では「４」で、入札量では「３」という値である場合が示されている。そして、入札では、ノード２と３のそれぞれのCPU利用率、レーダー情報及びソナー情報の４つのリソースについて、それぞれ入札参加者からの入札が行われ、落札量と落札値が決定されている。

図１５及び図１６では、２０回目以降のラウンドでは、リソースが適切に割り当てられている。２０回目のラウンドの結果を見ると、ノード２では、レーダー信号処理アプリケーションがCPU利用率７８％でレーダー情報５８％を生成し、ソナー信号処理アプリケーションがCPU利用率４２％でソナー情報３７％を生成している。ノード３では、レーダー信号処理アプリケーションがCPU利用率８６％でレーダー情報４２％を生成し、ソナー信号処理アプリケーションがCPU利用率５６％でソナー情報６３％を生成している。

これらの割り当て結果は、レーダー信号処理アプリケーションは、１００％のレーダー情報を生成するのに、CPU利用率１３５％を必要とし、ソナー信号処理アプリケーションは、１００％のソナー情報を生成するのに、CPU利用率９０％を必要とするという条件を満たしている。また、レーダー情報表示アプリケーションは６０％のCPU利用率で、ソナー情報表示アプリケーションは３５％のCPU利用率という条件も満たしている。さらに、レーダー情報表示アプリケーションは１００％のレーダー情報を落札し、ソナー情報表示アプリケーションは１００％のソナー情報を落札しているので、それぞれ表示に必要なデータも問題なく得ている。２０回目の以前のラウンドでは、一応の動作は可能であるが、CPU利用率が十分に割り当てられていない場合もあるので、装置全体のリアルタイム性が満足されていない状態となる虞がある。しかし、このような状態は、入札初期の状態のときだけで生じるので、全体として問題はない。

本実施の形態では、レーダー情報がソナー情報よりも重要であるので、レーダーの信号処理と情報表示がソナーの信号処理と情報表示よりも優先されて実行されるように、入札値の上限値が設定されている。上述した例では、２つのセンサ情報表示アプリケーション間で、買値の上限値を異ならせ、各センサ情報表示アプリケーションは、その上限値の範囲内で、自己が消費するリソースを買って動作を行なう。なお、この上限値は、状況に応じて設定変更可能とすれば、各アプリケーションの重要度は、状況に応じて変更可能となる。

また、レーダー情報表示アプリケーションによってCPU利用率が落札されてCPU利用率の価格が上がっているノード２よりも、ノード３の方がCPU利用率の入札値が低いので、ノード２のレーダー情報処理アプリケーションよりもノード３のレーダー情報処理アプリケーションの方がレーダー情報のリソースとしての入札値（売値）が低いため、レーダー情報表示アプリケーション４５は、ノード３のレーダー情報処理アプリケーション５３からレーダー情報を買うことになり、ノード３のレーダー情報処理アプリケーション５３が動作している。

さらに、リソース応札部１０２において、最終入札値記憶部１０５が設けられているため、次の処理単位時間における入札処理では、前回の入札結果に基づいて、入札値が計算されるので、適切な状態に収束するまでの時間が長く掛かるということが回避されている。

すなわち、入札処理を単純に打ち切ってしまうのでは対応として不十分となる虞があるため、上述したように、複数のラウンドの入札処理が実行される。これは、リソースの割り当て効率を漸進的に改善するためであるが、少数のラウンドでは十分に改善が進まないこともあり得る。そのような場合、処理単位時間毎の入札でのリソース割り当てが非効率、つまりその局面での信号処理の重要度などを正しく考慮したリソース割り当てた方ができない状態が続いてしまう。そのような場合に、もし最終入札値記憶部がなければ、生産者や消費者の入札値は処理単位時間ごとに毎回0から開始することになり、適切な割り当て状態に収束するまでには多くの回数の、上述の場合であれば２０回以上のラウンドを経なければならない。そのため、上述したように、本実施の形態では、入札を一定の時間内に終了することを保証するためにラウンド繰り返し管理部によってラウンドを例えば５回で打ち切っても、例えば４つの処理単位時間を経ることによって適切な割り当て状態に収束するように、最終入札値記憶部によって前回の入札値が記憶されている。

なお、変形例として、上述した実施の形態では、ラウンドの打ち切り条件は繰り返し回数であるが、ラウンド繰り返し管理部は、ラウンドの回数ではなくラウンドの実行時間を計測して所定時間に達したらラウンドの打ち切りを行なうようにしてもよい。
この所定の時間はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。あるいは、時間計測によるラウンドの打ち切りの方法としては、初回ラウンド時にOSが提供するタイマー機能を利用して、タイマーを設定し、その設定した時間が経過したことを通知させて打ち切りを行なうようにしてもよい。
また、初回ラウンド時にOSのリアルタイムクロックを読み出して時刻をラウンド繰り返し管理部に記憶し、ラウンドの度に現在の時刻と記憶された時刻との差を計算して一定の時間が達したかどうかを判定する、といった方法も可能である。

なお、以上説明した本実施の形態では、センサ情報システム１は、説明の簡単のために、２つのノード２，３からなるシステムであるが、３以上のノードを含むものであってもよい。また、センサ信号を出力するレーダー装置２５とソナー装置３５は、それぞれノード２と３に接続されているが、それぞれがセンサ信号を出力する複数の装置が、１つのノードに接続されるように、システムが構成されていてもよい。すなわち、ノードの中には、センサ信号を出力する装置が接続されていないものがあったり、それぞれがセンサ信号を出力する複数の装置が接続されているものがあってもよい。

さらになお、上述した実施の形態では、各ノードには、２つのCPUが設けられているが、１つあるいは３以上のCPUが設けられていてもよく、各ノード内部のバスにより、一つまたは複数のCPUが他の回路とバスで接続される。

以上のように、上述した本発明の実施の形態によれば、サプライチェーン入札などの高度な入札にもとづいたリアルタイムシステムにおいて、回数または時間などの条件によって複数ラウンド入札におけるラウンドを打ち切ることにより、入札のリアルタイム性を確保しながら、リソースの割り当てが実現できる。すなわち、上述した実施の形態のリソース管理装置は、データの重要性に応じて、リアルタイム性を確保しながら、対応するアプリケーションを実行させるようにすることができる。

また、前回の処理単位時間の入札における最終入札値を記録して次の処理単位時間の入札の初期値に利用することにより、入札値が長期的には打ち切りのない複数ラウンド入札値に漸近するという効果がある。

本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明する。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。

さらになお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のリソース管理装置を実現することができる。

本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明の実施の形態に係わるセンサ情報処理システムの構成を示す構成図である。 ２つのノードのソフトウエア構成におけるリソース管理の部分を説明するためのブロック構成図である。 本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。 リソース管理装置を構成するリソース応札部と入札管理部の構成を示すブロック図である。 供給者の入札値計算部の処理の流れの例を示すフローチャートである。 生産者が供給するリソースについての入札値計算部の処理の流れの例を示すフローチャートである。 消費者の入札値計算部の処理の流れの例を示すフローチャートである。 ラウンド繰り返し管理部により、入札処理が所定回数しか行われないことを説明するための図である。 処理単位時間を説明するための図である。 物理リソースの入札情報の例を示す図である。 データの入札情報の例を示す図である。 供給者である物理リソースマネージャの落札者決定部の処理の流れの例を示すフローチャートである。 情報表示アプリケーションの落札者決定部の処理の流れの例を示すフローチャートである。 ラウンド繰り返し管理部の処理の流れの例を示すフローチャートである。 ラウンドが経過するにつれて、CPU利用率の入札と落札の量と値が変化する例を示す表である。 ラウンドが経過するにつれて、データの入札と落札の量と値が変化する例を示す表である。

符号の説明

１ センサ情報システム、２、３ ノード、４ ネットワーク、２７，３７ バス、１０１ リソース管理装置

Claims (5)

1. 複数のアプリケーションプログラムのそれぞれに対応して設けられ、前記複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースについて、入札値を計算して前記入札値の情報を生成する複数のリソース応札部と、
   該複数のリソース応札部からの前記入札値の情報に基づいて、前記所定の単位時間における、前記複数のアプリケーションプログラムのそれぞれに割り当てる前記リソースを決定するリソース割り当て処理を行なう入札管理部と、
   前記所定の単位時間において、入札打ち切り条件が満たされるまで前記リソース割り当て処理が繰り返されるように前記入札管理部を管理する繰り返し管理部と、
   を有することを特徴とするリソース管理装置。
2. 前記複数のリソース応札部は、それぞれ前記所定の単位時間において最終的に落札された入札値を記憶する最終入札値記憶部を有し、
   前記複数のリソース応札部のそれぞれは、前記所定の単位時間における最初の入札値として、前記最終入札値記憶部に記憶された前記入札値を用いるようにしたことを特徴とする請求項１記載のリソース管理装置。
3. 前記入札打ち切り条件は、前記割り当て処理の繰り返し回数、又は前記所定の単位時間内の所定時間であることを特徴とする請求項１又は請求項２に記載のリソース管理装置。
4. 前記複数のアプリケーションプログラムは、レーダー装置からのレーダー信号を処理するプログラムと、前記レーダー信号に基づくレーダー情報を表示するプログラムと、ソナー装置からのソナー信号を処理するプログラムと、前記ソナー信号に基づくソナー情報を表示するプログラムとを含むことを特徴とする請求項１から３のいずれか１つに記載のリソース管理装置。
5. 入札管理部と、繰り返し管理部と、複数のアプリケーションプログラムのそれぞれに対応して設けられた複数のリソース応札部とを具備したコンピュータにおいて、
   前記複数のリソース応札部により、前記複数のアプリケーションプログラムのそれぞれが所定の単位時間内に消費または供給するリソースについて、入札値を計算して前記入札値の情報を生成する手順と、
   前記入札管理部により、前記複数のリソース応札部からの入札値情報に基づいて、前記所定の単位時間における、前記複数のアプリケーションプログラムのそれぞれに前記リソースを割り当てる手順と、
   前記繰り返し管理部により、前記所定の単位時間において、入札打ち切り条件が満たされるまで前記リソース割り当て処理が繰り返されるように前記入札管理部を管理する手順と、
   を実行させるためのプログラム。
   

Images