JP4431513B2 - セキュリティシステム - Google Patents

Description

本発明は、人や物の変化を連続的に追跡可能なセンサネットワークシステムとアプリケーションシステムとの協調システムに関し、特にセキュリティシステムに関する。

従来から、入退室管理や危険防止を目的として、監視カメラの利用、個人を特定可能なＩＣカードによる認証等が提案され、また実用化されてきた。
その一方で、現在技術開発の進展が甚だしいＩＴ技術、無線通信技術をこのようなセキュリティ分野に応用することも提案されている。特許文献１は、個人の情報を収集するためのセンサとそれを収集するための無線通信装置を備えた情報端末を個人に装着あるいは自宅に設け、それらから収集する情報に基づき、異常判定あるいは異常予測された場合には、情報端末による警報、あるいはネットワークを通じて警報を発することを開示する。

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

従来の監視カメラ等によるセキュリティシステムは、ある特定の場所において人の行動を監視することは可能であるが、その監視範囲を外れてしまうと監視することができない。また、ＩＣカードによる認証もゲートや立入制限エリアといったごく限られた場所でしか適用することが困難であり、利用者にとっても煩雑な手続きを要求することになる。人の行動をその人に対してストレスを与えることなく、定期的あるいは連続的に監視し、行動の履歴や変化から異常の発生を判定あるいは予測することは実用化されていなかった。

一方、特許文献１は本発明の完成後に公知例調査を行い見出したものであるが、センサを備えた情報端末からの情報を蓄積して異常判定、予測を行うことを開示している。しかしながら時々刻々と変化する情報を蓄積して何らかの判定を行うことは現在の進歩した計算機能力をもってしても容易ではない。また、このようなシステムは監視したい項目、場所が新たに追加された場合に容易に拡張できる仕組みを有する必要がある。

さらに、各種センサからの情報（ここでは、ＩＤのような値が固定の情報も含む）に基づき、人や物を定期的または連続的にモニタするセンサネットワークシステムを構築する場合に、このようなモニタリングシステムと上記したセキュリティシステムとをどのように協調してシステムを構築するかについて考慮されていなかった。

本発明は、センサネットワークシステムとアプリケーションシステムとを連携させ、特に既存のアプリケーションシステムが容易にセンサネットワークシステムの提供する情報を利用してその付加価値を向上させることが可能なセンサネットワーク／アプリケーションシステム協調システムを提供する。

サイトに設置された機器と、機器の状態を制御する制御装置と、制御装置に対し、あらかじめ設定されたセキュリティレベルのいずれかに応じた状態に機器を制御するよう指示する管制装置とを有するセキュリティシステムであって、管制装置はネットワークを介して第１のサーバに接続可能であり、第１のサーバは、サイト内に配置された複数のノードから収集された情報があらかじめ登録された条件に合致したことを検出する機能を有し、管制装置は第１のサーバに対して、セキュリティレベルを変更する場合の条件をあらかじめ登録し、第１のサーバからの条件に合致した旨の通知を受けることにより、条件に対応したセキュリティレベルの変更がなされるように制御装置に指示することを特徴とする。

第１のサーバはセンサネットワークシステムを形成し、センサネットワークシステムは時々刻々と蓄積される大量のデータを処理するのに適したスキームにしたがって構成される。すなわち、センサネットワークシステムにおいてはイベント−アクションスキームを採用し、あらかじめ条件（イベント）を設定してセンサネットワークシステムに登録しておけば、常にセキュリティシステムそれ自体が監視活動を行わなくとも、その条件が満たされた場合にその旨のセンサネットワークシステムから通知される（アクション）ことで、いわば自動的にセキュリティシステムによるきめ細かな管理が実現することができるのである。

特に限定されないが、アプリケーションシステムであるセキュリティシステムからは、第１のサーバが見えるだけであるが、第１のサーバとリンクされる複数のサーバにデータが蓄積されることで、拡張性の高いセンサネットワークシステムが実現できる。

また、ノードとしては人が装着可能なノードを用いることが出来る。センサネットワークシステムと協調することにより、ある一時点での位置のみならず、そのサイトにおける行動を追跡することができる。これにより、条件として人の行動が予期されるパターンと外れたこと（例えば、あらかじめ登録されたその人の行動予定から許容される行動パターンを設定することが出来るであろう）を設定することにより、センサネットワークシステムを用いなければ困難なきめ細かい管理を実現できる。

センサネットワークシステムとアプリケーションシステムとを協調させることにより、アプリケーションシステムの提供する価値を高めることができる。

以下、本発明の実施形態を添付図面に基づいて説明する。図１はセンサネットワーク／アプリケーション協調システムの構成図である。

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

固定的に設置される無線センサノードＷＳＮは、例えば、搭載されたセンサが周期的に周囲の状況をセンシングして、予め設定された基地局ＢＳＴへセンシング情報を送信する。無線モバイルセンサノードＭＳＮは、ヒトが持ち歩く、クルマに搭載されるなど、移動可能であることを前提とし、至近の基地局ＢＳＴに情報を送信する。

ここで、無線センサノードの全体（総称）を指すときにはＷＳＮまたはＭＳＮとし、個々の無線センサノードを指すときには、ＷＳＮ−１〜ｎあるいはＭＳＮ−１〜ｎのように添え字を付して表す。他の構成要素についても以下同様に、総称を示すときには添え字無しで表し、個々を示すときには添え字「−１〜ｎ」を付すものとする。

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

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

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

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

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

ディレクトリサーバＤＲＳは、図示しないＣＰＵ、メモリ及びストレージ装置を備えて所定のプログラムを実行し、後述するように、有意な情報に関連づけられたオブジェクトを管理する。すなわち、アプリケーションシステムＡＰＳが、アプリケーションインタフェースを介して実世界モデルに対してアクセスを要求すると、ディレクトリサーバＤＲＳは実世界モデルに該当する測定データを所有する分散データ処理サーバＤＤＳ−１〜ｎにアクセスし、該当する測定データを取得し、そのセンシングデータを、必要あればアプリケーションシステムＡＰＳが利用しやすい形に変換してアプリケーションシステムＡＰＳに渡す。

図２は、図１に示したセンサネットワーク／アプリケーション協調システムの機能ブロック図である。ここでは、説明を簡易にするため、図１の分散データ処理サーバＤＤＳ−１〜ｎのうち分散データ処理サーバＤＤＳ−１の詳細のみを示し、また、分散データ処理サーバＤＤＳ−１に接続された基地局ＢＳＴ−１〜ｎのうち基地局ＢＳＴ−１のみを示す。他の分散データ処理サーバＤＤＳや基地局ＢＳＴも同様に構成される。
以下、各部の構成について説明する。

