JP4885463B2 - センサネットワークシステム、センサデータの処理方法及びプログラム - Google Patents

Description

本発明は、ネットワークに接続した多数のセンサからの情報を利用する技術に関する。

近年におけるインターネット等のネットワークの利用は、検索エンジンや予め設定したリンクなどから文書や画像あるいは映像、音声など蓄積されたコンテンツにアクセスするものが主流となっている。すなわち、保存されている過去のコンテンツに対してアクセスする技術は完成している。

一方、現在の情報を送信するものとして、所定の位置に設けたカメラ（ＷＥＢカメラ）の画像を連続的に配信するストリーミング技術がある。また、最近は、大量の小型の無線センサノードから得られるセンシングデータを、ネットワークを通じて取得するセンサネットワークの技術が発展しつつある（例えば、特許文献１〜５）。近年、現実世界の情報をセンサによって取り込み、この情報を、ネットワークを通して離れた場所で利用するセンサネットワークへの期待が高まっている。現在のインターネット上のサービスは仮想空間上のサービスに閉じているが、センサネットワークが現在のインターネットと本質的に違う点は、実空間と融合している点である。実空間との融合を図ることができれば、時間、位置など状況依存型のさまざまなサービスが実現できる。実空間に存在する多様なオブジェクトがネットワーク接続されることでトレーサビリティが実現でき、広義の意味での「安全」を求める社会ニーズや、在庫管理やオフィスワークの「効率化」のニーズに対処することが可能となる。
特開２００２−００６９３７号公報 特開２００３−３１９５５０号公報 特開２００４−２８０４１１号公報 米国特許出願公開第２００４／００９３２３９号明細書 米国特許出願公開第２００４／０１０３１３９号明細書

しかしながら、上記従来例に示したような検索エンジンでは、過去に蓄積されたデータについて、ネットワーク上の位置（アドレス）を知ることができるものの、ネットワークに接続された膨大なセンサ情報からのリアルタイムの情報に対しての効率的な検索や、情報変化検出には適していない、という問題がある。

そこで本発明は、ネットワークに接続された多数のセンサからのリアルタイムの情報を、容易に取得できるようなセンサネットワークシステムを実現することを目的とし、膨大なセンサからの情報のうち所望の情報をリアルタイムで監視し、情報の変化を迅速に把握することを目的とする。

本発明は、複数のセンサノードから送信されるデータを処理する分散サーバと、前記センサノードを管理する管理サーバとをネットワークで接続し、前記センサノードからのデータに基づいて予め設定した処理を実行する方法であって、前記管理サーバが、前記センサノードの識別子であるセンサＩＤと、前記センサノードのセンシング対象を規定するモデル名を関連づけて管理サーバ記憶領域のモデルリストに格納し、前記管理サーバが、前記モデルリストに基づいて、特定のモデル名について関連づけられた各センサＩＤに対する監視条件を設定して前記分散サーバに送信し、前記分散サーバが、前記管理サーバから前記特定のモデル名について関連づけられた各センサＩＤに対する監視条件を受信して、前記センサＩＤに対応するデータの値の監視条件を、分散サーバ記憶領域のイベントテーブルに格納し、前記分散サーバが、前記センサノードのひとつからデータを受信した際に、前記センサＩＤに対応して前記イベントテーブルから抽出される前記監視条件に前記受信したデータが合致している場合、前記管理サーバへイベントの発生を通知し、前記管理サーバが、前記分散サーバからイベントの発生を通知された場合に、予め設定された処理を実行する。

したがって、本発明は、データ収集を行う分散サーバでデータの監視を行うことで、多数の分散サーバを管理する管理サーバに負荷が集中するのを防ぐことができ、センサノードの数が膨大になってもセンサネットワークシステムの運営を円滑に行うことができる。

そして、ユーザ端末を利用するユーザは、モデル名と意味情報を設定するだけで、多数のセンサノードのデータから所望のデータを監視することができるので、多数のセンサノードの情報のうち所望の情報のみを極めて容易にリアルタイムで利用することが可能となる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本発明の第１実施形態を示すセンサネットワークシステムの構成図である。

＜システム構成の概要＞
センサノードＷＳＮ（無線センサノード）、ＭＳＮ（無線モバイルセンサノード）は、所定の位置に設置され、あるいは所定の物あるいは人に取り付けられ、環境に関する情報や取り付けられた物に関する情報を収集し、その情報を基地局ＢＳＴ−１〜ｎに送信するノードである。センサノードは無線により基地局ＢＳＴ−１〜ｎに接続される無線センサノードＷＳＮ、ＭＳＮと、有線によりネットワークＮＷＫ−ｎに接続される有線センサノードＦＳＮとから構成されている。なお、無線センサノードＷＳＮ、ＭＳＮ及び有線センサノードＦＳＮの総称を、単にセンサノードという。

固定的に設置される無線センサノードＷＳＮは、例えば、搭載されたセンサが周期的に周囲の状況をセンシングして、予め設定された基地局ＢＳＴへセンシング情報を送信する。無線モバイルセンサノードＭＳＮは、ヒトが持ち歩く、クルマに搭載されるなど、移動可能であることを前提とし、至近の基地局ＢＳＴに情報を送信する。なお、無線センサノードの全体（総称）を指すときにはＷＳＮまたはＭＳＮとし、個々の無線センサノードを指すときには、ＷＳＮ−１〜ｎあるいはＭＳＮ−１〜ｎのように添え字を付して表す。他の構成要素についても以下同様に、総称を示すときには添え字無しで表し、個々を示すときには添え字「−１〜ｎ」を付すものとする。

各基地局ＢＳＴ−１〜ｎには、１つまたは複数の無線センサノードＷＳＮ、ＭＳＮが接続され、各基地局ＢＳＴ−１〜ｎは、ネットワークＮＷＫ−２〜ｎを介して各センサノードからのデータを収集する分散データ処理サーバＤＤＳ−１〜ｎに接続される。なお、ネットワークＮＷＫ−２〜ｎは、基地局ＢＳＴと分散データ処理サーバ（分散サーバ）ＤＤＳとを接続するためのものである。分散データ処理サーバＤＤＳは、システム規模の大きさによって、その接続数を可変とすることができる。

各分散データ処理サーバＤＤＳ−１〜ｎは、無線及び有線センサノード（以下、単にセンサノードという）が検出したデータ等を格納するディスク装置ＤＳＫと、図示しないＣＰＵ及びメモリを備えて所定のプログラムを実行し、後述するようにセンサノードからの測定データを収集し、予め規定した条件に従って、データの格納、データの加工、さらには、ネットワークＮＷＫ−１を介して、ディレクトリサーバ（管理サーバ）ＤＲＳもしくは他のサーバへの通知やデータ転送などのアクションを行う。なお、ネットワークＮＷＫ−１は、ＬＡＮやインターネット等で構成される。

ここで、センサノードから収集したデータは、主には、センサノードやセンサ種別などを識別する固有のデータＩＤが付与されている数値データであり、時系列に応じた変化を示すが、そのままではセンサノードの出力を利用するユーザ（ユーザ端末ＵＳＴ等の利用者）が容易に理解する形式にはなっていない。そこで、ディレクトリサーバＤＲＳでは、予め設定された定義に基づいて、センサノードの出力データをユーザが理解可能な実世界モデル（ヒト、モノ、状態、など）に変換してからユーザに提示する。

なお、分散データ処理サーバＤＤＳ−１〜ｎがデータを収集する対象は、自身が接続されたネットワークＮＷＫ−２〜ｎの基地局ＢＳＴに所属するセンサノードや、他の基地局ＢＳＴから移動してきた無線センサノードＭＳＮである。また、有線のセンサノードＦＳＮは、分散データ処理サーバＤＤＳ−１〜ｎに接続するようにしても良い。もちろん、有線のセンサノードＦＳＮを基地局ＢＳＴに接続し、基地局ＢＳＴが有線のセンサノードＦＳＮを無線センサノードと同等に管理することもできる。

ネットワークＮＷＫ−１には、分散データ処理サーバＤＤＳから送られたセンシング情報に関連づけられた実世界モデルを管理するディレクトリサーバＤＲＳと、このディレクトリサーバＤＲＳの情報を利用するユーザ端末ＵＳＴと、ディレクトリサーバＤＲＳや分散データ処理サーバＤＤＳ及び基地局ＢＳＴ、センサノードの設定及び管理を行う管理端末ＡＤＴが接続される。なお、管理端末は、センサノードを管理するセンサ管理者と、センサネットワークのサービスを管理するサービス管理者用にそれぞれ用意しても良い。

ディレクトリサーバＤＲＳは、図示しないＣＰＵ、メモリ及びストレージ装置を備えて所定のプログラムを実行し、後述するように、有意な情報に関連づけられたオブジェクトを管理する。

すなわち、ユーザは、ユーザ端末ＵＳＴを通じて実世界モデルに対してアクセスを要求すると、ディレクトリサーバＤＲＳは実世界モデルに該当する測定データを所有する分散データ処理サーバＤＤＳ−１〜ｎにアクセスし、該当する測定データを取得し、そのセンシングデータを、必要あればユーザにわかりやすい形に変換してユーザ端末ＵＳＴに表示する。

図２は、図１に示したセンサネットワークの機能ブロック図である。ここでは、説明を簡易にするため、図１の分散データ処理サーバＤＤＳ−１〜ｎのうち分散データ処理サーバＤＤＳ−１の構成のみを示し、また、分散データ処理サーバＤＤＳ−１に接続された基地局ＢＳＴ−１〜ｎのうち基地局ＢＳＴ−１の構成のみを示す。他の分散データ処理サーバＤＤＳや基地局ＢＳＴも同様に構成される。

以下、各部の詳細について説明する。

＜基地局ＢＳＴ＞
無線センサノードＷＳＮ、ＭＳＮや有線センサノードＦＳＮ（以下、センサノードという）からデータを収集する基地局ＢＳＴ−１は、コマンド制御部ＣＭＣ−Ｂと、センサノード管理部ＳＮＭと、イベント監視部ＥＶＭとを備える。なお、センサノードは、予め設定されたデータＩＤを付して測定データを送信する。

コマンド制御部ＣＭＣ−Ｂでは、後述する分散データ処理サーバＤＤＳ−１のコマンド制御部ＣＭＣ−Ｄとの間でコマンドの送受を行う。例えば、分散データ処理サーバＤＤＳ−１からのコマンドに応じて、基地局ＢＳＴ−１のパラメータの設定を実行したり、基地局ＢＳＴ−１の状態を分散データ処理サーバＤＤＳ−１へ送信する。あるいは、基地局ＢＳＴ−１が管理するセンサノードのパラメータの設定を実行したり、センサノードの状態を分散データ処理サーバＤＤＳ−１へ送信する。

センサノード管理部ＳＮＭは、自身が管理するセンサノードの管理情報（稼動状態、残電力など）を保持する。そして、分散データ処理サーバＤＤＳ−１からセンサノードに関する問い合わせがあった場合には、各センサノードに代わって、管理情報を通知する。センサノードは管理に関連する処理を基地局ＢＳＴに委ねることで、自身の処理負荷を低減することができ、余計な電力消費を抑制することが可能となる。

また、センサノード管理部ＳＮＭは、イベント監視部ＥＶＭが異常を検出した場合には、センサノードの管理情報を更新し、分散データ処理サーバＤＤＳ−１へ異常のあったセンサノードに関する情報を通知する。なお、センサノードの異常とは、センサノードからの応答がない場合や、センサノードの電力が予め設定したしきい値以下になった場合など、センサノードの機能が停止または停止に至る状態を示す。

また、センサノード管理部ＳＮＭは、コマンド制御部ＣＭＣ−Ｄからセンサノードに対するコマンド（出力タイミングのパラメータ変更等）を受けた場合には、このコマンドをセンサノードに送信して設定を行い、設定の完了を示す通知をセンサノードから受信した後に、センサノードの管理情報を更新する。なお、センサノードの出力タイミングは、例えば、無線センサノードＷＳＮが基地局ＢＳＴ−１にデータを周期的に送信する際の期を示す。

基地局ＢＳＴは、予め設定された配下の無線センサノードＷＳＮ、ＭＳＮ及び有線センサノードＦＳＮについて管理を行い、各センサノードが測定したデータを分散データ処理サーバＤＤＳに送信する。

＜分散データ処理サーバＤＤＳ＞
分散データ処理サーバＤＤＳ−１は、データベースＤＢを格納するディスク装置ＤＳＫと、後述のようなコマンド制御部ＣＭＣ−Ｄ、イベントアクション制御部ＥＡＣ、データベース制御部ＤＢＣを備える。

コマンド制御部ＣＭＣ−Ｄは、基地局ＢＳＴ及び後述するディレクトリサーバＤＲＳと通信を行って、コマンド等の送受信を行う。

イベントアクション制御部ＥＡＣは、センサノードからの測定データを基地局ＢＳＴから受信するたびに、測定データに対応するＩＤ、すなわちデータＩＤを取得し、後述するテーブル（図１０のイベントテーブルＥＴＢ）からデータＩＤに対応するイベントの発生ルールを読み込んで、測定データの値に応じたイベントの発生の有無を判定する。さらに、イベントアクション制御部ＥＡＣでは、データＩＤに該当するイベントの発生通知に対応するアクションを実行する。なお、センサノードにセンサが１つだけ備えられている場合は、センサノードを識別するためのセンサノードのＩＤをデータＩＤとしてもよい。

また、本実施形態において、イベントとは測定データ（または加工データ）に関して予め設定された条件を示す。また、イベントの発生とは測定データが所定の条件を満足したことを示すものである。

そして、アクション実施の内容としては、ユーザなどにより予め設定されたデータＩＤ毎のルールに基づいて、測定データを加工データに変換したり、測定データと加工データをデータベース制御部ＤＢＣを通じてデータベースＤＢへ格納したり、また、ディレクトリサーバＤＲＳや他のサーバに通知を行うなどの処理を含む。

本実施形態では、図１で示すように、複数の基地局ＢＳＴに対して、これらのいくつかを地域的（または、場所的）に集約する複数の分散データ処理サーバＤＤＳを配置することで、多数のセンサノードからの情報を分散して処理することが可能になる。例えば、オフィスなどではフロア毎に分散データ処理サーバＤＤＳを設け、工場などでは建屋毎に分散データ処理サーバＤＤＳを設ければよい。

分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫは、基地局ＢＳＴから受信したセンサノードＷＳＮ、ＭＳＮ、ＦＳＮの測定データと、これらの測定データを加工した加工データと、基地局ＢＳＴや無線センサノードＷＳＮ、ＭＳＮ及び有線センサノードＦＳＮに関する装置データを、データベースＤＢとして格納する。

そして、データ処理サーバＤＤＳ−１のデータベース制御部ＤＢＣは、イベントアクション制御部ＥＡＣから送られたセンサノードの出力である測定データをデータベースＤＢに格納する。また、必要あれば測定データを数値処理したり、他データと融合することにより得られる加工データをデータベースＤＢに格納する。なお、装置データについては、管理者端末ＡＤＴなどからの要求に応じて随時更新される。

＜ディレクトリサーバＤＲＳ＞
複数の分散データ処理サーバＤＤＳを管理するディレクトリサーバＤＲＳは、ネットワークＮＷＫ−１を介して接続されたユーザ端末ＵＳＴや管理者端末ＡＤＴからの通信を制御するセッション制御部ＳＥＳと、後述するように、モデル管理部ＭＭＧ、モデルテーブルＭＴＢ、装置管理部ＮＭＧ、アクション制御部ＡＣＣ及び検索エンジンＳＥＲから構成される。

モデル管理部ＭＭＧは、ユーザが理解し易い実世界のモデル（オブジェクト）と分散データ処理サーバＤＤＳがセンサノードから収集した測定データ、もしくは加工データとの対応関係を実世界モデルテーブルＭＴＢに設定した実世界モデルリストＭＤＬによって管理する。つまり、実世界モデルテーブルＭＴＢは、ユーザが理解可能な意味情報をオブジェクトとし、センサノードからの測定データ（または加工データ）のＩＤと所在（格納場所）をオブジェクトに対応付け、また、後述の属性別意味解釈リストＡＴＬによりセンサノードからの測定データをユーザが理解可能な意味情報に変換するものである。

ディレクトリサーバＤＲＳは、実世界モデルに相当する測定データもしくは加工データの存在場所の位置情報（ＵＲＬなどのリンク）も管理している。つまり、ユーザは、実世界モデルを指定することで、時々刻々と変化するセンサノードの最新の測定情報や過去のログデータにダイレクトにアクセス可能となる。センサノードからの測定データ及び加工データは、時間の経過につれて増大するのに対し、実世界モデル情報は時間が経過してもサイズが変化することはなく、その内容のみが変化する。この実世界モデルの詳細については後述する。

なお、実世界モデルテーブルＭＴＢは、ディレクトリサーバＤＲＳの所定のストレージ装置（図示省略）などに格納される。

ディレクトリサーバＤＲＳのアクション制御部ＡＣＣは、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣやコマンド制御部ＣＭＣ−Ｄと通信を行って、ユーザ端末ＵＳＴや管理者端末ＡＤＴからのイベントアクションの設定要求を受け付ける。そして、受け付けたイベントまたはアクションの内容を解析し、解析結果に応じたディレクトリサーバＤＲＳと分散データ処理サーバＤＤＳ−１〜ｎ間の機能分担を設定する。なお、一つのアクションやイベントは、一つの分散データ処理サーバＤＤＳだけではなく、複数の分散データ処理サーバＤＤＳ−１〜ｎに関与する場合もある。

