JP6124813B2 - プラント監視制御システム - Google Patents

Description

この発明は、火力／原子力プラント等において、操作端末によって制御装置の稼働状況を監視するプラント監視制御システムに関するものである。

従来のプラント監視制御システムは、プラント・補機に接続された分散ＰＩＯ（Ｐｒｏｃｅｓｓ Ｉ／Ｏ）が、プラント上のデータをアナログ／デジタル入力信号として取得し、制御装置に転送する。
制御装置は、取得したデータを用いて各種の演算処理を行うことで、プラントの制御を行う。さらに、制御装置はネットワークを通じて、操作端末と接続されており、ユーザは操作端末から、制御装置の様々な制御データの監視を行う。

一方、制御装置の保守を行う際に、制御装置の稼働状況を、ユーザがネットワークを通じて操作端末から確認したい場合がある。
稼働状況データには、定期状態データと一時ログデータの２種類が存在する。定期状態データは、制御装置の運転モードや、重故障／軽故障ランプのように、定期的に収集する必要のあるデータであり、データ量は小さく、比較的容易に取得することができる。
また、一時ログデータは、制御装置で何か異常が起こったときに、その詳細を調べるために用いられる一時的なログデータであり、データ量は大きく、そのデータを取得するためには、制御装置にある程度の負荷がかかってしまう。

ただし、稼働状況データは、制御データよりも重要度の劣るデータであり、稼働状況データのやり取りを行うことによって、制御データのやり取りに影響を与えてはならない。
そのため、制御装置が行う各種の演算処理の空き時間に、操作端末からのリクエストを受け付け、自身の稼働状況データを返信することになる。このように、制御装置が自身の稼働状況データを取り扱うリソースには限りがあり、汎用ＰＣである操作端末と比べると、その能力は極めて限定的である。
したがって、多数のユーザが別々の操作端末から同時に、１台の制御装置の稼働状況を確認しようとした際に、リソースに限りのある制御装置に負荷を与えてしまい、稼働状況の確認に時間がかかってしまったり、最悪、制御装置がダウンしてしまったりする恐れがある。

また、アクセス代理装置とアクセス依頼装置を用いることによって、各装置間のデータ同期を行う方法等が先行技術として提案されている（特許文献１）ものの、この提案では、複数の装置に非同期にアクセスすることによるデータの矛盾回避、および、アクセス時間の短縮が主な目的であり、アクセスされる側への負荷軽減は考慮されていない。

特開２００１−２２９１３６号公報（第５〜６頁、第１図）

従来のプラント監視制御システムにおける稼働状況監視では、多数のユーザが別々の操作端末から同時に、１台の制御装置の稼働状況を確認しようとした際に、リソースに限りのある制御装置に負荷を与えてしまい、稼働状況の確認に時間がかかってしまったり、最悪、制御装置がダウンしてしまったりする恐れがあった。
また、特許文献１のものでは、複数の装置に非同期にアクセスすることによるデータの矛盾回避、および、アクセス時間の短縮が主な目的であり、アクセスされる側への負荷軽減を考慮していなかった。

この発明は、上述のような課題を解決するためになされたものであり、複数のユーザが別々の操作端末から同時に制御装置の稼働状況を監視する際に、信頼性を維持したまま、制御装置の負荷を平準化できるプラント監視制御システムを得ることを目的とする。

この発明に係わるプラント監視制御システムにおいては、プラント機器を制御する制御装置、この制御装置の稼働状況を示す稼働状況データを取得し、表示する複数の操作端末、及びこの操作端末の制御装置からの稼働状況データの取得を代行する複数の代行端末を備え、稼働状況データは、制御装置の運転状態を示すデータを定期的に取得した状態データと、制御装置で異常が発生した場合のデータである一時ログデータとを有し、各代行端末は、状態データを定周期で取得して、自身のデータベースに保存するとともに、操作端末から状態データの要求を受けた場合には、データベースに保存した状態データを当該操作端末に送信し、操作端末から一時ログデータの要求を受けた場合には、制御装置から一時ログデータを取得して、当該操作端末に転送するものである。

