JP2005301438A - 分散監視制御システム - Google Patents

Abstract

【課題】 メンテナンス計算機により、主計算機や試験計算機でのオンライン用設備ＤＢが高速に更新し、また、それら計算機立上げ時には、それらに具備されている設備ＤＢ等を復元させること。
【解決手段】 主計算機Ａ，Ｂそれぞれのオンライン設備ＤＢ１０４，２０４と、メンテナンス計算機Ｄのメンテナンス用設備ＤＢ７、保存用設備ＤＢ８及び設備ＤＢ状態テーブル９と、試験計算機Ｃのオンライン用設備ＤＢ３０４とが主メモリ上に配置される一方、設備ＤＢ管理機能部１０による制御下に、計算機Ａ，Ｂそれぞれの立上げ時には、テーブル９に基づき、設備ＤＢ１０４，２０４の内容が設備ＤＢ８からの該当設備ＤＢにより復元され、また、計算機Ｃの立上げ時には、テーブル９に基づき、設備ＤＢ３０４の内容が設備ＤＢ８からの該当設備ＤＢにより復元され、更に、計算機Ｃの立上げ時には、設備ＤＢ７，８及びテーブル９の内容が退避ディスク１１からの退避内容により復元されるようにした。
【選択図】 図１

Description

本発明は、電力系統監視制御システム等、分散化された、複数の計算機から構成されている分散監視制御システムに係り、特に設備データベース等の記憶用に主メモリが採用されたことによって、メンテナンス計算機で作成されたメンテナンス用設備データベースにより主計算機や試験計算機でのオンライン用設備データが高速に更新され、また、それら計算機立上げ時での設備データベース等の復元が容易とされた分散監視制御システムに関する。

例えば、電力系統に例を採れば、電力系統には発電機や送電線、変圧器、開閉器等の設備が含まれており、このような電力系統が電力系統監視制御システムにより監視制御されている。その監視制御システムでは、それら設備に関するデータ、即ち、設備データが種類別にレコードとして構成されており、更に、これらレコードが纏まって設備ＤＢ（ＤＢ：データベース）が形成されるようになっている。

ところで、電力系統設備は、年々、拡大化、複雑化の一途を辿っており、これら拡大化、複雑化に対処すべく、電力系統監視制御システムには、更なる高性能化、高信頼性化が望まれている。このような状況の中、電力系統監視制御システムには多重化や分散化が採用されており、したがって、通常、電力系統監視制御システムは、一般に複数の計算機から構成される。

ここで、従来技術に係る電力系統監視制御システムについて説明すれば、その一例でのシステム構成を図８に示す。図示のように、オンライン業務処理を実行する二重系の主計算機Ａ，Ｂやオンライン業務処理を模擬（シミュレート）する試験計算機Ｃ、メンテナンス用設備ＤＢ７をメンテナンスするメンテナンス計算機Ｄを含むようにして、これら計算機Ａ〜Ｄがネットワーク上に分散設置された分散型多重系計算機システムとして構成されている。これら計算機Ａ〜Ｄそれぞれには、通常、設備ＤＢ記憶用としてディスク（磁気ディスク等）が具備されているが、設備ＤＢの高速転送を図るには、ディスクに代って、半導体メモリ、例えば、非不揮発性半導体メモリが採用されるのが望ましくなっている。

さて、以上の計算機Ａ〜Ｄのうち、主計算機Ａ、主計算機Ｂ、試験計算機Ｃそれぞれにはオンライン用設備ＤＢ１０４，２０４，３０４が具備されており、また、メンテナンス計算機Ｄには、メンテナンス用設備ＤＢ７、保存用設備ＤＢ８及び設備ＤＢ状態テーブル９が具備される。メンテナンス計算機Ｄでは、データ入力装置５からの入力データに基づき、設備ＤＢ変更機能部（設備ＤＢ変更機能を果たす手段）６によりメンテナンス用設備ＤＢ７が作成されており、メンテナンス用設備ＤＢ７が作成される度に、その作成されたメンテナンス用設備ＤＢ７により試験計算機Ｃのオンライン用設備ＤＢ３０４が更新されるようになっている。試験計算機Ｃでは、そのオンライン用設備ＤＢ３０４を用い、オンライン業務の模擬試験及びオンライン用設備ＤＢ３０４自体の模擬試験が実行されているが、その模擬試験の結果として、異常がなければ、その作成されたメンテナンス用設備ＤＢ７は保存用設備ＤＢ８に保存される一方、その作成されたメンテナンス用設備ＤＢ７により主計算機Ａ，Ｂのオンライン用設備ＤＢ１０４，２０４が更新可能となっている。因みに、上記の「模擬試験」とは、あくまでも、ソフトウェア上での模擬的な試験（シミュレーション）という意味であり、実際のオンライン業務に携わっての試験ではないことに注意されたい（実際の設備と間で信号の授受を行わない）。

