JPH08314768A - 監視制御システムにおけるイベントデータの管理方式 - Google Patents

Abstract

(57)【要約】 【目的】 イベントデータの管理に関する機能の充実を
図り、かつソフトウェアの流用率を向上させるとともに
拡張性を高めるようにした。 【構成】 図示破線で囲んだ部分がイベントデータ管理
サブシステムであり、このサブシステムはイベントデー
タ管理プロセス１とイベントデータの管理のために構築
されたデータベース２からなり、データベース２はイベ
ントデータファイル２Ａとイベントファイルアクセス用
データ２Ｂからなる。一般アプリケーションプロセス３
は登録要求受付用（キューターミナルＱ１）に接続さ
れ、また一般アプリケーション４は検索、追加、イニシ
ャライズ、バックアップ要求受付用（キューターミナル
Ｑ２）に接続される。イベントデータ受け渡し用ファイ
ル５は一般アプリケーション４に接続される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、様々な運転業務の効
率化と系統の安定した運用を目的として制御所等に配置
される計算機システムからなる監視制御システムにおけ
るイベントデータの管理方式に関する。

【０００２】

【従来の技術】監視制御システムには次に述べるような
２大機能がある。

【０００３】（１）監視制御機能：テレコン等の伝送装
置を経由して、管轄地区に散在する各種の機器を監視す
る。

【０００４】（２）ロギング機能：イベントデータ記
録、帳票記録等を作成する。なお、イベントデータとは
次のような記録データのことである。機器の操作メッセ
ージ、機器の故障メッセージ、事故のメッセージ、監視
機能からのメッセージ、システムの異常メッセージ等で
ある。

【０００５】監視制御システムにおけるイベントデータ
記録は、機器の操作内容等のイベントデータ（メッセー
ジ）をリアルタイムに専用プリンタに印字したり、ＣＲ
Ｔ画面に表示を行うものである。また、蓄積されたイベ
ントデータの中から、オペレータの指定した日付けおよ
び種別（機器操作、機器故障等の）の条件に合ったイベ
ントデータを印字または画面表示させることも可能であ
る。これらの機能を実現するために、イベントデータが
どのように管理されているかの方式を図３４により述べ
る。なお、図３４は現行のイベントデータ管理方式の概
念図で、この図３４において、３４ａ，３４ｂは一般ア
プリケーションプロセス、３４ｃはプリンタ、３４ｄは
ＣＲＴ、３４ｅはイベントデータ登録プロセス、３４ｆ
はイベントデータファイルである。まず、機能に付いて
述べる。

【０００６】（１）機能：イベントデータの管理に関し
ては次の２つの機能がある。ただし、検索機能はイベン
トデータの検索を必要とする一般アプリケーションプロ
セスが独自に行っている。なお、プロセスとは、計算機
におけるソフトウェアの最小実行単位のことである。

【０００７】（ａ）登録機能：一定件数または期間のイ
ベントデータを保存する。

【０００８】（ｂ）検索機能：日付けおよび種別の指定
により、条件に一致したイベントデータを検索する。

【０００９】（２）プロセス間コミュニケーションデー
タ：前述のように、イベントデータの検索を必要とする
一般アプリケーションプロセスは、直接イベントデータ
を参照（READ ONLY）し、指定された条件に一致したデ
ータを検索している。従って、イベントデータ管理に関
するプロセス間コミュニケーションデータは、登録要求
だけである。

【００１０】（ａ）登録要求：イベントデータの登録を
必要とする一般アプリケーションプロセス３４ａは、イ
ベントデータ登録プロセス３４ｅに対して登録要求を行
う。

【００１１】（ｂ）検索要求：なし。

【００１２】（３）データ：イベントデータは次のデー
タによって管理されている。イベントデータファイル３
４ｆは、実際のイベントデータが蓄積されるデータ部と
そのデータ部をコントロールする管理部から構成されて
いて、管理部には図３５（データフォーマット）に示す
ようにデータ部内における最古および最新イベントデー
タのレコード番号（位置）等の管理情報が格納されてい
る。なお、最古イベントデータのレコード番号はイベン
トデータファイルのデータ部において、最も古いイベン
トデータが格納されているレコード番号、また、最新イ
ベントデータのレコード番号は最も新しいイベントデー
タが格納されているレコード番号である。

【００１３】データ部にはイベントデータが図３５に示
すように登録（発生）順に格納されていて、そのイベン
トデータには発生時刻、種別、その他の固有情報が格納
されている。なお、データ部に空きがなくなった場合に
は最古イベントデータから削除され、サイクリックに使
用される。

【００１４】（４）処理は次に示すように登録処理と検
索処理からなり、図３６、図３７はそれぞれのフローチ
ャートである。

【００１５】（ａ）登録処理：一般アプリケーションプ
ロセスから登録要求を受けたイベントデータ登録プロセ
スの処理は図３６に示すように行われる。図３６におい
て、ステップＳ１はイベントデータファイル（データ
部）の空きレコード番号を求めるものである。次にイベ
ントデータファイル（データ部）に空きレコード番号が
あるかをステップＳ２で判定し、空きがあるときには、
イベントデータファイル（管理部）の最古レコード番号
＝０、空きレコード番号＝イベントデータファイル（管
理部）の最新レコード番号＝１とし、前記イベントデー
タファイル（データ部）に空きがないときには、イベン
トデータファイル（管理部）の最古レコード番号≠０、
空きレコード番号＝イベントデータファイル（管理部）
の最古レコード番号とする。

【００１６】ステップＳ２で空きレコード番号があると
判定されたとき、ステップＳ３に進んで、指定されたイ
ベントデータを前述のようにして求められたイベントデ
ータファイル（データ部）の空きレコード番号に登録す
る。その後、ステップＳ４でイベントデータファイル
（管理部）のレコード番号を更新する。

