JP5666543B2 - 処理プラントに関連する異常事態を検出する方法及びシステム - Google Patents

Description

関連出願の相互参照
汎用目的のためにその全体が本明細書中に参照することによって援用されている、２００４年３月３日に出願され、「処理プラントにおける異常事態防止」と題された米国仮特許出願第60/549,796号の特典を請求する。

本出願は、以下の特許出願：
本出願と同日出願され、「処理プラントにおける異常事態防止のための構成システムおよび方法」と題された米国特許出願第１０／９７２，２２４号（弁護士管理番号Ｎｏ．３０２０３／３９７４６）、および
本出願と同日出願され、「処理プラントにおける異常事態防止のためのデータ提示システム」と題された米国特許出願番号１０／９７２，１５５号（弁護士管理番号Ｎｏ．３０２０３／４００５６）に関連している。
上記の参照特許出願は、汎用目的のためにその全体が本明細書中に参照することによって援用されている。

本発明は、一般に、処理プラントにおける診断およびメンテナンスを実行することに係り、より詳細には、処理プラント内での異常事態発生を削減または防止できるように処理プラント内に予測診断能力を提供することに関する。

化学薬品、石油、または他の処理において使用されるシステムなどの処理コントロールシステムは、一般に、少なくとも一つのホストまたはオペレータワークステーション、および、アナログ、ディジタル、またはアナログ／ディジタル共用のバスを介して、例えば、フィールドデバイスなどの一つ以上の処理コントロールおよび計装デバイスに通信可能に連結された一つ以上の集中型または分散型処理コントローラを含む。例えば、バルブ、バルブポジショナ（位置決め器）、スイッチ、トランスミッタ、およびセンサ（例えば、温度、圧力、および流量センサ）の形態をとり得るフィールドデバイスは、処理プラント環境内に配置され、バルブの開閉、処理パラメタの測定、流体流量の増減などの処理プラント内機能を実行する。周知のＦＯＵＮＤＡＴＩＯＮ^TMＦｉｅｌｄｂｕｓ（ファンデーション（商標）フィールドバス）(以下、Ｆｉｅｌｄｂｕｓと称せられる）プロトコルまたはＨＡＲＴ^R（ハート（登録商標））プロトコルに追従するフィールドデバイスなどのスマートフィールドデバイスも、コントロール計算、報知（アラーム）機能、および処理コントローラ内で一般にインプリメント（実装）される他のコントロール機能を実行することもできる。

一般に処理プラント環境内に配置される処理コントローラは、フィールドデバイスによって作成されあるいは該フィールドデバイスに関連する処理測定値または処理変数、および／または、該フィールドデバイスに一部関連する他の情報を表す信号を受信し、コントローラアプリケーションを実行する。該コントローラアプリケーションは、例えば、処理コントロールを決定し、受信した情報に基づいてコントロール信号を生成し、ＨＡＲＴおよびＦｉｅｌｄｂｕｓフィールドデバイスなどのフィールドデバイスにおいて実行されているコントロールモジュールまたはブロックと協働する異なるコントロールモジュールをインプリメントする。該処理コントローラ内のコントロールモジュールは、通信回線や信号パスを介して、フィールドデバイスへコントロール信号を送信し、これによって、該処理のオペレーションをコントロールする。

処理に関しての、例えば、処理コントロールルーチンの設定変更、処理コントローラやスマートフィールドデバイス内でのコントロールモジュールのオペレーションの修正、処理の現在状態または処理プラント内の特定デバイスの現在状態の目視（ビューイング）、フィールドデバイスおよび処理コントローラによって生成される報知の目視、人員訓練や処理コントロールソフトウェアの試験を目的とした処理の動作のシミュレーション、処理プラント内の問題やハードウェア故障の診断などの所望の機能を、オペレータやメンテナンス担当者が、実行することを可能とするために、フィールドデバイスおよび処理コントローラからの情報は、一般に、例えば、オペレータワークステーション、メンテナンスワークステーション、パーソナルコンピュータ、携帯デバイス、データ履歴（ヒストリアン）、レポートジェネレータ、集中データベースなどの一つ以上の他のハードウェアデバイスによって使用可能とされている。

一般的な処理プラントは、一つ以上の処理コントローラに接続された、バルブ、トランスミッタ、センサなどの処理コントロールおよび計装デバイスを有するが、処理オペレーションに必要であるかあるいは関連している多くの他の支援デバイスも設けられている。これらの更なるデバイスとしては、例えば、電源装置、発電および配電装置、タービンやモータなどの回転装置などが挙げられ、これらの装置は、一般プラントの多数の箇所に配置されている。この更なる装置は、処理変数を必ずしも生成することもなければ使用することもないし、多くの例において、処理オペレーションに影響を与える目的で、処理コントローラによって制御されることもなければ、連結されることもないが、にもかかわらず、これらの装置は、該処理の適切なオペレーションに重要であり、最終的には必要とされる。

知られているように、特に、多数のフィールドデバイスおよび支援装置を有する処理プラントにおける処理プラント環境下でさまざまな問題が頻繁に発生している。これらの問題は、デバイスが破壊したり、誤動作を生じたりすること、ソフトウェアルーチンなどの論理エレメントが不良モードにあること、処理コントロールループの調整が不良であること、処理プラント内のデバイス間の通信の一つ以上に故障が発生するなどの形態をとる。以上の問題は、実際、多数発生しており、これが、一般には、通常、処理が、処理プラントの準最適性能に関連する異常状態（即ち、処理プラントが異常状況にあること）で動作するという結果を生じる。一旦、これらの問題が発生し検出されると、処理プラント内で発生する問題の原因を突き止め、判断するとともに、オペレータやメンテナンス担当者が、これらの問題を診断するとともに補正するのを助けるために、多数の診断ツールおよびアプリケーションが開発されてきた。例えば、直接またはワイヤレスバス、イーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））、モデム、電話回線などの通信接続を介して、一般に処理コントローラに接続されている、オペレータワークステーションは、多数のコントロールモジュールおよびコントロールループ診断ツールを含むＥｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ（エマーソンプロセスマネージメント社）によって販売されているＤＥＬＴＡ Ｖ^TM（デルタＶ（商標））システムおよびＯｖａｔｉｏｎ（オベーション）コントロールシステムなどのソフトウェアまたはファームウェアを実行するように用いられるプロセッサおよびメモリを有する。同様に、コントローラアプリケーションと同じ通信接続を介して、または、（ＯＰＣ）（処理コントロールのためのオブジェクト連結および埋込み）接続、携帯接続などの異なる通信接続を介して、フィールドデバイスなどの処理コントロールデバイスに接続され得る、メンテナンスワークステーションは、一般に、処理プラント内のデバイスを試験するとともに処理プラント内のフィールドデバイスおよび他のデバイス上でメンテナンス業務を実行するために処理プラント内のフィールドデバイスによって生成されるメンテナンスの報知および警告を目視（ビュー）するように設計された一つ以上のアプリケーションを含む。処理プラント内の支援装置の問題を診断するためにも同様の診断アプリケーションが開発されている。

このように、例えば、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔによって販売される（“Ｉｎｔｅｇｒａｔｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋ ｆｏｒ ｕｓｅ ｉｎ ａ Ｆｉｅｌｄ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（フィールドデバイスマネージメントシステムにおいて使用する統合通信ネットワーク）”と題された米国特許第5,960,214号に少なくとも部分的に記載された）Ａｓｓｅｔ Ｍａｎａｇｅｍｅｎｔ Ｓｏｌｕｔｉｏｎｓ（ＡＭＳ）（アセットマネージメントソリューション）アプリケーションは、フィールドデバイスの動作状態を確認しトラッキング（追跡）するために、該フィールドデバイスに一部関連するデータとの通信を可能とすると共に該データを格納する。いくつかの例において、ＡＭＳアプリケーションは、フィールドデバイスと通信して該フィールドデバイス内のパラメタを変更し、例えば、自己較正ルーチンまたは自己診断ルーチンなどのアプリケーションをフィールドデバイスそれ自体に実行させ、該フィールドデバイスの状態またはヘルス（調子）などについて情報を得るために使用される。この情報は、例えば、状態情報（例えば、報知または他の同様の事象が発生したかについて）、デバイス構成情報（フィールドデバイスが現在構成されているまたは構成され得る方法と該フィールドデバイスによって用いられる測定単位の種類）、デバイスパラメタ（例えば、フィールドデバイス範囲値および他のパラメタ）などを含み得る。当然、この情報は、フィールドデバイスに伴う問題をモニタし、維持し、および／または診断するために、メンテナンス担当者によって使用され得る。

同様に、多くの処理プラントは、種々の回転装置の動作状態をモニタし、診断し、最適化するために使用される、例えば、ＣＳＩ（共通システムインターフェース）システムによって提供されるＲＢＭ（リスクベースメンテナンス）製品などの装置モニタおよび診断アプリケーション、または、任意の他の公知のアプリケーションを含む。通常、メンテナンス担当者は、プラント内の回転装置の性能を維持、管理し、回転装置に関わる問題について判断し、該回転装置を修理すべきか交換すべきかについて、また、その適切な時期を判断するためにこれらのアプリケーションを使用する。同様に、多くの処理プラントは、発電および配電装置をコントロールすると共に維持するため、例えば、リーバート（Ｌｉｅｂｅｒｔ）社およびアスコ（ＡＳＣＯ）社によって提供される電源制御および診断アプリケーションを含む。また、処理プラントの制御業務を最適化するために、処理プラント内で、例えば、リアルタイムオプティマイザ（実時間最適化装置）（ＲＴＯ＋）などの制御最適化アプリケーションを実行することも知られている。一般に、このような最適化アプリケーションは、該処理プラントの複雑なアルゴリズムおよび／またはモデルを使用して、例えば、利益などのいくつかの所望される最適化変数に対して該処理プラントのオペレーション最適化のためにどのように入力を変更すべきかを予測する。

以上の診断および最適化アプリケーションは、一般に、オペレータまたはメンテナンスワークステーションの一つ以上においてシステムワイドベースでインプリメントされ、処理プラントの作動状態、または、該処理プラント内のデバイスおよび装置に関して、オペレータまたはメンテナンス担当者へ、予備構成されたディスプレイを提供する。一般のディスプレイは、処理プラント内の処理コントローラまたは他のデバイスによって生成される報知を受ける報知ディスプレイ、処理コントローラおよび処理プラント内の他のデバイスの動作状態を示すコントロールディスプレイ、処理プラント内のデバイスの動作状態を示すメンテナンスディスプレイなどを含む。同様に、以上の診断アプリケーションは、オペレータやメンテナンス担当者が、コントロールループを再調整したり、他のコントロールパラメタをリセットしたり、これらのフィールドデバイスの現行の状態を判断するために一つ以上のフィールドデバイスを試験したり、フィールドデバイスまたは他の装置を較正したり、あるいは、処理プラント内のデバイスおよび装置上での他の問題の検出および補正業務を実行することを可能とする。

これらの種々のアプリケーション及びツールは、処理プラント内の問題を識別し補正する際に非常に役の立つのであるが、一般に、これらの診断アプリケーションは、処理プラント内で問題が発生した後でのみ、即ち、該プラント内に異常事態既存状態において、使用するように構成されている。あいにく、異常事態は、これらのツールを使って、検出され、識別され、補正される前のある段階で存在するため、結果的には、該問題が検出され、識別され、補正されている期間について、該処理プラントは準最適性能となる。多くの場合、コントロールオペレータは、最初に、処理プラントの報知、警告または性能低下に基づいていくつかの問題が存在することを検出する。次に、オペレータは、メンテナンス担当者に潜在的な問題を通知する。メンテナンス担当者は、実際の問題を検出する場合もあれば、検出しない場合もあり、試験や他の診断アプリケーションを実際に実行する前に更にプロンプトしたり、あるいは、実際の問題を識別するために必要とされる他の業務を実行したりする必要がある場合もある。一旦問題が識別されると、メンテナンス担当者は、部品を注文しメンテナンス手順の予定を立てる必要があり、これらのすべてを含む問題の発生とこの問題の補正までに結果的にはかなりの期間が必要とされ、この間、処理プラントは一般に該プラントの準最適性能に対応付けられる異常事態下で稼動される。

更に、多くの処理プラントは、相対的に短時間でプラント内に相当なコストやダメージを生じる異常事態を経験し得る。例えば、いくつかの異常事態は、設備に相当なダメージを与え、原材料の損失を生じ、または、これらの異常事態が発生している時間がたとえ短くても、処理プラント内で予期できない作業中止時間を生じることになる。このように、問題が発生した後、単にプラント内で問題を検出するだけでは、その問題がいかに迅速に補正されても、やはりまだ処理プラント内に多くの損失やダメージが生じ得る。この結果、異常事態が発生してから、該処理プラント内で既に発生した問題に対処したりそれらを補正したりするのではなく、異常事態の発生を初めから防止しようと試みることが望ましい。

処理プラント内で何らかの重大な損失が発生する前に予測される異常事態を防止する工程を取るという目的に沿って、これらの異常事態が実際に発生する前に処理プラント内のいくつかの異常事態の発生をユーザに予測させることを可能とするデータを収集するために使用され得る技術が現在一つ提供されている。この方法は、（一部が米国特許出願第08/623,569号、現在は、米国特許第6,017,143号に基づく）「根本原因診断（”Ｒｏｏｔ Ｃａｕｓｅ Ｄｉａｇｎｏｓｔｉｃｓ”）と題された米国特許出願第09/972,078号に開示されている。これらの両出願は本明細書中に参照することによって組み込まれている。概して、この技術は、統計データ収集および処理ブロックまたは統計処理モニタ（ＳＰＭ）ブロックを、処理プラント内のフィールドデバイスなどの多数のデバイスの各々に、配置する。該統計データ収集および処理ブロックは、例えば、処理可変データを収集し、該収集されたデータに関連する、平均値、メジアン値、標準偏差値などの統計測定値を求める。次に、これらの統計測定値は、ユーザに送られ、既知の異常事態の今後の発生を示唆するパターンを認識するために解析される。今後発生しそうな特定の異常事態が検出されると、根本的な問題を補正するための工程がとられ、これにより、この異常事態を初めから回避することができる。しかしながら、統計データを収集する多数のフィールドデバイスを有する処理プラントにおいては特に、データの収集および解析は、通常のメンテナンスオペレータにとっては、非常に面倒であり、冗長な作業である。更にまた、メンテナンス担当者が統計データを収集することが可能である場合でも、この人物が、該データを最適に解析しあるいは目視する方法や、仮にあったとしても、該データによって今後発生する異常事態のどの異常事態を示唆すべきかを判断する方法を知らない場合も考えられる。

また、概して、大きな処理規模においては特に、ＳＰＭ（統計処理モニタ）によって生成される統計処理データの全てを収集すると共に目視するためのプラントを構成することは負荷が大きく、非常に冗長である。実際、現在、ユーザは、異なるフィールドデバイス内で関心が持たれるパラメタの各々を個別にモニタするＯＰＣクライアントを作成する必要があり、これは、該データを収集するために全てのフィールドデバイスが個別に構成されなければならないということである。この構成処理には非常に手間がかかり、人的エラーを誘いやすい。

一つの態様において、システムは、処理プラントに関連する異常状態を検出する。該システムは、複数のデバイスによって実施される信号処理データ収集ブロックによって生成される信号処理データを受信する。該信号処理データ収集ブロックは、統計データ、周波数解析データ、自動回帰データ、ウェーブレットなどを生成し得る。該システムは、該処理プラントに関連する少なくとも一つの異常状態を検出すべく構成される解析エンジンを含む。信号処理データは、該解析エンジンに提供され、該解析エンジンがアクションを取るべきかを判断する。

他の態様において、処理プラントに関連する異常状態を検出するために解析エンジンを構成するためのシステムは、該解析エンジンによって解析すべき信号処理パラメタを指定するためのユーザインターフェースメカニズムを含む。該信号処理パラメタは、該処理プラント内の複数のデバイスによってインプリメントされる信号処理データ収集ブロックによって生成され得る。該指定された信号処理パラメタの解析を指定する為に他のユーザインターフェースメカニズムが使用され得る。構成データは、ユーザインターフェースメカニズムを介して、受信され、格納される。

一つ以上のオペレータおよびメンテナンスワークステーション、コントローラ、フィールドデバイスおよび支援装置を含む分散コントロールおよびメンテナンスネットワークを有する処理プラントを示す例示的なブロック図である。 処理プラントの異なるエレメント内に配置される異常事態防止システムの種々のコンポーネント間の通信接続を示す、図１の処理プラントの一部を示す例示的なブロック図である。 図１または２の処理プラントのデバイス内で一組の統計処理モニタブロックの構成を示すディスプレイである。 処理プラント内で統計処理収集ブロックを構成するとともに該処理プラントの操業中にこれらのブロックから統計データを収集するための技術を示すフローチャートである。 図１または図２の処理プラント内でＯＰＣサーバによって収集されるようなプラント階層を示すディスプレイスクリーンを示す図である。 統計処理モニタブロックを有するデバイスに関連するプラントエレメントの階層を示すディスプレイスクリーンを示す図である。 統計処理モニタブロック内でモニタされる一組の統計処理モニタパラメタをユーザが選択することを可能とするディスプレイスクリーン示す図である。 統計処理モニタブロックを有するデバイス内で生成される収集された統計処理モニタデータを示すために提供され得るディスプレイスクリーンを示す図である。 デバイス内のデータ収集ブロックから収集された統計データエレメントを含むエクスプローラ階層を示すスクリーンディスプレイである。 フィールドデバイス内の統計データ収集ブロックを追加または構成する方法を示すスクリーンディスプレイである。 ユーザがトレンドデータを目視するためにナビゲートする方法を示すスクリーンディスプレイである。 統計収集ブロックから収集された生データを目視するためにユーザがナビゲートし得る方法を示すスクリーンディスプレイである。 統計処理モニタパラメタ対時間の座標を示すスクリーンディスプレイである。 各々が同一座標に描かれた一つ以上のパラメタを有する、異なる統計処理モニタパラメタ対時間の四つの座標からなる一組を示すスクリーンディスプレイである。 コントロールおよび指定限界値を含む統計処理モニタパラメタのヒストグラムの座標を示すスクリーンディスプレイである。 統計処理モニタパラメタ対時間のＸ−チャートを示すスクリーンディスプレイである。 統計処理モニタパラメタ対時間のＳ−チャートを示すスクリーンディスプレイである。 一組の統計処理モニタパラメタに対する２次元分布図を示すスクリーンディスプレイである。 一組の三つの統計処理モニタパラメタに対する３次元分布図を示すスクリーンディスプレイである。 一組の四つの統計処理モニタパラメタに対する４次元分布図を示すスクリーンディスプレイである。 一組の統計処理モニタパラメタに対する相関マトリックスを示すスクリーンディスプレイである。 図２１の相関マトリックスの一部を描く３次元棒グラフを示すスクリーンディスプレイである。 所望される相関ドメインからの偏差値を示す相関ドメイン座標を示すスクリーンディスプレイである。 カラーコード化された相関マトリックスを示すスクリーンディスプレイである。 選択されたデバイスの処理変数とユーザが他の比較値を目視することを可能とするユーザインタフェースエレメントとの二つの測定値を比較する比較図を示すスクリーンディスプレイである。 二つの統計モニタ処理パラメタ対時間の座標を示すスクリーンディスプレイであって、これらのパラメタ間の既知の相関値を示す図である。 相関値対時間の座標を示すスクリーンディスプレイである。 複数の相関値対時間の座標を示すスクリーンディスプレイである。 相関値とベースライン値対時間の座標を示すスクリーンディスプレイである。 一組の統計処理モニタパラメタのための相関値変更マトリクスを示すスクリーンディスプレイである。 カラーコード化された相関値変更マトリックスを示すスクリーンディスプレイである。 相関値合計対時間の座標を示すスクリーンディスプレイである。 カラーコード化された相関値変更マトリックスと全体の相関値対時間の座標を示すスクリーンディスプレイである。 相関値と最適ラインの傾きに対応する角度との極座標を示す図である。 最適ラインの傾きに対応する角度との複数の相関値の極座標を示すスクリーンディスプレイである。 最適ラインの傾きに対応する角度との複数の相関値の極座標を示すスクリーンディスプレイである。 ユーザが処理プラントから収集された統計処理モニタデータに対してルールを作成し適用することを可能とするルールエンジン開発および実行システムを示すブロック図である。 ユーザが図３７のルールエンジン開発および実行システムに対してルールを作成することを可能とする構成スクリーンを示すスクリーンディスプレイである。 図３７のルールエンジンによって使用されるルールと該ルールエンジンによって生成される警告を要約する、ルール実行エンジンオペレーション要約を示すスクリーンディスプレイである。 ユーザが図３７のルールエンジン開発および実行システムのためのルールを作成することを可能とする第２の構成スクリーンを示すスクリーンディスプレイである。 ユーザが図３７のルールエンジン開発および実行システムのためのルールを作成することを可能とする第３の構成スクリーンを示すスクリーンディスプレイである。 警告／報知情報を含む、処理プラントの一部を示すスクリーンディスプレイである。 警告／報知情報を含む、処理プラントの一部を示す他のスクリーンディスプレイである。 警告／報知情報を含む、処理プラントの一部を示すまた他のスクリーンディスプレイである。 警告／報知情報を含む、処理プラントの一部を示す更に他のスクリーンディスプレイである。 異常事態検出および防止を実行するための他の処理プラント内で接続されるインターフェースデバイスを示す図である。 異常事態検出および防止を実行するためのまた他の処理プラント内で接続されるインターフェースデバイスを示す図である。

図１を参照すると、異常事態防止システムがインプリメントされ得る例示的な処理プラント１０は、一つ以上の通信網を介して支援装置と相互接続される多数のコントロール（制御）およびメンテナンスシステムを含む。特に、図１の処理プラント１０は、一つ以上の処理コントロールシステム１２および１４を含む。処理コントロールシステム１２は、ＰＲＯＶＯＸ（プロボックス）やＲＳ３システムなどの従来の処理コントロールシステムであってもよいし、コントローラ１２Ｂおよび入力／出力（Ｉ／Ｏ)カード１２Ｃに接続されたオペレータインタフェース１２Ａを含む任意の他のコントロールシステムであってよい。また、該入力／出力（Ｉ／Ｏ)カード１２Ｃは、アナログおよび（Ｈｉｇｈｗａｙ Ａｄｄｒｅｓｓａｂｌｅ Ｒｅｍｏｔｅ Ｔｒａｎｓｍｉｔｔｅｒ（ＨＡＲＴ））フィールドデバイス１５などの種々のフィールドデバイスに接続されている。分散形処理コントロールシステムであってもよい処理コントロールシステム１４は、Ｅｔｈｅｒｎｅｔ（登録商標）（イーサネット（登録商標））バスなどのバスを介して、一つ以上の分散コントローラ１４Ｂに連結された一つ以上のオペレータインターフェース１４Ａを含む。該コントローラ１４Ｂは、例えば、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ（エマーソンプロセスマネージメント社、テキサス州、オースティン）によって販売されているＤｅｌｔａＶ^TM（商標）や任意の他の所望されるタイプのコントローラであってもよい。コントローラ１４Ｂは、Ｉ／Ｏデバイスを介して、例えば、ＨＡＲＴやＦｉｅｌｄｂｕｓフィールドデバイスなどの一つ以上のフィールドデバイス１６に、または、ＰＲＯＦＩＢＵＳ（プロフィバス）（登録商標）、ＷＯＲＬＤＦＩＰ（ワールドフィップ）（登録商標）、Ｄｅｖｉｃｅ−Ｎｅｔ（デバイスネット）（登録商標）、ＡＳ−Ｉｎｔｅｒｆａｃｅ（インターフェース）およびＣＡＮ（キャン）プロトコルのいずれかを使用するフィールドデバイスを含む任意の他のスマートまたはノンスマートフィールドデバイスに、接続される。公知のように、フィールドデバイス１６は、コントローラ１４Ｂへ、処理変数だけでなく他のデバイス情報に関連するアナログまたはディジタル情報を提供し得る。オペレータインタフェース１４Ａは、たとえば、コントロール（制御）オプティマイザ、診療エキスパート、ニューラルネットワーク、チューナなどを含む処理動作をコントロールするために、処理コントロールオペレータが利用可能なツールを格納するとともに実行し得る。

