JP6851952B2 - データ収集装置及びデータ収集方法 - Google Patents

Description

本発明は、データ収集装置に関する。

近年、工場設備や機器からデータを収集し、収集したデータに基づいて設備や機器を遠隔から監視したり、制御したりするシステムが提供されている。このようなシステムでは、工場設備や機器からのデータを無線通信を利用して定期的に及びオンデマンドにデータを取得する。

本技術分野の背景技術として、以下の先行技術がある。特許文献１（特開２０１５−３２０８６号公報）には、スマートフォン等のアプリ実行機能を有する端末であって、操作ログやセンサログを収集するログ収集手段と、収集したログを分析し、周辺状況あるいはユーザの利用状況を推定する状況推定手段と、推定した結果を、すべてのユーザで共通のシンボルである複数種類の状況データとして任意のアプリに出力する状況出力手段と、を備え、ログ収集手段は、状況推定手段以外からのアクセスを拒絶する端末が記載されている。

また、特許文献２（特開２０１６−１５２６１１号公報）では、データ収集装置であって、データ収集部により出力された要求フレームの履歴に基づいて、スケジュール情報を生成するスケジュール情報生成部、スケジュール情報を中継装置に向けて通信部から送信させるスケジュール情報送信部、要求フレームと応答フレームとの対応関係を示す対応関係情報を生成する対応関係情報生成部、スケジュール情報が中継装置に送信された後は、対応関係情報に基づいて、データ収集部により出力された要求フレームに対応する応答フレームを特定し、特定した応答フレームをデータ収集部に供給するフレーム処理部を有するデータ収集装置が記載されている。

特開２０１５−３２０８６号公報 特開２０１６−１５２６１１号公報

しかし、工場設備や機器からデータを取得するシステムでは、定期的にデータを収集する他に、オンデマンドで不定期にデータを収集することがあるが、前述した従来技術では、オンデマンドのデータ収集が考慮されておらず、それらによる通信負荷の増加が課題となる。

また、データ収集端末からポーリング方式でデータを収集する際、一回のデータ取得要求によって大きなデータを収集することがあり、応答パケットの大きさを考慮した通信負荷が平準化されていない。

無線ネットワーク、特に無線マルチホップネットワークにおいて、安定した通信を継続するためには、過大な通信負荷を避けて、一定の負荷を維持することが重要である。従って、無線マルチホップネットワークにおいて、高効率かつ高確率でデータを収集するためには、オンデマンド通信、定期通信、大容量通信の発生を考慮して通信負荷を平準化する必要がある。

本発明は、定期通信、オンデマンド通信、大容量通信などの発生を考慮して通信スケジュールを調整し、無線マルチホップネットワークを安定的に稼動させて、高効率かつ高確率でデータ収集をするデータ収集装置を提案する。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、通信路を介して接続される端末装置からデータを収集するデータ収集装置であって、管理されたタイミングデータに従って、前記端末装置にデータ取得要求を送信するスケジュールを決定するスケジュール管理部と、前記データ取得要求の送信量を調整する送信量調整部と、前記端末装置から収集したデータを管理する収集データ管理部と、を備え、前記スケジュール管理部は、前記各端末装置からのデータ収集を開始する時刻である起点時刻、前記各端末装置からのデータ収集の間隔である収集周期、前記端末装置からのデータ収集が失敗したときにデータ取得要求を再送するまでの時間である再送間隔、及び、前記データ取得要求を再送する回数である再送回数を、前記タイミングデータとして管理するものであって、前記データ取得要求の宛先となる端末装置を二つ選択し、前記選択された端末装置のデータ取得要求の順序を入れ替えることによって、データ取得要求の送信スケジュールを変更し、前記変更後の送信スケジュールにおいて、前記通信路のトラフィックが平準化されているかを評価し、前記通信路のトラフィックが所定の平準化条件を満たさない場合、さらに、前記選択された端末装置と少なくとも一方が異なる端末装置を二つ選択して、データ取得要求の順序を入れ替える。

本発明の一態様によれば、複数要件からなるデータ収集を考慮し、通信負荷を平準化できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

実施例１のデータ収集システムの構成を示す図である。 データ収集装置の機能構成を示す図である。 要求送信順序決定部の構成を示す図である。 スケジュール情報設定画面の構成を示す図である。 スケジュール情報管理テーブルの構成例を示す図である。 デバイス情報管理テーブルの構成例を示す図である。 無線情報管理テーブルの構成例を示す図である。 実施例１のスケジュール調整処理のフローチャートである。 送信量調整のフローチャートである。 実施例２のスケジュール調整処理のフローチャートである。 実施例３のスケジュール調整処理のフローチャートである。

以下図面を参照して、本発明の実施例を詳述する。

＜実施例１＞
図１は、実施例１のデータ収集システムの構成を示す図である。

本実施例のデータ収集システムは、データ収集装置１０１と、複数のサービス装置２（１０４（Ａ）、１０４（Ｂ）、……）と、複数のセンサ装置１０２（１０２（Ａ）、１０２（Ｂ）、……）とを有する。複数のサービス装置２（１０４（Ａ）、１０４（Ｂ）、……）は、ネットワーク等の通信路１０５を介してデータ収集装置１０１に接続され、データ収集装置１０１が無線ネットワーク（無線マルチホップネットワーク）の通信路１０３を介して複数のセンサ装置１０２（１０２（Ａ）、１０２（Ｂ）、……）と接続される。

サービス装置２は、各センサ装置１０２から収集される現場データを利用したサービスをユーザに提供するアプリケーションプログラム（以下、サービスアプリと称する）１４１が実装されたサーバ装置であり、サービス毎に用意される。サービス装置２は、必要な測定データ（環境情報、設備情報など）を、データ収集装置１０１を介してセンサ装置１０２から取得する。

センサ装置１０２は、測定対象（監視対象の装置や環境）から測定データを取得し、取得した現場データをデータ収集装置１０１に送信する端末装置であり、測定対象毎に設けられる。センサ装置１０２は、取得する現場データの種類に応じて種々の構成である。例えば、測定対象の温度センサを計測する温度計測装置、監視対象の装置の映像を取得するカメラ装置、監視対象の環境の音（ノイズ）などを収集する音響センサ装置などである。それら各センサに対応するセンシング方法やセンシングタイミングなどの各種設定がセンサ装置１０２内のＲＡＭ１２６やＲＯＭ１２５で管理される。ＣＰＵ１２３は、ＲＯＭ１２５に格納されたセンサプログラム１２４を実行する。センサ装置１０２が有するセンサ１２２が取得した測定データは、通信インターフェース１２１から無線通信路１０３に送信され、データ収集装置１０１に集約される。センサ装置１０２のＣＰＵ１２３は、センサ装置１０２全体の動作を制御するプロセッサである。ＲＡＭ１２６は、ＣＰＵ１２３のワークメモリとして利用され、ＲＯＭ１２５は、主としてプログラムを格納するために利用される。なお、ＣＰＵ１２３がプログラムを実行して行う処理の一部をハードウェア（例えば、ＦＰＧＡ）で行ってもよい。

データ収集装置１０１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、不揮発性ストレージ１１４、通信インターフェース１１５、操作部１１６及び表示部１１７を有する計算機である。ＣＰＵ１１１は、データ収集装置１０１におけるデータ取得要求の送信やデータ受信時の各種処理を実行する演算装置である。なお、ＣＰＵ１１１が実行する機能の一部をハードウェアによる演算装置（例えば、ＦＰＧＡ）に実行させてもよい。ＲＡＭ１１２は、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、ＣＰＵ１１１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。ＲＯＭ１１３は、不揮発性の記憶素子であり、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。

