JP2009146386A - リアルタイムバッチラン環境下におけるオンライン式レシピ同期化 - Google Patents

Abstract

【課題】製造環境において、複数の動作および複数のパラメーターを指定する製品レシピによってバッチ処理を実行する際に、レシピの変更に迅速に対応する。
【解決手段】製品レシピの第１バージョンに対応しているバッチ処理の少なくとも１つの動作を行なうステップ３８８と、上記製品レシピの第１バージョンとは異なる上記製品レシピの第２バージョンを受け取るステップ３９４と、上記バッチ処理の実行をそのバッチ処理が完了する前に一時停止するステップ３９６と、および上記製品レシピの第２バージョンによって上記バッチ処理の実行を再開するステップ３９８を実行する。
【選択図】図７

Description

本発明は、一般にプロセス制御ネットワークに関するものであり、さらに詳しくは、現在実行中のバッチの変更を受け入れることのできるバッチランエンジンに関するものである。

本出願は、２００７年９月２１日に提出された「リアルタイムバッチラン環境下におけるオンライン式レシピ同期化」と題された米国仮出願第６０／９７４，３６８号の利益を主張するものであり、その出願の開示は参照によって本明細書の中にここで明確に組み入れられる。

大量の医薬、化学物質、飲料、塗料、または他のあらゆる生成物を生成するためにバッチ処理技術を使用するようなプロセス制御システムには一般に、例えば、バルブポジショナー、スイッチ、センサー（温度センサー、圧力センサーおよび流量センサー）などのような１つ以上のフィールド装置へ通信可能に連結された１つ以上の中央プロセス制御装置が含まれている。これらのフィールド装置は、例えば、バルブ、ポンプ、混合ユニットなどのような制御設備に関連付けられていてもよく、プロセス制御システムの内部で物理的制御機能（バルブの開放または閉鎖、ポンプまたは混合ユニットのオン・オフなど）を果たしてもよく、プロセスの動作を制御する際に使用するためにこのプロセス制御システムの内部で測定を行ってもよく、または、このプロセス制御システムの内部で他のあらゆる所望される機能を果たしてもよい。一般的に言えば、このプロセス制御装置は、１つ以上のフィールド装置によって得られた測定値を示す信号および／またはそのフィールド装置に関する他の情報を受け、この情報を典型的に複雑な制御ルーチンを実施するために使用し、かつ、信号回線または信号バスを通してこれらのフィールド装置へ送られた制御信号を生成して、このプロセス制御システムの動作を制御する。

さらにまた、これらのプロセス制御装置は一般に、イーサネット（登録商標）バス（Ethernet（登録商標） bus) のようなデータハイウェイを介して、１つ以上のワークステーションおよび他の装置へ連結されている。これらの他の装置は典型的には、上記制御ルーチンのユーザーインターフェイスを提供し、その制御ルーチンの修正または更新を可能にし、上記フィールド装置に接続され、履歴的プロセス制御データを記憶し、ユーザーのアクセスを制御しまたは制限するなどのような他のプロセス制御機能を提供するために、１つ以上の制御装置によって提供された情報を使用する他のアプリケーションまたはプログラムを実行する。いくつかの大きいプロセス制御システムでは、リモートサイトに置かれた１つ以上のワークステーションを、インターネット接続、衛星通信リンクまたは移動体通信リンク、無線リンク（無線イーサネット（登録商標）接続において使用されるような）などのようなさらに別の通信ネットワークを介してデータハイウェイへ連結することができる。

製品のバッチを生成するプロセス制御システムには一般に、ユーザー（例えばエンジニア）が１つ以上の基本的な製品レシピ、バッチパラメーター、設備リストなどを定義しかつ記憶させることのできるグラフィカルインターフェイス（graphical interface）が含まれている。これらの基本的な製品レシピには、それぞれ特定の設備リストに関連付けられまたは結び付けられた一連の処理ステップが典型的に含まれている。ユーザー（例えばオペレーター）は、これらのレシピ処理ステップを特定の設備へ関連付ける際に、レシピのバッチランの前に、そのレシピのそれぞれの処理ステップを実行するために使用される一部のプロセス制御設備を明確に定義する。加えて、それぞれの処理ステップには、ユーザー（例えばオペレーター）が、設備動作の順序および／またはタイミングを制御し、警報限界値を設定し、目標制御値（例えば設定値）を設定するなどするために、バッチの実行の間に使用される１つ以上の入力／出力（Ｉ／Ｏ）バッチパラメーター値を定義することが必要とされる場合がある。これらのＩ／Ｏバッチパラメーター値は、このプロセス制御システムの内部におけるフィールド装置の１つ以上へ送られるかまたはこれらのフィールド装置の１つ以上から受けられる入力値および出力値に関連付けられてもよく、または代わりに、バッチの実行の間にこのプロセス制御システムによって生成された中間値または計算値であってもよい。従って、バッチを定義するときに、ユーザー（例えばオペレーター）は典型的には、グラフィカルインターフェイスを使用して基本的な製品レシピ（上記レシピの上記処理ステップをプロセス制御設備へ結び付ける規格を含んでいる）を選択し、かつ、そのバッチの実行の間に使用されるパラメーター値を指定する。例えば、塗料のバッチを生成する制御システムでは、ユーザー（例えばオペレーター）は、例えば半光沢性外装用水性塗料のような基本的塗料レシピを選択するために上記グラフィカルインターフェイスとのやりとりをしてもよく、また、特定色の半光沢性外装用水性塗料における１００ガロンのバッチの生成がもたらされるパラメーター値を指定してもよい。

一例として、基本的塗料レシピには、基本的な塗料混合物へ着色剤または他の物質を添加する１つ以上の処理ステップが含まれていてもよく、また、これらの着色剤または他の物質をその基本的な塗料混合物の中へ機械的に混合する付加的な処理ステップがさらに含まれていてもよい。これらの混合処理（mixing, blending）ステップ、または上記基本的塗料レシピに関連付けられた他のあらゆる処理ステップをこのプロセス制御システムの内部における特定の設備の特定部分へ結び付けることができる。例えば、第１混合ステップを第１混合機へ結び付けることができ、また、第２混合ステップを第２混合機へ結び付けることができ、または、代わりに、必要に応じて、その第２混合ステップを上記第１混合機へ代わりに結び付けることができる。同様に、着色剤を上記塗料混合物へ添加するレシピのそれぞれの処理ステップを特定の着色剤分配設備へ結び付けることができる。

さらにまた、バッチを定義するときに、ユーザーは、そのバッチによって特定された処理ステップを実行して所望の最終塗料製品を獲得するために、そのバッチの実行の間にこのプロセス制御システムによって使用される、混合時間、着色剤の量などのようなさまざまなＩ／Ｏパラメーター値を提供することができる。従って、ユーザーは、さまざまな基本的塗料型（基本的レシピによって特定されたような型）が含まれているさまざまな最終塗料製品をさまざまな色（Ｉ／Ｏパラメーター値によって特定されたような色）で作ることができる。従来のバッチ定義技術は、医薬、飲料、食品などのような他の多くの型の製品を作り出すために使用することもできるので、特定の処理ステップ、この処理ステップへ結び付けられた設備およびＩ／Ｏパラメーター値は、このプロセス制御システムによって所望の最終製品が作られるように変更することができる、ことはもちろんである。

近年、バッチラン環境は著しくいっそう複雑なものになってきた。例えば、多くの最新のバッチ処理プラントでは、複数の「設備トレイン（equipment train）」と呼ばれる、特定のバッチランを物理的に行うために必要な作動的に連結された複数のセットの制御設備ユニットを使用して、いくつかの並列なバッチが実行される。レシピは、いっそう長くなり、さらに、すべての手順ステップにおいて複雑さを増している。その一方で、測定装置によって、バッチパラメーターのより良好な測定値がもたらされるようになり、また、これらの測定値は、リアルタイムで、またはほとんどリアルタイムで制御装置およびオペレーターワークステーションへ報告される。具体的に言えば、これらの測定装置は、例えば高すぎる温度、不充分な圧力、または特定化学物質の予想以上に高い濃度のような異常状況を迅速かつ正確に検出することができる。オペレーターは、製品損失を減らすとともに有害な状況を防止するために、これらの状況にできるだけ迅速に対応することを確かに望むのである。その結果、バッチを制御するという仕事がますます複雑になるにもかかわらず、産業界はバッチラン環境からの柔軟性をいっそう要求している。

さらにまた、いくつかの国では、ある製造方法に関連した政府規制における変更にもまた直面している。例えば、米国の食品医薬品局（ＦＤＡ）は最近、いわゆるプロセス分析技術（ＰＡＴ）の唱導に着手した。ＰＡＴの目標は、製造された最終製品に加えて、製造プロセスを制御することである。ＰＡＴの要求に応じるために、製造業者は、対応する製造プロセスの中間ステップでの品質を保証することができるようにしなければならず、また、もちろん、検出された状況に適切かつタイムリーに対応することができるようにしなければならない。従って、最新のバッチラン環境は、経済的理由および法的理由の両方に対して柔軟性があるものでなければならない。

残念なことに、現行のバッチランの技術および方法論は、これらの要求を費用効率的なやり方で満たすには不充分である。バッチ処理プラントで機能を果たす典型的なプロセス制御システムでは、専用データベースの中にレシピ情報が記憶されている。そのデータベースには、すべての製品について、そのレシピの手順構造、レシピパラメーター、そのレシピによって要求された設備ユニットのリスト、および他のレシピ情報が含まれていてもよい「制御レシピ」が記憶されている。オペレーターのコマンドまたは他の所定条件に応じて、このプロセス制御システムは、特定の制御レシピをそのデータベースから検索するとともに、そのレシピを選択された「バッチ監視部（batch executive）」に適用する。このバッチ監視部は、受け入れられたレシピに従って１つ以上のバッチを実行するために対応することのできるサブシステムである。このバッチ監視部は、その制御レシピの変更がすでに作動されているバッチの実行に影響を及ぼさないように、そのレシピの受け入れバージョンのスナップショットを保存する。換言すれば、このバッチ監視部は、最初に受け入れたレシピだけを実行することができ、そのデータベースの中における制御レシピへの潜在的な変更には対応しない。

伝統的に、オペレーターは、バッチ監視部と受け入れることのできるレシピの単一バージョンとがそれらの存続期間にわたって関連付けられることを許容していた。技術および政府規制の最近の急速な変更まで、プラントは１つ以上のバッチを何ヶ月も同じレシピで一度に作動させていた。オペレーターが新しいレシピを適用することは比較的まれであり、新しいレシピの導入は事前に計画されていた。しかしながら、産業界の現在の状況は、何週間または何ヶ月間で完了するようなバッチに対しても、バッチラン環境がレシピの突然かつ頻繁な変更に対応するようになることを要求している。