この発明によれば、プラント機器を制御する制御装置、この制御装置の稼働状況を示す稼働状況データを取得し、表示する複数の操作端末、及びこの操作端末の制御装置からの稼働状況データの取得を代行する複数の代行端末を備え、稼働状況データは、制御装置の運転状態を示すデータを定期的に取得した状態データと、制御装置で異常が発生した場合のデータである一時ログデータとを有し、各代行端末は、状態データを定周期で取得して、自身のデータベースに保存するとともに、操作端末から状態データの要求を受けた場合には、データベースに保存した状態データを当該操作端末に送信し、操作端末から一時ログデータの要求を受けた場合には、制御装置から一時ログデータを取得して、当該操作端末に転送するので、複数のユーザが別々の操作端末から同時に制御装置の稼働状況を監視する際に、信頼性を維持したまま、制御装置の負荷を平準化することができる。

この発明の実施の形態１によるプラント監視制御システムを示すシステム構成図である。 この発明の実施の形態１によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。 この発明の実施の形態１によるプラント監視制御システムの稼働状況監視の画面イメージ図である。 この発明の実施の形態１によるプラント監視制御システムの稼働状況監視の対象となる稼働状況データの概要を示す構成図である。 この発明の実施の形態１によるプラント監視制御システムの稼働状況表示機能の手順を示すフローチャートである。 この発明の実施の形態１によるプラント監視制御システムの稼働状況取得部の手順を示すフローチャートである。 この発明の実施の形態１によるプラント監視制御システムの稼働状況転送部の手順を示すフローチャートである。 この発明の実施の形態２によるプラント監視制御システムを示すシステム構成図である。 この発明の実施の形態２によるプラント監視制御システムの稼働状況表示機能の手順を示すフローチャートである。 この発明の実施の形態３によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。 この発明の実施の形態３によるプラント監視制御システムの稼働状況表示機能の手順を示すフローチャートである。 この発明の実施の形態３によるプラント監視制御システムの稼働状況転送部の手順を示すフローチャートである。 この発明の実施の形態４によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。 この発明の実施の形態４によるプラント監視制御システムの稼働状況転送部の手順を示すフローチャートである。 この発明の実施の形態５によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。 この発明の実施の形態５によるプラント監視制御システムの稼働状況表示機能の手順を示すフローチャートである。 この発明の実施の形態６によるプラント監視制御システムを示すシステム構成図である。 この発明の実施の形態６によるプラント監視制御システムの稼働状況表示機能の手順を示すフローチャートである。

実施の形態１．
以下、この発明の実施の形態１を図に基づいて説明する。
図１は、この発明の実施の形態１によるプラント監視制御システムを示すシステム構成図である。
図１において、プラント・補機６は、監視制御対象の機器である。分散ＰＩＯ５は、プラント上のデータ（圧力／温度／流量や、ファン／ポンプなどの起動／停止状態、オン／オフ弁の開／閉状態など）をアナログ／デジタル入力信号として取得し、制御装置１に転送する。
制御装置１は、取得したデータを用いて各種の演算処理を行うことで、プラント・補機６の制御を行う。さらに、制御装置１は、ネットワーク４を通じて、操作端末２と接続されており、ユーザ３は操作端末２から、制御装置１の様々な制御データの監視を行う。
制御装置１の保守を行う際には、制御装置１の稼働状況（稼働状況データ）を、ユーザ３がネットワーク４を通じて操作端末２から確認するようになっている。
このとき、制御装置１に負荷が集中しないように、操作端末２の中から代行端末１２を２台選定し、代行端末１２から制御装置１の稼働状況データを取得する。実施の形態１では、代行端末１２は、代行端末（マスタ）１０または代行端末（スレーブ）１１として動作するようになっている。

