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

Description

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

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

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

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

本発明では、ネットワークに接続された多数のセンサからのリアルタイムの情報を、容易に検索できるようなセンサネットワークシステムを実現することを目的とする。

本発明は、複数のセンサノードから送信されるデータを格納する分散サーバと、第１のネットワークを介して複数の前記分散サーバとユーザ端末に接続される管理サーバと、を備え、前記複数の分散サーバは、前記複数のセンサノードから送信されるデータをそれぞれ蓄積する記憶部を有し、前記管理サーバは、予め設定された複数のモデル名と、前記モデル名に対応するデータの格納先が何れの前記分散サーバであるかを特定する情報格納先とを、を格納したモデルリストと、前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストと、前記モデル名を構成する要素のうち、複数のモデル名で共通する要素を含み、かつ異なる種類のデータについて前記モデルリストの情報格納先と関連付けを行った定義を格納するモデルバインドリストと、を管理するモデル管理部と、前記ユーザ端末から検索要求を受けて付けて、前記検索要求に含まれるモデル名を含むデータの情報格納先を前記ユーザ端末に応答する検索部と、前記分散サーバから受信したデータをユーザ端末を利用するユーザが理解可能な有意な情報に変換して、前記分散サーバに代わって前記ユーザ端末に応答する意味解釈部と、を備え、前記検索部は、前記ユーザ端末から検索要求を受け付けて、前記検索要求に含まれるモデル名の要素を前記モデルバインドリストから検索し、前記検索要求に含まれるモデル名の要素が一致する前記定義を抽出して前記ユーザ端末に前記モデル名の要素と前記情報格納先を応答し、前記ユーザ端末は、前記検索部から受信した定義のうち、ユーザが選択したモデル名の要素とデータの種類に対応する情報格納先を取得して、当該情報格納先の分散サーバに前記モデル名に対応するデータを要求し、前記分散サーバは、前記ユーザ端末から前記データの要求を受け付けると、前記データを記憶部から取得して前記管理サーバに送信し、前管理サーバの意味解釈部は、前記分散サーバから受信したデータを、前記モデル名に対応する前記変換定義を前記意味解釈リストから取得して、当該変換定義に基づいて前記取得したデータを有意な情報に変換し、当該有意な情報を前記ユーザ端末に応答する。

したがって、本発明は、センサからのデータ収集は分散サーバで行い、センサのデータの所在は管理サーバで管理し、ユーザ端末は管理サーバにデータの所在を要求し、ユーザ端末は管理サーバから取得した情報格納先の分散サーバにデータを要求し、管理サーバが分散サーバから受信したデータを取得し、ユーザ端末に応答する。これにより、センサの数が膨大になったとしても、管理サーバにはデータが蓄積されないため負荷が過大になるのを防ぐことができ、多数のセンサを使用しながら、管理サーバと分散サーバ及びユーザ端末を接続するネットワークのトラフィックが過大になるのを抑制しながら、ユーザに必要な情報を容易且つ迅速に提供することができる。

そして、ユーザは、センサの位置や機能を把握する必要がなく、管理サーバにデータを要求すれば所望のセンサのデータを有意な情報として取得でき、多数のセンサを有するセンサネットワークにおいて、情報の利用を容易にすることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

モデル管理部ＭＭＧは、ユーザが理解し易い実世界のモデル（オブジェクト）と分散データ処理サーバＤＤＳがセンサノードから収集した測定データ、もしくは加工データとの対応関係を実世界モデルテーブルＭＴＢに設定した実世界モデルリストＭＤＬによって管理する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そして、ディレクトリサーバＤＲＳは、分散データ処理サーバＤＤＳから得られたデータを属性別意味解釈リストＡＴＬに基づいて、ユーザが理解可能な情報に変換してユーザ端末ＵＳＴに提供するので、
また、ディレクトリサーバＤＲＳに格納するオブジェクトは、構築するシステム構成に応じて設定・変更されるものであり、センサノードが検出する測定データのように経時的に変化するものではないので、オブジェクトを集中的に管理する部分は経時的な測定データの負荷変動の影響を受けない。したがって、分散データ処理サーバＤＤＳとの間で直接的にセンサノードのデータをやり取りすることが抑制されるので、ディレクトリサーバＤＲＳに接続されたネットワークＮＷＫ−１の負荷が過大になるのを抑制できる。

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

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

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

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

例えば、図中、データＩＤが「ＸＸＸ」の測定データは、その値がＡ１より大のときにイベントの発生をディレクトリサーバＤＲＳに通知する。なお、データＩＤが「ＸＸＸ」の測定データは、データ到着毎に、ディスク装置ＤＳＫに書き込まれるように設定される。

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

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

