JP2004355622A - 独立バッチ実行プロセスを有するバッチ実行エンジン - Google Patents

Abstract

【課題】
バッチ実行中にソフトウェア不良が発生すると、通常、バッチ実行アプリケーションが停止または中止されるようにプログラミングされ、これに起因して同じバッチ実行アプリケーションの制御下で同時に実行されているバッチの全部が停止または中止させられる。【解決手段】
プロセスプラント制御システムは、各バッチに対して、別々のアプリケーションプロセス空間内に別々のバッチプロセスアプリケーションを生成または作成するバッチ実行エンジンを備えており、このバッチ実行エンジンは、バッチランを設定すべく用いられるバッチオペレータインターフェイスまたは他のインターフェイスと通信するための通信ソフトウェアと、前記プロセスプラント内の装置の現行の状態を示すマスタプロセス装置モデルと、バッチプロセスを作成してそのバッチプロセスの各々を別々のアプリケーションプロセス空間に分離独立させるバッチ実行マネージャとを備えている。
【選択図】 図４

Description

本発明は、一般的に、プロセス制御ネットワークに関するものであり、さらに詳細には、プロセスプラントにおいて、独立したバッチプロセスを実行するバッチ実行エンジンに関するものである。

化学プロセス、石油プロセス、または他のプロセスにおいて利用されるプロセス制御ネットワークは、一または複数のフィールドデバイスに通信可能に接続された集中型プロセスコントローラを備えていることが一般的である。これらのフィールドデバイスには、たとえば、バルブポジショナ、スイッチ、センサ（たとえば、温度センサ、圧力センサ、および流量センサ）などが含まれる。これらのフィールドデバイスは、プロセス内において物理的な制御機能（たとえば、バルブの開閉）を実行し、プロセス内においてプロセス動作の制御に用いられるプロセスプラント内の測定を実行し、またはプロセス内のその他の所望な機能を実行しうる。従来、プロセスコントローラは、フィールドデバイスに対してまたはフィールドデバイスからたとえば４〜２０ｍＡ（ミリアンペア）信号を伝送しうる一または複数のアナログ信号回線またはアナログ信号バスを用いて、フィールドデバイスに接続されていた。しかしながら、近年、プロセス制御工業では、Ｆｏｕｎｄａｔｉｏｎ（登録商標）ＦＩＬＥＤＢＵＳ（以下「Ｆｉｅｌｄｂｕｓ」と呼ぶ）プロトコル、ＨＡＲＴ（登録商標）プロトコル、ＰＲＯＦＩＢＵＳ（登録商標）プロトコル、ＷＯＲＬＤＦＩＰ（登録商標）プロトコル、Ｄｅｖｉｃｅ−Ｎｅｔ（登録商標）プロトコル、およびＣＡＮプロトコルの如き複数の標準型、開放型、またはデジタルとアナログとの混合型の通信プロトコルが開発されてきた。これらの通信プロトコルを利用することにより、コントローラとフィールドデバイスとの間の通信が実現される。一般的に、プロセスコントローラは、一または複数のフィールドデバイスにより計測される測定値および／またはそれらのフィールドデバイスに関する他の情報を表す信号を受信し、この情報を用いて通常複雑な制御ルーチンを実施し、制御信号を生成する。この制御信号は、上記の信号回線またはバスを介して、フィールドデバイスに送信され、プロセスプラントの運転を制御する。

バッチプロセスに用いられるような特定のタイプのプロセス制御ネットワークは、複数の組の複製の装置を備えていることが一般的であり、各組は、同一のまたは同等の装置を有するように設計され、これらの装置は、プロセスプラント内において実質的に同一の機能を実行する。従って、たとえば、クッキー製造プラントは複数の組の混合装置、複数の組の焼き装置、および複数の組の包装装置を有しており、混合器の一部または全部は平行して動作可能であり、焼き装置および包装装置の一部または全部と連続して動作するように接続可能である。そのようなシステムでは、任意の特定の組の複製の装置の動作を制御するために同一の共通の制御アルゴリズムまたは制御ルーチンの使用することにより、作成してコントローラ内に格納しなければならない制御ルーチンの数を減らせることが望まれている。しかしながら、これらの制御アルゴリズムは、実行された場合に、その時点において使用されている特定のユニットの装置を特定するように書かれなければならない。通常、バッチ制御手順においては、複数の異なるステップまたはステージが順次に実行され、第一のステージを終了してから第二のステージが開始される。したがって、上記のクッキー製造プラントでは、バッチ手順では、混合装置を制御する第一のサブプロセスまたはステップを実行され、次いで、混合装置により作られた製品に対して焼き装置を作動させる第二のサブプロセスを実行され、次いで、焼き装置により生産される製品を包装する放送装置を制御する第三のサブプロセスを実行される。各ステップには有限の時間がかかる。

従来のプロセス制御システムでは、ユーザが異なる装置を用いてまたは同一の装置のうちの一部を異なる時間に用いて、プロセスプラント内で同時並行的に複数の異なるバッチランを実行できるようなバッチ実行ルーチンまたはバッチ実行アプリケーションを供することが知られている。このバッチ実行アプリケーションは、プラント内の異なる装置のリストおよびそれらの相互接続関係を収納するプロセス装置モデルを格納する。これらのリストおよび相互接続関係は、バッチ実行アプリケーションにより、バッチ運転中の任意の所与の時間実行されている個別のバッチの各ステップにおいて使用されるべき実際の装置を選択するために利用される。異なるバッチランの動作中に装置を動的に選択する方法は、特許文献１に開示されており、本明細書において参照することにより、明示的に、その内容を援用する。いうまでもなく、プラントの規模にもよるが、バッチ実行アプリケーションを利用して、プラント内の異なる装置を用いる複数の同時並行のバッチランを実行することができる。大規模プロセスプラントの一部では、一度に１バッチと２，３百バッチとの間にあるいずれかの数のバッチ実行を調整するためにバッチ実行アプリケーションが利用されている。
米国特許第6,522,936号公報

