特許 6194835 鉄鋼プラント制御システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6194835

(24)【登録日】2017年8月25日

(45)【発行日】2017年9月13日

(54)【発明の名称】鉄鋼プラント制御システム

(51)【国際特許分類】

   H04L 12/28 20060101AFI20170904BHJP

【ＦＩ】

   H04L12/28 200M

   H04L12/28 100F

【請求項の数】7

【全頁数】20

(21)【出願番号】特願2014-66348(P2014-66348)

(22)【出願日】2014年3月27日

(65)【公開番号】特開2015-192202(P2015-192202A)

(43)【公開日】2015年11月2日

【審査請求日】2016年2月24日

(73)【特許権者】

【識別番号】501137636

【氏名又は名称】東芝三菱電機産業システム株式会社

(74)【代理人】

【識別番号】100082175

【弁理士】

【氏名又は名称】高田 守

(74)【代理人】

【識別番号】100106150

【弁理士】

【氏名又は名称】高橋 英樹

(72)【発明者】

【氏名】吉森 文紀

【審査官】 衣鳩 文彦

(56)【参考文献】

【文献】 特開２００１−００７８１６（ＪＰ，Ａ）

【文献】 特開平０８−１８１７３８（ＪＰ，Ａ）

【文献】 特開２００４−２８２５４１（ＪＰ，Ａ）

【文献】 特開平１１−００３２９３（ＪＰ，Ａ）

【文献】 国際公開第２０１２／０６６８２４（ＷＯ，Ａ１）

【文献】 特開平０２−０５５４４３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／２８

(57)【特許請求の範囲】

【請求項1】

独立した第１伝送経路と第２伝送経路とにそれぞれ接続された監視対象機器と、前記第１伝送経路と前記第２伝送経路とにそれぞれ接続された監視装置と、を備える鉄鋼プラント制御システムであって、
前記監視装置は、
前記第１伝送経路を介して前記監視対象機器に対して状態を問い合わせる第１送受信処理と、前記第２伝送経路を介して前記監視対象機器に対して状態を問い合わせる第２送受信処理とを実行するポーリング処理部と、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果との組み合わせに基づいて、前記第１伝送経路、前記第２伝送経路、前記監視対象機器それぞれについて正常状態であるか異常状態であるかを判定する状態監視処理部と、を備え、
前記監視対象機器は、鉄鋼プラントのアクチュエータを制御するコントローラであり、
前記コントローラは、自機器の状態情報とエラー情報を記憶する共有メモリを備え、
前記コントローラの共有メモリの内容は、第３伝送経路を介して前記監視装置の共有メモリに同期され、
前記監視装置は、
自装置の共有メモリから前記コントローラの状態情報を取得して、前記コントローラが正常状態であるか異常状態であるかを判定するヘルシー監視部と、
前記ヘルシー監視部が前記コントローラは異常状態であると判定した場合に、自装置の共有メモリから前記コントローラのエラー情報を収集するＰＬＣ故障情報収集部と、をさらに備えること、
を特徴とする鉄鋼プラント制御システム。

【請求項2】

前記状態監視処理部は、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果の少なくとも一方が応答有りである場合に、前記監視対象機器は正常状態であると判定し、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果の両方が応答無しである場合に、前記監視対象機器は異常状態であると判定すること、
を特徴とする請求項１記載の鉄鋼プラント制御システム。

【請求項3】

前記状態監視処理部は、
前記第１送受信処理の問い合わせ結果が応答無し、かつ、前記第２送受信処理の問い合わせ結果が応答有りである場合に、前記第１伝送経路は異常状態、かつ、前記監視対象機器は正常状態であると判定すること、
を特徴とする請求項１又は２記載の鉄鋼プラント制御システム。

【請求項4】

コネクション型プロトコルで互いに通信可能な第１監視対象機器および第２監視対象機器を備え、
前記監視装置は、前記第１監視対象機器が認識するコネクション状態と、前記第２監視対象機器が認識するコネクション状態とを収集し、両コネクション状態がオープンである場合にのみ正常な接続状態であると判定し、いずれかのコネクション状態がオープン以外である場合に異常な接続状態であると判定するコネクション状態監視部をさらに備えること、
を特徴とする請求項１乃至３のいずれか１項記載の鉄鋼プラント制御システム。

【請求項5】

前記監視対象機器は、前記第１伝送経路および前記第２伝送経路の一部を構成するネットワーク機器を含み、
前記監視装置は、ＳＮＭＰを用いて前記ネットワーク機器のステータス情報を収集し、予め定められた定義情報と比較して全て一致する場合には正常、それ以外の場合には異常と判定するＳＮＭＰ情報収集部をさらに備えること、
を特徴とする請求項１乃至４のいずれか１項記載の鉄鋼プラント制御システム。

【請求項6】

独立した第１伝送経路と第２伝送経路とにそれぞれ接続された監視対象機器と、前記第１伝送経路と前記第２伝送経路とにそれぞれ接続された監視装置と、を備える鉄鋼プラント制御システムであって、
前記監視装置は、
前記第１伝送経路を介して前記監視対象機器に対して状態を問い合わせる第１送受信処理と、前記第２伝送経路を介して前記監視対象機器に対して状態を問い合わせる第２送受信処理とを実行するポーリング処理部と、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果との組み合わせに基づいて、前記第１伝送経路、前記第２伝送経路、前記監視対象機器それぞれについて正常状態であるか異常状態であるかを判定する状態監視処理部と、を備え、
コネクション型プロトコルで互いに通信可能な第１監視対象機器および第２監視対象機器を備え、
前記監視装置は、前記第１監視対象機器が認識するコネクション状態と、前記第２監視対象機器が認識するコネクション状態とを収集し、両コネクション状態がオープンである場合にのみ正常な接続状態であると判定し、いずれかのコネクション状態がオープン以外である場合に異常な接続状態であると判定するコネクション状態監視部をさらに備えること、
を特徴とする鉄鋼プラント制御システム。

