JP5377585B2 - バッチ処理用事象ヒストリアン - Google Patents

Description

本発明は、プロセス制御システムおよびアプリケーションに関し、より特定的には、実時間のバッチ処理に関する履歴データを集めて提示するとともに、このようなデータをこのバッチ処理で用いられる手法、プロシージャ、および機器と関連付けるための方法および関連の構造に関する。

（バッチ処理）
多くの種類の産業プロセスがある。停止されるまでは連続的に実行されるものもあり、典型的には、開始と停止との間で多量の製品を製造する。部品のグループで動作する産業プロセスもあり、グループは、ワークステーション間でユニットとして動作するが、各部品はそれ自身の独自のアイデンティティを維持する。

産業プロセスの第３の種類はバッチ処理であり、これは、ひとつ以上の機器を用いて原料に処理ステップを施して、製品の「バッチ（batch）」を作る。料理は、家庭で行われるバッチ処理の一例である。原料となる食べ物が準備され、鍋にいれられて、レシピで指定される時間の間に料理され、食されるべく用意された料理即ち「バッチ」ができあがる。

ポリ塩化ビニールを準備することは、産業的な規模で実施される例である。ポリ塩化ビニールは、塩化ビニールよりもずっと小さい分子を重合させるかまたは「一緒に結合すること」により作られる。これは、適切なレベルまで、バッチ反応装置を、塩化ビニール、溶剤、および重合誘導物質の混合物で充填し、反応装置内で混合物を加熱し、結果として生じるバッチを冷却し、残りの物質を取除くことでバッチを浄化して完成する。

これらはバッチ処理のほんの数例に過ぎない。一般的に、多くの様々な種類のバッチ処理がある。それらには、例えば、製品製造、製品流通、および製品テストと複数の他の製品および非製品志向のプロセスとが含まれる。

（バッチ処理制御）
一般的に、バッチ処理を制御することは重要である。ある例として、もしある料理が調理中あまりにも長くストーブ上で放っておかれたならば、焼けてしまい、結果生じる食べ物のバッチはだめになるだろう。別の例として、塩化ビニールの反応混合物が十分に長く反応しなかったら、処理から得られるポリ塩化ビニールの量は不充分で金銭の無駄である。バッチ処理を制御することは、危険な化学物質またはそれに匹敵する物の生産が含まれる場合に決定的に重要になるだろう。

バッチ処理を制御するひとつの方法は手動制御である。つまり、ひとり以上の作業員は、全てが計画に従って進行しているのを確かめるためバッチ処理の全ての面を監視する仕事が割り当てられる。しかしながら、これは退屈な仕事であり、間違いが気づかないうちに生じるおそれがある。

これらのおよび他の理由で、現在、バッチ制御の分野の作業員は、電子装置を用いてバッチ処理の制御を自動化しようとしている。バッチ処理の制御を自動化するために、コンピュータ、プログラマブルコントローラ、およびそれに匹敵する電子装置が、多くのバッチ制御システム供給者により、インテリジェントフィールド装置（即ちインテリジェントセンサおよび制御可能な弁）と関連して用いられてきた。

インテリジェントセンサは典型的には機器上に配置され、プラント内の中央制御室に機器に関して報告する。制御可能な弁は典型的には、機器への入力およびそこからの出力を制御し、インテリジェントセンサから受け取った情報に基づいて、中央制御室から制御される。

バッチ処理を自動化しようとする努力は、とりわけ、バッチ処理に関わる産業の人々およびバッチ処理機器の供給者による規格委員会の形成につながった。これらの規格委員会の一般的な目的は、自動化バッチ処理のための不変の規格を規定することであった。

このようなある規格は、プロセス制御の問題と関連する国際的組織である、測定および制御のための国際社会（International Society for Measurement and Control）により普及させられてきた。この規格は、バッチ制御パート１：モデルおよび専門用語と題され、しばしばＩＳＡ Ｓ８８．０１−１９９５規格（またはこのアプリケーションのために「Ｓ８８」と称される。

Ｓ８８．０１規格は、機器のモデルおよび自動化バッチ処理で用いられるプロシージャのモデルと、それらのモデルを参照する際に用いられる専門用語およびそれらの要素とを定義する。Ｓ８８．０１規格は、ひとつ以上の機器を用いて時間の有限期間にわたって、入力された物質に順序付けられた組の処理活動を施すことにより有限量の物質の生産につながるプロセスとして、バッチ処理を定義する。「バッチ」は、生成されているかまたはバッチ処理の一回の実行で生産される物質として定義される。

（プロシージャモデル）
バッチ処理機器（即ち、弁、ヒータ、ミキサーなどのような制御可能な要素）は、バッチを作るためのプロシージャに従って動作する。このアプリケーションのために、このような機器全ては機器、機器モジュール、処理機器、または物理的要素と同義で称される。このような物理的要素を動作させるプロシージャは、しばしばＳ８８．０１規格においては「プロシージャモデル」と称される。Ｓ８８．０１規格によれば、プロシージャモデルはプロシージャの階層的順位として構成され、最高レベルは低レベルの各々を含み、最高レベルの次に高いレベルはそれより下のレベルの各々を含む、などである。このアプリケーションの目的のための特定の関心のＳ８８．０１プロシージャモデルのレベルは、「プロシージャ」、「ユニットプロシージャ」、「オペレーション」、「フェーズ」の順で下がっていく。

用語「プロシージャ要素」は、Ｓ８８．０１プロシージャモデルのこれらのレベルの具現化または実現化を指すためにこのアプリケーションで用いられるのであって、プロシージャモデルの「プロシージャ」レベルまたは他の単一のレベルの具現化または実現化を指すために使用されるのではない。

関心のある最高レベルのプロシージャ要素はプロシージャと称され、これはひとつ以上のユニットプロシージャで構成される。各ユニットプロシージャはひとつ以上のオペレーションで構成され、これらは、各々がひとつ以上のフェーズで構成される。Ｓ８８．０１プロシージャモデルは他の階層レベルの定義および使用を排除するものではないし、各レベルが特定のアプリケーションで存在することを要求するわけでもない。むしろ、この規格は、自動化されたバッチ処理制御において従われるプロシージャを記述する、広い、標準化されたモデルを与えるように意図されたものである。

（物理的要素およびプロシージャ要素の関連）
一般に、プロシージャ要素は、パソコン、ワークステーションおよびプログラマブルコントローラを含め、データ処理装置によりまたデータ処理装置内で実行されるコンピュータプログラムとして実行される。典型的なプロシージャ要素を実行すると、データ処理装置からの電気出力または光出力を生じさせ、これは、ローカルエリアネットワークまたはワイドエリアネットワークによって、典型的にはデータ処理装置の出力を物理的要素に直接的にまたは間接的に接続することにより、物理要素を制御するのに用いられる。

プロシージャ要素は、少なくともひとつの物理的要素に対して「基本制御」を呼び出すことでその割り当てられたタスクを行なう。この種類の制御は、物理的要素の具体的な所望の状態を確立して維持することに捧げられている。基本制御は、例えば、収納用の箱要素内の物質の流れを開始させるかもしくは維持し、または塩化ビニール反応装置要素内で物質の加熱を開始するか維持するだろう。

実務上、プロシージャモデル（即ちフェーズ）の低レベルは、実際の物理要素と実際の通信を行い、それにより基本制御を呼び出すかまたは行う。高レベルのプロシージャモデルは本質的には、プロシージャモデルの編成および構造、ならびに物理的モデルを向上させるための抽象作用である。

（プロシージャ要素および状態機械モデル）
状態機械（ステートマシーン）モデルは、プロセスまたは活動の状態を説明するのに通常は用いられる論理構成体である。このモデルは、多くのプロセス状態を、それらの状態間の遷移の原因となるオペレーションと一緒に記述するか定義する。プロセスの状態機械モデルは、初期の遷移によってある特定の状態になりその状態にあると言われる。特定の事象が生じるかまたは特定の状態が感知されると、状態機械モデルは、特定の事象または感知された状態に相当する別の状態に遷移する。

状態機械モデルは、バッチ処理のプロシージャ要素のオペレーションを定義して実行するのに有用な技術である。状態機械として定義され実行されるプロシージャ要素は、例えば、その関連の状態機械が古い状態から新しい状態に遷移するときにオペレーションを開始する。

Ｓ８８．０１規格は、標準的な状態機械モデルに従ってプロシージャ要素の定義および実行を許可する。Ｓ８８．０１規格はこのアプローチを命じたりしないが、様々な小売業者の製品の間の高度の相互運用（さらに以下に述べるように）を可能とすべくプロセス制御産業で広く採用されてきた。状態機械モデルに従ってプロシージャ要素が定義され実行されるＳ８８．０１規格のある商業的アプリケーションは、テキサス州、７８７５４、オースティン、キャメロンロード８３０１のフィッシャー・ローズマウント・システムズ（Fisher-Rosemount Systems）のDeltaV Batch製品である。

DeltaV Batchにおいては、サーバプログラムは、プロシージャ要素を実行するデータ処理装置上で実行される。サーバプログラムは、ひとつ以上の状態機械モデルに従ってプロシージャ要素の実行を調整する。プロシージャ、対応するユニットプロシージャ、対応するオペレーション、および対応するフェーズは、サーバプログラムによりそれぞれのステップを経て一定の順序に従って配列される。

例えば、あるフェーズがサーバプログラムにより開始されると、そのフェーズは、プログラマブルコントローラ内のフェーズ論理インターフェースに開始要求を伝える。プログラマブルコントローラは次いで、そのフェーズのための実際の状態論理を実行し、通信によってプロセス機器に必要なプロセス制御を与える。

（履歴データ）
このようなバッチ処理においては、バッチの処理を構成する履歴事象を表すデータを集めることが望ましい。このような履歴データは、例えば、品質制御の傾向（trend）を決定する際に、またはバッチ処理で用いられる機器がいつサービスを必要とするかを決定するのに有用であるのかもしれない。

多くの種類のデータは、バッチ処理の質または進行を見直す際に潜在的に有用である。データのあるこのようなソースは、バッチ処理の間のバッチ処理において様々なデータ点により生成された連続データである。あるデータポイントは、バッチ処理の何らかの制御値または他の状態値もしくは測定値を反映させるこのような連続的データのひとつのソースである。例えば、センサにより測定される物質の流量または温度の特定のレベルは、ひとつのこのようなデータポイントである。制御値の現在の設定は、べつのこのような例のデータポイントであるだろう。