バッチラン環境の柔軟性を増大させるために、いくつかの試みが近年、行われた。例えば、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ（登録商標） ＤｅｌｔａＶ（登録商標）インターフェイスツールによれば、オペレーターは、Ａｃｔｉｖｅ Ｓｔｅｐ Ｃｈａｎｇｅ機能の一部として、ステップの間における移行を強制することができる。Ｆｏｒｃｅ Ｔｒａｎｓｉｔｉｏｎ機能はレシピの実行過程におけるオペレーターの制御能力を大きく拡張するが、この機能は、そのレシピの実際のステップまたは論理構造にわたる制御権利をオペレーターに与えるものではない。Ａｃｔｉｖｅ Ｓｔｅｐ Ｃｈａｎｇｅによれば、オペレーターはさらに、レシピにおけるあるフェーズ（Phase）の実行を独立型バッチとして開始することができる。しかしながら、この機能のこの態様は、同じようにそのレシピの最初（original）の定義に制限される。さらにまた、手動操作はそのフェーズレベルにおいてだけ可能である。従って、エンジニアまたはオペレーターがバッチ実行部によってすでに実行されているレシピを更新すると、現在の技術では、そのバッチ実行部は、最初のバージョンの実行がそのレシピの適用における変更ポイントをまだ過ぎていなくても、その最初のバージョンの実行が終わるまで、レシピの新しいバージョンを獲得することができない。

プロセス制御システムにおいて作動するバッチラン環境によれば、ユーザーは、作動しているバッチをその作動しているバッチによって実行されるレシピの新しいバージョンに同期化することができる。ユーザーは、ユーザーインターフェイスツールを使用して、そのレシピの旧バージョンを実行するバッチを選択し、その選択されたバッチの実行を中断し、その中断されたバッチの動作をそのレシピの更新されたバージョンで再開する。１つの実施形態では、バッチサブシステムが、ユーザーインターフェイスツールからレシピの新バージョンを受けて、その新バージョンを構成データベースの中に保存し、そのレシピの新バージョンとこのバッチラン環境において現在作動しているバージョンの同じレシピとの間の相違点を自動的に確認する。ユーザーインターフェイスツールからのコマンドを受け取ると、このバッチサブシステムは、そのバッチをそのレシピの新バージョンに自動的に同期化する。

１つの態様では、このバッチサブシステムは要求に応じて再同期化を行う。別の態様では、このバッチサブシステムは、所定条件によって自動再同期化を引き起こすことができる。さらに別の態様では、ユーザーは、ユーザーの認定を要求することなく再同期化を自動的に試みるようにこのバッチサブシステムを構成することができ、または、上記ユーザーインターフェイスツールにより異なるオプションを起動することによって、ユーザーは再同期化を手動操作だけに制限することができる。この場合に、このバッチサブシステムは、新しいバージョンのレシピを認識したとしても、再同期化の前にユーザーから明確なコマンドを受け取る必要がある。

１つの実施形態では、そのバッチサブシステムには、それぞれのバッチ実行部が丁度１つのバッチを実行する１つ以上のバッチ実行部処理、それぞれのバッチ実行部処理の動作を管理するバッチ管理処理、およびレシピの変更を検出するバッチランタイム処理部を含んでいる。それぞれのバッチ実行部は、異なるレシピを実行するように構成されていてもよい。１つの実施形態では、それぞれのバッチ実行部は、ステップ、操作、およびフェーズの間における移行過程（transition）等のイベント情報を永続的な場所に保存する。バッチ管理部は、それぞれのバッチ実行部についての上記イベント情報を上記ユーザーインターフェイスツールへ報告する。別の態様では、バッチ管理部は、上記ユーザーインターフェイスツールからのコマンドを受け取って、バッチ実行部に実行の開始、停止または保持の時点を通知する。

１つの態様では、ユーザーは、現行のレシピの特定要素に対応している単位手順（Unit Procedure）の最初の名称を変更することなくこの特定要素に対して変更を行うことができ、従って、そのレシピにおける最初の上位レベルの論理構造を保持することができる。別の態様では、ユーザーは、上記ユーザーインターフェイスツールを使用して、バッチ実行部によって現在作動しているレシピの論理構造を、条件付きステップの選択を制御する演算子の変更によって更新することができる。例えば、ユーザーは、ＯＲ演算子をＡＮＤ演算子へ変更すること、またはあるレシピ要素を省略することを望むことが考えられる。さらに別の態様では、ユーザーは、付加的なレシピ要素を含んでいるバージョンのレシピで作動中のバッチを再同期化することができる。

１つの実施形態では、ユーザーは、レシピ構成の間にまたは現行のレシピへその後にアクセスすることによって、１つ以上の有効再同期化ポイントを指定する。それぞれの有効再同期化ポイントは、最初のレシピにおいてバッチを安全に停止させるかまたは一時停止させることのできる移行過程である。安全機能として、このバッチサブシステムは、バッチが上記有効再同期化ポイントの１つへ到達するまでユーザーがそのバッチを再同期化することを防止する。別の実施形態では、バッチサブシステムは、上記再同期化ポイントを使用することによって自動再同期化を行う。対応しているモードに構成されている場合には、上記バッチ管理部は、有効再同期化ポイントへ到達したバッチ実行部を自動的に一時停止させるとともに、（上記バッチランタイム処理部が有効なレシピ変更を検出すると）そのレシピの新バージョンをそのバッチ実行部に適用する。

１つの実施形態では、バッチサブシステムは、新しいバージョンのレシピを自動的に検出し、異なるバージョンのレシピの間の相違点を決定し、その新しいレシピ要素または移行過程に関連した情報を上記ユーザーインターフェイスツールへ送信する。いくつかの考えられる実施形態では、バッチサブシステムは、新しいレシピが旧いレシピの新バージョンであるかどうかを決定するために、構成データベースへ最近加えられたレシピへ割り当てられた名称を解析する。上記ユーザーインターフェイスツールは、レシピ要素のリストをユーザーへ視覚的に提示するとともに、ユーザーの注意を同期化のために潜在的に利用することができる新しいレシピ要素へ導く。

別の態様では、バッチサブシステムは、これに加えて、バッチ処理が一時中断した後に上記ユーザーインターフェイスツールから同期化もしくは再起動オプションを受け取る。この同期化オプションまたは再起動オプションは、一時停止したバッチ処理を最初から作動させるか（「コールド（cold）」再起動または同期化のオプション）、または先に一時停止した状況から作動させるか（「ウォーム（warm）」再起動または同期化のオプション）を通知する。さらにまた、同期化オプションまたは再起動オプションは、そのバッチ処理をそのレシピの前のバージョンへ戻すか（「再起動する」）、またはそのレシピの新バージョンを適用させるか（「同期化する」）を指定する。

さて、図１によれば、処理プラント制御ネットワーク１０にはプロセス制御装置１２が含まれており、この制御装置は例えばイーサネット（登録商標）通信結線１５によって多数のワークステーション１４へ連結されている。制御装置１２は、入力／出力（Ｉ／Ｏ）装置（図示略）および通信回線のセットまたはバス１８によって、処理プラント（参照符号１６によって全体が表わされている）の内部における装置または設備へもまた連結されている。制御装置１２は、ほんの一例としてＦｉｓｈｅｒ−Ｒｏｓｅｍｏｕｎｔ（登録商標） Ｓｙｓｔｅｍｓ，Ｉｎｃ．，によって販売されている上記ＤｅｌｔａＶ制御装置であってもよいが、１つ以上のプロセス制御ルーチンを実行し、それによって処理プラント１６の所望の制御を実施するために、処理プラント１６の全体にわたって配置されたフィールド装置やこれらのフィールド装置の内部における機能ブロックのような制御要素と通信することができるものである。これらのプロセス制御ルーチンは、連続的なものであってもよく、またはバッチ式のプロセス制御のルーチンまたは手順であってもよい。ワークステーション１４（例えばパーソナルコンピュータ、サーバーなどであってよい）は、制御装置１２によって実行されるプロセス制御ルーチンを設計し、これらのようなプロセス制御ルーチンをダウンロードするように制御装置１２と通信し、処理プラント１６の作動中に処理プラント１６に関する情報を受け取るとともに表示し、そして、さもなければ、制御装置１２によって実行されたプロセス制御ルーチンとのやりとりをするために、一人以上のエンジニアまたはオペレーターによって使用されてもよい。加えて、データ履歴作成装置１９をＬＡＮ１５へ接続することができ、また、制御装置１２、上記フィールド装置およびワークステーション１４も含まれるプラント５０の内部で生成されたデータを自動的に選択するとともに記憶することができる。

それぞれのワークステーション１４には、構成設計アプリケーションのようなアプリケーションを記憶するための、また、処理プラント１６の構成に関する構成データのようなデータを記憶するためのメモリー２０が含まれている。それぞれのワークステーション１４には、とりわけユーザーがプロセス制御ルーチンを設計することを可能にするとともにこれらのプロセス制御ルーチンを制御装置１２へダウンロードすることを可能にするための上記アプリケーションを実行するプロセッサー２１もまた含まれている。同様に、制御装置１２には、構成データと処理プラント１６を制御するために使用されるプロセス制御ルーチンとを記憶するためのメモリー２２が含まれているとともに、プロセス制御方策を実施するためにプロセス制御ルーチンを実行するプロセッサー２４が含まれている。制御装置１２がＤｅｌｔａＶ制御装置である場合には、この制御装置は、ワークステーション１４の１つにおける１つ以上のアプリケーションと相まって、そのプロセス制御ルーチンの内部における上記制御要素とこれらの制御要素が処理プラント１６の制御を提供するように構成されている方式とを例示する、制御装置１２の内部のプロセス制御ルーチンの図式的描写をユーザーへ提供することができる。

一般的に言えば、図１のプロセス制御システムは、例えばワークステーション１４の１つが処理プラント１６の内部で相異なるバッチランを実施するとともにこれらを調整するバッチ監視部を実行するバッチ処理の実施のために使用することができる。図１に例示された代表的なプロセス制御システムでは、そのようなバッチ監視部３０がワークステーション１４ａの中に存在している。しかしながら、バッチ監視部３０は、他のワークステーション１４の中で、もしくは、バス１５またはバス１８へ無線方式を含む所望の方式によって通信可能に接続された他のコンピュータの中で、記憶され、実行されてもよい。同様に、図３に関していっそう詳しく検討されるように、バッチ監視部３０は、さまざまな構成要素に分けることができ、または、処理プラント１６の内部における相異なるコンピュータまたはワークステーションの中で記憶されかつ実行されるさまざまな構成要素に関連付けることができる。