不揮発性ストレージ１１４は、例えば、ハードディスク装置、不揮発性半導体記憶装置（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、不揮発性メモリなどの不揮発性の記憶媒体から構成され、アプリケーションやデータなどを長期間保持するために利用される。不揮発性ストレージ１１４には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や各種パラメータの他、データ収集装置１０１を機能させるための各種プログラムが格納される。すなわち、プログラムは、不揮発性ストレージ１１４から読み出されて、ＲＡＭ１１２にロードされて、ＣＰＵ１１１によって実行される。

通信インターフェース１１５は、通信路１０５や通信路１０３を介する通信時におけるプロトコル制御を行う装置であり、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）などである。操作部１１６は、例えば、キーボードやマウスなどから構成され、ユーザが各種操作や指令を入力するために用いられる。表示部１１７は、例えば、液晶ディスプレイ表示装置などから構成され、必要な画面や各種処理の結果を表示する。後述するデバイス情報管理テーブル２０４、スケジュール情報管理テーブル２０５、無線情報管理テーブル２１３は、ＲＡＭ１１２や不揮発性ストレージ１１４に格納されて保持される。

ＣＰＵ１１１が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介してデータ収集装置１０１に提供され、非一時的記憶媒体である不揮発性ストレージ１１４に格納される。このため、データ収集装置１０１は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

データ収集装置１０１は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

図２は、データ収集装置１０１の機能構成を示す図である。

本実施例のデータ収集システムでは、システム管理者が、各センサ装置１０２より収集される現場データ毎に、データを収集開始する時刻（起点時刻）、収集間隔、収集失敗時の再取得要求の間隔や回数などのスケジュール情報をスケジュール管理部２０２のスケジュール２０５に予め登録する。また、システム管理者は、各種センサ装置１０２が有するセンサ１２２の種類などの情報をデバイス情報２０４に予め登録する。

さらに、データ収集装置１０１とセンサ装置１０２との間の無線マルチホップネットワークの品質情報などを無線情報管理部２１２がリアルタイムに収集し、無線情報２１３に格納して保持する。例えば、各センサ装置１０２のネットワーク内の位置であるホップ数や通信成功確率などを無線情報管理部２１２が収集する。

データ収集装置１０１は、上記のように事前に登録されたスケジュール２０５、デバイス情報２０４及び無線情報２１３を用いて、通信帯域を長期的に均一にするためのデータ取得順序をスケジュール管理部２０２の要求送信順序決定部２０３にて決定し、実行スケジュールとしてスケジュール２０５に登録する。当該実行スケジュールに従って、定期的・周期的なデータ取得を実行する。定期的・周期的なデータ取得の際は、データ取得要求送信量調整部２０６が、無線情報２１３及びデバイス情報２０４を参照してデータ取得要求間隔を調整しながら、データ取得要求を周期送信キュー２０７に格納し、無線通信処理部２０９を介してセンサ装置１０２に送信する。

各センサ装置１０２は、データ取得要求を受信すると、センサ１２２で測定した測定データを格納した応答パケットを返信する。データ収集装置１０１の無線通信処理部２０９は応答パケットを受信し、収集データ管理部２１０に送る。

収集データ管理部２１０は、各センサ装置１０２から収集した無線パケットのペイロード部分を解析して、測定データを取り出し、収集データ２１１に格納する。

また、サービス装置１０４（Ａ）又はサービス装置１０４（Ｂ）は情報設定画面２０１を介して、オンデマンドでセンサ装置１０２（Ａ）・・・１０２（Ｅ）から不定期にデータ取得する要求を発生させることができる。例えば、周期的なスケジュールに加えて、現在のデータを取得したい場合などに、オンデマンドのデータ発生要求を利用する。このとき、情報設定画面２０１からデータ取得要求送信量調整部２０６にオンデマンドデータ取得要求を伝達し、データ取得要求送信量調整部２０６が、無線情報２１３及びデバイス情報２０４を参照してデータ取得要求間隔を調整しながら、オンデマンドデータ取得要求をオンデマンド送信キュー２０８に格納し、無線通信処理部２０９を介してセンサ装置１０２に送信する。オンデマンド送信キュー２０８は、周期送信キュー２０７より優先して無線通信処理部２０９にデータ取得要求を伝送する。

図３は、データ収集装置１０１内のスケジュール管理部２０２の要求送信順序決定部２０３の構成を示す図である。

要求送信順序決定部２０３は、システム管理者が予め入力した周期送信のスケジュール決定に必要な情報（周期送信を開始する起点時刻、収集間隔、再送間隔、再送回数など）を考慮して、デバイス情報２０４に登録されたすべてセンサ装置１０２に対するデータ取得要求順序を決定する。ここでは、同一時刻の起点時刻が設定されている場合は、無線ネットワークに加入した順、又はランダムに順序を選択するなどによって、仮の順序を決定する。

次に、順序入替端末抽出機能３０２が、前記初期順から順序入替可能なセンサ装置１０２を複数選択し、データ取得順序を入れ替える。このとき、再送時刻再割当機能３０３と連動して、１回目のデータ取得要求、及びその要求が失敗した場合の再送のデータ取得要求の順序を入れ替える。

例えば、起点時刻０時０分、収集間隔が１５分のセンサ装置（Ａ）のスケジュールと、起点時刻０時０分、収集間隔が１０分のセンサ装置（Ｂ）のスケジュールとが予め入力、設定され、センサ装置（Ａ）に対して０時０分３０秒に１回目のデータ取得要求、０時５分３０秒に再送のデータ取得要求、センサ装置（Ｂ）に対して０時２分４５秒に１回目のデータ取得要求、０時６分に再送のデータ取得要求が初期順序として設定された場合、順序入替端末抽出機能３０２は、センサ装置（Ａ）とセンサ装置（Ｂ）とを選択し、再送時刻再割当機能３０３と連動し、センサ装置（Ａ）の１回目のデータ取得要求とセンサ装置（Ｂ）の再送のデータ取得要求の時刻を入れ替える。これにより、０時２分４５秒にセンサ装置（Ｂ）の１回目のデータ取得要求、０時６分３０秒にセンサ装置（Ａ）の１回目のデータ取得要求が再割り当てされ、その後、それぞれの収集間隔を考慮して、再送時刻が改めて設定される。例えば、０時５分３０秒にセンサ装置（Ｂ）の再送のデータ取得要求を、０時１０分１０秒にセンサ装置（Ａ）の再送のデータ取得要求を改めて割り当てる。

この再送割り当てができない場合は、前記順序入替えは不可能であり、前記入れ替え前のスケジュールに戻す必要がある。再送割当て可否判定部３０４がこの判定を行う。このような順序入替えに関して、通信トラフィック評価機能３０５は、長期的なスケジュールにおいて、通信トラフィックの発生が均一化されたことを確認し、評価する。

図４は、スケジュール情報設定画面２０１の構成を示す図である。