＜基地局ＢＳＴ＞
センサノードからデータを収集する基地局ＢＳＴ−１は、分散データ処理サーバＤＤＳ−１との間で通信を行って、分散データ処理サーバＤＤＳ−１からのコマンドを送受信し、また、センサノードに対してコマンドを送受するコマンド制御部ＣＭＣ−Ｂと、センサノードの状態管理を行うセンサノード管理部ＳＮＭと、センサノードの故障を検出したり、センサノードからの異常なデータの検出を行ったりして検索結果をセンサノード管理部ＳＮＭに通知するイベント監視部ＥＶＭとを含むコントローラを備える。なお、センサノードは、予め設定されたＩＤを付して測定データを送信する。

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

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

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

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

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

＜分散データ処理サーバＤＤＳ＞
分散データ処理サーバＤＤＳ−１は、データベースＤＢを格納するディスク装置ＤＳＫと、後述のようなコマンド制御部ＣＭＣ−Ｄ、イベントアクション制御部ＥＡＣ、データベース制御部ＤＢＣを備える。
コマンド制御部ＣＭＣ−Ｄは、基地局ＢＳＴ及び後述するディレクトリサーバＤＲＳと通信を行って、コマンド等の送受信を行う。

イベントアクション制御部ＥＡＣは、センサノードからの測定データを基地局ＢＳＴから受信するたびに、測定データに含まれるセンサノードのＩＤを取得し、後述するテーブル（図９のイベントテーブルＥＴＢ）からセンサノードのＩＤに対応するイベントの発生ルールを読み込んで、測定データの値に応じたイベントの発生の有無を判定する。さらに、イベントアクション制御部ＥＡＣでは、センサノードのＩＤに該当するイベントの発生に対応するアクションを実行する。

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

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

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

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

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

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

ディレクトリサーバＤＲＳは、実世界モデルに相当する測定データもしくは加工データの存在場所の位置情報（ＵＲＬなどのリンク）も管理している。つまり、アプリケーションシステム開発者は、実世界モデルを指定することで、時々刻々と変化するセンサノードの測定情報にダイレクトにアクセス可能となる。センサノードからの測定データ及び加工データは、時間の経過につれて増大するのに対し、実世界モデル情報は時間が経過してもサイズが変化することはなく、その内容のみが変化する。この実世界モデルの詳細については後述する。
なお、実世界モデルテーブルＭＴＢは、ディレクトリサーバＤＲＳの所定のストレージ装置（図示省略）などに格納される。

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

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

なお、検索要求がクエリーであれば、クエリーの内容に従ったデータベースＤＢの対応付けと、クエリーのＳＱＬ（Structured Query Language）変換を実行し、検索を実行する。なお、検索対象となるデータベースＤＢは、複数の分散データ処理サーバＤＤＳにまたがる場合がある。また、最新データ取得（ストリーム）はアクション制御部ＡＣＣのアクションの設定にて対応できる。例えば、該当のデータを常にアプリケーションシステムＡＰＳに転送するようなアクションの設定を、該当する分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣに設定しておけばよい。

次に、装置管理部ＮＭＧは、ネットワークＮＷＫ−１に接続されてセンサネットワークを構成する分散データ処理サーバＤＤＳと、分散データ処理サーバＤＤＳに接続された基地局ＢＳＴ、基地局ＢＳＴに接続されたセンサノードを統合的に管理するものである。装置管理部ＮＭＧでは、分散データ処理サーバＤＤＳ、基地局ＢＳＴ、センサノードの登録や検索に関するインターフェースを管理者端末ＡＤＴ等に提供し、それぞれの装置の状態や、センサノードの状態を管理する。

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

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

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

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

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

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

電源ＰＯＷは、電池（二次電池を含む）を利用するのが一般的であると考えられるが、それに限られず、太陽電池や振動発電などの自律発電機構を具備する、あるいはモバイルセンサノードでなければ、外部電源から電源を供給する構成とすることもできる。

なお、図３は一つのセンサノードに一つのセンサＳＳＲを備えた例であるが、複数のセンサＳＳＲを配置しても良い。あるいは、センサＳＳＲに代わって、固有の識別子ＩＤを格納したメモリを設けても良く、センサノードをタグとして使用しても良い。また、無線モバイルセンサノードＭＳＮ、有線センサノードＦＳＮも図３、図４と同様に構成することが可能である。

図５は、分散データ処理サーバＤＤＳに接続されるセンサノードの設置例を示す図である。図５の例では、オフィスビルのロビー、廊下、部屋、エレベータ等に基地局を設置し、ビル内にいる人にモバイルセンサノードを設置した例を示している。この例では、無線センサノードを適用した例として説明するが、分散データ処理サーバとセンサノードとを無線通信で接続するか、有線通信で接続するかは、適宜選択すればよい。

図５のビル内には、例えば１階には、ロビーに基地局ＢＳＴ−１、１Ｆ廊下に基地局ＢＳＴ−２およびＢＳＴ−３、第１会議室に基地局ＢＳＴ−４、居室１に基地局ＢＳＴ−５およびＢＳＴ−６が設置されている。また、２階には、居室２に基地局ＢＳＴ−７、廊下にＢＳＴ−８およびＢＳＴ−９、第２会議室にＢＳＴ−１０、居室３に基地局ＢＳＴ−１１およびＢＳＴ−１２、また、エレベータの籠ＥＬＶに基地局ＢＳＴ−１３が設置されている。さらに、３階には、居室４に基地局ＢＳＴ−１４、廊下に基地局ＢＳＴ−１５およびＢＳＴ−１６、第３会議室に基地局ＢＳＴ−１７、居室５にＢＳＴ−１８およびＢＳＴ−１９が設置されている。

一方、ビル内にいる人ＰＳ−１は、例えば名札形状のモバイルセンサノードＭＳＮ−１を装着する。また、ＷＳＮ−１からＷＳＮ−１９は、据置き型の無線センサノードを示している。これらの無線センサノードは、例えば出入り口に設置して人感センサで人の出入りを検知したり、居室や会議室に設置して温度センサ、湿度センサ、照度センサで気温、湿度、明るさの絶対量あるいは変化を検知したりする。

