JP4722888B2 - フィールドデバイスコンフィギュレーションへのチェンジのレコードのトランザクションデーターベースを管理する為のシステム及び方法 - Google Patents

Description

本発明は、広義にはデーターベース管理に関し、詳細にはプロセス内で、スマートフィールドデバイスのパラメーターに起きた変化の為のトランザクションレコードのデーターベースを保守する為のデーターベース管理のシステム及び方法に関する。

代表的には、プロセス工場（例えば、化学精製工場及び薬品製造工場）はそのプロセス内のパラメーターを制御、測定するフィールドデバイスを多数持つ。各フィールドデバイスは制御デバイス（流体バルブコントローラーの如き）、測定器（温度ゲージ、プレッシャーゲージ、流量計等）及び／又はプロセスと関連する値に影響し或いはそれを決定する他の如何なるデバイスを含み得る。過去１０年ぐらい迄は、フィールドデバイスは代表的には、どちらかと言えば単純なデバイスであって手動或いは電子的に制御されその出力を電子的に表示したり或いはそのデバイスに接続されたゲージに表示するものであった。しかしながら、これらのデバイスは代表的には、これらのデバイスによって得られた表示値或いは測定値に関するアナログ信号のごとき限定的な情報を制御器に提供するのみであった。

最近では、所謂「スマート“フィールドデバイスが開発された。スマートフィールドデバイスはそのデバイスに関連するプロセスコントローラー及び／又は管理システムと通信する事が出来る。代表的なスマートフィールドデバイスはそのデバイスに関連する値、例えば測定値、を示すアナログ信号を送信する事ができ、校正、構成、診断、保守及び／又はプロセス情報を含む詳細なデバイス特有の情報をストアしたり亦デジタル的に送信することも出来る。或スマートデバイスは例えば、デバイスが測定に用いる単位、デバイスが正確に作動可能な最大範囲、デバイスに就いてのトラブルシューテイング情報、デバイスをどの様に、そして何時校正すべきか等をストアし且つ送信する事が出来る。更に、スマートデバイスはそれ自身動作可能で、自己テスト、自己校正等を行う事が出来る。例えばスマートデバイスはハート（ＨＡＲＴ、ハイウエーアドレス可能遠隔トランスデューサー）プロトコル（ハートデバイス）、フィールドバスプロトコル（フィールドデバイス）、Ｍｏｄバスプロトコル及びＤＥプロトコル等に従うデバイスを含む。しかしながら、異なったタイプのスマートデバイスをサポートする為に他のスマートデバイスプロトコルが存在可能であり或いは将来開発可能である。

現在、従来式のスマートデバイスはすべて或プロセスに関し、一又はそれ以上の特別な入出力機能を持つ。入力機能とは温度又は圧力測定デバイスによって実行される機能のような、あるプロセスに関連する値を測定或いは読む如何なる機能をも言う。出力機能とはバルブ又は流量コントローラーによって行われるような或プロセス内の或ものを変化する如何なる機能をも言う。更に、フィールドバスデバイスの様な、ある種のスマートデバイスはプロセス制御に関連する機能である制御機能を行う。デバイスに依って行われる各入力、出力及び制御部分機能はブロックと呼ばれる。従って、定義により、各デバイスは少なくとも、一つ及び恐らくそれ以上のブロックを含む。フィールドバスデバイスは通常多重ブロック（即ち、一又はそれ以上の入出力及び制御ブロック）含み、一方ハートデバイスは、それ自体ブロックを持たないが、ハートデバイスの内容は当業者によって唯一つのブロックを構成するものとして考えられている。

各ブロック（概念上のブロック）及び、従って各デバイスは一又はそれ以上のパラメーターを有する。パラメーターはそのブロックを特徴づけ、影響を及ぼし、或いは別の態様で関係するブロックの一属性である。パラメーターは、例えば、ブロックのタイプ、ブロックの最大動作或いは測定範囲、ブロックのモード、ブロック測定値等である。

同様に、各パラメーターはそれに関連する一又はそれ以上のプロパテイを持っており、そのプロパテイの各々はパラメーター内の情報を定義し、或いは記述する。例えば、温度測定デバイスの温度パラメーターは、パラメーターの名前（例えば「温度」）をストアするラベルプロパテイ、パラメーターの値（例えば温度実測値）をストアする値プロパテイ及び温度が表現される単位（例えば摂氏度或いは華氏度）をストアする単位プロパテイからなる。デバイス或いはブロック構成はそのデバイス又はブロック関連の各パラメーターの各プロパテイの値のセットを含む。

上述のように、スマートフィールドデバイスは数種の利用可能なプロトコル（例えばハート及びフィールドプロトコル）の一つに於いて通信可能なように開発される。これらのプロトコルはデバイス製造者にそのデバイス特有の情報を提供する事を許容し、勿論特定の情報はスマートフィールドデバイスの型に依って異なる。従って、これらのプロトコルは複雑であり、デバイスプログラミングにおいて使用上困難がある。更に詳細に述べるならば、これらのプロトコルの或ものは、それに従うすべてのスマートデバイスとの通信の為の完全に整合性を有する方法を提供しない。その代わりこれらのプロトコル、例えばハートプロトコル、は単にデバイス製造者に対し各スマートフィールドデバイスから得られる情報且つその情報の検索方法を特定する方法を提供するたけである。

スマートデバイスとの通信は或程度スマートデバイス製造者の提供するデバイス記述言語（ＤＤＬ）及びデバイス記述サービス（ＤＤＳ）の出現によって単純化された。ＤＤＬはスマートデバイから得られるデーターを記述する為のプロトコル、スマートデバイスに関連し、其れから検索されるデータの意味、スマートデバイスの実働化の為の方法、データーを取る為のスマートデバイスと通信する為のフォーマット、編集表示及びメニューの如きデバイスに就いて及びスマートデバイスの係る他の情報のハンドリング及びインタープリトの為のユーザーインタフェース情報を提供する人間可読言語である。

ＤＤＬソースファイルはデバイス開発者によって書かれた人間可読テキストを含む。これらのファイルはデバイスに関し、デバイスとバス或いはデバイスが接続されるホストとの間のすべての情報を特定化する。基本的には、デバイスの為のＤＤＬソースファイル開発に際しては、開発者は、各ブロック、パラメーター及びスマートデバイスの特別な特徴に関係するグループ特有の、及び販売者特有の定義を提供する為は勿論、デバイスのコア或いは本質的なパラメーター特性を記述する為にＤＤＬ言語を使用する。

ＤＤＬソースファイルは管理システムの如きホストシステムにストアされる様デバイス製造業者或いは第３者開発者によってユーザーに提供されうる、デバイス記述（ＤＤ）として知られる機械可読ファイルを作る為にバイナリフォーマットに編集される。或場合には、例えばフィールドデバイスでは、ＤＤＬソースファイルはスマートデバイス内にストアされ得、スマートデバイスからホストシステムに転送し得る。ホストシステムがスマートデバイスの為のＤＤオブジェクトファイルを受領した時は、デバイスとの完全なインタフェイス記述を導き出す為にＤＤをデコード及びインタプリトする事が出来る。

ＤＤＳはＦｉｓｈｅｒ−Ｒｅｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ，Ｉｎｃ．及び／又はＲｏｓｅｍｏｕｎｔ，Ｉｎｃによって、スマートデバイスのＤＤを自動的にデコーデイング且っインタプリテイングする為に開発され提供された汎用ソフトウエアシステムである。更に詳細には、ＤＤＳはルーテインのライブラリであって、ホストによってコールされた時、１）スマートデバイスのセットアップ及び構成、（２）スマートデバイスとの通信、（３）ユーザーインタフェイス及び（４）スマートデバイスと結合して使用される場合の可能な方法に関する情報を含むスマートデバイスに関する情報をホストに提供する為にスマートデバイスのＤＤをインタプリトする。ＤＤＳの一つの非常に有効な応用例はホストシステムと関連するＤＤＬソースファイル（そして対応のＤＤオブジェクトファイル）を持つ一又はそれ以上のスマートデバイスどの間に整合性のあるインタフェイスを提供する場合である。

ＤＤＳ，ＤＤＬ及びＤＤは公知であるが、ＤＤＬの特定の機能及びフォーマットに関する一層の情報及び特にフィールドバスのＤＤＬに就いての情報は Ｉｎｔｅｒｏｐｅｒａｂｌｅ Ｓｙｓｔｅｍ Ｐｒｏｊｅｃｔ Ｆｉｅｌｄｂｕｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ と言うタイトルで Ｉｎｔｅｒｏｐｅｒａｂｌｅ Ｓｙｓｔｅｍ Ｐｒｏｊｅｃｔ Ｆｏｕｎｄａｔｉｏｎ（１９９３）のマニュアルに含まれている。これは参照文献として本明細書に含まれる。ハートＤＤＬに関する同様な文献はｔｈｅ ＨＡＲＴ ｆｏｕｎｄａｔｉｏｎによって提供されている。

管理システムは一つ又はそれ以上のスマートデバイスと相互に作用するシステムであって、デバイス、ブロック、パラメーター、変数或いはこれらのデバイスに関連する構成情報を読む。代表的には、管理システムは、スマートデバイスと相互接続し、通信し且つ其れを再構成することを許す適当な通信ポートを有するパーソナルコンピューターを含む。管理システムはオンラインであり、即ちスマートデバイスと有線或いは他の恒久的な接続が為されている。管理システムは持ち運び可能とする事ができ、スマートデバイスを再構成する為に周期的にスマートデバイスに接続されても良い。

管理システムは代表的にはシステム内でスマートデバイスに関し多様な機能を実行する。例えば、管理システムは或プロセスの状態及び同プロセスに関連或いは接続しているスマートフィールドデバイスに関しての情報（即ち、変数やパラメーターの値）を提供しても良い。管理システムは必要に応じ、プロセス内でスマートデバイスを再構成する事によってユーザがプロセスをモニターしコントロールする事が出来るように使用され得る。

本システムに依って提供される特徴を使用して管理システム内で諸機能を実行する為に用いられるソフトウエアルーテインは代表的にはアプリケーションと呼ばれる。代表的には、管理システムは特定のスマートデバイス上で変化を実行し且つそれからデーター読み取る為に個々のスマートデバイス製造者によって提供されるアプリケーションを実行する。その結果、管理システム内の各種アプリケーションは屡共通の或いは整合性のあるインタフェイスを共有するする事が出来ず、一つのアプリケーションから他のアプリケーションに移行する事は従って、面倒な時間のかかる作業となる。更に、異なったアプリケーションで作られ、且つストアされたスマートデバイス構成データー、構成ログ及びスマートデバイス診断データーは、異なったデーターベースで多様なフォーマットでストアされており、そして或場合には、所有権の絡むフォーマットにストアされている為に、分散不可能であり、相互参照も不可能である。従って、或システム内で、各デバイスに共通な課題が別のアプリケーションでは重ねて行わなければならない。

別々に開発されたアプリケーションを実行する管理システムは代表的には、各デバイスのアプリケーションは別々日稼動しているので、同時に或工場又は或プロセスにおいてすべてのスマートデバイスに関する情報を見ることはない。ユーザーがプロセス内のデバイスに関連するＤＤＳ、ＤＤＬ及びＤＤに対し、十分な知識をもつことは通常ないので、更に或プロセス内の複数の、異なったデバイスに関するデーターを総括的に見るアプリケーションをユーザーが書くことは不可能である。もし仮にユーザーが十分な知識を持っていたとしても、かかるアプリケーションは開発に時間がかかり亦費用を要し、しかもシステムに新しいスマートデバイスが加わるごとに、同アプリケーションの更新が必要となる。

統合された管理システムの必要性は、そのプロセスに依って作られる製品に、排出物が一定のレベル以下である事、及び安全手続きが基準に合っている等厳密な基準が課せられている、例えば、ある種の化学及び医薬品プロセスを規制するＥＰＡ及びＦＤＡの如き政府機関によって認定されなければならないプロセス或いはシステムでは特に大きい。かかる認定を維持する為の規制されたプロセスを実施する為の工場にとって最も容易な方法は重要なプロセスパラメーターの値が、関連の政府機関の規制必要基準及び安全手続きに従う特定の値或いは特定の範囲に留まっている事を政府検査官に証明する十分に徹底した記録を保持する事である。プロセスのスマートデバイス結合した統合システムは、これらの値をデーターベース内に自動的に記録するように用いられる。従って、統合システムのデーターベースにストアされたデーターはこれらの重要な値が夫々の基準値範囲に留まっている事を証明するのに使用され得る。

以前では、管理システムが制御システムにおけるフィールドデバイスの状態を変えた時は（フィールドデバイス内のどの情報を変えた時も）常に、管理システムは内部の「状態データーベース」内に、デバイスの為の完全に新しい或いは現在「状態」をストアした。デバイスの「状態」とは（１）何時変化が起きたか（即ち何時デバイスが新し状態に置かれたか）の表示、及び（２）デバイス内にストアされたすべての情報に対応するデータである。先行技術の状態データーベースはまたデバイスの状態に加えて付加的な情報（即ち何がデバイス状態の変化を起こしたか或いは何故に就いての情報）を含み得た。

この様な態様で状態データーベースを保持する事及び制御システムのそのフィールドデバイスになされた変化の際に常に新しい状態に対応する完全なセットの変数をストアする事は大きな記憶容量と多大なプロセシング時間を必要とする。更に、多重オンライン管理システムは代表的には相互接続され、各システムからのデータは全制御システムの状態を反映する為統合された履歴データベースを構成する為に結合される。各新状態に対応する時間の多重相互接続状態データーベースの記録内の表示の存在は多重データーベースをかかる統合履歴データーベースに開発することを許すけれども、先行技術の管理システムが、携帯通信機と直接インタフェイスし、そして携帯通信機から管理システム内にデーターを転送する事が出来ないと言う良く知られた欠点を克服する事は出来ない。その理由は、極めて原始的な器具である現在の携帯通信機が内部にリアルタイムクロックを持たず、従って、管理システムに携帯通信機が戻す状態記録にタイムスタンプを付す事が出来ないからである。結局、管理システムは時系列的に且つ歴史的なデータベースにおいて、現存する時系列データーベースに対しその新状態をストアする為に携帯通信機から受信した記録又は新状態を挿入すべき特定の時間を決定する事が出来ない。

統合管理システムはまたデバイスが使用されるプロセスの保証性を保持する為にスマートデバイスをもっと規則的に再構成する為に使用される。現在大部分の、複数のスマートフィールドデバイスをサポートする管理システムは、そのサポートされるスマートデバイスの各々の為に書かれた特定化されたソフトウエアを含み、そのスマートデバイスと通信する事が可能である。従って、新しいスマートデバイスをプロセスに加える事は、そのプロセスの為の管理システムが再プログラムされる事を要求する。再度申し上げるが、このプログラミングは、管理システムのソフトウエアのみならずスマートデバイスプロトコル及び新スマートデバイスに就いても知識を持つ人間によって、作られなければならないので、時間がかかり，且つ費用を要する。

特別なプロトコルに従う異なったスマートデバイスとインタフェイスする携帯用通信機が存在するが、これらのデバイスは単にデバイスとの間でデーターを読み書きするだけで、如何なる有意義な態様でそのデーターを処理する事は出来ない。

アプリケーション開発の他の面倒な局面は、あるシステム内の各スマートデバイスとユーザーとの間の通信における、是に関連する或いはこの為に必要な多数の課題を実施する為のアプリケーションをプログラムする事である。開発者は各分離したデバイスとどのように通信するかと言う事を含む詳細について注意を向けなければならないし、同時に開発者は、例えばデイスプレーなどユーザーにどのようにして情報を提供するかについても特別な注意を払はなければならない。代表的なアプリケーションは一定のユーザーインタフェイスを使用しないので、この課題はもっと難しいものとなる。これら機能の各々は多くのプログラミング時間と努力を要求し、それはシステムに新しいスマートデバイスが加わるごとに繰り返されなければならないのである。

更に、アプリケーションは代表的には、プロセス内のデバイス、ブロック或いはの現在構成を見る事をユーザに許すが、そのアプリケーションはユーザに過去の構成を見る事或いはその構成を比較する為の多重構成の同時デイスプレーを許さない。

本発明の１態様では、装置データを有するフィールドデバイスと通信する様に設計されたフィールドデバイス管理システムにおいて、当該装置データは当該装置データのサブセットを含むデバイス記述と関連づけられているフィールドデバイス管理システムであって、前記フィールドデバイスと通信する通信手段と、前記デバイス記述内に含まれた前記装置データのサブセットを獲得するために前記デバイス記述を解釈するための解釈手段と、前記装置データに関連する情報の範疇の階層を保持するための保持手段であって、当該範疇と関連する当該装置データに関連した通信方法を決定するために当該範疇の各々と関連する手段を包含する保持手段と、前記装置データの一部及び前記通信手段に関連するコマンドを始動するための始動手段と、前記情報の範疇の所定の階層の前記範疇の一つに関連するようにコマンドを分類するための分類手段と、前記通信手段と前記解釈手段を前記範疇の一つと関連する通信方法に基づいて制御するための前記分類手段に呼応する手段とを備えている。

上記のフィールドデバイス管理システムにおいて、更に前記装置データの第２の部分を保持するためのデータベースと、前記データベースとインターフェースするためのインターフェース手段と、前記範疇の一つと関連する通信方法に基づいて前記インターフェース手段を制御するための前記分類手段に呼応する手段を包含してもよい。また、前記装置データの第２の部分がフィールドデバイスの過去の形状に関するデータを包含してもよい。また、前記始動手段は、前記フィールドデバイス、前記デバイス記述、前記データベースの一つから装置データを検索するためのコマンドを始動してもよい。また、前記始動手段は前記フィールドデバイスと前記データベースのうちの一つで装置データを保持するためのコマンドを始動してもよい。また、前記始動手段は、フィールドデバイスに所定の機能を実行させるためのコマンドを始動させてもよい。また、前記情報の範疇の所定の階層はフィールドデバイスの物理的な連結性に関する範疇を包含し、前記フィールドデバイスの形状に関する範疇を包含してもよい。また、前記フィールドデバイスは、入力、出力、フィールドデバイスの管理機能の一つを形成する機能ブロックを包含し、前記情報の範疇の所定の階層は、フィールドデバイスブロックを形成する範疇を包含してもよい。また、前記情報の範疇の所定の階層は、情報の複数の範疇の間での相互関連を特定するための手段を包含し、特定の相互関連に基づいて情報の複数の範疇の内の二つの範疇間でメッセージを送り、前記通信手段と前記解釈手段を制御するための手段を包含してもよい。また、前記情報の範疇の階層内で範疇の中の選択された範疇の位置に基づいて選択された範疇に名前を割り当てるための手段を包含してもよい。また、前記保持手段は、オブジェクト指向プログラミングパラダイムにおける一組のオブジェクトを包含してもよい。また、前記通信手段は携帯通信装置を介してフィールドデバイスと通信するための手段を更に包含してもよい。

図１は、以下でフィールド管理解システム（ＦＭＳシステム）と呼ぶ管理システム１０が、プロセス１２、プロセス１２を制御するディジタル制御システム１４（ＤＣＳ）、および別のＦＭＳシステム１５などさらなる管理システムと相互接続されている状態を示す。プロセス１２は、製造工程または精練工程など、所望の種類のプロセスから構成することができ、３つのＨＡＲＴデバイス１６、１９、２０および１つのフィールドバス２２を含む４つのスマートフィールドデバイスと、従来型（すなわち非スマート）デバイス２４とを含むものとして示されている。デバイス１６、１８、２０、２２、２４は、所望の方法でディジタル制御システム１４によって制御される。