図２は、この発明の実施の形態１によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。
図２において、１〜３、１２は図１におけるものと同一のものである。代行端末１２には、稼働状況データを収集する稼働状況収集機能１４を設けている。稼働状況収集機能１４は、稼働状況データのうちの定期状態データ８（状態データ）を制御装置１から取得する稼働状況取得部１５と、取得した定期状態データ８を操作端末２に転送する稼働状況転送部１６と、取得した定期状態データ８を格納する稼働状況データベース１７（データベース）とを有する。稼働状況取得部１５は、定期起動トリガ１８によって動作を促され、定期的に定期状態データを取得する。
操作端末２には、稼働状況データを表示する稼働状況表示機能１３が設けられている。

図３は、この発明の実施の形態１によるプラント監視制御システムの稼働状況監視の画面イメージ図である。
図３において、メイン画面と、メイン画面を操作することによって呼び出される制御装置状態画面が示されている。メイン画面には、定期状態データ８が表示され、メイン画面から遷移する制御装置状態画面には、一時ログデータ９が表示される。
図３では、異常と表示された制御装置をクリックすることによって、エラー内容を表わす制御装置状態画面が表示されるようになっている。

図４は、この発明の実施の形態１によるプラント監視制御システムの稼働状況監視の対象となる稼働状況データの概要を示す構成図である。
図４において、稼働状況データ７には、定期状態データ８と一時ログデータ９の２種類が存在する。定期状態データ８は、制御装置１の運転モードや、重故障／軽故障ランプのように、定期的に収集する必要のあるデータであり、データ量は小さく、比較的容易に取得することができる。
一時ログデータ９は、制御装置１で何か異常が起こったときに、その詳細を調べるために用いられる一時的なログデータであり、データ量は大きく、そのデータを取得するためには、制御装置１にある程度の負荷がかかってしまう。
よって、図３の画面上では、メイン画面に表示されるデータが定期状態データとなり、メイン画面から遷移する制御装置状態画面に表示されるデータが一時ログデータとなる。

次に、動作について説明する。
まず、操作端末２の中から代行端末１２を２台選定する。そして、この２台に対して、あらかじめ代行端末（マスタ）１０または代行端末（スレーブ）１１の設定を行っておく。
なお、本説明では、操作端末２にて代行端末１２を兼用しているが、代行端末１２を新しい別の端末として用意してもかまわない。
代行端末１２では、代行端末（マスタ）１０または代行端末（スレーブ）１１の割り当てに関係なく、稼働状況収集機能１４の稼働状況取得部１５が常に制御装置１とアクセスを行い、最新の定期状態データ８を、自身の稼働状況データベース１７に保存しておく。

ユーザ３が、操作端末２上から制御装置１の稼働状況を監視する際、操作端末２上の稼働状況表示機能１３は、制御装置１の稼働状況データ７として、定期状態データ８と一時ログデータ９の両方を収集する。
このとき、表示頻度や項目数の少ない一時ログデータ９については、従来通り、制御装置１から収集する。一方、表示頻度や項目数の多い定期状態データ８については、代行端末１２から収集する。
代行端末１２から定期状態データ８を収集する際、稼働状況表示機能１３は、まず、代行端末（マスタ）１０に問い合わせを行う。このとき、稼働状況収集機能１４の稼働状況転送部１６は、稼働状況表示機能１３からリクエストを受けた際は、自身の稼働状況データベース１７から、必要な情報を収集し、稼働状況表示機能１３に返信する。
また、代行端末（マスタ）１０が動作していない場合、稼働状況表示機能１３は、続けて代行端末（スレーブ）１１に問い合わせを行う。このように二重系にすることによって、１台の代行端末１２で何か異常が発生した場合に備えることができ、信頼性が確保できる。

次に、操作端末２と代行端末１２の各機能の動作について説明する。
まず、操作端末２の稼働状況表示機能１３の手順を、図５を用いて説明する。
稼働状況表示機能１３は、あらかじめ起動しておき、ユーザ３から画面表示のリクエストを受け付けるまで待機する（Ｓ１１１１）。そして、ユーザ３から受け付けた画面表示のリクエストに応じて、表示する稼働状況データ７の種類を確認する（Ｓ１１１２）。
ここで、表示するデータが、一時ログデータ９の場合は、制御装置１に対して、一時ログデータ９の問い合わせを行う（Ｓ１１１３）。