加えて、処理プラント制御ネットワーク１０には２つ以上のバッチ監視部３０が含まれていてもよい、ということを認識されたい。例えば、最新のプラントでは、処理プラント制御ネットワーク１０のリソースのいくつか、またはすべてを共用する４つまでのバッチ監視部が現在サポートされている。１つ以上のバッチ監視部３０は一般に、バッチサブシステムと呼ばれることがある。これに対して、構成サブシステムは、レシピを定義するとともに編集し、バッチランの遂行を監視し、そして、他の管理目的のために使用される、ユーザーインターフェイスツール、構成データベース、および他のハードウェア、ファームウェア、ならびに、ソフトウェアモジュールを指す。この検討において、「バッチ監視部」および「バッチサブシステム」という用語は交換可能に使用される、ことに留意されたい。

作動において、ユーザーは、レシピを定義し、このレシピを実行するバッチを作成し、かつ、バッチランを制御するために、バッチオペレーターインターフェイス（「ＢＯＩ」）３２を作動させることができる。バッチランの制御に関して具体的に言えば、ＢＯＩ３４によって、ユーザーは、バッチランを起動させ、停止させ、一時停止させ、かつ更新することができる。ＢＯＩ３４は、イーサネット（登録商標）リンク１５によって、無線リンクにわたって、または他のあらゆる公知の方式で、バッチサブシステム３０とのやりとりすることができる。図１はＢＯＩ３４をワークステーション１４の一部として模式的に描写しているが、他の実装および配置もまた同様に可能である。例えば、ＢＯＩ３４は、ワークステーション１４ａや、携帯機器（図示略）や、または処理プラント制御ネットワーク１０の外側に配置されたホストコンピュータにおいて、実行することもできる。さらに、多数のオペレーターを同時にサポートする処理プラント制御ネットワーク１０におけるさまざまなホストコンピュータに実体化されたＢＯＩ３４のいくつかの実体例がある。またさらに、処理プラント制御ネットワーク１０によれば、レシピ構成およびバッチ動作にアクセスするための２つ以上のユーザーインターフェイス手段が提供される、ということを認識されたい。１つの例を挙げると、上記ＤｅｌｔａＶシステムによれば、とりわけＤｅｌｔａＶ ＯｐｅｒａｔｅおよびＤｅｌｔａＶ Ｂａｔｃｈ Ｏｐｅｒａｔｏｒ Ｉｎｔｅｒｆａｃｅのような構成要素によってユーザーインターフェイスが提供される。

再び図１によれば、構成（configuration）データベース３４には、バッチサブシステム３０のためのレシピ、このプラントにおける設備ユニットおよび設備階層のリストのような設備データ、このプラントのさまざまな区域、設備ユニットのプラント区域との関連性、設備の階層的機能停止に関連した管理情報、および他の構成データを記憶することができる。この構成データベース３４は、バッチサブシステム３０から離れた構成サブシステムの中に存在していてもよい。また、構成データベース３４は、別のサーバーまたは一群のサーバーであってもよいこと、または処理プラント制御ネットワーク１０が充分に小さい場合には、構成データベース３４は、ワークステーション１４または１４ａのファイルシステムの専用プロセス供給部として簡単に実施することができる、ことに留意されたい。

図１に例示された処理プラント制御ネットワーク１０の例では、制御装置１２は、バス１８によって、同じように構成された２セットの設備へ通信可能に接続されており、それぞれの設備セットは、本明細書ではREACTOR＿０１（反応装置１、R1）またはREACTOR＿０２（反応装置２、R2）と呼ばれる反応ユニット、本明細書ではFILTER＿０１（フィルター１、F1）またはFILTER＿０２（フィルター２、F2）と呼ばれるフィルターユニット、および本明細書ではDRYER＿０１（乾燥装置１、D1）またはDRYER＿０２（乾燥装置２、D2）と呼ばれる乾燥ユニットを有している。REACTOR＿０１には、反応容器１００と、例えばヘッドタンク（図示略）から反応容器１００の中へ流体を供給する流体入口管路を制御するように接続された２つの入力バルブ１０１および１０２と、出口流体管路によって反応容器１００の外側への流体の流れを制御するように接続された出力バルブ１０３とが含まれている。温度センサー、圧力センサー、流体レベルメーターなどのようなセンサーであってよい装置１０５、または電気ヒーターまたは蒸気ヒーターのような何らかの他の設備が、反応容器１００の中にまたは近傍に配置されている。REACTOR＿０１は、バルブ１０３を介して、フィルター設備１１０が備わっているFILTER＿０１へ、次いで、乾燥設備１２０が備わっているDRYER＿０１へ連結されている。同様に、第２セットの設備には、反応容器２００と、２つの入力バルブ２０１および２０２と、出力バルブ２０３と、装置２０５とが備わっているREACTOR＿０２が含まれている。REACTOR＿０２は、フィルター設備２１０が備わっているFILTER＿０２へ、次いで、乾燥設備２２０が備わっているDRYER＿０２へ連結されている。フィルター設備１１０および２１０と乾燥設備１２０および２２０とには、これらに関連付けられた付加的な制御要素（ヒーター、コンベアベルトなど）、センサーなどが備わっていてもよい。必要であれば、反応装置、フィルターおよび乾燥装置のそれぞれの１つを使用するバッチランが図１に例示された設備の任意の組み合わせを使用することができるようにするためには、図示されていないが、それぞれのフィルターユニットであるFILTER＿０１およびFILTER＿０２は、それぞれの反応ユニットであるREACTOR＿０１およびREACTOR＿０２へ物理的に連結することができ、一方、それぞれの乾燥ユニットであるDRYER＿０１およびDRYER＿０２は、それぞれのフィルターユニットであるFILTER＿０１およびFILTER＿０２に連結することができる。

図１に例示されたように、制御装置１２は、バス１８を介して、バルブ１０１〜１０３，２０１〜２０３と、装置１０５，２０５と、フィルター１１０，２１０と、および、乾燥装置１２０、２２０とへ（さらに、これらに関連付けられた他の設備へ）通信可能に連結されており、これらの要素（ユニット、フィールド装置などであってよい）に関する一つ以上の動作を管理する。このような動作には、例えば、上記の反応容器または乾燥装置を充填すること、その反応容器または乾燥装置の内部における物質を加熱すること、その反応容器または乾燥装置の中身を放出すること、その反応容器または乾燥装置を洗浄すること、上記フィルターを作動させることなどが含まれていてもよい。当然のことながら、制御装置１２は、付加的なバスを介して、４〜２０ミリアンペア回線やＨＡＲＴ通信回線などのような専用通信回線を介して、処理プラント１６の内部における諸要素へ連結されていてもよい。

図１に例示されたバルブ、センサーおよび他の設備は、例えば、フィールドバスフィールド装置、標準的な４〜２０ミリアンペアフィールド装置、ＨＡＲＴフィールド装置などが含まれるあらゆる所望の種類または型の設備であってもよく、また、フィールドバスプロトコル、ＨＡＲＴプロトコル、４〜２０ミリアンペアアナログプロトコルなどのような、あらゆる公知のまたは所望の通信プロトコルを使用して、制御装置１２と通信してもよい。またさらに、他の型の装置が、接続されていてもよく、所望の方式で制御装置１２によって制御されてもよい。さらに、他の装置または処理プラント１６に関連付けられた区域を制御するために、他の制御装置が、例えばイーサネット（登録商標）通信回線１５を介して制御装置１２へかつワークステーション１４へ接続されていてもよく、また、このような付加的制御装置の動作は、図１に例示された制御装置１２の動作とあらゆる所望のまたは公知の方式で連動させてもよい。

ユーザーは、レシピを設定し、装置バルブ１０１〜１０２および容器１００などのプロセス制御設備から設備トレインを形成し、この設備トレインをバッチに関連付け、また、ＢＯＩ３４または他のインターフェイスツールを介してバッチサブシステム３０とやりとりをすることができる。ＢＯＩ３４は、定期的にまたはリアルタイムで、そのシステムの中で実行されているそれぞれのバッチの状況情報を取り出すことができる。このネットワーク１０のバッチラン環境、とりわけＢＯＩ３４および構成データベース３４と相まって機能するバッチサブシステム３０によれば、ユーザーは、実行中のバッチを選択し、そのバッチを一時的に停止させ、そのバッチによって実行されるレシピを検分し、かつ、レシピ要素に「穴を開ける（drilling into)」ことによって、上位レベルにおいて、または下層の１つにおいてのいずれかで、そのレシピの変更を行うことができる。ユーザーはその後、更新されたレシピを構成データベース３４に保存することができるとともに、バッチサブシステム３０に対して一時停止されたバッチを、選択された再同期化オプションの１つによるレシピの新バージョンで再同期化することができる。新しいバージョンのレシピを実行中の上記バッチに同期化することと実行することとに関するモジュールおよび方法は、図３〜１１を参照して以下で詳しく検討される。

バッチサブシステム３０には、ユーザーがこの処理プラントの内部で行なわれるいくつかのバッチランを指定することを可能にし、いくつかの異なったバッチランまたはバッチ処理がこの処理プラント制御ネットワーク１０の内部で上記の相異なるバッチランを実施するために基本的に独立して作動するように設定する、上位レベルの制御ルーチンが含まれている。このようなバッチ処理のそれぞれは、反応ユニット、フィルターユニット、乾燥ユニットまたはこの処理プラントの内部における他の設備のうちの１つの単一ユニットを操作するサブルーチンまたは処理である、１つ以上の単位手順の動作を導く。それぞれの単位手順（一般にワークステーション１４の１つにおいて実行されるバッチランの一部である）は、一連の操作を行い、これらの各々はあるユニットにおいて１つ以上のフェーズを行ってもよい。上記説明において、あるフェーズは、あるユニットにおいて行われる最も下位レベルにおいての動作またはステップであり、また、典型的には制御装置１２の１つにおいて実施されるかまたは実行され、ある操作は、そのユニットにおいて特定の機能を行うフェーズのセットであり、典型的には制御装置１２の内部でフェーズのセットを呼び出すことによってワークステーション１４の１つにおいて実施されるかまたは実行され、一方、ある単位手順は、ある単一ユニットにおいて行われた１つ以上の操作のセットであり、また、典型的にはワークステーション１４の１つにおいて呼び出される操作のセットとして実施される。その結果、任意の単位手順には、１つ以上のフェーズおよび／または１つ以上の操作が含まれている。このように、それぞれのバッチ処理は、食品、薬品などのような製品を作るために必要とされる相異なるステップまたはステージ（すなわち単位手順）を実行する。

