JP5613098B2 - バッチプロセスキャンペーン編集方法、バッチプロセスキャンペーン編集システム。 - Google Patents

Description

本発明は一般的にプロセスコントロールシステムに関するものであり、より詳細に述べると、プロセスコントロールシステムによるバッチプロセスキャンペーンの作成および実行を監督管理するキャンペーン管理手法に関するものである。

例えば、薬品、ケミカル、飲料、塗料、もしくはその他製品の量産に用いられるバッチプロセス手法のようなプロセスコントロールシステムは、通常一つもしくはそれ以上の中央に集約されたプロセスコントローラを含み、それらは一つもしくはそれ以上のフィールドデバイス、例えば、バルブポジショナー、スイッチ、センサー（例えば、温度、圧力、流速センサー）などと通信で接続されている。これらのフィールドデバイスは、例えばバルブ、ポンプ、ミキシングユニットなどのコントロール装置と接続されており、物理的な制御機能（バルブの開閉、ポンプおよびミキシングユニットのオン・オフなど）をプロセスコントロールシステム内で実行し、プロセスの働きを制御するためプロセスコントロールシステム内で測定をし、もしくは要求されるその他の機能をプロセスコントロールシステム内で実行する。一般的に言えば、プロセスコントローラは、一つもしくはそれ以上のフィールドデバイスによって測定されたシグナルおよび／またはそのフィールドデバイスに関係するその他の情報を受信し、この情報を用いて通常複雑なコントロールルーチンを履行し、制御信号をシグナルラインもしくはバスを通じてフィールドデバイスに伝送し、プロセスコントロールシステムの働きを制御している。

また、プロセスコントローラは通常イーサネット（登録商標）バスのようなデータハイウェイを通して、一つもしくはそれ以上のワークステーションおよびその他のデバイスとつながっている。これらその他のデバイスは通常一つもしくはそれ以上のプロセスコントローラからの情報をもとに、その他のアプリケーションおよびプログラムを起動させその他のプロセス制御機能を果たす。それらは、コントロールルーチンへのユーザインタフェースの機能、コントロールルーチンの変更および更新、フィールドデバイスとのインタフェースの連結、過去のプロセス制御データの蓄積、ユーザアクセスの制御もしくは制限などである。ある大きなプロセスコントロールシステムでは、一つもしくはそれ以上の遠隔地にあるワークステーションがインターネット接続、サテライトもしくはセルラー通信接続、無線接続（無線イーサネット（登録商標）接続に用いられているような）などの通信ネットワークによりデータハイウェイに接続されている。