【請求項7】

独立した第１伝送経路と第２伝送経路とにそれぞれ接続された監視対象機器と、前記第１伝送経路と前記第２伝送経路とにそれぞれ接続された監視装置と、を備える鉄鋼プラント制御システムであって、
前記監視装置は、
前記第１伝送経路を介して前記監視対象機器に対して状態を問い合わせる第１送受信処理と、前記第２伝送経路を介して前記監視対象機器に対して状態を問い合わせる第２送受信処理とを実行するポーリング処理部と、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果との組み合わせに基づいて、前記第１伝送経路、前記第２伝送経路、前記監視対象機器それぞれについて正常状態であるか異常状態であるかを判定する状態監視処理部と、を備え、
前記監視対象機器は、前記第１伝送経路および前記第２伝送経路の一部を構成するネットワーク機器を含み、
前記監視装置は、ＳＮＭＰを用いて前記ネットワーク機器のステータス情報を収集し、予め定められた定義情報と比較して全て一致する場合には正常、それ以外の場合には異常と判定するＳＮＭＰ情報収集部をさらに備えること、
を特徴とする鉄鋼プラント制御システム。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、鉄鋼プラント制御システムに係り、特に、ネットワーク接続された監視対象機器（制御機器、ネットワーク機器）の健全性を監視する監視装置を備えた鉄鋼プラント制御システムに関する。

【背景技術】

【0002】

従来、ＳＮＭＰ（Simple Network Management Protocol）を用いて監視対象機器の情報を収集し、ネットワークを監視するネットワーク監視装置が知られている。特許文献１（特開２００３−２４４１４３号公報）では、ＳＮＭＰのポーリングを用いて、複数の監視対象機器の故障発生および復旧情報を取得する場合に、監視対象装置を効率よく監視することが可能な遠隔監視制御方法が提案されている。
尚、出願人は、本発明に関連するものとして、上記の文献を含めて、以下に記載する文献を認識している。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００３−２４４１４３号公報

【特許文献2】特開２００７−１８９６１５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１のネットワーク監視装置では、ＳＮＭＰのポーリングを用いて監視対象機器の故障発生および復旧情報を取得するが、監視対象機器まで間の伝送経路（ネットワーク）に障害が発生している場合、監視対象機器の情報を取得することができない。この場合、伝送経路に障害があるのか、監視対象機器に障害があるのかを知り得ず、システムの障害箇所、障害内容の特定が十分に行えないという課題がある。特に多数の監視対象機器を備えた大規模ネットワークでは大きな課題となる。

【0005】

この発明は、上述のような課題を解決するためになされたもので、ネットワーク接続された監視対象機器を備える鉄鋼プラント制御システムにおいて、ネットワーク自体に障害が発生した場合であっても、ロバスト性高く障害箇所を特定することのできる鉄鋼プラント制御システムを提供することを目的とする。

【課題を解決するための手段】

【0006】

第１の発明は、上記の目的を達成するため、独立した第１伝送経路と第２伝送経路とにそれぞれ接続された監視対象機器と、前記第１伝送経路と前記第２伝送経路とにそれぞれ接続された監視装置と、を備える鉄鋼プラント制御システムであって、
前記監視装置は、
前記第１伝送経路を介して前記監視対象機器に対して状態を問い合わせる第１送受信処理と、前記第２伝送経路を介して前記監視対象機器に対して状態を問い合わせる第２送受信処理とを実行するポーリング処理部と、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果との組み合わせに基づいて、前記第１伝送経路、前記第２伝送経路、前記監視対象機器それぞれについて正常状態であるか異常状態であるかを判定する状態監視処理部と、を備えることを特徴とする。

【0007】

また、第２の発明は、第１の発明において、
前記状態監視処理部は、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果の少なくとも一方が応答有りである場合に、前記監視対象機器は正常状態であると判定し、
前記第１送受信処理の問い合わせ結果と、前記第２送受信処理の問い合わせ結果の両方が応答無しである場合に、前記監視対象機器は異常状態であると判定すること、を特徴とする。

【0008】

また、第３の発明は、第１又は第２の発明において、
前記状態監視処理部は、
前記第１送受信処理の問い合わせ結果が応答無し、かつ、前記第２送受信処理の問い合わせ結果が応答有りである場合に、前記第１伝送経路は異常状態、かつ、前記監視対象機器は正常状態であると判定すること、を特徴とする。

【0009】

また、第４の発明は、第１乃至第３の発明のいずれかにおいて、
前記監視対象機器は、鉄鋼プラントのアクチュエータを制御するコントローラであり、
前記コントローラは、自機器の状態情報とエラー情報を記憶する共有メモリを備え、
前記コントローラの共有メモリの内容は、第３伝送経路を介して前記監視装置の共有メモリに同期され、
前記監視装置は、
自装置の共有メモリから前記コントローラの状態情報を取得して、前記コントローラが正常状態であるか異常状態であるかを判定するヘルシー監視部と、
前記ヘルシー監視部が前記コントローラは異常状態であると判定した場合に、自装置の共有メモリから前記コントローラのエラー情報を収集するＰＬＣ故障情報収集部と、をさらに備えること、を特徴とする。

【0010】

