JP5406362B2 - モニタリングシステム、装置および方法 - Google Patents

Description

本発明はモニタリングシステム、特に広帯域網の帯域制限を考慮した優先度制御を行うモニタリング技術に関する。

近年、ボイラーや火力タービンといった設備監視や保守、エネルギー消費のモニタリングを現場から離れたセンタ側から遠隔で行いたいという需要が高まっている。このようなモニタリングシステムの末端に設備されるセンサや監視カメラのデータは、全てセンタ側へ吸い上げるのが理想であるが、それらの台数が増加するにつれて、ネットワークの伝送可能なトラフィック容量の関係から、常時全てのデータをセンタ側に吸い上げることが困難になってきている。

このような現状に対応するため、例えば特許文献１においては、移動ノードと固定ノードとの通信から得られる優先度情報に基づいて、カメラからの画像データの転送・表示の優先度を制御する技術を開示している。

特開２００９−１７１４７１号公報

上述の全データの吸い上げの困難性の要因としては、次の要因が考えられる。
・カメラの動画像等、データレートの高い端末が増えたため、ネットワーク内で生成されるデータの総容量が、ネットワークで伝送可能なトラフィック容量（通常、イーサネット（登録商標）で、１００Ｍ〜１０Ｇｂｐｓ程度）を超えてしまう。
・総計多重効果により、総トラフィック量の平均値と最大値の差異が大きく、ワースト条件でネットワークを設計するとオーバースペックになる。
・インターネット等公衆網を利用する場合、同一ネットワーク配下で発生するトラフィック量が予想できない。
・特に無線を利用する場合、電波伝搬状況により伝送可能な容量が変動する。

さらに、ネットワークのトラフィック容量が足りていても、有料のネットワーク（特に従量課金制のもの）を利用する場合は、通信費用を必要最低限に抑えたいとのニーズもある。

上述のようにネットワークのトラフィック容量が足りない或いは変動するため、常時全てのデータをセンタに挙げることができない場合、例えば、QoS（Quality of Service）帯域保証により優先度が高いデータについては常時帯域を確保する方法、及びベストエフォート通信により送れる範囲内でなるべく沢山送る方法の組合せが考えられる。更に、優先度が監視対象の異常情報、アラートの有無等の状況によって変化するような場合、QoS帯域保証するデータの優先順序を入れ替えることなどが考えられる。

しかし、温度センサのようにデータレートは低いが、一定間隔で確実に送りたい情報と、監視カメラのようにデータレートが高いが、通常時は優先度が低いものが混在している場合、QoS保証帯域が一定のままで、アラーム検出時のみ監視カメラデータの優先度を上げると、QoS保証帯域がカメラデータに独占され、センサデータを送ることができない、またアラーム検出時のみQoS保証帯域を広げようとした場合、そのときのネットワークのトラフィック状態によっては、必ずしも必要なQoS保証帯域を確保できないといった状況が考えられる。

本発明の目的は、上述した種々の課題を解決し、ネットワークの帯域制限を考慮した優先度制御を実現可能なモニタリングシステムを提供することにある。

また、本発明の他の目的は、データレートは低いが一定間隔で確実に送りたい情報と、データレートが高いが通常時は優先度が低い情報が混在し、且つネットワークのトラフィック容量が足りない又は変動するため、常時全てのデータを管理センタに挙げることができない場合に、モニタリングシステムとしての性能を保ちながら、管理センタへ吸い上げるデータ量を低減する通信制御装置、及び方法を提供することにある。

上記の目的を達成するため、本発明においては、複数の通信端末が接続される第１のネットワークと管理センタが接続される第２のネットワークを接続するネットワーク相互接続装置を用いたモニタリングシステムであって、ネットワーク相互接続装置は、複数の通信端末のイベントステータスに応じた送出データの優先順に基づき第２のネットワークの管理センタなどの上位ノードへの送出データを選択し、イベントステータス及びネットワークの通信状況に応じた送出データのデータ圧縮方法を選択するモニタリングシステムを提供する。

また、上記の目的を達成するため、本発明においては、第１のネットワークを介して複数の通信端末からのデータを受信し、第２のネットワークを介して管理センタに送信するよう制御する通信制御装置であって、第１のネットワークと第２のネットワークとそれぞれ通信を行う通信部と、処理部と、記憶部とを備え、処理部は、通信部を介して複数の通信端末からのデータのフィルタリング処理によりイベントステータスを抽出し、通信部を介して受信した管理センタからの受信データ等に基づき、第２のネットワークの通信状況を推定し、通信状況に応じて送出すべきデータの圧縮度を選択し、イベントステータスと圧縮度に基づき、送出すべきデータの優先順と圧縮方法を決定する通信制御装置を提供する。

更に、上記の目的を達成するため、本発明においては、通信部と、処理部と、記憶部とを備え、第１のネットワークを介して複数の通信端末からのデータを受信し、第２のネットワークを介して管理センタに送信する通信装置の通信制御方法であって、処理部は、通信部を介して複数の通信端末からのデータに基づきイベントステータスを抽出し、通信部を介して受信した管理センタからの受信データ等に基づき、ネットワークの通信状況を推定し、通信状況に応じて送出すべきデータの圧縮度を選択し、イベントステータスと圧縮度に基づき、送出すべきデータの優先順と圧縮方法を決定する通信制御方法を提供する。

本発明によれば、第１のネットワークで発生した全てのデータを常時第２のネットワークで送ることが出来ない場合でも、モニタリングシステムの性能を落とすことなく、第２のネットワークへの送出データ量を低減できる。更に、有料のネットワークを使用しても、その通信コストを抑えることができる。

