JP4521448B2 - 遠隔監視・診断システム - Google Patents

Description

本発明は、特に、ネットワークを介して中央システムから送信する移動プログラムを利用して、遠隔地の監視・診断対象に対する監視・診断処理を行なう遠隔監視・診断システムに関する。

近年、プラント機器やエレベータなどの監視・診断対象に対して、遠隔地から監視・診断処理を行なう遠隔監視・診断システムが開発されている。このようなシステムは、具体的には、例えば電力系統の遠隔運用や遠隔保守を行なうための電力系統保護制御システムに適用されている（例えば、非特許文献１〜３を参照）。

また、遠隔からのプラントの監視と診断を目的とするプラント監視・診断システムが提案されている（例えば、特許文献１を参照）。このシステムは、プラント制御プログラムとプラント監視・診断プログラムとを連携して、監視・診断処理及びプラント制御処理を行うことができる。さらに、複数の発電プラントを遠隔から監視・診断・検査・保全するシステムも提案されている（例えば、特許文献２を参照）。このシステムは、電力系統などのプラントを対象としており、イントラネットを利用する構成である。

要するに、遠隔監視・診断システムとしては、監視・診断対象毎に専用に開発されたシステム、数万点レベルの監視・診断対象が存在するシステム、様々な処理能力を有する監視・診断対象が存在するシステム、あるいは公衆回線によるインターネットを利用するシステムなどが開発又は提案されている。特に、近年では、移動エージェント技術を利用した遠隔監視・診断システムが注目されている（例えば、特許文献４〜７を参照）。

ところで、遠隔監視・診断システムでは、遠隔地の監視・診断対象と、中央システム（中央監視システム）とがネットワークを介して接続されている場合が多く、災害発生時にネットワーク接続が遮断された場合などにおいて、災害時の対策が重要である。先行技術としては、データのバックアップやサーバのバックアップ、リカバリなどに関する提案はある（例えば、特許文献３を参照）。
特許第３６２１９３５号公報 特開２００３−１１４２９４号公報 特開２００２−１７１５０６号公報 特開２００６−２８０１９８号公報 特開２００４−７０４２８号公報 特開２００２−２９７５５７号公報 特開２０００−１３４７８６号公報 「変革を遂げる電力系統監視制御・保護システム」津久井良一、増田文雄、鈴木邦明著、東芝レビュー、Vol54、No.6、26〜29ページ、1999 「イントラネット応用電力系統監視制御システム」長谷川義朗、江幡良雄、林秀樹著、東芝レビュー、Vol54、No.6、30〜33ページ、1999 「電力系統保護制御システムへのイントラネット技術適用」関口勝彦、竹中章二、白田義博著、東芝レビュー、Vol54、No.6、34〜37ページ、1999

前述のように、遠隔監視・診断システムでは、災害発生時に、遠隔地とのネットワーク接続の遮断などに対する災害対策が重要である。しかしながら、有効な災害対策を実現できる先行技術は無く、保守員がそれぞれの監視・診断対象の状況を直接調査し、これらの調査結果を利用する災害対策方法があるだけである。

しかしながら、災害時において、ネットワーク回線の断線などに関する監視・診断対象の状況を調査するために、監視・診断処理に必要な保守情報を収集する作業の負荷は莫大である。従って、監視・診断対象の状況を直接調査する方法は、実際上の災害対策としては必ずしも有効ではない。

そこで、本発明の目的は、災害発生時に、監視・診断対象の監視・診断処理に必要な保守情報を効率的に収集できるようにして、有効な災害対策を実現できる遠隔監視・診断システムを提供することにある。

本発明の観点は、中央システムから送信される移動プログラムにより監視・診断処理を実行する複数のローカル端末において、災害発生時に、中央システムと接続するためのネットワークが切断されたときに、代表ローカル端末により、監視・診断処理に必要な保守情報を収集する機能を備えた遠隔監視・診断システムである。

本発明の観点に従った遠隔監視・診断システムは、ネットワークを介して中央システムと接続されて、指定のエリアに存在する監視・診断対象に対する監視・診断処理を行なう複数のローカル端末を有する遠隔監視・診断システムにおいて、前記中央システムから、前記監視・診断処理を実行するための監視・診断用プログラムまたは災害時処理プログラムを前記各ローカル端末に移動させるプログラム移動手段と、前記ネットワークを介した中央システムとの接続が遮断されたときに、前記指定エリアに含まれる各ローカル端末から代表ローカル端末を設定する設定手段と、前記代表ローカル端末により、前記指定エリアに存在する他のローカル端末から災害時保守情報を収集する情報収集手段とを備えた構成である。

本発明によれば、災害発生時に、監視・診断対象の監視・診断処理に必要な保守情報を効率的に収集できるようにして、有効な災害対策を実現できる遠隔監視・診断システムを提供することができる。

以下図面を参照して、本発明の実施形態を説明する。

［第１の実施形態］
図１は、本実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図である。図２は、本実施形態に関するシステムの動作を説明するための概念図である。

（システムの構成）
遠隔監視・診断システムは大別して、図１に示すように、中央システム（中央監視システム）１０と、この中央システム１０とネットワーク９を介して接続されるローカル端末１１とから構成される。ローカル端末１１は、中央システム１０から遠隔地に設置されている監視・診断対象機器１００に対する監視・診断処理を実行する。通常では、１台の中央システム１０に対して、複数のローカル端末１１がネットワーク９を介して接続されている（図２を参照）。

ここで、監視・診断対象機器１００は、例えばビル内のエレベータである。ローカル端末１１は、例えばビル内に設置されている複数のエレベータ毎に配置されて、エレベータの動作の監視・診断処理を実行する。

中央システム１０は、エリア分割構成作成部１と、代表監視・診断対象側ローカル端末候補決定部（以下、代表ローカル端末候補決定部と略す）２と、ローカル端末用プログラム作成部３と、ローカル端末用プログラム検証・評価部４と、プログラム送信部５と、監視・診断結果データ処理部（以下、データ処理部と略す）６と、監視診断結果受信部（以下、受信部と略す）７と、監視・診断結果表示部（以下、表示部と略す）８とを備えた構成である。

ローカル端末１１は、ローカル端末用プログラム受信部１２と、監視・診断プログラム実行部１３と、監視・診断結果送信部１４と、自動災害検知部１５と、災害時処理開始指令受信部１６と、災害時処理プログラム実行部１８とを有する。

災害時処理プログラム実行部１８は、代表ローカル端末処理実施判定部１７と、災害時代表ローカル端末処理部１９と、災害時通常ローカル端末処理部２４と、災害時保守情報表示部２６と、災害時保守情報保存部２７とを有する。

さらに、災害時代表ローカル端末処理部１９は、災害時保守情報送信依頼部２０と、災害時保守情報受信部２１と、災害時保守情報管理部２２と、災害時保守情報データベース（ＤＢ）２３とを含む。また、災害時通常ローカル端末処理部２４は、災害時保守情報送信部２５を含む。

（システムの作用）
以下、図２から図６を参照して、本実施形態に関するシステムの作用を説明する。