一方、表示するデータが定期状態データ８の場合は、代行端末（マスタ）１０の稼働状況転送部１６に対して、定期状態データ８の問い合わせを行う（Ｓ１１１４）。このとき、代行端末（マスタ）１０への問い合わせに失敗した場合（Ｓ１１１５）は、続いて、代行端末（スレーブ）１１の稼働状況転送部１６に対して、定期状態データ８の問い合わせを行う（Ｓ１１１６）。
最後に、取得した稼働状況データ７を、稼働状況表示機能１３の画面に表示する（Ｓ１１１７）。なお、制御装置１または代行端末１２のどちらの問い合わせにも失敗した場合は、不定を示すデータを画面に表示する。

次に、代行端末１２の稼働状況取得部１５の手順を、図６を用いて説明する。
稼働状況収集機能１４の稼働状況取得部１５は、代行端末１２上であらかじめ起動しておき、一定間隔の定期起動トリガ１８を検出するまで待機する（Ｓ１２１１）。定期起動トリガ１８は、１秒おき程度を想定しているが、システムに応じて変更できるようにすることが望ましい。
そして、定期起動トリガ１８を受け付けると、実際に制御装置１に問い合わせを行い、定期状態データ８を取得する（Ｓ１２１２）。
最後に、取得した定期状態データ８を、自身の稼働状況データベース１７に保存する（Ｓ１２１３）。そして、これらの手順を稼働状況収集機能１４が起動している限り、繰り返す。

次に、代行端末１２の稼働状況転送部１６の手順を、図７を用いて説明する。
稼働状況収集機能１４の稼働状況転送部１６は、代行端末１２上であらかじめ起動しておき、操作端末２の稼働状況表示機能１３から、定期状態データ８取得のリクエストがあるまで待機する（Ｓ１３１１）。
そして、稼働状況表示機能１３からのリクエストを受け付けると、自身の稼働状況データベース１７に保存されている最新の定期状態データ８を取得する（Ｓ１３１２）。
最後に、取得した定期状態データ８を稼働状況表示機能１３に返信する（Ｓ１３１３）。そして、これらの手順を稼働状況収集機能１４が起動している限り、繰り返す。

実施の形態１によれば、このようにすることによって、全ての操作端末２が直接、同時に制御装置１にアクセスするのを避け、代行端末１２を二重系にしたことで信頼性を確保したまま、制御装置１の負荷を平準化することができる。

実施の形態２．
実施の形態１では、代行端末１２に対して厳密なマスタ／スレーブを定義しているため、操作端末２からの同時アクセスによる負荷が代行端末（マスタ）１０に集中しやすい傾向がある。
そこで、実施の形態２は、実施の形態１において、代行端末１２におけるマスタ／スレーブの定義をやめ、操作端末２と代行端末１２の間の負荷を分散した場合についてのものである。

図８は、この発明の実施の形態２によるプラント監視制御システムを示すシステム構成図である。
図８にいて、１〜６、１２は図１におけるものと同一のものである。図８では、代行端末１２に、マスタ／スレーブを定義していない。この代行端末１２は、便宜上２台として説明するが、３台以上でも特に問題はない。ただし、代行端末１２を設置しすぎると、制御装置１の負荷が高くなってしまうので注意が必要である。

次に、動作について説明する。
操作端末２の稼働状況表示機能１３の手順を、図９を用いて説明する。
稼働状況表示機能１３は、実施の形態１と同様にあらかじめ起動しておき、ユーザ３から画面表示のリクエストを受け付けるまで待機する（Ｓ１１１１）。そして、ユーザ３から受け付けた画面表示のリクエストに応じて、表示する稼働状況データ７の種類を確認する（Ｓ１１１２）。
ここで、表示するデータが、一時ログデータ９の場合は、実施の形態１と同様に、制御装置１に対して、一時ログデータ９の問い合わせを行う（Ｓ１１１３）。