このようなデータポイント各々は、バッチ処理アプリケーションにより時間をかけて感知されるかまたは制御されるデータの連続的なストリームを生成する。バッチの処理の間に生成されたこのような連続データの合算はしばしば、バッチ処理システムによりログされる。このようなデータポイントのログ記録は通常、タイムスタンプおよび現在値を、データのソースを識別するためのタグのようなデータポイントのための他の識別情報と一緒に含む。

バッチ処理の質または進行を再検討する際に有用な別の種類のデータは、事象情報である。ここで用いられる事象情報は、プロシージャモデル実行に関してバッチ処理を記述する情報を指す。例えば、ある特定のフェーズもしくは特定のオペレーション、プロシージャモデルのユニットプロシージャまたはプロシージャの開始時刻および終了時刻を記述するバッチ事象はこのような事象情報を構成する。事象情報はプロセス事象、即ちバッチ処理の物理的要素またはオペレータにより生成された情報を含む。各機器モジュール、セルなどは、特定のフェーズを開始し停止する（即ち具体的な基本制御オペレーションを行なう）際にその具体的活動を示すべくプロセス事象を生成してもよい。機器により認識された警報状況は、プロセス事象のさらなる例である。プロセス事象は、そのオペレーションの間にバッチ処理に対するオペレータの変更に関する情報も含む。

これらの様々な形の事象情報および連続データを統合して、バッチ処理のユーザに、このような情報の総合的、理解可能な提示を与えるのは非常に有用である。しかしながら、バッチ処理の質および進行に関する報告のために現在利用可能なツールは、このような統合にははるかに及ばない。ユーザは、様々な解体（disjoint）ツールを用いて手操作で「統合」を行うことが要求される。さらに、限られた範囲で本発明の解決策がこのような統合を与え、ユーザは、報告プログラムが様々な種類のおよびソースの事象情報と連続データとを相関させることができるように重要、詳細な構成情報を与えることが要求される。

バッチ処理で用いられる現在のツールは、バッチ処理からの連続データを集める。他のツールは次いで、興味有るデータの特定のセクションを位置付けるために、ユーザにやっかいなインターフェースを与える。例えば、ユーザは、指標付けツールを用いて、バッチ処理おいて特定の事象またはプロシージャに関するキャプチャされたデータを位置付けるフィルタまたはトリガを定義してもよい。フィルタまたはトリガは、例えば、特定のフェーズの実行に関するデータの開始時刻および終了時刻を規定するのと同じ位単純であってよい。または、その定義は、特定のプロシージャ要素に相当するデータを識別する他のパラメータを識別するようにユーザに要求するほど複雑であってもよい。

一般に、ユーザは、バッチ処理において関心のある事象を定義するように構成情報を手操作で与えなければならない。この情報の構成はしばしば、関心のある事象の重要なユーザの知識および関心のあるそれらの事象に関連するデータの可能性のある特性と必要とする複雑なタスクを提供する。さらに、データをプロシージャ事象と関連付けるためのフィルタを定義する複雑さにもかかわらず、データをバッチ事象と関連付けるためにこのようなフィルタを定義するプロセスは、当該技術で現在実践されているようにほとんど手操作のプロセスである。本質的には、ユーザは、特定の事象とその事象と関連する連続データの特定の部分とを識別する構成データを入力しなければならない。このような手操作プロセスは、事象情報と関連の連続データとの間の関係が間違って確立されるように間違いが生じ易い。

データのユーザは記憶されたデータの構造の知識を必要とし、データの間の意味のある関係を生成して提示することに責任がある。既存の技術の問合せ能力（ケイパビリティ）は重要であるが、それらは、データをアクセスするためのリレーショナルデータベース「前置（フロントエンド）」を与えるだけである。このようなリレーショナルデータベース管理システム問合せオペレーションは、記憶されたデータの様々な要素の間の関係を理解し、所望のデータを提示するために、そこから意味のある問合せを作成することをユーザに要求する。

現在のバッチ処理に付随する別の問題は、ユーザにこのような事象情報の提示する際に生じる。バッチヒストリアンプログラムは、このような事象情報を集め、バッチ処理システムのユーザにこの情報を提示する。現在のバッチヒストリアンプログラムは、連続データから表文字の報告を作成するか、せいぜい、連続データの要素における傾向の単純な線形グラフを作成するだけである。バッチ処理システムの現在のバッチヒストリアン特徴はしたがって、ユーザにデータを提示するには柔軟性が限られている。例えば、バッチ事象またはプロセス事象および連続データの間の関係は、現在のヒストリアンプログラムの表を用いた文字の提示からは識別しにくい。

したがって、事象情報の様々なソースとバッチ処理から集められた連続データとの間の関係を成立させるプロセスを自動化する方法および構造を提供することが問題となる。改善された構造として必要とされるのは、様々な集められた事象およびデータの間で関係を成立させることを自動化および単純化するものである。バッチ処理システムのユーザがデータを良く解析することができるように、改善された方法および構造が集められたデータを提示する際に柔軟性を向上させることがさらに望ましい。

本発明は上記の問題およびその他の問題を解決し、バッチ処理に関する履歴データをより効果的にキャプチャし、記憶し、提示するための方法および関連の構造を与えることにより、有用な従来技術の状態を進歩させる。特に、本発明のバッチヒストリアンは、バッチプロセスにより生成された事象情報全てを受け取る実行プログラムを含む。実行プログラムは、データを解析して、いつ受け取られた事象が新たなバッチまたはバッチの処理内の新たなプロシージャ要素の例示（instantiation）を反映するか決定する。このような解析はしたがって、バッチとそのバッチと関連するバッチ処理との間の関係を再構成するように受け取られた様々な事象の間の関係を決定する。事象および事象間の関係はしたがって、集められたバッチ事象およびプロセス事象から自動的に得られる。

実行プログラムの解析によりこのように識別される事象は、ログされた連続データを実行プログラムにより得られる事象情報と自動的に関連付けるために用いられる。連続データログは、履歴実行プログラムにより得られる事象情報を用いて構文解析され、それを事象情報と関連させる形で表示される。

本発明はしたがって、プロシージャモデルサーバ処理から生成された様々なバッチ処理間の関係と所望の制御を実際に行う物理的要素により生成されたプロセス事象とを自動的に決定する。本発明はまた、この得られた事象情報を、バッチ処理システムの他のコンポーネントによりログされた連続データと自動的に関連付ける。したがって、本発明により、ユーザは、バッチ事象を識別し、このような事象を他のプロセス事象または連続データと関連付けるためにシステムを手操作で構成する必要はない。

好ましい実施の形態において、所望の事象情報は、得られた事象情報はオブジェクト志向の持続性記憶装置（object oriented persistent storage）（即ちオブジェクト志向のデータベース管理システム（Object Oriented Database Management SystemまたはＯＯＤＢＭＳ）内に記憶される。この記憶アプローチは、事象の履歴シーケンスおよび様々な事象の間の関係をよく理解するために、集められ得られたデータの特別の問合せをユーザが生成する柔軟性を向上させる。下で述べるように、当業者は、データを持続的に記憶するために複数のファイルまたはデータベース構造のいずれかが本発明と関連して用いられることを認めるだろう。ＯＯＤＢＭＳは、本発明のバッチ履歴特徴に重要な柔軟性を与えるひとつのこのような構造にすぎない。

本発明はさらに、図形のユーザインターフェースビュークライアントプログラムを与え、これにより、ユーザは、集められたデータの階層的関係を反映するように、構造化された履歴データを見ることが出来る。様々な集められたデータおよびそれらが表す事象は、データの様々な関係の間でナビゲーションを可能とするようにユーザに提示される。例えば、バッチの処理の特定のプロシージャ要素に関する情報がユーザに提示されて良く、ユーザは、図形的表示要素上をクリックして、具体的フェーズのような関連する低レベルのプロシージャアスペクト（aspect）を見てもよい。ユーザは、バッチ処理と特定の製造されたバッチとを含むオブジェクトの間の様々な関係を容易に見れる。

好ましい実施の形態において、ビュークライアントは、バッチおよび時間を各プロシージャ要素と関連させるために行われる様々なプロシージャを図形で示すガント（Ｇａｎｔｔ）チャート時間線として表示画面上にバッチ処理を提示する。プロシージャの低レベルの（階層的）詳細を見るために、ユーザは、あるプロシージャを「クリックオン」（選択）してそのなかのユニットプロシージャを見る。同様にして、ユニットプロシージャがクリックされ、オペレーションを見て、あるオペレーションが選択されてフェーズを見る。ガントチャート下の画面の表の文字部分は、選択されたプロシージャ要素を含む事象の詳細を明示する。プロシージャモデル階層の多レベルは、ディスプレイのガントチャート部分上で同時に表示される。ユーザは、このように表示されるべき詳細のレベルを構成してよい。

第１および第２のバッチは、ビュークライアントにより同時に表示されて２つのバッチを視覚的に比較することもできる。例えば、所望の製品を生成する「素晴らしい（golden）」バッチは、失敗したバッチと比較されてよい。バッチの失敗の理由は、バッチガントチャートを図形で比較することで視覚的には明らかである。ビュークライアントの特徴により、チャートを視覚的によりよく整列させることが出来るように、各ガントチャートの時間線が絶対時間においてまたはバッチ相対的時間において提示可能となる。時間線は、バッチのスタートで整列されても、両方の時間線において他の規定されたプロシージャ事象（即ち開始もしくは終了または両方の時間線に共通なある特定のプロシージャ要素）で整列されてもよい。

ビュークライアントの図形ユーザインターフェース特徴により、ユーザは、選択されたプロシージャ要素と関連する連続データを簡単に見直すことが出来る。本発明により自動的に決定される関係は、ログされた連続データを特定のプロシージャ要素と相関させる。ビュークライアントによって、連続的なログされたデータ内のひとつ以上のタグ付きデータポイントが特定のプロシージャ要素のために提示されるようになる。例えば、ひとつ以上のタグ付きデータポイント値は、表示され、および／またはバッチの特定の選択されたフェーズのためにプロットされる。所望のフェーズが選択され、ユーザがそのフェーズのためのタグ付きデータポイントを選択できるようなダイアログボックスが提示される。そのフェーズのための選択されたタグ付きデータポイントは連続データのログから検索されてユーザのディスプレイ上に提示される。本発明の重要な点は、当該技術で現在実践されているのとは違って、ユーザは手動で入力された構成情報において各プロシージャ要素の開始および終了を指定する必要はないということである。そうではなく、ユーザは単に図形表示からプロシージャ要素を選択するだけであり、本発明の方法および構造は、選択されたプロシージャ要素を、そのプロシージャ要素ならびに他の関連の事象のための事象情報、プロシージャ要素および機器と関連付ける。

