JP2011198379A - センサネットワークシステム及びセンサネットワークのデータ処理方法 - Google Patents

Abstract

【課題】各ノードの動作フローをユーザの要求や状況に応じて動的に変更する。
【解決手段】クライアント２０５が、予め複数のノードに対する処理が設定されたスクリプトから下位ノードに対するスクリプトを抽出して下位ノードへ前記抽出したスクリプトを配布するステップ４１５と、スクリプトから自ノードに対する処理を実行するステップと、下位ノードが配布されたスクリプトを受信し、当該ノードに対する処理を実行するステップと、下位ノードがスクリプトから自ノードよりも下位のノードに対するスクリプトを抽出し、下位ノードに対するスクリプトが存在すれば前記下位ノードへ抽出したスクリプトを配布するステップ４１０と、を含んで、各ノードが実行するスクリプトにより、最も下位のセンサノードからのイベントを、中間ノードを経てクライアント２０５に送る。
【選択図】図２

Description

本発明は、ネットワークに接続した多数のセンサからの情報を利用する技術に関し、特に、地域に分散する多数のセンサにより情報を収集し、現況把握・異常発見・予測・最適化などの意思決定支援に利用されるセンサネットワークシステムに関する。

近年、多数のセンサノードから得られるセンシングデータを、ネットワークを通じて取得するセンサネットワークの技術が発展しつつある。センサネットワークは、センサが取得した情報を、ネットワークを通して離れた場所で利用するものであり、広域・多様な環境観測へ対応する必要がある。広域において多様な観測を行う場合、多種・多数のセンサノードが必要となる。これら全てのセンサノードの観測イベント（測定結果の通知）をそのままサーバで受け取ると、サーバに負荷集中が発生する。これを回避するため、サーバに配送されるイベントの情報集約・フィルタリングを行い、イベント数を削減する必要があった。そのため、センサノードやサーバにイベントハンドラを設置し、それぞれが協調してイベントの集約・フィルタリングを行う方法が知られている（非特許文献１〜３）。

センサネットワークでは、一般に、センサノードが発信し、それぞれのシステムに配送される情報はイベントと呼ばれ、またイベントを処理する機構はイベントハンドラと呼ばれる。センサネットワークの処理体系は、センサノードが主体となって、環境観測情報をサーバやWeb Service、クライアントへ配送し、それぞれが予め設定されたルールで処理を行っている。例えば、非特許文献１では、環境の変化を検知して所定の処理を実行するイベントハンドラが開示されており、予め設定したセンサノードに対するイベントハンドラを、ＳＱＬ（Structured Query Language）を拡張したスクリプト言語を用いて構成するものが開示される。

また、非特許文献２、３には、スクリプト言語によりセンサノードを制御する技術が開示されている。

Samuel Madden, Michael Franklin, Joseph Hellerstein, and Wei Hong. TinyDB: An Acquisitional Query Processing System for Sensor Networks. ACM TODS(2005)、「ＰＤＦ」、「平成１７年５月１２日検索」、インターネット＜URL:http://astragalus.lcs.mit.edu/madden/html/tinydb_tods_final.pdf＞ Philip Levis and David Culler、「Mate: A Tiny Virtual Machine for Sensor Networks」、Computer Science Division, University of California,Berkeley, California、Intel Research: Berkeley, Intel Corporation, Berkeley, California、「ＰＤＦ」、「平成１７年５月１２日検索」、インターネット＜http://www.cs.berkeley.edu/~pal/pubs/mate.pdf＞ A. Boulis, C.C. Han, and M. B. Srivastava、「Design and Implementation of a Framework for Efficient and Programmable Sensor Networks」、「ＰＤＦ」、「平成１７年５月１２日検索」、インターネット＜http://www.ee.ucla.edu/~boulis/phd/SensorWare-Mobisys03.pdf＞

上記従来例のイベントハンドラは、センサノードやサーバなどの各ノード上に実装されたプログラムであり、イベントハンドラの動作フローは運用前に決定され、運用中は固定であった。イベントハンドラの動作フローを変更するためには、ノード上に実装されたプログラムを再登録する必要があった。ノード上のプログラムのサイズは巨大であり、無線通信で送信できない場合もあるため、動作フローを変更するためにはノードを回収して有線通信でプログラムを交換する必要がある場合もあった。

ここで、センサネットワークを利用するユーザは、センサノードから収集した情報を様々な情報に加工して利用することができる。この場合、各ノードの動作フローを変更することで、ユーザの要求に応えることができる。しかしながら、各ノードの動作フローを変更するには、上記従来例のように多数のノードのプログラムを再登録する必要が生じてしまい、容易に動作フローを変更できない、という問題がある。

ここで、動作フローの変更が必要となる要因として、次の要因が考えられる。

第一の要因は、ユーザ目的の変化である。特定目的を想定した小規模センサネットワークではなく、複数の目的に利用可能な大規模センサネットワークの場合、一般にセンサネットワークの運用開始後に、複数のユーザ目的を実現するために複数の動作フローが決定される。また動作フローはユーザ目的の変化に合わせて動的に変化していく。上記従来例においては、センサネットワークの管理者が全てのユーザ目的の変化に対応して動作フローを変更していくことは困難であった。

第二の要因は、状況の変化である。たとえば移動体を監視するセンサネットワークにおいて、移動体が存在しないことが分かっているセンサノードが観測を行うことは無駄である。また温度センサノードの観測に基づきエアコンディショナーを起動するセンサネットワークにおいて、火災発生時に該温度センサノードが観測を行うことは無駄である。上記従来例の固定されたイベントハンドラでは、このような状況の変化に応じて動作フローを変更するのは困難であった。

そこで本発明は、上記問題点に鑑みてなされたもので、各ノードの動作フローをユーザの要求や状況に応じて動的に変更することを容易に行うことが可能なセンサネットワークを提供することを目的とする。

本発明は、観測した情報に基づいて上位のノードへイベントを送信する第１センサノードおよび第２センサノードと、下位のノードへ予め設定したコマンドを含むスクリプトを送信し、前記第１および第２センサノードからのイベントを受信するクライアントノードと、前記第１および第２センサノードからクライアントノードへの通信を取り次ぐ中間ノードと、を備えたセンサネットワークシステムにおいて、前記クライアントノードは、予め複数のノードに対する処理が設定されたスクリプトを実行し、下位のノードに対するスクリプトを抽出して前記下位ノードへ前記抽出したスクリプトを配布する第１のスクリプトマネージャを有し、前記中間ノードは、前記第１のスクリプトマネージャが配布したスクリプトを実行し、当該中間ノードに対する制御を実行し、下位のノードに対するスクリプトを抽出して当該ノードへ前記抽出したスクリプトを配布する第２のスクリプトマネージャを有し、前記第１および第２センサノードは、各々前記第２のスクリプトマネージャが配布したスクリプトを実行することで観測した情報に基づくイベントを上位のノードに送信する第３のスクリプトマネージャを有し、前記第２のスクリプトマネージャから前記第１センサノードに配布された第１スクリプトと、前記第２センサノードに配布された第２スクリプトは、異なるスクリプトである。

したがって、本発明は、各ノードで分散してイベントのハンドリングを行う動作フローを、ひとつのスクリプトで制御できる。これにより、複数存在し、一般化できず、動的に変化していくユーザ目的に対応して動的に変更できるため、単一のセンサネットワーク上に多様なユーザ目的を反映することができる。このため設置・メンテナンス費用を複数のユーザで費用分担できるため、広域環境を観測する大規模センサネットワークインフラ基盤が実現できる。

また本発明により、分散イベントハンドリングの動作フローを、動的に変化していく状況に対応して動的に変更できるため、あらかじめ固定したイベントハンドリングを行う場合に比べ、無駄な処理を行う必要がなくなり、その結果配送するイベント数を削減することができるため、サーバへの負荷集中を減少させることができる。また各ノードの処理を不要な時に停止することができるため、各ノードの消費電力を抑えることができる。

本発明の第１の実施形態を示すセンサネットワークのブロック図である。 同じく第１実施形態の分散イベントハンドリングを実現する本発明のセンサネットワークの各ノードの主要な機能のブロック図である。 ノード間通信の一例を示す説明図である。 同じく第１実施形態におけるセンサノードの機器構成図である。 同じく第１実施形態におけるのルータノードの機器構成図である。 同じく第１実施形態におけるサーバの機器構成図である。 同じく第１実施形態におけるクライアントの機器構成図である。 同じく第１実施形態におけるスクリプトマネージャと上位アプリケーションとの接続インタフェースのブロック図である。 同じく第１実施形態におけるスクリプトマネージャの内部構造図である。 同じく第１実施形態におけるタグツリーの構造の説明図である。 同じく第１実施形態におけるスクリプトの基本的な実行順序の説明図である。 同じく第１実施形態における非同期コマンドを含むスクリプトの実行順序の説明図である。 同じく第１実施形態における並列コマンドを含むスクリプトの実行順序の説明図である。 同じく第１実施形態におけるpostActionインタフェースのアルゴリズムを説明する処理の流れ図（ＰＡＤ図）である。 同じく第１実施形態におけるpostCommandインタフェースのアルゴリズムを説明する処理の流れ図（ＰＡＤ図）である。 同じく第１実施形態におけるparseCommandインタフェースのアルゴリズムを説明するＰＡＤ図である。 同じく第１実施形態におけるonEventインタフェースのアルゴリズムを説明する処理の流れ図（ＰＡＤ図）である。 同じく第１実施形態におけるイベント待機コマンドの動作フローを説明するシーケンス図である。 同じく第１実施形態における通信コマンドの動作フローを説明するシーケンス図である。 同じく第１実施形態におけるイベント待機コマンドと通信コマンドを組み合わせた場合の動作フローを説明するシーケンス図である。 同じく第１実施形態における並列コマンドｏｒおよびａｎｙの動作を説明するスクリプトの説明図である。 同じく第１実施形態における圧縮スクリプトの構造の説明図である。 同じく第１実施形態における圧縮スクリプトに対するpostCommandインタフェースのアルゴリズムを説明する流れ図（ＰＡＤ図）である。 同じく第１実施形態における圧縮スクリプトに対するparseCommandインタフェースのアルゴリズムを説明する流れ図（ＰＡＤ図）である。 本発明の第２の実施形態を示し、二次イベント識別子問題を説明するシステム構成図である。 本発明の第３の実施形態を示し、ルール数爆発問題を説明するシステム構成図である。 同じく本発明の第３の実施形態を示し、ルール数爆発問題を説明するロジック記述の説明図である。 本発明の第４の実施形態を示し、Ａｄ−Ｈｏｃ問題を説明するシステム構成図である。 同じく本発明の第４の実施形態を示し、スクリプトの変更例の説明図である。 本発明の第５の実施形態を示し、センサノード上のスクリプトの説明図である。 本発明の第６の実施形態を示し、ハードウェア割り込みを利用したセンサノードの要部の構成図である。 本発明の第７の実施形態を示し、平時・緊急時の両方で利用可能なセンサネットワークの構成図である。 本発明の第８の実施形態を示し、Ａｄ−Ｈｏｃなセンサネットワークを説明する図である。 同じく本発明の第８の実施形態を示し、再起構造を用いたスクリプトの説明図である。 本発明の第９の実施形態を示し、本発明における名札ノードのユーザインタフェースの説明図である。 本発明の第１０または第１１の実施形態を示し、センサネットワークの構成図である。 本発明の第１２の実施形態を示し、スクリプトを生成するためのユーザインタフェースを示す図である。 同じく本発明の第１２の実施形態を示し、ユーザ要求の宣言型言語のスクリプトを実際の動作が記述された手続き型言語のスクリプトに変換する例の説明図である。 本発明の第１３の実施形態を示し、プロジェクト管理システムの一例の説明図である。

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

図１は、本発明を適用するセンサネットワークの一例を示すブロック図である。

センサネットワークは、環境に分散する多数のセンサノード２０１、２０６、２０７において環境情報を観測し、無線通信または有線通信で接続されたルータノード２０２を経由して観測情報を集約・配送し、中央のサーバ２０３において観測情報を収集することにより、人間の意思決定を支援するシステムである。サーバ２０３に収集された観測情報は、ユーザの目的に応じて存在する複数のWebサービス（WEBサーバ）２０４に配送され、最終的にユーザ端末であるクライアント２０５に配送される。またセンサノード２０２と同様に環境に分散する多数のアクチュエータノード２０８が環境を制御する場合もある。なお、本発明では、センサネットワークを構成するセンサノード２０１、ルータノード２０２、サーバ２０３、Web Service２０４、クライアント２０５、アクチュエータノード２０８を一般的に「ノード」と呼ぶ。

センサノード２０１、２０６、２０７は、温度センサや湿度センサなどのセンサや、個人を識別する識別子を有し、ルータノード２０２、２０９に接続される。ルータノード２０２には複数のセンサノード２０１、２０６が接続され、これらセンサノードからの観測情報を収集する。ルータノード２０２は、配下のセンサノード２０１、２０６から収集した観測情報をサーバ２０３に送る。また、ルータノード２０９には、センサノード２０７とアクチュエータノード２０８が接続され、センサノード２０７から収集した観測情報をサーバ２０３に送り、サーバ２０３からの指令に基づいてアクチュエータノード２０８を制御する。アクチュエータノード２０８はクライアント２０５のユーザなどが設定した条件に基づいて動作するもので、例えば、エアコンディショナなどで構成されている。

サーバ２０３は、ルータノード２０２、２０９から送られた観測情報を収集し、複数のWEBサービス２０４を介してクライアント２０５に観測情報や観測情報に基づく通知を送信する。

センサネットワークの主要なアプリケーションでは、環境が変化したタイミングを知ることが重要となる。そのためセンサネットワークの処理体系は、センサノード２０１が主体となって、環境観測情報をサーバ２０３やWEBサービス２０４、クライアント２０５へ配送し、それぞれがあらかじめ設定されたルールで処理を行うという方式を取る。一般に、センサノード２０１が発信し、それぞれのシステムに配送される情報はイベントと呼ばれ、またイベントを処理する機構はイベントハンドラと呼ばれる。

イベントハンドラでの処理は、イベント（Event）を受け取り、条件判定（Condition）を行い、それに対応したアクション（Action）を行う、という三段階から構成される。これは一般にＥＣＡ（Event-Condition-Action）モデルと呼ばれる。なお一般にアクションとは、イベントと対比される概念であり、ノードへ与えられる処理要求のことである。アクションの種類としては、新たなイベントを発行する、アクチュエータノード２０８の制御を行うなどがある。

また、本実施形態では、センサノード２０１側を下位のノードとし、クライアント２０５を上位側のノードとする。例えば、センサノード２０１は所属する上位のノードであるルータノードに観測情報に基づくイベントまたは結果を通知し、ルータノードは所属する上位のノードであるサーバ２０３にイベントを通知し、サーバ２０３はｗｅｂサービスを介して上位のノードであるクライアント２０５にイベントを通知する。