共通管理テーブルとしての設備ＤＢ状態テーブル９ではまた、計算機Ａ〜Ｄそれぞれの設備ＤＢ１０４，２０４，３０４，７の過渡状態と、設備ＤＢ１０４，２０４が更新された際での計算機Ａ，Ｂの正常／異常状態とが一元管理されている。計算機Ａ，Ｂそれぞれの正常、異常のステータスは異常検出機能部１０２，２０２にて監視される一方、オンライン用設備ＤＢ１０４，２０４，３０４それぞれの件名状態は、設備ＤＢ切替機能部１０３，２０３，３０３からネットワークを介しメンテナンス計算機Ｄで収集されることで、設備ＤＢ状態テーブル９が更新可能となっている。主計算機Ａ，Ｂや試験計算機Ｃでは、設備ＤＢ状態テーブル９内に保持されている設備データベースの状態に基づき、メンテナンス用設備ＤＢ７によりオンライン設備ＤＢ１０４，２０４，３０４が更新可能か否かが設備ＤＢ切替機能部１０３，２０３，３０３により判断可能となっている。更新不可能と判断された場合には、その更新は不可能とされる。

更にまた、メンテナンス計算機Ｄには保存用設備ＤＢ８が具備されており、これには、メンテナンス用設備ＤＢ７が設備ＤＢ変更機能部６により作成される度に、その作成されたメンテナンス用設備ＤＢ７が試験済みのものとして設備ＤＢ変更機能部６により保存される。このように、過去に作成されたメンテナンス用設備ＤＢ７を複数、保存しておくことによって、主計算機Ａ，Ｂのオンライン用設備ＤＢ１０４，２０４がメンテナンス用設備ＤＢ７により更新された後に、オンライン用設備ＤＢ１０４，２０４を更新前の状態として復元するには、その保存されている複数のメンテナンス用設備ＤＢ７のうち、該当するものによりオンライン用設備ＤＢ１０４，２０４が更新されるようにすればよいものである。

以上のように、設備ＤＢ状態テーブル９により、オンライン用設備ＤＢ１０４，２０４，３０４それぞれが更新可能か否かが判断可能とされている。詳細な説明は省略するが、この設備ＤＢ状態テーブル９が参照されることで、オンライン用設備ＤＢ等が誤って更新されるのが防止可能となっている。具体的には、以下の更新が防止可能とされる。
１）模擬試験途中、またはオンライン用として確定しているオンライン用設備ＤＢ１０４，２０４，３０４のメンテナンス計算機Ｄによる更新
２）メンテナンス途中でのメンテナンス用設備ＤＢ７によるオンライン用設備ＤＢ１０４，２０４，３０４の更新
３）模擬試験途中でのオンライン用設備データベース３０４によるオンライン用設備ＤＢ１０４，２０４の更新
４）模擬試験結果が異常であるオンライン用設備ＤＢ３０４によるオンライン用設備ＤＢ１０４，２０４の更新

この設備ＤＢ状態テーブル９について簡単に説明すれば、以下のようである。
即ち、設備ＤＢ状態テーブル９はＤＢ状態テーブル及び件名状態テーブルから構成されており、そのＤＢ状態テーブルの構成例を図９に、その件名状態テーブルの構成例を図１０にそれぞれ示す。図９に示すように、ＤＢ状態テーブル９Ａには、計算機Ａ〜Ｄそれぞれで保持されている設備ＤＢの「件名No．」と、主計算機Ａ，Ｂそれぞれで現在保持されている設備ＤＢに更新された際に、異常が発生したか否かを示す「切替え状態」と、主計算機Ａ，Ｂそれぞれにハードウェアの異常が発生したか否かを示す「計算機状態」とが時間の経過とともに更新可として記憶されるようになっている。具体的に、「切替え状態」は、オンライン用設備ＤＢが正常か異常かを示すフラグ値とされ、また、「計算機状態」は、計算機のハードウェアが正常か異常かを示すフラグ値とされる。設備ＤＢの運用中にソフトウェアエラーが発生すれば、「切替え状態」には異常フラグが設定され、また、ハードウェアエラーが発生すれば、「計算機状態」には異常フラグが設定される。

因みに、そのＤＢ状態テーブル９Ａには、主計算機Ａのオンライン用設備ＤＢ１０４が運用中（件名No．＝４）、切替え状態が正常、計算機状態が正常であるという過渡状態が、また、主計算機Ｂのオンライン用設備ＤＢ２０４が運用中（件名No．＝４）、切替え状態が正常、計算機状態が正常であるという過渡状態が、更に、試験計算機Ｃが試験中（件名No．＝７）であるという過渡状態が、更にまた、メンテナンス計算機Ｄが試験中（件名No．＝７）であるという過渡状態が、それぞれ示されている。ここにいう運用中とは、設備ＤＢに基づいて、実際に計算機が動作中（動作可能な状態を含む）であることを示しており、また、試験中とは、データベースの模擬試験が実行されている状態を示す。

