JP5646802B2 - バッチ表示システムおよびバッチ表示方法 - Google Patents

Description

本発明は、概して、プロセス制御ネットワークに関し、より具体的には、プロセスプラント内において実施されるバッチプロセスに関する情報を取得及び表示するバッチ表示エンジン関する。

一般的に、化学薬品の処理工程や石油精製又はその他のプロセスにおいて使用されるようなプロセス制御ネットワークは、例えばバルブ・ポジショナ、スイッチ、センサ（温度、圧力、流量センサ、等）などでありうる１つ以上のフィールド装置と通信可能に連結される集中型のプロセス制御装置を含む。これらのフィールド装置は、プロセスプラント内における物理的な制御機能（バルブ開閉など）を実行したり、プロセスプラントの動作を制御する際に使用するためにプロセスプラント内で計測を行ったり、プロセスプラント内におけるその他所望の機能を実行しうる。

従来、プロセス制御装置は、例えばフィールド装置との間で４〜２０ｍＡ（ミリアンペア）の信号をやり取りしうる１つ以上のアナログ信号線又はバスを介してフィールド装置に接続されていた。しかしながら、過去数十年ほどの間に、プロセス制御産業では、制御装置とフィールド装置との間の通信を実施するのに使用される、FOUNDATION^TM FIELDBUS（以下、「Fieldbus」）や、HART（登録商標）、PROFIBUS（登録商標）、WORLDFIP（登録商標）、Device-Net（登録商標）及びＣＡＮプロトコルといった、標準化され、オープンで、デジタル、又はデジタル・アナログ混合の通信プロトコル（接続手順）が多数開発されている。

一般的に言えば、プロセス制御装置は、１つ以上のフィールド装置により生成された計測値及び／又はこれらフィールド装置に関するその他の情報を示す信号を受信し、この情報を使用して一般に複雑な制御ルーチンを実施し、信号線又はバスを介してフィールド装置に送信される制御信号を生成し、それによってプロセスプラントの動作を制御する。

通常、バッチプロセスに使用されるような特定タイプのプロセス制御ネットワークには、複数組の複製された設備（replicated equipment; 複製設備）が含まれる。複製設備の各組は、プロセスプラント内において本質的に同一の機能を実行する、同一の又は類似したハードウェアを有するように設計されている。

例えば、クッキー製造プラントは、複数組の混合機、複数組のオーブン（焼付機）、及び複数組の梱包装置が備えられている。個々の混合機のいくつか又は全てが並行に作動可能となっていると共に、オーブン（焼付機）及び梱包装置のいくつか又は全てと直列に作動可能な状態で接続されている。このようなシステムでは、特定のバッチ処方（レシピ）による定義に従って、同一製品を製造する際には、複製設備の特定の組の何れの動作を制御するにも、同一の全般統制アルゴリズム又はルーチンを使用するのが典型的である。

通常、このようなバッチ制御手順はそれぞれ、第２段階を開始する前に第１段階を終了するなどといった具合に、多数の異なるステップ又は段階を順々に実行する。このように、上記のクッキー製造プラントにおいては、バッチ制御手順によって、混合機を制御するために第１の処理手順又はステップが実行され、その後混合機により製造された製品に対してオーブン（焼付機）を作動するための処理手順が実行され、そしてその後更にオーブン（焼付機）により生産された製品を梱包するために梱包装置を制御する第３の処理手順が実行される。各ステップとも制限された時間で実行される。

このように、バッチプロセスは一般的に、「１バッチ（一回分）」の製品を生産するために１つ又は複数の設備を使用して、原材料を処理段階に従って供給することを伴う。工業規模で実施されるバッチプロセスの一例であるポリ塩化ビニル製造においては、はるかに小さな塩化ビニル分子を共に重合又は結合してポリ塩化ビニルを製造する。このプロセスは、バッチ反応器（回分反応器）に塩化ビニルと溶媒と重合誘導物質の混合物を適正水準まで仕込み、反応器内の混合物を加熱し、結果として得られるバッチを冷却し、そして残りの出発物質を取り除いてバッチを精製することより達成される。但し、ポリ塩化ビニルの製造はバッチプロセスの一例に過ぎず、一般に、製品製造・配送・検査に使用されているものに加えて、直接製品に関係しない用途に関連するバッチプロセスをも含む様々な種類のバッチプロセスが存在する。

プロセス制御に関する内容に携わる国際組織である国際計測制御学会（International Society for Measurement and Control）により公布されているバッチ制御の標準規格の１つとして、「Batch Control Part 1: Models and Terminology」（仮訳：「バッチ制御 第１部：モデルと特殊用語」）と題するものがあり、しばしばＩＳＡ規格Ｓ８８．０１−１９９５又はその改訂版（以下、「Ｓ８８標準」と総称する。）と称される。このＳ８８標準は、自動化されたバッチプロセスにおいて使用される設備や手順のモデルを定義する外、当該モデル及びそれらの構成要素に関連して使用される特定の用語も定義しているものである。

例えば、「バッチプロセス」という用語はＳ８８標準によると、１つ以上の設備を用いて、有限量の入力物質を供給し、有限時間の間に順序付けられた一連の処理を行うことにより、有限量の物質を生産するプロセスとして定義されている。また、他の例として、「バッチ」という用語は、バッチプロセスの単一の実行により生産されている又は生産された物質、としてＳ８８標準では定義されている。

バッチ処理設備（例えば、バルブ、ヒータ、混合機などの制御可能要素、等）が、バッチプロセス又はバッチ運転中に、バッチを製造するために事前に定義された処理手順に従って作動する。本稿においては、このようなバッチ処理設備の全ては、設備（equipment）、機器（equipment module）、処理設備（processing equipment）、及び／又は物理的要素（physical element）と、同義的に使用される。このような物理的要素を操作する手順は、Ｓ８８標準によれば「手順制御モデル（procedural model）」と称されている。

Ｓ８８標準によると、手順制御モデルは、処理手順の階層順位方式により構成されており、最も高い階層が下位の階層のそれぞれを包含し、次に高い階層がその下の階層のそれぞれを包含する、などと構成されている。ここで特に関心の対象となっているＳ８８手順制御モデルの階層には、高位から下位の順に述べると、「手順（procedures）」、「単位手順（unit procedures）」、「単位操作（operations）」、そして「フェーズ（phases）」とが含まれる。

本稿においては、「処理手順要素（procedural element）」又は「バッチ従属処理手順（batch sub-procedures）」という用語は、一式のバッチ処理手順の他の階層的な定義に使用されるのと同様に、これらＳ８８手順制御モデルの任意の階層における任意の実施形態又は実施にも使用される。

上述したように、ここで関心の対象になっている最も上位のＳ８８手順要素は、１つ又は複数の単位手順からなる手順と称される。一方、各単位手順は１つ又は複数の単位操作から順に構成される又は構成することが可能である。また、各単位操作は１つ又は複数のフェーズから順に構成される又は構成することが可能である。

なお、Ｓ８８手順制御モデルは、特定のアプリケーションにおける定義やその他の階層レベルの使用を除外するものではない。むしろ、ここではＳ８８標準及び手順要素は、自動化されたバッチプロセス制御において従うべき手順を示すために、一般的な標準モデルを提供することを意図して参照されているに過ぎず、これらの要素はＳ８８標準により定義される４つの処理手順要素に限定されない。

バッチの異なる処理手順要素は、一般的に実際の運用においてはコンピュータプログラムとして実施される。これらコンピュータプログラムは、パーソナルコンピュータ、ワークステーション及びプログラマブル・コントローラを含むデータ処理装置により且つデータ処理装置において実行される。一般的な処理手順要素が実行されると、通常、データ処理装置の出力を物理的要素に直接接続することにより、又はローカルエリア又は広域ネットワークを通して間接的に接続することにより、物理的要素を制御するのに使用されうるデータ処理装置からの電気的又は光学的出力が得られる。

処理手順要素は、少なくとも１つの物理的要素に関しての「基本制御」を起動することにより、割当てられた又は関連付けられている作業（task）を実行する。通常、このタイプの制御は、物理的要素の特定の所要状態を確立し維持する機能専用に設けられている。基本制御の例としては、貯蔵容器要素中の物質の流動の開始や維持、そしてポリ塩化ビニル反応器要素中の出発物質の加熱などが挙げられる。実際には、手順制御モデルの下位階層（すなわち、フェーズ）は、実際の物理的要素と実際の通信を行ない、それによって基本制御を起動又は実行する。手順制御モデルの高位階層は、本質的には、物理的モデルと同様に、手順制御モデルの組織及び構造を改良するための抽象的概念である。

また、多くのバッチシステムは、バッチプロセス又はアクティビティの状態（state）を示すために、論理的構成として「状態機械モデル（state machine model）」を使用している。状態機械モデルは、多数のプロセス状態を、これらの状態間におけるトランジション（遷移）を引き起こすアクション（個々の動作・処置）と共に、記述し又は定義する。プロセスの状態機械モデルは、初期遷移で特定の状態へと遷移するために、特定の状態にあると言われている。

特定の事象（イベント）が発生したり、特定の状態が感知されたりすると、状態機械モデルは、それら特定のイベント又は感知された状態に応じて、別の状態へと遷移する。状態機械モデルは、バッチプロセスの手順要素の動作を定義及び実施するのに有用な技法である。特に、状態機械（state machine）として定義且つ実施される手順要素は、例えば、それに関連する状態機械が古い状態から新しい状態に遷移した時点で、アクション（個々の動作・処置）を開始する。

もちろん、Ｓ８８標準は、標準状態機械モデル（standard state machine model）に従って、処理手順要素の定義及び実施を可能にする。Ｓ８８標準はこのアプローチを強制するわけではないが、このアプローチはプロセス制御産業において幅広く採用されて、様々なベンダーの製品間における、より高度な相互運用性を可能にしている。状態機械モデルに応じて定義かつ実施される手順要素を有しＳ８８標準の現在市販されているアプリケーションの１つとして、Emerson Process Management社が提供するDeltaV^TMバッチ製品が挙げられる。

DeltaV^TMバッチでは、サーバプログラム又はバッチ・エグゼクティブ・プログラムが、様々な処理手順要素を実行するデータ処理装置にて作動する。サーバプログラム又はバッチ・エグゼクティブ・プログラムは、手順、対応する単位手順、対応する単位操作、及び対応するフェーズが、サーバプログラムにより各手順の各ステップが順番に並べられるように、１つ以上の状態機械モデルに応じて処理手順要素の実行を統合調整（coordinate）する。

また、バッチ・キャンペーン・プログラムをユーザ・インターフェースと共に使用して、プラント設備を使用したプラント内で実行されるように、一式の様々なバッチプロセス又はバッチ運転を設定することができる。いかなる場合にも、例えばフェーズがサーバプログラムにより開始される時などは、特定のバッチ運転又は特定のバッチプロセスの実施の最中であっても、そのフェーズはプログラマブル・コントローラ内のフェーズ・ロジック・インターフェースに開始要求を送信する。プログラマブル・コントローラは、その後に、フェーズ用の制御ルーチン又は実際の状態論理を実行し、通信を介してプロセス設備に要求されたプロセス制御を提供する。

当然のことながら、バッチ運転の処理を構成するヒストリカルイベント（バッチ履歴）を表すデータを収集することが望ましい。このようなヒストリカルデータは、例えば、品質管理における傾向（トレンド）を判断する際に、又はバッチプロセスにて使用される設備が保守点検（サービス）の実施を必要とする場合を判断するのに役立ちうる。多くのタイプのデータが、バッチプロセスの品質又は進行を評価検討する際に有用となりうる可能性がある。

このようなデータ源の１つとして、バッチの処理中にバッチプロセスにおいて様々なデータ点により生成された連続データが挙げられる。データ点は連続データの単一源であり、連続データはバッチプロセスの制御値、その他の状態、又は計測値のいくつかを反映する。例えば、センサにより測定される特定レベルの物質の流量又は温度が、このようなデータ点の１つとなりうる。制御バルブの現在の設定やサンプルが採取された時間などは、別のデータ点として採用されうる。このようなデータ点の各々は、それと関連するバッチ・プロセス・アプリケーションにより、一定の時間をかけて検知又は制御される一連の連続したデータ値を有することができる。

バッチの処理中に生成されたこのような連続データの集合は、大抵の場合バッチシステムによりログに記録される。これらのログ記録には、通常、タイムスタンプや現行値の外に、データ源を識別するためのタグのように、その他のデータ点の識別情報が含まれる。

バッチプロセスの品質又は進行を評価検討する際に有用な別のタイプのデータは、イベント情報である。イベント情報は、手順制御モデルの実行という観点からバッチプロセスを表す情報に関係している、又はそれを含んでいる。例えば、手順制御モデルの特定のフェーズ又は特定の単位操作の開始・終了時間、手順制御モデルの単位手順又は手順の開始・終了時間を示すバッチイベントが、イベント情報を構成する。また、イベント情報は、プロセスイベントを含む。プロセスイベントは、バッチプロセスの物理的要素により又はオペレータにより生成された情報を含んでいる。