一般に、ＦＭＳシステム１０はＰＣを使用するソフトウェアツールであり、フィールドデバイスの管理タスクを実行する応用プログラムを含む。ＦＭＳシステム１０は、ユーザがプロセス１２に対応付けられるスマートフィールドデバイスのいずれかおよび全部を例えば構成、校正、監視、および障害探索するのを助けることによって、プロセス１２内のデバイスの各々のデバイス管理を統合する。

ＦＭＳシステム１０は、任意の種類のコンピュータまたはマイクロプロセッサを使用するシステムで構成することができ、オペレーティングシステムおよびＣＰＵ３６に接続されたディスプレイ３０、プリンタ３１、キーボード３２、およびマウス３４を含むことができる。ＦＭＳデータベース４０を備えたメモリ３８は、オペレーティングシステムおよびＣＰＵ３６に接続される。ＦＭＳデータベース４０を含むメモリ３８は、ディスプレイ３０またはプリンタ３１を介して情報をユーザに表示したりスマートデバイス１６、１８、２０、２２と通信することに関連するタスクを実行する際に、ＦＭＳシステムによって使用されるソフトウェアおよびデータを保存する。さらにＦＭＳデータベース４０は、例えばデバイスの過去の構成に関する情報、オフラインスマートデバイスや従来型デバイスなどのオフラインデバイスに関する情報、および次のサービスがいつ必要になるか、誰がサービス手順を実行したか、望ましい交換デバイス等を含むサービスノートに関する情報など、スマートデバイスからは得られないデバイス関連情報を保存する。オフラインスマートデバイスに関するデータは、そのデータが実際にオフラインデバイス内に保存される形式と同一の形式で、データベース４０内に保存することができるので、ＦＭＳシステム１０にとって、オフラインデバイスは、これらのデバイスがオンラインの場合に利用できるのと同様の方法で、データベース４０を介して利用できるように見える。

スマートデバイス１６、１８は、通信回線４２およびモデム４４を介してＦＭＳシステムに接続されたオンラインデバイスである。スマートデバイス２２は、フィールドバスインタフェース４５を介してＦＭＳシステムに接続されたオンラインデバイスである。スマートデバイス２０は、ＦＭＳシステム１０に永久接続されないオフラインデバイスである。しかし、スマートデバイス２０は、デバイス２０および／または他のスマートデバイスからデータを読み出したり、そこへデータを書き込むために、後で詳述するようにデバイス２０および／または他のスマートデバイスのどれにでも定期的に接続できるハンドヘルドコミュニケータおよび／または２次（ラップトップ）ＦＭＳ４６を介して、ＦＭＳシステム１０と通信することができる。その後、ハンドヘルドコミュニケータおよび／または２次ＦＭＳ４６をＦＭＳシステム１０に接続し、それが接続されたスマートデバイス２０および／またはその他のいずれかのスマートデバイスに関するデータをアップロードすることができる。

希望すれば、ＦＭＳシステムのオペレーティングシステムおよびＣＰＵ３６を、例えばイーサネット（登録商標）通信リンク４８および／またはその他の通信リンクを介して、ディジタル制御システム１４および他のＦＭＳシステム、例えばもう１つのＦＭＳシステム１５に接続することができる。

図２は、ハードウェアおよびソフトウェアコンボーネントを含むＦＭＳシステム１０の様々な構成部品間の相互接続を示すものであり、ＦＭＳシステム１０のメモリ３８に保存された様々なソフトウェアコンポーネントが相互同士、およびディスプレイ３０、プリンタ３１、キーボード３２、マウス３４、ＦＭＳデータベース４０、およびプロセス１２内のスマートデバイスと、いかに相互作用するかを説明するために使用される。ＦＭＳシステム１０のソフトウェアコンポーネントは、メモリ３８に保存され、オペレーティングシステムおよびＣＰＵ３６上で実行することを理解されたい。

ＦＭＳシステム１０はマイクロソフトウィンドウズ（登録商標）環境（ウィンドウズ（登録商標）９５ＴＭ環境など）で動作することが望ましく、したがって、標準ウィンドウズ（登録商標）〜オペレーティングシステム４６を含み、これは、データや情報をディスプレイ３０やプリンタ３１に表示したり、データや情報をキーボード３２やマウス３４から検索するために使用される。したがって、ウィンドウズ（登録商標）オペレーティングシステム４６に提供されたり、そこから検索される情報は、当業者には周知である所望の種類の標準ウィンドウズ（登録商標）呼出しフォーマットで提供することが望ましい。しかし、本発明では、例えばマッキントッシュ、Ｘウィンドウズ（登録商標）、またはＩＢＭ ＤＯＳフォーマットをはじめ、その他の所望のウィンドウズ（登録商標）系または非ウィンドウズ（登録商標）系のインタフェースフォーマット（グラフィカルユーザインタフェースであるか否かに関係なく）を使用して、ＦＭＳシステム１０を実現することができる。

ＦＭＳシステム１０は、コアアプリケーション５２およびアドオンアプリケーション５４から構成される１組のＦＭＳアプリケーションを含む。コアアプリケーション５２は基本的に、予め定められ頻繁に使用される動作を実行するために、ＦＭＳシステム提供者によって作成されたプログラムである。アドオンアプリケーションは、ユーザまたは第３者開発業者によって作成され、カスタマイズされた機能を実行するためにＦＭＳシステム１０に移入された応用プログラムである。

以下で使用するアプリケーションとは、ＦＭＳシステム１０によって実現されるソフトウェアルーチンを指し、これは、プロセス１２または１つ以上のデバイス、ブロック、パラメータに関連するユーザ情報、またはＦＭＳシステム１０に接続または対応付けられたデバイスに対応付けられたその他の情報を表示したり、ＦＭＳシステム１０に対応付けられるか接続された１つ以上のデバイスをユーザに再構成させることができる。アプリケーションによって使用される情報は一般的にプロセス１２内のスマートデバイスに保存されるか、またはこれによって作成され、あるいはＦＭＳデータベース４０に保存される。

したがって、例えば、ＦＭＳシステム１０は、ユーザがＦＭＳデータベース４０内および／またはプロセス１２内部のスマートデバイス内のデータと相互作用して、プロセス１２内のデバイスの１つ以上の現在の状態を表示したり、プロセス１２内のスマートデバイスの１つ以上の構成を変更したり、複数のデバイスを同時にまたは逐次的に表示したり、共通スマートデバイス制御および構成機能を実行したり、ネットワーク内でデバイスを位置決めするブラウザを実行したり、デバイスの状態を監視したり、アラームリストを生成したり、デバイスの校正および検査ルーチンを実現することを可能にするコアまたはその他のアプリケーションを含むことができる。

その他の一般的なコアアプリケーションとして、構成アプリケーション、構成管理アプリケーション、アラーム走査アプリケーション、履歴イベントログアプリケーション、レポートアプリケーション、トレンド解析アプリケーション、および診断アプリケーションを挙げることができる。構成アプリケーションは、プロセス内のデバイスの１つ以上のパラメータに対応付けられる変数の値を表示し、これらのパラメータ値のうち適切な幾つかをユーザに変更させることができる。構成管理アプリケーションは、例えばデバイスのリセット、デバイスの初期化、およびデバイスの校正など、デバイス全体の構成をユーザに管理させる。アラーム走査アプリケーションは、ＦＭＳシステム１０によって管理されている全てのデバイスを検査し、これらのデバイスが正しく作動しているかどうか、あるいはこれらのデバイスのどれかに誤りが発生していないかどうかを決定する。履歴イベントログアプリケーションは、例えばユーザログイン情報、ＦＭＳシステム１０によって管理されているデバイスの構成に行なわれた変更、ＦＭＳシステム１０によって管理されているデバイスに対応付けられるアラーム、およびその他のイベントを示す時刻表示メッセージを含むイベントログを提供する。レポートアプリケーションは、１つ以上のデバイスの例えば過去、現在、および所望の未来の構成を全て示すレポートを自動的に生成する。トレンド解析または「傾向変動（ｔｒｅｎｄｉｎｇ）」アプリケーションは、特定のデバイス内またはプロセス全体で発生するかもしれないトレンド（傾向）を識別するために、プロセス１２内のデバイスによって測定されたデータを記録する。その他の所望のアプリケーションを作成し、ＦＭＳシステム１０に設けることができることは、明白である。

ＦＭＳシステム１０の動作中、ユーザは、実行するアプリケーションの１つまたはそれ以上を選択する。選択されたアプリケーションは、図２で現在のアプリケーション５６として識別されている。複数のアプリケーションをＦＭＳシステム１０によって同時に実行できるので、複数の現在のアプリケーション５６が存在し得る。現在のアプリケーション５６はどれも、ウィンドウズ（登録商標）オペレーティングシステム４６、インタフェースブロック５８、ディジタル制御インタフェース（ＤＣＩ） ６０、およびＦＭＳデータベースインタフェース６２と直接インタフェースすることができる。望むならば、現在のアプリケーション５６は、オープンデータベースコネクティビティ（ＯＤＢＣ）ブロック６４（ほとんど全てのデータベースとの通信を可能にする、よく知られたマイクロソフトデータベースアプリケーションインタフェース（ＡＰＩ）システム）ともインタフェースすることができる。しかし、多くのアプリケーションにとって、そうした接続は必要でなく、あるいは望ましくない。さらに、現在のアプリケーション５６はどれも、ウィンドウズ（登録商標）オペレーティングシステム４６、プロセス１２内のスマートデバイス、およびデータベース４０とインタフェースブロック５８を介して、間接的にインタフェースすることができる。

インタフェースブロック５８は基本的に、例えば特に構成されたウィンドウズ（登録商標）カスタムコントロール、ＯＸＣコントロール、またはＶＢＸコントロールを有するソフトウェアパッケージであり、これは、現在のアプリケーション５６、プロセス１２内のスマートデバイス、データベース４０、およびウィンドウズ（登録商標）オペレーティングシステム４６とディスプレイ３０とプリンタ３１とキーボード３２とマウス３４とから構成されるユーザインタフェース６５の間における特定の頻繁に使用される情報の通信に関係する機能を、自動的に実行する。インタフェースブロック５８は現在のアプリケーション５６によって使用され、関係するプロトコルの仕様を知っているアプリケーション設計者がいなくても、これらのインタフェース機能を実行することができる。その結果、インタフェースブロック５８により、アプリケーションはいっそう容易に設計することが可能になり、一貫したユーザインタフェースが得られる。

現在のアプリケーション５６およびインタフェースブロック５８は、サーバ６８、７０から構成されるサーバネットワーク６６を介して、ＤＣＩ６０、およびプロセス１２内のスマートデバイス、他のＦＭＳシステムまたはディジタル制御システム、および／またはデータベース４０とインタフェースして通信することが望ましい。一般的に、サーバネットワーク６６はＦＭＳシステム１０内に配置され、それに対応付けられるが、図２のＤＣＩ６０とサーバ６６、７０との間の点線は、ＤＣＩ６０が、例えば図１に示すイーサネット（登録商標）接続を介して、他のＦＭＳシステムのサーバネットワークにもアクセスできることを示す。

基本的に、ＤＣＩ６０は、データベース４０、プロセス１２内のスマートシステム、および／またはその他のＦＭＳシステムと通信し、そこからデータを検索するために必要な機能や、これらに関係するその他の機能を実行するライブラリルーチンで構成されるコンビニエンス層（ｃｏｎｖｅｎｉｅｎｃｅ ｌａｙｅｒ）である。動作中、ＤＣＩ６０は、現在のアプリケーション５６およびインタフェースブロック５８から送信されたコマンドおよびメッセージを、サーバネットワーク６６で認識され使用されるフォーマットに変換し、同様に、サーバネットワーク６６によって提供されたデータを、現在のアプリケーション５６およびインタフェースブロック５８で認識され使用される形式に変換する。

ＤＣＩ ６０は、これらの通信機能を実施するために任意の好ましいプロトコルを使用できるが、好ましくは目的向きプロトコルを使用し、また最も好ましくは、マイクロソフト社により開発および文書化されたＯｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ（ＯＬＥ）プロトコルのようなオブジェクト連結および埋込みプロトコルを使用する。マイクロソフトＯＬＥ（２．０）プロトコルは、マイクロソフトのウインドウズ９５のオペレーティングシステムに使用され、技術上周知のものである。

一般に目的向きプロトコルは、送信メッセージにより対話する独立オブジェクトの収集として世界をモデル化するプログラミング模範である。オブジェクトには、データ（状態）およびそのデータで実施できる方法（アルゴリズム）が含まれる。加えてオブジェクトは、インタフェース接続部を通して互いに関連し、また階層メッセージを通して他のオブジェクトと通信できる。オブジェクトは、メッセージを受信すると、そのオブジェクト内のデータを処理することができるオブジェクト自体の方法を使用することにより、および特定のタスクを実施しかつ適切な結果を多分返送するために他のオブジェクトへメッセージを送信することにより、応答する。

ＤＣＩ ６０はＯＬＥ階層を通してサーバネットワーク６６と通信する。ＤＣＩは、ＯＬＥオブジェクトの読出と書込に関する標準ＯＬＥ手順と呼出しを使用し、ＯＬＥオブジェクト内の一組の列挙された値を列挙し、ＯＬＥオブジェクト内の特性を入手および設定し、ＯＬＥオブジェクトの方法を呼出しかつ実施し、およびＯＬＥアイテム方法（特定の方式のＯＬＥ方法）と連係してＯＬＥ収集オブジェクト内に格納されている特性データを検索する。しかしながら他のＯＬＥ手順は、サーバネットワーク６６と通信するためにＯＬＥオブジェクトでＤＣＩ６０により実施できる。

以下にさらに詳細に説明するように、ＦＭＳシステム１０により好ましくは使用される特定のＯＬＥ階層は、各種の情報の全てを分類するために、かつＤＤのそれぞれに関連する各種のＤＤＬのそれぞれに利用できるかまたはそれぞれにより使用される各種の情報間の相関関係を分類するために開発されたＯＬＥオブジェクト階層であり、ついでそのＤＤは、ＦＭＳシステム１０によりサービスされているプロセス１２内のデバイスと関連する。この決められた階層は一組のＯＬＥオブジェクトを形成し、そのそれぞれは、その階層により定義される一組の特性と、および特性データを処理するために、かつ階層により形成される関係に従って他のＯＬＥオブジェクトと通信するために使用できる特定の組の方法とを格納する。この階層は、図３および４と連係してさらに詳細に検討する。

本質的にＤＣＩ ６０は、決められた階層について識別された全てのＯＬＥオブジェクトがサーバネットワーク６６のメモリ内にあたかも存在するように、サーバネットワーク６６と通信する。ＤＣＩ ６０は、ＯＬＥプロトコル内のＯＬＥオブジェクトとの通信に必要な単一の組の呼出しを実施する。しかしながら現実には、それぞれのＯＬＥオブジェクトのデータと方法は、読出の呼出しまたは書込の呼出しのような呼出しが、例えばＤＣＩ ６０、ＤＤＳ ７２、スマートデバイスコミュニケーションネットワーク７４、またはＦＭＳデータベースインタフェース８０によりそのようなＯＬＥオブジェクト用のサーバネットワーク６６へ送られるまで、サーバネットワーク６６のメモリへは実際には格納または収納されない。その時点においてサーバネットワーク６６は、ＯＬＥオブジェクトに関係するデータと方法を検索し、かつがサーバ６８または７０の１つに関連するメモリに格納しなければならないことを認識し、そのＯＬＥオブジェクトのデータと方法を検索するのに必要な機能を自動的に実施する。

サーバネットワーク６６は、そのメモリに格納されるＯＬＥオブジェクトの１つの内部のデータと方法の読出と書込に関係する呼出しを受信したとき、プロセス１２およびＦＭＳデータベース４０内のＯＬＥオブジェクト、ＤＤＳ ７２、スマートデバイスからデータを読出しかつ、それへデータを書込むように、その格納されたルーチンに従ってＯＬＥオブジェクトデータへ要求された情報を返すか、または要求された機能を実施する。

同様にＤＣＩ ６０は、サーバネットワーク６６に関連するメモリに格納されるＯＬＥオブジェクトの変更を認識または受信し、カレントアプリケーション５６およびインタフェースブロック５６との通信を実施するために、それに基づいた機能を実施する。サーバネットワーク６６は、決められたＯＬＥ階層内のＯＬＥオブジェクトとインタフェースをとり、またデバイスサーバ６８およびデータベースサーバ７０を備える。デバイスサーバ６８は本質的には、決められたＯＬＥ階層内の一組のＯＬＥオブジェクトとの規定された対応を有する一組のソフトウエアルーチンである。これらのルーチンは、ＤＤＳ ７２、スマートデバイスコミュニケーションネットワーク７４、および決められた階層のＯＬＥオブジェクトとの通信のために特に開発される。そのようなルーチンは、プロセス１２内のスマートデバイスから、および／またはプロセス１２内のスマートデバイスに関連するＤＤ（これはファイルである）から入手できるか、またはその内部に格納される特定の種類のデータと情報を例えば送信、検索および変更できる。同様にデータベースサーバ７０は本質的に、決められたＯＬＥ階層内のＯＬＥオブジェクトに関連する一組のソフトウエアルーチンである。これらのルーチンは、ＤＤＳまたはＡＰＩおよび／またはＦＭＳデータベースインタフェース８０と通信して、ＦＭＳデータベース４０から、および／またはスマートデバイス用のデータがＦＭＳデータベース４０に格納されるスマートデバイスに関連するＤＤから入手できるか、またはその内部に格納される特定の種類のデータと情報を例えば送信、検索および変更する。図２に示されるようにＤＤＳ ７２により使用されるＤＤは、ＤＤＳライブラリ７２へ連結されるデバイス記述ライブラリ７６に格納される。

サーバ６６と７０のルーチンは、ＤＤＳ ７２から、スマートデバイスから、またはデータベース４０からＯＬＥオブジェクトのデータを検索するために必要な特定の読出機能を実施するルーチンが、ＤＣＩ ６０からのそのようなデータについての要求により自動的に実施されるように、ＯＬＥオブジェクトのそれぞれに関連する。同様にサーバ６６と７０のルーチンは、スマートデバイスの構成を変更するために、または情報をデータベース４０に格納するために要求される特定の書込機能を実施するルーチンが、ＯＬＥオブジェクト内のそのようなデータを書込む要求により自動的に実施されるように、ＯＬＥオブジェクトのそれぞれに関連する。

例えば、スマートデバイス内、またはそれに関連するデータを表すＯＬＥオブジェクト内の特性値を書込むようにＤＣＩ６０によりなされる要求により、サーバ６８は、新しい特性値をスマートデバイスへ書込むルーチンを実施する。同様に、スマートデバイスに格納される、またはそれと関連する特性値を任意のＯＬＥオブジェクトから読出す要求により、そのＯＬＥオブジェクトに関連する特性値をＤＤＳおよび／またはスマートデバイスから検索するサーバルーチンが自動的に呼び出され、またそのような特性値が、ＯＬＥオブジェクトとして、サーバ６８に関連するメモリ（図示されない）に格納される。同様に、データベース４０に格納されるデータに関連するＯＬＥオブジェクト内の特性値を書込むように例えばＤＣＩ ６０によりなされる要求により、そのＯＬＥオブジェクトが関連するデータベース４０内の位置へ新しい特性値を書込むサーバ７０ルーチンが自動的に実施される。同様に、ＯＬＥオブジェクトから特性値を読出す要求により、サーバ７０は、ＤＤＳから、および／またはこれらの特性値に関連するデータベース４０内の位置からそのＯＬＥオブジェクトに関連するデータを検索し、またそのような特性値を、ＯＬＥオブジェクトとして、サーバ７０のメモリ（図示されない）に格納する。