また、第５の発明は、第１乃至第４の発明のいずれかにおいて、
コネクション型プロトコルで互いに通信可能な第１監視対象機器および第２監視対象機器を備え、
前記監視装置は、前記第１監視対象機器が認識するコネクション状態と、前記第２監視対象機器が認識するコネクション状態と収集し、両コネクション状態がオープンである場合にのみ正常な接続状態であると判定し、いずれかのコネクション状態がオープン以外である場合に異常な接続状態であると判定するコネクション状態監視部をさらに備えること、を特徴とする。

【0011】

また、第６の発明は、第１乃至第５の発明のいずれかにおいて、
前記監視対象機器は、前記第１伝送経路および前記第２伝送経路の一部を構成するネットワーク機器を含み、
前記監視装置は、ＳＮＭＰを用いて前記ネットワーク機器のステータス情報を収集し、予め定義された定義情報と比較して全て一致する場合には正常、それ以外の場合には異常と判定するＳＮＭＰ情報収集部をさらに備えること、を特徴とする。

【発明の効果】

【0012】

これらの発明によれば、監視対象機器と監視装置との間の伝送経路（ネットワーク）を２重化し、それぞれの伝送経路を用いて監視対象機器を監視し、監視結果を掛け合わせることで、監視対象機器の状態をロバスト性高く判定可能となる。また、ネットワーク自体に障害が発生した場合であっても、ロバスト性高く障害箇所を特定することができる。

【図面の簡単な説明】

【0013】

【図1】本発明の実施の形態１に係るシステム構成を説明するための図である。

【図2】定義ファイル読込処理部１４が実行する処理ルーチンのフローチャートである。

【図3】ポーリング処理部１３が実行する処理ルーチンのフローチャートである。

【図4】状態監視処理部１５が実行する処理ルーチンのフローチャートである。

【図5】ポーリング応答監視結果の一例を示す図である。

【図6】計算機情報収集部１７が実行する処理ルーチンのフローチャートである。

【図7】ヘルシー監視部１８が実行する処理ルーチンのフローチャートである。

【図8】Ｗｅｂサーバ部１９が実行する処理ルーチンのフローチャートである。

【図9】Ｗｅｂ端末７に表示されるＷｅｂ監視画面の一例である。

【図10】本発明の実施の形態２に係るシステム構成を説明するための図である。

【図11】ＰＬＣ故障情報収集部２０が実行する処理ルーチンのフローチャートである。

【図12】本発明の実施の形態３に係るシステム構成を説明するための図である。

【図13】コネクション状態監視部２２が実行する処理ルーチンのフローチャートである。

【図14】コネクション状態情報のチェック結果の一例である。

【図15】本発明の実施の形態４に係るシステム構成を説明するための図である。

【図16】ＳＮＭＰ情報収集部２４が実行する処理ルーチンのフローチャートである。

【図17】ＳＮＭＰ情報の一例である。

【発明を実施するための形態】

【0014】

以下、図面を参照して本発明の実施の形態について詳細に説明する。尚、各図において共通する要素には、同一の符号を付して重複する説明を省略する。

【0015】

実施の形態１．
［実施の形態１のシステム構成］
図１は、本発明の実施の形態１に係るシステム構成を説明するための図である。図１に示すシステムは、鉄鋼プラント制御システムである。図１に示すシステムは、制御機器と、ネットワーク機器と、監視装置とを有する。

【0016】

制御機器は、計算機１、ＨＭＩ（Human Machine Interface）４、ＰＬＣ（Programmable Logic Controller）５、Ｇ／Ｗ（Gateway）６、Ｗｅｂ端末７である。ネットワーク機器は、第１ＨＵＢ２、第２ＨＵＢ３、制御ＬＡＮ用ＨＵＢ８である。監視装置は、ネットワーク監視装置９である。

【0017】

計算機１は、プラントのラインを制御するスケジュールを生成する汎用コンピュータである。計算機１は、情報収集エージェント１６を備える。また、ＨＭＩ４は、計算機１で生成されたスケジュールや制御状態を表示する汎用コンピュータである。

【0018】

ネットワーク監視装置９は、演算装置、記憶装置、入出力装置を備える。ネットワーク監視装置９は、ネットワーク監視部１０、状態監視ＤＢ１２、計算機情報収集部１７、ヘルシー監視部１８、Ｗｅｂサーバ部１９を備える。各部は所定のプログラムにより演算装置、記憶装置、入出力装置を動作させることで実現される。

【0019】

また、ネットワーク監視装置９は、定義ファイル１１を備える。定義ファイル１１は、鉄鋼プラント制御システムを構成する機器の情報を記述したファイルである。例えば、定義ファイルには、機器名称、機器の第１ＩＰアドレス、第２ＩＰアドレス、接続情報（第１ＨＵＢ２、第２ＨＵＢ３、制御ＬＡＮ用ＨＵＢ８との接続情報）、Ｗｅｂ端末表示用の位置情報、第１ＭＡＣアドレス、第２ＭＡＣアドレス、機器種別、各部の起動間隔など、ネットワーク監視装置９の各部が動作するための種々の情報が含まれる。

【0020】

ネットワーク監視部１０は、ポーリング処理部１３、定義ファイル読込処理部１４、状態監視処理部１５を備える。

【0021】

（ネットワーク）
制御機器である計算機１、ＨＭＩ４、ＰＬＣ５、Ｇ／Ｗ６、Ｗｅｂ端末７は、それぞれ
第１ＨＵＢ２に接続される。同様に、計算機１、ＨＭＩ４、ＰＬＣ５、Ｇ／Ｗ６、Ｗｅｂ端末７は、それぞれ第２ＨＵＢ３に接続される。つまり、各制御機器は、独立した２つのＨＵＢにそれぞれ接続される。