情報設定画面（スケジュール情報登録・解除画面）２０１は、スケジュール２０５に登録された内容を表示し、スケジュール２０５を登録するため入力欄を含む。具体的には、情報設定画面２０１は、収集開始ボタン４０１、収集停止ボタン４０２、設定値リロードボタン４０３、スケジュール調整機能ボタン４０４、設定装置の選択ボックス４０５、無線接続状況表示部４０６、デバイスＩＤ表示部４０７、起点時刻入力・表示部４０８、データ収集周期入力・表示部４０９、再送間隔入力・表示部４１０、再送回数入力・表示部４１１及び関連性入力・表示部４１２を含む。

収集開始ボタン４０１は、スケジュールに従った周期収集の開始をデータ収集装置１０１に指示するためのボタンである。収集停止ボタン４０２は、前記周期収集の停止をデータ収集装置１０１に指示するためのボタンである。設定値リロードボタン４０３は、既に設定されている各センサ装置の周期収集のスケジュール２０５を読込み、起点時刻入力・表示部４０８、データ収集周期入力・表示部４０９、再送間隔入力・表示部４１０、再送回数入力・表示部４１１及び関連性入力・表示部４１２の表示内容を更新するためのボタンである。スケジュール調整機能ボタン４０４は、センサ装置１０２のデータ取得要求送信順序の初期順序に対し、通信トラフィックの均一化などを目的に順序入替えの実行を、要求送信順序決定部２０３に指示するためのボタンである。スケジュール調整機能ボタン４０４は、操作毎に、送信順序調整機能の有効／無効が切り替えられる。

設定装置の選択ボックス４０５は、予め入力された各センサ装置１０２の周期収集のスケジュール情報を変更する場合、又は、スケジュールが未入力のセンサ装置１０２にスケジュール情報を入力する場合、対象となるセンサ装置１０２を選択するためのチェックボックスである。個別のセンサ装置１０２にスケジュールを設定せず、全てのセンサ装置１０２に同一の起点時刻、データ収集周期、再送間隔、及び再送回数を設定する場合、一括設定の選択ボックス４０５（Ａ）を選択してもよい。

また、同一センサ装置に複数の起点時刻、データ収集周期を設定してもよい。システム管理者が、選択ボックス４０５によって追加のスケジュールを設定するセンサ装置１０２を選択し、スケジュール追加ボタン４１３を操作すると、スケジュールを入力する欄が増設され、既にデータ収集スケジュールが設定されているセンサ装置１０２の追加のスケジュールを入力できる。本実施例では、１台のセンサ装置１０２に複数の起点時刻や周期のスケジュール設定できるので、データ収集スケジュールを柔軟に設定できる。例えば不定間隔でデータを収集できる。また、一つのセンサ装置１０２を複数の用途（サービスアプリ１４１）で共用でき、設置されるセンサ装置１０２の数の増加を抑制できる。

無線接続状況表示部４０６は、現在の無線ネットワークに既に加入し、接続状態にある、加入待ちのため未加入、又は加入後に無線状況が悪化して切断状態にあるなど、各センサ装置１０２の無線ネットワークの接続状況を表示する領域である。

デバイスＩＤ表示部４０７は、スケジュール情報の登録・解除を実施するセンサ装置１０２を識別するための識別情報（デバイスＩＤ）を表示する領域である。デバイスＩＤはシステム内で重複することなく一意に定められたものでも、グローバルに一意に定められたものでもよい。例えば、無線通信のために割り当てられたＭＡＣアドレスを利用してもよい。

起点時刻入力・表示部４０８は、センサ装置１０２に対して、周期的なデータ収集を開始したい時刻を入力、表示する領域であり、本例では、時、分が設定可能である。データ収集周期入力・表示部４０９は、周期収集を実行する時間間隔を入力、表示する領域である。例えば、サービスアプリ１４１が、あるセンサ装置１０２に毎朝８時の温度のモニタリングをさせたい場合、起点時刻に８時０分、データ収集周期に２４時００分を設定するとよい。また、本システムでは、無線ネットワークの利用を想定しているため、必ずしもデータ収集が成功するとは限らない。従って、データ収集の失敗を考慮して、再送間隔入力・表示部４１０に再送間隔を入力、表示でき、再送回数入力・表示部４１１に再送回数を入力、表示できる。再送回数及び再送間隔は、サービスアプリ１４１のデータ取得要求に対するレスポンス時間や必要度合いに応じて、サービスアプリ１４１やシステム管理者が設定する。

関連性入力・表示部４１２は、複数のセンサ装置１０２から連続的にデータを収集したい場合に、当該センサ装置１０２のグループを設定するための領域である。例えば、あるサービスアプリ１４１では、センサ装置１０２（Ａ）とセンサ装置１０２（Ｂ）からの情報の両方を利用する。例えば、Ｘ軸にセンサ装置１０２（Ａ）の値と、Ｙ軸にセンサ装置１０２（Ｂ）の値とを設定したグラフに表す場合などである。

図５は、スケジュール情報管理テーブル２０５の構成例を示す図である。

前述したように、データ収集装置１０１では、システム管理者、サービスアプリ１４１、又は本データ収集システムの外部に接続されたシステム（当該外部システムで動作するシステム管理プログラム）などがスケジュール情報を入力、設定した際、スケジュール管理部２０２がスケジュール２０５に情報を登録する。スケジュール情報管理テーブル２０５は、データ収集装置１０１から各センサ装置１０２へのデータ収集スケジュールを管理するためのテーブルであり、デバイスＩＤ欄５０１、起点時刻欄５０２、収集周期欄５０３、再送間隔欄５０４、再送回数欄５０５、関連Ｇｒ欄５０６及び次回送信欄５０７を含む。

デバイスＩＤ欄５０１は、データ収集スケジュールが管理されるセンサ装置１０２の識別情報を格納する。デバイスＩＤ欄５０１に格納されたデータは、情報設定画面２０１のデバイスＩＤ表示部４０７に表示される。

起点時刻欄５０２は、情報設定画面２０１の起点時刻入力・表示部４０８に入力された情報を格納する。収集周期欄５０３は、情報設定画面２０１のデータ収集周期入力・表示部４０９に入力された情報を格納する。再送間隔欄５０４は、情報設定画面２０１の再送間隔入力・表示部４１０に入力された情報を格納する。再送回数欄５０５は、情報設定画面２０１の再送回数入力・表示部４１１に入力された情報を格納する。関連Ｇｒ欄５０６は、情報設定画面２０１の関連性入力・表示部４１２に入力された情報を格納する。

次回送信欄５０７は、スケジュール調整によって決定された順序に従った、次回のデータ取得要求時刻を格納する。この次回送信時刻は、１回目のデータ取得要求と再送のデータ取得要求とを区別せずにデータ取得要求を実施すべき時刻を格納する。従って、１回目のデータ取得を実施する際には、再送予定時刻が次回送信欄５０７に格納され、センサ装置１０２からのデータ取得が成功した場合、データ収集周期から計算された次の１回目のデータ取得要求時刻に更新される。