【００１７】前記ステップＳ２で空きレコード番号がな
いときには、ステップＳ５の処理を行う。ステップＳ５
の処理は最古レコード番号にイベントデータを登録す
る。その後、ステップＳ４の処理を行う。ステップＳ４
の処理において、イベントデータファイル（データ部）
に空きがあるとき、管理部の最古レコード番号＝０であ
ると、最新レコード番号≠最大イベントデータ数とな
り、最古レコード番号＝１であると、最新レコード番号
＝最大イベントデータ数となる。

【００１８】また、イベントデータファイル（データ
部）に空きがないとき、管理部の最古レコード番号≠０
であると、最古レコード番号＝最古レコード番号＋１に
なって、最新レコード番号≠最大イベントデータ数とな
り、最古レコード番号＝１であると、最新レコード番号
＝最大イベントデータ数となる。

【００１９】（ｂ）検索処理：イベントデータの検索を
必要とする一般アプリケーションプロセスが図３７に示
すように行われる。図３７において、Ｓ１１はイベント
データファイル（管理部）から最古レコード番号を取得
するステップで、このステップＳ１１で取得したレコー
ド番号が最新レコード番号であるかをステップＳ１２で
判定する。判定の結果「ＹＥＳ」のときには、処理を終
了し、「ＮＯ」のときには、イベントデータファイル
（データ部）からイベントデータをステップＳ１３で取
得する。取得されたイベントデータは検索条件に一致す
るかをステップＳ１４で判定し、検索条件に、一致「Ｙ
ＥＳ」したなら、当該イベントデータをステップＳ１５
でセーブする。セーブ後、次の検索イベントデータをス
テップＳ１６で取得し、再び、ステップＳ１２から処理
を行う。なお、ステップＳ１４で検索条件が一致しない
ならステップＳ１６の処理に移る。

【００２０】

【発明が解決しようとする課題】上記のように構成され
た従来のイベントデータ管理方式では次に述べるような
問題がある。

【００２１】（１）イベントデータの管理に関する機能
は登録機能と検索機能があるが、クライアントの要望お
よびイベントデータ関連の障害に対するメーカーの対応
方法等を考慮すると、追加機能、削除機能といった他の
機能も必要になってくるが、それらはそれぞれ別々のプ
ロセスで実行されるために、イベントデータ関連機能が
貧弱である。

【００２２】（２）監視制御システムにおけるロギング
機能、取り分けイベントデータ記録はシステムにとって
必要不可欠な機能である。一方、ソフトウェアの見地か
ら見ると、登録処理は専用のプロセスが、検索処理は一
般アプリケーションプロセスが実行しており、イベント
データの管理に関する処理は独立していない。従って、
同等のシステムへの流用を除き、新たにシステムを開発
するような場合は、一般アプリケーションの処理だけで
なく、イベントデータの管理に関する処理も開発しなけ
ればならなくなる。このため、ソフトウェアの流用率が
低下する問題がある。

【００２３】（３）イベントデータの管理に関する機能
の追加や変更、また、保存するイベントデータ数等のシ
ステムレベルの定数を変更するような場合、従来の方式
では、イベントデータの管理に関する処理が他の一般ア
プリケーション処理と関連を持ってしまっているため、
ちょっとした変更でも大掛かりな作業になってしまい、
拡張性に乏しい問題がある。

【００２４】この発明は上記の事情に鑑みてなされたも
ので、イベントデータの管理に関する機能の充実を図
り、かつソフトウェアの流用率を向上させるとともに拡
張性を高めるようにした監視制御システムにおけるイベ
ントデータの管理方式を提供することを目的とする。

【００２５】

【課題を解決するための手段および作用】この発明は、
上記の目的を達成するために、第１発明は、監視制御シ
ステムにおける機器の操作、機器の故障、事故等のメッ
セージからなるイベントデータを、登録処理機能および
検索処理機能プログラムを有するコンピュータにより管
理する方法において、前記２つの処理機能の他に追加処
理、削除処理、イニシャライズ処理およびバックアップ
処理機能プログラムを有するイベントデータ管理サブシ
ステムを形成し、このサブシステムにイベントデータ管
理プログラムを設け、この管理プログラムのためのデー
タべースを構築して、前記登録処理機能プログラムから
のイベントデータ登録要求に対してデータベースを元に
そのデータの登録処理を行い、検索処理機能プログラム
からのイベントデータ検索要求に対してデータベースを
元にその検索処理を行うとともに、イベントデータ追
加、削除、イニシャライズおよびバックアップ処理要求
に対してもデータベースを元にそれらデータ処理を要求
により順次行うようにしたことを特徴とすものである。

【００２６】第２発明は、前記データベースには前記登
録、検索処理機能プログラムに対して指定されたイベン
トデータをデータベースに保存するとともに、指定され
た検索条件と一致するイベントデータをデータベースの
中から検索し、しかも、イベントデータの追加があった
ときにはデータベースに追加を行い、前以て検索された
イベントデータの中から指定されたイベントデータをデ
ータベースから削除するようにしたことを特徴とするも
のである。

【００２７】第３発明は、前記データベースはイベント
データファイルとイベントファイルアクセス用データか
ら構築されているものである。

【００２８】第４発明は、前記イベントデータファイル
アクセス用データは時間ルートインデックス用データと
種別ルートインデックス用データからなることを特徴と
するものである。

【００２９】

