監視システム、監視装置および監視方法
【課題】最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、を提供すること。
【解決手段】実施形態によれば、監視システムは、それぞれ被監視装置に接続される複数のコントローラと、上記複数のコントローラに通信ネットワークを介して接続され１つの代表サーバを含む複数のサーバとを具備する。上記サーバの各々は、検出部と、取得部と、配信部とを備える。検出部は、異常の生じたコントローラが当該異常から復帰したことを検出する。取得部は、上記代表サーバであれば、上記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する。配信部は、上記取得した状態を上記代表サーバ以外のサーバに上記通信ネットワークを介して配信する。
【解決手段】実施形態によれば、監視システムは、それぞれ被監視装置に接続される複数のコントローラと、上記複数のコントローラに通信ネットワークを介して接続され１つの代表サーバを含む複数のサーバとを具備する。上記サーバの各々は、検出部と、取得部と、配信部とを備える。検出部は、異常の生じたコントローラが当該異常から復帰したことを検出する。取得部は、上記代表サーバであれば、上記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する。配信部は、上記取得した状態を上記代表サーバ以外のサーバに上記通信ネットワークを介して配信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ビルオートメーションなどに適用される監視システム、監視装置および監視方法に関する。特に本発明の実施形態は、通信プロトコルとしてＢＡＣｎｅｔ（登録商標）が適用されるシステムに係わる。
【背景技術】
【０００２】
Building Automation and Control Networking protocol（ＢＡＣｎｅｔ（登録商標））は、ビルや工場などの施設における監視装置／被監視装置間で通信されるデータの表現方法と通信方法を標準化するために規定された通信プロトコルである。現在ではＩＳＯの標準規格にもなっており、ＢＡＣｎｅｔ（登録商標）はビル管理システムにおいてマルチベンダ化を促進するためには注目すべき技術である。
【０００３】
ＢＡＣｎｅｔ（登録商標）を用いた監視システムは、BACnet Operator Workstation（Ｂ−ＯＷＳ）と、BACnet Building Controller（Ｂ−ＢＣ）とを備える。Ｂ−ＯＷＳは監視機能を備えてＢ−ＢＣよりも上位の位置付けにあり、Ｂ−ＢＣは被監視装置を制御するコントローラであってＢ−ＯＷＳよりも下位の位置付けにある。
【０００４】
ＢＡＣｎｅｔ（登録商標）では監視対象の機器の状態が変化すると、その旨をＢ−ＢＣからＢ−ＯＷＳにイベント通告(EventNotification：ＵＤＰパケット）で通知することが規定されている。イベント通告には確認付き、確認無しの双方が用意されている。すなわちＢＡＣｎｅｔ（登録商標）ではConfirmedEventNotificationとUnconfirmedEventNotificationとの双方がサポートされている。
【０００５】
ネットワーク負荷の増大や監視端末での表示性能低下を避けるため、一般的なマルチベンダの監視システムでは確認無しイベント通告のブロードキャストを使用するケースが多い。しかしながらこのような環境では『ネットワーク障害時におけるＢ−ＯＷＳへのイベント通告の未達』、あるいは『Ｂ−ＢＣの障害復旧後におけるイベント通告の送信抜け』といった事態が起こり得る。このような事態が起こればＢ−ＢＣの保持する状態（監視対象機器の実際の状態）とＢ−ＯＷＳのモニタに表示される内容とが一致しない（不整合）おそれがあり、好ましくない。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】［平成２３年９月２６日検索］、インターネット＜URL：http://www.bacnet.org/＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記したように確認無しイベント通告を用いる既存の監視システムでは、Ｂ−ＢＣの保持する状態とＢ−ＯＷＳの認識している状態（つまりＢ−ＯＷＳの取得している状態）との間の不整合が起こりうる。これを避けるため既存の技術では、リードプロパティ（ReadProperty：ＵＤＰパケット）を各Ｂ−ＯＷＳからＢ−ＢＣへ定期的に送信し、監視対象機器（以下、被監視装置と総称する）の現在の正しい状態を取得するようにしていた。
【０００８】
しかしながらリードプロパティの送信周期が短いとＢ−ＢＣの通信負荷が大きくなる。リードプロパティが限度を超えて頻発するとＢ−ＢＣをダウンさせてしまうケースもあり、マルチベンダ環境下では特に注意しなくてはならない。逆に送信周期を長くすると、不整合が解消されるまでに時間がかかる。このように既存の技術では通信負荷の低減と不整合期間の短縮との両立が難しく、解決策が模索されている。
【０００９】
目的は、最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、監視装置および監視方法を提供することにある。
【課題を解決するための手段】
【００１０】
実施形態によれば、監視システムは、それぞれ被監視装置に接続される複数のコントローラと、上記複数のコントローラに通信ネットワークを介して接続され１つの代表サーバを含む複数のサーバとを具備する。上記サーバの各々は、検出部と、取得部と、配信部とを備える。検出部は、異常の生じたコントローラが当該異常から復帰したことを検出する。取得部は、上記代表サーバであれば、上記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する。配信部は、上記取得した状態を上記代表サーバ以外のサーバに上記通信ネットワークを介して配信する。
【図面の簡単な説明】
【００１１】
【図１】実施形態に係わる監視システムの一例を示すシステム図。
【図２】監視装置１１〜１ｎの第１の実施の形態を示す機能ブロック図。
【図３】第１の実施形態における処理手順を示すフローチャート。
【図４】第１の実施形態における作用を説明するための図。
【図５】比較のため既存の監視システムの一例を示す図。
【図６】監視装置１１〜１ｎの第２の実施の形態を示す機能ブロック図である。
【図７】第２の実施形態における処理手順を示すフローチャート。
【図８】第２の実施形態における作用を説明するための図。
【発明を実施するための形態】
【００１２】
図１は、実施形態に係わる監視システムの一例を示すシステム図である。図１において、複数の監視装置１１〜１ｎおよびローカルコントローラ２１〜２ｍが通信ネットワークとしてのLocal Area Network（ＬＡＮ）１００に接続される。実施形態においてＬＡＮ１００の上位層にはＢＡＣｎｅｔ（登録商標）が形成される。すなわち実施形態に係わる監視システムはＢＡＣｎｅｔ（登録商標）に準拠する。これにより監視システム内に異ベンダシステムが混在することが可能になる。
【００１３】
ローカルコントローラ２１〜２ｍにはそれぞれ通信回線を介してノードが接続される。各ノードは例えばフロアごとの空調機器、照明機器、動力機器などである。ローカルコントローラ２１〜２ｍはそれぞれ接続されるノードを被監視装置として認識し、その状態をモニタする。ローカルコントローラ２１〜２ｍは実施形態においてはＢ−ＢＣとして機能する。
【００１４】
監視装置１１〜１ｎはローカルコントローラ２１〜２ｍから通知されるモニタ結果を受け監視システムを上位レベルで監視制御したり、オペレータに各種の情報を提供したりするサーバとしての機能を有する。監視装置１１〜１ｎは実施形態においてはＢ−ＯＷＳとして機能する。
【００１５】
実施形態では監視装置１１〜１ｎのうち一つを、監視装置１１〜１ｎの代表として機能させる。代表としての監視装置を代表サーバと称することにする。代表サーバを決めるにあたっては監視装置１１〜１ｎにそれぞれユニークな番号を予め決めておき、正常な監視装置のうち一番若い番号の監視装置を代表サーバとして機能させることとする。もちろん、番号の一番大きい監視装置を代表サーバとしても良い。
【００１６】
［第１の実施形態］
図２は、図１に示される監視装置１１〜１ｎの第１の実施の形態を示す機能ブロック図である。監視装置１１〜１ｎは、ネットワークインタフェース部４１、表示部４２、入出力部４３、データベース部４４、および、主制御部４５を備える。インタフェース部４１はＬＡＮ１００との通信に係わるインタフェース処理を担う。
【００１７】
表示部４２は入出力部４３とともにユーザインタフェースを提供し、ＧＵＩ（Graphical User Interface）環境を構築する。データベース部４４はハードディスクドライブなどのストレージデバイスであり、管理テーブル４４ａを記憶する。管理テーブル４４ａにはシステム内の被監視装置（ノード）の個別の状態などが記憶される。表示部４２および入出力部４３は管理テーブル４４ａから取得したデータを処理し、例えばＷｅｂブラウザなどの形態でユーザへの情報通知を行う。
【００１８】
ところで、主制御部４５は、この実施形態に係わる処理機能として検出部４５ａ、取得部４５ｂ、および、配信部４５ｃを備える。
検出部４５ａは、異常の生じたローカルコントローラが異常から復帰したことを検出する。実施形態では、検出部４５ａは異常から復帰したローカルコントローラから通知されるI-Amを受信することでその送信元のローカルコントローラが復帰したことを検出する。
【００１９】
ＢＡＣｎｅｔ（登録商標）にはＢ−ＯＷＳ／Ｂ−ＢＣの健全性をチェックする仕組みが規定されている。すなわち各デバイスから６０秒ごとに送信されるI-Am（健全性通知、ＵＤＰパケット）が１５０秒間にわたって不達であれば、そのI-Amの送信元デバイスに異常が生じたと判定することになっている。また、異常と判定されている状態のデバイスからI-Amが届けば正常復帰と判定することになっている。検出部４５ａはこのルールを利用してローカルコントローラの正常復帰を検出する。
【００２０】
なお異常とはローカルコントローラ自体の障害だけでなく、監視装置とローカルコントローラとを結ぶ通信回線（ＬＡＮ１００を含む）における障害をも含む概念である。実施形態では要するに、監視装置とローカルコントローラとの通信に障害が生じた状態を異常と称する。このような状態は基板異常、ネットワーク断線、熱暴走などあらゆる状況で起こり得る。
【００２１】
取得部４５ｂは、自らが代表サーバであれば、異常から復帰したローカルコントローラに接続される各ノードの状態を取得する。すなわち取得部４５ｂは復帰したローカルコントローラにReadPropertyを送信し、その返信を受けることで送出先のローカルコントローラに接続されるノードの状態を取得する。
【００２２】
配信部４５ｃは、取得した各ノードの状態を代表サーバ以外の監視装置、つまり他の監視装置にＬＡＮ１００を介して配信する。その際、配信部４５ｃは、各ノードの状態を示す情報を圧縮して配信することで、ＬＡＮ１００を流れるトラフィックを抑制する。次に、上記構成における作用を説明する。
【００２３】
図３は、第１の実施形態における処理手順を示すフローチャートである。図４と併せて説明する。なお図４においてはＢＡＣｎｅｔ（登録商標）における役割の明示のため、監視装置をＢ−ＯＷＳと表記し、ローカルコントローラ２１〜２ｍをＢ−ＢＣと表記する。便宜上、監視装置１１を代表サーバとし、ローカルコントローラ２１に異常が生じたとする。
【００２４】
図３において、監視装置１１がローカルコントローラ２１の異常からの復帰を検出すると（ステップＳ１）、監視装置１１は自らが代表サーバであるか否かを判定する（ステップＳ２）。仮に代表サーバでなければ（ステップＳ２でＮｏ）、監視装置１１は図３に係わる主体的な処理を実施することなく他の装置からの通知を待ち受ける。
【００２５】
監視装置１１は代表サーバであるので（ステップＳ２でＹｅｓ）、復帰したローカルコントローラ２１にReadPropertyを送信し、ローカルコントローラ２１の配下のノードの状態を取得する（ステップＳ３）。次に監視装置１１は取得したデータを既定のフォーマットで圧縮したのち（ステップＳ４）、他の監視装置に向け配信する（ステップＳ５）。ステップＳ５の手順はステップＳ６１〜Ｓ６２のループにおいて他の監視装置の数すなわちｎ−１回繰り返される。なお配信の順番は、例えば監視装置の番号順とすれば良い。
【００２６】
図４に示すように、Ｂ−ＢＣとしてのローカルコントローラ２１が異常から復帰すると［（１）］、I-Amが送出されて監視装置１１により受信される。I-Amを受けた監視装置１１はローカルコントローラ２１の復帰を検出し［（２）］、このローカルコントローラ２１からノードの状態を取得する［（３）］。データの取得が完了すると監視装置１１は取得したデータを圧縮して他の全ての監視装置１２〜１ｎに向け配信する［（４）］。
【００２７】
図５（ａ）に示すように、UnconfirmedEventNotificationではパケットの到着が保証されないのでメッセージの未達が起こることがある。またＢ−ＢＣや通信回線に異常が起こるとメッセージを送信できないこともある。このようなケースではＢ−ＢＣとＢ−ＯＷＳとの双方が互いに保持する情報（ノードの状態を含む）が一致しないケースがある。これを避けるため図５（ｂ）に示すように、Ｂ−ＯＷＳから一定の周期でReadpropertyをＢ−ＢＣに送信するようにしたシステムもあるが、通信負荷が大きくなる。
【００２８】
そこで第１の実施形態では、ＢＡＣｎｅｔ（登録商標）ベースであって主としてUnconfirmedEventNotificationにより状態通知を行う監視システムにおいて、Ｂ−ＢＣの異常からの復帰をトリガとしてＢ−ＯＷＳの主体的な処理によりノードの状態を取得するようにしている。すなわちＢ−ＢＣの復帰を検出したＢ−ＯＷＳは、復帰したＢ−ＢＣにReadPropertyを送信して配下のノードの状態の返信を要求する。ただしこの処理を、自らが代表サーバである場合にのみ、Ｂ−ＯＷＳは実行する。これにより復帰したＢ−ＢＣの通信負荷を最小にできる。
【００２９】
Ｂ−ＯＷＳはReadPropertyに対する返信により状態を取得すると、取得したデータを圧縮して他のＢ−ＯＷＳに配信する。これによりＬＡＮ１００の通信負荷も抑えることができる。また、復帰したＢ−ＢＣに全てのＢ−ＯＷＳが個別に問い合わせるよりも、通信量を格段に削減することができる。
【００３０】
通信負荷が少ないことは、Ｂ−ＢＣとＢ−ＯＷＳとの間、および各Ｂ−ＯＷＳ間でのデータの同期（整合）にかかる時間を短縮できることを意味する。また第１の実施形態では、ReadPropertyの定期的な送信ではなく、Ｂ−ＢＣの復帰後ただちにReadPropertyを送信するようにしているので、Ｂ−ＯＷＳにおけるノードの状態の取得にかかる時間を最小にすることができる。よってＢ−ＢＣの保持する状態とＢ−ＯＷＳの認識している状態とが一致していない期間を、可能な限り短くすることが可能になる。これらのことから、最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、監視装置および監視方法を提供することが可能となる。
【００３１】
［第２の実施形態］
図６は、監視装置１１〜１ｎの第２の実施の形態を示す機能ブロック図である。図６において図２と共通する部分には同じ符号を付し、ここでは異なる部分についてのみ説明する。
【００３２】
第２の実施形態では、主制御部４５はサーチ部４５ｄ、要求部４５ｅ、および、送信部４５ｆを備える。
サーチ部４５ｄは、自らの監視装置が起動する際に、正常に稼動している他の監視装置を検出する。要求部４５ｅは、サーチ部４５ｄにより検出された監視装置のうち少なくとも一つに、当該監視装置が認識している監視システム内のノード（被監視装置）の状態の取得を要求する。送信部４５ｆは、他の監視装置から上記要求を受けると、その要求に応じて被監視装置の状態を送信する。その際、送信部４５ｆは、各ノードの状態を示す情報を圧縮して配信することで、ＬＡＮ１００を流れるトラフィックを抑制する。次に、上記構成における作用を説明する。
【００３３】
図７は、第２の実施形態における処理手順を示すフローチャートである。第２の実施形態では監視装置すなわちＢ−ＯＷＳの起動時における処理につき説明する。以下では監視装置１ｎが起動した際の処理を説明する。
図７において、監視装置１ｎ（Ｂ−ＯＷＳ）が起動すると（ステップＳ７）、監視装置１ｎは他に正常稼動しているＢ−ＯＷＳがＬＡＮ１００上に存在するか否かをサーチする（ステップＳ８）。健全なＢ−ＯＷＳが見つかれば（ステップＳ８でＹｅｓ）、監視装置１ｎはそのいずれかのＢ−ＯＷＳにReadPropertyを送信し、当該Ｂ−ＯＷＳに保持されているシステムの状態、すなわち全てのＢ−ＢＣの状態を取得する（ステップＳ９）。ここでは例えば代表サーバとしてのＢ−ＯＷＳ（監視装置１１）から必要なデータを取得するようにする。
その際、データの送出元である監視装置１１は、要求されたデータを圧縮してReadPropertyの送信元である監視装置１ｎに返送する。これによりＬＡＮ１００上のトラフィックを削減できる。健全なＢ−ＯＷＳが見つからなければ（ステップＳ８でＮｏ）、監視装置１ｎは全てのＢ−ＢＣにReadPropertyを送信し、各Ｂ−ＢＣの状態を個別に取得する（ステップＳ１０）。
図８に示すように、Ｂ−ＯＷＳとしての監視装置１ｎが起動すると［（１）］、監視装置１ｎは正常な監視装置を見つけ出す。代表としての監視装置１１が正常であれば、監視装置１ｎは圧縮されたデータを監視装置１１から取得する［（２）］。
【００３４】
以上のように第２の実施形態では、Ｂ−ＯＷＳ起動時におけるＢ−ＢＣとの状態合わせシーケンスにおいて、Ｂ−ＢＣへReadPropertyを送信することなく、必要なデータを代表のＢ−ＯＷＳに要求することで取得するようにしている。
すなわちＢ−ＯＷＳの起動時には、その時点での正しい情報を表示するために全Ｂ−ＢＣから状態を取得するようになっている。そこで第２の実施形態では他の健全なＢ−ＯＷＳから状態を示す情報を取得することで、通信負荷を削減する。また、要求を受けたＢ−ＯＷＳは状態データを圧縮して送信することで通信負荷をさらに削減する。このようにしたので、監視装置の起動時においても第１の実施形態と同様の効果を得ることが可能になる。
【００３５】
なお本発明は上記実施の形態にされるものではない。例えば異常の発生からの復帰が短期間でなされた場合には、Ｂ−ＯＷＳにおいてＢ−ＢＣの異常を検出できないことがある。このようなケースに備え、通信の負荷が過大にならない程度にReadPropertyによる状態の取得を実行するようにしても良い。あるいはオペレータのマニュアルでの操作によりReadPropertyコマンドを投入するようにしても良い。
【００３６】
また実施形態ではＢＡＣｎｅｔ（登録商標）について説明したが、デバイスの健全性を通知すること、および状態の取得を行うことがプロトコルで既定されているシステムであれば、実施形態において開示された思想はＢＡＣｎｅｔ（登録商標）以外のシステムにおいても適用することができる。
【００３７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００３８】
１１〜１ｎ…監視装置、２１〜２ｍ…ローカルコントローラ、１００…Local Area Network（ＬＡＮ）、４１…ネットワークインタフェース部、４２…表示部、４３…入出力部、４４…データベース部、４４ａ…管理テーブル、４５…主制御部、４５ａ…検出部、４５ｂ…取得部、４５ｃ…配信部、４５ｄ…サーチ部、４５ｅ…要求部、４５ｆ…送信部
【技術分野】
【０００１】
本発明の実施形態は、ビルオートメーションなどに適用される監視システム、監視装置および監視方法に関する。特に本発明の実施形態は、通信プロトコルとしてＢＡＣｎｅｔ（登録商標）が適用されるシステムに係わる。
【背景技術】
【０００２】
Building Automation and Control Networking protocol（ＢＡＣｎｅｔ（登録商標））は、ビルや工場などの施設における監視装置／被監視装置間で通信されるデータの表現方法と通信方法を標準化するために規定された通信プロトコルである。現在ではＩＳＯの標準規格にもなっており、ＢＡＣｎｅｔ（登録商標）はビル管理システムにおいてマルチベンダ化を促進するためには注目すべき技術である。
【０００３】
ＢＡＣｎｅｔ（登録商標）を用いた監視システムは、BACnet Operator Workstation（Ｂ−ＯＷＳ）と、BACnet Building Controller（Ｂ−ＢＣ）とを備える。Ｂ−ＯＷＳは監視機能を備えてＢ−ＢＣよりも上位の位置付けにあり、Ｂ−ＢＣは被監視装置を制御するコントローラであってＢ−ＯＷＳよりも下位の位置付けにある。
【０００４】
ＢＡＣｎｅｔ（登録商標）では監視対象の機器の状態が変化すると、その旨をＢ−ＢＣからＢ−ＯＷＳにイベント通告(EventNotification：ＵＤＰパケット）で通知することが規定されている。イベント通告には確認付き、確認無しの双方が用意されている。すなわちＢＡＣｎｅｔ（登録商標）ではConfirmedEventNotificationとUnconfirmedEventNotificationとの双方がサポートされている。
【０００５】
ネットワーク負荷の増大や監視端末での表示性能低下を避けるため、一般的なマルチベンダの監視システムでは確認無しイベント通告のブロードキャストを使用するケースが多い。しかしながらこのような環境では『ネットワーク障害時におけるＢ−ＯＷＳへのイベント通告の未達』、あるいは『Ｂ−ＢＣの障害復旧後におけるイベント通告の送信抜け』といった事態が起こり得る。このような事態が起こればＢ−ＢＣの保持する状態（監視対象機器の実際の状態）とＢ−ＯＷＳのモニタに表示される内容とが一致しない（不整合）おそれがあり、好ましくない。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】［平成２３年９月２６日検索］、インターネット＜URL：http://www.bacnet.org/＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記したように確認無しイベント通告を用いる既存の監視システムでは、Ｂ−ＢＣの保持する状態とＢ−ＯＷＳの認識している状態（つまりＢ−ＯＷＳの取得している状態）との間の不整合が起こりうる。これを避けるため既存の技術では、リードプロパティ（ReadProperty：ＵＤＰパケット）を各Ｂ−ＯＷＳからＢ−ＢＣへ定期的に送信し、監視対象機器（以下、被監視装置と総称する）の現在の正しい状態を取得するようにしていた。
【０００８】
しかしながらリードプロパティの送信周期が短いとＢ−ＢＣの通信負荷が大きくなる。リードプロパティが限度を超えて頻発するとＢ−ＢＣをダウンさせてしまうケースもあり、マルチベンダ環境下では特に注意しなくてはならない。逆に送信周期を長くすると、不整合が解消されるまでに時間がかかる。このように既存の技術では通信負荷の低減と不整合期間の短縮との両立が難しく、解決策が模索されている。
【０００９】
目的は、最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、監視装置および監視方法を提供することにある。
【課題を解決するための手段】
【００１０】
実施形態によれば、監視システムは、それぞれ被監視装置に接続される複数のコントローラと、上記複数のコントローラに通信ネットワークを介して接続され１つの代表サーバを含む複数のサーバとを具備する。上記サーバの各々は、検出部と、取得部と、配信部とを備える。検出部は、異常の生じたコントローラが当該異常から復帰したことを検出する。取得部は、上記代表サーバであれば、上記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する。配信部は、上記取得した状態を上記代表サーバ以外のサーバに上記通信ネットワークを介して配信する。
【図面の簡単な説明】
【００１１】
【図１】実施形態に係わる監視システムの一例を示すシステム図。
【図２】監視装置１１〜１ｎの第１の実施の形態を示す機能ブロック図。
【図３】第１の実施形態における処理手順を示すフローチャート。
【図４】第１の実施形態における作用を説明するための図。
【図５】比較のため既存の監視システムの一例を示す図。
【図６】監視装置１１〜１ｎの第２の実施の形態を示す機能ブロック図である。
【図７】第２の実施形態における処理手順を示すフローチャート。
【図８】第２の実施形態における作用を説明するための図。
【発明を実施するための形態】
【００１２】
図１は、実施形態に係わる監視システムの一例を示すシステム図である。図１において、複数の監視装置１１〜１ｎおよびローカルコントローラ２１〜２ｍが通信ネットワークとしてのLocal Area Network（ＬＡＮ）１００に接続される。実施形態においてＬＡＮ１００の上位層にはＢＡＣｎｅｔ（登録商標）が形成される。すなわち実施形態に係わる監視システムはＢＡＣｎｅｔ（登録商標）に準拠する。これにより監視システム内に異ベンダシステムが混在することが可能になる。
【００１３】
ローカルコントローラ２１〜２ｍにはそれぞれ通信回線を介してノードが接続される。各ノードは例えばフロアごとの空調機器、照明機器、動力機器などである。ローカルコントローラ２１〜２ｍはそれぞれ接続されるノードを被監視装置として認識し、その状態をモニタする。ローカルコントローラ２１〜２ｍは実施形態においてはＢ−ＢＣとして機能する。
【００１４】
監視装置１１〜１ｎはローカルコントローラ２１〜２ｍから通知されるモニタ結果を受け監視システムを上位レベルで監視制御したり、オペレータに各種の情報を提供したりするサーバとしての機能を有する。監視装置１１〜１ｎは実施形態においてはＢ−ＯＷＳとして機能する。
【００１５】
実施形態では監視装置１１〜１ｎのうち一つを、監視装置１１〜１ｎの代表として機能させる。代表としての監視装置を代表サーバと称することにする。代表サーバを決めるにあたっては監視装置１１〜１ｎにそれぞれユニークな番号を予め決めておき、正常な監視装置のうち一番若い番号の監視装置を代表サーバとして機能させることとする。もちろん、番号の一番大きい監視装置を代表サーバとしても良い。
【００１６】
［第１の実施形態］
図２は、図１に示される監視装置１１〜１ｎの第１の実施の形態を示す機能ブロック図である。監視装置１１〜１ｎは、ネットワークインタフェース部４１、表示部４２、入出力部４３、データベース部４４、および、主制御部４５を備える。インタフェース部４１はＬＡＮ１００との通信に係わるインタフェース処理を担う。
【００１７】
表示部４２は入出力部４３とともにユーザインタフェースを提供し、ＧＵＩ（Graphical User Interface）環境を構築する。データベース部４４はハードディスクドライブなどのストレージデバイスであり、管理テーブル４４ａを記憶する。管理テーブル４４ａにはシステム内の被監視装置（ノード）の個別の状態などが記憶される。表示部４２および入出力部４３は管理テーブル４４ａから取得したデータを処理し、例えばＷｅｂブラウザなどの形態でユーザへの情報通知を行う。
【００１８】
ところで、主制御部４５は、この実施形態に係わる処理機能として検出部４５ａ、取得部４５ｂ、および、配信部４５ｃを備える。
検出部４５ａは、異常の生じたローカルコントローラが異常から復帰したことを検出する。実施形態では、検出部４５ａは異常から復帰したローカルコントローラから通知されるI-Amを受信することでその送信元のローカルコントローラが復帰したことを検出する。
【００１９】
ＢＡＣｎｅｔ（登録商標）にはＢ−ＯＷＳ／Ｂ−ＢＣの健全性をチェックする仕組みが規定されている。すなわち各デバイスから６０秒ごとに送信されるI-Am（健全性通知、ＵＤＰパケット）が１５０秒間にわたって不達であれば、そのI-Amの送信元デバイスに異常が生じたと判定することになっている。また、異常と判定されている状態のデバイスからI-Amが届けば正常復帰と判定することになっている。検出部４５ａはこのルールを利用してローカルコントローラの正常復帰を検出する。
【００２０】
なお異常とはローカルコントローラ自体の障害だけでなく、監視装置とローカルコントローラとを結ぶ通信回線（ＬＡＮ１００を含む）における障害をも含む概念である。実施形態では要するに、監視装置とローカルコントローラとの通信に障害が生じた状態を異常と称する。このような状態は基板異常、ネットワーク断線、熱暴走などあらゆる状況で起こり得る。
【００２１】
取得部４５ｂは、自らが代表サーバであれば、異常から復帰したローカルコントローラに接続される各ノードの状態を取得する。すなわち取得部４５ｂは復帰したローカルコントローラにReadPropertyを送信し、その返信を受けることで送出先のローカルコントローラに接続されるノードの状態を取得する。
【００２２】
配信部４５ｃは、取得した各ノードの状態を代表サーバ以外の監視装置、つまり他の監視装置にＬＡＮ１００を介して配信する。その際、配信部４５ｃは、各ノードの状態を示す情報を圧縮して配信することで、ＬＡＮ１００を流れるトラフィックを抑制する。次に、上記構成における作用を説明する。
【００２３】
図３は、第１の実施形態における処理手順を示すフローチャートである。図４と併せて説明する。なお図４においてはＢＡＣｎｅｔ（登録商標）における役割の明示のため、監視装置をＢ−ＯＷＳと表記し、ローカルコントローラ２１〜２ｍをＢ−ＢＣと表記する。便宜上、監視装置１１を代表サーバとし、ローカルコントローラ２１に異常が生じたとする。
【００２４】
図３において、監視装置１１がローカルコントローラ２１の異常からの復帰を検出すると（ステップＳ１）、監視装置１１は自らが代表サーバであるか否かを判定する（ステップＳ２）。仮に代表サーバでなければ（ステップＳ２でＮｏ）、監視装置１１は図３に係わる主体的な処理を実施することなく他の装置からの通知を待ち受ける。
【００２５】
監視装置１１は代表サーバであるので（ステップＳ２でＹｅｓ）、復帰したローカルコントローラ２１にReadPropertyを送信し、ローカルコントローラ２１の配下のノードの状態を取得する（ステップＳ３）。次に監視装置１１は取得したデータを既定のフォーマットで圧縮したのち（ステップＳ４）、他の監視装置に向け配信する（ステップＳ５）。ステップＳ５の手順はステップＳ６１〜Ｓ６２のループにおいて他の監視装置の数すなわちｎ−１回繰り返される。なお配信の順番は、例えば監視装置の番号順とすれば良い。
【００２６】
図４に示すように、Ｂ−ＢＣとしてのローカルコントローラ２１が異常から復帰すると［（１）］、I-Amが送出されて監視装置１１により受信される。I-Amを受けた監視装置１１はローカルコントローラ２１の復帰を検出し［（２）］、このローカルコントローラ２１からノードの状態を取得する［（３）］。データの取得が完了すると監視装置１１は取得したデータを圧縮して他の全ての監視装置１２〜１ｎに向け配信する［（４）］。
【００２７】
図５（ａ）に示すように、UnconfirmedEventNotificationではパケットの到着が保証されないのでメッセージの未達が起こることがある。またＢ−ＢＣや通信回線に異常が起こるとメッセージを送信できないこともある。このようなケースではＢ−ＢＣとＢ−ＯＷＳとの双方が互いに保持する情報（ノードの状態を含む）が一致しないケースがある。これを避けるため図５（ｂ）に示すように、Ｂ−ＯＷＳから一定の周期でReadpropertyをＢ−ＢＣに送信するようにしたシステムもあるが、通信負荷が大きくなる。
【００２８】
そこで第１の実施形態では、ＢＡＣｎｅｔ（登録商標）ベースであって主としてUnconfirmedEventNotificationにより状態通知を行う監視システムにおいて、Ｂ−ＢＣの異常からの復帰をトリガとしてＢ−ＯＷＳの主体的な処理によりノードの状態を取得するようにしている。すなわちＢ−ＢＣの復帰を検出したＢ−ＯＷＳは、復帰したＢ−ＢＣにReadPropertyを送信して配下のノードの状態の返信を要求する。ただしこの処理を、自らが代表サーバである場合にのみ、Ｂ−ＯＷＳは実行する。これにより復帰したＢ−ＢＣの通信負荷を最小にできる。
【００２９】
Ｂ−ＯＷＳはReadPropertyに対する返信により状態を取得すると、取得したデータを圧縮して他のＢ−ＯＷＳに配信する。これによりＬＡＮ１００の通信負荷も抑えることができる。また、復帰したＢ−ＢＣに全てのＢ−ＯＷＳが個別に問い合わせるよりも、通信量を格段に削減することができる。
【００３０】
通信負荷が少ないことは、Ｂ−ＢＣとＢ−ＯＷＳとの間、および各Ｂ−ＯＷＳ間でのデータの同期（整合）にかかる時間を短縮できることを意味する。また第１の実施形態では、ReadPropertyの定期的な送信ではなく、Ｂ−ＢＣの復帰後ただちにReadPropertyを送信するようにしているので、Ｂ−ＯＷＳにおけるノードの状態の取得にかかる時間を最小にすることができる。よってＢ−ＢＣの保持する状態とＢ−ＯＷＳの認識している状態とが一致していない期間を、可能な限り短くすることが可能になる。これらのことから、最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、監視装置および監視方法を提供することが可能となる。
【００３１】
［第２の実施形態］
図６は、監視装置１１〜１ｎの第２の実施の形態を示す機能ブロック図である。図６において図２と共通する部分には同じ符号を付し、ここでは異なる部分についてのみ説明する。
【００３２】
第２の実施形態では、主制御部４５はサーチ部４５ｄ、要求部４５ｅ、および、送信部４５ｆを備える。
サーチ部４５ｄは、自らの監視装置が起動する際に、正常に稼動している他の監視装置を検出する。要求部４５ｅは、サーチ部４５ｄにより検出された監視装置のうち少なくとも一つに、当該監視装置が認識している監視システム内のノード（被監視装置）の状態の取得を要求する。送信部４５ｆは、他の監視装置から上記要求を受けると、その要求に応じて被監視装置の状態を送信する。その際、送信部４５ｆは、各ノードの状態を示す情報を圧縮して配信することで、ＬＡＮ１００を流れるトラフィックを抑制する。次に、上記構成における作用を説明する。
【００３３】
図７は、第２の実施形態における処理手順を示すフローチャートである。第２の実施形態では監視装置すなわちＢ−ＯＷＳの起動時における処理につき説明する。以下では監視装置１ｎが起動した際の処理を説明する。
図７において、監視装置１ｎ（Ｂ−ＯＷＳ）が起動すると（ステップＳ７）、監視装置１ｎは他に正常稼動しているＢ−ＯＷＳがＬＡＮ１００上に存在するか否かをサーチする（ステップＳ８）。健全なＢ−ＯＷＳが見つかれば（ステップＳ８でＹｅｓ）、監視装置１ｎはそのいずれかのＢ−ＯＷＳにReadPropertyを送信し、当該Ｂ−ＯＷＳに保持されているシステムの状態、すなわち全てのＢ−ＢＣの状態を取得する（ステップＳ９）。ここでは例えば代表サーバとしてのＢ−ＯＷＳ（監視装置１１）から必要なデータを取得するようにする。
その際、データの送出元である監視装置１１は、要求されたデータを圧縮してReadPropertyの送信元である監視装置１ｎに返送する。これによりＬＡＮ１００上のトラフィックを削減できる。健全なＢ−ＯＷＳが見つからなければ（ステップＳ８でＮｏ）、監視装置１ｎは全てのＢ−ＢＣにReadPropertyを送信し、各Ｂ−ＢＣの状態を個別に取得する（ステップＳ１０）。
図８に示すように、Ｂ−ＯＷＳとしての監視装置１ｎが起動すると［（１）］、監視装置１ｎは正常な監視装置を見つけ出す。代表としての監視装置１１が正常であれば、監視装置１ｎは圧縮されたデータを監視装置１１から取得する［（２）］。
【００３４】
以上のように第２の実施形態では、Ｂ−ＯＷＳ起動時におけるＢ−ＢＣとの状態合わせシーケンスにおいて、Ｂ−ＢＣへReadPropertyを送信することなく、必要なデータを代表のＢ−ＯＷＳに要求することで取得するようにしている。
すなわちＢ−ＯＷＳの起動時には、その時点での正しい情報を表示するために全Ｂ−ＢＣから状態を取得するようになっている。そこで第２の実施形態では他の健全なＢ−ＯＷＳから状態を示す情報を取得することで、通信負荷を削減する。また、要求を受けたＢ−ＯＷＳは状態データを圧縮して送信することで通信負荷をさらに削減する。このようにしたので、監視装置の起動時においても第１の実施形態と同様の効果を得ることが可能になる。
【００３５】
なお本発明は上記実施の形態にされるものではない。例えば異常の発生からの復帰が短期間でなされた場合には、Ｂ−ＯＷＳにおいてＢ−ＢＣの異常を検出できないことがある。このようなケースに備え、通信の負荷が過大にならない程度にReadPropertyによる状態の取得を実行するようにしても良い。あるいはオペレータのマニュアルでの操作によりReadPropertyコマンドを投入するようにしても良い。
【００３６】
また実施形態ではＢＡＣｎｅｔ（登録商標）について説明したが、デバイスの健全性を通知すること、および状態の取得を行うことがプロトコルで既定されているシステムであれば、実施形態において開示された思想はＢＡＣｎｅｔ（登録商標）以外のシステムにおいても適用することができる。
【００３７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００３８】
１１〜１ｎ…監視装置、２１〜２ｍ…ローカルコントローラ、１００…Local Area Network（ＬＡＮ）、４１…ネットワークインタフェース部、４２…表示部、４３…入出力部、４４…データベース部、４４ａ…管理テーブル、４５…主制御部、４５ａ…検出部、４５ｂ…取得部、４５ｃ…配信部、４５ｄ…サーチ部、４５ｅ…要求部、４５ｆ…送信部
【特許請求の範囲】
【請求項１】
それぞれ被監視装置に接続される複数のコントローラと、
前記複数のコントローラに通信ネットワークを介して接続され１つの代表サーバを含む複数のサーバとを具備し、
前記サーバの各々は、
異常の生じたコントローラが当該異常から復帰したことを検出する検出部と、
前記代表サーバであれば、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する取得部と、
前記取得した状態を前記代表サーバ以外のサーバに前記通信ネットワークを介して配信する配信部とを備える、監視システム。
【請求項２】
ＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記検出部は、前記復帰したコントローラから通知されるI-Amの受信により当該コントローラが復帰したことを検出し、
前記取得部は、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項１に記載の監視システム。
【請求項３】
前記配信部は、前記取得した状態を示す情報を圧縮して配信する、請求項１または２のいずれか１項に記載の監視システム。
【請求項４】
それぞれ被監視装置に接続される複数のコントローラと、
前記複数のコントローラに通信ネットワークを介して接続される複数のサーバとを具備し、
前記サーバの各々は、
起動時に正常なサーバを検出するサーチ部と、
前記サーチ部により検出されたサーバのうち少なくとも一つに前記被監視装置の状態の取得を要求する要求部と、
他サーバからの前記要求に応じて前記被監視装置の状態を送信する送信部とを備える、監視システム。
【請求項５】
ＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記要求部は、前記検出されたサーバにReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項４に記載の監視システム。
【請求項６】
前記送信部は、前記状態を示す情報を圧縮して送信する、請求項４または５のいずれか１項に記載の監視システム。
【請求項７】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され１つの代表監視装置を含む複数の監視装置とを具備する監視システムに用いられる前記監視装置であって、
異常の生じたコントローラが当該異常から復帰したことを検出する検出部と、
前記代表監視装置であれば、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する取得部と、
前記取得した状態を前記代表監視装置以外の監視装置に前記通信ネットワークを介して配信する配信部とを備える、監視装置。
【請求項８】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記検出部は、前記復帰したコントローラから通知されるI-Amの受信により当該コントローラが復帰したことを検出し、
前記取得部は、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項７に記載の監視装置。
【請求項９】
前記配信部は、前記取得した状態を示す情報を圧縮して配信する、請求項７または８のいずれか１項に記載の監視装置。
【請求項１０】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数の監視装置とを具備する監視システムに用いられる前記監視装置であって、
起動時に正常な監視装置を検出するサーチ部と、
前記サーチ部により検出された監視装置のうち少なくとも一つに前記被監視装置の状態の取得を要求する要求部と、
他監視装置からの前記要求に応じて前記被監視装置の状態を送信する送信部とを備える、監視装置。
【請求項１１】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記要求部は、前記検出された監視装置にReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項１０に記載の監視装置。
【請求項１２】
前記送信部は、前記状態を示す情報を圧縮して送信する、請求項１０または１１のいずれか１項に記載の監視装置。
【請求項１３】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され１つの代表監視装置を含む複数の監視装置とを具備する監視システムに用いられる前記監視装置による監視方法であって、
前記監視装置が、異常の生じたコントローラが当該異常から復帰したことを検出し、
前記代表監視装置であれば、前記監視装置が、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得し、
前記監視装置が、前記取得した状態を前記代表監視装置以外の監視装置に前記通信ネットワークを介して配信する、監視方法。
【請求項１４】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記検出することは、前記復帰したコントローラから通知されるI-Amの受信により当該コントローラが復帰したことを検出し、
前記取得することは、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項１３に記載の監視方法。
【請求項１５】
前記配信することは、前記取得した状態を示す情報を圧縮して配信する、請求項１３または１４のいずれか１項に記載の監視方法。
【請求項１６】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数の監視装置とを具備する監視システムに用いられる監視装置による監視方法であって、
前記監視装置が、起動時に正常な監視装置を検出し、
前記監視装置が、前記検出された監視装置のうち少なくとも一つに前記被監視装置の状態の取得を要求し、
他監視装置から前記要求を受けた監視装置が、この要求に応じて前記被監視装置の状態を送信する、監視方法。
【請求項１７】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記要求することは、前記検出された監視装置にReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項１６に記載の監視方法。
【請求項１８】
前記送信することは、前記状態を示す情報を圧縮して送信する、請求項１６または１７のいずれか１項に記載の監視方法。
【請求項１】
それぞれ被監視装置に接続される複数のコントローラと、
前記複数のコントローラに通信ネットワークを介して接続され１つの代表サーバを含む複数のサーバとを具備し、
前記サーバの各々は、
異常の生じたコントローラが当該異常から復帰したことを検出する検出部と、
前記代表サーバであれば、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する取得部と、
前記取得した状態を前記代表サーバ以外のサーバに前記通信ネットワークを介して配信する配信部とを備える、監視システム。
【請求項２】
ＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記検出部は、前記復帰したコントローラから通知されるI-Amの受信により当該コントローラが復帰したことを検出し、
前記取得部は、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項１に記載の監視システム。
【請求項３】
前記配信部は、前記取得した状態を示す情報を圧縮して配信する、請求項１または２のいずれか１項に記載の監視システム。
【請求項４】
それぞれ被監視装置に接続される複数のコントローラと、
前記複数のコントローラに通信ネットワークを介して接続される複数のサーバとを具備し、
前記サーバの各々は、
起動時に正常なサーバを検出するサーチ部と、
前記サーチ部により検出されたサーバのうち少なくとも一つに前記被監視装置の状態の取得を要求する要求部と、
他サーバからの前記要求に応じて前記被監視装置の状態を送信する送信部とを備える、監視システム。
【請求項５】
ＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記要求部は、前記検出されたサーバにReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項４に記載の監視システム。
【請求項６】
前記送信部は、前記状態を示す情報を圧縮して送信する、請求項４または５のいずれか１項に記載の監視システム。
【請求項７】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され１つの代表監視装置を含む複数の監視装置とを具備する監視システムに用いられる前記監視装置であって、
異常の生じたコントローラが当該異常から復帰したことを検出する検出部と、
前記代表監視装置であれば、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する取得部と、
前記取得した状態を前記代表監視装置以外の監視装置に前記通信ネットワークを介して配信する配信部とを備える、監視装置。
【請求項８】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記検出部は、前記復帰したコントローラから通知されるI-Amの受信により当該コントローラが復帰したことを検出し、
前記取得部は、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項７に記載の監視装置。
【請求項９】
前記配信部は、前記取得した状態を示す情報を圧縮して配信する、請求項７または８のいずれか１項に記載の監視装置。
【請求項１０】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数の監視装置とを具備する監視システムに用いられる前記監視装置であって、
起動時に正常な監視装置を検出するサーチ部と、
前記サーチ部により検出された監視装置のうち少なくとも一つに前記被監視装置の状態の取得を要求する要求部と、
他監視装置からの前記要求に応じて前記被監視装置の状態を送信する送信部とを備える、監視装置。
【請求項１１】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記要求部は、前記検出された監視装置にReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項１０に記載の監視装置。
【請求項１２】
前記送信部は、前記状態を示す情報を圧縮して送信する、請求項１０または１１のいずれか１項に記載の監視装置。
【請求項１３】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され１つの代表監視装置を含む複数の監視装置とを具備する監視システムに用いられる前記監視装置による監視方法であって、
前記監視装置が、異常の生じたコントローラが当該異常から復帰したことを検出し、
前記代表監視装置であれば、前記監視装置が、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得し、
前記監視装置が、前記取得した状態を前記代表監視装置以外の監視装置に前記通信ネットワークを介して配信する、監視方法。
【請求項１４】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記検出することは、前記復帰したコントローラから通知されるI-Amの受信により当該コントローラが復帰したことを検出し、
前記取得することは、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項１３に記載の監視方法。
【請求項１５】
前記配信することは、前記取得した状態を示す情報を圧縮して配信する、請求項１３または１４のいずれか１項に記載の監視方法。
【請求項１６】
それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数の監視装置とを具備する監視システムに用いられる監視装置による監視方法であって、
前記監視装置が、起動時に正常な監視装置を検出し、
前記監視装置が、前記検出された監視装置のうち少なくとも一つに前記被監視装置の状態の取得を要求し、
他監視装置から前記要求を受けた監視装置が、この要求に応じて前記被監視装置の状態を送信する、監視方法。
【請求項１７】
前記監視システムはＢＡＣｎｅｔ（登録商標）に準拠しUnconfirmedEventNotificationを用いる監視システムであって、
前記要求することは、前記検出された監視装置にReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項１６に記載の監視方法。
【請求項１８】
前記送信することは、前記状態を示す情報を圧縮して送信する、請求項１６または１７のいずれか１項に記載の監視方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−７７９８１（Ｐ２０１３−７７９８１Ａ）
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願番号】特願２０１１−２１６５７１（Ｐ２０１１−２１６５７１）
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]