ここで、本実施形態のシステムは、図２に示すように、ネットワーク９を介して、中央システム１０と、後述するように、複数のエリア（ローカルネットワークエリア）１〜３に分割されて管理される指定のエリアに配置された複数のローカル端末１１とが接続された状況を想定する。ここで、各エリア１〜３はそれぞれ、例えば１つビル内を分割した各エリアに対応する。また、監視・診断対象機器１００としては、例えばビル内に設置された複数のエレベータに相当する。なお、各ローカル端末１１は、監視・診断対象機器１００の外側に配置される端末、あるいは監視・診断対象機器１００の内部に組み込まれた端末である。

本実施形態のシステムは大別して、各エリア１〜３に対する遠隔監視・診断機能に関する部分と、災害時対応機能に関する部分に分けられる。遠隔監視・診断機能は、中央システム１０において、ローカル端末用プログラム作成部３、ローカル端末用プログラム検証・評価部４、プログラム送信部５、データ処理部６、受信部７、及び表示部８の動作により実現される。また、ローカル端末１１では、ローカル端末用プログラム受信部１２、監視・診断プログラム実行部１３、及び監視・診断結果送信部１４が関係する。

ローカル端末用プログラム作成部３は、ローカル端末１１にて使用されるローカル端末用プログラムを作成する。本実施形態では、ローカル端末用プログラムには、監視・診断用プログラムと災害時処理プログラムが含まれる。ローカル端末用プログラム作成部３は、監視・診断アルゴリズムを実行する監視・診断用プログラムを、移動可能なマルチエージェントなどを使用する移動プログラムとして作成する。なお、災害時処理プログラムに含まれる災害時保守情報収集用移動プログラム等については、後述する。

ここで、通常のプログラムソースコードをコンパイルして実行可能形式にしたものやスクリプト的なコードの場合は、ローカル端末１１で実行可能な形態で、監視・診断処理を行うプログラムを作成すればよい。最も簡単な監視・診断プログラムとしては、例えば“異常を判断する閾値を設定し、これの閾値を超えた場合を異常状態と判断し、異常発報する”などのアルゴリズムが考えられる。

監視・診断プログラムは、中央システム１０において、ローカル端末用プログラム作成部３により移動プログラムとして作成されて、プログラム送信部５からネットワーク９を介して各ローカル端末１１（各エリア１〜３に配置されたローカル端末群）に配信される。なお、移動プログラムとは、エージェントを含む広い概念で、ネットワークを移動できるプログラムを意味する。通常では、エージェントは移動だけでなく、エージェント間の通信などの機能を含む高機能の移動プログラムを意味する場合が多い。

中央システム１０では、ローカル端末用プログラム作成部３により作成されたプログラムは、ローカル端末用プログラム検証・評価部４により検証・評価される。ローカル端末用プログラム検証・評価部４は、作成部３により作成されたプログラムのソースコードやコンパイル後のプログラム、またはスクリプト的なコードを用いて、ソフトウェアシミュレーションにより動作検証・評価を行う。

ソフトウェアシミュレーションでは、監視・診断対象の挙動を模擬する監視対象挙動模擬プログラムが利用される。この監視・診断対象のソフトウェアシミュレーション結果に基づいて、監視・診断プログラムで監視・診断処理を実行させて、その結果を表示させる。この表示結果を用いて、作成した監視・診断プログラムの動作が、意図したものであるかを確認・評価することができる。なお、作成したプログラムが意図したものと異なる場合には、ローカル端末用プログラム作成部３において、プログラムの修正が行なわれる。

ローカル端末用プログラム作成部３により作成されて、検証・評価部４の検証・評価で問題ないと判断されたプログラム（移動プログラム）は、プログラム送信部５から、ネットワーク９を介して、各ローカル端末１１に配信される。ローカル端末１１では、ローカル端末用プログラム受信部１２は、中央システム１０から配信された移動プログラムを受信すると、監視・診断プログラムを監視・診断プログラム実行部１３に転送し、災害時処理プログラムを災害時処理プログラム実行部１８に転送する。

ここで、ネットワーク９は、イントラネットやインターネット等である。各エリア１〜３が、例えば比較的狭域（例えばビルの１フロアのみ等）の場合には、ネットワーク９は、電力線搬送によるネットワークでもよい。ここで、ネットワーク９には、インターネット等のように、セキュリティを考慮する必要があるネットワークがある。このようなネットワークを使用して、中央システム１０から移動プログラムを送信する場合には、プログラム送信部５及びローカル端末用プログラム受信部１２において、プログラムデータの暗号化、認証、復号化などのセキュリティ処理が実行される。

ローカル端末１１では、監視・診断プログラム実行部１３は、監視・診断プログラムを実行することにより、監視・診断対象機器１００から取得される情報を用いて監視・診断処理を行う。具体的には、ローカル端末１１は、監視・診断対象機器１００の内部メモリやポートを参照することにより、計測値や電流指令値等の監視・診断処理に必要な情報を入手する。

監視・診断結果送信部１４は、監視・診断プログラム実行部１３による監視・診断処理により得られる監視・診断結果を、ネットワーク９を介して中央システム１０に送信する。中央システム１０では、受信部７がネットワーク９を介して送信された監視・診断結果を受信する。ここで、ネットワーク９がインターネット等のようなセキュリティを考慮する必要がある場合には、監視・診断結果送信部１４及び受信部７において、監視・診断結果データの暗号化、認証、復号化などのセキュリティ処理が実行される。

なお、プログラム送信部５からはプログラムを送信する場合を説明したが、プログラム自体の変更がなく、パラメータのみの変更でよい場合には、プログラム送信部５からはパラメータのみを送信する動作でもよい。即ち、監視・診断プログラムの構成がパラメータのみの変更の反映が可能な場合（パラメータを別ファイルとしてある等）は、パラメータのみを送付して、パラメータのみの変更を反映することで監視・診断する形態も構成可能である。

中央システム１０では、受信部７は、受信した監視・診断対象機器１００の監視・診断結果が暗号化されている場合には、復号化してデータ処理部６及び表示部８に転送する。データ処理部６は、監視・診断対象機器１００の監視・診断結果に対して、所定の加工処理を実行する。具体的には、例えば、複数の監視・診断対象機器の各監視・診断結果を統合する処理である。データ処理部６は、処理結果を表示部８に伝送する。表示部８は、データ処理部６からの処理結果、及び受信部７で受信した監視・診断結果を、例えば液晶表示画面上に表示する。

（災害時対応機能に関する作用）
次に、主として図３及び図４のフローチャートを参照して、本実施形態のシステムでの災害時対応機能に関する作用を説明する。

災害時対応機能とは、図２に示すように、災害発生時に、中央システム１０に接続されているネットワーク９の一部２００が断線（有線での断線又は無線接続機器の故障・破壊等）した場合に、監視・診断対象機器１００の監視・診断処理に必要な災害時保守情報を各ローカル端末１１から収集するための機能である。

具体的には、監視・診断対象機器１００が設置されているエリア（例えば１つのビル）を、ある範囲の複数の管理エリア１〜３に分割し、分割されたそれぞれのエリア１〜３内に代表となるローカル端末（以下、代表ローカル端末）を決定する。代表ローカル端末は、当該エリア内の全ローカル端末から災害時保守情報を収集する。これにより、災害発生時に、災害時保守情報を収集すべき保守員は、エリア内の全ローカル端末を移動して災害時情報収集をすることなく、代表ローカル端末から集中的に該当エリア内の全ローカル端末の災害時保守情報を収集することが可能となる。