特にプロセスの各機器（equipment module）や設備（cell）等は、特定のフェーズの開始、停止又は作動状態において１以上の特定の動作（即ち、特定の基本制御動作の実行など）を示すプロセスイベントを生成しうる。プロセス設備により認識される警報（アラーム）及びイベントの状態は、プロセスイベントのさらなる一例である。また、プロセスイベントは、バッチプロセス稼動中にバッチプロセスになされるオペレータ変更に関する情報を含みうる。

これら種々の形式のイベント情報及び連続データを統合して、バッチプロセスのユーザにこれらの情報を包括的で分かり易い形で提供することは、最も有用である。しかしながら、バッチプロセスの品質及び進行を報告するための現在入手可能なツールの多くは、このような統合機能に欠ける。通常、ユーザは、種々の解体ツールを使用して統合作業をマニュアル操作で行なう必要がある。また、既存の解決法ではこのような統合を限られた範囲においてのみ提供するだけである。

このためユーザは、報告プログラムが種々のタイプ及び供給源のイベント情報と連続データとを関連付けられるように、かなり詳細なシステムの設定・構成に関する情報（configuration information）を提供する必要がある。例えば、バッチ処理において使用される既存のツールの多くは、バッチプロセスから連続データを収集するが、それ以外のツールは厄介で扱いにくいインターフェースをユーザに提供することによって、関心のあるデータの特定部分の位置を突き止めるようになっている。

例えば、ユーザは、索引付けツール（indexing tool）を使用して、バッチプロセスにおける特定のイベント又は手順に関係する捕獲データ（captured data）の位置を突き止めるためのフィルタ又はトリガを定義することができる。これらフィルタやトリガは、例えば、特定のフェーズの実行に関係するデータの開始・終了時間を定義することと同様に、単純なものでよい。場合によっては、特定の手順要素に対応するデータを識別するその他のパラメータの確認をユーザに要求することで、定義がより複雑となることもある。

一般に、これらのツールを用いる場合、バッチプロセスにて関心の対象となっているイベントを定義するためには、ユーザがマニュアル操作でシステムの設定・構成に関する情報を提供しなければならない。この情報にアクセスしたり、この情報を構成したりするには、大抵の場合、ユーザは複雑な作業を行う必要がある。また、ユーザが関心の対象になっているイベントと、これらのイベントに関連するデータの好ましい特質とについて、かなりの知識を持っていることが要求される。更に、処理手順イベントにデータを関連付けるために行うフィルタ定義の複雑さに関係なく、バッチイベントにデータを関連付けるために、このようなフィルタを定義する作業の大部分は、マニュアル操作によるプロセスとなっている。

根本的に、これらのツールを使用する際、ユーザは、特定のイベント及びそのイベントに関連した連続データの特定の部分を識別する構成データ（configuration data）を入力しなければならない。このようなマニュアル操作によるプロセスではエラーが発生しやすく、イベント情報と関連する連続データとの関係が不正確な状態で確立される可能性がある。更に、これらのツールは、格納されているデータの構造に関するユーザの知識が豊富であることを要求すると共に、それらを提示する際にユーザにデータ間の有意義な関係を生成する責任を負わせる。

概存の技術においても照合（クエリー）能力はそれなりのものであるが、これらの技術は概してデータにアクセスするために、関係データベースの「フロント-エンド」に毛が生えたようなものを提供するのみである。このような関係データベース管理システムによる照合操作では、格納されているデータの様々な要素間の関係を理解すること、及び所望のデータを提示するために有意義な問合せ（クエリー）を生成することが、ユーザに要求される。

既存のバッチ処理ツールの多くに関連する別の問題は、プロセス及びバッチイベント情報をユーザに表示するところで生じている。バッチ・ヒストリアン・プログラムは、バッチシステムに関係するバッチイベント情報を収集してユーザに表示するシステムの１つである。しかしながら、既存のバッチ・ヒストリアン・プログラムは一般的に、連続データから、表式やテキスト形式のレポートを作成するだけである。或いは、せいぜい連続データの要素の傾向（トレンド）を示す簡単な線図を作成するだけである。

バッチシステムにおいて現在利用できるバッチヒストリアン機能特性では、データをユーザに表示する際の柔軟性が限られたものとなる。例えば、既存のヒストリアン・プログラムの表式・テキスト形式の表示から、バッチイベント又はプロセスイベントと連続データとの関係を読み取ることは困難である。

１９９９年４月２９日出願、英国特許第ＧＢ２，３５３，６１６号として公開の「Methods and Structure for Batch Processing Event History Processing and Viewing（バッチ処理イベント履歴処理と表示の方法及び構造）」と題する米国特許出願第０９／３０２，６８７号には、種々のバッチ処理手順要素又はイベントに関する連続的なバッチデータを、ユーザがより簡単に表示できるようにしたバッチ表示システムを開示する（特許文献１）。

特に、上記特許文献１には、バッチ履歴エグゼクティブ（batch history executive）から得られるイベント情報とバッチの種々のイベント間の関係とを表示する際に、かなりの柔軟性をユーザに提供する表示クライアント・プロセス（view client process）が記載されている。一般的に、表示クライアントは、バッチ及び関連する処理手順の階層イベントを表わすために、ガント図表を画面に表示することによりグラフィック（図形）方式にてイベント情報を表示する。

また、グラフィカル・ユーザ・インターフェースは、「掘り下げる（drill down）」ことができるように表示されたイベントを選択し、選択されたイベントを構成する階層イベントの下位の階層を表示する機能を、ユーザに提供する。また、選択されたイベントを含む階層的に下位のイベントのテキスト形式、表式での提示は、グラフィック式のガント図表の表示の下側に、テキスト形式、表形式で表示される。このバッチ表示は、ユーザが、ログ記録されたデータ点での連続データを、連続データをこの連続データに関係するイベント情報に関連付ける方法によって、グラフィック形式で表示することを可能にする。

しかしながら、この場合においても、バッチ表示はガント図表により提示されるため、ユーザにとって有用又は有意義な方法で、バッチプロセス全体を理解又は表示することが困難となる場合がある。

よって、当然のことながら、現在進行中のバッチ動作を表示するために、特定の時点においてバッチプロセスの単純なスナップショットをとり、そのデータをユーザに対して表示することは不可能である。これはバッチプロセスには、種々の異なる処理手順要素が存在するためである。異なる処理手順要素は、異なる設定点や設定などを採用して、異なる時にプラント内における異なる設備上で実行されうる。

その代りに、バッチ運転を表示して、ユーザはバッチの処理手順イベントに関係する種々の異なる時点におけるバッチからのデータを、評価検討し、分析しなければならない。それによってバッチ運転の動作を理解することができる。バッチの処理手順イベントとしては、例えば、バッチに関連する従属処理手順（sub-procedure）及び従属工程（sub-process）が挙げられる。

通常、種々のバッチデータは、バッチ運転作動中に、自動的に収集され、格納されるが、異なるタイプのデータは、一般に異なる従属システムにより収集され、実際に異なるデータベースに格納されうる。この事実は、いかなる特定のバッチプロセスについても、オペレータが包括的な表示を得ることを困難にする。

例えば、バッチプロセス内のセンサやバルブなどの実フィールド装置から得られる警報データ及びセンサ計測データなどのデータは、通常、タイムスタンプ付きデータとしてデータ・ヒストリアンに格納される。格納されたデータは、一般的にデータが収集されたタイミングに基づいて、前記データ・ヒストリアンから利用可能となる。

しかしながら、バッチ・エクゼクティブ・ルーチンに関連したデータベース等の異なるデータベースには、バッチ運転の開始・終了時間やバッチ運転中の種々の異なる従属処理手順又は処理手順要素が格納されうる。

それでも、ユーザやオペレータが、コンパクトな方式でバッチの動作を簡単に表示できることが重要であり、場合によっては非常に重大である。コンパクトな方式とは、例えば、バッチの動作中に収集された大量の生データの全領域を、ユーザがスクロールして表示する必要がないような方式である。多くの場合、所定のバッチが、ゴールデン・バッチ（golden batch; 過去の最良データ）によって定義されたような「標準（norm）」から逸脱するかどうかを判断するために、バッチを即座に且つ簡単に検査・検討できることが望ましい。

現時点において、この問題を解決するには、バッチ運転中に収集された特定のプロセス変数に関するデータを監視し、それらのバッチ・パラメータを標準（norm）に対してグラフ化することがユーザに要求される。これらは、バッチプロセスが実際に正常な処理手順に応じて行われているか、バッチ出力が劣るような状態でバッチプロセスが逸脱したかどうか、バッチプロセスがもはや正常に機能していないことを示すような状態でバッチプロセスが作動しているか、を理解するために行われる。
米国特許出願第０９／３０２，６８７号

本発明は、上記問題を解決すべく成されたもので、プロセスプラント内のプロセス用設備により実施されるバッチプロセスのバッチ運転の１つ以上に関連したバッチデータを表示するためのプロセッサで実行されるように採用されるバッチ表示システムにおいて、多くの手作業によるデータ操作をユーザが行なう必要なく、バッチ運転を即座に且つ簡単に検査・検討すること、別のバッチ運転と比較すること、及び／又は特定のバッチ運転が標準（norm）から逸脱するかどうか判断すること、を可能にすることを目的とする。

本発明のバッチ表示システムは、プロセスプラント内のプロセス用設備により実施されるバッチプロセスのバッチ運転の一つ又は複数に関連したバッチデータを表示するためのプロセッサで実行されるように適用されるバッチ表示システムであって、メモリと、前記バッチプロセスのバッチ運転の一つ又は複数に関連したバッチデータを受信するために前記プロセスプラントに通信可能に接続されるように適用される通信ルーチンと、前記メモリ上に格納され、前記プロセッサに実行されるように適用され、前記バッチプロセスにおける一つ又は複数のバッチ運転中に生成された複数タイプのバッチデータを表すバッチ表示を生成するために適用され、且つ前記バッチ表示が、前記バッチプロセスのバッチ運転の一つ又は複数を実施中に異なるイベントが発生する時間を示す時間スケール及び前記時間スケールに関連して配置された多重化されたバッチデータ層を含む、バッチ表示アプリケーションと、を含み、前記バッチ表示が、異なるタイプの異なるイベントに関連した複数の異なるタイプのアイコンを含むことを特徴とする。

本発明のバッチ表示方法は、バッチプロセスのバッチ運転の一つ又は複数に関連したバッチデータを表示するバッチ表示方法であって、プロセスプラント内のプロセス用設備から、前記バッチプロセスのバッチ運転の一つ又は複数に関連した複数タイプのバッチデータを収集する工程と、前記バッチプロセスのバッチ運転の一つ又は複数に関連した複数タイプのバッチデータを図示するバッチ表示を表示し、且つ前記バッチ表示が、前記バッチプロセスのバッチ運転の一つ又は複数を実施中に異なるイベントが発生する時間を示す時間スケール及び前記時間スケールに関連して配置された多重化されたバッチデータ層を含むことを特徴とするバッチ表示画面を生成する工程と、を含み、前記バッチ表示が、異なるタイプの異なるイベントに関連した複数の異なるタイプのアイコンを含むことを特徴とする。

本発明のバッチ運転分析方法は、バッチプロセスのバッチ運転を分析するバッチ運転分析方法であって、プロセスプラント内のプロセス用設備から、前記バッチプロセスに関連した複数イベントの発生に関連したバッチデータを含む、前記バッチプロセスのバッチ運転の複数と関連したバッチデータを収集する工程と、前記収集されたバッチデータから、前記バッチプロセスに関連した前記複数イベントの各々の発生のタイミングに関する統計的尺度を含むバッチ署名を生成する工程と、ユーザーインターフェース機能を実行するために前記バッチ署名を使用する工程と、を含むことを特徴とする。

本発明のデータ処理システムは、バッチプロセスと関連した複数のイベントの発生に関連したバッチデータを含む、バッチプロセスにおける複数のバッチ運転用にデータを処理するためのデータ処理システムであって、メモリと、前記メモリ上に格納され、前記バッチプロセスに関連した複数のイベント各々の発生のタイミングに関係する統計的尺度を含むバッチ署名を生成するために前記バッチデータを使用する目的で、プロセッサにより実行されるように適用される第１のルーチンと、前記メモリ上に格納され、前記バッチ署名を使用してユーザーインターフェース機能を実行するために、前記プロセッサにより実行されるように適用される第２のルーチンと、を含むことを特徴とする。

本発明は、プロセスプラントのプロセス制御システム内におけるデータ収集及び表示用アプリケーションを備え、該アプリケーションは多くの手作業によるデータ操作をユーザが行なう必要なく、バッチ運転を即座に且つ簡単に検査・検討すること、別のバッチ運転と比較すること、及び／又は特定のバッチ運転が標準（norm）から逸脱するかどうか判断すること、を可能にするユーザ・インターフェースを提供する。