検索エンジンＳＥＲは、セッション制御部ＳＥＳが受け付けたオブジェクトに対する検索要求に基づいて、実世界モデルテーブルＭＴＢを参照し、分散データ処理サーバＤＤＳのデータベースＤＢに対して検索を実行する。

なお、検索要求がクエリーであれば、クエリーの内容に従ったデータベースＤＢの対応付けと、クエリーのＳＱＬ（Structured Query Language）変換を実行し、検索を実行する。なお、検索対象となるデータベースＤＢは、複数の分散データ処理サーバＤＤＳにまたがる場合がある。

そして、このクエリーとしては、「最新データ取得（スナップショット／ストリーム）」に対応する。なお、「最新データ取得（ストリーム）」はアクション制御部ＡＣＣのアクションの設定にて対応する。つまり、該当のデータを常に所望のサーバや端末に転送するようなアクションの設定を、該当する分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣに設定しておけばよい。

次に、装置管理部ＮＭＧは、ネットワークＮＷＫ−１に接続されてセンサネットワークを構成する分散データ処理サーバＤＤＳと、分散データ処理サーバＤＤＳに接続された基地局ＢＳＴ、基地局ＢＳＴに接続されたセンサノードを統合的に管理するものである。

装置管理部ＮＭＧでは、分散データ処理サーバＤＤＳ、基地局ＢＳＴ、センサノードの登録や検索に関するインターフェースを管理者端末ＡＤＴ等に提供し、それぞれの装置の状態や、センサノードの状態を管理する。

装置管理部ＮＭＧは、分散データ処理サーバＤＤＳや基地局ＢＳＴ、センサノードに対してコマンドを発行することができ、このコマンドによりセンサネットワークのリソースを管理する。なお、センサノードは上位となる基地局ＢＳＴのコマンド制御部ＣＭＣ−Ｂを介して装置管理部ＮＭＧからコマンドを受け、基地局ＢＳＴは上位の分散データ処理サーバＤＤＳのコマンド制御部ＣＭＣ−Ｄを介して装置管理部ＮＭＧからコマンドを受ける。

なお、コマンド制御部ＣＭＣ−Ｄを介して装置管理部ＮＭＧが発行するコマンドとしては、例えば、リセット、パラメータ設定、データ消去、データ転送、定型イベント／アクション設定等がある。

＜センサノードの一例＞
次に、センサノードの一例を図３〜図５に示す。

図３は、無線センサノードＷＳＮの一例を示すブロック図である。無線センサノードＷＳＮは、測定対象の状態量（温度、圧力、位置等）または状態量の変化（低温／高温、低圧／高圧など）を測定するセンサＳＳＲと、センサＳＳＲを制御するコントローラＣＮＴと、基地局ＢＳＴと通信を行う無線処理部ＷＰＲと、各ブロックＳＳＲ、ＣＮＴ、ＷＰＲに電力を供給する電源ＰＯＷ、送受信を行うアンテナＡＮＴから構成される。

コントローラＣＮＴは、予め設定された周期でセンサＳＳＲの測定データを読み込み、この測定データに予め設定したデータＩＤを加えて無線処理部ＷＰＲに転送する。測定データにはセンシングを行った時間情報をタイムスタンプとして与える場合もある。無線処理部ＷＰＲは、コントローラＣＮＴから送られたデータを基地局ＢＳＴに送信する。

また、無線処理部ＷＰＲは基地局ＢＳＴから受信したコマンドなどをコントローラＣＮＴに送信し、コントローラＣＮＴは受信したコマンドを解析して、所定の処理（例えば、設定変更など）を行う。また、コントローラＣＮＴは、電源ＰＯＷの残電力（または充電量）の情報を、無線処理部ＷＰＲを介して基地局ＢＳＴに対して送信する。なお、コントローラＣＮＴ自身が電源ＰＯＷの残電力（または充電量）を監視し、残電力が予め設定されたしきい値を下回った場合に、基地局ＢＳＴに対して電力がなくなる警報を送信するようにしておいても良い。

無線処理部ＷＰＲでは、限りのある電力で長時間測定を行うため、図４で示すように、間欠的に動作して、電力消費を低減している。図中、スリープ状態ＳＬＰではコントローラＣＮＴはセンサＳＳＲの駆動を停止し、所定の周期でスリープ状態から動作状態に切り替わって、センサＳＳＲを駆動して測定データを送信する。

なお、図３においては、一つの無線センサノードＷＳＮに一つのセンサＳＳＲを備えた例を示したが、複数のセンサＳＳＲを配置しても良い。あるいは、センサＳＳＲに代わって、固有の識別子ＩＤを格納したメモリを設けても良く、無線センサノードＷＳＮをタグとして使用しても良い。

また、図３、図４においては、電源ＰＯＷは、電池を使用する場合や、太陽電池や振動発電などの自律発電機構を具備する構成としても良い。また、無線モバイルセンサノードＭＳＮも図３、図４と同様に構成すればよい。

図５は、上記図１、図２に示した分散データ処理サーバＤＤＳ−１に接続されたセンサノードの一例を示す詳細図である。

本実施形態では、オフィスおよびＡ会議室、Ｂにセンサノードを設けた例を示している。

オフィスには基地局ＢＳＴ−０が設置され、オフィスの椅子にはセンサＳＳＲとして感圧（圧力）スイッチを備えた無線センサノードＷＳＮ−０が配置される。無線センサノードＷＳＮ−０は、基地局ＢＳＴ−０と通信するように設定される。

Ａ会議室には基地局ＢＳＴ−１が設置され、Ａ会議室の椅子にはセンサＳＳＲとして感圧スイッチを備えた無線センサノードＷＳＮ−３〜１０が配置される。また、Ａ会議室には温度センサを備えた有線センサノードＦＳＮ−１が設置され、基地局ＢＳＴ−１に接続されている。各無線センサノードＷＳＮ−３〜１０及び有線センサノードＦＳＮ−１は、基地局ＢＳＴ−１と通信するように設定される。

同様に、会議室Ｂには基地局ＢＳＴ−２が設置され、会議室Ｂの椅子にはセンサＳＳＲとして感圧スイッチを備えた無線センサノードＷＳＮ−１１〜１８と、温度センサを備えた有線センサノードＦＳＮ−２が設置され、基地局ＢＳＴ−２に接続されている。

これらＡ会議室、Ｂを利用する従業者には名札を兼ねた無線センサノードＭＳＮ−１が装着される。無線センサノードＭＳＮ−１は、従業者の体温（または周囲の温度）を測定する温度センサＳＳＲ−１と、従業者に固有の識別子（従業者ＩＤ）を格納したタグＴＧ−１を備える名札として構成される。無線センサノードＭＳＮ−１は基地局ＢＳＴ−０、１または２に、従業者ＩＤと測定データとしての温度を送信することができる。

＜センサネットワークの動作概念＞
次に、上記図１〜図５に示したセンサネットワークの動作の概要について、図６〜図８を用いて説明する。

図６は、実世界モデルの具体的な形であるオブジェクトとセンサノードの測定データの関連を示すブロック図で、測定の開始時を示し、図７は、図６の状態から所定時間が経過した状態を示す。

図６において、ディレクトリサーバＤＲＳは、実世界モデルとして予め次のようなオブジェクトを生成し、実世界モデルテーブルＭＴＢの実世界モデルリストＭＤＬに定義しておく。ここでは、図５のオフィスまたはＡ会議室、Ｂ会議室を利用する従業者として鈴木さんの場合を示し、図６に示した無線センサノードＭＳＮ−１を、この人物が装着しているものとする。

図１２のセンサ情報テーブルＳＴＢに示されるように、各センサノードＭＳＮの測定データ（ｅｘ．温度）や位置情報がデータ格納先として指定される分散データ処理サーバＤＤＳに格納されるようセンサ情報テーブルは定義されている。ここで、センサノードＭＳＮの位置情報は、センサノードＭＳＮを検出する基地局ＢＳＴのＩＤ情報として得ることができる。

そして、実世界モデルテーブルＭＴＢの実世界モデルリストＭＤＬには、鈴木さんの位置というオブジェクト（ＯＢＪ−１）は、測定データ１（ＬＩＮＫ−１）という格納先にデータの実体があることが定義され、実世界モデルと実際のデータの格納位置との対応関係が管理されている。

つまり、実世界モデルリストＭＤＬにおいて、鈴木さん位置（ＯＢＪ−１）というオブジェクトは、測定データ１（ＬＩＮＫ−１）に対応する分散データ処理サーバＤＤＳの格納位置に関連付けられている。図６、図７においては、鈴木さんの位置を示す無線センサノードＭＳＮ−１からの位置情報（例えば「どこの基地局ＢＳＴに接続される」として定義される）は、分散データ処理サーバＤＤＳのディスク装置ＤＳＫ１に格納される。

ユーザ端末ＵＳＴから見ると、鈴木さん位置（ＯＢＪ−１）の値はディレクトリサーバＤＲＳの実世界モデルテーブルＭＴＢに存在するように見えるが、実際のデータはディレクトリサーバＤＲＳではなく、予め設定された分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ１に格納されるのである。

鈴木さん着座（ＯＢＪ−２）というオブジェクトは、オフィスの椅子に装着された感圧スイッチ（ＷＳＮ−０）から求めた着座情報が測定データ２（ＬＩＮＫ−２）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ２に対応する分散データ処理サーバＤＤＳと格納位置が定義される。図６、図７においては、ＭＳＮ−１及び無線センサノードＷＳＮからの着座情報は分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ２に格納する。

鈴木さん温度（ＯＢＪ−３）というオブジェクトは、無線センサノードＭＳＮ−１の温度センサＳＳＲ−１が測定した温度が測定データ３（ＬＩＮＫ−３）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ３に対応する分散データ処理サーバＤＤＳと格納位置が定義される。図６、図７においては、ＭＳＮ−１からの温度は分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ３に格納する。

Ａ会議室メンバ（ＯＢＪ−４）というオブジェクトは、Ａ会議室の基地局ＢＳＴ−１が接続した無線センサノードＭＳＮの情報から求めた従業者の名前が測定データ４（ＬＩＮＫ−４）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。感圧スイッチ（ＷＳＮ−３〜１０）を使用しない場合には、ある単位時間内にＡ会議室内の基地局ＢＳＴ−１で検出された無線センサノードＭＳＮ数によりＡ会議室の人数を求めても良い。さらに、測定データ４に対応する分散データ処理サーバＤＤＳと格納位置が定義される。図６、図７においては、各従業者の無線センサノードＭＳＮからの個人情報は分散データ処理サーバＤＤＳのディスク装置ＤＳＫ４に格納する。

Ａ会議室人数（ＯＢＪ−５）というオブジェクトは、Ａ会議室の感圧スイッチ（ＷＳＮ−３〜１０）から求めた人数が測定データ５（ＬＩＮＫ−５）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ５に対応する分散データ処理サーバＤＤＳと格納位置が定義される。図６、図７においては、無線センサノードＷＳＮ３〜１０の着座情報は分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ５に格納する。

Ａ会議室温度（ＯＢＪ−６）というオブジェクトは、Ａ会議室の有線センサノードＦＳＮ−１が測定した温度が測定データ６（ＬＩＮＫ−６）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ６に対応する分散データ処理サーバＤＤＳと格納位置が定義される。図６、図７においては、ＦＳＮ−１からの温度は分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ６に格納する。

すなわち、実世界モデルテーブルＭＴＢに定義された各オブジェクトＯＢＪは、測定データに対応する格納先（ＬＩＮＫ）を格納しており、ユーザ端末ＵＳＴからは目的のデータがディレクトリサーバＤＲＳに存在するように見えるが、実際のデータは分散データ処理サーバＤＤＳに格納される。

そして、情報の格納先ＬＩＮＫには、センサノードが測定した測定データまたは測定データを数値変換した加工データなど、ユーザが利用可能なデータの格納位置が設定されている。センサノードからの測定データの収集は各分散データ処理サーバＤＤＳで行われ、さらに、後述するようにイベントアクションが設定されていれば、測定データに対して加工などが加えられ、加工データとして所定の分散データ処理サーバＤＤＳに格納されていく。

実際のセンサノードからのデータ収集と加工は分散データ処理サーバＤＤＳで行われ、ディレクトリサーバＤＲＳでは、実世界モデルと情報の格納先及びセンサノードの定義などが管理される。

これにより、ユーザ端末ＵＳＴの利用者はセンサノードの所在を知る必要がなく、オブジェクトＯＢＪを検索することで、センサノードの測定値（または加工データ）に対応する所望のデータを得ることができるのである。

そして、ディレクトリサーバＤＲＳは、オブジェクトＯＢＪ毎の格納先（リンク先）を管理し、実際のデータは分散データ処理サーバＤＤＳが分散的に格納・処理するので、センサノードの数が膨大になったとしても、センサデータ処理の負荷が過大になるのを防ぐことができるのである。また、多数のセンサノードを使用しながら、ディレクトリサーバＤＲＳと分散データ処理サーバＤＤＳ及びユーザ端末ＵＳＴを接続するネットワークＮＷＫ−１のトラフィックが過大になるのを抑制できるのである。

図６の状態から所定時間経過した図７では、分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ１〜６にセンサノードからの実際の測定データが書き込まれ、時間の経過とともにデータ量は増大する。

一方、ディレクトリサーバＤＲＳの実世界モデルテーブルＭＴＢのモデルリストＭＤＬに設定されたオブジェクトＯＢＪ−１〜６に対応する格納先ＬＩＮＫ−１〜６は、時間が経過しても情報量は変化することなく、格納先ＬＩＮＫ−１〜６が指し示す情報の内容が変化する。

つまり、ディレクトリサーバＤＲＳが管理するオブジェクトＯＢＪ−１〜６の情報量と、分散データ処理サーバＤＤＳ−１が管理する測定データ１〜６のデータ量と時間の関係は、図８のように、オブジェクトのデータ量が一定であるのに対し、測定データは時間の経過につれて増加する。

例えば、ひとつの基地局ＢＳＴに数百のセンサノードが接続され、ひとつの分散データ処理サーバＤＤＳに数個の基地局ＢＳＴが接続され、ひとつのディレクトリサーバＤＲＳに数十の分散データ処理サーバＤＤＳが接続される場合、センサノードの総数は数千乃至数万となる。仮に、各センサノードが１分毎に順次データを送るとすれば、毎秒百乃至千程度の測定データが分散データ処理サーバＤＤＳに送られて、イベントの有無が判定され、イベントが発生した場合には所定のアクションにより通知やデータの加工などの処理が生じることになる。これらの処理を一つあるいは、少数のサーバで実現しようとすれば、サーバ自体の負荷やサーバと接続するためのネットワークの負荷が極めて大きくなる。さらに、収集したデータや加工したデータについて、ユーザ端末ＵＳＴからアクセスが発生するため、ユーザ端末ＵＳＴへデータを提供するためにもサーバの負荷やネットワークの負荷はさらに大きくなる。

そこで、ユーザ端末ＵＳＴからアクセスを受け付け、センサノードの情報の格納先を管理するディレクトリサーバＤＲＳと、複数の基地局ＢＳＴを管理して、基地局ＢＳＴに割り当てられたセンサノードからデータを収集し、加工する分散データ処理サーバＤＤＳとで処理の分担を行う。

センサノードからの情報は、複数の分散データ処理サーバＤＤＳで分散して収集し、各分散データ処理サーバＤＤＳでそれぞれデータの格納あるいは加工を行うことで、多数のセンサノードのデータ収集及び加工処理を分散し、特定のサーバに負荷が集中するのを防ぐことができる。

一方、ディレクトリサーバＤＲＳは、センサノードの測定データから得られた情報の格納先を集中的（一元的）に管理し、ユーザ端末ＵＳＴにオブジェクトと格納先ＬＩＮＫの対応関係を提供する。ユーザは、センサノードの物理的な位置等を知らなくとも、ディレクトリサーバＤＲＳに目的のオブジェクトについて問い合わせを行えば、データの格納位置から有意な情報を得ることができる。つまり、情報の格納先をディレクトリサーバＤＲＳで集中管理することにより、センサノードの所在に係わらず、ユーザ端末ＵＳＴはディレクトリサーバＤＲＳにアクセスすれば、目的のセンサノードに関する測定データまたは加工データを得ることができるのである。

そして、ディレクトリサーバＤＲＳは、分散データ処理サーバＤＤＳから得られたデータを属性別意味解釈リストＡＴＬに基づいて、ユーザが理解可能な情報（意味情報）に変換してユーザ端末ＵＳＴに提供する。

また、ディレクトリサーバＤＲＳに格納するオブジェクトは、構築するシステム構成に応じて設定・変更されるものであり、センサノードが検出する測定データのように経時的に変化するものではないので、オブジェクトを集中的に管理する部分は経時的な測定データの負荷変動の影響を受けない。したがって、分散データ処理サーバＤＤＳとの間で直接的にセンサノードのデータをやり取りすることが抑制されるので、ディレクトリサーバＤＲＳに接続されたネットワークＮＷＫ−１の負荷が過大になるのを抑制できる。