災害発生時に、中央システム１０では、エリア分割構成作成部１及び代表ローカル端末候補決定部２は、ローカル端末１１で実行する災害時処理プログラムを作成する際に利用する情報を作成する。エリア分割構成作成部１は、中央システム１０とローカル端末１１とを接続するネットワーク９が断線した場合に、ローカル側を複数のエリア１〜３に分割し、災害時の保守情報収集の管理を行うことを想定とした場合の管理エリアの分割構成を作成する。

エリア分割の方法としては、例えば、監視・診断対象機器１００の設置範囲が、領域面積的（距離的）に同等の領域となるように決定する。分割するエリア数としては、各保守拠点がそれぞれのエリアの状況を把握することを想定すると、保守拠点数に対応するエリア数が望ましい。なお、図２では、便宜的に保守拠点Ａ，Ｂのみを示すが、拠点数としては３の場合を想定している。

また、保守拠点の配置から領域面積的に同等とすることが難しい場合は、各保守拠点間の距離が同等となる様に、エリアを分割する方法もある。また、活断層近辺では、大規模な地震が発生した場合に、地表のずれが発生する可能性が高く、その際にネットワーク９が断線する可能性が高いと考えられる。よって、活断層情報を考慮（例えば活断層がエリアを縦断しない用にする等）したエリア分割方法もある。この方法であれば、エリア内の断線の可能性を低くしたエリア分割が可能である。このようにして、エリア分割構成作成部１は、複数のエリア１〜３に分割するための分割構成を作成する。

次に、代表ローカル端末候補決定部２は、エリア分割構成作成部１で作成された各エリア１〜３において、それぞれのエリアを代表する代表ローカル端末の候補を決定する。代表ローカル端末候補の決定方法としては、例えばエリアに最も近接している保守拠点からの早退距離または移動する際の距離が短い順に有力候補とする。

ローカル端末用プログラム作成部３は、エリア分割構成作成部１で作成されたエリア分割構成、及び代表ローカル端末候補決定部２により決定された代表ローカル端末候補順のそれぞれに関する情報を参照し、ローカル端末側で災害時に動作する災害時処理プログラムを作成する。

ここで、エリア分割構成に関する情報としては、各エリア１〜３を識別可能なＩＤ情報（識別情報）に対して、エリア内に含まれるローカル端末１１のＩＤを対応させた情報である。また、代表ローカル端末候補順に関する情報としては、各エリア１〜３を識別可能なＩＤ情報に対して、エリア内に含まれるローカル端末１１のＩＤ情報及びその代表ローカル端末候補順を対応させた情報である。ローカル端末用プログラム作成部３は、各情報をプログラムの内部あるいは設定ファイルとして保持する。

以上のようにして作成された災害時処理プログラムは、前述の監視・診断プログラムと同様に、ローカル端末用プログラム検証・評価部４により検証・評価される。この検証・評価部４の検証・評価で問題ないと判断された災害時処理プログラム（移動プログラム）は、プログラム送信部５から、ネットワーク９を介して、各ローカル端末１１に配信される。ローカル端末１１では、ローカル端末用プログラム受信部１２は、中央システム１０から配信された移動プログラムを受信すると、災害時処理プログラムを災害時処理プログラム実行部１８に転送する。

災害時処理プログラム実行部１８は災害時の発生まで待機し、自動災害検知部１５の検知結果、あるいは災害時処理開始指令受信部１６からの開始指令を受けた場合に、災害時と判断し、災害時処理プログラムを実行する。自動災害検知部１５は、例えば地震センサからの検知信号に基づいて災害発生を検知する。また、災害時処理開始指令受信部１６は、例えば保守員が災害時処理開始指令送信用の可搬型端末をエリア内のネットワークに接続し、当該端末から送信された開始指令を受信することで、災害時処理の開始指令を出力する。

災害時処理プログラム実行部１８は災害時処理プログラムを実行することにより、図３のフローチャートに示すような手順の処理を実行する。

まず、代表ローカル端末処理実施判定部１７は、中央システム１０の代表ローカル端末候補決定部２により決定された代表ローカル端末候補順を示す情報を参照することにより、自ローカルがエリアを代表する代表ローカル端末であるか否かを判定する（ステップＳ１，Ｓ２）。当該判定部１７は、代表ローカル端末の候補順において、一番最初の候補として自ローカル端末が位置している場合には、自ローカル端末が代表ローカル端末であると判定する（ステップＳ２のＹＥＳ）。そうでない場合には、当該判定部１７は、自ローカル端末が代表ローカル端末でないと判定する（ステップＳ２のＮＯ）。

代表ローカル端末であると判定された場合には、災害時代表ローカル端末処理部１９では、災害時保守情報送信依頼部２０は、当該エリア内の全ローカル端末に対して災害時保守情報送信依頼を行なう（ステップＳ３）。このとき、災害時保守情報送信依頼部２０は、依頼をしたことを、災害時保守情報受信部２１及び災害時保守情報管理部２２に通知する。

さらに、災害時保守情報送信依頼部２０は、災害時保守情報の送信依頼を送付した各ローカル端末から応答が来なかった場合には、当該エリアに断線が発生しているか、または応答しないローカル端末が故障していると判定する（ステップＳ４）。

災害時代表ローカル端末処理部１９では、災害時保守情報受信部２１は、依頼に応じてエリア内の各ローカル端末から送信された災害時保守情報を受信する（ステップＳ５）。災害時保守情報受信部２１は、受信した災害時保守情報を災害時保守情報管理部２２に転送する。

災害時保守情報管理部２２は、エリア内の各ローカル端末から受信した災害時保守情報を、災害時保守情報ＤＢ２３に蓄積し、災害時保守情報表示部２６に転送するための処理を実行する（ステップＳ６）。災害時保守情報ＤＢ２３は、例えばハードディスクドライブから構成されており、災害時保守情報をデータファイルとして蓄積する。また、災害時保守情報ＤＢ２３は、例えばフラッシュメモリから構成されており、同様に、災害時保守情報をデータファイルとして蓄積する。また、災害時保守情報管理部２２は、前述した当該エリアに断線が発生していると判断した場合のエリア内の断線情報や、応答しないローカル端末が故障していると判断した場合のローカルの故障情報も、災害時保守情報として災害時保守情報ＤＢ２３に蓄積する。

ここで、災害時保守情報管理部２２は、各ローカル端末から受信した災害時保守情報から保存に必要な情報を取得し、災害時保守情報保存部２７に転送する（ステップＳ７のＹＥＳ）。災害時保守情報保存部２７は、災害時保守情報管理部２２から転送された必要情報を保存する（ステップＳ８）。

また、災害時保守情報保存部２７は、保守員がローカル端末より災害時保守情報を収集する際に機能する。この災害時保守情報の収集に関しては、例えば、保守員が情報収集用の端末を持ち、該当のローカル端末まで移動し、有線にて情報収集用端末をローカル端末に接続して、情報をダウンロードする方法で行なう。

ここで、代表ローカル端末に対して情報収集を行うことで、エリア内のローカル端末の災害時保守情報が取得可能である。また、ローカル端末が充電可能な電池を有し、無線による情報通信方法が利用可能な場合には、災害時で保守員がローカル端末に近づくことが困難なケースでも、無線通信に対応した情報収集端末を利用することで、ローカル端末より多少離れた場所（安全が確保できる場所）での情報収集が可能である。更に、ローカル端末が充電可能な電池を有し、災害時にも動作可能な場合には、災害時に商用電源が断たれた場合においても災害時保守情報の収集が可能である。この場合、災害の自動検知が可能な場合など、その自動検知結果により電池に切り替える等の方法で利用したり、常に電池を接続しておき、断線されても機能が停止しないようにする等の方法が利用できる。