これらのサーバルーチンは、単純であり、直接的であり、かつ技術に有能な者による書込みが容易であるので、ここでは提供されない。しかしながらＯＬＥおよびＤＤＬに周知の者は、任意の好ましいプログラミング言語を使用して単純な仕方でそのようなルーチンを作成できる。必要に応じて、できるだけ高速で実施して、それによりＦＭＳシステム１０内のカレントアプリケーションの操作速度を増加するように、任意の好ましい方法で、そのルーチンを書込むか、または最適化ができる。

一般に、プロセス１２のオンラインデバイスの１つから特定のデータ、またはその１つに関連する特定のデータを検索するために、サーバ６８はＤＤＳ ７２に特定のデータを尋ねる。そのデータが、スマートデバイス用のＤＤに格納されているならば、ＤＤＳ ７２は、参照されたデバイスについてＤＤＳ７２を調べるか、または参照されたデバイスのブロックに関連するＤＤを調べて、要求されたデータをサーバ６８へ返す。

特定のデータがＤＤから入手できたならば、サーバ６８は、検索されたデータが関連するＯＬＥオブジェクト内にそのデータを格納し維持する。しかしながら要求された特定のデータがデバイス用またはデバイスのブロック用のＤＤから入手できないが、代わりにオンラインデバイス内に格納されているならば、サーバ６８は、コマンドをスマートデバイスコミュニケーションインタフェース７４（これは、例えばカールスルーエに所在するドイツの会社であるＳｏｆｔＩｎｇにより開発されたＦｉｅｌｄｂｕｓデバイスインタフェース、またはコロラド州ボルダーに所在するＭｉｃｒｏｍｏｔｉｏｎのＨＡＲＴデバイスインタフェースを含む既知の任意のスマートデバイスコミュニケーションインタフェースから構成できる）へ送り、オンラインデバイスから特定のデータを検索する。

ついでスマートデバイスコミュニケーションインタフェース７４は、サーバ６８により要求されるデータのために特定のオンラインデバイスへ到達する仕方についての情報の要求をＤＤＳ ７２へ送る。ＤＤＳ ７２は、オンラインデバイス用のＤＤからこの命令情報を検索し、命令情報をスマートデバイスコミュニケーションインタフェース７４へ返し、ついでインタフェース７４が適切な要求をオンラインスマートデバイスへ送る。ついでスマートデバイスは、特定のデータを含むデータストリームに応答する。ついでスマートデバイスコミュニケーションインタフェース７４は、オンラインスマートデバイスから受信したデータストリームを解釈する仕方についての情報の要求をＤＤＳ ７２へ送る。ついでＤＤＳ ７２は、オンラインスマートデバイス用のＤＤからの解釈命令を検索し、その解釈命令をスマートデバイスコミュニケーションインタフェース７４へ返し、ついでインタフェース７４が、サーバ６８により要求された特定のデータを抽出するために、解釈命令に従ってオンラインデバイスからのデータストリームを解釈する。ついでスマートデバイスコミュニケーションインタフェースが、特定のデータをサーバ６８へ返し、サーバ６８は、そのデータが関連するＯＬＥオブジェクトへ検索されたデータを提供する。

サーバー６８がまずＤＤＳ７２に、例えばデータが書込み可能であるかどうか、どのタイプ、どの特定値及びどのデータ範囲が書き込み可能であるか、等の書込み情報の要求を送信する場合を除いて、オンラインデバイスへのデータ書き込みの工程は、同デバイスからのデータ読取りの工程に類似している。データの書き込みが可能であれば、サーバー６８はスマートデバイスコミュニケーションインタフェース７４に書き込み指令を送り、同インタフェース７４は、次いでＤＤＳ７２とインタフェースで接続して当該オンラインデバイスの書込みプロトコルを照会し、情報に応じてオンラインデバイスに書込み指令を送信する。スマートデバイスコミュニケーションインタフェース７４はまた、デバイス内で発生する書込み検証、応答コード、データまたは値の変更等のオンラインデバイスからの他のデータを解釈し、適当なＯＬＥオブジェクトに保存するためにこうしたデータをサーバー６８に送信することができる。

インタフェースによっては、ＤＤＳ７２がサーバー６８に対し、データ要求に返答するにはさらなる情報が必要であると通知する場合がある。例えば、ＤＤＳ７２は、あるパラメータのハンドリングプロパティ（即ち、同パラメータが読取り可能及び／或いは書込み可能かどうか）が特定デバイスのモードパラメータに依存すると判断することができる。ＤＤＳ７２は、サーバー６８に、デバイスのモードパラメータ要求を送信する。サーバー６８は、これに応答して、スマートデバイスコミュニケーションインタフェース７４にデバイスのモードパラメータ要求を送信し、同インタフェース７４は、上述の通りに作動して同デバイスのモードパラメータを検索する。サーバー６８は、スマートデバイスコミュニケーションインタフェース７４から同デバイスのモードパラメータを受信すると、同情報をＤＤＳ７２に送信し、ＤＤＳ７２は次いでデバイスのパラメータのハンドリングプロパティを決定し、こうしたプロパティをサーバー６８に戻し、サーバー６８がこれを受けてその値を適当なＯＬＥパラメータオブジェクトに配置する。

サーバー７０と、ＤＤＳ７２と、ＦＭＳデータベースインタフェース８０との間の通信は、ＦＭＳデータベースインタフェース８０がスマートデバイスではなくＦＭＳデータベース４０との間で情報の読取り及び書込みを行うようにプログラムされていることを除けば、上述のものと類似している。しかしながら一般的には、ＦＭＳデータベースインタフェース８０は、ＤＤＳ７２とサーバー７０との間の通信に関連している点でスマートデバイスコミュニケーションインタフェース７４の機能に似ている。

ＦＭＳデータベースインタフェース８０に、例えばデータベース４０に於けるオフラインデバイスに付随する値のような情報、及びオンライン及びオフラインデバイスに対して行われる変更に関するデータを、ＤＤＬフォーマットで、即ちオンラインデバイスに於けるこうした情報の保存方法に似たフォーマットで保存させることは可能である。このような場合には、ＦＭＳデータベースインタフェース８０はＤＤＳ７２にアクセスしてデータがＦＭＳデータベース４０内にどのように保存されているかを決定する必要があると思われる。例えば場合によっては、データベース４０は、デバイスの状態を模倣する、といった目的で過去のパラメータ等のパラメータ値を保存している。従って、ＦＭＳデータベースインタフェース８０は、同データベースにどんな種類のデータが保存されているか、つまり、整数、計数他、を知るために、ＤＤＳ７２にアクセスしてこの情報を検索しなければならない場合がある。しかしながら、データベース４０に保存される情報は、ＤＤＬフォーマットで保存される必要はない。従って、サーバー７０からのデータベース４０との間のデータの読取り及び書込み指令を実行するに当たって、ＦＭＳデータベースインタフェース８０はＤＤＳ７２にアクセスしてデバイス値を求める必要がない可能性がある。代わりにＦＭＳデータベースインタフェース８０は、データベース４０との間で直接、データの書込み及び読取りを行うことができる。

ＦＭＳデータベースインタフェース８０は、好適には任意のコンベンショナルタイプのアプリケーションプログラムインタフェース（ＡＰＩ）であり、任意の望ましい或いは周知の方法に従ってデータベース４０から情報を検索するように特にセットアップされ、構築されている。従って、ＦＭＳデータベースインタフェース８０は、データベース４０のどこに、どんな方法でデータが保存され、検索されるかを自動的に記録する。

先の指摘の通り、カレントアプリケーション５６、及び必要であればインタフェースブロック５８もまた、ＦＭＳデータベースインタフェース６２及びＯＤＢＣブロック６４を通じてデータベース４０とインタフェースで接続することができる。ＦＭＳデータベースインタフェース６２は、データ及び要求をカレントアプリケーション５６による認識或いは使用が可能なフォーマットからＯＤＢＣブロック６４による認識及び使用が可能な形式に、またこの逆で変換するように開発されたルーチンのライブラリを有する任意の望ましい或いは周知のアプリケーションプログラムインタフェースで構成することができる。ＦＭＳデータベースインタフェース６２（ＡＰＩ）を使用してデータベース４０への書込みを行うことは、ＯＤＢＣブロック６４を直接使用することとは対照的に、データベースの完全性及び一貫性の維持を助長し、またアプリケーションがデータベース管理からシールドされるためにアプリケーションによる書込みが容易になる。典型的には、データベース４０にデータを本明細書に於いて検討したＯＬＥオブジェクト階層通信計画によるアクセスが不可能な、或いは同計画との互換性のないフォーマットで保存する必要のあるアプリケーションでは、ＦＭＳデータベースインタフェース６２及びＯＤＢＣブロック６４（または他の任意のオープンデータベースアクセスシステム）が使用される。

図３及び図４は、１つまたは複数のＤＤＬで定義された、或いは同ＤＤＬから入手可能な全ての情報を表示するように開発された特別のＯＬＥオブジェクト階層と、こうしたＤＤＬのプロトコルに従ったスマートデバイスと、こうしたＤＤＬを使用しているデバイスに関連する情報を保存したデータベースとを示している。図３及び図４の階層はまた、こうしたＯＬＥオブジェクト間の関係性を表示している。この階層をＯＬＥ環境に於いて使用すると、ＤＤＬ、ＤＤＬを使用するスマートデバイス及びＤＤＬを使用するスマートデバイスに関連する情報を保存するデータベースに付随する情報を検索するアプリケーションを実行することができる。このように、図３及び図４の階層は、ＤＤＬ情報（即ち、ＤＤＬのＤＤから入手可能な情報及び／或いはデバイスまたは１つまたは複数のＤＤＬを使用するデバイスに付随するデータベースから入手可能な情報）の配置だけでなく、この情報にアクセスし、これを検索、変更するために図２のＤＣＩ６０及びサーバー６８、７０間のインタフェースを定義する方法を示している。

図３及び図４の階層に於ける各ＯＬＥオブジェクトは、好適にはＯＬＥオートメーションオブジェクトであり、ＯＬＥオブジェクトのタイプを内部に同定した長円形として表示されている。図３及び図４のＯＬＥオブジェクトは各々、１つまたは複数のＤＤＬ内に定義された、或いはＤＤＬによって使用される情報サブセット、及びＤＤ、スマートデバイス及びスマートデバイスに関する情報を保存しているデータベースから入手可能な情報サブセットを含むか、これに接続されている。

一般に、図３及び図４のＯＬＥオートメーションオブジェクトは各々、プロパティ（または属性）、方法及びインタフェースを含んでいる。図３及び図４内のＯＬＥオブジェクトはオートメーションオブジェクトであるため、これにはＩＤｉｓｐａｔｃｈインタフェース（ＯＬＥプロトコルの周知のインタフェース）が接続されている。図３及び図４のＯＬＥオートメーションオブジェクトのＩＤｉｓｐａｔｃｈは、例えばＤＣＩ６０及びサーバーネットワーク６６によって、同ＯＬＥオブジェクトのプロパティ及び方法に関する情報を検索し、他のＯＬＥオブジェクトと通信する際に使用可能である。

ＯＬＥオブジェクトのプロパティは、オブジェクトに関するデータで構成される。各プロパティはまた、例えばプロパティ値の取得、及びＯＬＥオブジェクトのプロパティ値の設定に際して使用可能な機能を有している。例えばＯＬＥオブジェクトのプロパティは、オブジェクトの名称、オブジェクト内またはオブジェクトに付随する項の計数、オブジェクトに付随するラベル及びオブジェクトに付随するヘルプを含んでいる。

ＯＬＥオブジェクトの方法は、ＯＬＥオブジェクト上またはＯＬＥオブジェクト内のデータ上で作動し、ＯＬＥオブジェクト内のデータを使用して特別ルーチンを実行し、他のＯＬＥオブジェクトと通信する。例えば、一つの方法は他のＯＬＥオブジェクト内の値七ットを計数することができる。ＯＬＥオートメーションオブジェクトのプロパティと方法は、共にサーバーネットワーク６６及びＤＣＩ６０によるアクセスが可能な当該ＯＬＥオブジェクトのプログラマブルインターフェースを定義する。

図３及び図４の階層は、図３が示す上部階層と図４が示す下部階層で構成される。図３の上部階層は、ＨＡＲＴ、Ｆｉｅｌｄｂｕｓ及びその他のスマートデバイスまたはコンベンショナルデバイスのようなデバイスと、Ｆｉｅｌｄｂｕｓブロックのような工程内接続されたブロックとの物理的或いは定義された連結度に対応し、且つそれを図示している。図４の下部階層は、ＨＡＲＴ及びＦｉｅｌｄｂｕｓＤＤＬ等のＤＤＬから入手可能な、或いはこれらによって参照されるデータと、ＤＤ、スマートデバイス及び／或いはスマートデバイスまたは他のデバイスに関するデータベースに保存されている、及び／或いはこれから入手可能なデータとの間の関係性を図示している。

図３及び図４の階層の完全な理解を促進するため、本明細書の末尾に表（「ＯＬＥオブジェクトＤＤＬ等価物」と題する）を提供している。「ＯＬＥオブジェクトＤＤＬ等価物」表は、図４の下部階層に示された各ＯＬＥオブジェクトに関して、当該ＯＬＥオブジェクトに対応するＦｉｅｌｄｂｕｓＤＤＬの機能的同等物であるデータ、定義及び／或いは構成を同定している。しかしながら、図３及び図４のＯＬＥオブジェクトも同様に、ＨＡＲＴ ＤＤＬのような他のＤＤＬに於いて入手可能な機能的に同等である種類のデータ、定義及び構成を有すること、従って図３及び図４の階層はあらゆるＤＤＬに適用可能であることを認識すべきである。やはり本明細書の末尾に記載している他の表（「ＯＬＥオブジェクトの定義」と題する）は、図３及び図４が示す各ＯＬＥオブジェクトに付随する幾つかの重要なプロパティ及び方法のリストを提示し、こうしたプロパティ及び方法について簡単に説明している。

先にも述べたように、図３及び図４のＯＬＥオブジェクトのプロパティは、ＤＤＬ（例えば、ＨＡＲＴ及びＦｉｅｌｄｂｕｓＤＤＬ等）から入手可能か或いはＤＤＬによって定義される同タイプのデータを表し、またこれに対応している。これは、上述のように図３及び図４のＯＬＥオブジェクトがこうしたＤＤＬから入手可能であるか、或いはこうしたＤＤＬによって定義されるデータをマップし、表示するように開発されているためである。従って、例えば、図３のブロックオブジェクトは、ＦｉｅｌｄｂｕｓＤＤＬによって認識され使用されるブロックエンティティを表し、またこれに対応しており、図３のデバイスオブジェクト及び図４のパラメータオブジェクトは、ＨＡＲＴ及びＦｉｅｌｄｂｕｓＤＤＬの両方によって認識され使用されるデバイス及びパラメータエンティティを各々表し、またこれに対応している。「ＯＬＥオブジェクトの定義」表に於いて同定された方法は標準的なＯＬＥ方法である。

図３および図４の階層内の各ＯＬＥオブジェクトは、そのＯＬＥオブジェクトへの階層を通るパスを通過することによってアクセスまたは定義することができる。図３のトップから始まり、図３と図４の階層を通る各パスは、ルートオブジェクトを含んでいる。特に，ルートオブジェクトは、ルートオブジェクトの下のいずれかのＯＬＥオブジェクトが関係しているＶｉｅｗＴｉｍｅを定義している。さらに詳しく言えば、ルートオブジェクトは、「過去」、「現在」、または「未来」であるＶｉｅｗＴｉｍｅと結び付けられており、時には特定の時間を指定しているＶｉｅｗＴｉｍｅと結び付けられている。ＶｉｅｗＴｉｍｅが現在である場合、時間は実際の時間である。ＶｉｅｗＴｉｍｅが過去である場合、時間はいずれかの歴史的時間に設定されるが、１つ以上のパラメータ値に対して変更が加えられた時間に設定されることが望ましい。さらに、この変更は、データベース４，たとえばイベントログに保存される。ＶｉｅｗＴｉｍｅが未来の場合、時間は未来の時間に設定するか、一般的に未来を指していることだけを示すように設定できる。

ルートオブジェクトのアイテムメソッドは、ＯＬＥオブジェクト定義テーブルで識別されるコレクションのセットを含んでおり、このコレクションのセットは図３の階層の次の層を定義している。一般に、ＯＬＥメソッドのアイテムメソッドのコレクションは、ＯＬＥオブジェクトと、図３および図４の階層内のそのＯＬＥオブジェクトの下のＯＬＥオブジェクトの間の相互接続を定義している。ＯＬＥオブジェクトのアイテムメソッドの各コレクションは、そのコレクションを含んでいるＯＬＥオブジェクトの下にあるそのコレクションの引用名によって、図３および図４の階層において示される。コレクション内のメンバーの一般名は、コレクションタイプと結び付いているＯＬＥオブジェクトの下にあり、かつプロパティの１つとしてこの式に関係した情報を持っているＯＬＥオブジェクトの上にある、引用が終りアンダーラインが付されている式によって、図３および図４において識別される。

したがって、たとえば、ルートオブジェクトは、（ＢｌｏｃｋＴａｇコレクションとして識別される）ＢｌｏｃｋＴａｇオブジェクトのコレクションを持ち、それぞれが、ＢｌｏｃｋＴａｇとして図３に一般的に示されている特定の名前を持っている。一般に，ブロックタグは、特定のブロックを識別するために、ＦＭＳシステムをインストール／構成する技術者によってＦＭＳシステム内で特定のブロックに割り当てられるユニークな識別子である。したがって、Ｂｌｏｃｋ Ｔａｇの名前を持っているＢｌｏｃｋＴａｇオブジェクトは、図３に示すように、ブロックオブジェクトをユニークに定義する。明らかに、図３および図４の階層内のＢｌｏｃｋＴａｇオブジェクトの実際のメンバーは、（その名前がＦｉｅｌｄｂｕｓ ＤＤＬプロトコルで使われているので）ＦＭＳシステム１０と接続あるいは結び付いているブロックのメンバーに依存している。

ＰｈｙｓｉｃａｌＴａｇ，ＤｅｖｉｃｅＩＤ，ＤｅｖｉｃｅＴａｇオブジェクトは、それぞれ、ルートオブジェクトのＰｈｙｓｉｃａｌＴａｇ，ＤｅｖｉｃｅＩＤ，ＤｅｖｉｃｅＴａｇコレクションと関連あるいは結び付いており、ＦＭＳシステム１０と接続あるいは結び付いている特定のデバイスをユニークに定義するのに使われる。通常、デバイスＩＤは、デバイスメーカーの名前、デバイスのモデル番号、デバイスのシリアル番号から構成される情報の組を含んでいる。通常，デバイスタグや物理タグは、プラントまたはプロセス１２のようなプロセスにおけるデバイスの位置を参照している。物理タグ及び／又はデバイスタグの値は、プラントにおける特定の物理的位置に結び付けられている英数字コードであるか、物理的位置の記述である。ＨＡＲＴデバイスの場合、物理タグはデバイスタグと同じと見なされ、Ｆｉｅｌｄｂｕｓデバイスの場合は、物理タグはデバイスタグとは別の値を持ちうる。ＤｅｖｉｃｅＴａｇオブジェクト、ＤｅｖｉｃｅＩＤオブジェクトのような引用コレクション名の直ぐ下の、図３および図４にあるＯＬＥオブジェクトも、ＤＤＬＬがコレクションと見なす、あるいは定義する構文に関係付けられているので、コレクションとして参照される。

