JP2013047922A - イベント収集方法及び情報処理装置 - Google Patents

Abstract

【課題】ネットワークトラフィックを抑制すること。
【解決手段】サーバノード１１０は、センサネットワークのトポロジを取得する。サーバノード１１０は、トポロジが変更された場合に、センサネットワークに含まれるノードから当該ノードによって出力されるイベントの種別、当該ノードを含む複数のノードを集約する集約属性の属性名及び属性値を取得する。サーバノード１１０は、モジュールが入力とする複数のイベントの種別のうち一部のイベントを出力するノードであり、かつ各ノード間でモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。モジュールには、サービス提供処理が起動されるトリガーとなるイベントの集約処理が組み込まれる。サーバノード１１０は、複数のノードが抽出された場合に、センサネットワークのトポロジを参照して、各ノードが収容される上位ノードにモジュールを配備する。
【選択図】図２

Description

本発明は、イベント収集方法及び情報処理装置に関する。

センサノードによってセンシングされたセンシングデータをイベントとして採取するセンサネットワークが知られている。かかるセンサネットワークを介してサーバノードに採取されたイベントに応じて各種のサービス、例えばアラートの発信や機器の制御などが提供される。

このように、センサノードからのイベントをサーバノードに収集させる場合には、全てのイベントがサーバノードに集中して通知されることになる。このため、サーバノードの負荷が増大するとともに、ネットワークのトラフィックの増加に伴ってネットワーク帯域も逼迫する。

かかるサーバノードの負荷とネットワークトラフィックとを抑制する技術の一例として、次のような技術が提案されている。一例としては、データをフィルタリングするフィルタエージェントを消費ノードからデータ生産ノードへ転送することによってシステムパフォーマンスおよび／またはリソース消費を改善するシステムが挙げられる。他の一例としては、スクリプトを入れ子構造とし、スクリプトの一部を下位ノードである中間ノードや下位ノードに実行させるセンサネットワークシステムが挙げられる。

特開２００８−９７６０３号公報 特開２００６−３４４０１７号公報

しかしながら、上記の従来技術には、以下に説明するように、依然として、ネットワークトラフィックを抑制できないという問題がある。

すなわち、前者及び後者のいずれのシステムにおいても、センサノードや中継ノードがセンサネットワークに新たに追加されたり、あるいは撤去されたりすることによってセンサネットワークのトポロジが変化する場合に対応できない。なぜなら、センサネットワークのトポロジが変化した場合に、下位ノードにフィルタエージェントやスクリプトを適切に再配備することができないからである。このため、前者及び後者のいずれのシステムを用いた場合でも、センサネットワークのトポロジが変化すると変化前よりもネットワークトラフィックが悪化してしまう。

開示の技術は、上記に鑑みてなされたものであって、ネットワークトラフィックを抑制できるイベント収集方法及び情報処理装置を提供することを目的とする。

本願の開示するイベント収集方法は、検知したイベントを送信するセンサノードと、前記イベントを中継する中間ノードと、を含む複数のノードが接続されたセンサネットワークからイベントを収集するコンピュータが実行するイベント収集方法である。さらに、前記コンピュータが、前記イベントを加工処理するモジュールを識別するモジュール識別子と、前記モジュールが加工処理するイベントの種別を示す入力イベント種別と、前記モジュールが集約するイベントを分類する集約属性名とを関連付けて管理するモジュール定義情報を記憶する処理を実行する。さらに、前記コンピュータが、前記ノードで発生するイベントを収集し、当該収集したイベントの種別を示す発生イベント種別と、当該収集したイベントに関連づけられた属性名と属性値を含む発生イベント属性と、当該収集したイベントが発生したノードを識別する発生ノード識別子とを関連付けて管理する発生イベント情報を記憶する処理を実行する。さらに、前記コンピュータが、前記ノードの接続関係を収集し、当該接続関係を管理するトポロジ情報を記憶する処理を実行する。さらに、前記コンピュータが、前記モジュール定義情報と前記発生イベント情報とに基づき、前記入力イベント種別と前記発生イベント種別が対応し、前記集約属性名で特定される前記属性名に対応する前記属性値で分類される前記発生ノード識別子を前記モジュールの加工処理ごとに抽出する処理を実行する。さらに、前記コンピュータが、前記抽出した発生ノード識別子が前記モジュールの加工処理に対して単一の場合は、当該発生ノード識別子で識別されるノードを当該モジュール識別子で識別されるモジュールの配備先として決定する処理を実行する。さらに、前記コンピュータが、前記抽出した発生ノード識別子が前記モジュールの加工処理に対して複数の場合は、前記トポロジ情報を参照し、前記複数の発生ノード識別子に共通する上位ノードを当該モジュール識別子で識別されるモジュールの配備先として決定する処理を実行する。さらに、前記コンピュータが、前記決定した配備先のノードに対して、前記モジュールを配備する処理を実行する。

本願の開示するイベント収集方法の一つの態様によれば、ネットワークトラフィックを抑制できるという効果を奏する。

図１は、実施例１に係るセンサネットワークシステムのシステム構成を示す図である。 図２は、実施例１に係るサーバノードの機能的構成を示すブロック図である。 図３は、モジュール記憶部に記憶される情報の構成例を示す図である。 図４は、モジュール定義記憶部に記憶される情報の構成例を示す図である。 図５は、トポロジ記憶部に記憶される情報の構成例を示す図である。 図６は、イベント記憶部に記憶される情報の構成例を示す図である。 図７は、発生イベント情報記憶部に記憶される情報の構成例を示す図である。 図８は、配備先情報記憶部に記憶される情報の構成例を示す図である。 図９は、図８に示した配備先情報記憶部からの配備状況の遷移を示す図である。 図１０は、図７に示した発生イベント情報記憶部からのイベント発生状況の遷移を示す図である。 図１１は、図９に示した配備先情報記憶部からの配備状況の遷移を示す図である。 図１２は、図１０に示した発生イベント情報記憶部からのイベント発生状況の遷移を示す図である。 図１３は、図１に示したセンサネットワークにおけるトポロジ変更の一例を示す図である。 図１４は、図５に示したトポロジ記憶部からのトポロジの遷移を示す図である。 図１５は、図９に示した配備先情報記憶部からの配備状況の遷移を示す図である。 図１６は、図１０に示した発生イベント情報記憶部からのイベント発生状況の遷移を示す図である。 図１７は、実施例１に係るセンサノードの機能的構成を示すブロック図である。 図１８は、実施例１に係るＧＷノードの機能的構成を示すブロック図である。 図１９は、実施例１に係るセンサノードにおける全体処理の手順を示すフローチャートである。 図２０は、実施例１に係るモジュール配備処理の手順を示すフローチャートである。 図２１は、実施例２に係るサーバノードの機能的構成を示すブロック図である。 図２２は、トポロジ記憶部に記憶される情報の構成例を示す図である。 図２３は、配備先情報記憶部に記憶される情報の構成例を示す図である。 図２４は、発生イベント情報記憶部に記憶される情報の構成例を示す図である。 図２５は、配備先情報記憶部に記憶される情報の構成例を示す図である。 図２６は、実施例２に係るセンサノードにおける全体処理の手順を示すフローチャートである。 図２７は、実施例２に係るモジュール配備処理の手順を示すフローチャートである。 図２８は、実施例３に係るサーバノードの機能的構成を示すブロック図である。 図２９は、実施例３に係るセンサノードの機能的構成を示すブロック図である。 図３０は、実施例３に係るＧＷノードの機能的構成を示すブロック図である。 図３１は、実施例３に係るセンサノードにおける全体処理の手順を示すフローチャートである。 図３２は、実施例３に係るモジュール配備処理の手順を示すフローチャートである。 図３３は、実施例４に係るサーバノードの機能的構成を示すブロック図である。 図３４は、トポロジ記憶部に記憶される情報の構成例を示す図である。 図３５は、配備先情報記憶部に記憶される情報の構成例を示す図である。 図３６は、発生イベント情報記憶部に記憶される情報の構成例を示す図である。 図３７は、配備先情報記憶部に記憶される情報の構成例を示す図である。 図３８は、実施例４に係るセンサノードにおける全体処理の手順を示すフローチャートである。 図３９は、実施例４に係るモジュール配備処理の手順を示すフローチャートである。 図４０は、実施例５に係るサーバノードの機能的構成を示すブロック図である。 図４１は、モジュール定義記憶部に記憶される情報の構成例を示す図である。 図４２は、実施例５に係るセンサノードの機能的構成を示すブロック図である。 図４３は、実施例５に係るＧＷノードの機能的構成を示すブロック図である。 図４４は、実施例５に係るセンサノードにおける全体処理の手順を示すフローチャートである。 図４５は、実施例６に係るサーバノードの機能的構成を示すブロック図である。 図４６は、モジュール定義記憶部に記憶される情報の構成例を示す図である。 図４７は、実施例６に係るセンサノードの機能的構成を示すブロック図である。 図４８は、実施例６に係るＧＷノードの機能的構成を示すブロック図である。 図４９は、実施例６に係るセンサノードにおける全体処理の手順を示すフローチャートである。 図５０は、実施例６に係るモジュール配備処理の手順を示すフローチャートである。

以下に、本願の開示するイベント収集方法及び情報処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［システム構成］
まず、本実施例に係るセンサネットワークシステムのシステム構成について説明する。図１は、実施例１に係るセンサネットワークシステムのシステム構成を示す図である。図１に示すセンサネットワークシステム１は、センサノード２１０によってセンシングされたセンシングデータをイベントとして収集し、収集したイベントに応じて各種のサービスを提供するものである。

図１に示すように、センサネットワークシステム１には、サーバノード１１０と、センサノード２１０Ｘ−１、２１０Ｘ−２及び２１０Ｙ−１とが収容される。この図１の例では、Ｘ家に収容されたセンサノード２１０Ｘ−１及び２１０Ｘ−２と、Ｙ家に収容されたセンサノード２１０Ｙ−１とからサーバノード１１０へイベントデータが収集される場合を想定する。なお、以下では、センサノード２１０Ｘ−１、２１０Ｘ−２及び２１０Ｙ−１を区別なく総称する場合に「センサノード２１０」と記載する場合がある。

これらセンサノード２１０とサーバノード１１０との間は、ネットワーク５を介して通信可能に接続される。かかるネットワーク５の一例としては、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの通信網が挙げられる。なお、図１の例では、センサノード２１０を３つ収容する場合を例示したが、少なくとも複数のセンサノードが収容されていればよく、任意の数のセンサノードを収容する場合に適用することができる。

このうち、センサノード２１０は、センサ付きの通信端末である。かかるセンサノード２１０の一態様としては、パーソナルコンピュータや周辺機器、ＡＶ機器、携帯電話機やＰＨＳ（Personal Handyphone System）の携帯端末、家電製品などの各種の機器が挙げられる。また、センサノード２１０に搭載されるセンサの一態様としては、温度を計測する温度センサ、湿度を計測する湿度センサ、温度および湿度を計測する温湿度センサなどの環境センサが挙げられる。なお、ここでは、センサノード２１０に搭載されるセンサの例として環境センサを例示したが、センサノード２１０にはＧＰＳ（Global Positioning System）センサ、加速度センサやジャイロセンサなどの任意のセンサを搭載できる。

サーバノード１１０は、センサネットワークのルートノードとして機能し、イベントに応じて各種のサービスを提供するサーバ装置である。一態様としては、サーバノード１１０は、センサノード２１０から受信したイベントを加工する加工処理を実行するモジュールを自装置よりも下位に位置するノードに配備することによってイベントを分散処理させる。かかるモジュールには、サービス提供用のアプリケーションによって実行されるサービス提供処理のトリガーとなるイベントのフィルタリング処理や集約処理が組み込まれる。

ここで、本実施例に係るサーバノード１１０は、センサネットワークのトポロジを取得する。さらに、本実施例に係るサーバノード１１０は、トポロジが変更された場合に、各ノードから当該ノードによって出力されるイベントの種別、当該ノードを含む複数のノードを集約する集約属性の属性名及び属性値を取得する。さらに、本実施例に係るサーバノード１１０は、モジュールが入力とする複数のイベントの種別のうち一部のイベントを出力するノードであり、かつ各ノード間でモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。さらに、本実施例に係るサーバノード１１０は、複数のノードが抽出された場合に、センサネットワークのトポロジを参照して、各ノードが収容される上位ノードに当該モジュールを配備する。

このため、本実施例に係るサーバノード１１０では、センサネットワークのトポロジが変化した場合でも、モジュールによって集約されるイベントが集合するノードのうちできるだけセンシングデータが採取される下位側のノードにモジュールを分散配備できる。したがって、本実施例に係るサーバノード１１０によれば、センサネットワーク上のノードにモジュールを適切に配備できる結果、センサネットワークのトラフィックを抑制できる。さらに、本実施例に係るサーバノード１１０では、モジュールを分散配備するので、サーバノード１１０に負荷が集中することも防止できる。

なお、図１の例では、サーバノード１１０の下位ノードとしてセンサノード２１０を図示しているが、後述するように、センサノード２１０及びサーバノード１１０間の通信を中継するＧＷノードがサーバノード１１０の下位ノードとして含まれる場合もある。以下では、ルートノードであるサーバノード１１０以外のセンサノード２１０や後述のＧＷノード３１０のことを「下位ノード」と総称する場合がある。

［サーバノードの構成］
続いて、本実施例に係るサーバノードの機能的構成について説明する。図２は、実施例１に係るサーバノード１１０の機能的構成を示すブロック図である。なお、サーバノード１１０は、図２に示す機能部以外にも既知のサーバ装置が有する各種の機能部、例えば各種の入力デバイスや音声出力デバイスなどの機能を有するものとする。

図２に示すように、サーバノード１１０は、モジュール登録部１１１と、モジュール記憶部１１１Ａと、モジュール定義記憶部１１１Ｂと、トポロジ取得部１１２と、トポロジ記憶部１１２Ａとを有する。さらに、サーバノード１１０は、イベント受信部１１３と、イベント記憶部１１４と、モジュール実行部１１５と、発生イベント登録部１１６と、発生イベント情報記憶部１１６Ａとを有する。さらに、サーバノード１１０は、配備先情報記憶部１１７Ａと、配備先決定部１１７と、モジュール送信部１１８とを有する。

モジュール登録部１１１は、モジュールを登録する処理部である。一態様としては、モジュール登録部１１１は、モジュールの開発者によって各種のサービス提供処理のトリガーとなるイベントをフィルタリングまたは集約するようにプログラミングされたモジュールのアップロードを受け付ける。すると、モジュール登録部１１１は、サーバノード１１０にアップロードされたモジュールを後述のモジュール記憶部１１１Ａに登録する。さらに、モジュール登録部１１１は、アップロードされたモジュールに関する定義を開発者が使用する端末装置を介して受け付け、受け付けたモジュールに関する定義を後述のモジュール定義記憶部１１１Ｂに登録する。

モジュール記憶部１１１Ａは、モジュールを記憶する記憶部である。一例としては、モジュール記憶部１１１Ａは、モジュールがアップロードされた場合に、モジュール登録部１１１によってモジュールが登録される。他の一例としては、モジュール記憶部１１１Ａは、センサノード２１０や後述のＧＷノード３１０などの下位ノードにモジュールを配備する場合に、後述のモジュール送信部１１８によって参照される。