例えば、スケジュール情報管理テーブル２０５の行５１０には、デバイスＩＤ「ＡＡ−ＢＢ−１１」のセンサ装置１０２について、起点時刻が８時０分、周期が２４時間、再送間隔が５分、再送回数が３回、関連Ｇｒが１、次回送信が８時０分６秒としたスケジュールが登録されている。また、前述のように、本発明では、同一センサ装置に対して、複数の周期を設定可能であり、行５１１には、行５１０と同一のデバイスＩＤ「ＡＡ−ＢＢ−１１」のセンサ装置１０２について、起点時刻が１７時０分、周期が２４時間、再送間隔が５分、再送回数が３回、関連Ｇｒが２、次回送信が１７時０分２０秒としたスケジュールが登録されている。さらに、行５１２には、デバイスＩＤ「ＡＡ−ＢＢ−２２」のセンサ装置１０２について、起点時刻が８時０分、周期が１時間、再送間隔が１０分、再送回数が１回、関連Ｇｒが１、次回送信が８時０分８秒としたスケジュールが登録されている。このとき、行５１０と行５１２は同一の関連Ｇｒとして登録されており、８時に収集するデータに関しては、連続的にスケジューリングされる。一方で、行５１２のスケジュールは１時間周期であり、行５１０のスケジュールは２４時間周期であるため、両スケジュールのデータ取得要求時刻が一致しない時刻（９時、１０時など）には、関連Ｇｒを考慮しないデータ取得要求スケジュールとなる。

図６は、デバイス情報管理テーブル２０４の構成例を示す図である。

デバイス情報管理テーブル２０４は、センサ装置１０２の種類など、センサ装置１０２に固有の情報を管理するためのテーブルであり、デバイスＩＤ欄６０１、センサ種類欄６０２及びデータ長欄６０３を含む。デバイス情報管理テーブル２０４は システム管理者、システム管理プログラム、又はサービスアプリ１４１などによって登録される。

例えば、行６１０には、デバイスＩＤ「ＡＡ−ＢＢ−１１」のセンサ装置１０２はは温度計であり、計測データを含めて３０Ｂのデータ長のデータがセンサ装置１０２からデータ収集装置１０１に送信されること示されている。

図７は、無線情報管理テーブル２１３の構成例を示す図である。

無線情報管理テーブル２１３は、データ収集装置１０１が、無線通信処理部２０９を介して収集した無線ネットワークの構成や通信品質などの情報を無線情報管理部２１２で管理するためのテーブルである。無線情報管理テーブル２１３は、デバイスＩＤ欄７０１、通信品質欄７０２及びホップ数欄７０３を含む。図示した例では、通信品質欄７０２は通信成功確率７０２（Ａ）及び通信遅延７０２（Ｂ）を含むが、これらの一部でもよく、また、他の情報を含んでもよい。例えば、無線ネットワークから受信電波強度や近隣のセンサ装置１０２の数などが取得できる場合は、それら情報を合わせて管理してもよい。

例えば、行７１０には、デバイスＩＤ「ＡＡ−ＢＢ−１１」のセンサ装置１０２は、データ収集装置１０１から１段の中継装置を経由して、２ホップ先に位置した場所でネットワークに加入しており、通信遅延の実績値が平均１．１秒、データ収集装置１０１がデータ取得要求を送信して１回でデータ取得できる確率が７５％であることが示されている。

次に、図８、図９を用いて、第一の実施例において、スケジュール管理部２０２が実行するスケジュール調整処理８０１、及び、データ取得要求送信量調整部２０６が実行する送信量調整処理９０１を説明する。

データ収集装置１０１で、データ取得要求のためのスケジュールが情報設定画面２０１に入力され、収集開始ボタン４０１が操作されると、スケジュール管理部２０２の要求送信順序決定部２０３が、各センサ装置１０２へ送信するデータ取得要求について図８に示すスケジュール調整処理８０１を実行し、データ取得要求のスケジュールを決定する。

まず、ステップ８０２において、要求送信順序決定部２０３（初期順序決定部３０１）は、スケジュール情報管理テーブル２０５に格納された全データを読み出し、起点時刻、収集間隔、再送回数、及び再送間隔に基づいて、データ取得要求の送信先となるセンサ装置１０２の順序を決定する。ステップ８０２で決定される初期順序は、無線ネットワークに加入した順やランダムに並べた順序など任意の順序を採用でき、必ずしもスケジュール全体で通信トラフィックが均一化や、平準化されていなくてもよい。このとき、データ取得要求に対する応答パケットの遅延時間を考慮した時間間隔でセンサ装置１０２を並べると、データ取得要求と応答パケットとの衝突や、応答パケット同士の衝突を回避できる。

次に、ステップ８０３において、送信順序調整機能が有効か、無効かを判定する。具体的には、情報設定画面２０１のスケジュール調整機能ボタン４０４の操作によって、送信順序調整機能の有効に切り替えられているか否かで判定可能である。送信順序調整機能が有効である場合はステップ８０４に進みスケジュールの調整を実施し、有効でない場合はステップ８０９に進みスケジュール調整を終了する。

ステップ８０４において、順序入替端末抽出機能３０２が、前記初期順序から順序を入替可能なセンサ装置１０２を複数（少なくとも二つ以上）選択し、ステップ８０５に進む。入替候補のセンサ装置１０２の選択は、ランダム、ネットワーク加入順など任意の順序を採用できる。

なお、順序入替端末抽出機能３０２が順序を入れ替えるセンサ装置１０２を抽出する際、無線情報２１３を考慮してもよい。例えば、ホップ数が大きいセンサ装置１０２とホップ数が小さいセンサ装置１０２とが交互に並ぶように、データ取得要求の送信順序を入れ替えることによって、１回のデータ取得要求に必要な実際の無線通信回数（ホップ数）を時間的な観点で平準化できる。

ステップ８０５において、再送時刻再割当機能３０３が、データ取得順序を入れ替え、ステップ８０６において、再送時刻再割当機能３０３が、データ取得要求の送信スケジュールを変更する。このとき、１回目のデータ取得要求及び当該要求が失敗した場合の再送を含めて順序を入れ替えて、ステップ８０７に進む。ただし、前記選択した入れ替え候補において、再送割当て可否判定部３０４が、システム管理者、システム管理プログラム、サービスアプリ１４１などによって予め設定されたスケジュール情報管理テーブル２０５の再送間隔や再送数などの条件を満たすかを判定し、条件を満たさない場合は、入れ替えを実施せず、ステップ８０７に進む。

ステップ８０７において、通信トラフィック評価機能３０５が、前記データ取得要求順序の入れ替えの結果を評価するため、評価結果を算出し、ステップ８０８に進む。例えば、所定時間（例えば、５分）間隔で要求送信数を算出し、各５分の中の要求送信数のばらつきの程度、５分ごとの要求送信数のばらつきの程度などを評価指標とする。

ステップ８０８において、通信トラフィック評価機能３０５は、算出された評価指標が予め決定した閾値に到達しているか否かを判定する。閾値を越えた場合はステップ８０９に進み、スケジュール調整処理を終了する。閾値より小さい場合はステップ８０４に戻り、ステップ８０４〜８０８の入替処理を繰り返し実行する。この閾値はシステムにおいてが予め定められたシステムパラメータであり、システム管理者、システム管理プログラム、サービスアプリ１４１などが予め決定しておくものである。

データ収集装置１０１では、スケジュール管理部２０２から周期的なデータ取得要求が発行された際、又は、サービスアプリ１４１やシステム管理者などからオンデマンドのデータ取得要求が発行された際、データ取得要求送信量調整部２０６が周期送信キュー２０７又はオンデマンド送信キュー２０８にデータ取得要求を格納する。データ取得要求送信量調整部２０６は、図９の送信量調整処理９０１を実行し、データ取得要求を格納するタイミングを、デバイス情報２０４及び無線情報２１３に基づいて調整する。