デバイスタグ、物理タグ、及び／又はデバイスＩＤを持つ代わりに、あるいは持つ他に、デバイスは、ＦＭＳシステムとの物理通信接続によって識別されうる。特に、各デバイスは、各々が式ＴＣＰ／ＩＰノード名によって識別されるネットワークの１メンバーを通してＦＭＳシステムに接続される（これは、ルートオブジェクトのＮｅｔコレクションであるネットワークオブジェクトによって、図３に示されている）。

各ネットワークは、図３においてＮｅｔＮｏｄｅオブジェクトによって識別される一連のノードを含んでいる。また、ネットワークノードは、ｃｏｍｌやｃｏｍ２などの名前を持ちうる、（ポートオブジェクトによって示されている）ポートセットを含んでいる。ポートは、（モデムオブジェクトによって識別される）モデムを通じて、１６のステーションアドレスのいずれかでデバイスに接続され、モデムは異なるステーションアドレスによって識別される。

また、ネットワークノードのポートは、ステーションアドレスを持っている（ＨＩＵオブジェクトによって識別される）１つまたは複数のＨＡＲＴインタフェースユニット（ＨＩＵ）を通してデバイスに接続されることもある。各ＨＩＵは、（インタチェンジオブジェクトによって識別される）１つまたは複数のインターチェンジを含んでおり、このインターチェンジは通常回線番号によって識別される８回線を含んでいる。また、インターチェンジオブジェクトは、（先に述べた引用名に関する一般的規則に反し、ラベルＢｌｏｃｋによって識別される）メソッドを含んでおり、このメソッドはＨＩＵを記述している特定のブロックオブジェクトにインタフェースを返す。

また、ネットワークノードは、１つまたは複数のＤＣＳ、たとえばＲＳ３，Ｐｒｏｖｏｘ，またはその他のＤＣＳを通してデバイスとつなげられる。図３は、各ノードが総称的なＤＣＳオブジェクトを通して接続されていることを示しているが、たとえば、ＲＳ３ ＤＣＳとの実際の接続が行なわれ、ノード番号、カード番号、回線（通常ポート毎に４回線）によって図３において識別される。しかし、これらのＤＣＳシステムの構成はまだ完全に開発されていないので、実際の接続は示されておらず、ＤＣＳオブジェクトについては、ＯＬＥオブジェクト定義テーブルで言及されていない。

さらに、ネットワークノードは、１つまたは複数のＦｉｅｌｄｂｕｓインタフェースカードとつなげられることもある。しかし、Ｆｉｅｌｄｂｕｓデバイスはまだ販売されていないので、デバイスとの正確な接続はまだ分かっていない。したがって、この接続は図３の階層には示されていない。しかし、そのようなＦｉｅｌｄｂｕｓ接続は、Ｆｉｅｌｄｂｕｓオブジェクトを示すことによって、また、ネットワークノード間のＦｉｅｌｄｂｕｓ接続とＮｅｔＮｏｄｅオブジェクトとデバイスオブジェクトの間のデバイスに必要なコンポーネントに関係したその他のＯＬＥオブジェクトを示すことによって、簡単に追加することができる。

あるデバイスが先に述べたいずれかの方法で識別されると、そのデバイス内のブロックは、ＨＡＲＴ Ｔａｇ名を持つ、タグオブジェクトとして示されているＴａｇコレクションによってユニークに決めることができる。デバイスがＨＡＲＴデバイスである場合、そしてその内容がただ１つの概念ブロックによって示される場合、そのブロックは既にユニークに識別されており、ＨＡＲＴコレクションによって簡単に指定できる。タグオブジェクトに関係したタグの名前は、図３においてＨＡＲＴ Ｔａｇとして指定されている。なぜなら、ＨＡＲＴデバイスのＨＡＲＴタグはこの識別子として使われているからである。しかし、他のタイプのデバイスに別のタグを代わりに使うことができる。

既に述べたように、ブロックオブジェクトとプロセスのブロックは、図３の上の階層を通る定義済みのパスを通過することによってユニークに識別できる。同様に、図３と図４の階層内のすべてのその他のＯＬＥオブジェクトは、特定のＯＬＥオブジェクトを通り、図３の階層のトップのルートオブジェクトからのパスを通過することによって得られるユニークな名前によって識別できる。したがって、図３と図４の階層内のいずれかのＯＬＥオブジェクトのプロパティとメソッドは、そのＯＬＥオブジェクト用に開発された名前を使って、参照可能であり、取得可能である。

具体的に言えば、名前は、図３のルートオブジェクトから当該ＯＬＥオブジェクトへのパスを通る時に存在する引用および非引用／アンダーライン式からなるストリングをコンパイルし、その式を感嘆符（！）によって分けることによって図３と図４の階層から決定しうる。たとえば、ブロックオブジェクトの名前は、以下のいずれかでありうる。

Ｒｏｏｔ！ＢｌｏｃｋＴａｇ！Ｂｌｏｃｋ Ｔａｇ！

Ｒｏｏｔ！ＰｈｙｃｉａｌＴａｇ！ＨＡＲＴ Ｔａｇ！Ｔａｇ！ＨＡＲＴ Ｔａｇ

Ｒｏｏｔ！ＤｅｖｉｃｅＩＤ！Ｕｎｉｑｕｅ Ｉｎｄｅｎｔｉｆｉｅｒ！ＨＡＲＴ

Ｒｏｏｔ！Ｎｅｔ！ＴＣＰ／ＩＰ Ｎｏｄｅ Ｎａｍｅ！Ｐｏｒｔ

Ｎａｍｅ！Ｍｏｄｅｍ！Ｓｔａｔｉｏｎ Ａｄｄｒｅｓｓｓ！Ｔａｇ！ＨＡＲＴ Ｔａｇ

明らかに、図３と図４に示されている他のＯＬＥオブジェクトの名前は、このフォーマットを使って開発できる。（ＮａｍｅｄＣｏｎｆｉｇｓオブジェクトによって示されている）図３のルートオブジェクトのＮａｍｅｄＣｏｎｆｉｇコレクションは、ＦＭＳデータベース４０に保存され、デバイスからは利用できないオブジェクトに関係付けられている。各ＮａｍｅｄＣｏｎｆｉｇｓオブジェクトは、特定のＮａｍｅｄＣｏｎｆｉｇオブジェクトを指定するためにＣｏｎｆｉｇＮａｍｅによって識別される。たとえば、ＮａｍｅｄＣｏｎｆｉｇオブジェクトは、プロセス内の特定の機能を実装するのに必要な「レシピ」すなわち特定の構成、プロセス内のブロックの過去の構成、または、ブロックオブジェクトに関係している他のユーザ情報を含みうる。しかし、図２のサーバネットワーク６６にとって、各ＮａｍｅｄＣｏｎｆｉｇオブジェクトは、ＮａｍｅｄＣｏｎｆｉｇオブジェクトのパラメータ値データが、デバイスからではなく、ＦＭＳデータベース４０から検索されるという点を除き、ブロックオブジェクトのように見える。ＮａｍｅｄＣｏｎｆｉｇオブジェクトは、通常ブロックオブジェクトに結び付けられている情報のサブセットを持つことができる。

図４の下位の階層は、システムの各ブロックと結び付いているデータ間の内部関係を示している。したがって、図４に示すように、各ブロックオブジェクト（およびＮａｍｅｄＣｏｎｆｉｇオブジェクト）は、（名前は若干異なるが）それぞれが関連のＯＬＥオブジェクトを持っている、Ｐｒａｍ，Ｕｎｉｔ，Ｄａｔａｂａｓｅ，Ｒｅｆｒｅｓｈ，ＩｔｅｍＡｒｒａｙ，Ｃｏｌｌｅｃｔｉｏｎ，Ｍｅｎｕ，Ｍｅｔｈｏｄ，ＥｄｉｔＤｉｓｐｌａｙ，ＷＡＯという名前のコレクションのセットを含んでいる。また、これらの各ＯＬＥオブジェクトは、図４に定義されているように、関連の他のＯＬＥオブジェクトを持っている。したがって、たとえば、Ｐａｒａｍ Ｎａｍｅによって識別されるパラメータオブジェクトは、ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクト、あるいはＲｅｃｏｒｄＰａｒａｍｅｔｅｒオブジェクト、あるいはＡｒｒａｙＰａｒａｍｅｔｅｒオブジェクトでありうる。ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトである場合、それは、関連のＯＬＥオブジェクトを持っているＩｎｄｅｘｅｄＩｔｅｍＡｒｒａｙ，Ｅｎｕｍ，ＰｒｅＥｄｉｔ，ＰｏｓｔＥｄｉｔのコレクションを含む。ＥｎｕｍｅｒａｔｉｏｎＶａｌｕｅｓオブジェクト（列挙型の変数のＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトのコレクション）は、列挙値オブジェクトによって識別される特定の列挙値を持ち、この列挙値オブジェクトはメソッドオブジェクトのコレクションを含む。たとえば、このメソッドオブジェクトは、ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトの列挙値を取得あるいは変更するメソッドを含む。

ＤａｔａｂａｓｅＰａｒａｍｅｔｅｒｓやＤａｔａｂａｓｅＰａｒａｍｅｔｅｒオブジェクトを除き、図４内のすべてのＯＬＥオブジェクトに保存あるいは結び付けられているプロパティ、データ、メソッドは、ＤＤまたはＤＤＬに合致しているデバイスの使用によって利用できる情報を表わしている。ＤａｔａｂａｓｅＰａｒａｍｅｔｅｒｓオブジェクトやＤａｔａｂａｓｅＰａｒａｍｅｔｅｒｓオブジェクトのデータやメソッドは、データベースに保存される。

図３に示されているように、図４のどのＯＬＥオブジェクトでも、図３のルートオブジェクトから当該ＯＬＥオブジェクトへのパスをたどることによって開発される名前によって、ユニークに識別することができる。したがって、たとえば、プリエディトメソッドブロックの名前は、図３のブロックオブジェクト用の名前の最後に付加することによって作成することができる。そしてまた、図３のブロックオブジェクトは、図４のブロックオブジェクト−！Ｐａｒａｍ！Ｐａｒａｍ Ｎａｍｅ！ＰｒｅＥｄｉｔ！Ｉｎｄｅｘ−によっても表わされる。

図３と図４の階層内の特定のオブジェクトに名前が設定され、サーバネットワーク６６と結び付いているメモリに保存されると、以後、ＤＣＩ ６０とサーバネットワーク６６は、サーバネットワーク６６が作成する短いユニークな「ハンドル」を使って、そのＯＬＥオブジェクトを操作したり、そのＯＬＥオブジェクトにアクセスすることができる。たとえば、ハンドルは、サーバネットワーク６６のメモリに保存されたＯＬＥオブジェクトを識別するユニークな番号でありうる。

基本的に、ユニークな名前またはハンドルの場合、図３と図４の階層によって識別されるいかなるＯＬＥオブジェクトでも、ＤＣＩ ６０またはサーバネットワーク６６によって直接アクセスでき、ＤＤＳ、データベース、スマートデバイス、あるいは必要に応じその他のＯＬＥオブジェクトとの通信を確立するために、そのＯＬＥオブジェクト内のメソッドを起動することができる。したがって、たとえば、特定のデバイスから特定のパラメータ値を検索するためにＤＤＳ ７２にアクセスするサーバ６８内のソフトウェアルーチンは、パラメータ値を読み取るようにＯＬＥ ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトに指示するコマンドを使って、ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトへのコールがＤＣＩ ６０によって開始されるときに、起動することができる。

明らかに、サーバネットワーク６６は、ＤＣＩ ６０とカレントアプリケーション５６に対して透過的に、データベース４０、ＤＤＳ ７２、およびオンラインデバイスと通信する。なぜなら、サーバネットワークは、ＯＬＥオブジェクトまたはＤＤＳが要求する新しい情報を取得するのに必要な実装ルーチンを決めるために、図４の下位階層によって識別されるＯＬＥオブジェクト間の相互関係に自動的にアクセスするからである。

図３および図４のＯＬＥオブジェクトがアクセスされるためには、そのＯＬＥオブジェクトと図３のルートオブジェクトの間の少なくとも１つのパス上にある、そのＯＬＥオブジェクトの上のＯＬＥオブジェクトは、サーバネットワークメモリに保存されなければならないことに注意しなければならない。したがって、たとえば、あるブロックのパラメータのＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトにアクセスするとき、パラメータオブジェクト、そのパラメータに結び付いているブロックオブジェクト、そしてそのブロックもサーバネットワークメモリに保存されなければならない。デバイスオブジェクト、デバイスＩＤオブジェクト、ルートオブジェクトも、サーバネットワークメモリに保存することができる。こうした高位オブジェクトがない場合、サーバネットワーク６６は、ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトのデータを突き止め、検索する方法を決めるのに十分な情報にアクセスすることができない。

通常、ＤＣＩ ６０は、ＯＬＥオブジェクトから値を取得するためにコマンドを送る。たとえば、ＤＣＩ ６０は、ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトに提供されている名前またはハンドルを使って特定のデバイスの特定のブロックに対するＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトのハンドリングプロパティを取得するためにコマンドを送る。識別済みのＯＬＥオブジェクトがまだサーバネットワーク６６のメモリに保存されていない場合、サーバネットワーク６６は、このデータを、たとえばＤＤＳ ７２、スマートデバイス自身、またはデータベース４０のいずれかから検索するために、そのＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトの上の１つまたは複数のＯＬＥオブジェクトの作成済みルーチンやメソッドを使う。その後、サーバネットワーク６６は、このデータをサーバメモリに保存する。必要な場合、サーバネットワークは６６は最初にメモリ内のルートオブジェクト、デバイスＩＤオブジェクト、デバイスオブジェクト、ブロックオブジェクト、そしてパラメータオブジェクトを保存する。

次に、サーバは、（ＤＤＳ ７２はブロックの変数パラメータのハンドリング情報が存在している場所なので）ＤＤＳ ７２にアクセスするために、ＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトのメソッドや関連の作成済みルーチンを使用する。この例のように、変数パラメータのハンドリングプロパティの値がスマートドライブに設定されてるモードパラメータに依存している場合、ＤＤＳは、その変数を含んでいるデバイスまたはブロックに関係しているモードパラメータ情報を必要としていることをサーバ６８に知らせるメッセージをサーバ６８に返す。その時点で、サーバ６８はＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトに関係しているデバイスオブジェクトを突き止め、デバイスとの通信方法を知る。すなわち、システム上でのデバイスの位置やそのデバイスと対話する方法を知る。次に、サーバ６６はデバイスオブジェクトに結び付いているデバイスと通信するために作成済みのルーチンを使って、スマートドライブ通信インタフェース７４に対してデバイスのモードパラメータを検索するように指示する。スマートドライブ通信インタフェース７４がモードパラメータ値をサーバ６８に返すと、サーバ６８は、この情報をＤＤＳ ７２に提供し、その後、ＤＤＳ ７２はサーバ６６にハンドリングプロパティを計算して返す。さらにまた、サーバ６６はこの情報をＶａｒｉａｂｌｅＰａｒａｍｅｔｅｒオブジェクトに転送し、それによってＤＣＩ ６０に転送する（なぜなら、ＯＬＥオブジェクトの変更により、メッセージがホストに、この場合はＤＣＩ ６０に送られるからである）。したがって、ＤＣＩ ６０にとって、パラメータのハンドリングプロパティの読み取り要求は、ＯＬＥオブジェクトに送られ、ハンドリングプロパティを持ったメッセージが返されたように見える。ＤＤＳとの、またＯＬＥオブジェクト間の通信は、カレントアプリケーション５６には透過的にサーバによって自動的に実現される。アプリケーションは、アクセスされたデバイスのタイプ、そのデバイスと結び付いているＤＤまたはＤＤＬの特徴について知る必要がない。したがって、先に定義されているインタフェースを使って、アプリケーションは、通信を実装するのに使わなければならないＤＤＳ、ＤＤＬ、またはＤＤの特徴を考慮することなく、同じまたは異なるＤＤＬプロトコルに従って多数の様々なスマートデバイスと通信することができる。

専門家には明らかなように、ＤＣＩ ６０は、たとえば、次のような比較的単純なルーチンを実行することによって、図３と図４に示されているＯＬＥ階層と通信したり、このＯＬＥ階層から情報を検索したりすることができる。（１） オブジェクト階層を作成し、それをサーバネットワーク６６と結び付ける、（２） オブジェクト階層を通って指定のオブジェクトの下のオブジェクトを探す、（３） あるオブジェクトから別のオブジェクトへの特定のパスを通るＩｔｅｍ、１レベル下のオブジェクトを列挙するためのインタフェースを作成するＮｅｗＥｎｕｍのような標準ＯＬＥメソッドを実装する、（４） ＤＤＬオペレーションに関連したメソッドを含むことができるブロックオブジェクトに関係したメソッドを実装する、（６）ＯＬＥオブジェクトからの非ブロッキング読み書き要求を起動し，制御する、（７） ブロッキング読み書きからの結果を検索する、（８） データベース４０への変更を制御する，（９） たとえば時間の変更、変更を行なった人やコンピュータの身元を始めとする、システムに対するユーザ変更に関係した情報を含むイベントログの作成と保守を制御する。

その結果、ＦＭＳ システム１０のアプリケーションは、ＤＤＳ、データベース、またはスマートドライブとのインタフェースを特別にプログラミングする必要がなくなる。そして、それにより、アプリケーション開発者には、ＤＤＬフォーマットやＤＤ、スマートカード通信に関する詳細な知識が必要なくなる。

先に述べたように、図３と図４の階層を使って、ＦＭＳシステム１０によって実装されるどのアプリケーションも、たとえば、階層の各オブジェクトと結び付いているＩＵｎｋｎｏｗｎやＩＤｉｓｐａｔｈインタフェースを利用するためにＯＬＥ互換プログラミング環境を使って、ＦＭＳデバイスとのインタフェースを取ることができることに注意しなければならない。Ｖｉｓｕａｌ ＢａｓｉｃプログラムやＣ＋＋プログラムが、先の定義済みＯＬＥ階層を使うのに適していると思われる。

さらに、図３と図４の階層は特にＦｉｅ１ｄｂｕｓ ＤＤＬやＦｉｅｌｄｂｕｓ ＤＤＬと非常に似ているＨＡＲＴ ＤＤＬに関係付けられているが、本発明に従い、たとえばＭｏｄｂｕｓスマートデバイスを始めとする他のスマートデバイスと結び付けられる他のＤＤＬ用の階層や類似の階層を作成しうると思われる。さらに、図３や図５の階層は、他のオブジェクト指向プログラミングプロトコルを使って、または非オブジェクト指向プログラミングプロトコルを使っても、実装できる。

図５に示したように、ＦＭＳデータベース４０（図１と図２）は、トランザクションデータベース２００を含んでいる。そして、ＦＭＳシステム１０は、このトランザクションデータベース２００を使って、プロセス１２のデバイス１６，１８，２０，２２に対応する様々なブロックのパラメータに対する変更を表わしている情報を保存する。特に、トランザクションデータベース２００は、ＦＭＳシステム１０が知っている各パラメータの変更に対応したトランザクションレコード２０２を保存するのに適している。各トランザクションレコード２０２は、多数のフィールド２０４−２１３を含んでいる。そして、各フィールド２０４−２１３は、トランザクションレコード２０２に対応している「トランザクション」関係の情報（すなわち、パラメータの値の変更）を保存する。

