JP4189527B2 - プロセス制御システムにおける故障管理方法とシステムおよびそのデバイス並びにそのプロセス制御システム - Google Patents

Description

【発明の属する技術分野】
本発明は一般的にプロセス制御システムに関し、より詳細にはプロセス制御システム中の故障情報を自動的に管理するために統合された装置階層を使用する技術に関する。
【従来の技術】
大量の医薬、化学薬品、飲料、塗料または他の何れかの製品を生産するために、バッチプロセス技術を使用するようなプロセス制御システムは、一般的に例えば弁位置設定器、スイッチ，センサ（温度、圧力および流量センサのような）等で良い一つ以上のフィールドデバイスに通信連絡的に連結された一つ以上の集中プロセスコントローラを含む。これらのフィールドデバイスは例えば弁、ポンプ、混合ユニット等のような制御装置と関連でき、プロセス制御システム内部の（弁の開閉，ポンプまたは混合ユニットの運転または停止等のような）物理的制御機能を実施でき、プロセスの操作の制御に使用するプロセス制御システム内部の測定値を取ることができ、またはプロセス制御システム内部の他の何れの望ましい機能をも実施できる。一般的に言えば、プロセスコントローラは、一つ以上のフィールドデバイスによって作られた測定値を表す信号および／またはフィールドデバイスに関する他の情報を受け、制御ルーチンを実行するためにこの情報を使用し、およびプロセス制御システムの操作を制御するために信号線路または母線を経由してフィールドデバイスに送られてくる制御信号を発生する。
更にプロセスコントローラは、一般的にイーサネット（登録商標）母線のようなデータハイウェイを経由して一つ以上のワークステーションまたは他のデバイスに連結される。これらの他のデバイスは、制御ルーチンへのユーザーインターフェースを提供すること、制御ルーチンの変更または更新を可能にすること、フィールドデバイスとインターフェースすること、履歴プロセス制御データを記憶すること、またはユーザーのアクセスを制限することなどの他のプロセス制御機能を提供するために、一つ以上のコントローラによって与えられる情報を使用する他の応用またはプログラムを運転する。或る大きなプロセス制御システムにおいて、遠方に位置された一つ以上のワークステーションは、インターネット接続、人工衛星方式またはセル方式通信リンク、（無線イーサネット（登録商標）接続に使用されるような）無線リンクのような別の通信網を経由してデータハイウェイと連結できる。
プロセス制御システムは、典型的にプロセス制御エラーやデバイスまたは装置の故障（例えば故障したセンサ、膠着した弁等）をシステムオペレータに報告する故障モニターロジックを含む。或るプロセス制御システムにおいて、プロセス制御エラー、デバイス故障または他の如何なる故障情報も例えばグラフィカル・ユーザー・インターフェースを経由してオペレータに表示できる。これらのプロセス制御システムにおいて、システムオペレータは臨界デバイスが故障したこと、または可変の或るプロセスが許容動作範囲の外に逸れたことを示すグラフィカル・ユーザー・インターフェース内部の記述を見ることができる。これらの表示された故障に応動して、システムオペレータはプロセスが継続することを停止するように介入することを選択でき、かつ適正な修正動作を取ることができるように故障を診断する更なるステップを取ることができる。バッチプロセスを実施しているプロセス制御システムの場合には、そのシステムが劣悪なおよび／または危険な生産バッチを生産することを防止するように、そのプロセスを停止することが必要となるであろう。
或る他のプロセス制御システムにおいて、より複合的な故障管理方式が、システムオペレータまたはユーザーによる手動モニターおよび介入を補い、または取り替えるために使用できる。例えば医薬を生産するプロセス制御システムにおいて、システム全体に分布されたセンサ、作動器、および他のデバイスは連続的にモニターでき、かつもしセンサまたは関係する制御パラメータの何れか一つが許容動作範囲を外れたならば、プロセス制御システムは自動的にそのプロセスを停止できる。プロセスの自動停止に応動して、システムオペレータは故障診断のステップを取ることができ、そしてもし故障が非臨界的であるかまたは許容最終製品の生産を他の面で損なうものでなければ、オペレータはシステムにプロセスの実施を再開できる。あるいは、もしオペレータがその故障が修理、較正または或る他の修正動作を必要とすると判断するならば、オペレータはバッチプロセスの実施再開の前に故障を修理するフィールド技術者または保全要員の派遣を要請できる。
プロセス制御システムによって典型的に使用される大量の入力、出力プロセス制御変数等により、プロセス制御システムの操作を制御するソフトウェアは、通常良く知られたオブジェクト指向プログラミング技術を使用して典型的に作り出されるソフトウェアオブジェクトを使用して行われる。これらのソフトウェアオブジェクトは、プロセス制御システムによって実施されるであろう高度の複合プロセス制御ルーチン、すなわちアルゴリズムの創造を単純化するプロセス制御システムの階層モデルを使用して開発できる。例えば、通常使用される一つの階層モデルは、ユニットモジュールと制御モジュールを使用する。ユニットモジュールまたはユニットは、典型的に例えば色々な動作をタンク内部で実施させる各種の入り口弁、出口弁、レベルセンサ、調合機等を持つ混合タンクのようなプロセス制御システム内部にある物理的装置の特別な部分を表す。一方制御モジュールは、一つ以上のユニットによって指向されるような低レベル調節制御機能、または動作を遂行するために具体化される制御ソフトウェア（すなわちサブルーチン、オブジェクト等）を表す。
不運なことに、プロセス制御システムについての上記階層モデルは複合プロセス制御アルゴリズムの開発を促進できる一方、この従来の階層モデルは典型的にユニットモジュールと制御モジュール間の如何なる実行時通信関係も確立しない。その結果、ユニットモジュールは、典型的にどの制御モジュールがそのユニットモジュールに従属的であるかについての知識を持たない。更にこの従来の階層モデルは、典型的に故障情報（すなわち装置故障、デバイス故障制御パラメータ誤差等）を従属制御モジュールから親ユニットモジュールへ自動的に伝達する如何なる機構も提供しない。また更にこの従来の階層モデルは、典型的にそれによってユニットモジュールが特定の時間（例えばそれらの制御モジュールが現在行われているプロセス制御アルゴリズムの部分を実施するために必要でない時）における一つ以上の制御モジュールからの特定のタイプの故障情報についての重要度を記録できるか、または逆に無視できる如何なる機構も提供しない。
上記の従来の階層モデルに基づくプロセス制御システムに見出されるユニットモジュールと制御モジュール間の実行時通信関係の欠如により、システム設計者はプロセス制御システム全体を通して分布される故障情報へのアクセスを持つ高レベル実施機能、またはユニットレベル機能内部の比較的複合した故障管理の使用を強いられるであろう。典型的には、これらの複合故障管理ルーチンはバッチ実行機能またはユニット手順内部に存在し、かつ典型的にプロセス制御システム全体を通して分布されている数百のデバイスによって与えられる膨大な量の故障情報を直接管理する。
更に、プロセス制御システムは、典型的には故障情報を自動的に制御モジュールからユニットモジュールへ伝達させないので、従来の故障管理技術は、モニターされている或るデバイスがその特定の時間に（または何時でも）行われているプロセス制御アルゴリズムによって必要とされるか否かに関わらず、そのプロセス制御システム全体を通して分布される数百のデバイスを典型的に連続してモニターする。例えば医薬を生産するプロセス制御システムは、多数の異なる医薬生産物を生産するために色々な組合せで使用できるセンサ、作動器等のような大量のデバイスを含むことができる。しかしながら特定のバッチプロセスを使用して生産できる如何なる特定の医薬生産物についても、利用できる総てのデバイスの内の一つの部分集合のみが必要とされるであろう（すなわち幾つかのデバイスは全く使用されないであろう）。如何なる場合においてもプロセス制御システム全体を通して分布された総てのデバイスを連続してモニターすることは、膨大な量の故障情報を発生する。その結果、この膨大な量の故障情報を処理し、かつ一つ以上の故障条件（例えばバッチプロセスを停止しかつシステムオペレータに故障について知らせること）に基づいて自動的に動作を取ることができる故障管理ロジックの開発は非常に複雑となり、かつたとえ中程度の複雑さのプロセス制御システムについても、行うためには時間の掛かるものとなる。
加えて、従来の故障管理技術はそのプロセスを停止することによって故障が発生したことを示す故障情報に応動し、そして通常故障の性質または苛酷度に無関係にシステムオペレータが適当な修正動作を取ることを待つ。典型的には、バッチプロセスはシステムオペレータが故障に至った条件が除去されたことを示し、かつシステムに再開操作を命令する時、再開できる。
こうして、現在そのプロセスによって必要でないか、または全く必要でないデバイスに関連する誤差が停止を引き起こしてしまうので、従来の故障管理技術はプロセスの不必要な停止に至るであろう。加えて、行われているプロセスによって使用されている一つ以上のデバイスが、プロセスの結果に対して臨界的でない、またはそれに悪影響を与えないであろう故障条件を顕示する時、不必要な停止が生じるであろう。例えば一対の余剰のセンサの一方の故障は、そのプロセス制御システムの不必要な停止に至るであろう。
【課題を解決するための手段】
階層故障管理技術は、プロセスの実行の間、故障情報が制御モジュールからユニットモジュールへ自動的に通過できるように、プロセス制御システム内部のユニットモジュールと制御モジュール間の実行時通信関係を確立する。より詳細には、ここに記述される階層故障管理技術は、ユニットモジュールに、プロセス制御アルゴリズムの現在のフェーズまたはステップを遂行するためにユニットモジュールによって必要とされる制御モジュールからの故障情報に重要度を記録させ、かつその故障情報を自動的に受信させおよび処理させ、並びにフェーズまたはステップを遂行するためにユニットモジュールによって現在必要とされない制御モジュールに関連する故障情報を無視させるように、ユニットモジュールと制御モジュール間の実行時通信関係を使用する。
加えて、ここに記述される階層故障管理技術は、故障情報を収集しかつそこから合成故障コードを発生する制御モジュールを使用する。これらの合成故障コードの各々は、例えばその機能を遂行するために制御モジュールによって使用される色々なセンサ、制御ループ、装置等の操作状態または故障の加重合計を表すことができる。これらの合成故障コードは、制御モジュール内部の、および／またはその機能を遂行するために制御モジュールによって使用されるデバイス内部の故障のタイプ、および集合的苛酷度を表すことができる。各制御モジュールは、その合成故障コードをその制御モジュールからの故障情報を現在要求しているユニットモジュールへ送ることができ、そのプロセスが進行できるか否か、何れのフィールド検査／修理が必要とされるであろうか否か等を迅速に判断するために、それによってユニットモジュールに合成故障コードを処理させる。この仕方でここに記述される階層故障管理技術は、プロセス制御システム内部のユニットモジュール、またはより高いレベルの実行機能（例えばバッチ実行のような）が、以前の故障管理技術の場合のようにプロセス制御システム全体を通して分布される総てのデバイス、装置等から故障情報を直接かつ連続的にモニターする必要性を除去するかまたは低減する。代わりに、ここに記述される階層故障管理技術は、故障情報がユニットモジュールによって必要とされる時は何時でも、制御モジュールからユニットモジュールへ比較的少量の合成故障情報を自動的に渡す。ユニットモジュールは次いで、ユニットモジュールによって指向されるプロセスを遂行するために必要な制御モジュールに影響を与える故障のタイプおよび集合的苛酷度に基づいて、フェーズまたはフェーズ内部のステップが進行できるか否かを判断でき、それによって不必要なプロセスの停止を最小化しまたは除去する。
本発明の観点によれば、プロセス制御システム中の故障を管理するシステムとその方法は、複数の制御モジュールの各々の内部の故障情報を収集し、かつその制御モジュールによって収集された故障情報に基づいて各制御モジュール内部に合成故障コードを発生する。加えてそのシステムと方法は、合成故障コードのグループを自動的にユニットモジュールに送り、かつその合成故障コードのグループに基づいてプロセスが停止されるべきか否かを判断する。
本発明の別の観点によれば、プロセス制御システム中の故障を管理する方法は、制御モジュール内部の故障情報を収集し、かつその制御モジュールによって収集された故障情報に基づいて制御モジュール内部に合成故障コードを発生する。加えてその方法は、合成故障コードをユニットモジュールへ自動的に送り、かつ合成故障コードに基づいてプロセスが停止されるべきか否かを判断する。
本発明の更に別の観点によれば、プロセス制御システム中の故障を管理するデバイスは、メモリーとそのメモリーに通信連絡的に連結されたプロセッサーを持つコントローラを含む。コントローラは、プロセスが停止されるべきか否かを判断するために合成故障コードを使用するようにプログラムされる。
【発明の実施の形態】
階層故障管理技術はバッチプロセスを実行するプロセス制御システムと関連して記述されるが、ここに記述される階層故障管理技術は有利にも例えば加熱および換気、ビルディングの安全、汚水処理、電力発生等のような実質的に連続するプロセスを遂行するプロセス制御システムを含む色々なプロセス制御システムの内部で使用できる。
階層故障管理技術をより詳細に議論する前に、従来の故障管理技術は、典型的にユニットモジュールまたはユニットが従属制御モジュールからの故障情報をそれによって自動的に受け取る如何なる実行時機構を含まない、ということを認識することが重要である。更に従来のこれらの故障管理技術は、典型的に如何なる仕方においても制御モジュールからユニットモジュールへ故障情報を送るに先立って故障情報を処理しない。代わりに、これらの従来技術は、プロセス制御システム設計者またはユーザーに、作るのが困難でかつ時間を要し、並びにワークステーションまたはコントローラ内部に分離して具体化されなければならない比較的複雑な故障管理ルーチンを発生することを要求する。典型的には、これらの従来の故障管理技術は、制御活動と連続基準でプロセス制御システム全体を通して位置されたデバイスとに関連する故障情報を処理する。実際、故障情報はこれらの従来技術によって典型的に処理され、かつ故障情報と関連するデバイスが実行されているプロセスを遂行するためにプロセス制御システムによって現在必要とされるか否かに関わらず、および根本的な故障の性質または苛酷度に関わらず、そのシステムは通常停止される。こうしてこれらの従来の故障管理技術は、プロセスを完成するために必要でないデバイス（例えばセンサ）の故障に応動して、またはプロセスの結果に影響を及ぼさないであろう最小苛酷度（例えば故障した余剰センサ）に応動して、プロセスの不必要な停止を引き起こしてしまう。
図１は、合成故障コードを制御モジュールからユニットモジュールへ自動的に送るために階層故障管理技術を使用するプロセス制御システム１０の例示の略式ブロック図である。例示目的のみのために、プロセス制御システム１０はバッチプロセス、特に塗料のバッチを作るバッチプロセスを実行するように適応される。しかしながら、ここに記述される故障管理技術は他の何れのバッチ処理応用分野にも、より一般的には他の何れのバッチプロセスまたは何れの連続プロセスを実行する他の何れのプロセス制御システムにも使用できる、ということが理解されるべきである。
プロセス制御システム１０は、イーサネット（登録商標）データ母線またはデータの伝送に適する他の何れのデータ母線でも良いシステムレベルデータ母線１８を経由して通信連絡的に連結されるワークステーション１２および１４およびサーバー１６を含む。ワークステーション１２および１４は、パーソナルコンピュータプラットフォームまたは他の何れかの適当なラットフォームでも良く、かつ既知の色々なプロセス制御機能を実施できる。例えばワークステーション１２は、メモリー２１に記憶され、かつ安全機能を実施しかつ他の機能へのユーザーアクセスおよびプロセス制御システム１０内部の情報を制御するプロセッサー２２により実行されるルーチン２０を含むことができる。同様にワークステーション１４は、メモリー２５に記憶され、かつデータ経歴およびバッチ実行機能を提供するためにプロセッサー２６によって実行されるルーチン２３および２４を含むことができる。ワークステーション１４によって実施されるバッチ実行機能のようなバッチ実行機能により、プロセス制御システムは一つ以上のタイプの製品のバッチを生産するために制御動作の複雑なシーケンスを遂行できる。例えばワークステーション１４によって実施されるバッチ実行機能により、システムオペレータはプロセス制御システム１０内部に一つ以上の塗料バッチを作るバッチプロセスを作り出すことができ、かつ具体化することができる。
一般的に言えば、プロセス制御システム１０はユニットモジュールと制御モジュール間の実行時関係を確立し、それによりプロセス制御システム１０内部の所定シーケンスの事象または動作の実行ができる。特に以下により詳細に議論されるように、ユニットモジュールと制御モジュール情報またはルーチンは、プロセス制御システム１０全体を通して分布される一つ以上のコントローラおよび／またはフィールドデバイスへダウンロードできる。このダウンロード情報の或る部分または総ては、次いでバッチ実行の指導の下に適当な時間に適当なシーケンスで望ましいバッチ処理動作を遂行するために具体化することができる。更に以下により詳細に議論されるように、バッチ実行機能は、ユニットモジュール内部に、プロセス制御システム１０内の一つ以上のデバイス、制御パラメータ等の状態に基づいてバッチ処理活動が停止されるべきか否かを判断する故障管理ロジックを含むことができ、またはそれに従うことができる。
サーバー１６は、ここに記述された階層故障管理技術の一部または総てを実施するために、メモリー３０に記憶された一つ以上のルーチン２８を実行するプロセッサー２７を持つワークステーションで良い。サーバー１６は、システムレベルデータ母線１８を通じて、または代わりに人工衛星準拠無線リンク、モデムリンク等のような他の何れかの適当な通信リンクを通じて、クライアント３２および３４と通信できる。同様にサーバー１６は、またイーサネット（登録商標）データ母線または他の何れの適当なデータ母線でも良いデータ母線３５を経由して別のノードまたはシステム上のクライアント３３と通信できる。クライアント３２−３４は、サーバー１６と通信できるワークステーション、個人的データ補助、ラップトップコンピュータ等のような何れのタイプのハードウェアプラットフォーム上でも進行できる。勿論データ記憶デバイス、追加のユーザーインターフェース等（図示せず）のような他のデバイスもまた、システムレベルデータ母線１８および／または他のノードまたはシステムと関連するデータ母線３５に接続できる。
プロセス制御システム１０は更に、例えばＦｉｓｈｅｒ−ＲｏｓｅｍｏｕｎｔＳｙｓｔｅｍ，Ｉｎｃ．（フィッシャー−ローズマウントシステムズインコーポレイテッド）から商業的に利用できるＤｅｌｔａＶ（登録商標）コントローラのような分散型制御システム（ＤＳＣ）型コントローラ、または他の何れのタイプのコントローラでも良い第一および第二コントローラ３６および３８を含む。コントローラ３６および３８は、専有通信プロトコルまたは適当な他の何れかの通信プロトコルの何れかを使用してシステムレベルデータ母線１８に通信連絡的に連結できる。コントローラ３６および３８は、それぞれの第一および第二入力／出力（Ｉ／Ｏ）デバイス５２および５４、並びにコントローラデータ母線５６および５８を経由してそれぞれのフィールドデバイス４０−４４および４６−５０と通信する。図１に示されるように、フィールドデバイス４０−５０は、コントローラデータ母線５６および５８を通じてメッセージを送ることによりプロセス制御システム１０に関係する情報を通信する情報処理機能を持つフィールドデバイスである。良く知られているように、情報処理機能を持つフィールドデバイスはコントローラと関連する、またはそれから独立する一つ以上のプロセス制御ループを実行するために使用できる。情報処理機能を持つフィールドデバイス４０−５０は例えばフィールド母線デバイスで良く、その場合にはコントローラデータ母線５６および５８はＦＯＵＮＤＡＴＩＯＮ （登録商標）フィールド母線信号プロトコルを使用する非専有プロトコルデータ母線である。しかしながら、ＨＡＲＴ（登録商標）、ＰＲＯＦＩＢＵＳ（登録商標）、ＷＯＲＬＤＦＩＰ（登録商標）、Ｄｅｖｉｃｅ−Ｎｅｔ（登録商標）、ＣＡＮおよびＡＳ−インターフェースプロトコルのような他のタイプのデバイスおよびプロトコルもまた同様に使用することができる。加えてコントローラ３６および３８は従来の（すなわち情報処理機能を持たない）フィールドデバイス（例えば４−２０ｍＡまたは０−１０ＶＤＣのような従来のアナログインターフェースを持つフィールドデバイス）に直接接続できる。例示目的のために、第一コントローラ３６は従来の情報処理機能を持たないフィールドデバイス６０に接続され、そして第二コントローラ３８は情報処理機能を持たないフィールドデバイス６１に接続される。
フィールドデバイス４０−５０、６０および６１は、装置６２−７１に接続される。特に情報処理機能を持たないフィールドデバイス６０および６１はそれぞれの混合タンク６２および７１に接続され、フィールドデバイス４２は第一塗料ベース分配器６３に接続され、フィールドデバイス４０は第一調合機に接続され、フィールドデバイス４４は第一着色剤分配器６６に接続され、フィールドデバイス４６は第二調合機７０に接続され、フィールドデバイス５０は第二着色剤分配器６８に接続され、およびフィールドデバイス４８は第二塗料ベース分配器６９に接続される。図１には示されていないが、プロセス制御システム１０は、塗料のバッチを作るために必要とされる追加のコントローラ、フィールドデバイスおよび装置を含んでも良い。
操作に当たって、故障情報は、望ましいまたは要求される操作範囲外に落ちる制御パラメータに応動して、動作を実施するためのデバイスの故障に応動して、またはフィールドデバイス内部の異常なまたは受入れ不能な条件に応動して、一つ以上のフィールドデバイス４０−５０、６０および６１によって発生できる。例えばフィールドデバイス６０は、混合タンク６２内部の塗料混合物のレベルを感知するレベルセンサで良い。もし混合タンク６２内部の塗料混合物の測定されたレベルが所定の最大レベルを超過するならば、コントローラ３６は自動的に混合タンク６２中の塗料混合物が所定の最大レベルを超過したことを示すフィールドデバイス６０からの故障情報を受けることができる。同様に例えば情報処理機能を持つフィールドデバイス４４は、混合タンク６２中へ一つ以上の着色剤の制御された量を着色剤分配器６６に測らせる弁で良い。フィールドデバイス４４は、フィールドデバイス４４によって送られる命令および／または制御信号に適切に応動するために着色剤分配器６６の故障に応動して故障情報を発生する感知設備と制御ロジック（例えば確認ロジック）を含んでも良い。例えばもしフィールドデバイス４４が着色剤分配器６６に分配器６６内部の弁を開放する信号を送り、かつフィールドデバイス４４は弁が開放されずまたは弁が膠着開放状態であることを（配線、通信等を経由して）検出するならば、フィールドデバイス４４はコントローラ３６へ渡される適当な故障情報を発生できる。
プロセス制御システムと典型的に関連する大量のフィールドデバイスおよび制御パラメータによって、バッチ実行機能および／またはユニットモジュールはプロセス制御システム全体を通して分布される比較的大量のデバイス、制御ループ等から収集される実行不能な程大量の故障情報を潜在的に処理しおよび管理しなければならないであろう。例えば従来のシステムは、特定のデバイスが現在実行されているプロセス（またはフェーズ）によって必要とされるか否かに関わらず、バッチプロセスを遂行するためにシステムによって潜在的に使用できる総てのフィールドデバイスの操作状態を同時にモニターするように、バッチ実行または他の或る故障管理ルーチンを必要とする。実際、このような大量の故障情報をバッチ実行機能またはユニットモジュールのようなより高度のレベル機能によって管理することは、非常に困難である。その結果、多くのシステム設計者／オペレータは、プロセス制御システム内部の、バッチ実行がモニターするまたは各ユニットモジュールがモニターするデバイスの数を実質的に低減する方を選択するであろうし、それによって劣悪なおよび／または危険な生産物が知らぬ間にシステムによって生産されるリスクを増大する（すなわちモニターされないデバイスの故障は検出されないであろう）。あるいは、システム設計者は、プロセス制御システム内部の事実上総てのデバイスおよび制御パラメータをモニターすることを選択するであろうが、それによってそうでなければそのシステムによって生産される生産物の品質に影響を与えなかったであろう誤差や故障に応動してプロセスが停止させられる頻度を大いに増加する。
以下により詳細に議論されるように、ここに記述される階層故障管理技術は実質的にバッチプロセスの実行の間、与えられる如何なる時間においてもバッチ実行機能（および／またはユニットフェーズ内部の故障管理ロジック）が処理しなければならない故障情報の量を低減する。より詳細には、ここに記述される階層故障管理技術は、合成故障コードを発生しかつ実行されているプロセスを遂行するために、その合成故障コードがユニットフェーズによって現在必要とされるモジュールに対応する時点において、これらの合成故障コードを装置階層のユニットレベルへ自動的に送る、（装置階層のユニットレベルにある）制御モジュール内部の機能ブロックを組込む。（ユニットレベルにある）ユニットモジュールは、現在の実行バッチプロセスが継続できるか、またはバッチプロセスは停止されるべきかを判断するために、更にこれらの合成故障コードを処理する機能を組込む。この仕方でユニットモジュールは、実行バッチプロセスが継続すべきであるか、または現在実行しているバッチプロセスが停止されるべきかを判断するために比較的少ない合成故障コードを処理する比較的単純な制御ロジックを採用できる。勿論ユニットレベルにおいて処理された故障情報の一部または総てをまたバッチ実行機能に渡すことができる。バッチ実行機能は次いで、プロセスが継続すべきか否か、または故障したデバイスまたは装置を回避し、かつ現在実行されているバッチの停止を防ぐために装置が再割当てされるべきか否かを独立して判断するために、この情報を使用できる。更に各合成故障コードは大量のデバイス状態条件と制御ループパラメータ条件に基づいて形成できるので、システム設計者またはシステムオペレータは、複合プロセス制御システム内部の故障管理ロジックの実行を実際的なものにするために、デバイスおよび／または制御パラメータのモニターリングを先行させる必要はない。それと反対に、合成故障コード内部の故障情報の連結により、プロセス制御システムは比較的大量の故障情報をより有効に管理できる。また更にここに記述される階層故障管理技術は、合成故障コードをバッチプロセスのフェーズ内部の現在実行しているフェーズまたはステップに関連するユニットレベルまで（そしてもし望むならばバッチ実行まで）送るので、ここに記述される故障管理技術は、故障情報を効果的に時間的にフィルターし、それによって故障管理ロジックがプロセスの実行の間に与えられた如何なるフェーズまたはステップ（すなわち時間間隔）においても処理しなければならない故障情報の量を大いに低減する。
階層故障管理技術のより特定の観点を議論する前に、プロセス制御システム１０内部の物理的装置と、システム１０によって実行されるプロセス制御アルゴリズムと関連する色々なレベルの抽出との間の階層関係の簡単な討議が図２および３と関連して以下に議論される。図２は、プロセス制御システム１０内部の色々なレベルの制御と物理的活動間の物理的関係を表す階層装置モデル１００を描くブロック図である。図２に示されるモデル１００は良く知られたＳＰ−８８装置階層に基づくけれども、しかしながら他の階層モデルも本発明の範囲と意図から逸脱せずに代わりに使用できるであろう。
モデル１００の最高レベルに、区域１０５とプロセスセル１１０はある。区域１０５とプロセスセル１１０は本質的に本来地理的であり、かつプロセス制御システム１０内部の物理的位置を表す。典型的に区域１０５はビルディングまたはプラントと関連するが、一方プロセスセル１１０は特別なタイプの製品を生産する、ビルディングまたはプラント内部の位置と関連する。例えば図１に示されるシステム１０は、その幾つかは図１に示され（すなわちコントローラ３６および３８）およびその幾つかは示されていない複数のコントローラ、複数のフィールドデバイス、装置の色々な部分、クライアントステーション等を含む塗料生産設備でも良い区域に物理的に対応できる。一方、コントローラ３６および３８は、フィールドデバイス４０−５０、６０および６１、Ｉ／Ｏデバイス５２および５４、並びに装置６２−７１と共に一纏めにして一つ以上の塗料のバッチを調合するプロセスセルに対応できる。
階層モデル１００内部のユニットモジュール１１５は、典型的にその装置と関連して働く如何なるセンサ、作動器等と共に装置の特別の部分に対応する。例えば、コントローラ３６（図１）、そこに接続されたフィールドデバイス４０−４４および６０、混合タンク６２、（タンク６２の内容物を混合する）調合機６４、ベース分配器６３および（タンク６２内部の混合物に一つ以上の着色剤を加えることができる）着色剤分配器６６は一纏めにしてユニットモジュールまたはユニット（すなわち塗料混合ユニット）に対応できる。同様にコントローラ３８、フィールドデバイス４６−５０および６１、混合タンク７１、調合機７０、ベース分配器６９および着色剤分配器６８は一纏めにして別のユニットに対応できる。
階層モデル１００内部の制御モジュール１２０は、典型的に例えば比例、積分および／または微分制御機能のような低レベル調節制御機能に対応する。少なくとも概念的には制御モジュールは本来一次機能的である一方、制御モジュールはセンサおよび／または（閉鎖ループ制御を達成するために必要なフィードバック信号を提供するために典型的に使用される）他のモジュールからの入力を受け、および作動器、ヒーター、モータ等へ適当な出力を提供する所定の制御アルゴリズムを使用して、望ましい制御ループ条件（例えばセットポイント）を達成するためにこれらの入力を処理する。例えば図１を参照して、（レベルセンサでも良い）フィールドデバイス６０、ベース分配器６３およびフィールドデバイス４２は、ベース分配器６３によって混合タンク６２に加えられるベース塗料混合物のレベルを制御するために、制御モジュールと協働できる。この制御モジュールに関連する制御アルゴリズムは、情報処理機能を持つフィールドデバイス４２内部に具体化することができ、あるいはコントローラ３６内部に具体化することができる。勿論制御モジュール１２０は抽出であるので、例えば装置の一部が複数の制御モジュールと相互作用でき、または多重制御モジュールが一個の装置を操作するために必要とされることができるように、制御モジュール１２０の対応する物理的構成要素は実施に当たって重なり合うことができる。
図２に示される階層装置モデル１００は、ワークステーション１２および１４、コントローラ３６および３８および／または情報処理機能を持つフィールドデバイス４０−５０の内部に具体化される時、プロセス制御システム１０に塗料のバッチを生産させる色々なソフトウェアオブジェクトの開発を促進するために使用できる。良く知られているように、オブジェクト指向プログラミング技術は個別のオブジェクトまたはモジュールが独立して開発できるようなモジュール形式で高度に複雑な制御アルゴリズムを開発するために使用できる。また良く知られているように、これらのモジュールまたはソフトウェアオブジェクトはパラメータ値を交換することによって互いに通信でき、かつ高度に複雑な制御機能または制御手順を形成するように互いの内部で入れ子状に収まることができる。
図２に示される階層モデル１００を使用して、図１に示されるシステム１０のようなプロセス制御システムをモデル化する時、システム設計者は、そのプロセス制御システムを構成する色々な制御モジュール、ユニットモジュール、プロセスセル等に対応する階層的に関連するソフトウェアオブジェクトを容易に開発できる。例示目的のみのために、この仕方で図１に示されるシステム１０を見る時、そのシステム設計者は、着色剤分配器６６および６８内部の弁のような弁を、特定の期間開放するモジュールが必要とされることを認識できる。ここでそのシステム設計者は、弁開／閉状態、開放時間、弁ＩＤ等のようなパラメータを受け、およびこれらのパラメータについて受け取られた値に応動して、特定の期間特別の弁を開放させる出力を提供し、それによって特定の着色剤の所定量を分配するオブジェクトを開発できる。勿論、この弁開放オブジェクトは、弁の時限作動を必要とするプロセス制御システム１０内部の他の何れの制御モジュールの機能を実施するためにも使用できる。更にシステム設計者は、ユニットレベルソフトウェアオブジェクトは弁開放オブジェクトを呼び出すために必要とされることを認識できる。このユニットレベルソフトウェアオブジェクトは、着色剤分配機能を遂行するために（例えばバッチ実行から）着色剤の量、着色剤のタイプ等を示すパラメータを受けることができる。着色剤分配オブジェクトは次に弁開放オブジェクトを呼び出すことができ、かつ着色剤の適当なタイプと量が混合タンク６２中に分配されるように適当な弁状態、開放期間、および弁ＩＤパラメータ値を提供できる。如何なる事象においても、先の討議から図２に示される階層モデル１００は、複合制御プロセスを遂行するために協働するモジュールソフトウェアオブジェクトの階層の開発を促進するために使用できる。
図３は、複合バッチプロセス制御アルゴリズム内部の抽出の色々なレベルを表すブロック図１５０である。一般的に言えば、バッチプロセス制御アルゴリズムはバッチ実行によって実行される時、高レベルバッチ命令を遂行するために必要とされるユニットモジュールと制御モジュールとに関連するソフトウェアオブジェクトの逐次的具体化を起こす高レベルプログラムである。例えば図１を参照して、１００ガロンの深夜青ラテックス塗料を生産するバッチ手順は、特定の青着色剤の１パイントを混合タンク６２に加えることを特定する。バッチプロセスの実行の間、バッチ実行は例えばコントローラ３６内部のＡＤＤ＿ＣＯＬＯＲＡＮＴ（着色剤添加）オブジェクトを具体化することができ、および加えられるべき青着色剤および青着色剤の量を特定しながらパラメータをコントローラ３６内部のＡＤＤ＿ＣＯＬＯＲＡＮＴオブジェクトへ渡すことができる。ＡＤＤ＿ＣＯＬＯＲＡＮＴオブジェクトは次に情報処理機能を持つフィールドデバイス４４内部に具体化することができ、かつ弁は開放されるべきである弁ＩＤおよびその弁が開放状態に保持されるべき期間を特定するＶＡＬＶＥ＿ＯＰＥＮ（弁開）オブジェクトにパラメータを渡すことができるＶＡＬＶＥ＿ＯＰＥＮオブジェクトを呼び出す。ＡＤＤ＿ＣＯＬＯＲＡＮＴオブジェクトからのパラメータの受け取りに応動して、フィールドデバイス４４内部のＶＡＬＶＥ＿ＯＰＥＮオブジェクトは、フィールドデバイス４４に望ましい青着色剤の望ましい量を混合タンク６２へ分配するために、着色剤分配器６６内部の弁を開放する着色剤分配器６６へ出力を送らせる。
実施に当たって、バッチ手順の実行は、階層的に関係するソフトウェアオブジェクトの連続的な具体化を含むことができる。より詳細には図３に示されるように、バッチ手順１５５は、典型的にプロセス制御システムのユニットレベル（例えばコントローラ）内部に具体化されるソフトウェアオブジェクトである一つ以上のユニット手順１６０およびユニット操作１６５を呼び出すことができる。一般的に言えば、ユニット手順および操作は、装置の特別のタイプの操作および／または制御に関係するオブジェクトである。一方フェーズ１７０は、一般的に装置の特別の一部が遂行できる動作のタイプに関係する。例えば塗料のバッチの生産と関連するフェーズは、ＡＤＤ＿ＣＯＬＯＲＡＮＴ（着色剤添加）、ＭＩＸ（混合）、ＳＴＩＲ（かき混ぜ）、ＢＬＥＮＤ（調合）、ＦＩＬＬ＿ＢＡＳＥ（ベース充填）等であろう。これらのフェーズの各々は、次に一つのアルゴリズムに従う逐次的仕方で実行される一つ以上のステップ１７５より構成される。ステップ１７５はシステム階層の制御モジュールレベルに存在し、かつ各ステップは典型的にソフトウェアオブジェクトおよび制御モジュールと関連するオブジェクトを呼び出す。例えば、ＭＩＸフェーズは混合タンク６２および７１内部の塗料の有効な混合を達成するために、所定の仕方で（すなわちアルゴリズムに従って）調合機６４および７０の一つを開閉させる一つ以上のステップを含むことができる。
フェーズ１７０とフェーズ１７０内部のステップ１７５はプロセス制御システム１０によって実行されるので、制御プロセスが進行する前に入力はセンサから要求され、装置は動作を実施するように要求され、制御パラメータは望ましい目標範囲内部にあることが要求される等々であろう。こうして入力なし、または受入れられない不正確な入力に終わるセンサ故障、要求される動作を遂行するための装置の故障、および／または許容範囲内部に落ちるための制御パラメータの故障は、装置への損傷、劣悪なまたは危険な生産物の生産することを防止するために、および／またはプロセスを継続する前に故障を修復するようにシステムオペレータに介在させるために、プロセスを停止するように要求できる。
図１に示されるプロセス制御システム１０は、デバイス故障および制御誤差、または制御モジュールレベルにおいて収集される他の何れの故障情報をも含む合成故障情報をシステム階層のユニットモジュールレベルまで自動的に渡すように、完全に統合された装置階層（図２および３に一般的に描かれるような）を使用する。この統合された階層により、ユニットモジュールは、それらの制御モジュールから自動的に故障情報を受けるために、そのユニットモジュールに従属的であることができる色々な制御モジュール（またはそのユニットモジュールに従属的でないであろうシステム１０内部の他の何れかの制御モジュール）と合うことができる。その結果、ユニットモジュール内部で運転するフェーズは、そのフェーズに従属的でなく、むしろそのフェーズのステップを遂行する制御モジュール、またはフェーズステップの実行に影響を与えることができる制御モジュールに関連する故障情報を自動的に受けることができる。そのフェーズは次いで、プロセスが継続できるか否か（すなわち現行ステップおよび／または更なるステップが実行できるか否か）を判断するために故障情報を処理できる。勿論ユニットモジュール内部のフェーズによって処理された故障情報もまた、ワークステーション１４内部で運転するバッチ実行に渡すことができ、およびバッチ実行は次いで例えばグラフィカル・ユーザー・インターフェースを経由してシステムオペレータにその故障を報告できる。加えて、バッチ実行は更に故障の周りで作業するために装置を再配置する動作を取ることができ、および／または進行する前にシステムオペレータからの更なる指令待つことができる。
図４は、プロセス制御アルゴリズムのフェーズとステップがプロセス制御システム１０（図１）のユニットモジュールと制御モジュールレベルにおいて、相互作用できる仕方をより詳細に図示する略式ブロック図である。特にコントローラ３６（図１）と関連する塗料混合ユニット２００が、図４に示されている。バッチプロセスの実行の間、バッチ実行機能は混合タンク６２を所定量の塗料ベースで満たすためにユニット処理／操作を呼び出すことができる。典型的には、しかし必ずしも必要ではないが、ユニット処理はコントローラ３６内部に具体化される。ユニット処理は次に、ｂａｓｅ＿ｔｙｐｅ（ベースタイプ）またはｂａｓｅ＿ｑｕａｎｔｉｔｙ（ベース量）のようなパラメータをＦＩＬＬ＿ＢＡＳＥ２０４に渡すことにより、同様に典型的にコントローラ３６内部で具体化されるＦＩＬＬ＿ＢＡＳＥ２０４を呼び出す。図４に示されるように、ＦＩＬＬ＿ＢＡＳＥ２０４は一つ以上のステップ２０６を含むことができ、その各々は一つ以上の制御モジュール２０８−２１２を呼び出すことにより遂行できる。例えばＦＩＬＬ＿ＢＡＳＥ２０４は、特別なベースの望ましい量が混合タンク６２に加えられるように所定の時間量の間ベース分配器６３内部の弁を開くステップを含むことができる。このステップは望ましい動作を遂行するために、ｖａｌｖｅ＿ＩＤ、開閉状態、および期間のようなパラメータを（フィールドデバイス４２内部に具体化することができる）ＶＡＬＶＥ＿ＯＰＥＮモジュール２０８へ渡すことができる。特に、ＶＡＬＶＥ＿ＯＰＥＮモジュール２０８は、望ましい塗料ベースが混合タンク６２に加えられるように、適当な時間量の間ベース分配器６３内部の弁２１８および２１９の適当な一つを開放する出力をフィールドデバイス４２に準備させることができる。勿論ＦＩＬＬ＿ＢＡＳＥ２０４は一旦混合タンク６２に加えられると、ベースをかき混ぜるステップのような、および必要に応じてレベルセンサ６０等を使用してベースのレベルをチェックするステップのような別のステップを含むことができる。
ＦＩＬＬ＿ＢＡＳＥ２０４はまた、ステップ２０６（すなわち制御モジュール２０８−２１２）についての動作を遂行するように必然的には要求されていないが、しかしながらＦＩＬＬ＿ＢＡＳＥ２０４の実行に影響を及ぼすことができる非従属モジュール中に重要度を明示的に記録できる。例示目的のみのために、ＦＩＬＬ＿ＢＡＳＥ２０４は、比較的大きな量の塗料（または塗料構成成分）が例えば漏洩管、弁、タンク等により流出するか否かを判断するために、ユニット２００を囲むプラント床区域を連続的にモニターするＳＰＩＬＬモジュール２２０中に重要度を明白に記録できる。ＦＩＬＬ＿ＢＡＳＥ２０４のステップはそれにパラメータを送ることによってＳＰＩＬＬ（流出）モジュール２２０を制御しない、または呼び出さないけれども、システム設計者はＳＰＩＬＬモジュール２２０に応動する、ＦＩＬＬ＿ＢＡＳＥ２０４への特別安全関連および／または警報ステップを含むことができる。例えばもしＦＩＬＬ＿ＢＡＳＥ２０４がＳＰＩＬＬモジュール２２０を経由して大量の塗料が流出したことを判断するならば、ＦＩＬＬ＿ＢＡＳＥ２０４は直ちに現在の開放弁を閉鎖でき、かつ流出が生じたことを示す警報をオペレータへ送ることができる。
フェーズステップによって呼び出された動作を遂行し、または明白に要求される状態情報を提供することに加えて、モジュール２０８−２１２および２２０は、各モジュールによって制御される装置の操作状態、所定の操作範囲（例えばセットポイントまたは制御範囲）と比較されるプロセス変数の値、または望まれる他の何れの故障情報をもモニターするそれぞれのロジック２２２−２２６を含むことができる。プロセス制御システム１０の装置階層は十分に統合されるので、モジュール２０８−２１２および２２０の各々によって収集される故障情報はもし望むならば自動的にユニット２００まで伝達できる。こうして各フェーズはそのステップが進行できるか否かを判断するために、そのステップを遂行する一つまたは複数のモジュールと関連する故障情報を、ステップ毎に処理できる。この仕方で、そのフェーズもそのバッチ実行も先行システムの場合であったように、全システムベースで総ての故障情報を直接モニターしかつ処理してはならない。代わりに、各フェーズは、各ステップについてそのステップが実行された時点（またはそのステップが実行される時の直前）でそのステップに関与する故障情報のみを処理することによって、そのプロセスが継続できるか否かを判断できる。バッチ実行は次いで例えばそのプロセスが停止されたというフェーズからのメッセージを受けることができ、または代わりに或る他の動作を取るために故障が検出されたけれどもそのプロセスは故障の結果として停止されたか否かのメッセージを受けることができる。
図５は、制御モジュールが故障情報をユニットフェーズまで伝達する仕方、および現在の実行しているバッチプロセスが停止されるべきか否か、または或る他の動作がシステムオペレータによって取られるべきか否かを判断するために、ユニットフェーズが更にこの故障情報を処理する仕方を図示する例示の略式ブロック図である。図５に示されるように、複数の制御モジュール３００−３０４がユニット３０６内部で運転するフェーズと関連する。そのフェーズのステップは、望ましいバッチプロセスを遂行する動作（例えば装置の一部に一つの動作を実行させる）をモジュール３００−３０４に遂行させるために、特別の時間に特別のシーケンスでユニット３０６に従属する一つ以上の制御モジュール３００−３０４にパラメータを送ることができる。或いはまたはそれに加えて、そのフェーズは、ユニット３０６に従属的でないが一つ以上のフェーズステップの実行に影響を与えることができる一つ以上の制御モジュールに明白に重要度を記録できる。如何なる事象においても、制御モジュール３００−３０４の各々は、例えば要求された故障情報のような情報をユニットフェーズに自動的に渡すことができる。特に制御モジュール３００−３０４は、故障情報３０８−３１２のそれぞれのリストを含む。リスト３０８−３１２の各々はその機能を実施するために制御モジュール３００−３０４のそれぞれによって必要とされるセンサ、装置、プロセス制御変数等に関係する故障情報を含む。例えば故障情報３０８−３１２のリストは、センサが最早機能していないこと、弁が膠着開放または閉鎖されていること、および制御パラメータが値の所定範囲外に落ちたことの表示を、あるいは装置の一部および／またはモジュール機能を遂行するために必要とされる制御ループの操作状態に関する他の何れかの情報を含むことができる。
重要なことに、制御モジュール３００−３０４は更に制御モジュール３００−３０４の各々についての合成故障コードを形成するために、リスト３０８−３１２に含まれる故障情報を処理するそれぞれのロジック３１４−３１８を含む。一般的に言えば、ユニットフェーズが比較的大量のデバイス、装置等と関連する合成故障情報をより迅速にかつ容易に処理できるように、ユニットフェーズがその特別な制御モジュールを必要とする（すなわち動作を遂行するために必然的にモジュールを要求する、または安全の目的または何か他の目的のために明白にモジュールを要求する）ステップに入るまたは入ろうとしている時、合成故障コードは形成され、かつ制御モジュール３００−３０４の各々によってユニット３０６へ送られる。
合成故障コードは、色々な技術を使用して発生することができる。例えば故障情報３０８−３１２のリスト内部の各項目は、その特別な故障情報のタイプと苛酷度を反映する数値を割り当てられる。各リスト３０８−３１２内部の数値は、次いでそのモジュールについての合成故障コードを形成するために数学的に結合される。例えばリスト３０８−３１２内部の数値は、もし望むならば加重係数を使用して合計される。或いはまたはそれに加えて、数値は掛け算され、引き算されおよび／または望ましい如何なる線形関数、非線形関数、不連続関数等を使用して処理される。勿論、各リスト内部の故障情報は、本発明の範囲と意図から逸脱することなしに合成故障コードを作るために他の如何なる方法でも結合することができる。
更に或るタイプの故障は、リスト中の別の故障の存在または欠如に基づいて、より大きなまたはより小さな数値が与えられる。例えば一対の余剰センサの場合、一対の余剰センサの一方の故障はそのリスト中の故障センサに割り当てられた一つの数値に帰着するのに対し、一方両センサの故障はより高い数値をリスト内部の両故障に割り当てることができる。また更に各故障に割り当てられた数値は、プロセス制御システムによって生産される製品のタイプの基づくことができる。例えば、塗料のバッチを生産するプロセス制御システムの場合には一般的により低い数値がリスト３０８−３１２内部の故障に割り当てられ、一方医薬製品を生産するプロセス制御システムの場合には一般的により高い数値がリスト３０８−３１２内部の故障に割り当てられる。
制御モジュール３００−３０４の各々によって発生される故障コードはユニット３０６まで渡され、かつユニット３０６内部の動的故障コードリスト３２０中に維持される。ユニット３０６内部で現在実行されているフェーズは、フェーズのステップを遂行することを必然的に要求されるモジュールからのそれらの故障コード、およびそのフェーズのステップの間モニターされることをユーザーが明白に要求したモジュールからの故障コードのみを故障コードリスト３２０中に含むことを、ユニット３０６に指示する。そのフェーズは、以下の図７と関連して例示目的で記述される故障管理ロジック３２２を含み、その故障管理ロジック３２２は実行されているプロセスが継続すべきかまたは或る他の動作が取られるべきかを判断するために、故障コードリスト３２０中の故障コードを処理する。
図６は例示目的のみのために、図５に示されるユニット３０６内部の故障コードリスト３２０が時間と共に（すなわちプロセスが進行するにつれて）変化できる仕方をグラフ的に描写する。図６に見ることができるように、時間ｔ１において、ユニットフェーズのみによって実行されているステップはモジュール１（Ｍ１）を使用する。こうしてユニット故障コードリスト３２０は、Ｍ１についての（例示目的のために数値５００を持つように示される）現在の合成故障コードのみを含む。同様に時間ｔ２、ｔ３およびｔ４においてユニット故障コードリスト３２０の内容は、フェーズによって現在必要とされないモジュールが故障コードリスト３２０に含まれないように、動的に変化する。例えば時間ｔ２において、ユニットフェーズはモジュール１、２および３（すなわちＭ１、Ｍ２およびＭ３）を使用し、およびユニット故障コードリスト３２０はそれぞれの合成故障コード７５０，２５０および１０００を含む。図６に見ることができるように、ユニット故障コードリスト３２０内部の合成故障コードを持つモジュールのグループは、時間と共に変化する。更に特別のモジュールによって与えられる合成故障コードの数値は、時間と共に変化する。例えばＭ１は時間ｔ１−ｔ４についてのユニット故障コードリスト３２０中の合成故障コードを持つモジュールグループの一員であるが、Ｍ１によって与えられる合成故障コードの数値はｔ１からｔ４に亘って２５０から７５０の範囲に変動する。
図７は、図５に示されるフェーズの故障管理ロジック３２２が、故障コードリスト３２０内部の故障コードを処理できる一つの仕方を図示する例示の流れ図である。ブロック４００は、故障コードリスト３２０から最悪の故障コードを選択する。この例における最悪の故障コードは、この例においてはモジュールはより苛酷な故障により高い数値を割り当てるように構成されているので、最大数値を持つ故障コードである。しかしながら代わりの処理技術は、モジュールがより苛酷な故障により低い数値を割り当てる場合において、最小数値を持つ故障コードを選択できるであろう。如何なる場合においても、ブロック４０４は最悪故障コードが第一閾値（ＴＨ１）より小さいか否かを判断する。もし最悪故障コードが第一閾値（ＴＨ１）より小さければ故障管理ロジック３２２はブロック４０８に入り、そのプロセスが進行できるか否かを判断する。一方もし最悪故障コードが第一閾値（ＴＨ１）より大きければ、故障管理ロジック３２２はブロック４１２に入る。ブロック４１２は最悪故障コードが第二閾値（ＴＨ２）より小さいか否かを判断し、もし最悪故障コードが第二閾値より小さければ、故障管理ロジック３２２はブロック４１６に入る。ブロック４１６は、そのプロセスが進行できるが、合成故障コードはシステムオペレータによる更なる調査に値するために十分に大きいことを指示する。ユニット３０６はバッチ実行に調査の必要性を報告でき、バッチ実行は次にグラフィカル・ユーザー・インターフェースを経由してシステムオペレータに適当な命令を表示できる、ということを認識することは重要である。一方もし最悪合成故障コードが第二閾値より小さくなければ、次いで故障管理ロジック３２２はブロック４１８に入る。ブロック４１８は最悪合成故障コードが第三閾値（ＴＨ３）より小さいか否かを判断し、もし最悪故障コードが第三閾値より小さければ、故障管理ロジック３２２はブロック４２２に入る。ブロック４２２はバッチプロセスの実行が進行できるが、合成故障コードは故障を調査するために保全要員の派遣に値するために十分に大きいことを指示する。もし最悪合成故障コードが第三閾値より大きければ、次いで故障管理ロジック３２２はブロック４２６に入り、かつ自動的にバッチを実行から停止する。
図７に示される第一から第三閾値についての数値は、生産される製品のタイプ、プロセス制御システムのパラメータ、製品品質目標等に基づいて選択できる。例えば医薬製品および高品質塗料製品の生産は、比較的重要度の低い問題でさえバッチの停止に至るであろうということを保証するために、一般的により低い閾値を要求する。一方例えば低品質塗料製品は、生産コストを低く保つためにバッチ停止の可能性を最小にするようにより高い閾値を使用させることができる。その上、図７と関連して三つの閾値が議論されたが、その代わりにより多いまたはより少ない閾値が本発明の範囲と意図から逸脱することなしに使用できるであろう。更にまた故障対策の指導／調査すべき示唆等は、特別の応用分野に適するために望ましいように変更できる。
図７と関連して記述される故障管理ロジック３２２はユニット３０６内部で実行されるように記述されたが、（この例では図１に示されるワークステーション１４内部で運転している）バッチ実行機能は代わりに故障管理活動の幾つかまたは総て実施することができるであろう。或いはまたはそれに加えて、故障管理活動の幾つかまたは総てはサーバー１６内部で運転する一つ以上のソフトウェアルーチンによって実施できるであろう。如何なる事象においても、もしユニット３０６が故障管理活動を実施するならば、ユニット３０６はバッチ実行機能に報告するであろうことが、必ずしも必要ではないが、好ましい。例えばユニット故障管理ロジック３２２が、高い値の故障コードの原因を判断するために更なる調査が値すると判断する時、このような判断はバッチ実行に報告され、それは次いでそのメッセージをユーザーインターフェースを経由してシステムオペレータに伝えることができる。
ここに記述された階層故障管理技術は、現在実行されているプロセスが継続できるか否かを判断するために、故障情報をその情報がユニットによって必要とされる時は何時でも、制御モジュールからユニットへ自動的に渡す。更に階層故障管理技術は、ユニット内部の故障管理ロジックによって処理されるようにユニットへ渡される合成故障コードを制御モジュールレベルで発生する。これらの合成故障コードは、プロセスが操作を継続できるか否かをユニットレベルで迅速に判断するために比較的大量の故障情報が使用できるようにする。また更にここに記述された階層故障管理技術は、非臨界的故障に応動して、または実行されているプロセスのフェーズを遂行するために現在必要でないデバイスおよび／または装置に関連する故障に応動して、不必要なプロセス停止の発生を最小にしまたは除去することができる。
もしソフトウェアにおいて実行されるならば、ここに議論した機能的ブロックおよびルーチンは、磁気、光、または他の記憶媒体上の如何なるコンピュータ読み出し可能メモリー中に、およびコンピュータ、コントローラ、フィールドデバイス等のＲＡＭまたはＲＯＭ中に記憶できる。同様にこのソフトウェアはキャリヤー上で変調でき、かつ例えば電話線インターネット等のような通信チャンネルを通じることを含む如何なる既知のまたは望ましい配信方法を経由してユーザーまたはデバイスに配信できる。
本発明は例示のみを意図されかつ本発明を限定するものではない特定の例を参照して記述されてきたが、当該技術に習熟した人々には本発明の意図とその範囲から逸脱せずに変更、追加または削除が開示された実施例に為され得る、ということは自明であろう。
【図面の簡単な説明】
【図１】バッチプロセスを実施しつつ、階層故障管理技術を使用するプロセス制御システムの略式ブロック図である。
【図２】図１に示されたプロセス制御システムによる実施についての複合プロセス制御アルゴリズムを開発するために使用できる階層装置モデルのブロック図である。
【図３】複合プロセス制御アルゴリズム内部の色々な抽出レベルを表すブロック図である。
【図４】図１に示されたプロセス制御システム内部のユニットモジュール、制御モジュール、フェーズおよびステップ間の実行時通信関係を図示する例示の略式ブロック図である。
【図５】合成故障コードが制御モジュールからユニットモジュールへ自動的に通過できる一つの仕方を図示する例示のブロック図である。
【図６】ユニットモジュール内部の合成故障コードが時間的に変化する仕方の例示的なグラフ的記述であり、および、
【図７】プロセスが進行すべきかどうかを決定するために、ユニットモジュールが合成故障コードのリストを処理できる一つの仕方を記述する例示的な流れ図である。
【符号の説明】
１０：プロセス制御システム
１６：サーバー
３３：クライアント
３６：コントローラ
６０：フィールドデバイス
６２：混合タンク
６３：ベース分配器、
６４：調合機
６６：着色剤分配器
１１０：プロセスセル
１１５：ユニットモジュール
１２０：制御モジュール

