実行時アプリケーションに情報を結合する方法およびグラフィックユーザインタフェースを更新する方法
【課題】実行時アプリケーションに情報を結合する。
【解決手段】
実行時アプリケーションと関連するデータコンテキストをリソースマネージャに提供し、変数、スクリプト、またはデータソース参照の内の少なくとも１つと、該データコンテキストからの少なくとも１つのプロキシを、該リソースマネージャを介して関連付け、該変数、該スクリプト、または該データソースの内の該少なくとも１つに該少なくとも１つの特性を結合する。該データソース基準に該少なくとも１つの特性を結合するためにコンテキストオブジェクトを使用してもよい。
【解決手段】
実行時アプリケーションと関連するデータコンテキストをリソースマネージャに提供し、変数、スクリプト、またはデータソース参照の内の少なくとも１つと、該データコンテキストからの少なくとも１つのプロキシを、該リソースマネージャを介して関連付け、該変数、該スクリプト、または該データソースの内の該少なくとも１つに該少なくとも１つの特性を結合する。該データソース基準に該少なくとも１つの特性を結合するためにコンテキストオブジェクトを使用してもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概してプロセス制御システムに関し、より詳細にはプロセス制御システムのためのサービス指向型アーキテクチャに関する。
【背景技術】
【０００２】
化学関連プロセス、石油関連プロセスまたは他のプロセスで使用されるシステム等のプロセス制御システムは、通常、アナログバス、デジタルバス、またはアナログ／デジタル結合バスを介して少なくとも１つのホストワークステーションまたはオペレータワークステーションに、および1台以上のフィールドデバイスに通信可能に結合されている１台以
上のプロセスコントローラおよび入力／出力（Ｉ／Ｏ）装置を含む。例えば、バルブ、バルブポジショナ、スイッチおよび送信機（例えば、温度センサ、圧力センサ、および流量センサ）であってよいフィールドデバイスは、バルブの開閉およびプロセスパラメータの測定等のプロセス機能を実行する。プロセスコントローラは、フィールドデバイスにより行われるプロセス測定、および／またはフィールドデバイスに関する他の情報を示す信号を受信し、制御ルーチンを実現するためにこの情報を使用し、次にプロセスの動作を制御するためにフィールドデバイスにバスまたは他の通信回線上で送信される制御信号を発生させる。このように、プロセスコントローラは、フィールドデバイスを通信可能に結合するバスおよび／または他の通信リンクを介してフィールドデバイスを使用して制御戦略を実行し、調整してよい。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第２００４／００７５６８９号明細書
【特許文献２】米国特許出願公開第２００４／０１５３８０４号明細書
【特許文献３】米国特許出願公開第２００４／０１９９９２５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
フィールドデバイスおよびコントローラからの情報は、オペレータが、プロセスの現状を見る、プロセスを評価する、プロセスの動作を修正する等のプロセスに関して所望の機能を実行可能とするために（例えばプロセッサベースのシステム等の）オペレータワークステーションによって実行される１つ以上のアプリケーション（つまり、ソフトウェアルーチン、プログラム等）が利用できてよい。多くのプロセス制御システムは１つ以上のアプリケーションステーションも含む。通常、これらのアプリケーションステーションは、コントローラ、オペレータワークステーションおよびローカルエリアネットワーク（ＬＡＮ）を介してプロセス制御システム内の他のシステムに通信可能に結合されるパーソナルコンピュータ、ワークステーション等を使用して実現される。各アプリケーションステーションは、プロセス制御システムの中でキャンペーン管理機能、保守管理機能、バーチャル制御機能、診断機能、リアルタイム監視機能、安全性関連機能、構成機能等を実行する１つ以上のソフトウェアアプリケーションを実行してよい。
【０００５】
多くのプロセス制御システムの多様なアプリケーションを実現するために使用されるソフトウェア要素（例えばプログラム）は、通常、オブジェクト指向型のプログラミング技術およびアーキテクチャの使用に大幅に依存している。このようなオブジェクト指向型プログラミングの技術とアーキテクチャは、より高いレベル（例えばより複雑な）ソフトウェアオブジェクトが１つ以上のより低いレベルのオブジェクトから構築され、したがって１つ以上のより低いレベルのオブジェクトの特性（プロパティ）を継承するソフトウェアオブジェクトの階層配列に基づいている。これらのオブジェクト指向型プログラミング内での継承を多用することは高度のコード（つまりソフトウェア命令、プログラム等）の共用を可能にし、制御システムを実現するために必要とされるコードまたはソフトウェアの総合的な量を大幅に削減する傾向がある。
【０００６】
公知のオブジェクト指向型プログラミングは、相対的に複雑なプロセス制御システムを実現するために必要とされるソフトウェアまたはコードの量を有利に削減できるが、これらの構成に関連する高度な継承またはコード共用は、制御システムを構成する多様なソフトウェアルーチンまたは構成要素間の高度な依存状態（例えばデータ依存）を生じさせる。その結果、これらの多様なソフトウェアルーチンの独立した開発および／またはバージョニングが困難であるかまたは不可能である場合がある。例えば、前述されたオブジェクト指向型の構成では、プロセス制御システムアプリケーション（例えばプロセス監視アプリケーション）、データベースサービス、および実行時サービスを利用するいくつかのプロセス制御システムは強固に結合している（つまり互いに対してかなり依存している）。特にクライアントアプリケーションはデータベース内のデータを表すデータ構成要素の共通したセット上に構築されてよい。したがって、共通データ構成要素の変更は、クライアントアプリケーションを再構築することを必要とする。その結果、特にプロセス制御システムの異なるソフトウェア構成要素が異なるロケーション（開発サイトまたはセンタ）で開発される場合、公知のオブジェクト指向型プロセス制御ソフトウェアアーキテクチャに固有のデータ依存により、データベース構成要素および実行時ソフトウェア構成要素の独立したバージョニングまたは開発は非常に困難または不可能になる。これらの公知のオブジェクト指向型アーキテクチャに固有のデータ依存に対処するために、プロセスソフトウェア開発者はデータベース構成要素、実行時構成要素、およびシステムソフトウェア構成要素の開発を、これらの構成要素が統一して構築され、リリースされるように調整することを余儀なくされてきた。
【課題を解決するための手段】
【０００７】
一例では、プロセス制御システムにおけるクライアントプロセスとサーバプロセス間でプロセス制御情報を伝達するための方法および装置は、各々が対応するサービスインタフェースを有する複数のプロセス制御サービスを含むサーバプロセスを確立する。この方法および装置の例では、クライアントプロセスが通信接続を確立する複数のサービスの各々にプロキシを有するクライアントプロセスも確立する。さらに、この方法および装置の例では、クライアントプロセスとサーバプロセス間のプロセス制御情報の伝達を可能にするためにクライアントプロセスへのサービスインタフェースと関連付けられた端点情報（ｅｎｄ ｐｏｉｎｔ）（例えばポート情報、ＵＲＬ、ＵＲＩ等）を提供する。
【０００８】
別の例では、ルーチンアプリケーションに情報を結び付ける方法は、リソースマネージャに実行時アプリケーションと関連するデータコンテキストを提供し、リソースマネージャを介してデータコンテキストからの少なくとも１つの特性を、変数、スクリプトまたはデータソース基準の内の少なくとも１つと関連付ける。さらに、該方法は変数、スクリプトまたはデータソース基準の内の該少なくとも１つに該少なくとも１つの特性を結び付ける。
【図面の簡単な説明】
【０００９】
【図１】本明細書に説明されるサービス指向型アーキテクチャを使用するプロセス制御システム例のブロック図である。
【図２】図１のプロセス制御システム例の中で使用されてよいサービス指向型アーキテクチャ例を描くブロック図である。
【図３】図２のアーキテクチャ例によって提供されるディスカバリサービスと実行時サーバとの間の関係性を描く図である。
【図４】図３のディスカバリサービスとそのホスト側サーバが図３のデータアクセスサービスとそのホスト側サーバと相互作動する1つの方法を描くフロー図である。
【図５】図３のディスカバリサービスがそれによってサービスを配置するプロセス例である。
【図６】セッションサービスのインプリメンテーション例を描く図である。
【図７】図３の実行時サーバ例によって提供されてよい実行時サービスのより詳細な線図である。
【図８】図６のデータベースサーバによって提供されてよいデータベースサービス例のより詳細な線図である。
【図９】図６のバージョン制御サーバ、バージョンサーバおよびデータベースサーバが相互作動する方法の例を描く図である。
【図１０】複数の履歴サービスを提供してよい履歴サーバ例の線図である。
【図１１】履歴スキャナサーバ例と、履歴スキャナサーバがいかにして図７の実行時サービス例と図１０の履歴サービス例と相互作動してよいのかを描く図である。
【図１２】本明細書に説明されているサービス指向型アーキテクチャ例を実現するために使用されてよいアラームおよびイベントサーバ例を描く。
【図１３】本明細書に説明されているサービス指向型アーキテクチャ例を実現するために使用されてよいＯＰＣデータサーバ例を描く。
【図１４】本明細書に説明されているサービス指向型アーキテクチャ例がデータサービスまたはソースに、クライアントアプリケーションと関連する実行時プロセスをリンクする、または結び付けるために使用されてよい１つの方法の例を描く。
【図１５】ユーザインタフェースがデータサービスまたはソースとリンク、あるいは結び付けられてよい１つの方法のより詳細な例を描く。
【図１６】本明細書に説明されている装置および方法を実現するために使用されてよいプロセッサシステム例を描く。
【発明を実施するための形態】
【００１０】
一般的に、本明細書に説明されている装置、方法および製品の例では、プロセス制御システムを構成する多様なソフトウェア要素（例えば、プログラム、アプリケーション、サービス等）間の高い独立性を提供するためにプロセス制御システム内で使用されてよい。より詳細には、本明細書に説明されている例は、複数の独立したプロセス制御関連アプリケーションがその上に層化している、複数の緩やかに結合された（つまり、実質的にデータから独立している）コアサービスを提供するソフトウェアおよびハードウェアのアーキテクチャを利用する。コアサービスの各々は個別にテストし、バージョニングできる良く定義された外部インタフェース（例えば、スキーマ、サービスに及び／又はサービスから渡されるパラメータ、データフォーマット等）を提供する。同様に、プロセス制御関連のアプリケーションは、アプリケーションの実質的にデータから独立した性質のために高度に独立した方法で（異なる開発チーム、場所等の間で最小の調整を行い、またはほとんど調整を行わずに）構築または開発できる。言い換えると、全体的なプロセス制御システムの中で使用するためにある特定のアプリケーションを開発している、ある場所にいるソフトウェア開発者は、別の物理的な場所にいるソフトウェア開発者の別のグループによって開発されている別のアプリケーションの開発に必ずしも密接に関係する、あるいは通知される必要はない。このように、本明細書に説明されているサービス指向型アーキテクチャ例は、別のソフトウェア開発チームが彼ら各々の開発作業を（例えば、会議および／または他の形の通信を介して）調整する多大な量の時間を費やす必要性を最小限に抑えるまたは排除し、それにより各々の開発作業のための開発時間と費用を大幅に削減する。
【００１１】
コードまたはソフトウェア再利用に焦点を当てた多くの公知のオブジェクト指向型インプリメンテーションまたはアーキテクチャとは対照的に、本明細書に説明されているサービス指向型制御アーキテクチャ例はデータサービスおよび／またはクライアントアプリケーション間の比較的に緩やかな結合（例えば、存在するとしても、比較的に少ないデータ依存）であることを強調する。さらに、公知のオブジェクト指向型インプリメンテーションを用いると、プロセス制御ソフトウェアアプリケーションまたはプログラムは、本来、共用されるクラスライブラリから引き出されるソフトウェア要素の構成または配列である。対照的に、本明細書に説明されているサービス指向型アーキテクチャ例は、相対的に自律したサービスから構成されるアプリケーションを活用する。より詳細には、本明細書に説明されているサービス志向型アーキテクチャ例と関連する相対的に自律したサービスは、クラス情報を共用するよりむしろ、（構造のための）スキーマと（動作のための）コントラクトを共用する。本明細書に説明されている相対的に自律したサービス（例えばデータサービス）の各々は、サービスが送受できるメッセージの構造を説明する（例えば、ＸＭＬ等の拡張可能マークアップ言語を使用して）コントラクトを確立する。
【００１２】
またさらに、公知のオブジェクト指向型プロセス制御ソフトウェアインプリメンテーションは、ソフトウェア要素または構成要素（例えばサービス）と開発者（異なる開発現場のソフトウェア開発者）間の通信を、（処理効率の観点から）安価かつ暗示的に処理する。対照的に、本明細書に説明されているサービス指向型アーキテクチャ例はこのような通信を相対的に高価かつ明示的に処理する。したがって、本明細書に説明されているサービス指向型アーキテクチャ例は、サービス全体で（つまり、プロセス制御ソフトウェアのコアサービスを構成する多様なソフトウェア構成要素と関連するサービス境界全体で）共用されなければならない抽出数および抽出の複雑性を削減するように構成される。
【００１３】
さらに、アプリケーションの展開を一元的に（つまり、相互に関連のあるアプリケーションのグループの共通のリリース）処理する公知のオブジェクト指向型インプリメンテーションとは対照的に、本明細書に説明されているサービス指向型プロセス制御ソフトウェアアーキテクチャ例は継続的なより不連続な方法でアプリケーション展開を処理する。例えば、本明細書に説明されているサービス指向型アーキテクチャ例を使用すると、クライアントアプリケーションは全体的なシステムおよびアプリケーションの集合的な状態が経時的に混合されるようにそれらのアプリケーションにより使用される根本的なデータサービスとは独立してバージョンニングされてよい。例えば、いくつかの場合、サービスは、該サービスを利用するアプリケーションが展開されるよりも十分に前に展開されてよい。さらに、アプリケーションとサービスが実質的に独立していることにより、サービスおよび／またはアプリケーションは経時的に異なる速度で独立して進化できる（つまり、無関係に開発または修正できる）。しかしながら、本明細書に説明されているサービス指向型アーキテクチャまたはフレームワークの例で活用される相対的に高度に切り離されたサービスおよび／またはアプリケーションの相互作動におけるさらに高い完全度を保証するために、各サービスはそれが別のサービスまたはアプリケーションから受信する各メッセージでバリデーションプロセスを実行するように構成されてよい。
【００１４】
本明細書にさらに詳しく説明されるように、サービス指向型アーキテクチャ例は、変数、実行可能スクリプト、および／または前述されたデータサービスに実行時アプリケーションを関連するパラメータのリンケージ、結合、またはさらに一般的には通信結合または動作結合を可能にするために有利に適用されてよい。例えば、プロセス制御システムユーザインタフェースアプリケーションと関連するレンダリンググラフィックディスプレイ要素と関連して使用されるパラメータは、実行時データサービスに通信可能にまたは操作で結合されてよい。この例では、パラメータに結合されるデータの変更は、変更されたデータを反映するために例えばグラフィックディスプレイを更新できる表示アプリケーションにデータサービスから自動的に伝搬できる。あるインプリメンテーションでは、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）により提供されている周知のアバロン（Ａｖａｌｏｎ）ソフトウェアプラットフォームとインティゴ（Ｉｎｄｉｇｏ）ソフトウェアプラットフォームが、実行時における変数、スクリプト、および／またはデータサービスに対するディスプレイエンティティに関連する特性の結合を可能にするために使用されてよい。しかしながら、アバロン（Ａｖａｌｏｎ）および／またはインディゴ（Ｉｎｄｉｇｏ）の代わりに任意の他の適切なソフトウェアプラットフォームが使用できるであろう。
【００１５】
より詳細に後述されるように、本明細書に説明されているサービス指向型アーキテクチャ例は、プロセス制御関連のデータをデータソース層に提供できるデータサービス層を含む。後述されるように、データソース層はアプリケーションの中からデータサービス層へ相対的に一般的なアクセスを提供する。データソース層上で層化されているリソースマネージャは、変数、スクリプトおよび／または参照を１つ以上の実行時アプリケーション、ディスプレイ、グラフィック要素、パラメータ等と関連するデータソースの中に管理する。パラメータとこのような変数またはデータソースとの間の結合（複数の場合がある）を静的にコード化することとは対照的に、本明細書に説明されるリソースマネージャは、有利なことに、例えばグラフィックディスプレイ要素に関連するパラメータを、実行時に１つ以上の変数またはデータサービス（例えば、サーバを介して提供されるプロセス制御データソース）に結合できるようにする。
【００１６】
より詳細には、本明細書に説明される装置、方法および製品の例を用いると、ディスプレイアプリケーションはリソースマネージャからそのグラフィック要素と関連する多様な特性の値あるいは他のデータまたは情報を要求してよい。同様に、リソースマネージャは、ディスプレイアプリケーションにより使用される特性にデータソースを提供する（例えば、マッピングする、関連付ける、あるいはそれ以外の場合結び付ける）ように実行時には構成されてよい。その結果として、ディスプレイアプリケーションは、それらのグラフィック要素と関連するパラメータ値に結合される、そのグラフィック要素と変数またはデータソースとの間の関係性を定義するために静的にコード化される必要はない。代わりに、リソースマネージャはより柔軟かつ動的にそれらの関係性を定義するために実行時に構成できる。
【００１７】
図１は、本明細書に説明されているサービス指向型アーキテクチャ例を使用するプロセス制御システム例１０のブロック図である。図１に描かれているように、プロセス制御システム１０はコントローラ１６、オペレータステーション１８、アクティブアプリケーションステーション２０、およびスタンバイアプリケーションステーション２２を含み、そのすべては、バス、または一般的にアプリケーション制御ネットワーク（ＡＣＮ）と呼ばれているローカルエリアネットワーク（ＬＡＮ）を介して通信可能に結合されてよい。オペレータステーション１８とアプリケーションステーション２０と２２は、1つ以上のワ
ークステーション、あるいは他の適切なコンピュータシステムまたは処理装置を使用して実現されてよい。例えば、アプリケーションステーション２０と２２は、単一のプロセッサワークステーションまたはマルチプロセッサワークステーション等の、以下の図１６に示されるプロセッサシステム例１６０２と同様に単一のプロセッサパーソナルコンピュータを使用して実現できるであろう。さらに、ＬＡＮ２４は、所望の通信媒体およびプロトコルを使用して実現されてよい。例えば、ＬＡＮ２４は、周知であり、本明細書ではさらに詳しく説明しない、ハードワイヤードの、または無線イーサネット（登録商標）通信スキームに基づいてよい。しかしながら、当業者により容易に理解されるように、任意の他の適切な通信媒体およびプロトコルを使用できるであろう。さらに、単一のＬＡＮが示されているが、複数のＬＡＮおよびアプリケーションステーション２０と２２の中の適切な通信ハードウェアが、オペレータステーション１８、アプリケーションステーション２０と２２、およびコントローラ１６の間に冗長な通信パスを提供するために使用されてよい。
【００１８】
コントローラ１６は、デジタルデータバス３２および入力／出力（Ｉ／Ｏ）デバイス３４を介して複数のスマートフィールドデバイス２６、２８および３０に結合されてよい。スマートフィールドデバイス２６から３０は、Ｆｉｅｌｄｂｕｓに準拠するバルブ、アクチュエータ、センサ等であってよく、その場合にはスマートフィールドデバイス２６から３０は周知のＦｉｅｌｄｂｕｓプロトコルを使用してデジタルデータバス３２を介して通信する。言うまでもなく、他のタイプのスマートフィールドデバイスと通信プロトコルが代わりに使用できるであろう。例えば、スマートフィールドデバイス２６から３０は、代わりに周知のＰｒｏｆｉｂｕｓ通信プロトコルおよびＨＡＲＴ通信プロトコルを使用して、データバス３２を介して通信するＰｒｏｆｉｂｕｓまたはＨＡＲＴに準拠するデバイスとなるであろう。（Ｉ／Ｏデバイス３４に類似するまたは同一の）追加のＩ／Ｏデバイスは、Ｆｉｅｌｄｂｕｓデバイス、ＨＡＲＴデバイス等であってよいスマートフィールドデバイスの追加のグループがコントローラ１６と通信可能にきるようにするためにコントローラ１６に結合されてよい。
【００１９】
スマートフィールドデバイス２６から３０に加えて、１台以上の非スマートフィールドデバイス３６と３８がコントローラ１６に通信可能に結合されてよい。非スマートフィールドデバイス３６と３８は、例えば、各々のハードワイヤードリンク４０と４２を介してコントローラ１６と通信する従来の４−２０ミリアンペア（ｍＡ）または０−１０ボルト直流（ＶＤＣ）デバイスであってよい。
【００２０】
コントローラ１６は、例えば、エマーソンプロセスマネジメント、ＬＬＬＰより販売されているＤｅｌｔａ（商標）コントローラであってよい。しかしながら、他のコントローラが代わりに使用できるであろう。さらに、図１には１台だけしかコントローラが図示されていないが、所望のタイプのまたはタイプの組み合せの追加のコントローラがＬＡＮ２４に結合できるであろう。コントローラ１６は、プロセス制御システム１０と関連する１つ以上のプロセス制御ルーチンを実行してよい。このようなプロセス制御ルーチンは、オペレータステーション１８を使用してシステムエンジニアまたは他のシステムオペレータによって生成され、コントローラ１６にダウンロードされ、コントローラ１６内でインスタンスを作成されてよい。
【００２１】
図１に説明されているように、プロセス制御システム例１０は、通信リンク４６とＬＡＮ４８を介してアプリケーションステーション２０と２２に通信可能に結合されるリモートオペレータステーション４４も含んでよい。リモートオペレータステーション４４は地理的に遠く離れて配置されてよく、その場合、通信リンク４６は、必ずしもではないが好ましくは無線通信リンク、インターネットベースまたは他のパケット交換通信のネットワーク、電話回線（例えば、デジタル加入者回線）またはその任意の組み合わせである。
【００２２】
図１の例に描かれているように、アクティブアプリケーションステーション２０とスタンバイアプリケーションステーション２２はＬＡＮ２４を介して、および冗長リンク５０を介して通信可能に結合されている。冗長リンク５０は、アクティブアプリケーションステーション２０とスタンバイアプリケーションステーション２２との間の個別な専用の（つまり共用されていない）通信リンクであってよい。冗長リンク５０は、例えば専用のイーサネット（登録商標）リンク（例えば、互いに結合されているアプリケーションステーション２０と２２各々の専用のイーサネット（登録商標）カード）を使用して実現されてよい。しかしながら、他の例では、冗長リンク５０は、アプリケーションステーション２０と２２に通信可能に結合される、必ずしも両方とも専用ではないが、ＬＡＮ２４または冗長ＬＡＮ（図示されていない）を使用して実現できるであろう。
【００２３】
一般的に、アプリケーションステーション２０と２２は、冗長コンテキストを確立し、維持するために冗長リンク５０を介して連続的に、例外によって、または周期的に情報を交換する。冗長コンテキストによって、アクティブアプリケーションステーション２０とスタンバイアプリケーションステーション２２間の制御の円滑なまたはバンプレスなハンドオフまたは切り替えが可能になる。例えば、冗長コンテキストは、アクティブアプリケーションステーション２０の中のハードウェア故障またはソフトウェア故障に応えて、あるいはプロセス制御システム１０のシステムオペレータまたはユーザまたはクライアントアプリケーションからの命令に応えて、アクティブアプリケーションステーション２０からスタンバイアプリケーションステーション２２への制御ハンドオフまたは切り替えを実行できる。
【００２４】
図２は、図１のプロセス制御システム例１０の中で使用されてよいサービス指向型アーキテクチャまたは構造の例２００を描くブロック図である。図２に示されているように、サービス指向型アーキテクチャ例２００は、サーバ２０２とクライアント２０４を含む。サーバ２０２は複数のサービス２０６、２０８、および２１０または集合体を含み、その内のいくつかまたはすべては関連機能を実行してよい。サービス２０６、２０８、および２１０は、通信ポート２１８を介したクライアント２０４との通信を可能にする各々のインタフェース（例えば、公開されているパラメータの１つ以上のセット）２１２、２１４、および２１６を提供する。サービスインタフェース２１２，２１４および２１６は、実質的には本質的に汎用であるため、実質的には図１のプロセス制御システム例１０と関連する構成および／または実行時データベースに含まれるデータのために使用されるスキーマ（つまり、データフォーマット、プロトコル等）とは無関係である。結果として、サービスインタフェース２１２、２１４、および２１６は、新規サービス能力（例えば機能）がサービス２０６、２０８および２１０の内の１つ以上に追加される場合、修正（例えば更新）だけを必要とする。したがって、サービスインタフェース２１２、２１４および２１６は、新規に公開されたインタフェースを使用するデータオブジェクトがプロセス制御システム１０（図１）内での使用に追加されない限り変更される必要はない。
【００２５】
サーバ２０２は、例えば、図１のシステム例に示されているアプリケーションステーション２０と２２および／またはオペレータステーション１８と４４の内の１つ以上等のプロセッサベースのシステムで実行されるソフトウェアとして実現されてよい。言うまでもなく、サーバ２０２は、プロセス制御システム例１０（図１）に結合されている他のプロセッサベースのシステムまたはワークステーションを使用して実現されてよい。
【００２６】
クライアント２０４は、各々がサービス２０６、２０８および２１０の内の１つに対応する複数のサービスインタフェースプロキシ２２０、２２２および２２４を含む。クライアント２０４によって使用されるサービスインタフェースプロキシの数は、サーバ２０２によって提供されるサービスの数より少ない場合がある。言い換えると、クライアント２０４は好ましくは、それがアクセスを必要とするサービスのためにのみプロキシを作成する。したがって、クライアント２０４は、サーバ２０２によって提供されるサービス２０６、２０８、および２１０の内の１つ以上にアクセスする、あるいはそれらと対話するために必要に応じて１つ以上のプロキシを生成してよい。
【００２７】
サーバ２０２と同様に、クライアント２０４は、例えば、アプリケーションステーション２０と２２の内の１つ以上、および／またはオペレータステーション１８と４４の内の１つ以上等のプロセッサベースのシステムで実行されるソフトウェアとして実現されてよい。あるインプリメンテーション例では、クライアント２０４は、サーバ２０２によって提供される１つ以上のサービス２０６、２０８および２１０にアクセスするために、１つ以上のウェブブラウザフレームワーク（例えばインターネットエクスプローラ（Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ）等を活用してよい。しかしながら、他の所望のソフトウェアフレームワークは、このようなウェブブラウザフレームワークの代わりに、またはこのようなウェブブラウザフレームワークに加えて使用されてよい。さらに一般的に、クライアント２０４はプロセス制御システム例１０（図１）内の所望のアプリケーションを表してよい。したがって、クライアント２０４は、例えば構成アプリケーション、保守アプリケーション、監視アプリケーション、プロセス制御アプリケーション、および／または任意の他のアプリケーションまたはアプリケーションの組み合わせであってよい。図１４および図１５に関連してさらに詳しく後述されるように、クライアント２０４（つまり、クライアントアプリケーション（複数の場合がある））は、一人以上のシステムオペレータ、エンジニアおよび／または任意の他のユーザが構成動作、実行時等の間にプロセス制御データを見るおよび／または変更することが可能となるように表示機能（例えばグラフィックユーザインタフェース機能）を含んでよい。
【００２８】
図２のアーキテクチャ例２００は単一のクライアントと通信して単一のサーバを描いているが、所望の場合追加のサーバおよびクライアントが使用されてよい。例えば、いくつかのインプリメンテーションでは、クライアント２０４は、２台以上のサーバと通信し、２台以上のサーバと相互作動し、および／または２台以上のサーバの中でサービスにアクセスしてよい。同様に、これらのインプリメンテーションまたは他のインプリメンテーションでは、サーバ例２０２（または他の個々のサーバ）は、複数のクライアントと通信してよい、および／または相互作動してよい。さらに、クライアント２０４がそれらの通信のためにサーバとして別のシステムと機能と通信してよいことが理解されなければならない。同様に、サーバ２０２がクライアント２０４以外のシステムと通信する場合、それらの通信のためのクライアントとして機能してよい。さらに、サービス２０６、２０８および２１０はサーバ２０２内で実現されているものとして描かれているが、サービス２０６、２０８、および２１０の内の１つ以上はクライアント２０４で代わりに実現されてよい。
【００２９】
このように、図２のサービス指向型アプリケーション例２００を用いると、サービス２０６、２０８および２１０は、相互から、およびサービス２０６、２０８および２１０を利用する（例えば呼び出す）アプリケーションから実質的（例えばデータ依存性に関して）に切り離される。有利なことに、このような切り離しによりサービス２０６、２０８および２１０の各々と関連するソフトウェアは、クライアント２０４によって活用され、サービス２０６、２０８および２１０にアクセスするアプリケーション（複数の場合がある）を修正またはバージョニングする必要なく、無関係に修正またはバージョンニングすることができ、現場での使用のためにリリースできる。同様に、クライアント２０４に関連するアプリケーション（複数の場合がある）が各々のサービス２０６、２０８および２１０のインタフェース２１２、２１４および２１６を順守するまたは適合しないかぎり、クライアント２０４と関連するアプリケーション（複数の場合がある）は、サービス２０６、２０８、および２１０を修正またはバージョニングする必要なく、無関係に修正またはバージョニングしてよい。したがって、アプリケーションおよび／またはサービス２０６、２０８、２１０と関連するソフトウェアが生成される時点でこのような関係性を固定する（つまりデータ依存性を生じさせる）ことにより、クライアント２０４とサービス２０６、２０８および２１０の内の１つ以上との間の関係性を静的に定義する代わりに、図２のアーキテクチャ例２００はこのような関係性を実行時に動的に確立できるようにする。
【００３０】
以下にさらに詳しく説明されるように、サービス指向型アーキテクチャ例２００は、種々のコアサービスおよび機能を提供してよい。具体的には、アーキテクチャ例２００はプロセス制御システム例１０（図１）の中でサービスを登録し、配置するためのディスカバリサービスを提供してよい。アーキテクチャ例２００は、クライアント２０４と関連するアプリケーション、ローカル実行時情報およびリモート実行時情報にアクセスを提供するための実行時サービス、多様なプロセス制御データベースにアクセスするためのデータベースサービス、およびプロセス制御システム例１０（図１）内で使用されるサービスおよび／またはアプリケーションと関連するバージョンニング情報を記憶し、取り出すためのバージョン制御サービスの内の１つ以上の中にログし、またはその中からのログを可能にするためのセッションサービスも提供してよい。さらに、アーキテクチャ例２００は履歴情報を照会するための履歴サービス、つまりヒストリアンスキャナサービスを提供してよく、アラーム情報の読取り、およびプロセス制御（ＯＰＣ）データサービスのためのＯＬＥを可能にする実行時サービスとヒストリアンサービスとの対話、アラームおよびイベントサービスを必要とする。前記に注記された例各々のより詳細な説明は以下に示される。しかしながら、特に本明細書説明されるものに加えて他のサービス、および本明細書に説明されているものの代替策が所望のとおりに使用されてよいことが理解されなければならない。さらに、必ずしもでなくても、好ましくは、サービス２０６、２０８、および２１０は通常、システムユーザ（例えばシステムオペレータ、エンジニア等）が直接的に対話しないプロセス制御データ収集機能および処理機能と関連付けられていることが認識される必要がある。むしろ、このようなサービス（例えばサービス２０６、２０８および２１０）は、それらのデータをユーザが対話するクライアントアプリケーション（例えば実行時グラフィックユーザインタフェース）にそのデータを提供する（またはクライアントアプリケーションからデータを受信する）。さらにこのようなサービス（例えばサービス２０６、２０８および２１０）は、通常、複数のクライアントアプリケーションに有用である情報またはデータを提供する。例えば、プロセス制御データベースにアクセスを提供するサービスは、例えば、プロセス制御システム動作、保守、履歴等に関する情報を提供するグラフィックユーザインタフェース等、複数のクライアントアプリケーションに有用であってよい。サービス等の機能（データベースアクセス機能）をクライアント関連機能（例えばユーザインタフェース機能）から分離することにより、グラフィックユーザインタフェース等は、グラフィックユーザインタフェースがデータを交換するサービスを修正する必要なく、バージョニング、修正等を行うことができる。同様に、サービスは、グラフィックユーザインタフェース機能を提供するアプリケーションを修正しなくてもバージョニングするまたは修正することができる、および／または新しいサービスを追加できる。
【００３１】
図３は、図２のアーキテクチャ例２００によって提供されてよいディスカバリサービス例３００と実行時サーバ３０２との間の関係性を表す図である。一般的に、ディスカバリサービス例３００は、サービス登録機能３０４、サービス位置決め機能３０６、およびサービス公開機能３０８を提供する。
【００３２】
図３に描かれているように、ディスカバリサービス３００および従って、登録機能、位置決め機能および公開機能３０４、３０６、および３０８は、実行時サーバ３０２によって提供されているデータアクセスサービス３１０と連携する。図７に関連して後述される実行時サーバ３０２によって提供される複数のサービスの内の１つであるデータアクセスサービス３１０は、プロセス制御システム（例えば、図１のシステム例１０）の中で各ノード（例えば各サーバ）上にインストールされてよいサービスに関連する情報の照会を可能にするためのインタフェースを提供する。
【００３３】
サービスは、ユニフォームリソース識別子（ＵＲＩ）を使用して位置決めされてよい、および／または登録されてよい。このようなＵＲＩは、サーバ識別子フィールド、ポートフィールド、パス識別フィールド、および／または照会文字列を含むアドレスの形を取ってよい。しかしながら、同一なまたは同様な結果を達成するために、任意の他の所望のＵＲＩフォーマットが利用されてよい。いくつかのＵＲＩフォーマット（つまり、アイデンティティ役割、ｈｔｔｐアドレス、およびカスタムｈｔｔｐアドレス）が以下に示される。
【００３４】
【数１】
【００３５】
図４はディスカバリサービス例３００（図３）とそのホスト側ディスカバリサーバ３１２が協働するまたはデータアクセスサービス３１０およびそのホスト実行時サーバ３０２と相互作動する１つの方法を描くフロー図である。一般的に、図４に描かれているプロセスにより１つ以上の実行時サービス（例えば、図７の実行時サービス例７００）をディスカバリサーバ３１２を介して登録できるようにする。詳細に図４に目を向けると、ワークステーション（例えば、オペレータステーション、アプリケーションステーション等）がブートする（ブロック４０２）と、登録プロセス４００が開始する。次にワークステーションは、同時にディスカバリサービス（例えば、図３のディスカバリサービス３００）を起動する（ブロック４０６）ディスカバリサーバのインスタンスを作成する、あるいは起動する（例えば、図３のディスカバリサーバ３１２）（ブロック４０４）。ブロック４０６でディスカバリサービスを起動すると、（ディスカバリサービスのホストを努める）ディスカバリサーバはディスカバリサービスに以前に登録されたＵＲＩを公開する。
【００３６】
ブロック４０６でディスカバリサービスを起動後、ワークステーションは実行時サーバ（複数の場合がある）を起動する（ブロック４０８）。次に、実行時サーバ（複数の場合がある）は、ＵＲＩプレースホルダを作成し、ＵＲＩとポートを関連付ける（つまりＵＲＩにポートを割り当てる）ことによりディスカバリプロキシを作成する（ブロック４１０）。ブロック４１０で割り当てられたポート番号は次にディスカバリサービスに渡される（ブロック４１２）。
【００３７】
ブロック４１２でディスカバリサービスにポート番号を送信後、実行時サーバ（複数の場合がある）は、ブロック４１０で割り当てられるポート番号を使用して登録されるＵＲＩを構築し（ブロック４１４）、次に登録されるＵＲＩを実行時サービスに公開する（ブロック４１６）。プロセス４００は、次にディスカバリプロキシを介してディスカバリサービスにブロック４１６で公開されたＵＲＩを登録する。
【００３８】
図５は、ディスカバリサービスがそれによってサービスを位置決めする（例えば、所望のサービスのＵＲＩを決定する）プロセス例５００である。プロセス例５００は、クライアントアプリケーションが起動されると開始する（ブロック５０２）。次にクライアントアプリケーションが決定されるＵＲＩのプレースホルダを作成し（ブロック５０４）、ディスカバリプロキシを介してディスカバリサービス内で位置決め機能を呼び出す（位置決めされるサービスの名前を渡す）（ブロック５０６）。ブロック５０６での動作の結果としてクライアントアプリケーションに戻される、位置決めされるサービスのＵＲＩは次にサービスプロキシを介して位置決めされたサービスを起動するために使用される（ブロック５０８）。
【００３９】
図６は、セッションサービス６００のインプリメンテーション例を描く図である。一般的に、セッションサービス例６００は各クライアントアプリケーションにロードし、アプリケーションとアプリケーションを呼び出すユーザに関連する権限を追跡する。したがって、本明細書に説明される各サービスサーバは、サービスに対するアクセスを調整し、サーバにより提供されるサービスの内の１つ以上へのアクセスを要求するユーザ／クライアントアプリケーションの組み合わせと関連付けられるセキュリティ証明書を確証するセッションサービスを含む。
【００４０】
作動中、クライアントアプリケーションは特定のＵＲＩを使用してサーバに接続し、セッションサービスインタフェースを要求する。セッションサービスインタフェースはログイン機能とログアウト機能の両方を提供する。ログイン機能が呼び出されると、セキュリティ評価が、要求側のクライアントアプリケーションとユーザアイデンティティに基づいて実行され、セキュリティ評価が許容できる場合、セッションハンドルが戻され、要求側クライアントアプリケーションは実行時セッションに接続される。クライアントアプリケーションがサーバによって提供される別の（例えば追加の）サービスに対する接続を要求すると、クライアントアプリケーションはサーバにセッションハンドルをサーバに渡し、サーバはそのクライアントアプリケーションに関連するセッションに別のサービスを内部的に追加するためにセッションハンドルを使用する。ログアウト機能が呼び出されると、クライアントアプリケーションによって明示的に閉じられていなかったすべてのサービスが閉じられる。
【００４１】
ここで図６の詳細を見ると、セッションサービスインプリメンテーション例６００はクライアントプロセス６０２、データベースプロセス６０４、及び実行時プロセス６０６を含んでいる。クライアントプロセス６０２は、例えばアプリケーションステーション（例えば、図１のアプリケーションステーション例２０）、オペレータステーション（図1の
オペレータステーション１８）、及び／または機械読取可能な命令、コードまたはソフトウェアを実行できる任意の他のシステムで実行可能な１つ以上のアプリケーションを含んでよい。データベースプロセス６０４は、データベースサーバ６０８を介して全体でまたは部分的に実行されてよく、実行時プロセス６０６は実行時サーバ３０２を介して全体でまたは部分的に実行されてよい。
【００４２】
図６に描かれているように、セッションサービス例６００のクライアントプロセス６０２は、データベースサーバ６０８内のセッションサービスインスタンス６１８と６２０に対応する各々のセッションサービスプロキシ６１４と６１６を有する複数のクライアントアプリケーション６１０と６１２を含む。さらに、クライアントプロセス６０２と関連するアプリケーション例６１０と６１２の各々は、データベースアクセスを必要とし、したがってデータベースサーバ６０８により提供されるデータアクセスサービスインスタンス６２６と６２８と関連する各々のプロキシ６２２と６２４を含む。クライアントプロセス例６０２は、データベースサーバ６０８によって提供されてよいダウンロードサービス６３２と関連するプロキシ６３０も提供する。データベースサーバ６０８はさらに、データベースサーバ６０８内のアクティブセッション（セッション６１８と６２０）を追跡するおよび／または管理するセッションマネージャ６３４を含む。
【００４３】
セッション６１８と６２０、およびデータベースサーバ６０８内のダウンロードサービス６２３は、各々のプロキシ６４２、６４４および６４６を介して実行時サーバ３０２内の各々のインスタンス６３６、６３８および６４０と動作可能に関連付けられる。マシン端末セッション６４８は、セッション６３６と６３８を管理し、セッションオブジェクト６５０を保持し、前記に注記されたセッションオブジェクト６５０に対する安全性評価動作を実行するためにセキュリティサービス６５２と相互作動する。
【００４４】
このように、図６のインプリメンテーション例で分かるように、各クライアントアプリケーションは、１台以上のサーバにより提供される１つ以上のサービスと相互作動する。さらに具体的には、クライアントアプリケーションがプロセス制御データベースに対するアクセスを必要とする範囲まで、そのクライアントアプリケーションは、必要とされるデータベースアクセスサービス（複数の場合がある）を提供するサーバとのセッション（例えば通信リンク）を確立する。例えば、図６のインプリメンテーション例では、アプリケーション６１０がデータベースサーバ６０８内で（例えば、セッションサービス６１８を介して）セッションを確立し、データベースサーバ６０８内でＤａｔａＡｃｃｅｓｓサービス６２６を利用する。このように、クライアントアプリケーションは、複数の緩やかに結合された（つまり実質的にはデータから独立している）サービスを使用して実現することができ、それら各々が別のサーバ上にホスティングされてよい。クライアントアプリケーションは、次にホスト側サーバの各々で１つ以上のプロキシおよび１つ以上のセッションサービスオブジェクトを介してアプリケーションの各々によって、必要に応じてサービスと通信する。
【００４５】
図７は、実行時サーバ３０２（図３）によって提供されてよい実行時サービス７００のより詳細な線図である。一般的に、実行時サービス７００は、ローカル実行時プロセス制御情報およびリモート実行時プロセス制御情報に対するアクセスを提供する。図７に示されているように、実行時サービス７００はデータアクセスサービス３１０、アップロードサービス７０４、Ｆｉｅｌｄｂｕｓコミッショニングサービス７０６、実行時セッションサービス７０８、ダウンロードサービス７１０、コミッショニングサービス７１２、サブシステムサービス７１４、およびダウンロードリスナーサービス７１６を含んでよい。
【００４６】
データアクセスサービス３１０は、実行時データベース（例えば、図１のプロセス制御システム例１０内でプロセス制御パラメータ値を含む実行時データベース）内でのパラメータの読み書きを可能にする機能を提供する。さらに、データアクセスサービス３１０は、実行時データベース内のアイテム（例えば、コミッショニングされたコントローラノード）の収集を列挙することができる。
【００４７】
アップロードサービス、ダウンロードサービスおよびダウンロードリスナーサービス７０４、７１０、および７１６は、実行時データベースへのデータのアップロードとダウンロードを可能にし、Ｆｉｅｌｄｂｕｓコミッショニングサービスとコミッショニングサービス７０６と７１２は実行時データベース内のフィールドデバイスのコミッショニングを可能にし、実行時セッションサービス７０８は図６のインプリメンテーション例と関連して前述されたように、機械端末セッション７２０とサーバセッションサービス７１８と協働してセキュリティ機能を実行する。
【００４８】
図８は、データベースサーバ６０８によって提供されてよいデータベースサービス例８００のより詳細な線図である。図８に示されているように、データベースサービス８００は、データアクセスサービス８０２、ダウンロードサービス８０４、アップロードサービス８０６、Ｆｉｅｌｄｂｕｓコミッショニングサービス８０８、インポートサービス８１０、エキスポートサービス８１２、コミッショニングサービス８１４、データベース管理サービス８１６およびバージョン制御サービス８２０を含んでよい。データアクセスサービス８０２は、データベースを照会し、更新するための機能を提供する。データアクセスサービス８０２は、クライアントアプリケーションによって発行されるコマンドをデータベースサーバ６０８のデータベースに対して実行できるようにするコマンド機能も提供する。各コマンドは、データベースに適用される複数のナビゲーション動作と更新動作を含んでよい。加えて、各コマンドは単一のデータベーストランザクションで実行してよい。コマンドはアプリケーション内で構成され、データベースサーバ６０８内のスクリプトとして代わりに解釈される（例えば、コンパイルされ、実行される）文字列（ストリング）として伝達される。必ずしもではないが、好ましくは、コマンドは、共通のスクリプトをすべての同様な動作に使用できるようにパラメータ化される。データベースサーバ６０８は実行速度を強化するためにスクリプトを事前コンパイルし、キャッシュに入れてよい。１つの特定の例では、クライアントアプリケーションによってデータベースサーバ６０８に送信される更新コマンドは、バージョン制御アクション（つまり、バージョン制御サービス）が必要とされる場合に、クライアントインタフェースに対する呼び戻しをトリガしてよい。使用できるあらゆる更新は、コマンドの実行および呼び出し側ルーチンへのその同期された戻りに続いて、データベースサーバ６０８内のデータベースから収集される。
【００４９】
ダウンロードサービス８０４は、データベースサーバ６０８内での順序制御をサポートするインタフェースとして実現されてよい。ダウンロードサービス８０４インタフェースはダウンロードリストにアイテムを追加する機能、アップロードをチェックし、実行する機能、依存性をチェックする機能、ダウンロードを検証する機能、およびダウンロードアイテムをターゲットシステムに送信する機能を提供する。ダウンロードサービス８０４は、アップロードを実行するために、（図６に示されるように）実行時データアクセスサービス７０２（図７）と相互作動するように構成されてよい。ダウンロードサービス８０４は、デバイスがコミッションされることを確実にするために、実行時コミッショニングサービス７１２（図７）と相互作動してもよく、ダウンロードスクリプトを伝達するために実行時ダウンロードサービス７１０（図７）と相互作動してよい。
【００５０】
インポートサービス８１０は、データベースサーバ６０８内で順序付け可能なインタフェースとして実現されてもよい。インポートサービス８１０は、インポートファイルを指定する機能、インポートオプションを指定する機能、および要求されたデータをインポートする機能を提供してよい。インポートサービス８１０のインタフェースは、呼び出し側クライアントがサーバ６０８のためのインポートファイルを読み取り、インポートの進行を報告できるようにする呼び戻しを提供してもよい。
【００５１】
エクスポートサービス８１２は順序付け可能なインタフェースとして実現されてもよい。エクスポートサービス８１２は、エクスポートサービス８１２がエクスポートリストにアイテムを追加してから、エクスポートを実行できるようにするインタフェースを含んでよい。加えて、エクスポートサービス８１２は、クライアントアプリケーションがサーバのためのエクスポートファイルを書き込み、エクスポートの進行を報告できるようにする呼び出し側クライアントアプリケーションで呼び戻しインタフェースを提供してよい。
【００５２】
データベース管理サービス８１６は、データベースの作成、削除、バックアップ、および復元を可能にする機能を提供する。バージョン制御サービス８２０は、バージョンの管理を可能にする機能（例えば、サービスの異なるバージョン）を提供する。
【００５３】
図９は、バージョン制御サーバ９００、バージョンサーバ９０２、およびデータベースサーバ６０８が相互作動する方法を描く図である。図９に描かれているように、バージョン制御サーバ９００は複数のバージョン制御サービス９０４を含む。バージョン制御サービス９０４は管理サービス９０６とバージョンサービス９０８を含んでよい。
【００５４】
図１０は、複数の履歴サービス１００２を提供してよい履歴サーバ例１０００の線図である。履歴サービス１００２は、データアクセスサービス１００４、インポートサービス１００６、データ書き込みサービス１００８、エクスポートサービス１０１０、管理サービス１０１２、および監査サービス１０１４を含んでよい。一般的に、履歴サービス１００２によって、クライアントアプリケーションは履歴プロセス制御情報にアクセスする、あるいは照会することができる。さらに具体的には、データアクセスサービス１００４によって指定された期間の履歴情報の読み取り、時間情報（例えばタイムスタンプ）およびコメントを含む履歴情報の書き込み、および時間情報とコメントを含む履歴情報の更新を可能にする。インポートサービス１００６は、指定ファイルの中の情報のインポートを可能にする。データ書き込みサービス１００８は、履歴サーバデータベースへデータを書き込むために呼び出されてよい。エクスポートサービス１０１０は、エクスポートファイルに呼び出されてよい。管理サービス１０１２は、例えば、履歴データのアーカイブの作成、削除および移動等の履歴情報の管理を可能にする機能を提供する。
【００５５】
図１１は、履歴スキャナサーバ例１１００と、履歴スキャナサーバ１１００が実行時サービス７０２（図７）と履歴サービス１００２（図１０）と相互作動する方法を描く図である。図１１に描かれているように、履歴スキャナサーバ１１００は、それ独自のサービスのいずれも提供しないが、むしろ実行時サービス７０２と履歴サービス１００２を使用する。
【００５６】
図１２および図１３は、各々アラームイベントサーバ１２００とＯＰＣデータサーバ１３００とを描いている。アラームイベントサーバ１２００は、デコーダアクセスサービス１２０４、管理サービス１２０６、および構成サービス１２０８を含む複数のサービス１２０２を提供する。ＯＰＣデータサービス１３００は、データアクセスサービス１３０４、管理サービス１３０６、および構成サービス１３０８を含む複数のサービス１３０２を提供する。
【００５７】
図１４は、本明細書に説明されているサービス指向型アーキテクチャ例が、クライアントアプリケーションと関連するユーザインタフェースディスプレイグラフィックスを変数、スクリプト、および／またはデータサービスまたはソースとリンクさせる、または結合させるために使用されてよい１つの方法の例を描く。図１４に描かれているように、その内のいくつかまたはすべてが図２、図３、および図７から図１３に関連して前述されたサービス例に類似した、または同一の方法で実現されてよい、例えばヒストリアンデータサービス１４０２、実行時サービス１４０４、および／または他のデータサービス１４０６等の１つ以上のデータサービス１４００は、１つ以上の実行時プロセス１４０８にリンクされてよく、通信可能に結合されてよく、またそれ以外の場合は、動作可能に結合されてよい。実行時プロセス１４０８はあらゆる所望の実行時プロセスまたはアプリケーションを含んでよい。ただし、図１４の例でのように、実行時プロセス１４０８は、ユーザが、プロセス制御パラメータ値、履歴プロセス関連情報、トレンド情報、保守情報、アラーム情報または警告情報等のプロセス制御データを見る、および／または修正することができるようにするグラフィックユーザインタフェースまたはディスプレイアプリケーション１４１０を含む。
【００５８】
やはり図１４に描かれているように、実行プロセス１４０８とデータサービス１４００との間の通信結合またはリンケージは、データ結合動作またはプロセス１４１２およびデータソース（複数の場合がある）動作またはプロセス１４１４を使用して実現される。一般的に、実行時プロセス１４０８、データ結合プロセス１４１２およびデータソースプロセス１４１４は、例えばクライアント２０４（図２）によって実行されてよく、データサービス１４００は例えばサーバ２０２（図２）によって実行されてよい。より詳細には、実行時プロセス１４０８、データ結合プロセス１４１２、およびデータソースプロセス１４１４を含むクライアント２０４（図２）と関連するプロセスは、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によって提供されているアバロン（Ａｖａｌｏｎ）オペレーティングシステムフレームワークを使用して実現されてよい。アバロン（Ａｖａｌｏｎ）フレームワークは周知であり、本明細書に説明されている装置、方法、および製品の例の理解を容易にするためにアバロン（Ａｖａｌｏｎ）フレームワークの特定の態様のみが説明される。さらに、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によって提供されているアバロン（Ａｖａｌｏｎ）フレームワークが本明細書に説明されている例を実現するための１つの特に有用なフレームワークである一方、アバロン（Ａｖａｌｏｎ）フレームワークの代わりに、またはそれに加えて任意の他の適切なソフトウェアフレームワークが使用できるであろうことが理解されなければならない。
【００５９】
より詳細に図１４に目を向けると、データ結合関連プロセス１４１２は、より詳細に後述されるように変数、スクリプトおよびデータソースに対する参照を作成し、追跡調査するリソースマネージャ１４１６を含む。各ディスプレイ（例えばディスプレイ１４１０）は、専用のリソースマネージャインスタンス（例えばリソースマネージャ１４１６）によって管理されている。図１４に示されるように、ディスプレイ例１４１０は、同様にコンテキスト１４３０の１つ以上の結合または結合オブジェクト１４２８を介してデータサービス１４００の内の１つ以上に連結される、リンクされ、あるいは結合される１つ以上の変数１４２２、スクリプト（つまり実行可能なソフトウェアスクリプト）１４２４、およびデータソース参照１４２６と関連付けられたグラフィック要素１４１８と関連特性１４２０を含む。結合オブジェクト１４２８は、データソース（たとえば、データサービス１４００の１つ以上）内のある特定のデータアイテムの位置の文字列表現を含んでよいため、結合オブジェクト１４２８はデータソースに特化している。さらに、文字列表現は実行時中に変更されてよいエイリアスに対する参照を含んでよい。図示されるように、コンテキスト１４３０は、実行時データソース１４３１と、後述されるデータソースマネージャ１４３２にも結合される。
【００６０】
図１４に描かれているように、リソースマネージャ１４１６はディスプレイ１４１０からデータコンテキストを取り出す。一般的に、データコンテキストは、要素１４１８をレンダリングする場合にディスプレイ１４１０によって使用される特性１４２０から構成されている。リソースマネージャ１４１６は、変数１４２２、スクリプト１４２４および参照１４２６の内の適切なものに、データコンテキストに関連する特性１４２０をマッピングする、関連させる、あるいはそれ以外の場合結び付けるように構成される。さらに、リソースマネージャ１４１６はさらに、結合１４２８、コンテキスト１４３０、およびデータソースマネージャ１４３２を介してデータサービス１４００の内の１つ以上に特性１４２０をマッピングする、関連させる、あるいはそれ以外の場合結び付けるようにさらに構成されてよい。ディスプレイ１４１０の特性１４２０を変数１４２２、スクリプト１４２４、参照１４２６および／またはデータサービス１４００に関連させるためにリソースマネージャ１４１６によって使用されるマッピングは、例えば構成エンジニアまたは任意の他のシステムユーザによってシステム構成動作の間に確立できる。このように、多くの公知のプロセス制御システムディスプレイまたはユーザインタフェースとは対照的に、ディスプレイ１４１０の実行時特性、またはさらに一般的には実行時プロセス１４０８は、実行時プロセス１４０８と関連するアプリケーションを構成するソフトウェアによって静的に定義される。逆に、リソースマネージャ１４１６は、ディスプレイ１４１０の特性１４２０と、変数１４２２、スクリプト１４２４、参照１４２６、および実行時のデータソース１４００の内の１つ以上との間の関係性を確立するように構成される。
【００６１】
動作中、リソースマネージャ１４１６は、変数、値、テキスト名等の変更に関する情報を受信してよい。いくつかの場合、データ変更はリソースマネージャ１４１６に提供されるデータコンテキストの変化を介して伝達されてよい。さらに具体的には、それらの場合、ユーザが開始した特性１４２０の内の１つ以上に対する変更は、変数１４２２および／または参照１４２６と関連する値の１つ以上を変更させるためにスクリプト１４２４の内の１つ以上を呼び出してよい。したがって、変更がデータサービス１４００の内の１つ以上に記憶されるデータに関連する場合、リソースマネージャ１４１６により管理されるオブジェクトに対する変更は結合１４２８とコンテキストオブジェクト１４３０を介してデータサービス１４００の内の適切な１つ以上に自動的に伝搬されてよい。他の場合、データ変更は（例えば、プロセス変数値の変更の結果として）データサービス１４００の１つ以上の中で発生してよく、変更はリソースマネージャ１４１６によって提供されるマッピング機能を介して、特性１４２０の内の適切な１つにコンテキスト１４３０と結合１４２８を介して自動的に伝搬されてよい。
【００６２】
データソースマネージャ１４３２は、データソースに関連する結合オブジェクト（例えば、結合オブジェクト１４２８）の集合体に関するクライアント状態情報を維持するために使用されるコンテキストオブジェクト（例えば、コンテキストオブジェクト１４３０）を作成、管理する。グラフィックユーザインタフェースと関連するディスプレイの場合、コンテキストオブジェクトとディスプレイの間には１対１の対応がある。言い換えると、ディスプレイごとに１つのコンテキストがあり、各々のコンテキストはそのディスプレイと関連する結合だけを含む。このように、図１４の例では、コンテキストオブジェクト１４３０は一意にディスプレイ１４１０に対応する。
【００６３】
コンテキストオブジェクトは、その内の一方はイベントベースであり、ありとあらゆるイベントに応えて更新を開始し、その内のもう一方が本来照合され、複数のデータ変更イベントを収集し、周期的に（例えば、タイマに基づいて）変更された結合アイテムのリストをタイマに応えてデータソースに送信することにより更新を始動するデータ更新機構も提供する。言うまでもなく、相対的に処理する多数のイベントがある場合、各イベントに個別に応えることは、実行時プロセス１４０８および全体的なプロセス制御システム（例えば、図１のプロセス制御システム１０）の性能を害することがある（例えば、反応性の鈍化）。したがって、周期的に（データは変化したが、実行時プロセスにまだ渡されていない）不正な結合のリストに応答して、全体的な性能が改善されうる。コンテキストオブジェクト１４３０とデータサービス１４００との間の接続は、例えばマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によって提供されているインディゴ（Ｉｎｄｉｇｏ）フレームワークを使用して実現されてよい。
【００６４】
図１４の例と関連する変更情報の流れはディスプレイ１４１０で開始され、リソースマネージャ１４１６、結合１４２８、データソースマネージャ１４３２およびコンテキスト１４３０を介してデータサービス１４００の内の１つ以上に自動的に伝搬されるものとして説明されているが、データ変更情報は、代わりにまたは加えて、データサービス１４００の内の１つ以上からディスプレイ１４１０に自動的に伝搬できるであろう。
【００６５】
図１５は、ユーザインタフェースディスプレイグラフィックスがデータサービスまたはソースにリンクされる、あるいは結合されてよい１つの方法の例を描いている。図１５に描かれているように、ディスプレイ（例えばディスプレイを提供するアプリケーションまたは他の実行時エンティティ）１５０２は、同様にパラメータまたはディスプレイコンテンツ１５０６と関連付けられるディスプレイ要素またはグラフィックス１５０４を含む。ディスプレイ１５０２は、１つ以上のプロセス制御関連アプリケーションと関連するユーザインタフェースであってよく、その場合、グラフィックス１５０４は、例えばプロセス制御値、ポンプ、バルブ等のプロセス制御デバイスのグラフィック表現を保持するためのテキストボックス等のプロセス制御関連グラフィックスであってよい。ディスプレイコンテンツ１５０６は、（たとえば、ディスプレイグラフィックス１５０４がテキストボックスである場合の）テキスト情報、プロセス状態（例えば、赤は所定の限度に近づいている、あるいは超えたパラメータ値および／または是正処置を講じる必要性を示してよい）を表す色（例えば、複数の塗り潰し色の内の１つ）、グラフィック要素（例えば、ファンまたはポンプインペラ）の回転速度、振動、移動等するモータまたは他のデバイスの三次元ビュー、および／または任意の他のコンテンツを含んでよい。
【００６６】
ディスプレイ１５０２は、同様にプロセスコンテキスト１５１０とプロセス結合１５１２に通信可能にまたは動作可能に結合されるリソースマネージャインスタンス１５０８に通信可能に、または動作可能に結合される。プロセスコンテキスト１５１０は、プロセス結合１５１２に照合されたデータ変更通知またはイベント駆動データ変更通知を提供するように構成されてよい。プロセス結合１５１２は、データソースまたはサービスの中の固定メモリ位置のデータを参照してよい、および／またはデータソースまたはサービス内のデータのエイリアスを参照してよい。プロセス結合１５１２は結合オブジェクト１５１４を介してディスプレイコンテンツ１５０６に通信可能に、または動作可能に結合される。
【００６７】
動作中、リソースマネージャ１５０８は、ディスプレイグラフィックス１５０４とディスプレイコンテンツ１５０６をレンダリングするためにディスプレイ１５０２によって使用されるデータコンテキストまたはパラメータを保持する。リソースマネージャ１５０８は、ディスプレイ１５０２と関連する特性の少なくとも１つを、プロセスコンテキスト１５１０により提供されるデータにマップする、関係させる、またはその他関連させて、データサービス（たとえば、図１４に図示されるデータサービス１４００の内の１つ）内に記憶されるデータのためのデータランディングサイトを提供する。言い換えると、プロセスコンテキスト１５１０は、例えばコンテキストオブジェクト１４３０（図１４）等のコンテキストオブジェクト、したがってデータサービスまたは他のデータソースからの情報をリソースマネージャ１５０８に、そして最終的にはディスプレイコンテンツ１５０６、したがってディスプレイ１５０２に動作可能にまたは通信可能に結合するための機能を使用して実現されてよい。プロセスコンテキスト１５１０は、プロセス結合１５１２に対して照合された方法で（例えば変更されたデータ情報の集合体を周期的に送信する）、あるいは各データ変更イベントに応えてプロセス結合１５１２にデータ変更情報を送信するように構成されてよい。プロセスコンテキスト１５１０は、リソースマネージャ１５０８が変更通知を必要とするデータのプロセスコンテキスト１５１０を通知する情報をリソースマネージャ１５０８から受信するように構成される。このようにプロセスコンテキスト１５１０はリソースマネージャ１５０８により保持されるディスプレイ１５０２のデータコンテキストと関連するデータに関係するデータ変更通知だけを提供するように構成されてよい。いずれの場合でも、プロセス結合１５１２が１つ以上のデータ値が変更した旨の通知をプロセスコンテキスト１５１０から受信すると、プロセス結合１５１２は（結合１５１４を介して）ディスプレイコンテンツ１５０６に新しい値（複数の場合がある）を結合してから、リソースマネージャ１５０８に変更通知を提供する。プロセス結合１５１２から変更通知を受信すると、リソースマネージャ１５０８はディスプレイ１５０２上で特性変更メソッドを呼び出し、それによりディスプレイ１５０２に新規に結合されたデータを組み込むために更新させる。
【００６８】
本明細書に説明されている機能ブロック又はオペレーションは、ソフトウェア、ファームウェアおよびハードウェアの任意の所望の組み合わせを使用して実現されてよい。例えば、１台以上のマイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）等は、メソッドを実施するため、本明細書に説明される装置を実現するために機械またはプロセッサがアクセス可能な機能媒体上に記憶されている命令またはデータにアクセスしてよい。記憶媒体は、例えばランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）等を含むソリッドステート記憶媒体、光記憶媒体、磁気記憶媒体等のデバイスおよび／または媒体の任意の組み合わせを含んでよい。加えて、機能ブロックを実現するために使用されるソフトウェアは、さらにまたは代わりに、インターネット、電話回線、衛星通信等を介してソフトウェアを実行するプロセッサまたは他の１台以上のデバイスに送達され、それらによってアクセスされてよい。
【００６９】
図１６は、本明細書に説明される装置および方法を実現するために使用されてよいプロセッサシステム例１６０２を描く。プロセッサベースのシステム例１６０２は、例えば、サーバ、パソコン、または任意の他のタイプのコンピューティング装置であってよい。
【００７０】
プロセッサ１６００は、例えば、ペンティアム（登録商標）（Ｐｅｎｔｉｕｍ（登録商標））ファミリ、アイテニアム（Ｉｔａｎｉｕｍ）（登録商標）ファミリ、またはＸＳｃａｌｅ（登録商標）ファミリの１台以上のインテル（Ｉｎｔｅｌ）（登録商標）マイクロプロセッサを使用して実現されてよい。言うまでもなく、他のファミリおよび企業の他のプロセッサも適切である。プロセッサ１６００は、バス１６０８を介して揮発性メモリ１６０４および不揮発性メモリ１６０６を含むメインメモリと通信している。揮発性メモリ１６０４は、同期型ＤＲＡＭ（ＳＤＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、ＲＡＭＢＵＳダイナミックアクセスメモリ（ＲＤＲＡＭ）および／または任意の他のタイプのランダムアクセスメモリデバイスによって実現されてよい。不揮発性メモリ１６０６は、フラッシュメモリおよび／または任意の他の所望のタイプの不揮発性メモリデバイスによって実現されてよい。メモリ１６０４に対するアクセスは、通常、従来の方法でメモリコントローラ（不図示）によって制御されている。
【００７１】
システム１６０２はインタフェース回路１６１０も含む。インタフェース回路１６１０は、例えば、システム１６０２が図１のリンク２４、３２、４０、４２、４６および４８の内の１つ以上を介して通信可能にきるようにするための任意のタイプの周知のインタフェース規格によって実現されてよい。
【００７２】
システム１６０２は、ソフトウェアおよび／またはデータを記憶するために１台以上の大量記憶装置１６１８も含む。このような大量記憶装置の例はフロッピー（登録商標）ディスクドライブ、ハードドライブディスク、コンパクトディスクドライブ、およびデジタル多用途ディスク（ＤＶＤ）ドライブを含む。
【００７３】
特定の方法および装置および製品が本明細書に説明されてきたが、本特許の範囲はそれに限定されない。むしろ本明細書は、字句通りに、または均等論の元でのいずれかにより添付請求項の範囲内に該当するすべての方法、装置および製品をカバーする。
【００７４】
（関連出願）
本願は、２００４年５月４日に出願され、本願がこれにより全体を本明細書に参照することにより明示的に組み込んでいる「プロセス制御システムを表現し、監視し、対話するためのグラフィックユーザインタフェース（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ ｆｏｒ Ｒｅｐｒｅｓｅｎｔｉｎｇ，Ｍｏｎｉｔｏｒｉｎｇ ａｎｄ Ｉｎｔｅｇｒａｔｉｎｇ ｗｉｔｈ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ）」と題される米国仮特許出願、出願番号第６０／５６７，９８０号の正規に出願された出願であり、その利益を主張する。本願は、全体の開示がこれによりその全体を本明細書に参照することにより明示的に組み込まれている、２００２年１０月２２日に出願され、２００４年４月２２日に特許文献１として公開された、同様に「プロセスプラントにおけるスマートプロセスモジュールおよびオブジェクト（Ｓｍａｒｔ Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ａｎｄ Ｏｂｊｅｃｔｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」と題される米国特許出願、出願番号第１０／２７８，４６９号の一部継続出願である、２００３年7月２１日に出願され、２００４年８月５日に特許文献２として公開された「グラフィックディスプレイ要素、プロセスモジュールおよび制御モジュールのプロセスプラントにおける統合（Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｅｌｅｍｅｎｔｓ，Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ａｎｄ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」と題される米国特許出願、出願番号第１０／６２５，４８１号にも関連する。本願は、全体の開示がこれによりその全体を本明細書に参照することにより明示的に組み込まれている、２００３年２月１８日に出願され、２００４年１０月７日に特許文献３として公開された「プロセスプラント構成システムにおけるモジュールクラスオブジェクト（Ｍｏｄｕｌｅ Ｃｌａｓｓ Ｏｂｊｅｃｔｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｐｌａｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｙｓｔｅｍ）」と題される米国特許出願、出願番号第１０／３６８，１５１号にも関連する。本願は、本願と同日に国際（ＰＣＴ）出願として出願され、本願がこれにより全体を本明細書に参照することにより組み込んでいる以下の特許出願にも関連する。つまり、「プロセス環境における関連グラフィックディスプレイ（Ａｓｓｏｃｉａｔｅｄ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１１号）、「プロセス制御システムのためのユーザにより構成可能なアラームおよびアラームトレンド分析（Ｕｓｅｒ Ｃｏｎｆｉｇｕｒａｂｌｅ Ａｌａｒｍｓ ａｎｄ Ａｌａｒｍ Ｔｒｅｎｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ）」（代理人整理番号第０６００５／４１１１２号）、「プロセスプラントのプロセスモジュールとエキスパートシステムとの統合（Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ａｎｄ Ｅｘｐｅｒｔ Ｓｙｓｔｅｍｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」（代理人整理番号第０６００５／４１１１３号）、「統合された環境におけるカスタマイズされたプロセスグラフィックディスプレイ層を有するプロセスプラントユーザインタフェースシステム（Ａ Ｐｒｏｃｅｓｓ Ｐｌａｎｔ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ Ｓｙｓｔｅｍ Ｈａｖｉｎｇ Ｃｕｓｓｔｏｍｉｚｅｄ Ｐｒｏｃｅｓｓ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｌａｙｅｒｓ ｉｎ ａｎ Ｉｎｔｅｇｒａｔｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１４号）、「プロセス環境におけるスクリプト化されたグラフィック（Ｓｃｒｉｐｔｅｄ Ｇｒａｐｈｉｃｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１５号）、「プロセス構成および制御環境へのグラフィック統合（Ｇｒａｐｈｉｃｓ Ｉｎｔｅｇｒａｔｉｏｎ ｉｎｔｏ ａ Ｐｒｏｃｅｓｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｃｏｎｔｒｏｌ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１６号）、「プロセス環境における複数の視覚化のあるグラフィック要素（Ｇｒａｐｈｉｃ Ｅｌｅｍｅｎｔ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１７号）、「プロセスプラントにおいてグラフィックディスプレイ要素およびプロセスモジュールを構成するためのシステム（Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｆｉｇｕｒｉｎｇ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｅｌｅｍｅｎｔｓ ａｎｄ Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」（代理人整理番号第０６００５／４１１１８号）、「統合プロセス制御システムイシステムインタフェースのためのグラフィックディスプレイ構成フレームワーク（Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｕｎｉｆｉｅｄ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）」（代理人整理番号第０６００５／４１１２４号）、「プロセスプラントユーザインタフェースにおけるマークアップ言語をベースにした動的プロセスグラフィックス（Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ−Ｂａｓｅｄ，Ｄｙｎａｍｉｃ Ｐｒｏｃｅｓｓ Ｇｒａｐｈｉｃｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｐｌａｎｔ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）」（代理人整理番号第０６００５／４１１２７号）、「プロセス制御データを修正するための方法および装置（Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｍｏｄｉｆｙｉｎｇ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｄａｔａ）」（代理人整理番号第０６００５／５９１６２２号と第２００４０／５９−１１６２２号）、「プロセス制御データにアクセスするための方法および装置（Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｃｃｅｓｓｉｎｇ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｄａｔａ）」（代理人整理番号第０６００５／５９１６２３号および第２００４０／５９−１１６２３号）、「プロセス制御システムのための統合グラフィック実行時インタフェース（Ｉｎｔｅｇｒａｔｅｄ Ｇｒａｐｈｉｃａｌ Ｒｕｎｔｉｍｅ Ｉｎｔｅｒｆａｃｅ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ）」（代理人整理番号第０６００５／５９１６２８号および第２００４０／５９−１１６２８号）である。
【符号の説明】
【００７５】
１６００ プロセッサ
１６０２ プロセッサシステム
１６０４ メインメモリ
１６０６ 不揮発性メモリ
１６１０ インタフェース回路
１６１８ 記憶装置
【技術分野】
【０００１】
本発明は概してプロセス制御システムに関し、より詳細にはプロセス制御システムのためのサービス指向型アーキテクチャに関する。
【背景技術】
【０００２】
化学関連プロセス、石油関連プロセスまたは他のプロセスで使用されるシステム等のプロセス制御システムは、通常、アナログバス、デジタルバス、またはアナログ／デジタル結合バスを介して少なくとも１つのホストワークステーションまたはオペレータワークステーションに、および1台以上のフィールドデバイスに通信可能に結合されている１台以
上のプロセスコントローラおよび入力／出力（Ｉ／Ｏ）装置を含む。例えば、バルブ、バルブポジショナ、スイッチおよび送信機（例えば、温度センサ、圧力センサ、および流量センサ）であってよいフィールドデバイスは、バルブの開閉およびプロセスパラメータの測定等のプロセス機能を実行する。プロセスコントローラは、フィールドデバイスにより行われるプロセス測定、および／またはフィールドデバイスに関する他の情報を示す信号を受信し、制御ルーチンを実現するためにこの情報を使用し、次にプロセスの動作を制御するためにフィールドデバイスにバスまたは他の通信回線上で送信される制御信号を発生させる。このように、プロセスコントローラは、フィールドデバイスを通信可能に結合するバスおよび／または他の通信リンクを介してフィールドデバイスを使用して制御戦略を実行し、調整してよい。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第２００４／００７５６８９号明細書
【特許文献２】米国特許出願公開第２００４／０１５３８０４号明細書
【特許文献３】米国特許出願公開第２００４／０１９９９２５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
フィールドデバイスおよびコントローラからの情報は、オペレータが、プロセスの現状を見る、プロセスを評価する、プロセスの動作を修正する等のプロセスに関して所望の機能を実行可能とするために（例えばプロセッサベースのシステム等の）オペレータワークステーションによって実行される１つ以上のアプリケーション（つまり、ソフトウェアルーチン、プログラム等）が利用できてよい。多くのプロセス制御システムは１つ以上のアプリケーションステーションも含む。通常、これらのアプリケーションステーションは、コントローラ、オペレータワークステーションおよびローカルエリアネットワーク（ＬＡＮ）を介してプロセス制御システム内の他のシステムに通信可能に結合されるパーソナルコンピュータ、ワークステーション等を使用して実現される。各アプリケーションステーションは、プロセス制御システムの中でキャンペーン管理機能、保守管理機能、バーチャル制御機能、診断機能、リアルタイム監視機能、安全性関連機能、構成機能等を実行する１つ以上のソフトウェアアプリケーションを実行してよい。
【０００５】
多くのプロセス制御システムの多様なアプリケーションを実現するために使用されるソフトウェア要素（例えばプログラム）は、通常、オブジェクト指向型のプログラミング技術およびアーキテクチャの使用に大幅に依存している。このようなオブジェクト指向型プログラミングの技術とアーキテクチャは、より高いレベル（例えばより複雑な）ソフトウェアオブジェクトが１つ以上のより低いレベルのオブジェクトから構築され、したがって１つ以上のより低いレベルのオブジェクトの特性（プロパティ）を継承するソフトウェアオブジェクトの階層配列に基づいている。これらのオブジェクト指向型プログラミング内での継承を多用することは高度のコード（つまりソフトウェア命令、プログラム等）の共用を可能にし、制御システムを実現するために必要とされるコードまたはソフトウェアの総合的な量を大幅に削減する傾向がある。
【０００６】
公知のオブジェクト指向型プログラミングは、相対的に複雑なプロセス制御システムを実現するために必要とされるソフトウェアまたはコードの量を有利に削減できるが、これらの構成に関連する高度な継承またはコード共用は、制御システムを構成する多様なソフトウェアルーチンまたは構成要素間の高度な依存状態（例えばデータ依存）を生じさせる。その結果、これらの多様なソフトウェアルーチンの独立した開発および／またはバージョニングが困難であるかまたは不可能である場合がある。例えば、前述されたオブジェクト指向型の構成では、プロセス制御システムアプリケーション（例えばプロセス監視アプリケーション）、データベースサービス、および実行時サービスを利用するいくつかのプロセス制御システムは強固に結合している（つまり互いに対してかなり依存している）。特にクライアントアプリケーションはデータベース内のデータを表すデータ構成要素の共通したセット上に構築されてよい。したがって、共通データ構成要素の変更は、クライアントアプリケーションを再構築することを必要とする。その結果、特にプロセス制御システムの異なるソフトウェア構成要素が異なるロケーション（開発サイトまたはセンタ）で開発される場合、公知のオブジェクト指向型プロセス制御ソフトウェアアーキテクチャに固有のデータ依存により、データベース構成要素および実行時ソフトウェア構成要素の独立したバージョニングまたは開発は非常に困難または不可能になる。これらの公知のオブジェクト指向型アーキテクチャに固有のデータ依存に対処するために、プロセスソフトウェア開発者はデータベース構成要素、実行時構成要素、およびシステムソフトウェア構成要素の開発を、これらの構成要素が統一して構築され、リリースされるように調整することを余儀なくされてきた。
【課題を解決するための手段】
【０００７】
一例では、プロセス制御システムにおけるクライアントプロセスとサーバプロセス間でプロセス制御情報を伝達するための方法および装置は、各々が対応するサービスインタフェースを有する複数のプロセス制御サービスを含むサーバプロセスを確立する。この方法および装置の例では、クライアントプロセスが通信接続を確立する複数のサービスの各々にプロキシを有するクライアントプロセスも確立する。さらに、この方法および装置の例では、クライアントプロセスとサーバプロセス間のプロセス制御情報の伝達を可能にするためにクライアントプロセスへのサービスインタフェースと関連付けられた端点情報（ｅｎｄ ｐｏｉｎｔ）（例えばポート情報、ＵＲＬ、ＵＲＩ等）を提供する。
【０００８】
別の例では、ルーチンアプリケーションに情報を結び付ける方法は、リソースマネージャに実行時アプリケーションと関連するデータコンテキストを提供し、リソースマネージャを介してデータコンテキストからの少なくとも１つの特性を、変数、スクリプトまたはデータソース基準の内の少なくとも１つと関連付ける。さらに、該方法は変数、スクリプトまたはデータソース基準の内の該少なくとも１つに該少なくとも１つの特性を結び付ける。
【図面の簡単な説明】
【０００９】
【図１】本明細書に説明されるサービス指向型アーキテクチャを使用するプロセス制御システム例のブロック図である。
【図２】図１のプロセス制御システム例の中で使用されてよいサービス指向型アーキテクチャ例を描くブロック図である。
【図３】図２のアーキテクチャ例によって提供されるディスカバリサービスと実行時サーバとの間の関係性を描く図である。
【図４】図３のディスカバリサービスとそのホスト側サーバが図３のデータアクセスサービスとそのホスト側サーバと相互作動する1つの方法を描くフロー図である。
【図５】図３のディスカバリサービスがそれによってサービスを配置するプロセス例である。
【図６】セッションサービスのインプリメンテーション例を描く図である。
【図７】図３の実行時サーバ例によって提供されてよい実行時サービスのより詳細な線図である。
【図８】図６のデータベースサーバによって提供されてよいデータベースサービス例のより詳細な線図である。
【図９】図６のバージョン制御サーバ、バージョンサーバおよびデータベースサーバが相互作動する方法の例を描く図である。
【図１０】複数の履歴サービスを提供してよい履歴サーバ例の線図である。
【図１１】履歴スキャナサーバ例と、履歴スキャナサーバがいかにして図７の実行時サービス例と図１０の履歴サービス例と相互作動してよいのかを描く図である。
【図１２】本明細書に説明されているサービス指向型アーキテクチャ例を実現するために使用されてよいアラームおよびイベントサーバ例を描く。
【図１３】本明細書に説明されているサービス指向型アーキテクチャ例を実現するために使用されてよいＯＰＣデータサーバ例を描く。
【図１４】本明細書に説明されているサービス指向型アーキテクチャ例がデータサービスまたはソースに、クライアントアプリケーションと関連する実行時プロセスをリンクする、または結び付けるために使用されてよい１つの方法の例を描く。
【図１５】ユーザインタフェースがデータサービスまたはソースとリンク、あるいは結び付けられてよい１つの方法のより詳細な例を描く。
【図１６】本明細書に説明されている装置および方法を実現するために使用されてよいプロセッサシステム例を描く。
【発明を実施するための形態】
【００１０】
一般的に、本明細書に説明されている装置、方法および製品の例では、プロセス制御システムを構成する多様なソフトウェア要素（例えば、プログラム、アプリケーション、サービス等）間の高い独立性を提供するためにプロセス制御システム内で使用されてよい。より詳細には、本明細書に説明されている例は、複数の独立したプロセス制御関連アプリケーションがその上に層化している、複数の緩やかに結合された（つまり、実質的にデータから独立している）コアサービスを提供するソフトウェアおよびハードウェアのアーキテクチャを利用する。コアサービスの各々は個別にテストし、バージョニングできる良く定義された外部インタフェース（例えば、スキーマ、サービスに及び／又はサービスから渡されるパラメータ、データフォーマット等）を提供する。同様に、プロセス制御関連のアプリケーションは、アプリケーションの実質的にデータから独立した性質のために高度に独立した方法で（異なる開発チーム、場所等の間で最小の調整を行い、またはほとんど調整を行わずに）構築または開発できる。言い換えると、全体的なプロセス制御システムの中で使用するためにある特定のアプリケーションを開発している、ある場所にいるソフトウェア開発者は、別の物理的な場所にいるソフトウェア開発者の別のグループによって開発されている別のアプリケーションの開発に必ずしも密接に関係する、あるいは通知される必要はない。このように、本明細書に説明されているサービス指向型アーキテクチャ例は、別のソフトウェア開発チームが彼ら各々の開発作業を（例えば、会議および／または他の形の通信を介して）調整する多大な量の時間を費やす必要性を最小限に抑えるまたは排除し、それにより各々の開発作業のための開発時間と費用を大幅に削減する。
【００１１】
コードまたはソフトウェア再利用に焦点を当てた多くの公知のオブジェクト指向型インプリメンテーションまたはアーキテクチャとは対照的に、本明細書に説明されているサービス指向型制御アーキテクチャ例はデータサービスおよび／またはクライアントアプリケーション間の比較的に緩やかな結合（例えば、存在するとしても、比較的に少ないデータ依存）であることを強調する。さらに、公知のオブジェクト指向型インプリメンテーションを用いると、プロセス制御ソフトウェアアプリケーションまたはプログラムは、本来、共用されるクラスライブラリから引き出されるソフトウェア要素の構成または配列である。対照的に、本明細書に説明されているサービス指向型アーキテクチャ例は、相対的に自律したサービスから構成されるアプリケーションを活用する。より詳細には、本明細書に説明されているサービス志向型アーキテクチャ例と関連する相対的に自律したサービスは、クラス情報を共用するよりむしろ、（構造のための）スキーマと（動作のための）コントラクトを共用する。本明細書に説明されている相対的に自律したサービス（例えばデータサービス）の各々は、サービスが送受できるメッセージの構造を説明する（例えば、ＸＭＬ等の拡張可能マークアップ言語を使用して）コントラクトを確立する。
【００１２】
またさらに、公知のオブジェクト指向型プロセス制御ソフトウェアインプリメンテーションは、ソフトウェア要素または構成要素（例えばサービス）と開発者（異なる開発現場のソフトウェア開発者）間の通信を、（処理効率の観点から）安価かつ暗示的に処理する。対照的に、本明細書に説明されているサービス指向型アーキテクチャ例はこのような通信を相対的に高価かつ明示的に処理する。したがって、本明細書に説明されているサービス指向型アーキテクチャ例は、サービス全体で（つまり、プロセス制御ソフトウェアのコアサービスを構成する多様なソフトウェア構成要素と関連するサービス境界全体で）共用されなければならない抽出数および抽出の複雑性を削減するように構成される。
【００１３】
さらに、アプリケーションの展開を一元的に（つまり、相互に関連のあるアプリケーションのグループの共通のリリース）処理する公知のオブジェクト指向型インプリメンテーションとは対照的に、本明細書に説明されているサービス指向型プロセス制御ソフトウェアアーキテクチャ例は継続的なより不連続な方法でアプリケーション展開を処理する。例えば、本明細書に説明されているサービス指向型アーキテクチャ例を使用すると、クライアントアプリケーションは全体的なシステムおよびアプリケーションの集合的な状態が経時的に混合されるようにそれらのアプリケーションにより使用される根本的なデータサービスとは独立してバージョンニングされてよい。例えば、いくつかの場合、サービスは、該サービスを利用するアプリケーションが展開されるよりも十分に前に展開されてよい。さらに、アプリケーションとサービスが実質的に独立していることにより、サービスおよび／またはアプリケーションは経時的に異なる速度で独立して進化できる（つまり、無関係に開発または修正できる）。しかしながら、本明細書に説明されているサービス指向型アーキテクチャまたはフレームワークの例で活用される相対的に高度に切り離されたサービスおよび／またはアプリケーションの相互作動におけるさらに高い完全度を保証するために、各サービスはそれが別のサービスまたはアプリケーションから受信する各メッセージでバリデーションプロセスを実行するように構成されてよい。
【００１４】
本明細書にさらに詳しく説明されるように、サービス指向型アーキテクチャ例は、変数、実行可能スクリプト、および／または前述されたデータサービスに実行時アプリケーションを関連するパラメータのリンケージ、結合、またはさらに一般的には通信結合または動作結合を可能にするために有利に適用されてよい。例えば、プロセス制御システムユーザインタフェースアプリケーションと関連するレンダリンググラフィックディスプレイ要素と関連して使用されるパラメータは、実行時データサービスに通信可能にまたは操作で結合されてよい。この例では、パラメータに結合されるデータの変更は、変更されたデータを反映するために例えばグラフィックディスプレイを更新できる表示アプリケーションにデータサービスから自動的に伝搬できる。あるインプリメンテーションでは、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）により提供されている周知のアバロン（Ａｖａｌｏｎ）ソフトウェアプラットフォームとインティゴ（Ｉｎｄｉｇｏ）ソフトウェアプラットフォームが、実行時における変数、スクリプト、および／またはデータサービスに対するディスプレイエンティティに関連する特性の結合を可能にするために使用されてよい。しかしながら、アバロン（Ａｖａｌｏｎ）および／またはインディゴ（Ｉｎｄｉｇｏ）の代わりに任意の他の適切なソフトウェアプラットフォームが使用できるであろう。
【００１５】
より詳細に後述されるように、本明細書に説明されているサービス指向型アーキテクチャ例は、プロセス制御関連のデータをデータソース層に提供できるデータサービス層を含む。後述されるように、データソース層はアプリケーションの中からデータサービス層へ相対的に一般的なアクセスを提供する。データソース層上で層化されているリソースマネージャは、変数、スクリプトおよび／または参照を１つ以上の実行時アプリケーション、ディスプレイ、グラフィック要素、パラメータ等と関連するデータソースの中に管理する。パラメータとこのような変数またはデータソースとの間の結合（複数の場合がある）を静的にコード化することとは対照的に、本明細書に説明されるリソースマネージャは、有利なことに、例えばグラフィックディスプレイ要素に関連するパラメータを、実行時に１つ以上の変数またはデータサービス（例えば、サーバを介して提供されるプロセス制御データソース）に結合できるようにする。
【００１６】
より詳細には、本明細書に説明される装置、方法および製品の例を用いると、ディスプレイアプリケーションはリソースマネージャからそのグラフィック要素と関連する多様な特性の値あるいは他のデータまたは情報を要求してよい。同様に、リソースマネージャは、ディスプレイアプリケーションにより使用される特性にデータソースを提供する（例えば、マッピングする、関連付ける、あるいはそれ以外の場合結び付ける）ように実行時には構成されてよい。その結果として、ディスプレイアプリケーションは、それらのグラフィック要素と関連するパラメータ値に結合される、そのグラフィック要素と変数またはデータソースとの間の関係性を定義するために静的にコード化される必要はない。代わりに、リソースマネージャはより柔軟かつ動的にそれらの関係性を定義するために実行時に構成できる。
【００１７】
図１は、本明細書に説明されているサービス指向型アーキテクチャ例を使用するプロセス制御システム例１０のブロック図である。図１に描かれているように、プロセス制御システム１０はコントローラ１６、オペレータステーション１８、アクティブアプリケーションステーション２０、およびスタンバイアプリケーションステーション２２を含み、そのすべては、バス、または一般的にアプリケーション制御ネットワーク（ＡＣＮ）と呼ばれているローカルエリアネットワーク（ＬＡＮ）を介して通信可能に結合されてよい。オペレータステーション１８とアプリケーションステーション２０と２２は、1つ以上のワ
ークステーション、あるいは他の適切なコンピュータシステムまたは処理装置を使用して実現されてよい。例えば、アプリケーションステーション２０と２２は、単一のプロセッサワークステーションまたはマルチプロセッサワークステーション等の、以下の図１６に示されるプロセッサシステム例１６０２と同様に単一のプロセッサパーソナルコンピュータを使用して実現できるであろう。さらに、ＬＡＮ２４は、所望の通信媒体およびプロトコルを使用して実現されてよい。例えば、ＬＡＮ２４は、周知であり、本明細書ではさらに詳しく説明しない、ハードワイヤードの、または無線イーサネット（登録商標）通信スキームに基づいてよい。しかしながら、当業者により容易に理解されるように、任意の他の適切な通信媒体およびプロトコルを使用できるであろう。さらに、単一のＬＡＮが示されているが、複数のＬＡＮおよびアプリケーションステーション２０と２２の中の適切な通信ハードウェアが、オペレータステーション１８、アプリケーションステーション２０と２２、およびコントローラ１６の間に冗長な通信パスを提供するために使用されてよい。
【００１８】
コントローラ１６は、デジタルデータバス３２および入力／出力（Ｉ／Ｏ）デバイス３４を介して複数のスマートフィールドデバイス２６、２８および３０に結合されてよい。スマートフィールドデバイス２６から３０は、Ｆｉｅｌｄｂｕｓに準拠するバルブ、アクチュエータ、センサ等であってよく、その場合にはスマートフィールドデバイス２６から３０は周知のＦｉｅｌｄｂｕｓプロトコルを使用してデジタルデータバス３２を介して通信する。言うまでもなく、他のタイプのスマートフィールドデバイスと通信プロトコルが代わりに使用できるであろう。例えば、スマートフィールドデバイス２６から３０は、代わりに周知のＰｒｏｆｉｂｕｓ通信プロトコルおよびＨＡＲＴ通信プロトコルを使用して、データバス３２を介して通信するＰｒｏｆｉｂｕｓまたはＨＡＲＴに準拠するデバイスとなるであろう。（Ｉ／Ｏデバイス３４に類似するまたは同一の）追加のＩ／Ｏデバイスは、Ｆｉｅｌｄｂｕｓデバイス、ＨＡＲＴデバイス等であってよいスマートフィールドデバイスの追加のグループがコントローラ１６と通信可能にきるようにするためにコントローラ１６に結合されてよい。
【００１９】
スマートフィールドデバイス２６から３０に加えて、１台以上の非スマートフィールドデバイス３６と３８がコントローラ１６に通信可能に結合されてよい。非スマートフィールドデバイス３６と３８は、例えば、各々のハードワイヤードリンク４０と４２を介してコントローラ１６と通信する従来の４−２０ミリアンペア（ｍＡ）または０−１０ボルト直流（ＶＤＣ）デバイスであってよい。
【００２０】
コントローラ１６は、例えば、エマーソンプロセスマネジメント、ＬＬＬＰより販売されているＤｅｌｔａ（商標）コントローラであってよい。しかしながら、他のコントローラが代わりに使用できるであろう。さらに、図１には１台だけしかコントローラが図示されていないが、所望のタイプのまたはタイプの組み合せの追加のコントローラがＬＡＮ２４に結合できるであろう。コントローラ１６は、プロセス制御システム１０と関連する１つ以上のプロセス制御ルーチンを実行してよい。このようなプロセス制御ルーチンは、オペレータステーション１８を使用してシステムエンジニアまたは他のシステムオペレータによって生成され、コントローラ１６にダウンロードされ、コントローラ１６内でインスタンスを作成されてよい。
【００２１】
図１に説明されているように、プロセス制御システム例１０は、通信リンク４６とＬＡＮ４８を介してアプリケーションステーション２０と２２に通信可能に結合されるリモートオペレータステーション４４も含んでよい。リモートオペレータステーション４４は地理的に遠く離れて配置されてよく、その場合、通信リンク４６は、必ずしもではないが好ましくは無線通信リンク、インターネットベースまたは他のパケット交換通信のネットワーク、電話回線（例えば、デジタル加入者回線）またはその任意の組み合わせである。
【００２２】
図１の例に描かれているように、アクティブアプリケーションステーション２０とスタンバイアプリケーションステーション２２はＬＡＮ２４を介して、および冗長リンク５０を介して通信可能に結合されている。冗長リンク５０は、アクティブアプリケーションステーション２０とスタンバイアプリケーションステーション２２との間の個別な専用の（つまり共用されていない）通信リンクであってよい。冗長リンク５０は、例えば専用のイーサネット（登録商標）リンク（例えば、互いに結合されているアプリケーションステーション２０と２２各々の専用のイーサネット（登録商標）カード）を使用して実現されてよい。しかしながら、他の例では、冗長リンク５０は、アプリケーションステーション２０と２２に通信可能に結合される、必ずしも両方とも専用ではないが、ＬＡＮ２４または冗長ＬＡＮ（図示されていない）を使用して実現できるであろう。
【００２３】
一般的に、アプリケーションステーション２０と２２は、冗長コンテキストを確立し、維持するために冗長リンク５０を介して連続的に、例外によって、または周期的に情報を交換する。冗長コンテキストによって、アクティブアプリケーションステーション２０とスタンバイアプリケーションステーション２２間の制御の円滑なまたはバンプレスなハンドオフまたは切り替えが可能になる。例えば、冗長コンテキストは、アクティブアプリケーションステーション２０の中のハードウェア故障またはソフトウェア故障に応えて、あるいはプロセス制御システム１０のシステムオペレータまたはユーザまたはクライアントアプリケーションからの命令に応えて、アクティブアプリケーションステーション２０からスタンバイアプリケーションステーション２２への制御ハンドオフまたは切り替えを実行できる。
【００２４】
図２は、図１のプロセス制御システム例１０の中で使用されてよいサービス指向型アーキテクチャまたは構造の例２００を描くブロック図である。図２に示されているように、サービス指向型アーキテクチャ例２００は、サーバ２０２とクライアント２０４を含む。サーバ２０２は複数のサービス２０６、２０８、および２１０または集合体を含み、その内のいくつかまたはすべては関連機能を実行してよい。サービス２０６、２０８、および２１０は、通信ポート２１８を介したクライアント２０４との通信を可能にする各々のインタフェース（例えば、公開されているパラメータの１つ以上のセット）２１２、２１４、および２１６を提供する。サービスインタフェース２１２，２１４および２１６は、実質的には本質的に汎用であるため、実質的には図１のプロセス制御システム例１０と関連する構成および／または実行時データベースに含まれるデータのために使用されるスキーマ（つまり、データフォーマット、プロトコル等）とは無関係である。結果として、サービスインタフェース２１２、２１４、および２１６は、新規サービス能力（例えば機能）がサービス２０６、２０８および２１０の内の１つ以上に追加される場合、修正（例えば更新）だけを必要とする。したがって、サービスインタフェース２１２、２１４および２１６は、新規に公開されたインタフェースを使用するデータオブジェクトがプロセス制御システム１０（図１）内での使用に追加されない限り変更される必要はない。
【００２５】
サーバ２０２は、例えば、図１のシステム例に示されているアプリケーションステーション２０と２２および／またはオペレータステーション１８と４４の内の１つ以上等のプロセッサベースのシステムで実行されるソフトウェアとして実現されてよい。言うまでもなく、サーバ２０２は、プロセス制御システム例１０（図１）に結合されている他のプロセッサベースのシステムまたはワークステーションを使用して実現されてよい。
【００２６】
クライアント２０４は、各々がサービス２０６、２０８および２１０の内の１つに対応する複数のサービスインタフェースプロキシ２２０、２２２および２２４を含む。クライアント２０４によって使用されるサービスインタフェースプロキシの数は、サーバ２０２によって提供されるサービスの数より少ない場合がある。言い換えると、クライアント２０４は好ましくは、それがアクセスを必要とするサービスのためにのみプロキシを作成する。したがって、クライアント２０４は、サーバ２０２によって提供されるサービス２０６、２０８、および２１０の内の１つ以上にアクセスする、あるいはそれらと対話するために必要に応じて１つ以上のプロキシを生成してよい。
【００２７】
サーバ２０２と同様に、クライアント２０４は、例えば、アプリケーションステーション２０と２２の内の１つ以上、および／またはオペレータステーション１８と４４の内の１つ以上等のプロセッサベースのシステムで実行されるソフトウェアとして実現されてよい。あるインプリメンテーション例では、クライアント２０４は、サーバ２０２によって提供される１つ以上のサービス２０６、２０８および２１０にアクセスするために、１つ以上のウェブブラウザフレームワーク（例えばインターネットエクスプローラ（Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ）等を活用してよい。しかしながら、他の所望のソフトウェアフレームワークは、このようなウェブブラウザフレームワークの代わりに、またはこのようなウェブブラウザフレームワークに加えて使用されてよい。さらに一般的に、クライアント２０４はプロセス制御システム例１０（図１）内の所望のアプリケーションを表してよい。したがって、クライアント２０４は、例えば構成アプリケーション、保守アプリケーション、監視アプリケーション、プロセス制御アプリケーション、および／または任意の他のアプリケーションまたはアプリケーションの組み合わせであってよい。図１４および図１５に関連してさらに詳しく後述されるように、クライアント２０４（つまり、クライアントアプリケーション（複数の場合がある））は、一人以上のシステムオペレータ、エンジニアおよび／または任意の他のユーザが構成動作、実行時等の間にプロセス制御データを見るおよび／または変更することが可能となるように表示機能（例えばグラフィックユーザインタフェース機能）を含んでよい。
【００２８】
図２のアーキテクチャ例２００は単一のクライアントと通信して単一のサーバを描いているが、所望の場合追加のサーバおよびクライアントが使用されてよい。例えば、いくつかのインプリメンテーションでは、クライアント２０４は、２台以上のサーバと通信し、２台以上のサーバと相互作動し、および／または２台以上のサーバの中でサービスにアクセスしてよい。同様に、これらのインプリメンテーションまたは他のインプリメンテーションでは、サーバ例２０２（または他の個々のサーバ）は、複数のクライアントと通信してよい、および／または相互作動してよい。さらに、クライアント２０４がそれらの通信のためにサーバとして別のシステムと機能と通信してよいことが理解されなければならない。同様に、サーバ２０２がクライアント２０４以外のシステムと通信する場合、それらの通信のためのクライアントとして機能してよい。さらに、サービス２０６、２０８および２１０はサーバ２０２内で実現されているものとして描かれているが、サービス２０６、２０８、および２１０の内の１つ以上はクライアント２０４で代わりに実現されてよい。
【００２９】
このように、図２のサービス指向型アプリケーション例２００を用いると、サービス２０６、２０８および２１０は、相互から、およびサービス２０６、２０８および２１０を利用する（例えば呼び出す）アプリケーションから実質的（例えばデータ依存性に関して）に切り離される。有利なことに、このような切り離しによりサービス２０６、２０８および２１０の各々と関連するソフトウェアは、クライアント２０４によって活用され、サービス２０６、２０８および２１０にアクセスするアプリケーション（複数の場合がある）を修正またはバージョニングする必要なく、無関係に修正またはバージョンニングすることができ、現場での使用のためにリリースできる。同様に、クライアント２０４に関連するアプリケーション（複数の場合がある）が各々のサービス２０６、２０８および２１０のインタフェース２１２、２１４および２１６を順守するまたは適合しないかぎり、クライアント２０４と関連するアプリケーション（複数の場合がある）は、サービス２０６、２０８、および２１０を修正またはバージョニングする必要なく、無関係に修正またはバージョニングしてよい。したがって、アプリケーションおよび／またはサービス２０６、２０８、２１０と関連するソフトウェアが生成される時点でこのような関係性を固定する（つまりデータ依存性を生じさせる）ことにより、クライアント２０４とサービス２０６、２０８および２１０の内の１つ以上との間の関係性を静的に定義する代わりに、図２のアーキテクチャ例２００はこのような関係性を実行時に動的に確立できるようにする。
【００３０】
以下にさらに詳しく説明されるように、サービス指向型アーキテクチャ例２００は、種々のコアサービスおよび機能を提供してよい。具体的には、アーキテクチャ例２００はプロセス制御システム例１０（図１）の中でサービスを登録し、配置するためのディスカバリサービスを提供してよい。アーキテクチャ例２００は、クライアント２０４と関連するアプリケーション、ローカル実行時情報およびリモート実行時情報にアクセスを提供するための実行時サービス、多様なプロセス制御データベースにアクセスするためのデータベースサービス、およびプロセス制御システム例１０（図１）内で使用されるサービスおよび／またはアプリケーションと関連するバージョンニング情報を記憶し、取り出すためのバージョン制御サービスの内の１つ以上の中にログし、またはその中からのログを可能にするためのセッションサービスも提供してよい。さらに、アーキテクチャ例２００は履歴情報を照会するための履歴サービス、つまりヒストリアンスキャナサービスを提供してよく、アラーム情報の読取り、およびプロセス制御（ＯＰＣ）データサービスのためのＯＬＥを可能にする実行時サービスとヒストリアンサービスとの対話、アラームおよびイベントサービスを必要とする。前記に注記された例各々のより詳細な説明は以下に示される。しかしながら、特に本明細書説明されるものに加えて他のサービス、および本明細書に説明されているものの代替策が所望のとおりに使用されてよいことが理解されなければならない。さらに、必ずしもでなくても、好ましくは、サービス２０６、２０８、および２１０は通常、システムユーザ（例えばシステムオペレータ、エンジニア等）が直接的に対話しないプロセス制御データ収集機能および処理機能と関連付けられていることが認識される必要がある。むしろ、このようなサービス（例えばサービス２０６、２０８および２１０）は、それらのデータをユーザが対話するクライアントアプリケーション（例えば実行時グラフィックユーザインタフェース）にそのデータを提供する（またはクライアントアプリケーションからデータを受信する）。さらにこのようなサービス（例えばサービス２０６、２０８および２１０）は、通常、複数のクライアントアプリケーションに有用である情報またはデータを提供する。例えば、プロセス制御データベースにアクセスを提供するサービスは、例えば、プロセス制御システム動作、保守、履歴等に関する情報を提供するグラフィックユーザインタフェース等、複数のクライアントアプリケーションに有用であってよい。サービス等の機能（データベースアクセス機能）をクライアント関連機能（例えばユーザインタフェース機能）から分離することにより、グラフィックユーザインタフェース等は、グラフィックユーザインタフェースがデータを交換するサービスを修正する必要なく、バージョニング、修正等を行うことができる。同様に、サービスは、グラフィックユーザインタフェース機能を提供するアプリケーションを修正しなくてもバージョニングするまたは修正することができる、および／または新しいサービスを追加できる。
【００３１】
図３は、図２のアーキテクチャ例２００によって提供されてよいディスカバリサービス例３００と実行時サーバ３０２との間の関係性を表す図である。一般的に、ディスカバリサービス例３００は、サービス登録機能３０４、サービス位置決め機能３０６、およびサービス公開機能３０８を提供する。
【００３２】
図３に描かれているように、ディスカバリサービス３００および従って、登録機能、位置決め機能および公開機能３０４、３０６、および３０８は、実行時サーバ３０２によって提供されているデータアクセスサービス３１０と連携する。図７に関連して後述される実行時サーバ３０２によって提供される複数のサービスの内の１つであるデータアクセスサービス３１０は、プロセス制御システム（例えば、図１のシステム例１０）の中で各ノード（例えば各サーバ）上にインストールされてよいサービスに関連する情報の照会を可能にするためのインタフェースを提供する。
【００３３】
サービスは、ユニフォームリソース識別子（ＵＲＩ）を使用して位置決めされてよい、および／または登録されてよい。このようなＵＲＩは、サーバ識別子フィールド、ポートフィールド、パス識別フィールド、および／または照会文字列を含むアドレスの形を取ってよい。しかしながら、同一なまたは同様な結果を達成するために、任意の他の所望のＵＲＩフォーマットが利用されてよい。いくつかのＵＲＩフォーマット（つまり、アイデンティティ役割、ｈｔｔｐアドレス、およびカスタムｈｔｔｐアドレス）が以下に示される。
【００３４】
【数１】
【００３５】
図４はディスカバリサービス例３００（図３）とそのホスト側ディスカバリサーバ３１２が協働するまたはデータアクセスサービス３１０およびそのホスト実行時サーバ３０２と相互作動する１つの方法を描くフロー図である。一般的に、図４に描かれているプロセスにより１つ以上の実行時サービス（例えば、図７の実行時サービス例７００）をディスカバリサーバ３１２を介して登録できるようにする。詳細に図４に目を向けると、ワークステーション（例えば、オペレータステーション、アプリケーションステーション等）がブートする（ブロック４０２）と、登録プロセス４００が開始する。次にワークステーションは、同時にディスカバリサービス（例えば、図３のディスカバリサービス３００）を起動する（ブロック４０６）ディスカバリサーバのインスタンスを作成する、あるいは起動する（例えば、図３のディスカバリサーバ３１２）（ブロック４０４）。ブロック４０６でディスカバリサービスを起動すると、（ディスカバリサービスのホストを努める）ディスカバリサーバはディスカバリサービスに以前に登録されたＵＲＩを公開する。
【００３６】
ブロック４０６でディスカバリサービスを起動後、ワークステーションは実行時サーバ（複数の場合がある）を起動する（ブロック４０８）。次に、実行時サーバ（複数の場合がある）は、ＵＲＩプレースホルダを作成し、ＵＲＩとポートを関連付ける（つまりＵＲＩにポートを割り当てる）ことによりディスカバリプロキシを作成する（ブロック４１０）。ブロック４１０で割り当てられたポート番号は次にディスカバリサービスに渡される（ブロック４１２）。
【００３７】
ブロック４１２でディスカバリサービスにポート番号を送信後、実行時サーバ（複数の場合がある）は、ブロック４１０で割り当てられるポート番号を使用して登録されるＵＲＩを構築し（ブロック４１４）、次に登録されるＵＲＩを実行時サービスに公開する（ブロック４１６）。プロセス４００は、次にディスカバリプロキシを介してディスカバリサービスにブロック４１６で公開されたＵＲＩを登録する。
【００３８】
図５は、ディスカバリサービスがそれによってサービスを位置決めする（例えば、所望のサービスのＵＲＩを決定する）プロセス例５００である。プロセス例５００は、クライアントアプリケーションが起動されると開始する（ブロック５０２）。次にクライアントアプリケーションが決定されるＵＲＩのプレースホルダを作成し（ブロック５０４）、ディスカバリプロキシを介してディスカバリサービス内で位置決め機能を呼び出す（位置決めされるサービスの名前を渡す）（ブロック５０６）。ブロック５０６での動作の結果としてクライアントアプリケーションに戻される、位置決めされるサービスのＵＲＩは次にサービスプロキシを介して位置決めされたサービスを起動するために使用される（ブロック５０８）。
【００３９】
図６は、セッションサービス６００のインプリメンテーション例を描く図である。一般的に、セッションサービス例６００は各クライアントアプリケーションにロードし、アプリケーションとアプリケーションを呼び出すユーザに関連する権限を追跡する。したがって、本明細書に説明される各サービスサーバは、サービスに対するアクセスを調整し、サーバにより提供されるサービスの内の１つ以上へのアクセスを要求するユーザ／クライアントアプリケーションの組み合わせと関連付けられるセキュリティ証明書を確証するセッションサービスを含む。
【００４０】
作動中、クライアントアプリケーションは特定のＵＲＩを使用してサーバに接続し、セッションサービスインタフェースを要求する。セッションサービスインタフェースはログイン機能とログアウト機能の両方を提供する。ログイン機能が呼び出されると、セキュリティ評価が、要求側のクライアントアプリケーションとユーザアイデンティティに基づいて実行され、セキュリティ評価が許容できる場合、セッションハンドルが戻され、要求側クライアントアプリケーションは実行時セッションに接続される。クライアントアプリケーションがサーバによって提供される別の（例えば追加の）サービスに対する接続を要求すると、クライアントアプリケーションはサーバにセッションハンドルをサーバに渡し、サーバはそのクライアントアプリケーションに関連するセッションに別のサービスを内部的に追加するためにセッションハンドルを使用する。ログアウト機能が呼び出されると、クライアントアプリケーションによって明示的に閉じられていなかったすべてのサービスが閉じられる。
【００４１】
ここで図６の詳細を見ると、セッションサービスインプリメンテーション例６００はクライアントプロセス６０２、データベースプロセス６０４、及び実行時プロセス６０６を含んでいる。クライアントプロセス６０２は、例えばアプリケーションステーション（例えば、図１のアプリケーションステーション例２０）、オペレータステーション（図1の
オペレータステーション１８）、及び／または機械読取可能な命令、コードまたはソフトウェアを実行できる任意の他のシステムで実行可能な１つ以上のアプリケーションを含んでよい。データベースプロセス６０４は、データベースサーバ６０８を介して全体でまたは部分的に実行されてよく、実行時プロセス６０６は実行時サーバ３０２を介して全体でまたは部分的に実行されてよい。
【００４２】
図６に描かれているように、セッションサービス例６００のクライアントプロセス６０２は、データベースサーバ６０８内のセッションサービスインスタンス６１８と６２０に対応する各々のセッションサービスプロキシ６１４と６１６を有する複数のクライアントアプリケーション６１０と６１２を含む。さらに、クライアントプロセス６０２と関連するアプリケーション例６１０と６１２の各々は、データベースアクセスを必要とし、したがってデータベースサーバ６０８により提供されるデータアクセスサービスインスタンス６２６と６２８と関連する各々のプロキシ６２２と６２４を含む。クライアントプロセス例６０２は、データベースサーバ６０８によって提供されてよいダウンロードサービス６３２と関連するプロキシ６３０も提供する。データベースサーバ６０８はさらに、データベースサーバ６０８内のアクティブセッション（セッション６１８と６２０）を追跡するおよび／または管理するセッションマネージャ６３４を含む。
【００４３】
セッション６１８と６２０、およびデータベースサーバ６０８内のダウンロードサービス６２３は、各々のプロキシ６４２、６４４および６４６を介して実行時サーバ３０２内の各々のインスタンス６３６、６３８および６４０と動作可能に関連付けられる。マシン端末セッション６４８は、セッション６３６と６３８を管理し、セッションオブジェクト６５０を保持し、前記に注記されたセッションオブジェクト６５０に対する安全性評価動作を実行するためにセキュリティサービス６５２と相互作動する。
【００４４】
このように、図６のインプリメンテーション例で分かるように、各クライアントアプリケーションは、１台以上のサーバにより提供される１つ以上のサービスと相互作動する。さらに具体的には、クライアントアプリケーションがプロセス制御データベースに対するアクセスを必要とする範囲まで、そのクライアントアプリケーションは、必要とされるデータベースアクセスサービス（複数の場合がある）を提供するサーバとのセッション（例えば通信リンク）を確立する。例えば、図６のインプリメンテーション例では、アプリケーション６１０がデータベースサーバ６０８内で（例えば、セッションサービス６１８を介して）セッションを確立し、データベースサーバ６０８内でＤａｔａＡｃｃｅｓｓサービス６２６を利用する。このように、クライアントアプリケーションは、複数の緩やかに結合された（つまり実質的にはデータから独立している）サービスを使用して実現することができ、それら各々が別のサーバ上にホスティングされてよい。クライアントアプリケーションは、次にホスト側サーバの各々で１つ以上のプロキシおよび１つ以上のセッションサービスオブジェクトを介してアプリケーションの各々によって、必要に応じてサービスと通信する。
【００４５】
図７は、実行時サーバ３０２（図３）によって提供されてよい実行時サービス７００のより詳細な線図である。一般的に、実行時サービス７００は、ローカル実行時プロセス制御情報およびリモート実行時プロセス制御情報に対するアクセスを提供する。図７に示されているように、実行時サービス７００はデータアクセスサービス３１０、アップロードサービス７０４、Ｆｉｅｌｄｂｕｓコミッショニングサービス７０６、実行時セッションサービス７０８、ダウンロードサービス７１０、コミッショニングサービス７１２、サブシステムサービス７１４、およびダウンロードリスナーサービス７１６を含んでよい。
【００４６】
データアクセスサービス３１０は、実行時データベース（例えば、図１のプロセス制御システム例１０内でプロセス制御パラメータ値を含む実行時データベース）内でのパラメータの読み書きを可能にする機能を提供する。さらに、データアクセスサービス３１０は、実行時データベース内のアイテム（例えば、コミッショニングされたコントローラノード）の収集を列挙することができる。
【００４７】
アップロードサービス、ダウンロードサービスおよびダウンロードリスナーサービス７０４、７１０、および７１６は、実行時データベースへのデータのアップロードとダウンロードを可能にし、Ｆｉｅｌｄｂｕｓコミッショニングサービスとコミッショニングサービス７０６と７１２は実行時データベース内のフィールドデバイスのコミッショニングを可能にし、実行時セッションサービス７０８は図６のインプリメンテーション例と関連して前述されたように、機械端末セッション７２０とサーバセッションサービス７１８と協働してセキュリティ機能を実行する。
【００４８】
図８は、データベースサーバ６０８によって提供されてよいデータベースサービス例８００のより詳細な線図である。図８に示されているように、データベースサービス８００は、データアクセスサービス８０２、ダウンロードサービス８０４、アップロードサービス８０６、Ｆｉｅｌｄｂｕｓコミッショニングサービス８０８、インポートサービス８１０、エキスポートサービス８１２、コミッショニングサービス８１４、データベース管理サービス８１６およびバージョン制御サービス８２０を含んでよい。データアクセスサービス８０２は、データベースを照会し、更新するための機能を提供する。データアクセスサービス８０２は、クライアントアプリケーションによって発行されるコマンドをデータベースサーバ６０８のデータベースに対して実行できるようにするコマンド機能も提供する。各コマンドは、データベースに適用される複数のナビゲーション動作と更新動作を含んでよい。加えて、各コマンドは単一のデータベーストランザクションで実行してよい。コマンドはアプリケーション内で構成され、データベースサーバ６０８内のスクリプトとして代わりに解釈される（例えば、コンパイルされ、実行される）文字列（ストリング）として伝達される。必ずしもではないが、好ましくは、コマンドは、共通のスクリプトをすべての同様な動作に使用できるようにパラメータ化される。データベースサーバ６０８は実行速度を強化するためにスクリプトを事前コンパイルし、キャッシュに入れてよい。１つの特定の例では、クライアントアプリケーションによってデータベースサーバ６０８に送信される更新コマンドは、バージョン制御アクション（つまり、バージョン制御サービス）が必要とされる場合に、クライアントインタフェースに対する呼び戻しをトリガしてよい。使用できるあらゆる更新は、コマンドの実行および呼び出し側ルーチンへのその同期された戻りに続いて、データベースサーバ６０８内のデータベースから収集される。
【００４９】
ダウンロードサービス８０４は、データベースサーバ６０８内での順序制御をサポートするインタフェースとして実現されてよい。ダウンロードサービス８０４インタフェースはダウンロードリストにアイテムを追加する機能、アップロードをチェックし、実行する機能、依存性をチェックする機能、ダウンロードを検証する機能、およびダウンロードアイテムをターゲットシステムに送信する機能を提供する。ダウンロードサービス８０４は、アップロードを実行するために、（図６に示されるように）実行時データアクセスサービス７０２（図７）と相互作動するように構成されてよい。ダウンロードサービス８０４は、デバイスがコミッションされることを確実にするために、実行時コミッショニングサービス７１２（図７）と相互作動してもよく、ダウンロードスクリプトを伝達するために実行時ダウンロードサービス７１０（図７）と相互作動してよい。
【００５０】
インポートサービス８１０は、データベースサーバ６０８内で順序付け可能なインタフェースとして実現されてもよい。インポートサービス８１０は、インポートファイルを指定する機能、インポートオプションを指定する機能、および要求されたデータをインポートする機能を提供してよい。インポートサービス８１０のインタフェースは、呼び出し側クライアントがサーバ６０８のためのインポートファイルを読み取り、インポートの進行を報告できるようにする呼び戻しを提供してもよい。
【００５１】
エクスポートサービス８１２は順序付け可能なインタフェースとして実現されてもよい。エクスポートサービス８１２は、エクスポートサービス８１２がエクスポートリストにアイテムを追加してから、エクスポートを実行できるようにするインタフェースを含んでよい。加えて、エクスポートサービス８１２は、クライアントアプリケーションがサーバのためのエクスポートファイルを書き込み、エクスポートの進行を報告できるようにする呼び出し側クライアントアプリケーションで呼び戻しインタフェースを提供してよい。
【００５２】
データベース管理サービス８１６は、データベースの作成、削除、バックアップ、および復元を可能にする機能を提供する。バージョン制御サービス８２０は、バージョンの管理を可能にする機能（例えば、サービスの異なるバージョン）を提供する。
【００５３】
図９は、バージョン制御サーバ９００、バージョンサーバ９０２、およびデータベースサーバ６０８が相互作動する方法を描く図である。図９に描かれているように、バージョン制御サーバ９００は複数のバージョン制御サービス９０４を含む。バージョン制御サービス９０４は管理サービス９０６とバージョンサービス９０８を含んでよい。
【００５４】
図１０は、複数の履歴サービス１００２を提供してよい履歴サーバ例１０００の線図である。履歴サービス１００２は、データアクセスサービス１００４、インポートサービス１００６、データ書き込みサービス１００８、エクスポートサービス１０１０、管理サービス１０１２、および監査サービス１０１４を含んでよい。一般的に、履歴サービス１００２によって、クライアントアプリケーションは履歴プロセス制御情報にアクセスする、あるいは照会することができる。さらに具体的には、データアクセスサービス１００４によって指定された期間の履歴情報の読み取り、時間情報（例えばタイムスタンプ）およびコメントを含む履歴情報の書き込み、および時間情報とコメントを含む履歴情報の更新を可能にする。インポートサービス１００６は、指定ファイルの中の情報のインポートを可能にする。データ書き込みサービス１００８は、履歴サーバデータベースへデータを書き込むために呼び出されてよい。エクスポートサービス１０１０は、エクスポートファイルに呼び出されてよい。管理サービス１０１２は、例えば、履歴データのアーカイブの作成、削除および移動等の履歴情報の管理を可能にする機能を提供する。
【００５５】
図１１は、履歴スキャナサーバ例１１００と、履歴スキャナサーバ１１００が実行時サービス７０２（図７）と履歴サービス１００２（図１０）と相互作動する方法を描く図である。図１１に描かれているように、履歴スキャナサーバ１１００は、それ独自のサービスのいずれも提供しないが、むしろ実行時サービス７０２と履歴サービス１００２を使用する。
【００５６】
図１２および図１３は、各々アラームイベントサーバ１２００とＯＰＣデータサーバ１３００とを描いている。アラームイベントサーバ１２００は、デコーダアクセスサービス１２０４、管理サービス１２０６、および構成サービス１２０８を含む複数のサービス１２０２を提供する。ＯＰＣデータサービス１３００は、データアクセスサービス１３０４、管理サービス１３０６、および構成サービス１３０８を含む複数のサービス１３０２を提供する。
【００５７】
図１４は、本明細書に説明されているサービス指向型アーキテクチャ例が、クライアントアプリケーションと関連するユーザインタフェースディスプレイグラフィックスを変数、スクリプト、および／またはデータサービスまたはソースとリンクさせる、または結合させるために使用されてよい１つの方法の例を描く。図１４に描かれているように、その内のいくつかまたはすべてが図２、図３、および図７から図１３に関連して前述されたサービス例に類似した、または同一の方法で実現されてよい、例えばヒストリアンデータサービス１４０２、実行時サービス１４０４、および／または他のデータサービス１４０６等の１つ以上のデータサービス１４００は、１つ以上の実行時プロセス１４０８にリンクされてよく、通信可能に結合されてよく、またそれ以外の場合は、動作可能に結合されてよい。実行時プロセス１４０８はあらゆる所望の実行時プロセスまたはアプリケーションを含んでよい。ただし、図１４の例でのように、実行時プロセス１４０８は、ユーザが、プロセス制御パラメータ値、履歴プロセス関連情報、トレンド情報、保守情報、アラーム情報または警告情報等のプロセス制御データを見る、および／または修正することができるようにするグラフィックユーザインタフェースまたはディスプレイアプリケーション１４１０を含む。
【００５８】
やはり図１４に描かれているように、実行プロセス１４０８とデータサービス１４００との間の通信結合またはリンケージは、データ結合動作またはプロセス１４１２およびデータソース（複数の場合がある）動作またはプロセス１４１４を使用して実現される。一般的に、実行時プロセス１４０８、データ結合プロセス１４１２およびデータソースプロセス１４１４は、例えばクライアント２０４（図２）によって実行されてよく、データサービス１４００は例えばサーバ２０２（図２）によって実行されてよい。より詳細には、実行時プロセス１４０８、データ結合プロセス１４１２、およびデータソースプロセス１４１４を含むクライアント２０４（図２）と関連するプロセスは、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によって提供されているアバロン（Ａｖａｌｏｎ）オペレーティングシステムフレームワークを使用して実現されてよい。アバロン（Ａｖａｌｏｎ）フレームワークは周知であり、本明細書に説明されている装置、方法、および製品の例の理解を容易にするためにアバロン（Ａｖａｌｏｎ）フレームワークの特定の態様のみが説明される。さらに、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によって提供されているアバロン（Ａｖａｌｏｎ）フレームワークが本明細書に説明されている例を実現するための１つの特に有用なフレームワークである一方、アバロン（Ａｖａｌｏｎ）フレームワークの代わりに、またはそれに加えて任意の他の適切なソフトウェアフレームワークが使用できるであろうことが理解されなければならない。
【００５９】
より詳細に図１４に目を向けると、データ結合関連プロセス１４１２は、より詳細に後述されるように変数、スクリプトおよびデータソースに対する参照を作成し、追跡調査するリソースマネージャ１４１６を含む。各ディスプレイ（例えばディスプレイ１４１０）は、専用のリソースマネージャインスタンス（例えばリソースマネージャ１４１６）によって管理されている。図１４に示されるように、ディスプレイ例１４１０は、同様にコンテキスト１４３０の１つ以上の結合または結合オブジェクト１４２８を介してデータサービス１４００の内の１つ以上に連結される、リンクされ、あるいは結合される１つ以上の変数１４２２、スクリプト（つまり実行可能なソフトウェアスクリプト）１４２４、およびデータソース参照１４２６と関連付けられたグラフィック要素１４１８と関連特性１４２０を含む。結合オブジェクト１４２８は、データソース（たとえば、データサービス１４００の１つ以上）内のある特定のデータアイテムの位置の文字列表現を含んでよいため、結合オブジェクト１４２８はデータソースに特化している。さらに、文字列表現は実行時中に変更されてよいエイリアスに対する参照を含んでよい。図示されるように、コンテキスト１４３０は、実行時データソース１４３１と、後述されるデータソースマネージャ１４３２にも結合される。
【００６０】
図１４に描かれているように、リソースマネージャ１４１６はディスプレイ１４１０からデータコンテキストを取り出す。一般的に、データコンテキストは、要素１４１８をレンダリングする場合にディスプレイ１４１０によって使用される特性１４２０から構成されている。リソースマネージャ１４１６は、変数１４２２、スクリプト１４２４および参照１４２６の内の適切なものに、データコンテキストに関連する特性１４２０をマッピングする、関連させる、あるいはそれ以外の場合結び付けるように構成される。さらに、リソースマネージャ１４１６はさらに、結合１４２８、コンテキスト１４３０、およびデータソースマネージャ１４３２を介してデータサービス１４００の内の１つ以上に特性１４２０をマッピングする、関連させる、あるいはそれ以外の場合結び付けるようにさらに構成されてよい。ディスプレイ１４１０の特性１４２０を変数１４２２、スクリプト１４２４、参照１４２６および／またはデータサービス１４００に関連させるためにリソースマネージャ１４１６によって使用されるマッピングは、例えば構成エンジニアまたは任意の他のシステムユーザによってシステム構成動作の間に確立できる。このように、多くの公知のプロセス制御システムディスプレイまたはユーザインタフェースとは対照的に、ディスプレイ１４１０の実行時特性、またはさらに一般的には実行時プロセス１４０８は、実行時プロセス１４０８と関連するアプリケーションを構成するソフトウェアによって静的に定義される。逆に、リソースマネージャ１４１６は、ディスプレイ１４１０の特性１４２０と、変数１４２２、スクリプト１４２４、参照１４２６、および実行時のデータソース１４００の内の１つ以上との間の関係性を確立するように構成される。
【００６１】
動作中、リソースマネージャ１４１６は、変数、値、テキスト名等の変更に関する情報を受信してよい。いくつかの場合、データ変更はリソースマネージャ１４１６に提供されるデータコンテキストの変化を介して伝達されてよい。さらに具体的には、それらの場合、ユーザが開始した特性１４２０の内の１つ以上に対する変更は、変数１４２２および／または参照１４２６と関連する値の１つ以上を変更させるためにスクリプト１４２４の内の１つ以上を呼び出してよい。したがって、変更がデータサービス１４００の内の１つ以上に記憶されるデータに関連する場合、リソースマネージャ１４１６により管理されるオブジェクトに対する変更は結合１４２８とコンテキストオブジェクト１４３０を介してデータサービス１４００の内の適切な１つ以上に自動的に伝搬されてよい。他の場合、データ変更は（例えば、プロセス変数値の変更の結果として）データサービス１４００の１つ以上の中で発生してよく、変更はリソースマネージャ１４１６によって提供されるマッピング機能を介して、特性１４２０の内の適切な１つにコンテキスト１４３０と結合１４２８を介して自動的に伝搬されてよい。
【００６２】
データソースマネージャ１４３２は、データソースに関連する結合オブジェクト（例えば、結合オブジェクト１４２８）の集合体に関するクライアント状態情報を維持するために使用されるコンテキストオブジェクト（例えば、コンテキストオブジェクト１４３０）を作成、管理する。グラフィックユーザインタフェースと関連するディスプレイの場合、コンテキストオブジェクトとディスプレイの間には１対１の対応がある。言い換えると、ディスプレイごとに１つのコンテキストがあり、各々のコンテキストはそのディスプレイと関連する結合だけを含む。このように、図１４の例では、コンテキストオブジェクト１４３０は一意にディスプレイ１４１０に対応する。
【００６３】
コンテキストオブジェクトは、その内の一方はイベントベースであり、ありとあらゆるイベントに応えて更新を開始し、その内のもう一方が本来照合され、複数のデータ変更イベントを収集し、周期的に（例えば、タイマに基づいて）変更された結合アイテムのリストをタイマに応えてデータソースに送信することにより更新を始動するデータ更新機構も提供する。言うまでもなく、相対的に処理する多数のイベントがある場合、各イベントに個別に応えることは、実行時プロセス１４０８および全体的なプロセス制御システム（例えば、図１のプロセス制御システム１０）の性能を害することがある（例えば、反応性の鈍化）。したがって、周期的に（データは変化したが、実行時プロセスにまだ渡されていない）不正な結合のリストに応答して、全体的な性能が改善されうる。コンテキストオブジェクト１４３０とデータサービス１４００との間の接続は、例えばマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によって提供されているインディゴ（Ｉｎｄｉｇｏ）フレームワークを使用して実現されてよい。
【００６４】
図１４の例と関連する変更情報の流れはディスプレイ１４１０で開始され、リソースマネージャ１４１６、結合１４２８、データソースマネージャ１４３２およびコンテキスト１４３０を介してデータサービス１４００の内の１つ以上に自動的に伝搬されるものとして説明されているが、データ変更情報は、代わりにまたは加えて、データサービス１４００の内の１つ以上からディスプレイ１４１０に自動的に伝搬できるであろう。
【００６５】
図１５は、ユーザインタフェースディスプレイグラフィックスがデータサービスまたはソースにリンクされる、あるいは結合されてよい１つの方法の例を描いている。図１５に描かれているように、ディスプレイ（例えばディスプレイを提供するアプリケーションまたは他の実行時エンティティ）１５０２は、同様にパラメータまたはディスプレイコンテンツ１５０６と関連付けられるディスプレイ要素またはグラフィックス１５０４を含む。ディスプレイ１５０２は、１つ以上のプロセス制御関連アプリケーションと関連するユーザインタフェースであってよく、その場合、グラフィックス１５０４は、例えばプロセス制御値、ポンプ、バルブ等のプロセス制御デバイスのグラフィック表現を保持するためのテキストボックス等のプロセス制御関連グラフィックスであってよい。ディスプレイコンテンツ１５０６は、（たとえば、ディスプレイグラフィックス１５０４がテキストボックスである場合の）テキスト情報、プロセス状態（例えば、赤は所定の限度に近づいている、あるいは超えたパラメータ値および／または是正処置を講じる必要性を示してよい）を表す色（例えば、複数の塗り潰し色の内の１つ）、グラフィック要素（例えば、ファンまたはポンプインペラ）の回転速度、振動、移動等するモータまたは他のデバイスの三次元ビュー、および／または任意の他のコンテンツを含んでよい。
【００６６】
ディスプレイ１５０２は、同様にプロセスコンテキスト１５１０とプロセス結合１５１２に通信可能にまたは動作可能に結合されるリソースマネージャインスタンス１５０８に通信可能に、または動作可能に結合される。プロセスコンテキスト１５１０は、プロセス結合１５１２に照合されたデータ変更通知またはイベント駆動データ変更通知を提供するように構成されてよい。プロセス結合１５１２は、データソースまたはサービスの中の固定メモリ位置のデータを参照してよい、および／またはデータソースまたはサービス内のデータのエイリアスを参照してよい。プロセス結合１５１２は結合オブジェクト１５１４を介してディスプレイコンテンツ１５０６に通信可能に、または動作可能に結合される。
【００６７】
動作中、リソースマネージャ１５０８は、ディスプレイグラフィックス１５０４とディスプレイコンテンツ１５０６をレンダリングするためにディスプレイ１５０２によって使用されるデータコンテキストまたはパラメータを保持する。リソースマネージャ１５０８は、ディスプレイ１５０２と関連する特性の少なくとも１つを、プロセスコンテキスト１５１０により提供されるデータにマップする、関係させる、またはその他関連させて、データサービス（たとえば、図１４に図示されるデータサービス１４００の内の１つ）内に記憶されるデータのためのデータランディングサイトを提供する。言い換えると、プロセスコンテキスト１５１０は、例えばコンテキストオブジェクト１４３０（図１４）等のコンテキストオブジェクト、したがってデータサービスまたは他のデータソースからの情報をリソースマネージャ１５０８に、そして最終的にはディスプレイコンテンツ１５０６、したがってディスプレイ１５０２に動作可能にまたは通信可能に結合するための機能を使用して実現されてよい。プロセスコンテキスト１５１０は、プロセス結合１５１２に対して照合された方法で（例えば変更されたデータ情報の集合体を周期的に送信する）、あるいは各データ変更イベントに応えてプロセス結合１５１２にデータ変更情報を送信するように構成されてよい。プロセスコンテキスト１５１０は、リソースマネージャ１５０８が変更通知を必要とするデータのプロセスコンテキスト１５１０を通知する情報をリソースマネージャ１５０８から受信するように構成される。このようにプロセスコンテキスト１５１０はリソースマネージャ１５０８により保持されるディスプレイ１５０２のデータコンテキストと関連するデータに関係するデータ変更通知だけを提供するように構成されてよい。いずれの場合でも、プロセス結合１５１２が１つ以上のデータ値が変更した旨の通知をプロセスコンテキスト１５１０から受信すると、プロセス結合１５１２は（結合１５１４を介して）ディスプレイコンテンツ１５０６に新しい値（複数の場合がある）を結合してから、リソースマネージャ１５０８に変更通知を提供する。プロセス結合１５１２から変更通知を受信すると、リソースマネージャ１５０８はディスプレイ１５０２上で特性変更メソッドを呼び出し、それによりディスプレイ１５０２に新規に結合されたデータを組み込むために更新させる。
【００６８】
本明細書に説明されている機能ブロック又はオペレーションは、ソフトウェア、ファームウェアおよびハードウェアの任意の所望の組み合わせを使用して実現されてよい。例えば、１台以上のマイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）等は、メソッドを実施するため、本明細書に説明される装置を実現するために機械またはプロセッサがアクセス可能な機能媒体上に記憶されている命令またはデータにアクセスしてよい。記憶媒体は、例えばランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）等を含むソリッドステート記憶媒体、光記憶媒体、磁気記憶媒体等のデバイスおよび／または媒体の任意の組み合わせを含んでよい。加えて、機能ブロックを実現するために使用されるソフトウェアは、さらにまたは代わりに、インターネット、電話回線、衛星通信等を介してソフトウェアを実行するプロセッサまたは他の１台以上のデバイスに送達され、それらによってアクセスされてよい。
【００６９】
図１６は、本明細書に説明される装置および方法を実現するために使用されてよいプロセッサシステム例１６０２を描く。プロセッサベースのシステム例１６０２は、例えば、サーバ、パソコン、または任意の他のタイプのコンピューティング装置であってよい。
【００７０】
プロセッサ１６００は、例えば、ペンティアム（登録商標）（Ｐｅｎｔｉｕｍ（登録商標））ファミリ、アイテニアム（Ｉｔａｎｉｕｍ）（登録商標）ファミリ、またはＸＳｃａｌｅ（登録商標）ファミリの１台以上のインテル（Ｉｎｔｅｌ）（登録商標）マイクロプロセッサを使用して実現されてよい。言うまでもなく、他のファミリおよび企業の他のプロセッサも適切である。プロセッサ１６００は、バス１６０８を介して揮発性メモリ１６０４および不揮発性メモリ１６０６を含むメインメモリと通信している。揮発性メモリ１６０４は、同期型ＤＲＡＭ（ＳＤＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、ＲＡＭＢＵＳダイナミックアクセスメモリ（ＲＤＲＡＭ）および／または任意の他のタイプのランダムアクセスメモリデバイスによって実現されてよい。不揮発性メモリ１６０６は、フラッシュメモリおよび／または任意の他の所望のタイプの不揮発性メモリデバイスによって実現されてよい。メモリ１６０４に対するアクセスは、通常、従来の方法でメモリコントローラ（不図示）によって制御されている。
【００７１】
システム１６０２はインタフェース回路１６１０も含む。インタフェース回路１６１０は、例えば、システム１６０２が図１のリンク２４、３２、４０、４２、４６および４８の内の１つ以上を介して通信可能にきるようにするための任意のタイプの周知のインタフェース規格によって実現されてよい。
【００７２】
システム１６０２は、ソフトウェアおよび／またはデータを記憶するために１台以上の大量記憶装置１６１８も含む。このような大量記憶装置の例はフロッピー（登録商標）ディスクドライブ、ハードドライブディスク、コンパクトディスクドライブ、およびデジタル多用途ディスク（ＤＶＤ）ドライブを含む。
【００７３】
特定の方法および装置および製品が本明細書に説明されてきたが、本特許の範囲はそれに限定されない。むしろ本明細書は、字句通りに、または均等論の元でのいずれかにより添付請求項の範囲内に該当するすべての方法、装置および製品をカバーする。
【００７４】
（関連出願）
本願は、２００４年５月４日に出願され、本願がこれにより全体を本明細書に参照することにより明示的に組み込んでいる「プロセス制御システムを表現し、監視し、対話するためのグラフィックユーザインタフェース（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ ｆｏｒ Ｒｅｐｒｅｓｅｎｔｉｎｇ，Ｍｏｎｉｔｏｒｉｎｇ ａｎｄ Ｉｎｔｅｇｒａｔｉｎｇ ｗｉｔｈ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ）」と題される米国仮特許出願、出願番号第６０／５６７，９８０号の正規に出願された出願であり、その利益を主張する。本願は、全体の開示がこれによりその全体を本明細書に参照することにより明示的に組み込まれている、２００２年１０月２２日に出願され、２００４年４月２２日に特許文献１として公開された、同様に「プロセスプラントにおけるスマートプロセスモジュールおよびオブジェクト（Ｓｍａｒｔ Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ａｎｄ Ｏｂｊｅｃｔｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」と題される米国特許出願、出願番号第１０／２７８，４６９号の一部継続出願である、２００３年7月２１日に出願され、２００４年８月５日に特許文献２として公開された「グラフィックディスプレイ要素、プロセスモジュールおよび制御モジュールのプロセスプラントにおける統合（Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｅｌｅｍｅｎｔｓ，Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ａｎｄ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」と題される米国特許出願、出願番号第１０／６２５，４８１号にも関連する。本願は、全体の開示がこれによりその全体を本明細書に参照することにより明示的に組み込まれている、２００３年２月１８日に出願され、２００４年１０月７日に特許文献３として公開された「プロセスプラント構成システムにおけるモジュールクラスオブジェクト（Ｍｏｄｕｌｅ Ｃｌａｓｓ Ｏｂｊｅｃｔｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｐｌａｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｙｓｔｅｍ）」と題される米国特許出願、出願番号第１０／３６８，１５１号にも関連する。本願は、本願と同日に国際（ＰＣＴ）出願として出願され、本願がこれにより全体を本明細書に参照することにより組み込んでいる以下の特許出願にも関連する。つまり、「プロセス環境における関連グラフィックディスプレイ（Ａｓｓｏｃｉａｔｅｄ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１１号）、「プロセス制御システムのためのユーザにより構成可能なアラームおよびアラームトレンド分析（Ｕｓｅｒ Ｃｏｎｆｉｇｕｒａｂｌｅ Ａｌａｒｍｓ ａｎｄ Ａｌａｒｍ Ｔｒｅｎｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ）」（代理人整理番号第０６００５／４１１１２号）、「プロセスプラントのプロセスモジュールとエキスパートシステムとの統合（Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ａｎｄ Ｅｘｐｅｒｔ Ｓｙｓｔｅｍｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」（代理人整理番号第０６００５／４１１１３号）、「統合された環境におけるカスタマイズされたプロセスグラフィックディスプレイ層を有するプロセスプラントユーザインタフェースシステム（Ａ Ｐｒｏｃｅｓｓ Ｐｌａｎｔ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ Ｓｙｓｔｅｍ Ｈａｖｉｎｇ Ｃｕｓｓｔｏｍｉｚｅｄ Ｐｒｏｃｅｓｓ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｌａｙｅｒｓ ｉｎ ａｎ Ｉｎｔｅｇｒａｔｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１４号）、「プロセス環境におけるスクリプト化されたグラフィック（Ｓｃｒｉｐｔｅｄ Ｇｒａｐｈｉｃｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１５号）、「プロセス構成および制御環境へのグラフィック統合（Ｇｒａｐｈｉｃｓ Ｉｎｔｅｇｒａｔｉｏｎ ｉｎｔｏ ａ Ｐｒｏｃｅｓｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｃｏｎｔｒｏｌ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１６号）、「プロセス環境における複数の視覚化のあるグラフィック要素（Ｇｒａｐｈｉｃ Ｅｌｅｍｅｎｔ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｅｎｖｉｒｏｎｍｅｎｔ）」（代理人整理番号第０６００５／４１１１７号）、「プロセスプラントにおいてグラフィックディスプレイ要素およびプロセスモジュールを構成するためのシステム（Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｆｉｇｕｒｉｎｇ Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｅｌｅｍｅｎｔｓ ａｎｄ Ｐｒｏｃｅｓｓ Ｍｏｄｕｌｅｓ ｉｎ Ｐｒｏｃｅｓｓ Ｐｌａｎｔｓ）」（代理人整理番号第０６００５／４１１１８号）、「統合プロセス制御システムイシステムインタフェースのためのグラフィックディスプレイ構成フレームワーク（Ｇｒａｐｈｉｃ Ｄｉｓｐｌａｙ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｕｎｉｆｉｅｄ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）」（代理人整理番号第０６００５／４１１２４号）、「プロセスプラントユーザインタフェースにおけるマークアップ言語をベースにした動的プロセスグラフィックス（Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ−Ｂａｓｅｄ，Ｄｙｎａｍｉｃ Ｐｒｏｃｅｓｓ Ｇｒａｐｈｉｃｓ ｉｎ ａ Ｐｒｏｃｅｓｓ Ｐｌａｎｔ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）」（代理人整理番号第０６００５／４１１２７号）、「プロセス制御データを修正するための方法および装置（Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｍｏｄｉｆｙｉｎｇ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｄａｔａ）」（代理人整理番号第０６００５／５９１６２２号と第２００４０／５９−１１６２２号）、「プロセス制御データにアクセスするための方法および装置（Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｃｃｅｓｓｉｎｇ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｄａｔａ）」（代理人整理番号第０６００５／５９１６２３号および第２００４０／５９−１１６２３号）、「プロセス制御システムのための統合グラフィック実行時インタフェース（Ｉｎｔｅｇｒａｔｅｄ Ｇｒａｐｈｉｃａｌ Ｒｕｎｔｉｍｅ Ｉｎｔｅｒｆａｃｅ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍｓ）」（代理人整理番号第０６００５／５９１６２８号および第２００４０／５９−１１６２８号）である。
【符号の説明】
【００７５】
１６００ プロセッサ
１６０２ プロセッサシステム
１６０４ メインメモリ
１６０６ 不揮発性メモリ
１６１０ インタフェース回路
１６１８ 記憶装置
【特許請求の範囲】
【請求項１】
実行時アプリケーションに情報を結合する方法であって、
該実行時アプリケーションと関連するデータコンテキストをリソースマネージャに提供することと、
変数、スクリプト、またはデータソース参照の内の少なくとも１つと、該データコンテキストからの少なくとも１つのプロキシを、該リソースマネージャを介して関連付けることと、
該変数、該スクリプト、または該データソースの内の該少なくとも１つに該少なくとも１つの特性を結合することと、
を備える方法。
【請求項２】
該データソース基準に該少なくとも１つの特性を結合するためにコンテキストオブジェクトを使用することをさらに備える請求項１に記載の方法。
【請求項３】
該実行時アプリケーションが、グラフィックユーザインタフェースを備える請求項１に記載の方法。
【請求項４】
該データソースが、実行時サービスを備える請求項１に記載の方法。
【請求項５】
グラフィックユーザインタフェースを更新する方法であって、
該グラフィックユーザインタフェースと関連するパラメータにデータソース値を結合することと、
該パラメータと関連するデータ変更通知をリソースマネージャに提供することと、
該グラフィックユーザインタフェースに、該変更通知に対応するデータ変更を反映すべく更新させるために、該リソースマネージャを介して、該グラフィックユーザと関連するメソッドを呼び出すことと、
を備える方法。
【請求項６】
該データソース値と該グラフィックユーザインタフェースが、プロセス制御システムと関連付けられる請求項５に記載の方法。
【請求項７】
該グラフィックユーザインタフェースと関連する該パラメータに変数またはスクリプトの内の少なくとも１つを結合することをさらに備える請求項５に記載の方法。
【請求項８】
該パラメータが、該グラフィックユーザインタフェースのためのディスプレイグラフィックスと関連するコンテンツに対応する請求項５に記載の方法。
【請求項１】
実行時アプリケーションに情報を結合する方法であって、
該実行時アプリケーションと関連するデータコンテキストをリソースマネージャに提供することと、
変数、スクリプト、またはデータソース参照の内の少なくとも１つと、該データコンテキストからの少なくとも１つのプロキシを、該リソースマネージャを介して関連付けることと、
該変数、該スクリプト、または該データソースの内の該少なくとも１つに該少なくとも１つの特性を結合することと、
を備える方法。
【請求項２】
該データソース基準に該少なくとも１つの特性を結合するためにコンテキストオブジェクトを使用することをさらに備える請求項１に記載の方法。
【請求項３】
該実行時アプリケーションが、グラフィックユーザインタフェースを備える請求項１に記載の方法。
【請求項４】
該データソースが、実行時サービスを備える請求項１に記載の方法。
【請求項５】
グラフィックユーザインタフェースを更新する方法であって、
該グラフィックユーザインタフェースと関連するパラメータにデータソース値を結合することと、
該パラメータと関連するデータ変更通知をリソースマネージャに提供することと、
該グラフィックユーザインタフェースに、該変更通知に対応するデータ変更を反映すべく更新させるために、該リソースマネージャを介して、該グラフィックユーザと関連するメソッドを呼び出すことと、
を備える方法。
【請求項６】
該データソース値と該グラフィックユーザインタフェースが、プロセス制御システムと関連付けられる請求項５に記載の方法。
【請求項７】
該グラフィックユーザインタフェースと関連する該パラメータに変数またはスクリプトの内の少なくとも１つを結合することをさらに備える請求項５に記載の方法。
【請求項８】
該パラメータが、該グラフィックユーザインタフェースのためのディスプレイグラフィックスと関連するコンテンツに対応する請求項５に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１１−１３４３５０（Ｐ２０１１−１３４３５０Ａ）
【公開日】平成２３年７月７日（２０１１．７．７）
【国際特許分類】
【出願番号】特願２０１１−６２８５９（Ｐ２０１１−６２８５９）
【出願日】平成２３年３月２２日（２０１１．３．２２）
【分割の表示】特願２００７−５１１５２１（Ｐ２００７−５１１５２１）の分割
【原出願日】平成１７年５月３日（２００５．５．３）
【出願人】（５０６２６６０２３）フィッシャー−ローズマウント・システムズ・インコーポレーテッド (37)
【氏名又は名称原語表記】Ｆｉｓｈｅｒ−Ｒｏｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ， Ｉｎｃ．
【Ｆターム（参考）】
【公開日】平成２３年７月７日（２０１１．７．７）
【国際特許分類】
【出願日】平成２３年３月２２日（２０１１．３．２２）
【分割の表示】特願２００７−５１１５２１（Ｐ２００７−５１１５２１）の分割
【原出願日】平成１７年５月３日（２００５．５．３）
【出願人】（５０６２６６０２３）フィッシャー−ローズマウント・システムズ・インコーポレーテッド (37)
【氏名又は名称原語表記】Ｆｉｓｈｅｒ−Ｒｏｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ， Ｉｎｃ．
【Ｆターム（参考）】
[ Back to top ]