本発明の実施例１に係る通信システムの全体構成図である。 実施例１におけるローカルネットワークの一構成例を示す図である。 実施例１に係る、ネットワーク相互接続装置の一実施例を示す図である。 実施例１に係る、優先順／フィルタ種別選択処理部の一処理フローを示す図である。 実施例１に係る、ステータス毎のテーブルの一例を示す図である。 実施例１に係る、圧縮度算出テーブルの一例を示す図である。 実施例１に係る、ステータス用テーブルの構成要素の一例を示す図である。 実施例１に係る、ステータス用テーブルの構成要素の他の一例を示す図である。 実施例１のモニタリングシステムの効果を説明するための図である。 実施例１に係る、広域ネットワークの通信状況判断のための通信フローを説明する図である。 実施例１に係る、広域ネットワークの通信状況判断のための通信フローを説明する図である。 実施例１に係る、広域ネットワークの通信状況判断のための通信フローを説明する図である。 実施例１に係る、ネットワーク相互接続装置の一構成例を示す図である。 実施例１に係る、通信端末の一構成例を示す図である。 実施例１に係る、管理センタの一構成例を示す図である。 実施例１に係る、時刻差の統計データの確率分布のグラフを示す図である。 本発明の実施例３に係る通信システムの全体構成図である。 本発明の実施例４に係る通信システムの全体構成図である。 実施例４に係る、ステータス用テーブルの構成要素の一例を示す図である。 実施例４に係る、ステータス用テーブルの構成要素の他の一例を示す図である。 実施例１及び実施例４に係る、通信端末からネットワーク相互接続装置へ送る情報の内容と形式の一例を示す図である。 図６Ａ、６Ｂに示すステータス用テーブルの構成要素の一例の別例を示す図である。 図６Ａ、６Ｂに示すステータス用テーブルの構成要素の一例の別例を示す図である。

以下、本発明の種々の実施形態を図面に従い説明する。なお、本願明細書において、中央処理部（Central Processing Unit：ＣＰＵ）が実行する各種のソフトウェアで実現される構成を、「プログラム」、「処理部」、「モジュール」、或いは「部」と表現する。

図１に第１の実施例に係る、各種のモニタリングを実現可能な通信システムの全体構成図を示す。同図において、１０、１４はそれぞれＷＡＮ(Wide Area Network)と称される広域ネットワークと、ＬＡＮ(Local Area Network)と称されるローカルネットワークを示す、１１はそれらを相互接続するネットワーク相互接続装置である。第１のネットワークとして機能するローカルネットワーク１４には、温度センサなどの各種のセンサや監視カメラなどの複数の通信端末１２が接続されており、第２のネットワークとして機能する広域ネットワーク１０には上位ノードである管理センタ１３が接続されている。二層モデルである本システム構成においては、ネットワーク相互接続装置１１は、各ネットワークのエッジノードとして機能する。なお、第１のネットワーク、第２のネットワークは例示したＬＡＮ、ＷＡＮに限定されないことは言うまでもない。

図２に本実施例の第１のネットワークとして機能するローカルネットワーク１４のより具体的な構成の一例を示す。同図において、２０は監視の対象となる監視装置を示し、２１〜２５は図１の通信端末１２である、センサ１、センサ２、センサ３、監視カメラ４、監視カメラ５をそれぞれ示す。同図のローカルネットワーク１４では、監視装置２０に関する動作環境等の各種センシングデータや監視映像データがセンサや監視カメラからネットワーク相互接続装置１１を介して第２のネットワークとして機能する広域ネットワーク１４に送出される。

すなわち、図１、図２で示される本実施例のモニタリングシステムは、監視装置２０の周辺にセンサ２１〜２３と監視カメラ２４、２５を配置し、一旦、ローカルネットワーク１４のエッジノードとして機能するネットワーク相互接続装置１１にデータを集約後、更に広域ネットワーク１０を介して、管理センタ１３にデータを集約する構成を有する。

本実施例のモニタリングシステムにおいては、具体例として、センサ２１〜２３のセンシングデータは一つ当たり、圧縮無しで１ｋｂｐｓ、後で詳述する平均化、特徴抽出等のフィルタリング処理により、最小で０．２ｋｂｐｓまで圧縮できるものとすることができる。また、カメラ２４、２５からのデータは、１台あたり画質に応じて４ｋ、１６ｋ、３２ｋ、６４ｋ、１２８ｋｂｐｓの５段階から選択できるよう構成することができるが、これらに限定するものでないことは言うまでもない。

図１８を用いて、通信端末１２からネットワーク相互接続装置に送る情報の内容と形式（パケットフォーマット）を説明する。通信端末１２からは、ヘッダ情報１８０と、その端末に接続されたセンサや監視カメラ等から入力される各種センシングデータや画像などを含むセンシング情報１８１を送る。ヘッダ情報１８０の中には、通信端末及び接続されているデバイス（センサ、監視カメラ等）の種別を表す端末種別１８２、複数の通信端末を区別するための端末ＩＤ１８３、センシング情報を取得した際の時刻情報１８４、等が含まれる。本実施例においては、端末種別は「センサ」と「監視カメラ」の二種類に分かれ、端末ＩＤは１〜５までとなる。端末ＩＤは、本実施例のように、端末種別が「センサ」か「監視カメラ」かによらず通し番号で付けることもできるし、端末種別毎に「センサ１」「監視カメラ１」と分けて付けることもできる。

図１１、図１２、図１３を用いて、まず、図１に示した本実施例のシステム全体構成の中の、ネットワーク相互接続装置１１、通信端末１２、管理センタ１３の内部構成の一例を説明する。