残念なことには、バッチ実行アプリケーションの一部には、バッチランのうちのいずれか一つのバッチ実行中にソフトウェア不良が発生すると、バッチ実行アプリケーションが「停止」または中止されるようにプログラミングされているものもあり、通常、これに起因して、その同じバッチ実行アプリケーションの制御下で同時に実行されているバッチの全部が停止または中止させられる。バッチ実行アプリケーションが停止すると、プロセスプラントの処理機能が停止してしまい、オペレータが手動ですべてのバッチランを再び開始させる必要が生じる。バッチ実行アプリケーションが、停止時間以前の状態に各バッチを戻し、稼働している制御システムと同期を取り直している間に、そのような再開始作業を行うには非常に多くの時間を必要とする。いうまでもなく、この作業により、プロセスプラントの不稼働時間が増加し、オペレータの仕事をさらに増やすことになる。また、バッチ実行アプリケーションが停止すると、その停止の時点においてプロセスプラントに存在していた一または複数のバッチ分の材料が廃棄されることもあり、その場合、材料の無駄およびプラント稼働時間の損失の両方の点における財務上の損失が発生することになる。

さらに、公知のバッチ実行アプリケーションがプロセスプラント内で動作しているまたは実行されている間に、このアプリケーションにより用いられているプロセス装置モデルの設定を修正することは不可能ではないにしても困難なことである。というのは、このバッチ実行アプリケーションにより実行されている異なるバッチの各々が、使用装置に関する決定を行うために、その装置モデルを参照または使用するからである。したがって、公知のバッチ実行アプリケーションの場合には、（現在実行中のバッチが終了するまで待機してまたはそれらのバッチの動作を中断してから）バッチ実行アプリケーションを停止し、そのバッチ実行アプリケーション内のプロセス装置モデルの設定を更新し、次いで、新規のプロセス装置モデルを用いてそのバッチ実行アプリケーションを再始動する。いうまでもなく、この作業は、バッチ実行アプリケーションによりその実行が現在制御されているすべてのバッチに対して悪い影響を与える可能性がある。

さらに、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングソフトウェアの如きオペレーティングソフトウェアのほとんどは、任意の特定の（単一の）アプリケーションによりアドレス指定されるまたは用いられうる物理的メモリおよび仮想メモリの量を制限する。一つのケースでは、オペレーティングソフトウェアは、メモリ領域が不足してオペレーティングシステムにより停止されるまでに約２ギガバイトのメモリをアプリケーションが使用できるというような制限をしている。このような機能により、バッチ実行アプリケーションにより同時に実行されうるバッチ、とくに複雑なレシピを有する大規模なまたは複雑なバッチ数を必然的に制限される。というのは、新規のバッチが実行される毎にバッチ実行アプリケーションの必要メモリ量が増加するからである。現在、百に近い数のバッチを同時に実行するバッチ実行アプリケーションは、このメモリ制限の壁にぶち当たり始めている。このようなメモリ制約は、たいていの小規模プロセスプラントではほとんど問題にならないが、この制約により、非常に大規模のプロセスプラントでは、バッチ実行アプリケーションにより同時並行で実行可能なバッチの数が制限されている。この制約が原因で、バッチプロセス設計者は、所望の数のバッチを同時に実行できるように、同一プラント内に複数の異なるバッチ実行アプリケーションを実装する場合がある。しかしながら、そのような対処手段を利用したとしても、（別々のアプリケーションとして動作する）異なるバッチ実行アプリケーションでは、最も経済的なまたは最適な方法で、プロセス装置を共有することもできなければそれらの利用を調整することもできない。

プロセスプラント用のプロセス制御システムは、プロセスプラント内で実行すべく各バッチに対して個別のバッチ実行プロセスを生成または作成するバッチ実行エンジンを備えている。このバッチ実行エンジンは、バッチランを設定すべく用いられるバッチオペレータインターフェイスと通信するための通信ソフトウェアと、プロセスプラント内の装置の現状を示すマスタプロセス装置モデルと、異なるバッチプロセスを作成し、異なるアプリケーションプロセス空間で実行すべくこれらの異なるバッチプロセスを分離独立させるバッチ実行マネージャとを備えている。これらの作成されたバッチプロセスの各々は、バッチレシピにより定義される通りに特定のバッチを実現するバッチロジックと、プロセス装置モデルのコピーと、特定のバッチ情報をユーザに供与するため、プロセスプラント内の他のバッチとの調整を要求または実現するため、などのためにバッチ実行マネージャとの通信用の通信インターフェイスとを備えている。上記のバッチロジックは、一または複数のユニット手順からなる手順を備えており、各ユニット手順は、一または複数のユニットオペレーションからなり、各オペレーションは、一または複数のフェイズからなっている。

バッチプロセスの各々は、いったん作成されると、バッチ実行エンジンから独立し他アプリケーション空間で動作し、特定のバッチの操作を実行および監視する。この作成されたバッチプロセスは、バッチ実行エンジンからおよび相互に分離されたアプリケーションプロセス空間において実行されるので、あるバッチプロセスでのソフトウェア不良がそのバッチ実行エンジンの停止またはその他のバッチプロセスのいずれかの停止を引き起こすことはない。これにより、特定のバッチプロセスのソフトウェア不良の影響が削減される。同様に、既存するバッチプロセスの現行の動作に影響を与えることなく、バッチ実行エンジンに関連するプロセス装置モデルを変更することができる。というのは、実行中のバッチプロセスは、そのバッチプロセスが作成されたときに存在していたプロセス装置モデルのコピーを備えており、その情報がその時点において正確である限りにおいて、バッチ実行マネージャが動作していなくともバッチプロセスの動作中にいつでもこの装置モデルのコピーを使用することができるからである。さらに、バッチプロセスの各々が、別々のアプリケーション空間における別々のアプリケーションとして実行されるので、各バッチプロセスは、個々のプロセスのオペレーティングシステムにより課される制限により影響を受けない。