また更に、ＡＭＳアプリケーションまたは任意の他のデバイスモニタおよび通信アプリケーションを実行するコンピュータなどのメンテナンスシステムは、処理コントロールシステム１２および１４に、または、これらのシステム内部の個々のデバイスに接続され、メンテナンスおよびモニタ活動を実行する。例えば、メンテナンスコンピュータ１８は、（ワイヤレスまたは携帯デバイス・ネットワークを含む）任意の所望される通信回線またはネットワークを介して、コントローラ１２Ｂにおよび／またはデバイス１５に接続され、デバイス１５と通信したり、場合によっては、該デバイス１５上で他のメンテナンス活動を再構築または実行したりする。同様に、ＡＭＳアプリケーションなどのメンテナンスアプリケーションは、デバイス１６の動作状態に関連するデータ収集を含むメンテナンスおよびモニタ機能を実行するために、分散処理コントロールシステム１４に関連する一つ以上のユーザインターフェース１４Ａでインストールされ、実行され得る。

処理プラント１０はまた、いくつかの永続的な、あるいは、（装置２０に接続されて読み出しを行っては、次に、削除されるようなバス、ワイヤレス通信システムまたは携帯デバイスなどの）一時的な通信リンクを介して、メンテナンスコンピュータ２２に接続されたタービンやモータなどのさまざまな回転装置２０も含む。メンテナンスコンピュータ２２は、例えば、ＣＳＩ（Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｐａｎｙ（エマーションプロセスマネージメント社））によって提供される公知のモニタおよび診断アプリケーション２３、または、回転装置２０の状態を診断し、モニタし、最適化するために使用される任意の他の公知のアプリケーションを格納し、実行し得る。通常、メンテナンス担当者は、プラント１０内の回転装置２０の性能を維持し管理し、回転装置２０に関わる問題を判断し、該回転装置２０の修理または交換の時期あるいは修理または交換しなければならないかについての判断を行うために、アプリケーション２３を使用する。場合によっては、外部の専門家やサービス機関が、装置２０に関するデータを一時的に取得または測定し、該装置２０に影響を与える問題、性能低下または他の問題点を検出すべく、該装置に対する解析を実行するためにこのデータを使用することもある。これらの場合において、解析を実行するコンピュータは、いかなる通信回線を介してもシステム１０の他の部分に接続されることはなく、たとえ、接続されたにせよ、一時的にすぎない。

同様に、プラント１０に関連する発電および分配装置２５を有する発電および分配システム２４は、例えば、バスを介して、該プラント１０内の発電および分配装置２５の動作を実行し管理する他のコンピュータ２６に接続されている。コンピュータ２６は、発電および分配装置２５をコントロールし、維持するために、例えば、リーバート社およびアスコ社や他社によって提供される公知の電源コントロールおよび診断アプリケーション２７を実行する。またここでも、多くの場合は、外部の専門家やサービス機関が、装置２５に関するデータを一時的に取得または測定し、該装置２５に影響を与える問題、性能低下または他の問題点を検出すべく、該装置に対する解析を実行するために、このデータを使用することもある。これらの場合において、解析を実行するコンピュータ（例えば、コンピュータ２６）は、いかなる通信回線を介してもシステム１０の他の部分に接続されることはなく、たとえ、接続されたにせよ、一時的にすぎない。

図１に示されるように、コンピュータシステム３０は、異常事態防止システム３５の少なくとも一部をインプリメントし、特に、コンピュータシステム３０は、統計的収集および処理ブロックを含み得る、構成およびデータ収集アプリケーション３８、目視またはインターフェースアプリケーション４０と、ルールエンジン開発および実行アプリケーション４２を格納し、更に、該処理内のいくつかのデバイス内で生成される統計データを格納する統計処理モニタデータベース４３を格納する。概して、構成およびデータ収集アプリケーション３８は、フィールドデバイス１５、１６、コントローラ１２Ｂ、コントローラ１４Ｂ、回転デバイス２０またはその支援コンピュータ２２、発電装置２５またはその支援コンピュータ２６、および処理プラント１０内の任意の他の所望されるデバイスおよび装置内に配置された、多数の統計データ収集および解析ブロック（図１に示されていない）の各々を構成するとともにこれらと通信し、これによって、異常事態防止を実行するこれらのブロックの各々から統計データ（または、場合によっては、処理可変データ）を収集する。構成およびデータ収集アプリケーション３８は、ハードワイヤードバス４５を介して、プラント１０内のコンピュータやデバイスの各々に通信可能に接続されてもよいし、または、それに替えて、例えば、ワイヤレス接続、ＯＰＣを使用する専用接続、データを収集するための携帯デバイスなどに依存するような断続接続などを含む、任意の他の所望される通信接続などを介して、接続されてもよい。同様に、アプリケーション３８は、（図１にインターネット接続４６として示される）インターネット、電話接続などのＬＡＮや公衆接続を介して、処理プラント１０内のフィールドデバイスおよび装置に関するデータを得ることができる。このようなデータは、例えば、第三者のサービスプロバイダによって収集される。また、アプリケーション３８は、例えば、イーサネット（登録商標）、Ｍｏｄｂｕｓ（モドバス）、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ ＭａｒｋＵＰ Ｌａｎｇｕａｇｅ（ハイパーテキストマーク付け言語）、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ ＭａｒｋＵＰ Ｌａｎｇｕａｇｅ（拡張可能なマーク付け言語）、プロプラエタリ（所有権主張可能）な技術および／またはプロトコルなどを含む、種々の技術および／またはプロトコルを介して、プラント１０内のコンピュータおよび／またはデバイスに通信可能に連結され得る。このように、本明細書中では、プラント１０のコンピュータおよび／またはデバイスにアプリケーション３８を通信可能に連結させるためのＯＰＣを用いた特定の例が記載されているが、当業者は、それぞれ、プラント１０内のコンピュータおよび／またはデバイスにアプリケーション３８を連結させるための種々の他の方法が使用できることを認識するであろう。一般に、アプリケーション３８は、収集されたデータをデータベース４３に格納してもよい。

統計データ（または処理可変データ）が一旦収集されると、目視（ビューイング）アプリケーション４０は、データを処理するため、および／または、さまざまな方法で、（例えば、データベース４３に格納されているような）収集または処理された統計データを表示するために使用されてもよく、これによって、メンテナンス担当者などのユーザが、異常事態の有無または予測される今後の異常事態の有無を判断したり、先取りして補正動作を取ったりすることがより容易にできるようにする。ルールエンジン開発および実行アプリケーション４２は、処理プラント１０内の異常事態の有無を判断したり、将来的な異常事態を予測したりすべく、収集されたデータを解析するために、該アプリケーション４２に格納されている一つ以上のルールを使用してもよい。更に、これらのルールエンジン開発および実行アプリケーション４２は、オペレータまたは他のユーザが異常事態を検出または予測するためにルールエンジンによってインプリメントされる更なるルールを作成することを可能とする。

図２は、統計データ収集が異常事態防止システム３５によって実行され得る一つの方法を記載するために、図１に例示された処理プラント１０の部分５０を示す。図２は、異常事態防止システムアプリケーション３８、４０、４２、およびデータベース４３とＨａｒｔおよび、Ｆｉｅｌｄｂｕｓフィールドデバイス内の一つ以上のデータ収集ブロックの間の通信を示すが、異常事態防止システムアプリケーション３８、４０、および４２と図１に示されるデバイスおよび装置のいずれかを含む処理プラント１０内の他のデバイスおよび装置の間に同様の通信が発生し得ることが理解されよう。

図２に示される処理プラント１０の部分５０は、任意の所望される通信やコントローラプロトコルに従う任意の所望されるタイプのＩ／Ｏ（入出力）デバイスであってもよい、Ｉ／Ｏカードまたはデバイス６８および７０を介して、一つ以上のフィールドデバイス６４および６６に接続される一つ以上の処理コントローラ６０を有する、分散処理コントロールシステム５４を含む。フィールドデバイス６４は、任意の他の所望される通信プロトコルをも使用することができるが、該フィールドデバイス６４は、ＨＡＲＴフィールドデバイスとして示され、フィールドデバイス６６は、Ｆｉｅｌｄｂｕｓフィールドデバイスとして示される。更に、フィールドデバイス６４および６６は、例えば、センサ、バルブ、トランスミッタ、ポジショナなどの任意のタイプのデバイスであり得て、また、これらのフィールドデバイスは、任意の所望されるオープンな、プロプラエタリな他の通信またはプログラミングプロトコルに追従し得て、Ｉ／Ｏデバイス６８および７０が、フィールドデバイス６４および６６によって使用される所望のプロトコルと互換性がある必要があることが理解されよう。

いずれにしても、構成エンジニア、処理コントロールオペレータ、メンテナンス担当者、プラントマネジャーなどのプラント関係者によってアクセス可能な一つ以上のユーザインターフェースまたはコンピュータ７２および７４（任意のタイプのパソコン、ワークステーションであってもよい）が、任意の所望されるハードワイヤードまたはワイヤレス通信構造を用いて、および、例えば、イーサネット（登録商標）プロトコルなどの任意の所望されるあるいは好適な通信プロトコルを用いて、インプリメントされ得る通信回線またはバス７６を介して、処理コントローラ６０に接続される。更に、データベース７８は、通信バス７６に接続されて、構成情報だけでなく、処理プラント１０内の処理コントローラ６０およびフィールドデバイス６４および６６に関連する、オンライン処理可変データ、パラメタデータ、状態データ、および他のデータを収集するとともに格納するデータ履歴として動作する。このように、データベース７８は、処理構成モジュールだけでなく、処理コントローラ６０およびフィールドデバイス６４および６６内にダウンロードされ、格納されたときの処理コントロールシステム５４のためのコントロール構成情報を含む、現在の構成を格納するための構成データベースとして動作する。同様に、データベース７８は、処理プラント１０内のフィールド６４および６６によって収集された統計データまたはフィールドデバイス６４および６６によって収集された処理変数から求められた統計データを含む、経過的な異常事態防止データを格納することができる。

処理コントローラ６０、Ｉ／Ｏデバイス６８および７０、フィールドデバイス６４および６６は、一般に、時には過酷なプラント環境下に配置され、この環境を介して分配されるが、ワークステーション７２および７４とデータベース７８は、オペレータやメンテナンス担当者などがアクセスしやすい、コントロールルーム、メンテナンスルームまたは他のあまり厳しくない環境に配置される。

概して、処理コントローラ６０は、多数の異なる、個別に実行されるコントロールモジュールまたはブロックを用いて、コントロール戦略を実行する一つ以上のコントローラアプリケーションを格納すると共に実行する。コントロールモジュールは、それぞれ、一般に、機能ブロックと呼ばれるものから構成され得る。ここで、各機能ブロックは、全体的なコントロールルーチンの一部またはサブルーチンであり、処理プラント１０内で処理コントロールループをインプリメントするために他の機能ブロックと組み合わされて（リンクと呼ばれる通信を介して）動作する。周知のように、オブジェクト指向プログラミングプロトコル内のオブジェクトであってもよい機能ブロックは、一般に、処理プラント１０内でいくつかの物理的機能を実行するために、トランスミッタ、センサ、または他の処理パラメタ測定デバイスに関連する機能などの入力機能と、ＰＩＤ、ファジー論理などのコントロールを実行するコントロールルーチンに関連する機能などのコントロール機能と、または、バルブなどのいくつかのデバイスの動作をコントロールする出力機能とのうちの一つを実行する。当然、モデル予測コントローラ（ＭＰＣ：ｍｏｄｅｌ ｐｒｅｄｉｃｔｉｖｅ ｃｏｎｔｒｏｌｌｅｒｓ）、オプティマイザなどのハイブリッドおよび他のタイプの複雑な機能ブロックも存在する。ＦｉｅｌｄｂｕｓプロトコルおよびＤｅｌｔａＶ^TM（登録商標）システムプロトコルは、オブジェクト指向プログラミングプロトコルにおいて設計されインプリメントされるコントロールモジュールおよび機能ブロックを使用する一方、該コントロールモジュールは、例えば、逐次機能ブロック、ラダー論理などを含む任意の所望されるコントロールプログラミング技術を用いて設計され得ることが理解されよう。但し、該コントロールモジュールは、機能ブロックや任意の他の特定のプログラミング技術を用いての設計に限定されない。

図２に示されているように、メンテナンスワークステーション７４は、プロセッサ７４Ａ、メモリ７４Ｂ、およびディスプレイデバイス７４Ｃ を含む。メモリ７４Ｂは、ディスプレイ７４Ｃ （またはプリンタなどの任意の他のディスプレイデバイス）を介して、ユーザに情報を提供すべく、プロセッサ７４Ａ上でアプリケーションがインプリメントされ得るように、図１で説明された異常事態防止アプリケーション３８、４０、および４２を格納する。

更に、図２に示されるように、フィールドデバイス６４および６６のいくつか（潜在的には全て）は、データ収集および処理ブロック８０および８２を含む。一方、図２に関しては、ブロック８０および８２が、本説明を行うために、Ｆｉｅｌｄｂｕｓ デバイス内の統計データを収集し処理するためのＦｉｅｌｄｂｕｓデバイスに追加され得るＦｉｅｌｄｂｕｓデバイス内で統計データを収集し処理する、公知のＦｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓ機能ブロックである、高度診断ブロック（ＡＤＢ）として、説明されているが、該処理ブロック８０および８２は、これらのブロックが、Ｆｉｅｌｄｂｕｓデバイス内に配置されていようがいまいが、あるいは、Ｆｉｅｌｄｂｕｓプロトコルに追従していようがいまいが、デバイスデータを収集し、該データに対する一つ以上の統計測定値またはパラメタを計算したり決定したりする、処理デバイス内に配置される任意の他のタイプのブロックやモジュールであってもよいし、あるいは、これらを含んでいてもよい。図２のブロック８０および８２は、デバイス６４の一つとデバイス６６の一つに配置されているものとして示されているが、これらのブロックあるいは同様のブロックは、任意数のフィールドデバイス６４および６６に配置されてもよいし、コントローラ６０、Ｉ／Ｏデバイス６８および７０、または図１に示されるいずれかのデバイスなどの他のデバイス内に配置され得る。更に、該ブロック８０および８２は、フィールドデバイス６４および６６の任意のサブセット内にあってもよい。

概して、ブロック８０および８２、またはこれらのブロックのサブエレメントは、それらが配置され、なんらかの理由があってデータ上で統計処理または解析を実行するデバイス内で処理可変データなどのデータを収集する。例えば、バルブと関連しているものとして示される、ブロック８０は、該バルブがスタック（膠着）状態にあるかを判断するためにバルブ処理可変データを解析するスタックバルブ検出ルーチンを有し得る。更に、ブロック８０は、例えば、収集されたデータの平均値、メジアン値、標準偏差値、平方根（ＲＭＳ）、変化の割合、範囲値、最小値、最大値などを求めるため、および／または、収集したデータにおいてドリフト（浮漂）、バイアス（偏り）、ノイズ（雑音）、スパイク（過電圧）などの事象を検出するため、バルブ内の処理可変または他のデータを収集し、該収集されたデータ上で一つ以上の統計的計算を実行し得る四つの統計処理モニタ（ＳＰＭ）ブロックまたはユニットＳＰＭ１〜ＳＰＭ４のセットを含む。生成された特定の統計データもそれが生成される方法もあまり重要ではない。このように、上述された特定のタイプの統計データ以外にそれに代わる異なるタイプの統計データが生成され得る。更に、公知の技術を含む種々の技術が、このようなデータを生成するために使用され得る。本明細書中では、少なくとも一つの処理変数または他の処理パラメタ上で統計処理モニタを実行する機能性を説明するために、用語「統計処理モニタ（ＳＰＭ）」ブロックが用いられ、該デバイス内またはデータが収集されるデバイス以外において任意の所望されるソフトウェア、ファームウェア、またはハードウェアによって実行され得る。一般に、ＳＰＭは、デバイスデータが収集されるデバイス内に配置されるので、ＳＰＭが量的に勝り、質的により正確な処理可変データを取得できることが理解されよう。これによって、一般に、ＳＰＭブロックは、処理可変データが収集されるデバイス以外に配置されたブロックより、収集された処理可変データに関してより良好な統計計算を求めることが可能である。