一態様としては、モジュール記憶部１１１Ａは、モジュール識別子とバイナリコードが対応付けられたデータを記憶する。ここで言う「モジュール識別子」は、モジュールを識別するための識別子を指す。例えば、Ｃ言語でプログラミングされたモジュールには関数名を付与したり、Ｊａｖａ（登録商標）言語でプログラミングされたモジュールにはクラス名を付与したりするなど、開発に使用されたプログラム言語に応じて識別子を付与することができる。また、「バイナリコード」は、モジュール本体となるコンパイル済みのバイナリデータを指す。

図３は、モジュール記憶部１１１Ａに記憶される情報の構成例を示す図である。図３の例では、４つのモジュール識別子「温度警告」、「平均温度計算」、「平均湿度計算」及び「不快指数計算」とそのバイナリコードとが対応付けられた例を示している。このうち、「温度警告」は、温度が所定値以上になった場合に警告を実行するモジュールのクラス名を指す。このモジュール「温度警告」が下位ノードに配備された場合には、下位ノードからサーバノード１１０に送信されるイベントがフィルタリングされることになる。また、「平均温度計算」は、所定期間の温度の平均を計算するモジュールのクラス名を指し、「平均湿度計算」は、所定期間の湿度の平均を計算するモジュールのクラス名を指す。さらに、「不快指数計算」は、及び平均温度と平均湿度から不快指数を計算するモジュールのクラス名を指す。これらモジュール「平均温度計算」、「平均湿度計算」及び「不快指数計算」が下位ノードに配備された場合には、下位ノードからサーバノード１１０に送信されるイベントが集約されることになる。

なお、図３の例では、モジュールのバイナリコードを記憶する場合を例示したが、必ずしもバイナリ形式でモジュールを記憶する必要はなく、バイナリ形式以外のデータを記憶することとしてもかまわない。例えば、モジュールがスクリプト言語である場合には、スクリプトが記述されたテキストデータを記憶することとしてもよい。また、コンパイル前のソースコードを記憶することとしてもかまわない。この場合には、モジュールがセンサノード２１０等の下位ノードに配備される段階でコンパイルするか、あるいは配備先の下位ノードでコンパイルさせることとすればよい。

モジュール定義記憶部１１１Ｂは、モジュールに関する定義を記憶する記憶部である。一例としては、モジュール定義記憶部１１１Ｂは、モジュールとともにモジュールに関する定義がアップロードされた場合に、モジュール登録部１１１によってモジュールの定義が登録される。他の一例としては、モジュール定義記憶部１１１Ｂは、モジュールの配備先を決定するために、後述の配備先決定部１１７によって参照される。

一態様としては、モジュール定義記憶部１１１Ｂは、モジュール識別子、入力イベント型、出力イベント型及び集約属性名が対応付けられたデータを記憶する。ここで言う「入力イベント型」とは、モジュールによって実行される処理の入力となるイベントの型を指す。また、「出力イベント型」とは、モジュールによって実行された処理の出力となるイベントの型を指す。また、「集約属性名」とは、複数のノードを集約する枠組みである集約属性の名称を指す。

図４は、モジュール定義記憶部１１１Ｂに記憶される情報の構成例を示す図である。図４に示すモジュール「温度警告」の例では、温度イベントが入力されて警告イベントが出力されることを示す。この「温度警告」の場合には、１度の処理で１つの温度イベントしか入力されないので、集約属性名は付与されていない。また、図４に示すモジュール「平均温度計算」の例では、複数の温度イベントが入力されて平均温度イベントが１つ出力されることを示す。この「平均温度計算」の場合には、１度の処理で複数の温度イベントが入力され、同一のセンサノード２１０によってセンシングされた温度が対象となるので、集約属性名として温度センサＩＤが付与されている。さらに、図４に示すモジュール「平均湿度計算」の例についても、モジュール「平均温度計算」の例と同様の理由から、集約属性名として湿度センサＩＤが付与されている。また、図４に示すモジュール「不快指数計算」の例では、平均温度イベント及び平均湿度イベントが入力されて不快指数イベントが出力されることを示す。この「不快指数計算」の場合には、１度の処理で平均温度イベント及び平均湿度イベントが入力され、同一の家に収容されたセンサノード２１０によってセンシングされた温度が対象となるので、集約属性名として家ＩＤが付与されている。

トポロジ取得部１１２は、センサネットワークの接続形態、いわゆるトポロジを取得する処理部である。一態様としては、トポロジ取得部１１２は、センサネットワークに収容されたセンサノード２１０や後述のＧＷノード３１０を含む下位ノードから、当該下位ノードがどの上位ノードに接続されているかを表すノード間の接続情報を取得する。その上で、トポロジ取得部１１２は、下位ノードから取得したノード間の接続情報を後述のトポロジ記憶部１１２Ａに登録する。なお、以下では、下位ノードがＵＰｎＰ（Universal Plug and Play）プロトコル等を用いて上位ノードを自動認識することによって検出した接続情報を取得する場合を想定するが、サーバノード１１０が下位ノードとの接続状況を認識することとしてもよい。

トポロジ記憶部１１２Ａは、センサネットワークのトポロジを記憶する記憶部である。一例としては、トポロジ記憶部１１２Ａは、下位ノードからノード間の接続情報が取得された場合に、トポロジ取得部１１２によってノード間の接続情報がトポロジとして登録される。他の一例としては、トポロジ記憶部１１２Ａは、モジュールの配備先を決定するために、後述の配備先決定部１１７によって参照される。

一態様としては、トポロジ記憶部１１２Ａは、下位ノードＩＤ及び上位ノードＩＤが対応付けられたデータを記憶する。ここで言う「下位ノードＩＤ」は、下位ノードを識別するための識別子を指す。また、「上位ノードＩＤ」は、下位ノードに接続される上位ノードを識別するための識別子を指す。

図５は、トポロジ記憶部１１２Ａに記憶される情報の構成例を示す図である。図５の例では、図１に示したセンサノード２１０Ｘ−１がＸ家に収容された温度センサＸであり、センサノード２１０Ｘ−２がＸ家に収容された湿度センサＸであり、また、センサノード２１０Ｙ−１がＹ家に収容された温湿度センサＹである場合を想定している。図５に示す例では、温度センサＸ、湿度センサＸ及び温湿度センサＹの上位ノードが全てクラウドであるサーバノード１１０であり、センサノード２１０とサーバノード１１０の間にＧＷノード３１０などの中継ノードが介在していないことを示す。

イベント受信部１１３は、イベントを受信する処理部である。一態様としては、イベント受信部１１３は、センサノード２１０や後述のＧＷノード３１０などの下位ノードからイベントを受信すると、当該イベントを後述のイベント記憶部１１４に格納する。このとき、イベント受信部１１３は、下位ノードから受信したイベントを後述の発生イベント登録部１１６にも出力する。なお、イベント受信部１１３では、必ずしもセンサノード２１０によってセンシングされた未加工のイベントが受信されるとは限らず、下位ノードに配備されたモジュールによって加工処理が実行されることにより、加工済みのイベントが受信される場合もある。

イベント記憶部１１４は、イベントを記憶する記憶部である。このイベント記憶部１１４は、イベントの発生をトリガーとしてサービスを提供するサービス提供用のアプリケーションに参照させるために設けられる。

一例としては、イベント記憶部１１４は、下位ノードからイベントが受信された場合に、イベント受信部１１３によってイベントが登録される。他の一例としては、イベント記憶部１１４は、モジュールによってイベントが処理された場合に、後述のモジュール実行部１１５によって処理実行後のイベントが登録される。

一態様としては、イベント記憶部１１４は、イベント型名、イベント発生時刻及びイベント属性が対応付けられたデータを記憶する。ここで言う「イベント型」は、イベントの種類を識別するための識別子を指す。また、「イベント発生時刻」は、イベントが発生した時刻、すなわちセンサノード２１０によってセンシングされた時刻を指す。また、「イベント属性」とは、イベントの性質や由来を指し、例えば、イベントとして採取されるセンシングデータ又はそれが加工処理されたデータの種類、イベントが発生した発生ノードや発生ノードを含む複数のノードを集約する集約属性などの属性データの集合を指す。なお、以下では、イベント属性に含まれる各属性データが属性名と属性値のペアを含んで構成される場合を想定して説明を行う。

図６は、イベント記憶部１１４に記憶される情報の構成例を示す図である。図６に示す１番目のレコードは、２０１１年７月１３日の１２時にＸ家の温度センサＸによって２８度の温度が計測されたというイベントを示す。また、図６に示す２番目のレコードは、２０１１年７月１３日の１２時００分１０秒にＸ家の湿度センサＸによって５０％の湿度が計測されたというイベントを示す。図６に示す３番目のレコードは、２０１１年７月１３日の１２時００分２０秒にＹ家の温湿度センサＹによって３０度の温度が計測されたというイベントを示す。図６に示す４番目のレコードは、２０１１年７月１３日の１２時００分３０秒にＹ家の温湿度センサＹによって７０％の湿度が計測されたというイベントを示す。

このように、イベント記憶部１１４に記憶されたイベントは、サービス提供用のアプリケーションによってサービス提供処理を実行するトリガーとして参照される。なお、図６の例では、センサノード２１０によってセンシングされた未加工のイベントを例示したが、モジュールが下位ノードに配備された場合には、モジュールによって加工処理がなされた新たなイベントも格納されることになる。

モジュール実行部１１５は、サーバノード１１０に配備されたモジュールの実行制御を行う処理部である。一態様としては、モジュール実行部１１５は、イベント受信部１１３によってイベントが受信された場合に、受信されたイベントを入力イベント型とするモジュールがサーバノード１１０に配備されているか否かを判定する。このとき、モジュール実行部１１５は、モジュールがサーバノード１１０に配備されている場合には、当該モジュールを実行することによってイベントの加工処理を実行する。その後、モジュール実行部１１５は、モジュールによって加工処理が実行されたデータを新たなイベントとしてイベント記憶部１１４に格納する。

発生イベント登録部１１６は、センサノード２１０やＧＷノード３１０などの下位ノードで発生した発生イベントを登録する処理部である。一態様としては、発生イベント登録部１１６は、イベント受信部１１３によってイベントが受信された場合に、受信されたイベントが発生イベントとして後述の発生イベント情報記憶部１１６Ａに既に登録されているか否かを判定する。このとき、発生イベント登録部１１６は、発生イベントとして未だ登録されていない場合には、下位ノードから受信したイベントを後述の発生イベント情報記憶部１１６Ａに登録する。

発生イベント情報記憶部１１６Ａは、発生イベントに関する情報を記憶する記憶部である。この発生イベント情報記憶部１１６Ａは、センサノード２１０またはＧＷノード３１０などの下位ノードでどのようなイベントが発生しているのかを管理するために設けられる。

一例としては、発生イベント情報記憶部１１６Ａは、下位ノードからイベントが受信された場合に、発生イベント登録部１１６によって発生イベントが登録される。他の一例としては、発生イベント情報記憶部１１６Ａは、モジュールの配備先を決定するために、後述の配備先決定部１１７によって参照される。

一態様としては、発生イベント情報記憶部１１６Ａは、発生ノードＩＤ、発生イベント型及び発生イベント属性が対応付けられたデータを記憶する。ここで言う「発生ノードＩＤ」は、発生ノードを識別するための識別子を指す。また、「発生イベント型」は、発生イベントの種類を識別するための識別子を指す。また、「発生イベント属性」は、発生ノードのイベント属性を指す。

図７は、発生イベント情報記憶部１１６Ａに記憶される情報の構成例を示す図である。図７に示す１番目のレコードは、Ｘ家の温度センサＸで温度が計測されるというイベントが発生していることを示す。また、図７に示す２番目のレコードは、Ｘ家の湿度センサＸで湿度が計測されるというイベントが発生していることを示す。図７に示す３番目のレコードは、Ｙ家の温湿度センサＹで温度が計測されるというイベントが発生していることを示す。図７に示す４番目のレコードは、Ｙ家の温湿度センサＹで湿度が計測されるというイベントが発生していることを示す。なお、図７の例では、発生イベントとしてセンサノード２１０によってセンシングされた未加工のイベントを例示したが、モジュールが下位ノードに配備された場合には、モジュールによって加工処理がなされた新たなイベントも発生イベントとして格納される。

配備先情報記憶部１１７Ａは、モジュールの配備先に関する情報を記憶する記憶部である。一例としては、配備先情報記憶部１１７Ａは、センサネットワークのトポロジに変化があった場合に、後述の配備先決定部１１７によってアクセスされる。

一態様としては、配備先情報記憶部１１７Ａは、モジュール識別子、入力イベント型、集約属性名、発生イベント属性、発生ノードＩＤ及び配備先ノードＩＤが対応付けられたデータを記憶する。ここで言う「配備先ノードＩＤ」は、モジュールが配備されるセンサノード２１０、後述のＧＷノード３１０またはサーバノード１１０を識別するための識別子を指す。

図８は、配備先情報記憶部１１７Ａに記憶される情報の構成例を示す図である。この図８の例では、センサネットワークのトポロジに変化が検出されて後述の配備先決定部１１７によるモジュールの配備先の決定が開始された段階のテーブル例を図示している。すなわち、図８に示すように、全カラムのうちモジュール識別子、入力イベント型及び集約属性名がモジュール定義記憶部１１１Ｂから複写された段階のテーブル例が図示されている。以降の配備先ノードＩＤを始めとする残りのカラムが埋められる遷移については、図９や図１１などを用いて後述する。

配備先決定部１１７は、モジュールの配備先を決定する処理部である。一態様としては、配備先決定部１１７は、トポロジ記憶部１１２Ａが更新された場合、すなわちセンサネットワークのトポロジに変化があった場合に、以下に説明する処理を実行する。

これを説明すると、配備先決定部１１７は、モジュール定義記憶部１１１Ｂに記憶されたモジュールの定義のうちモジュール識別子、入力イベント型及び集約属性名のカラムデータを配備先情報記憶部１１７Ａの該当カラムに書き込む。このとき、配備先情報記憶部１１７Ａは、図８に示すように、発生イベント属性、発生ノードＩＤ及び配備先ノードＩＤのカラムがブランクの状態となる。

続いて、配備先決定部１１７は、発生イベント情報記憶部１１６Ａに記憶された発生ノードＩＤのうち、発生イベント型が未配備のモジュールの入力イベント型に含まれる発生ノードＩＤを抽出する。さらに、配備先決定部１１７は、前述のように抽出した発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。その後、配備先決定部１１７は、抽出結果として得られた発生ノードＩＤ及び発生ノードＩＤに対応付けられた発生イベント属性を配備先情報記憶部１１７Ａに書き込む。

このとき、配備先決定部１１７は、発生ノードＩＤが配備先情報記憶部１１７Ａに複数登録された場合には、次のような処理を実行する。すなわち、配備先登録部１１７は、トポロジ記憶部１１２Ａに記憶された上位ノードＩＤのうち各発生ノードＩＤに対応するセンサノード２１０又は後述のＧＷノード３１０が下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。そして、配備先決定部１１７は、前述のように抽出したノードＩＤを配備先ノードＩＤのカラムに登録する。

また、配備先決定部１１７は、発生ノードＩＤが配備先情報記憶部１１７Ａに１つ登録された場合には、モジュールを配備するノードに選択の余地がないので、先に抽出結果として得られた発生ノードＩＤを配備先ノードＩＤのカラムに登録する。