センサノードＭＳＮ−１、およびＷＳＮ−１からＷＳＮ−１９は、それぞれがビル内に配置された基地局ＢＳＴ−１からＢＳＴ−１９のいずれかと無線通信を行うことによってセンサを用いて検知した状態量または状態量の変化を送信する。基地局ＢＳＴ−１からＢＳＴ−１９は、センサノードから受信した状態量または状態量の変化を、図１に示したネットワークＮＷＫ−２からＮＷＫ−Ｎを介して分散データ処理サーバＤＤＳに送信する。

＜センサネットワークの動作概念＞
次に、センサネットワークＳＮＳの動作の概要について、図６を用いて説明する。図６は、実世界モデルの具体的な形であるオブジェクトとセンサノードの測定データの関連を示すブロック図である。

図１、２を用いて説明したディレクトリサーバＤＲＳは、図６に示すように実世界モデルとして予め以下に述べるようなオブジェクト（ＯＢＪ−１からＯＢＪ−６）を生成し、実世界モデルテーブルＭＴＢの実世界モデルリストＭＤＬに定義する。ここでは、図５のオフィスビルを利用する人物ＰＳ−１の場合を示し、図６に示した無線センサノードＭＳＮ−１を、この人物が装着しているものとする。

一例として、モバイルセンサノードＭＳＮ−１の位置情報は、測定データ１（図７のデータ格納先）が指し示す分散データ処理サーバＤＤＳに格納されるよう、装置管理部ＮＭＧで定義されている。なお、モバイルセンサノードＭＳＮ−１の位置情報の求め方は特に限定しないが、最も単純な方法としてはモバイルセンサノードＭＳＮ−１が交信している基地局ＢＳＴの位置をモバイルセンサノードＭＳＮ−１の位置として定義することができる。

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

アプリケーションシステムＡＰＳからは、ＰＳ−１位置（ＯＢＪ−１）の値はディレクトリサーバＤＲＳの実世界モデルテーブルＭＴＢに存在するようにアクセスできるが、実際のデータはディレクトリサーバＤＲＳではなく、予め設定された分散データ処理サーバＤＤＳ−１のディスク装置ＤＳＫ１に格納されるのである。

また、ＰＳ−１移動速度（ＯＢＪ−２）というオブジェクトは、移動するセンサノードＭＳＮ−１の移動速度情報が測定データ２（ＬＩＮＫ−２）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。モバイルセンサノードＭＳＮ−１の移動速度の求め方は特に限定しないが、最も単純な方法としては移動するセンサノードＭＳＮ−１が通信した基地局ＢＳＴが切り替わる時間から求めることができる。さらに、測定データ２に対応する分散データ処理サーバＤＤＳと格納位置が定義される。例えば、分散データ処理サーバＤＤＳ−２のディスク装置ＤＳＫ２に格納する。

ＰＳ−１ノード装着（ＯＢＪ−３）というオブジェクトは、名札型無線センサノードＭＳＮ−１のクリップ等に取り付けたスイッチ等により着脱を検出することによって判定したノード装着状態が測定データ３（ＬＩＮＫ−３）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ３に対応する分散データ処理サーバＤＤＳと格納位置が定義される。例えば、ＭＳＮ−１に取り付けられたスイッチの状態は、例えば分散データ処理サーバＤＤＳ−３のディスク装置ＤＳＫ３に格納する。

周囲気温（ＯＢＪ−４）というオブジェクトは、人ＰＳ−１が接続した基地局（例えばＢＳＴ−１）に接続している無線センサノード（例えば図５におけるＷＳＮ−３）の温度センサが測定した温度情報が測定データ４（ＬＩＮＫ−４）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ４に対応する分散データ処理サーバＤＤＳと格納位置が定義される。例えば、無線センサノードＷＳＮ−３からの温度は、例えば分散データ処理サーバＤＤＳ−４のディスク装置ＤＳＫ４に格納する。

ＰＳ−１ゲート通過（ＯＢＪ−５）というオブジェクトは、人ＰＳ−１が接続した基地局（例えばＢＳＴ−１）に接続している無線センサノード（例えばＷＳＮ−２）の人感センサが測定した人検知情報が測定データ５（ＬＩＮＫ−５）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ５に対応する分散データ処理サーバＤＤＳと格納位置が定義される。例えば、例えば図５における無線センサノードＷＳＮ−２からの人検知情報は分散データ処理サーバＤＤＳ−５のディスク装置ＤＳＫ５に格納する。

周囲明るさ（ＯＢＪ−５）というオブジェクトは、人ＰＳ−１が接続した基地局（例えばＢＳＴ−１）に接続している無線センサノード（例えば図５におけるＷＳＮ−３）の照度センサが測定した照度情報が測定データ６（ＬＩＮＫ−６）に格納されるよう、実世界モデルテーブルＭＴＢに定義される。さらに、測定データ６に対応する分散データ処理サーバＤＤＳと格納位置が定義される。例えば、無線センサノードＷＳＮ−３からの照度は、例えば分散データ処理サーバＤＤＳ−６のディスク装置ＤＳＫ６に格納する。

このように、実世界モデルテーブルＭＴＢに定義された各オブジェクトＯＢＪは、測定データに対応する格納先（ＬＩＮＫ）を格納しており、アプリケーションシステムＡＰＳからは目的のデータがディレクトリサーバＤＲＳに存在するように見えるが、実際のデータは分散データ処理サーバＤＤＳに格納される。

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

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

これにより、アプリケーションシステム開発者はセンサノードの所在を意識する必要がなく、オブジェクトＯＢＪを検索することで、センサノードの測定値（または加工データ）に対応する所望のデータを得ることができるのである。

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

測定開始から所定時間経過した状態では、分散データ処理サーバのディスク装置ＤＳＫ１〜６にセンサノードからの実際の測定データが書き込まれ、時間の経過とともにデータ量は増大する。しかしながら、ディレクトリサーバＤＲＳの実世界モデルテーブルＭＴＢのモデルリストＭＤＬに設定されたオブジェクトＯＢＪ−１〜６に対応する格納先ＬＩＮＫ−１〜６は、時間が経過しても情報量は変化することなく、格納先ＬＩＮＫ−１〜６が指し示す情報の内容が変化するだけである。

なお、図６の例では、オブジェクト毎に異なるデータ処理サーバに格納している例を示しているが、異なるオブジェクトを同じデータ処理サーバのディスク装置に格納することができることはいうまでもない。データ処理の扱い易さ等から、どのオブジェクトの測定データをどのデータ処理サーバに格納するかを決めておけばよい。

