(57)【要約】【課題】  センサノードの限られたリソースを節約して有効に利用しながらも、間欠動作を前提とするセンサノードの障害監視を効率的にかつ信頼性高く実現することを目的とする。【解決手段】  センサノードの障害判定処理の実行タイミングを，予め設定された規則に従って，前記センサノードで想定されている間欠動作間隔に基づいて決定する。すなわち，センサノードの間欠動作間隔の変更要求があっ場合，センサノードでの動作間隔変更の操作完了を確認した直後に，システムの監視部は障害判定処理の実行タイミングをその動作間隔の変更に追従するように変更する。また，センサノードの固体あるいは種類毎に要求される間欠動作間隔が異なる場合，センサノードの個体毎あるいは種類毎に障害判定処理の実行タイミングを使い分ける。【選択図】  図７
2008015722.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される端末から所定間隔で送信されてくるデータを受信する通信部と、
上記受信するデータの有無を判定して上記端末の異常判定を行う判定部とを有し、
上記判定部は、上記端末について上記異常判定を行う間隔を、予め定められた規則に従って上記所定間隔に基づいて決定することを特徴とするデータ処理システム。
【請求項２】
上記規則は，上記異常判定を行う間隔を上記所定間隔に任意の数を乗ずることによって決定するものであることを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
上記判定部は、上記端末からデータが送信される間隔が変更された旨の通知を受信すると、
上記予め定められた規則に従って上記異常判定を行う間隔を再決定することを特徴とする請求項１又は２に記載のデータ処理システム。
【請求項４】
上記判定部は、上記端末から送信されるデータを受信すると、該受信時刻から改めて上記異常判定を行う間隔の経過をカウントすることを特徴とする請求項１乃至３の何れかに記載のデータ処理システム。
【請求項５】
上記端末は無線センサノードであって、
上記受信部が受信するデータは該センサノードが所定間隔で無線送信するセンシングデータであることを特徴とする請求項１乃至４のいずれかに記載のデータ処理システム。
【請求項６】
上記判定部は、上記判定の結果該無線端末を異常と判定した場合には、接続される上位装置に該無線端末が異常である旨を通知することを特徴とする請求項１乃至５の何れかに記載のデータ処理システム。
【請求項７】
上記端末のデータ送信間隔の変更指示は上記判定部が発行し、上記端末に送出することを特徴とする請求項１乃至６の何れかに記載のデータ処理システム。
【請求項８】
上記判定部は、上記変更指示の対象となる上記端末の稼動状態が「異常」とされた場合に、上記変更指示の取消指示を発行することを特徴とする請求項７記載のデータ処理システム。
【請求項９】
上記判定部は，少なくとも２回以上連続して上記端末からデータを受信したタイミングからセンサノードの動作間隔を判定し、該判定した動作間隔に上記予め定められた規則を適応して上記端末の異常判定を行うタイミングを決定することを特徴とする請求項1乃至８の何れかに記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続した多数の端末の稼動状態を監視する技術に関する。
【背景技術】
【０００２】
近年、センサに無線通信機能を有する小型の電子回路を付加して、現実世界の様々な情報をリアルタイムに情報処理装置に取り込むネットワークシステム（以下、センサネットシステムという）が検討されている。センサネットシステムには幅広い応用が考えられており、例えば、無線回路、プロセッサ、センサ、電池を集積した小型情報端末（以下、センサノードという）により、温湿度や加速度等を測定し，人やモノの置かれた状態や周辺の環境情報，あるいは位置情報等を常時モニタし、モニタ結果は無線通信によりサーバ等に送信され、サーバに収集されるモニタ結果に基づいて人の活動状態やモノの保管状態の分析を行い，サービスに結び付ける技術が提案されている。
【０００３】
無線通信回路、プロセッサ，センサ、および、電池等の電源を搭載するセンサノードは従来の計算機システムにはない特徴を持っている。センサノードの通信及び電源がワイヤフリーであることにより，センサネットシステムを使うと従来観測できなかったモノや場所の状態をも観測可能となる。こうしたセンサネットシステムを広く実用化するためには、限られたエネルギー制約の中で長時間に渡ってメンテナンスフリーで（例えば，電池交換を少なくして），センシングデータを送信し続けられるセンサノードが求められる。また，センシングデータを使った何らかのサービスを提供し続けるためには，複数のセンサノードを含むセンサネットシステム全体の効率的な運用管理が求められる。
【０００４】
特に、システムの各構成要素が異常な状態になっていないか（障害が発生していないか，あるいは障害の兆候が表われていないか），その反対に正常に稼動し続けているか，を可能な限り監視することが要求される。例えば、システム構成要素の障害検出手段として、各クライアントがサーバから送出されたハードビート信号によりその障害有無を検知する技術がある（例えば、特許文献１参照）。
【０００５】
【特許文献１】特開平７−５６８３８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本願の対象とするセンサネットセンサノードはできる限り低消費電力で動作することが望まれる。従って，センサノードは，ある時間間隔毎に起動と休止を繰り返す，間欠動作をすることで消費電力を大幅に抑える場合が多い。この間欠動作についてはデータを活用する側であるアプリケーションからの要求により変動することがある。例えば，センシングデータの種類に応じて異なるデータの更新頻度を要求したり，同一のセンサであってもセンシングする時間帯に応じて異なるデータの更新頻度を要求したりすることがある。より具体的には，室内の温湿度を監視して空調制御を行うアプリケーションを考えた場合，室内に人が居ない時間帯（例えば，夜間）は，温湿度測定及びそのデータ送信の頻度を少なく（例えば５分に１回）し，部屋に人が居る時間帯（昼間）には，温湿度の測定及びそのデータ送信頻度を増やす（例えば１分に１回）ことが考えられる。
【０００７】
更に、システムの運用管理の観点からは，データの送信間隔が変わることによって，上記のセンサノードの障害判定の実行タイミングも適応的に調整する必要が出てくる。センサノードの障害判定処理の実行タイミングが適切でないと（例えば固定），動作間隔変更時以降に，非効率的な判定処理を実行したり，障害の検出遅延が許容範囲を超えたりしてしまう，といった問題が生じる。一方で，障害判定処理を常に繰り返し実行させることはシステムの計算機リソース消費の観点から非現実的である。
【０００８】
また，送信間隔が変更されることを全く前提としていないシステムにおいては，場合によっては障害監視において誤った検出あるいは検出し損なうという問題が発生することもあり得る。
さらに，上記の問題に対して，障害判定処理の実行タイミングをシステム管理者が個別に設定して対処することは，特にセンサノードの数が増加した場合に非常に非効率な対処となる。
【０００９】
そこで本発明は、上記問題点に鑑みてなされたもので、センサノードの限られたリソースを節約して有効に利用しながらも、間欠動作を前提とするセンサノードの障害監視を効率的にかつ信頼性高く実現することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために本願で開示する代表的な発明の概要は以下の通りである。
ネットワークを介して接続される端末から所定間隔で送信されてくるデータを受信する通信部と、受信するデータの有無を持って上記端末の異常判定を行う判定部とを有し、判定部は、上記端末について上記異常判定を行う間隔を、予め定められた規則に従って上記所定間隔に基づいて決定するデータ処理システム。
【発明の効果】
【００１１】
したがって，本発明により，センサノードの障害判定処理の実行タイミングを最適化でき，実際の障害検出を効果的に実現できる。また，システムに含まれるセンサノードの全て，あるいは，複数に対して共通に適用することが可能な規則に従って障害判定処理の実行タイミングを変更するため，設定の手間もかからない。したがって，効率的なシステム運用保守の実現に貢献し，システムを使って提供するサービスの品質を高く保つことができる。
例えば，こまめな空調制御が必要でない時間帯にセンサノードの動作頻度を抑えて，エネルギー（電源）の消費を抑える効果もある。さらに，使っている無線周波数帯によっては，昼間は人が障害物となり無線通信の品質が劣化する場合に送信頻度を増やして無線通信の信頼性を向上することも考えられる。さらに，これを遠隔から実現できるようにすることでシステム運用サービスを低コストで品質を向上させることも可能となる。
【実施例１】
【００１２】
以下、本発明の一実施形態を添付図面に基づいて説明する。
図１は、第１の実施形態を示し、本発明を適用するセンサネットワークシステム（以下，センサネットシステム）の一例を示すブロック図である。図示のセンサネットシステムでは、センサノードＳＮ１〜ＳＮｎらのセンシングデータを無線通信により基地局ＧＷ１〜ＧＷｍのいずれかの基地局ＧＷまで転送し、基地局ＧＷは無線通信上のセンシングデータを有線ネットワークＷＤＮへのゲートウェイとして機能する。基地局ＧＷで転送されるセンシングデータは有線ネットワークＷＤＮを介してセンサネット管理サーバＳＮＭＳに送られ、ユーザ端末ＵＳＴにより利用される。
【００１３】
センサネットワークシステムの構成要素の１つであるセンサノードＳＮ１〜ＳＮｎについて説明する。
図１において、センサノードＳＮ１〜ＳＮｎは，センシングデータまたは予め設定されたＩＤ（識別子）を無線通信により出力するセンサノードである。これらセンサノードＳＮ１〜ＳＮｎは、無線ネットワークＷＬＮにより、基地局ＧＷと無線通信を行う。センサノードＳＮ１〜ＳＮｎは、例えば、人の状態をモニタする目的で、人の所定の部位に装着される。各センサノードＳＮ１〜ＳＮｎは、センシングした温度や脈拍，加速度等のデータを，基地局ＧＷを介してセンサネット管理サーバＳＮＭＳに送信する。
【００１４】
ＳＮ１〜ＳＮｎは，無線通信を実現する無線回路ＲＦＣ，周辺あるいは接触している人，モノや環境の何らかの物理現象（例えば，温度，加速度，圧力，等）を測定（センシング）するセンサデバイスＳＤＥＶ，周辺あるいは接触している人やモノや環境へ何らかの物理現象（例えば，発光，文字表示，振動，等）を作用させるアクチュエータデバイスＡＤＥＶ，センサノード自身の動作を規定するプログラムを実行するためのマイコンＣＰＵ，以上の構成要素を駆動させる電源ＰＷＲからなる。例えば，電源ＰＷＲが電池の場合，使える電力には制限がある。なるべく寿命を長くするためには，センシング処理などの稼動時の消費電力を抑えると伴に，センシング処理などが必要ない時間は使用しない構成部品には電力を供給しないように制御する必要がある。
【００１５】
センサノードＳＮ１〜ＳＮｎのマイコンCPUは、それぞれのセンサノードＳＮ１〜ＳＮｎに設けたセンサデバイスＳＤＥＶの動作を管理・制御するセンサ制御部ＳＣＴＬと、センサノードＳＮ１〜ＳＮｎに設けたアクチュエータデバイスＡＤＥＶの動作を管理・制御するアクチュエータ制御部ＡＣＴＬと，無線ネットワークＷＬＮを介して他のセンサノードＳＮｉあるいは基地局ＧＷと無線通信を管理・制御する無線通信制御部ＲＦＣＴＬと、センサノードＳＮ１〜ＳＮｎに設けた電源ＰＷＲからの電力供給を制御する電源制御部ＰＷＣＴＬと，前記センサ制御部とアクチュエータ制御部と無線通信制御部と電源制御部を統制する動作制御部ＭＣＴＬとの機能を備える。なお，前記センサ制御部とアクチュエータ制御部と無線通信制御部と電源制御部と動作制御部は，前記マイコンＣＰＵ上でプログラムとして実現できる。
【００１６】
センサノードＳＮ１〜ＳＮｎが備えるセンサデバイスとしては、例えば、温度センサ、湿度センサ、加速度センサ，圧力センサ，脈拍センサであり、この他、個人や個々の物を識別するための識別子を有するものである。
【００１７】
また，センサノードＳＮ１〜ＳＮｎが備えるアクチュエータデバイスとしては、発光素子であるＬＥＤや液晶表示装置ＬＣＤなどがあり，それらを備えた例えば腕時計型の形態のセンサノードなどが実現可能である。なお、アクチュエータのないセンサノードＳＮ１〜ＳＮｎでは、アクチュエータ制御部ＡＣＴＬは設けない。
【００１８】
センサネットワークシステムの構成要素の１つである基地局ＧＷについて説明する。
基地局ＧＷは、配下の複数のセンサノードＳＮ１〜ＳＮｎとの無線通信を制御する無線通信制御部ＧＲＦＣと、センサネット管理サーバＳＮＭＳとの有線通信を制御する有線通信制御部ＧＮＩＣと、ＩＤを管理するＩＤ管理部ＧＩＤＭと，コマンドを管理するコマンド管理部ＧＣＭＭと，センサネットサーバＳＮＭＳとセンサノードＳＮ１〜ＳＮｎの間で送受信されるパケットを変換する上りパケット変換部ＵＰＣと，同様に下りパケットを変換する下りパケット変換部ＤＰＣを有する。基地局ＧＷは１つのＰＡＮ（Personal Area Network）を管理し，ＰＡＮの中に所属する任意の個数のセンサノードと無線通信によりデータの送受信をすることができる。
【００１９】
ＩＤ管理部ＧＩＤＭは、新規にＰＡＮへの参加要求をしてくるセンサノードに対するローカルＩＤの割り当て，ローカルＩＤからグローバルＩＤへの変換、またはグローバルＩＤからローカルＩＤへの変換を行う。このためのＩＤ管理表を内部に持つ。ローカルＩＤとは、１つのＰＡＮ（Personal Area Network）内をスコープとするＩＤである。通常、１つのＰＡＮにローカルＩＤを管理する機能を持った基地局ＧＷが１つ存在する。ローカルＩＤはグローバルＩＤよりもビット長が短く、送受信パケットに含む際に無線通信の消費電力を抑える効果が期待できる。
【００２０】
グローバルＩＤとは、少なくともセンサネットシステム上のアプリケーションあるいはセンサネットシステムの上位システムがセンサノードを識別可能なＩＤである。１つのセンサネットシステムでは、複数のＰＡＮを含むことがあるため、アプリケーションあるいはセンサネットシステムの上位システムではグローバルＩＤを使ってセンサノードを管理する。このため、グローバルＩＤはローカルＩＤに比べて、ビット数が多い。例えば、ユビキタスＩＤセンタのucodeでは基本は128 ビットから成り、EPCグローバルのEPC(Electronic Product Code)は96ビットから成る。これに対して、ローカルＩＤは例えば16ビット程度である。
【００２１】
下りパケットは，センサノードに対するコマンドである。センサノードの動作間隔などの動作パラメータを変更するコマンド，ある動作パラメータの現在の設定値を問い合わるコマンドなどである。一方，上りパケットはセンサノードによる観測データ，あるいは，前記センサノードに対するコマンドの応答などである。
【００２２】
コマンド管理部ＧＣＭＭは、センサノードＳＮ１〜ＳＮｎからセンサネットサーバＳＮＳへ向かう上りのデータが、以前にセンサノードに送信したコマンドに対する応答であるかどうかを判定するために、無線通信制御部ＧＲＦＣが送信したコマンドを管理している。センサノードＳＮ１〜ＳＮｎへ向かう下りパケット変換部ＤＰＣから配下のセンサノードＳＮ１〜ＳＮｎへコマンドを送信する時に、そのコマンドが登録される。
【００２３】
センサネットワークシステムの構成要素の１つである無線ネットワークＷＬＮについて説明する。
無線ネットワークＷＬＮは消費電力の少ない無線方式で構築される。例えば，IEEE.802.15といった標準規格が使われる。ただし，本発明ではこの規格に限定するものではない。
【００２４】
センサネットワークシステムの構成要素の１つであるユーザ端末について説明する。
ユーザ端末ＵＳＴは，センサネットシステムのシステム管理者がシステムの状態監視や動作パラメータの確認・設定などの操作を行うためのセンサネット管理クライアントＳＮＭＣやセンサネットシステムを適用するアプリケーションとして，人やモノ，環境の状態をモニタしたり，モニタした結果に基づいて特定のサービスを提供するアプリクライアントＡＰＰＣからなる。ただし，これらセンサネットクライアントＳＮＭＣとアプリクライアントＡＰＰＣは，物理的にセンサネット管理サーバと同じ計算機上にあっても，別の計算機上にあっても良い。また，それぞれが異なる計算機上にあっても良い。
【００２５】
センサネットワークシステムの構成要素の１つであるセンサネット管理サーバＳＮＭＳについて説明する。
センサネット管理サーバＳＮＭＳは、有線ネットワークＷＤＮ（例えば、インターネット等）を介して複数の基地局ＧＷ〜ＧＷｍが収集したセンシングデータを管理し、ユーザ端末（ユーザ計算機）ＵＳＴに意味情報を付加したセンシングデータを提供する。
【００２６】
センサネット管理サーバＳＮＭＳは以下の処理部を有する。有線ネットワークＷＤＮを介して基地局ＧＷやユーザ端末ＵＳＴ，外部装置と通信を行う有線通信制御部ＳＮＩＣ。ユーザ端末ＵＳＴとの送受信を制御し管理するセッション管理部ＳＳＭ。受信したデータをイベントとして受け付け，予め組み込まれたロジックに従って，条件判定した結果に基づいて所定のアクションを起動するイベント処理エンジンＥＶＥ。前記イベント処理エンジンに組み込まれるロジックをユーザ端末より予めスクリプトとして受信して管理するスクリプト管理部ＳＣＭ。イベント処理エンジンＥＶＥが起動するアクションの１つとして外部装置の操作をする外部装置連携アダプタＥＸＴＩＦ。予め指定されたタイミングで前記イベント処理エンジンが受け付けるイベントの一つともなるタイマイベントを発行するタイマＴＭＲ。センサノードＳＮ１〜ＳＮｎや基地局ＧＷ１〜ＧＷｍの構成情報（ＩＤや設置場所、稼働状態、等）や管理するセンサノードに搭載されているそれぞれのセンサによるセンシングデータを統合的に管理するセンサネット構成管理部ＣＦＭ。ユーザ端末ＵＳＴ等からの，あるいは，前記イベント実行エンジンや前記センサネット構成管理部からの基地局ＧＷやセンサノードＳＮ１〜ＳＮｎに対する指令を発行し管理するセンサネットコマンド管理部ＣＭＭ。前記センサネット構成管理部や前記セッション管理部が扱うデータをデータベースとして管理するデータベース管理部ＤＢＭＳ。
【００２７】
前記イベント処理エンジンＥＶＥは、有線通信制御部ＳＮＩＣが受信した基地局ＧＷ１〜ＧＷｍからのデータが事前にセンサネットコマンド管理部ＣＭＭが発行したコマンドに対する応答であれば，センサネットコマンド管理部ＣＭＭに転送し，センシング（観測）データであれば，予め組み込まれたロジックに従って，対応するアクションを起動する。例えば，受信したデータが予め異常監視ロジックが組み込まれているセンシングデータであった場合は，異常な値になっていないか判定し，異常と判断された場合は，後述する構成管理の管理データを更新すると共に、所定のアクションが予め登録されていればそのアクションを起動する。所定のアクションとは，例えば，ユーザ端末ＵＳＴ上のアプリクライアントＡＰＰＣに異常が検出された旨を示すメッセージを表示する，といった動作であり，ユーザ端末ＵＳＴからの指示に応じて予めスクリプト管理部ＳＣＭを介して設定される。また、イベント処理エンジンＥＶＥは、タイマＴＭＲからのタイマイベントをトリガーに特定の動作を起動させることもある。例えば、イベント処理エンジンＥＶＥは、タイマＴＭＲからの定期的なタイマイベントを受信する度に、システムの各構成要素であるセンサノードの生死判定を含めて、障害が発生していないかどうかを判定する処理を実行する。
【００２８】
前記センサネット構成管理部ＣＦＭでは、基地局ＧＷｉ、センサノードＳＮｉなどセンサネットシステムを構成する各デバイスの動作パラメータや稼働状態などを管理する。また、それら各デバイスの登録や検索に関するインターフェースをユーザ端末ＵＳＴ等に提供する。図９に具体的に管理する項目（図９（Ａ）基地局管理項目，（Ｂ）センサノード管理項目），基地局管理テーブル（図９（Ｃ））及びセンサノード管理テーブル（図９（Ｄ））の一例を示す。管理項目（あるいは属性）の中には，“名称”や“ＭＡＣアドレス”のように運用中は基本的には変更されない項目、“データ送信間隔”のように運用中に変更される可能性のある動作パラメータ、あるいは“接続ノードリスト”や“稼働状態”や“温度最新値”や“最終データ受信時刻”のように運用中に状況に応じて自動的に更新される項目がある。自動的に更新される項目の更新処理は，例えば前記イベント処理エンジンＥＶＥがセンサネット構成管理ＣＦＭの属性の更新処理を呼び出すことで実現される。また、“接続ノードリスト”や“所属基地局ＩＤ”のように、各センサノードＳＮｉについて、どの基地局ＧＷｉの配下に属しているかといった接続関係を構成情報として管理する。例えば，この接続関係に基づいて，あるセンサノードＳＮに動作パラメータ（センシング間隔やデータ送信間隔など）を変更するコマンド（指令）を送りたい場合に，まずどの基地局ＧＷに対してそのコマンドを送信（センサノードへのコマンド転送を依頼）すれば良いか送信経路を決定する。
【００２９】
なお，基地局ＧＷの１つが物理的にセンサネット管理サーバの機能を備えていても良い。
図１における有線ネットワークＷＤＮは，必ずしも有線ネットワークである必要はなく，無線のネットワークであっても良い。但し，図１中の無線センサネットを形成する無線ネットワークＷＬＮのように低消費電力が必要な特殊な無線ネットワークである必要はなく，例えばIEEE.801.11a/b/gのような所謂無線ＬＡＮで良い。
【００３０】
センサネットシステムにおけるセンサノードの稼動状態監視について説明する。
さて，システムを使って何らかのサービスを継続的に提供することを考えると，システムの運用管理は必須である。運用管理の１つに様々なシステム異常を監視する作業がある。センサネットシステムにおいても，例えば多数あるセンサノードがそれぞれ正常に稼動しているかどうかを統合的に把握し，異常があればいち早く検出して可能な対処をすることが必要である。
【００３１】
遠隔で稼動しているある装置の異常を監視する手段の１つとして，監視装置である管理サーバが任意のタイミングで監視対象の装置に状態を問合せる指令を送り，その応答が比較的瞬時にある特定の待ち時間の間に返ってくるかどうかを見ることで監視対象の装置が正常に稼動しているかどうかを把握することができる。しかし，センサネットシステムの場合，センサノードは消費電力を抑えるためにある一定間隔毎に稼動と休止を繰り返すような間欠動作をしているため，任意のタイミングで瞬時に応答することは困難である。
【００３２】
別な手段として，監視対象である装置がある固定された間隔で特定のハートビート信号（生死判定をするための信号）を送出し，監視装置である管理サーバがそのハートビート信号の受信状況に基づいて監視対象の装置の稼動状態を判定する方法がある。すなわち，最後にハートビート信号を受信した時刻とハートビート信号の送信間隔から次にハートビート信号を受信すべき時刻を求め，その時刻が現在の時刻より以前か以後か判定し，以後（未来）であれば正常と判断し，もし以前（過去）であれば最後のハートビート信号が届いていないということで障害と判定を下すことができる。センサノードの場合もこの方法により，稼動状態を監視することができる。ここで，消費電力を抑える必要があるセンサノードでは，監視のためだけに特定のハートビート信号を送出することは避けたい。センサを使って環境情報（例えば，温度）を定期的にセンシング（観測）することが要求されている場合には，そのセンシングデータが定期的に送信されるので，送信されるセンシングデータを同時にハートビート信号と見做すことができる。
尚、消費電力を犠牲にしてでもセンシングデータを取得する信頼度を上げるためには，センシングデータよりも短い間隔で頻繁に別途特定（専用）のハートビート信号を送信する場合も例外的にあり得る。また，人やモノが置かれた，人やモノが触った，などを機械的なスイッチをトリガーにしてデータを非定期に送信することが想定されているセンサノードでは，やはり別途生死判定をするための目的で、ある一定間隔でハートビート信号を送信する場合もある。この場合に送信する信号は、ハートビート専用の信号としても良いし、何らかのセンシングデータを含めても良い。
【００３３】
図２及び図３はセンサノードの測定データが届かない障害の監視を説明するシーケンス図である。
【００３４】
図２は，センサノードの障害監視の一実施例を示すシーケンス図であり，データ受信非同期型タイマ（詳細後述）を使った場合である。図２におけるセンサノードＳＮｘは図１におけるセンサノードＳＮ１〜ＳＮｎの１つに相当し，タイマＴＭＲは図１と同じある。また，図２における構成管理＆イベント処理（ＣＦＭ＆ＥＶＥ）は図１におけるセンサネット構成管理ＣＦＭ及びイベント処理エンジンＥＶＥに相当し，図２における管理クライアントＳＮＭＣは図１におけるセンサネット管理クライアントＳＮＭＣに相当する。なお，図２においては，図１における基地局ＧＷは省略してある。
【００３５】
前提として図２のシーケンス例において、イベント処理部ＥＶＥはタイマイベントを受付けるとそれをトリガーにセンサノードの障害判定を実行する。ここで、障害を判定する対象となるセンサノードは，構成管理部ＣＦＭ内のセンサノード管理テーブル（図９（Ｄ））において、その時点で「稼働」（または「加入」）という“稼動状態”として管理されているセンサノードである。基本的には障害判定対象となっているセンサノード全てに対して、イベント処理部ＥＶＥはタイマイベントを受けるたびに障害判定処理を実行する。
【００３６】
また、管理クライアントＳＮＭＣは構成管理部ＣＦＭに対して、同構成管理部が管理している任意の属性が更新された場合にそのことを通知してもらうように予め登録しておくこともできる。また、管理クライアントＳＮＭＣは、構成管理部ＣＦＭに更新通知を事前に登録しているか否かに関わらず、任意のタイミングで構成管理部に対して任意の管理属性（例えばセンサノードの稼動状態）を問合せることもできる。以上の前提は図２だけでなく、図３から図８までに関しても当てはまる。
【００３７】
図２において，センサノードＳＮｘはＰＡＮに加入（joinまたはassociate）した後，一定間隔で間欠的に稼動し，稼動中はある観測対象をセンシングし，その観測データを無線通信により送信するという処理を一定間隔で繰り返す。イベント処理エンジンＥＶＥは，センサノードＳＮｘが加入したイベント通知を受けると，構成管理部ＣＦＭは構成管理情報（図９）の一部であるセンサノードＳＮｘに関する属性の１つ“稼動状態”を「加入」という値に更新する。この「加入」への更新は，そのことを予め通知するように管理クライアントＳＮＭＣが登録していれば，図２に示すように通知される。また図２では、センサノードからの加入イベントを受信したことでタイマＴＭＲを起動しているシーケンスを示しているが、既にタイマＴＭＲが起動されていればこの処理は必要ない。
【００３８】
図２に沿って，センサノードが起動した後の基本的な動作をさらに説明する。
構成管理部ＣＦＭは，イベント処理部ＥＶＥ経由でセンサノードＳＮｘから一定間隔で測定データを受信する度に，構成情報を表わす属性の１つである“稼働状態”が正常状態を表す「稼動」であることを確認し，「稼動」になっていなければ（例えば「加入」や「障害」「不明」）「稼動」に更新する。さらに、別の属性である “最終データ受信時刻”を更新する。
【００３９】
イベント処理部ＥＶＥは，タイマＴＭＲからタイマイベントを受ける度に，稼働状態判定（障害判定）処理を実行し，センサノードＳＮｘを含む全てのセンサノードについて、構成管理部ＣＦＭで図９（Ｄ）のようにノードＩＤにそれぞれ対応づけて管理しているそれぞれのセンサノードの“最終データ受信時刻”からそれぞれのセンサノードの“データ送信間隔”以上の時間が経過していないかを判定し，もし経過しているセンサノードがあれば「障害」と判定する。「障害」と判定された場合は，構成管理部ＣＦＭの図９（Ｄ）のテーブル中、該当するセンサノードの属性“稼動状態”の値を「障害」に更新する。図２において，１番目から４番目のタイマイベントを受信したときの稼働状態判定結果は正常であり，“稼動状態”は「稼動」のままである。５番目のタイマイベントを受信したときは，センサノードＳＮｘから３番目の測定データが何らかの原因で届いておらず，「障害」と判定している。この判定結果は，予め通知の設定がされていれば管理クライアントＳＮＭＣにも通知される。障害検出した際，“稼動状態”を「障害」に更新しているが，その後，測定データを受信して復旧を確認できた場合には，“稼動状態”を再び「稼動」に戻し，予め通知の設定が登録されていれば管理クライアントＳＮＭＣに「復旧」を通知する。なお、「加入」「稼働」「障害」といった属性“稼働状態”が取る値はこれらに限る必要はなく、表現を変えても良いし、取り得る値のバラエティを新たに追加しても良い。
【００４０】
図２で示しているデータ受信非同期型タイマを利用した場合には，予め設定されたタイミングでタイマＴＭＲから発行されたタイマイベントをイベント処理エンジンＥＶＥが受け取ったタイミングで障害判定を行うために，図中に示したように検出遅延及び通知遅延は避けられず，予め遅延許容時間範囲を吟味した上で，タイマイベントの発行間隔を決定し設定しておく必要がある。
【００４１】
図３は，センサノードの障害監視の別の例を示すシーケンス図であり，データ受信同期型タイマ（詳細後述）を使った場合である。本シーケンス例においては、センサノードからの送信データの送信タイミングと障害判定実行タイミングとをなるべく同期させるべく、タイマに動作周期が設定されている。尚、図３各部と図１の関係は図２と同様である。
【００４２】
図３において，センサノードＳＮｘはＰＡＮに加入（joinまたはassociate）した後，一定間隔で間欠的に稼動し，稼動中はある観測対象をセンシングし，その観測データを無線通信により送信するという処理を一定間隔で繰り返す。イベント処理部ＥＶＥは，センサノードＳＮｘが加入した通知を受けると，タイマＴＭＲをセンサノードＳＮｘが想定している測定データ送信間隔に基づいた時間間隔（例えば，想定している“データ送信間隔”）でタイマイベントを発行するように設定する。構成管理部ＣＦＭはセンサノード管理テーブル（図９（Ｄ））の中で対応するセンサノードＳＮｘの“稼動状態”を「加入」に更新する。この「加入」は，そのことを予め通知するように管理クライアントＳＮＭＣが登録していれば，図３に示すように通知される。
【００４３】
続いて，構成管理部ＣＦＭは，イベント処理部ＥＶＥ経由でセンサノードＳＮｘから一定間隔で測定データを受信すると，センサノード管理テーブル（図９（Ｄ））内で保持している属性（あるいは管理項目）である“稼動状態”が正常状態を表す「稼動」であることを確認し，「稼動」になっていなければ「稼動」に更新し，同時にセンサノード管理テーブル（図９（Ｄ））内で保持している“最終データ受信時刻”を更新する。また同時に，イベント処理エンジンＥＶＥは，タイマＴＭＲに対して再起動の指令を出し，前記のタイマイベント発行を一旦取り消し，同じ条件でタイマイベント発行を再設定する。ここでタイマＴＭＲを再設定しているが、これはタイマイベントの精度の問題である。測定データと同期するように精度を保つためには測定データを受信する度に同期を取ることが望ましいが、何らかの手段で再設定せずに同期するタイミングが維持できるならば、タイマＴＭＲの再設定は必須ではない。
【００４４】
図３においては，センサノードＳＮｘから３番目の測定データが何らかの原因で届かなかった場合のシナリオを想定している。したがって、３番目の測定データが届く予定であった直後にタイマからタイマイベントが発行される。イベント処理部ＥＶＥは、このタイマイベントを受けるだけでセンサノードＳＮｘの状態を「障害」と判定し，障害を検出できる。より厳密には，構成管理部ＣＦＭ内のセンサノード管理テーブル（図９（Ｄ））で保持しているあるセンサノードＳＮｘに関する“最終データ受信時刻”から，同じくセンサノード管理テーブルで保持している“データ送信間隔”以上の時間が経過していないかを評価し，もし経過していれば「障害」と判定してもよい。ここで，障害検出の判断結果は，センサノード管理テーブル（図９（Ｄ））内の該当するノードの“稼動状態”の値を「障害」に更新する。いずれにしてもこの障害検出にはほとんど遅延が生じないのが、データ受信同期型タイマを使った場合の特徴である。
【００４５】
また、この判定結果は，管理クライアントＳＮＭＣに通知することもできるが、その通知にもほとんど遅延が生じない。
【００４６】
次に，タイマＴＭＲについて説明する。図２及び図３に示した通り，障害判定処理の実行タイミングを決めるタイマの使い方は２通り考えられるが，それぞれに長所と短所があるので，状況に応じて使い分けることが望ましい。
【００４７】
図２で用いた“データ受信非同期型タイマ”は，データ受信タイミングとは無関係に適当な間隔でタイマイベントを発行し続けるように使うタイマであり，１つのタイマを複数のセンサノードの障害判定起動に共用する。この方法によれば，１回の障害判定実行時にタイマを共用している全ての監視対象センサノードについて判定処理をする必要があり，送信間隔の一番短いセンサノードに合わせて障害検出遅延を決めると計算量が多くなる傾向にあり，障害検出（及び障害通知）の遅延時間が明らかに存在する。一方，タイマを共用するためタイマを実装するための計算機リソース（主にメモリ使用量）が少ない。従って，許容できる遅延時間が比較的緩い場合と，監視対象のセンサノード数が多い場合に有効である。
【００４８】
図３で用いた“データ受信同期型タイマ”は，センサノードからのデータ受信に合わせて起動し，想定される送信間隔＋α（例えば１秒）の時間経過後にタイマイベントを発行するように使うタイマであり，センサノード毎にタイマを用意し，個々のセンサノードのセンシングデータの送信タイミングに沿ったタイマイベントを利用する。
【００４９】
この方法によればは，センサノードの数だけタイマを実装するための計算機リソース（主にメモリ）が多くなる。一方で，障害判定の実行がセンサノード単位なので必要最小限の計算量（時間）で済み，障害（ハートビート不達）検出の遅延時間が少なくなる。従って，許容できる遅延時間が厳しい場合と，監視対象のセンサノード数が少ない場合に有効である。
【００５０】
次に，センサノードからのデータ送信間隔の変更について説明する。
ハートビート信号と見做すセンシング（測定）データの送信間隔は必ずしも固定ではない。センサノードが間欠動作に伴い送信するセンシングデータの送信間隔は，そのデータを活用する側であるアプリケーションからの要求により変動することがある。例えば，センシングデータの種類に応じて異なるデータの更新頻度を要求したり，同一のセンサであってもセンシングする時間帯に応じて異なるデータの更新頻度を要求したりすることがある。
【００５１】
なお，送信間隔の変更は，アプリケーションやセンサネットシステム管理者からの指示により変更することもあるし，センサノード自身が自分で観測しているデータがある条件を満たしたときに自らの測定間隔やデータ送信間隔を自律的に変更することもあるし，あるいは，あるセンサノードによるある観測対象の測定の結果がある条件を満たしたときに別のセンサノードの測定間隔やデータ送信間隔をシステム（センサネット管理サーバＳＮＭＳ）内で自動的に変更することもある。
【００５２】
ここで，システムの運用管理の観点からは，あるセンサノードにおいてデータの送信間隔が変更されることに伴い，同センサノードの障害判定の実行タイミングも適応的に調整する必要が出てくる。センサノードの障害判定処理の実行タイミングが適切でないと（例えば固定），動作間隔変更時以降に，非効率的な判定処理を実行したり，障害の検出遅延が許容範囲を超えたりしてしまう，といった問題が生じる。一方で，障害判定処理を常に繰り返し実行させることはシステムの計算機リソース消費の観点から非現実的である。また，送信間隔が変更されることを全く前提としていないシステムにおいては，場合によっては障害監視において誤った検出あるいは検出し損なうという問題が発生することもあり得る。
【００５３】
（規則の説明）
上記問題を解決するために本発明では，センサノードの障害判定処理の実行タイミングを，予め設定された規則に従って，前記センサノードで想定されている間欠動作間隔（あるいはデータ送信間隔）に基づいて決定する。データ受信同期型タイマを利用する場合は，例えば，あるセンサノードの障害判定処理の実行タイミングを，最初のタイミングについては前の測定データを受信してからそのセンサノードに設定されている“データ送信間隔”にマージン間隔１秒を足した時刻とし、その後“データ送信間隔”と同じ時間間隔毎に実行するように予め規則を設定し、そのように障害判定処理実行のトリガーとなるタイマイベントが発行されるようにタイマＴＭＲを設定する。もちろんマージン間隔としては、受信タイミングと判定タイミングがかけ離れない範囲で、任意の値を設定しておくことができる。
【００５４】
また，データ受信非同期型タイマを利用する場合は，例えば，センサノードの障害判定処理の実行間隔（すなわちタイマイベント発行間隔）を、そのセンサノードに設定されている“データ送信間隔”，あるいは“データ送信間隔”の１／２の時間や１／３の時間などの任意の数値倍間隔になるように予め規則を設定し、そのように障害判定処理を実行するトリガーとなるタイマイベントを発行するようにタイマを設定する。
【００５５】
さらに，センサノードの固体あるいは種類毎に要求される間欠動作間隔が異なる場合，各センサノードの障害判定処理の実行タイミングを使い分けても良い。また，アプリケーションから観測データの要求頻度が変更された場合，あるいは，システム管理者からセンサノードの間欠動作間隔の変更要求があった場合，センサネット管理サーバＳＮＭＳは障害判定処理の実行タイミングをその動作間隔の変更に追従するように変更する。具体的には，イベント処理エンジンＥＶＥは，あるセンサノードに対する動作間隔変更指示に対して，センサノードの自律的なタイミングによる動作間隔の変更操作結果を受信することにより，センサノードでの動作間隔変更の操作完了を確認できた直後に，タイマＴＭＲに対してタイマイベント発行タイミングを変更するよう設定する。
【００５６】
したがって，本発明により，センサノードの障害判定処理の実行タイミングを最適化でき，実際の障害検出を効果的に実現できる。したがって，効率的なシステム運用保守の実現に貢献し，システムを使って提供するサービスの品質を高く保つことができる。
【００５７】
（図４，図５の説明）
図４及び図５は，データ受信非同期型タイマを利用したシステムにおいて，本発明の適用前及び適用後の送信間隔変更時のシーケンス図である。図４及び図５において，センサノードＳＮｘは図１におけるセンサノードＳＮ１〜ＳＮｎの中の１つに相当し，ＧＷはセンサノードＳＮｘを配下に持つ基地局を示している。また，図４及び図５における，構成管理＆イベント処理＆コマンド管理部（ＣＦＭ＆ＥＶＥ＆ＣＭＭ），及び要求管理ＳＳＭは，図１におけるセンサネット構成管理部ＣＦＭ、イベント処理エンジンＥＶＥ、センサネットコマンド管理部，及びセッション管理部ＳＳＭに相当する。また，図４及び図５における管理クライアントＳＮＭＣは図１におけるセンサネット管理クライアントＳＮＭＣに相当する。
【００５８】
図４は，センサノードＳＮｘの動作間隔（“データ送信間隔”）がt0からt1（但し，t0>t1）に変更されたシナリオに沿って，センサネット管理サーバＳＮＭＳにおいて，判定基準は変更する（次にデータ受信すべき時刻は変更後の動作間隔に基づいて推定する）が，判定処理自体を実行するためのタイマ間隔（判定処理開始のトリガーとなるタイマイベントを発行するタイミング）は特に変更しなかった場合のシステムの動作シーケンスを示している。図４に示すように，タイマＴＭＲからのタイマイベントの発行は測定データの受信とは非同期に起こる。
【００５９】
図４に図示している通り，例えば，管理クライアントＳＮＭＣからセンサノードＳＮｘの送信間隔変更コマンドをセンサネット管理サーバＳＮＭＳに対して要求すると，その送信間隔変更コマンドはセンサネットコマンド管理部ＣＭＭを経由して、センサノードＳＮｘを配下に持っている基地局ＧＷまで一旦転送される。このとき複数の基地局ＧＷのどの基地局ＧＷにコマンドを転送したら良いかは図１の説明で既に記載した通り，センサネット管理サーバ内のセンサネット構成管理部ＣＦＭ内で解決される。その転送先である基地局へは、センサネットコマンド管理部ＣＭＭから転送されると共にセンサネットコマンド管理部ＣＭＭでは転送したコマンドを保持，管理している。基地局ＧＷへ転送された送信変更コマンドはそこで一時保管される。なぜならば，センサノードＳＮｘは間欠動作しており，任意のタイミングでデータ受信できないためである。センサノードＳＮｘは間欠動作をして測定データを送信した直後のみ受信状態になることができる。したがって，基地局ＧＷに一時保存されていた送信間隔変更コマンドは，センサノードＳＮｘが間欠動作中に測定データを送信した直後に，センサノードＳＮｘに伝達される。センサノードＳＮｘは受信した送信間隔変更コマンドに基づいて，自分の動作パラメータを変更する。具体的には無線通信制御部ＲＦＣＴＬで受信した送信間隔変更コマンドに基づいて、動作間隔を変更する。図１に図示はしていないが、センサノードはクロックとRTC(Real Time Clock)等の計時機能のある素子だけには常時電源を供給し、少ない電力で間欠動作の動作間隔を制御することができる。
【００６０】
動作間隔を変更したセンサノードＳＮｘは、無線通信制御部ＲＦＣＴＬを介して，間隔変更結果を基地局ＧＷへ返信する。センサネット管理サーバＳＮＭＳ内のイベント処理部ＥＶＥは，基地局ＧＷ経由でセンサノードＳＮｘでの送信間隔変更コマンドの結果の通知をセンサネットコマンド管理部へ転送する。センサネットコマンド管理部ＣＭＭは、コマンドが完了したことを確認すると，その結果を受けセンサネット構成管理部ＣＦＭで管理しているセンサノードＳＮｘの動作パラメータに関する項目“データ送信間隔”の値をt0からt1に変更する。これにより少なくとも測定データ不達の障害の判定基準（想定している“データ送信間隔”）は更新することになるが、センサネット管理サーバＳＮＭＳ内におけるタイマＴＭＲによるタイマ間隔は変更されないために、センサノードからの送信間隔が短くなったにもかかわらず従来の間隔，すなわち頻度でのみ障害判定は実行される。
【００６１】
このとき，図４に例示しているように，センサノードＳＮｘが動作間隔を変更した後に送信されている測定データのうちd4及びd5が何らかの不具合で基地局ＧＷまで届かなかった場合，次の障害判定のトリガーとなるタイマイベントが発生するまで障害判定が実施されない。すなわち，図４の場合，障害検出の遅延時間が大きくなってしまい，さらに言うと届かなかった測定データd4に対する障害検出は実質できていないに等しい。さらに，図４の例では別の届いていない測定データd7の障害検出はできていないことになる。
【００６２】
図５は，センサノードＳＮｘの動作間隔（“データ送信間隔”）をt0からt1（但し，t0>t1）に変更したシナリオにおいて，本発明を適用して，判定基準及びタイマ間隔を変更した場合のシステム全体の大まかな動作シーケンスを示している。図５に示すように，図４と同様にタイマＴＭＲからのタイマイベントの発行は測定データの受信とは非同期に起こる。
【００６３】
前提として本実施例において，イベント処理部ＥＶＥは，障害判定処理を実行する間隔を“データ送信間隔”と同じ長さとするというルールを予め設定しているとする。すなわち，測定データの測定頻度要求が変動する等によりセンサノードからの測定データの送信間隔が変更された場合には，イベント処理部ＥＶＥがセンサノードの障害判定処理を実行するタイミングを連動して変更する。
【００６４】
図５に示す通り，本発明を適用することにより，イベント処理部ＥＶＥはセンサノードＳＮｘに対する送信間隔変更コマンドが完了したイベントを受信した際に，構成管理部ＣＦＭが管理している動作パラメータである同センサノードＳＮｘの“データ送信間隔”の値をt0からt1に変更する。さらにイベント処理部ＥＶＥは，タイマＴＭＲに対して，タイマイベント発行間隔を前述のルールに従って決定した時間間隔にタイマを再設定する（図５のc1）。図５の例では，タイマイベント発行間隔は“データ送信間隔”と同じという条件が設定されていたために，センサノードＳＮｘに対して新たに設定した送信間隔t1と同じ間隔でタイマイベントを発行するようにタイマを再設定している。図５に示しているように，本発明を適用することによって，障害検出の遅延時間が大きくなってしまったり，障害検出できていなかったりしていた測定データd4，d5，d7が，検出遅延時間はあるものの確実に障害検出できるようになっている。
【００６５】
例えば、障害検出の間隔を予め極力短く設定しておくことで，ある程度の障害検出ミスや障害検出の遅延時間を短くすることは可能ではある。ただし，将来どの程度の送信間隔に設定されるか予測することは不可能であり，予めかなり短い固定の間隔でタイマイベントを発行するように設定することは，計算機リソースの無駄使いにもなり，システム全体でも非効率な動作となってしまう。それに対して本発明の障害検出判定処理の駆動タイミングを動的に調整することにより，測定データの送信間隔が動的に変わる場合でも，常にその間隔に同期した効率的な障害検出が可能となる。また、複数のセンサノードのデータ送信間隔を変更するような場合でも、基本的には共通のルールが適用でき、１つのルールだけ保持あるいはメンテナンスするだけで済むので管理上の手間も少ない。
【００６６】
尚、上記実施例ではデータ送信間隔と同じ間隔とするように設定したが、本願発明において異常判定を行うタイミングを上記所定間隔に任意の数を乗ずることによって決定するものであれば、無駄なくかつ最適なタイミングにおいて異常判定を行うというメリットを得ることができる。任意の数としては、より緻密に判定を行いたい場合には小数とすれば良いし、整数を設定すればセンシング複数回に一回、必ず異常判定が行われることになる。
【００６７】
（図６及び図７の説明）
図６及び図７は，データ受信同期型タイマを利用したシステムにおいて，本発明の適用前及び適用後の送信間隔変更時のシーケンス図である。図６及び図７において，センサノードＳＮｘ，タイマＴＭＲ，構成管理＆イベント処理部（ＣＦＭ＆ＥＶＥ），要求管理ＳＳＭ，及び管理クライアントＳＮＭＣの各構成要素は図４及び図５と同様に図１に対応付けられる。
【００６８】
図６は，センサノードＳＮｘの動作間隔（“データ送信間隔”）がt0からt1（但し，t0<t1）に変更されたシナリオを説明する。図６においては、基地局ＧＷが送信間隔変更コマンドを一時保存した後，センサノードＳＮｘに伝達され送信間隔の値がt0からt1に変更される構成までは図４，５における動作と同一である。
【００６９】
図６の実施例においては、タイマＴＭＲからのタイマイベントの発行は測定データの受信と同期して起こるように、その発行タイミングをデータ受信時刻から初期設定の“データ送信間隔”後とするようにタイマの動作間隔を予め設定する。ただし、センサノードの測定間隔（あるいは，データ送信間隔）を延ばすようにｔ0からｔ１（t0<t1）に変更されても、タイマＴＭＲの設定は変更されない。そのため、センサノードＳＮｘが動作間隔を変更した以降の測定データのうちd15が何らかの不具合で基地局ＧＷまで届かなかった場合，最初のタイマイベントでは無駄な障害判定を実行することになり、その次のタイマイベントが発生するまで障害判定が実施されない。すなわち，図６の場合，障害検出に遅延時間が発生してしまう。さらに，検出遅延は管理クライアントＳＮＭＣに対する通知遅延，場合によっては対策遅延を生じさせることにもつながる。
【００７０】
図７は，センサノードＳＮｘの動作間隔（“データ送信間隔”）をt0からt1（但し，t0<t1）に変更するシナリオにおいて，本発明を適用してタイマ設定まで変更した場合のシステム全体の大まかな動作シーケンスを示している。本実施例では，イベント処理部ＥＶＥに「センサノードＳＮｘからのデータ送信間隔が変更されたら，それと同じ時間間隔でタイマイベントが発行されるようにタイマＴＭＲを設定変更する」ように予め規則が設定されている。図７に示すように，図６と同様にタイマＴＭＲからのタイマイベントの発行は測定データの受信と同期して起こるようにタイマを設定する。
【００７１】
図７に示す通り，本発明を適用することにより，イベント処理部ＥＶＥはセンサノードＳＮｘに対する送信間隔変更コマンド完了通知（イベント）を受信すると，センサネットコマンド管理部ＣＭＭにその完了通知を転送するとともに、構成管理部ＣＦＭが構成管理情報として管理している動作パラメータであるセンサノードＳＮｘの“データ送信間隔”の値をt0からt1に変更する。さらに、イベント処理部ＥＶＥは、タイマＴＭＲに対して，タイマイベント発行間隔を予め定められた規則に従って決定した時間間隔に再設定する（c11）。図７の例では，タイマ間隔をデータ送信間隔と同じ間隔とするという規則に従い，データを受信した時刻を基点として，センサノードＳＮｘに対して新たに設定した送信間隔t1と同じ間隔でタイマイベントを発行するようにタイマＴＭＲを再設定している。図７に示しているように，本発明を適用することによって，障害の検出遅延の発生が抑えられるようになる。
【００７２】
したがって，本発明を適用し，障害検出判定処理の駆動タイミングを動的に調整することにより，測定データの送信間隔が動的に変わる場合でも，効率的な障害検出が可能となる。また，本発明の規則は，センサノード毎に固有の定数などは含まず送信間隔のような変数あるいは属性の種類として定義されているので，センサノード毎に個別の設定は不要であり，全てあるいは複数のセンサノードに同時に適用できるために設定の手間も非常に少ないというメリットがある。
【００７３】
＜図８の説明＞
図８は，図７の場合と同様にデータ受信同期型タイマを使用したシステムにおいて，センサノードＳＮｘの動作間隔（測定データ送信間隔）をt0からt1（但し，t0<t1）に変更しようとしたが，動作間隔変更コマンドを基地局ＧＷで一時保存している間に，測定データ（ｄ２３）が基地局ＧＷまで届かず，一時保存していたコマンドをセンサノードまで届けることができない場合をシーケンス図で示している。
【００７４】
図８では，送信間隔変更のコマンドを受け付けた後の測定データ（図８内のｄ２３）が届いていないケースを一例として示している。イベント処理部ＥＶＥにおける障害判定処理でセンサノードの障害が検出されている。その障害検出結果を受けて構成管理部ＣＦＭ内で対応するセンサノードの管理項目“稼働状態”を「障害」に更新している。また，障害検出結果はセンサネットコマンド管理部ＣＭＭにも転送される。
【００７５】
センサネットコマンド管理部ＣＭＭでは，どこからの要求により，どのセンサノードに対して，どういうコマンドを発行しているかという情報を保持している。したがって，構成管理部ＣＦＭから障害通知を受けると，センサネットコマンド管理部ＣＭＭは，該当する「障害」という“稼動状態”になったセンサノードに向けて，基地局経由で送信間隔変更コマンドが発行されていることを判定でき，発行済みの送信間隔変更コマンドを取り消す処理を基地局ＧＷに送信している。このとき基地局ＧＷは一時的に保持していた送信間隔変更コマンドを廃棄する。
【００７６】
また，センサネットコマンド管理部ＣＭＭは、要求管理部ＳＳＭ（センサネットコマンド管理部ＣＭから見たコマンド実行の直接の要求元）に対して，コマンド実行結果を失敗である旨を通知する。さらに要求管理部ＳＳＭは，管理クライアントＳＮＭＣに対してはコマンド実行に失敗した旨の通知を行っている。要求管理部ＳＳＭは，管理クライアントＳＮＭＣに相当するクライアントが複数ある場合にもその要求の要求元を管理している。
【００７７】
また少し異なるケースとして，図示はしていないが，センサネットコマンド管理部ＣＭＭが送信間隔変更コマンドを受けた際に，構成管理部ＣＦＭに問い合わせて対象となるセンサノードの“稼働状態”が既に「障害」状態になっている場合には，基地局ＧＷ経由でセンサノードにコマンドを転送することはせずに，要求管理部ＳＳＭに対して，「障害発生中につきコマンド実行できない」旨を返信する。その結果，要求管理部ＳＳＭは，要求管理クライアントＳＮＭＣに対してコマンド要求に対する応答として，同様に「障害発生中につきコマンド実行できない」旨を通知するようにする。
【００７８】
また，センサノードが自律的に“データ送信間隔”を変更する機能を持っている場合には，データ送信間隔を変更したことを通知するイベントを送信するようにしても良い。その変更通知イベントを，送信間隔変更コマンド完了通知と同様に処理することで，センサノードの自律的なデータ送信間隔変更にも対応して，障害判定処理の実行タイミングを調整できる。
【００７９】
ここで、センサノードＳＮｘにおける動作間隔変更コマンドの結果通知が，あるいは，自律的にデータ送信間隔を変更したセンサノードからのデータ送信間隔変更通知イベントが，何らかの不具合でセンサネット管理サーバＳＮＭＳまで伝達されない場合が起こり得る。発生する確率は低いが，このような場合はセンサノードの動作間隔変更がセンサネット管理サーバＳＮＭＳでは全く確認できない。このような場合は、例えば、センサネット管理サーバＳＮＭＳ内で、構成管理部ＣＦＭが該当するセンサノードＳＮｘから送信されてくるなるべく連続した２つ以上のデータ及びそれらのデータ受信時刻を保持し、かつ、それらの情報からデータの受信間隔を計算する機能を持つことにより、センサノードＳＮｘの変更後の動作間隔を推定することができる。その結果を前記障害判定処理の実行タイミングの再設定に用いることで、障害判定処理を効率良く実行するように維持することができる。
【００８０】
次に，特定のセンサノードで取得する測定データの測定頻度，すなわち，送信頻度を動的に変更するアプリケーションについて，３つの具体例を挙げて説明する。
【００８１】
第１の例は空調制御の応用例である。温湿度センサを搭載したセンサノードで室内の温湿度を監視して空調制御を行うことができる。例えば，センサノードに人感センサも搭載し，温湿度と同時に人が室内にいるかどうかをモニタし，室内に人が居ない時間帯（例えば，夜間）は，温湿度測定及びそのデータ送信の頻度を少なく（例えば５分に１回）し，部屋に人が居る時間帯（昼間）には，温湿度の測定及びそのデータ送信頻度を増やす（例えば１分に１回）ことが考えられる。昼間は単に空調サービスを受ける人がいるかいないかだけでなく，無線通信にとって人が遮蔽物になる確率が高くなるので，無線通信の品質を維持するためにも昼間はアプリケーションが要求する頻度よりも温湿度データの送信頻度を高く，すなわちセンサノードの動作間隔を短くすることにより無線通信の信頼性を確保する効果もある。具体的には，センサネット管理サーバのイベント処理エンジンＥＶＥが受信する人感センサの情報が所定値を超えるかどうかの判断を行い、その判断結果に基づいて，必要に応じて各センサノードに温湿度データの送信間隔を変更させるコマンドを出力する。
【００８２】
第２の例は火災監視システムである。建物内に人が居ないときは，温度監視を緩め（長めの測定周期）にする。温度監視頻度を抑えることによって電池寿命も伸ばせる。例えば，温度は５分間隔でモニタし，障害検出の許容遅延時間を最大５分（すなわち障害判定処理の実行間隔）とする。一方，建物内に人がいるときは，人命にも関わるので，温度監視及びシステム障害監視を厳しく実行する。例えば，温度は３０秒間隔でモニタし，障害検出の許容遅延時間は最大１０秒（できるだけ早く）とする。なお第１の例と同様に，建物内に人が居るか居ないかは人感センサを用い，その人感センサからの情報に基づいて温度データを送信する間隔を制御するのはセンサネット管理サーバである。
【００８３】
第３の例は健康モニタリングシステムである。脈拍や体温などが正常なときは，脈拍など各種生体情報のモニタリング間隔及び障害監視の最大許容遅延時間を緩めに設定して，電池寿命も伸ばす。一方，脈拍などで異常を検出したときは，観測精度を上げるために，脈拍など生体情報の監視頻度を上げ，それに伴いセンサノードの障害監視の最大許容遅延時間も短く設定する。この例でも監視頻度（測定間隔）の変更制御はセンサネット管理サーバの機能として実現されるが，この例の場合は特に新たなセンサを追加せずに，測定対象としている脈拍などの生体情報が異常値を示しているか否かで測定間隔すなわちデータ送信間隔の変更タイミングを判断することができる。
【００８４】
上記３例のように，時間帯や状況に応じて測定データの送信頻度を動的に変更したい場合があり，そのような場合，障害監視の精度（障害検出の許容遅延時間）も送信間隔に合わせて緩めたり，厳しくしたりすることが必要である。
【００８５】
以上のように，センサネット応用システムでは，測定データの送信頻度の値は様々な要求に従い変更されることが想定される。センサノードから定期的に送信される信号（温度などの測定データを含む）の有無の傾向に基づいて，その信号をハートビート信号と見做して，センサノード生死判定（通信可否判定）を行っているので，間隔が変更する点を考慮してハートビート信号を監視することはセンサネットシステム特有の新しい観点であり，センサネットシステム監視上の新しい課題であると言える。
【００８６】
（遠隔運用監視サービス）
また，以上のようなシステムの運用，監視，保守サービスを第３者が行う場合には，電池交換などの保守作業をなるべく抑えつつ，顧客に対して質の高いサービスを提供することも可能となる。例えば，図１において，有線ネットワークＷＤＮはインターネット，あるいは，何らかの専用線を使ったネットワークである場合，ユーザ端末ＵＳＴはセンサネットシステムから地理的に遠く離れた例えば監視サービスセンタの中に置かれた計算機と見做すことができる。そして，ユーザ端末ＵＳＴ内のセンサネット管理クライアントＳＮＭＣを遠隔地で操作することによって，本発明に含まれるセンサノード毎の測定データ送信間隔の変更などを遠隔サービスとして実施することも容易に実現できる。
【産業上の利用可能性】
【００８７】
以上のように、本発明は様々な種類のセンサノードを含むセンサネットシステム，及びその運用保守管理サービスに適用することができる。
【図面の簡単な説明】
【００８８】
【図１】本発明の第１の実施形態を示すセンサネットシステムのブロック図。
【図２】データ受信非同期型タイマを利用した場合の測定データ不達の障害監視シーケンス図。
【図３】データ受信同期型タイマを利用した場合の測定データ不達の障害監視シーケンス図。
【図４】送信間隔変更要求を伴うシナリオにおいて，データ受信非同期型タイマを利用した上で本発明を適用せずに障害監視に不具合が生じた場合のシーケンス図。
【図５】送信間隔変更要求を伴うシナリオにおいて，データ受信非同期型タイマを利用した上で本発明を適用して障害監視の不具合を抑えた場合のシーケンス図。
【図６】送信間隔変更要求を伴うシナリオにおいて，データ受信同期型タイマを利用した上で本発明を適用せずに障害監視に不具合が生じる別の場合のシーケンス図。
【図７】送信間隔変更要求を伴うシナリオにおいて，データ受信同期型タイマを利用した上で本発明を適用して障害監視を適切に実施した別の場合のシーケンス図。
【図８】送信間隔変更要求がセンサノードまで伝達されなかった場合のシーケンス図。
【図９】構成管理データを示すテーブルの例。
【符号の説明】
【００８９】
ＳＮ１〜ＳＮｎ  センサノード
ＧＷ１〜ＧＷｍ  基地局
ＳＮＭＳ  センサネット管理サーバ
ＷＤＮ  有線ネットワーク
ＷＬＮ  無線ネットワーク
ＲＦＣ  無線回路
ＰＷＲ  電源
ＣＰＵ  マイコン
ＳＤＥＶ  センサデバイス
ＡＤＥＶ  アクチュエータデバイス
ＲＦＣＴＬ  センサノード上の無線通信制御部
ＰＷＣＴＬ  センサノード上の電源制御部
ＭＣＴＬ  センサノード上の動作制御部
ＳＣＴＬ  センサノード上のセンサ制御部
ＡＣＴＬ  センサノード上のアクチュエータ制御部
ＵＰＣ  基地局上の上りパケット変換部
ＤＰＣ  基地局上の下りパケット変換部
ＧＩＤＭ  基地局上のＩＤ管理部
ＧＣＭＭ  基地局上のコマンド管理部
ＧＲＦＣ  基地局上の無線通信制御部
ＧＮＩＣ  基地局上の有線通信制御部
ＳＳＭ  センサネット管理サーバ上のセッション管理部
ＥＶＥ  センサネット管理サーバ上のイベント処理エンジン
ＳＣＭ  センサネット管理サーバ上のセッション管理部
ＥＸＴＩＦ  センサネット管理サーバ上の外部装置連携アダプタ
ＴＭＲ  センサネット管理サーバ上のタイマ
ＣＭＭ  センサネット管理サーバ上のセンサネットコマンド管理部
ＣＦＭ  センサネット管理サーバ上のセンサネット構成管理部
ＤＢＭＳ  センサネット管理サーバ上のデータベース管理部
ＳＮＩＣ  センサネット管理サーバ上の（有線）通信制御部。
【図９】
2008015722.tif 000003
【図１】
2008015722.tif 000004
【図２】
2008015722.tif 000005
【図３】
2008015722.tif 000006
【図４】
2008015722.tif 000007
【図５】
2008015722.tif 000008
【図６】
2008015722.tif 000009
【図７】
2008015722.tif 000010
【図８】
2008015722.tif 000011