イベント発生判定部ＥＶＭでは、測定データの値とイベント内容ＥＶＴを比較して、条件を満たせばイベントの発生を、ディレクトリサーバインターフェースＤＳＩを通じて、ディレクトリサーバＤＲＳに通知する。また、イベント発生判定部ＥＶＭは、データ格納ＤＨＬの要求を最新データメモリに伝える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、アクション管理部ＡＭＧでは、「Ｘさんの着席」というイベント発生を分散データ処理サーバＤＤＳで監視するため、上記選択したセンサノードを管理する分散データ処理サーバＤＤＳに対して「Ｘさんの着席」というイベント発生を監視するように指令を送出する。そして、アクション管理部ＡＭＧは、アクションテーブルＡＴＢに「ＩＰアドレス：Ａのユーザ端末ＵＳＴにポップアップ通知を送信する」というアクションを設定し、当該アクションを実行するイベントのＩＤとして、上記センサノードＩＤを設定する。

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

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

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

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

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

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

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

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

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

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

アクション実行部ＡＣＥは、アクション管理部ＡＭＧから指示されたＩＰアドレス：Ａのユーザ端末ＵＳＴに対してポップアップ通知を送信する。

ＩＰアドレス：Ａのユーザ端末ＵＳＴには、ポップアップ通知が送信され、Ｘさんの着席が検知されたことを確認できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データアクセス受け付け部ＤＡＲは前記第１実施形態と同様であり、アクセス要求が最新のデータであれば、アクセス要求に含まれるデータＩＤに対応する測定データを最新データメモリＬＤＭから読み込んで、ディレクトリサーバインターフェースＤＳＩへ返送する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そして、図４７で示すように、測定データ（生データ）と加工データを一つの分散データ処理サーバＤＤＳに格納している。なお、この場合加工データＡ、Ｂを、当該加工データを管理する分散データ管理サーバと異なる分散データ管理サーバＣへ転送し、加工データＡ、Ｂを生データとして扱い、三次データＣ’を加工データとして扱うことができる。

＜変形例２＞
図４８は、第２の変形例を示し、前記第１または第２実施形態において、分散データ処理サーバＤＤＳを接続するネットワークを複数に分割したものであり、その他の構成は前記第１または第２実施形態と同様である。

この例では、測定データを参照する頻度等に応じて分散データ処理サーバＤＤＳを接続するネットワークが異なるように設定したものである。

ディレクトリサーバＤＲＳ（図示省略）から測定データあるいは加工データの参照頻度の高いものを、ディレクトリサーバＤＲＳと同一のネットワーク１に接続する。そして、比較的参照頻度の引く合い加工データＤを格納する分散データ処理サーバＤＤＳをネットワーク２に接続し、ほとんど参照されない加工データＥを格納する分散データ処理サーバＤＤＳをネットワーク３に接続する。そして、各ネットワーク１〜３を図示しないゲートウェイにより接続しておく。

このように分散データ処理サーバＤＤＳを配置することで、頻繁に参照するデータを持つ分散データ処理サーバＤＤＳへのアクセス速度を向上させることができる。

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

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

以上のように、本発明によれば、ディレクトリサーバがデータの所在を一元的に管理し、センサノードからのデータをリアルタイムで収集する分散データ処理サーバを複数備えて、ネットワーク上に分散したので、膨大な数のセンサノードからのデータに対して迅速かつ容易にアクセスすることが可能となり、多数のセンサノードを備えるセンサネットワークに適用することができる。

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

符号の説明

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

Claims (12)

1. 複数のセンサノードから送信されるデータを格納する分散サーバと、
   第１のネットワークを介して複数の前記分散サーバとユーザ端末に接続される管理サーバと、を備え、
   前記複数の分散サーバは、
   前記複数のセンサノードから送信されるデータをそれぞれ蓄積する記憶部を有し、
   前記管理サーバは、
   予め設定された複数のモデル名と、前記モデル名に対応するデータの格納先が何れの前記分散サーバであるかを特定する情報格納先とを、を格納したモデルリストと、前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストと、前記モデル名を構成する要素のうち、複数のモデル名で共通する要素を含み、かつ異なる種類のデータについて前記モデルリストの情報格納先と関連付けを行った定義を格納するモデルバインドリストと、を管理するモデル管理部と、
   前記ユーザ端末から検索要求を受けて付けて、前記検索要求に含まれるモデル名を含むデータの情報格納先を前記ユーザ端末に応答する検索部と、
   前記分散サーバから受信したデータをユーザ端末を利用するユーザが理解可能な有意な情報に変換して、前記分散サーバに代わって前記ユーザ端末に応答する意味解釈部と、を備え、
   前記検索部は、
   前記ユーザ端末から検索要求を受け付けて、前記検索要求に含まれるモデル名の要素を前記モデルバインドリストから検索し、前記検索要求に含まれるモデル名の要素が一致する前記定義を抽出して前記ユーザ端末に前記モデル名の要素と前記情報格納先を応答し、
   前記ユーザ端末は、
   前記検索部から受信した定義のうち、ユーザが選択したモデル名の要素とデータの種類に対応する情報格納先を取得して、当該情報格納先の分散サーバに前記モデル名に対応するデータを要求し、
   前記分散サーバは、
   前記ユーザ端末から前記データの要求を受け付けると、前記データを記憶部から取得して前記管理サーバに送信し、
   前管理サーバの意味解釈部は、
   前記分散サーバから受信したデータを、前記モデル名に対応する前記変換定義を前記意味解釈リストから取得して、当該変換定義に基づいて前記取得したデータを有意な情報に変換し、当該有意な情報を前記ユーザ端末に応答することを特徴とするセンサネットワークシステム。