＜測定データとイベントの関係＞
次に、分散データ処理サーバＤＤＳで収集される測定データと、測定データに基づくイベントアクションの関係を図７、図８、図９に示す。
図７は、ディレクトリサーバＤＲＳが管理するセンサ情報テーブルＳＴＢの例である。センサ情報テーブルＳＴＢは実世界モデルテーブルＭＴＢに格納されている。センサ情報テーブルＳＴＢには、測定データに付与されるデータＩＤ毎に、センサ種別、センシング情報の意味、計測値、設置場所、センシングの間隔、データ格納先が格納されている。ここでは、一つのセンサノードが複数種類のセンシングデータと関連づけられることを考慮して、測定データ毎にＩＤを付与しているが、一つのセンサノードが一種類のセンシングデータとしか関連づけられない場合は、データＩＤに代えてセンサノードＩＤを用いることができる。また、図７に示したセンサ情報テーブルに格納する情報の例は一例であって、センサネットワークシステムの管理の必要性に応じて格納する情報の増減は可能である。

図８において、分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣには、ディレクトリサーバインターフェースＤＳＩを介して、基地局ＢＳＴから収集される測定データをイベントに対応付けるイベントテーブルＥＴＢを備える。イベントテーブルＥＴＢは、図９で示すように、センサノード毎に割り当てられて測定データに付与されるデータＩＤ（ＤＩＤ）と、測定データに関してイベントの発生判断条件であるＥＶＴと、測定データをデータベースＤＢに格納するか否かを決定するデータ格納ＤＨＬとから１レコードが構成されている。

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

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

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

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

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

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

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

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

＜アクション制御部＞
図１０は、ディレクトリサーバＤＲＳのアクション制御部ＡＣＣの詳細を示すブロック図である。
アクション制御部ＡＣＣは、複数の分散データ処理サーバＤＤＳのイベントアクション制御部ＥＡＣから受信したイベント発生に基づいて、予め設定した動作（アクション）を自動的に行うものである。

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

アクションの登録について、図１１のタイミングチャートを参照しながら説明する。図１１では、まず、アプリケーションシステム管理者がアプリケーションシステムＡＰＳからディレクトリサーバＤＲＳのアクション制御部ＡＣＣに接続し、アクションの設定を要求する。例えば、アクションの一例として、出入口等のゲートをＸさんが通過するのを監視し、アプリケーションシステムＡＰＳに通知を送信する、というアクションを設定する場合について説明する。

アクション制御部ＡＣＣのアクション受付部ＡＲＣは、このアクションの設定要求を受け付けると、アクション分析部ＡＡＮに当該アクションの設定を要求する。アクション分析部ＡＡＮは、監視対象のデータＩＤを選択し、さらにその測定データがどのようになったらイベントを発生させるか決定する。すなわち、「Ｘさんのゲート通過」という実世界の事象をセンサネットシステムに蓄積されるセンシングデータにより判定可能なモデルとして構築する。

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

次に、アクション管理部ＡＭＧでは、「Ｘさんのゲート通過」というイベントを分散データ処理サーバＤＤＳで発生させるため、上記選択したセンサノードを管理する分散データ処理サーバＤＤＳに対して「Ｘさんのゲート通過」というイベントを発生するように指令を送出する。そして、アクション管理部ＡＭＧは、アクションテーブルＡＴＢに「アプリケーションシステムに通知を送信する」というアクションを設定し、当該アクションを実行するイベントのＩＤとして、上記センサノードＩＤを設定する。

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

具体的に、図６の例を用いて説明する。ディレクトリサーバＤＲＳはオブジェクトＯＢＪ−１（無線センサノードＭＳＮ−１の位置情報）を管理するデータ処理サーバＤＤＳ−１に対して、図１２に示すイベントテーブルＥＴＢを登録させる。ここで、条件「００」が当該ゲートを通信範囲に含む基地局のＩＤとすれば、人ＰＳ−１が当該ゲートを通過したときにオブジェクトＯＢＪ−１（無線センサノードＭＳＮ−１の位置情報）に対応するデータＩＤ（Ｘ２）の値は「００」の値を返すことになる。このように、実世界の事象とセンシング情報とが関係づけられ、Ｘ２＝００の条件が成立した場合に、データ処理サーバＤＤＳ−１はディレクトリサーバのアクション制御部ＡＣＣに対して、イベント発生を通知する。

いうまでもなく、以上のイベント発生条件は一例である。例えば、ゲートに付加された人感センサの情報と人ＰＳ−１の位置情報との双方を用いてイベント発生条件とすることも可能であろう。

また、図１３のアクションテーブルＡＴＢはディレクトリサーバＤＲＳのアクションデーブルＡＴＢであり、監視対象のイベントＩＤを示すデータＩＤ欄には、「ＰＳ−１のゲート通過」を示すデータＩＤ＝Ｘ２が設定され、イベントの条件欄には、分散データ処理サーバＤＤＳ−１からのイベント発生の受信が設定され、ディレクトリサーバＤＲＳが実行するアクション欄には、アプリケーションシステムＡＰＳへの通知が設定され、アクションのパラメータ欄にはアプリケーションシステムＡＰＳを示すＩＰアドレスが設定される。

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

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

＜アクションの実行＞
図１５は、設定したアクションの実行を示すタイムチャートである。
監視対象のセンサノードの測定データがイベント発生条件の「００」に変化して、Ｘさんのゲート通過が判定されると、分散データ処理サーバＤＤＳ−１は、データＩＤ＝Ｘ２に関するイベント通知を発生する。

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

アクション実行部ＡＣＥは、アプリケーションシステムＡＰＳに対して人ＰＳ−１がゲートを通過した旨を連絡する。
なお、以上は一つのイベント発生でひとつのアクションを行う例について述べたが、２つ以上のイベント発生条件が全て成立したらあるアクションを実行するように設定してもよく、一つのイベント発生で複数のアクションを行うように設定することもできる。

以上述べたような、イベント−アクション制御は、ディレクトリサーバで実行することも、データ処理サーバで実行することも可能であり、これはイベントとアクションの内容によって定めることが望ましい。例えば、イベントの判定が一つのデータ処理サーバに格納されているデータで実行できるのであればディレクトリサーバの負荷、通信経路の負荷を軽くするためにも、データ処理サーバで実行することが望ましい。一方、複数のデータ処理サーバにデータが分散している場合には、ディレクトリサーバで実行しても良いし、ある一つのデータ処理サーバにイベントの判定を割り当てても良い。