特に、上記のユーザ・インターフェースは、バッチに関するコンパクト型のグラフィック表示を提供又は作成する。コンパクト型のバッチ表示には、多重化されたバッチデータ層（a multiplicity of batch data layer）が含まれている。このグラフィック表示は、単独のバッチ運転を表示するか、その他の１つ以上のバッチ運転と比較するかのいずれかによって、ユーザが簡単にバッチ運転動作を表示又は理解できるようにする方式を用い、相互関連した状態で多くの異なるタイプのバッチ関連データを図示する。

一般的に言って、コンパクト型のバッチ表示には、ディスプレイ上に並置又は交互配置される多くのグラフィック層が含まれている。各グラフィック層は、バッチ動作や互いに同期化した時点について、異なるタイプの情報を提供するようになっている。

コンパクト型バッチ表示のベース層（base layer）が、バッチが開始又は作動した時点からバッチが終了又は停止する時間までを含む「バッチの所要時間（全所要時間）」を説明又は表示することが望ましい。一方、Ｓ８８標準により識別されるような、バッチプロセスの処理手順要素、ステップ又は段階の異なる態様を、１つ以上の付加層（additional layer）に表示してもよい。

なお、また、アラーム（警報）、アラート（警告）、イベント等は、その他の情報と共に、１つ以上の付加層（additional layer）に配置してもよい。また、バッチのコンパクト型グラフィック表示を提供するために、種々の層を共に表示するようにしてもよい。

コンパクト型グラフィック表示は、特定タイプのバッチプロセスのための「バッチ署名（batch signature）」又は特定の「バッチ処方（batch recipe）」を含むことが望ましい。このようなバッチ署名は、例えば、種々の処理手順要素の平均的な開始・終了時間、又は種々の処理手順要素の予想される開始・終了時間や、バッチ運転中に発生する種々のイベントやアラームなどに関連した統計的時間などを示すことで、多数の異なるバッチ運転の数学的又は統計的な表現として開発することが可能である。実際のバッチ運転又はモデル化されたバッチ運転から得られた、若しくは実際のバッチ運転及びモデル化されたバッチ運転の両方から得られた、１つ以上のデータの統計的尺度を利用して、バッチ署名を開発することが望ましい。

以上説明したように本発明によれば、多くの手作業によるデータ操作をユーザが行なう必要なく、バッチ運転を即座に且つ簡単に検査・検討すること、別のバッチ運転と比較すること、及び／又は特定のバッチ運転が標準（norm）から逸脱するかどうか判断することが可能になる、という効果がある。

以下、図面を参照して本発明の実施の形態の一例を詳細に説明する。

図１は部分的なブロック図であり、特にコンパクト型バッチ表示を作成し表示するのに使用されるバッチデータ収集及び表示用アプリケーションを含むプロセス制御ネットワークの一部を示す部分的な概略図である。ここで図１を参照して説明すると、プロセスプラント制御ネットワーク１０は、プロセス制御装置（コントローラ）１２を含んでいる。コントローラ１２は、ローカル・エリア・ネットワーク（ＬＡＮ）１５を介して、多数のワークステーション１４に接続されている。ＬＡＮ１５としては、例えば、イーサネット（登録商標）通信接続が一例として挙げられる。また、コントローラ１２は、プロセスプラント内の装置又は設備（符号１６を付してプロセスプラント１６と総称する）に、１つ以上の入出力（Ｉ／Ｏ）装置（図示せず）及び一式の通信線及び／又はバス１８を介して接続されている。

コントローラ１２は、Emerson Process Management社により販売されているDeltaV^TMバッチコントローラ等を一実施例として記載される。コントローラ１２は、１つ以上のプロセス制御ルーチンを行うことによりプロセスプラント１６の所望の制御を実施するために、プロセスプラント１６の全体に分散配置されるフィールド装置やフィールド装置内の機能ブロックなどの制御要素と通信することができる。これらのプロセス制御ルーチンは、連続プロセス制御ルーチンでありうるが、ここではバッチプロセス制御ルーチン又は処理手順として説明される。

ワークステーション１４は、例えば、パーソナルコンピュータ、サーバ等で構成することができる。ワークステーション１４は、一人又は複数のエンジニア、オペレータ、又はその他のユーザにより使用されて、コントローラ１２により実行される１つ以上のプロセス制御ルーチンを設計及び実行する。また、ワークステーション１４は、このようなプロセス制御ルーチンをダウンロードするためにコントローラ１２と通信する。また、ワークステーション１４は、プロセスプラント１６の作動中にプロセスプラント１６に関する情報を受信及び表示する。また、ワークステーション１４は、例えばコントローラ１２により実行されるプロセス制御ルーチンと交信する。

また、データ・ヒストリアン（履歴データツール）１９は、ＬＡＮ１５に接続されていてもよい。データ・ヒストリアン１９は、プロセスプラント１６内で生成されたデータだけでなく、コントローラ１２やフィールド装置に加えワークステーション１４内において生成されたデータを、いかなる周知又は所望の方法を用いて、自動的に収集し格納するようにしてもよい。

ワークステーション１４の各々は、メモリ２０を含む。メモリ２０は、システム構成（コンフィギュレーション）設計用アプリケーション等のアプリケーションを格納すると共に、プロセスプラント１６のコンフィギュレーションに関する構成データなどのデータを格納する。また、ワークステーション１４の各々は、１つ以上のアプリケーションを実行するプロセッサ２１も含む。このアプリケーションは、数ある特徴なかでも特に、ユーザがバッチ制御ルーチンなどのプロセス制御ルーチンを設計し、これらのプロセス制御ルーチンをコントローラ１２にダウンロードすることを可能とする。

同様に、コントローラ１２は、システム構成データとプロセスプラント１６の制御に使用されるプロセス制御ルーチンとを格納するメモリ２２を含んでいる。また、コントローラ１２は、プロセス制御法（process control strategy）を実施するためにプロセス制御ルーチンを実行するプロセッサ２４を含んでいる。コントローラ１２がDeltaVバッチコントローラである場合には、コントローラ１２は、ワークステーション１４の１つに格納される１つ以上のアプリケーションと協働して、プロセス制御ルーチン内の制御要素と、プロセスプラント１６の制御を提供するためにこれらの制御要素が構成される方法と、を図示して、コントローラ１２内のプロセス制御ルーチンのグラフィック式表示をユーザに提供する。

図１に実施例として示されるプロセスプラント制御ネットワーク１０において、コントローラ１２は、同じように構成された２組の設備にバス１８を介して通信可能に接続される。設備の各組は、ここでは反応器＿０１（Ｒ１）又は反応器＿０２（Ｒ２）と称される反応器ユニットと、ここではフィルタ＿０１（Ｆ１）又はフィルタ＿０２（Ｆ２）と称されるフィルターユニットと、ここでは乾燥器＿０１（Ｄ１）又は乾燥器＿０２（Ｄ２）と称される乾燥器ユニットと、を有する。

反応器＿０１には、反応槽１００と、例えばヘッドタンク（図示せず）から反応槽１００へ流体を供給する流体入口配管を制御するように接続された２つの入力バルブ１０１，１０２と、流体出口配管を介して反応槽１００からの流体の流れを制御するように接続された出力バルブ１０３と、が含まれる。

装置１０５は、温度センサ、圧力センサ、液面計測器などのセンサでもよく、又は電気的なヒータや蒸気ヒータなどの他の何らかの設備であってもよい。装置１０５は、反応槽１００に又は反応槽１００の付近に配置される。反応器＿０１は、フィルタ設備１１０を有するフィルタ＿０１にバルブ１０３を介して連結され、フィルタ設備１１０は乾燥器設備１２０を有する乾燥器＿０１に順に連結される。

同様に、２組目の設備には、反応槽２００、２つの入力バルブ２０１と２０２、出力バルブ２０３、及び装置２０５を有する反応器＿０２が含まれている。反応器＿０１は、フィルタ設備２１０を有するフィルタ＿０２に連結され、フィルタ設備２１０は乾燥器設備２２０を有する乾燥器＿０２に順に連結される。フィルタ設備１１０，２１０及び乾燥器設備１２０，２２０は、それに関連するさらに別の制御要素（ヒータ、コンベヤ・ベルト及びそれと同等のもの等）やセンサなどを備えていてもよい。

図示されてないが、各反応器、各フィルタ、及び各乾燥器の１つを使用するバッチ運転が、図１に示す設備のいかなる組合せをも使用することができるように、各々のフィルターユニット（フィルタ＿０１及びフィルタ＿０２）を各々の反応器ユニット（反応器＿０１及び反応器＿０２）に物理的に連結すると共に、各々の乾燥器ユニット（乾燥器＿０１及び乾燥器＿０２）を各々のフィルターユニット（フィルタ＿０１及びフィルタ＿０２）に連結することが望ましい。

図１に図示されるように、コントローラ１２は、バス１８を介して、バルブ１０１，１０３，２０１，２０３に、装置１０５，２０５に、フィルタ１１０，２１０に、乾燥器１２０，２２０に、及びそれらに関連する他の設備に、通信可能に連結されており、これらの要素（ユニット、フィールド装置等）の動作を制御し、これらの要素に関しての１つ以上の操作を行なう。このような操作としては、例えば、反応槽又は乾燥器の充填、反応槽又は乾燥器内の材料の加熱、反応槽又は乾燥器の排出、反応槽又は乾燥器の洗浄、フィルタの操作などが挙げられる。もちろん、コントローラ１２は、別のバスを介してプロセスプラント１６内の要素に連結することができるし、例えば４−２０ｍａ回線、ＨＡＲＴ通信線などの専用の通信線を介してプロセスプラント１６内の要素に連結することも可能である。

図１に図示されるバルブ、センサ、及びその他の設備は、例えば、Fieldbusで接続されたフィールド装置、標準の４‐２０ｍａ回線で接続されたフィールド装置、HARTで接続されたフィールド装置等を含む、どのような所望の種類又はタイプの設備でもよい。これらの設備は、Fieldbusプロトコル、HARTプロトコル、４−２０ｍａアナログ・プロトコル等、周知の又は所望の通信プロトコルを使用して、コントローラ１２と通信することができる。さらにまた、その他のタイプの装置を、所望の方法によりコントローラ１２に接続し、コントローラ１２により制御することができる。

また、プロセスプラント１６に関連したその他の装置（device）又は部位（area）を制御するために、その他のコントローラを、例えばイーサネット（登録商標）通信線路（ＬＡＮ１５）を介して、コントローラ１２及びワークステーション１４に接続することができる。そして、追加されたコントローラの動作は、所望の又は周知の方法で、図１に図示されるコントローラ１２の動作と統合調整（coordinate）することができる。

一般的に言って、図１のプロセス制御システムは、ワークステーション１４の１つが、
プロセスプラント１６内で異なるバッチ運転を実施し且つ場合によっては統合調整する「バッチ実行アプリケーション（batch execution application）」を実行するような、バッチプロセスを実施するために使用することもできる。このようなバッチ実行エンジン３０は、図１のワークステーション１４ａに格納された状態で図示されているが、当然のことながら、バッチ実行エンジン３０を、その他のワークステーション１４に格納し、実行することも可能である。

或いは、バッチ実行エンジン３０を、ワイヤレス方式を含む所望の方法によりＬＡＮ１５又はバス１８に通信可能に接続された、その他のコンピュータに格納し、実行することも可能である。同様に、バッチ実行エンジン３０を、種々の構成要素（component）に分割してもよい。或いは、バッチ実行エンジン３０を、プロセスプラント１６内の異なるコンピュータ又はワークステーションに格納され且つそれにおいて実行される種々の構成要素と関連させてもよい。

バッチ実行エンジン３０は、通常、ハイレベルの制御ルーチンであり、一般に「バッチ・キャンペーン・マネージャー（batch campaign manager）」と称されるものを含んでいる。バッチ・キャンペーン・マネージャーは、ユーザがプロセスプラント内にて行なわれる多くのバッチ運転を指定する（specify）ことを可能にすると共に、多くの異なるバッチ運転又はバッチプロセスを、プロセスプラント制御ネットワーク１０内で本質的に個々独立して操作できるように設定することを可能にする。また、バッチ実行エンジン３０は、バッチ・キャンペーン・マネージャーにより指定された異なるバッチ運転を、実施（implement）及び監視（oversee）する「バッチ・エクゼクティブ・ルーチン」又はアプリケーションを含んでいる。

このようなバッチ運転のそれぞれは、１つ以上の手順（procedures）、単位手順（unit procedures）、単位操作（operations）、フェーズ（phases）、及びバッチのその他の従属区域（sub-divisions）の動作を指示する。これら動作の各々は、プロセスプラント１６内の反応器ユニット、フィルターユニット、乾燥器ユニット、又はその他の設備の１つなど、単一ユニット上で作動する従属ルーチン又はプロセスである（又はあり得る）。この実施例においては、各単位手順は一連の単位操作を実行し、一連の単位操作の各々は
物理的ユニット上で１以上のフェーズを実行する。なお、各単位手順は、一般的にワークステーション１４の１つで実行されるバッチ運転の一部である。

