JP2009005136A - センサネットシステム - Google Patents

Abstract

【課題】センサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で要求する加工値で取得できるセンサネットの共用システムを提供する。
【解決手段】センサネットの共用システム１０は、複数のセンサノードを有するセンサネットに接続され前記センサネットの制御を行い、複数のセンサノード１１からの観測値を複数のユーザにより共用して観測値を配送先のユーザ４０に配送する管理サーバ３０を備える。管理サーバ３０は、センサノード１１の観測値の種類と観測値の配送先ごとにタイマを備え、管理サーバ３０は、センサノード１１からの観測値Ｍの受信時には観測値Ｍを保持し、タイマが切れたときに、保持していた観測値Ｍを配送先へ配送する。
【選択図】図１

Description

本発明は、センサネットシステムに関し、特にセンサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で取得でき、好ましくはさらに要求する加工値で取得できるセンサネットを共用するシステムに関する。

１つの目的のために、１つのセンサネットを利用することが前提となっている。例えば、ある空間の温湿度を観測するといった場合である。このような観測をする場合には、下記のような状況が発生しうる。
（１）目的数が増えると、新たにセンサネットを設置する必要がある。
（２）同じ目的であっても、ユーザが要求する精度により、別のセンサネットが必要となる。
（３）同じ目的であっても、ユーザが異なると、別のセンサネットが必要となる。

センサネットが複数設置されるようになると、場所の制限、設置／維持費用、輻輳などの問題が発生する。これらの問題を回避する手段として、ノードに複数のセンサを搭載してマルチ機能化して、１つのセンサネットを複数のユーザが共有して利用する方法が考えられる（例えば、特許文献１参照）。
特開平８―１４００８１号公報

ところが、１つのセンサネットを複数のユーザが共有して利用した場合には、以下の課題が発生する。
（１）センサノードは送信間隔を１つしか保持できないため、異なる送信間隔の要求に対応できない。たとえば、送信間隔をそれぞれユーザＡが５分ごと、ユーザＢが毎分とした場合に、ユーザＡに毎分データを送信したとすると、ユーザＡにとってはストレージ容量や通信費が問題になることが考えられる。このため、ユーザごとに異なる送信間隔が要求されるが、これに答えることができない。
（２）費用負担を明確にする必要がある。

（３）通信の優先順位をどうするか。ノードへのアクセス制御をどうするか。使用制限や、送信間隔の最小値をさらに小さくできるかどうか等の問題がある。
（４）センサネットの管理責任者は誰か。
（５）異常時はユーザへ通知するかどうか。
（６）欲しいデータのみを欲しいときに受信できるようにする。複数センサが搭載されたノード利用時は、ユーザにとっては必ずしもすべての観測値を必要としない。

そこで、本発明は、上記課題を解消するために、センサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で取得でき、好ましくはさらに要求する加工値で取得できるセンサネットシステムを提供することを目的とする。

本発明は、２以上のセンサノードを有するセンサネットと、該センサネットを接続し、該センサネットの制御を行い、前記センサノードからの観測値を受信し複数のユーザに配送する管理サーバとを備えるセンサネットシステムにおいて、前記管理サーバは、前記センサノードが送信する観測値の種類データと送信間隔データ、及び前記ユーザごとに配送する観測値の種類データと配送間隔データとを有しており、前記センサノードは、前記管理サーバが有する配送間隔データのうちの最小の配送間隔又はそれ以下の時間間隔で前記観測値を送信し、前記管理サーバは、前記センサノードから受信した観測値をそれぞれ更新して記憶し、前記配送する観測値の種類データと配送間隔データを基にユーザに配送する際に、配送時に記憶する観測値を該ユーザに配送するセンサネットシステムである。

また、本発明は、前記管理サーバが、ユーザへの配送間隔をそれぞれ管理するタイマを有し、各タイマには前記観測値の加工方法の情報を関連付けており、関連付けられた加工方法で前記観測値を加工し、前記観測値の加工値をユーザへ配送するセンサネットシステムである。