＜センサネットワーク／アプリケーション協調システム＞
以上説明したようなセンサネットワークシステムとアプリケーションシステムとを協調して動作するように構成したセンサネットワーク／アプリケーション協調システムの実施形態について以降説明する。図１６は、図１で説明したセンサネットワークシステムＳＮＳと協調するアプリケーションシステムＡＰＳとして、セキュリティシステムＳＣＳを接続した場合の構成例である。図１６では、センサネットワークシステムを構成するネットワークＮＷＫ−１を介してセキュリティシステムが接続している。なお、図１６の例では一つのセキュリティシステムに対して一つのセンサネットワークシステムＳＮＳが接続されているが、複数のセンサネットワークシステムＳＮＳが接続されてもよい。例えば、セキュリティシステムが監視対象とする場所（例えば、オフィス、工場等）が複数あり、場所毎にセンサネットワークシステムが構築されているというような場合である。また、一つのセンサネットワークシステムに対し、複数のセキュリティシステムＳＣＳが接続されても良い。例えば、一つの監視対象場所の管理者が、同時に複数の異なるセキュリティサービスを契約することによってセキュリティ性を高める場合である。または、セキュリティシステムＡは来訪者の監視を行い、セキュリティシステムＢは従業員の監視を行う等、同一の監視対象場所において監視対象が異なる場合である。もちろん、センサネットワークシステムＳＮＳとセキュリティシステムＳＣＳの双方が複数存在し、各々が相互に接続されることも可能である。以降の説明ではセンサネットワークシステムはアプリケーションシステム（セキュリティ）に関連してのみ説明するが、センサネットワークシステムは各サイトにおいてこのアプリケーション（セキュリティ）に関する機能を果たすのみならず、他の機能を果たすように運用されることも可能である。

また、アプリケーションについてはセキュリティに限定されるものではなく、例えば人の所在に基づく空調や照明の制御、物流の所在の管理等、本発明で示した手段に基づいてセンサネットワークと協調することにより所定の機能を実現可能な、様々なアプリケーションに適用できることは明らかである。

＜セキュリティシステム＞
図１７は、図１６で示したセンサネットワークシステムＳＮＳに接続するセキュリティシステムＳＣＳの構成例である。図１７の例では、セキュリティシステムＳＣＳは、管制センタＣＲＣと監視サイトに置いたサイトコントローラＳＣＲ、サイトコントローラＳＣＲに接続して監視サイトの状態監視を行うためのセンシング機器ＳＳＤ、およびサイトコントローラＳＣＲにより制御を行う監視サイトの制御対象機器ＣＴＤで構成される。

管制センタＣＲＣは、監視サイトを統合管理するサービスセンタ等である。
サイトコントローラＳＣＲと管制センタＣＲＣの間は公衆回線等の通信網ＰＮＷを介して接続する。
サイトコントローラＳＣＲは、監視サイトの状態をセンシング機器ＳＳＤを用いて監視し、異常が発生した際に通信網ＰＮＷを介して管制センタＣＲＣに通知する。管制センタは、異常の種類を判定し、判定結果に応じて係員を監視サイトに派遣したり、セキュリティサービス契約者に連絡したり、緊急時には警察や消防に通報する等の処理を行う。また、通信網ＰＮＷを介してサイトコントローラに指示を出し、制御対象機器の制御を行う。

センシング機器としては、例えばドアの開閉を検知する開閉センサ、人の接近や通過を検知する人感センサ、ガス漏れを検知するガスセンサ、窓ガラス等への衝撃を検知する衝撃センサ、室温や湿度を観測する温度センサ、湿度センサ、映像監視を行うカメラ、音響監視を行うマイク等がある。

また、制御対象機器としては、例えば出入口やマシンラック等の電子錠、ドア、防犯／防火シャッタ、空調機器、照明機器、火災初期消火のためのスプリンクラ、警告灯、スピーカ等がある。また、例えばカメラやマイク等、センシング機器の中にも制御対象機器となるものもある。

図１８を用いてセキュリティシステムにおける処理の流れを説明する。
サイトコントローラＳＣＲにおいて、センシング情報取得部ＩＦＲは、監視対象サイトに配置されたセンシング機器ＳＳＤを用いて監視対象サイトの情報を取得する。状態判定部ＳＴＭは、センシング情報取得部ＩＦＲが取得した情報を用いて例えば出入口の開閉や、ガス漏れ等の監視対象サイトの状態を判定する。異常検出部ＡＮＣは、状態判定部ＳＴＭが判定した状態が異常かどうかを判断し、異常を検出した場合に異常信号を通知部ＩＮＦに送る。通知部ＩＮＦは、通信制御部ＣＭＣ−Ｂを用いて通信網ＰＮＷを介して異常信号を管制センタＣＲＣに通知する。管制センタＣＲＣでは、通信制御部ＣＭＣ−Ａを用いて異常信号を受信し、処理決定部ＰＲＤにおいて異常信号に対応する処理を決定し、処理設定部ＰＲＳにおいて実際の対応処理を設定する。例えば対応処理が契約者への連絡や、警察／消防への通報であった場合は、通信部ＣＯＭに対して処理を設定し、通信部ＣＯＭは、通信機器ＣＭＤを用いて契約者への連絡や、警察／消防への通報を行う。対応処理が、例えば監視対象サイトの制御対象機器の制御であった場合は、通信制御部ＣＭＣ−Ａを用いて通信網ＰＮＷを介し、処理指示をサイトコントローラＳＣＲに送る。サイトコントローラＳＣＲは、通信制御部ＣＭＣ−Ｂを用いて受信した処理指示を機器制御部ＤＣＴに送り、機器制御部ＤＣＴが指示された制御対象機器ＣＴＤの一つまたは複数を制御する。

＜センサネットワークシステムとセキュリティシステムの協調＞
図１９は、センサネットワークシステムとセキュリティシステムとを協調させる場合の要部を示す図である。本構成では、セキュリティシステムはセンサネットワークシステムにおけるアプリケーションシステムとして位置づけられる。従って、セキュリティシステムとセンサネットワークシステムの協調は、図８〜図１５を用いて説明したように、セキュリティシステムからセンサネットワークシステムに対しアクションを設定し、イベント発生時のアクション通知を受ける形で行われる。