【0022】

ネットワーク監視装置９は、第１ＨＵＢ２と第２ＨＵＢ３にそれぞれ接続される。そのため、ネットワーク監視装置９は、第１ＨＵＢ２を有する第１伝送経路（図１の第１ネットワーク）を介して各制御機器に接続されると共に、第２ＨＵＢ３を有する第２伝送経路（図１の第２ネットワーク）を介して各制御機器に接続される。つまり、各制御装置は、２系統の異なるネットワークを介してネットワーク監視装置９に接続される。

【0023】

ネットワーク監視装置９は、少なくとも２つ以上のネットワークに接続される。好ましくは、ネットワーク監視装置９は、鉄鋼プラント制御システムを構成するすべてのネットワークに接続される。

【0024】

また、ＰＬＣ５、Ｇ／Ｗ６、ネットワーク監視装置９は、制御ＬＡＮ用ＨＵＢ８にも接続される。制御ＬＡＮ用ＨＵＢ８は、リモートＩ／Ｏを介して鉄鋼プラントの各部に接続される。

【0025】

制御ＬＡＮ用ＨＵＢ８を介してＰＬＣ５、Ｇ／Ｗ６、ネットワーク監視装置９が接続された第３伝送経路は、論理的な共有メモリを有するスキャン（周期）伝送方式のネットワークである（以下、制御ＬＡＮと記す。）。具体的には、制御ＬＡＮでは、各ノード（ＰＬＣ５、Ｇ／Ｗ６、ネットワーク監視装置９）は、それぞれ共有メモリを有する。各共有メモリには、自ノードの情報と他ノードの情報を記憶する領域が割り当てられている。各ノードの情報は、自ノードの共有メモリに記憶され、周期的に他ノードにマルチキャストされる。そのため、各ノードの共有メモリは同期され、各ノードは自ノードの共有メモリから他ノードの情報を取得できる。このように、各ノードの共有メモリが同期されることで、制御ＬＡＮは論理的な共有メモリを実現する。以下の説明においては、単に制御ＬＡＮの共有メモリと称する。

【0026】

鉄鋼プラント制御システムでは、ＰＬＣ、ＨＭＩ等の制御機器は本来複数台あり、鉄鋼プラントの必要箇所に設置される。本実施の形態では説明容易のため、各１台のみ記載しているがこれに限定されるものではない。また、ＨＵＢとの間では、ＭＣ（メディアコンバータ）等を利用してメディア変換（ＵＴＰケーブルから光ケーブルへ変換）することがある。この発明では、ＭＣはネットワークとして取り扱う。

【0027】

図１において、Ｗｅｂ端末７は、第２ＨＵＢ３に接続されているが、ネットワーク監視装置９にアクセス可能なネットワークに接続されていれば良い。また、Ｗｅｂ端末は、ネットワークに複数台接続されていても良い。

【0028】

［実施の形態１における各部動作］
次に図１〜図８を用いて、ネットワーク監視装置９の各部の動作について説明する。ネットワーク監視部１０、計算機情報収集部１７、ヘルシー監視部１８、Ｗｅｂサーバ部１９では、それぞれ監視対象とする機器や監視方法が異なる。各部を同一周期で動作させると、監視結果収集が一番遅いものに収集周期を合わせる必要がある。その場合、収集周期が遅いために一時的な障害を見逃す可能性がある。本実施の形態のシステムでは、このような制約条件を緩和するため、各部に個別に収集周期を設定可能である。

【0029】

（定義ファイル読込処理）
ネットワーク監視部１０は、定義ファイル読込処理部１４によって、まず鉄鋼プラント制御システムを構成する機器の情報を記述した定義ファイル１１を読み込む。図２は、定義ファイル読込処理部１４が実行する処理ルーチンのフローチャートである。

【0030】

図２において、まず、定義ファイル読込処理部１４は、定義ファイル１１を読み込む（ステップＳ２１）。具体的には、定義ファイル読込処理部１４は、読み込んだ定義ファイル１１の内容が所定のフォーマットを満たしているか否かを判定し、異常があればエラーメッセージを出力する。

【0031】

定義ファイル１１が所定のフォーマットを満たしている場合には、定義ファイル読込処理部１４は、定義ファイル１１の内容を定義情報として状態監視ＤＢ１２に書き込む（ステップＳ２２）。

【0032】

（ポーリング処理）
次に、ネットワーク監視部１０は、状態監視ＤＢ１２の定義情報に従い、ポーリング処理を実行する。ポーリング処理部１３は、第１伝送経路（図１の第１ネットワーク）を用いて監視対象機器に対して状態を問い合わせる第１送受信処理と、第２伝送経路（図１の第２ネットワーク）を用いて監視対象機器に対して状態を問い合わせる第２送受信処理とを実行する。監視対象機器には、上述した制御機器およびネットワーク機器が含まれる。全ての制御機器およびネットワーク機器を監視対象機器としてもよいが、特定の制御機器のみを監視対象機器としてもよい。

【0033】

図３は、ポーリング処理部１３が実行する処理ルーチンのフローチャートである。ポーリング処理部１３の起動間隔は、定義ファイル１１で指定されており、状態監視ＤＢ１２の定義情報として格納されている。

【0034】

図３において、まず、ポーリング処理部１３は、状態監視ＤＢ１２の定義情報に従い、定義情報に登録された監視対象機器（登録機器）に対し、第１送受信処理による第１伝送経路を用いたポーリング（ｐｉｎｇ等）と、第２送受信処理による第２伝送経路を用いたポーリングを個別に実行する（ステップＳ３１）。

