JP2016201142A - 製品レシピを生成する方法 - Google Patents

Abstract

【課題】製品レシピが複数のアクション、一式の遷移および一式のパラメータと関連付けられ、且つ、バッチプロセスが設備と交信するフェーズ・レベルを含む複数の論理レベルを複数のアクションが定義するように自動化製造環境においてバッチプロセスにより実行するために製品レシピを生成する方法の提供。【解決手段】本発明の方法には、複数のアクションを指定する手順の定義を受け取ることと、一式の遷移における各々が二つ以上の複数のアクションと関連付けられるように該一式の遷移を指定する取引（トランザクション）の定義を受け取ること、そして該一式のパラメータを受け取ることとが含まれる。該一式のパラメータを受け取ることには、レシピまたはレシピのフェーズ・レベルで関連付けられているオペレータ・プロンプトから値を得ることなく値になる少なくとも一つの動的入力パラメータを受け取ることが含まれる。【選択図】図１

Description

本発明は、概してプロセス制御ネットワークに関し、より具体的にはレシピ階層のいかなるレベルでの事前に定義されたコマンドセットおよび動的入力パラメータをサポートするバッチ実行環境に関する。

一般に、大量の製薬、化学薬品、飲料、塗料またはその他いかなる製品を生成するためのバッチ処理技法を利用するようなプロセス制御システムは、例えばバルブポジショナ、スイッチ、センサ（温度、圧力および流量センサ、等）などでありうる一つ又は複数のフィールド装置に通信可能に連結された一つ又は複数の集中プロセスコントローラを含んでいる。これらのフィールド装置は、例えばバルブ、ポンプ、混合ユニットなどの制御設備と関連しうる、プロセス制御システム内の物的管理機能（例えば、バルブの開閉、ポンプまたは混合ユニットのオン・オフ、等）を行いうる、工程の動作を制御するのに使用するプロセス制御システム内の計測を取りうる、またはプロセス制御システム内のその他所望の機能を行いうる。一般的に言って、プロセスコントローラは、一つ又は複数のフィールド装置により作成された測定且つ又はフィールド装置に関するその他の情報を示す信号を受け取り、この情報を利用して一般に複雑な制御ルーチンを実施し、プロセス制御システムの動作を制御するべくフィールド装置に信号ラインまたはバスを介して送信される制御信号を生成する。

さらに、プロセスコントローラは一般に一つ又は複数のワークステーションおよびその他の装置にイーサネット（登録商標）・バスなどデータ・ハイウェイを介して連結される。
一般に、これらその他の装置は、ユーザーインタフェースを制御ルーチンに提供したり、制御ルーチンの修正変更または更新を可能にしたり、フィールド装置とのインターフェース接続や履歴に基づくプロセス制御データの格納、ユーザ・アクセスの制御または制限を行うなど、その他のプロセス制御機能を提供するべく一つ又は複数のコントローラにより提供される情報を利用するその他のアプリケーションまたはプログラムを実行する。大規模なプロセス制御システムの幾つかでは、リモートサイトに位置する一つ又は複数のワークステーションが、例えばインターネット接続、サテライトまたは移動体通信リンク、（ワイヤレス・イーサネット（登録商標）接続に使用されるような）無線リンクなどの更なる通信ネットワークを介してデータ・ハイウェイに連結されうる。

一般に、製品のバッチを生産するプロセス制御システムは、ユーザ（例えば、エンジニア）が基本製品レシピ、バッチパラメータ、設備リストなどを一つ又は複数定義し格納することを可能にするグラフィカルインターフェースを含んでいる。一般に、これらの基本製品レシピは、特定の設備リストに各々関連するまたは結合される工程ステップの配列を含んでいる。レシピ工程ステップを特定の設備に結合するにあたり、ユーザ（例えば、オペレータ）は、レシピのバッチ実行前に、どのプロセス制御装置がレシピの各工程ステップを実行するのに使用されることになるかを明示的に定義する。加えて、工程ステップの各々において、装置作動の順序且つ又はタイミングの制御、警報設定や標的制御値（例えば、設定点）の設定などのためにバッチの実行中に使用される一つ又は複数の入・出力（Ｉ／Ｏ）バッチパラメータ値を定義することがユーザ（例えば、オペレータ）に要求されうる。これらのＩ／Ｏパラメータ値は、プロセス制御システム内のフィールド装置の一つ又は複数に送られる、または該フィールド装置の一つ又は複数から受け取られる入力および出力と関連しうる、あるいはその代わりに、バッチの実行中にプロセス制御システムにより生成される中間値または計算値でありうる。よって、バッチを定義するにあたり、ユーザ（例えば、オペレータ）は一般にグラフィカルインターフェースを使用して、（レシピの工程ステップをプロセス制御装置に結合する仕様を含んでいる）基本製品レシピを選択したり、バッチの実行中に使用されるべきパラメータ値を指定したりする。例えば、塗料のバッチを生産するコントロールシステムでは、ユーザ(例えば、オペレータ)が、例えば半光沢の屋外用ラテックス塗料など、基本的な塗料レシピを選択するべくグラフィカルインターフェースとの交信を行い、特定色の半光沢屋外用ラテックス塗料１００ガロンのバッチの生産をもたらすパラメータ値を指定しうる。

一例に過ぎないが、基本塗料レシピは、基本的な塗料混合物に着色剤またはその他の物質を追加する工程ステップを一つ又は複数含みうるし、且つ、これらの着色剤およびその他の物質を該基本塗料混合物に機械的に混合する更なる付加的な工程ステップを含みうる。配合および混合工程ステップまたは基本的な塗料レシピと関連するその他いかなる工程ステップは、プロセス制御システム内の特定の設備に結合されうる。例えば、第１の混合ステップが第１の混合機に結合され、第２の混合ステップは第２の混合機に結合されうる、またはその代わりに、望ましい場合、第２の混合ステップは第１の混合機に結合されうる。同様に、塗料混合物に着色剤を追加するレシピの各工程ステップは、特定の着色剤分配設備に結合されうる。

さらに、バッチを定義する際に、ユーザは、バッチにより指定された工程ステップを実行し所望の最終塗料製品を得るべくバッチの実行中にプロセス制御システムにより使用される様々なＩ／Ｏパラメータ値（例えば配合倍率、着色剤量など）を提供しうる。よってユーザは、（Ｉ／Ｏパラメータ値により指定される如く）様々な色で（基本レシピにより指定される如く）様々な基本塗料タイプをはじめとし、様々な最終塗料製品を生産することができる。もちろん、従来のバッチ定義技法は、例えば製薬、飲料、食品製品などその他の多くのタイプの製品を作り出すのにも使用されうるので、プロセス制御システムが所望の最終製品を生産するように異なった特定の工程ステップ、工程ステップに結合された設備およびＩ／Ｏパラメータ値を設定しうる。

近年、バッチ実行環境は著しく複雑性を増している。例えば、最新バッチプロセス工場の多くが、複数の「設備系列」（即ち、特定のバッチ運転を物理的に行うのに必要である動作可能な状態で接続されている一式の制御設備ユニット）を採用して複数の並列バッチを稼動させている。また、レシピもより長いものとなってきており、それに応じて各手順ステップの複雑性も増してきている。一方、現在の計測装置はより優れたバッチパラメータの計測を得て、これらの計測をコントローラやオペレーターワークステーションに実時間で（または実時間に近い状態で）報告できるようになっている。特に、これらの計測装置は、例えば温度上昇過大、不十分な圧力または特定の化学薬品の予想外に高い濃度などの異常状態を迅速かつ正確に検出しうる。当然、オペレータは、これらの条件に可能な限り迅速に対応し、製品の損失を低減し有害な状況を避けることを望む。その結果、業界としては、たとえ制御バッチの作業がますます複雑になりつつあるとしてもバッチ実行環境により多くのフレキシビリティを求める。

なおまた、幾つかの国では、特定の製造手法に関連する政府規制の変更も生じている。例えば、米国の食品医薬品局（ＦＤＡ）は最近いわゆるプロセス解析工学（ＰＡＴ：Process Analytic Technology）を率先し始めた。ＰＡＴの目標は、最終製造品に加えて製造工程を制御することであると述べられている。ＰＡＴ要求に準拠するため、製造会社は、対応する製造工程の中間ステップで品質を保証し、且つ、当然のことながら、適切且つ適時に検出された状態に対応できるようになっていなければならない。よって、現代のバッチ実行環境は、経済的および規制上の理由でフレキシビリティを有していなければならない。

あいにく既存のバッチ実行技術と方法は、これらの要求を費用効率が高い方法で満たすに至らない。バッチプロセス工場で稼動する代表的なプロセス制御システムは、デディケイテッド・データベース内のレシピ情報を維持管理する。該データベースは、製品ごとに、レシピの手順構造、レシピ・パラメータ、レシピにより要求される設備ユニットの一覧リストおよびその他のレシピ情報を含みうる「制御レシピ」を格納する。オペレータの命令またはその他あらかじめ定められた条件に応答して、プロセス制御システムは、データベースから特定の制御レシピを読み出し、選択されている「バッチエグゼクティブ」または、受け取ったレシピに応じて一つ又は複数のバッチ運転の実行をつかさどるサブシステムにレシピを適用する。

近年、バッチ実行環境のフレキシビリティを高める試みが幾つかなされている。例えば、エマソン・プロセスマネジメント社製ＤｅｌｔａＶ（登録商標）インターフェースツールは、オペレータが、アクティブステップ変更機能の一部としてレシピのステップ間の遷移を強いることを可能にする。さらにこの機能によって、スタンド・アロンのバッチとしてオペレータがレシピの特定のフェーズの実行を開始することが可能になる。但し、該機能におけるこの態様はレシピの元の定義に限られている。なおまた、マニュアル操作はフェーズ・レベルでのみ可能である。新たなバージョンの対応するバッチレシピで実行されるバッチをオペレータが同期化できるようにするべく、「Online Recipe Synchronization in a Real-Time Batch Executive Environment（仮訳：実時間バッチエグゼクティブ環境におけるオンラインでのレシピ同期化）」と題されるＰｅｔｔｕｓらによる米国特許出願Ｎｏ．１２／２３４，１１７の一部に、現在稼動中のバッチへの変更を受け入れることができるバッチ実行エンジンが開示されている。米国特許出願Ｎｏ．１２／２３４，１１７の開示全体をここに参照することにより本稿において明示的に援用するものとする。

別の態様において、ＤｅｌｔａＶ（登録商標）バッチシステムのようなバッチエグゼクティブ環境は、一つの、または一つ以上のバッチが同じリソースを確保しようとする際に生じるコンフリクトを防止且つ解消するべく設備の調停を行う。例えば、「Method and System for Batch Process Arbitration in a Process Control System（仮訳：プロセス制御システムにおけるバッチプロセスの調停の方法とシステム）」と題されるシェリフらによる米国特許出願Ｎｏ．１０／９７２，１９２では、プロセス制御システムにおける設備の調停の方法とシステムが開示されている。米国特許出願Ｎｏ．１０／９７２，１９２の開示全体をここに参照することにより本稿において明示的に援用するものとする。但し、バッチ制御および設備の調停においてフレキシビリティを追加することにより、バッチエグゼクティブ環境の便宜および効率をさらに向上しうる。

本発明は、構成の手間を省くことができ、バッチ実行におけるフレキシビリティを向上させることができる、製品レシピを生成する方法を提供することを課題とする。

プロセス制御システムにおいて作動するバッチ実行環境は、ユーザが動的入力パラメータを含むレシピを定義することを可能にする。レシピを実行しているバッチは、レシピのある一ステップからレシピの別のステップに遷移する時、またはある一ステップ、動作またはフェーズの実行中に一つ又は複数の動的入力パラメータのために数値を得ることができる。レシピに一つまたは幾つかの動的入力パラメータを含むことにより、ユーザはレシピ論理外部の数値を参照することができ、それによってレシピを実行するバッチのフレキシビリティを向上させることができる。特に、ユーザは、各パラメータに対して数値を常に指定したり、オペレータの入力を促進するプロンプトを必要としたりすることなくレシピにパラメータを含むことができる。別の態様では、動的入力パラメータは、実行時中の作動条件の変更に合わせてバッチが効率的に調節されることを可能にする。

一実施形態において、動的入力パラメータは、設備フェーズ実行中または設備フェーズの完了時に設備フェーズから受信したレポート値を参照する。かかる動的入力パラメータを含むレシピを実行しているバッチは、報告レポートの一部として対応する設備フェーズから数値を受信し、該受信した数値をそれ以降のまたはそれに並列するフェーズに供給する。幾つかの実施形態において、バッチは、レシピの最高レベルの動作、ユニット手順またはステップ遷移論理など、別のレベルのレシピ論理に該受信した数値を供給する。