また、下位のセンサノード２０１と上位のクライアント２０５の間に存在するルータノード２０２、サーバ（サーバノード）２０３、ｗｅｂサービス（ｗｅｂサーバノード）２０４は、中間ノードとしてセンサノード２０１とクライアント２０５との通信を中継し、またクライアント２０５からのスクリプトを実行する。

＜センサネットワークのノードとスクリプトの構成＞
図２は、センサネットワークにおいて分散イベントハンドリングを実施する機能要素のブロック図である。ここで、分散イベントハンドリングとは、センサネットワーク上のノード間のイベントの通知を、各ノードが分散して実行することである。つまり、イベントの発生を通知するノードが、直接、次の階層のノードにイベントを通知するものである。

図２において、センサノード２０１、ルータノード２０２、サーバ２０３、クライアント２０５のうち、イベントハンドリングを行いたいノードに、それぞれイベントハンドラのかわりに本発明のスクリプト実行エンジンであるスクリプトマネージャ４０４、４０９、４１４、４１９を設置し、分散イベントハンドリングを行う。なお、図２では、イベントハンドリングを行わないWEBサービス２０４は省略した。また、図１に示したセンサノード２０６、２０７やアクチュエータノード２０８、ルータノード２０９、他のクライアント２０５も同様に構成される。

センサネットワークに分散イベントハンドリングの動作フローを設置したいユーザ４２０は、クライアント２０５で動作フロー全体を定義するスクリプト４１８を記述し、スクリプトマネージャ４１９に実行を依頼する。スクリプト４１８は内部に再帰的に各ノードにおけるイベントハンドリングを行う部分スクリプト４１３、４０８、４０３を含む。

クライアント２０５のスクリプトマネージャ４１９は、スクリプト実行の過程で他のノード（サーバ２０３）４１２のスクリプトマネージャ４１４に部分スクリプト４１３を送信し、スクリプトの実行を依頼するアクション４１５を実行する。これを再帰的に繰り返す事により、全てのノード２０１、２０２、２０３、２０５にスクリプト４０３、４０８、４１３、４１８を配布することができる。

つまり、スクリプト４１８には、センサネットワークの階層に応じた順位で多のノードのスクリプトが入れ子状に配置される。クライアント２０５で実行されるスクリプト４１８は、サーバ２０３で実行するためのスクリプト４１３が内包される。このスクリプト４１３には、ルータノード２０２で実行するためのスクリプト４０８が内包され、さらにスクリプト４０８には、センサノード２０１で実行するためのスクリプト４０３が内包される。

クライアント２０５のスクリプトマネージャ４１９がスクリプト４１８を実行すると、上記のようにスクリプト４１３を抽出してサーバ２０３に送信する。サーバ２０３では、スクリプトマネージャ４１４が受信したスクリプト４１３を実行すると、内包されたスクリプト４０８を抽出してルータノード２０２に送信する。ルータノード２０２では、サーバ２０３から受信したスクリプト４０８をスクリプトマネージャ４０９が実行すると、内包されていたスクリプト４０３を抽出してセンサノード２０１に送信する。センサノード２０１では、スクリプトマネージャ４０４がスクリプト４０３を実行する。

このように、クライアント２０５で定義された入れ子状のスクリプトは、各ノードで順次抽出されてから送信され、各ノードのスクリプトマネージャで実行することができ、一つのスクリプトを定義すれば、複数のノードを制御すうことができる。ここでは、ひとつのセンサノード２０１とひとつのルータノード２０２に対して部分スクリプト４０８、４０３を配布し実行させる例を示したが、一つのスクリプトの中に、複数のセンサノード２０１に対するスクリプトや複数のルータノード２０２に対するスクリプトを内包することで、一つのスクリプトにより多数のノードを制御することが可能となるのである。

センサノード２０１の観測イベント４０２は、センサノード２０１のスクリプトマネージャ４０４によりスクリプト４０３のルールに従い判定され、スクリプト４０３のコマンド実行完了イベント４０５としてルータノード２０２に配送される。

以降順番にコマンド実行完了イベント４１１、４１６としてルータノード２０２からサーバ２０３へ、サーバ２０３からクライアント２０５へと上位のノードに送信される。

＜スクリプトの構成＞
図３は、上記図２のノード間で行われる処理の説明図である。図３においては、通信元ノード１０１のスクリプト１０２と、通信先ノード１０７のスクリプト１１７の関係について示したもので、スクリプト１０２は、例えば、図２のクライアント２０５のスクリプト４１８であり、スクリプト１１７は、例えばサーバ２０３のスクリプト４１３である。

本発明のスクリプト実行エンジンであるスクリプトマネージャは、lisp等の関数型言語と同様な表記法である、コマンドの木構造で表記されたスクリプト１０２を受け付け、該スクリプトをインタプリタ方式で実行する。

基本的なコマンド実行順序ルールは、関数型言語と同様、通信元ノード１０１の親コマンド１０３の実行前に全ての子コマンド（１０４、１０５）をその出現順に実行し、コマンド返戻データを親コマンド１０３の引数とするという処理体系を持つ。

さらに本発明による新たなコマンド実行順序ルールとして、非同期コマンドを導入する。非同期コマンド実行時は非同期コマンド処理主体に、コマンド実行要求１１２として、
（１）実行中のスクリプトを一意に識別するアクションＩＤ１０９と、
（２）スクリプト内で該非同期コマンドを一意に識別するコマンドＩＤと、
（３）該非同期コマンドを根とする部分スクリプト１０６を部分スクリプト１１１として通信先ノード１０７に送信し、通信先ノード１０７で部分スクリプト１１１の実行を依頼し、スクリプト１０２を通信元ノード１０１で保存してスクリプトを一時停止する機能と、コマンド実行完了イベント１１６として返戻データ１１５と共に該アクションＩＤ１１３と該コマンドＩＤ１１４を通信元ノード１０１で受信し、該コマンドＩＤ１１５で識別されるコマンド位置から該実行順序ルールに基づき処理を再開する機能を用いることにより、非同期な処理を可能とする。

特定イベントを待ち受けるイベントハンドラを、該非同期コマンドから呼び出される非同期コマンドの処理主体として実装し、非同期コマンド実行時に各ノード上に存在するＰｕｂ／Ｓｕｂモデル（Publish/Subscribeモデル）の実装であるイベントパブリッシャにイベント配送予約を行い、イベントが配送された時点で非同期コマンドの返戻とすることにより、「スクリプトによるイベントハンドラ」が実現できる。

また、通信先ノード１０７への通信機能を、該非同期コマンドから呼び出される非同期コマンドの処理主体として実装し、通信先ノード１０７への通信内容として、該非同期コマンド処理主体への送信内容であるアクションＩＤ１０９、コマンドＩＤ１１０、１１１に加え、通信元ノードＩＤ１０８を加えて実装することにより、通信元ノード１０１が通信先ノード１０７へスクリプト実行依頼を行う機能が実現できる。通信先ノードへ通信する部分スクリプト１０６として、上述した「スクリプトによるイベントハンドラ」を送信することにより、単一のスクリプトから複数のノードへイベントハンドラを配布することができる。

ユーザの入力したスクリプトにより複数のノードへイベントハンドラを配布・登録することができる事から、ユーザ目的の変化に応じてセンサネットワークの動作フローを動的に変更することができる。また各ノードのスクリプトマネージャがスクリプトに従ってイベントハンドラを配布することができる事から、たとえばあるイベントの条件判定の結果、新たなイベントハンドラを配布・登録するように、状況に応じてセンサネットワークの動作フローを動的に変更することができる。

なお、各ノード間で通信するノードＩＤ１０８は、センサネットワーク全体を管理するサーバ２０３がセンサネットワーク上で一意の識別子として決定し、管理するものである。

また、アクションＩＤ１０９、１１３は、後述するスクリプトマネージャのアクションハンドラリスト９０２によりアクションハンドラリスト内で一意である識別子として付与される。また、コマンドＩＤ１１０、１１４は、スクリプトの処理を依頼されたタイミングでスクリプトマネージャのアクションハンドラ１００５により付与される。

＜センサネットワークの構成要素の詳細＞
次に、図２に示したセンサネットワークの各構成要素の詳細について、図４〜図７に基づいて以下に説明する。

＜センサノードの詳細＞
図４は、センサノード２０１の機器構成を示すブロック図である。なお、図示はしないが、図１に示したセンサノード２０６、２０７も同様に構成される。

センサノード２０１は、環境を観測してイベントを発行するノードであり、メモリ５０２、ＣＰＵ５０３、データの長期記録を行うフラッシュメモリ５０４、環境の観測を行うセンサデバイス５０５、通信を行う通信デバイス５０６、通信コネクタ５０７から構成される。センサノード２０１の起動時に、フラッシュメモリ５０４に記録されているプログラム（４０４、５０９〜５１３）をメモリ５０２上に読み込み、ＣＰＵ５０３で実行することにより処理を行う。

メモリ５０２上に読み込まれるプログラムは、本発明のスクリプト実行エンジンであるスクリプトマネージャ４０４、スクリプトを構成するコマンドの処理主体の集合であるコマンドライブラリ５０９、センサデバイス５０５を利用して観測を行うセンサドライバ５１０、センサドライバ５１０とスクリプトマネージャ４０４を接続するセンサアダプタ５１１、通信デバイス５０６やネットワークコネクタ５０７を利用して通信を行う通信ドライバ５１２、通信ドライバ５１２とスクリプトマネージャ４０４を接続する通信アダプタ５１３、ユーザ目的に応じて適切に設置されるアプリケーション５１４から構成される。

通信デバイス５０６およびネットワークコネクタ５０７は、特定の識別子を持つ他のノードと双方向通信が行えるものであればよく、例えば有線の通信規格Ethernet（登録商標）、無線の通信規格Blue Tooth、IEEE802.15.4、ZigBeeなどを実装するものが挙げられる。

センサデバイス５０５は、例えば温度センサ、湿度センサ、照度センサ、ボルトの緩みを検知するひずみセンサ、椅子への着座や扉の開閉を検知する圧力センサ、人の存在を検知する赤外線センサ、脈拍を検知する赤外線センサなどが挙げられる。また、図３６に示す名札ノードもセンサノード２０１の一種であり、ユーザのボタン入力３６０３、３６０４、３６０５を検知するスイッチがセンサデバイス５０５となる。

また、図７に示すクライアント２０５もセンサノード２０１の一種である。キーボード８０８やマウス８０９がセンサデバイス５０５となり、ユーザが現在操作を行っているかどうかで在席確認を行う、現在操作しているアプリケーション名を検知することでどの仕事をしているなどの情報を観測することができる。

図１に示したアクチュエータノード２０８の機器構成図は、図５に示すセンサノード２０１の機器構成図から、センサアダプタ５１１、センサドライバ５１０、センサデバイス５０５をそれぞれアクチュエータアダプタ、アクチュエータドライバ、アクチュエータデバイスに置き換える以外は同様なので割愛する。アクチュエータデバイスの例としては、エアコンディショナー、アラーム、スピーカ、減光機能つきライトなどが挙げられる。

センサノードとアクチュエータノードを組み合わせたノードとして、自律移動型ロボットが挙げられる。たとえば観測対象に向かって移動するロボット、観測情報により移動する掃除機ロボットなどが挙げられる。本発明を利用することにより、サーバ２０３からのスクリプトにより、その挙動を自由に変更することができる。また自律移動によりルータノードとの接続が一時的に中断した場合でも、センサデバイス５０５からの入力を元にスクリプトマネージャ４０４で動作の判断を行い、アクチュエータデバイスを利用して移動を行うことができる。

＜ルータノードの詳細＞
図５は、ルータノード２０２の機器構成を示すブロック図である。なお、図１に示したルータノード２０９も同様に構成される。

ルータノード２０２は、通信を中継するノードであり、メモリ６０２、ＣＰＵ６０３、データの長期記録を行うフラッシュメモリ６０４、通信を行う通信デバイス６０６、通信コネクタ６０７から構成される。ルータノード６０１起動時に、フラッシュメモリ６０４に記録されているプログラム（４０９、６０８〜６１０）をメモリ６０２上に読み込み、ＣＰＵ６０３で実行することにより処理を行う。

メモリ上に読み込まれるプログラムは本発明のスクリプト実行エンジンであるスクリプトマネージャ４０９、スクリプトを構成するコマンドの処理主体の集合であるコマンドライブラリ６０８、通信デバイス６０５を利用して通信を行う通信ドライバ６０９、通信ドライバ６０９とスクリプトマネージャ４０９を接続する通信アダプタ６１０、ユーザ目的に応じて適切に設置されるアプリケーション６１１から構成される。

無線通信と有線通信を接続するゲートウェイノードもルータノードの一種である。この場合、ネットワークアダプタ６１０、ネットワークドライバ６０９、ネットワークデバイス６０５、ネットワークコネクタ６０６は有線用、無線用の２組を持つ構成となる。また、無線通信を行うルータノード２０２は、「新たなノードと接続した」、「接続しているノードが離脱した」というイベントを検知するセンサノード２０１と捉えることもできる。例えば図３６に示す名札ノード３６０１のように、人間が携帯するセンサノードは、常に固定されたルータノードと接続されている保障はない。この性質を利用して、名札ノードと接続したルータノードは、「名札ノードを携帯している人物が到来した」、名札ノードの離脱を確認したルータノードは、「名札ノードを携帯している人物が去った」というイベントを観測することができる。

＜サーバノードの詳細＞
図６は、サーバ２０３の機器構成を示すブロック図である。

図６において、サーバ２０３は、観測情報の収集・蓄積・配信を行うノードであり、メモリ７０２、ＣＰＵ７０３、データの長期記録を行うハードディスク７０４、通信を行う通信デバイス７０５、通信コネクタ７０６から構成される。サーバ２０３の起動時に、ハードディスク７０４に記録されているプログラム（４１４、７０８〜７１２）をメモリ７０２上に読み込み、ＣＰＵ７０３で実行することにより処理を行う。なお、ハードディスク７０４に代わって、ＳＡＮやＮＡＳのストレージ装置を用いるようにしても良い。

メモリ７０２上に読み込まれるプログラムは本発明のスクリプト実行エンジンであるスクリプトマネージャ４１４、スクリプトを構成するコマンドの処理主体の集合であるコマンドライブラリ７０８、通信デバイス７０５を利用して通信を行う通信ドライバ７０９、通信ドライバ７０９とスクリプトマネージャ４１４を接続する通信アダプタ７１０、ユーザ目的に応じて適切に設置されるアプリケーション７１１、データベース７１２から構成される。

ネットワークアダプタ７１０において、クライアント２０５に様々な手段でイベントを転送するため、様々なプロトコルを実装することが考えられる。例えば、ＳＩＰ（Session Initiation Protocol）でポップアップ通知やデータ転送を行う、ＳＭＴＰ（Simple Mail Transfer Protocol）でメールの送信を行う、ＨＴＭＬ（Hyper Text Markup Language）やＸＭＬ等で記述されたイベントをＨＴＴＰ（Hyper Text Transfer Protocol）で送信する、などが考えられる。また上記プロトコルを、逆にクライアントからサーバへスクリプトの転送・実行依頼を行う経路として使用することもできる。WEBサービス（WEbサーバ）２０４の機器構成図は図６に示すサーバ２０３の機器構成図と同様なので割愛する。