さらに、災害時保守情報管理部２２は、各ローカル端末から受信した災害時保守情報の表示が必要であると判断した場合には、当該情報を災害時保守情報表示部２６に転送する（ステップＳ９のＹＥＳ）。災害時保守情報表示部２６は、災害時保守情報管理部２２から転送された災害時保守情報を画面上に表示する（ステップＳ１０）。

具体的には、災害時保守情報表示部２６は、図６（Ａ）に示すように、液晶ディスプレイからなる画面６０に、災害時保守情報管理２２から転送された文字情報の災害時保守情報を表示する。画面６０には、数種類の情報がｎ秒（例えば２秒）毎に、繰り返し表示される。ここで、代表ローカル端末になった場合は、エリア内の全ローカル端末に災害時保守情報送信依頼を行うため、エリア内全ローカル端末への依頼送信が可能となるような情報（各ローカル端末のＩＰアドレス等）が、災害時処理プログラム内に保持されているか、または設定ファイルとしてローカル端末上で参照可能な形態で記憶されている。

また、災害時保守情報表示部２６は、図６（Ｂ）に示すように、液晶ディスプレイからなる画面６０を有すると共に、表示情報切替用ボタン６１を有する。この表示情報切替用ボタン６１を操作することにより、画面６０には、数種類の情報がボタン６１を押す度に順番に表示される。従って、例えば重要な情報から表示するなど、保守員の意志に即した情報収集が可能となる。ここで、表示内容切替用ボタン６１の代わりに、回転式ダイヤル等も利用可能である。

また、ローカル端末において、液晶ディスプレイ６０を設置するスペースがない場合には、図６（Ｃ）に示すように、発光ダイオード素子（ＬＥＤ）６２でもよい。即ち、災害時保守情報表示部２６は、ＬＥＤの色および点滅方法にて災害時保守情報を表示する。例えば、情報に応じてＬＥＤの発光色を変化させたり、フラグオン時に点灯、フラグオフ時に点滅などの表示形態で情報を表示できる。なお、情報はｎ秒（例えば２秒）毎に、繰り返し表示される。

この場合、例えば代表ローカル端末であるかどうかを表示する場合、ＬＥＤ６２の点滅により、代表ローカル端末であることを示す情報を表示できる。また、複数のＬＥＤを設置することで、それぞれのＬＥＤに個別の情報を対応させて、ＬＥＤの色、点滅方法（点滅の周期や、点灯および消灯時間、また点滅の種類（３回短く点灯し１回消灯等））により複数の情報の表示が可能となる。最も簡単な方法は、それぞれのＬＥＤをビット情報とし、それぞれＬＥＤが点灯時はビットが１、ＬＥＤが消灯時はビットが０などと決定しておき、例えば１番目のＬＥＤを代表ローカル端末かどうかの情報、２番目のＬＥＤを断線があるかどうかの情報もしくは自ローカル端末が孤立（他のどのローカル端末とも接続されていない）しているどうかの情報を対応させ表示する方法がある。

さらに、図６（Ｄ）に示すように、ＬＥＤ６２と、表示内容切替用ボタン６１とを組み合わせた災害時保守情報表示部２６でもよい。ＬＥＤ６２は、前述したように、情報に応じて発光色が変化し、フラグオン時に点灯、フラグオフ時に点滅などの表示形態で情報を表示する。一方、表示情報切替用ボタン６１を操作することにより、情報はボタン６１を押す度に順番に表示される。

一方、代表ローカル端末処理実施判定部１７により、自ローカル端末が代表ローカル端末ではないと判定された場合には、災害時通常ローカル端末処理部２４が動作する（ステップＳ２のＮＯ）。災害時通常ローカル端末処理部２４では、災害時保守情報送信部２５は、代表ローカル端末からの災害時保守情報の送信依頼に応じて、自ローカル端末の災害時保守情報を当該代表ローカル端末へ送信する（ステップＳ１２）。災害時保守情報としては、自ローカル端末を特定するための情報（ＩＤまたはＩＰアドレス等）、自ローカル端末の正常機能可能の可否を表す情報（フラグ）、送信データの送信時の時刻に関する情報、及び故障箇所の有無を表す故障情報を含む（図１０を参照）。ここで、図１０は、災害時に各ローカル端末が災害時保守情報を代表ローカル端末へ送信する場合の処理手順を示すフローチャートである。この故障情報は、例えば、それぞれの各構成要素に対応するビットを設定し、各構成要素において故障している要素のみビットを１とし、故障していない場合は０とすることで、故障状況表示ビット（又はこれらを纏めたデータ）を含む。

この他にも、災害時保守情報としては、代表ローカル端末の情報蓄積容量が許す限り、また、ネットワーク負荷に悪影響がでないレベルで、災害時に有効利用可能なデータを含むことも可能である。更に、災害時保守情報に対して、送信データの送信時の時刻に関する情報を付加することで、事故発生時の時間を推測するための情報が得られる（図１０及び図１１を参照）。また、代表ローカル端末側にて、災害時保守情報を受信した際に、受信時刻を付加して管理することで、情報の送付側ローカル端末と代表ローカル端末間の情報伝送に要した時間の目安が得られる。また、その情報の送信時刻と受信時刻とを比較し、比較結果が妥当でない場合には、送信側ローカル端末または代表ローカル端末のどちらかの時刻取得機能（内蔵時計等）の故障発見のトリガ情報として利用することなどが可能である（図１０のＳ６１〜Ｓ６３を参照）。ここで、時刻合わせ用共通サーバを利用可能である場合は、情報取得時に時刻合わせ用共通サーバに時刻問合せを行うことで、より正確な事項情報を取得可能であり、また、時刻ずれの発見が可能である（図１１の１１０を参照）。

次に、エリア内で、災害に伴うネットワークの断線がある場合の処理手順について、図４のフローチャートを参照して説明する。

代表ローカル端末処理実施判定部１７により、自ローカル端末が代表ローカル端末ではないと判定された場合において、エリア内で代表ローカル端末と接続されていない場合は保守情報が収集されないことになる。よって、代表ローカル端末と自ローカル端末とを接続するネットワークが断線している場合には、次の代表ローカル端末候補を代表ローカル端末として接続状況をチェックし、自ローカル端末と接続しているローカル端末で代表ローカル端末候補順の順位が高いローカル端末を代表ローカル端末とする。これらの作業を繰り返すことで、ある程度の断線状況が把握できる。

具体的には、代表ローカル端末処理実施判定部１７は、自ローカル端末が代表ローカル端末でない場合、代表ローカル端末候補順にて最も順位が代表ローカル端末に対して、代表ローカル端末として機能可能か否かの問合せを行う（ステップＳ２１）。ここで、予め作成された代表ローカル端末候補順に準拠して代表ローカル端末を決定していくことで、保守員が災害時に代表ローカル端末の設置場所に移動する際にも、代表ローカル端末候補順に従って移動することで、保守員の移動の負荷も低減する。

