JP2001084026A - 監視制御装置 - Google Patents

Abstract

(57)【要約】 【課題】イベントを配信したクライアントとそのコンフ
ァームの状況の管理を実現できる監視制御装置を提供す
ること。 【解決手段】イベントを定義する手段及びイベントの発
生を通知する手段を有する監視サーバー４と、該監視サ
ーバー４からのイベント通知を受けてイベント・アラー
ム処理をする複数の監視クライアント５，６とからなる
監視制御装置であり、前記監視サーバー４は、通知する
イベント毎に通知する監視クライアント５，６の数を記
憶し、通知したイベントに応動した監視クライアント
５，６からの応コンファームを受信して、イベント通知
した監視クライアント５，６の数とコンファームを受信
した監視クライアント５，６の数とに基づき所定のイベ
ントの復帰処理をする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の監視クライ
アント及びサーバを備え、プラントのプロセス等を監視
制御する監視制御装置に関する。

【０００２】

【従来の技術】図１を参照して、従来技術及び本発明に
おける監視制御装置について説明する。図１において、
監視クライアント１，２は、ネットワークシステムイン
ターフェース３Ａ〜３Ｃを介してネットワークシステム
３にて監視サーバー４に接続され、監視サーバー４のデ
ータソース管理部１０は、フィールドデバイスなどの制
御機器１０の情報の入出力を行う。

【０００３】監視サーバー４内には、データソースの値
などの情報から、監視クライアント１，２に通知すべき
イベントであると判断するか否かを定義するイベント定
義ファイル６Ａ〜８Ａが用意されており、個々のイベン
トを通知するためのイベント定義／通知サーバー６〜７
は、イベント定義ファイル６Ａ〜８Ａとデータソースか
らイベント発生と判断したときには、データベース４Ａ
を接続しているイベントサーバー５を介し、監視クライ
アント１，２に通知する。

【０００４】監視クライアント１，２は、監視サーバー
４のイベント通知をイベントソース部１Ｃ，２Ｃで受信
し、これをイベント表示処理部１Ｄ，２Ｄにて処理後、
内容を画面１Ｅ，２Ｅに表示する。また、監視クライア
ント１，２には、データベース１Ａ，２Ａ及び入力装置
１Ｂ，２Ｂが接続されている。

【０００５】このような、監視クライアント１，２及び
サーバー４を備える監視制御装置においては、一般に、
プラントやプロセス値の状態変化をイベントとして捉え
て、監視クライアント１，２へ通知する機能は実施され
ている。監視クライアント１，２はこの通知をうけて、
所定の画面に表示などをおこなう。

【０００６】監視サーバー４が監視クライアント１，２
に通知するこれらのイベントのなかには、監視クライア
ント１，２にとっては、画面に表示するだけでよいもの
のほかに、警報イベントのようにオペレータがその警報
を認識、確認したかどうか重要になるイベントがある。

【０００７】これらの警報イベントに対し、オペレータ
は、警報メッセージ情報などを確認した際、自身の警報
画面の制定・復帰処理（フリッカ停止など）と同時にコ
ンファーム（警報確認）信号を監視サーバー４に通知
し、該当警報イベントを確認したことを知らせるととも
に、同一警報イベントの再送防止などを行うのが一般に
行われている。

【０００８】

【発明が解決しようとする課題】一般に、このようなシ
ステム構成の場合、サーバーが警報イベントを集中管理
しており、警報イベントソースに対応したコンファーム
を行うと、監視クライアントへの警報イベントの通知は
停止される。

【０００９】このため、例えば、互いに離れたところに
分散配置された複数の監視クライアントのいずれかがコ
ンファームを行った場合、コンファームをおこなってい
ない監視クライアントにとっては、該警報イベントはコ
ンファーム済みという扱いになる。すると、例えば、警
報停止→警報復帰という２挙動方式の監視方式をとって
いる場合、警報停止即警報復帰となる可能性があり、以
後の処理に問題がおきる可能性がある。

【００１０】監視装置によっては、あえてアラームサプ
レッションとか代表警報停止のように、イベント表示や
警報処理を軽減する方式のものもある。

【００１１】しかし、同一プラントをオーバラップして
監視する複数の監視クライアントがあり且つ一部の異常
や警報イベントの確認（コンファーム）には、該全クラ
イアントのコンファームを必用とするケースやどのクラ
イアントにてコンファームを実施したかという情報を管
理したいという場合において、これら機能を実現できな
いという問題がある。