別の実施形態において、動的入力パラメータは、レシピの実行中にバッチエグゼクティブが外部モジュールまたはホストから受け取った数値を参照する。該数値は、例えば研究情報管理システム（ＬＥＭＳ）やウェブサービスなどから到達しうる。バッチエグゼクティブ内で作動するバッチマネージャ（バッチ管理ルーチン）は、該数値を実時間で受信し、レシピを実行している一つまたは幾つかのバッチランナー（バッチ実行ルーチン）へと該受信した数値を伝播する。あるいは、バッチランナーが、該数値が次のステップや動作またはフェーズの実行に必要とされる時にバッチマネージャを介して該数値を依頼するようにしても良い。

別の実施形態において、レシピは、一台の設備と関連するパラメータへの参照パスを含んでいる動的入力パラメータを使用する。例えば、動的入力パラメータは、混合タンクの容量を表しうる。しかるべく、レシピを実行するバッチは、レシピ実行の初めに、混合タンクが利用可能になった時に、または混合タンクの容量に対応する該数値が必要とされるレシピ実行ステップにバッチが達した時に混合タンクの容量を読み出しうる。さらに、レシピは特定のユニットまたは実行時中に選択されたユニットを参照しうる。動的パラメータは、よって複数のランタイム選択または計算後にのみ特定の数値になりうる。さらにまた、レシピは、一般に認められたバッチ生産原則と一貫しているユニットの分類、ユニット、設備、または特定のユニット内の制御モジュール、あるいは別のレベルの設備階層と関連する数値を参照しうる。

幾つかの実施形態において、バッチ実行環境は、ユーザが一つ又は複数のコマンド、設定点、コマンドパラメータ一式などを事前に定義して、例えばユニット動作、ユニット手順または手順など、レシピのいかなるレベルの一ステップと該事前に定義された一式を関連付けることも可能にする。よって、ユーザは、レシピのフェーズ・レベルに高レベルの論理を強いることなく、低レベルの標準レシピ構造またはプロセスコントローラでのみ現在利用可能であるアクション（個々の動作・処置）を定義且つプログラムできる。このように、ユーザは、構成の手間を省くことができ、バッチ実行におけるフレキシビリティを向上させることができる。

実施形態において、事前に定義されたコマンドセットは、例えばユニット手順または動作のレベルで行われるべき設備調停依頼を含みうる。ステップの一部として特定の設備調停依頼を必要とするレシピを実行しているバッチは、動作のフェーズの何らかを実行する前に物理的なリソースを効率的に確保する。このように、バッチ実行環境は、第１のバッチがこのリソースを使用している間に他のバッチが物理的なリソースに干渉できないことを保証する。

実施形態において、事前に定義されたコマンドセットは、レシピ論理のいかなるレベルで（例えばユニット手順または動作内などで）行われるべきユニット選択依頼を含みうる。レシピ論理内の選択された位置にユニット選択依頼を含むことにより、ユーザは、幾つかの候補ユニットを評価して特定の手順、動作またはフェーズに最も適しているユニットを選択するためにバッチを構成することができる。さらに、事前に定義されたコマンドセットは、選択されたユニットをバッチが実際に確保できることを保証するべく、ユニット選択依頼とそれ以降の調停依頼の両方を含みうる。さらにまた、事前に定義されたコマンドセットは、バッチがランタイム中にまたはそれ以外の場合はレシピ外部の論理から特定の選択基準のための数値を受信するようにユニット選択依頼の一部として動的入力パラメータを含みうる。

実施形態において、本開示のバッチ実行環境は、レシピ階層のいかなるレベルでもオペレータメッセージおよびプロンプトをサポートする。この実施形態によると、レシピを実行しているバッチは、例えばレシピのある一段階からレシピの別の段階に遷移時にプロンプトを示しうる。よって、フェーズ・レベルのみにオペレータメッセージとプロンプトを制限する概知のシステムと異なり、該バッチ実行環境では、オペレータメッセージまたはプロンプトがレシピの高位レベルステップから発するのでレシピを作成するために必要とされる構成の手間が少なくなる。

別の実施形態において、バッチ実行環境は、ユーザが設備または制御のモジュールを選択し、選択されたモジュールに対して一式のコマンドを定義することを可能にする。少なくとも幾つか実施形態において、ユーザは、コマンドセットの一部としてモジュールの異なる作動モードと様々なコマンドまたは一つ又は複数の設定点を関連付けることができる。レシピを作成する時、同じまたは異なるユーザが、コマンドセットを選択し、特定のレシピで使用する動作のモードとして希望するもの選択して、レシピ論理のいかなるレベルにてコマンドセットを効率的に挿入することができる。しかるべく、レシピを実行するバッチは、定義された一式のコマンドの適切なサブセットを対応する設備モジュールへと送りうる。このように、ユーザは、ユニット・フェーズを介してコマンドまたは設定点を設備に仕向ける必要はない。代わりに、ユーザは、例えば設備または制御モジュールで直接稼動するように一式のコマンドを構成しうる。

別の実施形態において、バッチ実行環境は、ウェブサービスを介してまたは別のタイプのメッセージング機構を使用することによりその他のシステムにコマンドを送信するレシピをサポートする。例えば、バッチ実行環境は生産実行システム（ＭＥＳ）にメッセージを送信しうる。特に、レシピに応じてプロセス制御システムにおいて実行されるバッチは、レシピ論理の手順レベル（即ち、最上レベル）で通信ステップを開始し、通信ステップの一部としてメッセージをＭＥＳへと送信し、ＭＥＳからの受信確認応答がプロセス制御システムに到着するまで実行を一時停止しうる。このように、本開示のバッチ実行環境では、ＭＥＳでバッチ実行を継続的に監視する必要がなくなる。

本開示の一実施形態と一貫するバッチ実行環境が動的レシピステップを実行しうるプロセス制御ネットワークの一部分の部分概略図を示す部分ブロック図である。 幾つかの論理的または地理的な領域と関連する製造設備がプロセス制御システムと交信を行う製造環境を示すブロック図である。 Ｓ８８標準と一貫しているレシピの入れ子構造を示すブロック図である。 バッチ実行制御の一般的な原則に応じてレシピのフェーズにより使用されるレシピおよび設備の関係を示すブロック図である。 バッチ実行制御の一般的な原則と一貫している設備エンティティの階層と製造環境において作動する幾つかの例示的な設備エンティティとの関係を示すブロック図である。 バッチ実行環境における構成サブシステムおよび幾つかの外部システムと交信を行うバッチサブシステムの代表的なアーキテクチャを示すブロック図である。 別の設備フェーズへの入力パラメータとして一設備フェーズにより生成された報告パラメータの使用を示すブロック図である。 特定のフェーズの入力および出力パラメータの操作用に本開示のバッチ実行環境がユーザに提示しうる例示的なインターフェース画面を示す図である。 特定のフェーズの報告パラメータを動作レベルパラメータに関連付けるために本開示のバッチ実行環境がユーザに提示しうる例示的なインターフェース画面を示す図である。 設備ユニットに特有なパラメータの動的選択を示すブロック図である。 製造設備ユニットの選択制御モジュールに特有な数値の動的選択を示すブロック図である。 レシピ階層の様々なレベルでの設備の調停を示すメッセージ順序表である。 事前に定義されたコマンドセット、設備調停依頼、ユニット選択依頼、オペレータ・プロンプト、または生産実行システム（ＭＥＳ）用メッセージを選択するためと、該選択を特定の選択されたレベルでレシピ論理に追加するために本開示のバッチ実行環境がユーザに提示しうる例示的なインターフェース画面を示す図である。 本開示の一実施形態と一貫しているバッチ実行環境が製造設備へのアクセスを調停しうるプロセス制御ネットワークを示す概略図である。

図１を参照するに、プロセス工場制御ネットワークまたはシステム１０は、例えばイーサネット（登録商標）通信接続１５を介して幾多のワークステーション１４に連結されているプロセスコントローラ１２を含んでいる。また、コントローラ１２も、（概して参照番号１６で指される）プロセス工場内の装置または設備に入・出力（Ｉ／Ｏ）装置（図示せず）および一式の通信回線またはバス１８を介して連結されている。
コントローラ１２は、一例に過ぎないがフィッシャー−ローズマウント・システムズ株式会社により販売されるＤｅｌｔａＶ（登録商標）コントローラでありえ、一つ又は複数のプロセス制御ルーチンを行い、それによってプロセス工場１６の所望の制御を実行するべくプロセス工場１６の全体にわたって分散されるフィールド装置およびフィールド装置内の機能ブロックなどの制御要素と通信可能である。これらのプロセス制御ルーチンは連続的またはバッチプロセス制御ルーチンまたは手順でありうる。一人又は複数のエンジニアまたはオペレータがワークステーション１４（例えばパソコン、サーバー、などでありうる）を使用して、コントローラ１２により実行されるプロセス制御ルーチンを設計したり、かかるプロセス制御ルーチンをダウンロードするべくコントローラ１２と通信したり、プロセス工場１６の稼動中にプロセス工場１６に関する情報を受信して表示したり、それ以外の場合はコントローラ１２により実行されるプロセス制御ルーチンとの交信を行ったりしうる。加えて、いかなる周知または所望の方法で、データ・ヒストリアン１９は、ＬＡＮ １５に接続されうるし、コントローラ１２、プロセス工場１６内のフィールド装置、さらにはワークステーション１４内を含み、工場１６内で生成されたデータを自動的に収集し格納しうる。

ワークステーション１４の各々は、構成設計用アプリケーションなどのアプリケーションを格納するため、且つプロセス工場１６の構成に関する構成データなどのデータを格納するためのメモリ２０を含んでいる。また、ワークステーション１４の各々は、その他数ある機能の中でも特にユーザがプロセス制御ルーチンを設計しコントローラ１２にそれらのプロセス制御ルーチンをダウンロードすることを可能にするアプリケーションを実行するプロセッサ２１も含んでいる。同様に、コントローラ１２は、プロセス工場１６を制御するのに使用するためのプロセス制御ルーチンおよび構成データを格納するためのメモリ２２を含み、且つプロセス制御法を実施するべくプロセス制御ルーチンを実行するプロセッサ２４を含んでいる。コントローラ１２がＤｅｌｔａＶ（登録商標）コントローラである場合、それはワークステーション１４の一つで実行される一人又は複数のアプリケーションと共に機能して、プロセス制御ルーチン内の制御要素とこれらの制御要素がプロセス工場１６の制御を提供するように構成される方法を示してコントローラ１２内のプロセス制御ルーチンの図形描写をユーザに提供しうる。

図１のプロセス制御システムは、製品レシピに応じて製品を生成するためのバッチプロセスを実行するのに使用されうる。例えば、ワークステーション１４のうちの一つは、プロセス工場１６内のバッチ運転を実施および調整するバッチエグゼクティブを実行しうる。稼動中、バッチエグゼクティブ３０は、一般に、遷移的論理により分けられたアクションの順序集合を含んでいるレシピを各バッチ運転に供給する。以下詳述の如く、アクションの順序集合は、各レシピが一つまたは幾つかのステップを含み、各ステップが一つまたは幾つかの動作を含み、そして各動作一つまたは幾つかのフェーズを含むように階層構造に対応する。本開示の方法および構造要素によれば、バッチエグゼクティブ３０は、レシピがレシピ論理外の数値を参照したりまたはレシピ実行の前回のまたは並列するフェーズから実行時中にパラメータ値を得たりすることを可能にする動的入力パラメータをサポートしたりする。言い換えると、プロセスエンジニア若しくは適切に権限を与えられたオペレータなどのユーザが、ワークステーション１４の一つでユーザーインタフェースを介してバッチエグゼクティブ３０にアクセスし、一連のアクション（例えば、容器槽中に原料を流し込み、それを混合して型の中に注ぎ、加熱する、など）、特定のアクションに対応する様々な確定パラメータ（例えば、１００ｌの水、１０分間混合する、など）、およびこれらまたはその他のアクションに対応する様々な動的パラメータ（例えば、前回のフェーズにより報告された量の生地を混合機＃５の中に流し込み、それを１．２５×センサ＃２７により測定された圧力に等しい時間（分）加熱し、タンクを選択して、選択されたタンクをタンク容量５０％まで充填する、など）を指定するレシピを作成しうる。フレキシビリティをさらに向上させるべく、バッチエグゼクティブ３０は、ユーザがコマンドまたは設定点一式を定義してこれら一式をレシピ階層のいずれかのレベルに関連付けることを可能にする。