Claims (37)

1. ユニットモジュール、および該ユニットモジュールよりも下位の階層にあって該ユニットモジュールに通信連絡的に連結された複数の制御モジュールを有してなりプロセスを実行するプロセス制御システムにおいて使用する故障管理方法において、
   前記制御モジュールの各々によって、該制御モジュールの各々の内部の故障情報を収集するステップと、
   前記制御モジュールの各々によって、各制御モジュール内部の前記故障情報に基づいて、前記制御モジュールの各々の故障のタイプ及び集合的苛酷度を示す前記制御モジュールの各々の内部の合成故障コードを発生するステップと、
   前記制御モジュールによって、前記合成故障コードグループを自動的にそのユニットモジュールに送るステップと、
   前記ユニットモジュールによって、前記合成故障コードグループに基づいて前記プロセスが停止されるべきか否かを判断するステップとを有し、
   前記合成故障コードグループを前記ユニットモジュールへ自動的に送るステップは、前記ユニットモジュールによって、前記プロセスを構成すると共に前記制御モジュールを動作させるための１以上のステップにより構成される前記ユニットモジュールにより実行されるフェーズに基づいて前記合成故障コードグループを選択するステップを含む
   ことを特徴とする方法。
2. 前記制御モジュールの各々の内部の故障情報を収集するステップは、前記制御モジュールの各々の内部の故障のリストを発生するステップを含む、
   ことを特徴とする請求項１に記載の方法。
