JP2007141219A - プロセスコントロールシステムにおけるプロセスモデル識別 - Google Patents

Abstract

【課題】複数のコントロールループを有するプロセスコントロールシステムを管理すること。
【解決手段】動作条件データは、複数のコントロールループの各コントロールループの動作に関連して収集され、それぞれのプロセスモデルは、該複数のコントロールループのコントロールループごとに収集された該それぞれの動作条件データから該複数のコントロールループのコントロールループごとに識別される。一部の実施形態では、該それぞれのプロセスモデルの識別は、検出されたプロセス変化の結果として自動的であってもよく、あるいは注入されたパラメータ変化の結果としてオンデマンドであってもよい。
【選択図】図２

Description

本発明は概してプロセスコントロールシステムに関し、より具体的にはプロセスコントロールシステムにおけるプロセスモデルの識別および適用に関する。

化学、石油または他のプロセスで使用されるような分散またはスケーラブルプロセスコントロールシステムなどのプロセスコントロールシステムは通常、アナログ、ディジタルまたは結合アナログ／ディジタルバスを介して相互に、少なくとも１つのホストまたはオペレータワークステーションに、かつ１つ以上のフィールドデバイスに通信可能に結合された１つ以上のプロセスコントローラを含んでいる。例えばバルブ、バルブポジショナー、スイッチおよび送信機（例えば、温度、圧力および流量センサー）であってもよいフィールドデバイスは、バルブの開閉およびプロセスパラメータの測定などのプロセス内の機能を実行する。プロセスコントローラは、フィールドデバイスによってなされたプロセス測定結果および／またはフィールドデバイスに関する情報を表す信号を受信し、この情報を使用してコントロールルーチンを実施し、そしてプロセスの動作をコントロールするためにフィールドデバイスにバスを介して送られるコントロール信号を生成する。フィールドデバイスおよびコントローラからの情報は通常、オペレータワークステーションによって実行される１つ以上のアプリケーションに対して使用可能とされて、プロセスの現在の状態を閲覧したり、プロセスの動作を修正したりするなどの、プロセスに対する所望の機能をオペレータが実行できるようにする。

Ａｕｓｔｉｎ，Ｔｅｘａｓに本社があるＦｉｓｈｅｒ Ｒｏｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，によって販売されているＤｅｌｔａＶ（登録）システムなどのプロセスコントロールシステムは、コントローラや異なるフィールドデバイスに配置されたモジュールと称される機能ブロックや機能ブロックグループを使用して、コントロール動作を実行する。これらの場合、コントローラや他のデバイスは１つ以上の機能ブロックやモジュールを含み、かつ実行することが可能であり、これらの各々は（同一のデバイス内または異なるデバイス内のいずれかの）他の機能ブロックからの入力を受信し、かつ／またはこれらへの出力を提供し、プロセスパラメータの測定や検出、デバイスのコントロール、あるいは比例積分微分（ＰＩＤ）コントロールルーチンの実施などのコントロール動作の実行などのプロセス動作を実行する。プロセスコントロールシステム内の異なる機能ブロックおよびモジュールは概して、（例えば、バスを介して）相互に通信して１つ以上のプロセスコントロールループを形成するように構成されている。

プロセスコントローラは通常、流量コントロールループ、温度コントロールループ、圧力コントロールループなどのプロセスに対して定義され、あるいはこのプロセス内に含まれた多数の異なるループの各々について、（すべてコントロールルーチンである）異なるアルゴリズム、サブルーチンまたはコントロールループを実行するようにプログラミングされている。一般的に、このような各コントロールループは、アナログ入力（ＡＩ）機能ブロックなどの１つ以上の入力ブロック、比例積分微分（ＰＩＤ）やファジー理論コントロール機能ブロックなどの単出力コントロールブロック、およびアナログ出力（ＡＯ）機能ブロックなどの出力ブロックを含んでいる。

コントロールルーチンと、このようなルーチンを実施する機能ブロックとは、ＰＩＤコントロール、ファジー理論コントロール、およびスミス予測器（Ｓｍｉｔｈ Ｐｒｅｄｉｃｔｏｒ）やモデル予測コントロール（ＭＰＣ）などのモデルベース技術を含む多数のコントロール技術に従って構成されていた。モデルベースコントロール技術において、閉ループコントロール応答を判断するためのルーチンで使用されているパラメータは、プロセスへの入力として作用する操作または測定外乱の変化に対する動的プロセス応答に基づいている。プロセス入力の変化に対するプロセスのこの応答の表示はプロセスモデルとして特徴付けられることがある。例えば、第１次パラメータ化プロセスモデルは、プロセスの利得、無駄時間および時間定数の値を特定することがある。

モデルベース技術であるモデル予測コントロール（ＭＰＣ）は、プロセスの入力と出力の動的関係を捕捉するように設計された多数のステップやインパルス応答モデルを伴う。ＭＰＣ技術によって、プロセスモデルはコントローラを生成するために直接使用される。プロセスの無駄時間やプロセス遅延などの大きな変化を経験するプロセスに関連して使用される場合、ＭＰＣコントローラは、現在のプロセス条件に一致するようにモデルを使用して自動的に再生成されなければならない。このような場合、プロセスモデルは多数の動作条件の各々でそれに応じて識別されていた。現在のプロセス条件に一致するための複数のプロセスモデルの導入およびコントローラの必須自動生成は望ましくないことに、プロセスコントロールシステムの複雑さを増大させる。

プロセスモデルはまた、適合コントロール技術を使用してＰＩＤおよび他のコントロールスキームのチューニングパラメータを設定するために使用されており、この場合ＰＩＤ（または他の）コントローラのチューニングは概して、プロセスモデルおよびユーザが選択したチューニングルールの変化の結果として更新される。開示全体が参照してここに組み込まれている、「静的ベース適合フィードバック・フィードフォワードＰＩＤコントローラ（Ｓｔａｔｅ Ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｆｅｅｄｂａｃｋ Ｆｅｅｄｆｏｒｗａｒｄ ＰＩＤ Ｃｏｎｔｒｏｌｌｅｒ）」と題された米国特許公開第２００３／０１９５６４１号、および「適合フィードバック／フィードフォワードＰＩＤコントローラ（Ａｄａｐｔｉｖｅ Ｆｅｅｄｂａｃｋ／Ｆｅｅｄｆｏｒｗａｒｄ ＰＩＤ Ｃｏｎｔｒｏｌｌｅｒ）」と題された米国特許第６，５７７，９０８号を参照のこと。

コントロール性能の改良の見込みにもかかわらず、プロセス産業における適合コントロール技術の使用は、これらの技術がしばしば実用的に実施困難であったため、制限されていた。実用的な問題として、モデル識別は通常、特に適合コントロールに対して設計された特定機能ブロックの一部であった。残念ながら、いずれのプロセスコントロールループが適合コントロールの実施の利益を享受するか、つまりいずれのループが適合コントロール能力に対して選択されるべきかを判断するのはしばしば困難である。１つの理由は、通常のプラントで監視される極めて多くの（例えば、数百の）コントロールループおよび機器（例えば、数千）に関する。しかしプラントのサイズや複雑さに関わらず、従来のプロセスコントロールシステムは通常、プラントにおけるコントロールループのすべてに対するプロセスモデルの作成をサポートしない。さらに悪いことに、全コントロールループに対する新たなプロセスモデルの識別に必要なマニュアルテストは実際に実行されないこともある。例えば、テストは、オンラインプロセスと矛盾する１つ以上のプロセス摂動の適用を必要とする場合がある。

動作において、適合コントロール技術は限定的な診断能力を提供していた。より具体的には、適合コントロールスキームがプロセスコントロールにおいて選択的に実用化される場合、識別されたプロセス応答は概して、コントロールループのチューニングを確立するためだけに使用される。結果として、プロセスコントロールシステムは、コントロール性能の損失を招くプロセスや機器の異常な条件を示せないことがある。

本開示の一態様によると、複数のコントロールループを有するプロセスコントロールシステムをコントロールするための方法が有用である。該方法は、該複数のコントロールループの動作をコントロールするための複数のコントロールルーチンを実施するステップであって、該複数のコントロールルーチンが少なくとも１つの非適合コントロールルーチンを含んでいるステップと、該複数のコントロールループの各コントロールループの動作に従って動作条件データを収集するステップと、該複数のコントロールループのコントロールループごとに収集された該それぞれの動作条件データから該複数のコントロールループのコントロールループごとにそれぞれのプロセスモデルを識別するステップとを含む。

該方法がさらに、該複数のコントロールループのコントロールループごとのそれぞれのプロセスモデル履歴に、該それぞれの識別されたプロセスモデルを示すデータを記憶するステップを含む場合もある。該方法はまた、該動作条件データを検証して、その変化を検出するステップと、該変化が検出された場合に該プロセスモデル識別をトリガするステップとを含んでもよい。

一部の実施形態では、該識別は、ユーザコマンドに応答して、該収集された動作条件データに基づいて該プロセスモデルを計算するために実行される場合がある。そして該収集された動作条件データは、該ユーザコマンドの結果として適用された注入パラメータ変化への応答を示す場合がある。

該動作条件データは、該複数のコントロールループの該動作を介してコントロールされるプロセスのオンライン動作を示す場合がある。