何バッチもの製品を生産するプロセスコントロールシステムにおいては、通常グラフィカルインタフェースを通じてユーザ (例えば、エンジニア）が一つもしくはそれ以上の基本製品製法、バッチパラメータ、装置リストなどを定義および保存出来る。これらの基本製品製法は一組のプロセスステップを含み、それぞれのプロセスステップは特定の装置リストに関連もしくは接続されている。製法プロセスステップを特定の装置に接続させる際、ユーザ（例えば、オペレータ）が明白に、その製法のバッチの実行以前に、どのプロセスコントロール装置を、それぞれの製法プロセスステップを実行する上で使用するか定義する。さらに、それぞれのプロセスステップは、バッチ実行中の装置の作動の順番および／またはタイミングを制御し、アラームリミットを設定し、目標制御値（例えば、セットポイント）などを設定するのに必要な一つもしくはそれ以上の入出力（Ｉ／Ｏ）バッチパラメータ値の設定をユーザ（例えば、オペレータ）に要求する。これらの入出力パラメータ値はプロセスコントロールシステム内の一つもしくはそれ以上のフィールドデバイスに送受信される入出力に関連し、そうでなければプロセスコントロールシステムによってバッチの実行中の中間値もしくは計算値である。故に、バッチを定義するに当たって、ユーザ（例えば、オペレータ）は通常グラフィカルインタフェースを通じて基本製品製法を選定し（それは製法内のプロセスステップをプロセスコントロール装置と接続する仕様を含む）、そしてバッチの実行中に必要なパラメータ値を特定する。例えば、何バッチもの塗料を生産するコントロールシステムにおいては、ユーザ（例えば、オペレータ）はグラフィカルインタフェースを通じて、例えば、半光沢仕上げの外壁用水性塗料の基本塗料製法を選定し、特定の色の半光沢仕上げの外壁用水性塗料を１００ガロン生産するパラメータ値を設定する。

例証としては、基本塗料製法は基本塗料混合物に着色剤もしくはその他の物質を加える一つもしくはそれ以上のプロセスステップを含み、また、さらにこれらの着色剤とその他の物質を基本塗料混合物中で機械的に撹拌する追加のプロセスステップを含む。撹拌およびミキシングプロセスステップもしくはその他の基本塗料製法に関連しているプロセスステップはプロセスコントロールシステム内の特定の装置に接続されている。例えば、第一番目のミキシングステップは第一番目の撹拌機に、第二番目のミキシングステップは第二番目の撹拌機に接続され、もしくは必要があればそれに替えて第二番目のミキシングステップは第一番目の撹拌機に接続される。同様に、着色剤を塗料混合物に加える基本塗料製法のそれぞれのプロセスステップは特定の着色剤分配装置に接続されている。

さらに、バッチを定義する際に、ユーザはバッチの実行時にプロセスコントロールシステムによって用いられる撹拌時間および着色剤の量など多種のＩ／Ｏパラメータ値を設定し、それによって、欲しい最終塗料製品を生産するためにバッチにより特定されたプロセスステップを実行する。故に、従来のバッチ定義手法で、ユーザは多種の色（Ｉ／Ｏパラメータ値で特定出来る）および多種の基本塗料タイプ（基本塗料製法で特定出来る）を含む多種の最終塗料製品を生産することが出来る。もちろん、従来のバッチ定義手法は、例えば、薬品、飲料品、食料品など、その他たくさんの製品を生産するのにも使うことが出来るので、特定のプロセスステップ、そのプロセスステップに接続された装置、そしてＩ／Ｏパラメータ値を変えることによりプロセスコントロールシステムは要求されている最終製品を生産することが出来る。

プロダクションキャンペーンはバッチ仕様のプロセスコントロールシステムの実行効率をあげるための手法としてよく知られている。伝統的には、プロダクションキャンペーンとは同じバッチを繰り返し実行するように特定することである。ある従来のバッチ仕様のプロセスコントロールシステムにおいては、ユーザが手作業で一つのバッチを複数回入力することにより一つのプロダクションキャンペーンを作成することが出来る。例えば、もしユーザが２０バッチの特定された塗料製法を含むキャンペーンを作成したい場合は、ユーザは同じ製法とパラメータ値を特定するのに、２０回も同じバッチ定義のためにインタフェースを通じて入力しなければならない。もちろん、そのようなキャンペーンを作成するため、繰り返しバッチを定義するには、ユーザは非常に多くのデータ量の入力を要求される。それ故、ユーザがバッチを一度定義し、そしてキャンペーンを終了までのバッチの繰り返し実行回数を特定するだけですむいくつかのバッチ定義インタフェース等も開発されてきている。

とにかく、従来のプロダクションキャンペーンの作成手法は相対的に柔軟性に欠ける。と言うのは、それらが一般的にユーザに違ったタイプのバッチを含むキャンペーンの作成を許さないからである。言いかえれば、従来のプロダクションキャンペーン作成手法では、ユーザは通常同じバッチを含むキャンペーンしか作成することが出来ない。さらに、プロダクションキャンペーンを作成し実行する従来の手法は、通常、プロセスコントロールシステムのバッチ定義および実行機能としっかりとは統合されておらず、また、これら従来のキャンペーンの作成および実行する手法は、例えば、セキュリティ機能（例えば、ユーザアクセスコントロール）、データヒストリアン機能などのような他のプロセスコントロール機能ともしっかりとは統合されていない。事実、セキュリティ機能、データヒストリアン機能、そしてプロセスコントロールシステム内にあるその他の機能は、バッチ定義および実行機能に用いられるデータベースに保存されているバッチに関する情報に通常はアクセス出来ない。その結果、ユーザは手作業で非常に多くのデータを入力することにより、キャンペーンの作成および実行するプロセスを統合したいそれぞれのプロセスコントロールシステム機能内に、別のバッチ情報データベースを作成しなければならない。残念なことに、手作業による別のバッチ情報データベースの作成および維持には、例えばもしどれか一つのデータベースにおいて、製法、バッチパラメータもしくはそのバッチに関連する情報に変更がなされた場合でも、データベース間の同期性（データベース間の情報に矛盾がないこと）を忘れないことがユーザに要求される。

さらに、従来のキャンペーンの作成および実行手法は、しばしばバッチ実行メモリおよびプロセス資源の非効率的な使用の結果につながる。例えば、ある従来のキャンペーン作成手法では、ユーザは、多くのバッチ作成および実証を、一度に一バッチづつ、バッチ定義機能を通じて行っている。現実問題として、この従来のキャンペーン作成手法を用いる時、ユーザは通常、いずれかのバッチが実行を終了しているかいないかに関わらず、また、これら実証済のバッチの一つ以上を実行出来る装置のあるなしに関わらず、キャンペーン内の全ての必要なバッチを作成および実証する。その結果、実証がすみ実行を待っている多くのバッチは不必要にメモリとプロセス資源を消費していることになる。

他の従来のキャンペーン作成手法では、ユーザは、まず一つのバッチをバッチ定義機能を通じて作成および実証し、その後キャンペーン作成および実行機能を通じて、その定義されたバッチをキャンペーン実行機能によって繰り返し実行される回数を特定することが出来る。

さらに、従来のキャンペーン作成および実行手法では、一度キャンペーンがバッチ実行機能内で作成および実証されてしまったなら、もしくは、バッチ実行機能にリリースされてしまったならば、ユーザがそのキャンペーンに相当量の変化を加えることは通常許されない。例えば、ある従来のプロセスコントロールシステムでは、ユーザにキャンペーンの実行中であってもパラメータ値の多少の変化を加えることを許すが、これらの従来のシステムは通常ユーザが実行されているキャンペーン内の所定のバッチがどの製法を使用するかを変えることは許さないし、これらの従来のシステムは、一度キャンペーンが作成および実証されてしまった後は、ユーザがバッチ実行機能の中で異なった装置をプロセスステップに接続することは許されない。

キャンペーン管理手法はプロセスコントロールシステムにしっかりと統合されており、プロセスコントロールシステムによるバッチプロセスキャンペーンの作成および実行の監督管理機能を果たす。一般的に言えば、ここに書かれているキャンペーン管理手法はバッチ定義および実行機能の上位に位置し、しっかりと統合する高度の監督機能を果たす。キャンペーン管理手法はまた、バッチヒストリアン機能および／またはセキュリティ機能（例えば、ユーザアクセス管理）、もしくはその他のプロセスコントロールシステム機能のようなその他のバッチに関係する機能もしっかりと統合している。

本発明の一つの側面は、バッチ作成機能にバッチ情報を要求する第一番目のメッセージを送信し、そしてバッチ情報要求の第一番目のメッセージの返信として、一組のバッチ情報を含む第二番目のメッセージを受信するバッチプロセスキャンペーンの作成システムおよび方法である。前記システムおよび方法は、グラフィカルユーザインタフェースを通じて一組のバッチ情報を表示し、複数のバッチの中の少なくとも一つのバッチに含めるべき、表示された一組のバッチ情報のサブセットを特定した第一番目の入力をユーザに促す。さらに、前記方式および方法は、バッチプロセスキャンペーンに含めるべきキャンペーン情報を特定する第二番目の入力をユーザに促し、第一番目と第二番目の入力を用いてバッチプロセスキャンペーンを作成する。

本発明の他の側面によれば、バッチプロセスを実行する前記方式および方法は、バッチプロセスキャンペーンに関連するバッチ実行モードを決め、複数のバッチから一つもしくはそれ以上のバッチをバッチ実行モードに基づいてバッチ実行機能にリリースする。前記方式および方法はまたメッセージをバッチ実行機能に送信し、バッチ実行機能が一つもしくはそれ以上のリリースされたバッチを実行する。

本発明のもう一つ他の側面によれば、バッチプロセスキャンペーンを編集する前記方式および方法は、グラフィカルユーザインタフェースを通じて、バッチプロセスキャンペーンから一つもしくはそれ以上の非リリースのバッチを特定する第一番目の入力をユーザに促す。もっと言えば、前記方式および方法は、グラフィカルユーザインタフェースを通じて、特定された一つもしくはそれ以上の非リリースのバッチに付属するバッチ情報の変更を特定する第二番目の入力をユーザに促し、そのバッチ情報の変更をバッチプロセスキャンペーンと共に記憶装置に保存する。ここで、一つもしくはそれ以上の非リリースのバッチの内の第一番目のバッチは、その一つもしくはそれ以上の非リリースのバッチの内の第二番目のバッチとは異なる一組の運転パラメータを含む。

図１はバッチプロセスキャンペーン作成および実行を監督制御するキャンペーン管理手法を用いるプロセスコントロールシステムの略ブロック図である。 図２は図１のサーバによって実行されるキャンペーン管理手法がどのようにその他のプロセス管理機能としっかりと統合されているかを示す、代表的な略ブロック図である。 図３は図２のグラフィカルユーザインタフェースによって与えられるキャンペーンリストの代表的な図である。 図４は図３のキャンペーンリストに新規のキャンペーンを作成し付け加えることを可能にしてくれるキャンペーン作成ダイアログウインドウの代表的な図である。 図５はユーザが図４の”クリエイトキャンペーン”ウインドウ（キャンペーン作成ウインドウ）内のセレクトボタンを押した時に表示されるセレクト製法ウインドウ（製法選択ウインドウ）の代表的な図である。 図６はユーザが図５の”ビューパラメータ”ボタンを選択すると表示されるセレクト製法ウインドウの代表的な図である。 図７はユーザにキャンペーン内のバッチが図２のバッチエグゼクティブによってリリースまたは開始される方法を選択または最適化することを可能にしているバッチキャンペーンプロパティウインドウの代表的な図である。 図８は図２のキャンペーン実行機能とバッチ実行エンジンがオートスタートバッチ実行モードを使ってどのように相互扶助してバッチプロセスキャンペーンを実行するのかを説明する代表的な工程系統図である。 図９はユーザがキャンペーン内の一つもしくはそれ以上のバッチを編集することを可能にするバッチ編集ウインドウの代表的な図である。 図１０は図９のバッチ編集ウインドウで変更されたバッチを表示しているウインドウの代表的な図である。

１０ プロセスコントロールシステム
１２,１４ ワークステーション
１６ サーバ
３２,３３,３４ クライアント
３６,３８ コントローラ
４０,４２,４４,４６,４８,５０,６０ フィールドデバイス
６２ ミキシングタンク
６４ 第一番目の撹拌機
６６ 第一番目の着色剤分配器
６８ 第二番目の着色剤分配器
７０ 第二番目の撹拌機

ここでは、キャンペーン管理手法は、塗料を生産するプロセスコントロールシステムとの関連付けで説明されているが、例えば、薬品、ケミカル、食料品、消費財もしくはその他の製品を生産するプロセスコントロールシステムを含む多種のバッチ仕様のプロセスコントロールシステム内においても、ここで説明されているキャンペーン管理手法は有効に利用出来るということを周知しておくべきである。前記キャンペーン管理手法をより詳細に説明する前に、バッチ定義および実行機能によって使用されるデータベースに含まれる情報へのアクセスは、従来のキャンペーン作成および実行手法では通常許可されていないということを認識しておくことは大切である。その代わりに、これらの従来の手法は、キャンペーン作成および実行機能と情報伝送して欲しいそれぞれのプロセスコントロール機能内に、バッチ情報データベースを再作成することをユーザに要求する。さらに、これらの従来のキャンペーン作成および実行手法は、どの一つのバッチ情報データベース内で変更がなされた時でも、手作業で全てのバッチ情報データベースの更新を必ず行うことをユーザに要求する。言いかえれば、ユーザは通常大きなバッチ情報データベースを何回も更新し、そして手作業でこれら複数のバッチ情報データベースの同期の維持に多大なる努力を払わなければならない。そうすることにより、あるキャンペーン作成機能で作られ、あるバッチデータベースを使用しているキャンペーンが、他の異なったバッチデータベースを使用しているバッチ実行機能により実行させられた時にも適切に作動する。

さらに、従来のキャンペーン作成および実行手法では、通常ユーザは一度キャンペーンの実行が開始すれば、キャンペーンのどの部分をも編集することは出来ない。その結果、キャンペーンの実行中に使用されていた装置が壊れた時、ユーザは全てのキャンペーンの実行を止め、そして代わりの機能する装置を使うように新しいキャンペーンを作成することによりその状況を改善していくことしか出来ない。同様に、もしユーザがキャンペーン内の特定のバッチに関連している製法を変更したい時（例えば、顧客の要望の変更に応えるため）、ユーザはまた全てのキャンペーンを停止して、要求されるタイプのバッチを特定する新しいキャンペーンを作成しなければならない。

図1はキャンペーン管理手法を用いてバッチプロセスキャンペーンの作成および実行を監督管理するのに用いられるプロセスコントロールシステム１０の略ブロック図である。特に、例証として、前記プロセスコントロールシステム１０は何バッチもの塗料を生産するように構成されている。しかし、何バッチもの薬品、ケミカル、食料品、もしくはその他の製品を生産するのにも、ここに述べられているキャンペーン管理手法は、プロセスコントロールシステム内で有効に使用することが出来るということを理解しておくべきである。プロセスコントロールシステム１０はワークステーション１２と１４およびサーバ１６を含み、それらはイーサネット（登録商標）もしくはその他のデータの伝送に適したデータバスなどのシステムレベルデータバス１８で通信接続されている。ワークステーション１２と１４は多種の知られているプロセスコントロール機能を果たす。例えば、ワークステーション１２は、メモリ２１に記憶されているルーチン２０を含み、プロセッサ２２よって起動され、セキュリティ機能を果たす。このセキュリティ機能はプロセスコントロールシステム１０内にあるその他の機能および情報へのユーザのアクセスを制御する。同様に、ワークステーション１４は、メモリ２５に記憶されているルーチン２３と２４を含み、プロセッサ２６により起動され、データヒストリアンおよびバッチ実行機能をそれぞれ果たしている。サーバ１６はプロセッサ２７を持つワークステーションであり、メモリ３０に記憶されている一つもしくはそれ以上のソフトウェアルーチン２８を実行し、ここに述べられているキャンペーン管理手法を実行する。サーバ１６は、システムレベルデータバス１８もしくはその代わりにその他の適切なコミュニケーション接続、例えば衛星ベースの無線接続、モデム接続などを通じて、クライアント３２と３４と情報を伝送する。同様に、サーバ１６は、またイーサネット（登録商標）もしくはその他の適したデータバスであるデータバス３５を通じて、他のノードもしくはシステムにあるクライアント３３と通信する。クライアント３２−３４は、ワークステーション、携帯型情報機器、ラップトップコンピュータなど、サーバ１６と通信出来るどのようなタイプのハードウェアプラットホーム上でも起動させられる。もちろん、データ記憶デバイス、追加のユーザインタフェース（図示せず）などのその他のデバイスも、システムレベルデータバス１８および／またはその他のノードもしくはシステムにつながっているデータバス３５に接続させられる。

プロセスコントロールシステム１０は第一番目および第二番目コントローラ３６と３８を含み、それらはDCSタイプコントローラもしくはその他のタイプのコントローラであり、それらは独占権を持つ通信プロトコルもしくはその他の適した通信プロトコルを用いてシステムレベルデータバス１８に通信接続される。コントローラ３６と３８は、第一番目と第二番目入出力（Ｉ／Ｏ)デバイス５２と５４とそしてコントローラデータバス５６と５８とを通じて、それぞれフィールドデバイス４０−４４および４６−５０と通信する。図１に示されたように、フィールドデバイス４０−５０はスマートフィールドデバイスであり、プロセスコントロールシステム１０に関する情報を、メッセージをコントローラデータバス５６と５８を通じて送信することにより伝送する。よく知られているように、スマートフィールドデバイスはコントローラと接続もしくは独立して、一つもしくはそれ以上のプロセスコントロールループを実行する。スマートフィールドデバイス４０−５０は、例えば、フィールドバスデバイスであるかもしれない。その場合、コントローラデータバス５６と５８はフィールドバス信号プロトコルを用いた独占権を持たないプロトコルデータバスである。しかし、その他のデバイスおよびプロトコル、例えば、HART、PROFIBUS、WORLDFIP、Device-Net、CAN、そしてAS-Interfaceプロトコルも同様に用いることが出来る。さらに、コントローラ３６と３８は直接従来の（例えば、非スマート）フィールドデバイス（例えば、４−２０ｍＡもしくは０−１０ＶＤＣのような従来のアナログ接続端子を持つフィールドデバイス）に接続される。例えば、図１に示されているように、第一番目のコントローラ３６は従来の非スマートフィールドデバイス６０に接続されている。

