(57)【要約】【課題】多数の設備機器でイベントが発生した場合でも、遠隔監視装置に過剰な負荷をかけることなく、当該イベントデータを収集する。【解決手段】本発明の一態様としての遠隔監視システムは、複数の通信装置と遠隔監視装置とを備え、前記遠隔監視装置は、前記複数の通信装置との通信に利用可能な総帯域幅に基づき、前記複数の通信装置にそれぞれ対応する設備機器で発生したイベントデータの送信可能な時刻を記述したイベントデータ送信スケジュールを前記通信装置毎に生成するスケジュール作成部と、前記イベントデータ送信スケジュールを前記通信装置に送信する送信部と、前記通信装置から前記イベントデータを含むイベントデータメッセージを受信する受信部とを備える。【選択図】図１
2014082723.tif 000002
【特許請求の範囲】
【請求項１】
それぞれ設備機器を管理する複数の通信装置と、前記複数の通信装置とネットワークを介して通信する遠隔監視装置とを備えた遠隔監視システムであって、
前記遠隔監視装置は、
前記複数の通信装置との通信に利用可能な総帯域幅に基づき、前記複数の通信装置にそれぞれ対応する設備機器で発生したイベントデータの送信可能な時刻を記述したイベントデータ送信スケジュールを前記通信装置毎に生成するスケジュール作成部と、
前記イベントデータ送信スケジュールを前記通信装置に送信する送信部と、
前記通信装置から前記イベントデータを含むイベントデータメッセージを受信する受信部と、を備え、
前記通信装置は、
前記イベントデータ送信スケジュールを前記遠隔監視装置から受信する受信部と、
前記通信装置に対応する設備機器で発生したイベントデータを検出する検出部と、
前記検出部により検出されたイベントデータを格納するバッファと、
前記イベントデータ送信スケジュールに従って、前記バッファから選択したイベントデータを含むイベントデータメッセージを前記遠隔監視装置に送信するよう制御するイベントメッセージ送信制御部と
を備えた遠隔監視システム。
【請求項２】
前記スケジュール作成部は、任意の時刻で各前記通信装置により利用される帯域幅の統計的代表値が上限値を下回るように、前記イベント送信スケジュールを作成する
ことを特徴とする請求項１に記載の遠隔監視システム。
【請求項３】
前記統計的代表値は、任意の時刻で各前記通信装置により前記イベントデータメッセージの送信に利用される帯域幅の合計の期待値または最大値を含む
ことを特徴とする請求項２に記載の遠隔監視システム。
【請求項４】
前記スケジュール作成部は、任意の時刻で各通信装置により前記イベントデータメッセージの送信に利用される帯域幅の合計がある信頼確率で上限値を下回るように、前記イベント送信スケジュールを作成する
ことを特徴とする請求項１に記載の遠隔監視システム。
【請求項５】
前記スケジュール作成部は、前記通信装置が送信する任意の種別のイベントデータの送信可能な時刻の間隔が上限値を下回るように前記イベントデータ送信スケジュールを作成する
ことを特徴とする請求項１に記載の遠隔監視システム。
【請求項６】
前記遠隔監視装置は、前記通信装置からのプロセスデータの収集スケジュールにしたがって、前記通信装置へリクエストメッセージを送信するよう制御する通信制御部を有し、
前記通信装置は、前記遠隔監視装置から受信したリクエストメッセージにしたがって前記設備機器からプロセスデータを取得する取得部と、前記プロセスデータを含むレスポンスメッセージを前記遠隔監視装置に送信する送信部を有する
ことを特徴とする請求項１に記載の遠隔監視システム。
【請求項７】
前記スケジュール作成部は、任意の時刻で各前記通信装置により送信される前記イベントデータメッセージおよび前記レスポンスメッセージにより占められる帯域幅の統計的代表値が上限値を下回るように、前記イベント送信スケジュールおよび前記プロセスデータの収集スケジュールを作成する
ことを特徴とする請求項６に記載の遠隔監視システム。
【請求項８】
前記統計的代表値は、前記任意の時刻で各前記通信装置により送信される前記イベントデータメッセージおよび前記レスポンスメッセージにより占められる帯域幅の合計の期待値または最大値を含む
ことを特徴とする請求項７に記載の遠隔監視システム。
【請求項９】
前記スケジュール作成部は、任意の時刻で各通信装置により送信される前記イベントデータメッセージおよび前記レスポンスメッセージにより占められる帯域幅の合計がある信頼確率で上限値を下回るように、前記イベント送信スケジュールおよび前記プロセスデータの収集スケジュールを作成する
ことを特徴とする請求項６に記載の遠隔監視システム。
【請求項１０】
前記通信装置は、前記レスポンスメッセージに前記プロセスデータとともに前記バッファから選択したイベントデータを含め、前記イベントデータと前記プロセスデータとを含む前記レスポンスメッセージを前記遠隔監視装置に送信する
ことを特徴とする請求項７ないし９のいずれか一項に記載の遠隔監視システム。
【請求項１１】
前記スケジュール作成部は、前記イベントデータメッセージと前記レスポンスメッセージとの両方によって送信可能な任意の種別のイベントデータの送信可能な時刻の間隔が、上限値を下回るように前記イベントデータ送信スケジュールおよび前記プロセスデータの収集スケジュールを作成する
ことを特徴とする請求項１０に記載の遠隔監視システム。
【請求項１２】
複数の通信装置との通信に利用可能な総帯域幅に基づき、前記複数の通信装置にそれぞれ対応する設備機器で発生したイベントデータの送信可能な時刻を記述したイベントデータ送信スケジュールを前記通信装置毎に生成するスケジュール作成部と、
前記イベントデータ送信スケジュールを前記通信装置に送信する送信部と、
前記通信装置から前記イベントデータを含むイベントデータメッセージを受信する受信部と
を備えた遠隔監視装置。
【請求項１３】
設備機器で発生したイベントデータの送信可能な時刻を記述したイベントデータ送信スケジュールを遠隔監視装置から受信する受信部と、
前記設備機器で発生したイベントデータを検出する検出部と、
前記検出部により検出されたイベントデータを格納するバッファと、
前記イベントデータ送信スケジュールに従って、前記バッファから選択したイベントデータを含むイベントデータメッセージを前記監視装置に送信するよう制御する送信制御部と
を備えた通信装置。
【請求項１４】
遠隔監視装置が複数の通信装置との通信に利用可能な総帯域幅に基づき、前記複数の通信装置にそれぞれ対応する設備機器で発生したイベントデータの送信可能な時刻を記述したイベントデータ送信スケジュールを前記通信装置毎に生成するステップと、
前記イベントデータ送信スケジュールを前記遠隔監視装置から前記通信装置に送信するステップと、
前記設備機器で発生したイベントデータを検出し、前記イベントデータをバッファに格納するステップと、
前記イベントデータ送信スケジュールに従って、前記バッファから選択したイベントデータを含むイベントデータメッセージを前記通信装置から前記監視装置に送信するステップと、
を備えた遠隔監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ネットワークを経由して遠隔地にある複数の設備機器を監視する技術に関する。
【背景技術】
【０００２】
オフィスや商業施設などを収容するビルには多くの設備機器が設置されている。このような設備機器には照明、空調、エレベータやエスカレータ、防犯・防災機器などが含まれ、ビル管理システムによって監視・制御される。近年では、これらの設備機器の監視や制御をインターネットなどの通信網を通じて遠隔地から行う技術がある。このような設備機器の遠隔監視制御技術を用いることで、多くのビルの設備機器を一箇所のリモートセンターで管理することが可能となり、各ビルに対して低コストでビル管理サービスを提供することができる。
【０００３】
一般に設備機器の遠隔監視制御システムでは、ビル内部にある設備機器の動作状態やセンサ機器で計測されるデータ(プロセスデータと呼ぶ)を、リモートセンターがそれぞれ一定の周期で繰り返し収集することで設備機器の監視を行う。このようにリモートセンターがポーリングを行う方式による設備機器監視には、複数のビルに渡って通信のタイミングを調整することによって、プロセスデータ収集における通信帯域の利用効率を高めることができるという利点がある。
【０００４】
しかし、設備機器を監視する上ではプロセスデータの定期的な収集の他に、何らかのきっかけで設備機器が生成する情報(イベントデータと呼ぶ)を監視することも重要となる。イベントデータには例えば、設備機器の故障や異常を通知するデータや、防災用機器が災害を検出した際にそれを通知するデータがある。イベントデータは平常時には存在しないが、特定のイベントが発生した際になるべく早く検出される必要があるという点で、プロセスデータとは性質が異なる。そのため、一般的なビル管理システムでは設備機器がイベントを検出した時点で自ら中央の監視システムへそのイベントデータを通知するようにしている。
【０００５】
しかし、遠隔監視制御システムにおいて設備機器が任意のタイミングで自らイベントデータをリモートセンターへ送信する場合、監視対象の多数のビルで同時にイベントが発生した場合にシステムが不安定になる危険がある。多数のビルで同時にイベントが発生すると、各ビルから送信されるイベントデータがリモートセンターに殺到し、リモートセンター側の通信機器や制御機器に過剰な負荷がかかる。このような状況では、リモートセンターによるプロセスデータの定常収集に支障をきたすばかりでなく、最悪の場合はシステムがダウンすることで全ビルへのビル管理サービスが停止する危険性もある。
【０００６】
このように、いつ送信されてくるか分からないデータの殺到を防ぐための手法は従来からいくつか提案されている。１つの手法では、データの送信を希望する機器(クライアント)はまずアクセスタイミング管理サーバへアクセスする。アクセスタイミング管理サーバは、データを受信するサーバの負荷状況などを考慮して、クライアントがデータを送信すべき適切なタイミングを計算し、クライアントへ通知する。クライアントは通知されたタイミングまで待機した後に、サーバへデータを送信する。この方法では、データの送信による負荷集中を防ぐことはできるものの、非常に多くのクライアントが同時にデータ送信を希望した場合、送信までの待機時間が無制限に長くなる問題がある。
【０００７】
別のアプローチとしては、イベントデータもプロセスデータと同様にリモートセンターからのポーリングで取得するという方法が考えられる。この場合、イベントデータの検出遅延を十分に小さく抑えるために、リモートセンターは許容される検出遅延よりも短い周期でビルに対してイベントの有無を問い合わせる必要がある。しかし、前述のようにイベントデータはイベントが発生した時のみ存在するデータであるため、リモートセンターからのポーリングによる問い合わせはほとんどの場合無意味なものとなる。このような無意味な通信はリモートセンターやビル側の通信機器(ビルゲートウェイと呼ぶ)の負荷コストをいたずらに増大させることにつながり、望ましくない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開2010-263337号公報
【特許文献２】特開2010-231353号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
以上で述べたように、多数のビルの設備機器を遠隔から監視するシステムにおいては、監視対象とする大量の設備機器から同時にイベントデータが送信された場合にシステムが不安定になるという問題があった。また、これを防ぐための従来の手法には、イベントの検出遅延が長くなる、ビル側の機器ならびにリモートセンターに余計な負荷を与えるなどの問題があった。
【００１０】
本発明の一側面は、上記の問題を鑑みてなされたものであり、多数の設備機器でイベントが発生した場合でも、遠隔監視装置に過剰な負荷をかけることなく、当該イベントデータを収集することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の一態様としての遠隔監視システムは、それぞれ対応する設備機器を管理する複数の通信装置と、前記複数の通信装置とネットワークを介して通信する遠隔監視装置とを備える。
【００１２】
前記遠隔監視装置は、スケジュール作成部と、送信部と、受信部とを備える。
【００１３】
前記スケジュール作成部は、前記複数の通信装置との通信に利用可能な総帯域幅に基づき、前記複数の通信装置にそれぞれ対応する設備機器で発生したイベントデータの送信可能な時刻を記述したイベントデータ送信スケジュールを前記通信装置毎に生成する。
【００１４】
前記送信部は、前記イベントデータ送信スケジュールを前記通信装置に送信する。
【００１５】
前記受信部は、前記通信装置から前記イベントデータを含むイベントデータメッセージを受信する。
【００１６】
前記通信装置は、受信部と、検出部と、バッファと、送信制御部とを備える。
【００１７】
前記受信部は、前記イベントデータ送信スケジュールを前記遠隔監視装置から受信する。
【００１８】
前記検出部は、前記通信装置に対応する設備機器で発生したイベントデータを検出する。
【００１９】
前記バッファは、前記検出部により検出されたイベントデータを格納する。
【００２０】
前記送信制御部は、前記イベントデータ送信スケジュールに従って、前記バッファから選択したイベントデータを含むイベントデータメッセージを前記遠隔監視装置に送信するよう制御する。
【図面の簡単な説明】
【００２１】
【図１】第１の実施形態の全体のシステム構成を示す図。
【図２】リモートセンターの内部構成を示す図。
【図３】あるビルゲートウェイについてのビルゲートウェイ情報の例を示す図。
【図４】プロセスデータ収集スケジュールの例を示す図。
【図５】イベントデータ送信スケジュールの例を示す図。
【図６】リモートセンターの動作フローを示す図。
【図７】イベントデータ送信スケジュールの作成方法を説明するための図。
【図８】累積分布関数の例を示す図。
【図９】ビルゲートウェイの内部構成を示す図。
【図１０】ビルゲートウェイの動作のフローチャートを示す図。
【図１１】第２の実施形態におけるプロセスデータ収集スケジュールの形式を示す図。
【図１２】第２の実施形態におけるリモートセンターの動作フローチャートを示す図。
【図１３】イベントデータをプロセスデータメッセージに相乗りさせるための送信スケジュールの例を示す図。
【図１４】第２の実施形態におけるビルゲートウェイの内部構成を示す図。
【図１５】第２の実施形態におけるビルゲートウェイの動作フローチャートを示す図。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態について説明する。
【００２３】
（第１の実施形態）
図１に、本発明の第１の実施形態の全体のシステム構成を示す。このシステムでは、リモートセンター（遠隔監視装置）１１がネットワーク１２を通じて一つないし複数のビルの設備機器を遠隔監視する。各ビルの内部にある設備機器は一つないし複数のビルゲートウェイと呼ばれる機器（通信装置）によって管理されており、リモートセンターは各ビルゲートウェイと直接通信することで設備機器を監視する。ビルゲートウェイ１３、１４は同じビルに配置されており、ビルゲートウェイ１５は、別のビルに配置されている。ビルゲートウェイ１３は設備機器１３ａ、１３ｂ、１３ｃを管理し、ビルゲートウェイ１４は設備機器１４ａ、１４ｂ、１４ｃを管理している。ビルゲートウェイ１５は、設備機器１５ａ、１５ｂを管理している。
【００２４】
リモートセンター１１は設備機器のプロセスデータを監視するために、各ビルゲートウェイ１３〜１５に対して定期的にリクエストメッセージを送る。リクエストメッセージを受け取ったビルゲートウェイは、リクエストされた設備機器のプロセスデータを取得し、プロセスデータを含むプロセスデータメッセージをレスポンスメッセージとしてリモートセンター１１に返信する。
【００２５】
ビルゲートウェイ１３〜１５は自身の管理する設備機器でイベントデータが発生すると、そのデータを一時的に記憶し、適切なタイミングでリモートセンター１１へ送信する。イベントデータの送信に適切なタイミングは、それぞれのビルゲートウェイについてイベントデータ送信スケジュールとしてあらかじめリモートセンター１１が計画し、ビルゲートウェイに通知しておく。
【００２６】
図２に、リモートセンター１１の内部構成図を示す。リモートセンター１１は、プロセスデータを収集する際のスケジュール(プロセスデータ収集スケジュール)の作成、各ビルゲートウェイがイベントデータを送信してよいタイミングを記述したイベントデータ送信スケジュールの作成、プロセスデータ収集スケジュールに従ったリクエストメッセージの送信、各ビルゲートウェイからのメッセージの受信といった処理を行う。
【００２７】
ビルゲートウェイ情報格納部３１には、リモートセンター１１が監視する各ビルゲートウェイについて、それらのビルゲートウェイが管理するプロセスデータとイベントデータの一覧を示すビルゲートウェイ情報を格納する。図３に、あるビルゲートウェイについてのビルゲートウェイ情報の例を示す。図に示すように、ビルゲートウェイが管理する各データについて、データID、データ種別、データの発生源となる設備、データのサイズ、イベントデータの緊急度、設備の種別などの情報が管理される。これらの情報は、リモートセンター１１にビルゲートウェイを接続する際にビルやビルゲートウェイの管理者からリモートセンター１１の管理者に伝えられる。
【００２８】
プロセスデータ収集スケジュール格納部２１には、リモートセンター１１が各ビルゲートウェイから設備機器のプロセスデータを収集するスケジュールデータが格納される。このスケジュールを、プロセスデータ収集スケジュールと呼ぶ。図４に、プロセスデータ収集スケジュールの例を示す。図に示すように、プロセスデータ収集スケジュールには、いつ、どのビルゲートウェイから、どのプロセスデータを収集するかが記述されている。ビルゲートウェイへ要求するプロセスデータはビルゲートウェイ情報格納部３１に記録されたデータIDを参照して指定される。リモートセンター１１は、プロセスデータ収集スケジュールに従ってプロセスデータを収集する。
【００２９】
イベントデータ送信スケジュール格納部２２には、ビルゲートウェイそれぞれについてイベントデータを送信してもよい時間帯を記述したスケジュールデータが格納される。このスケジュールを、イベントデータ送信スケジュールと呼ぶ。図５に、イベントデータ送信スケジュールの例を示す。図のイベントデータ送信スケジュールは図３で示したビルゲートウェイに対するものであり、このビルゲートウェイがイベントデータを送信可能な時間帯(開始時刻 〜 終了時刻)と、その時間帯で送信可能なイベントのパターン、及びその時間帯に割り当てられる帯域幅を記述している。図５のイベントデータ送信スケジュールがあるとき、例えば２０１２年７月２日の１０:２２に設備１１からのイベントデータが発生した場合、ビルゲートウェイはそのイベントデータを即座にリモートセンターへ送信する。しかし、１０:４５に設備１１でイベントデータが発生した場合、その時刻にはイベントデータ送信が許可されていないので、そのイベントデータは一時的にビルゲートウェイに蓄積される。その後、１０:５０になると、全てのイベントを送信可能な時間帯に入るため、ビルゲートウェイは蓄積されたイベントデータを送信する。このように、各ビルゲートウェイはイベントデータ送信スケジュールで許可された時間帯でのみ、その時間帯で割り当てられた帯域を利用してイベントデータの送信を行い、それ以外の時間帯で発生したイベントデータは適宜、送信を遅延させる。
【００３０】
イベントデータ送信スケジュールには、各時間帯において例えば以下に示すような基準を用いて、送信可能なイベント種別を設定することができる。
・  全てのイベント
・  特定の設備機器で発生したイベント
・  特定の種類の設備機器で発生したイベント
・  特定の物理的位置に設置されている設備機器で発生したイベント
・  特定の緊急度を持つイベント
スケジュール作成部２３は、プロセスデータ収集スケジュール及び各ビルゲートウェイに向けたイベントデータ送信スケジュールを作成する。なお、本実施例ではスケジュール作成部２３はリモートセンター１１に含まれているものとしているが、リモートセンターの外部にスケジュール作成部２３がある構成も可能である。
【００３１】
プロセスデータリクエスト作成部２４は、プロセスデータ収集スケジュールに記述されたリクエスト内容を読み出し、プロセスデータを収集する際にビルゲートウェイへ送信するリクエストメッセージを作成する。
【００３２】
イベントデータ送信スケジュール通知作成部２５は、イベントデータ送信スケジュールを読み出し、そのスケジュールデータを対象のビルゲートウェイへ通知するためのメッセージを作成する。
【００３３】
通信タイミング制御部（通信制御部）２６は、リモートセンター１１が送信するメッセージとそのタイミングを制御する。具体的には、プロセスデータ収集スケジュールと時計を参照し、プロセスデータを収集する時刻になったらプロセスデータリクエスト作成部２４からリクエストメッセージを取得して、宛先ビルゲートウェイへ送信する。また、イベントデータ送信スケジュール通知作成部２５からイベントデータ送信スケジュール通知メッセージを受け取った場合、そのメッセージを宛先ビルゲートウェイへ送信する。
【００３４】
送信部２８は、ビルゲートウェイに対して様々なメッセージを送信する機能であり、通信タイミング制御部２６によって制御される。
【００３５】
受信部２９は、ビルゲートウェイから送信されるメッセージを受信し、受信メッセージ処理部３０へ転送する。ビルゲートウェイから送信されるメッセージには、プロセスデータリクエストメッセージに対するレスポンスメッセージ（プロセスデータメッセージ）と、イベントデータメッセージの２種類がある。
【００３６】
受信メッセージ処理部３０は、受信部２９で受信されたメッセージを受け取り、メッセージの種類に応じて適切な処理を行う。
【００３７】
図６に、リモートセンター１１の動作フローを示す。
【００３８】
リモートセンター１１は動作を開始するとまずスケジュール作成部２３によってプロセスデータ収集スケジュールを作成する（Ｓ１０１）。プロセスデータ収集スケジュール作成の際には、監視対象とする設備機器の数や種類、各ビルゲートウェイの性能やネットワークの帯域幅などを考慮し、多くの設備機器を効率よく安定して収集できるようにスケジューリングが行われる。この際、ビルゲートウェイにプロセスデータのリクエストメッセージを送信してからレスポンスメッセージが返ってくるまでの時間などの通信特性を事前に計測しておき、計測した通信特性を利用してプロセスデータ収集スケジュールを作成してもよい。
【００３９】
プロセスデータ収集スケジュールを作成すると、リモートセンターは次に各ビルゲートウェイに対するイベントデータ送信スケジュールを作成する（Ｓ１０２）。図７に示すように、イベントデータ送信スケジュールは、以下の点に留意して作成する。
・  任意の時刻において、ビルゲートウェイに割り当てられる帯域幅の合計がシステムの帯域幅(リモートセンターが各ビルゲートウェイとの通信に利用可能な総帯域幅であり、リモートセンター内部の設備や、リモートセンターとビルゲートウェイをつなぐネットワークの性能で決まる)を下回るよう、各ビルおよび設備機器におけるイベント送信可能時刻を分散させる。このようにすることで、多数のビルや設備機器において同時にイベントデータが発生した場合でも、それらが一度にリモートセンターに殺到して過負荷をかけることを防ぐことができる。
・  送信可能時間帯の時間幅、送信可能イベント種別及び割り当て帯域幅は、その時間帯でなるべく全てのイベントを送信できるように調整する。具体的には、時間幅と帯域幅の積で算出される送信容量が、送信可能イベント種別の設定により選択されるイベントデータのデータサイズの合計を上回るように設定するのが望ましい。このようにすることで、送信可能なイベントを時間内に全て送信できる可能性が高まり、イベントの検出遅延を抑えることができる。なお、送信可能イベント種別の設定により選択されるイベントとそのデータサイズは、ビルゲートウェイ情報格納部３１から得ることができる。
・  特にプロセスデータ収集が予定される時刻においては、プロセスデータ収集で必要となる通信帯域幅やリモートセンターの処理能力を考慮して、送信を許可されるイベントデータの種別と割り当て帯域幅を制限する。このようにすることで、多数のビルや設備機器において同時にイベントデータが発生した場合でも、イベントデータ送信によってプロセスデータ収集が妨害されることを防ぐことができる。
・  任意のイベントデータの送信可能時間帯は、できるだけ等間隔になるよう時間的に分散して設定する。また、これらのイベントデータ送信可能時間帯の間隔は、システムで許容される検出遅延の上限値よりも短くなるように設定する。このようにすることで、イベントデータ発生から送信までの遅延をあらかじめ設定した上限値以下に抑えることができる。
【００４０】
以上で示したイベントデータ送信スケジュールの作成法は、イベント送信可能となった全てのビルゲートウェイが実際にイベントデータを送信した場合であってもシステムに過負荷がかからないようにするものである。
【００４１】
しかし、イベントデータの中には、同時に発生する可能性が低いものがある。例えば、地理的に十分に離れた二つのビルの異なる種類の設備機器で同時にイベントが発生する可能性は低いと考えられる。そのようなイベントデータに対するイベント送信可能時刻を積極的に同じ時間帯に設定することで、イベント送信の機会を増やし、検出遅延を短縮することができる。
【００４２】
このようにイベントの生起確率を考慮に入れてイベントデータ送信スケジュールを作成する場合、上記のようにある時刻において割り当てられる帯域幅の合計を基準とするのではなく、その確率的・統計的な代表値を基準とし、その値がシステムの許容上限を下回るようにスケジュールの作成を行うことができる。この場合、割り当てられた帯域のうち、実際にビルゲートウェイによって利用される帯域幅の合計は確率変数となる。この確率変数をXとおくと、実際に利用される帯域幅の期待値E(X)を基準とし、E(X)が帯域幅上限を下回るようにスケジュール作成を行う方法が可能である。また、Xがある変数x以下となる確率をf(x)と定義すると、f(x)はXの累積分布関数となり、これは一般に図８のような形状をとる。この時、あらかじめ設定した信頼確率をpとおき、p = f(xp)となる利用帯域幅xpを基準とし、xpが帯域幅上限を下回るようにスケジュールを行う方法も可能である。このようにスケジュール作成を行う場合、実際に利用される帯域幅の合計がシステムの帯域幅上限以下に収まる確率は、信頼確率p以上であることが保証される。
【００４３】
なお、先に示した、ビルゲートウェイに割り当てた帯域幅の合計を基準とする方法は、信頼確率pを１とおいた特殊な場合と考えることができる。p < 1なるpを用いてスケジュール作成を行うことで、システムの帯域幅上限を超えるイベントデータ送信が発生する可能性が生じることと引き換えに、イベントデータの送信機会を増やすことができる。
【００４４】
なお、本実施例では、スケジュール作成の一例として先にプロセスデータ収集スケジュールを作成し、その後でイベントデータ送信スケジュールを作成する方法を述べたが、これと異なる順序でスケジュールを作成することも可能である。例えば、イベントデータ送信スケジュールを作成してからプロセスデータ収集スケジュールを作成することもできるし、２種類のスケジュールを同時にかつ段階的に作成することも可能である。
【００４５】
以上のようにして全てのビルゲートウェイに対するイベントデータ送信スケジュールを作成すると、リモートセンター１１はそれらを各ビルゲートウェイへ通知する（Ｓ１０３）。イベントデータ送信スケジュール通知を受けたビルゲートウェイは、以降、それぞれのスケジュールに従ってイベントデータ送信を行う。
【００４６】
イベントデータ送信スケジュールの通知が完了すると、リモートセンター１１はプロセスデータの収集を開始する（Ｓ１０４）。通信タイミング制御部２６が時計２７とプロセスデータ収集スケジュールを参照し、プロセスデータ収集スケジュールで示されたタイミングで、指定された設備機器のプロセスデータリクエストを作成し、宛先となるビルゲートウェイへ送信する（Ｓ１０５、Ｓ１０６、Ｓ１０７、Ｓ１０８）。
【００４７】
プロセスデータ収集中のリモートセンターは、ビルゲートウェイから送信されてくるメッセージを受け付ける（Ｓ１０５、Ｓ１０９）。ビルゲートウェイからのメッセージにはプロセスデータリクエストへのレスポンスであるプロセスデータメッセージと、イベントデータメッセージがある。受信メッセージがプロセスデータメッセージである場合（Ｓ１１０の「プロセスデータ」）、受信したプロセスデータをデータベースへ格納する（Ｓ１１１）。受信メッセージがイベントデータメッセージである場合（Ｓ１１０の「イベントデータ」）、受信したイベントデータを記録するとともに、リモートセンター１１の管理者にイベント内容を通知する（Ｓ１１２）。
【００４８】
以上が、リモートセンターの内部構造及び動作フローである。
【００４９】
図９に、ビルゲートウェイの内部構成図を示す。ビルゲートウェイはリモートセンター１１からのプロセスデータリクエストに応答してプロセスデータを送信するとともに、設備機器で発生するイベントデータを監視し、適切なタイミングでイベントデータをリモートセンターへ送信する。
【００５０】
受信部４１は、リモートセンター１１から送信されるメッセージを受信し、メッセージ振り分け部４２に渡す。
【００５１】
メッセージ振り分け部４２は、メッセージがプロセスデータリクエストメッセージか、イベントデータ送信スケジュール通知メッセージか識別し、メッセージを適切な機能ブロックへ転送する。
【００５２】
プロセスデータリクエストメッセージはプロセスデータリクエスト処理部４３へ転送される。プロセスデータリクエスト処理部４３は、リクエストされた設備機器のプロセスデータを設備機器管理部４５から取得し、リモートセンター１１へのレスポンスメッセージを作成し、送信する。
【００５３】
イベントデータ送信スケジュール通知メッセージは、イベントデータ送信スケジュール通知受信処理部４６へ転送される。イベントデータ送信スケジュール通知受信処理部４６は、受信したイベントデータ送信スケジュールをイベントデータ送信スケジュール格納部４７へ格納する。
【００５４】
イベントデータ送信スケジュール格納部４７は、当該ビルゲートウェイにおけるイベントデータ送信スケジュールを保持する。
【００５５】
設備機器管理部４５は設備機器に直接接続され、プロセスデータの取得やイベントの監視を行う。ビルゲートウェイのプロセスデータリクエスト処理部４３やイベント監視部４８が直接設備機器と通信することも可能であるが、設備機器管理部４５によってビル内部の設備機器を集約管理する構成がより一般的である。設備機器で発生するイベントデータを検出する検出部は、設備機器管理部４５およびイベント監視部４８のどちらが備えていても良いが、本実施例では設備機器管理部４５が備えているとする。なお、本実施例では設備機器管理部４５はビルゲートウェイ内部の機能としたが、設備機器管理部４５がビルゲートウェイの外部に存在する構成も可能である。
【００５６】
イベント監視部４８は、設備機器管理部４５を経由して設備機器からのイベントデータを監視する。イベント監視部４８がイベントデータの発生を検出すると、そのイベントデータはイベントバッファ５１へ追加されるとともに、イベントメッセージ送信制御部４９へイベントの発生が通知される。
【００５７】
イベントメッセージ送信制御部４９は、イベントデータ送信スケジュールと時計５０を参照し、イベントバッファ５１内のイベントデータを適切なタイミングで送信する。イベントデータの送信を行う際には、送信データレートがイベントデータ送信スケジュールで割り当てられた帯域以下になるように調整する。
【００５８】
イベントバッファ５１は、送信待ちのイベントデータを一時的に記憶する記憶領域である。
【００５９】
図１０に、ビルゲートウェイの動作のフローチャートを示す。ビルゲートウェイはまず、リモートセンター１１からイベントデータ送信スケジュール通知を受信する（Ｓ２０１）。受信したイベントデータ送信スケジュールはイベントデータ送信スケジュール格納部４７に保存される。
【００６０】
その後、ビルゲートウェイはリモートセンター１１からのプロセスデータリクエストを待ち受けつつ、設備機器でイベントデータが発生した場合はそれを処理する。
【００６１】
より詳細には、ビルゲートウェイがリモートセンター１１からプロセスデータリクエストを受信した場合、設備機器管理部４５を経由して当該設備機器のプロセスデータを取得し、リモートセンター１１へ送信する（Ｓ２０２、Ｓ２０３、Ｓ２０４、Ｓ２０５）。
【００６２】
設備機器でイベントデータが発生した場合（Ｓ２０９）、それらは一旦全てイベントバッファ５１へ追加される（Ｓ２１０）。イベントバッファ５１へイベントが追加された後、ビルゲートウェイは時計５０とイベントデータ送信スケジュールを参照し、その時点で送信可能なイベントデータをイベントバッファ５１から選択して、当該イベントデータを含むイベントデータメッセージを送信する（Ｓ２０７、Ｓ２０８）。
【００６３】
イベントバッファ５１は優先度付きキューとなっており、ビルゲートウェイはイベントデータの優先度が高い順にデータを取り出し、送信する。あるイベントデータ送信可能時間帯の中で送信可能なイベントデータを全て送りきることができなかった場合、送信できなかったイベントデータはイベントバッファ５１内に残留し、次回以降にそれらが送信可能となった時間帯で送信される。なお、イベントデータの優先度は、イベントの緊急度（図３参照）が高いものほど高く、また、イベントが発生してからの経過時間が長いものほど高くなるように設定する。このようにすることで、イベントデータが大量に発生する場合であっても、イベント発生から送信までの遅延（検出遅延）をなるべく低く抑えることができる。なお、送信するすべてのイベントデータを、１つのイベントデータメッセージに含めることがプロトコル等の制約上不可の場合は、複数のイベントデータメッセージに分散して送信することも可能である。
【００６４】
イベントバッファ５１にイベントデータを追加する際にイベントバッファ５１の記憶領域に空きがない場合、イベントバッファ５１内のイベントデータと新たなイベントデータの優先度を調査し、最も優先度の低いイベントデータを破棄する。
【００６５】
現在時刻がイベントデータ送信スケジュールにおけるイベントデータ送信可能時間帯に新たに入った場合（Ｓ２０６）、ビルゲートウェイはイベントバッファ５１を参照し、その時間帯で送信可能なイベントデータがバッファ５１内にあるかどうかを確認する（Ｓ２０７）。そのようなイベントデータがある場合、ビルゲートウェイは前述と同様の手順でイベントバッファ５１からそのイベントデータを抜き出し、リモートセンター１１へ送信する（Ｓ２０８）。
【００６６】
以上が、ビルゲートウェイの内部構成及び動作フローである。
【００６７】
以上の記述では、リモートセンター１１とビルゲートウェイの定常的な動作について述べた。以下、リモートセンター１１に対して監視対象とするビルや設備機器の追加や削除が発生した場合について述べる。
【００６８】
リモートセンター１１が監視対象とするビルや設備機器が追加・削除された場合、リモートセンター１１はその変化に応じてスケジュールの再作成を行う。具体的には、図６で示すプロセスデータ収集スケジュール作成（Ｓ１０１）、イベントデータ送信スケジュール作成（Ｓ１０２）及びイベントデータ送信スケジュール通知メッセージの作成と送信（Ｓ１０３）を行う。以降は、リモートセンターは再作成したプロセスデータ収集スケジュールに従ってプロセスデータ収集を行う。
【００６９】
一方、ビルゲートウェイは再作成されたイベントデータ送信スケジュールを受信すると、以降はそのスケジュールに基づいてイベントデータの送信を行う。
【００７０】
以上、本実施形態によれば、監視対象とする設備機器で発生したイベントデータを低遅延でリモートセンターへ通知することが可能となる。また多数の設備機器で同時にイベントが発生した場合でも、それらのイベントデータがリモートセンターへ殺到するのを防ぐことができ、よって過剰な負荷をかけることなくイベントデータを収集できる。また、多数の設備機器で同時にイベントが発生した場合でも、リモートセンターのプロセスデータ収集を妨害しないようにそれらのイベントデータを収集できる。また、 リモートセンターからビル側の通信装置へのポーリングは不要であるため、ビル側の通信装置およびリモートセンターにかかる負荷を抑えることができる。これらの効果についてさらに詳しく述べると以下の通りである。
【００７１】
本実施形態では、ビルゲートウェイ(被監視装置)はイベントデータをいつ送信してよいかを記述したイベントデータ送信スケジュールを格納するイベントデータ送信スケジュール格納部２２およびイベントバッファ５１を備え、ビルゲートウェイから自発的にリモートセンター(監視装置)へデータを送信する際には必ずイベントデータ送信スケジュールで許可された時間帯に送信を行う。イベントデータ送信スケジュールでイベントデータ送信を禁止された時間帯に発生したイベントデータは一時的にイベントバッファ５１に格納し、その後イベントデータ送信を許可された時間帯に送信する。このようにすることで、イベントデータ送信スケジュールによって各ビルゲートウェイがイベントデータ送信を行うタイミングを制御することができる。
【００７２】
また、本実施形態によれば、イベントデータ送信スケジュールは任意の時刻においてビルゲートウェイに割り当てられる送信帯域幅の全ビルゲートウェイに渡る総和の最大値、期待値、あるいはその他の統計的代表値が、システムで許容される上限値を下回るように作成される。これにより、多数の設備機器で同時にイベントが発生した場合でも、同時に発生するイベントデータ送信のデータレートをシステムで許容される上限以下に抑えることができ、リモートセンターへのイベントデータの殺到を防ぐことができる。
【００７３】
また、本実施形態によれば、イベントデータ送信スケジュールは任意の種別のイベントデータについてそのデータを送信可能な時間帯の間隔がシステムで許容される上限を下回るように作成される。イベントデータを送信可能な時間帯の間隔は、そのイベントデータが発生してから送信されるまでの検出遅延の最大値となる。これにより、任意のイベントデータの検出遅延をシステムで許容される上限以下に抑えることができる。
【００７４】
また、本実施形態によれば、リモートセンターはビルゲートウェイへリクエストメッセージを送信する時刻を記述したプロセスデータ収集スケジュールを格納するプロセスデータ収集スケジュール格納部２１を持ち、プロセスデータ収集スケジュールに従ってビルゲートウェイへリクエストメッセージを送信し、設備機器のプロセスデータを収集する。これにより、リモートセンターは各設備機器のプロセスデータを定常的に監視することができる。
【００７５】
また、本実施形態よれば、イベントデータ送信スケジュールは、プロセスデータ収集スケジュールに記述された任意のリクエスト送信時刻においてビルゲートウェイに割り当てられる送信帯域幅の全ビルゲートウェイに渡る総和の最大値、期待値、あるいはその他の統計的代表値が、システムで許容される上限を下回るように作成される。これにより、リモートセンターがプロセスデータの収集を行うタイミングにおいて発生するイベントデータ送信のデータレートを上限以下に抑えることができるので、多数のイベントが同時に発生した場合でもプロセスデータ収集を妨害することなくイベントデータをリモートセンターへ通知することができる。
【００７６】
（第２の実施形態）
本発明の第１の実施形態におけるビルゲートウェイは、必ずイベントデータ送信スケジュールで許可された時間帯でのみ設備機器で発生したイベントデータを送信していた。これにより、リモートセンターへイベントデータが殺到することを防ぐことができたが、イベントデータを送信する機会が減ることで、イベントデータが発生してからリモートセンターでそれが受信されるまでのイベントデータ検出遅延が大きくなる可能性もある。
【００７７】
そこで、以下に示す本発明の第２の実施形態におけるビルゲートウェイでは、イベントバッファに蓄積されたイベントデータをプロセスデータメッセージに相乗りさせてリモートセンターへ送信する。プロセスデータメッセージとイベントデータメッセージを個別に送信する場合と比べ、相乗り送信にはTCP接続確立の処理やメッセージヘッダ送信のオーバーヘッドを削減できるという利点がある。よって、相乗り送信を行うことで、通信処理の負荷をほとんど増やすことなく、イベントデータの送信機会を増やし、イベントデータ検出遅延を抑えることができる。
【００７８】
本実施形態におけるシステムの全体構成は、図１に示す第１の実施形態におけるそれと同様であるため、割愛する。
【００７９】
本実施形態におけるリモートセンターの内部構成は、図２に示す第１の実施形態におけるそれと同様であるため、割愛する。
【００８０】
本実施形態におけるリモートセンターは、プロセスデータメッセージに含まれるイベントデータを受け付けるため、プロセスデータメッセージに相乗り可能なイベント種別をビルゲートウェイに通知する必要がある。そのため、本実施形態におけるプロセスデータ収集スケジュールは図１１のような形式を取る。
【００８１】
図１１に示すように、プロセスデータ収集スケジュールには、それぞれのプロセスデータメッセージに相乗りすることを許可するイベントの種別と、相乗り送信可能なイベントデータサイズの最大値を記述する。イベント種別の記載方法はイベントデータ送信スケジュールの送信可能イベント種別と同様である。相乗り可能イベント種別およびデータサイズの最大値の情報は、プロセスデータリクエストメッセージに含まれてビルゲートウェイへ送信される。
【００８２】
図１２に、本実施形態におけるリモートセンターの動作フローチャートを示す。図６に示す第１の実施形態におけるリモートセンターの動作との違いは、プロセスデータ収集スケジュール作成、イベントデータ送信スケジュール作成およびビルゲートウェイから送信されるメッセージの受信処理にある。第１の実施形態と同一の処理を行うステップについては同一の符号を付して、重複する説明を省略する。
【００８３】
プロセスデータ収集スケジュール作成（Ｓ３０１）では、第１の実施形態と同様の方法でプロセスデータ収集スケジュールを作成した上で、それぞれのプロセスデータリクエストについて相乗り可能イベント種別と相乗り可能データサイズの最大値を設定する。相乗り可能データサイズの最大値は、レスポンスメッセージのプロトコル上の制約や、システムの帯域幅を考慮して決定する。相乗り可能イベント種別は、選択されるイベント全てを送信する場合であっても、その合計データサイズが相乗り可能データサイズの最大値を超えないように設定するのが望ましい。
【００８４】
イベントデータ送信スケジュール作成（Ｓ３０２）では、第１の実施形態で示した留意点を満たすようにイベントデータ送信スケジュールを作成するが、その際、プロセスデータ収集スケジュールに記述された相乗り可能イベントも考慮に入れてスケジューリングを行う。この場合、任意のイベントデータについての送信可能時刻には、図１３に示すように、イベントデータ送信スケジュールに記述される送信可能時間帯と、プロセスデータ収集スケジュールに記述される相乗り可能な時刻の両方が含まれる。このようにして定義されたイベントデータ送信可能時刻がなるべく等間隔に設定されるようにするとともに、イベントデータ送信可能時刻の間隔がシステムで許容されるイベント検出遅延上限を下回るようにイベントデータ送信スケジュールの作成を行う。
【００８５】
本実施形態におけるリモートセンターは、イベントデータを相乗りさせたプロセスデータメッセージを受信し、それぞれ処理する。そのため図１２に示すように、リモートセンターはビルゲートウェイからメッセージを受信するとそのメッセージにプロセスデータ及びイベントデータが含まれているかそれぞれ調べ（Ｓ３０３、Ｓ３０５）、含まれている場合にはそれぞれのデータについて第１の実施形態で述べた様な適切な処理を行う（Ｓ３０４、Ｓ３０６）。
【００８６】
図１４に、本実施形態におけるビルゲートウェイの内部構成図を示す。図９に示す第１の実施形態におけるビルゲートウェイの内部構成図との違いは、プロセスデータリクエスト処理部６１がイベントバッファ５１を参照している点にある。第１の実施形態と同一の処理を行うステップについては同一の符号を付して、重複する説明を省略する。
【００８７】
図１５に、本実施形態におけるビルゲートウェイの動作フローチャートを示す。図１０に示す第１の実施形態におけるビルゲートウェイの動作フローチャートとの違いは、リモートセンターからプロセスデータリクエストを受信した際の動作にある。
【００８８】
本実施形態におけるビルゲートウェイは、プロセスデータリクエストメッセージを受信してプロセスデータを取得し、当該プロセスデータをレスポンスメッセージに含めるとともに（Ｓ４０１）、プロセスデータリクエストメッセージに含まれる相乗り可能イベント種別を取得する（Ｓ４０２）。ビルゲートウェイはこの情報を参照し、イベントバッファ５１内に相乗り送信可能なイベントデータがあるか調べ（Ｓ４０３）、ある場合はそれらのイベントデータをイベントバッファ５１から取り出し、レスポンスメッセージに含める（Ｓ４０４）。最後に、レスポンスメッセージをリモートセンターへ送信する（Ｓ４０５）。
【００８９】
以上のように、本実施形態における遠隔監視システムでは、ビルゲートウェイはイベント送信スケジュールで許可された時間帯に自発的にイベントデータを送信できるだけでなく、プロセスデータメッセージにイベントデータを相乗りさせて送信することもできる。
【００９０】
また、プロセスデータ収集スケジュール及び各ビルゲートウェイのイベントデータ送信スケジュールは、各ビルゲートウェイの任意の種別のイベントデータについて、そのデータの送信可能時刻(イベントデータ送信スケジュールで許可された時刻及び、プロセスデータリクエストメッセージに対するリクエストメッセージに含めて送信することができる時刻)の間隔がシステムで許容される上限を下回るように作成することができる。
【００９１】
このように、ビルゲートウェイはプロセスデータレスポンスメッセージに含めてイベントデータを送信することができるため、通信処理の負荷をほとんど増大させることなく、イベントデータの送信機会を増やすことができる。また、送信機会が増えることを考慮に入れてプロセスデータ収集スケジュール及びイベントデータ送信スケジュールを作成することで、通信負荷を増やすことなく検出遅延を短縮することが可能となる。
【００９２】
尚、リモートセンター（遠隔監視装置）およびビルゲートウェイ（通信装置）は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、遠隔監視装置および通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD-ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、遠隔監視装置および通信装置が備える各種の格納部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD-R、CD-RW、DVD-RAM、DVD-R等の記憶媒体などを適宜利用して実現することができる。
【００９３】
尚、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせて実施することも可能なことは言うまでもない。
【図１】
2014082723.tif 000003
【図２】
2014082723.tif 000004
【図３】
2014082723.tif 000005
【図４】
2014082723.tif 000006
【図５】
2014082723.tif 000007
【図６】
2014082723.tif 000008
【図７】
2014082723.tif 000009
【図８】
2014082723.tif 000010
【図９】
2014082723.tif 000011
【図１０】
2014082723.tif 000012
【図１１】
2014082723.tif 000013
【図１２】
2014082723.tif 000014
【図１３】
2014082723.tif 000015
【図１４】
2014082723.tif 000016
【図１５】
2014082723.tif 000017