JP2008135042A - 階層アーキテクチャを有する監視プロセス制御／製造情報システム・アプリケーション - Google Patents

Abstract

【課題】監視プロセス制御／製造情報システム・アプリケーションにおいて、中断や停止時間を最短に抑えながら変更を可能にすること。
【解決手段】アプリケーション構成要素（ＡＣと略す）は、多重レイヤ階層方式で、ネットワーク接続の複数のコンピュータ装置に分散でき、下位レイヤＡＣが、上位レイヤＡＣをホストする。アプリケーション・オブジェクト（ＡＯと略す）は、本アーキテクチャの上位レベルに位置し、プロセス制御システム内エンティティをモデル化したものである。エンジン・オブジェクト（ＥＯと略す）は、ランタイム環境でＡＯの実行をホストし、ＡＯは、関連するホストＥＯの展開後に展開できる。プラットフォーム・オブジェクト（ＰＯと略す）はＥＯをホストする。ＰＯは、ＥＯと関連ＡＯを実行する物理コンピュータ・システム構成要素に対応する。構成ファシリティは、分散アプリケーションの各オブジェクト関係を示すビューを提示する。
【選択図】図１

Description

本発明は一般に、コンピュータ化されたプロセス制御ネットワークの分野に関する。より詳細には、本発明は、監視プロセス制御／製造情報システム（supervisory process control and manufacturing information system）に関する。そうしたシステムは一般に、プロセス制御ネットワーク内の制御レイヤ上で実行されて、たとえばプログラマブル・ロジック・コントローラ（ＰＬＣ）など下位レベルの制御要素についての情報（guidance）を提供する。

工業用プロセス制御技術における著しい進歩は、工場およびプラント操業のすべての面を大幅に改良した。今日の現代的な工業用プロセス制御システムが導入される以前は、工業プロセスは、人間および簡単な機械制御によって、操作／制御されていた。その結果、プロセス制御の複雑さおよび程度には、１人または複数の人間が、さまざまなプロセス状態変数のステータスを確認し、現在のステータスを所望の操業レベルと比較し、（必要ならば）修正動作を計算し、状態変数が変化するように制御点を変更するのに要するスピードからくる限界があった。

プロセス制御技術の改良は、より大規模で、より複雑な工業プロセスを、プログラムされた制御プロセッサで制御することを可能にした。制御プロセッサは、複数のプロセス状態変数を読み取る制御プログラムを実行し、その状態変数データと所望の設定値情報とに基づく制御アルゴリズムを実行して、工業プロセス中の複数の制御点についての出力値を返す。こうした制御プロセッサおよびプログラムは、（一度、設定値が設定されると）実質的に、自動運転の工業プロセス（self-running industrial process）をサポートする。

工業プロセスが、プログラムされたプロセス・コントローラの制御下で、人間の介入を必要とせず、先に設定された設定値で動作できるとしても、制御プロセッサおよびその関連プロセスを監視制御し、モニタリングすることが望ましい。こうした監視（oversight）は、人間と、マルチ・レベル・プロセス制御ネットワークのアプリケーション／ヒューマン・インターフェース・レイヤに存在するより上位レベルの制御プログラムとの両方によって提供される。こうした監視には、一般に、下位レベルのプロセス・コントローラの下で制御されるプロセスが適切に実行されているか検証すること、制御されるプロセスの設定値を設定すること、が求められる。

製造／プロセス制御システムは、プロセス制御装置およびプロセス自体に変化が生じると、修正される。したがって、そうした場合に、システムの変化していない部分に影響を及ぼすことなく、速やかに構成／再構成を行う手段を提供することが重要になる。また、工業プロセスの動作の中断を最小限に抑えながら、たとえば、プロセスが停止する時間を最短に抑えながら、そうした変更を行う手段を提供することも重要になる。

監視プロセス制御／製造情報システムを改良し続けることによる利益とその望ましさを考えれば、監視プロセス制御／製造情報システムがある１つのアーキテクチャに固定されないようにすることが強く望まれる。プロセス制御システムは変化し、そうした変化に対して、その変化の規模にかかわらず、適合できる上位レベルのシステムを有していることが望ましい。さらに、柔軟性の低い監視プロセス制御／製造情報システムを提供するということは、一度インストールされるとそのアプリケーションに対する変更が相対的にフレキシビリティを欠くので、プロセス制御のインストール設計者は、アプリケーションの長期的に要求される事柄も考慮しなければならなくなる。

しかし、そうしたアプリケーションのフレキシビリティの欠如は、保守的な（conservative）工業用制御システムの市場では望ましくない。プロセス制御産業では、よく試験的に運用することに気を配り、しばしば、設計者は、最終的インストールに組み込まれる自動制御の全体的な範囲および形態を十分に認識していないことが多い。プラントの寿命の後期になって、新機能が付け加えられると、その新しい制御システム・コンポーネントは、既存システムを活用し、または既存システムを併合する。プロセス制御システムが大幅に変更されるような場合は、インストールされている監視プロセス制御アプリケーションに異なるアーキテクチャを組み入れたほうが有利である。

本発明の一態様によれば、監視プロセス制御／製造情報システム・アプリケーションは、下位レイヤのアプリケーション・コンポーネントは、より上位にインストールされたレイヤのアプリケーション・コンポーネントをホストする多重レイヤ階層方式（multi-layered hierarchical manner）で、ネットワーク接続された複数のコンピュータ装置に分散することができる。アプリケーション・オブジェクトは、分散アプリケーション・アーキテクチャの比較的上位レベルに常駐し、プロセス制御システム内のエンティティをモデル化したものである。エンジン・オブジェクトは、ランタイム環境で、アプリケーション・オブジェクトの実行をホストする。したがって、アプリケーション・オブジェクトが関連付けられているホスト・エンジン・オブジェクトを展開（deploy）しないうちに、アプリケーション・オブジェクトを展開することはできない。エンジン・オブジェクトは、プラットフォーム・オブジェクトにホストされる。プラットフォーム・オブジェクトは、エンジン・オブジェクトと関連アプリケーション・オブジェクトを実行するための、物理コンピュータ・システム・コンポーネントに対応する。

本発明の別の態様によれば、構成ファシリティ（configuration facility）は、監視プロセス制御／製造情報アプリケーションに関する展開モデル（deployment model）を指定する。展開モデルは、アプリケーション・オブジェクトを特定の物理コンピューティング装置に関連付け、物理コンピューティング装置上に分散するオブジェクトのビューを提供する。具体的には、構成ファシリティは、アプリケーション内でエンジンをホストするのに利用可能な１つまたは複数の物理コンピューティング装置タイプを指定する１組のプラットフォーム定義を含む。１組のエンジン定義は、物理コンピューティング・システム上で実行するエンジンを指定し、したがって物理コンピューティング装置によってサポートされるサービス・タイプを定める。１組のエリア定義は、アプリケーション・オブジェクトの論理的なグループ分けを指定する。さらに、１組の階層関係（hierarchical relationship）は、物理コンピューティング・システムのうちの特定システムへのエンジンの割り当て、およびエンジンのうちの特定エンジンへのエリアの割り当てを指定する。展開ビュー・ジェネレータ（deployment view generator）は、１組の階層関係に従って、物理コンピューティング装置、エンジン、およびエリアから成る階層ビューを生成する。

本発明のさらに別の態様によれば、監視プロセス制御／製造情報システム・アプリケーション構成ファシリティ（supervisory process control and manufacturing information system application configuration facility）は、多様な複数のビューを含む。この複数のビューは、プロセス制御／製造情報ソフトウェアの構成および展開を容易にする。構成ファシリティは、プラント内の複数のエンティティである装置および機能に対応する１組の監視プロセス制御システム・オブジェクトを含む。装置および機能（function）に関連付けられた個別機能（functionality）は、各オブジェクトに含まれる。さらに、監視プロセス制御システム・オブジェクトは、複数の監視プロセス制御システム・オブジェクト間の関係を指定する１組のアトリビュートで、自らを関連付けられた１組のアトリビュートを有する。

構成ファシリティは、監視プロセス制御システム・オブジェクト間の結合関係に従って、監視プロセス制御システム・オブジェクトを描くためのビュー・ジェネレータも含む。１組のビューは少なくとも、プロセス／プラントとモニタされるそのコンポーネントの論理構成を表す第１のビューと、アプリケーションを実施するオブジェクトのコンピュータ・システム上の物理展開を表す第２のビューを含む。

特許請求の範囲に、本発明の特徴を詳細に記述する。本発明、ならびにその目的および利点は、以下の詳細な説明を添付の図面と併せ読むことにより、最もよく理解することができるであろう。

変更されるプロセス制御システム・アーキテクチャに適合するということに関しての周知の監視プロセス制御アプリケーションの短所を考慮して、基盤をなす既存のプロセス制御システム技術に与える影響をできるだけ小さく抑えつつ、監視プロセス制御／製造情報システム・アプリケーションのようなアプリケーションを再構築（re-architect）（たとえば、拡張（augment）や再構成（reconfigure）など）する際にユーザに自由度を提供する監視プロセス制御／製造情報システム・アプリケーションが記載されている。具体的には、本明細書で例として説明する開示のシステム・アーキテクチャは、下位の各レイヤが、すぐ上のレイヤをホストするという関係を提示する複数のレイヤを備える。しかし、こうしたホスト関係は、通信の面まで及ばないこと、したがって、ホストされるレイヤへの／からの通信は、そのホストを通過する必要がないこと、に留意されたい。開示の階層アプリケーション・アーキテクチャによれば、アプリケーション・オブジェクトは、エンジンによってホストされる。このエンジンは、たとえば、基盤ソフトウェアを備えたパーソナル・コンピュータに対応するプラットフォームによってホストされる。中間のエンジン・レイヤは、プラットフォーム・アーキテクチャからアプリケーション・オブジェクトを抽象化する。したがって、アプリケーション・オブジェクトを含む物理システム内のロケーションを、アプリケーション・オブジェクトがアドレス指定する必要はない。

開示の監視プロセス制御／製造情報アプリケーションの一態様は、そのアプリケーション・オブジェクトが常駐するコンピューティング・システムのハードウェアに関連付けられる設計上の制約から、上位レベルのアプリケーション・オブジェクトを解放するオブジェクト階層である。具体的には、監視プロセス制御アプリケーション環境に関連付けられるオブジェクトは、物理コンピューティング装置上に、複数のレイヤを備える階層の形で配置される。アプリケーション・オブジェクトは、アプリケーション・レイヤで実行される。アプリケーション・オブジェクトは、中間レイヤのエンジン・オブジェクトによってホストされる。エンジン・オブジェクトは、３レイヤの最下位レイヤに位置するプラットフォーム・オブジェクトによってホストされる。各プラットフォーム・オブジェクトは、さらに下位のレイヤのブートストラップ・オブジェクトによって起動される。プラットフォーム・オブジェクトは、アプリケーション・オブジェクトおよびエンジン・オブジェクトがその上で実行される物理コンピューティング・システム（オペレーティング・システムを含む）に対応する。したがって、アプリケーション・オブジェクトは、ホスト・アプリケーション・エンジン・オブジェクトとの適切な標準化された関係を定めさえすればよい。監視制御／製造情報システムの物理コンピューティング装置およびそのオペレーティング・システムに関する側面は、エンジン／プラットフォーム・オブジェクト構成（engine and platform object configuration）が取り扱う。システムの物理トポロジおよびアプリケーションの物理ロケーションは、アプリケーション・オブジェクトの動作からは透過的である。

開示のオブジェクトの階層ホスティング構成（layered hosting arrangement）は、監視プロセス制御アプリケーションを、そのアプリケーションがその上で実行するコンピューティング・ハードウェアおよび監視制御ネットワーク・トポロジから独立にモデル化することを可能にする。アプリケーション・モデルを物理展開構成から分離することは、必要が生じた際にアプリケーションを新しい／異なるコンピューティング・システムに移動させ、そのアプリケーションの耐用期間（course of the life）にわたって基盤ハードウェアの変化に対応していくことができる。このような能力は、試験的なインストールがコンセプトの妥当性を明らかにするために使用され、それにつれてアプリケーションが成長し、いつか、アプリケーションが正しいとされる、という手法をとる、プロセス制御／製造情報システムの分野では特に有益である。

アプリケーション・モデルは、「エリア」と呼ばれる論理コンテナ内への複数のアプリケーション・オブジェクトのグループ分けを含む。同一エリア内のすべてのアプリケーション・オブジェクトは、ソフトウェア展開方式（software deployment scheme）に従って、同一のアプリケーション・エンジン上に展開しなければならない。しかし、階層アプリケーション・アーキテクチャでは、開発の後期ステージに、アプリケーション・モデルを特定の展開モデルに結びつけることが可能である。したがって、開発者が監視レベルのシステムを展開し実行する準備を整えるまで、抽象的な「エリア」を特定のエンジンに関連付ける必要はない。

監視制御／製造情報システムのセキュリティ・モデルは、物理的ハードウェアから独立しており、したがって、監視制御／製造情報システムの構築者は、物理システム・コンポーネントを収容する物理システム内にアプリケーション・モジュールを展開するまで、セキュリティを特定の物理システム・コンポーネントに結びつける必要がない。セキュリティをシステムの特定の物理コンポーネントに後から結びつけることは、開発者が、展開されたアプリケーション・オブジェクトに基づいて、個々のシステムへの権限付与を決めることができ、特定の個々のコンピューティング・ノードに展開されたアプリケーション・オブジェクトの機能性に基づいて、開発者がセキュリティを設定する、ことを可能にする。

さらに、アプリケーション・オブジェクトによって提供される機能（ビジネス・ロジック）を、その上でアプリケーション・オブジェクトが実行するコンピュータ・システムから分離するは、複数のビュー／モデルに従って定義されたシステム／ソフトウェア構成を提示することを可能とする。「プラントを中心にした（plant centric）」アプリケーション・モデルは、システム開発者が、論理的方法でアプリケーション・モデルを構築することを可能にする。システム開発者は、個々の装置および機能を、プラント内の別個のエンティティとして定義する。関連する機能はすべて、各々のオブジェクトに含まれる。ユーザは、プラント内の個々のオブジェクトを定義した後、オブジェクト間の関係を設定（configure）（アッセンブル）する。

アプリケーション・モデルは、プラントの物理エリア、および物理エリア内の設備と機能に関する、プラントの論理構造である。技術者は、これらプラント・エリアのエンティティの挙動および結合関係を設定する。監視プロセス制御／製造情報システムは、エリアと設備、および設備自体についての包含階層（containment hierarchy）を示すアプリケーション・モデルの構成ビュー（configuration view）を提供する。

アプリケーション・モデルは、オブジェクト内にオブジェクトを包含することをサポートし、包含関係をテンプレートで指定することができる。包含関係は、監視プロセス制御／製造情報アプリケーション開発について異なる技術者による異なるレベルでの作業を活用することを容易にする。ある技術者が、ある特定の下位レベルの装置についての詳細を定義した後で、別の技術者が、その特定の下位レベルの装置の１つまたは複数のインスタンスを含む、アプリケーション内の、ユニットまたは他の装置を定義することができる。

アプリケーション・モデルは、継承による変更の伝播をサポートする。つまり、子オブジェクトは、参照される親テンプレートの定義の変更を継承する。