フィールドデバイス４０−５０そして６０は装置６２−７０に接続されている。特に、非スマートフィールドデバイス６０はミキシングタンク６２に、フィールドデバイス４０と４２は第一番目の撹絆機６４に、フィールドデバイス４４は第一番目の着色剤分配器６６に、フィールドデバイス４６と４８は第二番目の撹絆機７０に、フィールドデバイス５０は第二番目の着色剤分配器６８にそれぞれ接続されている。図1には示されていないが、プロセスコントロール１０は追加のコントローラ、フィールドデバイス、そして装置を何バッチもの塗料の生産に必要であれば含められる。

図２は代表的な略ブロック図１００であり、図1のサーバ１６により実行されたキャンペーン管理手法が、図1に示されているプロセスコントロール１００のその他のプロセスコントロール機能とどのようにしっかりと連結されているか示している。ここに述べられているキャンペーン管理手法は、キャンペーン作成機能１１１、キャンペーン実行機能１１２、キャンペーン編集機能１１３、そして記憶装置を持つキャンペーンマネジャー１１０によって実行される。一般的に言えば、キャンペーン作成機能１１１はバッチプロセスキャンペーンの作成を監督管理し、キャンペーン実行機能１１２はバッチ実行のためのリリースを管理し、キャンペーン編集機能１１３はユーザが非リリースのバッチの急ぎの編集をするのを可能にし、装置の故障および顧客の注文の最終時点における変更などに柔軟に対応することが出来るようになっている。キャンペーンマネジャー１１０はメッセージおよびその他の情報をプロセスコントロールシステム１０内のその他の機能と交換する。特に、キャンペーンマネジャー１１０はグラフィカルユーザインタフェースを通じてユーザから入力および指令を受け取り、バッチエグゼクティブ１３０、セキュリティシステム１４０、そしてバッチヒストリアン１５０に伝送する。さらに、図２に示されているように、バッチエグゼクティブ１３０はバッチ実行メッセージをバッチヒストリアン１５０に送信しそしてセキュリティシステム１４０と交信する。

バッチエグゼクティブ１３０、セキュリティシステム１４０、そしてバッチヒストリアン１５０はよく知られたプロセスコントロール機能である。特に、バッチエグゼクティブ１３０は定義／実証機能１６０、実行エンジン１７０、そしてデータベース１８０を持っている。バッチエグゼクティブ１３０はサーバ１４上にあり、そうでなければ、プロセスコントロールシステム１０内の他のノードまたはシステム、例えばワークステーション１２もしくはサーバ１６上にあってもよい。バッチエグゼクティブ１３０は、例えばFisher‐Rosemount Systems Inc. が出しているDeltaＶTM Batch Executiveのような、バッチを実行させるための製法、装置リスト、バッチパラメータなどをユーザに定義させ、そしてバッチプロセスを実行出来るようにバッチを定義（例えば、作成）および実行させられるどのようなシステムであってもかまわない。製法の作成においては、定義／実証機能１６０は、グラフィカルインタフェースをユーザに提供し、例えばそれによってユーザが製法のプロセスステップとそれぞれのプロセスステップにおいて用いられる装置などを特定することが出来る。ユーザはこれらの仕様をキーボードから入力してもよいし、異なった方法もしくは追加方法として、アイコン、プルダウンメニュー、もしくは従来のグラフィカルユーザインタフェース手法を用いたポイントおよびクリックのマウス操作によって入力してもよい。さらに、定義／実証機能１６０では、バッチ内の所定の製法を実行する際に用いられる特定のパラメータ値をユーザが指定することにより、そのバッチをより特定することが出来る。