本稿の説明において、フェーズ、単位操作、単位手順、及び手順（又は処理手順）という用語は、Ｓ８８標準により定義される処理手順要素を指す意味で用いられている。よって、「フェーズ（過程段階）」とは、ユニット上で実行される最下位レベルのステップ又はアクション（個々の動作・処置）であって、通常コントローラ１２のうちの１つにおいて実施又は実行されるものである。また、「単位操作」とは、ユニット上で特定の機能を実行する一式のフェーズであり、通常コントローラ１２内の一連のフェーズを呼び出すことによりワークステーション１４の１つで実施又は実行されるものである。また、「単位手順」とは、単一ユニット上で実行される１つ以上の一連の単位操作であって、通常、ワークステーション１４の１つを呼び出す一式の単位操作として実施されるものである。

同様に、「処理手順」とは、例えば、プロセスプラント１６内の異なる物理的装置で実行されうる一式の単位手順である。従って、どのような処理手順であっても１つ以上の単位手順を含むことができ、どのような単位手順であっても１つ以上のフェーズ及び／又は１つ以上の単位操作を含むことができる。このように、各バッチプロセスは、例えば、食品や医薬品などの製品を製造するために必要とされる、異なるステップ又は段階（例えば、単位手順）を実行する。

個々のバッチ用に異なる手順、単位手順、単位操作、及びフェーズを実施するために、バッチプロセスは一般に「処方（レシピ）」と呼ばれるものを使用する。「処方」は、実行すべきステップや、該ステップ及び該ステップの順序に関連する量及び時間を指定する。

例えば、１つの処方を構成する複数のステップには、適切な材料又は成分を反応槽に充填すること、反応槽内の材料を混合することと、反応槽内の材料を特定の時間をかけて特定の温度まで加熱すること、次のバッチを準備するために反応槽を空にした後に反応槽を洗浄すること、及び反応器の出力物をろ過するためフィルタを稼動した後に、反応槽中に作り出された製品を乾燥するために乾燥器を稼動させることが、含まれる。

異なるユニットに関連した一連のステップの各々は、バッチの単位手順を定義し、バッチプロセスは、これらの単位手順の個々それぞれに対して異なる制御アルゴリズムを実行することになる。もちろん、特定の材料、材料の量、加熱温度及び時間などは、処方ごとに異なる。その結果として、これらのパラメータは、製造又は生産される製品、及び使用される処方によって、バッチ運転ごとに変化する。

