図1を参照すると、典型的なプロセス制御プラント10は、1つまたは複数の通信ネットワークを介して幾つかの制御及び保全システムと相互に接続される幾つかのビジネス及び他のコンピュータ・システムを含む。図示されたプロセス制御プラント10はまた、1つまたは複数のプロセス制御システム12及び14を含む。プロセス制御システム12は、PROVOXまたはRS3システムもしくは他の任意のDCSのような従来のプロセス制御システムであることが可能である。図1に示すシステム12は、コントローラ12Bと入力/出力(I/O)カード12Cとに結合されるオペレータ・インタフェース12Aを含み、コントローラ12B及び入力/出力(I/O)カード12Cはアナログ及び高速道路アドレス可能遠隔送信機(HART)フィールド・デバイス15等の様々なフィールド・デバイスに結合される。分散されたプロセス制御システムである可能性のあるプロセス制御システム14は、イーサネット(登録商標)・バス等のバスを介して1つまたは複数の分散されたコントローラ14Bに結合される1つまたは複数のオペレータ・インタフェース14Aを含む。コントローラ14Bは、例えばテキサス州オースティン所在のFisher Rosemount Systems, Inc.が市販するDeltaV(商標)コントローラまたは他の任意の所望タイプのコントローラであることが可能である。コントローラ14Bは、I/Oデバイスを介して、例えばHARTまたはFieldbusフィールド・デバイスまたは例えばPROFIBUS(登録商標)、WORLDFIP(登録商標)、Device Net(登録商標)、AS Interface及びCANの各プロトコルのうちの何れかを使用するものを含む他の任意のスマートまたは非スマート・フィールド・デバイス等の1つまたは複数のフィールド・デバイス16に接続される。周知のように、フィールド・デバイス16は、プロセス変数及び他のデバイス情報に関するアナログ及びデジタル情報をコントローラ14Bへ供給することができる。オペレータ・インタフェース14Aは、例えば制御オプティマイザ、診断エキスパート、ニューラル・ネットワーク、チューナ、他を含む、プロセス制御オペレータがプロセス・オペレーションを制御するために利用可能なツールを格納しかつ実行することができる。
またさらに、プロセス制御システム12及び14に、またはその内部の個々のデバイスには、保全及び監視アクティビティを実行するためにAMSアプリケーションまたは他の任意のデバイスまたは機器監視及び通信アプリケーションを実行するコンピュータのような保全システムを接続することが可能である。例えば、保全コンピュータ18は、デバイス15と交信しかつ例によってはデバイス15上で他の保全アクティビティを再構成する、または実行するために、所望の任意の通信回線またはネットワーク(無線または手持ち式デバイス・ネットワークを含む)を介してコントローラ12B及び/またはデバイス15に接続されることが可能である。同様に、AMSアプリケーション等の保全アプリケーションは、デバイス16の作動ステータスに関するデータ収集を含む保全及び監視機能を実行するために、分散されたプロセス制御システム14に関連づけられるユーザ・インタフェース14Aに実装され、かつこれにより実行されることが可能である。
図示されたプロセス制御プラント10はまた、何らかの永久的または一時的な通信リンク(バスまたは機器20に接続されて値を読み取れば除去される無線通信システムまたは手持ち式デバイス等)を介して保全コンピュータ22に接続されるタービン、モータ、他等の様々な回転機器20を含む。保全コンピュータ22は、例えばCSIシステムまたは回転機器20の作動状態を診断し、監視しかつ最適化するために使用される他の任意の周知アプリケーションによって供給される周知の監視及び診断アプリケーション23を格納しかつ実行することができる。保全要員は通常、アプリケーション23を使用してプラント10における回転機器20のパフォーマンスを保持しかつ監視し回転機器20に伴う問題点を決定し、回転機器20が修理または交換されなければならないかどうか、及びその時期を決定する。場合によっては、外部のコンサルタントまたはサービス組織が機器20に関するデータを一時的に捕捉または測定し、このデータを使用して機器20の分析を実行し、機器20に影響する問題点、低いパフォーマンスまたは他の結果を検出することができる。これらの場合、分析を実行するコンピュータはどの通信回線を介してもシステム10の他の部分に接続され得ず、または一時的にしか接続され得ない。
同様に、プラント10に関連づけられる発電及び配電機器25を有する発電及び配電システム24は、例えばバスを介して、プラント10内の発電及び配電機器25のオペレーションを実行しかつ監視する別のコンピュータ26に接続される。コンピュータ26は、例えばLiebert及びASCOまたは他のサービス企業によって提供されるもののような周知の電力制御及び診断アプリケーション27を実行し、発電及び配電機器25を制御しかつ保持することができる。ここでも多くの場合、外部のコンサルタントまたはサービス組織が機器25に関するデータを一時的に捕捉または測定し、このデータを使用して機器25の分析を実行し、機器25に影響する問題点、低いパフォーマンスまたは他の結果を検出することができる。これらの場合、分析を実行するコンピュータ(コンピュータ26等)はどの通信回線を介してもシステム10の他の部分に接続され得ず、または一時的にしか接続され得ない。
当然ながら、他の任意の機器及びプロセス制御デバイスをプラント10に取り付けること、またはプラント10の一部にすることが可能であり、本明細書に記載するシステムは図1に特定的に示す機器に限定されず、代わりに、または追加的に、他の任意のタイプのプロセス制御機器またはデバイスを含むことが可能である。
嘗て、様々なプロセス制御システム12及び14と発電及び保全システム22及び26とは、これらのシステムの各々において生成される、または各々によって収集されるデータを有益に共用できるようにする方法で互いに相互接続されていなかった。その結果、プロセス制御機能、発電機能及び回転機器機能等の異なる機能の各々は、その特定の機能によって影響を受ける、または上記特定の機能に影響を与える可能性のあるプラント内部の他の機器が完璧に作動しているという、当然ながらほとんどあり得ない想定の下で動作していた。しかしながら、上記機能はかくも異なるものであり、かつこれらの機能を監視するために使用される機器及び要員も異なることから、プラント10内のこれらの異なる機能システム間に意味のあるデータ・シェアリングはほとんど、または全く存在していない。
この問題点を克服するために、異種のデータ・ソースからデータを捕捉し、このデータを共通のデータ・フォーマットまたは構造体にフォーマットし、次いでこのデータを必要に応じて例えばコンピュータ・システム30で実行される、またはプロセス制御ネットワーク全体のワークステーション間に分配される任意のアプリケーション・スートへ供給するためのデータ収集及び分配システムが装備される。このアプリケーション・スートは、先行する異種である別々のシステムからのデータの使用を融合し、または統合してプラント10のよりよい測定、表示、制御及び理解をもたらすために供給される。図1に示すように、コンピュータ・システム30は、プロセス制御機能12及び14、コンピュータ18、14A、22及び26に実装されるもの等の保全機能及びプロセス・パフォーマンス監視の実行等のビジネス機能を含むプラント10内の様々な機能システムに関連づけられるコンピュータまたはインタフェースに通信可能に接続される。特にコンピュータ・システム30は、全てバス32を介して、従来のプロセス制御システム12と、上記制御システムに関連づけられる保全インタフェース18とに通信可能に接続され、分散されたプロセス制御システム14のプロセス制御及び/または保全インタフェース14Aに接続され、回転機器の保全コンピュータ22と、発電及び配電コンピュータ26とに接続される。バス32は、任意の所望される、または適切なローカル・エリア・ネットワーク(LAN)または広域ネットワーク(WAN)プロトコルを使用して通信を供給することができる。当然ながらコンピュータ・システム30は、固定リンクまたは断続的リンク、ハードワイヤード・リンクまたは放送リンクまたはFieldbus、IEEE802.3、blue tooth、X.25またはX.400通信プロトコルのうちの1つを使用する有線、無線、同軸ケーブル、電話モデム、光ファイバ、光学、流星バースト、衛星媒体、他のうちの1つのような任意の物理的媒体を含む他の通信リンクを介してプラント10のこれらの異なる部分に接続されることが可能である。
図1に示すように、コンピュータ30はまた、同じ、または異なるネットワーク・バス32を介してビジネス・システム・コンピュータ及び保全プランニング・コンピュータ35及び36に接続されることが可能であり、これらは例えば、企業リソース・プランニング(ERP)、材料リソース・プランニング(MRP)、パフォーマンス・モデリング、会計、生産及び顧客発注の各システム、保全プランニング・システムまたはその他部品、補給品及び原料の各発注アプリケーション、生産スケジューリング・アプリケーション等の任意の所望されるビジネス・アプリケーションのためのプロセス・モデリング、他を実行することができる。コンピュータ30はまた、例えばバス32を介してプラント全体に亘るLAN37、企業WAN38及び遠隔ロケーションからのプラント10の遠隔監視またはプラント10との交信を有効化するコンピュータ・システム40にも接続されることが可能である。
上述のデータ収集及び分配システムはまたコンピュータ30にも供給されることが可能であり、またはプロセス・ネットワーク10全体に亘る多くのロケーションに分配されることが可能であって、コントローラ・システム12及び14、監視システム22及び26、財政システム35、36、他等の任意のデータ・ソースからデータを捕捉しかつ処理する。データ収集及び分配システムがコンピュータ30内に位置づけられれば、これは、異なるデータ・フォーマットを使用して、または共通のフォーマットを使用してコントローラ、機器監視及び財政アプリケーション等の異種のデータ・ソースから別々にデータを受信することができる。ある実施形態では、バス32上の通信はXMLプロトコルを使用して発生する。この場合、コンピュータ12A、18、14A、22、26、35、36、他の各々からのデータはXMLラッパにラップされ、例えばコンピュータ30内に位置づけられることが可能なXMLサーバへ送られる。XMLは記述言語であることから、サーバはどんなタイプのデータでも処理することができる。サーバにおいて、必要であればデータはカプセル化されて新たなXMLラッパへマップされ、即ちこのデータは、1つのXMLスキーマから受信するアプリケーションの各々について生成される他の1つまたは複数のXMLスキーマへマップされる。この通信を供給する1つの方法は、本参照により明示的に開示に含まれる、2001年7月10日に出願された「プロセス制御システムのためのトランザクション・データ通信」と題する同時係属米国特許出願第09/902,201号に記述されている。このシステムを使用すれば、各データ発信者は、理解される、またはそのデバイスまたはアプリケーションにとって便利なスキーマを使用してそのデータをラップすることが可能であり、各受信アプリケーションは、受信アプリケーションに使用される、または受信アプリケーションによって理解される異なるスキーマでデータを受信することができる。サーバは、データのソース及び(1つまたは複数の)宛先に依存して1つのスキーマを別のスキーマにマップするように構成される。所望されれば、サーバはまた、データの受信を基礎として所定のデータ処理機能または他の機能も実行することができる。マッピング及び処理機能の規則は、本明細書に記述されているデータ統合アプリケーション・スートのオペレーションに先立ってサーバにおいて設定され、格納される。このようにして、データは任意の1つのアプリケーションから他の1つまたは複数のアプリケーションへ送信されることが可能である。
別の実施形態では、データの収集と分配の各アプリケーションはネットワーク10全体に分配されることが可能であり、データの収集は分散されたロケーションで達成されることが可能である。収集されたデータは次に分散されたロケーションにおいて共通のフォーマットに変換され、1つまたは複数の中央データベースへ送信されて引き続き分散されることが可能である。従って一般的に言えば、異種のデータ・ソースからデータを収集し、このデータを共通または整合するフォーマットで、このデータを使用できるコンピュータ30内のアプリケーションのようなアプリケーション・スートへ供給するために、1つまたは複数のデータ収集ルーチンが供給される。本明細書では、データ収集及び分配アプリケーションをデータ収集及び分配システムと称し、収集されたデータを使用する(例えば、このデータを統合する)アプリケーションを集合的に資産活用スート50と称する。
資産活用スート50内のアプリケーションは、収集されるデータ及びプロセス制御システム12及び14、保全システム18、22及び26及びビジネス及びプロセス・モデリング・システム35及び36により生成される他の情報、及びこれらのシステムの各々において実行されるデータ分析ツールによって生成される情報を使用する。一般的に言えば、資産活用スート50は、米国特許出願第09/256,585号または第09/499,445号等の1つまたは複数のユーザ・ディスプレイ・アプリケーション、及び1つまたは複数の診断エキスパートまたは例えば現在NEXUSによって提供されているOZエキスパート・システムを基礎とする他のタイプのエキスパート・システム・アプリケーションを含むことが可能である。但し資産活用スート50は、例えば任意のタイプのデータ・マイニング・システムを含む他の任意の所望されるタイプのエキスパート・システムを使用することができる。資産活用スート50はまた、様々な機能システムからのデータをユーザ情報目的、診断目的及びプロセス・プラント内でプロセス制御アクション、機器交換または修理アクション、財政因子、プロセス・パフォーマンス因子、他を基礎として生産される製品のタイプまたは量を変更すること等の措置を取る目的等の他の任意の目的で統合する他のアプリケーションも含むことが可能である。
例えば、資産活用スート50は、プロセス制御システム12及び14、保全システム18、22及び26及びビジネス・システム35及び36により発生されるデータ及び他の情報、及びこれらのシステムの各々において実行されるデータ分析ツールによって発生される情報を収集する資産活用エキスパート59を含むことが可能である。資産活用エキスパート59は、例えば現在NEXUSによって提供されているOZエキスパート・システムを基礎とすることが可能である。但し資産活用エキスパート59は、例えば任意のタイプのデータ・マイニング・システムを含む他の任意の所望されるタイプのエキスパート・システムであることが可能である。重要な点は、資産活用エキスパート59がプロセス・プラント10におけるデータ及び情報クリアリングハウスとして動作し、かつ保全エリア等の1つの機能エリアからのデータまたは情報のプロセス制御エリアまたはビジネス機能エリア等の他の機能エリアへの分配を調整できることである。資産活用エキスパート59はまた、収集されたデータを使用してプラント10内の異なる機能に関連づけられる1つまたは複数のコンピュータ・システムに分配され得る新たな情報またはデータを発生させる。またさらに、資産活用エキスパート59は、収集されたデータを使用してプロセス・プラント10内で使用される新たなタイプのデータを発生させる他のアプリケーションを実行する、または他アプリケーションの実行を監視することが可能である。資産活用エキスパート59はまた、データ収集及び分配システムの一部として実装される場合もある。
従ってデータ収集及び分配システムは、ある意味でプロセス・プラント10におけるデータ及び情報クリアリングハウスとして動作することが可能であり、保全エリア等の1つの機能エリアからのデータまたは情報のプロセス制御エリアまたはビジネス機能エリア等の他の機能エリアへの分配を調整する。その結果、資産活用スート50は、収集されたデータを使用してプラント10内の異なる機能に関連づけられる1つまたは複数のコンピュータ・システムに分配され得る新たな情報またはデータを発生させることが可能であり、かつ収集されたデータを使用してプロセス・プラント10内で使用される新たなタイプのデータを発生させる他のアプリケーションを実行する、または他アプリケーションの実行を監視することが可能である。
あるケースでは、資産活用スート50は、プロセス制御機能及び機器監視機能からのデータ、及び所望されればプロセス制御ネットワーク内で実行されるプロセス・パフォーマンス監視機能からのデータを使用する幾つかのアプリケーションを供給することができる。これらのアプリケーションは、プロセス制御データ、プロセス・パフォーマンス・モデリング・データまたは機器監視データのうちの2つ以上を使用するプラントに関する情報または属性を表示するための協調されたユーザ・ディスプレイを供給することができる。資産活用スート50に関連づけられるアプリケーションはまた、プロセス制御監視アプリケーション、プロセス・パフォーマンス監視アプリケーション及び機器監視アプリケーションのうちの2つ以上からのデータを基礎として、プロセス制御プラント10内の状態または問題点を診断することもできる。またさらに、資産活用スート50に関連づけられるアプリケーションは、診断された、または検出された問題点に応じてプロセス・プラント10内で措置を講じることが可能であり、または例えばプロセス制御オペレータ、保全技術員またはプラント10の全体オペレーションを担当するプラント10の「本部」におけるビジネス要員のうちの何れかであることが可能なユーザに、講じられるべき措置を推奨することができる。
より特定的に言えば、ある実施形態では、資産活用スート50は、プロセス制御及び計装デバイス、発電デバイス、回転機器、ユニット、エリア、他のようなデバイスに関連づけられる指標、またはプラント10内のループ他等のプロセス制御エンティティに関連づけられる指標を収集する、または生成する指標発生ソフトウェア51を含む、または実行することができる。これらの指標は次に、プロセス制御を最適化する手助けをするためにプロセス制御アプリケーションへ供給されることが可能であり、かつビジネス要員へプラント10のオペレーションに関連づけられるより完全な、またはより理解しやすい情報を提供するためにビジネス・ソフトウェアまたはビジネス・アプリケーションへ供給されることが可能である。ある実施形態では、指標発生ソフトウェア51は資産活用エキスパート59の一部として実装されることが可能である。
資産活用スート50はまた、オペレータによる制御最適化等の制御アクティビティの実行を補助するために、例えばプロセス制御システム14に関連づけられる制御エキスパート52へ保全データ(デバイスのステータス情報等)及びビジネス・データ(スケジュールされた注文、時間フレーム、他に関連づけられるデータ等)を供給することができる。制御エキスパート52は、例えばユーザ・インタフェース14Aまたは制御システム14に関連づけられる他の任意のコンピュータに、もしくは所望されればコンピュータ30内に位置づけられることが可能である。
所望されれば、制御エキスパート52は、例えば既に述べた米国特許出願第09/256,585号及び第09/499,445号に記述された制御エキスパートであることが可能である。但しこれらの制御エキスパートは、プロセス制御プラント10内のデバイスまたは他のハードウェアのステータスに関するデータ、またはこれらの制御エキスパートにより実行される意志決定においてプロセス・パフォーマンス・モデルを使用して生成されるパフォーマンス・データを追加的に組み込んで使用することができる。特に嘗ては、ソフトウェア制御エキスパートは概して、プロセス変数データ及び幾つかの限定されたデバイス・ステータス・データのみを使用して意志決定を行った、またはプロセス・オペレータに推奨を行った。制御エキスパート52は、資産活用スート50により供給される、または収集される、特にコンピュータ・システム18、14A、22及び26及びこれらに実装されるデータ分析ツールによって供給されるもののようなデバイスのステータス情報に関連する通信を使用して、ヘルス、パフォーマンス、活用及び可変性情報等のデバイス・ステータス情報を受信し、これらをプロセス変数情報と共にその意志決定へ組み込むことができる。
さらに、資産活用スート50は、プラント10内のデバイス及び制御アクティビティのオペレーションのステータスに関する情報をビジネス・システム35及び36へ提供することが可能であり、ビジネス・システム35及び36では、例えばワークオーダ発生アプリケーションまたはプログラム54が自動的にワークオーダを発生させ、プラント10内で検出された問題点を基礎として部品を発注することが可能であり、またはサプライヤーは実行されたワークオーダに基づいて発注を受け取ることが可能である。同様に、資産活用エキスパート59によって検出される制御システムの変化は、ビジネス・システム35または36に例えばプログラム54を使用してスケジューリング及び補給命令を実行するアプリケーションを実行させる。同様の方法で、顧客注文他の変化もビジネス・システム35または36へ入力されることが可能であり、かつこのデータは資産活用スート50へ送られかつ制御ルーチンまたは制御エキスパート52へ送られ、例えば新たに発注された製品の製造を開始する、またはビジネス・システム35及び36で行われる変更を実施するように制御を変更させることができる。当然ながら、所望されれば、バス32に接続された各コンピュータ・システムは、コンピュータ内の他のアプリケーションから適切なデータを取得してこのデータを例えば資産活用エキスパート59へ送るように機能するアプリケーションを内部に有することが可能である。
さらに、資産活用スート50は、情報を例えばプラント10内のオプティマイザ55によって使用される1つまたは複数のプロセス・モデルに送ることができる。例えばプロセス・モデル56及び制御オプティマイザ55はコンピュータ14A内に位置づけられることが可能であって、1つまたは複数の最適化ルーチン55A、55B、他を実行することができる。さらに、または代替として、プロセス・モデル56及びオプティマイザ・ルーチン55はコンピュータ30または他の任意のコンピュータに格納されかつ上記コンピュータによって実行されることが可能であり、よって必要なデータは資産活用エキスパート59によって送信されることが可能である。モデル56の結果は、資産活用エキスパート59または制御エキスパート52等の制御または他のエキスパートへ入力されることが可能であり、その目的については本明細書において後により詳細に説明する。但し一般的に言えば、モデル56は、プロセス・ユニットまたはエリア・パフォーマンスの決定に使用されることが可能であり、これは次に、オプティマイザ・ルーチン55に入力される、またはユーザに表示される、もしくは他の目的に使用されることが可能である。モデル56は、英国、ティーサイド所在のMDC Technologyによって製造され市販されているもの等のモデルであることが可能であり、もしくは、他の任意の所望タイプのモデルであることも可能である。当然ながら、プラント10内に装備されることが可能であり、かつ資産活用エキスパート59からのデータを使用可能である他のアプリケーションも存在し、よって本明細書に記述するシステムは本明細書において特に言及されているアプリケーションに限定されない。但し全体的に見れば、資産活用スート50は、プラント10の全ての機能エリア間のデータの共用及び資産の調整を有効化することにより、プラント10内の全ての資産の使用を最適化する手助けをする。
また一般的に言えば、1つまたは複数のユーザ・インタフェース・ルーチン58は、プラント10内のコンピュータのうちの1つまたは複数に格納される、またはこれらによって実行されることが可能である。例えば、コンピュータ30、ユーザ・インタフェース14A、ビジネス・システム・コンピュータ35または他の任意のコンピュータは、ユーザ・インタフェース・ルーチン58を実行することが可能である。ユーザ・インタフェース・ルーチン58の各々は、資産活用スート50からの情報を受信する、または入手することが可能であり、かつ情報を資産活用スート50へ提供することが可能であり、同じ、または異なるデータ・セットの何れかはユーザ・インタフェース・ルーチン58の各々へ送られることが可能である。ユーザ・インタフェース・ルーチン58はどれも、所望されれば、異なるユーザ向けに異なるスクリーンを使用して異なるタイプの情報を提供することができる。例えば、ユーザ・インタフェース・ルーチン58のうちの1つは、スクリーンまたはスクリーン・セットを制御オペレータまたはビジネス要員へ供給し、その要員が規格制御ルーチンまたは制御オプティマイザ・ルーチンで使用する制約を設定できるように、または最適化変数を選定できるようにすることが可能である。ユーザ・インタフェース・ルーチン58は、ユーザが指標発生ソフトウェア51またはプロセス・パフォーマンス・モデル56によって生成されるプロセス・パフォーマンス及び指標を何らかの協調的方法で見ることができるようにする制御ガイダンス・ツールを供給することが可能である。このオペレータ・ガイダンス・ツールはまた、プロセス・プラント10内の他のソフトウェアによって情報が検出されるに伴って、オペレータまたは他の任意の要員がデバイスのステータス、制御ループ、ユニット、他に関するこうした情報を取得できるように、かつこれらのエンティティに伴う問題点に関する情報を容易に見ることができるようにすることが可能である。ユーザ・インタフェース・ルーチン58はまた、ツール23及び27により供給される、または生成されるパフォーマンス監視データ、AMSアプリケーションまたは他の任意の保全プログラム等の、または資産活用スート50と合同してモデルにより生成されるような保全プログラムを使用して、パフォーマンス監視スクリーンを供給することも可能である。当然ながら、ユーザ・インタフェース・ルーチン58は、プラント10の全ての機能エリアで使用される選択または他の変数について任意のユーザにアクセス可能にして、かつこのユーザがこれらを変更できるようにすることが可能である。
次に図2を参照すると、単純化された機能ブロック図100は、異種のデータ・ソースからのデータが資産活用スート50によって使用され得るようにする、本明細書に記載するデータ収集及び分配システム102に関連づけられる、または上記システムにより使用されるデータ・フロー及び通信を示す。特に本図100は、多くのデータ・ソースからデータを受信するデータ収集及び分配システム102を含む。例えば(プロセス制御及び監視アプリケーション、プロセス制御診断アプリケーション、プロセス制御警報アプリケーション、他等の従来型のプロセス制御アクティビティ及びアプリケーションを含むことが可能な)プロセス制御データ・ソース104は、データをデータ収集及び分配システム102へ供給する。ブロック104は、プロセス制御環境内の従来型、即ちスタンドアロン型のプロセス・コントローラにより、DCSにより、DeltaVシステムにより、PLC他によりデータを送ることが可能である。
(従来型の機器監視アプリケーション、機器診断アプリケーション、機器警報アプリケーション、異常状況分析アプリケーション、環境監視アプリケーション、他を含むことが可能は)機器またはプロセスのヘルス・データ・ソース106もまた、データをデータ収集及び分配システム102へ送る。その結果、ソース106は、CSI、Fisher Rosemount Systems, Inc.により市販されているAMSアプリケーション、Nexisアプリケーション、他等の任意タイプの従来型機器監視及び診断アプリケーションまたはソースにより取得される、またはこれらによって発生されるデータを送ることが可能である。
(最適化アプリケーション等のパフォーマンス監視アプリケーション、プロセス・オペレーション、プロセスまたは機器ヘルスの監視またはモデリングに使用されるプロセス・モデル、他を含むことが可能な)パフォーマンス監視データ・ソース108もまた、システム102へデータを供給する。データ・ソース108は、任意タイプのパフォーマンス監視機器またはアプリケーションによって捕捉される、または発生されるデータを含む、または供給することが可能である。またさらに、(収益を最大にして環境関連の罰金を回避するプラント操業方法の決定、どんな製品をどれだけ製造するかの決定、他等のプロセス制御システム内で財政またはコストタイプ分析機能を実行するアプリケーションを含むことが可能な)財政または生産プランニング・データ・ソース110もシステム102に接続される。財政プランニング及びプロセス制御アプリケーションは共に、同じ、または異なるプロセス・モデルによって供給される情報を使用することが可能である。
またさらに、スマート・フィールド・デバイス等のフィールド・デバイス112もデータをデータ収集及び分配システム102へ供給することが可能である。当然ながら、フィールド・デバイス112によって供給されるデータは、警報、警告、測定データ、較正データ、他を含む、これらのフィールド・デバイスによって測定される、または生成される任意のデータであることが可能である。同様に、腐食監視データ・ソース114は、腐食監視サービスまたはアプリケーションにより収集される、または生成されるデータを収集システム102へ供給することが可能である。同様に、警報データ・ソース116は、高度警報アプリケーションまたはサービスにより収集される、または生成されるデータをシステム102へ供給することが可能である。警報データ・ソース116は、サンプルを測定し、またはサンプルを採り、ラボ分析を実行し、これらの分析を基礎として警報または他の情報を生成するアプリケーションまたはサービスを含むことが可能である。
図2に示すデータ・ソースに加えて、またはこれらの代わりに、他の任意のデータ・ソースからさらに他のデータが供給され得ることは、留意されなければならない。さらに、図2のデータ・ソースによって供給されるデータは、測定された生データである場合もあり、測定されたデータを基礎とする分析または他のルーチンによって生成されるデータである場合もあり、両者の何らかの組合せである場合もある。さらにまた、図2のデータ・ソースの任意のもの、または全てから供給されるデータは、このデータを測定または発生させる可能性のある異なる組織またはアプリケーションにより使用される自社独自のフォーマットを含む任意のフォーマットで測定され、発生され、または伝達され得ることも理解されるであろう。従って、例えば、異なるフィールド・デバイス112は異なるフォーマットでデータを収集しかつ発生させ、次いでこのデータをデータ収集及び分配システム102へ送ることが可能である。同様に、財政データ・ソース110、腐食データ・ソース114、警報データ・ソース116、他も任意の規格フォーマットまたは自社独自のフォーマットで測定された、または発生されたデータを供給することが可能であり、かつ任意の自社独自の、またはオープン・コードのアプリケーションを使用してデータを測定または発生させることが可能である。従って、一般的に言えば、データ、結果、結論、推奨事項、他を測定または発生させるために現在プロセス制御環境において使用されている(または将来の使用のために開発されている)アプリケーションまたはデバイスはどれも、これらのデータ・ソースがもともと部分的に、または完全に自社独自のものであるとしても、データ収集及び分配システム102へのデータ・ソースとして作用することが可能である。
データ収集及び分配システム102は、異なるデータ・ソースから共通のフォーマットでデータを収集する、または、データが受信されるとこれを、プロセス制御システムにおける他のエレメント、デバイスまたはアプリケーションによる後の格納及び使用のために共通のフォーマットに変換する。ある実施形態では、異なるデータ・ソースがOPC、PI、Fieldbus、他等のデータ変換プロトコルを使用してデータをデータ収集及び分配システム102へ伝達することが可能である。当然ながら、OPCまたは他の変換インタフェースは、データ収集及び分配システム102に、またはデータ・ソース自体に格納されることが可能である。さらに、所望されれば、データ・ソースのどれもが、そのデータをデータ収集及び分配システム102により使用される共通のフォーマットに変換し、変換されたそのデータをシステム102へ伝達することが可能である。当然ながら、データ収集及び分配システム102は、異なるデータ・ソースにより送られるデータを任意の共通のフォーマットまたはプロトコルに変換し、そのデータをデータベースに任意の所望される方法で格納しかつ編成することが可能である。データ収集及び分配システム102は、データを異なるデータ・ソースから周期的または非周期的に、連続的または断続的に、同期的または非同期的に、もしくは任意の所望される時間に受信することが可能である。
一旦受信されて変換されたデータは、何らかのアクセス可能な方法でデータベースに格納され、資産活用スート50内のアプリケーションまたはユーザが利用できるようにされる。例えば、プロセス制御、警報、デバイス保全、故障診断、予知保全、財政プランニング、最適化、他に関連するアプリケーションは、異なるデータ・ソースのうちの1つまたは複数からのデータを使用し、組合せ、または統合して、これらのアプリケーションが過去に大幅に異なる、または事前にアクセスできないデータ・ソースからのデータなしで動作していた場合よりもうまく動作することが可能である。図2に資産活用スート50の一部として示したアプリケーションは、図1に記述したアプリケーションの何れでもあることが可能であり、または、所望に応じて他のどんなタイプのアプリケーションでもあることが可能である。当然ながら、図2に示すデータ・ソース及び収集されたデータを使用するアプリケーションは共に事実上例示的なものであり、より多くの、より少ない、もしくは異なるデータ・ソース及びアプリケーションの使用が可能である。同様に、データ・ソース自体も、データ収集及び分配システム102により収集されるデータを受信するように構成されることが可能である。このようにして、自社独自のアプリケーションを有する可能性のある異なる供給者またはサービス・プロバイダは、データ収集及び分配システム102から事前に捕捉していなかった、または捕捉することがができなかった所定のデータを収集することが可能であり、これにより、これらのサービス・プロバイダによって提供されている製品またはサービスの強化が可能になる。
ある実施形態では、嘗て典型的には自社独自のアプリケーションを使用してプロセス制御ネットワーク以外のデータを収集しかつ生成してきた従来型のプロセス制御サービス・プロバイダが、今では収集された、または生成されたデータをデータ収集及び分配システム102へ供給し、上記システムは次いでこのデータを他のアプリケーションが利用できるようにすることが期待されている。これらの他のアプリケーションは、ホスト・デバイス、ユーザ・インタフェース、コントローラ、他等のプロセス制御環境に通信可能に接続されたコンピュータ内で実行されるアプリケーションであることが可能である。さらに、これらの他のアプリケーションは、従来型のサービス組織によって供給される、または使用されるアプリケーションであることが可能である。このようにして、現在ではどのアプリケーションも、プロセス・システム・オーナによって所有されるアプリケーションまたはサービス・プロバイダによって所有されかつ管理されるアプリケーションの何れによってもプロセス制御システム内で任意の方法で生成された任意のデータを使用するように設計されることが可能である。その結果、嘗ては入手不可能であったデータを使用できることからアプリケーションが強化され得る極めて多くの例が存在する。例えば、腐食分析サービス・プロバイダは、自社独自のプロセス制御システムまたは自社独自の機器監視アプリケーションにより収集されるデータを使用して、腐食分析の信頼性または予測可能性を強化し得る可能性がある。大幅に異なるタイプのサービス・プロバイダ及びアプリケーションからのデータのこのような相互交流は、嘗ては利用不可能であった。
次に図3を参照すると、プロセス制御プラント10内のデータ・フローを示すより詳細なデータ・フロー図200が提示されている。図200の左側から見ていくと、プロセス・プラント10に関連づけられるデータは、プラント10内の異なる機能エリアまたはデータ・ソースにより、またはこれらにおいて収集される。特に、プロセス制御データ201は、例えばフィールド・デバイス、入力/出力デバイス、手持ち式または遠隔のトランスミッタまたは例えばプロセス・コントローラへ通信可能に接続されることが可能な他の任意のデバイス等の典型的なプロセス制御デバイスによって収集される。同様に、従来型の機器監視アクティビティに関連づけられる機器監視データ202は、例えばプラント10内のセンサ、デバイス、トランスミッタまたは他の任意のデバイスによって収集される。プロセス・パフォーマンス・データ203は、プラント10内の同じ、または他のデバイスによって収集されることが可能である。所望されれば、財政データは、プロセス制御プラント内のコンピュータによって実行される他のアプリケーションによりパフォーマンス監視データとして収集されることが可能である。例によっては、収集されるデータは、サービス組織または供給者によって所有されかつ動作されるアプリケーション等の従来のプロセス制御ネットワーク以外のアプリケーションまたはソースからのものである場合がある。当然ながら、収集されるデータは、回転機器の角度位置、速度、加速データ(及び電力スペクトル密度、周波数振幅、他をもたらすこのデータの変形)、機器の応力データ、歪みデータ、肉厚データ、腐食程度及び腐食進行速度データ、プロセス流体腐食性データ、潤滑及び摩耗データ、ベアリング及びシール・データ、揮発性有機及び無機化合物に関するデータを含むがこれらに限定されない逃散する流体及び気体の漏れの存在率及び組成データ、ベアリング温度データ、音響トランスデューサ・データ、プロセスの物理的及び組成上の測定データ、他の何れかである可能性があるが、これらに限定されない。このデータは、自動または手動を含む任意の方法で収集されることが可能である。従ってデータ・コレクタは、手持ち式の収集デバイス、実験室での化学的及び物理的測定用固定式または一時的オンライン・デバイス、遠隔プロセス及び機器測定デバイス、オンライン・デバイス入力または遠隔マルチプレクサ及び/またはコンセントレータからデータを周期的(RF等)に遠隔測定で記録するデバイスまたは他の任意の収集デバイスを含むことが可能である。
プロセス制御データ、機器監視データ及びプロセス・パフォーマンス・データは、データ収集デバイス内で、または中央データ・ヒストリアン、プロセス・コントローラ、機器監視アプリケーション、他等の他の任意のデバイスまたはこのデータを受信または処理する他の任意のデバイス内で実行される(図2のデータ収集及び分配システム102の一部であることが可能な)データ収集及び照合アプリケーション204によって照合され、検証され、確認されかつ/またはフォーマットされることが可能である。当然ながら、収集されたデータは、任意の周知方法または所望される方法で照合またはメッセージとして通信されることが可能である。例えばデータは、共通のフォーマットまたはスケールにされる、異なる、または規格(共通)ユニットに変換される、異常値、誤った、または不正確なデータに関してスキャンされる、任意の周知方法または所望される方法で検証または確認される、等が可能である。データ照合を実行する周知方法及び技術は多く存在し、データを照合し、メッセージとして通信し、検証し、または収集する方法の使用が可能である。またさらに、異なるタイプのデータは、このデータが異なるフォーマット、プロトコル、他によるものである可能性があるとしても、共通のコレクタまたはデータ・コレクタ・ルーチンによって収集されることが可能である。
任意の周知方法または所望される方法で照合された後、または場合によっては全く照合されないまま、収集されたデータは、典型的にはプロセス制御システム10の異なる機能エリアに関連づけられる1つまたは複数のアプリケーションへ供給されることが可能である。例えば、周知のように、図3にプロセス制御機能ブロック206の一部として示した異なるプロセス・コントローラまたは制御アプリケーション208は、収集されたプロセス制御データ201を幾つかの理由または目的で使用することが可能である。これらのプロセス制御アプリケーションは、例えば従来型のDCS、PLC及びSCADAシステム、コンピュータ制御システム、ハイブリッド・システム及び現時点で周知である、または将来開発される任意タイプのデジタル制御システムを含むことが可能である。従って、任意の周知または所望されるプロセス制御ソフトウェアまたは技術を使用するプロセス・コントローラ・アプリケーション208は、プロセス制御データ201を使用して進行中のプロセス機能を監視しかつ制御する。このようなアプリケーションは、例えばPID、ファジー論理、モデル予測、ニューラル・ネットワーク、他のプロセス制御アクティビティを含む任意タイプのプロセス制御を実行することが可能である。プロセス制御アプリケーション208は、警報データまたは警報メッセージを生成し、発生させ、またはプロセス・オペレータへ送出することが可能であり、問題点または懸念を検出し、または環境保護局(EPA)による制約、食品医薬品局(FDA)による制約等の規制当局に関連づけられる監査を実行することが可能でありかつ多すぎてここには列挙しきれない他の周知のプロセス制御機能を実行することが可能である。またさらに、1つまたは複数の診断アプリケーション210は、収集されたプロセス制御データ201を使用してプロセス制御診断を実行することが可能である。このような診断アプリケーションは、例えば、1999年2月22日に出願されて本出願の譲受人に譲渡される、かつ本参照により明示的に開示に含まれる「プロセス制御システムにおける診断法」と題する米国特許出願第09/256,585号に開示されているもののような、オペレータがプロセス制御ループ、計器、アクチュエータ、他内の問題点を特定する手助けをするアプリケーションを含むことが可能である。診断アプリケーション210はまた、2000年2月7日に出願されて本出願の譲受人に譲渡される、かつ本参照により明示的に開示に含まれる「プロセス制御システムにおける診断エキスパート」と題する米国特許出願第09/499,445号に開示されているもののようなエキスパート診断エンジンを含むことが可能である。当然ながら、診断アプリケーション210は、他の任意の典型的な、または規格のプロセス診断アプリケーションの形式をとることが可能であり、本明細書で特定的に言及されたものに限定されない。さらにまた、これらの診断アプリケーション210の出力は任意の形式をとることが可能であり、例えばプロセス制御システム内の故障した、または働きの悪いループ、機能ブロック、エリア、ユニット、他を指摘することが可能であり、ループがチューニングを必要とする場合を指摘すること、他が可能である。
同じく図3に示すように、プロセス制御ヒストリアン212を使用して、先に収集されたプロセス制御データ201またはプロセス制御監視アプリケーション208、プロセス制御診断アプリケーション210の出力もしくは他の任意の所望されるプロセスデータを格納することが可能である。当然ながら、プロセス制御監視アプリケーション208及び診断アプリケーション210は、ヒストリアン212に格納されたデータを任意の周知方法または所望される方法で使用することが可能である。またさらに、アプリケーション208及び210は、プロセス10内のプロセス・ユニットまたはエリアの全て、または一部をモデリングするために生成されることが可能なプロセス・モデル214(図1のモデル56の一部でありかつパフォーマンス監視機能エリアの一部であることが可能)を使用することができる。
またさらに、機器監視機能ブロック220は、機器状態データ202、またはそのデータに照合が実行されていれば照合されたバージョンのこうしたデータを受信する。機器監視機能ブロック220は、例えば機器の様々な部品に伴う問題点を指摘する警報を受入れ、または発生させ、プラント10内の働きの悪い、または故障した機器を検出する、または機器に関して保全要員が関心を持つ可能性のある他の問題点または状態を検出する機器または状態監視アプリケーション222を含む。機器監視アプリケーションは周知であり、典型的にはプラント内の異なる特定タイプの機器に適合化されたユーティリティを含む。従って、これらのアプリケーションに関する詳細な検討は不要である。同様に、機器診断アプリケーション224は、機器に関して測定された生データを基礎として機器の問題点を検出しかつ診断するために実装されることが可能である。このような機器診断アプリケーション224は、例えば振動センサ・アプリケーション、回転機器アプリケーション、電力測定アプリケーション、他を含むことが可能である。当然ながら、プロセス制御プラント内の機器の異なる部品の状態または作動状態に関連づけられる多くの種類の異なるデータ・タイプを生成することができる周知の機器状態監視及び診断アプリケーションには、多くの異なるタイプが存在する。またさらに、ヒストリアン226は、機器監視デバイスによって検出される生データを格納することが可能であり、機器状態監視及び診断アプリケーション222及び224によって発生されたデータを格納することが可能でありかつデータを必要に応じてこれらのアプリケーションへ供給することが可能である。同様に、(図1のモデル56の一部である、よってパフォーマンス監視機能エリアの一部であることが可能な)機器モデル228は、機器状態監視及び診断アプリケーション222及び224によって任意の所望される方法で供給されかつ使用されることが可能である。このようなモデルの生成及び使用は技術上周知であり、本明細書でさらに説明する必要はない。
同様に、図3に示すプロセス・パフォーマンス監視機能ブロック230は、データ・コレクタ204によって照合、フォーマット、他を実行される場合も、されない場合もあるプロセス・パフォーマンス・データ203を受信する。プロセス監視機能ブロック230は、例えばプロセス制御モデル214、プロセス機器モデル228またはパフォーマンス・モデル232を使用して任意の周知方法または所望される方法でプロセス・パフォーマンス監視を実行することが可能であるプロセス・パフォーマンス監視アプリケーション231を含む。別のアプリケーション・セット233は、プロセス・パフォーマンス監視の出力を使用して、プロセスのより優れた全体的使用を実行するように、またはより効率的に作動する、もしくは儲けをより多くするプロセスを実現するようにユーザに推奨する、またはユーザにプロセス機器構成の変更方法をアドバイスすることが可能である。プロセス・パフォーマンス監視ヒストリアン234は、プロセス・パフォーマンス監視デバイスによって検出される生データを格納することが可能であり、プロセス・パフォーマンス監視アプリケーション231及び推奨アプリケーション233によって発生されるデータを格納することが可能でありかつこのデータを必要に応じて他のアプリケーションへ供給することが可能である。プロセス・モデル及びプロセス・パフォーマンス監視アプリケーションの生成及び使用は周知であり、本明細書ではさらなる説明を省く。
様々な外部ソースからのデータへの限定されたアクセスまたはアクセスなしという限定事項を克服するために、データを収集し、必要であればそのデータを図3に示す資産活用スート50内のアプリケーションによってアクセスされかつ使用されることが可能な共通のフォーマットまたはプロトコルへ変換するデータ収集及び分配システム102が供給される。このようにして、資産活用スート50内のアプリケーションは、プロセス制御機能エリア206、機器監視機能エリア220及びプロセス監視機能エリア230を含む異なる機能エリアまたはデータ・ソースから異なるタイプのデータを受信し、このデータをプラント10に直接利益をもたらすように幾つかの方法のうちの任意の方法で統合する。資産活用スート50の目標は、プラント10のより優れた監視を実現し、プラント10の全体的状態をより良く把握できるようにし、プラント内の全てのデータを基礎としてプラント10またはプラント10の資産の制御または使用に関してより優れた決定を下せるようにしかつ全体としてプラント10をさらに最適に操業できるようにすることである可能性がある。異なるタイプの機能データの統合は、改善された人身に対する安全、より長いプロセス及び機器使用可能時間、破局的プロセス及び/または機器故障の回避、より高いオペレーティング利用可能性(使用可能時間)及びプラント生産性、設計及び製造保証限度のより高い利用可能性及び上記限度により近くかつより速く安全かつ確実に操業する能力に由来するより高い製品スループット、環境限度値でプロセスを作動させる能力に由来するより高いスループット及び機器関連のプロセス及び製品変動の排除または最小化に起因する改善された品質をもたらす、または有効化することが可能である。これに対して嘗ては、プロセス監視、機器監視及びパフォーマンス監視等の異なる機能エリアは独立して実行され、各々が、所定の行為が他の機能エリアに及ぼすかもしれない影響を顧みることなくその関連の機能エリアを「最適化」しようとした。その結果、例えば優先度の低い機器の問題点であっても所望の、または極めて重大なプロセス制御パフォーマンスを達成する上で大きな問題を引き起こす可能性があったが、機器保全のコンテキストにおいてそれが極めて重要であるとは考えられなかったために是正されることはなかった。しかしながら、資産活用スート50へデータを供給するデータ収集及び分配システム102を使用すれば、作業者は機器監視データ、プロセス・パフォーマンス・データ及びプロセス制御監視データのうちの2つ以上を基礎としてプラント10のビューへのアクセスを得ることができる。同様に、プラント10に関して実行される診断は、プロセス・オペレーション及び機器オペレーションに関連づけられるデータを考慮して、より優れた全体的診断分析を供給することが可能である。従って、資産活用スート50内のアプリケーションは、プロセス制御、機器監視及びプロセス・パフォーマンスの各データを使用して、1つの機能エリアにとっては厳密に最適ではないものの、異なる機能エリアの独立したオペレーションでは見越すことのない方法でプラント全体のオペレーションを最適化することができる、より優れた、またはより完璧な決定を下すことが可能である。
データ収集及び分配システム102は、機能データ収集または発生ソース206、220、230及び239と資産活用スートとの間に配置される一方、異種のデータを収集している異なるデータ・ソースが何であるかに依存して、これはまた、もしくは代わりに、システム10内の他の場所に配置されても良い。実際には、データ収集及び分配システム102は、データ・ソースが何であるか、及びどのソースが規格または認識可能なフォーマットで既に統合されているか、またはデータを供給するかに依存して、図3のフロー図のどこにでも配置されることが可能である。先に指摘したように、データ収集及び分配システム102は資産活用スート50と機能エリア206、220、230及び239との間に配置されることが可能であり、通常はこうなる。しかしながらデータ収集及び分配システム102は、機能エリア206、220、230または239の何れか、または全ての前に配置される場合もあり、またこれらの2方法の何らかの組合せである場合もある。またさらに、データ収集及び分配システム102は中央に集めて示されている、即ち1つの場所に示されているが、これは分散されてシステム10内の複数の場所に配置されることも可能である。従って、このデータ収集及び分散ソフトウェアのコンポーネントは、複数の異なるデバイスにおいて実行される可能性があり、異種のデータ・ソースからより多くの、またはより優れたデータを収集することができる。これらの複数のデータ収集アプリケーションの各々は、収集ニーズ及びこれらのアプリケーションの配置に依存して1つまたは複数のソースからデータを収集するように動作し、各アプリケーションは次いで、収集されてフォーマットされたデータを、このデータが他のアプリケーションによりそこからアクセスされ得るシステム内の集中された1つまたは複数のデータベースへ供給することが可能である。
再度図3を参照すると、資産活用スート50は、例えば例示目的でパフォーマンス監視機能エリア230、プロセス制御機能エリア206及び機器監視機能エリア220を含む、プロセス制御プラント10内の異なる機能エリアまたはデータ・ソースから収集されるデータを使用する幾つかのアプリケーションを包含するものとして図示されている。当然ながら、資産活用スート50はこれらのエリアから、生データ、照合データ、ヒストリアン212、226及び234に格納されるデータ、監視アプリケーション208及び222によって生成されるデータ、パフォーマンス・モデル232によって生成されるデータ及び診断アプリケーション210及び224によって生成されるデータを含む任意のデータを受信することが可能である。所望されれば、資産活用スート50はまた、プロセス・モデル214及び機器モデル228を使用することが可能である。資産活用スート50は特定数のアプリケーションを包含するものとして示されているが、スート50は、本明細書に記述した任意の1つまたは複数のアプリケーションを実行する1つまたは複数を含む任意数のアプリケーションを包含し得ることは理解されるであろう。
特に、図3に示す資産活用スート50は、1つまたは複数の統合されたプラント状態監視アプリケーション240を含むことが可能である。このようなプラント状態監視アプリケーション240は、プロセス制御情報及びデバイス情報及びパフォーマンス情報のうちの2つ以上を基礎として、プラント10内のプロセス制御及び計装デバイス、発電デバイス、回転機器、ユニット、エリア、他のようなデバイスに関連づけられる指標及び/またはユニット、ループ、エリア、他のようなプロセス制御エンティティに関連づけられる指標を生成する図1の指標発生アプリケーション51を含むことが可能である。これらの指標の発生及び表示については、後に詳述する。但し一般的に言えば、これらの指標はプロセス制御データ及びプロセス・パフォーマンス及び機器監視データを基礎とすることが可能であり、ユーザに統合されたディスプレイを介して整合的なフォーマットで表示されることが可能である。
図3に示すように、資産活用スート50は任意のユーザに異なるデータを統合された、または共通の方法で表示する(図1のインタフェース・アプリケーション58のうちの何れか、または全てであることが可能な)統合されたディスプレイ・アプリケーション244を含む、または使用することが可能である。一般的に言えば、ディスプレイ・アプリケーション244は任意のユーザに異なる情報を提供するように構成され、この場合に表示される情報は、プロセス制御データ201、機器状態データ202及びプロセス・パフォーマンス・データ203のうちの2つ以上を反映する、もしくは基礎とする。アプリケーション244は、スート50内の他のアプリケーションから入力を受信してユーザが生データ201、202及び203を見ることを有効化することが可能であり、生データまたは処理されたデータを基礎としてユーザがスクリーンからスクリーンへプラント10の異なる部分または態様を見て回れるようにすることが可能であり、ユーザが機器状態、プロセス監視またはパフォーマンス監視アプリケーション222、208及び231、プロセス・モデル214、機器またはプロセス診断アプリケーション224及び210によって発生されるデータ等の処理されたデータ、または資産活用スート50内の他のアプリケーションによって発生されるデータを見ることを有効化することが可能である。
資産活用スート50はまた、プロセス及びデバイスの両警報を受信することが可能でありかつこれらの警報をユーザへ整合されたフォーマットで表示することができる統合された警報アプリケーション246を含むことが可能である。このような統合された警報ディスプレイ・アプリケーションは、2000年11月7日に出願され、本出願の譲受人に譲渡されかつ本参照により明示的に開示に含まれる「プロセス制御ネットワークにおける統合された警報ディスプレイ」と題する米国特許出願第09/707,580号に開示されている。統合された警報アプリケーション246は、受信された警報に関する情報を提示し、警報を統合する警報バナーを提示するユーザ・ディスプレイ248を生成することが可能である。
資産活用スート50はまた、プロセス制御データ201、プロセス・パフォーマンス・データ205及び機器状態データ202を統合してプラントワイドベースで診断を実行する1つまたは複数の統合された診断アプリケーション250を含むことが可能である。例えば、プロセス機器データとプロセス制御データが組み合わされると、これらのデータ・タイプの一方だけを使用する場合よりもプラント10内の状態に関してより優れた診断分析が生成され得るような例は多く存在する。同様に、機器状態診断アプリケーション224の出力とプロセス制御診断アプリケーション210の出力とを組み合わせれば、個々のアプリケーションの何れかの出力による場合よりも完全なプロセス・プラントの診断分析を生成することができる。統合された診断アプリケーション250は、任意の所望されるタイプのエキスパート・エンジン、プロセス及び/または機器モデル及び受信されるデータまたは他のアプリケーションから下される他の診断決定を基礎としてプラント10内の状態に関する予測を行う予測アプリケーションを含むことが可能である。当然ながら、統合された診断アプリケーション250はインタフェース・アプリケーション244を介してユーザにディスプレイを提示し、異なる診断分析を示すことが可能である。さらに統合された診断アプリケーション250は、ユーザがアプリケーション250を、アプリケーション250により特定の統合された診断決定を生成するように構成することを有効化することが可能である。例えばユーザには、ユーザがそこで実行される異なる診断アプリケーション(例えばプロセス診断アプリケーション210及び機器監視アプリケーション224の双方を含む)を選択し、次いでこれらの選択された診断アプリケーションの出力を基礎として他の診断決定を組み合わせる、または下すことができる構成スクリーンが提示されることが可能である。この場合、ユーザは、所定の周知のプロセス及び機器監視または診断アプリケーションの出力を、これらの出力を何らかの方法で組合せ、または評価して診断決定を下す(例えばプロセス・パフォーマンス機能であることが可能な)新たな機能に接続することが可能である。或いは、プロセス制御データ201及び機器監視データ202の双方を使用して新たな診断アプリケーションを生成し、プラント診断が実行される場合もある。これらの例では、診断アプリケーション250はユーザに、例えばユーザ・インタフェース・アプリケーション244を介してディスプレイを出力することが可能である。
故障診断アプリケーション250はまた、プロセス制御データ201及び機器状態データ202の双方を使用して検出された問題点のソースを決定するバックトラッキング・アプリケーションを含むことが可能である。プロセス制御データまたは機器状態データの何れかを基礎として検出された問題点のソースを位置づけようとするバックトラッキング・アプリケーションは存在しているが、プロセス制御データ及び機器状態データの双方を基礎としてプラント内の問題点をピンポイントするようなバックトラッキング・アプリケーションが使用されたことはない。プロセス及び機器データの双方を使用するバックトラッキング・アプリケーションの使用は、プロセス・プラント10内の問題点または状態の原因に関して、プロセスまたは機器データの一方のみを使用する先行するバックトラッキング・アプリケーションよりも優れた、またはより完全な答えをもたらすことができる。当然ながら、これらのバックトラッキング・アプリケーションは、プロセス制御及び機器監視データ、及び所望されればプロセス・パフォーマンス・データを統合して問題の原因を決定する。このような原因は、異なって加重される可能性のある因子の組合せ、同時に存在すべきものでないプロセス及び機器状態(ポンプの運転と遮断弁の閉止等)の検出、他である可能性がある。これらの問題点の提示は、確率、加重、述語条件の各状態、他の形である可能性がある。これらのバックトラッキングまたは他の診断アプリケーションは、プロセス及び機器の形式モデル及び入出力変数及びこれらの変数の実際の測定値の微分を使用して入力変数に対する出力変数の全微分を計算することが可能であり、かつ実際のプロセス測定値を使用してこの全微分を評価し、異なる潜在的ソースの原因寄与を計算することが可能である。原因データはまた、予測がどの程度持続されたかを決定するために、プラント10からの実際の出力データによって検証され、確認されかつ照合されることが可能である。
何れにしても、統合された診断アプリケーション250によって下される診断決定に関して、または警報または他の状態に応答して何らかの措置を講じるための1つまたは複数の他のアクション・アプリケーション260を供給することが可能である。例えばアプリケーション260は、潜在的なアクションまたは推奨事項のリストをユーザ・インタフェース・アプリケーション244を介してユーザへ、または予測アプリケーション262へ供給することが可能であり、予測アプリケーション262はこのような推奨の結果を予測しかつこのような結果を統合されたディスプレイ・アプリケーション244を介してユーザへ表示することが可能である。これらの推奨事項は、例えば問題を是正し、プラント10の寿命を延ばし、プラント10をより経済的に、または設定された財政またはEPA制約内で運転し、現行の、または予測されたプロセス及び機器の機能性を基礎として将来的な問題点を回避する、他を目的として措置を講じるべく設計されることが可能である。アプリケーション260はまた、ユーザが、提案されたアクションを基礎としてプラント10のシミュレーションを実行し、アクションを実施する前にこれらのアプリケーションのシミュレートされた効果を見ることを有効化することが可能である。アプリケーション260は、より優れた診断決定を下す最中により多くの、またはより優れたデータを収集する措置を講じることができる。このデータ収集は自動的に、機器状態監視またはプロセス監視アプリケーションまたはパフォーマンス監視アプリケーションにさらなる、または異なるタイプのデータを収集させることを伴う可能性がある。
アプリケーション260はまた、そのように構成されていればフィードバック経路264で示されるように、アプリケーション250により下される診断決定を基礎としてプラント10内で設定ポイントのリセット、ループのチューニング、機器の再構成、他等の措置を講じることが可能である。これらの措置は、プロセス制御アプリケーション、機器監視及び制御アプリケーションを使用してシステムの変更を実施することを含む場合も、含まない場合もある。これらの措置はまた、別のものとは異なるタイプまたは1つのタイプの製品を製造するようにプラント10を再構成すること、またはそうでなければ財政利益を最大化する、または他の懸念事項に影響を与えるようにプラント10を再構成することを伴う可能性がある。またさらに、アプリケーション260は、(図1のアプリケーション54であることが可能な)自動作業命令発生アプリケーション270等の他のアプリケーションを呼び出して機器に必要な部品を注文する、新製品の生産に必要な原料を注文する、他が可能である。当然ながらアプリケーション260は、統合された警報、財政上の制約または指示もしくは他のデータを使用して非常措置を講じ、プラント10に自動または手動変更が行われて必要に応じて指令、他に影響を与えるようにすべく制御を実行することが可能である。
理解されるように、ユーザ・インタフェース244は、実行されているスート50内のアプリケーションを基礎として幾つかの異なるタイプのユーザ・スクリーンのうちのどれか、または全てを表示することができる。従って例えば、ユーザ・インタフェース244は、機器パフォーマンス・スクリーン、生データ・スクリーン、状態図242、他を表示することが可能である。ユーザ・インタフェース244はまた、統合された警報アプリケーション246により生成される統合された警報スクリーン248も表示することが可能である。同様に、診断ディスプレイ273、推奨スクリーン274及び目標生産及び機器活用を示すスクリーン275及び276も、任意の故障診断アプリケーション250によって生成されることが可能である。同様に、任意の性質の生産プランニング及び財政スクリーン277も、措置実行アプリケーション260によって生成されることが可能である。当然ながら、多くのデータ・ソースからのデータを基礎として、他のタイプのスクリーン及びディスプレイがこれらの、または他のアプリケーションにより生成されることが可能である。
図3は、プロセス制御、機器監視及び診断及びパフォーマンス監視の各アプリケーションをアプリケーション・スート50から分離されたものとして示しているが、これらの特定的なアプリケーションは、所望されれば統合されたアプリケーション・スート50の一部であり得ること、または上記スートに使用され得ることは注目すべきである。さらに、図3はプラント10の一実施形態に関連づけられるデータを示しているが、図3は、任意のアプリケーションのアプリケーション・スート50内の物理的なロケーションを示すことを意図したものではない。従って、図3に示すアプリケーション及びハードウェアの任意のもの、または全ては、プラント内の任意の所望される場所に(または所望されればプラント10から離れた場所にも)配置されることが可能であり、これらのアプリケーションが同じ場所に配置される必要はない。またさらに、データ・コレクタとデータ収集及び分配システム102との間、及びデータ収集及び分配システム102と図3に示すアプリケーションとの間のデータ・フローは、LANまたはWAN、インターネット、任意のイントラネット、他等の任意の所望されるネットワーク上で形成することが可能である。データは、例えば任意の物理的媒体を含む任意の所望されるハードウェアと、有線、無線、同軸ケーブル、電話モデム、光ファイバ、光学、流星バースト、衛星、他のデバイスの使用を限定なしに含む任意の専用または共用情報伝送方法とを使用して、任意の所望される方法で伝送されることが可能である。この通信はまた、Fieldbus、XML、TCP/IP、IEEE802.3、Bluetooth、X.25、X.400といったプロトコルまたは現在周知である、または将来開発される他の任意のプロトコルを限定なしに含む任意の所望されるプロトコルを使用することが可能である。
さらにデータは、統合アプリケーション50へ送られ、上記アプリケーションにより使用され、または上記アプリケーションから送られる任意のステージで条件付けされる、または圧縮されることが可能である。当然ながら、例えばウェーブレット信号表示、フーリエ、アダマール他変換、フーリエ他係数の伝達、例外処理、スイングドア・データ圧縮、他を含む任意の周知または所望される圧縮の使用が可能である。
またさらに、診断アプリケーション250等の統合アプリケーション50は、プロセス機器及び行動の任意のジョイント・モデルを使用して、例えば形式上の数学モデル、統計上の相関関係、カルマン・フィルタを基礎とする推定量、ニューラル・ネットワーク、ファジー論理を基礎とするモデルまたはこれらの、もしくは他のモデルの任意の組合せを含む診断または予測決定を下すことが可能である。
ある実施形態では、診断アプリケーション250は、ユーザがプロセスまたは状態監視センサ出力の波形の特徴を見て、これらのパターンが変化すると制御変更の向きを変える、及び/または急を知らせる、及び/または制御変更を呼び出すことができるようにする。この機能性は、特徴セット上の警報限界によるパターン認識により、またはフーリエ成分を見て個々のフーリエ係数またはフーリエ係数もしくはその何らかの関数(例えば、二乗、合計AC電力、PSD係数、他)の加重された組合せに関して設定される限界値に基づいて方向づけ及び/または警報発生及び/または制御開始をもたらすことにより実装され得る。
ある実施形態では、プロセス及び機器監視アクティビティからの状態監視入力を収集し、変換しかつ処理またはバッファするために、図1のプロセス・コントローラ12または14のうちの1つまたは複数に接続される入力/出力(I/O)カード等の1つまたは複数のカードが供給されることが可能であり、よってこれらのカードはデータ収集及び分配システム102の一部または全てを実装することが可能である。(収集ルーチンがその上で実装されるサブアッセンブリ・プロセッサであることが可能な)これらのI/Oカードは、プロセス・プラント10のデバイス、エリア、他のうちの幾つか、または全てに対してデータ収集アクティビティを実行してプラント10内の統合されたアプリケーションが必要とするデータを供給することが可能である。これらのカードは、プロセス制御システム内の様々な複数の異なるデバイス・タイプまたはソースから、プロセス制御データ、機器監視データまたはプロセス・パフォーマンス・データのうちの任意のもの、または全てを収集するように構成されることが可能である。この場合も、このようなデータ・ソースは、例えば手持ち式の収集デバイス、実験室用の化学及び物理測定ソース、ダイレクトオンライン入力ソース及びリモート・ソースを含むことが可能である。またさらに、本明細書に記述した統合されたアプリケーションのうちの1つまたは複数を格納しかつ実装するために、コントローラに接続されるI/Oカード等の別のカードが供給されることが可能である。従って、図1はデータ収集及び分配アプリケーション及び資産活用スート内の統合されたアプリケーションを中央コンピュータ30に実装されて示しているが、これらのアプリケーション及びこれらのアプリケーションのためのデータ収集アクティビティは、プロセス・プラント10全体に分散された1つまたは複数の専用カードまたは他のデバイスに実装されることが可能である。これらのカードまたはサブアッセンブリ・プロセッサは、図1のバス32等のシステム・バスを介してユーザ・インタフェース及びコントローラへ直接接続される場合もあり、コントローラの1つまたは複数に関連づけられる入力/出力システムの一部である場合もあり、その他の場所に配置される場合もある。当然ながら、このような専用カードは1枚で、それが使用されているプロセス・プラント10の構成及び性質に依存して統合されたアプリケーションの全て、またはその任意のサブセットを実行することができる。場合によっては、収集されたデータにコントローラ・レベルで何らかの前処理が実行されることが可能であり、次いでこの前処理された、または部分処理されたデータはコンピュータ・システム30等の別のデバイスへ供給され、上記デバイスが統合された処理を完成させることが可能である。このようにして、プラント環境内で実装される場合、統合アプリケーション50は本質的に分散されることが可能である。
次に図4乃至6を参照して、異種のデータ・ソースからのデータを収集しかつ統合する方法について論じる。この例では、異種のデータ・ソースから収集されるデータは、Fisher Rosemount Systems, inc.が市販しているDeltaV(商標)プロセス制御システムを使用して実装されるプロセス制御システムによって使用されているフォーマットへ変換されることが理解されるであろう。その結果、プロセス制御データはリモート・データ・ソースではなくなる。しかしながら、保全データ、パフォーマンス監視データ、プロセス・モデル・データ、財政データ、他等の他のデータは、外部のデータ・ソースからのものである。一般的に言えば、このシステムは、システムの構成に関するデータを格納しかつ上記構成を追跡する構成システムを使用して構成される。嘗てこのような構成システムは、プロセス制御のデバイス、ソフトウェア及び方針の配置及び相互作用に限定され、フィールド・デバイス等の所定のデバイスに関する保全情報を限定的に含んでいた。しかしながら、システムの主たる焦点はプロセス制御オペレータの要求に応えることであったために、ユーザに表示されかつ構成システムによって追跡される情報は概してプロセス制御データに限定された。この周知システムでは、構成データベースが格納し、エクスプローラ・アプリケーションが表示したものは、プロセス制御デバイスに関する情報及びこれらのデバイスによって収集されかつ発生されるデータであった。
概して、異なるデータ・ソースからのデータを単一のシステム内で収集しかつ使用できるようにするために、現在では、異なるデータ・ソースがシステムに使用するデータを単一のデータ・ソースとして供給できるようにする構成データベースまたは他の統合された構成システムが供給されている。このような構成データベースは他の異種のデータ・ソースからデータを収集しかつ格納するために使用され、かつ収集されたデータの操作、編成を有効化して使用し、これによりそのデータを異なるアプリケーションが利用できるようにするためのエクスプローラ・タイプのディスプレイまたは階層が供給される。
図4は、プロセス制御システムを使用して異種のデータ・ソースからのデータ収集を実装するシステム300のアーキテクチャの概観を示す。概してシステム300は情報技術システム(ITS)セクション302を含み、上記セクションは、保全管理システム304、製品在庫管理システム306、生産スケジューリング・システム308及びLAN、インターネット、他によって接続される他のシステムを含むことが可能である。ITS302は、XMLトランザクション・サーバ312を介してウェブ・サービス・セクション310へ接続される。サーバ312は、ブロック304、306及び308により使用される、または発生されるデータを示すXMLでラップされたデータをウェブ・サービス310へ送る。
ウェブ・サービス310は、他のデータ・ソースからの所定のデータを聴いて、または予約視聴してこのデータを加入アプリケーションへ供給する一連のウェブ・サービス・リスナ314を含む。加入アプリケーションは、ITS302またはプロセス制御システム内のアプリケーションに関連づけられることが可能である。(データ収集及び分配システム102の一部であることが可能な)ウェブ・リスニング・サービスは、警報及びイベント・データ、プロセス状態監視データ及び機器状態監視データを聴きかつ再分配することが可能である。このデータのインタフェースは、データをFieldbusまたはDeltaVプロトコル等の規格フォーマットまたは所望されればXMLへ変換するために使用される。
ウェブ・サービス310は、ウェブ・サーバ316を介して他の外部データ・ソースと接触しかつこれらからデータを受信する。これらの外部ソースは、振動監視データ・ソース、リアルタイム最適化データ・ソース、エキスパート・システム分析データ・ソース、予測保全データ・ソース、ループ監視データ・ソースまたは他のデータ・ソースを含むことが可能である。当然ながら、各ソースは異なる外部サーバを介して接続される場合もあり、もしくは可能であれば、データ・ソースのうちの2つ以上がサーバを共有する場合もある。同様に、これらのデータ・ソースはプロセス制御環境内に埋め込まれる場合もあり、もしくはこれから分離され、インターネットまたは他のLANもしくはWANを介して外部サーバに接続される場合もある。何れにしても所望されれば、ウェブ・サーバ316は、受信されるデータをフォーマットすることによりデータ収集及び分配システム102の機能性の幾つかを実装することが可能である。
ウェブ・サービス310及び外部サーバ316には、プロセス制御ランタイム・システム318が接続している。ランタイム・システム318は、制御アプリケーション、オペレータ・インタフェース・アプリケーション、警報及びイベント・アプリケーション及びリアルタイム・データ・アプリケーションを含み、これらの何れもが外部サーバから、またはウェブ・サービスから(よってITS302から)のデータを使用することができる。ウェブ・サーバ316及びウェブ・サービス310からのデータを編成しかつ収集してこのデータをプロセス制御ランタイム・システム318による使用が可能な共通または整合的フォーマットで利用できるようにするために、相互運用システム320が供給される。相互運用システム320は、ウェブ・サーバ316及びウェブ・サービス・リスナ314から受信されるデータに対してデータ変換及び認識を実行することができるROC、OPC、PI及びVirtual Controller DLL I/Fインタフェース等の変換インタフェースを含むことが可能である。
最後に、構成データベース322は、外部のウェブ・サーバ316及びITS302から等のリモート・データ・ソースからの任意のデータを含む、相互運用システム320及びプロセス制御ランタイム・システム318からのデータを格納しかつ編成するために使用される。当然ながらITS302はまた、ウェブ・サービス310を介してプロセス制御システム及びリモート・データ・ソースからデータを予約して聴きかつ入手することが可能である。
図5A及び5Bは、構成データベース322に格納されているデータ収集及び分配システム102により収集されたデータを格納し、編成しかつ上記データにアクセスするために使用されることが可能なエクスプローラ・タイプのナビゲーション・ツールにより発生される例示ディスプレイ350を示す。ディスプレイまたは階層350は、異なる目的に使用されることが可能な多くの異なるセクションを含む。しかしながら階層350は、システムが利用可能なデータまたは他のエレメントの編成を表示し、その概観を示しかつこれらへのアクセスを提供する。従って階層350は、構成データベースに格納されたデータを表示するためと、そのデータを操作してシステム構成を何らかの方法で変更するために使用される。図から分かるように、図4の階層例は、「ライブラリ」セクション、「制御方針」セクション及び「ネットワーク」セクションを含む幾つかの異なるセクションを含み、その各々は異なる目的で、または構成データベースに格納された、または構成データベースが利用可能な異なるデータまたは異なるデータ編成を表すために使用されることが可能である。
一般的に言えば、ライブラリ・セクションは、構成に格納された、または構成に関連づけられた異なるエレメントのリストを含み、かつ上記リストへのアクセスを提供する。これらのエレメントは、例えばテンプレート・ソフトウェア・モジュール、フィールド・デバイス、コントローラ、ワークステーション、他を含むハードウェアまたはソフトウェア・エレメントであることが可能である。異種のデータ・ソースからのデータを表示し、編成しかつ上記データへのアクセスを提供するために、ライブラリはまた、異種のデータ・ソースから統合されたシステムへのデータ・フロー・コンジットとして使用される1つまたは複数の外部サーバを含むことが可能である。図4では、これらのサーバがウェブ・サーバ316として示されている。ここで使用されるように、統合されたシステムは、図2のデータ収集及び分配システム102より上のハードウェア及びソフトウェア・エレメントの全てを包含する。言い替えれば、統合されたシステムはシステム10内の同じデータ・フォーマットを使用するエレメントを含む。
各外部サーバの下には、故にこれに関連して、そのサーバをデータのコンジットとして使用するデータ・ソースのエレメントまたはパラメータが定義される。サーバの、故にかつデータ・ソースの定義されたパラメータは、サーバに接続された、または格納されたアプリケーションまたはハードウェア・デバイスを表示するアイコンであることが可能である。これらの定義されたパラメータは、実際の外部サーバによって供給されかつ異なるデータ・ソースに関連づけられるXMLスクリプトで満たされることが可能である。場合によっては、サービス・プロバイダまたはアプリケーションの作成者等のオーナまたはデータ・ソースを作成した者は、サーバまたはサーバに関連づけられるデータ・ソースのオペレーション・ケイパビリティを定義するXMLスクリプトを供給することが可能である。逆に、統合されたシステム内のユーザまたはオペレータは、外部サーバの目的及び属性を定義する情報でライブラリを満たすことが可能である。
図4における外部サーバに関連づけられるものとして示されているデータ・ソースの一例は、RTO+アプリケーションである。一般的に言えば、RTO+アプリケーションは、プロセス制御システムのサービス・プロバイダによって供給されかつ概して上記サービス・プロバイダにより実装される最適化アプリケーションである。このアプリケーションは通常、特定のプロセス制御システムに合わせて調整され、モデルを使用してプラントの制御を最適化する目的でプロセス制御プラントをモデル化する。物理的に外部サーバのデータ・ソース側に配置されるRTO+アイコンの下には、RTO+アプリケーションがボイラのスチーム・タービンとの関連で示されている。RTO+アプリケーションは、そのタービンの効率、そのタービンによって出力されるパワー及びタービンに関してRTO+ソフトウェアにより測定された、または発生された他のパラメータまたはデータのような情報を提供する。さらにライブラリには、RTO+ソフトウェアにより供給されるようなボイラのスチーム・タービンに関する他のエレメントが示される。例えば、ここにはタービンに関して定義された、またはタービンに関連づけられるファンクション・ブロック及びこれらのファンクション・ブロックのパラメータが列挙されている。同様に、タービンに関連づけられる警報も示され、ここで有効化(ターン・オン)または無効化(ターン・オフ)されることが可能である。同様に、RTO+ソフトウェアを介してタービンからデータを収集する必要のある可能性がある診断アプリケーション等の他のアプリケーションが有効化されるか、無効化されるかも指示される。またさらに、タービンに関して収集されかつ格納されるべきデータを定義する他の予め定義された履歴データも、ライブラリのこのセクションに列挙される。警報及び診断サービス等の他のサービスは事実上、ボイラのスチーム・タービンの部品ではないことは留意されるべき点である。但しこれらはタービンからデータを捕捉し、よってタービンをサポートすることから、これらはライブラリにおいてこのエレメントの下に列挙される。
次に、階層350の制御方針部分を参照すると、制御方針は、例えばエリア1、エリア2、他等の地理的領域によって編成される。各エリアは、ユニット1、ユニット2、他等の異なるユニットに分割されることが可能である。またさらに、各ユニットは次いで、各ユニットに関連づけられる多くのモジュールを有することが可能である。これらのモジュールは、プロセス制御ネットワーク内で整合的なフォーマットで開発されたモジュールまたは異種のデータ・ソースに関連づけられたモジュール等の任意のモジュールであることが可能である。これらのモジュールは、概して異なるアプリケーションが互いに協力して動作しかつ互いに通信し合う方法を構成するために使用される。この機能性については、図6を参照してさらに詳しく説明する。
制御方針セクションは、システム10内の異なるハードウェアのロケーション及び相互作用、システム10内の異なるソフトウェア・エレメントのロケーション及び相互作用、他を含む、システム10のカレント構成に関して構成データベースに格納されているような情報を示す。オペレータまたはユーザは、ディスプレイ350内のエレメントを操作することによってシステムの構成を操作することができる。例えば、ソフトウェアの一部をハードウェア・デバイスへダウンロードするために、ユーザは、そのソフトウェアを表示するアイコンをドラッグしてハードウェア・エレメント上へ置くことが可能である。新たなデバイス・アイコンの階層350への配置は、システムへ物理的に追加されている新たなデバイスを反映する。
一般的に言えば、構成データベースは、制御方針セクションに示されるモジュールの操作を格納しかつ許容するように設計される。他のエレメントは、ハードウェアまたはソフトウェア・エレメントの何れであっても、単一のモジュールにより、または相互に接続されたモジュールの組合せにより表示されることが可能である。従って、ユーザがディスプレイ350内のアイコンを操作しているとき、そのユーザは事実上、構成データベース内のモジュールまたはこれらのモジュールが配置される他のデータベースまたはメモリを操作している。
異なるデータ・ソースからのデータの収集及び使用を有効化するため、ディスプレイまたは階層350は、異なるデータ・ソースをモジュールまたはモジュールの組合せとして表示する。このようなモジュールは、次いで構成階層に配置されることが可能であり、かつプロセス制御モジュール等の統合されたシステム内のエンティティに関連づけられるモジュールが構成データベースにおいて操作される場合と同じ方法で操作されることが可能である。事前に知られていない、または接続されていないデータ・ソースのモジュールを作成する場合、ユーザはモジュールのコンテキストにそのデータ・ソースから受信されるべきデータのタイプ、性質または意味を定義する。この情報構造を使用して、そのデータ・ソースから実際に受信されるデータは次に、統合されたシステム内のエレメントの他のモジュールからのデータと同じように、統合されたシステム内で分類され、ラベリングされ、認識されて使用されることが可能である。このようにして、統合されるシステムに完全に関連づけられない編成または人がそのデータを実際に発生させるアプリケーションまたはデバイスを生成している場合であっても、異種のデータ・ソースから受信されるデータはどんなタイプでも収集されかつ格納されることが可能である。当然ながら、データ・ソースからのデータは、OPC、PI、Fieldbus、他等のデータ変換技術によって変換された後に構成データベースへ伝達されることは理解されるであろう。先に指摘したように、この機能は、図5の階層350には事実上示されていないデータ収集及び分配システム102によって実行される。スチーム・タービンのモジュールに関しては、図6を参照してさらに詳しく説明する。
階層350のネットワーク・セクションは、ネットワークの物理的及びオペレーション的相互接続を示す。当然ながら、概して、ネットワークに関連づけられるデバイス及びエレメントは、多くの異なるタイプが存在するであろう。しかしながら、例示した1つのエレメントは、コントローラ・ノードを含むACN(エリア制御ノード)である。コントローラ・ノードは、内部に格納される制御及び通信ソフトウェア等の制御方針を有する。ACNはまた、FieldbusのI/Oデバイス、HARTのI/Oデバイス、他であることが可能な1つまたは複数の入力/出力(I/O)デバイスを含む。当然ながら各I/Oデバイスは、これに接続される、またはI/Oデバイスに通信可能に繋がれる異なるポート、デバイス、ファンクション・ブロック、他を有することが可能である。ACNには、1つまたは複数のワークステーションもまた関連づけられることが可能である。これらのワークステーションは、ユーザ・インタフェースまたは他のタイプのワークステーションであることが可能である。図5に示すワークステーションは、本例ではコントローラ及びフィールド・デバイスに関する情報を得るようにコントローラ、フィールド・デバイス、他を構成するために使用されるもの等の警報及び警告処理または表示アプリケーション及び制御方針アプリケーションを含む多くのアプリケーションまたは他のファンクション・エレメントをサポートまたは実装する。
異なる、または異種のデータ・ソースからのデータ収集を有効化するために、このワークステーションにより相互運用(IOP)がまた供給される、または実行される。(図4にも示した)IOPセクションは、階層350のライブラリ・セクションにおいて同定されている外部サーバのうちの1つまたは複数を含む。ここでは、(外部サーバ1と呼ばれる)RTO+外部サーバは、ACNに示されたワークステーションによってサポートされる。当然ながら、所望により、図2及び3に関連して説明したもの等の他のデータ・ソースに関連づけられる他の外部サーバをこのワークステーションに、このACN内の他のワークステーションに、または他のACNに供給することも可能であり、妥当な任意数のデバイスが外部サーバによってサポートされ得る。これらのデバイスの全てはRTO+アプリケーションまたはサービスに関連づけられる可能性があるが、サーバによってサポートされるデバイスの全てが特定の1つのデータ・ソースに関連づけられる必要はない。単一のサーバは、このようにして多くの異なるデータ・ソースをサポートすることができる。
この例では、外部サーバ1によってサポートされているデバイスの1つが先に論じたボイラのスチーム・タービンである。ライブラリ・セクションで同様に示されているように、ボイラのスチーム・タービンは、効率、パワー、他等の特性、ファンクション・ブロック、警報、他を含むことが可能である。やはりライブラリ・セクションと同様に、ユーザは、タービン・デバイスの警報を選択してここで有効化することにより階層のこのロケーションにおいてデバイス警報等の警報を受信する、または有効化するような設定を行うことが可能である。またさらにユーザは、階層350のこのロケーションで警報、特性(効率、パワー等)、ファンクション・ブロック及びパラメータ・データにアクセスすることができる。
このようにして階層350のIOPセクションを使用しながら、ユーザは、統合されたシステムに事前に接続されなかったデータ・ソースに関連づけられるデバイス、アプリケーション、他からのデータを定義し、次いで上記データへのアクセスを供給することができる。場合によっては、ユーザは、外部のデバイスまたはアプリケーション等の外部データ・ソースの1つまたは複数のモジュールを定義し、これらのモジュールを使用して異種のデータ・ソースから収集されるデータを編成しかつ他のアプリケーションが上記データを利用できるようにする。このプロセスの一部として、ユーザは、外部データ・ソースに関連づけられるファンクション・ブロック、パラメータ、警報、他をデバイスすることが可能である。外部データ・ソースのモジュールまたはファンクション・ブロックが外部データ・ソース内に実際には存在せず、代わりにワークステーション及びその外部データ・ソースに接続される外部サーバによって実装されるようなデータ収集及び分配システム102内に配置される場合であっても、この点に変わりはない。
図5の構成階層350を使用して、ユーザは、IOPサービスによってサポートされる外部サーバを介して接続されるデバイスまたはアプリケーション等のデータ・ソースに関連づけられるモジュールを定義またはインポートする。図6は、モジュールが統合されたシステム内の他のモジュールに接続されるように生成されかつ操作されることを有効化する構成アプリケーションによって提示される構成スクリーンを示す。この構成スクリーンを使用して、統合されたシステム内のアプリケーション及びデバイスのモジュールと、統合されたシステムより外にある、即ち異種のデータ・ソースに関連づけられるアプリケーション及びデバイスのモジュールとは、互いに通信し合うように纏めて接続されることが可能である。この連結性は、次にモジュール間のデータ・フロー及び、従って外部データ・ソースと統合されたシステム内のアプリケーションとの間またはその逆のデータ・フローを画定する。
モジュールは、(図6のスクリーン左側の)複数のモジュール・テンプレート360のうちの1つをドラッグし、選択されたテンプレートを構成スクリーン362へ置くことによって生成されることが可能である。モジュールは次に、ポップアップ特性ボックス及びこれに類似するものを使用して図5の階層のIOPサービス内またはライブラリ内のタービン・デバイス等の特定のデバイスまたはデータ・ソースに割り当てられることが可能である。IOPサービス及び外部サーバを介して特定の外部デバイスまたはデータ・ソースに接続されると、モジュールは、そのデバイスに関連づけられる所定のパラメータを包含するように定義されることが可能である。このようなパラメータは、例示的にはモジュールからの出力等のモジュールから利用可能なモジュールの特性であることが可能である。定義されるモジュール・パラメータ・データの幾つか、または全ては、図5の階層350における外部デバイスまたはデータ・ソースに関連づけられるものとして反映されることが可能である。
この場合、スチーム・タービン・モジュール364は、モジュールからの出力として利用可能な効率パラメータ366及びパワー・パラメータ368を含む。図5の階層350に反映されるモジュール364の他のエレメントもまた、ファンクション・ブロック、デバイスの入力及び出力、デバイスに関連づけられる警報、他を含むモジュールの一部として供給される。図5の階層350のボイラのスチーム・タービンに関連づけられる、または上記スチーム・タービンのために生成されるタービン・モジュール364はまた警報を含むが、これは、階層350のIOPまたはライブラリ・セクションにおいてユーザにより同定される、または有効化される警報である。これらの警報のうちの1つは、出力として利用可能である。モジュールの出力は、外部サーバを介してデバイス自体から、またはデバイスに関連づけられる他のソフトウェアから供給されるタービン・デバイスに関連づけられるデータである。これらの出力は、モジュール364が定義される方法に依存してパラメータ、測定値、他であることが可能である。モジュールへの入力は、デバイスに何らかの方法で影響を与えるように外部サーバを介してそのデバイスに関連づけられる実際のデバイスまたはソフトウェアへ送られることが可能な、アプリケーション、他からの入力である。実際、モジュール364の入力は、関連づけられるデバイスが受諾する、または認識するデータまたは制御信号である。これらの入力の機能は、デバイスまたは上記デバイスに関連づけられるソフトウェアによって定義される。これらの入力は、統合されたシステム内のモジュールまたは他の外部データ・ソースに関連づけられるモジュール等の他のモジュールからのデータが、IOPサービスを介して、かつ故に外部データ・ソースに接続される外部サーバを介して外部のデータ・ソースまたはデバイスへ送られることを有効化する。外部のデータ・ソースは、この入力データをそれが所望する任意の方法で使用することが可能である。これは、例えばこの入力データによって制御されることが可能であり、またはこの入力データを使用してデバイス他のパラメータに関するより優れた、またはより正確な計算をすることが可能である。所望されれば、外部データ・ソースのモジュールはまた、入力、出力、パラメータ、他を使用して何らかの性質の計算をするソフトウェアを包含することが可能である。
構成システムの本好適な実施形態では、統合されたシステム及び外部データ・ソース内のデバイス、アプリケーション、他に関して生成されるモジュールが、極めて似ているFieldbusまたはDeltaVモジュール概念を基礎としている。この場合のモジュール364は、モジュール編成を使用しない外部データ・ソースに関連づけられることからシャドウ・ファンクション・ブロックまたはシャドウ・モジュールである。一般的に言えば、シャドウ・ファンクション・ブロックまたはシャドウ・モジュール・エレメントは統合されたシステムの構成データベース内の機能ブロックまたはモジュールであり、モジュールとして使用可能であるように構成される。但しこのシャドウ・モジュールは、データ・ソースまたはデバイスに接触していてその出力をその外部デバイスによって発生させ、または供給させる。さらにシャドウ・モジュールは、それが受信する入力を外部のデータ・ソースへ供給する。従ってシャドウ・モジュールは単に、入力及び出力と、そのソースから受信されるデータによって決定される実際のデバイスまたはデータ・ソースへの入力、実際のデバイスまたはデータ・ソースからの出力及び実際のデバイスまたはデータ・ソースの状態を反映する状態とを有する。但しシャドウ・モジュールの使用は、外部のデバイスまたはデータ・ソースの入力及び出力へ資産活用スート50内のアプリケーションに関連づけられるモジュール等の統合されたシステム内の他のモジュールがアクセスできるようにする。このようにして、シャドウ・ファンクション・ブロックまたはモジュールは、外部のデータ・ソースから受信されるデータを統合されたシステム内の他のアプリケーションによって使用可能なフォーマットにすることにより、外部データ・ソースと統合されたシステム内のアプリケーションとの間の情報コンジットとして動作する。シャドウ・ファンクション・ブロックの説明及び使用法は、本出願の譲受人に譲渡されかつ本参照により開示に含まれる、1998年9月10日に出願された「プロセス制御ネットワークにおいて使用するシャドウ・ファンクション・ブロック・インタフェース」と題する米国特許出願第09/151,084号に記述されている。
図6の構成スクリーン362は、ユーザがタービン・モジュール364を、その出力を計算またはCalcモジュール370として識別される別のモジュールの入力へ供給するように構成していることを示す。Calcモジュール370は、タービン・モジュール364から受信されるパワー入力と、統合されたシステム内のプロセス制御ルーチンに関連づけられるモジュールである可能性のあるPIDモジュール372から受信される入力とを含む。Calcモジュール370は、これらの入力を使用して、モジュール364に関連づけられるタービン内の何らかのパラメータを変更する必要性を示すものであることが可能な出力を作り出す。本例では、Calcモジュール370の出力は、このデータがIOPサービス及び外部のサーバを介してタービンに関連づけられるデータを供給する(RTO+アプリケーション等の)アプリケーションへ送られるように、タービン・モジュール364の入力へ供給される。Calcモジュール370は、統合されたシステム内のワークステーションで実装されかつ実行されるモジュールであることは理解されるであろう。Calcモジュール370は、資産活用スート50を有するアプリケーションの1つ等の別のアプリケーションに関連づけられることが可能である。従って図6の構成スクリーン362は、データをそのアプリケーションに供給するために1つの外部データ・ソースが統合されたシステム内のアプリケーションに結合される方法を示す。またさらに、統合されたシステム内のこのアプリケーション(即ちCalcモジュール360)は、リモート・データ及びプロセス制御データを使用して計算を実行し、他のデータまたは情報を外部サーバを介して外部データ・ソースへ送る。外部サーバは、OPCまたは他の任意の所望される通信変換プロトコルを使用して、データが統合されたシステムと外部データ・ソースとの間で何れかの方向へ流れる場合にデータを適切なフォーマットへ変換するように構成されることは理解されるであろう。
図6は、外部データ・ソースと統合されたシステム内のアプリケーションとの間の構成または通信方針を示しているが、他のデータ・ソースのモジュール、同じデータ・ソースに関連づけられる異なるモジュール、他も生成され、かつ相互に接続されて任意の外部データ・ソースと統合されたシステム内の任意のアプリケーションとの間に通信を供給し得ることは理解されるであろう。またさらに、異なる外部データ・ソースからのモジュールも通信可能に纏めて結合され、これらのデータ・ソース間に通信を供給することも可能である。この場合、データ収集及び分配システム102は、必要なデータ収集及び異なる外部データ・ソースに関連づけられるデータ・フォーマット間の変換を供給する。
ソースからのデータを収集しかつ編成するために生成されたモジュール内でその外部データ・ソースからのデータを操作する一例は、外部データ・ソースの警報の使用または生成である。特に警報は、モジュールが外部ソースから供給される実際の警報データを収集して反映させるように定義されることが可能である。さらに、または代替として、警報はモジュール内で、そのモジュールに関連づけられる外部データ・ソースから受信されるデータを基礎として生成されることが可能である。警報がモジュール内で生成されるケースでは、モジュール内のファンクション・ブロックは外部ソースからのデータ及び、そう所望されれば他のソースからのデータを捕捉し、任意の所望される計算を実行して警報または警告状態が存在するかどうかを決定することができる。上記状態が存在すれば、このファンクション・ブロックはそのモジュールに関連づけられる、かつ警報アプリケーションによって監視される、または送られることが可能な警報信号を設定することが可能であり、上記警報アプリケーションはこの警報を他の警報が処理される方法と同じように処理する。このような警報処理は、警報をユーザへ表示すること、警報を格納すること、警報が認識されるようにすること、他を含む可能性がある。さらに、外部データ・ソースに関連づけられるモジュール等のモジュールの警報ケイパビリティは、図5の階層350を介して有効化または無効化される(これにより、モジュールのケイパビリティはオンまたはオフになる)ことが可能である。従って、外部データ・ソースからのデータはモジュール内で警報にマップされ得ること、またはモジュールの、故に外部データ・ソースの警報を発生させるために使用され得ることは理解されるであろう。
外部データからの、または外部データ・ソースに関連づけられるデータにアクセスし、これを捕捉する、または見るために、ユーザは階層350のライブラリ・セクションを通って外部サーバに関連づけられる情報を見ることが可能である。さらにユーザは、制御方針を見て外部データ・ソースの特定のモジュールを捜すことが可能である。またさらにユーザは、ACN、ワークステーション、IOP、外部サーバ、階層350内のデバイス経路を使用して適切なデータを発見することが可能である。
警報サービスと同様に、図4の階層350及びデータ収集及び分配システム102を使用すれば、外部データ・ソースについて診断サービス等の他のタイプの外部データ・ソース用サービスが供給され得る。例えば、診断アプリケーションによっては、統合されたシステム内のモジュールからの、または上記モジュールに関するデータを定期的に収集し、このデータを使用して問題点、不良パフォーマンス、他を診断するものがある。現在では、データ・ソース用に生成されるモジュールを使用してその外部データ・ソースに関するデータを収集するために、この同じ診断アプリケーションを使用することができる。従って、外部データ・ソースに関連づけられるモジュールが診断アプリケーションに必要なデータを外部データ・ソースから受信する、または収集するように構成される限り、診断アプリケーションによって必要とされるデータは自動的に収集されることが可能である。場合によっては、モジュールの入力、出力または他のパラメータ内の可変性等のモジュール自体に関する情報を、診断目的で使用することが可能である。当然ながら、所望される任意のデータをこれらの診断アプリケーションのために収集または使用することも可能である。警報と同様に、Fisher Rosemount Systems, Inc.から市販されているInspectアプリケーション等の診断アプリケーションも、図5の階層350において有効化または無効化されることが可能である。この診断アプリケーションは、「プロセス制御システムにおける診断法」と題する米国特許出願第09/256,585号に詳述されている。当然ながら、他の診断アプリケーションも外部のデータ・ソースに関して、そのデータ・ソースまたはデータ・ソースに関連づけられるデバイスのヘルスを示す指標を生成することができる。このような指標は、活用指標、パフォーマンス指標、可変性指標または他のヘルプ指標を含むことが可能である。
データ収集及び分配システム102内での共通のモジュール定義またはスキームの使用は、このシステムの生成及び使用の理解、プログラミング及び使用をより容易にする。従って、Fieldbusプロトコル、Fieldbusプロトコルに極めて類似しているDeltaVプロトコルまたは他のオープン・プロトコル等のオープンまたは周知のモジュール・プロトコルを使用して本明細書に記載したモジュールを生成しかつ操作することが、必須ではないにしても望ましいと思われる。このようなプロトコル及びオープン・プロトコルを使用する場合、外部データ・ソースを供給している、または監督している可能性のあるサービス・プロバイダは、オープン・プロトコルを使用してデータをデータ収集及び分配システム102へ伝達する外部システムのフロント・エンドを生成することにより、データ収集及び分配システム102をサポートすることができる。こういう事情であるとしても、そのデータ・ソースの場合、OPC、PI、他のデータ収集及び分配システム102のためのフロント・エンドは必要でない可能性がある。代わりに、データ収集及び分配システム102によって生成されるモジュールが単に、遠隔のデータ・ソース自体からインポートされることが可能である。さらに、外部データ・ソースへのこのフロント・エンドの装備は、これらのデータ・ソースのオペレータまたはオーナがそれらのシステムから利用可能なデータを定義し、それらのシステムに最も関連のある警報及び警告を供給し、統合されたシステム内で使用される診断アプリケーションをより良くサポートすること、他を有効化し、これらは全て、それらの製品またはサービスをより望ましいものにする。同様に、このフロント・エンドは、それらのアプリケーションが統合されたシステム内の他の外部データ・ソースまたはアプリケーション等の他のソースからのデータを捕捉しかつ使用することをより容易にし、これにより、それらの製品の価値が高まる可能性がある。
データ収集及び分配システムは、本明細書においてモジュールを使用するものとして記述され、また図5のそれ等のエクスプローラ型の階層を使用して編成されかつ操作されるものとして記述されているが、これがこのシステムを実装する唯一の方法であることは理解されるであろう。外部データ・ソースからデータを収集し、それを共通または使用可能なフォーマットに変換し、そのデータを格納しかつそのデータを他のアプリケーションへ供給する他の任意の方法もまた、使用されることが可能である。さらに図3のデータ収集及び分配システム102は単一のエンティティであるものとして示されているが、これは本質的に分散されることが可能である。従って、統合されたシステム全体に展開された異なるワークステーションまたは他のコンピュータ・デバイスは、異なるソースからデータを収集し、このデータを、統合されたシステムが上記データを利用できるようになる方法で処理しかつ格納することが可能である。
データ収集及び分配システム102が構成されると、異種のデータ・ソースから収集されるデータを使用してプロセス環境内の新たな、またはより完全な機能を実行することができる多くの異なるタイプのアプリケーションが存在する。例えば、資産活用スート50内のアプリケーションの1つまたは複数は、デバイス、ユニット、ループ、エリア、他等のプラント内の特定のプラントまたはエンティティのオペレーションをモデル化する1つまたは複数の数学モデルまたはソフトウェア・モデルを実行する、または実行を監督するために使用されることが可能である。従って、収集されたデータを使用するために、プロセスまたはデバイス・モデルが生成されかつ実装されることが可能である。これらのモデルは、プロセス機器またはプロセス領域を基礎とすることが可能である。ある実施形態では、これらのモデルを生成するために、モデリング・エキスパートがプラントをコンポーネント機器に分割し、任意の所望される抽出レベルで異なるコンポーネント部分のモデルを供給する。例えば、プラントのモデルはソフトウェアに実装され、プラントの異なるエリアに関して階層的に関連する、相互に接続されたモデル・セットで作られる、または上記モデル・セットを含むことが可能である。同様に、任意のプラント・エリアのモデルは、プラント内の異なるユニットの個々のモデルで、これらのユニットの入力及び出力間の相互接続により作られることが可能である。同様にユニットは、相互に接続された機器モデルで作られる、等々が可能である。当然ながら、エリア・モデルは、ユニット・モデル、ループ・モデル、他に相互接続されたデバイス・モデルを有することが可能である。このモデル階層例では、デバイス等の下位レベル・エンティティのモデルの入力及び出力は相互に接続されてユニット等の高位レベル・エンティティのモデルを生成することが可能であり、その入力及び出力は相互に接続されてエリア・モデル等のさらに高位レベルのモデルを生成する、等々が可能である。異なるモデルが組み合わされる、または相互に接続される方法は、当然ながらモデル化されているプラントに依存する。当然ながらこれらのモデルは、上述の方法で外部データ・ソースから必要なデータを受信することが可能である。
次に、図7A及び7Bに関連して階層的ソフトウェア・モデルの使用例について説明する。図7Aは、精錬プラント内の複数のエリア380、381及び382のモデルを示す。図7Aに示すように、エリア・モデル382は、原油等の原料をプリプロセッサ・モデル388へ供給する原料ソース384のコンポーネント・モデルを含む。プリプロセッサ388は原料を幾分か精錬し、典型的には原油である出力をさらなる精錬のために蒸留プロセス390へ供給する。蒸留プロセス390は、通常は所望される製品であるC2H4と、一般的に言えば廃棄物であるC2H6とを出力する。C2H6はC2分解炉392へ送り返され、C2分解炉392はその出力をさらなる処理のためにプリプロセッサ388へ供給する。蒸留プロセス390からC2分解炉392を介するフィードバックは、リサイクル・プロセスである。従ってエリア382のモデルは、図7Aが示すように相互に接続された入力及び出力を有する原料ソース384、プリプロセッサ388、蒸留プロセス390及びC2分解炉392の分離されたモデルを含むことが可能である。即ち、各コンポーネント・モデルは図7Aに示す方法で他のコンポーネント・モデルの入力及び出力に結合され、エリア382のモデルを形成することが可能である。当然ながら、他のエリア380及び381のモデルは、相互に接続された入力及び出力を有する他のコンポーネント・モデルを有することが可能である。これらのモデルは外部データ・ソースに関連づけられるプロセッサに実装されることが可能であり、効率、他等の出力を統合されたシステムへ供給する。逆に、モデルは統合されたシステム内に実装され、1つまたは複数の外部データ・ソースからデータを受信することが可能である。
次に図7Bを参照すると、蒸留プロセス390のコンポーネント・モデルがより詳細に示され、これは頂部400Tと底部400Bとを有する蒸留塔400を含む。蒸留塔400への入力403は圧力及び温度を示し、これは図7Aに示すプリプロセッサ388のモデルの出力へ結合されることが可能である。但し、この入力はオペレータによって設定されることも可能であり、またはプラント10内の実際に測定された入力または変数を基礎として設定されることも可能である。一般的に言えば、蒸留塔400は内部に配置された幾つかのプレートを含み、蒸留プロセスの間、流体はプレート間を移動する。C2H4は塔400の頂部400Tから製造され、還流ドラム402はこの物質の幾分かを塔400の頂部400Tへフィードバックさせる。C2H6は概して塔400の底部から到来し、リボイラ404がポリプロピレンを塔400の底部400Bへとポンピングして蒸留プロセスを手助けする。当然ながら所望されれば、蒸留プロセス390のモデルは、蒸留プロセス390のコンポーネント・モデルを形成するために図7Bに示すように接続された入力及び出力を有する蒸留塔400、還流ドラム402、リボイラ404、他のコンポーネント・モデルで作られることが可能である。
先に述べたように、蒸留プロセス390のコンポーネント・モデルはエリア382のモデルの一部として実行されることが可能であり、または他のどのモデルとも離れて別々に実行されることが可能である。特に、蒸留塔400への入力403及び/または出力C2H4及びC2H6は実際に測定されることが可能であり、これらの測定値は蒸留プロセス390のモデル内で後述のように幾つかの方法で使用されることが可能である。ある実施形態では、蒸留プロセス390のモデルの入力及び出力が、蒸留プロセス390のモデルに関連づけられる他の要素またはパラメータ(蒸留塔の効率、他等)を決定して蒸留プロセス390のモデルをプラント10内の実際の蒸留塔のオペレーションにより精確に整合させるために測定され、使用されることが可能である。蒸留プロセス390のモデルは次いで、計算されたパラメータとエリアまたはプラント・モデル等のより大きなモデルの一部として共用されることが可能である。或いは、または追加的に、蒸留プロセス390のモデルは計算されたパラメータと共に、仮想センサ測定値を決定する、またはプラント10内の実際のセンサ測定値がエラー状態であるかどうかを決定するために使用されることが可能である。決定されたパラメータを有する蒸留プロセス390のモデルはまた、制御または資産活用最適化研究、他を実行するためにも使用されることが可能である。またさらに、コンポーネント・モデルは、プラント10内で展開しつつある問題点を検出して分離するために、またはプラント10の変化がプラント10に関する最適化パラメータの選択にどう影響し得るかを見るために使用されることが可能である。
所望されれば、任意の特定モデルまたはコンポーネント・モデルを実行してそのモデルに関連づけられるパラメータの値を決定することができる。効率パラメータ等のこれらのパラメータのうちの幾つか、または全ては、モデルのコンテキスト内ではエンジニアにとって何らかの意味を持っている可能性があるが、プラント10内では概して測定不能である。より具体的には、コンポーネント・モデルは概して式Y=F(X,P)で数学的に記述することができる。ここで、モデルの出力Yは入力Xとモデル・パラメータ集合Pとの関数である。図7Bの蒸留プロセス390のこの蒸留塔モデル例では、エキスパート・システムが実際のプラントから、モデルが関連するエンティティへの実際の入力X及び上記エンティティからの出力Yを示すデータを周期的に(例えば毎時間、毎10分、毎分、他)収集することが可能である。すると、その度毎に、モデル及び測定された複数の入力及び出力セットを使用して最大尤度、最小二乗または他の任意の回帰分析等の回帰分析が実行され、複数の測定データ・セットを基礎として未知のモデル・パラメータPの適合度が決定され得る。このようにして、任意の特定モデルのモデル・パラメータが実際の、または測定された入力及び出力を使用して決定され、モデルをモデリングされているエンティティに整合させることができる。当然ながら、このプロセスはプラント10内で使用される任意及び全てのコンポーネント・モデルについて実行可能であり、かつ測定された任意の適正数の入力及び出力を使用して実行されることが可能である。またさらに、収集されるデータまたはこのデータから計算される情報はデータ収集及び分配システム102へ供給されてモジュール内で使用されることが可能であり、これらのモデル、これらのモデルによりモデリングされるエレメント、他が反映される。
何れにしても、これらのコンポーネント・モデルまたはこれらのモデルにより収集または発生されるデータを使用して、資産活用スート50は、決定されたモデル・パラメータの値(及び/またはモデルの入力及び出力)を時間に対照させてプロットすることで資産のパフォーマンス監視を実行することができる。またさらに、モデルは、データ・ソース内または資産活用スート50内の何れで実行されるにせよ、潜在的な故障センサを検出することができる。センサのうちの1つまたは複数がそれらに関連して高度な、そうでなければ受容し難いエラーを有するようであれば、資産活用スート50は保全要員及び/またはプロセス制御オペレータに故障センサを知らせることができる。
先に述べたように、任意の特定モデルに関連づけられるパラメータ、入力、出力または他の変数は、プロセスまたはプラントのユニット、エリアまたは他の任意のエンティティに関するパフォーマンス監視を供給するために格納されかつ追跡されることが可能である。所望されれば、これらの変数のうちの2つ以上を纏めて追跡または監視して、エンティティのパフォーマンス測度を供給することが可能である。
資産活用スート50は、モデル・パラメータまたは他のモデル変数を基礎として1つまたは複数のエンティティを監視することが可能であり、かつこれらのエンティティの動作状態またはパフォーマンス測度を、プロセス制御エキスパート・システム、保全要員、ビジネス・アプリケーション、ユーザ・インタフェース・ルーチン、他等のプロセス制御プラント10内の他の任意の所望される要員、機能またはアプリケーションへ報告することができる。当然ながら、資産活用スート50は任意の所望されるエンティティに対し、各エンティティに関する1つ、2つ、3つまたは他の任意の所望される数のパラメータまたは変数を基礎としてパフォーマンスまたは状態監視を実行することが可能である。このパフォーマンス監視に使用されるべき変数またはパラメータの識別及び数は、概してプロセスに精通するエキスパートにより決定され、かつ監視されているエンティティのタイプが基礎とされる。
所望されれば、資産活用スート50、またはより具体的には状態監視アプリケーション240は、上述のようにモデルによって決定されるパラメータの1つまたは複数を、モデリングされているエンティティの設計パラメータに従って実行されるモデルにより決定される同じパラメータと比較することにより、パフォーマンス指標またはプロットを定義することが可能である。特に資産活用スート50は、モデルが関連するプラント10内のエンティティの設計パラメータを使用するモデルを実行して、設計されたエンティティ・パフォーマンスがプロセスのカレント状態に従って、かつプラント10内で測定されるエンティティへの実際の入力を使用して動作していればどうなるかを決定することが可能である。この設計パフォーマンスは、次に、そのエンティティのコンポーネント・モデルにより決定される、またはそのエンティティの測定された入力及び出力により決定されるエンティティの実際のパフォーマンスと比較され、エンティティ・パフォーマンスの測度を発生させることができる。
コンポーネント・モデルはまた、プロセス最適化の実行にも使用されることが可能である。特に、資産活用スート50は個々のコンポーネント・モデルを実行する1つまたは複数の最適化ルーチンを使用して、例えばプロセス制御オペレータまたはビジネス要員によりビジネス・アプリケーションを介して供給される幾つかの最適化基準に関してプラントのオペレーションを最適化することができる。オプティマイザは、その時点でのプラント10の実際の状態を基礎としてプラント10を最適化すべくリアルタイムで動作するリアルタイム・オプティマイザであることが可能である。或いは、または追加的に、オプティマイザは、所定のデバイスまたはユニットをラインに戻す等のプラント10に対して実行されるべきプラント10の最大級の最適化をもたらす変更を決定することが可能である。当然ながら、ここで言及したものの代わりに、またはこれらに加えて、他のタイプの最適化ルーチンを実行することもできる。
上記論議の結果、モデルの使用は、ビジネス・アプリケーション、プロセス制御アプリケーション及び資産保全及びパフォーマンス監視アプリケーションに多くの新しいタイプのデータまたは情報をもたらすことが分かる。特にモデルは、パフォーマンス監視を実行するためと、プラント内のデバイス、ユニット、エリア、他の相対パフォーマンスを示すパフォーマンス指標を生成するために使用されることが可能である。このパフォーマンス指標は、そのエンティティの可能パフォーマンスに対するエンティティ・パフォーマンスの測度である可能性がある。さらに、これまではデバイス及びユニット・モデルについて論じてきたが、ループ、ユニット、他等のプロセス制御エンティティについても同様のモデルを作って実行し、これらのタイプのエンティティについてもパフォーマンス測度及び最適化基準を供給することが可能である。また先に示したように、場合によってモデルは、所定のデバイスまたは他のエンティティのヘルスを測定または指摘しかつこれらのエンティティを示すヘルス指標を供給するために使用されることが可能である。例えば、所定のモデル上で使用される回帰分析により決定される所定の入出力センサのエラー測定は、これらのデバイスのヘルスの表示として使用される、または上記表示へと変換されることが可能である。また、モデルを基礎とするモデル・パラメータ及び仮想センサ測定値等の、別の方法ではプロセス・コントローラには利用不可能である他の情報も、多くの方法で使用するためにプロセス・コントローラへ、またはビジネス要員へ供給される可能性がある。
パフォーマンス及びヘルス指標の他にも、資産活用スート50は、活用指標及び可変性指標等の他のタイプの指標の生成に際して指標発生ルーチンをアシストすることができる。可変性指標は、デバイス、ループ、ユニット、他へ出入りする何らかの信号またはこれらに関連づけられる何らかの他のパラメータが、この信号またはパラメータに関して予測される変化程度に比べてどの程度変化するかを示す。この可変性指標の生成に必要なデータは、データ収集及び分配システム102を介して資産活用スート50により収集され、所望される任意の時間または都合の良い時間に指標発生ルーチンへ供給されることが可能である。当然ながら、信号またはパラメータの正常な変量は、エンティティに精通するメーカー、エンジニア、オペレータまたは保全要員により設定される場合もあれば、プラント内のそのエンティティまたは他の類似エンティティに関連づけられる統計測度(平均、標準偏差、他等)を基礎とする場合もあり、この正常な、または予測される変動は指標発生ルーチンによって格納される、または上記ルーチン内で更新されることが可能である。
ある形態または別の形態の活用指標は個々のループまたは他のエンティティの活用を追跡または反映し、これらのエンティティが先行して決定されたベンチマークまたはオペレーション目標を基礎として活用されているかどうかに関する何らかの表示を供給することが可能である。活用指標は、実際のデバイスの測定された使用回数を基礎として発生されることが可能である。例えばデバイスは、所望の活用に比べてプロセス内でどの程度の頻度で使用されているかを測定されることが可能である。活用指標は、所望に応じて、使用されていないループ、他を識別する場合もある。
先に示したように、ユーザ・インタフェース・ルーチン244は、資産活用スート50により供給される様々な資産活用ケイパビリティとユーザとの相互作用を促進させるために、本明細書に記載した資産活用スート50と統合されるグラフィック・ユーザ・インタフェース(GUI)を供給する。但しGUIをさらに詳しく論じる前に、GUIは任意の適切なプログラミング言語及び技術を使用して実装される1つまたは複数のソフトウェア・ルーチンを包含する可能性のあることは認識されるべきである。さらに、GUIを作り上げるソフトウェア・ルーチンは、例えばプラント10内のワークステーション、コントローラ、他等の単一の処理ステーションまたはユニット内に格納されかつ処理される場合もあれば、代替としてGUIのソフトウェア・ルーチンは、資産活用システム内で互いに通式可能に接続される複数の処理ユニットを使用して分散的に格納されかつ実行される場合もある。またさらに、所定のスクリーンを生成するためにGUIにより使用されるデータは、外部のデータ・ソースからデータ収集及び分配システム102を介してアクセスされることが可能である。
必須ではないが好適には、GUIは、相互にリンクされた複数のグラフィック・ビューまたはページがユーザによるページを通じた所望の方法によるナビゲートを有効化して特定タイプの情報を見る、及び/または検索できるようにするごく普通のグラフィック・ウィンドウ・ベースの構造及び外観を使用して実装されることが可能である。上述の資産活用スート50の機能及び/またはケイパビリティは、GUIの1つまたは複数の対応するページ、ビューまたはディスプレイを介して表示、アクセス、呼び出し、他をされることが可能である。さらに、GUIを作り上げる様々なディスプレイは、特定タイプの情報を検索する、または資産活用スート50の特定のケイパビリティにアクセスする、及び/またはこれを呼び出すためのディスプレイを通じたユーザによる迅速かつ直観的なナビゲーションを促進するために論理的な方法で相互にリンクされることが可能である。
ある実施形態では、先の図5と同様に、GUIは、プロセス制御システムの本質(プラント内のエリア、ループ、デバイス、コントローラ・ルーチンのパフォーマンス監視アプリケーション、他等)に関するより基本的または一般的な情報がより高位レベルのディスプレイにおいて何らかの方法で表示される、一組または一連の階層ディスプレイを実行または表示することが可能である。次いで、高位レベルのディスプレイ内の任意の特定情報を選択してクリックすればアクセスされることが可能な一連の後続の下位レベル・ディスプレイは、制御ルーチン、保全ルーチン、プロセス制御機器の相互接続及び実際のパフォーマンス測定値、警報、問題点、他等のプロセス制御ルーチン・アクティビティ、パフォーマンス推奨、予測、他等のパフォーマンス測定値及びプラント内で発生する問題点、他等の保全情報に関してさらなる情報を提供することが可能である。他の下位レベルのディスプレイは次に、これらのディスプレイにおけるエレメントに関してさらなる情報を提供することが可能である。概して、このような階層的ディスプレイは、ユーザがディスプレイにおいてより下位のレベルへと掘り下げて進んでいくにつれて、特定のエリア、ループ、他に関するさらなる情報及びプロセス制御アクティビティ、保全アクティビティ及びプロセス・パフォーマンス・アクティビティの視点からこれらに関連づけられる問題点を供給する。
一般的に言えば、本明細書に記載したGUIは、プロセス制御のエリア、ユニット、ループ、デバイス、他の直観的なグラフィック描写またはディスプレイを供給する。これらのグラフィック・ディスプレイの各々は、GUIにより表示されている特定のビューに関連づけられる多くの状態及びパフォーマンス指標(その幾つか、または全ては上述の指標発生ルーチンにより発生され得る)を含むことが可能である。例えば、プロセス制御エリアを描写するディスプレイは、そのエリア(即ち、特定レベルの機器階層におけるプロセス制御システムの特定部分)の状態及びパフォーマンスを反映する指標セットを供給することが可能である。これに対して、ループを描写するディスプレイは、その特定ループに関連づけられる状態及びパフォーマンス指標セットを供給することが可能である。何れにしてもユーザは、任意のビュー、ページまたはディスプレイ内に示される指標を使用して、そのディスプレイ内に描写される任意のデバイス、ループ、他内に問題点が存在するかどうかについて迅速にアクセスすることが可能である。
さらに、本明細書に記載したGUIは、自動的に、またはユーザによる要求に応答してユーザへ保全情報を提供することが可能である。保全情報は、資産活用スート50の任意の部分によって提供されることが可能である。同様にGUIは、同じく資産活用スート50によって提供されることが可能な警報情報、プロセス制御情報、他を表示することが可能である。またさらにGUIはユーザへ、プラント10内で発生した、または発生しつつある可能性のある問題点に関してメッセージを供給することが可能である。これらのメッセージは、問題点を説明し、現行の問題点を軽減するために実装されることが可能でありかつ潜在的な問題点を回避するために実装されることが可能なシステムに加える可能な変更を提案し、問題点を是正または回避するために遂行され得るアクション課程を記述する、他のグラフィック的及び/または文字による情報を包含することが可能である。
またさらに、本明細書に記載したGUIは、自動的に、またはユーザによる要求に応答してユーザへプロセス・パフォーマンス情報を提供することが可能である。プロセス・パフォーマンス情報は、資産活用スート50の任意の部分によって提供されることが可能である。このようなパフォーマンス・データまたは情報は、パフォーマンスの測度、予測またはパフォーマンスを変えるためのプロセス変更に関するユーザへの推奨事項を含むことが可能であり、システムによって現行使用されているパフォーマンス目標の入力または表示、他を含むことが可能である。
図8は、GUIによって表示されることが可能なプロセス制御システム内のユニット500を表示するディスプレイの例示的描写である。図8に示すように、ユニット500は、例えば全て図のようにグラフ表示されることが可能であるバルブ、ポンプ、温度発信器、他等の複数のデバイスを含む。加えて、本ディスプレイはさらに、矢印線及び様々なデバイス間の論理的及び物理的相互接続を表す他の任意の印を含むことが可能である。当然ながら、プロセス制御システム(またはプロセス制御システムの一部)のこのようなグラフィック表示は技術上周知であり、よってここではこれらのグラフィック表示またはディスプレイの実装方法の詳述を省く。
図8に示すGUIディスプレイはまた、複数の指標名及び値550を含む。特に、指標名及び値550はパフォーマンス指標、ヘルス指標、可変性指標及び活用指標を含むが、これらについては全て、先に資産活用スート50及びその指標発生ルーチンに関連して簡単に論じた。指標名及び値550は、図のように表の様式で、または他の任意の所望されるフォーマットで表示されることが可能である。指標名及び値550はユニット500全体のパフォーマンス及びステータスを表示し、よって図示される指標値は、必須ではないが好適には、指標値またはユニット500を作り上げるサブユニット及び/またはデバイスの各々に関連づけられるフィールドで構成される。
GUI及び、資産情報、プロセス制御情報、保全情報、診断情報、パフォーマンス情報または他の任意タイプの情報がGUIによりユーザに表示される方法について論じる前に、以下、パフォーマンス及びステータス指標が発生される方法について簡単に論じる。同じく、パフォーマンス指標、ヘルス指標、可変性指標及び活用指標についてもここではGUIの様々なディスプレイに関連して詳述するが、追加的及び/または異なる指標が資産活用スート50により発生されかつGUIを介して表示され得ることは理解されるべきである。また、GUIにより表示されるデータの幾つか、または全ては外部のデータ・ソースから到来する可能性があることも理解されるであろう。
概して、指標発生ルーチンにより発生されかつGUIを介して表示される指標は、個々のデバイス別、デバイスの論理的及び/または物理的グループ別、論理的プロセス(例えば制御ループ)別、ユニット及びエリア等のプロセス機器の論理的グループ別、他で計算されることが可能である。言い替えれば、指標は原則として、プロセス制御システムまたはより一般的に言えば1つまたは複数のプロセス制御システムを含むことが可能な資産活用システムの機器及び論理的階層の各レベルにおいて計算されることが可能である。但し、特定指標の意味は、指標が発生されかつ表示されるコンテキスト(即ち、指標がデバイス及び/またはパラメータの論理的または物理的グループ分けに対応しているかどうか)に依存する可能性があり、かつそれが表示される階層レベルに依存する可能性がある。例えば、機器階層の最下位レベルでは、指標はバルブ、温度センサ、アクチュエータ、他等の物理的デバイスに対応する。よって、各デバイスは、デバイスの製造時にデバイス内に格納される情報を基礎としてデバイス内で、またはデバイスに関して発生される可能性のある固有の指標セットを有することが可能である。従って、各デバイスはその指標を発生させて高位の階層レベルへ、かつ必要に応じて資産活用スート50へ供給することが可能である。
同様に、その各々が1つまたは複数のデバイスまたはファンクション・ブロックで構成されるユニットまたはループは、各々が固有の指標セットを有することが可能である。当然ながら、論理的及び機器階層のあらゆるレベルに関してパフォーマンス、ヘルス、可変性及び活用の各指標のうちの1つまたは複数を計算することは適切でない、必要でない、または有益でない場合がある。これらの指標の何れか、または全ては、システム内のデバイスまたは他のエンティティのヘルスを示すことが可能である。例えば、デバイスのヘルス指標(HI)は、そのデバイスの使用履歴を基礎とすることが可能である。特に、デバイスのメーカーはそのデバイスのライフサイクルに関する情報をデバイス内に格納することが可能であり、デバイスの使用及びそのオペレーションの間にデバイスに加わる環境的影響(例えば温度変化、衝撃、他)を基礎として、デバイスは、デバイスがそのライフサイクル曲線沿いにどの程度移動してきたか(即ち経年数)を決定することが可能である。メーカーは、デバイスのライフサイクルのカレント・ステータスを示すHI値を供給するようにデバイスをプログラムすることが可能である。例えば、ストローク型のバルブは、フルストローク25,000回の予測された有効オペレーティング・ライフサイクルを有することが可能であり、典型的にはスマート・フィールド・デバイスであるストローク・バルブ・デバイスのメーカーは、そのメモリに予測された寿命オペレーティング・ストローク数をそのバルブが完了しているカレント・ストローク数と共に格納している。従って、HI値が良好、要早期保全(NMS)及び要即時保全(NMN)へと及ぶ可能性のある場合には、発生されるHI値はゼロから250,000までの範囲のストローク数を基礎とする可能性がある。当然ながら、HI値とライフサイクル特性(ストローク数等)との間の正確な関係性は線形でない可能性がある。これに対して、多くのライフサイクル特性は指数関数的特性に準じ、これにより、デバイスのパフォーマンス/オペレーションにおける不良及び劣化は、時間の経過、ストロークの完了、他に伴ってより高速で進行する。当然ながら、デバイスの検出されたカレント状態及びその作動状態如何を基礎としてデバイスのHIを定義または計算する方法は、他にも多く存在する。これに対してループのHIは、必須ではないが好適にはループを作り上げるファンクション・ブロックを基礎としている。
同様に、ループ、エリア及びユニットの各レベルに関して計算されるUIは、特定の資産(例えばループ)がその容量または所望される活用に比較してどの程度活用されているかを表わす。例えばUI値は、ループが所望通りに制御を実行するために使用されている時間量を基礎とする可能性がある。
ループ、サブユニット、ユニット及びエリアの各階層レベルについて指標値を形成するためのデバイス指標値の数学的組合せは、加重和または加重平均もしくは他の任意の適切な数学的組合せを使用することが可能である。当然ながら、論理的及び機器階層のあらゆるレベルに関してパフォーマンス、ヘルス、可変性及び活用の各指標のうちの1つまたは複数を計算することは適切でない、必要でない、または有益でない場合がある。図9は、システム階層のデバイス、ループ、サブユニット及びユニットの各レベルに関してパフォーマンス指標(PI)、ヘルス指標(HI)、可変性指標(VI)及び活用指標(UI)が発生され得る、または発生され得ない一つの方法を示す表の例である。図9に示すように、PIは、ユニット及びサブユニットの各レベルに関して発生されることが可能である。ユニット及びサブユニットの各レベルでは、PIは、ユニットまたはサブユニットのモデル(モデル56の1つ等)を上記ユニットまたはサブユニットの実際のパフォーマンスと比較することにより、または他の任意の所望される方法で計算されることが可能である。特に、このコンテキストにおける(即ち階層のユニット及びサブユニットの各レベルでの)PIは、例えば理論的最大値に対する、もしくは実際のシステム・パフォーマンスを基礎とする経験的に導出された最大効率に対する効率であることが可能である。図9に示す表はまた、個々のデバイスまたはループに関してはPIを計算する必要のないことを示している。しかしながら、アプリケーションによっては、ループ及びデバイスに関してPIを計算することが望ましい場合がある。例えば、デバイスに関してPIを計算する場合、デバイスのメーカーはデバイス内にパフォーマンス情報を格納することが可能であり、よってオペレーションの間、デバイスは、実際のパフォーマンス特性(例えば運転効率等)と理論上最大のデバイス効率を含む可能性のある格納されたパフォーマンス情報との比較を基礎としてPIを計算することが可能である。当然ながら、指標発生ルーチン51もまたこの機能を実行することが可能である。ループに関してPIを計算する場合、システムは、例えばループの最大または平均エラー(即ち定常状態のエラー信号)を理想的にはゼロである可能性のある何らかの予め決められたエラー最小値と比較することが可能である。この方法では、少ないループ・エラーが良好なパフォーマンスを示すPI値に対応する可能性がある。
図9はまた、ループ及びデバイスの各階層レベルに関してVIが計算され得ることを示す。デバイス・レベルでは、VIは、デバイス出力の変化または偏差を、予測される、または所望の変化または変動量と比較することにより計算されることが可能である。VIの過度の高値または過度の低値は、デバイスの不良または機能不全或いはおそらくは切迫した不良または機能不全を示す可能性がある。同様にループ・レベルでは、ループ出力の過度に頻繁な、または程度の大きい変化は問題点を示す可能性がある。何れにしても、ループ及びデバイスに関するVIは、パラメータの実際の可変性と、理論的または経験的に決定されることが可能な予測されるパラメータ可変性との比較を基礎とすることが可能である。図9は、VIがユニット及びサブユニット・レベルに関しては計算されない可能性のあることを示しているが、アプリケーションによっては、これらのレベルに関してVIを発生させることが望ましい場合がある。
図9は、HIがデバイス、ループ、サブユニット及びユニットの各レベルに関して計算されることを示す。デバイスのHIは、そのデバイスの使用履歴を基礎とすることが可能である。特に、デバイスのメーカーはそのデバイスのライフサイクルに関する情報をデバイス内に格納することが可能であり、デバイスの使用及びそのオペレーションの間にデバイスに加わる環境的影響(例えば温度変化、衝撃、他)を基礎として、デバイスは、デバイスがそのライフサイクル曲線沿いにどの程度移動してきたか(即ち経年数)を決定することが可能である。メーカーは、デバイスのライフサイクルのカレント・ステータスを示すHI値を供給するようにデバイスをプログラムすることが可能である。例えば、ストローク型のバルブは、フルストローク250,000回の予測された有効オペレーティング・ライフサイクルを有することが可能であり、典型的にはスマート・フィールド・デバイスであるストローク・バルブ・デバイスのメーカーは、そのメモリに予測された寿命オペレーティング・ストローク数をそのバルブが完了しているカレント・ストローク数と共に格納している。従って、HI値がゼロから10の範囲(ゼロは不良ヘルスを表し、10は完璧ヘルスを表す)である可能性のある場合には、バルブにより発生されるHI値は、ストローク数がゼロから250,000まで上がるにつれてゼロから10の範囲に及ぶ可能性がある。当然ながら、HI値とライフサイクル特性(ストローク数等)との間の正確な関係性は、線形でない可能性がある。これに対して、多くのライフサイクル特性は指数関数的特性に準じ、これにより、デバイスのパフォーマンス/オペレーションにおける不良及び劣化は、時間の経過、ストロークの完了、他に伴ってより高速で進行する。当然ながら、デバイスの検出されたカレント状態及びその作動状態如何を基礎としてデバイスのHIを定義または計算する方法は、他にも多く存在する。例えば、デバイスにさほど重要でない問題点が2つ検出されていれば、そのHIは低下する可能性がある。
これに対して、ループのHIは、必須ではないが好適には、ループを作り上げる個々のデバイスまたはファンクション・ブロックに関するHI値の数学的組合せ(例えば加重和または加重平均等)である。同様に、サブユニット及びユニットの各レベルのHI値はまた、ループ及びサブユニットの基本的HI値の数学的組合せである可能性もある。よって結局は、デバイス・レベルより上のレベルのHI値階層は、合成値へと形成されているデバイスに関する1つまたは複数のHI値を基礎としている。
同じく図9に示すように、UIはループ、サブユニット及びユニットの各レベルに関して計算されることが可能であるが、デバイス・レベルに関しては必ずしも計算されない可能性がある。一般的に言えば、UIは、特定の資産(例えばループ、サブユニットまたはユニット)がその容量または所望される活用に比較してどの程度活用されているかを表わす。例えばUI値は、ユニット、サブユニットまたはループが所望通りに制御を実行するために使用されている時間量を基礎とする可能性がある。さらに、または代替として、UI値は、ループ、サブユニット及び/またはユニットによって処理されている材料の量とそのループ、サブユニット、ユニット、他によって処理されることが可能な最大量との比較を基礎とすることが可能である。
図10は、図8に示すユニット500のPIが計算され得る方法を描写する例示的チャートである。図10に示すように、ユニット500を作り上げる複数のループ575の各々は、その独自のPIと加重係数とを有するが、これらはユニット500のオペレーション全体に対するその特定ループの相対重要度を基礎としてユーザに選択または定義されることが可能である。ループ575の指標及び/または加重は、次にユニット500のPI値83.2に到達すべく加重平均を使用して数学的に組み合わされることが可能である。
同様にして、ユニット500のHIも、ユニット500を作り上げるデバイス(及び/またはループ)の全てに関するHI値の加重平均として計算されることが可能である。図11に示すもののような表は、加重平均に包含されるべき値を表すために使用されることが可能である。同じく図11に示すように、特定のデバイス及び指標値に文章記述を関連づけることも可能である。文章によるこれらの記述は、HI値及びこのHI値に関連づけられる特定のデバイスを基礎として診断情報、保全情報、他を供給することが可能である。
図12は、図8に示すユニット500等のユニットに関してVIが計算され得る一方法を示す例示的な表である。HIの場合のように、図8のユニット500に関して計算されるVIは、ユニット500を作り上げる個々のデバイス、ループ及び/またはサブユニットに関するVI値の加重平均を基礎とする。当然ながら、GUIはユーザに図10乃至12に示すもの等の加重平均データを見る能力を与え、かつユーザが重みを変更できるようにすることが可能である。
図13は、ユーザがプラント10内のユニット、サブユニット、ループ、デバイス、他のパフォーマンスを監視できるようにするためにGUIにより供給されることが可能なディスプレイの例示的なグラフ描写である。図13に示すように、様々な指標の値は時間の関数としてプロットされることが可能であり、これによりユーザは、問題点を暗示する可能性のある任意の傾向または他の任意の時間ベースの変化をより直観的に分析することができるようになる。さらに、このようなグラフ描写はまた、様々な指標における変化間の重要な相関性または関係性を明らかにすることが可能である。例えばユーザは、低下する、または低いHI値と上昇する、または過度に高いVI値との関係をより容易に同定する能力を有することが可能である。
またさらにGUIは、図13に示すグラフ表示内に、または他の何らかのディスプレイまたはページに、表示される指標値またはその変動に関連する可能性のある現行の、または潜在的な問題点をユーザに指摘する文章メッセージを提供することも可能である。これらの文章メッセージは、同定されている問題点に対する可能ソリューションを同定することが可能である。図13内に描写したグラフィック情報は、指標がパーセントで表されかつ時間軸が月単位でラベリングされるようにスケーリングされているが、代わりに他の任意の単位及び表示分解能を使用することも可能である。例えば、指標が高速で変化している可能性がある、または高速で変化することもある場合には、GUIはユーザが指標値を、所望されれば時間ベースで、毎分、数秒毎またはさらに高頻度(即ち、より高い時間分解能)で表示できるようにすることが可能である。
図14は、ユーザがプラント10内の制御エリアのオペレーション・ステータス及びパフォーマンスを迅速に分析できるようにGUIによって供給されることが可能な例示的グラフ表示である。図14に示すように、GUIは、制御エリア600内の物理的機器(及びこれらの間の相互接続)をグラフィック描写することが可能である。当然ながら、図14に示すGUIディスプレイには制御エリアが描写されているが、代わりに例えばユニット、サブユニット、ループ、デバイス、他等のプラント10の他の任意の部分を描写して同じ、または類似の結果を達成し得ることは認識されるべきである。何れにしても、制御エリア600は、全てが図14に示すように相互接続されることが可能な1対のタンク、複数の温度発信器、圧力発信器、フロー発信器、他及び配管を有するものとして描かれている。さらに、物理的デバイスの各々は、プラント10内のそのデバイスを一意に同定する関連の英数字識別子(例えばTT-394)と共に表示されることが可能であり、またユーザがそのデバイスに関連づけられる検出パラメータのステータスを即座に決定できるようにするグラフ・メータまたはゲージ(即ち、部分的に陰影をつけられた半円形状のもの)と共に表示されることも可能である。例えばGUIは、温度発信器に関連づけられるグラフ・メータまたはゲージを表示することが可能であり、かつ温度発信器によって現行検出されている温度を基礎としてメータの幾分かに陰影をつけることが可能である。VI、HI、UI及びPI値のうちの1つまたは複数は、エリア600内に示したデバイスのうちの1つまたは複数に関して表示されることが可能である点は重要である。本図では単なる例示として、エリア600内のタンク610に接続されるデバイスのうちの幾つかに関してHI値が表示されているが、所望されれば、より多い、または少ないHI値が表示されることも可能である。さらに、所望に応じて、エリア600内に出現するデバイスのうちの任意のものに関して、異なる指標値または指標値グループが表示されることも可能である。図14に示すディスプレイから認識され得るように、ユーザはエリアが適正に機能していて、引き続き適正に機能していくかどうかを即座に確認することができる。またユーザは、注意する必要のある可能性のある、かつ/または特定の問題を発生させつつある可能性のあるデバイス、ユニット、サブユニット、他を即座に識別することもできる。
また、ユーザはプラント内のより下位のエンティティを順次連続して見ることが可能であり、かつこれらの異なるエンティティまたはビューの各々に関連づけられる指標に関する情報を供給され得ることも理解されるであろう。従って例えば、ユーザはプラントのビューに目を通して、プラント固有の指標セットを見ることが可能である。次いでユーザは、プラント・ビュー内のエリアの1つをクリックする等により1つのエリアに注目し、そのエリアに関連づけられる指標を見ることが可能である。同様に、表示されたエリア内のユニットをクリックすれば、異なるユニットに関する指標を見ることが可能である。次いで同様に、ループ、サブユニット、デバイス、他の指標も、これらのエンティティが位置づけられているエンティティ・ビューからこれらの異なるエンティティにフォーカスすることにより見ることが可能である。このようにして、ユーザは、プラントの任意のポイントまたはレベルにおいて予測より低い(または高い)指標の原因を即座に発見することができる。
図15は、ユーザがエリア600内で使用される任意のデバイスに関して監査証跡を見ることを有効化するためにGUIにより供給されることが可能なディスプレイの例示的な描写である。例示として、ユーザは、マウスを使用して所定のデバイスまたはその英数字識別子をクリックし、もしくは代替としてキーボードを介して識別子を入力し、そのデバイスの監査証跡のポップアップ・ウィンドウ650を要求することが可能である。このようにして、ユーザは監査証跡情報を使用し、デバイスの適正な、または時宜を得た方法での較正ができないことに不適正または受け入れられない指標値が関係している可能性があるかどうか、デバイスが適正に構成されていたかいなかったか、他を決定することができる。
図16は、ユーザがエリア600内の特定デバイスに関する指標のうちの1つまたは複数を発生させる際に使用され得るデータのより詳細な分析を実行すること、または状態監視を実行することを有効化するためにGUIにより供給されることが可能なディスプレイの例示的な描写である。単なる例示として、ポップアップ・ウィンドウ680にはモータ675に関する振動分析が表示されることが可能である。ユーザは、モータ675に影響されるユニットに関する異常に高い、または異常に低い指標値に応答してこのようなポップアップ・ウィンドウを要求することが可能であり、かつ/またはモータに関連づけられる指標値が問題の可能性を示していればこのウィンドウを要求することが可能である。さらに、所望されればGUIは、1つまたは複数の異常な指標値を有するデバイス、ユニット、他に関する詳細なデータ分析を含むこのようなポップアップ・ウィンドウを自動的に供給することが可能である。同様に図17も、ユーザがエリア600内のデバイスのパフォーマンス特性をグラフで見る、または監視することを有効化するためにGUIにより供給されることが可能なディスプレイの例示的な描写である。例示として、モータ675の効率を表すグラフを含むポップアップ・ウィンドウ690は、ユーザによる要求に応答して、または資産活用エキスパート59による自動的な要求に応答して供給される。このようなポップアップ・ウィンドウは、タンク610によって実行されているプロセスの一部に関連づけられる1つまたは複数の指数値が異常であれば要求される、または必要とされる可能性がある。特に本例では、ユーザは、モータ675が不良PI値を有すること、及び/またはエリア600が不良PI値を有することを認識することが可能である。その結果ユーザは、モータ675に伴って問題が存在するかどうかを決定するために、ポップアップ・ウィンドウ690内に含まれるもの等のより詳細な情報を要求することが可能である。また本例では、ポップアップ・ウィンドウは、実際の効率データ700を理論的または経験的に導出された最大効率データ710に対比させてグラフ表示したモータ675の経時的効率を示すグラフを含むことが可能である。先に論じたように、これらの2つの効率データ・セットは、例えば理論的最大効率に対する実際の効率の割合をPI値として使用することによりモータ675の経時的なPI値を計算するためにも使用されることが可能である。
図18は、ユーザがプラント10内の警報情報、状態、他を即座に調査できるようにするためにGUIにより供給されることが可能なディスプレイのさらに別の例示的描写である。プラント10の高レベル・グラフィック・ビュー750は、1つまたは複数の緊急警報を有する警報バナー760を含むことが可能である。警報バナー内の警報の各々は、警報またはイベントを発生したデバイスに一意に関連づけられる英数字インジケータを使用して表示されることが可能である。加えて、バナー760内の警報の各々は情報ボタン770も含むことが可能であり、これは、その特定の警報に関するより詳細な情報を含むポップアップ・ウィンドウ775を発生させるためにユーザにより選択されることが可能である。さらにユーザは、特定の警報を引き起こすデバイスの英数字指示子を選択し、その警報の考えられる理由を調べることも可能である。英数字指示子が選択されると、GUIによりポップアップ・ウィンドウ780が供給されることが可能である。ポップアップ・ウィンドウ780は1つまたは複数の応答カテゴリ785を供給することが可能であり、これらは、特定の警報が如何に対応されるべきか、及び警報は如何なる時間枠内で対応されるべきか、に関するユーザの理解を容易にすることが可能である。例示的に、ポップアップ・ウィンドウ780は、特定のデバイスがもはや通信状態にないこと、デバイスが故障していること、デバイスが即時保全を必要とすること、またはデバイスが早急な保全または他の何らかの注意を要することを指示する可能性がある。当然ながら、代わりに、より多い、少ない、かつ/または異なる応答カテゴリを使用することも可能である。この時点でGUIにより発生される警報ディスプレイは、本参照により明示的に開示に含まれる(2000年11月7日 出願の)米国特許出願第09/707,580号に開示されている統合されたディスプレイであることが可能である。概してこの警報ディスプレイは、プロセス警報及び警告及び保全警報及び警告のような他のタイプの警報を示すことが可能である。さらに、警報バナーのフィールド775に供給される特定情報等の警報に関する情報はGUIへ、または資産活用エキスパート59へ警報と共に送られることが可能である。
データ収集及び分配システム102、資産活用スート50及び他のプロセス・エレメントは、好適にはソフトウェアに実装されるものとして説明してきたが、これらはハードウェア、ファームウェア、他に実装される場合もあり、かつプロセス制御プラント10に関連づけられる他の任意のプロセッサにより実装される場合もある。従って、本明細書に記述したエレメントは、所望に応じて、規格汎用CPUに、またはアプリケーション指定集積回路(ASIC)等の特別に設計されたハードウェアまたはファームウェア上に、もしくは他のハードワイヤード・デバイス上に実装されることが可能である。ソフトウェアに実装される場合、ソフトウェア・ルーチンは、コンピュータまたはプロセッサのRAMまたはROM、任意のデータベース、他における磁気ディスク、レーザ・ディスクまたは他の記憶媒体上等、任意のコンピュータ読取り可能メモリに格納されることが可能である。同様に、このソフトウェアはユーザまたはプロセス制御プラントへ、例えばコンピュータ読取り可能ディスクまたは他のトランスポート可能コンピュータ記憶メカニズム上、または電話回線、インターネット、他等の通信チャネル上(このようなソフトウェアをトランスポート可能記憶媒体を介して供給することと同じである、または互換性があるとされている)を含む任意の周知または所望の配信方法を介して配信されることが可能である。また、スート50は規則ベースのエキスパートである、または上記エキスパートを使用する可能性があるものとして記述されているが、他の周知のデータ・マイニング技術を使用するものを含む他のタイプのエキスパート・エンジンも使用される可能性がある。
次に図19を参照すると、資産活用エキスパート59とプロセス・プラント10内の他のコンピュータ・ツールまたはアプリケーションとの間のデータ・フローのうちの幾つかを示すデータ・フロー図が提示されている。図1を参照して、図19を説明する。特に資産活用エキスパート59は、プロセス・プラント10内のマルチプレクサ、発信器、センサ、手持ち式デバイス、制御システム、無線周波数(RF)トランシーバ、オンライン制御システム、ウェブ・サーバ、ヒストリアン、制御モジュールまたは他の制御アプリケーション等の多くのデータ・コレクタまたはデータ・ソースと、ユーザ・インタフェース及びI/Oインタフェース並びにバス(例えばFieldbus、HART及びイーサネット(登録商標)・バス)、バルブ、トランシーバ、センサ、サーバ及びコントローラ等のデータ・サーバと、プロセス・インスツルメント、回転機器、電気機器、発電機器、他等の他のプラント資産とから情報を受信することが可能である。このデータは、データが他の機能システムにより如何に発生され、または使用されるか、を基礎として任意の所望される形式をとることができる。またさらに、このデータは、先に論じたXMLプロトコル等の任意の所望される、または適切なデータ通信プロトコル及び通信ハードウェアを使用して資産活用エキスパート59へ送られることが可能である。但し一般的に言えば、プラント10は、資産活用エキスパート59がデータ・ソースのうちの1つまたは複数から特別な種類のデータを自動的に受信し、かつ資産活用エキスパート59がそのデータに関連して予め決められたアクションをとることができるように構成される。
また資産活用エキスパート59は、今日現行供給されている典型的な保全データ分析ツール等のデータ分析ツール、デバイスに関連づけられるもの等のパフォーマンス追跡ツール及び既に述べた米国特許出願第09/256,585号及び第09/499,445号に記載されているようなプロセス制御システムのパフォーマンス追跡ツールから情報を受信する(かつ実際にこれらを実行することが可能である)。データ分析ツールはまた、例えば所定タイプの問題点の根本的原因を検出する根本原因診断アプリケーション、米国特許第6,017,143号に記載されているようなイベント検出、本参照により明示的に開示に含まれる米国特許出願第09/303,869号(出願日、1999年3月3日)に開示されているような定期的なループ診断、本参照により明示的に開示に含まれる米国特許出願第09/257,896号(出願日、1999年2月25日)に記載されているような衝撃ライン・プラギング検出アプリケーション、他のプラギング・ライン検出アプリケーション、デバイス・ステータス・アプリケーション、デバイス構成アプリケーション及び保全アプリケーション、AMS等のデバイス記憶、ヒストリアン及び情報表示ツール、エクスプローラ・アプリケーション及び監査証跡アプリケーションを含むことが可能である。またさらにエキスパート59は、高度制御エキスパート52、本参照により明示的に開示に含まれる米国特許出願第09/593,327号(出願日、2000年6月14日)及び第09/412,078号(出願日、1999年10月4日)に記載されているもの、調整ルーチン、ファジー論理制御ルーチン及びニューラル・ネットワーク制御ルーチン等のモデル予測制御プロセス・ルーチン等のプロセス制御データ分析ツールからと、プロセス制御システム10内に供給されることが可能な米国特許第5,680,409号に記載されているもの等の仮想センサから、データ及び任意の情報を受信することができる。またさらに資産活用エキスパート59は、オンライン振動、RF無線センサ及び手持ち式データ収集ユニット等の回転機器関連のデータ分析ツールから、及び回転機器、サーモグラフィ、超音波システム及びレーザ・アラインメント及びバランシング・システムに関連づけられるオイル分析から情報を受信することが可能であり、これらは全て、プロセス・プラント10内の回転機器の問題点またはステータスの検出に関連づけられることが可能である。これらのツールは現時点で技術上周知であり、よってここでは詳述を省く。またさらに資産活用エキスパート59は、任意の所望される電力管理及び電力機器監視及び分析ツールを含むことが可能な図1のアプリケーション23及び27等の電力管理及び電力機器及び供給品に関するデータを受信することが可能である。
ある実施形態では、資産活用エキスパート59は、例えばコンピュータ30またはプロセス・プラント10内の他の任意の所望されるコンピュータによって実行されるデバイス・モデル、ループ・モデル、ユニット・モデル、エリア・モデル、他等のプラント10内の幾つかの、または全ての機器の数学的ソフトウェア・モデル56を実行する、または実行を監視する。資産活用エキスパート59は、これらのモデルによって展開される、または関連づけられるデータを幾つかの理由で使用することが可能である。このデータ(またはモデル自体)の幾つかは、プラント10内に仮想センサを供給するために使用されることが可能である。このデータまたはモデル自体の幾つかは、プラント10内の予測制御またはリアルタイム最適制御を実装するために使用されることが可能である。モデル56によって発生されるデータの幾つかは指標発生ルーチン51によって使用されることが可能であり、ビジネス及びプロセス制御アプリケーション等の他のアプリケーションで使用される指標が発生される。
資産活用エキスパート59は、データをその発生に伴って、または所定の周期的時間で例えばバス32またはプロセス・プラント10内の他の任意の通信ネットワーク上で受信する。その後、資産活用エキスパート59は周期的に、または必要に応じてデータを他のアプリケーションへ再配信し、またはそのデータを使用してプロセス・プラント10の異なる態様の制御またはオペレーションにおいて有益な他の情報を発生させかつこれをプラント10内の他の機能システムへ供給する。特に資産活用エキスパート59は、データを供給して指標発生ルーチン51にプロセス・プラント10内のデバイス、ユニット、ループ、エリアまたは他のエンティティに関連づけられるパフォーマンス指標、活用指標、ヘルス指標及び可変性指標等の一連の合成指標を生成させることが可能である。これらの指標の発生及び使用については、ここでまたさらに詳しく論じる。
資産活用エキスパート59はまた、プロセス・コントローラまたはこれらのコントローラに関連づけられるインタフェース内に配置されることが可能な制御ルーチン862、オプティマイザ55、ビジネス・アプリケーション863、保全アプリケーション866、他へデータを供給しかつこれらからデータを受信することが可能である。
さらに、(予測プロセス・コントローラを含む可能性のある)制御エキスパート865は、嘗てはそれが制御していたデバイスが正常に作動しているか全く作動していないかの何れかであると想定するだけであったが、資産活用エキスパート59から、上述の活用、可変性、ヘルスまたはパフォーマンスの各指標等のそれが制御しているデバイスのステータスまたはヘルスに関する情報、またはプロセスを制御しようとする際に考慮され得るデバイス、ループ、他のオペレーティング・ステータスに関する他の情報を受信することができる。予測コントローラ865及びオプティマイザ55は、ユーザ・インタフェース・ルーチン58へ追加の情報及びデータを供給することが可能である。予測コントローラ865またはオプティマイザ55は、ネットワーク内のデバイスの実際のカレント・ステータスに関するステータス情報を使用し、同時に例えばビジネス・アプリケーション863により定義される通りの資産活用エキスパート59から供給されるビジネス・ソリューション・ソフトウェアによって同定されるもの等の目標及び将来のニーズを考慮して、制御システム内の予測事項を基礎として制御を最適化することが可能である。
またさらに資産活用エキスパート59は、ビジネス・ソリューションまたはビジネス・コンピュータ35及び36において典型的に使用されるもの等の企業リソース・プランニング・ツールにデータを供給しかつ上記ツールからデータを受信することが可能である。これらのアプリケーションは、生産プランニング及び原料リソース・プランニングを制御する生産プランニング・ツール、ビジネス・アプリケーションに使用する部品発注、作業命令または補給品発注を自動的に発生させる作業命令発生ツール54、他を含むことが可能である。当然ながら、部品発注、作業命令及び補給品発注の発生は資産活用エキスパート59からの情報を基礎として自動的に完了されることが可能であり、これにより、資産が修繕を要することを認識するために要する時間、及び保全問題に対して是正措置を講じるために必要な部品を受け取るために要する時間が短縮される。
資産活用エキスパート59はまた保全システム・アプリケーション866に情報を供給し、上記アプリケーションは、即時保全要員に問題点に対する注意を喚起させるだけでなく、問題点を是正するために必要になる部品発注、他等の是正措置を講じる。またさらに、資産活用エキスパート59は利用可能であるがどの単一システムも先行して利用することはできなかったタイプの情報を使用して、新たなモデル868が生成され得る。当然ながら、図19からは、資産活用エキスパート59はデータ・モデル及び分析ツールから情報またはデータを受信するだけでなく、企業リソース・ツール、保全ツール及びプロセス制御ツールからも情報を受け取ることが理解されるであろう。
さらに、1つまたは複数の協調されたユーザ・インタフェース・ルーチン58は、資産活用エキスパート59及びプラント10内の他の任意のアプリケーションと通信し、オペレータ、保全要員、ビジネス要員、他へヘルプ及び視覚化を提供することが可能である。オペレータ及び他のユーザは、協調されたユーザ・インタフェース・ルーチン58を使用して予測制御を実行するまたは実装し、プラント10の設定を変更し、プラント10内のヘルプを見る、または資産活用エキスパート59によって供給される情報に関する他の任意のアクティビティを実行することが可能である。先に論じたように、ユーザ・インタフェース・ルーチン58は、予測コントローラ865からの情報及び、プロセスまたはプロセス内のデバイスのステータスを見ること等の多くの機能の実行を手助けしかつ予測コントローラ865を案内する、または予測制御または最適化された制御を実行するためにオペレータまたは他のユーザにより使用され得る指標に関する情報を受信するオペレータ・ガイダンス・ツールを含むことが可能である。またさらにユーザ・インタフェース・ルーチン58は、例えば資産活用エキスパート59を介してプロセス・プラント10の他の部分における任意のツールからのデータを見る、または上記データを入手するために使用されることが可能である。例えばマネージャーは、戦略的プランを立てるために、プロセス内で何が発生しているかを知りたいと思う可能性があり、またはプロセス・プラント10に関する高レベルの情報を必要とする可能性がある。
従って、データが中央データベースで受信され、例えば共通のフォーマットに変換されると、データは何らかのアクセス可能な方法でデータベースに格納され、資産活用エキスパート59内のアプリケーションまたはユーザがこれを利用できるようになることは理解されるであろう。例えば、プロセス制御、警報発生、デバイス保全、故障診断、予測保全、財政プランニング、最適化、他に関するアプリケーションは、異なるデータ・ソースのうちの1つまたは複数からのデータを使用し、組合せかつ統合して、これらのアプリケーションが大幅に異なる、または事前にアクセス不可能なデータ・ソースからのデータなしに動作し得ていた嘗てよりも良好に動作することが可能である。資産活用エキスパート59の一部として図19に示されているアプリケーションは、図1に記述したアプリケーションの何れでもあることが可能であり、または所望されれば、他の任意タイプのアプリケーションであり得る。当然ながら、図19に示すデータ・ソース及び収集されたデータを使用するアプリケーションは本質的に例示的なものであり、より多い、少ない、または異なるデータ・ソース及びアプリケーションが使用されることも可能である。同様に、データ・ソース自体も、データ収集及び分配システムまたはデータベースによって収集されるデータを受信するように構成されることが可能である。このようにして、自社独自のアプリケーションを有する可能性のある異なる供給メーカーまたはサービス・プロバイダは、これらのサービス・プロバイダによって提供されている製品またはサービスを強化する可能性のある、嘗ては保有していなかった、またはプロセス・プラントから事前に入手し得なかった所定のデータを収集することが可能である。
ある実施形態では、嘗て典型的には自社独自のアプリケーションを使用してプロセス制御ネットワーク以外のデータを収集しかつ発生させていた従来のプロセス制御サービス・プロバイダは、今では収集された、または発生されたデータを資産活用エキスパート59へ供給し、上記エキスパートはこのデータを他のアプリケーションが利用できるようにすることが予期されている。これらの他のアプリケーションは、プロセス制御環境に通信可能に接続されたコンピュータ内で実行される、ホスト・デバイス、ユーザ・インタフェース、コントローラ、他内のアプリケーション等のアプリケーションであり得る。さらにこれらのアプリケーションは、従来のサービス組織により供給される、または使用されるアプリケーションであることが可能である。このようにして、現在ではどのアプリケーションも、プロセス・システムのオーナーによって所有されるアプリケーション、またはサービス・プロバイダにより所有されかつ管理されるアプリケーションの何れによってもプロセス・プラント内で発生される任意のデータを任意の方法で使用するように設計され得る。その結果、嘗ては利用が不可能であったデータを使用できることからアプリケーションが強化され得るかなり多くの例が存在する。例えば、腐食分析サービス・プロバイダは、自社独自のプロセス制御システムまたは自社独自の機器監視アプリケーションによって収集されるデータを使用して、腐食分析の信頼性または予測可能性を強化できる可能性がある。大幅に異なるタイプのサービス・プロバイダからのデータのこのような相互交流は、嘗ては利用不可能であった。
上述のように、資産活用エキスパート59は、特定のプラントまたはデバイス、ユニット、ループ、エリア、他等のプラント内のエンティティのオペレーションをモデリングする1つまたは複数の数学的またはソフトウェア・モデル56を実行する、または上記モデルの実行を監視することができる。これらのモデルはハードウェア・モデルである場合もあれば、プロセス制御モデルである場合もある。ある実施形態では、これらのモデルを生成するために、モデリング・エキスパートがプラントをコンポーネント・ハードウェア及び/またはプロセス制御パーツに分割し、任意の所望される抽出レベルで異なるコンポーネント・パーツのモデルを供給する。例えば、あるプラントのモデルはソフトウェアに実装され、かつプラントの異なるエリアの階層的に相関され相互接続されたモデルのセットで構成される、または上記セットを包含することが可能である。同様に、任意のプラント・エリアのモデルも、プラント内の異なるユニットの個々のモデルで、これらのユニットの入力及び出力が相互に接続されて構成されることが可能である。同様にユニットも、相互に接続されたデバイス・モデルで構成される、等々が可能である。当然ながらエリア・モデルは、ユニット・モデル、ループ・モデル、他と相互に接続されるデバイス・モデルを有することが可能である。このモデル階層例では、デバイス等の下位レベル・エンティティのモデルの入力及び出力が相互に接続されてユニット等の高位レベル・エンティティのモデルを生成することが可能であり、かつその入力及び出力が相互に接続されてエリア・モデル等のさらなる高位レベルのモデルを生成する、等々が可能である。異なるモデルが組み合わされる、または相互に接続される方法は、当然ながらモデリングされるプラントに依存する。プラント全体に関する単一の数学的完全モデルが使用されることも可能ではあるが、幾つかの理由で、エリア、ユニット、ループ、デバイス、他等のプラントの異なる部分またはプラント内の異なるエンティティについて異なる独立したコンポーネント・モデルを供給し、これらの異なるモデルを相互に接続してより大きいモデルを形成することが有益であるとされている。さらに、互いに独立して実行され得ると同時により大きいモデルの一部として他のコンポーネント・モデルと共に実行され得るコンポーネント・モデルを使用することが望ましい。
プラント全体または任意の、または全てのコンポーネント・モデルについては、数学的に極めて正確な、または理論的なモデル(第3次または第4次のモデル)が使用される可能性はあるが、個々のモデルは必ずしも可能な限り数学的に正確である必要はなく、例えば第1次または第2次のモデルまたは他のタイプのモデルであることも可能である。より単純なこれらのモデルは、概してソフトウェアにおいてより高速に実行されることが可能であり、かつモデルの入力及び出力を本明細書に記載した方法でプラント内で行われる入力及び出力の実際の測定と整合させることにより、より正確なものになり得る。言い替えれば、個々のモデルは、プラントからの実際のフィードバックを基礎としてプラントまたはプラント内のエンティティを正確にモデリングするように調整または微調整されることが可能である。
使用されることが可能な階層モデルの例については、図7A及び7Bを参照して論じた。
モデルの使用は、ビジネス・アプリケーション、プロセス制御アプリケーション及び資産保全及び監視アプリケーションに多くの新しいタイプのデータまたは情報をもたらす。特にモデルは、パフォーマンス監視の実行、及びプラント内のデバイス、ユニット、エリア、他の相対パフォーマンスを示すパフォーマンス指標の生成に使用され得る。このパフォーマンス指標は、エンティティの可能パフォーマンスに対するそのエンティティのパフォーマンスの測度である可能性がある。さらに、デバイス及びユニットのモデルについて先に論じたが、ループ、ユニット、他等のプロセス制御エンティティについても同様のモデルを作って実行すれば、これらのタイプのエンティティにパフォーマンス測度及び最適化基準を供給することが可能である。また先に指摘したように、場合によってモデルは、所定のデバイスまたは他のエンティティのヘルスを測定または指示しかつこれらのエンティティを示すヘルス指標を供給するために使用されることが可能である。例えば、所定のモデルに対して使用される回帰分析により決定された所定の入力及び出力センサのエラー測定値は、これらのデバイスのヘルスの示度として使用される、または上記示度に変換されることが可能である。また、モデルを基礎とするモデル・パラメータ及び仮想センサ測定値等のプロセス・コントローラが他では利用できない他の情報もプロセス・コントローラまたはビジネス要員に供給され、多くの方法で使用されることが可能である。
パフォーマンス及びヘルス指標以外にも、資産活用エキスパート59は、活用指標及び可変性指標等の他のタイプの指標を生成する際に指標発生ルーチン51をアシストすることができる。可変性指標は、デバイス、ループ、ユニット、他に出入りする何らかの信号またはこれらに関連づけられる他の何らかのパラメータがこの信号またはパラメータの予想変化量に比較してどの程度変化するかを指示する。この可変性指標の生成に必要なデータは資産活用エキスパート59によって収集され、任意の所望される時間または都合の良い時間に指標発生ルーチン51へ供給されることが可能である。当然ながら、信号またはパラメータの正常な変化量はエンティティに精通しているメーカー、エンジニア、オペレータまたは保全要員によって設定されることが可能であり、またはプラント内のその、または他の類似エンティティに関連づけられる統計的測度(平均、標準偏差、他等)を基礎とすることが可能であり、この正常な、または想定される変化は指標発生ルーチン51によって格納される、または指標発生ルーチン51内で更新されることが可能である。
次に図20を参照して、モデル、オプティマイザ及び1つまたは複数のプロセス・プラントのパフォーマンス監視ツール等の他のデータ分析ツールへのアクセスを遠隔から提供する方法について説明する。図20に示すように、1つまたは複数のプロセス・プラント900、901、902及び903は独立して操業する。プラント900乃至903の各々は、そのプラントに関するデータを周期的に収集し、そのデータをデータ処理ファシリティまたは遠隔監視ファシリティ910へ送る。この機能を達成するために、プラント900乃至903の各々はユーザ・インタフェースまたはサーバ900A乃至903Aを有し、これらのサーバはインターネットまたはワールドワイドウェブ等の任意の所望される通信ネットワークを介して遠隔監視ファシリティ910へ接続される。
図21に示すように、遠隔監視ファシリティ910は、それを介してプロセス900乃至903が遠隔監視ファシリティ910と交信するウェブ・サーバ912を含む。遠隔監視ファシリティ910はまた、幾つかのプロセス監視アプリケーションまたはツールを格納しかつ実行する関連のデータベースを有する1つまたは複数のプロセッサ914を含む。特に各プロセッサ914は、プラント900乃至903のうちの1つまたは複数またはこれらのプラント内のエンティティをモデリングするために生成されている本明細書に記載したコンポーネント・モデル等のモデル916へのアクセスを有しかつ上記モデルを実行することが可能である。モデル916は異なるプラント900乃至903の各々の異なるコンポーネント・モデルを含むことが可能であり、これらのモデル916は、例えばプラント900乃至903内の変化を反映してプラント900乃至903内の要員によりファシリティ910との通信を介して修正または変更されることが可能である。プロセッサ914はまた、プロセス900乃至903からのデータを使用して、図1及び2を参照しながら本明細書で説明したように実装され得るリアルタイム・オプティマイザまたは他の任意の種類のオプティマイザ918を格納しかつ実行することが可能である。またさらに、プロセッサ914は、例えばプロセス制御ツール、プロセス監視ツール、機器またはデバイス監視ツール、指標発生ツール、作業命令発生ツール、本明細書に記載したビジネスまたは他のツールまたはアプリケーションのうちの任意のもの等の図1の任意のコンピュータ・システム内の任意のアプリケーションまたはツールを含む他のデータ監視ツール920へのアクセスを有しかつ上記ツールを実行することが可能である。ある例においては、米国特許出願第09/256,585号または第09/499,445号に記載されているプロセス監視ツールを使用してプロセス・パラメータを監視することが可能である。
オペレーションの間、プロセス900乃至903のうちの何れかは、都合の良い時間にそのプロセスに関連づけられる入力及び出力データを収集し、このようなデータをサーバ900A乃至903A及びワールドワイドウェブ、インターネットまたはサーバ912に接続される他の通信ネットワークのうちの1つを介して遠隔監視ファシリティ910へ供給することが可能である。プラントからデータを受信すると、プロセッサ914のうちの適切な1つがそのデータにアクセスしかつそのプラントに関する適切なプロセス監視及び状態監視ツールを実行して、収集されたデータを基礎としてプラント内の問題点を検出し、そのプラント用の状態、プラントまたはプロセス監視を供給し、またはそのプラントの最適化を実行する。当然ながら、プラントで収集されて遠隔監視ファシリティ910へ送られるデータは、所望されるモデル916、オプティマイザ918または他のデータ分析ツール920を実行するために必要であることが事前に決定されているデータであり、実行されているツールまたはモデルにとって適切な周期的または非周期的度合いで収集され、ファシリティ910へ送られる。従ってオプティマイザの場合、データはモデルまたはパフォーマンス、プロセスまたは資産の各監視ツールとは異なる度合いで収集されかつ送信されることが必要である可能性がある。当然ながら、最適化またはパフォーマンス、状態またはプロセスの各監視エクササイズの一部として、任意の適切なモデルまたは他のツールを実行することが可能であり、これらのモデルまたは他のツールの実行は概して、図1のプラント10におけるこれらと同じツールに関連して先に論じた原理に従う。
何れにしても、モデル、データ分析またはオプティマイザ・ツールが実行されるとプロセッサ914はその結果をサーバ912へ戻し、プラント900乃至903の適切な1つはここで、これらの結果を任意の所望される時間にピックアップすることができる。代替として、またはさらに、これらの結果はサーバ912によりプラント900乃至903のうちの適切な1つへ直接送られることが可能である。分析の結果として生じるデータは、例えばユーザ・インタフェース・ルーチンまたはGUIルーチン58に関連して先に述べたものを含む任意の所望されるパフォーマンス・モデリング・データ、プロットまたはチャートであることが可能である。結果はまた、プラント、プラントに関する指標またはこれらのツール・タイプによって供給され得る他の任意の結果に変更を加えるための、例えばオプティマイザによる提案である可能性もある。
ある実施形態では、先に記述したようなリアルタイム・オプティマイザは、プラント900乃至903が時宜を得た周期でこのオプティマイザの適正な実行を有効化するに足るデータを供給することを想定して、リアルタイム・ベースで実行されることが可能である。所望されれば、サーバ900A乃至903Aは、オプティマイザの適正なオペレーションを有効化する十分なデータを自動的に収集して送ることが可能である。ある実施形態では、プラントは本明細書に記載した資産活用エキスパート59または他の任意のエキスパート・データ収集ツールを包含し、適切なデータが遠隔監視ファシリティ910へ時宜を得た方法で、または周期的に送られることを保証する際に使用することが可能である。
このようにして、遠隔監視ファシリティ910は、資産、パフォーマンス、状態及びプロセス監視用のソフトウェアを実行すると同時に、異なるプラントに関して1つまたは複数のオプティマイザを実行することができる。延てはこれは、プラント900乃至903はこれらの目的のために処理パワーまたはアプリケーションを包含する必要がなく、プラントにとっては経費が安くなる可能性のあることを意味する。当然ながら、プラントは、遠隔監視ファシリティ910の利用に対して使用の度毎に、または予め決められた他の何らかの料金表に基づいて支払いをすることが可能である。所望されれば、遠隔監視ファシリティ910は、ファシリティ910におけるツールの利用及びこれらのツールの結果の履行を基礎としてプラントの収益及び/または損失の一部を引き受けるように請け負うことが可能である。
所望されれば、プラント900乃至903の各々は、XML、HTML、他等の任意の所望される通信フォーマットを使用してサーバ912へ新たな、または更新されたモデルを送ることにより、遠隔監視ファシリティ910に格納されている、これらのプラントが利用することのできるモデル916を更新することが可能である。またさらに遠隔監視ファシリティ910は、サーバ912を介してプラント900乃至903の各々へダウンロードされることが可能な異なるプロセス・プラント、エリア、ユニット、デバイス、ループ、他のための総称テンプレートを含むことが可能であり、これらのテンプレートは、これらのプラントの実際のオペレーションを反映してプラント900乃至903において変更されることが可能である。更新されたモデルは次に遠隔監視ファシリティ910へモデルとして送り返され、プラントの資産、状態またはプロセス監視に、またはオプティマイザに実装されることが可能である。このようにして、プラント900乃至903に対する変更は、遠隔監視ファシリティ910内で適正に、または正確に反映されることが可能である。
資産活用エキスパート59及び他のプロセス・エレメントは、好適にはソフトウェアに実装されるものとして記述されているが、これらはハードウェア、ファームウェア、他に実装される場合もあり、プロセス制御システム10に関連づけられる他の任意のプロセッサによって実装される場合もある。従って本明細書に記載したエレメントは、所望に応じて規格汎用CPUに、またはアプリケーション指定集積回路(ASIC)または他のハードワイヤード・デバイス等の特殊設計ハードウェアまたはファームウェア上に実装されることが可能である。ソフトウェアに実装される場合、ソフトウェア・ルーチンは、磁気ディスク、レーザ・ディスクまたは他の記憶媒体上等の任意のコンピュータ読取り可能メモリに、コンピュータまたはプロセッサのRAMまたはROMに、任意のデータベース、他に格納されることが可能である。同様に、このソフトウェアは、例えばコンピュータ読取り可能ディスクまたは他の可搬式コンピュータ記憶メカニズム上を含む任意の周知配信方法または所望される配信方法を介して、または(可搬式記憶媒体を介するこのようなソフトウェアの供給と同じである、または互換性があると見なされる)電話回線、インターネット、他等の通信チャネル上でユーザまたはプロセス・プラントへ配信されることが可能である。また、エキスパート59は規則ベースのエキスパートである可能性のあるものとして説明されているが、他の周知のデータ・マイニング技術を使用するものを含む他のタイプのエキスパート・エンジンが使用される場合もある。
再度図1を参照すると、プロセス・プラント10は1つまたは複数の制御システム12及び14を含むことが可能である。図22は、例示的なプロセス制御システム1000を示す。プロセス制御ネットワークまたはシステム1000は、(任意タイプのパーソナル・コンピュータまたはワークステーションであることが可能な)1つまたは複数のホスト・ワークステーションまたはコンピュータ1014と、各々が1つまたは複数のフィールド・デバイス1025乃至1039に接続される入力/出力(I/O)デバイス1020、1022のバンクとに接続される1つまたは複数のプロセス・コントローラ1012を含む。コントローラ1012は、例えばFisher Rosemount Systems, Inc.から市販されているDeltaV(商標)コントローラであることが可能であり、例えばイーサネット(登録商標)接続1040またはインターネットを含む他の任意の適切な通信リンクを介してホスト・コンピュータ1014へ通信可能に接続される。同様にコントローラ1012は、例えば規格4-20mAデバイスに関連づけられる任意の所望されるハードウェア及びソフトウェア及び/またはFieldbusまたはHARTプロトコル等の任意のスマート通信プロトコルを使用して、フィールド・デバイス1025乃至1039へ通信可能に接続される。概して周知であるように、コントローラ1012は、コントローラ1012内に格納されている、またはそうでなければコントローラ1012に関連づけられるプロセス制御ルーチンを実装または管理し、フィールド・デバイス1025乃至1039と通信して任意の所望される方法でプロセスを制御する。
フィールド・デバイス1025乃至1039は、センサ、バルブ、発信器、ポジショナ、他等の任意タイプのデバイスであることが可能であり、I/Oデバイス1020及び1022のバンク内のI/Oカードは、HART、Fieldbus、Profibus、他等の任意の所望される通信またはコントローラ・プロトコルに適合する任意タイプのI/Oデバイスであることが可能である。図22に示す実施形態では、フィールド・デバイス1025乃至1027はアナログ回線上でI/Oカード1022Aへ通信する規格4-20mAデバイスであり、フィールド・デバイス1028乃至1031はHART互換I/Oデバイス1020Aへ接続されるHARTデバイスとして示され、フィールド・デバイス1032乃至1039は、Fieldbusプロトコル通信を使用してデジタル・バス1042または1044上でI/Oカード1020Bまたは1022Bへ通信するFieldbusフィールド・デバイスである。
コントローラ1012の各々は、機能、トランスデューサ及びリソースの各ブロックを使用して制御方針を実装するように構成される。周知のように、各ブロックは全体制御ルーチンの一部(例えばサブルーチン)であり、(リンクと呼ばれる通信を介して)他のブロックと合同し、プロセス制御システム1000内のプロセス制御ループを実装するように動作する。機能ブロック及びトランスデューサ・ブロックは、典型的には、センサまたは他のプロセス・パラメータ測定デバイスに関連づけられるもの等の入力機能、PID制御、ファジー論理制御、他を実行する制御ルーチンに関連づけられるもの等の制御機能またはバルブ等の何らかのデバイスのオペレーションを制御してプロセス制御システム1000内の何らかの物理的機能を実行する出力機能を実行する。当然ながら、ハイブリッド及び他のタイプのブロックも存在する。
機能ブロックは、典型的には機能ブロックが規格4-20mAデバイス及び幾つかのタイプのスマート・フィールド・デバイスに使用される、または関連づけられる場合にそうであるようにコントローラ1012に格納されかつ上記コントローラによって実行される場合もあり、フィールド・デバイスに格納されかつ上記デバイスによって実装される場合もある。本明細書では、制御システム1000を機能、トランスデューサ及びリソース・ブロック制御方針を使用して説明しているが、ラダー論理、シーケンス・フローチャート、他等の他の技術を使用しかつ任意の所望される自社独自の、または自社独自でないプログラミング言語を使用する制御方針を実装することも可能である。
プロセス制御システム1000はまた、ワークステーション1014の一方または両方内に、またはプロセス制御システム1000に通式可能に接続される1つまたは複数の他のコンピュータ・システム(図示されていない)もしくは他のタイプのプラットフォーム(例えば、ウェブ・サーバ、無線通信デバイス、他)内に実装されることが可能な1つまたは複数のビジネス・システムを含むことが可能である。これらのビジネス・システムは、プロセス制御システム1000と相互運用してそのオペレーションを効率的に管理する企業資産管理システム、異常状況管理システム、他を含むことが可能である。プロセス制御システム1000を作り上げる様々なデバイス、システム、他は、インターネットを含む1つまたは複数のタイプの通信ネットワークを介して通式可能に接続される可能性のある点を認識することは重要である。好適には、コンピュータ化された保全システム(CMMS)1055が1つのワークステーション1014内で実行される。但し所望されれば、CMMS1055は、プロセス制御システム1000に通式可能に接続される他の任意のワークステーション、サーバまたはコンピュータ・システム内で実行される場合もある。
図22に示すプロセス制御システム1000では、ホストデバイス1014の1つまたは複数がオペレータ・ワークステーションとして機能し、内部に格納された警報処理ソフトウェア1050を有する。一般的に言えば、警報処理ソフトウェア1050は、システム内に存在する警報に関連してプロセスの現行のオペレーション・ステータスを見るシステム・オペレータまたはユーザの理解度または能力に即してプロセス制御システム1000に関する情報を表示する。例えば警報処理ソフトウェア1050は、内部に警報表示を有する警報バナーと、警報バナー内に表示されている1つまたは複数の警報に関係のあるプロセス制御システム1000のセクションに関連づけられるデバイス及び他の機器を含む、プロセス制御システム1000のセクションを示す基本制御ディスプレイとを表示することが可能である。基本制御ディスプレイは、タンク内の流体のレベル、バルブ及び他の流体ラインのフロー特性、機器の設定値、センサの示度、デバイスのステータス、他等のプロセス制御システム1000のカレント・ステータスに関する情報を提示することが可能である。このようなディスプレイの一例を、図24に示す。オペレータは、警報処理ソフトウェア1050を使用してプロセス制御システム1000の異なる部分またはプロセス制御システム1000内の機器を見ることが可能である。当然ながら、警報処理ソフトウェア1050はコントローラ1012及び必要であればフィールド・デバイス1025乃至1039、I/Oデバイス1020及び1022の任意のバンクまたは他の任意のデバイスと通信し、ワークステーション1014のオペレータ・ディスプレイ上にインタフェース・スクリーンを生成するためにプロセス制御システム1000に関連づけられる、または上記システムにおいて生成される関連の値、設定値及び測定値を取得する。
警報処理ソフトウェア1050は、コントローラ1012、I/Oデバイス1020及び1022及び/またはフィールド・デバイス1025乃至1039の幾つか、または全てにおける警報発生ソフトウェアにより生成される警報メッセージを受信するように構成される。図22では、この警報処理ソフトウェア1050を概して、単に例示的にソフトウェア・エレメント1051、1052及び1053として示す。一般的に言えば、警報処理ソフトウェア1050は、例えば(典型的には、プロセスのランタイムの間に使用されるプロセス制御ルーチンを形成する通信可能に相互接続された機能ブロックで構成されるもの等のプロセス制御ソフトウェア・モジュールにより発生される)プロセス警報、コントローラ1012、I/Oデバイス1020及び1022または他のワークステーション1014によりこれらのデバイスの状態または機能状態に関して発生される警報等のハードウェア警報及びフィールド・デバイス1025乃至1039のうちの幾つか、または全てによりこれらのデバイスに関連づけられる問題点または潜在的問題点を指摘するために発生されるデバイス警報を含む、異なるカテゴリの警報メッセージを受信する。これらの、または他のカテゴリの警報も、任意の所望される方法で発生されることが可能である。例えば、プロセス制御機能を実装するために使用される機能ブロックまたはソフトウェア・モジュールにプロセス警報を生じさせることは周知であり、これらのプロセス警報は、典型的には警報メッセージの形式でオペレータ・インタフェースに送られ、表示される。また、幾つかのスマート・デバイス、コントローラ、I/Oデバイス、データベース、サーバ、ワークステーション、他は、任意の所望される自社独自の、または自社独自でないソフトウェアを使用して問題点、エラー、保全警告、他を検出することが可能であり、かつこれらの状態を示す警報または警告をワークステーション1014内のオペレータ・インタフェースへ送ることが可能である。特に、コントローラ、I/Oデバイス及びスマート・フィールド・デバイス等の多くのデバイスには、バルブ・プラグの固着、部品の破壊、保全上の懸念事項、他等のハードウェアに関する問題点を検出しかつこれらの状態を示す信号またはメッセージを発生させることが可能なソフトウェア及び/またはセンサが供給される。
所望されれば、警報処理ソフトウェア1050は、警報を受信しかつ幾つかのファクタを基礎としてこれを濾波することが可能である。特に警報処理ソフトウェア1050は、ソフトウェア1050が実行されるワークステーションまたはコンピュータ・システム、ワークステーションにログインする者の識別及び警報のカテゴリ、タイプ、優先度、ステータス、発生時間、他等のオペレータ構成可能設定を基礎として警報をフィルタリングすることが可能である。例えば警報処理ソフトウェア1050は、警報をフィルタリングして、警報処理ソフトウェア1050を実行しているワークステーションが受信するように構成されているプラントのエリアまたはセクションからの警報を選択的に表示することが可能である。言い替えれば、プラントの所定のエリアまたはセクションに関する警報は、特定のワークステーションでは表示されない可能性がある。代わりに、各ワークステーションはプラントの1つまたは複数の特定エリアに関する警報を表示するように限定される場合もある。同様に警報は、個々のオペレータが所定のカテゴリ、タイプ、優先レベル、他の警報をみることに限定されることが可能であり、またはプラントの1つのセクションまたはサブセクション(例えばエリア)からの警報を見ることに限定されることが可能であるように、オペレータの識別を基礎としてフィルタリングされることも可能である。警報処理ソフトウェア1050はまた、オペレータのセキュリティ・クリアランスを基礎として警報をフィルタリングし、表示することが可能である。概して、本明細書ではこれらのワークステーション及びオペレータ関連のフィルタリング設定をワークステーション及びオペレータ・スコープ制御と称する。
警報処理ソフトウェア1050はまた、例えば警報カテゴリ(例えばプロセス、デバイスまたはハードウェア警報)、警報タイプ(例えば通信、故障、助言、保全、他)、警報優先度、警報が関連しているモジュール、デバイス、ハードウェア、ノードまたはエリア、警報が確認されているか差し止められているか、警報がアクティブであるかどうか、他を含むオペレータ構成可能設定を基礎として、視聴可能警報(即ち、ワークステーション及びオペレータ・スコープ制御内にあるもの)をフィルタリングすることが可能である。
Fieldbusデバイス1032乃至1039のうちの幾つか、または全ては、Fieldbusデバイスに関連して以前は使用されていなかった個々に報告することが可能な3つのデバイス警報または警告カテゴリを含むことが可能である。一般的に言えば、これらの個々に報告することが可能なデバイス警報または警告カテゴリの各々は異なるレベルの苛酷さに対応する可能性があり、よって各カテゴリ内の警報または警告は、システム・ユーザまたはオペレータによる異なるタイプの応答を要求する可能性がある。
特に、Fieldbusデバイス1032乃至1039は、概して正常に作動しなくなっている、または全く作動していない可能性のあるデバイス内の、そのためにデバイスがその正常な検出及び/または制御機能を実行できなくなっている問題点を示す警報パラメータFAILED_ALMを供給することが可能である。例えば、デバイス内のメモリ故障、デバイス内のドライブ故障または即時的注意(即ち保全、修理、他)を必要とする他の任意のデバイス故障は、FAILED_ALMパラメータを使用して報告されることが可能である。Fieldbusデバイス1032乃至1039はまた、概して何らかのタイプのデバイス保全の要求に関連づけられるが、FAILED_ALMパラメータを介して報告するに値するほど苛酷ではないデバイス内で検出される状態を示す、警報パラメータMAINT_ALMを供給することが可能である。MAINT_ALMパラメータを使用して報告されるデバイス状態は、必須ではないが好適には、最終的にデバイスが故障する結果となる可能性のあるデバイス内の何らかのタイプの劣化、摩耗、疲労、他から生じる、但し必ずしも他の任意の必要な機能を検出し、制御し、または実行するデバイスの能力には影響しない状態である。例えば、固着しているバルブ、接続されつつある衝撃線、他は、MAINT_ALMパラメータを介して警報または警告を報告する結果となる可能性のあるデバイス状態である。さらに、Fieldbusデバイス1032乃至1039は、概して助言的性質の警報または警告に値するだけのデバイス内で検出される状態を示す、警報パラメータADVISE_ALMを供給することが可能である。一般的に言えば、ADVISE_ALMパラメータを使用して報告される警報または警告は、そのデバイスを使用して制御及び/または監視されているデバイスまたはプロセスのオペレーションに何ら影響を与えない。例えば、マグメータで検出された接地上の問題点、センサで検出された一時的な過熱または一時的な過圧は、ADVISE_ALMパラメータを使用して報告されることが可能である。
従って、従来のFieldbusデバイスにより使用されるBLOCK_ALM及びBLOCK_ERRパラメータとは対照的に、本明細書に記載した独立して報告され得るFAILED_ALM、MAINT_ALM及びADVISE_ALMの各パラメータは、Fieldbusデバイスが異なるレベルの苛酷さを有する複数の警報または警告を同時に報告できるようにする。言い替えれば、本明細書に記載した独立して報告され得る警報の使用により、単一のFieldbusデバイスは、何ら即時的注意を要求しない接地上の問題点を、ADVISE_ALMを使用して報告することが可能であり、同時にこのFieldbusデバイスは、上記ADVISE_ALMがシステム・オペレータによって確認されているか消去されているかに関わらず、例えば即時的注意を要求するセンサ故障等のより苛酷な状態をFAILED_ALMパラメータを使用して報告することができる。
必須ではないが好適には、本明細書に記載したFAILED_ALM、MAINT_ALM及びADVISE_ALM・パラメータの各々は、例えば共に周知のIEEE規格であるDS-72またはDS71等の任意の所望されるデータ・フォーマットまたはタイプを基礎とする32ビットワードを使用して形成され、よってここでは詳述を省く。各32ビットワード内の各ビットは、この32ビットワードに対応する警報パラメータを使用して報告されるべき一意のデバイス状態を表示している可能性がある。従って、3つの異なる苛酷度レベル(即ちFAILED_ALM、MAINT_ALM及びADVISE_ALM)の各々に32のデバイス状態が存在する合計96の一意の警報または警告状態を、各Fieldbusデバイスによって報告することが可能である。所望されれば、独立して報告され得る警報FAILED_ALM、MAINT_ALM及びADVISE_ALMの各々のうちの1ビットを特に定義されていない「他の」状態用に使用することが可能であり、これによりデバイスは、デバイスの設計の間には予期されない可能性のある、かつ/または特定のユーザにより必要とされる可能性のある様々なデバイス状態の検出に、よりフレキシブルに備えることができるようになる。
概して、苛酷度の低い警報または警告は、FAILED_ALMパラメータを使用してより苛酷度の高い警報を同時に報告するFieldbusデバイスの能力に影響を与えることなく、ADVISE_ALMまたはMAINT_ALMパラメータを使用して報告されることが可能であるが、特定の警報パラメータ内の複数のアクティブ状態(即ち検出された複数のデバイス状態)は、複数の警報イベントがオペレータ・ワークステーション1014へ送信される結果にならない可能性がある。例えば、Fieldbusデバイスのうちの1つが過圧状態と過熱状態とを検出すると、これらの状態に対応するビットはそのデバイスのADVISE_ALMパラメータ内に設定される。但し、最初に検出された状態は警報イベントを発生させてオペレータ・ワークステーション1014へと送信させるが、その次に検出される状態はどれも、先の、または最初に検出された状態に関連づけられる警報イベントがシステム・オペレータまたはユーザによりクリアされて、または確認されて初めて別の警報イベントを発生させ、ワークステーションへと送信させる。その結果、Fieldbusデバイスが過圧状態を先に検出すれば、これに続いて検出される過熱状態は、システム・ユーザまたはオペレータがこの過圧警報または警告をクリアする、またはこれを確認するまで警報イベントを発生させない。
FAILED_ALM、MAINT_ALM及びADVISE_ALMパラメータは、上述のFieldbus警報メッセージ・フォーマット(即ちブロック識別フィールド、サブコード・フィールド、他を含むメッセージ・フォーマット)を使用し、ワークステーション1014の1つを介してシステム・ユーザまたはオペレータへ独立して報告されることが可能である。さらに、これらの警報がFieldbus警報メッセージ・フォーマットを使用してシステム・ワークステーションへ送られる場合、FAILED_ALM、MAINT_ALM及びADVISE_ALMパラメータの各々に関連づけられる32の可能状態の各々は、必須ではないが好適には、一意のサブコードを使用して表示される。各Fieldbusデバイスは、FAILED_ALM、MAINT_ALM及びADVISE_ALMパラメータの各々に関する可能状態の各々に関連づけられるサブコードの定義を含む。また、各Fieldbusデバイスは、サブコードの各々に関連づけられる状態を記述する一意のテキスト・メッセージを定義することが可能である。各サブコードは、好適には一意のデバイス状態に、従って一意のテキスト・メッセージに対応するが、状況によっては、2つ以上のデバイス状態について単一のテキスト・メッセージを使用することが望ましい場合もある。
本明細書に記載した独立して報告され得る警報パラメータは、起こり得るデバイス状態(即ち96の起こり得る状態)のうちの1つまたは複数に応答する警報または警告の報告を有効化または無効化するために各デバイスによりフィルタリングされることが可能である。本明細書に記載した独立して報告され得るFAILED_ALM、MAINT_ALM及びADVISE_ALMパラメータを使用して警報を報告する能力を有するFieldbusデバイス1032乃至1039の各々は、さらに、独立して報告され得る警報パラメータの各々についてアクティブな警報パラメータとマスク・パラメータとを含むことが可能である。特に、Fieldbusデバイス1032乃至1039の各々は、報告され得るFAILED_ALMパラメータに対応するFAILED_ACTIVE及びFAILED_MASKパラメータと、報告され得るMAINT_ALMパラメータに対応するMAINT_ACTIVE及びMAINT_MASKパラメータと、報告され得るADVISE_ALMパラメータに対応するADVISE_ACTIVE及びADVISE_MASKとを含むことが可能である。マスク及びアクティブ・パラメータは、必須ではないが好適には、符号なし32ビットのデータ・フォーマットまたはタイプを使用して実装される。当然ながら、他の任意の適切なデータ・タイプまたはフォーマットが代わりに使用される場合もある。
マスク及びアクティブ・パラメータにおける32ビットの各々は、その対応する報告され得る警報パラメータ(即ちFAILED_ALM、MAINT_ALM及びADVISE_ALM)内の状態に一意に対応する。概して、各デバイスのマスク・パラメータのビットは、例えば構成の間に、FAILED_ALM、MAINT_ALM及びADVISE_ALMパラメータに関連づけられる状態の検出に応答する警報またはそのデバイスに関する警報を報告するデバイスの能力を有効化または無効化するように設定またはリセットされることが可能である。このようにして、システム・ユーザまたはオペレータは、各デバイスがFieldbus警報または警告メッセージを発生させる対象であるこれらの状態を選択的に有効化または無効化することが可能である。当然ながら、システム・ユーザまたはオペレータは、望み通り多くの、または少ないデバイス状態を有効化または無効化することが可能である。
運転中にFieldbusデバイスがある状態を検出すると、検出されたその状態に対応するビットが適切なアクティブ・パラメータ内に設定されることが可能である。例えば、Fieldbusデバイスが故障したセンサを検出すると、そのデバイス内のトランスデューサ・ブロックに関するFAILED_ACTIVEパラメータ内のその状態に対応するビットが設定またはリセットされてセンサの故障を示すことが可能である。検出されている(かつ未だ確認、キャンセルまたはクリアされていない)、またはいつの時点であっても検出される任意の追加のデバイス状態はまた、これらの追加状態の存在を指摘するようにアクティブ・パラメータ内のビットを設定またはリセットさせる結果となる可能性がある。但し、後に詳述するように、未だ確認されていない報告され得る状態(即ち、それに関してFieldbus警報メッセージがシステム・オペレータへ既に送られているもの)に続いて検出される状態は、その報告され得る状態がシステム・ユーザまたはオペレータにより確認、キャンセルまたはそうでなければクリアされるまで報告されない可能性がある。Fieldbusデバイスは次に、トランスデューサ・ブロックに関するFAILED_MASKパラメータを使用して、そのブロックに関連づけられる、ユーザまたはシステム・オペレータがその警報または警告の受信を希望しないデバイス状態をフィルタリングすることが可能である。システム・ユーザまたはオペレータは、システム構成の時点で、所望されるフィルタリングを達成するためにはFAILED_MASKパラメータ内のどのビットが設定またはリセットされるかを定義することが可能である。例示として、FAILED_MASKパラメータとFAILED_ACTIVEパラメータとを使用して論理ANDオペレーションを実行すれば、現行でアクティブであり(即ち検出されている)かつマスク・パラメータによってマスクされていないデバイス状態の存在を指摘するために設定またはリセットされているビットを有するFAILED_ACTIVEパラメータを発生させることが可能である。
概して、独立して報告され得る警告パラメータFAILED_ALM、MAINT_ALM及びADVISE_ALMの各々は、システム・ユーザまたはオペレータへ(アクティブでありかつマスクされていない検出された任意の状態に関する)Fieldbus警報または警告メッセージをこれらの状態が検出される順番に報告する、またはFieldbusデバイスにこれを送信させることが可能である。言い替えれば、特定のデバイスに関する独立して報告され得る警報パラメータのうちの特別の1つにおける検出された状態は、システム・ユーザまたはオペレータへこれらの状態が検出された順(即ち先入れ先出し式)に報告されることが可能である。当然ながら所望されれば、検出された状態は、システム・ユーザまたはオペレータへ他の何らかの優先順位または順序付けのメカニズムを使用して報告されることも可能である。例えば検出された、マスクされていない状態は、検出された状態のタイプ、他を基礎として逆年代順(即ち後入れ先出し式)に報告されることが可能である。さらに、Fieldbusデバイスは、特定の警報パラメータに関連づけられる全ての警報メッセージがクリアされると、クリア警報メッセージを供給することが可能である。さらに、警報パラメータに関連づけられる状態がアクティブである間に、特定の警報に関するマスク・パラメータが変更されれば、デバイスは警報をクリアしかつマスク・パラメータに加えられた任意の変更を基礎として警報を再評価することが可能である。
Fieldbusデバイス1032乃至1039の各々はまた、その個々のFAILED_ALM、MAINT_ALM及びADVISE_ALMパラメータの各々について、優先パラメータFAILED_PRI、MAINT_PRI及びADVISE_PRIを含むことが可能である。これらの優先パラメータは、256の起こり得る優先レベルを供給する符号なしの8ビット値を使用して実装されることが可能であり、かつ例えばデフォルト・レベルまたは値2を割り当てられることが可能である。警報の優先レベルをゼロに設定すると、その警報を報告することが無効化され、優先レベルを1乃至255までの任意の値に設定すると、警報処理ソフトウェア1050がシステムワイド・ベースで警報または警告を管理する方法のユーザまたはシステム・オペレータによる制御が有効化される。特に、どのデバイス警報または警告が他のデバイスの警報または警告に先行するかを決定するためには、多くの起こり得る優先レベルを使用することが可能である。このようにして、システム・ユーザまたはオペレータは、システムが潜在的に多数であるアクティブな警報を如何に管理しかつ処理するかを予め定義することができる。
Fieldbusデバイス1032乃至1039の各々はまた、ワークステーション1014内に格納されることが可能であるデバイス記述情報内のテキスト情報にマップされることが可能なRECOMMENDED_ACTIONパラメータを含むことが可能である。RECOMMENDED_ACTIONパラメータによって参照されるテキスト情報は、警報を発したデバイスの補正、修繕、他をアシストするためにシステム・オペレータまたはユーザへ表示されることが可能である。報告される警報が複数のアクティブな状態を有するケースでは、システム・ユーザまたはオペレータへ表示される推奨されるアクションは最も危機的または最優先状態である可能性がある。
先に述べたように、Fieldbusデバイス1032乃至1039により発生される様々なタイプの警報または警告は、デバイス・レベルで複数の独立して報告され得る警報パラメータ(例えばFAILED_ALM、MAINT_ALM及びADVISE_ALM)にマップされることが可能である。このようにして、複数のFieldbusデバイスからの警報または警告は監視され、処理されて、ワークステーション1014を介してシステム・オペレータまたはユーザへ整合的かつ論理的方法で表示され得る。さらに、所与のFieldbusデバイス内では、本明細書に記載した独立して報告され得る警報パラメータは、苛酷度の低いタイプの警告がシステム・オペレータまたはユーザへの苛酷度の高いタイプの警報または警告の通信または表示をマスキングすることを防止する。
HARTデバイス1028乃至1031の各々は、8つの規格ステータス状態と、所望されれば1つまたは複数のデバイス固有のステータス状態とを供給する。しかしながら、HARTデバイスに関連づけられるこれらの規格及びデバイス固有のステータス状態は、典型的にはFieldbusデバイスにより報告されるステータス状態に整合しない。特にHARTデバイス1028乃至1031は、ステータス状態を本明細書に記載した独立して報告され得る警報パラメータFAILED_ALM、MAINT_ALM及びADVISE_ALMと整合する方法で報告しない。
HARTデバイス1028乃至1031により報告されるステータス状態に関連づけられる警報または警告、及び本明細書に記載した独立して報告され得る警報パラメータを介してFieldbusデバイス1032乃至1039により報告される警報または警告の統合された監視、処理及び表示を促進するため、警報処理ソフトウェア1050はHART対応ステータス情報を、独立して報告され得る警報パラメータFAILED_ALM、MAINT_ALM及びADVISE_ALMに整合する警報または警告カテゴリにマップする、または分類する。単に例示として、8つの規格HARTデバイス・ステータス状態は、下記の表Iが示すようにマップされることが可能である。表Iに示すように、警報処理ソフトウェア1050は、8つの規格HARTデバイス・ステータス状態をFAILED、MAINTENANCE及びADVISORYの各カテゴリへマップする、または分類ことが可能であり、これにより、これらの規格HARTステータス状態がFieldbusデバイスの警報または警告情報と共にシステム・オペレータまたはユーザへ、先行システムを使用した場合に可能であったものより整合的かつ論理的方法で報告される、または表示されることが有効化される。
周知のように、Fieldbusデバイスとは対照的に、HARTデバイスはデバイスのカレント・ステータス状態を取得するためにポーリングされなければならない。従って、警報処理ソフトウェア1050、コントローラ1012及び/またはI/Oデバイス1020Aは、ステータス情報を求めてHARTデバイス1028乃至1031を周期的にポーリングするように構成されることが可能である。HARTデバイスにより送られるあらゆる応答メッセージは、8つの規格ステータス状態のカレント状態を含むことから、警報処理ソフトウェア1050は、典型的にはコントローラ1012によりI/Oデバイス1020Aを介してHARTデバイス1028乃至1031へ送られるコマンドに対する応答からステータス情報を抽出することにより、このステータス情報を効率的に取得することが可能である。言い替えれば、警報処理ソフトウェア1050は、そうでなければ要求されたプロセス制御または監視アクティビティを実行するためにコントローラ1012によりHARTデバイス1028乃至1031へ周期的に送られるはずのコマンドに対する応答からステータス情報を取得することによって、追加の通信オーバーヘッドをほとんど、または全く導入する可能性がない。例えば、コントローラ1012がDeltaVタイプのコントローラであるケースでは、HARTコマンド#0及び#3がHARTデバイス1028乃至1031へ周期的に送られる。従って、警報処理ソフトウェア1050は、これらのコマンドに応答して送られるメッセージからデバイス1028乃至1031に関連づけられる規格HARTのステータス状態情報を抽出することが可能である。当然ながら、所望されれば、HARTデバイス1028乃至1031に規格HARTステータス情報を含む応答メッセージを送信させるために、コントローラ1012及び警報処理ソフトウェア1050により他の任意のコマンドが使用される可能性もある。
周知のように、HARTデバイス1028乃至1031へHARTコマンド#48を送れば、非規格HARTステータス(即ちデバイス固有ステータス)状態を取得することが可能である。同じく周知のように、HART通信プロトコルは、「デバイス機能不全」または「より多くの有効ステータス」状態の何れかが真である(即ちビットが論理1に設定されている)とき、デバイス固有のステータス情報が入手可能になり得ることを規定している。従って、警報処理ソフトウェア1050がHARTデバイス1028乃至1031のうちの1つについて「デバイス機能不全」または「より多くの有効ステータス」ステータス状態の何れかに真状態を検出すると、警報処理ソフトウェア1050はそのデバイスへHARTコマンド#48を送る。ポーリングされたデバイスは、コマンド#48に応答してデバイス固有の状態またはステータスの性状に関するより詳細な情報を提供する。警報処理ソフトウェア1050は次に、コマンド#48に応答して供給される任意のデバイス固有のステータス状態を次のようにして分類することが可能である。即ち、(1)「デバイス機能不全」ビットが設定されていれば、警報処理ソフトウェア1050はそのデバイス固有のステータス状態を「FAILED」警報または警告カテゴリへマップし、(2)「より多くの有効ステータス」ビットが設定されていれば、警報処理ソフトウェア1050はそのデバイス固有のステータス状態を「ADVISORY」警報または警告カテゴリへマップする。
次に図23を参照すると、警報ディスプレイ及びインタフェース・システムを実装するワークステーション1014の1つの構成がより詳細に示されている。図23に示すように、ワークステーション1014は、イーサネット(登録商標)接続1040(または例えばインターネット等の他の何らかの通信ネットワーク)を介してコントローラ1012と通信しコントローラ1012、バンク1020及び1022内のI/Oデバイス、フィールド・デバイス1025乃至1039及び/または他のワークステーションにより送られる信号を受信する通信レイヤまたはスタック1062等の通信ソフトウェアを格納しかつ実行する。通信レイヤ1062はまた、コントローラ、I/Oデバイス、フィールド・デバイス1025乃至1039及び他のワークステーションに送られるべき警報確認メッセージまたは信号、他等のメッセージを適切にフォーマットする。通信レイヤ1062の実装に使用される通信ソフトウェアは、例えばイーサネット(登録商標)通信によって現在使用されている任意の周知または所望される通信ソフトウェアであり得る。当然ながら、通信レイヤ1062は、ワークステーション1014内で実行される構成アプリケーション、診断または他のプロセス・アプリケーション、データベース管理アプリケーション、他等の他の機能を実行する他のソフトウェアに結合される。
警報ディスプレイ及びインタフェース・システムは、通信レイヤ1062から警報または他のイベント情報をメッセージの形式で受信し、警報または他のイベント情報を含むこれらのメッセージを復号しかつこの警報及び他のイベント情報をデータベース1066に格納することが可能な警報処理ユニット1064を含む。通信レイヤ1062及びデータベース1066とインタフェースで連結する警報処理ユニット1064のフロント・エンドは、警報受信機であることが可能である。警報処理ソフトウェア1050はまた、警報処理ユニット1064がワークステーション1014に関連づけられるユーザ・インタフェース1069(CRT、LCD、LED、プラズマ・ディスプレイ、プリンタ、他等)上へどの警報が表示されるべきかを決定する際に使用する警報フィルタ1068を含む。フィルタ1068はその設定値をデータベース1066に格納させることが可能であり、かつこれらのフィルタ設定値は、ユーザの好みを基礎としてユーザにより事前に構成される、かつ/または変更されることが可能である。フィルタ1068及びその設定値は、本明細書に記載したようなFieldbusデバイスとの関連で使用されることが可能なデバイス・レベル・マスク・パラメータFAILED_MASK、MAINT_MASK及びADVISE_MASKとは区別的なものであることは認識されるべきである。即ちシステム・ユーザまたはオペレータは、特定のデバイス内の特定の状態により発生される特定の警報をデバイス・マスク・パラメータを使用してフィルタリングすることが可能である。本明細書に記載したように代替として、または追加的に、システム・ユーザまたはオペレータは、フィルタ1068を使用してプロセス制御システム内の特定のプラント、エリア、ユニット、ループ、他に関連づけられる警報、警報のカテゴリ・タイプをフィルタリングすることが可能である。例えば、警報処理ソフトウェア1050がHARTデバイス1028乃至1031のうちの1つまたは複数により送られる警報または警告情報を処理しているケースでは、警報または警告情報を任意の所望される方法で選択的に表示するために警報フィルタ1068が使用されることが可能である。当然ながら、HARTデバイス1028乃至1031は、例えばFieldbusデバイス1032乃至1039に関連して先に述べたデバイス・レベル・マスク・パラメータ等の内部警報または警告フィルタリング・メカニズムを保有しない。
概して、警報フィルタ1068のフィルタ設定値は警報のカテゴリ及び優先度を制御することが可能であり、かつ所望されれば、幾つかの異なる基準を使用して表示されるべき警報の順序を確定することが可能である。ワークステーション及びオペレータのスコープ制御は、オペレータの識別及びオペレータがログオンするワークステーションを基礎として特定のオペレータが何を見ることができるか(例えば、特定のワークステーションにどの警報を表示することができるか)を左右する。この場合、各ワークステーションにはオペレーション・ライセンスが割り当てられることが可能であり、オペレーション・ライセンスがなければ、警報情報及び全ての警報リスト/簡易ディスプレイは空になる可能性がある。言い替えれば、如何なるカテゴリ(即ちプロセス、ハードウェアまたはデバイス)のアクティブまたは抑制された警告も警報処理ユニット1064によっては示されない。またさらに、そのワークステーションの警報ディスプレイに現出する資格のあるものは、オペレータのカレント・スコープ(オペレータは通常、プラント・エリアにおいて少なくとも1つの安全キーを与えられる)内のプラント・エリアからの警報のみである。また、この警報ディスプレイに現出する資格のあるものは、プラント・エリアまたはユニット・フィルタリング・ディスプレイ(後述する)を使用してターンオフされていないプラント・エリア及びユニットからの警報のみでもある。このようにして、警報フィルタ1068は、ワークステーション及びオペレータ・スコープの外の警報及びオペレータによりターンオフされているエリアまたはユニットからの警報の表示を防止する。
ワークステーション及びオペレータ・スコープ制御との適合性に関して警報を試験した後、フィルタ1068は、例えば警報のカテゴリ、警報の優先度、警報のタイプ、警報の確認ステータス、警報の抑制ステータス、警報の時刻、警報のアクティブ・ステータス、他を含むことが可能なオペレータ設定値を基礎として警報をフィルタリングし、その表示順序を決定する。警報メッセージ(例えばFieldbus警報メッセージ)を使用して警報処理ソフトウェア1050へ送られる受信された警報は、これらの値の各々についてパラメータを含む可能性があり、フィルタ1068は、警報の適切なパラメータをフィルタ設定値に比較して表示する警報をフィルタリングすることが可能である。例えば、オペレータは、スクリーンに警報のどのカテゴリ及び優先レベルが表示されるべきかを指示することができる。所望されれば、オペレータは、優先レベルをその警報に関してメーカーが設定した事前設定優先レベルからオフセットすることにより、警報の予め決められた優先レベルを調整することができる。DeltaV(商標)システムでは、各警報について典型的には約3乃至15の間の優先レベルが選択されるが、オペレータは、フィルタ1068に掛けられるとより高位の優先度をより低位の優先度にし、またはより低位の優先度をより高位の優先度にする任意の数字により、この優先レベルをオフセットすることができる。オペレータはフィルタ1068を通過する警報の表示順序を設定することが可能であるが、この順序はまた、異なるタイプの警報の整合的な表示をもたらすように予め設定された設定値によって決定されることも可能である。
何れにしても、オペレータは、全てプロセス警報、デバイス警報、ハードウェア警報等の1つの警報カテゴリまたはタイプもしくは2つ以上の警報カテゴリの任意の組合せであることが可能な、ユーザに最も関心のある警報のカテゴリまたはタイプを基礎として警報の表示方法をカスタマイズすることができる。さらにユーザは、異なる苛酷度の警報または警告が表示され得る、または表示され得ないように警報ディスプレイを構成することが可能である。例えばユーザは、FAILED_ALM及びMAINT_ALMパラメータ内に含まれる警報または警告のみを見ることを希望し、ADVISE_ALMパラメータ内に含まれる警報または警告を見ることを希望しない可能性がある。より一般的には、システム・オペレータまたはユーザは、デバイス故障、保全を要するデバイス及び/またはデバイス関連の当を得た措置に関連づけられる警報または警告を見るように警報ディスプレイを構成することが可能である。ユーザはまた、警報が如何に提示されかつ警報に伴って情報が如何に供給されるかに対する制御も保有することが可能である。このようにして、警報処理ソフトウェア1050は、通常はプラント内の異なるロケーションで異なる要員により対応される警報を同一のスクリーンで見て対応することにより、単一の要員がオペレータ、技術者または保全要員及びエンジニアのオペレーションを実行できるようにする。または、同一のシステムにおいて異なる時間に、保全要員はこの同じシステムを使用して保全警報のみを見ることができて、エンジニアはデバイスに影響する他のタイプの警報を見ることができる。このようにして、警報処理ソフトウェア1050は、プロセス制御システム1000に関連づけられる異なる警報の態様を見るために、異なるタイプの要員により異なるワークステーションにおいて同時に使用されることが可能である。さらに、警報処理ソフトウェア1050を使用する場合、個々の者がそれまでに見ていた警報機能を切り替えて、同じソフトウェアを有する可能性のある別の個人へ認識を行うことは比較的容易である。代替として、または追加的に、個人は、別の要員が一般に見る警報を受容するようにそのフィルタを設定することが可能である。このようにして、幾つかのフィルタ設定値をリセットすれば、一人の要員は警報ビュー機能を異なるワークステーションにいる他の要員達に切り替えて昼食に出ることができる。昼食から戻れば、この要員はこれらの機能の制御を取り戻すことが可能である。また、警報情報量が多すぎて一人の要員では処理しきれなくなった場合、この要員は、プロセス警報、デバイス警報またはハードウェア警報等の所定の警報カテゴリに関するロードを、これらの警報が他の要員または他のターミナルで処理され得るように引き渡す、または落とすことが可能である。
警報処理ユニット1064がフィルタ1068を使用して、ディスプレイ1069を介してユーザへどの警報(即ちマスクされていない状態)が表示されるべきか、及び警報が表示されるべき順序を決定すると、警報処理ユニット1064はこの情報をユーザ・ディスプレイ・インタフェース1070へ供給し、上記インタフェースは任意の規格または所望されるオペレーティング・システムを使用して警報情報を警報ディスプレイ1069上へ任意の所望される方法で表示する。当然ながら、ユーザ・ディスプレイ・インタフェース1070は、データベース1066から、またはプロセス制御システム1000から通信レイヤ1062を介して受信される他の通信信号から、プロセス制御システム1000の配置または構成、そのシステム内のパラメータ値または信号値、他に関する情報等のそれが必要とする他の情報を取得する。またユーザ・ディスプレイ・インタフェース1070は、ユーザから例えば特定の警報、警報またはフィルタ設定値の変更、新たな警報ディスプレイ、他に関するさらなる情報を要求するコマンドを受信してこの情報を警報処理ユニット1064へ供給し、上記ユニットは要求された措置を講じかつ警報情報、他を求めてデータベース1066を検索し、ディスプレイ1069を介してユーザへ新たな警報ビューを供給する。
一般的に言えば、ディスプレイ1069上で発生されかつ表示され得る警報には、例えばプロセス警報、デバイス警報及びハードウェア警報を含む異なるカテゴリが存在する。周知でありかつ典型的にはコントローラまたはフィールド・デバイス上で実行されるプロセス制御ルーチン内のファンクション・ブロックまたはモジュールによって発生されるプロセス警報は、嘗てはオペレータ・インタフェースに送られ、上記インタフェース上記に表示されていた。プロセス警報は概して、プロセス制御ソフトウェアの機能オペレーションに伴う問題点、即ち限界外の測定値、プロセス・パラメータと設定ポイントとの異常な差異、他等のプロセス制御ルーチン自体に伴う問題点を指摘する。プロセス警報は典型的にはユーザによりプロセス制御モジュールの成分として構成され、オペレータ・インタフェース上に供給される構成情報にはモジュール名に関連づけられて現出する可能性がある。プロセス警報の幾つかのタイプには、不良入力/出力、限界外の測定値、しきい値超過、他が含まれる。プロセス警報は技術上周知であり、ここでは詳述を省く。
デバイス故障、デバイス保全及び/またはデバイス関連の当を得た措置に関連づけられる警報等のデバイス警報はプロセス内のフィールド・デバイスのオペレーションに関連づけられる警報であり、フィールド・デバイスのオペレーションに伴う問題点またはエラーを指摘するために、プロセス制御システム1000内に接続されるフィールド・デバイスまたは他のデバイス内のソフトウェア(例えば図22のソフトウェア1053)によって検出されることが可能である。デバイス警報は、本明細書に記載したシステムのオペレータ・インタフェースに特定のデバイスに関連づけられるものとして現出する可能性がある。デバイス警報は、例えば、バルブ内の圧力が高すぎて、または低すぎてバルブが適正に作動しないこと、バルブ内のモータ電流が高すぎる、または低すぎること、デバイスの電圧レベルが同期されていないこと、バルブ内のバルブ・プラグが詰まっていること、デバイスの通信状態が不適正であること、例えば最後の保全から所定の期間が経過している、またはデバイスのバルブ部材が所定量の行程を経験していることからデバイスが予定された保全を必要としていること、他を指示することが可能である。デバイス警報は、デバイス自体に、または警報を発生させる対象であるデバイスに接続される他のデバイス内に位置づけられる自社独自の、または自社独自でないソフトウェアを使用して、デバイスに伴う特定の問題点を認識しかつ検出し、それに関して警報を発生させることを含む任意の所望される方法で発生され得る。
先に論じたように、デバイス警報には、例えばデバイス内に故障した、または故障しつつある状態が存在することを示す故障警報、何らかのタイプの保全が実行されるべきであることを示す保全警報、デバイスが正常に通信していない、または全く通信していないことを示す通信警報、助言的警報、他を含む多くの異なるタイプが存在し得る。故障(例えば「故障している」)警報は、デバイスが重要な機能を実行することができず、よって即時的保全が必要であることを示す1つまたは複数の状態を検出していることを示す。故障警報状態が真であるときはいつも、デバイスの完全性は不良であるものとされ、これがコントローラに伝わり、デバイスが接続されるコントローラ・ノードの完全性も不良になる。これに対して保全警報は、デバイスは重要な機能を実行することができるが、対応されないままに置かれると故障に繋がる可能性のある1つまたは複数の状態が検出されているため、デバイスは早期に保全上の配慮を受けるべきであることを示す。通信(例えば「通信していない」)警報は、デバイスが通信することを停止するとアクティブになる。通信していない警報状態が真であるときはいつも、デバイスの完全性は不良であるものとされ、デバイスが接続されるコントローラ・ノードの完全性も不良になる。助言的警報は、デバイスが他の警報カテゴリに入らない状態を検出していることを示す。一般に、助言的警報は個々のデバイスによって供給される警報であり、フロー信号の可変性を追跡するフロー・メータ等のデバイス・タイプに一意に関連づけられる。この場合デバイスは、デバイスに関連づけられる何らかの信号の可変性が大きすぎる、または少なすぎること、これは、普通でない何かが発生していて調査を要するという意味であることを認識することができる。デバイスに依存して、助言的警報は保全警報より緊急度の高いまたは低い注意を要求する可能性があり、よってユーザは助言的警報の優先順位を保全警報のそれより低く設定することが可能である。当然ながら、故障、保全及び助言的という警報はあらゆるデバイスによってサポートされない可能性があり、この故障、保全及び助言的警報の代わりに、最終的には通信なし、異常、の合計2つの警報になる汎用デバイス用「異常」警報等の単一の包括的警報を使用することも可能である。当然ながら、上述のものに代えて、またはこれらに追加して他のタイプのデバイス警報を生成する、または使用することも可能である。
ある実施形態では、ユーザに統合された警報情報がディスプレイ上の例えばディスプレイ画面の端に警報バナーの形式で供給されることが可能である。次に図24を参照すると、警報バナー1073がスクリーン71の底部に位置づけられている。警報バナー1073は、プロセス制御システム1000により発生されかつフィルタ1068をディスプレイ1069へと通過した様々な警報の示度を表示する最初の行を含む。警報バナー1073内に指示される警報のうちの少なくとも1つは、スクリーン71の主要部分に描かれるプロセス制御システム1000の一部に関連づけられることが可能である。警報バナー1073に表示される特定の警報及びこれらの警報の順序は、マスク及び優先パラメータの構成及びフィルタ1068のフィルタ設定値に従って決定される。一般的に言えば、確認、抑制またはマスクされていない最優先警報が最初に表示され、続いては次に高い優先順位の警報、等々と表示される。図24の例示的なスクリーンでは、最優先警報1074はプロセス警報であり、PID101制御ルーチンに関連づけられるものとして示されている。警報1074は、その優先性の高さを示すために赤で表示される。警報バナー1073の2行目では、警報情報フィールド1076が、その時点で選択されている警報バナー1073内の警報に関連づけられる警報情報を表示する。警報1074が選択されている図24の例では、警報情報フィールド1076は、警報1074が金曜日の12時52分19秒に発生され、「タンク16レベル制御」に関連し、PID101/HI_Hf_ALMという呼称または名称を有し、超高優先順位を有し、極めて重要な警報であることを示す。警報1074が点滅していれば、警報1074は確認されておらず、警報バナー1073内の定常(非点滅)警報表示は、警報1074が何れかのオペレータまたはユーザによって確認されていることを示す。当然ながら、他のタイプの警報情報が警報情報フィールド1076内に表示される可能性もある。
また、警報バナー1073における警報表示1078等の他の警報表示は、その警報に関連づけられる重大さまたは優先度の他のレベルを示すために黄、紫または他の任意の色であることが可能である。警報1078、1080、1081または1082等の別の警報が選択されると、警報情報フィールド1076にはその警報に関する警報情報が表示されることが可能である。警報バナー1073内の警報を見たユーザは、その警報を確認し、適切な措置を講じて警報を発生させた状態を是正するように保全または技術要員に警告を発することができる、または、所定の設定ポイントをリセットする等の他の処置を取って警報状態を緩和させることも可能である。
先に指摘したように、警報バナー1073において警報1074等の警報の1つを選択することにより、スクリーン1071にはその警報の基本制御ディスプレイが提示される。特に、図24に示すように、スクリーン1071の主体は、プロセス制御システム1000内の特定の警報(選択された警報)に関連づけられる関連ハードウェアの基本制御ディスプレイまたは描写を含む。図24の例では、本ハードウェアは様々なセンサが付着されている3つのタンクを含み、これらは全て、様々なバルブ及び流体フロー・ラインによって相互に接続されている。このハードウェア描写は、プロセス制御システム1000の一部の内部機器を表示するものであり、タンク、センサ、他に関連づけられる値またはパラメータ等の幾つかの機器のオペレーションに関する情報を提供する。当然ながら、この情報の幾つかは、データベース1066内の構成情報及びコントローラ1012及びイーサネット(登録商標)接続1040を介するプロセス制御システム内のセンサからの信号によって供給されることが可能である。この場合、このような情報は、通信レイヤ1062を介して送信され、任意の周知または所望されるソフトウェアを介してユーザ・ディスプレイ・インタフェース1070へ供給される。
図25乃至27は、警報表示及びインタフェース・ソフトウェア1050を介してシステム・ユーザまたはオペレータにより使用されるために供給されることが可能なグラフィック・ディスプレイを例示的に描写したものである。図25は、図24に示す警報バナー1073から警報の1つを選択するシステム・ユーザまたはオペレータに応答して警報処理ソフトウェア1050により表示されることが可能な例示的なポップアップ・ウィンドウ1100を描いている。特に、ユーザがフロー・バルブFV101に関連づけられる警報80を(例えばダブルクリックにより)選択すると、ポップアップ・ウィンドウ1100が表示されることが可能である。図25に示すように、ポップアップ・ウィンドウ1100は警報または警告バー1102を含み、上記バーのうちの1つまたは複数は、この場合はフロー・バルブFV101であるFieldbusデバイス1032乃至1039のうちの1つまたは複数に関する独立して報告され得る警報パラメータ(即ちFAILED_ALM、MAINT_ALM及びADVISE_ALM)のうちの1つまたは複数内のアクティブ状態を指示するために強調されることが可能である。さらに、警告バーの1つまたは複数は、HARTデバイス1028乃至1031のうちの1つまたは複数からのデバイス故障、保全または助言的警報または警告に関連づけられるアクティブ状態を示すことが可能である。当然ながら、「故障」警報バーはFAILED_ALMパラメータ内のアクティブ状態の結果として強調されることが可能であり、「要早期保全」バーはMAINT_ALMパラメータ内のアクティブ状態の結果として強調されることが可能であり、「助言的」バーはADVISE_ALM内のアクティブ状態の結果として強調されることが可能である。さらに図25に示すように、警報または警告バー1102は、フィールド・デバイス1025乃至1039の1つまたは複数に関連づけられる通信不良の存在を示す「通信不良」バーを含むことが可能である。
システム・ユーザまたはオペレータは、確認ボタン1104を選択してウィンドウ1100内の強調されている警報または警告を確認することが可能であり、または代替として、キャンセル・ボックス1106の1つを選択して1つまたは複数のアクティブな警報または警告をキャンセルすることも可能である。さらに、所望されれば、ユーザまたはシステム・オペレータは「詳細」ボタン1108を選択して、後に詳述するようにウィンドウ1100内のその時点でアクティブである警報に関連する追加情報を供給する他のポップアップ・ウィンドウを呼び出すことも可能である。
図25はまた、フロー・バルブFV101に関連づけられるさらに詳細なステータス情報を含む別のポップアップ・ウィンドウ1110を描いている。ステータス・ウィンドウ1110は、アイコン1112、詳細ボタン1108、警報または警告バー1106のうちの強調されている1つを選択することにより、また他の任意の所望される方法でウィンドウ1100から呼び出されることが可能である。何れにしても、ステータス・ウィンドウ1110は、各々が独立して報告され得る警報または警告の1つに対応するバー1114、1116及び1118を含むことが可能である。本例では、この時点でフロー・バルブFV101がバルブFV101のFAILED_ALMパラメータ内にアクティブ状態を有することから、「故障」バーが強調されている。ステータス・ウィンドウ1110はまた、フロー・バルブFV101内の故障報告に関連づけられる可能状態リスト1120を含む。本例では5つの状態しか示されていないが、所望されれば5つより多い、または少ない状態が提示され得る点を認識することは重要である。ウィンドウ1110内に示す可能状態1120の各々は、FAILED_ALMにより報告されることが可能なマスクされていないアクティブ状態またはそのデバイスのデバイス故障パラメータに一意に対応する。またさらに、ウィンドウ1110は、デバイスのRECOMMENDED_ACTIONパラメータに関連づけられかつデバイスのデバイス記述内に格納されることが可能なテキスト情報を表示する推奨アクション・バー1122を供給する。さらにウィンドウ1110は、システム・ユーザまたはオペレータによって選択されると、ユーザまたはシステム・オペレータによるその時点で目に入る警報または警告を発生させたデバイスのトラブルシューティング、修繕、他を促進するためのテキスト情報を含む別のポップアップ・ウィンドウ(図27に示す、後述のヘルプ・ウィンドウ1144等)を呼び出すことが可能なヘルプ・ボタン1124を含む。
図26は、圧力発信器PT101に関連づけられるステータス情報を供給するポップアップ・ウィンドウ1130の別の例示的描写である。図26に示すウィンドウ1130の全体フォーマットは図25に示すものと同一であるが、ウィンドウ1130は圧力発信器PT101に保全警報または警告を発生させる原因になり得る状態である可能状態1132を含む点が異なる。本例では、保全ボタン1116が強調され、またはアクティブであり、これは、圧力発信器PT101に関するMAINT_ALMに関連づけられるマスクされていない状態またはデバイス要保全パラメータが現時点でアクティブであることを示す点は留意されるべきである。
図27は、フロー発信器FT101に関連づけられるステータス情報を提供しかつフロー発信器FT101に関するMAINT_ALMまたはデバイス要保全パラメータにより報告されることが可能な状態に類似する、または上記状態と同一である可能状態グループ1142を含むポップアップ・ウィンドウ1140のさらに他の例示的描写である。図27はまた、ヘルプ・ボタン1124を選択することによって呼び出されることが可能なヘルプ・ウィンドウ1144を示している。図27に示すように、ヘルプ・ウィンドウ1144は、フロー発信器FT101のデバイス記述により供給されかつワークステーション1014へ送信されて警報表示ソフトウェア1050を介して表示されることが可能である詳細なテキスト情報を含む。
警報表示及びインタフェース・ソフトウェア1050は、Fieldbus、HART及び規格4-20mAデバイスと合同して使用されるように記述されているが、これは、他の任意の外部プロセス制御通信プロトコルを使用して実装されることが可能であり、かつ他の任意のタイプのコントローラ・ソフトウェアと共に使用されることが可能である。本明細書に記載した警報表示及びインタフェース・ソフトウェア1050は好適にはソフトウェアとして実装されるが、これは、ハードウェア、ファームウェア、他に実装される場合もあり、かつプロセス制御システム1000に関連づけられる他の任意のプロセッサによって実装される場合もある。従って、本明細書に記載したルーチン1050は、規格汎用プロセッサ内に、または所望に沿って特別に設計されたハードウェアまたはファームウェアを使用して実装されることが可能である。ソフトウェアに実装される場合、ソフトウェア・ルーチンは、磁気ディスク、レーザ・ディスクまたは他の記憶媒体上等の任意のコンピュータ読取り可能メモリに、コンピュータまたはプロセッサのRAMまたはROM、他に格納されることが可能である。同様に、このソフトウェアは、例えばコンピュータ読取り可能ディスクまたは他の可搬式コンピュータ記憶メカニズム上を含む任意の周知配信方法または所望される配信方法を介して、または(可搬式記憶媒体を介するこのようなソフトウェアの供給と同じである、または互換性があると見なされる)電話回線、インターネット、他等の通信チャネル上でユーザまたはプロセス制御システムへ配信されることが可能である。
当然ながら、本明細書に記載した独立して報告され得る警報は3つのレベルの警報苛酷度またはタイプ(即ちデバイス故障、デバイス保全及び助言的措置)を有するように記述されているが、代わりに2つまたは4つ以上の苛酷度レベルの使用が可能であることは認識されるべきである。
デバイス警報または警告情報の統合されたディスプレイを有効化することに加えて、上述の警報編成及び優先順位システム及び技術もまた、デバイス警報または警告と典型的にはプロセス制御プラントまたは企業内で使用されるビジネス・システムとのより効果的な統合を有効化する。図28は、イベント管理システム1202を使用してデバイス警報または警告と1つまたは複数のビジネス・システム1204とを統合するシステム1200の例示的なファンクション・ブロック図である。資産管理システム1206は、デバイス警報または警告、プロセス警報または警告もしくはプロセス制御システムまたはプラントのオペレーションに関する他の任意の所望される警報または警告情報をイベント管理システム1202へ供給する、または伝達することが可能である。一般的に言えば、資産管理システム1206は、様々な診断ツールと、最適化ツールと、プロセス制御ツール及びプロセス制御プラントのオペレーションに関する情報を処理するために使用されることが可能な他の任意のソフトウェア及び/またはハードウェア・ツールとの間の情報の相互運用及び交換を調整する。資産管理システム1206は、ワークステーション1014の一方または双方に実装されることが可能であり、かつ図23に関連して論じた警報処理ソフトウェア1050を含むことが可能である。何れにしても、資産管理システム1206は複数のプロセス制御デバイス、制御ループ、他から警報または警告情報を受信することが可能であり、かつこの警報または警告情報に優先順位を付け、編成し、または上述の技術に類似する、または一致する技術を使用して故障、保全及び助言的カテゴリに類別する。
資産管理システム1206は、類別された警報または警告情報をイベント管理システム1202へ伝達することが可能である。さらに資産管理システム1206は、イベント管理システム1202へ伝達される警報または警告の各々に関して記述情報(例えばテキスト情報)をイベント管理システム1202へ送ることが可能である。この記述情報は、フィールド・デバイスから直接受信してデータベース1208に格納される場合もあれば、代替として、監視されているデバイスの各々についてユーザまたはオペレータにより生成され、後の検索またはイベント管理システム1202への伝達用にデータベース1208に格納される場合もある。
イベント管理システム1202は概して、資産管理システム1206とビジネス・システム1204との間のエキスパート・システム・インタフェースとして機能する。より具体的には、イベント管理システム1202は、実行されると警報または警告情報がビジネス・システム1204へ送信される、またはそうでなければビジネス・システム1204のオペレーションに影響を与える方法を制御するためにイベント管理システム1202により使用される警報または警告の優先順位及びルールを構成するために使用されることが可能な、1つまたは複数の構成ルーチン1210を含むことが可能である。構成の間、ユーザまたはオペレータには、イベント管理システム1202により監視されるべきデバイス(即ち、このデバイスから警報または警告情報が受信されかつ処理される)の選択を容易にするグラフィック・インタフェースが供給されることが可能である。構成ルーチン1210は、例えばプロセス制御システム内の各デバイスを一意に同定する全デバイス・タグのリストまたはテーブルを保持することが可能であり、かつユーザによる特定デバイスの選択または非選択を基礎としてこのリストまたはテーブルを更新することが可能である。周知のウィンドウ・ベースのグラフィクス、ポイント−アンド−クリック・オペレーション、他は、ユーザまたはオペレータに監視または追跡されるべきデバイスを選択しかつ非選択状態にするための直観的グラフィック・インタフェースを供給するために使用されることが可能である。
構成ルーチン1210はまた、ユーザまたはオペレータが選択される各デバイスに関して監視されるべき特定のパラメータ(即ち特定のデバイス警報または警告)を選択または定義できるようにすることが可能である。監視されることが可能なパラメータ、警報または警告は、例えばデバイス記述を使用してデバイス自体によって提示されることが可能である。当然ながら、選択される各デバイスを監視するために利用可能なパラメータは、かわりに例えば資産管理システム1206内のデータベース1208等のデータベースから供給されることが可能である。何れにしても、選択される各パラメータにもまた、例えば、1乃至10の範囲の数値であることが可能な優先順位が割り当てられる。但し、1は最も低い優先順位であり、10は最高の優先順位値であることが可能である。当然ながら、所望されれば、他の任意の数値範囲または他の任意の記号を使用して変化する優先レベルを表示することも可能である。例えば、パラメータには0乃至100の範囲の数値である優先順位が割り当てられることが可能であり、この場合の0は最高の優先順位、100は最低の優先順位である。
監視用に選択される各パラメータに割り当てられる優先順位は、必須ではないが好適には、そのパラメータに関連づけられる警報または警告の全体的苛酷度を反映する。従って、デバイスにより発生される警告のタイプ(即ち、その警告が特にどのパラメータに関連するか)及びデバイスのオペレーションの監視されるデバイスを内部で使用する制御システム全体に対する相対的重要さが、優先順位値の割当てに影響する可能性がある。本明細書で論じた故障、保全及び助言的カテゴリは、優先順位の割当てを自動的に発生させるために使用されることが可能である。例えば、イベント管理システム1202が1乃至10の数値を使用して増大するパラメータ優先レベルを表すとすれば、イベント管理システム1202は、故障と類別される警報または警告に数値10を割当て、保全と類別される警報または警告に数値5を割当て、かつ助言と類別される警報または警告に数値1を割当てることが可能である。当然ながら、システム・ユーザまたはオペレータはこれらの自動的な優先順位付けを無効にすることを許容される可能性があり、選択されるパラメータの1つまたは複数に異なる優先順位を割り当てることが可能である。例示として、保全エンジニアは、ある特定のデバイスをプロセス制御システムまたはプラントのオペレーションにとって極めて重大であると考える可能性があり、そのデバイスに関して選択されるパラメータに関連づけられる警報または警告の幾つか、または全てが本質的に保全または助言として類別されていたとしても、このデバイスに関連づけられる全ての警報または警告に高い優先順位(例えば10)を割り当てることが可能である。反対に、プロセス制御システムまたはプラント内のデバイスが重要でないプロセス・パラメータの監視に使用されているだけである場合には、そのデバイスに関して選択されるパラメータに関連づけられる警報または警告の幾つか、または全てが故障として類別されるとしても、ユーザまたはオペレータはそのデバイスに関連して受信される警報または警告に比較的低い優先順位(例えば1)を設定することが可能である。このように、幾つかのデバイスのオペレーションは他より重大である可能性があることから、プロセス制御システム内の異なるデバイスが同じ警報または警告に対して異なる優先順位を有する場合がある。上述のデバイス選択プロセスの場合のように、パラメータ選択及び優先順位決定プロセスは、ウィンドウ−ベースのグラフィック・ユーザ・インタフェースを使用して実行されることが可能である。さらに、所望されれば、選択されるパラメータの各々に関する適正な優先レベルの決定をアシストするためにポップアップ・ヘルプ・ウィンドウが自動的に供給される、もしくはユーザまたはオペレータの要求で供給されることが可能である。
またさらに、図29に示すように、イベント管理システム1202は、イベント管理システム1202により受信される警報または警告がビジネス・システム1204の1つまたは複数へ送信されるべきかどうかを決定するルール・エンジン1212を含むことが可能である。ルール・エンジン1212は、例えばどの警報または警告がビジネス・システム1204のどの1つへ送信されるべきか、または送信されるべきでないかを指示するフィルタとして機能するルックアップ・テーブル等の比較的単純なルールを使用して実装されることが可能である。これに対して、1つまたは複数のプラント状態、プロセス制御システム状態、他を考慮する複合条件付きロジック等のより複雑なルールは、ルール・エンジン1212内で実装されることが可能である。単に例示として、条件付きロジックは、例えば「条件Aが真であれば、措置Bを講じよ」等のロジック条件に類似する、またはこれに一致する可能性がある。
図29に示すように、イベント管理システム1202はまた、1つまたは複数の状態マシン1214と、データベース1216とを含むことが可能である。状態マシンのオペレーションの基本原理は技術上周知であり、よってここでは詳述を省く。但し、状態マシン1214は、状態情報をルール・エンジン1212へ供給すべく特別に適合化される。特に、状態マシン1214は、ルール・エンジン1212が例えば、ある措置が講じられるべきかどうかを決定する前に1つまたは複数の条件(上記条件「A」等)が真であるか偽であるかを決定すべく状態情報を検索するためにアクセスすることが可能なデータベース1216内の状態テーブルを格納することが可能である。
上述のイベント管理システム1202は、プロセス制御プラントに関連づけられるプロセス制御システム及びビジネス・システムと通信状態にあるワークステーション、サーバまたは他の任意のコンピュータ内で実行されるソフトウェアまたはハードウェアとソフトウェアとの組合せとして実装されることが可能である。例えば、図22に示すプロセス制御システム1000の場合、イベント管理システム1202は、ワークステーション1014の一方または双方、もしくはプロセス制御システム1000に通式可能に接続される他の任意のワークステーション、サーバまたはコンピュータ・システム内に実装されることが可能である。
運転中、資産管理システム1206は、構成ルーチン1210を実行する間に選択された特定のデバイスの特定のパラメータに関連づけられる警報または警告情報を送信する。ルール・エンジン1212は受信される警報または警告情報を処理し、もしあればビジネス・システム1204のどれが通知を受信するかを決定する。これらの通知は、警告、警告に関連づけられる優先順位及びデバイス記述によって供給される、またはデバイス記述から導出されることが可能な警告に関する記述を含むことが可能である。このような記述は、例えば検出された問題点を改善するためのデバイスの修繕及び/または交換に関するテキスト情報を含むことが可能である。さらに、これらの通知は、好適にはビジネス・システム1204のうちの受信する1つによって何らかの措置を引き出すように設計される。場合によっては、ビジネス・システムは通知を要求するように設計されることが可能であり、こうした場合、イベント管理システム1202はこのような要求が行われなければ通知を送らない。但し他の場合には、ビジネス・システムは、イベント管理システム1202にポーリングを行う必要なく単にイベント管理システム1202からの通知を受信することが可能である。
通知を送信した後、イベント管理システム1202は、資産管理システム1206によって送信される警報または警告のステータスの変化に応答して、ビジネス・システム1204の1つまたは複数へ後続通知を送ることが可能である。より具体的には、状態マシン1214は、イベント管理システム1202が追跡するように構成された警報または警告のカレント・ステータスが継続して監視され得るように資産管理システム1206から情報を受信する。このようにして、イベント管理システム1202は、例えばまずビジネス・システム1204の1つにデバイスが保全を必要としていることを通知し、続いて、資産管理システム1206からのこのような故障が検出されていることを指摘する警報または警告の受信に応答して、そのビジネス・システムの1つにデバイスが故障していることを通知することが可能である。必須ではないが好適には、状態マシン1214は、イベント管理システム1202とビジネス・システム1204との間の通知の通信を管理するために使用されることが可能である。イベント管理システム1202が警報または警告情報に関して資産管理システム1206にポーリングを行っているという状況では発生する可能性のある、資産管理システム1206からの複数の同じ警報または警告の受信に応答して複数の、または冗長な通知を送信することとは対照的に、状態マシン1214は、ステータスの変化にのみ応答して通知を更新する、または通知をビジネス・システム1204へ送信するように構成されることが可能である点は重要である。
概して、ビジネス・システム1204は、企業資産管理システム、異常状況管理システムまたはプロセス制御プラントのオペレーションに関連して使用される可能性のある他の任意のシステムを含むことが可能である。企業資産管理システムの特に有益なタイプの1つは、プロセス制御プラントの保全要員のアクティビティを調整するために使用されることが可能なコンピュータ化された保全システム(CMMS)である。イベント管理システム1202がCMMSへ通知を送るようなケースでは、通知は、警報または警告情報、通知を起こした警報または警告に応答するための提案または指令を含むテキスト情報、CMMSに所望される方法で応答させるコマンドまたは他の指令、他を供給することが可能である。保全要員により実行される作業を促進するため、CMMSは、最優先の作業命令がまず実行され得るように作業命令情報、予防保全情報または他の任意の保全情報を表示し、印刷し、またはそうでなければこれらを保全要員へ伝達することが可能である。
ビジネス・システム1204はまた、確認情報をイベント管理システム1202へ送るように適合化されることも可能である。一般的に言えば、これらの確認は、ビジネス・システム1204のユーザによる、またはオペレータによる使用またはビジネス・システム1204との相互作用に関連して実行されている措置を示す情報を含む。これらの確認は、イベント管理システム1202により、イベント管理システム1202内でイベントをクリアする、かつ/または状態マシン1214を更新するために使用されることが可能である。イベント管理システム1202はまた、データベース1208内へ格納するために確認情報を資産管理システム1206へ送ることが可能である。例えばCMMSの場合、CMMSは、作業命令の発生に応答して、予防保全要求に応答して、特定の問題点または作業命令への要員の配備に応答して、作業命令または予防保全要求に関連づけられる作業が完了したとき、作業命令または予防保全要求が閉じられるとき、他で確認をイベント管理システム1202を介してデータベース1208へ送ることが可能である。このようにして、データベース1208に格納された確認情報は、資産管理システム1206により監視されるデバイスに関して実行される作業の完全な記録及び文書調製を供給するために使用されることが可能である。当然ながら、他のタイプのビジネス・システム(即ちCMMSでないもの)によって送られる確認は、ビジネス・システムの性質に整合している。
従って、周知のコンピュータ化された保全管理システムとは対照的に、本明細書に記載したイベント管理システム1202は、純粋に反応的に単なる修繕または交換を実行する、かつ/または単に予め決められたスケジュールに基づいて予防保全アクティビティを実行するのではなく、例えばプロセス制御プラント内の保全アクティビティのスケジューリングを、実際のデバイス・パフォーマンスを予測する方法で、かつ実際のデバイス・ステータスまたは状態を基礎とする方法で自動化するために使用されることが可能である。特に、本明細書に記載したイベント管理システム1202は、CMMSと共用されると保全要員が実際のデバイス状態またはステータスを基礎としてデバイスに予防保全を実行することを有効化し、これにより、不測のデバイス故障及び/または予定外のプラント停止が最小限に抑えられる、または排除される。例えば、1つまたは複数のフィールド・デバイスは衝撃線の閉塞を監視するために使用されることが可能であり、かつ故障状態を回避するためには上記線に対する当を得た措置または保全が必要であることを示す警報または警告を送ることが可能である。スマート・バルブ、リニア・アクチュエータまたは他の類似デバイスの場合、デバイスは、デバイスの合計ストローク数及び定格寿命を基礎として、バルブ、アクチュエータまたは他のデバイスが早急に整備されるべきであることを示す警報または警告を送ることが可能である。例えばモータ等の回転機器の場合には、1つまたは複数のスマート・フィールド・デバイスがモータ軸またはモータの他の部分の振動を監視するために使用されることが可能であり、かつ振動の性質はベアリング及び/またはモータの他のコンポーネントが摩耗していて故障の発生前に交換されるべきであることを示していると指摘する警報または警告を送ることが可能である。
上述の警報処理ソフトウェアの場合のように、本明細書に記載したイベント管理システム1202は、ハードウェアとソフトウェアの任意の所望される組合せを使用して実装されることが可能である。このようなハードウェアは、プログラム可能コントローラ、マイクロプロセッサ、アプリケーション指定集積回路または他の任意のデジタル回路及びアナログ回路を含むことが可能である。ソフトウェア実装は、高レベル及び低レベルのプログラミング言語の任意の組合せを使用することが可能であり、このようなソフトウェアは、ソリッド・ステート、磁気または光媒体を含む任意のコンピュータ読取り可能メモリに格納されることが可能である。さらに、イベント管理システム1202、ビジネス・システム1204及び資産管理システム1208は、例えばインターネットを含む任意の所望される通信ネットワークを介して互いに通信することが可能である。
図30は、図1のプロセス・プラント10等のプロセス・プラントにおいて使用されることが可能なシステム1300内の情報フローのブロック図である。プロセス・プラント内の様々なプロセス・エンティティまたはプロセス・エンティティを監視する監視機器、診断機器、他は、様々なプロセス・エンティティに関連づけられるオペレーション・ステータス情報を発生させることが可能である。典型的には、これらのプロセス・エンティティの多くに関連づけられるオペレーション・ステータス情報は、上述の独立して報告され得る警報パラメータFAILED_ALM、MAINT_ALM及びADVISE_ALMとは整合しない。このオペレーション・ステータス情報の統合された監視及び/または処理及び/または表示を促進するために、マッピング・システム1304は、オペレーション・ステータス情報を上述のFAILED_ALM、MAINT_ALM及びADVISE_ALMの各カテゴリへマップする。従ってマッピング・システム1304は、オペレーション・ステータス情報が例えばシステム・オペレータ、保全要員、ビジネス要員、他へ先行システムよりも整合的かつ論理的な方法で報告または表示されるべく有効化することが可能である。図30のシステム1300は図1のプロセス・プラント10等のシステムに実装されることが可能であり、よって図1を参照して説明していく。
マッピング・システム1304は、フィールド・デバイス1308、プロセス制御ソフトウェア1312、ハードウェア・デバイス1316(例えばプロセス・コントローラ、入力/出力デバイス、オペレータ・ワークステーション、ネットワーク機器、他)、監視及び/または診断システム1320、ソフトウェアまたは数学モデル1324、最適化システム1332、保全システム1336、他を含む様々なプロセス・エンティティに関連づけられるオペレーション・ステータス情報を受信することが可能である。図1のプロセス・プラント10では、マッピング・システム1304は例えばコンピュータ30によって実装されることが可能である。特定例として、マッピング・システム1304は、図22及び23を参照して説明したような警報処理ソフトウェア1050に類似するソフトウェアの一部として実装されることが可能である。追加の例では、マッピング・システム1304は、図28及び29を参照して説明したようなイベント管理システム1202及び/または資産管理システム1206の一部として実装されることも可能である。
マッピング・システム1304は、コンピュータ12A、14A、18、22、26、35、36、他等の1つまたは複数の他のコンピュータ、ワークステーション、他によって実装され得る。例えば、回転機器に関連づけられるマッピング・オペレーション・ステータス情報に関連するマッピング・システム1304の一部はコンピュータ22によって実装されることが可能であり、発電/配電機器に関連づけられるマッピング・オペレーション・ステータス情報に関連するマッピング・システム1304の別の部分はコンピュータ26によって実装されることが可能である。従って、マッピング・システム1304は単一のコンピュータ上に実装される場合もあれば、マッピング・システム1304は複数のコンピュータによって実装される分散システムである場合もある。
フィールド・デバイス1308は、フィールドバス・デバイス、HARTデバイス、PROFIBUS(登録商標)、WORLDFIP(登録商標)、DeltaVDEVICE-NET(登録商標)、CAN、イーサネット(登録商標)、他等のオープン・プロトコルに従って通信するデバイス、自社独自のプロトコルに従って通信するデバイス、他を含むことが可能である。フィールド・デバイス1308に関連づけられるオペレーション・ステータス情報は、警報または警告、ステータス状態またはフィールド・デバイス1308のオペレーション・ステータスに関連する他の情報を含むことが可能である。図1を参照すると、フィールド・デバイス1308はフィールド・デバイス15及び16を含むことが可能である。フィールド・デバイス1308に関連づけられるオペレーション・ステータス情報は、フィールド・デバイス15及び16、コンピュータ12A、14A、18、コントローラ12B、14B、他から受信されることが可能である。
プロセス制御ソフトウェア1312に関連づけられるオペレーション・ステータス情報は、プロセス警報または警告もしくはプロセス制御ソフトウェア1312のオペレーション・ステータスに関連する他の情報を含むことが可能である。図1を参照すると、プロセス制御ソフトウェア1312は、コントローラ12B及び14Bにより実装されるソフトウェア、フィールド・デバイス16内のソフトウェア、他を含むことが可能である。
ハードウェア・デバイス1316に関連づけられるオペレーション・ステータス情報は、警報または警告もしくはハードウェア・デバイス1316のオペレーション・ステータスに関連する他の情報を含むことが可能である。図1を参照すると、ハードウェア・デバイス1316は、コントローラ12B、14B、I/Oカード312C、コンピュータ12A、14A、18、22、26、30、他を含むことが可能である。ハードウェア・デバイスはまた、スイッチ、ルータ、ブリッジ、ハブ、他等のネットワーク・デバイスを含むことが可能である。ネットワーク・デバイスは、イーサネット(登録商標)・ネットワーク等のネットワークに結合されることが可能である。さらにネットワークは、簡易ネットワーク管理プロトコル(SNMP)による通信用に構成されることが可能である。さらに、ハードウェア・デバイス1316に関連づけられるオペレーション・ステータス情報は、ハードウェア・デバイスにより実行されるソフトウェアによって発生される警報、警告、メッセージ、他を含むことが可能である。一例として、ハードウェア・デバイス1316に関連づけられるオペレーション・ステータス情報は、ネットワーク・オブジェクトにより発生される情報であることが可能である。ネットワーク・オブジェクトは、SNMPに従ってオペレーション・ステータス情報を送信することが可能である。
監視及び/または診断システム1320は、上述のもの等の診断分析を監視及び/または実行するシステムを含むことが可能である。例えばこのようなシステムは、プロセス・システム(例えば原因診断システム)、回転機器、発電及び/または配信機器、他の診断分析を監視及び/または実行することが可能である。監視及び/または診断システム1320に関連づけられるオペレーション・ステータス情報は、監視及び/または診断システム1320により監視及び/または分析されているプロセス・システムまたは機器のオペレーション・ステータスに関する警報または警告もしくは他の情報を含むことが可能である。図1を参照すると、監視/分析される機器は、例えば回転機器20、発電/配電機器25、他を含むことが可能であり、オペレーション情報は、例えばコンピュータ22及び26から受信されることが可能である。
ソフトウェアまたは数学モデル1324及びエキスパート・システム1328は、上述のもの等のモデル及びエキスパート・システムを含むことが可能である。最適化システム1332及び保全システム1336は、上述のもの等の最適化及び保全システムを含むことが可能である。
マッピング・システム1304は、プロセス・エンティティに関連づけられるオペレーション・ステータス情報を受信することが可能であり、かつ対応する警報メッセージ(例えば上述のFAILED_ALM、MAINT_ALMまたはADVISE_ALM)を発生させることが可能である。対応する警報メッセージは、オペレーション・ステータス情報及び追加要素(例えばプロセス・エンティティのロケーションまたはプロセス・エンティティが位置づけられるプロセス・プラントのセクション、フィールド・デバイス、プロセス制御ソフトウェア・モジュール、他が警告、警報、ステータス状態、他を発生させている速度、フィールド・デバイスのタイプ、ユーザ・インタフェース、他)を基礎として発生されることが可能である。プロセス・エンティティに関連づけられるオペレーション・ステータス情報は、例えばプロセス・エンティティの問題点、状態、他の相対苛酷度を示す優先順位値、苛酷度値、他を含むことが可能である。この場合、マッピング・システム1304は、優先順位値または苛酷度値を基礎として対応する警報パラメータを発生させることが可能である。
マッピング・システム1304はまた、所定のオペレーション・ステータス情報をNO_COMMUNICATION警報メッセージへマップすることが可能である。例えば、プロセス・エンティティに関連づけられるオペレーション・ステータス情報は、プロセス・エンティティ(またはプロセス・エンティティを監視するデバイス)との通信がもはや発生していないと指摘することが可能である。このようなオペレーション・ステータス情報は、NO_COMMUNICATION警報メッセージへマップされることが可能である。
FAILED_ALM、MAINT_ALM、ADVISE_ALM及びNO_COMMUNICATION警報メッセージは、上述の技術及び警報メッセージに類似する方法及びフォーマットで発生されることが可能である。例えば警報メッセージは、ユーザ・インタフェース上での最終ディスプレイ用にフォーマットされることが可能である。別の例では、警報メッセージは、別のデバイスとの通信用にDS-71またはDS-72IEEE規格等のフォーマットに従ってフォーマットされることが可能である。さらに警報メッセージは、優先レベル、推奨措置、詳細なヘルプを提供するテキストまたは文書へのリンク、他を示す情報を含むことが可能である。リンクされるテキストまたは文書は、問題点を処理するための手順、文書、図面、別の文書へのリンク、図面へのリンク、他を含むことが可能である。
再度図1を参照すると、コンピュータ30はプロセス・エンティティに関連づけられるオペレーション・ステータス情報に対応する警報メッセージを発生させることが可能であり、かつ警報メッセージを例えば表示するためにオペレータ・ワークステーションへ、ビジネス・システムへ、デバイス他へ伝達することが可能である。
様々なプロセス・エンティティからのオペレーション情報はマッピング・システム1304により共通のフォーマットで、かつプロセス・プラント内の他のデバイス、システム、他により発生される警報メッセージに共通である可能性のあるフォーマットで供給されることから、オペレーション情報の相対的な重要さは、より容易に確定され得る。例えば、回転機器に関連づけられる診断情報がFAILEDカテゴリへマップされかつフィールド・デバイスに関連づけられる警報がMAINTENANCEカテゴリへマップされれば、オペレータは、回転機器に伴う問題点がフィールド・デバイスに伴う問題点よりも差し迫った問題である可能性のあることをより容易に推論することが可能である。
本明細書に記載したマッピング・システム1304は、ハードウェアとソフトウェアの任意の所望される組合せを使用して実装されることが可能である。このようなハードウェアは、プログラム可能コントローラ、マイクロプロセッサ、アプリケーション指定集積回路または他の任意のデジタル回路及び/またはアナログ回路を含むことが可能である。ソフトウェア実装は、高レベル及び低レベルのプログラミング言語の任意の組合せを使用することが可能であり、このようなソフトウェアは、ソリッド・ステート、磁気または光媒体を含む任意のコンピュータ読取り可能メモリに格納されることが可能である。さらに、マッピング・システム1304は、例えばバス、LAN、WAN、インターネット、他を含む任意の所望される通信ネットワークを介して他のシステムと通信することが可能である。
このように、単なる例示を意図したものであって本発明を限定するものではない特定の例を参照して本発明を説明してきたが、一般的な当業者には、本発明の精神及び範囲を逸脱することなく開示された実施形態に変更、追加または削除を行ない得ることが明白であろう。