個々のバッチについて相異なる単位手順、操作およびフェーズを実施するために、バッチ処理では、行うべき諸ステップ及びこれらのステップに関連付けられた量および時間、ならびにこれらのステップの順序を指定する一般にレシピと呼ばれているものを使用する。１つのレシピについてのステップには、例えば、反応容器を適切な物質または材料で満たし、その反応容器の内部でその物質を混合し、その反応容器の内部でその物質をある温度まである時間だけ加熱し、その反応容器を空にし、その後、次のバッチのためにその反応容器を洗浄し、反応容器の産出物を濾過するためにフィルターを作動させ、その後、その反応容器の中で作り出された生成物を乾燥するために乾燥装置を作動させること等が含まれていてもよい。異なったユニットに関連付けられた一連のステップのそれぞれは、そのバッチの単位手順を定義しており、また、そのバッチ処理はこれらの単位手順におけるそれぞれの１つについての異なった制御アルゴリズムを実行する。当然のことながら、上記の特定の物質、これらの物質の量、加熱の温度および時間などは、相異なるレシピについて異なっていてもよく、従って、これらのパラメーターは、製造されまたは生成される生成物および使用されるレシピに左右されるため、バッチランごとに変更されてもよい。制御ルーチンおよび構成が、図１に例示された上記反応ユニット、上記フィルターユニットおよび上記乾燥ユニットを使用するバッチについて本明細書の中に説明されている一方で、他の所望の装置を制御して、他の任意の所望バッチ処理実行を行ったり、望まれる場合には連続的なプロセスプラント実行を行ったりするために、制御ルーチンを使用してもよいことを当業者は理解されよう。

さらに、一般的なバッチ処理における同一のフェーズ、操作または単位手順は、図１の相異なる反応ユニットのそれぞれについて、相異なる実際のバッチ処理の一部として同時にまたは異なった時点で実施してもよいことを当業者は理解されよう。さらにまた、図１の反応ユニットには一般に、同一の数および型の設備（すなわち、これらは同一のユニット部類に属している）が含まれるので、特定のフェーズについての同一の一般的なフェーズ制御ルーチンを使用して、相異なる反応ユニットのそれぞれを制御することができるが、ただし、この一般的なフェーズ制御ルーチンは、相異なる反応ユニットに関連付けられた、異なるハードウェアまたは設備を制御するためには、修正しなければならない。例えば、REACTOR＿０１についての（ここでは反応ユニットが満たすための）充填フェーズを実施するためには、１つ以上の入力バルブ１０１または１０２が、ある時間だけ、例えば上記容器１００が満たされていることを上記流体レベルメーター１０５が感知するまで、充填制御ルーチンによって開放される。しかしながら、この同一の制御ルーチンは、入力バルブの指定をバルブ１０１または１０２に代えてバルブ２０１または２０２へ変更し、かつ、流体レベルメーターの指定を流体レベルメーター１０５に代えて流体レベルメーター２０５へ変更することだけで、REACTOR＿０２についての充填フェーズをも実施するために使用することができる。

バッチランの一般的動作に関連付けられた論理構造は周知であるが、図２は、あるバッチラン環境におけるオンライン式レシピ同期化方法に関するレシピ構成の概略図を提供する。レシピ２５５はＳ８８規格の階層構造に準拠している。しかしながら、このオンライン式レシピ同期化方法は、現在のかつ将来の他のレシピ定義規格に適用することもできることを当業者は認識されよう。図２に例示されたように、レシピ２５５には、ステップ２５３およびステップ２５５のような、移行過程２５７によって分離された１つ以上のステップが含まれている。レシピ２５５のそれぞれのステップは、複雑な内部構成を有していてもよく、また、分離された単位手順として定義されてもよい。例えば、ステップ２５５は単位手順２６０として定義されてもよい。

移行過程２５７は、移行過程２５７の次に来るステップ（この場合にはステップ２５５）を行う前に、ステップ２５３の内部において満たされなくてはならない条件を指定することができる。例えば、ステップ２５３が２つの化学物質の混合を行う場合、条件２５７によってその混合が２分の制限時間を超えたかどうかを検査することができる。別の例として、実行中のステップ２５３の結果にかかわりなく移行過程に影響を及ぼすために、移行過程２５７のブール値（Ｂｏｏｌｅａｎ）を「真」であるように設定することができる。一般に、これらの条件は、簡単なものであっても複雑なものであってもよく、また、ANDおよびORのようなブール演算子を含んでいてもよい。単位手順２６０にはまた、同じように条件２５７によって分離された１つ以上の操作２６３または２６５が含まれていてもよい。図２に例示された例では、操作２６１は操作定義２７０によって実施される。操作定義２７０には、条件２５７によって分離された１つ以上のフェーズ２７２および２７４が含まれていてもよい。

ユーザーは、１つ以上のワークステーション１４または１４ａにおいて、レシピ２５０のようなレシピのための専用ソフトウェアを作成することができる。いくつかの実施形態では、このソフトウェア作成用ソフトウェアはＢＯＩ３２の一部として設けられている。このようなソフトウェアパッケージの１つは、上記ＤｅｌｔａＶシステムの一部として設けられたＲｅｃｉｐｅ Ｓｔｕｄｉｏである。名称をレシピ２５０へ割り当てるのに加えて、ユーザーはそのレシピをあるバージョンに関連付けることができる。言い換えれば、ユーザーは、レシピ２５０の最初のバージョンを作成し、そのレシピ２５０に「Ｃｈｏｃｏｌａｔｅ＿Ｃｏｏｋｉｅ＿００１」という名称を割り当て、そして、そのレシピ２５０にバージョン識別子「ｖ１」を関連付けることができる。その後、ユーザーは、同じレシピ２５０の別のバージョンを作成するとともに、その新しいバージョンに例えばバージョン識別子「ｖ２」を関連付けることができる。１つの実施形態では、構成データベース３４には、同じ名称であるが異なったバージョン識別子のある２つのレシピが含まれていてもよい。別の実施形態では、ユーザーは、その新しいバージョンを前のバージョンと同じ名称で簡単に保存することができる。

いずれの場合にも、新しいバージョンのレシピは常に、ユーザーインターフェイス３２から、またはバッチサブシステム３０を介する構成データベース３４での他のレシピ作成ツールからもたらされる。言い換えれば、バッチシステム３０は、既存のバージョンのレシピの変更を常に知っておくために、ユーザーと構成データベース３４との間でレシピ情報を受け渡しする。このようにして、バッチシステム３０は、その新しいバージョンのレシピを必要な場合にはサブシステム３０の内部で実行されるバッチと同期化することができる。別の実施形態では、ユーザーインターフェイス３２は構成データベース３４と直接やりとりをする。レシピ再同期化の少なくともいくつかの態様を自動化するために（以下でいっそう詳しく検討されるように）、ユーザーインターフェイス３２または構成データベース３４には、バッチサブシステム３０のためのレシピ情報を複製するソフトウェアルーチンが含まれている。さらに別の代案として、ユーザーインターフェイス３２は構成データベース３４と直接やりとりをするとともに、バッチシステム３０は構成データベース３４からの更新を定期的に要求する。例えば、バッチシステム３０は、このバッチシステム３０によって実行されているそれらのレシピの新しいバージョンが最後の問い合わせ時以降、構成データベース３４で利用可能なものになったかどうかを問い合わせるために、所定のタイムアウト値に従って注意喚起するバックグラウンド処理を実行することができる。しかしながら、バッチシステム３０を上記ユーザーインターフェイスツールと構成データベース３４との間に置くことによってバッチラン環境をいっそう効率的に実施することができる、ということを当業者は認識されよう。

図３は、処理プラント制御ネットワーク１０におけるバッチサブシステム３０の代表的アーキテクチャーを例示している。このバッチ監視サブシステム３０は、イーサネット（登録商標）通信結線１５によってまたは、このバッチサブシステム３０が同じワークステーション１４または１４ａに存在している場合には公知のプロセス間通信（ＩＰＣ）手段によって、ＢＯＩ３０のようなユーザーインターフェイスツールとのやりとりをすることができる。バッチサブシステム３０には、バッチ管理部２８２、バッチランタイム処理部２８４、および１つ以上のバッチ実行部２８６〜２９０が含まれていてもよい。バッチサブシステム３０のそれぞれの構成要素は、独立したプロセスまたはスレッドとして実施することができる。上で示されたように、バッチサブシステム３０は、いくつかのワークステーションまたは他のホストコンピュータにわたって配置することができる。

それぞれのバッチ実行部２８６〜２９０は１つのバッチを正確に実行する。いくつかのバッチ実行部２８６〜２９０は、例えばレシピ２５０のような同じレシピを実行することができる。これらのバッチ実行部２８６〜２９０は、たとえそれぞれのバッチ実行部が同じレシピを実行する場合でも常に同じ実行の状況にある必要はない、ということを認識されたい。図３に例示された例では、バッチ実行部２９０は、イーサネット（登録商標）結線１５によって制御装置１２へ接続されている。操作において、バッチ実行部２９０は、対応するワークステーション１４または１４ａの処理スペースにおける単位手順および操作のレベルにおける論理構造を実行することができる。しかしながら、バッチ実行部２９０は、それぞれの操作のフェーズ２７２および２７４を制御装置１２の中へロードする。

再び図３によれば、永続的記憶ユニット２９２が、バッチ実行部２８６〜２９０のそれぞれに関連した状態情報、移行過程情報、およびパラメーター情報を保有するができる。この永続的記憶部２９２は、ワークステーション１４または１４ａの１つのハードディスク、ＣＤまたはＤＶＤのような外部記憶装置、または他の公知のデータ記憶装置であってよい。バッチ管理部２８２、バッチランタイム処理部２８４、およびそれぞれのバッチ実行部２８６〜２９０は、永続的記憶部２９２が同じホストコンピュータに存在している場合には、イーサネット（登録商標）１５によって、またはＩＰＣ呼び出しを通して、永続的記憶部２９２へアクセスすることができる。操作において、それぞれのバッチ実行部２８６〜２９０は、対応するバッチの実行状況に関連した情報を保存する。例えば、バッチ実行部２９０は、現在実行されている単位手順、操作、およびフェーズの状況を記録することができる。従って、永続的記憶ユニット２９２における記録は、ある点で、バッチ実行部２９０がレシピ２５０のステップ３、操作１、フェーズ２を現在実行していることを示すことができる。加えて、この記録は、例えばＲＵＮＮＩＮＧ（実行中）、ＨＥＬＤ（一時停止中）、またはＡＢＯＲＴＥＤ（中止）のようなそれぞれのレベルの状態を指定することができる。さらに、バッチ実行部２９０は、単位手順、操作、およびフェーズの中へ渡ったパラメーターの値を記録することができる。バッチ実行部２９０は、永続的記憶ユニット２９２を実質的にリアルタイムで更新するのが好ましい。