開発者がプロセス制御／製造情報アプリケーションの機能性を指定した後、アプリケーションは、潜在的に多数の物理コンピューティング・システムに展開される。本明細書で開示する本発明の一実施形態では、展開モデルと呼ばれる第２のタイプのシステム・ビューは、ユーザが、アプリケーションに関連する物理的ＰＣおよび装置を構成することを可能にする。この展開モデルは、複数のＰＣ、およびそのプラットフォーム上で動作する複数のエンジン・タイプを定義し、また外部装置の統合（external device integration）を定義する。ユーザは、特定のエンジン上で動作することになるエリアを定義し、それによって、特定のアプリケーションを物理的にどこで実行するかを決定する。監視プロセス制御／製造情報システムは、物理的ＰＣとその物理的ＰＣ上で動作するエリアおよびアプリケーション・オブジェクトに関して階層を示す展開モデルの構成ビューを提供する。開発者が展開モデルを指定／確認した後、アプリケーション・オブジェクトとエンジン・オブジェクトは、その展開モデルに従って、物理的コンピューティング装置上に展開される。

システムの再構成（再構築）することを容易にする監視プロセス制御／製造情報システムの新しいアーキテクチャについての概要を述べてきたが、次に、本発明を実施したアプリケーション・アーキテクチャを組み込んだシステムの説明用の例を備える、図１を参照する。第１のアプリケーション・サーバ用パーソナル・コンピュータ（ＰＣ）１００と第２のアプリケーション・サーバ用ＰＣ１０２は、共同し連携しながら、第１の部分１０４と第２の部分１０６を含む分散多重レイヤ監視プロセス制御／製造情報アプリケーションを実行する。アプリケーション部分１０４、１０６は、装置統合アプリケーション・オブジェクト（device integration application object）ＰＬＣ１ＮｅｔｗｏｒｋとＰＬＣ１、およびＰＬＣ２ＮｅｔｗｏｒｋとＰＬＣ２をそれぞれ含む。ＰＬＣｘＮｅｔｗｏｒｋ装置統合オブジェクトは、データ・アクセス・サーバ（たとえば、ＯＰＣ ＤＡＳｅｒｖｅｒ１１６、１１８）（ＯＰＣ；OLE for Process Control、ＯＬＥ；Object Linking and Embedding）の構成を容易にする。ＯＰＣクライアントとして動作するＰＬＣ１およびＰＬＣ２装置統合オブジェクトは、ＯＰＣ ＤＡＳｅｒｖｅｒ１１６、１１８のバッファ内のデータ・ロケーションにアクセスする。データ・アクセス・サーバ１１６、１１８、および装置統合オブジェクトは連携して、ＰＬＣまたはその他のフィールド装置（field device）などの外部のプロセス制御コンポーネントからデータをインポートしバッファリングする。データ・バッファには、パーソナル・コンピュータ１００、１０２上で実行されるさまざまなアプリケーション・オブジェクト１０５、１０７がアクセスする。アプリケーション・オブジェクトの例としては、たとえば、ディスクリート装置（discrete device）、アナログ装置、フィールド参照（field references）などが挙げられる。

本発明の一実施形態によれば、アプリケーション・エンジンは、（本明細書で「エリア」と呼ぶ論理グループ化オブジェクトを介して）アプリケーション・オブジェクトをホストする。このエンジンは、監視プロセス制御／製造情報アプリケーション内ですぐ下のレベルに位置するプラットフォーム・オブジェクトによって、同様にホストされる。アプリケーション部分１０４、１０６は、汎用的なブートストラップ・コンポーネント１０８、１１０によって、同様にホストされる。上記のすべてのコンポーネントを、以下本明細書で、図２を参照しながら説明する。

本発明を実施した例示的なシステムでは、部分１０４、１０６を含む多重レイヤ・アプリケーションは、制御されるプロセスと通信可能に接続される。具体的には、第１のアプリケーション・サーバ用パーソナル・コンピュータ１００は、第１のプログラマブル・ロジック・コントローラ１１２に通信可能に結合され、第２のアプリケーション・サーバ用パーソナル・コンピュータ１０２は、第２のプログラマブル・ロジック・コントローラ１１４に通信可能に結合される。ＰＣ１００、１０２からＰＬＣ１１２、１１４への図示のコネクションは、論理コネクションであることに留意されたい。そのような論理コネクションは、直接的および間接的な物理通信リンクに相当する。たとえば、ある具体的な実施形態では、ＰＬＣ１１２、１１４は、パーソナル・コンピュータ１００、１０４も接続されたイーサネット（登録商標）ＬＡＮ上のノードを含む。別の実施形態では、ＰＬＣ１１２、１１４は、ＰＣ１００、１０２の物理的通信ポートに直接接続される。

図１に示す例示的な実施形態では、ＰＣ１００、１０２はそれぞれ、データ・アクセス・サーバ１１６、１１８を実行する。データ・アクセス・サーバ１１６、１１８は、ＰＬＣ１１２、１１４から与えられたプロセス情報を取得／抽出し、部分１０４、１０６を含むアプリケーションのアプリケーション・オブジェクト（たとえば、ＰＬＣ１Ｎｅｔｗｏｒｋ、ＰＬＣ１、ＰＬＣ２Ｎｅｔｗｏｒｋ、ＰＬＣ２）にそのプロセス情報を提供する。データ・アクセス・サーバ１１６、１１８は、たとえば、ＯＰＣ（OLE for Process Control）サーバである。しかし、データ・アクセス・サーバ１１６、１１８が、カスタマイズされた、また標準化された多種多様なデータ・フォーマット／プロトコルを潜在的に実行できることは、当業者には容易に理解されよう。さらに、例示的なアプリケーション・オブジェクトは、データ・アクセス・サーバ１１６、１１８へのコネクションを介して、ＰＬＣネットワーク、およびＰＬＣ自体の動作を表す。しかし、このアプリケーション・オブジェクトは、監視プロセス制御／製造情報アプリケーションのコンテクストで所望の監視制御機能およびデータ獲得／統合機能を実行する実行可能オブジェクトについての、仮想的に際限の無い広範囲のクラスを含む。

監視プロセス制御／管理情報アプリケーションは、たとえば、データベースアプリケーション・オブジェクト、およびアプリケーション・オブジェクトを生成するテンプレートを始めとするその他の関連情報に対して、監視プロセス制御／管理情報アプリケーションの構成データベース１２４を維持管理するデータベース（たとえば、ＳＱＬ）・サーバ１２２を実行する構成パーソナル・コンピュータ１２０によって、増強される。構成データベース１２４はまた、ロケーションとは独立のオブジェクト名をロケーションから導出した、図１に示すシステム内のオブジェクト間でメッセージを容易に転送できるようにする、ハンドルに結びつけることを容易にするグローバル名前テーブル（global name table）１２５も含む。構成ＰＣ１２０および関連するデータベース・サーバ１２２は、マルチユーザ環境の管理上のモニタリング（administrative monitoring）、改定履歴管理、集中的ライセンス管理、新しいオブジェクトおよび関連ソフトウェアの展開およびインストールを含む集中的オブジェクト展開（centralized object deployment）、グローバル名前テーブル１２５のメンテナンス、およびオブジェクト・テンプレートおよびインスタンスのインポート／エキスポート、をサポートする。

アプリケーションの実際の構成は、分散コンポーネント・オブジェクト・モデル（ＤＣＯＭ；distributed component object model）プロトコルを介してデータベース・サーバ１２２と通信する、統合開発環境（ＩＤＥ；Integrated Development Environment）１２７によって実施される。ＩＤＥは、アプリケーション・オブジェクトを構成し、アプリケーション・サーバＰＣ１００、１０２に展開するためのユーティリティである。監視プロセス制御／製造情報アプリケーションの開発者は、ＩＤＥを介して、新しいオブジェクトおよびテンプレート・タイプのインポートすること、既存テンプレートからの新テンプレートを構成すること、新しいアプリケーション・オブジェクトを定義すること、およびアプリケーション・サーバＰＣ１００、１０２上のホスト・アプリケーション・エンジン（図１のＡｐｐＥｎｇｉｎｅ１およびＡｐｐＥｎｇｉｎｅ２）へのアプリケーション・オブジェクトの展開、を含む多種多様なシステム設計機能を実施する。

図１に示す例示的な監視制御ネットワーク環境は、１組の操作者ステーション１３０、１３２、１３４も含み、これらの操作者ステーションは、ＰＣ１００、１０２上の１組の階層オブジェクトとしてインストールされて実行される監視プロセス制御／管理情報アプリケーションによってモニタされ／制御されるプロセスまたはプロセスの一部へのビューを提供する。原料（RawMaterial）ＰＣ１３０は、監視される工業プロセスの原料エリアをモニタできるようにする担当者ビュー（representative view）を提供する。生産（Production）ＰＣ１３２は、監視される工業プロセスの生産部分についての担当者ビューを提示する。完成品（Finished Product）ＰＣ１３４は、完成品に関連付けられる生産ファシリティ・エリアについての担当者ビューを提供する。操作者ステーション１３０、１３２、１３４の各々は、個々の操作者ステーション・プラットフォームに対してホストするブートストラップを含む。操作者ステーション１３０、１３２、１３４の各々は、グラフィック情報を処理して、監視される工業プロセスまたはその一部についてグラフィカルに描き出すビュー・エンジンを含む。

図１に示し、本明細書で、ここまで説明したシステムは、監視プロセス制御／製造情報システム用の多重レイヤ階層アーキテクチャの一例にすぎないことに留意されたい。本発明は、開示された特定のアプリケーション／システムに限定されるものではない。たとえば、多重レイヤ・アプリケーション手法は、より下位のレイヤで、分散制御システム（ＤＣＳ；distributed control system）またはプログラマブル・ロジック・コントローラ（ＰＬＣ）アプリケーションにも適用可能であることが企図されている。これらの場合、ＤＣＳまたはＰＬＣ内の独自のコンピューティング・ハードウェアに対して、それぞれ固有のプラットフォームおよびアプリケーション・エンジンのそれぞれのオブジェクトが開発される。さらに、図１は、インストールされたソフトウェアと物理コンピューティング・ハードウェアとの相互関係の論理ビューとして提示されており、何らかの特定のネットワーク・トポロジを指定するものではないことにも留意されたい。寧ろ、本発明は、仮想的な任意のネットワーク・トポロジにふさわしい。実際、本発明は、制御対象プロセスに接続された単一コンピュータ・システム上で動作する制御アプリケーションにも適用可能である。

次に図２に移ると、少なくとも監視プロセス制御／製造情報アプリケーションの一部を実行するコンピュータに関連付けられた階層ソフトウェアの階層的構成を示すクラス図が示されている。各コンピュータは、階層の最下位レベルで、マイクロソフトのＷＩＮＤＯＷＳ（登録商標）などのオペレーティング・システム２００を実行する。オペレーティング・システム２００は、ブートストラップ・オブジェクト２０２をホストする。ブートストラップ・オブジェクト２０２は、コンピュータにロードされ、オペレーティング・システム２００によって実行される起動プロシージャに関連して活動化される。ブートストラップ・オブジェクト２０２は、プラットフォーム・クラス・オブジェクト２０４のホストとして、プラットフォーム・クラス・オブジェクト２０４の動作を開始する前に活動化しなければならない。ブートストラップ・オブジェクト２０２は、プラットフォーム・クラス・オブジェクトを開始させ、また停止させる。ブートストラップ・オブジェクト２０２はまた、プラットフォーム・クラス・オブジェクト２０４がホストする１つまたは複数のエンジン・オブジェクト２０６を開始させ、また停止させるために、プラットフォーム・クラス・オブジェクト２０４が利用するサービスを提供する。

プラットフォーム・クラス・オブジェクト２０４は、１つまたは複数のエンジン・オブジェクト２０６のホストとなる。本発明の一実施形態では、プラットフォーム・クラス・オブジェクト２０４は、１つまたは複数のエンジン・オブジェクト２０６に対して、特定のオペレーティング・システムを実行するコンピュータとなる。プラットフォーム・クラス・オブジェクト２０４は、プラットフォーム・クラス・オブジェクト２０４上に展開されるエンジン・オブジェクト２０６のリストを維持管理し、エンジン・オブジェクト２０６を開始させ、また停止させ、エンジン・オブジェクト２０６がクラッシュした場合、これを再開する。プラットフォーム・クラス・オブジェクト２０４は、エンジン・オブジェクト２０６の動作状態をモニタし、クライアントに状態情報を公開する。プラットフォーム・クラス・オブジェクト２０４は、プラットフォーム・クラス・オブジェクト２０４を実行するコンピュータ・システム上で、診断および管理タスクの実行を可能とするシステム管理コンソール診断ユーティリティ（system management console diagnostic utility）を含む。プラットフォーム・クラス・オブジェクト２０４はまた、分散警報サブシステム（distributed alarm subsystem）へ警報を提供する。

エンジン・オブジェクト２０６は、アプリケーションに関連付けられた監視プロセス制御および／または製造情報獲得機能（supervisory process control and/or manufacturing information acquisition function）を実施する１組のアプリケーション・オブジェクトをホストする。エンジン・オブジェクト２０６は、すべてのアプリケーション・オブジェクト２１０のスタートアップを開始する。エンジン・オブジェクト２０６はまた、スケジューラ・オブジェクトの助けを得て、アプリケーション・オブジェクト２１０同士の間でその実行をスケジュールする。エンジンは、アプリケーション・オブジェクトを実行のためスケジューラに登録する。スケジューラは、エンジンによって指定された構成に基づく他のアプリケーション・オブジェクトとの相対関係に従って、アプリケーション・オブジェクトを実行する。エンジン・オブジェクト２０６は、アプリケーション・オブジェクト２１０の動作をモニタし、機能不良なものを隔離状態におく。エンジン・オブジェクト２０６は、オートメーション・オブジェクト（automation objects）によるランタイム・アプリケーションの変更を構成ファイルにセーブ／リストアすることによって、チェック・ポイント機能をサポートする。エンジン・オブジェクト２０６は、アトリビュート参照（たとえば、ｔａｎｋ１．ｖａｌｖｅ．ｐｖ）をアプリケーション・オブジェクト２１０のうちの適切なものに参照を付ける名前バインディング・サービス（name binding service）を維持管理する。

エンジン・オブジェクト２０６は最終的に、アプリケーション・オブジェクトの実行をいかに起させるかを制御する。しかし、エンジン・オブジェクト２０６がアプリケーション・オブジェクト２１０に関する実行スケジュールを決定した後は、それらの実行についてのリアルタイム・スケジューリングは、スケジューラ２０８によって制御される。スケジューラは、メソッドＲｅｇｉｓｔｅｒＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔ（）およびＵｎｒｅｇｉｓｔｅｒＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔ（）を含むインターフェースをサポートする。これらのメソッドは、エンジン・オブジェクト２０６が特定のアプリケーション・オブジェクトをスケジューラのスケジュール済み動作のスケジュール・リストに追加したり、またリストから削除したりすることができるようにする。

