処理プラントに関連する異常状態を検出する方法であって、該方法が、該処理プラントに関連する複数のデバイスによってインプリメントされた信号処理データ収集ブロックによって生成される信号処理データを受信し、少なくとも前記信号処理データに基づいて前記処理プラントに関連する少なくとも一つの異常状態を検出するために、解析エンジンを構成すべく、該解析エンジンへ構成データを提供し、前記解析エンジンへ前記信号処理データを提供し、アクションをとるべきかを判断するために前記解析エンジンを使用すること、を含む、処理プラントに関連する異常状態を検出する方法。信号処理データを受信することが、データベースから検索された信号処理データを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、前記処理プラントに関連する少なくとも一つのフィールドデバイスからの信号処理データを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、処理変数に関連する信号処理パラメタを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、処理変数に関連する信号処理パラメタの状態の表示を受信することを含む、請求項1に記載の方法。信号処理データを受信することが、統計データ、周波数解析データ、自動回帰データ、ウェーブレットデータ、ニューラルネットワークを使って生成されるデータ、およびファジー論理を用いて生成されるデータの少なくとも一つを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、少なくとも一つの統計データ収集ブロックによって生成された信号処理データを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、フィールドデバイスによってインプリメントされる少なくとも一つの信号処理データ収集ブロックによって生成された信号処理データを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、処理コントローラ、データ履歴、およびワークステーションの少なくとも一つによってインプリメントされる少なくとも一つの信号処理データ収集ブロックによって生成された信号処理データを受信することを含む、請求項1に記載の方法。FoundationFieldbusプロトコル、HARTプロトコル、PROFIBUSプロトコル、WORLDFIPプロトコル、Device-Netプロトコル、AS-Interfaceプロトコル、およびCANプロトコルの少なくとも一つに追従するフィールドデバイスによって生成されたデータを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、ワイヤードネットワークとワイヤレスネットワークの少なくとも一つを介して信号処理データを受信することを含む、請求項1に記載の方法。信号処理データを受信することが、ワイヤード接続、ワイヤレス接続、および断続接続の少なくとも一つを介して、信号処理データを受信することを含む、請求項1に記載の方法。前記解析エンジンへ前記信号処理データを提供することが、ルールエンジンへ信号処理データを提供することを含む、請求項1に記載の方法。前記ルールエンジンへ信号処理データを提供することが、前記信号処理データの少なくともいくつかのデータに少なくとも一つのブールのルールを適用すべく構成されたルールエンジンへ信号処理データを提供することを含む、請求項13に記載の方法。前記ルールエンジンへ信号処理データを提供することが、前記信号処理データの少なくともいくつかのデータに少なくとも一つのファジー論理ルールを適用すべく構成されたルールエンジンへ信号処理データを提供することを含む、請求項13に記載の方法。前記解析エンジンへ信号処理データを提供することが、前記信号処理データの少なくともいくつかの中から相関度を求めるべく構成された解析エンジンへ信号処理データを提供することを含む、請求項1に記載の方法。前記解析エンジンへ信号処理データを提供することが、ニューラルネットワーク、数学的演算エンジン、ファジー論理解析エンジン、パターンマッチングエンジン、および回帰解析エンジンの少なくとも一つへ前記信号処理データを提供することを含む、請求項1に記載の方法。前記解析エンジンを用いることが、警告または報知を出すべきかを判断するために該解析エンジンを用いることを含み、該方法が、前記警告または報知を発生することを更に含む、請求項1に記載の方法。前記解析エンジンを用いることが、前記処理プラントに関連するコントロール設定を変更すべきかを判断するために、該解析エンジンを用いることを含み、該方法が、前記コントロール設定を変更させることを更に含む、請求項1に記載の方法。前記解析エンジンを用いることが、オペレータが、異常状態に関する一つ以上の推奨アクションに促されて、アクションを取るべきかを判断するために、該解析エンジンを用いることを含み、該方法が、前記オペレータが、前記一つ以上の推奨アクションに促されるようにすることを更に含む、請求項1に記載の方法。前記解析エンジンを用いることが、コントローラに関連するコントロール状態および設定点の少なくとも一つを変更すべきかを判断するために、該解析エンジンを用いることを含み、該方法が、前記コントローラに関連する前記コントロール状態および前記設定点の少なくとも一つを変更させることを更に含む、請求項1に記載の方法。前記信号処理データの解析中に前記解析エンジンの状態を表す情報を、ユーザインターフェースを介して、提供することを含む、請求項1に記載の方法。前記信号処理データの解析中に前記解析エンジンの構成を表す情報を、ユーザインターフェースを介して、提供することを含む、請求項1に記載の方法。前記解析エンジンへ構成データを提供することが、処理構成データ、コントロール戦略データ、コントロール出力データ、処理可変データ、履歴データ、シミュレーションデータ、最適化データ、警告、報知、警告/報知管理データ、ドキュメント管理データ、ヘルプ/ガイダンスデータ、回転装置データ、ラボ解析データ、環境調整データの少なくとも一つに更に基づいて、前記処理プラントに関連する少なくとも一つの異常状態を検出すべく前記解析エンジンを構成するために該解析エンジンへ構成データを提供することを含む、請求項1に記載の方法。処理プラントに関連する異常状態を検出するシステムであって、該システムが、前記処理プラントに関連するネットワークに通信可能に連結された少なくとも一つのプロセッサと、前記少なくとも一つのプロセッサに通信可能に連結された少なくとも一つのコンピュータ可読メモリと、前記処理プラントに関連する複数のデバイスによってインプリメントされる信号処理データ収集ブロックによって生成される信号処理データを受信するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第1のルーチンと、前記処理プラントに関連する少なくとも一つの異常状態を検出すべく前記解析エンジンを構成するために解析エンジンへ構成データを提供するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第2のルーチンと、アクションを取るべきかを判断すべく、前記信号処理データの少なくともいくつかを解析するために前記解析エンジンをインプリメントするために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第3のルーチンと、を含む、処理プラントに関連する異常状態を検出するシステム。前記第3のルーチンが、前記アクションを取るべきかを判断するために、処理構成データ、コントロール戦略データ、コントロール出力データ、処理可変データ、履歴データ、シミュレーションデータ、最適化データ、警告、報知、警告/報知管理データ、ドキュメント管理データ、ヘルプ/ガイダンスデータ、回転装置データ、ラボ解析データ、環境調整データの少なくとも一つを更に解析するために、該解析エンジンをインプリメントすることである、請求項25に記載のシステム。処理プラントに関連する異常状態を検出するために解析エンジンを構成する方法であって、該方法が、前記処理プラントに関連する複数のデバイスによってインプリメントされる複数の信号処理データ収集ブロックによって生成される複数の信号処理パラメタから第1の信号処理パラメタを指定するために、第1のユーザインターフェース機構を提供し、前記複数のデバイスによってインプリメントされる前記複数の信号処理データ収集ブロックによって生成される前記複数の信号処理パラメタから第2の信号処理パラメタを指定するために、第2のユーザインターフェース機構を提供し、前記解析エンジンによって実行されるべく少なくとも前記第1の信号処理パラメタと前記第2の信号処理パラメタの解析を指定するために、第3のユーザインターフェース機構を提供し、前記第1、第2、および第3のユーザインターフェース機構を介して、構成データを受信し、前記構成データを格納すること、を含む、処理プラントに関連する異常状態を検出するための解析エンジン構成方法。前記複数の信号処理データ収集ブロックが、フィールドデバイス、処理コントローラ、データ履歴、およびワークステーションの少なくとも一つによってインプリメントされる信号処理データ収集ブロックを含む、請求項27に記載の方法。第1のユーザインターフェース機構を提供することが、前記複数のデバイスから一つのデバイスを指定するために第4のユーザインターフェース機構を提供し、前記一つのデバイスによってインプリメントされる少なくとも一つの信号処理データ収集ブロックによって生成される第1のセットの信号処理パラメタから第1の信号処理パラメタを指定するために、第5のユーザインターフェース機構を提供すること、を含む、請求項27に記載の方法。前記第5のユーザインターフェース機構を提供することが、前記一つのデバイスによってインプリメントされる信号処理データ収集ブロックから一つの信号処理データ収集ブロックのセットを指定するために、第6のユーザインターフェースデバイスを提供し、前記一つの信号処理データ収集ブロックによって生成される第2のセットの信号処理パラメタから前記第1の信号処理パラメタを指定するために、第7のユーザインターフェースデバイスを提供すること、を含む請求項29に記載の方法。前記第3のユーザインターフェース機構を提供することが、前記第1の信号処理パラメタに対して実行される比較解析を指定するために、第4のユーザインターフェース機構を提供することを含む、請求項27に記載の方法。前記第3のユーザインターフェース機構を提供することが、前記第1の信号処理パラメタと比較する値を指定するために、第5のユーザインターフェース機構を提供することを含む、請求項31に記載の方法。前記第3のユーザインターフェース機構を提供することが、前記第1の信号処理パラメタと比較する第3の信号処理パラメタを指定するために、第5のユーザインターフェース機構を提供することを含む、請求項31に記載の方法。前記第3のユーザインターフェース機構を提供することが、前記第1の信号処理パラメタと前記第2の信号処理パラメタに対して実行されるブール論理演算を指定するために、第4のユーザインターフェース機構を提供することを含む、請求項27に記載の方法。条件が一致したことを前記解析が示した場合に、取るべきアクションを指定するために、第4のユーザインターフェース機構を提供することを更に含み、構成データを受信することが、前記第4のユーザインターフェース機構を介して、構成データを受信することを含む、請求項27に記載の方法。前記第4のユーザインターフェース機構を提供することが、前記条件が一致したことを前記解析が示した場合に、生成される警告を指定するために、前記第4のユーザインターフェース機構を提供することを含む、請求項35に記載の方法。前記第4のユーザインターフェース機構を提供することが、前記条件が一致したことを前記解析が示した場合に、コントロール設定変更を指定するために、前記第4のユーザインターフェース機構を提供することを含む、請求項35に記載の方法。前記第4のユーザインターフェース機構を提供することが、前記条件が一致したことを前記解析が示した場合に、取るべき一つ以上の推奨アクションによってオペレータを促すためのプロンプトを指定するために、第4のユーザインターフェース機構を提供することを含む、請求項35に記載の方法。前記第4のユーザインターフェース機構を提供することが、前記条件が一致したことを前記解析が示した場合に、コントロール条件変更および設定点変更の少なくとも一つを指定するために、第4のユーザインターフェース機構を提供することを含む、請求項35に記載の方法。処理プラントに関連する異常状態を検出するために解析エンジンを構成するためのシステムであって、該システムが、処理プラントに関連するネットワークに通信可能に連結された少なくとも一つのプロセッサと、前記少なくとも一つのプロセッサに通信可能に連結された少なくとも一つのコンピュータ可読メモリと、前記処理プラントに関連する複数のデバイスによってインプリメントされる複数の信号処理データ収集ブロックによって生成される複数の信号処理パラメタから第1の信号処理パラメタを指定すべく第1のユーザインターフェース機構を提供するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第1のルーチンと、前記複数のデバイスによってインプリメントされる前記複数の信号処理データ収集ブロックによって生成される前記複数の信号処理パラメタから第2の信号処理パラメタを指定すべく第2のユーザインターフェース機構を提供するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第2のルーチンと、前記解析エンジンによって実行される少なくとも前記第1の信号処理パラメタおよび前記第2の信号処理パラメタの解析を指定すべく第3のユーザインターフェース機構を提供するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサ上で実行されるべく用いられる、第3のルーチンと、前記第1のユーザインターフェース機構、前記第2のユーザインターフェース機構、および前記第3のユーザインターフェース機構を介して、構成データを受信するために、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサで実行されるべく用いられる第4のルーチンと、前記少なくとも一つのコンピュータ可読メモリに格納され、前記少なくとも一つのプロセッサで実行されるべく用いられる、第5のルーチンと、を含む、処理プラントに関連する異常状態を検出するために解析エンジンを構成するためのシステム。前記複数の信号処理データ収集ブロックがフィールドデバイス、処理コントローラ、データ履歴、およびワークステーションの少なくとも一つによってインプリメントされる信号処理データ収集ブロックを含む、請求項40に記載のシステム。知られているように、特に、多数のフィールドデバイスおよび支援装置を有する処理プラントにおける処理プラント環境下でさまざまな問題が頻繁に発生している。これらの問題は、デバイスが破壊したり、誤動作を生じたりすること、ソフトウェアルーチンなどの論理エレメントが不良モードにあること、処理コントロールループの調整が不良であること、処理プラント内のデバイス間の通信の一つ以上に故障が発生するなどの形態をとる。以上の問題は、実際、多数発生しており、これが、一般には、通常、処理が、処理プラントの準最適性能に関連する異常状態即ち、処理プラントが異常状況にあることで動作するという結果を生じる。一旦、これらの問題が発生し検出されると、処理プラント内で発生する問題の原因を突き止め、判断するとともに、オペレータやメンテナンス担当者が、これらの問題を診断するとともに補正するのを助けるために、多数の診断ツールおよびアプリケーションが開発されてきた。例えば、直接またはワイヤレスバス、イーサネット登録商標Ethernet登録商標、モデム、電話回線などの通信接続を介して、一般に処理コントローラに接続されている、オペレータワークステーションは、多数のコントロールモジュールおよびコントロールループ診断ツールを含むEmersonProcessManagementエマーソンプロセスマネージメント社によって販売されているDELTAVTMデルタV商標システムおよびOvationオベーションコントロールシステムなどのソフトウェアまたはファームウェアを実行するように用いられるプロセッサおよびメモリを有する。同様に、コントローラアプリケーションと同じ通信接続を介して、または、OPC処理コントロールのためのオブジェクト連結および埋込み接続、携帯接続などの異なる通信接続を介して、フィールドデバイスなどの処理コントロールデバイスに接続され得る、メンテナンスワークステーションは、一般に、処理プラント内のデバイスを試験するとともに処理プラント内のフィールドデバイスおよび他のデバイス上でメンテナンス業務を実行するために処理プラント内のフィールドデバイスによって生成されるメンテナンスの報知および警告を目視ビューするように設計された一つ以上のアプリケーションを含む。処理プラント内の支援装置の問題を診断するためにも同様の診断アプリケーションが開発されている。このように、例えば、EmersonProcessManagementによって販売されるIntegratedCommunicationNetworkforuseinaFieldDeviceManagementSystemフィールドデバイスマネージメントシステムにおいて使用する統合通信ネットワークと題された米国特許第5960214号に少なくとも部分的に記載されたAssetManagementSolutionsAMSアセットマネージメントソリューションアプリケーションは、フィールドデバイスの動作状態を確認しトラッキング追跡するために、該フィールドデバイスに一部関連するデータとの通信を可能とすると共に該データを格納する。いくつかの例において、AMSアプリケーションは、フィールドデバイスと通信して該フィールドデバイス内のパラメタを変更し、例えば、自己較正ルーチンまたは自己診断ルーチンなどのアプリケーションをフィールドデバイスそれ自体に実行させ、該フィールドデバイスの状態またはヘルス調子などについて情報を得るために使用される。この情報は、例えば、状態情報例えば、報知または他の同様の事象が発生したかについて、デバイス構成情報フィールドデバイスが現在構成されているまたは構成され得る方法と該フィールドデバイスによって用いられる測定単位の種類、デバイスパラメタ例えば、フィールドデバイス範囲値および他のパラメタなどを含み得る。当然、この情報は、フィールドデバイスに伴う問題をモニタし、維持し、および/または診断するために、メンテナンス担当者によって使用され得る。同様に、多くの処理プラントは、種々の回転装置の動作状態をモニタし、診断し、最適化するために使用される、例えば、CSI共通システムインターフェースシステムによって提供されるRBMリスクベースメンテナンス製品などの装置モニタおよび診断アプリケーション、または、任意の他の公知のアプリケーションを含む。通常、メンテナンス担当者は、プラント内の回転装置の性能を維持、管理し、回転装置に関わる問題について判断し、該回転装置を修理すべきか交換すべきかについて、また、その適切な時期を判断するためにこれらのアプリケーションを使用する。同様に、多くの処理プラントは、発電および配電装置をコントロールすると共に維持するため、例えば、リーバートLiebert社およびアスコASCO社によって提供される電源制御および診断アプリケーションを含む。また、処理プラントの制御業務を最適化するために、処理プラント内で、例えば、リアルタイムオプティマイザ実時間最適化装置RTOなどの制御最適化アプリケーションを実行することも知られている。一般に、このような最適化アプリケーションは、該処理プラントの複雑なアルゴリズムおよび/またはモデルを使用して、例えば、利益などのいくつかの所望される最適化変数に対して該処理プラントのオペレーション最適化のためにどのように入力を変更すべきかを予測する。以上の診断および最適化アプリケーションは、一般に、オペレータまたはメンテナンスワークステーションの一つ以上においてシステムワイドベースでインプリメントされ、処理プラントの作動状態、または、該処理プラント内のデバイスおよび装置に関して、オペレータまたはメンテナンス担当者へ、予備構成されたディスプレイを提供する。一般のディスプレイは、処理プラント内の処理コントローラまたは他のデバイスによって生成される報知を受ける報知ディスプレイ、処理コントローラおよび処理プラント内の他のデバイスの動作状態を示すコントロールディスプレイ、処理プラント内のデバイスの動作状態を示すメンテナンスディスプレイなどを含む。同様に、以上の診断アプリケーションは、オペレータやメンテナンス担当者が、コントロールループを再調整したり、他のコントロールパラメタをリセットしたり、これらのフィールドデバイスの現行の状態を判断するために一つ以上のフィールドデバイスを試験したり、フィールドデバイスまたは他の装置を較正したり、あるいは、処理プラント内のデバイスおよび装置上での他の問題の検出および補正業務を実行することを可能とする。これらの種々のアプリケーション及びツールは、処理プラント内の問題を識別し補正する際に非常に役の立つのであるが、一般に、これらの診断アプリケーションは、処理プラント内で問題が発生した後でのみ、即ち、該プラント内に異常事態既存状態において、使用するように構成されている。あいにく、異常事態は、これらのツールを使って、検出され、識別され、補正される前のある段階で存在するため、結果的には、該問題が検出され、識別され、補正されている期間について、該処理プラントは準最適性能となる。多くの場合、コントロールオペレータは、最初に、処理プラントの報知、警告または性能低下に基づいていくつかの問題が存在することを検出する。次に、オペレータは、メンテナンス担当者に潜在的な問題を通知する。メンテナンス担当者は、実際の問題を検出する場合もあれば、検出しない場合もあり、試験や他の診断アプリケーションを実際に実行する前に更にプロンプトしたり、あるいは、実際の問題を識別するために必要とされる他の業務を実行したりする必要がある場合もある。一旦問題が識別されると、メンテナンス担当者は、部品を注文しメンテナンス手順の予定を立てる必要があり、これらのすべてを含む問題の発生とこの問題の補正までに結果的にはかなりの期間が必要とされ、この間、処理プラントは一般に該プラントの準最適性能に対応付けられる異常事態下で稼動される。更に、多くの処理プラントは、相対的に短時間でプラント内に相当なコストやダメージを生じる異常事態を経験し得る。例えば、いくつかの異常事態は、設備に相当なダメージを与え、原材料の損失を生じ、または、これらの異常事態が発生している時間がたとえ短くても、処理プラント内で予期できない作業中止時間を生じることになる。このように、問題が発生した後、単にプラント内で問題を検出するだけでは、その問題がいかに迅速に補正されても、やはりまだ処理プラント内に多くの損失やダメージが生じ得る。この結果、異常事態が発生してから、該処理プラント内で既に発生した問題に対処したりそれらを補正したりするのではなく、異常事態の発生を初めから防止しようと試みることが望ましい。処理プラント内で何らかの重大な損失が発生する前に予測される異常事態を防止する工程を取るという目的に沿って、これらの異常事態が実際に発生する前に処理プラント内のいくつかの異常事態の発生をユーザに予測させることを可能とするデータを収集するために使用され得る技術が現在一つ提供されている。この方法は、一部が米国特許出願第08623569号、現在は、米国特許第6017143号に基づく根本原因診断RootCauseDiagnosticsと題された米国特許出願第09972078号に開示されている。これらの両出願は本明細書中に参照することによって組み込まれている。概して、この技術は、統計データ収集および処理ブロックまたは統計処理モニタSPMブロックを、処理プラント内のフィールドデバイスなどの多数のデバイスの各々に、配置する。該統計データ収集および処理ブロックは、例えば、処理可変データを収集し、該収集されたデータに関連する、平均値、メジアン値、標準偏差値などの統計測定値を求める。次に、これらの統計測定値は、ユーザに送られ、既知の異常事態の今後の発生を示唆するパターンを認識するために解析される。今後発生しそうな特定の異常事態が検出されると、根本的な問題を補正するための工程がとられ、これにより、この異常事態を初めから回避することができる。しかしながら、統計データを収集する多数のフィールドデバイスを有する処理プラントにおいては特に、データの収集および解析は、通常のメンテナンスオペレータにとっては、非常に面倒であり、冗長な作業である。更にまた、メンテナンス担当者が統計データを収集することが可能である場合でも、この人物が、該データを最適に解析しあるいは目視する方法や、仮にあったとしても、該データによって今後発生する異常事態のどの異常事態を示唆すべきかを判断する方法を知らない場合も考えられる。また、概して、大きな処理規模においては特に、SPM統計処理モニタによって生成される統計処理データの全てを収集すると共に目視するためのプラントを構成することは負荷が大きく、非常に冗長である。実際、現在、ユーザは、異なるフィールドデバイス内で関心が持たれるパラメタの各々を個別にモニタするOPCクライアントを作成する必要があり、これは、該データを収集するために全てのフィールドデバイスが個別に構成されなければならないということである。この構成処理には非常に手間がかかり、人的エラーを誘いやすい。一つの態様において、システムは、処理プラントに関連する異常状態を検出する。該システムは、複数のデバイスによって実施される信号処理データ収集ブロックによって生成される信号処理データを受信する。該信号処理データ収集ブロックは、統計データ、周波数解析データ、自動回帰データ、ウェーブレットなどを生成し得る。該システムは、該処理プラントに関連する少なくとも一つの異常状態を検出すべく構成される解析エンジンを含む。信号処理データは、該解析エンジンに提供され、該解析エンジンがアクションを取るべきかを判断する。他の態様において、処理プラントに関連する異常状態を検出するために解析エンジンを構成するためのシステムは、該解析エンジンによって解析すべき信号処理パラメタを指定するためのユーザインターフェースメカニズムを含む。該信号処理パラメタは、該処理プラント内の複数のデバイスによってインプリメントされる信号処理データ収集ブロックによって生成され得る。該指定された信号処理パラメタの解析を指定する為に他のユーザインターフェースメカニズムが使用され得る。構成データは、ユーザインターフェースメカニズムを介して、受信され、格納される。図1を参照すると、異常事態防止システムがインプリメントされ得る例示的な処理プラント10は、一つ以上の通信網を介して支援装置と相互接続される多数のコントロール制御およびメンテナンスシステムを含む。特に、図1の処理プラント10は、一つ以上の処理コントロールシステム12および14を含む。処理コントロールシステム12は、PROVOXプロボックスやRS3システムなどの従来の処理コントロールシステムであってもよいし、コントローラ12Bおよび入力/出力I/Oカード12Cに接続されたオペレータインタフェース12Aを含む任意の他のコントロールシステムであってよい。また、該入力/出力I/Oカード12Cは、アナログおよびHighwayAddressableRemoteTransmitterHARTフィールドデバイス15などの種々のフィールドデバイスに接続されている。分散形処理コントロールシステムであってもよい処理コントロールシステム14は、Ethernet登録商標イーサネット登録商標バスなどのバスを介して、一つ以上の分散コントローラ14Bに連結された一つ以上のオペレータインターフェース14Aを含む。該コントローラ14Bは、例えば、EmersonProcessManagementエマーソンプロセスマネージメント社、テキサス州、オースティンによって販売されているDeltaVTM商標や任意の他の所望されるタイプのコントローラであってもよい。コントローラ14Bは、I/Oデバイスを介して、例えば、HARTやFieldbusフィールドデバイスなどの一つ以上のフィールドデバイス16に、または、PROFIBUSプロフィバス登録商標、WORLDFIPワールドフィップ登録商標、Device-Netデバイスネット登録商標、AS-InterfaceインターフェースおよびCANキャンプロトコルのいずれかを使用するフィールドデバイスを含む任意の他のスマートまたはノンスマートフィールドデバイスに、接続される。公知のように、フィールドデバイス16は、コントローラ14Bへ、処理変数だけでなく他のデバイス情報に関連するアナログまたはディジタル情報を提供し得る。オペレータインタフェース14Aは、たとえば、コントロール制御オプティマイザ、診療エキスパート、ニューラルネットワーク、チューナなどを含む処理動作をコントロールするために、処理コントロールオペレータが利用可能なツールを格納するとともに実行し得る。また更に、AMSアプリケーションまたは任意の他のデバイスモニタおよび通信アプリケーションを実行するコンピュータなどのメンテナンスシステムは、処理コントロールシステム12および14に、または、これらのシステム内部の個々のデバイスに接続され、メンテナンスおよびモニタ活動を実行する。例えば、メンテナンスコンピュータ18は、ワイヤレスまたは携帯デバイスネットワークを含む任意の所望される通信回線またはネットワークを介して、コントローラ12Bにおよび/またはデバイス15に接続され、デバイス15と通信したり、場合によっては、該デバイス15上で他のメンテナンス活動を再構築または実行したりする。同様に、AMSアプリケーションなどのメンテナンスアプリケーションは、デバイス16の動作状態に関連するデータ収集を含むメンテナンスおよびモニタ機能を実行するために、分散処理コントロールシステム14に関連する一つ以上のユーザインターフェース14Aでインストールされ、実行され得る。処理プラント10はまた、いくつかの永続的な、あるいは、装置20に接続されて読み出しを行っては、次に、削除されるようなバス、ワイヤレス通信システムまたは携帯デバイスなどの一時的な通信リンクを介して、メンテナンスコンピュータ22に接続されたタービンやモータなどのさまざまな回転装置20も含む。メンテナンスコンピュータ22は、例えば、CSIEmersonProcessManagementCompanyエマーションプロセスマネージメント社によって提供される公知のモニタおよび診断アプリケーション23、または、回転装置20の状態を診断し、モニタし、最適化するために使用される任意の他の公知のアプリケーションを格納し、実行し得る。通常、メンテナンス担当者は、プラント10内の回転装置20の性能を維持し管理し、回転装置20に関わる問題を判断し、該回転装置20の修理または交換の時期あるいは修理または交換しなければならないかについての判断を行うために、アプリケーション23を使用する。場合によっては、外部の専門家やサービス機関が、装置20に関するデータを一時的に取得または測定し、該装置20に影響を与える問題、性能低下または他の問題点を検出すべく、該装置に対する解析を実行するためにこのデータを使用することもある。これらの場合において、解析を実行するコンピュータは、いかなる通信回線を介してもシステム10の他の部分に接続されることはなく、たとえ、接続されたにせよ、一時的にすぎない。同様に、プラント10に関連する発電および分配装置25を有する発電および分配システム24は、例えば、バスを介して、該プラント10内の発電および分配装置25の動作を実行し管理する他のコンピュータ26に接続されている。コンピュータ26は、発電および分配装置25をコントロールし、維持するために、例えば、リーバート社およびアスコ社や他社によって提供される公知の電源コントロールおよび診断アプリケーション27を実行する。またここでも、多くの場合は、外部の専門家やサービス機関が、装置25に関するデータを一時的に取得または測定し、該装置25に影響を与える問題、性能低下または他の問題点を検出すべく、該装置に対する解析を実行するために、このデータを使用することもある。これらの場合において、解析を実行するコンピュータ例えば、コンピュータ26は、いかなる通信回線を介してもシステム10の他の部分に接続されることはなく、たとえ、接続されたにせよ、一時的にすぎない。図1に示されるように、コンピュータシステム30は、異常事態防止システム35の少なくとも一部をインプリメントし、特に、コンピュータシステム30は、統計的収集および処理ブロックを含み得る、構成およびデータ収集アプリケーション38、目視またはインターフェースアプリケーション40と、ルールエンジン開発および実行アプリケーション42を格納し、更に、該処理内のいくつかのデバイス内で生成される統計データを格納する統計処理モニタデータベース43を格納する。概して、構成およびデータ収集アプリケーション38は、フィールドデバイス15、16、コントローラ12B、コントローラ14B、回転デバイス20またはその支援コンピュータ22、発電装置25またはその支援コンピュータ26、および処理プラント10内の任意の他の所望されるデバイスおよび装置内に配置された、多数の統計データ収集および解析ブロック図1に示されていないの各々を構成するとともにこれらと通信し、これによって、異常事態防止を実行するこれらのブロックの各々から統計データまたは、場合によっては、処理可変データを収集する。構成およびデータ収集アプリケーション38は、ハードワイヤードバス45を介して、プラント10内のコンピュータやデバイスの各々に通信可能に接続されてもよいし、または、それに替えて、例えば、ワイヤレス接続、OPCを使用する専用接続、データを収集するための携帯デバイスなどに依存するような断続接続などを含む、任意の他の所望される通信接続などを介して、接続されてもよい。同様に、アプリケーション38は、図1にインターネット接続46として示されるインターネット、電話接続などのLANや公衆接続を介して、処理プラント10内のフィールドデバイスおよび装置に関するデータを得ることができる。このようなデータは、例えば、第三者のサービスプロバイダによって収集される。また、アプリケーション38は、例えば、イーサネット登録商標、Modbusモドバス、HTMLHyperTextMarkUPLanguageハイパーテキストマーク付け言語、XMLExtensibleMarkUPLanguage拡張可能なマーク付け言語、プロプラエタリ所有権主張可能な技術および/またはプロトコルなどを含む、種々の技術および/またはプロトコルを介して、プラント10内のコンピュータおよび/またはデバイスに通信可能に連結され得る。このように、本明細書中では、プラント10のコンピュータおよび/またはデバイスにアプリケーション38を通信可能に連結させるためのOPCを用いた特定の例が記載されているが、当業者は、それぞれ、プラント10内のコンピュータおよび/またはデバイスにアプリケーション38を連結させるための種々の他の方法が使用できることを認識するであろう。一般に、アプリケーション38は、収集されたデータをデータベース43に格納してもよい。統計データまたは処理可変データが一旦収集されると、目視ビューイングアプリケーション40は、データを処理するため、および/または、さまざまな方法で、例えば、データベース43に格納されているような収集または処理された統計データを表示するために使用されてもよく、これによって、メンテナンス担当者などのユーザが、異常事態の有無または予測される今後の異常事態の有無を判断したり、先取りして補正動作を取ったりすることがより容易にできるようにする。ルールエンジン開発および実行アプリケーション42は、処理プラント10内の異常事態の有無を判断したり、将来的な異常事態を予測したりすべく、収集されたデータを解析するために、該アプリケーション42に格納されている一つ以上のルールを使用してもよい。更に、これらのルールエンジン開発および実行アプリケーション42は、オペレータまたは他のユーザが異常事態を検出または予測するためにルールエンジンによってインプリメントされる更なるルールを作成することを可能とする。図2は、統計データ収集が異常事態防止システム35によって実行され得る一つの方法を記載するために、図1に例示された処理プラント10の部分50を示す。図2は、異常事態防止システムアプリケーション38、40、42、およびデータベース43とHartおよび、Fieldbusフィールドデバイス内の一つ以上のデータ収集ブロックの間の通信を示すが、異常事態防止システムアプリケーション38、40、および42と図1に示されるデバイスおよび装置のいずれかを含む処理プラント10内の他のデバイスおよび装置の間に同様の通信が発生し得ることが理解されよう。図2に示される処理プラント10の部分50は、任意の所望される通信やコントローラプロトコルに従う任意の所望されるタイプのI/O入出力デバイスであってもよい、I/Oカードまたはデバイス68および70を介して、一つ以上のフィールドデバイス64および66に接続される一つ以上の処理コントローラ60を有する、分散処理コントロールシステム54を含む。フィールドデバイス64は、任意の他の所望される通信プロトコルをも使用することができるが、該フィールドデバイス64は、HARTフィールドデバイスとして示され、フィールドデバイス66は、Fieldbusフィールドデバイスとして示される。更に、フィールドデバイス64および66は、例えば、センサ、バルブ、トランスミッタ、ポジショナなどの任意のタイプのデバイスであり得て、また、これらのフィールドデバイスは、任意の所望されるオープンな、プロプラエタリな他の通信またはプログラミングプロトコルに追従し得て、I/Oデバイス68および70が、フィールドデバイス64および66によって使用される所望のプロトコルと互換性がある必要があることが理解されよう。いずれにしても、構成エンジニア、処理コントロールオペレータ、メンテナンス担当者、プラントマネジャーなどのプラント関係者によってアクセス可能な一つ以上のユーザインターフェースまたはコンピュータ72および74任意のタイプのパソコン、ワークステーションであってもよいが、任意の所望されるハードワイヤードまたはワイヤレス通信構造を用いて、および、例えば、イーサネット登録商標プロトコルなどの任意の所望されるあるいは好適な通信プロトコルを用いて、インプリメントされ得る通信回線またはバス76を介して、処理コントローラ60に接続される。更に、データベース78は、通信バス76に接続されて、構成情報だけでなく、処理プラント10内の処理コントローラ60およびフィールドデバイス64および66に関連する、オンライン処理可変データ、パラメタデータ、状態データ、および他のデータを収集するとともに格納するデータ履歴として動作する。このように、データベース78は、処理構成モジュールだけでなく、処理コントローラ60およびフィールドデバイス64および66内にダウンロードされ、格納されたときの処理コントロールシステム54のためのコントロール構成情報を含む、現在の構成を格納するための構成データベースとして動作する。同様に、データベース78は、処理プラント10内のフィールド64および66によって収集された統計データまたはフィールドデバイス64および66によって収集された処理変数から求められた統計データを含む、経過的な異常事態防止データを格納することができる。処理コントローラ60、I/Oデバイス68および70、フィールドデバイス64および66は、一般に、時には過酷なプラント環境下に配置され、この環境を介して分配されるが、ワークステーション72および74とデータベース78は、オペレータやメンテナンス担当者などがアクセスしやすい、コントロールルーム、メンテナンスルームまたは他のあまり厳しくない環境に配置される。概して、処理コントローラ60は、多数の異なる、個別に実行されるコントロールモジュールまたはブロックを用いて、コントロール戦略を実行する一つ以上のコントローラアプリケーションを格納すると共に実行する。コントロールモジュールは、それぞれ、一般に、機能ブロックと呼ばれるものから構成され得る。ここで、各機能ブロックは、全体的なコントロールルーチンの一部またはサブルーチンであり、処理プラント10内で処理コントロールループをインプリメントするために他の機能ブロックと組み合わされてリンクと呼ばれる通信を介して動作する。周知のように、オブジェクト指向プログラミングプロトコル内のオブジェクトであってもよい機能ブロックは、一般に、処理プラント10内でいくつかの物理的機能を実行するために、トランスミッタ、センサ、または他の処理パラメタ測定デバイスに関連する機能などの入力機能と、PID、ファジー論理などのコントロールを実行するコントロールルーチンに関連する機能などのコントロール機能と、または、バルブなどのいくつかのデバイスの動作をコントロールする出力機能とのうちの一つを実行する。当然、モデル予測コントローラMPC:modelpredictivecontrollers、オプティマイザなどのハイブリッドおよび他のタイプの複雑な機能ブロックも存在する。FieldbusプロトコルおよびDeltaVTM登録商標システムプロトコルは、オブジェクト指向プログラミングプロトコルにおいて設計されインプリメントされるコントロールモジュールおよび機能ブロックを使用する一方、該コントロールモジュールは、例えば、逐次機能ブロック、ラダー論理などを含む任意の所望されるコントロールプログラミング技術を用いて設計され得ることが理解されよう。但し、該コントロールモジュールは、機能ブロックや任意の他の特定のプログラミング技術を用いての設計に限定されない。図2に示されているように、メンテナンスワークステーション74は、プロセッサ74A、メモリ74B、およびディスプレイデバイス74Cを含む。メモリ74Bは、ディスプレイ74Cまたはプリンタなどの任意の他のディスプレイデバイスを介して、ユーザに情報を提供すべく、プロセッサ74A上でアプリケーションがインプリメントされ得るように、図1で説明された異常事態防止アプリケーション38、40、および42を格納する。更に、図2に示されるように、フィールドデバイス64および66のいくつか潜在的には全ては、データ収集および処理ブロック80および82を含む。一方、図2に関しては、ブロック80および82が、本説明を行うために、Fieldbusデバイス内の統計データを収集し処理するためのFieldbusデバイスに追加され得るFieldbusデバイス内で統計データを収集し処理する、公知のFoundationFieldbus機能ブロックである、高度診断ブロックADBとして、説明されているが、該処理ブロック80および82は、これらのブロックが、Fieldbusデバイス内に配置されていようがいまいが、あるいは、Fieldbusプロトコルに追従していようがいまいが、デバイスデータを収集し、該データに対する一つ以上の統計測定値またはパラメタを計算したり決定したりする、処理デバイス内に配置される任意の他のタイプのブロックやモジュールであってもよいし、あるいは、これらを含んでいてもよい。図2のブロック80および82は、デバイス64の一つとデバイス66の一つに配置されているものとして示されているが、これらのブロックあるいは同様のブロックは、任意数のフィールドデバイス64および66に配置されてもよいし、コントローラ60、I/Oデバイス68および70、または図1に示されるいずれかのデバイスなどの他のデバイス内に配置され得る。更に、該ブロック80および82は、フィールドデバイス64および66の任意のサブセット内にあってもよい。概して、ブロック80および82、またはこれらのブロックのサブエレメントは、それらが配置され、なんらかの理由があってデータ上で統計処理または解析を実行するデバイス内で処理可変データなどのデータを収集する。例えば、バルブと関連しているものとして示される、ブロック80は、該バルブがスタック膠着状態にあるかを判断するためにバルブ処理可変データを解析するスタックバルブ検出ルーチンを有し得る。更に、ブロック80は、例えば、収集されたデータの平均値、メジアン値、標準偏差値、平方根RMS、変化の割合、範囲値、最小値、最大値などを求めるため、および/または、収集したデータにおいてドリフト浮漂、バイアス偏り、ノイズ雑音、スパイク過電圧などの事象を検出するため、バルブ内の処理可変または他のデータを収集し、該収集されたデータ上で一つ以上の統計的計算を実行し得る四つの統計処理モニタSPMブロックまたはユニットSPM1~SPM4のセットを含む。生成された特定の統計データもそれが生成される方法もあまり重要ではない。このように、上述された特定のタイプの統計データ以外にそれに代わる異なるタイプの統計データが生成され得る。更に、公知の技術を含む種々の技術が、このようなデータを生成するために使用され得る。本明細書中では、少なくとも一つの処理変数または他の処理パラメタ上で統計処理モニタを実行する機能性を説明するために、用語統計処理モニタSPMブロックが用いられ、該デバイス内またはデータが収集されるデバイス以外において任意の所望されるソフトウェア、ファームウェア、またはハードウェアによって実行され得る。一般に、SPMは、デバイスデータが収集されるデバイス内に配置されるので、SPMが量的に勝り、質的により正確な処理可変データを取得できることが理解されよう。これによって、一般に、SPMブロックは、処理可変データが収集されるデバイス以外に配置されたブロックより、収集された処理可変データに関してより良好な統計計算を求めることが可能である。他の例としては、トランスミッタと関連するものとして示されている図2のブロック82は、プラント内のラインが閉塞されたかを判断するために、該トランスミッタによって収集される処理可変データを解析する閉塞ライン検出ユニットを有することもある。更に、ブロック82は、例えば、収集されたデータの平均値、メジアン値、標準偏差値などを求めるために、該トランスミッタ内の処理可変データまたは他のデータを収集し、該収集されたデータ上で一つ以上の統計的計算を実行し得る四つの統計処理モニタSPMブロックまたはユニットSPM1~SPM4のセットを含む。所望されれば、上記に参照されている米国特許第6017143号に記載されているように、ブロック80および82の基底動作が実行またはインプリメントされてもよい。ブロック80および82は、4つのSPMをそれぞれ含むように示されているが、ブロック80および82は、統計データを収集するとともに求めるために、他の任意数のSPMブロックを有することもできる。同様に、ブロック80および82がプラント10内で特定の状態を検出するための検出ソフトウェアを含むとして図示されているが、このような検出ソフトウェアは有する必要はない。更にまた、本明細書中に説明されているSPMブロックがADBのサブエレメントであるとして図示されているが、そうではなく、デバイス内に配置されるスタンドアローンブロックであってもよい。また更に、本明細書中で説明されているSPMブロックは、公知のFoundationFieldbusSPMブロックであってもよいが、本明細書中では、用語統計処理モニタSPMブロックは、処理可変データなどのデータを収集し、平均値、標準偏差値などの統計的測定値を求めるために該データ上でいくつかの統計的処理を実行する、任意のタイプのブロックまたはエレメントを言及するために用いられる。これによって、この用語は、これらのエレメントが、機能ブロックや他のタイプのブロック、プログラム、ルーチンまたはエレメントの形態を取っていようといまいと、および、これらのエレメントが、FoundationFieldbusプロトコル、または、PROFIBUS、WORLDFIP、Device-ネットワーク、AS-Interface、HART、CANなどの他のプロトコルに追従していようがいまいが、この機能を実行するソフトウェア、ファームウェアまたは他のエレメントを網羅するように意図されている。一つの実施の形態において、ADB80および82内の各SPMブロックは、稼動中であってもよいし、休止中であってもよい。稼動中SPMブロックは、処理変数または他の処理パラメタを現在モニタしているブロックであるが、休止中SPMブロックは、処理変数を現在モニタしていないブロックである。概して、SPMブロックは、デフォルト値によって休止中となり、これにより、一般に、各SPMブロックが、処理変数をモニタするためには個別に構成されなければならない。図3は、デバイスに対する現在SPM構成を記述し変更するために、ユーザ、エンジニアなどに提示され得る、例示的な構成ディスプレイ84を示す。ディスプレイ84において示されるように、この特定のデバイスのためのSPMブロック1、2および3の全てが構成されているが、SPMブロック4は、構成されなかった。構成されたSPMブロックSPMl、SPM2およびSPM3の各々は、ブロックタグBlockTagによって示されるようなデバイス内の特定のブロック、ブロックタイプBlockType、ブロック内のパラメタインデックスParameterIndex即ち、モニタされているパラメタ、および該SPMブロックのモニタ機能性を示すユーザコマンドUserCommandに関連している。また更に、各構成されたSPMブロックは、決定された統計パラメタが比較される一組の閾値を含み、これらの閾値は、例えば、平均限界値、信号において過多の変動値を指定する高変動限界値、および信号における過少の変動値を指定する低ダイナミック値を含む。本来、平均値における変化を検出することは、処理が上下にドリフトしていることを示し、高い変動値を検出することは処理内のエレメントが大きくなった振動によって生じるノイズなどの予期しなかったノイズを経験していることを意味し、低い変動を検出することは、処理信号がフィルタリングされつつあること、または、エレメントが、例えば、スタックバルブなどのように予期せぬうちに休止することを意味する。また更に、平均値および標準偏差値などのベースライン値がSPMブロックごとに設定されてもよい。これらのベースライン値は、デバイス内で限界値を満たしているかあるいは超えているかを判断するために使用され得る。モニタリングを開始するためにユーザコマンドを受信したことから、図3のSPMブロック1および3はともに稼動中である。一方、SPMブロック2は、アイドルIdle状態にあるので、休止中である。また、この例において、SPM能力はボックス86によって示されるように、デバイス全体に対してイネーブルであり、ボックス88によって示されるように、5分毎にモニタまたは計算されるように設定される。当然、許可されたユーザは、デバイス内の他の機能ブロックなどの他のブロック、該デバイス内の様々なブロックに関連する他のパラメタをモニタするためだけでなく、他の閾値、ベースライン値などを有するために、該デバイス内のSPMブロックを再構成することができる。図3のディスプレイ84には、いくつかの統計的モニタブロックが示されているが、他のパラメタも同様に、または、他のパラメタも加えて、モニタされてもよい。例えば、図2に関して説明されるSPMブロックまたはADBは、処理に関連する統計パラメタを計算し、これらの値における変化に基づいて、いくつかの警告を引き出す場合もある。例えば、FieldbusタイプのSPMブロックは、処理変数をモニタし、そのモニタリングに関連する15の異なるパラメタを提供し得る。これらのパラメタは、ブロックタグ、ブロックタイプ、平均値Mean、標準偏差値StandardDeviation、平均変化値MeanChange、標準偏差変化値StandardDeviationChange、ベースライン平均値BaselineMean、ベースライン標準偏差値BaselineStandardDeviation、高変動限界値HighVariationLimit、低ダイナミック限界値LowDynamicsLimit、平均限界値MeanLimit、状態値Status、パラメタインデックス、タイムスタンプTimeStamp、およびユーザコマンドなどを含む。現在、二つの最も有用なパラメタは、平均値と標準偏差値であると考えられる。しかしながら、しばしば有用である他のSPMパラメタは、ベースライン平均値、ベースライン標準偏差値、平均変化値、標準偏差値、および状態値である。もちろん、SPMブロックは、任意の他の所望される統計測定値やパラメタを決定することができるとともに、特定のブロックに関連する他のパラメタをユーザまたは要求アプリケーションへ提供することができる。このように、SPMブロックは本明細書中において説明されているブロックに限定されない。再び図2を参照すると、フィールドデバイス内のSPMブロックSPM1乃至SPM4のパラメタは、バスまたは通信ネットワーク76およびコントローラ60を介して、例えば、ワークステーション74に対しての外部クライアントにとって利用可能とされ得る。その以外またはそれに代わるものとして、ADB80および82内のSPMブロックSPM1乃至SPM4によって収集されあるいは生成されるパラメタや他の情報は、例えば、OPCサーバ89を介して、ワークステーション74にとって利用可能とされ得る。この接続は、一つ以上の携帯デバイスなどのワイヤレス接続、ハードワイヤード接続、断続接続、または、任意の所望されるあるいは適切な通信プロトコルを用いた任意の所望される通信接続でもあってもよい。当然、本明細書中に記載されている通信接続のいずれかは、共通または一定のフォーマットにおいて、異なるタイプのデバイスから受信されたデータを統合するために、OPC通信サーバを使用してもよい。また更に、生の処理可変データなどの生データを収集または生成するデバイス以外で、統計処理モニタを実行するために、ホストデバイス、フィールドデバイス以外のデバイス、または、他のフィールドデバイス内に、SPMブロックを配置することが可能である。このように、例えば、図2のアプリケーション38は、例えば、OPCサーバ89を介して、生の処理可変データを収集するとともにその処理可変データについての平均値、標準偏差値などのいくつかの統計測定値またはパラメタを計算する一つ以上のSPMブロックを含み得る。これらのSPMブロックは、一般に、該データを収集するデバイス内に配置されていないため、これにより、該データに対する通信要件に応じた統計的計算を実行するために十分な処理可変データを収集することが一般には不可能であるが、該SPMブロックは、デバイスに対する統計パラメタを決定する際、または、SPM機能もなく支援もしないデバイス内では処理変数を決定する際に、有用である。更に、技術が進歩するにつれて、経時的に、ネットワークの使用可能な処理量スループットが増加し、生データを収集するデバイス内に配置されてなかったSPMブロックは、統計的計算を実行するためにより多くの処理可変データを収集することが可能である。このように、SPMブロックによって生成されると記載された任意の統計的測定値またはパラメタが、ADB80および82内のSPM1乃至SPM4ブロックなどのSPMブロックによって、または、他のフィールドデバイスを含むホストまたは他のデバイス内のSPMブロックにおいて、生成され得ることが以下の記載において理解されよう。処理プラントにおいて統計データ収集ブロックまたはSPMの数が大きくなるので、データをトレンド傾向付けし更なるデータ凝集および意思決定のためのエキスパート専門家システムへ検出結果を提供するためには、異なるデバイス内のSPMブロックから統計パラメタデータを集める自動機構を有することが役に立つ。実際、現時点では、大規模な処理に対して統計処理データの全てを目視することは非常に面倒であり、冗長である。今のところ、関心がもたれるSPMパラメタの各々を個別にモニタするOPCクライアントを作成しなければならず、これを行うためには、SPM収集に用いられる全てのデバイスを個別に構成しなければならない。上記のように、統計データのこの構成および目視は、非常に手間がかかり、人的エラーが発生しやすくなる。該構成およびデータ収集アプリケーション38は、例えば、バルブ、トランスミッタなどのデバイスにおいてSPMブロックを自動的に構成するように、および、処理の動作中に該処理が使用できるSPMデータをこれらのSPMブロックから収集するように、用いられる。図4は、SPMデータを収集するために処理プラント内でデバイスを構成し、該処理プラント10の動作中にデータを自動的に収集するためにアプリケーション38によって使用され得る例示的な技術を記述するフローチャート90を示す。図4において、円は、アプリケーション38によって処理プラントにおいて実行されるアクションを示すが、四角形は、該アプリケーション38によって使用されるか、または、生成される、オブジェクトやアイテムを示す。この例は、Fieldbusプロトコルを使用するとともに統計データを収集するFieldbusブロックを有する、特定のタイプのトランスミッタからのSPMデータの収集について説明するが、この技術または同様の技術が、他の通信および機能ブロックプロトコルを用いた他のデバイスから、あるいは、機能ブロックプログラミングパラダイム以外のプログラミングパラダイムを使用するデバイス内の他のデバイスまたはエレメントから、統計データまたは他のパラメタを収集するために使用され得ることが理解されよう。いずれにしても、第1のブロック92において、アプリケーション38は、ADBなどの統計データ収集ブロックを含む処理プラント内でデバイスのリストを決定するために処理コントロールネットワーク例えば、処理プラントの階層をスキャンする。ブロック92は、他のタイプの統計データ収集ブロックを検索してもよいし、ADB内のFieldbusタイプのSPMに加えて、該他のタイプの統計データ収集ブロックを検索してもよいし、また、方法は、FieldbusADBによる使用に限定されないし、FieldbusADB内のSPMブロックにも限定されないのであるが、説明の便宜上、上記のように、統計データ収集ブロックは、FieldbusADB内のSPMブロックの形態を取るものと仮定されている。一つの実施の形態において、図2のサーバ89などのOPCサーバは、アプリケーション38などのクライアントがコントロールおよびデバイス情報にアクセスできるようにするために使用され得る。例えば、OPCオートメーション2.0プロダクトは、OPCサーバのコンテンツをブラウジングするために標準的な方法を提供し、ほとんどのブラウザ方法が、OPC階層を自動的に走査して、ADBを含むデバイスを見つけるために使用され得る。更に、新しいOPCスペックは、データを統合するとともに該データをウェブ環境で使用できるようにするために使用され得るXML定義を含む。図5は、OPCサーバによって作成される例示的なプラント階層94の一部を示し、該OPCサーバによってスキャンされている処理プラントのデバイスおよび他のエレメントを示す。階層94の最上層は、モジュールModulesおよびIOと呼ばれるノード96および98をそれぞれ含み、モジュールノード96はコントロール戦略情報を含み、IOノード98はハードウェアおよび/またはデバイス情報を含む。図5の例示的な階層に示されるように、IOノード98は、コントローラCTLR、カードCおよびポートPに関連するサブノードを含み、この例において、ポートPは、コントローラネットワークに実際に存在するFieldbusセグメントに関連している。さらに、階層の更に下方では、Fieldbusデバイスがそれぞれのポートの下に列挙されている。図5の例において、ADBを含む各Fieldbusデバイスは、デバイスの下のTRANSDUCERトランスデューサ800またはTRANSDUCER1300という名のノードを含む。Rosemountローズマウント3051FデバイスにおいてADBはTRANSDUCER800と称されるが、Rosemount3051SにおいてADBはTRANSDUCER1300と称される。図5の階層には、このようなTRANSDUCER800と称されるノード100が示されている。ADBノード100は、関心が持たれる診断情報を含む。この特定の場合において、アプリケーション38は、Rosemount3051FデバイスにおいてADBに関連するエレメントのいくつかを示すために、図5の階層において拡張された、ADBノード100内の統計処理モニタSPMパラメタに関心を持つ。当然、名称TRANSDUCER800およびTRANSDUCER1300は、ある知られている製造業者によって提供される公知の機能ブロックの名称の単純な例である。他のADBブロックまたはSPMブロックは、他の名称を有してもよいし、および/または、名称は、OPCを利用するシステム以外のシステムにおいて異なり得る。他のインプリメンテーション実装において、さまざまな名称は、二、三、例を挙げると、今後開発される、および/または、他の製造者によって製造される、および/または、FoundationFieldbusスペックに記載されているような他のTRANSDUCERブロックのADBブロックまたはSPMブロック、機能ブロックなどに対応する名称であってもよいし、Profibus、HART、CAN、AS-Interface、HTML、XMLなどのプロトコルにおける任意のエレメントなどの任意の他のスマート通信プロトコル例えば、ディジタルプロトコルにおけるブロックまたは他のソフトウェアエレメントであってもよい。ADB、従って、該ADB内のSPMブロックを発見するために、ブロック92図4は、プラント内の全てのADBを含むデバイスを探すためにOPC階層94を自動的に走査または検索する。当然、ブロック92は、該ブロック92がADBを含むデバイスを最良の方法で見つけるために予めプログラミングされ得る。本明細書中に記載の方法は、DELTAVTMOPCツリーに基づいているが、該方法の改良は、他のOPCサービスだけでなく、他のタイプの目視ツールによって生成されるプラント階層に対して行われてもよい。階層またはツリー94を検索するとき、一般に、スピードと堅牢性ロバストネスの間にトレード-オフ二律背反がある。特に、階層94を検索することが、一般に、ADBを有するデバイスの全てを見つける時にもADBを有するデバイスのみを見つける時にも100信頼できる方法ではない。一般に、ADBを有するデバイスを見つける方法が正確であればあるほど、該方法の進行が遅くなる。例えば、別の製造者が、3051Fトランスミッタ内のADBブロックと同じ名称を有するブロックを含むOPCツリー94に出現するデバイスを有すれば、該階層を検索することは、このデバイスを、ADBを有するものとして、偽に検出することになる。逆に、ブロック92が、実際のADBを含むノードだけを探し出すことを確実にするために、過剰な量のサブノートを検索してこの問題を回避しようとすれば、該方法の速度は低下する。いずれにしろ、一つの実施の形態において、ブロック92は、いくつかのデバイスにおいてADBと関連すると分かっている名称を有する各ノードを探し出すために、階層またはツリー94内のすべてのノードを検出し得る。大規模な処理プラントにおけるような場合においては、かなり長い検索時間が掛かるが、処理プラントにおいて、ADBの各々、従って、SPMの各々を探し出すためには、これが、最も正確な方法である。一方、TRANSDUCER800またはTRANSDUCER1300などの公知の統計モニタブロックに関連する名称、あるいは、公知の統計モニタブロックを表示するためにいくつかのデバイスの製造者によって使用されることが分かっている任意の他の特定の名称を含むノードに到達するかあるいは該ノードを見つけるまで、ブロック92は、階層の下層へと検索し得る。このようなノードが見つかった場合、次に、該ノードに関連付けられる親ノードが、ADBを有するデバイスとして検出され得る。該方法は、特定のOPC階層またはツリー内の全てのノードを検出するほど堅牢ではないが、処理は速い。とはいっても、他の製造者が、TRANSDUCER800と名付けられたOPCノードを有するデバイスを作製する場合、この方法でも、ADBを有するものとして他のデバイスを偽に検出する。あるいは、ブロック92は、ADBと一意的に関連付けられ、または、ADBを表していることが分かっているデバイス内で更なるアイテムに対して、知られているADBに関連する名称を有することを該ブロック92が発見する各ノード下で検索し得る。このように、ADBを特定するために少なくとも一つの製造者によって使用されることが分かっている名称を有するノードを探し出した後、ブロック92は、アイテムCharacteristic/BLOCKTAG.STRING特徴/ブロックタグ.ストリングが、値ADVANCEDDIAGNOSTICS高度診断を有するかを判断するためにサブノードを検出する。この例において、Characteristic/BLOCKTAG.STRINGアイテムは、ADBを有するデバイスに対してのみ、ADVANCEDDIAGNOSTICSの値を有する。この方法は、ADBを有するデバイスのみを探し出す際に非常に堅牢であるが、OPCサーバを介してデバイスから値を読み出すことを必要とするので、OPC階層をブラウジングするより相当に長い時間を要する。従って、この方法は、正確ではあるが、いくつかの状況に対しては非常に低速である。速度とロバストネスの間でミドルグラウンド中間位置を提供するOPCツリー94を検索するために、図4のブロック92によってインプリメントされ得る他の方法は、ADBに共通して関連する名称を有するサブノードに対して、ADBに関連することが共通して分かっている名称を有するノード下で、OPC階層を検索することを含む。例えば、この方法は、OPCツリー94図5のトップからスタートし、IOノード98を検索し得る。次に、方法は、IOノード98下で全てのサブノードを再帰的に検索し得る。TRANSDUCER800またはTRANSDUCER1300と名付けられたサブノードまたはADBなどの統計モニタブロックに関連付けられることが分かっているいくつかの他の名称が見つかった場合、次に、該方法は、このノードが、SPMACTIVEアクティブと名づけられたサブノードまたは具体的に統計モニタブロックと関連する任意の他のサブノードを有するか否かをチェックする。例えば、TRANSDUCER800ノード下でSPMACTIVEが見つけられた場合、次に、ブロック92は、TRANSDUCER800ノードの親ノードを、ADBを含むデバイスとして、検出する。当然のことながら、ブロック92は、ADBを有する従って、SPMを有するデバイスを検索するために、これらの技術のいずれか、これらの技術の任意の組合せ、または任意の他の所望される技術を使用することができる。例えば、一つのインプリメンテーションは、少なくとも一つの製造者のデバイスによってインプリメントされると分かっている少なくとも全てのADBを識別しようとするが、処理プラント内の全てのADBを識別することが可能である場合もあれば、不可能な場合もある。他の例としては、いくつかの異なる製造者のデバイスによってインプリメントされることが分かっている全てのADBを識別しようとする試みもある。更に、このスキャンステップは、OPC階層を用いて実行されるものとして、即ち、OPCサーバによって生成されるものとして、記載されているが、この方法は、コントローラ、処理プラント内で構成階層を格納するデータ履歴、デバイス階層を格納するワークステーションなどの他のデバイスによって生成される階層上で用いたり、使用されたりする。このように、他のインプリメンテーションは、OPCサーバおよび/またはOPC階層を使用する必要はないが、公知の、または、今後開発される、コンピュータデバイス、通信プロトコル、および階層プロトコルを含む、多種多様の他のコンピュータデバイス、通信プロトコル、および階層プロトコルを使用することもできる。他のインプリメンテーションは、例えば、ウェブサーバ、XML、および/または、プロプラエタリ演算装置、およびプロトコルを使用し得る。ADBを含むデバイスを探し出したり検索したりする処理において、ブロック92は、図4のボックス108によって示されるように、ADB、SPMブロック、または他のタイプのデータ収集ブロックを有するものとして、検出されたデバイスのリストを格納してもよい。所望されれば、ボックス108に挙げられているデバイスがそれらの階層に応じたツリービューディスプレイで表示されてもよい。このような階層的なディスプレイ110の例は、図6に示されている。お分かりのように、図6のビューにおいて表示された階層110は、コントロールディスプレイ内の全てのデバイスが一般にADBを含むとは限らないが、コントローラによって生成されるコントロールネットワークディスプレイ下で表示される階層のサブセットである。事実、図6のビュー110は、ADBを含むデバイスのみを含むコントローラ階層を実際にコピーしたものである。お分かりのように、図6のディスプレイは、CTLR-002EC6と名付けられたコントローラの入力/出力デバイスIO1のカードCOlのポートPOlに接続されたデバイスPT-101およびPT-102と、CTLR-002EC6と名付けられたコントローラの入力/出力デバイスIO1のカードC01のポートP02に接続されたデバイスPT-103、FT-201およびFT-202がそれぞれADBを有することを示す。デバイスからSPMパラメタのいずれかを読み出すため、このパラメタのOPCアイテムIDを知ることが一般的に必要とされる。一般的には、即ち、FieldbusSPMブロックの場合、SPMパラメタに対するOPCアイテムのIDは、アイテム指定子が続くDeviceデバイスIDを含む。DeviceIDを探し出すために、ADBを含むと判断されたデバイスノードごとに、サブノードSPMACTIVEを見つけることもある。次に、ブロック92は、リーフ葉CVに対してOPCアイテムIDを得ることもある。例えば、OPCアイテムIDは、DEVICE0011513051022201100534030003969800SPMACTIVECVである。次に、DeviceIDは、OPCアイテムIDからサフィックス接尾部SPMACTIVE.CVを引いたものである。従って、この例では、DEVICE0011513051022201100534030003969800である。当然ながら、これは、OPCシステムにおいてDeviceIDを決定する一つの方法にすぎず、他の技術を代わりに使ってもよい。いずれにせよ、ブロック92がADBを有するデバイスを決定するために階層をスキャンした後、アプリケーション38は、これらのデバイスの各々に対して、DeviceTagデバイスタグ、DeviceID、DeviceLocationデバイス位置を知っているし、または、容易に決定することができる。ADBを有する五つのデバイスを含む単純なシステムに対するこのデータの例が以下の表に示されている。再び図4を参照すると、ブロック114は、ボックス108に格納されたデバイスのどのデバイスが統計処理モニタを実行するようにすでに構成されているかを判断し得る。この機能を実行するために、ブロック114は、該ボックス108に格納されたデバイスの各々に対してOPCサーバから、値SPM_ACTIVE.CVを読み出してもよい。例えば、上記のテーブル内のトランスミッタPT-101については、ブロック114が、OPCアイテムDEVICE00115130510222011005340300O3969800SPMACTIVECVを読み出し得る。このOPCアイテムは、0または255の値を取ることもできる。FieldbusSPMブロックの場合、値がゼロの場合、SPMブロックは、このデバイスに対してディセーブルであり、値が255である場合、SPMブロックは、このブロックに対してイネーブルである。SPMがデバイスごとにイネーブルであるかをチェックする場合、ブロック114は全てのデバイスを二つのカテゴリ、即ち、SPMがすでに構成されているデバイスとSPMがまだ構成されていないデバイスへ分割することができる。デバイスのこれらのカテゴリまたはリストは、図4のボックス116とボックス118によって示される。ブロック114が、SPMがボックス108に挙げられたデバイスの各々においてイネーブルであるか否かを決定した後、ブロック120は、SPMがイネーブルであるデバイス、即ち、ボックス116に列挙または格納されたデバイスの各々の内部のSPMブロックの各々に対して状態をチェックすることができる。基本的に、ブロック120は、SPMがイネーブルであるデバイス内の各SPMブロックが現時点で処理変数をモニタするように構成されているか否かを判断し、そうである場合、どの処理変数がモニタされているかを判断するために、このステップを実行する。この例において、SPMブロックの状態を読み出すことによってSPMブロックが現時点で処理変数をモニタしているか否かを判断することが可能である。FieldbusSPMブロックにおいて、OPCサーバからのSPM[n]STATUS.CVアイテムを読み出すことによって、状態がチェックされ得る。このように、例えば、上の表のデバイスPT-101のSPMブロック1に対する状態を読み出すために、ブロック120は、OPCアイテムIDDEVICE00115130510222011005340300O3969800SPM1STATUSCVを読み出してもよい。概して、状態の値は0から255に及ぶ8ビット数である。この状態は、オンまたはオフされ得る8つの異なるビットの組合せである。これらのビットは、以下の通りであるInactive休止1、Learning学習2、Verifying確認、MeanChange平均変化値値セクション318を含む。さらにまた、ボックス320は、状態記述の各セットの間で用いて、IF状態の全体を定義するために状態記述が論理的に組み合わされる方法を定義するように、ユーザがAND演算子やOR演算子などのブール論理演算子を選択したり定義したりすることを可能とする。図38では、選択される可能性のあるものとしてANDおよびORのブールの演算子のみが図示されているが、ユーザがより複雑なルールを打ちたてることができるように、任意の他のブール演算子または他の所望のタイプの演算子も提供することができる。さらにまた、一組のチェックボックス322および324は、状態記述のグループ化を定義するために使用され得る。例えば、チェックボックス322前カッコの前の選択は、一組のカッコ内で定義される新しいセットの状態記述の始まりを示す一方、チェックボックス324の選択は、一組のカッコ内の一組の状態記述の終わりを示す。お分かりのように、一組のカッコ内の状態記述は、異なるセットのカッコ内で状態記述または状態記述のグループが組み合わされる前にそれらの間でブール演算子を用いて組み合わされる。このように、図38の例において、1PT-101デバイスのSPMブロック1によって測定された平均値が102以下であり、且つANDPT-102デバイスのSPMブロック3によって測定された標準偏差値が1.234以上である場合、又はOR2FT-201のデバイスのSPMブロック2の状態パラメタが平均変化値に等しく、且つANDFT-201デバイスのSPMブロック4の状態パラメタが平均変化値に等しい場合、アクションセクション306で定義されるアクションが適用される。図38に示されるように、アクションセクション306はユーザ指定警告名セクション330、重大度定義セクション332および記述セクション334を含む。警告名セクション330は、状態セクション304が真である場合に生成される警告に関連するあるいはこれに付与される名称を定義し、重大度定義セクション332は、故障、メンテナンス、通信または他のタイプの警告などの警告の重大度を定義し、記述セクション334は、該警告のユーザまたは目視者ビューワに提供され得る警告に関連する記述を提供する。もちろん、図38のアクションセクション306は、生成される警告を定義する一方、該アクションセクション306が、該プラント内でデバイス、装置などの稼動の停止、該プラント内のコントロールの設定の切替えや変更、該プラント内でコントローラへ新しい設定ポイントまたは制御条件を提供することなどの他の取るべきアクションをその他にまたはそれに替えて定義することができる。図37のルールデータベースに一組のルールが作成され格納された後、エキスパートエンジン開発および実行システム42が、処理プラントの稼動中に該処理プラント内のSPMブロックによって返されたデータや異常状態に基づいて処理の異常を自動的に検出するために使用される。もちろん、システム42は、ルールデータベース292内のルールに基づいて処理プラント内の異常状態を検出するために処理プラントの稼動中に連続的にあるいは定期的に動作または実行してもよいことが理解されよう。所望されれば、システム42は、ユーザに、図37のルールエンジン290の現時点の構成および状態についての情報をもたらす目視スクリーンを提供する。このようなディスプレイの例が図39に示されている。特に、図39のディスプレイ340は、テストまたは比較状態354、および任意の処理変数またはSPMパラメタであってもよい更なるエレメント356を含む。これらのエレメントの各々は、所望に応じて、手動的に記入されてもよいし、プルダウンメニューから選択されてもよい。同じく、図38を示すスクリーンと同様に、ブール演算子は、各状態記述351を組み合わせるために指定されてもよいし、結果セクション360は、定義されたIF記述ステートメントが真である場合に、警告の一部としてユーザへ提供される警告名、重大度およびメッセージを指定するために使用され得る。図41は、さまざまなボタン374の選択によって組み立てられ得るIFセクション372を含む、より高度なアドバンスドタイプのルール定義子370を示す。ボタン374は、セクション372においてより複雑なIF記述を作成する際に使用される、ADBパラメタ、SPMパラメタ、処理変数PV状態、パラメタ等のタイプまたは特定のパラメタ、ブール演算子、数字および数学的に同等の記述を含み、あるいは、これらをユーザが指定することを可能にする。警告名定義セクション、重大度定義セクション、およびメッセージセクションを含むセクション376は、該ルールによって生成される警告または報知を定義するために使用され得る。もちろん、アプリケーション40は、現行のまたは予測される異常事態を検出するためにルールエンジン290によってインプリメントされるルールを定義する任意の他の方法を提供することができる。また更に、図38、図40、および図41を示すスクリーンは、IF-THENタイプのブールのルールを定義することを可能とするために使用され得るが、他のタイプのルールをこれ以外にまたは代替的に定義されてもよい。例えば、図38、図40、および図41を示すスクリーンが変更されてもよいし、あるいは、スプレッドシートタイプのルール例えば、マイクロソフト社からのエクセル商標のスプレッドシートソフトウェアによって提供されるものと同様のルール、ファジー論理ルール、パラメタ間の数学的な関係の定義、相関値の生成、パラメタのフィルタ例えば、低域パスフィルタ、広域パスフィルタ、帯域パスフィルタ、有限インパルス応答FIRフィルタ、無限インパルス応答IIRなどを可能とするために提供され得る。動作中、図37のルールエンジン290は、SPMブロックの状態をルールデータベース292内の定義されたルールと合致させるために、多数の異なる方法を使用することができる。ルールデータベース292内のルールがあまり複雑ではない場合、エンジン290は適切な論理ハンドラによって単純にプログラムされる。しかしながら、これらのルールのいくつかが非常に複雑な場合、すでに開発されているエキスパートシステムを使用することも有利である。お分かりのように、モニタ処理がスタートすると、すべてのルールが任意の適切なインターフェースを介してルールエンジン292へ送られる。その後、図4のブロック132または134によって検出されるように、SPMの状態が変化する度に、これらの状態がルールエンジン292へ送られる。インターバルごとに、ルールエンジン292は、これらのルールのいずれかの状態が合致するかを判断する。これらのルールのどれかが満たされると、ルールエンジン290は主要アプリケーションへそのことを通知し、これによって、警告はユーザに表示され、合致した特定のルールのアクション記述に基づいて、いくつかの他のアクションを取ることができる。図42は、処理プラントの一部と報知ディスプレイ382からなる例示的なスクリーンディスプレイ380を示す。ルールエンジン290は、一つ以上の適切なルールが満たされた場合に該報知ディスプレイ382が表示されるようにする。該報知ディスプレイ382は、示唆された補正アクション、プラント手順へのリンク、性能および/または品質データを目視するためのリンクなどを含んでもよい。スクリーンディスプレイ380は、該報知に関連付けられるデバイス、ループ、測定値などをあらわすためにディスプレイの部分の周辺にハイライト383を含む。例えば、ルールエンジン290は、該エンジン290に報知ディスプレイ382とハイライト383を表示させる目視アプリケーション40へデータを送信してもよい。図43は、警告および/または報知情報を含む、処理プラントの一部である他の例示的なスクリーンディスプレイ384を示す。特に、座標385は、該警告/報知に関連する種々の統計パラメタを表示する。スクリーンディスプレイ384は、報知に関連する情報を表示する情報ウィンドウ386および387を含んでもよい。情報ウィンドウ386および387は、例えば、カラー符号化を介して異なるレベルの重要性を示す。ルールエンジン290は、一つ以上の適切なルールが満たされた場合は、ウィンドウ385、386および387を表示させる。例えば、ルールエンジン290は、該エンジンが、ウィンドウ385、386および387を表示させる目視アプリケーション40へデータを送信してもよい。図44は、警告/報知情報を含む、処理プラントの一部であるまた他の例示的なスクリーンディスプレイ390を示す。図45は、警告および/または報知情報を含む、処理プラントの一部である、更に他の例示的なスクリーンディスプレイ395を示す。ルールエンジン292が上記に説明されたが、他のタイプの解析エンジンを、それ以外に、または、それに代わるものとして、使用することができる。使用され得る解析エンジンのタイプの他の例としては、数学的演算エンジン例えば、WolframResearchウルフラムリサーチのMathematicaRマセマティカ登録商標、ファジー論理解析エンジン、パターンマッチングエンジン、ニューラルネットワーク、回帰解析エンジンなどを含む。上記のデータ収集技術、可視化技術およびルールエンジン技術は、図1のプラント構成におけるSPMデータを収集し、目視し、処理するために使用され得るが、他の構成においても使用され得る。例えば、これらの技術は、プラント階層を獲得し、所与のプラントにおいてデバイスを発見し、ADBおよびSPMデータの能力を有するデバイスを見分けるためにソフトウェアが種々のサーバ例えば、OPCサーバ、ウェブサーバなどにアクセスを有するPCベース環境例えば、DeltaV、AMS、およびオベーションにおいて使用され得る。他には、OPCサーバで組み立てられ、フィールドデバイスに直接アクセスする、Rosemount3420のような、フィールドハード化デバイスにおいて直接使用される。この場合、デバイスそれ自体が、データコレクションおよびルールエンジンアプリケーションを格納し、ユーザワークステーションなどの個別のプラットフォームを必要とせずに、これらのアプリケーションを実行することができる。更に、さまざまのケースにおいて、本明細書中に記載されている可視化アプリケーションまたはコンポーネントは、ユーザが目視するために収集されたSPMデータ、警告などを得るためにスタンドアローンデバイスに接続され得る、携帯デバイス、パーソナルアシスタントなどの他のデバイスにおいて実行またはインプリメントされ得る。同様に、データ収集および目視アプリケーションは遠隔目視デバイスを介してフィールドデバイスまたは他のデバイスにアクセスしてもよい。このように、このソフトウエアは、例えば、EmersonProcessManagementによって提供されるアセットポータルとAMSウェブAssetPortalandAMSwebなどのウェブサーバに常駐、あるいは、これらを介して、アクセス可能となる。また、図2において、OPCサーバは、SPMブロックを含むフィールドデバイスから分離しているものとして示されているが、OPCサーバまたは他のサーバがフィールドデバイス自体の一つ以上に配置されてもよい。同様に、異常事態防止システムのデータ収集アプリケーション38およびルールエンジン42は、例えば、ADBまたはSPMブロックを有するデバイス内で、SPMデータを生成する、ADBおよび/またはSPMブロックと同じデバイス内に配置されてもよい。この場合、異常事態防止システム35は、OPCインターフェースOPCインターフェースをいまだに使用している場合もあるがを必要とせずに、統計的なデータ収集ブロックと同じデバイスにおいて動作したり、実行されたりする。所望されれば、アプリケーション38および42によって生成されるSPMデータまたは警告、報知などは、コントローラ接続を介して、ワイヤレスに、携帯デバイスを介して、などの、フィールドデバイスから一般的にアクセスされるようなやり方でアクセスされ得る。図46は、SPMブロックおよび異常事態防止機能を支援するために、分散コントローラ、ホストまたは他のかなり以前から使用されている従来のユーザインターフェースの使用を必要としない処理プラントにおいて異常事態防止をインプリメントする他の方法を示す。図46のシステム400において、異常事態防止アプリケーション35および/またはアプリケーション38乃至42が、ホストワークステーションまたはパーソナルコンピュータ以外のデバイスにおいて格納され得る。図46の例示的なシステム400は、例えば、Rosemount3420デバイスであってもよいインターフェースデバイス410に接続されたFieldbusフィールドデバイスとして図示されているが他のタイプのデバイスであってもよい一組のフィールドデバイス405を含む。この場合、パーソナルコンピュータではないインターフェースデバイス410は、上記の異常事態防止システム35の機能のいくつかまたは全てを含むこともある。特に、インターフェースデバイス410は、フィールドデバイス405種々の異なるタイプのフィールドデバイスであってよいから分配されたデータを受信し編成するためにブラウザ412を含むこともある。所望されれば、ブラウザまたは通信デバイス412は、OPCブラウザを含むこともある。データ収集アプリケーション38またはその一部は、SPMブロックを有する任意のフィールドデバイスに対して、上記のように、SPMデータを含むフィールドデバイス405からデータを収集するために、インターフェースデバイス410のプロセッサ内に格納され、実行される。更に、インターフェースデバイス410は、SPMブロックや機能性を含まないフィールドデバイスなどのフィールドデバイスの一つ以上から処理可変データを直接収集し、上記のように、SPMパラメタを生成するために、一つ以上のSPMブロック414を含んでいてもよい。このように、インターフェースデバイス410に格納され、実行されるSPMブロック414は、フィールドデバイス405のいくつかの内部においてSPMブロックの欠落を補償することが可能であり、SPMブロックやSPM機能をそれら自体が支援しないフィールドデバイスに対して、SPMデータを提供するために使用され得る。更に、ルールエンジンアプリケーション42または、図37のルールエンジン290などのルールエンジンの一部がインターフェースデバイス410によって格納され、実行されてもよいし、データベース43も、同様に、インターフェースデバイス410内に配置されてもよい。インターフェースデバイス410は、ユーザが目視するためのデバイスに対して、SPMデータや、警告、データ座標などのSPMデータから展開されたデータなどを提供するために、2回線、3回線、4回線などの接続などのハード接続を介して、ホストワークステーション430などの他のデバイスと通信し得る。更に、図46に示されるように、インターフェースデバイス410は、一つ以上のワイヤレス通信接続を介して、ウェブブラウザ440、および電話、パーソナルデータアシスタントPDA、ラップトップコンピュータなどの携帯コンピュータデータデバイス450に接続され得る。この例において、目視アプリケーション40の一つ以上がウェブブラウザ440または携帯演算デバイス450のホストアプリケーション430などの他のデバイスにおいて格納され実行され、これらのアプリケーションは、上記のいずれかのような、任意の方法で処理および目視するための所望されるデータを得るために、インターフェースデバイス410と通信することもできる。所望されれば、デバイス430、440および450は、インターフェースデバイス410によってインプリメントされるルールをユーザが生成することを可能とする為に、図37のルール定義アプリケーション298を含み得る。同様に、図46に示されるように、インターフェースデバイス410からのデータは、ウェブブラウザ460によってホスト430から間接的にアクセスされてもよいし、任意の所望されるウェブ接続を介して、他のユーザへ提供されてもよい。当然のことながら、インターフェースデバイス410は、ウェブサーバを含むこともできるし、OPC、Modbus、イーサネット登録商標、HTML、XMLなどの任意の他のプロトコルを用いたデバイス430、440、450および460などの任意の他のデバイスと通信することもできる。図47は、図46のそれと類似したものでもよいしあるいは同一であってもよいインーフェースデバイス410が、熱交換器515を構成する一組のフィールドデバイス510と処理コントロールシステム520の間で接続されている、更なる処理プラント構成500を示す。ここで、図46のデバイス410のアプリケーションと機能性の全てを含み得るインターフェースデバイス410が、ホスト530へ目視するためのデータを提供し得て、ルールエンジンによって生成された警告または報知をコントローラシステム520へ提供し得る。コントロールシステム520は、例えば、オペレータワークステーション540におけるコントロールオペレータによって、これらの警告または報知を目視用の他のコントローラタイプの警告および報知と一体化させることもできる。いうまでもなく、所望されれば、ホストワークステーション530は、任意の所望される方法データにおいて、本明細書中で説明されている任意のものを含む、インターフェースデバイス410において収集され、該インターフェースデバイス410によって提供されるデータを目視するために、任意の所望される目視アプリケーションを含み得る。同様に、このデータは、ウェブブラウザ550を介して他のユーザによって目視するために使用可能とされ得る。このように、お分かりのように、異常事態防止システム35に関連しているものとして本明細書中に説明されている種々のアプリケーションは、異なるデバイスに分配されてもよいし、全てがユーザインターフェースを有するデバイスにおいて操作される必要もない。代わりに、SPMデータなどのデータが、インターフェースデバイス410におけるような一つのデバイスにおいて収集され処理され、完全に異なるデバイスにおいて目視するために送信されてもよい。同様に、ルールは、ホスト、ウェブブラウザ、PDAなどのユーザインターフェースデバイスにおいて作成され、ルールエンジンにおけるインプリメンテーションのために、インターフェースデバイス410のような異なるデバイスへ送信されてもよい。図1および図2の例において、異常事態防止システム35に関連するアプリケーション38、40、42は、同一のワークステーションまたはコンピュータ上で格納されるものとして図示されているが、これらのアプリケーションのいくつか、または、他のエンティティが、処理プラント10内またはこれに関連した他のワークステーションまたはコンピュータにおいて格納され実行され得る。さらに、異常事態防止システム35内のアプリケーションが分割されて、二つ以上のコンピュータやマシン上で実行されてもよいし、ワイヤード、ワイヤレス、および/または、断続通信接続を介して、互いに連結して、動作するように構成されてもよい。また、本明細書中に記載の異常事態防止システム35は、アプリケーション38、40、および42のいずれかまたは全てを含んでもよいし、必ずしも含まなくてもよいが、本明細書中に記載のADBまたはSPMブロックを含んでもよい。また、本明細書中に記載の例としては、FieldbusSPMブロックの形態でSPMブロックを使用しているが、本明細書中で使用されている用語SPMブロックは、これらのブロックまたはルーチンが公知のFieldbusプロトコルに合致するものであろうとなかろうと、処理データまたは変数を収集すると共に何らかの統計演算またはモニタリングを実行する任意の他のタイプの統計処理モニタブロック、ルーチンなどを言及しこれらを含むように意図されている。更に、上記説明は、統計データを計算するADBブロックおよびSPMブロックのようなブロックに述べられているが、他のタイプの信号処理データを生成する他のタイプの信号処理データ収集ブロックが使用されてもよい。例えば、周波数解析データ例えば、処理変数のフーリエ変換や他の変換に基づいて生成されるデータ、自動回帰データ、ウェーブレットデータ、ニューラルネットワークを用いて生成されるデータ、ファジー論理を用いて生成されるデータなど、を生成する信号処理データ収集ブロックが異常事態防止システムにおいて使用され得る。このように、本明細書中において使用されている用語信号処理データ収集ブロックは、処理データまたは変数を収集し、統計データの生成、処理データの例えば、フーリエ変換、離散型フーリエ変換、高速フーリエ変換、短期フーリエ変換、Z-変換、ヒルベルト変換、ラドン変換、ウィグナー分布、ウェーブレット変換などの数学的変換、変換された処理データからの情報の抽出、フィルタリング、ファジー論理を用いた処理データからの情報の抽出、ニューラルネットワーク、自動回帰技術などの信号処理演算やモニタリングを実行する、任意のタイプのモニタリングブロック、ソフトウェアルーチン、ハードウェアなどを言及すると共にこれらを含むように意図されている。また、信号処理プラント内の信号データ収集ブロックから信号処理データが集められ、解析される例が説明されてきたが、複数の処理プラントのコンテクスト状況において同様の技術が使用可能であることが理解されよう。例えば、複数の処理プラントからの信号処理データが集められ、このデータは、解析エンジンおよび/または目視アプリケーションに提供され得る。特定の通信プロトコルおよび技術を用いた例について説明されてきたが、公知のプロトコルおよび技術を含む、信号データ収集ブロックからの構成データおよび信号処理データにアクセスするためのさまざまな他のプロトコルおよび技術が使用され得る。例えば、信号データ収集ブロックを識別および/または構成し、信号処理データなどを収集するために、OPC以外の他のプロトコルおよび技術を使用することができる。他の技術には、例えば、インターネットプロトコル、イーサネット登録商標、XML、プロプラエタリプロトコルなどを使用することを含んでもよいし、他のインプリメンテーションは、ウェブサーバ、および/または、処理コントローラ、I/O出入力デバイス、ワークステーション、フィールドデバイスなどのプロプラエタリ演算デバイスが使用し得る。同様に、プロプラエタリデータを含む他のタイプの階層データが使用され得る。本明細書中に記載の異常事態防止システムとアプリケーションが異常事態防止システムと関連するものとして好ましくはソフトウェアにおいてインプリメントされているが、これらはハードウェア、ファームウェアなどにおいてインプリメントされ得て、該処理コントロールシステムに関連する任意の他のプロセッサによってインプリメントされ得る。このように、本明細書中に記載のエレメントは、標準多目的CPU内で、または、所望に応じたASIC特定用途向けICや他のハード回線デバイスなどの専用設計のハードウェアやファームウェア上でインプリメントされ得る。ソフトウェアにおいてインプリメントされるとき、ソフトウェアルーチンは、磁気ディスク、DVDなどのレーザディスク、他の格納媒体などの任意のコンピュータ可読媒体、コンピュータやプロセッサのRAMランダムアクセスメモリやROMリードオンリーメモリ、任意のデータベースなどに格納され得る。同様に、このソフトウェアは、例えば、コンピュータ可読ディスクや他の運搬可能なコンピュータ格納機構上で、あるいは、電話回線、インターネットなどの通信チャネルなどを介して、即ち、任意の公知のまたは所望される分配方法を介して、ユーザや処理プラントへ分配され得る運搬可能な格納媒体を介してこのようなソフトウェアを提供することと同じ、あるいは、互換性があると見なされる。このように、本開示は、特定の実施例について説明されているが、これは単に例示することを目的するものであり、本発明を限定するものではない。従って、本開示内容の精神および範囲を逸脱しない限りにおいてあらゆる変更、追加、および削除が行われてよいことが当業者に明確であろう。