(57)【特許請求の範囲】
【請求項１】
ネットワークを介して複数のセンサノードと接続されるゲートウェイと、
ネットワークを介して前記ゲートウェイと接続されたサーバとを備えたセンサネットシステムにおいて、
前記センサノードは、センサが検出した測定値とセンサノードの識別子とをセンシングデータとして送信する通信部を有し、
前記ゲートウェイは、
前記センサノードからセンシングデータを受信する第１通信制御部と、
前記受信したセンシングデータを前記サーバに送信する第２通信制御部と、
変換定義情報を受け付けて保持して管理する変換定義情報管理部と、
前記変換定義情報管理部が保持する変換定義情報から前記センシングデータに含まれる識別子に対応する変換定義情報を選択する変換定義情報選択部と、
前記センシングデータに対して前記選択した変換定義情報に設定されたフォーマット変換処理を行う変換処理部と、
を有し、
前記サーバは、
前記ネットワークから受信したセンシングデータを格納するセンシングデータデータベースと、
前記複数のゲートウェイによって管理されている複数の変換定義情報を管理する変換定義情報データベースと、
ユーザ端末あるいは他の通信装置から変換定義情報の参照、更新または追加の要求を受け付ける変換定義情報入出力部と、
前記更新または追加の要求があった場合に、前記複数のゲートウェイにおける前記変換定義情報管理部に前記変換定義情報の更新または追加を要求する変換定義情報配布部と、を有し、
前記センシングデータベースは前記変換されたセンシングデータを格納することを特徴とするセンサネットシステム。
【請求項２】
前記センシングデータはバイナリ形式であって、前記変換定義情報は該センシングデータのバイナリ形式のフォーマットを異なるフォーマットのセンシングデータに変換する第１の変換定義情報を含み、
前記変換処理部は、
前記第１の変換定義情報が選択された場合に、前記バイナリ形式のセンシングデータを前記選択した第１の変換定義情報に基づいて異なるフォーマット形式のセンシングデータに変換し、
前記センシングデータデータベースは前記変換されたセンシングデータを格納することを特徴とする請求項１に記載のセンサネットシステム。
【請求項３】
前記変換定義情報は、
前記受信したセンシングデータに単位を付加して変換する第２の変換定義情報を含み、
前記変換定義情報管理部は、
前記サーバまたはユーザ端末あるいは他の通信装置から入力された第２の変換定義情報を受け付けて格納して管理し、
前記変換定義情報選択部は、
前記変換定義情報管理部が保持する複数の第２の変換定義情報から前記センシングデータに含まれる識別子に対応する第２の変換定義情報を選択し、
前記変換処理部は、
前記センシングデータを前記選択した第２の変換定義情報に基づいて単位を付加して変換し、
前記センシングデータデータベースは前記変換されたセンシングデータを格納することを特徴とする請求項１に記載のセンサネットシステム。
【請求項４】
前記変換定義情報選択部は、
前記センシングデータに含まれる識別子と、前記変換定義情報を選択する選択情報とを関連づける変換定義情報関連付けテーブルと、
前記センシングデータに含まれる識別子に対応する選択情報に基づいて、前記変換定義情報を選択することを特徴とする請求項１に記載のセンサネットシステム。
【請求項５】
前記選択情報が、センシングデータに含まれる識別子に対応した変換定義情報を予め設定してあることを指し示す場合には、
前記変換定義情報選択部は、前記識別子に対応した変換定義情報を選択することを特徴とする請求項４に記載のセンサネットシステム。
【請求項６】
前記選択情報が、センシングデータに含まれるデータで変換定義情報を指し示す場合には、
前記変換定義情報選択部は、前記センシングデータの所定の位置のデータが指し示す変換定義情報を選択することを特徴とする請求項４に記載のセンサネットシステム。
【請求項７】
前記センサノードは、
所定の周期でスリープ状態から起動してセンサの測定値を取得する実測部と、
前記センサの測定値を取得した時点のセンサの予測値を演算する予測値演算部と、
前記測定値と予測値の差が予め設定された許容範囲内であるか否かを判定する判定部と、
前記測定値と予測値の差が前記許容範囲内のときには、みなし通信回数を加算するみなし通信カウンタと、
前記測定値と予測値の差が前記許容範囲を超えたときには、前記測定値と前記みなし通信回数をセンシングデータとして送信する送信部と、を備え、
前記変換定義情報選択部は、
前記センサノードからセンシングデータを受信したときには、前記みなし通信回数に応じた予測値を生成する指令を含む前記第１の変換定義情報を選択し、
前記サーバは、
前記受信したセンシングデータに単位を付加して変換する第２の変換処理部を有し、
前記第２の変換処理部は、
前記受信したセンシングデータに前記みなし通信回数に応じた予測値を生成する指令を含むときには、前回のセンシングデータの受信時刻から前記みなし通信回数に対応する時刻を演算し、前記演算した時刻のセンサの予測値を演算し、前記演算した時刻毎の予測値をセンシングデータとして、予め設定した第２の変換定義情報に基づいて前記センシングデータに単位を付加して変換することを特徴とする請求項３に記載のセンサネットシステム。
【請求項８】
前記センサノードは、
所定の周期でスリープ状態から起動してセンサの測定値を取得する実測部と、
前記測定値をゲートウェイに送信し、ゲートウェイとの通信状態の良否を判定する通信状態判定部と、
前記ゲートウェイと通信が行えないときには、前記測定値を蓄積するデータ蓄積部と、
前記ゲートウェイと通信が行えるときには、前記実測部が測定した最新の測定値に加えて前記データ蓄積部に蓄積された過去の測定値を一括して送信する一括送信部と、を備え、
前記変換定義情報選択部は、
前記センサノードからセンシングデータを受信したときには、前記最新の測定値と過去の測定値を処理する前記第１の変換定義情報を選択し、
前記サーバは、
前記受信したセンシングデータに単位を付加して変換する第２の変換処理部を有し、
前記第２の変換処理部は、
前記受信したセンシングデータが前記複数の測定値を含むときには、予め設定した第２の変換定義情報に基づいて前記センシングデータに含まれる測定値毎に単位を付加して変換することを特徴とする請求項２に記載のセンサネットシステム。
【請求項９】
前記変換処理部は、
前記変換定義情報に基づいて前記バイナリ形式のセンシングデータに含まれる測定値の意味情報をテキスト形式のセンシングデータに付加することを特徴とする請求項１に記載のセンサネットシステム。
【請求項１０】
前記第１の変換定義情報は、
前記センサノードが備える前記センサの種別またはセンサの機能あるいはセンサの測定値に対する処理を含むことを特徴とする請求項２に記載のセンサネットシステム。
【請求項１１】
前記センサノードは半導体ひずみセンサを有し、
該半導体ひずみセンサの前記通信部は、該半導体ひずみセンサの測定値を上記センシングデータとして送信することを特徴とする請求項３に記載のセンサネットシステム。
【請求項１２】
前記センサノードは温度センサを有し、
前記変換処理部は、前記温度センサからのセンシングデータを用いて、前記半導体ひずみからのセンシングデータを補正することを特徴とする請求項１１に記載のセンサネットシステム。
【請求項１３】
前記センサノードが温度センサ、湿度センサ、振動センサ、加速度センサのうちの少なくとも１つを備え、
前記変換処理部は、前記半導体ひずみセンサからのセンシングデータと、前記湿度センサ、振動センサ、加速度センサのうちの少なくとも１つからのセンシングデータとを用いて、前記半導体ひずみセンサの測定対象耐久性を評価することを特徴とする請求項１１に記載のセンサネットシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続した多数のセンサからの情報を利用する技術に関する。
【背景技術】
【０００２】
近年、センサに無線通信機能を有する小型の電子回路を付加して、現実世界の様々な情報をリアルタイムに情報処理装置に取り込むネットワークシステム（以下、センサネットシステムという）が検討されている。センサネットシステムには幅広い応用が考えられており、例えば、無線回路、プロセッサ、センサ、電池を集積した小型電子回路により、脈拍等の生体情報や位置情報等を常時モニタし、モニタ結果は無線通信によりサーバ等に送信され、モニタ結果に基づいて健康状態の判定を行う技術が提案されている。
【０００３】
センサネットシステムを広く実用化するためには、無線通信機能、センサ、および、電池等の電源を搭載する電子回路（以下、センサノードという）を、長時間に渡ってメンテナンスフリー、かつセンシングデータを送信し続けられるものが求められる。
【０００４】
現在のインターネット上のサービスは仮想空間上のサービスに閉じているが、センサネットシステムが現在のインターネットと本質的に違う点は、実空間と融合している点である。実空間との融合を図ることができれば、時間、位置など状況依存型のさまざまなサービスが実現できる。実空間に存在する多様なオブジェクトがネットワーク接続されることでトレーサビリティが実現でき、広義の意味での「安全」を求める社会ニーズや、在庫管理やオフィスワークの「効率化」のニーズに対処することが可能となる（例えば、特許文献１）。
【特許文献１】特開２００３−１２２７９８号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来のセンサネットシステムでは、センサノードが出力した未加工データを、データの種別や単位など意味のあるデータに変換するゲートウェイやサーバなどの処理装置は、予め設定されたデータフォーマットについてのみ処理可能である。
【０００６】
今後、センサノードの種類は増大し、センサネットシステムに参加するセンサノードの種類も増加することが予想される。また、センサノードとセンサネットシステムのゲートウェイ間の通信規格などについても新規な規格を採用していく必要が生じる。
【０００７】
しかしながら、従来のセンサネットシステムではセンサノードの出力の取り扱い（特にフォーマット定義）ついて、各センサネットシステム毎に独自の定義を用いている。このため、新たな種類のセンサノードを加入させたり、新たな通信規格をゲートウェイに取り入れる場合には、各センサネットシステムのアプリケーションソフトウェア毎に、センサノードの出力に関する定義やゲートウェイの通信規格に関する定義を変更する必要がある。
【０００８】
しかし、新種のセンサノードや異種のセンサノードを既存のセンサネットシステムへ加入させるには、全てのアプリケーションソフトウェアでセンサノードの出力に関する定義を変更する必要が生じて、膨大な労力が必要となる。さらに、新たなセンサノードが加わるたびに出力に関する定義を変更する必要があり、アプリケーションソフトウェアの開発やメンテンスに要する労力が膨大になる、という問題がある。
【０００９】
特に、複数のゲートウェイを備え、各ゲートウェイの配下に多数のセンサノードを有する大規模なセンサノードでは、新たな種類のセンサノードや通信規格を加える度にソフトウェア開発やメンテナンスのコストが増大してしまう。
【００１０】
そこで本発明は、上記問題点に鑑みてなされたもので、センサノードの送受するデータ形式を上位のサーバでの処理前により扱いやすいフォーマットに変換することを前提とし、かつ、既存のセンサネットシステムで新たな種類のセンサノードの加入や新たな通信規格の採用を容易に行うことを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、ネットワークを介して複数のセンサノードと接続されるゲートウェイと、ネットワークを介して前記ゲートウェイと接続されたサーバとを備えたセンサネットシステムにおいて、前記センサノードは、センサが検出した測定値とセンサノードの識別子とをセンシングデータとして送信する通信部を有し、前記ゲートウェイは、前記センサノードからセンシングデータを受信する第１通信制御部と、前記受信したセンシングデータを前記サーバに送信する第２通信制御部と、変換定義情報を受け付けて保持して管理する変換定義情報管理部と、前記変換定義情報管理部が保持する変換定義情報から前記センシングデータに含まれる識別子に対応する変換定義情報を選択する変換定義情報選択部と、前記センシングデータに対して前記選択した変換定義情報に設定されたフォーマット変換処理を行う変換処理部と、を有し、前記サーバは、前記ネットワークから受信したセンシングデータを格納するセンシングデータデータベースと、前記複数のゲートウェイによって管理されている複数の変換定義情報を管理する変換定義情報データベースと、ユーザ端末あるいは他の通信装置から変換定義情報の参照、更新または追加の要求を受け付ける変換定義情報入出力部と、前記更新または追加の要求があった場合に、前記複数のゲートウェイにおける前記変換定義情報管理部に前記変換定義情報の更新または追加を要求する変換定義情報配布部と、を有し、前記センシングデータベースは前記変換されたセンシングデータを格納する。
【００１２】
また、前記変換定義情報は、前記センシングデータをテキスト形式のセンシングデータに変換する第１の変換定義情報を含み、前記変換定義情報管理部は、前記サーバまたはユーザ端末あるいは他の通信装置から入力された第１の変換定義情報を受け付けて格納して管理し、前記変換定義情報選択部は、前記変換定義情報管理部が保持する複数の第１の変換定義情報から前記センシングデータに含まれる識別子に対応する第１の変換定義情報を選択し、前記変換処理部は、前記センシングデータを前記選択した第１の変換定義情報に基づいてのセンシングデータに変換し、前記センシングデータデータベースは前記変換されたセンシングデータを格納する。
【発明の効果】
【００１３】
したがって、本発明は、基地局が受信したネットワークからのセンシングデータのフォーマット変換のルールを変換設定定義（プロファイルまたはプラグイン）としてセンサノード毎、あるいはセンシングデータ毎に設定することができる。これにより、ゲートウェイやサーバのソフトウェアを更新することなく新たな種類のセンサノードや新たな通信規格を容易に採用することができる。
【００１４】
変換処理部では、変換定義情報によって受信したセンサノードの未加工のセンシングデータをテキスト形式のセンシングデータへ変換する際に、センシングデータの意味情報を付加してからネットワークに送信することで、リソースの制約が多い無線ネットワークの負荷を低減して利用効率を向上させることができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００１６】
図１は、第１の実施形態を示し、本発明を適用するセンサネットワークシステム（以下、センサネットシステム）の一例を示すブロック図である。図１のセンサネットシステムでは、センサノードＳＮ１〜ＳＮｎは、センサＳＳが検出した測定値を所定のバイナリ形式のセンシングデータとして無線通信により基地局ＢＳＴへ送る。基地局ＢＳＴは受信したバイナリ形式のセンシングデータ（センサの生データ）をセンサネットシステムで利用可能な所定のフォーマットのテキスト形式（例えば、ＸＭＬ（eXtended Markup Language）形式など）のセンシングデータに変換する。このフォーマット変換では、センサノードの種別に応じて測定したデータの意味を付加してテキスト形式のセンシングデータを生成する。そして、本実施例において、基地局ＢＳＴは、有線ネットワークＷＤＮを介してセンサネットサーバＳＮＳに送る。
【００１７】
センサネットサーバＳＮＳでは、基地局ＢＳＴから受信したテキスト形式のセンシングデータを、センサの生データから人間が理解可能な値で表記されたセンシングデータに変換し、データベースＤＢに格納する。そして、センサネットサーバＳＮＳはユーザ端末ＵＳＴからの要求、または、ユーザ端末ＵＳＴのアプリケーションや管理ツールからの要求に応じて、データベースＤＢに格納された意味情報を付加したセンシングデータを提供する。
【００１８】
＜センサノード＞
図１において、ＳＮ１〜ＳＮｎは、無線通信によりセンシングデータまたは予め設定されたＩＤ（識別子）を出力するセンサノードである。センサノードＳＮ１〜ＳＮｎは、例えば、ユーザの状態をモニタする目的で、ユーザの所定の部位に装着される。これらセンサノードＳＮ１〜ＳＮｎは、無線ネットワークＷＬＮにより、基地局ＢＳＴと無線通信を行う。各センサノードＳＮ１〜ＳＮｎは、センシングした温度や脈拍等のデータを基地局ＢＳＴに送信する。
【００１９】
センサノードＳＮ１〜ＳＮｎは、それぞれのセンサノードＳＮ１〜ＳＮｎに設けたセンサＳＳの動作を管理する制御部ＣＴＬと、センサノードの動作を制御するプログラムを格納する読み出し専用のメモリＲＯＭと、データなどを格納する読み書き可能なメモリＲＡＭと、無線ネットワークＷＬＮを介して基地局ＢＳＴと通信を行う無線通信制御部ＳＲＦと、所定のスリープ期間をカウントしてスリープ期間が経過する度に制御部ＣＴＬを起動させるタイマＴＭＲを備えて構成される。
【００２０】
センサノードＳＮ１〜ＳＮｎは、電池ＢＡＴにより駆動され、電池ＢＡＴの消耗を抑制するためセンシング動作は間欠的に行われる。つまり、予め設定されたスリープ時間を経過する度に起動して、センサＳＳを駆動して測定を実施する。そして、測定したセンシングデータをバイナリ形式で基地局ＢＳＴに送信した後、スリープ状態に移行し、次回の起動に備える。
【００２１】
なお、センサノードＳＮ１〜ＳＮｎが備えるセンサＳＳとしては、例えば、温度センサ、湿度センサ、脈拍センサであり、この他、個人や個々の物を識別するための識別子を有するものである。
【００２２】
なお、センサノードＳＮ１〜ＳＮｎにアクチュエータを備えてもよく、例えば、エアコンディショナなどがこの種のセンサノードとなる。
【００２３】
上記の様に本実施例においては、センサノードが送受信するデータ形式としてバイナリフォーマットを前提とする。バイナリフォーマットには、可読性が悪く、定義や処理方法が予め固定的に決めておかなければならないという課題がある。その一方で、低レベルプログラミング言語を用いた処理に適している、データサイズが小さくて済むという利点がある。例えば"181"という数値を表現するのに、バイナリフォーマットを用いれば１バイトで済む（0xB5）が、テキストフォーマットであれば３バイト必要となり、可読性をより向上したければデータサイズはさらに増加する。本発明が対象とするセンサネットシステムにおいても、センサノードにおいては、小型・低電力・低リソースであったり、用途に特化した多様なハードコーディング処理が主となるため、通信時のデータ形式としてバイナリフォーマットが好適である。一方、多数のセンサノードからのセンシングデータを集約するサーバ側においては、通信帯域・プロセッサ・メモリ等のリソースが潤沢に利用できる。そのため、高級プログラミング言語を用いて、より人間や多様な応用アプリケーションが利用しやすいデータ形式であるテキストフォーマットを採用することができれば好都合であり、本願構成適応の効果がある。
＜基地局の概要＞
基地局ＢＳＴは、配下の複数のセンサノードＳＮ１〜ＳＮｎとの無線通信を制御する無線通信制御部ＢＲＦと、センサネットサーバＳＮＳとの有線通信を制御する有線通信制御部ＢＮＩＣと、センサネットサーバＳＮＳとセンサノードＳＮ１〜ＳＮｎの間で送受信されるパケットのフォーマットを双方向で変換する変換エンジンＣＶＥＮ（フォーマット変換部）と、変換エンジンＣＶＥＮに与える変換定義情報（以下、プロファイル）ＰＦを制御するパーサＰＳＲと、上位のサーバ（例えば、センサネットサーバＳＮＳ）から受信したプロファイルＰＦ（第１変換定義情報）を格納するプロファイル格納部ＰＳＴを含んで構成される。
【００２４】
変換エンジンＣＶＥＮは、センサノードＳＮ１〜ＳＮｎからセンサネットサーバＳＮＳへ向かう上りのパケットを、パーサＰＳＲが選択したプロファイルＰＦ（変換ルール）に沿って、センシングデータの意味を付加してテキスト形式のセンシングデータに変換（デコード）する。基地局ＢＳＴの変換エンジンＣＶＥＮが付加するデータの意味は、センサノードＳＮ１〜ＳＮｎから受信したセンシングデータの種別（例えば、温度、湿度、脈拍数など）である。つまり、センサノードＳＮ１〜ＳＮｎから上がってくるバイナリ形式のセンシングデータに対して、パケットまたはセンサノード毎に物理量の種類（温度、電圧など）等を付加する。
【００２５】
また、変換エンジンＣＶＥＮでは、センサネットサーバＳＮＳからセンサノードＳＮ１〜ＳＮｎへ向かう下りパケットを、パーサＰＳＲが選択したプロファイルＰＦ（変換ルール）に沿って、テキスト形式のデータ（コマンド）をバイナリ形式のデータに変換（エンコード）する。なお、パーサＰＳＲは、後述するように、受信したパケットの内容を解析してプロファイル格納部ＰＳＴから最適なプロファイルＰＦを選択し、変換エンジンＣＶＥＮへ付与する。
【００２６】
プロファイル格納部ＰＳＴは、上位のサーバ（例えば、センサネットサーバＳＮＳ）から配布されたプロファイルＰＦを格納する。プロファイルＰＦは、センサネットサーバＳＮＳで予め設定された変換ルールである。
【００２７】
また、変換エンジンＣＶＥＮは、センサノードＳＮ１〜ＳＮｎからセンサネットサーバＳＮＳへ向かう上りのデータが、以前にセンサノードに送信したコマンドに対する応答であるかどうかを判定するために、無線通信制御部ＢＲＦが送信したコマンドを管理している。センサノードＳＮ１〜ＳＮｎへ向かう下りパケット変換部ＤＰＣから配下のセンサノードＳＮ１〜ＳＮｎへコマンドを送信する時に、そのコマンドが登録される。
【００２８】
また、変換エンジンＣＶＥＮは、センサネットサーバＳＮＳから受信したコマンドを、テキスト形式のコマンドから、各センサノードＳＮ１〜ＳＮｎへのバイナリ形式のコマンドに変換する。
【００２９】
本実施例では、センサノードＳＮ１〜ＳＮｎが送受するデータ形式がバイナリフォーマットであって、センサネットサーバＳＮＳが送受するデータ形式がテキストフォーマットであるとしている。本実施例の変形として、センサネットサーバＳＮＳが送受するデータ形式がセンサノードＳＮ１〜ＳＮｎとは異なるバイナリフォーマットであったり、センサノードＳＮ１〜ＳＮｎが送受するデータ形式がセンサネットサーバＳＮＳとは異なるテキストフォーマットであった場合についても同様の構成により対応可能である。また、これらのフォーマットが、バイナリフォーマットを単純な規則によってテキストフォーマットへ符号化したＢＡＳＥ６４フォーマットや、２進数の数値データを１０進数であるかのように符号化したＢＣＤ（Ｂｉｎａｒｙ Ｃｏｄｅｄ Ｄｅｃｉｍａｌ、２進化１０進法）フォーマットのように、バイナリとテキストの中間的な位置付けを有するフォーマットであった場合についても同様の構成により対応可能である。
【００３０】
このように、本実施例の基地局ＢＳＴと同様の構成により、多様なフォーマット変換を行うことのできるゲートウェイ装置が実現可能である。後述するように、本願ではフォーマット変換の設定および選択の手段を提供することによって、必要になった時点で新しいフォーマットへ対応したり、複数の独立したフォーマットへ対応したりといったことが簡単に実現できるようになっており、ここに本願の大きな特徴がある。フォーマット変換は、異なる通信規格を有する装置間の通信を仲介するゲートウェイやプロキシサーバといった装置において広く行われてきた処理であり、それら従来装置に本願構成を適用することによって、用途毎に予め特定規格のフォーマット変換機能を作り込むしかなかった従来技術の問題点を完全に除去する効果が得られる。そしてこの効果は特に、多種多様な規格のセンサやセンサノードを扱う必要があるセンサネットシステムへの適用において、最大限の威力を発揮する。
【００３１】
図２は、基地局ＢＳＴの変換エンジンＣＶＥＮの詳細を示すブロック図である。変換エンジンＣＶＥＮは、無線通信制御部ＢＲＦがパケットを受信したときに、バイナリ形式のセンシングデータ（あるいは接続要求）を含むパケットの内容を解析して適用すべきプロファイルＰＦとの参照関係を解決するバイナリ参照制御部ＢＮＲと、受信したバイナリ形式のセンシングデータと変換エンジンＣＶＥＮの内部フォーマット（パケット構造体ＰＣＳ）との間の相互変換を行うバイナリ変換制御部ＢＮＣＶと、内部フォーマット（パケット構造体ＰＣＳ）と有線ネットワークＷＤＮ側のメッセージ（テキスト形式のセンシングデータ）との間の相互変換を行うテキスト変換制御部ＴＸＣＶと、有線通信制御部ＢＮＩＣがテキスト形式のメッセージを受信したときに、コマンドなどを含むパケットの内容を解析して適用すべきプロファイルＰＦとの参照関係を解決するテキスト参照制御部ＴＸＲと、受信したパケットを一時的に格納するパケットバッファＰＢＦと、センサノードまたはパケットのＩＤと上りパケット変換用のプロファイルＰＦの関連付けを格納したプロファイル関連付けテーブル（変換定義情報関連付けテーブル）ＰＦＴ１と、を備える。
【００３２】
さらに、変換エンジンＣＶＥＮでは、センサノードＳＮ１〜ＳＮｎからのセンシングデータに対して、無線ネットワークＷＬＮ内のローカルＩＤから有線ネットワークＷＤＮで使用するグローバルＩＤへの変換、またはグローバルＩＤからローカルＩＤへの変換を行う。
【００３３】
ローカルＩＤとは、例えば、１つのＰＡＮ（Personal Area Network） 内をスコープとするＩＤである。通常、１つのＰＡＮにローカルＩＤを管理する機能を持った基地局ＢＳＴが１つ存在する。ローカルＩＤはグローバルＩＤよりもビット長が短く、送受信パケットに含む際に無線通信の消費電力を抑える効果が期待できる。
【００３４】
グローバルＩＤとは、少なくともセンサネットシステム上のプリケーションあるいはセンサネットシステムの上位システムがセンサノードを識別可能なＩＤである。１つのセンサネットシステムでは、複数のＰＡＮを含むことが可能であるため、アプリケーションあるいはセンサネットシステムの上位システムではグローバルＩＤを使ってセンサノードを管理する。
【００３５】
このため、グローバルＩＤはローカルＩＤに比べて、ビット数が多い。例えば、ユビキタスＩＤセンタのucodeでは基本は128ビットから成り、EPCグローバルのEPC(Electronic Product Code)は96ビットから成る。これに対して、ローカルＩＤは例えば16ビット程度である。
【００３６】
＜センサネットサーバ＞
センサネットサーバＳＮＳは、有線ネットワークＷＤＮ（例えば、インターネット等）を介して複数の基地局ＢＳＴ〜ＢＳＴｎから収集したテキスト形式のセンシングデータ（センサの生データ）を人間が理解可能な値に変換してデータベースＤＢへ格納する。そして、センサネットサーバＳＮＳは、ユーザ端末（ユーザ計算機）ＵＳＴに意味情報を付加したセンシングデータをデータベースＤＢから提供する。
【００３７】
センサネットサーバＳＮＳは、有線ネットワークＷＤＮを介して基地局ＢＳＴや有線センサ、ＲＦタグリーダ、携帯電話、ユーザ端末ＵＳＴと通信を行う有線通信制御部ＳＮＩＣと、基地局ＢＳＴとの通信を行う基地局用インターフェースＢＩＦと、ユーザ端末ＵＳＴのアプリケーションＡＰＰや管理ツールとの間で通信を行うアプリケーション用インターフェースＡＩＦ及び管理用インターフェースＭＩＦと、管理者などにより予め設定されたプロファイルＰＦを格納し、基地局ＢＳＴへ配布するプロファイル管理部ＰＭＧと、基地局ＢＳＴやセンサノードＳＮ１〜ＳＮｎの構成を管理するセンサネット管理部ＮＭＧと、基地局ＢＳＴからテキスト形式のセンシングデータを受信すると、データの種別に応じてセンシングデータに記載されたセンサＳＳの出力値を有意な測定値に変換するように変換部ＤＣＶへ依頼するイベント発行部ＥＶＰと、イベント発行部ＥＶＰから依頼に応じて適切な変換ルール（測定値変換プラグイン）を選択し、センシングデータに単位などの意味情報を付加して人間が理解可能な値に変換する変換部ＤＣＶと、意味情報を付加したセンシングデータをデータベースＤＢへ格納し、管理するデータベース制御部ＤＢＭＳと、を含んで構成される。
【００３８】
管理用インターフェースＭＩＦは、ユーザ端末ＵＳＴを利用する管理者が、プロファイル管理（作成、変更、配布など）を含む各種のシステム管理を行うための機能を提供する。アプリケーション用インタフェースＡＩＦは、センサネットシステムが提供するセンシングデータ等をユーザ端末ＵＳＴで稼動するアプリケーション向けのサービスとして提供する。基地局用インターフェースＢＩＦは、基地局ＢＳＴからのセンシングデータの受信、センサノードＳＮ１〜ＳＮｎの設定に関するコマンドの送信や、プロファイルＰＦの配信などの機能を提供する。
【００３９】
センサネット管理部ＮＭＧは、各々のセンサノードＳＮ１〜ＳＮｎの動作制御（送信間隔の設定など）、センシングデータの管理等の機能を提供する。プロファイル管理部ＰＭＧは、プロファイルＰＦの登録や基地局ＢＳＴへのプロファイルＰＦの配布管理の機能を提供する。なお、プロファイルＰＦは図３で示すプロファイルレジストリデータベースＰＤＢに格納される。このプロファイルレジストリデータベースＰＤＢには、センサネットシステム全体のプロファイル群が記憶される。また、プロファイル管理部ＰＭＧは、プロファイルＰＦに記述した機能やパラメータをセンサネット管理部ＮＭＧへ配布する。
【００４０】
変換部ＤＣＶは、図３で示すように、センサネットシステムに所属するセンサノードＳＮ１〜ＳＮｎのセンシングデータの種別等に応じた測定値変換プラグイン（測定値変換定義情報：第２変換定義情報）を備える。
【００４１】
基地局ＢＳＴでデータの種別を付加したテキスト形式に変換されたセンシングデータは、センサノードの測定値としてセンサＳＳの出力値がそのまま記載されている。変換部ＤＣＶを構成する測定値変換プラグインは、この出力値を人間が理解可能な値に変換し、さらに、ＳＩ単位などの単位を意味情報として付加して有意なセンシングデータに変換する。
【００４２】
このとき、イベント発行部ＥＶＰは、センシングデータに記載されたセンサノードＳＮ１〜ＳＮｎのＩＤ（ＭＡＣアドレス）からセンサネット管理部ＮＭＧにセンサノードＳＮ１〜ＳＮｎの種別を問い合わせて、使用すべき測定値変換プラグインを選択する。そして、この変換部ＤＣＶに対してセンサＳＳの出力値を有意な測定値に変換して、予め測定値変換プラグインで設定された単位を付加するように指令する。
【００４３】
測定値変換プラグインとしては、例えば、図３で示すように温度値変換用プラグインＰＩ１、湿度値変換用プラグインＰＩ２、加速度値変換用プラグインＰＩ３、ＲＳＳＩ（受信強度：Received Signal Strength Indicator）値変換用プラグインＰＩ４などがある。
【００４４】
例えば、温度値変換用プラグインＰＩ１は、基地局ＢＳＴから受信したセンシングデータの値を「°Ｃ」や「°Ｆ」等の単位に応じた値に変換する。例えば、基地局ＢＳＴから受信したセンシングデータの内容が、
<Temperature>
<Value>14936</Value>
であれば、このセンシングデータの識別子（例えば、センサノードのＩＤ＝ＭＡＣアドレス）から所定の温度値変換用プラグインＰＩ１を呼び出して、センサの生データを人間が理解可能な値への変換と単位の付加を行う。例えば、上記「14936」という温度センサの出力値は、温度値変換用プラグインＰＩ１で変換することで「２０℃」という意味づけがなされた有意な情報に変換される。
【００４５】
ここで、変換部ＤＣＶの温度値変換用プラグインＰＩ１は、センサネットシステムのセンサノードの種別毎に用意されており、センサノードＳＮ１〜ＳＮｎのＩＤに応じたプラグインＰＩ１を利用する。つまりセンサノードＳＮ１〜ＳＮｎの種別ごとにセンサの特性は異なるので、センサネットシステムが利用するセンサノードＳＮ１〜ＳＮｎの種類毎にプラグインＰＩが予め設定される。
【００４６】
そして、変換部ＤＣＶはセンサノードＳＮ１〜ＳＮｎのＩＤを抽出し、予め設定されたセンサノードのＩＤと使用するプラグインを決定し、センシングデータの値の変換を行う。
【００４７】
湿度値変換用プラグインＰＩ２、加速度値変換用プラグインＰＩ３あるいはＲＳＳＩ値変換用プラグインＰＩ４も上記温度値変換用プラグインＰＩ１と同様に、センサノードＳＮ１〜ＳＮｎの種類毎にそれぞれ複数のプラグインが用意される。そして、変換部ＤＣＶは、受信したセンシングデータに記載されたセンサノードのＩＤに応じたプラグインを呼び出してセンシングデータの値を有意な情報に変換する。
【００４８】
そして、変換部ＤＣＶで有意な情報に変換されたセンシングデータは、ＤＢ制御部ＤＢＭＳを介してデータベースＤＢへ格納される。
【００４９】
なお、測定値変換プラグインはセンシングデータの種別毎に随時設定することができ、新たな種別のセンシングデータ（センサノード）を扱う場合には、ユーザ端末ＵＳＴの管理ツールなどから新たな測定値変換プラグインを加えればよい。
【００５０】
本願の構成により、センサネットサーバＳＮＳは、基地局ＢＳＴが予め扱いやすいテキストフォーマットに変換されたセンシングデータに対して、さらにＳＩ単位への変換のように意味レベルでの整形まで施した上でデータベースＤＢへ格納することができる。本願を適用しない場合には、センサノードＳＮ１〜ＳＮｎが送信してくるデータがそのままの形式でデータベースＤＢへ格納されることとなる。このデータはセンサデバイスやマイコン処理、無線通信等の規格によって暗黙的に意味が定められたバイナリフォーマットであって、人間が見ても意味を理解することは非常に困難である。しかも、データベースＤＢに格納した後のデータを様々なアプリケーションに提供する際に、前記のような特定の規格に依存したデータ形式で提供されることとなり、個々のアプリケーションがそのデータを利用するためには前記特定規格の詳細を理解した上で、自身にとって都合の良いデータ形式へと変換し直さなければならない。このようなシステムでは、せっかく有用なセンシングデータを収集したとしても、データの再利用性が悪く、アプリケーションに煩雑なデータ変換処理を押し付けることとなり、使い勝手が大きく損なわれてしまう。本願の適用により、収集したセンシングデータの再利用性を高め、多様なデータ交換を可能とする効果が得られる。
【００５１】
なお、後述するように、データのフォーマット変換を基地局ＢＳＴで、データの意味付けをセンサネットサーバＳＮＳで行うことに拘る必要はない。本願の効果を得るためには、データベースＤＢに格納されるまでのいずれかの箇所においてフォーマット変換および意味付けを施せば十分である。本実施例は、処理負荷の分散や処理レベルに基づく役割分担の観点を加味し、特に最適と思われる実施形態を示したものである。
【００５２】
＜基地局のパケット変換処理＞
＜上りパケット変換処理＞
図２を参照しながら、基地局ＢＳＴで行われるセンシングデータの変換処理について説明する。まず、センサノードＳＮ１〜ＳＮｎから基地局ＢＳＴを介してセンサネットサーバＳＮＳへ向かう上りパケットについて説明する。
【００５３】
バイナリ参照制御部ＢＮＲは、センサノードＳＮ１〜ＳＮｎから受信した上りパケット（センシングデータ）またはセンサノードＳＮ１〜ＳＮｎのＩＤに基づいて、プロファイル関連付けテーブルＰＦＴ１を参照し、適用するプロファイルＰＦを後述するように決定し、パーサＰＳＲに通知する。なお、パケットやセンサノードＳＮのＩＤとしては、例えば、センサノードＳＮのＭＡＣアドレスを用いることができる。あるいは、センサノードＳＮ１〜ＳＮｎが基地局ＢＳＴの配下に加入したとき、基地局ＢＳＴがセンサノードＳＮ１〜ＳＮｎに付与するローカルＩＤ（例えば、ＩＰアドレス）を用いても良い。
【００５４】
パーサＰＳＲは、上記決定したプロファイルＰＦをプロファイル格納部ＰＳＴから読み込んで、プロファイルＰＦに記述されたデコード用のプロファイル記述をテキスト変換制御部ＴＸＣＶに通知する。
【００５５】
バイナリ変換制御部ＢＮＣＶは、受信したバイナリ形式のセンシングデータを変換エンジンＣＶＥＮ内の中間コードであるパケット構造体に変換する。
【００５６】
テキスト変換制御部ＴＸＣＶは、パーサＰＳＲから取得したプロファイル記述に基づいて、パケット構造体の内容を、意味情報を加えたテキスト形式のセンシングデータに変換する。そして、変換エンジンＣＶＥＮは、テキスト形式のセンシングデータを有線通信制御部ＢＮＩＣへ送り、センサネットサーバＳＮＳに送信する。
【００５７】
図４は、上記無線ネットワークＷＬＮ(無線区間)からのセンシングデータをＸＭＬによるテキスト形式のセンシングデータに変換する一例を示す説明図で、センサノードが温度センサを備えた場合である。
【００５８】
図４において、無線区間のセンシングデータは、パケットＰＷＬとしてセンサノードＳＮ１〜ＳＮｎから送信され、基地局ＢＳＴが受信する。パケットＰＷＬは、先頭（図中ＭＳＢ）から物理（ＰＨＹ）ヘッダ、ＭＡＣヘッダが続き、ＭＡＣヘッダ以降にデータを格納するためのペイロードＰＬＤが設定される。ＭＡＣヘッダには、送り元となるセンサノードＳＮ１〜ＳＮｎの識別子であるＭＡＣアドレスが格納される。ＭＡＣヘッダの後ろには、データを格納するためのペイロードＰＬＤが可変長で設定される。
【００５９】
基地局ＢＳＴのバイナリ参照制御部ＢＮＲは、センサノードＳＮ１〜ＳＮｎからセンシングデータを受信すると、パケットＰＷＬのＭＡＣヘッダからＭＡＣアドレスを抽出する。次に、バイナリ参照制御部ＢＮＲは、図５に示すプロファイル関連付けテーブルＰＦＴ１を参照して受信したパケットＰＷＬのプロファイルの選択区分を決定する。プロファイル関連付けテーブルＰＦＴ１は、センサノードＳＮ１〜ＳＮｎの初期接続時に各センサノードＳＮ１〜ＳＮｎ毎にエントリが生成され、後述するように選択区分が決定される。
【００６０】
図５のプロファイル関連付けテーブルＰＦＴ１は、ひとつのエントリがＭＡＣアドレスに対応するプロファイルの選択区分と、選択すべきプロファイルのＩＤ及びプロファイルＩＤを短縮するＳｈｏｒｔＩＤと、から構成される。
【００６１】
そして、バイナリ参照制御部ＢＮＲは、プロファイル関連付けテーブルＰＦＴで該当するＭＡＣアドレスの選択区分に応じてプロファイルＰＦを指定し、パーサＰＳＲに通知する。
【００６２】
例えば、図４に示すように、ＭＡＣアドレス＝3F71000A0314のセンシングデータの場合、図５のプロファイル関連付けテーブルＰＦＴ１から選択区分が0x02を得る。この選択区分ではプロファイル関連付けテーブルＰＦＴ１に記載されたプロファイルＩＤ＝０ｘ０４１を選択する。
【００６３】
パーサＰＳＲは、プロファイル格納部ＰＳＴからＩＤ＝０ｘ０４１のプロファイルＰＦを読み出して、プロファイル記述をテキスト変換制御部ＴＸＣＶへ渡す。テキスト変換制御部ＴＸＣＶは、バイナリ変換制御部ＢＮＣＶが変換したパケット構造体に対して、プロファイル記述を適用してテキスト形式のセンシングデータ変換する。
【００６４】
例えば、図４のように、読み出したプロファイルＩＤ＝０ｘ０４１のプロファイルＰＦの記述が、
<sequence type="upPacket" name="observed">
<element name="Temperature" dataType="int16u"/>
</sequence>
とする。このプロファイル記述は、upPacket＝上りパケットに対してセンシングデータの名称を「observed」（観測値）に設定し、意味情報が温度であり、データタイプが「int16u」＝２ｂｙｔｅ値を符号なし１０進整数として扱うことを意味している。
【００６５】
テキスト変換制御部ＴＸＣＶは、このプロファイル記述に基づいて、ペイロードＰＬＤの１、２バイト目のデータ＝「０ｘ３Ａ５８」をデータとして取得する。そして、符号無しの１０進数＝１４９３６に変換する。
【００６６】
テキスト変換制御部ＴＸＣＶは、図４の（１’）で示すように、有線ネットワークＷＤＮの温度観測イベントとして、センシングデータの識別子にセンサノードのＭＡＣアドレスを設定し、意味情報としてプロファイル記述で指定された「温度」を設定し、測定値として上記変換した１０進数＝「０ｘ３Ａ５８」を設定したテキスト形式のセンシングデータを生成する。そして、有線通信制御部ＢＮＩＣがテキスト形式のセンシングデータをセンサネットサーバＳＮＳへ送信する。
【００６７】
本願の構成により、センサノードの送信するセンシングデータの形式としては従来通りのバイナリフォーマットであることを前提としつつも、サーバのデータベースに格納するまでの間にフォーマット変換を施すことによって、人間や多様な応用アプリケーションに対しては、可読性が高く柔軟な処理を行いやすいデータ形式であるテキストフォーマットでデータを提供することができるという効果が得られる。そして、プロファイル格納部ＰＳＴやプロファイル関連付けテーブルＰＦＴ、バイナリ変換制御部ＢＮＣＶ等の働きによって、複数のバイナリフォーマットへの対応が可能であることから、多種多様なノードに随時対応することができる。又、特に無線通信を利用するセンサノードでは、電池の消費電力を抑制して長期間の利用を実現するため、通信時間を極めて短時間に抑制したい。しかしながら、センサノード側の処理を増加させたり、既存のセンサネットシステムのために余分な情報を付加した場合には、演算処理や通信するデータ量が増えた分だけ消費電力が増大して電池の寿命が短くなるのに加え、多数のセンサノードを利用する際には一つのセンサノードが冗長な通信を行うことで、有限の無線通信帯域の利用効率が低下してしまうという課題がある。本願は、これらの問題点を解決する上でも特に効果がある。
【００６８】
＜下りパケット変換処理＞
次に、センサネットサーバＳＮＳからセンサノードＳＮ１〜ＳＮｎに対する指令は、テキスト形式のコマンドが基地局ＢＳＴへ送信され、基地局ＢＳＴでバイナリ形式のコマンドに変換（エンコード）してからセンサノードＳＮ１〜ＳＮｎへ送信される。基地局ＢＳＴは、センサノードＳＮ１〜ＳＮｎへ向かう下りパケットに対して以下のような変換処理を実行する。
【００６９】
テキスト参照制御部ＴＸＲは、有線ネットワークＷＤＮを介してセンサネットサーバＳＮＳから受信した下りパケット（コマンド）の内容に基づいて、予め設定したプロファイルＰＦからパーサＰＳＲを介して呼び出す。
【００７０】
パーサＰＳＲは、上記決定したプロファイルＰＦをプロファイル格納部ＰＳＴから読み込んで、プロファイルＰＦに記述されたエンコード用のプロファイル記述をバイナリ変換制御部ＢＮＣＶに通知する。
【００７１】
テキスト変換制御部ＴＸＣＶは、受信したテキスト形式のコマンドを変換エンジンＣＶＥＮ内の中間コードであるパケット構造体に変換する。
【００７２】
バイナリ変換制御部ＢＮＣＶは、パーサＰＳＲから取得したプロファイル記述に基づいて、パケット構造体の内容を、所定のフォーマットのバイナリ形式のコマンドデータに変換する。そして、変換エンジンＣＶＥＮは、バイナリ形式のコマンドを無線通信制御部ＢＲＦへ送り、センサノードＳＮ１〜ＳＮｎに送信する。
【００７３】
図６は、センサネットサーバＳＮＳ(有線区間)からのＸＭＬによるテキスト形式のコマンドを、バイナリ形式のコマンドに変換する一例を示す説明図で、センサノードに対してスリープ時間を設定する場合である。
【００７４】
図６において、基地局ＢＳＴがセンサネットサーバＳＮＳから受信した有線ネットワークＷＤＮ（有線区間）のコマンドは、テキスト参照制御部ＴＸＲで内容を解析する。図示の例では、コマンドの意味が書き込み「write」で、あて先のセンサノードのＩＤ（ＭＡＣアドレス）＝「3F71000A0314」で、書き込む内容がスリープ時間を「３００」に設定するものである。
【００７５】
テキスト参照制御部ＴＸＲは、コマンドの意味が書き込みで、スリープ時間の設定であることをパーサＰＳＲに通知する。
【００７６】
パーサＰＳＲは、プロファイル格納部ＰＳＴから書き込みコマンドに対応するプロファイルＰＦを取得する。このプロファイルＰＦの一例としては、図７に示すものがある。パーサＰＳＲは、図７において、上記書き込みコマンドに対応するプロファイル記述（図中ＰＦＤ）を取得してバイナリ変換制御部ＢＮＣＶに通知する。各コマンドと内容に応じたプロファイル記述は図８のようになる。図６に示したスリープ時間の設定は、図８の下りパケットプロファイル記述のサンプルＮＯ＝３に相当し、エンコードの詳細が記述される。
【００７７】
バイナリ変換制御部ＢＮＣＶでは、このプロファイル記述（サンプルＮＯ＝３）に基づいて、コマンド＝writeに対応する１６進数「０２」と、スリープ時間に対応する１６進数「０５０３」と、設定値＝「３００」に対応する１６進数を、無線ネットワークＷＬＮ（無線区間）のパケットＰＷＬを生成し、図６のようにペイロードＰＬＤに上記１６進数を順次設定してバイナリ形式のコマンドを設定する。なお、あて先は、図６のＭＡＣアドレスを図４に示したＭＡＣヘッダに設定する。そして、無線通信制御部ＢＲＦがテキスト形式のコマンドをセンサノードに送信する。
【００７８】
＜プロファイル記述＞
次に、パーサＰＳＲによってプロファイル格納部ＰＳＴから取得されるプロファイルＰＦについて以下に説明する。
【００７９】
プロファイルＰＦは、例えば、ＸＭＬ形式で定義され、センサノードＳＮ１〜ＳＮｎからセンサネットサーバＳＮＳへ向かうセンシングデータをバイナリ形式からテキスト形式に変換するデコードルールと、センサネットサーバＳＮＳからセンサノードＳＮ１〜ＳＮｎへ向かうテキストコマンドを形式からバイナリ形式に変換するエンコードルールがある。デコードルールの番号と内容とエンコードルールの番号と内容を以下に示す。
【００８０】
（１） デコードルール：コマンド応答、イベント
［Rule  ０］  ＜Profile＞または＜sequence＞の属性＜type＞が”upPacket”の場合にデコードルールを適用する。
［Rule  １］  ＜element＞出現時、＜name＞で指定した名称のタグを作成し、ペイロー          ドＰＬＤから＜dataType＞で指定されたデータを取得し、テキスト要素に格納          する。
［Rule  ２］  ＜sequence＞出現時、子要素で指定された規則を順番に適用する。
［Rule  ３］  ＜sequence＞の属性に＜name＞が存在する場合、全ての子要素を囲む、指定した名称のタグを作成する。
［Rule  ４］  ＜sequence＞の属性に＜maxOccurs＞が存在する場合、（ａ）ペイロード          から繰返し数Ｎを取得し、（ｂ）取得した繰返し数Ｎ回分、子要素で指定され          た規則を順番に適用することを繰り返す。
［Rule  ５］  ＜choice＞出現時、（ａ）ペイロードから選択タイプの通し番号Ｔ（０か          ら開始）を取得し、（ｂ）子要素で指定された規則のうちＴ番目（０から開始          ）の規則を適用する。
［Rule  ６］  ＜choice＞の子要素の属性に＜id＞が存在する場合、ペイロード中の選択番号Ｔとの明示的な対応関係（１６進値）を示す。
［Rule  ７］  ＜dummy＞の出現時は、属性＜dataType＞で指定したサイズ分、無線ペイロードをスキップする。
［Rule  ８］  ＜Message＞の属性に＜id＞が存在する場合、＜choice＞と同様の処理に          より、ペイロード先頭のメッセージ識別番号（１６進値）に対応するメッセー          ジフォーマットを識別する。
［Rule  ９］  ＜putParam＞出現時、無線ペイロードからデータを読み込まず、＜type＞          が示す外部パラメータを＜format＞が指定する形式で挿入する。
［Rule  １０］  その他、特定の無線通信プロトコルに特化した暗黙のデコードルールを含んでも良い。
【００８１】
（２）  エンコードルール：コマンド
［Rule  ０］  ＜Profile＞または＜sequence＞の属性＜type＞が”downPacket”の場合にエンコードルールを適用する。
［Rule  １］  ＜element＞または＜sequence＞の出現時、有線区間パケット（テキスト）から＜name＞で指定した名称のタグを取得し、  ＜dataValue＞の値を＜dataType＞で指定されたフォーマットに変換し、無線パケットのペイロードに格納する。
［Rule  ２］  ＜sequence＞出現時、子要素で指定された規則を順番に適用する。
［Rule  ３］  ＜element＞または＜sequence＞の＜dataType＞がｎｕｌｌの場合、無線パケットのペイロードには何も格納しない。
［Rule  ４］  ＜element＞または＜sequence＞において＜dataType＞がｎｕｌｌ以外で          かつ＜dataValue＞が存在しない場合、有線区間パケットから＜dataType＞で          指定されたフォーマットで値を取得し、無線パケットのペイロードに格納する          。
［Rule  ５］  ＜choice＞出現時、有線区間パケットの構造にマッチするいずれかの子要素を選択して適用する。
［Rule  ６］  ＜getParam＞出現時、有線区間パケットから取得したテキスト要素を、＜          type＞が示す外部パラメータとして、＜format＞が指定する形式で取得する。      
【００８２】
［Rule  ７］  その他、特定の無線通信プロトコルに特化した暗黙のエンコードルールを含んでも良い。
【００８３】
以上のように、上りパケットに対するデコードルールと下りパケットに対するエンコードルールがＸＭＬ等で記述される。
【００８４】
エンコードのプロファイルＰＦの一例としては、上記図７、図８があり、デコードのプロファイルＰＦとしては、図９〜図１１に示すものがある。図９〜図１１では、サンプルＮＯ＝１〜９に対応して、無線区間のペイロードの内容（意味情報）とプロファイル記述と、上記デコードルール番号と、テキスト形式のフォーマットが設定されている。なお、これらのプロファイルＰＦがプロファイル格納部ＰＳＴに設定されている。また、図９〜図１１のプロファイルＰＦで使用されるＤＡＴＡＴＹＰＥは、図１２で示すように、予め設定されたものである。
【００８５】
上記デコードのプロファイルＰＦでは、サンプルＮＯ＝１のように、ペイロードＰＬＤに含まれるひとつのセンシングデータをテキスト形式に変換するプロファイルと、サンプルＮＯ＝２〜９のように、ペイロードＰＬＤに含まれる複数のセンシングデータをテキスト形式に変換するプロファイルＰＦが定義されている。
【００８６】
変換エンジンＣＶＥＮは、センサノードＳＮ１〜ＳＮｎまたはパケットＰＷＬに応じたプロファイルＰＦを選択することで、多種多様なセンサノードＳＮ１〜ＳＮｎを利用することができるのである。そして、新たな種類のセンサノードを基地局ＢＳＴへ参加させるには、後述するように生成したプロファイルＰＦを基地局ＢＳＴへ配布する。そして、上記図５で示したプロファイル関連付けテーブルＰＦＴに新たなセンサノードのＩＤと、新たなプロファイルＰＦを対応付けることで、センサネットシステムで任意のセンサノードＳＮ１〜ＳＮｎを利用することができる。
【００８７】
なお、図９においてサンプルＮＯ＝４及び５では、センサノードがセンサＳＳのセンシングデータをメモリＲＡＭへ蓄積しておき、基地局ＢＳＴへの送信時に蓄積しておいたセンシングデータを一括して送信する場合（ため込み通信）を示している。
【００８８】
これは、センサノードＳＮ１〜ＳＮｎが基地局ＢＳＴと通信できない場合や無線通信状態が不安定な場合、所定のスリープ期間毎にセンサノードＳＮ１〜ＳＮｎは基地局ＢＳＴへセンシングデータを送信しようとするが、基地局ＢＳＴと接続できずに送信のリトライを繰り返すと電池ＢＡＴを消耗するだけとなる。つまり、センサノードＳＮ１〜ＳＮｎがセンシングデータの送信後、基地局ＢＳＴからの応答（ＡＣＫ信号）を待つが、所定時間経過しても応答が無いときにはセンサノードＳＮ１〜ＳＮｎは再度センシングデータの送信を行って応答を待つ動作（リトライ）を繰り返す。
【００８９】
そこで、センサノードＳＮ１〜ＳＮｎは、電池ＢＡＴの無駄な消耗を防ぐため、所定回数（２〜３回）のリトライで基地局ＢＳＴと通信できない場合には、センサノードＳＮ１〜ＳＮｎは基地局ＢＳＴへの送信を停止し、メモリＲＡＭへセンシングデータを蓄積する。
【００９０】
そして、センサノードＳＮ１〜ＳＮｎは、次回の起動時以降に基地局ＢＳＴと通信できたときに、現在の測定値（最新の測定値）に加えて蓄積しておいた過去の測定値をまとめて送信するようにしたものである。
【００９１】
ここで、基地局ＢＳＴで選択するプロファイルＰＦには、センサノードＳＮ１〜ＳＮｎから受信したセンシングデータから、複数の測定値を抽出して所定の順序（例えば、タイムスタンプ順）でテキスト形式のセンシングデータへ変換する。
【００９２】
センサネットサーバＳＮＳは、複数の測定値を含むセンシングデータを受信すると、複数の測定値を抽出して、それぞれ単位を付加する変換を行ってから所定の順序でデータベースＤＢへ格納する。
【００９３】
＜センサネットシステムの動作＞
次に、センサネットシステム全体での処理について、図１３を参照しながら以下に説明する。
【００９４】
図１３は、センサノードＳＮ１と、基地局ＢＳＴ及びセンサネットサーバＳＮＳの間で行われる処理の流れを示すタイミングチャートである。
【００９５】
＜センサノードの接続開始時＞
センサノードＳＮ１は、基地局ＢＳＴの配下に加入するため接続通知パケットを送信する（Ｔ１）。基地局ＢＳＴでは、センサノードＳＮ１のＩＤ（例えば、ＭＡＣアドレス）に対して適用するプロファイルＰＦを決定する必要がある。センサノードＳＮ１からの接続通知パケットを受信した基地局ＢＳＴは、接続通知パケットの内容を解析し、図５に示したプロファイル関連付けテーブルＰＦＴに新たなエントリを生成して、センサノードＳＮ１と選択するプロファイルＰＦの関係を設定する。
【００９６】
センサノードＳＮ１が送信する接続通知パケットのペイロードＰＬＤは、図１４で示すように、０バイト目がプロファイルＩＤを参照する選択区分を示すＴＹＰＥフィールドとなっており、図５に示したプロファイル関連付けテーブルＰＦＴの選択区分の値（選択情報）となる。そして、ペイロードＰＬＤの２バイト目以降は、このセンサノードＳＮ１またはパケットに割り当てるべきプロファイルＩＤを示すＩＤフィールドとなっており、第１バイト目はＩＤフィールドのサイズを示す。
【００９７】
基地局ＢＳＴは、接続通知パケットを受信すると、図５のプロファイル関連付けテーブルＰＦＴに新たなエントリを追加して、センサノードＳＮ１のＩＤとしてパケットＰＷＬのＭＡＣヘッダから取得したＭＡＣアドレスを図５のプロファイル関連付けテーブルＰＦＴのＭＡＣ欄に追加する。そして、基地局ＢＳＴは受信したペイロードＰＬＤのＴＹＰＥを選択区分に設定する。また、選択区分＝０ｘ０２の場合は、センサノードＳＮ１のＩＤにプロファイルＩＤを割り当てるので、プロファイル関連付けテーブルＰＦＴのプロファイルＩＤ欄にはペイロードＰＬＤのＩＤフィールドから取得した値を設定する。
【００９８】
プロファイルＩＤの選択区分を示すＴＹＰＥの値は、図１５で示すとおりである。接続通知パケットのＴＹＰＥ＝０ｘ０１の場合、センシングデータ毎にペイロードＰＬＤの先頭にプロファイルＩＤを指定する。図１６のＴＹＰＥ＝０ｘ０１のように、センサノードＳＮ１は、センシングデータの送信時に、個々のデータパケットのペイロードＰＬＤの先頭に必ずプロファイルＩＤをセンサノードＳＮ１が付与する。この場合は、センシングデータのパケットＰＷＬに対してプロファイルＩＤを割り当てるものである。そして、この場合のプロファイル関連付けテーブルＰＦＴには選択区分に０ｘ０１が設定され、接続通知パケットのＩＤフィールドの値がプロファイルＩＤに設定される。
【００９９】
この選択区分＝０ｘ０１のセンサノードＳＮ１では、接続通知時に、センサノードＳＮ１側からＩＤフィールドに設定するプロファイルＩＤを変更することで、所望のプロファイルＰＦを呼び出すことができる。
【０１００】
接続通知パケットのＴＹＰＥ＝０ｘ０２の場合、接続通知パケットのＩＤフィールドに記載されたプロファイルＩＤをセンサノードＳＮ１のＭＡＣアドレスに対して割り当てる。
【０１０１】
センサノードＳＮ１は、接続通知パケットで使用するプロファイルＩＤを基地局ＢＳＴへ通知し、センシングデータの送信時には、図１６のＴＹＰＥ＝０ｘ０２のように個々のデータパケットではプロファイルＩＤを指定せず、基地局ＢＳＴがＭＡＣアドレスに対応するプロファイルＩＤを決定する。そして、この場合のプロファイル関連付けテーブルＰＦＴには選択区分に０ｘ０２が設定され、プロファイルＩＤ欄には接続通知パケットのＩＤフィールドに格納された値が設定される。例えば、図１４のＴＹＰＥ＝０ｘ０２のペイロードＰＬＤでは、センサノードＳＮ１のＭＡＣアドレスに対してプロファイルＩＤ＝０ｘ００４１のプロファイルＰＦを割り当てることを示している。
【０１０２】
接続通知パケットのＴＹＰＥ＝０ｘ０３の場合、センシングデータ毎にペイロードＰＬＤの先頭にプロファイルＩＤを指定する点は、ＴＹＰＥ＝０ｘ０１と同様であるが、この場合、無線区間のデータサイズ圧縮のために、センシングデータ中では、上位システムが管理するプロファイルＩＤ値よりも短い「Ｓｈｏｒｔ  ＩＤ」を使用する。例えば、図１４のＴＹＰＥ＝０ｘ０３の例では、プロファイルＩＤ＝０ｘ０１３８をＳｈｏｒｔ  ＩＤ＝０ｘ５０で指定することを示している。センシングデータの送信時には、図１６のＴＹＰＥ＝０ｘ０３のように、センサノードＳＮ１はペイロードＰＬＤの先頭にＳｈｏｒｔＩＤを付加してプロファイルＩＤを指定する。
【０１０３】
そして、この場合のプロファイル関連付けテーブルＰＦＴには選択区分に０ｘ０３が設定され、ＩＤフィールドの値がプロファイルＩＤに設定され、ＳｈｏｒｔＩＤも設定される。
【０１０４】
この場合も選択区分＝０ｘ０１と同様に、接続通知にセンサノードＳＮ１側からＩＤフィールドに設定するプロファイルＩＤを変更することで、所望のプロファイルＰＦを呼び出すことができる。
【０１０５】
ＴＹＰＥ値は、上記の他に基地局ＢＳＴの種別に応じてプロファイルＩＤを設定する場合（０ｘ１１）や無線通信規格の種別に応じてプロファイルＩＤを設定する場合（０ｘ１２）等がある。
【０１０６】
以上のように、図１３のＴ１では基地局ＢＳＴがセンサノードＳＮ１から受信した接続通知パケットに基づいてプロファイル関連付けテーブルＰＦＴを設定し、以降のセンシングデータに適用するプロファイルＩＤを決定する。
【０１０７】
また、基地局ＢＳＴは、接続通知を要求されたセンサノードＳＮ１のＭＡＣアドレスをセンサネットサーバＳＮＳへ通知する。
【０１０８】
センサネットサーバＳＮＳでは、接続通知のあったセンサノードＳＮ１のＭＡＣアドレスをセンサネット管理部ＮＭＧに記録し、このＭＡＣアドレスのセンサノードＳＮ１が基地局ＢＳＴの配下にいることを管理する。
【０１０９】
以下、図１３の説明では、上記接続通知パケットのＴＹＰＥ＝０ｘ０１の場合について説明する。Ｔ１で接続通知パケットの処理が完了し、ＭＡＣアドレスに対してプロファイルＩＤ＝＃１が割り当てられたものとする。なお、図示のように、プロファイルＩＤ＝＃１のプロファイルＰＦ（ノードプロファイル）は、複数のパケットプロファイル＃Ａ、＃Ｂ、＃Ｃを含んでいる。基地局ＢＳＴはこのセンサノードＳＮ１に対して初期設定の完了を通知し、センシングデータの送信を許可する。このとき、基地局ＢＳＴはこのセンサノードＳＮ１に対して、ローカルＩＤを付与する。
【０１１０】
次に、図１３のＴ２では、所定のスリープ時間が経過した後、センサノードＳＮ１はセンシングデータを基地局ＢＳＴに送信する。
【０１１１】
センサノードＳＮ１からのセンシングデータ受信時、基地局ＢＳＴはペイロードＰＬＤ先頭の識別フィールドの値＊Ａから、対応するパケットプロファイルＩＤが＃Ａであることを識別する。基地局ＢＳＴはＭＡＣアドレスからプロファイル関連付けテーブルＰＦＴを参照し、プロファイルＩＤ＝＃１のプロファイルＰＦのサブセットであるプロファイルＩＤ＝＊Ａを読み込んで、温度測定値と測定時刻のバイナリ形式のセンシングデータをテキスト形式のセンシングデータに変換する。そして、基地局ＢＳＴはテキスト形式のセンシングデータをセンサネットサーバＳＮＳへ送信する。
【０１１２】
センサネットサーバＳＮＳは、基地局ＢＳＴから受信したセンシングデータからＭＡＣアドレスと意味情報を抽出して適用する測定値変換プラグインを選択する。そして、選択した測定値変換プラグインでテキスト形式のセンシングデータに記載されている測定値（センサＳＳの出力値）を単位を付加した有意な情報に変換し、データベースＤＢに格納する。
【０１１３】
なお、＊Ａは、ペイロードＰＬＤが複数あるパケットプロファイルのいずれの定義に対応するのかが分かる識別情報であれば良く、必ずしもパケットプロファイルのＩＤ（＃Ａ）そのものでなくても良い。また、パケットプロファイルが１つであったり、パケットプロファイルを使用せずにノードプロファイル内でパケット定義を記述している場合には、＊Ａに相当する識別情報は、該プロファイル中のパケット定義のうちのどの部分に対応するかが矛盾なく識別可能な情報であれば任意に設定できる。該ノードが固定的なペイロードのみを送信する場合には、このような識別情報自体が不要であり、上記図５のプロファイル関連付けテーブルＰＦＴのように、固定的に記述されたプロファイル定義によって解釈可能である。
【０１１４】
次に、センサネットサーバＳＮＳからの下り通信の場合、有線区間パケット（テキスト形式）中で指定されたあて先ＭＡＣアドレス値から、対応するノードプロファイルが識別される。さらに、メッセージ中の識別情報から、対応するパケットプロファイルが＃Ｂであることが識別される。プロファイルＩＤ＝＃Ｂの記述に従ってエンコードされたバイナリ形式のコマンドが無線区間に送信される。
【０１１５】
図１３のＴ３では、センサノードＳＮ１はセンサネットサーバＳＮＳからのコマンドを受信して応答する。この応答も、上記Ｔ２と同様の手順によって行い、対応するプロファイルに従ってバイナリ形式の変換が行われる。
【０１１６】
前記のように、本実施形態においてはプロファイルＰＦに３つの役割を持たせており、役割の異なる２種類のプロファイルＰＦを用意している。プロファイルＰＦの第１の役割は、センサノードＳＮ１〜ＳＮｎが送信してきた接続通知パケットに格納された識別情報と対応けられることによって、特定のセンサノードＳＮ１〜ＳＮｎとの通信の際に該プロファイルＰＦで定義した情報を常に参照可能とすることである。この役割を果たすプロファイルＰＦを、本実施形態ではノードプロファイルと名付けている。プロファイルＰＦの第２の役割は、接続完了後に送受信される、センシングデータやコマンドといったパケットをエンコードまたはデコードするために必要な情報を提供することである。この役割を果たすプロファイルＰＦを、本実施形態ではパケットプロファイルと名付けている。さらにプロファイルＰＦの第３の役割は、特定のセンサノードが送受信するパケットをエンコードまたはデコードするための定義が、どのパケットプロファイルにより提供されているかを特定することである。本実施形態では、ノードプロファイル中で参照すべきパケットプロファイルを指定することによってこの役割を果たさせている。
【０１１７】
応用上の利便性を考えると、センサノードＳＮ１〜ＳＮｎはその種別や用途を単位として管理するのが好適であると考えられる。その際、本実施形態で示した仕組みを利用して、同一の種別のセンサノードＳＮ１〜ＳＮｎを同一のノードプロファイルに関連付けることで、センサノードＳＮ１〜ＳＮｎの種別に基づいた管理が非常に効率良く行うことが可能となる。また、センサノードＳＮ１〜ＳＮｎの本体部分および基本機能は同一であるが、搭載するセンサＳＳが異なるために送受信するパケット種別が異なるという場合には、新しいパケット種別に対応するパケットプロファイルのみを新たに用意することにより、非常に効率の良い管理が可能となる。
【０１１８】
本実施形態ではノードプロファイルとパケットプロファイルという２種類のプロファイルＰＦを用意する例を示したが、プロファイルＰＦの役割分担はこれに限定されるものではない。例えば、第１の役割と第２の役割の両方を果たす、単一種類のプロファイルＰＦを用いることも可能である。あるいは、第１の役割とこれに対応する関連付け制御の機能を全く提供せず、パケットのペイロードＰＬＤ中にパケットプロファイルに対応付けた識別情報を必ず格納することとして、ノードプロファイルを一切使用せずにパケットプロファイルのみによって第２の役割のみを提供する構成とすることも可能である。
【０１１９】
上記基地局ＢＳＴの処理のフローチャートは、図１７で示すようになる。
【０１２０】
基地局ＢＳＴは、接続通知パケットを受信すると（Ｓ１）、ペイロードＰＬＤの内容を解析する（Ｓ２）。そして、ＴＹＰＥ値フィールドの値に基づいて分岐する（Ｓ３）。ＴＹＰＥ値＝０ｘ０１であればＳ４へ進み、ＴＹＰＥ値＝０ｘ０２であればＳ８へ進み、ＴＹＰＥ値＝０ｘ０３であればS１２へ進む。
【０１２１】
Ｓ４では、プロファイル関連付けテーブルＰＦＴにＭＡＣアドレスとＴＹＰＥ値＝０ｘ０１及びプロファイルＩＤの値を記録する。そして、センシングデータの受信を待ち（Ｓ５）、センシングデータを受信すると（Ｓ６）、パケットＰＷＬのペイロードＰＬＤから先頭の２バイトをプロファイルＩＤの値として抽出する（Ｓ７）。
【０１２２】
そして、抽出したプロファイルＩＤに対応するプロファイルＰＦを読み込んで、受信したバイナリ形式のセンシングデータをテキスト形式のセンシングデータに変換する（Ｓ１６）。基地局ＢＳＴは、変換したテキスト形式のセンシングデータをセンサネットサーバＳＮＳへ送信する（Ｓ１７）。以降デコード・スタンバイの処理に復帰して次のセンシングデータを待つ。
【０１２３】
ＴＹＰＥ値＝０ｘ０２の場合は、Ｓ８で、プロファイル関連付けテーブルＰＦＴにＭＡＣアドレスとＴＹＰＥ値＝０ｘ０２及びプロファイルＩＤの値を記録する。そして、センシングデータの受信を待ち（Ｓ９）、センシングデータを受信すると（Ｓ１０）、パケットＰＷＬのＭＡＣアドレスからプロファイル関連付けテーブルＰＦＴを参照してプロファイルＩＤを決定する（Ｓ１１）。
【０１２４】
そして、決定したプロファイルＩＤに対応するプロファイルＰＦを読み込んで（Ｓ１６）、上記ＴＹＰＥ値＝０ｘ０１と同様に受信したバイナリ形式のセンシングデータをテキスト形式のセンシングデータに変換し、センサネットサーバＳＮＳへ送信する。
【０１２５】
ＴＹＰＥ値＝０ｘ０３の場合は、Ｓ１２で、プロファイル関連付けテーブルＰＦＴにＭＡＣアドレスとＴＹＰＥ値＝０ｘ０２及びプロファイルＩＤとＳｈｏｒｔＩＤの値を記録する。そして、センシングデータの受信を待ち（Ｓ１３）、センシングデータを受信すると（Ｓ１４）、パケットＰＷＬのペイロードＰＬＤの先頭バイトをＳｈｏｒｔＩＤとして抽出し、ＭＡＣアドレスからプロファイル関連付けテーブルＰＦＴを参照してＳｈｏｒｔＩＤに対応するプロファイルＩＤを決定する。
【０１２６】
そして、決定したプロファイルＩＤに対応するプロファイルＰＦを読み込んで（Ｓ１６）、上記ＴＹＰＥ値＝０ｘ０１と同様に受信したバイナリ形式のセンシングデータをテキスト形式のセンシングデータに変換し、センサネットサーバＳＮＳへ送信する。
【０１２７】
このように、一つの基地局ＢＳＴでありながらプロファイル関連付けテーブルＰＦＴで定義されたプロファイル関連付けテーブルＰＦＴをセンサノードＳＮ１〜ＳＮｎ毎にＭＡＣアドレスなどの識別子に基づいて、対応するプロファイルＰＦを適用することで、多種多様なセンサノードＳＮ１〜ＳＮｎを利用することが可能となる。
【０１２８】
そして、基地局ＢＳＴに配布するプロファイルＰＦを更新するだけで、新たなセンサノードＳＮ１〜ＳＮｎを利用することが可能になり、前記従来例のように基地局ＢＳＴのソフトウェアやセンサネットサーバＳＮＳのソフトウェアを更新する必要がない。また、センサノードＳＮ１〜ＳＮｎが送信するセンシングデータは、プロファイルＩＤを特定するために必要最小限のデータを含めばよい。このため、無線通信の限られたリソースを有効に利用しながらも、既存のセンサネットシステムで新たな種類のセンサノードの加入や新たな通信規格の採用を容易に行うことが可能となるのである。特に、上記ＴＹＰＥ＝０ｘ０２の場合では、ＭＡＣアドレスのみでプロファイルＩＤを決定することができるので、プロファイルＩＤを決定するためのデータを付加しなくとも良い。
【０１２９】
また、機能や性能の異なる複数の基地局ＢＳＴが混在する場合には、各基地局ＢＳＴで使用するプロファイルＰＦを変えるようにしてもよい。さらに、ＺｉｇＢｅｅ端末とＲＦＩＤタグのように無線通信規格そのものが異なる端末を一つのセンサネットシステムで統合的に扱うような場合では、基地局ＢＳＴや無線通信規格の識別情報に基づいてプロファイルＰＦとの参照関係を制御してもよい（図１５のｔｙｐｅ＝”０ｘ１１”や”０ｘ１２”）。
【０１３０】
＜プロファイルの設定＞
上記基地局ＢＳＴのプロファイル格納部ＰＳＴに格納するプロファイルＰＦの設定について、図１８を参照しながら以下に説明する。
【０１３１】
図１８は、センサネットシステムの管理者が利用するユーザ端末ＵＳＴと、センサネットサーバＳＮＳと３つの基地局ＢＳＴ１〜３で構成されたセンサネットシステムでプロファイルＰＦの更新を行う例を示す。
【０１３２】
まず、ユーザ端末ＵＳＴはセンサネットサーバＳＮＳにログインを行い、認証を完了する（Ｓ２０）。
【０１３３】
次に、ユーザ端末ＵＳＴはセンサネットサーバＳＮＳのプロファイル管理部ＰＭＧに対してプロファイルレジストリデータベースＰＤＢ（図３参照）に格納されているプロファイル群の全体構造を参照するよう要求する（Ｓ２１）。センサネットサーバＳＮＳは、要求に基づいて、プロファイルの全体構造をユーザ端末ＵＳＴに送信する。
【０１３４】
ユーザ端末ＵＳＴでは、管理者が所望のプロファイルを選択して、当該プロファイルＰＦの詳細をセンサネットサーバＳＮＳに要求する（Ｓ２２）。センサネットサーバＳＮＳは、要求に応じて指定されたプロファイルＰＦ＝＃ＡをプロファイルレジストリデータベースＰＤＢから読み込んで、ユーザ端末ＵＳＴに送信する。
【０１３５】
ユーザ端末ＵＳＴでは、このプロファイルＰＦ＝＃Ａについて変更を加え、＃ＡとしてセンサネットサーバＳＮＳのプロファイルレジストリデータベースＰＤＢへ登録する（Ｓ２３）。また、ユーザ端末ＵＳＴは、新たなセンサノードのために新たなプロファイルＰＦ＝＃Ｂを生成してプロファイルレジストリデータベースＰＤＢへ登録する。また、ユーザ端末ＵＳＴでは、不要になったプロファイルＰＦについて削除するようセンサネットサーバＳＮＳに指令する。
【０１３６】
ユーザ端末ＵＳＴの指令に応じてプロファイルＰＦの更新、追加または削除を行った結果を、センサネットサーバＳＮＳはプロファイル管理部ＰＭＧのプロファイルレジストリデータベースＰＤＢへ適用する。
【０１３７】
プロファイルレジストリデータベースＰＤＢが更新されると、センサネットサーバＳＮＳは、センサネットシステム内の基地局ＢＳＴ１〜３に対して更新されたプロファイルＰＦの配信を行う（Ｓ２４）。このとき、センサネットサーバＳＮＳは、プロファイルレジストリデータベースＰＤＢのプロファイルＰＦのうち更新差分の情報を配信し、通信量を抑制する。
【０１３８】
各基地局ＢＳＴ１〜３では、センサネットサーバＳＮＳから受信したプロファイルＰＦの更新差分に基づいて、プロファイルＰＦの更新、追加、削除などプロファイル格納部ＰＳＴのパラメータを更新する（Ｓ２５）。
【０１３９】
そして、プロファイル格納部ＰＳＴの更新が完了すると、各基地局ＢＳＴ１〜３は、新たな運用状態となる（Ｓ２６）。
【０１４０】
このように、センサノードの種類の変更や仕様の変更などに応じて、センサネットサーバＳＮＳのプロファイルレジストリデータベースＰＤＢを更新すると、センサネットシステム内の全ての基地局ＢＳＴ１〜３にプロファイルＰＦの更新を自動的に反映させることができる。
【０１４１】
したがって、極めて少ない労力で全ての基地局ＢＳＴ１〜３にプロファイルＰＦの更新を実現し、また、センサネットサーバＳＮＳのプロファイルレジストリデータベースＰＤＢを更新した後には、基地局ＢＳＴ１〜３が即座に更新内容を反映するので、センサノードの追加や更新を迅速に行うことが可能となる。
【０１４２】
＜まとめ＞
以上のように、本発明では、基地局ＢＳＴが無線ネットワークＷＬＮから受信したセンシングデータを、より扱いやすい形式のセンシングデータに変換するためのフォーマット変換ルールをプロファイルＰＦとして上位のサーバ（センサネットサーバＳＮＳ）から設定可能となる。これにより、基地局ＢＳＴのソフトウェアを更新することなく新たな種類のセンサノードや新たな通信規格を容易に採用することができる。特にバイナリ形式からテキスト形式への変換により、より扱いやすいデータでの管理が可能となる。
【０１４３】
基地局ＢＳＴでは、センサネットサーバＳＮＳから配信されたプロファイルによって、基地局ＢＳＴは受信したセンサノードＳＮの未加工情報に、意味情報を付加してから有線ネットワークＷＤＮに送信することで、リソースの制約が多い無線ネットワークＷＬＮの負荷を低減して利用効率を向上させることができる。
【０１４４】
そして、センサネットサーバＳＮＳに格納されるセンシングデータには、センサノードの種類に応じたプロファイルＰＦによりゲートウェイ（基地局ＢＳＴ）で意味情報が付加されているので、センサネットサーバＳＮＳでは容易にセンシングデータの加工を施すことができ、多様なセンサノードを利用するセンサネットにおいて、アプリケーションの開発及び保守を容易にすることができる。
【０１４５】
また、センサネットサーバＳＮＳでは、センサＳＳの出力値を記載したテキスト形式のセンシングデータを測定値変換プラグインで変換するようにしたので、新たな種類のセンサノードを追加する際には測定値変換プラグインを追加するだけでよいので、既存のセンサネットシステムで新たな種類のセンサノードの加入を容易かつ低コストで行うことが可能となる。
【０１４６】
なお、上記ではバイナリ形式のセンシングデータをテキスト形式のセンシングデータに変換する変換エンジンＣＶＥＮとパーサＰＳＲを基地局ＢＳＴに設けた例を示したが、センサネットサーバＳＮＳに変換エンジンＣＶＥＮとパーサＰＳＲを設けても良い。あるいは、基地局ＢＳＴからセンサネットサーバＳＮＳに至る有線ネットワークＷＤＮの経路上に変換エンジンＣＶＥＮとパーサＰＳＲを有する計算機を設けても良い。
【０１４７】
また、上記ではセンサＳＳの測定データを有意な情報に変換する変換部ＤＣＶをセンサネットサーバＳＮＳに設けた例を示したが、変換部ＤＣＶを基地局ＢＳＴに設けても良い。この場合、センサネットサーバＳＮＳに格納されるセンシングデータには、センサノードの種類に応じたプロファイルＰＦによりゲートウェイ（基地局ＢＳＴ）で意味情報の付加が行われ、プラグインにより測定値の変換がされているので、センサネットサーバＳＮＳはセンシングデータの加工を施す必要が無くなって負荷を低減することができる。
【０１４８】
また、上記実施形態では、プロファイルの配布とセンシングデータを格納するデータベースＤＢを同一の計算機で構成した例を示したが、プロファイルを配布するサーバと、センシングデータを格納するデータベースＤＢを提供するサーバを独立した計算機で構成しても良い。
【０１４９】
また、上記ではプロファイルＰＦを用いて、バイナリ形式のセンシングデータをテキスト形式のセンシングデータへ変換する変換エンジンＣＶＥＮを基地局ＢＳＴに配置し、センサＳＳの出力値をＳＩ単位系へ変換する変換部ＤＣＶを、センサネットサーバＳＮＳに配置した例を示したが、センサネットサーバＳＮＳまたは基地局ＢＳＴの何れか一方に、変換エンジンＣＶＥＮと変換部ＤＣＶを備えるようにしても良い。この場合、プロファイルを第１変換定義情報として扱い、プラグインを第２変換定義情報として扱えばよい。つまり、プラグインもセンサノードＳＮ１〜ＳＮｎの種類や必要とする処理に応じて任意に設定することができる。
【０１５０】
＜変形例１＞
前記図３に示した測定値変換プラグインでは、センサＳＳの出力値（１０進変換値）をＳＩ単位系の有意な情報に変換する例を示したが、図１９で示すように、温度値変換プラグインＰＩ１’のように、センサＳＳの出力値を変換するための変換テーブルＰＩ１Ｔａと、変換した測定値に対してセンサノードの個体による誤差を補償する個体特性補正テーブルＰＩ１Ｔｂとを備えてもよい。これにより、センサノードの個体毎の誤差を補正してより正確なセンシングデータを提供することができる。
【０１５１】
＜第２実施形態＞
図２０〜図２２は、第２の実施形態を示し、所定のスリープ時間が経過したときに測定したセンサＳＳの出力値が、この時点で求めた測定値の予測値が許容範囲（許容誤差）内であればセンサノードＳＮ１〜ＳＮｎは測定結果を送信せず、センサネットサーバＳＮＳではセンサノードＳＮ１〜ＳＮｎと同一のアルゴリズムで予測値を演算してセンシングデータとするものである。センサネットシステムのハードウェアは前記第１実施形態と同様であり、センサノードＳＮ１〜ＳＮｎの制御プログラムと、基地局ＢＳＴのプロファイルＰＦ及びセンサネットサーバＳＮＳのプラグインが異なる。
【０１５２】
センサノードＳＮ１〜ＳＮｎ（以下、ＳＮ１とする）では、電池ＢＡＴにより長時間の駆動が必要であり、このため電力消費量の大きい無線通信の回数は極力低減した方が望ましい。
【０１５３】
特に、センサＳＳが温度センサや湿度センサの場合では、測定値が環境に依存しているため急激な変動は頻繁には生じない。そこで、測定値の変動傾向から次回の予測値を演算し、スリープ期間が終了した時点の測定値（実測値）に対して予測値が予め設定した許容範囲内であれば、測定値の送信を省略することで電力消費を大幅に抑制する。つまり、スリープ期間が終了する度に測定値を送信する場合に比して、無線通信に要する電力消費を極力低減するのである。
【０１５４】
一方、センサネットサーバＳＮＳでは、測定値を受信できなかった値をセンサノードＳＮ１と同一の予測演算によりセンシングデータを生成し、データベースＤＢを補完する。つまり、センサノードＳＮ１は新たに測定値を送信するときに、送信しなかった測定値の回数をセンサネットサーバＳＮＳへ通知する。センサネットサーバＳＮＳは、センサノードＳＮ１のスリープ期間をセンサネット管理部ＮＭＧで管理しているので、最後に受信した測定値の時刻からスリープ期間毎に予測値を演算し、センシングデータとして生成することで、実際には通信の無かったセンシングデータを正確に補完することができるのである。
【０１５５】
＜制御の概要＞
図２０は、本第２実施形態のセンサノードＳＮ１における実測値と予測値の関係と、センサネットサーバＳＮＳにおける実測値（図中黒丸）と予測値（図中白丸）の関係を示すグラフである。この例ではセンサＳＳとして温度センサを用いた場合を示す。
【０１５６】
図中左側のセンサノードＳＮ１では、まず最初に、２つの基準測定点０，１を作成する。このため、時刻Ｔ１１で測定した測定値（実測値）を基準測定点０とし、所定のスリープ期間後の時刻Ｔ１２で測定した測定値を基準測定点１として記憶する。なお、各時刻Ｔ１１，Ｔ１２ではそれぞれ基地局ＢＳＴを介してセンサネットサーバＳＮＳへ測定値を送信する。図２０の右側に示すセンサネットサーバＳＮＳのデータベースＤＢには、時刻Ｔ１１、Ｔ１２における測定値（実測値）が前記第１実施形態で述べたように有意な情報に変換されたセンシングデータがそれぞれ格納される。
【０１５７】
次に、センサノードＳＮ１では、時刻Ｔ１３で２つの基準測定点０，１から今回の予測値を後述するように演算する。そして、センサＳＳを駆動して測定値を取得し、この測定値が予測値の所定の範囲を加えた許容範囲内であれば送信せずにスリープ状態へ移行する。なお、このとき、スリープ状態へ移行する前に、送信を省略した回数（以下、みなし通信回数とする）を記憶する。時刻Ｔ１４も同様に予測値と測定値を比較して、測定値が許容範囲内であるので送信は行わずにみなし通信回数をインクリメントしてスリープ状態へ移行する。
【０１５８】
時刻Ｔ１５では、測定値が許容範囲を超えたので、センサノードＳＮ１は測定値と、前回の送信時から現在までに送信を省略した回数を基地局ＢＳＴへ送信する。また、センサノードＳＮ１では、予測値を演算する基準測定点が変化したので、基準測定点０に時刻Ｔ１５の測定値をセットし、基準測定点１をクリアし、次回の測定値をセットする。そして、次回の時刻Ｔ１６では測定値を基準測定点１にセットし、測定値を基地局ＢＳＴへ送信する。次の時刻Ｔ１７では、２つの基準測定点０，１がセットされているので、センサノードＳＮ１は予測値を演算する。そして、センサＳＳから測定値を取得して、測定値が許容範囲内であるかを判定する。センサノードＳＮ１は測定値が許容範囲内であったので、送信は行わずにスリープ状態へ移行する。
【０１５９】
一方、センサネットサーバＳＮＳは、時刻Ｔ１５で測定値とみなし通信回数を受信する。この例では、みなし通信回数が２であり、センサノードＳＮ１のスリープ期間が既知であることから、センサノードＳＮ１は、最後の受信時刻Ｔ１２から、スリープ期間毎の時刻Ｔ１３、Ｔ１４の予測値を演算し、各時刻Ｔ１３、Ｔ１４のセンシングデータを生成する。そして、センサネットサーバＳＮＳは、生成した時刻Ｔ１３、Ｔ１４の予測値と、受信した時刻Ｔ１５の測定値を変換部ＤＣＶで変換した後にデータベースＤＢへ格納する。
【０１６０】
以上のように、測定値が許容範囲内であればセンサノードＳＮ１は送信を行わず、省略した測定値は、センサノードＳＮ１と同一の予測演算によりセンサネットサーバＳＮＳではセンサノードＳＮ１からの通信があったものとみなして生成することで、無線通信回数を大幅に低減することができる。これにより、センサノードＳＮ１の電池交換や充電などのメンテナンス間隔が飛躍的に増大し、長期間メンテナンスなしで稼動可能なセンサノードＳＮ１を提供できるのである。なお、以上のように、センサノードＳＮ１とセンサネットサーバＳＮＳで、測定値の変化が許容範囲内にあれば実際のセンシングデータの通信を行わずに、センサネットサーバＳＮＳで予測値を測定値に置き換えて生成する形態を、以下、みなし通信と呼ぶ。
【０１６１】
さらに、センサネットサーバＳＮＳ及び基地局ＢＳＴは、センサノードＳＮ１からの通信回数が大幅に減少するので、処理負荷を大幅に削減できる。換言すれば、より多くのセンサノードＳＮ１をセンサネットシステムに参加させても、センサネットサーバＳＮＳや基地局ＢＳＴが過負荷になるのを防止できるのである。
【０１６２】
＜センサノードの制御＞
図２１は、センサノードＳＮ１の機能要素のうち、みなし通信を行う機能要素のブロック図である。メモリＲＡＭには、上記基準測定点０，１を格納する基準点格納部Ｄ１とセンサＳＳが測定した測定値を格納する実測値格納部Ｄ２と、みなし通信回数を計数するみなし通信カウンタＤ３が設定される。なお、実測値格納部Ｄ２は、所定回数の測定値を格納する有限の領域であり、例えば、リングバッファなどで構成すればよい。
【０１６３】
制御部ＣＴＫには、所定のスリープ期間が経過する度にセンサＳＳを駆動して測定値を取得し、実測値格納部Ｄ１へ格納する実測部ＣＴＬ１と、実測部ＣＴＬ１が測定を行うときに、現在の予測値を後述するように演算する予測値演算部ＣＴＬ２と、測定値が予測値に対応する許容範囲内にあれば、センシングデータの送信を省略してみなし通信カウンタＤ３をインクリメントする一方、測定値が許容範囲を超えていれば、測定値とみなし通信回数を無線通信制御部ＳＲＦから基地局ＢＳＴへ送信するように指令する送信判定部ＣＴＬ３と、を含んで構成される。なお、その他の構成は前記第１実施形態の図１と同様である。
【０１６４】
図２２は、制御部ＣＴＬで行われるみなし通信の制御の一例を示すフローチャートである。この処理は、所定のスリープ期間毎に実行される。
【０１６５】
まずＳ２０では、２つの基準測定点０，１に測定値がセットされているか否かを判定する。２つの基準測定点０，１の測定値が揃っていない場合には、Ｓ３１に進んでセンサＳＳを駆動し、測定値を取得する。そして、Ｓ３２で基準測定点０または基準測定点１に測定値を格納する。次に、Ｓ３３では、測定値をセンシングデータとして基地局ＢＳＴへ送信する。その後、Ｓ４２でスリープ状態へ移行する。
【０１６６】
制御部ＣＴＬのタイマＴＭＲが所定のスリープ期間をカウントすると制御部ＣＴＬはスリープ状態から起動状態へ移行し、再び、Ｓ３０で判定を行う。基準測定点０を測定した後では、基準測定点１がセットされていないので、上記と同様にＳ３１〜Ｓ３３の処理で測定値を取得して基地局ＢＳＴへ送信し、基準測定点１にこの時点での測定値をセットする。
【０１６７】
次回以降のＳ３０では、２つの基準測定点０，１が揃っているので、Ｓ３４に進み、予測値の演算を行う。そしてＳ３５ではＳ３１と同様にセンサＳＳの測定値を取得する。Ｓ３６では現時点の測定値が上記Ｓ３４で求めた予測値に基づく許容範囲内であるかを判定する。測定値が許容範囲内であればセンシングデータの送信を行わず。Ｓ３７へ進んでみなし通信カウンタの値をインクリメントした後に、Ｓ４２へ進んでスリープ状態へ移行する。
【０１６８】
一方、Ｓ３６の判定で、測定値が許容範囲を超えていた場合には、Ｓ３８へ進んで、現在の測定値とみなし通信カウンタの値を基地局ＢＳＴへ送信する。そして、Ｓ３９で現在の測定値を基準測定点０にセットした後、Ｓ４０で基準測定点１をリセットする。さらに、Ｓ４１でみなし通信カウンタを０でリセットした後に、Ｓ４２へ進んでスリープ状態へ移行する。すなわち、Ｓ３８〜Ｓ４１では、測定値が許容範囲を超えると、現在の測定値とみなし通信カウンタの値を基地局ＢＳＴへ送信し、基準測定点０，１及びみなし通信カウンタの値をリセットし、現在の測定値を基準測定点０にセットするのである。このため、次回の測定値はＳ３１〜Ｓ３３で基準測定点１を取得し、基地局ＢＳＴへ送信することになる。
【０１６９】
以上の処理をスリープ期間が経過する度に実行することで、図２０で示したように、２つの基準測定点０，１に基づく測定値の変化傾向を予測して、測定値が許容範囲内の期間は実際のセンシングデータの送信を行わず、センサネットサーバＳＮＳで生成した予測値を実際の測定値に代わってセンシングデータとするのである。
【０１７０】
なお、上記みなし通信でセンサノードＳＮ１が送信するセンシングデータのペイロードＰＬＤのフォーマットは、例えば、図２３のようにすればよい。
【０１７１】
図２３では、０バイト目から６バイト目を使用し、先頭から、イベントを示す値と、測定値（この例では温度のセンサ出力値）、タイムスタンプ、みなし通信回数（図中、cTransCount）の順で格納する。なお、上記基準測定点０，１を送信するＳ３３の処理では、みなし通信回数を０として送信する。
【０１７２】
＜予測値の演算＞
上記Ｓ３４で行う予測値の演算は、次のように行うことができる。以下では、一次式により予測値ｘｅを求める例を示す。
【０１７３】
【数１】
0004719034.tif 000002
【０１７４】
ただし、
ｘｅ：予測値
Ｘ0：基準測定点０の測定値
Ｔ0：基準測定点０の時刻
Ｘ1：基準測定点１の測定値
Ｔ1：基準測定点１の時刻
ｔ  ：対象となる時刻
である。なお、基準測定点０＝（Ｘ0、Ｔ0）、基準測定点１＝（Ｘ1、Ｔ1）である。
【０１７５】
そして、許容誤差範囲をｄとし、対象時刻の測定値をｘとすると、上記Ｓ３６の判定は次式を満たすか否かを判定する。
【０１７６】
【数２】
0004719034.tif 000003
【０１７７】
ただし、ｄ：許容誤差
である。
【０１７８】
上記（２）式のように対象時刻ｔ（例えば、現時点）の測定値ｘと予測値ｘｅの絶対値の差が予め設定した許容誤差の範囲内であれば、センサノードＳＮ１はセンシングデータを送信しない。一方、対象時刻ｔの測定値ｘと予測値ｘｅの絶対値の差が予め設定した許容誤差の範囲を超えたときにはセンサノードＳＮ１がセンシングデータを送信することになる。
【０１７９】
なお、センサネットサーバＳＮＳでは、上記（１）式により予測値の演算を行う。
【０１８０】
また、上記では一次式により予測値ｘｅを求める例を示したが、より予測精度を向上させるために二次式や高次の予測式を用いても良い。
【０１８１】
＜基地局の処理＞
基地局ＢＳＴでは、センサノードＳＮ１から受信したセンシングデータを前記第１実施形態と同様に解析し、センサノードＳＮ１のＭＡＣアドレスに対応するプロファイルＰＦを呼び出す。
【０１８２】
図２４で示すように、基地局ＢＳＴが受信した無線通信区間のパケットＰＷＬは、前記第１実施形態と同様に、変換エンジンＣＶＥＮで所定のプロファイルＰＦが呼び出される。ここで、みなし通信を行うプロファイルＰＦには、センサネットサーバＳＮＳのデータイベント発行部ＥＶＰで呼び出すプラグイン名（図中、func0016）をテキスト形式のセンシングデータに埋め込むよう記述される。
【０１８３】
変換エンジンＣＶＥＮは、このプロファイルＰＦに基づいて、センサノードＳＮ１から受信したバイナリ形式のセンシングデータから温度を１０進数に変換し、タイムスタンプとプラグイン名及びみなし通信回数を埋め込んだテキスト形式のセンシングデータを生成する。そして、基地局ＢＳＴはプラグイン名とみなし通信回数を含むテキスト形式のセンシングデータをセンサネットサーバＳＮＳへ送信する。
【０１８４】
＜センサネットサーバの処理＞
次に、図２５はセンサネットサーバＳＮＳで行われるみなし通信処理の機能要素を示すブロック図である。
【０１８５】
基地局用インターフェースＢＩＦは、基地局ＢＳＴから受信したセンシングデータをイベント発行部ＥＶＰへ送る。イベント発行部ＥＶＰは、テキスト形式のセンシングデータを解析してセンサノードＳＮ１のＩＤ（ＭＡＣアドレス）から呼び出すプラグインを決定する。このとき、みなし通信のセンシングデータには、図２４で示したように呼び出すプラグイン名（func0016）が埋め込まれているので、イベント発行部ＥＶＰは、指定されたみなし通信用のプラグインＰＩ５を呼び出し、変換処理を行う。
【０１８６】
みなし通信用プラグインＰＩ５は、上記センサノードＳＮ１の予測値の演算と同様のロジックを備えた予測アルゴリズムＰＩ５０と、基準測定点０，１を保持する基準測定点保持部ＰＩ５１と、制御用のパラメータ（例えば、スリープ期間）を保持する制御パラメータＰＩ５２を含む。
【０１８７】
みなし通信用プラグインＰＩ５は、図２４に示したテキスト形式のセンシングデータを受け付けると、次の処理を行う。
【０１８８】
まず、みなし通信回数を読み込んで、生成する予測値の数ｉを求める。次に、基準測定点保持部ＰＩ５１から基準測定点０（Ｘ0、Ｔ0）、基準測定点１（Ｘ1、Ｔ1）を読み込む。次に、制御パラメータＰＩ５２からスリープ期間を読み込んで、基準測定点１の測定時刻Ｔ1に基づいて生成する予測値の時刻ｔｍ（ｍ＝１〜ｉ）を求める。なお、センサノードＳＮ１のスリープ期間は、センシングデータに記載されたセンサノードＳＮ１のＭＡＣアドレスから、センサネット管理部ＮＭＧから取得しても良い。
【０１８９】
そして、上記（１）式の現在時刻ｔに上記予測値の時刻ｔｍをｍ＝１〜ｉまで順次代入して、基準測定点１（Ｘ1、Ｔ1）以降の予測値を測定点（Ｘm、Ｔm）として生成する。こうして、上記（１）の予測式から演算した測定点（Ｘm、Ｔm）と現在の測定値及びタイムスタンプを、温度値変換用プラグインＰＩ１でセンサＳＳの出力値から摂氏などの所定の単位を付加した有意な測定値に変換してからセンシングデータ格納用データベースＤＢへ格納する。なお、みなし通信用プラグインＰＩ５は、出力先を温度値変換用プラグインＰＩ１に設定しているものとする。
【０１９０】
以上のように、センサノードＳＮ１とセンサネットサーバＳＮＳで、同一の予測式を用いることで、実際にはセンサノードＳＮ１が送信しなかったセンシングデータを、センサネットサーバＳＮＳで推定して生成する。
【０１９１】
このように、第２の実施形態によるみなし通信では、電池ＢＡＴで駆動されるセンサノードＳＮ１の無線通信回数を大幅に低減することで、センサノードＳＮ１のメンテナンス期間の増大や機器寿命の増大を図り、さらに、センサネットサーバＳＮＳ及び基地局ＢＳＴのトラフィックを大幅に削減して負荷を低減することが可能となる。これにより、基地局ＢＳＴやセンサネットサーバＳＮＳが処理可能なみかけ上のセンサノードＳＮ１を増大することができる。
【０１９２】
なお、上記では２つの基準測定点を用いる例を示したが、より多数の基準測定点を用いることで予測値の精度を向上させることが可能となる。
【０１９３】
＜第３実施形態＞
図２６は、第３の実施形態を示し、前記第１、第２実施形態で示したプロファイルＰＦを利用する変換エンジンＣＶＥＮをソフトウェアアダプタとして、前記第１または第２実施形態のゲートウェイ（基地局ＢＳＴ）だけではなく、センサネットサーバＳＮＳやモバイル基地局にソフトウェアアダプタとして適用する例を示したものである。
【０１９４】
単一または複数のセンサネットサーバＳＮＳには、有線ネットワークＷＤＮを介してＲＦＩＤのリーダやカメラまたはマイクなどの有線のセンサノードが接続される。そして、センサネットサーバＳＮＳでは、これらの有線センサノードＳＮやＲＦＩＤリーダ（またはライタ）のセンシングデータを利用するため、前記第１実施形態のプロファイルＰＦを用いた変換エンジンＣＶＥＮとパーサＰＳＲをセンサネットサーバＳＮＳに実装する。
【０１９５】
また、モバイル計算機や携帯電話に前記第１実施形態または第２実施形態の変換エンジンＣＶＥＮとパーサＰＳＲをソフトウェアアダプタとして組み込むことで、モバイル基地局ＭＢＳＴとすることができる。モバイル基地局ＭＢＳＴの配下には、前記第１実施形態の無線通信によるセンサノードＳＮ１〜ＳＮｎや有線センサノードを参加させることができ、例えば、図中のように、個人の識別子を通知する名札型センサノードＳＮＮや脈拍を体温を検出する腕輪型センサノードＳＮＢを用いることができる。
【０１９６】
すなわち、前記第１または第２実施形態で示した変換エンジンＣＶＥＮ及びパーサＰＳＲは、ソフトウェアアダプタとしてセンサネットシステムのゲートウェイからセンサネットサーバＳＮＳまでの区間の任意の位置にある計算機に組み込むことことができる。
【０１９７】
これにより、基地局ＢＳＴとして専用の計算機を設けることなく大規模なセンサネットシステムを容易かつ低コストで構築することが可能となるのである。
【０１９８】
＜第４実施形態＞
図２７は第４の実施形態を示し、前記第１実施形態のセンサノードＳＮ１のセンサとして、温度センサと複数の半導体ひずみセンサを備え、基地局ＢＳＴとセンサネットサーバＳＮＳでのフォーマット変換及び測定値変換を上記ノードプロファイルで行うようにしたものである。その他の構成は前記第１実施形態と同様である。
【０１９９】
センサノードＳＮ１は、温度センサＳＳ１と複数の半導体ひずみセンサＳＳ２〜ＳＳ５を備えている。その他の構成は、前記第１実施形態のセンサノードＳＮ１と同様である。
【０２００】
半導体ひずみセンサは、シリコン単結晶におけるピエゾ抵抗の原理を応用してひずみを検出する、シリコン基板上に形成可能な回路機構である。従来主流であった抵抗線ひずみゲージ方式のひずみセンサと比べると、超小型、超低電力、高感度等の特長を備えており、小型低電力センサノードへの搭載に非常に適している。
【０２０１】
本実施形態のように、センサノードＳＮ１が複数のひずみセンサＳＳ２〜ＳＳ５を搭載する目的としては、異なる軸方向のひずみを計測したり、応力破壊に備えて予備のセンサを搭載しておく等が想定される。
【０２０２】
基地局ＢＳＴでは、センサノードＳＮ１からの接続通知を受信すると、前記第１実施形態の図１及び図２で示したように変換エンジンＣＶＥＮとパーサＰＳＲがセンサノードＳＮ１に対応するノードプロファイルＰＦ１を選択する。
【０２０３】
ノードプロファイルＰＦ１は、センサノードＳＮ１に１つの温度センサＳＳ１と４つの半導体ひずみセンサＳＳ２〜５を搭載していることや、動作関連のパラメータ情報が記述されている。ノードプロファイルＰＦ１では、各々の半導体ひずみセンサＳＳ２〜５のキャリブレーション（個体差の補正）を行うための、半導体ひずみセンサＳＳ２〜５のゲイン（sensorGain）やオフセット（sensorOffset）が設定可能である。また、センサノードＳＮ１は定期的にセンシングを行うが、測定したひずみ値の最大値または最小値を超えた場合にはじめて測定値の送信を実行するといった閾値ベースの動作（thresholdBaseDriven）を行う。
【０２０４】
ノードプロファイルＰＦ１には、その動作パラメータであるセンシング周期（SensingInterval）や測定閾値（maxThreshold、minThreshold）が設定可能であることも記述されている。さらには、センサノードＳＮ１は、測定したひずみ値が閾値を越えない場合であっても一定時間が経過すれば強制的にセンシングデータを送信する（maxTxInterval）ことによって、センサノードＳＮ１のハートビート（HeartBeat）の機能も提供できる。このように、ノードプロファイルＰＦ１には、センサノード種別毎にパケット種別を識別する役割を果たすだけにとどまらず、そのセンサノードに特有の機能や制御可能なパラメータを記述することにより、センサネットシステムの管理者がこのセンサノードを制御または管理するために必要な情報（センサノードがどのような機能を有しており、どのようなパラメータが制御可能か）を提供する役割も果たすことができる。センサネットシステムの管理者にとって利便性の高い管理用インタフェースを提供することが可能となる。
【０２０５】
具体的には、前記第１実施形態の図３に示したセンサネットサーバＳＮＳにおいて、プロファイル管理部ＰＭＧからセンサネット管理部ＮＭＧに対してノードプロファイルＰＦ１が配布されることにより、管理用インタフェースＭＩＦは、センサネット管理部ＮＭＧを介して各センサノードＳＮ１〜ＳＮｎのランタイム情報に加えて機能やパラメータの情報を管理者に提供することができる。
【０２０６】
センサノードＳＮ１は、基地局ＢＳＴの配下に入ると接続通知を送信し、基地局ＢＳＴでは前記第１実施形態と同様にして変換エンジンＣＶＥＮとパーサＰＳＲが当該センサノードＳＮ１に適用するノードプロファイルＰＦ１を選択する。なお、無線ネットワークＷＬＮのペイロードＰＬＤのフォーマットは前記第１実施形態と同様である。基地局ＢＳＴは、ノードプロファイルＰＦ１に基づいて以降のセンシングデータの変換定義を設定する。基地局ＢＳＴは、接続通知パケットを受信すると前記第１実施形態と同様にセンサネットサーバＳＮＳへ通知を行う。
【０２０７】
センサネットサーバＳＮＳでは、接続通知のあったセンサノードＳＮ１のＭＡＣアドレスを基地局ＢＳＴの配下にあることをセンサネット管理部ＮＭＧに記録する。さらに、このＭＡＣアドレスのセンサノードＳＮ１が基地局ＢＳＴの配下にいることを管理する。
【０２０８】
半導体ひずみセンサＳＳ２〜５等のセンサデバイスにおいては、その形成プロセスや外部環境に依存して、センサの出力値に個体差や、零バランス、ヒステリシス等が発生する場合がある。精密測定用途では、あらかじめセンサデバイスにホイートストンブリッジ回路等の補償回路が組み込まれることが多いが、センサノードやセンサデバイスを可能な限り単純で安価なハードウェア構成としたい場合も想定される。半導体ひずみセンサＳＳ２〜５の場合には、温度に依存してセンサの出力値が変化する特性がある。これを補正するために補償回路を用いることも可能であるが、本実施形態ではセンサノードＳＮ１に半導体ひずみセンサＳＳ２〜５（補償回路なし）と共に温度センサＳＳ１を搭載し、センサネットサーバＳＮＳ側に、ひずみ値に温度を加味した補正を行った上でＳＩ単位（stain）への変換を行うプラグインＰＩ２０を用意しておく。また、センサネットサーバＳＮＳの変換部ＤＣＶは、前記第１実施形態と同様に温度値変換用プラグインＰＩ１を有する。
【０２０９】
センサネットサーバＳＮＳは、基地局ＢＳＴでテキスト形式に変換されたセンサノードＳＮ１からのセンシングデータを受信すると、イベント発行部ＥＶＰが図２７に示したひずみ値変換用プラグインＰＩ２０と温度値変換用プラグインＰＩ１を呼び出して値の変換を指令する。
【０２１０】
変換部ＤＣＶは、温度値変換用プラグインＰＩ１で温度センサＳＳ１の出力値をＳＩ単位変換し、ひずみ値変換用プラグインＰＩ２０は、温度値変換用プラグインＰＩ１の出力に基づいてひずみ値の温度補正を行ってＳＩ単位へ変換する。このため、ひずみ値変換用プラグインＰＩ２０は、温度値変換用プラグインＰＩから出力値（温度値：ＳＩ単位）を取得してひずみ値のＳＩ単位への変換を制御する変換制御部ＰＩ２１と、ひずみ値を補正するための変換テーブルＰＩ２２と、センシングデータに記載されたセンサノードＳＮ１のＩＤに基づいて個体の特性に応じた補正値を格納した個体特性補正テーブルＰＩ２３とを備える。
【０２１１】
変換制御部ＰＩ２１は予め設定された変換定義情報に基づいてセンシングデータのひずみセンサＳＳ２〜５の出力値を、ＳＩ単位へ変換する。次に、変換制御部ＰＩ２１は、温度値変換用プラグインＰＩから温度値を取得して、ＳＩ単位へ変換したひずみ値に温度補正を行う。最後に、変換制御部ＰＩ２１は、センシングデータに含まれるセンサノードＳＮ１のＩＤから個体特性補正テーブルＰＩ２３を参照して、センサノードＳＮ１に固有の補正値を取得する。そして、変換制御部ＰＩ２１は、固有の補正値でさらにひずみ値を補正して出力し、データベースＤＢに格納する。
【０２１２】
このように、センサネットサーバＳＮＳの変換部ＤＣＶのプラグインも、基地局ＢＳＴの変換エンジンＣＶＥＮのプラグインと同様に、センサノードＳＮ１のＩＤ等の識別子に応じた変換定義情報を選択することで、多種多様なセンサノードの出力値を加工することができるのである。
【０２１３】
特に、センサノードの個体特性に応じた補正や、複数のセンサＳＳの出力値に基づく補償など、単に出力値からＳＩ単位への変換だけではなく、複数の処理をプラグインに定義することが可能となる。
【０２１４】
なお、センサノードＳＮ１は1センチ角以下の小型なものではあるが、用途や環境によっては、センサノードＳＮ１の基板上でも多少の温度分布が生じる可能性がある。そのような場合には、温度センサＳＳ１と半導体ひずみセンサＳＳ２〜５とは、基板上で可能な限り近接あるいは接触するように配置することが好適であろう。温度センサＳＳ１がひずみセンサＳＳ２〜５よりもさらに小型である場合には、回路形成技術によりひずみセンサ回路の中に温度センサ回路を組み込んでも良い。
【０２１５】
なお、センサノードＳＮ１が温度センサＳＳ１を半導体ひずみセンサＳＳ２〜５と同一のセンサノードに搭載されない場合であっても、近隣に設置した別のセンサノードＳＮ２等が温度センサを搭載している場合には、その温度値を用いてひずみ値の温度補正を行っても良い。この場合は、前記第２実施形態と同様に、基地局ＢＳＴの変換エンジンＣＶＥＮが、テキスト形式のセンシングデータに、センサネットサーバＳＮＳで呼び出すプラグインを定義しておけばよい。
【０２１６】
また、ひずみ値と温度値を同時に測定することの別の効果として、測定対象における物理現象を精度良く捉えられるようになることが挙げられる。例えば、高温や低音にさらされる過酷な環境に設置する構造物の耐久性を評価するためには、ひずみと温度の両方を加味した上で評価することが必要である。また温度以外にも、湿度や振動、加速度といった多様な物理量も同時に収集することによって、測定の効果をより高いものとすることができる。構造物の材質が例えば鉄筋であるか、コンクリートであるか、木材であるかによって、これら多様な物理量を用いた耐久性の評価の方法は変わり得るので、各々の材質に対応した評価アルゴリズムをプラグインに持たせることが考えられる。また、これらの多様な物理量を測定するセンサは、センサノードＳＮ１に搭載しても良いし、近隣に設置した別のセンサノードＳＮ２等に搭載しても良い。
【０２１７】
＜第５実施形態＞
図２８は、第５の実施形態を示し、前記第１実施形態で示したセンサネットサーバＳＮＳに、ＲＦＩＤコントローラと接続するＲＦＩＤシステム用インターフェースＲＦＩＦと、ＲＦＩＤシステム用インターフェースＲＦＩＦの出力にプロファイルＰＦＲＦを適用して、センサネットシステムのイベント発行部ＥＶＰに接続するプロファイルドアダプタＰＦＡＤを付加したものである。
【０２１８】
つまり、プロファイルＰＦを利用する変換エンジンＣＶＥＮをソフトウェアアダプタとして、前記第１または第２実施形態のゲートウェイ（基地局ＢＳＴ）だけではなく、センサネットサーバＳＮＳやモバイル基地局にソフトウェアアダプタとして適用する例を示したものである。
【０２１９】
なお、ＲＦＩＤコントローラはＲＦＩＤタグの読み書きを行うＲＦＩＤリーダ／ライタに接続される。パッシブ型のＲＦＩＤタグは、機能面ではアクティブ型のセンサチップより劣るが、安価で扱いやすいことから物品トレーサビリティに威力を発揮し、バーコードシステムの替わる新しいＩＴシステムとしての導入が進んでいる。このようなＲＦＩＤシステムとセンサネットシステムとをシームレスに連携させることによって、より高度な物品トレーサビリティや生産管理への応用が可能となる。
【０２２０】
例えば、パッシブ型ＲＦＩＤタグを貼付した商品を出荷する際、原材料の情報や製造時に行った加工情報のような履歴情報を、該ＲＦＩＤタグの識別子（tagID）と共にセンサネットサーバＳＮＳのデータベースＤＢにおいて管理する。それに加えて、センサノードから送信されてくる温度、湿度、振動等の情報をセンサネットサーバＳＮＳのデータベースＤＢに逐一反映されることによって、運搬時や保管時にどのような環境に置かれたかという履歴情報が自動的に蓄積される。
【０２２１】
＜ソフトウェアアダプタを用いたＲＦＩＤシステムとの接続＞
典型的なＲＦＩＤシステムは、ＲＦＩＤタグ、ＲＦＩＤリーダ、ＲＦＩＤコントローラによるシステム構成を取る。
【０２２２】
システムとしての観点では、前記第１実施形態で示したような無線センサネットＷＬＮのシステムとＲＦＩＤのシステムとは構成に類似点が多い。しかしながら、個々の要素技術や実装技術の観点ではこれらのシステムを連携もしくは統合をすることは容易なことではない。無線通信方式に関しては、センサネットではZigBee及びIEEE802.15.4という無線規格が最も有力な方式とされている。一方ＲＦＩＤで広く使われている無線規格はＮＦＣ（Near Field Communication）である。これはZigBeeやIEEE802.15.4とは全く異なるものであり、お互いに通信することは出来ない。また、ＲＦＩＤリーダやＲＦＩＤコントローラは、システムの中での役割としてはセンサネットシステムの基地局ＢＳＴと同等と見ることができるが、専用のハードウェア及びソフトウェアとして提供される場合が多い。
【０２２３】
このため、センサネットシステムと接続しようとしても、特定規格のパケットフォーマットしか送受信できず、また追加でユーザプログラムをインストールすることができない場合が多い。そのため、ＲＦＩＤリーダやＲＦＩＤコントローラに、図２に示したようなセンサネットシステムの基地局ＢＳＴのとしての機能を持たせることは期待できない。
【０２２４】
そこで、図２８は、前記第１実施形態の図２に示した基地局ＢＳＴの変換エンジンＣＶＥＮの機能を提供するソフトウェアアダプタをプロファイルドアダプタＰＦＡＤとして用意し、センサネットサーバＳＮＳ内に組み込む。これにより、ＲＦＩＤシステムとセンサネットシステムを最小限の手間で接続することができる。
【０２２５】
プロファイルドアダプタＰＦＡＤは、前記第１実施形態の変換エンジンＣＶＥＮと同様に構成されて、ＲＦＩＤシステム用のプロファイルＰＦＲＦを設定することによって、ＲＦＩＤコントローラが送受信する特定規格のパケットフォーマットをセンサネットサーバＳＮＳ側で直接エンコード及びデコードできるようになる。つまり、プロファイルドアダプタＰＦＡＤが、ＲＦＩＤシステム用インターフェースＲＦＩＦからのデータを、プロファイルＰＦＲＦに基づいて、テキスト形式のセンシングデータに変換し、イベント発行部ＥＶＰに送信する。これにより、ＲＦＩＤコントローラの検出値をセンサＳＳの出力値と同等に扱うことができる。また、変換部ＤＣＶでは、ＲＦＩＤコントローラのＩＤ等の識別子に基づいて、所定のプラグインを選択して有意な情報に変換すればよい。
【０２２６】
通常、ＲＦＩＤコントローラはEthernet（登録商標）インタフェースを有するので、ＲＦＩＤシステム用インタフェースは、典型的にはＲＦＩＤコントローラの対向となるＴＣＰ／ＩＰソケットインタフェースである。なお、ＲＦＩＤリーダとＲＦＩＤコントローラとの間でＴＣＰ／ＩＰ通信を行う規格であった場合には、ＲＦＩＤコントローラを使用せずに、ＲＦＩＤリーダとセンサネットサーバが直接通信する構成も考えられる。この場合には、プロファイルドアダプタＰＦＡＤがＲＦＩＤコントローラの役割をも模倣することとなる。
【０２２７】
また、ＲＦＩＤコントローラが、上位システムとの間の通信にバイナリフォーマットではなく、テキストフォーマットを使用する場合も考えられる。本発明全体としては、バイナリフォーマットをテキストフォーマットにデコードする課題を前提として説明してきたが、本発明のセンサネットサーバの特定の実施形態が、他の規格で定義されたテキストフォーマットを扱うために、テキストフォーマット間の相互変換を実施するためのプロファイルを定義してもよい。プロファイルの記述や実現するための仕組みに若干の変更を加えることにより、本発明がそのような用途にも適用可能であることは明らかであろう。
【０２２８】
無線センサノードＳＮ１〜ＳＮｎへの搭載に適した小型低電力センサデバイスとしては、温度センサ、湿度センサ、加速度センサ、衝撃センサ、半導体ひずみセンサ、音波センサ（マイク）、光センサ、磁気センサ等が実用化されている。
【０２２９】
一方、測定原理等の関係により、小型化あるいは低電力化が困難なセンサデバイスも存在する。例えば、粉塵計測やガス計測の場合、具体的な測定対象や測定精度により多少の違いはあるが、外形が数ミリ角、消費電力が数ミリワットといったオーダのセンサデバイスを実現するのは困難であると考えられる。また、画像や動画をセンシングする場合も、センサデバイスそのものは小型化、低電力化できたとしても、測定データのサイズが大きくなり、データの処理あるいは通信に相当のリソース負荷が必要となることから、マイコンやメモリのリソース制約の大きい小型低電力センサノードに搭載するのには適さない。
【０２３０】
このようなセンサデバイスを用いる場合には、小型低電力の無線ノードに搭載するのではなく、ＡＣ給電のボックス型計測装置として提供するのが好ましいであろう。ボックス型計測装置の場合、通信インタフェースはもちろん無線であっても良いが、１０／１００ＢＡＳＥ−Ｔ Ethernet（登録商標）や、ＦＡ（ファクトリ・オートメーション）系の標準規格等のように、有線通信インタフェースを使用する場合もあるであろう。このような場合、前記第１実施形態のような基地局ＢＳＴに相当する機器がなく、有線通信インタフェースを有するセンサノードが直接センサネットサーバと通信を行う形態としてもよい。そのような場合にも、本第５実施形態のようにプロファイル機能をセンサネットサーバＳＮＳ内のソフトウェアアダプタとして実装する方法が有効である。
【産業上の利用可能性】
【０２３１】
以上のように、本発明はセンサノードと基地局の間で無線通信を行い、基地局とサーバの間で有線通信を行うセンサネットシステムに適用することができる。
【図面の簡単な説明】
【０２３２】
【図１】本発明の第１の実施形態を示すセンサネットシステムのブロック図。
【図２】同じく、基地局の機能ブロック図。
【図３】同じく、センサネットサーバの機能ブロック図。
【図４】同じく、基地局で行われる上り方向のフォーマット変換を示し、無線ネットワークのバイナリ形式のセンシングデータからプロファイルを適用してテキスト形式のセンシングデータに変換するデータフォーマットの一例を示す説明図。
【図５】同じく、基地局のプロファイル関連付けテーブルの一例を示す説明図。
【図６】同じく、基地局で行われる下り方向のフォーマット変換を示し、テキスト形式のセンシングデータからバイナリ形式のセンシングデータに変換するデータフォーマットの一例を示す説明図。
【図７】同じく、基地局の下り方向のフォーマット変換で用いるプロファイルの一例を示す説明図。
【図８】同じく、基地局の下り方向のフォーマット変換で用いるプロファイルの一例を示す説明図。
【図９】同じく、基地局の上り方向のフォーマット変換で用いるプロファイルの他の一例を示す説明図。
【図１０】同じく、基地局の上り方向のフォーマット変換で用いるプロファイルの他の一例を示す説明図。
【図１１】同じく、基地局の上り方向のフォーマット変換で用いるプロファイルの他の一例を示す説明図。
【図１２】同じく、プロファイルで定義するデータタイプの説明図。
【図１３】同じく、センサノードと基地局及びセンサネットサーバで行われる通信のタイムチャート。
【図１４】同じく、接続通知パケットのペイロードのデータフォーマットを示す説明図。
【図１５】同じく、接続通知パケットのペイロードのデータフィールドの内容を示す説明図。
【図１６】同じく、プロファイルの選択区分に対応したセンシングデータのデータフォーマットを示す説明図。
【図１７】同じく、基地局で行われる処理の一例を示す説明図。
【図１８】同じく、センサノードと基地局及びセンサネットサーバで行われるプロファイルの設定と配布のタイムチャート。
【図１９】変形例１を示し、センサネットサーバのプラグインの詳細を示す説明図。
【図２０】第２の実施形態を示し、みなし通信を行う場合のセンサノードとセンサネットサーバのデータと時刻の関係を示すグラフ。
【図２１】同じく、第２の実施形態を示し、センサノードの機能要素を示すブロック図。
【図２２】同じく、第２の実施形態を示し、センサノードの制御部で実行される処理の一例を示すフローチャート。
【図２３】同じく、第２の実施形態を示し、センサノードが送信する無線通信区間のパケットのペイロードを示すデータフォーマット。
【図２４】同じく、第２の実施形態を示し、基地局で行われるフォーマット変換処理の説明図。
【図２５】同じく、第２の実施形態を示し、センサネットサーバの機能要素の要部を示すブロック図。
【図２６】第３の実施形態を示すセンサネットシステムのブロック図。
【図２７】第４の実施形態を示すセンサネットシステムのブロック図。
【図２８】第５の実施形態を示すセンサネットシステムのブロック図。
【符号の説明】
【０２３３】
ＳＮ１〜ＳＮｎ  センサノード
ＢＳＴ  基地局
ＳＮＳ  センサネットサーバ
ＷＤＮ  有線ネットワーク
ＷＬＮ  無線ネットワーク
ＮＭＧ  センサネット管理部
ＰＭＧ  プロファイル管理部
ＥＶＰ  イベント発行部
ＰＳＲ  パーサ
ＰＳＴ  プロファイル格納部
ＣＶＥＮ  変換エンジン
ＢＮＲ  バイナリ参照制御部
ＢＮＣＶ  バイナリ変換制御部
ＴＸＣＶ  テキスト変換制御部
ＴＸＲ  テキスト参照制御部
【図１】
0004719034.tif 000004
【図２】
0004719034.tif 000005
【図３】
0004719034.tif 000006
【図４】
0004719034.tif 000007
【図５】
0004719034.tif 000008
【図６】
0004719034.tif 000009
【図７】
0004719034.tif 000010
【図８】
0004719034.tif 000011
【図９】
0004719034.tif 000012
【図１０】
0004719034.tif 000013
【図１１】
0004719034.tif 000014
【図１２】
0004719034.tif 000015
【図１３】
0004719034.tif 000016
【図１４】
0004719034.tif 000017
【図１５】
0004719034.tif 000018
【図１６】
0004719034.tif 000019
【図１７】
0004719034.tif 000020
【図１８】
0004719034.tif 000021
【図１９】
0004719034.tif 000022
【図２０】
0004719034.tif 000023
【図２１】
0004719034.tif 000024
【図２２】
0004719034.tif 000025
【図２３】
0004719034.tif 000026
【図２４】
0004719034.tif 000027
【図２５】
0004719034.tif 000028
【図２６】
0004719034.tif 000029
【図２７】
0004719034.tif 000030
【図２８】
0004719034.tif 000031