該方法はさらに、コントロールループごとに識別された該それぞれのプロセスモデルを監視して、コントロールループ性能を評価するステップを含むことがある。代替的または付加的に、該方法はまた、コントロールループごとに識別された該それぞれのプロセスモデルを分析して、いずれのコントロールループが適合コントロールスキームを利用すべきかを判断するステップを含む場合がある。代替的または付加的に、該方法はさらに、コントロールループごとに識別された該それぞれのプロセスモデルを分析してコントロールの問題を診断するステップを含む場合がある。

本開示の別の態様によると、複数のコントロールルーチンを有するプロセスコントロールシステムをコントロールするための方法は、該複数のコントロールルーチンを実施する際に動作条件データを収集するステップと、プロセス変化と関連した該複数のコントロールルーチンのうちの１つのコントロールルーチンに関連する該プロセス変化を示すイベントを検出するステップと、該プロセス変化と関連した該コントロールルーチンに対するプロセスモデルを識別するステップと、該プロセス変化と関連した該コントロールルーチンに対するプロセスモデル履歴を作成する際に該生成されたプロセスモデルを示すデータを記憶するステップとを含んでいる。

該方法がさらに、該イベントの検出時に該識別ステップに対するデータを自動的に収集するステップを含む場合がある。

該方法はまた、該複数のコントロールルーチンのコントロールルーチンごとにそれぞれのプロセスモデルを識別するステップを含むことがある。該複数のコントロールルーチンは、非適合コントロールスキームを実施するコントロールルーチンを含むことがある。

本開示をより完全に理解するために、以下の詳細な説明および添付の図面を参照すべきであり、図面において、同一の参照番号は同一の要素を示している。

開示されるシステムおよび方法は種々の形態の実施形態を許容するが、本発明の具体的な実施形態が図面に示されており（また後述される）、本開示は例示的目的であり、本明細書で説明および図示されている具体的な実施形態に本発明を制限する意図はないことを理解すべきである。

適合コントロールに対するプロセスモデルを現在必ずしも利用していないプロセスコントロールシステムにおいてコントロールループのプロセスモデルを自動的に識別する技術を実施するプロセスコントロールシステムおよび方法がここに開示されている。従って、適合コントロールの実施以外の（または、これに加えて）理由でプロセスモデルが作成される。例えば、いずれのコントロールループが適合コントロールをこれに適合させるべきかについての判断は、開示される技術によって識別されたプロセスモデルの評価によってより簡単になされる。

プロセスモデルの識別が、プロセスコントロールシステムの全コントロールループに拡張される場合がある。このように、プロセスモデルは、プロセスコントロールシステムのノードごとに生成されることがある。しかし、プロセスモデルが、開示されるシステムの具体的な実施形態におけるコントロールループやノードごとに識別されているか否かに関わらず、非適合コントロールループへのプロセスモデル識別の拡張は、とりわけオンデマンドコントローラチューニング、異常条件の監視および診断を含む多数の利点を有している。

プロセスコントロールデータが、コントロールループに対する多数のプロセスモデルを識別するために収集されることによって、プロセスモデルの履歴を生成する場合がある。プロセスモデル履歴を生じるプロセスコントロールデータは、プロセスの日常的動作時に、これと関連して且つこの結果として生成されてもよい。これらの場合、生じるプロセスモデル履歴は、コントロールループの最近のオンライン性能の表示を提供する。そして特殊なテストやテスト手順は必要とされない。

コントロールループが適合コントロールスキーム（例えば、適合ＰＩＤコントロール）を実施している場合、プロセスモデル履歴は、適合コントロールが現在の動作条件に、より一般的にはコントロールループ自体に適しているか否かを示すことがある。反対に、非適合コントロールループに対するプロセスモデル履歴もまた、適合コントロールスキームが有用であることを示す場合がある。

プロセスモデルが、コントロールルーチンを実施するプロセスコントローラに埋め込まれたルーチンによって識別される（例えば、生成される）場合がある。このために、コントローラは、プロセスコントロールデータを記憶して、（複数の）プロセスモデルの生成をサポートするためにプロセス変化によってトリガされることがある。トリガとして作用するプロセス変化や他のイベントは、セットポイント変化、コントローラ出力に自動的に注入された摂動、あるいは開または閉コントロールループへの変化を含んでもよい。これら、かつ他の方法で、プロセスモデル識別ルーチンは、日常的な動作を通してプロセスコントロールデータを捕捉するためのコントローラ（または、システムの（複数の）要素）によって連続的に実施されてもよい。さらにまた、従ってプロセスモデルはプロセス変化（または、他のトリガイベント）の検出時に自動的に識別されてもよく、プロセスがオンラインにある間に、計算のすべてがバックグラウンドで生じる。

識別および／または記憶されると、（複数の）プロセスモデルは、性能監視、オンデマンドチューニング、コントロールアルゴリズム推奨、ループ応答シミュレーション、プロセス監視、コントロール診断および適合コントロールを含むプロセスコントロールシステムの管理と関連して実施される多数のプロセスコントロールタスクをサポートするために分析、処理、適用、または他の方法で利用されてもよい。例えば、以下に説明されるように、プロセスモデルは、識別されたコントロールループのモデルベース性能指数を計算するために使用されてもよい。

開示される技術によって識別されたプロセスモデルはまたモデルベースコントロールスキーム（例えば、適合コントロール）に左右されることがあるが、開示される技術の実施は、特定のタイプのコントロールループ、プロセスコントローラ、プロセスコントロールシステムまたはプロセスコントロールネットワークアーキテクチャに制限されない。さらに、開示される技術は、個々に、あるいは分散的に１つ以上のレベル（例えば、プロセスコントローラレベル、コントロールループレベルなど）で、プロセスコントロールシステムの多数の要素によって実施されてもよい。さらに、開示される技術は特定のプロセスモデルタイプに制限されず、例えば、プロセスのパラメータ化された動的モデルを利用してもよい。

次に図１を参照すると、プロセスコントロールシステム１０は、データヒストリアン１２と、各々がディスプレイスクリーン１４を有している（任意のタイプのパソコン、ワークステーションなどであってもよい）１つ以上のホストワークステーションつまりコンピュータ１３とに接続されたプロセスコントローラ１１を含んでいる。コントローラ１１はまた入力／出力（Ｉ／Ｏ）カード２６および２８を介してフィールドデバイス１５乃至２２に接続されている。データヒストリアン１２は、データを記憶するための所望のタイプのメモリと所望または既知のソフトウェア、ハードウェアまたはファームウェアとを有する所望のタイプのデータ収集ユニットであってもよい。データヒストリアン１２はワークステーション１３のうちの１つとは（図１に示されたように）別個、またはこの一部であってもよい。一例としてＦｉｓｈｅｒ−Ｒｏｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，から販売されているＤｅｌｔａＶコントローラであってもよいコントローラ１１は、例えばイーサネット接続や他の所望の通信ネットワークを介してホストコンピュータ１３およびデータヒストリアン１２に通信可能に接続されている。コントローラ１１はまた、例えば標準４−２０ｍａデバイスおよび／またはＦＯＵＮＤＡＴＩＯＮ ＦｉｅｌｄｂｕｓプロトコルやＨＡＲＴプロトコルなどの任意のスマート通信プロトコルと関連した所望のハードウェアおよびソフトウェアを使用してフィールドデバイス１５乃至２２に通信可能に接続される。

フィールドデバイス１５乃至２２は、センサー、バルブ、送信機、ポジショナーなどの任意のタイプのデバイスであってもよいのに対して、Ｉ／Ｏカード２６および２８は、所望の通信またはコントローラプロトコルに準拠する任意のタイプのＩ／Ｏデバイスであってもよい。図１に示された実施形態では、フィールドデバイス１５乃至１８はＩ／Ｏカード２６へのアナログラインで通信する標準４−２０ｍａデバイスであるのに対して、フィールドデバイス１９乃至２２はＦｉｅｌｄｂｕｓプロトコル通信を使用するＩ／Ｏカード２８へのディジタルバスで通信する、Ｆｉｅｌｄｂｕｓフィールドデバイスなどのスマートデバイスである。当然、フィールドデバイス１５乃至２２は、将来展開される任意の標準やプロトコルを含む他の所望の（複数の）標準やプロトコルに準拠してもよい。

コントローラ１１は、（メモリ２４に記憶されている）１つ以上のプロセスコントロールルーチンを実施または監督するプロセッサ２３を含んでおり、これは、記憶されたり、他の方法で関連付けられたりしているコントロールループを含んでもよく、またデバイス１５乃至２２、ホストコンピュータ１３およびデータヒストリアン１２と通信して、所望の方法でプロセスをコントロールする。本明細書で説明されるコントロールルーチンやモジュールは、所望ならば異なるコントローラや他のデバイスによって実施または実行されるものの一部であってもよい点に留意すべきである。同様に、プロセスコントロールシステム１０内で実施される、本明細書で説明されるコントロールルーチンやモジュールは、ソフトウェア、ファームウェア、ハードウェアなどを含む任意の形態をとってもよい。本開示の目的について、プロセスコントロールモジュールは、例えばコンピュータ可読媒体上に記憶されたルーチン、ブロックまたはこれらの要素を含むプロセスコントロールシステムの一部であってもよい。モジュール、またはサブルーチンなどのコントロール手順の一部、（コードラインなどの）サブルーチンの一部などであってもよいコントロールルーチンは、オブジェクト指向プログラミングを使用したり、ラダーロジック、シーケンシャル機能チャート、機能ブロック図を使用したり、ソフトウェアプログラミング言語や設計パラダイムを使用したりするなど、所望のソフトウェアフォーマットで実施されてもよい。同様に、コントロールルーチンは、例えば１つ以上のＥＰＲＯＭ、ＥＥＰＲＯＭ、特定用途向け集積回路（ＡＳＩＣ）、または他のハードウェアやファームウェア要素にハードコード化されてもよい。さらに、コントロールルーチンは、グラフィカル設計ツールや、他のタイプのソフトウェア／ハードウェア／ファームウェアプログラミングまたは設計ツールを含む任意の設計ツールを使用して設計されてもよい。従って、コントローラ１１は、コントロール戦略やコントロールルーチンを所望の方法で実施するように構成されてもよい。