3. 前記故障のリストを発生するステップは、前記制御モジュールについての動作を遂行する一つ以上の制御ループ、センサおよび作動器に関連する故障情報を記憶するステップを含む、
   ことを特徴とする請求項２に記載の方法。
4. 前記各制御モジュール内部の前記故障情報に基づいて前記制御モジュールの各々の内部の合成故障コードを発生するステップは、各制御モジュール内部の前記故障情報を数学的に結合するステップを含む、
   ことを特徴とする請求項１に記載の方法。
5. 前記故障情報を数学的に結合するステップは、前記故障情報を使用して加重合計を計算するステップを含む、
   ことを特徴とする請求項４に記載の方法。
6. 前記フェーズに基づいて前記合成故障コードグループを選択するステップは、前記プロセスにて現在実行されているフェーズに基づいて、該フェーズの実行に関連する前記制御モジュールの内部のその合成故障コードグループを選択するステップを含む、
   ことを特徴とする請求項１に記載の方法。
7. 前記フェーズに基づいて前記合成故障コードグループを選択するステップは、前記ユニットモジュールに対して非従属の制御モジュールと関連する合成故障コードを選択するステップを含む、
   ことを特徴とする請求項１に記載の方法。
8. 前記非従属の制御モジュールと関連する合成故障コードを選択するステップは、前記ユニットモジュールにより現在実行されているフェーズに該非従属の制御モジュールを必要な制御モジュールとして含めることに対する明白な要求に基づいて、該合成故障コードを選択するステップを含む、
   ことを特徴とする請求項７に記載の方法。