ここで説明したレコード２０２のフィールド２０４−２１３は、ＢｌｏｃｋＫｅｙ，ＴｉｍｅＫｅｙ，ＰａｒａｍＮａｍｅ，ＰａｒａｍＫｉｎｄ，ＶａｌｕｅＭｏｄｅ，ＰａｒａｍＤａｔａＴｙｐｅ，ＰａｒａｍＳｉｚｅ，ＰｒａｍＤａｔａ，Ａｒｃｈｉｖｅｄ，Ｅｘｐｅｃｔｅｄとして識別される。しかし、ここで説明したトランザクションデータベース２００のトランザクションレコード２０２の特定の内容だけは、例外である。本発明に従い、トランザクションデータベース２００のレコード２０２は、必要ならば、保存されているトランザクションやその他の情報に関連したその他の必要なあるいは希望する情報を含めるのに適している。

特定のフィールド２０４−２１３のそれぞれの意味は、特定の時点（Ｔ）での特定のブロック（Ｂ）の特定のパラメータ（Ｐ）への特定の値（Ｖ）の代入を含む変更やトランザクションの例と共に、詳細に説明される。ＢｌｏｃｋＫｅｙフィールド２０４は、変更が過去、現在、未来のいずれであれ、変更が適用されるブロックの識別番号を含んでいる。ＢｌｏｃｋＫｅｙフィールド２０４に保存される識別番号は、ＦＭＳシステム１０がブロックＢに割り当て、ブロックＢをユニークに識別するのに使うユニークな番号である。特定のブロックのＢｌｏｃｋＫｅｙの値は任意である。しかｓ、ＦＭＳシステム１０は、すべてのブロックに割り当てられているＢｌｏｃｋＫｅｙのインデックス（ＦＭＳデータベース４０の場合）を保守しなければならない。

ＴｉｍｅＫｅｙフィールド２０５は、トランザクションレコード２０２が表している変更が行なわれた特定の時間Ｔを表している番号または番号の集まりを保存している。たとえば、ＴｉｍｅＫｅｙは必要なだけの精度（秒またはミリ秒）で表されている実際のカレンダの日時であるか、特定の基準日時からの（たとえば、１９８０年１月１日１２：００ａｍ）からの経過秒数またはミリ秒数のような、この情報から得られた数字である。便宜のために、変更ためのＴｉｍｅＫｅｙは、変更の日付を含んでいるフィールドと変更の時刻を含んでいるフィールドで表すことができる。また、ここで、タイムフィールドは、実際の時刻または基準の時刻からの経過秒数（またはミリ秒数）として表わすこともできる。

ＰａｒａｍＮａｍｅフィールド２０６は、トランザクションレコード２０２によって保存されている変更が関係している特定のブロックＢの特定のパラメータＰの名前を含んでいる。トランザクションレコード２０２のＰａｒａｍＮａｍｅフィールド２０６に保存されている名前は、先に説明したようにブロックＢのＯＬＥパラメータオブジェクトで使われるパラメータの実際の名前である。便宜のために、この名前はＤＤＬにあるパラメータの名前と一致している。

ＰａｒａｍＫｉｎｄフィールド２０７は、パラメータＰの種類に対応している１文字の英字を含んでいる。特にパラメータＰが「実際の」または「現実の」パラメータ（すなわち、ブロックの動作に影響したり、ブロックの動作を変えたりするパラメータ）である場合、ＰａｒａｍＫｉｎｄフィールド２０７は値Ｐを含んでいる。パラメータがデータベース４０（図１）に保存されているパラメータである場合、ＰａｒａｍＫｉｎｄフィールド２０７は値Ｄを含む。後者のタイプのパラメータは、データベース４０だけに保存され、デバイスには保存されない。パラメータの種類の追加指定も提供できる（たとえば、ユーザ定義パラメータまたはブロックに影響しないブロックに関する情報を含んでいるパラメータ）。

ＶａｌｕｅＭｏｄｅフィールド２０８はパラメーター「Ｐ」の値「Ｖ」がブロックＢに対応するデバイスの「実際の」状態の一部であるか、あるいはその代わりに、そのデバイスの「将来の」状態の一部であるかを示すアルファベット文字を含む。特に、ＶａｌｕｅＭｏｄｅフィールド２０８は、トランザクションレコード２０２が実際の状態の一部を表わす場合（つまり、レコード２０２がブロックＢに対する過去を表わすか、あるいは現在の変化を表わす場合）、値「Ｈ」を含む。他方、ＶａｌｕｅＭｏｄｅフィールド２０８は、トランザクションレコード２０２が将来の状態の一部を表わす場合（つまり、トランザクションレコード２０２が将来の指定されていない時間においてブロックＢに対して為されるべき変化を表わす場合）、値「Ｆ」を含む。

ＰａｒａｍＤａｔａＴｙｐｅフィールド２０９はパラメーターＰに記憶されたデータのタイプまたは値「Ｄ」に対応する数（つまり、１＝ストリング、２＝整数、３＝長い整数、４＝符号の付いていない長い整数、５＝浮動小数点、６＝二倍精度、７＝バイナリー等）を含む。様々な利用できるデータタイプに対応する数は、ＦＭＳシステム１０によって任意に指定することができるが、ＦＭＳシステム１０はこれらの指定のトラックを保持しなければならない。

ＰａｒａｍＤａｔａＳｉｚｅフィールド２１０はパラメーターＰに記憶されたデータＤのサイズに対応する数を含む。ＰａｒａｍＤａｔａＳｉｚｅフィールド２１０に記憶された値は、パラメーターＰの値を表わすデータＤを記憶するために使用されるバイト数である。

トランザクションレコード２０２内のＰａｒａｍＤａｔａフィールド２１１は、トランザクションレコード２０２によって表わされる変化によって、パラメーターＰに指定される実際のデータまたは値Ｄを記憶する。

Ａｒｃｈｉｖｅｄフィールド２１２は連合するトランザクションレコード２０２の内容が既にアーカイブに保管されたか、あるいはバックアップ記憶媒体に保管されたかの表示を記憶する任意のフィールドである。Ａｒｃｈｉｖｅｄフィールドは、これらのアーカイブに保管されているトランザクシヨンレコード２０２を次のアーカイビング手順の間に飛ばすことができるように、既にアーカイブに保管されているこれらのトランザクションレコード２０２を特定することによって、データベース２００のバックアップを完成するために必要な時間を最小にする働きをする。更にＡｒｃｈｉｖｅｄフィールドは、まだアーカイブに保管されていないトランザクションレコード２０２の（例えば、ハウスキーピングまたはユーティリティソフトウエアによる）不注意な、及び／または望ましくない削除に対する保護手段を提供する。トランザクションレコード２０２のＡｒｃｈｉｖｅｄフィールド２１２は、トランザクションレコード２０２が既にアーカイブに保管されている場合、１または「真の」値を含み、またそうでない場合は０または「偽の」値を含む。

Ｅｘｐｅｃｔｅｄフィールド２１３は、トランザクションレコード２０２によって表示される変化またはトランザクションが、その変化を実施したＦＭＳシステム１０によって、「予想される」変化、あるいは「予想されない」変化であると特定されたかどうかの指示を含む。下記において詳細に説明するように、ＦＭＳシステム１０は本発明のトランザクションデータベース２００のトランザクションレコード２０２を使用して、どの特定の時間に対しても、プロセス１２内のどのデバイスのどのブロックの予想される状態をも再現することができる。あるデバイスに対して「予想される」状態とは、ＦＭＳシステム１０のトランザクションデータベース２００に保管されたトランザクション史に基づいて、ＦＭＳシステム１０がそのデバイスの状態であると考える状態である。しかし、ある所定の時間に、ＦＭＳシステム１０は１つのデバイスの実際の状態に等しくない状態をそのデバイスに対して「予想する」かもしれない。例えば、第２のＦＭＳシステム１０、あるいはハンドヘルドコミュニケータ４６が、そのデバイスの状態を変更したが、その変更を実施したことを第１のＦＭＳシステム１０にまだ知らせていないかもしれない。

１つのＦＭＳシステム１０（あるいはハンドヘルドコミュニケータ）が１つのデバイス（例えば、ブロックＢを含むデバイス）に対して変更をする前に、ＦＭＳシステム１０はＦＭＳシステム１０が「予想する」状態にそのデバイスがあるのか、あるいはデバイスが別の「予想されない」状態にあるのかを決定する。もしそのデバイスがＦＭＳシステム１０によって予想される状態にある場合、ＦＭＳシステム１０は変更を行い、（変更が予想されていたことを示す）その変更に対応する１（あるいは他の適当な「真の」値）をトランザクションレコード２０２のＥｘｐｅｃｔｅｄフィールド２１３に保管する。他方、ＦＭＳシステム１０が、デバイスがＦＭＳシステム１０が予想した状態以外の状態にあることを発見した場合、ＦＭＳシステム１０はＦＭＳシステム１０のトランザクションデータベース２００に一致しなかった変更が為されたことを知る。（変更をＦＭＳトランザクションデータベース２００に一致させる手順については、下記において詳述する）。その場合、ＦＭＳシステム１０は、ＦＭＳシステム１０が予想するデバイスの状態から、ＦＭＳシステム１０が見い出したそのデバイスの実際の状態へとデバイスの状態を変更するために、デバイスに対して為されていなければならないであろう変更を表わすトランザクションレコード２０２をトランザクションデータベース２００に記入する。更に、ＦＭＳシステム１０は、その変更に対応して、その変更が予想されていなかったことを示す０（または他の適当な「偽の」値）を、トランザクションレコード２０２用のＥｘｐｅｃｔｅｄフィールド２１３に保管する。図９及び図１０に関連して下記に詳細に説明するように、Ｅｘｐｅｃｔｅｄフィールド２１３は、二次的なＦＭＳシステム及び／またはハンドヘルドコミュニケータ４６からのトランザクションレコード２０２を一次的なＦＭＳシステム１０に一致させる際に、（一次的ＦＭＳ等の）１つのＦＭＳシステム１０によって使用される。

トランザクションレコード２０２のＰａｒａｍＫｉｎｄフィールド２０７、ＶａｌｕｅＭｏｄｅフィールド２０８、ＰａｒａｍＤａｔａＴｙｐｅフィールド２０９、ＰａｒａｍＤａｔａＳｉｚｅフィールド２１０は、全体としてトランザクションレコード２０２及びパラメーターＰに対応するパラメーターオブジェクトのＰａｒａｍＤａｔａフィールド２１１に記憶されるデータの処理を容易にするために、トランザクションレコード２０２に含まれる。上述のように、その変更を行った人物の名前、その変更を行った理由、あるいは標準のプラントのオペレーティング手順、規定の要件、ユーザーの好み等によって必要になるかもしれない他の情報等の他の適当な情報も、トランザクションデータベース２００のトランザクションレコード２０２に保管することができる。あるいはその代わりに、この付加的な情報をトランザクションデータベース２００と同様の、付加的な情報用の付加的なフィールドと共に、トランザクション特定情報（例えば、ＢｌｏｃｋＫｅｙフィールド２０４、Ｔｉｍｅｋｅｙフィールド２０５、ＰａｒａｍＮａｍｅフィールド２０６等）を含む第２のデータテーブルに保管することもできる。その後ＦＭＳシステム１０は、トランザクションデータベース２００内の変更を表示する特定のトランザクションレコード２０２内のトランザクション特定フィールドを使用して、第２のデータテーブルを相互参照することによって、各々の変更に対する付加的な情報にアクセスする。

次に、トランザクションデータベース２００に対してＦＭＳシステム１０によって遂行されるデータベース機能について詳細に説明する。一般に、ＦＭＳシステム１０は、プロセス１２において、例えばデバイス１６、１８、２０、２２等のスマートフィールドデバイスに対してなされる変更の歴史的なレコードを維持するため；様々なフィールドデバイス内のパラメーターの現在値を保管するため；またこれらのデバイスに対してなされる将来の変更レコードを保管するために、トランザクションデータベース２００を使用する。トランザクションデータベース２００に対して、幾つかの特殊な機能をＦＭＳシステム１０によって果たすことができる。

第１の機能は、ＦＭＳシステム１０（本明細書において、時には一次的ＦＭＳシステムと称する）自体がデバイスのパラメーターに対する変更、より詳細には、デバイスの特定のブロックに対する変更を行う時、ＦＭＳシステム１０はその変更に関する上述の情報の全てを提供するデータベース２００にレコード２０２を付け加える。変更が為されるブロックに対してＦＭＳシステム１０によって指定されるＢｌｏｃｋＫｅｙがＢｌｏｃｋｋｅｙフィールド２０４に保管される。変更が為される時間に対応するＴｉｍｅＫｅｙはＴｉｍｅＫｅｙフィールド２０５に保管される。その値が変更されるパラメーターの名前はＰａｒａｍＮａｍｅフィールド２０６に保管される。そのパラメーターの種類はＰａｒａｍＫｉｎｄフィールド２０７に保管される。パラメーターの値のモードはＶａｌｕｅＭｏｄｅフィールド２０８に保管される。パラメーターによって記憶されるデータのタイプはＤａｔａＴｙｐｅフィールド２０９に保管される。パラメーターによって記憶されるデータのサイズはＰａｒａｍＤａｔａＳｉｚｅフィールド２１０に保管される。パラメーターに記憶される新しい値はＰａｒａｍＤａｔａフィールド２１１に保管される。Ａｒｃｈｉｖｅｄフィールド２１２はもちろん０に設定される。なぜなら、トランザクションレコード２０２は新しいので、まだアーカイブに保管され得ないからである。最後に、ＦＭＳシステム１０自体がデバイスに対する変更を行ったので、Ｅｘｐｅｃｔｅｄフィールド２１３は、変更が予想されたものであることを示す１に設定される：ＦＭＳシステム１０が変更自体を認可し実施したので、変更は明確に「予想されている」。

多くのデバイスにおいて、ＦＭＳシステム１０はプロセス１２内の全てのスマートデバイスに永久的に接続されているのではない。なぜなら、このような永久的接続は、デバイスが永久的に接続されるＦＭＳシステム１０によってデバイスの構成をしやすくするという点で利点を提供するが、典型的に設置に費用がかかるからである。いわゆる過渡的な、あるいは一次的な接続をＦＭＳシステム１０とスマートデバイス間に提供することができ、ＦＭＳシステム１０がスマートデバイスに所望の変更を行うことができるように、スマートデバイスはＦＭＳシステム１０に永久的には接続されない。あるいはその代わりに、二次的なＦＭＳシステム４６を一次的ＦＭＳシステム１０にまず接続して、どのような変更を行うかに関する指示を受けるようにすることができ、二次的ＦＭＳシステム４６を次に一次的ＦＭＳシステム１０から切断し、代わりにスマートデバイスに接続して、二次的ＦＭＳシステム４６によって指示される変更を行うようにすることもできる。

変更を行うために、一次的ＦＭＳシステム１０が二次的ＦＭＳシステム４６に指示を送る時、一次的ＦＭＳシステム１０は実施すべき変更に対する指示（つまり、変更すべきパラメーター名、及びそのパラメーターに対する新しい値）と共に、デバイスの「予想される」状態も二次的ＦＭＳシステム４６に送る。

二次的ＦＭＳシステムまたはラップトップコンピューター４６に一次的ＦＭＳシステムによる変更指示がロードされた後、技術者が二次的ＦＭＳシステム４６をフィールドに取り込み、それを変更を行うべきプロセスのスマートフィールドデバイス１６、１８、２０及び／または２２等に接続して、以下の変更作成操作を行う（図７）。

図７はプロセス１２内のスマートデバイス１６、１８、２０及び２２に変更を行う際に、ＦＭＳシステム１０がどのようにしてトランザクションデータベース２００と相互作用するかを示すフローチャートである。もちろん、ＦＭＳシステム１０はそれが電気的に、あるいは他の適当な通信モードを介して、デバイスに結合されている場合にのみ、デバイスを変更することができる。上述のように、ＦＭＳシステム１０はフィールドデバイスまたは過渡的なデバイスに永久的に接続することができる。二次的ＦＭＳシステム４６とＦＭＳシステム１０間の過渡的な接続が図１において点線４７で示されており、別のこのような接続が（付加的に、あるいは二者択一的にハンドヘルドコミュニケータ４６を表わすことができる）二次的ＦＭＳシステム４６とフィールドデバイス２０間に示されている。ＦＭＳシステム１０が永久的にフィールドデバイスと接続される場合、ＦＭＳシステム１０自体がフィールドデバイスに変更を行うことができる。デバイスがＦＭＳシステム１０に永久的に接続されない場合、２つの方法でＦＭＳシステム１０を使用してフィールドデバイスの変更を行うことができる。第１は、フィールドデバイスをＦＭＳシステム１０の場所に輸送し、シリアルインターフェイスまたはＦＭＳシステム１０の他のポートへの過渡的な接続を介してＦＭＳシステム１０とインターフェイスで連結し、ＦＭＳシステム１０自体が変更を行えるようにすることができる。第２は、デバイスをＦＭＳシステム１０に直接インターフェイスで連結することが非実用的であるか、不便である場合、二次的ＦＭＳシステム４６（図１）をＦＭＳシステム１０に過渡的に接続するか、インターフェイスで連結し、ＦＭＳシステム１０が必要な変更を行うよう指示することができる。二次的ＦＭＳシステム４６を次にＦＭＳシステム１０から切断し、フィールドオペレーターが変更を行うべき各々のリモートフィールドデバイスの所に運ぶ。オペレーターは二次的ＦＭＳシステム４６をフィールドデバイスに接続し、ちようどＦＭＳシステム１０が行うのと同様に、二次的ＦＭＳシステム４６が変更を行う。

以後、簡略化のために、ＦＭＳシステム１０及び二次的ＦＭＳシステム４６を各々一次的ＦＭＳシステム及び二次的ＦＭＳシステムと称することがある。これらのラベルは単に任意の名称であり、一次的及び二次的ＦＭＳシステムは構造と機能が同じであってよく、あるいは所望であれば、二次的ＦＭＳシステムが一次的ＦＭＳシステムと比べて機能的に劣っていてもよいことに注意すべきである。

例えば、（一次的であれ二次的であれ）ＦＭＳシステムが、ハートデバイス１６、１８、２０またはフィールドバスデバイス２２（図１）等のスマートフィールドデバイスにおいて、１つ以上のパラメーターに１つ以上の変更を加えるプロセスについて、図７を参照して詳細に説明する。

変更実施プロセスは、変更を実施すべきスマートフィールドデバイスにＦＭＳシステム１０または４６を接続するブロック２２０において始まり、変更を実施すべき特定のブロックの全てのパラメーターのためにデバイスから値を得ることによって、そのデバイスの実際の状態を引き出す。次にブロック２２２がデバイスの実際の状態をそのデバイスの予想される状態と比較するが、この予想される状態は上述のように、ＦＭＳシステム１０をデバイスに接続する前にＦＭＳシステム１０に保管されている。一次的ＦＭＳシステム１０が二次的ＦＭＳシステム４６に対してデバイスに変更を行うように指示する時、一次的ＦＭＳシステム１０は二次的ＦＭＳシステム４６に対してそのデバイスの予想される状態を伝達する。

ブロック２２２がデバイスの実際の状態が予想される状態と等しいと決定した場合、ブロック２２４がＦＭＳシステム１０に次の変更をデバイスに加えさせ、ブロック２２６がその変更レコードをトランザクションデータベース２００（図５）に付け加える。ブロック２２２がデバイスの実際の状態が予想される状態と等しくないと決定した場合、ブロック２２４がデバイスに変更を加える前に、ブロック２２８が「予想されない」変更を計算し、予想されない変更のレコードをトランザクションデータベース２００に付け加え、ＦＭＳシステム１０が変更を実施する前に存在するデバイスの現在の状態をトランザクションデータベース２００が正確に反映するようにする。