データベース１８０は、詳細な製法情報、装置の空き情報とプロファイル、接続情報、バッチ実行状況情報などのバッチ定義および実行情報を記憶している。定義／実証機能１６０を用いて作成されたバッチに関する情報（例えば、製法そしてバッチパラメータ値など）は、そのバッチの実行中に、実行エンジン１７０によって参照出来るように、また、詳細は後ほど説明するが、キャンペーンの作成および実行中に、キャンペーンマネジャー１１０およびグラフィカルユーザインタフェースによって参照出来るように、データベース１８０の中に記憶されている。

キャンペーンマネジャー１１０は、別のバッチ情報データベースをキャンペーン管理機能内に持たないし、ユーザに持つことも要求しない。その反対に、キャンペーンマネジャー１１０はサーバ１６内において、例えば、メッセージ（例えば、要求）をシステムレベルデータバス１８を通じてバッチエグゼクティブ１３０（例えば、ワークステーション１４において）に送信し、キャンペーンを作成し実行するのに必要なバッチに関する情報をデータベース１８０（例えば、メモリ２５に記憶されている）から取り出すように依頼することが出来る。故に、キャンペーンマネジャー１１０とバッチエグゼクティブ１３０は一つのバッチ情報の保存貯蔵庫を共有し、それが故に、従来のキャンペーン作成および実行手法と違って、ユーザはいくつものデータベース１８０のコピーを作り保管維持（例えば、同期）する必要がない。

バッチ実行エンジン１７０は、キャンペーン実行機能１１２が実行するためにリリースするバッチの受諾および実証をする。キャンペーンの実行中に、バッチ実行エンジン１７０は装置の調整を担い、バッチ実行状況の情報、装置の空き状態などのメッセージをキャンペーン実行機能およびバッチヒストリアン１５０に送信する。特に、バッチ実行エンジン１７０は、一つもしくはそれ以上のスマートフィールドデバイス４０−５０に適切な手続きを開始するために、メッセージを一つもしくは両方のコントローラ３６および３８に送受信し、そして、バッチ実行エンジン１７０により現在実行させられているバッチに関連するプロセスステップを実行するために、適切なメッセージ・シグナルを一つもしくはそれ以上のフィールドデバイス４０−５０および６０と送受信する。

キャンペーン作成機能１１１、キャンペーン実行機能１１２、そしてキャンペーン編集機能１１３は、ユーザがバッチプロセスキャンペーンを作成および実行出来るよう、グラフィカルユーザインタフェースと連動してはたらく。特に、キャンペーン作成機能１１１は、ユーザが多数のタイプのバッチを含むキャンペーンを柔軟に作成出来るようにし、また、バッチエグゼクティブ１３０に関連するメモリおよびプロセス資源をより一層有効に利用出来るように、バッチエグゼクティブ１３０へのバッチのリリースの制御を司っている複数の操作モードからのユーザの選択を可能にしている。

グラフィカルユーザインタフェース１２０は、例えば、WindowsTM（登録商標）の操作環境を用いて実行することが出来、それ故、バッチプロセスキャンペーンの作成、キャンペーン状況の監視、キャンペーンの編集などを容易にするための多種のプルダウンメニュー、アイコン、そしてその他のグラフィックス機能などを含んでいる。グラフィカルユーザインタフェース１２０はクライアント３２−３４上で、もしくは代わって、プロセスコントロールシステム１０内のどのノード、もしくはシステム上のどのクライアント上でも、起動出来ることを知っておくべきである。さらに、グラフィカルユーザインタフェース１２０は、事実上、例えば、携帯型情報機器、バーコードスキャナー、ラップトップ、パームトップなどを含むどのようなハードウェアプラットホーム上においても基礎を置くことが出来、そして、キャンペーンマネジャー１１０とシステムレベルデータバス１８、もしくはその他の有線もしくは無線通信接続（例えば、移動電話接続、衛星接続など）を通じて通信していることを知っておくべきである。

図３はキャンペーン作成機能１１１を用いてユーザが作成および定義したキャンペーンのリスト２０５を含み、グラフィカルユーザインタフェース１２０よって表示されたキャンペーンリストスクリーン２００を例示している。

ヘッダー２０７はリスト２０５内のそれぞれのキャンペーンをより詳細に説明する多くのフィールドを含んでいる。キャンペーンフィールド２１０は、キャンペーンの作成、編集、もしくは実行中にキャンペーンを識別するためにキャンペーンマネジャー１１０によって使用され、ユーザによって定義されたキャンペーン名を含んでいる。プロセスコントロールシステム１０内の、例えば、バッチエグゼクティブ１３０、セキュリティシステム１４０、そしてバッチヒストリアン１５０、もしくはその他のユーザインタフェースまたはシステムのような他のプロセス管理機能により現在、作成、編集、または実行されているキャンペーンを識別するのに、キャンペーン名はプロセスコントロールシステム１０の全域で使用することが出来る。実行モードフィールド２２０はユーザがどの実行モードを選択したのかを示している。後ほどもっと詳しく説明するように、ユーザは複数のバッチ実行モード、例えば手動、自動リリース、そして自動スタートモードなどから選択することが出来る。その一つ一つは、バッチエグゼクティブ１３０内のプロセスおよびメモリ資源をもっと有効に活用するために、バッチエグゼクティブ１３０へのバッチのリリースを制御するためにキャンペーン機能１１２によって用いられている。状況フィールド２３０は、バッチは定義され実行された（”完了”）のか、現在活動しているのか、もしくはバッチは定義されただけでまだバッチエグゼクティブ１３０によって実行されていないのかを表示する。基本製法フィールド２４０はどの基本製法がバッチの定義に用られたのかを表示する。図３に表示されている代表的なリストスクリーン２００の中のリスト２０５内の全てのキャンペーンは、基本製法フィールド２４０内の”EXT-ENAMEL-STRG"と表示されている外壁用エナメル塗料のための基本製法に基づいている。バッチカウントフィールド２５０は、リスト２０５内のそれぞれのキャンペーンに幾つのバッチ数があるのかを示し、クリエイティドバイフィールド２６０はどのユーザがどのキャンペーンを作成したのかを表示している。

図４は図３に表示されているキャンペーンリスト２０５に新しいキャンペーンを作成および付け加えるのに使える代表的なキャンペーン作成ダイアログウインドウ３００を表示している。一般的に言えば、ダイアログウインドウ３００は、キャンペーンを作成する時に、必要な情報をグラフィカルエントリーブロックを通じて入力する様にユーザを促す。もちろん、その他のユーザに情報の入力を促す手法、例えば、文字による質問なども用いることが出来る。特に、キャンペーンネームブロック３０５はユーザに文字および数字の両方を使うことを認めており、それらは、作成されるキャンペーンに関連して、プロセスコントロールシステム１０の中のキャンペーンマネジャー１１０、バッチエグゼクティブ１３０、そしてその他のプロセス管理機能によって利用される。バッチ数ブロック３１０は作成されるキャンペーン内に含むバッチの数をユーザが入力することを可能にし、マキシマムアクティブバッチブロック３１５はバッチエグゼクティブ１３０内で幾つのバッチを同時に例示および実行するのかその数をユーザが入力することを可能にする。通常、ユーザは手に入る装置を十分に利用するため最大値を入力する。例えば、もし５バッチを同時に実行するのに十分な装置がプロセスコントロールシステム１０内に存在するならば、ユーザは図３に示されているようにアクティブバッチの最大値を５と設定する。