図１１は、ネットワーク相互接続装置１１の一実施例を示している。同図において、ネットワーク相互接続装置１１は、ローカルネットワーク１４、広域ネットワーク１０と接続されるローカルネットワーク通信インタフェース（Ｉ／Ｆ）１１１と広域ネットワーク通信Ｉ／Ｆ１１６を備え、それらを接続する内部バス１１７に接続された処理部となる中央処理部（Central Processing Unit：ＣＰＵ）１１２、処理部となるハードウェアアクセラレータ１１５、記憶部である演算用メモリ１１４と、ＣＰＵ１１２で実行されるプログラムを記憶する記憶部であるプログラム格納用メモリ１１３から構成される。なお、詳述する各種のテーブルは、記憶部を構成する演算用メモリ１１４、プログラム格納用メモリ１１３のどちらに蓄積・記憶しても良い。ここで、ハードウェアアクセラレータ１１５とは、ＣＰＵ１１２で実行されるフィルタリング処理部３３のようなソフトウェア演算の一部をハードウェア回路に置換し、フィルタリング処理部１１５１として演算を高速化するものを指す。例えば、ＦＦＴ演算、ターボ符号などの誤り訂正復号演算、ＭＰＥＧ画像の圧縮・復元等を実行するものであり、ＦＰＧＡ（Field Programmable Gate Array）の回路ＩＰとして市販されているものを使用することも可能である。

また、プログラム格納用メモリ１１３には、図３に示した各処理部と、図５Ａ、図５Ｂに示した各テーブルに対応するフィルタリングプログラム１１３１、ローカルネットワークデータ統計プログラム１１３２、優先順／フィルタ種別選択プログラム１１３３、広域ネットワーク状況推進プログラム１１３６、送出データ選択プログラム１１３７とステータス用テーブル１１３４、圧縮度算出テーブル１１３５が格納される。一方、演算用メモリ１１４には、その各プログラムの実行状況に応じて、そのエリアとして、バッファリング領域１１４１、ローカルネットワークデータ統計情報１１４２、広域ネットワーク状況推定情報１１４３、優先順／フィルタ種別選択情報１１４４が設けられる。

図１２は、通信端末１２の一実施例を示している。同図において、通信端末１２は、上述した各種通信端末としてのセンサ機能、カメラ機能に加え、図１２に示したブロック要素を備えている。すなわち、ローカルネットワーク１４と接続されるローカルネットワーク通信Ｉ／Ｆ１２１を備え、それに接続される内部バス１２７に接続されたＣＰＵ１２２、演算用メモリ１２４、プログラム格納用メモリ１２３から構成される。各通信端末１２は、これらＣＰＵ１２２、演算用メモリ１２４、プログラム格納用メモリ１２３を用いて、図示を省略した各センサ機能部やカメラ機能部からのデータを処理して、ローカルネットワーク１４に送出する様に制御する。

同図においても、ハードウェアアクセラレータ１２５はフィルタリング処理部１２５１が一部置換される。また、プログラム格納用メモリ１２３には、フィルタリングプログラム１２３１、ローカルネットワークデータ統計プログラム１２３２が格納される。一方、演算用メモリ１２４には、その各プログラムの実行状況に応じて、そのエリアとして、バッファリング領域１２４１、ローカルネットワークデータ統計情報１２４２が設けられる。

図１３は、管理センタ１３の一実施例を示している。同図において、管理センタ１３は、広域ネットワーク１０と接続される広域ネットワーク通信Ｉ／Ｆ１３６を備え、それに接続する内部バス１３７に接続されたＣＰＵ１３２、ハードウェアアクセラレータ１３５、演算用メモリ１３４、プログラム格納用メモリ１３３から構成される。

同様に同図の構成においても、ハードウェアアクセラレータ１３５はフィルタリング処理部１３５１が一部置換される。また、プログラム格納用メモリ１３３には、フィルタリングプログラム１３３１、広域ネットワーク状況推進プログラム１３３２が格納される。一方、演算用メモリ１３４には、その各プログラムの実行状況に応じて、そのエリアとして、バッファリング領域１３４１、広域ネットワーク状況推定情報１３４２が設けられる。

図３は、実施例１のエッジノードとして機能するネットワーク相互接続装置１１の一構成を示す図である。同図において、３１〜３９はネットワーク相互接続装置１１の処理部で実行されるソフトウェア、またはＦＰＧＡで実現する専用ハードウェア等で実現される各処理ブロックを示し、それぞれローカルネットワーク通信処理部、バッファリング処理部、フィルタリング処理部、優先制御部、ローカルネットワークデータ統計処理部、優先順／フィルタ種別選択処理部、広域ネットワーク状況推定処理部、送出データ選択処理部、広域ネットワーク通信処理部を示している。広域ネットワーク状況推定処理部３６は、広域ネットワーク１０の通信状況、すなわち実質的に送出可能なレートの平均等を定期的にモニタリングする処理を実現する。

ローカルネットワーク通信処理部３１は、ローカルネットワーク１４との通信インタフェースである。バッファリング処理部３２は、メモリを用いたデータバッファとして機能する。

フィルタリング処理部３３には、先に図１８で説明した通信端末からの情報のうち、ヘッダ情報１８０の圧縮処理等の可逆な処理と、センシング情報１８１の量子化処理等の不可逆な処理がある。フィルタリング処理部３３のフィルタリング処理の内容は、予めエッジノードである装置１１の内部に作りこみまれたフィルタリング処理ライブラリとして読み出される場合と、上位ノードにあたる管理センタから配布される場合の二通りがある。

可逆な処理としては、センサによるセンシング情報の基準値からの差分計算処理、複数のセンシング情報のまとめパケット生成処理、規定された通信プロトコルに則ったヘッダ情報の圧縮処理（例えば、ＩＥＴＦ規格ＲＦＣ４９４４に規定あり）などがある。

一方、不可逆な処理としては、不要なセンシング情報の破棄処理、センシング情報の平均値計算処理、最大値／最小値検出／判定処理、異常値判定処理、時間方向のサンプリング間引き処理、量子化処理や、カメラ画像情報のフレーム間引き処理、画像サイズ変更処理、顔検出、動き検出等の特徴抽出処理などがある。