まず、送信量調整処理９０１を開始すると、ステップ９０２においてデータ取得要求を受け付けた直前及び直後の周期データ取得のスケジュールを確認する。本処理において、データ取得要求を受け付けたセンサ装置１０２の通信遅延を無線情報管理テーブル２１３から取得し、本処理を受け付けた後に通信遅延時間が経過するまでに送信が予定されている周期的なデータ取得要求の数、及び、送信済みのデータ取得要求に対して当該通信遅延時間が経過するまでに受信される応答パケットの数を算出し、ステップ９０３に進む。送信済みのデータ取得要求に対して当該通信遅延時間が経過するまでに受信される応答パケットの数を算出することによって、上りと下りの両方のトラフィックを考慮して、データ取得をスケジューリングできる。

ステップ９０３において、ステップ９０２で算出されたパケット数の通信トラフィック負荷が閾値を越えているか否かを判定する。ステップ９０３における通信トラフィックは、直前に受け付けたオンデマンドのデータ取得要求に対する応答パケットも考慮するとよい。例えば、オンデマンドのデータ取得要求に対する未受信の応答パケットの数を、前記周期的なデータ取得要求数に加算した値を通信トラフィック負荷とする。閾値以上であればステップ９０４に進み、閾値より小さければステップ９０５に進む。

ステップ９０４において、今回の送信量調整機能の開始がオンデマンドのデータ取得要求に起因する場合は、通信負荷をこれ以上増加させないため、オンデマンドのデータ取得要求を受付待ち状態に変更する。具体的には、オンデマンドのデータ取得要求が、オンデマンド送信キュー２０８に格納せずに、データ取得要求送信量調整部２０６に保持される。このとき、オンデマンドのデータ取得要求の要求元であるサービスアプリ１４１やシステム管理者に、オンデマンドのデータ取得要求のステータスを通知するとよい。データ取得要求のステータスは、送信待ち、送信済、受信完了を含むとよい。そして、ステップ９０２に進む。これにより、オンデマンドのデータ取得要求があっても、通信トラフィックの過度な増加を回避できる。

ステップ９０５において、今回の送信量調整機能の開始がオンデマンドのデータ取得要求に起因する場合は、該当要求を受け付け、ステップ９０６に進む。

ステップ９０６において、前記受け付けたオンデマンドのデータ取得要求をオンデマンド送信キュー２０８に格納する。この時、周期的なデータ取得要求の送信を実施している場合は、無線情報管理テーブル２１３から取得した通信遅延時間以上待機した後に、前記受け付けたオンデマンドのデータ取得要求をオンデマンド送信キュー２０８に格納する。周期的なデータ取得要求を送信を実施していない場合は、前記受け付けたオンデマンドのデータ取得要求を直ちにオンデマンド送信キュー２０８に格納し、ステップ９０７に進む。このように、通信遅延時間以上待機した後にオンデマンドのデータ取得要求をスケジューリングすることによって、周期的なデータ取得要求に対する応答パケットとの衝突を回避できる。

なお、データ取得要求をオンデマンド送信キュー２０８へ格納するタイミングによって、データ取得要求の送信量を制御するが、データ取得要求をオンデマンド送信キュー２０８から取り出すタイミングによって、データ取得要求の送信量を制御してもよい。

ステップ９０７において、デバイス情報管理テーブル２０４から、オンデマンドのデータ取得要求の送信先のセンサ装置１０２から受信するデータ長を取得し、前記オンデマンド取得要求に対する応答パケット数を算出し、ステップ９０８に進む。例えば、無線パケットのペイロード長が１００バイトであり、センサ装置１０２が送信するデータ長が２Ｋバイトである場合、少なくとも２０個の応答パケットを受信することになる。

ステップ９０８において、定期スケジュールのための送信間隔調整が必要か否かを判定する。ステップ９０７において、オンデマンドのデータ取得要求に対する応答パケットが多数ある場合はステップ９０９に進み、周期的なデータ取得要求の送信タイミングを調整する。一方、オンデマンドのデータ取得要求に対する応答パケットが多数ではない場合は、周期的なデータ取得要求の送信タイミングを調整しなくてもよいので、ステップ９１０に進み、送信量調整処理を終了する。

ステップ９０９において、周期送信キュー２０７に既に格納済みのデータ取得要求を取り出す間隔を調整する。データ取得要求の応答パケットが多くなると通信トラフィックが増加するため、データ収集装置１０１から送信される周期的なデータ取得要求の間隔を伸ばし、ステップ９１０に進む。本処理により、無線ネットワークにかかる通信トラフィック負荷を抑制できる。

以上のように、実施例１のデータ収集システムでは、サービスアプリ１４１やシステム管理者が設定した周期的なデータ取得スケジュールについて、データ収集装置１０１が、全てのセンサ装置１０２に対して送信される１回目と再送のデータ取得要求の順番を入れ替えることによって、長期的な観点において、データ収集装置１０１から発生するデータ取得要求を平準化でき、通信トラフィック負荷を平準化できる。また、通信トラフィックを考慮して、オンデマンドなデータ取得要求の数や送信間隔を調整することによって、通信トラフィックの急激な増加を抑制できる。これにより、無線マルチホップネットワークを安定的に稼動させることができる。

＜実施例２＞
前述した本発明の実施例１では、周期送信の順序入替処理において、サービスアプリ１４１によるデータの利用を考慮していなかった。例えば、あるサービスアプリ１４１が複数のセンサ装置１０２からのデータを同じタイミングに（具体的には連続して）取得し、同じタイミングに取得したデータを合わせて利用して、測定対象の稼動状況を判定する用途がある。この場合、通信トラフィックを平準化した後でも、これらの複数のセンサ装置１０２のデータ取得要求は時間的に連続して実施すべきである。よって、データ取得要求の順序を入れ替えると、特定のサービスアプリ１４１では正確なデータを取得できない不都合が生じることがある。このため、実施例２では、関連するセンサ装置群のデータ取得順序を考慮して、データ取得要求の順序を決定するデータ収集システムを説明する。

実施例２のシステム構成、データ収集装置１０１の構成、スケジュール管理部２０２の機能ブロック、情報設定画面２０１、各種情報管理テーブル２０４、２０５、２１１、２１３、及び、送信量調整処理９０１などは実施例１と同じであるため、これらの説明は省略し、図１０を用いて、実施例２のスケジュール調整処理を説明する。

図１０は、関連する複数のセンサ装置１０２からのデータ取得順序を考慮したスケジュール調整処理１００１のフローチャートである。

データ収集装置１０１で、データ取得要求のためのスケジュールが情報設定画面２０１に入力され、収集開始ボタン４０１が操作されると、スケジュール管理部２０２の要求送信順序決定部２０３が、各センサ装置１０２へ送信するデータ取得要求について図１０に示す処理を実行し、データ取得要求のスケジュールを決定する。

まず、ステップ１００２において、要求送信順序決定部２０３（初期順序決定部３０１）は、スケジュール情報管理テーブル２０５に格納された全データを読み出し、起点時刻、収集間隔、再送回数、再送間隔、及び関連Ｇｒに基づいて、データ取得要求の送信先となるセンサ装置１０２の順序を決定する。ステップ１００２で決定される初期順序は、無線ネットワークに加入した順やランダムに並べた順序など任意の順序を採用でき、必ず
しもスケジュール全体で通信トラフィックが均一化や、平準化されていなくてもよい。なお、実施例１で説明したと同様に、無線情報２１３を考慮した順序に（例えば、ホップ数が大きいセンサ装置１０２とホップ数が小さいセンサ装置１０２とが交互に）並べてもよい。実施例２では、同一の関連Ｇｒに属するセンサ装置１０２が連続して並ぶことを優先する。