記述ブロック３２０は作成しているキャンペーンの文章記述をユーザが入力するのを可能にする。例えば、ユーザは顧客名、製品名、キャンペーンもしくはその他の希望する文章記述に関連する記述文、例えば、”Weatherkiller Six Star Exterior Latex”のように入力をする。基本製法ブロック３２５は、どの基本製法がキャンペーンを作成するのに使用されているのかを示し、図５および６との関係で後に説明するように、バッチを作成するのに異なった基本製法を選ぶために選択ボタン３３０を使用してもよい。

バッチ識別ブロック３３５はバッチ接頭辞ブロック３４０、バッチシーケンス開始Ｎｏ．ブロック３４５、そしてバッチ接尾辞特定ブロック３５０を含む。バッチ識別ブロック３３５は、どのような名前を作成しているキャンペーン内のバッチに付ければよいかを、キャンペーン作成機能１１１にユーザが指示することを可能にする。例えば、接頭辞が”Patent-Demo-3-”、シーケンスＮｏ．が”001” 、そして接尾辞が”．A”である場合、キャンペーン作成機能１１１は連続したバッチ名”Patent-Demo-3-XXX．A．”を作成し、”XXX”は”001”から始まり、キャンペーン内でそれぞれのバッチに対して一づつ増やしながらインデックスをつけて行く。故に、上の例に基づいて２０バッチが作成された場合、キャンペーン作成機能１１１は最後の作成されたバッチを”Patent-Demo-3-020．A．”と名付けることになる。

セットアップバッチボタン３５５とクリーンアップバッチボタン３６０はユーザに特別のセットアップバッチを、作成されるキャンペーンの最初のバッチとして、および／または特別のクリーンアップバッチを、キャンペーンの最後のバッチとして含ませることを可能としている。セットアップバッチは、装置をリセットし原料の有無を調べるなどすることにより、プロセスコントロールシステムがキャンペーンを実行させるための準備を整える。一方、クリーンアップバッチは、前のキャンペーンの原料が次に実行するキャンペーンのバッチを汚染しないように、キャンペーン間にミキシング装置に水を流して洗浄する。例えば、最初のキャンペーンが何バッチもの赤い油性塗料を生産して、次のキャンペーンが何バッチもの白い水性塗料を生産していた場合、最初のキャンペーンの油性および赤い色が次キャンペーンの白い水性塗料に悪い影響を与えないことを確実にするために、クリーンアップバッチがそれらのキャンペーンの間に必要となる。

さらに、異なったタイプのバッチの間にプロセスコントロール装置の洗浄をしないで連続的に実行させればバッチが汚染される結果になるだろうから、複数のタイプのバッチを含むキャンペーンの内のバッチとバッチの間にもクリーンアップバッチを含みたいとユーザは考えるであろう。例えば、もしユーザが１０バッチの赤い油性塗料と１０バッチの緑の油性塗料（それは同じ基本塗料製法を使用するかもしれないし、しないかもしれない）を含む一つのキャンペーンを定義したとするなら、クリーンアップバッチは最後の赤い塗料のバッチと最初の緑の塗料のバッチとの間に緑のバッチの色汚染を防ぐために挿入されるであろう。もちろん、あるケースの場合、一つのキャンペーンの中で、異なったタイプのバッチが汚染されるリスクのないままプロセスコントロール装置を経過して連続的に使用されることもある。例えば、もしキャンペーンが１０バッチの白色水性塗料に続いて１０バッチの黒色水性塗料を含む場合、最後の白色塗料のバッチと最初の黒色塗料のバッチの間にはクリーンアップバッチは必要ないであろう。

作成ボタン３６５は作成キャンペーンウインドウ３００内で特定された全てのバッチを自動的に呼び出すためユーザにより選択される。図４のウインドウでは、作成ボタン３６５を選択することによりキャンペーン作成機能１１１は基本製法ブロック３２５により特定された製法の２０バッチ（それぞれ、バッチ識別ブロック３３５に準じて前に説明したように、特異な名前を持っている）を含むキャンペーン”Patent-Demo-3”を作成する。

図５は代表的な製法選択ウインドウ４００の表示であり、作成キャンペーンウインドウ３００（図４）内の選択ボタン３３０をユーザが起動したことに応答して現れる。製法選択ウインドウ４００はユーザに基本塗料製法の選択および変更することを可能にし、ユーザが独自の組成に関連したバッチパラメータ値を入力することにより、選択された基本製法に独自の組成を定義することを許している。

基本製法ブロック４１０はどの基本製法が現在選択されているかを表示し、プルダウンアロー４１５は、もし選択されれば、従来のポイント−ハイライト−セレクトするウインドウ操作を使って選べる複数の追加基本製法タイプを表示する。

ユニット結合ブロック４２０はプロセスステップ４２５とプロセスステップ４２５のそれぞれと連結した結合装置４３０を含む。プロセスステップ４２５のそれぞれは目的ベースルーチンもしくはその他のタイプのソフトウェアルーチンであり、図1のプロセスコントロールシステム１０内で起動したりプロセスコントロールパラメータを監視したりする。さらに、プロセスステップ４２５のそれぞれは、例えば、図1に示されている装置６２−７０などの独自の装置と関連もしくは接続されている。ユーザ（例えば、オペレータ）はプロセスステップ４２５のそれぞれを必要があれば適切な装置と接続させることが出来る。例えば、ミキシングステップは図1に示されている撹拌機６４−７０内の一つの撹拌機と接続することが出来、そして基本塗料混合物に着色剤を加えるステップは着色剤分配器６６および６８の一つと接続することが出来る。

組成コンフィギャレイションブロック４３５は選択された基本製法を実行しているバッチ内で用いる一つもしくはそれ以上のバッチパラメータを含む独自の塗料製法をユーザが選択するのを可能にしている。プルダウンアロー４３７を選択することにより、ユーザが使用可能な製法のリストを閲覧し、従来のポイントアンドクリック手法で独自の製法を選択することが出来る。さらに、ユーザはビュウパラメータボタン４４０を選択し、現在選択されている製法を閲覧および／または編集することが出来る。

図６はユーザが図５に示されているビュウパラメータボタン４４０を選択した時に現れる代表的な製法選択ウインドウ４００の図である。図６に示されているようにパラメータブロック４５０は組成ブロック４３５の下位に表示される。そのパラメータブロック４５０は選択された基本製法のプロセスステップ４２５を実行するために必要な全てのパラメータとパラメータ値の表を含んでいる。例証として、パラメータブロック４５０はパラメータ名４５５のリストを含み、それらは基本製法のバッチ実行中、プロセスステップ４２５に必要なパラメータと一致するものである。図６に示されているように、それぞれのパラメータは複数の数値を含み、それらは、例えば、最小値４６０、目的値４６５、調整値４７０、最大値４７５、そしてまたそれらの数値に付随する工業単位４８０を含む．もちろん、その他の数値および単位も同様に含ませることが出来る。

パラメータブロック４５０内でパラメータを閲覧することに加えて、ユーザはそれぞれのパラメータに付随する数値を編集することが出来る。例えば、もしユーザがミキシングプロセスステップのミキシング時間を長くしたい場合、もしくはユーザが塗料混合物に加える着色剤の量を変更したい場合は、ユーザはそれらの数値に適切な変更を加えることが出来る。パラメータ値を変更するためには、ユーザは変更される数値を選択し、キーボードからもしくはその他のデータ入力手段を使って新しい数値を入れなくてはならない。もし何らかのパラメータ値の変更がユーザにより行われたなら、キャンペーン実行機能１１２は、一つもしくはそれ以上のパラメータ変更メッセージをその他のバッチ関連の情報と共に、バッチ実行エンジン１７０が実行出来るようにキャンペーン実行機能１１２がバッチをリリースする時に、実行エンジン１７０に送信する。