アプリケーション・オブジェクト２１０は、特定のプロセス制御動作（たとえば、ポンプを作動させる、弁を開くなど）、および／または情報収集／管理機能（たとえば、フィールド装置の出力信号の受信値に基づいて警報を発生させるなど）を、たとえば、工業プロセス制御システムのコンテクストで実行することを容易にするビジネス・ロジックを実行する多種多様なオブジェクトを含む。アプリケーション・オブジェクトの例として、アナログ入力、ディスクリート装置、ＰＩＤループ（ＰＩＤ ｌｏｏｐ）などが挙げられる。あるクラスのアプリケーション・オブジェクト２１０は、装置統合オブジェクト（たとえば、ＯＰＣ ＤＡＳｅｒｖｅｒ１１８）を介して、ＰＬＣなどのプロセス制御システムによって供給されるデータに基づいて動作する。統合オブジェクトの機能は、プロセス制御／製造情報ソースと監視プロセス制御／製造情報アプリケーションとの間にブリッジを提供することである。

例示的な実施形態では、アプリケーション・オブジェクト２１０は、エンジン・オブジェクトおよびスケジューラによってアクセスされるアプリケーション・インターフェースを含む。エンジン・オブジェクトは、アプリケーション・オブジェクト・インターフェースにアクセスして、アプリケーション・オブジェクトを初期化したり、開始させたり、また停止させたりする。スケジューラは、アプリケーション・オブジェクト・インターフェースを使用して、アプリケーション・オブジェクトのスケジュールされた実行を開始する。

階層化構成の監視プロセス制御／製造情報アプリケーションの主要コンポーネントを説明してきたが、次に、図３から図７を参照する。これらは、上記のオブジェクト構造を構成するプリミティブのアトリビュートを識別する。最初に図３を参照すると、共通のオブジェクト・プリミティブ定義（common object primitive definition）が示されている。共通のプリミティブは、すべてのアプリケーション・オブジェクト（すなわち、プラットフォーム、アプリケーション・エンジン、スケジューラ、アプリケーションなど）に組み込まれる。Ｓｃｒｉｐｔｓアトリビュート３００は、アプリケーション・オブジェクトに関連付けられたスクリプトを把握するのに使用される。Ｓｃｒｉｐｔｓアトリビュート３００は、特定のオブジェクト・タイプ用に特に生成されたスクリプトに加えて、テンプレートから継承したスクリプトも含む。ＵＤＡ（ユーザ定義アトリビュート）アトリビュート３０２は、オブジェクト用の、継承されたユーザ定義アトリビュートと新しいユーザ定義アトリビュートを参照付けする。Ａｌａｒｍ Ｍｏｄｅアトリビュート３０４は、警報を有効にするかどうか、またどの程度まで有効にするかを指定する。Ｂａｓｅｄ Ｏｎアトリビュート３０６は、オブジェクトの派生元である特定の基底テンプレートを識別する。アトリビュート３０８は、オブジェクト内のアトリビュート名を識別する文字列を格納する。Ｃｏｎｔａｉｎｅｄ Ｎａｍｅアトリビュート３１０は、コンテナ内のオブジェクトに割り当てられた名前を識別する。たとえば、オブジェクトは、「ｒｅａｃｔｏｒ」オブジェクト内に含まれる「ｌｅｖｅｌ」に相当するものとすることができる。Ｄｅｐｌｏｙｅｄ ｖｅｒｓｉｏｎアトリビュート３１２は、展開されたオブジェクトのバージョンを識別する整数を格納する。Ｄｅｒｉｖｅｄ ｆｒｏｍアトリビュート３１４は、オブジェクトの直接の派生元であるテンプレートを識別する。Ｄｅｒｉｖｅｄ ｆｒｏｍアトリビュート３１４の内容は、Ｂａｓｅｄ Ｏｎアトリビュート３０６の内容とは異なる。Ｂａｓｅｄ Ｏｎアトリビュート３０６は、当該オブジェクトの派生元の基底テンプレートを表す。Ｄｅｒｉｖｅｄ ｆｒｏｍアトリビュート３１４は、当該オブジェクトを生成した直前のテンプレートを表す。たとえば、以下に示すテンプレート階層を考える。

$DiscreteDevice
$Pump
Pump001

ここで、＄ＤｉｓｃｒｅｔｅＤｅｖｉｃｅは、新しいテンプレート＄Ｐｕｍｐを派生させる基底テンプレートである。インスタンスＰｕｍｐ００１は、テンプレート＄Ｐｕｍｐから生成される。オブジェクトＰｕｍｐ００１のアトリビュート「Ｄｅｒｉｖｅｄ ｆｒｏｍ」は＄Ｐｕｍｐとなる。オブジェクトＰｕｍｐ００１のアトリビュート「Ｂａｓｅｄ Ｏｎ」は＄ＤｉｓｃｒｅｔｅＤｅｖｉｃｅとなる。

Ｒｅｌａｔｉｖｅ Ｅｘｅｃｕｔｉｏｎ Ｏｒｄｅｒアトリビュート３１６は、当該オブジェクトとある相対的な実行順序関係をもつ別のオブジェクトを識別する。別のオブジェクトを識別するのに加えて、アトリビュート３１６は、そのオブジェクト実行の相対的順序（たとえば、無し、前、後など）も識別する。相対的実行順序情報は、アプリケーション・オブジェクトの実行をスケジュールするのに利用される。Ｈｉｅｒａｒｃｈｉｃａｌ Ｎａｍｅアトリビュート３１８は、そのオブジェクトのすべてのコンテナを含む、そのオブジェクトのフルネーム（たとえば、Ｒｅａｃｔｏｒ１．ｌｅｖｅｌ）を格納する。ＩｓＴｅｍｐｌａｔｅアトリビュート３２０は、そのオブジェクトが、テンプレートであるか、それともテンプレートからインスタンス化されたオブジェクトであるかを示す。エリアまたはコンテナ・オブジェクト内のＡｌａｒｍＩｎｈｉｂｉｔアトリビュート３２２は、エリアまたはコンテナ内のすべてのオブジェクトについて警報を抑制するためのカットアウト機能を提供する。Ａｌａｒｍ Ｍｏｄｅアトリビュート３２４は、オブジェクトの現在の警報モードを指定する。このモードは、エリアおよびコンテナが有効とされている場合、そのオブジェクトの命令されたモード（commanded mode）に基づく。無効な場合、コンテナまたは親エリアの最も無効な状態（most disabled state）が適用される。Ａｌａｒｍ Ｍｏｄｅ Ｃｏｍｍａｎｄアトリビュート３２６は、そのオブジェクトの現在の命令された警報モードを指定する。

本発明の説明のための例では、オブジェクト階層がサポートされる。オブジェクトは、プラント／モデル・ビューのコンテクストでのそうした階層を、Ａｒｅａアトリビュート３２８中で指定し、このアトリビュート３２８は、そのオブジェクトが属するエリアを指定する。Ｃｏｎｔａｉｎｅｒアトリビュート３３０は、オブジェクトを含むコンテナを指定する。先に説明したように、ホスト関係は、さまざまな展開オブジェクト間に存在する。具体的には、プラットフォームはエンジンをホストし、エンジンは（エリアを介して）アプリケーション・オブジェクトをホストする。このように、Ｈｏｓｔアトリビュート３３８は、オブジェクトのホストを識別する。

Ｃａｔｅｇｏｒｙアトリビュート３３２は、そのオブジェクトが関連するオブジェクト・クラスを指定し、それによって、局所的な関係および／または機能によってオブジェクトを体系づけることを容易にする。その値は、Ｃａｔｅｇｏｒｙ Ｅｎｕｍアトリビュート３３４内に名前が列挙されているカテゴリのうちの値である。Ｅｒｒｏｒアトリビュート３３６は、そのオブジェクトによって生じたエラーを識別する。ＩｎＡｌａｒｍフラグ３４０は、オブジェクト内に警報が発生しているかどうかを示すブール・フラグ（Boolean flag）を格納する。このフラグは、Ｓｃａｎ Ｓｔａｔｅフラグ３４２が真（オブジェクトはスキャン対象）であり、かつオブジェクトの警報が有効な場合にのみ、真となる。オブジェクトのスキャン状態は、そのオブジェクトがスキャン対象か対象外かを通知するＳｃａｎＳｔａｔｅＣｏｍｍａｎｄ３４４によって変更される。

Ｓｅｃｕｒｉｔｙ Ｇｒｏｕｐ３４６は、オブジェクトへのアクセス／使用を特定のクラスのユーザのみに制限するために、オブジェクトに固有のセキュリティ・グループを指定することを可能にする。Ｄｅｓｃｒｉｐｔｉｏｎアトリビュート３４８は、オブジェクトの短い説明を格納する領域を提供する。ＴａｇＮａｍｅアトリビュート３５０は、オブジェクトの一意タグを指定する。Ｗａｒｎｉｎｇアトリビュート３５２には、オブジェクトが出したすべての警告が記入される。

本明細書で説明するすべてのオブジェクトに共通のアトリビュートについて説明したが、次に以下の本明細書で、各オブジェクト・タイプに固有の１組のアトリビュートについて説明する。まず、図４に示されたプラットフォーム・プリミティブのアトリビュートから始める。図４の中で識別されるアトリビュートは、オブジェクト／エンジン／プラットフォームのホスティング階層のサポートに関連する。図４には記されていないが、プラットフォーム・プリミティブによって、プラットフォーム・オブジェクトがコンピュータ装置の統計データをモニタ／報告できるようにする１組のアトリビュートが、提供される。図４には含まれないが、例示的なプラットフォーム・プリミティブには、コンピュータ装置の統計データに関連付けられた警報の検出および報告、ならびに統計データの保存に関するアトリビュートが含まれる。

ＲｅｇｉｓｔｅｒＥｎｇｉｎｅアトリビュート４００には、新しいエンジンを登録するためのコマンドが格納される。ＲｅｇｉｓｔｅｒＥｎｇｉｎｅアトリビュート４００は、展開時に、ホスト・プラットフォームにエンジンを登録するのに使用される。ＳｔａｒｔＥｎｇｉｎｅアトリビュート４０２には、プラットフォーム上に展開された特定のエンジンを開始させるためのコマンドが格納される。ＳｔａｒｔＨｏｓｔｅｄＯｂｊｅｃｔｓアトリビュート４０４には、自動スタートおよび半自動スタート・タイプのエンジンである、すべてのホストされるエンジンを開始するために、プラットフォームに渡されるコマンドが格納される。ＳｔｏｐＥｎｇｉｎｅアトリビュート４０６には、プラットフォーム上に展開された特定のエンジンを停止させるためのコマンドが格納される。ＵｎｒｅｇｉｓｔｅｒＥｎｇｉｎｅアトリビュート３０８には、プラットフォーム上に先に展開されたエンジンを展開解除するためのコマンドが格納される。Ｅｎｇｉｎｅアトリビュート４１０には、プラットフォーム上に展開されたすべてのエンジンのリストが格納される。ＥｎｇｉｎｅＳｔａｔｕｓアトリビュート４１２には、プラットフォームによってホストされるすべてのエンジン・オブジェクトの現在の動作状態のリストが格納される。

図５に、エンジン・プリミティブに関連付けられる１組のアトリビュートを要約して示す。Ｅｘｔｅｒｎａｌ Ｎａｍｅアトリビュート５００には、外部参照用に使用される文字列が格納される。Ｉｎｔｅｒｎａｌ Ｎａｍｅアトリビュート５０２には、内部参照用に使用される文字列が格納される。Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔアトリビュート５０４には、エンジン・オブジェクトを参照付けするオブジェクトの数が格納される。参照付けの数が０に達した場合、エンジンの外部に、エンジン上のＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔアトリビュートを参照するクライアントはない。これは、エンジンを停止させた場合の影響度（どれだけのクライアントが影響を受けるか）を、操作者が判断するのに役立つ。Ｏｂｊｅｃｔアトリビュート５０６は、エンジン・オブジェクトにホストされるすべてのオブジェクトの組を備えた配列（array）である。Ｓｔａｒｔｕｐ Ｔｙｐｅアトリビュート５０８は、エンジン・オブジェクトがどのようにして開始されるか（たとえば、自動、半自動、手動など）を識別する。ＣａｎＧｏＯｎｓｃａｎアトリビュート５１０は、エンジン・オブジェクトをスキャン対象にできるかどうかを示す。ＢｉｎｄＲｅｆｅｒｅｎｃｅアトリビュート５１２は、ハンドルへの参照（たとえば、ｐｕｍｐ００１．ｉｎｌｅｔ．ＰＶ）を解決するのに使用されるコマンドである。これらのハンドルは、実行中にメッセージング基盤（messaging infrastructure）によってオブジェクトを探し出すのに使用される。ＡｕｔｏＲｅｓｔａｒｔアトリビュート５１４には、障害の検出時にエンジン・オブジェクトを自動的に再開するかどうかを指示するブール値が格納される。ＣｈｅｃｋＰｏｉｎｔＦａｉｌｅｄアトリビュート５１６には、ホストされるオブジェクトに関するチェック・ポイント情報をセーブする直近の試み（last attempt to checkpoint hosted objects）がその試みの最中に失敗したかどうかを示す値が格納される。ＡｌａｒｍＴｈｒｏｔｔｌｅＬｉｍｉｔアトリビュート５１８には、エンジン上のオブジェクトが発生させる警報を制限される（throttling of alarms）までに、エンジン・オブジェクトが１秒間に発生させることのできる警報の数（value, in alarms per second raised by a engine object）を格納する。ＥｎｇｉｎｅＡｌａｒｍＲａｔｅアトリビュート５２０は、直近に完了したスキャンの最中にエンジンに登録された警報の数を示す。ＡｌａｒｍｓＴｈｒｏｔｔｌｅｄアトリビュート５２２は、直近のスキャンの最中にエンジン・オブジェクトが警報を制限したことを示す。

スクリプト実行を処理するための１組のアトリビュートが提供される。ＳｃｒｉｐｔＥｘｅｃｕｔｅＴｉｍｅｏｕｔアトリビュート５２４には、エンジン・オブジェクトに警報を発生させることなく、同期的スクリプトに実行を完了させるための時間の限界が格納される。ＳｃｒｉｐｔＳｔａｒｔｕｐＴｉｍｅｏｕｔアトリビュート５２６には、警報を発生させずに、同期的スクリプトを開始するための時間の限界が格納される。ＳｃｒｉｐｔＳｈｕｔｄｏｗｎＴｉｍｅｏｕｔアトリビュート５２８には、警報を発生させずに、同期的スクリプトを停止するための時間の限界が格納される。ＰｕｂｌｉｓｈｅｒＨｅａｒｔｂｅａｔアトリビュート５３０には、エンジン・オブジェクトが別のエンジン・オブジェクトからのハートビート・メッセージを、そのエンジンが障害を起していると仮定せずに待つことのできる秒数に相当する数が格納される。ＰｒｏｃｅｓｓＩｄアトリビュート５３２は、エンジン・プロセスに割り当てられた一意の識別子を識別する。

エンジン・オブジェクトはまた、アプリケーション・オブジェクトの管理に関連付けられた１組のコマンド・アトリビュートも含む。ＣｒｅａｔｅＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔアトリビュート５３４は、アプリケーション・オブジェクトを生成するためのコマンド・アトリビュートである。ＤｅｌｅｔｅＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔアトリビュート５３６は、アプリケーション・オブジェクトを削除するためのコマンド・アトリビュートである。ＳｔａｒｔＨｏｓｔｅｄＯｂｊｅｃｔｓアトリビュート５３８は、ホスト対象アプリケーション・オブジェクトを開始するためのコマンド・アトリビュートである。