他の例としては、トランスミッタと関連するものとして示されている図２のブロック８２は、プラント内のラインが閉塞されたかを判断するために、該トランスミッタによって収集される処理可変データを解析する閉塞ライン検出ユニットを有することもある。更に、ブロック８２は、例えば、収集されたデータの平均値、メジアン値、標準偏差値などを求めるために、該トランスミッタ内の処理可変データまたは他のデータを収集し、該収集されたデータ上で一つ以上の統計的計算を実行し得る四つの統計処理モニタ（ＳＰＭ）ブロックまたはユニットＳＰＭ１〜ＳＰＭ４のセットを含む。所望されれば、上記に参照されている米国特許第6,017,143号に記載されているように、ブロック８０および８２の基底動作が実行またはインプリメントされてもよい。ブロック８０および８２は、４つのＳＰＭをそれぞれ含むように示されているが、ブロック８０および８２は、統計データを収集するとともに求めるために、他の任意数のＳＰＭブロックを有することもできる。同様に、ブロック８０および８２がプラント１０ 内で特定の状態を検出するための検出ソフトウェアを含むとして図示されているが、このような検出ソフトウェアは有する必要はない。更にまた、本明細書中に説明されているＳＰＭブロックがＡＤＢのサブエレメントであるとして図示されているが、そうではなく、デバイス内に配置されるスタンドアローンブロックであってもよい。また更に、本明細書中で説明されているＳＰＭブロックは、公知のＦｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓ ＳＰＭブロックであってもよいが、本明細書中では、用語「統計処理モニタ（ＳＰＭ）ブロック」は、処理可変データなどのデータを収集し、平均値、標準偏差値などの統計的測定値を求めるために該データ上でいくつかの統計的処理を実行する、任意のタイプのブロックまたはエレメントを言及するために用いられる。これによって、この用語は、これらのエレメントが、機能ブロックや他のタイプのブロック、プログラム、ルーチンまたはエレメントの形態を取っていようといまいと、および、これらのエレメントが、Ｆｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓプロトコル、または、ＰＲＯＦＩＢＵＳ、ＷＯＲＬＤＦＩＰ、Ｄｅｖｉｃｅ−ネットワーク、ＡＳ−Ｉｎｔｅｒｆａｃｅ、ＨＡＲＴ、ＣＡＮなどの他のプロトコルに追従していようがいまいが、この機能を実行するソフトウェア、ファームウェアまたは他のエレメントを網羅するように意図されている。

一つの実施の形態において、ＡＤＢ８０および８２内の各ＳＰＭブロックは、稼動中であってもよいし、休止中であってもよい。稼動中ＳＰＭブロックは、処理変数（または他の処理パラメタ）を現在モニタしているブロックであるが、休止中ＳＰＭブロックは、処理変数を現在モニタしていないブロックである。概して、ＳＰＭブロックは、デフォルト値によって休止中となり、これにより、一般に、各ＳＰＭブロックが、処理変数をモニタするためには個別に構成されなければならない。図３は、デバイスに対する現在ＳＰＭ構成を記述し変更するために、ユーザ、エンジニアなどに提示され得る、例示的な構成ディスプレイ８４を示す。ディスプレイ８４において示されるように、この特定のデバイスのためのＳＰＭブロック１、２および３の全てが構成されているが、ＳＰＭブロック４は、構成されなかった。構成されたＳＰＭブロックＳＰＭｌ、ＳＰＭ２およびＳＰＭ３の各々は、（ブロックタグ（Ｂｌｏｃｋ Ｔａｇ）によって示されるような）デバイス内の特定のブロック、ブロックタイプ（Ｂｌｏｃｋ Ｔｙｐｅ）、ブロック内のパラメタインデックス（Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘ）（即ち、モニタされているパラメタ）、および該ＳＰＭブロックのモニタ機能性を示すユーザコマンド（Ｕｓｅｒ Ｃｏｍｍａｎｄ）に関連している。また更に、各構成されたＳＰＭブロックは、決定された統計パラメタが比較される一組の閾値を含み、これらの閾値は、例えば、平均限界値、（信号において過多の変動値を指定する）高変動限界値、および（信号における過少の変動値を指定する）低ダイナミック値を含む。本来、平均値における変化を検出することは、処理が上下にドリフトしていることを示し、高い変動値を検出することは処理内のエレメントが（大きくなった振動によって生じるノイズなどの）予期しなかったノイズを経験していることを意味し、低い変動を検出することは、処理信号がフィルタリングされつつあること、または、エレメントが、例えば、スタックバルブなどのように予期せぬうちに休止することを意味する。また更に、平均値および標準偏差値などのベースライン値がＳＰＭブロックごとに設定されてもよい。これらのベースライン値は、デバイス内で限界値を満たしているかあるいは超えているかを判断するために使用され得る。モニタリングを開始するためにユーザコマンドを受信したことから、図３のＳＰＭブロック１および３はともに稼動中である。一方、ＳＰＭブロック２は、アイドル（Ｉｄｌｅ）状態にあるので、休止中である。また、この例において、ＳＰＭ能力はボックス８６によって示されるように、デバイス全体に対してイネーブルであり、ボックス８８によって示されるように、５分毎にモニタまたは計算されるように設定される。当然、許可されたユーザは、デバイス内の他の機能ブロックなどの他のブロック、該デバイス内の様々なブロックに関連する他のパラメタをモニタするためだけでなく、他の閾値、ベースライン値などを有するために、該デバイス内のＳＰＭブロックを再構成することができる。

図３のディスプレイ８４には、いくつかの統計的モニタブロックが示されているが、他のパラメタも同様に、または、他のパラメタも加えて、モニタされてもよい。例えば、図２に関して説明されるＳＰＭブロックまたはＡＤＢは、処理に関連する統計パラメタを計算し、これらの値における変化に基づいて、いくつかの警告を引き出す場合もある。例えば、ＦｉｅｌｄｂｕｓタイプのＳＰＭブロックは、処理変数をモニタし、そのモニタリングに関連する１５の異なるパラメタを提供し得る。これらのパラメタは、ブロックタグ、ブロックタイプ、平均値（Ｍｅａｎ）、標準偏差値（Ｓｔａｎｄａｒｄ Ｄｅｖｉａｔｉｏｎ）、平均変化値（Ｍｅａｎ Ｃｈａｎｇｅ）、標準偏差変化値（Ｓｔａｎｄａｒｄ Ｄｅｖｉａｔｉｏｎ Ｃｈａｎｇｅ）、ベースライン平均値（Ｂａｓｅｌｉｎｅ Ｍｅａｎ）、ベースライン標準偏差値（Ｂａｓｅｌｉｎｅ Ｓｔａｎｄａｒｄ Ｄｅｖｉａｔｉｏｎ）、高変動限界値（Ｈｉｇｈ Ｖａｒｉａｔｉｏｎ Ｌｉｍｉｔ）、低ダイナミック限界値（Ｌｏｗ Ｄｙｎａｍｉｃｓ Ｌｉｍｉｔ）、平均限界値（Ｍｅａｎ Ｌｉｍｉｔ）、 状態値（Ｓｔａｔｕｓ）、パラメタインデックス、タイムスタンプ（Ｔｉｍｅ Ｓｔａｍｐ）、およびユーザコマンドなどを含む。現在、二つの最も有用なパラメタは、平均値と標準偏差値であると考えられる。しかしながら、しばしば有用である他のＳＰＭパラメタは、ベースライン平均値、ベースライン標準偏差値、平均変化値、標準偏差値、および状態値である。もちろん、ＳＰＭブロックは、任意の他の所望される統計測定値やパラメタを決定することができるとともに、特定のブロックに関連する他のパラメタをユーザまたは要求アプリケーションへ提供することができる。このように、ＳＰＭブロックは本明細書中において説明されているブロックに限定されない。

再び図２を参照すると、フィールドデバイス内のＳＰＭブロック（ＳＰＭ１乃至ＳＰＭ４）のパラメタは、バスまたは通信ネットワーク７６およびコントローラ６０を介して、例えば、ワークステーション７４に対しての外部クライアントにとって利用可能とされ得る。その以外またはそれに代わるものとして、ＡＤＢ８０および８２内のＳＰＭブロック（ＳＰＭ１乃至ＳＰＭ４）によって収集されあるいは生成されるパラメタや他の情報は、例えば、ＯＰＣサーバ８９を介して、ワークステーション７４にとって利用可能とされ得る。この接続は、（一つ以上の携帯デバイスなどの）ワイヤレス接続、ハードワイヤード接続、断続接続、または、任意の所望されるあるいは適切な通信プロトコルを用いた任意の所望される通信接続でもあってもよい。当然、本明細書中に記載されている通信接続のいずれかは、共通または一定のフォーマットにおいて、異なるタイプのデバイスから受信されたデータを統合するために、ＯＰＣ通信サーバを使用してもよい。

また更に、生の処理可変データなどの生データを収集または生成するデバイス以外で、統計処理モニタを実行するために、ホストデバイス、フィールドデバイス以外のデバイス、または、他のフィールドデバイス内に、ＳＰＭブロックを配置することが可能である。このように、例えば、図２のアプリケーション３８は、例えば、ＯＰＣサーバ８９を介して、生の処理可変データを収集するとともにその処理可変データについての平均値、標準偏差値などのいくつかの統計測定値またはパラメタを計算する一つ以上のＳＰＭブロックを含み得る。これらのＳＰＭブロックは、一般に、該データを収集するデバイス内に配置されていないため、これにより、該データに対する通信要件に応じた統計的計算を実行するために十分な処理可変データを収集することが一般には不可能であるが、該ＳＰＭブロックは、デバイスに対する統計パラメタを決定する際、または、ＳＰＭ機能もなく支援もしないデバイス内では処理変数を決定する際に、有用である。更に、技術が進歩するにつれて、経時的に、ネットワークの使用可能な処理量（スループット）が増加し、生データを収集するデバイス内に配置されてなかったＳＰＭブロックは、統計的計算を実行するためにより多くの処理可変データを収集することが可能である。このように、ＳＰＭブロックによって生成されると記載された任意の統計的測定値またはパラメタが、ＡＤＢ８０および８２内のＳＰＭ１乃至ＳＰＭ４ブロックなどのＳＰＭブロックによって、または、他のフィールドデバイスを含むホストまたは他のデバイス内のＳＰＭブロックにおいて、生成され得ることが以下の記載において理解されよう。

処理プラントにおいて統計データ収集ブロックまたはＳＰＭの数が大きくなるので、データをトレンド（傾向付け）し更なるデータ凝集および意思決定のためのエキスパート（専門家）システムへ検出結果を提供するためには、異なるデバイス内のＳＰＭブロックから統計パラメタデータを集める自動機構を有することが役に立つ。実際、現時点では、大規模な処理に対して統計処理データの全てを目視することは非常に面倒であり、冗長である。今のところ、関心がもたれるＳＰＭパラメタの各々を個別にモニタするＯＰＣクライアントを作成しなければならず、これを行うためには、ＳＰＭ収集に用いられる全てのデバイスを個別に構成しなければならない。上記のように、統計データのこの構成および目視は、非常に手間がかかり、人的エラーが発生しやすくなる。

該構成およびデータ収集アプリケーション３８は、例えば、バルブ、トランスミッタなどのデバイスにおいてＳＰＭブロックを自動的に構成するように、および、処理の動作中に該処理が使用できるＳＰＭデータをこれらのＳＰＭブロックから収集するように、用いられる。図４は、ＳＰＭデータを収集するために処理プラント内でデバイスを構成し、該処理プラント１０の動作中にデータを自動的に収集するためにアプリケーション３８によって使用され得る例示的な技術を記述するフローチャート９０を示す。図４において、円は、アプリケーション３８によって処理プラントにおいて実行されるアクションを示すが、四角形は、該アプリケーション３８によって使用されるか、または、生成される、オブジェクトやアイテムを示す。この例は、Ｆｉｅｌｄｂｕｓプロトコルを使用するとともに統計データを収集するＦｉｅｌｄｂｕｓブロックを有する、特定のタイプのトランスミッタからのＳＰＭデータの収集について説明するが、この技術または同様の技術が、他の通信および機能ブロックプロトコルを用いた他のデバイスから、あるいは、機能ブロックプログラミングパラダイム以外のプログラミングパラダイムを使用するデバイス内の他のデバイスまたはエレメントから、統計データ（または他のパラメタ）を収集するために使用され得ることが理解されよう。

いずれにしても、第１のブロック９２において、アプリケーション３８は、（ＡＤＢなどの）統計データ収集ブロックを含む処理プラント内でデバイスのリストを決定するために処理コントロールネットワーク（例えば、処理プラント）の階層をスキャンする。ブロック９２は、他のタイプの統計データ収集ブロックを検索してもよいし、ＡＤＢ内のＦｉｅｌｄｂｕｓタイプのＳＰＭに加えて、該他のタイプの統計データ収集ブロックを検索してもよいし、また、方法は、Ｆｉｅｌｄｂｕｓ ＡＤＢによる使用に限定されないし、Ｆｉｅｌｄｂｕｓ ＡＤＢ内のＳＰＭブロックにも限定されないのであるが、説明の便宜上、上記のように、統計データ収集ブロックは、Ｆｉｅｌｄｂｕｓ ＡＤＢ内のＳＰＭブロックの形態を取るものと仮定されている。一つの実施の形態において、（図２のサーバ８９などの）ＯＰＣサーバは、アプリケーション３８などのクライアントがコントロールおよびデバイス情報にアクセスできるようにするために使用され得る。例えば、ＯＰＣオートメーション２．０プロダクトは、ＯＰＣサーバのコンテンツをブラウジングするために標準的な方法を提供し、ほとんどのブラウザ方法が、ＯＰＣ階層を自動的に走査して、ＡＤＢを含むデバイスを見つけるために使用され得る。更に、新しいＯＰＣスペックは、データを統合するとともに該データをウェブ環境で使用できるようにするために使用され得るＸＭＬ定義を含む。

図５は、ＯＰＣサーバによって作成される例示的なプラント階層９４の一部を示し、該ＯＰＣサーバによってスキャンされている処理プラントのデバイスおよび他のエレメントを示す。階層９４の最上層は、モジュール（Ｍｏｄｕｌｅｓ）およびＩＯと呼ばれるノード９６および９８をそれぞれ含み、モジュールノード９６はコントロール戦略情報を含み、ＩＯノード９８はハードウェアおよび／またはデバイス情報を含む。図５の例示的な階層に示されるように、ＩＯノード９８は、コントローラ（ＣＴＬＲ）、カード（Ｃ）およびポート（Ｐ）に関連するサブノードを含み、この例において、ポート（Ｐ）は、コントローラネットワークに実際に存在するＦｉｅｌｄｂｕｓセグメントに関連している。さらに、階層の更に下方では、Ｆｉｅｌｄｂｕｓデバイスがそれぞれのポートの下に列挙されている。図５の例において、ＡＤＢを含む各Ｆｉｅｌｄｂｕｓデバイスは、デバイスの下のＴＲＡＮＳＤＵＣＥＲ（トランスデューサ）８００またはＴＲＡＮＳＤＵＣＥＲ１３００という名のノードを含む。（Ｒｏｓｅｍｏｕｎｔ （ローズマウント）３０５１ＦデバイスにおいてＡＤＢはＴＲＡＮＳＤＵＣＥＲ８００と称されるが、Ｒｏｓｅｍｏｕｎｔ３０５１ＳにおいてＡＤＢはＴＲＡＮＳＤＵＣＥＲ１３００と称される）。図５の階層には、このようなＴＲＡＮＳＤＵＣＥＲ８００と称されるノード１００が示されている。ＡＤＢノード１００は、関心が持たれる診断情報を含む。この特定の場合において、アプリケーション３８は、Ｒｏｓｅｍｏｕｎｔ３０５１ＦデバイスにおいてＡＤＢに関連するエレメントのいくつかを示すために、図５の階層において拡張された、ＡＤＢノード１００内の統計処理モニタ（ＳＰＭ）パラメタに関心を持つ。当然、名称「ＴＲＡＮＳＤＵＣＥＲ８００」および「ＴＲＡＮＳＤＵＣＥＲ１３００」は、ある知られている製造業者によって提供される公知の機能ブロックの名称の単純な例である。他のＡＤＢブロックまたはＳＰＭブロックは、他の名称を有してもよいし、および／または、名称は、ＯＰＣを利用するシステム以外のシステムにおいて異なり得る。他のインプリメンテーション（実装）において、さまざまな名称は、二、三、例を挙げると、今後開発される、および／または、他の製造者によって製造される、および／または、Ｆｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓスペックに記載されているような他のＴＲＡＮＳＤＵＣＥＲブロックのＡＤＢブロックまたはＳＰＭブロック、機能ブロックなどに対応する名称であってもよいし、Ｐｒｏｆｉｂｕｓ、ＨＡＲＴ、ＣＡＮ、ＡＳ−Ｉｎｔｅｒｆａｃｅ、ＨＴＭＬ、ＸＭＬなどのプロトコルにおける任意のエレメントなどの任意の他のスマート通信プロトコル（例えば、ディジタルプロトコル）におけるブロックまたは他のソフトウェアエレメントであってもよい。

ＡＤＢ、従って、該ＡＤＢ内のＳＰＭブロックを発見するために、ブロック９２（図４）は、プラント内の全てのＡＤＢを含むデバイスを探すためにＯＰＣ階層９４を自動的に走査または検索する。当然、ブロック９２は、該ブロック９２がＡＤＢを含むデバイスを最良の方法で見つけるために予めプログラミングされ得る。本明細書中に記載の方法は、ＤＥＬＴＡ Ｖ^TM ＯＰＣツリーに基づいているが、該方法の改良は、他のＯＰＣサービスだけでなく、他のタイプの目視ツールによって生成されるプラント階層に対して行われてもよい。

階層またはツリー９４を検索するとき、一般に、スピードと堅牢性（ロバストネス）の間にトレード−オフ（二律背反）がある。特に、階層９４を検索することが、一般に、ＡＤＢを有するデバイスの全てを見つける時にもＡＤＢを有するデバイスのみを見つける時にも１００％信頼できる方法ではない。一般に、ＡＤＢを有するデバイスを見つける方法が正確であればあるほど、該方法の進行が遅くなる。例えば、別の製造者が、３０５１Ｆトランスミッタ内のＡＤＢブロックと同じ名称を有するブロックを含むＯＰＣツリー９４に出現するデバイスを有すれば、該階層を検索することは、このデバイスを、ＡＤＢを有するものとして、偽に検出することになる。逆に、ブロック９２が、実際のＡＤＢを含むノードだけを探し出すことを確実にするために、過剰な量のサブノートを検索してこの問題を回避しようとすれば、該方法の速度は低下する。

いずれにしろ、一つの実施の形態において、ブロック９２は、いくつかのデバイスにおいてＡＤＢと関連すると分かっている名称を有する各ノードを探し出すために、階層またはツリー９４内のすべてのノードを検出し得る。大規模な処理プラントにおけるような場合においては、かなり長い検索時間が掛かるが、処理プラントにおいて、ＡＤＢの各々、従って、ＳＰＭの各々を探し出すためには、これが、最も正確な方法である。一方、ＴＲＡＮＳＤＵＣＥＲ８００またはＴＲＡＮＳＤＵＣＥＲ１３００などの公知の統計モニタブロックに関連する名称、あるいは、公知の統計モニタブロックを表示するためにいくつかのデバイスの製造者によって使用されることが分かっている任意の他の特定の名称を含むノードに到達するかあるいは該ノードを見つけるまで、ブロック９２は、階層の下層へと検索し得る。このようなノードが見つかった場合、次に、該ノードに関連付けられる親ノードが、ＡＤＢを有するデバイスとして検出され得る。該方法は、特定のＯＰＣ階層またはツリー内の全てのノードを検出するほど堅牢ではないが、処理は速い。とはいっても、他の製造者が、ＴＲＡＮＳＤＵＣＥＲ８００と名付けられたＯＰＣノードを有するデバイスを作製する場合、この方法でも、ＡＤＢを有するものとして他のデバイスを偽に検出する。

あるいは、ブロック９２は、ＡＤＢと一意的に関連付けられ、または、ＡＤＢを表していることが分かっているデバイス内で更なるアイテムに対して、知られているＡＤＢに関連する名称を有することを該ブロック９２が発見する各ノード下で検索し得る。このように、ＡＤＢを特定するために少なくとも一つの製造者によって使用されることが分かっている名称を有するノードを探し出した後、ブロック９２は、アイテム「Ｃｈａｒａｃｔｅｒｉｓｔｉｃ／ＢＬＯＣＫ ＴＡＧ．ＳＴＲＩＮＧ（特徴／ブロックタグ．ストリング」が、値「ＡＤＶＡＮＣＥＤ ＤＩＡＧＮＯＳＴＩＣＳ（高度診断）」を有するかを判断するためにサブノードを検出する。この例において、「Ｃｈａｒａｃｔｅｒｉｓｔｉｃ／ＢＬＯＣＫ ＴＡＧ．ＳＴＲＩＮＧ」アイテムは、ＡＤＢを有するデバイスに対してのみ、「ＡＤＶＡＮＣＥＤ ＤＩＡＧＮＯＳＴＩＣＳ」の値を有する。この方法は、ＡＤＢを有するデバイスのみを探し出す際に非常に堅牢であるが、ＯＰＣサーバを介してデバイスから値を読み出すことを必要とするので、ＯＰＣ階層をブラウジングするより相当に長い時間を要する。従って、この方法は、正確ではあるが、いくつかの状況に対しては非常に低速である。