【００１２】逆に、監視クライアントの機器にＰＤＡや
電話などが混在する場合、サーバーから送信したアラー
ムやイベントに対してオペレータが確認したか否かを、
サーバー側では機械的には確認できないという問題があ
る。

【００１３】本発明の目的は、監視サーバーにイベント
配信とクライアントからのコンファームを管理する機構
を設けることにより、イベントを配信したクライアント
とそのコンファームの状況の管理を実現できる監視制御
装置を提供することにある。

【００１４】

【課題を解決するための手段】上記課題を解決するため
に請求項１に係る発明では、監視サーバーには、個別イ
ベントを監視クライアントに通知するイベント通知サー
バーと、個別イベントサーバーを統合管理し、監視クラ
イアントとの接続を行うイベントサーバーを設けてお
り、クライアントに送信するイベントの中でも、送信の
みでよいものと、アラーム通知のようにクライアントか
らの応答又は確認信号を必用とするものもあり、このよ
うな種類のイベント通知に関しては、通知するイベント
ごとに、通知するクライアント数を記憶しておき、クラ
イアントからのコンファーム信号を確認するように構成
する。

【００１５】これにより、監視サーバー側で送信した全
クライアントに関してコンファームがあったかどうかを
確認することができるため、アラームを通知したものの
別の監視クライアントのコンファーム信号のみで、アラ
ーム復帰処理をしてしまう、という問題を回避すること
ができる。

【００１６】請求項２の発明では、イベントの属性とク
ライアントの通知要求である監視キーとから、通知する
クライアントの数を算出するために、クライアント要求
の監視キーとイベントの監視キーを比較する機能を設け
る。

【００１７】これにより、監視キーを用いたイベント送
受信に関しても、請求項１での効果を得ることができ
る。

【００１８】請求項３の発明では、イベント通知ごとに
クライアントの応答有無をチェックし、指定条件を得て
も応答のないクライアントに対して、応答を促すイベン
ト通知を行う機構を設ける。

【００１９】これにより、コンファーム応答の無い監視
クライアントに対して、応答を促すことができる。

【００２０】請求項４の発明では、監視クライアントの
画面の一部に、自身が要求する監視キーを設定する監視
キー設定画面を設け、クライアントの要求キーをサーバ
ー側に設定するとともに、サーバー側に設定された監視
キーの値を監視クライアントに送信する機能を設ける。
クライアントでは、該値を上記監視キー設定画面上にフ
ィードバック表示することで、自らの監視キーを確認す
ることができ、イベントのチェック漏れを防止すること
ができる。

【００２１】これにより、監視キーを用いたイベントの
フィルタリングを行う場合にも、監視クライアントで、
アラームメッセージのチェックもれを防止することがで
きる。

【００２２】請求項５の発明では、サーバー側の監視キ
ーをはずし、本来他クライアントに通知されるイベント
をも受信し表示するアラーム画面と、上記監視キー設定
画面の監視キーにて、受信したイベントをフィルタリン
グする機構と、その結果を表示するための画面を複数設
けるものである。

【００２３】これにより、監視キーのフィルタリング機
能を瞬時に切り替え、全イベントの監視を行うことがで
きる。

【００２４】

【発明の実施の形態】以下図面を参照して本発明の実施
の形態について説明する。

【００２５】本発明の監視制御装置の基本構成は、従来
技術の説明の際に用いた図１に示す構成のものと同じで
あり、以下の実施形態では、相違する部分について説明
する。

【００２６】（第１の実施の形態:請求項１に対応）本
実施形態においては、送信イベントコンファームが監視
サーバー４から監視クライアント１，２に送信される
が、この送信イベントコンファームのフォーマットは、
図２に例示される。すなわち、送信イベントコンファー
ムは、図２の（ａ）に示す配信イベントテーブルと、図
２の（ｂ）に示すメッセージディスクリプタと、図２の
（ｃ）に示すイベント識別子テーブルとから構成され
る。

【００２７】ここで、送信イベントコンファームにおけ
るメインのフォーマットは、図２の（ａ）の配信イベン
トテーブルであり、この配信イベントテーブルは、図２
の（ｂ）及び（ｃ）のテーブルとリンクしている。

【００２８】これらテーブル内の各構成要素たとえばア
ラーム及びイベントの種類２０ｂやコンファーム要否２
０ｃやメッセージ２１ａなどは、データソース一点ごと
に予めシステム設計時に定義した、図１のイベント定義
ファイル６Ａ〜８Ａなどから導き出したものである。