なお、図６、図７では、別々の分散データ処理サーバＤＤＳに対して、それぞれにディスク装置ＤＳＫが接続された場合を示したが、図５のように、１つの分散データ処理サーバＤＤＳを設け、これに複数のディスク装置ＤＳＫを設けてもよく、複数の分散データ処理サーバＤＤＳにグループ分けしてディスク装置ＤＳＫを接続することも可能である。

＜測定データとイベントの関係＞
次に、分散データ処理サーバＤＤＳで収集される測定データと、測定データに基づくイベントアクションの関係を図９、図１０に示す。

図９において、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣは、基地局ＢＳＴから収集される測定データをイベントに対応付けるイベントテーブルＥＴＢを備える。

イベントテーブルＥＴＢは、図１０で示すように、測定データに付与されるデータＩＤ（図１２のＩＤ及び図１４のデータＩＤに対応）と、測定データに関してイベントの発生判断条件であるＥＶＴと、測定データをデータベースＤＢに格納するか否かを決定するデータ格納ＤＨＬとから１レコードが構成されている。

例えば、図中、データＩＤが「ＸＸＸ」の測定データは、その値がＡ１より大のときにイベントの発生をディレクトリサーバＤＲＳに通知する。なお、データＩＤが「ＸＸＸ」の測定データは、データ到着毎に、ディスク装置ＤＳＫに書き込まれるように設定される。ディスクＤＳＫへの格納は、イベントテーブルＥＴＢのアクション欄に設定された設定に基づくものである。

分散データ処理サーバＤＤＳでは、基地局ＢＳＴから受信した測定データを、まず、センシングデータＩＤ抽出部ＩＤＥで受け付け、測定データに付与されているＩＤであるデータＩＤを抽出する。また、センシングデータＩＤ抽出部ＩＤＥは、測定データを最新データメモリＬＤＭに送る。

抽出されたデータＩＤはイベント検索部ＥＶＳに送られて、イベントテーブルＥＴＢを検索し、データＩＤが一致するレコードがあれば、当該レコードのイベント内容ＥＶＴと測定データをイベント発生判定部ＥＶＭに送る。

イベント発生判定部ＥＶＭでは、測定データの値とイベント内容ＥＶＴを比較して、条件を満たせばイベントの発生を、ネットワーク処理部ＮＷＰからネットワークＮＷＫ−１を通じて、ディレクトリサーバＤＲＳに通知する。また、イベント発生判定部ＥＶＭは、データ格納ＤＨＬの要求を最新データメモリに伝える。

ＤＢ制御部ＤＢＣは、イベントテーブルＥＴＢのデータ格納ＤＨＬがＹＥＳとなっているデータについては、最新データメモリＬＤＭからデータを受け取り、ディスク装置ＤＳＫに書き込みを行う。

分散データ処理サーバＤＤＳは、ネットワーク処理部ＮＷＰがディレクトリサーバＤＲＳより測定データの参照要求を受信した場合、データアクセス受け付け部ＤＡＲに当該アクセス要求を送る。

データアクセス受け付け部ＤＡＲでは、アクセス要求が最新のデータであれば、アクセス要求に含まれるデータＩＤに対応する測定データを最新データメモリＬＤＭから読み込んで、ネットワーク処理部ＮＷＰへ返送する。あるいは、アクセス要求が過去のデータであれば、アクセス要求に含まれるデータＩＤに対応する測定データをディスク装置ＤＳＫから読み込んで、ネットワーク処理部ＮＷＰへ返送する。

このように、分散データ処理サーバＤＤＳでは、基地局ＢＳＴから収集したセンサノードのデータのうち、最新のデータを最新データメモリＬＤＭに保持し、さらに、後で参照が必要と予想されるデータについてのみディスク装置ＤＳＫに記録する。また、イベント発生時のデータのみ、データをディスク装置ＤＳＫに記録する設定も可能である。この場合には、周期的（観測間隔）に収集するデータによるディスク使用量増加を防ぐことができる。以上の方法により、ひとつの分散データ処理サーバＤＤＳで複数の基地局ＢＳＴ（つまり、多数のセンサノード）を管理することが可能となる。

＜装置管理部ＮＭＧ及びモデル管理部ＭＭＧの詳細＞
＜装置管理部ＮＭＧ＞
図１１は、図２に示したディレクトリサーバＤＲＳの、装置管理部ＮＭＧとモデル管理部ＭＭＧ及び実世界モデルテーブルＭＴＢの詳細を示す。

まず、ディレクトリサーバＤＲＳの装置管理部ＮＭＧは、センサノードを管理するセンサ情報テーブルＳＴＢと、センサ情報テーブルＳＴＢにセンサノードを登録／変更するための登録インターフェースと、センサ情報テーブルＳＴＢの内容を検索する検索インターフェースを備える。なお、ここでは、センサ情報テーブルＳＴＢは、センサ管理者端末ＡＤＴ−Ａにより管理されるものとする。

センサ情報テーブルＳＴＢは、図１２で示すように、センサノード毎、または、センサ毎などセンサデータソースに対して予め割り当てられたデータＩＤと、センサノードの種類を示すセンサ種別と、センサノードの測定対象を示す意味と、センサノードが測定する計測値の内容と、センサノードを設置した位置（または対象）を示す設置場所と、センサノードが測定対象から測定値を検出する周期を示す観測間隔と、測定したデータの格納先（分散データ処理サーバＤＤＳ−１〜ｎ上の格納位置）を示すデータ格納先が、１レコードで構成され、データＩＤをインデックスとして管理される。

例えば、図５に示した名札として構成された無線センサノードＭＳＮ−１のタグＴＧ−１は、センサノードのデータＩＤが０１に割り当てられ、測定対象が無線センサノードＭＳＮ−１の場所（位置）であり、測定の周期が３０秒おきであり、測定データは分散データ処理サーバＤＤＳ−１に格納されることを示している。同様に、名札として構成された無線センサノードＭＳＮ−１に配置されたセンサＳＳＲ−１は、データＩＤが０２に割り当てられ、測定対象が周囲の温度であり、測定の周期が６０秒おきであり、測定データは分散データ処理サーバＤＤＳ−２に格納されることを示している。

このセンサ情報テーブルＳＴＢは、上記センサ管理者端末ＡＤＴ−Ａから設定されたものであり、センサ管理者やサービス管理者はセンサ情報テーブルＳＴＢを参照することにより、センサノードの機能と位置及び測定データの格納先を知ることができる。

また、センサノードがデータを測定する周期が一定でない場合には、図１２に示すデータＩＤ＝０３の着座センサのように、観測間隔を「イベント」とすることにより、周期に関わらず、センサが特定の状態を検出したときのみ、この状態を分散データ処理サーバＤＤＳに通知する。

＜モデル管理部ＭＭＧ＞
次に、図１１に示すモデル管理部ＭＭＧ及び実世界モデルテーブルＭＴＢについて説明する。

モデル管理部ＭＭＧが管理する実世界モデルテーブルＭＴＢは、センサノードの測定データがどのような意味を持つのかを解釈するための属性別意味解釈リストＡＴＬと、図６に示したオブジェクトＯＢＪ−１〜ｎのモデル名と実際の情報の格納位置との対応関係を示す実世界モデルリストＭＤＬと、オブジェクトＯＢＪ−１〜ｎ間の相関関係を示すモデルバインドリストＭＢＬとから構成される。

そして、モデル管理部ＭＭＧは、これら実世界モデルテーブルＭＴＢの各リストを管理するため、属性別意味解釈リストＡＴＬを管理する属性別意味解釈リスト管理部ＡＴＭと、実世界モデルリストＭＤＬを管理する実世界モデルリスト管理部ＭＬＭと、モデルバインドリストＭＢＬを管理するモデルバインドリスト管理部ＭＢＭを備え、各管理部は、リストの登録／変更を行うための登録インターフェースと、各リストの検索を行うための検索インターフェースをそれぞれ備えている。

なお、ここでは、実世界モデルテーブルＭＴＢは、サービス管理者端末ＡＤＴ−Ｂを利用するサービス管理者により管理されるものとする。なお、図１１において、センサ管理者端末とサービス管理者端末は、図１に示したように一つの管理端末ＡＤＴを用いても良い。

また、センサネットワークを利用するユーザ端末ＵＳＴは、各リストの検索インターフェースを介して所望のリストからオブジェクトＯＢＪの検索を行う。

まず、属性別意味解釈リスト管理部ＡＴＭが管理する属性別意味解釈リストＡＴＬは、センサノードＷＳＮ、ＭＳＮ、ＦＳＮからの戻り値（測定値）や分散データ処理サーバＤＤＳで変換した加工データは、そのままの値ではユーザ端末ＵＳＴの利用者（以下、単にユーザとする）が理解することができないため、図１３に示すように、センサノードの出力値を有意な情報に変換するためのテーブルを備える。図１３は、オブジェクトＯＢＪ−１〜ｎに対応して予め設定されたものである。

図１３において、名前テーブルＡＴＬ−ｍは、図６に示した鈴木さん位置ＯＢＪ−１に対応付けられたもので、図１２で示したように、センサ種別が名札であるセンサノードＭＳＮ−１に設定されたタグＴＧに設定された識別子からの戻り値（測定値）に応じた人名が意味の欄に対応付けられている。

図１３において、場所テーブルＡＴＬ−ｐは、名札を装着した従業者の位置を示すテーブルで、戻り値（例えばセンサノードが接続される基地局のＩＤ）に対応した場所の名称が意味の欄に対応付けられている。例えば、戻り値が０１の場合は、場所がオフィスであることを意味している。

また、図１３の着座テーブルＡＴＬ−ｓは、図５に示したオフィス内もしくは、Ａ会議室の椅子の着席状態を示し、各椅子（各無線センサノードＷＳＮ−３〜１０）毎に設けられ、無線センサノードＷＳＮ−３〜１０の戻り値（測定値）に応じた着席状態（在籍または不在）が格納される。例えば、戻り値が００の場合、在席（着席）状態であることを示し、戻り値が０１の場合は不在であることを示す。

同様に、図１３の温度テーブルＡＴＬ−ｔは、図５に示した温度センサ（ＭＳＮ−１のＳＳＲ−１、ＦＳＮ−１、２）の示す値を示すテーブルであり、戻り値（温度センサの測定データ）を温度ｙに変換する関数ｆ（ｘ）が意味の欄に格納される。

図１３において、人数テーブルＡＴＬ−ｎは、Ａ会議室にいる従業者の人数を示すテーブルで、戻り値（Ａ会議室内椅子センサの着席数、あるいは、Ａ会議室内のモバイルノードＭＳＮの数）に対応した人数が意味の欄に対応付けられている。

このように、属性別意味解釈リストＡＴＬには、測定データに対する意味を定義するリストであり、生成したオブジェクトに応じてそれぞれのテーブルが設定される。

次に、実世界モデルリストＭＤＬは、サービス管理者などが予め設定したもので、図１４で示すように、オブジェクト毎に設定されたモデル名に対応する情報の位置が、情報リンク先に格納される。つまり、モデル名と情報リンク先及びデータＩＤが対になったものが実世界モデルリストＭＤＬを構成する。

ディレクトリサーバＤＲＳは、モデルリストＭＤＬによりユーザが理解可能な有意な情報のみを管理しており、この有意な情報の所在は分散データ処理サーバＤＤＳ−１〜ｎの何れかとなる。このため、モデルリストＭＤＬに定義したオブジェクトＯＢＪは、有意な情報の実体が何処にあるかを情報リンク先に設定しておく。なお、この情報リンク先はサービス管理者などが予め設定したものである。同様に、データＩＤは、オブジェクトの値の元になるセンサデータ（センサノードから直接得られるデータ、もしくは、加工されて得られるデータ）に対応する値である。

図１４においては、例えば、鈴木さんの位置ＯＢＪ−１に対してＬＩＮＫ−１という情報リンク先が格納されており、この情報リンク先にはＵＲＬやパスなどが格納され、ユーザ端末ＵＳＴから、このオブジェクトを検索すると情報リンク先から有意な情報（オブジェクトの実体）を得ることができる。

例えば、ユーザ端末ＵＳＴからキーワードなどをディレクトリサーバＤＲＳの検索エンジンＳＥＲに送信すると、モデルリストＭＤＬのモデル名の中からキーワードを含むモデル名のリストが検索エンジンＳＥＲから返信される。ユーザ端末ＵＳＴを操作するユーザは、所望のモデル名を選択すると、まず、情報リンク先ＬＩＮＫに設定された分散データ処理サーバＤＤＳから、ディレクトリサーバＤＲＳの情報リンク先に対応するデータを取得する。

ディレクトリサーバＤＲＳは、取得したデータを属性別意味解釈リストＡＴＬに基づいて、ユーザが理解可能な情報に変換してからユーザ端末ＵＳＴに送信する。

したがって、ユーザは個々のセンサノードに関する知識や所在を知らなくとも、必要な情報を認識できる情報として取得できるのである。

そして、分散データ処理サーバＤＤＳでは、センサノードから収集したデータを、収集する度にユーザに理解可能な形に変換する必要がないので、多数のセンサノードのデータを収集・管理する分散データ処理サーバＤＤＳの負荷を大幅に低減できる。このデータの変換処理は、ユーザから要求に基づいてディレクトリサーバＤＲＳが必要に応じて行うことにより、不要な変換処理が行われるのを抑制でき、センサネットワークのリソースを無駄なく機能させることが可能となる。

次に、オブジェクトＯＢＪ−１〜ｎ間の相関関係を示すモデルバインドリストＭＢＬは、実世界モデルリストＭＤＬのオブジェクトＯＢＪに共通する要素について、関連する情報を集約したものである。

モデルバインドリストＭＢＬの一例としては、図１５に示すように、実世界モデルリストＭＤＬのオブジェクトＯＢＪのうち、共通する要素として「人名」（図中「鈴木さん」）と「Ａ会議室」に関連するものを抽出したものである。例えば、図１３の属性別意味解釈リストＡＴＬの名前テーブルＡＴＬ−ｍの意味欄に登録された「鈴木さん」という人名に関連するオブジェクトＯＢＪとして、位置ＯＢＪ−１、オフィス内自席の着座状態ＯＢＪ−２、温度ＯＢＪ−３があり、鈴木さんという人名に関連したオブジェクトのリンク先を、図示のように「位置」ＬＩＮＫ−１、「着座状態」ＬＩＮＫ−２、「温度」ＬＩＮＫ−３とツリー状に設定し、これを人名に関するモデルバインドリストＭＢＬ−Ｐとする。

同様に、Ａ会議室という要素から実世界モデルリストＭＤＬを見ると、「メンバ」、「人数」、「温度」というオブジェクトＯＢＪ−４〜６があり、Ａ会議室という場所に関連したオブジェクトの情報リンク先ＬＩＮＫ−４〜６を、図示のように「メンバ」、「人数」、「温度」とツリー状に設定し、これをＡ会議室に関するモデルバインドリストＭＢＬ−Ｒとする。

このように、モデルバインドリストＭＢＬは、実世界モデルリストＭＤＬのオブジェクトの要素のうち、共通情報について関連付けを行った情報となる。なお、このモデルバインドリストＭＢＬの関連付けは、サービス管理者などが予め設定する。

＜モデル管理部ＭＭＧの動作＞
次に、センサネットワークシステムの動作について、以下に説明する。

＜センサノードの登録＞
まず、センサノードの登録の手順について、図１６、図１７を参照しながら説明する。センサ管理者は、センサノードを所定の場所または人にセンサノードを設置した後、図１６のタイムチャートに従ってディレクトリサーバＤＲＳにセンサノードの登録を行う。

図１６において、まず、センサ管理者はセンサ管理者端末ＡＤＴ−ＡからディレクトリサーバＤＲＳに接続し、装置管理部ＮＭＧの登録インターフェースを呼び出す。そして、センサ管理者端末ＡＤＴ−Ａから図１７に示すデータフォーマットに従って、新たに追加するセンサノードのデータＩＤ、センサ種別、属性、計測値、設置場所、観測間隔、データ格納先を設定し、ディレクトリサーバＤＲＳの装置管理部ＮＭＧに登録要求として送信する（ＲＧ−１）。ここで、登録に先立って、センサノードデータを受信する分散データサーバＤＤＳに対して、データ格納先の確保と属性の指定を行っておくものとする。

ディレクトリサーバＤＲＳは、装置管理部ＮＭＧは、この登録要求を受信すると、図１２に示したセンサ情報テーブルＳＴＢに当該登録要求のあったセンサノードの情報を追加する。そして、装置管理部ＮＭＧは新たに追加したセンサノードについてデータＩＤを割り当てる。このデータＩＤは、センサ管理者端末ＡＤＴ−Ａから割り当てるようにしても良い。

装置管理部ＮＭＧは、データ格納先に指定された分散データ処理サーバＤＤＳに対して、登録要求のあったセンサノードの測定データの格納先の割り当てを行った後、センサ情報テーブルＳＴＢの１レコードを完成させる。

そして、装置管理部ＮＭＧは、新たなレコードが追加されたことを示す完了通知（ＡＣＫ）をセンサ管理者端末ＡＤＴ−Ａに返信し、登録処理を終了する。