一方、図１０に示すように、件名状態テーブル９Ｂには、設備ＤＢの来歴を区別する「件名No．」と、設備ＤＢの過渡状態を示す「件名状態」との対応関係が記憶されている。件名はＤＢの来歴を区別するものであり、件名No．はその識別子とされる。このように、設備ＤＢの過渡状態は件名No．に対応付けされているが、この件名No．は、例えば１〜１０という整数値とされる。因みに、その件名状態テーブル９Ｂでは、過渡状態として、例えば、運用完了は「１」、保存完了は「２」、更新前の状態への復元中は「３」、運用中は「４」、切替え中は「５」、切替え待ちは「６」、試験中は「７」、試験待ちは「８」、作成中は「９」、作成待ちは「１０」として、それぞれ指定されている。

ここで、運用中や試験中以外の各件名状態について簡単に説明すれば、以下のようである。
作成待ち ：設備ＤＢの作成・編集作業に着手する前の状態
作成中 ：設備ＤＢ作成・編集が完了していない状態
試験待ち ：作成された設備ＤＢに対し、模擬試験が実施可能であるも、まだ、実施されていない状態
切替え待ち：模擬試験の完了後、主計算機へのアップロードが開始される前の状態
切替え中 ：主計算機へのアップロードが実施されている状態（メンテナンス用設備ＤＢにより主計算機のオンライン用設備ＤＢが更新中である状態）
復元中 ：過去の件名の設備ＤＢが主計算機にアップロードされている状態
保存完了 ：過去の件名の設備ＤＢが保存用設備ＤＢに格納された状態
運用完了 ：新件名により運用中の件名が完了した状態

以上のような構成において、オンライン業務処理機能部（オンライン業務処理機能を果たす手段）１０１，２０１，３０１それぞれでは、オンライン用設備ＤＢ１０４，２０４，３０４上の設備データに基づき、電力系統の電圧や電流の監視、発電機制御、開閉器のＯＮ／ＯＦＦ操作指令等のオンライン業務が行われる。一方、設備ＤＢ変更機能部６では、データ入力装置５からのデータ入力に基づき、メンテナンスが実行されており、この設備ＤＢ変更機能部６によりメンテナンス用設備ＤＢ７に対しては、設備データの変更や追加、削除等が行われるようになっている。

図１１にはまた、主計算機Ａ，Ｂや試験計算機Ｃでの一般的な立上げ処理フローが示されているが、これによる場合、設備ＤＢ記憶用としてディスクが使用される限りにおいては、特に不具合は生じないものとなっている。設備ＤＢは計算機の停止（動作電源の停止）直前にディスクに保存されているからである。その立上げ処理フローによる場合、先ずそれら計算機Ａ〜Ｃそれぞれは単独で立上げられた上、基本ソフトウェアの開始処理が行われる（ステップＳ１，Ｓ２）。この基本ソフトウェアの開始処理完了で、ディスク上の設備ＤＢが使用可能とされる。次いで、業務ソフトウェアの開始処理が行われる（ステップＳ３）。この業務ソフトウェアの開始処理は、オンライン業務処理に対する前処理（設備ＤＢ読込みやワークテーブルの初期化等、起動時に行われる処理）とされる。その業務ソフトウェアの開始処理が終了すれば、その後、その開始処理が全て正常裡に終了したか否かが判定される（ステップＳ４）。全ての開始処理が正常に終了したと判定された場合には、初めて業務が開始される（ステップＳ５）。しかし、業務ソフトウェアの開始処理が正常に終了しなかった場合には、異常要因が除去された上、立上げ処理が再開されるようになっている（ステップＳ６）。

以上、従来技術に係る電力系統監視制御システムについて説明した。今後、システム構成が複雑になる一方で、日々変化する電力系統設備に適合させるには、電力系統監視制御システム上に保持されている設備データベースは、頻度大にして更新されなければならなく、しかも、その更新は高速に行われる必要がある。

因みに、特許文献１には、送電線の追加や変電所の増設、容量の変更等の追加や削除、変更があった場合での設備ＤＢ更新方法が開示されている。追加や変更により編集されたメンテナンス用設備ＤＢはオンライン用設備ＤＢを備える全ての計算機に配信されており、それらオンライン用設備ＤＢはメンテナンス用設備ＤＢにより更新されるようになっている。
特開２００１―５７９６号公報

ところで、監視制御システム上に保持されている設備データベースが高速に更新されなければならないことを考慮の上、これまでのディスクに代わって、計算機それぞれに具備されている既存の主メモリ（一般に、非不揮発性半導体メモリ）が設備ＤＢ記憶用、設備ＤＢ状態テーブル記憶用として採用されるとしても、新たな不具合が生じることになる。というのは、計算機の停止等を要因として、それに具備されている設備ＤＢや設備ＤＢ状態テーブルの内容が消失されてしまうからである。このように、設備ＤＢ等を主メモリ上に配置している計算機それぞれでは、内容が消失状態にある設備ＤＢに対する復元は自身では不可能とされていることから、これまでの計算機立上げ処理のままでは、業務ソフトウェアの開始処理でエラーが継続してしまい、計算機は正常に立上げられることはなく、業務開始には至らないことになる。尤も、主メモリに比し動作速度はやや劣るが、計算機の停止等によっては、内容が消失されることがない不揮発性半導体メモリ（フラッシュメモリ等）を採用することも考えられる。しかし、不揮発性半導体メモリの採用は、計算機それぞれへの新たな設備の導入となり、既存の主メモリの有効利用上からしても、その積極的な採用は必ずしも望ましいとはいえない。