一部の実施形態では、コントローラ１１は、通常機能ブロックと称されるものを使用してコントロール戦略を実施し、この場合各機能ブロックはコントロールルーチン全体のオブジェクトか他の部分（例えば、サブルーチン）であり、プロセスコントロールシステム１０内のプロセスコントロールループを実施するために（リンクと呼ばれる通信を介する）他の機能ブロックと関連して動作する。機能ブロックは通常、送信機、センサーまたは他のプロセスパラメータ測定デバイスと関連するような入力機能や、ＰＩＤ、ファジー理論などのコントロールを実行するコントロールルーチンと関連するようなコントロール機能や、プロセスコントロールシステム１０内の物理的機能を実行するための、バルブなどのデバイスの動作をコントロールする出力機能のうちの１つを実行する。当然、ハイブリッドおよび他のタイプの機能ブロックも存在する。機能ブロックはコントローラ１１に記憶されたり、これによって実行されたりしてもよく、これは通常、これらの機能ブロックが標準４−２０ｍａデバイス、およびＨＡＲＴデバイスなどのあるタイプのスマートフィールドデバイスに対して使用されたり、これらと関連していたりする場合であり、あるいはフィールドデバイス自体に記憶されたり、これによって実施されてもよく、これはＦｉｅｌｄｂｕｓデバイスを用いる場合である可能性がある。コントロールシステムに関する説明が機能ブロックコントロール戦略を使用して本明細書で提供されているのに対して、開示される技術およびシステムもまた、ラダーロジックやシーケンシャル機能チャートなどの従来技術を使用したり、所望のプログラミング言語やパラダイムを使用したりして実施または設計されてもよい。

図１の分解ブロック３０によって図示されるように、コントローラ１１は、ルーチン３２および３４と示されるような多数の単ループコントロールルーチンを含んでもよく、また所望なら、コントロールループ３６と示されるような１つ以上の拡張コントロールループを実施してもよい。このような各ループは通常コントロールモジュールと称される。単ループコントロールルーチン３２および３４は、適切なアナログ入力（ＡＩ）およびアナログ出力（ＡＯ）の機能ブロックにそれぞれ接続された単入力／単出力ファジー理論コントロールブロックおよび単入力／単出力ＰＩＤコントロールブロックを使用して単ループコントロールを実行するものとして示されており、これは、温度および圧力送信機などの測定デバイス、あるいはプロセスコントロールシステム１０内の他のデバイスを有する、バルブなどのプロセスコントロールデバイスと関連していることもある。拡張コントロールブロック３８の入力および出力は、他のタイプの入力を受信し、かつ他のタイプのコントロール出力を提供するように所望の機能ブロックやコントロール要素に接続されてもよいが、拡張コントロールループ３６は、１つ以上のＡＩ機能ブロックに通信可能に接続された入力と、１つ以上のＡＯ機能ブロックに通信可能に接続された出力とを有する拡張コントロールブロック３８を含むものとして示されている。拡張コントロールブロック３８は任意のタイプのモデル予測コントロール（ＭＰＣ）ブロック、ニューラルネットワークモデリングまたはコントロールブロック、多変数ファジー理論コントロールブロック、リアルタイム最適化ブロックなどであってもよい。拡張コントロールブロック３８を含む図１に示された機能ブロックはコントローラ１１によって実行可能であり、あるいはまた、ワークステーション１３やフィールドデバイス１９乃至２２のうちの１つなどの他の処理デバイスに配置され、かつこれによって実行可能である点が理解されるであろう。

次に図２を参照すると、コントローラ１１は、オンラインプロセスをコントロールするための対応するプロセスコントロールルーチンを定義および実施する任意の数のコントロールモジュール５０、５２および５４を有してもよい。従って、コントロールモジュール５０、５２および５４は、モジュール５６によってコントロールされた動作環境やモードと関連して、かつ一般的にはプロセスの通常のスケジュール済みコントロールと関連して実施されてもよい。上記のように、各コントロールモジュール５０、５２および５４は、コントロール機能ブロックを含む任意の数の機能ブロックを有してもよい。

開示される技術の一部の実施形態によると、パラメータ値および他の動作条件データは、コントロールモジュール５０、５２および５４からモデル識別ルーチンつまりモジュール６０のデータ収集機能５８に渡される。一般的に、パラメータ値および他の動作条件データは、コントロールモジュール５０、５２および５４およびこの機能ブロックの実行時に使用可能にされる（あるいは他の方法で通信される）。このような実行はスケジュール済みプロセスコントロールアクティビティ時にはかなり連続的であるため、パラメータ値および動作条件データの通信もまた連続的な場合がある。

機能ブロックのように、データ収集機能５８は（複数の）オブジェクト（またはオブジェクトエンティティ）としてオブジェクト指向的に実施される場合があるが、この必要はない。この構造に関わらず、データ収集機能５８は、データ取扱い手順を含む、データ収集において実施される手順を定義する１つ以上のルーチンを含むことがある。従って、データ収集機能５８のルーチンは、例えば１つ以上のレジスタ６２や他のメモリにおける、収集されたデータの記憶を調整、サポートまたは実施することがある。データ収集機能５８によって実行された手順は、後述するように、コントロールモジュール５０、５２および５４からいつデータを収集するかを判断するステップを含んでもよい。

より一般的には、データ収集機能５８は、パラメータおよび他の動作条件データの自動収集、採集、受信または他の取扱いをサポートするための１つ以上のルーチンを含むことがある。パラメータおよびデータの自動収集や他の取扱いがデータ収集機能５８によって実施される限り、モジュール５６と、コントロールモジュール５０、５２および５４と、これらのコントロールブロックとに対する計算要件は少ない。コントロール機能ブロックからのモデル識別手順のこのような分離の結果として、機能ブロックメモリおよび実行要件は、モデル識別が有効でも無効でも同じである。さらに、適合（つまり、適合コントロール）をサポートするためにコントロールブロックに付加されたパラメータおよび関連メモリ要件数は最小化される。

モジュール５６および６０の分離によっても、一部の実施形態はモデル識別モジュール６０、ひいてはデータ収集機能５８を無効化するオプションを提供することができる。モデル識別の無効化は、例えば、コントローラ１１が計算や他の処理に対する十分なメモリや時間がないと判断される場合に有用であることがある。関連事項としては、適合コントロールを提供するための識別されたモデルの使用もまた、ループ、エリア、システムまたはコントロール単位で有効化または無効化されてもよい。

個別のモデル識別機能性はまた、プロセス入力変化の調整をサポートする。コントローラ内のモデル識別は１つのプロセスに集中されるため、このような調整が可能になる。例えば、セットポイント変更がなされない場合、モデル識別モジュール６０（または、他の要素やルーチン）はコントローラ出力の変化を自動注入してもよい。これらの変化は、プロセス動作に対する衝撃を最小化するように調整されてもよい。従って、これらの変化は経時的に分散されることがある。

個別モデル識別または、モデル識別用のデータ処理がコントローラ１１のフリータイムまたはダウンタイム、あるいはコントローラ１１によって適切と見られる時に実行されてもよいことを意味している。結果として、モデル識別処理の実施は、例えばモジュール５６によって提供されるスケジュール済みコントロール機能性への悪影響を回避する。結果として、一部の実施形態では、モデル識別モジュール６０はバックグラウンドにあるコントローラ１１によって実施されてもよいのに対して、プロセスはオンラインであり、また、コントローラ１１の他のモジュールやコンポーネントによって行われるスケジュール済みコントロールおよびアクティビティ時には戦略的に好都合な時間である。

代替実施形態では、モデル識別機能性はコントロール機能ブロック自体に一体化されてもよい。

一部の実施形態では、パラメータおよび他のデータは、コントロールブロックが実行する場合は常に自動的に、コントロールモジュール５０、５２および５４からデータ収集機能５８に渡される。この意味で、データ収集モジュール５８は、プロセスの動作中常にデータ収集手順をサポートするために連続的に実施されてもよい。コントロールの実行がスケジューリングされていない期間、データ収集機能５８は、プロセスモデルが生成（例えば、作成または識別）されるべきか否かを判断するために収集されたデータを検証することがある。代替実施形態では、コントローラ１１は、周期的または何らかのスケジューリング方法で、収集されたデータを検証または他の方法で処理することがある。当然、さらなる代替実施形態では、データ収集機能５８は、例えば計算デマンドを最小化するために、または他の所望の理由でコントローラ１１によって、あるいはこの一部として実施されないこともある。このような処理がコントローラ１１に埋め込まれていない場合がある例に関するさらなる詳細について、開示される技術が既存のプロセスコントロールシステム上に層化（または他の方法でこれと一体化）される実施形態と関連して以下に説明する。