9. 前記合成故障コードグループに基づいて前記プロセスが停止されるべきか否かを判断するステップは、前記合成故障コードグループから一つの合成故障コードを選択するステップと、該一つの選択された合成故障コードを前記プロセスが停止されるべきであるか否かの判断に関連する第一所定閾値と比較するステップとを含む、
   ことを特徴とする請求項１に記載の方法。
10. 前記合成故障コードグループに基づいて前記プロセスが停止されるべきか否かを判断するステップは、更に、前記一つの選択された合成故障コードを前記プロセスが継続すべきであるという判断と関連する第二所定閾値と比較するステップを有する、
    ことを特徴とする請求項９に記載の方法。
11. 前記合成故障コードグループから一つの合成故障コードを選択するステップは、前記集合的苛酷度が最も高いことを示す最悪合成故障コードを選択するステップを含む、
    ことを特徴とする請求項９に記載の方法。
12. 前記最悪合成故障コード選択するステップは、前記合成故障コードグループから最高数値を持つ合成故障コードを選択するステップを含む、
    ことを特徴とする請求項１１に記載の方法。
13. ユニットモジュール、および該ユニットモジュールの下位の階層にあって該ユニットモジュールに通信連絡的に連結された制御モジュールを有してなりプロセスを実行するプロセス制御システムにおいて使用する故障管理方法において、
    前記制御モジュールによって、該制御モジュールの内部の故障情報を収集するステップと、
    前記制御モジュールによって、前記制御モジュール内部の前記故障情報に基づいて、前記制御モジュールの故障のタイプ及び集合的苛酷度を示す前記制御モジュールの内部の合成故障コードを発生するステップと、
    前記制御モジュールによって、前記合成故障コードを自動的に前記ユニットモジュールに送るステップと、
    前記ユニットモジュールによって、前記合成故障コードに基づいて前記プロセスが停止されるべきか否かを判断するステップと、を有し、
    前記合成故障コードグループに基づいて前記プロセスが停止されるべきか否かを判断するステップは、前記合成故障コードグループから一つの合成故障コードを選択するステップと、該一つの選択された合成故障コードを前記プロセスが停止されるべきであるか否かの判断に関連する第一所定閾値と比較するステップとを含み、
    前記合成故障コードグループから一つの合成故障コードを選択するステップは、前記集合的苛酷度が最も高いことを示す最悪合成故障コードを選択するステップを含む
    ことを特徴とする方法。