引き続き図１を参照するに、プロセス制御システムのこの代表的な構成においてバッチエグゼクティブ３０がワークステーション１４ａに備えられている。その他の実施形態では、バッチエグゼクティブ３０を、その他のワークステーション１４に、またはいかなるワイヤレス様態を含むいかなる所望の方法でバス１５またはバス１８に通信可能に接続されたその他のコンピュータに格納して実行することも可能である。同様に、図５に関してより詳細に説明されているように、バッチエグゼクティブ３０は、様々な構成部分に分けても良い、またはプロセス工場１６内の異なるコンピュータまたはワークステーションに格納され実行される様々な構成部分と関連するようにしても良い。

また、当然のことながら、プロセス工場制御ネットワーク１０は二つ以上のバッチエグゼクティブ３０を含みうる。例えば、現時点において、最新の工場は、プロセス工場制御ネットワーク１０のリソースの幾つか又は全てを共有するバッチエグゼクティブを最大４つサポートする。一つ又は複数のバッチエグゼクティブ３０は、概してバッチサブシステムと呼ばれる場合もある。一方、構成サブシステムは、ユーザーインターフェイスツール、構成データベース、およびレシピの定義および編集、バッチ運転の性能の監視およびその他の運営上の目的に使用されるその他のハードウェア、ファームウェアおよびソフトウェア・モジュールを指す。なお、本説明中、「バッチエグゼクティブ」と「バッチサブシステム」という用語は置き換えても同じ意味を持つものとして使用されている。

稼動中、ユーザは、バッチ・オペレータ・インタフェース（「ＢＯＩ」）３２を操作して、レシピを定義したり、レシピを実行するバッチを作成したり、そしてバッチ実行を制御したりしうる。特に制御バッチ実行について、ＢＯＩ ３２は、ユーザがバッチ運転の開始、停止、一時停止、更新を行うことを可能にしうる。ＢＯＩ ３２は、イーサネット（登録商標）・リンク１５を介して、ワイヤレス・リンクを通じて、またはその他いかなる概知の様態で、バッチサブシステム３０と交信しうる。図１にはワークステーション１４の一部としてＢＯＩ ３２が概略的に描かれているが、その他の実施形態および配置方式も同様に可能性である。例えば、ＢＯＩ ３２は、携帯機器（図示せず）で、またはプロセス工場制御ネットワーク１０外部に配置されたホストでもワークステーション１４ａを実行しうる。さらに、同時に複数のオペレータをサポートするプロセス工場制御ネットワーク１０における様々なホストでインスタンス化されたＢＯＩ ３２のインスタンスが幾つかあるかもしれない。さらにまた、当然のことながら、プロセス工場制御ネットワーク１０は、レシピ構成およびバッチ操作にアクセスするためのユーザーインタフェース手段を二つ以上備えうる。一例をとるとＤｅｌｔａＶ（登録商標）システムがあるが、これは、その他数ある中でも特にＤｅｌｔａＶ（登録商標）オペレートおよびＤｅｌｔａＶ（登録商標）バッチ・オペレータ・インタフェースなどの構成部分を通してユーザーインタフェースを提供する。

図１に再び戻って説明すると、構成データベース３４は、バッチサブシステム３０用のレシピ、工場および設備階層における設備ユニットの一覧リストなどの機器データ、工場の様々な領域に関係する運用管理情報、設備ユニットの工場領域との関連性、設備の階層内訳およびその他の構成データを格納しうる。構成データベース３４は、バッチサブシステム３０とは別の構成サブシステムに備えうる。なお、構成データベース３４は、別のサーバーまたはサーバーの集団でありえ、または、プロセス工場制御ネットワーク１０が十分に小型の場合、構成データベース３４は、単にワークステーション１４または１４ａのファイル・システムの専用プロセスサービシング部分として実施されうる。

図１に示される例示的なプロセス工場制御ネットワーク１０において、コントローラ１２は、バス１８を介して類似して構成される二式の設備に通信可能に接続される。この場合、設備の各一式は、ここにおいてリアクタ＿０１（Ｒ１）またはリアクタ＿０２（Ｒ２）と呼ばれる反応装置ユニットと、ここにおいてフィルタ＿０１（Ｆ１）またはフィルタ＿０２（Ｆ２）と呼ばれるフィルタ・ユニットと、ここにおいて乾燥器＿０１（Ｄ１）または乾燥器＿０２（Ｄ２）と呼ばれる乾燥機ユニットとを有する。リアクタ＿０１は、反応器槽４０と、例えばヘッドタンク（図示せず）から反応器槽４０の中に流体を供給する流体入口配管を制御するように接続されている二つの入力バルブ４１および４２と、流体出口配管を介して反応器槽４０の流体の流れを制御するように接続されている出力バルブ４３とを含んでいる。装置４５は、例えば温度センサ、圧力センサ、液面レベル計測器などのセンサまたは電気ヒータまたは蒸気ヒータなどその他何らかの設備でありえ、反応器槽４０の中またはその近くに配置される。リアクタ＿０１は、乾燥機設備４９を備える乾燥器＿０１に連結されるフィルタ設備４７を備えるフィルタ＿０１にバルブ４３を介して連結されている。同様に、設備の第２の一式は、反応器槽４０Ａと、二つの入力バルブ４１Ａおよび４２Ａと、出力バルブ４３Ａおよび装置４５Ａとを備えるリアクタ＿０２を含んでいる。リアクタ＿０２は、乾燥機設備４９Ａを備える乾燥器＿０２に連結されるフィルタ設備４７Ａを備えるフィルタ＿０２に連結される。フィルタ設備４７と４７Ａおよび乾燥機設備４９と４９Ａは、それと関連付けられている付加的な制御要素（ヒータ、コンベヤベルトおよびそれ同等のものなど）や、センサなどを備えうる。図示されてはいないが、望ましい場合には、フィルタ・ユニットであるフィルタ＿０１とフィルタ＿０２の各々を反応装置ユニットであるリアクタ＿０１とリアクタ＿０２の各々に対して物理的に連結する一方で、乾燥機ユニットである乾燥器＿０１および乾燥器＿０２の各々をフィルタ・ユニットであるフィルタ＿０１とフィルタ＿０２の各々に連結し、それによって、反応装置、フィルタおよび乾燥機の各々の一つを用いるバッチ運転によって図１に示される設備のいかなる組合せを使用できるようにしても良い。

図１に示される如く、コントローラ１２は、バルブ４１−４３，４１Ａ−４３Ａに、装置４５，４５Ａに、フィルタ４７，４７Ａにそして乾燥機４９と４９Ａに（およびそれと関連付けられている他の設備に）、バス１８を介して通信可能に連結されており、これら要素（ユニット、フィールド装置などでありうる）に関する一つ又は複数の動作を行うべくこれら要素の動作を制御する。かかる動作には、例えば、反応器槽または乾燥機の充填、反応器槽または乾燥機内の材料の加熱、反応器槽または乾燥機の中身の排出、反応器槽または乾燥機の清掃、フィルタの操作、などが含まれる。もちろん、コントローラ１２は、付加的なバスを介して、例えば４−２０ｍａ配線、ＨＡＲＴ通信回線など、専用の通信回線を介して、プロセス工場１６内の要素に連結することも可能である。

図１に示されるバルブ、センサおよびその他の設備は、例えば、フィールドバス・フィールド装置、標準４-２０ｍａフィールド装置、ＨＡＲＴフィールド装置などをはじめとするいかなる所望の種類またはタイプの設備であえ、例えばフィールドバス・プロトコル、ＨＡＲＴプロトコル、４-２０ｍａアナログ・プロトコルなど、いかなる周知または所望の通信プロトコルを使用してコントローラ１２と通信するようにしても良い。さらにまた、その他のタイプの装置を、所望のいかなる方法にて、コントローラ１２に接続し、コントローラ１２により制御しうる。また、例えばイーサネット（登録商標）通信回線１５を介して他のコントローラをコントローラ１２およびワークステーション１４に接続して、プロセス工場１６と関連付けられているその他の装置または領域を制御するようにしても良く、この場合、かかる付加的なコントローラの動作を、いかなる所望のまたは周知の様態において図１に示されるコントローラ１２の動作に合わせるようにしても良い。

ユーザは、レシピを定義および編集したり、設備を構成したり、装置バルブ４１−４３および容器槽４０などのプロセス制御装置から設備系列を形成したり、バッチに設備系列を関連付けたり、且つ、ＢＯＩ ３２またはその他のインターフェースツールを介してバッチサブシステム３０と交信したりしうる。ＢＯＩ ３２は、システムにおいて定期的にまたは実時間で実行される各バッチの状態を読み出しうる。ネットワーク１０のバッチ実行環境、そして特にＢＯＩ ３２と協働するバッチサブシステム３０により、ユーザが動的パラメータおよび事前に定義されたコマンド・ステップでレシピを構成することが可能になる。

同時バッチ運転に使用されるプロセス制御システムとプロセス制御装置の関係をより良く示すべく、図２は、（例えば論理的または地理的な原則に応じた）設備編成および設備の調停の観点から図１のプロセス工場１６を示す。特に、プロセス工場１６は、一つ又は複数の領域５４、一つ又は複数のリソース５６、および一つ又は複数のリソース・ユーザ６０を含んでいる。領域５４は、プロセス工場１６、リソース５６およびリソース・ユーザ６０の論理的且つ又は物理的な編成を表す。一般に、領域５４は、工場１６において使用されるレシピのステップを実行する際に使用されるリソース５６を編成するのに使用される。領域５４の編成は、工場１６におけるリソース５６の物理的位置、工場１６におけるリソース５６の論理編成、またはリソース５６の物理的および論理的編成の組合せなど、それぞれ適したものに基づきうる。例えば、バッチ処理動作は、受入れ、準備、処理および出荷に対して別々の領域５４に分割されうる。例えば、薬物生成プロセス用の原材料が、受入領域において受け取られ、準備領域において変えられ、処理領域において標的製薬を作るために混合、処理された後、該標的の製薬が包装され出荷領域から出荷される。領域５４におけるリソース５６は、異なる製薬を作るのに使用される各種機器など、異なるタイプの最終製品を生産する一環として使用されうる。また、一実施形態において、領域５４は、システム１０用のリソース５６およびリソース・ユーザ６０が一つの集団として取り扱うには多過ぎるといった問題に対する現実的解決案を提供する。領域５４は、大規模なレシピの処理を分割するのに使用されうるので、プロセス制御システム１０が、その他のプロセス監視作業を実行する間に多数のリソース５６を管理するのに必要とされるが故に速度が低下するといったことがなくなる。例えば、工場全体１６にわたって管理するべき対話処理が多いとコントロールシステム５２の処理能力が圧倒される場合があるが、工場１６全体を別々の領域５４に分けることによって対話処理の数を減らすことができる。

リソース５６は各バルブ、タンク、ポンプ、コンベヤベルト、混合機、ヒータ、または工場１６において行われる工程の一部として使用可能なその他の適切な装置を構成しうる。リソース５６は、様々な時点で、異なるリソース・ユーザ６０によりバッチプロセスの異なる部分において使用されうる。例えば、特定のヒータ・リソース５６を、１つの最終製品用の第１の物質と使用してから清掃し、後で異なる最終製品用に第２の物質に使用しても良い。

リソース・ユーザ６０は、リソース５６を使用する物理的または論理的なエンティティを表す。例えば、ユーザ６０は、特定の製品を生産する特定の順番でリソース５６を使用するプロセス制御システム１０により実行される特定のレシピを表しうる。例えば、ポンプ・リソースは、ポンプ・リソースが特定の材料でタンク・リソースを充填できるようにタンク・リソースへのアクセスを依頼する時にリソース・ユーザの役割を果たしうる。さらに、リソース・ユーザ６０は、原材料など、生産工程自体の一部として使用される材質を表しうる。例えば、第１の物質をレシピの一部としてのヒータに移動させるべく、現在タンクに貯蔵されている第１の物質がポンプへのアクセスを依頼しうる。また、リソース・ユーザ６０は、プロセス制御システム１０により直接制御されていないがプロセス制御システム１０からリソース５６へのアクセスを依頼しうる人間またはその他のエンティティでありうる。一般に、リソース・ユーザ６０は、プロセス制御システム１０の制御下に製品を生産するために工場１６により採用される人間、材料、ハードウェア、ソフトウェア且つ又は他のリソース５６でありうる。