【実施例】以下この発明の実施例を図面に基づいて説明
する。図１はこの発明の実施例を示すイベントデータ管
理サブシステムの概念図で、図１において、図示破線で
囲んだ部分がイベントデータ管理サブシステムであり、
このサブシステムはイベントデータ管理プロセス１とイ
ベントデータの管理のために構築されたデータベース２
からなり、データベース２は後述するイベントデータフ
ァイル２Ａとイベントファイルアクセス用データ２Ｂか
らなる。３、４は一般アプリケーションプロセス、５は
イベントデータ受け渡し用ファイルである。

【００３０】上記のように構成されたサブシステムにお
いては、データベース２を元に一般アプリケーションプ
ロセス３、４に対して次のような６つの機能を持ってい
る。以下各機能に付いて述べる。

【００３１】（ａ）登録機能：指定されたイベントデー
タを実施例のサブシステムのデータベース２に一定件数
または一定期間保存する機能、 （ｂ）検索機能：指定された検索条件と一致するイベン
トデータをサブシステムのデータベース２の中から検索
する機能、 （ｃ）追加機能：指定されたイベントデータをサブシス
テムのデータベース２の所定の位置に追加する機能、 （ｄ）削除機能：前以て検索されたイベントデータの中
から、指定されたイベントデータをサブシステムのデー
タベース２から削除する機能、 （ｅ）イニシャライズ機能：サブシステムの保守機能の
ひとつで、ディスク上にセーブしてあるイベントデータ
アクセス用セーブデータをメモリ上に展開する第１のイ
ニシャライズ処理機能と、イベントデータ保存用データ
を元にイベントデータアクセス用データを再構築する第
２のイニシャライズ処理機能、 （ｆ）バックアップ機能：サブシステムの保守機能のひ
とつで、メモリ上のイベントデータアクセス用データを
ディスク上にセーブする機能である。

【００３２】次にプロセス間コミュニケーションデータ
の授受についてのべる。上記実施例のサブシステムの機
能を必要とする一般アプリケーションプロセス３、４は
各処理要求をサブシステム専用の受信用キューターミナ
ルＱ１，Ｑ２に対して発行する。このとき、必要に応じ
てイベントデータ受け渡し用ファイル５も使用する。ま
た、同期を取る必要のある処理要求に対して、サブシス
テムは処理終了応答を専用の処理終了応答キューターミ
ナルＱａから一般アプリケーションプロセス４に通知す
る。

【００３３】以下この実施例の受信用キューターミナル
Ｑ１，Ｑ２の処理シーケンス、処理要求データ（Ｉ／Ｆ
データ、イベントデータ受け渡し用データ等）について
説明する。なお、受信用キューターミナルＱ１，Ｑ２
は、それぞれ処理の優先順位がＱ１＞Ｑ２に設定されて
いる。

【００３４】キューターミナルＱ１は登録要求を受け付
け、イベントデータ受け渡し用ファイル５は使用しな
い。このときの処理シーケンスは図２に示すように一般
アプリケーションプロセス３とは非同期に処理される。
すなわち、一般アプリケーションプロセス３からの登録
要求をイベントデータ管理プロセス１が受け付け、その
後データベース２との間で登録を処理する。

【００３５】Ｉ／Ｆデータ：本キューターミナルＱ１を
介して通知される処理要求データには次のものがある。

【００３６】登録要求データ：一般アプリケーションプ
ロセス３がイベントデータ管理サブシステムに対してイ
ベントデータの登録要求を行うときに使用するキュータ
ーミナルＱ１のＩ／Ｆデータフォーマットを図３に示
す。図３において、種別にはＩ／Ｆデータを識別するた
めに、本サブシステムで定めた値が格納され、要求元プ
ロセス番号には本サブシステムに対して処理要求を行っ
た一般アプリケーションプロセス３のプロセス番号が格
納され、データ部サイズにはデータサイズが格納されて
いて、データ部には処理要求の対象となるイベントデー
タが図示のように格納されている。

【００３７】次にキューターミナルＱ２について述べ
る。キューターミナルＱ２は検索、追加、削除、イニシ
ャライズ、バックアップの各要求を受け付ける。なお、
検索、追加、イニシャライズ、バックアップ受け渡し用
ファイルを使用してイベントデータの授受を行う。この
ときの処理シーケンスは図４に示すように行われる。

【００３８】まず、一般アプリケーションプロセス４と
同期を取って次のようなシーケンス処理を行う。なお、
図４に示す符号〔１〕〜〔７〕は処理順序である。

【００３９】〔１〕イベントデータ受け渡し用ファイル
５に処理対象データが設定される（検索要求、追加要
求、削除要求の場合）、〔２〕一般アプリケーションプ
ロセス４からの検索要求、追加要求、削除要求などの処
理要求をイベントデータ管理プロセス１が受信し、
〔３〕イベントデータ受け渡し用ファイル５をイベント
データ管理プロセス１が読み込む（検索要求、追加要
求、削除要求の場合）、〔４〕管理プロセス１が処理要
求に対する処理を行い、〔５〕管理プロセス１がイベン
トデータ受け渡し用ファイル５に処理結果データを設定
し（検索要求の場合）、〔６〕イベントデータ管理プロ
セス１から一般アプリケーションプロセス４に処理要求
に対する応答を返し、〔７〕検索要求の場合、イベント
データ受け渡し用ファイル５が一般アプリケーションプ
ロセス４に読み込まれてシーケンスが終わる。

【００４０】Ｉ／Ｆデータ：本キューターミナルＱ２を
介して通知される処理要求データには次のものがある。