14. 前記制御モジュール内部の前記故障情報に基づいて前記制御モジュールの内部の合成故障コードを発生するステップは、前記制御モジュール内部の前記故障情報を数学的に結合するステップを含む、
    ことを特徴とする請求項１３に記載の方法。
15. 前記故障情報を数学的に結合するステップは、前記故障情報を使用して加重合計を計算するステップを含む、
    ことを特徴とする請求項１４に記載の方法。
16. 前記合成故障コードに基づいて前記プロセスが停止されるべきか否かを判断するステップは、前記合成故障コードを所定閾値と比較するステップを含む、
    ことを特徴とする請求項１３に記載の方法。
17. プロセッサーと、ユニットモジュールと、該ユニットモジュールの下位の階層にあって該ユニットモジュールに通信連絡的に連結された複数の制御モジュールとを有してなりプロセスを実行するプロセス制御システムにおいて使用される故障管理のためのコンピュータ読み出し可能指示を格納するように構成されたコンピュータ読み出し可能媒体において、前記コンピュータ読み出し可能指示が、
    前記プロセッサーによって、前記制御モジュールの各々が、前記制御モジュールの各々の内部の故障情報を収集するように実行させるべく適応されている第一ルーチンと、
    前記プロセッサーによって、前記制御モジュールの各々が、各制御モジュール内部の前記故障情報に基づいて前記制御モジュールの各々の内部の合成故障コードを発生するように実行させるべく適応されている第二ルーチンと、
    前記プロセッサーによって、前記制御モジュールが、合成故障コードグループをそのユニットモジュールへ自動的に送るように実行させるべく適応されている第三ルーチンと、
    前記プロセッサーによって、前記ユニットモジュールが、前記合成故障コードグループに基づいて前記プロセスが停止されるべきか否かを判断するように実行させるべく適応されている第四ルーチンとを有し、
    前記第三ルーチンは、更に、前記プロセスを構成すると共に前記制御モジュールにより実行されるステップにより構成されて前記ユニットモジュールにより実行されるフェーズに基づいて、前記合成故障コードグループを選択するように適応されている
    ことを特徴とするコンピュータ読み出し可能媒体。