厳密に言えば、予想されない変更は、一方で、ＦＭＳシステム１０が予想するデバイスの状態から、他方で、ＦＭＳシステム１０が見い出したデバイスの実際の状態へと、デバイスの状態を変更するために必ず実施していなければならない変更（ＦＭＳシステム１０に対してｕｎｂｅｋｎｏｗｎｓｔ）である。

「予想されない」変更レコードがトランザクションデータベース２００に付け加えられた後、付加的な変更が必要である場合、ブロック２３０はＦＭＳシステム１０のオペレーターがデバイスに付加的な変更を行うことを許し、ＦＭＳシステム１０は付加的な変更を表わすトランザクションレコードをトランザクションデータベース２００に保管する。これらの付加的な変更はトランザクションデータベース２００において「予想される」変更として特定される。

その後、上述のように、次の変更をデバイスに加えるブロック２２４に制御が移る。その変更レコードがブロック２２６によって一旦ＦＭＳシステムのトランザクションデータベース２００に加えられると、ブロック２３２はＦＭＳシステム１０が接続されるデバイスに更なる変更を実施しなければならないかどうかを決定する。そうである場合、制御はブロック２２２に戻り、次の変更のために前述のプロセスを繰り返し、そうでない場合は、図７のプロセスが終了する。

第２ＦＭＳシステムに変更を行うように命令を与えることに加え、第ＩＦＭＳシステム１０は、本質的に情報が漏れない（ｓａｆｅ）ハンドヘルドコミュニケータ４６、例えばフィッシャー−ローズマウント・システムズ・インク製のモデル２７５−ＨＣハートコミュニケータに、変更命令をダウンロードすることができる。このようなハンドヘルドコミュニケータ４６は、フィールドオペレータが、第ＩＦＭＳシステムとは離れたエリア及び／又は本質的に情報が漏れないことが要求される危険の多いエリア（第２（ラップトップ）ＦＭＳシステムはこのような危険の多いエリアでの使用には適さない）に配置されたハートフィールドデバイスに、変更情報を伝達するために用いられる。オペレータは、ハンドヘルドコミュニケータ４６をスマートハートフィールドデバイスに接続して変更を行うことができる。

ハンドヘルドコミュニケータ４６（図１）を用いてスマートフィールドデバイスに変更を行うプロセスを図８をもとに詳細に説明する。

まず、図１に示すようにハンドヘルドコミュニケータ４６がＦＭＳシステム１０に接続され、ブロック２４０（図８）に示すようにＦＭＳシステム１０がハンドヘルドコミュニケータ４６のメモリ内のある特定のコンフィギュレーションを記憶する。もちろん、所望により、複数のコンフィギュレーションを複数のデバイス用のハンドヘルドコミュニケータ４６に記憶させることもできる。さらに、ハンドヘルドコミュニケータ４６は、図１のように第１ＦＭＳシステム１０からコンフィギュレーション情報を受信するのと同様の方法で、第２ＦＭＳシステム４６からコンフィギュレーション情報を受信することができる。

ハンドヘルドコミュニケータ４６に、１又はそれ以上のスマートフィールドデバイス１６、１８、２０、２２のコンフィギュレーション情報がロードされた後、ハンドヘルドコミュニケータ４６がこれらのスマートフィールドデバイスのうちの１つに接続され、ブロック２４２に示すように、そこでコミュニケータ４６が接続されたデバイスの新しいコンフィギュレーション情報をこのデバイスに送り込む。

コンフィギュレーションは、第１ＦＭＳシステム１０及び第２ＦＭＳシステム４６に関連した上述の変更と同じ情報をすべて含む。さらに、コンフィギュレーションは、デバイスのパラメータのいくつか（部分コンフィギュレーション）あるいはすべて（全コンフィギュレーション）の新しい値を含むことができる。コンフィギュレーションと変更との相違点は、単にコンフィギュレーションが変更とは異なり時間的要因を含まないという点である。このような相違点がある理由は、ハンドヘルドコミュニケータ４６にコスト上の制約があり、また非常に使いやすいことが望まれているからで、そのために時間記録機能が省かれている。従って、ハンドヘルドコミュニケータ４６がデバイスに変更を行う図８に示した一連の処理は、ＦＭＳシステム１０がこのような変更を行う図７に示した一連の処理に比べていくぶん簡単である。しかしながら、その結果、ハンドヘルドコミュニケータでは、ＦＭＳシステム１０に比べて、それほど複雑な演算を行うことができない。

図８に点線で示したブロック２４４に示すように、ハンドヘルドコミュニケータ４６は、任意で接続されたデバイスの全状態を読み返し、その状態を第１ＦＭＳシステム１０（又は第２ＦＭＳシステム４６）に戻すことができるため、ＦＭＳシステム１０又は４６は、デバイスの新しい状態をＦＭＳシステムのトランザクションデータベース２００と一致させることができる。典型的には、プラントは、ＦＭＳシステム１０が命令を与えてハンドヘルドコミュニケータ４６に行わせようとする変更がそのまま確実に実行されることが必須である状況において、この一連の処理を標準操作手順の一部として必要とすることがある。重要なことは、ＦＭＳシステム１０がコンフィギュレーションをハンドヘルドコミュニケータ４６に伝達する際に、ＦＭＳシステム１０が、自身のトランザクションデータベース２００にトランザクションを入力して伝達するコンフィギュレーションに対応する変更を反映するということである。トランザクションレコードは予期される変更として認識される。それは、ＦＭＳシステム１０が、ハンドヘルドコミュニケータ４６が実際に変更を行うであろうと仮定しているからである。

上述のように、複数ＦＭＳシステムは相互接続が可能なため、これらのそれぞれのトランザクションデータベース２００のデータをマージし、複数ＦＭＳシステムを利用するプラントにおいて一貫性のある包括的な体系（ｖｉｅｗ）を構築することができる。これにより、例えば、上述のような政府機関からの様々な規制要求やプラント安全団体によって決められたガイドラインや規則に応じてプラントを運営する責任のある監査人等が、プラントの運営に関する過去のこれまでの情報を容易に再検討することができる。

図９は、ある１つのＦＭＳシステム（例えば、第２ＦＭＳシステム４６）のトランザクションデータベース２００が他のＦＭＳシステム（例えば、第１ＦＭＳシステム１０）のトランザクションデータベース２００にマージされる処理を示したフローチャートである。本明細書で先に記載したように、どのＦＭＳシステムも第ＩＦＭＳシステム又は第２ＦＭＳシステムとなり得るが、“第ＩＦＭＳ”であるとする場合は通常定置型のシステムを意味するものとする。また、第２ＦＭＳシステムは通常ラップトップコンピュータ内に設けられ、監査責任者等が必要時にいつでも容易にアクセスできるとは限らない。以下、ＦＭＳＩ及びＦＭＳ２という用語は、それぞれ、第１ＦＭＳシステムのトランザクションデータベース２００、第２ＦＭＳシステムのトランザクションデータベース２００を意味するものとする。

最初に、ブロック２５０で、第２ＦＭＳシステム４６に一致しないトランザクションレコードが存在するか否かが判断される。存在しないか、あるいは第２ＦＭＳシステム４６で一致しなかったトランザクションレコードがすべて一致すれば、図９の処理は終了する。一致しないトランザクションが第２ＦＭＳシステム４６に残っている（すなわち、トランザクションレコードがまだ第１ＦＭＳシステム１０のトランザクションデータベース２００に一致していない）場合、ブロック２５２に進み、ここで次の一致しないトランザクションレコード（本明細書中ではＴＲと記載する）が、第２ＦＭＳシステム４６のメモリから第１ＦＭＳシステム１０のメモリにロードされる。さらに、ブロック２５４で、トランザクションレコードによって示される変更が予期される変更であるかどうかを判断するために、このトランザクションレコードＴＲが検討される。予期される変更である場合、次にブロック２５６で、トランザクションレコードＴＲが、第１ＦＭＳのトランザクションデータベースＦＭＳ１にすでに存在してはいるがＦＭＳＩにおいて“予期されない”変更と認識されている変更と同じ変更を示しているかどうかが判断される。トランザクションレコードＴＲにより示される変更がＦＭＳ１の予期されない変更と一致しない場合、トランザクションレコードＴＲは、次に第１ＦＭＳのトランザクションデータベースＦＭＳ１に日付順に格納され、制御はブロック２５０に戻り、一致しないトランザクションが第２ＦＭＳシステム４６にまだ残っていないかどうかが判断される。ブロック２５６において、トランザクションレコードＴＲにより示される変更がトランザクションデータベースＦＭＳ１の予期されない変更と一致すると判断された場合、次にブロック２６０で予期されない変更がトランザクションレコードＴＲ（これは予期される変更）に書き換えられ、制御はブロック２５０に戻る。

一方、ブロック２５４で、トランザクションレコードＴＲが予期されない変更を示すと判断された場合、制御は次にブロック２６２に進み、第１ＦＭＳのトランザクションデータベースＦＭＳ１が、トランザクションレコードＴＲにより示される変更と同じパラメータと同じ値の割り当て（ａｓｓｉｇｎｍｅｎｔ）を示すトランザクションレコードを含むかどうか、及びどのトランザクションレコードが、トランザクションレコードＴＲのタイムキーをある所定の許容範囲の時間的誤差内に近づけるタイムキー（フィールド２０５、図６）として機能する（ｂｅａｒ）のかが判断される。このようなトランザクションレコードがＦＭＳ１に存在しない場合、次にブロック２６４において、第１ＦＭＳのトランザクションデータベースＦＭＳ１の最後にトランザクションレコードＴＲが追加され、レコード２０２のイクスペクテッドフィールド２１３をトランザクションデータベースＦＭＳ１の変更に対応するように設定することにより、このトランザクションレコードにより示される変更は“予期されない”変更として認識される。その後、制御はブロック２５０に戻り、一致しないトランザクションレコード２０２が第２ＦＭＳシステム４６にさらにまだあるかどうかをチェックする。ブロック２６２で、トランザクションレコードＴＲにより示される変更に類似する変更が、第１ＦＭＳのトランザクションデータベースＦＭＳ１にすでにあるようだと判断された場合、予期されないトランザクションレコードＴＲに対応する実際の変更が既にトランザクションデータベースＦＭＳ１のトランザクションレコード２０２により示されているので、次のブロック２６６でトランザクションレコードＴＲは消去される。そして制御は再びブロック２５０に戻り、一致しないトランザクションレコード２０２が第２ＦＭＳシステム４６にまだあるかどうかをチェックする。

ＦＭＳトランザクションデータベース２００の使用例をいくつか、表をもとに以下に詳細に記載する。第１実施例において、第１ＦＭＳシステム１０（Ｐ＿ＦＭＳ）は、第２ＦＭＳシステム４６（Ｓ＿ＦＭＳ）が特定のスマートフィールドデバイス（実施例１と記載された表参照）に将来的変更ＣＦ（すなわち、時期がまだ決まっていない変更）を行うように命令を与える。この実施例では、第１及び第２ＦＭＳシステムで起こったこと、並びに該命令が実行された際にデバイスで起こったことを説明しており、結果は第２ＦＭＳシステム４６から第１ＦＭＳシステム１０に報告され返される。

実施例１

前述の表の第１の行は、ある任意の時間ｉにおけるフィールド・デバイスの一次及び二次ＰＭＳシステムを記述している。時間ｉにおいて、デバイスの実際の状態はＳ（ｉ）であり、その状態は一次ＦＭＳシステム１０及び二次ＦＭＳシステム４６のトランザクション・データベース２００に正確に反映される。

後の時間ｉ＋１においては、一次ＦＭＳシステム１０が、二次ＦＭＳシステム４６にデバイスに将来に変更を加えるよう指令を出す。従って、この時に、デバイスは、状態Ｓ（ｉ）のままでいる。更に、一次及び二次ＦＭＳトランザクション・データベースＰ＿ＦＭＳ及びＳ＿ＦＭＳは、デバイスの実際の状態がＳ（ｉ）であることを正確に反映し続けるが、二次ＦＭＳシステム４６のトランザクション・データベース２００は、現在、将来の変更ＣＦを示すトランザクション・レコード２０２を保持している。

また、後の時期に、二次ＦＭＳシステム４６は、デバイスに接続され、デバイスに対してＣ（ｉ＋１）と呼ばれる将来の変更を行おうと試みる。二次ＦＭＳシステム４６は、デバイスの以前の実際の状態Ｓ（ｉ）が、デバイスについて二次システム４６が予想する状態Ｓ（ｉ）に一致するということを検知するので、二次ＦＭＳシステム４６は、デバイスに変更を加え、そのトランザクション・データベースＳ ＦＭＳに変更に対応するトランザクション・レコード２０２を記録する。デバイスに変更を加えたので、デバイスは、現在、状態Ｓ（ｉ＋１）にあり、また、その変更についてのトランザクション・レコード（ちなみに、トランザクション・データベース２００の期待された状態と呼ばれる）、二次ＦＭＳシステム４６のトランザクション・データベース２００に反映されたデバイスの期待された状態もまた、Ｓ（ｉ＋１）に更新される。しかしながら、一次ＦＭＳシステム１０が、まだ、二次ＦＭＳ４６が将来の変更ＣＦに成功したことを通知されていないので、一次ＦＭＳシステム１０は、デバイスについて期待した状態としてＳ（ｉ）を維持する。

時間ｉ＋３に、二次ＦＭＳシステム４６が一次ＦＭＳシステム１０に接続し、変更Ｃ（ｉ＋１）に対応するトランザクション・レコードを一次ＦＭＳシステム１０に伝達すると、一次ＦＭＳシステム１０は、図９のプロセスと関連して、そのトランザクション・レコードを上記で説明した一次ＦＭＳトランザクション・データベース２００に一致させる。特に、到来するトランザクション・レコードは、期待された変更と呼ばれ、変更が、まだ、期待された変更として一次ＦＭＳトランザクション・データベース２００に入れられていないので（それが実際に入れられていないと想定して）、一次ＦＭＳシステム１０のトランザクション・データベース２００によって反映されたデバイスの期待された状態が、デバイスの実際の状態、すなわち、Ｓ（ｉ＋１）を正確に反映するように、変更Ｃ（ｉ＋１）に関するトランザクション・レコードが、時間順にブロック２５８（図９）毎に一次ＦＭＳトランザクション・データベース２００に入れられる。

その代わりに、変更Ｃ（ｉ＋１）を示すトランザクション・レコードが一次ＦＭＳトランザクション・データベース２００と一致した場合には、合致する期待しない変更が、一次ＦＭＳトランザクシヨン・データベース２００に存在すると確定され、次に、期待された変更Ｃ（ｉ＋１）に関するトランザクション・レコードが、対応する期待しない変更に関するトランザクション・レコード２０２の変わりに、一次ＦＭＳトランザクション・データベース２００に挿入されていたかもしれない。

「実施例２」とタイトルを付けた次の表を参照して、一次ＦＭＳトランザクション・データベース２００に対する「期待しない」変更を示すトランザクション・レコード２０２の一致を説明する別の実施例をここで詳細に説明する。

実施例２

この実施例では、一次ＦＭＳシステム１０及び２つの二次ＦＭＳシステム４６が、最初の時間ｉにおいて、デバイスの実際の状態Ｓ（ｉ）を正確に反映する。

後の時間ｉ＋１に、一次ＦＭＳシステム１０が、第１の二次ＦＭＳ（ＦＭＳ１）にデバイスに変更Ｃ（ｉ＋１）を加えるよう指令を出す。また、その時に、二次ＦＭＳシステム１０が、第２の二次ＦＭＳ（ＦＭＳ２）に同じデバイスに将来の変更ＣＦを加えるよう指令を出す。従って、時間ｉ＋１において、一次ＦＭＳシステム及び第１と第２の二次ＦＭＳシステムのトランザクション・データベース２００が、デバイスの実際の状態Ｓ（ｉ＋１）を正確に反映する。それに加えて、変更Ｃ（ｉ＋１）の記録が、第１の二次ＦＭＳシステム４６に保存され、将来の変更ＣＦの記録が第２の二次ＦＭＳシステム４６に保存される。

後の時間ｉ＋２において、ＦＭＳ１が、図７に関連して上記で説明した手順に従ったデバイスに変更Ｃ（ｉ＋１）を加える。従って、その時に、ＦＭＳ１は、そのトランザクション・データベース２００に実際の状態Ｓ（ｉ＋１）を正確に反映するが、一次ＦＭＳ ＰＦＭＳ及び第２の二次ＦＭＳ ＰＦＭＳ２は、それぞれのトランザクション・データベース２００にデバイスの以前の状態Ｓ（ｉ）を反映し続ける。また、ＦＭＳ２は、まだ、まだ行われていない将来の変更ＣＦに関するトランザクション・レコードを保持する。

後の時間ｉ＋３において、ＦＭＳ２は、デバイスに将来の変更ＣＦを加えようと試み、デバイスが期待しない状態Ｓ（ｉ＋１）にあるということを検知する（すなわち、ＦＭＳ２のトランザクション・データベース２００が反映しない、状態Ｓ（ｉ）以外の状態である）。従って、ＦＭＳ２は、デバイスの状態を（ＦＭＳ２が期待した）Ｓ（ｉ）からＳ（ｉ＋１）に変更するために行われたにちがいない期待しない変更ＣＵを計算する。次に、ＦＭＳ２は、期待しない変更ＣＵに対応するトランザクション・レコードをそのトランザクション・データベース２００に記録し、次に、デバイスに将来の変更ＣＦを加え、変更ＣＦに対応するトランザクション・レコードを現在のタイムキーと共にＦＭＳ２のトランザクション・データベース２００に記録する。従って、これで、ＦＭＳ２のトランザクション・データベース２００は、デバイスの現在の状態Ｓ（ｉ＋２）を正確に反映し、ＦＭＳ２のトランザクション・データベース２００には、デバイスに対して行われたとＦＭＳ２が認識した期待しない変更ＣＵの記録が含まれる。

更に、後に時間ｉ＋４において、二次ＦＭＳシステムＦＭＳ２が一次ＦＭＳシステム１０に接続され、期待しない変更ＣＵ及び現在行われ、承認された変更Ｃ（ｉ＋２）を一次ＦＭＳシステム１０に報告する。次に、そうした２つの変更に関するトランザクション・レコードは、一次ＦＭＳシステム１０によって、図９の手順に従ってそのトランザクション・データベース２００と一致させられるので、一次ＦＭＳシステム１０のトランザクション・データベース２００は、デバイスの実際の状態Ｓ（ｉ＋２）を正確に反映し、変更ＣＵ及びＣ（ｉ＋２）に対応するトランザクション・レコードが含まれる。一次ＦＭＳＦＭＳ１は、依然として、デバイスについてＳ（ｉ＋１）の状態を期待するということを反映しているが、二次ＦＭＳ ＦＭＳ２は、デバイスの実際の状態Ｓ（ｉ＋２）正確に反映する。

