JP2011253500A - データ配布システム、分散監視制御システム及びデータ配布方法 - Google Patents

Abstract

【課題】少ないネットワーク帯域であっても、サーバ拠点とクライアント拠点とのデータ同期化を行い、クライアント拠点におけるデータの信頼性を向上させることを目的とする。
【解決手段】管轄する電力系統を監視制御する給電システム３４のデータを管理するサーバ３３と、サーバ３３と広域ネットワーク網２６にて接続された支援システム３６とを備え、サーバ３３は、第１のデータベース１１１を更新した際に支援システム３６に更新イベントを送信し、更新イベントの送信が失敗した場合に更新イベントを再送信するサーバサーバ計算機５１を備え、支援システム３６は、更新イベントを受信した場合に第１のデータベース１１１を取得する取得処理を行い、第１のデータベース１１１の取得処理が失敗した場合に前記取得処理を行うクライアントクライアント計算機５２を備えた。
【選択図】図２

Description

本発明は、電力系統の機器や他の機器などを電子計算機により監視制御する監視制御システムに関し、特にネットワークに接続され、分散配置されたサーバ拠点とクライアント拠点にてデータベースの同期を行う分散監視制御システムに関するものである。

電力系統は、発電所で発電した電力を需要家（工場、家庭など）に送るための、発電所、変電所、送電線等の設備である。発電所で発電した電力は、発電所の変圧器で昇圧され、送電線に供給され、一次変電所、二次変電所で降圧され、配電線に供給されて需要家に配電される。この電力系統は、給電所及び制御所で監視制御される。給電所や制御所には、それぞれ給電所システム、制御所システムが配置され、管轄の設備機器や送電線、配電線が監視制御される。

一般に、電力系統には給電所や制御所が複数存在する。それぞれの給電所や制御所からネットワークを通じて各種のデータを収集し、他の場所でデータの閲覧や管理を行う場合がある。この場合に、各種データの供給元であるサーバ拠点（給電所や制御所）と、収集場所であるクライアント拠点との間で、ネットワークを通じてデータベースの同期化が行われる。

データベースの同期化は、例えば特許文献１に示されている。特許文献１のデータ同期化制御方式は、あるサーバ拠点Ａにおけるデータベースの更新がされた際に、サーバ拠点Ａから別のサーバ拠点Ｂへデータ更新通知を送り、通知を受信したサーバ拠点Ｂは更新が完了すると通知元のサーバ拠点Ａへデータ更新完了通知を行う。通知先サーバ拠点Ｂに障害が発生し、通知元サーバＡに通知先サーバ拠点Ｂからのデータ更新完了通知が異常または無応答の場合には、通知元サーバＡは、その障害サーバ拠点Ｂと更新内容の差分ファイルを自拠点Ａに登録する。通知先サーバ拠点Ｂの復旧後、通知先サーバ拠点Ｂから通知元のサーバ拠点Ａにレプリケーション要求を行い、データベースの更新を行っていた。

特開２００１−２９０６８７号公報（００１２段〜００１５段）

電力系統を監視し制御を行う監視制御システムは、複数の給電所や制御所等の間で、ネットワークを通じて重要度の高いデータの送受信が大量に行われる。それぞれの給電所や制御所からネットワークを通じて各種データを収集し、他の場所でデータの閲覧や管理を行う支援システムは、同じネットワークを使ってデータを収集する場合、使用可能なネットワーク帯域が制限されることがある。

従来のデータ同期化制御方式は、通知先サーバ拠点Ｂからの異常応答または無応答によるタイムアウトが発生した場合に、障害サーバ情報（装置番号、レコード番号）と更新内内容（データ内容）からなる差分ファイルを自拠点Ａに登録し、その差分ファイルに対して通知先サーバ拠点Ｂがレプリケーション要求をかけている。しかしながら、使用可能なネットワーク帯域が制限された場合には、通知先サーバ拠点Ｂからの応答前に通知元サーバ拠点Ａがダウンすること場合もあることを考慮する必要がある。通知先サーバ拠点Ｂからの応答前に通知元サーバ拠点Ａがダウンしたときは、その後通知先サーバ拠点Ｂからレ
プリケーション要求があっても障害情報が登録されていないため、レプリケーションができず、サーバ拠点Ｂにおいてデータ信頼性に問題が生じる場合がある。

本発明は、少ないネットワーク帯域であっても、サーバ拠点とクライアント拠点とのデータ同期化を行い、クライアント拠点におけるデータの信頼性を向上させることを目的とする。

管轄する電力系統を監視制御する給電システムのデータを管理するサーバと、サーバと広域ネットワーク網にて接続された支援システムとを備え、サーバの第１のデータベースと支援システムの第２のデータベースとの同期を行うデータ配布システムである。サーバは、第１のデータベースを更新した際に支援システムに更新イベントを送信し、更新イベントの送信が失敗した場合に更新イベントを再送信するサーバ計算機を備え、支援システムは、更新イベントを受信した場合に第１のデータベースを取得する取得処理を行い、第１のデータベースの取得処理が失敗した場合に前記取得処理を行うクライアント計算機を備えた。