【００４１】ａ．検索要求データ：一般アプリケーショ
ンプロセス４がイベントデータ管理サブシステムに対し
てイベントデータの検索要求を行うときに使用するキュ
ーターミナルＱ２のＩ／Ｆデータ（イベントデータ受け
渡し用ファイル使用）フォーマットを図５に示す。な
お、検索条件はイベントデータ受け渡し用ファイル５に
設定しておく。図５において、種別にはＩ／Ｆデータを
識別するために、本管理サブシステムで定めた値が格納
され、要求元プロセス番号にはサブシステムに対して処
理要求を行った一般アプリケーションプロセスのプロセ
ス番号が格納され、ファイル番号、レコード番号および
データサイズには処理要求の対象となるデータが設定さ
れているイベントデータ受け渡し用ファイルのファイル
番号、レコード番号およびデータサイズが格納されてい
る。

【００４２】ｂ．追加要求データ：一般アプリケーショ
ンプロセス４が本サブシステムに対してイベントデータ
の追加要求を行うときに使用するキューデータフォーマ
ットを図５に示す。なお、追加したいイベントデータは
イベントデータ受け渡し用ファイル５に設定しておく。

【００４３】ｃ．削除要求データ：上記ａ，ｂと同様に
イベントデータの削除要求を行うときに使用するキュー
データフォーマット（図５）である。なお、削除したい
イベントデータの情報はイベントデータ受け渡し用ファ
イル５に設定しておく。

【００４４】ｄ．イニシャル要求データ：一般アプリケ
ーションプロセス４が本サブシステムに対してイベント
データのイニシャル要求を行うときに使用するキュータ
ーミナルＱ２のＩ／Ｆデータ（イベントデータ受け渡し
用ファイル未使用）フォーマットを図６に示す。なお、
図６はイベントデータ受け渡し用ファイルには使用しな
い。

【００４５】ｅ．バックアップ要求データ：上記と同様
にイベントデータのバックアップ要求を行うときに使用
するキューデータフォーマット（図６）である。なお、
図６はイベントデータ受け渡し用ファイルには使用しな
い。図６における種別、要求元プロセス番号は図５の場
合と同様である。

【００４６】次に処理終了応答の場合のＩ／Ｆデータと
して、本キューターミナルＱ２を介して通知する処理要
求応答データには次のａ〜ｅがある。

【００４７】ａ．検索要求応答データ：一般アプリケー
ションプロセスからの検索要求に対してサブシステムが
要求元プロセスに通知する処理終了応答Ｉ／Ｆデータ
（イベントデータ受け渡し用ファイル使用）フォーマッ
トを図７に示す。なお、検索結果はイベントデータ受け
渡し用ファイルに設定される。

【００４８】ｂ．追加要求応答データ：一般アプリケー
ションプロセスからの追加要求に対してサブシステムが
要求元プロセスに通知する応答Ｉ／Ｆデータ（イベント
データ受け渡し用ファイル未使用）フォーマットを図８
に示す。なお、イベントデータ受け渡し用ファイルは使
用しない。

【００４９】ｃ．削除要求応答データ：一般アプリケー
ションプロセスからの削除要求に対してサブシステムが
要求元プロセスに通知するデータフォーマットを図８に
示す。なお、イベントデータ受け渡し用ファイルは使用
しない。

【００５０】ｄ．イニシャル要求応答データ：一般アプ
リケーションプロセスからのイニシャル要求に対してサ
ブシステムが要求元プロセスに通知するデータフォーマ
ットを図８に示す。なお、応答時は、イベントデータ受
け渡し用ファイルは使用しない。

【００５１】ｅ．バックアップ要求応答データ：一般ア
プリケーションプロセスからのバックアップ要求に対し
てサブシステムが要求元プロセスに通知するデータフォ
ーマットを図８に示す。なお、イベントデータ受け渡し
用ファイルは使用しない。

【００５２】一般アプリケーションプロセスがイベント
データ管理サブシステムへの処理要求時に設定するイベ
ントデータ受け渡し用データには次のａ〜ｃがある。

【００５３】ａ．検索要求受け渡し用データフォーマッ
トは、図９に示すように、一般アプリケーションプロセ
スがイベントデータ検索要求時に検索条件を設定するも
ので、次のような属性を指定する。

【００５４】（イ）検索順：イベントデータの古い方か
ら検索するのか、新しい方から検索するのかを指定す
る。

【００５５】（ロ）検索数：本属性を除いた条件で検索
されたイベントデータの中で、何番目（開始番号）から
何番目（終了番号）までを転送するかを指定する。本サ
ブシステムでは、検索要求によって検索されたイベント
データ（ただし、検索数属性を除く）を“EQID(Event Q
ueue ID)”というシーケンシャル番号で管理し、本属性
ではこのEQIDを指定する。なお、EQIDはイベントデータ
の削除要求時にも使用される。

【００５６】（ハ）検索条件（時間）：検索したいイベ
ントデータの時刻の範囲を指定する。

【００５７】本サブシステムでは、イベントデータの種
別と種別内容を１条件（最小単位）とし、サブストッパ
ーまでの全条件のANDを取ったものを１つのAND条件グル
ープとする。同様に全サブストッパーまでのAND条件グ
ループとストッパーまでのAND条件グループの全てのOR
を取ったものが検索条件（種別）に一致したイベントデ
ータとなる。イベントデータの種別と種別内容の例を次
表に示す。

【００５８】

【表１】

【００５９】ｂ．追加要求受け渡し用データフォーマッ
トは、図１０に示すような、一般アプリケーションプロ
セスがイベントデータ追加要求時に追加したいイベント
データを設定するものである。

【００６０】ｃ．削除要求受け渡し用データフォーマッ
トは、図１１に示すような、一般アプリケーションプロ
セスがイベントデータ削除要求時に削除したいイベント
データのEQIDを設定するものである。