そして、本発明は、前記管理サーバが、ユーザから観測値の配送要求を受信したとき、前記ユーザの要求する前記観測値の配送間隔と前記センサノードの前記観測値の送信間隔を比較し、前記配送間隔が前記送信間隔よりも短い時間間隔である場合に、前記配送間隔を、前記センサノードの送信間隔として設定するセンサネットシステムである。

更に、本発明は、前記管理サーバが、センサネットの管理者の指示を受けて、前記観測値の配送先の優先順位や前記センサノードへのアクセス制御を管理するセンサネットシステムである。

また、本発明は、前記管理サーバが、前記観測値の配送量、前記観測値の加工方法、前記配送先の優先順位による重み付けを利用して前記センサネットの利用料金を計算し、前記ユーザへ課金請求するセンサネットシステムである。

本発明によれば、センサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で取得でき、好ましくはさらに要求する加工値で取得できる。

本発明を実施するための最良の形態を説明する。
本発明のセンサネットシステムの実施例について、図面を用いて説明する。

実施例を説明する。図１は、本発明のセンサネットシステムの好ましい実施例を示すシステム構成図である。図１に示すように、本実施例のセンサネットシステム１０は、センサネットワーク２０と、センサネット管理サーバ３０と、複数のユーザ端末４０から構成されている。破線で示しているセンサネットワーク２０は、複数のセンサノード１１，ルータ１２，ＧＷ（ゲートウェイ）１３により構成されている。

センサノード１１は、温湿度、加速度等のセンサ、マイクロコンピュータ、無線通信機能を備えた小型のハードウェアであり、センサノード１１はバッテリにより駆動される。
ルータ１２は、センサノード１１とＧＷ１３が直接通信できない場合に、通信を中継するための中継装置である。ルータ１２は、ルーティング機能など負荷の要する処理を行うため、ＡＣ電源で稼動する。
ＧＷ１３は，無線区間通信と有線区間通信を仲介するための装置である。ＧＷ１３もルータ１２同様に、ＡＣ電源で稼働する。

センサネット管理サーバ３０は、ＧＷ１３経由でセンサノード１１から送られる観測値Ｍを、必要に応じて加工してユーザ端末４０へ配送したり、ユーザ端末４０からの要求に応じて、ＧＷ１３経由でセンサノード１１を制御したりするためのサーバである。

ユーザ端末４０を利用するユーザＡ，Ｂ，Ｃは、センサネットワーク２０を利用するユーザである。ユーザとしては、同一企業内の複数部署の場合もあれば、複数企業のユーザが同一のセンサネットワーク２０を利用する場合もありうる。

図２は、図１のセンサネット管理サーバ３０のモジュール構成を示す図である。センサネット管理サーバ３０は、ノード通信用アダプタ３１、ユーザ管理モジュール３２、データ管理モジュール３３、コマンド発行モジュール３４、イベント発行モジュール３５、ユーザアプリ通信用アダプタ３６を有している。

ノード通信用アダプタ３１は、ＧＷ１３から送られてきた観測値Ｍを、アプリケーションが理解しやすいイベントに変換してイベント発行モジュール３５へ送信する。イベント発行モジュール３５は、観測値Ｍの情報に加え、観測値Ｍが観測された時刻や観測したセンサノード１１の情報等を含めることができ、たとえば、ＸＭＬ形式で表現することができる。

また、ノード通信用アダプタ３１は、コマンド発行モジュール３４から送られてきたセンサネット制御用の命令Ｒを、図１のＧＷ１３が理解できるバイナリ形式に変換してＧＷ１３へ送信する。

イベント発行モジュール３５は、ノード通信用アダプタ３１から送信された観測値Ｍを、ユーザ管理モジュール３２、コマンド発行モジュール３４等へ、イベントとして発行する。他のモジュール、すなわちデータ管理モジュール３３は、イベント配送予約をイベント発行モジュール３５に対して行うことで、任意のイベントを受信することができる。

コマンド発行モジュール３４は、様々なコマンドを発行・管理するモジュールである。この様々なコマンドには、たとえば、データ管理モジュール３３が管理するデータを操作するためのコマンド群やセンサネットワーク２０を制御するためのコマンド群がある。