ビュークライアントのさらなる特徴により、事象データ（即ちガントチャート）またはプロットされた連続データは実時間でモニタ可能となる。バッチ処理が実行されているときは、データの実時間表示はチャートをスクロールしたり画面にわたってプロットして、新しいデータをチャートまたはグラフの終わりに付け加える。

本発明の上記の目的および他の目的、局面、特徴、および利点は、以下の説明および添付図面から明らかになるだろう。

バッチ履歴ロギングおよび報告システムの技術の現在の状態を示すブロック図である。 本発明にしたがったバッチ事象ヒストリアンを含むアーキテクチュアを示すブロック図である。 本発明のバッチ事象ヒストリアンの動作を説明するフローチャートである。 図３のバッチ事象ヒストリアンのさらなる詳細を説明するフローチャートである。 図３のバッチ事象ヒストリアンのさらなる詳細を説明するフローチャートである。 図３のバッチ事象ヒストリアンのさらなる詳細を説明するフローチャートである。 図３のバッチ事象ヒストリアンのさらなる詳細を説明するフローチャートである。 図３のバッチ事象ヒストリアンのさらなる詳細を説明するフローチャートである。 図２のバッチ事象履歴ビュークライアントの動作を説明するフローチャートである。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。 図９のバッチ事象履歴ビュークライアントにより生成される表示画面の例である。

本発明は様々な修正例および代替例の形を可能とするが、その具体例は図面で例示として示され、ここで詳細に説明される。しかしながら、本発明を開示される特定の形に限定することを意図するものではなく、反対に、本発明は、前掲の特許請求の範囲により規定される本発明の精神および範囲内に入る全ての修正，均等物、および代替例をカバーする。

（バッチ事象ヒストリアンシステム）
図１は、バッチ処理環境に関する履歴データの記録および提示の現在知られている技術の状態を示すブロック図である。連続データログ１００は、バッチ処理環境において多数の連続データソースに相当するタグ付き情報を記録する。特に、連続データ収集要素１０６は、複数のデータポイント１０４の各々から連続値の現在のストリーム受け取る。このようなデータポイントは、例えば、バッチ処理に関わるセンサおよびアクチュエータからの現在のアナログ値およびディジタル値を含む。このように受け取られた各データ値は、識別および他の情報（即ちタイムスタンプ値）でタグをつけられ、データポイント値は分類されるか、同じソースからの類似のデータポイントと関連付けられるようになる。タグ付きデータポイント値は、次いで圧縮されて後の処理のために圧縮されたタグ付きログ１１０内に記憶される。

この圧縮されたタグ付きデータは、クライアントアプリケーション１１４−１１８およびユーザアクセスエンジン１１２で用いられるようにアプリケーションプログラムインターフェース（ＡＰＩ）１０８により検索される。ＡＰＩ１０８により、圧縮されたタグ付きログ１１０から所望のデータポイント値を簡単にフィルタ処理して選択できる。同じソース識別でタグをつけられた値は伸張され、選択された範囲のタイムスタンプ値を求めてログから検索されてよい。

標準的データ整理（data reduction）および解析クライアントアプリケーション１１４−１１８は、圧縮されたタグ付きのデータポイント値の検索および解析により特定のデータポイントを静的に解析する。解析されるべき値の範囲は、データポイントのタグおよび関心のあるタイムスタンプの範囲を識別することによりユーザにより与えられる。

ユーザアクセスエンジン１１２は、ユーザに、圧縮されたタグ付きデータポイント値に対しより柔軟に特別な問合せを与える。ユーザはまず、様々なデータソースの間の関係と各バッチプロシージャステップの開始および停止と関連する時間とを記述するために構成データ１２２を与える。言いかえると、ユーザは、ユーザアクセスエンジン１１２が様々な圧縮タグ付きデータポイント値の間の関係と、関連するバッチを作るために動作したバッチプロシージャとを決定するために各プロシージャ事象（フェーズ、オペレーション、ユニットプロシージャおよびプロシージャ）の開始および停止を手動で規定しなければならない。

ユーザアクセスエンジン１１２はこのユーザ構成データ１２２を用いて、様々なユーザ定義のプロシージャ事象の間のこれらの関係を記憶するため従来のリレーショナルデータベース管理システム１２０を構造化する。

プロセス事象１０１は、バッチの処理の間にプロセス機器およびオペレータにより生成された実時間の事象を示す。これらの事象は、タイムスタンプ情報と、メッセージを生成した機器またはオペレータを示す識別情報とを含み、プロセス事象ログ１０２においてログされ、ユーザアクセスエンジン１１２に与えられてこれらの事象の間の他の関係を決定する。

従来技術で重要なのはユーザ構成情報１２２である。ユーザは、実時間プロセス事象および連続データをＳ８８プロシージャモデルに関係付けるプロシージャ事象を手動で識別する責任がある。言いかえると、ユーザにとってもっともなじみのあるバッチ処理プロシージャモデルに関連付けられる方法でプロセス事象および連続データを見るために、ユーザは様々なプロシージャ事象を識別すべくタイミング情報を与えなければならない。このような手動のプロシージャは、ユーザにとってはやっかいで、間違いが起こりやすい。間違ったユーザ構成データは、バッチ処理におけるプロシージャ事象に関するときにデータを意味もなく提示することにつながる。

対照的に、図２は、集められたプロセス事象データ、バッチプロシージャ事象、および関連の連続データ間の関係を自動的に決定するために、バッチ処理に関する事象情報を記憶し検索するバッチ事象ヒストリアン（batch event historian）２００を含む。このような関係をこのように自動的に決定することで、本発明により、このような事象タイミング情報を手動で構成する従来技術は必要ではなくなる。このような事象を構成する従来技術によりユーザに課されたやっかいな負担とこのような手動プロシージャから生じる誘導されたエラーはなくなる。

特に、バッチ事象ヒストリアン２００は、多数のデータソースから事象情報を受け取り、集められた事象データの間の関係を決定するバッチヒストリアンエグゼクティブ２０２(batch historian executive)を含む。より特定的には、好ましい実施の形態にいては、エグゼクティブ２０２は、プロセス事象ログ１０２およびプロセス事象サーバ２１８によってプロセス事象１０１を受け取る。上で述べたように、プロセス事象は、物理的機器および／またはバッチとのオペレータの対話（図示せず）により生成される。プロセス事象ログ１０２はしたがって、プロセス事象サーバ２１８により処理されるべきこのような事象をバッファするためのバッファ（即ち相互プロセス通信ＦＩＦＯまたはパイプ）を表す。エグゼクティブ２０２は、バッチ事象２１４およびバッチ事象サーバ２１６によってバッチサーバ事象（プロシージャ自称とも称される）２１２を受け取る。上記のように、バッチ事象２１４は、バッチ処理を行うバッチサーバプロセス（図示せず）により生成される。バッチ事象２１４はしたがって、バッチ事象サーバ２１６により処理されるべきこのような事象をバッファするためのバッファ（相互プロセス通信ＦＩＦＯまたはパイプ）を表す。

プロセス事象サーバ２１８およびバッチ事象サーバ２１６は、この実施の形態においては、エグゼクティブ２０２とその接続されたデータソースバッチ事象２１４との間で、またエグゼクティブ２０２とプロセス事象ログ１０２との間で共通の相互プロセス通信インターフェースを与えるために存在する。当業者は、可能性として異なるデータフォーマットを有する多様なデータソースからエグゼクティブ２０２がデータを集めることが出来るような均等のソフトウェア構造を認めるだろう。図２に示される好ましい実施の形態はしたがって、エグゼクティブ２０２と多様なデータソースとの間の単一の共通のインターフェースを可能化するためのひとつのこのような設計選択の例と意図される。さらに、当業者は、どんな数のデータソースでもエグゼクティブ２０２により統合されてその間の事象関係を決定すると認めるだろう。好ましい実施の形態において、各データソースは、そのデータソースを標準フォーマットに変換し、周知の相互プロセス通信技術によってこのような標準データをエグゼクティブに与えるようにサーバプロセスと関連付けさせられる。

本発明の構造および方法は、任意の数のデータソースをバッチヒストリアンエグゼクティブ２０２に接続することが可能であることが意図される。他の事象２４０はしたがって、持続性記憶装置（persistent store）に記録される他の種類の事象を表し、バッチ処理階層またはプロシージャ要素および物理的要素に関する。このような他の事象のログ２４２は、処理のためにこのような事象の生成をバッファするように機能する。他の事象サーバ２４４は次いで、ログされた他の事象を処理し、それらを持続的記憶のためにエグゼクティブ２０２に与える。当業者は、どんな数のこのようなデータソースでもエグゼクティブ２０２に接続されてよいことを認めるだろう。各々は、ログされた事象情報を、エグゼクティブ２０２へ入力するために指定された標準的なフォーマットに変換するサーバプロセスと関連付けられる。

エグゼクティブ２０２は、バッチサーバ２１２から受けとられた事象メッセージから、実行されたプロシージャ事象のバッチプロセスプロシージャ階層を再構成する。バッチサーバ２１２は、各プロシージャ要素がある特定の識別されたバッチの代わりに実行されるときにメッセージを生成する。このようなメッセージの事象情報は、特定のプロシージャ要素を識別する識別情報とその事象の時間とを含む。事象は、プロシージャ要素の開始、停止、休止、中止などを含む。本質的には、Ｓ８８規格のプロシージャモデルの状態遷移全てにより、事象情報メッセージが生成され、（バッチ事象サーバ２１６によって）メッセージがエグゼクティブ２０２に伝送される。他の事象メッセージ全ては、エグゼクティブ２０２により再構成されたプロシージャ階層に関している。