18. 前記第一ルーチンは、更に、前記制御モジュールの各々の内部に故障のリストを発生するように適応されている、
    ことを特徴とする請求項１７に記載のコンピュータ読み出し可能媒体。
19. 前記第一ルーチンは、更に、前記制御モジュールについての動作を遂行する一つ以上の制御ループ、センサおよび作動器と関連する故障情報を記憶するように適応されている、
    ことを特徴とする請求項１８に記載のコンピュータ読み出し可能媒体。
20. 前記第二ルーチンは、更に、前記制御モジュールの各々の内部の前記故障情報を数学的に結合するように適応されている、
    ことを特徴とする請求項１７に記載のコンピュータ読み出し可能媒体。
21. 前記第二ルーチンは、更に、前記故障情報を使用して加重合計を計算するように適応されている、
    ことを特徴とする請求項２０に記載のコンピュータ読み出し可能媒体。
22. 前記第三ルーチンは、更に、前記プロセスにて現在実行されているフェーズに基づいて、前記合成故障コードグループを選択するように適応されている、
    ことを特徴とする請求項１７に記載のコンピュータ読み出し可能媒体。
23. 前記第四ルーチンは、更に、前記合成故障コードグループから一つの合成故障コードを選択し、かつ該一つの合成故障コードを前記プロセスが停止されるべきであるか否かの判断に関連する第一所定閾値と比較するように適応されている、
    ことを特徴とする請求項１７に記載のコンピュータ読み出し可能媒体。