データ管理モジュール３３は、図１のセンサノード１１が観測した観測値Ｍ等を管理するためのモジュールであり、コマンド発行モジュール３４やユーザ管理モジュール３２から必要に応じて利用される。また、データ管理モジュール３３が管理するデータの更新時等は、データ更新を知らせるためのイベントを発行することもできる。

ユーザアプリ通信用アダプタ３６は、ユーザ端末４０のアプリケーションと上記センサネット管理サーバ３０の各モジュールとを仲介するための機能を提供する。

ユーザ管理モジュール３２は、ユーザごとのデータ配送管理を行う機能を提供する。ユーザ管理モジュール３２の詳細な動作を、以下の例にて詳しく説明する。

図３は、ユーザがデータ配送要求した時のタイマ起動をするためのフローチャートであり、ステップＳ１〜Ｓ７を有する。ステップＳ１では、ユーザ（新規、既存問わず）が、センサネット管理サーバ３０にデータ配送要求を出した時に、データ配送要求は、ユーザ管理モジュール３２が受信する。データ管理モジュール３３内には、図１０に示す内容が格納されている。図１０は、データ管理モジュール３３が管理するユーザデータ、例えばユーザＡ〜Ｄに関するデータである。

ステップＳ２では、ユーザ管理モジュール３３がデータ配送要求を受信後、データ管理モジュール３３内の図１０を検索し、ステップＳ３では、該当ユーザから該当データの配送要求がすでに行われているかどうかを、テーブル（図１０）のエントリの有無により調べる。エントリが存在している時には、すでにデータの配送が行われているため、何も処理をせずに終了する。
ステップＳ３において、エントリが存在していないときは、ステップＳ４では該当データ配送のため（配送先ユーザ、配送データ、頻度、加工方法）の情報を関連付けたタイマを生成する。

ステップＳ５では、ユーザ管理モジュール３３は、タイマの起動前に、上記関連付けた内容でイベント配送予約をイベント発行モジュール３５に対して行う。ステップＳ６においてタイマを起動後に、ステップＳ７では、本タイマに関する情報をテーブル（図１０）に本配送要求に関するエントリを追加する。

以上説明した例は、ユーザへのデータ配送を継続して行う場合の説明であったが、ユーザによっては、１回のみのデータ配送を要求する場合も考えられる。この場合、一例として、ユーザがデータ配送要求を行うときに、オプションとして配送回数「１」を指定する方法がある。ユーザ管理モジュール３２では、配送要求に該当オプションが指定されていたときはエントリの検索を行わず、センサネット管理サーバ３０のデータ管理モジュール３３にて保持している最新の観測値をユーザへ配送する。こうすることで、ユーザからの１度のみのデータ配送要求に応えることができる。

次に、図４は、センサノード１１が送信した観測値Ｍを受信した時のフローチャートである。図４は、ステップＳ１０〜Ｓ１３を有している。センサノード１１が送信した観測値Ｍを、ユーザ管理モジュール３２が受信し、配送予約したタイマにデータ配送したあとのタイマの処理フローである。

ステップＳ１０ではタイマに関連付けられたエントリからデータ加工方法を取得する。ステップＳ１１では、観測値Ｍを受信したタイマでは、タイマ自身に関連付けられたデータ加工方法が指定されているどうかを確認する。ステップＳ１１において加工方法が指定されていれば、ステップＳ１２において、その加工方法の内容にしたがって観測値Ｍを加工する。たとえば加工方法として平均値が指定されていたときは、受信値と保持していた値から平均値を求めることができる。
データ加工後は、ステップＳ１３において、加工した観測値Ｍを最新値として保持する。一方、ステップＳ１１において加工方法が何も指定されていない場合は、ステップＳ１３において受信した観測値Ｍを最新値として上書き保存する。

図５は、タイマ期限切れ時のデータ配送方法を示すフローチャートである。図５は、ステップＳ２０〜Ｓ２３を有している。タイマの期限が切れた時に、タイマは図２のイベント発行モジュール３５に対してイベント配送予約を行っているので、ステップＳ２０ではタイマが切れる前にイベントを受信した際は、イベントに含まれる観測値をタイマが持つ観測値を取得して保持する。