次に、ステップ１００３において、送信順序調整機能が有効か、無効かを判定する。具体的には、情報設定画面２０１のスケジュール調整機能ボタン４０４の操作によって、送信順序調整機能の有効に切り替えられているか否かで判定可能である。送信順序調整機能が有効である場合はステップ１００４に進みスケジュールの調整を実施し、有効でない場合はステップ１０１１に進みスケジュール調整を終了する。

ステップ１００４において、順序入替端末抽出機能３０２が、前記初期順から順序を入替可能なセンサ装置１０２を複数（少なくとも二つ以上）選択し、ステップ１００５に進む。入替候補のセンサ装置１０２の選択は、ランダム、ネットワーク加入順など任意の方法を採用できる。なお、実施例１で説明したように、無線情報２１３を考慮して順序を入れ替えるセンサ装置１０２を抽出してもよい。

ステップ１００５において、ステップ１００４で抽出した入替候補のセンサ装置１０２と同一の関連Ｇｒに属するセンサ装置１０２があるか否かを確認する。同一の関連Ｇｒに属するセンサ装置１０２がある場合はステップ１００６に進み、同一の関連Ｇｒに属するセンサ装置１０２がない場合はステップ１００７に進む。

ステップ１００６において、同一の関連Ｇｒに属する複数のセンサ装置１０２へのデータ取得要求が連続してスケジューリングされるように、同一の関連Ｇｒに属する全てのセンサ装置１０２を選択し、ステップ１００７に進む。

ステップ１００７において、再送時刻再割当機能３０３が、データ取得順序を入れ替え、ステップ１００８において、再送時刻再割当機能３０３が、データ取得要求の送信スケジュールを変更する。このとき、１回目のデータ取得要求及び当該要求が失敗した場合の再送を含めて順序を入れ替えて、ステップ１００９に進む。ただし、前記選択した入れ替え候補において、再送割当て可否判定部３０４が、システム管理者、システム管理プログラム、サービスアプリ１４１などによって予め設定されたスケジュール情報管理テーブル２０５の再送間隔や再送数などの条件を満たすかを判定し、条件を満たさない場合は、入れ替えを実施せず、ステップ１００９に進む。

ステップ１００９において、通信トラフィック評価機能３０５が、前記データ取得要求順序の入れ替えの結果を評価するため、評価結果を算出し、ステップ１０１０に進む。例えば、所定時間（例えば、５分）間隔で要求送信数を算出し、各５分の中の要求送信数のばらつきの程度、５分ごとの要求送信数のばらつきの程度などを評価指標とする。

ステップ１０１０において、通信トラフィック評価機能３０５は、前記算出された評価指標が予め決定した閾値に到達しているか否かを判定する。閾値を越えた場合はステップ１０１１に進み、スケジュール調整処理を終了する。閾値より小さい場合はステップ１００４に戻り、ステップ１００４〜１０１０の入替処理を繰り返し実行する。この閾値はシステムにおいてが予め定められたシステムパラメータであり、システム管理者、システム管理プログラム、サービスアプリ１４１などが予め決定しておくものである。

以上のように、本実施例のデータ収集システムでは、前述した実施例の効果の他、サービスアプリ１４１やシステム管理者が設定した周期的なデータ取得スケジュールを変更しても、サービスアプリ１４１が合わせて利用したいデータをセンサ装置１０２から連続的に取得できるので、サービスアプリ１４１が必要とする同時性を考慮してデータを提供できる。

前述した実施例においては、情報設定画面２０１に入力された関連Ｇｒの情報によって関連するセンサ装置１０２を特定するが、センサ装置１０２間の関連性が特定できれば、関連性の特定は他の態様でもよい。

＜実施例３＞
前述した実施例１、２では、周期送信の順序入替処理において、各データ取得要求に起因する応答パケットのデータ量（パケット数）を考慮していなかった。よって、データ量が大きい応答パケットの近傍では通信トラフックが大きくなり、データ量が小さい応答パケットの近傍では通信トラフックが小さくなることがあった。無線ネットワークの通信トラフィックを平準化するためには、応答パケット数を考慮して、データ取得要求の順序を入れ替えるべきである。このため、実施例３では、応答パケットのデータ量を考慮して、データ取得要求の順序を決定するデータ収集システムを説明する。また、実施例２と同様に、センサ装置間の関連性についても考慮する例を説明するが、実施例２と組み合わせずに、実施例３を単独で実施例１と組み合わせてもよい。

実施例３のシステム構成、データ収集装置１０１の構成、スケジュール管理部２０２の機能ブロック、情報設定画面２０１、各種情報管理テーブル２０４、２０５、２１１、２１３、及び、送信量調整処理９０１などは実施例１、２と同じであるため、これらの説明は省略し、図１１を用いて、実施例１、２と相違するスケジュール調整処理を説明する。

図１１は、応答パケットのデータ量を考慮したスケジュール調整処理１００１のフローチャートである。

データ収集装置１０１で、データ取得要求のためのスケジュールが情報設定画面２０１に入力され、収集開始ボタン４０１が操作されると、スケジュール管理部２０２の要求送信順序決定部２０３が、各センサ装置１０２へ送信するデータ取得要求について図１１に示す処理を実行し、データ取得要求のスケジュールを決定する。

まず、ステップ１１０２において、要求送信順序決定部２０３（初期順序決定部３０１）は、スケジュール情報管理テーブル２０５に格納された全データを読み出し、起点時刻、収集間隔、再送回数、再送間隔、及び関連Ｇｒに基づいて、データ取得要求の送信先となるセンサ装置１０２の順序を決定する。ステップ１１０２で決定される初期順序は、無線ネットワークに加入した順やランダムに並べた順序など任意の順序を採用でき、必ずしもスケジュール全体で通信トラフィックが均一化や、平準化されていなくてもよい。なお、実施例１で説明したと同様に、無線情報２１３を考慮した順序に（例えば、ホップ数が大きいセンサ装置１０２とホップ数が小さいセンサ装置１０２とが交互に）並べてもよい。実施例３でも、同一の関連Ｇｒに属するセンサ装置１０２が連続して並ぶことを優先する。

次に、ステップ１１０３において、送信順序調整機能が有効か、無効かを判定する。具体的には、情報設定画面２０１のスケジュール調整機能ボタン４０４の操作によって、送信順序調整機能の有効に切り替えられているか否かで判定可能である。送信順序調整機能が有効である場合はステップ１１０４に進みスケジュールの調整を実施し、有効でない場合はステップ１１１２に進みスケジュール調整を終了する。

ステップ１１０４において、スケジュール管理部２０２が管理するデバイス情報２０４からデータ取得要求に対する応答パケットのデータ長を取得し、応答パケット数を算出してステップ１１０５に進む。

ステップ１１０５において、順序入替端末抽出機能３０２が、前記初期順から順序を入替可能なセンサ装置１０２を複数（少なくとも二つ以上）選択し、ステップ１１０６に進む。入替候補のセンサ装置１０２の選択は、ランダム、ネットワーク加入順など任意の方法を採用できる。なお、実施例１で説明したように、無線情報２１３を考慮して順序を入れ替えるセンサ装置１０２を抽出してもよい。