本発明の目的は、メンテナンス計算機で作成されたメンテナンス用設備ＤＢ、あるいはメンテナンス計算機に保存されているメンテナンス用設備ＤＢにより、主計算機や試験計算機でのオンライン用設備ＤＢが高速に更新され得るばかりか、それら計算機立上げ時には、それに具備されている設備ＤＢや設備ＤＢ状態テーブル等が容易に復元され得る分散監視制御システムを提供することにある。

本発明による分散監視制御システムは、それぞれに設備データが記憶されるオンライン用設備ＤＢを含む、少なくとも二台以上の主計算機と、これら主計算機それぞれでのオンライン用設備ＤＢをメンテナンスするためのメンテナンス用設備ＤＢ、及び保存用設備ＤＢを含むメンテナンス計算機と、このメンテナンス計算機で作成されたメンテナンス用設備ＤＢによりオンライン用設備ＤＢが更新された状態で、該メンテナンス用設備ＤＢを模擬試験する試験計算機とを含み、上記メンテナンス計算機には、更に、該メンテナンス計算機、上記主計算機、上記試験計算機それぞれにおけるオンライン用、メンテナンス用の設備ＤＢの過渡状態と、オンライン用設備ＤＢ更新時における上記主計算機それぞれの正常／異常状態とを管理するための設備ＤＢ状態テーブルが備えられている分散監視制御システムとされ、主計算機それぞれのオンライン設備ＤＢと、メンテナンス計算機のメンテナンス用設備ＤＢ、保存用設備ＤＢ及び設備ＤＢ状態テーブルと、試験計算機のオンライン用設備ＤＢとが主メモリ上に配置される一方、上記主計算機それぞれの立上げ時には、上記設備ＤＢ状態テーブルに基づいて該主計算機のオンライン用設備ＤＢの内容を、上記試験計算機の立上げ時には、上記設備ＤＢ状態テーブルに基づいて該試験計算機のオンライン用設備ＤＢの内容を、上記メンテナンス計算機の立上げ時には、該メンテナンス計算機のメンテナンス用設備ＤＢ、保存用設備ＤＢ及び設備ＤＢ状態テーブルの内容を、それぞれ停止前の状態に復元する手段を備えるように、構成されたものである。

具体的には、主計算機それぞれのオンライン用設備ＤＢと、試験計算機のオンライン用設備ＤＢとが保存用設備ＤＢで管理・保持されている状態で、主計算機、試験計算機それぞれの立上げ時には、メンテナンス計算機により停止前の主計算機、試験計算機のオンライン用設備ＤＢの状態が設備ＤＢ状態テーブルより判断された上、立上げ状態にある主計算機、試験計算機それぞれに対しては、オンライン用設備ＤＢの復元に必要とされる該当設備ＤＢが配信されることによって、オンライン用設備ＤＢが復元されるようにした。

また、メンテナンス計算機の停止時には、メンテナンス用設備ＤＢ、保存用設備ＤＢ、設備ＤＢ状態テーブルそれぞれの内容は一定条件下に退避ディスクに退避される一方、メンテナンス計算機の立上げ時には、メンテナンス用設備ＤＢ、保存用設備ＤＢ、設備ＤＢ状態テーブルそれぞれの内容は退避ディスクから復元されるようにした。

メンテナンス計算機で作成されたメンテナンス用設備ＤＢ、あるいはメンテナンス計算機に保存されているメンテナンス用設備ＤＢにより、主計算機や試験計算機でのオンライン用設備ＤＢが高速に更新され得るばかりか、それら計算機立上げ時には、それに具備されている設備ＤＢが容易に復元可能となる。

以下、本発明の一実施の形態を図１から図７により説明する。
先ずその具体的説明に先立って、本発明の概要について説明しておく。既に明らかなように、本発明の１つの特徴としては、各種設備ＤＢや設備ＤＢ状態テーブルの記憶用として、これまでのディスクに代って、既存の主メモリ、即ち、非不揮発性半導体メモリが採用されるようにした。近年のネットワーク製品や半導体メモリ製品の高速・大容量化に伴い、各種設備ＤＢをデータ転送が低速なディスクから、データ転送が高速な非不揮発性半導体メモリに置換しようというものである。このように、計算機それぞれに具備される各種設備ＤＢ等がその非不揮発性半導体メモリ上に配置される場合は、ディスクに比し設備データの高速書込み・読出しが可能となり、したがって、メンテナンス用設備ＤＢによるオンライン用設備ＤＢの更新処理もまた、より高速化されることになる。