更に、後に時間ｉ＋５において、ＦＭＳ１が一次ＦＭＳシステム１０に接続され、それに対する変更Ｃ（ｉ＋１）を報告する。一次ＦＭＳシステム１０は、変更Ｃ（ｉ＋１）に関するトランザクション・レコードをそのトランザクション・データベース２００に一致させ、Ｃ（ｉ＋１）が、時間ｉ＋４に一次ＦＭＳシステム１０のトランザクション・データベース２００に入力された期待しない変更ＣＵに一致する、ということを発見する。従って、ブロック２６０（図９）に従って、変更Ｃ（ｉ＋１）に関するトランザクション・レコードが、一次ＦＭＳシステム１０のトランザクション・データベース２００の期待しない変更ＣＵに関するトランザクション・レコードと入れ替わる。従って、この時に、すべての未決のトランザクション・レコード２０２が、一次ＦＭＳトランザクション・データベース２００に一致させられており、デバイスの実際の現在の状態Ｓ（ｉ＋２）を、また、非常に重要なことであるが、デバイスの構成歴の完全な会計履歴（すなわち、デバイスの構成歴）を正確に反映する。

ここで、インターフェース・ブロック５８の機能を更に詳細に説明する。上記のように、動作中に、現アプリケーション５６は、インターフェース・ブロック５８を呼び出して、特定の１つ、あるいは、それ以上の制御（（プログラム））を初期化し、制御（（プログラム））は、その後で、ウインドウズ・オペレーティング・システム４６、プロセス内１２のスマート・デバイス、及び／あるいは、プロヤス１２に関連したデバイス、ブロック、又は、パラメータに関するＦＭＳデータベース４０との間のインターフェースに関連したすべての動作を自動的に処理する。また、インターフェース・ブロック５６も、サーバ・ネットワーク６６のメモリに保存されたルート・オブジェクトの時間プロパティを変更して、有利な方法でディスプレーを制御することができる。

インターフェース・ブロック５８の各制御（（プログラム））は、デバイス、パラメータ、あるいは、時間に関わる情報をディスプレー３０上に表示し、更新する；及び、ユーザ、あるいは、アプリケーションの入力に応答して、スマート・デバイス、データベース４０、及びサーバ・ネットワーク６６と通信を行って、現アプリケーション５６を更に関わらせる事なく、ＤＤＳ７２、スマート・デバイス、データベース４０、あるいは、サーバ・ネットワーク６６のルート・オブジェクト、と間でデータ検索、データ書込みを行う。重要なことであるが、一旦確立されたら、制御（（プログラム））は、一般的に、現アプリケーション５６、及び確立されているであろう他の制御（（プログラム））とは独立して動作するように見える。

図１１に示したように、インターフェース・ブロック５８には、マスタ・コントロール・ルーチン３００が含まれ、それを使用して、プロセス１２と関連したデバイス、ブロック、あるいは、パラメータに関する制御機能を含めた制御機能を実行することができる。また、インターフェース・ブロック５８には、マスタ・タイムライン・コントロール・ルーチン３０１が含まれ、それを使用して、ルート・オブジェクトからの時間の読み取り、書込み、及びデータベース４０からの時間値の変更といった制御機能を実行することができる。

現アプリケーション５６がインターフェース・ブロック５８を呼び出して、デバイス、ブロック、パラメータ、あるいは、タイムライン制御を行う場合、実際、マスタ・タイムライン・コントロール・ルーチン３００、あるいは、３０１の一つがコピーされ、特定の制御ルーチン、あるいは、制御（（プログラム））に変換される。そうした特定の制御（（プログラム））は、デバイス制御（（プログラム））３０２、ブロック制御（（プログラム））３０４、パラメータ制御（（プログラム））３０６、及びタイムライン制御（（プログラム））３０８として図１１に示してある。その後、特定の制御（（プログラム））３０２、３０４、３０６、３０８は、ウインドウズ・オペレーティング・システム４６、現アプリケーション５６、データベース４０（ＤＣＩ６０を介して）、ＤＤＳ７２（ＤＣＩ６０を介して）、及びオンライン・スマート・デバイス（ＤＣＩ６０を介して）との間の通信に関連した機能を自動的に処理するが、それは、そうした通信が、そのために制御（（プログラム））が生成される特定のデバイス、ブロック、パラメータ、あるいは、タイムラインに関連しているからである。一旦確立されたら、各々の制御（（プログラム））３０２、３０４、３０６、３０８は、他の制御（（プログラム））及び現アプリケーション５６とは独立して、連続的に動作する。同じ、及び／あるいは、異なるタイプの制御（（プログラム））を幾つでも同時に実行させることができる。

図１１には、マスタ・コントロール・ルーチン３００、あるいは、３０１の一つのコピーである別個のルーチンとして制御（（プログラム））３０２、３０４、３０６、３０８を示してあるが、制御（（プログラム））３０２、３０４、３０６、３０８には、マスタ・タイムライン・コントロール・ルーチン３００、あるいは、３０１の一つを使用する特定のデバイス、ブロック、パラメータ、あるいは、タイムライン制御（（プログラム））を実行するために必要なデータを含めることができる。

図１２には、一般的に、例えば、図１１に示した制御（（プログラム））のいずれかを含めて、制御（（プログラム））を初期化するために現アプリケーション５６が実行すべきステップを示してある。制御（（プログラム））が関連付けられた図３及び４の階層内のＯＬＥオブジェクトを指す独自な名前をインターフェース・ブロック５８に与えることによって、ブロック３１０は、制御（（プログラム））のタイプを、例えば、デバイス、ブロック、パラメータ、あるいは、タイムライン制御（（プログラム））を定義する。概念的に、ＦＭＳアプリケーションにとって利用可能な場合に、図３及び４の階層の具体例が存在するので、例えば、制御（（プログラム））が関連付けられたルート・オブジェクトの時間と外観を指定することによって、タイムライン制御（（プログラム））が、特定の階層のルート・オブジェクトを指定する。

ブロック３１１は、例えば表示される文字、情報が表示されるスタイルのフォント、サイズ等、制御情報が表示される表示画面の場所、制御表示のサイズがユーザーにより変更できる場合は制御表示の初期のウインドウ・サイズ、とまたいわゆる制御の「可視性」のようなものから成るユーザー・インターフェースの属性を定義する。制御の「可視性」は、制御が、実際に表示されるかあるいは画面上でみるこができるかどうかを決定する。データを該関連するＯＬＥ（リンキングと埋め込み）オブジェクトから検索するために不可視制御が、まだ稼働しおり、該情報をカレントのアプリケーション５６に提供している間に、該制御のインターフェースの稼働は、単に非作動化される。

ブロック３１２は、制御のリフレッシュ（再生）速度（即ち制御が、該関連するＯＬＥオブジェクトから情報を周期的な読み込みで受け取る速度）を定義する。実際は、ブロック３１２は、制御を図３と４の中の階層の特定のルート（最上位）オブジェクトに接続してから、ルート・オブジェクトは、周期的読み込みに応答してＯＬＥオブジェクトがデータを再生する速度を定義する。

図１３は、デバイス制御、ブロック制御、パラメータ制御、とまた図１１のタイムライン（スケジュール）制御に使用することができる制御ルーチンの一般動作を示している。ブロック３１３は、図３と４の階層とカレントのアプリケーション５６により設けられた名前により定義されている正しいＯＬＥオブジェクトへ接続するか接続を再設定する。具体的には、制御は、例えば制御に関連するＯＬＥオブジェクトの特性のような情報を読み込むために、ＤＣＩ（表示制御インターフェース）６０を経由してサーバ・ネットワーク６６にコマンドを送信する。該コマンドは、周期的に要求されているデータを制御に送信するために、デバイス、ブロックあるいはパラメータ・オブジェクトのようなＯＬＥオブジェクトに告げる周期的な読み込みであることが好ましい。

読み込みに応答して、サーバ・ネットワーク６６は、ＯＬＥオブジェクトからのデータをＤＤＳ（デジタル・データ保存）７２、スマー・デバイスあるいはデータベース４０あるいいはその双方から検索することでＯＬＥオブジェクトへの接続を設定してから、該データをＯＬＥオブジェクトとしてサーバ・ネットワーク・メモリーの中に保存する。しかし、この読み込み機能を実行するために、サーバ・ネットワーク６６は、また該ネットの中にデバイスあるいはブロック・オブジェクトあるいはその双方に関するデータを、図３と４の階層により定義されているとおりに要求されたＯＬＥオブジェクトの上に保存しなければならない。サーバ・メモリーの中に保存されたとき、要求されたＯＬＥオブジェクト・データが、ＤＣＩ ６０に送信されてから、該データが、インターフェース・ブロック５８に関連するメモリーあるいは制御キャッシュに保存されるインターフェース・ブロック５８に送信される。

ブロック３１４は、それから図１２のブロック３１１により制御に設けられているユーザーの属性により定義されている特定の制御に対してユーザーの表示装置３０上の画面を設定するかあるいは初期化する。標準ウインドウス呼び出しとウインドウス・フォーマットを利用して、制御情報を表示させるための表示属性を、如何なる希望する方法でも構成させることができる。各デバイス、パラメータ、とタイムライン制御に対する例としての画面は、図２０−２２に図示されている。

次ぎに、ブロック３１５は、何等かのメッセージがアプリケーション、ウインドウス操作システム４６を経由するユーザーのインターフェース、あるいはＤＣＩ ６０を経由してＯＬＥブロックから受信されたかどうかを調べる。これ等の如何なるメッセージも受信されていない場合は、ブロック３１５は、引続きこのようなメッセージを点検する。ブロック３１５が、メッセージを受信したとき、制御は、１、２と３のラベルが付けられた識別子に示されているとおりに転送される。

図１４は、カレント・アプリケーション５６からのメッセージに応答した制御の作動を示している。ブロック３１６は、読み込みＯＬＥオブジェクト・データ・メソセージ、変更パラメータ・オブジェクト値、あるいはルート・オブジェクト値メッセージと変更ユーザーインターフェース・メッセージを含む三つの一般タイプの一つである可能性があるメッセージを翻訳する。読み込みＯＬＥオブジェクト・データ・メッセージに応答して、ブロック３１８は、要求されたデータを、引用された図３と４のＯＬＥオブジェクトから読み込む。例えば、ブロック制御が、ブロック・オブジェクトの名前特性あるいは「Ｐａｒａｍ」（パラメータ）集を読み込むことができる一方で、デバイス制御は、デバイスＩＤ特性あるいはデバイス・オブジェクトの「タグ」集を読み込むことができる。パラメータ制御は、変数パラメータ・オブジェクトの数値あるいは名前のようなパラメータ特性を読み込むことができる。タイムライン制御は、ルート・オブジェクトの特性を読み込むことができ、またデータベース４０からの過去に存在したルート・オブジェクトに対する時間のリストを入手することができる。その後で、ブロック３１８は、制御をブロック３１５に返す。

変更パラメータあるいはルート値メッセージに応答して、ブロック３２０は、例えば、変数パラメータ・オブジェクト、記録パラメータ・オブジェクト、あるいは図４のアレー・パラメータ・オブジェクトのような、引用されたパラメータ・オブジェクト、に対して変更を実行してから、制御をブロック３１５に返す。変更−ユーザー−インターフェース・メッセージに応答して、ブロック３２２は、ユーザー・インターフェースの変更を実行してから、制御をブロック３１５に返す。

図１５は、読み込みＯＬＥオブジェクト・データ処理の間に、制御により実行されるルーチン３２４を示している。具体的には、ブロック３２６は、ＤＣＯ６０を経由してメッセージを、制御に関連するＯＬＥオブジェクトに送信して、該オブジェクトからのデータを検索する。その後で、ブロック３２８は、どんなタイプの読み込みメッヤージが受信されたかを決定する。非ブロック化、非周期あるいは非ブロック化、周期的メッセージが受信された場合は、ブロック３２８は、制御を、ルーチンが元々呼び出された該ブロックに返す。非ブロックは、制御が読み込みメッセージを制御に関連したＯＬＥオブジェクトに対して送信したものに照会し、他の機能で継続する前に、ＯＬＥオブジェクトの応答を待たない。非周期読み込みは、制御に関連するＯＬＥオブジェクトからの単独の、一回読み込みに対する要求である。周期的読み込みは、ＯＬＥオブジェクトに、該ＯＬＥと関連するルート・オブジェクトの中で定義されている速度で周期的にＯＬＥの中のデータに対して起こった制御の変更を通知することを命令する。

しかし、読み込みが、常に非周期的読み込みであるブロック化であった場合は、ブロック３３０は、ＯＬＥオブジェクトからのデータ返還を待つ。次ぎに、ブロック３３２は、制御キャッシュの中の受信されたＯＬＥオブジェクト・データを保存する。必要に応じて、ブロック３３４は、読み込みにより入手された新しいデータを反映させるために下記に説明されるユーザー・インターフェース変更ルーチンによりユーザーのインターフェースを変更する。ブロック３３６は、カーレント・アプリケーション５６に、例えば、制御の初期化の間に、ＯＬＥオブジェクト・データ読み込みからメッセージあるいはデータ変更を受信することを希望しているアプリケーションが識別されたかどうかを通知する。その後で、制御は、ルーチン３２４を呼んだ何れかのブロックに返される。

図１６は、ＯＥＬＯＬＥオブジェクト（変数パラメータ・オブジェクト）のパラメータあるいはルーツ値あるいはルート・オブジェクトの変更の制御により実行されるルーチン３３８を示している。ブロック３４０は、変更されるべきであると示されているパラメータあるいはルート値が書き込み可能であるかどうかを決定する。要約すれば、ブロック３４０は、ＣＬＥオブジェクトハンドリング特性を読み込んでから、パラメータ値が書き込み可能であるかどうかを決定するためにメッセージを送信する。ブロック３４０が、パラメータあるはルート・データ値が書き込み不能であると決定した場合は、ブロック３４２は、下記に説明されている変更−ユーザー・インターフェース・ルーチンを呼び出すことでユーザーあるいはカレント・アプリケーション３４２に、パラメータあるいはルート値が書き込み可能でないことを通知する。その後で、制御はルーチン３３８が、元々呼び出されたブロックに返される。

それとは反対に、ブロック３４０が、パラメータあるいはルート値が書き込み可能であると決定した場合は、ブロック３４４は、新しいパラメータ値（あるいはルート値）が受け入れられた数値であるかどうかを決定する。この機能を実施するには、ブロック３４４が、例えば、最低値、最大値と、例えば、変数、計数セット等である、受け入れられた数値のタイプのような制御と関連するパラメータ・オブジェクトの数値特性を読み込む。その後、ブロック３４４が、新しい数値が範囲外あるいは間違ったタイプと決定した場合は、ブロック３４６は、メッセージをアプリケーションに送信するか、あるいは受け入れることができない数値が入力されたことを示すためにユーザーの表示を変更するか、あるいはその双方を行う。その後、制御は、るーりん３８８が、元々呼び出されたブロックに返される。

ブロック３４４が、新しい数値が、パラメータあるいはルート・オブジェクトに対して受け入れられる数値であると決定した場合は、ブロック３４８は、ＤＣＩ ６０を経由してメッセージを正しいＯＬＥパラメータあるいはルート・オブジェクトに送信する。新しい数値が、そこで、言うまでもなく、スマート・デバイスの中あるいはデータベース４０の中で対応する変更を行うＯＬＥオブジェクトの中で変更される。

ブロック３５０は、帰還メッセージを待ち、またブロック３５２は、書き込みが成功したかどうかを決定するために、メッセージを復号する。書き込みが、成功であった場合は、ブロック３５４は、ユーザー・インターフェースを経由してアプリケーションあるいはユーザーあるいはその双方に、変更が行われたことを示す（例えば、スクリーン上のデータの背景の色を変更することで）。

ブロック３５２が、書き込みが不成功であると決定した場合は、ブロック３５６は、ユーザー・インターフェースを経由してアプリケーションあるいはユーザーあるいはその双方に、変更が行われなかったことを示す（例えば、スクリーン上のデータを元の状態に変更することで）。棄却の理由が、決定できるかあるいはユーザーに表示されることができるように、ＯＬＥオブジェクトに関連するレスポンス・コードが、アプリケーションにとって入手可能であることを付け加える。

ブロック３５２が、変更が行われたが、書き込み条件が存在すると決定した場合は、ブロック３５８は、ＯＬＥオブジェクトから特に正しい読み込みを開始することで、ＯＬＥオブジェクトからレスポンス・コードを検索する。ブロック３６０は、そこで希望すれば、アプリケーションあるいはユーザーあるいはその双方に、書き込み条件が存在することを示す。ブロック３６０は、また条件のタイプ（例えば、ＯＬＥオブジェクト特性が、最も近い入手可能な数値に設定されていたこと）を示すことができる。ブロック３５４、３５６と３６０は、制御を、元々ルーチン３３８を呼び出したブロックに返す。

図１７は、ユーザー・インターフェース表示を変更するために制御により実行されたルーチン３６２を示している。ブロック３６４は、新しいカレント・アプリケーション５６により提供された新しい属性と関連するか、あるいはここで新たに存在する条件に対して制御により以前に定義された属性のセットに従って該表示インターフェースの属性を変更する。該以前に定義された属性は、制御キャッシュのような、制御に関連するメモリーに保存される。ブロック３６６は、荒らしいユーザーの表示属性と表示されるはずの制御キャッシュの中のデータを利用してユーザ一表示を再生する。それから、制御は、元々ルーチン３６２が呼び出されたブロックに返る。

図１８は、ユーザー・インターフェースからのメッセ−ジに応答する制御の作動を示している。ブロック３７０は、ユーザーの行動が、意味があるかどうかを決定するために点検する。ブロック３７０は、例えば、ユーザーが、マウスの正しいボタンをクリックした、あるいはポインター（即ち、カーソルあるいは矢印）の位置が、制御が、行動に対して要求さているとおりのユーザーの行動を認識する制御表示の領域の範囲内であるかどうかを決定する。ユーザーの行動が無意味であった場合は、ブロック３７２は、単にユーザーの行動を無視するか、あるいは行動が無視されたことの一定の表示（即ち、ユーザーの表示を、同じ表示インターフェース属性で再生する）を与える。その後で、制御は、ブロック３１５に返される。

これとは反対に、ユーザーの行動が、意味がある場合は、ブロック３７４は、ユーザーのインターフェースからメッセージを翻訳する。ユーザーのインターフェースからのメッセージが、ユーザーがパラメータ値あるいはルート値を変更したいことを示している場合は、ブロック３７６は、変更−パラメータ／ルート値ルーチン３３８を呼び出してから、制御をブロック３１５に返す。希望すれば、ブロック３７６は、例えば、書き込まれるべきデータを囲んでいる背景フィールドの色変更を実施するために、またユーザー・インターフェースを変更できる。

成功した書き込みの表示が受け取られたら、直ちに、ブロック３７６は、また数値が書き込まれたことを示すために背景の色をその元の状態に返す（ルーチン３３８がこれを行っていなかった場合は）。

これとは反対に、ブロック３７４が、ユーザーがユーザーのインターフェースの中で変更を要求していることを決定した場合は、ブロック３７８は、変更−パラメータ／ルート値ルーチン３６２を呼び出してから、制御をブロック３１５に返す。

図１９は、ＤＣＩ ６０からの、即ち図３と４の階層の中のＯＬＥオブジェクトからのメッセージに応答した制御の作動を示している。ブロック３８０は、最初にＤＣＩ ６０からのメッセージが、非ブロック化読み込み帰還か、あるいはメッセージが、ＯＥＬ階層の引用されたＯＬＥオブジェクトの範囲内の一部の他の変更あるいは変更された条件を示しているかどうかを決定する。条件変更メッセージは、例えば、多重のユーザーが特定のブロックをアクセスすることを同時に処理中のデバイスの範囲内で予防するＦＭＳ阻止メッセージから成る。例えば、ブロックが、異なるユーザーにより、携帯通信機あるいはデバイスに取り付けられている他のＦＭＳシステムによりアクセスされている場合、ＯＬＥオブジェクトは、ＤＣＩ ６０を経由して制御に対する該状態を識別する。 その後で、制御は、該ブロックのデータがもはや書き込み不能であることを、例えば、通常書き込み可能な数値を囲んで、スクリーン上のグレーの背景を表示して、ユーザーに示す。

