プロセスシステムにおけるバッチ処理および実行のための方法とシステム
【課題】制御レシピを効率的に実施すると共に、および制御レシピの実行中に不整合性を解決するためのシステム及び方法を提供する、
【解決手段】本発明のシステム及び方法は、制御プロセスの論理構造を読み込み、制御プロセスがインスタンス化される場合に複数のインスタンス化オブジェクト又はプロセスを読み込み、実行中に制御プロセスが手順要素を呼び出すたびに制御プロセスの手順要素をインスタンス化するためにインスタンス化オブジェクトを使用し、制御プロセスの一部として手順要素を実行し、制御プロセスの実行中に手順要素の実行が完了するにつれて手順要素を解体することを含む。
【解決手段】本発明のシステム及び方法は、制御プロセスの論理構造を読み込み、制御プロセスがインスタンス化される場合に複数のインスタンス化オブジェクト又はプロセスを読み込み、実行中に制御プロセスが手順要素を呼び出すたびに制御プロセスの手順要素をインスタンス化するためにインスタンス化オブジェクトを使用し、制御プロセスの一部として手順要素を実行し、制御プロセスの実行中に手順要素の実行が完了するにつれて手順要素を解体することを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概してプロセス工場内のプロセス制御システムに関し、より具体的にはバッチプロセスなどのプロセスの実行および、該プロセスの稼動中における不整合性の解決に関する。
【背景技術】
【０００２】
製造工場およびその他の生産工場は一般に多種多様な製品を生成するために使用される。テキサス州オースティン市を所在地とするＥｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ， ＬＬＰ社により提供されるようなプロセス制御システムをはじめとするプロセス制御システムは、製品の製造又はプロセスの制御（例えば、化学薬品の製造、発電所の制御、など）が行われるこのような製造工場且つ又はその他工場施設において幅広く使用されている。また、プロセス制御システムは、例えば石油・ガス掘削および貯蔵工程をはじめとする天然資源などの採掘にも使用されている。一つ又は複数のプロセス制御システムのアプリケーションを通じて、実質的に全て製造工程や資源採掘工程などを自動化できる。
【０００３】
一般に、化学薬品の処理工程や石油精製又はその他のプロセスにおいて使用されるようなプロセス制御ネットワークには、例えば、バルブポジショナ、スイッチ、センサ（温度、圧力および流量センサ、等）など、一つ又は複数のフィールド装置に通信可能に連結された集中型プロセスコントローラが含まれる。これらのフィールド装置は、プロセス内の物理的制御機能（バルブ開閉など）を実行しうるし、プロセスの動作の制御に使用するためにプロセス内の計測を講じうるし、又はプロセス内においてその他所望の機能を実行しうる。プロセスコントローラは従来から一つ又は複数の（例えば、フィールド装置間で４〜２０ミリアンペア（ｍＡ）の信号を伝送しうる）アナログ信号線又はバスを介してフィールド装置に接続されるものであった。しかしながら、より最近になって、プロセス制御の産業分野では標準、オープン、デジタル又はジタル・アナログ混合通信プロトコルが数多く開発されており、その数例としてＦＯＵＮＤＡＴＩＯＮ（登録商標） ＦＩＥＬＤＢＵＳ（以下「Ｆｉｅｌｄｂｕｓ」）、ＨＡＲＴ（登録商標）、ＰＲＯＦＩＢＵＳ（登録商標）、ＷＯＲＬＤＦＩＰ（登録商標）、Ｄｅｖｉｃｅ Ｎｅｔ（登録商標）およびＣＡＮプロトコルが挙げられ、これらを使用してコントローラとフィールド装置間の通信を実施できるようになっている。一般的にプロセスコントローラは、一つ又は複数のフィールド装置により生成された計測且つ又はフィールド装置に関するその他の情報を示す信号を受信し、この情報を使用して通常複雑な制御ルーチンを実施し、さらに信号線又はバスを介してフィールド装置に送信される制御信号を生成することによってプロセスの動作を制御する。
【０００４】
その他、プロセス制御システムにより制御される製造工程の一般的なものとしてはバッチプロセスがある。一般に、バッチ処理には材料を生成するための「レシピ」と呼ばれるものが関与する。例えば、バッチ処理は一般に製薬および化学工業において薬剤や化学薬品およびその他の物質を製造するために使用される。バッチプロセスの内容を記述するレシピは一般に、どのようにして所望の物質を生成するかを示す。例えば、特定の化学薬品は、まず二つの化学薬品を混合した後にその混合物を加熱することにより生成されうる。単に一つの物質を生成するために何百もの段階が全体的なレシピに含まれうる。所望の物質を生産するにはどの材料をどのような割り合で使用するべきであるか、材料を加熱するべきか冷却するべきかどうか、どのような設備が必要か、などをレシピは示すことができる。工業規模で実施されている例としてはポリ塩化ビニルの調合が挙げられる。ポリ塩化ビニルは、塩化ビニルの非常に小さい分子を重合又は「結合する」ことにより作られる。これは、バッチ反応装置内に塩化ビニルと溶剤および重合誘導物質の混合物を適切なレベルまで充填し、混合物を反応装置の中で加熱し、結果的に得られるバッチを冷却してから、残存の出発物質を取り除くことによりバッチを精製することにより達成される。
【０００５】
通常、バッチプロセスにおいて使用されるものなど、特定のタイプのプロセス制御ネットワークには、プロセス内で本質的に同じ機能を実行する同じ又は似した設備を備えるように設計された複数組（セット）の複製設備が含まれている。よって、例えば、ポリ塩化ビニルの製造工場には、複数組の反応処理設備（すなわち反応装置）、複数組の加熱処理設備（すなわち加熱器）、複数組の冷却処理設備（すなわち冷却器）、複数組の精製処理設備（すなわち精製器）、および複数組の梱包設備（すなわち梱包ユニット）が備えられうる。またこの場合、反応装置のいくつか又は全てが、加熱ユニット、冷却ユニット、精製ユニットおよび梱包ユニットのいくつか又は全てと並列して作動可能、且つ、加熱ユニット、冷却ユニット、精製ユニットおよび梱包ユニットのいくつか又は全てと直列作動が可能な状態で接続されるようにしても良い。
【０００６】
一般に、バッチプロセスは第２の段階を開始する前に第１の段階を終了させるといった具合に、複数の異なるフェーズ又はテップを順々に実行する。このように、上記の製造工場では、バッチプロセスが、反応処理ユニットを制御するように第１のフェーズ又はテップを実行してから、反応処理設備により作られた製品上で加熱処理ユニットを実行するように第２のフェーズを実行し、加熱処理ユニットにより生産された製品を冷却するように冷却処理ユニットを制御する第三のフェーズを実行し、製品を精製するように精製処理設備を制御する第四のフェーズを実行し、そして精製された製品を梱包するように梱包ユニットを制御する第五のフェーズを実行する。一般に、各ユニットは、それに関連付けられているユニットモジュール・オブジェクト（例えば、ハードウェア構成機器のようなユニットの状態を表すように構成されたソフトウェアでありうる）を有する。ユニットモジュール・オブジェクトは、下位レベルのモジュールの実行を協調させるよう最適化された、ソフトウェア命令にて具現化されたアルゴリズムでありうる。（以下、「下位レベルモジュール」を単に「モジュールオブジェクト」と総称する。）モジュールオブジェクトは、以下さらに詳しく説明されているように、可変部分とアルゴリズム部分を含みうる。一般に、モジュールオブジェクトは、単一の論理機能（例えば、バルブを開く、又はタンクを充填する、など）を遂行するように設計されている。手短に言えば、モジュールオブジェクトはハードウェア構成機器の状態を変更するために使用される。
【０００７】
前述のポリ塩化ビニルを作る代表的なバッチプロセスでは各フェーズがある特定のユニット上で動作するように説明されているが、これは必ずしもそうでなければならないとは限らない。それぞれのフェーズのステップ数によっては、複数台の設備ユニットが特定のフェーズを遂行するために使用されるようにしても良い。例えば、ポリ塩化ビニルを作るようにバッチプロセスをプログラムして使用する代わりに、ポリ塩化ビニルの生成をより大きなバッチプロセス中の一つのフェーズとしても良く、このようなフェーズは、反応装置、加熱器、冷却器、精製器および梱包ユニットでありうる。
【０００８】
バッチプロセスを制御することは一般に重要な要素である。例えば、塩化ビニルの反応混合物が十分に長い時間をかけて反応されないと、そのプロセスから得られるポリ塩化ビニルの歩留りが不十分となり、資金の損失につながる。危険薬品又はれ同等のエンティティ（実体）の生産を伴う場合、バッチプロセスの制御は決定的な重要性を持つようになる可能性がある。バッチプロセスを制御する一つの方法はマニュアル操作による制御である。即ち、全てが確実に計画通りに進行するようにするために、一人又は複数の作業者に対して、バッチプロセスの全ての面を監視する仕事が割り当てられる。但し、これは忍耐を要する作業であり、また、気付かないままエラーが発生する可能性がある。これらの理由、およびその他の理由で、電子装置を使用して制御バッチプロセスの自動化が展開されている。バッチプロセス制御の自動化を目指して、複数のバッチ制御システム供給業者によりコンピューターやプログラム可能制御装置およびそれ同等の電子装置が、知的フィールド装置（すなわち知能センサおよび制御可能バルブ）と連動した状態で使用されてきた。知能センサは、通常一台の設備機器上に配置されており、工場施設内の中央制御室へと設備機器状態を報告する。一般に、制御可能バルブは、一台の設備機器への入力又は台の設備機器からの出力を制御するものであり、大抵の場合は知能センサから受信した情報に基づいて中央制御室から制御することができるものである。
【０００９】
バッチ処理自動化への取り組みの結果、とりわけバッチ処理に関与する産業分野に属する者およびバッチ処理設備の供給業者によって標準委員会が設立されるに至った。これら標準委員会の全体的な目的は自動化バッチ処理のために一律した標準を定義することにある。このような標準の一つとしては、プロセス制御の問題に従事する国際組織である国際計測制御学会により公布されたものがある。この標準は、「Ｂａｔｃｈ Ｃｏｎｔｒｏｌ
Ｐａｒｔ １： Ｍｏｄｅｌｓ ａｎｄ Ｔｅｒｍｉｎｏｌｏｇｙ（バッチ制御 第１部： モデルおよび用語集）」と題され、しばしばＩＳＡ Ｓ８８．０１−１９９５標準（又は本出願においては「Ｓ８８」）と呼ばれるものである。このＳ８８．０１標準は、自動化バッチプロセスにおいて使用する設備機器のモデルおよび手順ならびに、当該のモデルとその要素を指すために用いられる用語を定義している。「バッチプロセス」とは、Ｓ８８．０１標準によると、一台又は複数台の設備機器を使用して限定された期間の間、多数の入力素材を順序化された処理作業のセットに従わせることにより、有限量の材料を生産するに至るプロセスとされている。「バッチ」とは、バッチプロセスの単一の実行により生産される、又は生産済みの、材料を指す。
【００１０】
バッチプロセス内の物理的要素を操作する制御レシピは、Ｓ８８標準によってしばしば「手続き型モデル（ｐｒｏｃｅｄｕｒａｌ ｍｏｄｅｌ）」としても指称されている。ＳＳ８８標準によると、この手続き型モデルは、手順の階層順位方式により構成されており、最も高いレベルが下位レベルの各々を包含し、次に高いレベルがその下のレベルの各々を包含する、などといった具合に構成されている。手続き型モデルのレベルには、上から下の順に述べると、「手順（ｐｒｏｃｅｄｕｒｅ）」、「ユニット手順（ｕｎｉｔ ｐｒｏｃｅｄｕｒｅ）」、「動作（ｏｐｅｒａｔｉｏｎ）」、そして「フェーズ（ｐｈａｓｅ：過程段階）」とが含まれ、「手続要素」とは制御レシピ又は手続き型モデルの任意のレベルを指すものである。階層において、最も高いレベルの手順要素が「手順」と呼ばれ、一つ又は複数のユニット手順から成る。各ユニット手順は一つ又は複数の動作から構成されており、各動作は順じて一つ又は複数のフェーズから構成されている。
【００１１】
バッチ実行環境は、（特にＳ８８．０１標準の到来に伴って）ますます複雑になった。一般的に、このような複雑性は、典型的にはますます大規模な制御レシピという形で現れ、また一見して、その一つ一つに含まれる手順要素の数も増加し続けるように思われる。それと同時に、バッチ処理工場のサイズおよび能力もまた成長している。例えば、バッチ処理工場施設は複数の製品「列（ｔｒａｉｎｓ）」を同時に稼動する能力を有するが故に、制御システムには多くのバッチを並列して同時に管理する能力が備わっていることが要求される。しかしながら、レシピの複雑性およびサイズの増大ならびに実際の工場における設備のフレキシビリティ（柔軟性・融通性）の向上に伴い、バッチ処理制御システムにかかる負担も増大している。大規模且つ複雑なレシピに基づいて多くのバッチを読み込んで実行するには、処理能力、メモリ機能、およびその他のリソースを限界に至るまで利用することになる。
【００１２】
例えば、バッチ実行エンジンは、プロセスメモリに制御レシピを読み込んでから、事前に構成された順番で制御レシピの手順要素を実行し始める。様々な手順要素が後で実際に実行されるかどうかに関係なく、手順構造全体が制御レシピのレベルを全て含んだ状態で作成時に読み込まれる。このように、二つの異なる手順のどちらを実行するかの選択によっては、選択されない手順（関連付けられている手順ユニット、動作およびフェーズのいくつか又は全てを含む）が実際に必要とされない場合が存在することも全く可能である。あいにく、どの手順を実際に実行するかの選択は通常、制御レシピを実行するまで分からず、この制御レシピの実行時は通常、作成時に全て手順要素を読み込む時点をはるかに経過した時点のことである。結果として、手順要素のいくつかが実際の実行時に必要とされる・されないにかかわらず読み込まれるので、大量のメモリ、プロセッサ処理時間、およびその他のリソースが手順要素により消費されることになる。結局、工場施設がバッチ実行エンジンに通常読み込むことができるバッチ数がこれらの負担によって制限されることになる。
【００１３】
既に複雑なバッチ実行環境がますます複雑になることにより、工場施設の構成がさらに大規模なものとなる。加えて、当該工場施設の構成は、定期的な保守管理や更新を要するものである。典型的なシステムでは、バッチの実行中には次の二つの構成部分が利用される。即ち、バルブやポンプおよびその他の装置を作動させる下位レベルコントローラと、該下位レベルコントローラを調停、監視および調整する高位レベルのバッチ実行エンジンの二つである。これらの構成部分は両方とも実際の工場の最新モデル（上記の手順モデル、および特定のバッチを実行中に工場設備を制御するのに必要な、前記手順モデルに関連付けられている論理など）を利用する。工場の技術員や監督者は、新製品の製造や能率の増加などに対応できるように工場設備の一部を再構成したい場合もありえる。当該の再構成には、新規の構成と一致するように制御レシピや設備モデルを変更することが含まれうる。このような場合が生じた際には、変更を認識し且つ新規変更を実施できるようにコントローラおよびバッチ実行エンジンを更新すべきである。あいにく様々な理由によりこれら二つの構成部分間の不整合性が生じることがあり、このような場合には通常バッチ全体を一時停止又は中断しなければならなくなり、よって、生産時間の損失、さらには製品の損失につながる。しかしながら、不整合性は無害かもしれず、或いは旧式のモデル又はモデルパラメータを使用して不整合性を実際に克服することも全く可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
制御レシピを実施するため、および制御レシピの実行中に不整合性を解決するためのシステムと方法を提供する。
【課題を解決するための手段】
【００１５】
具体的に、制御レシピは、読込みに必要とされる時間とメモリを最適化するとともに同時処理可能な同時バッチの数を増加しつつ最も複雑な制御レシピさえも実行できる技法を使用して実施される。該技法には、「ジャストインタイム」に、そして制御レシピの作成時にではなく制御レシピの実行時中に利用される場合のみに、レシピの手順要素をインスタンス化して読み込む作業を伴う。制御レシピが手順要素を終了させた時点で（例えば、手順要素の実行が終了した時点で）、手順要素が解体されて制御レシピからアンロード（解放）される。
【００１６】
「ジャストインタイム」処理のためのシステムと方法は、制御レシピの一部として実施されるか、又は制御レシピにより呼び出される、インスタンス化オブジェクト又は手順を利用する。制御レシピの実行時中に呼び出されうる手順要素の各々はインスタンス化オブジェクトと関連付けられている。例えば、バッチ作成時には、手順要素が、関連付けられているインスタンス化オブジェクトに読み込まれうる。特に、手順要素がプロセスの局面を制御するために使用する様々なパラメータが手順要素の論理構造に含まれていない場合、手順要素の論理構造をインスタンス化オブジェクトに読み込みうる。別の実施例における手順要素の論理構造は、手順要素が使用されるにつれてインスタンス化オブジェクト内に生成される。インスタンス化オブジェクトは、実行時中に、手順要素を（制御レシピにより必要とされる場合に）インスタンス化するのに使用される。いったん手順要素が制御レシピの一部として実行されると、インスタンス化オブジェクトは制御レシピからの手順要素を解体するために使用される。それによって手順要素により使用されたリソースを制御レシピの実行にてさらに使用するために再要求（ｒｅｃｌａｉｍ）することができる。
【００１７】
別の態様では、同じインスタンス化オブジェクトを複数の手順要素に使用しうる。例えば、同じ論理構造を利用する複数の手順要素は同じインスタンス化オブジェクトを使用しうる。インスタンス化オブジェクトは論理構造を読み込むか生成し、特定の手順により使用されるパラメータを論理構造に投入する。結果として、作成時に読み込まれる手順要素の数が少なくなるので、リソース使用の削減につながりうる。
【００１８】
さらに、制御レシピの実行中に生じる不整合性を検出し解決するための技法は、不整合性を無視するか、あるいは不整合性を訂正するためにバッチプロセスを中断（保留）するかの選択を可能にする。特に、該技法は、高位レベルのエグゼクティブ（実行）・エンジンおよび下位レベルのコントローラを使用したモデルにおける不整合性を解決する。不整合性についての情報が提供されるようにしても良く、その不整合性についての情報に基づいてバッチプロセスを続けるべきか中断するべきかどうかをバッチ実行エンジン又はバッチ・オペレータが決定するようにしても良い。一実施例では、デフォルトパラメータや、使用するコントローラ全てのためのグローバルパラメータや、以前に使用されたパラメータなどをバッチプロセスが継続して使用することを可能にする。
【００１９】
本発明の第１の態様は、プロセス制御システム内の制御プロセスを実施するためのシステムであって、前記制御プロセスが制御プロセス構造を含み、前記制御プロセスの実行には複数の手順要素の実行が含まれ、前記システムが、制御プロセスの各手順要素が各々関連付けられている複数のインスタンス化オブジェクトと、制御プロセス実行エンジンに制御プロセス構造を読み込み、制御プロセスがインスタンス化された時に制御プロセス実行エンジンに複数のインスタンス化オブジェクトの各々を読み込み、制御プロセス構造が制御プロセス実行中に手順要素を呼び出すにつれて、インスタンス化オブジェクトに関連した手順要素をインスタンス化するために各インスタンス化オブジェクトを使用し、制御プロセスの一部としてインスタンス化された手順要素を実行し、そして制御プロセスの実行中に手順要素の実行が完了するにつれて、インスタンス化された手順要素を解体するためにインスタンス化オブジェクトを使用する、制御プロセス実行オブジェクトと、を含むことを特徴とする。
【００２０】
本発明の第２の態様は、制御プロセスの実行中にプロセス制御システム内の装置モデルにおける不整合性を解決するためのシステムであって、プロセス制御システムのエンティティの第１のモデルを含むプロセスコントローラと、プロセス制御システムのエンティティの第２のモデルを備える制御プロセス実行エンジンであって、制御プロセス実行エンジンがエンティティの第２のモデルに基づいてプロセスコントローラに制御命令を提供し、前記プロセスコントローラがエンティティの第１のモデルに基づいて制御命令を実行するように構成されることを特徴とする、制御プロセス実行エンジンと、制御プロセスの実行中にエンティティの第１および第２のモデル間の相違を検出し、相違の検出に応答してプロンプト（入力要求メッセージ）を生成し、制御プロセスの継続的な動作に関する動作指示を受け取る制御実行オブジェクトであって、前記動作指示が制御プロセスの実行を続けるか、制御プロセスの実行を中断するかのいずれかを含む、制御実行オブジェクトと、を含むことを特徴とする。
【００２１】
本発明の第３の態様は、プロセス制御システム内の制御プロセスを実施する方法であって、制御プロセスが、制御プロセスの実行中に複数の手順要素に対する呼出しを有する制御プロセス構造を含み、前記方法が、手順要素の各々のためにインスタンス化オブジェクトを確立し、制御プロセスの実行中に手順要素が制御プロセスにより呼び出されるにつれて、関連付けられているインスタンス化オブジェクト内に手順要素を構築し、制御プロセスの一部として手順要素を実行することと、いったん手順要素が制御プロセスの一部として実行された時点で、インスタンス化オブジェクト内の手順要素を解体すること、を含み、前記手順要素の解体が制御プロセスの実行中に実行されることを特徴とする。
【００２２】
本発明の第４の態様は、処理および実行環境における不整合性を解決する方法であって、制御パラメータを生成するために、プロセス制御モデルの第１のバージョンに基づいて制御プロセスを実行し、プロセスにおけるコントローラに制御パラメータを伝送し、プロセス制御モデルの第２のバージョンで制御パラメータを使用して制御機能を実行し、プロセス制御モデルの第２のバージョンの制御パラメータ使用能力に基づいて制御プロセスの継続的な動作に関する動作指示を依頼し、プロセス制御モデルの第２のバージョンでパラメータを使用できない場合にプロセス制御モデルの第２のバージョンがエラーを生成し、
動作指示が実行継続指示を含む場合に制御プロセスの実行を続け、動作指示が実行中断指示を含む場合に制御プロセスの実行を中断すること、を含むことを特徴とする。
【００２３】
本発明の第５の態様は、プロセス制御システムにおいてバッチプロセスのために制御レシピを実施する方法であって、制御レシピには、制御レシピの実行中に複数の手順要素に対する呼出しを有する制御レシピ構造が含まれ、前記方法は、手順要素の各々のためにインスタンス化オブジェクトを確立し、制御パラメータを生成するためにプロセス制御モデルの第１のバージョンに基づいて制御レシピを実行し、制御プロセスの実行中に手順要素が制御プロセスにより呼び出されるにつれて、関連付けられているインスタンス化オブジェクトから手順要素を構築し、制御レシピの一部として手順要素を実行することであって、前記手順要素の実行には、バッチプロセスにおいてコントローラに制御パラメータを伝送することと、プロセス制御モデルの第２のバージョンで制御パラメータを使用して制御機能を実行することと、プロセス制御モデルの第２のバージョンの制御パラメータ使用能力に基づいて制御レシピの継続的な動作に関する動作指示を依頼することとが含まれ、プロセス制御モデルの第２のバージョンでパラメータを使用できない場合にプロセス制御モデルの第２のバージョンがエラーを生成し、動作指示が実行継続指示を含む場合にバッチプロセスの実行を継続することであって、前記バッチプロセスの実行の継続には手順要素が制御レシピの一部としていったん実行された時点において手順要素を解体することが含まれ、手順要素の解体が制御レシピの実行中に実行され、動作指示が実行中断指示を含む場合にバッチプロセスの実行を中断すること、を含むことを特徴とする。
【００２４】
本発明の第６の態様は、プロセス制御システムにおいてバッチプロセスのために制御レシピを実施するためのシステムであって、制御レシピが制御レシピ構造を含み、制御レシピの実行には複数の手順要素の実行が含まれ、前記システムが、プロセス制御システムのエンティティの第１のモデルを有するプロセスコントローラと、制御レシピの各手順要素がインスタンス化オブジェクトのうちの一つと関連付けられている複数のインスタンス化オブジェクトと、プロセス制御システムのエンティティの第２のモデルを有するバッチプロセス実行エンジンであって、前記バッチプロセス実行エンジンがエンティティの第２のモデルに基づいてプロセスコントローラに制御命令を提供するように構成され、前記プロセスコントローラがエンティティの第１のモデルに基づいて制御命令を実行するように構成される、バッチプロセス実行エンジンと、バッチプロセス実行エンジンに制御プロセス構造を読み込み、制御プロセスがインスタンス化される場合にバッチプロセス実行エンジンに複数のインスタンス化オブジェクトの各々を読み込み、制御レシピ構造が制御レシピ実行中に手順要素を呼び出すにつれてインスタンス化オブジェクトに関連した手順要素をインスタンス化するために各インスタンス化オブジェクトを使用し、制御レシピの一部としてインスタンス化された手順要素を実行し、制御レシピにおけるインスタンス化された手順要素の実行中にエンティティの第１および第２のモデル間の相違を検出して相違の検出に応答してプロンプトを生成し、バッチプロセスの継続的な動作に関する動作指示を受け取り、前記動作指示がバッチプロセスの実行を継続すること又は制御プロセスの実行を中断することのいずれか一つを含み、動作指示が実行継続指示を含む場合に制御レシピの実行中に手順要素の実行が完了するにつれてインスタンス化された手順要素を解体するためにインスタンス化オブジェクトを使用し、動作指示が実行中断指示を含む場合にバッチプロセスの実行を中断する、バッチプロセス実行オブジェクトと、を含むことを特徴とする。
【図面の簡単な説明】
【００２５】
【図１】バッチプロセス工場施設において実施されるバッチ実行環境を描写する、プロセス工場の一部分の実施例の部分的概略図を示す部分ブロック図である。
【図２】図１のプロセス制御システムの一部分およびバッチプロセスの一部分の実施例の部分的概略図を示す部分ブロック図である。
【図３】バッチ実行環境における様々な手順要素の実行を含む制御レシピ実行例のフローチャートである。
【図４】バッチ実行環境において様々な手順要素をインスタンス化するためにインスタンス化オブジェクトを使用して行う制御レシピ実行例のフローチャートである。
【図５】インスタンス化オブジェクトが手順要素をインスタンス化し、手順要素が実行され、インスタンス化オブジェクトが手順要素を解体する実施例のフローチャートである。
【図６】バッチ実行環境において複数の手順要素をインスタンス化するために同じインスタンス化オブジェクトを使用して行う制御レシピ実行例のフローチャートである。
【図７】高位レベルバッチ実行エンジンと下位レベルコントローラの関係、およびそれにおいて使用されるモデルを描写する、プロセス工場における一部分の実施例の部分的概略図を示す部分ブロック図である。
【図８】高位レベルのバッチ実行エンジンのモデルと下位レベルコントローラのモデルとの間の不整合性を解決する手順の実施例のフローチャートである。
【発明を実施するための最良の形態】
【００２６】
プロセス制御システムは、多種多様な産業分野において工業用工場施設で様々な装置の動作を制御かつ監視するために頻繁に使用される。プロセス制御システムを使用する工業用工場施設の一種として薬物製造施設が挙げられる。薬物製造施設では、段階的なプロセスを通じて、薬剤などをはじめとする特定の物質を大量に生成するためにバッチ処理技法が使用される。精製所を通る天然ガスの流れを制御するために使用される連続処理技法とは対照的に、バッチ処理技法は、製品を生成する個々のステップを指定するレシピなど、順序づけられた一連の離散した工程を伴う。例えば、バッチ処理環境において、完成品又は所望の製品は通常一連の「制御レシピ」として知られるステップを使用して生成される。各ステップには、ヒータやコンベヤベルト、タンク、混合器など、一台又は複数台の設備を使用することが必要とされうる。
【００２７】
また、特定の工場施設は、実質的に並列稼動する複数のレシピを有しうる。一般に製造工場は、バッチ制御システム処理能力の過負荷を防止するように異なる設備機器のグループに論理的に分離される。各グループは特定の設備機器を含み、多くの場合特定の動作に対して指定されるようになっている。一般的に各制御レシピには、特定の製品を製造するための異なるプロセス区域、ユニット、ループ、又は設備機器をはじめとするプロセスの様々なグループを制御する全ての情報（例えば、手順の構造、レシピ・パラメータ、必要設備、など）を含んでいる。例えば、あるレシピは混合槽の使用を必要としうる一方、別のレシピは貯蔵容器中での加熱を伴いうる。これらの制御レシピは１以上の「バッチ」を実行するようにインスタンス化され、バッチ・エグゼクティブ（実行部）又はそれ同等のサブシステムにより進行する。制御レシピを実際に稼動中のバッチにインスタンス化することには通常、例えばバッチ・エグゼクティブにより使用されるメモリーリソースにレシピを読み込むことによりバッチ・エグゼクティブのプロセスに制御レシピを読み込む作業を伴い、バッチ・エグゼクティブはプロセッサおよびその他のコンピューターリソース（様々なハードウェアおよびソフトウェア・リソースを含む）を使用して制御レシピを実行する。
【００２８】
ここで図１を参照すると、バッチ・エグゼクティブにより一つ又は複数の制御プロセス、特にバッチプロセス又はレシピを実施し実行しうる状態で実施例のプロセス工場１０が図示されている。特に、図１に示されるように、プロセス工場５０には、プロセス制御システム５２、一つ又は複数の区域５４、一つ又は複数の装置５６、通信ネットワーク５８および一人又は複数人の装置ユーザ６０が含まれている。プロセス工場５０は、薬物の製造又は生産施設や、精製又は他の化学処理作業や、その他適切なバッチ又は連続プロセス環境を構成しうる。開示の実施形態において、プロセス工場５０では、バッチ・レシピなど少なくとも一つのバッチ処理技法を使用する。
【００２９】
プロセス制御システム５２は、通信ネットワーク５８を通じて装置５６を制御、命令、監視、テスト、装置５６と通信、及び（それ以外の場合）装置５６を使用することの少なくとも一つを行うように作動する、ハードウェア及び／又はソフトウェアを構成することができる。例えば、プロセス制御システム５２には、テキサス州オースティン市を所在地とするＥｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ ＬＬＰ社により販売されるＤｅｌｔａＶ（登録商標）システムを使用することができる。一般に、プロセス制御システム５２は、装置５６へのアクセスを制御し、装置５６が装置ユーザ６０により使用されるスケジュールを作成する。通信ネットワーク５８は、プロセス制御システム５２、区域５４、装置５６および装置ユーザ６０間のデータ通信をサポートし、且つ、いかなる所望のハードワイヤード式及び／又はワイヤレス通信構造、又はその他にもイーサネット（登録商標）やＦｏｕｎｄａｔｉｏｎ（登録商標） Ｆｉｅｌｄｂｕｓ又はＰｒｏｆｉｂｕｓ（登録商標）プロトコルなどの適切な通信プロトコルを使用して、任意の所望のバスを基盤とするか、又はバスを基盤としないハードウェアを単独で、又は様々な組合せのいずれかで使用することにより実施することができる。
【００３０】
区域５４とは、プロセス工場５０、装置５６および装置ユーザ６０の論理的及び／又は物理的編成のことである。一般的に区域５４は、工場施設５０にて使用されるレシピのステップを実行するのに使用される装置５６を編成するために使用される。区域５４の編成は、工場施設５０における装置５６の物理的位置、又は、工場施設５０における装置５６の論理編成、又は、適切であれば装置５６の物理的および論理的な編成の組合せに基づきうる。例えば、バッチ処理動作は、受入れ、準備、処理および出荷などの個々別々の区域５４に分割されることができる。前回の実施例を続けて使用すると、薬物生成プロセスの原材料を受入れ区域にて受け取り、準備区域にて変更され、処理区域にて目標とする薬物を生成するために混合・処理され、その後、当該標的薬物が出荷区域で梱包され、そこから出荷されるようにすることができる。異なる製薬を生成するために使用される各種機器など、区域５４内にある装置５６は、異なるタイプの最終製品を生産する一部として使用されうる。また、一実施形態における区域５４は、単一のグループとして取り扱うにはあまりにも多過ぎる装置５６および装置ユーザ６０がシステム５２に存在するといった問題に対する現実的解決方法も提供する。その他のプロセス監視機能を実行しながら多数の装置５６を管理する際にも、プロセス制御システム５２の速度が遅くならないようにするために大規模なレシピの処理を分割するのにも区域５４を利用することができる。
【００３１】
装置５６は各々、バルブ、タンク、ポンプ、コンベヤベルト、混合機、ヒータ、又はその他工場施設５０で実行されるプロセスの一部として使用できる適切な装置を構成することができる。装置５６は、異なる装置ユーザ６０によりバッチプロセスの異なる部分で、様々な時点において使用されうる。例えば、特定のヒータ装置５６を、ある最終製品に使用される第１の物質に使用してから清掃し、後で異なる最終製品に使用される第２の物質に使用するようにしても良い。
【００３２】
装置ユーザ６０とは、装置５６を使用する物理的又は論理エンティティ（実体）のことである。例えば、ユーザ６０とは、特定の製品を生産するために特定の順で装置５６を使用するプロセス制御システム５２により実行される特定のレシピを指すことができる。装置ユーザ６０は装置５６自身であってもよい。例えば、ポンプ装置が特定の材料をタンク装置に充填できるように、ポンプ装置はタンク装置にアクセスを求めるが、その際ポンプ装置は装置ユーザとしての機能を果たしうる。さらに、装置ユーザ６０は、原材料など生産工程自体の一部として使用される材料を指す場合もある。例えば、現在タンクに格納されている第１の物質は、レシピの一部として第１の物質をヒータに移動させるためにポンプへのアクセスを求める場合もある。また、装置ユーザ６０は、プロセス制御システム５２により直接に制御されていないが、プロセス制御システム５２から装置５６にアクセスを求める場合のある、人間又はその他のエンティティ（実体）でもありうる。一般に装置ユーザ６０は、人間、材料、ハードウェア、ソフトウェア、及びその他のプロセス制御システム５２の制御下で製品を生産するために工場施設５０により使用される装置５６のうちの少なくとも１つでありうる。
【００３３】
稼動中に一人又は複数人の人間ユーザ（図示せず）は、プロセス制御システム５２を使用して一つ又は複数のレシピ、バッチプロセス又はその他のプロセスの実行を構成、制御および監視することができる。レシピは、一つ又は複数の所望の最終製品を生成するためにプロセス工場５０で利用可能な装置５６を使用して実行される。プロセス制御システム５２は、二つのユーザ６０が同じ装置５６を同時に使用しようとしないように、装置ユーザ６０による装置５６へのアクセスの制御をつかさどる。
【００３４】
図２は、区域５４と交信するプロセス制御システム５２のより詳細な図である。一般的に、プロセスコントローラ１２は、例えば一実施例ではイーサネット（登録商標）通信接続でありうるローカルエリアネットワーク（ＬＡＮ）１５を介して多数のワークステーション１４に連結されている。また、コントローラ１２は、プロセス工場内の装置又は設備機器（全体として５６の参照番号で示される）に、一つ又は複数の入出力（Ｉ／Ｏ）装置（図示せず）および一式の通信線及び／又はバス１８を介して連結される。コントローラ１２（例としては、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ社により販売されるＤｅｌｔａＶ（登録商標）バッチコントローラが挙げられる）は、一つ又は複数のプロセス制御ルーチンを実行することによってプロセス工場５０の所望の制御を実施するためにプロセス工場５０全体にわたり分散される、フィールド装置およびフィールド装置内の機能ブロックなどの制御要素と通信できる。これらのプロセス制御ルーチンは、連続プロセス制御ルーチンでありうるが、本明細書においてはバッチプロセス制御ルーチン又は手順として記載される。ワークステーション１４（例えばパーソナルコンピュータ、サーバ、などでありうる）は、コントローラ１２と通信すべくコントローラ１２により実行される、一つ又は複数のプロセス制御ルーチンを設計および実行するため、前記のようなプロセス制御ルーチンをダウンロードのために通信するため、プロセス工場５０の稼動中にプロセス工場５０に関する情報を受信および表示するため、またそれ以外の場合は例えばコントローラ１２により実行されるプロセス制御ルーチンと交信するために、一人又は複数人のエンジニア又はオペレータ又はその他のユーザにより使用されることができる。また、データ・ヒストリアン１９は、ＬＡＮ１５に接続してもよく、任意の周知又は所望の方法にて、工場５０内（コントローラ１２やフィールド装置ならびにワークステーション１４内を含む）で生成されたデータを自動的に収集し格納するようにしてもよい。
【００３５】
ワークステーション１４の各々は、構成設計用アプリケーションなどのアプリケーションを格納するため、及び、プロセス工場５０の構成に関する構成データなどのデータを格納するためのメモリ２０を含んでいる。ワークステーション１４の各々はまた、数ある特徴のなかでも特に、ユーザがバッチ制御ルーチンなどのプロセス制御ルーチンを設計すること且つこれらのプロセス制御ルーチンをコントローラ１２にダウンロードすることを可能にする、一つ又は複数のアプリケーションを実行するプロセッサ２１も含んでいる。同様に、コントローラ１２は、プロセス工場５０の制御に使用されるプロセス制御ルーチンと構成データを格納するためのメモリ２２を含んでおり、また、プロセス制御法を実施するためにプロセス制御ルーチンを実行するプロセッサ２４を含んでいる。コントローラ１２がＤｅｌｔａＶ（登録商標）バッチコントローラの場合、それはワークステーション１４のうちの一つにある一つ又は複数のアプリケーションと連動して、プロセス制御ルーチン内の制御要素およびこれらの制御要素がプロセス工場５０の制御を提供する構成のされ方を示すことにより、コントローラ１２内のプロセス制御ルーチンのグラフィック描写をユーザに提供しうる。
【００３６】
図２に示される実施例では、コントローラ１２がバス１８を介して同じように構成された２組の設備機器に通信可能に接続されており、当該設備機器の各組は、ここでは反応装置＿０１又は反応装置＿０２として示される反応処理ユニットと、フィルタ＿０１又はフィルタ＿０２として示されるフィルタユニットと、乾燥器＿０１又は乾燥器＿０２として示される乾燥器ユニットとを備えている。反応器＿０１には、反応器槽１００と、例えばヘッドタンク（図示せず）から反応器槽１００へ流体を供給する流体入口配管を制御するように接続された二つの入力バルブ１０１および１０２と、流体出口配管を介して反応器槽１００からの流体の流れを制御するように接続された出力バルブ１０３とが含まれる。温度センサ、圧力センサ、液面計測器などのセンサ又は電気的なヒータや蒸気ヒータなどの他の何らかの設備機器であってよい装置１０５は、反応器槽１００に、又は該反応器槽の付近に配置される。反応器＿０１は、乾燥器設備１２０を有する乾燥器＿０１に順じて連結されるフィルタ設備１１０を有するフィルタ＿０１にバルブ１０３を介して連結される。同様に、二台目の設備機器には、反応器槽２００、二つの入力バルブ２０１と２０２、出力バルブ２０３および装置２０５を有する反応器＿０２が含まれている。反応器＿０２は、乾燥器設備２２０を有する乾燥器＿０２に続いて連結されるフィルタ設備２１０を有するフィルタ＿０２に連結される。フィルタ設備１１０，２１０および乾燥器設備１２０，２２０は、それに関連するさらに別の制御要素（ヒータ、コンベヤベルトおよびそれ同等のもの等）およびセンサなどを備えうる。図示されていないが、望ましい場合は、各反応器、フィルタおよび乾燥器のうちの一つを使用するバッチの実行が図２に示される設備機器の任意の組合せを使用できるように、各々のフィルタユニット（フィルタ＿０１およびフィルタ＿０２）を各々の反応器・ユニット（反応器＿０１および反応器＿０２）に物理的に連結し、各々の乾燥器ユニット（乾燥器＿０１および乾燥器＿０２）を各々のフィルタユニット（フィルタ＿０１およびフィルタ＿０２）に連結してもよい。
【００３７】
図２に図示されるように、コントローラ１２は、バス１８を介して、バルブ１０１，１０３，２０１，２０３に、装置１０５，２０５に、フィルタ１１０，２１０に、乾燥器１２０，２２０に（およびそれに関連する他の設備に）通信可能に連結され、これらの（ユニット、フィールド装置などであってよい）要素の作動を制御し、これらの要素に関しての一つ又は複数の動作を行う。このような動作としては、例えば反応器槽（又は乾燥器）の充填、反応器槽又は乾燥器内の材料の加熱、反応器槽又は乾燥器の中身の排出、反応器槽又は乾燥器の清浄、フィルタの操作などが挙げられる。もちろん、コントローラ１２は、例えば４−２０ｍａ回線、ＨＡＲＴ（登録商標）通信線などの専用の通信線を介して、さらには別のバスを介して、プロセス工場５０内の要素に連結することも可能である。
【００３８】
図１に図示されるバルブ、センサおよびその他の設備機器は、例えばＦｉｅｌｄｂｕｓフィールド装置、標準の４‐２０ ｍａフィールド装置、ＨＡＲＴ（登録商標）フィールド装置などをはじめとするいかなる所望の種類又はタイプの設備であってもよく、Ｆｉｅｌｄｂｕｓプロトコル、ＨＡＲＴ（登録商標）プロトコル、４−２０ ｍａアナログ・プロトコルなどの任意の周知又は所望の通信プロトコルを使用してコントローラ１２と通信することができる。さらにまた、その他のタイプの装置を、所望の任意の方法にて、コントローラ１２に接続し、コントローラ１２により制御してもよい。また、プロセス工場５０に関連したその他の装置又は区域を制御するために、その他のコントローラを、例えばイーサネット（登録商標）通信回線１５を介してコントローラ１２およびワークステーション１４に接続しても良い。また、任意の所望の又は周知の様態において、このような付加的なコントローラの動作は図２に示されるコントローラ１２の動作と協調することができる。
【００３９】
一般的に言って、例えば一つ又は複数の制御レシピに従ってプロセス工場５０内の異なるバッチ稼動を実施し、場合によっては協調させるバッチ実行アプリケーションをワークステーション１４の一つによって実行する、バッチプロセスを実施するために、図２のプロセス制御システムを使用しうる。このようなバッチ実行エンジン３０は、図１のワークステーション１４ａに格納された状態で図示されている。この場合当然のことながら、バッチ実行エンジン３０は、それ以外のワークステーション１４、又は任意のワイヤレス（無線）形態を含む任意の所望の形態でバス１５又はバス１８に通信可能に接続されたその他のコンピューターにおいて格納および実行できるはずである。同様に、望ましい場合はバッチ実行エンジン３０を、様々な構成素子に分割してもよく、あるいは、プロセス工場５０内の異なるコンピューター又はワークステーションに格納され、そこで実行される様々な構成要素に関連付けられてもよい。
【００４０】
バッチ実行エンジン３０は一般に先述の制御レシピなどの高レベルの制御ルーチンである。ユーザがプロセス工場内で実行すべき複数のバッチ稼動を指定できるようにし、根本的に独立してプロセス工場制御ネットワーク１０内で動作するように複数の異なるバッチ稼動又はバッチプロセスを設定するバッチキャンペーン管理機能と一般に呼ばれるものが、該バッチ実行エンジン３０には含まれうる。また、バッチ実行エンジン３０は、キャンペーン管理機能により指定された異なるバッチの実行を実施および監視するバッチ・エクゼクティブ・ルーチン又はアプリケーションを含みうる。このようなバッチの実行はそれぞれ、各々がプロセス工場１６内の反応器・ユニット、フィルタユニット、乾燥器ユニット、又はその他の設備機器の一つなどの単一ユニット上で作動するサブルーチン又はプロセスである（又はありうる）一つ又は複数の処理手順、ユニット手順、動作、フェーズ、およびその他のバッチ小区分の動作を指示する。この実施例において、各ユニット手順（一般的にワークステーション１４のうちの一つで実行されるバッチ実行の一部である）は、それぞれが物理的ユニットの一つ又は複数のフェーズを実行しうる一連の動作を実行することができる。これを説明するにあたって、フェーズ、動作、ユニット手順および手順という用語は、Ｓ８８標準により定義される手順要素のそれらを指しうるものである。従って、フェーズとは、実行される最下位レベルのアクション又はステップであり、通常はコントローラ１２の一つにおいて実施又は実行されるものである。また、動作とは、特定の機能を実行する一組のフェーズであり、通常はコントローラ１２内の一連のフェーズを呼び出すことによりワークステーション１４の一つで実施又は実行される。ユニット手順とは、実行される一連の一つ又は複数の動作で、通常ワークステーション１４の一つにおける一式の動作呼出しとして実施される。同様に、手順とは、制御レシピ内のステップとして実施され、例えばプロセス工場５０内の異なる物理的装置又は設備機器上で実行されうる一式のユニット手順でありうる。しかるに、手順はいかなるものでも一つ又は複数のユニット手順を含むことができ、ユニット手順はいかなるものでも一つ又は複数のフェーズ且つ又は一つ又は複数の動作を含むことができる。このように、各バッチプロセスは、例えば食品製品や薬物などの製品を生産するために必要とされる異なるステップ又は段階（例えば、ユニット手順）を実行する。「手順要素」という用語は、本稿において手続き型モデルのこれらのレベルの任意の実施形態又は実装を示す意味で使用されており、「手順」のレベル又はその他手続き型モデルの単一レベルだけに限定されるものではない。
【００４１】
個々のバッチに対して異なる手順、ユニット手順、動作およびフェーズを実施するために、制御レシピは、実行されるべきステップと、ステップに関連した量および時間およびステップの順序を指定する。一つのレシピのためのステップには、例えば反応器槽に適切な材料又は成分を充填すること、反応器槽内の材料を混合すること、特定の時間をかけて反応器槽内の材料を特定の温度に加熱すること、反応器槽を空にしてから次のバッチのための準備として反応器槽を清掃すること、反応装置の生産物をろ過するためにフィルタを稼動すること、そしてその後に反応器槽中で生成された製品を乾燥させるために乾燥器を稼動すること、を含んでよい。異なるユニットに関連する各一連のステップはバッチのユニット手順を定義し、制御レシピはこれらユニット手順の各々に対して異なる制御アルゴリズムを実行することになる。もちろん、特定の材料、材料の量、加熱温度および時間などは、レシピごとに異なっていてよい。その結果として、これらのパラメータは、製造又は生産される製品および使用されるレシピによってバッチの稼動ごとに変化しうる。
【００４２】
当業者にとっては当然のことながら、業界標準による（汎用）バッチプロセスにおける同一のフェーズ、動作、ユニット手順および手順は、異なる実際のバッチプロセス又はバッチ実行の一部として同時に又は異なる時点で、図２に示されるような異なる反応器ユニットのそれぞれで実施できる。さらに、通常図２の反応処理ユニットには同じ数又はタイプの設備機器（すなわち、これらは同じユニット・クラスに属する）が含まれているので、異なる反応処理ユニットの各々を制御するために特定のフェーズについて同じ業界標準により構成されるフェーズ制御ルーチンを使用しうる。但しこれは、異なる反応処理ユニットに関連した異なるハードウェア又は設備機器を制御するには当該の業界標準によるフェーズ制御ルーチンを修正変更しなければならない場合を除く。例えば、（反応処理ユニットが充填される段階である）反応装置＿０１の充填フェーズを実施するために、充填制御ルーチンは、一つ又は複数の入力バルブ１０１又は１０２を特定の時間（例えば、容器槽１００が満タンになったことを液面レベル計測器１０５が検知するまで）開くことになる。しかしながら、この同じ制御ルーチンを使用して、単に入力バルブの指示をバルブ１０１又は１０２の代わりにバルブ２０１又は２０２に変更するとともに、液面レベル計測器の指示を液面レベル計測器１０５の代わりに液面計測器２０５に変更するだけで、反応装置＿０２の充填フェーズを実施することができる。
【００４３】
図３は、バッチ実行エンジン３０において実施され、バッチ実行エンジン３０により実行される制御レシピ３００の実行例を示す。以下の実施例は、手順要素が区域内の設備又は装置の制御に関係する状態を例として手順要素に関連して説明されているが、当然のことながら、例えば手順要素がプロセス内の異なる区域に関係するなど、手順要素がプロセスの階層中の高位レベルに関係しうるし、もしくは、例えば手順要素が異なるユニット、異なるループ、異なる設備などに関係するなど、手順要素はプロセスの階層の下位レベルにも関係しうることが分かるはずである。同様に、制御レシピにおける手順要素の実施は、制御レシピの階層における様々なレベル（あらゆる手順、ユニット手順、動作又はフェーズを含む）を参照して行われることが分かるはずである。従って、制御レシピの実行は、一つ又は複数のバッチプロセスの高レベル実行に関係して、又はバッチ稼動中にプロセスの下位レベル実行に関係して行われうることが分かるはずである。このように、制御レシピ実行３００と、制御レシピを実施するためのここに記載される技法は、バッチプロセス内のあらゆるレベルの実行に適用されうる。
【００４４】
図３に示されるように、制御レシピは上記のように手順要素又はステップの階層を含んでいる。それぞれの手順要素又はステップは、制御レシピによって特定の順に実行するように構成され、制御レシピの実行は、二つ以上の手順要素間でいくつかの決定樹状図を含みうる。各決定ごとに行われる手順要素の選択は、プロセスの状態や、プロセスから送り返されたパラメータや、制御レシピ内の前回の手順要素の結果、又はバッチ稼動に関係する多種多様な要因の任意のものを含む多種多様な要因に依存しうる。従って、他ならずある一つの手順要素を利用する決定により、選択された手順要素の実行がもたらされ、選択されなかった１以上の手順要素は実行されない。但し、選択されなかった１以上の手順要素は、制御レシピの実行中に別のところで実行される場合もある。しかし、選択されなかった手順要素がバッチ稼動中に一度も実行されない可能性があることに変わりはない。
【００４５】
特に、図３を参照するに、制御レシピの実行は、ブロック３０２で第１の手順要素の実行とともに開始し、その後に続くブロック３０４では、ブロック３０６で第２の手順要素を実行するか、ブロック３０８で第３の手順要素を実行するかの決定が下される。ブロック３０４での決定は、ブロック３０２における第１の手順要素から得られる結果に依存しうる。例えば、ブロック３０２での第１の手順要素が反応器槽の反応装置＿０１ １００を充填して反応処理を実行することになっている場合、ブロック３０４での決定は、センサ１０５からの計測に基づいて反応処理が完了したかどうかを判断することに基づくことができる。反応処理が全て完了した場合、制御レシピは、フィルタ１１０に反応装置１００の中身を出力するためにバルブ１０３を開くべく、ブロック３０６の第２の手順要素に進んでよい。反応処理が完了していない場合、制御レシピは、ブロック３０８で第３の手順要素（及び、場合によっては、それ以降の決定に依存しうるそれ以降の手順要素）を使用することにより反応処理を継続又は繰り返してよく、この場合制御はブロック３０６の第２の手順要素に戻る。或いは、ブロック３０６の第３の手順要素は、フィルタ１１０に反応装置１００の中身を出力するためにバルブ１０３を開くことも行いうるが、第３の手順要素は異なる様態で関係することになり、この場合、第２の手順要素が選択された場合のバッチプロセスの実行に照らして（と比較して）バッチプロセスが実行される。
【００４６】
このように、制御レシピは、任意数の手順要素（手順１−Ｎ）３０２、３０４、３０８、３１２、３１４、３１８、３２０の将来的に行われる可能性のある実行に関与しうる。なお、制御レシピの実行中に下される決定３０６、３１０、３１６によっては、これらの手順要素の全てが制御レシピの実行中に実行されるとは限らない。図３に示される手順３、４、５、・・・Ｎのうちのいずれかは、制御レシピの実行中に実行されない場合もある。現に、例えばブロック３０８で手順３として表される手順要素は、制御レシピ内のブロック３０４における「ＯＲ」決定点で下される選択によっては実際に必要とされない場合もある。一方、手順要素のいくつかは、制御レシピ（例えば、手順１と手順２）の実行中に必ず実行されてよい。
【００４７】
また図３に示されるように、制御レシピの実行中に行われる手順要素（例えば、手順２）の実行には、手順のステップの階層構造中に配列される一つ又は複数の下位手順要素の実行がさらに含まれうる。例えば、ブロック３０６での第２の手順要素がバルブ１０３を開き且つ反応装置１００の中身をフィルタ１１０に出力するための動作に関与している場合、下位手順要素は、フィルタ１１０を作動するためにインスタンス化された別の下位手順要素（例えば、フェーズ）を伴い、自己の開口を制御するためにインスタンス化されたフェーズでありうる。制御レシピの実行と同様に、手順要素の実行も一つ又は複数の決定を伴いうる。従って、下位手順要素のいくつかは、手順要素の実行の一環として必ず実行される反面、その他の下位手順要素は手順要素の実行中に実行されない場合がある。さらにまた、手順要素内の下位手順要素にはさらなる下位手順要素を含んでよく、さらに下位の手順要素についても同様である。例えば、上記されるように、制御レシピは、それぞれがユニット手順を含みうる手順をいくつか含みうるし、また該ユニット手順は動作を含みうるし、動作はフェーズを含みうる。このように、図３に示される制御レシピは実際に高位レベルの制御レシピ内に含まれる手順要素でありうる。
【００４８】
当然のことながら、本稿において手順要素および下位手順要素という用語は、全体的なバッチプロセスの階層中の異なるレベルにある手順要素間の関係は下記される請求の範囲を限定するものとして解釈されるべきでないことを明らかにする意図のもとにだけ用いられている、と理解されたい。例えば、階層のあるレベルに属する手順要素（例えば、ユニット手順）は、階層の別のレベル（例えば、手順）に関して考慮した場合に下位手順要素としてみなされうる。逆に、階層中のあるレベルに属する下位手順要素は、階層中の別のレベルの（例えば、フェーズ）に関して考慮した場合に手順要素としてみなされうる。このように、あらゆる手順要素又は下位手順要素は、それ自体が各々、全体的なバッチプロセス制御の階層中の異なるレベルで制御レシピと関係しうる。さらに、制御レシピ実行３００が種々様々な決定３０４、３１０、３１６を含んだ状態で示されているが、当然のことながら、制御レシピの実行には、事前に構成された順に実行される一連の手順要素が含まれてよく、手順要素の各々が制御レシピの実行中に実行される。
【００４９】
図４は、制御レシピの実行中に各手順要素をインスタンス化するために一つ又は複数のインスタンス化オブジェクト又はプロセスを実施する制御レシピの構造の実施例である。具体的には、制御プロセス実行オブジェクト又はプロセスを使用して、バッチ実行エンジン３０はバッチ生成の時点で制御レシピの構造を読み込み、制御レシピがインスタンス化されるか、もしくは読み込まれた時点でインスタンス化オブジェクトを読み込むことができる。バッチを稼動するのに使用しうる全ての手順要素、構造、レシピ・パラメータ、設備機器などを含む制御レシピ構造全体を読み込む、典型的な制御レシピ実行と比較した場合、インスタンス化オブジェクトは、手順要素が制御レシピにより利用されるにつれて（利用される際に）、それぞれの手順要素をインスタンス化するために使用される。繰り返して言うが、特定の手順要素が制御プロセスの実行中に実際に実行されうるかどうかに関する選択は、作成時（例えば、制御レシピが実行に向けて読み込まれた場合）に分かる場合もあれば、実行時（例えば、制御レシピの実行）まで分からない場合もある。手順要素が実行された後、インスタンス化オブジェクトは制御レシピから手順要素をアンロードし、制御レシピは実行を続ける。別の言い方をすると、制御レシピに含まれる様々な手順要素は、作成時にではなく、むしろ必要とされた場合にだけ「ジャストインタイム」で読み込まれる。制御レシピにより手順要素が利用される際にそれぞれの手順要素をインスタンス化するためにインスタンス化オブジェクトを使うことにより、それぞれの手順要素は概して、手順要素が実行される間のみ、プロセス制御システム５２（例えば、メモリ、プロセッサ、ソフトウェア、など）のリソースを利用する。さらに、手順要素のインスタンス化を作成時にではなく必要な時だけに行うようにすることにより、制御レシピの実行中に実際に使用される手順要素だけが、プロセスシステム５２のリソースを利用することになる。結果として、リソースの利用の点で、バッチ実行エンジン３０（および一般にプロセスシステム５２）の性能の能率向上（例えば、プロセッサ利用率の向上、メモリーリソース使用率の向上、など）を実現することができる。
【００５０】
図４を参照すると、制御レシピの論理構造が、手順ハイドレータとして示される（例えば、Ｐｒｏｃ＿Ｈｙｄｒａ １Ｎ）複数のインスタンス化オブジェクトに関連して示されている。図に示されるように、制御レシピの論理構造は、様々な手順要素およびあらゆる「ＯＲ」決定点の実施においてあらかじめ定義された論理的な順序を伴う点で、図３に示される構造に類似する。しかしながら、制御レシピの論理構造は、制御レシピの実行中に呼び出されうる全手順要素をはじめとし、バッチ作成時に制御レシピ全体を読み込むのではなく、手順要素無しでバッチ実行エンジン３０に読み込まれる。一実施例において、制御レシピの論理構造は、制御レシピの論理的な流れ、「ＯＲ」決定点、および制御レシピの実行中に呼び出されうる可能な手順要素のそれぞれと関連付けられているマーカー又は呼出しを参照できる。
【００５１】
また、バッチ作成時には、インスタンス化オブジェクトの各々をバッチ実行エンジン３０に読み込むことができる。図４に示され、図３と比較した場合、インスタンス化オブジェクトは、制御レシピの実行中に実行されうる手順要素のそれぞれと関連付けられている。一実施例においては、インスタンス化オブジェクトの各々を制御レシピの論理構造において実施してよい。一方、制御レシピの論理構造内の呼出し又はマーカーは、手順要素をインスタンス化するのに必要とされる場合に各インスタンス化オブジェクトを呼び出すために使用することができる。
【００５２】
バッチ実行時および制御レシピ実行中に、各手順要素は、各手順要素がリソースを必要な時のみ使用するように手順要素の実行所要時間内にインスタンス化され、実行され、解体される。例えば、バッチプロセスの実行時中に、バッチ実行エンジン３０は、図３に示される手順要素１のインスタンス化を行うためにブロック４０２のインスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ １を使用して図４の制御レシピを開始する。いったん手順要素１が実行されると、バッチ実行エンジン３０は、手順要素１を解体するためにインスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ １を使用し、それによって、その実行中に手順要素１に割り当てられた全てのリソースは、割当て解除されてバッチ実行エンジン３０に戻される（又は解放される）。その後、制御レシピの実行は、手順２又は手順３に進むかの決定を提示する決定点４０４に達する。（なお、手順２又は手順３のどちらに進むかの選択は前回手順１の実行によって決定される。）制御レシピの論理に基づいて手順３が選択されると、インスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ ３は手順３をインスタンス化するために使用され、その一方、手順２が選択されると、インスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ ２は手順２をインスタンス化するために使用される。従って、制御レシピの実行は、実行中に呼び出されうる手順要素３０２、３０６、３０８、３１２、３１４、３１８、３２０の各々を、（ここに記載される順で）各々インスタンス化オブジェクト４０２、４０８、４０６、４１２、４１４、４１８、４２０と置き換えるか、又はインスタンス化オブジェクト４０２、４０８、４０６、４１２、４１４、４１８、４２０に呼出しをかける。
【００５３】
インスタンス化オブジェクトは、手順要素中に呼び出されるあらゆる下位手順要素に対して同じような方法で使用することができる。例えば、実行手順２において、手順要素の論理構造はインスタンス化オブジェクトを含んでよく、或いはインスタンス化オブジェクトに呼出しをかける。下位手順要素（例えば、ユニット手順、動作、フェーズ、など）が手順要素（例えば、手順２）の実行中に必要とされる場合には、インスタンス化オブジェクトは、下位手順要素が手順要素の実行時中に実行され、下位手順要素の完了時に解体されるように、関連付けられている下位手順要素をインスタンス化するために使用される。手順要素は必要に応じて継続してもよく、又は終了し手順要素に関連するインスタンス化オブジェクトにより解体されてもよい。これによって制御レシピは必要に応じて実行を続ける。このように、インスタンス化オブジェクトを制御レシピ内の様々な階層レベルにも同様に適用できることが分かる。
【００５４】
図５は、制御レシピにより使用される手順要素をインスタンス化し解体するためにインスタンス化オブジェクトにより使用されるプロセスの実施例である。インスタンス化オブジェクトは、それが関連付けられており、作成時にインスタンス化オブジェクトに読み込みうる手順要素の論理構造を含むことができる。あるいは、インスタンス化オブジェクトには、手順要素がインスタンス化される時に手順要素の論理構造がどのように実施されるかを認識して手順要素の論理構造を構築する論理モジュール又はルーチンが含まれうる。
【００５５】
各インスタンス化オブジェクトは、手順要素の論理構造内のパラメータを実施する方法を認識する論理モジュール又はルーチンをさらに含んでよい。具体的には、インスタンス化オブジェクトは、異なるパラメータを伴う手順要素を生成する方法を理解する。この場合、実行時属性などの論理的文法項、又は制御レシピの実行中に開発された論理的文法項、そしてプロセス制御変数、プロセス制御データ、装置利用率などがパラメータに含まれうる。例えば、ブロック４０２における手順２のためのインスタンス化オブジェクトは、制御レシピにより実行された時に手順１から導かれた計測データ（例えば、反応装置１００を充填するために使用される製品の量）を利用する方法を理解することができる。手順２のためのインスタンス化オブジェクトはさらに、反応装置１００に関する装置情報（例えば、充填状態、圧力）を、手順２をインスタンス化する際に利用する方法を理解することができる（例えば、バルブ１０３を開くための移動距離および速度）。さらにまた、インスタンス化オブジェクトは、手順２において使用される装置のパラメータ（例えば、およびバルブ、診断の情報）を考慮することができる。インスタンス化オブジェクトはこのように、実行中に手順要素により使用されることになっているパラメータを伴う、関連付けられている手順要素の論理構造を構築しデータ投入することができる。
【００５６】
図５を参照すると、インスタンス化オブジェクト（Ｐｒｏｃ＿Ｈｙｄｒａ）は、ブロック５０２における制御レシピ又はバッチ実行エンジン３０により起発動されるか又は呼び出されるのを待機してよい。例えば、インスタンス化オブジェクトは、インスタンス化オブジェクトに関連した手順要素の呼出しに基づいて起動又は呼び出されることができ、制御レシピの論理構造に含まれるかどうかに基づいて起動されることができ、又は制御レシピの論理構造におけるインスタンス化オブジェクトのマーカー或いは呼出しを含むかどうかに基づいて呼び出されることができる。
【００５７】
インスタンス化オブジェクトがブロック５０２にて呼び出されるか、又は起動されると、インスタンス化オブジェクトは、関連付けられている手順要素により、又はその内部で、インスタンス化される。上記に示されるように、各インスタンス化オブジェクトは、バッチ実行エンジン３０に、読み込まれたインスタンス化オブジェクトに関連付けられている手順要素の論理構造を伴って読み込まれうる。一方、ブロック５０４では、インスタンス化オブジェクトは上記参照される論理モジュール又はルーチンを使用して、あらゆる下位手順要素に対する考慮を含む手順要素の論理構造を構築しうる。いったん手順要素の論理構造が構築されると（もしくは読み出されると）、インスタンス化オブジェクトはブロック５０６で、前回実行された手順要素により導かれたか又はそれに基づくパラメータを含む、制御レシピの実行時中に導かれたパラメータを含むか又はパラメータに基づいていてよい、手順要素のパラメータを読み出す。上記されるようにパラメータは、使用する設備機器、プロセス制御データ、プロセス制御変数、論理的文法項又は属性など（但しこれらに限定されない）を含むことができる。
【００５８】
ブロック５０８にてインスタンス化オブジェクトは、手順要素のインスタンス化を終了させるために、ブロック５０６に読み出されたパラメータと手順要素の論理構造をマージする。インスタンス化オブジェクトの論理は、（バッチ実行エンジン３０により誘導されうる）実行を行うために手順要素により必要とされる場合にパラメータおよび論理構造をマージするために提供される。その後、手順要素は、ブロック５１０にて制御レシピ内の実行用のバッチ実行エンジン３０に読み込まれる。
【００５９】
ブロック５１２では、手順要素が実行を終えるのをインスタンス化オブジェクトが待つ。手順要素が実行された場合（インスタンス化オブジェクトが発動又は呼び出されることで実行されたことが示される）、インスタンス化オブジェクトはブロック５１４にて手順要素を解体するために使用される。具体的には、インスタンス化オブジェクトは、バッチ実行エンジン３０からの手順要素をアンロードしてもよく、それによって、バッチ実行エンジン・リソースを解放し、手順要素の論理構造からパラメータを取り除く。インスタンス化オブジェクトは、手順要素の論理構造を維持しうる、又は論理構造を解体しうる。その後、インスタンス化オブジェクトは、制御をブロック５０２に戻して、制御レシピの実行中に必要に応じて再起動又は再呼出し可能な状態になる。
【００６０】
図６は、バッチ実行環境における制御レシピの上記の実施に使用されることができるインスタンス化オブジェクトのさらなる態様を例示する。特に、制御レシピの実行に使用される多くの手順要素が同じ論理構造を利用するか、或いは手順要素間の相違はその中に利用されているパラメータにだけ存在する。根本的に、同じ論理構造が制御レシピ実行の間に何度も利用される。但し、上記の説明からも分かるように、手順要素により利用されるパラメータは、実行時（即ち、制御レシピの実行中）まで分からない場合もある。
【００６１】
例えば、図３を再び参照すると、手順４および手順５の間の相違は、手順４は反応装置１００上で稼動するが、手順５は反応装置２００上で稼動するということである。手順４および手順５のそれ以外の論理構造は同じで、それに関連する設備機器およびパラメータだけが異なる。別の実施例として、手順１が反応装置１００を使用した反応工程を伴う場合には、決定点３０４での決定ステップにより、再び手順３を使用して反応工程を稼動する必要があるのか、或いは手順２を使用してバッチプロセスを続けるのかどうかが決定されうる。異なるパラメータ（例えば、異なる反応時間）を伴う場可能性があるが、手順３は根本的に手順１の再実行であるため、手順３は手順１と同じ論理構造を有しうる。
【００６２】
図６に戻って参照すると、一般的に６００の参照番号で示される制御レシピの実行は、種々様々な手順要素６０２、６０４、６０６（手順Ａ〜Ｃ）を含む状態で図示されている。もちろん当然のことながら、制御レシピは、様々な手順要素および下位手順要素の品目構造などを含み、図６に示されるものよりもはるかに複雑でありうる。手順ＡとＣ（６０２，６０６）はそれぞれ同じ論理構造を含んだ状態で示されている。従って、全体として６０８の参照番号で示される同じインスタンス化オブジェクトは、手順要素ＡおよびＣの両方に使用することができる。即ち、同じインスタンス化オブジェクト６０８が、必要に応じて、手順要素ＡとＣの各々をインスタンス化し、手順要素ＡとＣに特有のパラメータで論理構造をマージする際に、同じ論理構造を利用することができる。
【００６３】
結果として、制御レシピの実行には二つの異なる手順要素が利用されるが、一つのインスタンス化オブジェクトだけが両方の手順要素に必要とされる。即ち、作成時にインスタンス化オブジェクトが一つだけバッチ実行エンジン３０に読み込まれ、インスタンス化オブジェクトは、両方の手順要素に対して一つの論理構造を保持すれば良いか、もしくは、両方の手順要素に対して一つの論理構造を構築するための論理を保持すれば良いことになる。
【００６４】
制御レシピを実施するための上記のアプローチはメモリ使用量又は消費量を著しく向上できる（制御レシピの複雑性によっては９３％までも向上できる）ことが、比較検査の結果により明らかになっている。結果として利用可能リソースが増加し、さらに多くのバッチを同時に稼動することができる。必要に応じて各手順要素をインスタンス化するにはある程度の時間がかかるが、最大サイズの複雑な制御レシピの場合でさえも手順要素のインスタンス化にかかる所要時間の増加は数秒だけですむ。
【００６５】
上記ではバッチ実行技法が制御レシピを実施するための改善された方法とシステムを参照して説明されているが、プロセス制御システムにおける制御レシピの稼動は、実行環境に対する工場施設の物理的設備を示す設備機器（例えば、タンク、バルブ、ポンプ、など）のモデルに依存する。一般に手順要素は、パーソナルコンピュータやワークステーション１４およびコントローラ１２を含むデータ処理装置により、およびそのデータ処理装置内で実行される、コンピュータプログラムとして実施される。手順要素の実行は、設備機器などの物理要素を制御するために使用できるデータ処理装置からの出力をもたらす。手順要素は、少なくとも一つの物理要素に関して「基本制御」を起発動することにより、その割り当てられた作業を実行する。このタイプの制御は、物理要素に特定の期待される状態を設定および維持するために専用に設けられる。基本制御は、例えば、蓄積要素中の材料の流れを開始又は維持したり、又は、ポリ塩化ビニル反応器要素中の出発物質を加熱することもできる。
【００６６】
手続き型モデルの下位レベル（すなわちフェーズ）は、実際の物理的要素と実際の通信を実行することにより、基本制御を起動又は実行する。手続き型モデルの高位レベルは、手続き型モデルの編成および構造を（即ち、物理的モデルの編成および構造を）向上させるための抽象的概念として提供される。実行オブジェクト又はプロセスは、手順要素を実行するデータ処理装置（例えば、バッチ実行エンジン）上で稼動する。該オブジェクト又はプロセスは、一つ又は複数のモデルに従って手順要素の実行を協調させる。手順および、対応するユニット手順、対応する動作および対応するフェーズは、オブジェクト又はプロセスにより各々のステップを通じて順番付けられる。フェーズがインスタンス化される場合、該フェーズは、関連付けられているコントローラ１２内のフェーズ論理インターフェースにインスタンス化要求を通信する。その後、プログラム可能制御装置１２は、フェーズのための実状態論理を実行し、プロセス用設備機器と通信を行い必要なプロセス制御を提供する。
【００６７】
図７は、バッチ実行エンジン３０と、バッチ実行環境内のコントローラ１２、およびそれに提供される設備モデル７００との間の論理関係の例を示す。設備モデル７００は、モジュラー・ブロックが各々制御動作の論理セットを表す状態で生成されるように、Ｓ−８８標準に指定されるように、設備機器モジュールと制御モジュール７０２、７０４、７０６に分割される。例えば、反応装置およびそれに関連付けられているフィルタおよび乾燥器は、三つ又は四つの制御モジュールに分割され、該制御モジュールのそれぞれが、不適切に不要な供給材料を混合することなく、ある反応装置から別の反応装置に（又はある区域から別の区域に）製品を移動するよう、様々なバルブ１０３とポンプを操作し協調するために使用されうる。通常これらの制御モジュールはそれら自体が「フェーズ論理モジュール」７０８と称されるものを構成するためにグループ化される。
【００６８】
フェーズ論理モジュール７０８はそれ自体、例えば、「混合する」、「移動する」、「加熱する」など特定の作業を実行するのに使用しうるエンティティ（実体）である。通常、これらのフェーズ７０８は、分散型バッチ制御システムに存在するコントローラ１２において割り当てられ実行される。同時に、工場設備モデル７００もまた、各々完成品をもたらす高位レベル制御レシピの中に、コントローラ１２にて稼動する様々なフェーズ７０８を協調（編成）させる作業をつかさどる、「高位レベル」のバッチ実行エンジン３０に割り当てられ読み込まれる。
【００６９】
コントローラ１２およびバッチ実行エンジン３０間にはこのような論理関係が存在するので、制御レシピの実行が成功裡に完了するためにも、下位レベルコントローラ１２および高位レベルバッチ実行エンジン３０間の設備モデル７００の二つ複製の整合性を維持すべきである。けれども、見落としにより又は必要性が生じた結果、一つ又は複数のコントローラ１２により認識されている設備モデルと、バッチ実行エンジン１２の間に不整合性が生じうる。このような状態が生じた場合、不整合性が生じた際にバッチを完全に中断するのではなく、不整合を一致させるために以下に説明される解決技法を使用することができる。以下の技法を使用して、生産時間の損失が削減され、また、最悪の場合でも、実行されている物理的プロセスに関する時間制約による製品の損失が削減される。
【００７０】
図８は、コントローラ１２およびバッチ実行エンジン３０により保持されるモデル間における不整合性を解決するための技法の実施例を示す。具体的には該技法は、不整合性が検出され、実行時に不一致を解決するべきか無視するべきかを決定する能力を、バッチ実行エンジン３０又は工場人員に提供する方法を提供する。一実施例において、不整合性を解決するための技法は、上記されるように手順要素の実行の一部として実行されうる。このオプションにより、旧式と新規バージョンのモデル、又はそれのパラメータが同時に共存することが可能になると共に、工場設備モデル変更を実施する方法と時期を決定する際にフレキシビリティが提供される。
【００７１】
図８を参照すると、「フェーズ＿１」で示されるフェーズがプロセス工場内で使用され、フェーズ＿１はブロック８０２で「反応＿時間」として示される単一の入力パラメータ（フェーズがどれくらいの時間反応装置１００を稼動するか決定するためにそのフェーズ論理により使用される）を有する、と仮定した実施例が示されている。しかし当然のことながら図８に示される技法は、異なるモデルバージョン、異なる設備機器（例えば、異なる反応装置）用のモデル、又はその他のモデルパラメータを含むモデル間のいかなる不一致にも同様に適用しうる。さらに、モデルは、プロセス工場内の設備機器又は装置を参照して提供されているが、当然のことながらモデルは、ループ、ユニット、区域およびプロセス工場施設そのもの全体のモデルを含む、プロセス工場内のあらゆるエンティティ（実体）を参照してよい。
【００７２】
ある時点において、工場設備モデル全体の一部であるフェーズは、ブロック８０４に示されるようにコントローラ１２およびバッチ実行エンジン３０の両方にダウンロードされ、必要に応じて利用される。この実施例において、反応＿時間パラメータは実行時にバッチ実行エンジン３０により初期化され（なお、この作業はオペレータの入力選択に基づくことができる）、その後、フェーズ＿１が開始する直前に、コントローラ１２のもとに送信されることができる。
【００７３】
この実施例では、コントローラ１２のうちの少なくとも一つにおいて保持されるモデルと、バッチ実行エンジン３０により維持されるモデルとの間に不一致が生じる、とさらに仮定される。例えば、入力パラメータを一つだけ設ける代わりに二つ設けられるようにするために、工場人員がフェーズ＿１に修正変更を行う必要がありうる。例えば、工場人員は、フェーズ＿１完了後に製品がどこに送られるべきかを決定するために使用される第２のパラメータ（「排出＿先」）を追加することができる。このフェーズの新規バージョンを使用するために、変更がいかなるコントローラ１２にダウンロードされるべきであり、この場合、該コントローラ１２はブロック８０８に示されるような論理を稼動する必要があると同時にバッチ実行エンジン３０に新規情報を送る必要がある場合もある。
【００７４】
しかしながら、いくつかのコントローラ１〜Ｎ−Ｍへの変更を安全に更新することができるが、その他のコントローラ（Ｎ）への変更を安全に更新できないこともありえ、またそうなる見込みが多い。これは、コントローラを使用する様々なバッチの状態に基づきうる。例えば、バッチ実行エンジン３０が、その時点において第２のパラメータ（排出＿先）に更新されたモデル、より具体的にはフェーズを持っていないコントローラＮに対してバッチを稼動している場合、コントローラＮを使用しているバッチは、コントローラがモデルを更新するのを妨げうる。
【００７５】
バッチ実行エンジン３０がブロック８１０に示されるようにコントローラＮに対してバッチを実行する（例えば、コントローラＮに関連したプロセスを実行する）ために入力を受け取った時点で、バッチ実行エンジン３０は、ブロック８１２に示されるようなコントローラのもとに排出＿先の値を送る。しかし、コントローラ１２により保持されるフェーズ＿１の旧式バージョンは、新規の排出＿先パラメータについては何も認識しないだろう。
【００７６】
しかし、現実においては、不一致は全く害がないものでありうる。例えば、旧式の構成における排出＿先はフェーズ論理自体に「ハードコード」されているために、フェーズ＿１が、かなりの期間（例えば、数週間）、旧式の構成で問題なく稼動する可能性がある。この場合、ハードコードされた値が十分であり、フェーズ＿１はコントローラにより実行されうる。一方で、欠けているパラメータを無視することができない場合には、不整合性の見落とし（すなわち、新規の構成がコントローラにダウンロードされず、コントローラが排出＿先の値を含んでいない）が生じる可能性がある。不整合性については、ブロック８１４にてコントローラ１２により、例えば値又はパラメータが不明であることを示す値を受け取った時点でのハンドシェイク信号により、バッチ実行エンジン３０に報告されることができる。そしてバッチ実行エンジン３０は、オペレータが不整合性に対する対処を行えるように、ワークステーション１４に不整合性に関するメッセージを提供することができる。この場合、オペレータにはワークステーションユーザー又はワークステーション１４により利用される診断および保守ルーチンを含んでよい。あるいは、バッチ実行エンジン３０は、ワークステーション３０への報告を伴って、又はワークステーション３０への報告無しに、不整合性への対処を行ってもよい。
【００７７】
具体的には、自動的にバッチプロセスを中断する代わりに、ブロック８１８でバッチプロセスを中断するか（保留するか）、又はブロック８２０でバッチプロセスを続けることによりフェーズ＿１を実行し続けるかのオプションがブロック８１６で提供される。その決定（判断）は、ワークステーションユーザー次第、ワークステーション１４又はバッチ実行エンジン３０により利用される診断および保守ルーチン次第であってよい。例えば、プロンプト（入力要求メッセージ）が、ワークステーション１４でワークステーションのユーザ（例えば、工場のオペレータ）に表示されるか、もしくはワークステーション１４又はバッチ実行エンジン３０に提供されてもよい。プロンプトには、不整合の生じた位置（例えば、コントローラ）、関与するモデル、モデルのバージョン、関与するモデルパラメータ（例えば、フェーズ＿１、排出＿先）、又はその他の不整合性の原因となっているコントローラ１２のモデルとバッチ実行エンジン３０のモデル間の相違に関する、あらゆる情報を含む、不整合性に関する情報が含まれてよい。プロンプトにはさらに、使用されうる置換値（例えば、ハードコードされた値）を検索することにより不整合性の重大さを評価する際、又は不整合性が見落としエラーであったかどうか判断する際の付加的情報が含まれてよい。
【００７８】
プロンプト内に情報を提供するための論理は、コントローラ１２とバッチ実行エンジン３０およびワークステーション１４を含むプロセスシステムの様々な態様により提供されることができる。例えば、コントローラ１２およびバッチ実行エンジン３０はそれぞれ、各々のモデルバージョンおよび関連付けられたパラメータ、障害を起こすパラメータの識別情報、障害を起こすパラメータに以前使用された値、以前に行われた更新の日付／時間、などを提供してもよい。また、あらゆるコントローラ１２、バッチ実行エンジン３０およびワークステーション１４は、その情報を使用して、不整合性の出所およびそれのバッチプロセスに対する影響を決定することができる。もちろん、ユーザが決定を発動できるようにするためにこの情報をユーザに表示するようにもできる。
【００７９】
ブロック８１６での決定がバッチプロセスを中断すること（保留すること）である場合、コントローラ１２に正しいモデル又はモデル更新をアップロードすることにより不整合性が解決されることができる。ブロック８１６での決定がバッチプロセスを継続することである場合、モデル又はフェーズの旧式バージョンを使用する指示など、使用すべき代替情報がコントローラに提供されてよい。例えば、データ・ヒストリアン１９などから前回のバッチ稼動で問題なく使用された「排出＿先」の前回値（ハードコードされた値により提供されうる）がコントローラ１２に提供されてよい。コントローラ１２はその後フェーズ＿１を実行することができ、バッチプロセスの継続が許可される。コントローラ１２又はバッチ実行エンジン３０が使用しうるパラメータのその他の実施例は、既定値（例えば、製造メーカ既定値又はバッチプロセス既定）、ユーザにより入力された値などを含む。プロセスにおける複数のコントローラが同じモデル又はモデルパラメータを使用するが一つのコントローラだけが不整合性を提示する場合、バッチ実行エンジン３０は、全てのコントローラ１２により使用されるものであり、且つモデルの全てのバージョンと互換性を持つグローバルパラメータを提供することができる。
【００８０】
上記には本発明の多数の異なる実施形態の詳細な説明が記載されているが、当然のことながら、本発明の適用範囲は、本明細書に記載されている特許請求の範囲の記載により定義されるものと理解されたい。当該詳細な説明は、例示的なものとしてのみ解釈されるべきものであり、また、考えうる全ての実施形態を記載することは（不可能でないとすれば）現実的でないことから、考えうる全ての実施形態の説明を含んでいない。現存する技術又は、（なおも本発明を定義する特許請求の範囲に含まれる）本特許出願後に開発される技術のいずれかを用いて、別の実施形態をその他数多く実施することが可能である。
【００８１】
したがって、本発明の精神と範囲から逸脱することなく、ここに記載される技法と構成により多種多様の改造および変形が可能である。よって、当然のことながら、ここに記載される方法と装置は実施例に過ぎず、本発明の範囲を限定するものではない。
【技術分野】
【０００１】
本開示は、概してプロセス工場内のプロセス制御システムに関し、より具体的にはバッチプロセスなどのプロセスの実行および、該プロセスの稼動中における不整合性の解決に関する。
【背景技術】
【０００２】
製造工場およびその他の生産工場は一般に多種多様な製品を生成するために使用される。テキサス州オースティン市を所在地とするＥｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ， ＬＬＰ社により提供されるようなプロセス制御システムをはじめとするプロセス制御システムは、製品の製造又はプロセスの制御（例えば、化学薬品の製造、発電所の制御、など）が行われるこのような製造工場且つ又はその他工場施設において幅広く使用されている。また、プロセス制御システムは、例えば石油・ガス掘削および貯蔵工程をはじめとする天然資源などの採掘にも使用されている。一つ又は複数のプロセス制御システムのアプリケーションを通じて、実質的に全て製造工程や資源採掘工程などを自動化できる。
【０００３】
一般に、化学薬品の処理工程や石油精製又はその他のプロセスにおいて使用されるようなプロセス制御ネットワークには、例えば、バルブポジショナ、スイッチ、センサ（温度、圧力および流量センサ、等）など、一つ又は複数のフィールド装置に通信可能に連結された集中型プロセスコントローラが含まれる。これらのフィールド装置は、プロセス内の物理的制御機能（バルブ開閉など）を実行しうるし、プロセスの動作の制御に使用するためにプロセス内の計測を講じうるし、又はプロセス内においてその他所望の機能を実行しうる。プロセスコントローラは従来から一つ又は複数の（例えば、フィールド装置間で４〜２０ミリアンペア（ｍＡ）の信号を伝送しうる）アナログ信号線又はバスを介してフィールド装置に接続されるものであった。しかしながら、より最近になって、プロセス制御の産業分野では標準、オープン、デジタル又はジタル・アナログ混合通信プロトコルが数多く開発されており、その数例としてＦＯＵＮＤＡＴＩＯＮ（登録商標） ＦＩＥＬＤＢＵＳ（以下「Ｆｉｅｌｄｂｕｓ」）、ＨＡＲＴ（登録商標）、ＰＲＯＦＩＢＵＳ（登録商標）、ＷＯＲＬＤＦＩＰ（登録商標）、Ｄｅｖｉｃｅ Ｎｅｔ（登録商標）およびＣＡＮプロトコルが挙げられ、これらを使用してコントローラとフィールド装置間の通信を実施できるようになっている。一般的にプロセスコントローラは、一つ又は複数のフィールド装置により生成された計測且つ又はフィールド装置に関するその他の情報を示す信号を受信し、この情報を使用して通常複雑な制御ルーチンを実施し、さらに信号線又はバスを介してフィールド装置に送信される制御信号を生成することによってプロセスの動作を制御する。
【０００４】
その他、プロセス制御システムにより制御される製造工程の一般的なものとしてはバッチプロセスがある。一般に、バッチ処理には材料を生成するための「レシピ」と呼ばれるものが関与する。例えば、バッチ処理は一般に製薬および化学工業において薬剤や化学薬品およびその他の物質を製造するために使用される。バッチプロセスの内容を記述するレシピは一般に、どのようにして所望の物質を生成するかを示す。例えば、特定の化学薬品は、まず二つの化学薬品を混合した後にその混合物を加熱することにより生成されうる。単に一つの物質を生成するために何百もの段階が全体的なレシピに含まれうる。所望の物質を生産するにはどの材料をどのような割り合で使用するべきであるか、材料を加熱するべきか冷却するべきかどうか、どのような設備が必要か、などをレシピは示すことができる。工業規模で実施されている例としてはポリ塩化ビニルの調合が挙げられる。ポリ塩化ビニルは、塩化ビニルの非常に小さい分子を重合又は「結合する」ことにより作られる。これは、バッチ反応装置内に塩化ビニルと溶剤および重合誘導物質の混合物を適切なレベルまで充填し、混合物を反応装置の中で加熱し、結果的に得られるバッチを冷却してから、残存の出発物質を取り除くことによりバッチを精製することにより達成される。
【０００５】
通常、バッチプロセスにおいて使用されるものなど、特定のタイプのプロセス制御ネットワークには、プロセス内で本質的に同じ機能を実行する同じ又は似した設備を備えるように設計された複数組（セット）の複製設備が含まれている。よって、例えば、ポリ塩化ビニルの製造工場には、複数組の反応処理設備（すなわち反応装置）、複数組の加熱処理設備（すなわち加熱器）、複数組の冷却処理設備（すなわち冷却器）、複数組の精製処理設備（すなわち精製器）、および複数組の梱包設備（すなわち梱包ユニット）が備えられうる。またこの場合、反応装置のいくつか又は全てが、加熱ユニット、冷却ユニット、精製ユニットおよび梱包ユニットのいくつか又は全てと並列して作動可能、且つ、加熱ユニット、冷却ユニット、精製ユニットおよび梱包ユニットのいくつか又は全てと直列作動が可能な状態で接続されるようにしても良い。
【０００６】
一般に、バッチプロセスは第２の段階を開始する前に第１の段階を終了させるといった具合に、複数の異なるフェーズ又はテップを順々に実行する。このように、上記の製造工場では、バッチプロセスが、反応処理ユニットを制御するように第１のフェーズ又はテップを実行してから、反応処理設備により作られた製品上で加熱処理ユニットを実行するように第２のフェーズを実行し、加熱処理ユニットにより生産された製品を冷却するように冷却処理ユニットを制御する第三のフェーズを実行し、製品を精製するように精製処理設備を制御する第四のフェーズを実行し、そして精製された製品を梱包するように梱包ユニットを制御する第五のフェーズを実行する。一般に、各ユニットは、それに関連付けられているユニットモジュール・オブジェクト（例えば、ハードウェア構成機器のようなユニットの状態を表すように構成されたソフトウェアでありうる）を有する。ユニットモジュール・オブジェクトは、下位レベルのモジュールの実行を協調させるよう最適化された、ソフトウェア命令にて具現化されたアルゴリズムでありうる。（以下、「下位レベルモジュール」を単に「モジュールオブジェクト」と総称する。）モジュールオブジェクトは、以下さらに詳しく説明されているように、可変部分とアルゴリズム部分を含みうる。一般に、モジュールオブジェクトは、単一の論理機能（例えば、バルブを開く、又はタンクを充填する、など）を遂行するように設計されている。手短に言えば、モジュールオブジェクトはハードウェア構成機器の状態を変更するために使用される。
【０００７】
前述のポリ塩化ビニルを作る代表的なバッチプロセスでは各フェーズがある特定のユニット上で動作するように説明されているが、これは必ずしもそうでなければならないとは限らない。それぞれのフェーズのステップ数によっては、複数台の設備ユニットが特定のフェーズを遂行するために使用されるようにしても良い。例えば、ポリ塩化ビニルを作るようにバッチプロセスをプログラムして使用する代わりに、ポリ塩化ビニルの生成をより大きなバッチプロセス中の一つのフェーズとしても良く、このようなフェーズは、反応装置、加熱器、冷却器、精製器および梱包ユニットでありうる。
【０００８】
バッチプロセスを制御することは一般に重要な要素である。例えば、塩化ビニルの反応混合物が十分に長い時間をかけて反応されないと、そのプロセスから得られるポリ塩化ビニルの歩留りが不十分となり、資金の損失につながる。危険薬品又はれ同等のエンティティ（実体）の生産を伴う場合、バッチプロセスの制御は決定的な重要性を持つようになる可能性がある。バッチプロセスを制御する一つの方法はマニュアル操作による制御である。即ち、全てが確実に計画通りに進行するようにするために、一人又は複数の作業者に対して、バッチプロセスの全ての面を監視する仕事が割り当てられる。但し、これは忍耐を要する作業であり、また、気付かないままエラーが発生する可能性がある。これらの理由、およびその他の理由で、電子装置を使用して制御バッチプロセスの自動化が展開されている。バッチプロセス制御の自動化を目指して、複数のバッチ制御システム供給業者によりコンピューターやプログラム可能制御装置およびそれ同等の電子装置が、知的フィールド装置（すなわち知能センサおよび制御可能バルブ）と連動した状態で使用されてきた。知能センサは、通常一台の設備機器上に配置されており、工場施設内の中央制御室へと設備機器状態を報告する。一般に、制御可能バルブは、一台の設備機器への入力又は台の設備機器からの出力を制御するものであり、大抵の場合は知能センサから受信した情報に基づいて中央制御室から制御することができるものである。
【０００９】
バッチ処理自動化への取り組みの結果、とりわけバッチ処理に関与する産業分野に属する者およびバッチ処理設備の供給業者によって標準委員会が設立されるに至った。これら標準委員会の全体的な目的は自動化バッチ処理のために一律した標準を定義することにある。このような標準の一つとしては、プロセス制御の問題に従事する国際組織である国際計測制御学会により公布されたものがある。この標準は、「Ｂａｔｃｈ Ｃｏｎｔｒｏｌ
Ｐａｒｔ １： Ｍｏｄｅｌｓ ａｎｄ Ｔｅｒｍｉｎｏｌｏｇｙ（バッチ制御 第１部： モデルおよび用語集）」と題され、しばしばＩＳＡ Ｓ８８．０１−１９９５標準（又は本出願においては「Ｓ８８」）と呼ばれるものである。このＳ８８．０１標準は、自動化バッチプロセスにおいて使用する設備機器のモデルおよび手順ならびに、当該のモデルとその要素を指すために用いられる用語を定義している。「バッチプロセス」とは、Ｓ８８．０１標準によると、一台又は複数台の設備機器を使用して限定された期間の間、多数の入力素材を順序化された処理作業のセットに従わせることにより、有限量の材料を生産するに至るプロセスとされている。「バッチ」とは、バッチプロセスの単一の実行により生産される、又は生産済みの、材料を指す。
【００１０】
バッチプロセス内の物理的要素を操作する制御レシピは、Ｓ８８標準によってしばしば「手続き型モデル（ｐｒｏｃｅｄｕｒａｌ ｍｏｄｅｌ）」としても指称されている。ＳＳ８８標準によると、この手続き型モデルは、手順の階層順位方式により構成されており、最も高いレベルが下位レベルの各々を包含し、次に高いレベルがその下のレベルの各々を包含する、などといった具合に構成されている。手続き型モデルのレベルには、上から下の順に述べると、「手順（ｐｒｏｃｅｄｕｒｅ）」、「ユニット手順（ｕｎｉｔ ｐｒｏｃｅｄｕｒｅ）」、「動作（ｏｐｅｒａｔｉｏｎ）」、そして「フェーズ（ｐｈａｓｅ：過程段階）」とが含まれ、「手続要素」とは制御レシピ又は手続き型モデルの任意のレベルを指すものである。階層において、最も高いレベルの手順要素が「手順」と呼ばれ、一つ又は複数のユニット手順から成る。各ユニット手順は一つ又は複数の動作から構成されており、各動作は順じて一つ又は複数のフェーズから構成されている。
【００１１】
バッチ実行環境は、（特にＳ８８．０１標準の到来に伴って）ますます複雑になった。一般的に、このような複雑性は、典型的にはますます大規模な制御レシピという形で現れ、また一見して、その一つ一つに含まれる手順要素の数も増加し続けるように思われる。それと同時に、バッチ処理工場のサイズおよび能力もまた成長している。例えば、バッチ処理工場施設は複数の製品「列（ｔｒａｉｎｓ）」を同時に稼動する能力を有するが故に、制御システムには多くのバッチを並列して同時に管理する能力が備わっていることが要求される。しかしながら、レシピの複雑性およびサイズの増大ならびに実際の工場における設備のフレキシビリティ（柔軟性・融通性）の向上に伴い、バッチ処理制御システムにかかる負担も増大している。大規模且つ複雑なレシピに基づいて多くのバッチを読み込んで実行するには、処理能力、メモリ機能、およびその他のリソースを限界に至るまで利用することになる。
【００１２】
例えば、バッチ実行エンジンは、プロセスメモリに制御レシピを読み込んでから、事前に構成された順番で制御レシピの手順要素を実行し始める。様々な手順要素が後で実際に実行されるかどうかに関係なく、手順構造全体が制御レシピのレベルを全て含んだ状態で作成時に読み込まれる。このように、二つの異なる手順のどちらを実行するかの選択によっては、選択されない手順（関連付けられている手順ユニット、動作およびフェーズのいくつか又は全てを含む）が実際に必要とされない場合が存在することも全く可能である。あいにく、どの手順を実際に実行するかの選択は通常、制御レシピを実行するまで分からず、この制御レシピの実行時は通常、作成時に全て手順要素を読み込む時点をはるかに経過した時点のことである。結果として、手順要素のいくつかが実際の実行時に必要とされる・されないにかかわらず読み込まれるので、大量のメモリ、プロセッサ処理時間、およびその他のリソースが手順要素により消費されることになる。結局、工場施設がバッチ実行エンジンに通常読み込むことができるバッチ数がこれらの負担によって制限されることになる。
【００１３】
既に複雑なバッチ実行環境がますます複雑になることにより、工場施設の構成がさらに大規模なものとなる。加えて、当該工場施設の構成は、定期的な保守管理や更新を要するものである。典型的なシステムでは、バッチの実行中には次の二つの構成部分が利用される。即ち、バルブやポンプおよびその他の装置を作動させる下位レベルコントローラと、該下位レベルコントローラを調停、監視および調整する高位レベルのバッチ実行エンジンの二つである。これらの構成部分は両方とも実際の工場の最新モデル（上記の手順モデル、および特定のバッチを実行中に工場設備を制御するのに必要な、前記手順モデルに関連付けられている論理など）を利用する。工場の技術員や監督者は、新製品の製造や能率の増加などに対応できるように工場設備の一部を再構成したい場合もありえる。当該の再構成には、新規の構成と一致するように制御レシピや設備モデルを変更することが含まれうる。このような場合が生じた際には、変更を認識し且つ新規変更を実施できるようにコントローラおよびバッチ実行エンジンを更新すべきである。あいにく様々な理由によりこれら二つの構成部分間の不整合性が生じることがあり、このような場合には通常バッチ全体を一時停止又は中断しなければならなくなり、よって、生産時間の損失、さらには製品の損失につながる。しかしながら、不整合性は無害かもしれず、或いは旧式のモデル又はモデルパラメータを使用して不整合性を実際に克服することも全く可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
制御レシピを実施するため、および制御レシピの実行中に不整合性を解決するためのシステムと方法を提供する。
【課題を解決するための手段】
【００１５】
具体的に、制御レシピは、読込みに必要とされる時間とメモリを最適化するとともに同時処理可能な同時バッチの数を増加しつつ最も複雑な制御レシピさえも実行できる技法を使用して実施される。該技法には、「ジャストインタイム」に、そして制御レシピの作成時にではなく制御レシピの実行時中に利用される場合のみに、レシピの手順要素をインスタンス化して読み込む作業を伴う。制御レシピが手順要素を終了させた時点で（例えば、手順要素の実行が終了した時点で）、手順要素が解体されて制御レシピからアンロード（解放）される。
【００１６】
「ジャストインタイム」処理のためのシステムと方法は、制御レシピの一部として実施されるか、又は制御レシピにより呼び出される、インスタンス化オブジェクト又は手順を利用する。制御レシピの実行時中に呼び出されうる手順要素の各々はインスタンス化オブジェクトと関連付けられている。例えば、バッチ作成時には、手順要素が、関連付けられているインスタンス化オブジェクトに読み込まれうる。特に、手順要素がプロセスの局面を制御するために使用する様々なパラメータが手順要素の論理構造に含まれていない場合、手順要素の論理構造をインスタンス化オブジェクトに読み込みうる。別の実施例における手順要素の論理構造は、手順要素が使用されるにつれてインスタンス化オブジェクト内に生成される。インスタンス化オブジェクトは、実行時中に、手順要素を（制御レシピにより必要とされる場合に）インスタンス化するのに使用される。いったん手順要素が制御レシピの一部として実行されると、インスタンス化オブジェクトは制御レシピからの手順要素を解体するために使用される。それによって手順要素により使用されたリソースを制御レシピの実行にてさらに使用するために再要求（ｒｅｃｌａｉｍ）することができる。
【００１７】
別の態様では、同じインスタンス化オブジェクトを複数の手順要素に使用しうる。例えば、同じ論理構造を利用する複数の手順要素は同じインスタンス化オブジェクトを使用しうる。インスタンス化オブジェクトは論理構造を読み込むか生成し、特定の手順により使用されるパラメータを論理構造に投入する。結果として、作成時に読み込まれる手順要素の数が少なくなるので、リソース使用の削減につながりうる。
【００１８】
さらに、制御レシピの実行中に生じる不整合性を検出し解決するための技法は、不整合性を無視するか、あるいは不整合性を訂正するためにバッチプロセスを中断（保留）するかの選択を可能にする。特に、該技法は、高位レベルのエグゼクティブ（実行）・エンジンおよび下位レベルのコントローラを使用したモデルにおける不整合性を解決する。不整合性についての情報が提供されるようにしても良く、その不整合性についての情報に基づいてバッチプロセスを続けるべきか中断するべきかどうかをバッチ実行エンジン又はバッチ・オペレータが決定するようにしても良い。一実施例では、デフォルトパラメータや、使用するコントローラ全てのためのグローバルパラメータや、以前に使用されたパラメータなどをバッチプロセスが継続して使用することを可能にする。
【００１９】
本発明の第１の態様は、プロセス制御システム内の制御プロセスを実施するためのシステムであって、前記制御プロセスが制御プロセス構造を含み、前記制御プロセスの実行には複数の手順要素の実行が含まれ、前記システムが、制御プロセスの各手順要素が各々関連付けられている複数のインスタンス化オブジェクトと、制御プロセス実行エンジンに制御プロセス構造を読み込み、制御プロセスがインスタンス化された時に制御プロセス実行エンジンに複数のインスタンス化オブジェクトの各々を読み込み、制御プロセス構造が制御プロセス実行中に手順要素を呼び出すにつれて、インスタンス化オブジェクトに関連した手順要素をインスタンス化するために各インスタンス化オブジェクトを使用し、制御プロセスの一部としてインスタンス化された手順要素を実行し、そして制御プロセスの実行中に手順要素の実行が完了するにつれて、インスタンス化された手順要素を解体するためにインスタンス化オブジェクトを使用する、制御プロセス実行オブジェクトと、を含むことを特徴とする。
【００２０】
本発明の第２の態様は、制御プロセスの実行中にプロセス制御システム内の装置モデルにおける不整合性を解決するためのシステムであって、プロセス制御システムのエンティティの第１のモデルを含むプロセスコントローラと、プロセス制御システムのエンティティの第２のモデルを備える制御プロセス実行エンジンであって、制御プロセス実行エンジンがエンティティの第２のモデルに基づいてプロセスコントローラに制御命令を提供し、前記プロセスコントローラがエンティティの第１のモデルに基づいて制御命令を実行するように構成されることを特徴とする、制御プロセス実行エンジンと、制御プロセスの実行中にエンティティの第１および第２のモデル間の相違を検出し、相違の検出に応答してプロンプト（入力要求メッセージ）を生成し、制御プロセスの継続的な動作に関する動作指示を受け取る制御実行オブジェクトであって、前記動作指示が制御プロセスの実行を続けるか、制御プロセスの実行を中断するかのいずれかを含む、制御実行オブジェクトと、を含むことを特徴とする。
【００２１】
本発明の第３の態様は、プロセス制御システム内の制御プロセスを実施する方法であって、制御プロセスが、制御プロセスの実行中に複数の手順要素に対する呼出しを有する制御プロセス構造を含み、前記方法が、手順要素の各々のためにインスタンス化オブジェクトを確立し、制御プロセスの実行中に手順要素が制御プロセスにより呼び出されるにつれて、関連付けられているインスタンス化オブジェクト内に手順要素を構築し、制御プロセスの一部として手順要素を実行することと、いったん手順要素が制御プロセスの一部として実行された時点で、インスタンス化オブジェクト内の手順要素を解体すること、を含み、前記手順要素の解体が制御プロセスの実行中に実行されることを特徴とする。
【００２２】
本発明の第４の態様は、処理および実行環境における不整合性を解決する方法であって、制御パラメータを生成するために、プロセス制御モデルの第１のバージョンに基づいて制御プロセスを実行し、プロセスにおけるコントローラに制御パラメータを伝送し、プロセス制御モデルの第２のバージョンで制御パラメータを使用して制御機能を実行し、プロセス制御モデルの第２のバージョンの制御パラメータ使用能力に基づいて制御プロセスの継続的な動作に関する動作指示を依頼し、プロセス制御モデルの第２のバージョンでパラメータを使用できない場合にプロセス制御モデルの第２のバージョンがエラーを生成し、
動作指示が実行継続指示を含む場合に制御プロセスの実行を続け、動作指示が実行中断指示を含む場合に制御プロセスの実行を中断すること、を含むことを特徴とする。
【００２３】
本発明の第５の態様は、プロセス制御システムにおいてバッチプロセスのために制御レシピを実施する方法であって、制御レシピには、制御レシピの実行中に複数の手順要素に対する呼出しを有する制御レシピ構造が含まれ、前記方法は、手順要素の各々のためにインスタンス化オブジェクトを確立し、制御パラメータを生成するためにプロセス制御モデルの第１のバージョンに基づいて制御レシピを実行し、制御プロセスの実行中に手順要素が制御プロセスにより呼び出されるにつれて、関連付けられているインスタンス化オブジェクトから手順要素を構築し、制御レシピの一部として手順要素を実行することであって、前記手順要素の実行には、バッチプロセスにおいてコントローラに制御パラメータを伝送することと、プロセス制御モデルの第２のバージョンで制御パラメータを使用して制御機能を実行することと、プロセス制御モデルの第２のバージョンの制御パラメータ使用能力に基づいて制御レシピの継続的な動作に関する動作指示を依頼することとが含まれ、プロセス制御モデルの第２のバージョンでパラメータを使用できない場合にプロセス制御モデルの第２のバージョンがエラーを生成し、動作指示が実行継続指示を含む場合にバッチプロセスの実行を継続することであって、前記バッチプロセスの実行の継続には手順要素が制御レシピの一部としていったん実行された時点において手順要素を解体することが含まれ、手順要素の解体が制御レシピの実行中に実行され、動作指示が実行中断指示を含む場合にバッチプロセスの実行を中断すること、を含むことを特徴とする。
【００２４】
本発明の第６の態様は、プロセス制御システムにおいてバッチプロセスのために制御レシピを実施するためのシステムであって、制御レシピが制御レシピ構造を含み、制御レシピの実行には複数の手順要素の実行が含まれ、前記システムが、プロセス制御システムのエンティティの第１のモデルを有するプロセスコントローラと、制御レシピの各手順要素がインスタンス化オブジェクトのうちの一つと関連付けられている複数のインスタンス化オブジェクトと、プロセス制御システムのエンティティの第２のモデルを有するバッチプロセス実行エンジンであって、前記バッチプロセス実行エンジンがエンティティの第２のモデルに基づいてプロセスコントローラに制御命令を提供するように構成され、前記プロセスコントローラがエンティティの第１のモデルに基づいて制御命令を実行するように構成される、バッチプロセス実行エンジンと、バッチプロセス実行エンジンに制御プロセス構造を読み込み、制御プロセスがインスタンス化される場合にバッチプロセス実行エンジンに複数のインスタンス化オブジェクトの各々を読み込み、制御レシピ構造が制御レシピ実行中に手順要素を呼び出すにつれてインスタンス化オブジェクトに関連した手順要素をインスタンス化するために各インスタンス化オブジェクトを使用し、制御レシピの一部としてインスタンス化された手順要素を実行し、制御レシピにおけるインスタンス化された手順要素の実行中にエンティティの第１および第２のモデル間の相違を検出して相違の検出に応答してプロンプトを生成し、バッチプロセスの継続的な動作に関する動作指示を受け取り、前記動作指示がバッチプロセスの実行を継続すること又は制御プロセスの実行を中断することのいずれか一つを含み、動作指示が実行継続指示を含む場合に制御レシピの実行中に手順要素の実行が完了するにつれてインスタンス化された手順要素を解体するためにインスタンス化オブジェクトを使用し、動作指示が実行中断指示を含む場合にバッチプロセスの実行を中断する、バッチプロセス実行オブジェクトと、を含むことを特徴とする。
【図面の簡単な説明】
【００２５】
【図１】バッチプロセス工場施設において実施されるバッチ実行環境を描写する、プロセス工場の一部分の実施例の部分的概略図を示す部分ブロック図である。
【図２】図１のプロセス制御システムの一部分およびバッチプロセスの一部分の実施例の部分的概略図を示す部分ブロック図である。
【図３】バッチ実行環境における様々な手順要素の実行を含む制御レシピ実行例のフローチャートである。
【図４】バッチ実行環境において様々な手順要素をインスタンス化するためにインスタンス化オブジェクトを使用して行う制御レシピ実行例のフローチャートである。
【図５】インスタンス化オブジェクトが手順要素をインスタンス化し、手順要素が実行され、インスタンス化オブジェクトが手順要素を解体する実施例のフローチャートである。
【図６】バッチ実行環境において複数の手順要素をインスタンス化するために同じインスタンス化オブジェクトを使用して行う制御レシピ実行例のフローチャートである。
【図７】高位レベルバッチ実行エンジンと下位レベルコントローラの関係、およびそれにおいて使用されるモデルを描写する、プロセス工場における一部分の実施例の部分的概略図を示す部分ブロック図である。
【図８】高位レベルのバッチ実行エンジンのモデルと下位レベルコントローラのモデルとの間の不整合性を解決する手順の実施例のフローチャートである。
【発明を実施するための最良の形態】
【００２６】
プロセス制御システムは、多種多様な産業分野において工業用工場施設で様々な装置の動作を制御かつ監視するために頻繁に使用される。プロセス制御システムを使用する工業用工場施設の一種として薬物製造施設が挙げられる。薬物製造施設では、段階的なプロセスを通じて、薬剤などをはじめとする特定の物質を大量に生成するためにバッチ処理技法が使用される。精製所を通る天然ガスの流れを制御するために使用される連続処理技法とは対照的に、バッチ処理技法は、製品を生成する個々のステップを指定するレシピなど、順序づけられた一連の離散した工程を伴う。例えば、バッチ処理環境において、完成品又は所望の製品は通常一連の「制御レシピ」として知られるステップを使用して生成される。各ステップには、ヒータやコンベヤベルト、タンク、混合器など、一台又は複数台の設備を使用することが必要とされうる。
【００２７】
また、特定の工場施設は、実質的に並列稼動する複数のレシピを有しうる。一般に製造工場は、バッチ制御システム処理能力の過負荷を防止するように異なる設備機器のグループに論理的に分離される。各グループは特定の設備機器を含み、多くの場合特定の動作に対して指定されるようになっている。一般的に各制御レシピには、特定の製品を製造するための異なるプロセス区域、ユニット、ループ、又は設備機器をはじめとするプロセスの様々なグループを制御する全ての情報（例えば、手順の構造、レシピ・パラメータ、必要設備、など）を含んでいる。例えば、あるレシピは混合槽の使用を必要としうる一方、別のレシピは貯蔵容器中での加熱を伴いうる。これらの制御レシピは１以上の「バッチ」を実行するようにインスタンス化され、バッチ・エグゼクティブ（実行部）又はそれ同等のサブシステムにより進行する。制御レシピを実際に稼動中のバッチにインスタンス化することには通常、例えばバッチ・エグゼクティブにより使用されるメモリーリソースにレシピを読み込むことによりバッチ・エグゼクティブのプロセスに制御レシピを読み込む作業を伴い、バッチ・エグゼクティブはプロセッサおよびその他のコンピューターリソース（様々なハードウェアおよびソフトウェア・リソースを含む）を使用して制御レシピを実行する。
【００２８】
ここで図１を参照すると、バッチ・エグゼクティブにより一つ又は複数の制御プロセス、特にバッチプロセス又はレシピを実施し実行しうる状態で実施例のプロセス工場１０が図示されている。特に、図１に示されるように、プロセス工場５０には、プロセス制御システム５２、一つ又は複数の区域５４、一つ又は複数の装置５６、通信ネットワーク５８および一人又は複数人の装置ユーザ６０が含まれている。プロセス工場５０は、薬物の製造又は生産施設や、精製又は他の化学処理作業や、その他適切なバッチ又は連続プロセス環境を構成しうる。開示の実施形態において、プロセス工場５０では、バッチ・レシピなど少なくとも一つのバッチ処理技法を使用する。
【００２９】
プロセス制御システム５２は、通信ネットワーク５８を通じて装置５６を制御、命令、監視、テスト、装置５６と通信、及び（それ以外の場合）装置５６を使用することの少なくとも一つを行うように作動する、ハードウェア及び／又はソフトウェアを構成することができる。例えば、プロセス制御システム５２には、テキサス州オースティン市を所在地とするＥｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ ＬＬＰ社により販売されるＤｅｌｔａＶ（登録商標）システムを使用することができる。一般に、プロセス制御システム５２は、装置５６へのアクセスを制御し、装置５６が装置ユーザ６０により使用されるスケジュールを作成する。通信ネットワーク５８は、プロセス制御システム５２、区域５４、装置５６および装置ユーザ６０間のデータ通信をサポートし、且つ、いかなる所望のハードワイヤード式及び／又はワイヤレス通信構造、又はその他にもイーサネット（登録商標）やＦｏｕｎｄａｔｉｏｎ（登録商標） Ｆｉｅｌｄｂｕｓ又はＰｒｏｆｉｂｕｓ（登録商標）プロトコルなどの適切な通信プロトコルを使用して、任意の所望のバスを基盤とするか、又はバスを基盤としないハードウェアを単独で、又は様々な組合せのいずれかで使用することにより実施することができる。
【００３０】
区域５４とは、プロセス工場５０、装置５６および装置ユーザ６０の論理的及び／又は物理的編成のことである。一般的に区域５４は、工場施設５０にて使用されるレシピのステップを実行するのに使用される装置５６を編成するために使用される。区域５４の編成は、工場施設５０における装置５６の物理的位置、又は、工場施設５０における装置５６の論理編成、又は、適切であれば装置５６の物理的および論理的な編成の組合せに基づきうる。例えば、バッチ処理動作は、受入れ、準備、処理および出荷などの個々別々の区域５４に分割されることができる。前回の実施例を続けて使用すると、薬物生成プロセスの原材料を受入れ区域にて受け取り、準備区域にて変更され、処理区域にて目標とする薬物を生成するために混合・処理され、その後、当該標的薬物が出荷区域で梱包され、そこから出荷されるようにすることができる。異なる製薬を生成するために使用される各種機器など、区域５４内にある装置５６は、異なるタイプの最終製品を生産する一部として使用されうる。また、一実施形態における区域５４は、単一のグループとして取り扱うにはあまりにも多過ぎる装置５６および装置ユーザ６０がシステム５２に存在するといった問題に対する現実的解決方法も提供する。その他のプロセス監視機能を実行しながら多数の装置５６を管理する際にも、プロセス制御システム５２の速度が遅くならないようにするために大規模なレシピの処理を分割するのにも区域５４を利用することができる。
【００３１】
装置５６は各々、バルブ、タンク、ポンプ、コンベヤベルト、混合機、ヒータ、又はその他工場施設５０で実行されるプロセスの一部として使用できる適切な装置を構成することができる。装置５６は、異なる装置ユーザ６０によりバッチプロセスの異なる部分で、様々な時点において使用されうる。例えば、特定のヒータ装置５６を、ある最終製品に使用される第１の物質に使用してから清掃し、後で異なる最終製品に使用される第２の物質に使用するようにしても良い。
【００３２】
装置ユーザ６０とは、装置５６を使用する物理的又は論理エンティティ（実体）のことである。例えば、ユーザ６０とは、特定の製品を生産するために特定の順で装置５６を使用するプロセス制御システム５２により実行される特定のレシピを指すことができる。装置ユーザ６０は装置５６自身であってもよい。例えば、ポンプ装置が特定の材料をタンク装置に充填できるように、ポンプ装置はタンク装置にアクセスを求めるが、その際ポンプ装置は装置ユーザとしての機能を果たしうる。さらに、装置ユーザ６０は、原材料など生産工程自体の一部として使用される材料を指す場合もある。例えば、現在タンクに格納されている第１の物質は、レシピの一部として第１の物質をヒータに移動させるためにポンプへのアクセスを求める場合もある。また、装置ユーザ６０は、プロセス制御システム５２により直接に制御されていないが、プロセス制御システム５２から装置５６にアクセスを求める場合のある、人間又はその他のエンティティ（実体）でもありうる。一般に装置ユーザ６０は、人間、材料、ハードウェア、ソフトウェア、及びその他のプロセス制御システム５２の制御下で製品を生産するために工場施設５０により使用される装置５６のうちの少なくとも１つでありうる。
【００３３】
稼動中に一人又は複数人の人間ユーザ（図示せず）は、プロセス制御システム５２を使用して一つ又は複数のレシピ、バッチプロセス又はその他のプロセスの実行を構成、制御および監視することができる。レシピは、一つ又は複数の所望の最終製品を生成するためにプロセス工場５０で利用可能な装置５６を使用して実行される。プロセス制御システム５２は、二つのユーザ６０が同じ装置５６を同時に使用しようとしないように、装置ユーザ６０による装置５６へのアクセスの制御をつかさどる。
【００３４】
図２は、区域５４と交信するプロセス制御システム５２のより詳細な図である。一般的に、プロセスコントローラ１２は、例えば一実施例ではイーサネット（登録商標）通信接続でありうるローカルエリアネットワーク（ＬＡＮ）１５を介して多数のワークステーション１４に連結されている。また、コントローラ１２は、プロセス工場内の装置又は設備機器（全体として５６の参照番号で示される）に、一つ又は複数の入出力（Ｉ／Ｏ）装置（図示せず）および一式の通信線及び／又はバス１８を介して連結される。コントローラ１２（例としては、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ社により販売されるＤｅｌｔａＶ（登録商標）バッチコントローラが挙げられる）は、一つ又は複数のプロセス制御ルーチンを実行することによってプロセス工場５０の所望の制御を実施するためにプロセス工場５０全体にわたり分散される、フィールド装置およびフィールド装置内の機能ブロックなどの制御要素と通信できる。これらのプロセス制御ルーチンは、連続プロセス制御ルーチンでありうるが、本明細書においてはバッチプロセス制御ルーチン又は手順として記載される。ワークステーション１４（例えばパーソナルコンピュータ、サーバ、などでありうる）は、コントローラ１２と通信すべくコントローラ１２により実行される、一つ又は複数のプロセス制御ルーチンを設計および実行するため、前記のようなプロセス制御ルーチンをダウンロードのために通信するため、プロセス工場５０の稼動中にプロセス工場５０に関する情報を受信および表示するため、またそれ以外の場合は例えばコントローラ１２により実行されるプロセス制御ルーチンと交信するために、一人又は複数人のエンジニア又はオペレータ又はその他のユーザにより使用されることができる。また、データ・ヒストリアン１９は、ＬＡＮ１５に接続してもよく、任意の周知又は所望の方法にて、工場５０内（コントローラ１２やフィールド装置ならびにワークステーション１４内を含む）で生成されたデータを自動的に収集し格納するようにしてもよい。
【００３５】
ワークステーション１４の各々は、構成設計用アプリケーションなどのアプリケーションを格納するため、及び、プロセス工場５０の構成に関する構成データなどのデータを格納するためのメモリ２０を含んでいる。ワークステーション１４の各々はまた、数ある特徴のなかでも特に、ユーザがバッチ制御ルーチンなどのプロセス制御ルーチンを設計すること且つこれらのプロセス制御ルーチンをコントローラ１２にダウンロードすることを可能にする、一つ又は複数のアプリケーションを実行するプロセッサ２１も含んでいる。同様に、コントローラ１２は、プロセス工場５０の制御に使用されるプロセス制御ルーチンと構成データを格納するためのメモリ２２を含んでおり、また、プロセス制御法を実施するためにプロセス制御ルーチンを実行するプロセッサ２４を含んでいる。コントローラ１２がＤｅｌｔａＶ（登録商標）バッチコントローラの場合、それはワークステーション１４のうちの一つにある一つ又は複数のアプリケーションと連動して、プロセス制御ルーチン内の制御要素およびこれらの制御要素がプロセス工場５０の制御を提供する構成のされ方を示すことにより、コントローラ１２内のプロセス制御ルーチンのグラフィック描写をユーザに提供しうる。
【００３６】
図２に示される実施例では、コントローラ１２がバス１８を介して同じように構成された２組の設備機器に通信可能に接続されており、当該設備機器の各組は、ここでは反応装置＿０１又は反応装置＿０２として示される反応処理ユニットと、フィルタ＿０１又はフィルタ＿０２として示されるフィルタユニットと、乾燥器＿０１又は乾燥器＿０２として示される乾燥器ユニットとを備えている。反応器＿０１には、反応器槽１００と、例えばヘッドタンク（図示せず）から反応器槽１００へ流体を供給する流体入口配管を制御するように接続された二つの入力バルブ１０１および１０２と、流体出口配管を介して反応器槽１００からの流体の流れを制御するように接続された出力バルブ１０３とが含まれる。温度センサ、圧力センサ、液面計測器などのセンサ又は電気的なヒータや蒸気ヒータなどの他の何らかの設備機器であってよい装置１０５は、反応器槽１００に、又は該反応器槽の付近に配置される。反応器＿０１は、乾燥器設備１２０を有する乾燥器＿０１に順じて連結されるフィルタ設備１１０を有するフィルタ＿０１にバルブ１０３を介して連結される。同様に、二台目の設備機器には、反応器槽２００、二つの入力バルブ２０１と２０２、出力バルブ２０３および装置２０５を有する反応器＿０２が含まれている。反応器＿０２は、乾燥器設備２２０を有する乾燥器＿０２に続いて連結されるフィルタ設備２１０を有するフィルタ＿０２に連結される。フィルタ設備１１０，２１０および乾燥器設備１２０，２２０は、それに関連するさらに別の制御要素（ヒータ、コンベヤベルトおよびそれ同等のもの等）およびセンサなどを備えうる。図示されていないが、望ましい場合は、各反応器、フィルタおよび乾燥器のうちの一つを使用するバッチの実行が図２に示される設備機器の任意の組合せを使用できるように、各々のフィルタユニット（フィルタ＿０１およびフィルタ＿０２）を各々の反応器・ユニット（反応器＿０１および反応器＿０２）に物理的に連結し、各々の乾燥器ユニット（乾燥器＿０１および乾燥器＿０２）を各々のフィルタユニット（フィルタ＿０１およびフィルタ＿０２）に連結してもよい。
【００３７】
図２に図示されるように、コントローラ１２は、バス１８を介して、バルブ１０１，１０３，２０１，２０３に、装置１０５，２０５に、フィルタ１１０，２１０に、乾燥器１２０，２２０に（およびそれに関連する他の設備に）通信可能に連結され、これらの（ユニット、フィールド装置などであってよい）要素の作動を制御し、これらの要素に関しての一つ又は複数の動作を行う。このような動作としては、例えば反応器槽（又は乾燥器）の充填、反応器槽又は乾燥器内の材料の加熱、反応器槽又は乾燥器の中身の排出、反応器槽又は乾燥器の清浄、フィルタの操作などが挙げられる。もちろん、コントローラ１２は、例えば４−２０ｍａ回線、ＨＡＲＴ（登録商標）通信線などの専用の通信線を介して、さらには別のバスを介して、プロセス工場５０内の要素に連結することも可能である。
【００３８】
図１に図示されるバルブ、センサおよびその他の設備機器は、例えばＦｉｅｌｄｂｕｓフィールド装置、標準の４‐２０ ｍａフィールド装置、ＨＡＲＴ（登録商標）フィールド装置などをはじめとするいかなる所望の種類又はタイプの設備であってもよく、Ｆｉｅｌｄｂｕｓプロトコル、ＨＡＲＴ（登録商標）プロトコル、４−２０ ｍａアナログ・プロトコルなどの任意の周知又は所望の通信プロトコルを使用してコントローラ１２と通信することができる。さらにまた、その他のタイプの装置を、所望の任意の方法にて、コントローラ１２に接続し、コントローラ１２により制御してもよい。また、プロセス工場５０に関連したその他の装置又は区域を制御するために、その他のコントローラを、例えばイーサネット（登録商標）通信回線１５を介してコントローラ１２およびワークステーション１４に接続しても良い。また、任意の所望の又は周知の様態において、このような付加的なコントローラの動作は図２に示されるコントローラ１２の動作と協調することができる。
【００３９】
一般的に言って、例えば一つ又は複数の制御レシピに従ってプロセス工場５０内の異なるバッチ稼動を実施し、場合によっては協調させるバッチ実行アプリケーションをワークステーション１４の一つによって実行する、バッチプロセスを実施するために、図２のプロセス制御システムを使用しうる。このようなバッチ実行エンジン３０は、図１のワークステーション１４ａに格納された状態で図示されている。この場合当然のことながら、バッチ実行エンジン３０は、それ以外のワークステーション１４、又は任意のワイヤレス（無線）形態を含む任意の所望の形態でバス１５又はバス１８に通信可能に接続されたその他のコンピューターにおいて格納および実行できるはずである。同様に、望ましい場合はバッチ実行エンジン３０を、様々な構成素子に分割してもよく、あるいは、プロセス工場５０内の異なるコンピューター又はワークステーションに格納され、そこで実行される様々な構成要素に関連付けられてもよい。
【００４０】
バッチ実行エンジン３０は一般に先述の制御レシピなどの高レベルの制御ルーチンである。ユーザがプロセス工場内で実行すべき複数のバッチ稼動を指定できるようにし、根本的に独立してプロセス工場制御ネットワーク１０内で動作するように複数の異なるバッチ稼動又はバッチプロセスを設定するバッチキャンペーン管理機能と一般に呼ばれるものが、該バッチ実行エンジン３０には含まれうる。また、バッチ実行エンジン３０は、キャンペーン管理機能により指定された異なるバッチの実行を実施および監視するバッチ・エクゼクティブ・ルーチン又はアプリケーションを含みうる。このようなバッチの実行はそれぞれ、各々がプロセス工場１６内の反応器・ユニット、フィルタユニット、乾燥器ユニット、又はその他の設備機器の一つなどの単一ユニット上で作動するサブルーチン又はプロセスである（又はありうる）一つ又は複数の処理手順、ユニット手順、動作、フェーズ、およびその他のバッチ小区分の動作を指示する。この実施例において、各ユニット手順（一般的にワークステーション１４のうちの一つで実行されるバッチ実行の一部である）は、それぞれが物理的ユニットの一つ又は複数のフェーズを実行しうる一連の動作を実行することができる。これを説明するにあたって、フェーズ、動作、ユニット手順および手順という用語は、Ｓ８８標準により定義される手順要素のそれらを指しうるものである。従って、フェーズとは、実行される最下位レベルのアクション又はステップであり、通常はコントローラ１２の一つにおいて実施又は実行されるものである。また、動作とは、特定の機能を実行する一組のフェーズであり、通常はコントローラ１２内の一連のフェーズを呼び出すことによりワークステーション１４の一つで実施又は実行される。ユニット手順とは、実行される一連の一つ又は複数の動作で、通常ワークステーション１４の一つにおける一式の動作呼出しとして実施される。同様に、手順とは、制御レシピ内のステップとして実施され、例えばプロセス工場５０内の異なる物理的装置又は設備機器上で実行されうる一式のユニット手順でありうる。しかるに、手順はいかなるものでも一つ又は複数のユニット手順を含むことができ、ユニット手順はいかなるものでも一つ又は複数のフェーズ且つ又は一つ又は複数の動作を含むことができる。このように、各バッチプロセスは、例えば食品製品や薬物などの製品を生産するために必要とされる異なるステップ又は段階（例えば、ユニット手順）を実行する。「手順要素」という用語は、本稿において手続き型モデルのこれらのレベルの任意の実施形態又は実装を示す意味で使用されており、「手順」のレベル又はその他手続き型モデルの単一レベルだけに限定されるものではない。
【００４１】
個々のバッチに対して異なる手順、ユニット手順、動作およびフェーズを実施するために、制御レシピは、実行されるべきステップと、ステップに関連した量および時間およびステップの順序を指定する。一つのレシピのためのステップには、例えば反応器槽に適切な材料又は成分を充填すること、反応器槽内の材料を混合すること、特定の時間をかけて反応器槽内の材料を特定の温度に加熱すること、反応器槽を空にしてから次のバッチのための準備として反応器槽を清掃すること、反応装置の生産物をろ過するためにフィルタを稼動すること、そしてその後に反応器槽中で生成された製品を乾燥させるために乾燥器を稼動すること、を含んでよい。異なるユニットに関連する各一連のステップはバッチのユニット手順を定義し、制御レシピはこれらユニット手順の各々に対して異なる制御アルゴリズムを実行することになる。もちろん、特定の材料、材料の量、加熱温度および時間などは、レシピごとに異なっていてよい。その結果として、これらのパラメータは、製造又は生産される製品および使用されるレシピによってバッチの稼動ごとに変化しうる。
【００４２】
当業者にとっては当然のことながら、業界標準による（汎用）バッチプロセスにおける同一のフェーズ、動作、ユニット手順および手順は、異なる実際のバッチプロセス又はバッチ実行の一部として同時に又は異なる時点で、図２に示されるような異なる反応器ユニットのそれぞれで実施できる。さらに、通常図２の反応処理ユニットには同じ数又はタイプの設備機器（すなわち、これらは同じユニット・クラスに属する）が含まれているので、異なる反応処理ユニットの各々を制御するために特定のフェーズについて同じ業界標準により構成されるフェーズ制御ルーチンを使用しうる。但しこれは、異なる反応処理ユニットに関連した異なるハードウェア又は設備機器を制御するには当該の業界標準によるフェーズ制御ルーチンを修正変更しなければならない場合を除く。例えば、（反応処理ユニットが充填される段階である）反応装置＿０１の充填フェーズを実施するために、充填制御ルーチンは、一つ又は複数の入力バルブ１０１又は１０２を特定の時間（例えば、容器槽１００が満タンになったことを液面レベル計測器１０５が検知するまで）開くことになる。しかしながら、この同じ制御ルーチンを使用して、単に入力バルブの指示をバルブ１０１又は１０２の代わりにバルブ２０１又は２０２に変更するとともに、液面レベル計測器の指示を液面レベル計測器１０５の代わりに液面計測器２０５に変更するだけで、反応装置＿０２の充填フェーズを実施することができる。
【００４３】
図３は、バッチ実行エンジン３０において実施され、バッチ実行エンジン３０により実行される制御レシピ３００の実行例を示す。以下の実施例は、手順要素が区域内の設備又は装置の制御に関係する状態を例として手順要素に関連して説明されているが、当然のことながら、例えば手順要素がプロセス内の異なる区域に関係するなど、手順要素がプロセスの階層中の高位レベルに関係しうるし、もしくは、例えば手順要素が異なるユニット、異なるループ、異なる設備などに関係するなど、手順要素はプロセスの階層の下位レベルにも関係しうることが分かるはずである。同様に、制御レシピにおける手順要素の実施は、制御レシピの階層における様々なレベル（あらゆる手順、ユニット手順、動作又はフェーズを含む）を参照して行われることが分かるはずである。従って、制御レシピの実行は、一つ又は複数のバッチプロセスの高レベル実行に関係して、又はバッチ稼動中にプロセスの下位レベル実行に関係して行われうることが分かるはずである。このように、制御レシピ実行３００と、制御レシピを実施するためのここに記載される技法は、バッチプロセス内のあらゆるレベルの実行に適用されうる。
【００４４】
図３に示されるように、制御レシピは上記のように手順要素又はステップの階層を含んでいる。それぞれの手順要素又はステップは、制御レシピによって特定の順に実行するように構成され、制御レシピの実行は、二つ以上の手順要素間でいくつかの決定樹状図を含みうる。各決定ごとに行われる手順要素の選択は、プロセスの状態や、プロセスから送り返されたパラメータや、制御レシピ内の前回の手順要素の結果、又はバッチ稼動に関係する多種多様な要因の任意のものを含む多種多様な要因に依存しうる。従って、他ならずある一つの手順要素を利用する決定により、選択された手順要素の実行がもたらされ、選択されなかった１以上の手順要素は実行されない。但し、選択されなかった１以上の手順要素は、制御レシピの実行中に別のところで実行される場合もある。しかし、選択されなかった手順要素がバッチ稼動中に一度も実行されない可能性があることに変わりはない。
【００４５】
特に、図３を参照するに、制御レシピの実行は、ブロック３０２で第１の手順要素の実行とともに開始し、その後に続くブロック３０４では、ブロック３０６で第２の手順要素を実行するか、ブロック３０８で第３の手順要素を実行するかの決定が下される。ブロック３０４での決定は、ブロック３０２における第１の手順要素から得られる結果に依存しうる。例えば、ブロック３０２での第１の手順要素が反応器槽の反応装置＿０１ １００を充填して反応処理を実行することになっている場合、ブロック３０４での決定は、センサ１０５からの計測に基づいて反応処理が完了したかどうかを判断することに基づくことができる。反応処理が全て完了した場合、制御レシピは、フィルタ１１０に反応装置１００の中身を出力するためにバルブ１０３を開くべく、ブロック３０６の第２の手順要素に進んでよい。反応処理が完了していない場合、制御レシピは、ブロック３０８で第３の手順要素（及び、場合によっては、それ以降の決定に依存しうるそれ以降の手順要素）を使用することにより反応処理を継続又は繰り返してよく、この場合制御はブロック３０６の第２の手順要素に戻る。或いは、ブロック３０６の第３の手順要素は、フィルタ１１０に反応装置１００の中身を出力するためにバルブ１０３を開くことも行いうるが、第３の手順要素は異なる様態で関係することになり、この場合、第２の手順要素が選択された場合のバッチプロセスの実行に照らして（と比較して）バッチプロセスが実行される。
【００４６】
このように、制御レシピは、任意数の手順要素（手順１−Ｎ）３０２、３０４、３０８、３１２、３１４、３１８、３２０の将来的に行われる可能性のある実行に関与しうる。なお、制御レシピの実行中に下される決定３０６、３１０、３１６によっては、これらの手順要素の全てが制御レシピの実行中に実行されるとは限らない。図３に示される手順３、４、５、・・・Ｎのうちのいずれかは、制御レシピの実行中に実行されない場合もある。現に、例えばブロック３０８で手順３として表される手順要素は、制御レシピ内のブロック３０４における「ＯＲ」決定点で下される選択によっては実際に必要とされない場合もある。一方、手順要素のいくつかは、制御レシピ（例えば、手順１と手順２）の実行中に必ず実行されてよい。
【００４７】
また図３に示されるように、制御レシピの実行中に行われる手順要素（例えば、手順２）の実行には、手順のステップの階層構造中に配列される一つ又は複数の下位手順要素の実行がさらに含まれうる。例えば、ブロック３０６での第２の手順要素がバルブ１０３を開き且つ反応装置１００の中身をフィルタ１１０に出力するための動作に関与している場合、下位手順要素は、フィルタ１１０を作動するためにインスタンス化された別の下位手順要素（例えば、フェーズ）を伴い、自己の開口を制御するためにインスタンス化されたフェーズでありうる。制御レシピの実行と同様に、手順要素の実行も一つ又は複数の決定を伴いうる。従って、下位手順要素のいくつかは、手順要素の実行の一環として必ず実行される反面、その他の下位手順要素は手順要素の実行中に実行されない場合がある。さらにまた、手順要素内の下位手順要素にはさらなる下位手順要素を含んでよく、さらに下位の手順要素についても同様である。例えば、上記されるように、制御レシピは、それぞれがユニット手順を含みうる手順をいくつか含みうるし、また該ユニット手順は動作を含みうるし、動作はフェーズを含みうる。このように、図３に示される制御レシピは実際に高位レベルの制御レシピ内に含まれる手順要素でありうる。
【００４８】
当然のことながら、本稿において手順要素および下位手順要素という用語は、全体的なバッチプロセスの階層中の異なるレベルにある手順要素間の関係は下記される請求の範囲を限定するものとして解釈されるべきでないことを明らかにする意図のもとにだけ用いられている、と理解されたい。例えば、階層のあるレベルに属する手順要素（例えば、ユニット手順）は、階層の別のレベル（例えば、手順）に関して考慮した場合に下位手順要素としてみなされうる。逆に、階層中のあるレベルに属する下位手順要素は、階層中の別のレベルの（例えば、フェーズ）に関して考慮した場合に手順要素としてみなされうる。このように、あらゆる手順要素又は下位手順要素は、それ自体が各々、全体的なバッチプロセス制御の階層中の異なるレベルで制御レシピと関係しうる。さらに、制御レシピ実行３００が種々様々な決定３０４、３１０、３１６を含んだ状態で示されているが、当然のことながら、制御レシピの実行には、事前に構成された順に実行される一連の手順要素が含まれてよく、手順要素の各々が制御レシピの実行中に実行される。
【００４９】
図４は、制御レシピの実行中に各手順要素をインスタンス化するために一つ又は複数のインスタンス化オブジェクト又はプロセスを実施する制御レシピの構造の実施例である。具体的には、制御プロセス実行オブジェクト又はプロセスを使用して、バッチ実行エンジン３０はバッチ生成の時点で制御レシピの構造を読み込み、制御レシピがインスタンス化されるか、もしくは読み込まれた時点でインスタンス化オブジェクトを読み込むことができる。バッチを稼動するのに使用しうる全ての手順要素、構造、レシピ・パラメータ、設備機器などを含む制御レシピ構造全体を読み込む、典型的な制御レシピ実行と比較した場合、インスタンス化オブジェクトは、手順要素が制御レシピにより利用されるにつれて（利用される際に）、それぞれの手順要素をインスタンス化するために使用される。繰り返して言うが、特定の手順要素が制御プロセスの実行中に実際に実行されうるかどうかに関する選択は、作成時（例えば、制御レシピが実行に向けて読み込まれた場合）に分かる場合もあれば、実行時（例えば、制御レシピの実行）まで分からない場合もある。手順要素が実行された後、インスタンス化オブジェクトは制御レシピから手順要素をアンロードし、制御レシピは実行を続ける。別の言い方をすると、制御レシピに含まれる様々な手順要素は、作成時にではなく、むしろ必要とされた場合にだけ「ジャストインタイム」で読み込まれる。制御レシピにより手順要素が利用される際にそれぞれの手順要素をインスタンス化するためにインスタンス化オブジェクトを使うことにより、それぞれの手順要素は概して、手順要素が実行される間のみ、プロセス制御システム５２（例えば、メモリ、プロセッサ、ソフトウェア、など）のリソースを利用する。さらに、手順要素のインスタンス化を作成時にではなく必要な時だけに行うようにすることにより、制御レシピの実行中に実際に使用される手順要素だけが、プロセスシステム５２のリソースを利用することになる。結果として、リソースの利用の点で、バッチ実行エンジン３０（および一般にプロセスシステム５２）の性能の能率向上（例えば、プロセッサ利用率の向上、メモリーリソース使用率の向上、など）を実現することができる。
【００５０】
図４を参照すると、制御レシピの論理構造が、手順ハイドレータとして示される（例えば、Ｐｒｏｃ＿Ｈｙｄｒａ １Ｎ）複数のインスタンス化オブジェクトに関連して示されている。図に示されるように、制御レシピの論理構造は、様々な手順要素およびあらゆる「ＯＲ」決定点の実施においてあらかじめ定義された論理的な順序を伴う点で、図３に示される構造に類似する。しかしながら、制御レシピの論理構造は、制御レシピの実行中に呼び出されうる全手順要素をはじめとし、バッチ作成時に制御レシピ全体を読み込むのではなく、手順要素無しでバッチ実行エンジン３０に読み込まれる。一実施例において、制御レシピの論理構造は、制御レシピの論理的な流れ、「ＯＲ」決定点、および制御レシピの実行中に呼び出されうる可能な手順要素のそれぞれと関連付けられているマーカー又は呼出しを参照できる。
【００５１】
また、バッチ作成時には、インスタンス化オブジェクトの各々をバッチ実行エンジン３０に読み込むことができる。図４に示され、図３と比較した場合、インスタンス化オブジェクトは、制御レシピの実行中に実行されうる手順要素のそれぞれと関連付けられている。一実施例においては、インスタンス化オブジェクトの各々を制御レシピの論理構造において実施してよい。一方、制御レシピの論理構造内の呼出し又はマーカーは、手順要素をインスタンス化するのに必要とされる場合に各インスタンス化オブジェクトを呼び出すために使用することができる。
【００５２】
バッチ実行時および制御レシピ実行中に、各手順要素は、各手順要素がリソースを必要な時のみ使用するように手順要素の実行所要時間内にインスタンス化され、実行され、解体される。例えば、バッチプロセスの実行時中に、バッチ実行エンジン３０は、図３に示される手順要素１のインスタンス化を行うためにブロック４０２のインスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ １を使用して図４の制御レシピを開始する。いったん手順要素１が実行されると、バッチ実行エンジン３０は、手順要素１を解体するためにインスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ １を使用し、それによって、その実行中に手順要素１に割り当てられた全てのリソースは、割当て解除されてバッチ実行エンジン３０に戻される（又は解放される）。その後、制御レシピの実行は、手順２又は手順３に進むかの決定を提示する決定点４０４に達する。（なお、手順２又は手順３のどちらに進むかの選択は前回手順１の実行によって決定される。）制御レシピの論理に基づいて手順３が選択されると、インスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ ３は手順３をインスタンス化するために使用され、その一方、手順２が選択されると、インスタンス化オブジェクトＰｒｏｃ＿Ｈｙｄｒａ ２は手順２をインスタンス化するために使用される。従って、制御レシピの実行は、実行中に呼び出されうる手順要素３０２、３０６、３０８、３１２、３１４、３１８、３２０の各々を、（ここに記載される順で）各々インスタンス化オブジェクト４０２、４０８、４０６、４１２、４１４、４１８、４２０と置き換えるか、又はインスタンス化オブジェクト４０２、４０８、４０６、４１２、４１４、４１８、４２０に呼出しをかける。
【００５３】
インスタンス化オブジェクトは、手順要素中に呼び出されるあらゆる下位手順要素に対して同じような方法で使用することができる。例えば、実行手順２において、手順要素の論理構造はインスタンス化オブジェクトを含んでよく、或いはインスタンス化オブジェクトに呼出しをかける。下位手順要素（例えば、ユニット手順、動作、フェーズ、など）が手順要素（例えば、手順２）の実行中に必要とされる場合には、インスタンス化オブジェクトは、下位手順要素が手順要素の実行時中に実行され、下位手順要素の完了時に解体されるように、関連付けられている下位手順要素をインスタンス化するために使用される。手順要素は必要に応じて継続してもよく、又は終了し手順要素に関連するインスタンス化オブジェクトにより解体されてもよい。これによって制御レシピは必要に応じて実行を続ける。このように、インスタンス化オブジェクトを制御レシピ内の様々な階層レベルにも同様に適用できることが分かる。
【００５４】
図５は、制御レシピにより使用される手順要素をインスタンス化し解体するためにインスタンス化オブジェクトにより使用されるプロセスの実施例である。インスタンス化オブジェクトは、それが関連付けられており、作成時にインスタンス化オブジェクトに読み込みうる手順要素の論理構造を含むことができる。あるいは、インスタンス化オブジェクトには、手順要素がインスタンス化される時に手順要素の論理構造がどのように実施されるかを認識して手順要素の論理構造を構築する論理モジュール又はルーチンが含まれうる。
【００５５】
各インスタンス化オブジェクトは、手順要素の論理構造内のパラメータを実施する方法を認識する論理モジュール又はルーチンをさらに含んでよい。具体的には、インスタンス化オブジェクトは、異なるパラメータを伴う手順要素を生成する方法を理解する。この場合、実行時属性などの論理的文法項、又は制御レシピの実行中に開発された論理的文法項、そしてプロセス制御変数、プロセス制御データ、装置利用率などがパラメータに含まれうる。例えば、ブロック４０２における手順２のためのインスタンス化オブジェクトは、制御レシピにより実行された時に手順１から導かれた計測データ（例えば、反応装置１００を充填するために使用される製品の量）を利用する方法を理解することができる。手順２のためのインスタンス化オブジェクトはさらに、反応装置１００に関する装置情報（例えば、充填状態、圧力）を、手順２をインスタンス化する際に利用する方法を理解することができる（例えば、バルブ１０３を開くための移動距離および速度）。さらにまた、インスタンス化オブジェクトは、手順２において使用される装置のパラメータ（例えば、およびバルブ、診断の情報）を考慮することができる。インスタンス化オブジェクトはこのように、実行中に手順要素により使用されることになっているパラメータを伴う、関連付けられている手順要素の論理構造を構築しデータ投入することができる。
【００５６】
図５を参照すると、インスタンス化オブジェクト（Ｐｒｏｃ＿Ｈｙｄｒａ）は、ブロック５０２における制御レシピ又はバッチ実行エンジン３０により起発動されるか又は呼び出されるのを待機してよい。例えば、インスタンス化オブジェクトは、インスタンス化オブジェクトに関連した手順要素の呼出しに基づいて起動又は呼び出されることができ、制御レシピの論理構造に含まれるかどうかに基づいて起動されることができ、又は制御レシピの論理構造におけるインスタンス化オブジェクトのマーカー或いは呼出しを含むかどうかに基づいて呼び出されることができる。
【００５７】
インスタンス化オブジェクトがブロック５０２にて呼び出されるか、又は起動されると、インスタンス化オブジェクトは、関連付けられている手順要素により、又はその内部で、インスタンス化される。上記に示されるように、各インスタンス化オブジェクトは、バッチ実行エンジン３０に、読み込まれたインスタンス化オブジェクトに関連付けられている手順要素の論理構造を伴って読み込まれうる。一方、ブロック５０４では、インスタンス化オブジェクトは上記参照される論理モジュール又はルーチンを使用して、あらゆる下位手順要素に対する考慮を含む手順要素の論理構造を構築しうる。いったん手順要素の論理構造が構築されると（もしくは読み出されると）、インスタンス化オブジェクトはブロック５０６で、前回実行された手順要素により導かれたか又はそれに基づくパラメータを含む、制御レシピの実行時中に導かれたパラメータを含むか又はパラメータに基づいていてよい、手順要素のパラメータを読み出す。上記されるようにパラメータは、使用する設備機器、プロセス制御データ、プロセス制御変数、論理的文法項又は属性など（但しこれらに限定されない）を含むことができる。
【００５８】
ブロック５０８にてインスタンス化オブジェクトは、手順要素のインスタンス化を終了させるために、ブロック５０６に読み出されたパラメータと手順要素の論理構造をマージする。インスタンス化オブジェクトの論理は、（バッチ実行エンジン３０により誘導されうる）実行を行うために手順要素により必要とされる場合にパラメータおよび論理構造をマージするために提供される。その後、手順要素は、ブロック５１０にて制御レシピ内の実行用のバッチ実行エンジン３０に読み込まれる。
【００５９】
ブロック５１２では、手順要素が実行を終えるのをインスタンス化オブジェクトが待つ。手順要素が実行された場合（インスタンス化オブジェクトが発動又は呼び出されることで実行されたことが示される）、インスタンス化オブジェクトはブロック５１４にて手順要素を解体するために使用される。具体的には、インスタンス化オブジェクトは、バッチ実行エンジン３０からの手順要素をアンロードしてもよく、それによって、バッチ実行エンジン・リソースを解放し、手順要素の論理構造からパラメータを取り除く。インスタンス化オブジェクトは、手順要素の論理構造を維持しうる、又は論理構造を解体しうる。その後、インスタンス化オブジェクトは、制御をブロック５０２に戻して、制御レシピの実行中に必要に応じて再起動又は再呼出し可能な状態になる。
【００６０】
図６は、バッチ実行環境における制御レシピの上記の実施に使用されることができるインスタンス化オブジェクトのさらなる態様を例示する。特に、制御レシピの実行に使用される多くの手順要素が同じ論理構造を利用するか、或いは手順要素間の相違はその中に利用されているパラメータにだけ存在する。根本的に、同じ論理構造が制御レシピ実行の間に何度も利用される。但し、上記の説明からも分かるように、手順要素により利用されるパラメータは、実行時（即ち、制御レシピの実行中）まで分からない場合もある。
【００６１】
例えば、図３を再び参照すると、手順４および手順５の間の相違は、手順４は反応装置１００上で稼動するが、手順５は反応装置２００上で稼動するということである。手順４および手順５のそれ以外の論理構造は同じで、それに関連する設備機器およびパラメータだけが異なる。別の実施例として、手順１が反応装置１００を使用した反応工程を伴う場合には、決定点３０４での決定ステップにより、再び手順３を使用して反応工程を稼動する必要があるのか、或いは手順２を使用してバッチプロセスを続けるのかどうかが決定されうる。異なるパラメータ（例えば、異なる反応時間）を伴う場可能性があるが、手順３は根本的に手順１の再実行であるため、手順３は手順１と同じ論理構造を有しうる。
【００６２】
図６に戻って参照すると、一般的に６００の参照番号で示される制御レシピの実行は、種々様々な手順要素６０２、６０４、６０６（手順Ａ〜Ｃ）を含む状態で図示されている。もちろん当然のことながら、制御レシピは、様々な手順要素および下位手順要素の品目構造などを含み、図６に示されるものよりもはるかに複雑でありうる。手順ＡとＣ（６０２，６０６）はそれぞれ同じ論理構造を含んだ状態で示されている。従って、全体として６０８の参照番号で示される同じインスタンス化オブジェクトは、手順要素ＡおよびＣの両方に使用することができる。即ち、同じインスタンス化オブジェクト６０８が、必要に応じて、手順要素ＡとＣの各々をインスタンス化し、手順要素ＡとＣに特有のパラメータで論理構造をマージする際に、同じ論理構造を利用することができる。
【００６３】
結果として、制御レシピの実行には二つの異なる手順要素が利用されるが、一つのインスタンス化オブジェクトだけが両方の手順要素に必要とされる。即ち、作成時にインスタンス化オブジェクトが一つだけバッチ実行エンジン３０に読み込まれ、インスタンス化オブジェクトは、両方の手順要素に対して一つの論理構造を保持すれば良いか、もしくは、両方の手順要素に対して一つの論理構造を構築するための論理を保持すれば良いことになる。
【００６４】
制御レシピを実施するための上記のアプローチはメモリ使用量又は消費量を著しく向上できる（制御レシピの複雑性によっては９３％までも向上できる）ことが、比較検査の結果により明らかになっている。結果として利用可能リソースが増加し、さらに多くのバッチを同時に稼動することができる。必要に応じて各手順要素をインスタンス化するにはある程度の時間がかかるが、最大サイズの複雑な制御レシピの場合でさえも手順要素のインスタンス化にかかる所要時間の増加は数秒だけですむ。
【００６５】
上記ではバッチ実行技法が制御レシピを実施するための改善された方法とシステムを参照して説明されているが、プロセス制御システムにおける制御レシピの稼動は、実行環境に対する工場施設の物理的設備を示す設備機器（例えば、タンク、バルブ、ポンプ、など）のモデルに依存する。一般に手順要素は、パーソナルコンピュータやワークステーション１４およびコントローラ１２を含むデータ処理装置により、およびそのデータ処理装置内で実行される、コンピュータプログラムとして実施される。手順要素の実行は、設備機器などの物理要素を制御するために使用できるデータ処理装置からの出力をもたらす。手順要素は、少なくとも一つの物理要素に関して「基本制御」を起発動することにより、その割り当てられた作業を実行する。このタイプの制御は、物理要素に特定の期待される状態を設定および維持するために専用に設けられる。基本制御は、例えば、蓄積要素中の材料の流れを開始又は維持したり、又は、ポリ塩化ビニル反応器要素中の出発物質を加熱することもできる。
【００６６】
手続き型モデルの下位レベル（すなわちフェーズ）は、実際の物理的要素と実際の通信を実行することにより、基本制御を起動又は実行する。手続き型モデルの高位レベルは、手続き型モデルの編成および構造を（即ち、物理的モデルの編成および構造を）向上させるための抽象的概念として提供される。実行オブジェクト又はプロセスは、手順要素を実行するデータ処理装置（例えば、バッチ実行エンジン）上で稼動する。該オブジェクト又はプロセスは、一つ又は複数のモデルに従って手順要素の実行を協調させる。手順および、対応するユニット手順、対応する動作および対応するフェーズは、オブジェクト又はプロセスにより各々のステップを通じて順番付けられる。フェーズがインスタンス化される場合、該フェーズは、関連付けられているコントローラ１２内のフェーズ論理インターフェースにインスタンス化要求を通信する。その後、プログラム可能制御装置１２は、フェーズのための実状態論理を実行し、プロセス用設備機器と通信を行い必要なプロセス制御を提供する。
【００６７】
図７は、バッチ実行エンジン３０と、バッチ実行環境内のコントローラ１２、およびそれに提供される設備モデル７００との間の論理関係の例を示す。設備モデル７００は、モジュラー・ブロックが各々制御動作の論理セットを表す状態で生成されるように、Ｓ−８８標準に指定されるように、設備機器モジュールと制御モジュール７０２、７０４、７０６に分割される。例えば、反応装置およびそれに関連付けられているフィルタおよび乾燥器は、三つ又は四つの制御モジュールに分割され、該制御モジュールのそれぞれが、不適切に不要な供給材料を混合することなく、ある反応装置から別の反応装置に（又はある区域から別の区域に）製品を移動するよう、様々なバルブ１０３とポンプを操作し協調するために使用されうる。通常これらの制御モジュールはそれら自体が「フェーズ論理モジュール」７０８と称されるものを構成するためにグループ化される。
【００６８】
フェーズ論理モジュール７０８はそれ自体、例えば、「混合する」、「移動する」、「加熱する」など特定の作業を実行するのに使用しうるエンティティ（実体）である。通常、これらのフェーズ７０８は、分散型バッチ制御システムに存在するコントローラ１２において割り当てられ実行される。同時に、工場設備モデル７００もまた、各々完成品をもたらす高位レベル制御レシピの中に、コントローラ１２にて稼動する様々なフェーズ７０８を協調（編成）させる作業をつかさどる、「高位レベル」のバッチ実行エンジン３０に割り当てられ読み込まれる。
【００６９】
コントローラ１２およびバッチ実行エンジン３０間にはこのような論理関係が存在するので、制御レシピの実行が成功裡に完了するためにも、下位レベルコントローラ１２および高位レベルバッチ実行エンジン３０間の設備モデル７００の二つ複製の整合性を維持すべきである。けれども、見落としにより又は必要性が生じた結果、一つ又は複数のコントローラ１２により認識されている設備モデルと、バッチ実行エンジン１２の間に不整合性が生じうる。このような状態が生じた場合、不整合性が生じた際にバッチを完全に中断するのではなく、不整合を一致させるために以下に説明される解決技法を使用することができる。以下の技法を使用して、生産時間の損失が削減され、また、最悪の場合でも、実行されている物理的プロセスに関する時間制約による製品の損失が削減される。
【００７０】
図８は、コントローラ１２およびバッチ実行エンジン３０により保持されるモデル間における不整合性を解決するための技法の実施例を示す。具体的には該技法は、不整合性が検出され、実行時に不一致を解決するべきか無視するべきかを決定する能力を、バッチ実行エンジン３０又は工場人員に提供する方法を提供する。一実施例において、不整合性を解決するための技法は、上記されるように手順要素の実行の一部として実行されうる。このオプションにより、旧式と新規バージョンのモデル、又はそれのパラメータが同時に共存することが可能になると共に、工場設備モデル変更を実施する方法と時期を決定する際にフレキシビリティが提供される。
【００７１】
図８を参照すると、「フェーズ＿１」で示されるフェーズがプロセス工場内で使用され、フェーズ＿１はブロック８０２で「反応＿時間」として示される単一の入力パラメータ（フェーズがどれくらいの時間反応装置１００を稼動するか決定するためにそのフェーズ論理により使用される）を有する、と仮定した実施例が示されている。しかし当然のことながら図８に示される技法は、異なるモデルバージョン、異なる設備機器（例えば、異なる反応装置）用のモデル、又はその他のモデルパラメータを含むモデル間のいかなる不一致にも同様に適用しうる。さらに、モデルは、プロセス工場内の設備機器又は装置を参照して提供されているが、当然のことながらモデルは、ループ、ユニット、区域およびプロセス工場施設そのもの全体のモデルを含む、プロセス工場内のあらゆるエンティティ（実体）を参照してよい。
【００７２】
ある時点において、工場設備モデル全体の一部であるフェーズは、ブロック８０４に示されるようにコントローラ１２およびバッチ実行エンジン３０の両方にダウンロードされ、必要に応じて利用される。この実施例において、反応＿時間パラメータは実行時にバッチ実行エンジン３０により初期化され（なお、この作業はオペレータの入力選択に基づくことができる）、その後、フェーズ＿１が開始する直前に、コントローラ１２のもとに送信されることができる。
【００７３】
この実施例では、コントローラ１２のうちの少なくとも一つにおいて保持されるモデルと、バッチ実行エンジン３０により維持されるモデルとの間に不一致が生じる、とさらに仮定される。例えば、入力パラメータを一つだけ設ける代わりに二つ設けられるようにするために、工場人員がフェーズ＿１に修正変更を行う必要がありうる。例えば、工場人員は、フェーズ＿１完了後に製品がどこに送られるべきかを決定するために使用される第２のパラメータ（「排出＿先」）を追加することができる。このフェーズの新規バージョンを使用するために、変更がいかなるコントローラ１２にダウンロードされるべきであり、この場合、該コントローラ１２はブロック８０８に示されるような論理を稼動する必要があると同時にバッチ実行エンジン３０に新規情報を送る必要がある場合もある。
【００７４】
しかしながら、いくつかのコントローラ１〜Ｎ−Ｍへの変更を安全に更新することができるが、その他のコントローラ（Ｎ）への変更を安全に更新できないこともありえ、またそうなる見込みが多い。これは、コントローラを使用する様々なバッチの状態に基づきうる。例えば、バッチ実行エンジン３０が、その時点において第２のパラメータ（排出＿先）に更新されたモデル、より具体的にはフェーズを持っていないコントローラＮに対してバッチを稼動している場合、コントローラＮを使用しているバッチは、コントローラがモデルを更新するのを妨げうる。
【００７５】
バッチ実行エンジン３０がブロック８１０に示されるようにコントローラＮに対してバッチを実行する（例えば、コントローラＮに関連したプロセスを実行する）ために入力を受け取った時点で、バッチ実行エンジン３０は、ブロック８１２に示されるようなコントローラのもとに排出＿先の値を送る。しかし、コントローラ１２により保持されるフェーズ＿１の旧式バージョンは、新規の排出＿先パラメータについては何も認識しないだろう。
【００７６】
しかし、現実においては、不一致は全く害がないものでありうる。例えば、旧式の構成における排出＿先はフェーズ論理自体に「ハードコード」されているために、フェーズ＿１が、かなりの期間（例えば、数週間）、旧式の構成で問題なく稼動する可能性がある。この場合、ハードコードされた値が十分であり、フェーズ＿１はコントローラにより実行されうる。一方で、欠けているパラメータを無視することができない場合には、不整合性の見落とし（すなわち、新規の構成がコントローラにダウンロードされず、コントローラが排出＿先の値を含んでいない）が生じる可能性がある。不整合性については、ブロック８１４にてコントローラ１２により、例えば値又はパラメータが不明であることを示す値を受け取った時点でのハンドシェイク信号により、バッチ実行エンジン３０に報告されることができる。そしてバッチ実行エンジン３０は、オペレータが不整合性に対する対処を行えるように、ワークステーション１４に不整合性に関するメッセージを提供することができる。この場合、オペレータにはワークステーションユーザー又はワークステーション１４により利用される診断および保守ルーチンを含んでよい。あるいは、バッチ実行エンジン３０は、ワークステーション３０への報告を伴って、又はワークステーション３０への報告無しに、不整合性への対処を行ってもよい。
【００７７】
具体的には、自動的にバッチプロセスを中断する代わりに、ブロック８１８でバッチプロセスを中断するか（保留するか）、又はブロック８２０でバッチプロセスを続けることによりフェーズ＿１を実行し続けるかのオプションがブロック８１６で提供される。その決定（判断）は、ワークステーションユーザー次第、ワークステーション１４又はバッチ実行エンジン３０により利用される診断および保守ルーチン次第であってよい。例えば、プロンプト（入力要求メッセージ）が、ワークステーション１４でワークステーションのユーザ（例えば、工場のオペレータ）に表示されるか、もしくはワークステーション１４又はバッチ実行エンジン３０に提供されてもよい。プロンプトには、不整合の生じた位置（例えば、コントローラ）、関与するモデル、モデルのバージョン、関与するモデルパラメータ（例えば、フェーズ＿１、排出＿先）、又はその他の不整合性の原因となっているコントローラ１２のモデルとバッチ実行エンジン３０のモデル間の相違に関する、あらゆる情報を含む、不整合性に関する情報が含まれてよい。プロンプトにはさらに、使用されうる置換値（例えば、ハードコードされた値）を検索することにより不整合性の重大さを評価する際、又は不整合性が見落としエラーであったかどうか判断する際の付加的情報が含まれてよい。
【００７８】
プロンプト内に情報を提供するための論理は、コントローラ１２とバッチ実行エンジン３０およびワークステーション１４を含むプロセスシステムの様々な態様により提供されることができる。例えば、コントローラ１２およびバッチ実行エンジン３０はそれぞれ、各々のモデルバージョンおよび関連付けられたパラメータ、障害を起こすパラメータの識別情報、障害を起こすパラメータに以前使用された値、以前に行われた更新の日付／時間、などを提供してもよい。また、あらゆるコントローラ１２、バッチ実行エンジン３０およびワークステーション１４は、その情報を使用して、不整合性の出所およびそれのバッチプロセスに対する影響を決定することができる。もちろん、ユーザが決定を発動できるようにするためにこの情報をユーザに表示するようにもできる。
【００７９】
ブロック８１６での決定がバッチプロセスを中断すること（保留すること）である場合、コントローラ１２に正しいモデル又はモデル更新をアップロードすることにより不整合性が解決されることができる。ブロック８１６での決定がバッチプロセスを継続することである場合、モデル又はフェーズの旧式バージョンを使用する指示など、使用すべき代替情報がコントローラに提供されてよい。例えば、データ・ヒストリアン１９などから前回のバッチ稼動で問題なく使用された「排出＿先」の前回値（ハードコードされた値により提供されうる）がコントローラ１２に提供されてよい。コントローラ１２はその後フェーズ＿１を実行することができ、バッチプロセスの継続が許可される。コントローラ１２又はバッチ実行エンジン３０が使用しうるパラメータのその他の実施例は、既定値（例えば、製造メーカ既定値又はバッチプロセス既定）、ユーザにより入力された値などを含む。プロセスにおける複数のコントローラが同じモデル又はモデルパラメータを使用するが一つのコントローラだけが不整合性を提示する場合、バッチ実行エンジン３０は、全てのコントローラ１２により使用されるものであり、且つモデルの全てのバージョンと互換性を持つグローバルパラメータを提供することができる。
【００８０】
上記には本発明の多数の異なる実施形態の詳細な説明が記載されているが、当然のことながら、本発明の適用範囲は、本明細書に記載されている特許請求の範囲の記載により定義されるものと理解されたい。当該詳細な説明は、例示的なものとしてのみ解釈されるべきものであり、また、考えうる全ての実施形態を記載することは（不可能でないとすれば）現実的でないことから、考えうる全ての実施形態の説明を含んでいない。現存する技術又は、（なおも本発明を定義する特許請求の範囲に含まれる）本特許出願後に開発される技術のいずれかを用いて、別の実施形態をその他数多く実施することが可能である。
【００８１】
したがって、本発明の精神と範囲から逸脱することなく、ここに記載される技法と構成により多種多様の改造および変形が可能である。よって、当然のことながら、ここに記載される方法と装置は実施例に過ぎず、本発明の範囲を限定するものではない。
【特許請求の範囲】
【請求項１】
制御プロセスの実行中にプロセス制御システム内の装置モデルにおける不整合性を解決するためのシステムであって、
プロセス制御システムのエンティティの第１のモデルを含むプロセスコントローラと、
プロセス制御システムのエンティティの第２のモデルを備える制御プロセス実行エンジンであって、制御プロセス実行エンジンがエンティティの第２のモデルに基づいてプロセスコントローラに制御命令を提供し、前記プロセスコントローラがエンティティの第１のモデルに基づいて制御命令を実行するように構成されることを特徴とする、制御プロセス実行エンジンと、
制御プロセスの実行中にエンティティの第１および第２のモデル間の相違を検出し、相違の検出に応答してプロンプト（入力要求メッセージ）を生成し、制御プロセスの継続的な動作に関する動作指示を受け取る制御実行オブジェクトであって、前記動作指示が制御プロセスの実行を続けるか、制御プロセスの実行を中断するかのいずれかを含む、制御実行オブジェクトと、
を含むシステム。
【請求項２】
プロンプトが、エンティティの第１および第２のモデル間での相違の識別情報を含むことを特徴とする請求項１に記載のシステム。
【請求項３】
プロンプトが、エンティティの第１および第２のモデル間の相違に関するユーザへの表示を含むことを特徴とする請求項１に記載のシステム。
【請求項４】
動作指示が、制御プロセスからの制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする請求項１に記載のシステム。
【請求項５】
動作指示がユーザからの動作指示を含み、
制御プロセスの実行を続けるか、制御プロセスの実行を中断するかのオプションが前記ユーザに提供されることを特徴とする請求項１に記載のシステム。
【請求項６】
複数のプロセスコントローラをさらに含み、
エンティティの第１および第２のモデル間の相違が、エンティティの第１および第２のモデルのパラメータの相違を含み、
前記動作指示が、パラメータを利用する複数のプロセスコントローラの各々に提供されているユニバーサル・パラメータを使用して、制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする、請求項１に記載のシステム。
【請求項７】
エンティティの第１および第２のモデル間の相違が、エンティティの第１および第２のモデルのパラメータの相違を含み、
動作指示が、既定パラメータを使用して制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする、請求項１に記載のシステム。
【請求項８】
エンティティの第１および第２のモデル間の相違が、エンティティの第１および第２のモデルのパラメータの相違を含み、
動作指示が、第１および第２のモデルにより前回使用されたパラメータを使用して制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする、請求項１に記載のシステム。
【請求項９】
処理および実行環境における不整合性を解決する方法であって、
制御パラメータを生成するために、プロセス制御モデルの第１のバージョンに基づいて制御プロセスを実行することと、
プロセスにおけるコントローラに制御パラメータを伝送することと、
プロセス制御モデルの第２のバージョンで制御パラメータを使用して制御機能を実行することと、
プロセス制御モデルの第２のバージョンの制御パラメータ使用能力に基づいて制御プロセスの継続的な動作に関する動作指示を依頼し、プロセス制御モデルの第２のバージョンでパラメータを使用できない場合にプロセス制御モデルの第２のバージョンがエラーを生成することと、
動作指示が実行継続指示を含む場合に制御プロセスの実行を続けることと、
動作指示が実行中断指示を含む場合に制御プロセスの実行を中断することと、
を含む、処理および実行環境における不整合性を解決する方法。
【請求項１０】
動作指示の依頼には、エンティティの第１および第２のモデル間の相違の識別情報を有するプロンプトを通信することが含まれることを特徴とする請求項９に記載の方法。
【請求項１１】
動作指示を依頼することには、エンティティの第１および第２のモデル間の相違をユーザに表示することが含まれることを特徴とする請求項９に記載の方法。
【請求項１２】
プロセス制御モデルの第１および第２のバージョンのパラメータの相違によりパラメータを使用できない場合にエラーを生成することと、
パラメータを利用する複数のコントローラの各々にユニバーサル・パラメータを提供することと、をさらに含み、
制御プロセスの実行を続けることには、ユニバーサル・パラメータを使用して制御プロセスの実行を続けることが含まれることを特徴とする、請求項９に記載の方法。
【請求項１３】
プロセス制御モデルの第１および第２のバージョンのパラメータの相違によりパラメータを使用できない場合にエラーを生成することをさらに含み、
制御プロセスの実行を続けることには、既定パラメータを使用して制御プロセスの実行を続けることが含まれることを特徴とする、請求項９に記載の方法。
【請求項１４】
プロセス制御モデルの第１および第２のバージョンのパラメータの相違によりパラメータを使用できない場合にエラーを生成することをさらに含み、
制御プロセスの実行を続けることには、プロセス制御モデルの第１および第２のバージョンにより使用された前回のパラメータを使用して制御プロセスの実行を続けることが含まれることを特徴とする、請求項９に記載の方法。
【請求項１】
制御プロセスの実行中にプロセス制御システム内の装置モデルにおける不整合性を解決するためのシステムであって、
プロセス制御システムのエンティティの第１のモデルを含むプロセスコントローラと、
プロセス制御システムのエンティティの第２のモデルを備える制御プロセス実行エンジンであって、制御プロセス実行エンジンがエンティティの第２のモデルに基づいてプロセスコントローラに制御命令を提供し、前記プロセスコントローラがエンティティの第１のモデルに基づいて制御命令を実行するように構成されることを特徴とする、制御プロセス実行エンジンと、
制御プロセスの実行中にエンティティの第１および第２のモデル間の相違を検出し、相違の検出に応答してプロンプト（入力要求メッセージ）を生成し、制御プロセスの継続的な動作に関する動作指示を受け取る制御実行オブジェクトであって、前記動作指示が制御プロセスの実行を続けるか、制御プロセスの実行を中断するかのいずれかを含む、制御実行オブジェクトと、
を含むシステム。
【請求項２】
プロンプトが、エンティティの第１および第２のモデル間での相違の識別情報を含むことを特徴とする請求項１に記載のシステム。
【請求項３】
プロンプトが、エンティティの第１および第２のモデル間の相違に関するユーザへの表示を含むことを特徴とする請求項１に記載のシステム。
【請求項４】
動作指示が、制御プロセスからの制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする請求項１に記載のシステム。
【請求項５】
動作指示がユーザからの動作指示を含み、
制御プロセスの実行を続けるか、制御プロセスの実行を中断するかのオプションが前記ユーザに提供されることを特徴とする請求項１に記載のシステム。
【請求項６】
複数のプロセスコントローラをさらに含み、
エンティティの第１および第２のモデル間の相違が、エンティティの第１および第２のモデルのパラメータの相違を含み、
前記動作指示が、パラメータを利用する複数のプロセスコントローラの各々に提供されているユニバーサル・パラメータを使用して、制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする、請求項１に記載のシステム。
【請求項７】
エンティティの第１および第２のモデル間の相違が、エンティティの第１および第２のモデルのパラメータの相違を含み、
動作指示が、既定パラメータを使用して制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする、請求項１に記載のシステム。
【請求項８】
エンティティの第１および第２のモデル間の相違が、エンティティの第１および第２のモデルのパラメータの相違を含み、
動作指示が、第１および第２のモデルにより前回使用されたパラメータを使用して制御プロセスの実行を続けるようにとの動作指示を含むことを特徴とする、請求項１に記載のシステム。
【請求項９】
処理および実行環境における不整合性を解決する方法であって、
制御パラメータを生成するために、プロセス制御モデルの第１のバージョンに基づいて制御プロセスを実行することと、
プロセスにおけるコントローラに制御パラメータを伝送することと、
プロセス制御モデルの第２のバージョンで制御パラメータを使用して制御機能を実行することと、
プロセス制御モデルの第２のバージョンの制御パラメータ使用能力に基づいて制御プロセスの継続的な動作に関する動作指示を依頼し、プロセス制御モデルの第２のバージョンでパラメータを使用できない場合にプロセス制御モデルの第２のバージョンがエラーを生成することと、
動作指示が実行継続指示を含む場合に制御プロセスの実行を続けることと、
動作指示が実行中断指示を含む場合に制御プロセスの実行を中断することと、
を含む、処理および実行環境における不整合性を解決する方法。
【請求項１０】
動作指示の依頼には、エンティティの第１および第２のモデル間の相違の識別情報を有するプロンプトを通信することが含まれることを特徴とする請求項９に記載の方法。
【請求項１１】
動作指示を依頼することには、エンティティの第１および第２のモデル間の相違をユーザに表示することが含まれることを特徴とする請求項９に記載の方法。
【請求項１２】
プロセス制御モデルの第１および第２のバージョンのパラメータの相違によりパラメータを使用できない場合にエラーを生成することと、
パラメータを利用する複数のコントローラの各々にユニバーサル・パラメータを提供することと、をさらに含み、
制御プロセスの実行を続けることには、ユニバーサル・パラメータを使用して制御プロセスの実行を続けることが含まれることを特徴とする、請求項９に記載の方法。
【請求項１３】
プロセス制御モデルの第１および第２のバージョンのパラメータの相違によりパラメータを使用できない場合にエラーを生成することをさらに含み、
制御プロセスの実行を続けることには、既定パラメータを使用して制御プロセスの実行を続けることが含まれることを特徴とする、請求項９に記載の方法。
【請求項１４】
プロセス制御モデルの第１および第２のバージョンのパラメータの相違によりパラメータを使用できない場合にエラーを生成することをさらに含み、
制御プロセスの実行を続けることには、プロセス制御モデルの第１および第２のバージョンにより使用された前回のパラメータを使用して制御プロセスの実行を続けることが含まれることを特徴とする、請求項９に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−３７７２１（Ｐ２０１３−３７７２１Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１２−２２８６５２（Ｐ２０１２−２２８６５２）
【出願日】平成２４年１０月１６日（２０１２．１０．１６）
【分割の表示】特願２００８−１２７２４５（Ｐ２００８−１２７２４５）の分割
【原出願日】平成２０年５月１４日（２００８．５．１４）
【出願人】（５１２１３２０２２）フィッシャー−ローズマウント システムズ，インコーポレイテッド (28)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２４年１０月１６日（２０１２．１０．１６）
【分割の表示】特願２００８−１２７２４５（Ｐ２００８−１２７２４５）の分割
【原出願日】平成２０年５月１４日（２００８．５．１４）
【出願人】（５１２１３２０２２）フィッシャー−ローズマウント システムズ，インコーポレイテッド (28)
【Ｆターム（参考）】
[ Back to top ]