＜クライアントノードの詳細＞
図７は、クライアント２０５の機器構成を示すブロック図である。

クライアント２０５は、ユーザとのインタフェースとしてユーザからの要求入力および結果やイベントの提示を行うノードであり、メモリ８０２、ＣＰＵ８０３、データの長期記録を行うハードディスク８０４、通信を行う通信デバイス８０５、通信コネクタ８０６、ユーザに結果やイベントの提示を行うディスプレイ８０７、ユーザからの要求入力を受け付けるキーボード８０８やマウス８０９から構成される。クライアント２０５起動時に、ハードディスク８０４に記録されるプログラム（４１９、８１１〜８１４）をメモリ８０２上に読み込み、ＣＰＵ ８０３で実行することにより処理を行う。

メモリ８０２上に読み込まれるプログラムは本発明のスクリプト実行エンジンであるスクリプトマネージャ４１９、スクリプトを構成するコマンドの処理主体の集合であるコマンドライブラリ８１１、通信デバイス８０５を利用して通信を行う通信ドライバ８１２、通信ドライバ８１２とスクリプトマネージャ４１９を接続する通信アダプタ８１３、ユーザ目的に応じて適切に設置されるアプリケーション８１４から構成される。

＜スクリプトマネージャの概要＞
図８を用いて、本発明のスクリプトマネージャ９０１と上位アプリケーション９０５との接続インタフェースについて説明する。図８のスクリプトマネージャ９０１は、図２のスクリプトマネージャ４０４、４０９、４１４、４１９に相当するものである。なおここで上位アプリケーションとは、本発明のスクリプトマネージャ９０１を使用する全てのプログラムのことを指す。上位アプリケーションの例は、図２におけるスクリプトマネージャ４０４と接続するコマンドライブラリ５０９、センサアダプタ５１１、通信アダプタ５１３、図６におけるアプリケーション７１１、データベース７１２、である。

上位アプリケーション９０５の中心となるプログラムブロックを便宜上、中核ロジック（Application Core Logic）９０６と呼ぶことにする。図７のクライアント２０５などでは、ユーザとのやりとりを行うユーザインタフェース９０７を持つ中核ロジック９０６も存在する。

スクリプトマネージャ９０１は、実行中のスクリプトを複数管理するアクションハンドラリスト９０２、上記Ｐｕｂ／Ｓｕｂモデルの実装であるイベントパブリッシャ９０３、スクリプトで実行可能なコマンドを管理するコマンドハンドラリスト９０４から構成される。

スクリプトマネージャ９０１と上位アプリケーションの関係は、
（１）上位アプリケーションがスクリプトマネージャ９０１に処理を依頼する、
（２）スクリプトマネージャ９０１が上位アプリケーションに処理を依頼する、
の二種類に大別される。

上位アプリケーションがスクリプトマネージャ９０１に処理を依頼する場合、postActionインタフェース９１０と、onEventインタフェース９１２を使用する。上位アプリケーションは、スクリプトを引数にしてpostActionインタフェース９１０を呼び出すことにより、スクリプトが実行される。同期アクションの実行結果はこの返戻として、また非同期アクションの実行結果はあらかじめ登録しておいたイベントハンドラ９０８にonEventインタフェース９１２で返戻される。

スクリプトマネージャ９０１が上位アプリケーションに処理を依頼する場合、addCommandインタフェース９１３とpostCommandインタフェース９１４を使用する。addCommandインタフェース９１３はスクリプトマネージャ９０１に新たなコマンドと、処理主体であるコマンドハンドラ９０９を登録する。スクリプトの文脈で登録されたコマンドが出現した場合、スクリプトマネージャ９０１はコマンドハンドラ９０９のpostCommandインタフェース９１４を経由して上位アプリケーションに処理を依頼する。

スクリプトマネージャ９０１内にはＰｕｂ／Ｓｕｂモデルの実装であるイベントパブリッシャ９０３を含み、onEventインタフェース９１１でスクリプトマネージャ９０１にイベントを送信する機能と、subscribeインタフェース９１５でスクリプトにイベント配送予約を行うことによりonEventインタフェース９１２でイベントを配送する機能を有する。

＜スクリプトマネージャの詳細＞
図９を用いて、図８のスクリプトマネージャ９０１の内部構造を説明する。

スクリプトマネージャ９０１は内部にアクションハンドラリスト９０２、コマンドハンドラリスト９０４、イベントパブリッシャ９０３を持つ。

アクションハンドラリスト９０２は実行中のスクリプトを複数管理するブロックである。アクションハンドラリスト９０２は、０個以上のアクションハンドラ１００５を格納する。アクションハンドラ１００５は、上位アプリケーションから処理を依頼されたスクリプトをコマンド単位の木構造に展開したタグツリー１００８として管理する。またアクションハンドラ１００５は、アクションハンドラリスト９０２内でアクションハンドラを一意に識別するための識別子であるアクションＩＤ１００７を持つ。アクションＩＤ１００７はスクリプトの処理を依頼されたタイミングでアクションハンドラリスト９０２により付与される。

コマンドハンドラリスト９０４は、スクリプトマネージャ９０１に登録されている実行可能なコマンド群を管理するブロックである。コマンドハンドラリスト９０４は、０個以上のコマンドハンドラ１００９を格納する。コマンドハンドラ１００９はスクリプトを構成するコマンドに対する処理主体である。コマンドハンドラ１００９はコマンド名を一意に表す識別子をコマンドネーム１０１１に持つ。

イベントパブリッシャ９０３は、０個以上のイベントハンドラ１０１２を格納する。イベントハンドラ１０１２は、イベントパブリッシャ９０３に予約されたイベントに対する応答の処理主体である。なお、本発明における後述する図１２で説明される非同期コマンドのコマンド実行完了イベントを受け取る特別なイベントハンドラとして、アクションハンドラ１００５を格納する場合もある。

図１０を用いて、上記図９アクションハンドラ１００５のタグツリー１００８の構造について説明する。

タグツリー１００８は、Ｗ３Ｃ（World Wide Web Consortium）の提唱するＸＭＬ（eXtended Markup Language）の標準モデルの一つであるＤＯＭ（Document Object Model）と類似した構造を持つ。

タグツリー１００８は、タグ１１０１を根とし、０個以上の子を再帰的に持つ構造を取る。例えば、根タグ１１０１の子はタグ１１０２および１１０３であり、タグ１１０３の子はタグ１１０４および１１０５である。

各タグは属性として、図９のアクションハンドラ１００５内でタグの位置を一意に識別するための識別子であるコマンドＩＤ１１０６と、コマンドやデータの名前を表すタグネーム１１０７を持つ。コマンドＩＤ１１０６は、スクリプトの処理を依頼されたタイミングでアクションハンドラ１００５により付与される。

図９のスクリプトマネージャ９０１のpostActionインタフェース９１０を呼び出し、スクリプトの実行を依頼することにより、アクションハンドラリスト９０２内で新たにアクションハンドラ１００５が作成され、スクリプトはタグツリー１００８に展開される。アクションハンドラ１００５は図１０に示すタグツリー１００８の根タグ１１０１（図１０参照）から後述する実行順序でタグを解析し、タグネーム１１０７とコマンドハンドラリスト９０４内の、コマンドネーム１０１１と一致するコマンドハンドラ９０４のpostCommandインタフェース９１４を呼び出すことによりコマンドの処理を依頼する。
＜スクリプトの体系＞
次に、本発明のスクリプトマネージャ９０１が受け入れるスクリプトの言語体系を説明する。本発明のスクリプトの表記法は、再帰的な階層構造である。以降の説明では、スクリプトをＸＭＬで表現するが、再帰的な階層構造を持つものであれば、lispやschemeなどのＳ式表現、ConciseXMLなどのＸＭＬの亜流表現など、他の構造でもよい。

初めに、本スクリプトの書式をＥＢＮＦ（Extended Backus Naur Form:ISO/IEC 14977）記法で定義する。
［式１］ ＜Script＞：：＝＜CommandLine＞
［式２］ ＜CommandLine＞：：＝＜Command＞ ＜Param＞＊
［式３］ ＜Param＞：：＝＜CommandLine＞｜＜Data＞
［式４］ ＜Command＞：：＝＜SyncCommand＞｜＜AsyncCommand＞
［式５］ ＜Command＞：：＝＜SequentialCommand＞｜＜ParallelCommand＞
これらから分かるとおり、スクリプト＜Script＞は単一のコマンド＜Command＞を根とし、その引数＜Param＞として０個以上のコマンド＜Command＞やデータ＜Data＞を持ち、これが再帰的に繰り返される、という構造で表現される。

またコマンドは、同期コマンド＜SyncCommand＞と非同期コマンド＜AsyncCommand＞のいずれか、逐次コマンド＜SequentialCommand＞と並列コマンド＜ParallelCommand＞のいずれかに分類される。

同期コマンドと非同期コマンドは、コマンド自身の処理が同期処理か非同期処理かによる分類である。

同期コマンドは、同期処理を行うコマンドである。すなわち、コマンドの処理が終了するまで制御を返さない。同期コマンドの例は、加算コマンド、乗算コマンドなどの四則演算コマンドである。

非同期コマンドは、非同期処理を行うコマンドである。すなわち、コマンドの処理が終了する前に制御が返される。非同期コマンドは、コマンド処理時間が無視できないほど長い、あるいは不定である、あるいはコマンド処理結果が返戻されない可能性がある場合に用いられる。非同期コマンドの例は、統計処理などの長時間の計算を行うコマンド、ユーザに問合せを行い、返答の入力を待つコマンド、スクリプトによるイベントハンドラの実装であるイベント待機コマンド、通信コマンドなどである。非同期コマンド処理主体からの非同期処理の返戻は、コマンド実行完了イベントとして到来し、図９のアクションハンドラ１００５のonEventインタフェース１００６を介してアクションハンドラ１００５に返される。

逐次コマンドと並列コマンドは、該コマンドの子に位置するコマンド群を並列実行するか否かによる分類である。

逐次コマンドは、並列実行を行わない。すなわち、該コマンドのある子コマンドにおいて、該子コマンド自身あるいはその子孫コマンドが非同期コマンドである場合、該非同期コマンドのコマンド実行完了イベントが到来するまで処理を停止する。

並列コマンドは、並列実行を行う。すなわち、該コマンドのある子コマンドにおいて、該子コマンド自身あるいはその子孫コマンドが非同期コマンドである場合、該非同期コマンドのコマンド実行完了イベントの到来を待たずに該子コマンドの弟コマンドの実行を行う。

図８のaddCommandインタフェース９１３を利用することにより、スクリプトマネージャ９０１の作成者、センサネットワークの管理者、ユーザのいずれかあるいは全てにより、コマンドを自由に拡張することができる。

＜スクリプトの実行順序＞
＜１．基本的な実行順序＞
次に、図１１〜図１４を用いて、スクリプトの実行順序について説明する。

初めに、図１１の例を用いて、同期コマンド、逐次コマンドのみで構成されたスクリプトの実行順序について説明する。同期コマンド、逐次コマンドのみで構成されたスクリプトの実行順序は、関数型言語と同様に、以下のルールに従う。
［rule １］ スクリプトは根（親）のコマンドから実行を開始する。
［rule ２］ コマンドは、子コマンドを全て実行した後、実行結果を引数として自分自身を実行する。
［rule ３］ コマンドは、コマンド実行後、自分自身を実行結果であるデータと置換する。
［rule ４］ 根コマンドが終了した場合、スクリプトは終了する。

このルールに従うことにより、図１１のスクリプトは以下のステップで実行される。
［step １］ 初めに根コマンド１２０１の実行を試みる。コマンド１２０１は子１２０２および１２０３を持つので、コマンド１２０２の実行を試みる。コマンド１２０２は子１２０４および１２０５を持つので、コマンド１２０４の実行を試みる。
［step ２］ コマンド１２０４は子を持たないのでそのまま実行され、実行結果であるデータ１２０６に置換される。次にコマンド１２０４の弟であるコマンド１２０５の実行を試みる。なお、弟コマンドは、同一階層のコマンドにおいて実行順序の相対的に低いものを指す。すなわち、図１１においては、コマンド１２０２、１２０４が兄コマンドで、コマンド１２０３、１２０５が弟コマンドとなる。
［step ３］ コマンド１２０５は子を持たないのでそのまま実行され、実行結果であるデータ１２０７に置換される。
［step ４］ コマンド１２０２の全ての子が実行されたので、コマンド１２０２自身が実行され、実行結果であるデータ１２０８に置換される。

これを再帰的に繰り返すことにより、木構造で記載された全てのコマンドを実行することができる。根のコマンドがデータに置換された時点でスクリプトは終了し、結果であるデータをユーザに返戻する。

以上の処理により木構造のコマンドを有するスクリプトは、木構造の先端となる子コマンドから根（親）コマンドへ向けて順次実行され、各子コマンドの実行結果はデータに置き換えられ、最後に実行された根コマンドの実行結果がユーザに送られる。

＜２．非同期コマンドを含む場合の実行順序＞
次に非同期コマンドを含むスクリプトの実行順序について説明する。非同期コマンドを含むスクリプトの実行順序は、上述した［rule １］、［rule ２］、［rule３］、［rule４］に加えて以下のルールに従う。
［rule ５］ 非同期コマンドは、実行完了を待たず、直ちに未完了状態で終了する。
［rule ６］ 逐次コマンドは、子コマンドが未完了状態で終了した場合、自分自身を未完了状態で終了する。
［rule ７］ 根コマンドが未完了状態で終了した場合、スクリプトは未完了状態で終了する。
［rule ８］ コマンド実行完了イベントを受け取った場合、該非同期コマンドから処理を再開する。
［rule ９］ コマンド実行完了イベントにより再開されたスクリプトが終了した場合、スクリプト実行完了イベントをユーザに送る。

上記のルールに従うことにより、図１２のスクリプトは以下のステップで実行される。なお本例では、逐次コマンド（Sequencial）１３０１、逐次コマンド１３０２の子として非同期コマンド１３０４があるとする。

まず、step１１では、初めに根コマンド１３０１の実行を試みる。根コマンド１３０１は子１３０２および１３０３を持つので、子コマンド１３０２の実行を試みる。コマンド１３０２は子コマンド１３０４および１３０５を持つので、コマンド１３０４の実行を試みる。コマンド１３０４は子を持たないのでそのまま実行される。コマンド１３０４は非同期コマンドであるので、実行を非同期コマンド処理主体に依頼し、未完了状態で終了する。逐次コマンド１３０２は、子１３０４が未完了状態で終了したため、自分自身も未完了状態で終了する。根である逐次コマンド１３０１は、子１３０２が未完了状態で終了したため、自分自身も未完了状態で終了する。根コマンド１３０１が未完了状態で終了したため、スクリプトは未完了状態で終了し、制御がユーザに返される。