あるバッチプロセスでのソフトウェア不良がそのバッチ実行エンジン、またはその他のバッチプロセスのいずれかの停止を引き起こすことはないので、特定のバッチプロセスのソフトウェア不良の影響を削減することができる。

図１を参照すると、プロセスプラント制御ネットワーク10は、プロセスコントローラ12を備えている。このプロセスコントローラ12は、たとえばイーサネット（登録商標）型通信接続15を介して、複数のワークステーションに接続されている。また、このコントローラ12は、入出力（Ｉ／Ｏ）デバイス（図示せず）と一組の通信回線または通信バス18とを介して、（参照番号16が全体的に付されている）プロセスプラント内のデバイスまたは装置とも接続されている。一例ではあるが、コントローラ12は、フィッシャーローズマウントシステムズ社から販売されているＤｅｌｔａＶ（登録商標）であってもよい。このコントローラ12は、一または複数のプロセス制御ルーチンを実行してプロセスプラント16の所望の制御を実現すべくプロセスプラント16全体にわたり分散されているフィールドデバイスおよびフィールドデバイス内の機能ブロックの如き制御エレメントと通信することができる。これらの制御ルーチンは、連続式プロセス制御ルーチンまたは連続式プロセス制御ルーチン手順であってもよいしバッチ式プロセス制御ルーチンまたはバッチ式プロセス制御手順であってもよい。（たとえば、パーソナルコンピュータ、サーバなどでありうる）ワークステーション14は、コントローラ12により実行されるプロセス制御ルーチンを設計するために、そのようなプロセス制御ルーチンをダウンロードすべく通信するために、プロセスプラント16の運転中にプロセスプラント16に関する情報を受信・表示するために、およびコントローラ12により実行されるプロセス制御ルーチンと相互作用するために、一または複数のエンジニアまたはオペレータにより用いられてもよい。

ワークステーション14の各々は、メモリ20を備えており、このメモリ21は、コンフィギュレーション設計アプリケーションの如きアプリケーションを格納し、プロセスプラント16のコンフィギュレーションに関するコンフィギュレーションデータの如きデータを格納する。さらに、ワークステーション14の各々は、プロセッサ21を備えており、このプロセッサ21は、ユーザによるプロセス制御ルーチンの設計およびそのプロセス制御ルーチンのコントローラ12へのダウンロードなどを可能にするアプリケーションを実行する。同様に、コントローラ12は、コンフィギュレーションデータおよびプロセスプラント16を制御すべく用いられるプロセス制御ルーチンを格納するメモリ22と、プロセス制御戦略を実現するプロセス制御ルーチンを実行するプロセッサ24とを備えている。コントローラ12がＤｅｌｔａＶコントローラである場合、ワークステーション14のうちの一つのワークステーションにおける一または複数のアプリケーションと連動して、コントローラ12は、コントローラ12内のプロセス制御ルーチンの画像表示をユーザに提供して、そのプロセス制御ルーチン内の制御エレメントおよびプロセスプラント16の制御を実現すべくこれらの制御エレメントが設定される様態を表示しうる。

図１に示されているプロセスプラント制御ネットワーク10の一例では、コントローラ12は、バス18を介して、二組の同様に構成された装置に通信可能に接続されており、各組の装置は、リアクタ＿０１（Ｒ１）またはリアクタ＿０２（Ｒ２）と本明細書で呼ぶところのリアクタユニットと、フィルタ＿０１（Ｆ１）またはフィルタ＿０２（Ｆ２）と本明細書で呼ぶところのフィルタユニットと、ドライヤ＿０１（Ｄ１）またはドライヤ＿０２（Ｄ２）と本明細書で呼ぶところのドライヤユニットとを備えている。リアクタ＿０１は、リアクタ容器と、たとえばヘッドタンク（図示せず）からリアクタ容器100に流体を供給する流入管を制御するように接続されている二つの流入バルブ101、102と、流出管を介して、リアクタ容器100から流出する流体流量を制御するように接続されている。温度センサ、圧力センサ、液体レベル計測器などの如きセンサまたは電気ヒータまたはスチームヒータの如き他の装置でありうるデバイス105は、リアクタ容器100の中またはその近傍に配置されている。リアクタ＿０１は、フィルタ装置110を有するフィルタ＿０１にバルブ103を介して接続されており、次いで、フィルタ＿０１は、乾燥装置120を有するドライヤ＿０１に接続されている。同様に、第二の組の装置は、リアクタ容器200を有するリアクタ＿０２と、二つの流入バルブ201、202、流出バルブ203と、デバイス205とを含んでいる。リアクタ＿０２は、フィルタ装置210を有するフィルタ＿０２に接続されており、次いで、フィルタ＿０２は、乾燥機220を有するドライヤ＿０２に接続されている。フィルタ装置110、210および乾燥機120、220は、それらに関連する制御エレメント（たとえば、ヒータ、コンベヤベルトなど）、センサなどをさらに有しうる。所望ならば、図示されていないが、リアクタ、フィルタ、およびドライヤをそれぞれ一つずつ使用するようなバッチランにおいて、図１に例示されている装置を自由に組み合わせ使用できるように、フィルタユニットフィルタ＿０１、フィルタ＿０２の各々をリアクタユニットリアクタ＿０１、リアクタ＿０２の各々に物理的に接続し、ドライヤユニットドライヤ＿０１、ドライヤ＿０２の各々をフィルタユニットフィルタ＿０１、フィルタ＿０２の各々に接続してもよい。