【0035】

ポーリング処理部１３は、ポーリングの応答を監視する（ステップＳ３２）。具体的には、ポーリング処理部１３は、状態監視ＤＢ１２の定義情報に従い監視時間内に応答があるか否かを監視する。ポーリングの応答は、伝送経路毎（ネットワーク毎）に監視される。

【0036】

ポーリング処理部１３は、監視対象機器毎に登録機器応答チェックを行い、監視時間内に応答があれば正常と、監視時間内に応答が無ければ異常と判断する（ステップＳ３３）。応答の有無は、伝送経路毎（ネットワーク毎）に判断される。

【0037】

ポーリング処理部１３は、登録ＭＡＣチェックを実行する（ステップＳ３４）。具体的には、ポーリング処理部１３は、応答があった監視対象機器のＭＡＣアドレスと、状態監視ＤＢ１２の定義情報に登録されている監視対象機器のＭＡＣアドレスとが一致しているか否かを判定する。登録ＭＡＣアドレスと一致している場合には正常と、一致していない場合には異常と判定する。

【0038】

ポーリング処理部１３は、ポーリングの結果を状態監視ＤＢ１２に書き込む（ステップＳ３５）。具体的には、ポーリング処理部１３は、ステップＳ３３における登録機器応答チェックの結果とステップＳ３４における登録ＭＡＣチェックの結果を、ポーリング応答監視結果として状態監視ＤＢ１２に書き込む。

【0039】

なお、監視対象機器が接続されているネットワーク数は定義ファイル１１で変更可能である。本実施形態では、一例として、図１に示すネットワーク数が２つの場合を挙げて説明する。

【0040】

以上説明したように、本発明の実施の形態１のシステムによれば、監視対象機器の監視方法としてping等を使用することでＳＮＭＰの様な特別なプロトコルに対応していない機器も監視対象とすることができる。また、監視対象機器のＭＡＣアドレスを定義情報に登録することで、未登録の機器が制御システムに接続されていないかを検出することができる。

【0041】

（状態監視処理）
次に、ネットワーク監視部１０は、状態監視ＤＢ１２の定義情報に従い、状態監視処理を実行する。状態監視処理部１５は、第１送受信処理による第１伝送経路（図１の第１ネットワーク）を用いた問い合わせ結果と、第２送受信処理による第２伝送経路（図１の第２ネットワーク）を用いた問い合わせ結果との組み合わせに基づいて、第１伝送経路、第２伝送経路、監視対象機器それぞれについて正常状態であるか異常状態であるかを判定する。

【0042】

具体的には、状態監視処理部１５は、第１送受信処理の問い合わせ結果と、第２送受信処理の問い合わせ結果の少なくとも一方が応答有りである場合に、監視対象機器は正常状態であると判定する。

【0043】

また、状態監視処理部１５は、第１送受信処理の問い合わせ結果と、第２送受信処理の問い合わせ結果の両方が応答無しである場合に、監視対象機器は異常状態であると判定する。

【0044】

また、状態監視処理部１５は、第１送受信処理の問い合わせ結果が応答無しであり、第２送受信処理の問い合わせ結果が応答有りである場合に、第１伝送経路は異常状態、かつ、監視対象機器は正常状態であると判定する。

【0045】

図４は、状態監視処理部１５が実行する処理ルーチンのフローチャートである。状態監視処理部１５の起動間隔は、定義ファイル１１で指定されており、状態監視ＤＢの定義情報として格納されている。状態監視処理部１５の起動間隔は、ポーリング処理部１３の起動間隔の１／２以下に指定される。

【0046】

図４において、まず、状態監視処理部１５は、状態監視ＤＢ１２から定義情報と上述したポーリング応答監視結果を読み込む（ステップＳ４１）。

【0047】

状態監視処理部１５は、ポーリング応答監視結果に基づいて、ネットワーク毎に監視対象機器について応答チェックを行う（ステップＳ４２）。

【0048】

状態監視処理部１５は、監視対象機器の状態を判定する（ステップＳ４３）。具体的には、状態監視処理部１５は、図１の第１ネットワークを用いたポーリングの結果と、図２の第２ネットワークを用いたポーリングの結果の少なくとも一方が応答有りである場合に、監視対象機器は正常状態であると判定する。また、状態監視処理部１５は、第１伝送経路を用いたポーリングの結果と、第２伝送経路を用いたポーリングの結果の両方が応答無しである場合に、監視対象機器は異常状態であると判定する。

【0049】

図５は、ポーリング応答監視結果の一例を示す図である。図５に示す例では、第１ネットワークのみを用いて各監視対象機器を監視した場合には、第１ＨＵＢ２、ＨＭＩ４、ＰＬＣ５、Ｇ／Ｗ６が異常状態であるとの監視結果が得られる。本実施形態のシステムでは、さらに、第２ネットワークを用いた監視結果も取得する。ステップＳ４３の処理において、これらの監視結果を掛け合わせることで、第１ＨＵＢ２とＨＭＩ４が異常状態であり、他の監視対象機器は正常状態であると判定することができる。

【0050】

状態監視処理部１５は、ステップＳ４３において判定された各監視対象機器の状態を、状態監視結果として状態監視ＤＢ１２に書き込む（ステップＳ４４）。

【0051】

以上説明したように、本発明の実施の形態１のシステムによれば、監視対象機器の健全性を複数の独立したネットワークを介して監視し、各ネットワークにおける監視結果を掛け合わせることで、システムの障害発生箇所の特定が可能となる。