なお、図示はしないが、ディレクトリサーバＤＲＳからセンサノードの登録通知を受けた分散データ処理サーバＤＤＳは、該当するデータＩＤのデータを送出するセンサノードについて、所定の観測間隔で測定値を送出するよう指令する。基地局ＢＳＴのセンサ管理部ＳＮＭには、指令のあったデータＩＤ、および、観測間隔を登録しておく。

これにより、新たなセンサノードは、所属する基地局ＢＳＴとの間で通信を行って、このセンサノードが所属する分散データ処理サーバＤＤＳに対して測定データを送信することができる。

＜オブジェクトの定義＞
次に、上記図１６、図１７でディレクトリサーバＤＲＳに登録したセンサノードについて、センサノードの測定データとオブジェクトとの関係を生成する処理について、図１８を参照しながら説明する。なお、この処理は、センサネットワークのサービス管理者が行うものとする。

図１８において、サービス管理者はサービス管理者端末ＡＤＴ−ＢからディレクトリサーバＤＲＳに接続し、装置管理部ＮＭＧの検索インターフェースを呼び出す。そして、所望のセンサノードの検索をデータＩＤなどに基づいて行い、検索条件に一致したセンサノードをサービス管理者端末ＡＤＴ−Ｂに返信する。

サービス管理者端末ＡＤＴ−Ｂでは、装置管理部ＮＭＧから受信したセンサノードの検索結果を図示しない表示装置などに出力する。

サービス管理者は、サービス管理者端末ＡＤＴ−Ｂに表示されたセンサノードから所望のセンサノードを選択し、このセンサノードの測定データに対応付けるオブジェクトを設定して、ディレクトリサーバＤＲＳのモデル管理部ＭＭＧに登録する。

例えば、図１２に示したセンサ情報テーブルＳＴＢのデータＩＤ＝０１の名札型センサノード（図５のＭＳＮ−１）のオブジェクトとして、「鈴木さんの位置」というオブジェクトＯＢＪ−１を登録する。この登録によって、オブジェクトとその情報リンクの関係を示す実世界モデルリスト（ＭＤＬ）が生成される（図１４）。

そして、モデル管理部ＭＭＧは、「鈴木さんの位置」というオブジェクトＯＢＪ−１について、タグのＩＤがＴＧ−１（鈴木さんの識別子）のセンサノードＭＳＮを受信した基地局ＢＳＴの位置が、例えば、分散データ処理サーバＤＤＳ−１に格納されるように関連付けの設定指令を行う。

指令を受けた分散データ処理サーバＤＤＳ−１では、イベントアクション制御部ＥＡＣにて、タグのＩＤが鈴木さんを示すＴＧ−１のデータを受信したら、受信した基地局ＢＳＴの位置を椎別する値を、分散データ処理サーバＤＤＳ−１のデータベースＤＢへ格納するようアクションの登録が行われる。

そして、分散データ処理サーバＤＤＳ−１のデータベースＤＢに格納された「鈴木さんの位置」というデータの実体に対して、実世界モデルリストＭＤＬのオブジェクトＯＢＪ−１に対応する情報格納先が設定される。

あるいは、「鈴木さん着座」というオブジェクトＯＢＪ−２については、モデル管理部ＭＭＧは、センサＳＳＲとして感圧スイッチを備えた無線センサノードＷＳＮ−０の測定値がＯＮであれば「００」という値を分散データ処理サーバＤＤＳ−１のデータベースＤＢに書き込み、無線センサノードＷＳＮ−０の測定値がＯＦＦであれば「０１」という情報を分散データ処理サーバＤＤＳ−１のデータベースＤＢに書き込むよう分散データ処理サーバＤＤＳ−１に指令する。

この指令を受けた分散データ処理サーバＤＤＳ−１では、イベントアクション制御部ＥＡＣにて、センサノードＷＳＮ−０の測定データ値である「００」または「０１」（それぞれ、ＯＮ／ＯＦＦに相当）を、データ処理サーバＤＤＳ−１のデータベースＤＢに書き込む処理を行う。

そして、上記と同様に、分散データ処理サーバＤＤＳ−１のデータベースＤＢに格納された「鈴木さん着座」というデータの実体に対して、実世界モデルリストＭＤＬのオブジェクトＯＢＪ−２に対応する情報格納先が設定される。

こうして、モデル管理部ＭＭＧが設定したオブジェクト（情報格納先）と、実際に情報を格納する分散データ処理サーバＤＤＳとの対応関係が設定される。

モデル管理部ＭＭＧは、図１４で示したように、「鈴木さん位置」ＯＢＪ−１というオブジェクトを生成し、実世界モデルリストＭＤＬにモデル名と、センサノードの測定データに付されたデータＩＤ及び情報格納先を格納する。オブジェクトの登録が完了すると、モデル管理部ＭＭＧはサービス管理者端末ＡＤＴ−Ｂに完了通知を送信する。

サービス管理者端末ＡＤＴ−Ｂでは、受信したオブジェクトの生成完了通知を表示し、さらにオブジェクトを生成する場合には、上記の処理を繰り返して実行し、所望のオブジェクトを生成する。

＜モデルバインドリストの定義＞
次に、上記モデルリストＭＤＬの定義によって、複数のオブジェクトを生成した後に、複数のオブジェクトＯＢＪ−１〜ｎ間の相関関係を示すモデルバインドリストＭＢＬの設定について、図１９を参照しながら説明する。

図１９において、サービス管理者はサービス管理者端末ＡＤＴ−ＢからディレクトリサーバＤＲＳのモデル管理部ＭＭＧに接続し、モデル管理部ＭＭＧの検索インターフェースを呼び出す。そして、所望のオブジェクトの検索を行い、検索条件に一致したオブジェクトをサービス管理者端末ＡＤＴ−Ｂに返信する。

サービス管理者端末ＡＤＴ−Ｂは、モデル管理部ＭＭＧから受信したオブジェクトの検索結果を図示しない表示装置などに出力する。

サービス管理者は、サービス管理者端末ＡＤＴ−Ｂに表示されたオブジェクトから所望のオブジェクトを選択し、各オブジェクトに共通する要素をモデルバインドリストとして生成するように、ディレクトリサーバＤＲＳのモデル管理部ＭＭＧに要求する。

例えば、図１５で示したように、「鈴木さん」という人名をモデルバインドリストＭＢＬ−Ｐとして生成し、このモデルバインドリストＭＢＬ−Ｐに鈴木さん位置ＯＢＪ−１、鈴木さん着座状態ＯＢＪ−２、鈴木さん温度ＯＢＪ−３などのオブジェクトを対応付ける。

モデル管理部ＭＭＧは、モデルバインドリストＭＢＬ−Ｐと各オブジェクトＯＢＪ−１〜３の情報の格納先を関連づけて、モデルバインドリストＭＢＬに格納する。

モデルバインドリストＭＢＬの登録が完了すると、モデル管理部ＭＭＧはサービス管理者端末ＡＤＴ−Ｂに完了通知を送信する。

サービス管理者端末ＡＤＴ−Ｂでは、受信したモデルバインドリストの生成完了通知を表示し、さらにモデルバインドリストを生成する場合には、上記の処理を繰り返して実行し、所望のモデルバインドリストを生成する。

＜モデルバインドリストの検索＞
次に、上記のように設定したモデルバインドリストＭＢＬにより、センサネットワークのユーザが、モデルバインドリストを用いてセンサノードのデータを参照する処理の一例について、図２０、図２１を参照しながら説明する。

図２０において、ユーザ端末ＵＳＴは、ディレクトリサーバＤＲＳの検索エンジンＳＥＲに接続し、モデルバインド管理部ＭＢＭに対して、モデルバインドリストＭＢＬの検索を要求する。この検索要求は、例えば、キーワード検索や図１５のようなＧＵＩなどで行われる。

モデルバインド管理部ＭＢＭは、要求のあった検索結果をユーザ端末ＵＳＴに応答し、ユーザ端末ＵＳＴの図示しない表示装置などに、検索要求に一致したモデルバインドリストの結果を表示する。

ユーザ端末ＵＳＴにおいて、ユーザが検索結果の中から任意のモデルバインドリストを選択し、情報を要求する（ＳＴＥＰ１１０）。

ここで、モデルバインドリストは、図１５で示したように、オブジェクトＯＢＪ間で共通する要素についてまとめたツリー構造のリンク先で構成され、ユーザ端末ＵＳＴでモデルバインドリストに表示された何れかのリンク先を選択することで、情報の要求がリンク先の分散データ処理サーバＤＤＳに対して行われる。

分散データ処理サーバＤＤＳでは、ユーザ端末ＵＳＴから要求のあった測定データまたは加工データにアクセスを行って、アクセスした結果をディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭに返信する。

ディレクトリサーバＤＲＳでは、属性別意味解釈リスト管理部ＡＴＭが、分散データ処理サーバＤＤＳから送信された測定データのデータＩＤから、図１３に示した属性別意味解釈リストＡＴＬの戻り値に対する意味を取得する（ＳＴＥＰ１１２）。

次に、ディレクトリサーバＤＲＳの検索エンジンＳＥＲは、属性別意味解釈リスト管理部ＡＴＭで解析した測定データに対応する意味をユーザ端末ＵＳＴに返信し、ユーザ端末ＵＳＴでは当該ディレクトリサーバＤＲＳからの応答を分散データ処理サーバＤＤＳからの返信に代わって表示する。

例えば、図１５のモデルバインドリストＭＢＬ−Ｐのリンク先ＬＩＮＫ−１を選択した場合、ユーザ端末ＵＳＴから鈴木さん位置ＯＢＪ−１について予め設定した分散データ処理サーバＤＤＳ−１の測定データにアクセスが行われる。リンク先ＬＩＮＫ−１が例えば、図１２に示したセンサ情報テーブルＳＴＢのデータ格納先に対応付けられていれば、分散データ処理サーバＤＤＳは、このデータ格納先に対応するデータベースＤＢから測定データである無線センサノードＭＳＮ−１の測定データを読み込んでディレクトリサーバＤＲＳに返信する。

ディレクトリサーバＤＲＳでは、データと共に格納されているデータ属性から、属性別意味解釈リストＡＴＬの場所テーブルＡＴＬ−ｐを選択し、戻り値（測定データ）に対応する意味を取得する。この場合、例えば、図２１で示すように、戻り値＝０２であれば、モデルバインドリストＭＢＬ−Ｐのリンク先ＬＩＮＫ−１の情報は、「Ａ会議室」となる。したがって、モデルバインドリストＭＢＬ−Ｐの「鈴木さん位置」というオブジェクトＯＢＪ−１に対する応答はセンサノードＭＳＮ−１の測定データ「０２」という値から、「Ａ会議室」というユーザにとって有意な意味を持つ情報に変換されてユーザ端末ＵＳＴに表示（または通知）される。なお、本例ではデータ属性はデータと供に取得される方式を示したが、実世界モデルリストＭＤＬの登録時に、モデルに対して属性を指定しておく方法でも良い。この場合には、予めセンサノード登録時に、センサノードからのデータを受信する分散データ処理サーバＤＤＳに対して、データ格納先の確保と属性の指定を行っておけばよい。

図２２は、上記図２０の処理を、図１５のモデルバインドリストＭＢＬ−Ｐの「鈴木さん着座状態」ＬＩＮＫ−２について行ったものである。この場合も、各無線センサノードＷＳＮ−３〜１０からの戻り値「００」が分散データ処理サーバＤＤＳから読み込まれ、ディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭにて、戻り値＝「００」が「在席」となり、「鈴木さんは在席しています」という有意な情報を検索エンジンＳＥＲからユーザ端末ＵＳＴに返すことができる。

図２３は、上記図２０の処理を、図１５のモデルバインドリストＭＢＬ−Ｐの「鈴木さん温度」ＬＩＮＫ−３について行ったものである。この場合も、各無線センサノードＭＳＮ−１のセンサＳＳＲ−１からの戻り値「ｘ」が分散データ処理サーバＤＤＳから読み込まれ、ディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭにて、戻り値＝ｘが温度ｙ＝ｆ（ｘ）として演算され、「鈴木さんの周囲温度はｙ℃です」という有意な情報検索エンジンＳＥＲからユーザ端末ＵＳＴに返すことができる。

図２４は、上記図２０の処理を、図１５のモデルバインドリストＭＢＬ−Ｒの「Ａ会議室のメンバ」について行ったものである。この場合は、モデル管理部ＭＭＧでＡ会議室のメンバＯＢＪ−４というオブジェクトを生成した際に、所定の分散データ処理サーバＤＤＳ−１では、Ａ会議室に相当する基地局ＢＳＴ−１で検出された名札ノードのタグＩＤが、測定データとして基地局ＢＳＴ−１に読み込まれる。そしてこの値がデータ格納先として予め設定された、図１４の情報リンク先（ここでは、分散データ処理サーバＤＤＳ−１）に格納される。

分散データ処理サーバＤＤＳ−１は、所定の周期で基地局ＢＳＴ−１から無線センサノードＭＳＮ−１〜ｎのタグＩＤを収集し、上記Ａ会議室のメンバを示す値（名札ノードのタグＩＤの集合）を更新する。図２４においては、分散データ処理サーバＤＤＳ−１が収集した無線センサノードＭＳＮ−１〜ｎより、タグのＩＤが「０１」、「０２」の従業者がＡ会議室で検出されたことを示す。

分散データ処理サーバＤＤＳ−１はこの加工データ「０１、０２」をディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭに送信する。

ディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭでは、予め定義された人名テーブルＡＴＬ−ｍから、受信した加工データを、０１＝鈴木、０２＝田中、という有意な情報に変換してユーザ端末ＵＳＴに送信する。

この結果、ユーザ端末ＵＳＴでは、モデルバインドリストＭＢＬ−ＰのＡ会議室のメンバという情報要求に対して、「Ａ会議室には鈴木、田中がいます」という有意な情報を得ることができる。

図２５は、上記図２０の処理を、図１５のモデルバインドリストＭＢＬ−Ｒの「Ａ会議室の人数」について行ったものである。この場合は、モデル管理部ＭＭＧでＡ会議室の人数ＯＢＪ−５というオブジェクトを生成した際に、所定の分散データ処理サーバＤＤＳ−１では、Ａ会議室の人数、具体的にはある時間周期毎にＡ会議室に相当する基地局ＢＳＴ−１で検出される名札ノードのＩＤ数、もしくは着座ノードがＯＮとなっている数を計算する。そしてこの値がオブジェクトＯＢＪ−５のデータ格納先として、予め設定された図１４の情報リンク先に格納される。

分散データ処理サーバＤＤＳ−１は、所定の周期で基地局ＢＳＴ−１から無線センサノードＭＳＮ−１〜ｎのデータＩＤの数ｘを収集し、上記Ａ会議室の人数を示す値として管理する。分散データ処理サーバＤＤＳ−１はこのデータ値ｘをディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭに送信する。

ディレクトリサーバＤＲＳの属性別意味解釈リスト管理部ＡＴＭでは、予め定義された人数テーブルＡＴＬ−ｎから、受信した加工データを、人数ｙ＝ｘ、という有意な情報に変換して検索エンジンＳＥＲからユーザ端末ＵＳＴに送信する。

この結果、ユーザ端末ＵＳＴでは、モデルバインドリストＭＢＬ−ＰのＡ会議室の人数という情報要求に対して、「Ａ会議室にはｙ人います」という有意な情報を得ることができる。

＜アクション制御部＞
図２６は、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣの詳細を示すブロック図である。

アクション制御部ＡＣＣは、複数の分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣから受信したイベント発生通知に基づいて、予め設定した動作（アクション）を自動的に行うものである。

このため、アクション制御部ＡＣＣは、セッション制御部ＳＥＳを介してユーザ端末ＵＳＴからアクション設定を受け付けるアクション受け付け部ＡＲＣと、受け付けたアクションを分析し、分析結果に応じてディレクトリサーバＤＲＳと分散データ処理サーバＤＤＳ間の機能（または負荷）分担を設定するアクション分析部ＡＡＮと、アクションの定義及び実行を管理するアクション管理部ＡＭＧと、ユーザ端末ＵＳＴからの設定要求に応じたイベントとアクションの関係を格納するアクションテーブルＡＴＢと、アクションテーブルＡＴＢで定義されたイベントを監視するように分散データ処理サーバＤＤＳ−１〜ｎに指令を送出するイベント監視指示部ＥＭＮと、各分散データ処理サーバＤＤＳ−１〜ｎで発生したイベント通知を受信するイベント受信部ＥＲＣと、受信したイベント通知とアクションテーブルＡＴＢの定義に基づいて、予め設定された処理を実行するアクション実行部ＡＣＥＣとから構成される。

アクション制御部ＡＣＣを構成するアクション実行部ＡＣＥＣは、図２７のように構成される。図２７において、アクション実施部ＡＣＥＣは、図２６のアクション管理部ＡＭＧからイベント発生通知と、イベント発生通知があったデータＩＤに対応するアクションの内容及びアクション実行時のパラメータをアクションテーブルＡＴＢから読み込んで後述の各処理部へ指令を送出するアクションディスパッチャＡＤＰを有する。

