以下、本発明の一実施形態を添付図面に基づいて説明する。
図1は、本発明の第1実施形態を示すセンサネットワークシステムの構成図である。
<システム構成の概要>
センサノードWSN(無線センサノード)、MSN(無線モバイルセンサノード)は、所定の位置に設置され、あるいは所定の物あるいは人に取り付けられ、環境に関する情報や取り付けられた物に関する情報を収集し、その情報を基地局BST−1〜nに送る送信するノードである。センサノードは無線により基地局BST−1〜nに接続される無線センサノードWSN、MSNと、有線によりネットワークNWK−nに接続される有線センサノードFSNとから構成されている。
固定的に設置される無線センサノードWSNは、例えば、搭載されたセンサが周期的に周囲の状況をセンシングして、予め設定された基地局BSTへセンシング情報を送信する。無線モバイルセンサノードMSNは、ヒトが持ち歩く、クルマに搭載されるなど、移動可能であることを前提とし、至近の基地局BSTに情報を送信する。なお、無線センサノードの全体(総称)を指すときにはWSNまたはMSNとし、個々の無線センサノードを指すときには、WSN−1〜nあるいはMSN−1〜nのように添え字を付して表す。他の構成要素についても以下同様に、総称を示すときには添え字無しで表し、個々を示すときには添え字「−1〜n」を付すものとする。
各基地局BST−1〜nには、1つまたは複数の無線センサノードWSN、MSNが接続され、各基地局BST−1〜nは、ネットワークNWK−2〜nを介して各センサノードからのデータを収集する分散データ処理サーバDDS−1〜nに接続される。なお、ネットワークNWK−2〜nは、基地局BSTと分散データ処理サーバ(分散サーバ)DDSとを接続するためのものである。分散データ処理サーバDDSは、システム規模の大きさによって、その接続数を可変とすることができる。
各分散データ処理サーバDDS−1〜nは、無線及び有線センサノード(以下、単にセンサノードという)が検出したデータ等を格納するディスク装置DSKと、図示しないCPU及びメモリを備えて所定のプログラムを実行し、後述するようにセンサノードからの測定データを収集し、予め規定した条件に従って、データの格納、データの加工、さらには、ネットワークNWK−1を介して、ディレクトリサーバ(管理サーバ)DRSもしくは他のサーバへの通知やデータ転送などのアクションを行う。なお、ネットワークNWK−1は、LANやインターネット等で構成される。
ここで、センサノードから収集したデータは、主には、センサノードを識別する固有のIDおよびセンシングされた数値データであり、時系列に応じた変化を示すが、そのままではセンサノードの出力を利用するユーザ(ユーザ端末UST等の利用者)が容易に理解する形式にはなっていない。そこで、ディレクトリサーバDRSでは、予め設定された定義に基づいて、センサノードの出力データをユーザが理解可能な実世界モデル(ヒト、モノ、状態、など)に変換してからユーザに提示する。
なお、分散データ処理サーバDDS−1〜nがデータを収集する対象は、自身が接続されたネットワークNWK−2〜nの基地局BSTに所属するセンサノードや、他の基地局BSTから移動してきた無線センサノードMSNからのデータについてデータを収集し、上記変換を行うものである。また、有線のセンサノードFSNは、分散データ処理サーバDDS−1〜nに接続するようにしても良い。もちろん、有線のセンサノードFSNを基地局BSTに接続し、基地局BSTが有線のセンサノードFSNを無線センサノードと同等に管理することもできる。
ネットワークNWK−1には、分散データ処理サーバDDSから送られたセンシング情報に関連づけられた実世界モデルを管理するディレクトリサーバDRSと、このディレクトリサーバDRSの情報を利用するユーザ端末USTと、ディレクトリサーバDRSや分散データ処理サーバDDS及び基地局BST、センサノードの設定及び管理を行う管理端末ADTが接続される。なお、管理端末は、センサノードを管理するセンサ管理者と、センサネットワークのサービスを管理するサービス管理者用にそれぞれ用意しても良い。
ディレクトリサーバDRSは、図示しないCPU、メモリ及びストレージ装置を備えて所定のプログラムを実行し、後述するように、有意な情報に関連づけられたオブジェクトを管理する。
すなわち、ユーザは、ユーザ端末USTを通じて実世界モデルに対してアクセスを要求すると、ディレクトリサーバDRSは実世界モデルに該当する測定データを所有する分散データ処理サーバDDS−1〜nにアクセスし、該当する測定データを取得し、そのセンシングデータを、必要あればユーザにわかりやすい形に変換してユーザ端末USTに表示する。
図2は、図1に示したセンサネットワークの機能ブロック図である。ここでは、説明を簡易にするため、図1の分散データ処理サーバDDS−1〜nのうち分散データ処理サーバDDS−1の構成のみを示し、また、分散データ処理サーバDDS−1に接続された基地局BST−1〜nのうち基地局BST−1の構成のみを示す。他の分散データ処理サーバDDSや基地局BSTも同様に構成される。
以下、各部の詳細について説明する。
<基地局BST>
無線センサノードWSN、MSNや有線センサノードFSN(以下、センサノードという)からデータを収集する基地局BST−1は、コマンド制御部CMC−Bと、センサノード管理部SNMと、イベント監視部EVMとを備える。なお、センサノードは、予め設定されたIDを付して測定データを送信する。
コマンド制御部CMC−Bでは、後述する分散データ処理サーバDDS−1のコマンド制御部CMC−Dとの間でコマンドの送受を行う。例えば、分散データ処理サーバDDS−1からのコマンドに応じて、基地局BST−1のパラメータの設定を実行したり、基地局BST−1の状態を分散データ処理サーバDDS−1へ送信する。あるいは、基地局BST−1が管理するセンサノードのパラメータの設定を実行したり、センサノードの状態を分散データ処理サーバDDS−1へ送信する。
センサノード管理部SNMは、自身が管理するセンサノードの管理情報(稼動状態、残電力など)を保持する。そして、分散データ処理サーバDDS−1からセンサノードに関する問い合わせがあった場合には、各センサノードに代わって、管理情報を通知する。センサノードは管理に関連する処理を基地局BSTに委ねることで、自身の処理負荷を低減することができ、余計な電力消費を抑制することが可能となる。
また、センサノード管理部SNMは、イベント監視部EVMが異常を検出した場合には、センサノードの管理情報を更新し、分散データ処理サーバDDS−1へ異常のあったセンサノードを通知する。なお、センサノードの異常とは、センサノードからの応答がない場合や、センサノードの電力が予め設定したしきい値以下になった場合など、センサノードの機能が停止または停止に至る状態を示す。
また、センサノード管理部SNMは、コマンド制御部CMC−Dからセンサノードに対するコマンド(出力タイミングの設定)を受けた場合には、このコマンドをセンサノードに送信して設定を行い、設定の完了を示す通知をセンサノードから受信した後に、センサノードの管理情報を更新する。なお、センサノードの出力タイミングは、例えば、無線センサノードWSNが基地局BST−1にデータを周期的に送信する際の期を示す。
基地局BSTは、予め設定された配下の無線センサノードWSN、MSN及び有線センサノードFSNについて管理を行い、各センサノードが測定したデータを分散データ処理サーバDDSに送信する。
<分散データ処理サーバDDS>
分散データ処理サーバDDS−1は、データベースDBを格納するディスク装置DSKと、後述のようなコマンド制御部CMC−D、イベントアクション制御部EAC、データベース制御部DBCを備える。
コマンド制御部CMC−Dは、基地局BST及び後述するディレクトリサーバDRSと通信を行って、コマンド等の送受信を行う。
イベントアクション制御部EACは、センサノードからの測定データを基地局BSTから受信するたびに、測定データに対応するID、すなわちデータIDを取得し、後述するテーブル(図10のイベントテーブルETB)からデータIDに対応するイベントの発生ルールを読み込んで、測定データの値に応じたイベントの発生の有無を判定する。さらに、イベントアクション制御部EACでは、データIDに該当するイベントの発生に対応するアクションを実行する。なお、センサノードにセンサが1つだけ備えられている場合は、センサノードを識別するためのセンサノードのIDをデータIDとしてもよい。
そして、アクション実施の内容としては、ユーザなどにより予め設定されたデータID毎のルールに基づいて、測定データを加工データに変換したり、測定データと加工データをデータベース制御部DBCを通じてデータベースDBへ格納したり、また、ディレクトリサーバDRSに通知を行うなどの処理を含む。
本実施形態では、図1で示すように、複数の基地局BSTに対して、これらのいくつかを地域的(または、場所的)に集約する複数の分散データ処理サーバDDSを配置することで、多数のセンサノードからの情報を分散して処理することが可能になる。例えば、オフィスなどではフロア毎に分散データ処理サーバDDSを設け、工場などでは建屋毎に分散データ処理サーバDDSを設ければよい。
分散データ処理サーバDDS−1のディスク装置DSKは、基地局BSTから受信したセンサノードWSN、MSN、FSNの測定データと、これらの測定データを加工した加工データと、基地局BSTや無線センサノードWSN、MSN及び有線センサノードFSNに関する装置データを、データベースDBとして格納する。
そして、データ処理サーバDDS−1のデータベース制御部DBCは、イベントアクション制御部EACから送られたセンサノードの出力である測定データをデータベースDBに格納する。また、必要あれば測定データを数値処理したり、他データと融合することにより得られる加工データをデータベースDBに格納する。なお、装置データについては、管理者端末ADTなどからの要求に応じて随時更新される。
<ディレクトリサーバDRS>
複数の分散データ処理サーバDDSを管理するディレクトリサーバDRSは、ネットワークNWK−1を介して接続されたユーザ端末USTや管理者端末ADTからの通信を制御するセッション制御部SESと、後述するように、モデル管理部MMG、モデルテーブルMTB、装置管理部NMG、アクション制御部ACC及び検索エンジンSERから構成される。
モデル管理部MMGは、ユーザが理解し易い実世界のモデル(オブジェクト)と分散データ処理サーバDDSがセンサノードから収集した測定データ、もしくは加工データとの対応関係を実世界モデルテーブルMTBに設定した実世界モデルリストMDLによって管理する。
ディレクトリサーバDRSは、実世界モデルに相当する測定データもしくは加工データの存在場所の位置情報(URLなどのリンク)も管理している。つまり、ユーザは、実世界モデルを指定することで、時々刻々と変化するセンサノードの測定情報にダイレクトにアクセス可能となる。センサノードからの測定データ及び加工データは、時間の経過につれて増大するのに対し、実世界モデル情報は時間が経過してもサイズが変化することはなく、その内容のみが変化する。この実世界モデルの詳細については後述する。
なお、実世界モデルテーブルMTBは、ディレクトリサーバDRSの所定のストレージ装置(図示省略)などに格納される。
ディレクトリサーバDRSのアクション制御部ACCは、分散データ処理サーバDDSのイベントアクション制御部EACやコマンド制御部CMC−Dと通信を行って、ユーザ端末USTや管理者端末ADTからのイベントアクションの設定要求を受け付ける。そして、受け付けたイベントまたはアクションの内容を解析し、解析結果に応じたディレクトリサーバDRSと分散データ処理サーバDDS−1〜n間の機能分担を設定する。なお、一つのアクションやイベントは、一つの分散データ処理サーバDDSだけではなく、複数の分散データ処理サーバDDS−1〜nに関与する場合もある。
検索エンジンSERは、セッション制御部SESが受け付けたオブジェクトに対する検索要求に基づいて、実世界モデルテーブルMTBを参照し、分散データ処理サーバDDSのデータベースDBに対して検索を実行する。
なお、検索要求がクエリーであれば、クエリーの内容に従ったデータベースDBの対応付けと、クエリのSQL(Structured Query Language)変換を実行し、検索を実行する。なお、検索対象となるデータベースDBは、複数の分散データ処理サーバDDSにまたがる場合がある。
そして、このクエリーとしては、「最新データ取得(スナップショット/ストリーム)」に対応する。なお、「最新データ取得(ストリーム)」はアクション制御部ACCのアクションの設定にて対応する。つまり、該当のデータを常にユーザ端末に転送するようなアクションの設定を、該当する分散データ処理サーバDDSのイベントアクション制御部EACに設定しておけばよい。
次に、装置管理部NMGは、ネットワークNWK−1に接続されてセンサネットワークを構成する分散データ処理サーバDDSと、分散データ処理サーバDDSに接続された基地局BST、基地局BSTに接続されたセンサノードを統合的に管理するものである。
装置管理部NMGでは、分散データ処理サーバDDS、基地局BST、センサノードの登録や検索に関するインターフェースを管理者端末ADT等に提供し、それぞれの装置の状態や、センサノードの状態を管理する。
装置管理部NMGは、分散データ処理サーバDDSや基地局BST、センサノードに対してコマンドを発行することができ、このコマンドによりセンサネットワークのリソースを管理する。なお、センサノードは上位となる基地局BSTのコマンド制御部CMC−Bを介して装置管理部NMGからコマンドを受け、基地局BSTは上位の分散データ処理サーバDDSのコマンド制御部CMC−Dを介して装置管理部NMGからコマンドを受ける。
なお、コマンド制御部CMC−Dを介して装置管理部NMGが発行するコマンドとしては、例えば、リセット、パラメータ設定、データ消去、データ転送、定型イベント/アクション設定等がある。
<センサノードの一例>
次に、センサノードの一例を図3〜図5に示す。
図3は、無線センサノードWSNの一例を示すブロック図である。無線センサノードWSNは、測定対象の状態量(温度、圧力、位置等)または状態量の変化(低温/高温、低圧/高圧など)を測定するセンサSSRと、センサSSRを制御するコントローラCNTと、基地局BSTと通信を行う無線処理部WPRと、各ブロックSSR、CNT、WPRに電力を供給する電源POW、送受信を行うアンテナANTから構成される。
コントローラCNTは、予め設定された周期、もしくは不定期にセンサSSRの測定データを読み込み、この測定データに予め設定したセンサノードのIDを加えて無線処理部WPRに転送する。測定データにはセンシングを行った時間情報をタイムスタンプとして与える場合もある。無線処理部WPRは、コントローラCNTから送られたデータを基地局BSTに送信する。
また、無線処理部WPRは基地局BSTから受信したコマンドなどをコントローラCNTに送信し、コントローラCNTは受信したコマンドを解析して、所定の処理(例えば、設定変更など)を行う。また、コントローラCNTは、電源POWの残電力(または充電量)の情報を、無線処理部WPRを介して基地局BSTに対して送信する。なお、コントローラCNT自身が電源POWの残電力(または充電量)を監視し、残電力が予め設定されたしきい値を下回った場合に、基地局BSTに対して電力がなくなる警報を送信するようにしておいても良い。
無線処理部WPRでは、限りのある電力で長時間測定を行うため、図4で示すように、間欠的に動作して、電力消費を低減している。図中、スリープ状態SLPではコントローラCNTはセンサSSRの駆動を停止し、所定のタイミングでスリープ状態から動作状態に切り替わって、センサSSRを駆動して測定データを送信する。
なお、図3においては、一つの無線センサノードWSNに一つのセンサSSRを備えた例を示したが、複数のセンサSSRを配置しても良い。あるいは、センサSSRに代わって、固有の識別子IDを格納したメモリを設けても良く、無線センサノードWSNをタグとして使用しても良い。
また、図3、図4においては、電源POWは、電池を使用する場合や、太陽電池や振動発電などの自律発電機構を具備する構成としても良い。また、無線モバイルセンサノードMSNも図3、図4と同様に構成すればよい。
図5は、上記図1、図2に示した分散データ処理サーバDDS−1に接続されたセンサノードの一例を示す詳細図である。
本実施形態では、オフィスおよびA会議室、Bにセンサノードを設けた例を示している。
オフィスには基地局BST−0が設置され、オフィスの椅子にはセンサSSRとして感圧(圧力)スイッチを備えた無線センサノードWSN−0が配置される。無線センサノードWSN−0は、基地局BST−0と通信するように設定される。
A会議室には基地局BST−1が設置され、A会議室の椅子にはセンサSSRとして感圧スイッチを備えた無線センサノードWSN−3〜10が配置される。また、A会議室には温度センサを備えた有線センサノードFSN−1が設置され、基地局BST−1に接続されている。各無線センサノードWSN−3〜10及び有線センサノードFSN−1は、基地局BST−1と通信するように設定される。
同様に、会議室Bには基地局BST−2が設置され、会議室Bの椅子にはセンサSSRとして感圧スイッチを備えた無線センサノードWSN−11〜17と、温度センサを備えた有線センサノードFSN−2が設置され、基地局BST−2に接続されている。
これらオフィス、A会議室、B会議室を利用する従業者には名札を兼ねた無線センサノードMSN−1が装着される。無線センサノードMSN−1は、従業者の体温(または周囲の温度)を測定する温度センサSSR−1と、従業者に固有の識別子(従業者ID)を格納したタグTG−1を備える名札として構成される。無線センサノードMSN−1は基地局BST−0、1または2に、従業者IDと測定データとしての温度を送信することができる。
<センサネットワークの動作概念>
次に、上記図1〜図5に示したセンサネットワークの動作の概要について、図6〜図8を用いて説明する。
図6は、実世界モデルの具体的な形であるオブジェクトとセンサノードの測定データの関連を示すブロック図で、測定の開始時を示し、図7は、図6の状態から所定時間が経過した状態を示す。
図6において、ディレクトリサーバDRSは、実世界モデルとして予め次のようなオブジェクトを生成し、実世界モデルテーブルMTBの実世界モデルリストMDLに定義しておく。ここでは、図5のオフィスまたはA会議室、B会議室を利用する従業者として鈴木さんの場合を示し、図6に示した無線センサノードMSN−1を、この人物が装着しているものとする。
図12のセンサ情報テーブルSTBに示されるように、各センサノードMSNの測定データ(ex.温度)や位置情報がデータ格納先として指定される分散データ処理サーバDDSに格納されるようセンサ情報テーブルは定義されている。ここで、センサノードMSNの位置情報は、センサノードMSNを検出する基地局BSTのID情報として得ることができる。
そして、実世界モデルテーブルMTBの実世界モデルリストMDLには、鈴木さんの位置というオブジェクト(OBJ−1)は、測定データ1(LINK−1)という格納先にデータの実体があることが定義され、実世界モデルと実際のデータの位置の対応関係が管理されている。
つまり、実世界モデルリストMDLにおいて、鈴木さん位置(OBJ−1)というオブジェクトは、測定データ1(LINK−1)に対応する分散データ処理サーバDDSの格納位置に関連付けられている。図6、図7においては、鈴木さんの位置を示す無線センサノードMSN−1からの位置情報(例えば「どこの基地局BSTに接続される」として定義される)は、分散データ処理サーバDDSのディスク装置DSK1に格納される。
ユーザ端末USTから見ると、鈴木さん位置(OBJ−1)の値はディレクトリサーバDRSの実世界モデルテーブルMTBに存在するように見えるが、実際のデータはディレクトリサーバDRSではなく、予め設定された分散データ処理サーバDDSのディスク装置DSK1に格納されるのである。
鈴木さん着座(OBJ−2)というオブジェクトは、オフィスの椅子に装着された感圧スイッチ(WSN−0)から求めた着座情報が測定データ2(LINK−2)に格納されるよう、実世界モデルテーブルMTBに定義される。さらに、測定データ2に対応する分散データ処理サーバDDSと格納位置が定義される。図6、図7においては、MSN−1及び無線センサノードWSNからの着座情報は分散データ処理サーバDDSのディスク装置DSK2に格納する。
鈴木さん温度(OBJ−3)というオブジェクトは、無線センサノードMSN−1の温度センサSSR−1が測定した温度が測定データ3(LINK−3)に格納されるよう、実世界モデルテーブルMTBに定義される。さらに、測定データ3に対応する分散データ処理サーバDDSと格納位置が定義される。図6、図7においては、MSN−1からの温度は分散データ処理サーバDDSのディスク装置DSK3に格納する。
A会議室メンバ(OBJ−4)というオブジェクトは、A会議室の基地局BST−1が接続した無線センサノードMSNの情報から求めた従業者の名前が測定データ4(LINK−4)に格納されるよう、実世界モデルテーブルMTBに定義される。感圧スイッチ(WSN−3〜10)を使用しない場合には、ある単位時間内にA会議室内の基地局BST−1で検出された無線センサノードMSN数によりA会議室の人数を求めても良い。さらに、測定データ4に対応する分散データ処理サーバDDSと格納位置が定義される。図6、図7においては、各従業者の無線センサノードMSNからの個人情報は分散データ処理サーバDDSのディスク装置DSK4に格納する。
A会議室人数(OBJ−5)というオブジェクトは、A会議室の感圧スイッチ(WSN−3〜10)から求めた人数が測定データ5(LINK−5)に格納されるよう、実世界モデルテーブルMTBに定義される。さらに、測定データ5に対応する分散データ処理サーバDDSと格納位置が定義される。図6、図7においては、無線センサノードWSN3〜10の着座情報は分散データ処理サーバDDSのディスク装置DSK5に格納する。
A会議室温度(OBJ−6)というオブジェクトは、A会議室の有線センサノードFSN−1が測定した温度が測定データ6(LINK−6)に格納されるよう、実世界モデルテーブルMTBに定義される。さらに、測定データ6に対応する分散データ処理サーバDDSと格納位置が定義される。図6、図7においては、FSN−1からの温度は分散データ処理サーバDDSのディスク装置DSK6に格納する。
すなわち、実世界モデルテーブルMTBに定義された各オブジェクトOBJは、測定データに対応する格納先(LINK)を格納しており、ユーザ端末USTからは目的のデータがディレクトリサーバDRSに存在するように見えるが、実際のデータは分散データ処理サーバDDSに格納される。
そして、情報の格納先LINKには、センサノードが測定した測定データまたは測定データをユーザに理解可能な形に変換した加工データなど、ユーザが利用可能なデータの格納位置が設定されている。センサノードからの測定データの収集は各分散データ処理サーバDDSで行われ、さらに、後述するようにイベントアクションが設定されていれば、測定データに対して加工などが加えられ、加工データとして所定の分散データ処理サーバDDSに格納されていく。
実際のセンサノードからのデータ収集と加工は分散データ処理サーバDDSで行われ、ディレクトリサーバDRSでは、実世界モデルと情報の格納先及びセンサノードの定義などが管理される。
これにより、ユーザ端末USTの利用者はセンサノードの所在を知る必要がなく、オブジェクトOBJを検索することで、センサノードの測定値(または加工データ)に対応する所望のデータを得ることができるのである。
そして、ディレクトリサーバDRSは、オブジェクトOBJ毎の格納先(リンク先)を管理し、実際のデータは分散データ処理サーバDDSが格納し、処理するので、センサノードの数が膨大になったとしても、データ処理サーバDDSの負荷が過大になるのを防ぐことができるのである。つまり、多数のセンサノードを使用しながら、ディレクトリサーバDRSと分散データ処理サーバDDS及びユーザ端末USTを接続するネットワークNWK−1のトラフィックが過大になるのを抑制できるのである。
図6の状態から所定時間経過した図7では、分散データ処理サーバDDSのディスク装置DSK1〜6にセンサノードからの実際の測定データが書き込まれ、時間の経過とともにデータ量は増大する。
一方、ディレクトリサーバDRSの実世界モデルテーブルMTBのモデルリストMDLに設定されたオブジェクトOBJ−1〜6に対応する格納先LINK−1〜6は、時間が経過しても情報量は変化することなく、格納先LINK−1〜6が指し示す情報の内容が変化する。
つまり、ディレクトリサーバDRSが管理するオブジェクトOBJ−1〜6の情報量と、分散データ処理サーバDDSが管理する測定データ1〜6のデータ量と時間の関係は、図8のように、オブジェクトのデータ量が一定であるのに対し、測定データは時間の経過につれて増加する。
例えば、ひとつの基地局BSTに数百のセンサノードが接続され、ひとつの分散データ処理サーバDDSに数個の基地局BSTが接続され、ひとつのディレクトリサーバDRSに数十の分散データ処理サーバDDSが接続される場合、センサノードの総数は数千乃至数万となる。仮に、各センサノードが1分毎に順次データを送るとすれば、毎秒百乃至千程度の測定データが分散データ処理サーバDDSに送られて、イベントの有無が判定され、イベントが発生した場合には所定のアクションにより通知やデータの加工などの処理が生じることになる。これらの処理を一つあるいは、少数のサーバで実現しようとすれば、サーバ自体の負荷やサーバと接続するためのネットワークの負荷が極めて大きくなる。さらに、収集したデータや加工したデータについて、ユーザ端末USTからアクセスが発生するため、ユーザ端末USTへデータを提供するためにもサーバの負荷やネットワークの負荷はさらに大きくなる。
そこで、ユーザ端末USTからアクセスを受け付け、センサノードの情報の格納先を管理するディレクトリサーバDRSと、複数の基地局BSTを管理して、基地局BSTに割り当てられたセンサノードからデータを収集し、加工する分散データ処理サーバDDSに分ける。
センサノードからの情報は、複数の分散データ処理サーバDDSで分散して収集し、各分散データ処理サーバDDSでそれぞれデータの格納あるいは加工を行うことで、多数のセンサノードのデータ収集及び加工処理を分散し、特定のサーバに負荷が集中するのを防ぐことができる。
一方、ディレクトリサーバDRSは、センサノードの測定データから得られた情報の格納先を集中的(一元的)に管理し、ユーザ端末USTにオブジェクトと格納先LINKの対応関係を提供する。ユーザは、センサノードの物理的な位置等を知らなくとも、ディレクトリサーバDRSに目的のオブジェクトについて問い合わせを行えば、データの格納位置から有意な情報を得ることができる。つまり、情報の格納先をディレクトリサーバDRSで集中管理することにより、センサノードの所在に係わらず、ユーザ端末USTはディレクトリサーバDRSにアクセスすれば、目的のセンサノードに関する測定データまたは加工データを得ることができるのである。
そして、ディレクトリサーバDRSは、分散データ処理サーバDDSから得られたデータを属性別意味解釈リストATLに基づいて、ユーザが理解可能な情報に変換してユーザ端末USTに提供するので、
また、ディレクトリサーバDRSに格納するオブジェクトは、構築するシステム構成に応じて設定・変更されるものであり、センサノードが検出する測定データのように経時的に変化するものではないので、オブジェクトを集中的に管理する部分は経時的な測定データの負荷変動の影響を受けない。したがって、分散データ処理サーバDDSとの間で直接的にセンサノードのデータをやり取りすることが抑制されるので、ディレクトリサーバDRSに接続されたネットワークNWK−1の負荷が過大になるのを抑制できる。
なお、図6、図7では、別々の分散データ処理サーバDDSに対して、それぞれにディスク装置DSKが接続された場合を示したが、図5のように、1つの分散データ処理サーバDDSを設け、これに複数のディスク装置DSKを設けてもよく、複数の分散データ処理サーバDDSにグループ分けしてディスク装置DSKを接続することも可能である。
<測定データとイベントの関係>
次に、分散データ処理サーバDDSで収集される測定データと、測定データに基づくイベントアクションの関係を図9、図10に示す。
図9において、分散データ処理サーバDDSのイベントアクション制御部EACは、基地局BSTから収集される測定データをイベントに対応付けるイベントテーブルETBを備える。
イベントテーブルETBは、図10で示すように、センサノード毎に割り当てられて測定データに付与されるデータID(図12及び図14のデータIDに対応)と、測定データに関してイベントの発生判断条件であるEVTと、測定データをデータベースDBに格納するか否かを決定するデータ格納DHLとから1レコードが構成されている。
例えば、図中、データIDが「XXX」の測定データは、その値がA1より大のときにイベントの発生をディレクトリサーバDRSに通知する。なお、データIDが「XXX」の測定データは、データ到着毎に、ディスク装置DSKに書き込まれるように設定される。
分散データ処理サーバDDSでは、基地局BSTから受信した測定データを、まず、センシングデータID抽出部IDEで受け付け、測定データに付与されているIDであるデータIDを抽出する。また、センシングデータID抽出部IDEは、測定データを最新データメモリLDMに送る。
抽出されたデータIDはイベント検索部EVSに送られて、イベントテーブルETBを検索し、データIDが一致するレコードがあれば、当該レコードのイベント内容EVTと測定データをイベント発生判定部EVMに送る。
イベント発生判定部EVMでは、測定データの値とイベント内容EVTを比較して、条件を満たせばイベントの発生を、ディレクトリサーバインターフェースDSIを通じて、ディレクトリサーバDRSに通知する。また、イベント発生判定部EVMは、データ格納DHLの要求を最新データメモリに伝える。
DB制御部DBCは、イベントテーブルETBのデータ格納DHLがYESとなっているデータについては、最新データメモリLDMからデータを受け取り、ディスク装置DSKに書き込みを行う。
分散データ処理サーバDDSは、ディレクトリサーバインターフェースDSIがディレクトリサーバDRSより測定データの参照要求を受信した場合、データアクセス受け付け部DARに当該アクセス要求を送る。
データアクセス受け付け部DARでは、アクセス要求が最新のデータであれば、アクセス要求に含まれるデータIDに対応する測定データを最新データメモリLDMから読み込んで、ディレクトリサーバインターフェースDSIへ返送する。あるいは、アクセス要求が過去のデータであれば、アクセス要求に含まれるデータIDに対応する測定データをディスク装置DSKから読み込んで、ディレクトリサーバインターフェースDSIへ返送する。
このように、分散データ処理サーバDDSでは、基地局BSTから収集したセンサノードのデータのうち、最新のデータを最新データメモリLDMに保持し、さらに、後で参照が必要と予想されるデータについてのみディスク装置DSKに記録する。また、イベントが発生時のデータのみ、データをディスク装置DSKに記録する設定も可能である。この場合には、周期的(観測間隔)に収集するデータによるディスク使用量増加を防ぐことができる。以上の方法により、ひとつの分散データ処理サーバDDSで複数の基地局BST(つまり、多数のセンサノード)を管理することが可能となる。
<装置管理部NMG及びモデル管理部MMGの詳細>
<装置管理部NMG>
図11は、図2に示したディレクトリサーバDRSの、装置管理部NMGとモデル管理部MMG及び実世界モデルテーブルMTBの詳細を示す。
まず、ディレクトリサーバDRSの装置管理部NMGは、センサノードを管理するセンサ情報テーブルSTBと、センサ情報テーブルSTBにセンサノードを登録/変更するための登録インターフェースと、センサ情報テーブルSTBの内容を検索する検索インターフェースを備える。なお、ここでは、センサ情報テーブルSTBは、センサ管理者端末ADT−Aにより管理されるものとする。
センサ情報テーブルSTBは、図12で示すように、センサノード毎に予め割り当てたデータIDと、センサノードの種類を示すセンサ種別と、センサノードの測定対象を示す意味と、センサノードが測定する計測値の内容と、センサノードを設置した位置(または対象)を示す設置場所と、センサノードが測定対象から測定値を検出する周期を示す観測間隔と、測定したデータの格納先(分散データ処理サーバDDS−1〜n上の格納位置)を示すデータ格納先が、1レコードで構成され、センサノードを識別するIDをインデックスとして管理される。
例えば、図5に示した名札として構成された無線センサノードMSN−1のタグTG−1は、データIDが01に割り当てられ、測定対象が無線センサノードMSN−1の場所(位置)であり、測定の周期が30秒おきであり、測定データは分散データ処理サーバDDS−1に格納されることを示している。同様に、名札として構成された無線センサノードMSN−1に配置されたセンサSSR−1は、データIDが02に割り当てられ、測定対象が周囲の温度であり、測定の周期が60秒おきであり、測定データは分散データ処理サーバDDS−2に格納されることを示している。
このセンサ情報テーブルSTBは、上記センサ管理者端末ADT−Aから設定されたものであり、センサ管理者やサービス管理者はセンサ情報テーブルSTBを参照することにより、センサノードの機能と位置及び測定データの格納先を知ることができる。
また、センサノードがデータを測定する周期が一定でない場合には、図12のセンサノードID=03の着座センサのように、観測間隔を「イベント」とすることにより、周期に関わらず、センサが特定の状態を検出したときのみ、この状態を分散データ処理サーバDDSに通知する。
<モデル管理部MMG>
次に、図11に示すモデル管理部MMG及び実世界モデルテーブルMTBについて説明する。
モデル管理部MMGが管理する実世界モデルテーブルMTBは、センサノードの測定データがどのような意味を持つのかを解釈するための属性別意味解釈リストATLと、図6に示したオブジェクトOBJ−1〜nのモデル名と実際の情報の格納位置との対応関係を示す実世界モデルリストMDLと、オブジェクトOBJ−1〜n間の相関関係を示すモデルバインドリストMBLとから構成される。
そして、モデル管理部MMGは、これら実世界モデルテーブルMTBの各リストを管理するため、属性別意味解釈リストATLを管理する属性別意味解釈リスト管理部ATMと、実世界モデルリストMDLを管理する実世界モデルリスト管理部MDMと、モデルバインドリストMBLを管理するモデルバインドリスト管理部MBMを備え、各管理部は、リストの登録/変更を行うための登録インターフェースと、各リストの検索を行うための検索インターフェースをそれぞれ備えている。
なお、ここでは、実世界モデルテーブルMTBは、サービス管理者端末ADT−Bを利用するサービス管理者により管理されるものとする。なお、図11において、センサ管理者端末とサービス管理者端末は、図1に示したように一つの管理端末ADTを用いても良い。
また、センサネットワークを利用するユーザ端末USTは、各リストの検索インターフェースを介して所望のリストからオブジェクトOBJの検索を行う。
まず、属性別意味解釈リスト管理部ATMが管理する属性別意味解釈リストATLは、センサノードWSN、MSN、FSNからの戻り値(測定値)や分散データ処理サーバDDSで変換した加工データは、そのままの値ではユーザ端末USTの利用者(以下、単にユーザとする)が理解することができないため、図13に示すように、センサノードの出力値を有意な情報に変換するためのテーブルを備える。図13は、オブジェクトOBJ−1〜nに対応して予め設定されたものである。
図13において、名前テーブルATL−mは、図6に示した鈴木さん位置OBJ−1に対応付けられたもので、図12で示したように、センサ種別が名札であるセンサノードMSN−1に設定されたタグTGに設定された識別子からの戻り値(測定値)に応じた人名が意味の欄に対応付けられている。
図13において、場所テーブルATL−pは、名札を装着した従業者の位置を示すテーブルで、戻り値(例えばセンサノードが接続される基地局のID)に対応した場所の名称が意味の欄に対応付けられている。例えば、戻り値が01の場合は、場所がオフィスであることを意味している。
また、図13の着座テーブルATL−sは、図5に示したオフィス内もしくは、A会議室の椅子の着席状態を示し、各椅子(各無線センサノードWSN−3〜10)毎に設けられ、無線センサノードWSN−3〜10の戻り値(測定値)に応じた着席状態(在籍または不在)が格納される。例えば、戻り値が00の場合、在席(着席)状態であることを示し、戻り値が01の場合は不在であることを示す。
同様に、図13の温度テーブルATL−tは、図5に示した温度センサ(MSN−1のSSR−1、FSN−1、2)の示す値を示すテーブルであり、戻り値(温度センサの測定データ)を温度yに変換する関数f(x)が意味の欄に格納される。
図13において、人数テーブルATL−nは、A会議室にいる従業者の人数を示すテーブルで、戻り値(A会議室内椅子センサの着席数、あるいは、A会議室内のモバイルノードMSNの数)に対応した人数が意味の欄に対応付けられている。
このように、属性別意味解釈リストATLには、測定データに対する意味を定義するリストであり、生成したオブジェクトに応じてそれぞれのテーブルが設定される。
次に、実世界モデルリストMDLは、サービス管理者などが予め設定したもので、図14で示すように、オブジェクト毎に設定されたモデル名に対応する情報の位置が、情報リンク先に格納される。つまり、モデル名と情報リンク先及びデータIDが対になったものが実世界モデルリストMDLを構成する。
ディレクトリサーバDRSは、モデルリストMDLによりユーザが理解可能な有意な情報のみを管理しており、この有意な情報の所在は分散データ処理サーバDDS−1〜nの何れかとなる。このため、モデルリストMDLに定義したオブジェクトOBJは、有意な情報の実体が何処にあるかを情報リンク先に設定しておく。なお、この情報リンク先はサービス管理者などが予め設定したものである。同様に、データIDは、オブジェクトの値の元になるセンサデータ(センサノードから直接得られるデータ、もしくは、加工されて得られるデータ)に対応する値である。
図14においては、例えば、鈴木さんの位置OBJ−1に対してLINK−1という情報リンク先が格納されており、この情報リンク先にはURLやパスなどが格納され、ユーザ端末USTから、このオブジェクトを検索すると情報リンク先から有意な情報(オブジェクトの実体)を得ることができる。
例えば、ユーザ端末USTからキーワードなどをディレクトリサーバDRSの検索エンジンSERに送信すると、モデルリストMDLのモデル名の中からキーワードを含むモデル名のリストが検索エンジンSERから返信される。ユーザ端末USTを操作するユーザは、所望のモデル名を選択すると、まず、情報リンク先LINKに設定された分散データ処理サーバDDSから、ディレクトリサーバDRSは情報リンク先に対応するデータを取得する。
ディレクトリサーバDRSは、取得したデータを属性別意味解釈リストATLに基づいて、ユーザが理解可能な情報に変換してからユーザ端末USTに送信する。
したがって、ユーザは個々のセンサノードに関する知識や所在を知らなくとも、必要な情報を認識できる情報として取得できるのである。
そして、分散データ処理サーバDDSでは、センサノードから収集したデータを、収集する度にユーザに理解可能な形に変換する必要がないので、多数のセンサノードのデータを収集・管理する分散データ処理サーバDDSの負荷を大幅に低減できる。このデータの変換処理は、ユーザから要求に基づいてディレクトリサーバDRSが必要に応じて行うことにより、不要な変換処理が行われるのを抑制でき、センサネットワークのリソースを無駄なく機能させることが可能となる。
次に、オブジェクトOBJ−1〜n間の相関関係を示すモデルバインドリストMBLは、実世界モデルリストMDLのオブジェクトOBJに共通する要素について、関連する情報を集約したものである。
モデルバインドリストMBLの一例としては、図15に示すように、実世界モデルリストMDLのオブジェクトOBJのうち、共通する要素として「人名」(図中「鈴木さん」)と「A会議室」に関連するものを抽出したものである。例えば、図13の属性別意味解釈リストATLの名前テーブルATL−mの意味欄に登録された「鈴木さん」という人名に関連するオブジェクトOBJとして、位置OBJ−1、オフィス内自席の着座状態OBJ−2、温度OBJ−3があり、鈴木さんという人名に関連したオブジェクトのリンク先を、図示のように「位置」LINK−1、「着座状態」LINK−2、「温度」LINK−3とツリー状に設定し、これを人名に関するモデルバインドリストMBL−Pとする。
同様に、A会議室という要素から実世界モデルリストMDLを見ると、「メンバ」、「人数」、「温度」というオブジェクトOBJ−4〜6があり、A会議室という場所に関連したオブジェクトの情報リンク先LINK−4〜6を、図示のように「メンバ」、「人数」、「温度」とツリー状に設定し、これをA会議室に関するモデルバインドリストMBL−Rとする。
このように、モデルバインドリストMBLは、実世界モデルリストMDLのオブジェクトの要素のうち、共通する要素の異なる情報について関連付けを行った情報となる。なお、このモデルバインドリストMBLの関連付けは、サービス管理者などが予め設定したものである。
<モデル管理部MMGの動作>
次に、センサネットワークシステムの動作について、以下に説明する。
<センサノードの登録>
まず、センサノードの登録の手順について、図16、図17を参照しながら説明する。センサ管理者は、センサノードを所定の場所または人にセンサノードを設置した後、図16のタイムチャートに従ってディレクトリサーバDRSにセンサノードの登録を行う。
図16において、まず、センサ管理者はセンサ管理者端末ADT−AからディレクトリサーバDRSに接続し、装置管理部NMGの登録インターフェースを呼び出す。そして、センサ管理者端末ADT−Aから図17に示すデータフォーマットに従って、新たに追加するデータID、センサ種別、属性、計測値、設置場所、観測間隔、データ格納先を設定し、ディレクトリサーバDRSの装置管理部NMGに登録要求として送信する(RG−1)。ここで、登録に先立って、センサノードデータを受信する分散データサーバDDSに対して、データ格納先の確保と属性の指定を行っておくものとする。
ディレクトリサーバDRSの装置管理部NMGは、この登録要求を受信すると、図12に示したセンサ情報テーブルSTBに当該登録要求のあったセンサノードの情報を追加する。そして、装置管理部NMGは新たに追加したセンサノードについて識別子IDを割り当てる。このセンサノードのIDは、センサ管理者端末ADT−Aから割り当てるようにしても良い。
装置管理部NMGは、データ格納先に指定された分散データ処理サーバDDSに対して、登録要求のあったセンサノードの測定データの格納先の割り当てを行った後、センサ情報テーブルSTBの1レコードを完成させる。
そして、装置管理部NMGは、新たなレコードが追加されたことを示す完了通知(ACK)をセンサ管理者端末ADT−Aに返信し、登録処理を終了する。
なお、図示はしないが、ディレクトリサーバDRSからセンサノードの登録通知を受けた分散データ処理サーバDDSは、図17の「設置場所」に該当する基地局BSTへ該当するIDのセンサノードについて、所定の観測間隔でセンサノードからの測定値を検出するよう指令する。基地局BSTのセンサ管理部SNMには、指令のあったデータID、および、観測間隔を登録しておく。
これにより、新たなセンサノードは、所属する基地局BSTとの間で通信を行って、このセンサノードが所属する分散データ処理サーバDDSに対して測定データを送信することができる。
<オブジェクトの定義>
次に、上記図16、図17でディレクトリサーバDRSに登録したセンサノードについて、センサノードの測定データとオブジェクトとの関係を生成する処理について、図18を参照しながら説明する。なお、この処理は、センサネットワークのサービス管理者が行うものとする。
図18において、サービス管理者はサービス管理者端末ADT−BからディレクトリサーバDRSに接続し、装置管理部NMGの検索インターフェースを呼び出す。そして、所望のセンサノードの検索をIDなどに基づいて行い、検索条件に一致したセンサノードをサービス管理者端末ADT−Bに返信する。
サービス管理者端末ADT−Bでは、装置管理部NMGから受信したセンサノードの検索結果を図示しない表示装置などに出力する。
サービス管理者は、サービス管理者端末ADT−Bに表示されたセンサノードから所望のセンサノードを選択し、このセンサノードの測定データに対応付けるオブジェクトを指定して、ディレクトリサーバDRSのモデル管理部MMGに登録する。
例えば、図12に示したセンサ情報テーブルSTBのID=01の名札型センサノード(図5のMSN−1)のオブジェクトとして、「鈴木さんの位置」というオブジェクトOBJ−1を登録する。この登録によって、オブジェクトとその情報リンクの関係を示す実世界モデルリスト(MDL)が生成される(図14)。
そして、モデル管理部MMGは、「鈴木さんの位置」というオブジェクトOBJ−1について、タグのIDがTG−1(鈴木さんの識別子)のセンサノードMSNを受信した基地局BSTの位置を、例えば、分散データ処理サーバDDS−1に格納するように、分散データ処理サーバDDS−1へ所定のコマンドを指令する。
指令を受けた分散データ処理サーバDDS−1では、イベントアクション制御部EACにて、タグのIDが鈴木さんを示すTG−1のデータを受信したら、受信した基地局BSTの位置を椎別する値を、分散データ処理サーバDDS−1のデータベースDBへ格納するようアクションの登録が行われる。
そして、分散データ処理サーバDDS−1のデータベースDBに格納された「鈴木さんの位置」というデータの実体に対して、実世界モデルリストMDLのオブジェクトOBJ−1に対応する情報格納先が設定される。
あるいは、「鈴木さん着座」というオブジェクトOBJ−2については、モデル管理部MMGは、センサSSRとして感圧スイッチを備えた無線センサノードWSN−0の測定値がONであれば「00」という値を分散データ処理サーバDDS−1のデータベースDBに書き込み、無線センサノードWSN−0の測定値がOFFであれば「01」という情報を分散データ処理サーバDDS−1のデータベースDBに書き込むよう分散データ処理サーバDDS−1に指令する。
この指令を受けた分散データ処理サーバDDS−1では、イベントアクション制御部EACにて、センサノードWSN−0の測定データ値である「00」または「01」(それぞれ、ON/OFFに相当)を、データ処理サーバDDS−1のデータベースDBに書き込む処理を行う。
そして、上記と同様に、分散データ処理サーバDDS−1のデータベースDBに格納された「鈴木さん着座」というデータの実体に対して、実世界モデルリストMDLのオブジェクトOBJ−2に対応する情報格納先が設定される。
こうして、モデル管理部MMGが設定したオブジェクト(情報格納先)と、実際に情報を格納する分散データ処理サーバDDSの位置が設定される。
モデル管理部MMGは、図14で示したように、「鈴木さん位置」OBJ−1というオブジェクトを生成し、実世界モデルリストMDLにモデル名と、データID及び情報格納先を格納する。オブジェクトの登録が完了すると、モデル管理部MMGはサービス管理者端末ADT−Bに完了通知を送信する。
サービス管理者端末ADT−Bでは、受信したオブジェクトの生成完了通知を表示し、さらにオブジェクトを生成する場合には、上記の処理を繰り返して実行し、所望のオブジェクトを生成する。
<モデルバインドリストの定義>
次に、上記モデルリストMDLの定義によって、複数のオブジェクトを生成した後に、複数のオブジェクトOBJ−1〜n間の相関関係を示すモデルバインドリストMBLの設定について、図19を参照しながら説明する。
図19において、サービス管理者はサービス管理者端末ADT−BからディレクトリサーバDRSのモデル管理部MMGに接続し、モデル管理部MMGの検索インターフェースを呼び出す。そして、所望のオブジェクトの検索を行い、検索条件に一致したオブジェクトをサービス管理者端末ADT−Bに返信する。
サービス管理者端末ADT−Bは、モデル管理部MMGから受信したオブジェクトの検索結果を図示しない表示装置などに出力する。
サービス管理者は、サービス管理者端末ADT−Bに表示されたオブジェクトから所望のオブジェクトを選択し、各オブジェクトに共通する要素をモデルバインドリストとして生成するように、ディレクトリサーバDRSのモデル管理部MMGに要求する。
例えば、図15で示したように、「鈴木さん」という人名をモデルバインドリストMBL−Pとして生成し、このモデルバインドリストMBL−Pに鈴木さん位置OBJ−1、鈴木さん着座状態OBJ−2、鈴木さん温度OBJ−3などのオブジェクトを対応付ける。
モデル管理部MMGは、モデルバインドリストMBL−Pと各オブジェクトOBJ−1〜3の情報の格納先を関連づけて、モデルバインドリストMBLに格納する。
モデルバインドリストMBLの登録が完了すると、モデル管理部MMGはサービス管理者端末ADT−Bに完了通知を送信する。
サービス管理者端末ADT−Bでは、受信したモデルバインドリストの生成完了通知を表示し、さらにモデルバインドリストを生成する場合には、上記の処理を繰り返して実行し、所望のモデルバインドリストを生成する。
<モデルバインドリストの検索>
次に、上記のように設定したモデルバインドリストMBLにより、センサネットワークのユーザが、モデルバインドリストを用いてセンサノードのデータを参照する処理の一例について、図20、図21を参照しながら説明する。
ユーザ端末USTは、ディレクトリサーバDRSの検索エンジンSERに接続し、モデルバインド管理部MBMに対して、モデルバインドリストMBLの検索を要求する。この検索要求は、例えば、キーワード検索や図15のようなGUIなどで行われる。
モデルバインド管理部MBMは、要求のあった検索結果をユーザ端末USTに応答し、ユーザ端末USTの図示しない表示装置などに、検索要求に一致したモデルバインドリストの結果を表示する。
ユーザ端末USTにおいて、ユーザが検索結果の中から任意のモデルバインドリストを選択し、情報を要求する(STEP110)。
ここで、モデルバインドリストは、図15で示したように、オブジェクトOBJ間で共通する要素についてまとめたツリー構造のリンク先で構成され、ユーザ端末USTでモデルバインドリストに表示された何れかのリンク先を選択することで、情報の要求がリンク先の分散データ処理サーバDDSに対して行われる。
分散データ処理サーバDDSでは、ユーザ端末USTから要求のあった測定データまたは加工データにアクセスを行って、アクセスした結果をディレクトリサーバDRSの属性別意味解釈リスト管理部ATMに返信する。
ディレクトリサーバDRSでは、属性別意味解釈リスト管理部ATMが、分散データ処理サーバDDSから送信された測定データのIDから、図13に示した属性別意味解釈リストATLの戻り値に対する意味を取得する(STEP112)。
次に、ディレクトリサーバDRSの検索エンジンSERは、属性別意味解釈リスト管理部ATMで解析した測定データに対応する意味をユーザ端末USTに返信し、ユーザ端末USTでは当該ディレクトリサーバDRSからの応答を分散データ処理サーバDDSからの返信に代わって表示する。
例えば、図15のモデルバインドリストMBL−Pのリンク先LINK−1を選択した場合、ユーザ端末USTから鈴木さん位置OBJ−1について予め設定した分散データ処理サーバDDS−1の測定データにアクセスが行われる。リンク先LINK−1が例えば、図12に示したセンサ情報テーブルSTBのデータ格納先に対応付けられていれば、分散データ処理サーバDDSは、このデータ格納先に対応するデータベースDBから測定データである無線センサノードMSN−1の測定データを読み込んでディレクトリサーバDRSに返信する。
ディレクトリサーバDRSでは、データと共に格納されているデータ属性から、属性別意味解釈リストATLの場所テーブルATL−pを選択し、戻り値(測定データ)に対応する意味を取得する。この場合、例えば、戻り値=02であれば、モデルバインドリストMBL−Pのリンク先LINK−1の情報は、「A会議室」となる。したがって、モデルバインドリストMBL−Pの「鈴木さん位置」というオブジェクトOBJ−1に対する応答はセンサノードMSN−1の測定データ「02」という値から、「A会議室」というユーザにとって有意な意味を持つ情報に変換されてユーザ端末USTに表示(または通知)される。なお、本例ではデータ属性はデータと共に取得される方式を示した。この場合には、予めセンサノード登録時に、センサノードからのデータを受信する分散データ処理サーバDDSに対して、データ格納先の確保と属性の指定を行っておけばよい。データ属性を取得する別の方法としては、実世界モデルリストMDLの登録時に、モデルに対して属性を指定しておく方法でも良い。
図22は、上記図20の処理を、図15のモデルバインドリストMBL−Pの「鈴木さん着座状態」LINK−2について行ったものである。この場合も、各無線センサノードWSN−3〜10からの戻り値「00」が分散データ処理サーバDDSから読み込まれ、ディレクトリサーバDRSの属性別意味解釈リスト管理部ATMにて、戻り値=「00」が「在席」となり、「鈴木さんは在席しています」という有意な情報を検索エンジンSERからユーザ端末USTに返すことができる。
図23は、上記図20の処理を、図15のモデルバインドリストMBL−Pの「鈴木さん温度」LINK−3について行ったものである。この場合も、各無線センサノードMSN−1のセンサSSR−1からの戻り値「x」が分散データ処理サーバDDSから読み込まれ、ディレクトリサーバDRSの属性別意味解釈リスト管理部ATMにて、戻り値=xが温度y=f(x)として演算され、「鈴木さんの周囲温度はy℃です」という有意な情報検索エンジンSERからユーザ端末USTに返すことができる。
図24は、上記図20の処理を、図15のモデルバインドリストMBL−Rの「A会議室のメンバ」について行ったものである。この場合は、モデル管理部MMGでA会議室のメンバOBJ−4というオブジェクトを生成した際に、所定の分散データ処理サーバDDS−1では、A会議室に相当する基地局BST−1で検出された名札ノードのタグIDが、測定データとして基地局BST−1に読み込まれる。そしてこの値がデータ格納先として予め設定された、図14の情報リンク先(ここでは、分散データ処理サーバDDS−1)に格納される。
分散データ処理サーバDDS−1は、所定の周期で基地局BST−1から無線センサノードMSN−1〜nのタグIDを収集し、上記A会議室のメンバを示す値(名札ノードのタグIDの集合)を更新する。図24においては、分散データ処理サーバDDS−1が収集した無線センサノードMSN−1〜nより、タグのIDが「01」、「02」の従業者がA会議室で検出されたことを示す。
分散データ処理サーバDDS−1はこの加工データ「01、02」をディレクトリサーバDRSの属性別意味解釈リスト管理部ATMに送信する。
ディレクトリサーバDRSの属性別意味解釈リスト管理部ATMでは、予め定義された人名テーブルATL−mから、受信した加工データを、01=鈴木、02=田中、という有意な情報に変換してユーザ端末USTに送信する。
この結果、ユーザ端末USTでは、モデルバインドリストMBL−PのA会議室のメンバという情報要求に対して、「A会議室には鈴木、田中がいます」という有意な情報を得ることができる。
図25は、上記図20の処理を、図15のモデルバインドリストMBL−Rの「A会議室の人数」について行ったものである。この場合は、モデル管理部MMGでA会議室の人数OBJ−5というオブジェクトを生成した際に、所定の分散データ処理サーバDDS−1では、A会議室の人数、具体的にはある時間周期毎にA会議室に相当する基地局BST−1で検出される名札ノードのID数、もしくは着座ノードがONとなっている数を計算する。そしてこの値がオブジェクトOBJ−5のデータ格納先として、予め設定された図14の情報リンク先に格納される。
分散データ処理サーバDDS−1は、所定の周期で基地局BST−1から無線センサノードMSN−1〜nのIDの数xを収集し、上記A会議室の人数を示す値(加工データ)を演算して更新する。分散データ処理サーバDDS−1はこの加工データxをディレクトリサーバDRSの属性別意味解釈リスト管理部ATMに送信する。
ディレクトリサーバDRSの属性別意味解釈リスト管理部ATMでは、予め定義された人数テーブルATL−nから、受信した加工データを、人数y=x、という有意な情報に変換して検索エンジンSERからユーザ端末USTに送信する。
この結果、ユーザ端末USTでは、モデルバインドリストMBL−PのA会議室の人数という情報要求に対して、「A会議室にはy人います」という有意な情報を得ることができる。
<アクション制御部>
図26は、ディレクトリサーバDRSのアクション制御部ACCの詳細を示すブロック図である。
アクション制御部ACCは、複数の分散データ処理サーバDDSのイベントアクション制御部EACから受信したイベント発生通知に基づいて、予め設定した動作(アクション)を自動的に行うものである。
このため、アクション制御部ACCは、セッション制御部SESを介してユーザ端末USTからアクション設定を受け付けるアクション受け付け部ARCと、受け付けたアクションを分析し、分析結果に応じてディレクトリサーバDRSと分散データ処理サーバDDS間の機能(または負荷)分担を設定するアクション分析部AANと、アクションの定義及び実行を管理するアクション管理部AMGと、ユーザ端末USTからの設定要求に応じたイベントとアクションの関係を格納するアクションテーブルATBと、アクションテーブルATBで定義されたイベントを監視するように分散データ処理サーバDDS−1〜nに指令を送出するイベント監視指示部EMNと、各分散データ処理サーバDDS−1〜nで発生したイベント通知を受信するイベント受信部ERCと、受信したイベントとアクションテーブルATBの定義に基づいて、所定動作を実行するアクション実行部ACEとから構成される。
アクションの登録について、図27のタイミングチャートを参照しながら説明する。図27では、まず、ユーザ(またはサービス管理者)がユーザ端末UST等からディレクトリサーバDRSのアクション制御部ACCに接続し、アクションの設定を要求する。例えば、アクションの一例としては、図28で示すように、Xさんの着席を監視して、IPアドレス:Aのユーザ端末USTにポップアップ通知を送信する、というアクションを設定する場合について検討する。
アクション制御部ACCのアクション受付部ARCは、このアクションの設定要求を受け付けると、アクション分析部AANに当該アクションの設定を要求する。アクション分析部AANは、例えば、Xさんの着席から、監視対象のデータIDを選択し、またセンサノードの測定データがどのようになったらイベントを発生させるか決定する。ここでは、「Xさんの着席」という実世界の事象をデータIDへ変換するため、実世界モデルテーブルMTBの実世界モデルリストMDLと属性別意味解釈リストATLを参照して「Xさんの着席」というモデルを探索する。
ここで、図29で示すように、Xさん=鈴木さんの場合では、既に実世界モデルテーブルMTBにモデルが定義されているので、上記リストMDL、ATLからデータID=X2とデータを格納する情報格納先(分散データ処理サーバDDS1)を取得する。
次に、アクション管理部AMGでは、「Xさんの着席」というイベント発生を分散データ処理サーバDDSで監視するため、上記選択したセンサノードを管理する分散データ処理サーバDDSに対して「Xさんの着席」というイベント発生を監視するように指令を送出する。そして、アクション管理部AMGは、アクションテーブルATBに「IPアドレス:Aのユーザ端末USTにポップアップ通知を送信する」というアクションを設定し、当該アクションを実行するイベントのIDとして、上記センサノードIDを設定する。
ディレクトリサーバDRSのアクション管理部AMGから指令を受けた分散データ処理サーバDDSでは、図30で示すように、実世界モデルリストMDLから取得したデータID=X2について、属性意味解釈リストATLから取得した着席という条件「00」と、アクションとして行うべきイベントの通知先にディレクトリサーバDRSのアクション制御部ACCを登録する。なお、分散データ処理サーバDDS−1で行う、ディレクトリサーバDRSへの通知は、分散データ処理サーバDDS−1おけるアクションとする。
つまり、図30のイベントテーブルETBには、測定データのIDを示すデータID欄には、「鈴木さんの着席」を示す感圧センサのセンサノードID=X2が設定され、イベントの条件欄には、着席を示す「00」が設定され、分散データ処理サーバDDS−1のアクション欄には、ディレクトリサーバDRSのアクション制御部ACCへ通知する、というアクションが設定される。
また、図31のアクションテーブルATBには、監視対象のイベントIDを示すデータID欄には、「鈴木さんの着席」を示すセンサノードID=X2が設定され、イベントの条件欄には、分散データ処理サーバDDS−1からのイベント発生の受信が設定され、ディレクトリサーバDRSが実行するアクション欄には、ユーザ端末USTへのポップアップ通知が設定され、アクションのパラメータ欄には、ユーザ端末USTのうちAさんを示すIPアドレスが設定される。
アクション管理部AMGがアクションテーブルATBに登録するアクションは、図31で示すように、データID=X2のイベントを受信したことをイベントの条件とし、ポップアップ通知というアクションを、パラメータ欄に記載したアドレス(ここではIPアドレスAの端末)に対して実行するよう設定する。
なお、図28、図29のアクション設定要求画面は、ディレクトリサーバDRSのアクション受付部ARCがユーザ端末USTへ提供するもので、氏名のプルダウンメニューに実世界モデルリストMDLが対応付けられており、「着座」、「会議中」、「帰宅」のプルダウンメニューは、属性意味解釈リストATLに対応付けられており、「ポップアップ」、「メール」のプルダウンメニューは、ディレクトリサーバDRSで実行するアクションが設定されている。
上述のように、一つのイベント発生から一つのアクションを行うものを単一アクションとし、上記のようなアクションの設定は図32で示す流れとなる。すなわち、ユーザ端末USTからディレクトリサーバDRSのアクション制御部ACCに対してアクションの設定要求が行われ、アクションの分析とイベントの監視指示がアクション制御部ACCで生成され、分散データ処理サーバDDSのイベントアクション制御部EACにてイベントテーブルETBが定義される。その後、アクション制御部ACCのアクション管理部AMGは、イベント受信部ERCに対して、上記設定したイベント(データID=X2)の監視を指示する。これにより一連のアクションの設定が完了したことをアクション制御部ACCはユーザ端末USTに通知する。
<アクションの実行>
図33は、上記図28、図29で設定したアクションの実行を示すタイムチャートである。
監視対象のセンサノードの測定データがイベント発生条件の「00」に変化して、Xさんの着席が判定されると、分散データ処理サーバDDS−1は、データID=X2に関するイベント通知を発生する。
このイベント発生は、分散データ処理サーバDDSからディレクトリサーバDRSに通知され、図26のイベント受信部ERCが受信する。
ディレクトリサーバDRSのアクション管理部AMGは、受信したイベントのIDから図31のアクションテーブルATBを検索し、該当するアクションの有無を判定する。受信したID=X2のイベントは、アクションテーブルATBに定義があるので、アクション管理部AMGは、アクション実行部ACEに対してアクションテーブルATBのアクションとパラメータを通知する。
アクション実行部ACEは、アクション管理部AMGから指示されたIPアドレス:Aのユーザ端末USTに対してポップアップ通知を送信する。
IPアドレス:Aのユーザ端末USTには、ポップアップ通知が送信され、Xさんの着席が検知されたことを確認できる。
<複数アクションの設定及び実行>
上記図28、図29及び図33では、一つのイベント発生でひとつのアクションを行う例について述べたが、図34〜図39で示すように、2つのイベントが成立したらあるアクションを実行するように設定することができる。
図34、図35は、複数アクションの設定要求画面である。この設定要求画面には、2つの氏名欄についてそれぞれ「着席」等の状態を選択可能なプルダウンメニューが定義される。これら2つの氏名に対応するイベントの条件は、上記図28、図29と同様に、実世界モデルテーブルMTBの実世界モデルリストMDLと属性別意味解釈リストATLに対応付けられている。
さらに、これら2名のイベント条件の論理式(かつ、または)を設定するプルダウンメニューが加えられる。
そして、前記単一アクションと同様に、ディレクトリサーバDRSが実施するアクション(ポップアップ通知、メール送信)と、アクションの実行に必要とするパラメータ欄(アドレスなど)が設定される。
ここでは、「鈴木さんの着席」という分散データ処理サーバDDS−1のイベント発生と、「田中さんの着席」という分散データ処理サーバDDS−2からのイベント発生がともに成立した時点で、メールを送信するというアクションの例について説明する。
まず、「鈴木さんの着席」というイベントについては、上記図28、図29と同様に設定し、鈴木さんの着席を監視する分散データ処理サーバDDS−2のイベントテーブルETBには、図36に示すイベントが設定される。このときの、アクションテーブルの設定のタイムチャートを図39に示す。
次に、「田中さんの着席」というイベントについては、上記図28、図29と同様に、田中さんの着席を検知するセンサノードID=Y2をデータIDとし、意味解釈リストATLから着席を示す「00」をイベントの条件とし、このイベント条件成立時にはディレクトリサーバDRSのアクション制御部ACCへ通知するというアクションが、図37で示すように分散データ処理サーバDDS−2のイベントテーブルETBに設定される。
ディレクトリサーバDRSのアクション制御部ACCでは、図38で示すように、アクションテーブルATBに2つの条件が「AND」の論理式で結合され、設定される。
そして、「AND」により結合されたアクションテーブルATBの2つの条件について、アクション欄には「メール送信」が設定され、パラメータ欄には送信先のアドレスが設定される。
上記図32と同様にして、ユーザ端末USTからアクション制御部ACCに対して、鈴木さんの着席と田中さんの着席に関するアクションの設定要求が行われ、イベント監視指示部EMNから分散データ処理サーバDDS−1に対しては、データID=X2のセンサノードの測定データが所定条件(鈴木さんの着席)となったらイベントを通知するよう設定し、イベント監視指示部EMNから分散データ処理サーバDDS−2に対しては、データID=Y2のセンサノードの測定データが所定条件(田中さんの着席)となったらイベントを通知するよう設定する。
分散データ処理サーバDDS−1、2ではそれぞれイベントテーブルETBに新たなイベントが追加され、各分散データ処理サーバDDS−1、2のイベント発生判定部EVMでは、測定データに対するイベント監視が開始される。
また、アクション制御部ACCのアクション管理部AMGでは、イベント受信部ERCに、データID=X2とY2のイベントの監視が指示されて設定を終了する。
次に、図40はアクションの実行の様子を示すタイムチャートである。
まず、分散データ処理サーバDDS−1が、鈴木さんの着席に伴って、データID=X2のイベントを発生する。アクション制御部ACCではデータID=X2のイベントを受信するが、アクションテーブルATBでは、田中さんの着席がないとアクションを実行できないので、当該アクションは保留される。
次に、分散データ処理サーバDDS−2が、Yさんの着席に伴って、データID=Y2のイベントを発生する。アクション制御部ACCではデータID=Y2のイベントを受信し、アクションテーブルATBで、データID=X2とY2のAND条件が成立したので、アクションを実行し、所定のメールアドレスにメールを送信する。
このように、複数のイベントを条件としてアクションを実行することができ、多数のセンサから、ユーザに必要な応答のみを得ることが可能となる。これにより、膨大な数のセンサノードがあった場合でも、ユーザはほぼリアルタイムで所望の情報(または情報の変化)を検知でき、センサノードの情報を有効に利用することが可能となる。
<第2実施形態>
図41〜図45は、単一アクションの実行を分散データ処理サーバDDS側で行うようにしたもので、上記図9に示した分散データ処理サーバDDSのイベントアクション制御部EACにアクション実施部ACEを設け、図9のイベントテーブルETBをイベントアクションテーブルEATBに置き換えたもので、その他の構成は前記第1実施形態と同様である。
図41において、分散データ処理サーバDDSのイベントアクション制御部EACには、ディレクトリサーバインターフェースDSIを介して、基地局BSTから収集される測定データをイベントアクションに対応付けるイベントアクションテーブルEATBを備える。
イベントアクションテーブルEATBは、図43で示すように、センサノード毎に割り当てられて測定データに付与されるデータIDと、イベントを発生させる測定データの条件を示すイベント内容欄と、イベント発生時に分散データ処理サーバDDSが実施するアクションの内容を示すアクション欄と、アクションを実施する際に必要な値を格納するパラメータ欄と、イベント発生時に測定データをデータベースDBに格納するか否かを決定するデータ格納DHLとから1レコードが構成されている。
例えば、図中、データIDがX1の測定データは、その値が「02」のときにイベントを発生し、パラメータ欄で指定されたアドレスにメールを送信し、ディスク装置DSKへの測定データの書き込みは行わないように設定される。
分散データ処理サーバDDSでは、基地局BSTから受信した測定データを、まず、センシングデータID抽出部IDEで受け付け、センサノード毎に割り当てられたIDを測定データから抽出し、このIDをデータIDとする。また、センシングデータID抽出部IDEは、測定データを最新データメモリLDMに送る。
抽出されたデータIDはイベント検索部EVSに送られて、イベントアクションテーブルEATBを検索し、データIDが一致するレコードがあれば、当該レコードのイベント内容と測定データをイベント発生判定部EVMに送る。
イベント発生判定部EVMでは、測定データの値とイベント内容EVTを比較して、条件を満たせばアクション実施部ACEに送り、設定されたアクションを実施する。そして、アクション実施部ACEは、イベントの発生を最新データメモリLDMとDB制御部DBCに送る。
DB制御部DBCは、イベントアクションテーブルEATBのデータ格納DHLがYESとなっているデータについては、ディスク装置DSKに書き込みを行う。
データアクセス受け付け部DARは前記第1実施形態と同様であり、アクセス要求が最新のデータであれば、アクセス要求に含まれるデータIDに対応する測定データを最新データメモリLDMから読み込んで、ディレクトリサーバインターフェースDSIへ返送する。
図44は分散データ処理サーバDDSにアクションの設定を行う際のタイムチャートを示し、図42はアクションの設定を行う際に、ディレクトリサーバDRSのアクション制御部ACCがユーザ端末USTへ送信するインターフェースの一例を示す。なお、単一アクションの設定時では、ディレクトリサーバDRSが分散データ処理サーバDDSと通信し、ユーザ端末USTからのアクションの設定要求を、指定されたセンサノードIDに対応する分散データ処理サーバDDSに対して設定する。
まず、ユーザ(またはサービス管理者)がユーザ端末UST等からディレクトリサーバDRSのアクション制御部ACCに接続し、アクションの設定を要求する。例えば、アクションの一例としては、図28で示したように、Xさんの位置を監視してA会議室に入ったら、IPアドレス:Aのユーザ端末USTにポップアップ通知を送信する、というアクションを設定する場合について検討する。
アクション制御部ACCのアクション受付部ARCは、このアクションの設定要求を受け付けると、アクション分析部AANに当該アクションの設定を要求する。アクション分析部AANは、例えば、Xさんの着席から、監視対象のデータIDを選択し、またセンサノードの測定データがどのようになったらイベントを発生させるか決定する。ここでは、「Xさんの位置」という実世界の事象をデータIDへ変換するため、実世界モデルテーブルMTBの実世界モデルリストMDLと属性別意味解釈リストATLを参照して「Xさんの着席」というモデルを探索する。
ここで、図29で示したように、Xさん=鈴木さんの場合では、既に実世界モデルテーブルMTBにモデルが定義されているので、上記リストMDL、ATLからデータID=X2とデータを格納する情報格納先(分散データ処理サーバDDS1)を取得する。
次に、アクション管理部AMGでは、ユーザ端末USTからの要求が単一アクションであるか否かを判定し、単一アクションの場合には、要求されたアクションを上記情報格納先の分散データ処理サーバDDSに実施させるように設定する。
「Xさんの位置」に関するイベント発生の監視、およびイベント発生と関連付けられているアクションを分散データ処理サーバDDSで行うため、上記選択したセンサノードを管理する分散データ処理サーバDDSに対して「Xさんの位置」が「A会議室」に一致する、というイベント発生の有無を監視するように指令を送出する。さらに、ディレクトリサーバDRSのアクション制御部ACCは、分散データ処理サーバDDSに対してイベントアクションテーブルEATBに「メールアドレス:mailto_b@xyz.comのユーザにメールを送信する」というアクションを設定し、当該アクションを実行するイベントのIDとして、上記センサノードIDを設定する。
ディレクトリサーバDRSのアクション管理部AMGから指令を受けた分散データ処理サーバDDSでは、図43で示すように、実世界モデルリストMDLから取得したデータID=X1について、属性意味解釈リストATLから取得したA会議室という条件「02」と、アクションとして行うべきイベントの通知先に上記メールアドレスを登録する。
アクション管理部AMGが分散データ処理サーバDDSに登録するアクションは、図43で示すように、データID=X1のイベント発生時に、メール送信というアクションを、パラメータに記載したアドレスに対して実行するよう設定する。
このように、ユーザ端末USTから単一アクションの設定要求があると、ディレクトリサーバDRSのアクション制御部ACCは、自らのアクションテーブルATBに設定を行う代わりに、対応する分散データ処理サーバDDSに対して設定を行い、分散データ処理サーバDDSのイベントアクションテーブルEATBにイベントとアクションの双方が設定される。
分散データ処理サーバDDSにおけるイベントアクションの実行は、図45のように行われ、Xさんが会議室に入ると、データID=X1の値が「02」となり図43のイベントアクションテーブルEATBに定義されたイベント発生監視とそれに伴うアクションが実施される。アクションの実施により、所定のメールアドレスにはXさんがA会議室に入ったことが通知される。
この場合、ディレクトリサーバDRSは、アクションの設定のみを分散データ処理サーバDDSに対して行うだけで、実際のイベント発生を監視する必要がない。このため、データの収集と単一アクションの実行を分散データ処理サーバDDSに任せ、ディレクトリサーバDRSはユーザ端末USTからの検索要求と複数アクションの監視を行えばよいので、アクション監視の要求数が極めて大きいときに、ディレクトリサーバDRSの負荷が過大になるのを防いで、センサネットワークの円滑な運用が可能となる。
<変形例1>
図46、図47は前記第1または第2実施形態の第1の変形例を示す図である。この第1の変形例においては、あるセンサノードからの測定値を生データAとして所定の分散データ処理サーバDDSに格納し、また、異なるセンサノードからの測定値を生データBとして所定の分散データ処理サーバDDSに格納する。
そして、各分散データ処理サーバDDSでは、生データA、Bにそれぞれ加工(例えば、単位時間の平均値など)を施し、加工した結果をさらに加工ディレクトリサーバDRデータA、Bとしてそれぞれ格納する。生データA、Bの加工のタイミングは、ディレクトリサーバDRSまたは各分散データ処理サーバDDSにおいて、所定の条件(時間の経過)に基づくアクションとして実施すればよい。
さらに、各分散データ処理サーバDDSでは、加工を施した加工データA、Bから二次データCを所定のアクションとして演算し、新たな加工データとして所定の分散データ処理サーバDDSに格納する。この二次データCに加工を施したものを、さらに三次データC’として格納する。
例えば、生データAが温度、生データBが湿度の場合、加工データA、Bはそれぞれ、単位時間の平均温度と平均湿度となる。さらに、平均温度と平均湿度から求めた不快指数を二次データCと、さらに二次データCの単位時間の平均値を三次データC’として求めることができる。
上記第1または第2実施形態において、イベント発生を測定データとしたが、上記のような加工データA、Bや二次データC、三次データC’からイベントの発生やアクションの実施を行うことができる。
そして、図47で示すように、測定データ(生データ)と加工データを一つの分散データ処理サーバDDSに格納している。なお、この場合加工データA、Bを、当該加工データを管理する分散データ管理サーバと異なる分散データ管理サーバCへ転送し、加工データA、Bを生データとして扱い、三次データC’を加工データとして扱うことができる。
<変形例2>
図48は、第2の変形例を示し、前記第1または第2実施形態において、分散データ処理サーバDDSを接続するネットワークを複数に分割したものであり、その他の構成は前記第1または第2実施形態と同様である。
この例では、測定データを参照する頻度等に応じて分散データ処理サーバDDSを接続するネットワークが異なるように設定したものである。
ディレクトリサーバDRS(図示省略)から測定データあるいは加工データの参照頻度の高いものを、ディレクトリサーバDRSと同一のネットワーク1に接続する。そして、比較的参照頻度の引く合い加工データDを格納する分散データ処理サーバDDSをネットワーク2に接続し、ほとんど参照されない加工データEを格納する分散データ処理サーバDDSをネットワーク3に接続する。そして、各ネットワーク1〜3を図示しないゲートウェイにより接続しておく。
このように分散データ処理サーバDDSを配置することで、頻繁に参照するデータを持つ分散データ処理サーバDDSへのアクセス速度を向上させることができる。
<変形例3>
なお、上記第1または第2実施形態では、ディレクトリサーバDRSの実世界モデルリストMDLには、モデル名に対応するデータの格納先を情報リンク先として設定したが、レスポンス速度が迅速であることが必要な場合には、情報リンク先に加えてデータの最新値などを格納しても良い。
この場合、ディレクトリサーバDRSと分散データ処理サーバDDSの間のデータトラフィックは、オブジェクトの数に応じて増えるが、各センサからのデータは所定の周期で分散データ処理サーバDDSに収集されるので、上述した実施例と比較してネットワークNWK−1の負荷が増えることになるが、ユーザ端末USTからのデータ要求に対して、迅速に応答することが可能となり、レスポンスの向上を期待できる。