加えて、バッチ実行部２９０は例えば、ステップ２５３とステップ２５５との間、操作２６３と操作２６５との間、およびフェーズ２７２とフェーズ２７４との間におけるそれぞれの移行過程２５７を記録することができる。この移行過程は、状態情報およびパラメーター情報とともに、永続的記憶部２９２に記録することができる。代わりに、状態の移行過程は、データ履歴作成装置１９に記憶された別のイベントログとして記録することができる。イベントログには、上記パラメーター情報のいくつかまたはすべてと、それぞれの移行過程のタイムスタンプ、エラー条件、および事後においてシステムを監視、またはデバッグするために有用な他の情報等の付加情報が含まれていてもよい。上記イベントログには、同期化指示が同様に記憶されていてもよい。例えば、上記イベントログにおけるある記録は、９月２１日の午後である１４：２５にステップ３、動作１、フェーズ１において、レシピ「Ｃｈｏｃｏｌａｔｅ＿Ｃｏｏｋｉｅ＿００１」のバージョンｖ２で再同期化されたバッチ実行部２９０を示してもよい。

上で示されたように、バッチ管理部２８２はバッチ実行部２８６〜２９０の実行を制御する。具体的には、バッチ管理部２８２は、これらのバッチ実行部２８６〜２９０へ実行の起動時、停止時、または一時停止時を示す指示を送信する。加えて、バッチ管理部２８２は、それぞれのバッチ実行部２８６〜２９０の状態をユーザーインターフェイスツール２８０によってオペレーターへ報告する。例えば、バッチ管理部２８２は、バッチ実行部２９０の状態を検索するために永続的記憶部２９２へアクセスするとともに、その状態を、ＸＭＬのような周知のフォーマットまたはバッチサブシステム３０の要素の間におけるやりとりのために特に定義された特定目的のフォーマットに従ったメッセージ形式でインターフェイスツール２８０へ報告する。この意味で、バッチ管理部２８２は、すべてのバッチ実行部への集中型ゲートウェイとして作用する。

１つの実施形態では、バッチ管理部２８２およびバッチ実行部２８６〜２９０は、バッチサブシステム３０によって現在実行されているレシピのコピーを記憶する共用メモリー領域へのアクセスをさらに有している。この共用メモリー領域は、永続的または一時的なメモリー場所であってもよく、また、バッチサブシステム３０の内部または外部に配置されていてもよい。いくつかの実施形態では、バッチ管理部３０は、バッチ実行部２８６〜２９０の１つによってそれぞれのレシピのランを起動させる前にそれぞれのレシピのコピーを保存する。別の実施形態では、個々のバッチ実行部は、それ自体の処理スペースに、または知られていないかまたはバッチサブシステム３０の残り部分へアクセスすることのできない恒久的場所に、そのレシピのコピーを保存する。いずれの場合にも、バッチサブシステム３０は、それぞれのレシピを単一ファイルとしてまたは要素の階層的構造として、記憶することができる。好ましいのは、バッチ管理部２８２とそれぞれのバッチ実行部２８６〜２９０とが、単位手順、操作およびフェーズのような個々のレシピ要素へ読み取りおよび書き込むためのアクセス手段を有していることである。

ところで、バッチランタイム処理部２８４は、処理プラント制御ネットワーク１０の残り部分に関するインターフェイスとして作用する。具体的には、バッチランタイム処理部２８４は、レシピダウンロードスクリプトによって構成データベース３４とのやりとりをすることができる。 １つの実施形態では、ユーザーインターフェイス３２は、人間および機械の双方が読みやすくなるようにするために、それらのレシピをＸＭＬの中にひとまとめにする。 代わりに、ユーザーインターフェイス３２、バッチサブシステム３０、および構成データベース３４は、スクリプト情報を任意の標準プロトコルまたは専用プロトコルを介して送ることができる。また、バッチランタイム処理部２８４は、システムのセキュリティおよびログのメンテナンスのような機能を担っていてもよい。 さらにまた、バッチランタイム処理部２８４は、起動情報、停止情報、および永続的記憶部２９２の中かまたは構成データベース３４の中における他の上位レベルの関連情報を記録することができる。

さらに、バッチランタイム処理部２８４は、同じレシピの若いバージョンに関連した特定のレシピの変更を識別することができる。例えば、ミキサーが実行すべき時間の量のようなある動作における単一の小さいパラメーターが、２５分から３０分に変更されるとする。レシピの新しい３０分バージョンを受け取ると、バッチランタイム処理部２８４は、バッチ管理部２８２へ、いずれかのバッチ実行部２８６〜２９０が同じレシピの旧バージョンを現在実行しているかどうかをチェックするように、照会をまず送信する。１つの実施形態では、バッチランタイム処理部２８４およびバッチ管理部２８６は、それらのレシピの名称を単純に比較することによって、その新しいレシピがバッチサブシステム３０の中で現在実行されているかどうかを決定することができる。この目的のために、バッチ管理部２８６は、作動中のそれぞれのバッチ実行部についてのレシピの名称または他の固有の識別子を記憶してもよい。バッチランタイム処理部２８４からの上記照会への応答において、バッチ管理部２８６は、例えばそのレシピが作動中のバッチ実行部２８６〜２９０の１つ以上に適用することのできるものであることを指示することができる。バッチランタイム処理部２８４はその後、構成データベース３４から最初のレシピを検索するとともに、新しいレシピと旧いレシピとの間の比較を行う。代わりに、ユーザーインターフェイス３２は、ユーザーによって行われた変更を識別するレシピの「印が付けられた」コピーを生成するとともに伝搬することができる。

上記のように、レシピの更新は、ユーザーによって行われた変更の程度に左右され、いくつかのカテゴリーの１つに分類することができる。図４は、単位手順の名称が変更されることなくその単位手順の内部に修正を含む代表的な更新シナリオを例示している。このシナリオは、最初の操作名称を保持しながら個々の操作の内部に修正が行われる事例に類似していることを認識されたい。図４に例示されるように、レシピ３００の新しいバージョンおよび旧いバージョンには、ステップ３０２に移行過程３０４が続き、そしてステップ３０６が続くようにそれらが含まれている。しかしながら、ユーザーは、ステップ３１０に対応する上記単位手順を更新することができ、また、対応するバッチがいったん移行過程３０８へ達すると、ステップ３１０の代わりにステップ３１２を実行するようにサブシステム３０へ要求することができる。ステップ３１２は、実行された単位手順のそのバージョンにおいてだけ、ステップ３１０と異なっている。

このバッチラン環境の、そして具体的にはバッチサブシステム３０のいくつかの実施形態では、ユーザーは、新しいバージョンのレシピまたはレシピ要素を同じ名称で保存することを避けることを望む場合がある。いくつかの事例では、ユーザーは、方針として、存在しているレシピまたは手順名称を重複させることができない。この状況および類似した状況においては、ユーザーインターフェイス３２は、ＵＰＲＯＣ＿ＭＩＸ＿ＩＮＧＲＥＤＩＥＮＴＳ＿０１２＿Ｖ０１と名付けられた前のバージョンからレシピ３００の新しいバージョンを区別するために、ＵＰＲＯＣ＿ＭＩＸ＿ＩＮＧＲＥＤＩＥＮＴＳ＿０１２＿Ｖ０２のような単位手順の新しい名称を自動的に生成してもよい。この名称は、マシンスクリプトがその名称を容易に解析してそのバージョン番号および他の識別子を引き出すことができるようなものである。

ところで、図５に例示されたシナリオには、レシピ３２０への新しいレシピ要素の追加が含まれている。具体的には、レシピ３２０の新しいバージョンでは、ステップ３２２に新しいステップ３２４および移行過程３２６が続くことが必要とされる。移行過程３２６はレシピ３２０のフローを元のステップ３２８へ導き戻す。図５に例示されたシナリオは、存在しているバッチの範囲内でフェーズを手動で実行するものとは異なっていることを認識されたい。具体的には、新しいステップ３２４はＳ８８準拠型移行過程によって、現在のステップ３２２および３２８へ接続されている。言い換えれば、ユーザーは、新しいレシピ要素を追加した後に移行過程を手動で制御する必要がない。さらにまた、手順ステップ３２４は、レシピ３２０の一部になり、その結果、新しいステップ３２４からのイベントは、レシピ３２０を実行するバッチの一部として収集することができる。

図６によれば、レシピ３５０の新しいバージョンには、ステップ３５２に続くレシピ論理構造の変更が含まれている。具体的には、レシピ３５０の新しいバージョンに従って、条件３５４（OR）は条件３５６（AND）に変更される。このシナリオでは、レシピ３５０の単位手順はまったく変更されなくてもよい。それにもかかわらず、ユーザーは、例えば、レシピ３５０の前のバージョンに従ってチョコレートおよびバニラの一方を選択する代わりに、チョコレート（ステップ３６０）およびバニラ（ステップ３６２）の両方を追加するよう試みることを決定することができる。

図４〜図６による上記のシナリオにおいては、バッチ実行部２８６〜２９０の１つがレシピ３００、３２０または３５０の前のバージョンを現在実行しているかもしれないため、サブシステム３０は、これらのレシピを永続的なまたは一時的なメモリーの中に保持してもよい。１つの実施形態では、バッチランタイム処理部２８４は、更新されたレシピ３００，３２０または３５０の名称もしくは固有の識別子をさらに加えて、上記単位手順または操作レベルに関してレシピ３００の中で更新された特定要素のリストを、バッチ管理部２８２に通知することができる。バッチ管理部２８２は、バッチランがレシピ３００を実行するバッチ実行部２８６へ、例えば移行過程３０８へ到達するときにそのバッチランが一時停止されなければならないことを指示することができる。バッチ管理部２８２はその後、レシピ３００の全体のコピーかまたは、バッチサブシステム３０の中に保存されたステップ３１０に対応する単位手順のコピーのいずれかを更新することができる。