図１に例示されるように、コントローラ12は、バス18を介して、バルブ101〜103、201〜203、デバイス105、205、フィルタ110、210、および乾燥機120、220（ならびに、これらに関連するその他の装置）に通信可能に接続され、これらの（ユニット、フィールドデバイスなどでありうる）エレメントの動作を制御し、これらに関する一または複数の働きを実行する。このような働きには、たとえば、リアクタ容器または乾燥機の充填、リアクタ容器または乾燥機の内の材料の加熱、リアクタ容器または乾燥機の中身の放出、リアクタ容器または乾燥機の洗浄、フィルタの運転などが含まれる。もちろん、コントローラ12は、たとえば、追加のバスを介して、４〜２０ｍａ回線、ＨＡＲＴ通信回線の如き専用通信回線を介して、プロセスプラント16内のエレメントに接続されてもよい。

図１に例示されているバルブ、センサ、および他の装置は、たとえば、Ｆｉｅｌｄｂｕｓフィールドデバイス、標準型４〜２０ｍａフィールドデバイス、ＨＡＲＴフィールドデバイスなどを含むいかなる所望の種類のまたはタイプの装置であってよく、Ｆｉｅｌｄｂｕｓプロトコル、ＨＡＲＴプロトコル、４〜２０ｍａアナログプロトコルなどの如きいかなる公知のまたは所望の通信プロトコルを用いてコントローラ12と通信してもよい。さらに、他のタイプのデバイスを、いかなる所望の方法で、コントローラ12に接続してもそれにより制御してもよい。また、プロセスプラント16に関連する他のデバイスまたは領域を制御するために、たとえばイーサネット（登録商標）通信回線15を介して、他のコントローラをコントローラ12およびワークステーション14に接続してもよい。このような追加のコントローラの動作は、いかなる所望のまたは公知の方法で、図１に例示されているコントローラ12の動作と調整されてもよい。

一般的にいえば、図１のプロセス制御システムは、プロセスプラント16内のさまざまなバッチランを実行・調整するバッチ実行システムを、たとえばワークステーション14のうちの一つが実行するようなバッチプロセスを実現すべく用いられうる。このようなバッチ実行システム30が図１のワークステーション14a内に格納されているものとして例示されている。いうまでもなく、バッチ実行システム30は、他のワークステーション14または、任意の無線方式を含むいかなる所望の方法でバス15またはバス18に通信可能に接続されるコンピュータに格納されてもよいしそれにより実行されてもよい。同様に、図３に関連してさらに詳細に説明するように、バッチ実行システム30は、さまざまなコンポーネントに分割されてもよいし、プロセスプラント16内のさまざまなコンピュータまたはワークステーションに格納されそれにより実行されるさまざまなコンポーネントに関連付けされてもよい。

一般的にいえば、バッチ実行システム30は、プロセスプラント内で実行されるバッチランの数をユーザが指定できるようにし、かつプロセスプラント制御ネットワーク10内で実質的に独立して動作するように複数の異なるバッチランまたはバッチプロセスを設定して、さまざまなバッチランを実行する高水準の制御ルーチンである。このようなバッチプロセスの各々により、一または複数のユニット手順の動作が指揮される。ユニット手順とは、プロセスプラント内のリアクタユニット、フィルタユニット、ドライヤユニット、または他の装置のうちの一つの単一ユニット上で作動するサブルーチンまたはプロセスである。（ワークステーション14のうちのひとつで通常実行されるバッチランの一部である）各ユニット手続きは、一連の操作を実行する。これらの操作の各々は、ユニットに対して一または複数のフェイズを実行しうる。この説明の場合、フェイズとは、ユニットに対して実行される最小レベルのアクションまたはステップであり、コントローラ12のうちの一つ内で通常実現または実行され、操作とは、ユニットに対して特定の機能を実行する一組のフェイズであり、コントローラ12内に一連のフェイズを呼び出すことによりワークステーション14のうちの一つで通常実現または実行される。また、ユニット手続きとは、単一ユニットに対して実行される一連の一または複数の操作であり、ワークステーション14のうちの一つ上の一組の操作として通常実現される。したがって、いずれのユニット手続きであっても、一または複数のフェイズおよび／または一または複数の操作を有している。このようにして、各バッチプロセスは、食料品、医薬品などの如き製品を生産するために必要なさまざまなステップまたはステージ（すなわち、ユニット手続き）を実行する。

個別のバッチに対してさまざまなユニット手続き、操作、フェイズを実現するために、バッチプロセスは、いわゆるレシピを利用しており、このレシピは、実行されるステップ、それらのステップに関連する量および時間、ならびにそれらのステップの順番を指定する。一つのレシピのステップには、リアクタ容器を適切な材料または構成要素で充填すること、リアクタ容器内でそれらの材料を混合すること、特定の時間特定の温度にリアクタ容器内材料を加熱すること、リアクタ容器を空にして次のバッチのためにリアクタ容器を洗浄すること、リアクタの排出物をフィルタリングするためにフィルタを作動させること、リアクタ容器内で製造された製品を乾燥させるために乾燥機を作動させることなどが含まれる。異なるユニットに関連する一連のステップの各々は、そのバッチのユニット手続きを定義し、バッチプロセスは、これらのユニット手続きの各々に対して異なる制御アルゴリズムを実行する。もちろん、指定の材料、材料の量、加熱温度、加熱時間などは、レシピに応じて異なってよく、したがって、これらのパラメータは、製造または生産される製品および用いられるレシピに応じてバッチ毎に変えてもよい。当業者にとり明らかであるように、本明細書では、図１に例示されているリアクタユニット、フィルタユニット、およびドライヤユニットを用いるバッチに対する制御ルーチンおよび制御コンフィギュレーションが記載されているが、所望ならば、その他の所望のバッチプロセスランを実行するまたは連続型プロセスプラントランを実行するための他の所望のデバイスを制御するために制御ルーチンを用いてもよい。