タイマが切れたということは、ステップＳ２１ではユーザがデータ配送を要求した間隔が経過したことを示すため、ユーザへの観測値（データ）の配送を行う。このようにしてタイマが切れる毎に観測値（データ）の配送を行うことで、ユーザが要求する間隔でのデータ配送を実現する。
その後、ステップＳ２２では、次の配送タイミングに備えるためにタイマをリセットする。最後に、ステップＳ２３では、配送データに関する総配送量をインクリメントする。この情報を保持しておくことで、たとえばデータ配送量に応じた課金に利用することが可能になる。

図６は、ユーザへのデータ配送タイミングのシーケンス図である。図６は、センサノード１１，ユーザ管理モジュール３２，そしてユーザアプリ通信用アダプタ３６の間におけるデータ配送タイミングを示している。

タイマ期限切れに応じてユーザへデータ配送を行うとき、センサノード１１のデータ送信間隔とユーザが要求した配送頻度のタイミングによっては、ユーザ管理モジュール３２は、同じ値を再度、ユーザへ配送してしまうおそれがある。
具体的には、例えば、センサノード１１が１０分間隔でデータ送信を行っているときに、ユーザが５分に１回の配送要求を行ったとする。このとき、センサノード１１の送信タイミングによっては、ユーザへの２度目の配送データも１度目と同じデータが配送されてしまう場合がある。

そこで、ユーザへはできるだけ最新の観測値Ｍを配送できるようにする必要があり、これを図７に示すフローにより実現する。図７は、ユーザが配送要求した時のノードの送信間隔変更を示すフローチャートである。ステップＳ３０にて、ユーザから観測値の配送要求を受信した場合には、ユーザからの配送要求を受信してタイマを起動する前に、ある処理を追加する。

ステップＳ３１にて、センサノード１１の送信間隔を取得し、ステップＳ３２では受信したユーザの配送要求の送信頻度と比較して、センサノード１１側かユーザ要求側のどちらが短いかを比較する。その比較の結果、ユーザの配送頻度の方が短時間の時には、ステップＳ３３ではセンサノードの送信間隔を変更する。
上記の例で言えば、センサノード１１の送信間隔を長くても５分に変更する。無線区間での輻輳や再送、電波受信後の処理等を考えると、５分ではユーザへの配送に間に合わないと考えられる場合は、送信間隔を５分より短くしてたとえば４分５０秒程度の送信間隔にしてもよい。

このように、センサノード１１の送信間隔は、すべてのユーザからの配送要求の中で最小の値を設定し、ユーザ管理モジュール３２で配送のフィルタリングを行うことで、複数ユーザからの異なる送信頻度の配送要求に応えることができるとともに、各ユーザへは最新のデータを配送することができる。

また、比較の結果、センサノード１１の配送頻度の方が、ユーザの配送頻度の方に比べて短時間の時には、ステップＳ３４において、ユーザの配送要求に合わせてタイマを生成して起動する。

より短い時間間隔の配送要求が行われる一方で、長い時間間隔の配送要求が行われる場合もありうる。たとえば、上記図１０において、ユーザＡが加速度の配送頻度を１０分から１時間へ変更したとする。この場合、図７のフローによれば、センサノード１１の送信間隔は短くならないため、各ユーザへは短くても１時間ごとに配送するが、センサノード１１は１０分ごとのデータ送信を続けるため、センサノード１１のバッテリを無駄に消費してしまう。

そこで、このバッテリの無駄な消費状況を回避するために、図８に示すように、各ユーザからの配送要求の中で最小頻度の間隔にセンサノード１１の送信間隔をあわせる処理を追加する。

図８は、センサノード１１の送信間隔をチェックするためのフローチャートである。図８は、ステップＳ４０〜Ｓ４３を有している。
ステップＳ４０では、ユーザデータから最小頻度（１）を取得する。ステップＳ４１では、センサノード１１の送信間隔（２）を取得する。ステップＳ４２では、最小頻度（１）が送信間隔（２）に対して大きいかどうかを判断して、最小頻度（１）が送信間隔（２）と同じか小さい場合には処理を終了する。そうでなく、最小頻度（１）が送信間隔（２）に対して大きい場合には、ステップＳ４３においてセンサノード１１の送信間隔を最小頻度（１）に変更して処理を終了する。