稼動中に一人又は複数の人間のユーザ（図示せず）は、プロセス制御システム１０を使用して一つ又は複数のレシピ、バッチプロセスまたはその他の工程の実行を構成、制御、且つ監視しうる。レシピは、一つ又は複数の所望の最終製品を生成するためにプロセス工場１６で利用可能なリソース５６を使用して実行される。プロセス制御システム１０は、二人（２つ）のユーザ６０が同じリソース５６を同時に使用しようとしないように、リソース・ユーザ６０によるリソース５６へのアクセスの制御をつかさどる。異なるレシピに対して同じリソース５６が同時に使用されると、処理されている材料の汚染が生じる原因となる場合があり、製品を破棄することが必要になったり、またはその他の芳しくない結果がもたらされたりしうる。プロセス制御システム１０は、例えば米国特許出願Ｎｏ．１０／９７２，１９２により詳細に記述されているように、複数ユーザ６０からのリソース５６使用依頼間で調停することによりリソース５６へのアクセスを制御する。

上記の如く、バッチサブシステム３０は、ユーザがプロセス工場内で実行される複数のバッチ運転を指定することを可能にするとともに異なるバッチ運転を実施するべくプロセス工場制御ネットワーク１０内で本質的に独立して作動するように複数の異なるバッチ運転またはバッチプロセスを設定する高レベルの制御ルーチンを含んでいる。かかるバッチプロセスは各々、プロセス工場内の反応装置ユニット、フィルタ・ユニット、乾燥機ユニットまたはその他の設備の一つなどの単一ユニットで作動するサブルーチンまたは工程である一つ又は複数のユニット手順の動作を仕向ける。（一般にワークステーション１４の一つで実行されるバッチ運転の一部である）各ユニット手順は、（それぞれがユニット上で一つ又は複数のフェーズを行いうる）一連の動作を実行しうる。これを説明するに、一般に、フェーズは、ユニット上で実行される最下レベルのアクションまたはステップで、コントローラ１２の一つにおいて実施または実行され、動作は、ユニット上で特定の機能を実行する一式のフェーズであり、一般にコントローラ１２内の一連のフェーズを呼び出すことによりワークステーション１４の一つで実施または実行されるが、ユニット手順は、単一ユニット上で実行される一つ又は複数の一連の動作であり、一般にワークステーション１４の一つで一式の動作呼出しとして実施される。結果として、いかなるユニット手順は一つ又は複数のフェーズ且つ又は一つ又は複数の動作を含むことができる。このように、各バッチプロセスは、例えば食品製品や薬剤などの製品を生産するのに必要な異なるステップまたは段階（即ちユニット手順）を実行する。

個々のバッチのための異なるユニット手順、動作およびフェーズを実施するべく、バッチプロセスは、実行されるべきステップ、およびステップおよびステップの順序と関連する量および時間を指定する一般にレシピと呼ばれるものを使用する。１つのレシピのステップには、例えば、反応器槽を適切な材料または原料で充填すること、反応器槽内の材料を混合すること、反応器槽内の材料を特定の時間、特定の温度に加熱すること、反応器槽を空にしてから次のバッチの準備をするために反応器槽を清掃すること、反応装置の出力を濾過するためにフィルタを稼動してから反応器槽において作られた製品を乾燥するために乾燥機を稼動することが含まれているかもしれない。異なるユニットと関連する一連のステップの各々はバッチのユニット手順を定義し、バッチプロセスは、これらユニット手順の各々に対して異なる制御アルゴリズムを実行する。もちろん、特定の材料、材料の量、加熱温度および時間などは異なるレシピによって異なりうるので、これらのパラメータは、製造または生産されている製品および使用されるレシピによってバッチ運転ごとに変わりうる。図１に示される反応装置ユニット、フィルタ・ユニットおよび乾燥機ユニットを使用するバッチに関して制御ルーチンと構成がここに記載されているが、その他所望のバッチプロセスの運転を実行するためまたは希望に応じて連続プロセス工場運転を実行するためにその他所望の装置を制御するのにも制御ルーチンを使用しうることは当事者であれば理解できるはずである。

また、一般的な（ジェネリックな）バッチプロセスの同じフェーズ、動作またはユニット手順を、図１の異なる反応装置ユニットの各々で異なる実際のバッチプロセスの一部として同時にまたは異なる時点で実施できることも当事者であれば理解できるはずである。さらに、図１の反応装置ユニットが一般に同じ数とタイプの（即ち、同じユニットクラスに属する）設備を含んでいるので、特定のフェーズのための同じジェネリックフェーズ制御ルーチンを異なる反応装置ユニットの各々を制御するのに使用しうる。但し、このジェネリックフェーズ制御ルーチンを異なる反応装置ユニットと関連する異なるハードウェアまたは設備を制御するために修正変更しなければならない。例えば、リアクタ＿０１のための充填フェーズ（反応装置ユニットが充填されるフェーズ）を実施するべく、充填制御ルーチンは、特定の時間（例えば容器槽４０が満杯であることを液面レベル計測器４５が検知するまで）入力バルブ３１または４２の一つ又は複数を開く。但し、単に入力バルブの名称をバルブ４１または４２の代わりにバルブ４１Ａまたは４２Ａに変えることにより、且つ液面レベル計測器の名称を液面レベル計測器４５の代わりに液面レベル計測器４５Ａに変えることにより、この同じ制御ルーチンをリアクタ＿０２のための充填フェーズを実施するのにも使用しうる。

バッチ運転の一般的な動作と関連する論理は周知のものであるが、図３−５は、代表的なレシピの構造、レシピおよび対応する製造設備間の交信、およびバッチ生産の一般的な原則と一貫する設備階層の総合情報要約を提供する。

特に図３は、バッチ実行環境におけるオンライン・レシピ同期化の方法に関係のあるレシピ構造を示す。レシピ２５５はＳ８８標準の階層構造との適合性を有する。但し、オンライン・レシピ同期化の方法をその他既存のおよび将来的なレシピ定義標準にも適用しうることは、当業者であれば十分に理解できるはずである。図３に示される如く、レシピ２５５は、遷移２５７により分けられたステップ２５３および２５５など、一つ又は複数のステップを含んでいる。レシピ２５５のステップの各々は複雑な内部構造を有しうるし、別のユニット手順として定義されうる。例えば、ステップ２５５はユニット手順２６０として定義されうる。

遷移２５７は、遷移２５７に後続するステップ（この場合ステップ２５５）を実行する前にステップ２５３内で満たさなければならない条件を指定しうる。例えば、ステップ２５３が二つの化学薬品の混合を実行し、条件２５７の混合時間が２分の時間制限を越えたかどうか確認するようにしうる。別の実施例としては、ステップ２５３を実行した結果に関係なく遷移に影響するために遷移２５７をブーリアンの「真」に設定しうる。一般に、該条件は単一または複合のものでありうるし、「AND」や「OR」などのブーリアン演算子を含みうる。それに対してユニット手順２６０は、同様に条件２５７により分けられた一つ又は複数の動作２６３または２６５を含みうる。図３に示される実施例において、動作２６３は動作定義２７０に応じて実行される。動作定義２７０は、条件２５７により分けられた一つ又は複数のフェーズ２７２および２７４を含みうる。

図４を参照するに、レシピ２５０はフェーズ論理インターフェース２８２を介してユニット・フェーズ２８０と交信しうる。説明を明瞭にする目的で、図４には、一つ又は複数のユニット手順２６０を含むレシピ手順としてレシピ２５０の一般的な（ジェネリックな）画像表現も含まれている。この際、該一つ又は複数のユニット手順２６０には、一つ又は複数のフェーズ２７２−２７４を有する一つ又は複数の動作２７０が含まれうる。ここにおいて使用されるように、記号２８５は、二つのクラスまたはインスタンスの一対多数の関係を概略的に表す。図４に示される如く、各ユニット・フェーズ２８０は、一つまたは幾つかの制御モジュール２９２をそれぞれがカプセル化している一つまたは幾つかの設備モジュール２９０に携わる（即ち、それを実行し続ける）。

一般に、制御モジュール２９２は、プロセス制御システムにおける一つの論理エンティティとして作動する装置のグループ化を含んでいる。例えば、フィードバック制御用のコントローラ、特定のバルブ上で作動するバルブアクチュエータおよび流量計を含む要素が相互に接続された集団は、単一制御モジュールを定義しうる。これは、これらの装置は、高レベルの観点から、プロセス制御システム１０における特定の制御機能を提供しうるからである。

その間、設備モジュール２９０は、順序制御（即ち複数の制御関数）を含む特定の処理関数を実行する。例えば、特定の設備モジュール２９０は、特定のパイプラインを通して被ＰＩＤ制御フローを提供する制御モジュール２９２と、被制御フローを幾つかの仕向け先パイプラインの一つに選択的に仕向ける別の制御モジュール２９２を含みうる。別の実施例として、設備モジュール２９０は、例えば制御ポンプモジュールやバルブ制御モジュールなど幾つかの制御モジュール２９２を含む材料フィーダーでありうる。

引き続き図４を参照するに、レシピ２５０は、フェーズ論理インターフェース２８２を介してコマンドを送りレポートを受け取ることによりユニット・フェーズ２８０と交信する。各レポートは、フェーズ実行の単純論理式の結果が含みうる、または、フェーズ実行中に生成された一つまたは幾つかの数値計測またはその他の数値を伝えうる。一般に、設備フェーズ２８０は、プログラム可能論理制御装置（ＰＬＣ）または分散型コントロールシステム（ＤＣＳ）構成部分を使用するフェーズ論理のみをサポートする。周知の如く、ユニット・フェーズ２８０は、ユニット・フェーズを定義すべくユニット上で、または「設備フェーズ」とも呼ばれる設備モジュール・フェーズを定義すべく設備モジュール上で実行しうる。よって、レシピ２５０と、レシピ２５０に従ってバッチを実行することに関与する設備は、コマンドおよび実時間レポートまたは事後レポートを交換することによって交信する。

ここで図５を参照するに、完全設備階層３００は、会社またはその他のタイプの事業組織に対応する企業レベル３０２を含む。企業ノード３０２は、幾つかの拠点またはプロセス工場の位置３０４を含みうる。一般にプロセス工場のサイズは大規模であるため、各拠点３０４をさらに諸領域３０６に分けても良い。一方、領域３０６は、幾つかのプロセス・セル３０８を含みうる。

引き続き図５を参照するに、プロセス・セル３０８は、例えば自動クッキー製造工場のクッキー生地準備段階３１０に対応しうる。段階３１０は、階層３００中のユニット３１４に対応する二つの混合機３１２を含みうる。さらに、各混合機３１２は、設備モジュール３１８に対応する一つまたは幾つかのフィーダー３１６を含みうる。また、各フィーダー３１６は、制御モジュール３２２である一つまたは幾つかのポンプまたはバルブ３２０を含みうる。最後に、図５に示される如く、制御モジュール３２２は、一般に一つまたは幾つかの制御要素３２４（例えば、流量計、圧力センサ、など）を含んでいる。

よって、図３〜図５を参照して上述される如く、より具体的に言うと、プロセス制御システム１０は、図３に示される構造と一貫しているレシピをサポートし、図４および図５に示される階層に従って設備を編成する。但し当然のことながら、Ｓ８８標準と一貫しないまたは部分的にのみ一貫しうるその他のバッチ実行環境においても同様にプロセス制御システム１０が本開示の動的入力パラメータおよび事前定義のコマンド・ステップをサポートしうることは理解されるであろう。よって、動的入力パラメータおよび事前定義のコマンド・ステップを図３〜図５に示される原則と概して一貫しているプロセス制御システム１０を参照して以下説明するが、当然のことながら、プロセス制御システム１０およびプロセス工場１６がこれらの方法を適用しうる環境の一実施例に過ぎないことは理解されるであろう。

図６は、プロセス工場制御ネットワーク１０におけるバッチサブシステム３０の代表的なアーキテクチャを示す。バッチ・エグゼクティブ・サブシステム３０は、イーサネット（登録商標）通信接続１５を介して、あるいはバッチサブシステム３０とユーザーインタフェース３２が同じワークステーション１４または１４ａに備えられている場合には概知のプロセス間通信（ＩＰＣ）手段の一つを介して、ＢＯＩ ３２などのユーザーインターフェイスツールと交信しうる。バッチサブシステム３０は、バッチマネージャ３８２、バッチ実行時プロセス３８４および１つまたは複数のバッチランナー３８６〜３９０を含みうる。バッチサブシステム３０の処理の各構成部分は、独立処理またはスレッドとして実施されうる。上記の如く、バッチサブシステム３０は幾つかのワークステーションまたは他のホストにわたり分散されうる。