ただ、非不揮発性半導体メモリが設備ＤＢ記憶用等として採用されことに伴い、計算機の停止等を要因として、その計算機に具備されている設備ＤＢ等のデータの消失といった新たな不具合が生じることになる。そこで、本発明の他の特徴として、計算機それぞれが立上げされる際には、その計算機に具備されている設備ＤＢや設備ＤＢ状態テーブルには、計算機の停止前の設備データや設備ＤＢ状態が自動的に復元されるようにしたものである。

さて、本発明について、電力系統監視制御システムを例に採り、具体的に説明すれば、その一例でのシステム構成を図１に示す。図示のように、この電力系統監視制御システムも、図８に示したものと同様に、電力系統における監視制御をオンラインで実行する二重系の主計算機Ａ，Ｂと、メンテナンスされたメンテナンス用設備ＤＢをオンライン用設備ＤＢで検証するための試験計算機Ｃと、メンテナンス用設備ＤＢに対しメンテナンスを実行するためのメンテナンス計算機Ｄとを含むようにしてなる。

ここで、それら計算機Ａ〜Ｄそれぞれの構成について説明すれば、先ず主計算機Ａは、オンライン業務処理機能部１０１や異常検出機能部１０２、設備ＤＢ切替機能部１０３、オンライン用設備ＤＢ１０４を含むようにして構成される。また、主計算機Ｂも、主計算機Ａと同様に、オンライン業務処理機能部２０１や常検出機能部２０２、設備ＤＢ切替機能部２０３、オンライン用設備ＤＢ２０４を含む状態として構成される。更に、試験計算機Ｃは、オンライン業務処理機能部３０１や設備データベース切替機能部３０３、オンライン用設備ＤＢ３０４を含むようにして構成されている。更にまた、メンテナンス計算機Ｄは、設備ＤＢ変更機能部６やメンテナンス用設備ＤＢ７、保存用設備ＤＢ８、設備ＤＢ状態テーブル（設備ＤＢの過渡状態と、設備ＤＢ更新時における主計算機Ａ，Ｂの故障状態（正常／異常）を記憶）９を含むようにして構成されているが、従来技術に係る電力系統監視制御システムと大きく異なる点としては、以下の手段が新たに設けられていることが挙げられる。

即ち、設備ＤＢ状態テーブル９に基づき、メンテナンス用設備ＤＢ７や保存用設備ＤＢ８上の設備ＤＢにより、オンライン用設備ＤＢ１０４，２０４，３０４それぞれの更新制御を行うとともに、メンテナンス計算機Ｄの停止及び立上げ時においては、メンテナンス用設備ＤＢ７、保存用設備ＤＢ８及び設備ＤＢ状態テーブル９の退避、復元を管理する設備ＤＢ管理機能部（設備ＤＢ更新手段に相当）１０や、メンテナンス用設備ＤＢ７、保存用設備ＤＢ８及び設備ＤＢ状態テーブル９の内容を退避、保持するための退避ディスク１１が新たに設けられていることが挙げられる。

以上の構成で、オンライン用設備ＤＢ１０４，２０４，３０４やメンテナンス用設備ＤＢ７、保存用設備ＤＢ８、設備ＤＢ状態テーブル９が主メモリ上に配置されているとして、主計算機Ａ，Ｂや試験計算機Ｃでの立上げ処理フローを図２に示す。この立上げ処理は、主計算機Ａ，Ｂや試験計算機Ｃの何れか１つの計算機を単独で立上げる手順とされる。その立上げ処理では、従来の場合と同様にして、先ずそれら計算機Ａ〜Ｃそれぞれは単独で立上げられた上、基本ソフトウェアの開始処理が行われる（ステップＳ２１，Ｓ２２）。さて、主計算機Ａ，Ｂや試験計算機Ｃには、自律的に停止前の状態のオンライン設備ＤＢを保持、復元する手段が備えられていないため、業務ソフトウェア開始処理の前に、オンライン設備ＤＢ復元処理が行われる（ステップＳ２３）。

具体的に、このオンライン設備ＤＢ復元処理では、復元されるべき設備データを設備データ管理元としてのメンテナンス計算機Ｄに問合せをして、該当する件名の設備ＤＢを転送してもらい、この設備ＤＢがオンライン設備ＤＢに転送記憶されることによって、停止前の状態のオンライン設備ＤＢが復元される。より具体的に、メンテナンス計算機Ｄでは、要求元計算機の停止前のオンライン設備ＤＢが設備ＤＢ状態テーブルより特定された上、保存用設備ＤＢからは、該当する件名の設備ＤＢが要求元計算機のオンライン用設備ＤＢに転送記憶されるようになっている。このように、設備ＤＢ状態テーブルが参照されることで、復元されるべき設備データに誤りがないことが確認された上、メンテナンス計算機から要求元計算機には該当設備データが転送されているものである。