このように、図８に示す処理を、たとえば定期的に行うようにすれば、センサノード１１の送信間隔をユーザの要求に合わせることができ、バッテリの無駄な消費を抑えることができる。
図７のような制御を行うことで、どのユーザでも任意のタイミングでデータを受信することができるようになる。

一方で、センサノード１１を制御できることによる問題点もある。それは、センサノード１１の送信間隔が短くなればなるほど、バッテリの消耗が早くなるということである。小型化、無線化、バッテリ駆動を前提とするセンサノード１１は、センサネットワーク２０内に大量に設置しやすいために、設置されるセンサノード１１の数が増えるほど、各バッテリの交換に要するコストが大きくなる。

図９は、アクセス権限のチェック時のフローチャートである。図９は、ステップＳ５０〜Ｓ５６を有している。本例では、バッテリ交換に要するコストを削減して、センサネットワーク２０への制御を制限するために、共用するセンサネットワーク２０のオーナーという概念を導入する。

この概念では、このオーナーが他のユーザのセンサネットワーク２０への権限を設定する。たとえば、図１１に示すような権限を設定したとする。この場合、ユーザＡ（種別はオーナー）は、センサネットワーク２０の管理（参照と制御を含む）ができる。ユーザＢ、Ｃ（種別は利用者）は、センサネットワーク２０の参照と制御も行うことができるが、ユーザＤ（種別は利用者）は、参照しかできない。

この概念を、図９に示すフローチャートを使って説明する。図９のステップＳ５０ではユーザがデータ配送を要求する。ステップＳ５１ではセンサノード１１の送信間隔を変更するかどうかを判断して、送信間隔を変更しない場合には、ステップＳ５５において該当ユーザ用のタイマを生成して起動する。

そうでなく、センサノード１１の送信間隔を変更する場合には、ステップＳ５２では該当ユーザのセンサネットワークの利用権限を取得する。該当ユーザが利用権限を有する場合にはステップＳ５４においてセンサネットワーク２０の送信間隔を変更し、ステップＳ５６において該当ユーザ用のタイマを生成して起動する。
ステップＳ５３において該当ユーザが利用権限を有しない場合には、ステップＳ５５において権限エラーを発行し、ステップＳ５６において該当ユーザ用のタイマを生成して起動する。

より判りやすくするために、さらに図９を参照して一例を説明する。ステップＳ５０では、図１１のユーザＤが、１分間隔のデータ配送要求を行ったとする。この時、センサノード１１の送信間隔が５分であったとすれば、ステップＳ５１ではセンサノード１１の送信間隔を変更する必要がある。ここで、ステップＳ５２において該当ユーザＤのセンサネットワーク２０の利用権限を取得すると、図１１のユーザＤはセンサネットワーク２０の参照権限しか持っていないため、送信間隔を変更することができない。

そのため、ステップＳ５６にてユーザＤへは５分間は同じデータが配送され続ける。このような場合は、ユーザがオプションを指定して配送要求することにより、同じデータが配送され続けてもよいのか、あるいは配送間隔をセンサノード１１の送信間隔（この場合は５分に）に合わせて変更させるかを選択できるようにさせてもよい。
もし、図１１のユーザＤが５分間隔ではなく１０分間隔で配送要求したとすると、この時はセンサノード１１の送信間隔を変更する必要がないため、ユーザＤへは１０分間隔で観測値が配送される。

ここで、優先順位づけされたデータ配送の例を説明する。センサネットワーク２０のオーナーは、図１１に示すように、各ユーザＡ〜Ｄに対して優先順位をつけることもできる。こうすることで、たとえばユーザＢとユーザＤが同じデータを同じ頻度で要求した場合に、それぞれのユーザ用に起動されたタイマが同時に切れたときに、図２のユーザ管理モジュール３２はユーザＢへ先にデータ配送を行う。