バッチランナー３８６〜３９０の各々は、きっかり１つのバッチを実行する。バッチランナー３８６〜３９０の幾つかは、同じレシピ（例えばレシピ２５０など）を実行しうる。当然のことながら、バッチランナー３８６〜３９０の各々が同じレシピを実行していても、バッチランナー３８６〜３９０が常に同じ実行状態である必要のないことは理解されることであろう。図６に示される実施例では、バッチランナー２９０がイーサネット（登録商標）接続１５を介してコントローラ１２に接続されている。稼動中、バッチランナー３９０は、対応するワークステーション１４または１４ａ上のプロセス空間においてユニット手順と動作のレベルで論理を実行しうる。但し、バッチランナー３９０は、コントローラ１２に各動作のフェーズ２７２および２７４を読み込む。

再び図６に戻って説明すると、永続的格納ユニット３９２は、バッチランナー３８６〜３９０の各々に関する状態、遷移およびパラメータ情報を確保しうる。永続的格納機構３９２は、ワークステーション１４または１４ａの一つに備えられているハードディスク・ドライブ、ＣＤまたはＤＶＤなどの外部記憶装置、またはその他概知のデータ記憶装置でありうる。バッチマネージャ３８２、バッチ実行時プロセス３８４、およびバッチランナー３８６〜３９０の各々は、イーサネット（登録商標）接続１５を介してまたは永続的格納機構３９２が同じホスト上に備えられている場合ＩＰＣ呼出しを通して永続的格納機構３９２へのアクセスを有しうる。稼動中、バッチランナー３８６〜３９０の各々は、対応するバッチの実行状態と関係する情報を保存する。例えば、バッチランナー３９０は、現在実行されているユニット手順、動作およびフェーズの状態を記録しうる。よって、永続的格納ユニット３９２内の記録は、現在バッチランナー３９０がレシピ２５０のステップ３、動作１、フェーズ２を実行していることをある時点で示しうる。加えて、各レベルの記録は、各レベルの状態（例えば実行中、保留中または中断、など）を指定しうる。さらに、バッチランナー３９０は、ユニット手順、動作およびフェーズに受け渡されたパラメータ値を記録しうる。バッチランナー３９０は、実質的に実時間で永続的格納ユニット３９２を更新するものが好ましい。

加えて、バッチランナー３９０は、例えばステップ２５３と２５５間、動作２６３と２６５間、およびフェーズ２７２と２７４間での各遷移２５７を記録しうる。状態とパラメータ情報とともに遷移を永続的格納機構２９２に記録しうる。あるいは、別のイベント・ログがデータ・ヒストリアン１９に格納されるとともに、状態遷移を記録しうる。また、イベント・ログは、パラメータ情報の幾つか又は全て、および各遷移と関連するタイムスタンプ、エラー条件、および事後にシステムを監視またはデバッグするのに役立つその他の情報などの追加情報も含みうる。同様にイベント・ログは同期化指標を格納しる。例えば、イベント・ログ内の特定の記録には、バッチランナー３９０が９月２１日の１４：２５にステップ３、動作１、フェーズ１でレシピ「チョコレート＿クッキー＿００１」のバージョンＶ２と再度同期化したことを示しうる。

上記の如く、バッチマネージャ３８２は、バッチランナー３８６〜３９０の実行を制御する。特に、バッチマネージャ３８２は、いつ実行を開始するか、停止するか、または一時停止するかをバッチランナーに示すコマンドをバッチランナー３８６〜３９０に送信する。加えて、バッチマネージャ３８２は、ユーザーインターフェイスツール３２を介してオペレータにバッチランナー３８６〜３９０の各々の状態を報告する。例えば、バッチマネージャ３８２は、バッチランナー３９０の状態を読み出すべく永続的格納機構３９２にアクセスしうるし、ＸＭＬなど周知のフォーマットまたはバッチサブシステム３０の要素間の交信用に特別に定義されている特殊用途のフォーマットと一貫しているメッセージの形でインターフェースツール３８０に状態を報告しうる。この意味において、バッチマネージャ３８２は全てのバッチランナーにとって集中型ゲートウェイとして機能する。

一実施形態において、上記に加えバッチマネージャ３８２およびバッチランナー３８６〜３９０がバッチサブシステム３０により現在実行されているレシピのコピーを格納している共有メモリ領域へのアクセスを有する。共有メモリ領域は、永続的メモリまたは揮発性メモリの格納位置でありうるし、バッチサブシステム３０の内部またはその外部に配置されうる。幾つかの実施形態において、バッチマネージャ３８２は、バッチランナー３８６〜３９０の一つによりレシピの実行をトリガする前に各レシピのコピーを保存する。他の実施形態において、個々のバッチランナーが、残りのバッチサブシステム３０には不明であるまたはアクセスできない永久的格納位置に、またはそれ自身のプロセス空間にレシピのコピーを保存する。いずれの場合も、バッチサブシステム３０は、各レシピを一つのファイルとしてまたは要素の階層構造として格納しうる。バッチマネージャ３８２と、バッチランナー３８６〜３９０の各々が、読取りおよび書込み用のユニット手順、動作およびフェーズなど個々のレシピ要素にアクセスする手段を備えていることが好ましい。

その間、バッチ実行時プロセス３８４は、残りのプロセス工場制御ネットワーク１０とのインターフェースとして機能する。特に、バッチ実行時３８４はレシピ・ダウンロードスクリプトを通して構成データベース３４と交信しうる。一実施形態において、ユーザーインタフェース３２は、人間可読性と機械可読性の両方を可能にするためにＸＭＬでレシピをパッケージ化する。またその代わりとして、ユーザーインタフェース３２、バッチサブシステム３０および構成データベース３４がいかなる標準またはプロプライエタリの（独自の仕様による）プロトコルを通じてスクリプト情報を送信しうる。また、バッチ実行時プロセス３８４は、システム・セキュリティの維持およびログの保守保全のような機能をつかさどりうる。なおまた、バッチ実行時プロセス３８４は、開始や停止、そしてその他該当する適切な高レベルの情報を永続的格納機構３９２または構成データベース３４に記録しうる。

引き続き図６を参照するに、バッチマネージャ３８２は、研究情報管理システム（ＬＩＭＳ）３９６およびウェブサービス３９８とも通信しうる。ＬＩＭＳ ３９６は、個別領域に備えられ、例えば、イーサネット（登録商標）またはインターネット接続を介してを通信しうる。ＬＩＭＳ ３９６は、計測や設定点、あるいはその他のタイプの値を、構成データベース３４における幾つか又は全てのレシピにおいて使用するためにバッチエグゼクティブ３０へと供給しうる。同様に、ウェブサービス３９８は、例えば遠隔のオペレータからデータを供給しうる。また、バッチエグゼクティブ３０は、レシピにおいてウェブサービス３９８から受け取った値を使用しうる。なお、ＬＩＭＳ ３９６、ウェブサービス３９８、またはバッチマネージャ３８２に接続されているその他いかなる外部モジュールは各々、実時間で、またはバッチランナー３８６〜３９０の一つにより始動されたポーリングまたはクエリーに応答してデータを提供しうる。

上記に簡潔に述べられている如く、プロセス制御システム１０（より具体的にはバッチエグゼクティブ３０）は、レシピ論理の様々なレベルで動的入力パラメータおよび事前定義コマンド・ステップをサポートし、それによって、よりフレキシブルであるとともにプロセス工場１６における変化への適応性が向上した製品レシピをユーザが作成できるようになる。図７はかかる動的パラメータ関数の１つを示し、図８および図９は、ＢＯＩ ３２がこの機能性の使用を円滑にするために備えられているかもしれないユーザーインタフェースを示す。図１０および図１１には、それ以外に仮想される事態で本開示の動的入力パラメトリック関数に関係するものの二例が示されている。図１２は、本開示の方法およびシステムに従ってレシピ論理の幾つかのレベルで行われる設備調停および設備選択を示す。また、図１３は、ユーザが事前定義コマンドや調停依頼などを効率的にレシピに追加できるようにするための、ＢＯＩ ３２がサポートしうるユーザーインタフェースの一実施例を示す。

図７を参照するに、特定のレシピが、フェーズ４０２−４０８を含む動作４００（ユニット手順にカプセル化されたり、または、高レベルのレシピ論理に直接リンクされていたりするもの）を含みうる。フェーズ４０２の完了に際して、動作４００は、フェーズ４０４に遷移し、対応する設備フェーズ４１２へとバッチ入力パラメータ４１０を供給しうる。例えば、フェーズ４０４は、設備フェーズ４１２中に処理された材料を加熱する温度、または設備フェーズ４１２中の混合機が、前回のフェーズ４０２中に準備された原料の混合に際して作動する時間（分）を指定しうる。次に、設備フェーズ４１２は、単一の出力またはレポートパラメータ４１４、または複数の出力またはレポートパラメータ４１４を、実行時中に、または設備フェーズ４１２の完了に際して報告しうる。引き続き上記実施例を参照して説明すると、該出力パラメータは、設備フェーズ４１２の実行中に収集された温度計測値の平均または、設備フェーズ４１２中に混合機により生産されたガロン数でありうる。

受信した出力パラメータ４１４を、ロギングする目的でデータ・ヒストリアン１９やユーザーインタフェース３２または他のモジュールに伝播することに加えて（また場合によっては、その代わりに）、動作４００は、例えば設備フェーズ４１６など他の設備フェーズへの入力パラメータに出力パラメータ４１４を関連付けうる。図７は、動作４００経由にてパス４１８を通じた他のフェーズへの入力パラメータとの出力パラメータ４１４の関連性を概略的に示す。言い換えると、動作４００は、入力パラメータを動作論理のレベルで出力パラメータに「参照」し、それによって一つまたは幾つかの先行フェーズまたは並列するフェーズを考慮してフェーズの動的制御を行うこと可能にしうる。

図８は、図７を参照して上述されるように動的入力パラメータを構成するために、そして特に他のフェーズの入力パラメータにフェーズの出力またはレポートパラメータを関連付けるためにユーザがユーザーインタフェース３２を介してアクセスしうるところの例示的なインターフェース画面４４０を示す。インターフェース画面４４０は、レシピレベル選択用ウィンドウ枠４４２、レシピ論理構成用ウィンドウ枠４４４およびパラメータ構成用ウィンドウ枠４４６を含みうる。ユーザは、レシピレベル選択用ウィンドウ枠４４２においてレシピ、ユニット手順、動作またはフェーズを選択し、選択されたモジュール上でダブルクリックすることによりまたは類似した制御をアクティブにすることによりモジュールの論理を閲覧または編集の目的でレシピ論理構成用ウィンドウ枠４４４に読み込みうる。同様に、ユーザは、パラメータ構成用ウィンドウ枠４４６内でパラメータをハイライト表示してから、例えば、ボタン４５０をアクティブにすることにより該ハイライト表示されたパラメータを選択しうる。

図８に示される如く、ユーザはウィンドウ枠４４４においてフェーズ４６０を選択しても良く、且つ、パラメータ構成用ウィンドウ枠４４６はそれに応じて該選択されたフェーズ４６０と関連する幾つかの入力およびパラメータを表示しうる。この実施例において、フェーズ４６０は、二つの入力パラメータ４７０と４７２を受信して、二つの出力パラメータ４８０および４８２を出力または報告する。出力パラメータ４８０を例えば他のフェーズへの入力パラメータと関連付けて図７に示される構成を可能にするために、ユーザはしかるべく出力パラメータ４８０をインターフェース画面４４０且つ又は一つまたは幾つかの派生的画面を介して構成しうる。特に、ユーザは、出力パラメータ４８０のハイライト表示およびセレクトボタン４５０のアクティブ化により、図９に示されるパラメータ構成メニュー５００をアクティブ化しうる。