グラフィカルオペレータインタフェース１２０によりユーザに提示される全てのバッチに関する情報（例えば、図３−６と関連して示されるバッチに関連した情報）は、キャンペーンマネジャー１１０がバッチエグゼクティブ１３０から得たことを知っておくことは重要なことである。キャンペーンマネジャー１１０はバッチ情報要求のメッセージをバッチエグゼクティブ１３０に送信し、そして要求したバッチ情報が含まれた自分当ての返事のメッセージを受信することにより、グラフィカルユーザインタフェース１２０に表示された多種のバッチに関する項目をうめている。例えば、キャンペーン作成機能１１１はデータベース１８０からバッチに関連する情報を得るためにバッチエグゼクティブ１３０とメッセージ交換をしている。それらは、次に、グラフィカルユーザインタフェース１２０に送信され、前に説明した図３−６に示されているように、一つもしくはそれ以上の表示ウインドウにユーザが閲覧出来るよう表示される。故に、ユーザはバッチ実行エンジン１７０が何の製法を実行しているか、もしくはある特定のバッチないしはキャンペーンを実行するのにどのようなプロセス管理装置が手に入るかを、キャンペーン作成機能１１１に報告する必要はない。

図７は代表的なバッチキャンペーン特性ウインドウ５００の図であり、これを通じて、キャンペーン内のバッチをキャンペーン実行機能１１２がリリースし、バッチ実行エンジン１７０が開始する方法を、ユーザが選択および最適化出来る。バッチ実行モードブロック５０５は３つの選択可能なバッチ実行モードを表示している。手作業モードによる操作はバッチをバッチ実行エンジン１７０にリリースしそしてリリースされたバッチの実行を開始する。それはユーザが手作業によりリリースするバッチを選択し、そして手作業によりキャンペーン実行機能１１２に入力をすることに応答して起こる。手作業により入力されたキャンペーン実行機能１１２は次にメッセージをバッチ実行エンジン１７０に送信しそれがリリースされたバッチの実行開始の引き金になる。手作業モードでの操作は非常に重要でコストがかかりそして・もしくは傾向的に危険と思われるプロセスステップを含むプロセスコントロールシステムで重宝であり、現場においてオペレータのプロセス開始の指示により実行するのが最良である。

自動リリースモードでの操作は、ユーザが手作業によりキャンペーン内のそれぞれのバッチの実行を開始させ、次のバッチを前のバッチの終了以前に実行の準備を整えることを要求される。言い換えれば、バッチ実行における自動リリースモードでは、最初のバッチが現在実行されている間に次のバッチを待機させておく。これにより、バッチ実行エンジン１７０内のバッチを例示するのに関連したプロセスの遅れをなくすことが出来、そしてまた、次のバッチを実行するのにプロセスコントロールシステム１０を準備するのに必要なその他のステップに関連した遅れをなくすことが出来る。故に、バッチ実行の自動リリースモードでは、ユーザがもし望むなら、前のバッチが実行を終了するとすぐに次のバッチを開始出来るようにすることが可能である。

自動開始モード操作では、オペレータの介入なしに自動的にリリースしたり、バッチを待機させたり、待機しているバッチをスタートさせたりする。例えば、最初のバッチが実行下にある間に、キャンペーン実行機能１１２は次のバッチを待機させ、バッチ実行エンジン１７０内の準備の整ったバッチを例示することによりいつでも実行出来る状態にしておく。最初のバッチの実行が終了した時点で、次のバッチは自動的にオペレータの入力を必要とすることなく（もしくは、それを要求することさえなしに）機動を開始する。バッチ実行の自動開始モードは、サイクル時間の短いバッチを実行するプロセスコントロールシステムで使用される時や、プロセスの質がそんなに重要でない時や、そして・もしくはプロセス上の失敗がそんなに損害でも危険でもない時などに用いれば特に効果的であろう。例えば、バターを生産するプロセスコントロールシステムは非常に短い回転時間を要し、プロセス上の失敗が比較的低価格ですむ、故に、バッチ実行の自動開始モードを用いるのに非常に適している。事実、短い回転時間のため、手作業でそれぞれの新しいバターのバッチを開始するオペレータの介入は、バッチの自動開始モードを用いた結果起こりうるプロセス上の失敗による費用にくらべて、もっと高価につくであろう。

稼動されるバッチの最大値の特定はバッチがバッチ実行エンジン１７０にリリースされる方法およびバッチ実行エンジン１７０によって開始される方法に影響を与える。例えば、もし5つの稼動するバッチがキャンペーンによって特定され、5つの稼動する（実行される）バッチを支援する十分な装置が存在するなら、キャンペーン実行機能１１２はそのキャンペーンの最初の5つのバッチをリリースするだろう。一度これらの5つのバッチが全て稼動されたならば（選択されたバッチ実行モードにより特定されたのが自動的であろうと手作業であろうと）、キャンペーン実行機能１１２は追加のバッチの準備をする（例えば、追加のバッチはバッチ実行エンジン１７０内で列を作って待機させ実行される準備をしておく）。

とにかく、前に説明したところのバッチ実行モードは、バッチがバッチ実行エンジン１７０にリリースされる制御をし、その結果、バッチが属する全キャンペーンを同時にバッチエグゼクティブ１３０に送信する必要がなくなる。その代わり、キャンペーン実行機能１１２は、例えば、バッチ実行エンジン１７０が実行出来るように一つのバッチをバッチエグゼクティブ１３０にリリースし、そして、現在実行されているバッチの終了以前に次のバッチ（どのバッチ実行モードが選択されたかによって）の実行の準備をしておく。キャンペーン実行機能１１２はバッチエグゼクティブ１３０内の全てのキャンペーンを例示するわけではないので（前の例では２０バッチが含まれるであろう）、キャンペーンマネジャー１１０はバッチエグゼクティブ１３０内のプロセスおよびメモリ資源に課せられる需要を最小限にとどめる。