このようにして配備先情報記憶部１１７Ａに配備先ノードＩＤが登録されると、モジュール記憶部１１１Ａに記憶されたモジュールが後述のモジュール送信部１１８によって配備先ノードＩＤに対応するノードへ送信される。

その後、配備先決定部１１７は、モジュールの配備によって下位ノードから新たに取得される発生イベントが発生イベント情報記憶部１１６Ａに更新されるまで待機してから、未配備のモジュールがなくなるまでモジュールの配備を繰り返し実行する。

なお、発生ノードＩＤが配備先情報記憶部１１７Ａに１つも登録されなかった場合には、下位ノードから通知される発生イベントが発生イベント情報記憶部１１６Ａに登録し切れていない可能性がある。この場合には、配備先決定部１１７は、発生イベント情報記憶部１１６Ａが更新されるまで待機してからモジュールの配備を繰り返し実行する。

モジュール送信部１１８は、センサノード２１０または後述のＧＷノード３１０などの下位ノードにモジュールを送信する処理部である。一態様としては、モジュール送信部１１８は、配備先決定部１１７によって配備先ノードＩＤが配備先情報記憶部１１７Ａに登録されると、モジュール記憶部１１１Ａに記憶されたモジュールを配備先ノードＩＤに対応するノードへ送信する。

（１）モジュール配備の具体例１
ここで、図９〜図１２を用いて、モジュール配備の具体例１について説明する。図９は、図８に示した配備先情報記憶部１１７Ａからの配備状況の遷移を示す図である。図１０は、図７に示した発生イベント情報記憶部１１６Ａからのイベント発生状況の遷移を示す図である。図１１は、図９に示した配備先情報記憶部１１７Ａからの配備状況の遷移を示す図である。図１２は、図１０に示した発生イベント情報記憶部１１６Ａからのイベント発生状況の遷移を示す図である。

モジュールの配備が開始されると、図７に示した発生イベント情報記憶部１１６Ａと図８に示した配備先情報記憶部１１７Ａとの間で発生イベント型及び入力イベント型のカラムが配備先決定部１１７によって比較される。このとき、モジュール「温度警告」及びモジュール「平均温度計算」の入力イベント型と発生ノードＩＤ「温度センサＸ」及び発生ノードＩＤ「温湿度センサＹ」の発生イベント型が「温度」で一致する。また、モジュール「平均湿度計算」の入力イベント型と発生ノードＩＤ「湿度センサＸ」及び発生ノードＩＤ「温湿度センサＹ」の発生イベント型が「湿度」で一致する。

よって、モジュール「温度警告」、「平均温度計算」及び「平均湿度計算」に関し、発生ノードＩＤ「温度センサＸ」、「湿度センサＸ」及び「温湿度センサＹ」が配備先決定部１１７によって抽出される。

さらに、未配備のモジュール「温度警告」、「平均温度計算」及び「平均湿度計算」に定義された集約属性と、発生ノードＩＤ「温度センサＸ」、「湿度センサＸ」及び「温湿度センサＹ」に対応付けられた発生イベント属性とが配備先決定部１１７によって比較される。

このうち、モジュール「温度警告」は、イベントの集約処理を実行するものではなく、イベントのフィルタリング処理を実行するモジュールである。このように、イベントがフィルタリング処理される場合には、モジュールに集約属性名が定義されず、同一の下位ノードがフィルタリングの対象となるので、モジュール識別子と発生ノードＩＤが一対一に対応する。この場合には、発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードは抽出されないが、イベントが発生するノードにモジュールを配備するのが最適である。よって、例外として、発生ノードＩＤ間で未配備のモジュールに定義された集約属性名と同一の集約属性に属する属性値が同一であると見做す。したがって、図９に示すように、イベントが発生している発生ノードである「温度センサＸ」及び「温湿度センサＹ」がモジュール「温度警告」の配備先とされる。

一方、モジュール「平均温度計算」及び「平均湿度計算」は、いずれもイベントの集約処理を実行するモジュールである。このように、イベントが集約処理される場合には、モジュールに集約属性名は定義されるが、平均値の計算では同一の下位ノードが集約処理の対象となる結果、モジュール識別子と発生ノードＩＤが一対一に対応することになる。このため、発生ノードＩＤ間でモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードは抽出されるが、発生ノードＩＤが複数抽出されることはない。よって、図９に示すように、イベントが発生している発生ノードである「温度センサＸ」及び「温湿度センサＹ」がモジュール「平均温度計算」及び「平均湿度計算」の配備先と決定される。

このように、図９に示したモジュール「温度警告」、「平均温度計算」及び「平均湿度計算」が温度センサＸ、湿度センサＸ及び温湿度センサＹの発生ノードに配備される。これによって、発生ノードによって温度イベント及び湿度イベントが加工処理された温度警告イベント、平均温度イベント及び平均湿度イベントが新たにサーバノード１１０へ通知される。それゆえ、図１０に示す網掛け部分のように、発生イベント登録部１１６によって発生イベント型「温度警告」、「平均温度計算」及び「平均湿度計算」の発生イベントが発生イベント情報記憶部１１６Ａへ登録される。

図１０に示す発生イベントが発生イベント情報記憶部１１６Ａに新たに追加されると、配備先決定部１１７によって次のような処理が実行される。すなわち、図１０に示す発生イベント情報記憶部１１６Ａのレコードのうち発生イベント型と、図９に示す配備先情報記憶部１１７Ａに記憶された配備先情報のうち未配備であるモジュールの入力イベント型とのカラムが配備先決定部１１７によって比較される。

このとき、モジュール「不快指数計算」の入力イベント型と発生ノードＩＤ「温度センサＸ」及び発生ノードＩＤ「湿度センサＸ」の発生イベント型とが「平均温度」及び「平均湿度」で一致する。また、モジュール「不快指数計算」の入力イベント型と発生ノードＩＤ「温湿度センサＹ」の発生イベント型とが「平均温度」及び「平均湿度」で一致する。よって、モジュール「不快指数計算」に関し、発生ノードＩＤ「温度センサＸ」、「湿度センサＸ」及び「温湿度センサＹ」の３つの発生ノードが配備先決定部１１７によって抽出される。

ここで、発生ノードＩＤ「温度センサＸ」、「湿度センサＸ」及び「温湿度センサＹ」の発生ノード間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードが配備先決定部１１７によって抽出される。

かかるモジュール「不快指数計算」は、イベントの集約処理を実行するモジュールであるので、図４に示すように、モジュール「不快指数計算」に集約属性の属性名「家ＩＤ」が定義されている。一方、発生ノードＩＤ「温度センサＸ」及び「湿度センサＸ」の発生イベント属性には、図１０に示すように、属性名「家ＩＤ」及び属性値「Ｘ家」のペアを含んで構成される集約属性の属性データが含まれる。また、発生ノードＩＤ「温湿度センサＹ」の発生イベント属性には、図１０に示すように、属性名「家ＩＤ」及び属性値「Ｙ家」のペアを含んで構成される集約属性の属性データが含まれる。

これら発生ノードＩＤ「温度センサＸ」、「湿度センサＸ」及び「温湿度センサＹ」の発生ノードは、いずれも集約属性の属性名が「家ＩＤ」である。その一方で、発生ノードＩＤ「温度センサＸ」及び「湿度センサＸ」は、集約属性の属性値「Ｘ家」であるのに対し、発生ノードＩＤ「温湿度センサＹ」は、集約属性の属性値「Ｙ家」である。

したがって、モジュール「不快指数計算」は、Ｘ家用及びＹ家用のモジュールとして独立に配備される。すなわち、図１１に示す網掛け部分のように、モジュール「不快指数計算」に発生ノードＩＤ「温度センサＸ」及び「湿度センサＸ」とその発生イベント属性とが配備先情報記憶部１１７Ａの該当カラムに書き込まれる。さらに、図１１に示す網掛け部分のように、モジュール「不快指数計算」に発生ノードＩＤ「温湿度センサＹ」とその発生イベント属性とが配備先情報記憶部１１７Ａの該当カラムに書き込まれる。

このうち、Ｘ家用のモジュール「不快指数計算」は、発生ノードＩＤ「温度センサＸ」及び「湿度センサＸ」の２つの発生ノードが存在する。このため、図５に示したトポロジ記憶部１１２Ａに記憶された上位ノードＩＤのうち発生ノードＩＤ「温度センサＸ」及び「湿度センサＸ」の両方の発生ノードが下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。図５の例で言えば、発生ノードＩＤ「温度センサＸ」及び「湿度センサＹ」の発生ノードは、いずれもクラウドであるサーバノード１１０に接続されており、発生ノード及びサーバノード１１０の間に後述のＧＷノード３１０等の中継ノードが介在していない。このため、図１１に示すように、Ｘ家用のモジュール「不快指数計算」の配備先ノードＩＤのカラムには「クラウド」が格納される。これによって、Ｘ家用のモジュール「不快指数計算」がサーバノード１１０に配備されることになる。

一方、Ｙ家用のモジュール「不快指数計算」は、発生ノードＩＤ「温湿度センサＹ」しか存在しない。この場合には、発生ノードである「温湿度センサＹ」にモジュールを配備するのが最適である。このため、図１１に示すように、Ｙ家用のモジュール「不快指数計算」の配備先ノードＩＤのカラムには「温湿度センサＹ」が格納される。これによって、Ｙ家用のモジュール「不快指数計算」がセンサノード２１０Ｙ−１に配備されることになる。

このように、図１１に示したＸ家用のモジュール「不快指数計算」がクラウドに配備されるともに、Ｙ家用のモジュール「不快指数計算」が温湿度センサＹに配備される。これによって、クラウドであるサーバノード１１０によって平均温度イベント及び平均湿度イベントが加工処理される。また、温湿度センサＹによって平均温度イベント及び平均湿度イベントが加工処理された不快指数イベントが新たにサーバノード１１０へ通知される。それゆえ、図１２に示す網掛け部分のように、発生ノードＩＤが「クラウド」となった発生イベント型「不快指数」の発生イベントが発生イベント情報記憶部１１６Ａへ登録される。さらに、発生ノードＩＤが「温湿度センサＹ」となった発生イベント型「不快指数」の発生イベントが発生イベント情報記憶部１１６Ａへ登録される。

（２）モジュール配備の具体例２
次に、図１３〜図１６を用いて、モジュール配備の具体例２について説明する。図１３は、図１に示したセンサネットワークにおけるトポロジ変更の一例を示す図である。図１４は、図５に示したトポロジ記憶部１１２Ａからのトポロジの遷移を示す図である。図１５は、図９に示した配備先情報記憶部１１７Ａからの配備状況の遷移を示す図である。図１６は、図１０に示した発生イベント情報記憶部１１６Ａからのイベント発生状況の遷移を示す図である。

図１３に示すセンサネットワークシステム３は、図１に示したセンサネットワークシステム１と比較して、サーバノード１１０とセンサノード２１０Ｘ−１及び２１０Ｘ−２との間にＧＷノード３１０Ｘがさらに追加された点が異なる。さらに、センサネットワークシステム３は、サーバノード１１０とセンサノード２１０Ｙ−１との間にＧＷノード３１０Ｙがさらに追加された点が異なる。なお、以下では、Ｘ家に収容されているＧＷノード３１０Ｘがホームゲートウェイであり、Ｙ家に収容されているＧＷノード３１０Ｙがモバイルゲートウェイである場合を想定する。

これらセンサノード２１０Ｘ−１及び２１０Ｘ−２とＧＷノード３１０Ｘとの間は、ホームネットワーク５Ｘを介して通信可能に接続される。また、センサノード２１０Ｙ−１とＧＷノード３１０Ｙとの間は、無線ＬＡＮ（Local Area Network）５Ｙを介して通信可能に接続される。

このように、ＧＷノード３１０Ｘ及び３１０Ｙが追加された場合には、センサネットワークのトポロジが変化する。図１４の例で言えば、図５に示した例ではクラウドであるサーバノード１１０に直接接続されていた温度センサＸ及び湿度センサＸがホームＧＷ−Ｘを介してサーバノード１１０に接続される接続形態に変化している。さらに、図１４の例で言えば、図５に示した例ではクラウドであるサーバノード１１０に直接接続されていた温湿度センサＹがモバイルＧＷ−Ｙを介して接続される接続形態に変化している。なお、図１４の例では、図１３に示したＧＷノード３１０ＸがＸ家に収容されたホームＧＷ−Ｘであり、また、ＧＷノード３１０ＹがＹ家に収容されたモバイルＧＷ−Ｙである場合を想定している。

そして、図１４に示すように、センサネットワークのトポロジが変化した場合には、図１１に示す配備先情報記憶部１１７Ａに記憶されていたモジュールの配備設定は破棄され、図８に示すモジュールの配備開始状態から改めてモジュールが再配備される。

なお、図８に示したモジュールの配備開始段階から図９に示したモジュールの配備状況に遷移するまでは、上記の（１）モジュール配備の具体例１と同様であるので、その説明は省略する。また、図７に示したイベント発生状況から図１０に示すイベント発生状況に遷移するまでについても、上記の（１）モジュール配備の具体例１と同様であるので、その説明は省略する。

図１０に網掛けで示した発生イベントが発生イベント情報記憶部１１６Ａに新たに追加されると、図９に示したモジュールの配備状況が図１５に示すモジュールの配備状況に更新される。ここで、図１５に示すモジュールの配備状況は、図１１に示したモジュールの配備状況と比べて、Ｘ家用のモジュール「不快指数計算」がクラウドではなく、ホームＧＷ−Ｘに配備される点が異なる。

このように、Ｘ家用のモジュール「不快指数計算」がホームＧＷ−Ｘに配備されるのは、発生ノードＩＤ「温度センサＸ」及び「湿度センサＸ」の両方の発生ノードが収容される上位ノードのうちホームＧＷ−Ｘの方がクラウドよりも下位ノード側にあるからである。一方、Ｙ家用のモジュール「不快指数計算」は、モバイルＧＷ−Ｙの追加に関係なく、温湿度センサＹに配備される。これは、モバイルＧＷ−Ｙが追加されても、発生ノードが温湿度センサＹだけであることに変化がないからである。

そして、図１５に示すように、Ｘ家用のモジュール「不快指数計算」の配備先がクラウドからホームＧＷ−Ｘに変わると、クラウドで加工処理されていた平均温度イベント及び平均湿度イベントがホームＧＷ−Ｘによって加工処理されるようになる。これに伴って、図１６に示す網掛け部分のように、発生ノードＩＤが「ホームＧＷ−Ｘ」となった発生イベント型「不快指数」の発生イベントが発生イベント情報記憶部１１６Ａへ登録される。

なお、モジュール登録部１１１、トポロジ取得部１１２、イベント受信部１１３、モジュール実行部１１５、発生イベント登録部１１６、配備先決定部１１７及びモジュール送信部１１８には、各種の集積回路や電子回路を採用できる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。

また、上記のモジュール記憶部１１１Ａ、モジュール定義記憶部１１１Ｂ、トポロジ記憶部１１２Ａ、イベント記憶部１１４、発生イベント情報記憶部１１６Ａ及び配備先情報記憶部１１７Ａなどの記憶部には、半導体メモリ素子や記憶装置を採用できる。例えば、半導体メモリ素子としては、ＶＲＡＭ（Video Random Access Memory）、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などが挙げられる。また、記憶装置としては、ハードディスク、光ディスクなどの記憶装置が挙げられる。