ここで図９を参照するに、インターフェース画面５００が、パラメータ特性の構成専用に設けられており、パラメータ名識別子フィールド５０２、カテゴリーリスト選択子５０４、宛先リスト選択子５０６、標的リスト選択子５０８などを含みうる。通常の技術を有する当業者の一人であれは、インターフェース画面５００が付加的な情報フィールド、入力フィールドおよびリストから選択可能な選択肢を含むことも可能であり、またはその逆に図９に示されるものよりも少ないフィールドおよび選択子を含みうることは十分に理解できるはずである。この実施例において、インターフェース画面５００は、ユーザが、選択されたパラメータ「「ＰＨ＿出力＿パラメータ１」」または図８を参照して上述される出力パラメータ４８０を標的動作レベルパラメータＯＰ＿ＰＡＲＡＭ１（これはユーザが標的リスト選択子５０８内に見つけられるものでありうる）に仕向けることを可能にする。幾つかの実施形態において、所望のパラメータが標的リスト選択子５０８に含まれていない場合、ユーザは新規標的パラメータを定義しうる。この場合、インターフェース画面５００は、標的パラメータを定義且つ構成するために一つまたは幾つかのユーザダイアログをトリガしうる。

宛先リスト選択子５０６は、例えば「委託」パラメータまたは「参照」パラメータなどの選択を含みうる。図９の例示的なにおいて、ユーザは、出力パラメータ４８０に標的「動作＿パラメータ＿１」をマッピングするために（言い換えると、出力パラメータ４８０の値を自動的に「動作＿パラメータ＿１」パラメータに供給するために）「参照」の選択肢を選択する。これらの構成ステップの完了に際して、ユーザは、制御５１０をアクティブ化することにより変更を受け入れても、あるいは制御５１２を介して変更をキャンセルしうる。

次に、ユーザは、例えば他のフェーズの入力パラメータに「動作＿パラメータ＿１」パラメータを関連付けることを希望するかもしれない。この目的を達成するために、ユーザは、他のフェーズを選択して他のインターフェース画面（図示せず）をトリガしうる。このインターフェース画面によって、ユーザが「動作＿パラメータ＿１」を選択して動作レベルパラメータ「動作＿パラメータ＿１」およびフェーズ入力パラメータの逆連想を構成することが可能になるだろう。言い換えると、ユーザは、画面４４０と５００に類似する対話画面の一つまたは幾つかを操作して、フェーズ入力パラメータを動作レベルパラメータ「動作＿パラメータ＿１」へと「委託」しうる。

幾つかの実施形態において、ユーザは、レシピ階層のさらに上にある「ＰＨ＿出力＿パラメータ１」の値を、例えばフェーズ・レベルではなく動作またはユニット手順のレベルで処理されるように伝播することもできる。よって、当然のことながら、図７〜図９を参照して説明された仮想事態が一例としてのみ提供されていることや、レシピ論理のその他のレベルを通り過ぎる類似したパラメータも考慮されていることは理解されるであろう。

図１０は、他のタイプの動的入力パラメータを使用するレシピのフラグメントを示す。具体的に言うと、レシピ５３０は、特定のユニットおよびユニットと関連する特定のパラメータの選択に際して実行時中にのみ数値になる参照パスを持つ動的パラメータを含んでいるユニット手順５３２を含みうる。ユーザは、パラメータ「選択＿ユニット／能力」をユニット手順５３２に含み、それによって、バッチランナー３８６〜３９０が例えば（図６を参照すると）候補集合５５０の中から適切なユニットを選択して「選択＿ユニット／能力」が特定の値になるようにしうる。図１０に示される実施例において、バッチランナーは、（識別子「ユニット＿０２」に関連付けられている）ユニット５５２を選択し、パラメータ集合５６２から「能力」パラメータ５６０を読み出す。引き続き上記実施例を参照して説明すると、ユニット５５２の「能力」は、ユニット５５２に含まれている一次混合タンクの物的能力に対応させても良く、例えば１０００ガロンでありうる。パラメータ５６０の値「１０００」を読み出すべく、ユニット手順５３２は、ユニット５５２に出力パラメータを介してパラメータ５６０の値を報告させるフェーズ・レベル論理を含みうる。

またその代わりとして、パラメータ集合５６２の幾つか又は全ては、プロセス工場１６またはプロセス制御システム１０におけるどこか他のところに格納しうる。例えば、データベース３４は、ユニットと設備のモジュール・パラメータを維持管理しうる。また、バッチランナー３８６〜３９０は、ユニット５５２の選択に際してデータベース３４から必要なパラメータを読み出しうる。但しいずれの場合も、動的パラメータ「選択＿ユニット／能力」は、レシピ５３０外部に存在する特定の値（例えば、数値、文字列、など）になりうる。

その他の状況において、ユニット手順５３２は、例えばレシピ５３０作成時にユニット５５２が選択された場合、パラメータ５６０への完全なパスを指定することも可能である。かかる一事例においてユーザはユニット手順５３２にパラメータ「ユニット＿０２／能力」を含みうる。動的パラメータ「ユニット＿０２／能力」も同様に、対応するバッチランナー３８６〜３９０がフェーズ・レベル論理をユニット５５２に読み込む時点で特定の値になりうる。上記実施例でのように、レシピ５３０作成時にパラメータの特定の値は不明（またはそれ以外の場合利用不可能）でありうる。また、実行時中に「ユニット＿０２／能力」が変わるところの値はレシピ５３０の外部にある。

図１１を参照するに、レシピ５８０は、実行時中に選択された制御モジュール５８６と関連するパラメータを参照するユニット手順５８２とおよび設備モジュール５９４と関連するパラメータを直接参照するユニット手順５９０を含みうる。この特定の実施例においては、制御モジュール５８６と設備モジュール５９４が同じユニット５９６に属する。但し、レシピ、ユニット手順、動作およびフェーズが無関係な制御モジュール、設備モジュール、ユニットなどにおける値を参照することも可能である。

図１０に示される実施例と同様に、ユニット手順５８２は、「選択＿制御＿モジュール／最高＿速度」のパラメータを含んでいても良く、その場合、該「選択＿制御＿モジュール／最高＿速度」のパラメータは、実行中に、例えば、「制御＿モジュール＿０１／最高＿速度」）になり、最終的には例えば制御モジュール５８６と関連するモーターの最高速度に対応する特定の値になりうる。ユニット手順５９０は、例えば、「設備＿モジュール＿０１／重量」のパラメータを含みうる。

なお、一般に図１０および図１１に関しては、レシピが、レシピのいかなるレベルにてユニットまたは設備モジュール・パラメータを参照しうる。よって、レシピは、ユニット手順内に、動作内に、またはフェーズ内に、あるステップから別のステップへの遷移時に動的入力パラメータを含みうる。さらに、動的入力パラメータは静的値（例えば、タンクの能力）または変化する値（例えば、混合タンク内の現温度）を参照しうることも述べておく。

次に、事前定義コマンド・ステップの使用について、一般的な説明と、図１２および図１３に示される設備調停および設備選択の幾つかの実施例に参照しての具体的な説明との両方を提示する。図１４は、プロセスコントローラ１２およびプロセス工場１６において使用されうる設備調停システムの一実施例をさらに提示する。上記の如く、バッチエグゼクティブ３０（例えば、図１および図６を参照）は、ユーザがコマンドセット、設定点、コマンドパラメータおよびその他の関連情報を定義し、これらの事前に定義されたコマンドセットを特定の設備または制御モジュールに関連付け、そしてレシピ階層のいかなるレベルに所望の事前定義コマンドセットを追加することにより効率的にレシピを設計することを可能にする。レシピ内で使用された場合、これらのコマンドセットは、設備調停且つ又は選択を実行し、オペレータ・プロンプトおよびメッセージを提供し、外部システムにメッセージを送り、選択された動作モードに従って設備モジュールにコマンドとデータを送り、また、その他の事前に定義された機能性を実行しうる。一実施形態において、事前に定義された各セットは、容易に認識しうる視覚指標（例えばアイコンなど）を得るかもしれず、また、マウスなどいかなるポインティングデバイスで選択するように特定のウィンドウ枠において利用可能なものでありうる。その後、オペレータは、対応するアイコンをクリックしてからレシピの生成または編集に使用されるキャンバス領域にそのアイコンをドラッグして、アイコンをレシピ論理内の所望の位置にドロップすることにより、所望の事前に定義されたコマンドのセットを選択しうる。

設備モジュールの構成を簡素化するために事前に定義されたコマンドセットを使用する具体的な実施例を一つ取り上げて説明すると、特定の温度自動調節器は、各々の設定点を各々有する「高温」または「低温」モードで作動する。バッチエグゼクティブ３０は異なるレシピに従って実行する複数の同時バッチをサポートしうるので、温度自動調節器は、様々なバッチおよびレシピにおいて使用される可能性がある。よって、ユーザは、ＢＯＩ
３２を使用して新規コマンドセットを作成し、例えば「温度自動調節器＿マクロ」などの名前または識別子を状況に応じてコマンドセットに割り当て、各作動モード（即ち「高温」と「低温」）のステップを幾つか定義して、各作動モードのパラメータ且つ又は一つ又は複数の設定点を指定しうる。その後、ユーザは新規作成されたコマンドセットを保存しても良いし、且つ、簡単に視覚認識できるようにユーザ定義アイコンを状況に応じてコマンドセットへと割り当てても良い。この時点で、ユーザは、コマンドセット「温度自動調節器＿マクロ」の保存箇所（例えば構成データベース３４）を指定しうる。

レシピを作成するまたは編集する時、ユーザは「温度自動調節器＿マクロ」のためのアイコンを選択しても良いし、または名前またはその他の識別子によりこの事前に定義されたコマンドセットを参照して「温度自動調節器＿マクロ」をレシピに追加するようにしても良い。その後、ユーザは、特定のレシピに従って希望の作動モードを選択しうるし、「温度自動調節器＿マクロ」の一つまたは幾つかのパラメータを状況に応じて調節しうる。いずれの場合も、ユーザは、フェーズ・レベルで温度自動調節器モジュールの構成またはプログラミングを詳細にわたって行う必要がない。さらに、ＢＯＩ ３２は、ユーザが「温度自動調節器＿マクロ」を加え、該「温度自動調節器＿マクロ」を、選択されたレベルに適しており且つこのレベルに特有のその他いかなる規則に一致する遷移を使用してレシピ論理に接続することを希望するところの（例えば、ユニット手順、動作などの）レシピ論理のレベルを自動的に決定しうる。

設備の調停と選択に関し、図１２は、バッチマネージャ３８２を介してユーザーインタフェース３１、ウェブサービス３９８、または幾つかの外部モジュールと動的に交信するバッチランナー３８６を示す。ブロック６０２において、バッチランナー３８６は、レシピの特定のステップを実行しうる。次に、ブロック６０４において、バッチランナー３８６は、設備調停を必要とするレシピにおいて事前に定義されたコマンドセットに遭遇しうる。特に、この実施例におけるブロック６０４は、レシピ論理の手順レベルまたは最高レベルのものに対応する。よって、設備調停を始動するのに、バッチランナー３８６が、レシピの特定の動作内の特定のフェーズに到達している必要はないが、その代りにレシピ論理の何らかのレベルで調停を依頼しうる。なお、希望する場合、バッチランナー３８６が、幾つかの設備または制御モジュールを有するユニットの調停を依頼するようにしても良い。それ以外の場合、バッチランナー３８６が特定の設備モジュールまたは制御モジュールの調停を依頼するようにしても良い。

バッチマネージャは、図１４を参照して以下詳述される技法をはじめとする適切な調停方法の如何なるものを使用してブロック６０６において調停を行いうる。この特定の事例において、バッチマネージャ６０６は調停依頼を自動的に解決しうる。次に、ブロック６０８において、バッチランナー３８６は、バッチマネージャ３８２から設備調停の結果を明示する応答を受信して、レシピの実行を継続しうる。

さらに、バッチランナー３８６が実行するレシピは、別の設備調停依頼を含みうる。
図１２に示される実施例において、ユーザが、第２の設備調停依頼を動作６２２の完了に際して始動されるようにステップ６２０に関連付けてある。バッチマネージャ３８２は、ブロック６２６において第２の調停依頼を処理しうる。また、ブロック６２６は順じてオペレータ・プロンプト６２８をトリガしうる。なお、第２の調停依頼は、ブロック６０４において始動された第１の調停依頼と同じ事前定義コマンド・ステップでありうる。特に、ユーザは、レシピ論理の異なるレベルに各々対応するレシピ中の二箇所で同じ事前定義コマンドセットを使用したかもしれない。上記の如く、ＢＯＩ ３２は、選択された論理レベルでレシピに適切に嵌るようにコマンドセットを自動的に調節し、それによってユーザの構成の手間を大幅に簡素化しうる。