次に、step１２で、非同期コマンド１３０４の処理主体の処理が完了した時点で、コマンド実行完了イベントが発行され、これにより非同期コマンド１３０４をコマンド実行結果であるデータ１３０６に置換する。逐次コマンド１３０２は、非同期コマンド１３０４の弟に当たるコマンド１３０５の実行を試みる。逐次コマンド１３０２の全ての子が完了した後、コマンド１３０２の実行を行う。逐次コマンド１３０１は、子１３０２の実行完了を受け、子１３０２の弟コマンド１３０３の実行を試みる。根コマンド１３０１の全ての子が完了した後、スクリプト実行完了イベントをユーザに送る。

以上の処理により木構造のスクリプトに非同期コマンドが含まれる場合、非同期コマンドは実行を非同期コマンド処理主体に依頼して未完了状態で終了する。そして、非同期コマンドの処理主体の処理が完了した時点でコマンド実行完了イベントが発行されると、未完了状態で終了した他の子コマンドを順次実行するのである。

＜３．並列コマンドを含む場合の実行順序＞
次に並列コマンドを含むスクリプトの実行順序について説明する。並列コマンドを含むスクリプトの実行順序は、上述した［rule １］から［rule ９］に加えて以下のルールに従う。
［rule １０］ 並列コマンドは、特定の子コマンドの終了状態が完了状態、未完了状態のいずれであっても、全ての子コマンドの実行を試みる。
［rule １１］ 並列コマンドは、全ての子コマンドを実行した段階で、未完了状態の子コマンドが存在すれば、自分自身を未完了状態で終了する。

このルールに従うことにより、図１３のスクリプトは以下のステップで実行される。なお本例では、逐次コマンド１４０１の子に並列コマンド１４０２が、並列コマンド１４０２の子として非同期コマンド１４０４、１４０６、同期コマンド１４０５があるとする。

初めにstep２１では、根コマンド１４０１の実行を試みる。根コマンド１４０１は子１４０２および１４０３を持つので、コマンド１４０２の実行を試みる。コマンド１４０２は子１４０４、１４０５、１４０６を持つので、コマンド１４０４の実行を試みる。コマンド１４０４は子を持たないのでそのまま実行される。コマンド１４０４は非同期コマンドであるので、実行を非同期コマンド処理主体に依頼し、未完了状態で終了する。並列コマンド１４０２は、非同期コマンド１４０４の弟コマンド１４０５の実行を試みる。コマンド１４０５は同期コマンドであるので直ちに実行を完了し、データ１４０８に置換される。並列コマンド１４０２は、同期コマンド１４０５の弟コマンド１４０６の実行を試みる。コマンド１４０６は非同期コマンドであるので、実行を非同期コマンド処理主体に依頼し、未完了状態で終了する。全ての子を実行した並列コマンド１４０２は、子１４０４および１４０６が未完了であるため、自分自身も未完了状態で終了する。逐次コマンド１４０１は、子１４０２が未完了状態で終了したため、自分自身も未完了状態で終了する。根コマンド１４０１が未完了状態で終了したため、スクリプトは未完了状態で終了し、制御がユーザに返される。

Step２２では、非同期コマンド１４０４の処理主体の処理が完了した時点で、コマンド実行完了イベントが発行され、これにより非同期コマンド１４０４をコマンド実行結果であるデータ１４０７に置換する。並列コマンド１４０２は、全ての子の処理が完了したかを確認し、子１４０９が未完了であるため、自分自身も未完了状態で終了する。逐次コマンド１４０１は、子１４０２が未完了状態で終了したため、自分自身も未完了状態で終了する。根コマンド１４０１が未完了状態で終了したため、スクリプトは未完了状態で終了する。

次に、step２３では、非同期コマンド１４０６の処理主体の処理が完了した時点で、コマンド実行完了イベントが発行され、これにより非コマンド１４０６をコマンド実行結果であるデータ１４１０に置換する。並列コマンド１４０２は、全ての子の処理が完了したかを確認し、全ての子の実行が完了したため、自分自身を実行する。逐次コマンド１４０１は、子１４０２の実行完了を受け、子１４０２の弟コマンド１４０３の実行を試みる。根コマンド１４０１の全ての子が完了した後、スクリプト実行完了イベントをユーザに送る。

以上の処理により並列コマンドがある場合では、並列コマンドが子コマンドを並列的に実行する。そして、子コマンドあるいはその子孫コマンドが非同期コマンドである場合には、非同期コマンドのコマンド実行完了イベントの到来を待たずに子コマンドの弟コマンドの実行を行う。

＜スクリプトの実行アルゴリズム＞
次に、図１４、図１５、図１６、図１７を用いて、スクリプト実行のアルゴリズムについて説明する。

＜基本処理＞
図１４を用いて、図８、図９のpostActionインタフェース９１０を実行した時、すなわち上位アプリケーションがスクリプトマネージャ９０１にアクションを示すスクリプトを入力し、該アクションの実行を要求した時の基本処理フローについて説明する。
［step３１］ 上位アプリケーションが入力したスクリプトに対するアクションハンドラ１００５を新規に作成し、アクションハンドラリスト９０２に追加する。
［step３２］ アクションハンドラリスト９０２は、アクションハンドラリスト内で一意である識別子を新規作成し、アクションの属性であるアクションＩＤ１００７に格納する。
［step３３］ アクションハンドラ１００５は、自分自身をイベントハンドラとしてイベントパブリッシャ９０３に登録する。
［step３４］ アクションハンドラ１００５は、スクリプトをタグツリー１００８に展開し、図１０に示す各ノードの属性タグネーム１１０７に、スクリプト中に記載されたタグ名を格納する。
［step３５］ アクションハンドラ１００５は、タグツリー１００８の全ノードを再帰的にたどることにより、アクションハンドラ１００５内で一意である識別子をコマンドＩＤ１１０６に格納する。
［step３６］ アクションハンドラ１００５は、タグツリー１００８の根１１０１で指定されたコマンドを実行する。すなわち、図１０に示した根コマンド１１０１の属性タグネーム１１０７で指定された名称のコマンドをコマンドハンドラリスト９０４から探索し、タグネーム１１０７と同じコマンドネーム１０１１を持つコマンドハンドラ１００９を発見すると、該コマンドハンドラ１００９のpostCommandインタフェース１０１０を呼び出す。

＜postCommandインタフェース＞
図１５を用いて、図１４のstep３６で呼び出した、図９のコマンドハンドラ１００９のpostCommandインタフェース９１４のアルゴリズムについて説明する。
［step４１］ 現在処理しているコマンド（自分自身）が逐次コマンドか並列コマンドかを判定する。
［step４２］ 逐次コマンドの場合、全ての子コマンドに対し、後述の図１６で説明するparseCommandインタフェースを呼び出す。返戻が「未完了」の場合、即座に処理を打ち切り、未完了状態で終了する。
［step４３］ 並列コマンドの場合、全ての子に対し、parseCommandインタフェースを呼び出す。
［step４４］ 全ての子に対し実行終了後、返戻が「未完了」の子コマンドが一つでもある場合、未完了状態で終了する。
［step４５］ 自分自身のコマンド別処理を行う。
［step４６］ 「完了」状態で終了する。

＜parseCommandインタフェース＞
図１６を用いて、図１５のstep４２およびstep４３で呼び出した、アクションハンドラ１００５のparseCommandインタフェース１０１８のアルゴリズムについて説明する。

［step５１］ 現在処理しているコマンドが非同期コマンドで、かつコマンド実行完了イベントがまだ到来していない場合、未完了状態で終了する。
［step５２］ 対応するコマンドのコマンドハンドラ１００９をコマンドハンドラリスト９０４から探索する。結果該当なしの場合、該タグはコマンドではなくデータなので、そのまま完了状態で終了する。
［step５３］ 該当するコマンドハンドラ１００９のpostCommandインタフェース９１４を呼び出す。返戻が「未完了」の場合、即座に処理を打ち切り、未完了状態で終了する。
［step５４］ コマンドとその返戻結果であるデータを置換する。
［step５５］ 「完了」状態で終了する。

＜onEventインタフェース＞
次に、図１７を用いて、非同期コマンドの処理主体が非同期処理を終了した時の「コマンド実行完了イベント」に応答する、イベントパブリッシャ９０３のonEventインタフェース９１１について説明する。

［step６１］ 図３におけるコマンド実行完了イベント１１６のアクションＩＤ１１３と、イベントパブリッシャ９０３に図１４のstep３３で登録したアクションハンドラ１００５のアクションＩＤ１００７とを比較して目的のスクリプトを管理するアクションハンドラ１００５を検索し、該アクションハンドラ１００５のonEventインタフェース１００６を呼び出す。onEventインタフェース１００６では、コマンドＩＤ１１４（図３参照）と図１０のコマンドＩＤ１１０６とを比較して、完了した非同期コマンドの位置を探索する。
［step６２］ 探索したコマンドとその返戻結果であるデータを置換する。
［step６３］ 現在参照しているコマンド（自分）を探索したコマンドの親コマンドに位置を移す。
［step６４］ 現在参照しているコマンド（自分）が根になるまで、step６５〜step６８を繰り返す。
［step６５］ 親コマンドが逐次コマンドか並列コマンドかを判定する。
［step６６］ 逐次コマンドの場合、自分自身に対し、図１６で説明したparseCommandインタフェースを呼び出す。返戻が「未完了」の場合、「スクリプト未完了」フラグを真にする。
［step６７］ 並列コマンドの場合、全ての兄弟コマンドに対し、図１６で説明したparseCommandインタフェースを呼び出す。返戻が「未完了」の場合、「スクリプト未完了」フラグを真にする。
［step６８］ 現在参照しているコマンド（自分）を親コマンドに移す。
［step６９］ 「スクリプト未完了」フラグを確認し、未完了でなければstep７０〜step７１を実行する。
［step ７０］ ユーザにスクリプト完了イベントを発行する。
［step ７１］ スクリプトを破棄する。
［step ７２］ 終了する。

＜コマンドの体系＞
スクリプトで用いられる一般的なコマンドは、上記図４〜図７に示した各ノードのコマンドライブラリ５０９、６０８、７０８、８１１に格納する。コマンドは、例えば以下のものが考えられる。

＜prognコマンドとparallelコマンド＞
＜progn＞：：＝ “＜progn＞” ＜CommandLine＞＊ “＜／progn＞”
＜parallel＞：：＝ “＜parallel＞” ＜CommandLine＞＊ “＜／parallel＞”
prognコマンドとparallelコマンドはいずれも、子コマンド群を順番に実行する。なお、prognコマンドは逐次コマンド、parallelコマンドは並列コマンドである。

＜ifコマンド＞
＜if＞：：＝ “＜if＞” ＜condition−Param＞ ＜then−CommandLine＞ ［＜else−CommandLine＞］ “＜／if＞”
＜condition−Param＞：：＝＜Param＞
＜then−CommandLine＞：：＝＜CommandLine＞
＜else−CommandLine＞：：＝＜CommandLine＞
ifコマンドは、条件判定を行う。上記の例では、第一子の条件が真であれば、第二子が実行され、それ以外であれば第三子が実行される。第三子が存在しない場合何も実行しない。ifコマンドは第一子の結果を返戻する。

＜asyncroコマンド＞
＜asyncro＞：：＝ “＜asyncro delay＝’”NUMBER“’＞” ＜CommandLine＞ “＜／asyncro＞”
asyncroコマンドは、属性delayで指定した秒数待機した後、子を実行する非同期コマンドである。

＜Whenコマンド＞
＜when＞：：＝ “＜when event＝’”TEXT“’＞” ［＜condition−Param＞ ［＜then−CommandLine＞］］ “＜／when＞”
whenコマンドは、イベントを待機する非同期コマンドである。属性eventで指定した名称のイベントが到来した時、第一子の条件評価を行い、結果が真であれば、イベントを返戻して終了する。第二子が存在する場合、終了前に第二子を実行する。第一子、第二子が存在しなければ、無条件でイベントを返戻して終了する。

図１８のシーケンス図を用いて、whenコマンドの動作について説明する。なお、コマンドハンドラ（When）１９０２は、図９のコマンドハンドラ１００９の１つ、Whenプロセス１９０３は、イベントハンドラ実装であり、イベントパブリッシャ９０３内のイベントハンドラ１０１２の一つであり、イベントソース１９０５は任意のイベント発生源である。

whenコマンドの説明を行うためのサンプルスクリプトを１９０６に示す。これはobservedという種類のイベントが到来した時、イベントのパラメータＮａｍｅがTemperatureである場合、「Temperature Observed」というメッセージを標準出力に出力するというスクリプトである。スクリプト１９０６はタグツリー１００８として、ｉｆコマンド１９０７の下にｗｈｅｎコマンド１９０８、messageBoxコマンド１９１０、whenコマンド１９０８の下にequalToコマンド１９０９がある、という構造に展開されている。本スクリプトは以下のステップで実行される。
［step８１］ アクションハンドラ１００５からコマンドハンドラ（When）１９０２のpostCommandインタフェースを呼び出す。これは図１６のstep５３に相当する。
［step８２］ コマンドハンドラ（When）１９０２は、イベントハンドラの実装であるWhenプロセス１９０３を生成する。これは図１５のstep４５に相当する。
［step８３］ Whenプロセス１９０３は、whenコマンド１９０８の属性に記載される種類のイベントが到来した時、自分自身を呼び出すよう、イベントパブリッシャ９０３に予約する。
［step８４］ イベントソース１９０５はイベントパブリッシャ９０３にイベントを発行する。
［step８５］ イベントパブリッシャ９０３は、step８３で登録されたWhenプロセス１９０３にイベントを配送する。
［step８６］ Whenプロセス１９０３はwhenコマンド１９０８の子要素に記載されている規則に従い、条件判定を行う。
［step８７］ 条件が真の時、Whenプロセス１９０３はイベントパブリッシャ９０３に、step８３で予約したイベント配送予約を取り消す。なお、step８７を省略することにより、継続して発生するイベントに対し、継続してイベントを待機するコマンド「whenever」を実装することもできる。
［step８８］ Whenプロセス１９０３はイベントパブリッシャ９０３にコマンド実行完了イベントを発行する。
［step８９］ イベントパブリッシャ９０３は、コマンド実行完了イベントのアクションＩＤ１１３から、図１４のstep３３であらかじめ登録しておいた目的のアクションハンドラ１００５に対し、コマンド実行完了イベントを配送する。これにより図１７のonEventインタフェースが呼び出され、処理が継続される。