不可逆な処理を行ってセンシング情報の精度が落ちたり、意味合いが変化してしまう場合も、バッファリング処理部３２により、エッジノードとしてのネットワーク相互接続装置１１内に処理前のデータをバッファリングしておくことで、処理前のデータをそのまま送ったり、後から必要になった際に、上位ノードからエッジノードである装置１１にアクセスし、処理前のデータを確認することができる。

優先度制御部３４は、図３に示す通り、大きく分けて次の三つの処理を提供する。すなわち、ローカルネットワークデータ統計処理部３５、広域ネットワーク状況推定処理部３６、優先順／フィルタ種別選択処理部３７である。これらの処理は、先に説明した図１１のプログラム格納用メモリ１３３に記憶された各処理に対応するプログラムを、ＣＰＵ１３２が実行するソフトウェア処理によって実現することができる。

ここで広域ネットワーク状況推定処理部３６は、エッジノードが収集したセンシング情報を、広域ネットワーク通信処理部３９により上位ノードへ送出する際に使用する広域ネットワーク１０のスループットや遅延などの通信状況を推定し、優先順位／フィルタ種別選択処理部３７に通知する。

広域ネットワーク１０には、対象システム専用の閉じたネットワークも、インターネットや携帯電話網などのオープンなネットワークもあり、選出可能なデータ量（帯域）が常時一定量保証されている場合と、ネットワーク上のトラフィックが時々刻々変化し保証されない場合とがある。帯域保証されている場合には、広帯域ネットワーク状況推定処理部３６は、設定時の保証帯域の情報を保持する。帯域が変動する場合には、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）のウィンドウサイズ情報を参考情報として使用する、時刻情報を含む計測用パケットをエッジノード上位ノード間で定期的にやり取りし、計測用パケットの受領時刻とパケットに含まれる時刻情報との差から伝送遅延を算出する、などの方法を取る。

ローカルネットワークデータ統計処理部３５は、エッジノードがセンサからセンシング情報を収集する際に使用するローカルネットワーク１４のスループットや遅延、どのような優先度のデータがどれだけの量含まれているか、などの通信状況を測定し、優先順／フィルタ種別選択処理部３７に通知する。

優先順／フィルタ種別選択処理部３７では、広域ネットワーク状況推定処理部３６から通知される広域ネットワークの通信状況（送出可能なデータ量）と、ローカルネットワークデータ統計処理部３５から通知されるローカルネットワーク１４の通信状況（送出したいデータ量と優先度の分布）、フィルタリング処理部３３から通知される処理後のデータの（異常値判定結果など）の３つの入力から、実際にどの端末からのデータを、どういった形でフィルタリング処理（フィルタリング条件）し、どの順序で送出するかを決定する。優先順／フィルタ種別選択処理部３７は、決定したフィルタリング条件と送出順序を含む結果を、送出データ選択処理部３８に通知する。

図４は優先度制御部３４の優先順／フィルタ種別選択処理部３７の処理フローを示す図である。

この決定方法の一例の動作フローを図４に示した。図４において、まず、初期状態（４０）において、フィルタリング処理部３３から通知される処理後のデータである、例えば異常判定結果などからイベント条件を検知（４１）し、ローカルネットワークのイベントステータスを判断（４２）する。なお、このフィルタリング処理部３３における異常判定とは、先に詳述したように、温度センサやマイクロホンなどのセンシング情報の基準値からの差分計算結果に基づく異常値判定、顔検出、動き検出等の特徴抽出に基づく人物検出等のソフトウェア処理をいう。

次に、そのイベントステータスから参照すべきデータ圧縮方法の記載されたステータス用テーブルを選択（４３）する。そして送出したいデータ量と送出可能なデータ量の比から圧縮率を算出し、選択したステータステーブルを参照して、圧縮率に適した送出順序とフィルタ種別を決める（４４）。本実施例においては、この決定に際し、ローカルネットワークデータ統計処理部３５でローカルネットワークの状態判定（４５）を行い、また広域ネットワーク状態推定処理部３６で広域ネットワークの状態判定（４６）を行い、その状態判定結果に基づき、後で説明する圧縮度算出テーブルから両ネットワーク状態に対応する圧縮度を選択（４７）し、送出順序とフィルタ種別を指定する。このフィルタ種別とは、上述した時間方向のサンプリング間引き処理、量子化処理や、カメラ画像情報のフレーム間引き処理、画像サイズ変更処理などのソフトウェアによる圧縮方法が含まれることは言うまでもない。

続いて、以上で説明した本実施例のモニタリングシステムの構成を用いて、ネットワーク相互接続装置１１におけるネットワークの帯域制限を考慮した優先度制御方法の具体例を図５Ａ，図５Ｂ、図６Ａ、図６Ｂを用いて説明する。ネットワーク相互接続装置１１は、各センサ及びカメラからのデータをネットワークへ送出する際の優先順位を定義するステータス用テーブルを複数設定し、通常時、センサのアラーム検出時等のイベント条件に応じて有効にするテーブルを切替えることにより、帯域制限を考慮した優先度制御方法を実現する。

図５Ａは、本実施例におけるイベントステータス条件、すなわちステータス毎のテーブルとその構成要素の一例を示している。同図において、５１、５２、５３はそれぞれステータスＡ，ステータスＢ、ステータスＣ用のテーブルを示す。一例を示したステータスＣ用テーブル５３において、テーブル構成要素として、圧縮度に対応する圧縮率、送出順序、フィルタ種別を備えている。圧縮度は１以上の値を有する。ステータスＣ用テーブル５３に示すように、圧縮度１の場合、圧縮率は１．０となり、送出されるデータの圧縮は無い。送出順序には、α、β、γの順に送出するよう規定されている。圧縮度１の場合、例えばデータ量は２５９ｋｂｐｓとなり、圧縮度が高くなるのに対応し、データ量は１３１ｋｂｐｓ、−−−、８．６ｋｂｐｓ、４．６ｋｂｐｓのように低減するように設定される。

