(57)【要約】  【課題】特定のノード２０に負荷が集中させることなく、処理間の連携を考慮して複数のノード２０に処理を割り当てることができる分散処理システム１０を提供する。  【解決手段】本発明の分散処理システム１０は、マスタとなるノード２０が、各ノード２０に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を参照し、マスタ以外のノード２０に対して、それぞれのノード２０が有するリソースの処理能力の範囲内で、データの提供元の処理単位と当該データを処理する処理単位とを同一のノード２０に割り当てる。【選択図】図４
2010122773.tif 000002
【特許請求の範囲】
【請求項１】
互いにネットワーク接続された複数の情報処理装置を備え、それぞれの情報処理装置が互いに連携して動作する分散処理システムであって、
それぞれの情報処理装置は、
それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部と、
情報処理装置に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部と、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定部と、
自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、前記リソース情報格納部および前記処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当部と
を有することを特徴とする分散処理システム。
【請求項２】
請求項１に記載の分散処理システムであって、
前記処理割当部は、
必要な処理能力が大きい処理単位から順に、処理単位を情報処理装置に割り当てることを特徴とする分散処理システム。
【請求項３】
請求項１または２に記載の分散処理システムであって、
ぞれぞれの前記情報処理装置が有するリソースには、前記ネットワークを介さずに接続されているデバイスが含まれ、
前記処理定義には、
前記ネットワークを介さずに接続されている特定のデバイスと同数の処理単位が作成されるべきデバイス依存処理と、
当該デバイス依存処理に応じて作成される処理単位のいずれかが処理するデータの提供元の処理単位の処理ＩＤと、
処理ＩＤ毎の、単位時間当たりの実行回数を示すsensor-event値と、
処理ＩＤ毎の、単位時間当たりに実行されるイベントに必要な処理能力を示すmips値と
がさらに定義されており、
前記処理割当部は、
前記処理定義に前記デバイス依存処理が記述されている場合に、前記リソース情報格納部を参照し、前記ネットワークを介さずに接続されている特定のデバイスと同数の処理単位を新たに作成し、新たに作成したそれぞれの処理単位に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤを対応付け、対応付けた処理単位の処理ＩＤに対応付けられているsensor-event値と、新たに作成した処理単位に対応付けられているmips値とを乗算することにより、新たに作成したそれぞれの処理単位に必要な処理能力を算出し、自装置がマスタとなった場合に、前記処理定義および新たに作成した処理単位毎に必要な処理能力を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信することを特徴とする分散処理システム。
【請求項４】
請求項３に記載の分散処理システムであって、
前記処理割当部は、
前記ネットワークを介さずに接続されている特定のデバイスの数と同数の処理単位を新たに作成した場合に、新たに作成した処理単位が複数存在するならば、当該新たに作成した複数の処理単位の処理負荷が均等になるように、当該処理単位に、当該処理単位が処理するデータの提供元の処理単位の処理ＩＤを対応付けることを特徴とする分散処理システム。
【請求項５】
請求項３に記載の分散処理システムであって、
前記処理割当部は、
前記ネットワークを介さずに接続されている特定のデバイスの数と同数の処理単位を新たに作成した場合に、新たに作成した処理単位が複数存在するならば、当該新たに作成した処理単位に対応する特定のデバイスの処理能力の範囲内で、当該新たに作成したいずれかの処理単位に負荷が集中するように、当該処理単位に、当該処理単位が処理するデータの提供元の処理単位の処理ＩＤを対応付けることを特徴とする分散処理システム。
【請求項６】
請求項１から５のいずれかに記載の分散処理システムであって
自装置のリソース情報を第１の時間毎にネットワークを介して他の情報処理装置へ送信するリソース情報送信部と、
他の情報処理装置からリソース情報を受信した場合に、受信したリソース情報を前記リソース情報格納部に登録するリソース情報登録部と
をさらに備えることを特徴とする分散処理システム。
【請求項７】
請求項６に記載の分散処理システムであって、
前記リソース情報登録部は、
前記リソース情報格納部内に登録されているリソース情報を監視し、前記第１の時間よりも長い第２の時間以内に上書きされないリソース情報を前記リソース情報格納部から削除することを特徴とする分散処理システム。
【請求項８】
請求項６または７に記載の分散処理システムであって、
前記リソース情報送信部は、
前記リソース情報と共に、自装置の製造年月日を示す情報を１の時間毎に他の情報処理装置へ送信し、
前記リソース情報登録部は、
他の情報処理装置から受信した製造年月日を前記リソース情報格納部にさらに登録し、
前記マスタ決定部は、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定する場合に、前記リソース情報格納部を参照して、製造年月日が最新の情報処理装置をマスタとして提案することを特徴とする分散処理システム。
【請求項９】
請求項６または７に記載の分散処理システムであって、
自装置の障害を検出する障害発生検出部をさらに備え、
前記リソース情報送信部は、
前記障害発生検出部によって自装置に障害が発生したことが検出された場合に、次のリソース情報の送信タイミングで、リソース情報内に障害の発生を示す障害情報を含め、
前記リソース情報登録部は、
前記リソース情報に障害情報が含まれている場合に、障害情報以外のリソース情報で前記リソース情報格納部内の対応する情報を上書きすると共に、当該障害情報を障害履歴として前記リソース情報格納部に追加保存し、
前記マスタ決定部は、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定する場合に、前記リソース情報格納部を参照して、登録されている障害情報が少ない情報処理装置をマスタとして提案することを特徴とする分散処理システム。
【請求項１０】
請求項６または７に記載の分散処理システムであって、
自装置の稼働環境を測定し、稼働環境が悪い場合に高い数値を示す環境値を出力する環境測定部をさらに備え、
前記リソース情報送信部は、
前記環境測定部が出力した環境値をリソース情報内に含めて他の情報処理装置へ送信し、
前記マスタ決定部は、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定する場合に、前記リソース情報格納部を参照して、リソース情報に含まれている環境値が低い情報処理装置をマスタとして提案することを特徴とする分散処理システム。
【請求項１１】
請求項６から１０のいずれかに記載の分散処理システムであって、
前記マスタ決定部は、
自装置が起動してからの前記リソース情報格納部内のリソース情報の登録数の増加率を算出し、当該増加率が上昇から下降に転じた後に、当該増加率が、当該増加率の最大値から予め定められた割合だけ低い増加率となった場合に、その時点の情報処理装置の台数を、分散合意アルゴリズムにおける定足数として分間合意アルゴリズムを用いたマスタの決定処理を開始することを特徴とする分散処理システム。
【請求項１２】
互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムにおける処理割当方法であって、
それぞれの情報処理装置が、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定ステップと、
自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部、ならびに、情報処理装置に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当ステップと
を実行することを特徴とする処理割当方法。
【請求項１３】
互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムに用いられる情報処理装置であって、
それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部と、
情報処理装置に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部と、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定部と、
自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、前記リソース情報格納部および前記処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当部と
を備えることを特徴とする情報処理装置。
【請求項１４】
互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムに用いられる情報処理装置における処理割当方法であって、
前記情報処理装置が、
分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定ステップと、
自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部、ならびに、処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当ステップと
を実行することを特徴とする処理割当方法。
【請求項１５】
互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムであって、
それぞれの情報処理装置は、
他の情報処理装置の識別情報を格納する識別情報格納部と、
自装置が起動した場合に、他の情報処理装置に自装置の識別情報を通知する識別情報通知部と、
他の情報処理装置から受信した識別情報を前記識別情報格納部に格納する識別情報登録部と、
自装置が起動してからの前記識別情報格納部内の識別情報の登録数の増加率を算出し、当該増加率が上昇から下降に転じた後に、当該増加率が、当該増加率の最大値から予め定められた割合だけ低い増加率となった場合に、その時点で前記識別情報格納部に格納されている識別情報の数を、分散合意アルゴリズムにおける定足数として、分間合意アルゴリズムを用いた処理を開始する分散合意処理部と
を備えることを特徴とする分散処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散処理システム、処理割当方法、および情報処理装置に関し、特に互いにネットワーク接続された複数の情報処理装置を備え、それぞれの情報処理装置が互いに連携して動作する技術に関する。
【背景技術】
【０００２】
近年、RFID(Radio Frequency IDentification)や温度センサ等の各種センサを、情報システムと容易に連携することが可能となり、各種センサを活用したシステムが利用されるようになってきた。通常、これらセンサを活用する情報システムでは、専用の小型計算機がセンサを制御してセンサからデータを取得し、データをサーバへ送信する構成をとる場合が多い。小型計算機から送信されたデータは、様々なアプリケーションから利用できる形でサーバ内に蓄積される。それぞれの小型計算機は、サーバの負荷を軽減するために、簡単なデータ加工（例えば、差分抽出や時間平均等）を行い、データ量を少なくしてからサーバへデータを送信する場合がある。
【０００３】
１つの小型計算機では、その性能やセンサを接続するための接続インターフェイスの数等に限界があるため、大規模なシステムを構築する場合には、複数の小型計算機を利用する場合が多い。例えば、センサを制御する小型計算機と、センサが出力したデータを加工する小型計算機とを別々に用意しておき、小型計算機同士が連携する構成とする場合が多い。この場合、大規模なシステムでは、小型計算機の性能条件等を考慮した上で、どの小型計算機にどの役割（例えば、センサの制御やデータの加工）を実行させるか、どの小型計算機同士が連携するか等を決定する必要がある。上記した複数の小型計算機同士が連携して各種センサからデータを収集するシステムを、以後、ユビキタスフロントエンドシステムと呼ぶ。
【０００４】
例えば特許文献１には、業務プログラム毎に、その業務プログラムの実行に必要なリソース（例えば、ＣＰＵやストレージ等）の量を管理しておき、別途管理しているシステムのリソース情報と付き合わせて、業務プログラムへのリソース割り当て量を決定する技術が開示されている。上記したユビキタスフロントエンドシステムに特許文献１の技術を適用すると、各小型計算機の役割を自動的に決定することができる。
【０００５】
また、特許文献２には、サービス連携エンジンがサービス連携シナリオに記載された制御ロジックに基づき、利用すべきサービスコンポーネントを検索し、適切なサービスコンポーネントを順に呼び出す技術が開示されている。ユビキタスフロントエンドシステムに特許文献２の技術を適用すると、サービス間の連携方法を１つのサービス連携シナリオとして記述できるため、連携のための設定を各小型計算機に行う必要がなくなる。
【０００６】
特許文献１または２のようなシステムでは、システムを構成する計算機の１つが管理機能を有する計算機（管理計算機）となる。すなわち、特許文献１では業務プログラムへのリソースの割り当て量を決定する計算機が管理計算機となり、特許文献２では、サービス連携エンジンが動作する計算機が管理計算機となる。
【０００７】
また、小型計算機は、センサの近くに配置される場合が多い。そのため、通常の計算機と比較して過酷な環境（例えば、振動や埃が多い場所）で利用されることが多く、障害発生頻度が高い場合が多い。そのため、ユビキタスフロントエンドシステムでは、管理計算機に障害が発生した場合に、他の計算機が管理計算機となって処理を続けることができるようにするため、特定の小型計算機を固定的に管理計算機とするのではなく、複数の小型計算機の中から動的に管理計算機が選択される構成とすることが望ましい。
【０００８】
例えば特許文献３には、複数の計算機から管理計算機を決定する技術として、リング型ネットワークにおいて、各ノード（計算機）が自身の優先度を隣接ノードに転送し、最終的に最も優先度が高いノードを管理計算機として決定する技術が開示されている。また、複数の小型計算機同士が連携して１つの管理計算機を決定することは、分散合意の一種と考えることができる。分散合意とは、各計算機が独立に動作するが、互いの情報をやり取りすることにより、最終的には全ての計算機が同一の結果に辿り着く技術である。
【０００９】
非特許文献１には、分散合意アルゴリズムを使ったＰＡＸＯＳというプロトコルが開示されている。ＰＡＸＯＳとは、計算機間で投票処理を行い、定足数（多くの場合過半数とする）以上の合意が得られれば、結果をすべての計算機に確定するプロトコルであり、全ての計算機から合意が得られなくても、定足数以上の合意が得られれば、結果を確定することができる。
【００１０】
【特許文献１】特開２００４−３０２９３７号公報
【特許文献２】特開２００８−１３００３３号公報
【特許文献３】特開２００１−３５８７３６号公報
【非特許文献１】Ｌａｍｐｏｒｔ，  Ｌ．  Ｔｈｅ  ｐａｒｔ−ｔｉｍｅ  ｐａｒｌｉａｍｅｎｔ．  ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  １６，  ２  （１９９８），  １３３−１６９
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、ユビキタスフロントエンドシステムでは、小型計算機上で稼動するあるプログラムが必要とするリソースの量は、そのプログラムの処理内容に加えて、そのプログラムと連携する他のプログラムの動作にも依存する。例えば、センサを制御するプログラム（制御プログラム）が取得したデータを、別のプログラム（加工プログラム）が加工する場合、加工プログラムのＣＰＵ負荷は加工処理の内容だけでなく、制御プログラムから受信するデータの量にも依存する。また、複数の制御プログラムが加工プログラムにデータを送信する構成とした場合、加工プログラムのＣＰＵ負荷は、制御プログラムの数にも依存する。
【００１２】
上記した特許文献１では、各プログラムが必要とするリソースの量は、各プログラム個別の属性として管理されているため、プログラム間の連携が考慮されておらず、各プログラムは割り当てられたリソースで他のプログラムと連携して適切に動作することができない場合がある。また、特許文献２では、各サービスコンポーネントが作業を終了するたびに、その時点での変数等のデータを全てサービス連携エンジンが取得して次の各サービスコンポーネントに渡すため、サービス連携エンジンは、全てのサービスコンポーネントの動作に関与しなければならず、サービス連携エンジンに負荷が集中する場合がある。従って、ＣＰＵの性能やメモリ容量等が限られた小型計算機上で、サービス連携エンジンを動作させることができない場合がある。
【００１３】
また、システムの規模が大きくなると、それぞれの小型計算機が異なるネットワークに配置される場合がある。また、ネットワークがリング型でなくバス型のＬＡＮに上記の特許文献３の技術を用いるとすれば、ブロードキャストパケットを用いることになる。しかし、ネットワークの境界にあるルータ等の通信機器に所定のブロードキャストパケットを通過させる等の設定を行う必要があり、設定作業が煩雑になる。
【００１４】
また、ＰＡＸＯＳは、全体の過半数の合意が得られれば結果を確定することが可能であるが、過半数であるかどうかを決定するためには、全体のノード数が予め分かっている必要がある。管理者が全てのノード数を把握して設定することも考えられるが、システムの規模が大きくなったり、ノードが故障して機能しなくなったり、ノードが新たに追加されたりした場合、ノード数をその都度全て把握することは難しい。そこで、それぞれのノードが他のノードに自ノードの情報を発信させることで、自動的にシステム全体のノード数を測定することも考えられる。
【００１５】
しかし、システムの規模異が大きくなり、ノードが異なるネットワークに存在する場合には、ブロードキャストだけでなくユニキャストによる通信も行う必要があることから、それぞれのノードが全てのノードの情報を受信するには長い時間がかかる場合がある。そのため、システムはＰＡＸＯＳによる分散合意を開始するまでに長時間待機しなければならない場合があった。
【００１６】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、特定の計算機に負荷が集中することなく、処理間の連携を考慮して複数の計算機に処理を割り当てることにある。また、本発明の目的は、分散合意をより迅速に開始することができるようにすることにある。
【課題を解決するための手段】
【００１７】
上記課題を解決するために本発明は、複数の情報処理装置を有する分散処理システムにおいて、マスタとなる情報処理装置が、情報処理装置に割り当てる処理の単位である処理単位毎に、当該処理単位が処理するデータを提供する処理単位、および、当該処理単位に必要な処理能力を定義する処理定義を参照して、マスタ以外の情報処理装置に対して、それぞれの情報処理装置が有するリソースの処理能力の範囲内で、データの供給元の処理単位と当該データを処理する処理単位とを同一の情報処理装置に割り当てる。
【００１８】
例えば、本発明の第一の態様は、互いにネットワーク接続された複数の情報処理装置を備え、それぞれの情報処理装置が互いに連携して動作する分散処理システムであって、それぞれの情報処理装置は、それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部と、情報処理装置に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部と、分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定部と、自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、前記リソース情報格納部および前記処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当部とを有することを特徴とする分散処理システムを提供する。
【００１９】
また、本発明の第二の態様は、互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムにおける処理割当方法であって、それぞれの情報処理装置が、分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定ステップと、自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部、ならびに、情報処理装置に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当ステップとを実行することを特徴とする処理割当方法を提供する。
【００２０】
また、本発明の第三の態様は、互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムに用いられる情報処理装置であって、それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部と、情報処理装置に割り当てる処理の単位である処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部と、分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定部と、自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、前記リソース情報格納部および前記処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当部とを備えることを特徴とする情報処理装置を提供する。
【００２１】
また、本発明の第四の態様は、互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムに用いられる情報処理装置における処理割当方法であって、情報処理装置が、分散合意アルゴリズムを使って複数の情報処理装置間でマスタを決定するマスタ決定ステップと、自装置がマスタとなった場合に、自装置以外のそれぞれの情報処理装置について、それぞれの情報処理装置を識別するノードＩＤに対応付けて、当該情報処理装置が有するリソースの情報を格納するリソース情報格納部、ならびに、処理単位を識別する処理ＩＤ毎に、当該処理単位が処理するデータを提供する処理単位の処理ＩＤ、および、当該処理単位に必要な処理能力を定義する処理定義を格納する処理定義格納部を参照し、自装置以外のそれぞれの情報処理装置に対して、当該情報処理装置が有するリソースの処理能力の範囲内で、データを処理する処理単位と当該データの提供元の処理単位とを同一の情報処理装置に割り当て、割当結果をネットワークを介してそれぞれの情報処理装置へ送信する処理割当ステップとを実行することを特徴とする処理割当方法を提供する。
【００２２】
また、本発明の第五の態様は、互いにネットワーク接続されたそれぞれの情報処理装置が互いに連携して動作する分散処理システムであって、それぞれの情報処理装置は、他の情報処理装置の識別情報を格納する識別情報格納部と、自装置が起動した場合に、他の情報処理装置に自装置の識別情報を通知する識別情報通知部と、他の情報処理装置から受信した識別情報を前記識別情報格納部に格納する識別情報登録部と、自装置が起動してからの前記識別情報格納部内の識別情報の登録数の増加率を算出し、当該増加率が上昇から下降に転じた後に、当該増加率が、当該増加率の最大値から予め定められた割合だけ低い増加率となった場合に、その時点で前記識別情報格納部に格納されている識別情報の数を、分散合意アルゴリズムにおける定足数として、分間合意アルゴリズムを用いた処理を開始する分散合意処理部とを備えることを特徴とする分散処理システムを提供する。
【発明の効果】
【００２３】
本発明によれば、特定の計算機に負荷が集中することなく、処理間の連携を考慮して複数の情報処理装置に処理を割り当てることができる。また、本発明によれば、分散合意をより迅速に開始することができる。
【発明を実施するための最良の形態】
【００２４】
まず、本発明の第１の実施形態について説明する。
【００２５】
図１は、本発明の第１実施形態に係る分散処理システム１０の一例を示すシステム構成図である。分散処理システム１０は、ユビキタスフロントエンドシステムの一例であり、複数の情報処理装置２０（以下ノード２０と呼ぶ）および複数のセンサ１４を備える。
【００２６】
それぞれのノード２０は計算機用ＬＡＮ１２およびセンサ用ＬＡＮ１３に接続されている。それぞれのノード２０は、計算機用ＬＡＮ１２を介して、他のノード２０や、計算機用ＬＡＮ１２に接続されているコンソール１１と通信する。また、それぞれのノード２０は、センサ用ＬＡＮ１３を介してそれぞれのセンサ１４を制御する。それぞれのセンサ１４にはアドレス（例えばＩＰアドレス）が割り当てられており、それぞれのノード２０は、センサ用ＬＡＮ１３を介して、それぞれのセンサ１４にアクセスすることができる。
【００２７】
本実施形態において、分散処理システム１０は、ノード２０−０〜ノード２０−３を有する。また、ノード２０−３には、センサ用ＬＡＮ１３を介さずにＲＦＩＤのリーダライタ（Ｒ／Ｗ）であるセンサ１４ｃおよび１４ｄが接続されている。また、ノード２０−１にはアンテナ１５−１が接続されており、ノード２０−２にはアンテナ１５−２が接続されている。
【００２８】
コンソール１１は、各ノード２０から構成されるユビキタスフロントエンドシステムとユーザ間の情報伝達を行うための端末であり、分散処理システム１０の管理者等によって操作される。コンソール１１は、例えば通信機能を有する汎用のコンピュータであり、ディスプレイ、キーボード、およびマウス等の入出力装置が接続されている。分散処理システム１０の管理者は、これらの入出力装置を操作して分散処理システム１０へ指示を出したり、稼働状況を確認したりする。
【００２９】
図２は、コンソール１１の動作の一例を示すフローチャートである。例えば電源が投入される等の所定のタイミングで、コンソール１１は、本フローチャートに示す動作を開始する。
【００３０】
まず、コンソール１１は、分散処理システム１０の管理者等のユーザから処理定義を入力されたか否かを判定する（Ｓ１００）。処理定義の詳細な内容については後述する。処理定義がユーザから入力された場合（Ｓ１００：Ｙｅｓ）、コンソール１１は、複数のノード２０の中でマスタとなるノード２０のアドレスを要求するマスタ情報要求を、計算機用ＬＡＮ１２を介して全てのノード２０に、例えばブロードキャストによって送信する（Ｓ１０１）。
【００３１】
次に、コンソール１１は、計算機用ＬＡＮ１２を介してマスタとなるノード２０のアドレスを受信したか否かを判定する（Ｓ１０２）。マスタとなるノード２０のアドレスを受信した場合（Ｓ１０２：Ｙｅｓ）、コンソール１１は、当該ノード２０へユーザから入力された処理定義を送信し（Ｓ１０３）、再びステップＳ１００に示した処理を実行する。一方、マスタとなるノード２０のアドレスを受信しなかった場合（Ｓ１０２：Ｎｏ）、コンソール１１は、所定時間（例えば１０秒間）待機して再びステップＳ１０１に示した処理を実行する。
【００３２】
また、ステップＳ１００において、処理定義がユーザから入力されていない場合（Ｓ１００：Ｎｏ）、コンソール１１は、ユーザからマスタの再選出を指示されたか否かを判定する（Ｓ１０５）。マスタの再選出を指示されていない場合（Ｓ１０５：Ｎｏ）、コンソール１１は、再びステップＳ１００に示した処理を実行する。
【００３３】
一方、マスタの再選出を指示された場合（Ｓ１０５：Ｙｅｓ）、コンソール１１は、マスタ情報要求を計算機用ＬＡＮ１２を介して全てのノード２０に、例えばブロードキャストによって送信する（Ｓ１０６）。そして、コンソール１１は、マスタのノード２０にマスタの再選出を指示するメッセージを送信し（Ｓ１０７）、再びステップＳ１００に示した処理を実行する。
【００３４】
次に、それぞれのノード２０の構成について説明する。図３は、第１の実施形態におけるそれぞれのノード２０のハードウェア構成の一例を示す。ノード２０は、ＲＡＭ（Random Access Memory）２００、ＲＯＭ（Read Only Memory）２０１、ＣＰＵ（Central Processing Unit）２０２、ＬＡＮインターフェイス（Ｉ／Ｆ）２０５、ＬＡＮインターフェイス（Ｉ／Ｆ）２０６、およびメディアインターフェイス（Ｉ／Ｆ）２０７を備える。また、複数のノード２０の中には、入出力インターフェイス（Ｉ／Ｆ）２０３、無線インターフェイス（Ｉ／Ｆ）２０４、およびセンサインターフェイス（Ｉ／Ｆ）２０８の少なくともいずれかを含むものがある。
【００３５】
ＲＡＭ２００は、実行中のプログラムやプログラムが取り扱うデータを一時的に保存する。ＲＯＭ２０１には、初期起動用のプログラムが格納されている。ＣＰＵ２０２は、ＲＯＭ２０１または記録媒体２１３から読み出されてＲＡＭ２００に展開されたプログラム等を実行する。ＣＰＵ２０２は、ノード２０の電源が投入されると、ＲＯＭ２０１からプログラムを読み出してＲＡＭ２００に展開して実行する。メディアインターフェイス２０７は、コンパクトフラッシュ（登録商標）メモリカード等の記録媒体２１３を取り付けるためのインターフェイスである。当該記録媒体２１３には、各種プログラムやデータが格納され、メディアインターフェイス２０７は、ＣＰＵ２０２からの指示に応じて、これらを記録媒体２１３から読み出してＲＡＭ２００上に展開する。
【００３６】
ＬＡＮインターフェイス２０５およびＬＡＮインターフェイス２０６は、一般的なイーサネット（登録商標）規格のネットワークインターフェイスである。各ノード２０は２つのＬＡＮインターフェイスを備える。センサインターフェイス２０８は、例えばRS-232C規格等のシリアル通信インターフェイスであり、ノード２０に接続されているセンサ１４を制御するときに利用される。無線インターフェイス２０４はモバイル通信カード等の通信インターフェイスであり、分散処理システム１０内のいずれかのノード２０が収集したデータをデータ収集サーバ（図示せず）に送信するときに利用される。ノード２０を設置する現場では、有線ネットワークのインフラが整備されていない場合が多く、このような場合に本実施形態ではモバイル通信カードを利用してデータ収集サーバへデータを送信する。
【００３７】
入出力インターフェイス２０３、無線インターフェイス２０４、およびセンサインターフェイス２０８は、分散処理システム１０内の全てのノード２０に設けられている必要はない。すなわち、センサインターフェイス２０８は、センサ用ＬＡＮ１３を介さずにセンサ１４を接続するノード２０（図１の例ではノード２０−３）が備えていればよい。また、無線インターフェイス２０４は、データ収集サーバと通信するノード２０（図１の例ではノード２０−１およびノード２０−２）が備えていればよい。
【００３８】
次に、それぞれのノード２０の機能構成を説明する。図４は、第１の実施形態におけるそれぞれのノード２０の機能構成の一例を示すブロック図である。ノード２０は、リソース情報送信部２１、リソース情報登録部２２、履歴情報格納部２３、履歴情報管理部２４、マスタ決定部２５、処理割当部２６、リソース情報格納部２７、スレーブ処理部２８、およびセンシングアプリケーション実行部２９を備える。これらの機能を実現するプログラムは図３に示した記録媒体２１３に格納されており、ＣＰＵ２０２は、これらのプログラムをメディアインターフェイス２０７を介して記録媒体２１３から読み出してＲＡＭ２００に展開して実行する。
【００３９】
センシングアプリケーション実行部２９は、ディスパッチャ２９０、フィルタ２９１、駆動制御２９２、およびアダプタ２９３を有する。アダプタ２９３は、センサ１４間のインターフェイスの違いを吸収し、様々なセンサ１４を同一インターフェイスから利用できるようにする。駆動制御２９２は、センサ１４からデータを取得するタイミングを制御する。フィルタ２９１は、アダプタ２９３がセンサ１４から取得したデータを加工する。ディスパッチャ２９０は、アダプタ２９３がセンサ１４から取得したデータまたはフィルタ２９１が加工したデータを、予め定められた通信プロトコルでデータ収集サーバへ送信する。
【００４０】
センシングアプリケーション実行部２９の動作を纏めると例えば以下のようになる。駆動制御２９２が駆動指示をアダプタ２９３へ送信すると、アダプタ２９３はセンサ１４を制御してセンサ１４からデータを取得し、取得したデータを駆動制御２９２に返信する。駆動制御２９２は、受信したデータをフィルタ２９１へ送信し、フィルタ２９１はデータ加工を行った後、加工したデータをディスパッチャ２９０に渡す。最後にディスパッチャ２９０は、受け取ったデータをデータ収集サーバへ送信する。
【００４１】
このようにセンシングアプリケーション実行部２９内の各機能ブロックは連携動作するが、機能ブロック間の連携は１つのノード２０内で閉じるわけではなく、異なるノード２０の機能ブロック同士が連携する場合もある。例えば、アダプタ２９３、駆動制御２９２、フィルタ２９１、およびディスパッチャ２９０が全て異なるノード２０上で動作し、相互に連携することも可能であるし、あるノード２０上で動作する駆動制御２９２が、それぞれのノード２０上で動作するアダプタ２９３に対して、計算機用ＬＡＮ１２を介して順にデータ取得指示を送信することも可能である。
【００４２】
リソース情報格納部２７には、例えば図５に示すようなリソース情報管理テーブル２７０が格納されている。リソース情報管理テーブル２７０には、複数のレコード２７６が格納されており、それぞれのレコード２７６には、それぞれのノード２０を識別するノードＩＤ２７１、当該ノード２０のアドレス２７２（本実施形態ではＩＰアドレス）、当該レコード２７６が新たに登録されたあるいは更新された時刻を示す受信時刻２７３、当該ノード２０のリソース情報２７４、および当該ノード２０の製造年月日２７５が格納される。リソース情報２７４には、それぞれのリソースを識別する識別子（図５の例では、「Communicate」、「Cpu」、「Sensor」等）毎に、当該識別子によって特定されるリソースの詳細な情報が格納される。なお、リソース情報管理テーブル２７０には、自ノード２０のリソース情報が予め格納されている。また、自ノード２０に関しては、受信時刻２７３にはデータが登録されない。
【００４３】
例えば、図５に示した２７０には、ノードＩＤ２７１が「001」であるノード２０は、リソースとして通信手段（「Communicate」に対応）とCpuとを提供し、通信手段の性能は「80kbps」であり、Cpuの性能は「200mips（million instructions per second）」であることが記載されている。また、当該リソース情報管理テーブル２７０には、上記通信手段はデバイス識別子(devId)で識別され、当該通信手段のデバイス識別子の値が「card001」であることが記載されている。また、ノードＩＤ２７１が「003」であるノード２０には、シリアル(RS-232C)で制御するRFIDデバイスのセンサ１４が２個接続されており、各RFIDデバイスの識別子（devId）の値と各デバイスにアクセスするときに使用するシリアルポート名（serial）とが記載されている。
【００４４】
履歴情報格納部２３には、例えば図６に示すように、それぞれの履歴情報を識別する履歴番号２３０に対応付けて、当該履歴情報の内容２３１が格納される。図６の例では、履歴番号２３０が「013」および「014」のエントリがマスタノード情報であり、マスタノードのノードＩＤとリース期間とが含まれる。他のノード２０との間でマスタのノード２０が決まった場合に、マスタノードのノードＩＤとリース期間とが履歴として履歴情報格納部２３に格納される。図６に示した例において、履歴番号２３０が「013」のエントリでは、マスタノードのノードＩＤが「000」であり、リース期間が「10時5分0秒まで」となっている。
【００４５】
また、コンソール１１や他のノード２０から送信された処理定義も履歴情報として履歴情報格納部２３に格納される。図６に示した例において、履歴番号２３０が「015のエントリが処理定義である。処理定義は、図７に示す処理定義テンプレートと、図８および図９に示す処理定義本体とを含む。処理定義テンプレートは、処理定義本体に記載する内容のうち、カスタマイズされることがない項目、もしくはカスタマイズされる頻度が少ない項目を分離して記載したものである。つまり、処理定義テンプレートとは、処理定義本体に繰り返し記載する必要がある項目のデフォルト値を別にまとめたものである。全ての項目を処理定義本体に記載すれば、処理定義を分離する必要はないが、分離することで処理定義の作成作業を効率的に行うことができる。処理定義に記載されている内容の詳細については後述する。
【００４６】
リソース情報送信部２１は、自ノード２０のノードＩＤ、自ノード２０のアドレス、自ノード２０のリソース情報、および自ノード２０の製造年月日をリソース情報格納部２７内のリソース情報管理テーブル２７０から読み出して、計算機用ＬＡＮ１２を介して他のノード２０へ例えばブロードキャストにより送信する。なお、ＩＰ（Internet Protocol）が用いられる場合、リソース情報送信部２１が送信するブロードキャストパケットのパケットヘッダには、自ノード２０のＩＰアドレスが記録されるので、リソース情報送信部２１が明示的にブロードキャストパケットのメッセージに上記アドレスを記録する必要はない。
【００４７】
リソース情報登録部２２は、計算機用ＬＡＮ１２を介して他のノード２０からノードＩＤ、アドレス、リソース情報、および製造年月日を受信した場合に、リソース情報格納部２７内のリソース情報管理テーブル２７０を参照し、当該ノードＩＤがリソース情報管理テーブル２７０内に登録されていないならば、受信したこれらの情報と共に受信時刻をリソース情報管理テーブル２７０に新規に登録する。また、受信したノードＩＤがリソース情報管理テーブル２７０内に既に登録されているならば、リソース情報登録部２２は、受信したこれらの情報でリソース情報管理テーブル２７０内の情報を上書きすると共に、受信時刻を更新する。また、リソース情報登録部２２は、リソース情報管理テーブル２７０内の受信時刻を監視し、受信時刻から予め定められた時間（例えば４０秒）が経過したエントリをリソース情報管理テーブル２７０から削除する。
【００４８】
マスタ決定部２５は、分散合意により分散処理システム１０内の複数のノード２０間でマスタノードを決定する処理を実行する。マスタ決定部２５は、履歴情報管理部２４またはスレーブ処理部２８からマスタノードの決定を指示された場合に、例えばＰＡＸＯＳプロトコルを用いてマスタノードを選出する。ＰＡＸＯＳプロトコルを用いてマスタノードを選出する過程を説明するためのシーケンスを図１０に示す。ＰＡＸＯＳプロトコルは、１つの投票開催者と複数の投票参加者間の通信プロトコルである。図１０ではノード２０−０が投票開催者であり、ノード２０−１〜３が投票参加者となるケースを例として示している。
【００４９】
各投票は、決定する事項に対する番号（前述の履歴番号に等しい）と各投票に対する番号とを使用して管理される。本実施形態では、決定する事項に対する番号を事項番号（図１０ではＤと記載）と呼び、各投票に対する番号を投票番号（図１０ではｂと記載）と呼ぶ。各ノード２０のマスタ決定部２５は、ＰＡＸＯＳプロトコル処理のために、Ｑ、Ｄ、lastTried、nextBallot、lastVoteBallot、lastVoteDecreeという変数を内部に保持する。Ｑは定足数を意味し、ある事項に関して定足数以上の合意が得られれば、その事項が決定される。本実施形態において定足数は全参加者の過半数とする。Ｄは投票によって決定する事項の事項番号である。lastTriedは開催中の投票番号である。nextBallotは投票参加者が参加中の投票の投票番号である。lastVoteBallotは投票参加者が最後に投票した投票の投票番号である。lastVoteDecreeは投票参加者が最後に投票した投票の事項の内容である。
【００５０】
まず、新規に提案を行おうとするノード２０−０のマスタ決定部２５は、これから開催する投票の投票番号をnextBallotよりも大きな値になるように決め、lastTriedとnextBallotに保存する。ここでは、投票開催者は自身が開催する投票に対して投票参加者を兼ねるため、nextBallotにも投票番号を保存している。そして、マスタ決定部２５は、これから決定する事項の事項番号Ｄと、上記投票番号（図１０ではｂと記載）とを有するPrepareメッセージを作成し、ノード２０−１〜３へ送信し、これから投票を開始する旨を通知する（Ｓ２００）。ＰＡＸＯＳプロトコルでは、投票番号は投票毎に一意となる必要があるが、実際には任意のノードが投票開催者になる可能性があるため、異なるノード２０が開催した投票の投票番号が重複することを避ける必要がある。本実施形態では、投票番号にノードＩＤを含めることで、投票番号の重複を防いでいる。
【００５１】
次に、Pepareメッセージを受信したノード２０−１〜３のマスタ決定部２５は、自ノード２０が保持するnextBallotと受信したPrepareメッセージに含まれる投票番号ｂとを比較し、nextBallotが当該投票番号ｂよりも小さければ、nextBallotの値をｂに変更し、その投票への参加表明としてPromiseメッセージを送信する（Ｓ２０１）。マスタ決定部２５は、Prepareメッセージに含まれる事項番号Ｄに関して、以前に投票したことがあれば、以前の投票の情報（投票番号と事項内容と）をPromiseメッセージに含めて送信する。以前の投票の情報は、変数lastVoteBallotおよびlastVoteDecreeに保持されているので、これを利用する。
【００５２】
次に、ノード２０−０のマスタ決定部２５は、定足数（Ｑ−１）以上のノードからPromiseメッセージを受信した場合に、受信したPromiseメッセージに含まれるlastVoteBallot、lastVoteDecreeをチェックし、その中から最も値が大きいlastVoteBallotに対応するlastVoteDecreeを、次の投票の提案内容とする（Ｓ２０２）。事項番号Ｄに関して、今回が最初の投票である場合、どのノード２０からもlastVoteDecreeは送信されない。このような場合、ノード２０−０は、自身で決定した自提案を次の投票の提案内容とする。本実施形態において、マスタ決定部２５は、リソース情報格納部２７を参照して、製造年月日が最も新しいノード２０をマスタノードとして推薦する旨を自案として作成する。
【００５３】
次に、ノード２０−０のマスタ決定部２５は、事項番号Ｄ、変数lastTried、およびステップＳ２０２において決定した提案内容を含むAcceptメッセージを生成し、作成したAcceptメッセージをステップＳ２０１においてPromiseメッセージを送信したノード２０へ送信することで投票を開始する（Ｓ２０３）。図１０では、Accesptメッセージに含まれる投票番号をｂと記載しているが、これは上記変数lastTriedに等しい。また、図１０では、Acceptメッセージ含まれる提案内容を「Decree」と記載している。
【００５４】
次に、Acceptメッセージを受信したノード２０−１〜３のマスタ決定部２５は、Acceptメッセージに含まれる投票番号ｂとnextBallotとを比較し、ｂがnextBallotに一致した場合に、その提案に投票する（Ｓ２０４）。具体的には、Acceptメッセージに含まれる投票番号ｂをlastVoteBallotに、Acceptメッセージに含まれる提案内容DecreeをlastVoteDecreeに保存し、投票したことを示すためにAcceptedメッセージをノード２０−０へ送信する。
【００５５】
次に、ノード２０−０のマスタ決定部２５は、定足数（Ｑ−１）以上のノード２０からAcceptedメッセージを受信したら、事項が決定したことを示すために、事項番号Ｄと提案内容を含むCommitメッセージを作成し、全てのノードにCommitメッセージを送信する（Ｓ２０５）。この場合、Acceptedメッセージを送信しなかったノード２０に対しても、Commitメッセージが送信されることになる。
【００５６】
次に、ノード２０−０のマスタ決定部２５は、Commitメッセージを送信した場合に、事項番号Ｄを履歴番号として履歴情報格納部２３内の履歴番号２３０（図６参照）に格納し、提案内容を履歴情報格納部２３内の内容２３１に格納し、事項番号Ｄをインクリメントする。Commitメッセージを受信したノード２０−１〜３のマスタ決定部２５も同様に、Commitメッセージに含まれる事項番号Ｄと提案内容Decreeとを履歴情報格納部２３に格納し、事項番号Ｄをインクリメントする。そして、ノード２０−０〜３のマスタ決定部２５は、lastVoteBallotとlastVoteDecreeとを初期化する（Ｓ２０６）。
【００５７】
上記ステップＳ２００において、ノード２０−０のマスタ決定部２５が、以前に少なくとも１回Prepareメッセージを送信したことがあり、lastTriedとnextBallotの値が等しい場合、ステップＳ２００およびＳ２０１を省略してステップＳ２０３から実行されてもよい。このとき、投票番号は以前の番号（すなわちlastTriedもしくはnextBallot）をそのまま利用され、自提案が提案内容となる。
【００５８】
実際には、複数のノードが同時に投票を開催する場合があるため、ＰＡＸＯＳプロトコルでは、Ｓ２００〜Ｓ２０１の準備段階と、Ｓ２０３〜Ｓ２０４の投票段階の２段階を踏むことで衝突検出を行い、衝突が発生した投票が無効となるようにしている。例えば、Ｓ２００でノード２０−１が、ノード２０−０からPrepareを受信した後であり、かつ、Acceptを受信する前に、他のノード２０からより大きな投票番号を持つPrepareメッセージを受信した場合は、ノード２０−１は後から受信したPrepareメッセージ対してPromiseメッセージを返信する。以後、ノード２０−１はノード２０−０が開催する投票には参加しない。
【００５９】
履歴情報格納部２３に登録される内容２３１にはリース期間が含まれる。マスタノードはリース期間が経過する前に、リース期間を更新したマスタノード情報を上記ＰＡＸＯＳプロトコルによって全ノード２０へ送信し、後述する履歴情報管理部２４が、更新されたマスタノードを履歴情報格納部２３内に追記する。いったんマスタノードが決定した場合は、リース期間が切れるか、もしくはマスタノードに障害が発生するまで、マスタノード以外のノード２０はＰＡＸＯＳの投票開催者にはならない。これによって、スムーズにリース期間の更新が行われるようになっている。
【００６０】
マスタ決定部２５は、決定したマスタノードが自ノード２０である場合に、履歴情報格納部２３に格納されている処理定義に基づいてそれぞれのノード２０への処理の割当を処理割当部２６に指示する。また、マスタ決定部２５は、コンソール１１からマスタノードの再選出を指示された場合に、ＰＡＸＯＳプロトコルを用いてマスタを再度決定し直す。また、自ノード２０がマスタとならなかった場合、マスタ決定部２５は、マスタノードのノードＩＤをスレーブ処理部２８に通知する。
【００６１】
履歴情報管理部２４は、自ノード２０の起動後に、リソース情報格納部２７のリソース情報管理テーブル２７０内に登録されているノード２０の数を監視し、リソース情報管理テーブル２７０内に登録されているノード２０の数が全ノード２０の数の半数以上となった場合に、他のノード２０へ履歴情報を要求するメッセージを、例えばブロードキャストにより計算機用ＬＡＮ１２を介して送信し、他のノード２０から履歴情報を受信して履歴情報格納部２３に格納する。そして、履歴情報管理部２４は、履歴情報格納部２３を参照し、リース期限内のマスタノード情報が存在するか否かを判定する。リース期限内のマスタノード情報が履歴情報格納部２３内に存在する場合、履歴情報管理部２４は、マスタノードのノードＩＤをスレーブ処理部２８に通知する。リース期限内のマスタノード情報が履歴情報格納部２３内に存在しない場合、履歴情報管理部２４は、マスタノードの選出をマスタ決定部２５に指示する。なお、全てのノード２０の履歴情報管理部２４には、分散処理システム１０内のノード２０の数が管理者等によって予め設定されている。
【００６２】
また、他のノード２０から履歴情報を要求するメッセージを受信した場合、履歴情報管理部２４は、履歴情報格納部２３内の履歴を返す。また、履歴情報管理部２４は、コンソール１１からマスタノードのアドレスを要求された場合に、履歴情報格納部２３およびリソース情報格納部２７を参照して、自ノード２０がマスタノードならば、自ノード２０のアドレスをコンソール１１へ送信する。また、履歴情報管理部２４は、自ノード２０がマスタの場合に、処理定義をコンソール１１から受信したならば、受信した処理定義を履歴情報格納部２３に格納すると共に、新たに登録された処理定義を、ＰＡＸＯＳプロトコルを用いて他のノード２０と共有する。これにより、マスタノードに障害が発生した場合であっても、次にマスタとなったノード２０が、共有した処理定義を用いて処理を実行することができる。
【００６３】
処理割当部２６は、マスタ決定部２５から処理の割当を指示された場合に、履歴情報格納部２３内に格納されている処理定義およびリソース情報格納部２７内のリソース情報管理テーブル２７０に基づいて、マスタとなった自ノード２０以外の各ノード２０に割り当てる処理を決定する。割当方法の詳細については後述する。処理割当部２６は、割り当てた処理を示すノード別処理指示を例えばユニキャストにより計算機用ＬＡＮ１２を介して、自ノード２０以外のそれぞれのノード２０へ送信する。
【００６４】
スレーブ処理部２８は、計算機用ＬＡＮ１２を介して他のノード２０からノード別処理指示を受信した場合に、受信したノード別処理指示に従って、センシングアプリケーション実行部２９内のそれぞれのブロックを稼動させる。また、スレーブ処理部２８は、履歴情報管理部２４またはマスタ決定部２５から通知されたマスタノードのノードＩＤに基づいてリソース情報格納部２７内のリソース情報管理テーブル２７０を参照し、マスタノードのリソース情報が格納されているか否かを監視し、マスタノードのリソース情報がリソース情報管理テーブル２７０から削除された場合に、マスタノードに障害が発生したと判定してマスタ決定部２５にマスタノードの選出を指示する。
【００６５】
ここで、リソース情報登録部２２は、受信時刻から所定時間（例えば４０秒）経過したエントリをリソース情報管理テーブル２７０から削除するため、マスタノードが正常に稼動しており、マスタノード内のリソース情報送信部２１がリソース情報を所定時間（例えば３０秒）毎に正常に送信していれば、リソース情報管理テーブル２７０内にはマスタノードのリソース情報が存在し続けることになる。マスタノードのリソース情報がリソース情報管理テーブル２７０から削除されたことを検出することによって、スレーブ処理部２８は、マスタノードに障害が発生したことを検出することができる。
【００６６】
次に、ノード２０全体の動作について、フローチャートを用いて詳細に説明する。図１１は、第１の実施形態におけるノード２０の動作の一例を示すフローチャートである。例えば電源が投入される等の所定のタイミングで、ノード２０は、本フローチャートに示す動作を開始する。
【００６７】
まず、リソース情報送信部２１は、自ノード２０のノードＩＤ、自ノード２０のアドレス、自ノード２０のリソース情報、および自ノード２０の製造年月日をリソース情報格納部２７内のリソース情報管理テーブル２７０から読み出して、計算機用ＬＡＮ１２を介して他のノード２０へ例えばブロードキャストにより送信する（Ｓ３００）。そして、履歴情報管理部２４は、リソース情報格納部２７内のリソース情報管理テーブル２７０を参照して、所定数以上のノード２０に関するリソース情報がリソース情報管理テーブル２７０内に格納されたか否かを判定する（Ｓ３０１）。なお、リソース情報登録部２２は、他のノード２０からリソース情報等を受信する都度、受信したリソース情報等をリソース情報格納部２７内のリソース情報管理テーブル２７０に新規登録または上書登録する。
【００６８】
所定数以上のノード２０に関するリソース情報がリソース情報管理テーブル２７０内に格納された場合（Ｓ３０１：Ｙｅｓ）、履歴情報管理部２４は、他のノード２０へ履歴情報を要求するメッセージを、例えばブロードキャストにより計算機用ＬＡＮ１２を介して送信し、他のノード２０から送信された履歴情報を受信して履歴情報格納部２３に格納する（Ｓ３０２）。そして、履歴情報管理部２４は、履歴情報格納部２３を参照し、リース期限内のマスタノード情報が存在するか否かを判定する（Ｓ３０３）。
【００６９】
リース期限内のマスタノード情報が履歴情報格納部２３内に存在する場合（Ｓ３０３：Ｙｅｓ）、履歴情報管理部２４は、マスタノードのノードＩＤをスレーブ処理部２８に通知する。スレーブ処理部２８は、マスタノードから自ノード２０に割り当てられた処理が記述されたノード別処理指示を受信したか否かを判定する（Ｓ３０４）。自ノード２０のノード別処理指示をマスタノードから受信していない場合（Ｓ３０４：Ｎｏ）、スレーブ処理部２８は、ノード別処理指示を受信するまでステップＳ３０４に示した処理を実行する。
【００７０】
自ノード２０のノード別処理指示をマスタノードから受信した場合（Ｓ３０４：Ｙｅｓ）、スレーブ処理部２８は、受信したノード別処理指示に従って、センシングアプリケーション実行部２９内のそれぞれのブロックを稼動させる（Ｓ３０５）。そして、スレーブ処理部２８は、マスタノードのノードＩＤに基づいてリソース情報格納部２７内のリソース情報管理テーブル２７０を参照し、マスタノードのリソース情報が格納されているか否かを監視することにより、マスタノードが正常に稼動しているか否かを判定する（Ｓ３０６）。マスタノードが正常に稼動していない場合（Ｓ３０６：Ｎｏ）、スレーブ処理部２８は、マスタ決定部２５にマスタノードの決定を指示し、マスタ決定部２５は、後述するステップＳ３０７の処理を実行する。
【００７１】
ステップＳ３０３において、リース期限内のマスタノード情報が履歴情報格納部２３内に存在しない場合（Ｓ３０３：Ｎｏ）、履歴情報管理部２４は、マスタノードの選出をマスタ決定部２５に指示する。マスタ決定部２５は、例えばＰＡＸＯＳプロトコルを用い、図１０で説明した手順に従って、他のノード２０との間でマスタノードを決定する（Ｓ３０７）。そして、マスタ決定部２５は、自ノード２０がマスタとなったか否かを判定する（Ｓ３０８）。自ノード２０がマスタではない場合（Ｓ３０８：Ｎｏ）、マスタ決定部２５は、マスタノードのノードＩＤをスレーブ処理部２８に通知し、スレーブ処理部２８は、ステップＳ３０４に示した処理を実行する。一方、自ノード２０がマスタである場合（Ｓ３０８：Ｙｅｓ）、処理割当部２６は、履歴情報格納部２３内に処理定義が存在するか否かを判定する（Ｓ３０９）。履歴情報格納部２３内に処理定義が存在しない場合（Ｓ３０９：Ｎｏ）、処理割当部２６は、履歴情報格納部２３内に処理定義が格納されるまでステップＳ３０９を繰り返す。
【００７２】
履歴情報格納部２３内に処理定義が存在する場合（Ｓ３０９：Ｙｅｓ）、処理割当部２６は、後述する処理の割当を実行する（Ｓ４００）。そして、処理割当部２６は、自ノード２０以外の各ノード２０に割り当てた処理が記載されたノード別処理指示を、各ノード２０へ送信する（Ｓ３１０）。そして、処理割当部２６は、処理を割り当てたそれぞれのノード２０のリソース情報がリソース情報格納部２７内のリソース情報管理テーブル２７０に格納されているか否かを監視することにより、処理を割り当てたそれぞれのノード２０が正常に稼動しているか否かを判定する（Ｓ３１１）。
【００７３】
処理を割り当てたそれぞれのノード２０が正常に稼動している場合（Ｓ３１１：Ｙｅｓ）、履歴情報管理部２４は、計算機用ＬＡＮ１２を介してコンソール１１から新たな処理定義を受信したか否かを判定する（Ｓ３１２）。処理を割り当てたいずれかのノード２０が正常に稼動していない場合（Ｓ３１１：Ｎｏ）、または、コンソール１１から新たな処理定義を受信した場合（Ｓ３１２：Ｙｅｓ）、処理割当部２６は、再びステップＳ４００に示す処理を実行する。
【００７４】
一方、履歴情報管理部２４がコンソール１１から新たな処理定義を受信していない場合（Ｓ３１２：Ｎｏ）、マスタ決定部２５は、１２を介してコンソール１１からマスタノードの再選出を指示されたか否かを判定する（Ｓ３１３）。マスタノードの再選出を指示された場合（Ｓ３１３：Ｙｅｓ）、マスタ決定部２５は、再びステップＳ３０７に示した処理を実行する。一方、マスタノードの再選出を指示されなかった場合（Ｓ３１３：Ｎｏ）、処理割当部２６は、再びステップＳ３１１に示した処理を実行する。
【００７５】
図１２は、処理の割当（Ｓ４００）の処理の一例を示すフローチャートである。本フローチャートの説明に先立って、履歴情報格納部２３には、図７に例示した処理定義テンプレート、および、図８および図９に例示した処理定義本体が格納されているものと仮定する。また、リソース情報格納部２７内のリソース情報管理テーブル２７０には、図５に示した内容のデータが格納されているものと仮定する。
【００７６】
ここで、処理定義のデータ構造について説明する。処理定義は、処理定義テンプレートと処理定義本体とを有する。処理定義本体（図８および図９参照）は、複数のProcessセクションから構成され、ProcessセクションはSubProcessセクションを含む場合がある。ProcessセクションとSubProcessセクションは各ノード２０が実行する処理を表しており、「Process」および「SubProcess」の第一引数に各処理を実行するプログラムに対応したクラス名が記載される。簡潔に説明するため、以下ではProcessセクションおよびSubProcessセクションによって定義された処理のことを、単にProcessまたはSubProsessと呼ぶ。各処理の実行に必要なパラメタはセクション内の「Param」属性として記述される。Param属性の第一引数がパラメタ名、第二引数がパラメタ値である。
【００７７】
処理定義本体に記載された処理のインスタンス構成は、処理割当部２６によって決定される。１つのProcessやSubProcessのインスタンスは必ずしも１個ではなく、複数のノードが同一の処理を並列に実行する場合がある。一方、処理定義本体に記載された処理が２個以上存在してはならないことを、明示的に指定したい場合がある。例えば、処理定義本体（図９参照）の44行目〜47行目には、指定したアドレス（192.168.10.101）でアクセスされるRFIDデバイスを制御する処理が記載されているが、このRFIDデバイスは１つしか存在しないため、この処理のインスタンスは１個にする必要がある。このような場合、SubProcessセクションの第二引数にインスタンス名が指定される。インスタンス名が指定されたSubProcessセクションのインスタンスは、そのインスタンス名に対応するものだけになるため、インスタンスの個数は１個となる。
【００７８】
処理定義テンプレート（図７参照）は、処理定義本体と同様の構成をとる。処理定義テンプレートに記載された「ProcesUnit」、「Require」、および「SourceRef」が処理定義本体に記載されていない場合、処理定義テンプレートに記載されたものが処理定義本体に記載されたものとして扱われる。それ以外の項目（「Process」、「SubProcess」、または「Param」等）は、パターンマッチング条件として利用される。
【００７９】
例えば、処理定義テンプレート（図７参照）の21行目〜35行目には、処理定義本体（図９参照）の43行目〜84行目に対する値が記載されている。処理定義テンプレートの21行目に記載された「Process "sensor"」がパターンマッチング条件として利用され、処理定義本体の43行目に記載された「Process "sensor"」セクションにマッチする。そして、処理定義テンプレートの22行目に記載された「ProcessUnit "subprocess"」が処理定義本体の43行目以下のProcessセクション内に挿入される。
【００８０】
処理定義テンプレートの23行目以下に記載された部分のパターンマッチングは、上記と比較してやや複雑になる。例えば、処理定義テンプレートの23行目〜26行目に記載された部分は、23行目に記載された「SubProcess "sensor"」と25行目に記載された「Param "type" "rfid"」とがパターンマッチング条件として利用され、処理定義本体（図９参照）の44行目から59行目に記載された４つのSubProcessセクションにマッチする。そして、処理定義テンプレートの24行目に記載された「Require "cpu" "20" "mips-per-sensor-event」が、対応するSubProcessセクションに挿入される。
【００８１】
本実施形態において、処理定義本体は、「dispatch」、「filters」、「cycle」、および「sensors」の４つのProcessセクションから構成される。これらは図４に示したセンシングアプリケーション実行部２９が有するディスパッチャ２９０、フィルタ２９１、駆動制御２９２、およびアダプタ２９３にそれぞれ対応する。処理定義本体の１行目〜４行目に記載された、クラス名が「dispatch」であるProcessセクションは、ディスパッチャ２９０の処理を示しており、送信先（dest）とコンテンツのエンコード方式（content-coding）とがパラメタとして指定されている。
【００８２】
処理定義本体（図８参照）の６行目〜21行目に記載されたクラス名が「filters」である２つのProcessセクションは、フィルタ２９１の処理を示している。具体的な処理内容は、SubProcessセクションに定義される。処理定義本体の９行目〜11行目に記載されたSubProcessセクションは、RFIDタグのデータ処理で利用する差分フィルタであり、クラス名が「inout-filter」となっている。差分フィルタとは、連続的に入力されるデータの差分を出力するフィルタ処理である。例えば、新しくRFIDタグを検出すると、INのイベントを出力し、いままで存在したRFIDタグが見つからなくなると、OUTのイベントを出力する。この例では、パラメタとして出力データ（output）が「in」として記載されているので、OUTのイベントは出力されずに、INのイベントのみが出力されることになる。処理定義本体の17行目〜20行目に記載されたSubProcessセクションは、統計処理を行うフィルタである。パラメタとして出力データ（output）が指定されており、ここでは平均（average）と分散（variance）とが出力される。
【００８３】
処理定義本体の23行目〜41行目に記載されたクラス名が「cycle」であるProcessセクションは、駆動制御２９２の処理を示しており、独立に動作するセンサ制御サイクルがSubProcessセクションとして定義されている。この例では３つのセンサ制御サイクルが定義されている。各SubProcessセクション内では、駆動周期（period）と駆動するセンサ（sensor-ref）とがパラメタとして指定されている。パラメタsensor-refには、クラス名が「sensor」であるSubProcessのインスタンス名が指定される。後述するように、クラス名が「sensor」であるSubProcessはセンサに一対一に対応する。従って、パラメタsensor-refをこのように指定することは、センサを個別に指定することと等価である。処理定義本体の26〜27行目のようにsensor-refが複数記載された場合、それぞれの「sensor-ref」に記載されたセンサが並列的に駆動することが示される。従ってこの例では、センサ「ａ」および「ｂ」をこの順で駆動し、それと並列にセンサ「ｃ」および「ｄ」をこの順で駆動することになる。
【００８４】
処理定義本体（図９参照）の43行目〜84行目に記載されたクラス名が「sensors」であるProcessセクションは、アダプタ２９３の処理を示しており、各センサ１４の制御処理がSubProcessセクションとして定義される。各SubProcessには、センサ１４の種別（type）とセンサ１４のアドレス（addr）またはデバイス識別子（devId）とがパラメタとして指定される。この例では、ネットワーク接続されるタイプのセンサ１４はアドレスで指定され、シリアルインターフェイス経由でノード２０と直接接続されるものはデバイス識別子で指定されている。デバイス識別子で指定されたセンサ１４のデバイス識別子と、そのセンサ１４にアクセスするためのシリアルポート名は、リソース情報管理テーブル２７０（図５参照）のリソース情報２７４に記載されている。このようなセンサ１４にアクセスする場合、アダプタ２９３は、デバイス識別子をキーとしてリソース情報２７４を検索し、シリアルポート名を取得し、そのシリアルポートを使用する。
【００８５】
各処理の連携方法は、SourceRef属性で指定される。SourceRef属性の属性値は、そのSourceRef属性が記載されたProcessやSubProcessへの入力データを生成する他の処理（ProcessまたはSubProcess）を示す。SouceRef属性の第一引数には、Processセクションのクラス名が指定され、第二引数にはSubProcessセクションのクラス名が指定され、第三引数には処理のインスタンス名が指定される。例えば、処理定義本体（図８参照）の１行目〜４行目のProcessセクションには、SourceRef属性として「SourceRef "filters"」が指定されている。これはクラス名が「filters」であるProcessの出力結果が、クラス名が「dispatch」であるProcessの入力データとして使用されることを示している。
【００８６】
処理定義本体の16行目は、SourceRef属性の第三引数まで指定されている例である。これは、クラス名が「filters」であるProcessの入力データとして、Processのクラス名が「cycle」であり、SubProcessのクラス名が「sensor-group」であり、インスタンス名が「area2」および「area3」であるSubProcessの処理結果を使用することが示されている。このように、入力データを生成する処理が複数存在する場合、１つの引数内に複数の項目名がカンマ区切りで指定される。
【００８７】
図７の処理定義テンプレートにおいて、クラス名が「cycle」のProcessセクション内にクラス名が「sensor-group」であるSubProcessセクションが記載されているが、このSubProcessセクションのSourceRef属性は、「SourceRef "sensors" "sensor" "param:sensor-ref"」となっている。この第三引数は、そのセクション内に指定されたパラメタsensor-refのパラメタ値に置き換えられることを意味する。例えば、処理定義本体の24行目〜28行目を例に挙げると、sensor-refパラメタは２つ存在し、それぞれパラメタ値が、「a,b」「c,d」であるので、SourceRef属性の第三引数として「a,b,c,d」が指定されたことになる。結局、上記SubProcessは、Procss "sensors"セクション内のSubProcess "sensor"のインスタンス名が「a」、「b」、「c」、または「d」である４つのインスタンスの処理結果が入力データとして使用されることを意味する。
【００８８】
処理定義本体に記載した処理は複数のノード２０上で実行されるため、各処理のインスタンスを各ノード２０に割り当てる際、インスタンスの最小単位（以下、処理単位と呼ぶ）を決める必要がある。処理単位は、それ以上インスタンスを分解できない最小単位を意味し、１つの処理単位は必ず１つのノード上で実行される。また、ある処理が複数の処理単位から構成される場合は、各処理単位を異なるノードが実行することができる。処理単位を決める方法としては、例えば、（１）インスタンス名が指定された各SubProcessセクションを１つの処理単位として構成する方法、（２）その処理が使用するリソースに対応付けて処理単位を構成する方法、（３）その処理の入力データを生成する処理の処理単位に対応付けて処理単位を構成する方法等がある。
【００８９】
各Processセクションに記載された処理の処理単位が、上記のどの方法で決定されるのかは、ProcessセクションのProcessUnit属性に記述される。Process "cycle"セクション、および、Process "sensors"セクションに対する指定「ProcessUnit "subprocess"」が、上記（１）の指定の例である。ProcessUnit属性の第一引数（subprocess）が（１）の指定方法であることを意味する。本実施形態では、インスタンス名が指定されたSubProcessを必ず処理単位とすることにしているため、インスタンス名が指定されたSubProcessを含むProcessセクションのProcessUnit属性は必ず"subprocess"となる。
【００９０】
Process "dispatch"セクションに対する指定「ProcessUnit "device" "communicate"」が、上記（２）の指定の例である。ProcessUnit属性の第一引数（device）が（２）の指定方法であることを示しており、第二引数がデバイス種別を示している。この例で第二引数として記載された「communicate」は、通信デバイスを意味する。図５に示したリソース情報管理テーブル２７０には、ノードＩＤが「001」または「002」のノード２０に通信デバイスが設けられている旨が記載示されている。従って、Process "dispatch"セクションに記載された処理は、上記２つのノード２０のそれぞれで実行される２つの処理単位から構成される。
【００９１】
Process "filter"セクションに対する指定「ProcessUnit "source-subprocess"」が、上記（３）の指定の例である。ProcessUnit属性の第一引数（source-subprocess）が（３）の指定方法であることを示す。例えば、処理定義本体の14行目〜21行目に指定されたProcess "filter"セクションは、SourceRef属性に記載されているように、インスタンス名が「area2」および「area3」のSubProcessが出力するデータを入力データとして使用する。インスタンス名が指定されたSubProcessは処理単位であるから、入力データを生成する処理の処理単位は２個である。つまり、インスタンス名が「area2」であるSubProcessの出力データを入力データとして使用するフィルタ処理と、インスタンス名が「area3」であるSubProcessの出力データを入力データとして使用するフィルタ処理が、それぞれ処理単位となる。
【００９２】
上記（３）の方法で指定された場合、SourceRef属性が参照する処理の処理単位が明示的に分からない場合がある。例えば、SourceRef属性に第一引数（Process）のみ記載されている場合や、SourceRef属性が参照するSubProcessセクションにインスタンス名が記載されていない場合である。このような場合は、SourceRef属性が参照する処理のSourceRef属性をさらにたどることで、処理単位を確定する。SourceRef属性をたどると最終的には、Process "sensors"セクションで定義されるセンサ制御処理にたどり着く。センサ制御処理は、必ず各々のセンサに対応付けられるため、必然的に処理単位となる。従って、SourceRef属性をたどることで、必ず処理単位を確定することができる。
【００９３】
各処理の処理単位を実行するために必要なリソース量はRequire属性に記載される。Require属性の第一引数にはリソース種別が指定され、第二引数にはリソース量が指定され、第三引数には第二引数で指定されたリソース量の単位が指定される。本実施形態では、リソース種別として「communicate」および「cpu」の２種類が例示されている。
【００９４】
「communicate」は通信リソースを意味するリソース種別である。例えば、図７の処理定義テンプレートの３行目に「Require "communicate" "8k" "bps-per-sensor-event"」と記載されている。第三引数は「sensor-event」当たりに必要な通信帯域のbps（Bits Per Second）値を示す。sensor-eventとは、１つのセンサ１４が出力する１個のデータを意味し、event/secで表すこともできる。処理するデータ量は、センサ１４の個数とセンサ１４の駆動周期の逆数とに比例するため、sensor-eventという単位を使用している。結局上記は、「１個のセンサから毎秒一回取得したデータを処理する場合、8kbpsの通信リソースが必要」という意味になる。
【００９５】
「cpu」はＣＰＵリソースを意味するリソース種別である。例えば、図７の４行目に「Require "cpu" "10" "mips-per-sensor-event"」と記載されている。第三引数は「sensor-event」当たりに必要な処理能力のmips（Million Instructions Per Second）値を示す。sensor-eventは上記と同様の意味であるため、上記は「１個のセンサから毎秒一回取得したデータを処理する場合、10mipsのＣＰＵリソースが必要」という意味になる。
【００９６】
図１２に戻って、処理の割当（Ｓ４００）の処理の説明を続ける。まず、処理割当部２６は、図７に示した処理定義テンプレートと、図８および図９に示した処理定義本体とから、図１３に示す処理割当テーブル３０を作成する（Ｓ４０１）。処理割当テーブル３０には、それぞれの処理単位を識別する処理ＩＤ３１毎に、対応する処理単位の名称を示す処理単位名称３２、対応する処理単位が使用するデータの提供元の処理単位の処理ＩＤを示すデータソース３３、対応する処理単位の単位時間当たりの実行回数を示すevent/sec３４、対応する処理単位が使用する機器であって、ノード２０のセンサインターフェイス２０８に接続されている機器のＩＤを示すdevice３５、対応する処理単位に必要な処理能力を示すmips３６、および、対応する処理単位が割り当てられるノード２０のＩＤを示すnode３７が格納される。
【００９７】
処理割当部２６は、各ProcessセクションのProcessUnit属性を参照し、ProcessUnit属性の第一引数が（１）「subprocess」、（２）「device」、または（３）「source-subprocess」であるものの順に処理単位を決定していく。ProcessUnit属性の第一引数が（１）「subprocess」の場合、処理割当部２６は、SubProcessセクションをそのまま処理単位とする。処理単位の名称を、[Processのクラス名]/[SubProcessのクラス名]@[SubProcessのインスタンス名]とする。ProcessUnit属性の第一引数が（２）「device」の場合、処理割当部２６は、処理定義の他にリソース情報格納部２７内のリソース情報管理テーブル２７０を参照する必要があるため、ここではその処理を後回しにする。
【００９８】
ProcessUnit属性の第一引数が（３）「source-subprocess」の場合、処理割当部２６は、処理単位を決定しようとしているProcessもしくはSubProcessセクションのSourceRef属性を参照し、その処理の入力データを作成するSubProcessの処理単位を取得する。以下では、ある処理（ProcessまたはSubProcess）の入力データを生成する処理（ProcessまたはSubProcess）をデータソースと呼ぶ。データソースの処理単位が取得できたら、その処理単位に一対一に対応した処理単位を作成する。例えば、処理定義本体（図８）の14行目〜21行目に記載されたProcess "filters"セクションのSourceRef属性は「SourceRef "cycle" "sensor-group" "area2, area3"」となっており、SourceRef属性が参照する処理のインスタンス名まで記載されている。インスタンス名が記載された処理は処理単位となることから、データソースの処理単位は（Processのクラス名、SubProcessのクラス名、SubProcessのインスタンス名）=（cycle, sensor-group, area2）、（cycle, sensor-group, area3）で決定される２つの処理単位となる。処理割当部２６は、これら２つの処理単位に対応した処理単位を、Process "filters"セクションの処理単位として作成することになるが、処理単位の名称は、[Processのクラス名]/[データソースのSubProcessのクラス名]@[ データソースのSubProcessのインスタンス名]とする。従って、filters/sensor-group@area2、filters/sensor-group@area3が処理単位の名称となる。
【００９９】
上記手順で（２）の場合以外の処理単位を決定すると、処理割当部２６は、処理割当テーブル３０の処理単位名称３２に処理単位の名称を登録し、各処理単位を一意に識別可能な番号を生成して処理ＩＤ３１に登録する。次に、処理割当部２６は、ProcessUnit属性が「device」以外の処理単位について、使用するデバイスのデバイス識別子を処理定義から取得する。例えば、処理定義本体（図９参照）の54行目または58行目には、（クラス名、インスタンス名）=（sensor、c）（sensor、d）を持つ処理単位について、デバイス識別子がパラメタ「devId」として記載されている。処理割当部２６は、「devId」に対応する機器のＩＤを処理割当テーブル３０のdevice３５に登録する。
【０１００】
次に処理割当部２６は、処理定義に記載されたSource-Ref属性に基づき、各処理単位が使用するデータの提供元となる処理単位の処理ＩＤを、各処理単位に対応するデータソース３３に登録することで、処理単位間の連携関係を処理割当テーブル３０に登録する。ここでは、処理割当部２６は、Source-Ref属性にSubProcessのインスタンス名まで指定された場合についてのみデータソース３３に登録する。
【０１０１】
また、処理定義のProcessUnit属性がsource-subprocessである処理単位は、他の処理単位からデータを提供されているため、処理割当部２６は、当該処理単位について、データの提供元の処理単位の処理ＩＤをデータソース３３に登録する。具体的には、処理単位名称３２が「filter/sensor-group@area1」、「filter/sensor-group@area2」、または「filter/sensor-group@area3」の処理単位は、それぞれ処理単位名称３２が「cycle/sensor-group@area1」、「cycle/sensor-group@area2」、または「cycle/sensor-group@area3」の処理単位が生成するデータを入力データとして処理するので、処理割当部２６は処理割当テーブル３０においてこれらを対応付ける。その結果、図１３に示すように処理ＩＤ３１が「１」、「２」、および「３」の処理単位のデータソース３３は、それぞれ、「４」、「５」、および「６」となる。
【０１０２】
処理定義本体（図８参照）の23行目〜41行目については、SubProcessとそのSubProcessのデータソースの両方がインスタンス名まで記載されているため、SubProcessとデータソースの処理単位の関係は明白である。従って、処理割当部２６は、Source-Ref属性に記載内容に従って、データソースとの対応関係を処理割当テーブル３０に記載する。結果、図１３に示すように、処理ＩＤ３１が、「４」、「５」、および「６」の処理単位のデータソース３３は、それぞれ、「７，８，９，１０」、「１１，１２，１３」、および「１４，１５，１６」となる。
【０１０３】
次に、処理割当部２６は、処理定義本体（図８参照）のProcess "cycle"セクションの記載内容から、Process "sensors"セクションに定義されたセンサ制御処理の駆動間隔を求め、センサ制御処理の各処理単位に対してevent/sec３４の値を求める。このevent/sec３４の値を足し合わせることで、センサ制御処理が生成するデータを入力データとして使用する各種処理単位のevent/sec３４を求めていく。
【０１０４】
すなわち、処理割当部２６は、処理定義本体のProcess "cycle"セクションを参照し、SubProcess "sensor-group"セクション内の「period」パラメタから、センサ制御処理の駆動周期を取得する。例えば、処理定義本体（図８参照）の24行目〜28行目に記載されたSubProcessセクションでは、「a」、「b」、「c」、および「d」のインスタンス名を持つセンサ制御処理が1000ミリ秒周期で駆動している。従って、当該センサ制御処理の処理単位のevent/sec３４の値は「１」となる。同様に、処理定義本体の29行目〜34行目に記載されたSubProcessセクションから、「e」、「f」、および「g」のインスタンス名を持つセンサ制御処理の駆動周期が2000ミリ秒であることが分かり、これらセンサ制御処理の処理単位のevent/sec３４は「０．５」となる。このようにして、処理割当部２６は、各センサ制御処理の処理単位に対してevent/sec３４を求める。これにより、処理ＩＤ３１が「7」〜「16」の処理単位のevent/sec３４は、図１３のようになる。
【０１０５】
次に、処理割当部２６は、既にevent/sec３４の値を求めた処理単位の処理ＩＤ３１が、データソース３３に記載されている処理単位を探す。すなわち、処理割当部２６は、処理ＩＤ３１が「４」、「５」、および「６」の処理単位を見つける。そして、処理割当部２６が見つけたそれぞれの処理単位のevent/sec３４は、データソース３３に記載されている処理ＩＤ３１に対応する処理単位のevent/sec３４を合計したものになる。例えば、処理ＩＤ３１が「４」の処理単位のデータソース３３には、「７，８，９，１０」が記載されており、処理ＩＤ３１が「７」、「８」、「９」、または「１０」の処理単位のevent/sec３４の値は、それぞれ「１」となっている。従って、処理割当部２６は、処理ＩＤ３１が「４」の処理単位のevent/sec３４の値を、これらの合計である「４」と算出する。同様にして、処理割当部２６は、処理ＩＤ３１が「５」または「６」の処理単位についてもevent/sec３４を算出する。
【０１０６】
続いて処理割当部２６は、データソース３３に処理ＩＤが設定されている他の処理単位のそれぞれについても上記の手順を繰り返してevent/sec３４を求める。例えば、処理ＩＤ３１が「１」、「２」、または「３」の処理単位についてのevent/sec３４は、図１３に示す値となる。これにより、処理ＩＤ３１が「１」〜「１６」のそれぞれの処理単位についてevent/sec３４が設定された。
【０１０７】
次に処理割当部２６は、処理定義に記載された必要な処理能力に関するRequire属性と、各処理単位が処理するデータ量に基づき、各処理単位に必要な処理能力を算出する。処理定義には、Require属性として「mips-per-sensor-event」単位でのmips値が記載されており、この値と処理割当テーブル３０内の各処理単位のevent/sec３４を積算したものが、各処理単位に必要な処理能力となる。
【０１０８】
図１３の処理割当テーブル３０を参照すると、例えば、処理ＩＤ３１が「１」の処理単位のevent/sec３４は「４」である。この処理単位はProcess "filters"セクションとして定義されており、この処理単位に必要な処理能力に関するRequire属性は、処理定義本体（図８参照）の７行目に「Require "cpu" "10" "mips-per-sensor-event"」と記載されている。従って、処理割当部２６は、４×１０＝４０mipsを必要な処理能力として算出する。処理割当部２６は、算出した必要な処理能力を、対応する処理単位のmips３６の欄に登録する。処理割当部２６は、処理ＩＤ３１が「２」〜「１６」の処理単位についても同様にmips値をそれぞれ求めてmips３６に登録する。この時点で処理割当テーブル３０のmips３６に欄は、図１３の状態となる。
【０１０９】
図１２に戻って説明を続ける。次に、処理割当部２６は、処理定義およびリソース情報管理テーブル２７０を参照して、ノード２０に接続されている機器毎に作成されるべき処理単位を作成する（Ｓ４０２）。より詳しく説明すると、処理割当部２６は、処理定義テンプレートおよびリソース情報管理テーブル２７０のリソース情報２７４を参照し、ProcessUnit属性の第二引数に指定されたリソースを検索する。例えば、Process "dispatch"セクションのProcessUnit属性は、「ProcessUnit "device" "communicate"」であるので、処理割当部２６は、当該セクションに対して"communicate"リソースをリソース情報管理テーブル２７０内で検索する。図５に示したリソース情報管理テーブル２７０には、デバイス識別子（devID）が「card001」の通信カードと「card002」の通信カードが見つかるので、処理割当部２６は、それぞれに対応した処理単位を作成する。
【０１１０】
今の場合、SubProcessが存在しないので、処理割当部２６は、処理単位の名称を[Processのクラス名]@[デバイス識別子]とする。一方、SubProcessが存在する場合、処理割当部２６は、処理単位の名称を[Processのクラス名]/[SubProcessのクラス名]@[デバイス識別子]とする。なお、複数のノード２０を跨ると、デバイス識別子の重複が発生する場合があるので、処理割当部２６は、デバイス識別子の代わりにノードＩＤとデバイス識別子の組み合わせを使用してもよい。本実施形態では、説明を簡潔にするためデバイス識別子のみでデバイスを識別できるものと仮定する。そして、処理割当部２６は、作成した処理単位に対応する処理定義を参照して、当該処理単位が使用する機器であって、ノード２０に接続されたものがあれば、処理割当テーブル３０のdevice３５に登録する。ステップＳ４０２の処理が実行された後の処理割当テーブル３０は、例えば図１４のようになる。領域３００は、ステップＳ４０２の処理が実行されたことによって新たに登録されたデータを示している。
【０１１１】
次に、処理割当部２６は、新たに作成された処理単位（処理ＩＤ３１が「17」または「18」の処理単位）について、当該処理単位が使用するデータの提供元を割り当てる処理を実行する（Ｓ５００）。ここで、データ提供元の割当処理（Ｓ５００）の動作について図１５を用いて説明する。図１５は、データ提供元の割当処理（Ｓ５００）の一例を示すフローチャートである。本フローチャートでは、処理割当テーブル３０が図１４に示した状態にあることを前提として説明を行う。
【０１１２】
まず、処理割当部２６は、ステップＳ４０２において新たに作成された処理単位にデータを提供する処理単位の中で、新たに作成された処理単位のデータ提供元としてデータソース３３に登録されておらず、かつ、単位時間当たりの実行回数が最も多い処理単位を１つ選択する（Ｓ５０１）。図１４の処理割当テーブル３０の例では、処理割当部２６は、クラス名「filters」を持つ処理単位の中で、処理ＩＤ３１が「１」の処理を選択する。
【０１１３】
次に、処理割当部２６は、ステップＳ４０２において新たに作成されたそれぞれの処理単位について、現在割り当てられているリソースによって必要となる処理能力を算出し、算出した値を対応するevent/sec３４の欄に登録する（Ｓ５０２）。図１４の処理割当テーブル３０の例では、処理ＩＤ３１が「17」または「18」の処理単位のデータソース３３には、データが登録されていないため、当該処理単位が、他の処理単位から入力されたデータを処理するために必要な処理能力は、現時点ではいずれも「０」である。また、例えば、処理ＩＤ３１が「18」の処理単位のデータソース３３に「２」と「３」が登録されていた場合、処理割当部２６は、処理ＩＤ３１が「２」の処理単位のevent/sec３４に登録されている「1.5」と、処理ＩＤ３１が「３」の処理単位のevent/sec３４に登録されている「1.5」とを合計した処理能力を、他の処理単位から入力されたデータを処理するために必要な処理能力として算出する。
【０１１４】
次に、処理割当部２６は、ステップＳ４０２において新たに作成された処理単位の中で、必要な処理能力が最も低い処理単位に、ステップＳ５０１で選択した処理単位を割り当てる（Ｓ５０３）。図１４の処理割当テーブル３０の例では、処理ＩＤ３１が「17」または「18」の処理単位のいずれにも、現時点ではevent/sec３４に「０」が登録されている。この場合、処理割当部２６は、処理ＩＤ３１が「17」または「18」の処理単位のいずれのデータソース３３に「１」を登録してもよいが、本実施形態では、処理ＩＤ３１が小さい処理単位の３３に登録することとする。
【０１１５】
なお、ステップＳ５０３において、処理割当部２６は、ステップＳ４０２において新たに作成された処理単位の中で、必要な処理能力が最も低い処理単位に、ステップＳ５０１で選択した処理単位を割り当てるが、この場合、必要な処理能力が最も低い処理単位のdevice３５に登録されている機器のＩＤに基づいてリソース情報管理テーブル２７０を参照し、当該機器の処理能力を取得して、ステップＳ５０１で選択した処理単位を割り当てた場合に、当該処理能力を超えるならば、必要な処理能力が次に低い処理単位にステップＳ５０１で選択した処理単位を割り当てるようにする。
【０１１６】
次に、処理割当部２６は、ステップＳ４０２において新たに作成した処理単位にデータを提供する処理単位の全てを割り当てたか否かを判定する（Ｓ５０４）。ステップＳ４０２において新たに作成した処理単位にデータを提供する処理単位の全てを割り当てていない場合（Ｓ５０４：Ｎｏ）、処理割当部２６は、再びステップＳ５０１に示した処理を実行する。一方、ステップＳ４０２において新たに作成した処理単位にデータを提供する処理単位の全てを割り当てた場合（Ｓ５０４：Ｙｅｓ）、処理割当部２６は、本フローチャートに示したデータ提供元の割当の処理を終了する。本フローチャートに示した処理が終了すると、処理割当テーブル３０には、図１６に示した領域３０１および領域３０２内のデータが登録される。
【０１１７】
なお、図１５に示した方法は、各通信リソースの通信負荷が平均化されるように、処理単位間の連携関係を求めるものであるが、別な方法として、１つの通信リソースに性能限界まで通信負荷を与える方法が考えられる。時間課金の通信カードが用いられる場合、通信量が少ないときには利用する通信カードの数を少なくして、通信料金を節約したい場合がある。このような場合に本方法が有効である。本方法による処理単位間の連携関係の決定手順を図１７に示す。図１５との違いは、ステップＳ５０５のみである。
【０１１８】
ステップＳ５０２の次に、処理割当部２６は、ステップＳ４０２において新たに作成された処理単位のdevice３５に登録されている機器のＩＤに基づいてリソース情報管理テーブル２７０を参照し、当該機器の処理能力を取得する。そして、処理割当部２６は、ステップＳ５０１で選択した処理単位を、リソースの処理能力を超えない範囲で、必要となる処理能力が最も大きい処理単位のデータ提供元として割り当てる（Ｓ５０５）。なお、処理割当部２６は、リソースの処理能力いっぱいまでデータ提供元の処理単位を割り当てる他に、リソースの処理能力の所定割合（例えば７５％）に制限値を設け、ステップＳ５０１で選択した処理単位を、当該制限値を超えない範囲で、必要となる処理能力が最も大きい処理単位のデータ提供元として割り当てるようにしてもよい。
【０１１９】
図１２に戻って説明を続ける。処理割当部２６は、ステップＳ４０２で作成したそれぞれの処理単位について、必要な処理能力を算出する（Ｓ４０３）。ステップＳ４０３において、処理割当部２６は、処理定義に記載された必要な処理能力に関するRequire属性と、各処理単位が処理するデータ量に基づき、各処理単位に必要な処理能力を算出する。例えば、処理ＩＤ３１が「17」の処理単位のevent/sec３４は「４」であり、この処理単位はProcess "dispatch"セクションとして定義されており、この処理単位に必要な処理能力に関するRequire属性は、処理定義テンプレートの４行目に「Require "cpu" "10" "mips-per-sensor-event"」と記載されている。従って、処理割当部２６は、４×１０＝４０mipsを必要な処理能力として算出し、mips３６に登録する。処理割当部２６は、処理ＩＤ３１が「18」の処理単位についても同様にmips値を求めmips３６に登録する。これにより、処理割当テーブル３０には、図１５に示す領域３０３のデータが登録される。
【０１２０】
次に、処理割当部２６は、ノード２０に接続されている機器を利用する処理単位を、その機器が接続されているノード２０に割り当てる（Ｓ４０４）。処理割当部２６は、処理割当テーブル３０内でdevice３５にデータが登録されているそれぞれの処理単位について、リソース情報管理テーブル２７０を参照し、device３５と同一のデバイス識別子が記載されたリソース情報を探す。そして、処理割当部２６は、見つかったリソース情報に対応付けられているノードＩＤを、対応する処理単位のnode３７に登録する。
【０１２１】
例えば、処理ＩＤ３１が「17」の処理単位のdevice３５には「card001」が登録されているので、処理割当部２６は、リソース情報管理テーブル２７０にデバイス識別子「card001」が登録されているリソース情報を探し、ノードＩＤが「001」であるノード２０のリソース情報を検出する。そして、処理割当部２６は、処理割当テーブル３０の対応する処理単位のnode３７に「001」を登録する。処理割当部２６は、処理ＩＤ３１が「９」、「10」、または「18」の処理単位についても同様にしてnode３７を登録する。これにより、処理割当テーブル３０には、図１６に示す領域３０４および領域３０５のデータが登録される。
【０１２２】
次に、処理割当部２６は、処理単位を実行させるノード２０を決定する。各ノード２０への処理割り当てアルゴリズムの概要は以下のとおりである。
（１）要求性能が大きな処理に確実にＣＰＵリソースを割り当てるために、必要な処理能力（mips値）が大きな処理単位から順に割り当てる。
（２）ノード２０間の通信オーバヘッドを削減するため、データの送受信が関連している処理単位を、なるべく同一ノードに割り当てる。
（３）上記（１）のポリシーで割り当てを行うと、特定のノードに負荷が集中してしまう場合があるため、ＣＰＵ負荷に制限値（例えば75％）を設け、処理を割り当てたとすればＣＰＵ負荷が当該制限値以上となってしまう場合には、通信オーバヘッドが発生したとしても当該処理単位を他のノード２０に割り当てる。上の例ではＣＰＵ負荷の制限値を100%よりも小さな値にしているが、これはＣＰＵ負荷の変動にも対応可能とするためである。
【０１２３】
処理割当部２６は、まず、リソース情報管理テーブル２７０および処理割当テーブル３０を参照して、図１８に示す負荷テーブル４０を作成する。図１８に示す負荷テーブル４０には、ノードＩＤ４１に対応付けて、当該ノードＩＤ４１に対応するノード２０のＣＰＵ処理能力を示す許容値４２、および、当該ノードＩＤ４１に対応するノード２０に割り当てられている処理負荷を示す現在の負荷４３が格納される。処理割当部２６は、それぞれのノード２０について、リソース情報管理テーブル２７０を参照して許容値４２にデータを登録し、ステップＳ４０４においてノード２０に割り当てた処理単位の負荷の合計値を現在の負荷４３の欄に登録する（Ｓ４０５）。
【０１２４】
具体的には、処理割当部２６は、処理割当テーブル３０を参照して、処理ＩＤ３１が「17」の処理単位をノードＩＤが「001」のノード２０に割り当て、処理ＩＤ３１が「18」の処理単位をノードＩＤが「002」のノード２０に割り当て、処理ＩＤ３１が「９」または「10」の処理単位をノードＩＤが「003」のノード２０に割り当てる。従って、対応する処理単位のmips３６を加算すると、ノードＩＤが「001」のノード２０のＣＰＵ負荷は「40」、ノードＩＤが「002」のノード２０のＣＰＵ負荷は「30」、ノードＩＤが「003」のノード２０のＣＰＵ負荷は、２０＋２０＝４０と算出される。この時点で、負荷テーブル４０は、図１８に示す状態になる。
【０１２５】
次に、処理割当部２６は、処理割当テーブル３０を参照して、node３７にデータが登録されていない処理単位の中で、必要な処理能力が最大の処理単位を１つ選択する（Ｓ４０６）。図１６の状態では、node３７にデータが登録されていない処理単位の中で、mips３６に「75」が登録されている処理単位が２つ（処理ＩＤ３１が「２」または「３」の処理単位）存在する。必要な処理能力が最大の処理単位が複数存在する場合、処理割当部２６は、例えば処理ＩＤ３１が最も小さい処理単位（図１５の例では処理ＩＤ３１が「２」の処理単位）を選択する。
【０１２６】
次に、処理割当部２６は、選択した処理単位が使用するデータの提供元または提供先の処理単位の中で、ノード２０に既に割り当てられている処理単位が存在するか否かを判定する（Ｓ４０７）。例えば、図１６の処理割当テーブル３０では、処理ＩＤ３１が「２」の処理単位にデータを提供している処理単位は、処理ＩＤ３１が「５」の処理単位であり、処理ＩＤ３１が「２」の処理単位は、処理ＩＤ３１が「18」の処理単位にデータを提供している。処理ＩＤ３１が「５」または「18」の処理単位の中で、ノード２０に既に割り当てられているものは、図１６の処理割当テーブル３０では処理ＩＤが「18」の処理単位である。
【０１２７】
選択した処理単位が使用するデータの提供元または提供先の処理単位の中で、ノード２０に既に割り当てられている処理単位が存在しない場合（Ｓ４０７：Ｎｏ）、処理割当部２６は、ステップＳ４０９に示す処理を実行する。一方、選択した処理単位が使用するデータの提供元または提供先の処理単位の中で、ノード２０に既に割り当てられている処理単位が存在する場合（Ｓ４０７：Ｙｅｓ）、処理割当部２６は、その処理が割り当てられているノード２０の許容値および現在の負荷の値を負荷テーブル４０から取得し、ステップＳ４０６で選択した処理単位に必要な処理能力を処理割当テーブル３０から取得する。
【０１２８】
そして、処理割当部２６は、取得した現在の負荷の値と、ステップＳ４０６で選択した処理単位に必要な処理能力の値とを合計し、その合計値が、取得した許容値の所定割合（本実施形態では75％）以上か否かを判定する（Ｓ４０８）。合計値が許容値の所定割合未満である場合（Ｓ４０８：Ｎｏ）、処理割当部２６は、ステップＳ４０６で選択した処理単位に対応する処理割当テーブル３０のnode３７に、ステップＳ４０７のＹｅｓで検出したノード２０のノードＩＤを登録し（Ｓ４１０）、ステップＳ４１１に示す処理を実行する。
【０１２９】
一方、合計値が許容値の所定割合以上となる場合（Ｓ４０８：Ｙｅｓ）、処理割当部２６は、負荷テーブル４０を参照して、ステップＳ４０６で選択した処理単位を、現在の負荷が最も低いノード２０のノードＩＤを特定し、ステップＳ４０６で選択した処理単位に対応する処理割当テーブル３０のnode３７に、特定したノードＩＤを登録する（Ｓ４０９）。そして、処理割当部２６は、負荷テーブル４０を参照して、新たに処理単位を割り当てたノード２０の現在の負荷に、新たに割り当てた処理単位に必要な処理能力を加算することにより、負荷テーブル４０の内容を更新する（Ｓ４１１）。
【０１３０】
次に、処理割当部２６は、処理割当テーブル３０を参照して、全ての処理単位のnode３７の欄にノードＩＤが登録されているか否かを判定することにより、全ての処理単位がノード２０に割り当てられたか否かを判定する（Ｓ４１２）。いずれかの処理単位がノード２０に割り当てられていない場合（Ｓ４１２：Ｎｏ）、処理割当部２６は、再びステップＳ４０６に示した処理を実行する。一方、全ての処理単位がノード２０に割り当てられている場合（Ｓ４１２：Ｙｅｓ）、処理割当部２６は、自ノード２０以外のそれぞれのノード２０について後述するノード別処理指示の作成処理を実行し（Ｓ６００）、処理割当部２６は、本フローチャートに示した処理の割り当てを終了する。本フローチャートが終了した時点での負荷テーブル４０および処理割当テーブル３０は、それぞれ、例えば図１９および図２０のようになる。
【０１３１】
次に、ノード別処理指示の作成処理（Ｓ６００）の動作について説明する。図２１は、ノード別処理指示の作成処理（Ｓ６００）の一例を示すフローチャートである。本フローチャートでは、処理割当テーブル３０が図２０に示した状態にあることを前提として説明を行う。また、本フローチャートに示す処理は、自ノード２０以外のそれぞれのノード２０について実行されるが、以下では、ノードＩＤが「002」のノード２０についてのノード別処理指示を例に説明する。
【０１３２】
まず、処理割当部２６は、処理割当テーブル３０を参照して、未選択の処理単位を１つ選択し（Ｓ６０１）、選択した処理単位の処理単位名称３２から、対応するProcessのクラス名を取得し、処理定義を参照して同じクラス名を持つProcessセクションを取得する（Ｓ６０２）。今の場合、ノードＩＤが「002」であるから、処理ＩＤ３１1が「２」、「５」、「11」、「12」、または「18」の処理単位が見つかる。そして、処理割当部２６は、これらの処理単位の中の１つを選択し、例えば、処理ＩＤ３１が「18」の処理単位を選択した場合、処理単位名称３２は「dispatch@card002」であるので、クラス名が「dispatch」であるProcessセクションを取得する。
【０１３３】
次に、処理割当部２６は、ステップＳ６０２で取得したProcessセクションのProcessUnit属性を参照して、ProcessUnit属性が「device」であるか否かを判定する（Ｓ６０３）。今の場合、処理定義テンプレート（図７）の２行目に「ProcessUnit "device" "communicate"」と記載されており、第一引数が「device」であることから、処理割当部２６は、ステップＳ６０３においてＹｅｓと判定する。
【０１３４】
この処理単位は、デバイスに対応付けられているため、処理単位の実行にはデバイス情報が必要となる。処理割当部２６は、デバイスの情報をパラメタとしてProcessセクションに追加する（Ｓ６０４）。追加するパラメタの名称はProcessUnit属性の第二引数（すなわちデバイス種別）とし、パラメタ値はリソース情報管理テーブル２７０のリソース情報２７４に記載されているデバイス識別子とする。具体的には、処理割当部２６は、処理割当テーブル３０を参照して、ステップＳ６０１で選択した処理単位のnode３７から処理単位を実行するノードのＩＤを取得し、取得したノードＩＤをキーとしてリソース情報管理テーブル２７０を検索し、当該ノード２０のリソース情報を取得する。今の場合、処理単位を実行するノード２０のノードＩＤは「002」であるから、リソース情報管理テーブル２７０が「002」となっているリソース情報を取得する。処理割当部２６は、取得したリソース情報から、comunicateデバイスのデバイス識別子を取得する。その結果、処理割当部２６は、「card002」を得る。以上より、処理割当部２６は、「Param "communicate" "card2"」をProcessセクションに追加することになる。
【０１３５】
次に、処理割当部２６は、処理単位の名称をProcessセクションにName属性として追加する（Ｓ６０８）。Processセクションには、Processのクラス名が既に記載されているため、処理割当テーブル３０の処理単位名称３２に記載された名称からProcessのクラス名を削除したものをName属性とする。従って、ここでは、処理割当部２６は、「Name "@card002"」を追加することとなる。
【０１３６】
次に、処理割当部２６は、生成したデータを入力データとして処理する処理単位をDestRef属性に設定する（Ｓ６０９）。処理割当部２６は、ステップＳ６０１で選択した処理単位の処理ＩＤ３１をデータソース３３に持つ処理単位を検索することで、上記処理単位を検索する。今の場合、このような処理単位は見つからないので、処理割当部２６は、上記パラメタは設定しない。以上で、処理割当部２６は、処理ＩＤ３１が「18」の処理単位に対してのノード別処理指示が完成する。
【０１３７】
また、ステップＳ６０３において、ステップＳ６０２で取得したProcessセクションのProcessUnit属性が「device」でない場合（Ｓ６０３：Ｎｏ）、処理割当部２６は、ステップＳ６０２で取得したProcessセクションのProcessUnit属性を参照して、ProcessUnit属性が「souce-subprocess」であるか否かを判定する（Ｓ６０５）。ProcessUnit属性が「souce-subprocess」である場合（Ｓ６０５：Ｙｅｓ）、すなわち、ステップＳ６０１で処理ＩＤ３１が「２」の処理単位を選択した場合、Processのクラス名のみの比較では、複数のProcessセクションが取得される。今の場合、処理割当部２６は、処理定義本体（図８参照）の６行目〜12行目の部分と、14行目〜21行目の部分とを取得する。処理割当部２６は、SourceRef属性に基づき、上記どちらのProcessセクションを使用すべきかを決定する（Ｓ６０６）。
【０１３８】
ProcessUnit属性の第一引数が、souce-subprocessの場合、処理単位名称３２は、[Processのクラス名]/[データソースのSubProcessのクラス名]@[ データソースのSubProcessのインスタンス名]という命名規則になる。一方、SourceRef属性の第二引数、第三引数にはデータソースのSubProcessのクラス名、SUbProcessのインスタンス名が設定されているので、処理単位名称３２とSourceRef属性を比較することで、処理割当部２６は、処理定義の対応部分を抽出することができる。今の場合、処理単位名称３２からは、データソースのSubProcessのインスタンス名として「area2」を抽出することができるので、このインスタンス名を持つProcessセクションは、処理定義本体の14行目〜21行目の部分であることが分かる。
【０１３９】
次に、処理割当部２６は、ステップＳ６０８に示した処理を実行する。具体的には、処理割当部２６は、ProcessセクションのName属性を決定する。今の場合、ProcessセクションのName属性は、「Name "sensor-group@area2"」となる。そして、処理割当部２６は、Ｓ６０１で選択した処理単位の処理ＩＤ３１をデータソース３３に持つ処理単位を処理割当テーブル３０から検索する。今の場合、処理割当部２６は、処理ＩＤ３１が「18」である処理単位が条件を満たす処理単位として見つける。この処理単位がDestRef属性の設定先となる。処理割当部２６は、当該処理単位の処理単位名称３２とnode３７を参照して、それぞれ、「dispatch@card002」、「002」であることを確認する。また、処理割当部２６は、リソース情報管理テーブル２７０を参照して、当該node３７の欄に記載されたデータと同じ値をノードＩＤ２７１に持つエントリを検索し、見つけたエントリのアドレス２７２を参照することで、ノード２０のアドレスを取得する。処理割当部２６は、第一引数をノードＩＤ、第二引数をノード２０のアドレス、第三引数を処理単位の名称として、DestRef属性を設定する。従って、今の場合、処理割当部２６は、「DestRef "002" "192.168.10.12" "dispatch@card002"」をProcessセクションに追加することとなる。
【０１４０】
また、ステップＳ６０５において、ステップＳ６０２で取得したProcessセクションのProcessUnit属性が「souce-subprocess」でない場合（Ｓ６０５：Ｎｏ）、処理割当部２６は、ProcessUnit属性の第一引数が、「subprocess」であると判定する。例えば、処理ＩＤ３１が「５」の処理単位に対する処理を行う場合、処理割当部２６は、ステップＳ６０７を実行することになる。処理割当部２６は、Processのクラス名の比較で、処理定義本体（図８参照）の23行目〜41行目の部分が取得する。この部分は、複数の処理単位に対する設定情報を含んでいる。ステップＳ６０７において、処理割当部２６は、SubProcessのインスタンス名に基づき、情報を絞り込む。ProcessUnit属性の第一引数が、subprocessの場合、処理単位は、[Processのクラス名]/[SubProcessのクラス名]@[SubProcessのインスタンス名]という命名規則となる。従って、処理割当部２６は、取得したProcessセクション内のSubProcessセクションの第二引数から、対応するSubProcessセクションを決定することができる。今の場合、処理ＩＤ３１が「５」の処理単位の処理単位名称３２は、「cycle/sensor-group@area2」であるので、SubProcessのインスタンス名は「area2」である。従って、処理定義本体の29行目〜34行目が対応するSubProcessとなる。そして、処理割当部２６は、Processセクションから不要な他のSubProcessセクションを削除する。
【０１４１】
次に、処理割当部２６は、Ｓ６０８に示した処理を実行する。処理割当部２６は、処理ＩＤ３１が「11」または「12」の処理単位についても同様に処理を行い、ノードＩＤが「002」のノード２０に対するノード別処理指示を完成させる。ノードＩＤが「002」のノード２０に対するノード別処理指示を例示すると、例えば図２２のようになる。なお、ノード別処理指示には、処理定義テンプレートまたは処理定義本体に記載されている、SourceRef属性、ProcessUnit属性、およびRequire属性は記載される必要はなく、処理割当部２６は、ノード別処理指示を生成するときにこれら属性を削除する。
【０１４２】
以上、本発明の第１の実施形態について説明した。
【０１４３】
上記説明から明らかなように、本実施形態の分散処理システム１０によれば、特定のノード２０に負荷を集中させることなく、処理間の連携を考慮して複数のノード２０に処理を割り当てることができる。
【０１４４】
なお、ユビキタスフロントエンドシステムを構成する全てのノード２０が、同時に起動するとは限らないため、マスタノードが全てのノード２０のノード別処理指示を生成し、各ノードへノード別処理指示を送信してシステムが動作を開始した後に、新たなノード２０が起動する場合がある。また、システムが動作中にセンシングアプリケーション実行部２９を稼動させているノード２０に障害が発生する場合もある。マスタノードは、上記のようなノード２０の増減を検出した場合、構成変更を行い、改めて全体の最適化を行う。具体的には、マスタノードは全てのノード２０に、処理の停止を指示した後、図１２に示す処理を再度実行し、各ノード２０のノード別処理指示を再生成する。構成変更を実施するには、一旦システムの動作を停止する必要があるため、頻繁に構成変更を行うことは好ましくない。従って、マスタノードは、新規にノード２０を検出した場合は、ノード検出後、一定時間経過した後に構成変更を行う。一方、センシングアプリケーション実行部２９が動作中のノード２０に障害が発生した場合、そのままにしておくとシステムの機能が損なわれてしまうため、マスタノードは、直ちに構成変更を行う。
【０１４５】
次に、本発明の第２の実施形態について説明する。
【０１４６】
図２３は、第２の実施例における分散処理システム５０の一例を示すシステム構成図である。分散処理システム５０は、ＬＡＮ５２に接続された複数のノード６０を備える。それぞれのノード６０は、複数のグループ毎にサブネット５１に属している。それぞれのサブネット５１は、ルータ５３を介して接続されている。それぞれのノード６０は、複数の他のノード６０との間で、ＰＡＸＯＳプロトコルを使った分散合意の処理を行う。
【０１４７】
図２４は、第２の実施形態におけるノード６０の機能構成の一例を示すブロック図である。ノード６０は、ノードＩＤ格納部６１、ＩＤ通知部６２、ＩＤ登録部６３、および分散合意処理部６４を有する。ノードＩＤ格納部６１には、例えば図２５に示すように、それぞれのノード６０を識別するノードＩＤ６１１およびそれぞれのノード６０のアドレス６１２を、ＬＡＮ５２を介して他のノード６０から受信した受信時刻６１０に対応付けて格納する。
【０１４８】
ＩＤ通知部６２は、ノード６０が起動した場合に、自ノード６０のノードＩＤおよびアドレスを、ＬＡＮ５２を介して例えばブロードキャストにより他のノード６０へ送信する。ＩＤ登録部６３は、ＬＡＮ５２を介して他のノード６０からノードＩＤおよびアドレスを受信した場合に、受信したノードＩＤおよびアドレスを、受信時刻に対応付けてノードＩＤ格納部６１に登録する。なお、それぞれのサブネット５１内の少なくとも１つのノード６０には、他のサブネット５１内の少なくとも１つのノード６０のＩＰアドレスが設定されており、それぞれのサブネット５１内のノードの情報は、他のサブネット５１内の少なくとも１つのノード６０に伝達されるようになっている。
【０１４９】
分散合意処理部６４は、ノード６０の起動後に、ノードＩＤ格納部６１内のノードＩＤの登録数の増加率を測定し、増加率が上昇から下降に転じた後に、当該増加率が、当該増加率の最大値から予め定められた割合だけ低い増加率となった場合に、その時点でノードＩＤ格納部６１に登録されているノードＩＤの数を、分散合意アルゴリズムにおける定足数として、分間合意アルゴリズムを用いた処理を開始する。
【０１５０】
ここで、ユビキタスフロントエンドシステムが多数のノード６０から構成される場合、一般にはネットワーク負荷を分散させるため、図２３に示すように、システムを複数のサブネットに分離した構成にする場合が多い。一方、ブロードキャストパケットにはネットワークアドレスが含まれており、ブロードキャストパケットは、ブロードキャストパケットが有するネットワークアドレス内の全ノード６０に届くが、ネットワークが複数のサブネットで構成される場合、ブロードキャストパケットは、発信元のサブネット内にしか届かない。
【０１５１】
そのため、複数のサブネットから構成されるシステムでネットワーク全体へのブロードキャストを行うためには、全てのサブネットに対してブロードキャストパケットを送信する必要がある。そのためには、全てのサブネットのネットワークアドレスを予め全てのノード６０に設定しておく必要があり、システム構築作業が煩雑になる。また、全てのノード６０が、全てのサブネットに対してブロードキャストパケットを送信するとネットワーク負荷が増大するという課題もある。
【０１５２】
この課題を解決する手法として、大規模な分散システムではシステムを構成するノード６０同士が、ノード情報（ノード識別子とアドレス）を定期的に交換することで、ノード検出を行う方法がある。つまり、直接ノード情報を知らないノード同士が、他のノード６０を経由して芋づる式にノード情報を交換していく方式である。あるノード６０が他のノード６０のノード情報を保持する状態をエッジ（枝）とみなすと、システム全体をグラフ構造と考えることができる。このようなノード検出手法では、初期状態でグラフを構成する各ノード６０同士がどこかのエッジで相互接続されている、連結グラフになっていれば、全てのノード６０がノード検出を行うことができる。
【０１５３】
従って、グラフが連結グラフになるように各ノード６０に他のノード６０のノード情報を予め設定しておけば、一定時間後、全てのノード６０が他の全てのノード６０を検出した状態になる。また、各ノード６０は、停止するときに、これまで検出したノード６０の情報をフラッシュＲＯＭ等の不揮発性メモリに記録しておき、次回起動時に当該メモリからノード情報を読み出して通信を再開する。これによって次回起動時は、ノード情報の設定が不要となる。また次回起動時に、システムの構成変更によって一部のノード６０のアドレスが変化したり、ノード６０の増減があった場合も、変更されていない情報に基づき変更部分を検出することが可能となる。従って、システム構築時に設定作業が発生するが、一旦設定を行えば、その後のシステムの保守は不要になる。
【０１５４】
一方、ＰＡＸＯＳプロトコルによる分散合意を行うには定足数が必要である。通常、定足数は全ノード数の過半数とするため、各ノード６０は全ノード数を知っておく必要がある。前記した第１の実施形態では、各ノード６０に全ノード数を設定することにしていたが、ノード数が増えると各ノード６０への設定は煩雑になる。また、システム変更を行い、ノード数が変更された場合、全てのノード６０に対して再設定を行う必要がある。
【０１５５】
システムが１つのサブネット内に収まる場合は、ブロードキャストパケットの送信周期だけ待てば全てのノード６０を検出することが可能であるため、これによってそれぞれのノード６０は全ノード数を知ることができる。しかし、上記のようにシステムが複数のサブネットから構成されており、ノード同士がノード情報を交換することでノード検出を行う場合には、どの程度待てば全ノード数を検出した状態になるのか不明である。
【０１５６】
このような課題に対して本実施形態では、各ノード６０が検出したノード数の時間変化を記録しておき、検出したノード数の時間変化に基づき、全ノード数を予測し、ＰＡＸＯＳプロトコルで使用する定足数を決定する。
【０１５７】
図２６〜図２８に、ノード６０同士がノード情報を交換する方式でノード検出を行った場合のシミュレーション結果を示す。図２６〜図２８では、検出したノード数の時間変化が「＋」でプロットされ、それを微分した値（増加率）が「×」でプロットされている。グラフの縦軸は検出されたノード数、横軸はステップ数である。本シミュレーションでは、１ステップ毎に、各ノード６０がノード情報を送信するノード６０を検出済みのノード６０の中から１つ選択し、自ノード６０と検出済みのノード６０のノード情報を一定個数、選択したノード６０へ送信する操作を行うこととした。送信する検出済みのノード６０のノード情報と、送信先のノード６０は、ランダムに選択することとした。
【０１５８】
図２６は、全ノード数が256、サブネット数が16、各サブネット内のノード数が16、一回のノード交換で交換するノード情報の数が４という条件でシミュレーションを行った結果である。サブネット内では、ブロードキャストにより容易にノード６０の相互検出が可能であるため、初期状態としてサブネット内のノードは相互検出しているものとした。サブネット間を跨るノード情報の送信については、ｉ番目（ｉ＝１〜１５）のサブネット内の１つのノード６０がｉ＋１番目のサブネット内の１つのノード６０のノード情報を保持し、１６番目のサブネット内の１つのノード６０が１番目のサブネット内の１つのノード６０のノード情報を保持していることとした。
【０１５９】
図２７は、全ノード数が256、サブネット数が16、各サブネット内のノード数が16、一回のノード交換で交換するノード情報の数が８という条件でシミュレーションを行った結果である。図２７においても、初期状態として、各サブネット内のノード６０は相互検出しているという条件でシミュレーションを行った。また、サブネット間を跨るノード情報の送信については、ｉ番目（ｉ＝１〜１５）のサブネット内の１つのノード６０がｉ＋１番目のサブネット内の１つのノード６０のノード情報を保持し、１６番目のサブネット内の１つのノード６０が１番目のサブネット内の１つのノード６０のノード情報を保持していることとした。
【０１６０】
図２８は、全ノード数が256、サブネット数が8、各サブネット内のノード数が32、一回のノード交換で交換するノード情報の数が8という条件でシミュレーションを行った結果である。図２８においても、初期状態として、各サブネット内のノード６０は相互に検出しているという条件でシミュレーションを行った。また、サブネット間を跨るノード情報の送信については、ｉ番目（ｉ＝１〜７）のサブネット内の１つのノード６０がｉ＋１番目のサブネット内の１つのノード６０のノード情報を保持し、８番目のサブネット内の１つのノード６０が１番目のサブネット内の１つのノード６０のノード情報を保持していることとした。
【０１６１】
図２６〜図２８に示したシミュレーション結果はいずれも、「×」でプロットされたノード検出の増加率が最大値に達するときに、全ノード数の約半数を検出する特徴を示している。ノード検出の増加率が減少に転じたときには、全ノード数の半数以上を検出しているはずであるから、そのときに検出しているノード数をＰＡＸＯＳプロトコルの定足数とすればよいことがわかる。
【０１６２】
本実施形態において、分散合意処理部６４は、例えば図２９に示すように、自ノード６０の起動後に、ノードＩＤ格納部６１内のノードＩＤの登録数の増加率を測定する。そして、分散合意処理部６４は、当該増加率が上昇から下降に転じた後に、当該増加率が、当該増加率の最大値から予め定められた割合（図２９の例では70%）だけ低い増加率となった場合に、その時点（図２９のｔ０の時点）でノードＩＤ格納部６１に登録されているノードＩＤの数を、分散合意アルゴリズムにおける定足数として、分間合意アルゴリズムを用いた処理を開始する。これにより、全ノード数が判明するｔ０の時点まで待つことなく、分散合意処理部６４は、ｔ０の時点で迅速にＰＡＸＯＳプロトコルを使った分散合意の処理を開始することができる。
【０１６３】
図３０は、第２の実施形態におけるノード６０の動作の一例を示すフローチャートである。例えば、電源が投入される等の所定のタイミングで、ノード６０は、本フローチャートに示す動作を開始する。
【０１６４】
まず、ＩＤ通知部６２は、自ノード６０のノードＩＤおよびアドレスをＬＡＮ５２を介して他のノード６０に通知する（Ｓ７００）。そして、ＩＤ登録部６３は、ＬＡＮ５２を介して他のノード６０からノードＩＤおよびアドレスを受信したか否かを判定する（Ｓ７０１）。他のノード６０からノードＩＤおよびアドレスを受信していない場合（Ｓ７０１：Ｎｏ）、ＩＤ登録部６３は、他のノード６０からノードＩＤおよびアドレスを受信するまでステップＳ７０１を繰り返す。一方、他のノード６０からノードＩＤおよびアドレスを受信した場合（Ｓ７０１：Ｙｅｓ）、ＩＤ登録部６３は、受信したノードＩＤおよびアドレスを、受信時刻に対応付けてノードＩＤ格納部６１に登録する（Ｓ７０２）。
【０１６５】
次に、分散合意処理部６４は、ノードＩＤ格納部６１に登録されているノードＩＤの登録数の増加率を算出し（Ｓ７０３）、増加率が上昇から下降に転じたか否かを判定する（Ｓ７０４）。増加率が上昇から下降に転じた場合（Ｓ７０４：Ｙｅｓ）、分散合意処理部６４は、増加率が最大値から所定割合以下（例えば最大値の70%以下）になったか否かを判定する（Ｓ７０５）。増加率が上昇から下降に転じていない場合（Ｓ７０４：Ｎｏ）、または、増加率が最大値から所定割合以下になっていない場合（Ｓ７０５：Ｎｏ）、ＩＤ登録部６３は、再びステップＳ７０１に示した処理を実行する。増加率が最大値から所定割合以下になった場合（Ｓ７０５：Ｙｅｓ）、ＩＤ登録部６３は、ノードＩＤ格納部６１を参照し、現在のノード数を定足数として分散合意処理を開始し（Ｓ７０６）、ノード６０は、本フローチャートに示す動作を終了する。
【０１６６】
以上、本発明の第２の実施形態について説明した。
【０１６７】
なお、本発明は、上記した実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１６８】
例えば、上記した第１の実施形態において、マスタ決定部２５は、マスタノードの決定において、製造年月日が最も新しいノード２０をマスタノードとして提案するが、本発明はこれに限られない。他の形態として、マスタ決定部２５は、自ノード２０をマスタノードとして提案してもよく、ノードＩＤまたはアドレスの値が最も小さいノード２０をマスタノードとして提案してもよい。
【０１６９】
また、マスタ決定部２５は、処理割当テーブル３０に登録されているリソース情報を参照して、ＣＰＵ以外のリソースの情報が少ないノード２０をマスタノードとして提案するようにしてもよい。マスタノードの信頼性を向上する方法の１つとして、マスタノードがマスタノードとしての処理以外を行わないことが挙げられる。ＣＰＵ以外のリソースを持つノード２０は、そのリソースを利用した処理（マスタノードとしての処理以外の処理）を割り当てることができ、マスタ以外のノード２０として動作させることが好ましい。例えば、通信手段を備えるノード２０ではディスパッチャ２９０を稼動させ、データ収集サーバと通信させる。また、センサ１４が接続されたノード２０ではアダプタ２９３を稼動させ、センサ１４の制御処理を行わせる。これにより、複数のノード２０に効率よく処理を割り当てることができる。
【０１７０】
また、それぞれのノード２０に、自ノード２０の障害を検出する障害発生検出部をさらに設け、リソース情報送信部２１は、当該障害発生検出部によって自ノード２０に障害が発生したことが検出された場合に、次のリソース情報の送信タイミングで、リソース情報内に障害の発生を示す障害情報を含めて送信するようにしてもよい。この場合、リソース情報登録部２２は、リソース情報に障害情報が含まれている場合に、障害情報以外のリソース情報でリソース情報管理テーブル２７０内の対応する情報を上書きすると共に、当該障害情報を障害履歴としてリソース情報管理テーブル２７０に追加登録する。そして、マスタ決定部２５は、マスタノードを提案する場合に、リソース情報管理テーブル２７０を参照して、登録されている障害情報が少ないノード２０をマスタノードとして提案する。これにより、より信頼性の高いノード２０をマスタノードとして提案することができる。
【０１７１】
また、それぞれのノード２０に、自ノード２０の稼働環境を測定し、稼働環境が悪い場合に高い数値を示す環境値を出力する環境測定部をさらに設け、リソース情報送信部２１は、当該環境測定部が出力した環境値をリソース情報内に含めて他の情報処理装置へ送信するようにしてもよい。環境測定部は、例えば、稼働中の温度や湿度等が、予め設定された許容範囲から外れている度合いを数値として出力する。マスタノードを提案する場合、マスタ決定部２５は、リソース情報管理テーブル２７０を参照して、リソース情報に含まれている環境値が低いノード２０をマスタノードとして提案する。これにより、より稼働環境の良好なノード２０をマスタノードとして提案することができるため、より故障する可能性の低いノード２０をマスタノードとして提案することができる。
【０１７２】
また、上記した第１の実施形態では、分散合意における定足数は管理者等によってそれぞれのノード２０に予め設定されていたが、他の形態として、第１の実施形態において、上記した第２の実施形態の方法を用いるようにしてもよい。
【図面の簡単な説明】
【０１７３】
【図１】本発明の第１実施形態に係る分散処理システム１０の一例を示すシステム構成図である。
【図２】コンソール１１の動作の一例を示すフローチャートである。
【図３】第１の実施形態におけるそれぞれのノード２０の一例を示すハードウェア構成図である。
【図４】第１の実施形態におけるそれぞれのノード２０の機能構成の一例を示すブロック図である。
【図５】リソース情報格納部２７に格納されるデータの構造の一例を示す図である。
【図６】履歴情報格納部２３に格納されるデータの構造の一例を示す図である。
【図７】処理定義に含まれる処理定義テンプレートの一例を示す図である。
【図８】処理定義に含まれる処理定義本体の一例を示す図である。
【図９】処理定義に含まれる処理定義本体の一例を示す図である。
【図１０】ＰＡＸＯＳプロトコルを使った分散合意の一例を説明するためのシーケンス図である。
【図１１】第１の実施形態におけるノード２０の動作の一例を示すフローチャートである。
【図１２】処理の割当（Ｓ４００）の処理の一例を示すフローチャートである。
【図１３】処理の割当過程における処理割当テーブル３０の一例を示す概念図である。
【図１４】処理の割当過程における処理割当テーブル３０の一例を示す概念図である。
【図１５】データ提供元の割当処理（Ｓ５００）の一例を示すフローチャートである。
【図１６】処理の割当過程における処理割当テーブル３０の一例を示す図である。
【図１７】データ提供元の割当処理（Ｓ５００）の他の例を示すフローチャートである。
【図１８】処理の割当過程における負荷テーブル４０の一例を示す図である。
【図１９】処理の割当の終了時点における負荷テーブル４０の一例を示す図である。
【図２０】処理の割当の終了時点における処理割当テーブル３０の一例を示す図である。
【図２１】ノード別処理指示の作成処理（Ｓ６００）の一例を示すフローチャートである。
【図２２】ノード別処理指示の作成処理（Ｓ６００）によって作成されたノード別処理指示の一例を示す図である。
【図２３】第２の実施例における分散処理システム５０の一例を示すシステム構成図である。
【図２４】第２の実施形態におけるノード６０の機能構成の一例を示すブロック図である。
【図２５】ノードＩＤ格納部６１に格納されるデータの構造の一例を示す図である。
【図２６】ノード検出のシミュレーション結果を示す図である。
【図２７】ノード検出のシミュレーション結果を示す図である。
【図２８】ノード検出のシミュレーション結果を示す図である。
【図２９】定足数の推定方法の一例を説明するための概念図である。
【図３０】第２の実施形態におけるノード６０の動作の一例を示すフローチャートである。
【符号の説明】
【０１７４】
１０・・・分散処理システム、１１・・・コンソール、１２・・・計算機用ＬＡＮ、１３・・・センサ用ＬＡＮ、１４・・・センサ、１５・・・アンテナ、２０・・・ノード、２１・・・リソース情報送信部、２２・・・リソース情報登録部、２３・・・履歴情報格納部、２４・・・履歴情報管理部、２５・・・マスタ決定部、２６・・・処理割当部、２７・・・リソース情報格納部、２８・・・スレーブ処理部、２９・・・センシングアプリケーション実行部、２９０・・・ディスパッチャ、２９１・・・フィルタ、２９２・・・駆動制御、２９３・・・アダプタ、２００・・・ＲＡＭ、２０１・・・ＲＯＭ、２０２・・・ＣＰＵ、２０３・・・入出力インターフェイス、２０４・・・無線インターフェイス、２０５・・・ＬＡＮインターフェイス、２０６・・・ＬＡＮインターフェイス、２０７・・・メディアインターフェイス、２０８・・・センサインターフェイス、２１０・・・ディスプレイ、２１１・・・キーボード、２１２・・・マウス、２１３・・・記録媒体、３０・・・処理割当テーブル、３１・・・処理ＩＤ、３２・・・処理単位名称、３３・・・データソース、３４・・・event/sec、３５・・・device、３６・・・mips、３７・・・node、４０・・・負荷テーブル、４１・・・ノードＩＤ、４２・・・許容値、４３・・・現在の負荷、５０・・・分散処理システム、５１・・・サブネット、５２・・・ＬＡＮ、５３・・・ルータ、６０・・・ノード、６１・・・ノードＩＤ格納部、６２・・・ＩＤ通知部、６３・・・ＩＤ登録部、６４・・・分散合意処理部
【図１】
2010122773.tif 000003
【図２】
2010122773.tif 000004
【図３】
2010122773.tif 000005
【図４】
2010122773.tif 000006
【図５】
2010122773.tif 000007
【図６】
2010122773.tif 000008
【図７】
2010122773.tif 000009
【図８】
2010122773.tif 000010
【図９】
2010122773.tif 000011
【図１０】
2010122773.tif 000012
【図１１】
2010122773.tif 000013
【図１２】
2010122773.tif 000014
【図１３】
2010122773.tif 000015
【図１４】
2010122773.tif 000016
【図１５】
2010122773.tif 000017
【図１６】
2010122773.tif 000018
【図１７】
2010122773.tif 000019
【図１８】
2010122773.tif 000020
【図１９】
2010122773.tif 000021
【図２０】
2010122773.tif 000022
【図２１】
2010122773.tif 000023
【図２２】
2010122773.tif 000024
【図２３】
2010122773.tif 000025
【図２４】
2010122773.tif 000026
【図２５】
2010122773.tif 000027
【図２６】
2010122773.tif 000028
【図２７】
2010122773.tif 000029
【図２８】
2010122773.tif 000030
【図２９】
2010122773.tif 000031
【図３０】
2010122773.tif 000032