＜wheneverコマンド＞
＜whenever＞：：＝ “＜whenever event＝’”TEXT“’＞” ［＜condition−Param＞ ［＜then−CommandLine＞］］ “＜／whenever＞”
wheneverコマンドは、イベントを継続して待機する非同期コマンドである。whenコマンドとの違いは、whenコマンドは例えば「山田氏が来たら報告せよ」などの１回限りのイベントの待機を行うのに対し、wheneverコマンドは例えば「温度が１℃単位で上昇・下降したら報告せよ」などの複数回到来するイベントの待機を目的とする。wheneverの動作はwhenと同様であるが、wheneverを含むスクリプトは終了しない。

・killActionコマンド
＜killAction＞：：＝ “＜killAction id＝’” NUMBER “’／＞”
killActionコマンドは、属性ｉｄで指定される実行中のスクリプトを強制終了するコマンドである。whenコマンドなどの非同期コマンドの返戻待ち状態のスクリプトを強制終了する。wheneverコマンドは本コマンドでのみ強制終了できる。スクリプトを識別するｉｄは、図９のアクションＩＤ１００７であり、上記図１４のpostActionインタフェースの最終的な返戻としてユーザや上位システム（上位のノード）に提示することができる。

＜setコマンド＞
＜set＞：：＝（ “＜set＞” “＜XPath＞” ＜XPath＞ “＜／XPath＞” ＜CommandLine＞ “＜／set＞”）｜（“＜set XPath＝’” ＜XPath＞ “’＞” ＜CommandLine＞ “＜／set＞”）
setコマンドは、スクリプト内をスコープとする変数を設定するコマンドである。＜XPath＞は、Ｗ３Ｃで標準化を行っている、ＸＭＬ文書の位置を表す言語であるXPathで指定された、変数の位置を示す指標であり、例えば１番目の建物の２番目の部屋の温度は、Building［１］／Room［２］／Temperatureとして表現できる。XPathでは、Temperatureのように単独の変数としても利用でき、またRoom［２］のように１次元配列としても利用できる。複数のスクリプト間をスコープとするグローバルなsetコマンドを定義してもよい。またデータベースに値を代入するsetコマンドを定義してもよい。

この他、上記＜XPath＞で指定された、上述のsetコマンドで設定した変数を取得するgetコマンド、加減乗除を行うplusコマンド、minusコマンド、multiplyコマンド、divideコマンドや、１個以上の子を取り、合計を出すsumコマンド、１個以上の子を取り、平均値を出すaverageコマンド等のコマンドで構成される。

＜通信コマンド＞
図３のコマンド実行要求１１２で示したノード間通信機能は、本発明の非同期コマンドの一つである通信コマンド「ask」で実現できる。

図１９のシーケンス図を用いて、askコマンドの動作について説明する。なお、コマンドハンドラ（Ask）２００２は、図９のコマンドハンドラ１００９の１つであり、Askクライアント２００３は通信クライアントであり、通信先システム（通信先ノード）上のAskサーバ２００４と相互通信を行う。アクションハンドラ２００５は通信先システム上のアクションハンドラ１００５である。

Askクライアント２００３およびAskサーバ２００４の説明を行うためのサンプルスクリプトを２００６に示す。これは、四則演算（１＋２）＋３を実行するスクリプトであり、四則演算（１＋２）の部分を通信先システムで行っている。スクリプト２００６はタグツリー１００８として、ｐｌｕｓコマンド２００７の下にaskコマンド２００８、Ｖａｌｕｅデータ２０１２、askコマンド２００８の下にｐｌｕｓコマンド２００９、ｐｌｕｓコマンド２００９の下にＶａｌｕｅデータ２０１０および２０１１がある、という構造に展開されている。本スクリプトは以下のステップで実行される。
［step９１］ アクションハンドラ１００５からコマンドハンドラ（Ask）２００２のpostCommandインタフェースを呼び出す。これは図１６のstep５３に相当する。
［step９２］ コマンドハンドラ（Ask）１９０２は、通信クライアントであるAskクライアント２００３を生成する。これは図１５のstep４５に相当する。
［step９３］ Askクライアント２００３は、askコマンドの属性に記載される宛先の通信先システムに子である部分スクリプト（２００９、２０１０、２０１１）を送信する。
［step９４］ 通信先システムのAskサーバ２００４は、通信先システムのアクションハンドラ２００５にスクリプト実行を依頼する。これは図１４で説明したpostActionインタフェースを呼び出すことに相当する。スクリプト２００９は同期コマンドのみから構成されるため即座に結果が返戻され、結果はAskクライアント２００３に返戻される。
［step９５］ Askクライアント２００３は、図では省略されているイベントパブリッシャ９０３にコマンド実行完了イベントを発行し、イベントパブリッシャ９０３は、コマンド実行完了イベントのアクションＩＤ１１３からアクションハンドラ１００５に対し、コマンド実行完了イベントを配送する。これによりonEventインタフェースが呼び出され、処理が継続される。

図２のアクション４０６、４１０、４１５で示したイベントハンドラの配送・登録は、本発明のaskコマンドでwhenコマンドを配送する事により実現できる。

つまり、通信コマンドは、通信先ノードに子コマンドとしての通信コマンドとコマンド識別子及び通信元ノードの識別子を送信した後に、通信コマンドの親コマンドを未完了状態で終了させておく。そして、通信先ノードからの実行結果の返戻があるまで待機し、通信先ノードからの実行結果とコマンド識別子の返戻を契機に、未完了状態で終了したコマンド識別子に対応する親コマンドの実行を再開することで、送受信を実現する。

＜非同期イベント待機コマンド＞
図２０を用いて、図１９の非同期通信コマンドaskの子コマンドに図１８の非同期イベント待機コマンドwhenを設置した例について説明する。なお、コマンドハンドラ（Ask）２１０２は、図９のコマンドハンドラ１００９の１つであり、Askクライアント２１０３は通信クライアントであり、通信先システム（通信先ノード）上のAskサーバ２１０４と相互通信を行う。アクションハンドラ２１０５は通信先システム上のアクションハンドラ１００５であり、イベントソース２１０５は通信先システム上の任意のイベント発生源である。

本例を説明するためのサンプルスクリプトを２１０７に示す。これは、通信先システムでイベントobservedを待機し、返戻があったら通信元システムでメッセージを表示するという動作を行う。スクリプト２１０７はタグツリー１００８として、ifコマンド２１０８の下にaskコマンド２１０９、messageBoxコマンド２１１１、askコマンド２１０９の下にwhenコマンド２１１０がある、という構造に展開されている。本スクリプトは以下のステップで実行される。
［step１０１］ アクションハンドラ１００５からコマンドハンドラ（Ask）２１０２のpostCommandインタフェースを呼び出す。これは図１６のstep５３に相当する。
［step１０２］ コマンドハンドラ（Ask）２１０２は、Askクライアント２１０３を生成する。これは図１５のstep４５に相当する。
［step １０３］ Askクライアント２１０３は、通信先システムに子である部分スクリプト（２１１０）を送信する。
［step １０４］ 通信先システムのAskサーバ２１０４は、通信先システムのアクションハンドラ２１０５にスクリプト実行を依頼する。これは図１４で説明したpostActionインタフェースを呼び出すことに相当する。
［step１０５］ 通信先のイベントソース２１０４は、図２０では省略してある通信先のイベントパブリッシャ９０３にイベントを配送し、イベントパブリッシャ９０３は、最終的にアクションハンドラ２１０５に対し、コマンド実行完了イベントを配送する。
［step１０６］ アクションハンドラ２１０５はアクション実行元のAskサーバ２１０４にスクリプト実行完了イベントを配送する。
［step１０７］ 通信先システムのAskサーバ２１０４は通信元システムのAskクライアント２１０３にコマンド実行完了イベントを配送する。
［step１０８］ 通信元システムのAskクライアント２１０３は図２０では省略してある通信元のイベントパブリッシャにコマンド実行完了イベントを発行し、イベントパブリッシャ９０３は、最終的にアクションハンドラ２１０１に対し、コマンド実行完了イベントを配送する。これによりonEventインタフェースが呼び出され、処理が継続される。

＜並列コマンド＞
次に、図２１を用いて、本発明の並列コマンドの好ましい拡張である論理和コマンド「or」、締め切りコマンド「any」について説明する。

図２１の２２０１に並列論理和コマンド「or」の動作を説明するサンプルスクリプトを示す。これは、ｉｄがａ、ｂで識別されるクライアント２０５に対し、非同期コマンドである質問・回答要求コマンドquestionBoxを配送・実行依頼し、いずれかの回答が真であればメッセージを出力するというスクリプトである。なお、questionBoxコマンドは、クライアントを操作するユーザが「ＹＥＳ」ボタンあるいは「ＮＯ」ボタンを押下する事により真偽を返すコマンドである。

orコマンドは並列コマンドであるため、複数のクライアントに対し、一斉に質問文を発行することができる。また論理和の性質として、いずれかの子が真であれば成立するため、その実装として、いずれかの子のコマンド完了イベントが到来し、その値が真であれば、残りの子のコマンド完了イベントが到来する前に完了状態で終了することができる。これにより全ての回答を待たずに処理を継続できるため、効率的な処理を行うことができる。これは、図１５に示したpostCommandインタフェースのorコマンドの特別な実装として、step４４において上述した判定を行うことで実現できる。同様に論理積andコマンドも実装できる。

図２１の２２０２に並列締め切りコマンド「any」の動作を説明するサンプルスクリプトを示す。これは、ノードのｉｄがａ、ｂ、ｃで識別されるクライアント２０５に対し、アンケートとして一斉に非同期コマンドである質問・回答要求コマンドquestionBoxを配送・実行依頼し、anyコマンドにより回答締め切り数ｎを２個、また回答締切時間limitを１０分、として設定し、その結果をaverageコマンドで平均化し、ｓｅｔコマンドで変数ｘに代入し、messageBoxコマンドで標準出力に出力するスクリプトである。

anyコマンドは並列コマンドであるため、複数のクライアント（ノード）に対し、一斉に質問文を発行することができる。またアンケート機能として、締め切り数、締切時間を設定することができる。anyコマンドもorコマンドと同様、図１５に示したpostCommandインタフェースのstep４４で、未完了の子コマンドがいる場合に未完了状態で終了するのではなく、完了コマンドが指定された個数に達した時点、あるいは締切時刻を超過した時点でstep４５に移行するようにすればよい。

並列締め切りコマンド「any」の別の特徴として、センサネットワークの課題であった「ノードの低信頼性問題」を解決することができる。センサネットワークは基本的に低価格のセンサノードを大量に敷設することにより、各センサノードの信頼性のなさを数でカバーする、というコンセプトを持つシステムであり、故障等の原因でセンサノードの返戻が必ず帰ってくる保証はない、という事実を織り込まなければならない。しかし一般にイベントハンドラはイベントが発生しないと何も動作を行わない。そのため、イベントが返戻されない場合の何らかの対処が必要である。

観測したい事象を、誤検出や故障を見越して重複したセンサノードに一斉に観測させ、並列締め切りコマンド「any」の回答締め切り数を用いる事により、統計的に有意なイベントを抽出することができる。

また、一般にＤＭＳ（Dead Man Switch）と呼ばれる、定期連絡がない時にノード故障と判定するロジックは、並列締め切りコマンド「any」の回答締切時間を用いる事により実装することができる。

＜圧縮スクリプト＞
次に、図２２を用いて、本発明の好ましい拡張である圧縮スクリプトについて説明する。

一般に、図２におけるセンサノード２０１やルータノード２０２は、価格や電力の点からサーバ２０３と比較してメモリサイズ、ＣＰＵ処理速度、通信速度の点で非力なハードウェアで実現する場合が多い。その場合、本発明のスクリプトをＸＭＬで記載すると、通信コストやＣＰＵ処理コスト、メモリ消費量の点で問題が発生する可能性がある。そのため、スクリプトを圧縮構造で送信することが望ましい。

図２２のスクリプト２３０２はセンサノード２０１におけるイベントハンドラの記述例であり、「温度が２６℃以上であればイベントを発行する」というスクリプトである。なお、図中greaterThanコマンドは大小比較コマンド、getTempコマンドは温度観測値取得コマンド、throwコマンドはイベント発行コマンドである。本スクリプトをＣ言語で記載すると、図２２の２３０１のようになる。

本例を圧縮スクリプトで記載した例を、図２２の２３０３に示す。本圧縮スクリプトの圧縮方法は、以下のルールに従う。
［rule２１］ コマンド名は、対応するコマンド識別子にマッピングする。
［rule２２］ コマンドの子の数が固定個数の場合、圧縮者・展開者間の双方で既知であるとして省略する。
［rule２３］ コマンドの子の数が可変である場合、全ての子の先頭に子の数を記載する。

なお、コマンド識別子の名前空間のサイズは、非特許文献「WAP Binary XML Content Format W3C NOTE 24 June 1999」で開示されるMulti-byte Integersを使用する事により、自由に拡張できる。またコマンド識別子の名前空間の衝突問題は、ノード起動時に該ノードが適用するコマンド名とコマンド識別子のマッピングテーブルをサーバに送信することによって解決することができる。

図２３、図２４を用いて、非力なハードウェア上での圧縮スクリプト実行のアルゴリズムについて説明する。

下記アルゴリズムを使用することで、圧縮スクリプトを木構造に展開する必要がなく、また子コマンドの数だけのサイズを持つ配列resultを使用するだけでスクリプトを処理することができる。

図２３は、非力なハードウェア上での圧縮スクリプトにおける図９のコマンドハンドラ１００９のpostCommandインタフェース９１４の実装であり、図１５に相当する。
［step１１１］ 圧縮スクリプトのポインタptrを、コマンド識別子の分をインクリメントする。
［step１１２］ 予め規定された子の数だけ、図２４のparseCommandを呼び出す。
［step１１３］ 自分自身のコマンド別処理を行う。なお、最後からｎ個目の子の値は、配列resultの格納数resultNum−ｎ＋１に格納されている。
［step１１４］ 配列resultの格納数を子の数分だけ減じ、自分自身の返戻値を格納し、格納数を１インクリメントする。

図２４は、非力なハードウェア上での圧縮スクリプトにおける図９のアクションハンドラ１００５のparseCommandインタフェース１０１８であり、図１６に相当する。
［step１２１］ 圧縮スクリプトのポインタptrの値に対応するコマンドのコマンドハンドラ１００９を探索する。結果該当なしの場合、step１２２〜step１２４に進む。
［step１２２］ 圧縮スクリプトのポインタptrの値がデータ＜Value＞の場合、次の値はデータであるため、データを配列resultに追加し、ptrをコマンド識別子とデータサイズ分進める。
［step１２３］ 圧縮スクリプトのポインタptrの値が真偽値＜true／＞の場合、真値を配列resultに追加し、ptrをコマンド識別子分進める。
［step １２４］ 圧縮スクリプトのポインタptrの値が真偽値＜false／＞の場合、偽値を配列resultに追加し、ptrをコマンド識別子分進める。
［step１２５］ 対応するコマンドハンドラ１００９の図２３に示したpostCommandインタフェースを呼び出す。