図６に移ると、スケジューラ・プリミティブ内に含まれ、スケジューラ・オブジェクト毎に固有な１組のアトリビュートが要約されている。各スケジューラ・オブジェクトは、Ｅｘｔｅｒｎａｌ Ｎａｍｅアトリビュート６００およびＩｎｔｅｒｎａｌ Ｎａｍｅアトリビュート６０２を含む。ＳｔａｔｓＡｖｇＰｅｒｉｏｄアトリビュート６０４には、以下本明細書で説明するアトリビュートに格納される統計データを、スケジューラが獲得するのに要する平均期間を表す値が格納される。ＣｈｅｃｋｐｏｉｎｔＰｅｒｉｏｄＡｖｇアトリビュート６０６は、現在の平均期間の間におかれるチェック・ポイント間の現在の平均時間を識別する。ＥｘｅｃｕｔｉｏｎＴｉｍｅＡｖｇアトリビュート６０８には、１スキャン・サイクルですべてのオブジェクトを実行するのに要する時間量を表す値が格納される。ＨｏｕｓｅｋｅｅｐｉｎｇＴｉｍｅＡｖｇアトリビュート６１０には、日常業務（housekeeping operations）を完了するのに要する１サイクル当りの平均時間に相当する値が格納される。ＴｉｍｅＩｄｌｅＡｖｇアトリビュート６１２には、期間当りの平均アイドル時間を表す値が格納される。ＴｉｍｅＩｄｌｅＭａｘアトリビュート６１４には、記録された最長アイドル時間を表す値が格納される。ＴｉｍｅＩｄｌｅＭｉｎアトリビュート６１６には、記録された最短アイドル時間を表す値が格納される。ＩｎｐｕｔＭｓｇＳｉｚｅＡｖｇアトリビュート６１８には、平均期間での平均（普通の）入力メッセージ長が格納される。ＩｎｐｕｔＭｓｇｓＰｒｏｃｅｓｓｓｅｄＡｖｇアトリビュート６２０には、平均期間中の１スキャン・サイクルで処理されたメッセージの全体量を表す値がバイト単位で格納される。ＩｎｐｕｔＭｓｇｓＱｕｅｕｅｄＡｖｇアトリビュート６２２には、平均期間中の１スキャン・サイクルで待ち行列に入れられたメッセージの平均数が格納される。ＩｎｐｕｔＭｓｇｓＱｕｅｕｅｄＭａｘアトリビュート６２４には、統計データ・アトリビュートが最後にリセットされて以降の、アトリビュート６２２に格納された最大平均値が格納される。

ＩｎｐｕｔＱｕｅｕｅＳｉｚｅＭａｘＡｌｌｏｗｅｄアトリビュート６２６には、ネットワーク・メッセージ交換の入力待ち行列（network message exchange input queue）に入れられるメッセージの最大許容サイズが格納される。ＩｎｐｕｔＱｕｅｕｅＳｉｚｅＡｖｇアトリビュート６２８には、平均期間中の入力待ち行列の平均サイズがバイト単位で格納される。ＩｎｐｕｔＱｕｅｕｅＳｉｚｅＭａｘアトリビュート６３０には、統計アトリビュートが最後にリセットされて以降の、アトリビュート６２８に格納された最大平均値が格納される。

ＴｉｍｅＩｎｐｕｔＡｖｇアトリビュート６３２には、現在の期間中に入力メッセージを処理するのに必要な平均時間を表す値が格納される。ＯｂｊｅｃｔＣｎｔアトリビュート６３４には、スケジューラ・オブジェクトが現在処理しているアプリケーション・オブジェクトの数に相当する計数値が格納される。ＯｂｊｅｃｔＯｆｆＳｃａｎＣｎｔアトリビュート６３６は、現在スキャン対象外のアプリケーション・オブジェクトの数を示す。ＴｉｍｅＯｕｔｐｕｔＡｖｇアトリビュート６３８には、サイクル中に出力メッセージを処理するのに必要な平均時間量が格納される。ＳｔａｔｓＲｅｓｅｔアトリビュート６４０は、スケジューラに関して説明した統計アトリビュートのうち定期的にはリセットされないもの（たとえば、最大値など）をリセットするためのリクエストを指定する。ＳｃａｎＣｙｃｌｅｓＣｎｔアトリビュート６４２には、ＳｔａｔｓＲｅｓｅｔアトリビュート６４０によって最後にアトリビュートがリセットされて以降のサイクル数を示す値が格納される。ＳｃａｎＯｖｅｒｒｕｎｓＣｎｔアトリビュート６４４は、最後のＳｔａｔｓＲｅｓｅｔ以降の、すべてのオブジェクトのスキャンを完了させずに終了したスキャン・サイクルの回数を示す。ＳｃａｎＯｖｅｒｒｕｎｓＣｏｎｓｅｃｕｔｉｖｅＣｎｔアトリビュート６４６には、現在オーバランを連続して発生させている一連のサイクルの数が格納される。ＳｃａｎＯｖｅｒｒｕｎＨｉｇｈＬｉｍｉｔアトリビュート６４８には、ＳｃａｎＯｖｅｒｒｕｎＣｏｎｄｉｔｉｏｎアトリビュート６５０に格納されている警報をトリガする、連続オーバランの上側警報限界（high alarm limit）が格納される。ＳｃａｎＰｅｒｉｏｄアトリビュート６５２には、スケジューラのサイクル時間を表す値が格納される。

特定のオブジェクト・タイプに関連付けられるアトリビュートは、特定のオブジェクト・プリミティブ・タイプのものだけには限定されないことに留意されたい。実際、すべてのオブジェクト・タイプは、少なくとも上記のプリミティブの２つの組を含む。すべてのオブジェクト・タイプは、共通オブジェクト・プリミティブを利用する。加えて、プラットフォーム・オブジェクトは、上記のスケジューラ、エンジン、およびプラットフォーム・プリミティブを含む。エンジン・オブジェクトは、スケジューラ、およびエンジン・プリミティブを含む。

図７に移ると、アプリケーション・オブジェクトに関連付けられる１組のプリミティブが示されている。アプリケーション・オブジェクトの各タイプ毎に、固有の１組のプリミティブがある。プリミティブは、業務特有のロジックと、そのプリミティブの機能に固有の１組のアトリビュートを含む。これらのプリミティブは、異なるアプリケーションオブジェクトタイプの間で再利用することができる。

アナログ装置アプリケーション・オブジェクトに関連付けられた１組の例示的なプリミティブが図７に示されている。ＡｎａｌｏｇＤｅｖｉｃｅ Ａｔｔｒｉｂｕｔｅｓと名づけられたプリミティブ７００は、クライアントが関心を持つであろうアナログ装置特有の１組のアトリビュートを含む。ＰＶ．Ｉｎｐｕｔ７０１は、装置統合オブジェクト（たとえば、ＰＬＣ１など）を介して、フィールド装置からデータを読み取るプリミティブである。ＰＶ．Ｏｕｔｐｕｔ７０２は、装置統合オブジェクトを介して、そのフィールドへデータを書き込むプリミティブである。Ｓｃａｌｉｎｇ７０３は、入力プリミティブ（ＰＶ．Ｉｎｐｕｔ７０１）から読み取ったデータに対して、線形または平方根スケーリング（linear or square root scaling）を実行するプリミティブである。ＬｅｖｅｌＡｌａｒｍｓ７０４は、ＡｎａｌｏｇＤｅｖｉｃｅプリミティブ７００内のプロセス変数が設定値を上回った、または下回った場合に、警報を発生させるプリミティブである。ＰＶ．Ｒｏｃ７０５は、ＰＶが事前設定された限界より速く増加または減少した場合に、警報を発生させるプリミティブである。ＳＰ７０６は、ＰＶ．Ｏｕｔｐｕｔ７０２が書き込んだ値を変更したい場合に、クライアントが書き込むプリミティブである。ＰＶＤｅｖ７０７は、フィールド装置から（プリミティブ７０１を介して）読み込んだ値が、フィールド装置に（プリミティブ７０２を介して）書き込まれた値からある量だけずれている場合に、警報を発生させるために使用されるプリミティブである。ＣｔｒｌＴｒａｃｋ７０８は、設定点およびＰＶプリミティブが、外部装置によって引き起こされる変化を追跡できるようにするプリミティブである。本発明を実施する監視プロセス制御／製造情報アプリケーションの基本的な構成要素について説明してきたが、次に、そうしたアプリケーションを実行する際に用いられる方法を要約した１組のシーケンス図に話を進める。図８に移ると、階層ホスティング関係を実施するアプリケーションを開始させ、また停止させるための諸ステップを描いたシーケンス図が示されている。ステージ８００で、コンピュータ・システム上のブートストラップ・プロセスが、ロードされたプラットフォーム・オブジェクトにプラットフォーム開始リクエストを発行する。それに応答して、ステージ８０２で、プラットフォーム・プロセスが、プラットフォーム・オブジェクトがホストするすべてのアプリケーション・エンジンを開始させるようブートストラップに要求するコールを、ブートストラップ・インターフェースに発行する。ステージ８０４で、ブートストラップ・プロセスが、先に論じたアトリビュートを有するアプリケーション・エンジン・オブジェクトを生成する。

ステージ８０６で、アプリケーション・エンジン・プロセスが、ホスト対象であるすべてのアプリケーション・オブジェクトを開始させる。アプリケーション・エンジンはまた、ステージ８０８で、ホスト対象のアプリケーション・オブジェクトをスケジューラ・プロセスに登録する。アプリケーション・オブジェクトを登録することで、そのアプリケーション・オブジェクトは、スケジューラが各スキャン・サイクル中にスキャンする１組のアプリケーション・オブジェクトに追加される。ステージ８１０で、アプリケーション・エンジンが、スケジューラに、開始および登録したアプリケーション・オブジェクトの実行／スキャンを開始するコマンドを発行する。その後、ステージ８１２で、スケジューラが、登録したアプリケーション・オブジェクトを実行する。こうした実行は、各スキャン・サイクル中に周期的に行われる。

スケジューラは、停止コマンドを受信するまで、監視プロセス制御／製造情報システム・アプリケーションに従って、周期的に登録されたアプリケーション・オブジェクトのスキャンを繰り返す。具体的には、ステージ８１４で、ブートストラップ・プロセスが、オペレーション・システムの停止コマンドに応答して、プラットフォーム・プロセスに停止コマンドを発行する。ステージ８１６で、プラットフォーム・プロセスが、プラットフォーム・プロセスがホストするすべてのエンジンの停止を開始させるエンジン停止コマンドを、ブートストラップに返す。それに応答して、ステージ８１８で、ブートストラップが、アプリケーション・エンジンに停止を求めるリクエストを発行する。ブートストラップは、エンジンが停止するのを待機する。しかし、ある期間が過ぎてもアプリケーション・エンジンが停止しない場合、ブートストラップは、オペレーティング・システムにアプリケーション・エンジン・プロセスを停止させるようリクエストする。

正常動作状態の下では、ステージ８２０で、アプリケーション・エンジンが、エンジンがホストするアプリケーション・オブジェクトを登録解除するためのコマンドを、スケジューラに発行する。さらに、本発明の実施形態では、エンジンは、ホスト対象のアプリケーション・オブジェクトに停止を求めるリクエストを発行する。しかし、本発明の代替実施形態では、停止リクエストは、スケジューラが登録解除コマンドに応答して発行する。

上で説明した例示的な実施形態では、エンジン・オブジェクトとプラットフォーム・オブジェクトは、ブートストラップ・プロセスと通信を行い、アプリケーションがその上で実行している物理的なコンピューティング装置構成に関連する監視プロセス制御／製造情報システム・アプリケーションのいくつかの態様を処理していることに留意されたい。しかし、アプリケーション・オブジェクト自体は、プラットフォームとは独立のインターフェースによって、エンジンおよびスケジューラのみと通信を行う。アプリケーション・オブジェクトをホストする１つまたは複数のエンジン・オブジェクトは、アプリケーション・オブジェクトがその上で実行されるコンピュータ・システムの特性から、アプリケーション・オブジェクトを分離する。したがって、アプリケーション・オブジェクトは、物理的なコンピューティング装置構成とは独立に実行される。アプリケーション・オブジェクトは、同一エリア内のその他のアプリケーション・オブジェクトとは同一エンジン上で共に実行するよう制約を受けるが、システム内の複数の可能なエンジンおよび／またはプラットフォームのうちの特定の１つの上で実行すべきとの要件による制約を受けない。したがって、１組のアプリケーション・オブジェクトを備えるエリアの移動（moving）は、影響を受けるエンジン上で動作している他のアプリケーション・オブジェクトの実行をできるだけ妨げないようにして行われる。

図９に移ると、アプリケーション・オブジェクトのホスト・エンジン・オブジェクトからの動作独立性（operational independence）と、アプリケーション・オブジェクトを別のエンジン・オブジェクト上に再展開できることを説明するシーケンス図が示されている。最初にステージ９００で、エンジンＡが、アプリケーション・オブジェクトＡの周期的実行／スキャンを始める開始コマンドを、スケジューラＡに発行する。ステージ９０２で、スケジューラは、周期的にアプリケーション・オブジェクトＡを活動化して、複数のアプリケーション・オブジェクトを備えるアプリケーションに関連付けられたその業務ロジックを実行する。

その後、アプリケーション技術者が、アプリケーション・オブジェクトＡを異なるコンピュータ・プラットフォーム上のエンジンＢに移動させることにしたとする。そのような変更を行う１つの理由は、システムが大きくなった場合に、コンピュータ装置上の作業負荷を軽減するためである。ステージ９０４で、ユーザが、アプリケーション・オブジェクトＡを移動させるリクエストを、エンジンＡに発行する。それに応答して、ステージ９０６で、エンジンＡが、アプリケーション・オブジェクトＡのスキャンを停止させるリクエストを、スケジューラＡに発行する。ステージ９０８で、エンジンＡは、アプリケーション・オブジェクトＡに停止（シャットダウン）を求めるコマンドを発行する。それ以外の点では、エンジンＡおよびスケジューラＡの動作は、アプリケーション・オブジェクトＡの移動による影響を受けない。