2. 前記分散サーバは、
   前記センサノードから受信したデータにＩＤを付与して、当該データＩＤとデータを関連づけて前記記憶部に格納し、前記ユーザ端末からデータの要求を受け付けると、前記データとデータＩＤを前記記憶部から取得して前記管理サーバに送信し、
   前記モデルリストは、
   前記モデル名と、当該モデル名に対応する情報格納先と、当該モデル名に対応するデータＩＤを格納し、
   前記意味解釈部は、
   前記分散サーバからデータ及びデータＩＤを受信し、前記受信したデータＩＤで前記モデルリストを検索して前記データＩＤが一致するモデル名を検索し、当該モデル名に対応する前記変換定義を前記意味解釈リストから取得し、当該取得した変換定義で前記データを有意な情報に変換することを特徴とする請求項１に記載のセンサネットワークシステム。
3. 前記分散サーバは、前記センサノードから送信されたデータのうち、予め設定された条件に合致したデータについてのみ前記記憶部へ格納することを特徴とする請求項１に記載のセンサネットワークシステム。
4. 前記管理サーバは、
   前記センサノードのうち、前記記憶部にデータを蓄積する前記分散サーバを設定するセンサ情報テーブルを有し、
   当該センサ情報テーブルでセンサノードのデータの格納先に設定された分散サーバに対してセンサノードのデータを蓄積するよう指令し、
   前記センサノードに対して前記データの格納先の分散サーバを割り当て、
   前記センサノードは、前記データを前記格納先の分散サーバに送信し、
   前記分散サーバは、前記指令を受け付けて、センサ情報テーブルに設定されたセンサノードのみからデータを蓄積することを特徴とする請求項１に記載のセンサネットワークシステム。
5. 前記センサノードを複数接続した基地局と、
   複数の基地局と所定の分散サーバとを接続する第２のネットワークと、
   を備え、
   前記分散サーバは、前記基地局を介してセンサノードからのデータを収集することを特徴とする請求項１に記載のセンサネットワークシステム。
6. 前記複数のセンサノードから送信されるデータは経時的に変化し、
   前記複数の分散サーバは、前記経時的に変化するデータを逐次蓄積することを特徴とする請求項１に記載のセンサネットワークシステム。
7. 複数のセンサノードから送信されるデータを格納する分散サーバと、第１のネットワークを介して複数の前記分散サーバとユーザ端末に接続される管理サーバと、を備えて前記複数のセンサノードから送信されるデータを、ユーザ端末から検索する方法であって、
   前記複数のセンサノードから送信されるデータを分散サーバの記憶部に蓄積する第１の手順と、
   前記管理サーバが、予め設定された複数のモデル名と、前記モデル名に対応するデータの格納先が何れの前記分散サーバであるかを特定する情報格納先とを、を格納したモデルリストを設定する第２の手順と、
   前記管理サーバが、前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストを設定する第３の手順と、
   前記管理サーバが、前記モデル名を構成する要素のうち、複数のモデル名で共通する要素を含み、かつ異なる種類のデータについて前記モデルリストの情報格納先と関連付けを行った定義を格納するモデルバインドリストを設定する第４の手順と、
   前記管理サーバが、前記ユーザ端末から検索要求を受け付けて、前記検索要求に含まれるモデル名の要素を前記モデルバインドリストから検索し、前記検索要求に含まれるモデル名の要素が一致する前記定義を抽出して前記ユーザ端末に前記モデル名の要素と前記情報格納先を応答する第５の手順と、
   前記ユーザ端末は、前記管理サーバから受信した前記定義のうち、ユーザが選択したモデル名の要素とデータの種類に対応する情報格納先を取得して、当該情報格納先の分散サーバに前記モデル名に対応するデータを要求する第６の手順と、
   前記分散サーバが、前記ユーザ端末から前記データの要求を受け付けると、前記データを記憶部から取得して前記管理サーバに送信する第７の手順と、
   前管理サーバが、前記分散サーバから受信したデータを、前記モデル名に対応する前記変換定義を前記意味解釈リストから取得して、当該変換定義に基づいて前記取得したデータを有意な情報に変換する第８の手順と、
   前記管理サーバが、前記分散サーバに代わって前記ユーザ端末に前記有意な情報を応答する第９の手順と、
   を含むことを特徴とするセンサデータの検索方法。