［センサノードの構成］
次に、本実施例に係るセンサノードの機能的構成について説明する。図１７は、実施例１に係るセンサノード２１０の機能的構成を示すブロック図である。図１７に示すセンサノード２１０は、センサ情報受信部２１１と、モジュール受信部２１２と、モジュール実行部２１３と、イベント送信部２１４と、トポロジ検出部２１５と、トポロジ送信部２１６とを有する。

センサ情報受信部２１１は、センサノード２１０に内蔵または付設されたセンサデバイスからセンサ情報を受信する処理部である。一態様としては、センサ情報受信部２１１は、センサノード２１０に温度センサが内蔵されている場合には、温度センサによって計測された温度を受信する。他の一態様としては、センサ情報受信部２１１は、センサノード２１０に湿度センサが内蔵されている場合には、湿度センサによって計測された湿度を受信する。なお、センサノード２１０に複数のセンサデバイスが内蔵されている場合には、各々のセンサデバイスに対応してセンサ情報受信部２１１が設けられる。

モジュール受信部２１２は、サーバノード１１０からモジュールを受信する処理部である。このモジュール受信部２１２によって受信されたモジュールは、モジュールの実行制御を行うモジュール実行部２１３に出力される。

モジュール実行部２１３は、センサノード２１０に配備されたモジュールの実行制御を行う処理部である。一態様としては、モジュール実行部２１３は、センサ情報受信部２１１によってセンサ情報が受信された場合に、受信されたセンサ情報を入力イベント型とするモジュールがセンサノード２１０に配備されているか否かを判定する。このとき、モジュール実行部２１３は、モジュールがセンサノード２１０に配備されている場合には、当該モジュールを実行することによってイベントの加工処理を実行する。その後、モジュール実行部２１３は、モジュールによって加工処理が実行されたデータを新たなイベントとしてイベント送信部２１４へ出力する。なお、モジュールがセンサノード２１０に配備されていない場合には、センサ情報を加工処理せずにそのままイベント送信部２１４へ出力する。

イベント送信部２１４は、イベントを上位ノードに送信する処理部である。一態様としては、イベント送信部２１４は、モジュール実行部２１３によって加工処理されたイベント、あるいはセンサ情報受信部２１１によってセンサデバイスから受信されたセンサ情報を上位ノードに送信する。このとき、イベント送信部２１４は、センサ情報を上位ノードに送信する場合には、発生ノードであるセンサノード２１０のノードＩＤ、自装置を含む複数のノードを集約する集約属性の属性名及び属性値をセンサ情報に付加する。その上で、イベント送信部は、センサ情報とともに発生ノードのノードＩＤ及び集約属性を含むイベントを上位ノードに送信する。

ここで、上記の「集約属性」の属性名及び属性値は、センサノード２１０の製造段階でデバイスドライバなどに組み込んでおくことができる。例えば、センサデバイスが温度センサ、湿度センサや温湿度センサである場合には、温度や湿度が計測される枠組みである「家ＩＤ」を始め、「部屋ＩＤ」や「階ＩＤ」などの集約属性をイベントに付加するようにデバイスドライバを構成しておく。その上で、センサノード２１０がサーバノード１１０との間で通信コネクションが確立された段階で、既にサービスに加入している他のセンサノード２１０に先だって付与されている家ＩＤの属性値をサーバノード１１０から自動的に取得することもできる。なお、サーバノード１１０にＸ家またはＹ家の間取り等が登録されている場合には、「家ＩＤ」の他、「部屋ＩＤ」や「階ＩＤ」などの集約属性の属性値をサーバノード１１０から自動的に取得することもできる。

トポロジ検出部２１５は、センサノード２１０がどの上位ノードに接続されているかを表すノード間の接続情報をトポロジとして検出する処理部である。一態様としては、トポロジ検出部２１５は、ＵＰｎＰプロトコル等を用いて、センサノード２１０と同一のローカルネットワーク内に存在するＧＷノード３１０を認識したり、サーバノード１１０からＧＷノード３１０の存在の通知を受けたりすることによってトポロジを検出する。なお、サーバノード１１０とのネットワーク接続の確立は、サーバノード１１０のＵＲＬ等のアドレスを設定しておくことにより実現できる。

トポロジ送信部２１６は、トポロジ検出部２１５によって検出されたトポロジをサーバノード１１０に送信する処理部である。一態様としては、トポロジ送信部２１６は、センサノード２１０が接続されている上位ノードのノードＩＤをサーバノード１１０に送信する。

［ＧＷノードの構成］
次に、本実施例に係るＧＷノードの機能的構成について説明する。図１８は、実施例１に係るＧＷノード３１０の機能的構成を示すブロック図である。図１８に示すＧＷノード３１０は、イベント受信部３１１と、モジュール受信部３１２と、モジュール実行部３１３と、イベント送信部３１４と、トポロジ検出部３１５と、トポロジ送信部３１６とを有する。

イベント受信部３１１は、イベントを受信する処理部である。一態様としては、イベント受信部３１１は、下位ノードであるセンサノード２１０や他のＧＷノード３１０からイベントを受信する。

モジュール受信部３１２は、サーバノード１１０からモジュールを受信する処理部である。このモジュール受信部３１２によって受信されたモジュールは、モジュールの実行制御を行うモジュール実行部３１３に出力される。

モジュール実行部３１３は、ＧＷノード３１０に配備されたモジュールの実行制御を行う処理部である。一態様としては、モジュール実行部３１３は、イベント受信部３１１によってイベントが受信された場合に、受信されたイベントを入力イベント型とするモジュールがＧＷノード３１０に配備されているか否かを判定する。このとき、モジュール実行部３１３は、モジュールがＧＷノード３１０に配備されている場合には、当該モジュールを実行することによってイベントの加工処理を実行する。その後、モジュール実行部３１３は、モジュールによって加工処理が実行されたデータを新たなイベントとしてイベント送信部３１４へ出力する。なお、モジュールがＧＷノード３１０に配備されていない場合には、イベントを加工処理せずにそのままイベント送信部３１４へ出力する。

イベント送信部３１４は、イベントを上位ノードに送信する処理部である。一態様としては、イベント送信部３１４は、モジュール実行部３１３によって加工処理されたイベント、あるいはイベント受信部３１１によって受信されたイベントを上位ノードに送信する。

トポロジ検出部３１５は、ＧＷノード３１０がどの上位ノードに接続されているかを表すノード間の接続情報をトポロジとして検出する処理部である。一態様としては、トポロジ検出部３１５は、ＵＰｎＰプロトコル等を用いて、ＧＷノード３１０と同一のローカルネットワーク内に存在する他のＧＷノード３１０を認識したり、サーバノード１１０から他のＧＷノード３１０の存在の通知を受けたりすることによってトポロジを検出する。なお、サーバノード１１０とのネットワーク接続の確立は、サーバノード１１０のＵＲＬ等のアドレスを設定しておくことにより実現できる。

トポロジ送信部３１６は、トポロジ検出部３１５によって検出されたトポロジをサーバノード１１０に送信する処理部である。一態様としては、トポロジ送信部３１６は、ＧＷノード３１０が接続されている上位ノードのノードＩＤをサーバノード１１０に送信する。

［処理の流れ］
次に、本実施例に係るセンサネットワークシステムの処理の流れについて説明する。なお、ここでは、センサノード２１０によって実行される（１）全体処理を説明した後に、サーバノード１１０によって実行される（２）モジュール配備処理を説明することとする。

（１）全体処理
図１９は、実施例１に係るセンサノード２１０における全体処理の手順を示すフローチャートである。この全体処理は、センサノード２１０の電源がＯＮ状態である限り、繰り返し実行される。

図１９に示すように、新たな上位ノードを検出した場合（ステップＳ１０１肯定）には、センサノード２１０は、当該上位ノードのノードＩＤをサーバノード１１０へ送信する（ステップＳ１０２）。なお、新たな上位ノードを検出しなかった場合（ステップＳ１０１否定）には、ステップＳ１０２の処理を実行せずにステップＳ１０３の処理へ移行する。

続いて、サーバノード１１０からモジュールを受信した場合（ステップＳ１０３肯定）には、センサノード２１０は、サーバノード１１０から受信したモジュールを配備する（ステップＳ１０４）。なお、モジュールを受信しなかった場合（ステップＳ１０３否定）には、ステップＳ１０４の処理を実行せずにステップＳ１０５の処理へ移行する。

そして、センサデバイスからセンサ情報を受信した場合（ステップＳ１０５肯定）には、センサノード２１０は、当該センサ情報を入力イベント型とするモジュールが配備されているか否かをさらに判定する（ステップＳ１０６）。なお、センサ情報を受信しなかった場合（ステップＳ１０５否定）には、ステップＳ１０１の処理に戻る。

このとき、モジュールが配備されている場合（ステップＳ１０６肯定）には、センサノード２１０は、モジュールを実行することによってイベントを加工処理する（ステップＳ１０７）。そして、センサノード２１０は、加工処理が実行されたイベントを上位ノードへ送信する（ステップＳ１０８）。

一方、モジュールが配備されていない場合（ステップＳ１０６否定）には、センサノード２１０は、センサデバイスから受信したセンサ情報に発生ノードＩＤや集約属性などを付加した上で上位ノードへ送信する（ステップＳ１０９）。

このようにして、センサノード２１０は、上記のステップＳ１０１〜ステップＳ１０９までの処理を電源がＯＦＦ状態になるまで繰り返し実行する。

なお、ここでは、センサノード２１０の全体処理について説明したが、中継ノードであるＧＷノード３１０によって実行される全体処理も一部を除き同様である。すなわち、ＧＷノード３１０の場合には、上記のステップＳ１０５においてセンサ情報の代わりにイベントが受信される点が相違する点を除き、センサノード２１０と同様である。

（２）モジュール配備処理
続いて、本実施例に係るモジュール配備処理について説明する。図２０は、実施例１に係るモジュール配備処理の手順を示すフローチャートである。このモジュール配備処理は、センサネットワークのトポロジが変化した場合に処理が起動される。

図２０に示すように、サーバノード１１０は、発生イベント情報記憶部１１６Ａが更新されるのを待機する（ステップＳ２０１）。そして、発生イベント情報記憶部１１６Ａが更新されると、全てのモジュールの配備が終了したか否かが判断されるが（ステップＳ２０２）、ここではいずれのモジュールについても処理が終了していないので（ステップＳ２０２否定）、ステップＳ２０３の処理へ移行する。

続いて、サーバノード１１０は、モジュール定義記憶部１１１Ｂに記憶されたモジュールの定義のうちモジュール識別子、入力イベント型及び集約属性名のカラムデータを配備先情報記憶部１１７Ａの該当カラムに格納する（ステップＳ２０３）。

そして、サーバノード１１０は、ステップＳ２０３の処理を実行後に、下記に説明するステップＳ２０４の処理を実行する。すなわち、サーバノード１１０は、発生イベント情報記憶部１１６Ａに記憶された発生ノードＩＤのうち、発生イベント型が未配備のモジュールの入力イベント型に含まれる発生ノードＩＤを抽出する。さらに、サーバノード１１０は、前述のように抽出した発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。

その後、サーバノード１１０は、抽出結果として得られた発生ノードＩＤ及び発生ノードＩＤに対応付けられた発生イベント属性を配備先情報記憶部１１７Ａに書き込む（ステップＳ２０５）。

このとき、発生ノードＩＤの数が「０」である場合（ステップＳ２０６肯定）には、下位ノードから通知される発生イベントが発生イベント情報記憶部１１６Ａに登録し切れていない可能性がある。この場合には、ステップＳ２０２の処理に移行する。

ここで、発生ノードＩＤの数が複数である場合（ステップＳ２０７肯定）には、下記に説明するステップＳ２０８の処理を実行する。すなわち、サーバノード１１０は、トポロジ記憶部１１２Ａに記憶された上位ノードＩＤのうち各発生ノードＩＤに対応するセンサノード２１０又はＧＷノード３１０が下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。そして、サーバノード１１０は、前述のように抽出したノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

また、発生ノードＩＤの数が１つである場合（ステップＳ２０７否定）には、サーバノード１１０は、モジュールを配備するノードに選択の余地がないので、先に抽出結果として得られた発生ノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

続いて、サーバノード１１０は、モジュール記憶部１１１Ａに記憶されたモジュールを配備先ノードＩＤに対応するノードへ送信する（ステップＳ２１０）。そして、サーバノード１１０は、発生イベント情報記憶部１１６Ａが更新されるのを待機し（ステップＳ２１１）、ステップＳ２０２の処理に戻る。

その後、サーバノード１１０は、全てのモジュールの配備が終了するまで（ステップＳ２０２否定）、上記のステップＳ２０３〜ステップＳ２１１までの処理を繰り返し実行する。そして、全てのモジュールの配備が終了すると（ステップＳ２０２肯定）、処理を終了する。

［実施例１の効果］
上述してきたように、本実施例に係るサーバノード１１０では、センサネットワークのトポロジが変化した場合でも、モジュールによって集約されるイベントが集合するノードのうちできるだけセンシングデータが採取される下位側のノードにモジュールを分散配備できる。したがって、本実施例に係るサーバノード１１０によれば、センサネットワーク上のノードにモジュールを適切に配備できる結果、センサネットワークのトラフィックを抑制できる。さらに、本実施例に係るサーバノード１１０では、モジュールを分散配備するので、サーバノード１１０に負荷が集中することも防止できる。

また、本実施例に係るサーバノード１１０は、各ノードが収容される上位ノードのうち最下位のノードに当該モジュールを配備する。このため、本実施例に係るサーバノード１１０では、モジュールによって集約されるイベントが集合するノードの中で最もイベントの発生ノードに近いノードにモジュールを配備できる。それゆえ、本実施例に係るサーバノード１１０によれば、モジュールの分散配備を適切に実行できる。

さて、上記の実施例１では、イベントを加工処理するモジュールをできるだけ下位のノードに配備することによってネットワークトラフィックを抑制する例について説明したが、必ずしもモジュールが配備される下位ノードでモジュールを実行できるとは限らない。そこで、本実施例では、下位ノードがモジュールを実行可能な場合に限ってモジュールを配備する方法について説明する。

［サーバノードの構成］
図２１は、実施例２に係るサーバノード１２０の機能的構成を示すブロック図である。図２１に示すサーバノード１２０は、図２に示したサーバノード１１０に比べて、トポロジ取得部１２１及び配備先決定部１２２によって実行される処理の一部と、トポロジ記憶部１２１Ａに記憶される情報とが相違する。なお、以下では、上記の実施例１と同様の機能を発揮する機能部については同一の符号を付し、その説明を省略することとする。

トポロジ取得部１２１は、図２に示したトポロジ取得部１１２に比べて、下位ノードがどの上位ノードに接続されているかを表すノード間の接続情報を取得する点は共通し、下位ノードがイベントの加工処理を実行可能であるか否かを示す実行可能フラグをさらに取得する点が相違する。