エグゼクティブ２０２は、再構成されたバッチ処理プロシージャ実行を反映するＤＢ２０４内にオブジェクトを記憶する。エグゼクティブ２０２は、その接続されたデータソースからこのような集められた事象情報全てを検査し、そこで参照されるバッチ事象がエグゼクティブにすでに知られているかどうか決定する。このような事象がエグゼクティブに知られているのは、本質的にそれらがＤＢ２０４内にオブジェクトとして前に記憶されていると発見されるときである。新たなバッチ事象が検出されると、適切な記述オブジェクトが生成され、ＤＢ２０４内に記憶される。例えば、あるフェーズが開始された場合、識別情報およびタイムスタンプ情報全てを含むそのフェーズのためのオブジェクトが生成され、記憶される。そのフェーズがＤＢ２０４内でもうすでに知られているオペレーションに関連する場合、それらの関係は確立される。もしもオペレーション（またはユニットオペレーションまたはプロシージャ）が現在知られていないならば、プロシージャ階層実行のこれらの高レベルを反映するために、他のオブジェクトがＤＢ２０４内で生成されて記憶される。バッチ事象サーバ２１６により各バッチ事象メッセージを受け取ることで、エグゼクティブ２０２がバッチプロシージャ実行を再構成できる事象情報を与えることが出来る。

エグゼクティブ２０２は、プロセス事象ログ１０２とプロセス事象サーバ２１８とによって受け取られたプロセス事象１０１も、ＤＢ２０４内に記憶する。バッチ事象とプロセス事象との間の関係はそれにより、手動のユーザの構成を必要とせずに、ＤＢ２０４内で自動的に作成され保持される。

オブジェクトＡＰＩ２２２は、ＤＢ２０４内に記憶された事象情報と得られた関係とに対しユーザがアクセスするためのオブジェクト志向のプログラミングインターフェースを与える。好ましい実施の形態において、バッチ事象ヒストリアン２００は、ＤＢ２０４内に記憶された情報に外部からアクセスできるように構造化照会言語（Structured Query Language）(SQL)インターフェース２０６を与える。オブジェクトＡＰＩ２２２はしたがって、オープンデータベースコネクティビティ（ウインドウズ（登録商標）のソフトからネットワーク上のデータベースにアクセスするためのインターフェース規格）（ＯＤＢＣ）ドライバ２２０およびＳＱＬインターフェース２０６によりＤＢ２０４にアクセスする。この構造により、基礎となる持続性記憶装置はユーザまたはアプリケーションクライアントプログラムに対し大幅に見えなくなる。持続性記憶装置は、ＯＯＤＢＣ技術を用いて図２の好ましい実施の形態において示されるように実現されて良い。または、隠された基底構造を考慮して、持続性記憶装置は、標準的な関係のモデルデータベース管理パッケージまたは他の構造化記憶サブシステム２０４を用いて実現されてよい。さらに説明すると、ＤＢ２０４は、複数の入手可能な記憶管理ツールのいずれかを用いて複数の周知の方法のいずれかで記憶アーキテクチュアが構造化されてよいことを強調するために、持続性記憶装置、オブジェクト記憶装置およびそれの他の変形と同義に称される。本発明にとって重要なのは、バッチ事象および他の集められたデータ間の関係を導出するエグゼクティブ２０２の機能と、ユーザの代わりにこのような事象情報および関連の連続データに目に見えないようにアクセスするＡＰＩ２２２である。

例として示されるユーザアプリケーション２２４−２３０は、オブジェクトＡＰＩ２２２を用いて持続性記憶装置内の情報にアクセスする。ビュークライアント２２４は、獲得された履歴データの標準化された階層的ビューを与えるユーザアプリケーションの一例である。ビュークライアント２２４は以下に詳細に述べる。報告クライアント２２６は、履歴データから標準化された報告を作成するユーザアプリケーションの一例である。このような標準的な報告は、例えば、生成されたバッチの質およびバッチ処理で用いられている機器または特定のバッチ処理の進行に関する標準的な状態報告を監視する品質保証関連報告をふくんでよい。ＳＱＬブラウザクライアント２２８は、ユーザが持続性記憶装置に記憶された情報をざっと目を通すためにＳＱＬ規格問い合わせインターフェースを与えるユーザアプリケーションの例である。同様に、ユーザＳＱＬ ＡＰＩ２３０は、他のユーザ生成アプリケーションプロセスが標準的な問合せプログラミングインターフェースを用いて持続性記憶装置にアクセスできるユーザアプリケーションの一例である。当業者は、ユーザアプリケーション２２４−２３０が持続性記憶装置内のデータを利用する共通のアプリケーションプログラムの例であると意図されると認めるだろう。当業者は、持続性記憶装置へのこの標準的なインターフェースを利用することが可能な様々な同様のアプリケーションを認識するだろう。

オブジェクトＡＰＩ２２２のさらなる機能は、ユーザが連続データ１００にアクセスする標準的なインターフェースを与えることである。オブジェクトＡＰＩ２２２により、ユーザはまるでそれがＤＢ２０４内で統合されＤＢ２０４内のオブジェクトと関連づけられているかのように連続データ１００にアクセスできる。言いかえると、オブジェクトＡＰＩ２２２により、全てのデータが単一のデータベース内に記憶されているかのようにユーザは自由に、アクセスプロセス事象、関係のバッチ事象および関係の連続データを混合（intermix）することができる。正しい持続性記憶装置（即ちＤＢ２０４または連続データ１００）にユーザがアクセスするように指示して、そのデータをユーザの要求と関連付けさせるのに必要な関係全てを決定することは、オブジェクトＡＰＩ２２２により共通のユーザインターフェースを用いて処理される。ユーザは、特定のバッチ事象を指定して、ここから関連のバッチ事象全て（階層的に関連するプロシージャ要素）、関連のプロセス事象すべて、および関連の連続データにアクセスしてもよい。様々なデータの間の関係は、本発明のエグゼクティブ２０２およびオブジェクトＡＰＩ２２２により自動的に決定される。

診断インターフェース２０８および管理インターフェース２１０は持続性記憶装置（ＤＢ２０４）を管理するための管理ユーザインターフェースを与える。特に、ヒストリアンの処理を開始するか停止する要求または持続性記憶装置を再構成する（即ちＤＢのサイズを変更するかまたはデータソースについての情報を付加／除去／修正する）要求が、診断インターフェース２０８によっておよび／または管理インターフェース２１０によってユーザにより生成される。

管理インターフェース２１０は、エグゼクティブ２０２のアーカイバル（archival）特徴も制御する。エグゼクティブ２０２は、バッチベースのバックアップを制御可能に行なう。バッチベースのバックアップとは、ある特定のバッチの処理に関連した持続性記憶装置内の事象全てをバックアップするものである。バックアップは、ＤＢ２０４の別のセクション内で作成されて、それを他の処理のためにセーブしてよい。持続性記憶装置のこれらのバックアップセクションは、オフライン処理のためにＤＢ２０４から「切り離され(detached)」てよい。本質的に、管理インターフェース２１０は、エグゼクティブ２０２に、ひとつ以上の識別されたバッチのための事象情報すべての「スナップショット(snapshot)」を作成するように命じる。スナップショットは次いで、オフライン処理技術を用いて安全なバックアップにコピーされてよい。このようなアーカイブ（archived）事象情報は、さらなるバッチ履歴情報のために空きを作るために持続性記憶装置から消去されてよい。後に、初期のアーカイブはＤＢ２０４に回復されて（再接続されて）このデータが再び見られて動作されるようにされてよい。このようなアーカイブ情報を消去および回復することは、エグゼクティブ２０２を制御する管理インターフェース２１０の制御により行われる。

当業者は、診断インターフェース２０８および管理インターフェース２１０は、バッチ事象ヒストリアン２００の不可欠な要素ではないと認めるだろう。当業者により設計選択として様々な均等構造が用いられてよい。または、例えば、バッチ事象ヒストリアン２００は持続性記憶装置を静的に構成しても、および／またはそのオペレーションを開始および停止するためにユーザインターフェースなしで実行されて良い。このようなアーカイブ（スナップショット）事象情報は、さらなるバッチ履歴情報のために空きを作るために持続性記憶装置から消去されてよい。

当業者は、バッチ事象ヒストリアン２００および関連のオブジェクトＡＰＩ２２２のアーキテクチャが本発明の好ましい実施の形態の例を意図するものと認識するだろう。アーキテクチャの多数の変形例が当業者には生じるだろう。例えば、連続データ１００は、既存のインストールされたシステム（通常はレガシー（legacy）システムと称される）がこのような情報の持続的記憶ロギングを与えることに関わらないＤＢ２０４内で併合される。または、たとえば、事象情報のための持続性記憶装置は、オブジェクト志向のデータ記憶装置以外のものであってよい。または、さらなる例として、バッチエグゼクティブ２０２は、サーバプロセス（２１６および２１８）に依存することよりむしろ事象情報を与える様々な入力ソースに直接アクセスして、その入力を標準的形に変換してもよい。このような設計の選択多くが当業者には明らかである。

（バッチ事象履歴実行方法）
図３から８は、バッチヒストリアン２００および特にバッチヒストリアンエグゼクティブ２０２の動作を説明するフローチャートである。図３は、図２のバッチヒストリアンエグゼクティブ２０２のハイレベルの動作を説明する。図４から図８は、エグゼクティブの動作の特定のアスペクトに関するさらなる詳細を説明する。

図３の要素３００は、全ての現在構成されたデータソースへの接続を確立するように、即ちデータソースへ「接続」するように動作可能である。上で説明したように、好ましい実施の形態において、エグゼクティブと各データソースと関連するサーバプロセスとの間で、相互プロセス通信が用いられる。現在構成されたデータソースは持続性オブジェクト記憶装置内に記憶されたヒストリアンの構成パラメータである。好ましい実施の形態においては、２つのデータソースがある、即ちプロセス事象およびバッチ事象（プロシージャ事象）である。

さらなる相互プロセス通信リンクは、ユーザがバッチヒストリアンの動作を管理できるように診断インターフェースプログラムおよび管理インターフェースプログラムに対し要素３０２により確立される。上で述べたように、診断インターフェースおよび管理インターフェースにより、ユーザはバッチヒストリアンの動作を、その動作を開始するかまたは動作を停止することにより管理できるようになる。例えば、持続性記憶装置の容量または位置を変更すること、エグゼクティブに接続されたデータソースを付加／除去／修正すること、またはアーカイバル管理機能を実行することを含め、他の構成変更は、これらのインターフェースにより許可される。