本発明の一実施形態では、アプリケーションは、複数のコンピューティング装置上に分散され、各コンピューティング装置は、アプリケーション・オブジェクトの実行を容易にするアプリケーション階層を成すプラットフォーム、エンジン、およびスケジューラ・オブジェクトを備えている。下位レベルのホスティング機能を複数のハードウェア・プラットフォームにわたって複製することは、アプリケーションの動作に影響を与えることなく、アプリケーション・オブジェクトの再配置を可能にする、ある程度のプラットフォームの独立性を提供する。たとえば、ステージ９１０で、ユーザは、アプリケーション・オブジェクトＡを異なるコンピュータ上のエンジンＢに追加する。初期化ステージ９１２には、たとえば、アプリケーション・オブジェクトを開始する前に、アプリケーション・オブジェクトが実行するカスタマイズされた初期化動作（たとえば、アプリケーション・オブジェクトが使用するクラス変数、キャッシング・インターフェースの初期化など）が含まれる。ステージ９１４で、エンジンＢが、アプリケーション・オブジェクトＡに開始コマンドを発行する。この時点で、そのオブジェクトは、そのプリミティブのすべてが初期化されていて、これらのプリミティブ内で管理されるアトリビュートに基づいて、最初の計算を達成することができるとものとする。ステージ９１６で、エンジンＢが、実行中のアプリケーション・オブジェクトＡを、新しいコンピューティング・プラットフォーム上のスケジューラＢに登録する。その後、ステージ９１８で、スケジューラＢは周期的に、アプリケーション・オブジェクトＡにその業務ロジックを実行するよう指示する。アプリケーション・オブジェクトを実行した結果は、局所的に、また各エンジンを接続するネットワーク全体に提供される。したがって、アプリケーション・オブジェクトＡをエンジンＢに再展開したとしても、アプリケーション・オブジェクトＡに関するデータアクセスには影響を及ぼさない。

メッセージ交換（message exchange）を介したオブジェクト間通信
本発明の一実施形態では、アプリケーション・オブジェクトは、物理アドレスではなく論理名で、他のオブジェクトを参照する。したがって、同一アプリケーション内の複数のアプリケーション・オブジェクト間の通信は、アプリケーション・オブジェクトに関しては、そのアプリケーション・オブジェクトを含むその基礎をなすネットワークの物理構成から分離される。プラットフォームおよびエンジン・オブジェクト内に組み込まれた、メッセージ交換と呼ばれるアプリケーションのコンポーネントは、アプリケーション・オブジェクトが、その分散アプリケーションを実行するネットワーク内のどこに位置する他のオブジェクトからデータを抽出（取得）したり、そこへデータを送信（設定）したりすることができる。メッセージ交換は、相手を物理ネットワーク・アドレスではなく論理名で指定することのできるピアツーピアの通信基盤である。したがって、アプリケーション・オブジェクトは、データ・リクエストの受信相手の物理ロケーションを考慮することなく、通信を行うことができる。これによって、アプリケーション・オブジェクトが最終的にどこに展開されるかにかかわらず、アプリケーションのアプリケーション・オブジェクト・レイヤを配置することも可能になる。本発明の一実施形態では、メッセージ交換は、アプリケーション・エンジンが実行するローカル・メッセージ交換（ＬＭＸ）と、分散アプリケーションを実行する、ネットワークを介して接続されたコンピューティング装置間で名前付きリクエストを通信できるようにするプラットフォームによって実行されるネットワーク・メッセージ交換（ＮＭＸ）と、に分けられる。本発明のさらに別の実施形態では、ＬＭＸとＮＭＸの機能は、エンジンによって実行される。このような構成にすることによって、プラットフォーム・オブジェクトがＮＭＸを実行するイベントで必要になる、余計なプロセス間通信を回避することができる。

エンジン・オブジェクト（たとえば、アプリケーション・エンジン・オブジェクト）内に組み込まれたＬＭＸは、他のオブジェクトのアトリビュートとして維持管理されているデータに、アプリケーション・オブジェクトがアクセスできるようにするサービスを提供する。ＬＭＸを使用して対象データにアクセスする場合、アプリケーション・オブジェクトは、オブジェクトに関連付けられた１データを表す文字列（たとえば、「ＯｂｊｅｃｔＢ．ＡｔｔｒｉｂｕｔｅＡ」の形式で指定されるアトリビュート）を指定する。ＬＭＸは、この文字列を用いて、（ネットワーク内の別のコンピューティング装置上に位置する対象オブジェクトにアクセスするために、プラットフォームが提供するＮＭＸサービスを潜在的にリクエストする）オブジェクトに関連付けられたデータを探し出す。ＬＭＸは、オブジェクトに関連付けられたデータを、そのデータを要求したアプリケーション・オブジェクトに返す。さらに、メッセージ交換は、メッセージ配信の認証を保証する。したがって、アプリケーション・オブジェクトが、メッセージを他のアプリケーション・オブジェクトに送信すると、送信元オブジェクトは、メッセージ送信先がメッセージを受信したかどうかの確認を受信する。

アプリケーション・エンジンのＬＭＸは、たとえば、１組のインターフェースを含む。１組のインターフェースには、ＩＭｘＳｕｐｅｒｖｉｓｏｒｙＣｏｎｎｅｃｔｉｏｎとＩＭｘＵｓｅｒＣｏｎｎｅｃｔｉｏｎが含まれる。ＩＭｘＳｕｐｅｒｖｉｓｏｒｙＣｏｎｎｅｃｔｉｏｎインターフェースは、アプリケーション・オブジェクトがプラント内の物理装置からの情報にアクセスする際に使用するメソッドを定義する。このインターフェースで使用されるメソッドには、ＳｕｐｅｒｖｉｓｏｒｙＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅ、ＳｕｐｅｒｖｉｓｏｒｙＧｅｔＡｔｔｒｉｂｕｔｅ、およびＳｕｐｅｒｖｉｓｏｒｙＳｅｔＡｔｔｒｉｂｕｔｅがある。ＳｕｐｅｒｖｉｓｏｒｙＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅメソッドは、アトリビュートの値へのアクセス要求がこれから来ることをメッセージ交換に通知するために、アプリケーション・オブジェクトによって呼び出される。ＳｕｐｅｒｖｉｓｏｒｙＳｅｔＡｔｔｒｉｂｕｔｅメソッドは、先のＳｕｐｅｒｖｉｓｏｒｙＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅ呼び出しで指定されたアトリビュートの値を変更するようメッセージ交換に指示するために、アプリケーション・オブジェクトによって使用される。ＳｕｐｅｒｖｉｓｏｒｙＧｅｔＡｔｔｒｉｂｕｔｅメソッドは、先のＳｕｐｅｒｖｉｓｏｒｙＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅ呼び出しで指定されたアトリビュートの値を取り出すようメッセージ交換に指示するために、アプリケーション・オブジェクトによって使用される。

ＩＭｘＵｓｅｒＣｏｎｎｅｃｔｉｏｎインターフェースは、アプリケーションがプラント内の物理装置から取り出されたデータを視覚化する際に使用するメソッドを定義する。このインターフェースで使用されるメソッドには、ＵｓｅｒＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅ、ＵｓｅｒＧｅｔＡｔｔｒｉｂｕｔｅ、およびＵｓｅｒＳｅｔＡｔｔｒｉｂｕｔｅがある。これらのメソッドは、先に説明したＩＭｘＳｕｐｅｒｖｉｓｏｒｙＣｏｎｎｅｃｔｉｏｎインターフェースのメソッドと非常に類似している。１つの違いは、ＩＭｘＵｓｅｒＣｏｎｎｅｃｔｉｏｎインターフェース・メソッドのメソッドが、コールバック機構を介してデータ更新を可能にして、ユーザ・インターフェース・クライアントに応じるのに対して、ＩＭｘＳｕｐｅｒｖｉｓｏｒｙＣｏｎｎｅｃｔｉｏｎでは、ポーリング機構が利用されることである。

メッセージ交換の機能性を実現するために、１組の構造が利用される。ＭｘＲｅｆｅｒｅｎｃｅ構造は、ＩＭｘＲｅｆｅｒｅｎｃｅインターフェースを実装するマイクロソフトのコンポーネント・オブジェクト・モデル（ＣＯＭ）であり、値がアプリケーション・オブジェクトによってアクセスされるオブジェクトのアトリビュートを識別し、メソッドＳｕｐｅｒｖｉｓｏｒｙＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅおよびＵｓｅｒＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅに渡される。ＭｘＲｅｆｅｒｅｎｃｅＨａｎｄｌｅ（整数値）は、メッセージ交換よって使用され、ＭｘＲｅｆｅｒｅｎｃｅによって参照される値を取り出すロケーション透過な手段をアプリケーション・オブジェクトに提供する。ＳｕｐｅｒｖｉｓｏｒｙＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅコールまたはＵｓｅｒＲｅｇｉｓｔｅｒＲｅｆｅｒｅｎｃｅコールが正常終了したときに、メッセージ交換は、アプリケーション・オブジェクトにＭｘＲｅｆｅｒｅｎｃｅＨａｎｄｌｅを返す。ＭｘＲｅｆｅｒｅｎｃｅＨａｎｄｌｅは、アプリケーション・オブジェクトによって、アトリビュートの取得および設定を行う、ＵｓｅｒＳｅｔＡｔｔｒｉｂｕｔｅ、ＵｓｅｒＧｅｔＡｔｔｒｉｂｕｔｅ、ＳｕｐｅｒｖｉｓｏｒｙＳｅｔＡｔｔｒｉｂｕｔｅ、ＳｕｐｅｒｖｉｓｏｒｙＧｅｔＡｔｔｒｉｂｕｔｅなどのメソッド・コールに渡される。

ＭｘＨａｎｄｌｅ構造は、オブジェクトのアトリビュートのプロパティを識別する。ＭｘＨａｎｄｌｅは、オブジェクトが属するプラットフォームおよびエンジンを識別する。ＭｘＨａｎｄｌｅは、２つの構造、ＭｘＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔＨａｎｄｌｅおよびＭｘＡｔｔｒｉｂｕｔｅＨａｎｄｌｅを備える。ＭｘＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔＨａｎｄｌｅは、システム全体のオブジェクトのロケーションを表すのに使用されるデータ構造である。ＭｘＡｔｔｒｉｂｕｔｅＨａｎｄｌｅデータ構造は、オブジェクト内のアトリビュートのプロパティを識別するのに使用される。ＭｘＡｔｔｒｉｂｕｔｅＨａｎｄｌｅ構造は、速やかにオブジェクトのアトリビュートを探し出すために、メッセージ交換によって、内部的に、使用される。

ＭｘＡｕｔｏｍａｔｉｏｎＯｂｊｅｃｔＨａｎｄｌｅデータ構造は、５つのフィールド、ｇａｌａｘｙ、ｐｌａｔｆｏｒｍ、ｅｎｇｉｎｅ、ｏｂｊｅｃｔ、およびｓｉｇｎａｔｕｒｅを含む。ｇａｌａｘｙフィールドは、参照されるオブジェクトが属する全体的なシステムを識別する。ｐｌａｔｆｏｒｍフィールドは、参照されるオブジェクトが関連するプラットフォーム・オブジェクトを識別する。ｅｎｇｉｎｅフィールドは、オブジェクトのエンジンを識別する。ｏｂｊｅｃｔフィールドは、オブジェクトを識別する。ｓｉｇｎａｔｕｒｅフィールドには、オブジェクト名から派生し、オブジェクトの再配置時に発生し得る構成上の不整合を防止する値が格納される。

ＭｘＡｔｔｒｉｂｕｔｅＨａｎｄｌｅデータ構造は、７つのフィールド、ｐｒｉｍｉｔｉｖｅＩＤ、ａｔｔｒｉｂｕｔｅＩＤ、ｐｒｏｐｅｒｔｙＩＤ、ｉｎｄｅｘ１、ｉｎｄｅｘ２、ｉｎｄｅｘ３、およびｓｉｇｎａｔｕｒｅを含む。ｐｒｉｍｉｔｉｖｅＩＤフィールドは、オートメーション・オブジェクト内のプリミティブを識別する。プリミティブは、たとえば、アプリケーション・オブジェクト内の特定の動作を実行するヘルパ・オブジェクト（helper object）である。ａｔｔｒｉｂｕｔｅＩＤフィールドは、識別されたプリミティブ内の特定のアトリビュートを識別する。ｐｒｏｐｅｒｔｙＩＤフィールドは、アトリビュートのプロパティを識別する。ｉｎｄｅｘ１、ｉｎｄｅｘ２、ｉｎｄｅｘ３フィールドは、最高３次元の配列に対するインデクスを提供する。ｓｉｇｎａｔｕｒｅフィールドには、ＭｘＡｔｔｒｉｂｕｔｅＨａｎｄｌｅの内容から派生した、構成上の不整合を防止するためのチェックサム値が格納される。

本発明の実施形態では、メッセージ交換は、追加のデータ構造およびインターフェースを含むことに留意されたい。そうした追加のインターフェースおよび構造は、当業者には周知であろう。さらに本発明は、監視プロセス制御／製造情報アプリケーション内の１組のアプリケーション・オブジェクトのオブジェクト間通信向けに、ハードウェア／展開とは独立のメッセージ・サービスをメッセージ交換を利用して提供するシステムに限定されるものでないことにも留意されたい。

複数ビュー／後段階でのモデル展開の設定
提案されるアプリケーション・アーキテクチャの別の態様は、オブジェクト間の関連付け（associations）の指定である。以下本明細書で論じるこの関連付けは、本明細書で統合開発環境（ＩＤＥ）と呼ぶ構成コンポーネントが、１組の関連する複数のオブジェクトを、少なくとも（論理）モデル・ビュー（model view）と（物理コンピューティング）展開ビュー（deployment view）を含む多様なビューで、フィルタリングして表示することができる。ＩＤＥは、アプリケーションの構成についてその表示されたビューを通して、ユーザが、多数のコンピューティング装置を備えるコンピュータ・ネットワーク内のアプリケーションを設計し、展開することを可能にする。

アプリケーション構成は、構成データベース１２４内に「パッケージ（package）」として格納される。パッケージ・フレームワーク・サブ・システム（package framework subsystem）はインターフェースを提供し、ＩＤＥはこれを用いて、パッケージのオブジェクトを格納し、取り出すことができる。パッケージ・フレームワークは、オブジェクトと他のオブジェクトとの関連付け／関係（associations/relationships）に関するパッケージ・データおよび知識（knowledge）を格納するのに、リレーショナル・データベースを利用する。ＩＤＥは、あるオブジェクトとの指定された関連付けに基づくオブジェクトのリストを転送するよう、パッケージ・フレームワークにクエリを発行する。たとえば、ＩＤＥは、指名したエンジンがホストするオブジェクトをパッケージから取り出すよう、パッケージ・フレームワークに要求することができる。

開発者は、前述したオブジェクト間の関連付け（または「関係」）を、ＩＤＥおよびパッケージ・マネージャを介して構築する。こうした関連付けには、たとえば、以下の事前定義された割り当て関係、すなわち、ホスト、エリア、コンテナ、エンジン、およびプラットフォームが含まれる。これらの関係の各々について、以下本明細書で論じる。