データ収集機能５８によって収集されたデータは一般的に、コントローラ１１（つまり、より一般的にはプロセスコントロールシステム１０）によって実施される特定のコントロールループのプロセス入力および出力や動作セットポイントの値を含むことがある。これらのパラメータの各々について、トリガイベント前に開始し、かつ常態に達するまで続く期間、値は収集および記憶される。トリガイベントが、例えばデータ収集機能５８による、プロセス入力やセットポイントの変化の検出を伴う場合がある。

トリガイベントを構成するものがコントロールループの動作モードに左右される場合もある。コントロールループが動作の「自動」モードにある場合、ループは、オペレータ固有のセットポイントにプロセス出力（つまり、ループのコントロール済みパラメータ）を維持するためにコントローラ出力（つまり、操作済みプロセス入力）を継続的に調整している。従って、自動モードでは、セットポイントの変化は、プロセス入力および出力の変化を分析し、ひいてはモデルを展開するようにトリガを構成することになる。オペレータがセットポイントを全く（またはほとんど）変更せず、かつループが自動モードのままである場合、コントローラ出力に小さな変化が注入されることがあり、モデルを作成するトリガが存在する。

ループが「手動」モードにある場合、コントローラ出力はオペレータによって設定される、つまりコントロールアルゴリズムは出力を調整していない。従って、手動モードでは、オペレータによって導入された出力の変化は、プロセス入力および出力を分析してモデルを取得するトリガを構成する。

３つの上記トリガイベントは、フィードバックモデルの展開に使用されることがある。フィードフォワードモデル識別について、トリガイベントはフィードフォワード入力値の変化であってもよい。

トリガイベントが検出されると、モジュール５６および５８は、データ収集をサポートするために所望の方法で通信する。一部の実施形態では、データ収集はモジュール５６によって容易にされ、これはまた、トリガイベントの検出を示すこともある。より具体的には、コントロールモジュール５０、５２および５４によって実施されたコントロールループはデータに連続的にアクセスしたり、他の方法でデータを使用可能にしたりしてもよい。結果として、トリガイベント前の短時間に収集されたデータもまた、プロセスモデルを判断するために分析されることがある。例えば、データが収集されるＰＩＤコントロールループは、ブロック実行（例えば、ＰＶ）、ブロック出力値（例えば、ＯＵＴ）、フィードフォワードコントロール入力値（例えば、ＦＦ＿ＶＡＬ）、セットポイント、および動作のループモードを示す１つ以上のパラメータで使用されるプロセス変数の現在のデータ値にアクセスしてもよい。データ収集機能５８はパラメータや他のデータ値の選択を容易にする場合がある。代替的または付加的に、モデル識別モジュール６０は、いずれのパラメータが収集されるべきかを判断する（複数の）構成リストブロック６４を含むことがある。そのために、構成リストブロック６４は、リストデータに対するメモリや他の記憶機構を含んでもよい。モデルが生成されるべきコントロールブロックやモジュールのリストや識別は識別されたパラメータに伴って記憶されてもよい。

トリガイベントと関連するデータ収集に続くポイントでは、モデル識別モジュール６０はモデル識別アルゴリズムつまり計算ルーチン６６を実施する場合がある。モデル計算ルーチン６６はまた、単に計算を実行することに加えて、計算されたモデルを分析してもよい。このような分析は、とりわけモデルの品質を判断するためのプロセスおよび／またはコントロール診断を伴うことがある。そして計算されたモデルは、コントロールループごとに（複数の）最終識別モデルを保持する記憶装置や他のブロック６８に渡されてもよい。コントロールループが、例えばフィードバックおよびフィードフォワードコントロールの両方をサポートするために記憶された２つのモデルを有する場合がある。図２に示されるように、計算されたモデルは後に、ルーチン６６のモデル診断によって判断されるようなモデルの品質に応じてブロック６８に渡される。

モデルの品質もまた、モデルがコントロールモジュール５０、５２および５４のコントロール機能ブロックに渡されるか否かを決定することがある。図２の例示的実施形態では、コントロールモジュール５０、５２および５４の各々は、適合コントロールを有する少なくとも１つのコントロールループを内蔵しており、従って、示されたようにモデル識別ルーチン６０からプロセスモデルを受信する。しかしながら、開示される技術によって計算および他の方法で識別されたモデルは、ブロック６６によって判断された上記モデル品質に基づいて、あるいは、場合によっては新たなモデルを受信するコントロール機能ブロックの動作状態に基づいて処理および提供されることがある。

次に図３を参照すると、ワークステーション１３のうちの１つのユーザは、ワークステーション１３上で実施されるチューニングや他のアプリケーション７０によって提供されるリアルタイムまたは履歴データを選択することによって、プロセスモデルの作成を開始してもよい。このような、ユーザが開始したプロセスモデル作成は、図２と関連して説明される処理に付加されてもよい。事実、図３に示された例示的実施形態では、チューニングアプリケーション７０によって作成されたモデルが渡されるコントローラ１１はまた、モデル識別ルーチン６０およびその構成要素パーツ、つまりデータ収集機能５８およびモデル計算ルーチン６６などを含む。

プロセスモデルを作成するのに使用されるパラメータ値および他の動作条件データのソースとは別に、ワークステーション１３は、プロセスモデルの作成に対して同一または類似のステップを実施することがある。例えば、ワークステーション１３は、コントローラ１１のブロック６６に類似のモデル計算および診断モジュールつまりブロック７２を含んでもよい。モデル計算ブロック７２はこれに応じて、示されるように、コントローラ１１および記憶ブロック６８にブロックを渡す前に、またはこれと関連して作成されたブロックの品質および態様を判断してもよい。

一部の実施形態では、ワークステーション１３は、類似の機能性を提供する付加的または代替的アプリケーションを有してもよい。ある場合には、他のアプリケーションが、開示される技術によって識別されたプロセスモデルの分析および／または検査をサポートする１つ以上のディスプレイインタフェースを提供することがある。このアプリケーションに関するさらなる情報は以下に説明される。しかしながら、付加的プロセスモデルの生成に関連して、これらのワークステーションアプリケーションは、モデル作成で使用するためのプロセスデータを選択する機会を提供するトレンドウィンドウやディスプレイインタフェースを生成してもよい。これらのトレンドウィンドウやインタフェースを使用して、ユーザはタイムウィンドウを含むデータを選択してもよい。これらの場合、常態までの時間はそれに応じて、ユーザによって選択されたタイムウィンドウによって判断されてもよい。代替実施形態は、タイムウィンドウを手動または自動的に選択するための機構を提供することがある。

開示される技術の実践は、プロセスコントロールシステム１０のコントローラ１１またはワークステーション１３のいずれかに配置されるモデル識別ルーチンに制限されない。より一般的には、本明細書で説明されるモデル識別手順は、個々にまたは分散的に、ここから基本パラメータやデータが収集されるコントロールループとの調整および／または通信の度合いを変更する際に他のデバイスやシステムで実施されることがある。例えば、モデル識別手順は遠隔的に、かつ／またはＯＰＣや他のインタフェースを介してプロセスコントロールシステム上に層化されたシステムによって実施される場合もある。

上記のように、開示される技術の実践は、適合コントロールルーチンを実施するシステムに制限されない。しかしながら、開示される技術によるプロセスモデルの識別は、所望ならば、このようなルーチンをサポートするために利用されてもよい。

図４に示されるように、開示される技術と併用するための適合コントロール機能ブロック７４は、上記のように識別された所定数（例えば、５個）のプロセスモデルを保存または記憶するための１つ以上のメモリや他の記憶機構７６を含んでもよい。動作において、メモリ７６に記憶されたプロセスモデルのうちの１つは次いで、１つ以上のパラメータに応答する論理ブロック７８によって使用するために選択されてもよい。図４の例示的実施形態では、ブロック７８は、入力８０を介して提供された、選択された、または他の方法で判断されたプロセス状態パラメータに基づいてプロセスモデルを選択する。２個のパラメータ８２および８４もまた判断について左右されることがあり、変化する条件に動作状態を適合させるフィードバックおよび／またはフィードフォワードルールや設定に相当することがある。

機能ブロック７４のプロセスモデルは動作領域（例えば、図示されるように領域１、領域２など）と関連付けられている場合があるが、この必要はない。プロセスモデルはまた、機能ブロックのコントロールスキームに従って対で識別されることがある。この例示的場合において、各領域は、フィードバックおよびフィードフォワード処理の両方のサポートにおける１対のプロセスモデルを決定する。領域の選択の際、この１対のフィードバックおよびフィードフォワードモデルは、フィードバックおよびフィードフォワードチューニングパラメータをそれぞれ計算するためにブロック７８によって利用されてもよい。図４に示された例示的場合において、フィードフォワードチューニングパラメータは、例えば、これもまた無駄時間およびリード／ラグ動的補償のフィードフォワードコントロール入力値（例えば、ＦＦ＿ＶＡＬ）に応答して、動的補償ブロック８８に提供される。フィードバックチューニングパラメータに伴う動的補償の結果は、機能ブロックのコントロールアルゴリズムの実施を担うブロックつまりルーチン８８に渡されてもよい。この場合、フィードバックおよびフィードフォワードパラメータはＰＩＤおよびファジー理論アルゴリズムを修正するが、任意のコントロールスキームやコントロールスキームの組み合わせが利用されてもよい。