一方、表示するデータが定期状態データ８の場合は、代行端末１２の中から、任意の１台を選択して、その代行端末１２の稼働状況転送部１６に対して、定期状態データ８の問い合わせを行う（Ｓ１１２１）。このとき、その代行端末１２への問い合わせに失敗した場合（Ｓ１１２２）は、残りの代行端末１２の稼働状況転送部１６に対して、順番に定期状態データ８の問い合わせを行っていく（Ｓ１１２３）。
最後に、取得した稼働状況データ７を、稼働状況表示機能１３の画面に表示する（Ｓ１１１７）。なお、制御装置１または代行端末１２の全ての問い合わせに失敗した場合は、不定を示すデータを画面に表示する。

実施の形態２によれば、このようにすることによって、代行端末（マスタ）１０にアクセスが集中することを防止することができ、代行端末１２の負荷を分散することができる。

実施の形態３．
実施の形態１〜実施の形態２においては、一時ログデータ９については直接、操作端末２から制御装置１に問い合わせを行っていたため、頻度は少ないものの、複数の操作端末２から同時に制御装置１にアクセスがかかる可能性が残っていた。そのため、制御装置１側で多数のコネクションを受け付ける処理が必要であり、これについても制御装置１のリソースを圧迫している。
そこで、実施の形態３では、実施の形態１〜実施の形態２において、一時ログデータ９についても、代行端末１２が取りまとめを行い、複数の操作端末２から一度に一時ログデータ９の問い合わせが制御装置１へ行かないようにする機能を有する場合についてのものである。

図１０は、この発明の実施の形態３によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。
図１０において、１〜３、７〜９、１２〜１８は図２におけるものと同一のものである。図１０では、操作端末２は、一時ログデータ９を代行端末１２を介して取得する。
すなわち、操作端末２の稼働状況表示機能１３が直接、制御装置１に対して問い合わせを行うのではなく、稼働状況データ７の種類に関係なく、必ず代行端末１２上の稼働状況収集機能１４の稼働状況転送部１６へ問い合わせを行うようにする。

次に、実施の形態３による稼働状況表示機能１３の手順を、図１１を用いて説明する。
稼働状況表示機能１３は、実施の形態１〜実施の形態２と同様に、あらかじめ起動しておき、ユーザ３から画面表示のリクエストを受け付けるまで待機する（Ｓ１１１１）。そして、ユーザ３から画面表示のリクエストを受け付けると、表示する稼働状況データ７の種類に関係なく、代行端末１２に対して、稼働状況データ７の問い合わせを行う（Ｓ１１３１）。なお、複数ある代行端末のうち、どの代行端末に問い合わせを行うかについては、実施の形態１〜実施の形態２のどちらかの方式に従えばよい（Ｓ１１２２／Ｓ１１２３）。
最後に、取得した稼働状況データ７を、稼働状況表示機能１３の画面に表示する（Ｓ１１１７）。なお、代行端末１２の問い合わせに失敗した場合は、不定を示すデータを画面に表示する。

次に、実施の形態３による稼働状況収集機能１４の稼働状況転送部１６の手順を、図１２を用いて説明する。
稼働状況収集機能１４の稼働状況転送部１６は、実施の形態１〜実施の形態２と同様に、代行端末１２上であらかじめ起動しておき、操作端末２の稼働状況表示機能１３から、稼働状況データ７取得のリクエストがあるまで待機する（Ｓ１３１１）。
そして、稼働状況表示機能１３からのリクエストを受け付けると、ここで稼働状況データ７の種類に応じて、処理の切り替えを行う（Ｓ１３３１）。
リクエストを受け付けたのが定期状態データ８の場合は、実施の形態１〜実施の形態２と同様に稼働状況データベース１７から、最新の定期状態データ８を取得する（Ｓ１３１２）。