【００６１】図１２はイベントデータ応答受け渡し用デ
ータの検索要求応答受け渡し用のデータフォーマット
で、このフォーマットはイベントデータ検索要求に対す
る検索結果が設定されているものである。図１２のデー
タフォーマットにおいて、継続データ有無には、本サブ
システムによって検索されたイベントデータは、検索条
件に設定されたイベントデータ受け渡し用ファイルと同
じファイル番号、同じコード番号から書き込まれる（図
７参照）。従って、検索されたイベントデータ数が多く
指定されたバッファに入り切らないような場合は継続デ
ータ有無を「有」に設定する。

【００６２】図１３は本イベントデータ管理サブシステ
ムに使用されるデータベース概念図で、本イベントデー
タ管理サブシステムにデータベースが使用されるのは、
イベントデータの保存およびイベントデータの高速アク
セスのためである。このため、図１３に示すようなイベ
ントデータ管理サブシステムデータベース１３ａが構築
される。この図１３において、イベントデータ保存用デ
ータ１３ｂはイベントデータを保存しておくためのデー
タで、次に示すようなものがある。

【００６３】図１４はイベントデータフォーマットで、
そのフォーマットにはイベントデータが保存されてい
る。本サブシステムでは、イベントデータファイル内の
イベントデータの格納位置（レコード番号）を“EVID
（Event ID）”で表現する。なお、イベントデータファ
イル内の並びはイベントデータの登録（発生）時刻順と
は限らない。

【００６４】なお、前記図１３において、１３ｃはイベ
ントデータアクセス用データで、このデータはイベント
データ保存用データを効率良くアクセスするためのもの
で、時間ルートインデックス用データ１３ｄと種別ルー
トインデックス用データ１３ｅがある。

【００６５】前者の時間ルートインデックス用データ１
３ｄはイベントデータの時間ルートを管理するためのデ
ータで、インデックスデータはイベントデータの登録
（発生）時刻順を管理するデータである。このデータは
イベントデータファイルと対応しており、時間的に最も
古いイベントデータから最も新しいイベントデータデー
タまでがEVIDのチェーンで繋がっている。また、イベン
トデータファイル内の未使用のEVIDも図１５（インデッ
クスデータフォーマット）に示すようにチェーンで繋ぎ
管理している。また、日付けインデックスデータは、図
１６（日付けインデックスデータフォーマット）に示す
ように一日の一番最後に登録された（発生した）イベン
トデータおよびイベントデータファイル内の一番新しい
イベントデータの日付けを管理するデータである。

【００６６】後者の種別ルートインデックス用データ１
３ｅはイベントデータの種別ルートを管理するためのデ
ータで、このデータの中にはポインターデータ、種別内
容データおよび種別データがある。

【００６７】ポインターデータは、図１７（ポインター
データフォーマット）に示すように、イベントデータを
種別毎に管理するデータで、このデータは種別毎にイベ
ントデータファイルと対応しており、各種別の種別内容
がEVIDのチェーンで繋がる。なお、チェーンの先頭、最
後のEVIDの管理は種別内容データで行う。図１７におい
て、前EVIDは当該EVIDの１つ前に登録されたイベントデ
ータのＥVIDが格納されている。「０」で先頭EVIDとな
る。また、後EVIDは当該EVIDの１つ後に登録されたイベ
ントデータのＥVIDが格納されている。「０」で最後EVI
Dとなる。

【００６８】種別内容データは、図１８（種別内容デー
タフォーマット）に示すように、ポインターデータにお
ける各種別の種別内容毎のチェーンの先頭と最後を管理
するデータである。なお、種別内容位置（レコード番
号）は、種別データより求める（種別内容オフセット＋
種別内容）。図１８において、先頭EVIDには当該種別内
容位置（種別および種別内容により一意に決まる）を持
つイベントデータの中で先頭のイベントデータのEVIDが
格納されている。また、最後EVIDには当該種別内容位置
（種別および種別内容により一意に決まる）を持つイベ
ントデータの中で最後のイベントデータのEVIDが格納さ
れている。

【００６９】種別データは、図１９（種別データフォー
マット）に示すように、イベントデータの種別毎の固有
の情報（種別数、種別内容数他）を管理するデータであ
る。図１９において、種別内容数には当該種別の種別内
容数が格納され、種別内容オフセットには当該種別の種
別内容オフセットが格納され、イベントデータ内オフセ
ットには当該種別のイベントデータオフセット（当該種
別の内容がイベントデータ内のどの位置に設定されてい
るか）が格納され、イベントデータ内サイズには当該種
別のイベントデータ内サイズがそれぞれ格納されてい
る。なお、図２０、図２１は上記のデータ関連を表した
データ関連説明図である。

【００７０】１３ｆは前記図１３に示したイベントデー
タアクセス用セーブデータで、このデータ１３ｆはメモ
リ上のイベントデータアクセス用データをセーブしてお
くためのディスクデータであり、インデックスデータ、
日付けインデックスデータ、ポインターデータ、種別内
容データおよび種別をセーブするデータがある。

【００７１】次に前述した各機能の処理概要について述
べる。まず、図２２のフローチャートにより登録処理に
ついて述べる。図２２の登録処理において、ステップＳ
２１でイベントデータファイルにおける空きEVIDを求め
る。EVIDがあるかどうかをステップＳ２２で判定し、空
きの先頭EVID＝0（空きEVID無し）のときは、ステップ
Ｓ２３の処理でインデックスデータ（管理部）の最古EV
IDの削除処理を行う。一方、ステップＳ２２で空きの先
頭EVID≠0（空きEVID有り）のときには、ステップＳ２
４の処理を行う。この処理はステップＳ２３の削除処理
の後も行う。

