監視制御システム
【課題】信頼性の低下を招くことなく、運用コストを低減することが可能な監視制御システムを提供する。
【解決手段】第１サーバ群を備えた第１監視制御局１０と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局１０とネットワークを介して接続された第２監視制御局２０と、を備えた監視制御システムにおいて、前記第１監視制御局１０は、空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理するスケジュール管理部と、前記スケジュール管理部により運用開始時刻であると判断された場合に前記第２監視制御局２０を起動し、前記スケジュール管理部により運用終了時刻であると判断された場合に前記第２監視制御局２０を停止する起動・停止処理部と、を備えたことを特徴とする監視制御システム。
【解決手段】第１サーバ群を備えた第１監視制御局１０と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局１０とネットワークを介して接続された第２監視制御局２０と、を備えた監視制御システムにおいて、前記第１監視制御局１０は、空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理するスケジュール管理部と、前記スケジュール管理部により運用開始時刻であると判断された場合に前記第２監視制御局２０を起動し、前記スケジュール管理部により運用終了時刻であると判断された場合に前記第２監視制御局２０を停止する起動・停止処理部と、を備えたことを特徴とする監視制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、監視制御システムに関する。
【背景技術】
【０００２】
従来、空港内に設置された各種監視制御対象設備、例えば、灯火設備、受変電設備、発電設備、無停電電源設備、空調設備等を監視制御する監視制御システムが導入されている。このような監視制御システムについては、障害対策として、同じ構成の装置を予め２系統用意しておき、冗長化されることが望ましい。
【０００３】
監視制御システムの冗長化方式としては、ホットスタンバイ方式及びコールドスタンバイ方式が知られている。ホットスタンバイ方式は、一方の系（稼動系）を作動させ、他方の系（待機系）は稼動系と同じ動作を行いながら待機状態としておき、稼動系に障害が発生すると即座に待機系に処理を引き継ぐ方式である。コールドスタンバイ方式は、一方の系（稼動系）を作動させ、他方の系（待機系）は電源を停止しておき、稼動系に障害が発生してから、待機系を起動して処理を引き継ぐ方式である。
【０００４】
ホットスタンバイ方式の場合、稼動系に加えて待機系の電力を常に消費するために、これらの稼動系及び待機系がそれぞれ複数のサーバ群で構成される大規模システムになる程、消費電力が増大し、運用コストの増大を招くといった課題がある。コールドスタンバイ方式の場合、稼動系に障害が発生した場合に、稼動系で蓄積したデータを速やかに待機系に引き継ぐことができず、待機系の起動に際して長い起動時間を要するため、監視制御機能の停止時間が長く、信頼性の低下を招くといった課題がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−６０８０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本実施形態の目的は、信頼性の低下を招くことなく、運用コストを低減することが可能な監視制御システムを提供することにある。
【課題を解決するための手段】
【０００７】
本実施形態によれば、
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、前記第１監視制御局は、空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理するスケジュール管理部と、前記スケジュール管理部により運用開始時刻であると判断された場合に前記第２監視制御局を起動し、前記スケジュール管理部により運用終了時刻であると判断された場合に前記第２監視制御局を停止する起動・停止処理部と、を備えたことを特徴とする監視制御システムが提供される。
【０００８】
本実施形態によれば、
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、前記第１監視制御局は、監視制御システムの状態を監視するのに必要な監視信号を収集するシステム状態監視部と、前記システム状態監視部によって収集された監視信号に基づいて前記第１監視制御局のダウンの予兆の有無を判断するダウン予兆判断部と、運用時間内に前記第２監視制御局を起動し、運用時間外に前記第２監視制御局を停止するとともに、運用時間外において、前記ダウン予兆判断部によりダウンの予兆があると判断されたのに基づいて停止中の前記第２監視制御局を起動する起動・停止処理部と、を備えたことを特徴とする監視制御システムが提供される。
【図面の簡単な説明】
【０００９】
【図１】図１は、本実施形態における監視制御システムの構成を概略的に示す図である。
【図２】図２は、図１に示した代表処理サーバの処理部の構成を概略的に示す図である。
【図３】図３は、本実施形態における監視制御システムの動作を説明するためのフローチャートである。
【図４】図４は、監視制御システムの第２構成例において、第１監視制御局を構成する代表処理サーバの処理部の構成を概略的に示す図である。
【図５】図５は、監視制御システムの第２構成例における動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本実施形態について、図面を参照しながら詳細に説明する。なお、各図において、同一又は類似した機能を発揮する構成要素には同一の参照符号を付し、重複する説明は省略する。
【００１１】
図１は、本実施形態における監視制御システムの第１構成例を概略的に示す図である。
【００１２】
すなわち、本監視制御システムは、空港内に設置された灯火設備、受変電設備、発電設備、無停電電源設備、空調設備等の各種監視制御対象設備Ｘを監視制御するものである。このような監視制御システムは、第１監視制御局１０、及び、第２監視制御局２０を備えている。これらの第１監視制御局１０及び第２監視制御局２０は、ネットワークを介して接続されている。また、これらの第１監視制御局１０及び第２監視制御局２０には、ネットワークを介して、監視制御子局３０…、端末装置４０…などが接続されている。
【００１３】
監視制御子局３０は、監視制御対象設備Ｘとの間で監視制御信号を授受する。このような監視制御子局３０は、監視制御対象設備Ｘの個数に応じて１個以上設置されている。監視制御子局３０と監視制御対象設備Ｘとの間での監視制御信号の授受には、例えば、監視制御子局３０が監視制御対象設備Ｘにおける電流、電圧、温度などの各種計測データを受信することや、監視制御子局３０が監視制御対象設備Ｘにおける故障などの状態変化を検出することなどが含まれる。
【００１４】
例えば、監視制御対象設備Ｘの状態変化の検出は、以下のようにして行われる。監視制御対象設備Ｘは、監視制御項目に応じた個数の接点を有している。これらの接点のそれぞれは、監視制御子局３０の入力基板に電気的に接続されている。監視制御対象設備Ｘにおいて、故障などの状態変化が生じた場合には、対応する接点が閉じ、電気的な閉回路が形成される。この例では、閉回路を流れる電気が上記の監視制御信号に相当する。監視制御子局３０では、閉回路に電気が流れた際に、監視制御対象設備Ｘにおいて状態変化が発生した監視制御項目が判断される。
【００１５】
また、この監視制御子局３０は、第１監視制御局１０との間で監視制御信号を授受する。第１監視制御局１０と監視制御子局３０との間での監視制御信号の授受には、例えば、第１監視制御局１０が監視制御子局３０から監視制御対象設備Ｘの各種計測データや監視制御対象設備Ｘの状態変化の履歴を受信することなどが含まれる。なお、監視制御子局３０は、第１監視制御局１０及び第２監視制御局２０との双方の間で監視制御信号を授受しても良い。第１監視制御局１０に障害が発生した場合等には、監視制御子局３０は、第２監視制御局２０との間で監視制御信号を授受する。
【００１６】
端末装置４０は、監視員に情報提供を行ったり、監視員による操作入力を受け付けたりするものである。この端末装置４０は、第１監視制御局１０との間で各種情報を授受する。第１監視制御局１０と端末装置４０との間での情報の授受には、例えば、端末装置４０が第１監視制御局１０から監視制御対象設備Ｘの各種計測データや監視制御対象設備Ｘの状態変化の履歴を受信すること、第１監視制御局１０が端末装置４０から入力された情報を受信することなどが含まれる。なお、端末装置４０は、第１監視制御局１０及び第２監視制御局２０との双方の間で監視制御信号を授受しても良い。第１監視制御局１０に障害が発生した場合等には、端末装置４０は、第２監視制御局２０との間で各種情報を授受する。
【００１７】
このような端末装置４０は、１個以上設置されている。端末装置４０は、処理部４１、記録部４２、入力部４３、表示部４４、通信部４５などを備えて構成されている。処理部４１は、各種演算処理を行うものである。記録部４２は、各種データを蓄積するものである。入力部４３は、監視員による操作入力、具体的には、後述する空港の運用開始時刻及び運用終了時刻を規定する運用時間スケジュール（基本運用時間スケジュール及び運用時間延長スケジュールを含む）の入力、緊急便の離着陸に対応するための緊急便対応モードの設定操作及び解除操作、第１監視制御局１０から第２監視制御局２０へのデータの等値化処理を行う等値化スケジュールの入力、後述する第２構成例においてダウンの予兆の有無を判断するのに必要な閾値の設定などを受け付ける。表示部４４は、入力部４３を介して入力された情報、第１監視制御局１０や第２監視制御局２０から受信した情報（監視制御対象設備Ｘの計測データや状態変化の履歴などを含む）などを表示する。通信部４５は、ネットワーク経由で第１監視制御局１０や第２監視制御局２０などと情報を授受する。
【００１８】
第１監視制御局１０及び第２監視制御局２０は、監視制御子局３０との間で授受される監視制御信号を処理・蓄積し各種演算処理を行う。また、これらの第１監視制御局１０及び第２監視制御局２０は、端末装置４０との間で授受される各種情報を処理・蓄積し各種演算処理を行う。
【００１９】
第１監視制御局１０は、第１サーバ群を備えている。この第１サーバ群は、各種処理を行うための複数のサーバ群、すなわち、第１処理サーバ１０−１、…第ｎ処理サーバ１０−ｎと、それらを統括する代表処理サーバ１００とで構成されている（但し、ｎは正の整数である）。これらの第１処理サーバ１０−１乃至第ｎ処理サーバ１０−ｎは、例えば、アプリケーションサーバ、データベースサーバ、ＷＥＢサーバなどである。
第２監視制御局２０は、第１サーバ群と同等構成の第２サーバ群（第１処理サーバ２０−１、…第ｎ処理サーバ２０−ｎ、及び、代表処理サーバ２００）を備えている。
【００２０】
このような構成の第１監視制御局１０及び第２監視制御局２０は、監視制御子局３０に対して、「親局」と称される場合がある。本実施形態における監視制御システムは、これらの２つの親局により冗長化されている。なお、ここに示す例に限らず、親局は、３つ以上設置されても良い。
【００２１】
第１監視制御局１０の代表処理サーバ１００と、第２監視制御局２０の代表処理サーバ２００とは、同一構成であり、同一機能を有している。ここでは、代表処理サーバ１００の構成について説明し、代表処理サーバ２００の説明は省略する。代表処理サーバ１００は、処理部１、記録部２、通信部３などを備えて構成されている。処理部１は、各種演算処理を行うものであり、その詳細については後述する。記録部２は、各種データを蓄積するものである。通信部３は、ネットワーク経由で監視制御子局３０や端末装置４０などと情報を授受する。この代表処理サーバ１００は、第１処理サーバ１０−１乃至第ｎ処理サーバ１０−ｎとの間でも情報の授受を行う。
【００２２】
第１監視制御局１０の第１処理サーバ１０−１乃至第ｎ処理サーバ１０−ｎと、第２監視制御局２０の第１処理サーバ２０−１乃至第ｎ処理サーバ２０−ｎとは、同一構成である。ここでは、第１処理サーバ１０−１の構成について説明し、他の処理サーバの説明は省略する。第１処理サーバ１０−１は、処理部１１、記録部１２、通信部１３などを備えて構成されている。処理部１１は、各種演算処理を行うものである。記録部１２は、各種データを蓄積するものである。通信部１３は、ネットワーク経由で監視制御子局３０や端末装置４０などと情報を授受する。
【００２３】
図２は、図１に示した代表処理サーバの処理部の構成を概略的に示す図である。なお、ここでは、代表処理サーバ１００の処理部１の構成について説明するが、代表処理サーバ２００の処理部１についても同一構成であり、その説明を省略する。
【００２４】
処理部１は、スケジュール管理部１Ａと、緊急便対応管理部１Ｂと、起動・停止処理部１Ｃと、等値化処理部１Ｄとによって構成されている。これらのスケジュール管理部１Ａ、緊急便対応管理部１Ｂ、起動・停止処理部１Ｃ、及び、等値化処理部１Ｄの間では、各種情報の授受が行われる。
【００２５】
スケジュール管理部１Ａは、空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理する。より具体的には、スケジュール管理部１Ａは、端末装置４０から送信された基本運用時間スケジュール及び運用時間延長スケジュールに基づいて、運用時間スケジュールを管理する。このようなスケジュール管理部１Ａは、例えば、内部時計を備えており、現在時刻が運用開始時刻になったか否か、あるいは、現在時刻が運用終了時刻になったか否かなどを判断する。
【００２６】
基本運用時間スケジュールは、通常時に空港を運用状態とする運用時間、つまり、運用開始時刻及び運用終了時刻を規定したものである。このような基本運用時間スケジュールは、端末装置４０の入力部４３などを介して監視員によって入力され、例えば、記録部２に保存されている。
【００２７】
運用時間延長スケジュールは、遅延便発生などにより、基本運用時間スケジュールの運用終了時刻が予定よりも延長される場合に、延長後の運用終了時刻を規定したものである。このような運用時間延長スケジュールは、端末装置４０の入力部４３などを介して監視員によって入力され、例えば、記録部２に保存されている（場合によっては、運用開始時刻を前倒しする場合もあり、その場合には、運用時間延長スケジュールは、前倒し後の運用開始時刻を規定したものとなる）。
【００２８】
緊急便対応管理部１Ｂは、空港の運用時間外に緊急便の離着陸に対応するための緊急便対応モードの設定及び解除を管理する。より具体的には、緊急便対応管理部１Ｂは、空港が非運用状態である場合に、端末装置４０から送信された緊急便対応モードの設定指示を受け付け、緊急便対応モードに設定される。また、この緊急便対応管理部１Ｂは、緊急便対応モードに設定された状態において、端末装置４０から送信された緊急便対応モードの解除指示を受け付け、緊急便対応モードから解除される。
【００２９】
起動・停止処理部１Ｃは、スケジュール管理部１Ａにより現在時刻が運用開始時刻（基本運用時間スケジュールで規定された時刻、または、運用時間延長スケジュールで規定された前倒し後の時刻）であると判断された場合に第２監視制御局２０を起動し、また、スケジュール管理部１Ａにより現在時刻が運用終了時刻（基本運用時間スケジュールで規定された時刻、または、運用時間延長スケジュールで規定された延長後の時刻）であると判断された場合に第２監視制御局２０を停止する。
【００３０】
また、この起動・停止処理部１Ｃは、緊急便対応管理部１Ｂにより緊急便対応モードに設定された場合に第２監視制御局２０を起動し、また、緊急便対応管理部１Ｂにより緊急便対応モードが解除された場合に第２監視制御局２０を停止する。
【００３１】
等値化処理部１Ｄは、第１監視制御局１０から第２監視制御局２０へのデータの等値化処理を運用時間内に少なくとも１回行う。より具体的には、等値化処理部１Ｄは、例えば、内部時計を備えており、端末装置４０から送信された等値化スケジュールに基づいて、現在時刻が等値化時刻になった場合に、等値化処理を行う。この等値化処理は、第１監視制御局１０で蓄積されたファイリングデータ（例えば、監視制御対象設備Ｘの故障日時、稼動日時などの動作履歴や、監視制御対象設備Ｘの各種計測データなど）や、各種設定値データ（例えば、空調設備の設定温度などの監視制御対象設備Ｘを監視制御するための各種パラメータなど）を第２監視制御局２０にコピー（等値化）する処理である。
【００３２】
本実施形態では、第１監視制御局１０は、システムを立ち上げてからほぼ常時稼動する「稼動系」に対応し、第２監視制御局２０は、空港の運用状況により要求されるシステム信頼性のレベルに応じて起動・停止する「待機系」に対応する。すなわち、空港が運用状態である場合（つまり、要求されるシステムの信頼性が高レベルである場合）には、第１監視制御局１０に加えて、第２監視制御局２０も起動させて待機状態とし、第１監視制御局１０に障害等が発生した場合に即座に第２監視制御局２０にて自動的に処理が引き継がれる。つまり、運用時は、ホットスタンバイ状態となっている。一方で、空港が非運用状態である場合（つまり、要求されるシステムの信頼性が低レベルである場合）には、第１監視制御局１０が稼動している一方で、第２監視制御局２０は停止している。つまり、非運用時は、コールドスタンバイ状態となっている。
【００３３】
以下に、本実施形態における監視制御システムの動作についてより具体的に説明する。
【００３４】
図３は、本実施形態における監視制御システムの動作を説明するためのフローチャートである。
【００３５】
まず、第１監視制御局１０において、スケジュール管理部１Ａにより、現在時刻が基本運用時間スケジュール（例えば、７：３０〜２０：３０）内の時刻であるか否かが判断される（ステップＳＴ１）。すなわち、スケジュール管理部１Ａは、記録部２に保存されている空港の基本運用時間スケジュールを参照し、内部時計の現在時刻と対比する。ここでは、運用開始時刻が例えば７：３０であり、運用終了時刻が例えば２０：３０である場合について説明する。
【００３６】
スケジュール管理部１Ａにより、現在時刻が基本運用時間スケジュール外の時刻であると判断された場合には（ステップＳＴ１、Ｎｏ）、現在時刻が運用時間延長スケジュール内の時刻であるか否かが判断される（ステップＳＴ２）。すなわち、スケジュール管理部１Ａは、記録部２に運用時間延長スケジュールが保存されているか否かを判断するとともに、運用時間延長スケジュールが保存されている場合にはその運用時間延長スケジュールを参照し、内部時計の現在時刻と対比する。
【００３７】
スケジュール管理部１Ａにより、現在時刻が運用時間延長スケジュール外の時刻であると判断された場合（運用時間延長スケジュールが保存されていない場合も含む）には（ステップＳＴ２、Ｎｏ）、緊急便対応管理部１Ｂにより、緊急便対応モードが設定されているか否かが判断される（ステップＳＴ３）。すなわち、現在時刻が基本運用時間スケジュール外であり且つ運用時間延長スケジュール外である場合には、空港は非運用状態にある。このような状態において、緊急便対応管理部１Ｂは、緊急便対応モードに設定されているか否かを判断する。
【００３８】
スケジュール管理部１Ａにより、現在時刻が基本運用時間スケジュール内の時刻であると判断された場合（ステップＳＴ１、Ｙｅｓ）、あるいは、現在時刻が運用時間延長スケジュール内の時刻であると判断された場合（ステップＳＴ２、Ｙｅｓ）、あるいは、緊急便対応管理部１Ｂにより、緊急便対応モードが設定されていると判断された場合には（ステップＳＴ３、Ｙｅｓ）、空港が運用状態にある場合に相当し、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であるか否かが判断される（ステップＳＴ４）。
【００３９】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中ではないと判断された場合には（ステップＳＴ４、Ｎｏ）、第２監視制御局２０を起動する（ステップＳＴ５）。これにより、空港が運用状態にある場合には、第１監視制御局１０に加えて第２監視制御局２０が起動し、ホットスタンバイ状態となる。
【００４０】
そして、第２監視制御局２０を起動（ステップＳＴ５）した後、あるいは、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であると判断された場合には（ステップＳＴ４、Ｙｅｓ）、等値化処理部１Ｄにより、現在時刻が等値化の設定時刻であるか否かが判断される（ステップＳＴ６）。すなわち、等値化処理部１Ｄは、等値化スケジュールを参照し、内部時計の現在時刻と対比する。
【００４１】
等値化処理部１Ｄにより、現在時刻が等値化の設定時刻であると判断された場合に（ステップＳＴ６、Ｙｅｓ）、等値化処理を行い（ステップＳＴ７）、再びステップＳＴ１に戻る。また、等値化処理部１Ｄにより、現在時刻が等値化の設定時刻ではないと判断された場合にも（ステップＳＴ６、Ｎｏ）、同様に、再びステップＳＴ１に戻る。
【００４２】
一方、緊急便対応管理部１Ｂにより、緊急便対応モードが設定されていないあるいは緊急便対応モードが解除されたと判断された場合には（ステップＳＴ３、Ｎｏ）、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であるか否かが判断される（ステップＳＴ８）。
【００４３】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中ではないと判断された場合には（ステップＳＴ８、Ｎｏ）、再びステップＳＴ１に戻る。また、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であると判断された場合には（ステップＳＴ８、Ｙｅｓ）、第２監視制御局２０を停止する（ＳＴ９）。これにより、空港が非運用状態にある場合には、第１監視制御局１０のみが稼動し、コールドスタンバイ状態となる。
【００４４】
本実施形態によれば、基本運用時間スケジュール、運用時間延長スケジュール、及び、緊急便対応モードの設定の有無により、空港が運用状態にあるか非運用状態にあるかを判断し、運用状態にあるときには第１監視制御局（稼動系）１０のみならず第２監視制御局（待機系）２０を起動しておくことにより、稼動系故障時の速やかな処理引継ぎが可能となる。これにより、システムの信頼性の低下を防止することができる。また、非運用状態にあるときには、第２監視制御局２０を停止しておくことにより、消費電力の低減が可能となる。これにより、システムの運用コストを低減することができる。
【００４５】
また、本実施形態によれば、運用状態にあるときに、第１監視制御局１０から第２監視制御局２０に定期的にデータの等値化処理を行うことにより、待機系である第２監視制御局２０に処理が引き継がれた際に、稼動系である第１監視制御局１０と同等の運用が可能となる。
【００４６】
次に、本実施形態における監視制御システムの第２構成例について説明する。なお、以下に説明する監視制御システムの第２構成例は、図１に示した第１構成例と基本的な構成は同一である。
【００４７】
図４は、監視制御システムの第２構成例において、第１監視制御局１０を構成する代表処理サーバ１００の処理部１の構成を概略的に示す図である。
【００４８】
処理部１は、第１構成例で説明した起動・停止処理部１Ｃ及び等値化処理部１Ｄに加えて、システム状態監視部１Ｅと、ダウン予兆判断部１Ｆと、を備えている。なお、ここでは図示していないが、処理部１は、さらに、第１構成例で説明したスケジュール管理部１Ａ及び緊急便対応管理部１Ｂを備えていても良く、この場合には、第１構成例で説明した動作を組み合わせることが可能である。
【００４９】
システム状態監視部１Ｅは、監視制御システムの状態、つまり、第１監視制御局１０が備える第１サーバ群、第２監視制御局２０が備える第２サーバ群、監視制御局３０、端末装置４０などの状態を監視するのに必要な監視信号を収集する。システム状態監視部１Ｅが収集する監視信号とは、例えば、処理サーバの処理部が備えているＣＰＵの温度（処理部が複数のＣＰＵを備えている場合にはそれぞれのＣＰＵの温度）、ＣＰＵの演算スピード（ＣＰＵが複数のコアを有する場合にはそれぞれのコアの演算スピード）、処理サーバの記録部が備えている揮発性メモリへの書込の可否（記録部が複数の揮発性メモリを備えている場合にはそれぞれの揮発性メモリへの書込の可否）、揮発性メモリの使用率（記録部が複数の揮発性メモリを備えている場合にはそれぞれの揮発性メモリの使用率）、処理サーバが備えている不揮発性メモリへの書込の可否（記録部が複数の不揮発性メモリを備えている場合にはそれぞれの不揮発性メモリへの書込の可否）、不揮発性メモリの空き容量（記録部が複数の不揮発性メモリを備えている場合にはそれぞれの不揮発性メモリの空き容量）、処理サーバの通信部が備えているポートでの通信障害の有無（通信部が複数のポートを備えている場合にはそれぞれのポートでの通信障害の有無）などに関する信号が含まれる。システム状態監視部１Ｅでは、ほぼ常時、監視信号を収集している。
【００５０】
ダウン予兆判断部１Ｆは、システム状態監視部１Ｅによって収集された監視信号に基づいて第１監視制御局１０のダウン（障害発生）の予兆の有無を判断する。また、このダウン予兆判断部１Ｆは、システム状態監視部１Ｅによって収集された監視信号と、端末装置４０の入力部４３などにより設定された閾値とを比較して、ダウンの予兆の有無を判断する場合もある。ここでのダウンの予兆とは、第１監視制御局１０が直ちにダウンする異常ではないが、いずれダウンに至る可能性が極めて高い状態に相当する。
【００５１】
この第２構成例では、第１監視制御局１０の第１サーバ群を構成する各処理サーバは、冗長化されている。例えば、第１処理サーバ１０−１は、処理部１１が複数のＣＰＵを備え、記録部１２が複数の揮発性メモリ及び複数の不揮発性メモリを備え、通信部１３が複数のポートを備えており、他の処理サーバについても同様である。このため、各処理サーバにおいて、例え一つの機器（例えば、２つのＣＰＵのうちの一方のＣＰＵ）に異常が発生したとしても、同等の機能を有する他の機器（例えば、２つのＣＰＵのうちの他方のＣＰＵ）がバックアップするため、直ちにダウンすることはない。しかしながら、このような機器の異常が発生した状態は、いずれ第１監視制御局１０のダウンに至る可能性が極めて高い状態である。
【００５２】
このような第２構成例において、ダウン予兆判断部１Ｆは、ＣＰＵの温度が設定された閾値を超えた場合、ＣＰＵの一つのコアの演算スピードが設定された閾値よりも低下した場合、複数の揮発性メモリのうちの一つの揮発性メモリへの書込が不可となった場合、複数の揮発性メモリのうちの一つの揮発性メモリの使用率が設定された閾値を超えた場合、複数の不揮発性メモリのうちの一つの不揮発性メモリへの書込が不可となった場合、複数の不揮発性メモリのうちの一つの不揮発性メモリの空き容量が設定された閾値よりも低下した場合、複数のポートのうちの一つのポートで通信障害が発生した場合などに、第１監視制御局１０のダウンの予兆が有るものと判断する。
【００５３】
起動・停止処理部１Ｃは、上記の第１構成例と同様に、運用時間内に第２監視制御局２０を起動し、運用時間外に第２監視制御局２０を停止する。また、この起動・停止処理部１Ｃは、運用時間外において、ダウン予兆判断部１Ｆによりダウンの予兆があると判断されたのに基づいて、停止中の第２監視制御局２０を起動する。なお、起動・停止処理部１Ｃは、運用時間内においては第２監視制御局２０を起動しており、ダウン予兆判断部１Ｆによりダウンの予兆があると判断された場合には、第２監視制御局２０を起動した状態を維持する。
【００５４】
等値化処理部１Ｄは、第１監視制御局１０から第２監視制御局２０へのデータの等値化処理を行う。より具体的には、等値化処理部１Ｄは、例えば、内部時計を備えており、端末装置４０から送信された等値化スケジュールに基づいて、現在時刻が等値化時刻になった場合に、等値化処理を行う。具体的な等値化処理については、上記の第１構成例と同様であるため、説明を省略する。
【００５５】
このような本実施形態の第２構成例においても、第１監視制御局１０は、システムを立ち上げてからほぼ常時稼動する「稼動系」に対応し、第２監視制御局２０は、運用時間内に起動して待機状態とし、運用時間外に停止している「待機系」に対応する。
【００５６】
以下に、本実施形態における監視制御システムの動作についてより具体的に説明する。
【００５７】
図５は、本実施形態における監視制御システムの動作を説明するためのフローチャートである。
【００５８】
まず、第１監視制御局（稼動系）１０において、等値化処理部１Ｄは、現在時刻が等値化の設定時刻であるか否かを判断する（ステップＳＴ１１）。すなわち、等値化処理部１Ｄは、等値化スケジュールを参照し、内部時計の現在時刻と対比する。等値化処理部１Ｄにより、現在時刻が等値化の設定時刻であると判断された場合に（ステップＳＴ１１、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０が停止中であるか否かを判断する（ステップＳＴ１２）。
【００５９】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が停止中であると判断された場合には（ステップＳＴ１２、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０を起動する（ステップＳＴ１３）。起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が停止中ではない（つまり、起動中である）と判断された場合（ステップＳＴ１２、Ｎｏ）、あるいは、ステップＳＴ１３において起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が起動された後に、等値化処理部１Ｄは、等値化処理を行う（ステップＳＴ１４）。
【００６０】
等値化処理部１Ｄにより、現在時刻が等値化の設定時刻ではないと判断された場合（ステップＳＴ１１、Ｎｏ）、あるいは、ステップＳＴ１４において等値化処理部１Ｄにより等値化処理が行われた後に、ダウン予兆判断部１Ｆは、システム状態監視部１Ｅによって収集された監視信号に基づいて、監視制御システムにおける異常の有無を判断する（ステップＳＴ１５）。
【００６１】
ダウン予兆判断部１Ｆにより、監視制御システムにおいて異常が発生したと判断された場合には（ステップＳＴ１５、Ｙｅｓ）、ダウン予兆判断部１Ｆは、その異常が第１監視制御局（稼動系）１０のダウンの予兆であるか否かを判断する（ステップＳＴ１６）。ダウン予兆判断部１Ｆにより、ダウンの予兆であると判断された場合には（ステップＳＴ１６、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０が停止中であるか否かを判断する（ステップＳＴ１７）。
【００６２】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が停止中であると判断された場合には（ステップＳＴ１７、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０を起動する（ステップＳＴ１８）。起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が停止中ではない（つまり、起動中である）と判断された場合（ステップＳＴ１７、Ｎｏ）、再びステップＳＴ１１に戻る。これにより、第１監視制御局１０に加えて第２監視制御局２０が起動し、ホットスタンバイ状態となる。
【００６３】
一方、ダウン予兆判断部１Ｆにより、監視制御システムに異常が発生したと判断されたものの第１監視制御局（稼動系）１０のダウンの予兆ではないと判断された場合（例えば、処理サーバのファンの故障、監視制御子局の故障などの異常が発生した場合）には（ステップＳＴ１６、Ｎｏ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０が起動中であるか否かを判断する（ステップＳＴ１９）。
【００６４】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であると判断された場合には（ステップＳＴ１９、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０を停止する（ステップＳＴ２０）。起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が起動中ではない（つまり、停止中である）と判断された場合（ステップＳＴ１９、Ｎｏ）、再びステップＳＴ１１に戻る。これにより、第１監視制御局１０のみが稼動し、コールドスタンバイ状態となる。
【００６５】
このような第２構成例によれば、運用時間内においては、第１監視制御局（稼動系）１０のみならず第２監視制御局（待機系）２０を起動しておくことにより、第１監視制御局１０の障害発生時に、第１監視制御局１０から第２監視制御局２０へと速やかに処理を引継ぐことが可能となる。また、運用時間外においては、第１監視制御局１０が起動している一方で、第２監視制御局２０は停止しているが、第１監視制御局１０にダウンの予兆が有ると判断した場合には第２監視制御局２０を起動しておくことにより、例え第１監視制御局１０に障害が発生したとしても、第１監視制御局１０から第２監視制御局２０へと速やかに処理を引継ぐことが可能となる。したがって、待機系の消費電力の低減が可能となるとともに、システムの信頼性を向上することが可能となる。
【００６６】
また、第１監視制御局１０から第２監視制御局２０に定期的にデータの等値化処理を行うことにより、第２監視制御局２０に処理が引き継がれた際に、第１監視制御局１０と同等の運用が可能となる。
【００６７】
以上説明したように、本実施形態によれば、信頼性の低下を招くことなく、運用コストを低減することが可能な監視制御システムを提供することが可能となる。
【００６８】
なお、この発明は、上記実施形態そのものに限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００６９】
上述した本実施形態において、第１監視制御局１０及び第２監視制御局２０は、同一地域に設置されても良いし、遠隔地に設置されても良い。
【００７０】
また、第１監視制御局１０と第２監視制御局２０との間で運用時間内に等値化処理を行うタイミングや頻度については、特に問わない。等値化処理の頻度が高いほど、第１監視制御局１０に障害が発生した際に第２監視制御局２０に引き継がれるデータ量は多くなり（つまり、失われるデータ量が少なくなり）、第２監視制御局２０において、より第１監視制御局１０と同等の処理が可能となる。
【００７１】
但し、第１監視制御局１０と第２監視制御局２０とが遠隔地に設置された場合、等値化処理の際にネットワークに多大な負荷がかかるおそれがある。このため、等値化処理を行うタイミングや頻度については、ネットワークの負荷を考慮して適宜設定されることが望ましい。
【符号の説明】
【００７２】
１０…第１監視制御局
１００…代表処理サーバ
１…処理部
１Ａ…スケジュール管理部
１Ｂ…緊急便対応管理部
１Ｃ…起動・停止処理部
１Ｄ…等値化処理部
１Ｅ…システム状態監視部
１Ｆ…ダウン予兆判断部
２…記録部
３…通信部
１０−１〜１０−ｎ…処理サーバ
２０…第２監視制御局
３０…監視制御子局
４０…端末装置
【技術分野】
【０００１】
本発明の実施形態は、監視制御システムに関する。
【背景技術】
【０００２】
従来、空港内に設置された各種監視制御対象設備、例えば、灯火設備、受変電設備、発電設備、無停電電源設備、空調設備等を監視制御する監視制御システムが導入されている。このような監視制御システムについては、障害対策として、同じ構成の装置を予め２系統用意しておき、冗長化されることが望ましい。
【０００３】
監視制御システムの冗長化方式としては、ホットスタンバイ方式及びコールドスタンバイ方式が知られている。ホットスタンバイ方式は、一方の系（稼動系）を作動させ、他方の系（待機系）は稼動系と同じ動作を行いながら待機状態としておき、稼動系に障害が発生すると即座に待機系に処理を引き継ぐ方式である。コールドスタンバイ方式は、一方の系（稼動系）を作動させ、他方の系（待機系）は電源を停止しておき、稼動系に障害が発生してから、待機系を起動して処理を引き継ぐ方式である。
【０００４】
ホットスタンバイ方式の場合、稼動系に加えて待機系の電力を常に消費するために、これらの稼動系及び待機系がそれぞれ複数のサーバ群で構成される大規模システムになる程、消費電力が増大し、運用コストの増大を招くといった課題がある。コールドスタンバイ方式の場合、稼動系に障害が発生した場合に、稼動系で蓄積したデータを速やかに待機系に引き継ぐことができず、待機系の起動に際して長い起動時間を要するため、監視制御機能の停止時間が長く、信頼性の低下を招くといった課題がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−６０８０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本実施形態の目的は、信頼性の低下を招くことなく、運用コストを低減することが可能な監視制御システムを提供することにある。
【課題を解決するための手段】
【０００７】
本実施形態によれば、
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、前記第１監視制御局は、空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理するスケジュール管理部と、前記スケジュール管理部により運用開始時刻であると判断された場合に前記第２監視制御局を起動し、前記スケジュール管理部により運用終了時刻であると判断された場合に前記第２監視制御局を停止する起動・停止処理部と、を備えたことを特徴とする監視制御システムが提供される。
【０００８】
本実施形態によれば、
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、前記第１監視制御局は、監視制御システムの状態を監視するのに必要な監視信号を収集するシステム状態監視部と、前記システム状態監視部によって収集された監視信号に基づいて前記第１監視制御局のダウンの予兆の有無を判断するダウン予兆判断部と、運用時間内に前記第２監視制御局を起動し、運用時間外に前記第２監視制御局を停止するとともに、運用時間外において、前記ダウン予兆判断部によりダウンの予兆があると判断されたのに基づいて停止中の前記第２監視制御局を起動する起動・停止処理部と、を備えたことを特徴とする監視制御システムが提供される。
【図面の簡単な説明】
【０００９】
【図１】図１は、本実施形態における監視制御システムの構成を概略的に示す図である。
【図２】図２は、図１に示した代表処理サーバの処理部の構成を概略的に示す図である。
【図３】図３は、本実施形態における監視制御システムの動作を説明するためのフローチャートである。
【図４】図４は、監視制御システムの第２構成例において、第１監視制御局を構成する代表処理サーバの処理部の構成を概略的に示す図である。
【図５】図５は、監視制御システムの第２構成例における動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本実施形態について、図面を参照しながら詳細に説明する。なお、各図において、同一又は類似した機能を発揮する構成要素には同一の参照符号を付し、重複する説明は省略する。
【００１１】
図１は、本実施形態における監視制御システムの第１構成例を概略的に示す図である。
【００１２】
すなわち、本監視制御システムは、空港内に設置された灯火設備、受変電設備、発電設備、無停電電源設備、空調設備等の各種監視制御対象設備Ｘを監視制御するものである。このような監視制御システムは、第１監視制御局１０、及び、第２監視制御局２０を備えている。これらの第１監視制御局１０及び第２監視制御局２０は、ネットワークを介して接続されている。また、これらの第１監視制御局１０及び第２監視制御局２０には、ネットワークを介して、監視制御子局３０…、端末装置４０…などが接続されている。
【００１３】
監視制御子局３０は、監視制御対象設備Ｘとの間で監視制御信号を授受する。このような監視制御子局３０は、監視制御対象設備Ｘの個数に応じて１個以上設置されている。監視制御子局３０と監視制御対象設備Ｘとの間での監視制御信号の授受には、例えば、監視制御子局３０が監視制御対象設備Ｘにおける電流、電圧、温度などの各種計測データを受信することや、監視制御子局３０が監視制御対象設備Ｘにおける故障などの状態変化を検出することなどが含まれる。
【００１４】
例えば、監視制御対象設備Ｘの状態変化の検出は、以下のようにして行われる。監視制御対象設備Ｘは、監視制御項目に応じた個数の接点を有している。これらの接点のそれぞれは、監視制御子局３０の入力基板に電気的に接続されている。監視制御対象設備Ｘにおいて、故障などの状態変化が生じた場合には、対応する接点が閉じ、電気的な閉回路が形成される。この例では、閉回路を流れる電気が上記の監視制御信号に相当する。監視制御子局３０では、閉回路に電気が流れた際に、監視制御対象設備Ｘにおいて状態変化が発生した監視制御項目が判断される。
【００１５】
また、この監視制御子局３０は、第１監視制御局１０との間で監視制御信号を授受する。第１監視制御局１０と監視制御子局３０との間での監視制御信号の授受には、例えば、第１監視制御局１０が監視制御子局３０から監視制御対象設備Ｘの各種計測データや監視制御対象設備Ｘの状態変化の履歴を受信することなどが含まれる。なお、監視制御子局３０は、第１監視制御局１０及び第２監視制御局２０との双方の間で監視制御信号を授受しても良い。第１監視制御局１０に障害が発生した場合等には、監視制御子局３０は、第２監視制御局２０との間で監視制御信号を授受する。
【００１６】
端末装置４０は、監視員に情報提供を行ったり、監視員による操作入力を受け付けたりするものである。この端末装置４０は、第１監視制御局１０との間で各種情報を授受する。第１監視制御局１０と端末装置４０との間での情報の授受には、例えば、端末装置４０が第１監視制御局１０から監視制御対象設備Ｘの各種計測データや監視制御対象設備Ｘの状態変化の履歴を受信すること、第１監視制御局１０が端末装置４０から入力された情報を受信することなどが含まれる。なお、端末装置４０は、第１監視制御局１０及び第２監視制御局２０との双方の間で監視制御信号を授受しても良い。第１監視制御局１０に障害が発生した場合等には、端末装置４０は、第２監視制御局２０との間で各種情報を授受する。
【００１７】
このような端末装置４０は、１個以上設置されている。端末装置４０は、処理部４１、記録部４２、入力部４３、表示部４４、通信部４５などを備えて構成されている。処理部４１は、各種演算処理を行うものである。記録部４２は、各種データを蓄積するものである。入力部４３は、監視員による操作入力、具体的には、後述する空港の運用開始時刻及び運用終了時刻を規定する運用時間スケジュール（基本運用時間スケジュール及び運用時間延長スケジュールを含む）の入力、緊急便の離着陸に対応するための緊急便対応モードの設定操作及び解除操作、第１監視制御局１０から第２監視制御局２０へのデータの等値化処理を行う等値化スケジュールの入力、後述する第２構成例においてダウンの予兆の有無を判断するのに必要な閾値の設定などを受け付ける。表示部４４は、入力部４３を介して入力された情報、第１監視制御局１０や第２監視制御局２０から受信した情報（監視制御対象設備Ｘの計測データや状態変化の履歴などを含む）などを表示する。通信部４５は、ネットワーク経由で第１監視制御局１０や第２監視制御局２０などと情報を授受する。
【００１８】
第１監視制御局１０及び第２監視制御局２０は、監視制御子局３０との間で授受される監視制御信号を処理・蓄積し各種演算処理を行う。また、これらの第１監視制御局１０及び第２監視制御局２０は、端末装置４０との間で授受される各種情報を処理・蓄積し各種演算処理を行う。
【００１９】
第１監視制御局１０は、第１サーバ群を備えている。この第１サーバ群は、各種処理を行うための複数のサーバ群、すなわち、第１処理サーバ１０−１、…第ｎ処理サーバ１０−ｎと、それらを統括する代表処理サーバ１００とで構成されている（但し、ｎは正の整数である）。これらの第１処理サーバ１０−１乃至第ｎ処理サーバ１０−ｎは、例えば、アプリケーションサーバ、データベースサーバ、ＷＥＢサーバなどである。
第２監視制御局２０は、第１サーバ群と同等構成の第２サーバ群（第１処理サーバ２０−１、…第ｎ処理サーバ２０−ｎ、及び、代表処理サーバ２００）を備えている。
【００２０】
このような構成の第１監視制御局１０及び第２監視制御局２０は、監視制御子局３０に対して、「親局」と称される場合がある。本実施形態における監視制御システムは、これらの２つの親局により冗長化されている。なお、ここに示す例に限らず、親局は、３つ以上設置されても良い。
【００２１】
第１監視制御局１０の代表処理サーバ１００と、第２監視制御局２０の代表処理サーバ２００とは、同一構成であり、同一機能を有している。ここでは、代表処理サーバ１００の構成について説明し、代表処理サーバ２００の説明は省略する。代表処理サーバ１００は、処理部１、記録部２、通信部３などを備えて構成されている。処理部１は、各種演算処理を行うものであり、その詳細については後述する。記録部２は、各種データを蓄積するものである。通信部３は、ネットワーク経由で監視制御子局３０や端末装置４０などと情報を授受する。この代表処理サーバ１００は、第１処理サーバ１０−１乃至第ｎ処理サーバ１０−ｎとの間でも情報の授受を行う。
【００２２】
第１監視制御局１０の第１処理サーバ１０−１乃至第ｎ処理サーバ１０−ｎと、第２監視制御局２０の第１処理サーバ２０−１乃至第ｎ処理サーバ２０−ｎとは、同一構成である。ここでは、第１処理サーバ１０−１の構成について説明し、他の処理サーバの説明は省略する。第１処理サーバ１０−１は、処理部１１、記録部１２、通信部１３などを備えて構成されている。処理部１１は、各種演算処理を行うものである。記録部１２は、各種データを蓄積するものである。通信部１３は、ネットワーク経由で監視制御子局３０や端末装置４０などと情報を授受する。
【００２３】
図２は、図１に示した代表処理サーバの処理部の構成を概略的に示す図である。なお、ここでは、代表処理サーバ１００の処理部１の構成について説明するが、代表処理サーバ２００の処理部１についても同一構成であり、その説明を省略する。
【００２４】
処理部１は、スケジュール管理部１Ａと、緊急便対応管理部１Ｂと、起動・停止処理部１Ｃと、等値化処理部１Ｄとによって構成されている。これらのスケジュール管理部１Ａ、緊急便対応管理部１Ｂ、起動・停止処理部１Ｃ、及び、等値化処理部１Ｄの間では、各種情報の授受が行われる。
【００２５】
スケジュール管理部１Ａは、空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理する。より具体的には、スケジュール管理部１Ａは、端末装置４０から送信された基本運用時間スケジュール及び運用時間延長スケジュールに基づいて、運用時間スケジュールを管理する。このようなスケジュール管理部１Ａは、例えば、内部時計を備えており、現在時刻が運用開始時刻になったか否か、あるいは、現在時刻が運用終了時刻になったか否かなどを判断する。
【００２６】
基本運用時間スケジュールは、通常時に空港を運用状態とする運用時間、つまり、運用開始時刻及び運用終了時刻を規定したものである。このような基本運用時間スケジュールは、端末装置４０の入力部４３などを介して監視員によって入力され、例えば、記録部２に保存されている。
【００２７】
運用時間延長スケジュールは、遅延便発生などにより、基本運用時間スケジュールの運用終了時刻が予定よりも延長される場合に、延長後の運用終了時刻を規定したものである。このような運用時間延長スケジュールは、端末装置４０の入力部４３などを介して監視員によって入力され、例えば、記録部２に保存されている（場合によっては、運用開始時刻を前倒しする場合もあり、その場合には、運用時間延長スケジュールは、前倒し後の運用開始時刻を規定したものとなる）。
【００２８】
緊急便対応管理部１Ｂは、空港の運用時間外に緊急便の離着陸に対応するための緊急便対応モードの設定及び解除を管理する。より具体的には、緊急便対応管理部１Ｂは、空港が非運用状態である場合に、端末装置４０から送信された緊急便対応モードの設定指示を受け付け、緊急便対応モードに設定される。また、この緊急便対応管理部１Ｂは、緊急便対応モードに設定された状態において、端末装置４０から送信された緊急便対応モードの解除指示を受け付け、緊急便対応モードから解除される。
【００２９】
起動・停止処理部１Ｃは、スケジュール管理部１Ａにより現在時刻が運用開始時刻（基本運用時間スケジュールで規定された時刻、または、運用時間延長スケジュールで規定された前倒し後の時刻）であると判断された場合に第２監視制御局２０を起動し、また、スケジュール管理部１Ａにより現在時刻が運用終了時刻（基本運用時間スケジュールで規定された時刻、または、運用時間延長スケジュールで規定された延長後の時刻）であると判断された場合に第２監視制御局２０を停止する。
【００３０】
また、この起動・停止処理部１Ｃは、緊急便対応管理部１Ｂにより緊急便対応モードに設定された場合に第２監視制御局２０を起動し、また、緊急便対応管理部１Ｂにより緊急便対応モードが解除された場合に第２監視制御局２０を停止する。
【００３１】
等値化処理部１Ｄは、第１監視制御局１０から第２監視制御局２０へのデータの等値化処理を運用時間内に少なくとも１回行う。より具体的には、等値化処理部１Ｄは、例えば、内部時計を備えており、端末装置４０から送信された等値化スケジュールに基づいて、現在時刻が等値化時刻になった場合に、等値化処理を行う。この等値化処理は、第１監視制御局１０で蓄積されたファイリングデータ（例えば、監視制御対象設備Ｘの故障日時、稼動日時などの動作履歴や、監視制御対象設備Ｘの各種計測データなど）や、各種設定値データ（例えば、空調設備の設定温度などの監視制御対象設備Ｘを監視制御するための各種パラメータなど）を第２監視制御局２０にコピー（等値化）する処理である。
【００３２】
本実施形態では、第１監視制御局１０は、システムを立ち上げてからほぼ常時稼動する「稼動系」に対応し、第２監視制御局２０は、空港の運用状況により要求されるシステム信頼性のレベルに応じて起動・停止する「待機系」に対応する。すなわち、空港が運用状態である場合（つまり、要求されるシステムの信頼性が高レベルである場合）には、第１監視制御局１０に加えて、第２監視制御局２０も起動させて待機状態とし、第１監視制御局１０に障害等が発生した場合に即座に第２監視制御局２０にて自動的に処理が引き継がれる。つまり、運用時は、ホットスタンバイ状態となっている。一方で、空港が非運用状態である場合（つまり、要求されるシステムの信頼性が低レベルである場合）には、第１監視制御局１０が稼動している一方で、第２監視制御局２０は停止している。つまり、非運用時は、コールドスタンバイ状態となっている。
【００３３】
以下に、本実施形態における監視制御システムの動作についてより具体的に説明する。
【００３４】
図３は、本実施形態における監視制御システムの動作を説明するためのフローチャートである。
【００３５】
まず、第１監視制御局１０において、スケジュール管理部１Ａにより、現在時刻が基本運用時間スケジュール（例えば、７：３０〜２０：３０）内の時刻であるか否かが判断される（ステップＳＴ１）。すなわち、スケジュール管理部１Ａは、記録部２に保存されている空港の基本運用時間スケジュールを参照し、内部時計の現在時刻と対比する。ここでは、運用開始時刻が例えば７：３０であり、運用終了時刻が例えば２０：３０である場合について説明する。
【００３６】
スケジュール管理部１Ａにより、現在時刻が基本運用時間スケジュール外の時刻であると判断された場合には（ステップＳＴ１、Ｎｏ）、現在時刻が運用時間延長スケジュール内の時刻であるか否かが判断される（ステップＳＴ２）。すなわち、スケジュール管理部１Ａは、記録部２に運用時間延長スケジュールが保存されているか否かを判断するとともに、運用時間延長スケジュールが保存されている場合にはその運用時間延長スケジュールを参照し、内部時計の現在時刻と対比する。
【００３７】
スケジュール管理部１Ａにより、現在時刻が運用時間延長スケジュール外の時刻であると判断された場合（運用時間延長スケジュールが保存されていない場合も含む）には（ステップＳＴ２、Ｎｏ）、緊急便対応管理部１Ｂにより、緊急便対応モードが設定されているか否かが判断される（ステップＳＴ３）。すなわち、現在時刻が基本運用時間スケジュール外であり且つ運用時間延長スケジュール外である場合には、空港は非運用状態にある。このような状態において、緊急便対応管理部１Ｂは、緊急便対応モードに設定されているか否かを判断する。
【００３８】
スケジュール管理部１Ａにより、現在時刻が基本運用時間スケジュール内の時刻であると判断された場合（ステップＳＴ１、Ｙｅｓ）、あるいは、現在時刻が運用時間延長スケジュール内の時刻であると判断された場合（ステップＳＴ２、Ｙｅｓ）、あるいは、緊急便対応管理部１Ｂにより、緊急便対応モードが設定されていると判断された場合には（ステップＳＴ３、Ｙｅｓ）、空港が運用状態にある場合に相当し、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であるか否かが判断される（ステップＳＴ４）。
【００３９】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中ではないと判断された場合には（ステップＳＴ４、Ｎｏ）、第２監視制御局２０を起動する（ステップＳＴ５）。これにより、空港が運用状態にある場合には、第１監視制御局１０に加えて第２監視制御局２０が起動し、ホットスタンバイ状態となる。
【００４０】
そして、第２監視制御局２０を起動（ステップＳＴ５）した後、あるいは、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であると判断された場合には（ステップＳＴ４、Ｙｅｓ）、等値化処理部１Ｄにより、現在時刻が等値化の設定時刻であるか否かが判断される（ステップＳＴ６）。すなわち、等値化処理部１Ｄは、等値化スケジュールを参照し、内部時計の現在時刻と対比する。
【００４１】
等値化処理部１Ｄにより、現在時刻が等値化の設定時刻であると判断された場合に（ステップＳＴ６、Ｙｅｓ）、等値化処理を行い（ステップＳＴ７）、再びステップＳＴ１に戻る。また、等値化処理部１Ｄにより、現在時刻が等値化の設定時刻ではないと判断された場合にも（ステップＳＴ６、Ｎｏ）、同様に、再びステップＳＴ１に戻る。
【００４２】
一方、緊急便対応管理部１Ｂにより、緊急便対応モードが設定されていないあるいは緊急便対応モードが解除されたと判断された場合には（ステップＳＴ３、Ｎｏ）、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であるか否かが判断される（ステップＳＴ８）。
【００４３】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中ではないと判断された場合には（ステップＳＴ８、Ｎｏ）、再びステップＳＴ１に戻る。また、起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であると判断された場合には（ステップＳＴ８、Ｙｅｓ）、第２監視制御局２０を停止する（ＳＴ９）。これにより、空港が非運用状態にある場合には、第１監視制御局１０のみが稼動し、コールドスタンバイ状態となる。
【００４４】
本実施形態によれば、基本運用時間スケジュール、運用時間延長スケジュール、及び、緊急便対応モードの設定の有無により、空港が運用状態にあるか非運用状態にあるかを判断し、運用状態にあるときには第１監視制御局（稼動系）１０のみならず第２監視制御局（待機系）２０を起動しておくことにより、稼動系故障時の速やかな処理引継ぎが可能となる。これにより、システムの信頼性の低下を防止することができる。また、非運用状態にあるときには、第２監視制御局２０を停止しておくことにより、消費電力の低減が可能となる。これにより、システムの運用コストを低減することができる。
【００４５】
また、本実施形態によれば、運用状態にあるときに、第１監視制御局１０から第２監視制御局２０に定期的にデータの等値化処理を行うことにより、待機系である第２監視制御局２０に処理が引き継がれた際に、稼動系である第１監視制御局１０と同等の運用が可能となる。
【００４６】
次に、本実施形態における監視制御システムの第２構成例について説明する。なお、以下に説明する監視制御システムの第２構成例は、図１に示した第１構成例と基本的な構成は同一である。
【００４７】
図４は、監視制御システムの第２構成例において、第１監視制御局１０を構成する代表処理サーバ１００の処理部１の構成を概略的に示す図である。
【００４８】
処理部１は、第１構成例で説明した起動・停止処理部１Ｃ及び等値化処理部１Ｄに加えて、システム状態監視部１Ｅと、ダウン予兆判断部１Ｆと、を備えている。なお、ここでは図示していないが、処理部１は、さらに、第１構成例で説明したスケジュール管理部１Ａ及び緊急便対応管理部１Ｂを備えていても良く、この場合には、第１構成例で説明した動作を組み合わせることが可能である。
【００４９】
システム状態監視部１Ｅは、監視制御システムの状態、つまり、第１監視制御局１０が備える第１サーバ群、第２監視制御局２０が備える第２サーバ群、監視制御局３０、端末装置４０などの状態を監視するのに必要な監視信号を収集する。システム状態監視部１Ｅが収集する監視信号とは、例えば、処理サーバの処理部が備えているＣＰＵの温度（処理部が複数のＣＰＵを備えている場合にはそれぞれのＣＰＵの温度）、ＣＰＵの演算スピード（ＣＰＵが複数のコアを有する場合にはそれぞれのコアの演算スピード）、処理サーバの記録部が備えている揮発性メモリへの書込の可否（記録部が複数の揮発性メモリを備えている場合にはそれぞれの揮発性メモリへの書込の可否）、揮発性メモリの使用率（記録部が複数の揮発性メモリを備えている場合にはそれぞれの揮発性メモリの使用率）、処理サーバが備えている不揮発性メモリへの書込の可否（記録部が複数の不揮発性メモリを備えている場合にはそれぞれの不揮発性メモリへの書込の可否）、不揮発性メモリの空き容量（記録部が複数の不揮発性メモリを備えている場合にはそれぞれの不揮発性メモリの空き容量）、処理サーバの通信部が備えているポートでの通信障害の有無（通信部が複数のポートを備えている場合にはそれぞれのポートでの通信障害の有無）などに関する信号が含まれる。システム状態監視部１Ｅでは、ほぼ常時、監視信号を収集している。
【００５０】
ダウン予兆判断部１Ｆは、システム状態監視部１Ｅによって収集された監視信号に基づいて第１監視制御局１０のダウン（障害発生）の予兆の有無を判断する。また、このダウン予兆判断部１Ｆは、システム状態監視部１Ｅによって収集された監視信号と、端末装置４０の入力部４３などにより設定された閾値とを比較して、ダウンの予兆の有無を判断する場合もある。ここでのダウンの予兆とは、第１監視制御局１０が直ちにダウンする異常ではないが、いずれダウンに至る可能性が極めて高い状態に相当する。
【００５１】
この第２構成例では、第１監視制御局１０の第１サーバ群を構成する各処理サーバは、冗長化されている。例えば、第１処理サーバ１０−１は、処理部１１が複数のＣＰＵを備え、記録部１２が複数の揮発性メモリ及び複数の不揮発性メモリを備え、通信部１３が複数のポートを備えており、他の処理サーバについても同様である。このため、各処理サーバにおいて、例え一つの機器（例えば、２つのＣＰＵのうちの一方のＣＰＵ）に異常が発生したとしても、同等の機能を有する他の機器（例えば、２つのＣＰＵのうちの他方のＣＰＵ）がバックアップするため、直ちにダウンすることはない。しかしながら、このような機器の異常が発生した状態は、いずれ第１監視制御局１０のダウンに至る可能性が極めて高い状態である。
【００５２】
このような第２構成例において、ダウン予兆判断部１Ｆは、ＣＰＵの温度が設定された閾値を超えた場合、ＣＰＵの一つのコアの演算スピードが設定された閾値よりも低下した場合、複数の揮発性メモリのうちの一つの揮発性メモリへの書込が不可となった場合、複数の揮発性メモリのうちの一つの揮発性メモリの使用率が設定された閾値を超えた場合、複数の不揮発性メモリのうちの一つの不揮発性メモリへの書込が不可となった場合、複数の不揮発性メモリのうちの一つの不揮発性メモリの空き容量が設定された閾値よりも低下した場合、複数のポートのうちの一つのポートで通信障害が発生した場合などに、第１監視制御局１０のダウンの予兆が有るものと判断する。
【００５３】
起動・停止処理部１Ｃは、上記の第１構成例と同様に、運用時間内に第２監視制御局２０を起動し、運用時間外に第２監視制御局２０を停止する。また、この起動・停止処理部１Ｃは、運用時間外において、ダウン予兆判断部１Ｆによりダウンの予兆があると判断されたのに基づいて、停止中の第２監視制御局２０を起動する。なお、起動・停止処理部１Ｃは、運用時間内においては第２監視制御局２０を起動しており、ダウン予兆判断部１Ｆによりダウンの予兆があると判断された場合には、第２監視制御局２０を起動した状態を維持する。
【００５４】
等値化処理部１Ｄは、第１監視制御局１０から第２監視制御局２０へのデータの等値化処理を行う。より具体的には、等値化処理部１Ｄは、例えば、内部時計を備えており、端末装置４０から送信された等値化スケジュールに基づいて、現在時刻が等値化時刻になった場合に、等値化処理を行う。具体的な等値化処理については、上記の第１構成例と同様であるため、説明を省略する。
【００５５】
このような本実施形態の第２構成例においても、第１監視制御局１０は、システムを立ち上げてからほぼ常時稼動する「稼動系」に対応し、第２監視制御局２０は、運用時間内に起動して待機状態とし、運用時間外に停止している「待機系」に対応する。
【００５６】
以下に、本実施形態における監視制御システムの動作についてより具体的に説明する。
【００５７】
図５は、本実施形態における監視制御システムの動作を説明するためのフローチャートである。
【００５８】
まず、第１監視制御局（稼動系）１０において、等値化処理部１Ｄは、現在時刻が等値化の設定時刻であるか否かを判断する（ステップＳＴ１１）。すなわち、等値化処理部１Ｄは、等値化スケジュールを参照し、内部時計の現在時刻と対比する。等値化処理部１Ｄにより、現在時刻が等値化の設定時刻であると判断された場合に（ステップＳＴ１１、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０が停止中であるか否かを判断する（ステップＳＴ１２）。
【００５９】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が停止中であると判断された場合には（ステップＳＴ１２、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０を起動する（ステップＳＴ１３）。起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が停止中ではない（つまり、起動中である）と判断された場合（ステップＳＴ１２、Ｎｏ）、あるいは、ステップＳＴ１３において起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が起動された後に、等値化処理部１Ｄは、等値化処理を行う（ステップＳＴ１４）。
【００６０】
等値化処理部１Ｄにより、現在時刻が等値化の設定時刻ではないと判断された場合（ステップＳＴ１１、Ｎｏ）、あるいは、ステップＳＴ１４において等値化処理部１Ｄにより等値化処理が行われた後に、ダウン予兆判断部１Ｆは、システム状態監視部１Ｅによって収集された監視信号に基づいて、監視制御システムにおける異常の有無を判断する（ステップＳＴ１５）。
【００６１】
ダウン予兆判断部１Ｆにより、監視制御システムにおいて異常が発生したと判断された場合には（ステップＳＴ１５、Ｙｅｓ）、ダウン予兆判断部１Ｆは、その異常が第１監視制御局（稼動系）１０のダウンの予兆であるか否かを判断する（ステップＳＴ１６）。ダウン予兆判断部１Ｆにより、ダウンの予兆であると判断された場合には（ステップＳＴ１６、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０が停止中であるか否かを判断する（ステップＳＴ１７）。
【００６２】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が停止中であると判断された場合には（ステップＳＴ１７、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０を起動する（ステップＳＴ１８）。起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が停止中ではない（つまり、起動中である）と判断された場合（ステップＳＴ１７、Ｎｏ）、再びステップＳＴ１１に戻る。これにより、第１監視制御局１０に加えて第２監視制御局２０が起動し、ホットスタンバイ状態となる。
【００６３】
一方、ダウン予兆判断部１Ｆにより、監視制御システムに異常が発生したと判断されたものの第１監視制御局（稼動系）１０のダウンの予兆ではないと判断された場合（例えば、処理サーバのファンの故障、監視制御子局の故障などの異常が発生した場合）には（ステップＳＴ１６、Ｎｏ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０が起動中であるか否かを判断する（ステップＳＴ１９）。
【００６４】
起動・停止処理部１Ｃにより、第２監視制御局（待機系）２０が起動中であると判断された場合には（ステップＳＴ１９、Ｙｅｓ）、起動・停止処理部１Ｃは、第２監視制御局（待機系）２０を停止する（ステップＳＴ２０）。起動・停止処理部１Ｃにより第２監視制御局（待機系）２０が起動中ではない（つまり、停止中である）と判断された場合（ステップＳＴ１９、Ｎｏ）、再びステップＳＴ１１に戻る。これにより、第１監視制御局１０のみが稼動し、コールドスタンバイ状態となる。
【００６５】
このような第２構成例によれば、運用時間内においては、第１監視制御局（稼動系）１０のみならず第２監視制御局（待機系）２０を起動しておくことにより、第１監視制御局１０の障害発生時に、第１監視制御局１０から第２監視制御局２０へと速やかに処理を引継ぐことが可能となる。また、運用時間外においては、第１監視制御局１０が起動している一方で、第２監視制御局２０は停止しているが、第１監視制御局１０にダウンの予兆が有ると判断した場合には第２監視制御局２０を起動しておくことにより、例え第１監視制御局１０に障害が発生したとしても、第１監視制御局１０から第２監視制御局２０へと速やかに処理を引継ぐことが可能となる。したがって、待機系の消費電力の低減が可能となるとともに、システムの信頼性を向上することが可能となる。
【００６６】
また、第１監視制御局１０から第２監視制御局２０に定期的にデータの等値化処理を行うことにより、第２監視制御局２０に処理が引き継がれた際に、第１監視制御局１０と同等の運用が可能となる。
【００６７】
以上説明したように、本実施形態によれば、信頼性の低下を招くことなく、運用コストを低減することが可能な監視制御システムを提供することが可能となる。
【００６８】
なお、この発明は、上記実施形態そのものに限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００６９】
上述した本実施形態において、第１監視制御局１０及び第２監視制御局２０は、同一地域に設置されても良いし、遠隔地に設置されても良い。
【００７０】
また、第１監視制御局１０と第２監視制御局２０との間で運用時間内に等値化処理を行うタイミングや頻度については、特に問わない。等値化処理の頻度が高いほど、第１監視制御局１０に障害が発生した際に第２監視制御局２０に引き継がれるデータ量は多くなり（つまり、失われるデータ量が少なくなり）、第２監視制御局２０において、より第１監視制御局１０と同等の処理が可能となる。
【００７１】
但し、第１監視制御局１０と第２監視制御局２０とが遠隔地に設置された場合、等値化処理の際にネットワークに多大な負荷がかかるおそれがある。このため、等値化処理を行うタイミングや頻度については、ネットワークの負荷を考慮して適宜設定されることが望ましい。
【符号の説明】
【００７２】
１０…第１監視制御局
１００…代表処理サーバ
１…処理部
１Ａ…スケジュール管理部
１Ｂ…緊急便対応管理部
１Ｃ…起動・停止処理部
１Ｄ…等値化処理部
１Ｅ…システム状態監視部
１Ｆ…ダウン予兆判断部
２…記録部
３…通信部
１０−１〜１０−ｎ…処理サーバ
２０…第２監視制御局
３０…監視制御子局
４０…端末装置
【特許請求の範囲】
【請求項１】
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、
前記第１監視制御局は、
空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理するスケジュール管理部と、
前記スケジュール管理部により運用開始時刻であると判断された場合に前記第２監視制御局を起動し、前記スケジュール管理部により運用終了時刻であると判断された場合に前記第２監視制御局を停止する起動・停止処理部と、
を備えたことを特徴とする監視制御システム。
【請求項２】
前記スケジュール管理部は、基本運用時間スケジュール、及び、前記基本運用時間スケジュールから延長された運用時間延長スケジュールに基づいて、前記運用時間スケジュールを管理することを特徴とする請求項１に記載の監視制御システム。
【請求項３】
前記第１監視制御局は、さらに、緊急便の離着陸に対応するための緊急便対応モードの設定及び解除を管理する緊急便対応管理部を備え、
前記起動・停止処理部は、前記緊急便対応管理部により緊急便対応モードに設定された場合に前記第２監視制御局を起動し、前記緊急便対応管理部により緊急便対応モードが解除された場合に前記第２監視制御局を停止することを特徴とする請求項１または２に記載の監視制御システム。
【請求項４】
前記第１監視制御局は、さらに、前記第１監視制御局から前記第２監視制御局へのデータの等値化処理を運用時間内に少なくとも１回行う等値化処理部を備えたことを特徴とする請求項１乃至３のいずれか１項に記載の監視制御システム。
【請求項５】
前記第１監視制御局は、さらに、監視制御システムの状態を監視するのに必要な監視信号を収集するシステム状態監視部と、前記システム状態監視部によって収集された監視信号に基づいて前記第１監視制御局のダウンの予兆の有無を判断するダウン予兆判断部と、を備え、
前記起動・停止処理部は、前記ダウン予兆判断部によりダウンの予兆があると判断されたのに基づいて、停止中の前記第２監視制御局を起動することを特徴とする請求項１乃至４のいずれか１項に記載の監視制御システム。
【請求項６】
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、
前記第１監視制御局は、
監視制御システムの状態を監視するのに必要な監視信号を収集するシステム状態監視部と、
前記システム状態監視部によって収集された監視信号に基づいて前記第１監視制御局のダウンの予兆の有無を判断するダウン予兆判断部と、
運用時間内に前記第２監視制御局を起動し、運用時間外に前記第２監視制御局を停止するとともに、運用時間外において、前記ダウン予兆判断部によりダウンの予兆があると判断されたのに基づいて停止中の前記第２監視制御局を起動する起動・停止処理部と、
を備えたことを特徴とする監視制御システム。
【請求項７】
さらに、前記ダウン予兆判断部によりダウンの予兆の有無を判断するのに必要な閾値の設定を受け付ける入力部を備え、
前記ダウン予兆判断部は、前記入力部により設定された閾値と前記システム状態監視部によって収集された監視信号とを比較して、ダウンの予兆の有無を判断することを特徴とする請求項５または６に記載の監視制御システム。
【請求項１】
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、
前記第１監視制御局は、
空港の運用開始時刻及び運用終了時刻を規定した運用時間スケジュールを管理するスケジュール管理部と、
前記スケジュール管理部により運用開始時刻であると判断された場合に前記第２監視制御局を起動し、前記スケジュール管理部により運用終了時刻であると判断された場合に前記第２監視制御局を停止する起動・停止処理部と、
を備えたことを特徴とする監視制御システム。
【請求項２】
前記スケジュール管理部は、基本運用時間スケジュール、及び、前記基本運用時間スケジュールから延長された運用時間延長スケジュールに基づいて、前記運用時間スケジュールを管理することを特徴とする請求項１に記載の監視制御システム。
【請求項３】
前記第１監視制御局は、さらに、緊急便の離着陸に対応するための緊急便対応モードの設定及び解除を管理する緊急便対応管理部を備え、
前記起動・停止処理部は、前記緊急便対応管理部により緊急便対応モードに設定された場合に前記第２監視制御局を起動し、前記緊急便対応管理部により緊急便対応モードが解除された場合に前記第２監視制御局を停止することを特徴とする請求項１または２に記載の監視制御システム。
【請求項４】
前記第１監視制御局は、さらに、前記第１監視制御局から前記第２監視制御局へのデータの等値化処理を運用時間内に少なくとも１回行う等値化処理部を備えたことを特徴とする請求項１乃至３のいずれか１項に記載の監視制御システム。
【請求項５】
前記第１監視制御局は、さらに、監視制御システムの状態を監視するのに必要な監視信号を収集するシステム状態監視部と、前記システム状態監視部によって収集された監視信号に基づいて前記第１監視制御局のダウンの予兆の有無を判断するダウン予兆判断部と、を備え、
前記起動・停止処理部は、前記ダウン予兆判断部によりダウンの予兆があると判断されたのに基づいて、停止中の前記第２監視制御局を起動することを特徴とする請求項１乃至４のいずれか１項に記載の監視制御システム。
【請求項６】
第１サーバ群を備えた第１監視制御局と、前記第１サーバ群と同等構成の第２サーバ群を備え且つ前記第１監視制御局とネットワークを介して接続された第２監視制御局と、を備えた監視制御システムにおいて、
前記第１監視制御局は、
監視制御システムの状態を監視するのに必要な監視信号を収集するシステム状態監視部と、
前記システム状態監視部によって収集された監視信号に基づいて前記第１監視制御局のダウンの予兆の有無を判断するダウン予兆判断部と、
運用時間内に前記第２監視制御局を起動し、運用時間外に前記第２監視制御局を停止するとともに、運用時間外において、前記ダウン予兆判断部によりダウンの予兆があると判断されたのに基づいて停止中の前記第２監視制御局を起動する起動・停止処理部と、
を備えたことを特徴とする監視制御システム。
【請求項７】
さらに、前記ダウン予兆判断部によりダウンの予兆の有無を判断するのに必要な閾値の設定を受け付ける入力部を備え、
前記ダウン予兆判断部は、前記入力部により設定された閾値と前記システム状態監視部によって収集された監視信号とを比較して、ダウンの予兆の有無を判断することを特徴とする請求項５または６に記載の監視制御システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−７９２９２（Ｐ２０１２−７９２９２Ａ）
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願番号】特願２０１１−１７１１７１（Ｐ２０１１−１７１１７１）
【出願日】平成２３年８月４日（２０１１．８．４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願日】平成２３年８月４日（２０１１．８．４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]