一方、リクエストを受け付けたのが一時ログデータ９の場合は、稼働状況転送部１６が直接、制御装置１に対して問い合わせを行い、一時ログデータ９を取得する（Ｓ１３３２）。
このとき、複数のリクエストを同時に受け付けた場合は、制御装置１に対して同時に問い合わせを行わないように排他制御の処理を行う。
最後に、取得した稼働状況データ７を稼働状況表示機能１３に返信する（Ｓ１３１３）。そして、これらの手順を稼働状況収集機能１４が起動している限り、繰り返す。

実施の形態３によれば、このようにすることによって、制御装置１へのアクセスは、代行端末１２のみに制限することができ、制御装置１側のコネクション受け付けのリソースは、代行端末１２の台数に抑えることができる。
その結果、制御装置１のリソースを抑え、更なる負荷低減につなげることができる。

実施の形態４．
実施の形態３においては、稼働状況収集機能１４の稼働状況転送部１６が、同じ一時ログデータ９取得のリクエストを複数同時に受け付けた場合に、その回数だけ制御装置１に問い合わせを行うため、無駄な処理を行ってしまう恐れがある。
そこで、実施の形態４は、実施の形態３において、稼働状況収集機能１４の稼働状況転送部１６が、一時ログデータ９の問い合わせを制御装置１に対して行った際に、一旦、一時ログデータ９を稼働状況データベース１７（データベース）に保存する場合についてのものである。

図１３は、この発明の実施の形態４によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。
図１３において、１〜３、７〜９、１２〜１８は図１０におけるものと同一のものである。図１３では、一時ログデータ９を稼働状況データベース１７に保存するようにしている。稼働状況収集機能１４の稼働状況転送部１６は、一時ログデータ９について稼働状況データベース１７にアクセスする。
なお、図１３では、一時ログデータ９を稼働状況データベース１７に保存するようにしたが、一時ログデータ９を保存するデータベースは、稼働状況データベース１７とは別に設けてもよい。

次に、実施の形態４による稼働状況収集機能１４の稼働状況転送部１６の手順について、図１４を用いて説明する。
稼働状況収集機能１４の稼働状況転送部１６は、実施の形態１〜実施の形態３と同様に、代行端末１２上であらかじめ起動しておき、操作端末２の稼働状況表示機能１３から、稼働状況データ７取得のリクエストがあるまで待機する（Ｓ１３１１）。
そして、稼働状況表示機能１３からのリクエストを受け付けると、実施の形態３と同様に稼働状況データ７の種類に応じて、処理の切り替えを行う（Ｓ１３３１）。ここで、リクエストを受け付けたのが定期状態データ８の場合は、実施の形態１〜実施の形態３と同様に、稼働状況データベース１７から、最新の定期状態データ８を取得する（Ｓ１３１２）。

一方、リクエストを受け付けたのが一時ログデータ９の場合は、まず、直前の一時ログデータ９が稼働状況データベース１７に保存されていないかどうかを確認し、稼働状況データベース１７に保存されている場合は、保存されている一時ログデータ９をそのまま採用する（Ｓ１３４１）。なお、いつまでの期間を直前とするかについては、数分を想定しているが、システムに応じて変更できるようにすることが望ましい。
稼働状況データベース１７に保存されていない場合は、実施の形態３と同様に、制御装置１に対して一時ログデータ９の問い合わせを行う（Ｓ１３３２）。そして、取得した一時ログデータ９を稼働状況データベース１７に保存しておく（Ｓ１３４２）。
最後に、取得した稼働状況データ７を稼働状況表示機能１３に返信する（Ｓ１３１３）。そして、これらの手順を稼働状況収集機能１４が起動している限り、繰り返す。

実施の形態４によれば、このようにすることによって、制御装置１に対しての多重な一時ログデータ９の問い合わせを防止することができ、制御装置１の負荷を更に低減することができる。

実施の形態５．
実施の形態１〜実施の形態４においては、必ず代行端末１２を介する仕組みであったため、全ての代行端末１２がダウンしてしまった場合に稼働状況の監視ができなかった。
そこで、実施の形態５では、実施の形態１〜実施の形態４の仕組みによって、まずは代行端末１２に問い合わせを行うものの、もしも全ての代行端末１２への問い合わせに失敗した場合は、操作端末２自身が制御装置１に対して問い合わせを行う場合についてのものである。