ホスト関係は、オブジェクトがどこで実行されるかを示すために、実行時に使用される。さらに、オブジェクトは、そのホストが展開されないうちは展開できない。アプリケーション・オブジェクトは、エリア・オブジェクトによってホストされ、エリア・オブジェクトは、エンジン・オブジェクトによってホストされ、エンジン・オブジェクトは、プラットフォーム・オブジェクトによってホストされる。エリア関係は、オブジェクトを論理グループに分類し、エリアの下にまとめられたオブジェクトが発生させるイベントおよび警報を収集する手段を提供する。コンテナ関係は、２つのオブジェクト間の緩やかな結合を指定し、アプリケーション・ロジックのコンテクストにおいてのみ意味をもつ。たとえば、弁（Valve）オブジェクトは槽（Tank）オブジェクトの中に含まれる。包含されるオブジェクトは、そのオブジェクトのコンテナとの関係で、階層名（hierarchical name）を獲得することができる。たとえば、入口弁（inlet）として機能する弁は、別名「ｉｎｌｅｔ」を割り当てられ、階層名「Ｔａｎｋ．Ｉｎｌｅｔ」を受け取る。オブジェクトのエンジンは、そのオブジェクトを実行する実際のエンジンである。オブジェクトのプラットフォームは、そのオブジェクトが展開されたコンピュータ装置上で動作する唯一のプラットフォーム・オブジェクトである。オブジェクトは、これら５つの関係をすべてもつことができるが、１つのオブジェクトがこれらの関係のうちの任意の１つに関連付けられるだけである。たとえば、（一つの）アプリケーション・オブジェクトは、１つのエリアにしか割り当てることができない。

モデル・ビューは、制御されるプラント・プロセス内にあるプラント／プロセス設備間の論理的な関連付け、たとえば、物理的なプラント配置図表現、の形でアプリケーションを描き出す。展開ビューは、物理コンピュータ装置と、モデル・ビューで識別されるインスタンス化されたオブジェクトの、コンピュータ装置およびそのコンピュータ装置上で実行されるエンジンへの割り当てを描き出す。派生ビュー（derivation view）は、モデル・ビュー要素の機能を実行するために、テンプレートからインスタンス化されたオブジェクトのソース（基底テンプレートからインスタンスへ継承されたプロパティの関係）を描き出す。

たとえば、図１には、２台のアプリケーション・サーバ・コンピュータ１００、１０２に物理的に展開されたアプリケーションが示されている。あるいは、アプリケーションは、そのアプリケーションによる監視プロセス制御の実行および／または製造情報の抽出におけるアプリケーション・オブジェクトの役割を視覚的に表現することによって、ユーザに提示される。次に図１０に移ると、プラント・プロセス・アプリケーションが、プラント・プロセスにおけるアプリケーション・オブジェクトの役割に基づいて、プラント・モデルで表現されている。この説明のための例は、本発明の例示的な実施形態を説明的に表現する目的で規模を小さくしてある。当業者が容易に理解するように、本発明は、この例よりもはるかに複雑な多種多様な工業用／プラント用のモニタ／制御アプリケーションに適用可能である。

制御出口弁を有するホッパＨ１ １０００は、左右に移動または停止するように制御可能なコンベヤＣ１ １００２に原料を供給する。原料は、コンベヤＣ１ １００２によって、ミキサＭ１ １００４およびミキサＭ２ １００６の中に落とされる。原料は、ミキサＭ１ １００４の弁Ｖ１ １０１２およびミキサＭ２ １００６の弁Ｖ２ １０１４を開放することによって、各ミキサ内部に流れ込むようにされる。ミキサＭ１ １００４およびミキサＭ２ １００６はそれぞれ、制御可能な撹拌器Ａ１ １００８およびＡ２ １０１０を含む。混合された原料は、ホッパＨ２ １０１６およびＨ３ １０１８に落とされる。ホッパＨ２ １０１６およびＨ３ １０１８を選択的に開放して、混合された製品を、右に移動または、停止するコンベヤＣ２ １０２０の上に落とす。コンベヤＣ２ １０２０は、移動中であれば、混合された原料を昇降機Ｅ１ １０２２の上に落とす。昇降機Ｅ１ １０２２は、混合された原料を右に移動するコンベヤＣ３ １０２４の上に降ろす。コンベヤＣ３ １０２４は、左右に移動可能で、混合された製品を第１の２状態ドアＤ１ １０２８と第２の２状態ドアＤ２ １０３０とに分配することのできる分配コンベヤＣ４ １０２６の上に、原料を降ろす。ドアＤ１ １０２８は、完成品をビンＢ１ １０３２またはビンＢ２ １０３４に送り出すように制御可能である。ドアＤ２ １０３０は、完成品をビンＢ３ １０３６またはビンＢ４ １０３８に送り出すように制御可能である。

図１０に示した上記の加工ラインは単純であり、それゆえ、流れを追うのも比較的簡単であるが、大抵の場合、工程は非常に複雑であり、数百あるいは数千の異なるセンサや制御された構成要素を含む。そうした場合、センサや制御された構成要素に対応するアプリケーション・オブジェクトは、論理的にエリアにグループ分けされる。アプリケーション・オブジェクトの論理的グループ化は、実行時に、警報およびイベント管理に関して特定のアプリケーション・オブジェクトを一様に取り扱うために利用される。たとえば、あるエリア・オブジェクト内の１アトリビュートの指定次第で、そのエリア内ではすべての警報を無効にすることができる。ホスト・エリアとホストされるオブジェクトとの適合性は、ホストされるオブジェクトの「必要とされるホスト機能」と、ホスト・エリア・オブジェクトが指定する「サポートする機能（supported features）」とを調べることにより決定される。これらのオブジェクト・アトリビュートは、オブジェクトを構成するときに定められる。「必要とされるホスト機能（required host features）」が、「サポートする機能」と合致している場合、ホスト割り当ては、ホストされるオブジェクトに適切な値を割り当てることによって完了する。オブジェクトは、アプリケーションまたはエリア・オブジェクトの共通プリミティブのＡｒｅａアトリビュート３２８にエリア名を指定することによって、エリア内に配置される。

エリア自体も、階層構成内の別のエリア内にグループ化することができる。エリアを別の「ホスト」エリアに割り当てるには、たとえば、ホストされるエリア・オブジェクトのＡｒｅａアトリビュート３２８にホスト・エリア名を指定する。エリアとサブ・エリアの関係にあるエリア同士を、同一エンジン上で実行する必要はない。したがって、監視プロセス制御／製造情報アプリケーションのアプリケーション・オブジェクトを複数のプラットフォーム・オブジェクト（複数のコンピュータ装置に相当）とエンジン・オブジェクトを含むシステム内に展開する場合、エリア内のサブ・エリアを異なるアプリケーション・エンジンに割り当てることができる。しかし、本発明の一実施形態では、サブ・エリア内に指定される各アプリケーション・オブジェクトは、同一アプリケーション・エンジン上に展開するという制約を設ける。この制約は、ノード間通信遅延を発生させることなく、エリア内のすべてのアプリケーション・オブジェクトを処理することを確実にする。

エリア・オブジェクトは、たとえば、上記の機能性の実施を容易にするアトリビュート、すなわち、ａｌａｒｍ ｉｎｆｏｒｍａｔｉｏｎアトリビュート、ｄｉｓａｂｌｅ ａｌｌ ａｌａｒｍアトリビュート、ｄｉｓａｂｌｅ ｔｈｅ ｄｉｓｐｌａｙ ｏｆ ａｌｌ ａｌａｒｍｓアトリビュート、ｓｕｂ−ａｒｅａ ｌｉｓｔアトリビュートを含む。

図１１に移ると、図１０の関連するプロセス・コンポーネントを、論理的にエリアにグループ分けした様子が示されている。改定されたプロセス説明図では、論理的にグループ分けされた制御されるプロセス・コンポーネントを備える一連のエリアとして、システムが描いてある。原料貯蔵エリア１１００は、ホッパＨ１ １０００を含む。生産エリア１１０２は、コンベヤＣ１ １００２、ライン１エリア１１０４、およびライン２エリア１１０６を含み、ライン１エリアは、ミキサＭ１ １００４、弁Ｖ１ １０１２、およびホッパＨ２ １０１６を含み、ライン２エリアは、ミキサＭ２ １００６、弁Ｖ２ １０１４、およびホッパＨ３ １０１８を含む。配送エリア１１０８は、コンベヤＣ２ １０２０、昇降機Ｅ１ １０２２、コンベヤＣ３ １０２４、コンベヤＣ４ １０２６、２状態ドアＤ１ １０２８、および２状態ドアＤ２ １０３０を含む。完成品貯蔵エリア１１１０は、ビンＢ１ １０３２、Ｂ２ １０３４、Ｂ３ １０３６、およびＢ４ １０３８を含む。１組のサブ・エリアは、１つのプロセス・プラント・エリア１１２０の下にグループ化される。

例示的なプラント・プロセスと、そのプラント・プロセスに関連するアプリケーションを表示するための２つの択一的方法（すなわち、プラント・モデル・ビューとアプリケーション・オブジェクト展開ビュー）を説明してきたが、次に、これら２つの択一的ビューによってアプリケーション・コンポーネントを表示する、構成ユーティリティ・インターフェースについて説明する。図１２を簡単に参照すると、構成ユーティリティイが生成した未完成のモデル・ビュー・ユーザ・インターフェースによって描かれた、ツリー形式で表現したエリア階層が示されている。このツリー構造は、図１１に描かれたプロセス・プラント内で示されたエリアの上位レベルのモデル・ビューを提示している。このモデル・ビューは、識別された各エリアにグループ分けされたアプリケーション・オブジェクトと、アプリケーション・オブジェクト同士の包含関係を識別していないので、未完成である。

例示的なツリー構造を参照すると、プロセス・プラント・エリア１１２０に対応するＰｒｏｃｅｓｓＰｌａｎｔノード１２００が、階層エリア表現の最上位レベルとして指定されている。プロセス・プラント・エリア１１２０内でグループ分けされたサブ・エリアに対応する１組の第２レベルのノードは、ＰｒｏｃｅｓｓＰｌａｎｔノード１２００から枝分れしている。ＲａｗＭａｔｅｒｉａｌＳｔｏｒｅノード１２０２、Ｐｒｏｄｕｃｔｉｏｎノード１２０４、Ｄｉｓｔｒｉｂｕｔｉｏｎノード１２０６、ＦｉｎｉｓｈｅｄＰｒｏｄｕｃｔＳｔｏｒｅノード１２０８はそれぞれ、原料貯蔵エリア１１００、生産エリア１１０２、配送エリア１１０８、完成品貯蔵エリア１１１０に対応する。Ｐｒｏｄｕｃｔｉｏｎノード１２０４から枝分れするＬｉｎｅ１ノード１２１０、Ｌｉｎｅ２ノード１２１２は、図１１において生産エリア１１０２内でグループ分けされたライン１エリア１１０４、ライン２エリア１１０６に対応する。このビューは、技術者が、警報の挙動などの、アプリケーション・オブジェクトを制御する方針を定めるための論理グループ分けを、素早く、識別し、指定する（明示する）ことができる。

識別されたエリア内のアプリケーション・オブジェクトおよびコンパウンド（compound）を識別する、図１２のモデル・ビューの拡張版について説明する前に、テンプレートからのオブジェクトの派生について論じる。図１０内で識別される各構成要素は、１つのアプリケーション・オブジェクトに対応する。本発明の一実施形態では、アプリケーション・オブジェクトは、オブジェクト・テンプレートからインスタンス化される。派生ビューには、アプリケーションの現モデルによって指定されるアプリケーション・オブジェクトの派生元であるすべてのタイプのテンプレートが示される。

アプリケーション・オブジェクトがそこから派生する１組の候補テンプレート（candidate template）は拡張性をもつ。ユーザには、基底テンプレートと、ユーザがそこからアプリケーション・オブジェクトを構築するカスタマイズされた新しいテンプレートを定義するためのエディタと、を備えたツールキットが提供される。基底テンプレートの例としては（＄はテンプレートであることを表す）、図１０に描かれた主コンベヤおよび弁を表すアプリケーション・オブジェクトを生成するように構成できる状態機械である＄ＤｉｓｃｒｅｔｅＤｅｖｉｃｅ、および共通プリミティブのみを含む単純なオブジェクト・テンプレートである＄ＵｓｅｒＤｅｆｉｎｅｄが挙げられ、ユーザは、これらにビンやホッパに対応するアプリケーション・オブジェクトをモデル化するためのスクリプトやアトリビュートを追加することによって、構成環境内で、拡張（テンプレート）を構築する。

図１３に移ると、生成された派生ビューによって描かれた例示的な派生ビューが、説明のために図示されている。図１３を参照すると、図１０に示す例に関して、ユーザが、＄ＤｉｓｃｒｅｔｅＤｅｖｉｃｅ基底テンプレートから、＄Ｖａｌｖｅ、＄ＳｌｉｃｅＧａｔｅ、＄Ａｇｉｔａｔｏｒ、および＄Ｃｏｎｖｅｙｏｒのカスタム・アプリケーション・オブジェクト・テンプレート・タイプを派生させている。さらに、＄Ｃｏｎｖｅｙｏｒテンプレートの下に、＄ＳｉｎｇｌｅＤｉｒｅｃｔｉｏｎＣｏｎｖｅｙｏｒ、＄ＢｉＤｉｒｅｃｔｉｏｎＣｏｎｖｅｙｏｒ、および＄Ｅｌｅｖａｔｏｒテンプレート・タイプが定義されている。＄ＵｓｅｒＤｅｆｉｎｅｄテンプレートの下では、＄Ｖｅｓｓｅｌアプリケーション・オブジェクト・テンプレートが派生している。＄Ｖｅｓｓｅｌテンプレートはさらに、＄Ｈｏｐｐｅｒおよび＄Ｂｉｎのアプリケーション・オブジェクトを派生するように再定義されている。図１３を参照すると、基底テンプレートが、個々のテンプレートのユーザ指定に基づいて構成ビュー・ジェネレータが描いた階層派生ツリー（hierarchical derivation tree）の最上位レベルを占めている。基底テンプレートから派生したオブジェクト・テンプレートは、基底テンプレート・ノードから伸びる枝によって識別される。図１３に図示するように、オブジェクトを他の派生オブジェクトから派生させることが可能である。そのような場合、子は親テンプレートの指定された特性を継承する。子と親テンプレートの間の派生関係は、テンプレート・オブジェクトのＤｅｒｉｖｅｄ ｆｒｏｍアトリビュート３１４に登録される。

（アプリケーション・オブジェクトのＣｏｎｔａｉｎｅｒアトリビュート３３０で指定された）アプリケーション・オブジェクトの包含、および１組の定義済みオブジェクト・テンプレートからのコンパウンド・オブジェクトの生成が、本明細書で開示されるテンプレートアーキテクチャの別の態様である。本発明の一実施形態では、包含は同一オブジェクト・タイプに制限される。したがって、エリア・オブジェクトは、エリア・オブジェクトのみを含むことができ、アプリケーション・オブジェクトは、アプリケーション・オブジェクトのみを含むことができる。他のオブジェクトを含むオブジェクトを、本明細書では「コンパウンド（compounds）」と呼ぶ。他のオブジェクトを含むためだけに存在するオブジェクトを、「コンポジット（composite）」と呼ぶ。