問い合わせをした代表ローカル端末から応答がない場合には、動作不可能と判定し、予め決定されている代表ローカル端末候補順で、次に順位の高いローカル端末を代表ローカル端末として再設定する（ステップＳ２２のＮＯ，Ｓ２３）。代表ローカル端末処理実施判定部１７は、この再設定した代表ローカル端末が自ローカル端末であるか否かをチェックする（ステップＳ２４）。代表ローカル端末処理実施判定部１７は、自ローカル端末である場合には、代表ローカル端末として設定する（ステップＳ２４のＹＥＳ，Ｓ２５）。

一方、代表ローカル端末が自ローカル端末でない場合は、代表ローカル端末処理実施判定部１７は、再設定した代表ローカル端末に対して、代表ローカル端末として機能可能かどうかの問合せを行う（ステップＳ２４のＮＯ，Ｓ２６）。代表ローカル端末処理実施判定部１７は、この問合せに対する応答の有無をチェックする（ステップＳ２７）。

問い合わせをした代表ローカル端末から応答がない場合には、動作不可能と判定し、代表ローカル端末候補順に応じて代表ローカル端末を変更する処理を繰り返す（ステップＳ２７のＮＯ，Ｓ２３）。また、問い合わせをした代表ローカル端末からの応答（正常機能可能である回答）を受信できた場合には、正常機能可能であると判断し、現在設定の代表ローカル端末を代表ローカル端末として利用する（ステップＳ２７のＹＥＳ，Ｓ２８）。

この場合、災害時保守情報送信部２５は、代表ローカル端末からの災害時保守情報の送信依頼に応じて、自ローカル端末の災害時保守情報を当該代表ローカル端末に送信する（ステップＳ３１）。

また、代表ローカル端末処理実施判定部１７は、自ローカル端末を代表ローカル端末として設定した場合、災害時保守情報送信依頼部２０は、自機が代表ローカル端末であることを、問い合わせをしていない他のローカル端末に連絡する（ステップＳ３２）。さらに、災害時保守情報送信依頼部２０は、自ローカル端末が所属するエリアの各ローカル端末に対して、災害時保守情報の送信を依頼する（ステップＳ３３）。災害時保守情報送信依頼部２０は、災害時保守情報の送信依頼を実行した後、予め設定された一定の時間、各ローカル端末からの応答を待つため待機する（ステップＳ３４）。

災害時保守情報送信依頼部２０は、ある一定時間経過後に、全ローカル端末から災害時保守情報が収集できたか否かをチェックし、対象の全ローカルから災害時保守情報が収集できるまで待機状態となる（ステップＳ３５のＮＯ）。この場合、チェック処理を数回繰り返した結果（例えば３０分間（１０分毎に３回）等）、情報収集ができないローカル端末は、代表ローカル端末である自ローカル端末と断線していると判断し、災害時保守情報の収集を終了する（ステップＳ３５のＹＥＳ）。以上のようにして、代表ローカル端末である自ローカル端末は、エリア内の各ローカル端末から災害時保守情報を収集できる。また、接続されていないローカル端末も検知できるため、断線状況に関する情報も災害保守情報として収集できる。

一方、代表ローカル端末処理実施判定部１７は、問い合わせをした代表ローカル端末から応答があった場合、初期設定時の代表ローカル端末を代表ローカル端末として設定する（ステップＳ２２のＹＥＳ，Ｓ２９）。災害時保守情報送信部２５は、代表ローカル端末からの災害時保守情報の送信依頼に応じて、自ローカル端末の災害時保守情報を当該代表ローカル端末に送信する（ステップＳ３０）。

以上のような処理を、図５の概念図を参照して説明する。

図５に示すように、エリア１では、保守拠点Ａに最も近いローカル端末１が代表ローカル端末の１番目の候補であると想定する。ここでは、代表ローカル候補順は、保守拠点Ａに直線距離的に近いほうから順位が高いものとし、ローカル端末ｎの番号が優先順位であるものとする。また、ローカル端末１は故障もしくは破壊していない状況であるため、通常処理ではローカル端末１が、エリア１の代表ローカル端末となる。

ここで、エリア１内にて断線２１０が発生し、ローカル端末４、６，７，８，９は代表ローカル端末であるローカル端末１から断線した状況である。この場合に、ローカル端末４，６，７，８，９は、災害時処理プログラムの処理の開始後、ある設定時間（例えば自エリア内にて自ローカル端末から最も遠方のローカル端末への問合せ−回答に要する時間等）を超えても、代表ローカル端末からの災害時保守情報の送信依頼の問合せがないことになるため、代表ローカル端末候補順に従って、ローカル端末１以外の他のローカル端末を代表ローカル端末とすべく処理を進める。

ここでは、ローカル端末ｎの番号ｎが代表ローカル端末候補の優先順であるため、断線により生成されたサブエリア２においては、例えばローカル端末４が代表ローカル端末となる。また、サブエリア２における代表ローカル端末決定処理において、ローカル端末４、６，７，８，９は、ローカル端末１との接続状況を断線として判断しているため、この情報を断線状況情報として利用可能である。更に、サブエリア１においては、ローカル端末１は、エリア１内のローカル端末に対して、災害時保守情報の送信依頼を送付し、その応答状況を把握しているため、回答がないローカル端末４，６，７，８，９に関してはローカル端末１とは接続されておらず、ローカル端末２、５は接続されていることがわかる。また、サブエリア２においても、ローカル端末４が代表ローカル端末として動作開始した後は、ローカル端末１と同様に、エリア内ローカル端末に対して災害時保守情報の送信依頼の問合せを実行して、応答状況を把握する。これにより、応答がないローカル端末１，２，５はローカル端末４とは接続されておらず、ローカル端末６，７，８，９がローカル端末４と接続されていることがわかる。

このようにして、代表ローカル端末よりエリア内の断線情報がわかる。ここで、前記の例は、代表ローカル端末候補順がある場合の例であるが、代表ローカル端末候補順がない場合でも、各ローカル端末が、エリア内の全ての他のローカル端末に対して断線確認用の問合せを行い、その結果と“保守拠点とエリア内全ローカル端末との距離関係”に関する情報を所有している場合に、これらのデータから自動で次の代表ローカル端末を決定することも可能である。例えば、保守拠点とエリア内の全ローカル端末との距離関係より、サブエリア内に所属する全ローカル端末と保守拠点との距離から最も最短の距離のローカル端末を代表ローカル端末とするロジックを組み込み利用することで実現可能である。

また、断線情報の取得に関しては、比較的狭域の場合、例えばビル内の１フロア内のみ等の場合には、電力線搬送を利用したネットワーク通信を利用することが可能である。この場合、ネットワークのラインである電力線が断線した場合、通電自体もなくなるため、これに基づいて断線状況に関する情報を取得する方法もある。

以上のような本実施形態のシステムであれば、ネットワークが断線した場合に、遠隔地の監視・診断対象の各ローカル端末から災害時保守情報を効率よく収集することが可能となる。即ち、監視・診断対象である監視・診断機器が配置されているエリアを複数のエリアに分割し、各エリアにおいてローカル端末間の情報通信を利用して、代表ローカル端末に災害時保守情報を集中させることにより、災害時に保守情報を効率よく取得することが可能である。ここで、エリアの分割方法としては、エリアの領域を同等にするように分割したり、代表ローカル端末を保守拠点に最も近いローカル端末にする等により保守員の移動負荷を低減することが可能である。