本発明に係るデータ配布システムは、サーバが第１のデータベースを更新した際に支援システムに更新イベントの送信を成功するまで行い、支援システムが更新イベントを受信した場合に第１のデータベースの取得を成功するまで行うので、少ないネットワーク帯域であっても、サーバが配置されたサーバ拠点と支援システムが配置されたクライアント拠点とのデータ同期化を行い、クライアント拠点におけるデータの信頼性を向上することができる。

本発明の広域分散監視制御システムの構成図である。 本発明の実施の形態１のデータ配布システムの構成図である。 図２のリトライ対象拠点テーブルの例である。 図２のリトライ周期テーブル１３２の例である。 図２のリトライ周期テーブル１３４の例である。 図２のデータベース取得完了テーブルの例である。 図２のデータベース更新制御部の処理フローを示す図である。 図２の更新イベント送信部の処理フローを示す図である。 図２のリトライ送信部の処理フローを示す図である。 図２の更新イベント送信部の処理フローを示す図である。 図２のクライアント拠点における処理フローを示す図である。 本発明の実施の形態２のデータ配布システムの構成図である。 図１２のリトライ対象拠点テーブルの例である。 図１２のデータベース更新制御部の処理フローを示す図である。 図１２の更新イベント送信部の処理フローを示す図である。 図１２のリトライ送信部の処理フローを示す図である。 図１２の更新イベント送信部の処理フローを示す図である。 図１２のクライアント拠点における処理フローを示す図である。

実施の形態１．
図１は、本発明の実施の形態１の広域分散監視制御システムの構成図である。図１の広域分散監視制御システム１００は電力系統を監視制御する構成を示している。広域分散監視制御システム１００は、中央給電所２１、基幹給電所２２、複数の給電制御所（サーバ拠点）１１、複数のクライアント拠点１２を備え、それぞれが広域ネットワーク網２６に
より接続さている。中央給電所２１は、中央給電システム３１を有し、電力系統全体を監視制御する。基幹給電所２２は、基幹給電システム３２を有し、電力系統における基幹系統を監視制御する。給電制御所１１は、サーバ３３を有し、管轄する複数の給電所２４や制御所２５のデータを管理する。給電所２４は、給電システム３４を有し、電力系統における地方系統を監視制御する。制御所２５は、制御システム３５を有し、電力系統の地方系統における下流系統を監視制御する。クライアント拠点１２は、支援システム３６を有る。支援システム３６は、給電制御所（サーバ拠点）１１のサーバ３３に収集された各種のデータを閲覧したり、管理したりする。

図２は、本発明の実施の形態１のデータ配布システムの構成図である。データ配布システム９０は、給電制御所（サーバ拠点）１１とクライアント拠点１２とが広域ネットワーク網２６により接続された構成である。サーバ拠点１１は、マスタとなるデータベースを保持する拠点である。クライアント拠点１２は、サーバ拠点１１からのデータベース配布対象となる拠点である。サーバ拠点１１に配置されたサーバ３３は、各種の処理を行うサーバ計算機５１と、サーバ計算機５１に指示を入力したり、サーバ計算機５１の処理結果を表示したりする端末１２１と、データベース１１１、リトライ対象拠点テーブル１３１、リトライ周期テーブル１３２を有する。サーバ計算機５１は、データベース更新制御部１０１、更新イベント送信部１０２、リトライ送信部１０３を有する。

クライアント拠点１２に配置された支援システム３６は、各種の処理を行うクライアント計算機５２と、データベース１１２ａ、１１２ｂ、データベース取得完了テーブル１３３、リトライ周期テーブル１３４を有する。サーバ計算機５１は、データベース更新制御部１０４、更新イベント受信部１０５、データベース取得部１０６を有する。また、図示しない端末からクライアント計算機５２にデータ表示等の指示を行い、その指示を実行した処理結果を端末に表示する。

リトライ対象拠点テーブル１３１は、図３に示すように１行の表であり、クライアント拠点数だけの列を持つ。なお、図３に示した例は、クライアント拠点１２が４拠点の場合である。リトライ対象拠点テーブル１３１の各欄には送信ステータスが記録される。リトライ対象拠点テーブル１３１のＣの列に記録されたステータス０（Ｃの列）は、該当クライアント拠点へのデータベース更新通知（更新イベント）の送信が成功していないことを表す。リトライ対象拠点テーブル１３１のＡ列、Ｂ列、Ｄ列に記録されたステータス１は、該当クライアント拠点へのデータベース更新通知（更新イベント）の送信が成功したことを表す。なお、ステータス１は成功ステータスであり、ステータス０は非成功ステータス（失敗ステータス）である。

リトライ周期テーブル１３２は、図４に示すように１行の表であり、次の実行までの待機時間が記録される。リトライ周期テーブル１３４は、図５に示すように１行の表であり、次の実行までの待機時間が記録される。データベース取得完了テーブル１３３は、図６に示すように１行の表であり、各欄には取得ステータスが記録される。ステータス０はデータベースの取得が成功していないことを表わし、ステータス１はデータベースの取得が完了（成功）したことを表わす。なお、ステータス１は成功ステータスであり、ステータス０は非成功ステータス（失敗ステータス）である。