図１５は、この発明の実施の形態５によるプラント監視制御システムの稼働状況監視の動作を示すイメージ図である。
図１５において、１〜３、７、１２、１３は図１３におけるものと同一のものである。図１５では、操作端末２上の稼働状況表示機能１３が、全ての代行端末１２で稼働状況データの問い合わせに失敗した場合に、直接、制御装置１に対して問い合わせを行う。

次に、実施の形態５による稼働状況表示機能１３の手順について、図１６を用いて説明する。
稼働状況表示機能１３は、実施の形態１〜実施の形態４と同様に、あらかじめ起動しておき、ユーザ３から画面表示のリクエストを受け付けるまで待機する（Ｓ１１１１）。そして、ユーザ３から画面表示のリクエストを受け付けると、表示する稼働状況データ７の種類に関係なく、代行端末１２に対して、稼働状況データ７の問い合わせを行う（Ｓ１１３１）。なお、複数ある代行端末１２のうち、どの代行端末に問い合わせを行うかについては、実施の形態１〜実施の形態２のどちらかの方式に従えばよい（Ｓ１１２２／Ｓ１１２３）。

そして、全ての代行端末１２への問い合わせに失敗した場合は、稼働状況表示機能１３が直接、制御装置１に対して、稼働状況データ７取得の問い合わせを行う（Ｓ１１５１）。
最後に、取得した稼働状況データ７を、稼働状況表示機能１３の画面に表示する（Ｓ１１１７）。なお、制御装置１もしくは、全ての代行端末１２への問い合わせに失敗した場合は、不定を示すデータを画面に表示する。

実施の形態５によれば、このようにすることによって、代行端末１２が存在する場合は、代行端末１２を介することによる負荷の低減を、代行端末１２が存在しない場合は、従来同様の機能の確保を、実現することができる。

実施の形態６．
実施の形態１〜実施の形態５においては、全ての操作端末２が同じネットワーク４上に存在していたが、システムによっては、ネットワーク４が多段となり、ある制御装置１に対するネットワーク経路が操作端末２ごとに異なる場合がある。
そこで、実施の形態６では、このような場合において、複数の代行端末１２から取得した稼働状況データ７を１つにマージすることによって、より詳細な稼働状況を取得する場合についてのものである。

図１７は、この発明の実施の形態６によるプラント監視制御システムを示すシステム構成図である。
図１７において、１〜６、１２は図１におけるものと同一のものである。図１７では、ネットワーク４が複数の経路を持っている。ネットワーク４と制御装置１「Ｃ」との間が断線すると、代行端末１２「Ａ」からは、制御装置１「Ｃ」が見えるが、代行端末１２「Ｂ」からは不定に見える。

例えば、図１７のようなシステム構成の場合、代行端末１２「Ａ」と制御装置１「Ｃ」の間のネットワーク経路と、代行端末１２「Ｂ」と制御装置１「Ｃ」の間のネットワーク経路が異なる。このとき、代行端末１２「Ｂ」と制御装置１「Ｃ」の間でネットワーク４の断線が発生すると、代行端末１２「Ａ」から見ると制御装置１「Ｃ」は正常であるが、代行端末１２「Ｂ」から見ると制御装置１「Ｃ」は不定となってしまい、操作端末２から問い合わせた代行端末１２によって、ユーザ３が監視するべき稼働状況データ７の内容が変わってしまう。

そこで、この発明の実施の形態６による稼働状況監視では、あえて複数の代行端末１２に稼働状況データ７を問い合わせることによって、代行端末１２間の稼働状況データ７の差分を検証し、より詳細な稼働状況をユーザ３に表示する。本実施の形態６の場合では、制御装置１「Ｃ」が不定なのではなく、代行端末１２「Ｂ」と制御装置１「Ｃ」の間のネットワーク４が断線していることを画面に表示する。

