(57)【要約】【課題】アプリケーションの新規起動を抑制できるリソース管理装置を提供すること。【解決手段】複数のアプリケーションのそれぞれが予め定められた単位時間内に消費または供給するリソースの仮想的な価格を示す入札値を算出し、算出した入札値を入力することにより入札を行うリソース応札部４３ａ、４４ａと、リソース応札部４３ａ、４４ａが入力した入札値に基づいて、複数のアプリケーションのそれぞれに、単位時間におけるリソースを割り当てる入札管理部４２ｂ、４５ｂと、を備え、リソース応札部４３ａ、４４ａは、アプリケーションの起動の有無を判断し、起動されていないアプリケーションより起動されているアプリケーションに対してリソースを優先して割り当てる入札値を算出する。【選択図】        図２
2008158921.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.）
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかしながら、このような方式では、少数のノードだけで処理が可能であるのにもかかわらず、多数のノードに処理が分散されるという現象が生じる場合があった。そして、この現象によって、本来起動する必要のないノードでもアプリケーションが起動され、アプリケーションの起動処理のためにＣＰＵ時間が消費されるという問題があった。また、ノードが増える分、システム全体におけるアプリケーションの実行のためのメインメモリやキャッシュメモリの消費量が増加するという問題があった。
【００２０】
特に、上述のようなリアルタイムシステムでは、時間制約を守って処理を行なうために、単位時間毎にリソース割り当てを行なう必要がある。この場合、タスクの起動から終了までを単位としてリソース割り当てを行なう場合と比べて、アプリケーションの起動処理のためのＣＰＵ時間の相対的なコストが高いため、より大きな影響が生じる。
【００２１】
本発明は、上記に鑑みてなされたものであって、入札によりリソースを割り当てる方法において、アプリケーションの新規起動を抑制できる装置、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２２】
上述した課題を解決し、目的を達成するために、本発明は、入札方式でリソースを割り当てるリソース管理装置であって、複数のアプリケーションのそれぞれが予め定められた単位時間内に消費または供給する前記リソースの仮想的な価格を示す入札値を算出し、算出した前記入札値を入力することにより入札を行うリソース応札部と、前記リソース応札部が入力した前記入札値に基づいて、複数の前記アプリケーションのそれぞれに、前記単位時間における前記リソースを割り当てる入札管理部と、を備え、前記リソース応札部は、前記アプリケーションの起動の有無を判断し、起動されている前記アプリケーションに対して前記リソースを優先して割り当てる前記入札値を算出すること、を特徴とする。
【００２３】
また、本発明は、上記装置を実行することができるプログラムである。
【発明の効果】
【００２４】
本発明によれば、市場メカニズムによるリソース割り当て方式において、アプリケーションを起動するノードの数を抑制することによって、アプリケーション起動によるＣＰＵ、メインメモリ、またはキャッシュメモリなどのリソースの消費を低減することができるという効果を奏する。
【発明を実施するための最良の形態】
【００２５】
以下に添付図面を参照して、この発明にかかるリソース管理する装置、およびプログラムの最良な実施の形態を詳細に説明する。
【００２６】
（第１の実施の形態）
市場メカニズムによるリソース割り当て方式で、アプリケーションの新規起動を抑制するためには、１つのアプリケーションの処理を割り当てるノードの数をできるだけ減らす、という方針で処理を割り当てる方法が考えられる。
【００２７】
しかし、この割り当て方針を、ノードをまたがってシステム全体でのアプリケーションの起動数を制御する、といった一般的な方式で実現しようとすると、システム全体の集中管理が必要となる。これは、集中管理を行わずに処理の割り当てを行なう、という市場メカニズム導入の趣旨に反する。
【００２８】
そこで、集中管理を行わずに市場メカニズム上でこのような割り当てを行なう方法として、上記の割り当て方針を入札時にコストとして反映する、という方法が考えられる。すなわち、アプリケーションがまだ起動されていないノードは、すでにアプリケーションが起動されているノードよりもコスト分を上乗せした高い売値で入札を行なえばよい。
【００２９】
この方式によれば、コストを上回るほどアプリケーションの新規起動が必要な状態でのみ、アプリケーション未起動ノードのアプリケーションからの入札が落札に成功して起動されるので、新規起動が必要最小限に抑えられる。アプリケーションの新規起動が必要な状態としては、ノードの故障や、すでにアプリケーションが起動されているノードの過負荷などが生じた場合が想定される。
【００３０】
この方式では、アプリケーションが起動されていないノードでの入札を行なう機構が問題となる。本方式では入札はアプリケーションが自ら行なうことを前提とするため、アプリケーション未起動ノードでは、アプリケーションが入札に参加できないためである。
【００３１】
そこで、第１の実施の形態にかかるリソース管理装置は、入札を行なうアプリケーションを、アプリケーションが本来目的とする信号処理などの処理を行なうロジック処理部と、入札を行なうリソース応札部とに分離し、リソース応札部だけを起動しておく、という方法を採る。ロジック処理部は、アプリケーション未起動ノードのリソース応札部が落札に成功した際に別途起動される。
【００３２】
本実施の形態では、クライアント・サーバ方式によるアプリケーションの実現を前提としているため、アプリケーションはサーバとして実現され、クライアントからの呼び出しを受けて処理を行なう。なお、本実施の形態ではアプリケーションが直接ＴＣＰ／ＩＰによって通信処理を行なう形態を示すが、通信処理をＣＯＲＢＡ（Common Object Request Broker Architecture）などの分散ミドルウェアに行なわせる形態での実施も可能である。
【００３３】
１．システムのハードウェア構成
まず図１に基づき、第１の実施の形態に係わるシステムのハードウェア構成を説明する。図１は、第１の実施の形態に係わるセンサ情報処理システム（以下、センサ情報システムという）のハードウェア構成を示す構成図である。本実施の形態に関わるセンサ情報システムは、船舶、航空機等に用いられる。センサ情報システムは、ここでは、レーダー装置とソナー装置からのセンサ信号に基づいて、周囲の状況をセンサ情報として乗組員等に知らせるシステムである。センサ情報システムは、特にかつ危険な障害物等を検知した場合に、すばやく、すなわちその検知をしてから所定の時間内に乗組員等にそのセンサ情報を画面表示等により告知する、いわゆるリアルタイムシステムである。なお、リアルタイムシステムとは、所定の時間内に所定の処理が実行される、例えば、センサ信号を検知してから所定の時間としての１秒以内に、表示装置の画面上に所定のセンサ情報を表示する処理が実行されるようなシステムをいう。
【００３４】
センサ情報システム１は、複数のノード、ここでは２つのノード２、３がネットワーク４を介して接続されて構成されている。ノード２には、レーダー装置５と端末装置６とが接続されている。ノード２は、所定の信号処理を行い、信号処理の結果を端末装置６の表示装置６ａの画面上に表示する処理を行うコンピュータ装置である。後述するように、ノード２は、レーダー装置５とソナー装置７のそれぞれの信号に基づいて所定の信号処理を行う信号処理アプリケーションプログラム（以下、アプリケーションプログラムを単にアプリケーションということもある）と、レーダー装置５の信号に関する信号処理の結果を表示装置６ａに表示するために情報表示アプリケーションプログラムとを含む。
【００３５】
ノード３には、ソナー装置７と端末装置８とが接続されている。ノード３は、所定の信号処理を行い、信号処理の結果を端末装置８の表示装置８ａの画面上に表示する処理を行うコンピュータ装置である。後述するように、ノード３は、ソナー装置７とレーダー装置５のそれぞれの信号に基づいて所定の信号処理を行う信号処理アプリケーションプログラムと、ソナー装置７の信号に関する信号処理の結果を表示装置８ａに表示するために情報表示アプリケーションプログラムとを含む。
【００３６】
また、後述するように、レーダー装置５のセンサ信号は、ネットワーク４を介して、ノード３へ送信され、ソナー装置７のセンサ信号も、ネットワーク４を介して、ノード２へ送信されるように構成されている。
【００３７】
ノード２は、端末装置６の表示装置６ａの画面上に、レーダー情報を表示し、ユーザに対してレーダー装置５のセンサ信号に関する情報を、いわゆるリアルタイムで提示することができる。同様に、ノード３は、端末装置８の表示装置８ａの画面上に、ソナー情報を表示し、ユーザに対してソナー装置７のセンサ信号に関する情報を、いわゆるリアルタイムで提示することができる。
【００３８】
従って、本実施の形態では、レーダー装置５とソナー装置７という２つのセンサ装置からのセンサ情報の情報処理は、２つのノード２、３において行なわれ、処理結果であるレーダー情報とソナー情報が、それぞれの端末装置６、８の表示装置６ａ、８ａの画面上にリアルタイムで表示される。例えば、船舶の場合であれば、障害物がレーダー装置５で検知されるとその障害物の位置情報等がセンサ情報として画面上にリアルタイムで表示される。
【００３９】
ノード２は、２つの中央処理装置（以下、ＣＰＵと略す）２１、２２、メモリ２３、ネットワークインターフェース（以下、ネットワークＩ／Ｆと略す）２４、レーダー装置インターフェース（以下、レーダー装置Ｉ／Ｆと略す）２５、および端末装置インターフェース（以下、端末装置Ｉ／Ｆと略す）２６を含んで、お互いにバス２７を介して接続されて構成されている。
【００４０】
同様に、ノード３は、２つのＣＰＵ３１、３２、メモリ３３、ネットワークＩ／Ｆ３４、ソナー装置インターフェース（以下、ソナー装置Ｉ／Ｆと略す）３５、および端末装置Ｉ／Ｆ３６を含んで、お互いにバス３７を介して接続されて構成されている。
【００４１】
なお、バス２７、３７は、各ノードの基板間あるいは基板上の配線でもよいし、チップ内部の配線であってもよい。ネットワークＩ／Ｆ２４と３４は、それぞれノード２と３とをネットワーク４と接続するためのインターフェースである。端末装置Ｉ／Ｆ２６と３６は、それぞれノード２と３とをそれぞれの端末装置６と８と接続するためのインターフェースである。レーダー装置Ｉ／Ｆ２５を介して、ノード２とレーダー装置５とは接続されている。ソナー装置Ｉ／Ｆ３５を介して、ノード３とソナー装置７とは接続されている。
【００４２】
ネットワーク４は、リアルタイム性が保証されるネットワークでも、イーサネット（登録商標）Ethernet（登録商標）などのリアルタイム性が保証されないネットワークでもよい。
【００４３】
なお、図１では、レーダー装置５とソナー装置７は、それぞれインターフェースを介して、ノード２と３に接続されているが、ネットワークインターフェースを内蔵して、ネットワーク４に直接接続されるようにしてもよい。その場合、レーダー装置５とソナー装置７からの信号は、ネットワーク４を介して、それぞれノード２と３に伝達される。
【００４４】
さらになお、上述した説明では、端末装置６と８がそれぞれノード２と３に接続されているが、図１の一点鎖線で示すように、端末装置６と８に代えて、あるいは端末装置６と８に加えて、さらにネットワーク４に接続された別の端末装置９を設けてもよい。端末装置６と８に代えて端末装置９を設けた場合は、端末装置９の表示装置９ａ上に、レーダー情報とソナー情報を表示するようにし、あるいは端末装置６と８に加えて端末装置９を設けた場合は、端末装置９の表示装置９ａ上にのみ、あるいは端末装置９の表示装置９ａ上にも併せて、レーダー情報とソナー情報を表示するようにしてもよい。
【００４５】
また、図示はしないが、センサ情報システム１には、表示装置、キーボードなどを備えた端末装置が１つ以上存在し、ノード２と３のうち１つに接続されている。
【００４６】
２．システムのソフトウェア構成
次に、図２に基づき、ノード２と３のソフトウェア構成を説明する。図２は、第１の実施の形態における、ノード２と３におけるソフトウェア構成のリソース管理の部分を説明するためのブロック図である。
【００４７】
ノード２と３は、レーダー信号とソナー信号の信号処理と、レーダー情報表示あるいはソナー情報表示の表示処理とを実行するアプリケーション実行装置であるが、ＣＰＵ時間等のリソースを管理するリソース管理装置でもある。すなわち、ノード２と３は、レーダー信号とソナー信号に基づく信号処理を行い、その処理結果をレーダー情報あるいはソナー情報として、端末装置６と８の表示装置６ａと８ａにリアルタイムで表示するセンサ情報処理を行うが、そのようなリアルタイムのセンサ情報の処理のためにリソース管理も行っている。その意味で、ノード２と３は、リソース管理装置を構成し、リソース管理装置は、アプリケーションプログラムを各ノード上で実行するために動作するソフトウェアプログラムにより、主として実現されるコンピュータ装置である。
【００４８】
ノード２において、１つのＯＳ４１は、ハードウェアである２つのＣＰＵ２１、２２上で動作する。ＯＳ４１は、マルチプロセッサ対応のＯＳであり、例えば、ウインドウズ（登録商標）、リナックス等のＯＳである。ＯＳ４１の上には、物理リソースマネージャ４２が設けられており、リソースとしてのＣＰＵ時間を管理する。
【００４９】
物理リソースマネージャ４２を介して、レーダー信号処理部であるレーダー信号処理ＡＰ（アプリケーション）４３、ソナー信号処理部であるソナー信号処理ＡＰ（アプリケーション）４４およびレーダー情報表示部であるレーダー情報表示ＡＰ（アプリケーション）４５の、３つのアプリケーションプログラムが、ＯＳ４１上で動作する。
【００５０】
ノード３においても、１つのＯＳ５１は、ハードウェアである２つのＣＰＵ３１、３２上で動作する。ＯＳ５１も、マルチプロセッサ対応のＯＳである。ＯＳ５１の上には、物理リソースマネージャ５２が設けられており、リソースとしてのＣＰＵ時間を管理する。
【００５１】
物理リソースマネージャ５２を介して、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４およびソナー情報表示アプリケーション５５の、３つのアプリケーションプログラムが、ＯＳ５１上で動作する。
【００５２】
物理リソースマネージャ４２、５２は、各アプリケーションプログラムを実行する場合に、後述するように、各アプリケーションからの入札に対して、所定の処理を行い、各アプリケーションが落札したＣＰＵ時間だけ、各アプリケーションを実行させるように、ＣＰＵ時間を管理する。
【００５３】
リソース管理装置が動作する各ノードは、１つのＯＳ４１、５１によりソフトウェアおよびハードウェアが管理される。本実施の形態では、各ノードには２つのＣＰＵが存在するが、１つのノードに複数のＣＰＵが存在する場合でも、マルチプロセッサ対応のＯＳが１つ動作し、各ノード全体のリソースをそのＯＳが管理する。物理リソースの管理は、各ＯＳの上で動作するミドルウェアとして実現される物理リソースマネージャ４２、５２により行われる。なお、物理リソースマネージャ４２、５２は、ＯＳ内部の機能として実現されていてもよい。
【００５４】
リソース管理装置は、複数のリソース応札部・複数の入札管理部・複数のロジック処理部を含んで構成される。具体的には、ノード２において、物理リソースマネージャ４２は、リソース応札部４２ａと、入札管理部４２ｂとを有する。
【００５５】
レーダー信号処理アプリケーション４３は、リソース応札部４３ａを含むラッパー４３ｃと、ロジック処理部４３ｄとを含む。ソナー信号処理アプリケーション４４は、リソース応札部４４ａを含むラッパー４４ｃと、ロジック処理部４４ｄとを含む。レーダー情報表示アプリケーション４５は、リソース応札部４５ａと、入札管理部４５ｂと、ロジック処理部４５ｄとを有する。同様に、ノード３において、物理リソースマネージャ５２は、リソース応札部５２ａと、入札管理部４２ｂとを有する。レーダー信号処理アプリケーション５３は、リソース応札部５３ａを含むラッパー５３ｃとロジック処理部５３ｄとを含む。
【００５６】
ソナー信号処理アプリケーション５４は、リソース応札部５４ａを含むラッパー５４ｃと、ロジック処理部５４ｄとを含む。ソナー情報表示アプリケーション５５は、リソース応札部５５ａと、入札管理部５５ｂと、ロジック処理部５５ｄを有する。すなわち、各リソース応札部４２ａ、４３ａ、５２ａ、５３ａ等は、リソースの供給または消費を行なうモジュールである処理部（ここでは、物理リソースマネージャ４２、５２およびレーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４等）の内部に設けられている。
【００５７】
なお、一部のアプリケーションのみにリソース応札部を設けるようにしてもよい。例えば、リソースをあまり消費しないアプリケーションには、入札への参加を省略すべくリソース応札部を設けず、逆に、リソースを大量に消費するアプリケーションのみにリソース応札部を設けるようにする、といった構成でもよい。この場合、入札へ参加しないアプリケーションが消費するリソースは、ある程度余裕を持つようにするなどの方法で、別途固定的に割り当てておく必要がある。
【００５８】
一方、入札管理部は、ノード毎に、全体で１つ設けてもよいし、複数設けてもよい。また、入札管理部は、独立したミドルウェアやＯＳ内部の機能として実現してもよいし、あるいは、いずれかの処理部の内部で実現してもよい。一般に、供給者が１つで消費者が複数の場合は供給者の内部で実現し、供給者が複数で消費者が１つの場合は消費者の内部で実現すると入札の際の処理や通信が簡単になる。そこで、本実施の形態では、物理リソースマネージャ４２、５２（供給者）は、複数のアプリケーション（消費者）にＣＰＵ利用率を供給するだけであるので、物理リソースマネージャ４２、５２の内部に入札管理部４２ｂ、５２ｂを設けている。そして、センサ情報表示アプリケーション（消費者）は、複数のアプリケーション（供給者、生産者）から、ＣＰＵ利用率とセンサ情報を受けるだけであるので、センサ情報表示アプリケーション内部に入札管理部４５ｂ、５５ｂが設けられている。例えば、ノード２では、物理リソースマネージャ４２内部に入札管理部４２ｂが設けられ、そしてレーダー情報表示アプリケーション４５内部に入札管理部４５ｂが設けられている。
【００５９】
さらに、情報表示アプリケーションのように電源投入時から常に起動されるアプリケーションについては、ロジック処理部を分離せず、アプリケーション本体と一体で実現することも可能である。なお、ラッパー４３ｃ、４４ｃ、５３ｃ、５４ｃの機能の詳細については後述する。
【００６０】
３．リソースの供給と消費
３．１  リソース
ここで、リソースについて説明する。本実施の形態は、物理リソースであるＣＰＵ利用率に加えて、アプリケーションプログラムが生成したデータもリソースとして扱う、サプライチェーンモデルに基づく例である。
【００６１】
データもリソースとして扱うのは、次の理由による。すなわち、各センサ信号の信号処理部と各センサ情報の情報表示部とが分離されているため、センサ情報をリソースとして扱わずにＣＰＵ利用率のみをリソースとして扱うと、センサ情報の供給と消費関係を無視したリソースの割り当てが生じるおそれがある。例えば、ソナー信号処理アプリケーション４４、５４にＣＰＵ利用率が割り当てられて実行されるが、ソナー情報表示アプリケーション５５にはＣＰＵ利用率が割り当てられずに実行ができないという状況があり得る。その場合、利用されないセンサ情報を生成するためにＣＰＵが浪費される、といった状態が生じる。このような状態が生じないようにしながら、各信号処理部と各情報表示部とを分離できるようにするために、ＣＰＵ利用率に加えてデータもリソースとして扱われている。
【００６２】
なお、ＣＰＵ利用率は、後述する単位処理時間当たりにおける、そのアプリケーションが使用する割合（％）である。例えば、単位処理時間が、１秒で、ＣＰＵ利用率が３０％であれば、そのアプリケーションは、３００ｍｓだけＣＰＵを使用できることを意味する。本実施の形態では、ＣＰＵ利用率（％）を用いるが、ＣＰＵ使用時間（ｍｓ等）を用いてもよい。また、データは、本実施の形態では、レーダー情報とソナー情報である。
【００６３】
図３は、本実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。図３に示すように、本実施の形態のサプライチェーンモデルにおいて、物理リソースマネージャ４２、５２は、供給者に対応し、レーダー信号処理アプリケーション４３、５３とソナー信号処理アプリケーション４４、５４は、生産者に対応し、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５は消費者に対応する。
【００６４】
リソースの供給のみを行う供給者である物理リソースマネージャ４２、５２は、物理リソースであるＣＰＵ利用率の管理を行なうミドルウェアである。なお、物理リソースマネージャ４２、５２は、ＯＳの一部として、ＯＳの中に組み込まれたものであってもよい。
【００６５】
ＣＰＵ利用率は、供給者である物理リソースマネージャ４２、５２から、各アプリケーションに供給される。図３の場合、ＣＰＵ利用率は、物理リソースマネージャ４２から、レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４およびレーダー情報表示アプリケーション４５に供給される。物理リソースマネージャ５２から、レーダー信号処理アプリケーション５３、ソナー信号処理アプリケーション５４およびソナー情報表示アプリケーション５５に供給される。
【００６６】
生産者であるレーダー信号処理アプリケーション４３、５３およびソナー信号処理アプリケーション４４、５４は、それぞれ、ＣＰＵ利用率を消費して所定のセンサ情報を生成して、レーダー情報表示アプリケーション４５とソナー情報表示アプリケーション５５に供給する。すなわち、アプリケーションのうちセンサ信号処理アプリケーションは、センサ情報を供給する生産者である。
【００６７】
消費者であるレーダー情報表示アプリケーション４５およびソナー情報表示アプリケーション５５は、ＣＰＵ利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない。すなわち、アプリケーションのうち情報表示アプリケーションは、ＣＰＵ利用率とセンサ情報とを消費するのみで、リソースを他のアプリケーションに供給しない消費者である。
【００６８】
アプリケーションである各処理部は、自己が消費する全てのリソースが落札できた場合のみ動作する。なお、各信号処理部は、ノード２、３間の負荷分散のため両方のノードに存在するが、いずれか一方のみが実行されれば、センサ情報は生成される。例えば、レーダー情報表示アプリケーション４５は、ＣＰＵ利用率が割り当てられ、かつレーダー信号処理アプリケーション４３と５３のいずれか一方からレーダー情報の供給を受ければ、実行される。
【００６９】
３．２  リソースの供給方法
リソースの供給について説明する。リソースの供給のうち、データであるセンサ情報の供給は、信号処理アプリケーションが、実際にセンサ情報表示アプリケーションに、センサ情報を供給することによって行なわれる。例えば、レーダー信号処理アプリケーション４３が、信号処理の結果得られたレーダー情報を、レーダー情報表示アプリケーション４５に供給することが、センサ情報の供給となる。
【００７０】
一方、ＣＰＵ利用率の供給は概念上のものであって、明示的な受渡しはなく、アプリケーションプログラム作成の際に、ＣＰＵ利用率を落札できた場合のみＣＰＵを利用して実行されるようにそのプログラムを作成することによって実現される。なお、アプリケーションが第三者によって作成された場合など、アプリケーションの実際の挙動が信用できない場合には、アプリケーションが実際に落札した分のＣＰＵ利用率しか使用していないかを、物理リソースマネージャ４２、５２がＯＳの状態を監視するなどの方法でチェックするようにしてもよい。その場合、落札された以上のＣＰＵ利用率を使用していた場合は、そのアプリケーションを割り込み処理により強制終了したりすることによって、ＣＰＵ利用率の割り当てを強制的に守らせるようにすることも可能である。以上のリソースの割り当てが、リソース管理装置の入札によって行なわれる。
【００７１】
３．３  リソース割り当ての決定方法
（ａ）ＣＰＵ利用率
まず、物理リソースであるＣＰＵ利用率の消費量および供給量の決定方法について述べる。各アプリケーションは、処理単位時間ごとにそのアプリケーションが使用するＣＰＵ利用率、すなわち消費量を計算し、明示あるいは決定する。その決定は、アプリケーション作成者がアプリケーションのソースコード中に数値または計算式を明示的に記述することで行なってもよいし、コンパイラがコンパイル時に判定することで行なってもよい。さらに、各アプリケーションが、自己が実行された時に物理リソースマネージャ４２、５２やＯＳの状態を監視するなどの方法で実測し、測定履歴から今後の物理リソース使用量を推定するといった方法で行なってもよい。
【００７２】
物理リソースマネージャ４２、５２は、アプリケーションに供給できるリソースの供給量を計算する。本実施の形態では、ＣＰＵ台数分の全利用時間に対する割合を示すパーセンテージからＯＳやミドルウェアの動作や安全のためのマージンを差し引いた値がアプリケーションへの供給量である。本実施の形態では、各ノードは、ＣＰＵ２台分にあたる２００％からマージン２０％を差し引いた１８０％を供給量とする。
【００７３】
（ｂ）センサ情報
次に、センサ情報の消費量および供給量の決定方法について述べる。物理リソース以外のリソースであるセンサ情報は、アプリケーション作成者がアプリケーションのソースコード中にアプリケーションのロジックの一部として数値または計算式を明示的に記述することによって消費量および供給量が指定される。
【００７４】
例えば、ソナー信号処理アプリケーション４４は、センサ装置であるソナー装置７から所定のサンプリング周期でセンサ信号を受けるので、そのセンサ信号の量（ビットレート等）が消費量となる。また、ソナー信号処理アプリケーション４４は、所定の信号処理を行って、センサ情報をソナー情報表示アプリケーション５５に供給するので、そのセンサ情報の量（ビットレート等）が供給量となる。
【００７５】
また、後述するように、入札に基づいて消費量と供給量は変化するが、各ノードでは、各ノードに供給されるセンサ信号量に応じてＣＰＵ利用率も変化する。例えば、ノード２では、ノード２に供給されるセンサ信号量に応じてＣＰＵ利用率は変化し、同様にノード３でも、ノード３に供給されるセンサ信号量に応じてＣＰＵ利用率は変化する。従って、例えばレーダー装置５から出力されるセンサ信号の全量は、ノード２とノード３に、それぞれ分担され、各ノードは、その分担された量に対応したＣＰＵ利用率が必要となる。
【００７６】
（ｃ）リソース割り当ての通知
各処理部において、以上の手順で決定あるいは指定された消費量または供給量は、処理部の内部に実現されたリソース応札部に通知される、リソース応札部は、その消費量または供給量に対応する入札を入札管理部に対して行なう。
【００７７】
４．リソース管理装置の構成
４．１  リソース管理装置
図４は、リソース管理装置を構成するリソース応札部と入札管理部の構成を示すブロック図である。
【００７８】
本実施の形態におけるリソース管理装置１０１は、複数のリソース応札部１０２と複数の入札管理部１０３を含んで構成される。図４は、各アプリケーションのリソース応札部１０２と、対応する入札管理部１０３との関係を示すために、１つのリソース応札部１０２と、１つの入札管理部１０３との間でのデータの流れを示す。
【００７９】
例えば、ノード２の場合、ＣＰＵ利用率については、リソース応札部４２ａ、４３ａ、４４ａ、４５ａのそれぞれが、リソース応札部１０２に対応し、入札管理部４２ｂが、入札管理部１０３に対応する。レーダー情報のデータについては、レーダー信号処理アプリケーション４３のリソース応札部４３ａ（および５３ａ）、４５ａが、リソース応札部１０２に対応し、入札管理部４５ｂが、入札管理部１０３に対応する。
【００８０】
リソース応札部１０２は、入札値計算部１０４と、最終入札値記憶部１０５とを含む。入札管理部１０３は、落札者決定部１０６と、ラウンド繰り返し管理部１０７とを含む。
【００８１】
次に、リソース管理装置１０１の各構成要素の詳細な動作について述べる。
【００８２】
４．２  リソース応札部
まず、リソース応札部１０２の処理について述べる。リソース応札部１０２は、前述の判定によって得られた消費量または供給量のリソースを入札管理部１０３に対して入札する、すなわち自己のリソースの情報の提供を行う。入札は、リソース応札部１０２が入札管理部１０３に対して複数回すなわち複数ラウンドにわたる入札を行なうことによって行なわれる。
【００８３】
各ラウンドでは、入札値計算部１０４が入札価格としての入札値を計算する。入札価格としての入札値の計算にあたっては、その価格でリソースを売買することによる処理部の利益が最大化するような価格をつけなければならない。
【００８４】
入札値計算部１０４の具体的動作は、処理部が供給者、生産者および消費者のいずれであるかによって異なる。以下、それぞれの場合について説明する。図１５および図１６は、ラウンドが経過するにつれて、ＣＰＵ利用率とデータの入札と落札の量と値が変化する例を示す表である。図１５では、ＣＰＵ利用率についてのノード２と３における各処理部における入札量、入札値、落札量および落札値が示され、図１６では、データについての各処理部における入札量、入札値、落札量および落札値とが示されている。図１５および図１６の各部において並んだ数字は、左から順に、入札量、入札値、落札量および落札値が示されている。以下、図１５および図１６を参照しながら説明する。
【００８５】
（ａ）供給者の場合
供給者は、自己が供給できるリソースを売り惜しむ必要はないので、どれだけ安い値段であっても最大限リソースが売れるような入札を行なえばよい。従って、供給者の入札値計算部１０４は、固定の入札値を常に返せばよい。本実施の形態では供給者である物理リソースマネージャ４２、５２はＣＰＵ利用率を常に価格０で入札するものとする。このため供給者の場合には、最終入札値記憶部１０５は省略してよい。
【００８６】
図５は、供給者の入札値計算部１０４の処理の流れの例を示すフローチャートである。入札値計算部１０４は、所定の入札価格、ここでは常に例えば固定の「０」を、入札値とする（ステップＳ１）。
【００８７】
（ｂ）生産者の場合
生産者は、高い値段でリソースが売れる場合には、そのリソースの生成のために高い値段でリソースを買ってよい一方で、どうしても売値が買値を下回る場合は、売買を止める必要がある。このため生産者の入札値計算部１０４は以下のような処理を行なう。
【００８８】
はじめのラウンドでは、入札値計算部１０４は、最終入札値記憶部１０５に記録された値を入札値として採用する。なお、最終入札値記憶部１０５には初期値として０が記録されている。２回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたか否かによって入札値の調整を行う。
【００８９】
入札値計算部１０４は、自己の供給するリソース（例えば、レーダー信号処理アプリケーション４３であれば、レーダー情報というデータ）については、自己が消費するリソース（例えば、レーダー信号処理アプリケーション４３であれば、ＣＰＵ利用率）の入札値（買値）の合計の予測値を入札値（売値）として入札を行なう。自己が消費するリソースの入札値（買値）の予測値は、たとえば前回のラウンドでの自己が消費するリソースの落札値（必ずしもその処理部が落札できた値ではなく、その処理部が落札できなかった場合には他の処理部の落札値）の合計を求めるという方法で計算される。自己が消費するリソースについては、そのリソースが前回のラウンドで十分に落札できていなければ、そのリソース入札値を所定量だけ上げる、といった方法で計算される。
【００９０】
図６は、生産者が供給するリソースについての入札値計算部１０４の処理の流れの例を示すフローチャートである。図６の処理は、入札処理における各ラウンドが開始する直前に、レーダー信号処理アプリケーション４３が実行して、ラウンド毎に入札値を決定する。その決定された入札値は、入札管理部１０３へ供給される。
【００９１】
まず、入札値計算部１０４は、ＣＰＵ利用率の前回の落札量が、レーダー情報の落札量から計算したＣＰＵ利用率の必要量未満であったか否かを判定する（ステップＳ１１）。ＣＰＵ利用率の前回の落札量が、レーダー情報の落札量から計算したＣＰＵ利用率の必要量未満であった場合は（ステップＳ１１：ＹＥＳ）、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上か否かを判定する（ステップＳ１２）。
【００９２】
なお、図１５および図１６は、レーダー情報を「１００」生成するのに、レーダー信号処理アプリケーション４３は、ＣＰＵ利用率が「１３５」必要な場合の例である。
【００９３】
ステップＳ１１でＹＥＳとなるのは、ノード２のレーダー信号処理アプリケーション４３のラウンド５において、ＣＰＵ利用率については、図１５においては落札量が「４８」であるのに対して、図１６においては、レーダー情報の落札量「９１」の場合である。この場合、レーダー情報の落札量「９１」から計算したＣＰＵ利用率が「１２３」で、ＣＰＵ利用率の落札量が「４８」以上の場合である。
【００９４】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上である場合は（ステップＳ１２：ＹＥＳ）、処理はステップＳ１３へ移行する。ステップＳ１２でＹＥＳの場合は、いわゆる採算が取れている（すなわち売値が買値を上回っている）ことを意味とする。
【００９５】
ノード２のレーダー信号処理アプリケーション４３のラウンド１９において、ＣＰＵ利用率については、図１５においては落札量が「７４」で落札値が「０」で積が「０」に対して、レーダー情報については、図１６においては落札量が「５５」で落札値が「３７」で積が「２０３５」となっているような場合である。
【００９６】
ステップＳ１２でＹＥＳの場合は、レーダー信号処理アプリケーション４３のＣＰＵ利用率を上げてもよいので、入札値計算部１０４は、ＣＰＵ利用率の入札値を、所定量である微少量（ｄ１）だけ加算する（ステップＳ１３）。加算する微少量は、ここでは「４」である。図１５においては、ノード２のレーダー信号処理アプリケーション４３のラウンド１９から２０にかけて、入札値が、「７４」から「７８」に増加されているような場合である。
【００９７】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上でない場合は（ステップＳ１２：ＮＯ）、レーダー信号処理アプリケーション４３のレーダー情報の入札量を下げるために、入札値計算部１０４は、レーダー情報の入札量を、所定量である微少量（ｄ２）だけ減算する（ステップＳ１４）。ステップＳ１２でＮＯの場合は、いわゆる採算が取れていないことを意味とする。
【００９８】
ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、ＣＰＵ利用率については、図１５に示すように落札量が「７８」で落札値が「２８」でそれらの積が「２１８４」となる。これに対して、レーダー情報については、図１６において落札量が「３０」で落札値が「３７」でそれらの積が「１１１０」となっている。そのような場合に、レーダー信号処理アプリケーション４３は、ラウンド１８から１９にかけて、レーダー情報の入札量を「５８」から「５５」に下げているような場合である。
【００９９】
そして、入札値計算部１０４は、変更されたＣＰＵ利用率の入札量を、レーダー情報の入札量から計算する（ステップＳ１５）。ステップＳ１５の計算により得られたＣＰＵ利用率によれば、レーダー情報を生成するのに必要なＣＰＵ利用率が確保されることになる。
【０１００】
そして、入札値計算部１０４は、ＣＰＵ利用率の入札値と入札量との積を、レーダー情報の入札量で除算することによって、レーダー情報の入札値を計算する（ステップＳ１６）。
【０１０１】
ステップＳ１１で、ＣＰＵ利用率の前回の落札量が、レーダー情報の落札量から計算したＣＰＵ利用率の必要量未満でない場合（ステップＳ１１：ＮＯ）、すなわち、レーダー情報を処理するのに必要なＣＰＵ利用率が確保できている場合は、入札値計算部１０４は、レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上か否かを判定する（ステップＳ１７）。
【０１０２】
なお、ステップＳ１１でＮＯとなるのは、図１５に示すように、ノード２のレーダー信号処理アプリケーション４３のラウンド１８において、ＣＰＵ利用率については、落札量が「７８」であるのに対して、図１６に示すようにレーダー情報の落札量が「３０」の場合である。この場合、レーダー情報の落札量「３０」に対応する必要なＣＰＵ利用率は「４１」となり、ＣＰＵ利用率の落札量が「７８」よりも小さい。
【０１０３】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上の場合（ステップＳ１７：ＹＥＳ）、すなわち、いわゆる採算が取れている場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を上げるために、レーダー情報の入札量を、所定量である微少量（ｄ３）だけ加算する（ステップＳ１８）。
【０１０４】
レーダー情報の落札値とレーダー情報の落札量との積が、ＣＰＵ利用率の落札値とＣＰＵ利用率の落札量との積以上でない場合（ステップＳ１７：ＮＯ）、すなわち、いわゆる採算が取れていない場合は、入札値計算部１０４は、レーダー信号処理アプリケーション４３のレーダー情報の入札量を下げるために、レーダー情報の入札量を、所定量である微少量（ｄ４）だけ減算する（ステップＳ１９）。その後、入札値計算部１０４は、ステップＳ１５とＳ１６の処理を実行する。
【０１０５】
（ｃ）消費者の場合
消費者は、その局面すなわち状況におけるそのアプリケーションの重要度に対応した買値の上限値の範囲内で、自己が消費するリソースを買って処理動作を行なう。各アプリケーションの重要度は、状況に応じて変更可能である。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、アプリケーションが局面を認識して計算してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。
【０１０６】
本実施の形態では、レーダー情報がソナー情報よりも重要であると仮定して、レーダー情報表示アプリケーション４５のリソースの買値の合計の上限値を「２０００００」、ソナー情報表示アプリケーション５５のリソースの買値の合計の上限値を「１０００００」とし、その範囲内でリソースが買えなければ単位時間のリソース購入を断念するものとする。従って、センサ信号の重要度が反映された入札が行われる。
【０１０７】
入札値計算部１０４は、はじめのラウンドでは、最終入札値記憶手段に記録された値を入札値として採用する。なお、最終入札値記憶手段には初期値として「０」が記録されている。２回目以降のラウンドでは、入札値計算部１０４は、前回のラウンドで落札できたか否かによって入札値の調整を行なう。
【０１０８】
図７は、消費者の入札値計算部１０４の処理の流れの例を示すフローチャートである。まず、入札値計算部１０４は、ＣＰＵ利用率の落札量が、ＣＰＵ利用率の必要量未満であるか否かを判定する（ステップＳ２１）。
【０１０９】
その必要量は、ここでは固定値である。例えば、図１５では、ノード２のレーダー情報表示アプリケーション４５のＣＰＵ利用率の必要量は「６０」であり、図１５では、結果として落札量が「６０」となっている。
【０１１０】
ＣＰＵ利用率の落札量が、ＣＰＵ利用率の必要量未満である場合（ステップＳ２１：ＹＥＳ）、入札値計算部１０４は、ＣＰＵ利用率の入札値を、所定量である微少量（ｄ５）だけ増加する（ステップＳ２２）。
【０１１１】
そして、入札値計算部１０４は、ＣＰＵ利用率の入札値にＣＰＵ利用率の入札量を乗算した乗算値を上限値から減算し、その減算値を、レーダー情報の入札量で除算して、レーダー情報の入札値を計算する（ステップＳ２３）。すなわち、ＣＰＵ利用率の入札値にＣＰＵ利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、レーダー情報の入札値が決定される。
【０１１２】
ＣＰＵ利用率の落札量がＣＰＵ利用率の必要量以上の場合は（ステップＳ２１：ＮＯ）、入札値計算部１０４は、レーダー情報の落札量がレーダー情報の必要量以上であるか否かを判定する（ステップＳ２４）。
【０１１３】
レーダー情報の必要量は、ここでは固定である。例えば、ノード２のレーダー情報表示アプリケーション４５のレーダー情報の必要量は「１００」であり、図１６では、結果として落札量が「１００」となっている。
【０１１４】
レーダー情報の落札量がレーダー情報の必要量以上の場合は（ステップＳ２４：ＹＥＳ）、入札値計算部１０４は、レーダー情報の入札値を、所定量の微少量（ｄ６）だけ加算して増加する（ステップＳ２５）。レーダー情報により高い入札値を付けることにより、結果として、ＣＰＵ利用率には、より低い入札値を付けるためである。
【０１１５】
すなわち、入札値計算部１０４は、レーダー情報の入札値にレーダー情報の入札量を乗算した乗算値を上限値から減算し、その減算値を、ＣＰＵ利用率の入札量で除算して、ＣＰＵ利用率の入札値を計算する（ステップＳ２６）。すなわち、ＣＰＵ利用率の入札値にＣＰＵ利用率の入札量を乗算した値とレーダー情報の入札値にレーダー情報の入札量を乗算した値の和が、上限値を超えない範囲で、ＣＰＵ利用率の入札値が決定される。
【０１１６】
なお、ステップＳ２４で、レーダー情報の落札量がレーダー情報の必要量以上でない場合は（ステップＳ２４：ＮＯ）、入札値計算部１０４は処理を終了する。
【０１１７】
４．３  入札管理部
次に、入札管理部１０３の処理について述べる。入札管理部１０３は、各リソース応札部１０２からの入札、すなわち応札情報に基づき、いずれの処理部がリソースを落札するかを決定し、落札結果を各処理部のリソース応札部１０２に通知する。落札結果情報には、その処理部が落札できたか否かの情報と、落札値（必ずしもその処理部が落札できた価格ではなく、その処理部が落札できなかった場合には他の処理部の落札価格となる）の情報とが含まれている。
【０１１８】
落札結果情報を受け取った各処理部のリソース応札部１０２は、その結果にもとづいて処理単位時間の動作を行なう。消費するリソースを最終的に落札できた処理部は、そのリソースを消費する動作を行なう。通常、ある処理単位時間に消費するリソースを全て落札できなかった処理部は、その処理単位時間内に処理を行なわずにいわゆる休眠状態に入る。しかし、消費するリソースの一部が落札できなくてもなんらかの動作が可能な場合は、その処理部は、その分だけの処理動作を行なう。一方、供給できるリソースが落札されなかった処理部は、次の処理単位時間ではそのリソースの供給を行なわない。
【０１１９】
物理リソースであるＣＰＵ利用率の場合、各アプリケーションは、ＣＰＵ利用率を落札したときは、次の処理単位時間においてその落札の結果得られた時間だけ、ＣＰＵを利用した所定の処理を実行する。物理リソース以外のリソースであるデータの場合は、各アプリケーションは、データを落札したときは、落札量に応じたそのデータの供給を受ける。
【０１２０】
例えば、レーダー信号処理アプリケーション４３は、その落札の結果得られたＣＰＵ時間だけ、実行される。なお、上述したように、レーダー情報表示アプリケーション４５は、ＣＰＵ利用率の落札と、データの落札（レーダー信号処理アプリケーション４３あるいは５３のいずれかからの落札）の、両方が落札されたときに、落札の結果得られたＣＰＵ時間だけ、落札の結果得られたデータを用いて、実行される。
【０１２１】
（ａ）ラウンド管理
ここで、ラウンドについて説明する。本実施の形態では、ラウンド数すなわち繰り返し回数が入札の打ち切り条件である。すなわち、所定のラウンド数を超えて、入札処理が行われないように管理されている。すなわち、入札管理部１０３のラウンド繰り返し管理部１０７が、各処理単位時間におけるラウンド数をカウントし、所定の回数だけ落札者決定が行われるように監視して管理している。
【０１２２】
図８は、ラウンド繰り返し管理部１０７により、入札処理が所定回数しか行われないことを説明するための説明図である。
【０１２３】
図８に示すように、リソース応札部１０２は、最初に、前回の最終入札値を最終入札値記憶部１０５から読み出して、その最終入札値を用いて入札値を計算し、入札を行う（入札（１））。その入札に対しては、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（１））。この落札（１）に応じて、次の（すなわち２回目の）入札値計算が行われ、入札が再度行われる（入札（２））。その入札（２）に対しても、入札管理部１０３が落札処理を行い、落札者の決定を行う（落札（２））。さらに、その落札に対しても再度入札が行われ（入札（３））、落札処理が行われる。なお、１回目と２回目のときは、ラウンド繰り返し管理部１０７から落札者決定部１０６へ、後述する打ち切り通知は出力されない。
【０１２４】
このように、１回の入札に対する落札の処理を１ラウンドとして、ラウンド繰り返し管理部１０７は、入札の入力あるいは落札結果の出力があったときには、ラウンド数をインクリメントして、ラウンド数をカウントする。
【０１２５】
ラウンド数が、所定の数になると、ラウンド繰り返し管理部１０７はラウンド数が所定の数になったことを検出する。その検出結果は、落札者決定部１０６に、打ち切り通知として通知される。落札者決定部１０６は、打ち切り通知の情報をリソース応札部１０２に通知する。打ち切り通知を受けた入札値計算部１０４は、再度、入札値計算をしないで、落札情報の最終入札値を、最終入札値記憶部１０５に書き込む。
【０１２６】
以上のようにして、ラウンド数が入札処理の打ち切り条件として、所定の数以上入札が行われないようにしたので、本実施の形態のリソース管理装置は、所定時間内に確実に入札処理が終わらせることができるように構成されている。
【０１２７】
（ｂ）処理単位時間
次に、処理単位時間について説明する。処理単位時間は、ここでは、各アプリケーションの実行時間である。図９は、処理単位時間を説明するための説明図である。図９は、ノード２の３つのアプリケーション（レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４、レーダー情報表示アプリケーション４５）が実行される場合を示す。図９は、３つのアプリケーションＡＰ１、ＡＰ２、ＡＰ３が、処理単位時間毎に割り当てられたリソースであるＣＰＵ利用率に応じた時間だけ実行されることを示している。
【０１２８】
処理単位時間毎に、次の処理単位時間における各アプリケーション毎のリソースの配分が入札により決定される。時間ｔ（ｉ）から時間ｔ（ｉ＋１）までの間の処理単位時間（ＰＵＴ１）において、上述したように、所定の回数の入札を行い、最終的に落札者を決定している。本実施の形態では、所定回数は３回である。そして、その決定された落札結果に応じて、各アプリケーションは、割り当てられたＣＰＵ利用率だけ実行される。図９では、時間ｔ（ｉ＋１）から時間ｔ（ｉ＋２）までの間の処理単位時間（ＰＵＴ２）における各アプリケーションのＣＰＵ利用率は、処理単位時間（ＰＵＴ１）内における入札処理において、決定される。
【０１２９】
図９では、１回目の入札（Ｒ１）が行われた後、２回目の入札（Ｒ２）が行われ、その後、３回目の入札（Ｒ３）が行われる。３回の入札後において、最終的にタイミングＤにおいて、落札内容が決定される。その落札結果に応じて、次の処理単位時間において各アプリケーションが、割り当てられたＣＰＵ利用率だけ実行される。
【０１３０】
同様に、処理単位時間（ＰＵＴ３）における各アプリケーションのＣＰＵ利用率は、処理単位時間（ＰＵＴ２）内における入札処理において、決定される。以下同様にして、次の処理単位時間における、各アプリケーションに割り当てられるＣＰＵ利用率は、その処理単位時間の前の処理単位時間において入札により決定される。
【０１３１】
（ｃ）落札者決定部
入札情報を受け取った入札管理部１０３では、落札者決定部１０６が、いずれのアプリケーションがリソースを落札するかを決定する。
【０１３２】
落札者決定部１０６の動作を、ノード２の物理リソースマネージャ４２の入札管理部４２ｂが、図１０に示す内容に対して、入札を行った場合を例に説明する。図１０は、物理リソースの入札情報の例を示す説明図である。
【０１３３】
入札情報には、モジュール名、供給量または消費量、入札値、供給者と消費者の別の情報が含まれている。モジュール名は、各処理部を示し、図１０のような文字列のほか、プロセス番号などの数値で表現することもできる。供給量または消費量は、リソースをいくら消費または供給するかをリソースごとに定義された単位の数量で指定する。図１０ではＣＰＵ利用率をパーセンテージで指定している。入札価格である入札値は、リソースをいくらで消費または供給するかを仮想的な通貨で指定する。その指定は、リソースの単位ごとの単価で示してもよいし、総額（単価に数量を乗じた値）で示してもよい。図１０では単位利用率ごとの単価で示している。
【０１３４】
落札者決定部１０６の動作を説明する。まず、ＣＰＵ利用率のように、供給者が１つで消費者が複数である場合の、すなわち本実施の形態では物理リソースマネージャ４２の入札管理部４２ｂの場合の、落札者決定部１０６の動作を説明する。この場合は、消費者からの入札に対して、入札値が高い順に、供給量が存在しなくなるまで、あるいは消費者からの入札の入札値が供給者からの入札の入札値を下回るまで、リソースを割り当てることによって決定される。
【０１３５】
その際の落札値は、入札量を全て満たすだけのリソースが割り当てられなかった消費者からの入札のうち最大の入札値か、あるいは供給者からの入札の入札値かのいずれかの高い方の額となる。
【０１３６】
例として、図１０に示す入札が行なわれた場合、物理リソースマネージャ４２からの供給量である１８０％が各アプリケーションの消費量に割り当てられる。この場合、入札値の高い順に、まずレーダー情報表示アプリケーション４５に利用率８０％が割り当てられる。次に、レーダー信号処理アプリケーション４３の１６０％に対して、残りの供給量１００％が割り当てられる。また、落札値は、レーダー信号処理アプリケーション４３（入札量１６０％を全て満たすだけのリソースは割り当てられていない）の入札値「３」が物理リソースマネージャ４２の入札値「０」よりも高いので、「３」となる。
【０１３７】
次に、落札者決定部１０６の動作を、ノード２のレーダー情報表示アプリケーション４５の入札管理部４５ｂが、図１１に示す内容に対して、入札を行った場合を例に説明する。図１１は、データの入札情報の例を示す説明図である。
【０１３８】
図１１において、レーダー情報表示アプリケーション４５の消費量が「１００」となっているのは、レーダー情報表示アプリケーション４５は、１００％のデータをもらわなければ表示処理ができないことを意味している。ノード２のレーダー信号処理アプリケーション４３の供給量が「５８」となっているのでは、レーダー信号処理アプリケーション４３がレーダー情報を処理して供給できる割合（％）の最大値が「５８」であることを示している。この最大値「５８」は、ノード２においてレーダー信号処理アプリケーション４３が使えるＣＰＵ利用率から決定される値であり、レーダー情報１００％のうち５８％はレーダー信号処理アプリケーション４３によって処理してもよいとされる設定値である。同様に、ノード３のレーダー信号処理アプリケーション５３の供給量が「６４」となっているのでは、レーダー信号処理アプリケーション５３がレーダー情報を処理して供給できる割合（％）の最大値が「６４」であることを示している。この最大値「６４」は、ノード３においてレーダー信号処理アプリケーション５３が使えるＣＰＵ利用率から決定される値であり、レーダー情報１００％のうち６４％はレーダー信号処理アプリケーション５３によって処理してもよいとされる設定値である。
【０１３９】
レーダー情報表示アプリケーション４５の入札値が「１９８０」となっているのは、レーダー情報表示アプリケーション４５は、入札価格の最大値が「１９８０」であることを意味している。ノード２のレーダー信号処理アプリケーション４３とノード３のレーダー信号処理アプリケーション５３の入札値が、共に「３７」となっているのは、入札価格の最小値が共に「３７」であることを意味している。
【０１４０】
なお、ここでは入札値は、ＣＰＵ利用率の単位利用率ごとの単価としたので、入札値の大きさを比較する際にはＣＰＵ利用率を考慮する必要はないが、総額を入札値として入札を行なう場合は、落札者決定部１０６において、入札値をＣＰＵ利用率で割ることによって単価を計算し、その単価を比較して落札者を決定する必要がある。
【０１４１】
図１２は、供給者である物理リソースマネージャ４２の落札者決定部１０６の処理の流れの例を示すフローチャートである。ここでは、ノード２の場合で説明する。
【０１４２】
まず、落札者決定部１０６は、供給者の決定した供給量、すなわち供給者の入札情報における供給量を、供給量とする（ステップＳ３１）。
【０１４３】
落札者決定部１０６は、リソースの消費者からの入札情報の中で、価格が最も高い入札を選択する（ステップＳ３２）。図１０の例であれば、レーダー情報表示アプリケーション４５が選択される。
【０１４４】
落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値以上か否かの判定が行われる（ステップＳ３３）。図１０の場合、供給者である物理リソースマネージャ４２の入札値は「１」であり、消費者であるレーダー情報表示アプリケーション４５の入札値は「４」であるので（ステップＳ３３：ＹＥＳ）、ステップＳ３４へ処理は移行する。
【０１４５】
落札者決定部１０６は、その消費者からの入札の価格が、供給者からの入札値未満であるときは（ステップＳ３３：ＮＯ）、処理を終了する。
【０１４６】
ステップＳ３４では、落札者決定部１０６は、その消費者からの入札のうち、残りの供給量を超えない量を落札量と決定する。図１０の場合、レーダー情報表示アプリケーション４５の消費量８０が、供給量１８０から減算できるので、供給量を超えない量である消費量８０が落札量とされる。
【０１４７】
次に、落札者決定部１０６は、残り供給量を算出する、すなわち、残り供給量から落札量を減算することによって残り供給量を算出する（ステップＳ３５）。図１０の場合、供給量１８０から落札量８０を減算して、残り供給量１００が算出される。
【０１４８】
そして、落札者決定部１０６は、残り供給量が０以下であるか否かを判定する（ステップＳ３６）。
【０１４９】
残り供給量が０を超えるとき（ステップＳ３６：ＹＥＳ）、処理はステップＳ３２に戻る。残り供給量が０以下のとき（ステップＳ３６：ＮＯ）、処理は終了する。
【０１５０】
ステップＳ３２に戻った場合、落札者以外の消費者から入札について、上述したステップＳ３２からＳ３６までの処理を繰り返す。
【０１５１】
以上のステップＳ３１からＳ３６までの処理が、所定の回数（ここでは３回）繰り返される。ステップＳ３１からＳ３６までの処理が、１ラウンドに対応する。
【０１５２】
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを消費するリソース消費プログラムが複数ある場合、複数のリソース消費プログラムの中で、入札値の大きいプログラムを優先してリソースを割り当てるようにリソース割り当て処理を行なう。
【０１５３】
一方、センサ情報のように、供給者が複数で消費者が１つである場合、すなわち本実施の形態ではレーダー情報表示アプリケーション４５の入札管理部４５ｂの場合、の落札者決定部１０６の動作は、図１２において、「供給」と「消費」を読み替え、「高い」を「低い」と読み替えればよい。図１３は、情報表示アプリケーションの落札者決定部１０６の処理の流れの例を示すフローチャートである。
【０１５４】
まず、落札者決定部１０６は、消費者の決定した消費量、すなわち消費者の入札情報における消費量を、消費量とする（ステップＳ４１）。
【０１５５】
落札者決定部１０６は、リソースの供給者からの入札情報の中で、価格が最も低い入札を選択する（ステップＳ４２）。図１１の場合、ノード２のレーダー信号処理アプリケーション４３と、ノード３のレーダー信号処理アプリケーション５３とは、同じ入札値、すなわち「３７」であるので、ここでは、例えばこれら２つのアプリケーションに優先順位を予め設定しておくことにより、２つのアプリケーションのいずれかが選択される。例えば、レーダー信号処理アプリケーション４３が選択される。
【０１５６】
落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値以下か否かの判定が行われる（ステップＳ４３）。図１１の場合、消費者であるレーダー情報表示アプリケーション４５の入札値は、「１９８０」であるので（ステップＳ４３：ＹＥＳ）、ステップＳ４４へ処理は移行する。
【０１５７】
なお、落札者決定部１０６は、その供給者からの入札の価格が、消費者からの入札値を超えるとき（ステップＳ４３：ＮＯ）、処理を終了する。
【０１５８】
落札者決定部１０６は、ステップＳ４４では、その供給者からの入札のうち、残りの消費量を超えない量を落札量と決定する。図１１の場合、レーダー情報表示アプリケーション４５の消費量「１００」から供給量「５８」が減算できるので、消費量を超えない量である供給量「５８」が落札量とされる。
【０１５９】
次に、落札者決定部１０６は、残り消費量を算出する、すなわち、残り消費量から落札量を減算することによって残り消費量を算出する（ステップＳ４５）。図１１の場合、残り消費量１００から落札量５８を減算して、残り消費量４２が算出される。
【０１６０】
そして、落札者決定部１０６は、残り消費量が０以下であるか否かを判定する（ステップＳ４６）。
【０１６１】
残り消費量が０を超えるとき（ステップＳ４６：ＹＥＳ）、処理はステップＳ４２に戻る。残り消費量が０以下のとき（ステップＳ４６：ＮＯ）、処理は終了する。
【０１６２】
ステップＳ４２に戻った場合、落札者以外の供給者から入札について、上述したステップＳ４２からＳ４６までの処理を繰り返す。
以上のステップＳ４１からＳ４６までの処理が、所定の回数（ここでは３回）繰り返される。ステップＳ４１からＳ４６までの処理が、１ラウンドに対応する。この繰り返し回数も、予め決められており、本実施の形態では、３である。
【０１６３】
以上のように、入札管理部１０３は、複数のアプリケーションプログラムの中に、リソースを供給するリソース供給プログラムが複数ある場合、複数のリソース供給プログラムの中で、入札値の小さいプログラムを優先して前記リソースを割り当てるようにリソース割り当て処理を行なう。
【０１６４】
（ｄ）ラウンド繰り返し管理部
図１２および図１３で説明した処理の実行回数は、ラウンド繰り返し管理部１０７によりカウントされ、所定回数を超えて図１２および図１３の処理が実行されないように、ラウンド繰り返し管理部１０７は、落札者決定部１０６における上述した処理の実行を制御する。
【０１６５】
図１４は、ラウンド繰り返し管理部１０７の処理の流れの例を示すフローチャートである。ラウンド繰り返し管理部１０７は、上述したラウンドの繰り返し回数をカウントする（ステップＳ５１）。ラウンド繰り返し管理部１０７は、カウントしたラウンド繰り返し回数が所定回数、本実施の形態では３回になったか否かを判定する（ステップＳ５２）。そして、カウントしたラウンド繰り返し回数が所定回数にならなければ（ステップＳ５２：ＮＯ）、ステップＳ５１に戻る。カウントしたラウンド繰り返し回数が所定回数になると（ステップＳ５２：ＹＥＳ）、ラウンド繰り返し管理部１０７は、図１１および図１２の処理を終了させる実行終了処理を行う（ステップＳ５３）。実行終了処理では、上述した打ち切り通知が、落札情報と共に、あるいは落札情報とは別に、リソース応札部１０２に出力される。
【０１６６】
このように、ラウンド繰り返し管理部１０７は、内部にラウンドの回数を記憶し、ラウンドの度に１つずつインクリメントし、カウントしたラウンドの回数が上限すなわち所定回数に達したら、それ以上のラウンドを実行しないように、処理を打ち切る、すなわち終了させる。この上限値はアプリケーション作成者がアプリケーションのソースコード中に記述してもよいし、ユーザが端末での直接あるいか間接の指定によって与えてもよい。この打ち切りによって、入札が一定の時間内に終了することが保証される。なお、ラウンドが終了したか否かは入札を行なった処理部への落札結果の通知の際に、付加情報として通知される。
【０１６７】
５．装置全体の動作
上述したようなリソース管理装置において、入札値計算部１０４における増減させる所定量等のパラメータを適宜設定することにより、最終的には、ノード２のレーダー情報表示アプリケーション４５が、ノード３のレーダー信号処理アプリケーション５３からレーダー情報を得て動作する、という結果に収束させることができる。
【０１６８】
図１５および図１６は、ラウンド数が「２０」までの、本実施の形態におけるリソース管理装置の入札と落札の状況を示す表である。図１５および図１６では、連続した２０回のラウンドにおける入札値等のデータの例が示されているが、上述したラウンド繰り返し回数が「３」であるので、ラウンド１から３が、１回目の入札処理を経過と結果を示し、ラウンド４から６が、２回目の入札処理の経過と結果を示す。以下、同様に、３回のラウンドで、処理単位時間における入札処理が行われている。
【０１６９】
上述したように、図１５および図１６は、リソースの供給と消費の関係において、レーダー信号処理アプリケーション４３、５３は１００％のレーダー情報を生成するためにＣＰＵ利用率１３５％を必要であり、ソナー信号処理アプリケーション４４、５４は、１００％のソナー情報を生成するためにＣＰＵ利用率９０％を必要であり、レーダー情報表示アプリケーション４５は、１００％のレーダー情報を処理するのにＣＰＵ利用率９０％を必要であり、ソナー情報表示アプリケーション５５は、１００％のソナー情報を処理するのにＣＰＵ利用率３５％を必要であるという条件で処理が行われた場合の例を示す。また、入札値の計算の際に値を増減させる微少量は、入札値では「４」で、入札量では「３」という値である場合が示されている。そして、入札では、ノード２と３のそれぞれのＣＰＵ利用率、レーダー情報およびソナー情報の４つのリソースについて、それぞれ入札参加者からの入札が行われ、落札量と落札値が決定されている。
【０１７０】
図１５および図１６では、２０回目以降のラウンドでは、リソースが適切に割り当てられている。２０回目のラウンドの結果を見ると、ノード２では、レーダー信号処理アプリケーション４３がＣＰＵ利用率７８％でレーダー情報５８％を生成し、ソナー信号処理アプリケーション４４がＣＰＵ利用率４２％でソナー情報３７％を生成している。ノード３では、レーダー信号処理アプリケーション５３がＣＰＵ利用率８６％でレーダー情報４２％を生成し、ソナー信号処理アプリケーション５４がＣＰＵ利用率５６％でソナー情報６３％を生成している。
【０１７１】
これらの割り当て結果は、レーダー信号処理アプリケーション４３、５３は、１００％のレーダー情報を生成するのに、ＣＰＵ利用率１３５％を必要とし、ソナー信号処理アプリケーション４４、５４は、１００％のソナー情報を生成するのに、ＣＰＵ利用率９０％を必要とするという条件を満たしている。また、レーダー情報表示アプリケーション４５は６０％のＣＰＵ利用率で、ソナー情報表示アプリケーション５５は３５％のＣＰＵ利用率という条件も満たしている。さらに、レーダー情報表示アプリケーション４５は１００％のレーダー情報を落札し、ソナー情報表示アプリケーション５５は１００％のソナー情報を落札しているので、それぞれ表示に必要なデータも問題なく得ている。２０回目の以前のラウンドでは、一応の動作は可能であるが、ＣＰＵ利用率が十分に割り当てられていない場合もあるので、装置全体のリアルタイム性が満足されていない状態となるおそれがある。しかし、このような状態は、入札初期の状態のときだけで生じるので、全体として問題はない。
【０１７２】
本実施の形態では、レーダー情報がソナー情報よりも重要であるので、レーダーの信号処理と情報表示がソナーの信号処理と情報表示よりも優先されて実行されるように、入札値の上限値が設定されている。上述した例では、２つのセンサ情報表示アプリケーション間で、買値の上限値を異ならせ、各センサ情報表示アプリケーションは、その上限値の範囲内で、自己が消費するリソースを買って動作を行なう。なお、この上限値は、状況に応じて設定変更可能とすれば、各アプリケーションの重要度は、状況に応じて変更可能となる。
【０１７３】
また、レーダー情報表示アプリケーション４５によってＣＰＵ利用率が落札されてＣＰＵ利用率の価格が上がっているノード２よりも、ノード３の方がＣＰＵ利用率の入札値が低いので、ノード２のレーダー情報処理アプリケーションよりもノード３のレーダー情報処理アプリケーションの方がレーダー情報のリソースとしての入札値（売値）が低いため、レーダー情報表示アプリケーション４５は、ノード３のレーダー信号処理アプリケーション５３からレーダー情報を買うことになり、ノード３のレーダー信号処理アプリケーション５３が動作している。
【０１７４】
６．一部のノードでアプリケーションが未起動である場合の動作
以上は、ノード２、３のいずれにおいても信号処理アプリケーションが起動されている場合の動作である。以下では、アプリケーションを起動するノードの数を抑制するという本発明の趣旨に則り、レーダー信号について、ノード３でのみレーダー信号処理アプリケーション５３が起動されており、ノード２ではレーダー信号処理アプリケーション４３が起動されていない場合の動作について述べる。
【０１７５】
本実施の形態では、ロジック処理部とラッパーとを別のプロセスとして実現する。各リソース応札部はラッパーに含まれる。たとえばレーダー信号処理アプリケーション４３、５３のロジック処理部とラッパーとを別の実行ファイルとしてコンパイルおよびリンクしておき、それぞれ別プロセスとして起動すればよい。このほかダイナミックリンクなどの方法で、ロジック処理部とラッパーとを同一プロセスでありながら別々に起動する方式での実施も可能である。
【０１７６】
なお、あらゆるアプリケーションでロジック処理部とラッパーとを分離する必要はない。すなわち、一部のアプリケーション、たとえばメモリをあまり消費しないアプリケーションについては、ロジック処理部とラッパーとを一体で実現し、電源投入時に一括して起動しても構わない。
【０１７７】
ここで、ラッパーの機能について説明する。ラッパー４３ｃ、４４ｃ、５３ｃ、５４ｃは、それぞれ対応するアプリケーション（レーダー信号処理アプリケーション４３、ソナー信号処理アプリケーション４４、レーダー信号処理アプリケーション５３、およびソナー信号処理アプリケーション５４）に対する処理要求を受付けるものであり、各アプリケーションのロジック処理部が未起動であっても常に起動される。
【０１７８】
そして各ラッパーは、対応するアプリケーションがリソースを獲得したときに、当該対応するアプリケーションのロジック処理部を起動し、起動したロジック処理部に対して処理要求を転送する。
【０１７９】
また、上述のように各ラッパー内に、対応するアプリケーションのリソースの入札を行うリソース応札部が備えられている。そして、各リソース応札部は、ロジック処理部が未起動の場合は、起動時の売り値より高い入札値で入札を行う。ロジック処理部の起動有無は、起動状態を表す情報をメモリ等に保持し、この情報を参照する方法などにより判定する。また、各リソース応札部は、ロジック処理部が起動された後は、通常の算出方法により入札値を計算して入札を行う。
【０１８０】
図１７は、リソース応札部による入札切り分け処理の流れの一例を示すフローチャートである。
【０１８１】
まず、リソース応札部は、メモリ等に保存した起動状態を表す情報を参照してロジック処理部が起動中か否かを判断する（ステップＳ６１）。起動中の場合は（ステップＳ６１：ＹＥＳ）、リソース応札部は通常の売り値で入札を行う（ステップＳ６２）。すなわち、リソース応札部は、図６のフローチャートで示したような方法により入札値を算出して入札を行う。
【０１８２】
ロジック処理部が起動中でない場合は（ステップＳ６１：ＮＯ）、リソース応札部は、通常より高い売り値となる入札値で入札を行う（ステップＳ６３）。このとき、リソース応札部は、例えば、アプリケーションごとに予め定められた固定値を通常より高い売り値として入札を行う。
【０１８３】
次に、このように構成されたリソース管理装置であるノード２、３によるリソース管理の具体例について説明する。図１８は、ノード２、３いずれもが正常に動作している場合の動作例を示した説明図である。
【０１８４】
同図の状態では、ノード３のレーダー信号処理アプリケーション５３のロジック処理部５３ｄはすでに起動されているが、ノード２のレーダー信号処理アプリケーション４３のロジック処理部４３ｄは起動されていない。
【０１８５】
前述の通り、レーダー情報の入札は、生産者であるレーダー信号処理アプリケーション４３、５３が売り入札を行ない、消費者であるレーダー情報表示アプリケーション４５が買い入札を行なうが、ここでロジック処理部４３ｄが未起動であるノード２のレーダー信号処理アプリケーション４３のラッパー４３ｃ内のリソース応札部４３ａは、通常よりも高い売り値で入札を行なう。
【０１８６】
一方ノード３のレーダー信号処理アプリケーション５３のラッパー５３ｃ内のリソース応札部５３ａは、通常の売り値で入札を行なう。このため、ほかの条件が同じなら、ノード３のレーダー信号処理アプリケーション５３が落札して、ノード３のレーダー信号処理アプリケーション５３のロジック処理部５３ｄが動作し、ノード２のレーダー信号処理アプリケーション４３は落札せず、ノード２のレーダー信号処理アプリケーション４３のロジック処理部４３ｄは起動されないという結果になる。
【０１８７】
次に、ノード３の故障が起きた場合の具体例について説明する。図１９は、ノード３の故障が起きた場合の動作例を示した説明図である。
【０１８８】
同図の状態では、レーダー情報の売り入札を行なうのはノード２のレーダー信号処理アプリケーション４３のラッパー４３ｃ内のリソース応札部４３ａのみであるので、通常よりも高い売り値で入札を行なっているにもかかわらず、ノード２のレーダー信号処理アプリケーション４３のラッパー４３ｃ内のリソース応札部４３ａが落札する。落札に成功すると、ラッパー４３ｃはロジック処理部４３ｄを起動する。たとえばロジック処理部４３ｄとラッパー４３ｃとを別プロセスとして実現する場合、ラッパー４３ｃのプロセスからシステムコールを発行してロジック処理部４３ｄを子プロセスとして起動すればよい。
【０１８９】
ここで、レーダー情報表示アプリケーション４５は、クライアントとしてサーバであるレーダー信号処理アプリケーション４３に対してレーダー情報を要求するが、その要求はいったんラッパー４３ｃが受け取る。ラッパー４３ｃはその要求をロジック処理部４３ｄへ転送する。ロジック処理部４３ｄは要求にしたがってレーダー信号を生成し、レーダー信号をいったんラッパー４３ｃに渡す。ラッパー４３ｃはレーダー信号をレーダー情報表示アプリケーション４５に転送する。
【０１９０】
このように情報の転送を行なうことによって、クライアントからはあたかもラッパー４３ｃ自身がサーバであるかのように見えるため、前述のように、ロジック処理部４３ｄとラッパー４３ｃとが一体で実現されたアプリケーションが混在していても、混在を意識した処理をクライアントに記述することなしにサーバへの要求を行なうことができる。
【０１９１】
以上はノード３の故障が起きた際の動作であるが、ノード３が他のアプリケーションの負荷上昇などによって過負荷状態になった際にも同様の動作が生じる。
【０１９２】
このように、本実施の形態によれば、通常はすでに起動されているノード３のレーダー信号処理アプリケーション５３が落札して動作するが、ノード３の故障や過負荷によってノード３のレーダー信号処理アプリケーション５３が動作できない場合は、ノード２のレーダー信号処理アプリケーション４３が新規に起動されて処理を行なう。
【０１９３】
以上のように、第１の実施の形態にかかるリソース管理装置では、市場メカニズムによるリソース割り当てにおいて、必要なときにのみアプリケーションを起動可能となるため、アプリケーション起動によるＣＰＵ時間・メインメモリ・キャッシュメモリの消費を低減することができる。
【０１９４】
（第２の実施の形態）
第２の実施の形態にかかるリソース管理装置は、リソース応札部を、複数のアプリケーションに共通のプロクシと呼ばれるプログラムに含まれているリソース応札部と、各アプリケーション内に含まれるリソース応札部（個別リソース応札部）とに分離し、アプリケーションが起動されるまでの間の入札を前者に行わせるものである。
【０１９５】
図２０は、第２の実施の形態にかかるリソース管理装置であるノード２０２、２０３のソフトウェア構成を示すブロック図である。同図に示すように、ノード２０２は、ＣＰＵ２１、２２と、ＯＳ４１と、物理リソースマネージャ２４２と、レーダー信号処理アプリケーション２４３と、ソナー信号処理アプリケーション２４４と、レーダー情報表示アプリケーション２４５と、プロクシ２４６と、ＣＯＲＢＡミドルウェア２４７と、を備えている。
【０１９６】
また、ノード２０３は、ＣＰＵ３１、３２と、ＯＳ５１と、物理リソースマネージャ２５２と、レーダー信号処理アプリケーション２５３と、ソナー信号処理アプリケーション２５４と、ソナー情報表示アプリケーション２５５と、プロクシ２５６と、ＣＯＲＢＡミドルウェア２５７と、を備えている。
【０１９７】
第２の実施の形態では、ノード２０２（ノード２０３）は、物理リソースマネージャ２４２（２５２）、レーダー信号処理アプリケーション２４３（２５３）、ソナー信号処理アプリケーション２４４（２５４）、およびレーダー情報表示アプリケーション２４５（ソナー情報表示アプリケーション２５５）の構成と、プロクシ２４６（２５６）およびＣＯＲＢＡミドルウェア２４７（２５７）を追加したことと、が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるノード２（ノード３）の構成を表すブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１９８】
ノード２０２とノード２０３はそれぞれ同様の機能を有するリソース管理装置であるため、以下ではノード２０２を例として、各構成部の詳細について説明する。
【０１９９】
物理リソースマネージャ２４２は、リソース応札部４２ａの代わりに個別リソース応札部２４２ａを備えた点が、第１の実施の形態にかかる物理リソースマネージャ４２と異なっている。ただし、個別リソース応札部２４２ａとリソース応札部４２ａとは、名称が異なるだけであって、機能は同一である。これは、複数アプリケーションの入札を代理するプロクシ２４６内のリソース応札部２４６ａと区別する便宜のためである。
【０２００】
同様に、レーダー情報表示アプリケーション２４５は、リソース応札部４５ａの代わりに個別リソース応札部２４５ａを備えた点が、第１の実施の形態にかかるレーダー情報表示アプリケーション４５と異なっている。個別リソース応札部２４５ａとリソース応札部４５ａとは、名称が異なるだけであって、機能は同一であるため、その説明を省略する。
【０２０１】
レーダー信号処理アプリケーション２４３は、ラッパー４３ｃを含まず、リソース応札部４３ａの代わりに個別リソース応札部２４３ａを備えた点が、第１の実施の形態にかかるレーダー信号処理アプリケーション４３と異なっている。ソナー信号処理アプリケーション２４４も、レーダー信号処理アプリケーション２４３と同様に、ラッパー４４ｃを含まず、リソース応札部４４ａの代わりに個別リソース応札部２４４ａを備えた点が、第１の実施の形態にかかるソナー信号処理アプリケーション４４と異なっている。
【０２０２】
すなわち、第２の実施の形態では、ロジック処理部４３ｄ（４４ｄ）が未起動でも起動されるラッパー４３ｃ（４４ｃ）は備えず、個別リソース応札部２４３ａ（２４４ａ）は、ロジック処理部４３ｄ（４４ｄ）と連動して起動される。なお、個別リソース応札部２４３ａ（２４４ａ）自体の機能は、リソース応札部４３ａ（４４ａ）と同様であるのでその説明を省略する。
【０２０３】
プロクシ２４６は、各アプリケーションが起動されていないときにも起動され、起動していないアプリケーションの代理として市場に対して入札を行うＣＯＲＢＡオブジェクトであり、リソース応札部２４６ａを備えている。
【０２０４】
リソース応札部２４６ａは、プロクシ２４６内に保持された各アプリケーションの未起動時の入札値を参照し、各アプリケーションが未起動のときに各アプリケーションに代わって当該入札値で入札を行うものである。
【０２０５】
図２１は、プロクシ２４６内に格納されている、アプリケーションごとの入札値を保持するアプリケーション入札情報テーブルの一例を示した説明図である。同図に示すように、アプリケーション入札情報テーブルは、アプリケーション名と、当該アプリケーションの入札価格（入札値）の初期値と、入札数量の初期値とを対応づけて保持している。
【０２０６】
ＣＯＲＢＡミドルウェア２４７は、ＯＭＧ（Object Management Group）が定めた分散オブジェクト技術仕様であるＣＯＲＢＡを実装したミドルウェアであり、Implementation Repository２４７ａを備えている。本実施の形態では、起動されていないアプリケーションへの要求があった際に、次に説明するＣＯＲＢＡのImplementation Repositoryによってアプリケーションを自動的に起動する機構を利用することを前提としているためである。
【０２０７】
Implementation Repository２４７ａは、アプリケーションのサーバの稼働状況、つまりサーバが動作しているか否かと、動作している場合はいずれのポート番号で動作しているかの情報を管理する。また、Implementation Repository２４７ａは、クライアントからの要求があった際にサーバを起動する役割を有するため、サーバの起動に必要な情報（設定情報）を保持している。
【０２０８】
図２２は、Implementation Repository２４７ａ内に格納されている、アプリケーション起動のための設定情報を保持する設定情報テーブルの一例を示した説明図である。同図に示すように、設定情報テーブルは、アプリケーション名と、サーバ稼動の有無と、ポート番号と、実行ファイル名とを対応づけて保持している。
【０２０９】
同図では、たとえば、レーダー信号処理アプリケーション（RadarAnalyzer）がポート番号＝１２３４で稼働中であり（サーバの稼動の有無＝○）、実行ファイルが「/usr/local/bin/RadarAnalyzer」であることが示されている。また、ソナー信号処理アプリケーション（SonarAnalyzer）は未起動であることが示されている。
【０２１０】
クライアントからの要求があった際にはImplementation Repository２４７ａが、実行ファイル名を参照してアプリケーションを起動する。また、起動後には稼動の有無を「×」から「○」に変更し、ポート番号欄には動作しているポート番号（１２３４）が設定される。
【０２１１】
なお、ここではImplementation Repository２４７ａがアプリケーションを別プロセスで実行する実施形態を示すが、ＣＯＲＢＡミドルウェアと同一プロセスで実行されるように構成してもよい。
【０２１２】
なお、あらゆるアプリケーションでプロクシ２４６を用いた起動前の入札を行なわせる必要はない。すなわち、一部のアプリケーション、たとえばメモリをあまり消費しないアプリケーションについては、アプリケーションを電源投入時に一括して起動して、電源投入当初から当該アプリケーション自身で入札を行なわせるように構成してもよい。
【０２１３】
次に、このように構成された第２の実施の形態にかかるリソース管理装置による入札切り分け処理について説明する。図２３は、第２の実施の形態におけるプロクシ２４６内のリソース応札部２４６ａによる入札切り分け処理の全体の流れを示すフローチャートである。
【０２１４】
まず、プロクシ２４６内のリソース応札部２４６ａが、未起動のアプリケーションが存在するか否かを判断する（ステップＳ７１）。具体的には、リソース応札部２４６ａは、プロクシ２４６内部に保持されている設定情報テーブルのサーバ稼動の有無を参照して、未起動アプリケーションの存在を判断する。
【０２１５】
未起動アプリケーションが存在する場合は（ステップＳ７１：ＹＥＳ）、リソース応札部２４６ａは、該当するアプリケーションに対する入札価格、入札数量をアプリケーション入札情報テーブルから取得して、取得した入札価格、入札数量で入札を行う（ステップＳ７２）。
【０２１６】
未起動アプリケーションが存在しない場合は（ステップＳ７１：ＮＯ）、アプリケーションを代理して入札する必要がないため、処理を終了する。なお、アプリケーションが起動されている場合は、起動されている各アプリケーション内の個別リソース応札部が入札を行う。
【０２１７】
次に、このように構成されたリソース管理装置であるノード２０２、２０３によるリソース管理の具体例について説明する。ノード２０２、２０３のいずれにおいてもレーダー信号処理アプリケーション２４３、２５３が起動されている場合の動作は第１の実施の形態と同様である。
【０２１８】
ノード２０３でのみレーダー信号処理アプリケーション２５３が起動されており、ノード２０２ではレーダー信号処理アプリケーション２４３が起動されていない場合の動作を以下に述べる。図２４は、ノード２０２、２０３いずれもが正常に動作している場合の動作例を示した説明図である。
【０２１９】
なお、以下ではレーダー信号処理アプリケーション２４３の入札のみをプロクシ２４６に行なわせる例を示すが、複数のアプリケーションの入札をプロクシ２４６に一括して行なわせる場合、各アプリケーションの入札値をプロクシ２４６にそれぞれ保持する。
【０２２０】
図２４の状態では、ノード２０３のレーダー信号処理アプリケーション２５３はすでに起動されているが、ノード２０２のレーダー信号処理アプリケーション２４３は起動されていない。
【０２２１】
前述の通り、レーダー情報の入札は、生産者であるレーダー信号処理アプリケーション２４３、２５３が売り入札を行ない、消費者であるレーダー情報表示アプリケーション２４５が買い入札を行なう。ここで、未起動であるノード２０２のレーダー信号処理アプリケーション２４３の代理で入札を行なうノード２０２のプロクシ２４６のリソース応札部２４６ａは、通常よりも高い売り値で入札を行なう。
【０２２２】
一方、ノード２０３のレーダー信号処理アプリケーション２５３は通常の売り値で入札を行なう。このため、ほかの条件が同じなら、ノード２０３のレーダー信号処理アプリケーション２５３が落札して、ノード２０３のレーダー信号処理アプリケーション２５３のロジック処理部５３ｄが動作し、ノード２０２のプロクシ２４６内のリソース応札部２４６ａは落札しない。したがって、ノード２０２のレーダー信号処理アプリケーション２４３は起動されないという結果になる。
【０２２３】
次に、ノード２０３の故障が起きた場合の具体例について説明する。図２５は、ノード２０３の故障が起きた場合の動作例を示した説明図である。
【０２２４】
レーダー情報の売り入札を行なうのはノード２０２のレーダー信号処理アプリケーション２４３の代理であるノード２０２のプロクシ２４６のみであるので、通常よりも高い売り値で入札を行なっているにもかかわらず、ノード２０２のプロクシ２４６内のリソース応札部２４６ａが落札する。
【０２２５】
ノード２０２のプロクシ２４６が落札に成功した場合、レーダー情報表示アプリケーション２４５はクライアントとして、サーバであるレーダー信号処理アプリケーション２４３に対してレーダー情報を要求するが、その要求はいったんImplementationRepository２４７ａが受け取る。Implementation Repository２４７ａは要求を受け取ると、前述の設定情報テーブルからサーバ稼動の有無を読み出して、レーダー信号処理アプリケーション２４３がまだ起動されていないことを認識する。
【０２２６】
そして、Implementation Repository２４７ａは、設定情報テーブルから実行ファイル名を取得してレーダー信号処理アプリケーション２４３の起動を行なう。その上で、Implementation Repository２４７ａは、レーダー情報の要求を送信したレーダー情報表示アプリケーション２４５に対して、起動したレーダー信号処理アプリケーション２４３のポート番号を含む転送通知を返す。
【０２２７】
転送通知を受け取ったレーダー情報表示アプリケーション２４５は、レーダー信号処理アプリケーション２４３にレーダー情報の要求を送り直す。この転送機構はＣＯＲＢＡの規約上定められているものである。したがって、前述のように、プロクシ２４６を用いた起動前の入札を行なわせずに電源投入当初から自前で入札を行なうアプリケーションが混在していても、混在を意識した処理をクライアントに記述することなしにサーバへの要求を行なうことができる。
【０２２８】
いったんレーダー信号処理アプリケーション２４３が起動されたのちは、レーダー信号処理アプリケーション２４３の個別リソース応札部２４３ａが自ら入札に参加する。このため、プロクシ２４６にはアプリケーションが起動されるまでの入札を行なうための設定情報、たとえば入札価格と入札数量のそれぞれ初期値または初期値の計算方法のみを与えておけばよい。入札価格を状況に応じて細かく調整するといった高度な機能は必要に応じてアプリケーション自身で実現しておき、アプリケーション起動後の入札に際してのみ行なえばよい。
【０２２９】
以上はノード２０３の故障が起きた際の動作であるが、ノード２０３が他のアプリケーションの負荷上昇などによって過負荷状態になった際にも同様の動作が生じる。
【０２３０】
なお、ここではＣＯＲＢＡのImplementation Repository上での実施形態を示したが、ＣＯＲＢＡ以外の方式による分散ミドルウェア、たとえばＷｅｂサービスミドルウェアなどにおいても、Implementation Repositoryと類似のアプリケーション起動機構が利用できる場合は同様の実施形態を採ることができる。
【０２３１】
また、第２の実施の形態では、センサ情報システム１は、説明の簡単のために、２つのノード２０２、２０３からなるシステムとして説明したが、３以上のノードを含むものであってもよい。また、センサ信号を出力するレーダー装置５とソナー装置７は、それぞれノード２０２と２０３に接続されているが、それぞれがセンサ信号を出力する複数の装置が、１つのノードに接続されるように構成されていてもよい。すなわち、ノードの中には、センサ信号を出力する装置が接続されていないものが存在してもよいし、それぞれがセンサ信号を出力する複数の装置が接続されているものが存在してもよい。
【０２３２】
さらに、上述した実施の形態では、各ノードには、２つのＣＰＵが設けられているが、１つあるいは３以上のＣＰＵが設けられていてもよい。この場合、各ノード内部のバスにより、１つまたは複数のＣＰＵが他の回路とバスで接続される。
【０２３３】
以上のように、第２の実施の形態によれば、ＣＯＲＢＡのプロクシおよびImplementation Repositoryの仕組みを利用して、通常はすでに起動されているノード２０３のレーダー信号処理アプリケーション２５３が落札して動作するが、ノード２０３の故障や過負荷によってノード２０３のレーダー信号処理アプリケーション２５３が動作できない場合は、ノード２０２のレーダー信号処理アプリケーション２４３が新規に起動されて処理を行なうことができる。
【０２３４】
このように、第２の実施の形態にかかるリソース管理装置では、市場メカニズムによるリソース割り当てにおいて、アプリケーション起動によるＣＰＵ時間・メインメモリ・キャッシュメモリの消費を低減することができる。
【０２３５】
また、第２の実施の形態では、第１の実施の形態と異なり、ＣＯＲＢＡのImplementation Repositoryのような既存の汎用の機構を用いて起動処理を行なうため、ラッパーなどによる起動処理が不要であり、開発工数を抑えられるという利点がある。また、アプリケーションの呼び出しが直接アプリケーションに対して行なわれるため、ラッパーのようにロジック処理部へ呼び出しを中継する必要がないという利点もある。
【０２３６】
（変形例）
なお、上記各実施の形態では、ラッパーまたはプロクシを利用した２種類の実施の形態を示したが、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【０２３７】
たとえば、プロクシがアプリケーションの起動を行ない、アプリケーションの呼び出しはプロクシ経由でなく直接行なう、といった上記２種類の実施の形態の中間的な実施の形態も可能である。また、第２の実施の形態では、アプリケーション起動後は、アプリケーション内の個別リソース応札部が入札を行っていたが、アプリケーション起動後もプロクシ内のリソース応札部で各アプリケーションの入札を行うように構成してもよい。
【０２３８】
また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【０２３９】
第１または第２の実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０２４０】
また、第１または第２の実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０２４１】
また、第１または第２の実施の形態のリソース管理プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０２４２】
第１または第２の実施の形態にかかるリソース管理装置で実行されるリソース管理プログラムは、上述した各部（ロジック処理部、ラッパー、リソース応札部、入札管理部、プロクシなど）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体からリソース管理プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０２４３】
以上のように、本発明にかかる装置、およびプログラムは、市場メカニズムによるリソース割り当て方式によりリソースの管理を行うリソース管理装置、リソース管理プログラムに適している。
【図面の簡単な説明】
【０２４４】
【図１】第１の実施の形態に係わるセンサ情報システムのハードウェア構成を示す構成図である。
【図２】第１の実施の形態におけるソフトウェア構成のリソース管理の部分を説明するためのブロック図である。
【図３】第１の実施の形態に係るリソースの供給と消費の関係を説明するためのブロック図である。
【図４】リソース応札部と入札管理部の構成を示すブロック図である。
【図５】供給者の入札値計算部の処理の流れの例を示すフローチャートである。
【図６】生産者の入札値計算部の処理の流れの例を示すフローチャートである。
【図７】消費者の入札値計算部の処理の流れの例を示すフローチャートである。
【図８】入札処理が所定回数しか行われないことを説明するための説明図である。
【図９】処理単位時間を説明するための説明図である。
【図１０】物理リソースの入札情報の例を示す説明図である。
【図１１】データの入札情報の例を示す説明図である。
【図１２】物理リソースマネージャの落札者決定部の処理の流れの例を示すフローチャートである。
【図１３】情報表示アプリケーションの落札者決定部の処理の流れの例を示すフローチャートである。
【図１４】ラウンド繰り返し管理部の処理の流れの例を示すフローチャートである。
【図１５】ラウンド経過に伴うＣＰＵ利用率の入札と落札の量と値が変化する例を示す図表である。
【図１６】ラウンド経過に伴うデータの入札と落札の量と値が変化する例を示す表である。
【図１７】入札切り分け処理の流れの一例を示すフローチャートである。
【図１８】ノードが正常に動作している場合の動作例を示した説明図である。
【図１９】ノードの故障が起きた場合の動作例を示した説明図である。
【図２０】第２の実施の形態におけるソフトウェア構成のリソース管理の部分を説明するためのブロック図である。
【図２１】アプリケーション入札情報テーブルの一例を示した説明図である。
【図２２】設定情報テーブルの一例を示した説明図である。
【図２３】第２の実施の形態における入札切り分け処理の全体の流れを示すフローチャートである。
【図２４】ノードが正常に動作している場合の動作例を示した説明図である。
【図２５】ノードの故障が起きた場合の動作例を示した説明図である。
【符号の説明】
【０２４５】
１  センサ情報システム
２、３  ノード
４  ネットワーク
５  レーダー装置
６、８、９  端末装置
６ａ、８ａ、９ａ  表示装置
７  ソナー装置
２１、２２、３１、３２  ＣＰＵ
２３、３３  メモリ
２４、３４  ネットワークＩ／Ｆ
２５  レーダー装置Ｉ／Ｆ
２６、３６  端末装置Ｉ／Ｆ
２７、３７  バス
３５  ソナー装置Ｉ／Ｆ
４２、５２  物理リソースマネージャ
４３、５３  レーダー信号処理アプリケーション
４２ａ、５２ａ、４３ａ、５３ａ、４４ａ、５４ａ、４５ａ、５５ａ  リソース応札部
４２ｂ、５２ｂ、４５ｂ、５５ｂ  入札管理部
４３ｃ、５３ｃ、４４ｃ、５４ｃ  ラッパー
４３ｄ、５３ｄ、４４ｄ、５４ｄ、４５ｄ、５５ｄ  ロジック処理部
４４、５４  ソナー信号処理アプリケーション
４５  レーダー情報表示アプリケーション
５５  ソナー情報表示アプリケーション
１０１  リソース管理装置
１０２  リソース応札部
１０３  入札管理部
１０４  入札値計算部
１０５  最終入札値記憶部
１０６  落札者決定部
１０７  ラウンド繰り返し管理部
２０２、２０３  ノード
２４３、２５３  レーダー信号処理アプリケーション
２４４、２５４  ソナー信号処理アプリケーション
２４２ａ、２４３ａ、２４４ａ、２４５ａ  個別リソース応札部
２５２ａ、２５３ａ、２５４ａ、２５４ａ  個別リソース応札部
２４５  レーダー情報表示アプリケーション
２４６、２５６  プロクシ
２４６ａ、２５６ａ  リソース応札部
２４７、２５７  ＣＯＲＢＡミドルウェア
２４７ａ、２５７ａ  Implementation Repository
２５５  ソナー情報表示アプリケーション
【図１】
2008158921.tif 000003
【図２】
2008158921.tif 000004
【図３】
2008158921.tif 000005
【図４】
2008158921.tif 000006
【図５】
2008158921.tif 000007
【図６】
2008158921.tif 000008
【図７】
2008158921.tif 000009
【図８】
2008158921.tif 000010
【図９】
2008158921.tif 000011
【図１０】
2008158921.tif 000012
【図１１】
2008158921.tif 000013
【図１２】
2008158921.tif 000014
【図１３】
2008158921.tif 000015
【図１４】
2008158921.tif 000016
【図１５】
2008158921.tif 000017
【図１６】
2008158921.tif 000018
【図１７】
2008158921.tif 000019
【図１８】
2008158921.tif 000020
【図１９】
2008158921.tif 000021
【図２０】
2008158921.tif 000022
【図２１】
2008158921.tif 000023
【図２２】
2008158921.tif 000024
【図２３】
2008158921.tif 000025
【図２４】
2008158921.tif 000026
【図２５】
2008158921.tif 000027