次にデータ配布システム９０の動作を説明する。図７及び図８はサーバ拠点１１のデータベース更新発生時におけるクライアント拠点１２へのデータベース配布に関する処理フローである。図７はデータベース更新制御部の処理フローを示す図であり、図８は更新イベント送信部の処理フローを示す図である。図７のステップＳＴ１にて、データベース更新制御部１０１は、端末１２１からデータベース更新要求を受ける。ステップＳＴ２にて、リトライ送信部１０３が起動している場合は、データベース更新制御部１０１は、リトライ送信部１０３を停止させる。ステップＳＴ３にて、データベース更新制御部１０１は、自拠点のデータベース１１１を更新（変更を反映）し、また同時にリトライ対象拠点テーブル１３１の全拠点に０を設定する。ステップＳＴ４に進み、データベース更新制御部１０１は、更新イベント送信部１０２にデータベースの更新イベント（更新通知）の送信を依頼する。

図８のステップＳＴ１１にて、更新イベント送信部１０２は、データベース更新制御部１０１からの更新イベントの送信依頼を受け、ステップＳＴ１８までの処理を行う（更新イベント送信手順）。ステップＳＴ１２にて、更新イベント送信部１０２は、クライアント拠点１２の数だけステップＳＴ１２に戻ってくる処理ループを回す。ステップＳＴ１３にて、更新イベント送信部１０２は、全クライアント拠点１２の数だけループが回ったかを判定し、全クライアント拠点１２の数に達していればステップＳＴ１７に進み、全クライアント拠点１２の数に達していなければステップＳＴ１４に進む。ステップＳＴ１４にて、更新イベント送信部１０２は、リトライ対象拠点テーブル１３１のステータスが０であるクライアント拠点１２に更新イベントを送信する。更新イベント送信部１０２は、クライアント拠点１２の更新イベント受信部１０５とＴＣＰ／ＩＰプロトコルにより通信を行う。

ステップＳＴ１５にて、更新イベント送信部１０２は、更新イベント受信部１０５からのアック（ＡＣＫ）を受けて、送信が成功したかを判定し、成功の場合はステップＳＴ１６に進み、失敗の場合はステップＳＴ１２に戻って次のループの処理を行う。ステップＳＴ１６にて、更新イベント送信部１０２は、リトライ対象拠点テーブル１３１の該当拠点にステータスを１に設定し（送信ステータス設定手順）、ステップＳＴ１２に戻って次のループの処理を行う。これをクライアント拠点１２の数だけ繰り返す。ステップＳＴ１３にて、全クライアント拠点１２の数だけループが回ったと判定され、ステップＳＴ１７に進むと、更新イベント送信部１０２は、全拠点の送信が成功したかを、リトライ対象拠点テーブル１３１を参照して判定する。ステータスが０の拠点が一つでも存在すれば、ステップＳＴ１８にてリトライ送信部１０３を起動する。リトライ対象拠点テーブル１３１の全拠点のステータスが１の場合は、処理を終了する。

図９及び図１０はリトライ送信部１０３が起動された場合におけるクライアント拠点１２へのデータベース配布に関するサーバ拠点の処理フローである。図９はリトライ送信部の処理フローを示す図であり、図１０は更新イベント送信部の処理フローを示す図である。図９のステップＳＴ２１にて、リトライ送信部１０３は、リトライ対象拠点テーブル１３１を参照し、ステータスが０に設定されている拠点があるかを判定する。ステータスが０に設定されている拠点がある場合はステップＳＴ２２に進み、ステータスが０に設定されている拠点がない場合は終了する。ステップＳＴ２２にて、リトライ送信部１０３は、リトライ周期テーブル１３２で定義されている時間だけ待機する。例えば図４に示した１０秒間待機した後、ステップＳＴ２３にて、リトライ送信部１０３は、更新イベント送信部１０２にデータベースの更新イベント（更新通知）の送信を依頼する。

図１０のステップＳＴ３１にて、更新イベント送信部１０２は、リトライ送信部１０３からの更新イベントの送信依頼を受け、ステップＳＴ３４までの処理を行う（再信手順）。ステップＳＴ３２以降の処理は、図８のステップＳＴ１２からステップＳＴ１８の処理と同様であるが、ステップＳＴ３２、ＳＴ３３、ＳＴ３４にて、リトライ対象拠点テーブル１３１のステータスが０のクライアント拠点１２だけを対象にする点で異なる。ステップＳＴ３２にて、更新イベント送信部１０２は、リトライ対象拠点テーブル１３１のステータスが０のクライアント拠点１２の数だけステップＳＴ３２に戻ってくる処理ループを回す。ステップＳＴ３３にて、更新イベント送信部１０２は、該当するクライアント拠点１２の数だけループが回ったかを判定し、該当するクライアント拠点１２の数に達していればステップＳＴ３４に進み、該当するクライアント拠点１２の数に達していなければステップＳＴ１４に進む。ステップＳＴ３４にて、更新イベント送信部１０２は、該当拠点の送信が成功したかを、リトライ対象拠点テーブル１３１を参照して判定する。ステータスが０の拠点が一つでも存在すれば、ステップＳＴ１８にてリトライ送信部１０３を起動する。リトライ対象拠点テーブル１３１の全拠点のステータスが１の場合は、処理を終了する。