さらに、エリア分割や代表ローカル端末の決定において、活断層情報を考慮することで、より、断線の可能性が少ないようなエリア分割または代表ローカル端末の決定が可能となる。更に、エリア内にてローカル端末の生存（故障なく正常に動作し、断線もしていない状態）を問合せ確認し、災害保守情報の送受信を行うことで、断線情報も災害時保守情報として代表ローカル端末に収集することが可能である。

また、ローカル端末からの情報を保守員の情報収集端末に電子データとして収集可能であることで、情報収集効率および事後の処理効率を向上させることが可能である。特に、ローカル端末が無線通信可能な場合は、災害時で危険な状況でありローカル端末近辺に近づくことが困難な場合でも情報収集が可能である。なお、代表ローカル端末は、事前に決定されている方式が望ましい。自動的に決定される方式でも良いが、保守員が代表ローカル端末を探索する必要がある。

［第２の実施形態］
図７は、第２の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図である。なお、図１に示す第１の実施形態に関する遠隔監視・診断システムと同様の構成については同一符号を付して、詳細な説明は省略する。

本実施形態のシステムでは、各ローカル端末１１は、災害時通常ローカル端末処理部２４に含まれる情報収集用移動プログラム送受信部２８、及び災害時代表ローカル端末処理部１９に含まれる情報収集用移動プログラム情報収集開始部（以下、情報収集開始部と略す）２９を有する。さらに、災害時代表ローカル端末処理部１９には、情報収集用移動プログラム情報収集完了処理部（以下、情報収集完了処理部と略す）３０が含まれている。

（システムの作用）
まず、前述したように、災害時処理プログラム実行部１８は、災害時の発生まで待機し、自動災害検知部１５の検知結果、あるいは災害時処理開始指令受信部１６からの開始指令を受けた場合に、災害時と判断し、災害時処理プログラムを実行する。さらに、代表ローカル端末処理実施判定部１７は、自ローカル端末が代表ローカル端末であるか、又は通常のローカル端末であるかの判定処理を実行する。

次に、本実施形態では、エリア内でネットワークの断線が生じている場合には、情報収集用移動プログラムが各ローカル端末間を移動して情報収集する構成である。以下、図９のフローチャートを参照して、処理手順を説明する。

代表ローカル端末処理実施判定部１７は、エリア内の全ローカル端末に対して回答可能な状況であるか否かの問合せを行う（ステップＳ４１）。この問合せの回答状況により、エリア内の接続状況を表すマップ（エリア内接続状況マップ）を作成する（ステップＳ４２）。これは、エリア内の全ローカル端末毎に自ローカル端末との接続状況を示す情報を表形式などで保有する。この様な処理を全ローカル端末が実施することで、全ローカル端末がエリア内接続状況マップを所有することが可能である。

次に、代表ローカル端末処理実施判定部１７は、エリア内接続状況マップに基づいて、例えば保守拠点に最も近いローカル端末を代表ローカル端末として決定する（ステップＳ４３）。ここで、エリア内でのネットワーク断線がない場合には、予め決定されていた代表ローカル端末候補順にて、最も優先順位が高いローカル端末を代表ローカル端末として設定する。

一方、断線が生じている場合には、断線にてエリア内がサブエリアに分割されているため、自ローカル端末が所属するサブエリア内に代表ローカル端末を設定する必要がある。この代表ローカル端末を設定する場合に、エリア内接続状況マップを使用して、自ローカル端末と同じサブエリアに所属するローカル端末を認識できるため、この中から代表ローカル端末を決定する。決定方法としては、自ローカル端末と同じサブエリア内に所属するローカル端末の中で、保守拠点に最も近いものとする場合以外に、サブエリア内のローカル端末で、代表ローカル端末候補順にて最も優先順位が高いローカル端末を代表ローカル端末とする方法でもよい。

次に、代表ローカル端末処理実施判定部１７は、決定した代表ローカル端末が自ローカル端末であるか否かをチェックする（ステップＳ４４）。このチェック結果に基づいて、代表ローカル端末が自ローカル端末である場合は、自ローカル端末を代表ローカル端末として決定する（ステップＳ４５）。これにより、自ローカル端末は、代表ローカル端末として処理を進める。

一方、代表ローカル端末が他のローカル端末である場合は、自ローカル端末は通常のローカル端末として処理を実行する（ステップＳ４４のＮＯ）。即ち、通常ローカル端末処理部２４は、情報収集用移動プログラム送受信部２８が、代表ローカル端末より移動を開始した情報収集用移動プログラムを受信するまで待機する（ステップＳ５０）。情報収集用移動プログラムが自ローカル端末に到着すると、災害時保守情報送信部２５は、自ローカル端末の災害時保守情報を情報収集用移動プログラムに受け渡す（ステップＳ５１）。

ここで、災害時保守情報送信部２５は、災害時保守情報を受け渡す場合に、情報収集用移動プログラム自体にプログラムコードの一部として追加したり、ポートを利用して受け渡しを行う。また、情報収集用移動プログラムをエージェントで構成する場合は、例えばBee-gent（登録商標）を用いる場合には、例えばbaggage命令にてエージェント内にデータを保持することが可能であるため、baggage命令にて情報を収集することも可能である。

このような自ローカル端末の災害時保守情報の収集が完了した後に、情報収集用移動プログラム送受信部２８は、情報収集用移動プログラムを次のローカル端末に移動させる（ステップＳ５２）。この場合、災害時保守情報送信部２５は、情報収集用移動プログラム送受信部２８に災害時保守情報の送信終了のトリガを出力する。このトリガに基づいて、情報収集用移動プログラム送受信部２８は、情報収集用移動プログラムを次のローカル端末に移動させる。

この移動処理に関しては、情報収集用移動プログラム自体が予め移動順を持つ方法や、各ローカル端末に次の移動先の情報を設定して、これを参照する方法もある。この場合、ネットワーク断線を考慮し、複数の候補を設定しておく必要がある。また、移動処理に関しては、情報収集用移動プログラム送受信部２８が次のローカル端末へ情報収集用移動プログラムを送信する方法以外に、情報収集用移動プログラムが自律的に移動が可能な移動エージェントであれば、この移動エージェント内に移動に関する処理を記載し、その処理に基づいて移動する方法でもよい。

また、自ローカル端末が代表ローカル端末であると判定された場合には、自ローカル端末を代表ローカル端末として、代表ローカル端末の処理を実行する（ステップＳ４５）。即ち、災害時代表ローカル端末処理部１９に含まれる情報収集開始部２９は、エリア内接続状況マップに基づいて、情報収集用移動プログラムが移動して情報収集すべきローカル端末の一覧を作成する（ステップＳ４６）。この一覧表の作成においては、代表ローカル端末候補順の順序に準拠して並べる方法がある。この場合、代表ローカル端末候補順が保守拠点からの距離が短い順になっている場合、保守拠点から近い順に情報収集することが可能となる。

情報収集開始部２９は、作成した情報収集すべきローカル端末の一覧に基づいて、情報収集用移動プログラムによる災害時保守情報の情報収集を開始する（ステップＳ４７）。情報収集の方法としては、情報収集用移動プログラム自体が、ネットワーク９を介してローカル端末間を移動し、各ローカル端末の災害時保守情報を収集する。この情報収集開始処理が完了した時点で、情報収集用移動プログラムは、代表ローカル端末である自ローカル端末上には存在しないことになる。