トポロジ記憶部１２１Ａは、図２に示したトポロジ記憶部１１２Ａに比べて、下位ノードＩＤ及び上位ノードＩＤとともに、実行可否フラグがさらに対応付けられている点が相違する。ここで、「実行可否フラグ」とは、下位ノードがモジュールを実行可能であるか否かを表すフラグを指し、例えば、「true」または「false」の真偽値が採用される。図２２は、トポロジ記憶部１２１Ａに記憶される情報の構成例を示す図である。図２２の例では、温度センサＸ、湿度センサＸ及び温湿度センサＹの全ての下位ノードでモジュールが実行できず、その上位ノードであるホームＧＷ−Ｘ及びモバイルＧＷ−Ｙと、ルートノードであるクラウドとでしかモジュールが実行できないことを示す。

配備先決定部１２２は、図２に示した配備先決定部１１７に比べて、発生イベント型及び入力イベント型を用いたマッチングと、集約属性の属性名及び属性値を用いたマッチングとを経て抽出されたノードであっても、実行可否フラグが「true」でない限り、モジュールの配備先として決定しない点が異なる。

（３）モジュール配備の具体例３
ここで、図２３〜図２５を用いて、モジュール配備の具体例３について説明する。図２３及び図２５は、配備先情報記憶部１１７Ａに記憶される情報の構成例を示す図である。図２４は、発生イベント情報記憶部１１６Ａに記憶される情報の構成例を示す図である。

図２３に示すように、温度センサＸ、湿度センサＸ及び温湿度センサＹの下位ノードには、実行可否フラグ「false」が設定されているので、モジュールは配備されない。その代わりに、モジュール「温度警告」、「平均温度計算」及び「平均湿度計算」がホームＧＷ−Ｘ及びモバイルＧＷ−Ｙに配備される。これによって、中継ノードであるホームＧＷ−Ｘ及びモバイルＧＷ−Ｙによって温度イベント及び湿度イベントが加工処理された温度警告イベント、平均温度イベント及び平均湿度イベントが新たにサーバノード１２０へ通知される。それゆえ、図２４に示す網掛け部分のように、発生イベント登録部１１６によって発生イベント型「温度警告」、「平均温度」及び「平均湿度」の発生イベントが発生イベント情報記憶部１１６Ａへ登録される。

図２４に網掛けで示した発生イベントが発生イベント情報記憶部１１６Ａに新たに追加されると、図２３に示したモジュールの配備状況が図２５に示すモジュールの配備状況に更新される。ここで、図２５に示すモジュールの配備状況は、図１５に示したモジュールの配備状況と比べて、Ｙ家用のモジュール「不快指数計算」が温湿度センサＹではなく、モバイルＧＷ−Ｙに配備されている点が異なる。このように、Ｙ家用のモジュール「不快指数計算」がモバイルＧＷ−Ｙに配備されるのも、温湿度センサＹではモジュールが実行できず、温湿度センサＹの実行可否フラグに「false」が設定されているからである。

［処理の流れ］
次に、本実施例に係るセンサネットワークシステムの処理の流れについて説明する。なお、ここでは、センサノード２１０によって実行される（１）全体処理を説明した後に、サーバノード１２０によって実行される（２）モジュール配備処理を説明することとする。

（１）全体処理
図２６は、実施例２に係るセンサノード２１０における全体処理の手順を示すフローチャートである。この全体処理は、センサノード２１０の電源がＯＮ状態である限り、繰り返し実行される。なお、図２６に示すセンサノード２１０における全体処理は、図１９に示したセンサノード２１０における全体処理に比べて、ステップＳ１０２の代わりにステップＳ３０１が実行される点が異なる。

図２６に示すように、新たな上位ノードを検出した場合（ステップＳ１０１肯定）には、センサノード２１０は、当該上位ノードのノードＩＤをサーバノード１２０へ送信するとともに、イベントの加工処理に関する実行可否フラグを送信する（ステップＳ３０１）。なお、新たな上位ノードを検出しなかった場合（ステップＳ１０１否定）には、ステップＳ３０１の処理を実行せずにステップＳ１０３の処理へ移行する。

続いて、サーバノード１２０からモジュールを受信した場合（ステップＳ１０３肯定）には、センサノード２１０は、サーバノード１２０から受信したモジュールを配備する（ステップＳ１０４）。なお、モジュールを受信しなかった場合（ステップＳ１０３否定）には、ステップＳ１０４の処理を実行せずにステップＳ１０５の処理へ移行する。

そして、センサデバイスからセンサ情報を受信した場合（ステップＳ１０５肯定）には、センサノード２１０は、当該センサ情報を入力イベント型とするモジュールが配備されているか否かをさらに判定する（ステップＳ１０６）。なお、センサ情報を受信しなかった場合（ステップＳ１０５否定）には、ステップＳ１０１の処理に戻る。

このとき、モジュールが配備されている場合（ステップＳ１０６肯定）には、センサノード２１０は、モジュールを実行することによってイベントを加工処理する（ステップＳ１０７）。そして、センサノード２１０は、加工処理が実行されたイベントを上位ノードへ送信する（ステップＳ１０８）。

一方、モジュールが配備されていない場合（ステップＳ１０６否定）には、センサノード２１０は、センサデバイスから受信したセンサ情報に発生ノードＩＤや集約属性などを付加した上で上位ノードへ送信する（ステップＳ１０９）。

このように、ステップＳ１０８またはステップＳ１０９の処理が実行された後は、上記のステップＳ１０１に戻り、センサノード２１０の電源がＯＦＦ状態になるまで、ステップＳ１０１〜ステップＳ１０９までの処理を繰り返し実行する。

なお、ここでは、センサノード２１０の全体処理について説明したが、中継ノードであるＧＷノード３１０によって実行される全体処理も一部を除き同様である。すなわち、ＧＷノード３１０の場合には、上記のステップＳ１０５においてセンサ情報の代わりにイベントが受信される点が相違する点を除き、センサノード２１０と同様である。

（２）モジュール配備処理
続いて、本実施例に係るモジュール配備処理について説明する。図２７は、実施例２に係るモジュール配備処理の手順を示すフローチャートである。このモジュール配備処理は、センサネットワークのトポロジが変化した場合に処理が起動される。なお、図２７に示すモジュール配備処理は、図２０に示したモジュール配備処理に比べて、ステップＳ４０１及びステップＳ４０２がさらに実行される点が異なる。

図２７に示すように、サーバノード１２０は、発生イベント情報記憶部１１６Ａが更新されるのを待機する（ステップＳ２０１）。そして、発生イベント情報記憶部１１６Ａが更新されると、全てのモジュールの配備が終了したか否かが判断されるが（ステップＳ２０２）、ここではいずれのモジュールについても処理が終了していないので（ステップＳ２０２否定）、ステップＳ２０３の処理へ移行する。

続いて、サーバノード１２０は、モジュール定義記憶部１１１Ｂに記憶されたモジュールの定義のうちモジュール識別子、入力イベント型及び集約属性名のカラムデータを配備先情報記憶部１１７Ａの該当カラムに格納する（ステップＳ２０３）。

そして、サーバノード１２０は、ステップＳ２０３の処理を実行後に、下記に説明するステップＳ２０４の処理を実行する。すなわち、サーバノード１２０は、発生イベント情報記憶部１１６Ａに記憶された発生ノードＩＤのうち、発生イベント型が未配備のモジュールの入力イベント型に含まれる発生ノードＩＤを抽出する。さらに、サーバノード１２０は、前述のように抽出した発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。

その後、サーバノード１２０は、抽出結果として得られた発生ノードＩＤ及び発生ノードＩＤに対応付けられた発生イベント属性を配備先情報記憶部１１７Ａに書き込む（ステップＳ２０５）。

このとき、発生ノードＩＤの数が「０」である場合（ステップＳ２０６肯定）には、下位ノードから通知される発生イベントが発生イベント情報記憶部１１６Ａに登録し切れていない可能性がある。この場合には、ステップＳ２０２の処理に移行する。

ここで、発生ノードＩＤの数が複数である場合（ステップＳ２０７肯定）には、下記に説明するステップＳ２０８の処理を実行する。すなわち、サーバノード１２０は、トポロジ記憶部１２１Ａに記憶された上位ノードＩＤのうち各発生ノードＩＤに対応するセンサノード２１０又はＧＷノード３１０が下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。

また、発生ノードＩＤの数が１つである場合（ステップＳ２０７否定）には、サーバノード１２０は、モジュールの配備先ノードの候補として、抽出結果として得られた発生ノードＩＤを抽出する。

その後、サーバノード１２０は、前述のように抽出した配備先の候補となるノードの実行可否フラグが「true」または「false」のいずれであるかによってイベントの加工処理が実行可能であるか否かを判定する（ステップＳ４０１）。

このとき、配備先の候補となるノードでイベントの加工処理が実行不可能である場合（ステップＳ４０１否定）には、サーバノード１２０は、当該候補の上位ノードを新たな配備先の候補に変更する（ステップＳ４０２）。

一方、配備先の候補となるノードでイベントの加工処理が実行可能である場合（ステップＳ４０１肯定）には、サーバノード１２０は、配備先の候補として抽出されていたノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

続いて、サーバノード１２０は、モジュール記憶部１１１Ａに記憶されたモジュールを配備先ノードＩＤに対応するノードへ送信する（ステップＳ２１０）。そして、サーバノード１２０は、発生イベント情報記憶部１１６Ａが更新されるのを待機し（ステップＳ２１１）、ステップＳ２０２の処理に戻る。

その後、サーバノード１２０は、全てのモジュールの配備が終了するまで（ステップＳ２０２否定）、上記のステップＳ２０３〜ステップＳ２１１までの処理を繰り返し実行する。そして、全てのモジュールの配備が終了すると（ステップＳ２０２肯定）、処理を終了する。

［実施例２の効果］
上述してきたように、本実施例に係るサーバノード１２０は、ノードから当該ノードがモジュールを実行可能であるか否かを表す実行可否情報を取得する。さらに、本実施例に係るサーバノード１２０は、各ノードが収容される上位ノードのうち、モジュールの実行が可能である旨を表す実行可否情報が取得された上位ノードにモジュールを配備する。このため、本実施例に係るセンサノード１２０は、モジュールを実行できないノードにモジュールが配備されるのを抑制できるので、ネットワークトラフィックを抑制しつつ、モジュールの分散配備をより適切に実行することができる。

さて、本実施例では、モジュールの配備中は下位ノードにイベントを蓄積させておき、モジュールの配備が終了した段階で蓄積させていたイベントを送信させることによってモジュールの配備中に発生するイベントが破棄されるのを防止する方法について説明する。

［サーバノードの構成］
図２８は、実施例３に係るサーバノード１３０の機能的構成を示すブロック図である。なお、以下では、上記の実施例１と同様の機能を発揮する機能部については同一の符号を付し、その説明を省略することとする。

図２８に示すサーバノード１３０は、図２に示したサーバノード１１０に比べて、動作モード送信部１３１をさらに有する点が相違する。動作モード送信部１３１は、サーバノード１３０の動作モードを送信する処理部である。一態様としては、動作モード送信部１３１は、トポロジ記憶部１１２Ａが更新された場合に、モジュールを配備するモジュール配備モードで動作中である旨を示す動作モード情報を下位ノードに送信する。その後、動作モード送信部１３１は、全てのモジュールの配備が終了した場合に、イベントを収集または処理するイベント収集モードで動作中である旨を示す動作モード情報を下位ノードに送信する。

［センサノードの構成］
図２９は、実施例３に係るセンサノード２３０の機能的構成を示すブロック図である。図２９に示すセンサノード２３０は、図１７に示したセンサノード２１０に比べて、動作モード受信部２３１と、イベント記憶部２３２とをさらに有する点が相違する。

このうち、動作モード受信部２３１は、動作モード送信部１３１から動作モード情報を受信する処理部である。一態様としては、動作モード受信部２３１は、動作モード情報としてモジュール配備モードが通知された場合に、図示しない内部メモリで管理しているサーバノード１３０の動作モードを「モジュール配備モード」に更新する。その上で、動作モード受信部２３１は、センサデバイスから受信したセンサ情報をイベント記憶部２３２へ蓄積するようにセンサ情報受信部２１１へ指示する。さらに、動作モード受信部２３１は、センサ情報が加工処理されたイベントをイベント記憶部２３２へ蓄積するようにモジュール実行部２１３へ指示する。その後、動作モード受信部２３１は、動作モード情報としてイベント収集モードが通知された場合に、図示しない内部メモリで管理しているサーバノード１３０の動作モードを「イベント収集モード」に更新する。その上で、動作モード受信部２３１は、イベント記憶部２３２に記憶されたイベントをサーバノード１３０へ送信するようにイベント送信部２１４へ指示する。

イベント記憶部２３２は、イベントを記憶する記憶部である。このイベント記憶部２３２は、サーバノード１３０がモジュール配備モードである場合に、センサ情報受信部２１１によって受信されたセンサ情報やモジュール実行部２１３によって加工処理が実行されたイベントを一時的に蓄積するために使用される。なお、イベント記憶部２３２のスキーマは、図２に示したイベント記憶部１１４と同様である。

［ＧＷノードの構成］
図３０は、実施例３に係るＧＷノード３３０の機能的構成を示すブロック図である。図３０に示すＧＷノード３３０は、図１８に示したＧＷノード３１０に比べて、動作モード受信部３３１と、イベント記憶部３３２とをさらに有する点が相違する。

このうち、動作モード受信部３３１は、動作モード送信部１３１から動作モード情報を受信する処理部である。一態様としては、動作モード受信部３３１は、動作モード情報としてモジュール配備モードが通知された場合に、図示しない内部メモリで管理しているサーバノード１３０の動作モードを「モジュール配備モード」に更新する。その上で、動作モード受信部３３１は、下位ノードから受信したイベントをイベント記憶部３３２へ蓄積するようにイベント受信部３１１へ指示する。さらに、動作モード受信部３３１は、イベントが加工処理された新たなイベントをイベント記憶部３３２へ蓄積するようにモジュール実行部３１３へ指示する。その後、動作モード受信部３３１は、動作モード情報としてイベント収集モードが通知された場合に、図示しない内部メモリで管理しているサーバノード１３０の動作モードを「イベント収集モード」に更新する。その上で、動作モード受信部３３１は、イベント記憶部３３２に記憶されたイベントをサーバノード１３０へ送信するようにイベント送信部３１４へ指示する。

イベント記憶部３３２は、イベントを記憶する記憶部である。このイベント記憶部３３２は、サーバノード１３０がモジュール配備モードである場合に、イベント受信部３１１によって受信されたイベントやモジュール実行部３１３によって加工処理が実行されたイベントを一時的に蓄積するために使用される。なお、イベント記憶部３３２のスキーマは、図２に示したイベント記憶部１１４と同様である。

［処理の流れ］
次に、本実施例に係るセンサネットワークシステムの処理の流れについて説明する。なお、ここでは、センサノード２３０によって実行される（１）全体処理を説明した後に、サーバノード１３０によって実行される（２）モジュール配備処理を説明することとする。

（１）全体処理
図３１は、実施例３に係るセンサノード２３０における全体処理の手順を示すフローチャートである。この全体処理は、センサノード２３０の電源がＯＮ状態である限り、繰り返し実行される。

図３１に示すように、動作モード情報を受信した場合（ステップＳ５０１肯定）には、センサノード２３０は、図示しない内部メモリで管理しているサーバノード１３０の動作モードを「モジュール配備モード」に更新する（ステップＳ５０２）。なお、動作モード情報を受信していない場合（ステップＳ５０１否定）には、ステップＳ５０６へ移行する。