次にサーバ拠点１１からのデータベースの更新イベントを受信した場合にけるクライアント拠点１２の処理を説明する。図１１はクライアント拠点１２における処理フローを示す図である。ステップＳＴ４１にて、更新イベント受信部１０５は、サーバ拠点１１からのデータベースの更新イベントを受信する。ステップＳＴ４２にて、更新イベント受信部１０５は、データベース取得完了テーブル１３３のステータスに０を設定し、データベース取得部１０６にデータべース取得要求を行う。ステップＳＴ４３にて、データベース取得部１０６は、データベース取得完了テーブル１３３を参照し、ステップＳＴ４７までの処理を行う。

ステップＳＴ４４にて、データベース取得部１０６は、データベース取得完了テーブル１３３のステータスを判定する。ステータスが０の場合はステップＳＴ４５に進み、ステータスが１の場合は終了する。ステップＳＴ４５にて、データベース取得部１０６は、サーバ拠点１１のデータベース１１１を取得しに行く（取得処理手順）。データベース取得部１０６はデータベース更新制御部１０１とＴＣＰ／ＩＰプロトコルにより通信を行う。ステップＳＴ４６にて、データベース取得部１０６は、データベース更新制御部１０１からのアック（ＡＣＫ）を受けて、データベース１１１が正常に取得できたか判定する。正常に取得できた場合はステップＳＴ４７に進み、正常に取得できなかった場合はステップＳＴ４９に進む。ステップＳＴ４７にて、データベース取得部１０６は、データベース取得完了テーブル１３３のステータスを１に設定し（取得完了ステータス設定手順）、またデータベース更新制御部１０４にデータベース切り替え要求を出す。ステップＳＴ４６の判定で正常に取得できなかった場合は、ステップＳＴ４９にて、リトライ周期テーブル１３４で指定された時間だけ待機する。例えば図５に示した１０秒間待機した後、ステップＳＴ４５に戻り、再度データベース１１１を取得しに行く（再取得処理手順）。なお、実施の形態１では、データベース１１１を取得しに行く場合に、データベース１１１の全てを取得しに行く。

ステップＳＴ４７でデータベース取得部１０６からデータベース切り替え要求が出された場合、ステップＳＴ４８にて、データベース更新制御部１０４は、そのデータベース切り替え要求を受けて、使用中のデータベース１１２ａをサーバ拠点１１から取得したデータベース１１１が記録されたデータベース１１２ｂに切り替える（データベース切替え手順）。ステップＳＴ４６の判定で正常に取得できなかった場合は、データベース取得完了テーブルは更新されず、データベース１１２ａを使用する。

実施の形態１のデータ配布システム９０は、サーバ拠点１１はデータベース更新時にその情報を自拠点に記録（リトライ対象拠点テーブル１３１を０に設定）し、各クライアント拠点１２へのデータベースの更新通知（更新イベントの送信）が成功するまで、更新通知を定周期に実施する。各クライアント拠点１２は更新通知（更新イベント）があった情報を自拠点に記録（データベース取得完了テーブル１３３を０に設定）した後、サーバ拠点１１へのデータベース１１１の取得を定周期にて行うため、サーバ拠点１１のデータベース更新後にネットワーク障害やサーバ拠点１１、またはクライアント拠点１２の計算機ダウンが発生しても、これらの復旧直後にデータベース取得完了テーブル１３３の情報を参照してデータベース取得の動作を実行し、データベースの更新を行うことができる。したがって、各クライアント拠点１２のデータ信頼性を向上させることができる。

実施の形態１のデータ配布システム９０は、サーバ拠点１１から各クライアント拠点１２へはデータベースの更新通知（更新イベントの送信）だけを定周期で行い、データベース自体の配布は、サーバ拠点１１のデータベース更新後にネットワーク障害やサーバ拠点１１、またはクライアント拠点１２の計算機ダウンが発生した場合であっても、各クライアント拠点１２につき１度しか実施されない。したがって、広域ネットワーク網２６のネットワーク帯域が少ない場合、例えば１Ｍｂｐｓ程度に制限された場合であっても、サーバ拠点１１とクライアント拠点１２とのデータ同期化を行うことができる。少ないネットワーク帯域であっても、サーバ拠点１１とクライアント拠点１２とのデータ同期化を行うことができるので、クライアント拠点１２におけるデータの信頼性を向上させることができる。

なお、サーバ拠点１１は、サーバ計算機５１の起動の際にリトライ送信部１０３を起動するようにしてもよい。この場合は、サーバ計算機５１の起動の際に、リトライ送信部１０３が起動し、リトライ対象拠点テーブル１３１を参照し、ステータスが０に設定されている拠点がある場合は、ステップＳＴ２１からＳＴ２３の処理が行われ、更新イベント送信部１０２からクライアント拠点１２に更新イベント（更新通知）が送信される。したがって、クライアント拠点１２は、サーバ拠点１１のサーバ計算機５１の起動の際に、データベース取得処理を実行でき、サーバ拠点１１とクライアント拠点１２とのデータ同期化を遅滞なく行うことができる。