【００２９】ここで、メッセージ等が、データソースの
値とイベント定義ファイル６Ａ〜８Ａの設定状況とから
判断すると監視クライアント１，２に通知すべき内容で
ある場合、この判断は、図１のイベント定義／通知サー
バー６〜８にて行われ、該メッセージ等は、個々のイベ
ント定義／通知サーバー６〜８が生成し、上位のイベン
トサーバー５に伝達する。

【００３０】この通知を受けたイベントサーバー５は、
図２の（ｃ）の送信時刻２２dに示すように、自身の監
視サーバーとしての識別子など、他の監視サーバー（も
し存在すれば）との区別がつくような識別子を付加する
など、必要な情報を整える。その後、相手の監視クライ
アントに対して、この送信イベントコンファームのデー
タを送信し、イベントを通知する。

【００３１】この場合、送信相手となる監視クライアン
トの送信アドレスは、イベント定義／通知サーバー６〜
８が生成する。つまり、イベント定義／通知サーバー６
〜８個々と監視クライアント５，６とは標準的に取り決
めた手順と機能を有するオブジェクトである。このた
め、監視クライアントは、監視クライアントとイベント
サーバー５との間にあって所定の手順を実行すること
で、監視サーバ４内のイベント定義／通知サーバー６〜
８にて送信アドレスを生成することができるのである。

【００３２】このほか、イベントサーバー５やイベント
定義／通知サーバー６〜８には、図示しないがコネクタ
ブルオブジェクトインタフェースが設けられており、こ
のコネクタブルオブジェクトインタフェースを介して、
監視クライアント５，６とイベント定義／通知サーバー
６〜８とは相互に、相手のイベント通知アドレス（ポイ
ンタ）を知ることができるようになっている。尚、コネ
クタブルオブジェクトインタフェースは、かかるアドレ
スの記載のほかに実際のデータの送受信にも使用され
る。

【００３３】次に、監視サーバー４が監視クライアント
５，６から受信する受信イベントフォーマットを、図３
を用いて説明する。図３の（ａ）に示す受信イベントテ
ーブル２３は、監視サーバー４が送信したイベントの内
で、何らかの返答が必要と指定したイベントに対して監
視クライアント５，６が送信する際のフォーマットであ
る。

【００３４】コンファーム処理結果２３ａは、主にアラ
ームイベントに際使用するもので、監視クライアント
５，６がアラーム処理を行った、又は確認したという意
味を示すもので、監視サーバー４が通知するイベントご
とに割り付けたイベント番号２３Ｂ、クライアントＩＤ
２２ｃの情報をもとに、そのイベント（アラーム）に対
して、監視サーバ４側は確認済み、ということを、監視
サーバー４は知ることができる。

【００３５】図３の（ｂ）に示すイベントカウンタテー
ブル２４は、これら受信イベントの情報を、監視サーバ
ー４側で管理するためのテーブルであり、一般に監視ク
ライアント５，６毎に設けている。このテーブル２４の
項目のセットは、図４のイベント通知の処理フローにて
示される。

【００３６】すなわち、イベント通知ルーチン４０は、
イベント定義通知サーバー６にて起動されるルーチン
で、起動されたときに、該当するイベントに関してユニ
ークなイベント番号をステップ４１にて生成するが、そ
のイベント番号はイベントカウンタテーブル２４のイベ
ント番号２４ａの番号に相当するもので、且つイベント
識別子テーブル２２ａにも登録されて監視クライアント
５，６に送付される。

【００３７】この場合、イベント通知する監視クライア
ントが複数であれば、該当するクライアント数分のイベ
ントカウンタテーブル２４をステップ４２にて生成し、
イベント番号の生成、登録を繰り返す。送信時刻を２４
ｂにセット後、該当する監視クライアント５，６にステ
ップ４４で送信するものである。

【００３８】図５は、監視クライアント５，６から、イ
ベントコンファームを受信したときの監視サーバー４内
の処理を示すものである。ステップ５０ａでイベント受
信テーブル２３から、ユニークに割り付けられ、監視サ
ーバー４から送付されたイベント番号をとりだす。この
イベント番号と、クライアントＩＤ番号から、該当する
イベントカウンタテーブル２４の該当するイベント番号
２４を照合する。

