(57)【特許請求の範囲】
【請求項１】
センサにより取得されるセンシングデータを管理するセンサネットシステムであって、
上記センシングデータを格納する場所を示す格納アドレス情報と上記センサのセンサＩＤ情報との対応づけ及び上記センサＩＤ情報と実世界を表す名称との対応づけを管理する第１の管理部と、
上記センシングデータを格納する格納部と、
上記実世界を表す名称及び上記実世界を表す名称に対応するセンシングデータを出力する第１の制御部とを有し、
上記出力されるセンシングデータは、上記第１の管理部により上記センサＩＤ情報を介して上記実世界を表す名称と対応づけられた上記格納アドレス情報が示す場所に格納されたセンシングデータを、上記格納部から読み出したものであり、
上記第１の管理部は、上記センサＩＤ情報と上記実世界を表す名称を登録するモデルタイプを登録し、
上記モデルタイプは、上記モデルタイプを識別する名称と、上記モデルタイプに表示する情報を規定するエントリとから構成され、
上記第１の管理部は、上記エントリに上記センサＩＤ情報及び上記実世界を表す名称を登録することにより、上記センサＩＤ情報と上記実世界を表す名称との対応づけを管理するセンサネットシステム。
【請求項２】
請求項１に記載のセンサネットシステムにおいて、
上記第１の管理部はさらに、上記エントリに、上記実世界を表す名称を補足する属性情報を登録するセンサネットシステム。
【請求項３】
請求項２に記載のセンサネットシステムにおいて、
上記属性情報は、上記センサが配置される建物、フロア、場所の収容人数、の少なくとも何れかを示す情報であるセンサネットシステム。
【請求項４】
請求項１に記載のセンサネットシステムにおいて、
第１のサーバと、上記センサを有するセンサノードに接続される第２のサーバと、クライアント端末を有し、
上記第１のサーバは、上記第１の管理部及び上記第１の制御部を有し、
上記第２のサーバは、上記格納アドレス情報及び格納部を有し、
上記第１の管理部は、上記格納アドレス情報と上記第２のサーバのサーバＩＤ情報との対応づけ、上記サーバＩＤ情報と上記センサノードのセンサノードＩＤ情報との対応づけ、
上記センサノードＩＤ情報と上記センサＩＤ情報との対応づけを管理することにより、上記格納アドレス情報と上記センサＩＤ情報との対応づけを管理し、
上記クライアント端末は、
入力部と、
上記入力部を介して入力された上記センサＩＤ情報、及び上記センサノードＩＤ情報及び上記サーバＩＤ情報を少なくとも含むデバイス情報を管理する第２の管理部と、
上記管理されたデバイス情報を上記第１のサーバに出力する第２の制御部とを有し、
上記第１の管理部は、上記出力されたデバイス情報を管理し、
上記第１の制御部は、上記第１の管理部によって管理されたデバイス情報から選択される関連デバイス情報を上記第２のサーバに出力し、
上記第２のサーバは、上記出力された関連デバイス情報を管理し、
少なくとも上記センサＩＤ情報及び上記実世界を表す名称が登録された上記モデルタイプをモデル情報とし、
上記第２の管理部は、上記入力部を介して入力される上記モデル情報を管理し、
上記第２の制御部は、上記管理されたモデル情報を上記センサネットシステムに出力し、
上記第１の管理部は、上記出力されたモデル情報を管理するセンサネットシステム。
【請求項５】
請求項４に記載のセンサネットシステムにおいて、
上記第１の制御部は、上記モデル情報の指定を受け、上記指定を受けたモデル情報に登録された上記センサＩＤ情報を読み出し、上記読み出したセンサＩＤ情報を、上記センサＩＤ情報をもつセンサが取得したセンシングデータに置換するセンサネットシステム。
【請求項６】
請求項４に記載のセンサネットシステムにおいて、
上記第２の制御部は、上記入力部を介して指定される上記モデル情報から上記センサＩＤ情報を取得し、上記センサＩＤ情報を上記第１のサーバに出力し、
上記第１の制御部は、上記出力されたセンサＩＤ情報及び上記センサＩＤ情報に対応づけられた上記格納アドレス情報に基づいて、上記第２のサーバに上記センシングデータを要求し、
上記第２のサーバは、上記要求されたセンシングデータを検索し、上記検索されたセンシングデータを上記第１のサーバに出力し、
上記第１の制御部は、受信した上記センシングデータを上記クライアント端末に出力し、
上記第２の制御部は、上記センサＩＤ情報を、受信した上記センシングデータに置換するセンサネットシステム。
【請求項７】
請求項４に記載のセンサネットシステムにおいて、
上記第１または第２の管理部は、上記デバイス情報及びモデル情報を予め記述したデータを読み込むことにより管理するセンサネットシステム。
【請求項８】
センサにより取得されるセンシングデータを管理するセンサネットシステムにおけるセンサネットシステムデータ管理方法であって、
上記センシングデータを格納する場所を示す格納アドレス情報と上記センサのセンサＩＤ情報とを対応づけ、
上記センサＩＤ情報と実世界を表す名称とを対応づけ、
上記センシングデータを格納し、
上記実世界を表す名称及び上記実世界を表す名称に対応するセンシングデータを出力し、
上記出力されるセンシングデータは、上記センサＩＤ情報を介して上記実世界を表す名称と対応づけられた上記格納アドレス情報が示す場所に格納されたセンシングデータを読み出したものであり、
上記センサＩＤ情報と上記実世界を表す名称とを登録するモデルタイプを登録し、
上記モデルタイプは、上記モデルタイプを識別する名称と、上記モデルタイプに表示する情報を規定するエントリとから構成され、
上記エントリに上記センサＩＤ情報及び上記実世界を表す名称を登録することにより、上記センサＩＤ情報と上記実世界を表す名称との対応づけを管理するセンサネットシステムデータ管理方法。
【請求項９】
請求項８に記載のセンサネットシステムデータ管理方法において、
上記実世界を表す名称は、上記センサが配置される場所、物、及び人の少なくとも何れかを表すセンサネットシステムデータ管理方法。
【請求項１０】
請求項８に記載のセンサネットシステムデータ管理方法において、
上記センサネットシステムは、上記センサを有するセンサノードに接続されるサーバを有し、
上記格納アドレス情報と上記サーバのサーバＩＤ情報とを対応づけ、
上記サーバＩＤ情報と上記センサノードのセンサノードＩＤ情報とを対応づけ、
上記センサノードＩＤ情報と上記センサＩＤ情報とを対応づけることにより、上記格納アドレス情報と上記センサＩＤ情報とを対応づけるセンサネットシステムデータ管理方法。
【請求項１１】
請求項８に記載のセンサネットシステムデータ管理方法であって、
少なくとも上記センサＩＤ情報及び上記実世界を表す名称が登録された上記モデルタイプをモデル情報とし、
上記モデル情報の指定を受け、
上記指定を受けたモデル情報に登録された上記センサＩＤ情報を読み出し、
上記読み出したセンサＩＤ情報を、上記センサＩＤ情報をもつセンサが取得したセンシングデータに置換するセンサネットシステムデータ管理方法。
【請求項１２】
センサにより取得されるセンシングデータを管理するセンサネットシステムに、センサネットシステムデータ管理方法を実行させるセンサネットシステムデータ管理プログラムであって、
予め登録された、上記センサのセンサＩＤ情報と実世界を表す名称を登録するモデルタイプを読み出し、
上記モデルタイプは、上記モデルタイプを識別する名称と、上記モデルタイプに表示する情報を規定するエントリとから構成され、
上記エントリに上記センサＩＤ情報及び上記実世界を表す名称を登録し、上記モデルタイプの指定を受け、上記指定されたモデルタイプに登録された上記センサＩＤ情報を読み出し、
上記読み出されたセンサＩＤ情報を上記センサＩＤ情報をもつセンサが取得したセンシングデータに置換するセンサネットシステムデータ管理プログラム。
【請求項１３】
請求項１２に記載のセンサネットシステムデータ管理プログラムであって、
上記実世界を表す名称は、上記センサが配置される場所、物、及び人の少なくとも何れかを表すセンサネットシステムデータ管理プログラム。
【請求項１４】
請求項１２に記載のセンサネットシステムデータ管理プログラムであって、
上記エントリは、上記エントリに割り当てる名称と、上記エントリのデータ種別を示す文字列及び上記センサを含むエントリタイプとから構成されるセンサネットシステムデータ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された多数のセンサから発生するセンシングデータの管理方式および利用方式に関する。
【背景技術】
【０００２】
この明細書で参照される文献は以下の通りである。文献は、その文献番号によって参照されるものとする。
【特許文献１】特開２００５−１２２４９１号公報
【０００３】
最近は、大量の小型の無線センサノードから得られるセンシングデータを、ネットワークを通じて取得するセンサネットワークの技術が発展しつつある。現在のインターネット上のサービスは仮想空間上閉じているのに対して、センサネットワークは実空間と融合している点において、現在のインターネットと本質的に異なる。実空間との融合によって、時間、位置など状況依存型のさまざまなサービスが実現できる。つまり、現実世界の情報を大量のセンサデータとして取り込み、ネットワークを通して離れた場所にて、災害監視、設備監視、セキュリティなどの目的で利用することができる。汎用的なセンシングインフラをさまざまなアプリケーションに使用できるのもセンサネットの特徴である。特許文献１には、センシング環境とアプリケーション環境を独立に管理して、センシング環境を複数のアプリケーションで共有して利用する技術が開示されている。
従来の情報検索システムでは、対象となる静的な電子情報をネットワーク上のデータベースに入力して蓄積する。ユーザは、蓄積されているデータの情報を持つディレクトリから、キーワードや属性を元にした検索、ソーティングやビューの切り替えにより、所望する情報を取得することが可能である。
これに対して、センサネットのような物理的な電子機器を実空間上に多数配置することにより、時系列的に連続発生するセンシング情報の取得を行うシステムを考えた場合、物理的な電子情報の発生源（小型センサノードなど）とユーザに提示するセンシング情報との関連付け（マッピング）を汎用的かつ柔軟に実現する手段および手順が必要となる。そのため、従来の情報検索システムをそのまま適用することはできない。
例えば特許文献１では、センシング環境を特定のアプリケーションに対して予め関連付けを行い、センシングデータを予め指定したアプリケーションに対してルーティングするための技術が開示されている。しかし、センサネットの特徴である大量のセンシングデータについて、ユーザにわかりやすく提示するという点については記載されていない。
本発明の目的は、実世界のセンサネットから時系列的に連続発生するデータをユーザに対してわかり易く提示することである。
そのために、物理的な電子情報の発生源（小型センサノードなど）とユーザに提示するセンシング情報との関連付け（マッピング）を汎用的かつ柔軟に実現するシステム、手順、および、ユーザインタフェースを提供する。
具体的には、実空間上におけるセンサノードおよびセンサノードに搭載されているセンサの識別管理やセンシング情報種別の管理方法を提供する。さらには、センシング情報を特定して正確に取得するために必要な、無線基地局、サーバ、センサノードの関連付け方法、また、データ発生源（センサノード）の空間的な位置管理及びその位置管理を容易にするための関連属性情報の付与方法を提供する。
【発明の開示】
【０００４】
センサネットワークの管理部を、無線センサノードと無線基地局とデータ管理サーバの関連付けを行うためのデバイス管理テーブル、デバイス情報を含めて複数の属性を付与することのできる実世界モデルテーブル、これらの情報登録・検索を行うための登録・検索処理部、およびテーブル間のデータの関連付けを行うデータ管理部にて構成する。
【図面の簡単な説明】
【０００５】
図１  集中データ管理型センサネットワークのシステム構成図の一例。
図２  分散データ管理型センサネットワークのシステム構成図の一例。
図３  一般的な分散データ管理システムの一例。
図４  センサネットシステムの機能を実現するミドルウェアの論理構造の一例
図５  分散データ管理型センサネットワークシステムのブロック図の一例。
図６  無線センサノードのブロック図の一例。
図７  無線センサノードの動作状態における時間と消費電流の関係を示す図の一例。
図８  複数のセンサを搭載する無線センサノードのブロック図の一例。
図９  デバイス管理テーブルの構成図の一例。
図１０  実世界モデルテーブルの構成図の一例。
図１１  デバイス情報設定画面の一例。
図１２  デバイス情報設定のフローの一例。
図１３  ＲＳテーブルの設定例。
図１４  ＧＷテーブルの設定例。
図１５  センサノードテーブルの設定例。
図１６  センサテーブルの設定例。
図１７  センサノードタイプの設定例。
図１８  モデルタイプを登録するためのモデル情報設定画面の一例。
図１９  モデルタイプの登録フローの一例。
図２０  モデルタイプ新規作成時の画面の一例。
図２１  モデルを登録するためのモデル情報設定画面の一例。
図２２  モデル登録のフローの一例。
図２３  データ閲覧画面の一例。
図２４  データ閲覧画面の一例。
図２５  データ閲覧画面の一例。
図２６  データ閲覧画面の一例。
図２７  デバイス・モデル設定のフローの一例。
図２８  モデル設定のフローの一例。
図２９  センサシングデータの格納フローの一例。
図３０  センサシングデータの要求フローの一例。
図３１  モデルタイプ新規作成時の画面の一例。
図３２  デバイス情報設定画面でアラーム通知を行う図の一例。
図３３  デバイス情報設定のファイル記述例。
図３４  デバイス情報およびモデル情報設定のファイル記述例。
図３５  モデルタイプテーブルの設定例。
【発明を実施するための最良の形態】
【０００６】
【実施例１】
【０００７】
以下、本発明の一実施形態を添付図面に基づいて説明する。図３はネットワークＮＷＫ（ＬＡＮやインターネットなど）を使用した一般的な分散データ管理システムの例を示している。ユーザ端末ＵＳＴからユーザによって作成されたコンテンツデータは、インターネットなどのネットワークＮＷＫを介してサーバなどのデータ管理部ＤＴＭに送信され、データ管理部に接続されたディスク装置ＤＳＫに格納される。
ネットワーク上のデータの所在は、データディレクトリＤＤＲによって管理されている。ネットワーク上のユーザは、このデータディレクトリＤＤＲにアクセスして所望のデータの所在を入手した後、データへのアクセスを行う。例えば、インターネット上のデータへのアクセスは、検索サイト（前述のデータディレクトリに相当するサーバ）から所望のデータの所在をＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）という形で取得して行うことが多い。ＵＲＬはインターネット上に存在するドキュメントやリソース等の所在を一意に識別するためのアドレスであり、プロトコル名、サーバのドメイン名、ドキュメントのパス名で構成されている。
これに対して、センサネットワークのシステムは、データソースが実世界と密に結びついている点で異なっている。図１、図２は、本発明に適用されるセンサネットワークシステムの構成例を示している。
＜システム構成の概要＞
まず、システム構成の概要について説明する。センサネットシステムは、センサネットのデータ処理を集中的に行う場合（図１）と、分散的に行う場合（図２）が考えられる。ここで、集中的なデータ処理の場合には、センサノードから送信されるデータの処理・管理をシステム内でただひとつのセンサネットサーバＳＮＳで行い、分散的なデータ処理の場合にはセンサデータの基本的な処理・管理をネットワーク上に分散配備された分散データ処理サーバＲＳで行う。
センサノードＳＮは、所定の位置に設置され、あるいは所定の物あるいは人に取り付けられ、環境に関する情報や取り付けられた物に関する情報を収集し、その情報を無線基地局ＧＷに対して送信する。
各無線基地局ＧＷでは、１つまたは複数のセンサノードＳＮからのデータを受信することができる。また、無線基地局を通さずに有線でセンシング情報を送信するセンサノードＦＳＮが使用される場合もある。
集中データ処理を行う場合には、図１に示すように、各無線基地局ＧＷは、ネットワークＮＷＫを介して各センサノードＳＮからのデータを、センサネットサーバＳＮＳにて収集して管理する。
分散データ処理を行う場合には、図２に示すように、各無線基地局ＧＷは、ネットワークＮＷＫ−２を介して分散データ処理サーバＲＳに接続される。分散データ処理サーバＲＳの接続数は、システム規模によって可変とすることができる。
センサネットサーバＳＮＳのデータ処理部ＲＳＢ、もしくは、各分散データ処理サーバＲＳは、無線及び有線センサノード（以下、単にセンサノードという）が検出したデータ等を格納するディスク装置ＤＳＫと、図示しないＣＰＵ及びメモリを備えて所定のプログラムを実行する。所定のプログラムが実行されると、後述するようにセンサノードからの測定データを収集し、予め規定した条件に従って、データの格納、データの加工、さらには、他のサーバ（分散データ処理の場合には、ディレクトリサーバＷＳも含む）への通知やデータ転送などの処理を行う。
ネットワークＮＷＫ−１には、センシング情報を利用しセンサネットワークの設定及び管理を行うユーザ・管理者端末ＴＲＭが接続される。
ここで、センサノードから送信されるセンシングデータは、主に、センサノードを識別する固有のＩＤおよびセンシングされた数値データより構成され、数値データは時系列に応じて変化する。このセンシングデータは、そのままの形式では、ユーザが容易に理解する形式にはなっていない。そこで、センサネットサーバＳＮＳのディレクトリ部ＷＳＢ（集中データ処理の場合）もしくはディレクトリサーバＷＳ（分散データ処理の場合）では、センサノードの出力データとユーザが理解可能な実世界モデル（ヒト、モノ、状態、など）との対応関係を保持している。この対応関係を利用することにより、ユーザはデータ処理部ＲＳＢ（集中データ処理の場合）もしくは分散データ処理サーバＲＳ（分散データ処理の場合）のディスク装置ＤＳＫにて保存されている測定データに対して、理解の容易な形式でアクセスすることができる。
図４は、センサネットシステムの機能を実現するためのミドルウェアＳＮＭの論理構造を示したものである。ミドルウェアＳＮＭは、ディレクトリサーバ（ＷＳ）機能、データ処理サーバ（ＲＳ）機能、および、無線基地局（ＧＷ）機能により構成されている。
図５は、分散データ処理のセンサネットワークの詳細機能ブロック図であり、以下、各ブロックの詳細について説明する。
＜無線基地局ＧＷ＞
センサノードＳＮからのセンシングデータを受信する無線基地局ＧＷ、は以下の構成要素をもつ。コマンド制御部ＣＭＣ−Ｂは、分散データ処理サーバＲＳ内のコマンド制御部との間でコマンドの送受信を行う。また、センサノードに対して出力タイミングの設定変更などのコマンドを送受する。
センサノード管理部ＳＮＭは、センサノードの状態管理（稼動状態、残電力など）を行う。
イベント監視部ＥＶＭでは、センサノードの故障検出や、センサノードからの異常なデータの検出を行い、検索結果をセンサノード管理部ＳＮＭに通知する。なお、センサノードから無線基地局ＧＷに対しては、無線基地局ＧＷが一意に識別できるＩＤが付与された測定データが送信される。
＜分散データ処理サーバＲＳ＞
分散データ処理サーバＲＳは、以下の構成を備えている。
コマンド制御部ＣＭＣ−Ｄは、無線基地局ＧＷ及び後述するディレクトリサーバＷＳと通信を行って、コマンド等の送受信を行う。
イベントアクション制御部ＥＡＣは、センサノードからの測定データを基地局ＧＷから受信するたびに、測定データに含まれるデータＩＤを取得し、センサノードのＩＤに対応するイベントの発生ルールを読み込んで、イベントの発生の有無を判定する。
さらに、イベントアクション制御部ＥＡＣでは、データＩＤに該当するイベントの発生に対応するアクションを実行する。具体的なアクション実施の内容としては、測定データを加工データに変換したり、測定データと加工データを、データベース制御部ＤＢＣを通じてデータベースＤＢへ格納したり、他のサーバやディレクトリサーバＷＳに通知を行うなどの処理を含む。
ディスク装置ＤＳＫは、基地局ＧＷから受信したセンサノードＳＮの測定データと、これらの測定データを加工した加工データと、基地局ＧＷや無線センサノードＳＮ及び有線センサノードＦＳＮに関する装置データとを、データベースＤＢ内に格納する。
データベース制御部ＤＢＣは、イベントアクション制御部ＥＡＣから送られたセンサノードの出力である測定データＭＤＴをデータベースＤＢに格納する。また、必要あれば測定データＭＤＴに対して数値処理を行ったデータとして、もしくは、他データと融合する（例えば、温度データと湿度データから不快指数を計算する）ことにより得られる加工データＰＤＴとしてデータベースＤＢに格納する。なお、装置データ（例えば、無線基地局ＧＷやセンサノードＳＮの識別子やネットワークアドレスなどの設定情報）については、ユーザ・管理者端末ＴＲＭなどからの要求に応じて更新される。
＜ディレクトリサーバＷＳ＞
ディレクトリサーバＷＳは、以下の要素から構成される。
モデル管理部ＭＭＧは、ユーザが理解し易い実世界のモデル（オブジェクト）と分散データ処理サーバＲＳがセンサノードＳＮから収集した測定データもしくは加工データとの対応関係を、実世界モデルテーブルＭＴＢ２に設定した実世界モデルリストによって管理する。
ディレクトリサーバＷＳは、実世界モデルに相当する測定データもしくは加工データの存在場所の位置情報（ＲＳのＩＰアドレス等）も管理している。つまり、ユーザは、実世界モデルを指定することで、時々刻々と変化するセンサノードの測定情報にアクセス可能となる。なお、実世界モデルは、実世界モデルテーブルＭＴＢ２に格納されている。
検索エンジンＳＥＲは、セッション制御部ＳＥＳが受け付けたオブジェクトに対する検索要求に基づいて、実世界モデルテーブルＭＴＢ２の情報を参照し、測定データの格納先であるＤＢ制御部ＤＢＣ（分散データ処理サーバＲＳ内）に対して検索を実行する。
装置管理部ＮＭＧは、分散データ処理サーバＲＳ、基地局ＧＷ、センサノードＳＮに関する情報をデバイス管理テーブルＤＭＴ２内に登録し、それぞれの装置の状態や、センサノードの状態を管理する。また、これらの検索に対するインタフェースをユーザ・管理者端末ＴＲＭに提供する。装置管理部ＮＭＧが発行する管理コマンドとしては、例えば、リセット、パラメータ設定、データ消去、データ転送、定型イベント／アクション設定等がある。
ディレクトリサーバＷＳ内のアクション制御部ＡＣＣは、分散データ処理サーバＲＳのイベントアクション制御部ＥＡＣやコマンド制御部ＣＭＣ−Ｄと通信を行って、ユーザ・管理者端末ＴＲＭからのイベントアクションの設定要求を受け付ける。そして、受け付けたイベントまたはアクションの内容を解析し、解析結果に応じたディレクトリサーバＷＳと分散データ処理サーバＲＳ−１〜ｎ間の機能分担を設定する。なお、一つのアクションやイベントは、一つの分散データ処理サーバＲＳだけではなく、複数の分散データ処理サーバＲＳ−１〜ｎに関与する場合もある。
＜センサノードの一例＞
次に、センサノードの構成および動作タイミングについて図６、図７に示す。
図６は、無線センサノードＳＮの一例を示すブロック図である。無線センサノードＳＮは、測定対象の状態量（温度、圧力、位置等）または状態量の変化（低温／高温、低圧／高圧など）を測定するセンサＳＳＲと、センサＳＳＲを制御するコントローラＣＮＴと、基地局ＢＳＴと通信を行う無線処理部ＷＰＲと、各ブロックＳＳＲ、ＣＮＴ、ＷＰＲに電力を供給する電源ＰＯＷ、送受信を行うアンテナＡＮＴから構成される。
コントローラＣＮＴは、予め設定された周期、もしくは不定期にセンサＳＳＲの測定データを読み込み、この測定データに予め設定したセンサノードのＩＤを加えて無線処理部ＷＰＲに転送する。測定データにはセンシングを行った時間情報をタイムスタンプとして与える場合もある。
無線処理部ＷＰＲは、コントローラＣＮＴから送られたデータを基地局ＧＷに送信する。
また、無線処理部ＷＰＲは無線基地局ＧＷから受信したコマンドなどをコントローラＣＮＴに送信し、コントローラＣＮＴは受信したコマンドを解析して、所定の処理（例えば、設定変更など）を行う。
コントローラＣＮＴは、電源ＰＯＷの残電力（または充電量）を監視し、残電力が予め設定されたしきい値を下回ると、無線処理部ＷＰＲから無線基地局ＧＷに対して警報を送信する。
無線処理部ＷＰＲでは、限りのある電力で長時間測定を行うため、図７で示すように、間欠的に動作して、電力消費を低減している。図７において、スリープ状態ＳＬＰではコントローラＣＮＴはセンサＳＳＲの駆動を停止し、所定のタイミングでスリープ状態から動作状態に切り替わって、センサＳＳＲを駆動して測定データを送信する。
また、電源ＰＯＷは、電池もしくは太陽電池や振動発電などの自律発電機構を具備する構成としても良い。
図６では、一つの無線センサノードＳＮに一つのセンサＳＳＲを備えた例を示したが、図８のように２つ以上の複数のセンサ、例えば温度センサＳＳＲＡと湿度センサＳＳＲＢをひとつのセンサノード上に配置することもできる。
＜ユーザ・管理者端末ＴＲＭ＞
ユーザ・管理者端末ＴＲＭは、以下の要素より構成される。
登録・検索処理部ＲＳＰでは、ＧＵＩ（グラフィカル・ユーザ・インタフェース）により、デバイス情報（ＳＮ、ＧＷ、ＲＳ）や実世界モデルの登録、センシングデータの検索処理のインタフェースを提供する。
ここで、実世界モデルとは、通常、数値やＩＤ情報で表されるセンシングデータに対して、これを隠蔽し名前や場所などのモデル名を割り当てることで、ユーザからのデータ利用を容易にするものである。
データ管理部ＤＭは、登録・検索処理部ＲＳＰからの指示を受けて、デバイス情報（ＳＮ、ＧＷ、ＲＳ）及び実世界モデルを、デバイス管理テーブルＤＭＴ１、実世界モデルテーブルＭＴＢ１にそれぞれ登録し、センシングデータの検索処理をセンシングデータベースＳＳＤに対して行うなどデータ管理を行う。
ここでデバイス管理テーブルＤＭＴ１は、図９に示すように、センサ毎の設定を行うセンサテーブルＳＳＴＢ、センサノード毎の設定を行うセンサノードテーブルＳＮＴＢ、センサノードの形式を指定するセンサノードタイプＳＮＴＰ、無線基地局ＧＷの設定を行うＧＷテーブル、ＧＷＴＢ、および、ＲＳの設定を行うＲＳテーブルＲＳＴＢより構成される。
このように、デバイスの機能階層毎の設定を分離して行うことで、新規センサノードの追加や、既存センサノードへのセンサのみの追加などを容易に行うことができる。さらに、センサノードが故障してセンサノードの交換が必要となる場合等においても、モデル名を変更する必要は無く、モデル名とセンシングデータとの対応関係のみを変更すればよいので、ユーザはセンサノードの物理的な違いを意識する必要がない。
さらに、ＲＳテーブルＲＳＴＢは、図１３に示すように、ひとつのＲＳ毎に、その管理情報の要素として、装置管理上ユニークなＩＤ、ネーム、ＩＰアドレス、および、ポート番号を持つ。
ＧＷテーブルＧＷＴＢは、図１４に示すように、ひとつのＧＷ毎に、その管理情報の要素として、装置管理上ユニークなＩＤ、ネーム、接続されるＲＳのネーム、ＩＰアドレス、および、ポート番号、無線の送受信電力（Ｐｏｗｅｒ）、無線チャネルの識別番号であるＲａｄｉｏ  Ｃｈａｎｎｅｌ、無線ネットワークを識別するためのＩＤであるＰＡＮ  ＩＤを持つ。
センサノードテーブルＳＮＴＢは、図１５に示すように、ひとつのセンサノードＳＮ毎に、その管理情報の要素として、ＰＡＮ  ＩＤ上でユニークなＩＤ、ネーム、接続されるＲＳのネーム、センサノードタイプ、ノード単位の固体識別番号であるＧｌｏｂａｌ  ＩＤ、残電力情報（Ｂａｔｔｅｒｙ）、センシング間隔、無線の送受信電力（Ｐｏｗｅｒ）、無線チャネル、および、残バッテリ量に応じて警報を出すためのしきい値情報、を持つ。ここで、センサノードタイプとは、温度・湿度センサノードや健康モニタ用センサノードなどのセンサノード種別を区別するためのものである。
センサテーブルＳＳＴＢは、図１６に示すように、その管理情報の要素として、個々のセンサ（例えば、温度センサや湿度センサ）の単位で、システム上でユニークなＩＤ、ネーム、搭載されるセンサノードＳＮのネーム、センサノードタイプ、センシング間隔、および、センシング値の上限・下限しきい値、を持つ。センシング値の上限・下限しきい値は、センシング値の異常判定に用いるためのものである。
また、図１５、１６で用いるセンサノードタイプを識別するためのＩＤを管理するためのテーブルを有する（図１７）。このように、センサノードタイプの識別子（ＩＤ）に対して、対応するネームを割り当てることにより、図１５、図１６の各テーブルでのセンサノードタイプをわかり易く表示することができる。
図１３から図１７に示されたそれぞれのテーブル行の最左列のＩＤ情報は、エントリの追加時にシステムが自動的に割り当てを行う。
＜デバイス情報の設定手順＞
次に、これらデバイス情報の設定手順についての説明を行う。
デバイス情報の設定は、登録・検索処理部ＲＳＰにて提供されるＧＵＩを通じて行う。デバイス情報の設定に使用するＧＵＩであるデバイス情報設定画面ＤＶＳＣを図１１に示す。
この画面の、デバイスタイプ画面ＤＶＴ上のデバイス種別を選択すると、該当するテーブルの一覧がデバイステーブルＤＶＴＢに表示される。デバイスタイプＤＶＴにて、ＲＳ、ＧＷ、Ｓｅｎｓｏｒ  Ｎｏｄｅ  Ｔｙｐｅ、Ｓｅｎｓｏｒ  Ｎｏｄｅ、Ｓｅｎｓｏｒをそれぞれ選択すると、選択内容に応じて、図１３から図１７に示すテーブル内容が表示される。これらのテーブルは、デバイスとしての増設・減設を考慮したユニットとなっている。また、ひとつのセンサノードから複数種類のセンシングデータが発生する場合を考慮して、センサノードＳＮ上のセンサについて、センサ単位でのテーブル管理を行っている。
図１２はデバイス情報設定フローを示したものである。
まず、ステップ１０１としてＲＳに関する情報をＲＳテーブルＲＳＴＢに設定する（図１３）。
次のステップ１０２にてＧＷに関する情報をＧＷテーブルＧＷＴＢに設定する。ここで、ＧＷがどのＲＳの配下に接続されるかという接続関係については、既にステップ１０１で登録されているＲＳのネーム情報を選択することにより行う（図１４）。
次の、ステップ１０３のセンサノードタイプＳＮＴＰ設定では、図１７に示すセンサノードタイプＳＮＴＰの設定を行う。
次のステップ１０４のセンサノードテーブルＳＮＴＢ設定では、個々のセンサノードＳＮについて、設定情報およびどのＲＳに接続されるか、つまり、どのＲＳの配下にて管理されるかについての情報を、既に登録されているＲＳテーブルＲＳＴＢのネーム情報およびセンサノードタイプＳＮＴＰのタイプ情報を選択することにより行う（図１５）。
ここで、センサノードＳＮが移動する場合や電波状態の変化を考慮すると、センサノードＳＮがデータの送受信を行う無線基地局ＧＷが変化する可能性があるため、本例のセンサノードテーブル設定では、センサノードＳＮと無線基地局ＧＷの関係の管理を行っていない。
最後にステップ１０５として、個々のセンサに関する情報の設定をセンサテーブルＳＳＴＢに設定する。個々のセンサがどのセンサノードＳＮに搭載されているか、どのようなセンサノードのタイプであるかを、既に登録されているセンサノードテーブルＳＮＴＢのネーム情報およびセンサノードタイプＳＮＴＰのタイプ情報を選択することにより行う（図１６）。
以上のステップ１０１〜１０５により、各デバイスを対応づけることができる。
また、各デバイスを特定できる情報をＩＤ情報（例えば、センサＩＤ情報であればセンサのＩＤ、センサネームなど）と定義すると、センシングデータを格納するネットワーク上の位置を示す格納アドレス情報（ＩＰアドレス）と分散処理サーバＩＤ情報、分散処理サーバＩＤ情報とセンサノードＩＤ情報、及びセンサノードＩＤ情報とセンサＩＤ情報それぞれが対応付けて登録される。つまり、センサＩＤ情報と格納アドレス情報とを対応づけることができ、センサネットシステム内で一意に識別されるセンシングデータがどのＲＳにて管理されるかを定義することができる。
このようにデバイス情報の設定は、図１２にも示すように、各情報の対応関係を考慮してセンサネットシステムを構築する階層的に上位のものから行う。つまり、分散処理サーバＲＳ、基地局ＧＷ、センサノードＳＮ、センサＳＳの順に設定する。
上記の例では、デバイス情報を新規登録する場合の例を説明したが、サービス中にセンサノードＳＮや無線基地局などのデバイスを追加する場合にも同様な手順で設定を行うことができる。
また、図３３に示すように、各種デバイスの設定情報を例えばＣＶＳファイル（ＣＶＳＦ１）に予め記述しておき、これをデバイス情報設定画面から読み込むことによってデバイス情報の設定を行うこともできる。
＜モデルタイプ情報の設定手順＞
次に、図１８〜図２０を用いて、実世界モデルの雛形となるモデルタイプを登録する手順について説明する。
ここでモデルタイプとは、各デバイス情報、例えばセンサＩＤ情報と実世界を表す名称とを対応づけて登録するために用いるものである。モデルタイプは、そのモデルタイプを識別するための名称と表示する情報を規定するエントリから構成され、情報を表示するときに枠組みとなるものである。名称はモデルタイプごと、つまり規定される情報種別ごとに付される。ユーザは、エントリを登録することにより実世界モデルを構成する要素を決定することができる。これにより、ユーザがセンシングデータなどを閲覧するときの利便性が高まる。
モデルタイプ情報の登録は、登録・検索処理部ＲＳＰにて提供されるＧＵＩを通じて行う。モデルタイプ情報の登録に使用するＧＵＩであるモデル情報設定画面ＭＤＳＣを図１８に示す。モデルタイプ画面ＭＤＴ上のモデルタイプの名称を選択すると、該当するテーブルの一覧がモデルデータＭＤＤとして表示される。モデルデータとは、モデルタイプに従い、具体的な要素の割り当てを行ったものである。
モデルタイプの登録フローについて図１９を用いて説明する。
まず、ステップ２０１にてモデルタイプ名の設定を行う。モデルタイプ名としては、例えば、“温湿度計”など、ユーザが理解しやすいタイプ名を設定する。
次に、ステップ２０２〜２０５にてエントリの行追加とエントリ名の設定、および、エントリタイプの選択を行う。
ここで、エントリ名とはエントリに割り当てる名前、エントリタイプとは文字列、センサ、センサノード、ＧＷ、モデルなどのエントリのデータ種別を示す。図１８の例では、「温湿度計」というモデルタイプＭＤＴに対して、「Ｎａｍｅ」「Ｔｅｍｐｒａｔｕｒｅ」「Ｈｕｍｉｄｉｔｙ」の３つのエントリ名が登録されている。また、図１９の例では、「エントリ名：Ｎａｍｅ、エントリタイプ：文字列」、「エントリ名：Ｔｅｍｐｒａｔｕｒｅ、エントリタイプ：センサ」、「エントリ名：Ｈｕｍｉｄｉｔｙ、エントリタイプ：センサ」という３つのエントリ行を設定する例を示している。
これらの設定は、具体的には、図２０に示すモデルタイプ新規作成のポップアップ画面ＭＤＰＰにて行う。モデルタイプ名入力欄ＭＴＮへモデルタイプ名を入力し、エントリ追加ボタンによりエントリ列を追加した後、エントリ名ＥＮＮへの入力とこれに対応するエントリタイプＥＮＴの選択を行う。エントリ行については、該当するモデルについての付加的な属性情報などを含めて、必要な分だけ追加することができる。
例えば図３１では、図２０の設定に加えて「建物名」と「フロア名」という２つの属性をエントリ追加した場合の例を示している。必要なエントリ追加を行った後（ステップ２０５）、モデルタイプの登録フローを終了する。
図３５に上記手順で生成されるモデルタイプテーブルを示す。モデルタイプテーブルは、前述したようにモデルタイプ名ＭＴＮ、エントリ名ＥＮＮ、エントリタイプＥＮＴより構成される。
このようにエントリを予め定めておくことにより、データを管理する枠組みが決められる。ユーザはそのエントリの欄に直接入力することにより、データの追加や削除を簡便な操作で行うことができ、枠組みに従ってその種別ごとに入力すべき情報が明示されるので矛盾ないデータ整理が可能となる。
＜実世界モデル情報の設定手順＞
最後に、図２１〜図２２を用いて、実世界モデル登録の手順について説明する。図２１に、モデル登録の画面ＭＤＳＣを示す。図２２に示すモデル登録フローを用いて登録手順の説明を行う。
まず、ステップ３０１にてモデルタイプＭＤＴを選択する。
次に、ステップ３０２にて新規モデル登録メニューを選択すると、モデルデータＭＤＤに対応する空欄行が追加される。新規モデル登録メニューの選択は、図２１には図示していないが、右クリックなどで実現される。モデルＩＤについては、新規モデル登録の際に自動で割り当てが行われる。
その他のエントリについては、ステップ３０３〜３０５で示すように２種類ある。
エントリタイプが文字列の場合、ユーザは使用環境に応じて識別可能となるような実世界上の名前を直接入力することができる。この実世界を表す名称には、例えばセンサがセンシングを行う対象、すなわちセンサが配置される場所、位置、物、人、またはその物や人が属する企業などの組織名、プロジェクトＡや実験Ａなどセンシングを行う目的、を示す情報をユーザにとって判り易い形で自由に設定することができる。例えば図２３では、会議室Ａ温湿度計、屋上温湿度計などをモデル名として設定している。これにより、ユーザは容易にデータ管理を行うことができる。
エントリタイプが文字列でない場合つまり前述したセンサノードやセンサなどの場合には、デバイス情報に登録済みのデータから該当するものを選択する。選択されたデバイス情報に登録済みのデータは、ユーザの用途により表示する情報を変更することができる。
例えば、図２１のようにエントリタイプとしてセンサを設定した場合に、ユーザはセンサＩＤ情報としてＳＥ１、ＳＥ２などセンサネームを設定する。ユーザがそのセンサが取得したセンシングデータを閲覧したい場合には、具体的な数値データに変換して表示されるよう設定することができる。つまり、図２３に示すように、会議室Ａ湿温度計のセンサが取得した温度や湿度が具体的な数値として表示される。
また、ユーザが各センサの設置場所を管理したい場合には、具体的な数値としてではなく、センサネームのまま表示させることも可能である。
同様に、エントリタイプとしてセンサ以外のデバイスであるセンサノードやＧＷなどを設定した場合は、デバイスのネーム（ＩＤ情報）をそのまま表示することにより、ユーザはセンサノードの設置場所及びデバイス間の対応関係を管理することができる。
また、エントリタイプにモデルを選択した場合は、ユーザは既に設定されたモデルを設定する。これにより、ユーザはモデル名で各モデル情報を管理することが可能となり、各モデル情報に設定されている情報を容易に識別し管理することができる。
さらに、センサネームなどデバイスＩＤ情報は、センサノード設置者及びセンサネットシステム管理者が把握し易いようにデバイス情報設定時に定めておくとよい。これにより、設置者と管理者が異なる場合でも、センサの管理を円滑に行うことができる。
必要なモデルの追加とこれに対応するエントリ設定が完了すると（ステップ３０６）、モデル登録フローを終了する。
以上の実世界モデル情報の登録により、実世界を表す名称とセンサＩＤ情報との対応づけ及びセンサＩＤ情報を介した実世界を表す名称とＩＰアドレスとの対応づけなど、実世界とデバイス情報との対応づけを管理することが可能となる。
＜デバイス・モデル設定フロー＞
ユーザ・管理者端末ＴＲＭから管理者が設定した、デバイス情報及びモデル情報を、センサネットシステムの各種デバイス（ＷＳ、ＲＳ、ＧＷ）に反映するシーケンス図を図２７に示す。
管理者がデバイス管理テーブルＤＭＴ１と実世界モデルテーブルＭＴＢ１への設定を行った後、ＷＳ転送指示を行う（それぞれの設定画面のアップロードボタンＵＰＬＯＡＤを押す）と、これらの情報がＷＳのデバイス管理テーブルＤＭＴ２と実世界モデルテーブルＭＴＢ２にそれぞれ転送される。
その後、ＷＳからはデバイス情報のみがＲＳのＤＢ内の装置データＤＤＴに転送・登録され、さらに、ＧＷに関連する情報（ＧＷＴＢ）がＧＷに転送・登録される。
ここで、ＷＳからＲＳに転送されるデバイス情報は、デバイス管理テーブルＤＭＴ２すべてではなく、各ＲＳが関連する情報つまり各ＲＳが対応づけられるＧＷやセンサノードに関するデバイス情報テーブルのみ選択的に転送される。この選択的に転送されるデバイス情報を関連デバイス情報と定義する。これにより、ＲＳの記憶容量を効率的に利用することができる。
また、既に設定されているデバイス情報に対して、実世界のモデル情報の設定をユーザ（もしくは管理者）が行う場合の例を図２８に示す。この場合には、ユーザ・管理者端末ＴＲＭから設定した実世界モデルテーブルＭＴＢ１の情報に対して、ＷＳ転送指示を行うだけで良い（設定画面のアップロードボタンを押す）。この情報はＷＳの実世界モデルテーブルＭＴＢ１に転送される。
また、図３３に示すような各種デバイス設定情報、図３４に示すような各種デバイスの設定情報とモデル設定情報を、例えばＣＶＳファイル（ＣＶＳＦ１または２）に予め記述しておき、これを読み込むことによって、デバイス管理テーブルＤＭＴ１と実世界モデルテーブルＭＴＢ１への設定を一括して行うことができる。その後、ＷＳ転送を行う方法を取ることもできる。本方式では複数のデバイス設定を単一のファイル上で記述できるため、大量のセンサノードの情報を一括で初期設定する場合に有効である。
また、ユーザ・管理者端末ＴＲＭで設定されたデバイス管理テーブルＤＭＴ１を各種デバイス（ＷＳ、ＲＳ、ＧＷ）に反映した後は、ＴＲＭは必ずしもデバイス管理テーブルを保持している必要はない。ユーザがデバイス情報を再設定する場合は、ＷＳに登録されたデバイス管理テーブルＤＭＴ２を読み出して行うことができる。
＜データ閲覧＞
図２３〜２４にデータ閲覧の例を示す。データ閲覧は、登録・検索処理部ＲＳＰにて提供されるＧＵＩを通じて行う。データ閲覧画面ＤＴＳＣを図２３に示す。この画面の、モデルタイプＭＤＴ上でモデルタイプ種別を選択すると、該当するモデルの一覧がモデルデータＭＤＤとして表示される。
図２３の例では、図１８のモデルタイプに従って登録されたモデルが３つ表示されている。ここで、センシングを行う対象を表すモデル名はそれぞれ、会議室Ａ温湿度計、会議室Ｂ温湿度計、屋上温湿度計である。
このように、センシングデータをＩＤや数値からなるデバイス情報ではなく、モデル名を使用して検索・閲覧できるようにすることで、ユーザにとってわかりやすい情報提供を行うことが可能となる。
また、観測値が変化すると、エントリが更新される。更新については、定期的にもしくは手動でＤＢ内に格納されている測定データＭＤＴをポーリングするか、もしくは、イベントアクション制御部ＥＡＣの仕組みを利用して、センサからの観測値が変化するタイミングでデータをユーザ・管理者端末にプッシュする。このように、ユーザは最新のセンシングデータを所望のタイミングで取得することができる。
図３０にＲＳのＤＢに格納されたセンシングデータをユーザが取得するフローを示す。
ユーザがユーザ・管理者端末ＴＲＭを通じてモデルデータを選択すると、ＷＳに対してデータ取得の要求が行われる。ＷＳでは、実世界モデルテーブルＭＴＢ１から、該当するデバイス情報を検索し、センシングデータをＲＳのＤＢに対して要求する。具体的には、まず実世界モデルテーブルＭＴＢ（図１０）内のモデル情報ＭＤＴＢに格納されているモデルデータＭＤＤから、該当するセンサネームＳＥを取得する。次に、センサテーブルＳＳＴＢとセンサノードテーブルＳＮＴＢを利用し、取得したセンサネームをもつセンサに対応づけられた、所望のデータが格納されているＲＳ情報を取得する。さらに、ＲＳテーブル（ＲＳＴＢ）から、該当ＲＳのＩＰアドレスとポート番号を取得する。
ＷＳは取得したＲＳ情報及びセンサＩＤ情報に基づいて、ＲＳに対してセンシングデータを要求する。要求をうけたＲＳはＤＢから、該当するセンサノードのセンシングデータを検索し、検索されたデータはＷＳを通じてユーザ・管理者端末ＴＲＭに返送される。ユーザ・管理者端末ＴＲＭに返送されたセンシングデータは、表示画面上に実世界における具体的な数値として、実世界を表す名称と対応づけて表示される。
ユーザ・管理者端末ＴＲＭにおいて最新のセンシングデータの自動取得を行う場合には、上記の手順で、定期的にＤＢ内に格納されている測定データＭＤＴを定期的にポーリング取得する。
なお、センサノードＳＮから発生するセンシングデータは、該当するＲＳのＤＢに対して、定期的もしくは非定期に格納されている。また、各ＲＳのＤＢに格納される複数のセンシングデータは、センサ毎に識別可能な状態であるものとする（図２９）。
センサノードＳＮからのセンシングデータを受信した無線基地局ＧＷは、ＧＷテーブルＧＷＴＢとＲＳテーブルＲＳＴＢの情報（図１３および図１４）により、データを転送すべきＲＳおよびＩＰアドレスを知ることができる。
データ閲覧画面では、モデル名一覧から、特定のモデルのみを選択することで、該当するモデルデータのみを選択表示することも可能となる。特に、登録済みのモデルが多い場合には一画面に表示が収まらないため、図２４に示すように表示対象のモデルのみを簡単にソートして表示できることが望ましい。このようなソート機能により、ユーザの興味対象のデータのみを選択して表示することができる。
図２４にカスタムリストＣＴＬを使用してデータをソートする場合の例を示す。カスタムリストとは、ユーザがデータの表示条件を自由に作成できる機能のことであり、この条件に合致したモデルデータのみを選択表示させることができる。例えば、図２４では「２３度以上の温度」というカスタムリストを設定されている。ユーザが設定されたカスタムリストを選択すると、条件に合うモデルデータ、つまり会議室Ａ温湿度計のみが表示される。
図３２は、デバイス情報設定画面にて、残バッテリの少ないセンサノードＳＮから通知されるアラームイベントＡＬＭを表示する機能の例を示す。
デバイスタイプ（ＤＶＴ）で、各デバイス種別を選択することにより、該当するデバイスの一覧をデバイステーブルＤＶＴＢに表示する。特に、センサノードの場合には、バッテリが切れるとデータの送受信ができなくなる。これを防止するため、ユーザ・管理者端末ＴＲＭにて、いずれかのセンサノードのバッテリ残量がＬＯＷという情報を受信した時点で、ポップアップ画面にアラームイベントＡＬＭを表示する。
本機能により、すべてのセンサノードＳＮを常時監視すること無く、迅速に残バッテリの少ないセンサノードＳＮがあることを知ることができる。また、カスタムリストによりバッテリレベルでデータをソートすれば、残バッテリの少ないセンサノードを特定することも可能である。
このように、実世界モデルタイプを定義し、センサネットシステムから得られるセンシング情報を、実世界と対応したモデルデータという形で表現することで、ユーザは理解し易い形でセンサネットのデータを利用することができる。また、数多くのモデルデータをリスト形式で管理し、カスタムリストで条件設定したものだけを選択することより、ユーザが所望とする対象データのみを容易に表示することができ、データへのアクセス容易化を図ることができる。
【実施例２】
【０００８】
次にデータ閲覧の別の実施例を図２５〜２６に示す。
図２５では、図３１のモデルタイプに従って登録されたモデルが３つ表示されている。図２３のエントリに加えて、建物とフロアのエントリ（エントリタイプは文字列）が追加されている。これにより、センサが配置されている建物名とフロア名を設定することが可能である。さらに、各部屋の収容人数、配置されている場所を表す住所などを、属性情報として設定することもできる。
このように、作成したモデルを補足説明するための属性情報を付与することにより、数多くのモデルデータからのデータ選択表示を容易にする。例えば、図２６に示すように、建物名とフロア名の選択画面で、Ａという名前の建物と１階という条件を選択することにより、全てのモデルデータの中からこの条件に合致するデータのみ（会議室Ａ温湿度計）を表示することができる。
センサネットでは特に、空間的に数多くのセンサを配置してそのセンシングデータを管理するような使用方法が多いと想定される。そのため、空間的な階層を識別するための複数の属性情報をモデルデータに予め付与しておき、これをキーにデータのソーティングを行うことにより、目的とするデータへのアクセス性を飛躍的に向上させることが可能となる。
本発明によって得られる主な効果は以下の通りである。
本発明によれば、使用目的に応じたセンサネットシステムの構築・設定を柔軟かつ容易に行うことができる。また、センサネットにおいて連続的に入力されるデータへのアクセス性を飛躍的に向上させることが可能となる。
なお、本実施形態における処理フローはプログラムとして構成し、各制御部や各管理部はコンピュータでプログラムを読み取ることにより実行できる。
以上、本発明の例を説明したが、本発明は上記実施例に限定されるものではなく、種々変形可能であり、上述した各実施例を適宜組み合わせることが可能であることは当業者に理解されよう。
【産業上の利用可能性】
【０００９】
本発明は、ネットワークに接続された多数のセンサから発生するセンシングデータを、ユーザが判り易くアクセスするために利用されるものである。
【図１】
0004773510.tif 000002
【図２】
0004773510.tif 000003
【図３】
0004773510.tif 000004
【図４】
0004773510.tif 000005
【図５】
0004773510.tif 000006
【図６】
0004773510.tif 000007
【図７】
0004773510.tif 000008
【図８】
0004773510.tif 000009
【図９】
0004773510.tif 000010
【図１０】
0004773510.tif 000011
【図１１】
0004773510.tif 000012
【図１２】
0004773510.tif 000013
【図１３】
0004773510.tif 000014
【図１４】
0004773510.tif 000015
【図１５】
0004773510.tif 000016
【図１６】
0004773510.tif 000017
【図１７】
0004773510.tif 000018
【図１８】
0004773510.tif 000019
【図１９】
0004773510.tif 000020
【図２０】
0004773510.tif 000021
【図２１】
0004773510.tif 000022
【図２２】
0004773510.tif 000023
【図２３】
0004773510.tif 000024
【図２４】
0004773510.tif 000025
【図２５】
0004773510.tif 000026
【図２６】
0004773510.tif 000027
【図２７】
0004773510.tif 000028
【図２８】
0004773510.tif 000029
【図２９】
0004773510.tif 000030
【図３０】
0004773510.tif 000031
【図３１】
0004773510.tif 000032
【図３２】
0004773510.tif 000033
【図３３】
0004773510.tif 000034
【図３４】
0004773510.tif 000035
【図３５】
0004773510.tif 000036