以上のように実施の形態１のデータ配布システム９０によれば、管轄する電力系統を監視制御する給電システム３４のデータを管理するサーバ３３と、サーバ３３と広域ネットワーク網２６にて接続された支援システム３６とを備え、サーバ３３は、第１のデータベース１１１を更新した際に支援システム３６に更新イベントを送信し、更新イベントの送信が失敗した場合に更新イベントを再送信するサーバサーバ計算機５１を備え、支援システム３６は、更新イベントを受信した場合に第１のデータベース１１１を取得する取得処理を行い、第１のデータベース１１１の取得処理が失敗した場合に前記取得処理を行うクライアントクライアント計算機５２を備えたことにより、サーバ３３が第１のデータベース１１１を更新した際に支援システム３６に更新イベントの送信を成功するまで行い、支援システム３６が更新イベントを受信した場合に第１のデータベース１１１の取得を成功するまで行うので、少ないネットワーク帯域であっても、サーバ拠点とクライアント拠点とのデータ同期化を行い、クライアント拠点におけるデータの信頼性を向上することができる。

実施の形態１の分散監視制御システム１００によれば、電力系統の全体を監視制御する中央給電システム３１と、電力系統における基幹系統を監視制御する基幹給電システム３２と、電力系統における地方系統を監視制御する給電システム３４と、給電システム３４のデータを管理するサーバ３３と、サーバ３３のデータを収集する支援システム３６と、中央給電システム３１、基幹給電システム３２、給電システム３４、サーバ３３、支援システム３６のそれぞれが接続された広域ネットワーク網２６とを備え、サーバ３３の第１のデータベース１１１と支援システム３６の第２のデータベース１１２ａ、１１２ｂとの同期を行うデータ配布システム９０は、管轄する電力系統を監視制御する給電システム３４のデータを管理するサーバ３３と、サーバ３３と広域ネットワーク網２６にて接続された支援システム３６とを備え、サーバ３３は、第１のデータベース１１１を更新した際に支援システム３６に更新イベントを送信し、更新イベントの送信が失敗した場合に更新イベントを再送信するサーバサーバ計算機５１を備え、支援システム３６は、更新イベントを受信した場合に第１のデータベース１１１を取得する取得処理を行い、第１のデータベース１１１の取得処理が失敗した場合に前記取得処理を行うクライアントクライアント計算機５２を備えたので、少ないネットワーク帯域であっても、サーバ拠点とクライアント拠点とのデータ同期化を行い、クライアント拠点におけるデータの信頼性を向上することができ、電力系統の監視制御を妨げることがない。したがって、実施の形態１の分散監視制御システム１００は、電力系統の監視制御を円滑に行うことができる。

実施の形態１のデータ配布方法によれば、サーバ３３が第１のデータベース１１１を更新した際に支援システム３６に更新イベントを送信する更新イベント送信手順と、更新イベントの送信が失敗した場合にサーバ３３が更新イベントを再送信する再送信手順と、支援システム３６が更新イベントを受信した場合に第１のデータベース１１１を取得する取得処理手順と、取得処理手順が失敗した場合に支援システム３６が前記取得処理手順を行う再取得処理手順とを含むことにより、サーバ３３が第１のデータベース１１１を更新した際に支援システム３６に更新イベントの送信を成功するまで行い、支援システム３６が更新イベントを受信した場合に第１のデータベース１１１の取得を成功するまで行うので、少ないネットワーク帯域であっても、サーバ拠点とクライアント拠点とのデータ同期化を行い、クライアント拠点におけるデータの信頼性を向上することができる。

実施の形態２．
実施の形態１では、サーバ拠点１１のデータベース１１１の更新が発生するとクライアント拠点１２はデータベース１１１を全てコピーする例で説明したが、クライアント拠点１２はサーバ拠点１１の生成する差分ファイルをコピーしてもよい。クライアント拠点１２が差分ファイルをコピーすることで、実施の形態１よりも少ないネットワーク帯域であっても、サーバ拠点１１とクライアント拠点１２とのデータ同期化を行うことができる。以下に説明する。

図１２は、本発明の実施の形態２のデータ配布システムの構成図である。実施の形態２のデータ配布システム９０（９０ｂ）は、実施の形態１のデータ配布システム９０（９０ａ）とは、サーバ拠点１１（１１ｂ）に配置されたサーバ３３（３３ｂ）のリトライ対象拠点テーブル１３１（１３１ｂ）の記録内容が差分対応となり、クライアント拠点１２（１２ｂ）に配置された支援システム３６（３６ｂ）のデータベース取得部１０６（１０６ｂ）がデータベース１１１と差分ファイル１１３とを取得できる点で異なる。サーバ３３（３３ｂ）のサーバ計算機５１（５１ｂ）におけるデータベース更新制御部１０１（１０１ｂ）、更新イベント送信部１０２（１０２ｂ）、リトライ送信部１０３（１０３ｂ）の処理フローが実施の形態１とは異なり、支援システム３６（３６ｂ）のクライアント計算機５２（５２ｂ）におけるデータベース取得部１０６（１０６ｂ）の処理フローが実施の形態１とは異なる。

