遠隔監視システム
【課題】異常情報発報の集中時に他社監視センタが活用できるバックアップ態勢を講じて自社監視センタでの異常対応に支障をきたさないようにした遠隔監視システムを提供すること。
【解決手段】端末装置からの異常情報発報を受信する監視サーバ２が、自社監視センタ３，４や他社監視センタ５の未対応件数がそれぞれ過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である自社監視センタ３（または４）の未対応件数が過剰件数に達しているときには、該異常情報発報を未対応件数が過剰件数に達していない他社監視センタ５へ配信できるようにした。ただし、異常情報発報が緊急対応を要する重要発報の場合は、未対応件数に拘らず予め指定された自社監視センタ３（または４）へ配信するようにした。
【解決手段】端末装置からの異常情報発報を受信する監視サーバ２が、自社監視センタ３，４や他社監視センタ５の未対応件数がそれぞれ過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である自社監視センタ３（または４）の未対応件数が過剰件数に達しているときには、該異常情報発報を未対応件数が過剰件数に達していない他社監視センタ５へ配信できるようにした。ただし、異常情報発報が緊急対応を要する重要発報の場合は、未対応件数に拘らず予め指定された自社監視センタ３（または４）へ配信するようにした。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象の設備機器の異常が検出されたときに端末装置から通報される異常情報発報が、自社監視センタだけでなく他社監視センタへも配信可能な遠隔監視システムに関する。
【背景技術】
【０００２】
この種の遠隔監視システムの従来例として、建物内の設備機器が自社監視対象であるか他社監視対象であるかに応じて、各建物内の端末装置から通報された異常情報発報の配信先を監視サーバが決定し、規模の異なる複数の他社監視センタがそれぞれ監視対象の設備機器に関する異常情報発報を確実に取得できるようにしたものが知られている（例えば、特許文献１参照）。かかる従来の遠隔監視システムにおいて、前記監視サーバは、自社監視対象の設備機器に関する異常情報発報を自社監視センタへ配信して、迅速な異常対応が行えるようにしている。また、前記監視サーバは、他社監視対象の設備機器に関する異常情報発報は他社監視センタへ配信するが、他社監視センタが休止中の場合は該異常情報を記憶手段に格納して随時アクセス可能な状態にしておく。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−６５７６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前述した従来の遠隔監視システムは、自社監視対象の設備機器に関する異常情報発報は自社監視センタへ配信し、他社監視対象の設備機器に関する異常情報発報は他社監視センタへ配信するというものであるが、自社監視センタに異常情報発報が集中した際に他社監視センタが活用できる特別なバックアップ態勢が講じられているわけではない。そのため、広域災害などによって自社監視センタに各種の異常情報発報が集中すると、自社監視センタでは異常対応に手間取ってしまい、例えば、エレベータのかご内に乗客が閉じ込められて通報されたにも拘らず迅速に救出できない等の問題が発生し、態勢不備を指摘されかねない。
【０００５】
本発明は、このような従来技術の実情に鑑みてなされたもので、その目的は、異常情報発報の集中時に他社監視センタが活用できるバックアップ態勢を講じて自社監視センタでの異常対応に支障をきたさないようにした遠隔監視システムを提供することにある。
【課題を解決するための手段】
【０００６】
上記の目的を達成するために、本発明は、複数の建物にそれぞれ設置されて監視対象の設備機器の異常が検出されると異常情報を発報する端末装置と、これら複数の端末装置と通信回線を介して接続されて前記異常情報発報の配信先を管理する監視サーバと、前記異常情報発報が配信可能な１つ以上の自社監視センタおよび１つ以上の他社監視センタとを備えた遠隔監視システムにおいて、前記監視サーバが、前記自社監視センタと前記他社監視センタのそれぞれについて、未対応な前記異常情報発報の件数に基づき、該未対応件数が監視センタ毎に定めた過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である前記自社監視センタの未対応件数がその過剰件数に達しているときには、該異常情報発報を未対応件数がその過剰件数に達していない前記他社監視センタへ配信できるようにした。
【０００７】
このように異常情報発報の配信先を管理する監視サーバが、自社監視センタや他社監視センタの未対応件数がそれぞれ過剰件数に達しているか否かを把握していれば、自社監視センタへの異常情報発報が集中しているときに、優先的な配信先が自社監視センタである異常情報発報を、未対応件数が過剰件数に達していない他社監視センタへ配信することによって、異常対応の停滞が回避しやすくなる。すなわち、この遠隔監視システムは、異常対応に余裕のある他社監視センタを活用してバックアップ態勢が強化されているため、広域災害などで自社監視センタに各種の異常情報発報が集中した場合にも、自社監視センタでの異常対応が円滑に行いやすくなる。
【０００８】
上記の遠隔監視システムにおいて、監視サーバが、通報された異常情報発報の内容が緊急対応を要するものであるか否かを判定し、優先的な配信先が自社監視センタで緊急対応を要すると判定された異常情報発報については、未対応件数に拘らず該自社監視センタへ配信するようにしてあれば、緊急対応を要する異常情報（例えばエレベータの閉じ込め事故等）の発報には常に自社監視センタで対応できるため、致命的な対応遅れが回避しやすくなる。なお、この場合も、未対応件数が過剰件数に達している自社監視センタを優先的な配信先とする異常情報発報の内容が、緊急対応を要するものではない（例えば空調設備の故障等）と判定されたときには、これを他社監視センタへ配信して協力してもらうことで自社監視センタでの異常対応が円滑に行いやすくなり、且つ、緊急性の高い異常対応への協力を要請されるわけではないので他社監視センタ側の負担も軽減できる。
【発明の効果】
【０００９】
本発明の遠隔監視システムによれば、自社監視センタや他社監視センタの未対応件数がそれぞれ過剰件数に達しているか否かを、異常情報発報の配信先を管理する監視サーバが把握しており、自社監視センタへの異常情報発報が集中しているときに、優先的な配信先が自社監視センタである異常情報発報を、未対応件数が過剰件数に達していない他社監視センタへ配信できるようになっている。したがって、広域災害などで自社監視センタに各種の異常情報発報が集中したときに、異常対応に余裕のある他社監視センタが活用できることになってバックアップ態勢が強化され、自社監視センタでの異常対応が円滑に行いやすくなる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態例に係る遠隔監視システムの全体構成を示すブロック図である。
【図２】該遠隔監視システムで監視サーバが異常情報発報の配信先を決定する際に行う処理手順を示すフローチャートである。
【図３】該監視サーバによって作成される発報別情報テーブルの一例を示す説明図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態例に係る遠隔監視システムについて図１〜図３を参照しながら説明する。
【００１２】
図１に示すように、本実施形態例に係る遠隔監視システムで用いられる監視サーバ２は、通信回線７を介して自社監視センタ３および自社監視センタ４と接続されていると共に、通信回線８を介して他社監視センタ５と接続されている。これら各監視センタ３〜５は、後述する端末装置を介して監視対象の設備機器を遠隔的に監視している。また、監視サーバ２は一般電話回線６を介して、監視エリアＡに存する図示せぬ複数の建物にそれぞれ設置された端末装置１Ａｎ（ただしｎは不特定な自然数。以下同）や、監視エリアＢに存する図示せぬ複数の建物にそれぞれ設置された端末装置１Ｂｎと接続されている。端末装置群１Ａ１〜１Ａｎに含まれる多くの端末装置は、自社監視対象の設備機器の動作状態を自社監視センタ３へ自動発報するためのものである。同様に、端末装置群１Ｂ１〜１Ｂｎに含まれる多くの端末装置は、自社監視対象の設備機器の動作状態を自社監視センタ４へ自動発報するためのものである。ただし、端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎのうちの一部は、他社監視対象の設備機器の動作状態を他社監視センタ５へ自動発報するための端末装置である。
【００１３】
なお、監視対象の設備機器とはエレベータや空調設備、電気設備、防犯装置、防災装置などであり、前記端末装置は監視対象の設備機器と電気的に接続されているため、電気信号の変化に基づき設備機器の異常や復旧状態等を端末装置が検知できるようになっている。
【００１４】
端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎに含まれる個々の端末装置は、監視対象の設備機器の異常が検出されると異常情報を発報し、この異常情報発報は一般電話回線６を介して監視サーバ２へ通報される。監視サーバ２では、受信した異常情報発報を所定の配信先へ送信する。すなわち、配信先が自社監視センタ３や自社監視センタ４の場合は、監視サーバ２から通信回線７を介して異常情報発報が送信され、配信先が他社監視センタ５の場合は、監視サーバ２から通信回線８を介して異常情報発報が送信される。これにより、自社監視センタ３，４や他社監視センタ５では、受信した異常情報発報の内容に応じた迅速な対応が可能となる。なお、本実施形態例では、他社監視センタ５での送受信が監視サーバ２に接続可能な通信機能を有する汎用パソコンによって行われるため、通信回線８としてインターネット回線を利用している。
【００１５】
自社監視センタ３には複数の監視卓３１〜３ｎが設けられており、自社監視センタ４には複数の監視卓４１〜４ｎが設けられている。端末装置群１Ａ１〜１Ａｎのうち自社監視対象の設備機器と接続されている自社端末装置から発報された異常情報は、通常は自社監視センタ３へ配信されて対応する監視卓（例えば監視卓３１）に表示される。同様に、端末装置群１Ｂ１〜１Ｂｎのうち自社監視対象の設備機器と接続されている自社端末装置から発報された異常情報は、通常は自社監視センタ４へ配信されて対応する監視卓（例えば監視卓４１）に表示される。また、端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎのうち他社監視対象の設備機器と接続されている他社端末装置から発報された異常情報は、それぞれが他社監視センタ５として機能する他社監視卓５１〜５ｎに表示される。
【００１６】
監視サーバ２には、端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎとの接続を制御する回線制御装置２１と、受信データや送信データを管理するための演算処理等を行う制御装置２２と、制御装置２２の指定したデータを記憶する記憶装置２３と、自社監視センタ３，４や他社監視センタ５との送受信を制御する送受信制御装置２４とが備えられており、記憶装置２３には未対応件数管理テーブル２３Ａが設けられている。この未対応件数管理テーブル２３Ａには、監視センタ３〜５別に、対応すべき異常情報発報のうち未対応な発報の件数（未対応件数）と、この未対応件数が過剰ではないと判断しうる上限の件数（余裕限界件数）とが記憶されており、未対応件数が余裕限界件数よりも１件多い過剰件数に達すると、その監視センタは異常対応に手間取る可能性が高まる。
【００１７】
また、制御装置２２には、端末装置からの異常情報発報の配信先を決定するための監視センタ対応指令部２２Ａが設けられている。この監視センタ対応指令部２２Ａは、通常時には、受信した異常情報発報をその優先的な配信先へと配信するが、前記未対応件数が前記過剰件数に達している自社監視センタ３や自社監視センタ４を配信先とする異常情報発報を受信し、その異常情報の内容が緊急対応を要するものでないと確認できたときには、配信先の変更を行うように指令する。その際、新たな配信先に選定する監視センタは異常対応に余裕のあることが前提となるため、例えば、優先的な配信先が自社監視センタ３である異常情報発報の新たな配信先として、自社監視センタ４が不適な場合は、未対応件数が過剰件数に達していない他社監視センタ５が選定されるようになっている。
【００１８】
次に、監視サーバ２が端末装置からの異常情報発報の配信先を決定する際に行う処理手順を、図２のフローチャートを参照しながら説明する。
【００１９】
端末装置からの異常情報発報を回線制御装置２１が受信する（ステップＳ１）と、制御装置２２は、この異常情報発報のデータを図３に示す発報別情報テーブルＦに書き込む（ステップＳ２）。この発報別情報テーブルＦには、受信連番の項目Ｆ１と、ビル名の項目Ｆ２と、異常発生時刻の項目Ｆ３と、監視設備名の項目Ｆ４と、異常状態の項目Ｆ５と、対応先コードの項目Ｆ６とが用意されており、ステップＳ２では項目Ｆ６を除く各項目（Ｆ１〜Ｆ５）に異常情報発報のデータを書き込む。
【００２０】
ここで、発報別情報テーブルＦの各項目の内容について説明すると、項目Ｆ１の受信連番は、異常情報発報を受信する度に新規に採番されるコード番号（例えば９桁の通し番号）である。項目Ｆ２のビル名は、異常情報を発報した端末装置が設置されているビルの名称である。項目Ｆ３の異常発生時刻は、異常情報発報を受信した時刻である。項目Ｆ４の監視設備名は、異常が発生した監視対象の設備機器の名称である。項目Ｆ５の異常状態は、その設備機器の異常状態の内容ならびに対応優先度の重要度ランクであり、異常状態の内容が緊急対応を要する場合は、対応優先度がランクＡに指定される。項目Ｆ６の対応先コードは、異常情報発報の配信先として監視センタ対応指令部２２Ａが最終的に決定した監視センタ名を示すコード番号である。
【００２１】
図２のフローチャートへ戻り、ステップＳ２の後、制御装置２２の監視センタ対応指令部２２Ａは、記憶装置２３に記憶されているデータを参照して、受信した異常情報発報の優先的な配信先（通常時の対応先）がどの監視センタであるのかを確認する（ステップＳ３）。すなわち、異常情報を発報する端末装置毎に、その異常情報発報の優先的な配信先がどの監視センタであるのかは、予め端末別対応先データとして記憶装置２３に記憶されている。例えば、監視エリア１Ａ内の端末装置群１Ａ１〜１Ａｎの多くは優先的な配信先が自社監視センタ３であり、監視エリア１Ｂ内の端末装置群１Ｂ１〜１Ｂｎの多くは優先的な配信先が自社監視センタ４である。
【００２２】
ステップＳ３の後、制御装置２２の監視センタ対応指令部２２Ａは、受信した異常情報発報の優先的な配信先が自社監視センタ３または自社監視センタ４であるか否かを判定し（ステップＳ４）、判定が「Ｙｅｓ」の場合はステップＳ５へ進む。ただし、受信した異常情報発報の優先的な配信先が他社監視センタ５の場合は、ステップＳ４での判定が「Ｎｏ」となるため、ステップＳ１４へ進んで対応可能な他社監視センタ５を探し、該当する他社監視センタ５（例えば他社監視卓５１）を示すコード番号（例えば０５１）を発報別情報テーブルＦの対応先コードの項目Ｆ６に書き込んだ（ステップＳ１５）後、この異常情報発報を該当する他社監視センタ５へ配信（ステップＳ１６）して処理を終了する。
【００２３】
ステップＳ４での判定が「Ｙｅｓ」の場合は、ステップＳ５において、受信した異常情報が監視エリア１Ａ内の自社端末装置から発報されたものであるか否かを判定する。そして、ステップＳ５での判定が「Ｙｅｓ」の場合は、次なるステップＳ６で、その異常情報発報の内容の緊急性を判定し、緊急対応を要する重要発報ではないと確認された場合はステップＳ７へ進む。すなわち、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報を受信した場合、ステップＳ６での判定が「Ｙｅｓ」となり、次なるステップＳ７において、自社監視センタ３の未対応件数が過剰件数未満であるか否かが判定される。前述したように、監視センタでは未対応件数が余裕限界件数を上回る（つまり過剰件数に達する）と、異常対応に手間取る可能性が高まる。また、この余裕限界件数は監視センタの規模に応じて予め設定されており、本実施形態例では、自社監視センタ３，４の余裕限界件数をいずれも１０件とし、他社監視センタ５の余裕限界件数を例えば５件としている。
【００２４】
ステップＳ７で自社監視センタ３の未対応件数が過剰件数未満（１０件以内）であると判定された場合、自社監視センタ３は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報を、通常どおり自社監視センタ３へ配信するという決定を下し、発報別情報テーブルＦの対応先コードの項目Ｆ６に自社監視センタ３を示すコード番号（例えば００３）を書き込む（ステップＳ８）。そして、次なるステップＳ９で、この異常情報発報を送受信制御装置２４を介して自社監視センタ３へ配信した後、処理を終了する。
【００２５】
また、ステップＳ６での判定が「Ｎｏ」の場合、つまり、自社監視センタ３を優先的な配信先とする異常情報発報が緊急対応を要する重要発報（対応優先度がランクＡ）であると判定された場合は、自社監視センタ３の未対応件数に拘らず、監視センタ対応指令部２２Ａは配信先を自社監視センタ３に決定して、発報別情報テーブルＦの項目Ｆ６に自社監視センタ３を示すコード番号を書き込む（ステップＳ８）。そして、この異常情報発報を自社監視センタ３へ配信（ステップＳ９）した後、処理を終了する。したがって、この場合、自社監視センタ３の未対応件数が余裕限界件数（１０件）を上回ってしまうこともある。ただし、仮に未対応件数が過剰件数に達したとしても、エレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報を受信したときには、迅速な対応が最優先されるため、自社監視センタ３では緊急性の高くない未対応な異常情報発報については後刻対応することとし、ある程度の対応遅れを容認する。
【００２６】
一方、ステップＳ７で自社監視センタ３の未対応件数が過剰件数に達していると判定された場合はステップＳ１７へ進んで、別の自社監視センタ４の未対応件数が過剰件数未満（１０件以内）であるか否かが判定される。そして、ステップＳ１７での判定が「Ｙｅｓ」の場合、自社監視センタ４は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報を、別の自社監視センタ４へ配信するという配信先変更の決定を下し、発報別情報テーブルＦの対応先コードの項目Ｆ６に自社監視センタ４を示すコード番号（例えば００４）を書き込む（ステップＳ１２）。そして、次なるステップＳ１３で、この異常情報発報を送受信制御装置２４を介して自社監視センタ４へ配信した後、処理を終了する。
【００２７】
しかるに、ステップＳ１７での判定が「Ｎｏ」の場合は、別の自社監視センタ４の未対応件数も過剰件数に達している場合なので、監視センタ対応指令部２２Ａは、まず記憶装置２３の未対応件数管理テーブル２３Ａを参照して、未対応件数が過剰件数未満（例えば５件以内）の他社監視センタ５を探し（ステップＳ１４）、該当する他社監視センタ５（例えば他社監視卓５１）を、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報の配信先に決定する。つまり、監視センタ対応指令部２２Ａは、この異常情報発報をいずれかの他社監視センタ５へ配信するという配信先変更の決定を下し、発報別情報テーブルＦの対応先コードの項目Ｆ６に該当する他社監視センタ５を示すコード番号（例えば０５１）を書き込む（ステップＳ１５）。そして、次なるステップＳ１６で、この異常情報発報を送受信制御装置２４を介して該当する他社監視センタ５へ配信した後、処理を終了する。
【００２８】
一方、前記ステップＳ５での判定が「Ｎｏ」の場合、つまり、受信した異常情報発報が監視エリア１Ａ内の自社端末装置から発報されたものではないと判定された場合は、監視エリア１Ｂ内の自社端末装置から発報された異常情報発報であり、その優先的な配信先は自社監視センタ４であることがわかる。それゆえ、まずステップＳ１０へ進んで、受信した異常情報発報の内容の緊急性を判定する。このステップＳ１０において、緊急対応を要する重要発報ではないと確認された場合はステップＳ１１へ進んで、自社監視センタ４の未対応件数が過剰件数未満（１０件以内）であるか否かが判定される。
【００２９】
ステップＳ１１で自社監視センタ４の未対応件数が過剰件数未満であると判定された場合、自社監視センタ４は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ４を優先的な配信先とする緊急性の高くない異常情報発報を、通常どおり自社監視センタ４へ配信するという決定を下し、発報別情報テーブルＦの項目Ｆ６に自社監視センタ４を示すコード番号を書き込む（ステップＳ１２）。そして、次なるステップＳ１３で、この異常情報発報を自社監視センタ４へ配信した後、処理を終了する。
【００３０】
また、ステップＳ１０での判定が「Ｎｏ」の場合、つまり、自社監視センタ４を優先的な配信先とする異常情報発報が緊急対応を要する重要発報（対応優先度がランクＡ）であると判定された場合は、自社監視センタ４の未対応件数に拘らず、監視センタ対応指令部２２Ａは配信先を自社監視センタ４に決定して、発報別情報テーブルＦの項目Ｆ６に自社監視センタ４を示すコード番号を書き込む（ステップＳ１２）。そして、この異常情報発報を自社監視センタ４へ配信（ステップＳ１３）した後、処理を終了する。したがって、この場合、自社監視センタ４の未対応件数が余裕限界件数（１０件）を上回ってしまうこともあるが、前述したようにエレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報を受信したときには迅速な対応が最優先されるため、自社監視センタ４では緊急性の高くない未対応な異常情報発報については後刻対応することとし、ある程度の対応遅れを容認する。
【００３１】
一方、ステップＳ１１で自社監視センタ４の未対応件数が過剰件数に達していると判定された場合は、ステップＳ１８へ進んで、別の自社監視センタ３の未対応件数が過剰件数未満（１０件以内）であるか否かが判定される。そして、ステップＳ１８での判定が「Ｙｅｓ」の場合、自社監視センタ３は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ４を優先的な配信先とする緊急性の高くない異常情報発報を、別の自社監視センタ３へ配信するという配信先変更の決定を下し、発報別情報テーブルＦの項目Ｆ６に自社監視センタ３を示すコード番号を書き込む（ステップＳ８）。そして、次なるステップＳ９で、この異常情報発報を自社監視センタ３へ配信した後、処理を終了する。
【００３２】
しかるに、ステップＳ１８での判定が「Ｎｏ」の場合は、別の自社監視センタ３の未対応件数も過剰件数に達している場合なので、監視センタ対応指令部２２Ａは、まず記憶装置２３の未対応件数管理テーブル２３Ａを参照して、未対応件数が過剰件数未満の他社監視センタ５を探し（ステップＳ１４）、該当する他社監視センタ５を、自社監視センタ４を優先的な配信先とする緊急性の高くない異常情報発報の配信先に決定する。そして、発報別情報テーブルＦの項目Ｆ６に該当する他社監視センタ５を示すコード番号を書き込んで（ステップＳ１５）、この異常情報発報を該当する他社監視センタ５へ配信（ステップＳ１６）した後、処理を終了する。
【００３３】
以上説明したように、本実施形態例に係る遠隔監視システムでは、異常情報発報の配信先を管理する監視サーバ２が、自社監視センタ３，４や他社監視センタ５の未対応件数がそれぞれ過剰件数に達しているか否かを把握している。そして、自社監視センタ３（または４）への異常情報発報が集中しているときに、優先的な配信先が該自社監視センタ３（または４）である異常情報発報を、未対応件数が過剰件数に達していない別の自社監視センタ４（または３）や他社監視センタ５へ配信できるようになっている。したがって、広域災害などで自社監視センタ３（または４）に各種の異常情報発報が集中したときに、異常対応に余裕のある別の自社監視センタ４（または３）や他社監視センタ５が活用できることになってバックアップ態勢が強化され、自社監視センタ３，４での異常対応が円滑に行いやすくなる。
【００３４】
また、本実施形態例に係る遠隔監視システムでは、監視サーバ２が、優先的な配信先が自社監視センタ３（または４）で緊急対応を要すると判定した異常情報発報については、未対応件数に拘らず該自社監視センタ３（または４）へ配信するようにしてある。それゆえ、エレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報に対しては、常に自社監視センタで対応できることになり、致命的な対応遅れが回避しやすくなると共に、他社監視センタ５側の負担が軽減できる。
【００３５】
なお、上記の実施形態例では、自社監視センタを２つ備えた遠隔監視システムについて例示したが、自社監視センタが１つだけ、あるいは３つ以上であっても、本発明を適用できることは言うまでもない。また、余裕限界件数や過剰件数は各監視センタの規模に応じて適宜設定されるので、上記の実施形態例で例示した件数に限定されるものではない。
【符号の説明】
【００３６】
１Ａ，１Ｂ 監視エリア
１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎ 端末装置
２ 監視サーバ
３，４ 自社監視センタ
５ 他社監視センタ
５１〜５ｎ 他社監視卓
６ 通信回線（一般電話回線）
７，８ 通信回線
２１ 回線制御装置
２２ 制御装置
２２Ａ 監視センタ対応指令部
２３ 記憶装置
２３Ａ 未対応件数管理テーブル
２４ 送受信制御装置
Ｆ 発報別情報テーブル
【技術分野】
【０００１】
本発明は、監視対象の設備機器の異常が検出されたときに端末装置から通報される異常情報発報が、自社監視センタだけでなく他社監視センタへも配信可能な遠隔監視システムに関する。
【背景技術】
【０００２】
この種の遠隔監視システムの従来例として、建物内の設備機器が自社監視対象であるか他社監視対象であるかに応じて、各建物内の端末装置から通報された異常情報発報の配信先を監視サーバが決定し、規模の異なる複数の他社監視センタがそれぞれ監視対象の設備機器に関する異常情報発報を確実に取得できるようにしたものが知られている（例えば、特許文献１参照）。かかる従来の遠隔監視システムにおいて、前記監視サーバは、自社監視対象の設備機器に関する異常情報発報を自社監視センタへ配信して、迅速な異常対応が行えるようにしている。また、前記監視サーバは、他社監視対象の設備機器に関する異常情報発報は他社監視センタへ配信するが、他社監視センタが休止中の場合は該異常情報を記憶手段に格納して随時アクセス可能な状態にしておく。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−６５７６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前述した従来の遠隔監視システムは、自社監視対象の設備機器に関する異常情報発報は自社監視センタへ配信し、他社監視対象の設備機器に関する異常情報発報は他社監視センタへ配信するというものであるが、自社監視センタに異常情報発報が集中した際に他社監視センタが活用できる特別なバックアップ態勢が講じられているわけではない。そのため、広域災害などによって自社監視センタに各種の異常情報発報が集中すると、自社監視センタでは異常対応に手間取ってしまい、例えば、エレベータのかご内に乗客が閉じ込められて通報されたにも拘らず迅速に救出できない等の問題が発生し、態勢不備を指摘されかねない。
【０００５】
本発明は、このような従来技術の実情に鑑みてなされたもので、その目的は、異常情報発報の集中時に他社監視センタが活用できるバックアップ態勢を講じて自社監視センタでの異常対応に支障をきたさないようにした遠隔監視システムを提供することにある。
【課題を解決するための手段】
【０００６】
上記の目的を達成するために、本発明は、複数の建物にそれぞれ設置されて監視対象の設備機器の異常が検出されると異常情報を発報する端末装置と、これら複数の端末装置と通信回線を介して接続されて前記異常情報発報の配信先を管理する監視サーバと、前記異常情報発報が配信可能な１つ以上の自社監視センタおよび１つ以上の他社監視センタとを備えた遠隔監視システムにおいて、前記監視サーバが、前記自社監視センタと前記他社監視センタのそれぞれについて、未対応な前記異常情報発報の件数に基づき、該未対応件数が監視センタ毎に定めた過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である前記自社監視センタの未対応件数がその過剰件数に達しているときには、該異常情報発報を未対応件数がその過剰件数に達していない前記他社監視センタへ配信できるようにした。
【０００７】
このように異常情報発報の配信先を管理する監視サーバが、自社監視センタや他社監視センタの未対応件数がそれぞれ過剰件数に達しているか否かを把握していれば、自社監視センタへの異常情報発報が集中しているときに、優先的な配信先が自社監視センタである異常情報発報を、未対応件数が過剰件数に達していない他社監視センタへ配信することによって、異常対応の停滞が回避しやすくなる。すなわち、この遠隔監視システムは、異常対応に余裕のある他社監視センタを活用してバックアップ態勢が強化されているため、広域災害などで自社監視センタに各種の異常情報発報が集中した場合にも、自社監視センタでの異常対応が円滑に行いやすくなる。
【０００８】
上記の遠隔監視システムにおいて、監視サーバが、通報された異常情報発報の内容が緊急対応を要するものであるか否かを判定し、優先的な配信先が自社監視センタで緊急対応を要すると判定された異常情報発報については、未対応件数に拘らず該自社監視センタへ配信するようにしてあれば、緊急対応を要する異常情報（例えばエレベータの閉じ込め事故等）の発報には常に自社監視センタで対応できるため、致命的な対応遅れが回避しやすくなる。なお、この場合も、未対応件数が過剰件数に達している自社監視センタを優先的な配信先とする異常情報発報の内容が、緊急対応を要するものではない（例えば空調設備の故障等）と判定されたときには、これを他社監視センタへ配信して協力してもらうことで自社監視センタでの異常対応が円滑に行いやすくなり、且つ、緊急性の高い異常対応への協力を要請されるわけではないので他社監視センタ側の負担も軽減できる。
【発明の効果】
【０００９】
本発明の遠隔監視システムによれば、自社監視センタや他社監視センタの未対応件数がそれぞれ過剰件数に達しているか否かを、異常情報発報の配信先を管理する監視サーバが把握しており、自社監視センタへの異常情報発報が集中しているときに、優先的な配信先が自社監視センタである異常情報発報を、未対応件数が過剰件数に達していない他社監視センタへ配信できるようになっている。したがって、広域災害などで自社監視センタに各種の異常情報発報が集中したときに、異常対応に余裕のある他社監視センタが活用できることになってバックアップ態勢が強化され、自社監視センタでの異常対応が円滑に行いやすくなる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態例に係る遠隔監視システムの全体構成を示すブロック図である。
【図２】該遠隔監視システムで監視サーバが異常情報発報の配信先を決定する際に行う処理手順を示すフローチャートである。
【図３】該監視サーバによって作成される発報別情報テーブルの一例を示す説明図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態例に係る遠隔監視システムについて図１〜図３を参照しながら説明する。
【００１２】
図１に示すように、本実施形態例に係る遠隔監視システムで用いられる監視サーバ２は、通信回線７を介して自社監視センタ３および自社監視センタ４と接続されていると共に、通信回線８を介して他社監視センタ５と接続されている。これら各監視センタ３〜５は、後述する端末装置を介して監視対象の設備機器を遠隔的に監視している。また、監視サーバ２は一般電話回線６を介して、監視エリアＡに存する図示せぬ複数の建物にそれぞれ設置された端末装置１Ａｎ（ただしｎは不特定な自然数。以下同）や、監視エリアＢに存する図示せぬ複数の建物にそれぞれ設置された端末装置１Ｂｎと接続されている。端末装置群１Ａ１〜１Ａｎに含まれる多くの端末装置は、自社監視対象の設備機器の動作状態を自社監視センタ３へ自動発報するためのものである。同様に、端末装置群１Ｂ１〜１Ｂｎに含まれる多くの端末装置は、自社監視対象の設備機器の動作状態を自社監視センタ４へ自動発報するためのものである。ただし、端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎのうちの一部は、他社監視対象の設備機器の動作状態を他社監視センタ５へ自動発報するための端末装置である。
【００１３】
なお、監視対象の設備機器とはエレベータや空調設備、電気設備、防犯装置、防災装置などであり、前記端末装置は監視対象の設備機器と電気的に接続されているため、電気信号の変化に基づき設備機器の異常や復旧状態等を端末装置が検知できるようになっている。
【００１４】
端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎに含まれる個々の端末装置は、監視対象の設備機器の異常が検出されると異常情報を発報し、この異常情報発報は一般電話回線６を介して監視サーバ２へ通報される。監視サーバ２では、受信した異常情報発報を所定の配信先へ送信する。すなわち、配信先が自社監視センタ３や自社監視センタ４の場合は、監視サーバ２から通信回線７を介して異常情報発報が送信され、配信先が他社監視センタ５の場合は、監視サーバ２から通信回線８を介して異常情報発報が送信される。これにより、自社監視センタ３，４や他社監視センタ５では、受信した異常情報発報の内容に応じた迅速な対応が可能となる。なお、本実施形態例では、他社監視センタ５での送受信が監視サーバ２に接続可能な通信機能を有する汎用パソコンによって行われるため、通信回線８としてインターネット回線を利用している。
【００１５】
自社監視センタ３には複数の監視卓３１〜３ｎが設けられており、自社監視センタ４には複数の監視卓４１〜４ｎが設けられている。端末装置群１Ａ１〜１Ａｎのうち自社監視対象の設備機器と接続されている自社端末装置から発報された異常情報は、通常は自社監視センタ３へ配信されて対応する監視卓（例えば監視卓３１）に表示される。同様に、端末装置群１Ｂ１〜１Ｂｎのうち自社監視対象の設備機器と接続されている自社端末装置から発報された異常情報は、通常は自社監視センタ４へ配信されて対応する監視卓（例えば監視卓４１）に表示される。また、端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎのうち他社監視対象の設備機器と接続されている他社端末装置から発報された異常情報は、それぞれが他社監視センタ５として機能する他社監視卓５１〜５ｎに表示される。
【００１６】
監視サーバ２には、端末装置群１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎとの接続を制御する回線制御装置２１と、受信データや送信データを管理するための演算処理等を行う制御装置２２と、制御装置２２の指定したデータを記憶する記憶装置２３と、自社監視センタ３，４や他社監視センタ５との送受信を制御する送受信制御装置２４とが備えられており、記憶装置２３には未対応件数管理テーブル２３Ａが設けられている。この未対応件数管理テーブル２３Ａには、監視センタ３〜５別に、対応すべき異常情報発報のうち未対応な発報の件数（未対応件数）と、この未対応件数が過剰ではないと判断しうる上限の件数（余裕限界件数）とが記憶されており、未対応件数が余裕限界件数よりも１件多い過剰件数に達すると、その監視センタは異常対応に手間取る可能性が高まる。
【００１７】
また、制御装置２２には、端末装置からの異常情報発報の配信先を決定するための監視センタ対応指令部２２Ａが設けられている。この監視センタ対応指令部２２Ａは、通常時には、受信した異常情報発報をその優先的な配信先へと配信するが、前記未対応件数が前記過剰件数に達している自社監視センタ３や自社監視センタ４を配信先とする異常情報発報を受信し、その異常情報の内容が緊急対応を要するものでないと確認できたときには、配信先の変更を行うように指令する。その際、新たな配信先に選定する監視センタは異常対応に余裕のあることが前提となるため、例えば、優先的な配信先が自社監視センタ３である異常情報発報の新たな配信先として、自社監視センタ４が不適な場合は、未対応件数が過剰件数に達していない他社監視センタ５が選定されるようになっている。
【００１８】
次に、監視サーバ２が端末装置からの異常情報発報の配信先を決定する際に行う処理手順を、図２のフローチャートを参照しながら説明する。
【００１９】
端末装置からの異常情報発報を回線制御装置２１が受信する（ステップＳ１）と、制御装置２２は、この異常情報発報のデータを図３に示す発報別情報テーブルＦに書き込む（ステップＳ２）。この発報別情報テーブルＦには、受信連番の項目Ｆ１と、ビル名の項目Ｆ２と、異常発生時刻の項目Ｆ３と、監視設備名の項目Ｆ４と、異常状態の項目Ｆ５と、対応先コードの項目Ｆ６とが用意されており、ステップＳ２では項目Ｆ６を除く各項目（Ｆ１〜Ｆ５）に異常情報発報のデータを書き込む。
【００２０】
ここで、発報別情報テーブルＦの各項目の内容について説明すると、項目Ｆ１の受信連番は、異常情報発報を受信する度に新規に採番されるコード番号（例えば９桁の通し番号）である。項目Ｆ２のビル名は、異常情報を発報した端末装置が設置されているビルの名称である。項目Ｆ３の異常発生時刻は、異常情報発報を受信した時刻である。項目Ｆ４の監視設備名は、異常が発生した監視対象の設備機器の名称である。項目Ｆ５の異常状態は、その設備機器の異常状態の内容ならびに対応優先度の重要度ランクであり、異常状態の内容が緊急対応を要する場合は、対応優先度がランクＡに指定される。項目Ｆ６の対応先コードは、異常情報発報の配信先として監視センタ対応指令部２２Ａが最終的に決定した監視センタ名を示すコード番号である。
【００２１】
図２のフローチャートへ戻り、ステップＳ２の後、制御装置２２の監視センタ対応指令部２２Ａは、記憶装置２３に記憶されているデータを参照して、受信した異常情報発報の優先的な配信先（通常時の対応先）がどの監視センタであるのかを確認する（ステップＳ３）。すなわち、異常情報を発報する端末装置毎に、その異常情報発報の優先的な配信先がどの監視センタであるのかは、予め端末別対応先データとして記憶装置２３に記憶されている。例えば、監視エリア１Ａ内の端末装置群１Ａ１〜１Ａｎの多くは優先的な配信先が自社監視センタ３であり、監視エリア１Ｂ内の端末装置群１Ｂ１〜１Ｂｎの多くは優先的な配信先が自社監視センタ４である。
【００２２】
ステップＳ３の後、制御装置２２の監視センタ対応指令部２２Ａは、受信した異常情報発報の優先的な配信先が自社監視センタ３または自社監視センタ４であるか否かを判定し（ステップＳ４）、判定が「Ｙｅｓ」の場合はステップＳ５へ進む。ただし、受信した異常情報発報の優先的な配信先が他社監視センタ５の場合は、ステップＳ４での判定が「Ｎｏ」となるため、ステップＳ１４へ進んで対応可能な他社監視センタ５を探し、該当する他社監視センタ５（例えば他社監視卓５１）を示すコード番号（例えば０５１）を発報別情報テーブルＦの対応先コードの項目Ｆ６に書き込んだ（ステップＳ１５）後、この異常情報発報を該当する他社監視センタ５へ配信（ステップＳ１６）して処理を終了する。
【００２３】
ステップＳ４での判定が「Ｙｅｓ」の場合は、ステップＳ５において、受信した異常情報が監視エリア１Ａ内の自社端末装置から発報されたものであるか否かを判定する。そして、ステップＳ５での判定が「Ｙｅｓ」の場合は、次なるステップＳ６で、その異常情報発報の内容の緊急性を判定し、緊急対応を要する重要発報ではないと確認された場合はステップＳ７へ進む。すなわち、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報を受信した場合、ステップＳ６での判定が「Ｙｅｓ」となり、次なるステップＳ７において、自社監視センタ３の未対応件数が過剰件数未満であるか否かが判定される。前述したように、監視センタでは未対応件数が余裕限界件数を上回る（つまり過剰件数に達する）と、異常対応に手間取る可能性が高まる。また、この余裕限界件数は監視センタの規模に応じて予め設定されており、本実施形態例では、自社監視センタ３，４の余裕限界件数をいずれも１０件とし、他社監視センタ５の余裕限界件数を例えば５件としている。
【００２４】
ステップＳ７で自社監視センタ３の未対応件数が過剰件数未満（１０件以内）であると判定された場合、自社監視センタ３は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報を、通常どおり自社監視センタ３へ配信するという決定を下し、発報別情報テーブルＦの対応先コードの項目Ｆ６に自社監視センタ３を示すコード番号（例えば００３）を書き込む（ステップＳ８）。そして、次なるステップＳ９で、この異常情報発報を送受信制御装置２４を介して自社監視センタ３へ配信した後、処理を終了する。
【００２５】
また、ステップＳ６での判定が「Ｎｏ」の場合、つまり、自社監視センタ３を優先的な配信先とする異常情報発報が緊急対応を要する重要発報（対応優先度がランクＡ）であると判定された場合は、自社監視センタ３の未対応件数に拘らず、監視センタ対応指令部２２Ａは配信先を自社監視センタ３に決定して、発報別情報テーブルＦの項目Ｆ６に自社監視センタ３を示すコード番号を書き込む（ステップＳ８）。そして、この異常情報発報を自社監視センタ３へ配信（ステップＳ９）した後、処理を終了する。したがって、この場合、自社監視センタ３の未対応件数が余裕限界件数（１０件）を上回ってしまうこともある。ただし、仮に未対応件数が過剰件数に達したとしても、エレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報を受信したときには、迅速な対応が最優先されるため、自社監視センタ３では緊急性の高くない未対応な異常情報発報については後刻対応することとし、ある程度の対応遅れを容認する。
【００２６】
一方、ステップＳ７で自社監視センタ３の未対応件数が過剰件数に達していると判定された場合はステップＳ１７へ進んで、別の自社監視センタ４の未対応件数が過剰件数未満（１０件以内）であるか否かが判定される。そして、ステップＳ１７での判定が「Ｙｅｓ」の場合、自社監視センタ４は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報を、別の自社監視センタ４へ配信するという配信先変更の決定を下し、発報別情報テーブルＦの対応先コードの項目Ｆ６に自社監視センタ４を示すコード番号（例えば００４）を書き込む（ステップＳ１２）。そして、次なるステップＳ１３で、この異常情報発報を送受信制御装置２４を介して自社監視センタ４へ配信した後、処理を終了する。
【００２７】
しかるに、ステップＳ１７での判定が「Ｎｏ」の場合は、別の自社監視センタ４の未対応件数も過剰件数に達している場合なので、監視センタ対応指令部２２Ａは、まず記憶装置２３の未対応件数管理テーブル２３Ａを参照して、未対応件数が過剰件数未満（例えば５件以内）の他社監視センタ５を探し（ステップＳ１４）、該当する他社監視センタ５（例えば他社監視卓５１）を、自社監視センタ３を優先的な配信先とする緊急性の高くない異常情報発報の配信先に決定する。つまり、監視センタ対応指令部２２Ａは、この異常情報発報をいずれかの他社監視センタ５へ配信するという配信先変更の決定を下し、発報別情報テーブルＦの対応先コードの項目Ｆ６に該当する他社監視センタ５を示すコード番号（例えば０５１）を書き込む（ステップＳ１５）。そして、次なるステップＳ１６で、この異常情報発報を送受信制御装置２４を介して該当する他社監視センタ５へ配信した後、処理を終了する。
【００２８】
一方、前記ステップＳ５での判定が「Ｎｏ」の場合、つまり、受信した異常情報発報が監視エリア１Ａ内の自社端末装置から発報されたものではないと判定された場合は、監視エリア１Ｂ内の自社端末装置から発報された異常情報発報であり、その優先的な配信先は自社監視センタ４であることがわかる。それゆえ、まずステップＳ１０へ進んで、受信した異常情報発報の内容の緊急性を判定する。このステップＳ１０において、緊急対応を要する重要発報ではないと確認された場合はステップＳ１１へ進んで、自社監視センタ４の未対応件数が過剰件数未満（１０件以内）であるか否かが判定される。
【００２９】
ステップＳ１１で自社監視センタ４の未対応件数が過剰件数未満であると判定された場合、自社監視センタ４は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ４を優先的な配信先とする緊急性の高くない異常情報発報を、通常どおり自社監視センタ４へ配信するという決定を下し、発報別情報テーブルＦの項目Ｆ６に自社監視センタ４を示すコード番号を書き込む（ステップＳ１２）。そして、次なるステップＳ１３で、この異常情報発報を自社監視センタ４へ配信した後、処理を終了する。
【００３０】
また、ステップＳ１０での判定が「Ｎｏ」の場合、つまり、自社監視センタ４を優先的な配信先とする異常情報発報が緊急対応を要する重要発報（対応優先度がランクＡ）であると判定された場合は、自社監視センタ４の未対応件数に拘らず、監視センタ対応指令部２２Ａは配信先を自社監視センタ４に決定して、発報別情報テーブルＦの項目Ｆ６に自社監視センタ４を示すコード番号を書き込む（ステップＳ１２）。そして、この異常情報発報を自社監視センタ４へ配信（ステップＳ１３）した後、処理を終了する。したがって、この場合、自社監視センタ４の未対応件数が余裕限界件数（１０件）を上回ってしまうこともあるが、前述したようにエレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報を受信したときには迅速な対応が最優先されるため、自社監視センタ４では緊急性の高くない未対応な異常情報発報については後刻対応することとし、ある程度の対応遅れを容認する。
【００３１】
一方、ステップＳ１１で自社監視センタ４の未対応件数が過剰件数に達していると判定された場合は、ステップＳ１８へ進んで、別の自社監視センタ３の未対応件数が過剰件数未満（１０件以内）であるか否かが判定される。そして、ステップＳ１８での判定が「Ｙｅｓ」の場合、自社監視センタ３は異常対応に余裕があると判断できるため、監視センタ対応指令部２２Ａは、自社監視センタ４を優先的な配信先とする緊急性の高くない異常情報発報を、別の自社監視センタ３へ配信するという配信先変更の決定を下し、発報別情報テーブルＦの項目Ｆ６に自社監視センタ３を示すコード番号を書き込む（ステップＳ８）。そして、次なるステップＳ９で、この異常情報発報を自社監視センタ３へ配信した後、処理を終了する。
【００３２】
しかるに、ステップＳ１８での判定が「Ｎｏ」の場合は、別の自社監視センタ３の未対応件数も過剰件数に達している場合なので、監視センタ対応指令部２２Ａは、まず記憶装置２３の未対応件数管理テーブル２３Ａを参照して、未対応件数が過剰件数未満の他社監視センタ５を探し（ステップＳ１４）、該当する他社監視センタ５を、自社監視センタ４を優先的な配信先とする緊急性の高くない異常情報発報の配信先に決定する。そして、発報別情報テーブルＦの項目Ｆ６に該当する他社監視センタ５を示すコード番号を書き込んで（ステップＳ１５）、この異常情報発報を該当する他社監視センタ５へ配信（ステップＳ１６）した後、処理を終了する。
【００３３】
以上説明したように、本実施形態例に係る遠隔監視システムでは、異常情報発報の配信先を管理する監視サーバ２が、自社監視センタ３，４や他社監視センタ５の未対応件数がそれぞれ過剰件数に達しているか否かを把握している。そして、自社監視センタ３（または４）への異常情報発報が集中しているときに、優先的な配信先が該自社監視センタ３（または４）である異常情報発報を、未対応件数が過剰件数に達していない別の自社監視センタ４（または３）や他社監視センタ５へ配信できるようになっている。したがって、広域災害などで自社監視センタ３（または４）に各種の異常情報発報が集中したときに、異常対応に余裕のある別の自社監視センタ４（または３）や他社監視センタ５が活用できることになってバックアップ態勢が強化され、自社監視センタ３，４での異常対応が円滑に行いやすくなる。
【００３４】
また、本実施形態例に係る遠隔監視システムでは、監視サーバ２が、優先的な配信先が自社監視センタ３（または４）で緊急対応を要すると判定した異常情報発報については、未対応件数に拘らず該自社監視センタ３（または４）へ配信するようにしてある。それゆえ、エレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報に対しては、常に自社監視センタで対応できることになり、致命的な対応遅れが回避しやすくなると共に、他社監視センタ５側の負担が軽減できる。
【００３５】
なお、上記の実施形態例では、自社監視センタを２つ備えた遠隔監視システムについて例示したが、自社監視センタが１つだけ、あるいは３つ以上であっても、本発明を適用できることは言うまでもない。また、余裕限界件数や過剰件数は各監視センタの規模に応じて適宜設定されるので、上記の実施形態例で例示した件数に限定されるものではない。
【符号の説明】
【００３６】
１Ａ，１Ｂ 監視エリア
１Ａ１〜１Ａｎ，１Ｂ１〜１Ｂｎ 端末装置
２ 監視サーバ
３，４ 自社監視センタ
５ 他社監視センタ
５１〜５ｎ 他社監視卓
６ 通信回線（一般電話回線）
７，８ 通信回線
２１ 回線制御装置
２２ 制御装置
２２Ａ 監視センタ対応指令部
２３ 記憶装置
２３Ａ 未対応件数管理テーブル
２４ 送受信制御装置
Ｆ 発報別情報テーブル
【特許請求の範囲】
【請求項１】
複数の建物にそれぞれ設置されて監視対象の設備機器の異常が検出されると異常情報を発報する端末装置と、これら複数の端末装置と通信回線を介して接続されて前記異常情報発報の配信先を管理する監視サーバと、前記異常情報発報が配信可能な１つ以上の自社監視センタおよび１つ以上の他社監視センタとを備えた遠隔監視システムにおいて、
前記監視サーバが、前記自社監視センタと前記他社監視センタのそれぞれについて、未対応な前記異常情報発報の件数に基づき、該未対応件数が監視センタ毎に定めた過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である前記自社監視センタの未対応件数がその過剰件数に達しているときには、該異常情報発報を未対応件数がその過剰件数に達していない前記他社監視センタへ配信できるようにしたことを特徴とする遠隔監視システム。
【請求項２】
請求項１の記載において、前記監視サーバが、通報された前記異常情報発報の内容が緊急対応を要するものであるか否かを判定し、優先的な配信先が前記自社監視センタで緊急対応を要すると判定された前記異常情報発報については、未対応件数に拘らず該自社監視センタへ配信するようにしたことを特徴とする遠隔監視システム。
【請求項１】
複数の建物にそれぞれ設置されて監視対象の設備機器の異常が検出されると異常情報を発報する端末装置と、これら複数の端末装置と通信回線を介して接続されて前記異常情報発報の配信先を管理する監視サーバと、前記異常情報発報が配信可能な１つ以上の自社監視センタおよび１つ以上の他社監視センタとを備えた遠隔監視システムにおいて、
前記監視サーバが、前記自社監視センタと前記他社監視センタのそれぞれについて、未対応な前記異常情報発報の件数に基づき、該未対応件数が監視センタ毎に定めた過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である前記自社監視センタの未対応件数がその過剰件数に達しているときには、該異常情報発報を未対応件数がその過剰件数に達していない前記他社監視センタへ配信できるようにしたことを特徴とする遠隔監視システム。
【請求項２】
請求項１の記載において、前記監視サーバが、通報された前記異常情報発報の内容が緊急対応を要するものであるか否かを判定し、優先的な配信先が前記自社監視センタで緊急対応を要すると判定された前記異常情報発報については、未対応件数に拘らず該自社監視センタへ配信するようにしたことを特徴とする遠隔監視システム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１３−３７４７９（Ｐ２０１３−３７４７９Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１１−１７２０２９（Ｐ２０１１−１７２０２９）
【出願日】平成２３年８月５日（２０１１．８．５）
【出願人】（０００２３２９５５）株式会社日立ビルシステム (895)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２３年８月５日（２０１１．８．５）
【出願人】（０００２３２９５５）株式会社日立ビルシステム (895)
【Ｆターム（参考）】
[ Back to top ]