【００３９】受信データから、コンファーム関係である
ことを確認した後、ステップ５０ｄにて、イベントカウ
ントテーブル２４のコンファーム欄２４ｄをチェック
（フラグをセット）するものである。

【００４０】ステップ５０ｅでは、処理した受信データ
に関して、イベントカウンタテーブル２４に関して、監
視サーバー４が確かに送信したイベントＩＤか、又はク
ライアントであるかを確認するもので、異常がなけれ
ば、通常はステップ５０ｆのコンファーム処理に移行し
て、ここで、イベント定義／通知サーバー６〜８及びイ
ベント発信元の復帰処理を行う。

【００４１】以上述べた通常の処理ルーチンに加えて、
第１の実施形態では、イベントカウントルーチン５１に
て、ステップ５１ａ、ステップ５１ｂ、ステップ５１ｃ
を行うものである。

【００４２】先ず、ステップ５１ａでは、イベントカウ
ンタテーブル２４のイベント番号２４ａの項目をサーチ
することで、各監視クライアント５，６毎に返答（コン
ファーム）要求付きのイベントをいくつ送付したかをカ
ウントする。

【００４３】ステップ５１ｂでは同様に、イベントカウ
ンタテーブル２４で、コンファーム済みのイベント数を
カウントし、ステップ５１ｃにて、両者が一致すること
で、各クライアントごとに送信した返答要求付きイベン
トに対して、すべて返答（コンファーム）が返って来た
かを確認することができる。

【００４４】このよう本実施形態においては、通知する
イベントごとに、通知するクライアント数を記憶してお
き、クライアントからのコンファーム信号を確認するよ
うに構成したことにより、監視サーバー４側で送信した
全クライアントに関してコンファームがあったかどうか
を確認することができるため、アラームを通知したもの
の別の監視クライアントのコンファーム信号のみで、ア
ラーム復帰処理をしてしまう、という問題を回避するこ
とができる。

【００４５】（第２の実施の形態:請求項２に対応）次
に、請求項２に対応する本発明の第２の実施の形態につ
いて、図５を参照して説明する。本実施形態では、監視
サーバ４の機能として、監視キーチェックルーチン５２
を有する。

【００４６】ここで、監視キーとは、イベント定義ファ
イル６Ａ〜８Ａに予め設計時に定めておいたイベント属
性の一つで、個々のイベントに割り振られる。監視キー
の目的は、発生するイベントをいくつかのグループに分
類して、監視クライアント５，６が関心を持つグループ
毎に簡単に分類するとともに、監視クライアント５，６
には設定された監視キーに対応するイベント（アラー
ム）のみを送信することができる。

【００４７】そして、イベント定義ファイル６Ａ〜８Ａ
に定義した監視キーは、イベント発生時にはメッセージ
ディスクリプタ２１に、項目２１ｅとして引き出され、
またイベントカウンタテーブル２４に項目２１ｅとし
て、引き出される。さらに監視クライアント５，６から
の受信時にも、同様に受信イベントテーブル２３の監視
キーエリア２１ｅにセットされているものである。

【００４８】監視キーチェックルーチン５２では、ステ
ップ５２にて、受信イベントテーブル２３の監視キーを
検索し、ステップ５２ｂでは、受信の監視キーをベース
にイベントカウンタテーブル２４の監視キーのなかか
ら、同じ監視キーを持つイベント番号に関するコンファ
ーム有無の状況をチェックするものである。このルーチ
ンを設けることにより、監視キーというグループ分の属
性単位で、監視クライアントからコンファームがあった
か否かを確認することができる。

【００４９】以上のように本実施形態によれば、イベン
トの属性とクライアントの通知要求である監視キーとか
ら、通知するクライアントの数を算出するために、クラ
イアント要求の監視キーとイベントの監視キーを比較す
る機能を設けたことにより、監視キーを用いたイベント
送受信に関しても、第１の実施形態での効果を得ること
ができる。

【００５０】（第３の実施の形態:請求項３に対応）次
に、請求項３に対応する本発明の第３の実施の形態につ
いて、図５を参照して説明する。本実施形態では、監視
サーバ４の機能として、イベント再送ルーチン５３を有
する。

【００５１】先に述べた第１，第２の実施形態と同様
に、イベントカウンタテーブル２４にて、コンファーム
要求付きイベントに対して未受信のイベントがあった場
合及び未受信のクライアントがあった場合に、ステップ
５３ｂで再送すべきか否かを判定、例えば、前回すでに
再送しているか、未受信イベント数、送信時刻からの経
過時間などをパラメータとして判定し、再送すべきと判
定されたときには、ステップ５３ｃにて、イベントを監
視クライアント５，６に再送し、コンファームの確認返
答を促すものである。