機能ブロック７４はまた、コントロールループチューニングのオンデマンド修正をサポートするためのブロックつまりルーチン９０を含む。このために、ブロック９０は、プロセスコントロールシステム１０のコントローラ１１、ワークステーション１３または他の要素、あるいはこれと関連したデバイスを介して入力されたユーザコマンドに応答することがある。一般的に、ループに対して自動的に識別されたモデルは、ループチューニングを設定するための選択されたチューニングルールとオンデマンドで併用されてもよい。モデルが事前に識別されていない場合、ユーザコマンドは、コントローラ出力の変化を注入するためにリレー振動や他の技術を開始してもよい。そして、コントローラ出力の変化へのプロセス応答から展開された、得られるプロセスモデルは、ループチューニングを設定したり、チューニング推奨を提供したりするために選択されたチューニングルールと併用されることがある。

ブロック９０を介して、またはトリガイベントの結果（例えば、セットポイントや他のパラメータ値の変化）として生成されたプロセスモデルは、コントローラ１１や機能ブロック７４にダウンロードされる前に、まず閲覧用に保持される場合がある。例えば、このようなモデルは、ユーザインタフェースを介する分析が実施の承認を提供するまで、「未承認モデル」として分類されることがある。一部の実施形態では、このような承認は、コントローラ１１やワークステーション１３における診断などの機能性を介して代替的または付加的に、自動的に提供されることがある。

図５は、多数の異なる動作領域もまたサポートされている適合ＭＰＣコントロールブロック９２と関連した適合ブロックフレームワークを示している。これに関連して、モデル識別ルーチン６０によって識別された複数のプロセスモデルが図示されているように（図４のメモリ７６に類似した）メモリつまり記憶装置９４にさらに渡されてもよいが、モデルパラメータは、機能ブロック９２での実施前にＭＰＣコントローラ生成ルーチン９６によって処理されてもよい。より具体的には、ルーチン９６は、識別されたモデルに基づいてメモリ９８に記憶するために、対応するＭＰＣコントローラを生成することがある。論理ブロック１００は次いで、図示されているように、状態パラメータ、および入力やメモリ１０２、１０４および１０６を介して提供された他のパラメータの変化に基づいてＭＰＣコントローラを生成するのに使用されるモデルを選択したり、これらを切り換えたりしてもよい。

選択されたプロセスモデルと関連したＭＰＣコントローラは次いで、オンラインプロセスで実施するためにＭＰＣコントローラブロック１０８に提供されることがある。ＭＰＣコントローラブロック１０８は、選択されたＭＰＣコントローラの自動オンデマンドテストをサポートすることがあり、これは、所望ならば、外乱入力１１０の導入や他の方法によって開始されてもよい。

図４および５に示される例示的適合コントロール機能ブロック（ならびに、開示される技術と併用するための他のブロック）は一般的に３つの動作モード：学習モード、スケジュールモードおよび適合モードをサポートしている。学習モードにおいて、プロセスモデルが収集されることがあるが、ループチューニングを判断するためには自動的に使用されない。スケジュールモードにおいて、新たなプロセスモデルが収集されることがあり、承認されたこれらのモデルは、ループチューニングパラメータを判断するために自動的に使用されることになる。適合ＭＰＣブロックの場合、このような承認および適用されたモデルは次いで、コントローラが現在の動作領域と自動的に切り換わるため、現在の動作領域に従ってコントロール生成において使用されることになる。適合モードでは、プロセスモデルが収集され、自動的に承認され、ループチューニングパラメータを判断するために自動的に使用される。機能ブロックごとのデフォルト設定は学習モードである場合があるのに対して、例えばワークステーション１３上で実施されるアプリケーションの１つを介して提供されるディスプレイインタフェースは、所望ならば、設定を変更する機会を提供することがある。

次に図６を参照すると、ワークステーション１３によって実施される１つ以上のアプリケーションは、開示される技術によって識別されたコントロールループおよびプロセスモデルに対する性能監視、分析、管理および関連機能性を提供する。例えば、性能監視機能は、識別されたプロセスモデルを示すデータが後続の使用や分析用に入力されるプロセスモデル履歴の生成を含むことがある。プロセスモデル履歴の生成および使用に関するさらなる詳細を以下に説明する。あるレベルにおいて、履歴データは、開示される技術によって識別された各プロセスモデルを完全に定義するプロセスモデルパラメータ（例えば、無駄時間、時間定数および利得）を特定してもよい。この履歴データを利用して、コントロールループ、そのチューニング、コントロールスキーム（例えば、適合または非適合）などに関する多数の分析がなされてもよい。

一部の実施形態では、プロセスモデル履歴の一態様は、識別されたプロセスモデルのイベント記録の生成を目的としている。より具体的には、プロセスモデルが、コントローラ１１において自動的に（図２）あるいはリアルタイムまたは履歴データからオンデマンドで（図３）識別される場合は常に、モデル識別ルーチン６０はイベント記録つまり追跡モジュール１１２にアラート（または他のメッセージ）を送信することがある。イベント記録モジュール１１２は、特定のコントロールループ、デバイス、プラント領域などとモデルの関連付けを容易にするための任意の他のデータを伴って、モデル識別の時間および日付を特定するデータを生成することによって、アラートに応答する。図６に示された例示的実施形態では、イベントごとに記憶されたデータは、ノードまたはコントロールループ、日付／時間スタンプ、（例えば、無駄時間、時間定数および利得などのパラメータを識別することによる）モデルタイプ、コントロールループタイプ（例えば、機能ブロック）、プラント領域番号、チューニングルール、およびコントロール性能の診断表示と関連したデバイスのタグ名を含む。外部（または他の）データは、例えば１つ以上の要素をデータセットに追加することがあるアプリケーション１１６による処理の後に、プロセスモデル履歴の一部としてデータベース１１４に記憶されてもよい。アプリケーション１１６は、各コントロールループのチューニングの監視および／または管理を目的とする１つ以上のルーチンに相当してもよい。

データベース１１４は、システム１０内の複数のコントローラ１１に常駐し、かつある特定のタイプのコントローラとの併用に制限される必要のないコントロールループに対するこのような履歴データを記憶してもよい。例えば、データベース１１４は第三者コントローラに対するこのようなデータを記憶してもよい。

より一般的には、図７の例示的実施形態に示されるように、開示されるシステム、方法および技術の実施は、レガシーまたは第三者プロセスコントロールシステムに適用されることがある。言い換えると、開示されるシステムおよび技術は、レガシーや他のプロセスコントロールシステム「に優先して」実施されることがある。

これらの場合（および他の代替実施形態）において、ワークステーション１３は一般的に、コントローラ１１で実施される他の上記モデル識別機能性を含む。例えば、ワークステーション１３は、データ収集機能１２０と、構成リストモジュール１２２と、モデル計算ルーチン１２４と、コントロールループごとに（複数の）最終識別モデルを記憶するメモリ１２６とを有するモデル識別モジュール１１８を含んでもよい。上記コントローラ１１のモデル識別モジュール６０の要素に相当するこれらの要素に加えて、ワークステーション１３はまた、プロセスモデルが識別されているコントロールシステムの仮想コントローラ１２８を維持してもよい。仮想コントローラ１２８は、例えばそれぞれのパラメータの識別に伴った各コントロールループの現在の構成を反映するモジュールを含み、かつ記憶してもよい。つまり、開示される技術によって生成されるモデルおよび診断情報は、そのノードに対して自動的に作成されたモジュールに保存される。このように、仮想コントローラ１２８は、コントローラ１１で実施されるループと関連して実行されるのと全く同様に、チューニングや診断などによって情報を呈示するために利用されることがある。コントロールシステムの命名規則がワークステーション１３のと異なる場合、パラメータを関連付ける定義は、ワークステーション１３のインタフェース構成ブロック１３４や他の要素を介してなされてもよい。

開示される技術の広範な用途をサポートするために、ワークステーション１３は、ループの動的パラメータにアクセスするようにブロック１３４を介して構成されたＯＰＣ（オープンプロセスコントロール）や他のクライアントインタフェース１３２を含んでもよい。一般的に、ワークステーション１３とレガシーまたは第三者コントロールシステム間の通信リンクは、このＯＰＣサーバー１３６と、また場合によってはモデル識別プロセスに関する１つ以上のコントローラ１３８の識別などの他の通信設定とを識別することによって確立されてもよい。多数の（例えば、不必要な）通信ポートを開くことを回避するために、このようなＯＰＣ接続はトネラー（ｔｕｎｎｅｌｅｒ）ソフトウェアを使用してなされることがある。