図５Ｂは、本実施例におけるネットワーク状態、通信状況に基づき圧縮度を算出するための圧縮度算出テーブル５４の一例を示している。同図に明らかなように、本実施例の場合、同テーブル５４の縦軸のローカルネットワーク状態と横軸の広域ネットワーク状態に基づき、圧縮度１〜４が選択される。この、選択・決定された圧縮度に基づき、各イベントステータス用テーブル中の対応する圧縮度が選択・決定される。

図６Ａ、図６Ｂに、図５Ａに示したイベント条件であるステータスの具体例として、温度センサの検出温度の急変といったセンサ１、センサ２の異常発生時というイベント条件の際に使用するステータス用テーブルの一例を示した。図６Ａにおいて、ステータス用テーブル６１は図５Ａのテーブル５３同様、テーブル構成要素として、圧縮度、圧縮率、送出順序、フィルタ種別を有し、圧縮度１、２，３に対応して、それぞれ図示の通りの圧縮率１．０、０．６、０．４を有する。
また、送出順序として、センサ１〜３、監視カメラ４、アラーム１〜３に対して図示の通り、異常が発生したセンサ１のデータが最初に送出されるような順序を有する。更に、フィルタ種別として、センサ１〜３に対し、フィルタなし、アラーム検出結果のみ送出等が適宜選択され、監視カメラに対し、間引きなし、画像サイズ変更と間引き、人の有無といった特徴抽出結果のみ送出などが適宜選択される。例えば、圧縮度３においては、異常が発生したセンサ１のアラーム結果、監視カメラ４の特徴抽出結果、その他のセンサ２、センサ３のアラーム検出結果が送出されることとなる。

同様に図６Ｂのステータス用テーブル６２においては、圧縮度１、２、３に対応して、それぞれ圧縮率１．０、０．６、０．３を有し、また、送出順序も図示のとおり決定される。更に、フィルタ種別も図示の通りとなる。図６Ａのステータス用テーブル６１との差異は、送出順序やフィルタ種別において、センサ１とセンサ２、監視カメラ５と監視カメラ４とが入れ替わっている点である。これは、異常発生に係るセンサのデータを最優先で送出するためである。すなわち、イベントステータス条件が異常発生の場合、当該異常発生を検出したセンサのデータが最優先され、続いてネットワークのトラフィック状況に対応した圧縮度に応じて関連する監視カメラのデータ、あるいは他のセンサのデータが優先される。

なお、図５Ａ、図５Ｂ、図６Ａ、図６Ｂに示す各種テーブルはあくまで一例を示すものであり、他の要素を取り得ることは言うまでもない。

図６Ａ，Ｂの変形例として、図１９Ａ，Ｂを示す。図１９Ａ、Ｂは、図６Ａ，Ｂをさらに具体化したもので、送出順序の項では、どの端末からくるデータであるかを特定するため、先に図１８で説明した端末種別１８２と端末ＩＤ１８３を指定する。端末種別及び端末ＩＤの情報は、通信端末２１から送られてくるパケットのヘッダ情報の中に含まれている。送出順序の項で指定されないデータ（例えば本実施例の図１９Ａにおける監視カメラ４の画像）は、ネットワーク相互接続装置１１まで集められるが管理センタ１３には送出されない。フィルタ種別の項では、送出順序の項で特定したデータに対し、フィルタリング処理部３３で加える処理の種類を指定する。例えば、圧縮度１においては、センサ１の処理前データ、監視カメラ５の処理前データ、センサ２の処理前データ、センサ３の処理前データ、の順にデータを指定する。圧縮度３においては、センサ１のアラーム検出結果(イベントステータス)、監視カメラ５の特徴抽出結果、センサ２のアラーム検出結果、センサ３のアラーム検出結果、の順に送出データを指定する。

本実施例においては、優先度を決定、すなわち優先順位を決めた上で、送出可能な帯域に併せて、センシングデータや監視カメラデータの圧縮方法を選択するため、ネットワークのトラフィック状態に係らず、常に全ての通信端末からのデータを送出することができる。

図８、図１４、図９、図１０を用いて、本実施例のモニタリングシステムにおけるネットワークの通信状況判断のための通信フローの一例を説明する。図８、図９、図１０の通信フローは、時刻付与を行う装置、あるいはネットワークの通信状況を判断する装置が、ネットワーク相互接続装置１１、管理センタ１３、通信端末１２であるかに対応している。

まず、図８に示す通信フローの場合、モニタリングシステム上の通信端末１２がローカルネットワーク１４を介してネットワーク相互接続装置１１にパケット送信を行うと、装置１１は先に説明したバッファリング処理部によりバッファリング（８１）を行い、バッファリングされたパケットデータから送出するパケットデータを選択（８２）する。続いて、選択されたパケットのヘッダ情報に送出時の時刻情報を付（８３）し、広域ネットワーク１０を介して、管理センタ１３に当該パケットを送信する。管理センタ１３では、受信したパケットのヘッダ情報を、受信時の時刻情報と共に記録（８４）する。図８では、その広域送信時刻と広域受信時刻の一例を例示した。

そして、管理センタ１３は、この時刻差情報等を、ネットワーク相互接続装置１１に、逐次フィードバック情報として送信する。この逐次フィードバック情報を受信したネットワーク相互接続装置１１は、広域受信時刻と広域送信時刻の時刻差のフィードバック情報を蓄積し、その統計処理により、広域ネットワーク１０の通信状況を判断することができる。このネットワーク相互接続装置１１における統計処理を図１４で説明する。なお、この統計処理は、先に説明した図１１のプログラム格納用メモリ１３３に記憶された統計処理プログラムを、ＣＰＵ１３２が実行するソフトウェア処理によって実現することができる。この統計処理プログラムは、図３に示したネットワーク相互接続装置１１の構成の広域ネットワーク状況推定処理部３７に含まれるものである。