【0052】

（計算機情報収集）
情報収集エージェント１６は、計算機情報収集部１７からの要求に応じて、計算機１内の情報を収集する。図６は、計算機情報収集部１７が実行する処理ルーチンのフローチャートである。

【0053】

図６において、まず、計算機情報収集部１７は、状態監視ＤＢ１２から計算機１に関する定義情報を読み込む（ステップＳ６１）。

【0054】

計算機情報収集部１７は、計算機状態収集を実行する（ステップＳ６２）。具体的には、計算機情報収集部１７は、計算機１内の情報収集エージェント１６に対してＣＰＵ負荷、ＤＩＳＫ使用量、プログラム稼働状態等の収集を要求する。

【0055】

計算機情報収集部１７は、情報収集結果チェックを実行する（ステップＳ６３）。具体的には、計算機情報収集部１７は、ステップＳ６２により収集された収集結果の各項目を、定義情報に定められている各項目の閾値と比較し、収集結果が閾値以下であるか否かを判定する。計算機情報収集部１７は、全ての項目が閾値以下である場合に、計算機１は正常状態であると判定し、いずれかの項目が閾値より大きい場合に、計算機１は異常状態であると判定する。

【0056】

計算機情報収集部１７は、ステップＳ６２の収集結果とステップＳ６３の判定結果を状態監視ＤＢに書き込む（ステップＳ６４）。

【0057】

以上説明したように、本発明の実施の形態１のシステムによれば、計算機１の動作状態（ＣＰＵ負荷、ＤＩＳＫ使用料、プログラムの稼働状態等）を収集する情報収集エージェント１６を計算機１に配置することで、計算機１の動作状態を監視することができる。

【0058】

（ヘルシー監視）
上述した制御ＬＡＮの共有メモリ（スキャン伝送メモリ）には、監視対象機器（例えば、ＰＬＣ５）の状態が正常か異常かを検出するためのヘルシーカウンタがアサインされている。監視対象機器は、ヘルシーカウンタを定期的に更新する。ヘルシー監視部１８は、ヘルシーカウンタを監視する。

【0059】

図７は、ヘルシー監視部１８が実行する処理ルーチンのフローチャートである。ヘルシー監視部１８の起動間隔は、定義ファイル１１で指定されており、状態監視ＤＢ１２の定義情報として格納されている。

【0060】

図７において、まず、ヘルシー監視部１８は、状態監視ＤＢ１２に格納されたＰＬＣ５に関する定義情報を基に、監視対象機器であるＰＬＣ５について、ヘルシーカウンタの監視に必要な情報（ステーションアドレス等）を取得する（ステップＳ７１）。

【0061】

ヘルシー監視部１８は、ＰＬＣヘルシー収集を実行する（ステップＳ７２）。具体的には、ヘルシー監視部１８は、ネットワーク監視装置９上の共有メモリからＰＬＣ５のヘルシーカウンタを読み込む。

【0062】

ヘルシー監視部１８は、ＰＬＣヘルシーチェックを実行する（ステップＳ７３）。具体的には、ヘルシー監視部１８は、ＰＬＣ５のヘルシーカウンタが前回値から変更されているか否かをチェックする。ヘルシー監視部１８は、ヘルシーカウンタが停止している（前回値から変更無し）場合に、ＰＬＣ５は異常状態であると判定する。

【0063】

ヘルシー監視部１８は、判定したＰＬＣ５の状態（正常／異常）をＰＬＣ５の状態情報として、状態監視ＤＢ１２に書き込む（ステップＳ７４）。

【0064】

以上説明したように、本発明の実施の形態１のシステムによれば、監視対象機器であるＰＬＣ５のステータス情報（制御ＬＡＮの共有メモリ上のヘルシーカウンタ）を監視することでコントローラの動作状態を判定することができる。

【0065】

（Ｗｅｂサーバ）
Ｗｅｂサーバ部１９は、Ｗｅｂ端末７から要求に応じて、ネットワーク監視部１０、計算機情報収集部１７、ヘルシー監視部１８により収集した制御機器およびネットワーク機器の状態を表示する。

【0066】

図８は、Ｗｅｂサーバ部１９が実行する処理ルーチンのフローチャートである。Ｗｅｂ端末７からの表示要求に応じてＷｅｂサーバ部１９は動作する。

【0067】

図８において、まず、Ｗｅｂサーバ部１９は、状態監視ＤＢ１２から、ネットワークの構成情報と、監視対象機器（制御機器およびネットワーク機器）の状態情報を読み込む（ステップＳ８１）。

【0068】

Ｗｅｂサーバ部１９は、状態監視ＤＢ１２から読み込まれた監視対象機器の正常／異常の状態をチェックする（ステップＳ８２）。

【0069】

Ｗｅｂサーバ部１９は、鉄鋼プラント制御システムを構成するネットワーク機器や制御機器の描画情報をＷｅｂ端末７に送信する（ステップＳ８３）。図９は、Ｗｅｂ端末７に表示されるＷｅｂ監視画面の一例である。

【0070】

Ｗｅｂサーバ部１９は、監視対象機器の正常／異常に対応した色情報をＷｅｂ端末７に送信する（ステップＳ８４）。図９に示す例では、正常な機器は緑、異常な機器は赤で描画される。

【0071】

また、Ｗｅｂ端末７では、画面上の監視対象機器を選択することで、計算機情報収集部１７やヘルシー監視部１８の処理により収集された状態情報を表示させることが可能である。鉄鋼プラント制御システムを構成する機器の状態を画面で確認することができる。

【0072】