ステップ１１０６において、ステップ１１０５で抽出した入替候補のセンサ装置１０２と同一の関連Ｇｒに属するセンサ装置１０２があるか否かを確認する。同一の関連Ｇｒに属するセンサ装置１０２がある場合はステップ１１０７に進み、同一の関連Ｇｒに属するセンサ装置１０２がない場合はステップ１１０８に進む。

ステップ１１０７において、同一の関連Ｇｒに属する複数のセンサ装置１０２へのデータ取得要求が連続してスケジューリングされるように、同一の関連Ｇｒに属する全てのセンサ装置１０２を選択し、ステップ１１０９に進む。

ステップ１１０８において、再送時刻再割当機能３０３が、データ取得順序を入れ替える。このとき、１回目のデータ取得要求及び当該要求が失敗した場合の再送を含めて順序を入れ替えて、ステップ１１０９に進む。ただし、前記ステップ１１０７において選択された同一の関連Ｇｒに属するセンサ装置１０２へのデータ取得要求が連続してスケジューリングされるように、データ取得順序を入れ替える。また、連続してデータ取得要求をスケジュールする場合でも、連続するデータ取得要求にかかるセンサ装置１０２の間で、ステップ１１０４において算出した応答パケット数を考慮し、データ取得要求数と応答パケット数との合計数のばらつきが小さくなるように順序を入れ替えるとよい。

さらに、実施例１、２と同様に、前記選択した入れ替え候補において、再送割当て可否判定部３０４が、システム管理者、システム管理プログラム、サービスアプリ１４１などによって予め設定されたスケジュール情報管理テーブル２０５の再送間隔や再送数などの条件を満たすかを判定し、条件を満たさない場合は、入れ替えを実施せず、ステップ１１０９に進む。

ステップ１１０９において、再送時刻再割当機能３０３が、データ取得要求の送信スケジュールを変更する。

ステップ１１１０において、通信トラフィック評価機能３０５が、前記データ取得要求順序の入れ替えの結果を評価するため、評価結果を算出し、ステップ１１１１に進む。例えば、所定時間（例えば、５分）間隔で要求送信数を算出し、各５分の中の要求送信数のばらつきの程度、５分ごとの要求送信数のばらつきの程度などを評価指標とする。

ステップ１１１１において、通信トラフィック評価機能３０５は、算出された評価指標が予め決定した閾値に到達しているか否かを判定する。閾値を越えた場合はステップ１１１２に進み、スケジュール調整処理を終了する。閾値より小さい場合はステップ１１０４に戻り、ステップ１１０４〜１１１１の入替処理を繰り返し実行する。この閾値はシステムにおいてが予め定められたシステムパラメータであり、システム管理者、システム管理プログラム、サービスアプリ１４１などが予め決定しておくものである。

以上のように、実施例３のデータ収集システムでは、前述した実施例の効果の他、センサ装置１０２から取得するデータ量を考慮してデータ取得要求のスケジュールを設定するので、大容量のデータを収集する場合でも、通信トラフィックを平準化し、無線マルチホップネットワークを安定的に稼動させることができる。例えば、月に一度のシステムログの収集や、計測対象を撮影した画像などを収集する場合に有効である。

以上のように、本発明の実施例によると、タイミングデータに従って、センサ装置１０２にデータ取得要求を送信するスケジュールを決定するスケジュール管理部２０２と、データ取得要求の送信量を調整するデータ取得要求送信量調整部２０６と、センサ装置１０２から収集したデータを管理する収集データ管理部２１０と、を備え、スケジュール管理部２０２は、センサ装置１０２からのデータ収集を開始する時刻である起点時刻５０２、センサ装置１０２からのデータ収集の間隔である収集周期５０３、センサ装置１０２からのデータ収集が失敗したときにデータ取得要求を再送するまでの時間である再送間隔５０４、及び、データ取得要求を再送する回数である再送回数５０５をタイミングデータとして管理するので、センサ装置１０２からデータを収集するスケジュールを柔軟に作成できる。

また、スケジュール管理部２０２は、一台のセンサ装置１０２について、起点時刻５０２、収集周期５０３、再送間隔５０４及び再送回数５０５の組み合わせを複数保持し、保持された複数の組み合わせに従って、当該センサ装置１０２へのデータ取得要求の送信スケジュールを決定するので、複数の用途（サービスアプリ１４１）でセンサ装置１０２を活用できる。また、１日のうち不均一な周期（例えば、毎日９時と１７時）にデータを取得できる。

また、データ取得要求送信量調整部２０６は、周期的に送信されるデータ取得要求による通信負荷と所定の閾値との比較結果に基づいて、不定期に送信されるオンデマンドのデータ取得要求の送信を遅延させるので、オンデマンド通信を考慮して通信スケジュールを調整でき、無線マルチホップネットワークを安定的に稼動させて、データ収集率を向上できる。

また、スケジュール管理部２０２は、複数のセンサ装置１０２を一つのグループとして管理し、同一のグループに属する複数のセンサ装置１０２から連続してデータ収集するために、前記同一のグループに属する複数のセンサ装置１０２にデータ取得要求を連続して送信するように、データ取得要求の送信スケジュールを決定するので、複数のセンサ装置１０２から同じタイミングでデータを取得でき、同じタイミングでデータを必要とするサービスアプリ１４１にも対応できる。

また、スケジュール管理部２０２は、データ取得要求に対する応答パケットのデータ量を考慮して、通信路１０３のトラフィックが平準化するように、データ取得要求の送信スケジュールを決定するので、他のセンサ装置１０２からのデータ収集に影響せずに、大容量のデータを収集できる。

また、データ取得要求送信量調整部２０６は、データ取得要求の送信から応答パケットの受信までの遅延時間以上の時間間隔で、データ取得要求を送信するようにタイミングを決定するので、応答パケットとデータ取得要求との衝突を抑制し、データ収集率を向上できる。

また、スケジュール管理部２０２は、データ取得要求の宛先となる端末装置１０２を二つ選択し、前記選択された端末装置１０２のデータ取得要求の順序を入れ替えると、各端末装置１０２に定められたデータ取得の条件を満たすかを判定し、前記データ取得の条件を満たさない場合、当該端末装置１０２のデータ取得要求の順序を入れ替えずに、さらに、前記選択された端末装置１０２と少なくとも一方が異なる端末装置１０２を二つ選択し、前記データ取得の条件を満たす場合、当該端末装置１０２のデータ取得要求の順序を入れ替えることによって、データ取得要求の送信スケジュールを変更し、前記変更後の送信スケジュールにおいて、通信路１０３のトラフィックが平準化されているかを評価し、通信路１０３のトラフィックが所定の平準化の条件を満たさない場合、さらに、前記選択された端末装置１０２と少なくとも一方が異なる端末装置１０２を二つ選択して、データ取得要求の順序を入れ替えるので、予め設定された条件の下で通信負荷を平準化できる。また、データ取得の条件を満たすかの判定によって、データ取得要求の順序を入れ替える処理の負荷を軽減し、高速化できる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１０１……データ収集装置、１０２（Ａ）（Ｂ）（Ｃ）（Ｄ）（Ｅ）……センサ装置、１０３……無線マルチホップネットワーク（無線通信路）、１０４（Ａ）（Ｂ）……サービス装置、１０５……通信路