開示される技術の実施をコントロールおよび管理するために（レガシーまたは標準一体型観点のいずれかにおいて）ワークステーション１３によって提供されるアプリケーションに関するさらなる詳細を次に提供する。アプリケーションは一般的に、上記のように、プロセスモデルの識別をサポートし、また識別されたモデルの使用と関連する機能性を提供する。上記のように、プロセスモデルは、適合コントロールスキームと関連した使用のためにのみ生成される必要はない。開示される技術に従ったプロセスモデルの識別は、コントロールルーチンが適合コントロールルーチンであるか否かに関わらず実施される。適合および非適合両方の全コントロールループのプロセスモデルの識別は一般的に、プロセス、プロセスコントロールシステムおよびこれらの特定の要素の多数の異なる分析を実行する能力を提供する。つまり、開示されるシステムは、ダイアログボックス、ウィンドウ、フェースプレート、またはノード（またはループ）ごとにモデル識別を無効化するディスプレイインタフェースを介するオプションを提供する場合がある。ディスプレイインタフェースは、ワークステーション１３上で実行するアプリケーションの実施によって生成される多数のディスプレイインタフェースのうちの１つであってもよい。このようなディスプレイインタフェースの例は図９乃至１６に提供されている。

再度図１を参照すると、一般的に、ワークステーション１３は、プロセスプラント１０内に接続されたデバイスやユニットなどに関する機能性を閲覧および提供するために認証されたユーザ（例えば、構成エンジニア、オペレータなど）によってアクセス可能な一連のオペレータインタフェースアプリケーションおよび他のデータ構造１４０を（個々に、分散的に、または他の様式のいずれかで）含んでいる。一連のオペレータインタフェースアプリケーション１４０はワークステーション１３のメモリ１４２に記憶され、一連のアプリケーション１４０内のアプリケーションやエンティティの各々は、各ワークステーション１３と関連した（複数の）それぞれのプロセッサ１４４上で実行されるように適合される。一連のアプリケーション１４０全体がワークステーション１３に記憶されるものとして図示されているのに対して、これらのアプリケーションや他のエンティティの一部は、システム１０内の、あるいはこれと関連または連通している他のワークステーションやコンピュータデバイスにおいて記憶および実行されてもよい。さらにまた、一連のアプリケーション１４０は、ワークステーション１３、あるいは携帯デバイス、ラップトップ、他のワークステーション、プリンターなどを含む所望のディスプレイスクリーンやディスプレイデバイスと関連したディスプレイスクリーン１４６にディスプレイ出力を提供することがある。同様に、一連のアプリケーション１４０内のアプリケーションは２つ以上のコンピュータやマシーン上で分割および実行される場合があり、また相互に関連して動作するように構成されてもよい。

図８は、開示されるシステム、方法およびモデル識別技術の実施と関連して、より詳細に例示的ワークステーション１３を示している。具体的には、一連のアプリケーション１４０は、本明細書で説明されるように、コントロールシステム１０のモデルベース監視および管理の実施を目的とした多数のアプリケーション、ルーチン、モジュールおよび他の手順要素を含むことがある。アプリケーション、ルーチン、モジュールおよび要素は、ソフトウェア、ファームウェアおよびハードウェアの組み合わせによって実施されてもよく、また図８に示された例示的配列に制限されない。例えば、１つ以上のアプリケーションは所望の程度に一体化されてもよい。

アプリケーション一式は、モデルが上記技術によって識別されると、プロセスモデルデータ（例えば、パラメータ）の記録をサポートするためのヒストリアンアプリケーション１４８を含んでもよい。このために、ヒストリアンアプリケーション１４８は、ヒストリアンデータベース１２や他のメモリや記憶機構と通信してもよい。上記のように、プロセスモデルデータは、プロセスモデルの識別（または、これに続くデータの収集）を記録するデータと関連して記憶されてもよい。ヒストリアンアプリケーション１４８はまた、選択されたモデルパラメータの合計、平均および他の値の計算などの分析機能性を提供してもよい。ヒストリアンアプリケーション１４８は、１つ以上のディスプレイインタフェースを介して、このような計算値ならびに基本記憶データの閲覧を容易にすることができる。

第三者インタフェースアプリケーション１５０は、図７と関連して説明されているように、第三者またはレガシープロセスコントロールシステムとの通信リンクをサポートおよび維持するために提供されてもよい。このために、アプリケーション１５０は、通信リンクの構成を容易にし、仮想コントローラ１２８を維持および利用し、また他の方法でインタフェースをサポートするために多数のディスプレイインタフェースを生成してもよい。

さらなるディスプレイインタフェースが、コントローラ１１との通信をサポートする目的のアプリケーション１５２によって提供されてもよい。このような通信は、コントローラ１１において実行する適合コントロールルーチンの構成およびメンテナンスを伴い、または含むことがある。アプリケーション一式にわたる場合のように、ディスプレイインタフェースは、無制限ダイナモ、フェースプレート、詳細表示、ダイアログボックスおよびウィンドウを含む任意の形態をとってもよく、また異なる表示タイプでの表示に対して構成されてもよい。

アプリケーション一式は、チューニングと関連するプロセスモデル情報の使用のためのアプリケーション１５４を含んでもよい。上記モデル識別技術の結果として、チューニングアプリケーション１５４は、プラントの日常的変化や、オンデマンドチューニングテストからチューニングパラメータを自動的に計算することによってプロセスコントロール性能を改良することを目的としている。チューニング結果は、「開ループ」チューニング推奨および「閉ループ」適合コントロールの両方に対して使用可能である。

より具体的には、チューニングアプリケーション１５４は、開ループまたは閉ループ動作のいずれかにおける全コントロールループの連続チューニング計算の性能をサポートするために多数のディスプレイインタフェースを生成してもよい。チューニング計算は、ＰＩＤ、ファジー理論およびＭＰＣコントローラ上の標準および適合コントロールの両方をサポートし、従ってフィードバックおよびフィードフォワードコントロール双方のチューニング推奨を提供する。チューニングアプリケーション１５４はまた、リレー振動または他の手順のいずれかを使用して、上記のようにオンデマンドチューニングを提供することもある。

チューニングアプリケーション１５４はヒストリアンデータベース１２（または、所望なら他の場所）に記憶されたプロセスモデル履歴データへのアクセスを有し、従って、履歴プロセスモデルデータを使用して最適なチューニングを計算可能である。そのために、ディスプレイインタフェースは、履歴を容易に追跡して、このようなチューニング計算に適したデータを検索および選択するためのツールを提供または含んでもよい。チューニングアプリケーション１５４によって生成された（複数の）ディスプレイインタフェースのこの態様によってユーザは一般的に、モデルパラメータ（例えば、常態への時間、イベントトリガしきい値）を変更し、かつモデルを再識別し、あるいは、自動モデル識別について事前に有効化されていなかったループのモデルを識別することができる。

チューニングアプリケーションはまた、チューニング計算結果の履歴の分析をサポートするためのインタフェースを提供してもよい。この能力は、適合コントロール構成の分析および適合コントロール構成の改良を容易にすることがある。

上記のように、チューニングアプリケーション１５４は、プロセスへの手動変更（つまり、コントローラ出力への自動注入）がほとんどない場合にコントローラチューニングを識別する助けとなるコントロール「摂動」の導入をサポートするためのインタフェースを提供してもよい。良好なチューニングが計算されると摂動を無効化するオプションがインタフェースを介して提供されることがある。複数のコントロールループが摂動されると、プロセス外乱を分散および最小化するために移動が同期されることがある。

チューニングアプリケーション１５４は、計算結果がこれに応じて識別されるように、プロセス状態および他のステータス表示に応答する場合がある。このように、開示されるシステムは、不良な状態または不良なプロセスデータによって計算された情報の使用を回避する。そのために、モデル関連計算は、結果が良好か、不良か、または使用不可能かを、必要に応じた説明によって示すことができる。

チューニングアプリケーション１５４はまた、とりわけチューニング推奨情報と、チューニング変更および適合コントロールチューニング分析を証明するユーザログとを搬送するためのサマリーレポートを生成してもよい。

（単独、または他のアプリケーションと関連して）チューニングアプリケーション１５４によって生成されたディスプレイインタフェースに関するさらなる詳細が図１２乃至１６と関連して呈示され、これは一般的に、上記機能性を容易にするためにユーザに提供されるプロセスモデルおよびコントロールループのビューを示している。

引き続き図８を参照すると、アプリケーション１５６は一般的に、開示される技術によって識別されたプロセスモデルを利用する自動コントロール性能監視を目的としている。アプリケーション１５６はより具体的には、（ｉ）コントロール改良の機会の識別と、（ｉｉ）コントロール問題の原因の分析および診断と、（ｉｉｉ）動作、コントロールおよびメンテナンス人員に関する重要な性能レポートの生成とを容易にしたり、自動的に実施したりすることによってプロセスコントロール性能を改良することを目的としている。このために、アプリケーション１５６はプロセスモデルに基づいてコントロール性能指数を生成してもよい。この「モデルベース」指数は、再チューニングを必要とするコントロールループを識別するための良好なベンチマークを提供する。新たな指数は、プロセス可変性、識別されたプロセスモデルおよび既存のコントローラチューニングなどの要因に基づいてコントロールを改良する機会を測定する。このような性能監視は、適用可能ならば、ユニット状態を考慮し、ループが不適切なユニット状態であったり、他のステータス表示（例えば、Ｆｉｅｌｄｂｕｓステータス）やＩ／Ｏ通信が不良であったりする場合に性能計算を排除する。バルブスティクション、バックラッシュおよび他のバルブ診断指数もまた、全バルブに対して提供されてもよい。