速度とロバストネスの間でミドルグラウンド（中間位置）を提供するＯＰＣツリー９４を検索するために、図４のブロック９２によってインプリメントされ得る他の方法は、ＡＤＢに共通して関連する名称を有するサブノードに対して、ＡＤＢに関連することが共通して分かっている名称を有するノード下で、ＯＰＣ階層を検索することを含む。例えば、この方法は、ＯＰＣツリー９４（図５）のトップからスタートし、ＩＯノード９８を検索し得る。次に、方法は、ＩＯノード９８下で全てのサブノードを再帰的に検索し得る。ＴＲＡＮＳＤＵＣＥＲ８００またはＴＲＡＮＳＤＵＣＥＲ１３００と名付けられたサブノード（またはＡＤＢなどの統計モニタブロックに関連付けられることが分かっているいくつかの他の名称）が見つかった場合、次に、該方法は、このノードが、ＳＰＭ ＡＣＴＩＶＥ（アクティブ）と名づけられたサブノードまたは具体的に統計モニタブロックと関連する任意の他のサブノードを有するか否かをチェックする。例えば、ＴＲＡＮＳＤＵＣＥＲ８００ノード下でＳＰＭ ＡＣＴＩＶＥが見つけられた場合、次に、ブロック９２は、ＴＲＡＮＳＤＵＣＥＲ８００ノードの親ノードを、ＡＤＢを含むデバイスとして、検出する。

当然のことながら、ブロック９２は、ＡＤＢを有する（従って、ＳＰＭを有する）デバイスを検索するために、これらの技術のいずれか、これらの技術の任意の組合せ、または任意の他の所望される技術を使用することができる。例えば、一つのインプリメンテーションは、少なくとも一つの製造者のデバイスによってインプリメントされると分かっている少なくとも全てのＡＤＢを識別しようとするが、処理プラント内の全てのＡＤＢを識別することが可能である場合もあれば、不可能な場合もある。他の例としては、いくつかの異なる製造者のデバイスによってインプリメントされることが分かっている全てのＡＤＢを識別しようとする試みもある。更に、このスキャンステップは、ＯＰＣ階層を用いて実行されるものとして、即ち、ＯＰＣサーバによって生成されるものとして、記載されているが、この方法は、コントローラ、処理プラント内で構成階層を格納するデータ履歴、デバイス階層を格納するワークステーションなどの他のデバイスによって生成される階層上で用いたり、使用されたりする。このように、他のインプリメンテーションは、ＯＰＣサーバおよび／またはＯＰＣ階層を使用する必要はないが、公知の、または、今後開発される、コンピュータデバイス、通信プロトコル、および階層プロトコルを含む、多種多様の他のコンピュータデバイス、通信プロトコル、および階層プロトコルを使用することもできる。他のインプリメンテーションは、例えば、ウェブサーバ、ＸＭＬ、および／または、プロプラエタリ演算装置、およびプロトコルを使用し得る。

ＡＤＢを含むデバイスを探し出したり検索したりする処理において、ブロック９２は、図４のボックス１０８によって示されるように、ＡＤＢ、ＳＰＭブロック、または他のタイプのデータ収集ブロックを有するものとして、検出されたデバイスのリストを格納してもよい。所望されれば、ボックス１０８に挙げられているデバイスがそれらの階層に応じたツリービューディスプレイで表示されてもよい。このような階層的なディスプレイ１１０の例は、図６に示されている。お分かりのように、図６のビューにおいて表示された階層１１０は、コントロールディスプレイ内の全てのデバイスが一般にＡＤＢを含むとは限らないが、コントローラによって生成されるコントロールネットワークディスプレイ下で表示される階層のサブセットである。事実、図６のビュー１１０は、ＡＤＢを含むデバイスのみを含むコントローラ階層を実際にコピーしたものである。お分かりのように、図６のディスプレイは、（ＣＴＬＲ−００２ＥＣ６と名付けられたコントローラの入力／出力デバイスＩＯ１のカードＣＯｌのポートＰＯｌに接続された）デバイスＰＴ−１０１およびＰＴ−１０２と、（ＣＴＬＲ−００２ＥＣ６と名付けられたコントローラの入力／出力デバイスＩＯ１のカードＣ０１のポートＰ０２に接続された）デバイスＰＴ−１０３、ＦＴ−２０１およびＦＴ−２０２がそれぞれＡＤＢを有することを示す。

デバイスからＳＰＭパラメタのいずれかを読み出すため、このパラメタのＯＰＣアイテムＩＤを知ることが一般的に必要とされる。一般的には、即ち、Ｆｉｅｌｄｂｕｓ ＳＰＭブロックの場合、ＳＰＭパラメタに対するＯＰＣアイテムのＩＤは、アイテム指定子が続くＤｅｖｉｃｅ（デバイス）ＩＤを含む。ＤｅｖｉｃｅＩＤを探し出すために、ＡＤＢを含むと判断されたデバイスノードごとに、サブノードＳＰＭ ＡＣＴＩＶＥを見つけることもある。次に、ブロック９２は、リーフ（葉）「ＣＶ」に対してＯＰＣアイテムＩＤを得ることもある。例えば、ＯＰＣアイテムＩＤは、「DEVICE:0011513051022201100534-030003969/800/SPM ACTIVE.CV.」である。次に、ＤｅｖｉｃｅＩＤは、ＯＰＣアイテムＩＤからサフィックス（接尾部）“ＳＰＭ ＡＣＴＩＶＥ．ＣＶ”を引いたものである。従って、この例では、「DEVICE:0011513051022201100534-030003969/800/」である。当然ながら、これは、ＯＰＣシステムにおいてＤｅｖｉｃｅＩＤを決定する一つの方法にすぎず、他の技術を代わりに使ってもよい。

いずれにせよ、ブロック９２がＡＤＢを有するデバイスを決定するために階層をスキャンした後、アプリケーション３８は、これらのデバイスの各々に対して、Ｄｅｖｉｃｅ Ｔａｇ（デバイスタグ）、Ｄｅｖｉｃｅ ＩＤ、Ｄｅｖｉｃｅ Ｌｏｃａｔｉｏｎ（デバイス位置）を知っているし、または、容易に決定することができる。ＡＤＢを有する五つのデバイスを含む単純なシステムに対するこのデータの例が以下の表に示されている。

再び図４を参照すると、ブロック１１４は、ボックス１０８に格納されたデバイスのどのデバイスが統計処理モニタを実行するようにすでに構成されているかを判断し得る。この機能を実行するために、ブロック１１４は、該ボックス１０８に格納されたデバイスの各々に対してＯＰＣサーバから、値ＳＰＭ＿ＡＣＴＩＶＥ．ＣＶを読み出してもよい。例えば、上記のテーブル内のトランスミッタＰＴ−１０１については、ブロック１１４が、ＯＰＣアイテムDEVICE:0011513051022201100534-0300O3969/800/SPM ACTIVE.CV.を読み出し得る。このＯＰＣアイテムは、０または２５５の値を取ることもできる。ＦｉｅｌｄｂｕｓＳＰＭブロックの場合、値がゼロの場合、ＳＰＭブロックは、このデバイスに対してディセーブルであり、値が２５５である場合、ＳＰＭブロックは、このブロックに対してイネーブルである。ＳＰＭがデバイスごとにイネーブルであるかをチェックする場合、ブロック１１４は全てのデバイスを二つのカテゴリ、即ち、ＳＰＭがすでに構成されているデバイスとＳＰＭがまだ構成されていないデバイスへ分割することができる。デバイスのこれらのカテゴリまたはリストは、図４のボックス１１６とボックス１１８によって示される。

ブロック１１４が、ＳＰＭがボックス１０８に挙げられたデバイスの各々においてイネーブルであるか否かを決定した後、ブロック１２０は、ＳＰＭがイネーブルであるデバイス、即ち、ボックス１１６に列挙または格納されたデバイスの各々の内部のＳＰＭブロックの各々に対して状態をチェックすることができる。基本的に、ブロック１２０は、ＳＰＭがイネーブルであるデバイス内の各ＳＰＭブロックが現時点で処理変数をモニタするように構成されているか否かを判断し、そうである場合、どの処理変数がモニタされているかを判断するために、このステップを実行する。この例において、ＳＰＭブロックの状態を読み出すことによってＳＰＭブロックが現時点で処理変数をモニタしているか否かを判断することが可能である。ＦｉｅｌｄｂｕｓＳＰＭブロックにおいて、ＯＰＣサーバからのＳＰＭ［ｎ］ＳＴＡＴＵＳ．ＣＶアイテムを読み出すことによって、状態がチェックされ得る。このように、例えば、上の表のデバイスＰＴ−１０１のＳＰＭブロック１に対する状態を読み出すために、ブロック１２０は、ＯＰＣアイテムＩＤ DEVICE:00115130510222011005340300O3969/800/SPM1 STATUS.CV.を読み出してもよい。