情報収集開始部２９は、収集開始処理が完了した旨を情報収集完了処理部３０に通知する。情報収集を開始した情報収集用移動プログラムは、代表ローカル端末である自ローカル端末が所属するエリア（またはサブエリア）内の全ローカル端末を移動し、災害時保守情報の収集処理を実行する。

この間、代表ローカル端末上では、情報収集完了処理部３０は、情報収集用移動プログラムの戻りを待つ待機状態となる（ステップＳ４８）。情報収集完了処理部３０は、情報収集開始部２９から情報収集開始処理が完了した旨の通知を受けた後に待機状態となる。情報収集用移動プログラムが代表ローカル端末である自ローカル端末に戻った時点で、情報収集完了処理部３０は、情報収集作業完了処理を行う（ステップＳ４９）。この情報収集作業完了処理としては、最後の災害時保守情報として、自ローカル端末の災害時保守情報を収集して完了とする。

ここで、情報収集用移動プログラムは、ローカル端末間を移動するときに、次のローカル端末に移動する前に、次のローカル端末が移動可能な状況であるか否かの問合せを行う。この問い合わせに対する応答に基づいて、情報収集用移動プログラムは、次のローカル端末に移動可能か否かを判断し、可能であれば移動する。この場合、問合せに対する応答について、設定時間（“通常時にＰＩＮＧ命令などで求めた通信時間＋余裕時間”など）を超えても応答がない場合や、ローカル端末を構成する機器の一部が故障しており、移動に支障がある旨の応答があった場合には、次のローカル端末は断線（もしくは移動不可）と判断し、さらに次のローカル端末への移動を行う。

また、情報収集用移動プログラムが自律的に移動することが可能な移動エージェントの場合には、移動処理が移動失敗の結果になった場合や、移動完了までに設定時間以上を要する場合に、次のローカル端末が断線と判断する方法により、より最新の断線情報を収集する。さらに、情報収集用移動プログラムは、情報収集開始時の時刻、情報収集完了時の時刻、及び各ローカル端末にて災害時保守情報を収集した時点の時刻情報から、各ローカル端末の時刻情報の異常を推定する（図１２及び図１３を参照）。

図１３に示すように、情報収集用移動プログラムが情報収集を完了して代表ローカル端末に戻ってきた時刻と、ローカル端末Ｃでの情報収集時点の時刻を比較した場合、ローカル端末Ｃの時刻は明らかにかなり将来の時刻であり（誤差の範囲を超えており）、ローカル端末Ｃの時刻が明らかに異常であることがわかる（図１３の１３０を参照）。

情報収集用移動プログラムにより収集完了した情報は、災害時保守情報管理部２２に渡される。災害時保守情報管理部２２は、前述の第１の実施形態と同様に、収集完了した情報を災害時保守情報ＤＢ２３に蓄積したり、災害時保守情報表示部２６で情報表示する。また、災害時保守情報保存部２７は、災害時保守情報管理部２２から転送される収集完了した情報の一部又は全部を保存する。

以上のような本実施形態のシステムであれば、各エリアにおいて代表ローカル端末からの情報収集用移動プログラムが、ネットワーク９を介して、各ローカル端末間を移動しながら各ローカル端末の災害時保守情報を収集する。代表ローカル端末は、収集した情報を蓄積することにより、災害時の保守情報を効率よく取得することが可能である
更に、災害を自動検知し、情報収集用移動プログラムが収集作業を自動で開始する仕組みにより、災害時に自動情報収集が可能となる。また、情報収集用移動プログラムの移動時に、移動先のローカル端末が移動可能か否かの問合せを行うことで、より最新のネットワーク断線状況を取得することも可能である。

更に、本実施形態では、情報収集用移動プログラムは、図１５に示す処理１５０を実行することにより、代表ローカル端末を出発してからの通過時刻（Ｔｓ，Ｔｅ，Ｔ１，Ｔ２）に基づいて、各ローカル端末の内部時計の故障を判定することができる。即ち、情報収集用移動プログラムの収集開始時刻と収集完了時刻および各ローカル端末にて情報収集した時刻を比較することで、ローカル端末の時刻で明らかに異常なものがある場合は、それを検出することが可能である（図１４を参照）。なお、図１４において、エリア１内での点線は、情報収集用移動プログラムの情報収集経路を示す。

［第３の実施形態］
図１６は、第３の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図である。なお、図１に示す第１の実施形態に関する遠隔監視・診断システムと同様の構成については同一符号を付して、詳細な説明は省略する。

本実施形態のシステムでは、ネットワーク９に接続された可搬型情報収集装置３００が設けられている。また、各ローカル端末１１は、災害時通常ローカル端末処理部２４を含むが、災害時代表ローカル端末処理部１９を含まない構成である。

（システムの作用）
本実施形態の可搬型情報収集装置３００は、保守員が携帯して移動可能な可搬型の情報収集装置であり、監視・診断対象機器が接続されているネットワーク９に接続して利用する。ネットワーク９への接続は、例えばネットワークがインターネットである場合は、ローカル端末１１が接続されているハブ（ＨＵＢ）にＬＡＮ接続が可能である。

可搬型情報収集装置３００は、図１に示す災害時代表ローカル端末処理部１９に相当する機能を含む。即ち、可搬型情報収集装置３００は、災害時保守情報送信依頼部２０、災害時保守情報受信部２１、災害時保守情報管理部２２、及び災害時保守情報データベース（ＤＢ）２３の各機能を有する。

図１７に示すように、本実施形態の可搬型情報収集装置３００を使用して、ネットワーク９を介してローカル端末ｎ（１〜９）に接続し、災害時保守情報を参照、またはダウンロードすることで、エリア内の災害時保守情報の収集を行なうことができる。可搬型情報収集装置３００はネットワーク９のどこに接続しても良いため、各ローカル端末には代表ローカル端末の機能を持たせることなく、効率的な災害時保守情報の収集が可能である。

［第４の実施形態］
図１８は、第４の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図である。なお、図１に示す第１の実施形態に関する遠隔監視・診断システムと同様の構成については同一符号を付して、詳細な説明は省略する。

本実施形態のシステムでは、ネットワーク９に接続された災害時代表ローカル端末機能用ミニサーバ（以下、ミニサーバと略す）４００が設けられている。また、各ローカル端末１１は、災害時通常ローカル端末処理部２４を含むが、災害時代表ローカル端末処理部１９を含まない構成である。

（システムの作用）
本実施形態のミニサーバ４００は、監視・診断対象機器が接続されているネットワーク９に接続して利用する。ミニサーバ４００は、図１に示す災害時代表ローカル端末処理部１９に相当する機能を含む。即ち、ミニサーバ４００は、災害時保守情報送信依頼部２０、災害時保守情報受信部２１、災害時保守情報管理部２２、及び災害時保守情報データベース（ＤＢ）２３の各機能を有する。

図１９に示すように、本実施形態のミニサーバ４００は、ネットワーク９を介してローカル端末ｎ（１〜９）に接続し、災害時保守情報を参照、またはダウンロードすることで、エリア内の災害時保守情報の収集を行なうことができる。この場合、本実施形態のミニサーバ４００は、前述の搬型情報収集装置３００などと比較して、大容量の情報を蓄積する記憶装置を含むことが可能であるため、大容量の災害時保守情報を収集して蓄積することが可能となる。