要素３０４−３１２は、接続されたデータソース（管理インターフェースおよび診断インターフェースを含む）のいずれかからエグゼクティブで受け取られたデータを処理するように反復的に動作可能である。要素３０４はまず、メッセージが管理インターフェースまたは診断インターフェースから利用可能であるかどうか決定するように動作可能である。上で述べたように、これらのインターフェース（データソース）は、エグゼクティブに、動作を開始または停止するオペレータ入力と、持続性オブジェクト記憶装置のサイズまたは位置またはデータソースの付加／除去／修正のような再構成情報とを与える。このようなメッセージが利用可能であれば、要素３０６は、管理データソースおよび診断データソースから利用可能なこのようなメッセージ全てを処理する。両方の場合、処理は要素３０８へ進む。

要素３０８は、メッセージが他の構成されたデータソースから利用可能であるかどうか決定するように動作可能である。このましい実施の形態において、これらのデータソースは、少なくともバッチ事象データソースとプロセス事象データソースとを含む。バッチ事象データソースは、バッチプロシージャの実行においてバッチサーバプロセスにより生成された事象を記述するメッセージを与える。上で述べたように、好ましい実施の形態で、これらのメッセージは、メッセージを好ましい標準形に変換するサーバプロセスによって与えられる。同様に、プロセス事象は、サーバプロセスによって与えられたメッセージであり、バッチの処理の間に機器およびオペレータにより生成された情報を反映する。

このような事象情報が現在構成されたデータソースから利用可能であれば、要素３１０はこのようなメッセージ全てを処理するように動作可能である。メッセージの処理は、様々な事象の発生を記録し、様々な集められた事象の間の関係を生成するために持続性記憶装置内に適切なオブジェクトを記憶することを含む。特に、要素３１０は、このように処理されたメッセージからバッチプロシージャ事象の時間線および階層を再構成する。例えば、新たなフェーズが開始された場合、記憶されたオブジェクトは、関連のオペレーション、ユニットプロシージャ、およびプロシージャについての情報を記録する他のオブジェクトに関している。このような関連のオブジェクトが持続性記憶装置内に存在しないときに、要素３１０は、受け取られたフェーズ開始事象を処理するとすぐにこのような関連のオブジェクトを作成する。要素３１０の処理のさらなる詳細は図６を参照して以下に説明される。

全てのデータソースから現在利用可能なメッセージ全てが要素３０４−３１０により処理されてしまうと、要素３１２は、ヒストリアンエグゼクティブの状態を更新するように動作可能である。持続性記憶装置に行われた更新は好ましくは、高速のキャッシュされた（cashed）動作において行われる。様々なオブジェクトの揮発性（volatile ）のキャッシュされたバージョンは、エグゼクティブにより処理されたメッセージのために必要に応じて操作される。要素３１２は周期的に、これらの揮発性のキャッシュされたオブジェクトに対するこのような変更をバッチ事象ヒストリアンの持続性記憶装置にコミットする。さらに、要素３１２は、診断インターフェース要求または管理インターフェース要求を処理して、持続性記憶装置のサイズまたは位置を再構成する。要素３１２の処理のさらなる詳細は、図８を参照して以下に説明される。

処理は、新たに受け取られたメッセージを処理するために要素３０４に戻る。

当業者は、バッチヒストリアンエグゼクティブにおける処理の上で説明した方法を実行するための多くの均等ソフトウェア技術を認識するだろう。例えば、メッセージを受け取ると、他の休止状態の実行プロセスを上で説明されたメッセージポーリング技術とははっきりと区別されるものとして、よび起こすだろう。または、例えば、オブジェクトの操作は、揮発性のキャッシュされたオブジェクトにおいてよりもむしろ持続性記憶装置おいて直接に行うことが可能であり、それにより前の変化を周期的に行う必要はなくなる。設計選択のこのような問題は、ソフトウェアの当業者には周知である。

図４は、バッチヒストリアンエグゼクティブに接続された所望のデータソース全てに対し接続するための要素３００の動作に関するさらなる詳細を示す。要素４００は、ヒストリアンエグゼクティブのためにデータソースの現在の構成を識別する情報を持続性記憶装置から得るように動作可能である。上で説明したように、エグゼクティブは好ましくは、持続性記憶装置内にこの構成情報を記憶し、診断インターフェースまたは管理インターフェースからのユーザ入力にしたがってそれを更新する。データソースは好ましくは、エグゼクティブに接続されるべき相互プロセス通信チャンネルにより特定される。他のメタデータは、関連するデータソースから受けとられるメッセージの構造および意味を記述した状態で含まれる。

要素４０２および４０４は次いで、ヒストリアンエグゼクティブと持続性記憶装置で反映される現在の構成で見出される各データソースごとの関連のサーバプロセスとの間に接続を確立するように反復的に動作可能である。要素４０２が、現在構成されたデータソース全てが要素４０４により処理されてしまったと決定するとき、要素３００の処理は終了する。

図５は、オペレータからの管理メッセージおよび診断メッセージを処理するための図３の要素３０６の動作のさらなる詳細を記述するフローチャートである。要素５００はまず、アーカイブ要求が受け取られたかどうか決定するように動作可能である。もしそうならば、要素５０２は次ぎにアーカイブ要求を処理するように動作可能であり、それにより要素３０６の処理を終了する。そうでなければ、処理は要素５０４へと進む。

アーカイブ要求は、エグゼクティブに、持続的に記憶装置内に記憶されたオブジェクトのある部分をアーカイブおよび／または消去するように命令する。例えば、オペレータは、エグゼクティブに、重要でない理由で失敗したことがわかったある特定のバッチに関するオブジェクト全てを消去するように要求するかもしれない。このような無関係のオブジェクトを持続性記憶装置内に記憶されたままにしておくのではなく、オペレータは、エグゼクティブへの管理インターフェースまたは診断インターフェースを利用して、関連のオブジェクトの消去を要求するかもしれない。または、例えば、アーカイブ要求は、エグゼクティブにオブジェクトを検索し、それらを新しい位置にアーカイブし、そして持続性記憶装置からアーカイブされたオブジェクトを除くようにたのむ。このような要求は、古い処理されたバッチに関する古いオブジェクトを処分するのに用いられてよい。このようにアーカイブされたオブジェクトは、新たなバッチのためのオブジェクトを記憶するために空間を空けながら、アーカイブ目的のためにコストのかからない「オフライン」記憶装置へと移動させられてよい。

アーカイブメッセージＡＰＩは、ある特定のバッチに関する記憶された事象として手動で入力されたオペレータ注釈を挿入するのにも用いられる。例えば、オペレータは、バッチ処理により通常は感知されないかまたは記録されないある環境情報を記録してよい。または、例えば、オペレータは、ある特定のバッチに責任のあるオペレータが記憶された事象情報と関連するようにあるシフト上にその人個人の開始時間および停止時間をログしてよい。当業者は、オペレータにより記録され、対応するバッチ事象およびプロセス事象に関するオブジェクト内に記憶される多様なこのような補助情報を認識するだろう。

アーカイブ要求が存在しないとき、要素５０４は、停止要求が診断インターフェースまたは管理インターフェース上で受け取られたかどうか決定するように動作可能である。もしそうならば、要素５０６は、揮発性キャッシュ記憶装置内の現在コミットされていないオブジェクトを持続性記憶装置にコミットするように動作可能である。エグゼクティブ自身の処理はそれで終了する。エグゼクティブは、ヒストリアンエグゼクティブが動作可能であるサーバノードとユーザが通常に対話することでオペレータにより再開始される。

図６は、実行動作で現在構成された他のデータソースからの事象情報メッセージを処理するための図３の要素３１０の動作のさらなる詳細を記述するフローチャートである。要素６００はまず、現在構成されたデータソース全てが以下で説明されるように要素６０２、６０４により処理されたかどうか決定するように動作可能である。もしデータソース全がこのように処理されてしまっていたら、要素３１０の処理は完了する。あるデータソースがまだ処理されていないとき、要素６０２は、処理されるべき次ぎのデータソースからなんらかのメッセージが現在利用可能であるかどうか決定するように動作可能である。メッセージが利用可能であれば、要素６０４はそのデータソースから利用可能な次ぎのメッセージを処理する。データソースからの次ぎの利用可能なメッセージの処理に続いて、次ぎの診断メッセージまたは管理メッセージを処理できるように、制御は呼び出し機能に戻る。このようにして、データの全てのソースは、単一のデータソースからの多量のメッセージが延長された時間期間においてヒストリアンの処理を独占するのではなく相対的に等しい優先順位で処理される。

図７は、あるデータソースからのあるメッセージを処理するための図６の要素６０４の処理をさらに詳細に説明するフローチャートである。要素７００はまず、そのメッセージが知られている種類のものであることを確認する。好ましい実施の形態において上で説明されたように、全てのメッセージは、各データソースと関連するサーバプロセスにより標準形に変換される。その標準形のある態様は好ましくは、メッセージをある特定のデータソースと関連するものとしてまたその対応するサーバプロセスと関連するものとしてメッセージを識別するメッセージタイプの識別子である。要素７００はしたがって、このメッセージタイプがエグゼクティブに知られているタイプかどうか決定する。未知のメッセージタイプであれば、要素７１２へと進み、未知のメッセージに対応するオブジェクトを作成する。後に行われる後処理がこのようなメッセージを評価して、バッチ処理の他の事象に対するそれらの原因または関係を決定できるように、未知のメッセージでさえ持続性記憶装置内に保持される。未知のメッセージは、出来るだけ構文解釈され、その未知のメッセージが関連する持続性（永続性）の記憶装置内の他の可能性のあるオブジェクト（事象、機器など）に関連付けられる。要素７１４は、エグゼクティブにより記憶された統計内の未知のメッセージタイプを受け取るように動作可能であり、それにより要素６０４の処理を終了する。メッセージタイプが認識されたことで、処理は要素７０２へ進む。

要素７０２は、メッセージ内に含まれる事象情報からキーを生成する。メッセージの処理は、そのメッセージに含まれる事象情報に関するバッチ事象の階層を記述するメッセージからキーを生成することを含む。キーは、例えば、バッチ識別、プロシージャ識別、ユニットプロシージャ識別、オペレーション識別、およびフェーズ識別を含む。要素７０４は、生成されたキー値に一致する持続性記憶装置内のオブジェクト（または揮発性記憶装置内の現在キャッシュされたオブジェクト）の位置を突き止めるよう動作可能である。要素７０６は、要素７０４が持続性オブジェクト記憶装置内で所望のオブジェクトの位置を突き止めたかどうか決定する。このようなオブジェクトが見つけられると、（即ち、持続性オブジェクト記憶装置または揮発性オブジェクト記憶装置内でもうすでに記録されている）、処理は７１０へと進み、エグゼクティブにより操作される既知のオブジェクトに関する統計を更新する。生成されたキーに一致するオブジェクトの位置を突き止められなければ、要素７０８へと処理は進む。