次いで、業務ソフトウェアの開始処理が行われる（ステップＳ２４）。この業務ソフトウェアの開始処理は、オンライン業務処理に対する前処理（設備ＤＢ読込みやワークテーブルの初期化等、起動時に行われる処理）とされる。その業務ソフトウェアの開始処理が終了すれば、その後、その開始処理が全て正常裡に終了したか否かが判定される（ステップＳ２５）。全ての開始処理が正常に終了したと判定された場合には、初めてオンライン業務が開始されているものである（ステップＳ２６）。また、もしも、業務ソフトウェアの開始処理が正常に終了しなかった場合には、異常要因が除去された上、再び立上げ処理が開始されるようになっている（ステップＳ２７）。

図３はまた、主計算機Ａ，Ｂや試験計算機Ｃでのオンライン設備ＤＢ復元処理の際に、メンテナンス計算機Ｄとの間で授受される設備ＤＢ転送要求タイミングや設備ＤＢ転送タイミングを示す。新旧の設備ＤＢはメンテナンス計算機Ｄで一元的に管理、保持されているが、そのオンライン設備ＤＢ復元処理に際しては、先ず主計算機Ａ，Ｂや試験計算機Ｃからは、オンライン設備ＤＢ復元のための設備ＤＢの転送要求がメンテナンス計算機Ｄに対して発せられる（ステップＳ３１）。この転送要求はメンテナンス計算機Ｄで受け付けられた上、転送要求元計算機に復元されるべきオンライン設備ＤＢの状態が設備ＤＢ状態テーブルにて特定される（ステップＳ３２，Ｓ３３）。次いで、該当の設備ＤＢが転送要求元計算機に対し転送される（ステップＳ３４）。転送要求元計算機では、メンテナンス計算機Ｄからの設備ＤＢが受信された上、オンライン設備ＤＢに転送記憶されることで、一連のオンライン設備ＤＢ復元処理は終了される（ステップＳ３６）。

以上、主計算機Ａ，Ｂや試験計算機Ｃでの立上げ処理について説明した。次に、メンテナンス計算機Ｄでの停止時処理や立上げ処理について説明すれば、以下のようである。
即ち、先ず停止時処理について説明すれば、その停止時処理フローを図４に示す。メンテナンス計算機Ｄは自身がデータ保存元であるため、計算機の停止により保存用設備ＤＢやメンテナンス用設備ＤＢ，更には、設備ＤＢ状態テーブルの内容が完全に消失されないように、これら設備ＤＢやテーブルの内容を停止処理の中で退避させる手段がメンテナンス計算機Ｄには備えられている。停止処理の手順としては、先ず当該計算機上で動作している業務サービスの終了後、業務ソフトウェア（メンテナンス機能）の終了処理が実行される（ステップＳ４１，Ｓ４２）。次に、保存用設備ＤＢ、メンテナンス用設備ＤＢ及び設備ＤＢ状態テーブルの内容の退避処理が順次、実行される（ステップＳ４３）。その後は、基本ソフトウェア終了処理が行われた上、計算機は停止される（ステップＳ４４，Ｓ４５）。

図５はまた、メンテナンス用設備ＤＢ、保存用設備ＤＢ、設備ＤＢ状態テーブルそれぞれの退避処理フローの一例を示す。本例では、先ず保存用設備ＤＢが退避されるが、この保存用設備ＤＢには、運用中の設備データや、それ以前に運用完了した複数件名の設備ＤＢが管理、保持されていることから、これら全ての設備ＤＢが退避対象とされる。このように、保存用設備ＤＢの内容は、メンテナンス計算機Ｄの停止時に必ず退避されるべきものではあるが、前回の立上げから今回の停止までの間に、その内容が必ずしも更新されているとは限らない。したがって、保存用設備ＤＢは、前回の立上げから今回の停止までの間に、その内容が更新されたことにより、退避が必要とされる場合にのみ行うことが考えられる。今回停止時に退避させるべきか否かが判断されるべく、メンテナンス機能に更新管理フラグを備えさせ、このフラグの状態が参照されるようにすれば、保存用設備ＤＢ退避処理が必要か否かが容易に判断されることになる。

即ち、保存用設備ＤＢ退避処理では、先ずそのフラグの状態が参照されることで、前回の立上げから今回の停止までの間に、保存用設備ＤＢの内容が更新されたか否かが判断される（ステップＳ５１）。その内容が更新されている場合のみ、保存用設備ＤＢの内容はそのまま、退避ディスクに転送記憶される（ステップＳ５２）。また、その内容が更新されていない場合、または保存用設備ＤＢ退避処理が終了した場合には、次に、メンテナンス用設備ＤＢに退避対象の件名があるか否かが判断される（ステップＳ５３）。このメンテナンス用設備ＤＢには、メンテナンス作業中における設備ＤＢが管理、保持されており、既述の図１０に示す作成待ち、作成中、試験待ち、試験中、切替え待ち、切替え中、運用中の件名状態が含まれている。当該メンテナンス用設備ＤＢにおいても、保存用設備ＤＢと同様に、退避が必要とされる場合のみ、退避されるようになっている。保存中の設備データの上記件名状態の中で、退避されなければならない件名状態は、編集中、あるいは編集後の作成中、試験待ち、試験中の何れかに該当する場合である。