Claims (14)

1. 通信路を介して接続される端末装置からデータを収集するデータ収集装置であって、
   タイミングデータに従って、前記端末装置にデータ取得要求を送信するスケジュールを決定するスケジュール管理部と、
   前記データ取得要求の送信量を調整する送信量調整部と、
   前記端末装置から収集したデータを管理する収集データ管理部と、を備え、
   前記スケジュール管理部は、
   前記各端末装置からのデータ収集を開始する時刻である起点時刻、前記各端末装置からのデータ収集の間隔である収集周期、前記端末装置からのデータ収集が失敗したときにデータ取得要求を再送するまでの時間である再送間隔、及び、前記データ取得要求を再送する回数である再送回数を、前記タイミングデータとして管理するものであって、
   前記データ取得要求の宛先となる端末装置を二つ選択し、
   前記選択された端末装置のデータ取得要求の順序を入れ替えることによって、データ取得要求の送信スケジュールを変更し、
   前記変更後の送信スケジュールにおいて、前記通信路のトラフィックが平準化されているかを評価し、
   前記通信路のトラフィックが所定の平準化条件を満たさない場合、さらに、前記選択された端末装置と少なくとも一方が異なる端末装置を二つ選択して、データ取得要求の順序を入れ替えることを特徴とするデータ収集装置。
2. 請求項１に記載のデータ収集装置であって、
   前記スケジュール管理部は、
   一台の前記端末装置について、前記起点時刻、前記収集周期、前記再送間隔、及び、前記再送回数の組み合わせを複数保持し、
   前記保持された複数の組み合わせに従って、当該端末装置へのデータ取得要求の送信スケジュールを決定することを特徴とするデータ収集装置。
3. 請求項１に記載のデータ収集装置であって、
   前記送信量調整部は、周期的に送信されるデータ取得要求による通信負荷と所定の閾値との比較結果に基づいて、不定期に送信されるデータ取得要求の送信を遅延させることを特徴とするデータ収集装置。
4. 請求項１に記載のデータ収集装置であって、
   前記スケジュール管理部は、複数の前記端末装置を一つのグループとして管理し、同一のグループに属する複数の端末装置から連続してデータ収集するために、前記同一のグループに属する複数の端末装置にデータ取得要求を連続して送信するように、前記データ取得要求の送信スケジュールを決定することを特徴とするデータ収集装置。
5. 請求項１に記載のデータ収集装置であって、
   前記スケジュール管理部は、前記データ取得要求に対する応答パケットのデータ量を考慮して、前記通信路のトラフィックが平準化するように、前記データ取得要求の送信スケジュールを決定することを特徴とするデータ収集装置。
6. 請求項１に記載のデータ収集装置であって、
   前記送信量調整部は、前記データ取得要求の送信から応答パケットの受信までの遅延時間以上の時間間隔で、前記データ取得要求を送信するようにタイミングを決定することを特徴とするデータ収集装置。
7. 請求項１に記載のデータ収集装置であって、
   前記スケジュール管理部は、前記選択された端末装置のデータ取得要求の順序を入れ替えると、各端末装置に定められたデータ取得の条件を満たさない場合、当該端末装置のデータ取得要求の順序を入れ替えずに、さらに、前記選択された端末装置と少なくとも一方が異なる端末装置を二つ選択して、データ取得要求の順序を入れ替えることを特徴とするデータ収集装置。
8. 通信路を介して接続される端末装置からデータ収集装置がデータを収集する方法であって、
   前記データ収集装置は、所定の処理を実行する演算装置と、前記演算装置に接続された記憶デバイスと、前記演算装置に接続された通信インターフェースとを有し、
   前記方法は、
   前記演算装置が、前記端末装置にデータ取得要求を送信するスケジュールを決定するために参照されるタイミングデータを管理するスケジュール管理手順と、
   前記演算装置が、前記管理されたタイミングデータに従って、前記端末装置にデータ取得要求を送信するスケジュールを決定するスケジュール決定手順と、
   前記演算装置が、前記データ取得要求の送信量を調整する送信量調整手順と、
   前記演算装置が、前記端末装置から収集したデータを管理するデータ収集手順と、を含み、
   前記スケジュール管理手順では、前記演算装置が、前記各端末装置からのデータ収集を開始する時刻である起点時刻、前記各端末装置からのデータ収集の間隔である収集周期、前記端末装置からのデータ収集が失敗したときにデータ取得要求を再送するまでの時間である再送間隔、及び、前記データ取得要求を再送する回数である再送回数を、前記タイミングデータとして管理し、
   前記スケジュール決定手順では、
   前記演算装置が、前記データ取得要求の宛先となる端末装置を二つ選択し、
   前記演算装置が、前記選択された端末装置のデータ取得要求の順序を入れ替えることによって、データ取得要求の送信スケジュールを変更し、
   前記演算装置が、前記変更後の送信スケジュールにおいて、前記通信路のトラフィックが平準化されているかを評価し、
   前記演算装置が、前記通信路のトラフィックが所定の平準化条件を満たさない場合、さらに、前記選択された端末装置と少なくとも一方が異なる端末装置を二つ選択して、データ取得要求の順序を入れ替えることを特徴とする方法。
9. 請求項８に記載のデータ収集方法であって、
   前記スケジュール管理手順では、前記演算装置が、一台の前記端末装置について、前記起点時刻、前記収集周期、前記再送間隔、及び、前記再送回数の組み合わせを複数管理し、
   前記スケジュール決定手順では、前記演算装置が、前記管理されている複数の組み合わせに従って、当該端末装置へのデータ取得要求の送信スケジュールを決定することを特徴とする方法。
10. 請求項８に記載のデータ収集方法であって、
    前記送信量調整手順では、前記演算装置が、周期的に送信されるデータ取得要求による通信負荷と所定の閾値との比較結果に基づいて、不定期に送信されるデータ取得要求の送信を遅延させることを特徴とする方法。
11. 請求項８に記載のデータ収集方法であって、
    前記スケジュール管理手順では、前記演算装置が、複数の前記端末装置を一つのグループとして管理し、
    前記スケジュール決定手順では、前記演算装置が、同一のグループに属する複数の端末装置から連続してデータ収集するために、前記同一のグループに属する複数の端末装置にデータ取得要求を連続して送信するように、前記データ取得要求の送信スケジュールを決定することを特徴とする方法。
12. 請求項８に記載のデータ収集方法であって、
    前記スケジュール決定手順では、前記演算装置が、前記データ取得要求に対する応答パ
    ケットのデータ量を考慮して、前記通信路のトラフィックが平準化するように、前記データ取得要求の送信スケジュールを決定することを特徴とする方法。
13. 請求項８に記載のデータ収集方法であって、
    前記送信量調整手順では、前記演算装置が、前記データ取得要求の送信から応答パケットの受信までの遅延時間以上の時間間隔で、前記データ取得要求を送信するようにタイミングを決定することを特徴とする方法。
14. 請求項８に記載のデータ収集方法であって、
    前記スケジュール決定手順では、前記選択された端末装置のデータ取得要求の順序を入れ替えると、各端末装置に定められたデータ取得の条件を満たさない場合、前記演算装置が、当該端末装置のデータ取得要求の順序を入れ替えずに、さらに、前記選択された端末装置と少なくとも一方が異なる端末装置を二つ選択して、データ取得要求の順序を入れ替えることを特徴とする方法。

Images