要素７０８は、生成されたキーに基づいて持続性オブジェクト記憶装置内でまだ未知であるが必要なオブジェクト全てを作成するように動作可能である。例えば、バッチが現在はエグゼクティブにとって未知であるならば、メッセージ内の事象情報から得られたプロシージャ事象全てのためのオブジェクトだけでなく、バッチ自身のオブジェクトも作成される。具体的には、メッセージ内の事象情報から得られたプロシージャ、ユニットプロシージャ、オペレーションまたはフェーズも未知であろう。なぜなら、バッチ自身も以前はエグゼクティブにとっては未知であったからだ。メッセージの事象情報から得られたこれらのバッチ事象の各々に対応するオブジェクトは、持続性オブジェクト記憶装置内で作成される。上で述べたように、作成されたオブジェクトは、そのイベントのタイムスタンプ次用法および識別情報とを含む。オブジェクト間の関係は同様にオブジェクト記憶装置内で作成される。

活性化、開始時間、終了時間、および非活性化時間を示す別個の事象メッセージは、各プロシージャ要素ごとに受け取られる。これらの事象メッセージのひとつが受け取られるときはいつでも、適切なプロシージャ要素を記述するオブジェクトは持続性記憶装置内で発見されるか作成され、時間はオブジェクト内の適切なフィールドに付加される。機器の使用（バッチ処理において物理的な要素を使用すること）ための事象メッセージは、機器のための獲得時間および解放時間を識別する。同様の処理は、適切な機器のための持続性記憶装置内で使用記述オブジェクトを位置付けるかまたは作成するのにもちいられ、オブジェクトの適切なフィールドに獲得時間および解放時間を付加する。バッチ処理に対するオペレータ変更のような他の事象タイプ全ては、より詳細な開始、停止などの時間よりもむしろ事象の発生の時間だけを有する。

処理は次いで要素７１０へと進み、上で述べたように記憶された統計的情報を更新する。

上で述べたように、キーは、受け取られた事象メッセージに対応するオブジェクトの位置を突き止めるように生成される。このましい実施の形態において、様々な目的のために生成された多様なこのようなキーがある。ひとつのキーは、受け取られた事象メッセージのタイプを識別するのに用いられる。メッセージタイプキーは実際は、バッチヒストリアンエグゼクティブによりメッセージの残りの適切な内部処理を選択するのに用いられる。別のキーは、ある記憶された事象の具体的なインスタンスを識別し、メッセージがすでに受け取られ処理されたかどうか決定するのに用いられる。このキーを使用すると、同じ事象の重複記述を記憶する必要はなくなる。さらにべつのキー値は、バッチ記述、レシピ記述、式記述、プロシージャ要素、機器識別、機器使用記述またはユーザ識別のようなオブジェクトの具体的インスタンスを識別する。このキーは、メッセージがさらなる情報を既存のオブジェクトと関連させるときに持続性記憶装置内で既存のオブジェクトの位置を突き止めるのに用いられる原理（principle）キーである。

図８は、データソースからのメッセージの処理に続いてオブジェクト記憶装置を更新するための図３の要素３１２の処理のさらなる詳細を記述するフローチャートである。オブジェクトは好ましくは、メッセージが処理されるときに揮発性高速キャッシュメモリ内で更新される。揮発性高速キャッシュメモリ内で周期的に更新されたオブジェクトは、永久保存のために持続性記憶装置にコミットされる必要性がある。好ましい実施の形態において、揮発性高速キャッシュ記憶装置内のオブジェクトは、前のこのようなコミットメントから十分な時間が経過したとき、または前のコミットメントから後十分なメッセージが受け取られ処理されたときに記録される。要素８００、８０２はしたがって十分な時間が経過したかまたは十分なメッセージがエグゼクティブにより処理されたかどうか決定するように動作可能である。いずれの条件でも真であれば、処理は要素８０４へと進み、揮発性オブジェクト記憶装置内の変更されたまたは新たなオブジェクトを持続性記憶装置にコミットする。処理は要素８０６へと進む。

要素８０６および８０８は、オペレータ要求により与えられた構成変更に応答してオブジェクト記憶装置の構成を更新するように動作可能である。このような要求の例は、実行プログラムにより処理されるべきメッセージのデータソースを付加／除去／修正する要求である。このような構成変更が要求されたと要素８０６が決定するならば、要素８０８は、オブジェクト記憶構成および実行動作において要求された変更を完了する。両方の場合、処理は要素８１０へと進む。

要素８１０、８１２は、オペレータ要求にしたがって持続性オブジェクト記憶装置のサイズを変更するように動作可能である。このような要求がなされたと要素８１０が決定するならば、要素８１２は、オブジェクト記憶装置サイズの必要な変更を完了するように動作可能である。

ここで使用される、オブジェクト記憶装置または持続性記憶装置は、揮発性キャッシュメモリ内に一時的にキャッシュされたかオブジェクト記憶装置に持続的に記憶された（コミットされた）オブジェクトの全ての記憶装置を指す。性能を向上させるこのようなキャッシュ技術は、当業者にとっては周知の設計選択の問題である。

（バッチ事象履歴ビュークライアント）
図２に関して述べたように、本発明は、ユーザが事象情報とバッチ履歴エグゼクティブにより得られる様々な事象の間の関係を見る際のかなりの柔軟性を可能とするビュークライアントプロセスを含む。ビュークライアントは、ガント（Ｇａｎｔｔ）チャート表示を用いて図表で、ユーザフレンドリに事象情報を表示し、バッチ事象および関連のプロシージャ階層事象を表現する。図形のユーザインターフェースによって、ユーザは、「掘り下げられ（drill down）」るようにこのように表示された事象を選択して、この選択された事象を構成する低レベルの階層的事象を見ることができる。選択された事象を含む階層的に低い事象の文字表のフォーマット提示は、図形のガント（Ｇａｎｔｔ）チャート表示以下の文字表フォーマットで表示される。本発明のビュークライアントにより、ユーザは、連続データを関連の事象情報と関係付ける方法で、ログされたデータポイントのための連続データを図表でみることが出来る。言いかえると、連続データは、ユーザのディスプレイからバッチ事象を選択し、その選択された事象のための連続データがひとつ以上の選択されたデータポイントのために表示されることを要求することにより見られる。

図１０−２１は、バッチ事象履歴ビュークライアントの動作を説明する表示画面画像の例である。図１０は、バッチオーバービューを示す表示画面の例である。オブジェクト記憶装置内に記録された事象情報を有する各バッチ１００２は、ユーザのディスプレイのあるウインドウ上でガントチャートスタイルで示される。ガントチャート形でこのように表示される各バッチごとに、対応する表文字エントリは事象詳細表１０００に示される。ガントチャート表示と関連する水平方向のスクロールバー１００４により、ユーザはガントチャート表示内で水平方向にスクロールし、それと関連する前の時間または後の時間を有するバッチを見る。事象詳細表１０００と関連する垂直スクロールバー１００６により、ユーザは、現在はガントチャート形で表示されていない他のバッチをスクロールできる。エントリが事象詳細表１０００内に表示されるすべてのバッチは、表の上方にガントチャート形１００２で示される。

図１０に示されるように、各バッチは、バッチのガントチャート上でおよび事象詳細表１０００内の対応する文字エントリにおいてその対応するバッチＩＤの標識がついている。

図１１に示されるように、ユーザは、そのバッチの処理のさらなる詳細を検査するために、表示されたバッチのうちひとつを選択してもよい。ユーザは、所望のバッチを「クリックする」ことで特定のバッチを選択する。図１１で、バッチ１１００（ＥＥ １９９８１０１９．００９の標識がつけられた）はユーザにより選択された。選択されたバッチは表示画面上で強調表示され、対応する表エントリ１１０４も強調表示される。ポップアップメニュ１１０２は、選択されたバッチ上で典型的には「右クリック」することで起動される。ポップアップメニュにより、ユーザは、選択されたバッチの処理に関するさらなる詳細の表示を要求できる。

図１２は、バッチ１１００（ＥＥ １９９８１０１９．００９と標識を付けられた）の処理の詳細の表示の一例である。ユーザは、この表示画面を閉じて（図１１の）バッチオーバービュー画面に戻って良い。バッチを作成したプロシージャ１２０２（ＥＸＴＥＲＩＯＲ ＥＮＡＭＥＬと標識を付けられたプロシージャ）が、ユーザの画面のガントチャート表示領域の全体の幅に合わせて基準化されたガントチャート形で示される。特に、このプロシージャは１９９８年１０月１９日の７時５７分１２秒AMで開始され、同じ日の８時９分６秒ＡＭで終了した。このプロシージャを含むプロシージャ１２０４、１２１０は、ガントチャート形で以下に示される。各ユニットプロシージャを構成するオペレーション１２０６、１２１２も、ガントチャート形で対応するユニットプロシージャの下に示される。最後に、各オペレーションを構成するフェーズ１２０８、１２１４は、ガントチャート形で対応するオペレーションの下に示される。

好ましい実施の形態において、プロシージャ、ユニットプロシージャ、オペレーションおよびフェーズガントチャートは、カラーコーディング（color coding）により容易に区別される。カラーコードレジェンド（color code legend）１２１６はしたがって、ガントチャートのカラーコーディングを明確にするために与えられる。

事象詳細表１２２２は、選択されたバッチを作成したプロシージャの実行を含む事象を示す。垂直のスクロールバー１２１８により、表１２２２で現在は示されない付加的な事象情報をスクロールすることができる。同様に、表１２２２と関連する水平方向のスクロールバーにより、ユーザは、表１２２２内で現在の表示された事象の付加的な事象をスクロールできる。