アクションディスパッチャＡＤＰの指令を受けて所定のアクションを実行する上記各処理部としては、ユーザ端末などへ通信処理を行う通知／転送処理部ＮＴＣと、アクションとしてデータを最新データメモリＬＤＰ−Ｄに格納する格納処理部ＬＤＰと、アクションとしてデータに加工を行うデータ加工処理部ＤＰＲを備えている。

通知／転送処理部ＮＴＣは、ユーザ端末ＵＳＴなどへポップアップ通知やメール送信を行うため、アクションの内容に応じたプロトコル制御部を有し、例えば、ＳＩＰ（Session Initiation Protocol）でポップアップ通知やデータ転送を行い、ＳＭＴＰ（Simple Mail Transfer Protocol）でメールの送信を行い、ＨＴＭＬ（Hyper Text Markup Language）等で記述されたデータをＨＴＴＰ（Hyper Text Transfer Protocol）で送信する。

格納処理部ＬＤＰは、ディレクトリサーバＤＲＳに設けたデータメモリＬＤＰ−Ｄにアクションで指示されたデータを格納する。なお、ディレクトリサーバＤＲＳに設けたデータメモリＬＤＰ−Ｄは、ユーザ端末ＵＳＴからのアクセスに応じて最新のデータを提供可能にするもので、実世界モデルテーブルＭＴＢでオブジェクトとの対応関係が予め設定されたものである。

データ加工処理部ＤＰＲでは、分散データ処理サーバＤＤＳ等からのデータに対して、指定された演算を行って加工データを生成する。そして、この加工データにデータＩＤを付与する。この加工データは最新データメモリＬＤＰ−Ｄや他の分散データ処理サーバＤＤＳに送信することもできる。

そして、通知／転送処理部ＮＴＣ、格納処理部ＬＤＰ、データ加工処理部ＤＰＲはそれぞれネットワークインターフェースＮＩＦを介して第１のネットワークＮＷＫ−１と通信し、データの送受やメッセージの送信を行うことができる。

アクションディスパッチャＡＤＰは、アクション管理部ＡＭＧからイベント発生通知を受けると、このイベントを発生したデータのデータＩＤに対応するアクション及びパラメータをアクションテーブルＡＴＢから読み込む。

そして、アクションディスパッチャＡＤＰは、アクションの内容からいずれの処理部に指令を行うか判定し、データ加工処理部ＤＰＲ、通知／転送処理部ＮＴＣ及び格納処理部ＬＤＰへそれぞれ指令（必要あればパラメータ等を含めて）を送る。

アクションの登録について、図２８のタイミングチャートを参照しながら説明する。図２８では、まず、ユーザ（またはサービス管理者）がユーザ端末ＵＳＴ等からディレクトリサーバＤＲＳのアクション制御部ＡＣＣに接続し、アクションの設定を要求する。例えば、アクションの一例としては、図２９で示すように、Ｘさんの着席を監視して、ＩＰアドレス：Ａのユーザ端末ＵＳＴにポップアップ通知を送信する、というアクションを設定する場合について検討する。

アクション制御部ＡＣＣのアクション受付部ＡＲＣは、上記アクションの設定要求を受け付けると、アクション分析部ＡＡＮに当該アクションの設定を要求する。アクション分析部ＡＡＮは、例えば、ユーザ端末ＵＳＴから要求のあったＸさんの着席、という要求に対して、実世界モデルリストＭＤＬからＸさん着座状態というモデル名を通じて監視対象のセンサノードのデータＩＤを選択し、さらにセンサノードの測定データのイベント発生条件を決定する。ここでは、「Ｘさんの着席」という実世界の事象をセンサノードのデータＩＤへ変換するため、実世界モデルテーブルＭＴＢの実世界モデルリストＭＤＬと属性別意味解釈リストＡＴＬを参照して「Ｘさんの着席」というモデルと着席（在席）という意味に対応する戻り値を探索する。すなわち、ユーザが理解可能なモデル名と意味を、センサノードのＩＤ及び所在と戻り値に変換する。

ここで、図３０で示すように、Ｘさん＝鈴木さんの場合では、既に実世界モデルテーブルＭＴＢにモデルが定義されているので、上記リストＭＤＬ、ＡＴＬからデータＩＤ＝Ｘ２とデータを格納する情報格納先（分散データ処理サーバＤＤＳ１）を取得する。

次に、アクション管理部ＡＭＧでは、「Ｘさんの着席」というイベント発生を分散データ処理サーバＤＤＳで監視するため、上記選択したモデル名に対応するデータ格納先となる分散データ処理サーバＤＤＳに対して「Ｘさんの着席」というイベント発生を監視するように指令を送出する。ディレクトリサーバＤＲＳのアクション管理部ＡＭＧから指令を受けた分散データ処理サーバＤＤＳでは、図３１で示すように、実世界モデルリストＭＤＬから取得したデータＩＤ＝Ｘ２について、属性意味解釈リストＡＴＬから取得した着席という条件「００」と、アクションとして行うべきイベントの通知先にディレクトリサーバＤＲＳのアクション制御部ＡＣＣを登録する。なお、分散データ処理サーバＤＤＳ−１で行うディレクトリサーバＤＲＳへの通知は、分散データ処理サーバＤＤＳ−１おけるアクションとする。そして、アクション管理部ＡＭＧは、図３２で示すアクションテーブルＡＴＢに「ＩＰアドレス：Ａのユーザ端末ＵＳＴにポップアップ通知を送信する」というアクションを設定し、当該アクションを実行するイベントのＩＤとして、上記データＩＤを設定する。

つまり、図３１に示す分散データ処理サーバＤＤＳのイベントテーブルＥＴＢには、測定データのＩＤを示すデータＩＤ欄に、「鈴木さんの着席」を示す感圧センサのデータＩＤ＝Ｘ２が設定され、イベントの条件欄には、着席を示すＸ２データの値「００」が設定され、分散データ処理サーバＤＤＳ−１のアクション欄には、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣへ通知する、というアクションが設定される。

また、図３２に示すディレクトリサーバＤＲＳのアクションテーブルＡＴＢには、監視対象のイベントＩＤを示すデータＩＤ欄には、「鈴木さんの着席」を示すデータＩＤ＝Ｘ２が設定され、イベントの条件欄には、分散データ処理サーバＤＤＳ−１からのイベント発生の受信が設定され、ディレクトリサーバＤＲＳが実行するアクション欄には、ユーザ端末ＵＳＴへのポップアップ通知が設定され、アクションのパラメータ欄には、ユーザ端末ＵＳＴのうちＡさんを示すＩＰアドレスが設定される。

アクション管理部ＡＭＧがアクションテーブルＡＴＢに登録するアクションは、図３２のように、データＩＤ＝Ｘ２のイベントを受信したことをイベント発生の条件とし、ポップアップ通知というアクションを、パラメータ欄に記載したアドレス（ここではＩＰアドレスＡの端末）に対して実行するよう設定する。

なお、図２９、図３０のアクション設定要求画面は、ディレクトリサーバＤＲＳのアクション受付部ＡＲＣがユーザ端末ＵＳＴへ提供するもので、氏名のプルダウンメニューに実世界モデルリストＭＤＬが対応付けられており、「着座」、「会議中」、「帰宅」のプルダウンメニューは、属性意味解釈リストＡＴＬに対応付けられており、「ポップアップ」、「メール」のプルダウンメニューは、ディレクトリサーバＤＲＳで実行するアクションが設定されている。

上述のように、一つのイベント発生から一つのアクションを行うものを単一アクションとし、上記のような単一アクションの設定は図３３で示す流れとなる。

すなわち、ユーザ端末ＵＳＴからディレクトリサーバＤＲＳのアクション制御部ＡＣＣに対して、ユーザが理解可能な意味情報によりイベントとアクションの設定要求が行われると、意味情報に対応するアクションの分析とイベントの監視指示がアクション制御部ＡＣＣで生成され、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣにてイベントテーブルＥＴＢが定義される。その後、アクション制御部ＡＣＣのアクション管理部ＡＭＧは、イベント受信部ＥＲＣに対して、上記設定したイベント（データＩＤ＝Ｘ２）の監視を指示し、アクションテーブルＡＴＢにユーザが要求したアクション（ポップアップ通知）を設定する。アクション制御部ＡＣＣは一連のアクションの設定完了をユーザ端末ＵＳＴに通知する。

＜アクションの実行＞
図３４は、上記図２９、図３０で設定した単一のアクションの実行を示すタイムチャートである。

監視対象のセンサノードの測定データがイベント発生条件の「００」に変化して、Ｘさんの着席が判定されると、分散データ処理サーバＤＤＳ−１は、データＩＤ＝Ｘ２に関するイベント通知を発生する。

このイベント発生は、分散データ処理サーバＤＤＳからディレクトリサーバＤＲＳに通知され、図２６のイベント受信部ＥＲＣが受信する。

ディレクトリサーバＤＲＳのアクション管理部ＡＭＧは、受信したイベントのＩＤから図３２のアクションテーブルＡＴＢを検索し、該当するアクションの有無を判定する。受信したＩＤ＝Ｘ２のイベントは、アクションテーブルＡＴＢに定義があるので、アクション管理部ＡＭＧは、アクション実行部ＡＣＥＣに対してアクションテーブルＡＴＢのアクションとパラメータを通知する。

アクション実行部ＡＣＥＣは、アクション管理部ＡＭＧから指示された通知に基づいて、定義に対応する処理を実行する。この場合では、ＩＰアドレス：Ａのユーザ端末ＵＳＴに対してポップアップ通知を送信する。ＩＰアドレス：Ａのユーザ端末ＵＳＴには、ポップアップ通知が送信され、Ｘさんの着席が検知されたことを確認できる。

＜複数アクションの設定及び実行＞
上記図２９、図３０及び図３４では、一つのイベント発生でひとつのアクションを行う例について述べたが、図３５〜図４１で示すように、２つのイベントが成立したらあるアクションを実行するように設定することができる。

図３５、図３６は、複数アクションの設定要求画面である。この設定要求画面には、２つの氏名欄についてそれぞれ「着席」等の状態を選択可能なプルダウンメニューが定義される。これら２つの氏名に対応するイベントの条件は、上記図２９、図３０と同様に、実世界モデルテーブルＭＴＢの実世界モデルリストＭＤＬと属性別意味解釈リストＡＴＬに対応付けられている。

さらに、これら２名のイベント条件の論理式（かつ、または）を設定するプルダウンメニューが加えられる。

そして、前記単一アクションと同様に、ディレクトリサーバＤＲＳが実施するアクション（ポップアップ通知、メール送信）と、アクションの実行に必要とするパラメータ欄（アドレスなど）が設定される。

ここでは、「鈴木さんの着席」という分散データ処理サーバＤＤＳ−１のイベント発生と、「田中さんの着席」という分散データ処理サーバＤＤＳ−２からのイベント発生がともに成立した時点で、メールを送信するというアクションの例について説明する。

まず、「鈴木さんの着席」というイベントについては、上記図２９、図３０と同様に設定し、鈴木さんの着席を監視する分散データ処理サーバＤＤＳ−１のイベントテーブルＥＴＢには、図３７に示すイベントとアクションが設定される。このときの、アクションテーブルの設定のタイムチャートを図４０に示す。

次に、「田中さんの着席」というイベントについては、上記図２９、図３０と同様に、田中さんの着席を検知するセンサノードのデータＩＤ＝Ｙ２をデータＩＤ欄に設定し、意味解釈リストＡＴＬから着席を示す「００」をイベントの条件とし、このイベント条件成立時にはディレクトリサーバＤＲＳのアクション制御部ＡＣＣへ通知するというアクションが、図３８で示すように分散データ処理サーバＤＤＳ−２のイベントテーブルＥＴＢに設定される。

ディレクトリサーバＤＲＳのアクション制御部ＡＣＣでは、図３９で示すように、アクションテーブルＡＴＢに２つの条件が「ＡＮＤ」の論理式で結合され、設定される。

そして、「ＡＮＤ」により結合されたアクションテーブルＡＴＢの２つの条件について、アクション欄には「メール送信」が設定され、パラメータ欄には送信先のアドレス（Ｂさんのメールアドレス）が設定される。

図４０のタイムチャートでは、上記図３３と同様にして、ユーザ端末ＵＳＴからアクション制御部ＡＣＣに対して、鈴木さんの着席と田中さんの着席に関するアクションの設定要求が行われる。イベント監視指示部ＥＭＮから分散データ処理サーバＤＤＳ−１に対しては、データＩＤ＝Ｘ２のセンサノードの測定データが所定条件（鈴木さんの着席）となったらイベントを通知するよう設定し、イベント監視指示部ＥＭＮから分散データ処理サーバＤＤＳ−２に対しては、データＩＤ＝Ｙ２のセンサノードの測定データが所定条件（田中さんの着席）となったらイベントを通知するよう設定する。

分散データ処理サーバＤＤＳ−１、２ではそれぞれイベントテーブルＥＴＢに新たなイベントが追加され、各分散データ処理サーバＤＤＳ−１、２のイベント発生判定部ＥＶＭでは、測定データに対するイベント監視が開始される。

また、アクション制御部ＡＣＣのアクション管理部ＡＭＧでは、イベント受信部ＥＲＣに、データＩＤ＝Ｘ２とＹ２のイベントの監視が指示されて設定を終了する。

次に、図４１はアクションの実行の様子を示すタイムチャートである。

まず、分散データ処理サーバＤＤＳ−１が、鈴木さんの着席に伴って、データＩＤ＝Ｘ２のイベントを発生する。アクション制御部ＡＣＣではデータＩＤ＝Ｘ２のイベントを受信するが、アクションテーブルＡＴＢでは、田中さんの着席がないとアクションを実行できないので、当該アクションは保留される。

次に、分散データ処理サーバＤＤＳ−２が、Ｙさんの着席に伴って、データＩＤ＝Ｙ２のイベントを発生する。アクション制御部ＡＣＣではデータＩＤ＝Ｙ２のイベントを受信し、アクションテーブルＡＴＢで、データＩＤ＝Ｘ２とＹ２のＡＮＤ条件が成立したので、アクションを実行し、所定のメールアドレスにメールを送信する。

このように、複数のイベントを条件としてアクションを実行することができ、多数のセンサから、ユーザに必要な応答のみを得ることが可能となる。これにより、膨大な数のセンサノードがあった場合でも、ユーザはほぼリアルタイムで所望の情報（または情報の変化）を検知でき、センサノードの情報を有効に利用することが可能となる。

＜第２実施形態＞
図４２〜図４６は、第２の実施形態を示し、単一アクションの実行を分散データ処理サーバＤＤＳ側で行うようにしたもので、上記図９に示した分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣにアクション実施部ＡＣＥを設け、図９のイベントテーブルＥＴＢをイベントアクションテーブルＥＡＴＢに置き換えたものであり、その他の構成は前記第１実施形態と同様である。なお、イベントアクションテーブルＥＡＴＢは、前記第１実施形態のイベントテーブルＥＴＢとアクションテーブルＡＴＢを結合したものである。

図４２において、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣには、ネットワーク処理部ＮＷＰを介して、基地局ＢＳＴから収集される測定データをイベントアクションに対応付けるイベントアクションテーブルＥＡＴＢを備える。

イベントアクションテーブルＥＡＴＢは、図４４で示すように、センサノード毎に割り当てられて測定データに付与されるデータＩＤと、イベントを発生させる測定データの条件を示すイベント内容欄と、イベント発生時に分散データ処理サーバＤＤＳが実施するアクションの内容を示すアクション欄と、アクションを実施する際に必要な値を格納するパラメータ欄と、イベント発生時に測定データをデータベースＤＢに格納するか否かを決定するデータ格納ＤＨＬとから１レコードが構成されている。

例えば、図中、データＩＤがＸ１の測定データは、その値が「０２」のときにイベントを発生し、パラメータ欄で指定されたアドレスにメールを送信する。ディスク装置ＤＳＫへの測定データの書き込みは行わないように設定されている。

図４２に示すイベントアクション制御部ＥＡＣの機能について説明する。基地局ＢＳＴから受信した測定データは、まず、センシングデータＩＤ抽出部ＩＤＥにて、データＩＤが抽出される。また、同時に、センシングデータＩＤ抽出部ＩＤＥは、測定データを最新データメモリＬＤＭに送る。

抽出されたデータＩＤはイベント検索部ＥＶＳに送られて、イベント検索部ＥＶＳがイベントアクションテーブルＥＡＴＢを検索し、データＩＤが一致するレコードがあれば、当該レコードのイベント内容及びパラメータをイベント発生判定部ＥＶＭに送る。

イベント発生判定部ＥＶＭでは、測定データの値とイベント内容ＥＶＴを比較して、条件を満たせばアクション実施部ＡＣＥに送り、設定されたアクションを実施する。

そして、アクション実施部ＡＣＥは、イベントアクションテーブルＥＡＴＢに設定されたアクションの内容を読み込んで、ＤＢ制御部ＤＢＣ（あるいはディスクＤＳＫ）へデータを書き込んだり、ユーザ端末ＵＳＴへ通知を行ったり、測定データに演算処理を施して加工を行うなど、所定の処理を実行する。

ＤＢ制御部ＤＢＣは、イベントが発生した測定データの内、イベントアクションテーブルＥＡＴＢのデータ格納ＤＨＬがＹＥＳとなっているデータについてディスク装置ＤＳＫに書き込みを行う。