簡単に図１４ａおよび図１４ｂを参照すると、コンパウンド・アプリケーション・オブジェクト・テンプレートの例、この場合は、タグ名「Ｉｎｌｅｔ」を割り当てられた弁オブジェクト、オブジェクト名と同じタグ名「Ａｇｉｔａｔｏｒ」をもつ撹拌器オブジェクト、およびタグ名「Ｖｅｓｓｅｌ」を割り当てられたミキサ・オブジェクトを含む、＄ＭｉｘｅｒＶｅｓｓｅｌコンパウンド・オブジェクト・テンプレートが提供されている。包含されるこれら３つのオブジェクトの各々に対応したテンプレートのＣｏｎｔａｉｎｅｄ Ｎａｍｅアトリビュート３１０。完全な階層タグ名（たとえば、ＭｉｘｅｒＶｅｓｓｅｌ．Ｉｎｌｅｔ）は、包含される３つのオブジェクト各々のＨｉｅｒａｒｃｈｉｃａｌ Ｎａｍｅアトリビュート３１８に格納される。包含される各オブジェクトのＣｏｎｔａｉｎｅｒアトリビュート３３０には、文字列「ＭｉｘｅｒＶｅｓｓｅｌ」が割り当てられる。図１４ａには、図１０に描かれた、ミキサ槽装置を含むプロセス・プラントの一部が、概略的に描かれている。図１４ｂには、＄ＭｉｘｅｒＶｅｓｓｅｌアプリケーション・オブジェクト・テンプレートとそれが包含する（改名された）アプリケーション・オブジェクの間の包含関係を示す、コンパウンド・テンプレートのモデル・ビューが示されている。本発明の一実施形態では、実際のアプリケーション内でインスタンス化がなされると、コンパウンド・アプリケーション・オブジェクトに含まれるすべてのアプリケーション・オブジェクトは、アトリビュート３３８に同一ホストを（また、要件によりアトリビュート３２８に同一エリアを）指定する。この包含階層は、（展開制約に従うことを条件に）他のオブジェクトにも同様に適用可能であり、（数多くのより小さなアプリケーション・オブジェクトを含む）論理構成要素の生成をサポートすることによって、システム開発の際にシステム開発者を支援する。

本発明の一実施形態では、ＩＤＥによってサポートされる「包含（contain）」機能が、グラフィカル・ユーザ・インターフェースの「ドラッグ・アンド・ドロップ」操作を介して、オブジェクト間の包含関係の設定を容易にする。ソースとターゲット（コンテナ）アプリケーション・オブジェクトの間の包含関係を設定するために、開発者は、ユーザ・インターフェース上に表示されているソース・アプリケーション・オブジェクトを選択し、そのソース・アプリケーション・オブジェクトをターゲット（コンテナ）オブジェクトの上までドラッグし、そのソース・アプリケーション・オブジェクトをターゲット・アプリケーション・オブジェクトの上にドロップする。ＩＤＥは、２つのオブジェクト同士の適合性（すなわち、ともにアプリケーション・オブジェクトであること）を確認した後、（パッケージ・マネージャ・ユーティリティを用いて）ソース・オブジェクト内のＨｏｓｔ、Ａｒｅａ、Ｃｏｎｔａｉｎｅｒアトリビュートを設定する。具体的には、Ａｒｅａアトリビュート３２８には、ターゲット・オブジェクトのエリアが設定され、Ｈｏｓｔアトリビュート３３８には、ターゲットのホストが設定され、Ｃｏｎｔａｉｎｅｒアトリビュート３３０には、ターゲット・オブジェクトの名前が設定される。この時点で、ソースのＣｏｎｔａｉｎｅｄ Ｎａｍｅアトリビュート３１０およびＨｉｅｒａｒｃｈｉｃａｌ Ｎａｍｅアトリビュート３１８にも、開発者によって提供される名前が入れられる。

図１３に戻ると、＄ＭｉｘｅｒＶｅｓｓｅｌコンパウンド・アプリケーション・オブジェクト・テンプレートが、＄ＵｓｅｒＤｅｆｉｎｅｄ基底テンプレート・ノードの下の枝に割り当てられ、そのコンパウンドのアプリケーション・オブジェクト・テンプレート要素間の包含関係を指定している。さらに、＄Ｖａｌｖｅから派生した＄ＭｉｘｅｒＶｅｓｓｅｌ．Ｉｎｌｅｔテンプレートが、＄Ｖａｌｖｅテンプレート・ノードの下に展開されている。＄Ｖｅｓｓｅｌから派生した＄ＭｉｘｅｒＶｅｓｓｅｌ．Ｖｅｓｓｅｌテンプレートが、＄Ｖａｌｖｅテンプレート・ノードの下に展開されている。＄Ａｇｉｔａｔｏｒから派生した＄ＭｉｘｅｒＶｅｓｓｅｌ．Ａｇｉｔａｔｏｒテンプレートが、＄Ａｇｉｔａｔｏｒテンプレート・ノードの下に展開されている。この包含関係は、各コンパウンド要素のＣｏｎｔａｉｎｅｒアトリビュート３３０に＄ＭｉｘｅｒＶｅｓｓｅｌテンプレート・オブジェクトを指定することによって登録される。この包含関係は、図１３の派生ビュー・ツリーにおいて、派生ビュー・ツリー内での＄ＭｉｘｅｒＶｅｓｓｅｌ．Ｉｎｌｅｔ、＄ＭｉｘｅｒＶｅｓｓｅｌ．Ａｇｉｔａｔｏｒ、＄ＭｉｘｅｒＶｅｓｓｅｌ．Ｖｅｓｓｅｌというオブジェクト・テンプレート表現における「＄ＭｉｘｅｒＶｅｓｓｅｌ」のプリアンブルによって、示されている。

アトリビュート・ロッキング（attribute locking）、およびテンプレート間の変更伝播へのその影響が、本明細書で開示する例示的な構成ユーティリティについての派生アーキテクチャのまた別の態様である。派生アーキテクチャはオブジェクト・テンプレート内の情報を派生オブジェクトに伝播させることができ、あるいは、開発者が置き換え可能なデフォルト値が、派生テンプレートに指定される。本発明の一実施形態では、伝播は、親のロック・アトリビュート（locked attribute）のコピーへの参照を格納することによって、自動的に影響を受ける。

テンプレートまたはインスタンス内のアトリビュートは、親の中でアンロックおよびロックができ、あるいは自己の中でロックができる。テンプレートとインスタンスは、アンロックのアトリビュートをもつことができる。アンロックのアトリビュート（unlocked attribute）は、読み書き可能であり、オブジェクトは、アトリビュート値のそれ自身のコピー、すなわち、派生オブジェクトには共有（共用）されないコピーをもつ。テンプレートは、自己ロック・アトリビュート（locked in me attribute）状態を取ることができるが、インスタンスは取れない。自己ロック・アトリビュートの場合、その値は読み書き可能である。派生オブジェクトは、アトリビュート値の自己用のコピーをもつことはできず、代りに、アトリビュートがロックされている先祖を参照することによって、そのロックされた値を共有する。自己ロック・アトリビュートの子のアトリビュート状態は、「親ロック（locked in parent）」となる。したがって、自己ロック・テンプレート・アトリビュートの値の変更は、すべての子に伝播する。テンプレートとインスタンスは、親ロック・アトリビュート（locked in parent attribute）をもつことができる。親ロック・アトリビュートは、読取り専用である。

アトリビュートのロック状態を取得し設定するためのインターフェースが、構成クライアントに提示される。クライアントは、アトリビュートへの参照を取得し、そのロック状態を設定する。アトリビュートの変更が許可されるかどうか、および／またはその変更を派生した子に伝播させるかどうかは、テンプレート内の特定のアトリビュートがロックされているかどうかに基く。アトリビュートのロックによって、２つの結果がもたらされる。第１に、親ロック・アトリビュートは、派生テンプレートまたは派生インスタンスで変更することができない。第２に、テンプレートの自己ロック・アトリビュートは、変更することができ、その変更は、そのロック・アトリビュートを含むそのテンプレートから派生したすべてのテンプレートとインスタンスに次々に伝播する。一方、アトリビュートがロックされていない場合、そのアトリビュートは、派生テンプレート内で置き換えることのできるデフォルト値を指定する。さらに、非ロック（non-locked）アトリビュートの値が変更された場合、その変更は、派生テンプレートに伝播しない。

図１０内で識別されるアプリケーション・オブジェクトのために利用される１組のテンプレートを設定した後、提示のプロセス制御／製造情報監視アプリケーションに基づいて、アプリケーション・オブジェクト・インスタンスがテンプレートから生成される。図１３で定義されるテンプレートと図１０に描かれた例示的なプロセス・プラントを使用して、以下のアプリケーション・オブジェクトが描かれる。

＄ＭｉｘｅｒＶｅｓｓｅｌが、ミキサＭ１、Ｍ２用に使用される。
＄Ｈｏｐｐｅｒホッパが、Ｈ１、Ｈ２、Ｈ２用に使用される。
＄ＳｉｎｇｌｅＤｉｒｅｃｔｉｏｎＣｏｎｖｅｙｏｒが、コンベヤＣ２、Ｃ３用に使用される。
＄ＢｉＤｉｒｅｃｔｉｏｎａｌＣｏｎｖｅｙｏｒが、コンベヤＣ１、Ｃ４用に使用される。
＄ＳｌｉｄｅＧａｔｅが、ドアＤ１、Ｄ２用に使用される。
＄Ｂｉｎが、ビンＢ１、Ｂ２、Ｂ３、Ｂ４用に使用される。

図１５に移ると、生成元のオブジェクト・テンプレートから、エンジンおよびプラットフォームのオブジェクトのソース描き出したハードウェア派生ビューが示されている。こうしたビューは、特定のエンジンおよび／またはプラットフォーム要件をもつエリアをどこに分散し、または再配置するかを決める際に有益である。ノード１５００は、ＷＩＮＤＯＷＳ（登録商標）オペレーティング・システム・ベースのプラットフォーム・テンプレートに対応する。ＷＩＮＤＯＷＳ（登録商標）オペレーティング・システム・ベースのプラットフォーム・テンプレートから派生したプラットフォーム・オブジェクトに相当する１組のプラットフォーム・インスタンスが、ノード１５００から枝分れしており、これらは、図１内で識別されるパーソナル・コンピュータの各々に対応する。ノード１５１０は、アプリケーション・エンジン・テンプレートに対応する。アプリケーション・エンジン・テンプレートから派生する１組のアプリケーション・エンジン・インスタンスが、ノード１５１０から枝分れしており、これらは、図１に描かれたアプリケーション・エンジンに対応する。ノード１５２０は、ビューエンジン・テンプレートに対応する。１組のビューエンジン・インスタンスが、ノード１５２０から枝分れしており、これらは、図１に描かれたビュー・エンジンに対応する。ノード１５３０は、ＰＬＣＮｅｔｗｏｒｋ装置統合オブジェクト・テンプレートに対応する。ノード１５３０から派生する１組のインスタンスは、図１内で識別される、ＯＰＣサーバ１１６、１１８の構成をサポートする装置統合オブジェクトに対応する。最後に、ノード１５４０は、ＰＬＣＯｂｊｅｃｔ装置統合オブジェクト・テンプレートに対応する。ノード１５４０から派生する１組のインスタンスは、図１内で識別される装置統合オブジェクトに対応する。

図１６には、図１０および図１１に描かれたプロセス・アプリケーションのモデル・ビューが示されている。このモデル・ビューは、（アプリケーション・オブジェクトとエリアを含む）オブジェクトが指定する、エリア・ホスティングおよび包含関係を表示する。このモデル・ビューは、プラント・レイアウトを記述するために論理的にグループにまとめられたオブジェクトを識別する。このモデル・ビューは、ユーザがオブジェクトを速やかに指定することを可能にし、それによって、オブジェクトは特定の方針（たとえば、警報することなど）に従って一様に扱われるようになる。このモデル・ビューは、たとえば、図１１で指定されるノードで、図１２のエリアのツリー構造に描かれたエリアに対応するノードを含む。ツリー１６００の各リーフ（葉）は、アプリケーション・オブジェクトと、それらの識別されたエリアへ割り当てを識別する。さらに、このモデル・ビューのツリーは、（図１３を参照して先に論じた）＄ＭｉｘｅｒＶｅｓｓｅｌコンパウンド・テンプレートからインスタンス化された１組のコンパウンド・コンテナ・オブジェクトＭＶ１、ＭＶ２などのコンパウンド・コンテナが描かれている。

このモデル・ビューは、ある特定のアプリケーションの下で指定された、オブジェクトのＡｒｅａおよびＣｏｎｔａｉｎｅｒアトリビュートに基いて、モデル・ビュー・ジェネレータによって描かれる。本発明の一実施形態では、エリア／コンテナとグループ化された／包含されたオブジェクトとの適合性は、ユーザが関連付け（association）を生成しようとする際に確定される。この適合性は、親オブジェクトがサポートする機能を、グループ化された／包含された子オブジェクトの要求（needs）と比較することによって確定される。さらに、本発明の一実施形態では、あるコンテナに含まれるすべてのオブジェクトには、同じエリアを指定する必要がある。

エリアは階層をもつことができる。したがって、あるエリアは別のエリアを含むことができ、親エリアは、サブ・エリア内のすべてのオブジェクトのために、警報統計データを収集する。図１６に示すモデル・ビューの階層ツリー構造は、ツリー構造の最上位レベルから始まり、あるエリア・オブジェクトのためのエリアが指定されていない場合、そのエリア・オブジェクト（たとえば、ＰｒｏｃｅｓｓＰｌａｎｔ１６０２）は直接ルート・ノード（ツリーの最上位レベル）に接続される。次のレベルでは、ＰｒｏｃｅｓｓＰｌａｎｔ１６０２のサブ・エリア（すなわち、ＲａｗＭａｔｅｒｉａｌＳｔｏｒｅ１６０４、Ｐｒｏｄｕｃｔｉｏｎ１６０６、Ｄｉｓｔｒｉｂｕｔｉｏｎ１６０８、およびＦｉｎｉｓｈｅｄＰｒｏｄｕｃｔＳｔｏｒｅ１６１０）が、ＰｒｏｃｅｓｓＰｌａｎｔ１６０２ノードの枝として接続される。例示的なアプリケーション・モデル・ツリー１６００では、サブ・エリアから伸びる枝は、アプリケーション・オブジェクト（すなわち、ホッパＨ１、コンベヤＣ１〜Ｃ４、ドアＤ１〜Ｄ２、昇降機Ｅ１、およびビンＢ１〜Ｂ４）、および下位レベルのサブ・エリア（Ｐｒｏｄｕｃｔｉｏｎ１６０６サブ・エリア内のＬｉｎｅ１、Ｌｉｎｅ２）を含む。Ｌｉｎｅ１およびＬｉｎｅ２サブ・エリアは、コンパウンド（すなわち、ミキサ槽ＭＶ１、ＭＶ２）を含む。コンパウンドＭＶ１、ＭＶ２の葉は、コンパウンド・オブジェクトに含まれるオブジェクトを識別する。具体的な例では、ミキサ槽コンパウンドＭＶ１は、撹拌器Ａ１、槽Ｍ１、および入口弁Ｖ１を含む。ミキサ槽コンパウンドＭＶ２は、撹拌器Ａ２、槽Ｍ２、および入口弁Ｖ２を含む。