以上のように、本発明によれば、センサネットワークのノード上の分散イベントハンドリングの動作フローを、複数存在し、一般化できず、動的に変化していくユーザ目的に対応して動的に変更できるため、単一のセンサネットワーク上に多様なユーザ目的を反映することができる。このためセンサネットワークの設置・メンテナンス費用を複数のユーザで費用分担できるため、広域環境を観測する大規模センサネットワークインフラ基盤が実現できる。

また本発明により、分散イベントハンドリングの動作フローを、動的に変化していく状況に対応して動的に変更できるため、あらかじめ固定したイベントハンドリングを行う場合に比べ、無駄な処理を行う必要がなくなり、その結果配送するイベント数を削減することができるため、サーバへの負荷集中を減少させることができる。

そして、木構造のコマンドを有するスクリプトを、クライアント２０５からセンサネットワークへ指示することで、複数のノードを容易に制御することが可能となり、ユーザは一つのスクリプトを定義するだけでよいので、膨大な数のセンサノード２０１を備えたセンサネットワークから所望の情報を極めて容易に利用することが可能となる。さらに、スクリプトを適宜変更することで、ユーザの要求の変化に応じて利用するセンサネットワークの情報を容易に変更することが可能となる。

＜第２実施形態＞
図２５は、第２の実施形態を示し、別個の目的を持つ複数のクライアントを有するセンサネットワークを示す。

図２５において、センサノード２６０１、サーバ２６０７、別個の目的を持つクライアント２６１４および２６１５から構成されるセンサネットワークを想定する。クライアント２６１４および２６１５の要求によりセンサノード２６０１上のイベントハンドラ２６０２でそれぞれ異なるイベント加工を行い、二種類の二次イベント２６０５を発行する。その他の構成は、前記第１実施形態と同様であり、センサノード２６０１、２６０７は、前記第１実施形態の図４と同様であり、サーバ２６０７はサーバ２０３と同様に構成される。

ここで、従来のセンサネットワークの課題であった「二次イベント識別子問題」とその解決策について説明する。

一般に、イベント２６０５は、イベントの種類を識別する識別子とイベントのパラメータから構成される。ここで、イベントの種類を識別する識別子を誰が決定するかという問題が発生する。識別子をクライアント２６１５で決定することはできない。なぜならば異なるクライアント２６１４および２６１５との間で識別子の衝突が発生する可能性があるからである。しかし識別子をサーバ２６０７で一元管理し、動的に割り当てることもできない。なぜならば異なる領域をカバーするサーバ２６０７およびサーバ２６０９との間で識別子の衝突が発生する可能性があるからである。また、二次イベントの識別子を標準化することもできない。二次イベントの識別子を標準化するということは、イベントハンドラのルールを標準化組織で固定するということであり、ユーザによるイベントハンドラ作成の自由度を削減することになるからである。イベント要求元のクライアントを一意に識別する識別子と、クライアントで自由に決定した識別子を組み合わせたものを二次イベントの識別子として利用することにより上述した問題は解決する。しかし二次イベントの識別子のサイズが大きくなり、多量のイベントを扱うことを前提としたセンサネットワーク分野への適用は現実的ではない。

本発明では、前記第１実施形態の図３に示したとおり、二次イベントを非同期アクションの返戻であるアクション完了イベント１１６で代用し、アクションＩＤ１１３およびコマンドＩＤ１１４でイベント返戻先を決定しているため、上述した二次イベント識別子問題は発生しない。

図２５を用い、従来のセンサネットワークの課題であった「イベント漏洩問題」とその解決策について説明する。

センサノード２６０１のイベントハンドラ２６０２における情報加工の結果出力される二次イベント２６０５は、ユーザ要求に対応して作成される価値のある情報であり、相反する利益を持つ他のユーザに知られてはならない。イベント２６０５を通信路上で盗聴された場合、イベントの種類やイベント返戻先が漏洩する可能性がある。

本発明では、図３に示すとおり、アクション完了イベント１１６にはイベントの種類を示す情報、イベントの要求元のクライアントを一意に識別する識別子が含まれていないため、上述した問題は発生しない。

＜第３実施形態＞
図２６、図２７は、第３の実施形態を示し、一つのクライアントが、複数のセンサノードを複数のルールで取り扱う例を示す。

図２６において、センサネットワークは、「人検知イベント」を発行する人検知センサノード２７０１、「温度観測イベント」を発行する温度センサノード２７０２、これらのイベントを受け付けるイベントハンドラ２７０４を実装したサーバ２７０３から構成された例を示し、その他の構成は前記第１実施形態と同様である。なお、センサノード２７０１、２７０２は前記第１実施形態のセンサノード２０１と同様に構成され、サーバ２７０３は前記第１実施形態のサーバ２０３と同様に構成される。

サーバ２７０３のイベントハンドラ２７０４において、以下のルールを実装することを考える。
［Rule３１］ 人が存在する部屋が３０℃以上であれば、空調を起動する。
［Rule３２］ 部屋温度が４０℃以上の場合、火災であると判断し、もし人がいれば避難勧告を発行する。

ここで、従来のセンサネットワークの課題であった「ルール数爆発問題」とその解決策について説明する。一般に、イベントハンドラがＮ個の状態変数を管理し、Ｍ種類のイベントを受け取り、状態遷移を行うとすると、記述すべき状態遷移のルール数はＮ×Ｍ個以上となる。そのためイベントハンドラ作成者のルール記載もれにより、意図せぬアクションを誘発する可能性がある。これはルール数爆発問題と言われる。

従来例では、イベントハンドラは図２７のリスト２８０１のように記述される。リスト２８０１は到来イベントを中心とした記述であるため、上述したルールが容易に表現されず、可読性が低い。また、複数の状態変数、条件判定をする必要がある。状態変数やイベント数が増大すると、リスト２８０１の複雑度は爆発的に増大し、イベントハンドラ作成者のルール記載もれの発生する確率が増大することが容易に類推できる。

本発明のスクリプトとして、前記第１実施形態で示した並列コマンド、非同期待機コマンドを利用する事により、上記ルールをリスト２８０２のように記述することができる。リスト２８０２は上記ルールを容易に表現することができ、また状態変数を排することができるため、イベントハンドラ作成者のルール記載漏れを抑制することができる。

＜第４実施形態＞
図２８、図２９は第４の実施形態を示し、ノード間の構成が動的に変化する場合を示す。

図２８において、センサノード２９０１および２９０２が、ルータノード２９０３、２９０４、２９０５、２９０６によりサーバ２９０７と接続しているとする。ここで、ユーザの指定した観測対象領域２９０８の平均温度が指定値を逸脱するとセンサノード２９０１、２９０２はメッセージを出力する、という機能を付与されている。また、ルータノード２９０４、２９０５は並列的に配置されている。

なお、センサノード２９０１、２９０２は前記第１実施形態のセンサノード２０１と同様に構成され、ルータノード２９０３〜２９０６は前記第１実施形態のルータノード２０２と同様に構成され、また、サーバ２７０３は前記第１実施形態のサーバ２０３と同様に構成される。

ここで、従来のセンサネットワークには、「Ａｄ−Ｈｏｃ問題」という問題があり、その解決策について説明する。センサネットワークは基本的にＡｄ−Ｈｏｃ性を持つネットワークシステムである。すなわち、利用できるセンサノードの位置や個数、能力は、センサノードの故障、センサノードの追加・移動・撤去などの原因で、ユーザの制御できないタイミングで変化する可能性がある。そのため動作フローをあらかじめユーザが作成するのではなく、運用時に状況に応じて動的に作成する必要がある。

図２８において、サーバ２９０７に負荷集中を起こさず、また通信量を最小にする最も好適な方式は、センサノード２９０１および２９０２の観測値をルータノード２９０３に集積し、ルータノード２９０３のイベントハンドラで平均化処理と指定値逸脱判定を行う方式となる。しかし観測対象領域２９０８はユーザ目的や状況に応じて変化し、対応するセンサノード２９０１、２９０２やルータノード２９０３〜２９０６の構成も変化するため、センサネットワークの変化を自動的に発見し、それによって最適な動作フローを各ノードに設定することが必要となる。

本発明では、分散するノード間の動作フローを単一のスクリプトとして記載することができるため、スクリプトの変更を行うことだけで動作フローを変更することができる。

図２９を用いて、スクリプトの変更方式について説明する。

リスト３００１は、ユーザがサーバ２９０７に実行を依頼したスクリプトの例である。getTempFromRegionコマンドは、子で指定された矩形領域（観測対象領域２９０８）の平均温度を取得する。これによりリスト３００１は、矩形で表された観測対象領域２９０８の平均温度が３０℃を超えていれば、「温度が３０℃以上」というメッセージを表示する。

サーバ２９０７に実装されたgetTempFromRegionコマンドの処理主体は、観測対象領域２９０８に含まれるセンサノード２９０１、２９０２を探索するノード探索部、また該センサノード群にそれぞれ通信を到達させるための最適な経路（ルータノード）２９０６−２９０４−２９０３−２９０１および経路２９０６−２９０４−２９０３−２９０２を探索する経路探索部を持つ。上記ノード探索手段および経路探索手段については、たとえばAd Hocの無線通信規格ZigBeeで採用されているＡＯＤＶ（Ad-hoc On-demand Distance Vector）などの手段を利用することができる。

図２９のリスト３００１に該ノード探索部および経路探索部を用いてスクリプトを変形することにより、リスト３００２を得ることができる。リスト３００１の３行目から６行目のgetTempFromRegionコマンドが、リスト３００２の３行目から１０行目に置換されている。ここで、リスト３００２の４行目から６行目は、経路２９０６−２９０４−２９０３−２９０１を経由してセンサノード２９０１に温度観測イベントgetTempを実行依頼している。リスト３００２の７行目から９行目は、経路２９０６−２９０４−２９０３−２９０２を経由してセンサノード２９０２に温度観測コマンドgetTempを実行依頼している。リスト３００２の３行目は、平均計算コマンドaverageにより、子の返戻の平均を計算している。

リスト３００２に以下に示すルールを適用してスクリプトを変形することにより、リスト３００３を得ることができる。スクリプトを変形するための基本ルールは、数学分野で知られる交換則と分配則である。
［rule３１］ 分配則：ＡＢ・ＡＣ＝Ａ（Ｂ・Ｃ）
［rule３２］ 交換則：Ａ・Ｂ＝Ｂ・Ａ
交換則と分配側の適用条件として、以下のルールを用いる。
［rule３３］ 通信コマンドと該通信コマンドの親コマンドは、通信コマンドが兄弟コマンドを持たず、かつ該親コマンドが通信元ノードと通信先ノードで等しい動作をすることが保証されている場合、［rule３１］の交換則を適用できる。
［rule３４］ 通信コマンドが兄弟コマンドを持ち、全ての兄弟コマンドが通信元ノードと通信先ノードで等しい動作をすることが保障されている場合、［rule３１］の交換則を適用できる。
［rule３５］ 通信コマンドが、等しい通信先に対する通真コマンドを兄弟コマンドとして持つ場合、［rule３２］の分配則が適用できる。

これらのルールを適用することにより、リスト３００２の４行目および７行目がまとめられ、リスト３００２の１行目と２行目の間に移動している。これによりリスト３００３は、経路２９０６−２９０４−２９０３を経由してルータノード２９０３において、平均化処理と指定値範囲判定を行うことになり、上述したように運用状況に応じた最も好適な動作フローを得ることができる。

なお、ノード探索部は、スクリプトで指定した空間領域内に存在する複数のセンサノードから該要求精度に必要十分なセンサノード群を選択することで、空間領域内のセンサノードの観測結果を集積して該空間領域の特徴量を取得することも可能である。

＜第５実施形態＞
図３０は第５の実施形態を示し、前記第１実施形態のセンサノード２０１の挙動を変更可能なスクリプトの一例を示す。なお、センサネットワークの構成は、前記第１実施形態と同様である。

図３０のリスト３１０１は、観測値が閾値を超えていればイベントを送信する、というルールを記述したスクリプトである。まず、loopコマンドで子を繰り返す。次に、sleepコマンドで属性delayで指定した時間休止し、その後getTempコマンドで観測した温度が３０℃を超えていれば、unusualイベントを発行する。

リスト３１０２は、観測値が変化したら送信する、というルールを記述したスクリプトである。getTempコマンドで取得した温度が、oldというキーの温度履歴から変化したら、Changeイベントを発行する。

リスト３１０３は、時間平均値を送信する、というルールを記述したスクリプトである。３回観測を行った後、その平均値を持つＡＶＥイベントを発行する。

リスト３１０４は、温度、湿度という複数の観測値の条件判定の例である。温度が２５℃を超過し、かつ湿度が６０％を超過した時に、Disconfortイベントを発行する。

リスト３１０５は、最大値・最小値・平均値を送信する、というルールを記述したスクリプトである。

リスト３１０１から３１０５までのスクリプトをセンサノード２０１に送信し、実行依頼することにより、センサネットワーク運用中に動的にセンサノードの挙動を変化させることができる。これにより、センサネットワークの柔軟な運用が可能となる。

＜第６実施形態＞
図３１は、第６の実施形態を示し、前記第１実施形態のセンサノード２０１を省エネルギ型とした場合のセンサデバイスとマイコンの要部を示したものであり、その他の構成は前記第１実施形態の図４と同様である。

センサノード２０１を構成するマイコン３２２０は、一般に、電力消費の少ない休止モードと電力消費の多い活性モードの切り替えが可能である。休止モードの時のマイコン３２２０は割り込みポートからの割り込みにより活性モードに移行する。

タイマと接続する割り込みポート３２１８を設け、タイマ割り込みによりマイコンを活性モードに移行させスクリプトの処理を続行することにより、時間イベントで駆動するスクリプトパーサが実現できる。

例えば、上記図３０のリスト３１０１の二行目に記載した非同期休止コマンドであるsleepコマンドの実装として、タイマ３２１９に休止時間を設定し、図３のコマンドＩＤを記憶し、マイコンを休止状態に移行させ、マイコンが起動したら、記憶したコマンドＩＤからの処理を再開させることにより、観測時間のみ活性モードに移行するエネルギー効率のよいセンサノードが実現できる。

また同様に、観測値と固定値との簡単な比較・論理判定の演算回路をハードウェアで実装することにより、観測値イベントで駆動するスクリプトパーサが実現できる。

図３１において、センサノード２０１ａは、温度センサ３２０１と湿度センサ３２０２を有し、各センサの出力はコンパレータ３２０７〜３２１０で上限値と下限値が比較される。そして、コンパレータ３２０７〜３２１０の出力をＯＲゲート及びＡＮＤゲートで判定してマイコン３２２０へ入力する。

マイコン３２２０には、割り込みポート３２１６、割り込みポート３２１７のいずれかあるいは両方を設ける。割り込みポート３２１６は「温度観測値が指定範囲を超えた場合または湿度観測値が指定範囲を超えた場合」に割り込みが発生する。割り込みポート３２１７は「温度観測値が指定範囲を超えた場合かつ湿度観測値が指定範囲を超えた場合」に割り込みが発生する。