続いて、動作モードがイベント収集モードである場合（ステップＳ５０３肯定）には、センサノード２３０は、イベント記憶部２３２に蓄積中のイベントをサーバノード１３０へ送信する（ステップＳ５０４）。そして、センサノード２３０は、サーバノード１３０へ送信し終わったイベントをイベント記憶部２３２から削除する（ステップＳ５０５）。なお、動作モードがイベント収集モードではない場合（ステップＳ５０３否定）には、ステップＳ５０６へ移行する。

その後、新たな上位ノードを検出した場合（ステップＳ５０６肯定）には、センサノード２３０は、当該上位ノードのノードＩＤをサーバノード１３０へ送信する（ステップＳ５０７）。なお、新たな上位ノードを検出しなかった場合（ステップＳ５０６否定）には、ステップＳ５０７の処理を実行せずにステップＳ５０８の処理へ移行する。

続いて、サーバノード１３０からモジュールを受信した場合（ステップＳ５０８肯定）には、センサノード２３０は、サーバノード１３０から受信したモジュールを配備する（ステップＳ５０９）。なお、モジュールを受信しなかった場合（ステップＳ５０８否定）には、ステップＳ５０９の処理を実行せずにステップＳ５１０の処理へ移行する。

そして、センサデバイスからセンサ情報を受信した場合（ステップＳ５１０肯定）には、センサノード２３０は、当該センサ情報を入力イベント型とするモジュールが配備されているか否かをさらに判定する（ステップＳ５１１）。なお、センサ情報を受信しなかった場合（ステップＳ５１０否定）には、ステップＳ５０１の処理に戻る。

このとき、モジュールが配備されている場合（ステップＳ５１１肯定）には、センサノード２３０は、モジュールを実行することによってイベントを加工処理する（ステップＳ５１２）。そして、センサノード２３０は、加工処理が実行されたイベントを上位ノードへ送信する（ステップＳ５１３）。

一方、モジュールが配備されていない場合（ステップＳ５１１否定）には、センサノード２３０は、センサデバイスから受信したセンサ情報に発生ノードＩＤや集約属性などを付加した上で上位ノードへ送信する（ステップＳ５１４）。

そして、動作モードがモジュール配備モードである場合（ステップＳ５１５肯定）には、センサノード２３０は、イベントをイベント記憶部２３２へ蓄積し（ステップＳ５１６）、ステップＳ５０１に戻って以降の処理を繰り返し実行する。なお、動作モードがモジュール配備モードではない場合（ステップＳ５１５否定）には、ステップＳ５０１に戻って以降の処理を繰り返し実行する。

なお、ここでは、センサノード２３０の全体処理について説明したが、中継ノードであるＧＷノード３３０によって実行される全体処理も一部を除き同様である。すなわち、ＧＷノード３３０の場合には、上記のステップＳ５１０においてセンサ情報の代わりにイベントが受信される点が相違する点を除き、センサノード２３０と同様である。

（２）モジュール配備処理
続いて、本実施例に係るモジュール配備処理について説明する。図３２は、実施例３に係るモジュール配備処理の手順を示すフローチャートである。このモジュール配備処理は、センサネットワークのトポロジが変化した場合に処理が起動される。なお、図３２に示すモジュール配備処理は、図２０に示したモジュール配備処理に比べて、ステップＳ６０１及びステップＳ６０２がさらに実行される点が異なる。

図３２に示すように、サーバノード１３０は、モジュールを配備するモジュール配備モードで動作中である旨を示す動作モード情報を下位ノードへ送信する（ステップＳ６０１）。続いて、サーバノード１３０は、発生イベント情報記憶部１１６Ａが更新されるのを待機する（ステップＳ２０１）。

そして、発生イベント情報記憶部１１６Ａが更新されると、全てのモジュールの配備が終了したか否かが判断されるが（ステップＳ２０２）、ここではいずれのモジュールについても処理が終了していないので（ステップＳ２０２否定）、ステップＳ２０３の処理へ移行する。

続いて、サーバノード１３０は、モジュール定義記憶部１１１Ｂに記憶されたモジュールの定義のうちモジュール識別子、入力イベント型及び集約属性名のカラムデータを配備先情報記憶部１１７Ａの該当カラムに格納する（ステップＳ２０３）。

そして、サーバノード１３０は、ステップＳ２０３の処理を実行後に、下記に説明するステップＳ２０４の処理を実行する。すなわち、サーバノード１３０は、発生イベント情報記憶部１１６Ａに記憶された発生ノードＩＤのうち、発生イベント型が未配備のモジュールの入力イベント型に含まれる発生ノードＩＤを抽出する。さらに、サーバノード１３０は、前述のように抽出した発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。

その後、サーバノード１３０は、抽出結果として得られた発生ノードＩＤ及び発生ノードＩＤに対応付けられた発生イベント属性を配備先情報記憶部１１７Ａに書き込む（ステップＳ２０５）。

このとき、発生ノードＩＤの数が「０」である場合（ステップＳ２０６肯定）には、下位ノードから通知される発生イベントが発生イベント情報記憶部１１６Ａに登録し切れていない可能性がある。この場合には、ステップＳ２０２の処理に移行する。

ここで、発生ノードＩＤの数が複数である場合（ステップＳ２０７肯定）には、下記に説明するステップＳ２０８の処理を実行する。すなわち、サーバノード１３０は、トポロジ記憶部１２１Ａに記憶された上位ノードＩＤのうち各発生ノードＩＤに対応するセンサノード２３０又はＧＷノード３３０が下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。

その後、サーバノード１３０は、配備先の候補として抽出されていたノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

また、発生ノードＩＤの数が１つである場合（ステップＳ２０７否定）には、サーバノード１３０は、モジュールを配備するノードに選択の余地がないので、先に抽出結果として得られた発生ノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

続いて、サーバノード１３０は、モジュール記憶部１１１Ａに記憶されたモジュールを配備先ノードＩＤに対応するノードへ送信する（ステップＳ２１０）。そして、サーバノード１３０は、発生イベント情報記憶部１１６Ａが更新されるのを待機し（ステップＳ２１１）、ステップＳ２０２の処理に戻る。

その後、サーバノード１３０は、全てのモジュールの配備が終了するまで（ステップＳ２０２否定）、上記のステップＳ２０３〜ステップＳ２１１までの処理を繰り返し実行する。

そして、全てのモジュールの配備が終了すると（ステップＳ２０２肯定）、サーバノード１３０は、イベントを収集または処理するイベント処理モードで動作中である旨を示す動作モード情報を下位ノードに送信し（ステップＳ６０２）、処理を終了する。

［実施例３の効果］
上述してきたように、本実施例に係るサーバノード１３０は、モジュールの配備が終了した場合に、ノードに蓄積させていたイベントを出力させる指示をノードへ送信する。これによって、本実施例に係るサーバノード１３０では、モジュールの配備中に発生するイベントが破棄される事態を防止できる。

さて、上記の実施例１では、イベントを加工処理するモジュールをできるだけ下位のノードに配備させる場合について説明したが、必ずしもモジュールが配備される下位ノードでモジュールを実行させるのが最適であるとは限らない。そこで、本実施例では、下位ノードのノード負荷およびネットワークコストに応じてモジュールを最適に分散配備する方法について説明する。

［サーバノードの構成］
図３３は、実施例４に係るサーバノード１４０の機能的構成を示すブロック図である。図３３に示すサーバノード１４０は、図２に示したサーバノード１１０に比べて、トポロジ取得部１４１及び配備先決定部１４２によって実行される処理の一部と、トポロジ記憶部１４１Ａに記憶される情報とが相違する。なお、以下では、上記の実施例１と同様の機能を発揮する機能部については同一の符号を付し、その説明を省略することとする。

トポロジ取得部１４１は、図２に示したトポロジ取得部１１２に比べて、下位ノードがどの上位ノードに接続されているかを表すノード間の接続情報を取得する点は共通し、下位ノードのノード負荷およびネットワークコストをさらに取得する点が相違する。

トポロジ記憶部１４１Ａは、図２に示したトポロジ記憶部１１２Ａに比べて、下位ノードＩＤ及び上位ノードＩＤとともに、ノード負荷、ネットワークコストがさらに対応付けられている点が相違する。ここで言う「ノード負荷」とは、下位ノードの負荷を表す指標値を指し、例えば、ＣＰＵ使用率やメモリ使用量などが採用される。また、「ネットワークコスト」は、下位ノード及び上位ノードの間におけるネットワーク通信にかかるコストを表す指標値を指す。例えば、ネットワークコストには、携帯電話網等におけるパケット従量制料金のようにネットワーク通信量に応じてコストが増加する場合であれば、通信量単位のコストを採用できる。

図３４は、トポロジ記憶部１４１Ａに記憶される情報の構成例を示す図である。図３４の例では、温度センサＸ、湿度センサＸ及び温湿度センサＹの下位ノードが上位ノードよりも負荷が高いことを示す。さらに、図３４の例では、モバイルＧＷ−Ｙ及びクラウドの区間以外はネットワークコストがかかる一方で、それ以外のノード間ではネットワークコストがかからないことを示す。

配備先決定部１４２は、発生イベント型及び入力イベント型を用いたマッチングと、集約属性の属性名及び属性値を用いたマッチングと経て抽出されたノードであっても、必ずしも当該ノードをモジュールの配備先にするとは限らない。一態様としては、配備先決定部１４２は、上記のマッチングを経て抽出されたノードとその上位ノードとの間におけるネットワークコストの有無を判定する。このとき、配備先決定部１４２は、上位ノードとの間でネットワークコストが発生する場合には、上記のマッチングを経て抽出されたノードにモジュールを配備する。一方、配備先決定部１４２は、上位ノードとの間でネットワークコストが発生しない場合には、上記のマッチングを経て抽出されたノードのノード負荷と上位ノードのノード負荷を比較し、ノード負荷が低いノードにモジュールを配備する。なお、ノード負荷およびネットワークコストの片方だけを条件に使用することもできる。

（４）モジュール配備の具体例４
ここで、図３５〜図３７を用いて、モジュール配備の具体例４について説明する。図３５及び図３７は、配備先情報記憶部１１７Ａに記憶される情報の構成例を示す図である。図３６は、発生イベント情報記憶部１１６Ａに記憶される情報の構成例を示す図である。

図３４に示したように、温度センサＸ及び湿度センサＸとホームＧＷ−Ｘとのノード間でネットワークコストがかからず、温度センサＸ及び湿度センサＸのノード負荷はホームＧＷ−Ｘのノード負荷よりも高い。また、温湿度センサＹとモバイルＧＷ−Ｙとのノード間でもネットワークコストはかからず、温湿度センサＹのノード負荷はモバイルＧＷ−Ｙのノード負荷よりも高い。したがって、温度センサＸ、湿度センサＸ及び温湿度センサＹには、モジュールは配備されない。一方、モバイルＧＷ−Ｙのノード負荷は、クラウドのノード負荷よりも高いが、モバイルＧＷ−Ｙ及びクラウド間ではネットワークコストがかかるので、クラウドにはモジュールは配備されない。したがって、図３５に示すように、モジュール「温度警告」、「平均温度計算」及び「平均湿度計算」がホームＧＷ−Ｘ及びモバイルＧＷ−Ｙに配備される。

これによって、中継ノードであるホームＧＷ−Ｘ及びモバイルＧＷ−Ｙによって温度イベント及び湿度イベントが加工処理された温度警告イベント、平均温度イベント及び平均湿度イベントが新たにサーバノード１４０へ通知される。それゆえ、図３６に示す網掛け部分のように、発生イベント登録部１１６によって発生イベント型「温度警告」、「平均温度」及び「平均湿度」の発生イベントが発生イベント情報記憶部１１６Ａへ登録される。図３６に網掛けで示した発生イベントが発生イベント情報記憶部１１６Ａに新たに追加されると、図３５に示したモジュールの配備状況が図３７に示すモジュールの配備状況に更新される。図３７に示すように、発生イベント型「温度警告」、「平均温度」及び「平均湿度」の発生イベントが追加されても、上述したノード負荷とネットワークコストの関係により、ホームＧＷ−Ｘ及びモバイルＧＷ−Ｙにモジュール「不快指数計算」が配備される。

［処理の流れ］
次に、本実施例に係るセンサネットワークシステムの処理の流れについて説明する。なお、ここでは、センサノード２４０によって実行される（１）全体処理を説明した後に、サーバノード１４０によって実行される（２）モジュール配備処理を説明することとする。

（１）全体処理
図３８は、実施例４に係るセンサノード２４０における全体処理の手順を示すフローチャートである。この全体処理は、センサノード２４０の電源がＯＮ状態である限り、繰り返し実行される。なお、図３８に示すセンサノード２４０における全体処理は、図１９に示したセンサノード２１０における全体処理に比べて、ステップＳ１０２の代わりにステップＳ７０１の処理が実行される点が異なる。

図３８に示すように、新たな上位ノードを検出した場合（ステップＳ１０１肯定）には、センサノード２４０は、次のような処理を実行する。すなわち、センサノード２４０は、当該上位ノードのノードＩＤをサーバノード１４０へ送信するとともに、自ノードのノード負荷及び上位ノード間のネットワークコストを送信する（ステップＳ７０１）。なお、新たな上位ノードを検出しなかった場合（ステップＳ１０１否定）には、ステップＳ７０１の処理を実行せずにステップＳ１０３の処理へ移行する。

続いて、サーバノード１４０からモジュールを受信した場合（ステップＳ１０３肯定）には、センサノード２４０は、サーバノード１４０から受信したモジュールを配備する（ステップＳ１０４）。なお、モジュールを受信しなかった場合（ステップＳ１０３否定）には、ステップＳ１０４の処理を実行せずにステップＳ１０５の処理へ移行する。

そして、センサデバイスからセンサ情報を受信した場合（ステップＳ１０５肯定）には、センサノード２４０は、当該センサ情報を入力イベント型とするモジュールが配備されているか否かをさらに判定する（ステップＳ１０６）。なお、センサ情報を受信しなかった場合（ステップＳ１０５否定）には、ステップＳ１０１の処理に戻る。

このとき、モジュールが配備されている場合（ステップＳ１０６肯定）には、センサノード２４０は、モジュールを実行することによってイベントを加工処理する（ステップＳ１０７）。そして、センサノード２４０は、加工処理が実行されたイベントを上位ノードへ送信する（ステップＳ１０８）。

一方、モジュールが配備されていない場合（ステップＳ１０６否定）には、センサノード２４０は、センサデバイスから受信したセンサ情報に発生ノードＩＤや集約属性などを付加した上で上位ノードへ送信する（ステップＳ１０９）。

なお、ここでは、センサノード２４０の全体処理について説明したが、中継ノードであるＧＷノード３４０によって実行される全体処理も一部を除き同様である。すなわち、ＧＷノード３４０の場合には、上記のステップＳ１０５においてセンサ情報の代わりにイベントが受信される点が相違する点を除き、センサノード２４０と同様である。

（２）モジュール配備処理
続いて、本実施例に係るモジュール配備処理について説明する。図３９は、実施例４に係るモジュール配備処理の手順を示すフローチャートである。このモジュール配備処理は、センサネットワークのトポロジが変化した場合に処理が起動される。なお、図３９に示すモジュール配備処理は、図２０に示したモジュール配備処理に比べて、ステップＳ８０１〜ステップＳ８０３の処理がさらに実行される点が異なる。