図１４の１４１は、上述した時刻差の統計データの確率分布を示すグラフである。図１４のグラフ１４１の横軸は、上述の時刻差を表し、縦軸は蓄積されたデータ遅延量（時刻差）の発生確率分布を示している。統計処理プログラムは、確率密度が最大１４２となる時刻差に対応する遅延量が、予め閾値設定した「余裕」「通常」「混雑」のどの領域に含まれるかにより、通信状況を判断する。この判断の指標として、確率密度が最大となる時の値だけでなく、累積確率が所定値ｎパーセンテージより大きい（累積確率＞ｎ％）となる時の値を使っても良い。また、領域区分は図示のような３領域とは限らず、より細かく分割することも可能であることは言うまでもない。いずれにしても、このような統計処理プログラム自身は容易に入手可能である。

次に、図９に示す処理フローの場合を説明する。なお、説明は、図８との差分を中心に説明する。ネットワーク相互接続装置１１から選択されたパケットデータが送信されると、管理センタ１３は、受信したパケットのヘッダ情報を、受信時の時刻情報と共に記録（８４）、この時刻情報を元に時刻差情報の統計処理を行い、広域ネットワーク１０の通信状況を判断（９１）する。図９の処理フローにおいては、図８と異なり、統計処理に基づく広域ネットワーク１０の通信状況の判断を管理センタ１３が行い、その結果をパケット送信元のネットワーク相互接続装置１１に周期的にフィードバックする。この周期的なフィードバック情報は、先に説明した図３の広域ネットワーク状況推定処理部３７に送られることは言うまでもない。

続いて、図１０に示す処理フローの場合を説明する。この処理フローの場合、通信端末１２がパケット生成を行った場合、ヘッダに時刻情報を付与（１０１）し、当該パケット送信を行う。ネットワーク相互接続装置１１は、受信したパケットのヘッダ情報を、受信時の時刻情報と共に記録（１０２）する。その後、図８、図９の処理と同様な処理を経て、管理センタ１３は、装置１１から受信したパケットのヘッダ情報を、受信時の時刻情報と共に記録（１０３）する。本処理フローの場合、記録される時刻情報は、広域送信時刻、広域受信時刻に加え、パケット生成時刻とローカル受信時刻を含んでいる。ここで、ローカル受信時刻とは、ローカルネットワーク１４を介してネットワーク相互接続装置１１がパケットを受信したときの時刻情報であることは言うまでもない。

これらの時刻情報は、逐次フィードバックにより、ネットワーク相互接続装置１１に送信され、装置１１では、ローカル受信時刻とパケット生成時刻との差分情報からローカルネットワーク１４の通信状況を判断（１０４）、同様に広域ネットワーク１０の通信状況を判断（８５）する。なお、この変形例として、ネットワーク相互接続装置１１から管理センタ１３に送信するパケットのパケット生成時刻とローカル受信時刻については、装置１１中に蓄積しておき、その蓄積データを用いて時刻差の統計処理を行い、ローカルネットワーク１４の通信状況を判断することもできる。いずれの場合においても、図３に示したネットワーク相互接続装置１１の構成の一つであるローカルネットワークデータ統計処理部３５がこの統計処理を行うことは言うまでもない。

続いて、図７を用いて、以上詳述した第１の実施例のデータ送出方法の効果を説明する。図７では、本実施例の構成を用いない従来方式と、本実施例の方法の両方を比較して示した。図７の上段に示す従来方式の場合においては、通常時において、優先度の高い、温度センサなどのデータレートは低いが、一定間隔で確実に送りたいセンサ１〜３に対応するセンシングデータ７１〜７３はQoS帯域保証されており、一定のデータ送出量を確保できる。一方、データレートは高いが通常時は優先度の低い監視カメラ４については、ベストエフォート通信により、送れる範囲でなるべく沢山送信するため、そのデータ送出量は変動する。ここで、アラーム検出により監視対象の異常発生を認識し、監視カメラデータ７４の優先度を上げると、QoS帯域保証が監視カメラデータ７４に独占され、優先度の低いセンサデータ７２、７３を送ることができないことになる。更に、アラート発生時のみ、QoS保証帯域を広げようとした場合、そのときのネットワークのトラフィック状態によっては、必ずしも必要なQoS保証帯域を確保できない。

一方、図７の下段に示す本実施例の場合においては、上述の通り、優先度を決定、すなわち優先順位を決めた上で、送出可能な帯域７５に併せて、センシングデータ７１、監視カメラデータ７４、センシングデータ７２、７３の圧縮方法を選択するため、ネットワークのトラフィック状態に係らず、常に全ての通信端末からのデータを送出することができる。

以上詳述したように、本実施例のモニタリングシステムにおいては、ステータスに応じて、複数の通信端末からのデータの優先順序を決定し、更にネットワークで送出可能な帯域にあわせて圧縮方法を選択するため、ネットワークのトラフィック状態に係らず、複数の通信端末からのデータをその優先度に応じた送出順序で、全て送信することが可能となる。

次に、広域ネットワーク状況推定処理部の第２の実施例として、ＴＣＰによるフロー制御のウィンドウサイズ情報を使用する場合を説明する。

ＴＣＰによるフロー制御では、データを受信する側が送信する側にデータを受け取った旨を知らせるＡＣＫ(Acknowledge)信号を返す際、ＴＣＰヘッダのフォーマットに合わせてウィンドウサイズ情報を伝える。このウィンドウサイズ情報は、受信する側が一度に受け取れるパケット量、すなわち受信する側のバッファの空き具合を表す。ウィンドウサイズが小さい時は送信側で送り出す量を減らすことでパケットの輻輳を低減し、ウィンドウサイズが大きい時は送信側で送り出す量を増やすことでスループットを上げるよう制御する。このウィンドウサイズ情報は、上述した第１の実施例で説明した広域ネットワーク状況と必ずしも一致はしないが、広域ネットワーク状況の判断指標の一つとして利用可能であり、図３に示したネットワーク相互接続装置１１の広域ネットワーク状況推定処理部３７においてＴＣＰヘッダ内のウィンドウサイズ情報を抽出し、利用することができる。