また、当業者にとり明らかであるように、包括的バッチプロセスの同一のフェイズ、操作、またはユニット手続きを、異なる実際のバッチプロセスの一部として、同一のまたは異なる時間において、図１の異なるリアクタユニットの各々に対して実行しうる。さらに、図１のリアクタユニットが同一の数のまたはタイプの装置を有しているので（すなわち、それらが同一のユニットクラスに属しているので）、特定のフェイズに対する同一の包括的フェイズ制御ルーチンを異なるリアクタユニットの各々の制御のために用いうる。ただし、異なるリアクタユニットに関連する異なるハードウェアまたは装置を制御するためにこの包括的フェイズ制御ルーチンを変更する必要がある。たとえば、（リアクタユニットが充填される）リアクタ＿０１の充填フェイズを実行するために、充填制御ルーチンは、特定の時間、たとえば流体レベル計測器105が容器100が満タンであると感知するまで、一または複数の流入バルブ101、102を開く。しかしながら、この同一の制御ルーチンを、流入バルブの指定をバルブ101、102からバルブ201、202に変更し、流体レベル計測器の指定を流体レベル計測器105から流体レベル計測器205に変更するだけで、リアクタ＿０２の充填フェイズを実行するために用いうる。もちろん、バッチランの一般的な動作に関連するロジックは公知であるので、本明細書においてこれ以上記載しない。

図２は、プロセスプラント内で一または複数の従来のバッチ実行ルーチンを動作可能または実行すべく用いられてきた、バスまたは他の通信ネットワーク46を介して接続されている一組のクライアントコンピュータまたはクライアントノード42と一組のサーバコンピュータまたはサーバノードとを備える公知のクライアント／サーバネットワーク40を示すブロック線図である。一般的に、図２のバッチネットワーク機構は、クライアントノード42がコマンドまたはメッセージをサーバノード44に提供し、次いで、サーバノード44がプロセスプラント内の実際のバッチを実行する２層式のクライアント／サーバ型設計の形態を有している（図２に図示せず）。一般的に、クライアントノード42は、プラントに適応可能な任意の所望の戦略を用いてユーザがそのプロセスプラント内の複数のバッチランを設定・構成することができるオペレータインターフェイスアプリケーションを有している。図２の線図では、クライアントノード42a、42c、42dのうちの三つがバッチオペレータインターフェイス（ＢＯＩ）アプリケーション48を有しているものとして例示されている。このバッチオペレータインターフェイス（ＢＯＩ）アプリケーション48は、オペレータとインターフェイスを介して接続し、実行されるべき個別のバッチをオペレータが設定・指定できるようにする、すなわち一または複数のバッチランを開始できるようにするルーチンである。同様に、クライアントノード42b、42cは、キャンペインマネージャオペレータインターフェイス（ＣＭＯＩ）アプリケーション50を有しているものとして例示されている、このキャンペインマネージャオペレータインターフェイス50アプリケーションより、ユーザが、プロセスプラント内で、特定の順番でまたは特定の時間において運転または実行されるべき（一般的に複数のシーケンシャルバッチランを有する）一連のバッチランを設定できる。このようなキャンペインマネージャの一例が、２０００年６月３０日に出願された、標題が「バッチプロセスのキャンペイン管理」である米国特許出願番号第09/609,091号に詳細に開示されており、その内容は、本明細書において参照することによりここで明示的に援用される。いうまでもなく、他のＢＯＩアプリケーションおよびＣＭＯＩアプリケーションも公知になっており、同様に利用してもよい。

サーバノード44a、44b、44cの各々は、公知のバッチ実行ルーチンまたはバッチ実行アプリケーション52を有するバッチサーバである。このバッチ実行ルーチンまたはバッチ実行アプリケーション52は、ノード42a、42c、42d内のＢＯＩアプリケーション48のうちの一または複数と両方向通信を確立し、同時にプロセスプラント内の一または複数の別々のバッチを実行・監視する。同様に、クライアントノード44dは、キャンペインマネージャサーバアプリケーション54を有している。このキャンペインマネージャサーバアプリケーション54は、ＣＭＯＩアプリケーション50との両方向通信を確立し、（バッチ開始要求を用いて、）バッチサーバノード44a、44b、44c内のバッチ実行アプリケーション52とインターフェイスを介した接続するかまたは通信することにより、ＣＭＯＩアプリケーション50を用いて作成されたバッチキャンペインを実行する。図２のクライアント／サーバ機構は、より優れた障害許容を実現すべくサーバアプリケーションからクライアントアプリケーションを分離するために従来から用いられている。

バッチサーバノード44b内のバッチ実行アプリケーション52に関して例示されているように、バッチ実行アプリケーション52は、プロセスプラント16内で一または複数のバッチランを同時に実行すべくキャンペインマネージャサーバ54およびＢＯＩアプリケーション48により送信されたバッチ開始要求に応答する。いうまでもなく、バッチサーバ44bは、一または複数のコントローラ12に通信可能に接続されており、次いで、このコントローラ12は、たとえば図１に例示されているように、プロセスプラント内の一または複数のデバイス、ユニットなどと通信可能に接続されている。

図２のサーバ44bの拡大線図に関連して、公知のバッチ実行ルーチン52は、バッチ実行ロジック56と、（バッチラン１、バッチラン２、…、バッチランＮの符号のついた）有限の数の異なるバッチラン60を同時に実行すべくバッチ実行ロジック56により用いられるプロセス装置モデル58とを備えている。とくに、バッチ実行ロジック56は、ＢＯＩアプリケーション48のうちの一つを介してユーザにより命令されたとき、または内部に格納されているプロセス装置モデル58を用いてキャンペインマネージャサーバ54により命令されたときに、バッチラン60を作成・開始する。図２に例示されているように、バッチ実行ロジック56は、バッチ実行ロジック56と同一のアプリケーションプロセス空間内で異なるバッチラン60を作成・実行し、共有処理技術を用いてこれらの異なるバッチラン60の動作を監視する。バッチラン60の動作全般において、バッチ実行ロジック56は、しばしば、プロセス装置モデル58にアクセスしてそのバッチに利用可能な装置の割り出しなどを行ったり、一または複数のコントローラランタイムアプリケーション62と通信して、各バッチラン60の状態を監視し、そのバッチランの異なるフェイズを実行し、ユーザまたはオペレータにバッチラン60の状態についての情報を提供すべくクライアントノード42（または他のワークステーション）内のユーザインターフェイスまたは他のアプリケーションと通信したりする。