非ブロック化読み込み返還の場合、ブロック３８２は、返還された数値が変更されたかどうかを決定する。該場合、ブロック３８４は該新数値を制御キャッシュの中に保存する。ブロック３８４と、制御キャッシュの中に保存されたデータの中に変更がない場合は、ブロック３８２は、同様に、制御をブロック３８６に提供する。該ブロック３８６は、ブロック３８０が、ＯＬＥオブジェクトからのメッセージが変更と関連しており非ブロック化読み取りと関連していないと決定した場合は、また実行される。

ブロック３８６は、変更されたデータあるいは新しい条件あるいは状態が、スクリーンに表示されるべきかどうかのような、ユーザーのインターフェースに対する変更が必要かどうかを決定する。必要な場合は、ブロック３９０は、変更−ユーザー−インターフェース・ルーチン３６２を呼び出して、変更されたデータあるいは条件をユーザーに表示する。しかし、ブロック３８６が、変更されたデータあるいは条件が表示される必要がないと決定したか、あるいはブロック３９０が、該変更されたデータあるいは条件をユーザーに表示した場合は、ブロック３９２は、アプリケーションが、書き込み済みの命令に従って、該変更されたデータあるいは条件について通知を受けるべきかどうかを決定する。 もしそうである場合は、３９４は、変更されたデータあるいは条件を示しながら、メッセージをカーレント・アプリケーション５６に送信する。その後で、制御はブロック３１５に返される。

一般的に、デバイス、ブロック、パラメータ、あるいはタイムライン制御によりアクセスされた情報は、
（１）制御が通常のマイクロソフト・ウインドウス・エディット制御と同様に働くＥＤＩＴスタイル；
（２）制御が通常のマイクロソフト・ウインドウス・コンボ・ボックス制御と同様に（即ちドロップ・ダウン・リストと同様に）働くＣＯＭＢＯスタイル；
（３）制御が、通常のマイクロソフト・ウインドウス・リスト・ボックス制御と同様に（即ち計数の中の各項目が、リスト・ボックス・エントリーとして示されるように）働くＬＩＳＴスタイル；
（４）制御が、通常のマイクロソフト・ウインドウス・ボックス制御と同様に働くＧＲＯＵＰスタイル；とまた
（５）制御が、持ち上げられているか沈められたパネル、あるいは他の全ての希望するスタイルあるいはフォーマットで表示するＰＡＮＥＬスタイルから成る、希望する方法で、スクリーンに表示させることができる。

図２０は、二つのデバイス制御に関連する制御表示４００と４０２を示している。デバイス制御表示４００と４０２の各々は、カーレント・アプリケーションと関連するメモリーの中に保存されているデバイスの絵あるいはデバイスのデジタル・ビットマップ（通常はデバイスのメーカーあるいはＤＤＳ供給者により供給される）から成る。その代わりに、該ビットマップを、データベース４０の中に保存して、ＯＬＥオブジェクトによりアクセスさせることもできる。

該制御表示４００と４０２には、例えば、デバイスの名前（図２０に示されている）、タグ、略称（ＭＯＮＩＫＥＲ）等、あるいは他のデバイス特有の情報から成る、デバイスに関する他の希望する情報を入れることができる。更に、デバイスに対するメニューも、デバイス制御表示４００と４０２に関連するプルダウン・ウインドウの中に設けることができる。該メニューには、例えばデバイスに対するデバイス・オブジェクトに関連する名前集、目盛り調整、再設定、とまた自己診断方法を含むデバイス上で実行できる方法、デバイスに関連するブロック、デバイスに関連するパラメータのリスト、デバイスに対する支援、デバイスのためのサービス・ノート等のようなデバイスに関連するファイルを含めることができる。表示できるデバイスに関する他の情報は、デバイスの中の各パラメータの各々の変数の内容、デバイスのフェース・プレート情報、例えば、デバイスの中でエラーが起こっていいるかどうか、とまた例えば、特定の時間に存在しているかあるいは存在したデバイスの一つあるいはそれ以上のパラメータの変数の数値の対称リストを含むデバイスの作動状態から成る。

図２１は、デバイスの三個の特定のパラメータ制御と関連する特定のパラメータ制御表示４０８、４１０と４１２に沿って一般的なパラメータ制御表示４０６を示している。パラメータ制御表示４０６−４１２の各々の場所は、スクリーンの異なるところにあり、特に、パラメータ制御表示４０６の場所は、スクリーンのトップにある一方で、パラメータ制御表示４０８、４１０と４１２は、パラメータ制御表示４０６の下に連続して置かれている。

該パラメータ制御表示４０６は、パラメータ制御表示が、例えば「圧力」、 「温度」、あるいは「モード」が示される、情報のタイプに関する情報を提供するラベル・フィールド、パラメータの数値を示す数値フィールド、とまた数値が示される単位を示す単位フィールドから成る三個のフィールドを持っていることを示す。パラメータの数値を、整数、小数点数字（パラメタ制御表示４０８と４１０）あるいは、パラメータ制御表示４１２に関連するプルダウン・メニューの中でリストアップされているとおりの計数された数値のセットの一つで構成されている計数された数値とすることができる。該パラメータ制御表示４１２は、単位変数が、該表示に関連する計数されたセットに適用できないので、該変数を含まない。

図２２は、ブロック制御に関連する二個の制御表示４１４と４１６をを示している。デバイス制御表示と同様に、ブロック制御表示は、一般的に、例えば、ブロックが入力、出力あるいは制御（あるいはインターフェース）ブロックの何れかであることを含む、ブロックあるいはブロックが置かれているデバイスあるいはその双方に関連する絵あるいは他のブロックあるいは他の希望する情報あるいはその双方の他の符号から成る。

図２３は、デバイス、ブロックとパラメータ制御のような他の制御に接続され、またパラメータ制御を接続することができる、ＯＬＥルート・オブジェクトの時間とビュー（仮想テーブル）特性を制御し変更するために使用されるタイムライン制御表示４２０と４２２を示している。表示４２０と４２２に関連するタイムライン制御の各々は、関連するルート・オブジェクトの時間値を、ルート・オブジェクトが入手でき、システムに対して時間の変更が行われ、トランザクション記録が、ＦＭＳデータベース４０（図１）のトランザクション・データベース２００（図５）に保存されたとき、一般的に過去の時間を含む如何なる以前の時間に変更できる。更に、制御表示４２０と４２２に関連するタイムライン制御は、過去、現在、あるいは将来の設定の間で、ルート・オブジェクトのビューを変更することができる。

各タイムライン制御表示は、図２３の中に示されている通り、通常、どれが過去、現在を示しているスライダー４２４から成り、将来のビューは、ユーザーが、各々が例えば日付と時間を有する過去の経過した時間から選択できるように、コンボ・ボックス４２６と同時に選択される。

該タイムライン制御スライダー４２４を変更することで、ユーザーは、タイムライン制御に、該タイムライン制御に関連するルート・オブジェクト・ビューを変更するように告げる。タイムライン制御コンボ・ボックス４２６を変更することで、ユーザーは、タイムライン制御にルート・オブジェクト時間値を、特定の時間に変更することを告げる。

タイムライン制御が、時間あるいはルート・オブジェクトのビューを変更したとき、ルート・オブジェクトに関連するパラメータ、デバイスあるいはブロック制御のような他の何れの制御も、ＯＬＥオブジェクトにより作られた変更メッセージに応答して自動的に更新される。該メッセージは、ルート・オブジェクトと同じ階層の中のＯＬＥオブジェクトが、新しい時間、あるいは、ここでルート・オブジェクトと関連するビューに関連する新しいデータを検索したとき、ＯＬブジェクトにより作られる。

図２３は、またタイムライン制御表示４２０と関連するタイム制御と同じルート・オブジェクトに接続されている温度と圧力パラメータ制御表示４３０と４３２を示している。同様に、温度と圧力パラメータ制御表示４４０と４４２は、タイムライン制御表示４２２と関連するタイム制御と同じルート・オブジェクトに接続されている。タイムライン制御表示４２０と４２２は、異なった時間、即ち、過去の時間（制御表示４２０）と現在（制御表示４２２）に設定されるので、温度パラメータ４３０と４４０の数値は、異なり、また圧力パラメータ４３２と４４２は、異なる。パラメータ制御表示のリストを、デバイスあるいはブロック等に対する一つあるいはそれ以上の完全な形状で表示させるようにスクリーンの上の構成させることができる。デバイスとブロックあるは他のパラメータ制御あるいはその双方を、タイムライン制御として同じルート・オブジェクトに関連させることができ、また異なる時間に於けるデバイス、ブロックあるいはパラメータの構成を、スクリーンの中で対称あるいは他の関係で示している構成表示を示すために使用することができる。タイムライン制御を、デバイス、ブロックあるいはパラメータの設定あるいは数値をスクロールして、表示上で他の制御と関連させて使用することができる。言うまでもなく、全ての過去あるいは現在の情報をユーザーに示すために、例えば現在のオンライン・デバイスに関連する情報、即ち、オンラインデータ、とまた過去と将来のオンライン・デバイス、とまたオフライン・デバイスに関連する情報、即ちオフライン・データを含む、如何なるタイムライン、デバイス、ブロック、パラメータあるいは他の制御あるいはその双方の組合せも、可能である。更に、図２３に関連して示されているとおり、デバイスに対する同じデータ、例えば、同じパラメータ値を、タイムライン制御を利用して異なる時間に対して示すことがで、また希望すれば、設定値間の差を示すためにルーチンを実施することができる。

タイムライン制御は、ルート・オブジェクトの時間特性を、タイムライン制御を使用してユーザーが指定する特定の時間（以下ビュー時間と称す）に変更する。従って、ＯＬＥ階層のなかのルート・オブジェクトの全てのオブジェクトの川下に対する時間属性は、上記に説明されているとおりビュー時間に合うように変更される。更に、これ等のオブジェクトの他の特性の数値は、ビュー時間に対応する数値に更新される。

特にブロック・オブジェクトに対しては、希望する時点（即ちタイムライン制御を使用してビュー時間で指定された）での対応するブロックの状態５）は、上記で説明されているトランザクション・データベース２００（図を使用して得られる。より具体的には、ビュー時間に於けるブロック・オブジェクトのパラメータ値（即ち、ビュー時間に於けるブロック・オブジェクトのパラメータ・オブジェクトの数値特性の数値）は、ビュー時間あるいはそれより前に、最後にこれ等のパラメータ・オブジェクトに対応するパラメータに対して割り当てられた数値を探し出すためにビュー時間で始まる時計の逆回りでトランザクション・データベース２２０を検索することで得られる。この手続きは、詳しく、図２４のフローチャートに参照符号を付けて説明されている。

図２４は、どのようにして特定のブロックの状態を、上記に説明されているデータベース２００から再構築できるかを示すフローチャートである。先ず、ブロック４５０が、「セット」タイプ変数｛Ｓ｝をゼロに初期化する。「セット」タイプ変数｛Ｓ｝は、ビュー時間状態が再構築されなければならないブロックのパラメータのビュー時間に於ける数値を蓄積するのに使用される。ブロック４５２が、ビュー時間と等しい状態のセットと｛Ｓ｝関連する時間を、そこで設定する。その後で、ブロック４５４が、設定変数｛Ｓ｝が、ブロック・オブジェクトの各パラメータに対する数値を含んでいるかどうかを決定する。肯定的である場合は、ブロック４５６は、アッセンブルされた状態｛Ｓ｝を、ビュー時間に於けるブロックの状態として割り当ててから、図構築ルーチンは、終了する。

ブロック４５４が、蓄積された状態（即ち、セット変数｛Ｓ｝の内容）が、ブロックの中の各パラメータに対する数値を含んでいないと決定した場合は、ブロック４５８は、現在値が蓄積された状態｛Ｓ｝の中に含まれていない次のパラメータＰを識別する。ブロック４６０は、そこで、ビュー時間あるいはそれより前に、最後行われた変更ＴＲをを探し出すためにビュー時間で始まる時計の逆回りで時計と逆回りでトランザクション・データベース２００を検索する。ブロック４６２は、そこで、トランザクションＴＲの符号で示されている変更によりパラメータＰセットと共に、パラメータＰを、蓄積された状態｛Ｓ｝に加えてから、制御は、ブロックの中の全てのパラメータの数値が、状態｛Ｓ｝に蓄積されたかどうか更にもう一度点検するために、そこでブロック４５４に返る。

デバイス、ブロック、パラメータ、とまたタイムライン制御が、本明細書の中に図示されまた説明されているが、本発明に従った他の制御も、他の特性あるいは、図３と４の中で示されているＯＬＥオブジェクトの何れかの中のデータを含むＤＤＬを経由して入手できるデータを示すように構築できる。

本発明は、単に例示を目的としており、発明を限定することを目的として特定の例を引用して説明されたが、本発明の精神と範囲を逸脱することなく、変更、追加あるいは削除あるいはその双方を、開示された実施例に行うことが可能であることは当業者にとっては明かである。

OLEオブジェクトDDL等価

OLEオブジェクトの定義

Standard Properties

ArrayParameter Object

Block Object

BlockTag Collection

Collections Collection

CollectionItems Collection

Collections Object

DatabaseParameter Object

DatabaseParameters Collction

DeviceID Collection

Device Object

DeviceTag Collection

EditDisplayItems Collections

EditDisplays Co1lection

EditDisplay Object

Elements Collection

Enumeration Value Object

Enumeration Values Collection

HIU Collection

Interchange Object

ItemArray Object

ItemArrays Collection

ItemArrayItem Object

ItemArrayItems Collection

Members Collection

MenuItems Collection

MenuItem Object

Menu Object

Menus Collection

Methods Collection

Method Object

Modem Collection

NamedConfigs Collection

NamedConfig Object

Net Collection

NetNode Object

Parameters Collection

PhysicalTag Collection

Port Collection

RecordParameter Object

RefreshRelation Object

RefreshRelations Collection

ResponseCode Object

RelationItems Collection

ResponseCodes Collection

Root Object

Tag Collection

UnitRelation Object

UnitRelations Collection

VariableParameter Object

WriteAsOneRelation Object

WriteAsOneRelations Collection

プロセスとディジタル制御システムと管理システムとの間の相互接続を示すブロック図である。 デバイス通信インタフェースおよび本発明に従って動作する制御装置を有する図１の管理制御システムのブロック図である。 本発明によるオブジェクト情報の上部階層である。 本発明によるオブジェクト情報の下部階層である。 本発明によるオブジェクト情報の下部階層である。 本発明によるオブジェクト情報の下部階層である。 内部に含まれるトランザクションデータベースを示す図２のＦＭＳデータベースの線図である。 図５のトランザクションデータベースのレコードの線図である。 本発明によるトランザクションデータベース管理システムおよび方法のプログラミングを示す流れ図である。 本発明によるトランザクションデータベース管理システムおよび方法のプログラミングを示す流れ図である。 本発明によるトランザクションデータベース管理システムおよび方法のプログラミングを示す流れ図である。 本発明によるトランザクションデータベース管理システムおよび方法のプログラミングを示す流れ図である。 図２の制御ブロックを示す。 本発明に従って構築された制御に対応付けられる初期化段階を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による制御の動作を示す流れ図である。 本発明による１組のデバイス制御によって生成できる表示画面である。 本発明による１組のパラメータ制御によって生成できる表示画面である。 本発明による１組のブロック制御によって生成できる表示画面である。 本発明に従って１組の時間線およびパラメータ制御によって生成できる表示画面である。 図５のトランザクションデータベースから予想されるデバイス状態を再構築するためのプログラミングを示す流れ図である。

Claims (12)

1. 装置データを有するフィールドデバイスと通信する様に設計されたフィールドデバイス管理システムにおいて、当該装置データは当該装置データのサブセットを含むデバイス記述と関連づけられているフィールドデバイス管理システムであって、
   前記フィールドデバイスと通信する通信手段と、
   前記デバイス記述内に含まれた前記装置データのサブセットを獲得するために前記デバイス記述を解釈するための解釈手段と、
   前記装置データに関連する情報の範疇の階層を保持するための保持手段であって、当該範疇と関連する当該装置データに関連した通信方法を決定するために当該範疇の各々と関連する手段を包含する保持手段と、
   前記装置データの一部及び前記通信手段に関連するコマンドを始動するための始動手段と、
   前記情報の範疇の所定の階層の前記範疇の一つに関連するように前記コマンドを分類するための分類手段と、
   前記通信手段と前記解釈手段を前記範疇の一つと関連する通信方法に基づいて制御するための前記分類手段に呼応する手段とを備えた、フィールドデバイス管理システム。
2. 請求項１に記載のフィールドデバイス管理システムにおいて、更に前記装置データの第２の部分を保持するためのデータベースと、前記データベースとインターフェースするためのインターフェース手段と、前記範疇の一つと関連する通信方法に基づいて前記インターフェース手段を制御するための前記分類手段に呼応する手段を包含する、フィールドデバイス管理システム。
3. 請求項２に記載のフィールドデバイス管理システムにおいて、前記装置データの第２の部分が前記フィールドデバイスの過去の形状に関するデータを包含する、フィールドデバイス管理システム。
4. 請求項２に記載のフィールドデバイス管理システムにおいて、前記始動手段は、前記フィールドデバイス、前記デバイス記述、前記データベースの一つから装置データを検索するためのコマンドを始動する、フィールドデバイス管理システム。
5. 請求項２に記載のフィールドデバイス管理システムにおいて、前記始動手段は前記フィールドデバイスと前記データベースのうちの一つで装置データを保持するためのコマンドを始動する、フィールドデバイス管理システム。
6. 請求項２に記載のフィールドデバイス管理システムにおいて、前記始動手段は、フィールドデバイスに所定の機能を実行させるためのコマンドを始動させる、フィールドデバイス管理システム。
7. 請求項１に記載のフィールドデバイス管理システムにおいて、前記情報の範疇の所定の階層は、前記フィールドデバイスの物理的な連結性に関する範疇を包含し、前記フィールドデバイスの形状に関する範疇を包含する、フィールドデバイス管理システム。
8. 請求項１に記載のフィールドデバイス管理システムにおいて、前記フィールドデバイスは、入力、出力、フィールドデバイスの管理機能の一つを形成する機能ブロックを包含し、前記情報の範疇の所定の階層は、フィールドデバイスブロックを形成する範疇を包含する、フィールドデバイス管理システム。
9. 請求項１に記載のフィールドデバイス管理システムにおいて、前記情報の範疇の所定の階層は、情報の複数の範疇の間での相互関連を特定するための手段を包含し、特定の相互関連に基づいて情報の複数の範疇の内の二つの範疇間でメッセージを送り、前記通信手段と前記解釈手段を制御するための手段を包含する、フィールドデバイス管理システム。
10. 請求項１に記載のフィールドデバイス管理システムにおいて、前記情報の範疇の階層内で範疇の中の選択された範疇の位置に基づいて選択された範疇に名前を割り当てるための手段を包含する、フィールドデバイス管理システム。
11. 請求項１に記載のフィールドデバイス管理システムにおいて、前記保持手段は、オブジェクト指向プログラミングパラダイムにおける一組のオブジェクトを包含する、フィールドデバイス管理システム。
12. 請求項１に記載のフィールドデバイス管理システムにおいて、前記通信手段は携帯通信装置を介してフィールドデバイスと通信するための手段を更に包含する、フィールドデバイス管理システム。

Images