【００５２】図６は第１〜第３の実施形態で述べたコン
ファーム処理の内容をあらわしたもので、前提としては
イベント（アラーム）の発生元が除去されており、再
度、イベント定義／通知サーバー６〜８が起動する状態
ではないことが前提となる。

【００５３】すなわち、ステップ６０ａ，６０ｂでイベ
ントカウンタテーブル２４のコンファームエリアをチェ
ックし、ステップ６０ｃで、全クライアント、全イベン
トに対してコンファーム受信を確認したら、ステップ６
０ｄにて、イベントカウンタテーブル２４のフラグをリ
セットして、復帰処理とするものである。

【００５４】以上のように本実施形態によれば、イベン
ト通知毎に監視クライアント５，６の応答有無をチェッ
クし、指定条件を得ても応答のない監視クライアント
５，６に対して、応答を促すイベント通知を行う機構を
設けているので、コンファーム応答の無い監視クライア
ント５，６に対して、応答を促すことができる。

【００５５】（第４の実施の形態:請求項４に対応）次
に、請求項４に対応する本発明の第４の実施の形態につ
いて、図７を参照して説明する。本実施形態では、監視
キー設定画面７０が設けられており、これは監視クライ
アント５，６の画面１ｅ上に設けられたウィンドウであ
り、監視キーメニュー欄７０ａと、監視キーｏｎ／ｏｆ
ｆメニュー７０ｂとからなる。

【００５６】監視キー７０ａは、入力装置１Ｂを介して
自身が注目したい監視キーを入力するもので、監視キー
ｏｎ／ｏｆｆメニューをｏｎにすることで、監視キー７
０ａに入力された値（監視キー）は、監視サーバー４に
転送される。

【００５７】監視サーバー４側では、通知すべきイベン
トが発生した際、イベント定義ファイル６Ａ〜８Ａの監
視キー項目と、監視クライアント５，６が設定した監視
キーを比較し（図示せず）、一致するイベントのみを監
視クライアント５，６に送付する。

【００５８】この場合、監視キー設定画面７０で設定し
た監視キーは、そのまま表示され続ける。このため、監
視クライアント５，６側では、アラームパネル７１ａに
表示されるアラームメッセージが、監視キー設定画面７
０に表示されている監視キーの分だけで、未表示のアラ
ームがある可能性がある、ということを認識することが
できる。

【００５９】このように第４の実施形態によれば、監視
クライアント５，６の画面の一部に、自身が要求する監
視キーを設定する監視キー設定画面７０を設け、監視ク
ライアント５，６の要求キーを監視サーバー４側に設定
するとともに、監視サーバー４側に設定された監視キー
の値を監視クライアント５，６に送信する機能を設けて
いる。そして、監視クライアント５，６では、該値を上
記監視キー設定画面７０上にフィードバック表示するこ
とで、自らの監視キーを確認することができ、イベント
のチェック漏れを防止することができる。

【００６０】これにより、監視キーを用いたイベントの
フィルタリングを行う場合にも、監視クライアント５，
６で、アラームメッセージのチェックもれを防止するこ
とができる。

【００６１】（第５の実施の形態:請求項５に対応）次
に、請求項５に対応する本発明の第５の実施の形態につ
いて、図７を参照して説明する。本実施形態では、監視
キーモード画面８０にて、第４の実施形態における監視
キーによる表示フィルタリングを行うか（キーモード８
０ｂ）、否か（全モード８０ｃ）を設定するものであ
る。

【００６２】この場合、全モードを選択した際、その設
定は監視サーバー４に通知され、上記した第４の実施形
態で説明した監視キーの比較機能を停止させ、監視サー
バー４側で検出したイベントはすべて該当する監視クラ
イアント５，６に通知する。これにより、結果として
は、アラームパネル７１ａのメッセージ欄にすべてのア
ラームメニューが表示される。メニュー画面から溢れた
メッセージはロールバックキー７１ｃにて、再表示され
る。

【００６３】このように本実施形態によれば、監視サー
バー４側の監視キーをはずし、本来、他の監視クライア
ントに通知されるイベントをも受信し表示するアラーム
画面と、上記監視キー設定画面の監視キーにて、受信し
たイベントをフィルタリングする機構と、その結果を表
示するための画面を複数設けることにより、監視キーの
フィルタリング機能を瞬時に切り替え、全イベントの監
視を行うことができる。