上述のように、バッチラン60のすべてが、同一のアプリケーションプロセス空間内の同一のアプリケーションの一部として、バッチ実行ロジック56により実行されるので、装置の故障、コントローラまたは個別の装置との通信不良、メモリまたは電力の異常などによりバッチラン60のうちのいずれかが障害を起こすと、バッチ実行ロジック56が故障または「停止」してしまい、このことにより、その他のバッチラン60の動作も中断してしまう。上述のように、このことは、動作不能時間を著しく増加し、バッチラン60の各々をオンライン状態に戻すためにオペレータの多大な労力を必要とし、プロセスプラントの材料および運転時間に損失をもたらしてしまう結果となる場合がある。同様に、バッチサーバ44bのオペレーティングソフトウェアにより課されるメモリ制限により、バッチ実行ロジックは、一度に（すなわち、同時に）実行できるバッチラン60の数Ｎを実質的に制限されている。この制限は、任意の所与の時間において何百ものバッチランを物理的にサポートする可能性がある大規模なプロセスプラントにおいて問題になりうる。

図３は、図２のクライアント／サーバネットワークと同様のクライアント／サーバネットワーク68を例示しているが（同様の構成要素は同一の参照番号を有している）、その違いは、バッチサーバ44が、バッチ実行エンジン70を格納・実行しており、このバッチ実行エンジン70が、従来のバッチ実行アプリケーション52に関する上記の問題の一部または全部を排除するように構成されている、という点にある。図３のバッチサーバ44bに対してとくに例示されているように、バッチサーバ44の各々は、バッチ実行エンジン70を格納するメモリ72と、同時に複数の異なるバッチランを作成・実行するためにプロセスプラントの運転中にバッチ実行エンジン70を実行するプロセッサ74とを備えている。

一般的にいえば、図４でさらに詳細に例示されるバッチ実行エンジン70は、新しいバッチ毎に調整される別々のアプリケーションプロセス空間（ＡＰＳ）において実行される別々のバッチプロセスを作成・分離独立させる。このようなバッチプロセスは、それぞれ、特定のバッチを実行する別々のアプリケーションとして独立して動作するが、他のバッチとプロセス装置の利用を調整するために、オペレータまたは他のユーザに対してステータスメッセージ、アラームメッセージ、および他のメッセージを送信するために、バッチ実行エンジン70と通信しうる。具体的には、図４に例示されているように、バッチ実行エンジン70は、第一の通信レイヤ80と、バッチ実行マネージャ82と、マスタ装置モデル84と、第二の通信レイヤ86とを備えている。第一の通信レイヤ80は、ＢＯＩアプリケーション48、ＣＭサーバ50、および／または、クライアントノード42のうちの一つ内の閲覧アプリケーションおよび表示アプリケーション如きその他の所望のアプリケーションとの通信を可能にするとともに、ユーザまたはオペレータにより、作成されるバッチが指定されプロセスプラント16内での実行されることを可能にするいかなる標準型の通信ルーチンまたは通信プログラムであってもよい。バッチ実行マネージャ82は、実行する異なるバッチのそれぞれに対して、別々のアプリケーションプロセス空間に、すなわち別々のプログラムまたはアプリケーションとして、別々のバッチプロセス90を作成・分離独立させるプログラム、ルーチン、または他のロジックである。マスタ装置モデル84は、バッチのさまざまなフェイズおよび操作において用いられる装置をたとえば選択するために、それらのバッチにより用いられるプラントの最新バージョンの装置モデルを格納する。第二の通信レイヤ86は、第一の通信レイヤ80と同一であってもよいが、バッチ実行エンジン70と現在実行されているさまざまなバッチプロセス90との間の通信を供する。もちろん、通信レイヤ86は、同一のプロセッサ上で実行される二つの異なるアプリケーション間の通信を供するいかなる所望のまたは公知の方法で実現されてもよい。

図４は、（バッチ実行ロジック１，バッチ実行ロジック２、…、バッチ実行ロジックＮの符号が付けられた）Ｎ個で一組のバッチプロセス90を例示している。バッチプロセス90の各々は、別々のアプリケーションプロセス空間（ＡＰＳ）に存在し、したがって、バッチ実行マネージャ82からおよび相互に分離したプログラムまたはアプリケーションとして、図３のプロセッサ74により処理される。バッチ実行マネージャ82は、通信レイヤ92、バッチ実行ロジック94、および装置モデル96を含むように、バッチプロセス90の各々を作成する。通信レイヤ92は、バッチ実行エンジン70のバッチ実行マネージャ82への通信を提供することにより、たとえば、バッチプロセス90により実行されているバッチに関するステータスメッセージまたはアラームメッセージを提供するために、プロセス装置問題を解決または調整するようにバッチ実行マネージャ82へ要求するために、またはバッチ実行マネージャ82による異なるバッチプロセス90の相互調整を可能にするために、特定のバッチプロセス90がバッチ実行マネージャ82からメッセージを受信し、またバッチ実行マネージャ82へメッセージを送信できるようする。さらに、通信レイヤ92は、バッチランを実現し、監視し、実行するために、コントローラ、フィールドデバイスなどの如きランタイム装置と通信する。このような通信は、バッチプロセス90と同一のまたは異なるサーバに格納・実行される（図３に例示されている）ランタイムサーバ97を介して行われる。もちろん、通信レイヤ92は、いかなる形態をとってもよいが、バッチサーバノード44とクライアントノード42との間およびバッチサーバノード44と（図１のコントローラ12の如き）ランタイムシステムとの間において、プロセスプラント16内で用いられる通信および通信ネットワークのタイプに依存することが一般的である。