したがって、具体的には、当該設備ＤＢの件名状態が、設備ＤＢ状態テーブルより、作成中、試験待ち、試験中の何れかに該当するか否かが判断されるようにすればよい。結局のところ、メンテナンス用設備ＤＢ対応に用意されている更新管理フラグの状態が参照されることで、前回の立上げから今回の停止までの間に、メンテナンス用設備ＤＢの内容が更新されたか否かが判断されるようにすればよい。もしも、その間に更新されていれば、メンテナンス用設備ＤＢの内容はそのまま、退避ディスクに転送記憶される（ステップＳ５４）。また、その内容が更新されていない場合、またはメンテナンス用設備ＤＢ退避処理が終了した場合には、設備ＤＢ状態テーブル対応に用意されている更新管理フラグの状態が参照されることで、前回の立上げから今回の停止までの間に、設備ＤＢ状態テーブルの内容が更新された可否かが判断される（ステップＳ５５）。もしも、その間に更新されていれば、設備ＤＢ状態テーブルの内容はそのまま、退避ディスクに転送記憶されるようになっている（ステップＳ５６）。また、その内容が更新されていない場合、または設備ＤＢ状態テーブル退避処理が終了した場合には、一連の退避処理は終了される。

引続き、メンテナンス計算機Ｄでの立上げ処理について説明すれば、その立上げ処理フローの一例を図６に示す。これによる場合、先ず計算機の立上げに続いて、基本ソフトウェアが開始処理が行われる（ステップＳ６１，Ｓ６２）。その後に、保存用設備ＤＢ、メンテナンス用設備ＤＢ及び設備ＤＢ状態テーブルの復元処理が実行される（ステップＳ６３）。更に、その後は、業務ソフトウェア開始処理が実行された上、業務が開始されるようになっている（ステップＳ６４，Ｓ６５）。

以上の保存用設備ＤＢ、メンテナンス用設備ＤＢ及び設備ＤＢ状態テーブルの復元処理の処理フローの一例を図７に示す。これによる場合、先ず退避ディスクに退避記憶されている内容のうち、退避保存用設備ＤＢが保存用設備ＤＢに転送記憶されることで、保存用設備ＤＢは計算機停止前の状態として復元される（ステップＳ７１）。その後、退避ディスクに退避記憶されている内容のうち、退避メンテナンス用設備ＤＢがメンテナンス用設備ＤＢに転送記憶されることで、メンテナンス用設備ＤＢは計算機停止前の状態として復元される（ステップＳ７２）。更に、その後は、退避ディスクに退避記憶されている内容のうち、退避設備ＤＢ状態テーブルが設備ＤＢ状態テーブルに転送記憶されることで、設備ＤＢ状態テーブルは計算機停止前の状態として復元されるようになっている（ステップＳ７３）。このように、メンテナンス計算機Ｄでは、メンテナンス用設備ＤＢ、保存用設備ＤＢ及び設備ＤＢ状態テーブルの内容は、当該計算機の停止前での退避処理と立上げ後での復元処理とにより、その同一性が確実に確保されることになる。

以上、本発明による分散監視制御システムについて説明した。因みに、以上の説明では、主計算機Ａ，Ｂは二重系とされているが、これに限定されることなく、それぞれ独立に動作する主計算機が並列接続される方式にも適用可能であり、また、主計算機は三台以上から構成されるようにしてもよい。

以上、説明したように、主計算機や試験計算機のオンライン用設備ＤＢや、メンテナンス計算機のメンテナンス用設備ＤＢ、保存用設備ＤＢ及び設備ＤＢ状態テーブルは全て非主メモリ上に配置されていることから、メンテナンス用設備ＤＢや保存用設備ＤＢによる主計算機のオンライン用設備ＤＢの更新処理や、メンテナンス用設備ＤＢによる試験計算機のオンライン用設備ＤＢの更新処理は、ディスク配置を前提とする従来システムに比し、その処理時間が大幅に短縮化されることになる。また、メンテナンス計算機には、設備ＤＢ等の復元にディスクが必要とされているが、これ以外のディスク配置は不要となる。

以上、本発明者によってなされた発明を実施の形態に基づき、具体的に説明したが、本発明は上記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変更可能であることはいうまでもない。