8. 前記第１の手順は、
   前記分散サーバが、前記センサノードから受信したデータにＩＤを付与して、当該データＩＤとデータを関連づけて前記記憶部に格納し、
   前記第２の手順は、
   前記管理サーバが、前記モデル名と、当該モデル名に対応する情報格納先と、当該モデル名に対応するデータＩＤをモデルリストに格納し、
   前記第７の手順は、
   前記分散サーバが、前記ユーザ端末からデータの要求を受け付けると、前記データとデータＩＤを前記記憶部から取得して前記管理サーバに送信し、
   前記第８の手順は、
   前記管理サーバが、前記分散サーバからデータ及びデータＩＤを受信し、前記受信したデータＩＤで前記モデルリストを検索して前記データＩＤが一致するモデル名を検索し、当該モデル名に対応する前記変換定義を前記意味解釈リストから取得し、当該取得した変換定義で前記データを有意な情報に変換して前記ユーザ端末に応答することを特徴とする請求項７に記載のセンサデータの検索方法。
9. 前記第１の手順は、
   前記管理サーバが、前記センサノードのうち、前記記憶部にデータを蓄積する前記分散サーバを設定するセンサ情報テーブルを有し、当該センサ情報テーブルでセンサノードのデータの格納先に設定された分散サーバに対してセンサノードのデータを蓄積するよう指令する手順と、
   前記分散サーバが、前記指令を受け付けて、前記センサ情報テーブルに設定されたセンサノードのみからデータを蓄積する手順と、
   を含むことを特徴とする請求項７に記載のセンサデータの検索方法。
10. 前記複数のセンサノードから送信されるデータは経時的に変化し、
    前記複数の分散サーバは、前記経時的に変化するデータを逐次蓄積することを特徴とする請求項７に記載のセンサデータの検索方法。
11. ユーザ端末から受け付けたデータの参照要求に基づいて、複数のセンサノードから送信されるデータを記憶部に蓄積する分散サーバからデータを取得するプログラムであって、
    前記複数のセンサノードから送信されるデータの所在を、予め設定された複数のモデル名と、前記モデル名に対応するデータの格納先が何れの前記分散サーバであるかを特定する情報格納先とを、を格納したモデルリストを設定する第１のステップと、
    前記センサノードのデータを、前記ユーザ端末を利用するユーザが理解可能な情報に変換する変換定義を前記モデル名に対応して設定した意味解釈リストを設定する第２のステップと、
    前記モデル名を構成する要素のうち、複数のモデル名で共通する要素を含み、かつ異なる種類のデータについて前記モデルリストの情報格納先と関連付けを行った定義を格納するモデルバインドリストを設定する第３のステップと、
    前記ユーザ端末から検索要求を受け付けて、前記検索要求に含まれるモデル名の要素を前記モデルバインドリストから検索し、前記検索要求に含まれるモデル名の要素が一致する前記定義を抽出して前記ユーザ端末に前記モデル名の要素と前記情報格納先を応答する第４のステップと、
    前記ユーザ端末が、前記受信した前記定義のうち、ユーザが選択したモデル名の要素とデータの種類に対応する情報格納先により特定される分散サーバに前記モデル名に対応するデータを要求し、前記分散サーバが、前記要求を受け付けて前記データを記憶部から取得し、当該データを受信する第５のステップと、
    前記受信したデータを、前記モデル名に対応する前記変換定義を前記意味解釈リストから取得して、当該変換定義に基づいて前記取得したデータを有意な情報に変換する第６のステップと、
    前記分散サーバに代わって前記ユーザ端末に前記有意な情報を応答する第７のステップと、
    を管理サーバに実行させることを特徴とするプログラム。
12. 前記第１のステップは、
    前記分散サーバにはデータにデータＩＤが付与されて前記記憶部に格納され、前記モデル名と、当該モデル名に対応する情報格納先と、当該モデル名に対応するデータＩＤをモデルリストに格納し、
    前記第５のステップは、
    前記分散サーバから、前記データとデータＩＤを受信し、
    前記第６のステップは、
    前記受信したデータＩＤで前記モデルリストを検索して前記データＩＤが一致するモデル名を検索し、当該モデル名に対応する前記変換定義を前記意味解釈リストから取得し、当該取得した変換定義で前記データを有意な情報に変換することを特徴とする請求項１１に記載のプログラム。

Images