図１３は、リトライ対象拠点テーブル１３１ｂの例である。リトライ対象拠点テーブル１３１ｂは、ｏｌｄ行（旧行）とｎｅｗ行（新行）の２行のテーブルとなり、クライアント拠点数だけの列を持つ。なお、図１３に示した例は、クライアント拠点１２が４拠点の場合である。リトライ対象拠点テーブル１３１ｂの各欄には送信ステータスと、データベース更新時の各クライアント拠点１２におけるデータベース更新完了ステータス（取得完了ステータス）が記録される。ｏｌｄ行は前回のデータベース更新時の送信ステータスとデータベース更新完了ステータスを表す。ｎｅｗ行は今回のデータベース更新時の送信ステータスとデータベース更新完了ステータスを表す。ステータス０（失敗ステータス）、ステータス１（成功ステータス）は、実施の形態１のリトライ対象拠点テーブル１３１（１３１ａ）と同様の意味を表す。ステータス２は、取得完了ステータスであり、当該クライアント拠点が当該データベースの取得を完了したことを表す。

次にデータ配布システム９０（９０ｂ）の動作を説明する。動作の説明については、実施の形態１からの変更点のみ説明する。図１４及び図１５はサーバ拠点１１（１１ｂ）のデータベース更新発生時におけるクライアント拠点１２（１２ｂ）へのデータベース配布
に関する処理フローである。図１４はデータベース更新制御部の処理フローを示す図であり、図１５は更新イベント送信部の処理フローを示す図である。

図１４のデータベース更新制御部１０１（１０１ｂ）の処理フローは、実施の形態１の図７とはステップＳＴ３がステップＳＴ５に変更された点で異なる。ステップＳＴ５にて、データベース更新制御部１０１（１０１ｂ）は、自拠点のデータベース１１１を更新（変更を反映）し、更新の差分ファイル１１３を生成し（差分ファイル生成手順）、また同時にリトライ対象拠点テーブル１３１（１３１ｂ）のｎｅｗ行に設定されてあるステータスをｏｌｄ行に上書きし、ｎｅｗ行にステータス０を設定する。図１５の更新イベント送信部１０２（１０２ｂ）の処理フローは、実施の形態１の図８とはステップＳＴ１６がステップＳＴ１９に変更された点で異なる。ステップＳＴ１９にて、更新イベント送信部１０２（１０２ｂ）は、リトライ対象拠点テーブル１３１（１３１ｂ）のｎｅｗ行にステータスを１に設定し（送信ステータス設定手順）、ステップＳＴ１２に戻って次のループの処理を行う。

図１６及び図１７はリトライ送信部１０３（１０３ｂ）が起動された場合におけるクライアント拠点１２（１２ｂ）へのデータベース配布に関するサーバ拠点の処理フローである。図１６はリトライ送信部の処理フローを示す図であり、図１７は更新イベント送信部の処理フローを示す図である。

図１６のリトライ送信部１０３（１０３ｂ）の処理フローは、実施の形態１の図９とはステップＳＴ２１がステップＳＴ２４に変更された点で異なる。ステップＳＴ２４にて、リトライ送信部１０３（１０３ｂ）は、リトライ対象拠点テーブル１３１（１３１ｂ）を参照し、ｎｅｗ行にステータスが０に設定されている拠点があるかを判定する。図１７の更新イベント送信部１０２（１０２ｂ）の処理フローは、実施の形態１の図１０とはステップＳＴ３２がステップＳＴ３５に変更され、ステップＳＴ１６がステップＳＴ３６に変更された点で異なる。ステップＳＴ３５にて、更新イベント送信部１０２（１０２ｂ）は、リトライ対象拠点テーブル１３１（１３１ｂ）におけるｎｅｗ行のステータスが０のクライアント拠点１２（１２ｂ）の数だけステップＳＴ３２に戻ってくる処理ループを回す。ステップＳＴ３６にて、更新イベント送信部１０２は、リトライ対象拠点テーブル１３１ｂのｅｗ行にステータスを１に設定し（送信ステータス設定手順）、ステップＳＴ１２に戻って次のループの処理を行う。