データアクセス受け付け部ＤＡＲの処理内容は前記第１実施形態と同様である。つまり、アクセス要求が最新のデータであれば、アクセス要求に含まれるデータＩＤに対応する測定データを最新データメモリＬＤＭから読み込んで、ネットワーク処理部ＮＷＰへ返送する。

図４５は分散データ処理サーバＤＤＳにアクションの設定を行う際のタイムチャートを示し、図４３はアクションの設定を行う際に、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣがユーザ端末ＵＳＴへ送信するインターフェースの一例を示す。なお、単一アクションの設定時では、ディレクトリサーバＤＲＳが分散データ処理サーバＤＤＳと通信し、ユーザ端末ＵＳＴからのアクションの設定要求を、指定されたセンサノードのデータＩＤに対応する分散データ処理サーバＤＤＳに対して設定する。

まず、ユーザ（またはサービス管理者）がユーザ端末ＵＳＴ等からディレクトリサーバＤＲＳのアクション制御部ＡＣＣに接続し、アクションの設定を要求する。例えば、アクションの一例としては、図２９で示したように、Ｘさんの位置を監視してＡ会議室に入ったら、ＩＰアドレス：Ａのユーザ端末ＵＳＴにポップアップ通知を送信する、というアクションを設定する場合について検討する。

アクション制御部ＡＣＣのアクション受付部ＡＲＣは、このアクションの設定要求を受け付けると、アクション分析部ＡＡＮに当該アクションの設定を要求する。アクション分析部ＡＡＮは、例えば、Ｘさんの情報から、監視対象のセンサノードのデータＩＤを選択し、またセンサノードの測定データがどのようになったらイベントを発生させるか決定する。ここでは、「Ｘさんの位置」という実世界の事象をセンサノードのデータＩＤへ変換するため、実世界モデルテーブルＭＴＢの実世界モデルリストＭＤＬと属性別意味解釈リストＡＴＬ（意味情報管理テーブル）を参照して「Ｘさんの位置」というモデルを探索する。

ここで、図３１で示したように、Ｘさん＝鈴木さんの場合では、既に実世界モデルテーブルＭＴＢにモデルが定義されているので、上記リストＭＤＬ、ＡＴＬからデータＩＤ＝Ｘ２とデータを格納する情報格納先（分散データ処理サーバＤＤＳ１）を取得する。

次に、アクション管理部ＡＭＧでは、ユーザ端末ＵＳＴからの要求が単一アクションであるか否かを判定し、単一アクションの場合には、要求されたアクションを上記情報格納先の分散データ処理サーバＤＤＳに実施させるように設定する。

「Ｘさんの位置」というイベントとアクションを分散データ処理サーバＤＤＳで発生させるため、上記選択したセンサノードを管理する分散データ処理サーバＤＤＳに対して「Ｘさんの位置」が「Ａ会議室」というイベントを発生するように指令を送出する。さらに、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣは、分散データ処理サーバＤＤＳに対してイベントアクションテーブルＥＡＴＢに「メールアドレス：mailto＿b＠xyz.comのユーザにメールを送信する」というアクションを設定し、当該アクションを実行するイベントのＩＤとして、上記センサノードのデータＩＤを設定する。

ディレクトリサーバＤＲＳのアクション管理部ＡＭＧから指令を受けた分散データ処理サーバＤＤＳでは、図４４で示すように、実世界モデルリストＭＤＬから取得したデータＩＤ＝Ｘ１について、属性意味解釈リストＡＴＬから取得したＡ会議室という条件「０２」と、アクションとして行うべきイベントの通知先に上記メールアドレスを登録する。

アクション管理部ＡＭＧが分散データ処理サーバＤＤＳに登録するアクションは、図４４で示すように、データＩＤ＝Ｘ１のイベント発生時に、メール送信というアクションを、パラメータに記載したアドレスに対して実行するよう設定する。

このように、ユーザ端末ＵＳＴから単一アクションの設定要求があると、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣは、自らのアクションテーブルＡＴＢに設定を行う代わりに、対応する分散データ処理サーバＤＤＳに対して設定を行い、分散データ処理サーバＤＤＳのイベントアクションテーブルＥＡＴＢにイベントとアクションの双方が設定される。

分散データ処理サーバＤＤＳにおけるイベントアクションの実行は、図４６のように行われ、Ｘさんが会議室に入ると、データＩＤ＝Ｘ１の値が「０２」となり図４４のイベントアクションテーブルＥＡＴＢに定義されたイベントとアクションが実施される。アクションの実施により、所定のメールアドレスにはＸさんがＡ会議室に入ったことを通知される。

この場合、ディレクトリサーバＤＲＳは、アクションの設定のみを分散データ処理サーバＤＤＳに対して行うだけで、実際のイベント発生を監視する必要がない。このため、データの収集と単一アクションの実行を分散データ処理サーバＤＤＳに任せ、ディレクトリサーバＤＲＳはユーザ端末ＵＳＴからの検索要求と複数アクションの監視を行えばよいので、センサノードの数が極めて大きいときなどでは、ディレクトリサーバＤＲＳの負荷が過大になるのを防いで、センサネットワークの円滑な運用が可能となる。

なお、上記第２実施形態では、分散データ処理サーバＤＤＳのイベントアクションテーブルＥＡＴＢに、イベントとアクションを設定する例を示したが、イベントを格納するイベントテーブルと、アクションを格納するアクションテーブルを、独立させても良い。

＜第３実施形態＞
図４７〜図５３は、第３の実施形態を示し、前記第２実施形態の分散データ処理サーバＤＤＳのアクション実施部ＡＣＥから出力される加工データを、センシングデータＩＤ抽出部ＩＤＥへ入力させ、ひとつの分散データ処理サーバＤＤＳ内で加工データに基づいて次のイベントとアクションを連続的に実施するようにしたものであり、その他の構成は前記第２実施形態と同様である。

イベントアクション制御部ＥＡＣを構成するアクション実施部ＡＣＥは、図４８のように構成される。図４８において、アクション実施部ＡＣＥは、図４７のイベント発生判定部ＥＶＭからのイベント発生通知と、センシングデータＩＤ抽出部ＩＤＥからのデータ（測定データ＝生データ、加工データ）と、イベントアクションテーブルＥＡＴＢからのアクション及びパラメータを受け付けて、後述の各処理部へ指令を送出するアクションディスパッチャＡＤＰと、アクションとしてユーザ端末などへ通信処理を行う通知／転送処理部ＮＴＣと、アクションとしてデータを最新データメモリＬＤＭ及びディスクＤＳＫに格納するディスク格納処理部ＬＤＭ−Ｄと、アクションとしてデータに加工を行うデータ加工処理部ＤＰＲを備えている。

通知／転送処理部ＮＴＣは、ユーザ端末ＵＳＴなどへポップアップ通知やメール送信を行うため、アクションの内容に応じたプロトコル制御部を有し、例えば、ＳＩＰでポップアップ通知やデータ転送を行い、ＳＭＴＰでメールの送信を行い、ＨＴＭＬで記述されたデータをＨＴＴＰで送信する。

ディスク格納処理部ＬＤＭ−Ｄは、最新データメモリＬＤＭにアクセするためのメモリインターフェースを有し、データを最新データメモリＬＤＭに書き込む。また、イベントアクションテーブルＥＡＴＢの設定に基づいて、最新データメモリＬＤＭに書き込まれたデータを、ＤＢ制御部ＤＢＣを介してディスクＤＳＫに格納する。

データ加工処理部ＤＰＲでは、センシングデータＩＤ抽出部ＩＤＥからのデータに、パラメータなどで指示された演算を行って加工データを生成する。そして、この加工データにデータＩＤを付与する。

そして、データ加工処理部ＤＰＲの出力は、図４７に示すループバックパスＲＰによりセンシングデータＩＤ抽出部ＩＤＥに接続される。データ加工処理部ＤＰＲで加工された加工データはセンサノードからの測定データ（生データ）と同様にイベントアクション処理が施される。

アクションディスパッチャＡＤＰは、イベント発生判定部ＥＶＭからイベント発生通知を受けると、このイベントを発生したデータをセンシングデータＩＤ抽出部ＩＤＥから受け付け、このデータＩＤに対応するアクション及びパラメータとディスク格納の有無を読み込む。

アクションディスパッチャＡＤＰの指令及びデータは、データ加工処理部ＤＰＲ、通知／転送処理部ＮＴＣ及びディスク格納処理部ＬＤＭ−Ｄへそれぞれ入力され、イベントアクションテーブルＥＡＴＢに設定されたアクションの内容に応じて上記各処理部へデータまたはパラメータを送る。

図４７のように、分散データ処理サーバＤＤＳのアクション実施部ＡＣＥでは、新たなアクションがデータ加工である場合、上記データ加工処理部ＤＰＲで所定のデータ加工を行い、加工結果にデータＩＤを付与して、センシングデータＩＤ抽出部ＩＤＥへ入力することができ、また、アクション実施部ＡＣＥの各処理部は独立しているため、同時に複数のアクションを実施することができる。

これにより、図４９で示すように、一つのアクション（イベント発生）から複数のアクションを連鎖的に実行して測定データの加工、または加工データのさらなる加工を行うことができる。

例えば、図４９において、センサノードを温度センサとし、データＩＤ＝Ｘ１の測定データを摂氏から華氏に変換し、新たなデータＩＤ＝Ｘ２を付加するデータ加工アクション２１０と、華氏に変換された加工データに基づいて通知処理を行う通知アクション２２０を、一つの分散データ処理サーバＤＤＳで連続的に行うことができる。

上記図４９で示した処理を行う際にはイベントアクションテーブルＥＡＴＢを、例えば、図５０のように設定する。

ここで、本第３実施形態のイベントアクションテーブルＥＡＴＢは、アクション実施部ＡＣＥの処理部（データ加工処理部ＤＰＲ、通知／転送処理部ＮＴＣ及びディスク格納処理部ＬＤＭ−Ｄ）の数に対応した複数のアクション欄が設けられ、一つのデータＩＤについて複数のアクションを定義することができる。図５０では、アクション欄として、データ加工処理、データ転送処理、通知処理の３つのアクション欄を設けた例を示し、各アクション欄には、アクションの実行時に必要なパラメータを格納するパラメータ欄がそれぞれオプションとして設けられている。

上記図４９の処理を行う一例として、図５０のデータＩＤ＝Ｘ１のエントリでは、イベント発生条件にデータの到着（受信）を設定し、センサノードから測定データを受信したら測定データの単位を温度を摂氏から華氏に単位を変換する演算を行うデータの加工処理がアクション欄のデータ加工処理に設定される。そして、単位変換のデータ加工処理のオプションとして、新たに生成する加工データのデータＩＤを「Ｘ２」とすることがパラメータ欄に設定される。

このデータ加工処理に次いで行われるアクションとして、転送処理欄には生成した加工データをデータＩＤ抽出部ＩＤＥへ入力させる「ループバック」が設定される。ループバックの場合は、転送先が分散データ処理サーバＤＤＳ自身となるので、転送処理欄のパラメータ欄は空白とする（転送先の指定は不要）。なお、データＩＤ＝Ｘ１のイベントアクションでは、通知処理は行わないので、通知処理欄は空欄となる。

このエントリにより、分散データ処理サーバＤＤＳでは、データＩＤ＝Ｘ１の測定データを受信すると、摂氏から華氏への単位変換を行ってデータＩＤ＝Ｘ２の加工データを生成し、データＩＤ抽出部ＩＤＥへ入力するイベント発生及びアクションが実施される。

次に、生成された加工データのエントリをデータＩＤ＝Ｘ２としてイベントアクションテーブルＥＡＴＢに設定する。まず、イベント発生条件には、例えば、アクション実施部ＡＣＥから入力されたデータの値（華氏）が６０を超えた場合にイベントを発生するように設定する。そして、このイベント発生に基づいて実行するアクションとしては通知処理欄のメール通知を設定する。通知処理欄のパラメータ欄には、メールの通知先のアドレスを設定する。なお、メールの内容は予め設定したものであり、例えば、「規定の温度を超えました」などのように設定される。

このエントリにより、分散データ処理サーバＤＤＳでは、データＩＤ＝Ｘ２の加工データがＩＤ抽出部ＩＤＥへ入力されると、データの値が華氏６０度を超えていれば、所定の通知先にメールを送信するアクションが実施される。

上記２つのエントリにより、図４９で示したように、分散データ処理サーバＤＤＳは、摂氏の測定データを受信すると、華氏に変換した加工データを生成し、さらにこの加工データの値に基づいて通知のアクションを実施することができる。すなわち、分散データ処理サーバＤＤＳが受信した測定データを１次データとし、この１次データに基づいて生成された加工データを２次データとすれば、分散データ処理サーバＤＤＳでは、イベントアクションテーブルＥＡＴＢでは、１次データから２次、３次の加工データを生成し、さらに各データに対して転送処理や通知処理を並行して行うことができるのである。

上記では、１つの測定データから連鎖的にイベント及びアクションを実施する例を示したが、図５１、図５２で示すように、一つの分散データ処理サーバＤＤＳで、複数の測定データ（１次データ）から加工データ（２次データ）を生成することもできる。

例えば、図５１において、温度センサと湿度センサの出力から不快指数を求めることもできる。データＩＤ＝Ｙ１は意味情報Ａが温度である測定データで、データＩＤ＝Ｙ２は意味情報Ｄが湿度の測定データで、これらの測定データを受信した分散データ処理サーバＤＤＳは、温度と湿度の測定データから意味情報Ｅが不快指数を示す加工データＹ３を生成し（データ加工アクション３１０）、さらにこの加工データＹ３を転送する処理（データ転送アクション３２０）を行うことができる。

上記図５１の処理を行う一例として、図５２のようにイベントアクションテーブルＥＡＴＢを設定する。データＩＤ＝Ｙ１のエントリでは、イベント発生条件にデータの到着（受信）を設定し、センサノードから温度を意味する測定データを受信したら測定データを保持するようにアクション欄のデータ加工処理欄に設定する。なお、このデータ保持は、測定データＹ１が到着するたびに、最新データメモリＬＤＭの値を更新することを意味する。

次に、湿度を意味するデータＩＤ＝Ｙ２のエントリは、イベント発生条件にデータの到着（受信）を設定し、センサノードから湿度を意味する測定データを受信したら、温度を示す測定データＹ１と湿度を示す測定データＤＹ２を加算して、不快指数を示す加工データをデータＩＤ＝Ｙ３として生成するようデータ加工処理欄に設定する。さらに、転送処理欄にはループバックを設定する。

そして、不快指数を意味するデータＩＤ＝Ｙ３のエントリは、イベント発生条件にデータの到着（入力）を設定し、不快指数を意味する加工データを受信したら、宛先ＩＰアドレス「Ｂ」へ加工データＹ３を転送するよう、転送処理欄に設定する。

上記のようなイベントアクションテーブルＥＡＴＢの設定により、複数の測定データ（１次データ）から加工データ（２次データ）を求め、この加工データに基づいてさらにイベント及びアクションを実行することが可能となる。

このように、イベントアクションテーブルＥＡＴＢにおいて、加工したデータに仮想的なセンサノードのＩＤ（データＩＤ）を付加し、この仮想的なセンサノードのＩＤに対してイベントアクションを定義しておく。そして、アクション実施部ＡＥＣの出力をセンシングデータＩＤ抽出部ＩＤＥへ入力させる（ループバック）ことで、一つの測定データから複数のアクションを連鎖的に実施して、２次、３次の加工データを求め、あるいは他の処理を実行することができる。

これにより、一つの分散データ処理サーバＤＤＳにおいて、測定データの受信に基づいて複数のアクションを実行可能となるので、イベント発生の度にディレクトリサーバＤＲＳへ問い合わせを行う必要がなく、また、他の分散データ処理サーバＤＤＳとは独立して処理を行うことができるので、ディレクトリサーバＤＲＳの負荷とネットワークＮＷＫ−１の負荷をさらに低減することができる。つまり、分散データ処理サーバＤＤＳを多数備えるセンサネットワークであっても、ディレクトリサーバＤＲＳが分散データ処理サーバＤＤＳとの通信に費やす負荷を低減でき、同時にネットワークＮＷＫ−１の負荷（トラフィック）を低減することが可能となり、大規模なセンサネットワークを円滑に運営することができる。

なお、上記図５１の処理は、複数の分散データ処理サーバＤＤＳで連携して行うことができ、例えば、図５３で示すように３つの分散データ処理サーバＤＤＳ−１〜３で、それぞれ単一のイベントアクションを行うようにしても良い。

図５３において、分散データ処理サーバＤＤＳ−１では、温度を測定するセンサノードからの測定データ（ＩＤ＝Ｙ１）を監視し、測定データＹ１を受信したら分散データ処理サーバＤＤＳ−３に転送するという転送アクション４１０を実施する。分散データ処理サーバＤＤＳ−２では、湿度を測定するセンサノードからの測定データ（ＩＤ＝Ｙ２）を監視し、測定データＹ２を受信したら分散データ処理サーバＤＤＳ−３に転送するという転送アクション４２０を実施する。

そして、分散データ処理サーバＤＤＳ−３では、上記図５２のデータＩＤ＝Ｙ１〜３のエントリと同様に、測定データＹ１を受信したら保持し、測定データＹ２を受信したら測定データＹ１とＹ２の和を不快指数として求め、データＩＤ＝Ｙ３の加工データについて他のイベント及びアクション４４０を実行することができる。