ここで図１３を参照するに、インターフェース画面７００は、レシピ編集用ウィンドウ枠７０２および事前定義コマンドセット選択用ウィンドウ枠７０４を含みうる。この実施例において、事前定義コマンドセット選択用ウィンドウ枠７０４は、特定の温度自動調節器用の制御モジュールコマンドセット７１０と、特定のポンプに使用するための設備モジュールコマンドセット７１２と、特定の混合機に使用するための調停依頼コマンドセット７１４と、特定の貯蔵タンクに使用するためのユニット選択コマンドセット７１６と、標的圧力に関する問い合わせ（クエリー）を行うオペレータ・プロンプト・コマンドセット７１８、そして、生産実行システム（ＭＥＳ）にステータスアップデートを送る生産実行システムメッセージ・コマンドセット７２０とを含みうる。

ユーザは、事前定義コマンドセット７１０−７２０の如何なるものを選択し、選択されたコマンドセットをウィンドウ枠７０２のキャンバス領域にドラッグ・アンド・ドロップしうる。レシピ７３０に制御モジュールコマンドセット７１０のインスタンスを追加する一実施例が図１３に示されている。加えて、制御モジュールコマンドセット７１０の拡大図７３０には、対応する設備モジュールが少なくとも二種類の作動モードを有することが示されている。ここで該二種類の作動モードは別の設定点と各々関連付けられている。上述の如く、ユーザは、希望する動作モードを選択し、制御モジュールコマンドセット７１０をレシピ７０２に追加するに際してパラメータを状況に応じて調節しうる。もちろん、ユーザは、制御モジュールコマンドセット７１０をレシピ７０２のいかなるレベルに追加するべく動作レベル論理またはフェーズ・レベル論理に「ドリルダウン」しても良い。ユーザは、同様に事前定義ステップ７１０−７２０の如何なるものを、レシピ７０２の論理内の所望の位置にドラッグ・アンド・ドロップして、一つまたは幾つかのパラメータなどを調節しうる。

図１４は、設備アクセスおよびスケジュールの不一致を効率的に解決するためにバッチエグゼクティブ３０により利用されうる設備調停システムの例示的な一実施形態を示す。上述の如く、プロセス制御システム１０は一つ又は複数のワークステーション１４を含んでおり、リソース５６はタイプ８２０をさらに構成する。各々のタイプ８２０は、各リソース５６と関連付けられておりリソース５６が単一領域５４においてのみ使用されているのか、または複数の領域５４にわたって使用されているのかを示す。一実施形態において、タイプ８２０は「ローカル」または「グローバル」のいずれかである。ローカルタイプ８２０は、リソース５６が１つの領域５４においてのみ使用されていることを示すが、グローバルタイプ８２０は、リソース５６が複数の領域５４にわたって使用されていることを示す。リソース５６が１つの領域５４においてのみ必要とされるか、または複数の領域５４にわたって必要とされるかを指定することにより、マルチ領域設備調停機構（アービトレイタ）は、リソース５６を全て管理する必要なく複数の領域５４にわたってユーザ６０から同じリソース５６に対する同時の依頼または競合する依頼を管理することができる。一実施形態において、特定のリソース５６がローカルであるかグローバルであるかは、プロセス工場１６と関連する人間のオペレータまたはエンジニアにより決定される。

ワークステーション１４は、（プロセス制御サービスなどを提供するように作動可能な）モニター、キーボード、中央処理装置（ＣＰＵ）、コンピュータ可読メモリおよび格納部などのハードウェア且つ又はソフトウェアを備えうる。例えば、ワークステーション１００は、インテル（登録商標）社コンピュータープロセッサ上でマイクロソフト（登録商標）ウィンドウズ（登録商標）ＮＴ、２０００またはＸＰＲオペレーティングシステムを実行しているコンピュータ・ワークステーションまたはパソコン（ＰＣ）でありうる。別の実施例については、ワークステーション１００が、ランダムアクセス記憶装置（ＲＡＭ）やダイナミックＲＡＭ（ＤＲＡＭ）および読み出し専用メモリー（ＲＯＭ）などの電子メモリと、ハードドライブ、フロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−ＲＷドライブおよびデジタル多用途ディスク（ＤＶＤ）ドライブなどの磁気記憶装置および光学記憶装置、そしてその他の適切なコンピュータ構成部分を含みうる。

ワークステーション１４は、エマソン・プロセスマネジメント社によりＤｅｌｔａＶ（登録商標）システムの一部として販売されているＤｅｌｔａＶ（登録商標）バッチ・ソフトウェアなどのバッチプロセス制御機能をさらに備えうる。一実施形態において、ワークステーション１００は、バッチエグゼクティブ３０、ローカル設備調停機構（ＬＡＲ：local equipment arbitrator）８１２、およびグローバル設備調停機構（ＧＡＲ：global equipment arbitrator）８１４をさらに備える。

バッチエグゼクティブ３０は、コンピュータ可読媒体に格納され且つ一つ又は複数の領域５４に対してプロセス制御システム５２のバッチ処理部分を実行するべく作動可能なソフトウェアを含みうる。一実施形態において、各々の領域５４はそれぞれ別々のバッチエグゼクティブ３０により制御される。バッチエグゼクティブ３０は、工場１６で使用されるレシピのステップを実行するリソース・ユーザ６０およびリソース５６を制御する。例えば、バッチエグゼクティブ３０が、ある物質を華氏３５０度で１５分間加熱するようにヒータ・リソースを制御し、その後該加熱した物質を混合機リソースの中に静かに注ぐようにしても良い。バッチエグゼクティブ３０は、実質的に同時に且つ又は互いに並行させて複数のレシピの性能を制御しているかもしれない。バッチエグゼクティブ３０は、ユーザ６０によるリソース５６に対する依頼の取り扱うためにＬＡＲ ８１２およびＧＡＲ ８１４と通信する。

ＬＡＲ ８１２は、特定の領域５４内のユーザ６０によるリソース５６の使用に関する依頼が相反する場合にそれを調停するべくバッチエグゼクティブ３０と通信するように作動可能なハードウェア且つ又はコンピュータ可読媒体に格納されたソフトウェアを備えている。より具体的には、バッチエグゼクティブ３０がリソース５６を使用してレシピを実行している間に、二つ以上のユーザ６０が、同じリソース５６の使用を実質的に同一の時点で必要とするかもしれない。両方のユーザ６０が同じリソース５６を実質的に同一の時点で使用することをバッチエグゼクティブ３０が認めると、両方のレシピが駄目になるかもしれない。同様に、バッチエグゼクティブ３０は、レシピの一部として、一つ又は複数のリソース５６をレシピにおける時間依存のステップのために確保しておく必要が将来的にあるかもしれないと判断しうる、または清浄を必要とするリソース５６など、特定のリソース５６が特定のレシピで使用される前に準備されていなければならないと判断しうる。ユーザ６０に対して一つ又は複数のリソース５６を割り当てるまたは確保する前に、バッチエグゼクティブ３０は、ＬＡＲ ８１２リソース５６の使用を依頼する。ＬＡＲ ８１２は、依頼されたリソース５６が、バッチエグゼクティブの特定の領域５４内でバッチエグゼクティブ３０により使用できる状態であるかを判断する。一実施形態において、ＬＡＲ ８１２は、「ローカル」のタイプ８２０のリソース５６のみを取り扱う。

ＧＡＲ ８１４は、二つ以上の領域５４にわたってユーザ６０によるリソース５６の使用に関する依頼が相反する場合にそれを調停するべくバッチエグゼクティブ３０と通信するように作動可能なハードウェア且つ又は、コンピュータ可読媒体に格納されたソフトウェアを備えている。より具体的には、バッチエグゼクティブ３０がリソース５６を使用してレシピを実行している間に、二つ以上のレシピが、同じリソース５６の使用を実質的に同一の時点で必要とするかもしれない。レシピに一つ又は複数のリソース５６を割り当てるか確保する前に、バッチエグゼクティブ３０は、ＧＡＲ ８１４から異なる領域５４におけるリソース５６の使用を依頼しうる。ＧＡＲ ８１４は、依頼されたリソース５６がバッチエグゼクティブの特定の領域５４の外部でバッチエグゼクティブ３０により使用できる状態になっているかどうか判断する。一実施形態において、ＧＡＲ ８１４は、「グローバル」タイプ８２０のリソース５６のみを取り扱う。ＧＡＲ ８１４はリソース５６の依頼を解決するために互いに通信することができる。

一実施形態において、各々のＧＡＲ ８１４は、各々のバッチエグゼクティブ３０のそれぞれと関連し、当該のバッチエグゼクティブの特定の領域５４においてタイプ８２０がグローバルであるリソース５６につかさどる。異なる領域５４における第２のＧＡＲ ８１４は、依頼されたリソース５６を有する領域５４と関連するＧＡＲ ８１４からリソース５６を依頼する。例えば、図１４を参照するに、ユーザＵ２は、リソースＲ３へのアクセスを依頼しうる。ユーザＵ２はリソースＲ３とは異なる領域にいるので、ユーザＵ２の領域におけるＧＡＲ ８１４は、リソースＲ３の領域におけるＧＡＲ ８１４からリソースＲ３へのアクセスを依頼する。

また、一実施形態において、ＧＡＲ ８１４は、別の不具合を持つＧＡＲ ８１４により６８扱われているリソース５６を引き受けることにより別のＧＡＲ ８１４の不具合を取り扱うように作動可能でありうる。例えば、第１の領域におけるＧＡＲ ８１４に不具合が生じるような場合には、第２の領域におけるＧＡＲ ８１４が不具合を持つＧＡＲの領域におけるリソース５６に対してリソースの調停を引き受けうる。

稼動中、一つ又は複数のバッチエグゼクティブ３０が、一つ又は複数の領域５４の各々における一つ又は複数のレシピの性能を制御する。様々なリソース・ユーザ６０がレシピのステップを実行するために一つ又は複数のリソース５６へのアクセスを依頼しうる。リソース・ユーザ６０は、バッチエグゼクティブ３０を通してリソース５６へのアクセスを依頼する。その後、バッチエグゼクティブは、リソース５６の依頼を、依頼されているリソース５６のタイプ８２０に基づいてバッチエグゼクティブに関連付けられているＬＡＲ８１２またはＧＡＲ ８１４へと受け渡す。

依頼されたリソース５６のタイプ８２０がローカルな場合、ＬＡＲ ８１２は、適切な判定基準に基づいてリソース５６がユーザ６０により使用できるものかどうか判断する。例えば、ＬＡＲ ８１２は、単にリソース５６が別のユーザ６０により現在使用されているかどうか判断しうる。また、ユーザ６０が使用する前にリソース５６を定置洗浄システムなどにより洗浄する必要があるか、または依頼元ユーザ６０が使用する前にリソース５６を特定の温度にする必要があるかなど、複雑な使用上の決定もＬＡＲ ８１２は行いうる。その後、ＬＡＲ ８１２は、依頼されたリソース５６が利用可能であるかどうか、また状況に応じていつ利用可能であるかどうかをバッチエグゼクティブ３０に通信する。例えば、ユーザU1とＵ２がリソースＲ１にアクセスしようと試みた場合、ＬＡＲ ８１２はどのユーザが依頼されたリソースにアクセスするかを決定する。

依頼されたリソース５６のタイプ８２０がグローバルな場合、ＧＡＲ ８１４は、依頼元のユーザ６０がリソース５６を使用できるかどうか判断する。依頼されたリソース５６が、バッチエグゼクティブ３０と関連するＧＡＲ ８１４と同じ領域にある場合、ＧＡＲ ８１４は、リソースが利用可能かどうか判断し、依頼されたリソースが利用可能かをバッチエグゼクティブ３０に通信する。依頼されたリソース５６が、バッチエグゼクティブ３０と関連するＧＡＲ ８１４とは異なる領域にある場合、ＧＡＲ ８１４は、依頼されたリソース５６を領域５４内に有するＧＡＲ ８１４へと該依頼を通信する。依頼元のＧＡＲ ８１４は、何らかの適切な方法を用いて依頼を取り扱うのに適したＧＡＲ ８１４を決定しうる。一実施形態において、ＧＡＲ ８１４は、依頼がＧＡＲ ８１４の全てまたは一部分に一斉同時送信されて適したＧＡＲ ８１４により取り扱われるピアツーピア・ネットワーク構成においてピアとして編成される。別の実施形態において、ＧＡＲ ８１４は、なおまたピアとして編成されうるが、取り扱うリソース５６のリストを交換して、依頼を全てのＧＡＲ ８１４へと一斉同時送信する必要を避ける。その代わりに、適したＧＡＲ ８１４が依頼元のＧＡＲ ８１４により直接連絡を受けることも可能である。
一般に、ＧＡＲ ８１４は何らかの適切な様態において編成されうる。適したＧＡＲ ８１４は、依頼されたリソース５６が利用可能かどうか判断し、その結果を依頼元のＧＡＲ ８１４に改めて通信する。その後、依頼元のＧＡＲ ８１４は、その結果をバッチエグゼクティブ３０で取り扱うように該バッチエグゼクティブ３０へと再度受け渡す。あるいは、該結果を、依頼元のＧＡＲ ８１４を迂回して依頼元のバッチエグゼクティブ３０に直接送り返すようにしても良い。例えば、図１４を参照するに、現在ユーザU3がリソースＲ３を使用しており、且つユーザＵ２がリソースＲ３にアクセスすることを希望する場合、Ｕ２の領域におけるＧＡＲ ８１４が、Ｕ２の依頼をＲ３の領域中のＧＡＲ ８１４にて取り扱うように該ＧＡＲ ８１４へと受け渡す。