図１８はクライアント拠点１２（１２ｂ）における処理フローを示す図である。この処理フローは、実施の形態１の図１１とはステップＳＴ４５がステップＳＴ６１からＳＴ６４に変更され、ステップＳＴ４７がステップＳＴ６５に変更され、テップＳＴ４９がステップＳＴ６６に変更された点で異なる。ステップＳＴ６１からＳＴ６４は取得処理手順である。ステップＳＴ６１にて、データベース取得部１０６（１０６ｂ）は、サーバ拠点１１（１１ｂ）のリトライ対象拠点テーブル１３１（１３１ｂ）のｏｌｄ行を参照する（参照手順）。ステップＳＴ６２にて、ステータスが２であるかを判定すし、ステータスが２である場合はステップＳＴ６４に進み、ステータスが２でない場合はステップＳＴ６３に進む。ステップＳＴ６３にて、サーバ拠点１１（１１ｂ）のデータベース１１１を取得する。ステップＳＴ６４にて、ステータスが２の場合は、前回までのデータベースの差分ファイルが取得できていることから、現時点でサーバ拠点１１（１１ｂ）に配置されている差分ファイル１１３のみを取得する（コピーする処理を行う）。ステップＳＴ６５にて、データベース取得部１０６（１０６ｂ）は、データベース取得完了テーブル１３３のステータスを１に設定し、リトライ対象拠点テーブル１３１（１３１ｂ）の自拠点のｎｅｗ行のステータスを２に設定し（取得完了ステータス設定手順）、またデータベース更新制御部１０４にデータベース切り替え要求を出す。ステップＳＴ４６の判定で正常に取得できなかった場合は、ステップＳＴ６６にて、リトライ周期テーブル１３４で指定された時間だけ待機する。例えば図５に示した１０秒間待機した後、ステップＳＴ６１に戻り、再度データベース１１１または差分ファイル１１３を取得しに行く（再取得処理手順）。

以上のように、実施の形態２のデータ配布システム９０（９０ｂ）は、クライアント拠点１２（１２ｂ）がサーバ拠点１１（１１ｂ）の生成する差分ファイル１１３をコピーすることで実施の形態１よりもネットワークの帯域消費を抑えてクライアント拠点１２（１２ｂ）のデータベースの更新を行うことができる。

本発明に係るデータ配布システムは、電子計算機により機器を監視制御する監視制御システムや、ネットワーク上に分散配置されたサーバ拠点とクライアント拠点にてデータベースの同期を行う分散監視制御システムに利用できる。

１１、１１ａ、１１ｂ…給電制御所（サーバ拠点）、１２、１２ａ、１２ｂ…クライアント拠点、２６…広域ネットワーク網、３１…中央給電システム、３２…基幹給電システム、３３、３３ａ、３３ｂ…サーバ、３４、３４ａ、３４ｂ…給電システム、３６、３６ａ、３６ｂ…支援システム、５１、５１ａ、５１ｂ…サーバ計算機、５２、５２ａ、５２ｂ…クライアント計算機、９０、９０ａ、９０ｂ…データ配布システム、１００…広域分散監視制御システム、１０２、１０２ａ、１０２ｂ…更新イベント送信部、１０３、１０３ａ、１０３ｂ…リトライ送信部、１０５…更新イベント受信部、１０６、１０６ａ、１０６ｂ…データベース取得部、１１１、１１２ａ、１１２ｂ…データベース、１１３…差分ファイル、１３１、１３１ａ、１３１ｂ…リトライ対象拠点テーブル、１３３…データベース取得完了テーブル。

Claims (12)

1. 管轄する電力系統を監視制御する給電システムのデータを管理するサーバと、前記サーバと広域ネットワーク網にて接続された支援システムとを備え、前記サーバの第１のデータベースと前記支援システムの第２のデータベースとの同期を行うデータ配布システムであって、
   前記サーバは、サーバ拠点に配置され、前記第１のデータベースを更新した際に前記支援システムに更新イベントを送信し、前記更新イベントの送信が失敗した場合に前記更新イベントを再送信するサーバ計算機を備え、
   前記支援システムは、クライアント拠点に配置され、前記更新イベントを受信した場合に前記第１のデータベースを取得する取得処理を行い、前記第１のデータベースの取得処理が失敗した場合に前記取得処理を行うクライアント計算機を備えたデータ配布システム。
2. 前記サーバは、前記更新イベントの送信対象であるクライアント拠点に前記更新イベントを送信し、当該送信が成功したか否かを示す送信ステータスを記録したリトライ対象拠点テーブルを有し、
   前記サーバ計算機は、前記更新イベントを前記クライアント拠点に送信し、当該更新イベントの送信が成功した場合に、前記リトライ対象拠点テーブルの前記送信ステータスを成功ステータスに設定する更新イベント送信部を有することを特徴とする請求項１記載のデータ配布システム。
3. 前記サーバ計算機は、前記リトライ対象拠点テーブルを参照し、前記送信ステータスが成功ステータスでない前記クライアント拠点に対して、所定の時間が経過した後に前記更新イベントを当該クライアント拠点に送信するように、前記更新イベント送信部に前記更新イベントの送信を依頼するリトライ送信部を有することを特徴とする請求項２記載のデータ配布システム。
4. 前記サーバ計算機は、当該サーバ計算機の起動の際に、前記リトライ対象拠点テーブルを参照し、前記送信ステータスが成功ステータスでない前記クライアント拠点に対して、前記更新イベントを当該クライアント拠点に送信することを特徴とする請求項２または３に記載のデータ配布システム。
5. 前記支援システムは、前記クライアント拠点における前記第１のデータベースの取得処理を行い、当該データベースの取得が成功したか否か示す取得ステータスを記録したデータベース取得完了テーブルを有し、
   前記クライアント計算機は、前記更新イベントを受信する更新イベント受信部と、前記更新イベント受信部にて前記更新イベントが受信された場合に前記第１のデータベースを取得する取得処理を行うデータベース取得部とを有し、
   前記データベース取得部は、前記第１のデータベースの取得処理が成功した場合に、前記データベース取得完了テーブルの取得ステータスを成功ステータスに設定することを特徴とする請求項１乃至４のいずれか１項に記載のデータ配布システム。