24. 前記第四ルーチンは、更に、前記一つの合成故障コードを前記プロセスが継続すべきであるという判断と関連する第二所定閾値と比較するように適応されている、
    ことを特徴とする請求項２３に記載のコンピュータ読み出し可能媒体。
25. 前記第四ルーチンは、更に、前記合成故障コードグループから前記集合的苛酷度が最も高いことを示す最悪合成故障コードを選択するように適応されている、
    ことを特徴とする請求項２３に記載のコンピュータ読み出し可能媒体。
26. 前記第四ルーチンは、更に、最高数値を持つ合成故障コードを前記最悪合成故障コードとして選択するように適応されている、
    ことを特徴とする請求項２５に記載のコンピュータ読み出し可能媒体。
27. ユニットモジュール、および該ユニットモジュールの下位の階層にあって該ユニットモジュールに通信連絡的に連結された複数の制御モジュールを有してなりプロセスを実行するプロセス制御システムにおいて使用する故障管理デバイスにおいて、
    メモリーおよびそのメモリーに通信連絡的に連結されたプロセッサーを持つコントローラを有し、
    該コントローラは、前記プロセスが停止されるべきか否かを判断するために、前記制御ユニットの各々によって発生され、前記制御モジュールの各々の故障のタイプ及び集合的苛酷度を示す合成故障コードを使用するようにプログラムされており、
    前記コントローラは、更に、前記プロセスを遂行するために前記ユニットモジュールによって現在必要とされる前記制御モジュールの一つと関連する合成故障コードに基づいてそのプロセスが停止されるべきか否かを判断するようにプログラムされ、
    前記コントローラは、更に、前記プロセスが停止されるべきか否かを判断するために合成故障コードの一つを選択し、かつ該選択された一つの合成故障コードを所定閾値と比較するようにプログラムされている
    ことを特徴とするデバイス。