次に、センサネットワーク２０の利用に対する課金の例について説明する。図１に示すようにセンサネットワーク２０を複数ユーザで共用利用したときの課金方法について述べる。
たとえば、図１０に示すように、ユーザへ観測値を配送した総配回数を記憶しておき、その配送量に応じた従量制の課金を行う方法が考えられる。

また、図１１に示す優先順位（ユーザＡの優先順位は１位，ユーザＢの優先順位は２位，ユーザＣの優先順位は２位，ユーザＤの優先順位は３位）を課金の基データとして使用することもできる。高いリアルタイム性を要求するユーザは優先順位を高くし、優先順位に応じた重み付けを行い課金する。リアルタイム性をそれほど要求しないユーザについては、優先順位を低く設定するとともに重み付けを小さくすることで、低料金でセンサネットワーク２０を利用することができる。

重み付けに関しては、観測値の加工方法によって行うこともできる。たとえば、平均値のような単純な加工は重み付けを小さく設定し、フーリエ変換等の複雑な計算を要する加工は重み付けを大きく設定することができる。こうすることで、ユーザの様々なニーズに応じた課金体系を実現することができる。

本発明によれば、次のようにしてセンサネットワークの共用化を図っている。
（１）センサネットの制御を行う管理サーバにおいて、各ユーザのユーザ管理を行う。
（Ａ）ユーザごとに、データ配送間隔でタイマを起動する。
（Ａ−１）タイマは、欲しいデータの種類分だけ用意する。
（Ａ−２）観測値受信時、値を保持する。
（Ａ−３）タイマ期限切れ時、保持していた観測値を配送する。
（Ｂ）ユーザごとにデータ配送量を管理し、課金の元データとして利用する。
（２）センサノードには、各ユーザからの要求のうち、最小の送信間隔を設定する。
（３）センサネットの所有者を決めておき、データ配送先の優先順位やノードへのアクセス制御を管理できるようにする。
（４）センサネットに異常が発生したとき、どのユーザにどのような情報を通知するかを設定できるようにする。

ユーザ毎にユーザが要求するタイミングで情報（観測値）を受信することができ、この情報としては加工した情報を受信することもできる。従って、センサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で、かつ要求する加工値で取得できる。また、１つのセンサネットワークで、複数ユーザの異なる配送要求に応えることができる。

本発明のセンサネットシステム１０は、複数のセンサノードを有するセンサネットに接続され前記センサネットの制御を行い、複数のセンサノード１１からの観測値を複数のユーザにより共用して観測値を配送先のユーザ４０に配送する管理サーバ３０を備える。管理サーバ３０は、センサノード１１の観測値の種類と観測値の配送先ごとにタイマを備え、管理サーバ３０のユーザ管理モジュール３２は、センサノード１１からの観測値Ｍの受信時には観測値Ｍを保持し、タイマが切れたときに、保持していた観測値Ｍを配送先へ配送する。これにより、センサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で取得できる。また、１つのセンサネットワークで、複数ユーザの異なる配送要求に応えることができる。

本発明のセンサネットシステム１０では、各タイマには観測値Ｍの加工方法の情報を関連付けられており、関連付けられた加工方法で観測値を加工して、観測値の加工値を配送先へ配送する。これにより、センサノードが観測値を送る実際のタイミングを意識することなく、ユーザは観測値を要求する間隔で要求する加工値で取得できる。

本発明のセンサネットシステム１０では、ユーザからの観測値Ｍの配送要求を受信したときは、ユーザの要求する観測値Ｍの配送間隔とセンサノード１１の観測値Ｍの送信間隔を比較して、配送間隔と送信間隔の内の短い時間の間隔が、センサノード１１の送信間隔として設定される。これにより、管理サーバ３０は、各ユーザからの配送要求が互いに違っても、最小の送信間隔を設定することで、各ユーザは要求するタイミングで必ず観測値Ｍを受信できる。しかも、センサノード１１がバッテリ駆動される際に、バッテリの無駄な消費を抑えることができる。