図８は前に説明された自動開始バッチ実行モードを用いてどのようにＮ個のバッチが属するキャンペーンをキャンペーン実行機能１１２とバッチ実行エンジン１７０が協力して実行するのかを示した代表的な工程系統図である。ブロック５５２では、キャンペーン実行機能１１２はカウンター値Ｉを０にセットし、ブロック５５４では、キャンペーン実行機能１１２はカウンター値Ｉを一つずつ増やしていく。ブロック５５６では、キャンペーン実行機能１１２はカウンター値Ｉがキャンペーン内のバッチの数（Ｎ）より現在大きいかどうか判断する。そして、もしカウンター値Ｉが現在Ｎより大きくなければ、キャンペーン実行機能１１２はブロック５５８に進む。ブロック５５８では、キャンペーン実行機能１１２はバッチＩをバッチ実行エンジン１７０にリリースし、ブロック５６０では、キャンペーン実行機能１１２はバッチ実行エンジン１７０よって実行されているバッチ数が稼動するバッチの最大値 (ユーザにより特定されているように）と等しいか判断する。もし現在実行されているバッチ数が稼動するバッチの最大値と等しくなければ（例えば、少なければ）、キャンペーン実行機能１１２はブロック５６２に進む。ブロック５６２では、キャンペーン実行機能１１２はバッチＩを開始しそしてブロック５５４に再び進む。もしキャンペーン実行機能１１２がブロック５５６でカウンター値ＩがＮ（例えば、キャンペーン内のバッチ数）より大きいと判断すれば、キャンペーン実行機能１１２はブロック５６４に進む。ブロック５６４では、キャンペーン実行機能１１２はバッチ実行エンジン１７０よって実行されているバッチがまだあるかどうかを判断し、まだバッチが実行されているのであれば、キャンペーン実行機能１１２はブロック５６４に再び進む。一方、キャンペーン実行機能１１２がブロック５６４でもう現在実行されているバッチはないと判断すれば、キャンペーン実行機能１１２はブロック５６６に進みそのキャンペーンを終了する。

図９はキャンペーン内においてユーザが一つもしくはそれ以上のバッチを編集することを可能にする代表的なバッチ編集ウインドウ６００の図である。例証として、ユーザはキャンペーン”Patent-Demo-3”の５バッチのグループ６０５を編集のために選択しており、フォーミュラブロック４３５を通じて、これらのバッチの組成をMIDNIGHT-BLUEからFIREBIRD-REDに変更している。図１０はリストウインドウ２００の”フォーミュラ”と表示されているヘディングの下方に示されているようにバッチ集団６０５は今はFIREBIRD-REDを使用するように定義しなおされていることを表示している。

図９と図１０に例証として示されているように、キャンペーンの編集はバッチ実行エンジン１７０にまだリリースされていないキャンペーン内のバッチにしか出来ないということを理解しておくことは重要である。しかし、リリースされていないバッチの編集が急いで出来ることはキャンペーンの実行中に装置の故障が発生した場合など特に便利である。例えば、もしプロセスコントロールシステム１０（図１）の第一番目の撹拌機６４があるキャンペーンの実行中に故障したとすれば、ユーザは第一番目の撹拌機６４にもともと接続していたプロセスステップを第二番目の撹拌機７０に（もしくはその他の手に入る撹拌機に）接続しなおすようリリースされていないバッチの編集が出来る。同様に、もし顧客の注文もしくは注文の変更があるキャンペーン内のリリースされていない一つもしくはそれ以上のバッチに関連した組成もしくは製法の変更を求めている場合、ユーザはこれらのリリースされていないバッチに関連する適切な製法および／または組成の変更をすることが出来る。もちろん、もし望むなら、ユーザは新しいバッチをキャンペーンに加えたりもしくはバッチを完全に消去したりも出来る。

さらに、もし望むなら、ユーザはキャンペーンに関連しているバッチ実行モードを変更することも出来る。例えば、もしユーザがバッチを自動リリースもしくは自動開始する様に設定された現在実行されているキャンペーン内のバッチの変更をしたい場合、編集プロセス中の不注意なバッチのリリースおよび／または開始を防ぐために、バッチ実行モードを手作業リリースモードに変更しておくことは必要なことである。

バッチエグゼクティブ１３０としっかりと統合されていることに加えて、キャンペーンマネジャー１１０はセキュリティシステム１４０およびバッチヒストリアン１５０ともしっかりと統合されている。特に、キャンペーン実行機能１１２は、バッチエグゼクティブ１３０もしくはユーザからの何らかの介入も要求することなく、自動的にキャンペーン管理メッセージを正しいフォーマットで直接バッチヒストリアン１５０に保存するために送信する。同様に、セキュリティシステム１４０のアクセス管理の特徴は、製法の定義および装置リストの定義などの他の従来のプロセスコントロールアプリケーション内でユーザのアクセスを管理する手法に似た方法で、ユーザがバッチプロセスキャンペーンを編集および実行出来る権限をユーザ名およびパスワードで制限している。さらに、キャンペーンマネジャー１１０は、プロセスコントロールシステムが故障の場合、キャンペーン内のバッチのリカバリーおよび現状報告を、キャンペーンマネジャー１１０に行わせるようなデータ機構を組み入れている。

さらに、キャンペーンマネジャー１１０は文字入力の出来るものを使用して実行することが出来る。それはよく知られているように、ウェブベースのアプリケーションにおいて受け入れられている。さらに、キャンペーンマネジャー１１０は、図1に示されているように、クライアント−サーバシステム構成で作動するようにプロセスコントロール１０内に配置されている。この方法により、キャンペーンマネジャー１１０はワークステーションもしくはその他のプロセッサを有するシステムであるサーバ１６内に置かれ、その他のバッチエグゼクティブ１３０、セキュリティシステム１４０、そしてデータヒストリアン１５０などの機能を有するプロセスコントロール機能は、同じ場所もしくはその他のプロセスコントロール１０内のワークステーションおよび／またはノードに置かれている。これらその他のプロセスコントロール機能は、システムレベルデータバス１８もしくはその他の有線もしくは無線通信接続を通じて、キャンペーンマネジャー１１０と通信する。さらに、実質上どのハードウェアプラットホームを用いて（例えば、バーコードリーダ、携帯型情報機器、ラップトップ、パームトップなど）オペレータとの接点を保っている複数のクライアント（例えば、クライアント３２と３４）はキャンペーンマネジャー１１０と通信が出来、キャンペーンマネジャー１１０からの最新の現状報告を調査もしくは要求しなくともキャンペーンマネジャー１１０によって出されたメッセージを自動的に受け取ることが出来る。

ここに説明されているキャンペーン管理手法はバッチ定義および実行機能と通信を行い、自動的にキャンペーン管理機能からの要求に応答して、バッチ定義および実行機能によって使用されているデータベースからバッチ情報を（例えば、製法、バッチパラメータ、装置リストなど）受信する。このような方法で、ここに説明されているキャンペーン管理手法はバッチに関連したデータベースの情報をユーザが直接キャンペーン管理機能に入力するという必要性を削除し、またそれ以上に、従来のキャンペーン作成および実行手法が通常要求していた一つ以上のアプリケーション内にあるバッチ情報データベースをユーザが作成および更新（例えば、アプリケーション内のデータベースの同期化）する必要性をも削除する。故に、ここに説明されているキャンペーン管理手法は、バッチ定義および実行機能が製法の定義、装置の配置（例えば、装置の加工手段との接続）などに関連する情報を含んだ一つだけのバッチデータベースを管理すること許可する。言いかえれば、ここに説明されているキャンペーン管理手法を用いれば, ユーザは、例えば、どの製法をバッチ実行機能で実行させるのか、どのプロセスコントロール装置が特定のバッチもしくはキャンペーンを実行するのに手に入るのかをキャンペーン管理機能に報告する必要はない。

さらに、ここに説明されているキャンペーン管理手法は、複数のタイプのバッチを含むキャンペーンをユーザが柔軟に作成することを可能にする。故に、ここに説明されているキャンペーン管理手法を用いれば、従来のバッチ定義および実行手法の場合がそうであったが、キャンペーンは一つのタイプのバッチを何度も実行しなければならないというふうには限定されない。例えば、一つのキャンペーン内において、ユーザは１バッチのミッドナイトブルー半光沢仕上げ水性塗料、１バッチのネイビーブルー半光沢仕上げ水性塗料、そして１バッチのレッド油性塗料を生産することが出来る。また、例えば、このキャンペーン手法では、キャンペーンのためにプロセスコントロールシステムの準備をするために、キャンペーン内でいつも第一番目に実行される特別なセットアップ方法を含んだセットアップバッチのような特別なバッチを、またはキャンペーン内の他の全てのバッチが実行を終了した後特別なクリーンアップ製法を含んだ特別なクリーンアップバッチなどの特別なバッチを、ユーザが使えることを可能にする。

さらに、ここに説明されているキャンペーン管理手法は、メモリおよびプロセス資源を有効に利用する方法で、バッチ実行機能へのバッチのリリースを制御する。例えば、バッチを実行するのに必要な装置が手に入るようになった時に、ユーザはバッチ実行機能へバッチをリリースするための複数のキャンペーン管理操作モードから一つを選択することが出来る。これは装置資源が手に入るか否かには関係なく、バッチが属する全キャンペーンをバッチ実行にリリースする従来のキャンペーン作成および実行手法とは異なっている。

ここに説明されているキャンペーン管理手法は、バッチを実行するのに必要な装置が手に入るようになった時、バッチをバッチ実行機能にリリースする（例えば、送信する）ように構築することが出来る。このように、非リリースのバッチはバッチ実行機能のメモリ資源内で例示されないが、しかしその代わり、キャンペーン管理アプリケーション内に留まっている。さらに、これらの非リリースのバッチはユーザによりバッチ実行機能にリリースされる前に独自に変更することが出来る。これにより、ユーザは稼動しているキャンペーン内で、その現在稼動しているキャンペーンを止めることなく、また必要とする変更をするために全く新しいキャンペーンを作成することなく、非リリースのバッチに変更を加えることが出来る。例えば、あるキャンペーンが稼動している間の装置の故障に対して、ユーザは非リリースのバッチ内のプロセスステップを編集することにより対処することが出来、故障した装置に接続されているプロセスステップを変更し、これらのプロセスステップを代わりの機能する装置につなぎ変えらる事が出来る。また、例えば、非リリースのバッチを変更出来るということは、ユーザが遅い顧客の要求にキャンペーンを変更することで答えることを可能にする。例えば、もしあるキャンペーンが最初２０バッチのミッドナイトブルー外壁用の水性塗料を含んでおり、ある顧客がそのキャンペーンが実行され始めた後に、そのミッドナイトブルーの塗料の内、２バッチはネイビーブルー内壁用の油性塗料にして欲しいと要求した場合、ユーザは元のキャンペーン内の2つの非リリースのバッチを編集することで、これらの非リリースのバッチがミッドナイトブルー色の代わりにネイビーブルー色を生産するようにその内壁用の油性塗料に関連する製法とパラメータ値を特定することが出来る。

ここに説明されているキャンペーン管理手法は、クライアント−サーバシステム機構を用いて、プロセスコントロールシステム内に構築することが出来る。このように、キャンペーン管理機能はプロセスコントロールシステムのノードにあるサーバ上（例えば、ワークステーションもしくはその他のプロセッサを含むシステム）にあり、バッチ定義および実行機能、データヒストリアン機能、セキュリティ機能などその他のプロセス管理機能は同じ場所もしくはその他のプロセスコントロールシステムのワークステーションおよび／またはノード上にある。これらその他のプロセスコントロール機能はデータバスもしくはその他の有線もしくは無線通信接続を通じてキャンペーン管理機能と通信する。さらに、事実上どのようなハードウェアプラットホーム（例えば、携帯型情報機器、ラップトップ、パームトップなど）などでオペレータと接点を保持する複数のクライアントは、ここに説明されているキャンペーン管理手法と通信し、キャンペーン管理機能から現状報告を調査もしくは要求しなくとも、キャンペーン管理機構によって自動的に出されるイベントメッセージを受信することが出来る。

ここに説明されているキャンペーン管理手法はまたキャンペーン管理機能が、例えば、バッチヒストリアン機能およびセキュリティ機能などのプロセスコントロールシステム内のその他の機能としっかりと関連づけが出来ることを可能にする。故に、ここに説明されているキャンペーン管理機能は自動的にキャンペーン管理メッセージを、バッチ実行機能もしくはユーザからの介入を要求せずに、直接バッチヒストリアンに保存のために送信することが出来る。同様に、セキュリティ機能のアクセス管理の特徴は、製法の定義および装置リストの定義などの他の従来のプロセスコントロールアプリケーション内でのユーザのアクセス管理手法に似た方法で、ユーザがバッチプロセスキャンペーンを編集および実行出来る権限をユーザ名およびパスワードを通じて制限する。さらに、ここに説明されているキャンペーン管理手法は、プロセスコントロールシステムの故障の場合、キャンペーン内のバッチのリカバリーおよびバッチの現状報告をキャンペーン管理機能に行わせるデータ機構を組み入れている。

もしソフトウェアに装備されているならば、ここに説明されているファンクショナルブロックおよびルーチンは、コンピュータ、コントローラ、フィールドデバイスなどのRAMもしくはROMの磁気、光、もしくはその他の保存媒体のようなどのコンピュータでも読めるメモリに保存することが出来る。同様に、このソフトウェアは、例えば、通信媒体上に変調することが出来、ユーザもしくはデバイスなどに、電話線およびインターネットなどの通信チャネルなど今日知られている希望の通信方法を用いて送信することが出来る。

本発明は特定な例を参照しながら説明されているが、それらの例は説明のためだけのものであり本発明を限定するものではない。この分野における当業者にとって公開され具体化された例示の変更、付け足し、もしくは削除は本発明の精神および範囲から逸脱するものではないことは自明のことである。

Claims (4)

1. グラフィカルユーザインタフェースと記憶装置を持つプロセスコントロールシステム内での使用を目的とした複数のバッチを含むバッチプロセスキャンペーン編集方法であって、
   バッチ情報を含むデータベースを有するバッチエグゼクティブにバッチ情報を要求する第一のメッセージを送信するステップであって、当該バッチエグゼクティブは、命令している一組のフィールドデバイスが当該バッチエグゼクティブによって実行されているバッチと関連するプロセスステップを実行するようプロセスコントローラに命令を送信するよう構成されているステップと、
   バッチ情報を要求する前記第一のメッセージに応答して一組のバッチ情報を含む第二のメッセージを前記バッチエグゼクティブから受信するステップであって、当該一組のバッチ情報は前記バッチエグゼクティブのデータベースから取り出されるステップと、
   前記バッチエグゼクティブの前記データベースから取り出された前記一組のバッチ情報の少なくとも一部を用いてバッチプロセスキャンペーンを作成するステップと、
   グラフィカルユーザインタフェースを用いてバッチプロセスキャンペーンから一つもしくはそれ以上の非リリースのバッチを特定する第一番目の入力をユーザに促すステップと、
   グラフィカルユーザインタフェースを用いて特定された一つもしくはそれ以上の非リリースのバッチに関連するバッチ情報への変更を特定する第二番目の入力をユーザに促すステップと、
   前記バッチエグゼクティブに前記バッチプロセスキャンペーンのバッチを送信する前に、バッチ情報への変更をバッチプロセスキャンペーンと共に記憶装置に保存するステップとを含み、
   一つもしくはそれ以上の非リリースのバッチの内の第一番目のバッチが該一つもしくはそれ以上の非リリースのバッチの内の第二番目のバッチとは異なる一組の運転パラメータを含み、
   グラフィカルユーザインタフェースを用いて特定された一つもしくはそれ以上の非リリースのバッチに関連するバッチ情報への変更を特定する第二番目の入力をユーザに促すステップが、バッチプロセスキャンペーンが実行されている間に第二番目の入力をユーザに促すこととバッチ情報への製法の変更を特定する入力をユーザに促すこととの少なくともいずれかを含む、バッチプロセスキャンペーン編集方法。
2. グラフィカルユーザインタフェースを用いて特定された一つもしくはそれ以上の非リリースのバッチに関連するバッチ情報への変更を特定する第一番目の入力をユーザに促すステップが、パラメータ値変更を特定する入力をユーザに促すステップを含む請求項１に記載のバッチプロセスキャンペーン編集方法。
3. グラフィカルユーザインタフェースを用いて特定された一つもしくはそれ以上の非リリースのバッチに関連するバッチ情報への変更を特定する第二番目の入力をユーザに促すステップが、バッチプロセスキャンペーンに追加すべき追加バッチを特定する入力をユーザに促すステップを含む請求項１に記載のバッチプロセスキャンペーン編集方法。
4. プロセッサ、グラフィカルユーザインタフェース、及び記憶装置を持つプロセスコントロールシステム内での使用を目的としたバッチプロセスキャンペーン編集システムであって、
   コンピュータが読める媒体と、そして、
   コンピュータが読める媒体に保存され且つプロセッサよって実行出来るように適合された複数のルーチンとを含み、前記複数のルーチンは、
   情報を含むデータベースを有するバッチエグゼクティブにバッチ情報を要求する第一のメッセージを送信するように適合され、当該バッチエグゼクティブは、命令している一組のフィールドデバイスが当該バッチエグゼクティブによって実行されているバッチと関連するプロセスステップを実行するようプロセスコントローラに命令を送信するよう構成されている第一番目のルーチンと、
   バッチ情報を要求する前記第一のメッセージに応答して一組のバッチ情報を含む第二のメッセージを前記バッチエグゼクティブから受信するように適合され、当該一組のバッチ情報は前記バッチエグゼクティブのデータベースから取り出される第二番目のルーチンと、
   前記バッチエグゼクティブの前記データベースから取り出された前記一組のバッチ情報の少なくとも一部を用いてバッチプロセスキャンペーンを作成するように適合されている第三番目のルーチンと、
   グラフィカルユーザインタフェースを用いてバッチプロセスキャンペーンから一つもしくはそれ以上の非リリースのバッチを特定する第一番目の入力をユーザに促すように適合されている第四番目のルーチンと、
   グラフィカルユーザインタフェースを用いて特定された一つもしくはそれ以上の非リリースのバッチに関連するバッチ情報への変更を特定する第二番目の入力をユーザに促すように適合され、且つ、バッチプロセスキャンペーンが実行されている間に前記第二番目の入力をユーザに促すこととバッチ情報への製法の変更を特定する入力をユーザに促すこととの少なくともいずれかを行うように適合されている第五番目のルーチンと、
   バッチ情報への変更をバッチプロセスキャンペーンと共に記憶装置に保存するように適合されている第六番目のルーチンと、
   を含む、バッチプロセスキャンペーン編集システム。

Images