次に、第３の実施例として、モニタリングシステムの他の通信システムの構成例について説明する。

図１５に第３の実施例に係る、各種のモニタリングを実現可能なモニタリングシステムの全体構成図を示す。同図において、図１の通信システムとの差分は、図１５の通信システムにおいては、三層モデルになっており、ローカルエリアネットワーク１４のエッジノード２９にセンサ２６、２７、監視カメラ２８、更には監視装置などが接続され、エッジノード２９がセンシングデータやカメラデータのフィルタリングを行う。すなわち、実施例１、２におけるネットワーク相互接続装置１１のフィルタリング処理部の役割を一部分担する構成とすることができる。

次に、第４の実施例として、プラント設備の遠隔監視システムの構成例について説明する。

図１６に第４の実施例に係る、プラント設備の遠隔監視システムの全体構成図を示す。同図では、プラント設備内ネットワーク１６１に、監視カメラ１（１６２）、監視カメラ２（１６８）音声通信端末１（１６３）が接続される。ネットワーク相互接続装置１１がカメラ画像や音声データのフィルタリングを行い、広域ネットワーク１０を介して、管理センタ１３内の音声通信端末１６４と監視モニタ１６５に接続される。プラント設備にある監視カメラ１６２からの映像は、管理センタ内にある監視モニタ１６５に表示される。管理センタ１３にいる監視員１６７は、監視モニタ１６５の映像を見て、プラント設備内の状況を把握することが出来る。プラント設備にいる作業員１６６は、必要に応じて、プラント設備側の音声通信端末１６３と、管理センタ側の音声通信端末１６５を介して、管理センタにいる監視員１６７と通話することが出来る。音声通信は、作業員１６６からも、監視員１６７からも開始することが出来る。音声通信を開始したい時には、作業員１６６は音声通信端末１６３を通じて、音声伝送開始要求コマンドをネットワーク相互接続装置１１に送信する。監視員１６７も同様に、音声通信端末１６５を通じて、音声伝送開始要求コマンドをネットワーク相互接続装置１１に送信する。

第４の実施例においても、図４と同様に優先度制御部３４の優先順／フィルタ種別選択処理部３７の処理を行う。本実施例の場合、イベント検知４１の内容であるイベントステータスとしては、「音声通信端末１６３または１６５からの音声伝送開始要求コマンドの検知」や、「伝送パケットの解析による音声伝送の検知」等音声通信に関するイベントが検知された際のステータスと、検知されない際のステータスが考えられる。

図１７Ａ、図１７Ｂに、上記音声イベント検知の際に使用するステータス用テーブルの一例を示す。図１７Ａにおいて、ステータス用テーブル１７１は図５Ａのテーブル５３同様、テーブル構成要素として、圧縮度、圧縮率、送出順序、フィルタ種別を有し、圧縮度１、２，３に対応して、それぞれ図示の通りの圧縮率１．０、０．６、０．４を有する。送出順序の項では、どの端末からくるデータであるかを特定するため、先に図１８で説明した端末種別１８２と端末ＩＤ１８３を指定する。フィルタ種別の項では、送出順序の項で特定したデータに対し、フィルタリング処理部３３で加える処理の種類を指定する。本実施例の場合、送出順序の項で指定される端末種別は「監視カメラ」と「音声通信端末」の２種類となる。また、端末ＩＤは実施例１と異なり、「監視カメラ」１〜ｎ、「音声通信端末」１〜ｎ、と端末種別毎に付与する。図１７Ａのテーブル１７１は、前述の音声に関するイベントが検知されていない場合のステータス用テーブルを想定しており、送出順序は圧縮度によらず、「監視カメラ」１〜ｎ、「音声通信端末」１〜ｎの順に指定する。「音声通信端末」については、フィルタ種別も圧縮度によらず、常に「圧縮」を指定する。「監視カメラ」のフィルタ種別は、圧縮度に応じて、圧縮度１ではフィルタリングなし、圧縮度２では「間引き・縮小・圧縮」、圧縮度３では「特徴抽出」を指定する。

同様に図１７Ｂのステータス用テーブル１７２は、前述の音声に関するイベントが検知された場合のステータス用テーブルを想定しており、図１７Ａのステータス用テーブル１７１との差異は、送出順序やフィルタ種別において、音声イベントが検知された音声通信端末１のデータを優先的に送出する点である。他の送出データは図４の処理フローによって選択された圧縮度に応じてフィルタリングを適用する。

第４の実施例によれば、ネットワーク相互接続装置１１は前述の音声に関するイベント検知によってカメラ画像、音声間の優先度を決定し、プラント設備内ネットワークと広域ネットワークの状態に対応して圧縮度を選択することで、ネットワークのトラフィック状態に係らず、通話品質の高い音声通信が可能である。

本発明はセンサや監視カメラを利用したモニタリングシステム、特に広帯域網の帯域制限を考慮した優先度制御を行うモニタリング技術として有用である。