本発明のセンサネットシステム１０では、センサネット２０の管理者を決定して、管理者が、観測値の配送先の優先順位やセンサノード１１へのアクセス制御を管理する。これにより、ユーザの様々なニーズに応じて、センサネットへの制御を制限できる。

本発明のセンサネットシステム１０では、観測値の配送量、観測値の加工方法、配送先の優先順位による重み付けを利用してセンサネット２０の利用料金を計算して、ユーザへ課金する。これにより、ユーザの様々なニーズに応じた課金体系が実現できる。

ところで、本発明は、上記実施例に限定されず、種々の変更が可能である。例えば、図１では、センサネットワーク２０は、２つのセンサノード１１と１つのルータ１２が例示されているが、これに限らず３つ以上のセンサノード１１と２つ以上のルータ１２を備えていても良い。

実施例のセンサネットシステムのシステム構成の説明図。 実施例におけるセンサネットの管理サーバのモジュール構成の説明図。 実施例におけるユーザがデータ配送要求した時のタイマ起動をするためのフローチャートの説明図。 実施例における観測値を受信した時のフローチャートの説明図。 実施例におけるタイマ期限切れ時のデータ配送方法を示すフローチャートの説明図。 実施例におけるユーザへのデータ配送タイミングのシーケンスの説明図。 実施例におけるユーザが配送要求した時のノードの送信間隔変更を示すフローチャートの説明図。 実施例におけるセンサノードの送信間隔をチェックするためのフローチャートの説明図。 実施例にけるアクセス権限のチェック時のフローチャートの説明図。 実施例におけるデータ管理モジュールが管理するユーザデータの一例を示す図表。 実施例におけるセンサネット利用者の定義の一例を示す図表。

符号の説明

１０ センサネットシステム
１１ センサノード
１２ ルータ
２０ センサネットワーク
３０ センサネット管理サーバ
３１ ノード通信用アダプタ
３２ ユーザ管理モジュール
３３ データ管理モジュール
３４ コマンド発行モジュール
３５ イベント発行モジュール
３６ ユーザアプリ通信用アダプタ
４０ ユーザ端末
Ｍ 観測値
Ｒ センサネット制御用命令

Claims (5)

1. ２以上のセンサノードを有するセンサネットと、該センサネットを接続し、該センサネットの制御を行い、前記センサノードからの観測値を受信し複数のユーザに配送する管理サーバとを備えるセンサネットシステムにおいて、
   前記管理サーバは、前記センサノードが送信する観測値の種類データと送信間隔データ、及び前記ユーザごとに配送する観測値の種類データと配送間隔データとを有しており、
   前記センサノードは、前記管理サーバが有する配送間隔データのうちの最小の配送間隔又はそれ以下の時間間隔で前記観測値を送信し、前記管理サーバは、前記センサノードから受信した観測値をそれぞれ更新して記憶し、前記配送する観測値の種類データと配送間隔データを基にユーザに配送する際に、配送時に記憶する観測値を該ユーザに配送することを特徴とするセンサネットシステム。
2. 前記管理サーバは、ユーザへの配送間隔をそれぞれ管理するタイマを有し、各タイマには前記観測値の加工方法の情報を関連付けており、関連付けられた加工方法で前記観測値を加工し、前記観測値の加工値をユーザへ配送する請求項１に記載のセンサネットシステム。
3. 前記管理サーバは、ユーザから観測値の配送要求を受信したとき、前記ユーザの要求する前記観測値の配送間隔と前記センサノードの前記観測値の送信間隔を比較し、前記配送間隔が前記送信間隔よりも短い時間間隔である場合に、前記配送間隔を、前記センサノードの送信間隔として設定する請求項１または２に記載のセンサネットシステム。
4. 前記管理サーバは、センサネットの管理者の指示を受けて、前記観測値の配送先の優先順位や前記センサノードへのアクセス制御を管理する請求項３に記載のセンサネットシステム。
5. 前記管理サーバは、前記観測値の配送量、前記観測値の加工方法、前記配送先の優先順位による重み付けを利用して前記センサネットの利用料金を計算し、前記ユーザへ課金請求する請求項４に記載のセンサネットシステム。

Images