図１９の構成では、セキュリティシステムＳＣＳの構成要素である管制センタＣＲＣの処理設定部ＰＲＳにおいて、センサネットワークシステムＳＮＳに対してイベント発生条件の指定、およびイベント発生時のアクション通知を設定し、センサネットワークシステムＳＮＳの構成要素であるディレクトリサーバＤＲＳのセッション制御部ＳＥＳに対してアクション設定要求を行う。センサネットワークシステムＳＮＳは、処理設定部ＰＲＳから要求されたアクション設定をセッション制御部ＳＥＳで受付け、アクション制御部ＡＣＣにおいてアクションの分析を行う。アクション制御部ＡＣＣは、分散データ処理サーバＤＤＳに対してイベントの監視指示を出し、発生したイベントを受信して、予め設定してあったアクションを実行し、セキュリティシステムＳＣＳを構成する管制センタＣＲＣの処理決定部ＰＲＤに対してアクション通知を行う。

処理決定部ＰＲＤは、アクション通知と、セキュリティシステムのサイトコントローラＳＣＲからの異常通知に基づいて対応処理を決定し、処理設定部ＰＲＳにおいて対応処理を設定する。
以下で、セキュリティシステムＳＣＳがセンサネットワークシステムＳＮＳに対して設定するアクションの例を説明する。

セキュリティシステムにおいては、監視対象サイトにおける人の行動モデルを選択してアクションを設定する。そして、監視対象者の異常行動によって発生したイベントに基づくアクション通知と、セキュリティシステムに接続されているセンシング機器の情報から異常の種類と状態を判定してセキュリティシステムの処理を決定し、制御対象の機器の制御や、契約者への連絡、警察／消防等への通報、係員の派遣等の対応処理を行う。

また、センサネットワークシステムにおけるセンサノードの通信間隔やセンシング間隔の変更等、セキュリティシステムの判定結果に基づいてセンサネットワークシステムの各種パラメータ設定値を調整し、センサネットワークシステムの装置管理部ＮＭＧに変更要求を送る。

セキュリティシステムの対応処理としては、例えば対象エリアを複数の監視領域に分け、各々にセキュリティ処理ランクを設定し、処理決定部ＰＲＤにおいて監視領域の指定と、指定した監視領域のセキュリティ処理ランクを変更する。

図２０にセキュリティ処理ランクの例を示す。ここで、セキュリティ処理ランクはセキュリティシステムＳＣＳで採用している処理ランクであり、その対応方針、対応処理における機器制御、通知、係員の対応といった項目はセンサネットワークとは関係なく規定できる項目である。ここでの特徴は、センサネットワークからの情報を用いてセキュリティ処理ランクを変更することにある。例えば、「想定外行動継続時間が規定値超過」という内容をセンサネットワークが検出すべきイベントとして登録しておき、当該イベントが検出されたときにはセンサネットワークはセキュリティシステムにその旨を通知するというアクションを実行する。センサネットワークからの通知を受けてセキュリティシステムはそのセキュリティレベルに応じた対応処理（上記内容では異常レベル２）を実行する。さらにはセンサネットワークそのものも固有のアクションを実行してもよい。例えば、図２０の例では、センサノードとの通信頻度を高める、あるいはセンサノードが備えている警報装置を起動するといったようなことが挙げられる。このように構成することで、監視対象になっている人には過度のプレッシャーを与えることなく、きめ細かなセキュリティ環境が実現できる。

なお、ここでは、監視サイトの状態モニタのために用いるセンシング機器として、セキュリティシステムに接続したセンサを用いる例を説明したが、センサネットワークシステムに接続されているセンサノードに、セキュリティ監視に必要なセンサを搭載し、センサネットワークシステムの制御下で監視サイトの状態をモニタしても良い。

また、制御対象機器をセンサネットワークシステムに接続し、該制御機器の制御を、センサネットワークシステムを介して行うことも可能である。この場合のセキュリティシステムは、センサネットワークシステムと一体の構造となり、センサ情報の取得、および制御対象機器の制御は、全てセンサネットワークシステムのイベントアクション機能を用いて行うことが可能になる。

このような構成の場合、センサネットワークシステムが導入されているオフィスビル等のサイトに新規にセキュリティシステムを導入する際は、セキュリティシステムのために新たにセンシング機器や制御対象機器を接続するためのインフラ整備が不要になるため、導入コストを低く抑えることができる等の効果が期待できる。

図２１は、セキュリティシステムの対象サイトとして、例えばオフィスビルの監視を行う場合に、監視対象者の行動を判定する方法を説明する図である。
図は、オフィスビルの廊下を表している。センサネットワークシステムの基地局ＢＳＴ−１、ＢＳＴ−２、ＢＳＴ−３は、例えばオフィスビルの天井にセンサノードとの通信に必要十分な間隔で設置される。

監視対象者ＰＳ−１は、オフィスビルに入った際に、受付等で個人を特定する情報を示して名札型のモバイルセンサノードＭＳＮ−１を受け取り、これを胸等に装着する。このとき、受付者は、ＭＳＮ−１のノードＩＤをセンサネットワークシステムのノード登録機能を用いて登録し、対象者ＰＳ−１の個人情報とリンクさせる。図２２に個人情報テーブルの例を示す。図２２の例では、来訪者の管理を想定して登録内容が設定されており、個人情報テーブルに登録すべき内容はその目的やサイトのポリシーに応じて設定してよい。個人とその付与されたノードＩＤとの対応が少なくともとれていればよい。

図２１において、センサノードＭＳＮ−１は登録が完了した時点から、例えば３秒間隔でノードＩＤを無線で発信するものとする。また、ＭＳＮ−１の無線到達エリアをＣＡ−１とする。

今、ＭＳＮ−１を装着した監視対象者ＰＳ−１が、オフィスビルの廊下を歩行しているとき、ＭＳＮ−１が発信したノードＩＤ等の情報を、無線到達エリアＣＡ−１内にある基地局ＢＳＴ−１が受信することにより、監視対象者ＰＳ−１がＭＳＮ−１の無線到達エリアに存在する基地局ＢＳＴ−１の近傍にいることが特定できる。次にＰＳ−１が移動し、ＭＳＮ−１のノードＩＤをＢＳＴ−２が受信すれば、ＰＳ−１はＢＳＴ−２の近傍に到達したことがわかる。予め基地局の設置場所を登録しておけば、ノードＩＤを検出した基地局の位置の履歴から、監視対象者ＰＳ−１が監視対象エリアのどの経路を通過し、現在どこにいるかを無線到達エリアの大きさの精度で検出することができる。この時、各基地局がノードＩＤを受信した時間の差分を計算すれば、監視対象者ＰＳ−１のおおよその移動速度を推定することも可能である。基地局を十分密に配置しておけば、ノードＭＳＮ−１からの発信は通信エラー等の要因が無い限りは通常どれかの基地局が受信する。したがって、ノードからの発信が一定時間どの基地局からも受信されない状態をイベントとして設定することにより、例えば監視対象者ＰＳ−１がノードＭＳＮ−１のスイッチをオフにしたり、ＭＳＮ−１を破壊する等により発信を止めた場合に、その状態を異常としてセキュリティシステムに通知するアクションを実行することができる。