このように、複数のデータを他の分散データ処理サーバＤＤＳから取得し、加工データを生成することで、データ加工処理、転送処理、通知処理を実施する分散データ処理サーバＤＤＳを柔軟に設定あるいは変更することができ、センサネットワークのリソースを有効に利用することが可能となる。

＜第４実施形態＞
図５４は、第４実施形態を示し、前記第３実施形態において、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣを構成するアクション実施部ＡＣＥの構成を変更したもので、その他の構成は前記第３実施形態と同様である。

測定データまたは加工データの加工を行うデータ加工処理部ＤＰＲの出力は、前記第３実施形態と同様にデータＩＤ抽出部ＩＤＥへ入力されるとともに、通知／転送処理部ＮＴＣとディスク格納処理部ＬＤＭ−Ｄにも入力される。そして、アクションディスパッチャＡＤＰの指令及びデータは、データ加工処理部ＤＰＲ、通知／転送処理部ＮＴＣ及びディスク格納処理部ＬＤＭ−Ｄへそれぞれ入力される。

データ加工処理部ＤＰＲの後段に通知／転送処理部ＮＴＣとディスク格納処理部ＬＤＭ−Ｄを設けたので、一回のイベント発生で複数のアクションを実行することができる。例えば、イベントアクションテーブルＥＡＴＢには上記図５０と同様に、データの加工処理とデータの転送処理及び通知処理という３つのアクションと、各アクションに対応するパラメータを定義しておく。そして、所定の測定データを受信してイベントが発生すると、アクションディスパッチャＡＤＰは、データ加工のアクションをデータ加工処理部ＤＰＲへ指令し、加工データ転送のアクションを通知／転送処理部ＮＴＣへ指令し、また、加工データの格納をディスク格納処理部ＬＤＭ−Ｄに指令する。

データ加工処理部ＤＰＲがデータの加工を実行し、出力された加工データは通知／転送処理部ＮＴＣとディスク格納処理部ＬＤＭ−Ｄ及びデータＩＤ抽出部ＩＤＥへそれぞれ入力される。通知／転送処理部ＮＴＣでは、所定の宛先に加工データを転送し、ディスク格納処理部ＬＤＭ−ＤはディスクＤＳＫに加工データを書き込む。

このように、アクション実施部ＡＣＥの処理部を直列的に接続することで、一回のイベント発生で複数のアクションを実行することが可能となり、アクション実行の高速化を図ることができる。そして、データ加工処理部ＤＰＲの後段に他の処理部を設けることで、データ加工のアクションの後に生成された加工データに対する転送や格納などのアクションを一回のイベント発生で実行することが可能となる。

＜第５実施形態＞
図５５〜図５８は、第５実施形態を示し、前記第３実施形態において、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣに、例外的なアクションを設定する例外イベントアクションテーブルＥ−ＥＡＴＢを設け、アクション実施部ＡＣＥでこの例外イベントアクションテーブルＥ−ＥＡＴＢを参照するようにしたもので、その他の構成は前記第３実施形態と同様である。

そして、イベントアクションテーブルＥＡＴＢには、図５６で示すように、例外処理欄を設け、この例外処理欄に処理の内容とパラメータ欄を備えたものである。処理内容には、スクリプト処理など上記データ加工処理、転送処理及び通知処理などの定型化された処理では実施できないような複雑な処理を実行可能なスクリプト処理等のプログラム処理を実行可能にする。そして、オプション欄には処理が記述されたファイル名を設定する。

このオプション欄に設定されたファイル名は、予めイベントアクションテーブルＥＡＴＢ、例外イベントアクションテーブルＥ−ＥＡＴＢに格納しておく。ここでは、例外処理をＸＭＬスクリプトで記述した一例を図５７に示す。

図５７は、ファイル名ＣのＸＭＬスクリプトファイルであり、温度を示すデータＩＤ＝Ｚ１のデータをセンサノードから取得し、このデータの値が１０〜２０度の範囲になければ、「暑くなったのでクーラをつけます」というメッセージを、所定の送信先（ＩＰアドレス＝133.144.xx.xx）に送信し、さらに「cooler.com」という機器に対してクーラを作動させるように「activate」の指令を送信するものである。

上記例外処理を設定する処理の流れを図５８に示す。ユーザ端末ＵＳＴからディレクトリサーバＤＲＳに対してイベントアクションの登録要求を行うとともに、予め用意したスクリプトファイルを送付する（５００）。

ディレクトリサーバＤＲＳでは、アクション制御部ＡＣＣがイベントアクションの登録要求を受け付け、スクリプトファイルを取得する。アクション制御部ＡＣＣは、前記第１実施形態の図３３で示したように、要求のあった意味情報を実世界モデルテーブルＭＴＢに基づいて分析し、対応する分散データ処理サーバＤＤＳに対してイベントアクションの登録要求とスクリプトファイルを送付する（５１０）。

分散データ処理サーバＤＤＳでは、イベントアクション制御部ＥＡＣが送付されたスクリプトファイルを例外イベントアクションテーブルＥ−ＥＡＴＢに登録し（５２０）、イベントアクションテーブルＥＡＴＢに要求のあったイベントアクションと例外処理欄のパラメータ欄に登録したスクリプトファイル名を指定する（５３０）。そして、登録完了をディレクトリサーバＤＲＳに通知する（５４０）。

ディレクトリサーバＤＲＳは、分散データ処理サーバＤＤＳからの通知に基づいてユーザ端末ＵＳＴへイベントアクションの登録完了を通知する（５５０）。

以上のように設定されたイベントアクションテーブルＥＡＴＢにより、分散データ処理サーバＤＤＳでは次の処理が実行される。

イベントアクション制御部ＥＡＣは、センサノードからのデータＩＤ＝Ｚ１のデータを監視し、Ｚ１のデータを受信すると例外処理欄のスクリプト処理を実行するため、オプション欄に設定されたファイル名ＣのＸＭＬスクリプトファイルを例外イベントアクションテーブルＥ−ＥＡＴＢから読み込んで、アクション実施部ＡＣＥで実行する。

図５７に示されたスクリプトの場合は、温度を示すデータＩＤ＝Ｚ１のデータが１０〜２０度の範囲にあるかどうかを、すなわちイベントが発生したかどうかをアクション実施部で判定しており、スクリプトに基づきイベントが発生したと判定された場合は、「暑くなったのでクーラをつけます」というメッセージを送るというアクションと、クーラを作動させる、というアクションを実行している。

以上のように、定型化が難しい処理については、スクリプトなどのプログラム処理を用いることでより高度な処理を実現可能となり、センサノードからの測定データに基づいて、ユーザ必要とする処理を柔軟に設定可能となる。

なお、上記プログラム処理はスクリプトに限らず、実行ファイルなどであってもよい。

また、上記では例外イベントアクションテーブルＥ−ＥＡＴＢを分散データ処理サーバＤＤＳに設ける例を示したが、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣに例外イベントアクションテーブルＥ−ＥＡＴＢを設けても良い。この場合、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣにおいて、複数の分散データ処理サーバＤＤＳに渡る複雑な処理を実行することが可能となる。

＜変形例１＞
図５９、６０は、第１の変形例を示し、前記第１実施形態に示したディレクトリサーバＤＲＳのアクション制御部ＡＣＣにおいて、前記第３または第４実施形態で示したように、取得したデータ（またはイベント）に基づくアクションを連鎖的に行うようにしたもので、その他の構成は前記第１実施形態と同様である。

アクション実行部ＡＣＥＣの出力は、ユーザ端末ＵＳＴ側だけではなくイベント受信部ＥＲＣにも送信される。すなわち、アクション実行部ＡＣＥＣは図６０で示すように構成され、前記第１実施形態の図２７に対して、データ加工処理部ＤＰＲの出力がループバックパスＲＰによって、イベント受信部ＥＲＣに接続される点が異なっている。なおその他の構成は図２７に準じる。

データ加工処理部ＤＰＲで生成された加工データには仮想的なデータＩＤ（またはイベントＩＤ）が付加され、ネットワークインターフェースＮＩＦとイベント受信部ＥＲＣに送られる。

この加工データをイベント受信部ＥＲＣで受信すると、アクションディスパッチャＡＤＰでは、仮想的なデータＩＤに基づいてアクションテーブルＡＴＢから予め設定されたアクションを取得し、各処理部へ指令する。

このようにディレクトリサーバＤＲＳのアクション制御部ＡＣＣでは、実行したアクションに基づいて生成されたデータについて、アクションを実行することができる。

＜変形例２＞
図６１、図６２は第２の変形例を示し、前記第１または第２実施形態の変形例を示す図である。この変形例においては、あるセンサノードからの測定データを生データＡとして所定の分散データ処理サーバＤＤＳに格納し、また、異なるセンサノードからの測定データを生データＢとして所定の分散データ処理サーバＤＤＳに格納する。

そして、各分散データ処理サーバＤＤＳでは、生データＡ（ＲＤＡＴＡ）、生データＢにそれぞれ加工（例えば、単位時間の平均値など）を施し、加工した結果をさらにディレクトリサーバＤＤＳにデータＡ’（ＰＤＡＴＡ）、Ｂ’（ＰＤＡＴＢ）としてそれぞれ格納する。生データＡ、Ｂの加工のタイミングは、ディレクトリサーバＤＲＳまたは各分散データ処理サーバＤＤＳにおいて、所定の条件（時間の経過）に基づくアクションとして実施すればよい。なお、生データの加工を各分散データ処理サーバＤＤＳで行う場合には、図４４に示したイベントアクションテーブルＥＡＴＢにデータの格納先を付加すればよい。

さらに、各分散データ処理サーバＤＤＳでは、加工を施した加工データＡ’（ＰＤＡＴＡ）、Ｂ’（ＰＤＡＴＢ）から二次データＣ（ＲＤＡＴＣ）を所定のアクションとして演算し、新たな加工データとして所定の分散データ処理サーバＤＤＳに格納する。この二次データＣに加工を施したものを、さらに三次データＣ’（ＰＤＡＴＣ）として格納する。

例えば、生データＡが温度、生データＢが湿度の場合、加工データＡ、Ｂはそれぞれ、単位時間の平均温度と平均湿度となる。さらに、平均温度と平均湿度から求めた不快指数を二次データＣと、さらに二次データＣの単位時間の平均値を三次データＣ’として求めることができる。

上記第１または第２実施形態において、イベント発生を測定データとしたが、上記のような加工データＡ、Ｂや二次データＣ、三次データＣ’からイベントの発生やアクションの実施を行うことができる。

そして、図６２で示すように、測定データ（生データ）と加工データを一つの分散データ処理サーバＤＤＳに格納しておけば、ディレクトリサーバＤＲＳでの実世界モデルテーブルＭＴＢの構成を簡易にすることができる。なお、この場合、加工データＡ、Ｂから求めた二次データＣを生データとして扱い、三次データＣ’を加工データとして扱うことができる。

なお、生データから加工データの演算を、前記第１実施形態に示したディレクトリサーバＤＲＳで行う場合には、前記第１変形例と同様にして、ディレクトリサーバＤＲＳのアクション実行部ＡＣＥＣの出力を、イベント受信部ＥＲＣへ入力させ、加工データに仮想的なデータＩＤを付与するようにすればよい。

＜変形例３＞
図６３は、第３の変形例を示し、前記第２または第３実施形態において、複数のセンサネットワーク（ＮＷＫ１〜３）を接続し、異なるセンサネットワークの分散データ処理サーバＤＤＳ間でデータの加工を行うようにしたものである。

図６３において、ネットワークＮＷＫ１には、分散データ処理サーバＤＤＳ１−１〜３が接続され、これら分散データ処理サーバＤＤＳ１−１〜３には、それぞれ複数のセンサノード（図示省略）が接続されている。

また、ネットワークＮＷＫ２には分散データ処理サーバＤＤＳ２−１が接続され、ネットワークＮＷＫ３には分散データ処理サーバＤＤＳ３−１が接続され、各分散データ処理サーバＤＤＳには複数のセンサノードが接続されている。

ネットワークＮＷＫ１の分散データ処理サーバＤＤＳ１−１のイベントアクションテーブルＥＡＴＢには、測定データＲＤＡＴＡを受信するとディスクへ格納するとともに、ネットワークＮＷＫ２の分散データ処理サーバＤＤＳ２−１へ転送するように設定される。

また、ネットワークＮＷＫ２の分散データ処理サーバＤＤＳ２−１のイベントアクションテーブルＥＡＴＢには、測定データＲＤＡＴＡを受信すると所定の加工を行って加工データＰＤＡＴＤを生成し、ディスクへ格納するとともにネットワークＮＷＫ３の分散データ処理サーバＤＤＳ３−１へ加工データＰＤＡＴＤを転送するように設定される。

ネットワークＮＷＫ１の分散データ処理サーバＤＤＳ１−２のイベントアクションテーブルＥＡＴＢには、測定データＲＤＡＴＢを受信するとディスクへ格納するとともに、ネットワークＮＷＫ３の分散データ処理サーバＤＤＳ３−１へ転送するように設定される。

ネットワークＮＷＫ３の分散データ処理サーバＤＤＳ３−１のイベントアクションテーブルＥＡＴＢには、分散データ処理サーバＤＤＳ２−１からの加工データＰＤＡＴＤと、分散データ処理サーバＤＤＳ１−２からの測定データＲＤＡＴＢから加工データＰＤＡＴＥを演算し、ディスクへ格納するように設定されている。

上記のような設定により、ネットワークＮＷＫ１のセンサノードから測定された測定データＲＤＡＴＡはネットワークＮＷＫ２の分散データ処理サーバＤＤＳ２−１へ転送されて加工データＰＤＡＴＤとして加工されてからネットワークＮＷＫ３の分散データ処理サーバＤＤＳ３−１に加工データＰＤＡＴＤが転送される。

また、ネットワークＮＷＫ１のセンサノードから測定された測定データＲＤＡＴＢはネットワークＮＷＫ３の分散データ処理サーバＤＤＳ３−１へ転送される。

そして、ネットワークＮＷＫ３の分散データ処理サーバＤＤＳ３−１は、ネットワークＮＷＫ１からの測定データＲＤＡＴＢと、ネットワークＮＷＫ２からの加工データＰＤＡＴＤから加工データＰＤＡＴＥを演算して、ディスクへ格納する。

このように、イベントアクションテーブルＥＡＴＢに外部のネットワークＮＷＫとのデータの送受信と、データの加工を定義することで、異なるセンサネットワーク間で、データを転送しながら順次加工することができる。

これにより、各センサネットワークの膨大な数のセンサノードの測定データの中から必要なものだけを抽出し、各センサネットワークで必要な加工を行うことで、複数のセンサネットワークを連結して効率よくデータの送受信を行うことが可能となる。

＜変形例４＞
なお、上記第１または第２実施形態では、ディレクトリサーバＤＲＳの実世界モデルリストＭＤＬには、モデル名に対応するデータの格納先を情報リンク先として設定したが、情報リンク先に代わって、データの最新値などを格納しても良い。

この場合、ディレクトリサーバＤＲＳと分散データ処理サーバＤＤＳの間のデータトラフィックは、オブジェクトの数に応じて増えるが、各センサからのデータは所定の周期で分散データ処理サーバＤＤＳに収集されるので、ネットワークＮＷＫ−１の負荷が過大になるのを防いで、ユーザ端末ＵＳＴからのデータ要求に対して、迅速に応答することが可能となり、レスポンスの向上を期待できる。

以上のように、本発明によれば、ディレクトリサーバがデータの所在を一元的に管理し、センサノードからのデータをリアルタイムで収集する分散データ処理サーバを複数備えて、ネットワーク上に分散し、所望のセンサノードの情報をイベントとアクションによりリアルタイムで監視できるので、膨大な数のセンサノードからのデータを効率よく利用することが可能となり、多数のセンサノードを備えるセンサネットワークに適用することができる。

