それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され1つの代表サーバを含む複数のサーバとを具備し、前記サーバの各々は、異常の生じたコントローラが当該異常から復帰したことを検出する検出部と、前記代表サーバであれば、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する取得部と、前記取得した状態を前記代表サーバ以外のサーバに前記通信ネットワークを介して配信する配信部とを備える、監視システム。BACnet登録商標に準拠しUnconfirmedEventNotificationを用いる監視システムであって、前記検出部は、前記復帰したコントローラから通知されるIAmの受信により当該コントローラが復帰したことを検出し、前記取得部は、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項1に記載の監視システム。前記配信部は、前記取得した状態を示す情報を圧縮して配信する、請求項1または2のいずれか1項に記載の監視システム。それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数のサーバとを具備し、前記サーバの各々は、起動時に正常なサーバを検出するサーチ部と、前記サーチ部により検出されたサーバのうち少なくとも一つに前記被監視装置の状態の取得を要求する要求部と、他サーバからの前記要求に応じて前記被監視装置の状態を送信する送信部とを備える、監視システム。BACnet登録商標に準拠しUnconfirmedEventNotificationを用いる監視システムであって、前記要求部は、前記検出されたサーバにReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項4に記載の監視システム。前記送信部は、前記状態を示す情報を圧縮して送信する、請求項4または5のいずれか1項に記載の監視システム。それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され1つの代表監視装置を含む複数の監視装置とを具備する監視システムに用いられる前記監視装置であって、異常の生じたコントローラが当該異常から復帰したことを検出する検出部と、前記代表監視装置であれば、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する取得部と、前記取得した状態を前記代表監視装置以外の監視装置に前記通信ネットワークを介して配信する配信部とを備える、監視装置。前記監視システムはBACnet登録商標に準拠しUnconfirmedEventNotificationを用いる監視システムであって、前記検出部は、前記復帰したコントローラから通知されるIAmの受信により当該コントローラが復帰したことを検出し、前記取得部は、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項7に記載の監視装置。前記配信部は、前記取得した状態を示す情報を圧縮して配信する、請求項7または8のいずれか1項に記載の監視装置。それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数の監視装置とを具備する監視システムに用いられる前記監視装置であって、起動時に正常な監視装置を検出するサーチ部と、前記サーチ部により検出された監視装置のうち少なくとも一つに前記被監視装置の状態の取得を要求する要求部と、他監視装置からの前記要求に応じて前記被監視装置の状態を送信する送信部とを備える、監視装置。前記監視システムはBACnet登録商標に準拠しUnconfirmedEventNotificationを用いる監視システムであって、前記要求部は、前記検出された監視装置にReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項10に記載の監視装置。前記送信部は、前記状態を示す情報を圧縮して送信する、請求項10または11のいずれか1項に記載の監視装置。それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続され1つの代表監視装置を含む複数の監視装置とを具備する監視システムに用いられる前記監視装置による監視方法であって、前記監視装置が、異常の生じたコントローラが当該異常から復帰したことを検出し、前記代表監視装置であれば、前記監視装置が、前記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得し、前記監視装置が、前記取得した状態を前記代表監視装置以外の監視装置に前記通信ネットワークを介して配信する、監視方法。前記監視システムはBACnet登録商標に準拠しUnconfirmedEventNotificationを用いる監視システムであって、前記検出することは、前記復帰したコントローラから通知されるIAmの受信により当該コントローラが復帰したことを検出し、前記取得することは、前記復帰したコントローラにReadPropertyを送信して当該コントローラに接続される被監視装置の状態を取得する、請求項13に記載の監視方法。前記配信することは、前記取得した状態を示す情報を圧縮して配信する、請求項13または14のいずれか1項に記載の監視方法。それぞれ被監視装置に接続される複数のコントローラと、前記複数のコントローラに通信ネットワークを介して接続される複数の監視装置とを具備する監視システムに用いられる監視装置による監視方法であって、前記監視装置が、起動時に正常な監視装置を検出し、前記監視装置が、前記検出された監視装置のうち少なくとも一つに前記被監視装置の状態の取得を要求し、他監視装置から前記要求を受けた監視装置が、この要求に応じて前記被監視装置の状態を送信する、監視方法。前記監視システムはBACnet登録商標に準拠しUnconfirmedEventNotificationを用いる監視システムであって、前記要求することは、前記検出された監視装置にReadPropertyを送信して前記監視システム内の被監視装置の状態の取得を要求する、請求項16に記載の監視方法。前記送信することは、前記状態を示す情報を圧縮して送信する、請求項16または17のいずれか1項に記載の監視方法。上記したように確認無しイベント通告を用いる既存の監視システムでは、B-BCの保持する状態とB-OWSの認識している状態つまりB-OWSの取得している状態との間の不整合が起こりうる。これを避けるため既存の技術では、リードプロパティReadProperty:UDPパケットを各B-OWSからB-BCへ定期的に送信し、監視対象機器以下、被監視装置と総称するの現在の正しい状態を取得するようにしていた。しかしながらリードプロパティの送信周期が短いとB-BCの通信負荷が大きくなる。リードプロパティが限度を超えて頻発するとB-BCをダウンさせてしまうケースもあり、マルチベンダ環境下では特に注意しなくてはならない。逆に送信周期を長くすると、不整合が解消されるまでに時間がかかる。このように既存の技術では通信負荷の低減と不整合期間の短縮との両立が難しく、解決策が模索されている。目的は、最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、監視装置および監視方法を提供することにある。実施形態によれば、監視システムは、それぞれ被監視装置に接続される複数のコントローラと、上記複数のコントローラに通信ネットワークを介して接続され1つの代表サーバを含む複数のサーバとを具備する。上記サーバの各々は、検出部と、取得部と、配信部とを備える。検出部は、異常の生じたコントローラが当該異常から復帰したことを検出する。取得部は、上記代表サーバであれば、上記異常から復帰したコントローラに接続される被監視装置の状態を当該復帰したコントローラから取得する。配信部は、上記取得した状態を上記代表サーバ以外のサーバに上記通信ネットワークを介して配信する。図1は、実施形態に係わる監視システムの一例を示すシステム図である。図1において、複数の監視装置11~1nおよびローカルコントローラ21~2mが通信ネットワークとしてのLocalAreaNetworkLAN100に接続される。実施形態においてLAN100の上位層にはBACnet登録商標が形成される。すなわち実施形態に係わる監視システムはBACnet登録商標に準拠する。これにより監視システム内に異ベンダシステムが混在することが可能になる。ローカルコントローラ21~2mにはそれぞれ通信回線を介してノードが接続される。各ノードは例えばフロアごとの空調機器、照明機器、動力機器などである。ローカルコントローラ21~2mはそれぞれ接続されるノードを被監視装置として認識し、その状態をモニタする。ローカルコントローラ21~2mは実施形態においてはB-BCとして機能する。監視装置11~1nはローカルコントローラ21~2mから通知されるモニタ結果を受け監視システムを上位レベルで監視制御したり、オペレータに各種の情報を提供したりするサーバとしての機能を有する。監視装置11~1nは実施形態においてはB-OWSとして機能する。実施形態では監視装置11~1nのうち一つを、監視装置11~1nの代表として機能させる。代表としての監視装置を代表サーバと称することにする。代表サーバを決めるにあたっては監視装置11~1nにそれぞれユニークな番号を予め決めておき、正常な監視装置のうち一番若い番号の監視装置を代表サーバとして機能させることとする。もちろん、番号の一番大きい監視装置を代表サーバとしても良い。[第1の実施形態]図2は、図1に示される監視装置11~1nの第1の実施の形態を示す機能ブロック図である。監視装置11~1nは、ネットワークインタフェース部41、表示部42、入出力部43、データベース部44、および、主制御部45を備える。インタフェース部41はLAN100との通信に係わるインタフェース処理を担う。表示部42は入出力部43とともにユーザインタフェースを提供し、GUIGraphicalUserInterface環境を構築する。データベース部44はハードディスクドライブなどのストレージデバイスであり、管理テーブル44aを記憶する。管理テーブル44aにはシステム内の被監視装置ノードの個別の状態などが記憶される。表示部42および入出力部43は管理テーブル44aから取得したデータを処理し、例えばWebブラウザなどの形態でユーザへの情報通知を行う。ところで、主制御部45は、この実施形態に係わる処理機能として検出部45a、取得部45b、および、配信部45cを備える。検出部45aは、異常の生じたローカルコントローラが異常から復帰したことを検出する。実施形態では、検出部45aは異常から復帰したローカルコントローラから通知されるIAmを受信することでその送信元のローカルコントローラが復帰したことを検出する。BACnet登録商標にはB-OWS/B-BCの健全性をチェックする仕組みが規定されている。すなわち各デバイスから60秒ごとに送信されるIAm健全性通知、UDPパケットが150秒間にわたって不達であれば、そのIAmの送信元デバイスに異常が生じたと判定することになっている。また、異常と判定されている状態のデバイスからIAmが届けば正常復帰と判定することになっている。検出部45aはこのルールを利用してローカルコントローラの正常復帰を検出する。なお異常とはローカルコントローラ自体の障害だけでなく、監視装置とローカルコントローラとを結ぶ通信回線LAN100を含むにおける障害をも含む概念である。実施形態では要するに、監視装置とローカルコントローラとの通信に障害が生じた状態を異常と称する。このような状態は基板異常、ネットワーク断線、熱暴走などあらゆる状況で起こり得る。取得部45bは、自らが代表サーバであれば、異常から復帰したローカルコントローラに接続される各ノードの状態を取得する。すなわち取得部45bは復帰したローカルコントローラにReadPropertyを送信し、その返信を受けることで送出先のローカルコントローラに接続されるノードの状態を取得する。配信部45cは、取得した各ノードの状態を代表サーバ以外の監視装置、つまり他の監視装置にLAN100を介して配信する。その際、配信部45cは、各ノードの状態を示す情報を圧縮して配信することで、LAN100を流れるトラフィックを抑制する。次に、上記構成における作用を説明する。図3は、第1の実施形態における処理手順を示すフローチャートである。図4と併せて説明する。なお図4においてはBACnet登録商標における役割の明示のため、監視装置をB-OWSと表記し、ローカルコントローラ21~2mをB-BCと表記する。便宜上、監視装置11を代表サーバとし、ローカルコントローラ21に異常が生じたとする。図3において、監視装置11がローカルコントローラ21の異常からの復帰を検出するとステップS1、監視装置11は自らが代表サーバであるか否かを判定するステップS2。仮に代表サーバでなければステップS2でNo、監視装置11は図3に係わる主体的な処理を実施することなく他の装置からの通知を待ち受ける。監視装置11は代表サーバであるのでステップS2でYes、復帰したローカルコントローラ21にReadPropertyを送信し、ローカルコントローラ21の配下のノードの状態を取得するステップS3。次に監視装置11は取得したデータを既定のフォーマットで圧縮したのちステップS4、他の監視装置に向け配信するステップS5。ステップS5の手順はステップS61~S62のループにおいて他の監視装置の数すなわちn-1回繰り返される。なお配信の順番は、例えば監視装置の番号順とすれば良い。図4に示すように、B-BCとしてのローカルコントローラ21が異常から復帰すると[1]、IAmが送出されて監視装置11により受信される。IAmを受けた監視装置11はローカルコントローラ21の復帰を検出し[2]、このローカルコントローラ21からノードの状態を取得する[3]。データの取得が完了すると監視装置11は取得したデータを圧縮して他の全ての監視装置12~1nに向け配信する[4]。図5aに示すように、UnconfirmedEventNotificationではパケットの到着が保証されないのでメッセージの未達が起こることがある。またB-BCや通信回線に異常が起こるとメッセージを送信できないこともある。このようなケースではB-BCとB-OWSとの双方が互いに保持する情報ノードの状態を含むが一致しないケースがある。これを避けるため図5bに示すように、B-OWSから一定の周期でReadpropertyをB-BCに送信するようにしたシステムもあるが、通信負荷が大きくなる。そこで第1の実施形態では、BACnet登録商標ベースであって主としてUnconfirmedEventNotificationにより状態通知を行う監視システムにおいて、B-BCの異常からの復帰をトリガとしてB-OWSの主体的な処理によりノードの状態を取得するようにしている。すなわちB-BCの復帰を検出したB-OWSは、復帰したB-BCにReadPropertyを送信して配下のノードの状態の返信を要求する。ただしこの処理を、自らが代表サーバである場合にのみ、B-OWSは実行する。これにより復帰したB-BCの通信負荷を最小にできる。B-OWSはReadPropertyに対する返信により状態を取得すると、取得したデータを圧縮して他のB-OWSに配信する。これによりLAN100の通信負荷も抑えることができる。また、復帰したB-BCに全てのB-OWSが個別に問い合わせるよりも、通信量を格段に削減することができる。通信負荷が少ないことは、B-BCとB-OWSとの間、および各B-OWS間でのデータの同期整合にかかる時間を短縮できることを意味する。また第1の実施形態では、ReadPropertyの定期的な送信ではなく、B-BCの復帰後ただちにReadPropertyを送信するようにしているので、B-OWSにおけるノードの状態の取得にかかる時間を最小にすることができる。よってB-BCの保持する状態とB-OWSの認識している状態とが一致していない期間を、可能な限り短くすることが可能になる。これらのことから、最小限の通信負荷で被監視装置の状態を迅速に認識可能な監視システム、監視装置および監視方法を提供することが可能となる。[第2の実施形態]図6は、監視装置11~1nの第2の実施の形態を示す機能ブロック図である。図6において図2と共通する部分には同じ符号を付し、ここでは異なる部分についてのみ説明する。第2の実施形態では、主制御部45はサーチ部45d、要求部45e、および、送信部45fを備える。サーチ部45dは、自らの監視装置が起動する際に、正常に稼動している他の監視装置を検出する。要求部45eは、サーチ部45dにより検出された監視装置のうち少なくとも一つに、当該監視装置が認識している監視システム内のノード被監視装置の状態の取得を要求する。送信部45fは、他の監視装置から上記要求を受けると、その要求に応じて被監視装置の状態を送信する。その際、送信部45fは、各ノードの状態を示す情報を圧縮して配信することで、LAN100を流れるトラフィックを抑制する。次に、上記構成における作用を説明する。図7は、第2の実施形態における処理手順を示すフローチャートである。第2の実施形態では監視装置すなわちB-OWSの起動時における処理につき説明する。以下では監視装置1nが起動した際の処理を説明する。図7において、監視装置1nB-OWSが起動するとステップS7、監視装置1nは他に正常稼動しているB-OWSがLAN100上に存在するか否かをサーチするステップS8。健全なB-OWSが見つかればステップS8でYes、監視装置1nはそのいずれかのB-OWSにReadPropertyを送信し、当該B-OWSに保持されているシステムの状態、すなわち全てのB-BCの状態を取得するステップS9。ここでは例えば代表サーバとしてのB-OWS監視装置11から必要なデータを取得するようにする。その際、データの送出元である監視装置11は、要求されたデータを圧縮してReadPropertyの送信元である監視装置1nに返送する。これによりLAN100上のトラフィックを削減できる。健全なB-OWSが見つからなければステップS8でNo、監視装置1nは全てのB-BCにReadPropertyを送信し、各B-BCの状態を個別に取得するステップS10。図8に示すように、B-OWSとしての監視装置1nが起動すると[1]、監視装置1nは正常な監視装置を見つけ出す。代表としての監視装置11が正常であれば、監視装置1nは圧縮されたデータを監視装置11から取得する[2]。以上のように第2の実施形態では、B-OWS起動時におけるB-BCとの状態合わせシーケンスにおいて、B-BCへReadPropertyを送信することなく、必要なデータを代表のB-OWSに要求することで取得するようにしている。すなわちB-OWSの起動時には、その時点での正しい情報を表示するために全B-BCから状態を取得するようになっている。そこで第2の実施形態では他の健全なB-OWSから状態を示す情報を取得することで、通信負荷を削減する。また、要求を受けたB-OWSは状態データを圧縮して送信することで通信負荷をさらに削減する。このようにしたので、監視装置の起動時においても第1の実施形態と同様の効果を得ることが可能になる。なお本発明は上記実施の形態にされるものではない。例えば異常の発生からの復帰が短期間でなされた場合には、B-OWSにおいてB-BCの異常を検出できないことがある。このようなケースに備え、通信の負荷が過大にならない程度にReadPropertyによる状態の取得を実行するようにしても良い。あるいはオペレータのマニュアルでの操作によりReadPropertyコマンドを投入するようにしても良い。また実施形態ではBACnet登録商標について説明したが、デバイスの健全性を通知すること、および状態の取得を行うことがプロトコルで既定されているシステムであれば、実施形態において開示された思想はBACnet登録商標以外のシステムにおいても適用することができる。本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。