その後、バッチエグゼクティブ３０は、依頼されたリソース５６が利用可能かどうかによって適切な処置を払う。バッチエグゼクティブ３０は、利用できないリソースに対して、依頼元のユーザ６０と関連するレシピの実行を一時停止させるなどの適切な処置を取りうる。

一実施形態において、ＧＡＲ ８１４は、プロセス制御システム５２により提供されたＧＡＲ ８１４の全てまたは一部分からマスターＧＡＲを選択しうる。適切なＧＡＲ ８１４であれば如何なるものもマスターＧＡＲとして機能しうる。例えば、マスターＧＡＲは、特定の処理能力を有するまたは特定の処理負荷未満のワークステーション１００上で実行されるＧＡＲ ８１４に制限されうる。マスターＧＡＲは、特定のリソース５６が利
用可能か、どのリソース５６がどの領域５４にあるかを追跡するための、且つ又はその他の適切なデータを提供する集中化データベースとしても機能しうる。マスターＧＡＲは、リソース５６と当該リソース５６を取り扱うために割り当てられたＧＡＲ ８１４との間のマッピングを格納することによりＧＡＲ 814間で必要とされる通信の量を減らすためにも使用しうる。別の実施形態において、マスターＧＡＲは、リソース５６に関する（可用性などの）状態情報を格納しうる。この実施形態において、依頼元のＧＡＲ ８１４は、リソース５６が利用可能かどうか判断するためにマスターＧＡＲに問い合わせ（クエリー）を行うことも可能である。マスターＧＡＲの選択は何らかの適切な技法を使用して行いうる。例えば、ＧＡＲ ８１４は、どのＧＡＲ ８１４が最初にアクティブ化されたかを判断することによりマスターＧＡＲを決定しうる。ネットワークにおいて「マスター」要素を決定または選択するためのその他の技法は、本発明の属する技術分野において周知のものである。

また、ＧＡＲ ８１４は、その他のＧＡＲ ８１４の不具合を取り扱う能力を有しうる。より具体的には、特定の領域５４におけるＧＡＲ ８１４がクラッシュによりなど障害を起こすかもしれないが、別のＧＡＲ ８１４がかかる不具合を検出し、不具合を持つＧＡＲのリソース５６の取扱いを引き受けるようにしうる。例えば、マスターＧＡＲが不具合を検出し、不具合を持つＧＡＲのリソース５６に別のＧＡＲ ８１４を割り当てるようにしても良い。別の実施例では、依頼元のＧＡＲ ８１４が、別のＧＡＲ ８１４がある程度の期間応答していないことを検出して、不具合を持つＧＡＲ ８１４により取り扱われているリソース５６を引き受けるようにしても良い。

別の実施形態において、ＧＡＲ ８１４は、ユーザ６０が特定のリソース５６を使用してもよいかどうかをまとめて（集団的に）判断しうる。例えば、その領域５４におけるリソース５６へのアクセスを取り扱う責任を各領域５４におけるＧＡＲ ８１４に負わせるのとは対照的に、一つ又は複数の領域５４における一つ又は複数のリソース５６へのアクセスを取り扱う責任を二つ以上のＧＡＲ ８１４が負うようにしても良い。一般に、領域５４におけるリソース５６の幾つか又は全てへのアクセスを適宜に取り扱う責任をＧＡＲ８１４の幾つか又は全てが負うようにしうる。例えば、特定のリソース５６の可用性がＧＡＲ ８１４によりどのように取り扱われるか判断するために、更なるタイプ８２０を定義しうる。ＧＡＲ ８１４による投票するに基づいて、またはその他の適切な技法により、リソース５６の可用性をまとめて（集団的に）決定しても良い。また、集団的決定により、特定のリソース５６の可用性を判断する上で特定のＧＡＲ ８１４を優先することが可能になる。例えば、第1のＧＡＲが、一つ又は複数の第２のＧＡＲよりも多くの投票を得るかもしれない、または一つ又は複数の第２のＧＡＲを拒否する権利を得るかもしれない。さらに、依頼されている特定のリソース５６によっては、一つ又は複数のＧＡＲ ８１４の投票力または拒否能力が増加しうる。ＧＡＲ ８１４に提供する投票力または拒否権を増加させことにより、特定の状況においてリソース５６の優先使用を許可する能力を提供しうる。例えば、緊急事態または予期せぬ結果が生じた場合には、特定のユーザ６０に対して優先アクセスを提供する必要があるかもしれない。

前述の説明からも分かるように、動的入力パラメータを含むため、且つ又は製品レシピにおけるコマンド・ステップを事前定義するための方法およびシステムによって、ユーザは、製品レシピの論理外部の値を参照し、前回の又は並列する設備フェーズまたは外部モジュール（例えば、ＬＩＭＳ、ウェブサービス、など）により生成された値を参照することにより実行時中にバッチ操作を調節し、そして自動的にフェーズ実行の結果を読み出してこれらの結果を別のフェーズ、動作またはユニット手順に供給することによりオペレータの手間を軽減できるようになる。なおまた、上記の方法とシステムにより、ユーザは、設備調停と選択をレシピ論理の如何なるレベルで行えるようになり、またそれによって設備関連論理の全てを、対応するレシピのフェーズ・レベルまで「押し」下げることを避けられるようになる。なおまた、上記コマンド・ステップの事前定義がサポートされているので、オペレータとエンジニアが、複数のバッチが複数のレシピに従って実行されており頻繁に共通の物理的なリソースを確保しようと試みるような環境においてレシピを効率的に定義できるようになる。特に、コマンド・ステップが事前定義されているので、ユーザは、単純な、また希望する場合は複雑な指示、パラメータ且つ又は設定点一式を特定の設備クラス（例えば、ユニット・クラス)または特定の設備インスタンスと関連付け、そしてこの事前に定義された一式のコマンドを、全く調整を加えずに、または例えば希望動作モード且つ又は目標値の単純な選択を伴って、複数のレシピに追加できるようになる。

上記において、特定の実施例（本発明を例証する実施形態に過ぎず、本発明を限定するものではない）を参照して本発明を説明したが、通常の技術を有する当業者にとっては、本発明の精神と範囲から逸脱することなく、ここに開示される実施形態に変更、追加又は削除が生じうることが明らかなはずである。

Claims (13)

1. バッチ実行環境における製品レシピを構成するためのシステムであり、
   コマンドセットの定義を受け取るため、およびコンピュータ可読メモリに定義を格納するためのコマンドセット定義モジュールと、
   レシピ論理を定義するデータを受け取るための論理規格関数と、コマンドセットの選択を受け取るためのコマンドセット選択関数と、レシピ論理内の特定の箇所に対応する識別子を受け取り特定の箇所にコマンドセットを挿入するためのコマンドセット挿入関数とを含むレシピ論理を有するレシピの定義を円滑に実施するためのレシピ設計モジュールと、
   を備え、
   前記レシピ設計モジュールが、挿入されたコマンドセットをレシピ論理に自動的に関連付ける、
   ことを特徴とするシステム。
2. 前記コマンドセットが、設備エンティティまたは設備分類の一つについての設備識別子と、前記設備識別子に対応する設備についての調停依頼とを含んでいることを特徴とする請求項１に記載のシステム。
3. 前記コマンドセットが、設備エンティティまたは設備分類の一つについての設備識別子と、前記設備識別子に対応する設備についてのユニット選択依頼とを含んでいることを特徴とする請求項１に記載のシステム。
4. 前記コマンドセットが、設備モジュールまたは設備モジュールのクラスの一つについての設備識別子と、レシピの実行中に前記設備モジュールに条件付きで送信される一式のコマンドとを含んでいることを特徴とする請求項１に記載のシステム。
5. 前記コマンドのセットが、第１の作動モードに対応するコマンドの第１のサブセットおよび第２の作動モードに対応するコマンドの第２のサブセットを含んでいることを特徴とし、且つ、
   コマンドセット挿入関数が、少なくとも前記第１の作動モードと前記第２の作動モードとの間で選択を行うための識別子をさらに受け取ることを特徴とする、
   請求項４に記載のシステム。
6. 前記レシピ論理が、フェーズ・レベルおよび少なくとも一つの高位レベルと関連付けられていることを特徴とし、
   前記コマンドセットが、オペレータメッセージまたはオペレータ・プロンプトを生成するための一式のコマンドを含んでいることを特徴とし、且つ、
   前記レシピ論理内の特定の箇所が、前記レシピ論理の前記少なくとも一つの高位レベルと関連付けられている、
   ことを特徴とする請求項１〜請求項５の何れか1項に記載のシステム。
7. 前記コマンドセットが、バッチ実行環境外のモジュールにメッセージを送信するための一式のコマンドを含んでいることを特徴とする請求項１〜請求項６の何れか1項に記載のシステム。
8. 前記レシピ論理が、フェーズ・レベルおよび前記フェーズ・レベル以上の手順レベルを含む複数のレベルと関連付けられていることを特徴とし、且つ、
   前記コマンドセット挿入関数が、前記レシピ論理内の第２の箇所に対応する第２の識別子を受け取ることを特徴とし、
   第１の箇所および第２の箇所が、レシピ論理の複数のレベルのうち二つの異なるものと関連付けられていることを特徴とし、且つ、
   前記コマンドセット挿入関数が、同じ選択されたコマンドセットをレシピ論理内の第１の箇所と第２の箇所の中に挿入することを特徴とする、
   請求項１〜請求項７の何れか1項に記載のシステム。
9. 前記レシピ論理は、動的入力パラメータを含み、
   前記動的入力パラメータは、バッチ運転の開始の時には特定されていない値を含み、
   前記動的入力パラメータの前記特定されていない値は、前記製品レシピのフェーズ・レベルで関連する前記製品レシピ又はオペレータ・プロンプトからの値を取得せずにバッチプロセスの前記製品レシピの実行の間の値に特定される、
   請求項１〜請求項８の何れか１項に記載のシステム。
10. バッチ実行環境において実行する製品レシピを構成する方法であり、
    レシピ論理と互換性をもつ一式のコマンドの定義を受け取ることと、
    前記レシピ論理の部分的な定義を受け取ることと、
    前記レシピ論理内の選択された箇所に該一式のコマンドを挿入する依頼を受け取ることと、
    選択された箇所に準じて前記一式のコマンドをレシピと自動的に関連付けることと、
    を備える方法。
11. 前記一式のコマンドの定義を受け取ることには、設備調停、設備選択、オペレータメッセージの生成、またはオペレータ・プロンプトの生成の少なくとも一つを行うコマンドを受け取ることが含まれることを特徴とする請求項１０に記載の方法。
12. 前記一式のコマンドの定義を受け取ることには、第１の作動モードまたは第２の作動モードにおいて装置または制御モジュールを選択的に作動するコマンドを受け取ることが含まれることを特徴とし、
    前記レシピ論理内の選択された箇所に該一式のコマンドを挿入する依頼を受け取ることには、第１の作動モードまたは第２の作動モードの選択を指定することが含まれることを特徴とする、
    請求項１０又は請求項１１に記載の方法。
13. 前記レシピ論理は、動的入力パラメータを含み、
    前記動的入力パラメータは、バッチ運転の開始の時には特定されていない値を含み、
    前記動的入力パラメータの前記特定されていない値は、前記製品レシピのフェーズ・レベルで関連する前記製品レシピ又はオペレータ・プロンプトからの値を取得せずにバッチプロセスの前記製品レシピの実行の間の値に特定される、
    請求項１０又は請求項１１に記載の方法。