１０…広域ネットワーク
１１…ネットワーク相互接続装置
１２…通信端末
１３…管理センタ
１４…ローカルネットワーク
２０…監視装置
２１…センサ１
２２…センサ２
２３…センサ３
２４…監視カメラ４
２５…監視カメラ５
２６、２７…センサ
２８…カメラ
２９…エッジノード
３１…ローカルネットワーク通信処理部
３２…バッファリング処理部
３３…フィルタリング処理部
３４…優先度制御部
３５…ローカルネットワークデータ統計処理部
３６…広域ネットワーク状況推定処理部
３７…優先順/フィルタ種別選択処理部
３８…送出データ選択処理部
３９…広域ネットワーク通信処理部
５１、５２、５３…ステータスＡ、Ｂ、Ｃ用テーブル
６１、６２、１７１、１７２…ステータス用テーブル
７１、７２、７３…センシングデータ
７４…監視カメラデータ
７５…送出可能な帯域
１１１、１２１…ローカルネットワーク通信Ｉ／Ｆ
１１２、１２２、１３２…ＣＰＵ
１１３１２３、１３３…プログラム格納用メモリ
１１４、１２４、１３４…演算用メモリ
１１５、１３５…ハードウェアアクセラレータ
１１６、１２６、１３６…広域ネットワーク通信Ｉ／Ｆ
１１７、１２７、１３７…内部バス。
１６１…プラント設備内ネットワーク
１６２、１６８…監視カメラ
１６３、１６４…音声通信端末
１６５…監視モニタ
１６６…作業員
１６７…監視員
１８０…ヘッダ情報
１８１…センシング情報
１８２…端末種別
１８３…端末ＩＤ
１８４…時刻情報。

Claims (11)

1. 第１のネットワークを介して複数の通信端末から送信される情報である第１のデータおよび前記第１のデータと異なる種類のデータである第２のデータを含む複数のデータを受信し、第２のネットワークを介して管理センタに送信するよう制御する通信制御装置であって、
   前記第１のネットワークと前記第２のネットワークとそれぞれ通信を行う通信部と、処理部と、記憶部とを備え、
   前記記憶部は、
   イベントステータスに対応し、送出すべきデータの送出順序と、前記第１のデータおよび前記第２のデータに使用するフィルタの組み合わせと、が前記管理センタに送出すべき前記複数のデータの圧縮度に紐付いたテーブルを複数記憶しており、
   前記処理部は、
   前記通信部を介して受信した前記複数のデータに基づきイベントステータスを抽出し、前記第２のネットワークの通信状況を推定し、
   前記第２のネットワークの通信状況に応じて前記管理センタに送出すべき前記複数のデータの圧縮度を選択し、
   前記イベントステータスに基づき選択されたテーブルと前記圧縮度に基づき、送出すべき前記複数のデータの送出順序と、前記第１のデータに使用するフィルタおよび前記第２のデータに使用するフィルタの組み合わせを決定し、
   当該決定されたフィルタの組み合わせによりフィルタリング処理を経た後の前記複数のデータを前記第２のネットワークへ送信する、
   ことを特徴とする通信制御装置。
2. 請求項１に記載の通信制御装置であって、
   前記複数の通信端末は、少なくとも１個のセンサと、少なくとも１個のカメラを含み、
   前記第１のデータは前記センサから送信され、前記第２のデータは前記カメラから送信される、
   ことを特徴とする通信制御装置。
3. 請求項１に記載の通信制御装置であって、
   前記処理部は、
   前記第２のネットワークの通信状況を、送出すべき前記データの前記第２のネットワークへの送信時刻と前記データの前記管理センタでの受信時刻の時刻差に基づいて決定する、
   ことを特徴とする通信制御装置。
4. 請求項１に記載の通信制御装置であって、
   前記処理部は、
   前記送出データの前記第２のネットワークへの送信時刻と前記送出データの前記管理センタでの受信時刻の時刻差に基づき、前記管理センタが決定した前記第２ネットワークの通信状況を、前記管理センタから周期的にフィードバックされる、
   ことを特徴とする通信制御装置。
5. 請求項１に記載の通信制御装置であって、
   前記処理部は、
   前記通信部を介して受信した前記管理センタからの受信データに基づき、前記第２のネットワークの通信状況を推定する、
   ことを特徴とする通信制御装置。
6. 通信部と、処理部と、記憶部とを備え、第１のネットワークを介して複数の通信端末からのデータを受信し、第２のネットワークを介して管理センタに送信する通信装置の通信制御方法であって、
   前記処理部は、
   前記通信部を介して前記複数の通信端末からの前記データに基づきイベントステータスを抽出し、前記第１のネットワークと前記第２のネットワークの通信状況を推定し、
   前記第１のネットワークと前記第２のネットワークの通信状況に応じて送出すべき前記データの圧縮度を選択し、
   前記イベントステータスと前記圧縮度に基づき、送出すべき前記データの送信順序と圧縮方法を決定する、
   ことを特徴とする通信制御方法。
7. 請求項６に記載の通信制御方法であって、
   前記記憶部は、
   前記イベントステータスに対応し、送出すべき前記データの送出順序を記憶するテーブルを記憶しており、
   前記処理部は、
   前記イベントステータスに対応する前記テーブルに基づき、送出すべき前記データの送出順序を決定する、
   ことを特徴とする通信制御方法。
8. 請求項６に記載の通信制御方法であって、
   前記複数の通信端末は、少なくとも１個のセンサと、少なくとも１個のカメラを含む、
   ことを特徴とする通信制御方法。
9. 請求項６に記載の通信制御方法であって、
   前記処理部は、
   前記通信部を介して受信した前記管理センタからの受信データに基づき、前記第２のネットワークの通信状況を推定する、
   ことを特徴とする通信制御方法。
10. 請求項６に記載の通信制御方法であって、
    前記処理部は、
    前記第２のネットワークの通信状況を、送出すべき前記データの前記第２のネットワークへの送信時刻と前記データの前記管理センタでの受信時刻の時刻差に基づいて決定する、
    ことを特徴とする通信制御方法。
11. 請求項６に記載の通信制御方法であって、
    前記処理部は、
    前記送出データの前記第２のネットワークへの送信時刻と前記送出データの前記管理センタでの受信時刻の時刻差に基づき、前記管理センタが決定した前記第２のネットワークの通信状況を、周期的に前記管理センタからフィードバックされる、
    ことを特徴とする通信制御方法。

Images