当業者にとっては当然のことながら、標準的な(generic）バッチプロセスの同じフェーズ、単位操作、単位手順、及び手順は、異なる実際のバッチプロセス又はバッチ運転の一部として、同時に又は異なる時点で、図１に示されるような異なる反応器ユニットのそれぞれで実施できる。更に、図１に示す反応器ユニットは、一般的に同じ数及び同じタイプの設備（例えば、同一のユニット・クラスに属する）を含むので、異なる各々の反応器ユニットを制御するために、特定のフェーズ用の同じ標準的フェーズ制御ルーチンが使用される。但し、異なる反応器ユニットに関連した異なるハードウェア又は設備を制御するために、標準的フェーズ制御ルーチンを修正変更しなければならない場合は除く。

例えば、反応器＿０１の充填フェーズ（反応器ユニットが充填されるフェーズ）を実施するために、充填制御ルーチンによって入力バルブ１０１又は１０２の１つ以上が、特定の時間（例えば、液面計測器１０５によって反応槽１００が満杯となったことが検知されるまで）開かれることになる。しかしながら、単に入力バルブの指定をバルブ１０１又は１０２からバルブ２０１又は２０２に変更すると共に、液面計測器の指定を液面計測器１０５から液面計測器２０５に変更するだけで、同じ制御ルーチンを使用して反応器＿０２の充填フェーズを実施することができる。言うまでもなく、バッチ運転の一般的な動作に関連した論理は周知のことであるため、ここでは更なる説明は行わない。

図１に戻って説明すると、ワークステーション１４の１つ又は複数は、また、コントローラ１２、データ・ヒストリアン１９、及びバッチ実行エンジン３０の一つ又は複数とインターフェース接続された「バッチ・ディスプレイ・アプリケーション（ＢＤＡ）」３２を格納し、実施しうる。ＢＤＡ３２は、バッチデータを収集して、コンピュータ画面やプリンターなどの表示装置上にユーザのための表示画面を生成する。その表示画面は、１つ以上のバッチ運転の動作を、コンパクトで分かり易い方法で表示する。

図１では、ワークステーション１４ａだけがＢＤＡ３２を含む状態で図示されているが、他のワークステーション１４の外に、ＬＡＮ１５に接続されたその他のコンピュータ又はそれを含むワークステーション１４の１つでも、ＢＤＡ３２を格納し、実施することが可能である。

同様に、ＢＤＡ３２を実施するコンピュータは、有線接続又は無線接続（或いは、両者混在）を介して、プロセスプラント制御ネットワーク１０に接続することが可能であり、さらにラップトップ（laptops）、個人用データ補助装置（personal data assistants;ＰＤＡ）や携帯電話（cell phones）等のハンドヘルド装置（hand held devices）、又はその他の携帯型又は非携帯型のコンピュータ装置などの装置を含むことが可能である。

バッチ表示画面には、ここでは図１に図示されるような反応器ユニット、フィルターユニット、及び乾燥器ユニットを使用したバッチが表示されているが、その他のいかなる所望のバッチプロセスの実行を行う所望の装置の動作を図示するために、表示ルーチンを使用しうることは、当業者であれば理解できるはずである。

図２は、複数のバッチ実行エンジン３０を実施するために、望ましくは複数のＢＤＡ３２を実施するために、プロセス制御システムで使用しうる周知のクライアント／サーバ・ネットワーク４０のブロック図である。具体的には、ネットワーク４０には、一式のクライアント・コンピュータ又はノード４２（以下、「クライアントノード４２」という）と、一式のサーバ・コンピュータ又はノード４４（以下、「サーバノード４４」という）とが含まれる。これらクライアントノード４２とサーバノード４４とは、プロセスプラント内のバッチ・エクゼクティブ・ルーチン及び／又はバッチ・ディスプレイ・アプリケーション（ＢＤＡ）のうちの一つ又は複数を有効にして実施するために、使用しうるバス（又は、その他の通信ネットワーク）４６を介して接続される。

一般的に、図２のバッチ・ネットワーク・アーキテクチャは、従来ながらのツーティア（２階層式）のクライアント／サーバに基づく設計として示されている。このアーキテクチャでは、クライアントノード４２がサーバノード４４へ指令又はメッセージを与え、該サーバーノード４４がその後プロセスプラント内の実際のバッチ（図示せず）を実行させる。クライアントノード４２は、通常、１つ以上のオペレータ・インタフェース・アプリケーションを含む。オペレータ・インタフェース・アプリケーションは、ユーザがプラントに適用できる所望のあらゆる実施方法（strategy）を使用してプロセスプラント内の複数のバッチ運転を設定及び構成することを可能にすると共に、１人以上のユーザがプラント内で動作するバッチと関係するバッチデータを表示することを可能にする。

図２において、３つのクライアントノード４２ａ、４２ｃ及び４２ｄは、バッチ・オペレータ・インタフェース（ＢＯＩ）アプリケーション４８を含んだ状態で図示されている。ＢＯＩアプリケーション４８は、オペレータが、実行すべき（例えば、１つ以上のバッチ運転を開始するために）個別バッチを設定及び指定することを可能にするために、オペレータとインターフェース接続するルーチンである。同様に、クライアントノード４２ｂ及び４２ｃは、キャンペーン・マネージャー・オペレータ・インタフェース（ＣＭＯＩ）アプリケーション５０を含んだ状態で図示されている。ＣＭＯＩアプリケーション５０は、ユーザが、プロセスプラント内で将来的に特定の順番で又は特定の時間で、稼動又は実行すべきバッチ運転（通常、複数の連続するバッチ運転を含む）のキャンペーンを設定することを可能にする。キャンペーンは、生産スケジュールを意味する。

このようなキャンペーン・マネージャー・アプリケーションの１つが、２００６年３月２８日公開された「Campaign Management for Batch Processes（バッチプロセスのキャンペーン管理）」と題する米国特許第７，０２０，８７６号に詳細にわたり記載されている。当該特許開示はここに参照することにより本稿において明示的に援用される。当然のことながら、その他のＢＯＩ及びＣＭＯＩのアプリケーションも周知であり、同様にこれらを使用しうる。

また、２つのクライアントノード４２ｃ及び４２ｄが、バッチ・ディスプレイ・アプリケーション（ＢＤＡ）３２を含んだ状態で図示されている。ＢＤＡ３２は、バッチ運転の動作中に又はバッチ運転後のいずれかに、プロセスプラント内で実行された１つ以上のバッチプロセスに関連するコンパクト型バッチ表示を提供する。しかしながら、ＢＤＡ３２を、ＢＯＩアプリケーション４８及び／又はＣＭＯＩアプリケーション５０の１つの一部として、又はその他のユーザ・ディスプレイ・アプリケーションの一部として実施することが望ましい。

通常、サーバノード４４ａ、４４ｂ及び４４ｃの各々は、周知のバッチ・エクゼクティブ・ルーチン又はアプリケーション５２（以下、「バッチ・エクゼクティブ・ルーチン５２」という）を有するバッチサーバである。バッチ・エクゼクティブ・ルーチン５２は、クライアントノード４２ａ、４２ｃ及び４２ｄ内における１つ以上のＢＯＩアプリケーション４８及び／又はＢＤＡ３２との双方向通信を確立すると共に、プロセスプラント内の別々のバッチを１つ又は複数同時に実施及び監視する。

同様に、サーバノード４４ｄは、キャンペーン・マネージャー・サーバ・アプリケーション５４（以下、「キャンペーン・マネージャー・サーバ５４」又は「ＣＭサーバ５４」という）を含む。キャンペーン・マネージャー・サーバ５４は、ＣＭＯＩアプリケーション５０及び／又はＢＤＡ３２との双方向通信を確立して、サーバノード４４ａ、４４ｂ及び４４ｃ内で（バッチ開始要求を使用して）バッチ・エグゼクティブ・アプリケーション５２とインターフェース接続される又は通信することにより、ＣＭＯＩアプリケーション５０を使って作成されたバッチキャンペーンを実施する。

従来、図２のクライアント／サーバ・アーキテクチャは、より効果的なフォルトトレランス（耐故障性）を提供するために、サーバアプリケーションからクライアントアプリケーションを分離するのに使用されてきた。

サーバノード４４ｂのバッチ・エグゼクティブ・アプリケーション５２に図示されるように、バッチ・エグゼクティブ・アプリケーション５２は、プロセスプラント１６内のバッチ運転を一つ又は複数実施するために、キャンペーン・マネージャー・サーバ５４及びＢＯＩアプリケーション４８により送信されたバッチ開始要求に対して応答する。

当然のことながら、サーバノード４４ｂは、１つ以上のコントローラ１２に通信可能に接続される。コントローラ１２は、例えば、図１に図示されるように、プロセスプラント内の１つ以上の装置、ユニットなどに順に通信可能に接続される。

図３はコンパクト型バッチ表示の作成及び表示に使用されるバッチイベント・ヒストリアンを含むバッチ履歴のロギング（ログ記録）及びレポーティング（報告）システムを表すブロック図である。図３では、１つ以上のバッチ運転から得られるバッチデータを収集・格納した後に、コンパクト型バッチ表示を作成する際に使用するために、バッチデータをＢＤＡ３２に提供する方法を説明する。特に、１つ以上のバッチプロセスのバッチ運転のうちの１つ又は複数に関するイベント情報を収集、格納、検索するためのバッチイベント・ヒストリアン３００を示す。バッチイベント・ヒストリアン３００は、１つ以上のコンパクト型バッチ表示を作成するために必要とされるデータについて、該データが検出又は生成される様々な供給源からのデータの収集を自動化する。

特に、バッチイベント・ヒストリアン３００は、複数のデータ供給源からイベント情報を受信して、収集されたイベント・データの様々な要素の関係を判断するバッチ・ヒストリアン・エグゼクティブ３０２を含む。さらに具体的に述べると、バッチ・ヒストリアン・エグゼクティブ３０２は、プロセスイベント・ログ３０４及びプロセスイベント・サーバ３０５から、プロセスイベント３０３を受信する。当然のことながら、プロセスイベントは、物理的装置及び／又はオペレータによるバッチ（図示せず）との交信により生成され、通常、図１のデータ・ヒストリアン１９に格納されうる。

プロセスイベント・ログ３０４は、プロセスイベント・サーバ３０５により処理されるこのようなイベントのバッファリング（緩衝）用のバッファ（例えば、プロセス間の通信を行うFIFOやパイプ等の緩衝素子）を表す。バッチ・ヒストリアン・エグゼクティブ３０２は、また、バッチイベント・ログ３１４及び１つ以上のバッチイベント・サーバ３１６を介して、バッチサーバ・イベント（以下、「処理手順イベント」とも称される）３１２を受信する。

一般的に、バッチサーバ・イベント３１２は、バッチプロセスを実行するバッチサーバプロセス（図示せず）により生成されるものである。また、バッチサーバ・イベント３１２は、例えば、図１と図２に示される、コントローラ１２の１つ、バッチ・エグゼクティブ・エンジン３０、バッチ・エクゼクティブ・ルーチン５２、ＣＭＯＩアプリケーション５０、及びキャンペーン・マネージャー・サーバ５４の１つにより開発される。従って、バッチイベント・ログ３１４は、バッチイベント・サーバ３１６により処理されるこのようなイベントをバッファリング（緩衝）するバッファ（例えば、プロセス間の通信を行うFIFOやパイプ等）を表わしうる。

プロセスイベント・サーバ３０５及びバッチイベント・サーバ３１６は、バッチ・ヒストリアン・エグゼクティブ３０２とその関連データ供給源との間に、共通のプロセス間通信インターフェースを提供するために存在する。関連データ供給源は、バッチイベント・ログ３１４とプロセスイベント・ログ３０４内の、バッチイベント及びプロセスイベントを生成するような関連データ供給源である。しかしながら、当業者には、バッチ・ヒストリアン・エグゼクティブ３０２が、可能性として異なるデータ形式を有する種々様々なデータ供給源からデータを収集することを可能にする同等のソフトウェア構造がその他にも数多く存在することが明らかなはずである。

したがって、図３に示される実施形態は、前記のようにバッチ・ヒストリアン・エグゼクティブ３０２と種々様々なデータ供給源との間の単一で共通するインターフェースを可能にするための設計上の選択上の一例として示されている。また、当業者であれば、これらの様々なデータ供給源により生成されたイベント間のイベント関係を判断するために、バッチ・ヒストリアン・エグゼクティブ３０２によって、いかなる数のデータ供給源をも統合しえることが明らかなはずである。各データ供給源は、周知のプロセス間通信技法を介して、データ供給源を標準フォーマットに翻訳し、この標準データをバッチ・ヒストリアン・エグゼクティブ３０２に供給するために、サーバプロセスに関連することが望ましい。

実際には、任意の数のデータ供給源を、バッチ・ヒストリアン・エグゼクティブ３０２に接続することが望ましい。この概念を図示するために、別のイベント・ブロック３４１が図３に示されており、永続的な記憶機構（persistent store）に記録される前記のような別タイプのイベントを表わす。また、これら別タイプのイベントは、通常、バッチ処理階層（例えば、処理手順要素）及び／又はプロセスの物理的要素に関係する。前記のような別タイプのイベントのログ３４２（以下、「その他のイベントログ３４２」という）は、このようなイベントの生成を、処理工程用にバッファ（緩衝）する機能を果たす。

その他のイベントサーバ３４４は、その後、ログ記録されたその他のイベントを処理して、永続的に格納するために、それらをバッチ・ヒストリアン・エグゼクティブ３０２に提供する。当業者であれば、このようなデータ供給源はいかなる数でもバッチ・ヒストリアン・エグゼクティブ３０２に接続し得ること、そしてこのようなデータ供給源の各々が、ログ記録されたイベント情報をバッチ・ヒストリアン・エグゼクティブ３０２入力用に指定された標準フォーマットに変換するサーバプロセスと関連し得ること、が明らかなはずである。

バッチ・ヒストリアン・エグゼクティブ３０２は、バッチサーバ・イベント３１２から受信されたイベントメッセージから、実行された処理手順イベントのバッチプロセス手順階層を再構成する。バッチ・ヒストリアン・エグゼクティブ３０２は、識別された特定のバッチのために、各処理手順要素が実行されるとメッセージを生成しうる。また、このようなメッセージ中のイベント情報には、特定の処理手順要素及び該イベントの時間を識別するための識別情報が含まれる。例えば、イベントには、開始、停止、一時停止、中断等の手順要素が含まれる。本質的に、Ｓ８８標準の手順制御モデルの状態遷移は、イベント情報メッセージの生成と、そのメッセージの（バッチイベント・サーバ３１６を介する）エグゼクティブ３０２への送信と、を生じさせる。その他のイベントメッセージは、バッチ・ヒストリアン・エグゼクティブ３０２によって、再構成された処理手順の階層と関係しうる。

バッチ・ヒストリアン・エグゼクティブ３０２は、再構成されたバッチプロセス手順の実行を反映するオブジェクトをデータベース３４０に格納する。また、望ましくは、バッチ運転のために、コンパクト型バッチ表示を作成する。バッチ・ヒストリアン・エグゼクティブ３０２は、接続されたデータ供給源から収集されたイベント情報を全て点検すると共に、そこで参照されたバッチイベントが、バッチ・ヒストリアン・エグゼクティブ３０２に既に認識されているかどうか判断する。このようなイベントは、本質的には、オブジェクトとしてデータベース３４０に既に格納されていると判断された場合に、バッチ・ヒストリアン・エグゼクティブ３０２に認識される。

新しいバッチイベントが検出された時点で、適切な記述的オブジェクトが生成され、データベース３４０に格納される。例えば、フェーズが開始された時点で、識別情報及びタイムスタンプ情報を含む当該フェーズのオブジェクトが生成されて格納される。フェーズがデータベース３４０に既に認識されている単位操作に関連する場合に、このような関係が確立される。

単位操作（又は、単位手順又は手順）が目下認識されていない場合には、その他のオブジェクトが生成され、データベース３４０に格納されて、これらの手順階層実行におけるより高いレベルを反映しうる。したがって、バッチイベント・サーバ３１６を介して各バッチイベントメッセージを受信することにより、バッチ・ヒストリアン・エグゼクティブ３０２がバッチ処理手順実行を再構成することを可能にするイベント情報が提供される。

バッチ・ヒストリアン・エグゼクティブ３０２は、プロセスイベント・ログ３０４及びプロセスイベント・サーバ３０５を介して受信されたプロセスイベント３０３も、データベース３４０に格納する。バッチイベントとプロセスイベントとの関係は、これによって、ユーザのマニュアル操作による構成作業を必要とせずに、自動的に作成されて、保持される。

また、オブジェクトＡＰＩ３５０は、データベース３４０に格納されたイベント情報及び派生関係（derived relationships）、並びにデータベース３４０に格納されたコンパクト型バッチ表示のいかなるものにも、ユーザがアクセスできるようにオブジェクト指向型プログラミング・インターフェースを提供する。１つの実施形態において、バッチイベント・ヒストリアン３００は、データベース３４０に格納された情報への外部アクセス用に、ＳＱＬ（Structured Query Language; 構造化照会言語）インターフェース３５２を提供する。

従って、オブジェクトＡＰＩ３５０は、ＯＤＢＣ（Open Databese Connectivity）ドライバー３５４とＳＱＬインターフェース３５２を介して、データベース３４０にアクセスする。この構造により、下層に在る永続的記憶機構（persistent store）が、ユーザ又はアプリケーション・クライアント・プログラムにとって、非常に明白なものとなる。図３に示すように、ＯＯＤＢＭＳ（オブジェクト指向データベース管理システム）技術を使用して、永続的記憶機構を実施しうる。しかしながら、隠れた下層にある構造に鑑み、標準の関係モデルデータベース管理パッケージ又はその他の構造化記憶従属システムデータベースを使用して、永続的記憶機構を実施しうる。

更に説明を行うにあたり、市販のいかなる記憶管理ツールを使用していかなる公知の方法において記憶機構アーキテクチャを構造化しうることを強調するために、データベース３４０は、永続的記憶機構（persistent store）、永続的格納機構（persistent storage）、オブジェクト記憶機構（object store）、又はその変形と、同義的な意味で使用される。

代表的なユーザ・アプリケーション３６４〜３７０は、オブジェクトＡＰＩ３５０を使用して、永続的格納機構内の情報にアクセスしうる。表示クライアント（view client）３６４は、取得した履歴データ（historical data）の標準化階層表示を提供すると共に、ここに記載されるようなコンパクト型バッチ表示を提供するのに使用されうる代表的なユーザ・アプリケーションである。レポート・クライアント（report client）３６６は、履歴データから標準化レポートを作成する代表的なユーザ・アプリケーションである。

このような標準レポートは、例えば、生産されたバッチの品質及びバッチプロセスで使用された設備を監視するための品質保証関連レポートや、特定のバッチプロセスの進行を示す標準状態レポートを含みうる。ＳＱＬブラウザークライアント３６８は、永続的格納機構に格納された情報をブラウズ（照合検索）するためのＳＱＬ標準照合インターフェースを、ユーザに提供する代表的なユーザ・アプリケーションである。

同様に、ユーザＳＱＬ・ＡＰＩ３７０は、その他のユーザにより生成されたアプリケーション・プロセスが、標準照合プログラミング・インターフェースを使用して、永続的格納機構にアクセスすることを可能にする代表的なユーザ・アプリケーションである。当業者には、代表的なユーザ・アプリケーション３６４〜３７０が、永続的格納機構内のデータを利用しうる共通アプリケーション・プログラムの単なる一例にすぎないことが明らかなはずである。また、当業者には、永続的格納機構におけるデータに、この標準インターフェースを利用できる同じようなアプリケーションが、その他にも種々存在することが明らかなはずである。

オブジェクトＡＰＩ３５０のさらなる機能としては、連続データ３８０にアクセスするための標準インターフェースをユーザに提供することが挙げられる。オブジェクトＡＰＩ３５０は、ユーザ又はアプリケーションが、連続データ３８０に透過的（transparently）にアクセスできるようにする。即ち、あたかもこの連続データ３８０がデータベース３４０中のオブジェクトに統合され、関係付けられているかのように、アクセスできるようにする。

言い換えれば、オブジェクトＡＰＩ３５０は、ユーザ又はアプリケーションが、プロセスイベント、関連するバッチイベント、及び関連する連続データを、これらデータの全てが単独のデータベースに格納されているかのように、自在に混合しアクセスできるようにする。そして、これにより、これら異なるタイプのデータの一部又は全部を用いてコンパクト型バッチ表示を作成することを可能にする。ユーザによる適切な永続的記憶機構（例えば、データベース３４０又は連続データ３８０）へのアクセスの指示と、データを要求に関連づけるのに必要な全関係の決定とは、オブジェクトＡＰＩ３５０により共通のユーザーインターフェースで処理される。

ユーザは、特定のバッチイベントを指定できると共に、すべての関連するバッチイベント（階層的に関連する処理手順要素）、すべての関連するプロセスイベント、及びすべての関連する連続データ等にアクセスできる。諸データ間における関係は、バッチ・ヒストリアン・エグゼクティブ３０２及び／又はオブジェクトＡＰＩ３５０により、自動的に決定される。

診断インターフェース３９０及び管理インターフェース３９２は、永続的記憶機構（例えば、データベース３４０）を管理するための管理ユーザーインターフェース（administrative user interface）を提供する。特に、ヒストリアン処理を開始又はシャットダウン（停止）する要求や、永続的記憶機構を再構成する要求（即ち、データベース３４０のサイズを変更する、又はデータ供給源についての情報を追加／削除／修正変更する）が、診断インターフェース３９０及び／又は管理インターフェース３９２を介して、ユーザにより生成される。

また、管理インターフェース３９２は、バッチ・ヒストリアン・エグゼクティブ３０２アーカイブ（記録保管）機能を制御しうる。例えば、バッチ・ヒストリアン・エグゼクティブ３０２は、バッチごとのバックアップ（特定のバッチの処理に関係する永続的記憶機構中のイベント情報をすべて予備保存した予備用保存データ）を、制御可能な状態で実行してもよい。該バックアップは、データベース３４０の別の部分に作成することができ、また、その他の処理用に保存することができる。永続的記憶機構のこれらのバックアップ部分は、オフライン処理用のデータベース３４０から「切り離す（detached）」ことができる。

本質的に、管理インターフェース３９２は、バッチ・ヒストリアン・エグゼクティブ３０２に対して、特定された１以上のバッチ用に、全イベント情報の「スナップショット」を作成する指示を行う。その後、オフライン処理技法によって、スナップショットを安全なバックアップにコピーしうる。このような（スナップショットとして）アーカイブ記録された一式のイベント情報は、その後、さらなるバッチ履歴情報（batch history information）を格納するメモリ空間を確保するために、永続的記憶機構から削除しうる。

後に、データを再度表示し操作できるようにするために、先のアーカイブ記録をデータベース３４０に復元（restore）又は再添付（re-attach）することができる。このようなアーカイブ記録された情報の削除（deletion）及び復元（restoration）は、バッチ・ヒストリアン・エグゼクティブ３０２を制御する管理インターフェース３９２を制御することによっても実行される。

当業者には、診断インターフェース３９０及び管理インターフェース３９２が、図３に図示されたバッチイベント・ヒストリアン３００の動作に必要とされないこと、そして種々様々の異なる又は同等の構成が、図３に記載される要素の各々に対する当業者による設計上の選択として採用されうることが明らかなはずである。例えば、バッチイベント・ヒストリアン３００は、永続的格納機構を静的に構成しうる、及び又はその動作を開始及び停止するためのユーザーインターフェース無しでも作動しうる。

また、当業者には、バッチイベント・ヒストリアン３００及び関連オブジェクトＡＰＩ３５０のアーキテクチャは、本質的に代表例としてのみ示されていることが分るはずであり、当業者にとってはその他にも該アーキテクチャの変形が多数思い当たるであろう。例えば、既存の設置システム（一般にレガシー・システムと呼ばれる）の場合、このような情報の永続的格納機構へのログ記録を提供することには関与しないデータベース３４０内で、連続データ３８０を組み合せる（マージする）ことが可能である。

また、イベント情報用の永続的記憶機構は、オブジェクト指向型データ記憶機構以外のものでありうる。或いは、バッチ・ヒストリアン・エグゼクティブ３０２は、入力を標準フォーマットに翻訳するためにサーバプロセスに依存するのではなく、むしろイベント情報を提供する様々な入力源に直接アクセスしうる。言うまでも無く、その他多くの設計上の選択が存在することが当業者には明らかであろう。

過去においては、図１及び図２のバッチ実行エンジン３０、ＢＯＩアプリケーション４８、バッチ・エクゼクティブ・ルーチン５２により実施されたバッチプロセス又はレシピのバッチ運転、及び／又はＣＭＯＩアプリケーション５０及びキャンペーン・マネージャー・サーバ５４により確立されたバッチプロセス又はレシピのバッチ運転のそれぞれに対して、データが収集されていたが、これらデータの表示は期待されるほど簡単でも有用でもない。実際、バッチデータが通常ユーザに提示される場合には、ユーザは一般的に特定のバッチのそれぞれにおいて個々の設備から収集された生データを表示しなければならない。このような作業には多大なる忍耐と時間とを要する。また、バッチの現在の動作を表示しようとする際には、優れた効果を発揮できるとは言い難い。

また、バッチ内の特定の処理手順、単位手順、単位操作、及びフェーズの開始・停止時間などの重要なイベントについて、特定のアラーム又はイベントがこれらの処理手順要素実行中に発生したか否かについて、或いは個々のバッチ運転に関連するその他のタイミングに関する問題について、ユーザが調査・検索するときには、ユーザは大量のデータを表示しなければならないか、これらの異なるタイプのデータを表示するために、異なるデータベース又はデータベースの異なる部分を検索しなければならない。

米国特許出願第０９／３０２，６８７号には、ユーザがガント図表を表示して、バッチ運転の処理手順、単位手順、単位操作、及びフェーズに関し、異なる開始・停止時間を表示できるようにするシステムが記載されているが、このシステムにおいてもやはりユーザは、ガント図表をクリックしたり、その他の画面を表示したりして、連続データ及び警報データなどの他のデータにアクセスしなければならない。更にまた、一般的にガント図表の性質とバッチ運転又はバッチプロセスの長さとに応じて、ガント図表の表示には、かなりの量の表示スペースを必要とし、多数の処理手順要素が互いに縦断的に配置されることになるため、若干使いにくい表示となる。

これらの問題を削減又は緩和するために、ＢＤＡ３２は、図３の表示クライアント３６４の１つとして作動してもよい。また、ＢＤＡ３２は、バッチプロセスのバッチ運転用のコンパクト型バッチ表示の１つ又は複数、及び／又はバッチプロセス用に統計に基づくバッチ署名の１つ又は複数を、作成又は表示するためにバッチデータにアクセスしうるものである。

コンパクト型バッチ表示及びバッチ署名を作成するために、ＢＤＡ３２には、バッチプロセスの１以上のバッチ運転についてバッチイベント及びプロセスイベントに関連したバッチデータを得るために、プロセスプラント内のデータ・ヒストリアン、その他のデータベース又はその他の装置と通信する「通信ルーチン」と、バッチデータに関連した様々な統計的尺度を決定するために、これらデータを処理する「データ処理ルーチン」と、得られたデータ及び／又は処理されたデータを（コンピュータに関連した表示画面、個人用データ補助装置、無線電話，又はその他のハンドヘルド装置などの）画面上に表示して、ユーザに提示する「表示又はユーザーインターフェース・ルーチン」と、を含みうる。

図４は特定のバッチプロセス用のコンパクト型バッチ表示の実施例を示す。ＢＤＡ３２により生成されるコンパクト型バッチ表示の一例が、図４の表示画面４００に図示されている。一般的に言って、図４の表示画面４００は、コンパクト型バッチ表示部分（compact batch view section）４０２を含む。コンパクト型バッチ表示部分４０２は、本実施例においては、特定のバッチ運転のための単一コンパクト型バッチ表示４０４として図示される。また、表示画面４００は、バッチ一覧部分（batch list section）４０８を含む。バッチ一覧部分４０８は、表示部分４０２において選択でき且つ表示しうるバッチの一覧又はコンパクト型バッチ表示を含む。

同様に、表示画面４００は、コンパクト型バッチ表示４０２において使用される凡例又はアイコンの一覧を提示する凡例部分（legend section）４１０と、ユーザにより作動可能又は選択可能な一式のユーザボタン４１２と、を含む。ユーザボタン４１２は、バッチ一覧部分４０８に示されるような異なるコンパクト型バッチ表示をスクロールするため又は開くために使用されるか、これらのコンパクト型バッチ表示の一つ又は複数を削除するために使用される。

当然のことながら、図４の凡例部分４１０（コンパクト型バッチ表示４０４と同様）に示される「凡例」又は「アイコン」は、形状、サイズ、色などが異なったものでもよい。また、凡例部分４１０は、バッチ処理手順、単位手順、単位操作、フェーズ等の異なるタイプのバッチイベントの開始又は終了時間や、アラームのようなプロセスイベントの開始又は終了時間など、いくつかの態様を示す。これらはすべて単一コンパクト型バッチ表示４０４に図示されている。

しかしながら、凡例部分４１０は、その他のタイプの凡例も含みうる。その他のタイプの凡例には、イベント、警報、処理手順及び操作を含む、その他のタイプのプロセスイベント、プロセス警報、バッチ処理手順イベントなどが含まれる。また、その他のタイプの凡例には、Ｓ８８標準を用いる以外の様態で定義されるバッチ従属手順のその他の指標が含まれる。

説明からも明らかとなるように、コンパクト型バッチ表示４０４は、バッチ一覧部分４０８で特定され（highlighted）又は選択されたバッチについて、表示部分４０２に表示される。また、図４に図示されるように、コンパクト型バッチ表示４０４は、ベース層（base layer）４２０を含む。ベース層４２０は、特定のバッチ運転の開始・終了時間や、時間スケール４２２により定義されるような特定のバッチ運転の全体の実施期間を示す。図４のコンパクト型バッチ表示４０４の場合、時間スケール４２２は、バッチ運転の始点に相関した時間として示される。

しかしながら、これに限られず、時間スケール４２２は、バッチ運転に関連するその他の時間に相関するようにもできる。また、バッチ運転の（望ましい場合は日付や年度などを含む）実際の開始・終了時間を示す実時間や、当該バッチ運転と関連した様々な実時間を示すようにもできる。もちろん、その他のバッチ運転又はプロセスイベントに相関する時間スケールや、（バッチ運転の開始時間の代わりに）特定のバッチ運転におけるその他のイベントに相関する時間スケールなど、その他の時間スケールも使用しうる。

なお、また、その他様々な層をベース層４２０に追加して、バッチ運転に対するコンパクト型バッチ表示を生成することができる。特に、下側データ層４２３は、図４のベース層４２０の下に図示されており、事前に定義されたアイコン又は凡例を用いて、バッチ運転に関連した処理手順、単位手順、単位操作、及びフェーズの１つ又は複数に関する開始及び終了時間など、様々な異なるバッチ処理手順要素の開始・終了時間を示している。説明から明らかなように、単位手順は一般に処理手順の従属手順であり、単位操作は一般に単位手順の従属手順であり、フェーズは一般に単位操作に関連した従属手順である。

従って、図４のコンパクト型バッチ表示４０４においては、このバッチの特定の処理手順が第１のタイプの開始・終了時間凡例４２４により図示され、処理手順に関連した単位手順が第２のタイプの開始・終了時間凡例４２６により図示され、単位手順に関連した単位操作が第３のタイプの開始・終了時間凡例４２８により図示され、そして当該単位操作のフェーズが第４のタイプの開始・終了時間凡例４３０により図示されている。

さらに、１つのバッチ処理手順要素のアイコン又は凡例（即ち、第１のタイプのアイコン）を、同一のデータ層に（例えば、同一の水平線上又はレベル上に）配置しうる。また、１つのバッチ処理手順要素のアイコン又は凡例を、第２のバッチ処理手順要素のアイコン又は凡例（即ち、第２のタイプのアイコン）の間に配置しうる。このような配置により、異なる階層の処理手順要素に関連したデータの識別又は表示を分り易くする又は表示し易くする。

もちろん、バッチ処理手順の多くが多数又は複数の単位手順や単位操作及びフェーズなどの複数の従属要素を持つことになり、バッチ単位手順の多くが複数の単位操作及びフェーズを持つことになり、そしてバッチ単位操作の多くが複数のフェーズを持つことになる。このような実施例は、図４に示されていないが、当該の事例においては、結果的に得られるコンパクト型バッチ表示が、下側データ層４２３内において複数のフェーズ、複数の単位操作、複数の単位手順及び複数の処理手順に対して複数の開始・終了時間凡例を持つことになる。

さらにまた、ベース層４２０の上に図示される第３の層（上側データ層）４３１は、例えば、バッチ運転中に発生したプロセスイベント又はバッチイベントを含むその他のイベントの指標又はアイコンを含む。これらのアイコンは、下側データ層４２３のバッチ処理手順要素を図示するのに使用されたアイコンとは異なるタイプであるとして図示される。このようなイベントの一例としては、バッチ運転中に生成されたプロセス警報及びプロセス警告が挙げられる。

図４に実施例として挙げられるコンパクト型バッチ表示４０４においては、５つのアイコンからなる一団の警報アラーム４３２が、凡例４３０の印が付いたフェーズ中に発生している状態で図示されている。また、４つのアイコンからなる一団の警報アラーム４３４が、凡例４２６の印が付いた単位手順が終了後、凡例４２４の印が付いた処理手順終了前に、発生している状態で図示されている。

図４のコンパクト型バッチ表示４０４には、処理手順、単位手順、単位操作、フェーズ、そしてアラーム及びその他のイベントが示されているが、もちろん、テストサンプルがバッチから採取された時間、バッチ内で重要なイベントが発生した時間など、その他のタイプの情報及びイベント等もコンパクト型バッチ表示に図示しうる。また、その他のタイプの情報及びイベント等は、これらのイベントが発生した時に、バッチのコンパクト型表示に図示しうる。

前記その他のイベントには、例えば、臨界温度又は圧力に到達した時点や、設備利用状態の指標などが含まれうる。設備の利用状態の指標として、例えば、反応器Ｒ１の１つ等の特定の設備又は資源が、どれくらいの時間そのバッチにより使用されているかを監視することが重要となりうる。即ち、特定の資源が生産のボトルネック（隘路）になっているかどうかを判断するために、その資源がバッチにより「取り入れられた（acquired）」時点と「放出された（released）」時点など、を監視することが重要となりうる。

また、コンパクト型バッチ表示を分り易くするために、異なるタイプのデータを、コンパクト型バッチ表示の異なる層に配置してもよい。よって、例えば、バッチ処理手順要素データなどのバッチデータを１つの層に配置するとともに、アラームやイベントなどプロセスデータを別の層に配置することができる。上記の実施例において、資源の利用は、コンパクト型バッチ表示中の層として実施しうる。

また、所望の数の層を、コンパクト型バッチ表示に使用又は表示しうる。よって、例えば、外部イベント（例えば、プロセス変数が何らかの限度を超えた場合のアラーム）は、ベース層の表示に追加可能な層を構成でき、天候関連データなどの環境条件を１つの層に表示してもよく又は別の層にも表示してもよい。また、設備の利用状態を、別の層として実施しうる。

望ましくは、コンパクト型バッチ表示４０４に図示されるデータ又は凡例の表示を、色、点滅などの視覚効果、映像表示、図形などを使って、より良いものへと向上しうる。例えば、フェーズ及び単位操作のような異なるタイプのバッチ処理手順要素に関連する凡例や、同一のバッチ処理手順要素の開始及び停止に関連するアイコンを、異なる色及び／又は視覚効果を使って示しうる。

同様に、アラーム又はイベントの重大性又は重要度を、異なる色を使って示しうる。また、生産された製品の品質又はテストの結果を、数種の色と図形の組合せを使って示しうる。また、ユーザは、コンパクト型バッチ表示４０４に表示される凡例の意味又は凡例を裏付けるデータに関する更なる情報を、関連する凡例の上にマウス又はカーソルを置くことにより得ることが可能でありうる。

望ましくは、凡例をクリック又は選択することによりさらなる情報を取得しうる。凡例は、通常、コンパクト型バッチ表示に凡例を作成するために収集され、使用される生データ又はより完全なデータである情報を伴う。同様に、望ましくは、特定の層のいずれかに示すべき様々な情報や、特定のコンパクト型バッチ表示のいずれかに示すべき層の数やタイプを、ユーザが選択又は変更できるようし、これによりユーザが、特別なユーザニーズに応じた方法で、コンパクト型バッチ表示を構成できるようにしてもよい。

また、望ましくは、いくつかのコンパクト型表示を互いに平行した状態で、表示画面上に表示することも可能である。コンパクト型表示には、図３に示されるような水平方向ではなく、縦方向に時間スケールを設けることも可能である。このような表示画面は、例えば、複数のコンパクト型表示を同時に且つ簡単に表示するには、コンパクト型表示の層の情報が多すぎる場合に、役に立ちうる。

当然のことながら、また図４に示されるように、ＢＤＡ３２は、コンパクト型バッチ表示内の情報又はイベントを図示する際に、プロセスイベント及びバッチ処理手順要素の異なる部分（バッチ処理手順要素の開始又は停止、又はバッチ処理手順要素内の他の何らかのイベント等）に関連した異なるアイコンを含む、ディスクリートな（個々特有の）アイコン（即ち、ある時点のみに関連したアイコン）を使うことが望ましい。これは、ディスクリートなアイコンを使用することにより、より多くの情報をコンパクト型バッチ表示の単一層に配置することが可能になり、よって、コンパクト型バッチ表示をさらに簡易化（more compact）でき且つさらに分り易くすることができるからである。

特に、コンパクト型バッチ表示内の異なるイベントに対して異なるタイプのディスクリートなアイコンを使用することにより、例えば複数の異なるバッチ処理手順要素に関連するバッチデータ又はイベントを、コンパクト型バッチ表示内の同一のデータ層に表示することが可能となる。また、このように同一のデータ層に表示してもなお、これらのデータ又はイベントを表わすのに使用されているアイコンのタイプの違い（サイズ、形状、色などの違いに）に基づいて、お互いを識別し続けることができる。

もちろん、コンパクト型バッチ表示の作成に使用される情報は、直接様々なバッチ従属手順の各々の実際の開始・終了時間、及びアラームやその他の情報が実際に生成された時間に基づいて、図１及び図２のデータ・ヒストリアンから、コントローラ又はバッチ・エクゼクティブ・ルーチンから、又はキャンペーン管理ルーチンから取得しうる。及び／又は、この情報は図３のシステムを使用しても取得しうる。また、特定のコンパクト型バッチ表示を作成又は表示するＢＤＡ３２は、適切なデータ・ヒストリアンに格納されたデータにアクセスしうる。また、このＢＤＡ３２は、適切なバッチデータを収集するため及びコンパクト型バッチを作成するために、バッチ・エグゼクティブ又は該バッチ・エグゼクティブにより制御されるコントローラからデータを収集しうる。

一実施形態において、ＢＤＡ３２は、実行時、ユーザ定義のコンパクト型表示を作成するのに必要な情報を得るために、データ・ヒストリアン又はその他のデータベースの様々な部分に格納されたバッチデータを取得及び処理しうる。その後、これらのコンパクト型バッチ表示を、別々の表示として又は別のバッチ運転に関するデータとして格納し、後で同じ又は異なるＢＤＡ３２により、再度呼び出して表示できるようにしてもよい。よって、ＢＤＡ３２は、要求に応じて（on demandで）コンパクト型バッチ表示を作成するように作動してもよいし、及び／又はバッチ運転の現行の動作中にこれらのバッチ表示を自動的に作成してもよい。さらにこれらの表示を、所望の目的のために後で再度呼び出せるように、別のデータベースに格納してもよい。

コンパクト型バッチ表示４０４又はその他のコンパクト型バッチ表示は、バッチに関連した重要なイベントを、迅速に識別又は視覚化するために使用しうる。また、コンパクト型バッチ表示４０４又はその他のコンパクト型バッチ表示は、バッチの動作を理解する目的でバッチの現在進行中の動作を見るために、及び／又は簡単で役に立つ方式において異なるバッチ運転をお互いに比較するために、オペレータ又はその他のユーザにより表示されうる。

図５はバッチプロセスの異なるバッチ運転に関連した複数のコンパクト型バッチ表示の比較を可能にする画面を示す。例えば、図５の表示画面４４０には、さらに追加された別のコンパクト型バッチ表示４５０及び４６０に加えて、図４のコンパクト型バッチ表示４０４を含む３つのコンパクト型バッチ表示の一式が表示される。コンパクト型バッチ表示４５０及び４６０は、例えば、バッチ一覧部分４０８に図示されるバッチＩＤの内、さらに追加された別のバッチＩＤに関連したバッチ用に作成及び表示されうる。

一般的に言って、この場合、コンパクト型バッチ表示４０４、４５０及び４６０には、同一の処方を使用して、同時に又は異なる時点において、同一の又は異なる設備にて作動するバッチのバッチ運転が表示される。図５のコンパクト型バッチ表示４０４、４５０及び４６０から明らかなように、これらのコンパクト型バッチ表示のベース層４２０、４５２及び４６２には、バッチ運転がそれぞれ同じ時間を費やして実行又は完了されたことが示される。

さらにまた、関連するバッチの各々には、同じバッチ処理手順要素（例えば、１つのフェーズを有する、１つの単位操作を有する、１つの単位手順を有する、１つの処理手順など）が含まれている。一方、ベース層４２０、４５２、及び４６２の下側データ層４２３、４５３、及び４６３によって示されるように、これらのバッチ処理手順要素の相対的な開始・終了時間は、バッチ運転間で異なっていた。上側データ層４３１、４５４及び４６４により示されるように、これらのバッチ運転の各々において、異なるアラーム及びイベントが、異なる時間に発生した。また、バッチ一覧部分（バッチ識別部分）４０８に図示されるバッチ運転が、異なる実時間に開始且つ終了し、これらのバッチ運転は、バッチ運転の各々の開始時間から測定された相対時間に応じて、コンパクト型バッチ表示部分４０２に整列（aligned）される。

一般的に言って、複数のコンパクト型バッチ表示を、同じ表示画面上に同時に表示することによって、図５において図示されるように、同じ又は異なるバッチプロセス（例えば、バッチ処方）を、同じ又は異なる設備で実行した時に、実施される異なるバッチ運転を、オペレータやエンジニア又は保全要員などの諸ユーザが簡単に比較出来るようになる。従って、このようにバッチを同時表示することにより、ユーザは、傾向（トレンド）を表示及び決定したり、バッチ運転の現在の動作を表示したり、特定のバッチ運転により生産される品質又は数量の相違などにつながりえる又はその原因となりえるバッチ運転における相違を表示したり、できるようになる。

さらにまた、バッチ処方又はバッチプロセスのバッチ運転が幾つか開発されているので、ユーザが、特定のバッチ運転とそれと同じ処方や設備などを使用するその他のバッチ運転とを、より効果的に比較できるようにするために、ＢＤＡ３２は特定のバッチ処方又はバッチプロセスのバッチ署名を作成して図示しうる。一般的に、同じ又は類似したバッチ処方、原材料、設備、処理技術などを用いて実施された幾つかの以前のバッチ運転に基づいて、予定（期待）されるバッチ運転の統計的標準（norm）又は統計的尺度（measure）としてバッチ署名を作成しうる。

バッチ署名は、特定の一式の設備や処方などを使用するバッチ運転に対して、統計的に決定された標準（norm）でありうる。それ以降のバッチ運転がいずれも、該バッチ運転の完了後又はバッチ運転中のいずれにおいても、この標準（norm）と比較して、それによって該バッチ運転がバッチ署名により定義される標準（norm）の範囲内であるか否かを表示又は指摘しうる。或いは、比較によって、バッチプロセスの正常稼動に関連した特定の基準を満たすかどうかを表示又は指摘しうる。例えば、バッチプロセスの正常動作に基づいて特定のバッチ運転の変形を数量化するために、ユーザは、適切なバッチプロセスのバッチ署名に関連してのコンパクト型バッチ表示を比較しうる。

図６はバッチプロセスの複数のバッチ運転から収集されたバッチデータから生成される統計的バッチ署名を示す画面表示である。一実施例として、図６は統計的署名（バッチ署名）５００の下側に、図５のコンパクト型バッチ表示４５０を図示する。統計的署名５００は、コンパクト型バッチ表示４５０、コンパクト型バッチ表示４６０及びコンパクト型バッチ表示４０４を部材として含むバッチプロセス用に作成されたものである。特に、バッチ署名５００には、バッチ運転の処理手順、単位手順、単位操作、及びフェーズの各々の予測される開始及び停止時間に関連した統計的時間を図示するグラフを含みうる。

これらの予測時間の各々は統計的署名５００を表すグラフ中のパルスとして図示され、該パルスの中央（或いは、パルス中の線又は点など、その他の何らかの印）が、特定のバッチイベントに関連した開始時間（特定の処理手順の開始など）の平均値又は中央値を表わす。パルスの両端（エッジ）が、開始時間の平均値、中央値、又は予測値からの、通常の又は予測される偏差の何らかの統計的尺度を表わす。

このような統計的偏差は、例えば、開始時間の平均値又は中央値からの第１、第２又は第３の標準偏差でありうる。或いは、予測される偏差を、統計的署名を作成するのに使用された何れかのバッチ運転に含まれている開始時間の平均値又は中央値から、最大偏差として決定することもできる。もちろん、その他所望のいかなる方法においても、このような予測偏差を決定することが可能である。

例えば、単純な数値演算を行って、バッチのサンプル一式（例えば、バッチ署名を作成するのに使用された一式のバッチ運転）でのバッチ開始に対する、最初に発生したフェーズの開始点として、バッチプロセスのフェーズに関連したパルスの開始を決定することが可能である。或いは、バッチのサンプル一式でのバッチ開始に対する、最後に発生したフェーズの終了点として、当該フェーズに関連したパルスの終了を決定することが可能である。

もちろん、バッチ処理手順イベント、プロセスイベント又はその他いかなるバッチイベントに関連した各々の開始・終了時間の「平均値」、「中央値」、及び／又は「偏差」を、プロセスのいくつか又は複数のバッチ運転に基づいて統計的に決定しうる。よって、統計的署名５００は、コンパクト型バッチ表示４５０における処理手順５７４の開始に関連しているパルス５７２を含み、単位手順５８０の開始に関連した別のパルス５７６を含んでいる。

同様に、パルス５８２、５８４、５８６、５８８、５９０及び５９２は、コンパクト型バッチ表示４５０により識別された又はコンパクト型バッチ表示４５０内に表示されたバッチ運転のその他の処理手順、単位手順、単位操作及びフェーズの指標の開始又は終了に関連している。もちろん、アラーム、サンプル時間、テスト時間、利用状態などのようなプロセスイベントに対するなど、その他のイベントに対する、予測される又は統計に基づく時間を示すパルス又はその他の印（しるし）を、統計的署名５００に含むこともできる。

例えば、図６においては、パルス５９４が、コンパクト型バッチ表示４５０の上側データ層におけるアラームのうちの１つの署名として表示されている。さらにまた、図６のバッチ署名５００は、パルスを用いて図示されているが、バッチ運転用の統計データを表示するために、その他の印（しるし）又は指標を使用しうる。

もちろん、ユーザが特定のコンパクト型バッチ表示において定義又は図示される特定のバッチ運転と、その他複数のバッチ運転（統計的バッチ署名により表わされる）と、を比較することを可能にするために、そうすることが望ましいと判断される場合には、バッチ署名５００に提供される統計的尺度又はデータの全てを、バッチの開始時間に相対して表示しうるし、バッチに含まれる何らかの従属手順の開始時間に相対して表示しうる。このように、このバッチ署名によって、ユーザは、特定のバッチ運転の適合性を、統計的技法によりその他のバッチ運転と比較したり、表示したりできるようになる。

望ましくは、コンパクト型バッチ表示の各層に対して、異なるバッチ署名層を作成することが可能である。また、バッチ署名の様々な層を、これらの層がコンパクト型バッチ表示に表示される際に、同じ方法又は異なる方法で、お互いの上側・下側などに配置するなどして、相対して組み合わせたり、表示したりすることも可能である。このように、コンパクト型バッチ表示の種々の異なる層又は要素を、バッチ署名の同じ要素と比較しうる。

もちろん、バッチプロセスの署名パターンは、本来グラフィック（図形式）であるので、この署名は、ユーザが何らかの偏差を決定できるようにするために、バッチ表示中の層としての機能を果たすようになる、又は所定のバッチ表示上に重畳される。望ましくは、ＢＤＡ３２は、ルーチン実行時にアルゴリズムを使用して、署名標準（signature norm）から自動的にバッチ偏差を決定しうる。また、例えば、いかなる著しい偏差が発生した場合にも、警報又は警告を設定しうる。ここで、ユーザ又はオペレータは、特定の偏差に対して設定された警報又は警告が発生する「偏差量」を定義することができるようにしうる。

もちろん、ＢＤＡ３２は、また（或いは、その代わりに）、例えば、特定のコンパクト型バッチ表示に図示されるバッチが、それに関連するバッチ署名により定義される標準（norm）からどの時点で逸脱するかを示すために、画面をハイライト表示することにより、自動的に偏差をグラフィック（図形）で示しうる。また、バッチが現時点においてグラフィック（図形式）な性質を有している場合には、ＢＤＡ３２はまた、特定のバッチ運転の適切なバッチ署名からの偏差だけを表示する表示画面を作成しうる。

各バッチ署名は、一式の格納されたバッチから生成された状態で図示されているが、該バッチ署名は、ライブで又はバッチが作動している間に、現在作動しているその他のバッチ含む「その他のバッチ」の予め定められた数に基づいて生成してもよい。その他のバッチには、署名が表示されているバッチからのバッチデータを含むことが望ましい。よって、格納されたバッチ（バッチ署名が計算されうるところの）は、現在実行中のバッチからのバッチデータを含み得る。また、バッチ署名は、バッチが作動している時に、停止することなく（on the fly）又はオンライン状態（on line）で生成される。

また、異なるバッチ表示のより効果的な比較を可能にするために、ＢＤＡ３２は、ユーザが、１つ以上のコンパクト型バッチ表示及び／又はバッチ署名上で、本稿にて「時間褶曲（time folding）」として引用される概念を実施することを可能にする。これにより、ユーザが、特定の、隣接していない、コンパクト型バッチ表示又はバッチ署名の諸部分を、表示できるようにしてもよい。一般的に言って、時間褶曲は、バッチ運転の１以上の特定の期間を除外することとして説明できる。紙の上にコンパクト型バッチ表示を描いた後に、コンパクト型バッチ表示内の異なる隣接していない部分が繋がって見えるように、その紙を折り畳むといった概念である。

この時間褶曲機能は、バッチ運転の最も重要又は最も関心をそそる部分を表示する際に役立つものとなる。コンパクト型バッチ表示の多くは、非常に長くなり得るからである。特に、関連するバッチ運転が、それに関連する複数の処理手順、単位手順、単位操作及び／又はフェーズを有する場合に、非常に長くなる。また、コンパクト型バッチ表示に表示されるバッチ運転の一部分又は従属手順の中には、例えば、バッチ運転が適切に実行されているかどうかを判断する際に非常に重要となるものがある一方、ユーザにとってあまり重要でない又は妥当ではないものもある。このような状況においては、ユーザは、コンパクト型バッチ表示のそれほど重要ではない部分（及び／又は、それに関連するバッチ署名）を削除又は除去して、それによってコンパクト型バッチ表示のより重要な部分（及び／又は、それに関連するバッチ署名）をハイライト表示することを希望するかもしれない。

この時間褶曲機能を実行するために、ＢＤＡ３２は、コンパクト型表示の折り畳む又は除去する部分を指定する能力を、ユーザに提供しうる。図７はコンパクト型バッチ表示に時間褶曲を適用した状態を示す図である。図７は、コンパクト型バッチ表示４６０の諸部分をすべて表示する図５のコンパクト型バッチ表示４６０を最上部に示すと共に、折り畳まれた状態のコンパクト型バッチ表示４６０Ａを示す。

コンパクト型バッチ表示４６０Ａは、フェーズの開始（点線４７２Ａにより示される）から、単位手順の終了（点線４７２Ｂにより示される）までのコンパクト型バッチ表示４６０の全部分が、折り畳まれ又は取り除かれた状態になっていることを除いては、コンパクト型バッチ表示４６０と同じものである。このように、コンパクト型バッチ表示の様々な隣接していない部分が共に連結（連続）されうる。

より具体的には、本実施例においては、ＢＤＡ３２により時間褶曲が実行されて、点線４７２Ａ及び点線４７２Ｂをオーバーレイする（重ねて表示させる）ことにより、点線４７２Ａと４７２Ｂの間の部分４７２が取り除かれたコンパクト型バッチ表示が作成される。こうして、折り畳まれた状態のコンパクト型バッチ表示４６０Ａが作成される。

もちろん、コンパクト型バッチ表示は、複数の時間褶曲された部分（セグメント）を備えていてもよい。また、時間褶曲された部分（セグメント）は、ユーザがバッチ運転の該当する又は関心の対象となっている部分を連続した状態で見ることができるように、また、ユーザが単一の表示画面上に異なるバッチ運転の同一部分を表示できるように、所望のあらゆる位置にて、特定のコンパクト型バッチ表示から展開できるようにしてもよい。

よって、一実施例において、ユーザがバッチプロセスなどの異なるバッチ運転内の同じ時間を表示又は比較できるようにするために、図５のコンパクト型バッチ表示のように、様々な異なるコンパクト型バッチ表示の同一部分を時間褶曲して、同一のバッチプロセスに関連した様々なバッチ運転の様々な異なる部分からのデータを削除することができる。

もちろん、ユーザは、関心の対象にならないイベントに起因する種々のコンパクト型バッチ表示における相違を取り除くことを希望するかもしれない。関心の対象にならないイベントとは、バッチを実行するプロセス用設備を得るための待ち時間、設備の清掃に携わるその他の待ち時間、バッチの工程内における「保留」時間（例えば、オペレータが指示メッセージに応答するのをバッチが待っている間）などである。また、ユーザは、実行中のバッチがバッチ署名パターンと同期したり、又はその他のコンパクト型バッチ表示用にその他のバッチ運転と同期したり、できるようにすることを希望するかもしれない。

時間褶曲の別の利用方法として、例えば、バッチ運転の特定の単位操作、フェーズ、処理手順、単位手順、アラームなどの開始点が一列に並ぶように、例えば、ユーザが２つ以上のコンパクト型バッチ表示を「整列（align）」させることが挙げられる。この場合、何らかのつまらない理由で、バッチ運転の開始前の部分に異なる遅延が発生することなどを懸念することなく、単位操作やフェーズ等と後続の諸動作とを、隣り合った状態又はお互いに重なり合った状態で比較することができる。

当然のことながら、ここに記載されるバッチ・ディスプレイ・アプリケーション及びバッチ実行エンジン、ＢＯＩ、ＣＭＯＩ及びキャンペーン・マネージャー・サーバ・アプリケーションは、所望のあらゆるプロセスプラント制御プログラミング環境内にて使用及び実施でき、所望のあらゆるタイプのプロセスプラント制御通信プロトコルを用いてプロセスプラント制御システムのいかなるものにおいても使用することができ、さらにまた、いかなるタイプの装置又は装置の従属ユニットに関連するいかなるタイプの機能を実行するのにも使用しうる。

ここに記載されるバッチ・ルーチンは、例えばサーバ、ワークステーション又はその他のコンピュータに格納されたソフトウェアにおいて実施されることが好ましいが、その代わりに、又はそれに加えて、これらのルーチンを希望に応じてハードウェア、ファームウェア、特定用途向け集積回路、プログラム可能論理回路において実施してもよい。

ソフトウェアで実施する場合は、コンピュータ、コントローラ、フィールド装置などのＲＡＭ又はＲＯＭ、もしくは磁気ディスク、レーザーディスク又はその他の記憶媒体などを含むいかなるコンピュータ読取り可能なメモリにバッチ・ルーチンを格納しうる。同様に、このソフトウェアは、例えば、コンピュータ読取り可能なディスクなどの可搬型媒体で電話線やインターネットなどのような通信経路を通してなど、いかなる周知又は所望の配送方法によってユーザ又は装置に提供されうる。

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

部分的なブロック図である。特にコンパクト型バッチ表示を作成し表示するのに使用されうるバッチデータ収集及び表示用アプリケーションを含むプロセス制御ネットワークの一部分の部分的な概略図である。 プロセスプラント内に複数のバッチを実施するのに使用されるバッチ・エグゼクティブ・アプリケーションを含むコンピュータのネットワークのブロック図である。 コンパクト型バッチ表示の作成及び表示に使用されるバッチイベント・ヒストリアンを含むバッチ履歴のロギング（ログ記録）及びレポーティング（報告）システムを表すブロック図である。 特定のバッチプロセス用のコンパクト型バッチ表示の実施例を示す、図１のバッチデータ収集及び表示用アプリケーションにより生成される第１の代表的な画面表示である。 バッチプロセスの異なるバッチ運転に関連した複数のコンパクト型バッチ表示の比較を可能にする画面を示す、図１のバッチデータ収集及び表示用アプリケーションにより生成される第２の代表的な画面表示である。 バッチプロセスの複数のバッチ運転から収集されたバッチデータから生成される統計的バッチ署名を示した、図１のバッチデータ収集及び表示用アプリケーションにより生成される代表的な画面表示である。 コンパクト型バッチ表示に時間褶曲（time folding）を適用した状態を示した、図１のバッチデータ収集及び表示用アプリケーションにより生成される代表的な画面表示である。

符号の説明

１０ プロセスプラント制御ネットワーク
１２ プロセス制御装置（コントローラ）
１４ ワークステーション
１４ａ ワークステーション
１５ ＬＡＮ（イーサネット（登録商標）通信線路）
１６ プロセスプラント
１８ バス
１９ データ・ヒストリアン
２０ メモリ
２１ プロセッサ
２２ メモリ
２４ プロセッサ
３０ バッチ実行エンジン（バッチ・エグゼクティブ・エンジン）
３２ バッチ・ディスプレイ（表示）・アプリケーション（ＢＤＡ）
４０ クライント／サーバ・ネットワーク
４２ クライアントノード
４２ａ クライアントノード
４２ｂ クライアントノード
４２ｃ クライアントノード
４４ サーバーノード
４４ａ サーバーノード
４４ｂ サーバーノード
４６ バス
４８ ＢＯＩアプリケーション
５０ ＣＭＯＩアプリケーション
５２ バッチ・エグゼクティブ・アプリケーション（ルーチン）
５４ キャンペーン・マネージャー・サーバアプリケーション（ＣＭサーバ）
１００, ２００ 反応槽
１０１，１０２ 入力バルブ
２０１，２０２ 入力バルブ
１０３，２０３ 出力バルブ
１０５，２０５ 装置（液面計測器）
１１０，２１０ フィルタ設備
１２０，２２０ 乾燥器設備
３００ バッチイベント・ヒストリアン
３０２ バッチ・ヒストリアン・エグゼクティブ（エグゼクティブ）
３０３ プロセスイベント
３０４ プロセスイベント・ログ
３０５ プロセスイベント・サーバ
３１２ バッチサーバ・イベント
３１４ バッチイベント・ログ
３１６ バッチイベント・サーバ
３４０ データベース（ＯＯＤＢＭＳ）
３４１ その他のイベント
３４２ その他のイベントログ
３４４ その他のイベントサーバ
３５０ オブジェクトＡＰＩ
３５２ ＳＱＬインターフェース
３５４ ＯＤＢＣドライバー
３６４ 表示クライアント
３６６ レポート・クライアント
３６８ ＳＱＬブラウザークライアント
３７０ ユーザＳＱＬ・ＡＰＩ
３８０ 連続データ
３９０ 診断インターフェース
３９２ 管理インターフェース
４００ 表示画面
４０２ コンパクト型バッチ表示部分
４０４，４５０，４６０，４６０Ａ コンパクト型バッチ表示
４０８ バッチ一覧部分
４１０ 凡例部分
４１２ ユーザボタン
４２０，４５２，４６２ ベース層
４２２ 時間スケール
４２３，４５３，４６３ 下側データ層
４２４，４２６，４２８，４３０ 凡例
４３１，４５４，４６４ 上側データ層
４３２ 警報アラーム
４３４ 警報アラーム
４４０ 表示画面
４７２Ａ 点線
４７２Ｂ 点線
４７２ 部分
５００ 統計的署名（バッチ署名）
５７２，５７４，５８２，５８６，５８８，５９０，５９２，５９４ パルス
５７４ 処理手順
５８０ 単位手順

Claims (35)

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. 前記ディスクリートなアイコンの表示には、バッチ処理手順要素データを表すために第１のタイプのディスクリートなアイコンを表示し、プロセスイベント情報を表すために第２のタイプのディスクリートなアイコンを表示することが含まれることを特徴とする請求項２７に記載のバッチ表示方法。
33. 前記ディスクリートなアイコンの表示には、第１のタイプのバッチ処理手順要素データを表すために第１のタイプのディスクリートなアイコンを表示し、第２のタイプのバッチ処理手順要素データを表すために第２のタイプのディスクリートなアイコンを表示することが含まれることを特徴とする請求項２７に記載のバッチ表示方法。
34. 前記複数の異なる階層のバッチ処理手順要素が、バッチ処理手順、バッチ単位手順、バッチ単位操作及びバッチフェーズの少なくとも２つを含む、請求項１に記載のバッチ表示システム。
35. 前記複数の異なる階層のバッチ処理手順要素が、バッチ処理手順、バッチ単位手順、バッチ単位操作及びバッチフェーズの少なくとも２つを含む、請求項２７に記載のバッチ表示方法。

Images