しかしながら、バッチ管理部２８２は、レシピ３００の新しいバージョンが利用可能なものであり、差がバッチランタイム処理部２８４によって処理されたことを通知されたときに、レシピ３００を実行しているバッチ実行部２８６〜２９０のそれぞれを必ずしも常に同期化する必要がない。重要なことは、ユーザーが、どのバッチ実行部２８６〜２９０を新しいバージョンのレシピで同期化すべきか、もしくは、どのバッチ実行部が、最初のレシピを完了するか、新しい中止コマンドを受けるか、またはユーザーから一時停止コマンドを受け取るまで引き続いて実行すべきかを選択することができる点である。この点で、この処理プラント制御ネットワーク１０の構成サブシステムと相まってバッチサブシステム３０により支援されたオンラインレシピ再同期化によって、ユーザーは、その新しいバージョンのレシピをバッチサブシステム３０の全体または処理プラント１６の全体にその新しいバージョンのレシピを適合させる前に、その新しいバージョンのレシピを制御された規模で「試してみる」ことができる。

図７は、このような予想された１つのシナリオをいっそう詳しく例示している。この例では、ユーザーは、ＢＯＩ３２のようなユーザーインターフェイスソフトウェアを作動させて、あるレシピの第１バージョンを作成する（ブロック３８０）。この時点で、ユーザーは、このレシピの第１バージョンで２つの並行なバッチを実行するように計画してもよい。ユーザーインターフェイス３２は、バッチランタイム処理部２８４によってレシピをバッチサブシステム３０へ送る。このレシピを構成データベース３４に保存するのに加えて、バッチランタイム処理部２８４は、このレシピの第１バージョンをバッチ管理部２８２へ送り、次いで、このレシピを利用可能なバッチ実行部２８６および２８８に適用する（ステップ３８２）。このレシピは、ブロック３８４および３８６において、それぞれバッチ実行部２８６および２８８へロードされる。

次いで、バッチ管理部２８２は、バッチ実行部２８６および２８８におけるそのレシピの実行を起動させることができる。ブロック３８８においてバッチ実行部２８６はそのレシピのいくつかのステップにおける実行を起動させることができ、また、バッチ実行部２８８はブロック３９０においてバッチの実行を同様に開始させることができる。ところで、ユーザーは、このレシピを最初のバージョンにおける比較的小さい１つ以上の変更によって改善できると決定したとする。このために、ユーザーは、ブロック３９２においてこのレシピの新しいバージョンを作成することができる。さらにまた、ユーザーは、できるだけ速く効果を生じさせるために変更を希望することがある。同時に、ユーザーは、その新しいレシピをバッチサブシステム３０の全体にわたって適用することについて懸念があり、そのレシピを上記バッチのただ１つのものにまず適用するというように慎重に考えることもある。

いくつかの実施形態において、ユーザーは、それぞれのバッチ実行部の正確な状態を知ることができる。他のいくつかの実施形態において、バッチインターフェイス３２は、ユーザーのアクセス権またはプロフィール構成に左右される状態および移行過程に関する情報をユーザーへ選択的に提示することができる。ユーザーは、再同期化がまだ可能であるポイントを過ぎてレシピの実行がすでに進行したかどうかについて常に知っているとは限らないが、それにもかかわらず、ユーザーインターフェイス３２に、最初のレシピ名称で、またはそのバージョンのレシピを正確に反映している名称で、そのレシピの新しいバージョンを保存し、プロンプトにおいてコマンドをタイプするか、またはバッチインターフェイス３２において視覚的なコントロールを操作することによりバッチ実行部２８６を保留状態に置き、そして、バッチ実行部２８６をその新しいバージョンで同期化するようにバッチサブシステム３０に要求するように指示することができる。

代わりに、ユーザーは、ユーザーインターフェイス３２に、その新しいバージョンをバッチサブシステム３０の可能なかぎりの場所において適用するように指示することができる。もちろん、両方の選択肢がバッチサブシステム３０の同じ実施形態において利用可能にされていてもよい。さらにまた、再同期化は、バッチサブシステム３０と自動的にやりとりすることによって、どのバッチ実行部にその新しいレシピが適用されるのかを判断し、その関連バッチ実行部を自動的に保留状態に置くことができる単一の制御手段として提供されている、と考えられる。さらに、ユーザーインターフェイス３２は、確認用（confirmation）ダイアログをユーザーへ表示して、その新しいバージョンのレシピと潜在的に同期化することのできるバッチ処理についてユーザーへ情報を与えることができる。

バッチインターフェイス２８４は、レシピの第１バージョンへのいずれの変更が、バッチ実行部２８６に適用されるかを決定し、また、関連する更新情報をバッチ実行部２８６へ（直接にまたはバッチ管理部２８２を介して）送ってもよい。バッチ実行部２８６は、そのレシピの最初のバージョンを対応するメモリーから削除し、その新しいバージョンを保存し、次に実行されるステップを特定し、実行を再開させることをバッチ実行部２８６に告げるユーザー（図示略）からのコマンドを進行させるために上記ユーザーインターフェイスからの指示を待つことができる（ブロック３９６）。以下で検討されるように、ユーザーは、バッチ実行部２８６が実行を再開させることのできる上記レシピにおける特定のステップに関するバッチサブシステム３０への付加的指示をもたらすことができる。バッチ実行部２８６は、同期化が成功した場合は、引き続いてその実行をすることができる。しかしながら、ユーザーは、そのレシピの最初のバージョンを誤ったやり方でまたは違法（illegal）なやり方で変更する可能性がある。無効な移行過程、ステップの欠落、または他の異常な状況に遭遇すると、バッチ実行部２８６は、その状態を例えばＲＥＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮ＿ＦＡＩＬＥＤ（同期化失敗）に変更してもよい。考えられるいくつかの実施形態では、バッチ実行部２８６は、そのレシピの前の（安定した）バージョンへ自動的に戻すことができる。別の実施形態においてまたは別の構成の選択肢に従って、バッチ実行部２８６は、時には、「コールド再同期化」を試みる、つまり、第１ステップからその新しいレシピを起動させる。

ブロック３９８および４００において、バッチ実行部２８６および２８８はそれぞれのバッチを実行することができる。ユーザーは、ブロック４０２におけるバッチランの結果を評価することができるとともに、バッチ実行部２８６が、最初のバージョンのレシピへ戻すかまたはそのレシピの新しいバージョンをバッチ実行部２８８へ同様に適用するかについて、決定することができる。具体例として、バッチ実行部２８６は、そのレシピの検査されていない新バージョンを充分に実行することに失敗するかもしれない。この場合には、バッチサブシステムは、そのバッチの状態をＨＥＬＤ（一時停止中）にまたは実行が停止していることを示す同様の状態に自動的に変更することができる。ユーザーインターフェイス３２は次いで、質問「前のバージョンへ戻す（revert）？ はい／いいえ？」を表示するダイアログを生成してもよい。

図８は、バッチサブシステム３０にわたって配置された再同期化手順４２０とユーザーインターフェイス３２のような構成サブシステムの一部とを例示している代表的なフローチャートである。ブロック４２２において、ユーザーは、構成データベース３４からレシピを検索するとともにそのレシピの新しいバージョンを作成することができる。ブロック４２４において、ＢＯＩ３２は、現在作動中のバッチのリスト、それぞれバッチの状態、および作動中のそれぞれのバッチについてのレシピ情報を表示することができる。ユーザーは、ブロック４２６において１つのバッチを選択するとともに、そのバッチの作動状態をブロック４３０においてＳＴＯＰＰＥＤ（停止中）またはＡＢＯＲＴＥＤ（中止）に変更することができる。図８に例示された例では、ユーザーは、ブロック４２２の中で更新されたレシピの旧い方のバージョンを実行するバッチを選択する。

ユーザーは、ブロック４３２で、そのレシピの最初のバージョンを引き続いて実行するかまたは新しいバージョンを起動させるかどうかについて選択することができる。ユーザーが一時停止されたバッチを再同期化することを決定すると、手順４２０はブロック４３４へ進行することができる。ブロック４３４において、バッチ管理部２８２は、一時停止されたバッチを実行するバッチ実行部を特定し、その特定されたバッチ実行部にレシピ更新を適用することができる。先に検討されたように、ステップ４３４にも、構成データベース３４の中でその新しいバージョンのレシピを保存し、バッチランタイム処理部２８４の中でそのレシピの旧いバージョンと新しいバージョンとを比較し、および変更に関連した必要な情報をバッチ管理部２８２へ送信することが含まれていてもよい。

ブロック４３６において、ユーザーはコールド再起動とウォーム再起動との選択肢の間で選択することができる。具体的には、コールド再起動によると、そのレシピの第１ステップから始動するバッチランが結果的にもたらされる。これに対して、ウォーム再起動によれば、そのバッチは、そのレシピの現在のステップから再開することができる。ユーザーは、その新しいバージョンが最初のレシピと適切に整合して、１つのまたは更新されたステップまたは新しいステップへの移行過程が違反状態をもたらさない場合には、ウォーム再起動の選択肢を選択することができる。図４に戻れば、ユーザーは、上記バッチ実行部について、移行過程３０８の後に途切れることなくステップ３１２へ進むために、ウォーム再起動を選択することができる。このように、手順４２０はレシピをブロック／ステップ４３８において整合させることをまず試みる。ステップ４３８の一部として、手順４２０は、そのバッチが現在実行されているのはレシピのどのステップであるか、またはそのバッチが到達したのはどの移行過程であるかを特定し、そのステップまたは移行過程をその新しいレシピの中に配置し、これらが実際に可能であって許容できるかどうかを決定することができる。

重大な誤りを防止するために、手順４２０は方針として、バッチの作動中のステップにおける変更は違法であると見なしてもよく、作動中のステップにおける再同期化を禁止してもよい。例えば、あるバッチがあるレシピのステップ２／操作１／フェーズ３を現在実行している場合には、その変更がステップ２／操作１の内部で同じフェーズ３に影響を与えるか、またはその変更がステップ２の内部において操作１の名称に影響を与えるかなど、潜在的に異論がある状況において、手順４２０は、そのバッチがレシピの新しいバージョンで再同期化することを許容しない。加えて、手順４２０は、その新しいレシピが利用することのできない値を要求しないことを保証するために、手順パラメーターおよび操作パラメーターを確認（validate）してもよい。一例を挙げれば、そのレシピは、新しい構成において３つのパラメーターを要求する単位手順２を更新するとする。ところで、このバッチは、現在の構成においてただ２つのパラメーターを要求する単位手順２の内部で操作の１つを実行しているとする。従って、このポイントでこのバッチを再同期化すると、そのバッチの実行の早期段階で（すなわち、そのバッチがパラメーターを入力するとともにそのパラメーターを単位手順２へ供給するポイントで）別のパラメーターを追加しなければならないという不可能な要求がなされることになる。