また、個人情報から判断して本来一定時間の間に移動するはずの領域において、基地局間の移動時間が予め定めた値を超過した際にイベントを発生するように設定しておけば、監視対象者ＰＳ−１が迷っている、停止している等想定外の行動をとっていることが推定できる。

図２３は、基地局ＢＳＴの設置間隔が広い場合の例である。この場合は、まず監視対象者ＰＳ−１の装着しているノードＭＳＮ−１の無線到達エリアＣＡ−１の範囲に基地局ＢＳＴ−１が入り、ＭＳＮ−１とＢＳＴ−１の間で通信を行う。その後ＰＳ−１が移動し、進行方向に設置された次の基地局ＢＳＴ−２がノードＭＳＮ−１の無線到達エリアＣＡ−１の範囲に入るまでの間に、無線到達エリアＣＡ−１の範囲にいずれの基地局も存在しない状態になる場合がある。この状態でセンサノードＭＳＮ−１が信号を発信した場合は、どの基地局も該信号を受信しないため、監視対象者ＰＳ−１の所在が不明になる。このような場合には、監視対象者ＰＳ−１の移動方向や移動速度等の状態から行動を予測し、ＭＳＮ−１の無線到達エリアＣＡ−１の範囲に基地局ＢＳＴ−２が入る時間の範囲を推定し、その時間範囲の間にＭＳＮ−１からの発信を基地局ＢＳＴ−２が受信した場合は正常行動の範囲と判定するようにイベント発生条件を決める。これにより、次にノードからの発信を基地局が受信した際や、監視対象者が想定範囲の時間内に想定範囲の基地局の近傍に到達しなかった場合に、異常行動としてセキュリティシステムに通知するアクションを実行することが可能になる。

さらに正確に監視対象者ＰＳの状態を観測する方法としては、モバイルセンサノードＭＳＮに加速度センサや振動センサ、方位センサ、ジャイロセンサ等を装備する。加速度センサや振動センサからは、装着者の体の動きを計測することができるため、姿勢や、歩行動作を判定することができる。また、方位センサやジャイロセンサからは、監視対象者の体の向きの絶対値や変位を判定することができる。これらの組み合わせによって、監視対象者の移動速度、移動方向を判定すれば、監視対象者の行動を推定することができる。

また、名札ノードのクリップ部等にスイッチをつけてクリップの開閉を検知する着脱検知スイッチのオン／オフや、加速度センサで検出した加速度の変化から、名札ノードが外れたことを検出すれば、監視対象者が故意に名札ノードを外したことや、ノードが落下したことを検知することが可能になる。

図２４に、オフィスビルを訪問した人物の行動を追跡する例を示す。今、訪問者ＰＳ−１が図２２のリストの鈴木太郎氏であるとする。訪問者ＰＳ−１は、まず出入口を通過して正面受付で氏名、目的、行き先等の個人情報を伝える。受付では、名札型センサノードＭＳＮ−１のＩＤを訪問者ＰＳ−１の個人情報とリンクさせ、訪問者ＰＳ−１の胸等に装着したのち電源をＯＮにしてアクティブにする。この状態で訪問者ＰＳ−１は監視対象者としてシステムに登録される。監視対象者ＰＳ−１は、行き先である第２会議室に向かう。オフィスビル内の人ＰＳの行動モデルは、図２５に示したようなバインドリストによって規定される。監視対象者ＰＳ−１の行動は、図２２の個人情報リスト、および図２５の行動モデルに基づいて想定される。ここで、監視対象者ＰＳ−１が顧客で、訪問の目的が会議であるとすると、正面受付から第２会議室までの通常の経路は１階ロビー→中央エレベータ→２階ロビー→第２廊下→第２会議室の順、また想定所要時間は５分となる。この行動モデルに基づいて、図２１で示した方法により監視対象者ＰＳ−１の行動はモニタされる。セキュリティシステムは、想定行動からの逸脱をイベントとして登録し、イベント発生をアクションとして通知するようにアクション設定を行う。図２５の例では、正面玄関から第２会議室までの経路には、２階廊下入り口、および第２会議室入り口に通過ゲートがあり、該通過ゲートの通過は、セキュリティシステムに接続されているゲートモニタ用の人感センサが監視している。セキュリティシステムは、センサネットワークシステムが監視している監視対象者ＰＳ−１の行動と、通過ゲートの通過タイミングの情報を連動し、時間的な相関等に基づいて異常行動を検知してセキュリティ対応処理を決定して実行する。

想定行動からの逸脱イベントとしては、例えば下記のような条件を設定する。
・ 所定の所要時間を超過（どこかに寄った可能性あり）
・ 所定の所要時間より一定時間以上短い（走った可能性あり）
・ 所定の移動経路上の領域に想定時間範囲（Ｔ１からＴ２の間、T２＞T１）内に到達しなかった（想定経路を通らなかった）
所定の移動経路上の通過ゲートを想定時間範囲（Ｔ３からＴ４の間、T４＞T３）内に通過しなかった（想定経路を通らなかった）
・ 所定の移動経路以外の領域に到達した
・ 立ち入り制限区域に近づいた
セキュリティシステムでは、センサネットが上記のような異常行動を検出した場合には、所定のアクションを起動する。例えば、所定の所要時間を超過している場合、近隣地区のセキュリティレベルを一段階上げる、といった対応が考えられる。

なお、イベント発生条件設定時には、センサネットワークシステムのセンシング情報管理機能を利用して、例えば前回訪問時のイベント発生履歴や、同行者の行動情報との相違、さらには、センサネットワークシステムが管理する別の監視サイト訪問時のイベント発生履歴等を条件判定基準に加えても良い。

また、異常判定・予測に人の行動履歴を用いる例を示したが、加速度センサやその他各種センサを用いて行うことも可能である。

以上のように、本発明によれば、セキュリティシステムにおいて人の行動履歴を管理することが可能になるため、監視対象領域をよりきめ細かく監視し、迅速な対応を行うセキュリティサービスを提供することができる。また、監視される人にとってもストレスの少ない監視システムを実現できる。