スクロールバー（図示せず）は、ディスプレイのガントチャート部分と関連してよい。一般に、事象詳細表１２２２で示される事象情報は、ディスプレイのガントチャート部分において図表で選択されたプロシージャ要素に対応する。当業者は、厳密な対応関係は必要でもなく実務的でもないと認識するだろう。各セクションに提示されるレベルは、ある特定の選択されたプロシージャ要素と他の階層的に関連する要素および事象とに関連する実際の事象にしたがって変動するかもしれない。好ましい実施の形態において、事象詳細表１２２２およびガントチャート表示部分は、相関させられた情報を示すために調整されるが、ディスプレイの両方のセクションのスクロールバーにより、ユーザはデータの所望の部分を見ることができる。

ディスプレイの一番上にあるツールバーにおける詳細選択ツール１２００により、ユーザは、選択されたバッチに関して表示されるべき詳細の好ましいレベルを選択できる。レベル１−４が好ましい実施の形態において選択されて良い。レベル１で、バッチを含むプロシージャだけが表示される。レベル２で、プロシージャが表示され、対応するユニットプロシージャがそのプロシージャ下で表示される。レベル３で、プロシージャ、ユニットプロシージャおよび対応するオペレーションが表示される。最後に、レベル４で、プロシージャ、ユニットプロシージャ、オペレーションおよび対応するフェーズが表示される。

図１３は、ユーザがある特定の事象を選択してそれに関連するさらなる詳細を見る態様を示す。図１３に示されるように、ＣＨＡＲＧＥ ＣＯＬＯＲ：１．１と名づけられたフェーズ１３００が選択された。フェーズ１３００のためのガントチャートバーおよび対応する表エントリ１３０４がしたがって強調表示される。ポップアップメニュ１３０２により、ユーザは選択された事象に特に関連する事象（即ちフェーズ１３００内の事象）についてより多くの事象を要求できる。図１４は、図１３の詳細情報要求から結果として生じる表１４００の例である。ユーザは、この表示画面を閉じて（図１３の）前の画面に戻って良い。

図１５は、図１０において上で述べたバッチオーバービュー表示画面であり、ここではユーザは比較目的で２つのバッチ１５００、１５０１を選択した。選択されたバッチ１５００、１５０１および対応する文字エントリ１５０６、１５０４それぞれは、したがってディスプレイ上で強調表示される。ポップアップメニュ１５０２により、ユーザは表示画面上の２つの選択されたバッチを比較することが出来る。当業者は、任意の数のこのような選択されたバッチが比較されて良いことを認識するだろう。

図１６は結果として生じる比較画面を示す。ＥＥ １９９８１０１９．０１１と標識を付けられたバッチ１６００は、上で述べたようにガントチャート形で示され、対応する文字表１６０２で示される。ＥＥ １９９８１０１９．０１０と標識を付けられた第２の選択されたバッチ１６０４がガントチャート形で示され、対応する文字表１６０６で示される。最初に両方のバッチは、それらのそれぞれのガントチャートの対応する左エッジで実際の開始時間と同じ時間スケールで表示される。

図１６のバッチ比較画面により、ユーザは、２つのバッチの処理の差を素早く見ることができる。例えば、２つのバッチの１つが既知の良品質を作成した完全なまたは「素晴らしい」バッチであるならば、第２のバッチの品質問題の原因は、対応する２つのプロシージャ実行のガントチャートの差により簡単に識別されてもよい。

このような差を目で見て検出できるように、絶対時間とは区別されるバッチ相対時間（バッチ処理の開始からの時間）でバッチ処理を見ることは有用である。加えて、必ずしもプロシージャの開始ではなく、プロセスにおけるある特定の選択された開始ポイントの２つのガントチャート表示をユーザが図形で整列させることが出来るのも有用である。このような整列により、ユーザは、ある特定の機器モジュールがバッチ処理においてユーザ入力のために利用可能になるのを待つという遅延のような公知の説明できる差異を無視できる。

図１７において、ユーザは２つの事象１７００、１７０２（即ち両方のプロシージャから同じユニットプロシージャ）を選択した。選択されたユニットプロシージャ１７００、１７０２、および対応する文字表エントリ１７０６、１７０８それぞれがしたがってディスプレイ上で強調表示される。ポップアップメニュ１７０４により、ユーザは整列左オプションまたは整列右オプションを選択できる。整列左オプションは、２つの選択された事象がそれらの開始時間で整列されるように結果として生じる表示をシフトさせる。整列右オプションはそれぞれの終了時間で選択された事象を整列させる。両方の場合において、表示は、実時間スケールよりもバッチ相対時間スケールにトグル（toggle）可能である。

図１８は、図１７の整列左要求から生じる表示である。選択されたユニットプロシージャ１７００、１７０２は、それらのそれぞれの開始時間がガントチャート表示上で整列するように表示される。時間ベースは、バッチ相対時間（絶対時間とは区別されるバッチの開始からの時間）として選択された。番号１８００、１８０２は、バッチ相対時間における時間軸のゼロ時間スタートを指し示す。この整列されたビューにより、別のバッチと比較すると、あるバッチの処理の差を強調できる。過度の量の時間または極端な短時間を費やした事象は、表示内で目に見えるように区別できる。

２つ以上のバッチを目で見て比較することは特に有用であるが、バッチ相対時間のガントチャートの提示は他の有用なアプリケーションを有しても良い。絶対時間からバッチ相対時間へ時間線基礎を変更する能力と、所望の境界でガントチャート表示を整列させる関連の特徴はしたがって、好ましくは本発明の比較特徴から独立している。

バッチ処理における様々なデータポイントからログされる連続データは、ビュークライアントから見られても良い。ユーザは、所望の事象を選択し、それから、連続データをその時間期間の間に表示するように要求する。選択された事象の間に利用可能な特定の連続データポイントは、ユーザが提示されるべきひとつ以上のデータポイントを選択するように、ユーザにダイアログボックス内で提示される。このましい実施の形態において、要求された連続データポイント値は線形のグラフとしてプロットされる。

連続データは、図１８のようにバッチ比較表示から連続データの比較としてプロットされてよい。図１９は、図１８のように異なるバッチの左整列バッチを示し、２つの事象が選択される、即ち１９００、１９０２である。選択されたフェーズ１９００、１９０２および対応する文字エントリ１９０６、１９０８、それぞれがディスプレイ上で強調表示される。ポップアップメニュ１９０４により、ユーザは、連続データの傾向（trend）比較を要求できる。

図２０に示されるダイアログボックスが次いで表示され、これにより、ユーザは傾向比較のための所望の連続データポイントを選択できる。

図２１は、選択された事象持続時間にわたって、選択された連続データポイントを比較するために作成された結果として生じる線形のグラフを示す。

（バッチ事象履歴ビュークライアント方法）
図９は、様々なユーザ要求を処理するためのビュークライアントの方法を記述するフローチャートである。当業者は、図９のフローチャートは、図１０−２１に関して上で述べた様々なユーザ選択および要求のサンプリングを表すものであるとわかるだろう。当業者には周知の設計選択にしたがって様々な表示画面を生成する他のユーザ要求が処理されてよい。図９で説明される方法はしたがって、本発明のビュークライアントの典型的な機能の好ましい実施の形態の単に例として示される。本発明のビュークライアントアスペクトは、バッチ事象、プロセス事象およびあるバッチ事象からの連続データの多様なビューと、S８８プロシージャモデル階層にしたがったこのような事象情報の関係とを与えるように意図される。

要素９００は、持続性オブジェクト記憶装置内で既知のバッチすべてを表示するように動作可能である。あるバッチＩＤに関するオブジェクトが記憶装置内で発見されると、バッチがわかる。既知のバッチは、上で述べたバッチオーバービュー表示のフォーマットで最初に表示される。各バッチがガントチャートバーとして実時間時間線上で示される。各バッチのガントチャートバーは、それぞれの開始時間にしたがって時間線上で水平方向に位置決めされ、それぞれの終了時間により決定される位置まで伸びる。

表示上のスクロールバーにより、ガントチャートは、現在は表示されない後のまたは前の時間を見るために水平方向にスクロール可能である。ガントチャート時間線表示下の文字表は、対応するバッチと関連するバッチ情報を文字で表示する。文字表と関連するスクロールバーにより、表示上に存在しない詳細を見ることが出来る。

要素９０２は、表示されたバッチの少なくともひとつに関するさらなる詳細を与えるユーザ要求を受け入れる。上で述べたように、バッチは、対応するガントチャート上で（または表の対応する文字エントリ上で）ユーザクリックにより選択される。ポップアップメニュまたは他のユーザインターフェースツールは、選択されたバッチに関するさらなる詳細を提示するユーザの要求を受け入れる。

要素９０４は、選択されたバッチのために上で説明したようなバッチ詳細画面を表示する。上で述べたように、詳細のデフォルトレベルは、選択されたバッチ事象およびガントチャートの表示のためにユーザにより決定される。詳細のデフォルトレベルにしたがって、プロシージャ、対応するユニットプロシージャ、対応するオペレーション、および対応するフェーズが、それぞれの開始時間にしたがって整列され、それぞれの終了時間にしたがって伸びるガントチャートバーで表示される。階層的に低いレベルのガントチャートは、それを含む対応する高レベルプロシージャ要素下に表示される。

要素９０６は、現在選択されたバッチガントチャートに対応する事象情報の文字表を表示する。上で述べたように、スクロールバーにより、ユーザは表示上に現在はない付加的データをスクロールできる（表の形ででもまたはガントチャート形ででも）。

要素９０８は、新たな表示を要求するユーザ入力を受け入れる。ユーザがバッチオーバービュー表示に戻ることを要求するならば、要素９１０は、そのように検出するように動作可能であり上で述べたように要素９００にもどることで処理は続行する。そうでなければ、処理は９１２−９３４へと進み、ユーザ要求を処理する。上で述べたように、要素９１２−９３４は、本発明のバッチ事象履歴ビュークライアントにしたがって処理されるユーザの要求の例を意図するものである。当業者は、上で述べられたバッチ履歴エグゼクティブにより決定される関係にしたがって事象情報および関連の連続データを表示するため、多様な付加的なユーザ要求および対応する動作を認識するだろう。

要素９１２、９１４は、ユーザの要求に応答して、新たに選択されたバッチを表示するように動作可能である。新たなバッチが要素９０４、９０６に対して上で述べたように提示される。処理は、要素９０８にもどり、さらなるユーザ要求を待つ。ユーザが別の動作を要求するならば、処理は要素９１６に戻る。