図３９に示すように、サーバノード１４０は、発生イベント情報記憶部１１６Ａが更新されるのを待機する（ステップＳ２０１）。そして、発生イベント情報記憶部１１６Ａが更新されると、全てのモジュールの配備が終了したか否かが判断されるが（ステップＳ２０２）、ここではいずれのモジュールについても処理が終了していないので（ステップＳ２０２否定）、ステップＳ２０３の処理へ移行する。

続いて、サーバノード１４０は、モジュール定義記憶部１１１Ｂに記憶されたモジュールの定義のうちモジュール識別子、入力イベント型及び集約属性名のカラムデータを配備先情報記憶部１１７Ａの該当カラムに格納する（ステップＳ２０３）。

そして、サーバノード１４０は、ステップＳ２０３の処理を実行後に、下記に説明するステップＳ２０４の処理を実行する。すなわち、サーバノード１４０は、発生イベント情報記憶部１１６Ａに記憶された発生ノードＩＤのうち、発生イベント型が未配備のモジュールの入力イベント型に含まれる発生ノードＩＤを抽出する。さらに、サーバノード１４０は、前述のように抽出した発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。

その後、サーバノード１４０は、抽出結果として得られた発生ノードＩＤ及び発生ノードＩＤに対応付けられた発生イベント属性を配備先情報記憶部１１７Ａに書き込む（ステップＳ２０５）。

このとき、発生ノードＩＤの数が「０」である場合（ステップＳ２０６肯定）には、下位ノードから通知される発生イベントが発生イベント情報記憶部１１６Ａに登録し切れていない可能性がある。この場合には、ステップＳ２０２の処理に移行する。

ここで、発生ノードＩＤの数が複数である場合（ステップＳ２０７肯定）には、サーバノード１４０は、下記に説明するステップＳ２０８の処理を実行する。すなわち、サーバノード１４０は、トポロジ記憶部１２１Ａに記憶された上位ノードＩＤのうち各発生ノードＩＤに対応するセンサノード２４０又はＧＷノード３４０が下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。

また、発生ノードＩＤの数が１つである場合（ステップＳ２０７否定）には、サーバノード１４０は、モジュールを配備するノードの候補として、抽出結果として得られた発生ノードＩＤを抽出する。

続いて、サーバノード１４０は、前述のように抽出した配備先の候補となるノードとその上位ノードとの間でネットワークコストがかかるか否かを判定する（ステップＳ８０１）。このとき、配備先の候補となるノードとその上位ノードとの間でネットワークコストがかからない場合（ステップＳ８０１肯定）には、サーバノード１４０は、配備先の候補となるノードのノード負荷が上位ノードのノード負荷よりも大きいか否かをさらに判定する（ステップＳ８０２）。

ここで、配備先の候補となるノードのノード負荷が上位ノードのノード負荷よりも大きい場合（ステップＳ８０２肯定）には、サーバノード１４０は、当該候補の上位ノードを新たな配備先の候補に変更し（ステップＳ８０３）、ステップＳ８０１の処理に戻る。

一方、配備先の候補となるノードとその上位ノードとの間でネットワークコストがかかる場合（ステップＳ８０１否定）には、サーバノード１４０は、配備先の候補として抽出されていたノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。また、配備先の候補となるノードのノード負荷が上位ノードのノード負荷以下である場合（ステップＳ８０２否定）にも、上記のステップＳ２０９の処理が実行される。

続いて、サーバノード１４０は、モジュール記憶部１１１Ａに記憶されたモジュールを配備先ノードＩＤに対応するノードへ送信する（ステップＳ２１０）。そして、サーバノード１４０は、発生イベント情報記憶部１１６Ａが更新されるのを待機し（ステップＳ２１１）、ステップＳ２０２の処理に戻る。

その後、サーバノード１４０は、全てのモジュールの配備が終了するまで（ステップＳ２０２否定）、上記のステップＳ２０３〜ステップＳ２１１までの処理を繰り返し実行する。そして、全てのモジュールの配備が終了すると（ステップＳ２０２肯定）、処理を終了する。

［実施例４の効果］
上述してきたように、本実施例に係るサーバノード１４０は、ノードからノードの負荷およびノードと該ノードの上位ノードとの間におけるネットワークコストを取得する。さらに、本実施例に係るサーバノード１４０は、各ノードが収容される上位ノードのうち、負荷及びネットワークコストが所定の条件を満たす上位ノードにモジュールを配備する。このため、本実施例に係るサーバノード１４０では、ネットワークトラフィックだけでなく、装置負荷およびネットワークコストの観点からモジュールを配備することができる。したがって、本実施例に係るサーバノード１４０によれば、モジュールの分散配備を最適化することができる。

次に、本実施例では、センサノードがサーバノードへイベントを送信する場合の送信間隔を制御したり、イベントデータを圧縮したりすることにより、イベントの送信効率を向上させる方法について説明する。

［サーバノードの構成］
図４０は、実施例５に係るサーバノード１５０の機能的構成を示すブロック図である。図４０に示すように、サーバノード１５０は、図２に示したサーバノード１１０に比べて、モジュール定義記憶部１５１と、送信制御情報送信部１５２をさらに有する点が相違する。なお、以下では、上記の実施例１と同様の機能を発揮する機能部については同一の符号を付し、その説明を省略することとする。

このうち、モジュール定義記憶部１５１は、上記の実施例１と比較して、モジュールに関する定義に加え、イベントの送信制御情報をさらに対応付けて記憶する点が相違する。図４１は、モジュール定義記憶部１５１に記憶される情報の構成例を示す図である。図４１に示すように、温度警告は、０秒、すなわち即座に上位ノードに送信することが定められている。また、平均温度及び平均湿度は、６００秒（１０分）ごとにまとめて送信することが定められている。また、不快指数は、３６００秒（１時間）ごとにまとめて送信することが定められている。これらのイベントのうち不快指数は、データを圧縮して送信することが併せて定められている。なお、図中の真偽値が「true」である場合には、データを圧縮する設定であることを表し、図中の真偽値が「false」である場合には、データを圧縮しない設定であることを表す。

送信制御情報送信部１５２は、モジュール定義記憶部１５１に記憶された各項目のうち送信間隔およびデータ圧縮の要否を送信制御情報として下位ノードへ送信する処理部である。

［センサノードの構成］
図４２は、実施例５に係るセンサノード２５０の機能的構成を示すブロック図である。図４２に示すように、センサノード２５０は、図１７に示したセンサノード２１０に比べて、送信制御情報受信部２５１と、イベント送信制御部２５２とをさらに有する点が相違する。

このうち、送信制御情報受信部２５１は、送信制御情報送信部１５２によって送信された送信制御情報を受信する処理部である。このようにして受信された送信制御情報は、後述のイベント送信制御部２５２へ出力される。

イベント送信制御部２５２は、送信制御情報にしたがってイベントを上位ノードへ送信するように制御する処理部である。一態様としては、イベント送信制御部２５２は、送信制御情報に設定された送信間隔でイベントを上位ノードへ送信するようにイベント送信部２１４を制御する。他の一態様としては、イベント送信制御部２５２は、送信制御情報にデータを圧縮する設定がなされている場合に、イベントデータを圧縮した上で圧縮後のイベントデータを上位ノードへ送信するようにイベント送信部２１４を制御する。

［ＧＷノードの構成］
図４３は、実施例５に係るＧＷノード３５０の機能的構成を示すブロック図である。図４３に示すように、ＧＷノード３５０は、図１８に示したＧＷノード３１０に比べて、送信制御情報受信部３５１と、イベント送信制御部３５２とをさらに有する点が相違する。

このうち、送信制御情報受信部３５１は、送信制御情報送信部１５２によって送信された送信制御情報を受信する処理部である。このようにして受信された送信制御情報は、後述のイベント送信制御部３５２へ出力される。

イベント送信制御部３５２は、送信制御情報にしたがってイベントを上位ノードへ送信するように制御する処理部である。一態様としては、イベント送信制御部３５２は、送信制御情報に設定された送信間隔でイベントを上位ノードへ送信するようにイベント送信部３１４を制御する。他の一態様としては、イベント送信制御部３５２は、送信制御情報にデータを圧縮する設定がなされている場合に、イベントデータを圧縮した上で圧縮後のイベントデータを上位ノードへ送信するようにイベント送信部３１４を制御する。

［処理の流れ］
図４４は、実施例５に係るセンサノード２５０における全体処理の手順を示すフローチャートである。この全体処理は、センサノード２５０の電源がＯＮ状態である限り、繰り返し実行される。なお、図４４に示すセンサノード２５０における全体処理は、図１９に示したセンサノード２１０における全体処理に比べて、ステップＳ１０８〜ステップＳ１０９の代わりにステップＳ９０１〜ステップＳ９０４の処理が実行される点が異なる。

図４４に示すように、新たな上位ノードを検出した場合（ステップＳ１０１肯定）には、センサノード２５０は、当該上位ノードのノードＩＤをサーバノード１５０へ送信する（ステップＳ１０２）。なお、新たな上位ノードを検出しなかった場合（ステップＳ１０１否定）には、ステップＳ１０２の処理を実行せずにステップＳ１０３の処理へ移行する。

続いて、サーバノード１５０からモジュールを受信した場合（ステップＳ１０３肯定）には、センサノード２５０は、サーバノード１５０から受信したモジュールを配備する（ステップＳ１０４）。なお、モジュールを受信しなかった場合（ステップＳ１０３否定）には、ステップＳ１０４の処理を実行せずにステップＳ１０５の処理へ移行する。

そして、センサデバイスからセンサ情報を受信した場合（ステップＳ１０５肯定）には、センサノード２５０は、当該センサ情報を入力イベント型とするモジュールが配備されているか否かをさらに判定する（ステップＳ１０６）。なお、センサ情報を受信しなかった場合（ステップＳ１０５否定）には、ステップＳ１０１の処理に戻る。

このとき、モジュールが配備されている場合（ステップＳ１０６肯定）には、センサノード２５０は、モジュールを実行することによってイベントを加工処理する（ステップＳ１０７）。そして、センサノード２５０は、前回にイベントを送信してから送信制御情報に設定された送信間隔が経過するまで待機する（ステップＳ９０１）。

一方、モジュールが配備されていない場合（ステップＳ１０６否定）には、センサノード２５０は、次のような処理を実行する。すなわち、センサノード２５０は、前回にセンサ情報を送信してから送信制御情報に設定された送信間隔が経過するまで待機する（ステップＳ９０１）。

そして、送信制御情報にデータを圧縮する設定がなされている場合（ステップＳ９０２肯定）には、センサノード２５０は、イベントデータを圧縮し（ステップＳ９０３）、圧縮後のイベントを上位ノードへ送信する（ステップＳ９０４）。なお、送信制御情報にデータを圧縮する設定がなされていない場合（ステップＳ９０２否定）には、センサノード２５０は、圧縮せずにイベントを上位ノードへ送信する（ステップＳ９０４）。

このようにして、センサノード２５０は、上記のステップＳ１０１〜ステップＳ１０７及び上記のステップＳ９０１〜ステップＳ９０４までの処理を電源がＯＦＦ状態になるまで繰り返し実行する。

なお、ここでは、センサノード２５０の全体処理について説明したが、中継ノードであるＧＷノード３５０によって実行される全体処理も一部を除き同様である。すなわち、ＧＷノード３５０の場合には、上記のステップＳ１０５においてセンサ情報の代わりにイベントが受信される点が相違する点を除き、センサノード２５０と同様である。

［実施例５の効果］
上述してきたように、本実施例に係るサーバノード１５０は、センサノードがサーバノードへイベントを送信する場合の送信制御情報を下位ノードへ送信する。これによって、本実施例に係るサーバノード１５０は、センサノードが送信間隔を制御したり、イベントデータを圧縮したりしてイベントを送信することができ、イベントの送信効率を向上させることが可能になる。

次に、本実施例では、モジュールが処理を実行する場合に参照する参照データの一部を下位ノードに配備することにより、下位ノードで実行されるイベントの加工処理を効率よく実行させる方法について説明する。

［サーバノードの構成］
図４５は、実施例６に係るサーバノード１６０の機能的構成を示すブロック図である。図４５に示すように、サーバノード１６０は、図２に示したサーバノード１１０に比べて、モジュール定義記憶部１６１と、参照データ記憶部１６２と、部分参照データ送信部１６３とをさらに有する点が相違する。なお、以下では、上記の実施例１と同様の機能を発揮する機能部については同一の符号を付し、その説明を省略することとする。

このうち、モジュール定義記憶部１６１は、上記の実施例１と比較して、モジュールに関する定義に加え、モジュールがイベントを加工処理する場合に参照するテーブル名及びカラムをさらに対応付けて記憶する点が相違する。図４６は、モジュール定義記憶部１６１に記憶される情報の構成例を示す図である。図４６に示すように、モジュール「平均温度計算」、「平均湿度計算」及び「不快指数計算」によってイベントが加工処理する場合に参照されるテーブル名はいずれもテーブルＡであり、互いに共通している。また、テーブルＡの中で参照されるカラムについてもカラムＫは、モジュール「平均温度計算」、「平均湿度計算」及び「不快指数計算」に共通して参照される一方で、その他に参照されるカラムは順に「Ｘ」、「Ｙ」、「Ｚ」と互いに異なる。

参照データ記憶部１６２は、モジュールがイベントを加工処理する場合に参照されるデータを記憶する記憶部である。この参照データ記憶部１６２には、モジュール記憶部１１１Ａに記憶される全てのモジュールによって参照されるデータが記憶されている。

部分参照データ送信部１６３は、参照データ記憶部１６２に記憶された参照データのうち、下位ノードに配備するモジュールに対応する部分参照データを抽出した上で下位ノードへ送信する処理部である。一態様としては、部分参照データ送信部１６３は、モジュールが配備される場合に、当該モジュールに対応する参照テーブル及び参照カラムをモジュール定義記憶部１６１から読み出す。その上で、部分参照データ送信部１６３は、参照データ記憶部１６２に記憶された参照データのうち参照テーブル名及び参照カラムに対応する部分参照データを抽出してモジュールを配備する下位ノードへ送信する。

［センサノードの構成］
図４７は、実施例６に係るセンサノード２６０の機能的構成を示すブロック図である。図４７に示すように、センサノード２６０は、図１７に示したセンサノード２１０に比べて、部分参照データ受信部２６１と、部分参照データ記憶部２６２とをさらに有する点が相違する。

このうち、部分参照データ受信部２６１は、部分参照データ送信部１６３によって送信された部分参照データを受信する処理部である。このようにして受信された部分参照データは後述の部分参照データ記憶部２６２に登録される。

部分参照データ記憶部２６２は、部分参照データを記憶する記憶部である。この部分参照データ記憶部２６２は、センサノード２６０に配備されたモジュールによってイベントが加工処理される場合に、モジュール実行部２１３によって参照される。

［ＧＷノードの構成］
図４８は、実施例６に係るＧＷノード３６０の機能的構成を示すブロック図である。図４８に示すように、ＧＷノード３６０は、図１７に示したＧＷノード３１０に比べて、部分参照データ受信部３６１と、部分参照データ記憶部３６２とをさらに有する点が相違する。