28. 前記コントローラは、更に、前記選択された一つの合成故障コードとして前記集合的苛酷度が最も高いことを示す最悪合成故障コードを選択するようにプログラムされている、
    ことを特徴とする請求項２７に記載のデバイス。
29. プロセスを実行するプロセス制御システムにおいて、
    複数のフィールドデバイスと、
    その複数のフィールドデバイスに通信連絡的に連結されかつそのプロセスの少なくとも一部を遂行するユニットモジュールを含むコントローラとを有し、
    前記ユニットモジュールは、前記コントローラに前記プロセスが停止されるべきか否かを判断するために、該ユニットモジュールよりも下位の階層にある複数の制御モジュールによって発生されて該制御モジュールの各々の故障のタイプ及び集合的苛酷度を示す合成故障コードのグループを処理させ、
    前記ユニットモジュールは、前記プロセスを構成すると共に前記制御モジュールを動作させるための１以上のステップにより構成される前記ユニットモジュールにより実行されるフェーズのうち、前記プロセスにて現在実行されているフェーズに基づいて、前記コントローラにその合成故障コードのグループを選択させる
    ことを特徴とするプロセス制御システム。
30. 前記複数の制御モジュールは、前記複数のフィールドデバイス内部で具体化される、
    ことを特徴とする請求項２９に記載のプロセス制御システム。
31. 前記複数の制御モジュールは、コントローラ内部で具体化される、
    ことを特徴とする請求項２９に記載のプロセス制御システム。
32. 前記制御モジュールの各々は、そのそれぞれの合成故障コードを発生するために故障のリストを使用する、
    ことを特徴とする請求項２９に記載のプロセス制御システム。
33. 前記故障リストは一つ以上の故障と関連する数値を含み、そのフィールドデバイスの各々は、そのそれぞれの合成故障コードを発生するためにそのそれぞれの故障リスト内部の数値を数学的に結合する、
    ことを特徴とする請求項３２に記載のプロセス制御システム。
34. 前記制御モジュールの各々は、前記数値の加重合計を計算することによりそのそれぞれの故障リスト内部の数値を数学的に結合する、
    ことを特徴とする請求項３３に記載のプロセス制御システム。
35. 前記制御モジュールは、そのそれぞれの合成故障コードを前記コントローラへ自動的に送る、
    ことを特徴とする請求項２９に記載のプロセス制御システム。
36. 前記コントローラは、前記合成故障コードのグループから、前記集合的苛酷度が最も高いことを示す最悪故障コードを選択し、かつ該最悪故障コードを前記プロセスが停止されるべきか否かの判断と関連する所定閾値と比較することによって前記合成故障コードのグループを処理する、
    ことを特徴とする請求項２９に記載のプロセス制御システム。
37. 前記コントローラは、前記合成故障コードのグループから前記最悪故障コードとして最高数値を持つ合成故障コードを選択する、
    ことを特徴とする請求項３６に記載のプロセス制御システム。

Images