なお、温度センサ３２０１および湿度センサ３２０２は観測値を表す電圧を常時出力する。下限温度３２０３、上限温度３２０４、下限湿度３２０５、上限湿度３２０６は参照電圧生成回路であり、マイコンの出力ポート３２１５からの選択信号により、あらかじめ定義された参照電圧を出力する。コンパレータ３２０７、３２０８、３２０９、３２１０は入力される電圧を比較し、（−）入力電圧より（＋）入力電圧が高い場合、真値を表す電圧を出力する。

この参照電圧生成回路３２０３〜３２０６は、例えば、バンドギャップリファレンス回路などで構成することができる。バンドギャップリファレンス回路としては、例えば、＜http://www.sony.co.jp/~semicon/japanese/img/sonyj01/e6801283.pdf＞に記載の「10ビット80MSPS 1ch D／Aコンバータ」の第４頁に記載されるものが適用できる。バンドギャップリファレンスを用いた独立定電圧源出力端子をVREFに接続することにより、電源電圧の変動に依存しない安定した電圧が得られる。

コンパレータ３２０７は、観測温度が下限温度を下回った時に真を返す。コンパレータ３２０８は、観測温度が上限温度を上回った時に真を返す。コンパレータ３２０９は、観測湿度が下限湿度を下回った時に真を返す。コンパレータ３２１０は、観測湿度が上限湿度を上回った時に真を返す。ＯＲ回路３２１１、３２１２、３２１３はそれぞれ、入力の論理和が真の場合真を出力し、ＡＮＤ回路３２１４は入力の論理積が真の場合真を出力する。

以上より、観測値と固定値との簡単な比較・論理判定の演算回路をハードウェアで実装することが可能となる。またセンサノード２０１ａを処理が不要な時に停止することができるため、センサノード２０１ａの消費電力を抑えることができ、特に移動可能な無線式のセンサノード２０１ａに適用した場合には、電池の充電周期や寿命を延長することができる。

＜第７実施形態＞
図３２は、第７の実施形態を示し、平時・緊急時の両方で利用可能なセンサネットワークを示す。なお、センサノードとサーバ等は前記第１実施形態と同様に構成される。また、図示はしないが、センサノード３３０１とサーバ３３０２の間に複数のルータノードを設けても良い。

本発明により、状況に応じてイベントハンドラの動作フローを変更できるセンサネットワークを提供できる。センサネットワークの意義として、広域環境の観測情報が常時入手できるということの他に、緊急時に必要な環境情報が入手できるというポテンシャルを持つという点がある。例えば地震・火災・水害等の災害発生時において、電力網が遮断された時に自立電源を持つノードによる無線ネットワークが存在することの意義は大きい。しかし緊急時のためだけにセンサネットワークを敷設するのは費用対効果が悪く、平常時でも利用する両立形態を取ることが望ましい。また緊急時に必要とする粒度（空間間隔および時間間隔）の情報は一般に平常時には不要であり、不要な情報を常時取得していては電力を浪費することになる。

図３２を用いて、平時・緊急時の両方で利用可能なセンサネットワークの機能を説明する。平常時は、観測対象領域３３０１の全てのセンサノードを稼動させるのではなく、たとえば環境モニタリングに必要十分な空間間隔のセンサノード（図中３３０５で示す黒いノード）のみを稼動する。電力消費の平均化を図るため、定期的に稼動するセンサノード群３３０１を稼動していないノードと交換してもよい。緊急時には、全てのセンサノードを起動して詳細に環境情報を収集してもよいし、例えば火災発生地点周辺などのクリティカルな地点３３０５の周辺のセンサノード３３０４のみを稼動してもよい。このような例としては、ビルに敷設された人検知センサノードが、平常時には混雑状況監視に、火災発生時には要避難者発見用に使用されるセンサネットワーク、山岳・森林内に敷設された音響センサノードが、平常時には動物の生息状況モニタリングに、遭難者発生時には遭難者探索に使用されるセンサネットワーク、沿岸のブイ上に敷設された海水温度センサノードが、平常時には学術的利用、異常温度発生時にはホタテの壊死を防ぐために養殖籠を下降させるセンサネットワークが実現可能である。

＜第８実施形態＞
図３３、図３４は第８の実施形態を示し、前記第１実施形態に示したルータノードでスクリプトを実行することにより、センサノードの探索と観測要求、結果の収集を行う例を示す。なお、その他の構成は、前記第１実施形態と同様である。

図３３を、Ａｄ−Ｈｏｃにセンサノード３４０１〜４、３４０８、３４１２およびルータノード３４０５〜７、３４０９〜１１、３４１３、３４１４が接続されているセンサネットワークとする。Ａｄ−Ｈｏｃなセンサネットワークとは、サーバ３４１５、センサノードおよびルータノードは無線で接続され、通信範囲内の隣接ノードの存在は検知できるが、センサノード、ルータノードの構成が動的に変更されるため、サーバ３４１５は全体の構成を把握できないセンサネットワークのことである。

各センサノードは温度センサを有し、ユーザが「領域の温度の最大値を知りたい」という要求を行ったとする。そのためには、領域に存在するセンサノードを探索し、該センサノードで観測を行い、その結果の最大値を計算する必要がある。

上述した要求を実現するスクリプトは、図３４で実現できる。２行目のdefunコマンドで、ユーザ定義関数funcを定義している。関数funcは７行目で自分自身を再帰的に呼び出している。１３行目のｓｅｔコマンドで変数maxTempに、func関数の実行結果である最大温度を格納し、１４行目でクライアント３４１６に最大温度を送信している。

３行目のmaxコマンドは、１個以上の子から最大値を取る子を選択する。４行目のbroadcastコマンドは、通信範囲内の全ての隣接ノードに子である部分スクリプトを送信する。ループを防止するため、同じアクションＩＤを持つスクリプトの二重受信は拒否される。６行目のisRouterNodeコマンドは、ルータノードであれば真を返す。

サーバ３４１５で図３４のスクリプトを実行することにより、broadcastコマンドの子である５から９行目がルータノード３４１１、３４１４に転送される。ルータノード３４１１はisRouterNodeコマンドに真を返し、７行目が実行され、再帰的に２行目以降が実行され、broadcastコマンドの子である５から９行目がルータノード３４０７、ルータノード３４１０、サーバ３４１５に転送される。ループ防止のため、サーバ３４１５の通信は無視される。これを再帰的に繰り返すことにより、部分スクリプトがセンサノード３４０１、３４０２、３４０３、３４０４、３４０８、３４１２に到達する。センサノードはisRouterNodeコマンドに偽を返し、８行目の温度観測コマンドであるgetTempコマンドが実行される。その結果はbroadcastコマンドの返戻となり、探索経路上のルータノードでmaxコマンドにより最大値が選択され、最終的にサーバ３４１５に全てのセンサノードの観測した温度の最大値が返される。

このように、本発明のスクリプトパーサで再起構造を用いることにより、センサノードの探索を行うルータノードの挙動、温度を観測するというセンサノードの挙動、その返戻を集約するというルータノードの挙動をコンパクトに記載することができる。そして、６行目のisRouterNodeの部分を様々に変更することにより、例えば電池残量の少ないルータノードの使用を避けるなど、様々なルート探索アルゴリズムが実装できる。また８行目のgetTempコマンドを非同期イベント待機コマンドwheneverに変更することにより、継続した観測が実施できる。またこの動作はスクリプトで記載されているため、ユーザの要求に応じて多彩な動作を実現できる。

＜第９実施形態＞
図３５は、第９の実施形態を示し、前記第１実施形態のセンサノード２０１におけるユーザインターフェースの一例を示す。

図３５は、人間に対する簡易コミュニケーションツールとしてセンサノード２０１を名札ノードとした場合、センサノード２０１におけるユーザインターフェースの一例を示す。

名札ノード３６０１は図２のセンサノード２０１の一種であり、人間の名札を兼任したセンサノードである。名札ノード３６０１は人間に携帯され、ボタン押下により人間の意志表示を検知するという機能を持つ。名札ノード３６０１は質問文を表示する液晶画面等の表示装置３６０２と、回答のためのボタン（戻るボタン３６０３、選択ボタン３６０４、決定ボタン３６０５）を持ち、無線を用いたルータノード２０２やサーバ２０３への通信機能を持つ。さらに他のノードから質問文が到着したことをユーザに喚起するためのブザー機能、バイブレーション機能、ＬＥＤなどのランプ機能を付与してもよい。さらに人間が携帯するセンサノードという特質を生かし、環境の計測を行う温度センサ、湿度センサ、人間の行動の計測を行う加速度センサなどを付与してもよい。

他の人間（あるいはノード）より質問が発行された場合、画面３６０２のように質問文とその回答一覧が表示される。人間は選択ボタン３６０４を複数回押下する事により回答一覧から回答を選択し、決定ボタン３６０５を押下する事により回答を決定する。複数の質問が発行された場合、戻るボタン３６０３を押下する事により状態遷移３６０７により、画面３６０６に未回答の質問文一覧を表示する。質問文一覧が表示されている状態で選択ボタン３６０４を複数押下し、決定ボタン３６０５を押下する事により回答したい質問文を決定し、状態遷移３６０８により画面３６０２に戻ることができる。

名札ノードは、画面３６０６に示すように、複数の質問文を保持する機能を必要とする。また名札ノードを含むセンサネットワークは、質問文に対する回答を、質問を行った者に対して適切に配送する機能を必要とする。

本発明を適用することにより名札ノードを含むセンサネットワークを実現できる。前記第１実施形態のスクリプトマネージャ９０１を名札ノードに実装し、該スクリプトマネージャ９０１に、「質問文を画面に表示し、人間による回答ボタン押下イベントを待機する」という機能を持つ非同期コマンドである質問回答要求コマンドを、図１９で説明した非同期通信コマンドaskの子として発行すればよい。動作シーケンスは図２０と同等となる。本発明では、図３の返戻１１６のアクションＩＤ１１３により、質問を行ったサーバ側のスクリプトを識別できるため、質問の回答を質問者に適切に配信できる。

さらに名札ノードに対する通信コマンドaskの子として、図１８の条件判定コマンドif１９０７と組み合わせて質問回答要求コマンドを再帰的に木状に作成する事により、質問回答に応じた再質問などの複雑な処理が容易に実装できる。

＜第１０実施形態＞
図３６は、第１０の実施形態を示し、建物の各部屋にルータノードとしてのゲートウェイノードを設け、各ゲートウェイノードの配下にセンサノードを設け、各ゲートウェイノードを管理するサーバと、アクチュエータノードとして家電製品（例えば、エアコンディショナ）を設けたものである。

図３６において、ゲートウェイノード３７０７、サーバ３７１０、エアコンディショナーノード３７０８から構成されるセンサネットワークシステムが配置される。ゲートウェイノード３７０７は無線通信により人間が携帯するセンサノード及びクライアントの機能を併せ持つノードとしてのモバイルノード３７０４と無線通信を行う。

アクチュエータノードとしてのエアコンディショナーノード３７０８はエアコンディショナーと接続され、適切なコマンドにより室内を指定された温度・湿度に保つ機能を持つ。該建物内にモバイルノード３７０４を携帯したユーザ３７０３が到来した時、該センサネットワークシステムは、ユーザ３７０３の嗜好にあわせた温度でエアコンディショナーノード３７０８を制御する。

本実施形態においては、サーバ３７１０が前記第１実施形態のサーバ２０３に相当し、ゲートウェイノード３７０７、３７０８がルータノード２０２に相当し、モバイルノード３７０４、３７０５がセンサノード２０１及びクライアント２０５に相当し、エアコンディショナーノード３７０８がアクチュエータノード２０８に相当するもので、その他の構成は前記第１実施形態と同様である。

本機能の実現は以下の方法で行う。モバイルノード３７０４に「ユーザ３７０３の嗜好（例えば１８℃）に合わせた温度・湿度でエアコンディショナーを制御せよ」というスクリプトを登録しておき、ゲートウェイノード３７０７からモバイルノード３７０４への接続イベントに応じて、モバイルノード３７０４が該スクリプトをゲートウェイノード３７０７を経由してサーバ３７１０に発行する。サーバ３７１０は該スクリプトを実行する事により、エアコンディショナーノード３７０８を指定された温度・湿度で稼動させる。

従来のセンサネットワークで本機能を実現しようとすると、センサネットワーク管理者側がサーバ３７１０のイベントハンドラとして本機能をあらかじめ登録しておく必要があった。そのためユーザ個別の嗜好ではなく平均的な嗜好での温度制御を行うか、もしくは予めユーザの嗜好をサーバ３７１０に登録しておく必要があった。本発明を用いれば、サーバ３７１０やエアコンディショナーノード３７０８に本発明のスクリプトマネージャのみを登録しておけばよい。本適用はユーザ３７０３がたとえば喘息や風邪の場合、あるいは未熟児等、センサネットワーク管理者の予測できない特殊事情を抱える場合に有効である。

＜第１１実施形態＞
図３６は、第１１の実施形態を示し、建物の各部屋にルータノードとしてのゲートウェイノードを設け、各ゲートウェイノードを管理するサーバを設けたものである。ゲートウェイノード３７０７は無線通信により人間が携帯するセンサノード及びクライアントの機能を併せ持つノードとしてのモバイルノード３７０４と無線通信を行う。

互いに打合せを行う必要のある社員３７０３および３７０６がいると考える。両社員３７０３は出張が多く、多忙であり、打合せの日程調整を行えないとする。両社員３７０３および３７０６が偶然同じ出張先に存在しているということが分かればそこで打合せを行うことができ、これにより業務効率が改善される。従来はこのような偶然は有効活用されていなかった。

本機能の実現は以下の方法で行う。モバイルノード３７０４に「ユーザ３７０６のモバイルノード３７０５がセンサネットワークに接続されたら、モバイルノード３７０４に通知せよ」というスクリプトを登録しておき、ゲートウェイノード３７０７からモバイルノード３７０４への接続イベントに応じて、モバイルノード３７０４が該スクリプトをゲートウェイノード３７０７を経由してサーバ３７１０に発行する。

サーバ３７１０は該スクリプトを実行する事により、モバイルノード３７０５の接続を待機する。ユーザ３７０６が到来し、モバイルノード３７０５からの接続イベントを該スクリプトのイベント待機コマンドが受け、モバイルノード３７０４に対し、アクション実行完了イベントを発行する。モバイルノード３７０４で該イベントを受け、ユーザ３７０３に提示する事により、ユーザ３７０３はユーザ３７０６の到来を知ることができる。

本機能を従来のセンサネットワークで本機能を実現しようとすると、社員が出張する可能性のある全ての出張先のサーバ３７１０のイベントハンドラに上記機能をあらかじめ登録しておく必要があった。しかし従来のセンサネットワークにこのような個別要求を登録する機能はなく、また全ての出張先にあらかじめ登録するのはサーバ３７１０の処理負荷の点で現実的ではなかった。