上記特徴および以下に説明される特徴は一般的に、開示される技術によって自動的に作成されるプロセスモデルを利用することによって実行されるコントロール性能の比較によって提供される。プロセスモデルの使用を介して、十分にチューニングされないコントロールループと、コントロール性能に影響を与えるプロセスの変化とが識別されてもよい。履歴値からのプロセスモデルの偏差は、コントロールループを潜在的なプロセス問題としてフラグするのに使用されてもよい。

再度、プロセスモデルを使用して、振動指数もまた、振動しているループを識別するためにアプリケーション１５６によって生成されてもよい。より具体的には、振動分析ツールは、同じ振動期間を有する他のループを識別することができ、また主要なループと相互作用してもよい。そしてこの情報は、プロセスの相互作用および可能な設計推奨を識別するために使用可能である。

アプリケーション１５６によって提供される診断情報は、不良なコントロール性能の想定される原因の指示を伴うことがある。例えば、診断は、不良なコントロール性能が、機器のエラー、バルブスティクションやバックラッシュ、プロセスの相互作用、あるいはコントローラチューニングによって引き起こされるか否かを示すことがある。

一般的に、コントロール性能監視情報は、多数のカスタマイズされたディスプレイインタフェースおよびレポートを含む所望の形態で提供されてもよい。履歴性能レポートは、コントロールループがユーザ固有の期間に実行される様子を表示するために提供されてもよい。このようなレポートのデフォルト期間は、最終時間、最終シフト（８時間）、最終日、最終週、最終月を含む。ユーザは、詳細なループ情報にアクセスするためにサマリーレポートから「ドリルダウンする」オプションを提供されることがある。レポートやインタフェースは、例えば、全プラントおよび個々のプロセスユニットの全重み付け性能と、現在の期間と前の期間を比較するトレンドおよび／またはテーブルと、対応する性能測定による最優先ループのリストとによって管理サマリーに対してカスタマイズされてもよい。メンテナンスレポートがコントロールループ性能指数を提示し、かつプラント動作への重要性に基づいて動作アイテムに優先順位をつけてもよい。他のレポートは、コントロール性能指数、標準偏差、振動指数、（使用可能ならば）プロセスモデル、自動かつ相互関連性、ヒストグラム、電力スペクトルなどのデータを含む統計を提供することがある。

アプリケーション１５６によって提供される情報に関するさらなる詳細は、図９乃至１２に示される例示的ディスプレイインタフェースによって提供される。

アプリケーション一式はまた、個別のコントロールループ分析アプリケーション１５８を含むことがある。一部の実施形態では、アプリケーション１５８は、アプリケーション１５６によって生成された（複数の）ディスプレイインタフェースによって使用可能にされる。いずれの場合も、アプリケーション１５８は、上記モデル識別技術と関連して収集された履歴またはリアルタイムデータの分析をサポートする。データは、未測定外乱および測定雑音からコントロールのばらつきを検証することを容易にするインタフェースを介して呈示されてもよい。例えば、アプリケーション１５４および１５６によって識別される問題はさらに、分析アプリケーション１５８を使用して診断するために検証されてもよい。そのために、これによって生成されたディスプレイインタフェースは、電力スペクトル、自動相関性およびヒストグラムデータを計算するためのオプションを提供してもよい。

アドバイザーアプリケーション１６０は一般的に、異常条件を検出するための診断や、チューニングやアルゴリズム修正を介してコントロールスキームを改良するための機会と関連して識別されたモデルを利用する機能性を提供可能である。アドバイザーアプリケーション１６０によって提供される情報は、ワークステーション１３によって生成されるフェースプレート、コントローラ１１、またはシステム１０と連通している他の要素を含む任意のタイプのディスプレイインタフェースで提供されてもよい。具体例においては、ディスプレイインタフェースは、「チューニングチェック」などの新たなアドバイスメッセージの表示を示すフラグを有する場合がある。

より一般的には、アドバイザーアプリケーション１６０は、一連のアプリケーションのうちの任意の１つによって実行される分析や診断の結果として生成される推奨を提供することがある。さらにまた、推奨は、アドバイザーアプリケーションによって生成されるディスプレイインタフェースによって提供される必要はなく、むしろ、一連のアプリケーションのうちのいずれか１つ以上に表示するために送られる場合がある。従って、「新チューニング使用可能」、「プロセス検証−プロセスの重要な変化が検出済み」、「バルブチェック−デッド帯域／ヒステリシス大」、「チューニングチェック−ループ不安定」および「ＭＰＣ／適合を使用してコントロールは改良可能」などの推奨およびメッセージは一般的に、ワークステーション１３や、プロセスコントロールシステム１０と連通している他のデバイスによって提供可能である。メッセージや推奨の表示に加えて、基本条件に関する詳細は、コントロールループの履歴や他のパラメータとして記憶されることがある。そしてコントロールループに対して記憶されたデータの後続のアクセスや使用によって、アドバイスや他の一連のアプリケーションのユーザに詳細や関連メッセージが表示される。

これもまた開示される技術の実施をサポートする他のアプリケーションは、プロセスコントロールシステム１０内のナビゲーションを容易にするコントロールスタジオアプリケーション１６２と、上記レポートの生成のためのレポート生成アプリケーション１６４とを含む。最後に、１つ以上のメモリやデータベース１６６はまた、アプリケーション一式の一部として提供されてもよい。

図９は、プロセスモデル検査分析から生じる概観情報を呈示するための性能監視アプリケーション１５６（または、代替的に他のアプリケーションのうちのいずれか１つ以上）によって生成可能な例示的ディスプレイインタフェース１６８を示している。この具体例において、ディスプレイインタフェース１６８は、プロセスコントロールシステム１０全体におけるコントロールルーチンやモジュールの条件や、階層ツリーパネル１７０によって選択されるこのエリアを示す情報を呈示する。コントロール性能は、「不正確モード（Ｉｎｃｏｒｒｅｃｔ Ｍｏｄｅ）」、「制限コントロール（Ｌｉｍｉｔｅｄ Ｃｏｎｔｒｏｌ）」、「不特定入力（Ｕｎｃｅｒｔａｉｎ Ｉｎｐｕｔ）」および「可変性大（Ｌａｒｇｅ Ｖａｒｉａｂｉｌｉｔｙ）」を含むカテゴリを介してチャートパネル１７２において特定および要約されてもよい。コントロールモジュール、機能ブロックまたはルーチンのこれらのカテゴリのうちの１つへの割当てや分類は一般的に、開示される技術によって識別されたプロセスモデルによって可能にされ、またこれを使用して自動的に実施されてもよい。ディスプレイインタフェース１６８はまた、即時のメンテナンスを必要とし、アドバイスアラートを有し、または通信の不具合を経験する、不具合と思われるアセット数に関する統計的情報を呈示するためのアセットアラートチャートパネル１７４を含む。

図１０は、これもまた性能監視アプリケーション１５６によって生成可能な例示的ディスプレイインタフェース１７６を示している。ディスプレイインタフェース１７６はまた一般的にコントロール性能情報を呈示するが、詳細なレベルではない。本例において、性能情報は、階層ツリーパネルにおいて選択されたエリアにおけるコントロールループやモジュールごとに呈示される。特定のコントロールループに対して検出された各異常条件は、異常モード、制限コントロール、入力ステータス、高可変性または不活性関連デバイスと関連する問題を区別するテーブルに記されてもよい。優先度レベルはまた、異常条件を記述するレポートが生成されたか否かに関する指示に伴って表示されることがある。

図１１は、これもまた性能監視アプリケーション１５６によって生成可能な例示的ディスプレイインタフェース１７８を示している。ディスプレイインタフェース１７８は図１０のインタフェース１７６と類似しており、性能情報が呈示されるコントロールレベルが異なっている。この場合、モジュールやループはパネル１７０を介して選択され、性能情報はこの機能ブロックごとに呈示される。そして、特定のブロックの診断情報は、テーブルに表示されたブロック名を選択（例えば、右クリック）することによってアクセス可能である。

図１２は、チューニングアプリケーション１５４および性能監視アプリケーション１５６を含むアプリケーションのうちの１つ以上によって生成可能な例示的ディスプレイインタフェース１８０を示している。一般的に、ディスプレイインタフェース１８０は、選択されたコントロール要素（例えば、ＰＩＤ１）の診断計算の結果の検証を容易にする。計算によって導かれる統計の制限値はまた、所望ならば、比較およびユーザ修正のために表示される。制限を越えると、アラームが関連条件を示すことがある。より一般的には、ディスプレイインタフェース１８０に呈示される情報および基本計算は、コントロールループの安定性が、本明細書に開示されるプロセスモデル識別技術の結果として連続的に監視される様子を示している。

図１３は、自動プロセスモデル識別ならびにオンデマンドモデル識別のコントロールループのセットアップを容易にする例示的ディスプレイインタフェース１８２を示している。トリガイベントタイプ、トリガイベントレベル、パラメータ変化最大値などを特定するために多数のパネルがインタフェース１８２を介して提供される。このように、ディスプレイインタフェース１８２によってユーザは、ノードごとまたはループごとにプロセスモデル識別手順をカスタマイズすることができる。

図１４は、とりわけ必要とされる領域数を判断するために保存されたプロセスモデルをユーザが視覚化できる方法を示している。より具体的には、ディスプレイインタフェース１８４は、プロセスモデル履歴情報をリスト化するパネル１８６と、それぞれの水平線を介して認証されたモデル値と、およびドットを介して、履歴データベースに識別および記憶されているプロセスモデルのパラメータとを示すモデルグラフパネル１８８とを含む。上記のように、それぞれのモデルは多数の領域（例えば、５個）に認証されてもよく、またモデルパラメータの分散は領域の識別を容易にし、チューニング推奨を助長する。