以上説明したように、本発明の実施の形態１のシステムによれば、ネットワーク監視装置９内にＷｅｂサーバ部１９を設けることでネットワークに接続された外部機器（Ｗｅｂ端末７）から鉄鋼プラント制御システムの健全性の確認が可能となる。

【0073】

ところで、上述した実施の形態１のシステムにおいては、２系統の伝送経路でポーリング処理を実行することとしているが、これに限定されるものではない。３系統以上の伝送経路でポーリング処理を実行し、それらの問い合わせ結果を掛け合わせることで、システムの障害発生箇所の特定することとしてもよい。

【0074】

実施の形態２．
［実施の形態２のシステム構成］
次に、図１０、図１１を参照して本発明の実施の形態２について説明する。本実施形態のシステムは図１０に示す構成において、ネットワーク監視装置９に図１１のルーチンを実施させることで実現することができる。

【0075】

図１０は、本発明の実施の形態２に係るシステム構成を説明するための図である。図１０に示すシステム構成は、ネットワーク監視装置９が、更にＰＬＣ故障情報収集部２０と、ＰＬＣ故障ログ格納ファイル２１とを備える点を除き、図１に示すシステム構成と同様である。

【0076】

［実施の形態２における各部動作］
（ＰＬＣ故障情報収集）
図１１は、ＰＬＣ故障情報収集部２０が実行する処理ルーチンのフローチャートである。ＰＬＣ故障情報収集部２０は、状態監視ＤＢ１２の定義情報に従い定周期で起動される。

【0077】

図１１において、まず、ＰＬＣ故障情報収集部２０は、状態監視ＤＢ１２から監視対象となるＰＬＣ５の状態情報を読み込む（ステップＳ１１１）。ＰＬＣ５の状態情報は、実施の形態１で述べたヘルシー監視部１８により状態監視ＤＢ１２に書き込まれている。

【0078】

ＰＬＣ故障情報収集部２０は、ＰＬＣヘルシーチェックを実行する（ステップＳ１１２）。読み込まれたＰＬＣ５の状態情報をチェックし、異常状態であればＰＬＣ故障ログ（ＰＬＣ５内部で異常が発生した際に出力されるエラー情報）をネットワーク監視装置９の共有メモリから読み込む。

【0079】

ＰＬＣ故障情報収集部２０は、読み込んだＰＬＣ故障ログをネットワーク監視装置９のＰＬＣ故障ログ格納ファイル２１に書き込む（ステップＳ１１３）。

【0080】

通常、鉄鋼プラントの各種アクチュエータを制御するＰＬＣ５は、そのハードウェア制約により、ＰＬＣ５内に長期間のＰＬＣ故障ログを保存することは難しい。そのため、複数の故障が発生した場合等にＰＬＣ５内のＰＬＣ故障ログが上書きされることがあり、故障発生後、操作員の到着を待ってＰＬＣ故障ログを収集したのでは、ＰＬＣ故障時のエラー情報が失われ、故障原因の調査が困難となることがある。

【0081】

本発明の実施の形態２に係るシステムでは、定周期でＰＬＣ５の状態を監視して、異常発生時にＰＬＣ故障ログを、ＰＬＣ故障ログ格納ファイル２１に保存することで、ＰＬＣ故障時のエラー情報を残すことが可能となる。また、ＰＬＣ故障情報収集部２０の起動周期を短くすることで失われるＰＬＣ故障ログを少なくすることが可能であり、故障原因の調査が容易となる。

【0082】

実施の形態３．
［実施の形態３のシステム構成］
次に、図１２〜図１４を参照して本発明の実施の形態３について説明する。本実施形態のシステムは図１２に示す構成において、ネットワーク監視装置９に図１３のルーチンを実施させることで実現することができる。

【0083】

図１２は、本発明の実施の形態３に係るシステム構成を説明するための図である。図１２に示すシステム構成は、計算機１およびＰＬＣ５がコネクション状態収集部２３を備え、ネットワーク監視装置９が、コネクション状態監視部２２を備える点を除き、図１に示すシステム構成と同様である。

【0084】

［実施の形態３における各部動作］
（コネクション状態監視）
図１３は、コネクション状態監視部２２が実行する処理ルーチンのフローチャートである。コネクション状態監視部２２は、状態監視ＤＢ１２の定義情報に従い定周期で起動される。

【0085】

図１３において、まず、コネクション状態監視部２２は、状態監視ＤＢ１２からコネクション状態監視の監視対象となる機器（計算機１、ＰＬＣ５等のコネクション状態収集部２３を設けている機器）に関する定義情報を読み込む（ステップＳ１３１）。

【0086】

コネクション状態監視部２２は、コネクション状態情報を収集する（ステップＳ１３２）。読み込んだ定義情報に基づき、各監視対象機器のコネクション状態収集部２３に対して、コネクション状態情報（オープン／クローズ／オープニング／クロージング等）の送信を要求する。各監視対象機器のコネクション状態収集部２３は、他のルーチンにおいて現在のコネクション状態情報を収集しており、要求に応じてコネクション状態情報をコネクション状態監視部２２に送信する。

【0087】

なお、オープン／クローズとは、機器Ａが機器Ｂに接続要求／切断要求を求めて、機器Ｂから許可応答を受信した状態を意味し、オープニング／クロージングとは、機器Ａが機器Ｂに接続要求／切断要求を求めて、機器Ｂから未だ許可応答を受信していない状態を意味する。

【0088】