本発明の第１の実施形態を示すセンサネットワークのシステム構成図。 センサネットワークの機能ブロック図。 無線センサノードＷＳＮの一例を示すブロック図。 無線センサノードの動作状態を示すグラフで、時間と消費電流の関係を示す。 無線センサノードの配置の一例を示す説明図。 オブジェクトとセンサノードの測定データの関連を示すブロック図で、測定の開始時を示す。 オブジェクトとセンサノードの測定データの関連を示すブロック図で、測定開始から所定時間が経過した状態を示す。 オブジェクトのデータ量とセンサノードの測定データのデータ量と時間の関係を示すグラフ。 分散データ処理サーバＤＤＳのイベントアクション制御部を示すブロック図。 イベントテーブルの説明図。 ディレクトリサーバＤＲＳの要部を示すブロック図。 センサ情報テーブルの説明図。 属性別意味解釈リストの説明図。 実世界モデルリストと分散データ処理サーバＤＤＳの関係を示すブロック図。 モデルバインドリストの説明図。 センサ情報登録の様子を示すタイムチャート。 センサノード登録用のデータフォーマット。 実世界モデルリストの登録の様子を示すタイムチャート。 モデルバインドリストの登録の様子を示すタイムチャート。 モデルバインドリストへのアクセスに対する応答の一例を示すタイムチャート。 モデルバインドリストから鈴木さんの位置を指定した場合の処理の説明図。 モデルバインドリストから鈴木さんの着座状態を指定した場合の処理の説明図。 モデルバインドリストから鈴木さんの温度を指定した場合の処理の説明図。 モデルバインドリストからＡ会議室のメンバを指定した場合の処理の説明図。 モデルバインドリストからＡ会議室の人数を指定した場合の処理の説明図。 ディレクトリサーバＤＲＳのアクション制御部ＡＣＣのブロック図。 アクション制御部ＡＣＣを構成するアクション実施部ＡＣＥＣのブロック図。 アクションテーブル設定の説明図。 アクションテーブルの登録の際にユーザ端末ＵＳＴに表示されるアクション設定画面の説明図。 同じく、アクション設定画面の説明図。 分散データ処理サーバＤＤＳのイベントテーブルＥＴＢのエントリを示す説明図。 ディレクトリサーバＤＲＳのアクションテーブルＡＴＢのエントリを示す説明図。 単一のアクションの設定の流れを示すタイムチャート。 単一のアクションの応答の流れを示すタイムチャート。 複数アクションの登録の際にユーザ端末ＵＳＴに表示されるアクション設定画面の説明図。 同じく、複数アクションの登録の際にユーザ端末ＵＳＴに表示されるアクション設定画面の説明図。 分散データ処理サーバＤＤＳ−１のイベントテーブルのエントリを示す説明図。 分散データ処理サーバＤＤＳ−２のイベントテーブルのエントリを示す説明図。 ディレクトリサーバＤＲＳのアクションテーブルのエントリを示す説明図。 複数のアクションの設定の流れを示すタイムチャート。 複数のイベントの応答の流れを示すタイムチャート。 第２の実施形態を示し、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣを示すブロック図。 第２の実施形態を示し、アクションの登録の際にユーザ端末ＵＳＴに表示されるアクション設定画面の説明図。 第２の実施形態を示し、分散データ処理サーバＤＤＳのイベントアクションテーブルのエントリを示す説明図。 イベントアクションの設定の流れを示すタイムチャート。 第２の実施形態を示し、分散データ処理サーバＤＤＳでのアクションの実行の流れを示すタイムチャート。 第３の実施形態を示し、分散データ処理サーバＤＤＳのイベントアクション制御部を示すブロック図。 第３の実施形態を示し、イベントアクション制御部のアクション実施部ＡＣＥのブロック図。 第３の実施形態を示し、一つのイベント発生から連鎖的にイベント／アクションを実行する流れを示す説明図。 第３の実施形態を示し、イベントアクションテーブルの一例を示す説明図。 第３の実施形態を示し、複数の測定データから加工データを生成する流れを示す説明図。 第３の実施形態を示し、複数の測定データから加工データを生成する際のイベントアクションテーブルの一例を示す説明図。 第３の実施形態を示し、複数の分散データ処理サーバにより複数の測定データから加工データを生成する流れを示す説明図。 第４の実施形態を示し、イベントアクション制御部のアクション実施部ＡＣＥのブロック図。 第５の実施形態を示し、分散データ処理サーバＤＤＳのイベントアクション制御部を示すブロック図。 第５の実施形態を示し、イベントアクションテーブルの一例を示す説明図。 第５の実施形態を示し、例外イベントアクションテーブルに格納されるスクリプトファイルの一例を示す説明図。 第５の実施形態を示し、例外イベントアクションの設定の流れを示すタイムチャート。 第１の変形例を示し、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣのブロック図。 第１の変形例を示し、アクション制御部ＡＣＣを構成するアクション実行部ＡＣＥＣのブロック図。 第２の変形例を示すセンサネットワークのシステム構成図。 同じく、第２の変形例を示すセンサネットワークのシステム構成図。 第３の変形例を示すセンサネットワークのシステム構成図。

符号の説明

ＤＲＳ ディレクトリサーバ
ＤＤＳ 分散データ処理サーバ
ＷＳＮ、ＭＳＮ、ＦＳＮ センサノード
ＢＳＴ 基地局
ＭＭＧ モデル管理部
ＭＴＢ 実世界モデルテーブル
ＮＷＫ−１、２〜ｎ ネットワーク
ＡＣＣ アクション制御部
ＥＡＣ イベントアクション制御部

Claims (18)

1. 複数のセンサノードから送信されるデータを処理する分散サーバと、
   ネットワークを介して前記分散サーバと接続される管理サーバとを備え、
   前記管理サーバは、
   前記センサノードの識別子であるセンサＩＤ及びセンサノードのセンシング対象を規定するモデル名を関連づけるモデルリストを格納する管理サーバ記憶領域と、
   前記モデルリストに基づいて、特定のモデル名について関連づけられた各センサＩＤに対する監視条件を設定して前記分散サーバに送信し、前記分散サーバからイベントの発生を通知された場合に、予め設定された処理を実行するアクション制御部と、を有し、
   前記分散サーバは、
   前記センサＩＤに対応するデータの値の監視条件を格納するイベントテーブルと、を格納する分散サーバ記憶領域と、
   前記複数のセンサノードから送信されるデータをセンサＩＤと関連づけて格納するセンサデータ格納部と、
   前記アクション制御部から前記監視条件を受信した場合、前記イベントテーブルに当該監視条件を設定するイベントテーブル追加部と、
   前記センサノードのひとつからデータを受信した際に、前記センサＩＤに対応して前記イベントテーブルから抽出される前記監視条件に前記受信したデータが合致している場合、前記管理サーバへイベントの発生を通知するイベント発生判定部とを有することを特徴とするセンサネットワークシステム。
2. 複数のセンサノードから送信されるデータを処理する分散サーバと、
   ネットワークを介して前記分散サーバと接続される管理サーバとを備え、
   前記管理サーバは、
   センサノードの識別子であるセンサＩＤ及びセンサノードのセンシング対象を規定するモデル名を関連づけるモデルリストを格納する管理サーバ記憶領域と、
   前記モデルリストに基づいて、特定のモデル名について関連づけられた各センサＩＤに対する監視条件を設定して前記分散サーバに送信するアクション制御部を有し、
   前記分散サーバは、
   前記センサＩＤに対応するデータの値の監視条件を格納するイベントテーブルと、を格納する分散サーバ記憶領域と、
   前記複数のセンサノードから送信されるデータをセンサＩＤと関連づけて格納するセンサデータ格納部と、
   前記アクション制御部から前記監視条件を受信した場合、前記イベントテーブルに当該監視条件を設定するイベントテーブル追加部と、
   前記センサノードのひとつからデータを受信した際に、前記センサＩＤに対応して前記イベントテーブルから抽出される前記監視条件に前記受信したデータが合致している場合、予め設定された処理を実行するアクション実施部とを有することを特徴とするセンサネットワークシステム。
3. 前記管理サーバは、前記ネットワークを介してユーザが利用するユーザ端末に接続され、
   前記管理サーバ記憶領域には、前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストをさらに格納し、
   前記管理サーバの前記モデルリストは、前記モデル名に対応する前記データの情報格納先をさらに格納し、
   前記管理サーバのアクション制御部は、
   前記ユーザ端末の要求からモデル名と意味情報を取得する受付部と、
   前記モデル名からモデルリストを参照して情報格納先の分散サーバと監視対象のデータを決定し、前記意味情報から意味解釈リストを参照して、前記センサノードのデータに対する監視条件を決定する分析部と、
   前記決定した監視対象と監視条件とを前記情報格納先の分散サーバに指令する監視指示部を有し、
   前記分散サーバは、
   前記監視指示部からの指令に基づいて、前記イベントテーブルに監視対象と監視条件とを設定することを特徴とする請求項１または請求項２に記載のセンサネットワークシステム。
4. 前記管理サーバのセンサ情報管理部は、前記センサノードにセンサＩＤを設定し、
   前記センサノードは、前記設定されたセンサＩＤを含んでデータを送信し、
   前記分散サーバは、
   前記センサノードより受信したデータから前記センサＩＤを抽出するＩＤ抽出部と、
   前記抽出したセンサＩＤからデータを比較する監視条件を前記イベントテーブルから検索するイベント検索部と、を含み、
   前記イベント発生判定部は、
   前記検索した監視条件に基づいて前記データの比較を行って前記監視条件の成立を判定し、前記監視条件の成立時にはイベントを発生することを特徴とする請求項１または請求項２に記載のセンサネットワークシステム。
5. 前記管理サーバのアクション制御部は、
   前記イベントの発生が通知されたときに実行する処理を前記センサＩＤに対応して予め格納する第１アクションテーブルを有し、前記分散サーバのイベント発生判定部がイベントの発生を通知したときに、前記センサＩＤに基づいて前記第１アクションテーブルに格納された処理を実行することを特徴とする請求項４に記載のセンサネットワークシステム。
6. 前記管理サーバのアクション制御部は、
   前記第１アクションテーブルに格納される処理が、前記センサノードから送信されたデータを加工する処理であるときは、前記データを加工し、加工されたデータに識別子を付与し、当該加工後のデータを当該アクション制御部へイベントとして入力することを特徴とする請求項５に記載のセンサネットワークシステム。
7. 前記管理サーバは、前記ネットワークを介してユーザが利用するユーザ端末に接続され、
   前記管理サーバ記憶領域は、さらに前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストをさらに格納し、
   前記管理サーバの前記モデルリストは、前記モデル名に対応する前記データの情報格納先をさらに格納し、
   前記管理サーバのアクション制御部は、
   ユーザ端末の要求からモデル名と意味情報を取得する受付部と、
   前記モデル名からモデルリストを参照して情報格納先の分散サーバと監視対象のデータを選択し、前記意味情報から意味解釈リストを参照して、前記センサノードのデータに対する監視条件を決定する分析部と、
   前記決定した監視対象と監視条件とを前記情報格納先の分散サーバに指令する監視指示部とを有し、
   前記監視指示部は、ユーザ端末の要求に基づいて前記実行する処理を前記アクション制御部に通知し、
   前記アクション制御部は、当該通知に基づいて第１アクションテーブルに実行すべき処理を設定することを特徴とする請求項５に記載のセンサネットワークシステム。
8. 前記アクション実施部は、
   実行する処理を記述したファイルのファイル名を、前記センサＩＤに対応して指定される第１アクションテーブルと、
   前記実行する処理を記述したファイルを格納する第２アクションテーブルとを有し、
   前記アクション実施部は、前記センサＩＤに基づいて前記第１アクションテーブルに格納されるファイル名に基づき前記第２アクションテーブルに格納されるファイルの処理を実行する請求項６に記載のセンサネットワークシステム。
9. 前記第２アクションテーブルに格納されるファイルを前記アクション実施部で実行するときは、
   前記アクション実施部が、前記イベント発生判定部に代えて前記監視条件と前記データとを比較して前記監視条件の成立を判定し、該監視条件が成立した場合に実行する処理を決定することを特徴とする請求項８に記載のセンサネットワークシステム。
10. 複数のセンサノードから送信されるデータを処理する分散サーバと、前記センサノードを管理する管理サーバとをネットワークで接続し、前記センサノードからのデータに基づいて予め設定した処理を実行する方法であって、
    前記管理サーバが、前記センサノードの識別子であるセンサＩＤと、前記センサノードのセンシング対象を規定するモデル名を関連づけて管理サーバ記憶領域のモデルリストに格納する第１の手順と、
    前記管理サーバが、前記モデルリストに基づいて、特定のモデル名について関連づけられた各センサＩＤに対する監視条件を設定して前記分散サーバに送信する第２の手順と、
    前記分散サーバが、前記管理サーバから前記特定のモデル名について関連づけられた各センサＩＤに対する監視条件を受信して、前記センサＩＤに対応するデータの値の監視条件を、分散サーバ記憶領域のイベントテーブルに格納する第３の手順と、
    前記分散サーバが、前記センサノードのひとつからデータを受信した際に、前記センサＩＤに対応して前記イベントテーブルから抽出される前記監視条件に前記受信したデータが合致している場合、前記管理サーバへイベントの発生を通知する第４の手順と、
    前記管理サーバが、前記分散サーバからイベントの発生を通知された場合に、予め設定された処理を実行する第５の手順と、
    を含むことを特徴とするセンサデータの処理方法。
11. 複数のセンサノードから送信されるデータを処理する分散サーバと、前記センサノードを管理する管理サーバとをネットワークで接続し、前記センサノードからのデータに基づいて予め設定した処理を実行する方法であって、
    前記管理サーバが、前記センサノードの識別子であるセンサＩＤと、前記センサノードのセンシング対象を規定するモデル名を関連づけて管理サーバ記憶領域のモデルリストに格納する第１の手順と、
    前記管理サーバが、前記モデルリストに基づいて、特定のモデル名について関連づけられた各センサＩＤに対する監視条件を設定して前記分散サーバに送信する第２の手順と、
    前記分散サーバが、前記管理サーバから前記特定のモデル名について関連づけられた各センサＩＤに対する監視条件を受信して、前記センサＩＤに対応するデータの値の監視条件を、分散サーバ記憶領域のイベントテーブルに格納する第３の手順と、
    前記分散サーバが、前記センサノードのひとつからデータを受信した際に、前記センサＩＤに対応して前記イベントテーブルから抽出される前記監視条件に前記受信したデータが合致している場合、予め設定された処理を実行する第６の手順と、
    を含むことを特徴とするセンサデータの処理方法。
12. 前記管理サーバは、前記ネットワークを介してユーザが利用するユーザ端末に接続され、
    前記管理サーバ記憶領域には、前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストをさらに格納し、
    前記データの値の監視条件をイベントテーブルに設定する第３の手順は、
    前記管理サーバが、前記ユーザ端末の要求からモデル名と意味情報を取得する手順と、
    前記管理サーバが、前記モデル名から前記モデルリストを参照して情報格納先の分散サーバと監視対象のデータを決定し、前記意味情報から意味解釈リストを参照して、前記センサノードのデータに対する監視条件を決定する手順と、
    前記管理サーバが、前記決定した監視対象と監視条件とを前記情報格納先の分散サーバに指令する手順と、
    前記分散サーバが、前記管理サーバからの指令に基づいて、前記イベントテーブルに監視対象と監視条件とを設定する手順と、
    を含むことを特徴とする請求項１０または請求項１１に記載のセンサデータの処理方法。
13. 前記管理サーバが、前記センサノードにセンサＩＤを設定する手順と、
    前記センサノードが、前記設定されたセンサＩＤを含んでデータを分散サーバに送信する手順と、
    をさらに含み、
    前記第４の手順は、
    前記分散サーバが、前記センサノードより受信したデータから前記センサＩＤを抽出する手順と、
    前記分散サーバが、前記抽出したセンサＩＤからデータを比較する監視条件を前記イベントテーブルから検索する手順と、
    前記検索した監視条件と前記データとの比較を行って前記監視条件の成立を判定し、監視条件が成立したときにイベントを発生する手順と、
    を含むことを特徴とする請求項１０または請求項１１に記載のセンサデータの処理方法。
14. 前記監視条件が成立したときに実行する前記予め設定した処理を、前記センサＩＤに対応して第１アクションテーブルに格納する手順と、をさらに含み、
    前記予め設定した処理を実行する第５の手順は、
    前記管理サーバが前記イベントの発生を受信したときに、前記センサＩＤに基づいて前記第１アクションテーブルに格納された処理を実行する手順と、
    を含むことを特徴とする請求項１０に記載のセンサデータの処理方法。
15. 前記監視条件が成立したときに実行する前記予め設定した処理を、前記センサＩＤに対応して第１アクションテーブルに格納する手順と、をさらに含み、
    前記予め設定した処理を実行する第６の手順は、
    前記分散サーバが前記イベントを発生したときに、前記分散サーバが前記センサＩＤに基づいて前記第１アクションテーブルに格納される処理を実行する手順と、
    を含むことを特徴とする請求項１１に記載のセンサデータの処理方法。
16. 前記予め設定した処理を実行する第６の手順は、
    前記第１アクションテーブルに格納される処理が、前記センサノードから送信されたデータを加工する処理であるときは、
    前記分散サーバが前記データを加工する手順と、
    前記加工されたデータに識別子を付与する手順と、
    を含み、
    前記監視を行う手順は、
    前記分散サーバが、当該加工後のデータを仮想的なセンサノードのデータとして受け付ける手順と、
    を含むことを特徴とする請求項１５に記載のセンサデータの処理方法。
17. 前記管理サーバは、前記ネットワークを介してユーザが利用するユーザ端末に接続され、
    前記実行する処理を前記センサＩＤに対応して前記第１アクションテーブルに格納する手順は、
    ユーザ端末の要求に基づいて前記第１アクションテーブルに格納する手順と、
    を含むことを特徴とする請求項１５に記載のセンサデータの処理方法。
18. 実行する処理を記述したファイルのファイル名と、前記センサＩＤとを対応させて前記第１アクションテーブルに格納する手順と、
    前記分散サーバで、前記実行する処理を記述したファイルを第２アクションテーブルに格納する手順と、
    前記分散サーバで、前記センサＩＤに基づいて前記第１アクションテーブルに格納されるファイル名に基づき前記第２アクションテーブルに格納されるファイルの処理を実行する手順と、
    をさらに含むことを特徴とする請求項１５に記載のセンサデータの処理方法。

Images