図１５および１６は、それぞれファジー理論コントロールブロックおよびＭＰＣブロックと関連して最近識別されたモデルのプロセスモデル情報を示している。そのために、ディスプレイインタフェース１９０および１９２は、テスト、チューニング計算、コントローラパラメータ設定、チューニングシミュレーションおよびチューニング選択をサポートするための多数のパネル１９２、１９４、１９６および１９８を伴うプロセスモデルのそれぞれのグラフ表示を提供する。

用語「識別する」、「識別」およびこの派生語は、プロセスモデル全体、これを定義する１つ以上のパラメータ、あるいはこの定義特徴のいずれかの作成、生成、および、これに達する処理を含むプロセスモデルの使用と関連して広範囲な意味で本明細書では使用される。

上記アプリケーションのいずれかは、１つ以上の一体化アプリケーションのルーチン、モジュールまたは他のコンポーネントとして実施されてもよい。アプリケーション機能性の開示される配列は、図示を容易にするためにのみ提供されており、機能性がオペレータやユーザに提供されてもよい広範囲の方法を示しているのではない。さらにまた、上記アプリケーションは、所望ならば、ユーザプロファイル、コンテクストおよび他のパラメータに応じて形態を変更する際に提供されてもよい。例えば、ユーザタイプ（例えば、エンジニアリング）に対して生成されたディスプレイインタフェースビューは、異なるユーザタイプ（例えば、メンテナンス）に対して生成されたビューとは内容および方法が異なる場合がある。

実施される場合、本明細書で説明されたソフトウェアのいずれかは、コンピュータやプロセッサなどのＲＡＭやＲＯＭにおける、例えば磁気ディスクや、レーザーディスクや他の記憶媒体上のコンピュータ可読メモリに記憶されてもよい。同様に、このソフトウェアは、例えばコンピュータ可読ディスクや他の搬送可能なコンピュータ記憶機構上、あるいは電話線、インターネット、ワールドワイドウェブ、ローカルエリアネットワークやワイドエリアネットワークなどの通信チャネル上を含む既知または所望の配信方法を使用してユーザ、プロセスプラントあるいはオペレータワークステーションに配信されてもよい（この配信は、搬送可能な記憶媒体を介してこのようなソフトウェアを提供することと同一または互換性があるものとみられる）。さらにまた、このソフトウェアは、変調や暗号化なしで直接提供されてもよく、あるいは通信チャネル上を送信される前に、適切な変調搬送波および／または暗号化技術を使用して変調および／または暗号化されてもよい。

本発明は特定の例を参照して説明されてきたが、これは例示目的のためであり、本発明を制限するためのものではなく、変更、追加あるいは削除が本発明の主旨および範囲を逸脱することなく開示される実施形態に対してなされてもよいことが当業者にとって明らかであろう。

図１は、本開示の一態様に従った、１つ以上のコントロールルーチンによって構成されたコントローラを含むプロセスコントロールシステムの概略図である。 図２は、多数の機能ブロックと連通するモデル識別ルーチンを有する実施形態に従った図１のコントローラの概略図である。 図３は、コントローラが動向または他の履歴データを使用するモデル識別のワーステーションと連通している実施形態に従った図１のコントローラの概略図である。 図４は、適合コントロール機能ブロックが、記憶されているモデルおよび動作状態情報に従ってチューニングを修正する実施形態に従った、図１のコントローラの適合コントロール機能ブロックの概略図である。 図５は、ＭＰＣ機能ブロックがモデル識別のオンデマンドテストを実施する実施形態に従った、図１のコントローラの適合ＭＰＣ機能ブロックの概略図である。 図６は、識別されたモデルが履歴イベント情報と関連付けてデータベースに記憶されている実施形態に従った、図１のコントローラの概略図である。 図７は、ワークステーションが、ＯＰＣや他のインタフェースを介してコントローラと連通しているモデル識別ルーチンを実施する図１のプロセスコントロールシステムの代替実施形態の概略図である。 図８は、特にループおよびモデル分析と、診断と、チューニングと、ＭＰＣおよび適合コントロールとに対する関連機能性をコントロール性能監視および管理環境に提供する例示的アプリケーション一式をワークステーションが実施する、図１のプロセスコントロールシステムの一実施形態の概略図である。 図９は、コントロール性能概観情報を提供するための性能監視アプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１０は、選択されたシステム、エリアあるいは他のコントロールループグループに対してコントロールループ性能情報を提供するための性能監視アプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１１は、選択されたコントロールループに対して性能情報を提供するための性能監視アプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１２は、コントロールループ性能、適合モデル品質、およびコントロールループに関する他の診断パラメータを監視および管理するための診断または他の分析アプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１３は、コントロールループのモデル識別手順を構成、カスタマイズおよび管理するためのアプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１４は、状態パラメータ入力によって示される異なる動作条件について識別されたプロセスモデルを視覚化するための図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１５は、例えばファジー理論やＭＰＣコントロールスキームを実施するコントロール機能ブロックをチューニングするためのプロセスモデルの使用をサポートおよび管理するためのチューニングアプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。 図１６は、例えばファジー理論やＭＰＣコントロールスキームを実施するコントロール機能ブロックをチューニングするためのプロセスモデルの使用をサポートおよび管理するためのチューニングアプリケーションを有する図８のワークステーションの実施形態によって生成された例示的ディスプレイインタフェースの簡略図である。

Claims (16)

1. 複数のコントロールループを有するプロセスコントロールシステムをコントロールするための方法であって、
   前記複数のコントロールループそれぞれの動作をコントロールするために複数のコントロールルーチンを実施するステップであって、前記複数のコントロールルーチンが少なくとも１つの非適合コントロールルーチンを備えるステップと、
   前記複数のコントロールループの各コントロールループの動作と関連して動作条件データを収集するステップと、
   前記複数のコントロールループのコントロールループごとに収集された前記それぞれの動作条件データから前記複数のコントロールループのコントロールループごとにそれぞれのプロセスモデルを識別するステップと、を備える方法。
2. 前記複数のコントロールループのコントロールループごとのそれぞれのプロセスモデル履歴に、前記それぞれの識別されたプロセスモデルを示すデータ記憶するステップをさらに備える、請求項１に記載の方法。
3. 前記動作条件データを検証してその変化を検出するステップと、
   前記変化が検出された場合に前記プロセスモデル識別ステップをトリガするステップと、をさらに備える、請求項１に記載の方法。
4. 前記識別ステップが、ユーザコマンドに応答して、前記収集された動作条件データに基づいて前記プロセスモデルを計算するために実行される、請求項１に記載の方法。
5. 前記収集された動作条件データが、前記ユーザコマンドの結果として適用される注入パラメータ変化への応答を示す、請求項４に記載の方法。
6. 前記動作条件データが、前記複数のコントロールループの動作を介してコントロールされるプロセスのオンライン動作を示す、請求項１に記載の方法。
7. コントロールループ性能を評価するために、コントロールループごとに識別された前記それぞれのプロセスモデルを監視するステップをさらに備える、請求項１に記載の方法。
8. いずれのコントロールループが適合コントロールスキームを利用すべきかを判断するために、コントロールループごとに識別された前記それぞれのプロセスモデルを分析するステップをさらに備える、請求項１に記載の方法。
9. コントロール問題を診断するために、コントロールループごとに識別された前記それぞれのプロセスモデルを分析するステップをさらに備える、請求項１に記載の方法。
10. 複数のコントロールルーチンを有するプロセスコントロールシステムをコントロールするための方法であって、
    前記複数のコントロールルーチンの実施時に動作条件データを収集するステップと、
    プロセス変化と関連する前記複数のコントロールルーチンのうちの１つのコントロールルーチンと関連して前記プロセス変化を示すイベントを検出するステップと、
    前記プロセス変化と関連した前記コントロールルーチンのプロセスモデルを識別するステップと、
    前記プロセス変化と関連した前記コントロールルーチンのプロセスモデル履歴を作成する際に前記生成されたプロセスモデルを示すデータを記憶するステップと、を備える方法。
11. 前記イベントの検出時に前記識別ステップのデータを自動的に収集するステップをさらに備える、請求項１０に記載の方法。
12. 前記複数のコントロールルーチンのコントロールルーチンごとにそれぞれのプロセスモデルを識別するステップをさらに備える、請求項１０に記載の方法。
13. 前記複数のコントロールルーチンが、非適合コントロールスキームを実施するコントロールルーチンを備える、請求項１２に記載の方法。
14. コントロールルーチン性能を評価するために、コントロールルーチンごとに識別された前記それぞれのプロセスモデルを監視するステップをさらに備える、請求項１２に記載の方法。
15. いずれのコントロールルーチンが適合コントロールスキームを利用すべきかを判断するために、コントロールルーチンごとに識別された前記それぞれのプロセスモデルを分析するステップをさらに備える、請求項１２に記載の方法。
16. コントロール問題を診断するために、コントロールルーチンごとに識別された前記それぞれのプロセスモデルを分析するステップをさらに備える、請求項１２に記載の方法。

Images