このうち、部分参照データ受信部３６１は、部分参照データ送信部１６３によって送信された部分参照データを受信する処理部である。このようにして受信された部分参照データは後述の部分参照データ記憶部３６２に登録される。

部分参照データ記憶部３６２は、部分参照データを記憶する記憶部である。この部分参照データ記憶部３６２は、ＧＷノード３６０に配備されたモジュールによってイベントが加工処理される場合に、モジュール実行部３１３によって参照される。

［処理の流れ］
次に、本実施例に係るセンサネットワークシステムの処理の流れについて説明する。なお、ここでは、センサノード２６０によって実行される（１）全体処理を説明した後に、サーバノード１６０によって実行される（２）モジュール配備処理を説明することとする。

（１）全体処理
図４９は、実施例６に係るセンサノード２６０における全体処理の手順を示すフローチャートである。この全体処理は、センサノード２６０の電源がＯＮ状態である限り、繰り返し実行される。なお、図４９に示すセンサノード２６０における全体処理は、図１９に示したセンサノード２１０における全体処理に比べて、ステップＳ１００１〜ステップＳ１００３の処理がさらに実行される点が異なる。

図４９に示すように、新たな上位ノードを検出した場合（ステップＳ１０１肯定）には、センサノード２６０は、次のような処理を実行する。すなわち、センサノード２６０は、当該上位ノードのノードＩＤをサーバノード１６０へ送信する（ステップＳ１０２）。なお、新たな上位ノードを検出しなかった場合（ステップＳ１０１否定）には、ステップＳ１０２の処理を実行せずにステップＳ１０３の処理へ移行する。

続いて、サーバノード１６０からモジュールを受信した場合（ステップＳ１０３肯定）には、センサノード２６０は、サーバノード１６０から受信したモジュールを配備する（ステップＳ１０４）。なお、モジュールを受信しなかった場合（ステップＳ１０３否定）には、ステップＳ１０４の処理を実行せずにステップＳ１００１の処理へ移行する。

ここで、部分参照データを受信した場合（ステップＳ１００１肯定）には、センサノード２６０は、部分参照データを部分参照データ記憶部２６２に格納する（ステップＳ１００２）。なお、部分参照データを受信しなかった場合（ステップＳ１００１否定）には、ステップＳ１００２の処理を実行せずにステップＳ１０５の処理へ移行する。

そして、センサデバイスからセンサ情報を受信した場合（ステップＳ１０５肯定）には、センサノード２６０は、当該センサ情報を入力イベント型とするモジュールが配備されているか否かをさらに判定する（ステップＳ１０６）。なお、センサ情報を受信しなかった場合（ステップＳ１０５否定）には、ステップＳ１０１の処理に戻る。

このとき、モジュールが配備されている場合（ステップＳ１０６肯定）には、センサノード２６０は、モジュールを実行することによってイベントを加工処理する（ステップＳ１００３）。そして、センサノード２６０は、加工処理が実行されたイベントを上位ノードへ送信する（ステップＳ１０８）。

一方、モジュールが配備されていない場合（ステップＳ１０６否定）には、センサノード２６０は、センサデバイスから受信したセンサ情報に発生ノードＩＤや集約属性などを付加した上で上位ノードへ送信する（ステップＳ１０９）。

なお、ここでは、センサノード２６０の全体処理について説明したが、中継ノードであるＧＷノード３６０によって実行される全体処理も一部を除き同様である。すなわち、ＧＷノード３６０の場合には、上記のステップＳ１０５においてセンサ情報の代わりにイベントが受信される点が相違する点を除き、センサノード２６０と同様である。

（２）モジュール配備処理
続いて、本実施例に係るモジュール配備処理について説明する。図５０は、実施例６に係るモジュール配備処理の手順を示すフローチャートである。このモジュール配備処理は、センサネットワークのトポロジが変化した場合に処理が起動される。なお、図５０に示すモジュール配備処理は、図２０に示したモジュール配備処理に比べて、ステップＳ１１０１〜ステップＳ１１０２の処理がさらに実行される点が異なる。

図５０に示すように、サーバノード１６０は、発生イベント情報記憶部１１６Ａが更新されるのを待機する（ステップＳ２０１）。そして、発生イベント情報記憶部１１６Ａが更新されると、全てのモジュールの配備が終了したか否かが判断されるが（ステップＳ２０２）、ここではいずれのモジュールについても処理が終了していないので（ステップＳ２０２否定）、ステップＳ２０３の処理へ移行する。

続いて、サーバノード１６０は、モジュール定義記憶部１１１Ｂに記憶されたモジュールの定義のうちモジュール識別子、入力イベント型及び集約属性名のカラムデータを配備先情報記憶部１１７Ａの該当カラムに格納する（ステップＳ２０３）。

そして、サーバノード１６０は、ステップＳ２０３の処理を実行後に、下記に説明するステップＳ２０４の処理を実行する。すなわち、サーバノード１１０は、発生イベント情報記憶部１１６Ａに記憶された発生ノードＩＤのうち、発生イベント型が未配備のモジュールの入力イベント型に含まれる発生ノードＩＤを抽出する。さらに、サーバノード１６０は、前述のように抽出した発生ノードＩＤ間で未配備のモジュールに定義された集約属性の属性名と同一の集約属性に属する属性値が同一であるノードを抽出する。

その後、サーバノード１６０は、抽出結果として得られた発生ノードＩＤ及び発生ノードＩＤに対応付けられた発生イベント属性を配備先情報記憶部１１７Ａに書き込む（ステップＳ２０５）。

このとき、発生ノードＩＤの数が「０」である場合（ステップＳ２０６肯定）には、下位ノードから通知される発生イベントが発生イベント情報記憶部１１６Ａに登録し切れていない可能性がある。この場合には、ステップＳ２０２の処理に移行する。

ここで、発生ノードＩＤの数が複数である場合（ステップＳ２０７肯定）には、下記に説明するステップＳ２０８の処理を実行する。すなわち、サーバノード１６０は、トポロジ記憶部１１２Ａに記憶された上位ノードＩＤのうち各発生ノードＩＤに対応するセンサノード２６０又はＧＷノード３６０が下位ノードとして全て収容され、かつ最も下位ノード側であるノードＩＤを抽出する。そして、サーバノード１６０は、前述のように抽出したノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

また、発生ノードＩＤの数が１つである場合（ステップＳ２０７否定）には、サーバノード１６０は、モジュールを配備するノードに選択の余地がないので、先に抽出結果として得られた発生ノードＩＤを配備先ノードＩＤのカラムに登録する（ステップＳ２０９）。

続いて、サーバノード１６０は、モジュール記憶部１１１Ａに記憶されたモジュールを配備先ノードＩＤに対応するノードへ送信する（ステップＳ２１０）。そして、サーバノード１６０は、当該モジュールに対応する参照テーブル及び参照カラムをモジュール定義記憶部１６１から読み出し、参照データ記憶部１６２に記憶された参照データのうち参照テーブル名及び参照カラムに対応する部分参照データを読み出す（ステップＳ１１０１）。

その上で、サーバノード１６０は、参照データ記憶部１６２から読み出した部分参照データをモジュールを配備する下位ノードへ送信する（ステップＳ１１０２）。そして、サーバノード１６０は、発生イベント情報記憶部１１６Ａが更新されるのを待機し（ステップＳ２１１）、ステップＳ２０２の処理に戻る。

その後、サーバノード１６０は、全てのモジュールの配備が終了するまで（ステップＳ２０２否定）、上記のステップＳ２０３〜ステップＳ２１１までの処理を繰り返し実行する。そして、全てのモジュールの配備が終了すると（ステップＳ２０２肯定）、処理を終了する。

［実施例６の効果］
上述してきたように、本実施例に係るサーバノード１６０は、モジュールが処理を実行する場合に参照する参照データの一部を下位ノードに配備する。このため、本実施例に係るサーバノード１６０によれば、下位ノードで実行されるイベントの加工処理を効率よく実行させることができる。

なお、上記の実施例１〜６では、センサネットワークシステムにセンサノードやＧＷノードが追加される場合を例示したが、開示の装置は、センサネットワークシステムからノードが削除される場合にも同様に適用できる。例えば、サービスに加入していたノードがサービスを解除した場合には、サービス提供用のアプリケーションからセンサネットワークから削除すべきノードのノードＩＤなどを取得することもできる。また、サーバノードやＧＷノードが下位ノードによるネットワーク接続を監視しておき、ネットワーク接続が切断された場合に、削除すべきノードとして特定することもできる。

また、上記の実施例１〜６では、ネットワークのトポロジが変化したことを契機にモジュール配備処理を起動する場合を例示したが、モジュールが追加または削除された場合やモジュールの定義が変更された場合にモジュール配備処理を起動することとしてもよい。

なお、開示の装置では、モジュールによって実行されるイベント加工処理やサービス提供用のアプリケーションによって実行されるサービス提供処理のバックグラウンドでモジュール配備処理を実行することもできる。例えば、現用系のサーバノードでイベント加工処理やサービス提供処理を実行しつつ、待機系のサーバノードでモジュール配備処理を実行できる。

１ センサネットワークシステム
１１０ サーバノード
１１１ モジュール登録部
１１１Ａ モジュール記憶部
１１１Ｂ モジュール定義記憶部
１１２ トポロジ取得部
１１２Ａ トポロジ記憶部
１１３ イベント受信部
１１４ イベント記憶部
１１５ モジュール実行部
１１６ 発生イベント登録部
１１６Ａ 発生イベント情報記憶部
１１７ 配備先決定部
１１７Ａ 配備先情報記憶部
１１８ モジュール送信部

Claims (9)

1. 検知したイベントを送信するセンサノードと、前記イベントを中継する中間ノードと、を含む複数のノードが接続されたセンサネットワークからイベントを収集するコンピュータが実行するイベント収集方法において、
   前記イベントを加工処理するモジュールを識別するモジュール識別子と、前記モジュールが加工処理するイベントの種別を示す入力イベント種別と、前記モジュールが集約するイベントを分類する集約属性名とを関連付けて管理するモジュール定義情報を記憶し、
   前記ノードで発生するイベントを収集し、当該収集したイベントの種別を示す発生イベント種別と、当該収集したイベントに関連づけられた属性名と属性値を含む発生イベント属性と、当該収集したイベントが発生したノードを識別する発生ノード識別子とを関連付けて管理する発生イベント情報を記憶し、
   前記ノードの接続関係を収集し、当該接続関係を管理するトポロジ情報を記憶し、
   前記モジュール定義情報と前記発生イベント情報とに基づき、前記入力イベント種別と前記発生イベント種別が対応し、前記集約属性名で特定される前記属性名に対応する前記属性値で分類される前記発生ノード識別子を前記モジュールの加工処理ごとに抽出し、
   前記抽出した発生ノード識別子が前記モジュールの加工処理に対して単一の場合は、当該発生ノード識別子で識別されるノードを当該モジュール識別子で識別されるモジュールの配備先として決定し、
   前記抽出した発生ノード識別子が前記モジュールの加工処理に対して複数の場合は、前記トポロジ情報を参照し、前記複数の発生ノード識別子に共通する上位ノードを当該モジュール識別子で識別されるモジュールの配備先として決定し、
   前記決定した配備先のノードに対して、前記モジュールを配備する、
   各処理を実行するイベント収集方法。
2. 前記コンピュータが、
   前記ノードが前記モジュールを実行可能であるか否かを表す実行可否情報を収集し、
   前記決定した配備先のノードの実行可否情報が実行不可能な場合は、モジュールの配備先を当該ノードの上位ノードに決定する処理を実行することを特徴とする請求項１に記載のイベント収集方法。
3. 前記コンピュータが、
   前記モジュール配備方法を実行中に前記センサネットワークで発生するイベントを加工処理することを特徴とする請求項１または２に記載のイベント収集方法。
4. 前記コンピュータが、
   前記ノードの負荷情報を収集し、
   前記決定した配備先のノードと、該ノードの上位ノードの前記負荷情報が所定の条件を満たす場合は、モジュールの配備先を前記上位ノードに決定する処理を実行することを特徴とする請求項１〜３のいずれか１つに記載のイベント収集方法。
5. 前記コンピュータが、
   前記ノード間におけるネットワークコストを収集する処理をさらに実行し、
   前記所定の条件にネットワークコストを含むことを特徴とする請求項４に記載のイベント収集方法。
6. 前記コンピュータが、
   前記モジュールを配備したノードの上位ノードに、当該モジュールが出力するイベントを所定の時間間隔ごとに送信する指示を、当該ノードへ送信する処理をさらに実行し、
   イベントを前記所定の時間間隔で当該ノードの上位ノードに送信させることを特徴とする請求項１〜５のいずれか１つに記載のイベント収集方法。
7. 前記コンピュータが、
   前記モジュールを配備したノードの上位ノードに、当該モジュールが出力するイベントをデータ圧縮して送信する指示を、当該ノードへ送信する処理をさらに実行し、
   イベントをデータ圧縮して当該ノードの上位ノードに送信させることを特徴とする請求項１〜６のいずれか１つに記載のイベント収集方法。
8. 前記コンピュータが、
   前記モジュール定義情報に定義された１つまたは複数のモジュールが参照する参照データのうち、前記配備するモジュールが参照する部分の参照データを、当該モジュールの配備先のノードに送信する処理を実行することを特徴とする請求項１〜７のいずれか１つに記載のイベント収集方法。
9. 検知したイベントを送信するセンサノードと、前記イベントを中継する中間ノードと、を含む複数のノードが接続されたセンサネットワークと通信する通信部と、
   前記イベントを加工処理するモジュールを識別するモジュール識別子と、前記モジュールが加工処理するイベントの種別を示す入力イベント種別と、前記モジュールが集約するイベントを分類する集約属性名とを関連付けて管理するモジュール定義情報と、
   イベントの種別を示す発生イベント種別と、当該イベントに関連づけられた属性名と属性値を含む発生イベント属性と、当該イベントが発生したノードを識別する発生ノード識別子とを関連付けて管理する発生イベント情報と、
   前記ノードの接続関係を管理するトポロジ情報を記憶する記憶部と、
   前記ノードで発生するイベントを収集し、発生イベント種別と、発生イベント属性と、発生ノード識別子とを関連付けて発生イベント情報を記憶する処理と、
   前記ノードの接続関係を収集し、当該接続関係を管理するトポロジ情報を記憶する処理と、
   前記モジュール定義情報と前記発生イベント情報とに基づき、前記入力イベント種別と前記発生イベント種別が対応し、前記集約属性名で特定される前記属性名に対応する前記属性値で分類される前記発生ノード識別子を前記モジュールの加工処理ごとに抽出する処理と、
   前記抽出した発生ノード識別子が前記モジュールの加工処理に対して単一の場合は、当該発生ノード識別子で識別されるノードを当該モジュール識別子で識別されるモジュールの配備先として決定する処理と、
   前記抽出した発生ノード識別子が前記モジュールの加工処理に対して複数の場合は、前記トポロジ情報を参照し、前記複数の発生ノード識別子に共通する上位ノードを当該モジュール識別子で識別されるモジュールの配備先として決定する処理と、
   前記決定した配備先のノードに対して、前記モジュールを配備する処理と
   を実行する処理部を有する情報処理装置。

Images