【００６４】

【発明の効果】以上のように本発明によれば、監視サー
バーにイベント配信とクライアントからのコンファーム
を管理する機構を設けることにより、イベントを配信し
たクライアントとそのコンファームの状況の管理を実現
できる監視制御装置を提供できるものである。

【図面の簡単な説明】

【図１】本発明に係る監視制御装置の基本構成を示すブ
ロック図。

【図２】本発明における送信イベントコンファームフォ
ーマットの一例を示す図。

【図３】本発明における受信イベントフォーマットの一
例を示す図。

【図４】本発明におけるイベント通知フローのり一例を
示す図。

【図５】本発明におけるサーバ受信におけるイベントコ
ンファームを示すフロー図。

【図６】本発明におけるコンファーム処理のフロー図。

【図７】本発明における監視キー設定画面と監視キーモ
ード設定画面とを示す図。

【符号の説明】

１，２…監視クライアント、１Ａ，２Ａ…データベー
ス、１Ｂ，２Ｂ…データベース、１Ｃ，２Ｃ…イベント
ソース、１Ｄ，２Ｄ…イベント表示処理部、１Ｅ，２Ｅ
…画面、３…ネットワーク、３Ａ，３Ｂ，３Ｃ…ネット
ワークインターフェース、４…監視サーバ、４Ａ…デー
タベース、５…イベントサーバ、６〜８…イベント定義
／通知サーバ、６Ａ〜８Ａ…イベント定義ファイル、９
…データソース管理部、１０…制御機器、２０…配信イ
ベントテーブル、２１…メッセージディスプリクタ、２
２…イベント識別子テーブル、２３…受信イベントテー
ブル、２４，２５…イベントカウンタテーブル、５０…
イベントコンファームルーチン、５１…イベントカウン
トルーチン、５２…監視キーチェックルーチン、５３…
イベント再送ルーチン。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｑ 9/00 ３２１ Ｈ０４Ｑ 9/00 ３２１Ｃ ３６１ ３６１ Ｆターム(参考） 5B089 GA11 GB02 JA35 JB16 KA13 KB04 KC28 LB14 MC02 5E501 AC02 AC25 AC32 AC35 CA02 DA02 FA13 FA24 FA46 5H223 AA01 CC03 CC08 DD03 DD05 DD07 EE08 EE17 5K048 AA06 BA23 DA03 EB03 EB08 FA10 FB04 FB10 GA07 HA01 HA02

Claims (5)

【特許請求の範囲】
1. 【請求項１】 イベントの定義及びイベントの発生を通
   知する手段を有する監視サーバーと、該監視サーバーか
   らのイベント通知を受けてアラーム処理をする複数の監
   視クライアントとからなる監視制御装置において、 前記監視サーバーは、 通知するイベント毎に通知する監視クライアントの数を
   記憶する手段と、 前記通知したイベントに応動した監視クライアントから
   のコンファームを受信する手段と、 前記手段によるイベント通知した監視クライアントの数
   とコンファームを受信した監視クライアントの数とに基
   づき所定のイベントの復帰処理をするコンファーム管理
   手段とを具備することを特徴とする監視制御装置。
2. 【請求項２】 前記コンファーム管理手段は、 発生イベントの属性として監視キーを監視クライアント
   ごとに設定する手段と、 該監視キーごとのコンファー
   ムの受信数をカウントする手段とを有し、 発生イベントの属性に応じて発生イベントの復帰処理を
   行うことを特徴とする請求項１記載の監視制御装置。
3. 【請求項３】 前記監視サーバは、 前記監視クライアントからのコンファームの有無をチェ
   ックする手段と、 コンファームの応答のない監視クライアントに対しコン
   ファームを再要求するリトライ手段とを更に具備するこ
   とを特徴とする請求項１又は２記載の監視制御装置。
4. 【請求項４】 前記監視クライアントは、 監視キー設定画面を有し、この監視キー設定画面に対す
   る入力値を前記監視サーバーに設定すると共に該設定値
   を該キー設定画面に表示する手段を具備することを特徴
   とする請求項２記載の監視制御装置。
5. 【請求項５】 前記監視クライアントは、監視キーに該
   当するアラームのみ表示する画面と、監視キーに関係な
   く全アラームを表示する画面の両方を有することを特徴
   とする請求項４記載の監視制御装置。