概して、状態の値は０から２５５に及ぶ８-ビット数である。この状態は、オンまたはオフされ得る８つの異なるビットの組合せである。これらのビットは、以下の通りであるＩｎａｃｔｉｖｅ（休止）（１）、Ｌｅａｒｎｉｎｇ（学習）（２）、Ｖｅｒｉｆｙｉｎｇ（確認）(４）、Ｎｏ Ｄｅｔｅｃｔｉｏｎｓ（非検出）(８)、Ｍｅａｎ Ｃｈａｎｇｅ（平均変化値）(１６）、Ｈｉｇｈ Ｖａｒｉａｔｉｏｎ（高偏差値）（３２）、Ｌｏｗ Ｄｙｎａｍｉｃｓ（低ダイナミックス）（６４）およびＮｏｔ Ｌｉｃｅｎｓｅｄ（許可されない）（１２８）。許可はされたが、構成されなかった全てのＳＰＭブロックは、休止状態（Ｓｔａｔｅ ｏｆ Ｉｎａｃｔｉｖｅ）にある。ＳＰＭブロックの状態が、休止または無許可である場合、有用な情報を生成していないのでこのブロック１２０がモニタされないと判断してよい。しかしながら、状態（Ｓｔａｔｕｓ）が他の可能性のいずれかである場合、このブロック１２０は、ＳＰＭブロックをモニタし得る。

同様に、ブロック１２２は、ＳＰＭがイネーブルでない各デバイス（即ち、ボックス１１８に挙げられたデバイス）を自動的に構成し、これによって、これらのデバイス内の少なくとも一つのＳＰＭブロックが、処理変数を検出またはモニタすることを可能とし、これによって、その処理変数に対する統計データを作成し得る。Ｒｏｓｅｍｏｕｎｔ３０５１Ｆおよび３０５１Ｓのトランスミッタを用いた場合などのように多くの場合、デバイスは、ＳＰＭがまだ構成されていないプラントから出荷されるため、ユーザは一般に各デバイスにおいてＳＰＭを手動により構成することが要求される。ＡＤＢを有する数百あるいは数千のデバイスを抱えるプラントにおいて、これは非常に冗長な工程である。この手動による構成を緩和するために、デバイスごとに少なくとも一つのＳＰＭブロックを自動的に構成する。この構成を実行するため、ブロック１２２は、デバイス内でモニタされる特定の処理変数の表示を決定するかまたは格納することができる。この変数は、主要処理入力、ＰＩＤブロック出力、または、Ｆｉｅｌｄｂｕｓデバイスにおいて使用可能な任意の数の他の機能ブロック変数（入力または出力）であってもよい。どの変数をモニタされるかについての表示は、構成処理中に設定されてもよいし、状況に応じてユーザによって指定されてもよいし、または、一般的にルーチン３８のオペレーションの前にユーザによって指定されてもよい。

処理変数のいずれもモニタされ得るが、統計目的のためにモニタされる論理変数は、デバイスの主要アナログ入力である。Ｒｏｓｅｍｏｕｎｔ３０５１Ｆおよび３０５１Ｓのトランスミッタの場合、この変数は、測定された圧力または流量（例えば、差圧）である。このように、ブロック１２２は、デバイスの主要アナログ入力または出力をモニタするために、デバイスのＡＤＢにおいてＳＰＭブロックの一つを自動的に構成するために構成されてもよい。所望されれば、デバイスのＳＰＭブロックを手動的に構成することもできる。あるいは、ブロック１２２は、各タイプのデバイスごとにモニタされる処理変数のリストを格納してもよいし、ある状況が与えられた場合に、どの処理変数をモニタするかを選択または決定するためにこのリストを使用することもできる。ブロック１２２は、一つの処理変数をモニタするために、デバイス内で単一のＳＰＭブロックを構成するものとして本明細書中で記載されているが、ブロック１２２は特定のデバイス内で一つ以上のＳＰＭブロックを構成することができ、これによって、このデバイスに関連する一つ以上の処理変数をモニタすることができる。

更に、ＤｅｌｔａＶ ＯＰＣサーバによって、（充分な管理権限を付与された）ユーザは、デバイス内のいくつかのアイテムに値を書き込むことができる。このように、ＯＰＣサーバにおいて適切なアイテムに値を書き込むことによってデバイス内でＳＰＭパラメタを変更することが可能である。これによって、ブロック１２２は、一続きの値をＯＰＣサーバに書き込むことによって主要処理変数に対するＳＰＭをモニタするためにデバイスを自動的に構成し得る。ある具体的な例において、ＯＰＣサーバへ書き込まれた値が以下の表に示される。

ここで、表２で示されているように、[ＤｅｖｉｃｅＩＤ]は、ＤｅｖｉｃｅＩＤに置き換えられる。デバイスＰＴ−１０１については、第１のＯＰＣアイテムへ書き込まれる値は、DEVICE:0011513051022201100534-030003969/800/SPM MONITORING CYCLE.CV．である。これらのアイテムを全てＯＰＣサーバに書き込んだ後、デバイスは、ＳＰＭ１ブロック内の主要圧力変数をモニタするように構成される。言うまでもなく、これは、Ｆｉｅｌｄｂｕｓフィールドデバイス内で特定の種類のＳＰＭブロックへ書き込む一つの例にすぎない。従って、他のタイプのＳＰＭブロックへ書き込む他の方法もそれのほかにまたはそれに替えて使用できることも理解されよう。この場合、書き込みコマンドはこれらのＳＰＭブロックによって使用される通信プロトコルによって決定される。

いずれにせよ、図４のブロック１２０および１２２のオペレーションは、ＡＤＢを有するデバイス内でモニタされるＳＰＭブロックのセットまたはリストを作成する。このリストは、図４のボックス１２４内に格納または関連するものとして、示されている。更に、図４のボックス１２６は、モニタされるＳＰＭブロックの各々についてアプリケーション３８がモニタする一組のＳＰＭパラメタを指定する。ＳＰＭパラメタ１２６のリストは、アプリケーション３８の動作の前またはその最中にユーザによって指定あるいは選択されてもよいし、あるいは、構成処理中にモニタされる異なるＳＰＭブロックに対して個別に選択あるいは指定されてもよい。以下の表は、Ｆｉｅｌｄｂｕｓ ＳＰＭブロックごとにＯＰＣサーバから読み出され得るＳＰＭパラメタの全てを示す。

しかしながら、モニタされているＳＰＭブロック毎にこれらのパラメタの全てをモニタする必要はない。実際、過剰な量のアイテムがモニタされている場合は、ＯＰＣサーバがオーバーロードされる可能性がある。従って、アプリケーション３８はモニタされるＳＰＭパラメタのセットをユーザが選択することが可能である機構を提供し得る。この選択を可能とするスクリーンの例が図７に示され、ユーザは、ボックス１２４によって識別されるＳＰＭブロックの各々に対してユーザがモニタしたいＳＰＭパラメタをチェックすることができる。

ブロック１２８は、該処理の動作中にアプリケーション３８によってモニタされるＳＰＭ ＯＰＣアイテムのセットを構築するため、（ボックス１２６によって識別される）モニタされるＳＰＭパラメタのリストと（ボックス１２４によって識別される）モニタされるＳＰＭブロックのリストを使用する。ブロック１２８は、ボックス１３０によって示されるように、モニタ処理の今後のステップで使用するためにこのＯＰＣアイテムのセットを格納してもよい。概して、ブロック１２８は、（ボックス１２４によって示される）モニタされるＳＰＭブロックごとに、（ボックス１２６によって示される）モニタされるＳＰＭパラメタに対するＳＰＭ ＯＰＣアイテムを作成する。即ち、モニタされる一組のＳＰＭブロックと、このようなブロックごとにモニタされる一組のＳＰＭパラメタが付与されると、ブロック１２８は、モニタされるＳＰＭブロックとモニタされるＳＰＭパラメタの全ての可能性のある組み合わせに対して、ＯＰＣアイテムとしてモニタされる一組のＯＰＣアイテムを構築する。このように、例えば、モニタされる１０個のＳＰＭブロックと、ＳＰＭブロックに対してモニタされる５個のパラメタがある場合、ブロック１２８は、合計５０個のＯＰＣアイテムを作成する。この例において、ＯＰＣアイテムＩＤは、上記の表からのデバイスＩＤとＯＰＣサフィックスとの組み合わせである。例えば、デバイスＰＴ−１０１においてＳＰＭ１のための平均値を読み出すために、ＯＰＣアイテムＩＤは、DEVICE:0011513051022201100534030003969/800/SPM１MEAN.CV.となる。

ＯＰＣアイテムの全てがボックス１３０内で識別され格納された後、ブロック１３２および１３４は、処理の動作中の変化に対してＳＰＭパラメタをモニタする。ＳＰＭパラメタのいくつかは、ＳＰＭブロックの構成に応じて５分乃至６０分おきに変化し得るが、他のＳＰＭパラメタはＳＰＭブロックが構成された時のみ、変化し得る。これによって、ブロック１３２は、ＳＰＭパラメタをモニタする処理が開始された時に（ボックス１３０のＯＰＣアイテムによって指定された）ＳＰＭパラメタの全ての現在値を最初に読み出すこともある。一つの実施の形態において、ブロック１３２は、ＯＰＣアイテムＩＤのそれぞれの読み出しを要求するＳｙｎｃＲｅａｄ機能を用いて、この読み出しを実行し得る。図４のボックス１３６によって示されるように、ＳＰＭパラメタの各々を読み出すことによって一組のＳＰＭデータポイントが生成される。

ＳＰＭパラメタの最初の読み出しの後、ブロック１３４は、ＳＰＭパラメタにおける変化を待機してもよい。即ち、第１のセットのＳＰＭデータポイントを得るためにモニタされているＳＰＭパラメタの各々の初期値がＯＰＣサーバから読み出された後、ブロック１３４は、モニタされているＳＰＭパラメタのいずれかにおける変化を示す更なるデータを受信または取得する。ＳＰＭブロックの構成に応じて、平均値および標準偏差値のパラメタも５分乃至６０分ごとに変化する。にもかかわらず、ＳＰＭパラメタのいずれかが変化するとき、ＯＰＣサーバは、ＤａｔａＣｈａｎｇｅ（データ変更）事象を上昇させ、この事象は、ＯＰＣクライアント、例えば、アプリケーション３８によってキャプチャ（捕捉）される。あるいは、ブロック１３４は、新しいデータポイント（ボックス１３６）を得るためにモニタされているＳＰＭパラメタの各々を周期的または所定時間にポーリングしたり（聞いて回ったり）読み出したりする。このように、ＳＰＭパラメタデータは、たとえ変化しない場合でも読み出される。当然、ブロック１３４は、処理動作中は連続動作することができ、ユーザが目視するために、以下に詳細に記載されているルールエンジンによって使用されるように、または、任意の他の目的のために、新しいＳＰＭパラメタを受け取り、このＳＰＭパラメタデータをデータベース内に格納する。当然、所望されれば、図４のルーチン９０は、ＳＰＭブロックが、異常事態防止システム３５（図１）の他のエレメントへ統計測定値やパラメタを提供することを可能とするために、ＳＰＭブロックやホストデバイス内で他の統計データ収集ブロックを検出し構成することもできる。

実際、ボックス１３６のＳＰＭデータポイントのいずれかが読み出された後は常に、ブロック１３８は、傾向付けや他の目視目的のためにこれらのデータポイントを今後も参照できるように、これらのデータポイントを（図１および図２のデータベース４３などの）ローカルデータベース内に格納あるいは保存することができる。更に、ブロック１４０は、処理プラント内の異常事態を検出あるいは予測するなどの任意の目的のために任意の所望されるまたは有用なフォーマットにおいてＳＰＭデータをユーザへ提供するために、使用され得る。所望されれば、ブロック１４０は、図１および図２に示された目視アプリケーション４０によってインプリメントされ得る。

概して、（図４のブロック１４０によってインプリメントされ得る）目視アプリケーション４０は、例えば、ユーザが一瞥により最新のＳＰＭデータを目視できるように、任意の所望されるまたは有用なフォーマットにおいて、ユーザへＳＰＭパラメタデータを表示することもできる。例えば、目視アプリケーション４０は、従来のエクスプローラタイプのディスプレイを用いてＳＰＭデータを表示してもよい。このようなディスプレイの例は、図８に示されており、図６のエクスプローラ階層１１０がディスプレイスクリーンの左側に設けられ、（図７に示されるスクリーンによって指定されるように）モニタされているＳＰＭパラメタがモニタされているＳＰＭブロックごとにディスプレイ１１５の右側に描写されている。データが特定のデバイスと関連付けられるのを見つけたり目視したりすることを容易にするために、該ＳＰＭデータはディスプレイ部分１１５でデバイスによって類別（カテゴライズ）されている。当然、ユーザは、それらのアイテムやノードに関連するＳＰＭデータを目視するために階層１１０におけるアイテムやノードのいずれかを選択し得る。更に、所望されれば、目視アプリケーション４０は、ＳＰＭブロックエレメントと該ＳＰＭブロックエレメントに対してモニタされているＳＰＭパラメタを含む、図９のエクスプローラディスプレイのようなエクスプローラディスプレイを提供し得る。このように、図９の例示的な階層１４１において、ＳＰＭ１と名づけられたＳＰＭブロック１４２が３０５１−Ｆｌｏｗ（フロー）と名づけられたデバイスに配置されているのが示されている。ＳＰＭ１ブロック１４２の下のエレメント１４３は、モニタされ、ユーザが目視するために使用できるＳＰＭパラメタを示す。この場合、これらのパラメタは、平均値、平均変化値、標準偏差値、標準偏差変化値、標準偏差値によって除算された平均値、および該平均値によって除算された標準偏差値を含む。

所望されれば、目視アプリケーション４０は、フィールドデバイス内で、またはこれらのブロックが配置されるホストや他のデバイス内で、ユーザが、一つ以上のＳＰＭブロックを加算したり再構成したりすることを許可または可能とする。図１０は、スクリーンディスプレイ１４４を示し、この場合、ウィンドウ１４５によって示されるように、ユーザが新しいデバイスを加え、更には、この新しいデバイス内でＳＰＭブロックを追加したり構成したりすることを可能とする。ここで、ＳＰＭブロックは、ＳＰＭ１と名付けられ、（スクリーン１４４の左側の階層にデバイス３０５１ ＬＥＶＥＬとして示された）ＦＴ３０５１−ＣＯＬＤ１のデバイスタグに関連付けられ、ＡＩ１と名付けられたアナログ入力機能ブロックの出力（ＯＵＴ）パラメタまたは変数に関連している（該パラメタまたは変数で演算する）。この場合、目視アプリケーション４０は、ユーザが、関心が持たれる（即ち、モニタされる）ＳＰＭパラメタだけでなく、ＳＰＭブロックに対する平均値、平均変化値、標準偏差変化値などのベースラインおよび閾値を指定することを可能とする。

また更に、目視アプリケーション４０は、ＳＰＭブロック（または他のモニタブロック）からの直接のデータ、または、例えば、アプリケーション４０によって該ＳＰＭブロックから生成されるデータ、のいくつかの種類のビューを得るために、ユーザが、階層を介して、ナビゲートすることを可能とする。例えば、図１１は、スクリーンの左側にプラント階層１４７と、スクリーン１４６の右側のビュー１４８において該階層内のデバイスと関連する一つ以上のＳＰＭまたは他のブロックと、を描くスクリーンディスプレイ１４６を示す。ＳＰＭブロックの一つ（この場合、３０５１Ｓ−１デバイスのＳＰＭ１）を選択する際、ユーザは、ＳＰＭ１ブロックから、データを目視するための方法を選択するためにプルダウンまたはポップアップウィンドウ１４９を使用し得る。図１１において、ユーザは、Ｔｒｅｎｄ ｐｌｏｔ（トレンド座標）を目視することを選択し、更なるポップアップまたはプルダウンウィンドウが、ユーザが、トレンド座標に表示するために特定のＳＰＭパラメタデータ（またはこれらの組み合わせ）を指定することを可能とする。この場合、トレンドされる可能性のあるタイプのデータのいくつかが、ＳＰＭブロックの一つ以上からのデータの組合せとして、決定され得ること、そして、これらの組合せは、ホスト（例えば、アプリケーション４０において）、または、この生データにアクセスを有するフィールドデバイスまたは他のデバイスにおいて計算され得ることが理解されよう。

図１２は、ユーザがポップアップウィンドウ１４９においてデータを直接目視すること（Ｖｉｅｗ Ｄａｔａ）を選択した際のスクリーン１４６を示す。ここでは、もちろん、更なるポップアップウィンドウにおけるデータの選択は異なることもあり、ホストデバイス内で生成されたデータ（標準偏差値によって除算された平均値などの）に対してオプションを提供せずに、ＳＰＭブロックによって収集または生成された生データを指定し得る。アプリケーション４０がＳＰＭブロックからデータを得ることもあり、いくつかの場合においては、ＳＰＭブロックから収集された生統計データからそのデータを生成し得ることも当然理解されよう。また更に、他のタイプのビューまたはオプションが、ヒストグラム座標などの（ＳＰＭブロックからのデータまたはＳＰＭブロックからのデータから生成されるデータのいずれかの）データを目視するために提供され得る。また、ユーザは、ＳＰＭデータを削除したり、新しいデータ収集サイクルをスタートしたりなどのような他の機能を実行するために、スクリーン１４６およびポップアップウィンドウ１４９を使用してもよい。

図１３は、アプリケーション４０によって生成され得る、例示的なトレンドグラフ１５０を示し、該グラフは、ＳＰＭ平均値（Ｍｅａｎ）対時間を示す。このディスプレイにおいて、ユーザは、過去と未来のデータをレビューし、データの始まりまたは終わりを見るため、該データ内の限界値を検索するために、制御ボタン１５２を使用してもよい。いずれにせよ、図１３のトレンドウィンドウなどのようなトレンドウィンドウは、ユーザに、任意のＳＰＭパラメタに対してのビヘイビア（振る舞い）の履歴を目視させる。処理に応じて、異なる処理変数のトレンドに基づいて、異常の状態を特徴付けることが可能である。しかしながら、統計処理データに対してユーザができることには本質的に制限はなく、ユーザが、処理プラント内の現在または今後の異常事態を検出する以外の目的のために、このデータを使用できることも理解されよう。またさらに、ユーザは、収集された統計データを任意のフォーマットまたはビューにおいて目視することができ、これによって、このデータを読み出し、理解し、処理プラント内の事象を検出するとともに予測するために使用することが容易になる。

ざっと見たとき、図１３のグラフは、時間あたり処理変数の通常のグラフのように見える。しかしながら、このグラフは、純粋な時間あたりの処理可変データの座標ではなく、むしろ、ある一定の間隔をおいて計算される処理変数の平均値の座標であることに注目されたい。処理変数平均値対時間を作図するためにＤＣＳ履歴を使用することも可能であるが、ここで異なるのは、処理変数の平均値が一般に元来このデータをまさに収集しているデバイスにおいて計算されていること、また、データの収集速度が極めて速いという点にある。従って、データ履歴によって作成される座標における範囲では、図１３のグラフには測定ノイズが存在しないことが確信される。更に、統計測定値、例えば、平均値は、一般により多くの収集データに基づいているため、より正確である。

同様に、アプリケーション４０は、時間あたりの任意の他のＳＰＭパラメタ（例えば、標準平均値、平均変化値、標準偏差値など）のみならず、ＳＰＭパラメタ（例えば、平均値によって除算された標準偏差値など）の任意の数学的な組合せを作図し得る。また、アプリケーション４０は、ユーザが異なる統計データ間の比較をより簡単にするために、同じグラフまたはページにこれらの座標のいずれかを任意の組合せを配置してもよい。図１４は、同じタイムフレームあたりの処理変数の異なる統計測定値のグラフのセットを示し、全てのグラフは、同じディスプレイスクリーンで同時に、同じまたは異なるディスプレイスクリーンで逐次に、ユーザに提供され得る。図１４において、左上のグラフ１５６は、時間あたりの標準偏差値（Ｓｔａｎｄａｒｄ Ｄｅｖｉａｔｉｏｎ）を作図し、右上のグラフ１５８は、時間あたりの標準偏差値で除算された平均値（Ｍｅａｎ／Ｓｔｄ．Ｄｅｖ．）を作図し、左下のグラフ１６０は、同じ縮尺における時間あたりの（異なるＳＰＭブロックからの）三つの異なる平均値を作図し、右下のグラフ１６２は、同じ縮尺における時間あたりの（異なるＳＰＭブロックからの）三つの標準偏差値を作図する。当然、目視アプリケーション４０は、モニタされたＳＰＭパラメタのいずれか、または、これらのＳＰＭパラメタの時間あたりの任意の数学的な組合せをグラフ上に提供してもよいし、ユーザが処理プラント内で発生していることを理解するのを助けるために、時間あたりの任意の数の異なるＳＰＭパラメタ（または該ＳＰＭパラメタの数学的組合せ）を同一グラフ上に提供してもよい。

統計処理コントロールは、ある処理変数が許容可能な限界値を外れているか否かを判断するために処理コントロール業界においてしばしば使用される。一般に、アプリケーション３８によって収集されたＳＰＭデータに基づいて計算され得る上方管理限界値（ＵＣＬ）および下方管理限界値（ＬＣＬ）と上方指定限界値（ＵＳＬ）および下方指定限界値（ＬＳＬ）の両方がある。管理限界値は、ある例では、ＵＣＬ＝μ＋３σ、およびＬＣＬ＝μ−３σの式で表され、ここで、μとσは、それぞれ、ベースライン平均値とベースライン標準偏差値である。更に、指定限界値は、
（式１）

（式２）

で表され、
式中、Δμは、パーセントで表されるユーザ指定平均値である。もちろん、目視アプリケーション４０は、これらの値を直接計算することもできるし、ユーザにこれらの値を入力させることもできる。

以上のことから、目視アプリケーション４０は、ベースライン平均値と管理限界値に対して平均値の分散を作図し、プラントの稼動中に平均限界値に到達したときまたはこれを超過した時の可視化（ビジュアリゼーション）を提供し得る。この結果は、図１５のグラフ１６６に類似して見える本質的にはヒストグラムグラフである。お分かりのように、上方および下方管理限界値は、それぞれ、ライン１６７および１６８によって示され、上方および下方指定限界値は、それぞれ、ライン１６９および１７０によって示される。更に、平均点（即ち、各値における平均点の数）がライン１７２で作図され、ベースライン平均点は、ヒストグラム座標１７４を用いて作図される。グラフ１６６に示されるように、該処理が制御下にある場合、全てのデータが限界値内にあるということになる。異常事態が発生している場合は、データのいくつかが管理限界値または指定限界値１６７乃至１７０のいずれかを越える（範囲を外れる）。また、グラフ１６６は、処理測定値の平均値（およびベースライン平均値）を作図するが処理測定値そのものは作図しないので、該グラフ１６６は、標準のヒストグラム座標とは異なる。

所望されれば、目視アプリケーション４０は、上記に示されたような管理限界値と指定限界値を、時間あたりの平均値、標準偏差値、または、（メジアン値などの）任意の他の所望される統計測定値の座標に追加することもできる。限界値が平均値対時間座標に追加されたときに得られる座標はＸ−チャートと呼ばれる。統計平均値に対するＸ−チャート１７８の例は、図１６に示され、この図において、平均値（Ｍｅａｎ）対時間はライン１８０で示され、上方および下方の管理限界値はライン１８１と１８２によってそれぞれ示され、上方および下方の指定限界値はライン１８３および１８４によってそれぞれ示される。

この場合、目視アプリケーション４０は、実際の処理変数を作図しないが、ある一定の時間間隔で平均値を作図しているので、上方および下方の管理限界値の計算を調整することが望ましい。測定値のノイズが削減されるので、該処理変数の値を作図する標準Ｘチャートにおいて見られる同一変動が存在することはない。上方および下方の管理限界値に対して行われ得る一つの可能性のある調整としては、各平均値を計算するために使用されるデータポイントの数の平方根によって、３σ部分を除算することである。この形式によれば、上方および下方の管理限界値は、以下のように計算され得る。即ち、
（式３）

（式４）

式中、Ｎ＝（モニタ周期）^*（６０）^*（秒あたりのサンプル（抜き取り）値）

ここで、モニタ周期は、平均値と標準偏差値が計算される分数である。１５分のデフォルト（省略時値）が使用され得る。他の抜取り速度も使用可能であるが、秒あたりのサンプル値は測定値を取るデバイスの抜取り率に基づき、例えば、Ｒｏｓｅｍｏｕｎｔ３０５１Ｆトランスミッタは１０秒、Ｒｏｓｅｍｏｕｎｔ３０５１Ｓトランスミッタは２２秒である。

更に、アプリケーション４０は、時間あたりの標準偏差値が管理限界値および指定限界値によって作図されているＳ−チャートを作成し得る。この場合、上方および下方の管理限界値および上方および下方の指定限界値は、以下のように定義される。
（式５）

（式６）

（式７）

（式８）

Δ_HVは、パーセントで表されるユーザ定義の高変動限界値であり、Δ_LDは、ユーザ定義の低ダイナミック限界値である（Δ_LDは０より小さい）。

Ｓ−チャート１９０の例を図１７に示す。ここで、時間あたりの標準偏差値はライン１９２で示され、上方および下方の管理限界値はライン１９３と１９４でそれぞれ示され、上方および下方の指定限界値はライン１９５と１９６でそれぞれ示される。図１７の例において、処理変数の標準偏差値（ＳＴＤ．Ｄｅｖ．）は、上方および下方の管理限界値を何度もクロスオーバーし、上方の指定限界値を数回クロスオーバーし、これによって、異常事態の現在または将来の発生可能性の有無を潜在的に表している。

またさらに、アプリケーション４０は、収集されたデータから他の統計測定値または値を決定することができる。例えば、アプリケーション４０は、
（式９）

として、任意の統計変数を含み得る変数ｘに対して分散指数または測定値を計算することができる。

アプリケーション４０は、以下の式
（式１０）

によって、能力指数または測定値を計算することができ、および
（式１１）

として、（統計変数を含み得る）二つの変数間の相関係数を計算することができる。

他の例において、二つの変数間の相関係数は、以下の式
（式１２）

によって計算され得る。

もちろん、目視アプリケーション４０は、処理プラント内で一つ以上の異常事態を判断するために、該システム内で所望されるあるいは必要とされるところの（統計変数だけでなく処理変数を含む）任意の変数（あるいは複数の変数）に対して他の計算を実行することもできる。このように、例えば、アプリケーション４０やその中のいくつかのルーチンが、異常事態検出および防止を実行するために、収集されたデータ上で、基本的なコンポーネント解析、回帰解析、ニューラルネットワーク解析、または任意の他の単一または複数の変数解析を実行し得る。

概して、図１３、図１４、図１６および図１７のグラフは、時間当たりの一つ以上のＳＰＭパラメタを作図することを基本としている。しかしながら、目視アプリケーション４０は、時間とは無関係に、一つ以上のＳＰＭ変数間の相関を表したり図示したりするグラフも提供できる。一つの例において、目視アプリケーション４０は、一つのＳＰＭパラメタを他のパラメタに対して作図する分布図を作成し得る。目視アプリケーション４０またはユーザは、二つのＳＰＭパラメタ（または二つのＳＰＭパラメタのいくつかの組合せ）がいかに良好に相関し得るかを表す相関係数を求めることができる。図１８は、互いに対して二つのＳＰＭ平均パラメタを作図する分布図２００を示す。ここで、一般に、二つの平均値が（一つの平均値が増加すると他の平均値も上がる傾向にある）分布点の基本的な直線性によって比例的に相関することが分かる。一般的な分布領域をかなり外れたポイントは該プラント内の潜在的な問題を示唆する。

当然、目視アプリケーション４０は、図１８のような２次元分布図を提供することに限定されない。実際、目視アプリケーション４０は、互いに対して三つ以上のＳＰＭパラメタを作図する３次元以上の分布図を提供し得る。例えば、図１９は、互いに対して、三つのＳＰＭパラメタ、特に、互いに対する三つの処理変数の平均値の関係を作図する３次元分布図２１０を示す。

図２０は、四つのＳＰＭパラメタ間の相関を示す４次元の分布図マトリックス２２０を示す。実際、分布図マトリックス２２０は、１６個の分布図の各々が四つのＳＰＭパラメタの一つ対該四つのＳＰＭパラメタの他の一つを作図する、１６個の異なる２次元の分布図を含む。ここで、ユーザは、処理プラント内で、現在時点での異常事態の検出しようとする際、または、異常事態の今後の発生を予測しようとする際、異なるＳＰＭパラメタ間の相関または関係を素早く目視することができる。

また、図１８乃至図２０の分布図は、これらの分布図が一つ以上の処理変数の平均値は作図するが、処理可変データポイントそのものは作図しないという点で他の公知の分布座標とは異なる。従って、処理変数に一般に存在しているノイズが減少し、これによって、データのより円滑で理解しやすい描画が得られる。更に、アプリケーション４０は、平均値の作図のみに限定されず、標準偏差値、メジアン値などの他の統計変数値間の関係を作図することができる。またさらに、アプリケーション４０は、平均値、標準偏差値などの互いに異なるタイプの統計変数だけでなく、一つの処理変数に対する平均値対他の処理変数に対する平均値によって除算される標準偏差値などの統計変数の組合せを作図することもできる。例としては、アプリケーション４０は、平均値、標準偏差値、平均変化値、標準偏差変化値、または、処理変数をモニタする任意のＳＰＭブロックに対するこれらのＳＰＭ変数の任意の数学的な組合せを作図することができる。

所望されれば、上記にほぼ示されているように、目視アプリケーション４０は、任意の標準または公知の相関計算を用いて、任意のペアのＳＰＭパラメタに対する相関係数を計算してもよいし、求めてもよい。相関係数が１（または−１）に近似している時、二つのＳＰＭパラメタ間に強い線形相関（または弱い線形相関）がある。一組の二つ以上のＳＰＭ変数に対しては、相関マトリックスが決定され、該相関マトリック内の各エレメントが、異なるセットのＳＰＭパラメタの二つのパラメタ間の相関係数を定義する。図２１は、処理プラントのカスケード（翼列）ループ内の少なくとも９つのセンサ測定値の平均値に対する相関係数を有する例示的な相関マトリックス２３０の一部を示す。

図２１の相関マトリックス２３０から、どのＳＰＭパラメタが互いに最強の相関を有するかが決定され得る。明らかに、図２１のような数字のマトリックスは、あまり見やすくはない。しかしながら、アプリケーション４０は、図２２に示される棒図表２４０のような３次元の棒図表としてこのマトリックスを表示することができる。この３次元の棒図表２４０では、どこに最強の相関があるかが視覚的に非常に明確である。当然、アプリケーション４０は、全ての座標が最強の相関がどこにあるかを示すワイヤフレーム（針金細工）座標、等高線座標などの他の図形的な方法において、相関マトリックスを表示することができる。

図２３のスクリーンディスプレイ２４１に示されるような一つの例において、目視アプリケーション４０は、所望される処理状態の一組の相関点と現在または所望されたものではない処理状態における一組の相関点との差を示す相関座標を提供する。このように、図２３のスクリーン２４１は、所望される処理状態に対する相関点（Ｘマーク）を示す第１の相関座標と現在の処理状態に対する同じセットの相関点を示す第２の相関座標との一組２４２を含み、これによって、所望される処理状態と処理プラントの異常事態の存在を示すかもしれない現在の処理状態のパラメタ間の相関の偏差値を示す。ここで、Ｘマークの各相関点は、同一ＳＰＭブロックか異なるＳＰＭブロックのいずれかの少なくとも二つの異なるＳＰＭパラメタの相関値である。もちろん、図２３に示されるように、ベースライン平均値μおよびベースライン標準偏差値σは、片方または両方の処理状態に対して作図され得る。

同様に、図２４を示すスクリーン２４３に示されているように、目視アプリケーション４０は、カラー符号化された相関マトリックスを作成し得て、特定の相関点の値がその大きさによって一組の異なるカラーの一つにおいて図示される。このような相関座標は、ユーザが、異なるＳＰＭパラメタ間で相関を目視し、これによって、処理プラント内の異常事態を検出したり、今後の発生を予測したりすることを容易にする。また、他のタイプのＳＰＭパラメタ（平均値だけではない）、ＳＰＭパラメタの数学的組合せのみならず、異なるタイプのＳＰＭパラメタに対して、相関マトリックスが求められ、グラフ化されることが理解されよう。

また更に、アプリケーション４０は、上記に示されたもの以外に、または、それに代わるものとして、ＳＰＭデータの他のビューを提供することができる。例として、アプリケーション４０は、Ｘ軸に沿った時間あたりのＹ軸およびＺ軸に沿ったＳＰＭブロックの平均値および標準偏差値の３次元トレンド座標、Ｘ軸およびＹ軸に沿った平均値および標準偏差値とＺ軸に沿った各々の量を作図する３次元ヒストグラム座標、および平均値および標準偏差値のいずれかまたは両方が上方および下方の管理限界値および／または指定限界値を含んでいる、Ｘ軸に沿った時間あたりのＹ軸およびＺ軸に沿ったＳＰＭブロックの平均値および標準偏差値の３次元トレンド座標の形態において、可視化グラフやチャートを提供し得る。いうまでもなく、ＳＰＭデータを可視化するためのほぼ無制限の方法もあり、本開示は上記の特定の方法に限定されない。

図２５は、ユーザがＳＰＭパラメタなどの異なる変数の座標、または測定データおよび予測データなどの関連変数またはデータの座標を比較することを可能とするために目視アプリケーション４０によって生成され得る座標スクリーン２４４を示す。この場合、座標スクリーン２４４のセクション２４５は、ユーザが、スクリーンの座標セクション２４６上で表示されるデータの特定座標を選択することを可能とし得る。例えば、ユーザは、全て同一グラフ上で、残差データ、（モデルによって生成されるデータなどの）予測データ等の（同一画面上の階層ビューで選択されたデバイスに対する）測定データの座標を目視することを選択し得る。ユーザはまた、座標内のドリフト検知を実行すること、および／または、座標セクション２４６上の測定閾値を示すことを選択してもよい。図２５の例において、ユーザは、測定された処理状態と予測された処理状態の間のドリフトやミスアライメントを目視するために予測データと並列の（ＳＰＭデータまたは生の処理可変データであり得る）測定データの座標を目視することを選択している。当然、アプリケーション４０は、ユーザが、他の関係を目視すべく、同時作図するために、他の変数およびデータ（ＳＰＭデータと処理可変データの両方）を選択することを可能とする。

他の例としては、目視アプリケーション４０は、同一グラフ上の異なる二つの（またはそれ以上の）ＳＰＭパラメタを生成して、ＳＰＭパラメタの一つの該ＳＰＭパラメタのその他に対する予測されるかあるいは予測できない行動を目視することを可能とする。図２６は、（バルブ関連の）ライン２５２と（トランスミッタ関連の）ライン２５４によって作図されるグラフ２５０を示す。この例において、ユーザまたは技術者は、二つのＳＰＭパラメタの通常の開きに次いで該二つのＳＰＭパラメタの近づきが縦のライン２５５および２５６によって示されるような特定限界値に変換されることを予測する。しかしながら、限界値へ変換される前に、これら二つの変数間に縦のライン２５７および２５８によって示されるような開きが発生した後は、ユーザや技術者は、問題が既に発生してしまったこと、または、異常事態が今後発生し得ることを知ることになる。

ＳＰＭパラメタの相関は、プラント、プラントの一部、設備の一部などの全体的な安全性についてのいくつかの表示ができることが確信される。プラント（またはプラントの一部または設備の一部など）が通常の稼動状態にあるとき、他の変数と高い相関関係をもつ変数がいくつかある場合がある。経時的に、これらの相関値のいくつかが変化する可能性がある。相関値のいくつかの変化によってプラントが以前と同じ性能ではもはや稼動しないことを示す。従って、以下に記載されているいくつかの例は、一つ以上の相関値が経時的にどのようにして変化するかを可視化するための方法を提供する。

相関値の変化を経時的に目視するために、該相関値は異なる時間差で計算され得る。等式１１または等式１２などの式が全体的な使用可能範囲からデータの相関値を生成するために使用され得る。更に、データは、特定長さのセグメント（例えば、３０分、１時間、６時間、１日、７日、特定数のサンプルなど）へ分割され得て、次に、一つ以上の相関値がセグメントごとに計算され得る。このように、相関値が一つのセグメントから次のセグメントへ変化する場合、これは経時的な相関値の変化であると考えられる。他の例としては、相関値は、データのスライディングウィンドウに基づいて生成され、該スライディングウィンドウは、特定の長さ（例えば、３０分、１時間、６時間、１日、７日、特定数のサンプルなど）を有する。

図２７は、経時的な単一の相関値の例示的な座標（座標）２６０を示す。図２８は、経時的な複数の相関値の例示的な座標２６２を示す。図２８に示されるように、同一グラフに作図される相関値が大きくなるにつれて、座標がより込み入ってくる。このように、複数の相関値と関連するデータを可視化するための更なる例示的な方法が以下に示される。

一つの例において、相関値における変化が作図される。例えば、初期値、先行値、ベースライン値、「ノーマル（正常）」値、予測値、などからの相関値の変化が作図され得る。この例において、該変化は相対的変化（例えば、パーセント）または絶対的変化のいずれかとして表されてもよい。

所与の相対値に対するベースライン値は、一般に、相関値の基本となるデータを生成するために必要とされる処理可変データの量を基にした基本となるデータの量で計算すべきである。例えば、平均値は、短ければ、５分区切り、長ければ、丸一日を区切りとしたデータのセグメントに基づいて生成され得る。少なくとも３０個の平均値のデータポイントを用いた平均値のデータからの相関値は、統計的に信頼できるサンプルを提供できると現在のところでは考えられている。（いくつかのインプリメンテーションにおいて、３０個未満の平均値のデータポイントでも統計的に信頼できる相関値を提供できることもあれば、３０個より多い平均値のデータポイントが要求される場合もあることが理解されよう）。この場合、平均値のデータポイントは５分間隔で評価される場合、相関ウィンドウはほぼ３時間以上となる。

いくつかのインプリメンテーションにおいて、平均値データを生成することには、最初の平均値が保存される前の訓練（トレーニング）期間を含まれる。これらのインプリメンテーションにおいて、平均値を生成するためのアルゴリズムには、該処理のためのベースライン平均値を求めるようとすることが含まれる。ベースライン平均値の存在は、二つの連続するブロックのデータの平均値および標準偏差値が互いのある許容範囲内にあることを確認することによって判断され得る。これは、ベースライン平均値が該処理が安定した状態にある時に得られるものであり、該処理が過渡期にあるものではないことを確実とするのを補助することができる。ベースライン平均値が求められた後、アルゴリズムは計算を開始し、他のアルゴリズムや処理によって使用され得る平均値を提供する。これらの平均値は相関値を計算する為に使用され得る。このように、第１の平均値が該アルゴリズムによって計算されるときに該処理が安定した状態にあり、その正常な稼動状態にあるといえる。

一つの例において、ベースライン値の平均値が求められた後で計算された第１の相関値は、ベースライン相関値として選択される。上記のように、第１の相関値が計算される時、多くの場合、該処理は安定した状態であり、その正常な稼動状態にあるという。

しかしながら、いくつかの場合、第１の相関値を常に「ノーマル（正常）」値として使用しようとする場合、問題が発生し得る。例えば、該処理は、たとえ正常な稼動状態にあっても、相関係数が一つの相関ブロックから次の相関ブロックにかけて不規則になる可能性もある。これは二つの変数があるがままで非常に低い相関値を有する場合に特にあてはまることである。また、平均値を生成するＳＰＭブロックのモニタ周期が高すぎる周期あるいは低すぎる周期で構成される場合、あるいは、該平均値を生成するためのアルゴリズムがトレーニングされたときに該処理が正常な状態になかった場合、第１の相関値は基準値の良好な推定値にはならない。

従って、いくつかの状況において、第１の相関値とは異なる相関値をベースライン相関値として使用することが有用である。更に、ベースライン相関値が選択されないこと、あるいは、例えば、相関値が相対的に小さいかおよび／または不規則である時にベースライン相関値がいくつかの絶対値（例えば、０）として選択されることが判断される。

第１の相関値をベースライン値として使用するべきかを判断するためのいくつかの例示的な方法が以下に記載されている。一つの例において、第１の相関値と一つ以上の引き続く相関値の間の差が、該第１の相関値が引き続く相関値と一貫性を有するか判断するために生成され得る。第１の相関値が引き続く相関値とある一定の度合いで異なる場合、第１の相関値はベースライン値として使用してはならないことになる。一つの特定の例において、第１の相関値は第２の相関値と比較される。該第１の相関値がある一定の度合未満（例えば、１％、２％、３％、４％、５％、６％、７％など）で第２の相関値とは異なる場合、第１の相関値は、ベースライン相関値として選択され得る。その差が指定された度合より大きい場合、第１の相関値はベースライン相関値として選択されない。多くの他の方法が、第１の相関値がベースライン値として使用すべきかを判断するために使用され得る。

一つの例において、ベースライン値は、複数の生成された相関値（例えば、相関値を平均した値や中間相関値を取った値など）に基づいて生成され得る。他の例において、ベースライン値は、他の同様の処理から一つ以上の生成された相関値、シミュレーション、モデルなどに基づいて、生成され得る。

初期値、先行値、ベースライン値、「ノーマル（正常）」値、予測値などが相関値ごとに求められると、相関変化アレイが計算され得る。この相関変化アレイは、各相関値と対応する初期値、ベースライン値、「正常」値、予測値などとの間の差を含む。

この差は相対変化値（例えば、パーセント）または絶対変化値として表現され得る。相対値を計算するための一般的な方法が０（ゼロ）と１の間の相関値を生成するので、絶対変化値は、０と１の間であってもよい。しかしながら、パーセントの変化値が使用される場合、ベースライン相関値が０に近似している場合は特にパーセント変化値は潜在的に大きくなる可能性がある。しかしながら、絶対変化値を用いるより、パーセント変化値を使用することは有用でありおよび／または好ましいとされる状況も存在し得る。

図２９は、相関値およびベースライン値対時間の例示的な座標２６４である。この座標２６４は、ユーザが、経時的な相関値とベースライン値の間の差を調べることを可能とする。しかしながら、より多くの相関値とベースライン値が座標２６４に追加された場合、座標は雑然としてくる。

図３０は、対応するベースライン値からの相関差マトリックスの例示的なディスプレイ２６６を示す。この例において、ベースライン値を有さないと判断された相関値に対して、マトリックスセルは空白のままであった。あるいは、これらのマトリックスセルには、対応する相対値がベースライン値を有していないと判断されたことについての表示が記入される。

図３１は、相関値の対応するベースライン値との差のマトリックスを示す例示的なディスプレイ２６８である。ディスプレイ２６８において、相関差の値は、色分けされた四角形として描かれ、ここで、四角形のカラーは、差の程度を示す。例えば、絶対値の差が０．２未満の場合、四角形に第１のカラーが付与される。絶対値の差が０．４より大きい場合、四角形には第２のカラーが付与される。絶対値の差が０．２と０．４の間の場合、四角形には第３のカラーが付与される。

図３０および図３１のディスプレイ２６６と２６８は、時間の瞬間または時間の区分（セグメント）にわたる相関差の値を表示する。他の例において、ユーザに複数の時間の瞬間や期間あたりの相関差の値を表示させるために、ディスプレイが変更され得る。ユーザに種々の期間やセグメントにおける差を目視させるために、例えば、ユーザインターフェース機構（例えば、スクロールバー、矢印ボタンなど）が提供され得る。例えば、図３１のディスプレイ２６８は、異なる瞬時や期間あたりの相関差の値を表示するためのナビゲーションバー２６９を含む。更に、ディスプレイ２６６および２６８は、これらの差がいくつかの時間の瞬間やセグメントにわたっていかにして変化するかを示すために該ディスプレイを「アニメーション化」するためのユーザ−インターフェース機構を含んでいてもよい。同じく、ディスプレイ２６４は、ユーザに異なる期間を目視させるために同様のユーザ−インターフェース機構を設けてもよい。

更に、複数の相関差の値を表す値を生成するために複数の相関差の値が組み合わされる。この値は対時間として作図される。該複数の相関差の値はさまざまな方法で組み合わされてよい。例えば、一組の相関差の値はベクトルとして考えられ、該ベクトルのノルム(基準）は相関値における差を表すことができる。ベクトルのノルムを計算するための三つの等式が以下に提供される。該ノルムは、これらの等式のいずれかあるいは異なる等式によって計算され得る。
(式１３）

(式１４）

(式１５）

ここで、ΔＣｉはｉ番目の相関差の値であり、Ｎは相関差の値の数である。所望されれば、式１３の１／Ｎと式１４の１／√Ｎは省略されてよい。更に、他の式が使用されてもよい。

図３２は、２−ノルム（２−Ｎｏｒｍ）（式１４）値対時間の例示的な座標２７０を示す。該２−ノルム値は複数の相関差の値と対応する。図３３は、特定の時間または時間区分あたりの複数の相関差の値に対する相関差マトリックス２７３と該複数の相関差の値の２−ノルム値対時間の座標２７４を含む例示的なディスプレイ２７２である。ディスプレイ２７２は、異なる時間の瞬間やセグメントあたりの相関マトリックス２７３および／または座標２７４をユーザに見させるためにユーザインターフェース機構（例えば、スクロールバー、矢印ボタンなど）を含んでいてもよい。例えば、ディスプレイ２７２は、ナビゲーションバー２７５を含む。更に、座標２７４は、相関差マトリックス２７３に対応する座標２７４上で時間の瞬間またはセグメントを示すインジケータを含むことができる。また、ディスプレイ２７２は、マトリックス２７３における相関差がいくつかの時間の瞬間やセグメントにわたって、いかにして変化するかを示すために該マトリックス２７３を「アニメーション化」するためのユーザ−インターフェース機構を含んでいてもよい。

前述のように、相関値は二つの変数間の線形相関の度合の測定値を示すこともある。相関値は線形回帰が一組のデータ上で行われた時に相関値が求められ得る。一般に、線形回帰は、データのセットへの最適（ベストフィット）ラインを決定する。このラインの傾きおよび／またはこのラインの経時的な傾きにおける変化は、処理プラント、処理、設備の一部をモニタする際、および／または、異常事態を検出する際に有用である。二組のデータＸおよびＹが与えられたとき、最適ラインの傾きは以下の等式によって計算される。

(式１６）

式中、ｘｉはＸのデータセットのｉ番目のサンプルであり、ｙｉはＹのデータセットのｉ番目のサンプルであり、

はＸのデータセットのサンプルの平均値であり、

はＹのデータセットのサンプルの平均値であり、ＮはデータセットＸおよびＹの各々におけるサンプルの数である。

相関値と対応する傾きはそれらを極座標で作図することによって可視化され得る。特に、相関値の絶対値は半径に対応し、角度は以下のように求められる。
θ＝ｔａｎ−１ｍ （式１７）
式中、ｍは、式１６や他の式によって求められる傾きであり、逆正接関数の範囲は、

である。このように、この方法を用いることによって、極座標の平面の１／２だけが相関点を含む。任意に、極座標平面の全体を使用するために、以下の等式を使用することもできる。
θ＝２・ｔａｎ^-1ｍ （式１８）
この場合、座標に示される角度はラインの正確な傾きを示さない。しかしながら、ユーザがこの座標が視覚的により惹きつけると判断すれば、これは望ましいトレードオフとなる。図３４は、相関値と最適ラインの傾きに対応する角度がいかにして極座標グラフ２７６に作図されるかについての例を示す図である。

図３５は、相関値と極座標を用いて作図される角度の例示的なディスプレイ２７８を示す。このディスプレイ２７８において、中心は、０に近似する相関値を示すが、それ以外の部分は１に近似する相関値を示す。このように、外環に示されるポイントは最高の相関値を有するポイントであり、中心円に示されるポイントは最低の相関値を有するポイントである。これらの環は、さまざまなレベルの相関値を示すのを補助するために色分けされてもよい。ディスプレイ２７８は、異なる時間の瞬間または時間の区分に対して座標をユーザが見ることができるように、ユーザインターフェース機構（例えば、スクロールバー、ボタンなど）を含み得る。例えば、ディスプレイ２７８は、ナビゲーションバー２７９を含む。

他の例において、相関値とベースライン値の差は極座標で作図されてもよい。この例において、相関変化値の大きさが相関値とそのベースライン値の間の差の絶対値として計算され、角度は、例えば、式１８を用いて計算される、単なる相関値の角度である。このように、ベースライン値に近似する相関値は、座標の中心に配置される相関変化値を生じやすい。相関値がそのベースライン値から大きく変化した場合、該座標の中心から離間されて配置される相関変化値を生じやすい。図３６は、極座標を用いて作図される相関変化値の例示的なディスプレイ２８０である。ディスプレイ２８０の環は、相関値とそのベースライン値の間の異なるレベルの大きさの差を示し、カラー符号化されてもよい。この例示的なディスプレイ２８０において、中心環は、０．２未満の相関差を示す。中間環は、０．４未満０．２以上の相関差を示す。外環は０．６未満０．４以上の相関差を示す。異なるインプリメンテーションにおいては、異なる数の環と異なる半径が使用され得る。ディスプレイ２８０は、ユーザが異なる時間の瞬間または時間区分に従った座標をみることができるように、ユーザインターフェース機構（例えば、スクロールバー、ボタンなど）を含んでいてもよい。例えば、ディスプレイ２８０は、ナビゲーションバー２８１を含む。

いくつかの例において図３５および図３６におけるような極座標は、一つの座標における複数の時間の瞬間や区分に従って相関値または相関差の値を作図できる。例えば、ユーザが相関値や相関差値が経時的にいかにして変化するかを見るのを補助するために、異なる時間の瞬間または時間の区分あたりの相関値または相関差は、(任意に矢印を有する）ラインによって共に接続され得る。

図３５および図３６のディスプレイなどのディスプレイは、ユーザが処理の安全性をモニタするのを補助するために他のディスプレイと組み合わされてもよい。例えば、図２３は、極座標を組み込むディスプレイ２４１を示す。

図１１乃至図３６に対して上述された統計データ（例えば、平均値、標準偏差値、平均変化値、標準偏差変化値、相関値、相関変化値、ベースライン値など）は、フィールドデバイス、Ｉ／Ｏデバイス、処理コントローラ、ワークステーション、サーバ、データ履歴などの処理プラント内の種々のデバイスによって生成され得る。例えば、平均値が、フィールドデバイスにおいて生成され得るし、該平均値の相関値がワークステーションにおいて生成され得る。他の例としては、平均値とこの平均値の相関値がフィールドデバイスにおいて生成され得る。

目視アプリケーション４０は、ユーザまたは技術者に、該ユーザまたは技術者が処理プラント内の異常事態の存在または予測される今後の存在について手動的に検出させることができるように上記に説明されたビューのいくつかまたはすべてを提供できる一方、ルールエンジン開発および実行アプリケーション４２がＳＰＭデータに基づく異常事態を自動的に検出するために使用される。図１および図２のルールエンジン開発および実行アプリケーション４２の一つの可能性のある実施の形態が図３７に詳細に示されている。図３７に示されているように、ルールエンジン開発および実行アプリケーション４２は、任意のタイプのルールベースのエキスパートエンジンであってもよいルールエンジン２９０と、該ルールエンジンによってアクセス可能な（図２のメモリ７４Ｂ内におけるような）データベース内に格納され得る一組のルール２９２と、を含む。ルールエンジン２９０は、例えば、図１および図２のデータベース４３、図２の通信サーバ８９、データ履歴などからの（ブロック２９４において示される）統計処理モニタデータを収集するか、あるいは、モニタする。いうまでもなく、このＳＰＭデータは、ＳＰＭデータと処理可変データの両方を含む、上述されたデータ、あるいは、例えば、アプリケーション３８だけでなく、処理プラント内で生成された任意の他のデータによって、得られたデータのいずれを含み得る。即ち、ルールエンジン２９０は、ＳＰＭデータと、例えば、処理構成データ、コントロール戦略データ、コントロール出力データ、処理可変データ、履歴データ、シミュレーションデータ、最適化データ、警告、報知、警告／報知管理データ、ドキュメント管理データ、補助／案内データ、回転設備データ、ラボ解析データ、業界仕様データ、環境規制データなどを含むさまざまな他のタイプのデータを受信し得る。

該ルールエンジン２９０は、ブロック２９６によって示されるように、ルール２９２に少なくとも一つに応じて、警告または報知をユーザへ送信すべきであることを示す状態が存在するかを判断するために、ＳＰＭおよび他のデータへルール２９２を適用する。もちろん、ルールが問題発生を示した場合に、所望されれば、ルールエンジン２９０は、報知の提供や設定以外に、他のアクションをとってもよい。このようなアクションには、例えば、休止処置、より多くの処理用部品の手配、処理のコントロールを変更するためのコントロールパラメタの変更などが含まれる。

更に、ルール開発アプリケーションまたはルーチン２９８は、ユーザが、統計データパターンおよびこれらの相関値に基づいて、一つ以上のエキスパートシステムルールを開発（例えば、ルール２９２の一つとして使用）して、これによって、公知のプラント、ユニット、デバイス、コントロールループなどの異常事態を検出することを可能とする。このように、エキスパートエンジン２９０によって使用されるルール２９２の少なくともいくつは前もって設定されたり、構成されたりしてもよいが、ルール開発アプリケーション２９８は、ユーザが経験に基づいて、モニタされている処理プラント内で他のルールを作成することも可能とする。例えば、ユーザがＳＰＭの異常な状態または事象のある組合せが処理において発生する問題を示すことを分かっている場合、ユーザは、この状態を検出する為の適切なルールを作成するために、そして、所望されれば、この状態の検出された存在に基づいて、報知や警告を生成するために、あるいは他のアクションを取るために、ルール開発アプリケーション２９８を使用することができる。

当然、処理プラントの稼動中、ＳＰＭデータ(および任意のほかの必要とされるデータ
）を受信するように構成された、ルールエンジン２９０は、どのルールが合致するかを判断するためにルール２９２を適用する。該ルール２９２の一つ以上に基づいて該処理における問題が検出された場合、プラントのオペレータヘ警告が表示され、あるいは他の適切な担当者へ送信される。いうまでもなく、所望されれば、プラント内の種々の異常事態を検出するための種々のルールおよび処理動作がエキスパートシステム・ランタイム・エンジン２９０の部分を担うこともでき、これによって、進行する異常事態を検出するためのパターン、データとＳＰＭパラメタの相関値を検索することもできる。

更に、ルールエンジン２９０によって使用され得るデータのいくつかは、ＳＰＭデータが生成され得るデバイス内で検出され得るＳＰＭ状態である。この場合、ルールエンジン２９０は、クライアントシステムであってもよいし、例えば、ＯＰＣサーバを介してデバイスからのＳＰＭパラメタと状態を読み出すクライアントシステムの一部であってもよい。上述したように、これらのＳＰＭパラメタは、平均および標準偏差の値対時間を作図するなどのような今後の使用に向けてのデータベースへ格納されてもよい。いずれの場合においても、処理変数の平均値または標準偏差値が、ユーザ指定量より多く、変化する場合は、ＳＰＭブロックそれ自体が、平均変化値、高変動値または低ダイナミック値などの異常事態を検知し得る。次に、これらの異常事態は、これらのフィールドデバイスによって収集される全ての統計モニタデータと共に、クライアントシステム、例えば、ルールエンジン２９０へ伝達され得る。

さて、プラントエンジニアまたは他のユーザが、処理変数のいくつかの組合せがなんらかの方法で変化した時、報知が出され、即ち、何らかのアクションを取る必要があることが分かった場合、エンジニアは、その状態のセットが発生すると、該ルールのアプリケーションが報知を出すことをわかっている事態を検出するためのルールを定義するために、ルール定義ルーチン２９８を使用することができる。一つの例において、ルール定義アプリケーション２９８は、ユーザが、ルールデータベース２９２において格納される一つ以上のＩＦ−ＴＨＥＮまたはブール（Ｂｏｏｌｅａｎ）タイプのルールを作成することを可能とする構成スクリーンを作成することもできる。一つの可能性のあるこの種のユーザオブジェクト構成スクリーン３００の例が図３８に示されている。特に、構成スクリーン３００は、作成されているルールに対してユーザが名称を定義することを可能にする名称セクション３０２、ＩＦ−ＴＨＥＮタイプのルールに対してユーザがＩＦ状態を定義することを可能とする状態セクション３０４、および“ＩＦ”状態が真であると分かったときに取られる“ＴＨＥＮ”アクションを定義することを可能にするアクションセクション３０６を含む。

図３８の特定の例において、作成されているルールは、「ボイラー１チェック」と名付けられる。更に、図３８に示されるように、状態セクション３０４は、各々が（状態記述において使用されるＳＰＭデータを提供するＳＰＭブロックが配置されている）デバイス３１０の表示を含む、一組の分離した状態記述、（ＳＰＭデータを提供するデバイス内で特定のＳＰＭブロックを定義する）ＳＰＭブロック名３１２、（ＳＰＭブロックによって提供されているデータのタイプを定義する）ＳＰＭデータタイプ３１４、(ＳＰＭデータに対する数学的比較演算を定義する）比較記述３１６、および（該比較記述３１６を用いて受信されたＳＰＭデータが比較される対象である閾値または値を定義する)値セクション３１８を含む。さらにまた、ボックス３２０は、状態記述の各セットの間で用いて、“ＩＦ”状態の全体を定義するために状態記述が論理的に組み合わされる方法を定義するように、ユーザがＡＮＤ演算子やＯＲ演算子などのブール論理演算子を選択したり定義したりすることを可能とする。図３８では、選択される可能性のあるものとしてＡＮＤおよびＯＲのブールの演算子のみが図示されているが、ユーザがより複雑なルールを打ちたてることができるように、任意の他のブール演算子（または他の所望のタイプの演算子）も提供することができる。さらにまた、一組のチェックボックス３２２および３２４は、状態記述のグループ化を定義するために使用され得る。例えば、チェックボックス３２２（前カッコの前）の選択は、一組のカッコ内で定義される新しいセットの状態記述の始まりを示す一方、チェックボックス３２４(後カッコの前)の選択は、一組のカッコ内の一組の状態記述の終わりを示す。お分かりのように、一組のカッコ内の状態記述は、異なるセットのカッコ内で状態記述（または状態記述のグループ）が組み合わされる前にそれらの間でブール演算子を用いて組み合わされる。

このように、図３８の例において、（１）（ＰＴ−１０１デバイスのＳＰＭブロック１によって測定された)平均値が１０２以下であり、且つ（ＡＮＤ）（ＰＴ−１０２デバイスのＳＰＭブロック３によって測定された）標準偏差値が１．２３４以上である場合、又は（ＯＲ）（２）ＦＴ−２０１のデバイスのＳＰＭブロック２の状態パラメタが平均変化値に等しく、且つ（ＡＮＤ）ＦＴ−２０１デバイスのＳＰＭブロック４の状態パラメタが平均変化値に等しい場合、アクションセクション３０６で定義されるアクションが適用される。

図３８に示されるように、アクションセクション３０６はユーザ指定警告名セクション３３０、重大度定義セクション３３２および記述セクション３３４を含む。警告名セクション３３０は、状態セクション３０４が真である場合に生成される警告に関連するあるいはこれに付与される名称を定義し、重大度定義セクション３３２は、（故障、メンテナンス、通信または他のタイプの警告などの）警告の重大度を定義し、記述セクション３３４は、該警告のユーザまたは目視者（ビューワ）に提供され得る警告に関連する記述を提供する。もちろん、図３８のアクションセクション３０６は、生成される警告を定義する一方、該アクションセクション３０６が、該プラント内でデバイス、装置などの稼動の停止、該プラント内のコントロールの設定の切替えや変更、該プラント内でコントローラへ新しい設定ポイントまたは制御条件を提供することなどの他の取るべきアクションをその他にまたはそれに替えて定義することができる。

図３７のルールデータベースに一組のルールが作成され格納された後、エキスパートエンジン開発および実行システム４２が、処理プラントの稼動中に該処理プラント内のＳＰＭブロックによって返されたデータや異常状態に基づいて処理の異常を自動的に検出するために使用される。もちろん、システム４２は、ルールデータベース２９２内のルールに基づいて処理プラント内の異常状態を検出するために処理プラントの稼動中に連続的にあるいは定期的に動作または実行してもよいことが理解されよう。

所望されれば、システム４２は、ユーザに、図３７のルールエンジン２９０の現時点の構成および状態についての情報をもたらす目視スクリーンを提供する。このようなディスプレイの例が図３９に示されている。特に、図３９のディスプレイ３４０は、(本来図６および図８に関して記載されている）検出されたＡＤＢ階層１１０だけでなく図８に関して記載されているＳＰＭデータ１１５のサマリ（要約）を含む。更に、図３９を示すスクリーン３４０は、ルールエンジン２９０に対して定義されている、および該ルールエンジン２９０によってインプリメントされている、ルールについての情報を一覧にすると共に要約するルール要約セクション３４２を含む。図３９の例において、少なくとも三つのルールが定義されている。ルール要約セクション３４２は、これら三つのルールのそれぞれによって使用されるデバイスへの情報だけでなくこれら三つのルールのそれぞれによって生成される警告のタイプまたは重大度を提供する。図３９に示されるように、警告要約セクション３４４は、このようにして定義されたルールに基づいてルールエンジン２９０によって設定されたり送信されたりした任意の警告の表示を提供する。図３９の例において、二つの警告は、システム２故障警告およびボイラー要整備警告を含む二つの警告が現時点で設定されている。これらの警告は、要約セクション３４２において具体的に図示されていないルールに基づいて図３７のルールエンジン２９０によって生成されているが、そのように所望されれば、該警告は、要約セクション３４２で下へスクロールすることによってアクセスされ得る。

お分かりのように、主要ツリーブラウザ１１０と利用可能なＳＰＭブロックのサマリ１１５が図４に関して記載されている方法によって提供され得る。同様に、ルール要約セクション３４２における各ルールは、ユーザが図３８と同様の構成スクリーンを用いて作成され得る。また、ＳＰＭブロックの状態（Ｓｔａｔｕｓ）における状態のいずれかが定義されたルールのいずれかに合致している場合、これらの警告が表示される。いうまでもなく、知られている異常について予め定義されたルールを使用することもできるし、必要があれば、新しい状態に対して既存のルールを変更したり、まったく新しいルールを作成することもできる。

図４０および図４１はルール作成または定義スクリーンの他の例を示す。例えば、ルール定義スクリーン３５０は、各々がテストされる変数またはＳＰＭパラメタを指定する第１のエレメント３５２を有する一組の状態記述３５１を提供する「シンプル」タイプのブールのルール定義子と、（任意の数学的演算またはテストであってもよい)テストまたは
比較状態３５４、および任意の処理変数またはＳＰＭパラメタであってもよい更なるエレメント３５６を含む。これらのエレメントの各々は、所望に応じて、手動的に記入されてもよいし、プルダウンメニューから選択されてもよい。同じく、図３８を示すスクリーンと同様に、ブール演算子は、各状態記述３５１を組み合わせるために指定されてもよいし、結果セクション３６０は、定義されたＩＦ記述（ステートメント）が真である場合に、警告の一部としてユーザへ提供される警告名、重大度およびメッセージを指定するために使用され得る。

図４１は、さまざまなボタン３７４の選択によって組み立てられ得る「ＩＦ」セクション３７２を含む、より「高度な（アドバンスド）」タイプのルール定義子３７０を示す。ボタン３７４は、セクション３７２においてより複雑なＩＦ記述を作成する際に使用される、（ＡＤＢパラメタ、ＳＰＭパラメタ、処理変数（ＰＶ）状態、パラメタ等の）タイプまたは特定のパラメタ、ブール演算子、数字および数学的に同等の記述を含み、あるいは、これらをユーザが指定することを可能にする。警告名定義セクション、重大度定義セクション、およびメッセージセクションを含むセクション３７６は、該ルールによって生成される警告または報知を定義するために使用され得る。もちろん、アプリケーション４０は、現行のまたは予測される異常事態を検出するためにルールエンジン２９０によってインプリメントされるルールを定義する任意の他の方法を提供することができる。

また更に、図３８、図４０、および図４１を示すスクリーンは、ＩＦ−ＴＨＥＮタイプのブールのルールを定義することを可能とするために使用され得るが、他のタイプのルールをこれ以外にまたは代替的に定義されてもよい。例えば、図３８、図４０、および図４１を示すスクリーンが変更されてもよいし、あるいは、スプレッドシートタイプのルール（例えば、マイクロソフト社からのエクセル(商標）のスプレッドシートソフトウェアによって提供されるものと同様のルール）、ファジー論理ルール、パラメタ間の数学的な関係の定義、相関値の生成、パラメタのフィルタ（例えば、低域パスフィルタ、広域パスフィルタ、帯域パスフィルタ、有限インパルス応答（ＦＩＲ）フィルタ、無限インパルス応答（ＩＩＲ）などを可能とするために提供され得る。

動作中、図３７のルールエンジン２９０は、ＳＰＭブロックの状態をルールデータベース２９２内の定義されたルールと合致させるために、多数の異なる方法を使用することができる。ルールデータベース２９２内のルールがあまり複雑ではない場合、エンジン２９０は適切な論理ハンドラによって単純にプログラムされる。しかしながら、これらのルールのいくつかが非常に複雑な場合、すでに開発されているエキスパートシステムを使用することも有利である。

お分かりのように、モニタ処理がスタートすると、すべてのルールが任意の適切なインターフェースを介してルールエンジン２９０へ送られる。その後、図４のブロック１３２または１３４によって検出されるように、ＳＰＭの状態が変化する度に、これらの状態がルールエンジン２９０へ送られる。インターバルごとに、ルールエンジン２９０は、これらのルールのいずれかの状態が合致するかを判断する。これらのルールのどれかが満たされると、ルールエンジン２９０は主要アプリケーションへそのことを通知し、これによって、警告はユーザに表示され、合致した特定のルールのアクション記述に基づいて、いくつかの他のアクションを取ることができる。

図４２は、処理プラントの一部と報知ディスプレイ３８２からなる例示的なスクリーンディスプレイ３８０を示す。ルールエンジン２９０は、一つ以上の適切なルールが満たされた場合に該報知ディスプレイ３８２が表示されるようにする。該報知ディスプレイ３８２は、示唆された補正アクション、プラント手順へのリンク、性能および／または品質データを目視するためのリンクなどを含んでもよい。スクリーンディスプレイ３８０は、該報知に関連付けられるデバイス、ループ、測定値などをあらわすためにディスプレイの部分の周辺にハイライト３８３を含む。例えば、ルールエンジン２９０は、該エンジン２９０に報知ディスプレイ３８２とハイライト３８３を表示させる目視アプリケーション４０へデータを送信してもよい。

図４３は、警告および／または報知情報を含む、処理プラントの一部である他の例示的なスクリーンディスプレイ３８４を示す。特に、座標３８５は、該警告／報知に関連する種々の統計パラメタを表示する。スクリーンディスプレイ３８４は、報知に関連する情報を表示する情報ウィンドウ３８６および３８７を含んでもよい。情報ウィンドウ３８６および３８７は、例えば、カラー符号化を介して異なるレベルの重要性を示す。ルールエンジン２９０は、一つ以上の適切なルールが満たされた場合は、ウィンドウ３８５、３８６および３８７を表示させる。例えば、ルールエンジン２９０は、該エンジンが、ウィンドウ３８５、３８６および３８７を表示させる目視アプリケーション４０へデータを送信してもよい。

図４４は、警告／報知情報を含む、処理プラントの一部であるまた他の例示的なスクリーンディスプレイ３９０を示す。図４５は、警告および／または報知情報を含む、処理プラントの一部である、更に他の例示的なスクリーンディスプレイ３９５を示す。

ルールエンジン２９０が上記に説明されたが、他のタイプの解析エンジンを、それ以外に、または、それに代わるものとして、使用することができる。使用され得る解析エンジンのタイプの他の例としては、数学的演算エンジン（例えば、Ｗｏｌｆｒａｍ Ｒｅｓｅａｒｃｈ（ウルフラムリサーチ）のＭａｔｈｅｍａｔｉｃａR（マセマティカ（登録商標））、ファジー論理解析エンジン、パターンマッチングエンジン、ニューラルネットワーク、回帰解析エンジンなどを含む。

上記のデータ収集技術、可視化技術およびルールエンジン技術は、図１のプラント構成におけるＳＰＭデータを収集し、目視し、処理するために使用され得るが、他の構成においても使用され得る。例えば、これらの技術は、プラント階層を獲得し、所与のプラントにおいてデバイスを発見し、ＡＤＢおよびＳＰＭデータの能力を有するデバイスを見分けるためにソフトウェアが種々のサーバ（例えば、ＯＰＣサーバ、ウェブサーバなど）にアクセスを有するＰＣベース環境（例えば、ＤｅｌｔａＶ、ＡＭＳ、およびオベーション）において使用され得る。他には、ＯＰＣサーバで組み立てられ、フィールドデバイスに直接アクセスする、Ｒｏｓｅｍｏｕｎｔ３４２０のような、フィールドハード化デバイスにおいて直接使用される。この場合、デバイスそれ自体が、データコレクションおよびルールエンジンアプリケーションを格納し、ユーザワークステーションなどの個別のプラットフォームを必要とせずに、これらのアプリケーションを実行することができる。更に、さまざまのケースにおいて、本明細書中に記載されている可視化アプリケーションまたはコンポーネントは、ユーザが目視するために収集されたＳＰＭデータ、警告などを得るためにスタンドアローンデバイスに接続され得る、携帯デバイス、パーソナルアシスタントなどの他のデバイスにおいて実行またはインプリメントされ得る。

同様に、データ収集および目視アプリケーションは遠隔目視デバイスを介してフィールドデバイスまたは他のデバイスにアクセスしてもよい。このように、このソフトウエアは、例えば、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔによって提供されるアセットポータルとＡＭＳウェブ（Ａｓｓｅｔ Ｐｏｒｔａｌ ａｎｄ ＡＭＳｗｅｂ）などのウェブサーバに常駐、あるいは、これらを介して、アクセス可能となる。また、図２において、ＯＰＣサーバは、ＳＰＭブロックを含むフィールドデバイスから分離しているものとして示されているが、ＯＰＣサーバまたは他のサーバがフィールドデバイス自体の一つ以上に配置されてもよい。同様に、異常事態防止システムのデータ収集アプリケーション３８およびルールエンジン４２は、例えば、ＡＤＢまたはＳＰＭブロックを有するデバイス内で、ＳＰＭデータを生成する、ＡＤＢおよび／またはＳＰＭブロックと同じデバイス内に配置されてもよい。この場合、異常事態防止システム３５は、ＯＰＣインターフェース（ＯＰＣインターフェースをいまだに使用している場合もあるが）を必要とせずに、統計的なデータ収集ブロックと同じデバイスにおいて動作したり、実行されたりする。所望されれば、アプリケーション３８および４２によって生成されるＳＰＭデータまたは警告、報知などは、コントローラ接続を介して、ワイヤレスに、携帯デバイスを介して、などの、フィールドデバイスから一般的にアクセスされるようなやり方でアクセスされ得る。

図４６は、ＳＰＭブロックおよび異常事態防止機能を支援するために、分散コントローラ、ホストまたは他のかなり以前から使用されている従来のユーザインターフェースの使用を必要としない処理プラントにおいて異常事態防止をインプリメントする他の方法を示す。図４６のシステム４００において、異常事態防止アプリケーション３５および／またはアプリケーション３８乃至４２が、ホストワークステーションまたはパーソナルコンピュータ以外のデバイスにおいて格納され得る。図４６の例示的なシステム４００は、例えば、Ｒｏｓｅｍｏｕｎｔ３４２０デバイスであってもよいインターフェースデバイス４１０に接続された（Ｆｉｅｌｄｂｕｓフィールドデバイスとして図示されているが他のタイプのデバイスであってもよい）一組のフィールドデバイス４０５を含む。この場合、パーソナルコンピュータではないインターフェースデバイス４１０は、上記の異常事態防止システム３５の機能のいくつかまたは全てを含むこともある。特に、インターフェースデバイス４１０は、フィールドデバイス４０５（種々の異なるタイプのフィールドデバイスであってよい）から分配されたデータを受信し編成するためにブラウザ４１２を含むこともある。所望されれば、ブラウザまたは通信デバイス４１２は、ＯＰＣブラウザを含むこともある。データ収集アプリケーション３８（またはその一部）は、ＳＰＭブロックを有する任意のフィールドデバイスに対して、上記のように、ＳＰＭデータを含むフィールドデバイス４０５からデータを収集するために、インターフェースデバイス４１０のプロセッサ内に格納され、実行される。更に、インターフェースデバイス４１０は、（ＳＰＭブロックや機能性を含まないフィールドデバイスなどの）フィールドデバイスの一つ以上から処理可変データを直接収集し、上記のように、ＳＰＭパラメタを生成するために、一つ以上のＳＰＭブロック４１４を含んでいてもよい。このように、インターフェースデバイス４１０に格納され、実行されるＳＰＭブロック４１４は、フィールドデバイス４０５のいくつかの内部においてＳＰＭブロックの欠落を補償することが可能であり、ＳＰＭブロックやＳＰＭ機能をそれら自体が支援しないフィールドデバイスに対して、ＳＰＭデータを提供するために使用され得る。

更に、ルールエンジンアプリケーション４２（または、図３７のルールエンジン２９０などのルールエンジンの一部）がインターフェースデバイス４１０によって格納され、実行されてもよいし、データベース４３も、同様に、インターフェースデバイス４１０内に配置されてもよい。インターフェースデバイス４１０は、ユーザが目視するためのデバイスに対して、ＳＰＭデータや、警告、データ座標などのＳＰＭデータから展開されたデータなどを提供するために、２回線、３回線、４回線などの接続などのハード接続を介して、ホストワークステーション４３０などの他のデバイスと通信し得る。更に、図４６に示されるように、インターフェースデバイス４１０は、一つ以上のワイヤレス通信接続を介して、ウェブブラウザ４４０、および電話、パーソナルデータアシスタント（ＰＤＡ）、ラップトップコンピュータなどの携帯コンピュータデータデバイス４５０に接続され得る。この例において、目視アプリケーション４０の一つ以上がウェブブラウザ４４０または携帯演算デバイス４５０のホストアプリケーション４３０などの他のデバイスにおいて格納され実行され、これらのアプリケーションは、上記のいずれかのような、任意の方法で処理および目視するための所望されるデータを得るために、インターフェースデバイス４１０と通信することもできる。所望されれば、デバイス４３０、４４０および４５０は、インターフェースデバイス４１０によってインプリメントされるルールをユーザが生成することを可能とする為に、図３７のルール定義アプリケーション２９８を含み得る。同様に、図４６に示されるように、インターフェースデバイス４１０からのデータは、ウェブブラウザ４６０によってホスト４３０から間接的にアクセスされてもよいし、任意の所望されるウェブ接続を介して、他のユーザへ提供されてもよい。当然のことながら、インターフェースデバイス４１０は、ウェブサーバを含むこともできるし、ＯＰＣ、Ｍｏｄｂｕｓ、イーサネット（登録商標）、ＨＴＭＬ、ＸＭＬなどの任意の他のプロトコルを用いたデバイス４３０、４４０、４５０および４６０などの任意の他のデバイスと通信することもできる。

図４７は、図４６のそれと類似したものでもよいしあるいは同一であってもよいインーフェースデバイス４１０が、（熱交換器５１５を構成する）一組のフィールドデバイス５１０と処理コントロールシステム５２０の間で接続されている、更なる処理プラント構成５００を示す。ここで、図４６のデバイス４１０のアプリケーションと機能性の全てを含み得るインターフェースデバイス４１０が、ホスト５３０へ目視するためのデータを提供し得て、ルールエンジンによって生成された警告または報知をコントローラシステム５２０へ提供し得る。コントロールシステム５２０は、例えば、オペレータワークステーション５４０におけるコントロールオペレータによって、これらの警告または報知を目視用の他のコントローラタイプの警告および報知と一体化させることもできる。いうまでもなく、所望されれば、ホストワークステーション５３０は、任意の所望される方法データにおいて、本明細書中で説明されている任意のものを含む、インターフェースデバイス４１０において収集され、該インターフェースデバイス４１０によって提供されるデータを目視するために、任意の所望される目視アプリケーションを含み得る。同様に、このデータは、ウェブブラウザ５５０を介して他のユーザによって目視するために使用可能とされ得る。このように、お分かりのように、異常事態防止システム３５に関連しているものとして本明細書中に説明されている種々のアプリケーションは、異なるデバイスに分配されてもよいし、全てがユーザインターフェースを有するデバイスにおいて操作される必要もない。代わりに、（ＳＰＭデータなどの）データが、インターフェースデバイス４１０におけるような一つのデバイスにおいて収集され処理され、完全に異なるデバイスにおいて目視するために送信されてもよい。同様に、ルールは、ホスト、ウェブブラウザ、ＰＤＡなどのユーザインターフェースデバイスにおいて作成され、ルールエンジンにおけるインプリメンテーションのために、インターフェースデバイス４１０のような異なるデバイスへ送信されてもよい。

図１および図２の例において、異常事態防止システム３５に関連するアプリケーション３８、４０、４２は、同一のワークステーションまたはコンピュータ上で格納されるものとして図示されているが、これらのアプリケーションのいくつか、または、他のエンティティが、処理プラント１０内またはこれに関連した他のワークステーションまたはコンピュータにおいて格納され実行され得る。さらに、異常事態防止システム３５内のアプリケーションが分割されて、二つ以上のコンピュータやマシン上で実行されてもよいし、ワイヤード、ワイヤレス、および／または、断続通信接続を介して、互いに連結して、動作するように構成されてもよい。また、本明細書中に記載の異常事態防止システム３５は、アプリケーション３８、４０、および４２のいずれかまたは全てを含んでもよいし、必ずしも含まなくてもよいが、本明細書中に記載のＡＤＢまたはＳＰＭブロックを含んでもよい。また、本明細書中に記載の例としては、ＦｉｅｌｄｂｕｓＳＰＭブロックの形態でＳＰＭブロックを使用しているが、本明細書中で使用されている用語「ＳＰＭブロック」は、これらのブロックまたはルーチンが公知のＦｉｅｌｄｂｕｓプロトコルに合致するものであろうとなかろうと、処理データまたは変数を収集すると共に何らかの統計演算またはモニタリングを実行する任意の他のタイプの統計処理モニタブロック、ルーチンなどを言及しこれらを含むように意図されている。

更に、上記説明は、統計データを計算するＡＤＢブロックおよびＳＰＭブロックのようなブロックに述べられているが、他のタイプの信号処理データを生成する他のタイプの信号処理データ収集ブロックが使用されてもよい。例えば、周波数解析データ（例えば、処理変数のフーリエ変換や他の変換に基づいて生成されるデータ）、自動回帰データ、ウェーブレットデータ、ニューラルネットワークを用いて生成されるデータ、ファジー論理を用いて生成されるデータなど、を生成する信号処理データ収集ブロックが異常事態防止システムにおいて使用され得る。このように、本明細書中において使用されている用語「信号処理データ収集ブロック」は、処理データまたは変数を収集し、統計データの生成、処理データの（例えば、フーリエ変換、離散型フーリエ変換、高速フーリエ変換、短期フーリエ変換、Ｚ−変換、ヒルベルト変換、ラドン変換、ウィグナー分布、ウェーブレット変換などの）数学的変換、変換された処理データからの情報の抽出、フィルタリング、ファジー論理を用いた処理データからの情報の抽出、ニューラルネットワーク、自動回帰技術などの信号処理演算やモニタリングを実行する、任意のタイプのモニタリングブロック、ソフトウェアルーチン、ハードウェアなどを言及すると共にこれらを含むように意図されている。

また、信号処理プラント内の信号データ収集ブロックから信号処理データが集められ、解析される例が説明されてきたが、複数の処理プラントのコンテクスト（状況）において同様の技術が使用可能であることが理解されよう。例えば、複数の処理プラントからの信号処理データが集められ、このデータは、解析エンジンおよび／または目視アプリケーションに提供され得る。

特定の通信プロトコルおよび技術を用いた例について説明されてきたが、公知のプロトコルおよび技術を含む、信号データ収集ブロックからの構成データおよび信号処理データにアクセスするためのさまざまな他のプロトコルおよび技術が使用され得る。例えば、信号データ収集ブロックを識別および／または構成し、信号処理データなどを収集するために、ＯＰＣ以外の他のプロトコルおよび技術を使用することができる。他の技術には、例えば、インターネットプロトコル、イーサネット（登録商標）、ＸＭＬ、プロプラエタリ・プロトコルなどを使用することを含んでもよいし、他のインプリメンテーションは、ウェブサーバ、および／または、処理コントローラ、Ｉ／Ｏ（出入力）デバイス、ワークステーション、フィールドデバイスなどのプロプラエタリ演算デバイスが使用し得る。同様に、プロプラエタリ・データを含む他のタイプの階層データが使用され得る。

本明細書中に記載の異常事態防止システムとアプリケーションが異常事態防止システムと関連するものとして好ましくはソフトウェアにおいてインプリメントされているが、これらはハードウェア、ファームウェアなどにおいてインプリメントされ得て、該処理コントロールシステムに関連する任意の他のプロセッサによってインプリメントされ得る。このように、本明細書中に記載のエレメントは、標準多目的ＣＰＵ内で、または、所望に応じたＡＳＩＣ（特定用途向けＩＣ）や他のハード回線デバイスなどの専用設計のハードウェアやファームウェア上でインプリメントされ得る。ソフトウェアにおいてインプリメントされるとき、ソフトウェアルーチンは、磁気ディスク、（ＤＶＤなどの）レーザディスク、他の格納媒体などの任意のコンピュータ可読媒体、コンピュータやプロセッサのＲＡＭ（ランダムアクセスメモリ）やＲＯＭ（リードオンリーメモリ）、任意のデータベースなどに格納され得る。同様に、このソフトウェアは、例えば、コンピュータ可読ディスクや他の運搬可能なコンピュータ格納機構上で、あるいは、電話回線、インターネットなどの通信チャネルなどを介して、即ち、任意の公知のまたは所望される分配方法を介して、ユーザや処理プラントへ分配され得る（運搬可能な格納媒体を介してこのようなソフトウェアを提供することと同じ、あるいは、互換性があると見なされる）。

このように、本開示は、特定の実施例について説明されているが、これは単に例示することを目的するものであり、本発明を限定するものではない。従って、本開示内容の精神および範囲を逸脱しない限りにおいてあらゆる変更、追加、および削除が行われてよいことが当業者に明確であろう。

Claims (24)

1. 処理プラントに関連する異常状態を検出する方法であって、
   該方法が、
   （ａ）構成及びデータ収集アプリケーションを実行して、処理プラントに関連する複数のデバイス各々に設けられた信号処理データ収集ブロックを自動的に構成し、該複数の信号処理データ収集ブロックを自動的に構成することは、（１）処理コントロールネットワークの階層をスキャンして、信号処理データ収集ブロックを含む前記処理プラント内のデバイスをリストし、（２）前記信号処理データ収集ブロックのうちのいずれの信号処理データ収集ブロックがイネーブルされており及びいずれの信号処理データ収集ブロックがディセーブルされているかを判定し、（３）ディセーブルされている信号処理データ収集ブロックをモニタできるように自動的に構成し、（４）前記処理プラントのオペレーションの間前記信号処理データ収集ブロックをモニタし、収集した信号処理データをデータベースに記憶することを含み、
   （ｂ）前記データベースに記憶される前記信号処理データを受信し、該信号処理データは、前記処理プラントに関連する前記複数のデバイス各々に設けられた前記信号処理データ収集ブロックによって生成され、該信号処理データは、前記信号処理データ収集ブロックにより収集された少なくとも一つ以上の処理変数を入力として用いて前記信号処理データ収集ブロックにより生成された統計データを含み、該統計データは、平均値、標準偏差値、平均変化値、標準偏差変化値、ベースライン平均値、ベースライン標準偏差値、高変動限界値、低ダイナミック限界値及び平均限界値のうちの少なくとも一つのパラメータを含み、
   （ｃ）少なくとも前記信号処理データ収集ブロック各々から収集した信号処理データに基づいて前記処理プラントに関連する少なくとも一つの異常状態を検出及び予測するために、解析エンジンのルールエンジンを構成し、
   （ｄ）前記ルールエンジンへ前記信号処理データを提供し、
   （ｅ）アクションをとるべきかを判断するために前記ルールエンジンを使用することであって、前記ルールエンジンが、更に、
   （１）前記信号処理データと閾値との比較データ、（２）前記信号処理データの相関データ、及び（３）前記信号処理データに対応しモデルにより生成された予測データと前記信号処理データとの比較のデータのうちの少なくとも一つを生成し、
   前記信号処理データにより異常状態が存在するか又は異常状態が予測されるかを判断するルールを前記少なくとも１つの生成されたデータに適用し、異常状態を検出又は予測して警告又は報知を出すこと
   を含む、
   処理プラントに関連する異常状態を検出する方法。
2. 信号処理データを受信することが、前記データベースから検索された信号処理データを受信することを含む、請求項１に記載の方法。
3. 信号処理データを受信することが、前記処理プラントに関連する少なくとも一つのフィールドデバイスからの信号処理データを受信することを含む、請求項１に記載の方法。
4. 信号処理データを受信することが、処理変数に関連する信号処理パラメタを受信することを含む、請求項１に記載の方法。
5. 前記信号処理データは、統計データ、周波数解析データ、自動回帰データ、ウェーブレットデータ、ニューラルネットワークを使って生成されるデータ、およびファジー論理を用いて生成されるデータの少なくとも一つを含む、請求項１に記載の方法。
6. 信号処理データを受信することが、フィールドデバイスに設けられた少なくとも一つの信号処理データ収集ブロックによって生成された信号処理データを受信することを含む、請求項１に記載の方法。
7. 信号処理データを受信することが、処理コントローラ、データ履歴、およびワークステーションの少なくとも一つに設けられる少なくとも一つの信号処理データ収集ブロックによって生成された信号処理データを受信することを含む、請求項１に記載の方法。
8. Ｆｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓプロトコル、ＨＡＲＴプロトコル、ＰＲＯＦＩＢＵＳプロトコル、ＷＯＲＬＤＦＩＰプロトコル、Ｄｅｖｉｃｅ−Ｎｅｔプロトコル、ＡＳ−Ｉｎｔｅｒｆａｃｅプロトコル、およびＣＡＮプロトコルの少なくとも一つに追従するフィールドデバイスによって生成されたデータを受信することを含む、請求項１に記載の方法。
9. 信号処理データを受信することが、ワイヤードネットワークとワイヤレスネットワークの少なくとも一つを介して信号処理データを受信することを含む、請求項１に記載の方法。
10. 信号処理データを受信することが、ワイヤード接続、ワイヤレス接続、および断続接続の少なくとも一つを介して、信号処理データを受信することを含む、請求項１に記載の方法。
11. 前記解析エンジンへ前記信号処理データを提供することが、ルールエンジンへ信号処理データを提供することを含む、請求項１に記載の方法。
12. 前記ルールエンジンへ信号処理データを提供することが、前記信号処理データの少なくともいくつかのデータに少なくとも一つのブールのルールを適用すべく構成されたルールエンジンへ信号処理データを提供することを含む、請求項１１に記載の方法。
13. 前記ルールエンジンへ信号処理データを提供することが、前記信号処理データの少なくともいくつかのデータに少なくとも一つのファジー論理ルールを適用すべく構成されたルールエンジンへ信号処理データを提供することを含む、請求項１１に記載の方法。
14. 前記解析エンジンへ信号処理データを提供することが、前記信号処理データの少なくともいくつかの中から相関度を求めるべく構成された解析エンジンへ信号処理データを提供することを含む、請求項１に記載の方法。
15. 前記解析エンジンへ信号処理データを提供することが、ニューラルネットワーク、数学的演算エンジン、ファジー論理解析エンジン、パターンマッチングエンジン、および回帰解析エンジンの少なくとも一つへ前記信号処理データを提供することを含む、請求項１に記載の方法。
16. 前記解析エンジンを用いることが、警告または報知を出すべきかを判断するために該解析エンジンを用いることを含み、
    該方法が、前記警告または報知を発生することを更に含む、請求項１に記載の方法。
17. 前記解析エンジンを用いることが、前記処理プラントに関連するコントロールの設定を変更すべきかを判断するために、該解析エンジンを用いることを含み、
    該方法が、前記コントロールの設定を変更させることを更に含む、請求項１に記載の方法。
18. 前記解析エンジンを用いることが、オペレータが、異常状態に関する一つ以上の推奨アクションに促されて、アクションを取るべきかを判断するために、該解析エンジンを用いることを含み、
    該方法が、前記オペレータが、前記一つ以上の推奨アクションに促されるようにすることを更に含む、請求項１に記載の方法。
19. 前記解析エンジンを用いることが、コントローラに関連する制御状態および設定ポイントの少なくとも一つを変更すべきかを判断するために、該解析エンジンを用いることを含み、
    該方法が、前記コントローラに関連する前記制御状態および前記設定ポイントの少なくとも一つを変更させることを更に含む、請求項１に記載の方法。
20. 前記信号処理データの解析中に前記解析エンジンの状態を表す情報を、ユーザインターフェースを介して、提供することを含む、請求項１に記載の方法。
21. 前記信号処理データの解析中に前記解析エンジンの構成を表す情報を、ユーザインターフェースを介して、提供することを含む、請求項１に記載の方法。
22. 前記解析エンジンへ構成データを提供することが、処理構成データ、コントロール戦略データ、コントロール出力データ、処理可変データ、履歴データ、シミュレーションデータ、最適化データ、警告、報知、警告／報知管理データ、ドキュメント管理データ、ヘルプ／ガイダンスデータ、回転装置データ、ラボ解析データ、環境調整データの少なくとも一つに更に基づいて、前記処理プラントに関連する少なくとも一つの異常状態を検出すべく前記解析エンジンを構成するために該解析エンジンへ構成データを提供することを含む、請求項１に記載の方法。
23. 処理プラントに関連する異常状態を検出するシステムであって、
    該システムが、
    前記処理プラントに関連するネットワークに通信可能に連結された少なくとも一つのプロセッサと、
    前記少なくとも一つのプロセッサに通信可能に連結された少なくとも一つのコンピュータ可読メモリと、
    処理プラントに関連する複数のデバイス各々に設けられた信号処理データ収集ブロックを自動的に構成するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第１のルーチンであって、該第１のルーチンは、（１）処理コントロールネットワークの階層をスキャンして、信号処理データ収集ブロックを含む前記処理プラント内のデバイスをリストし、（２）前記信号処理データ収集ブロックのうちのいずれの信号処理データ収集ブロックがイネーブルされており及びいずれの信号処理データ収集ブロックがディセーブルされているかを判定し、（３）ディセーブルされている信号処理データ収集ブロックをモニタできるように自動的に構成し、（４）前記処理プラントのオペレーションの間前記信号処理データ収集ブロックをモニタし、収集した信号処理データをデータベースに記憶するよう作動する、前記第１のルーチンと、
    前記データベースに記憶される前記信号処理データを受信するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第２のルーチンであって、該信号処理データは、前記処理プラントに関連する前記複数のデバイス各々に設けられた前記信号処理データ収集ブロックによって生成され、該信号処理データは、前記信号処理データ収集ブロックにより収集された少なくとも一つ以上の処理変数を入力として用いて前記信号処理データ収集ブロックにより生成された統計データを含み、該統計データは、平均値、標準偏差値、平均変化値、標準偏差変化値、ベースライン平均値、ベースライン標準偏差値、高変動限界値、低ダイナミック限界値及び平均限界値のうちの少なくとも一つのパラメータを含む、前記第２のルーチンと、
    少なくとも前記信号処理データ収集ブロック各々から収集した信号処理データに基づいて前記処理プラントに関連する少なくとも一つの異常状態を検出及び予測するための解析エンジンを実行可能となるよう生成するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第３のルーチンと、
    前記信号処理データの少なくともいくつかを解析し、（１）前記信号処理データと閾値との比較データ、（２）前記信号処理データの相関データ、及び（３）前記信号処理データと対応しモデルにより生成される予測データと前記信号処理データとの比較のデータのうちの少なくとも一つを生成し、ルールエンジンを使用して前記信号処理データにより異常状態が存在するか又は異常状態が予測されるかを判断するルールを前記少なくとも一つの生成されたデータに適用することによりアクションを取るべきかを判断し、異常状態を検出又は予測して警告又は報知を出すように、前記解析エンジンを実行するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第４のルーチンと、
    を含む、
    処理プラントに関連する異常状態を検出するシステム。
24. 前記第４のルーチンは、処理構成データ、コントロール戦略データ、コントロール出力データ、処理可変データ、履歴データ、シミュレーションデータ、最適化データ、警告、報知、警告／報知管理データ、ドキュメント管理データ、ヘルプ／ガイダンスデータ、回転装置データ、ラボ解析データ、環境調整データの少なくとも一つを更に解析して、前記アクションを取るべきかを判断するように、該解析エンジンを実行する、請求項２３に記載のシステム。

Images