図１７には、アプリケーション・モデルのエリアを図１に示すハードウェアおよびプラットフォームに展開した、例示的な展開ビューが示されている。この展開ビューは、アプリケーションのさまざまなオブジェクトをどこで実行するかを視覚的に表している。したがって、展開ビューは、オブジェクトが指定するホスティング（アトリビュート３３８）および包含（アトリビュート３３０）関係に基いて描かれる。子エリア・オブジェクトを、指定された親エリア（アトリビュート３２８）と同じアプリケーション・エンジン上で実行する必要はなく、オブジェクトが指定するエリア関係は、展開ビューを描く際には適用されない。アプリケーション・オブジェクトは、そのエリアにホストされ（アトリビュート３３８）、したがって、展開ビューには、アプリケーション・オブジェクトとそのエリアとの関係が示される。したがって、展開ビュー（およびネストしたエリア・オブジェクトの実際の展開）は、エリア・オブジェクト間の指定された階層エリアのモデル関係に関連付けられた警報／イベントの集中および伝播を反映していない。

図１７には、アプリケーション・オブジェクトは表示されていない。しかし、展開ビュー・ジェネレータは、それらのオブジェクト内のホスト／コンテナ指定に基いて、適切なエリアの下にアプリケーション・オブジェクトを配置する。本発明の一実施形態では、アプリケーション・オブジェクトの指定されたホストおよびエリアは、要件から同一になる。したがって、エリア・オブジェクトを参照するすべてのアプリケーション・オブジェクトは、エリア・オブジェクトのＨｏｓｔアトリビュート３３８で識別されるのと同一のエンジン・オブジェクト上で実行される。この要件は、特定のエリアに属するアプリケーション・オブジェクト用に管理する警報およびデータを、同一のコンピュータ装置上で局所的に管理することを可能にする。アプリケーション・オブジェクトが、アトリビュート３３０でコンテナ（コンパウンド・アプリケーション・オブジェクト）を指定している場合、展開ビュー・ツリーを生成する際、指名されたエリア・ホストを指名されたコンテナで置き換える（すなわち、コンパウンド（コンテナ）内のアプリケーション・オブジェクトを、指定されたコンパウンド名の下に置く）。しかし、本発明の一実施形態では、コンパウンド内に含まれるすべてのアプリケーション・オブジェクトを、同一のホスト上で実行する必要はない（すなわち、包含されるすべてのアプリケーション・オブジェクトは、コンパウンド／コンテナの指定されたエリアを獲得する）。

エリアおよびそれに関連するオブジェクトは、プラットフォーム／アプリケーション・エンジンのどのような組合せによっても実行させることができるので、図１７に示す展開ビューは、例として特に適切にクラス分けされている。プラットフォーム／エンジン／エリア／アプリケーション・オブジェクトから成る多重レイヤのホスティング構成は、図１７に示すアプリケーション・コンポーネントについてのグラフィカルな展開表現における適切なホスト・エンジンのブランチ（枝）に、さまざまなエリア（およびそれに関連するアプリケーション・オブジェクト）をインストールできるようにする。展開ツリー階層の最上位レベルは、図１に示すパーソナル・コンピュータに対応する１組のプラットフォームを識別する。ノードによって表される１組のプラットフォームには、ＲａｗＭａｔｅｒｉａｌＰＣノード１７００、Ｐｒｏｄｕｃｔｉｏｎ ＰＣノード１７０２、ＦｉｎｉｓｈｅｄＰｒｏｄｕｃｔＰＣノード１７０４、ＣｏｎｆｉｇｕｒａｔｉｏｎＰＣノード１７０６、ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ１ＰＣノード１７０８、ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ２ＰＣノード１７１０が含まれる。

１組のエンジン（複数のエンジンの集合）がプラットフォーム・ホストに展開される。展開された１組のエンジン・オブジェクト・ノードは、示されたプラットフォーム・オブジェクトにホストされるエンジン・オブジェクトに対応し、これには、ＲａｗＭａｔｅｒｉａｌＶｉｅｗエンジン・ノード１７１２、ＰｒｏｄｕｃｔｉｏｎＶｉｅｗ エンジン・ノード１７１４、ＦｉｎｉｓｈｅｄＰｒｏｄｕｃｔＶｉｅｗエンジン・ノード１７１６、ＡｐｐＥｎｇｉｎｅ１ノード１７１８、ＡｐｐＥｎｇｉｎｅ２ノード１７２０が含まれる。

これらのエンジンは、展開ビュー内にノードとして表される、装置統合オブジェクト、およびアプリケーション・オブジェクトのエリア・グループにホストする。展開された装置統合オブジェクトに対応する１組の装置統合オブジェクト・ノードには、ＰＬＣ１Ｅｔｈｅｒｎｅｔ（登録商標）ノード１７２２、ＰＬＣ１ノード１７２４、ＰＬＣ２Ｅｔｈｅｒｎｅｔ（登録商標）ノード１７２６、ＰＬＣ２ノード１７２８が含まれる。アプリケーション・オブジェクトおよび／または他のエリアのグループを含む展開されたエリアに対応する１組のエリア・オブジェクト・ノードには、ＰｒｏｃｅｓｓＰｌａｎｔノード１７３０、ＲａｗＭａｔｅｒｉａｌＳｔｏｒｅノード１７３２、Ｐｒｏｄｕｃｔｉｏｎノード１７３４、Ｌｉｎｅ１ノード１７３６、Ｌｉｎｅ２ノード１７３８、Ｄｉｓｔｒｉｂｕｔｉｏｎノード１７４０、ＦｉｎｉｓｈｅｄＰｒｏｄｕｃｔＳｔｏｒｅノード１７４２が含まれる。上で識別したエリア・ノードをそれに関連するエンジンに接続するブランチ（枝）は、そのエリア・オブジェクトおよびそれに関連するアプリケーション・オブジェクトのＨｏｓｔアトリビュート３３８で識別される各エンジンに対応するが、いたずらに複雑となるのを避けるため、図１７に示す展開ビューでは省略してある。

本発明の例示的な実施形態およびその変形を、図面および付随の説明によって提供した。本発明は、これらの実施形態に限定されるものではない。監視プロセス制御／製造情報アプリケーションを構成し実施するための新しい有用な方法およびアプリケーションを説明してきたことが、当業者には理解されよう。本発明の原理が適用できる多くの可能な環境、およびソフトウェアベースのシステムを設計し実施する上での柔軟性に鑑みて、本明細書で説明した実施形態は例示的なものであり、本発明の範囲を限定するものと捉えるべきではないことを理解されたい。本発明の主旨から逸脱することなく、例示的な実施形態にその構成および詳細について変更を施し得ることが、本発明が適用される分野の当業者には理解されよう。本発明は、開示された実施形態のみならず、本開示および本明細書に添付した特許請求の範囲で規定される発明に照らして許容可能な最も広い範囲において本発明の範囲および主旨に収まるその他の実施形態を包含するものである。したがって、本明細書で説明した本発明は、添付の特許請求の範囲およびその均等物の範囲に収まり得るそうしたすべての実施形態を企図するものである。

多重レイヤ化された監視プロセス制御／製造情報アプリケーションを含む例示的な監視プロセス制御ネットワークの概略図である。 アプリケーションの多重に階層化されたオブジェクト構成を示す図である。 アプリケーションを構成する複数のオブジェクトの共通部分に関連付けられる１組のアトリビュートを示す図である。 プラットフォーム・オブジェクトのプラットフォーム固有部分に関連付けられる１組のアトリビュートを示す図である。 エンジン・オブジェクトに関連付けられる１組のアトリビュートを示す図である。 スケジューラ・オブジェクトに関連付けられる１組のアトリビュートを示す図である。 例示的なアプリケーション・オブジェクトに関連付けられる１組のアトリビュートを示す図である。 本発明を実施する多重レイヤ化されたアプリケーションを開始させるために実行する１組のステップを要約して示すシーケンス図である。 複数のアプリケーション・エンジンを備えるネットワーク内でオブジェクトを別のエンジンに移動するための１組のステップを要約して示すシーケンス図である。 単純なプラント・プロセス内の制御される構成要素を示す概略図である。 単純なプラント・プロセス内の構成要素が論理的にエリアにグループ分けされた様子を示す概略図である。 図１１のプラント構成におけるエリアのグループを示す階層ツリー構造図である。 図１０のプラント・プロセスに関連付けられた監視プロセス制御アプリケーションのオブジェクト間の派生関係を表す階層ツリー構造図である。 図１０のプラント・プロセスのミキサ槽の一部を示す概略図である。 図１４ａのミキサ槽に対応するＭｉｘｅｒＶｅｓｓｅｌコンパウンド・アプリケーション・オブジェクト・テンプレートの包含関係を表す階層モデル・ビューである。 システムのハードウェア（たとえば、プラットフォーム、エンジン、装置統合オブジェクト）に関連するアプリケーションの一部の派生構造を表す階層ツリー構造図である。 アプリケーション・オブジェクトが関連づけられるエリアを含むアプリケーション・オブジェクト構成のモデル・ビューを示す階層ツリー構造図である。 階層のトップレベルで識別されるプラットフォーム・オブジェクトで表される１組のコンピュータ装置にアプリケーションを展開した、展開ビューを示す階層ツリー構造図である。

符号の説明

１００ 第１のアプリケーション・サーバ用パーソナル・コンピュータ（ＰＣ）
１０２ 第２のアプリケーション・サーバ用ＰＣ
１０４、１０６ アプリケーション部分
１０５、１０７ アプリケーション・オブジェクト
１０８、１１０ 汎用的なブートストラップ・コンポーネント
１１２ 第１のプログラマブル・ロジック・コントローラ
１１４ 第２のプログラマブル・ロジック・コントローラ
１１６、１１８ ＯＰＣ ＤＡＳｅｒｖｅｒ
１２０ 構成パーソナル・コンピュータ
１２２ データベース・サーバ
１２４ 監視プロセス制御／管理情報アプリケーションの構成データベース
１２５ グローバル名前テーブル
１２６ 構成ＰＣプラットフォーム
１２７ 統合開発環境（ＩＤＥ）
１３０、１３２、１３４ 操作者ステーション
２００ オペレーティング・システム
２０２ ブートストラップ・オブジェクト
２０４ プラットフォーム・クラス・オブジェクト
２０６ エンジン・オブジェクト
２０８ スケジューラ
２１０ アプリケーション・オブジェクト
１０００ ホッパ
１００２、１０２０、１０２４ コンベア
１００４、１００６ ミキサ
１００８、１０１０ 攪拌機
１０１６、１０１８ ホッパ
１０２６ 分配コンベア
１０２８，１０３０ 状態ドア
１０３２，１０３４，１０３６，２０３８ ビン
１１００ 原料貯蔵エリア
１１０２ 生産エリア
１１０４ ライン１エリア
１１０６ ライン２エリア
１１０８ 配送エリア
１１１０ 完成品貯蔵エリア
１１２０ プロセス・プラント・エリア

Claims (9)

1. ネットワーク接続された複数のコンピュータ装置に分散可能な、階層アーキテクチャを有する監視プロセス制御／製造情報システム・アプリケーションであって、
   プロセス制御システム内の複数のエンティティをモデル化した複数のアプリケーション・オブジェクトと、
   ランタイム環境で前記複数のアプリケーション・オブジェクトの実行をホストする複数のエンジン・オブジェクトと、
   前記複数のエンジン・オブジェクトと関連する複数のアプリケーション・オブジェクトとを実行するための物理コンピュータ・システムに対応し、１つまたは複数の前記エンジン・オブジェクトをホストするプラットフォーム・オブジェクトと
   を備えることを特徴とするアプリケーション。
2. 前記複数のエンジン・オブジェクトと前記複数のプラットフォーム・オブジェクトは、前記アプリケーションがその上で実行する物理コンピューティング装置構成に関する前記アプリケーションの局面を処理し、前記アプリケーション・オブジェクトは、前記物理コンピューティング装置構成とは独立に実行することを特徴とする請求項１に記載のアプリケーション。
3. 同一コンピューティング装置上の前記複数のアプリケーション・オブジェクトは前記複数のエンジン・オブジェクトを介して通信を行い、コンピューティング装置のネットワーク全体にわたる通信は前記複数のプラットフォーム・オブジェクトによってサポートされ、それによって、前記複数のアプリケーション・オブジェクト間の通信を前記複数のアプリケーション・オブジェクトがその中で実行するコンピュータ・システムのトポロジから分離することを特徴とする請求項１に記載のアプリケーション。
4. 監視プロセス制御／製造情報アプリケーションの展開モデル（deployment model）を指定して、アプリケーション・オブジェクトを特定の複数の物理コンピューティング装置に関連付け、前記物理コンピューティング装置上の前記オブジェクトについての分散ビューを提供する、構成ファシリティであって、
   前記１つまたは複数の物理コンピューティング装置のタイプを指定するプラットフォーム定義と、
   前記物理コンピューティング・システム上で実行する複数のエンジンを指定し、それによって前記物理コンピューティング装置によってサポートされるサービスのタイプを定める、エンジン定義と、
   前記複数のアプリケーション・オブジェクトについての論理グループを備えるエリアを指定するエリア定義と、
   前記物理コンピューティング・システムのうち特定のものへの前記エンジンの割り当てと、前記エンジンのうち特定のものへの前記エリアの割り当てとを指定する１組の階層関係と、
   前記１組の階層関係に従って、前記物理コンピューティング装置、前記エンジン、および前記エリアの階層を描く展開ビュー・ジェネレータと
   を備えることを特徴とする構成ファシリティ。
5. 特定のビューに従って展開されたコンポーネントを含み、プロセス制御／製造情報ソフトウェアの構成および展開を容易にする、監視プロセス制御／製造情報システム・アプリケーション構成ファシリティであって、
   プラント内の個々のエンティティに対応する装置／機能に対応する監視プロセス制御システム・オブジェクトであって、前記装置／機能に関連する機能性は前記各オブジェクトに含まれ、監視プロセス制御システム・オブジェクトに関連付けられ、当該監視プロセス制御システム・オブジェクト間の関係を指定する１組のアトリビュートを有する監視プロセス制御システム・オブジェクトと、
   前記監視プロセス制御システム・オブジェクト間の結合関係に従って、前記監視プロセス制御システム・オブジェクトを描くビュー・ジェネレータであって、少なくとも
   プロセス／プラントおよびその監視される構成要素の論理構成を表す第１のビューと、
   前記アプリケーションを実施するコンピュータ・システム上での複数のオブジェクトについての物理展開を表す第２のビューと
   を提供するビュー・ジェネレータと
   を備えることを特徴とする構成ファシリティ。
6. ユーザが１組のエリアを定義し、当該各エリアは同一エンジン上で実行するように制限された関連する１組のアプリケーション・オブジェクトを含み、前記エリアと前記エンジンの間の結合関係は前記第２のビューで描かれることを特徴とする請求項５に記載の構成ファシリティ。
7. 前記監視プロセス制御システム・オブジェクトは、その内部にネストされた他の監視プロセス制御システム・オブジェクトを含むコンテナ・オブジェクトを備えることを特徴とする請求項５に記載の構成ファシリティ。
8. 前記監視プロセス制御システム・オブジェクトはテンプレートから派生／インスタンス化され、前記テンプレートは、他のテンプレートの包含を指定することを特徴とする請求項５に記載の構成ファシリティ。
9. 前記テンプレートは、親テンプレートを指定することができ、そこから前記テンプレートが、子テンプレートを指定した後で親テンプレートに加えられた変更を含めて、特性を継承することを特徴とする請求項８に記載の構成ファシリティ。

Images