本発明による分散監視制御システムの一例でのシステム構成を示す図である。 そのシステムを構成している主計算機や試験計算機での、本発明に係る立上げ処理フローを示す図である。 主計算機や試験計算機でのオンライン設備ＤＢ復元処理の際に、メンテナンス計算機との間で授受される設備ＤＢ転送要求タイミングや設備ＤＢ転送タイミングを示す図である。 メンテナンス計算機での停止時処理フローを示す図である。 メンテナンス用設備ＤＢ、保存用設備ＤＢ、設備ＤＢ状態テーブルそれぞれの退避処理フロー例を示す図である。 メンテナンス計算機での立上げ処理フローを示す図である。 保存用設備ＤＢ、メンテナンス用設備ＤＢ及び設備ＤＢ状態テーブルの復元処理フローを示す図である。 従来技術に係る電力系統監視制御システムの一例でのシステム構成を示す図である。 オンライン用設備データベースそれぞれが更新可能か否かを判断するための設備データベース状態テーブルの一構成要素としてのデータベース状態テーブルの構成例を示す図である。 オンライン用設備データベースそれぞれが更新可能か否かを判断するための設備データベース状態テーブルの一構成要素としての件名状態テーブルの構成例を示す図である。 そのシステムを構成している主計算機や試験計算機での一般的な立上げ処理フローを示す図である。

符号の説明

Ａ，Ｂ…主計算機、Ｃ…試験計算機、Ｄ…メンテナンス計算機、７…メンテナンス用設備ＤＢ、８…保存用設備ＤＢ，９…設備ＤＢ状態テーブル、１０…設備ＤＢ管理機能部（設備ＤＢ更新手段）、１１…退避ディスク、１０３，２０３，３０３…設備ＤＢ切替機能部（設備ＤＢ更新手段）、１０４，２０４，３０４…オンライン用設備ＤＢ

Claims (6)

1. それぞれに設備データが記憶されるオンライン用設備データベースを含む、少なくとも二台以上の主計算機と、該主計算機それぞれでのオンライン用設備データベースをメンテナンスするためのメンテナンス用設備データベース、及び保存用設備データベースを含むメンテナンス計算機と、該メンテナンス計算機で作成されたメンテナンス用設備データベースによりオンライン用設備データベースが更新された状態で、該メンテナンス用設備データベースを模擬試験する試験計算機とを含み、上記メンテナンス計算機には、更に、該メンテナンス計算機、上記主計算機、上記試験計算機それぞれにおけるオンライン用、メンテナンス用の設備データベースの過渡状態と、オンライン用設備データベース更新時における上記主計算機それぞれの正常／異常状態とを管理するための設備データベース状態テーブルが備えられている分散監視制御システムであって、主計算機それぞれのオンライン設備データベースと、メンテナンス計算機のメンテナンス用設備データベース、保存用設備データベース及び設備データベース状態テーブルと、試験計算機のオンライン用設備データベースとが主メモリ上に配置される一方、上記主計算機それぞれの立上げ時には、上記設備データベース状態テーブルに基づいて該主計算機のオンライン用設備データベースの内容を、上記試験計算機の立上げ時には、上記設備データベース状態テーブルに基づいて該試験計算機のオンライン用設備データベースの内容を、上記メンテナンス計算機の立上げ時には、該メンテナンス計算機のメンテナンス用設備データベース、保存用設備データベース及び設備データベース状態テーブルの内容を、それぞれ停止前の状態に復元する手段を備えてなる分散監視制御システム。
2. 請求項１記載の分散監視制御システムにおいて、上記主計算機、試験計算機それぞれには、上記設備データベース状態テーブルに保持されている設備データベースの状態に基づき、メンテナンス用設備データベースによるオンライン用設備データベースの更新可否を判断し、更新可能と判断した場合に、上記オンライン用設備データベースを更新する設備データベース更新手段が備えられてなる分散監視制御システム。
3. 請求項１、または２に記載の分散監視制御システムにおいて、上記主計算機それぞれのオンライン用設備データベースと、上記試験計算機のオンライン用設備データベースとが上記保存用設備データベースで管理・保持されている状態で、上記主計算機、試験計算機それぞれの立上げ時には、上記メンテナンス計算機により停止前の主計算機、試験計算機のオンライン用設備データベースの状態が上記設備データベース状態テーブルより判断された上、立上げ状態にある主計算機、試験計算機それぞれに対しては、オンライン用設備データベースの復元に必要とされる該当設備データベースが配信されることによって、オンライン用設備データベースが復元されるようにした分散監視制御システム。
4. 請求項３記載の分散監視制御システムにおいて、上記メンテナンス計算機からは、上記主計算機、試験計算機それぞれからの設備データベース転送要求を待って、該当設備データベースの配信が行われるようにした分散監視制御システム。
5. 請求項１〜４の何れかに記載の分散監視制御システムにおいて、上記メンテナンス計算機の停止時には、メンテナンス用設備データベース、保存用設備データベース、設備データベース状態テーブルそれぞれの内容は一定条件下に退避ディスクに退避される一方、上記メンテナンス計算機の立上げ時には、上記メンテナンス用設備データベース、保存用設備データベース、設備データベース状態テーブルそれぞれの内容は上記退避ディスクから復元されるようにした分散監視制御システム。
6. 請求項５記載の分散監視制御システムにおいて、上記メンテナンス用設備データベース、保存用設備データベース、設備データベース状態テーブルそれぞれの内容は、該内容が前回立上げから今回停止までの間に更新されていることを条件として退避ディスクに退避されるようにした分散監視制御システム。

Images