装置モデル96は、バッチ実行マネージャ82によりバッチプロセス90が作成され、分離独立されたときに存在していたマスタ装置モデル84と同じマスタ装置モデル84の全てまたは関連部分の単なるコピーである。バッチ実行ロジック94は、特定の装置を用いて特定のバッチを実際に実行するロジックであり、その装置は、バッチプロセス90の作成時点で指定された特定のレシピを用いて、そのバッチの実行中に装置モデル96から選択されうる。また、バッチ実行ロジック94は、バッチを開始し、バッチの運転および進行状況を監視し、レシピによる呼び出しに応じて、バッチ中に用いられる装置、手続き、フェイズなどを指定する、バッチ実行ルーチン内で現在用いられるロジックと類似しうる。いうまでもなく、バッチ実行ロジック94は、単一のバッチまたはバッチランにその状態全てを通過させる補助をする機能と、異なるバッチプロセス90間における装置調整のためのバッチ実行マネージャ82との通信またはその他のバッチ間プロセス通信もしくはクライアント通信を行う機能とを有している。クライアント通信には、バッチプロセス90により実行されているバッチの動作中に生成されるアラーム、アラート、イベントなどの如きバッチステータス情報を送信することが含まれうる。もちろん、いかなる所望のバッチ実行ロジックを用いてもよい。

動作中に、ＢＯＩアプリケーション48またはキャンペインマネージャサーバ54がバッチ実行エンジン70にバッチを実現または作成するように命令すると、バッチ実行マネージャ82は、そのＢＯＩアプリケーション48またはキャンペインマネージャサーバ54により提供されるそのバッチについての情報を用いて、そのバッチに対してバッチプロセス90（たとえば、バッチプロセス90a）を作成する。バッチプロセス90aを作成するために、バッチ実行マネージャ82は、包括的なバッチロッジク（または、プログラミング）を有するバッチプロセスロッジクテンプレート98を格納・使用し、利用されるレシピ、手続き、装置などの如き、特定のバッチを実行するためにバッチロジックテンプレートにより用いられる特定のデータを指定するファイルまたは他のデータを用いて上記ロジックを変更またはインスタント化しうる。この間に、バッチ実行マネージャ82は、マスタ装置モデル84（またはその内の該当するすべての部分）をバッチプロセス90aにまたはその一部としてコピーしうる。いったん作成されると、バッチ実行マネージャ82は、任意の所望のまたは公知の方法で、バッチプロセス90aを分離独立させ、プロセッサ74（図３）により、単独のアプリケーションプロセス空間で、バッチプロセス90aが実行されるようにする。こうすることにより、バッチプロセス90aは、バッチ実行マネージャ82から独立した独立型アプリケーションとして動作する。

図４に例示されているように、バッチ実行マネージャ82は、実行される新しいバッチ毎に、異なるアプリケーションプロセス空間に異なるバッチプロセス90を作成する。いったん作成または分離独立されると、バッチプロセス90の各々は、それが作成されたバッチサーバのプロセッサ74により実行され、そのプロセッサ74上のその他のアプリケーションと同様に動作し、よって、そのプロセッサ74のメモリ領域および処理時間を共有する。いうまでもなく、各バッチプロセス90は、以上の説明のように、独自に動作し、障害を受けた場合であっても、必ずしも、バッチ実行マネージャ82またはその他のバッチプロセス90のうちのいずれかに影響を与えない。したがって、本明細書で記載したバッチ実行エンジン70は、異なるバッチランを、同一のプロセッサによりまたは同一のサーバ内でしかし別々のアプリケーションプロセス空間内で実行される別々のバッチプロセスに分離し、これより、それらのバッチランのうちの一つノバッチランへの障害がそのサーバ上で実行されているその他のバッチラン全部に障害を与えるまたはその他のバッチラン全部を停止させることを防いでいる。したがって、バッチプロセス90のうちの一つの障害（たとえば、ソフトウェア異常）が、必ずしも、その他のバッチプロセス90のうちのいずれかに障害を与えるというわけではなく、ほとんどの場合は、そのバッチ実行エンジン70にさえも障害を加えない。したがって、その障害は、プロセッサ74により実行されている単一のバッチランに隔離されることが一般的であり、プロセッサ74により実行されているバッチランの全てに伝搬されたりそれらのバッチラン全てに影響を与えたりしない。このことにより、バッチソフトウェア障害に関連する再スタート時間を著しく減少する。というのは、通常、一つのバッチを手動により再スタートする必要があるのみだからである。また、バッチを再スタートできずその材料を廃棄しなければならない場合、本明細書で記載されたバッチ障害分離機能により、その障害に起因するプロセスプラント時間および資源の損失量が減少する。

さらに、バッチプロセス90の各々は、そのバッチプロセスが終了するまで使用するそれ自体の装置モデルを格納しているので、バッチ実行エンジン70内のマスタ装置モデル84を、現在実行されているバッチランまたはバッチプロセス90の動作に影響を与えることなく任意の時間に変更または部分変更することができる。したがって、ユーザまたはオペレータは、現在実行中のバッチプロセス90の完了を待たずにまたバッチ実行エンジン70内の変更を行うべくプロセス90を停止または中断せずに、プラント内の状態の変化を反映するための特定の装置の追加または除去の如き変更を、バッチ実行エンジン70内のマスタ装置モデル84に対して行うことができる。