【００７２】ステップＳ２４の処理はイベントデータを
ステップＳ２１で求めたイベントデータファイルの空き
EVIDに登録する。その後、ステップＳ２５でインデック
スデータを更新する。この更新処理においては、図２３
（インデックスデータの更新処理説明図）に示すよう
に、インデックスデータ（管理部）の最新EVIDを参照
し、インデックスデータ（データ部）における時間順チ
ェーンの最新EVIDの後に今回登録したイベントデータの
EVIDを繋げる。その後、インデックスデータ（管理部）
の空きの先頭EVIDを参照し、インデックスデータ（デー
タ部）における空きのEVIDのチェーンを繋ぎかえる。そ
して、インデックスデータ（管理部）の最新EVIDと空き
の先頭EVIDを図示ＡブロックからＢブロックに示すよう
に更新する。

【００７３】上記ステップＳ２５の処理の後、ステップ
Ｓ２６で日付けインデックスデータを更新する。このス
テップＳ２６では、登録したイベントデータから発生時
刻を取り出し、その日付けの日付けインデックスデータ
（データ部）を参照し、当該日の最終登録EVIDを取得す
る。インデックスデータ（データ部）から上記で取得し
たEVIDの発生時刻を取得する。登録したイベントデータ
の発生時刻と上記で取得した発生時刻を比較し、日付け
インデックスデータ（データ部）を更新する。その後、
日付けインデックスデータ（管理部）の最終登録日付け
を更新する。

【００７４】ステップＳ２６の処理が終了したなステッ
プＳ２７のポインターデータを更新する処理を図２４
（種別内容データ、ポインターデータの更新処理説明
図）に示すように行う。この処理では、まず、登録した
イベントデータから種別と種別内容を取り出し、種別デ
ータを参照し、上記で取り出した種別の種別内容オフセ
ットを求め、種別内容データにおける種別内容位置を計
算する（種別内容オフセット＋種別内容）。計算した種
別内容位置の種別内容データを取得する。取得した最後
EVIDを元にポインターデータの当該種別／種別内容のチ
ェーンの後に、今回登録したイベントデータのEVIDを繋
げ、登録したイベントデータの全種別について上記の処
理を繰り返す。すなわち、図２４に示すＡブロックをＢ
ブロックのように更新する。

【００７５】ステップＳ２７の処理が終了したならステ
ップＳ２８の種別内容データを更新する処理を行う。こ
の処理は、登録したイベントデータの全種別について上
記で取得した種別内容データを更新する。その後、上記
の処理を登録要求データ内の全イベントデータについて
行う。

【００７６】次に検索処理について図２５のフローチャ
ートにより述べる。ステップＳ３１で検索条件（種別）
に一致したイベントデータのEVIDを求める。この検索条
件の内容は次のように行われる。

【００７７】ａ．検索要求受け渡し用データ内の検索条
件（種別）の１条件の種別と種別内容から種別データの
種別内容オフセットを取り出し、種別内容データにおけ
る種別内容位置を計算する。

【００７８】ｂ．上記ａで求めた種別内容位置の種別内
容データを参照し、ポインターデータの先頭EVIDから最
終EVIDまでのチェーンをたどっていくことにより当該１
条件に一致するEVIDを取得する。

【００７９】ｃ．上記ａ．ｂの処理をサブストッパーま
たはストッパーが現れるまで繰り返し、各条件で取得し
たEVIDのANDを取ったAND条件グループを作成する。

【００８０】ｄ．上記ｃで求めたAND条件グループのOR
を取ったものが、検索条件（種別）に一致するEVIDとな
る。

【００８１】ステップＳ３１の処理が終了したなら、ス
テップＳ３２の検索条件（時間）の検索方向を求める。
これには検索要求受け渡し用データ内の検索順を参照す
る。その後、検索条件に一致したイベントデータのEVID
をステップＳ３３で求める。そのEVIDはステップＳ３２
で求めた検索方向を元に、検索条件（時間）の先頭のEV
IDと最後のEVIDである。上記で求めた先頭のEVIDから最
後のEVIDまでのインデックスデータ（データ部）のチェ
ーンをたどって行き、各EVIDについてステップＳ３１で
求めたEVIDと一致するEVIDが検索条件（種別）と検索条
件（時間）に一致したEVIDとなる。この処理がステップ
Ｓ３４である。この処理の後、ステップＳ３５で検索数
に一致したイベントデータのEVIDを求める。この場合、
上記ステップＳ３４で求めたEVIDとEQIDを関連付け、検
索要求受け渡し用データ内の検索数に一致したEVIDを取
得し、その後、検索要求受け渡し用データに求めたイベ
ントデータを設定する。

【００８２】次に追加処理について図２６のフローチャ
ートにより述べる。図２６において、ステップＳ４１か
らステップＳ４３までは登録処理のステップＳ２１から
ステップＳ２３と同様の処理であり、ステップＳ４３の
処理の後、ステップＳ４４でイベントデータのインデッ
クスデータにおける追加位置を求める。その後、ステッ
プＳ４５のインデックスデータを更新する。この更新に
は追加したイベントデータから発生時刻を取り出し、そ
の日付けの日付けインデックスデータ（データ部）を参
照し、当該日の最終登録EVIDを取得する。この取得した
EVIDを元にインデックスデータ（データ部）のチェーン
をたどって行き、追加したイベントデータが時間的にど
のEVIDとEVIDの間に追加されるのか求め、チェーンを繋
ぎ替える。すなわち、図２７（インデックスデータの更
新処理説明図）の図示ＡブロックからＢブロックに替え
る。その後のステップＳ４６からステップＳ４８の処理
は登録処理のステップＳ２６からステップＳ２８と同じ
である。