ユーザーがレシピ実行の論理構造に違反（violate）する状態を不注意にも作成した場合、手順４２０は代わりに、有効な同期化ポイントをレシピの後方において探索してもよく、またはそのバッチを単純にＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮ＿ＦＡＩＬＥＤ（再同期化失敗）状態に置いてもよい。ユーザーはその後、最初のバージョンのレシピを使用してそのランを再開するか、またはその新しいレシピを使用してコールド再起動を開始してもよい。これに対して、その同期化が有効（valid）であると判断されると、手順４２０は、その同期化が完了し、そのバッチを再開してもよいことをユーザーへ表示してもよい。ブロック４４０において、ユーザーは、適切なコマンドをバッチサブシステム３０へ送ってもよく、そのコマンドを受け取ると、手順４２０はそのバッチをＲＵＮＮＩＮＧ（実行中）状態へ進めて、そのバッチを引き続き実行してもよい。

バッチサブシステム３０はまた、一時停止位置リストによって新しいバージョンのレシピへの自動同期化をサポートすることもできる。図９に例示されたように、レシピ５００には、移行過程５０２〜５０８によって分けられるいくつかのステップが含まれている。一般的に言えば、レシピ５００のようなレシピには、バッチ手順、単位手順、および操作レベルにおいていくつかの移行過程が備わっている。先に検討されたように、ユーザーは、ＤｅｌｔａＶ Ｒｅｃｉｐｅ Ｓｔｕｄｉｏツールまたは同様の手段を使用して、レシピ５００を作成することができる。レシピ要素および移行過程を指定するのに加えて、ユーザーは、ゼロかまたは１つ以上の有効再同期化ポイントを含むレシピ５００に関連したリスト５１０を供給することができる。この代わりにまたはこれに加えて、サブシステム３０およびユーザーインターフェイス３２によって、ユーザーは、レシピ５００をすでに実行している作動中のバッチについてのリスト５１０を定義することができる。オペレーターが、レシピ５００についての問題点を発見し、同じレシピで実行しているがその問題点のあるバッチよりいくつかのステップが遅れている少なくとも１つ以上のバッチがあることを認識する状況では、例えばオペレーターが一時停止位置リストをその場で定義することが望ましい。

図９に例示された例では、リスト５１０には２つの移行過程識別子５１２および５１４が含まれている。移行過程識別子５１２は上記移行過程５０２に対応しており、移行過程識別子５１４は上記移行過程５０６に対応している。これらの移行過程識別子５１２および５１４をリスト５１０へ追加することによって、ユーザーは、レシピ５００の実行が移行過程５０２および５０６への到達時に一時停止されることを要求する。言い換えれば、移行過程５０２および５０６は常に無効にされるとは限らない。レシピ５００を実行するバッチが再開されるようにするためと、移行過程５０２および５０６が始まるようにするために、バッチサブシステム３０はユーザーからの明確なコマンドを受け取らなければならない。

サブシステム３０がそれぞれの移行過程５０２および５０６への到達時にレシピ５００を実行するバッチを自動的に同期化することも考えられる。このために、ユーザーインターフェイス３２は、ユーザーに手動同期化モードと自動同期化モードとの間で選択させるダイアログボックスまたはコマンドプロンプトのような制御部を設けてもよい。例えば、レシピの新しいバージョンが前のすべてのバージョンに無条件に取って代わり、かつオペレーターが手動更新をできないときに新しいバージョンが利用可能になるかもしれないことをユーザーが認識した場合には、ユーザーは、自動化モードを選択することができる。ユーザーがその自動化モードを選択したことが検出されると、上記バッチサブシステムは、移行過程５０２および５０６でレシピ５００の実行を中断し、更新されたレシピが構成データベース３４において利用可能であるかどうかをチェックし、新しいバージョンが利用可能なものである場合には、その新しいバージョンを１つ以上の対応バッチ実行部に適用する。バッチサブシステムは次いで、そのイベントをデータ履歴作成装置１４の中に記録するとともに、一時停止された同一の状態からの実行を再開する（すなわち、ウォーム再同期化を遂行する）ことができる。

図１０によれば、バッチランタイム処理部２８４は、レシピの変更を検出するために、構成データベース３４に定期的に照会することができる。バッチサブシステム３０は、検出した変更に関する指標をユーザーインターフェイス３２へ提供することができる。処理プラント制御ネットワーク１０を構成するとともに管理する多くのオペレーターおよびエンジニアが存在していてもよいことを当業者は認識されよう。その結果、エンジニアはレシピの新しいバージョンを作成することがあり、また、何人かのオペレーターはそれらの更新が利用できるものであることに気付かないことがある。人間のコミュニケーションの欠落による影響を最小限にするために、ユーザーインターフェイス３２は、代表的なウィンドウ５５０のような、バッチ構成・制御ツールにおける視覚的表示を使用してもよい。

具体的には、ウィンドウ５５０には現在実行中のバッチ５５５のリストが含まれていてもよい。好ましくは、ユーザーが、処理プラント制御ネットワーク１０の中で実行されているとともにバッチラン環境を閲覧するかまたは構成するように適合されたすべてのソフトウェアモジュールからウィンドウ５５０を呼び出すことができる。例えば、上記のＤｅｌｔａＶ環境によって、バッチ作動型インターフェイスソフトウェアの一部としてだけでなくバッチ作動ソフトウェアの一部として、ウィンドウ５５０を設けることができる。

それぞれの作動中のバッチについて、上記リスト５５５には、バッチ識別表示５５７、レシピ識別表示５５９、および状態表示５６１が含まれていてもよい。加えて、ウィンドウ５５０には、開始、停止、および一時停止のボタン５６５のようなバッチ動作コントロールが含まれていてもよい。さらに、ボタン５６７を操作することによって、ユーザーは、選択されたバッチの動作を手動制御の下に置くことができる。またさらに、ユーザーは、選択されたバッチをボタン５６９の操作によって同期化することができる。ユーザーが開始、停止、一時停止、および再同期化の選択肢を有効に呼び出すために、リスト５５５には更新表示５７０が含まれていてもよい。図１０に例示されたように、更新表示５７０は、最近更新されたレシピに対応しているラインにおいて起動することができる。例えば、RECIPE＿００１は、BATCH＿００１が開始された後で更新されているが、オペレーターがその更新に気付いていない場合がある。

ユーザーは、更新表示５７０を示しているラインにおいてダブルクリックするかあるいは詳細レシピウィンドウ５７５を同様なやり方で呼び出すことができる。詳細レシピウィンドウ５７５は、バッチランタイム処理部２８４が１つ以上の変更を検出したレシピの１つ以上の部分を反転表示させるか、さもなければそれを特定することができる。図１０に例示された例では、BATCH＿００１によって現在実行されているレシピの中に含まれたレシピ要素５８０は、上記の新しいバージョンとは異なっている。ユーザーは、このレシピ要素５８０の変更を見ることができるとともに、RECIPE＿００１を手動方式または自動方式で同期化することができる。

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

図１は、バッチラン環境が要求に応じてレシピ同期化を実施するプロセス制御ネットワークの一部の部分ブロック図、部分模式図である。 図２は、Ｓ８８規格に合致するレシピの入れ子構造が例示されているブロック図である。 図３は、バッチラン環境における構成サブシステムとやりとりするバッチサブシステムの代表的アーキテクチャーを例示しているブロック図である。 図４は、１つのレシピ要素がその要素の名称を変更することなく更新されるバージョンのレシピにおけるオンライン式バッチ同期化を模式的に例示している。 図５は、新しいレシピ要素が付加されたバージョンのレシピにおいてのオンライン式バッチ同期化を模式的に例示している。 図６は、いくつかの条件付き論理が更新されたバージョンのレシピにおけるオンライン式バッチ同期化を模式的に例示している。 図７は、代表的なバッチラン環境におけるバッチの同期化の間におけるレシピ構成サブシステムとバッチサブシステムとの間の上位レベルにおけるやりとりを例示しているブロック図である。 図８は、図３において例示されたシステムによって果たされた再同期化の手順を例示している代表的フローチャートである。 図９は、特定のレシピにおける有効再同期化ポイントの構成を例示している。 図１０は、手動再同期化手順の間にユーザーへ表示することのできる代表的ダイアログスクリーンを例示している。

Claims (32)

1. 製造環境において、複数の動作および複数のパラメーターを指定する製品レシピに従ってバッチ処理を実行する方法であって、
   前記製品レシピの第１バージョンに対応するバッチ処理の少なくとも１つの動作を実行し、
   前記製品レシピの前記第１バージョンとは異なる前記製品レシピの第２バージョンを受け取り、
   前記バッチ処理が完了する前に前記バッチ処理の実行を一時停止し、
   前記バッチ処理の実行を前記製品レシピの前記第２バージョンに従って再開する、
   方法。
2. 前記製品レシピに従って前記バッチ処理を実行することは、複数のステップを実行することを含み、それぞれのステップは、少なくとも１つの操作を備えている単位手順に対応し、それぞれの操作は、少なくとも１つのフェーズを有し、
   前記バッチ処理は、前記複数のステップの第１のステップに関連付けられた条件が満たされた場合に前記複数のステップの前記第１のステップから前記複数のステップの第２のステップへ移行することを含む、
   請求項１に記載の方法。
3. 前記製品レシピの前記第２バージョンを受け取ることは、
   単位手順、操作、またはフェーズの少なくとも１つにおいて前記製品レシピの前記第１バージョンとは異なる前記製品レシピの前記第２バージョンを受け取ることを含む、
   請求項２に記載の方法。
4. 前記製品レシピに従って前記バッチ処理を実行することは、
   ＡＮＳＩ／ＩＳＡ−８８（Ｓ８８）規格に合致する前記製品レシピに従って前記バッチ処理を実行することを含む、
   請求項２に記載の方法。
5. 前記バッチ処理の少なくとも１つの同期化ポイントを指定する構成データを受け取ることをさらに含み、
   前記少なくとも１つの同期化ポイントは、前記バッチ処理を一時停止することができる、前記製品レシピの前記第１バージョンの前記複数の動作のうちの２つ以上の動作の間のトランザクションに対応する、
   請求項１に記載の方法。