センサネットワーク／アプリケーション協調システムの構成図である。 センサネットワークの機能ブロック図である。 無線センサノードＷＳＮの一例を示すブロック図である。 無線センサノードの動作状態を示すグラフで、時間と消費電流の関係を示す。 無線センサノード等の配置の一例を示す説明図である。 オブジェクトとセンサノードの測定データの関連を示すブロック図である。 センサ情報テーブルの説明図である。 分散データ処理サーバＤＤＳのイベントアクション制御部を示すブロック図である。 イベントテーブルの説明図である。 ディレクトリサーバＤＲＳのアクション制御部ＡＣＣのブロック図である。 アクションテーブルの説明図である。 分散データ処理サーバＤＤＳのイベントテーブルのエントリを示す説明図である。 ディレクトリサーバＤＲＳのアクションテーブルのエントリを示す説明図である。 単一のアクションの設定の流れを示すタイムチャートである。 単一のアクションの応答の流れを示すタイムチャートである。 センサネットワークＳＮＳシステムとセキュリティシステムＳＣＳを接続した場合の構成例である。 センサネットワークシステムＳＮＳに接続するセキュリティシステムＳＣＳの構成例である。 セキュリティシステムにおける処理の流れを説明する図である。 センサネットワークシステムとセキュリティシステムを協調させる場合の構成例である。 セキュリティ処理ランクの例である。 監視対象者の行動を判定する方法を説明する図である。 個人情報テーブルの例である。 基地局ＢＳＴの設置間隔が広い場合の監視対象者の行動を判定する方法を説明する図である。 オフィスビルを訪問した人物の行動を追跡する例である。 行動モデルのバインドリストである。

符号の説明

ＤＲＳ：ディレクトリサーバ、ＤＤＳ：分散データ処理サーバ、ＷＳＮ，ＭＳＮ，ＦＳＮ：センサノード、ＢＳＴ：基地局、ＭＭＧ： モデル管理部、ＭＴＢ：実世界モデルテーブル、ＮＷＫ：ネットワーク、ＡＰＳ：アプリケーションシステム、ＳＣＳ：セキュリティシステム、ＳＮＳ：センサネットワークシステム。

Claims (9)

1. センサネットワークシステムと、上記センサネットワークシステムを構成するネットワークを介して接続されるセキュリティシステムからなるシステムであって、
   上記セキュリティシステムは、
   サイトに設置される制御対象機器と、
   複数のセキュリティレベルそれぞれに上記制御対象機器の状態を予め対応づけ、上記制御対象機器の状態を制御する処理決定部と、上記サイトを訪問する人物の個人情報と行動モデルから想定される上記人物の行動からの逸脱をイベント発生条件とし、かつ、上記イベント発生時の通知をアクションとして上記センサネットワークシステムに設定する処理設定部と、を有する管制装置と、を有し、
   上記センサネットワークシステムは、
   上記サイトを訪問する人物に装着されセンサによりデータを取得するノードと、
   上記ノードが送信する上記データを受信する基地局と、
   上記イベント発生条件及び上記アクションを上記管制装置から受信し、上記基地局から送信されるデータが上記イベント発生条件を満たす場合、上記アクションとして上記管制装置に通知を行う第１のサーバと、を有し、
   上記処理決定部は、上記通知を受けると、上記イベント発生に応じた上記セキュリティレベルに対応する状態に上記制御対象機器を制御するシステム。
2. 請求項１において、
   上記センサネットワークシステムは、上記ネットワークを介して上記第１のサーバに接続される第２のサーバを有し、
   上記第２のサーバは複数の上記ノードから送信されるデータを格納し、
   上記第１のサーバは、上記データの格納先を示す格納先情報を記憶することで、上記第２のサーバに格納された上記データにアクセス可能とされるシステム。
3. 請求項１において、
   上記セキュリティレベルに応じて上記サイト内に配置された複数のノードの状態が特定
   されており、
   上記データが上記イベント発生条件を満たす場合、上記イベント発生に応じた上記セキュリティレベルに基づいて上記複数のノードの状態を制御するシステム。
4. 請求項１において、
   上記セキュリティシステムは、
   上記サイト内に設置されたセンシング機器と、
   上記センシング機器からの情報に基づき異常を判断する制御装置と、をさらに有するシステム。
5. 請求項１において、
   上記制御対象機器として監視カメラを含み、上記セキュリティレベルに応じて上記監
   視カメラの制御方法が変更されるシステム。
6. 請求項１において、
   上記ノードから送信されるデータには、上記ノードのＩＤが含まれ、
   上記第１のサーバには、上記基地局の設置場所の情報が予め登録されており、
   上記第１のサーバは、上記ノードのＩＤを検出した基地局の設置場所の情報から上記イベント発生条件を満たすか判定するシステム。
7. ノードと、上記ノードからデータを受信する基地局と、ネットワークを介して上記基地局と接続される第１のサーバとからなるセンサネットワークシステムと、上記ネットワークを介して接続され制御対象機器と管制装置を有するセキュリティシステムで実行されるサイト管理方法であって、
   上記制御対象機器はサイトに設置され、
   上記管制装置は、複数のセキュリティレベルそれぞれに上記制御対象機器の状態を予め対応づけ、上記制御対象機器の状態を制御し、さらに、上記サイトを訪問する人物の個人情報と行動モデルから想定される上記人物の行動からの逸脱をイベント発生条件とし、かつ、上記イベント発生時の通知をアクションとして上記センサネットワークシステムに設定し、
   上記ノードは上記サイトを訪問する人物に装着され、
   上記基地局は、上記ノードからのデータを上記第１のサーバに送信し、
   上記第１のサーバは、上記イベント発生条件及び上記アクションを上記管制装置から受信し、上記基地局から送信されるデータが上記イベント発生条件を満たす場合、上記アクションとして上記管制装置に通知を行い、
   上記管制装置は、上記通知を受けると、上記イベント発生に応じた上記セキュリティレベルに対応する状態に上記制御対象機器を制御するサイト管理方法。
8. 請求項７において、
   上記センサネットワークシステムは、上記ネットワークを介して上記第１のサーバに接続される第２のサーバを有し、
   上記第２のサーバは複数の上記ノードから送信されるデータを格納し、
   上記第１のサーバは、上記データの格納先を示す格納先情報を記憶することで、上記第２のサーバに格納された上記データにアクセス可能とされるサイト管理方法。
9. 請求項７において、
   上記ノードから送信されるデータには、上記ノードのＩＤが含まれ、
   上記第１のサーバには、上記基地局の設置場所の情報が予め登録されており、
   上記第１のサーバは、上記ノードのＩＤを検出した基地局の設置場所の情報から上記イベント発生条件を満たすか判定するサイト管理方法。

Images