従って、本実施形態によれば、コスト的にミニサーバ４００の設置が可能であれば、災害時にミニサーバ４００内の代表ローカル端末処理機能により、大容量の災害時保守情報を収集して蓄積することが出来る。従って、効率的に災害時保守情報の収集を行なうことが可能となる。

なお、各実施形態のシステムは、代表ローカル端末を、エリア内の各ローカル端末から自動で決定する場合について説明したが、ローカル端末設置時に予め代表ローカル端末を決定して設置する方式でもよい。また、エリア内にローカル端末が１台のみの場合でも、各実施形態のシステムを適用することが可能である。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の第１の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図。 第１の実施形態に関する遠隔監視・診断システムの動作を説明するための概念図。 第１の実施形態に関する災害時保守情報収集プログラムの処理手順を説明するためのフローチャート。 第１の実施形態に関する災害時保守情報収集の処理手順を説明するためのフローチャート。 第１の実施形態に関してエリア内断線発生時での代表ローカル端末の切替え処理を説明するための概念図。 第１の実施形態に関する災害時保守情報表示部の表示形態の一例を説明するための図。 第２の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図。 第２の実施形態に関する遠隔監視・診断システムの動作を説明するための概念図。 第２の実施形態に関する情報収集用移動プログラムの処理手順を説明するためのフローチャート。 第１の実施形態に関して、各ローカル端末が災害時保守情報を代表ローカル端末へ送信する場合の処理手順を示すフローチャート。 第１の実施形態に関して、災害時保守情報に収集時刻情報を付加した場合の代表ローカル端末の動作を示す概念図。 第２の実施形態に関する情報収集用移動プログラムが収集時刻情報を付加した災害時保守情報を収集する場合の処理手順を示すフローチャート。 第２の実施形態に関して、災害時保守情報に収集時刻情報を付加した場合の代表ローカル端末の動作を示す概念図。 第２の実施形態に関する情報収集用移動プログラムによる災害時保守情報の収集における時刻情報を使用した動作を示す概念図。 第２の実施形態に関する情報収集用移動プログラムによる各ローカル端末の内部時計の故障判定処理の一例を示す概念図。 第３の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図。 第３の実施形態に関する遠隔監視・診断システムの動作を説明するための概念図。 第４の実施形態に関する遠隔監視・診断システムの構成を説明するためのブロック図。 第４の実施形態に関する遠隔監視・診断システムの動作を説明するための概念図。

符号の説明

１…エリア分割構成作成部、２…代表監視・診断対象側ローカル端末候補決定部、
３…ローカル端末用プログラム作成部、４…ローカル端末用プログラム検証・評価部、
５…プログラム送信部、６…監視・診断結果データ処理部、７…監視診断結果受信部、
８…監視・診断結果表示部、９…ネットワーク、１０…中央システム、
１１…ローカル端末、１２…ローカル端末用プログラム受信部、
１３…監視・診断プログラム実行部、１４…監視・診断結果送信部、
１５…自動災害検知部、１６…災害時処理開始指令受信部、
１７…代表ローカル端末処理実施判定部、１８…災害時処理プログラム実行部、
１９…災害時代表ローカル端末処理部、２０…災害時保守情報送信依頼部、
２１…災害時保守情報受信部、２２…災害時保守情報管理部、
２３…災害時保守情報データベース（ＤＢ）、２４…災害時通常ローカル端末処理部、
２５…災害時保守情報送信部、２６…災害時保守情報表示部、
２７…災害時保守情報保存部、２８…情報収集用移動プログラム送受信部、
２９…情報収集用移動プログラム情報収集開始部、
３０…情報収集用移動プログラム情報収集完了処理部、１００…監視・診断対象機器、
３００…搬型情報収集装置、４００…災害時代表ローカル端末機能用ミニサーバ。

Claims (9)

1. ネットワークを介して中央システムと接続されて、所定のエリアに存在する監視・診断対象に対する監視・診断処理を行なう複数のローカル端末を有する遠隔監視・診断システムにおいて、
   前記中央システムから、前記監視・診断処理を実行するための監視・診断用プログラムまたは災害時処理プログラムを前記各ローカル端末に移動させるプログラム移動手段と、
   前記ネットワークを介した中央システムとの接続が遮断されたときに、前記エリアに含まれる各ローカル端末から代表ローカル端末を設定する設定手段と、
   前記代表ローカル端末により、前記エリアに存在する他のローカル端末から災害時保守情報を収集する情報収集手段と
   を具備したことを特徴とする遠隔監視・診断システム。
2. 前記情報収集手段は、
   前記設定手段により設定された代表ローカル端末が、同一エリアに含まれる他のローカル端末との間での情報通信を使用して、当該他のローカル端末から前記災害時保守情報を収集するように構成されていることを特徴とする請求項１に記載の遠隔監視・診断システム。
3. 前記情報収集手段は、
   前記代表ローカル端末から、同一エリアに含まれる他のローカル端末間を、災害時保守情報収集用移動プログラムを移動させることで、前記他のローカル端末から災害時保守情報を収集するように構成されていることを特徴とする請求項１に記載の遠隔監視・診断システム。
4. 前記情報収集手段において、
   前記代表ローカル端末は、災害発生の自動検知結果または外部システムからの災害時処理開始依頼に応じて災害時保守情報の収集処理を開始し、前記他のローカル端末に対して災害時保守情報の送信依頼を実行することで、前記他のローカル端末から災害時保守情報を収集するように構成されていることを特徴とする請求項１または請求項２のいずれか１項に記載の遠隔監視・診断システム。
5. 前記代表ローカル端末からの前記災害時保守情報の送信依頼に対して、前記他のローカル端末から設定時間内に応答がない場合には、前記エリア内でのネットワーク断線が発生していると判断し、当該ネットワーク断線状況情報を生成する手段を有することを特徴とする請求項４に記載の遠隔監視・診断システム。
6. 前記情報収集手段において、
   前記代表ローカル端末は、災害発生の自動検知結果または外部システムからの災害時処理開始依頼に応じて災害時保守情報の収集処理を開始し、前記災害時保守情報収集用移動プログラムを移動させることで、前記他のローカル端末から災害時保守情報を収集するように構成されていることを特徴とする請求項１または請求項３のいずれか１項に記載の遠隔監視・診断システム。
7. 前記代表ローカル端末から前記他のローカル端末に対して、前記災害時保守情報収集用移動プログラムが設定時間内に移動できない場合に、前記エリア内でのネットワーク断線が発生していると判断する手段を有することを特徴とする請求項３に記載の遠隔監視・診断システム。
8. 前記設定手段は、前記ネットワークを介した中央システムとの接続が遮断されたときに、前記エリアに含まれる各ローカル端末から、予め設定された順序に従って代表ローカル端末を設定することを特徴とする請求項１に記載の遠隔監視・診断システム。
9. 前記設定手段は、前記ネットワークを介した中央システムとの接続が遮断されたときに、前記エリアに含まれる各ローカル端末のそれぞれに対して動作可能であるか否かをチェックし、動作可能な各ローカル端末の中から予め設定された順序に従って代表ローカル端末を設定することを特徴とする請求項１に記載の遠隔監視・診断システム。

Images