コネクション状態監視部２２は、収集したコネクション状態情報をチェックする（ステップＳ１３３）。収集したコネクション状態情報に基づいて、ペアとなるコネクション状態が全てオープンの場合にそのペアのコネクション状態は正常であると判定し、いずれかのコネクション状態がオープン以外である場合にコネクション状態は異常であると判定する。

【0089】

図１４は、コネクション状態情報のチェック結果の一例である。図１４には、計算機１とＰＬＣ５とのコネクション状態がソケット毎に記載されている。ソケット１のように、計算機１およびＰＬＣ５のコネクション状態収集部２３が収集したコネクション状態がいずれも「接続」である場合には、コネクション状態は正常であると判定される。また、ソケット２のように、計算機１のコネクション状態収集部２３が収集したコネクション状態が「未接続」であり、ＰＬＣ５のコネクション状態収集部２３が収集したコネクション状態が「接続」である場合には、コネクション状態は異常であると判定される。

【0090】

コネクション状態監視部２２は、コネクション状態情報のチェック結果を状態監視ＤＢ１２に書き込む（ステップＳ１３４）。

【0091】

以上説明したように、本発明の実施の形態３に係るシステムによれば、ハーフコネクション（ペアとなる片側はオープン、相手側はクローズ）の検出が可能となり論理的な接続の異常を検出することが可能となる。特に、鉄鋼プラント制御システムのように機器の接続関係が変更されないシステムにおいて好適である。

【0092】

実施の形態４．
［実施の形態４のシステム構成］
次に、図１５〜図１７を参照して本発明の実施の形態３について説明する。本実施形態のシステムは図１５に示す構成において、ネットワーク監視装置９に図１６のルーチンを実施させることで実現することができる。

【0093】

図１５は、本発明の実施の形態４に係るシステム構成を説明するための図である。図１５に示すシステム構成は、ネットワーク監視装置９が、ＳＮＭＰ情報収集部２４を備える点を除き、図１に示すシステム構成と同様である。

【0094】

［実施の形態４における各部動作］
（ＳＮＭＰ情報収集）
図１６は、ＳＮＭＰ情報収集部２４が実行する処理ルーチンのフローチャートである。ＳＮＭＰ情報収集部２４は、状態監視ＤＢ１２の定義情報に従い定周期で起動される。

【0095】

図１６において、まず、ＳＮＭＰ情報収集部２４は、状態監視ＤＢ１２からＳＮＭＰ状態収集の対象機器（図１５に示す例では、第１ＨＵＢ２、第２ＨＵＢ３が対象機器）に関する定義情報（各機器の登録情報並びに、通信ステータスの正常閾値情報）を読み込む（ステップＳ１６１）。

【0096】

ＳＮＭＰ情報収集部２４は、対象機器に対してＳＮＭＰ経由でＳＮＭＰ情報を収集する（ステップＳ１６２）。

【0097】

ＳＮＭＰ情報収集部２４は、収集したＳＮＭＰ情報をチェックする（ステップＳ１６３）。具体的には、ＳＮＭＰ情報収集部２４は、収集したＳＮＭＰ情報に基づき、各ポートのステータス（ｕｐ／ｄｏｗｎ）、リンク速度（例えば１００ＭＦｕｌｌ等）、接続先ＭＡＣアドレスをチェックし、ステップＳ１６１で読み込んだ登録情報と一致しているかをチェックする。全て一致した場合のみ正常と判定される。他の場合は異常と判定される。また、ステップＳ１６２で収集したＳＮＭＰ情報において、ＨＵＢ自体のステータスが異常である場合には、異常と判定される。

【0098】

さらに、ＳＮＭＰ情報収集部２４は、ステップＳ１６２で収集したＳＮＭＰ情報において、通信負荷、エラー発生率等の通信ステータス情報を、ステップＳ１６１で読み込んだ通信ステータスの正常閾値と比較して、通信ステータス情報が正常閾値以下であるか否かを判定する。正常・異常の判定を行う。ＳＮＭＰ情報収集部２４は、通信ステータス情報の各項目が正常閾値以下である場合に対象機器は正常であると判定し、いずれかの通信ステータス情報の項目が通信ステータス正常閾値より大きい場合に、対象機器は異常状態であると判定する。

【0099】

図１７は、ＳＮＭＰ情報の一例である。図１７には、ネットワーク機器毎に、ＩＰアドレスと各ポートの状態と、ＨＵＢ自体の状態が記載されている。

【0100】

ＳＮＭＰ情報収集部２４は、ＳＮＭＰ情報のチェック結果を状態監視ＤＢ１２に書き込む（ステップＳ１６４）。

【0101】

以上説明したように、本発明の実施の形態４に係るシステムによれば、ＳＮＭＰに対応したＨＵＢ等のネットワーク機器に対して、予め定めた登録情報との差異に基づいた異常検出が可能となる。

【符号の説明】

【0102】

１ 計算機
２ 第１ＨＵＢ
３ 第２ＨＵＢ
４ ＨＭＩ
５ ＰＬＣ
６ Ｇ／Ｗ
７ Ｗｅｂ端末
８ 制御ＬＡＮ用ＨＵＢ
９ ネットワーク監視装置
１０ ネットワーク監視部
１１ 定義ファイル
１２ 状態監視ＤＢ
１３ ポーリング処理部
１４ 定義ファイル読込処理部
１５ 状態監視処理部
１６ 情報収集エージェント
１７ 計算機情報収集部
１８ ヘルシー監視部
１９ Ｗｅｂサーバ部
２０ ＰＬＣ故障情報収集部
２１ 故障ログ格納ファイル
２２ コネクション状態監視部
２３ コネクション状態収集部
２４ ＳＮＭＰ情報収集部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】