6. 前記バッチ処理の実行を前記レシピの前記第２バージョンに従って再開することは、
   前記少なくとも１つの同期化ポイントに到達した場合に前記レシピの前記第２バージョンを自動的に選択することを含む、
   請求項５に記載の方法。
7. 前記構成データを受け取ることは、
   前記バッチ処理の少なくとも１つの動作を実行する前に、前記構成データを受け取ることを含み、
   前記バッチ処理の実行を一時停止することは、
   前記少なくとも１つの同期化ポイントに到達した場合に前記バッチ処理の実行を一時停止し、
   前記バッチ処理の実行の前記一時停止をユーザーインターフェイスへ報告する、
   ことを含み、
   前記方法は、
   前記ユーザーインターフェイスからの第１コマンドの受け取りに応じて、前記バッチ処理の実行を前記レシピの前記第１バージョンに従って再開することをさらに含み、
   前記バッチ処理の実行を前記レシピの前記第２バージョンに従って再開することは、
   前記ユーザーインターフェイスからの第２コマンドの受け取りに応じて、前記バッチ処理の実行を前記レシピの前記第２バージョンに従って再開することを含む、
   請求項５に記載の方法。
8. 前記構成データを受け取ることは、
   複数の同期化ポイントを指定する前記構成データを受けることを含み、
   前記バッチ処理の実行を一時停止することは、
   前記複数の同期化ポイントの１つに到達するたびに前記バッチ処理の実行を一時停止し、
   前記レシピの前記第２バージョンが利用可能であるかを検出するために照会を開始し、
   前記レシピの前記第２バージョンが利用可能でない場合には、前記バッチ処理の実行を前記レシピの前記第１バージョンに従って再開する、
   ことを含む、
   請求項５に記載の方法。
9. 前記バッチ処理の実行を前記製品レシピの前記第２バージョンに従って再開することは、
   認証されたユーザーからの確認を受け取ることを含む、
   請求項１に記載の方法。
10. 永続的メモリーの中にイベント情報を保存することをさらに含み、
    前記イベント情報は、前記複数の動作の１つまたはいくつかの完了に対応する、
    請求項１に記載の方法。
11. 前記製品レシピの前記第２バージョンを受け取ることは、
    前記レシピの前記第２バージョンを前記レシピの前記第１バージョンと比較して、前記レシピの前記第１バージョンと前記レシピの前記第２バージョンとの差を示すレポートを作成し、
    前記レポートをユーザーインターフェイスへ送信する、
    ことを含む、
    請求項１に記載の方法。
12. 製造環境において、複数の動作を指定する製品レシピに従って実行されるバッチ処理を制御するシステムであって、
    プロセス制御設備へ通信可能に接続されて、前記バッチ処理を実行するためのバッチ実行部と、
    前記バッチ実行部へ通信可能に接続されて、少なくとも、前記バッチ処理を起動する第１コマンドと前記バッチ処理を停止する第２コマンドとによって前記バッチ実行部を制御するバッチ管理部と、
    前記レシピの修正を検出するとともに前記検出された修正を示すデータを前記バッチ管理部へ報告するバッチランタイムモジュールと、
    を備え、
    前記バッチ管理部は、前記バッチ実行部が前記バッチ処理の実行を完了する前に、前記レシピにおける変更を前記バッチ実行部に適用することを含む、
    システム。
13. 前記レシピは、複数の単位手順を含み、
    前記レシピの修正は、前記レシピへの新しい単位手順の追加を含む、
    請求項１２に記載のシステム。
14. 前記レシピは、複数の単位手順を含み、
    前記修正は、前記複数の単位手順の１つの単位手順の複数のステップの少なくとも１つの変更を含み、
    前記複数の単位手順の前記１つの単位手順に、前記複数の単位手順の前記１つの単位手順の最初の名称に関連した新しいバージョン識別子を割り当てる、
    請求項１２に記載のシステム。
15. 前記修正は、前記複数の動作の２つの間の移行過程に関連付けられた論理演算子の変更を含む、
    請求項１２に記載のシステム。
16. 前記複数の動作の間の移行過程を示すイベントデータを記憶するために永続的メモリーをさらに備える、
    請求項１２に記載のシステム。
17. 前記バッチ管理部へ通信可能に接続されたユーザーインターフェイスをさらに備え、
    前記ユーザーインターフェイスは、
    前記修正を含む前記レシピの新しいバージョンで前記レシピを同期化し、前記レシピの前記新しいバージョンを前記バッチ実行部に適用するためのユーザー要求を受け取る第１機能を含む、
    請求項１２に記載のシステム。
18. 前記ユーザーインターフェイスは、
    作動中のバッチ実行部のリストをユーザーへ提供するための第２機能と、
    前記作動中のバッチ実行部の前記リストから作動中のバッチ実行部の選択をユーザーから受け取るための第３機能と、
    をさらに含む、
    請求項１７に記載のシステム。
19. 前記ユーザーインターフェイスは、
    前記レシピの前記新しいバージョンを前記バッチ実行部に適用する前にユーザー認証情報を確認するための第２機能をさらに含む、
    請求項１７に記載のシステム。
20. 前記ユーザーインターフェイスは、
    前記レシピの同期化ポイントのセットを指定する構成データを受け取るための第２機能をさらに含み、
    前記同期化ポイントのセットのそれぞれの同期化ポイントは、前記バッチ実行部を一時停止することができる、前記レシピの前記複数の動作のうちの２つの動作の間のトランザクションに対応している、
    請求項１７に記載のシステム。
21. 前記修正が前記レシピの論理構造に違反するか否かを決定するとともに確認表示を生成するための確認モジュールをさらに備え、
    前記バッチ管理部は、前記確認表示が前記論理の違反を示していない場合にだけ、前記レシピの前記変更を前記バッチ実行部に適用する、
    請求項１２に記載のシステム。
22. 前記バッチランタイムモジュールは、前記レシピの前記修正を示すレポートを作成するとともに前記作成されたレポートをユーザーへ送信する、
    請求項１２に記載のシステム。
23. 処理プラントの内部で、複数の動作および複数のパラメーターを指定する製品レシピに従って複数のバッチ処理を実行する方法であって、
    前記製品レシピの第１バージョンを受け取り、
    前記製品レシピの前記第１バージョンを第１バッチ実行部および第２バッチ実行部に適用し、前記第１バッチ実行部および前記第２バッチ実行部のそれぞれは各々のプロセス制御設備を使用して前記製品レシピの実行を制御し、
    前記第１バッチ実行部および前記第２バッチ実行部のそれぞれにおいて前記製品レシピの前記第１バージョンに合致する各々のバッチランを始動し、
    前記製品レシピの第２バージョンを受け取り、前記製品レシピの前記第２バージョンは前記複数の動作または前記複数のパラメーターの少なくとも一つにおいて前記製品レシピの前記第１バージョンとは異なるものであり、
    前記第１バッチ実行部において前記バッチランの実行を一時停止し、
    前記第１バッチ実行部が前記レシピの前記第１バージョンの実行を完了する前に、前記レシピの前記第２バージョンを前記第１バッチ実行部に適用し、
    前記レシピの前記第２バージョンに従って、前記第１バッチ実行部において前記バッチランの実行を再開する、
    方法。
24. 前記第１バッチ実行部における前記バッチランの実行を前記レシピの前記第２バージョンに従って完了し、
    前記第２バッチ実行部における前記バッチランの実行を前記レシピの前記第１バージョンに従って完了し、
    前記第１バッチ実行部および前記第２バッチ実行部から実行結果を受け取り、
    前記実行結果に基づいて前記第１バージョンおよび前記第２バージョンから選択する、
    ことをさらに含む、
    請求項２３に記載の方法。
25. 前記実行結果に基づいて前記第１バージョンおよび前記第２バージョンから選択することは、
    前記実行結果を示すユーザーレポートを作成し、
    前記製品レシピの前記第１バージョンまたは前記製品レシピの前記第２バージョンの選択を示すユーザー選択を受け取る、
    ことを含む、
    請求項２４に記載の方法。
26. 前記実行結果に基づいて前記第１バージョンおよび前記第２バージョンから選択することは、
    前記第１バッチ実行部に関連した前記実行結果が不満足なものである場合に前記第１バッチ実行部において前記製品レシピの前記第１バージョンへ戻すことを含む、
    請求項２４に記載の方法。
27. 前記第１バッチ実行部における前記バッチランの実行を一時停止することは、
    ユーザーコマンドの受け取りに応じて前記バッチランの実行を一時停止することを含む、
    請求項２４に記載の方法。
28. 前記第１バッチ実行部における前記バッチランの実行を一時停止することは、
    前記バッチランの実行に関連した所定の状態の検出に応じて前記バッチランの実行を自動的に一時停止することを含む、
    請求項２４に記載の方法。
29. 前記レシピの前記第１バージョンを、同期化ポイントのセットに関連付けることをさらに含み、同期化ポイントそれぞれが対応するバッチ実行部の実行を一時停止することが可能な前記複数の動作のうちの２つ以上の動作の間の移行過程を指定する、
    請求項２４に記載の方法。
30. 前記第１バッチ実行部における前記バッチランの実行を一時停止することは、
    前記第１バッチ実行部の現在の状態の情報を検索し、前記現在の状態は、前記バッチ実行部によってまたは前記複数の動作のうちの２つ以上の動作の間におけるトランザクションによって実行される前記複数の動作の１つを指定し、
    前記レシピの前記第２バージョンを前記バッチ実行部の前記現在の状態で前記第１バッチ実行部に適用することができるかどうかを決定するために、前記現在の状態の情報を前記同期化ポイントのセットと比較する、
    ことを含む、
    請求項２９に記載の方法。
31. 前記レシピの前記第２バージョンを前記第１バッチ実行部に適用する前に、前記レシピの前記第２バージョンに関連したレシピの論理構造を検証することにより前記レシピの前記第２バージョンを確認することをさらに含む、
    請求項２４に記載の方法。
32. 前記プロセス制御設備は、複数のフィールド装置を含み、
    前記複数のフィールド装置のそれぞれは、前記処理プラントの内部で測定機能または制御機能の少なくとも一つを実行し、
    前記第１バッチ実行部および前記第２バッチ実行部のそれぞれは、前記複数のフィールド装置に接続された少なくとも１つのプロセス制御装置と通信し、
    前記第１バッチ実行部および前記第２バッチ実行部のそれぞれにおいて各々のバッチランを始動することは、前記レシピの前記第１バージョンに対応している指示セットを前記プロセス制御装置にダウンロードすることを含む、
    請求項２４に記載の方法。

Images