【００８３】次に削除処理について図２８のフローチャ
ートにより説明する。まず、ステップＳ５０で、削除要
求受け渡し用データのEQIDを変換して、削除するイベン
トデータのEVIDを求める。次に、求めたEVIDからイベン
トデータファイルを参照して、ステップＳ５１でこのデ
ータファイルから削除するイベントデータを取得する。
この削除するイベントデータからステップＳ５２ではま
ず、種別と種別内容を取り出し、その種別データを参照
し、上記で取り出した種別の種別内容オフセットを求
め、種別内容データにおける種別内容位置を計算する。
そして、計算した種別内容位置の種別内容データを取得
する。取得したEVIDを元に当該種別のポインターデータ
の当該種別内容のチェーンをたどっていき、削除するイ
ベントデータの前後のEVIDを繋げる。その後、削除する
イベントデータの全種別について上記処理を繰り返して
図２９（種別内容データ、ポインターデータの更新処理
説明図）の図示ＡブロックからＢブロックに示すように
種別内容データ、ポインターデータを更新する。

【００８４】その後、削除するイベントデータの全種別
について上記ステップＳ５２で取得した種別内容データ
をステップＳ５３で更新した後、ステップＳ５１で取得
したイベントデータから発生時刻を取り出し、その日付
けの日付けインデックスデータ（データ部）を参照し、
当該日の最終登録EVIDを取得する。また、前記ステップ
Ｓ５３で取得したEVIDを元にインデックスデータ（デー
タ部）のチェーンをたどっていき、削除するイベントデ
ータのEVIDの前後を繋げて、ステップＳ５４でインデッ
クスデータを更新する。この更新処理を図３０（インデ
ックスデータの更新処理説明図）に示す。図３０におい
て、図示ＡブロックからＢブロックのように更新する。
この更新の後、ステップＳ５４で取り出した日付けの日
付けインデックスデータ（データ部）をステップＳ５５
で更新し、ステップＳ５６でステップＳ５１で取得した
イベントデータをイベントデータファイルから削除し
て、上記処理を削除要求受け渡し用データの全EQIDにつ
いて行う。

【００８５】図３１はイニシャライズ１処理のフローチ
ャートで、ステップＳ６０でバックアップ処理終了の認
識になっているかを判定し、処理可能の場合には、ステ
ップＳ６１によりバックアップ処理によりセーブされた
イベントアクセスセーブデータの最新登録日付インデッ
クスデータ（管理部）の最新登録日付けが一致している
かを判定する。一致していた場合には、ステップＳ６２
でバックアップ処理によりセーブされたイベントアクセ
スデータをメモリ上にロードする。なお、ステップＳ６
０とステップＳ６１で判定処理が「ＮＯ」の場合、すな
わち処理不能の場合にはステップＳ６３で次に述べるイ
ニシャライズ２処理を行う。

【００８６】図３１はイニシャライズ２処理のフローチ
ャートで、ステップＳ６４はイベントデータアクセス用
データ（種別内容データ、ポインターデータ、インデッ
クスデータ、日付けインデックスデータ）を初期化する
処理で、この処理の後、イベントデータファイルのイベ
ントデータを読み込んで、イベントデータアクセス用デ
ータを更新し、全イベントデータについて上記処理を行
って、ステップＳ６５でイベントデータアクセス用デー
タを再構築する。

【００８７】図３３はバックアップ処理のフローチャー
トで、図３３において、ステップＳ７０で登録処理、検
索処理などの他の処理中の場合は、その処理が終了して
からバックアップ処理が可能かを判定し、可能の場合に
は、ステップＳ７１でバックアップ処理中の認識をし
て、イベントデータアクセス用データをメモリ上からデ
ィスク上にステップＳ７２で書き込み、セーブする。前
記バックアップ処理中に登録要求が発生した場合には、
ステップＳ７３でバックアップ処理を中断し、ステップ
Ｓ７２に戻り登録処理を行う。バックアップ処理は登録
処理が終了次第、初めからやり直す。ステップＳ７３で
登録要求がない場合には、ステップＳ７４でバックアッ
プ処理終了の認識をする。

【００８８】

【発明の効果】以上述べたように、この発明によれば、
イベントデータの管理方式をサブシステム化することに
より、以下のような効果が得られる。

【００８９】（１）イベントデータの管理に関する機能
が充実する利点がある。これは従来の登録機能、検索機
能に加え、削除機能、追加機能があるため、一般的に考
えられるイベントデータの管理に関する機能が全て揃う
ことになり、新たな機能追加の必要がない。

【００９０】（２）ソフトウェア流用率が向上する利点
がある。これはイベントデータに関する処理を必要とす
る他の一般アプリケーションプロセスは、提供されたＩ
／Ｆを使用してサービスを受けることになる。従って、
新たに別のシステムを開発するような場合においても、
本サブシステムが使用しているキューサービスやファイ
ルサービスを新システムにインストールされているもの
に置き換えたり、本サブシステムのジェネレーションを
行うだけで、新システムに対応することができる利点が
ある。

【００９１】（３）拡張性に優れている利点がある。イ
ベントデータの管理に関する機能を追加、変更するよう
な場合、一般にアプリケーションプロセスに対するＩ／
Ｆの追加、変更や本システムのデータベースの追加、変
更を行うことで対応が可能となる。また、保存するイベ
ントデータ数の拡張といったシステムレベルの定数変更
も、本サブシステムの再ジェネレーションにより、機械
的に対応することができる。