要素９１６、９１８は、事象詳細画面内に表示された詳細のレベルを変更するように動作可能である。上で述べたように、バッチは最初、ユーザにより選択された詳細のデフォルトレベルで表示される。ユーザが表示された情報を解析するとき、バッチ履歴エグゼクティブにより決定される関係により規定されるプロシージャ階層を置かれ少なかれ見ることは有用であるかもしれない。要素９１６、９１８は、上で述べたように表示されたプロシージャ要素の階層を拡大するか崩壊させることによりこのような要求に応答する。処理は、要素９０８に戻り、さらなるユーザ要求を待つ。ユーザが別の動作を要求するならば、処理は要素９２０へと続く。

要素９２０、９２２は、比較目的のために第２のバッチを表示するユーザ要求に応答する。上で述べたように、ユーザのディスプレイ上に第２の（またはそれ以上の）バッチを同時に表示することがしばしば有用である。このような比較表示（比較文字表と関連する）により、ユーザがバッチ間の重要な差異を目で見て識別できるようになる。例えば、第１のバッチは、既知の高品質品を作成した「素晴らしい」バッチであるかもしれない。第２のバッチは、粗悪な質の品を作成したものかもしれない。このような差異の理由は、上で述べたバッチ比較表示で容易に観察されるＧａｎｎｔｔチャート時間線比較から容易に明らかである。処理は次いで要素９０８に戻ることで続行され、さらなるユーザの要求を待つ。もしユーザが別の動作を要求したならば、処理は９２４へと進む。

要素９２４、９２６は、絶対時間（実時間）からバッチ相対時間（バッチ処理の開始に対する相対的な時間）へＧａｎｎｔｔチャート時間線を変更するユーザ要求に応答する。上で述べたように、このような時間線の変更は、バッチ比較表示と関連して、Ｇａｎｎｔｔチャートが目で見て比較されている多数のバッチの特定の部分を整列させるのに有用である。このような整列により、様々なバッチに関する品質問題を説明する決定的に重要な差異を強調できる。処理は次いで要素９０８に戻ることで続行され、さらなるユーザの要求を待つ。もしユーザが別の動作を要求したならば、処理は９２８へと進む。

要素９２８−９３４は、ユーザ要求に応答して、表示を、選択された事象と関連する連続データのプロットに切り換える。要素９３０、９３２は、ユーザにより選択され、選択されたバッチ事象に対応する一組の要求された連続データポイント値を表示する。要素９３４がユーザがバッチ事象詳細表示に戻りたいと判断するまで、ユーザは多くのこのようなデータポイントを要求し、選択を修正してもよい。このようなとき、処理は次いで要素９０８に戻ることで続行され、さらなるユーザの要求を待つ。

上で述べたように、当業者は、図９の方法がバッチ事象情報とエグゼクティブによりこのようなデータ内で得られた関係とをユーザが対話的に表示する技術の一例であると認識するだろう。表示された様々なデータの間の関係の階層的性質を反映するＧａｎｎｔｔチャート内のこのようなデータの表示は、本発明のビュークライアントにとって重要である。さらに、バッチプロシージャ実行の階層的プロシージャ要素の選択によって様々な表示を経て進むことが、本発明のさらなる重要なアスペクトである。熟練のソフトウェア技術者は、本発明のビュークライアントのこれらおよび他の重要なアスペクトを当てる多様な均等の実現化例を認識するだろう。

本発明は具体的な例を参照して説明されたが、これはあくまで例示であり、本発明の限定を意図するものではないが、本発明の精神および範囲から逸脱することなく、変更、付加、または消去が開示された実施の形態に行なわれてよいことは明らかである。

２００ 事象ヒストリアン
２０２ 履歴エグゼクティブ要素
２０４ 記憶要素
２０６ 事象情報検索要素
１００ 連続データ収集要素
２２４ ビュークライアント
２１６ バッチ事象ジェネレータ
２１８ プロセス事象ジェネレータ

Claims (16)

1. バッチ処理のための事象ヒストリアンシステムであって、ユーザインターフェースシステムと、履歴エグゼクティブ要素と、記憶要素と、事象情報検索要素と、を含み、
   前記履歴エグゼクティブ要素は、
   プロセスの物理的要素において動作する１以上の入力ソースから、プロセス事象情報を受け取り、
   前記物理的要素とは別個に設けられてバッチ処理を実行するバッチサーバプロセスによって生成され、プロシージャ要素に関する情報を含んだバッチプロシージャ事象情報を受け取り、
   特定の前記プロセス事象情報を特定の前記プロシージャ要素と関連付けるように生成された事象メッセージに基づいて、前記プロセス事象情報の一部分と前記バッチプロシージャ事象情報の一部分との間の時間的な対応関係を自動的に導出し、前記プロセス事象情報及び前記バッチプロシージャ事象情報の間から導出される前記時間的な対応関係から前記バッチプロシージャ事象情報の時間線とバッチプロセスプロシージャ階層とを再構成し、
   前記記憶要素は、
   前記履歴エグゼクティブ要素に結合され、
   前記履歴エグゼクティブ要素からの要求に応答して前記プロセス事象情報及び前記バッチプロシージャ事象情報と、前記履歴エグゼクティブ要素により導出された前記対応関係とを持続的に記憶し、
   前記事象情報検索要素は、
   アプリケーションプロセスからの要求に応答して、前記履歴エグゼクティブ要素により導出された前記対応関係にしたがって、前記プロセス事象情報及び前記バッチプロシージャ事象情報を検索する、
   ことを特徴とする事象ヒストリアンシステム。
2. 実時間で連続データを受け取り記憶するための連続データ収集要素をさらに含み、前記連続データは、バッチ処理アプリケーションによって長期にわたり検出又は制御されるデータ値の連続ストリームからなり、各データ値は、バッチ処理の少なくともひとつの前記プロシージャ要素と時間で関連するものであり、前記バッチ処理の前記プロシージャ要素には、プロシージャ、ユニットプロシージャ、オペレーション及びフェーズのうちの少なくとも１つが含まれる請求項１に記載の事象ヒストリアンシステム。
3. 前記事象情報検索要素はさらに、ユーザに、前記バッチプロシージャ事象情報、および前記履歴エグゼクティブ要素により導出された前記対応関係と、前記連続データとを図表で提示するバッチヒストリアンビュークライアントアプリケーションを含む請求項２に記載の事象ヒストリアンシステム。
4. 前記事象情報検索要素はさらに、ユーザに、前記バッチプロシージャ事象情報、および前記履歴エグゼクティブ要素により導出された前記対応関係を図表で提示するバッチヒストリアンビュークライアントアプリケーションを含む請求項１に記載の事象ヒストリアンシステム。
5. 前記履歴エグゼクティブ要素に第１の前記入力ソースとして結合される前記バッチサーバプロセスと、
   前記履歴エグゼクティブ要素に第２の前記入力ソースとして結合される処理機器とを含み、
   前記バッチサーバプロセスは、前記プロシージャ要素が特定のバッチのために実行されるときにメッセージを生成し、
   前記処理機器は、前記バッチ処理の制御に用いられ、当該機器内で行われる前記プロシージャ要素を示す事象を生成し、
   前記処理機器により生成された事象がプロセス事象ログに記憶される請求項１に記載の事象ヒストリアンシステムシステム。
6. 実時間で連続データを受け取り記憶するための連続データ収集要素をさらに含み、前記連続データは、バッチ処理アプリケーションによって長期にわたって検出又は制御されるデータ値の連続ストリームからなり、前記データ値はバッチ処理の少なくともひとつのプロシージャ要素と時間で関連しており、前記プロシージャ要素には、プロシージャ、ユニットプロシージャ、オペレーション及びフェーズのうちの少なくとも１つが含まれる請求項５に記載の事象ヒストリアンシステム。
7. 前記履歴エグゼクティブ要素は、前記バッチ事象および前記プロセス事象と、前記連続データとの間の前記時間的な前記対応関係を決定するための要素を含む請求項６に記載の事象ヒストリアンシステム。
8. 請求項１乃至７のいずれか１項に記載のバッチ処理のための事象ヒストリアンシステムにおいて適用するためのバッチ履歴ビュークライアントアプリケーションであって、
   識別されたバッチに対応する事象情報を検索する手段と、
   前記事象情報と前記事象情報の各部分間の関係とをユーザに視覚的に提示する手段とを含むバッチ履歴ビュークライアントアプリケーション。
9. 前記視覚的に提示する手段はさらに、
   前記事象情報および前記関係をガントチャートとして提示するための手段を含み、前記ガントチャートは、バッチプロシージャのプロシージャ要素を表す請求項８に記載のバッチ履歴ビュークライアントアプリケーション。
10. 前記事象情報および前記関係をガントチャートとして提示するための手段はさらに、前記ガントチャートを絶対時間スケールで提示する手段を含む請求項９に記載のバッチ履歴ビュークライアントアプリケーション。
11. 前記事象情報および前記関係をガントチャートとして提示するための手段はさらに、前記ガントチャートをバッチ相対時間スケールで提示する手段を含む請求項９に記載のバッチ履歴ビュークライアントアプリケーション。
12. 第２の識別されたバッチに対応する他の事象情報を検索する手段と、ユーザに、前記他の事象情報と前記他の事象情報の部分間の関係とを提示する手段とを含み、前記他の事象情報を提示する手段は、前記事象情報と前記他の事象情報との間の差を示す手段を含む請求項８に記載のバッチ履歴ビュークライアントアプリケーション。
13. 前記視覚的に提示する手段は、前記事象情報が生成されるときに、前記事象情報および前記関係を提示する手段を含む請求項８に記載のバッチ履歴ビュークライアントアプリケーション。
14. 前記事象情報を実時間で提示する手段は、ユーザ表示画面を横切って水平方向に前記事象情報をスクロールする手段を含む請求項１３に記載のバッチ履歴ビュークライアントアプリケーション。
15. 実時間で連続データを集めるための連続データ収集手段をさらに含み、前記連続データは、バッチ処理の少なくともひとつのデータポイントに関連し、
    前記事象情報を実時間で提示する手段は、前記連続データが集められるときに実時間で前記連続データを提示する手段を含む請求項１３に記載のバッチ履歴ビュークライアントアプリケーション。
16. 前記連続データを実時間で提示する手段は、ユーザ表示画面を横切って水平方向に前記連続データをスクロールする手段を含む請求項１５に記載のバッチ履歴ビュークライアントアプリケーション。

Images