さらに、各バッチプロセスがバッチ実行エンジン70とは異なるアプリケーションプロセス空間内で実行されるので、バッチ実行エンジン70は、バッチサーバ44（図３）上で用いられるオペレーティングソフトウェアにより執行されるメモリ空間分配を侵害することなく、さらに多くのバッチランを実行することができる。というのは、新規に追加または作成されるバッチプロセス90の各々は、そのバッチプロセス90がいったん分離独立させられて独立して動作しだすと、バッチ実行エンジン82により使用されるメモリをおおきく増加しないからである。このおかげで、バッチ実行マネージャ82は、オペレーティングソフトエアにより課されるメモリ制約を侵害することなく、任意の単一用途に同時に実行するいかなる数のバッチプロセス90であっても効果的に作成することができる。

さらに、上述のように、図３の各バッチサーバ44はランタイムサーバ97を備えうる。このランタイムサーバ97は、バッチプロセスまたはバッチアプリケーション90の全てに対してランタイムインターフェイシングサービスおよびダウンロードサービスを提供し、プロセスプラント16内にバッチを作成して実行するために必要なセキュリティ情報、装置階層化情報、レシピ情報、およびコントローラ情報またはプロセスプラント情報の如き情報を提供しうる。同様に、ランタイムサーバ97は、図１のバッチプロセス90とコントローラ12との間の通信インターフェイスを提供してバッチプロセス90とコントローラ12との通信を可能にし、それにより、プロセスプラント16内のバッチを開始し、監視し、制御しうる。所望ならば、ランタイムサーバ97は、バッチ実行エンジン70内のマスタ装置モデル84の装置モデルの変更を部分的にダウンロードできるようにしてもよいし、また、さまざまなバッチ実行ノード44間においてそれらの調整を可能にすることによりノード44の異なるノードで実行されるバッチプロセス90が相互に調整できるようにし、相互ノード装置調整を実現するために利用されてもよい。

いうまでもなく、本明細書で記載されたバッチ実行エンジン機構により、所与のどの時間においても、一から数百までの数またはそれを超える数の異なるバッチプロセスを同時に実行でき、その時点において実行されているバッチプロセスのうちのいずれかにソフトウェア障害が発生しても、その他のバッチプロセスのうちのいずれかのバッチプロセスの実行またはバッチ実行マネージャの実行に対する影響を減少または防止できる。さらに、このバッチ実行エンジン機構により、再スタートに必要な時間を著しく削減しうる。というのは、ソフトウェア障害が発生した場合に手動で再スタートする必要があるのが、通常、全てのバッチランではなく単一のバッチラン（ソフトウェア障害を引き起こしたバチラン）のみであるからである。また、このバッチ実行エンジン機構により、バッチ実行エンジン内の装置モデルを、その時点で実行されているさまざまなバッチランを停止または中断することなく変更できる。各バッチプロセスがその独自のアプリケーションプロセス空間内で動作しているので、オペレーティングソフトエアが単一のアプリケーションによりアドレス指定可能な物理メモリまたは仮想メモリの量に制限を課していることによって、単一のバッチ実行エンジンが同時に実行しうるバッチ数が実質的に制限を受けることはない。したがって、プロセスプラントにおいて任意の所与の時間に実行しうる同時バッチランを分離するためまたはそれらの数を増やすために、同一のまたは異なるサーバ内に別々のアプリケーションエンジンを作成する必要性はないかまたは少ない。

いうまでもなく、本明細書で記載されたバッチ実行エンジンアプリケーション、ＢＯＩアプリケーション，ＣＭＯＩアプリケーション、キャンペインマネージャサーバアプリケーションの如きバッチルーチンは、いかなる所望のプロセスプラント制御プログラミング環境内で用いられても実現されてもよく、いかなる所望のタイプのプロセスプラント制御通信プロトコルを用いるいかなるプロセスプラント制御システムで用いられてもよく、さらに、いかなるタイプのデバイスまたはデバイスのサブユニットに対していかなる機能を実行するために用いられてもよい。本明細書で記載されたバッチルーチンは、たとえばサーバ、ワークステーション、または他のコンピュータに格納されるソフトウェアにより実現されることが好ましいが、所望ならば、それに代えてまたはそれに加えて、これらのルーチンは、ハードウェア、ファームウェア、特定用途集積回路、プログラマブルロジック回路などにより実現されてもよい。ソフトウェアにより実現される場合、これらのバッチルーチンは、磁気ディスク、レーザディスク、または他の格納媒体、コンピュータ、コントローラ、フィールドデバイスなどのＲＡＭまたはＲＯＭなどの如きいかなるコンピュータ読み取り可能メモリに格納されてもよい。同様に、このソフトウェアは、たとえば、電話回線、インターネットなどの如き通信チャネル、コンピュータ読み取り可能ディスクなどの如き伝達可能媒体を含むいかなる公知のまたは所望の搬送方法を用いて、ユーザまたはデバイスに搬送されてもよい。

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

化学プロセス、石油プロセスなどのプロセスプラント用のプロセス制御システムに利用することができる。

バッチ実行エンジンが同時にバッチプロセステムを実行しうるプロセス制御ネットワークの一部分の部分ブロック線図および部分略式線図である。 別々のバッチプロセスを利用せずにプロセスプラント内で付く数のバッチを実行すべく用いられる従来のバッチ実行アプリケーションを備えるコンピュータネットワークを示すブロック線図である。 各々がプロセスプラント内で異なるバッチを実行すべく用いられる異なるバッチを作成するバッチ実行マネージャを有するバッチ実行エンジンを備えているコンピュータネットワークを示すブロック線図である。 さまざまなアプリケーションプロセス空間に、別々のバッチプロセスを作成または分離独立させ、プロセスプラント内で同時にバッチを実行する図３のバッチ実行エンジンを示すブロック線図である。

符号の説明

12 コントローラ
14 ワークステーション
30、70 バッチ実行エンジン
82 バッチ実行マネージャ
86 通信レイヤ

Claims (26)

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. 前記バッチステータスデータが、前記プロセス内で実行されるバッチの動作中に生成されるアラームデータである請求項２５記載の方法。

Images