本機能はスクリプトの修正により、さらに、「ユーザ３７０６の到来を確認したら、ユーザ３７０６に打合せの都合を聞いて、了解であればユーザ３７０４に通知せよ」というルールに拡張することも容易にできる。モバイルノード３７０５に上記図３５で説明した名札ノードのインタフェースと質問回答要求コマンドを登録しておき、モバイルノード３７０５からの接続イベントの応答処理として該質問回答要求コマンドをモバイルノード３７０５に発行し、結果が応諾である場合にのみモバイルノード３７０４に対し、アクション実行完了イベントを発行するとすればよい。

＜第１２実施形態＞
図３７は、図２に示すクライアント２０５におけるユーザインターフェースの実装例として、スクリプトを生成するためのユーザインタフェースについて説明する。

図２に示すクライアント２０５のスクリプト生成画面では、属性条件式設定画面３８１０、関係条件式設定画面３８１１、論理式設定画面３８１２、全体式設定画面３８１３が表形式に表示される。

属性条件式設定画面３８１０はプルダウンメニュー３８１４および３８１５を持ち、「指定したオブジェクトまたはその属性」３８１４が「指定した状態」３８１５になった時に成立する条件式を表す。関係条件式設定画面３８１１はプルダウンメニュー３８１６、３８１７および３８１８を持ち、「指定したオブジェクトまたはその属性」３８１６と、「指定したオブジェクトまたはその属性」３８１７が、「指定した関係」３８１８を持った時に成立する条件式を表す。論理式設定画面３８１２はプルダウンメニュー３８１９、３８２０および３８２１を持ち、「指定した条件」３８１９と「指定した条件」３８２１が「論理和あるいは論理積」３８２０で成立する時成立する条件式を表す。ここで「指定した条件」は、属性条件式３８１０、関係条件式３８１１、論理式３８１２のいずれかが選択される。全体式設定画面３８１３はプルダウンメニュー３８２２および３８２３を持ち、「指定した条件」３８２２が成立した時、「指定したアクション」３８２３を実行することを設定する画面である。なお、各プルダウンメニューに表示されるデータは、サーバ３７１０の図示しないデータベースから取得したものである。

スクリプト生成画面では、初期状態では全体式設定画面３８１３のみが記述され、ユーザの条件追加操作により属性条件式３８１０、関係上見識３８１１、論理式３８１２を任意に追加できる。

ユーザの簡便な設定を実現するため、ユーザがプルダウンメニューを選択した時に、ユーザの選択操作に従って階層的に画面を表示していく方法が考えられる。

プルダウンメニュー３８１４、３８１６、３８１７ではいずれもオブジェクトまたはその属性を指定する。初めにオブジェクトのスキーマ表示画面３８０５を表示し、オブジェクトの種類を選択させる。オブジェクトの種類は例えば場所（施設名）、領域、人物が考えられる。ユーザが場所を選択すると、場所選択画面３８０３を表示し、場所の選択をさせる。

ユーザがさらに場所の属性を設定したい場合、属性選択画面３８０１を表示し、その場所に従った属性を選択させる。画面３８０５でユーザが領域を選択すると、領域選択画面３８０４として地図を表示し、マウスによる矩形ないしポリゴン入力により、領域を選択させる。ユーザがさらに領域の属性を設定したい場合、属性選択画面３８０２を表示する。画面３８０５でユーザが人物を選択すると、人物選択画面３８０６を表示し、人物の選択をさせる。ユーザがさらに人物の属性を設定したい場合、属性選択画面３８０７を表示し、その人物の属性を選択させる。

プルダウンメニュー３８１５ではオブジェクトまたは属性の状態を指定する。初めに関係選択画面３８２４を表示してユーザに関係を選択させ、その後定数値入力画面３８０８を表示して値の入力をさせる。同様にプルダウンメニュー３８１５では二つのオブジェクトまたは属性間の関係を指定する。初めに関係選択画面３８０９を表示してユーザに関係を選択させ、その後定数値入力画面３８０８を表示して値の入力をさせる。

このようなグラフィカルユーザインタフェースを用いることにより、スクリプトを生成するための情報を収集することができる。

図３８を用いて、図３６に示したサーバ３７１０または図２に示すサーバ２０３の実装例として、図３７のユーザインタフェースで入力されたユーザ要求をスクリプトに変換する方法について説明する。

図３８において、スクリプト３９０１を図３７のユーザインタフェースで入力されたユーザ要求とする。これは例えば、図３７の関係条件式設定画面３８１１を用いて、プルダウンメニュー３８１６に対し画面３８０６で「山田氏」を選択し、プルダウンメニュー３８１７に対し画面３８０３で「第一会議室」を選択し、プルダウンメニュー３８１８において「包含関係」を選択し、全体式設定画面３８１３を用いて、プルダウンメニュー３８２２に対し、上述した関係条件式３８１１を選択し、プルダウンメニュー３８２３に「山田氏が来ました」というメッセージを表示することを設定することにより得られる。スクリプト３９０１は宣言型言語であり、ユーザの要求を述べているのみであり、どのように実行するかについては説明されていない。これを初期式とし、変換する事により、終了式３９０６に変換する。終了式３９０６は、「データベースから、ＸＰａｔｈで指定された条件に従い、第一会議室という名称の会議室に存在する人検知センサノードのノードＩＤを取得し、該ノードＩＤに対し、部分スクリプトの実行を要求する、部分スクリプトは、『ノード検知イベントを検知したら、その検知したノードのノードＩＤが、データベースから取得した、山田という名前の人物の持つ名札ノードのノードＩＤと等しいかを判定する』という内容を持つ。またその結果が返戻されたら、山田氏が来ましたというメッセージを表示する」ということを述べている。

これは初期式３９０１に定理３９０２、３９０３を当てはめる事により実現できる。定理３９０２、３９０３は、図５に示すサーバの、データベース７１２に格納される。定理３９０２は、「人物が部屋内にいる≡人物の名札ノードが部屋内にいる」という論理を示し、定理３９０３は、「名札ノードが部屋内にいる≡名札ノードが部屋内の人検知センサに検知される」という論理を示す。これにより初期式３９０１のｉｓＩｎｓｉｄｅ以下のコマンドは、中間式３９０４に展開される。中間式３９０４で使用されるコマンドｉｓＩｎｓｉｄｅ２は、テンプレート３９０５として定義されている。その結果、初期式３９０１は終了式３９０６に展開することができる。このように、サーバ２０３の管理者があらかじめ定理３９０２、３９０３、テンプレート３９０５を用意しておく事により、ユーザの要求である宣言型言語の初期式３９０１を、手続き型言語である終了式３９０６に変化させることができる。この終了式３９０６を実行する事により、目的の結果が得られる。

＜第１３実施形態＞
図３９は、第１３の実施形態を示し、前記第１実施形態のセンサネットワークを進捗管理を行うプロジェクト管理システムに適用した例を示す。

一般に、プロジェクト管理の分野では、ＴＯＣ（Theory Of Constraints：制約理論）などの理論体系の整備が進み、様々なプロジェクト管理システムが提供されてきている。しかし従来のプロジェクト管理システムは、あくまでプロジェクト管理者の支援を行うことを目的とした、静的で受動的なシステムであった。本発明を適用することにより、動的で能動的なプロジェクト管理システムを構築することができる。

図３９を用いて、本発明によるプロジェクト管理システムの機能を説明する。プロジェクト管理を行うサーバ４００１は進捗管理グラフ４００５を用い、プロジェクトを構成する各業務の進捗を管理する。進捗管理グラフ４００５では、あらかじめプロジェクト管理者４００４が予測した業務の必要日数から算出した予定曲線４００６と、プロジェクトの実際の進捗を示す進捗曲線４００７を管理する。業務を担当する作業者４００２は、定期的にアクション４０１０により、進捗曲線４００７を更新していく。

本発明を適用することにより、様々なイベントハンドリングが可能となる。例えば業務の進捗が一定の割合４００８を越えた時点をイベントとして検知し、該業務の後に続く業務の作業者４００３にイベントを発行し、後に続く業務の開始日を通達することができる。また、プロジェクトの進捗が予定より一定日数遅れた時点をイベントとして検知し、作業者４００２にイベント４０１１を発行したり、プロジェクト管理者４００４にイベント４０１３を発行したりすることにより、業務遅延の対策を要求することができる。同様に業務終了予定日の一定日前４００９をイベントとして検知し、プロジェクトの進捗が予定より遅れている場合に作業者４００２にイベント４０１１を発行したり、プロジェクト管理者４００４にイベント４０１３を発行したりすることにより、業務遅延の対策を要求することができる。作業者４００２が進捗登録アクション４０１０を行わない場合にも、タイマイベントにより登録アクション４０１０がないことを判定し、作業者４００２にイベント４０１１を発行して入力を要求したり、プロジェクト管理者４００４にイベント４０１３を発行して、対策を要求することができる。

＜補足＞
前記第１実施形態に示したスクリプト実行エンジンであるスクリプトマネージャは、図２のセンサネットワークを構成するセンサノード２０１、ルータノード２０２、サーバ２０３、ＷＥＢサービス２０４、クライアント２０５の全てあるいはいずれかのノードにおける、イベントハンドリングを行いたいノードに設置する。図１では省略したが、ルータノード２０２は直列に複数個存在してもよい。

また、前記第１実施形態において、イベントハンドリングが不要なノードからスクリプトマネージャを削除してもよい。センサノード２０１からスクリプトマネージャ４０４を削除した場合、センサノード２０１は固定的なイベントを発行する。ルータノード２０２からスクリプトマネージャ４０９を削除した場合、通信経路途中でのイベント集約処理を行わない。サーバ２０３、WEBサービス２０４、クライアント２０５からスクリプトマネージャを削除した場合、それぞれの機器ではイベントハンドリングを行わない。したがって、イベントハンドリングが必要なノードにスクリプトマネージャを実装すればよいのである。

以上のように、本発明では、センサネットワーク上の分散イベントハンドリングの動作フローを、動的に変化していくユーザ目的に対応して任意の時点で動的に変更できるため、単一のセンサネットワーク上に多様なユーザ目的を反映することができる。このため設置・メンテナンス費用を複数のユーザで費用分担できるため、広域環境を観測する大規模センサネットワークインフラ基盤が実現できる。

１０２ スクリプト
１０６、１１７ 部分スクリプト
２０１ センサノード
２０２ ルータノード
２０３ サーバ
２０５ クライアント
４０４、４０９、４１４、４１９ スクリプトマネージャ

Claims (6)

1. 観測した情報に基づいて上位のノードへイベントを送信する第１センサノードおよび第２センサノードと、
   下位のノードへ予め設定したコマンドを含むスクリプトを送信し、前記第１および第２センサノードからのイベントを受信するクライアントノードと、
   前記第１および第２センサノードからクライアントノードへの通信を取り次ぐ中間ノードと、を備えたセンサネットワークシステムにおいて、
   前記クライアントノードは、予め複数のノードに対する処理が設定されたスクリプトを実行し、下位のノードに対するスクリプトを抽出して前記下位ノードへ前記抽出したスクリプトを配布する第１のスクリプトマネージャを有し、
   前記中間ノードは、前記第１のスクリプトマネージャが配布したスクリプトを実行し、当該中間ノードに対する制御を実行し、下位のノードに対するスクリプトを抽出して当該ノードへ前記抽出したスクリプトを配布する第２のスクリプトマネージャを有し、
   前記第１および第２センサノードは、各々前記第２のスクリプトマネージャが配布したスクリプトを実行することで観測した情報に基づくイベントを上位のノードに送信する第３のスクリプトマネージャを有し、
   前記第２のスクリプトマネージャから前記第１センサノードに配布された第１スクリプトと、前記第２センサノードに配布された第２スクリプトは、異なるスクリプトであることを特徴とするセンサネットワークシステム。
2. 前記スクリプトは、前記下位のノードに対するスクリプトを部分スクリプトとして入れ子構造で内包し、
   前記第１のスクリプトマネージャは、自ノードよりも下位のノードに対する部分スクリプトを抽出して前記下位のノードへ部分スクリプトを配布し、
   前記第２のスクリプトマネージャは、自ノードよりも下位のノードに対する部分スクリプトを抽出して前記下位のノードへ部分スクリプトを配布することを特徴とする請求項１に記載のセンサネットワークシステム。
3. 前記スクリプト及び部分スクリプトは、木構造のコマンドとして記述され、
   前記第１ないし第３のスクリプトマネージャは、木構造の根に当たる親コマンドを実行する以前に全ての子コマンドをその出現順に実行し、子コマンドの実行結果をデータに置き換えて親コマンドの引数とすることを特徴とする請求項２に記載のセンサネットワークシステム。
4. 前記コマンドは、当該コマンドの実行完了を待たずに直ちに未完了状態で終了する非同期コマンドを含み、
   前記第１ないし第３のスクリプトマネージャは、前記子コマンドとして非同期コマンドを実行する際には、前記子コマンドに実行を指令した後に、当該子コマンドの親コマンドを未完了状態で終了させて、前記子コマンドからの実行結果の返戻があるまで待機するアクションハンドラを有し、
   前記アクションハンドラは、子コマンドからの実行結果の返戻を契機に、前記未完了状態で終了した親コマンドの実行を再開することを特徴とする請求項３に記載のセンサネットワークシステム。
5. 第１のセンサノードと第２センサノードが観測した情報を中間ノードから上位のクライアントノードへイベントとして順次送信するセンサネットワークのデータ処理方法であって、
   前記クライアントノードまたは中間ノードの上位のノードが、予め複数のノードに対するコマンドが設定されたスクリプトから下位ノードに対するスクリプトを抽出して前記下位ノードへ前記抽出したスクリプトを配布する第１のステップと、
   前記スクリプトから自ノードに対する処理を各々実行する第２のステップと、
   前記下位ノードが前記配布されたスクリプトを受信し、当該ノードに対する処理を実行する第３のステップと、
   前記下位ノードが前記スクリプトから自ノードよりも下位のノードに対するスクリプトを抽出し、下位ノードに対するスクリプトが存在すれば前記下位ノードへ前記抽出したスクリプトを配布する第４のステップと、を含み、
   前記第４のステップは、
   前記自ノードよりも下位のノードとして前記第１のセンサノードと第２センサノードに前記スクリプトを配布し、前記第１および第２センサノードは、各々前記配信されたスクリプトを実行することで観測した情報に基づくイベントを上位のノードに送信するステップ含み、
   前記第２のスクリプトマネージャから前記第１センサノードに配布された第１スクリプトと、前記第２センサノードに配布された第２スクリプトは、異なるスクリプトであることを特徴とするセンサネットワークのデータ処理方法。
6. 前記スクリプトは、前記下位のノードに対するスクリプトを部分スクリプトとして入れ
   子構造で内包し、
   前記スクリプトを配布するステップは、自ノードよりも下位のノードに対する部分スク
   リプトを抽出して前記下位のノードへ部分スクリプトを配布することを特徴とする請求項
   ５に記載のセンサネットワークのデータ処理方法。

Images