次に、稼働状況表示機能１３の手順について、図１８を用いて説明する。
稼働状況表示機能１３は、実施の形態１〜実施の形態５と同様に、あらかじめ起動しておき、ユーザ３から画面表示のリクエストを受け付けるまで待機する（Ｓ１１１１）。そして、ユーザ３から画面表示のリクエストを受け付けると、表示する稼働状況データ７の種類に関係なく、代行端末１２に対して、稼働状況データ７の問い合わせを行う（Ｓ１１３１）。なお、代行端末１２が複数ある場合については、全ての代行端末１２に対して問い合わせを行う（Ｓ１１２３）。

そして、代行端末１２から取得した複数の稼働状況データ７の内容を１つにマージし、その差分からより詳細な稼働状況を算出する（Ｓ１１６１）。
最後に、取得し、内容をマージした稼働状況データ７を、稼働状況表示機能１３の画面に表示する（Ｓ１１１７）。なお、制御装置１もしくは、全ての代行端末１２への問い合わせに失敗した場合は、不定を示すデータを画面に表示する。

実施の形態６によれば、このようにすることによって、従来の稼働状況監視で確認することのできなかった、より高信頼な稼働状況の監視を実現することができる。

なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。

１ 制御装置、２ 操作端末、３ ユーザ、４ ネットワーク、５ 分散ＰＩＯ、
６ プラント・補機、７ 稼働状況データ、８ 定期状態データ、９ 一時ログデータ、１０ 代行端末（マスタ）、１１ 代行端末（スレーブ）、１２ 代行端末、
１３ 稼働状況表示機能、１４ 稼働状況収集機能、１５ 稼働状況取得部、
１６ 稼働状況転送部、１７ 稼働状況データベース、１８ 定期起動トリガ。

Claims (6)

1. プラント機器を制御する制御装置、
   この制御装置の稼働状況を示す稼働状況データを取得し、表示する複数の操作端末、
   及びこの操作端末の上記制御装置からの上記稼働状況データの取得を代行する複数の代行端末を備え、
   上記稼働状況データは、上記制御装置の運転状態を示すデータを定期的に取得した状態データと、上記制御装置で異常が発生した場合のデータである一時ログデータとを有し、
   上記各代行端末は、上記状態データを定周期で取得して、自身のデータベースに保存するとともに、
   上記操作端末から上記状態データの要求を受けた場合には、上記データベースに保存した上記状態データを当該操作端末に送信し、
   上記操作端末から上記一時ログデータの要求を受けた場合には、上記制御装置から上記一時ログデータを取得して、当該操作端末に転送することを特徴とするプラント監視制御システム。
2. 上記代行端末は、上記制御装置から取得した上記一時ログデータを自身のデータベースに保存し、他の操作端末から上記一時ログデータの要求を受けた場合に、上記データベースに保存した上記一時ログデータを当該操作端末に送信することを特徴とする請求項１記載のプラント監視制御システム。
3. 上記代行端末は、マスタまたはスレーブとして設定され、
   上記操作端末は、上記マスタを優先して上記稼働状況データの要求を行うとともに、
   上記マスタが上記要求を受けられない場合には、上記スレーブに上記要求を行うことを特徴とする請求項１または請求項２記載のプラント監視制御システム。
4. 上記操作端末は、複数台のうちの任意の１台の上記代行端末に上記稼働状況データの要求を行うとともに、
   当該代行端末が上記要求を受けられない場合には、他の代行端末に上記要求を行うことを特徴とする請求項１または請求項２記載のプラント監視制御システム。
5. 上記操作端末は、全ての上記代行端末への上記稼働状況データの要求に失敗した場合には、上記制御装置から直接、上記稼働状況データを取得することを特徴とする請求項１から請求項４のいずれか一項記載のプラント監視制御システム。
6. 上記代行端末は、上記操作端末の中から選定されることを特徴とする請求項１から請求項５のいずれか一項記載のプラント監視制御システム。