6. 前記データベース取得部は、前記データベース取得完了テーブルを参照し、前記取得ステータスが成功ステータスでない場合に、所定の時間が経過した後に前記第１のデータベースを取得する取得処理を行うことを特徴とする請求項５記載のデータ配布システム。
7. 前記クライアント計算機は、当該クライアント計算機の起動の際に、前記データベース取得完了テーブルを参照し、前記取得ステータスが成功ステータスでない場合に、前記第１のデータベースを取得する取得処理を行うことを特徴とする請求項５または６に記載のデータ配布システム。
8. 前記サーバは、前記第１のデータベースを更新する際に、更新前の第１のデータベースとの差分ファイルを生成し、
   前記リトライ対象拠点テーブルは、今回の更新作業の状況を示す新行と更新前の前記更新作業の状況を示す旧行を有し、前記更新イベントの送信対象であるクライアント拠点毎に前記第１のデータベースの取得が完了したか否かを示し、かつ前記取得が完了した場合に取得完了ステータスが記録され、
   前記クライアント計算機は、前記更新イベントを受信した場合に前記リトライ対象拠点テーブルにおける当該クライアント拠点に対応する前記旧行を参照し、前記旧行のステータスが前記取得完了ステータスになっている場合は前記差分ファイルを取得する取得処理を行い、前記旧行のステータスが前記取得完了ステータスになっていない場合は前記第１のデータベースの全てを取得する取得処理を行うことを特徴とする請求項２乃至７のいずれか１項に記載のデータ配布システム。
9. 電力系統の全体を監視制御する中央給電システムと、前記電力系統における基幹系統を監視制御する基幹給電システムと、前記電力系統における地方系統を監視制御する給電システムと、前記給電システムのデータを管理するサーバと、前記サーバのデータを収集する支援システムと、前記中央給電システム、前記基幹給電システム、前記給電システム、前記サーバ、前記支援システムのそれぞれが接続された広域ネットワーク網と、を備え、前記サーバの第１のデータベースと前記支援システムの第２のデータベースとの同期を行うデータ配布システムは、請求項１乃至８のいずれか１項に記載のデータ配布システムであることを特徴とする分散監視制御システム。
10. 管轄する電力系統を監視制御する給電システムのデータを管理するサーバにおける第１のデータベースと、前記サーバと広域ネットワーク網にて接続された支援システムにおける第２のデータベースとの同期を行うデータ配布方法であって、
    前記サーバが前記第１のデータベースを更新した際に前記支援システムに更新イベントを送信する更新イベント送信手順と、前記更新イベントの送信が失敗した場合に前記サーバが更新イベントを再送信する再送信手順と、
    前記支援システムが前記更新イベントを受信した場合に前記第１のデータベースを取得する取得処理手順と、前記取得処理手順が失敗した場合に前記支援システムが前記取得処理手順を行う再取得処理手順と、を含むことを特徴とするデータ配布方法。
11. 前記サーバはサーバ拠点に配置され、前記支援システムはクライアント拠点に配置され、前記サーバは、前記更新イベントの送信対象である前記クライアント拠点に前記更新イベントを送信し、送信が成功したか否かを示す送信ステータスを記録したリトライ対象拠点テーブルを有し、
    前記サーバが前記更新イベントを前記クライアント拠点に送信し、当該更新イベントの送信が成功した場合に、前記サーバが前記リトライ対象拠点テーブルの前記送信ステータスを成功ステータスに設定する送信ステータス設定手順と、を含むことを特徴とする請求項１０記載のデータ配布方法。
12. 前記リトライ対象拠点テーブルは、今回の更新作業の状況を示す新行と更新前の前記更新作業の状況を示す旧行を有し、前記更新イベントの送信対象であるクライアント拠点毎に前記第１のデータベースの取得が完了したか否かを示し、かつ前記取得が完了した場合に取得完了ステータスが記録され、
    前記サーバが前記第１のデータベースを更新する際に、更新前の第１のデータベースとの差分ファイルを生成する差分ファイル生成手順と、
    前記支援システムが前記更新イベントを受信した場合に前記リトライ対象拠点テーブルにおける当該クライアント拠点に対応する前記旧行を参照する参照手順と、を含み、
    前記取得処理手順において、
    前記旧行のステータスが前記取得完了ステータスになっている場合は、前記支援システムが前記差分ファイルを取得し、前記旧行のステータスが前記取得完了ステータスになっていない場合は、前記支援システムが前記第１のデータベースの全てを取得することを特徴とする請求項１１記載のデータ配布方法。

Images