【００９２】（４）イベントデータの管理に関する処理
の系統化ができる。イベントデータとそれをアクセスす
るためのデータをそれぞれに共通なEVIDという概念で管
理し、さらに、個々のイベントデータを時間ルート、種
別ルートのチェーンで関係付けることにより、今まで実
現されていなかった削除機能、追加機能を容易に可能に
することができる。また、登録機能、検索機能といった
既存の機能に関してもチェーンの繋ぎ替えを行うことで
簡単に実現することができる。その結果、障害の解析、
メンテナンス、機能改造、変更といった事象に対して柔
軟に対応できるようになる。

【００９３】（５）検索機能の柔軟性がある。イベント
データに関する処理の基幹となるのは登録機能と検索機
能である。このうち、検索機能には多様性が求められて
いる。本サブシステムではイベントデータに新たな種別
を追加するような場合でも、種別に関するデータに定数
を追加するだけで対応することができる。しかも、変更
となるのはデータだけでプログラム本体には全く依存し
ない。

【図面の簡単な説明】

【図１】この発明に実施例を示すイベントデータ管理サ
ブシステムの概念図。

【図２】実施例におけるキューターミナル１の処理シー
ケンス説明図。

【図３】キューターミナルＱ１のＩ／Ｆデータフォーマ
ット。

【図４】キューターミナルＱ２の処理シーケンス説明
図。

【図５】キューターミナルＱ２にＩ／Ｆデータ（イベン
トデータ受け渡し用ファイル使用）フォーマット。

【図６】キューターミナルＱ２にＩ／Ｆデータ（イベン
トデータ受け渡し用ファイル未使用）フォーマット。

【図７】処理終了応答Ｉ／Ｆデータ（イベントデータ受
け渡し用ファイル使用）フォーマット。

【図８】応答Ｉ／Ｆデータ（イベントデータ受け渡し用
ファイル未使用）フォーマット。

【図９】検索要求受け渡し用データフォーマット。

【図１０】追加要求受け渡し用データフォーマット。

【図１１】削除要求受け渡し用データフォーマット。

【図１２】検索要求応答受け渡し用データフォーマッ
ト。

【図１３】イベントデータ管理サブシステムデータベー
ス概念図。

【図１４】イベントデータフォーマット。

【図１５】インデックスデータフォーマット。

【図１６】日付けインデックスデータフォーマット。

【図１７】ポインターデータフォーマット。

【図１８】種別内容データフォーマット。

【図１９】種別データフォーマット。

【図２０】データ関連説明図。

【図２１】データ関連説明図。

【図２２】イベントデータ管理サブシステムの登録処理
フローチャート。

【図２３】インデックスデータの更新処理説明図。

【図２４】種別内容データ、ポインターデータの更新処
理説明図。

【図２５】イベントデータ管理サブシステムの検索処理
フローチャート。

【図２６】イベントデータ管理サブシステムの追加処理
フローチャート。

【図２７】インデックスデータの更新処理説明図。

【図２８】イベントデータ管理サブシステムの削除処理
フローチャート。

【図２９】種別内容データ、ポインターデータの更新処
理説明図。

【図３０】インデックスデータの更新処理説明図。

【図３１】イベントデータ管理サブシステムのイニシャ
ライズ１処理のフローチャート。

【図３２】イベントデータ管理サブシステムのイニシャ
ライズ２処理のフローチャート。

【図３３】イベントデータ管理サブシステムのバックア
ップ処理フローチャート。

【図３４】現行のイベントデータ管理方式の概念図。

【図３５】現行のイベントデータ管理方式のデータフォ
ーマット。

【図３６】現行のイベントデータ管理方式の登録処理フ
ローチャート。

【図３７】現行のイベントデータ管理方式の検索処理フ
ローチャート。

【符号の説明】

１…イベントデータ管理プロセス ２…データベース ３、４…一般アプリケーションプロセス ５…イベントデータ受け渡し用ファイル

Claims (4)

【特許請求の範囲】
1. 【請求項１】 監視制御システムにおける機器の操作、
   機器の故障、事故等のメッセージからなるイベントデー
   タを、登録処理機能および検索処理機能プログラムを有
   するコンピュータにより管理する方式において、 前記２つの処理機能の他に追加処理、削除処理、イニシ
   ャライズ処理およびバックアップ処理機能プログラムを
   有するイベントデータ管理サブシステムを形成し、この
   サブシステムにイベントデータ管理プログラムを設け、
   この管理プログラムのためのデータべースを構築して、
   前記登録処理機能プログラムからのイベントデータ登録
   要求に対してデータベースを元にそのデータの登録処理
   を行い、検索処理機能プログラムからのイベントデータ
   検索要求に対してデータベースを元にその検索処理を行
   うとともに、イベントデータ追加、削除、イニシャライ
   ズおよびバックアップ処理要求に対してもデータベース
   を元にそれらデータ処理を要求により順次行うようにし
   たことを特徴とする監視制御システムにおけるイベント
   データの管理方式。
2. 【請求項２】 前記データベースには前記登録、検索処
   理機能プログラムに対して指定されたイベントデータを
   データベースに保存するとともに、指定された検索条件
   と一致するイベントデータをデータベースの中から検索
   し、しかも、イベントデータの追加があったときにはデ
   ータベースに追加を行い、前以て検索されたイベントデ
   ータの中から指定されたイベントデータをデータベース
   から削除するようにしたことを特徴とする請求項１記載
   の監視制御システムにおけるイベントデータの管理方
   式。
3. 【請求項３】 前記データベースはイベントデータファ
   イルとイベントデータファイルアクセス用データから構
   築されている請求項１記載の監視制御システムにおける
   イベントデータの管理方式。
4. 【請求項４】 前記イベントデータファイルアクセス用
   データは時間ルートインデックス用データと種別ルート
   インデックス用データからなることを特徴とする請求項
   ３記載の監視制御システムにおけるイベントデータの管
   理方式。