JP2014116027A5

JP2014116027A5 -

Info

Publication number: JP2014116027A5
Application number: JP2014007287A
Authority: JP
Filing date: 2014-01-17
Publication date: 2015-11-05
Anticipated expiration: 2018-02-06

Description

プロセス制御システム

本発明はプロセス制御システムに関する。さらに特定すると、本発明は、複数の異なる型のデバイスの診断情報を監視し、一様に表示するプロセス制御システムに関する。

今日のプロセス制御システムは、温度、圧力、流量、および類似物を含む１つまたは複数のプロセス変数を選択されている目標値に維持するために、弁およびスイッチのような制御要素を監視、操作する計器、制御装置および通信システムを使用している。プロセス変数は、プロセスで活用されている機械および装置の安全かつ効率的な動作を達成するなどの、所望のプロセス目的を達成するように選択され、制御される。プロセス制御システムには、例えば、化学産業、石油産業、および製造業で使用されているプロセスのような産業プロセスの自動化における広範に渡る用途がある。

プロセスの制御は、多くの場合、プロセスのある特定の態様または全体としての完全なプロセスのどちらかを制御するために、ハードウエアデバイスとの間で命令およびデータを送受することによりプロセスを監視する、マイクロプロセッサをベースにした制御装置、コンピュータ、またはワークステーションを使用して実現されている。これらのマイクロプロセッサ、コンピュータまたはワークステーション内でソフトウエアプログラムにより実現される特定のプロセス制御機能は、ハードウエアに修正は必要としないが、プログラミングを通して個別に設計、修正、または変更することが可能である。例えば、エンジニアは、制御装置にタンク内の液位センサから流体液位を読み取らせ、タンク液位を所定の所望液位と比較させてから、読み取られた液位が、所定の所望液位より低かったのか、高かったのかに基づき供給弁を開閉させるためにプログラムを書き込ませることがある。パラメータは、プロセスの選択されているビューを表示してから、選択されているビューを使用してプログラムを修正することにより容易に変更される。エンジニアは、典型的に
は、エンジニアのプロセスに関する見解を表示、修正することによりパラメータを変更するだろう。

制御プロセスを実行することに加えて、ソフトウエアプログラムは、プロセスのビューも監視、表示し、特定のプロセスのステータスに関するオペレータの表示またはビューという形でフィードバックを提供する。監視ソフトウエアプログラムは、問題が発生すると警報を信号で知らせる。問題発生時にオペレータに対する指示または示唆を表示するプログラムもある。制御プロセスを担当しているオペレータは、自分の視点からプロセスを表示する必要がある。ディスプレイまたはコンソールは、典型的には、プロセス制御機能を実行しているマイクロプロセッサをベースにした制御装置またはコンピュータとオペレータの間、およびプログラマまたはエンジニアとプロセス制御機能を実行しているマイクロプロセッサをベースにした制御装置またはコンピュータの間のインタフェースとして提供される。

プロセス制御環境で機能を実行、監視、制御およびフィードバックするシステムは、典型的には、Basic、FortranまたはＣなどの高級コンピュータプログラミング言語で作成され、コンピュータまたは制御装置で実行されているソフトウエアにより実現される。
これらの高級言語は、プロセス制御プログラミングにとって有効ではあるが、通常は、プロセスエンジニア、保守エンジニア、制御エンジニア、オペレータ、および監督者により使用されたり、理解されていない。このような職員のためには、連続ファンクションブロックおよびはしご型論理などの高級グラフィックディスプレイが開発されてきた。したがって、エンジニア、保守職員、オペレータ、研究所職員等の各人は、自分達が自らの責任に関連した用語でシステムを表示できるようにするプロセス制御システムの要素のグラフィックビューを必要とする。

例えば、プロセス制御プログラムがFortranで作成され、２つの入力を必要とし、入力の平均値を計算し、この２つの入力の平均値に等しい出力値を作り出すことがある。このプログラムは、AVERAGE関数(function)と呼ばれ、制御エンジニア向けのグラフィックディスプレイを通して呼び出され、参照されることがある。典型的なグラフィックディスプレイは、２つの入力、１つの出力、およびそのブロックをAVERAGEと指定しているラベルを有している１つの矩形ブロックから成り立っている可能性がある。この同じ関数のグラフィック表示を作成し、オペレータが平均値を表示するためには、異なるプログラムが使用されてよい。システムがカスタマに納品される前、これらのソフトウエアプログラムは、既定義ユーザ選択可能関数（features）のライブラリの中に格納される。プログラムはファンクションブロック(function block)により特定されている。したがって、ユーザは任意の関数を呼び出し、既定義グラフィック表記を選択し、例えばFortranなどのまったく新しいプログラムを作成するよりはむしろ、プロセス制御ソリューションを定義する上で使用するためのライブラリから複数のファンクションブロックの内の１つを選択することにより、オペレータ、エンジニアなど向けのさまざまなビューを作成する。

それぞれが関連ファンクションブロックにより指定されている標準化した関数のグループは、制御ライブラリの中に記憶されてよい。このようなライブラリを備えているデザイナーは、特定のタスクを実行するために、選択されている多様な関数または要素をファンクションブロックと、コンピュータディスプレイ画面上で相互接続することによりプロセス制御ソリューションを設計することができる。マイクロプロセッサまたはコンピュータは、ファンクションブロックにより定義されている関数または要素を、ライブラリ内に記憶されている既存定義テンプレートと対応させ、プログラム関数または要素のそれぞれをデザイナーにより希望されている相互接続に従って互いに関係付ける。理想的には、デザイナーは、Fortranやその他の高級プログラミング言語で１行のコードも作成しないで、既定義関数のグラフィックビューを使用し、完全なプロセス制御プログラムを設計することができるだろう。

プロセス制御プログラミングのためにグラフィックビューを使用することにまつわる１つの問題点とは、既存のシステムを使用すると、この装置のユーザではなく装置製造業者だけが、対応するグラフィックビューとともに独自の制御関数を作成したり、提供されているライブラリ内で既定義関数を修正することができるという点である。

新規プロセス制御関数は、おもに、企業により供給されている関数の標準セットの一部ではない関数に対する特定のニーズを持っている可能性のあるエンドユーザによってではなく、設計システムを販売する企業によって設計される。標準化した関数は、エンドユーザに対しシステムに備えられている制御ライブラリ内に記憶されている。エンドユーザは、設計環境に付随している既存の関数を活用するか、あるいは自分達のために所望の特定のカスタマイズされている関数を開発するための設計環境を供給する企業に依存しなければならない。デザイナーがエンジニアのビューのパラメータを修正するように依頼される場合、多くの場合関数プログラムおよびビュープログラムは独立して開発されており、１つの統合されている開発環境の一部ではないため、それらのパラメータを使用している他のすべてのビューも相応して作成し直され、修正されなければならない。このような手順が非常に厄介で、高価、かつ時間を要することは明らかである。

既存のプロセス制御システムでの別の問題点とは、典型的には、ネットワーク内で中央制御装置を利用し、専門化されているユーザ定義制御タスク用にカスタマイズされているプログラムコードを実行する、集中制御の使用である。その結果、プロセス制御システムは、典型的にはある特定のサイズに制約され、発生してくるニーズに経時的に適応することが困難である。同様に、従来のプロセス制御システムは、構成という点で柔軟性に欠けており、多くの場合、新しいデバイスが組み込まれるとシステム全体に対する完全なソフトウエア改訂を必要とする。さらに、従来のプロセス制御システムは高価で、通常、制御システム全体の構成とプログラミングに精通している専門家によって新規関数を実行するために改変または再プログラミングされているだけである、当初ユーザまたはシステムデザイナーにより特定される関数上で実行する傾向がある。
既存のプロセス制御システムでの更なる問題点とは、異なるシステムの物理的実装が、制御装置及び広範囲な「知性(intelligence)」を有するフィールドデバイスを含んでいて、非常に多様であることである。例えば、弁、モータ、レギュレータといったフィールデバイスは、演算処理能力または制御能力を有しないかもしれない。他のフィールドデバイスは、高度の制御自立性を有するかもしれない。さらに他のフィールドデバイスは、ある程度の演算処理力であるが所望の制御タスクを完遂するには不十分な量の演算処理力を有するかもしれない。

必要とされているのは、既存のソリューションをカスタマイズし、自分の特定のプロセス制御関数の開発に対するニーズを満たすために、デザイナーや製造業者だけではなく、ユーザも容易に使用することができる統一、つまり汎用の設計環境である。さらに必要とされているのは、新規および異なる制御関数を実行するために、実質的には任意のサイズのプロセス内で容易に実現され、制御システムデザイナーに補助してもらわなくてもユーザによって更新されるパーソナルコンピュータをベースにしたプロセス制御システムである。

多くのプロセス制御システムは、多様な制御機能ルーチンを実現するために、Profibus、Fieldbus、CAN等の特定の制御プロトコルに反応する、弁、モータ、調整器等などのローカルフィールドデバイスを含んでいる。したがって、これらの制御装置は、フィールド内で制御機能性を実現するために一定の標準制御プロトコルに反応する。このような標準制御信号プロトコルを使用することにより、デザイナーはその制御プロトコルに反応するすべてのデバイスから同じ型の制御信号を使用できるため、制御システムを開発する時間および労力を削減することができる。

ただし、一定の制御装置は標準制御プロトコルには反応しない。これらのデバイスは、多くの場合、デジタルＯＮ／ＯＦＦ信号、アナログ電流信号、またはアナログ電圧信号などのそれ以外の型の制御信号に反応する。システムデザイナーは、インストールされているプロトコルに無反応であるフィールドデバイスの使用を回避するか、あるいは１つまたは複数のプロトコルの元で動作するシステムを開発しなければならない。したがって、今日の処理システムが、標準プロトコル制御装置と、標準プロトコルの元で定義されている制御信号に反応しないデバイスの両方を活用する能力に欠けているのが不利である。

必要とされているのは、１つの標準プロトコルを使用して定義されているデバイスと、それ以外の非プロトコルデバイスの両方を、プロセス制御システムのユーザにとってトランスペアレントに制御するプロセス制御システムである。

必要とされているのは、プロセスの物理的な制約まで制御プロセスをカスタマイズし、多様な制御装置とデバイスの制御機能を活用し、希望時にこれらの制御機能を補足し、プロセス制御システム全体で制御機能性を分散させ、プロセス制御機能の開発に対する特定のニーズを満たすために、デザイナーや製造業者だけではなくユーザも容易に使用することができる統一、つまり汎用の設計環境である。さらに必要とされているのは、新規および異なった制御機能を、これらの制御機能を中心レベル、中間レベルおよび周辺レベルすべてを含む制御システム全体に分散させることにより実行するために、実質的には任意のサイズのプロセス内で容易に実現され、制御システムデザイナーに補助してもらわなくてもユーザによって更新されるパーソナルコンピュータをベースにしたプロセス制御システムである。

診断情報とは、あるプロセス制御システム内で監視し、表示するために有用である１つのタイプの情報である。しかしながら、プロセス制御システム内では多岐に渡るフィールドデバイスを含む多様な型のデバイスが使用されており、診断情報は、通常、あるデバイスから次のデバイスで一貫して監視されていない。さらに、診断情報は、典型的には、制御装置とデバイス、または複数のデバイスと制御装置の組み合わされた動作などの、制御システムの複数の部分の相互作用に関係する。１つのシステム中の複数の回路に関係している診断情報は、典型的には、既存のプロセス制御システムにより取り扱われない。

診断情報は、診断情報監視時に発生している多様な制御動作に関係付けられるときにもっとも有用である。従来のプロセス制御システムは、典型的には、診断試験中に機能している制御動作や制御体系とは関係なく診断情報にアクセスし、表示する。

診断ディスプレイ用グラフィックビューの使用にまつわる１つの問題点とは、既存のシステムを使用すると、この装置のユーザではなく装置の製造業者だけが、対応するグラフィックビューとともに監視される診断情報を定義したり、提供されているライブラリ内で既定義診断関数を修正できるという点である。

必要とされているのは、プロセス制御システムの可変数のおよび可変型のデバイスと構成要素向けに診断動作の監視およびディスプレイをカスタマイズするために、デザイナーや製造業者だけではなくユーザも使用することのできる統一、つまり汎用の設計環境である。さらに必要とされているのは、プロセスフィールドデバイスの多様な組み合わせのために診断情報を監視し、表示するために、実質的には任意のサイズのプロセス内で容易に実現され、制御システムデザイナーに補助してもらわなくてもユーザによって更新される柔軟な診断監視表示機能性を含むパーソナルコンピュータをベースにしたプロセス制御システムである。

従来のプロセス制御システムにおいては、典型的には、ローカルフィールドデバイスは、多くの場合、携帯フィールドプログラマを使用して、ローカルフィールドデバイスを個別にプログラミングすることにより、フィールド内で構成される。フィールドデバイスの個別プログラミングは時間を要し、非効率であり、多くの場合、個々のデバイスが独立してプログラミングされているときシステムのグローバルビューを持続させることはさらに困難であるため、デバイス構成と、プロセス制御システム内のその他のデバイスと制御装置の構成の間での非互換性につながる。複数の異なるプログラミングデバイスは、典型的には、それぞれ異なるフィールドデバイスをプログラミングするために使用されなければならないので、個々のプログラミングデバイスの使用は不便である。

さらに、一時的な故障や局所的な停電（power disruptions）を含むローカルデバイスの故障は、それぞれの故障中のデバイスを局所的に構成し直す必要があるため、制御システム全体の動作を中断し、ダウンタイムの延長を引き起こすこともある。

必要とされているのは、個々のフィールドデバイスをローカルな独立したプログラミングを行わないで構成できるようにするプロセス制御システムである。さらに必要とされているのは、適切にグローバルに構成されている周辺要素が、制御機能性を達成するために独立して動作できるようにする一方、互換性のあるグローバルな構成が達成されるようにローカルフィールドデバイスから離れた場所からのグローバルシステムの構成を可能にするプロセス制御システムである。

グローバルシステムの構成は、システムを構成する特定のフィールドデバイスを記述するパラメータに基づく。しかしながら、フィールドデバイスと通信するための制御プロトコルが、システムを構成するのに十分であるパラメータを伝達するには不十分である場合がある。例えば、フィールドバスプロトコルのシステム管理仕様は、初期化された状態、初期化されていない状態、およびシステム管理稼動（SM_OPERATIONAL）状態を含む、デバイスにとっての３つの状態を定義する。この３つの定義された状態は、システム管理の観点からデバイスの動作を記述するには十分であるが、フィールドバスインタフェースまたはデバイスのステータスを分析、制御または表示するためのソフトウエアエンジニアリングツールのどちらかの観点からデバイスを記述するには不適当である。この不十分さは、構成が、初期化されていない状態でフィールドバスリンクに接続されているデバイスを作動させるという動作を含むときにきわめて顕著である。

さらに必要とされているのは、フィールドバスデバイスの状態を区別し、デバイスの自動検知をサポートし、デバイスのアドレス割当てを概略する、プロセス制御システムである。

複数の制御言語が、ユーザがコントロールストラテジー（control strategy（制御戦略））を実現するのを補助するＩＥＣ−１１３１規格の元で開発されてきた。これらの制御言語は、ファンクションブロック、シーケンシャルファンクションチャート、はしご型論理、およびストラクチャードテキストを含む。これらの言語のそれぞれは、制御エンジニア、制御システムデザイナー、技術者、オペレータ、および保守作業員を含む、ある特定の種類のユーザに向けられている。これらのユーザは、大きく異なるレベルと経験領域、訓練、および専門知識を持つ。典型的には、さまざまなユーザは、大きく異なる観点から制御システムを表示し、さまざまに表現されている、非常に異なっている問題に対する１つのソリューションを求める。例えば、制御システムデザイナーの制御構成ビューは、保守作業員には無意味である可能性もあれば、その逆の可能性もある。

必要とされているのは、ある特定の種類のユーザにとって、もっとも理解でき、かつ有益である様式で構成を柔軟に提示するユーザインタフェースである。

警報イベント情報は、プロセス制御システムで監視、表示するには非常に重大である１つの種類の情報である。しかしながら、プロセス制御システムで内では、多岐に渡るフィールドデバイスを含む多様な型のデバイスが使用されており、警報情報は、通常、有効に監視されていない。例えば、特定の警報に関して非常に異なった緊急性が存在することがある。緊急性のないなんらかの日常的な点検が行われなければならないことをただ示しているだけの警報状態もある。即座の注意を必要とする警報状態もある。プロセス制御システム内の一定のデバイスは、きわめて重大な状態を測定することもあるが、それ以外のデバイスははるかに緊急性のない情報を監視する。さらに、制御システムの複数の部分の相互作用、例えば、制御装置とデバイスあるいは複数のデバイスと制御装置の組み合わされた動作の情報に関係がある重要な警報状態もある。１つのシステム中の複数の回路およびデバイスの関係する警報状態は、典型的には、既存のプロセス制御システムによって取り扱われていない。

警報イベント情報は、状態監視時に発生する多様な制御動作に関係付けられるときにもっとも有用である。従来のプロセス制御システムは、典型的には、診断試験中に機能している制御動作や制御体系に関係なく警報情報にアクセスし、表示する。従来のプロセス制御システムは、通常、さまざまな警報状態とイベントの優先順位を設定するための一貫したシステムを有していない。

警報イベントディスプレイのためにグラフィックビューを使用することにまつわる１つの問題点とは、既存のシステムを使用すると、この装置のユーザではなく装置製造業者だけが、関連グラフィックビューとともに、監視されなければならない警報とイベントを定義したり、既定義イベント優先順位を修正できるという点である。異なる種類のユーザが、プロセス制御システムのさまざまな態様を視覚化する必要がある可能性がある。例えば、制御システムのいくつかの動作態様だけを変更する能力のあるユーザもいる。別のユーザにより制御される可能性のあるそれ以外のイベントに対しては、警報情報が緊急に必要とされていないが、これらのユーザは、自分達が制御できる状態情報に対するアクセスを必要とする。

必要とされているのは、警報イベント情報の表示に優先順位を設定するために、デザイナーや製造業者だけではなく、ユーザも容易に使用することのできる統一、つまり汎用の設計環境である。

本発明の開示に従って、プロセス制御装置は、デバイス間での通信および制御が、標準制御動作がユーザにとってトランスペアレントであるように実行されるように、スマートフィールドデバイス規格および他のバスベースアーキテクチャ規格を実現する。プロセス制御装置を使用すると、スマートデバイスおよび従来の非スマートデバイスを含む、理論的にかつ実質的には無制限の数および型のフィールドデバイスに対する接続が可能になる。多様な数および型のデバイスの制御動作および通信動作は、同時に、並行して実行される。

説明された設計環境は、プロセス制御デザイナーまたはユーザが、標準プロセス制御関数を修正したり、一意のカスタマイズされたプロセス制御関数を作成し、すべて１つの共通した環境内にある修正済みのまたは新規に作成されたプロセス制御関数に対応するグラフィックビューを作成できるようにする。設計環境は、関数の作成、およびエンジニアの関数が修正されたり、作成されると、修正または作成が関数のそれ以外のすべてのグラフィックビューにそれ自体を明示するように、それに関連するエンジニア、オペレータ、研究所職員と保守職員またはその他の希望されるユーザの両方にとって１つの共通したインタフェースを含む。さらに、設計環境は、属性と方法の１つの共通したデータベース構造を有しており、グラフィックは、修正済みまたは作成済みのプロセス制御関数を、他の希望されるグラフィックビューのような多様なエンジニア、オペレータ、研究所職員および保守職員により必要とされる、はしご型論理、連続ファンクションブロックまたはその他の設計言語などによってであろうと、デザイナーが希望するか、あるいは必要とするどんなグラフィック方法論においても表現できるようにするためのプロセス制御関数に関連している。

多くの利点は、前記システムおよび操作方法により達成される。１つの利点は、制御動作が、制御システムを通して分散されており、集中制御から生じる柔軟性の欠如を回避するという点である。別の利点は、制御システムがパーソナルコンピュータ（ＰＣ）ベースであるため、メインフレームベースのシステムに比較して安価であり、追加プロセスがシステムに追加されるにつれて容易にアップグレードされ、便利に複数ユーザによって操作されるという点である。ＰＣベースの制御は、さらに、Windows 95TMおよびWindows NTTMなどのユーザフレンドリなプログラミングとディスプレイプラットホームを可能にする点で有利である。

本発明に従って、プロセス制御装置は、標準型制御が非標準型デバイスに関して達成されるように、標準プロトコルにより定義されているファンクションブロックまたは制御関数の標準セットを実現、実行する。そのプロセス制御装置により、標準プロトコルデバイスは、ファンクションブロックおよび制御関数の標準セットを実現できる。プロセス制御装置は、ファンクションブロックを制御構造用の根本的なビルディングブロックとして使用することにより、すべての接続されているデバイスが標準デバイスであるかのように相対的なストラテジー（strategy（戦略））を実現する。これらのファンクションブロックは、すべての型のデバイス向けの制御構造を作成するように定義される。

多くの利点が、説明されるシステムおよび方法により得られる。１つの利点とは、接続されているデバイスが標準プロトコルデバイスであるのか、非標準プロトコルデバイスであるのかに関係なく、システムがきわめて統一されており、それによりシステム信頼性を高めるという点である。追加利点は、多様なデバイスを統一して取り扱うことにより、システム開発費用が大幅に削減されるという点である。別の利点とは、インテリジェントデバイスがインテリジェント機能を活用し、「ダム」（インテリジェントでない）デバイスがそれ以外の制御装置により制御されるように、幅広い異なるフィールドデバイスがサポートされているという点である。追加の利点は、ある特定のルーチンを実行しているソフトウエアルーチンが、きわめて再利用可能であり、ソフトウエア信頼性を高めるという点である。

本発明に従って、プロセス制御装置は、フィールドバスデバイスおよび非フィールドバスデバイスなどの分散型制御装置およびフィールドデバイスを含むプロセス制御ネットワーク内で、総体的な、ユーザにより作成されたコントロールストラテジーを実現する。ユーザは、複数のファンクションブロックおよび制御モジュールを構築し、フィールドバスデバイスおよび非フィールドバスデバイスの中にコントロールストラテジーのユーザにより指定される部分をダウンロードまたはインストールすることにより、コントロールストラテジーを定義する。それ以降、フィールドバスデバイスは、コントロールストラテジーのその他の部分に関係なく、総体的なストラテジーのダウンロードされた部分を自動的に実行する。例えば、フィールドデバイス、制御装置およびワークステーションを含むプロセス制御システム内では、フィールドデバイスの中にダウンロードまたはインストールされたコントロールストラテジーの部分は、制御装置およびワークステーションの制御動作とは無関係に、およびそれらに並行して動作するが、他の制御動作がフィールドバスデバイスを管理し、コントロールストラテジーのその他の部分を実現する。

説明されるプロセス制御システムおよび操作方法には、多くの利点がある。１つの利点とは、プロセスの物理的な制約まで制御プロセスをカスタマイズするために、多くの多様な専門知識レベル、経験レベルおよび訓練レベルのユーザに対しシステムが統一された汎用設計環境を供給するという点である。追加利点とは、説明されるシステムが、多様な制御装置およびデバイスの制御機能を使用し、希望されるときにこれらの制御機能を補足し、必要に応じて、プロセス制御システム全体に柔軟に制御機能性を分散するという点である。別の利点とは、プロセス制御システムが、新規のおよび異なった制御機能を実行するために、実質的には任意のサイズのプロセス内で容易に実現され、ユーザにより更新されるパーソナルコンピュータをベースにした設計に容易に基づいているという点である。この柔軟性は、すべての中心レベル、中間レベル、および周辺レベルを含む制御システム全体に制御機能を分散することにより達成される。

本発明に従って、プロセス制御システムは、複数のデバイスおよびシステム構成要素上で動作するプロセスに関係する診断情報を首尾一貫して表示するための診断監視表示機能性を含む。複数のデバイスおよびシステム構成要素は、典型的には、大幅に異なるデバイス型および操作基準を包含し、プロセス制御システムは、すべてのデバイスに関する診断情報を組み込み、動作コントロールストラテジーおよび診断情報が、あたかもすべての制御動作および診断情報が単一のロケーションで実行されたか、生成されたかのように、この情報を統一した様式でシステムユーザに提示する。ユーザ定義診断プログラムは、ファンクションブロックと制御モジュールのセットとしてアセンブルされ、属性としてアクセスされている情報構造を含むモジュールとして特定されている相互接続された制御オブジェクトの層のセットとして表現される。情報は、デバイス階層属性アドレス指定を使用し、モジュールからのＩ／Ｏ信号の直接アドレス指定をサポートし、Ｉ／Ｏ機能の使用をバイパスし、Ｉ／Ｏファンクションブロック動作を回避してアクセスされる。

多くの利点は、説明されるプロセス制御方法を使用して達成される。１つの利点は、制御体系および診断監視が同じようにシステム内で構成され、システムリソースを節約し、システム信頼性を高めるという点である。別の利点とは、診断の構成がきわめて用途が広く、広範囲の診断動作を達成するという点である。追加利点とは、同じ表示オブジェクトおよび手順が、構成情報、ステータス情報、診断、および事実上システム内で生成または記憶されているあらゆる他の情報を含む全種類の情報を表示するために使用されるという点である。

参考発明に従って、デジタル制御システムは、新規制御装置がネットワークに接続されるときを自動的に検知し、新規制御装置に接続されているＩ／Ｏポートの数および型を突き止める。デジタル制御システムは、Ｉ／Ｏポート情報をフォーマットし、ユーザによって要求されると表示する。デジタル制御システムプログラムは、入出力（Ｉ／Ｏ）サブシステムを自動的に構成することにより、新規制御装置の検知に応える自動構成プログラムも含む。ユーザは、物理的なスイッチやノードを設定しなくても新規制御装置を追加する。ユーザは、オプションで、デバイスの接続の前に、デバイスに関する構成情報をデータベースに供給する。デバイスの接続時、デバイスは、デバイスで物理的なスイッチを設定しなくても、データベース構成情報を使用して自動的に検知、構成される。

参考発明の別の態様に従って、制御装置のネットワークへの接続を自動的に検知し、制御装置をネットワークオペレーティングシステムの中に組み込むことは、制御装置をネットワークに接続するステップと、制御装置から要求を送信し、ネットワークアドレス割当てを確認するステップとを含み、要求には、制御装置メディアアクセス制御（ＭＡＣ）アドレスが付随し、ネットワーク構成サービスは確認のために要求を受信し、応答する。ネットワーク構成サービスは、一致するＭＡＣアドレスを求めて構成済みデバイスのテーブルを検索するステップと、ＭＡＣアドレスが一致すると、デバイスおよびネットワーク情報を生成するステップとを実行することにより応答する。デバイスおよびネットワーク情報は、デバイステーブルからのネットワークアドレスを含む。ＭＡＣアドレスが一致しないと、ネットワーク構成サービスは、ＭＡＣアドレスをベースにしたデフォルト情報からのネットワークアドレスを含むデバイスおよびネットワーク情報を作成し、デフォルト情報をデバイステーブルに追加する。ＭＡＣアドレスが一致しないと、ネットワーク構成サービスは、さらに、ユーザ制御下にある接続されている制御装置を、デバイステーブルに追加された新規デバイスとして、または過去にデバイステーブルに存在していたデバイス構成として割り当てるステップを実行する。

多くの利点は、説明されるシステムおよび方法により達成される。１つの利点とは、ローカル設定デバイスを使用する、デバイスの個々のフィールド設定が必要ないように、フィールドデバイスが離れた場所からプログラミングされるという点である。集中プログラム可能性（programmability）は、システム管理費用を削減するため、およびプロセス制御システムのダウンタイムを短縮するためにきわめて有効である。追加利点とは、個々のデバイスの設定よりむしろ、システム全体を構成する方が、個々のシステム設定がきわめて互換性があるシステムにつながるという点である。

参考発明の態様に従って、制御システムは、定義された制御構成に従って１つまたは複数の相互接続されているデバイスを制御する。制御システムは、制御システムに接続されているが、制御構成定義に含まれていないデバイスを自動的に検知する。制御システムは、デバイスから制御システムまで構成パラメータをアップロードするのに十分な初期相互接続情報を、接続されているデバイスに供給する。

参考発明の追加態様に従って、所定の構成のデジタル制御システムは、所定の構成に含まれていないデジタルデバイスのネットワークへの接続を自動的に検知する。デジタルデバイスは、一時アドレス情報を割り当てられ、スタンバイ状態と呼ばれている一時状態に置かれ、その場合デジタルデバイスがデジタル制御システムに情報を供給し、ユーザがデバイス情報および構成パラメータのアクセスを含むデジタルデバイスへアクセスできるようにする。デバイス情報および構成パラメータを使用して、ユーザは、物理デバイスタグおよびデバイスアドレスを割り当て、コントロールストラテジーをデジタルデバイスにインストールし、それによりデジタルデバイスを、デジタル制御システムとの通信で稼動状態にすることによって、デジタルデバイスを選択式に作動する。スタンバイ状態においては、ユーザは応答指令信号を送り、接続されているデバイスの型を突き止め、デジタル制御システムのコンテキストでのデバイスの役割を突き止め、突き止められた役割をデバイスに割り当てる物理デバイスタグを割り当て、ネットワークへのデバイスの接続を検証する。スタンバイ状態においても、ユーザは、デバイスの校正を含み、デジタル制御システムの総体的な制御体系内でデバイスを構成する、デバイスに適用されているそれ以外のアプリケーションを始動する。

参考発明の別の態様に従って、制御システムは、Fieldbus規格仕様に従って定義されている状態を越えたフィールドバスデバイス状態を区別する。制御システムは、タグを持たないデバイスのデバイス識別（ＩＤ）に等しい物理デバイスを設定するが、デバイスは自動検出される。デバイスＩＤに等しい物理デバイスタグセットとのフィールドバスリンクに接続されているデバイスは、初期化されていないデバイスの様式で制御される。

参考発明の態様に従って、フィールドデバイスの自動検知は、デジタル制御システムにより、従来の入／出力レベルを越えて、フィールドバスデバイスの構成まで拡張される。

説明されるシステムおよび方法により多くの利点が達成される。１つの利点とは、制御システムの構成が大幅に容易にされるという点である。デバイスのネットワークへの物理的な接続により、接続されているデバイスの制御システムの中への包含が始動する。説明されるシステムおよび方法は、構成の基礎として役立つ、ネットワークの構成とネットワークの物理的な相互接続の間の準拠を容易にする。説明されるシステムおよび方法は、ローカル設定デバイスを使用するデバイスの個々のフィールド設定が必要ないように、離れた場所からのフィールドデバイスのプログラミングを補助する。システムおよび方法は、システム管理費用を削減するため、およびプロセス制御システムのダウンタイムを短縮するためにきわめて有効である中央プログラム可能性をサポートする。追加利点とは、個々のデバイスの設定よりむしろ、システム全体を構成することの方が、個々のシステム設定がきわめて適合しているシステムにつながるという点である。

本発明に従って、プロセス制御システムは、複数のＩＥＣ−１１３１規格制御言語、および制御言語の中からのユーザ選択をサポートするユーザインタフェースを含んでいる。単一アプリケーションルーチンから、ユーザは、コントロールストラテジーを実現するために、例えば、ファンクションブロック、シーケンシャルファンクションチャート、はしご型論理およびストラクチャードテキストを含む複数の制御言語の中から１つの制御言語を選択する。

本発明の別の態様に従って、表示装置に接続されているプロセッサを備えているプロセス制御環境を構成するための方法は、複数の命令セクションを提供するステップを含む。命令セクションは、プロセス制御環境の構成に関する情報を述べる。方法は、プロセス制御環境構成を定義するために制御言語エディタを選択するステップと、選択されている制御言語エディタに関して指示されるように、命令セクションに関する構成画面提示のシーケンスを表示装置上に表示するステップと、構成画面提示のシーケンスを介してプロセス制御環境の構成を通してユーザを誘導するステップとも含む。

説明されるシステムおよび方法によって、多くの利点が達成される。１つの利点とは、広範囲の専門知識と経験を備えているユーザがシステムを容易に使用できるように、多くの異なるユーザがシステムによってサポートされているという点である。さらに、システムは、単一ユーザが、ある特定のシステム態様に対しもっとも適切な言語を使用して多様なシステムの態様を調整するのにきわめて有用である。

参考発明に従って、プロセス制御システムは、システムの多様なユーザが、表示されている警報イベント情報に容易に優先順位を設定できるように、警報イベント監視表示システムを含む。警報およびイベント構成はきわめて柔軟であり、ユーザにより命令されるように、階層構造で特定のイベントを表示するためにユーザにより構成される。ユーザは、所望の警報優先順位を設定し、より緊急な表示と予告のために高い重要性の警報を選択し、緊急性が低いイベントにはより低い表示ステータスを渡す（rendering）。ログオン時、ある特定のシステムユーザは、そのユーザに関連している警報イベント情報を表示するための表示構成と対応し、プロセス制御システムは、現在の警報を自動的に「提供され」ており、新規警報イベント派生についてのプロセス情報を始動する。

多くの利点が、説明されるプロセス制御方法を使用して達成される。１つの利点とは、警報情報が、ユーザによって命令される様式でその情報を最良に使用できるユーザに提示されるという点である。別の利点とは、ユーザが、ログオン時に自動的に適切な情報へのアクセスを達成するという点である。追加利点とは、関連する警報イベントがそのユーザのために即座蓄積を開始するように、ユーザがログオン時に、情報ストリームが「提供される」という点である。

図１Ａは、本発明の一般化されている実施態様に従ってプロセス制御システムを示す。図１Ｂは、図１Ａに図示されているプロセス制御システムの一部分をさらに詳細に示す図である。図１Ｃは、デジタル制御システム、プロセス制御装置等を実現するためのプロセス制御環境を示す図である。図２は、構成実装および実行時実装におけるプロセス制御環境を示す概略ブロック図である。図３は、プロセス制御環境の構成モデルと実行時モデルの両方とともに使用するためのユーザインタフェースを図解するブロック図である。図４は、本発明の実施態様に従って、構成モデルのシステムオブジェクトの間の階層関係を描写する概略ブロック図である。図５は、図４に示されている階層関係内で動作する構成アーキテクチャを描写する概略ブロック図である。図６は、構成モデル定義内でのある種のシステムオブジェクトである、要素ファンクションブロックの一例を示すブロック図である。図７は、構成モデル定義内での別の種類のシステムオブジェクトである、複合ファンクションブロックの一例を示すブロック図である。図８は、構成モデル定義内での別の種類のシステムオブジェクトである、制御モジュールの一例を示すブロック図である。図９は、図８に描かれている制御モジュール定義に従って作成される、モジュールインスタンス、特に制御モジュールインスタンスを示すブロック図である。図１０は、実行時の制御モジュールの実行の一例を示すフローチャートである。図１１は、制御構造の最高層にあるモジュールの一例を示している。図１２は、プロセスＩ／Ｏ属性ブロックをＰＩＯデバイスの中にインストールするオブジェクト指向方法を示すブロック図である。図１３は、制御モジュール入力属性をＰＩＯ属性にリンクするためのオブジェクト指向方法を描くブロック図である。図１４は、制御モジュール出力属性をＰＩＯ属性にリンクするためのオブジェクト指向方法を示すブロック図である。図１５は、記憶されているＰＩＯ属性の値を読み取るためのオブジェクト指向方法を示すブロック図である。図１６は、計測器信号タグ用の情報の編成を示すブロック図である。図１７は、プロセス制御環境でのネットワーク全体での制御システムをブートストラップロードするための方法を示すフローチャートである。図１８Ａ及び図１８Ｂは、接続のアクティブな発生側にデバイス接続を作成するための方法を示すオブジェクト通信図である。図１８Ａ及び図１８Ｂは、接続のアクティブな発生側にデバイス接続を作成するための方法を示すオブジェクト通信図である。図１９は、接続の受動的なリスン（listen）側にデバイス接続を作成するための方法を示すオブジェクト通信図である。図２０は、要求／応答メッセージをデバイス間で送信するための方法を示すオブジェクト通信図である。図２１Ａ及び図２１Ｂは、ネットワーク構成をダウンロードする方法を示すオブジェクト通信図である。図２１Ａ及び図２１Ｂは、ネットワーク構成をダウンロードする方法を示すオブジェクト通信図である。図２２は、診断表示ルーチンの動作のフローチャートを示す、画面前面（front-of-screen）ディスプレイの絵入りのビューである。図２３は、あるデバイスが、別のデバイスがネットワーク上に存在するかどうかをチェックするための方法を示すオブジェクト通信図である。図２４Ａ及び図２４Ｂは、デバイス通信診断を要求するための方法を示すオブジェクト通信図である。図２４Ａ及び図２４Ｂは、デバイス通信診断を要求するための方法を示すオブジェクト通信図である。図２５Ａ及び図２５Ｂは、デバイス接続通信診断を要求するための方法を示すオブジェクト通信図である。図２５Ａ及び図２５Ｂは、デバイス接続通信診断を要求するための方法を示すオブジェクト通信図である。図２６は、制御装置／マルチプレクサを自動的に検知し、実行時システムの中に組み込むための方法の手順を示す図である。図２７は、物理Ｉ／Ｏデバイスを構成するための自動構成ルーチンのステップを示すフローチャートである。図２８は、システム構成を表示するグラフィックユーザインタフェース（ＧＵＩ）用画面前面ディスプレイの絵入りのビューである。図２９は、フィールドデバイスの多様な状態を示す状態遷移図である。図３０は、新規デバイスを作動する第１動作を示すフローチャートである。図３１は、結合していないものを作動させる第２動作を示すフローチャートである。図３２は、デバイスの使用を中止する第３動作を示すフローチャートである。図３３は、稼動電源投入を使用可能としないで、作動されているデバイスを接続する第４動作を示すフローチャートである。図３４は、デバイスを置換する第５動作を示すフローチャートである。図３５は、未認識デバイスを接続する第６動作を示すフローチャートである。図３６は、認識されていないデバイスの使用を中止する第７動作を示すフローチャートである。図３７は、使用を中止されているデバイスをスタンバイ状態にする第８動作を示すフローチャートである。図３８は、複数の言語を使用してプロセス構成を定義するためのプロセス制御構成プログラムのプログラム構造を図解する概略ブロック図である。図３９Ａから図３９Ｅは、ファンクションブロック制御言語およびシーケンシャルファンクションチャート制御言語を使用して、構成動作の動作中に構成プログラムにより呼び出される構成画面、選択項目画面、および選択画面を示す複数の画面提示である。図３９Ａから図３９Ｅは、ファンクションブロック制御言語およびシーケンシャルファンクションチャート制御言語を使用して、構成動作の動作中に構成プログラムにより呼び出される構成画面、選択項目画面、および選択画面を示す複数の画面提示である。図３９Ａから図３９Ｅは、ファンクションブロック制御言語およびシーケンシャルファンクションチャート制御言語を使用して、構成動作の動作中に構成プログラムにより呼び出される構成画面、選択項目画面、および選択画面を示す複数の画面提示である。図３９Ａから図３９Ｅは、ファンクションブロック制御言語およびシーケンシャルファンクションチャート制御言語を使用して、構成動作の動作中に構成プログラムにより呼び出される構成画面、選択項目画面、および選択画面を示す複数の画面提示である。図３９Ａから図３９Ｅは、ファンクションブロック制御言語およびシーケンシャルファンクションチャート制御言語を使用して、構成動作の動作中に構成プログラムにより呼び出される構成画面、選択項目画面、および選択画面を示す複数の画面提示である。図４０Ａ、図４０Ｂ及び図４０Ｃは、警報機能およびイベント機能を取り扱うための多様なオブジェクトのオブジェクト関係を示すオブジェクトモデルである。図４０Ａ、図４０Ｂ及び図４０Ｃは、警報機能およびイベント関数を取り扱うための多様なオブジェクトのオブジェクト関係を示すオブジェクトモデルである。図４０Ａ、図４０Ｂ及び図４０Ｃは、警報関数およびイベント関数を取り扱うための多様なオブジェクトのオブジェクト関係を示すオブジェクトモデルである。図４１は、警報属性状態を描く状態遷移図である。図４２は、制御モジュールに関して警報イベントを定義するためのコンテキストを示すコンテキスト図である。図４３は、「イン警報（in alarm）」ステータスを喚起する（evokes）属性書込み動作を実行するための方法を示すオブジェクト通信図である。

以下、本発明の実施形態を図１Ａ乃至図２５Ｂを用いて例示する。
新規であると考えられている本発明の特徴は、添付した請求項に明確に述べられている。しかしながら、発明自体は、その構造（プロセス制御システム）に関して、以下の説明および添付図面を参照することによりもっともよく理解できる。

図１Ａを参照すると、制御システムが図示されている。一般的には、システム１は、ローカルエリアネットワークカードを介してローカルエリアネットワーク（「ＬＡＮ」）３に接続されているパーソナルコンピュータ２のようなメイン処理装置を含む。どのローカルエリアネットワークプロトコルも使用してよいが、ローカルエリアネットワーク３との通信を可能とするため、多くのアプリケーションでは所有権を主張できない（non-proprietary）イーサネットプロトコルが有益である。ローカルエリアネットワーク３は、プロセス制御システム内で関係している制御パラメータ、制御データ、およびその他の関連情報を搬送する専用である。そのようなものとして、ＬＡＮ３は、エリア制御ネットワークつまりＡＣＮ３と呼ばれてよい。ＡＣＮ３は、ＡＣＮ３の専用の性質に影響を及ぼさないでハブまたはゲートウェイを介して情報およびデータを共用するために他のＬＡＮに接続されてよい。

標準イーサネットプロトコルに従って、複数の物理デバイスが、多様な「ノード」でＡＣＮ３に接続されてよい。ＡＣＮ３に接続されている各物理デバイスは、ノードで接続されており、各ノードは、ＡＣＮ３を実現するために使用されているＬＡＮプロトコルに従って別個にアドレス指定可能である。

冗長システムを確立するためには、単一イーサネットまたはＬＡＮシステムの故障の結果、システム全体の故障が生じないように、２つまたは３つ以上のイーサネットシステムからＡＣＮ３を構築することが望ましいことがある。このような「冗長イーサネット」が使用されているとき、１つのイーサネットＬＡＮの故障は検出され、代わりのイーサネットＬＡＮが、ＡＣＮ３の所望の機能性を提供するためにマッピングすることができる。

メインパーソナルコンピュータ（「ＰＣ」）２は、ＡＣＮ３上でノードを形成する。ＰＣ２は、例えば、MicrosoftのWindow NTシステムなどの標準オペレーティングシステムを実行している標準パーソナルコンピュータであってよい。メインＰＣ２は、ユーザ入力コマンドに応えて、ＡＣＮ３を介して、メインＰＣ２内で選択、確立されている制御ルーチンにより定義されているコントロールストラテジーを実現する要素４と５として特定されている１つまたは複数のローカル制御装置に提供され、多様な制御ルーチンを生成するように構成される。メインＰＣ２は、ローカル制御装置４または５を介してよりむしろ、ＡＣＮ３全体での伝達を介して、ポンプ、弁、モータ等のフィールドデバイス上で直接制御ルーチンを実現するように構成されてもよい。

ローカル制御装置４と５は、ＰＣ２からＡＣＮ３を通して制御ルーチンおよびその他の
構成データを受け取る。それから、ローカル制御装置は、ＰＣ２により提供されているル
ーチンにより確立されている制御システムを実現するために、フィールド内で物理ステッ
プを実際に実現し、実行する、（ポンプ、モータ、調整器弁などの）多様なフィールドデ
バイス６から１５に対する多様な種類の信号を生成する。

２つの型のフィールドデバイスが、FieldBus、Profitbus等などの特定の制御プロトコルに反応するデバイス６から１１を含むローカル制御装置４と５に接続されてよい。当業者が理解するように、それらに従って特定プロトコル命令が（フィールドバスフィールドデバイスなどの）プロトコルフレンドリなデバイスに提供され、フィールドデバイス内に位置している制御装置に、プロトコル機能に対応するある特定の機能を実現させる、（フィールドバスなどの）標準制御プロトコルがある。したがって、フィールドデバイス６から１１は、プロトコルに特有な（例えばFieldBus）制御コマンドを、ローカル制御装置４と５、またはパーソナルコンピュータ２のどちらかから受け取り、フィールドデバイスに特定の機能を実現する。

ここでもまたローカル制御装置４と５に接続されているのは、それらは局所的な処理力を含まず、直接制御信号に応えることができるため、非プロトコルと呼ばれている非プロトコルフィールドデバイス１２から１５である。したがって、フィールドデバイス１２から１５は、FieldBus制御プロトコルなどの特定制御プロトコルにより定義されるだろう機能を実現することができない。

非プロトコルフィールドデバイス１２から１５を、プロトコルフレンドリ（例えば、FieldBusに特有な）デバイス６から１１として動作できるようにするために、機能性が供給される。さらに、この同じ機能性により、ローカルフィールドデバイス６から１１、ローカル制御装置４と５、およびパーソナルコンピュータ２の間で、プロトコルに特有な制御ルーチンの実装を分散できるようになる。

プロトコルに特有な制御ルーチンの配置は、図１Ｂに詳細に示されている。図１Ｂは、図１Ａに図示されているシステム、特にパーソナルコンピュータ２、イーサネット３、ローカル制御装置４、スマートフィールドデバイス６、およびダムデバイス１２の一部分をさらに詳細に参照している。

パーソナルコンピュータ２は、FieldBusプロトコルなどの標準制御プロトコルの標準機能ルーチンを実現するためのプログラムソフトウエアルーチンを含む。したがって、パーソナルコンピュータ２は、FieldBusコマンドを受け取り、フィールドバス機能を備えているローカルフィールドデバイスが実現できるだろう機能ルーチンのすべてを実現するようにプログラミングされる。FieldBusブロック機能性を実現するためにパーソナルコンピュータ２をプログラミングする能力およびステップは、技術で通常の技能を持つ人にとっては明らかであろう。

イーサネット３によりパーソナルコンピュータ２に接続されているのは、ローカル制御装置４である。ローカル制御装置４は、中央演算処理装置を構成し、適切な実用可能な（operational）機能を実現するために制御信号を提供するランダムアクセスメモリに接続されている中央演算処理装置を含む。読取り専用メモリは、ランダムアクセスメモリに接続されている。読取り専用メモリは、FieldBusのような標準制御プロトコルの機能ルーチンのすべてを実現するように中央演算処理装置を構成することができる制御ルーチンを含むようにプログラミングされる。パーソナルコンピュータ２は、読取り専用メモリ内のプログラマルーチンの１つ、２つ以上、あるいはすべてを、FieldBusルーチンなどの標準制御プロトコルルーチンの１つ、２つ以上、またはすべてを実現するようにＣＰＵを構成するために、ランダムアクセスメモリに転送させる、ローカル制御装置４にイーサネット３を通して信号を送信する。

スマートフィールドデバイス６は、一定の制御機能を実現する中央演算処理装置を含む。デバイスが、例えばFieldBusデバイスである場合には、フィールドデバイス６に結び付いている中央演算処理装置は、FieldBus機能性要件のすべてを実現できる。

ローカル制御装置４には、FieldBusに特有な制御を実現する能力があるため、制御装置４は、非プロトコルデバイス１２がFieldBusデバイスとして動作し、操作されるように動作する。例えば、制御ルーチンがパーソナルコンピュータ２内で、またはローカル制御装置４のＣＰＵで実行している場合、その制御ルーチンは、FieldBusコマンドを実現し、FieldBusデバイス６とフィールドバスデバイスとして動作している非プロトコルデバイス１２に提供することができる。フィールドデバイス６はFieldBusデバイスであるため、デバイス６は、これらのコマンドを受け取り、それによりそれらのコマンドによって命令される制御機能性を実現する。しかしながら、非プロトコルデバイス１２は、ローカル制御装置４の中央演算処理装置とともに動作し、フィールドデバイスと組み合わされているローカル制御装置がFieldBusコマンドを実現し、操作するように、FieldBus要件を実現する。

非FieldBusデバイス１２が、FieldBusデバイスとして行動（ａｃｔ）し、動作できるようにすることに加えて、説明された態様は、図１Ａに図示されているシステム１全体でのFieldBus制御ルーチンの分散を可能にする。例えば、制御ルーチンが、当初、フィールドデバイス６に複数のFieldBus制御ルーチンを実現するように要求する範囲まで、システム１は、FieldBus制御ルーチンの一部がローカル制御装置５により実現されており、それ以外のFieldBusルーチンがローカル制御装置４に記憶されているFieldBusルーチンの使用により実現されるように、制御をローカル制御装置４とローカル制御装置５の間で分けることを可能にする。FieldBusルーチン実装の分割は、さらに精密でさらに高速な制御、およびシステムの総体的な処理力のさらに効率的な活用を可能にすることがある。さらに、パーソナルコンピュータ２に、FieldBus制御ルーチンを実現する能力があるという事実、FieldBusルーチンは、ローカル制御装置４とパーソナルコンピュータ２の間でさらに分散される。このようにして、システムは、パーソナルコンピュータ２が、ある特定の制御アルゴリズムに対してFieldBusルーチンの１つまたはすべてを実現できるようにする。

さらに、システムは、FieldBusルーチンが、ローカル制御装置４で記憶されているFieldBusルーチンで使用することにより、非FieldBusデバイス１２で実現されるのと同じように、パーソナルコンピュータ２に記憶されているFieldBus制御ルーチンを使用することにより、イーサネット３に直接接続されている非FieldBusデバイスに対するFieldBus制御の実装を可能にする。

プロセス制御環境（プロセス制御システム）１００は図１Ｃに図示され、デジタル制御システム、プロセス制御装置等を実現するための制御環境を図解する。プロセス制御環境１００は、多様なワークステーションと複数の制御装置／マルチプレクサ１１０の間でデータおよび制御信号を転送、受信するために、ローカルエリアネットワーク（「ＬＡＮ」）１０８によって電気的に相互接続されている、オペレータワークステーション１０２、実験室ワークステーション１０４、およびエンジニアリングワークステーション１０６を含む。ワークステーション１０２、１０４、１０６は、ＬＡＮ１０８により、ワークステーションと複数のプロセス１１２の間で電気的に接続して機能する（interface）複数の制御装置／マルチプレクサ１１０に接続されていると図示されている。複数の多様な実施態様においては、ＬＡＮ１０８は、制御装置／マルチプレクサ１１０に直接的に接続されている単一のワークステーションを含むか、あるいは代わりに、プロセス制御環境１００の目的および要件に応じて、複数のワークステーション、例えば３つのワークステーション１０２、１０４、１０６および多くの制御装置／マルチプレクサ１１０を含む。単一プロセス制御装置／マルチプレクサ１１０が複数のプロセス１１２を制御するか、あるいは代わりに単一プロセスの一部を制御する実施態様もある。

プロセス制御環境１００においては、プロセスコントロールストラテジーは、例えば、エンジニアリングワークステーション１０６でソフトウエア制御ソリューションを作成し、実行のために、ＬＡＮ１０８を介してソリューションをオペレータワークステーション１０２、実験室ワークステーション１０４、および制御装置／マルチプレクサ１１０に転送することにより展開される。オペレータワークステーション１０２および実験室ワークステーション１０４供給インタフェースは、制御装置／マルチプレクサ１１０内で実現されている制御／監視ストラテジーに表示し、プロセス１１２を表示し、設計されているソリューションの要件に従って、属性値を変更するために、制御装置／マルチプレクサ１１０の１つまたは複数に通信する。プロセス１１２は、スマートフィールドデバイスまたは従来の（非スマート）フィールドデバイスであってよい、１つまたは複数のフィールドデバイスから形成されている。プロセス１１２は、２つのフィールドバスデバイス１３２、ＨＡＲＴ（ハイウェイアドレス指定可能リモート変換器（highway addressable remote transducer））デバイス１３４、および従来のフィールドデバイス１３６として実例として描かれている。

加えて、オペレータワークステーション１０２および実験室ワークステーション１０４は、制御されているプロセス１１２のステータスおよび状態に関してオペレータに視覚フィードバックおよび音声フィードバックを通信する。エンジニアリングワークステーション１０６は、中央演算処理装置（ＣＰＵ）１１６とディスプレイ、およびキーボード、ライトペン等の入／出力装置またはユーザインタフェースデバイス１１８を含む。ＣＰＵ１１６は、典型的には専用メモリ１１７を含む。専用メモリ１１７は、図１Ｃに図示されているプロセス制御環境１００の制御動作および機能を実現するためにＣＰＵ１１６上で実行する、デジタル制御システムプログラム（図示されていない）を含む。プロセス制御環境１００内でのオペレータワークステーション１０２、実験室ワークステーション１０４、および他のワークステーション（図示されていない）は、ユーザとＣＰＵの間での対話を可能とするために、ディスプレイ（図示されていない）およびユーザインタフェースデバイス（図示されていない）に電気的に接続されている少なくとも１つの中央演算処理装置（図示されていない）を含む。１つの実施態様においては、プロセス制御環境１００は、６８３６０プロセッサにより動かされている一次イーサネットポートと二次イーサネットポート（それぞれＳＣＳＩとＳＣＣ３）のある６８０４０とのコンパニオン（companion）モードで実行している、Motorola ６８０４０プロセッサおよびMotorola ６８３６０通信プロセッサを使用して実現されているワークステーションを含む。

プロセス制御環境１００は、組み合わされて制御テンプレートシステム１２０を形成している、テンプレートジェネレータ１２４および制御テンプレートライブラリ１２３も含む。制御テンプレートは、プロセス、およびある特定のプロセス制御関数、制御属性、変数、および特定の関数に対する出力、および必要に応じて、エンジニアビューとオペレータビューなどの関数のグラフィックビューに使用されている手法(methodology)を制御するために使用される属性及び関数のグルーピングとして定義される。

制御テンプレートシステム１２０は、テンプレートジェネレータ１２４と通信する制御テンプレートライブラリ１２３を含む。制御テンプレートライブラリ１２３は、プロセス制御プログラムで使用するための、事前に定義されたまたは既存の制御テンプレート関数のセットを表すデータを記憶する。制御テンプレート関数とは、一般的にシステムデザイナーからユーザへとシステムに付属するテンプレートである。テンプレートジェネレータ１２４とは、有利に、ユーザが、制御テンプレート関数を作成したり、既存の制御テンプレート関数を修正できるようにするインタフェースのことである。作成され、修正されたテンプレート関数は、制御テンプレートライブラリ１２３内に選択式で記憶される。

テンプレートジェネレータ１２４は、属性方法言語ジェネレータ１２６、およびグラフィックジェネレータ１２８を含む。属性方法言語ジェネレータ１２６は、ユーザが特定の制御テンプレートのために新しい、または修正済みの関数を実行する方法またはプログラムを選択できるようにするために表示画面を提供することだけではなく、ユーザが、新しい制御テンプレート関数の作成、またはある特定の既存の制御テンプレート関数の修正に関連している複数の属性関数を定義できるようにする表示画面を供給する。グラフィックジェネレータ１２８は、特定の制御テンプレートに対応しているグラフィックビューを設計する能力をユーザに与える。ユーザは、属性方法言語ジェネレータ１２６およびグラフィックジェネレータ１２８によって記憶されているデータを活用し、制御テンプレートに対し属性方法およびグラフィックビューを完全に定義する。作成済みの制御テンプレート関数を表すデータは、通常、制御テンプレートライブラリ１２３に記憶され、それ以降、プロセス制御ソリューションを設計するためにエンジニアが選択および使用する場合に利用できる。

プロセス制御環境１００は、オブジェクト指向フレームワークを使用して実現される。オブジェクト指向フレームワークは、クラス階層、オブジェクト状態、およびオブジェクト動作などのオブジェクト指向概念を使用する。以下に簡略に説明されているこれらの概念は、技術においてよく知られている。さらに、オブジェクト指向フレームワークは、技術でよく知られている、Ｃ＋＋プログラミング言語などのオブジェクト指向プログラミング言語を使用して作成されるか、あるいは好まれている実施態様での場合のように、Ｃなどの非オブジェクト言語を使用し、その言語でオブジェクト指向フレームワークを実現して作成されてよい。

オブジェクト指向フレームワークのビルディングブロックは、オブジェクトである。オブジェクトは状態および動作により定義される。オブジェクトの状態は、オブジェクトのフィールドにより述べられる。オブジェクトの動作は、オブジェクトの方法により述べられる。各オブジェクトは、オブジェクトにテンプレートを提供するクラスの実体（以下では、インスタンスという）である。クラスは、ゼロまたはそれ以上のフィールド、およびゼロまたはそれ以上の方法を定義する。

フィールドとは、オブジェクトの状態の一部を定義している情報を含むデータ構造である。同じクラスのインスタンスであるオブジェクトは、同じフィールドを持つ。ただし、オブジェクトのフィールド内に記憶されている特定の情報は、オブジェクトごとに変わることがある。各フィールドには、整数値などの直接的である、あるいは別のオブジェクトに対する参照などの間接的である情報が記憶できる。

方法とは、コンピュータシステムソフトウエアによりＣＰＵ１１６内で実行できるコンピュータ命令の集合体である。ソフトウエアが、方法が定義されているオブジェクトが方法を達成するように要求すると、方法の命令は実行され、つまり方法は達成される。方法は、方法を含むクラスのメンバーである任意のオブジェクトにより達成できる。その方法を達成しているその特定のオブジェクトは、応答者、つまり応答しているオブジェクトである。方法を達成する時に、応答者は１つまたは複数の引数、つまり入力データを消費し、ゼロまたは１つの結果、つまり出力データとして戻されるオブジェクトを作成する。ある特定のオブジェクトに対する方法が、そのオブジェクトの動作を定義する。

オブジェクト指向フレームワークのクラスは、クラス階層で編成される。クラス階層においては、クラスは、そのクラスのスーパークラスにより定義されるフィールドと方法を継承する。さらに、クラスによって定義されているフィールドおよび方法は、そのクラスのサブクラスによって継承される。すなわち、サブクラスのインスタンスは、スーパークラスによって定義されているフィールドを含み、スーパークラスによって定義されている方法を達成することができる。したがって、オブジェクトの方法が呼び出されると、アクセスされる方法は、オブジェクトがそのメンバーであるクラスで、あるいはオブジェクトがメンバーであるクラスのスーパークラスの任意の１つで定義されることがある。オブジェクトの方法が呼び出されると、プロセス制御環境１００は、オブジェクトのクラス、および必要な場合にはオブジェクトのあらゆるスーパークラスを調べることによって、実行する方法を選択する。

サブクラスは、サブクラスの動作を改善または変更するために、スーパークラスから継承される方法定義を無効にしたり、取って代わることがある。ただし、サブクラスは、方法のシグナチャに取って代わることができない。方法のシグナチャは、方法の識別子、引数の数と型、結果が戻されるかどうか、および戻される場合には結果の種類を含む。サブクラスは、方法の性能という点で、実行されるコンピュータ命令を定義し直すことにより継承されている方法定義に取って代わることがある。

インスタンスを持つことができるクラスは、具象クラスである。インスタンスを持つことができないクラスは、抽象クラスである。抽象クラスは、抽象クラスのサブクラスによって継承されるフィールドおよび方法を定義してよい。ただし、抽象クラスのサブクラス
は、他の抽象クラスであることがある。ただし、究極的には、クラス階層内で
は、サブクラスは具象クラスである。

以下に説明される混合（mix-in）クラスを除いては、開示されている好まれる実施態様に定義されているすべてのクラスは、クラスのサブクラス、オブジェクトである。したがって、ここに説明されており、混合クラスではない各クラスは、クラスオブジェクトの方法およびフィールドを継承する。

プロセス制御環境１００は、図２に図示されている、構成モデル、つまり構成実装２１０の、および実行時モデル、つまり実行時実装２２０の中に存在する。構成実装２１０においては、プロセス制御環境１００内の構成要素デバイス、オブジェクト、相互接続、および相互関係が定義される。実行時実装２２０においては、多様な構成要素デバイス、オブジェクト、相互接続、および相互関係の動作が実行される。構成実装２１０および実行時実装２２０は、ダウンロードすることにより相互接続される。ダウンロードされた言語（制御言語）は、ユーザによって供給されている定義に従ってシステムオブジェクトを作成し、供給されている定義からインスタンスを作成する。具体的には、各デバイスに関係する完全に構成されているデバイステーブルが、起動時に、およびデバイステーブルが変更されると、すべてのワークステーションにダウンロードされる。制御装置／マルチプレクサ１１０の場合、ダウンロードされたデバイステーブルは、制御装置／マルチプレクサ１１０が、特定の制御装置／マルチプレクサ１１０内で構成され、使用されている遠隔モジュールデータに基づいて通信を始動しなければならないデバイスのためのデータだけを含んでいる。他の構成データがダウンロードされるときに、デバイステーブルが制御装置／マルチプレクサ１１０にダウンロードされる。定義をダウンロードすることに加えて、ダウンロード言語（制御言語）は、インスタンスおよびインスタンス値もアップロードする。構成実装２１０は、インストール手順を使用して実行時実装２２０内で実行するために起動される。また、ネットワーク通信パラメータは、構成データがダウンロードされるとき、および値が変更されるときに各デバイスにダウンロードされる。

プロセス制御環境１００は、複数のサブシステムを含んでおり、サブシステムの内のいくつかは構成実装と実行時実装の両方を備えている。例えば、プロセスグラフィックサブシステム２３０は、ユーザ定義ビューおよびオペレータ接続（interfacing）をプロセス制御環境１００のアーキテクチャに供給する。プロセスグラフィックサブシステム２３０は、構成実装２１０の一部であるプロセスグラフィックエディタ２３２、および実行時実装２２０の部分であるプロセスグラフィックビューア２３４を有している。プロセスグラフィックエディタ２３２は、ダウンロードされた言語（制御言語）での相互サブシステムインタフェース２３６によりプロセスグラフィックビューア２３４に接続されている。プロセス制御環境１００は、制御モジュールおよび装置モジュールを構成し、定義及びモジュールエディタ２４２の中にインストールし、実行時制御装置２４４の中で制御モジュールおよび装置モジュールを実行する制御サブシステム２４０も含む。定義及びモジュールエディタ２４２は、構成実装２１０内で動作し、実行時制御装置２４４は実行時実装２２０内で動作し、連続順序制御関数を供給する。定義及びモジュールエディタ２４２は、ダウンロードされた言語（制御言語）で相互サブシステムインタフェース２４６によって実行時制御装置２４４に接続される。複数のサブシステムが、サブシステムインタフェース２５０によって相互接続される。

構成実装２１０および実行時実装２２０は、マスタデータベース２６０に接続し（interface）、共通のデータ構造をサポートする。多様なローカル（非マスタ）データベース２６２は、マスタデータベースにインターフェイスし、例えば、ユーザによって命令されるように、構成データをマスタデータベース２６０からローカルデータベース２６２に転送する。マスターデータベース２６０の一部は、永続データベース２７０である。永続データベース２７０とは、データベースの作成者が存在しなくなってもデータベースが存在し続けるように時間の限界を超え（transcends）、データベースが、それが作成されたアドレス空間とは異なるアドレス空間へ削除可能であるように空間の限界を超える（transcends）オブジェクトのことである。構成実装２１０の全体は、永続データベース２７０に記憶される。

マスタデータベース２６０およびローカルデータベース２６２は、構成、統計、および診断の文書が文書化目的で利用できるようにアクセス可能である。

実行時インタフェース２２０は、永続データベース２７０およびローカルデータベース２６２にインターフェイスし、構成実装２１０により形成されているデータ構造にアクセスする。特に、実行時実装２２０は、選択されている装置モジュール、ディスプレイ等をローカルデータベース２６２および永続データベース２７０からフェッチする。実行時実装２２０は、それ以外のサブシステムにインターフェイスし、定義をインストールし、それにより定義がまだ存在していないときにインスタンスを作成するために使用されるオブジェクトをインストールし、実行時インスタンスを具体化し、多様なソースからの情報を宛先オブジェクトに転送する。

デバイステーブルは、デバイスにとってローカルであり、組み合わせて構成実装２１０を定義する構成データベースの要素である。デバイステーブルには、プロセス制御環境１００内のデバイスに関する情報が包含されている。デバイステーブル内の情報アイテムは、デバイスＩＤ、デバイス名、デバイス型、ＰＣＮネットワーク番号、ＡＣＮセグメント番号、シンプレックス／冗長通信フラグ、制御装置MACアドレス、コメントフィールド、一次インターネットプロトコル（ＩＰ）アドレス、一次サブネットマスク、二次ＩＰアドレス、および二次サブネットマスクを含む。

図３を参照すると、ブロック図が、プロセス制御環境１００の構成モデルと実行時モデルの両方とともに使用するためのユーザインタフェース３００を示している。ユーザインタフェース３００の一部は、デバイスをベースにした構成アプローチを特徴とするWindows NTTMオペレーティングシステムで定義されているインターフェイスプログラムであるExplorerTM 310である。ユーザインタフェース３００の別の一部は、制御ベースの構成アプローチを使用してインターフェイスするためのモジュール定義エディタ３２０である。

ExplorerTM 310は、構成を選択、構築および操作するためにユーザにより操作される。さらに、ExplorerTM 310は、ネットワーク内の多様なツールおよびプロセッサを横切ってナビゲーションするための初期状態を供給する。ユーザは、ExplorerTM 310を制御し、ライブラリ、領域、プロセス制御装置、およびに機密保護動作にアクセスする。図３は、プロセス制御環境１００内で動作しているタスクによりアクセスされてよい多様なツールの間の関係、およびライブラリ、領域、プロセス制御環境および機密保護などのプロセス制御環境１００の構成要素間の関係を示している。例えば、ユーザが「タグ表示」機能を領域内から選択すると、「タグリストビルダー（builder）」が表示され、制御フラグおよびＩ／Ｏフラグのリストを示す。タグリストビルダーから、ユーザは「タグ追加」機能を使用して、リストにモジュールを追加し、それにより「モジュールエディタ」を呼び出すことができる。

図４を参照すると、概略ブロック図が、構成モデル４００のシステムオブジェクト間の階層構造関係を示している。構成モデル４００は、制御、Ｉ／Ｏ、プロセスグラフィックス、プロセス装置、警報、履歴およびイベントを含む多くの構成態様を含む。構成モデル４００は、デバイス説明およびネットワークトポロジーレイアウトも含む。

構成モデル階層４００は、システムオブジェクトの関係およびロケーションを視覚化し、多様なシステムオブジェクト間の保守情報を通信またはナビゲーションするためにある特定のユーザによって使用されるために定義される。例えば、１つの構成モデル階層４００、具体的には物理プラント階層は、物理的なプラント関係およびロケーションを視覚化し、物理的なプラント内の多様な計器および装置間で保守情報を通信またはナビゲーションするために、保守エンジニアおよび技術者によって使用されるために定義される。物理プラント階層を形成する構成モデル階層４００の実施態様は、ＳＰ８８物理装置規格階層のサブセットをサポートし、構成モデルサイト４１０、１つまたは複数の物理プラント領域４２０、装置モジュール４３０、および制御モジュール４４０を含む。

構成モデル階層４００は、構成モデル階層４００内で定義されている１つまたは複数の指定済み物理プラント領域に分割される単一のプロセスサイト４１０に定義されている。物理プラント領域４２０はオプションでタグ付きの複数のモジュールを包含し、そのそれぞれは構成モデル階層４００内で一意に具体化される。物理プラント領域４２０は、オプションで１つまたは複数の装置モジュール４３０を包含する。装置モジュール４３０は、オプションでその他の装置モジュール４３０、制御モジュール４４０、およびファンクションブロックを包含する。装置モジュール４３０は、連続ファンクションブロック、はしご形論理、またはシーケンシャルファンクションチャート（「ＳＦＣ」）を含む多くの異なったグラフィックプロセス制御プログラミングテンプレートに従って作成される制御テンプレートを含み、それにより制御される。構成モデル階層４００は、オプションで１つまたは複数の制御モジュール４４０を包含する。制御モジュール４４０は、物理プラント領域４２０、装置モジュール４３０、または別の制御モジュール４４０などのオブジェクトに包含される。制御モジュール４４０は、オプションで、その他の制御モジュール４４０またはファンクションブロックを包含する。かくして、制御モジュール４４０は、コンテナクラスであり、他のオブジェクトの集合であるインスタンスを有している。制御モジュール４４４は、制御モジュールの方法のコンテンツおよび実装のすべてが非表示となるようにカプセル化される。

図５を参照すると、概略ブロック図が、図４に示されている構成モデル階層４００内で動作する構成アーキテクチャ５００を示している。構成アーキテクチャ５００は、抽象の複数のレベルでの複数のオブジェクトおよびクラスを含む。抽象５１０の組織上のレベルでは、構成アーキテクチャ５００が、構成アーキテクチャ５００内で「名前が付けられている」オブジェクトおよびクラスを包含するサイトクラス５１２を含む。名前が付けられているオブジェクトおよびクラスとは、定義、画面とグラフィックスなどの表示構成要素、およびそれ以外のアイテムである。指定されているオブジェクトおよびクラスはファンクションブロック、ユーザアカウント、モジュール、プラント領域、イベント、ライブラリ、およびその他のサイト全体での情報を含む。名前が付けられているアイテムの例とは、ブロック定義、装置モジュール定義、制御モジュール定義、プラント領域名等である。

抽象５２０のプリミティブレベルでは、構成アーキテクチャ５００が、「＋」などのハードコーディング（hard-coded）されている関数を含む、構成アーキテクチャ５００内での関数に対するインタフェースを定義するプリミティブを含む。抽象５２０のプリミティブレベルは、関数５２２およびパラメータ５２４のクラスを含む。関数５２２は、構成アーキテクチャ５００の抽象の最低レベルでの稼動（operational）関数である。関数５２２は、通常、ＣまたはＣ＋＋言語で符号化されている。構成アーキテクチャ５００の１つの実施態様においては、実現されているファンクションブロック５２２の完全なセットはプリミティブである。抽象５２０のプリミティブレベルでのオブジェクトおよびクラスは、サイトクラス５１２全体で定義される。パラメータ５２４は、構成アーキテクチャの最低抽象レベルでのクラスおよびオブジェクトである。パラメータ５２４は、整数、実数、ベクタ、アレイ等を含む。属性値は、ファンクションブロック５２２内で使用するためにパラメータ５２４にマッピングされる。１つの実施態様において、抽象５２０のプリミティブレベルにあるファンクションブロック５２２が、以下に示すように表１〜３に一覧表示されているファンクションブロックプリミティブを含む。

抽象５３０の定義使用レベルでは、構成アーキテクチャ５００は、定義５３２および使用状況を含む。定義５３２および使用状況は、組み合わされて、ファンクションブロック、制御モジュール、装置モジュール、リンクおよび属性を含むオブジェクト用のアルゴリズムおよびインタフェースを定義する。定義５３２は、ファンクションブロック、モジュール、リンクおよび属性用のアルゴリズムおよびインタフェースを定義する。使用状況とは、別の定義内でのある定義の使用状況を表す抽象の定義使用状況レベルでのオブジェクトおよびクラスである。

抽象５４０のインスタンスレベルでは、構成アーキテクチャ５００は、構成内の「タグ付き」アイテムであるインスタンスを含む。プラント領域５４２、モジュール５４４、属性５４６、およびＰＩＯブロック５４８がタグ付きインスタンスである。インスタンスは定義５３２に従って定義される。プラント領域５４２は、プロセスサイトクラス５１２の地理学上の、または論理的なセグメンテーションを表す。抽象５４０のインスタンスレベルでのすべてのオブジェクトおよびクラスは、すべてのモジュールインスタンスがプラント領域５４２との０または１つの関連付けを有するように、プラント領域レベル全体で定義されている。実行時システムでインストールされるためには、モジュールインスタンスは、モジュールが、プラント領域というこのコンテキストで「によって包含されている」または「よく見られている」として表示されることを意味する、１つの関連付けを有さなければならない。モジュールインスタンス５４４は、プラント装置の特定のオブジェクトに関連付けられているインストール可能オブジェクトである。属性インスタンス５４６とは、モジュールインスタンス５４４、プラント領域インスタンス５４２、またはそれ以外のデバイスでの可視パラメータである。属性インスタンス５４６は、入力信号、出力信号、データ記憶装置等に使用されてよい。

抽象５５０のデバイスレベルでは、構成アーキテクチャ５００は、実際のプラント内の物理的なプロセス制御装置を表す、制御装置、スマートデバイスとコンソール、およびＰＩＯブロックなどの入出力装置（Ｉ／Ｏ）５６０等のようなデバイス５５２を含む。プロセス入出力（ＰＩＯ）ブロックとは、Hart、FieldBus、および構成アーキテクチャ５００中に接続されているそれ以外の入出力装置を含む、高密度と低密度の従来の入出力装置を表す抽象である。高密度または低密度は、Ｉ／Ｏカードでのチャネル数に関係する。例えば、高密度カードには３２のチャネルがあるが、典型的には８つのチャネルが低密度カード上にある。デバイス５５２は、構成アーキテクチャ５００内でのプロセス制御装置であり、制御装置、入出力装置、コンソール等のオブジェクトを含む。入出力装置（ＩＯ）５６０は、構成アーキテクチャ５００内の物理的なプロセス入出力装置である。

スマートデバイスとは、デバイス校正、構成、診断および保守に関係するデータを含む、デバイスに関連するデジタルデータを送受するために実現されるフィールドデバイスである。典型的には、スマートデバイスは、例えば、フィールドデバイスにより測定されているプロセス値を含む多様な情報を示す標準アナログ信号を伝送するためにも適応される。スマートフィールドデバイスの例は、HART（ハイウェイアドレス指定可能リモート変換器）プロトコル、フィールドバスプロトコル、Modbusプロトコル、およびデバイスネットプロトコルに従うフィールドデバイスを含む。

システムオブジェクト間の多様な階層構造関係は、異なるユーザによって図１Ｃに図示されているプロセス制御環境１００を通してのナビゲーションを容易にするため、およびさまざまなタスクを達成するために実現される。制御階層、制御システム階層、動作階層、および物理プラント階層を含む４つの異なる階層構造関係が定義される。特定システムオブジェクトは、複数の階層構造システム内で実現されてよい。

制御階層とは、標準ＳＰ階層のサブセットであり、サイトオブジェクト、物理領域オブジェクト、装置モジュールオブジェクト、制御モジュールオブジェクトおよび制御要素オブジェクトを含む、システムオブジェクトを有している。制御階層は、制御動作を編成し、指定済みオブジェクトの範囲を定義するために使用される。ユーザは、信号タグを有している、サイトインスタンス、装置モジュール定義、制御モジュール定義、プラント領域インスタンス、装置モジュールインスタンス、制御モジュールインスタンス、表示モジュールインスタンス、およびプロセスＩ／Ｏモジュール／ブロックインスタンスに基づき、制御階層と対話する。

制御システム階層は、領域制御ネットワーク（ＡＣＮ）、プロセス制御ネットワーク（ＰＣＮ）およびその他のＩ／Ｏネットワークの規格を含む多様なネットワーク規格を使用して関連付けられている、オペレータ／構成ステーション、ホストコンピュータ、制御装置、Ｉ／Ｏ装置、スマートデバイス、ゲートウェイ等を含む。１つの実施態様においては、ＡＣＮハードウエアが、標準１０ベースＴイーサネット通信ポートを含み、ワークステーションが標準イーサネット１０ベースＴインタフェースカードとソフトウエアドライバを具備する。ユーザは、定義されているサイトインスタンス、ネットワーク定義、定義されているネットワークインスタンス、デバイス、およびファイル、カード、チャネル、制御装置、動作ステーション、およびフィールドバスセグメントなどのサブシステムに基づいて制御システム階層と対話する。

領域制御ネットワーク（ＡＣＮ）は、リモートオブジェクト通信（ＲＯＣ）レベルと低レベル通信レベルという２つのレベルでの通信機能性を含む。ＲＯＣレベルは、Programmed（プログラミング済み）アプリケーションとＡＣＮ通信システム間のインタフェースを制御する。低レベル通信は、ＴＣＰ／ＩＰソケットとのインタフェースおよび実際のメッセージの伝送をサポートする。

リモートオブジェクト通信（ＲＯＣ）とは、図１Ｃに図示されているプロセス制御環境１００内でのオブジェクトの通信をサポートしている、特に、オブジェクトが同じデバイス内に常駐しているのか、リモートデバイスに常駐しているのかに関係なく、オブジェクト間の通信をサポートしているシステム動作である。ＲＯＣ通信レベルは、要求／応答、要求に基づかない報告、イベント／警報報告を含む通信メッセージサービス、および一斉送信メッセージサービスをサポートする。

要求／応答は、それによりアプリケーションがメッセージをリモートデバイスに送信し、そのデバイスから応答を受信するサービスである。要求に基づかない報告とは、定期的に更新済みデータをリモートデバイスに送信するためのサービスである。未変更データは報告されない。イベント／警報報告は、リモートデバイスへの送達のためにイベント、警報およびそれ以外のきわめて重大な情報の伝送に使用される保証済み送達メッセージサービスである。一斉送信メッセージサービスは、通信ネットワーク上のすべてのプログラムアプリケーションデバイスにメッセージを送信するために使用される。ＲＯＣレベルは、通信サブシステムの通信方針も設定する。つまり、ＲＯＣレベルは、入信メッセージがどのように処理されるのかだけではなく、どのメッセージがいつ送られるのかを管理する担当である。通信フロー制御も、ＲＯＣ部分の責任となるだろう。

低レベル通信サポートは、デバイス接続管理、ＡＣＮ冗長性、および通信システム診断のために含まれる。デバイス接続管理は、２つのデバイス間の通信接続を確立し、その２つのデバイス間でのメッセージの伝送を管理する。ＡＣＮ冗長性は、通信リンク故障の検出を取り扱い、あるリンクから別のリンクへの切替えを制御し、ホストデバイスと接続されているリモートデバイス間の通信リンクのステータスを追跡調査する。通信サブシステム診断は、通信完全性と統計情報を追跡調査し、通信診断データに対する要求に応答する。

ＡＣＮ通信システムでのデバイス接続管理は、ＵＤＰ型とＴＣＰ型両方のデバイス接続をサポートする。ＵＤＰ接続は、デバイス間での通常リアルタイムデータ転送に使用される。ＴＣＰ接続は、ファイル転送、デバイスフラッシュ、ダウンロード等のストリームプロトコルを使用する特定アプリケーションに使用される。デバイス間の通信は、Device Connection Object(デバイス接続オブジェクト)によって管理される。デバイス接続オブジェクトは、データを伝送し、２つの通信装置間の通信リンクのステータスを維持する。

すべての通常デバイス接続メッセージトラフィックは、単一ＵＤＰ通信ポートを通して向けられる。デバイス接続オブジェクトは、デバイス通信メッセージトラフィックの管理に必要とされている待ち行列を作成することだけではなく、このＵＤＰポートに関連付けられている通信ソケットを作成することによって通信システムを起動する。デバイス接続オブジェクトは、デバイス接続通信ソケット上ですべての入信メッセージを受信し、処理のためにメッセージを適切なデバイス接続インスタンスに送る。デバイス接続オブジェクトは、デバイス接続インスタンスに、肯定応答されるのを待機しているメッセージがいつタイムアウトになるのか、いつ通信リンクチェックが期限切れになるのか、およびいつデバイス接続再同期（ｒｅｓｙｎｃｓ）がタイムアウトしたのかを通知することを含む、デバイス接続のタイミング関数を取り扱う。

ＵＤＰ型通信は、デバイス間でのリアルタイムデータの転送に使用される。リモートオブジェクト通信（ＲＯＣ）サブシステムは、宛先デバイスまでの伝送のためにメッセージをＵＤＰ Device Connection（ＵＤＰデバイス接続）に渡す。各デバイスの起動時に、メッセージバッファのプールが作成される。メッセージプールは、デバイス間で伝送されている全データに使用され、通信サブシステムが、メモリを使い尽くすのを妨げ、それ以外のタスクがメモリを使い尽くさないことを確実にし、それにより、通信サブシステムが実行するのを妨げる。通信フロー制御は、デバイス接続オブジェクトで実現される。通信バッファプールのメッセージバッファ数が所定の低レベルに達すると、すべてのリモートデバイスは、低バッファ問題が、影響を受けているデバイスで解決され、メッセージの損失を妨げるまで、メッセージの送信を禁止される。

ＴＣＰ型通信は、ファイル転送およびデバイスフラッシュダウンロードなどのストリーム型プロトコルを使用するアプリケーションに使用される。ＴＣＰ型接続は、アプリケーションのニーズの期間、確立されている一時的な接続であり、アプリケーションがいったん通信タスクを完了すると終了される。インタオペラビリティー（相互運用性）、互換性、可用性のため、ＴＣＰ／ＩＰプロトコルスタックが利用される。ＴＣＰ／ＩＰスタックは、接続指向型バイトストリームプロトコル（ＴＣＰ）およびコネクションレスメッセージ指向型プロトコル（ＵＤＰ）を供給する。デバイス接続は、要求／応答メッセージ、応答不要のデータ、およびデバイス間のイベントと警報データをサポートする。通信システムは、単一の通信故障、典型的にはケーブル障害が発生した場合に２つの利用可能な通信リンクの内の１つを通してデバイス接続を維持する。障害の検出および代替通信経路への切替えは、短期の決定的な時間スパンで明らかになる。

動作階層は、一般的には、ディスプレイ、レポート、およびその他の情報を
提供するアイテムにアクセスするために、ユーザのある特定のセット、具体的にはオペレ
ータおよび保守エンジニア向けに定義される。ユーザは、サイトインスタンス、User Gro
up（ユーザグループ）定義、プラント領域インスタンス、装置モジュールインスタンス、
制御モジュールインスタンス、ディスプレイインスタンス、およびレポートインスタンス
に基づいて動作階層と対話する。

物理プラント階層は、典型的には、オブジェクト間の物理的な関係を突き止め、プラント計測器および装置についての保守情報をナビゲーションする目的で、ユーザのある特定のセット、具体的には保守エンジニアと技術者向けに定義される。ユーザは、サイトインスタンス、保守領域インスタンス、プラント領域インスタンス、部屋インスタンス、キャビネットインスタンス、ノード／デバイスインスタンス、およびディスプレインスタンスに基づいて物理プラント階層と対話する。

複数の階層構造システム内で実現されるシステムオブジェクトは、制御サブシステム、プロセスＩ／Ｏサブシステム、制御システムハードウエアサブシステム、冗長性管理サブシステム、イベント／警報管理サブシステム、履歴サービスサブシステム、プロセスグラフィックサブシステム、診断提示サブシステム、ユーザ環境サブシステム、管理組織サブシステム、およびフィールド管理システム（ＦＭＳ）サブシステムを含む、複数のサブシステムの中に配列される。制御サブシステムは、制御モジュールおよび装置モジュールを構成、インストール、および実行するためのルーチンを含む。プロセスＩ／Ｏサブシステムは、HART、フィールドバス、従来のＩ／Ｏ、およびその他の入出力システムを含むデバイスへの統一インタフェースである。制御システムハードウエアサブシステムは、制御システムトポロジー、トポロジー内でのデバイス、およびデバイスの能力と機能を定義する。制御システムハードウエアサブシステムは、ステータスおよび診断を示すデバイスレベルの情報にアクセスするためのオブジェクトおよびデータ構造も含む。

冗長性管理サブシステムは、一次制御アプリケーションと二次制御制御アプリケーション間の冗長なコンテキストを確立し、一次制御アプリケーションと二次制御アプリケーションの間のコンテキストで切替えを管理する。冗長性管理サブシステムは、サイト情報およびデータ待ち時間情報を含む冗長なコンテキスト診断情報も監視する。ネットワーク冗長性は、２つの別個のイーサネット通信リンクまたはネットワークを使用して達成される。一次通信リンクとは、好まれている通信経路である。二次リンクは、一次リンク故障時にだけ使用される。通信切替えは、デバイス単位で実行される。例えば、デバイスＡがデバイスＢとＣと通信しており、デバイスＣへの一次リンクが故障すると、デバイスＡは、一次リンク上でデバイスＢとの通信し続けるが、二次リンクをデバイスＣとの通信に切り替える。各イーサネットリンクは、ＩＰアドレスとサブネットマスクの専用セットを有している、別個の専用ネットワークである。

デバイス接続オブジェクトは、二次リンクにいつ切り替えるのか、および一次リンクにいつ戻すのかを制御すること含む、冗長通信を管理する。プロセス制御システムの各デバイスは、他の通信が発生していないときにリンクテストメッセージを定期的に送信することにより、リモートデバイスへの現在の全リンクの通信ステータスを追跡調査し、各デバイスへの通信リンクのステータスをチェックする。冗長性切り替えは、デバイス接続に基づいて実行される。

イベント／警報管理サブシステムは、重要なシステム状態、肯定応答および優先順位計算の通知を構成し、監視し、供給する。履歴サービスサブシステムは、プロセスイベント情報を記憶し、検索する。プロセスグラフィックサブシステムは、表示および定義済みシステムアーキテクチャへのオペレータインターフェイスのためにユーザ定義ビューを供給する。診断提示サブシステムは、通常はユーザの要求で診断情報のディスプレイを供給する。ユーザ環境サブシステムは、ユーザインタフェースを供給し、ユーザが図１Ｃに図示されているプロセス制御環境の動作を制御するためのコマンドを入力できるようにする。管理組織サブシステムは、サイト、領域、プリミティブ、ユーザライブラリへのアクセス、および定義済みオブジェクトとインスタンスのロケーションの指定を含むプロセス制御環境１００の組織的な構造を設定する。ＦＭＳは、HARTデバイスおよびフィールドバスデバイスの構成、インストール、および監視のためのユーザインタフェース、ビュー、および組織構造を供給する。

フィールドバスデバイスは、デバイス機能をメインまたは集中化デジタル制御システムから制御するという、さらに長く使用され、さらに型にはまったアプローチとは対照的に、プロセス内でのプロセスの局所化されている制御を実現する。Fieldbusデバイスは、フィールドバスデバイス内のフィールドデバイスと密接に関連付けられている、小型局所化制御装置／マルチプレクサ１１０を含むことにより局所化制御を達成する。フィールドバスの小型局所化制御装置は、フィールドバスデバイス内のフィールドデバイス上で動作し、フィールドバスデバイスに接続されているそれ以外のスマートフィールドデバイスでも動作する、標準化した制御機能または制御ブロックを実現する。

したがって、プロセス制御環境１００は、デバイス、特にFieldbusデバイス間での通信および制御が、Fieldbus型制御動作がユーザにトランスペアレントになるように実行されるように、フィールドバスＨ１規格、Profibus規格、ＣＡＮ規格およびそれ以外のバスをベースにしたアーキテクチャ規格などのスマートフィールドデバイス規格を実現する。

プロセス制御環境１００は、フィールドバスデバイスとHARTデバイスなどのスマートデバイス、および従来の非スマートデバイスを含む、実質的には無制限の数および型のフィールドデバイスへの接続を可能にする。多様な数と型のデバイスの制御および通信の動作は、同時に並行して実行されるのが有利である。

プロセス制御環境１００は、スマート型制御が、HARTデバイス１３４と従来のデバイス１３６などの非スマート型デバイスに関して達成されるように、フィールドバスＨ１規格などの標準フィールドバスプロトコルによって定義されているファンクションブロックまたは制御関数の標準セットを実現し、実行する。さらに、プロセス制御環境１００によって、スマートデバイスは、ファンクションブロックと制御関数の標準セットを実現できるようになる。有利なことに、プロセス制御環境１００は、まるですべての接続されているデバイスがスマートデバイスであるかのように、総体的なストラテジーを実現する。この実装は、部分的には、制御構造に根本的なビルディングブロックとしてファンクションブロックを使用することにより達成される。これらのファンクションブロックは、すべての型のデバイス用の制御構造を作成するために定義される。ファンクションブロックの根本的なビルディングブロックの使用は、図６、図７、図８、および図９に説明されている。

プロセス制御環境１００は、コントロールストラテジー（control strategy）の特定部分をスマートデバイスおよび非スマートデバイスの中にダウンロードまたはインストールすることによって、ファンクションブロックおよび制御モジュールの定義を通して総体的な、ユーザによって作成されたコントロールストラテジーを実現する。それ以降、スマートデバイスは、他の制御システム動作とは無関係に、総体的なストラテジーのダウンロードされた部分を自動的に実行する。例えば、デバイスの中にダウンロードされた、またはインストールされたコントロールストラテジーの部分は、制御装置／マルチプレクサ１１０およびワークステーションの制御動作とは無関係に、およびそれと並行して動作するが、他の制御動作は、スマートデバイスを管理し、コントロールストラテジーのそれ以外の部分を実現する。事実上、プロセス制御環境１００は、スマートデバイス内で制御装置／マルチプレクサ１１０を使用して、コントロールストラテジーを実現する。

図５に図示されている関数５２２のファンクションブロックを定義するブロック図の例が、図６に示されている。具体的には、図６は、プリミティブオブジェクトだけを包含するように定義されている「要素別処理」ファンクションブロック定義６００を描いている。要素別処理ファンクションブロック定義６００は、合計関数を定義し、「＋」プリミティブ６１０、プリミティブ６１０に適用されている第１パラメータ６１４である第１入力属性６１２、およびプリミティブ６１０に適用されている第２パラメータ６２４である第２入力属性６２２を含む。プリミティブ６１０は、出力属性６３０として供給される結果を作り出す。この例では、要素別処理ファンクションブロック定義６００は、作成され、ＳＵＭと名前が付けられるブロック定義である。

図５に図示されている関数５２２のファンクションブロックを定義しているブロック図の第２の例は、図７に示されている。具体的には、図７は、１つまたは複数の要素別処理ファンクションブロック６００、およびオプションで１つまたは複数のプリミティブオブジェクトを包含するように定義される「複合」ファンクションブロック定義７００を描いている。複合ファンクションブロック定義７００は、複合合計関数を定義し、そのそれぞれが、図６に示されているＳＵＭ要素別処理ファンクションブロック６００と同じである、第１ＳＵＭ要素別処理ファンクションブロック７１０と第２ＳＵＭ要素別処理ファンクションブロック７１２を含む。複合ファンクションブロック７００は、それぞれ、第１ＳＵＭ要素別処理ファンクションブロック７１０に適用されている第１パラメータ７２４と第２パラメータ７２６である、第１入力属性７２０および第２入力属性７２２を有している。第１要素別処理ファンクションブロック７１０は、第２ＳＵＭ要素別処理ファンクションブロック７１２に第１パラメータ７３０として適用される結果を生じさせる。複合ファンクションブロック７００は、第２ＳＵＭ要素別処理ファンクションブロック７１２に適用されている第２パラメータ７３２である、第３入力属性７２８を有している。第２ＳＵＭ要素別処理ファンクションブロック７１２は、出力属性７３４として供給される結果を生じさせる。この例では、複合ファンクションブロック定義７００は、作成され、ＳＵＭ３と名付けられているブロック定義である。

図４に図示されている制御モジュール４４０の制御モジュールを定義しているブロック定義の例が、図８に示されている。具体的には、図８は、定義されており、多様な入力属性８１０、要素別処理ファンクションブロック８２０、第１ＳＵＭ３複合ファンクションブロック８３０、および第２ＳＵＭ３複合ファンクションブロック８３２を包含する、制御モジュール定義８００を描いている。例示的な制御モジュール４４０は、その内の３つが第１ＳＵＭ３複合ファンクションブロック８３０に適用されている、５つの各要素別処理ファンクションブロック８２０に接続されている５つの入力属性８１０を含む。第１ＳＵＭ３複合ファンクションブロック８３０は、残りの２つの要素別処理ファンクションブロック８２０によって供給されているパラメータと組み合わせて第２ＳＵＭ３複合ファンクションブロック８３２へのパラメータとして供給される結果を生じさせる。第２ＳＵＭ３複合ファンクションブロック８３２は、出力属性８４０として供給される結果を生じさせる。この例では、制御モジュール８００は、作成され、ＣＭＩと名前が付けられている制御モジュール定義である。

図５に図示されているモジュールインスタンス５４４、具体的には制御モジュールインスタンスのモジュールインスタンスを定義しているブロック図の例が、図９に図示されている。制御モジュールインスタンス９１０と９２０は、各制御モジュールインスタンス９１０と９２０が、図８に図示されている５つの入力属性８１０に一致する、それぞれ５つの入力属性９１２と９２２を含むように、ＣＭ１制御モジュール定義に従って作成される。各制御モジュールインスタンス９１０と９２０は、図８に図示されている出力属性８４０に一致する、それぞれ１つの出力属性９１４と９２４も含む。この例では、制御モジュールインスタンス９１０と９２０は、作成され、それぞれＣＡＬＣ１とＣＡＬＣ２とタグが付けられている制御モジュールインスタンスである。

システムユーザは、定義エディタを使用して、ＳＵＭ３要素別処理ファンクションブロック定義、ＳＵＭ３複合ファンクションブロック定義、およびＣＭ１制御モジュール定義などの定義を作成し、名前を付ける。それから、モジュールエディタを使用し、システムユーザは、インスタンスを作成し、ＣＡＬＣ１とＣＡＬＣ２制御モジュールインスタンスなどのタグを付ける。

図１０を参照すると、フローチャートは、実行時の制御モジュール実行の一例を示している。実行時プログラムは、スケジューラルーチンを含む。スケジューラルーチンは、コンピューティング技術でよく知られている。スケジューラルーチンは、複合制御モジュール、例えば図８に図示されているタグＣＭ１付きの複合制御モジュール４４０の実行１０１０を要求する。ＣＭ１複合制御モジュール４４０は、入力属性８１０の転送を始動し、あらゆる関連付けられているリンク、つまり属性関連付けを転送させる（ステップ１０１４）。データベース定義は、典型的には、「関連付け」を参照するが、実行時定義は「リンク」に関係する。ステップ１０１６から１０５６では、ＣＭ１複合制御モジュール４４０が各要素別処理ファンクションブロック８２０、第１ＳＵＭ３複合ファンクションブロック８３０および第２ＳＵＭ３複合ファンクションブロック８３２に、代わりに実行するように要求する。

具体的には、ステップ１０１６では、ＣＭ１複合制御モジュール４４０が、各要素別処ファンクションブロック理８２０に実行するように要求する。要素別処理ファンクションブロック８２０は、入力属性、例えば図６に図示されている第１入力属性６１２の転送１０１８を始動する。要素別処理ファンクションブロック８２０の入力属性は、ステップ１０１４で転送されているリンクからの値のロードを要求する（ステップ１０２０）。リンクは、ソース属性から宛先属性へ値をコピーする（ステップ１０２２）。要素別処理ファンクションブロック８２０は、ブロックアルゴリズム１０２４を実行する。ブロックアルゴリズムの実行完了時、要素別処理ファンクションブロック８２０は、出力属性１０２６、例えば、図６に図示されている出力属性６３０の転送を始動する。

ステップ１０２８では、ＣＭ１複合制御モジュール４４０が、第１ＳＵＭ３複合ファンクションブロック８３０に実行するように要求する。第１ＳＵＭ３複合ファンクションブロック８３０は、入力属性、例えば図７に図示されている入力属性７２０、７２２、および７２８要素別処理ファンクションブロック８２０からの転送１０３０を始動する。ステップ１０３２では、第１ＳＵＭ３複合ファンクションブロック８３０は、内部ファンクションブロック、例えば、図７に図示されている第１ＳＵＭ要素別処理ファンクションブロック７１０と第２ＳＵＭ要素別処理ファンクションブロック７１２に、代わりに実行するように要求する。第１ＳＵＭ要素別処理ファンクションブロック７１０は、ステップ１０３４で、入力属性を読み取り、ブロックアルゴリズムを実行し、出力属性を設定する。第２ＳＵＭ要素別処理ファンクションブロック７１２は、ステップ１０３６で、入力属性を読み取り、ブロック図を実行し、出力属性を設定する。第１ＳＵＭ３複合ファンクションブロック８３０は、ステップ１０３８で出力属性の転送を始動する。第１ＳＵＭ３複合ファンクションブロック８３０の出力属性は、ステップ１０４０で、関連付けられているリンクに、出力属性から値をコピーするように要求する。

ステップ１０４２では、ＣＭ１複合制御モジュール４４０が、第２ＳＵＭ３複合ファンクションブロック８３２に実行するように要求する。第２ＳＵＭ３複合ファンクションブロック８３２は、第１ＳＵＭ３複合ファンクションブロック８３０出力属性に接続されているリンクから入力属性の転送１０４４を始動する。ステップ１０４６においては、第２ＳＵＭ３複合ファンクションブロック８３２が、内部ファンクションブロック、例えば、図７に図示されている第１ＳＵＭ要素別処理ファンクションブロック７１０と第２ＳＵＭ要素別処理ファンクションブロック７１２に、代わりに実行するように要求する。第１ＳＵＭ要素別処理ファンクションブロック７１０は、ステップ１０４８で、入力属性を読み取り、ブロックアルゴリズムを実行し、出力属性を設定する。第２ＳＵＭ要素別処理ファンクションブロック７１２は、ステップ１０５０で、入力属性を読み取り、ブロックアルゴリズムを実行し、出力属性を設定する。第２ＳＵＭ３複合ファンクションブロック８３２は、ステップ１０５２で出力属性の転送を始動する。第２ＳＵＭ３複合ファンクションブロック８３２の出力属性は、ステップ１０５４で、関連付けられているリンクに、出力属性からの値をコピーするように要求する。

ステップ１０５６では、ＣＭ１複合制御モジュール４４０が、出力属性の転送を始動し、出力属性８４０が、第２ＳＵＭ３複合ファンクションブロック８３２からのリンクに、第２ＳＵＭ３複合ファンクションブロック８３２出力属性の値をコピーするように要求する。いくつかの実施態様においては、出力ファンクションブロックは、出力値をユーザ構成ＰＩＯブロック属性（図示されていない）に出力する。このようにして、ＰＩＯ属性は、出力ファンクションブロックが出力値をＰＩＯブロック属性に出力する間に、ファンクションブロックによって「抽出される」。同様にして、入力ファンクションブロックは、ＰＩＯブロック属性から入力属性値を抽出する。

ユーザは、制御モジュールを構成し、コントロールストラテジーを決定するファンクションブロックを指定することにより、モジュールコントロールストラテジーを定義する。ユーザは、ファンクションブロックを追加、修正および削除し、ファンクションブロックに関連付けられているパラメータを構成し、新規属性に対するビューを作成することによって、モジュールコントロールストラテジーを修正するか、デバッグする。

ファンクションブロックおよび制御モジュールを定義することによって、ユーザ定義コントロールストラテジー、アプリケーションプログラムまたは診断プログラムは、モジュールとして識別されている相互接続済み制御オブジェクトの層のセットとして表される。コントロールストラテジーの層は、ユーザによって指定されるように相互接続されているモジュールのセットを含む。モジュールは、典型的には、特定の関数、および情報をユーザに表示するために使用される表示構成要素を実行するためのアルゴリズムを含む。モジュールは、オプションで、他のモジュールに接続するための入力接続と出力接続のセットを含むように表記される。モジュールは、指定されている関数を実行し、指定されている入力接続と出力接続を介して他のモジュールに接続されている「ブラックボックス」と考えてよい。

図１１を参照すると、表示画面が、制御構造のさらに高い層でのモジュールまたはアプリケーションプログラムＬＯＯＰＳＩＭの一例を示すものとして役立つ。ＬＯＯＰＳＩＭ１０６０のアプリケーションプログラムの示されている層は、ＡＩ１と呼ばれている入力属性（ＡＩＮ）モジュール１０６２、不感時間モジュール１０６４、比例積分微分（ＰＩＤ）制御モジュール１０６６、出力属性（ＡＯＵＴ）モジュール１０６８、およびシミュレーションモジュール１０７０を含む。実例となるモジュールのそれぞれは、回線を介して他のモジュールに接続されている、名前が付けられている入力接続および出力接続を含む。モジュールのセット、モジュールのセットの入力接続および出力接続、およびモジュールの間の相互接続が、ＬＯＯＰＳＩＭ１０６０アプリケーションの動作を定義する。

最低レベルでは、モジュールは、相互接続されているファンクションブロックのセットである。さらに高いレベルでは、モジュールでは、代わりにサブモジュールの追加セットを含んでよい相互接続されているサブモジュールのセットである。例えば、ＰＩＤ制御モジュール１０６６は、典型的には、ＰＩＤ機能性に含まれているさまざまな関数を実行する、相互接続されているサブモジュールのセットである。ＰＩＤモジュール１０６６の入力接続および出力接続は、ＰＩＤモジュール１０６６の次に低い層内の１つまたは複数のサブモジュールの入力接続および出力接続である。ＰＩＤモジュール１０６６のサブモジュールは、オプションで、サブモジュール間での相互接続を定義するほど十分なそれ以外の入力接続および出力接続を含む。

任意のモジュールレベルでのアプリケーション、モジュールまたはサブモジュールは、わずかに異なる関数を実行するため、あるいは異なるやり方で同じ関数を実行するためにユーザによりオプションで修正される。したがって、ユーザは、オプションでモジュールを修正し、それにより、制御構造を希望されるように修正する。具体的には、ユーザは、オプションで、モジュールに入力接続と出力接続を追加し、モジュールの入力接続および出力接続をさらに高いレベルのモジュールまで拡大し、そのため多様なアプリケーション用のモジュールをカスタマイズする。例えば、入力接続および出力接続をするユーザモジュール１０６６は、ＰＩＤモジュール１０６６に対する入力接続および出力接続として表示される。

プロセス制御環境は、フィールドブロックス（Field Blocks）、シーケンシャルファンクションチャート（ＳＦＣ）、はしご形論理およびストラクチャードテキストなどのＩＥＣ−１１３１標準言語を含む複数の制御言語で編集動作を供給することにより、制御構造の定義および修正を容易にする。したがって、異なった制御背景のさまざまな種類のユーザがさまざまな言語を使用し、同じアプリケーションまたは異なったアプリケーションを実現するためのさまざまなモジュールを書き込む。

制御モジュールは、複数の有利な特性を有するように指定される。属性への直接アクセスを可能にする制御モジュールもある。例えば、直接（最大性能）通信をサポートする「重い（heavy）」属性と呼ばれている属性がある。直接通信は、例えば、ファンクションブロックおよびControl Modules（制御モジュール）を接続するため、イベント／警報検出および高性能傾斜（trending）をサポートするために有利に使用される。制御モジュールの定義時に自動的に作成され、ユーザが制御モジュールの属性として露呈されるパラメータを促進または強制するオプションを持つ、いくつかの属性がある。パラメータを包含しているが、この性能を供給する上で生じるオーバヘッドを保証しない、属性の直接的な通信性能が制御モジュール、装置モジュール、ＰＩＯブロック、またはデバイスなどのモジュールを通してアクセスできるようになるパラメータもある。これらのパラメータは、制御システムチューニング、デバッギング、および保守に関係する情報を供給するために有利にアクセスされる。いくつかの実施態様においては、これらのパラメータは、コンテナ内の属性、呼出し可能サービス、およびサブコンポーネントを明らかにするためにタグ付きコンテナによって提供されているサービスを使用する、汎用パラメータブラウザアプリケーションによってアクセスされる。

図１２を参照すると、ブロック図が、制御サブシステムの動作を通してＰＩＯデバイスの中にプロセスＩ／Ｏ属性ブロックをインストールするためのオブジェクト指向方法を説明している。定義済みオブジェクトのブロック１１１０は、サイトオブジェクト１１１２、制御装置デバイス１１１４、制御装置Ｉ／Ｏサブシステム１１１６、ＰＩＯインタフェースデバイス１１１８、およびＰＩＯデバイス１１２０を含む。ＰＩＯデバイスのインストールに先立って、制御装置Ｉ／Ｏサブシステム１１１６が、予め作成される。ＰＩＯデバイス１１２０も、インストールまたはダウンロードのどちらかにより以前作成されている。定義済みオブジェクトのブロック１１１０は、詳細ポイント１１２２をブロック定義１１２４のリストに向け、作成ブロック１１２８の動作を命令する作成ポインタ１１２６によって作成される特定の型のオブジェクトを指定する。ブロック定義１１２４は、配線によるインストールとして、または過去のインストールによって、ＰＩＯ入力属性（ＡＩＮ）ブロック定義を含む。指定されているオブジェクトの属性は、エディタ１１３０の動作を通してユーザによって設定される。ＰＩＯデバイスのインストールの前に、入力属性（ＡＩＮ）ブロック１１３２は存在しない。

ユーザは、ＡＩＮブロック１１３２をインストールする前に、ＰＩＯデバイス１１２０
を作成し、それからエディタ１１３０を使用して、ＡＩＮブロック属性の初期値をセット
アップする。ユーザは、ビューパラメータ取得のための期間も設定する。ＡＩＮブロック
１１３２が保存されてから、インストールされる。

図１３を参照すると、ブロック図は、制御モジュール入力属性をプロセスＩ／Ｏ属性にリンクするためのオブジェクト指向方法を説明している。制御モジュール入力属性をＰＩＯ属性にリンクする前に、ＰＩＯブロックＡＩＮ１２２０は過去にインストールされ、制御モジュール１２１０もインストールされる。ユーザは、制御モジュール１２１０のＰＩＯＩＮ属性１２１２が属性入力プロセス変数ＰＶ１２１４に接続されていることを指定し、リンクが行われることを要求する。制御モジュールがＰＩＯＩＮ属性を発見して対応する属性インデックスを返し、プラント領域にＰＩＯＡＩＮを配置し、プロセス変数ＰＶ属性を発見して対応する属性インデックスを返し、実行時リンカー（linker）１２１６にプロセス変数（ＰＶ）１２１４でのソースおよびＰＩＯＩＮ属性１２１２とのリンクを作成するように指示し、リンクを作成し、リンク１２１６を接続すると、リンク１２１６が行われる。ダウンロードの最後で、リンクは連結オブジェクトにより分離される（resolved）。

図１４を参照すると、ブロック図が、制御モジュール出力属性（ＡＯＵＴ）１３１２をＰＩＯ出力属性（ＰＩＯＡＯＵＴ）１３２０にリンクするためのオブジェクト指向方法を示している。制御モジュール１３１０が過去にインストールされ、制御モジュール出力属性（ＡＯＵＴ）１３１２が制御モジュール１３１０内にインストールされる。ユーザは、制御モジュール出力属性（ＡＯＵＴ）１３１２が、ＰＩＯ出力属性（ＰＩＯＡＯＵＴ）１３２０に接続されることを指定する。制御モジュール１３１０の実行時実装がメッセージに送信され、接続を形成し、制御モジュール１３１０がＡＯＵＴ属性を発見し、ＰＩＯＡＯＵＴ属性１３２０のロケーションを要求し、リンク１３２２を作成し、ＡＯＵＴ属性１３１２およびＰＩＯＡＯＵＴ属性１３２０をリンク１３２２に接続すると、リンクが行われる。

図１５を参照すると、ブロック図が、包含されているＰＩＯ属性の値を読み取るためのオブジェクト指向方法を示す。ＰＩＯブロック１４１０は、過去にインストールされ、出力属性（ＡＯＵＴ）１４１２がＰＩＯブロック１４１０内で過去にインストールされている。ユーザ、例えばエンジニアは、すべての属性値が表示されているブロックの詳細なビューを要求する。詳細なディスプレイは、ＰＩＯブロック１４１０と関連付けられている、ビュー定義とも呼ばれる表示グループの１つまたは複数のセットを含む。ＡＯＵＴブロックの属性名および値は、プロキシクライアントルーチンに、ビューにアクセスするように要求するアプリケーションプログラムによって提示され、ＡＯＵＴプロキシクライアントが戻りビュー定義を設定し、属性プロキシオブジェクトを作成し、アプリケーションプログラムがＡＯＵＴプロキシクライアントに許可されている特権で名前が付けられている属性の値を読み出すように要求する。アプリケーションプログラムはデータをフォーマットし、表示する。表示グループパラメータは、Ｉ／Ｏブロック定義の一部であり、したがって構成可能ではない。表示グループは、属性のために定義される。表示グループおよびビューグループがブロックに関連付けられている非リンクＰＩＯ属性の更新を制御するため、ＰＩＯブロックがリンクされていない間に、情報は有利に更新される。

図１Ｃに図示されているプロセス制御環境１００は、制御構造のための根本的なビルデ
ィングブロックとしてファンクションブロックを使用することによってだけではなく、フィールドバスおよび非フィールドバスデバイスを同じように処理する入出力アーキテクチャを実現することによって、あたかもすべての接続されているデバイスがフィールドバスデバイスであるかのように、総体的なストラテジーを実現する。入出力アーキテクチャの根本的な特徴は、フィールドバス信号および非フィールドバス信号を含むすべてのＩ／Ｏ信号にユーザ構成可能名を与える計測器信号タグ（ＩＳＴ）に基づいている。

ユーザの観点からは、ＩＳＴはユーザ定義名を単一型に、Ｉ／Ｏサブシステム内の特定の信号に、属性を含む信号経路に、および信号特性設定値のセットに結合する。

ＩＳＴは、他のシステムオブジェクトのようにインストールされない。代わりに、ＩＳＴタグに固有な信号特性が、Ｉ／Ｏカードインストール時に利用できるようになる、Ｉ／ＯポートおよびＩ／Ｏデバイス特性と結合される。ＩＳＴ、Ｉ／ＯポートおよびＩ／Ｏデバイス特性の組み合わせは、実行時システムでＰＩＯファンクションブロックを作成するための情報を供給する。ＩＳＴからの信号経路は、モジュールのインストール中にＩ／Ｏファンクションブロックを定義するスクリプト内に含まれる。

プロセス制御環境１００全体で通信するため、Ｉ／Ｏ型ファンクションブロックは、Ｉ／Ｏ基準定義を使用する。ＩＳＴは、Ｉ／Ｏ基準の仕様を満たす。英国のメジャーメントテクノロジー社（Measurement Technologies Limited）により供給されるＭＴＬデバイスなどの従来のＩ／Ｏデバイスは、チャネルごとにＩＳＴを有している。HartデバイスおよびフィールドバスＩ／Ｏデバイスは、ポート上、またはフィールドデバイスでの別個の「Ｉ／Ｏ信号」ごとにＩＳＴを含んでよい。ＩＳＴ名は、システム全体の範囲を有し、モジュール、デバイスおよびエリア（領域）の名称空間を共用する。大型システムにおいては、ＩＳＴは、典型的には、計装図面上の測定器信号名に一致する。小型システムでは、公式計測器図面は存在しないことがあるため、明白なＩＳＴ名は推論されない。典型的には、任意のＩＳＴ名が回避されるように、カードが、制御装置ノード、Ｉ／Ｏサブシステム、カードおよびポートを表すデバイス階層に基づいて構成されると、ＩＳＴが自動的に生成される。典型的には大部分のＩＳＴは、新規Ｉ／Ｏカードが定義されると自動的に作成される。複数−単一Ｉ／Ｏデバイスの場合、ＩＳＴは、単一の「一次信号」のためだけに自動的に作成される。自動ＩＳＴ作成に加えて、ユーザは、ポートまたはデバイスが選択されている、エクスプローラNode/IOsubsys/Port/Deviceツリーから利用できる「Assign...」メニューを使用して、あるいはエクスプローラＩＳＴツリーから利用できる「New...」メニューを使用して、ＩＳＴを作成してもよい。

ＩＳＴは、Ｉ／Ｏ信号にアクセスするＩ／Ｏ信号とＩ／Ｏファンクションブロックの間での互換性を確実にするために「信号型」特性を持っている。信号型は、ＡＩＮ、ＡＯＵＴ、ＤＩＮ、ＤＯＵＴ、ＰＣＩＮ、ＰＣＯＵＴの内の１つである。ＩＳＴは、信号型に特定の「信号関係」属性のセット（例えば、ＤＯＵＴなどのＡＩＮ、MOMENTARYまたはLATCHEDの場合、ＥＵ０とＥＵ１００）を有している。同じ信号型のすべての信号ソースが、同じ「信号属性」のセットを有している。Ｉ／Ｏサブシステムオブジェクトのすべての他の特性は、カード、ポート、またはデバイスの属性に保持される。

完全に構成されているＩＳＴは、Ｉ／Ｏシステム、例えば「ＣＯＮ１／ＩＯ１／Ｓ０１／Ｃ０１／ＦＩＥＬＤ＿ＶＡＬ」内の対応する信号への完全に修飾されている経路を有している。ＩＳＴは、Ｉ／Ｏ構造詳細が完全に定義される前にモジュール構成が完了されるように、定義済み経路を定義しないで作成してよい。定義済み経路のないＩＳＴを使用するＩ／Ｏファンクションブロックのあるモジュールは、構成、インストールされてよいが、実行時システムは、Ｉ／Ｏファンクションブロック上で見失われているＩＳＴの見失われているＩ／Ｏ経路に適切に対処しなければならない。信号ソースはわずかＩＳＴしか有していない。同じ経路のある複数のＩＳＴを構成しようとすると拒絶される。

ユーザは、ＩＳＴを削除し、それによって関連付けられている信号特性を削除し、おそらくいくつかの分離不可能なＩＳＴ基準をＩ／Ｏファンクションブロックに残すことによってＩＳＴを削除してよい。削除されたＩＳＴは、関連付けられているＩＳＴを示さないエクスプローラツリーでのPort/Device上のＩＳＴの通常のディスプレイのあるカード／ポート／デバイス特性に影響を及ぼさない。

Ｉ／Ｏインタフェースファンクションブロックは、少なくとも１つのＩＳＴ−Reference特性を有している。ＩＳＴ−Reference特性は、ファンクションブロックがＩＳＴに接続していないことを示すためにブランクのままにされるか、あるいは有効なＩＳＴ名で指定される。Ｉ／ＯファンクションブロックのＩＳＴ−Reference特性は、まったく１つのＩＳＴ信号型と互換性がある。例えば、ＡＩファンクションブロックのＩＳＴ−Referenceは、信号型「ＡＩＮ」だけのあるＩＳｔを有している。複数のＩ／Ｏファンクションブロックは同じＩＳＴ信号型と互換性がある。

フィールドバスＩ／Ｏファンクションブロック定義との互換性のため、フィールドバスＩ／Ｏファンクションブロックは、ＩＳＴの単一特性のいくつかと重複するＸＤ＿ＳＣＡＬＥ，ＯＵＴ＿ＳＣＡＬＥなどの属性を有している。有効なＩＳＴ−Referenceが作成されると、これらの重複されているファンクションブロック属性の構成済み値は、Run-timeシステムで無視され、ＩＳＴからの対応する特性が代わりに使用される。フィールドバスＩ／Ｏファンクションブロックを構成するエンジニアは、ＩＳＴ基準が適所にあるときに無視されている属性の表示を使用する。このような表示は、典型的には、値がＩＳＴからコピーされている、グレー表示されている編集不可テキストとして表示装置で提示される。Ｉ／Ｏファンクションブロックは、典型的にはダウンロードされ、迅速に無効にされる無視されている属性の非公開設定値を保持する。ＩＳＴ−Referenceが削除されると、これらの属性の設定値がユーティリティを保持する。

Ｉ／Ｏカード、ポート及びデバイスは、エクスプローラ（登録商標）またはModule Definition Editorのどちらかである、ユーザインタフェースを動作しているユーザによって構成の中に組み込まれる。従来のＩ／Ｏカード上のチャネルは、従来のＩ／Ｏ用の特定ケースの専門用語が回避されるように、「ポート」と呼ばれ、Ｉ／Ｏポートとして処理される。また、ユーザインタフェースは、ユーザが、Ｉ／Ｏカード、ポート又はデバイスを削除できるようにする。例えば、８−チャネルＭＴＬＡＩ、８−チャネルＭＴＬＡＯ、８−チャネルＭＴＬＤＩ、８−チャネルＭＴＬＤＯ、４−チャネルＭＴＬ熱伝対／ＲＴＤ、８チャネルハート（HART）入力、８−チャネルハート（HART）出力、および４−chanSolenoidを含む複数のＩ／Ｏカード型がサポートされている。Ｉ／Ｏカード型は、同じＩ／Ｏカード上でのＩ／Ｏポート型の組み合わせを有している。Ｉ／Ｏカードの削除は、すべての従属ポートを削除する。Ｉ／Ｏポートの削除は、すべての従属デバイスを削除する。Ｉ／ＯポートまたはＩ／Ｏデバイスの削除は、関係する計測器信号タグ（ＩＳＴ）を削除しないが、関連付けられているＩ／Ｏ信号へのＩＳＴ経路の経路はもはや実施可能ではない。同じ経路を有している別のＩ／ＯポートまたはＩ／Ｏデバイスが作成されると、信号型が互換性がある限り、ＩＳＴは自動的にＩ／ＯポートまたはＩ／Ｏデバイスへ再結合する。

ユーザは、Subsystemで定義されているＩ／Ｏカードをインストールまたはインストールし直す、Ｉ／Ｏサブシステムのインストールを始動する。ユーザは、カード特性およびＩ／ＯポートおよびＩ／Ｏデバイスのすべての特性をインストールする、単一Ｉ／Ｏカードのインストールを始動することができる。

エクスプローラ（登録商標）およびModule Definition Editorは、現在の信号値、ステータス、およびＩ／Ｏサブシステム内でAttributesとして直接アドレス指定することができる選択されている特性にアクセスすることによってＩ／Ｏサブシステムを構成する。ユーザは、各カード、ポート、デバイスおよび信号値、およびデバイス階層属性経路アドレス指定（例えば、「ＣＯＮ１／ＩＯＩ１／Ｃ０１／Ｐ０１／ＦＩＥＬＤ＿ＶＡＬ」）を使用するステータスにアクセスすることによって、カード、ポート、デバイス、および信号値とステータスを示すグラフィックを表示する。

Ｉ／Ｏサブシステム属性は、デバイス間での通信でアドレス指定するために物理デバイス経路（例えば、ＣＯＮ１／ＩＯ１／Ｃ０１／Ｐ０１／ＦＩＥＬＤ＿ＶＡＬ）を使用して通信される。Ｉ／Ｏサブシステム属性の通信は、表示のために図１Ｃに図示されるように、制御装置／マルチプレクサ１１０からワークステーション１０２、１０４、１０６へ、および仮想Ｉ／Ｏ取扱いのために第１から第２制御装置／マルチプレクサに属性を伝送するために有利に使用される。

図１６を参照すると、ブロック図は、計測器信号タグ（ＩＳＴ）の情報の構成を示している。システムＩＳＴテーブル１５１０は、経路情報およびシステムオブジェクトへのポインタを含む、ＩＳＴに関係する情報を記載している。第１ポインタ１５１２は、属性信号テーブル１５２０を指す信号型を指定する。第２ポインタ１５１４は、属性信号テーブル１５２０でのエントリを指定する。

有利にアドレス指定するデバイス階層属性を使用して情報にアクセスすることにより、制御モジュール作業が完了する前にシステム統合チェックアウトのために、システム診断表示を設計、構築することができる。デバイス階層属性アドレス指定は、モジュールからのＩ／Ｏ信号の直接アドレス指定、Ｉ／Ｏファンクションブロックの使用のバイパス、およびＩ／Ｏファンクションブロック動作の回避もサポートする。一般的には、Ｉ／Ｏカード、Ｉ／ＯポートおよびＩ／Ｏデバイスの識別子は、スロット位置情報等に従って自動的に定義される。

図１７を参照すると、フローチャートが、制御装置／マルチプレクサ１１０をＩＰアドレス、ノード名、および制御装置／マルチプレクサ１１０のフラッシュＲＯＭに記憶されていないその他の起動情報のセットに割り当てる動作を含む、プロセス制御環境１００内でのネットワーク全体で制御システムをブートストラップロードする方法を説明している。インターネットプロトコル（ＩＰ）アドレスを、その初期ブートアップ時に制御装置に割り当てるためのプロセス１６００は、Ｂｏｏｔサーバ、Windows NTTMワークステーションのＭＡＣアドレスを制御装置／マルチプレクサ名に関連付けるステップ１６１０を含む。ＭＡＣアドレスだけが、制御装置／マルチプレクサアイデンティティを指定する。ステップ１６１２では、制御装置／マルチプレクサの名前には、属性デバイスＩＤ、および制御装置／マルチプレクサに接続されているケーブルによって決定されるＡＣＮリンク番号とＰＣＮネットワーク番号が割り当てられる。ステップ１６１４では、デバイスのＩＰアドレスがデバイスＩＤ、ＡＣＮリンク番号およびＰＣＮネットワーク番号から計算される。ステップ１６１６では、ノードをブートするために確保されているデフォルトの一次ＩＰアドレスと二次ＩＰアドレスを指定し、ＵＤＰユーザデータの制御装置／マルチプレクサＭＡＣアドレスを含むＵＤＰデータグラムが、一次インタフェース上のソースアドレスのためにデフォルトの一次ＩＰアドレスを使用する特定ＵＤＰ確保ブートポートに一斉送信される。ステップ１６１８では、ブートサーバがＭＡＣアドレスを割り当てられている名前とＩＰアドレスに照会し、割り当てられている名前とＩＰアドレスを、ＭＡＣアドレスのエコーとともに、ＵＤＰブートポートに一斉送信する。一斉送信することにより、ルーティングまたはＡＲＰ静的入力操作を実行するという問題は回避される。ステップ１６２０では、制御装置／マルチプレクサがデータグラムを受信し、ＭＡＣアドレスをチェックし、ＭＡＣアドレスが一致する場合にはＩＰアドレスを設定し、ノード名およびデバイスＩＤを保存する。データグラムが受信されないと、ステップ１６２２の動作を通して二次インタフェースを使用して、手順が繰り返される。ステップ１６２４では、制御装置／マルチプレクサが、新しいアドレスを使用して、制御装置／マルチプレクサが稼動中であることを示していると述べているブートサーバにメッセージを送信する。

ステップ１６２６では、ユーザは、デバイス名、デバイスＭＡＣアドレス、ＡＣＮリンク番号およびＰＣＮネットワーク番号を入力する。デバイスＩＤは、構成ソフトウエアにより自動的に割り当てることができる。通信サブシステムは、構成済みＡＣＮリンク番号、ＰＣＮネットワーク番号、および割り当てられているデバイスＩＤからのデバイスの３つのＩＰアドレスを計算する。ステップ１６２８では、制御装置／マルチプレクサ、またはＩ／Ｏカードソフトウエアが、メッセージおよびＳ−RecordファイルをＡＣＮ上のデバイス間で受け渡すことによって、ＡＣＮネットワーク上でフラッシュダウンロードされる。

図１８を参照すると、オブジェクト通信図が、接続のアクティブな発信側に対してデバイス接続を作成するための方法を示している。ワークステーションまたは制御装置／マルチプレクサのどちらかのアプリケーションプログラムは、別のデバイスに包含されている属性へのアクセスを要求する。他のデバイスへのＵＤＰ通信接続は、属性にアクセスできるように通信サービスによって確立される。デバイス接続の作成は、２つのアプリケーションプログラムに及ぶ。別のデバイス内に位置しているデータを要求することにより接続を始動するアプリケーションプログラム、およびリモートオブジェクト通信（ＲＯＣ）サービスアプリケーションプログラムは実際に他のデバイスにメッセージを送信する。ＲＯＣサービスプロセスがあるデバイスにメッセージを送信する準備ができているときに接続が存在しない場合、ＲＯＣサービスはそのデバイスに対する接続を作成する。

デバイス接続の前に、接続されるデバイスはソースデバイスを記載している有効なデバイステーブルを有しており、動作しており、直接接続ポートでメッセージを監視するオブジェクト（RtDeviceConnection）を含む。デバイス接続が作成された後、２つのデバイスの間で接続が確立され、（RtDeviceconnection）インスタンスがアクティブデバイスの中に作成され、接続を取り扱う。

ステップ１７１０では、アプリケーションプログラムが、メッセージ（getContainer）を、発見されたまたは作成されたモジュールのオブジェクトＩＤを戻すオブジェクト（RtSite）に送信する。ステップ１７１２では、オブジェクト（ＲｔＳｉｔｅ）が、モジュールの位置を見つけ出し、そのオブジェクトＩＤを戻すオブジェクト（RtPlantArea）に（Locate）メッセージを送信する。ステップ１７１４では、オブジェクト（RtSite）が、モジュールを包含しているデバイスのオブジェクトＩＤを戻すオブジェクト（RtDevice）に、（GetDevice）メッセージを送信する。ステップ１７１６では、リモートデバイスのプロキシが存在しないと仮定して、オブジェクト（RtDevice）が、オブジェクト（RtDeviceProxy）にCreateメッセージを送信する。ステップ１７１８では、オブジェクト（RtDeviceProxy）が、テンプレート（RtNew）を使用してオブジェクト（RtDeviceProxy）のインスタンスを作成する。ステップ１７２０では、オブジェクト（RtDeviceProxy）が、オブジェクト（RtDeviceConnection）に、オブジェクト（RtDeviceConnection）によって管理されているデバイス接続テーブル内のデバイス名のインデックスを戻す（GetDeviceConnectionIndex）ように依頼する。ステップ１７２２では、オブジェクト（RtDeviceProxy）が、（RegisterPointer）メッセージをオブジェクト（RtRegistry）に送信することにより、接続されているデバイスの（RtDeviceProxy）インスタンスに対するポインタを登録し、オブジェクト（RtDevice）にデバイスプロキシObject IDを戻す。ステップ１７２４においては、オブジェクト（RtPlantArea）が、オブジェクト（RtModuleProxyClient）に（Create）メッセージを送信し、リモートモジュールに対するプロキシクライアントを作成する。ステップ１７２６では、オブジェクト（RtModuleProxyClient）が、オブジェクト（RtModuleProxyServer）に（Create）メッセージを送信し、リモートデバイス内のモジュール用のプロキシサーバを作成する。ステップ１７２８では、オブジェクト（RtModuleProxyServer）が、プロキシサーバ作成メッセージを構築し、オブジェクト（RtRocReqRespService）に、リモートデバイスにリクエストを送信する（SendRequest）ように依頼する。ステップ１７３０では、オブジェクト（RtRocReqRespService）が、ＲＯＣ通信サービスプロセスがリモートデバイスに送信するために、メッセージを出発メッセージ待ち行列に付加する。ステップ１７３２では、ＲＯＣ通信サービスプロセス内のオブジェクト（RtRocReqRespService）が、（RemoveFirst）コマンドを出発メッセージ待ち行列に発行し、プロキシサーバ作成メッセージを取得する。ステップ１７３４では、オブジェクト（RtRocReqRespSerice）が、（sendMsg）コマンドを、宛先デバイスの（aRtDeviceProxy）インスタンスに発行することによりメッセージを送信する。ステップ１７３６では、（aRtDeviceProxy）インスタンスが、（GetDeviceConnection）コマンドを（RtDeviceConection）コマンドに発行し、宛先デバイスの（RtDevceConnection）インスタンスのオブジェクトＩＤを取得する。ステップ１７３８では、デバイス接続がすでに存在しないと仮定し、オブジェクト（RtDeviceConnection）がcreateDeviceConnectionを実行する。ステップ１７４０では、オブジェクト（RtDeviceConnection）が、テンプレート（RtNew）を使用して、RtDeviceConnectionのインスタンスを作成する。ステップ１７４２では、オブジェクト（RtDeviceConnection）が、（RegisterPointer）メッセージをオブジェクト（RtRegistry）に送信することにより（RtDeviceConnection）インスタンスに対するポインタを登録し、デバイス接続Object IDをオブジェクト（RtDeviceConnection）に戻す。ステップ１７４４では、オブジェクト（RtDeviceConnection）が、（startActiveConnection）メッセージを（aRtDeviceConnection）インスタンスに送信する。（aRtDeviceConnection）インスタンスは、他のデバイスに対する接続を確立するために必要なステップを実行する。ステップ１７４６では、（RtDeviceProxy）インスタンスが、sendMsgを（aRtDeviceConnection）インスタンスに発行し、サーバ作成メッセージをリモートデバイスに送信する。ステップ１７４８では、（aRtDeviceConnection）インスタンスが、新規に作成されている接続でリモートデバイスにメッセージを送信する。

図１９を参照すると、オブジェクト通信図が、接続の受動リスン側にデバイス接続を作
成する方法を示している。デバイス接続を確立するための要求は、別のワークステーショ
ンまたは制御装置／マルチプレクサから受け取られる。通信サービスは、要求側デバイス
とＵＤＰ通信接続を確立する。

接続の作成以前に、接続されるデバイスは動作中であり、接続を確立する準備ができているオブジェクト（aRtDeviceConnection）を包含している。オブジェクト（RtDevice Connection）は、デバイスの中に存在し、同期要求という形の入力メッセージを求めて傾聴している（listening）。接続が作成されてから、接続は２つのデバイスの間で確立され、（RtDeviceConnection）インスタンスが受動的なデバイス内に作成され、その接続を取り扱う。

ステップ１８１０では、オブジェクト（RtDeviceConnection）はリモートデバイスから同期要求メッセージを受け取る。ステップ１８１２では、オブジェクト（RtDeviceConnection）は、オブジェクト（RtDeviceConnection）にCreateメッセージを送信し、要求側デバイスへの接続を作成する。オブジェクト（RtDeviceConnection）は、デバイス接続がすでに存在していないと仮定し、ステップ１８１４で（createDevoceConnection）を実行する。ステップ１８１６では、オブジェクト（RtDevoceConnection）は、テンプレート（RtNew）を使用してオブジェクト（RtDeviceConnection）のインスタンスを作成する。ステップ１８１８においては、オブジェクト（RtDeviceConnection）は、（RegisterPointer）メッセージをRtRegistryに送信することによって（RtDeviceConnection）インスタンスに対するポインタを登録し、デバイス接続オブジェクトＩＤをオブジェクト（RtDeviceConnection）に戻す。ステップ１８２０では、オブジェクト（RtDeviceConnection）が、オブジェクト（RtDeviceProxy）にＣｒｅａｔｅメッセージを送信し、要求側デバイスのためのデバイスプロキシを作成する。ステップ１８２２では、オブジェクト（RtDeviceProxy）が、テンプレート（RtNew）を使用してオブジェクト（RtDeviceProxy）のインスタンスを作成する。ステップ１８２４では、オブジェクト（RtDeviceProxy）が、オブジェクト（RtDeviceConnection）に（GetDeviceConnectionIndex）メッセージを送信し、後で使用するために、デバイス接続テーブル内のデバイスのインデックスをオブジェクト（RtDeviceConnection）によって管理させる。ステップ１８２６では、オブジェクト（RtDeviceProxy）が、（RegisterPointer）メッセージをRtregistryに送信することによりオブジェクト（RtDeviceProxy）に対するポインタを登録し、デバイスプロキシオブジェクトＩＤをオブジェクト（RtDeviceConnection）に戻す。ステップ１８２８では、オブジェクト（RtDeviceConnection）は、handleInboundMessage方法を介して処理するために、（RtDeviceConnection）インスタンスに同期要求メッセージを渡す。ステップ１８３０では、オブジェクト（aRtDeviceConnection）が、リモートデバイスに同期応答メッセージを送り返し、（Device Connection）作成の無事完了を示す。

図２０を参照すると、オブジェクト通信図が、デバイス間で要求／応答メッセージを送信するための方法を示している。あるデバイスでのリモートオブジェクト通信（ＲＯＣ）サービスは、別のデバイス内のＲＯＣサービスに対し要求メッセージを送信する。要求メッセージは処理され、応答メッセージが発信側デバイスに送り返される。

メッセージを送信する前に、デバイス間でＵＤＰデバイス接続が確立される。デバイス間での要求／応答メッセージの送信に続き、リモートデバイスからの応答メッセージが、ＲＯＣサービスによる処理のために準備完了している。

ステップ１９１０では、読取り属性要求が、アプリケーションプログラムによってリモートデバイスに関連付けられている（RtDeviceProxy）インスタンスに対し発行される。ステップ１９１２では、（aRtDeviceProxy）インスタンスが、属性値を読み取るために、リモートデバイスに対し送信される要求メッセージを構築し、オブジェクト（RtRocReqRespService）にSendRequest方法を使用してメッセージを送信するように依頼する。ステップ１９１４では、オブジェクト（RtRocReqRespService）が、リモートデバイスへの接続に関連付けられているオブジェクト（RtDeviceConnection）のインスタンスに対し、send_msg方法を使用してメッセージを送信する。ステップ１９１６では、オブジェクト（RtDeviceConnection）のインスタンスが、デバイス接続でリモートデバイスに対しメッセージを伝送する。ステップ１９１８では、リモートデバイス内のオブジェクト（RtDeviceConnection）のインスタンスがメッセージを受け取り、（RtRocRouter）クラスにメッセージを正しい到着メッセージサービスにメッセージを送るように要求する。ステップ１９２０では、オブジェクト（RtRocRouter）が、メッセージが要求／応答メッセージであると判断し、オブジェクト（RtRocReqRespService）に、ProcessInboundRepRespするように要求する。メッセージがＲＯＣサービスおよびメッセージ消費者によって処理された後、応答メッセージが構築され、ステップ１９２２では、オブジェクト（RtRocRqstRespService）が、SendResponse方法を使用して応答メッセージを発信側デバイスに送信する。ステップ１９２４では、オブジェクト（RtRocReqRespService）の出発メッセージ待ち行列処理が、ｓｅｎｄ＿ｍｓｇ方法を使用して、ソースデバイスに対する接続に関連付けられているオブジェクト（RtDeviceConnection）のインスタンスに応答メッセージを送信する。ステップ１９２６では、オブジェクト（RtDeviceConnection）のインスタンスが、オリジナルデバイスに対し応答メッセージを送り返す。ステップ１９２８では、オリジナルデバイスのオブジェクト（RtDeviceConnection）のインスタンスがメッセージを受け取り、（RtRocRouter）クラスにメッセージを正しい到着メッセージサービスに送るように要求する。ステップ１９３０では、オブジェクト（RtRocRouter）が、メッセージが要求／応答メッセージであると判断し、オブジェクト（RtRocReqRespService）にProcessInboundreqRespするように要求する。

図２１を参照すると、オブジェクト通信図が、ネットワーク構成をダウンロードする方法を示している。ユーザは、システム用のデバイス構成の完了に続き、制御装置／マルチプレクサへのダウンロードを始動する。構成アプリケーションによってデバイステーブル構成スクリプトが構築される。通信サービスを使用して、構成アプリケーションは、ダウンロードを受信するために、制御装置／マルチプレクサとのデバイス接続を確立し、ダウンロードスクリプトを制御装置デバイスに送信する。制御装置／マルチプレクサは、ダウンロードスクリプトメッセージを受信し、デバイステーブルを処理する。ステップ２０１０では、構成ダウンロードアプリケーションプログラムが、デバイステーブルダウンロードスクリプトを包含するリモートオブジェクト通信（ＲＯＣ）スクリプトダウンロードメッセージを構築する。ステップ２０１２では、ダウンロードアプリケーションが、オブジェクト（RtDevice）に対し（GetDevice）メッセージを発行し、リモートデバイスのオブジェクト（RtDeviceProxy）のObject IDを取得する。ステップ２０１４では、オブジェクト（RtDeviceProxy）は、存在していないため、Createメッセージが必要なデバイスプロキシオブジェクトを作成するために、オブジェクト（RtDeviceProxyC）に送信される。ステップ２０１６では、オブジェクト（RtDeviceProxyC）が、オブジェクト（RtDeviceConnection）に（GetDeviceConnIndex）メッセージを送信し、デバイス接続テーブル内のリモートデバイスのデバイス接続のインデックスを取得する。ステップ２０１８では、デバイス接続は、まだ存在していないため、（aRtDeviceConnection）オブジェクトが作成され、リモートデバイスへの接続を管理する。ルックアップは、リモートデバイスエントリを発見するためにデータベースで実行される。デバイス通信データ（例えば、ＩＤおよびIP Addresses）がデータベースから検索され、新規エントリが構成デバイス接続テーブルに追加される。デバイスが接続を始動したので、接続は接続テーブルで恒久と記される。ステップ２０２０では、（startActiveconnection）メッセージがオブジェクト（RtDeviceConnection）に送信され、リモートデバイスへの接続を確立する。ステップ２０２２では、オブジェクト（aRtDeviceConnection）がリモートデバイスにRtSyncMessageを送信する。ステップ２０２４では、リモートデバイスがRtSyncMessageを受け取り、送信側デバイスのためのデバイス接続テーブル内でエントリを発見しようとする。ステップ２０２６では、エントリは発見されないため、新規エントリが送信側デバイスのためのデバイス接続テーブルに追加され、（aRtDeviceConnection）オブジェクトが作成され、受信側デバイスで接続を取り扱う。ステップ２０２８では、RtSyncreplyMessageが作成され、デバイステーブルからのデバイス接続インデックスを包含している送信側デバイスに送り返される。デバイス接続は、現在、確立され、メッセージの送受を行う準備が完了している。ステップ２０３０では、オブジェクト（RtDeviceProxyC）が、リモートデバイスの（RtDeviceProxyS）作成メッセージを送信する。ステップ２０３２では、（RtDeviceProxyS）がリモートデバイスで作成される。ステップ２０３４では、ダウンロードアプリケーションが、SendMsg呼出しを使用してオブジェクト（RtRocReqRespServices）を介してリモートデバイスにダウンロードスクリプトを送信する。ステップ２０３６では、RtCommScriptDownloadが、デバイステーブルを受信し、各デバイステーブルアイテムを処理し、そのデータを構成データを保持するために使用されているデータベースRegistryに記憶する。制御装置／マルチプレクサにとって、この処理は（RtDeviceConnection）オブジェクトを作成し、そのオブジェクトをデバイス接続テーブルに追加するために使用され、それ以降より、むしろダウンロード時にメモリを取得できるようにする。

図２１は、デジタル制御システムプログラム（図示されていない）は、診断情報がフィールドバスデバイスから引き出されているか、非フィールドバスデバイスから引き出されているかには関係なく、首尾一貫したやり方でプロセスに関する診断情報を表示するための診断プログラムおよび表示ルーチンを含む。デジタル制御システムプログラム（図示されていない）は、プロセス制御環境１００内のすべてのデバイスに関する診断情報を有利に組み込み、すべての制御動作および診断情報があたかも単一ロケーションで実行または作成されるかのようにコントロールストラテジーおよび診断情報がユーザに提示されるように、この情報を、診断表示ルーチンを使用して統一してユーザに提示する。

図２２を参照すると、画面前面の絵入り図が、通信診断プログラム２２１０を含む診断表示ルーチン２２００の動作を示している。ユーザは、容易に認識されているアイコンを使用して、プロセス制御環境１００内のワークステーション、制御装置、およびネットワークリンクのステータスおよび完全性をグラフィックで表示する。診断表示ルーチン２２００は、デバイスまたはネットワークリンクセグメントを求めて要約ステータス情報も作成する。診断表示ルーチン２２００は、送受されたパケット、接続数等を含む、ネットワークに接続されているデバイスに関する詳細な内部完全性情報を表示する。リモート診断機能性を実現するために、モデムを介してアクセスされる診断情報もある。

ワークステーション１０２または１０４、および制御装置／マルチプレクサ１１０は、ＡＣＮ通信リンクのステータス、デバイス接続、イーサネット統計についての詳細な完全性情報、および通信スタック診断情報を含む、接続されているデバイス内の通信サブシステムのステータスについての詳細な診断情報を供給するために組み合わされて機能する。通信機能性の診断チェックもサポートされる。通信診断プログラム２２１０は、ネットワーク全体の基本診断、単一デバイスの診断情報、および単一デバイス接続の診断情報を含む、３つのレベルの診断情報をサポートする。

基本的なネットワーク診断レベルでは、通信診断プログラム２２１０が、すべてのネットワークデバイスから情報を収集し、その情報をユーザに提示する。通信診断２２１０は、要求に応じてまたは定期的に実行しているバックグラウンドタスクとして、リモート制御装置／マルチプレクサ１１０から情報を収集する。通信診断プログラム２２１０はネットワーク通信ステータス要求をある特定のデバイスの診断ポートに送信し、そのデバイスに対する通信経路の完全性を確認する。

ネットワーク通信ステータスに対する応答は、デバイスが制御装置であるのか、あるいはワークステーションであるのかを示すデバイス型情報を含む通信完全性情報、および一次と二次ステータス要約情報を包含する。エラーがリンク上に存在する場合には「不良」に設定される接続ステータスの要約情報が、属性として通信サブシステムモジュールに追加され、ユーザが、要求があると、これらの値をオペレータインタフェースで表示できるようにする。

通信診断プログラム２２１０は、デバイスとリモートデバイスの間の通信リンクのステータスが表示されるように、プロセス制御環境１００に接続されている各デバイスから診断情報を要求する。

通信診断プログラム２２１０は、デバイス接続に関するリンクステータス情報、およびデバイス内のイーサネットインタフェースに関するイーサネット統計を含む、ある特定のデバイスの通信についての詳細な情報を供給するために、単一デバイスの診断情報を監視、表示する。通信診断プログラム２２１０は、適切な診断リモートオブジェクト通信（ＲＯＣ）メッセージを使用して、デバイス通信ステータスを要求する。デバイス通信ステータスは、デバイステーブルインデックス、デバイスＩＤ、デバイス接続状態（Ready（準備完了）、Synching（同期中）、ＡＣＫ Pending（ＡＣＫ未決）、Closed（閉鎖済み））、一次デバイスアドレス、二次デバイスアドレス、リンクのステータス、および単一デバイス接続の診断情報などの情報を含む。

イーサネット統計情報は、デバイスブート時に計数を開始し、デバイスのリブートまでリセットされないカウンタに保持される。カウントは、モジュール属性の一部として通信サブシステムモジュールに対する属性として実現され、合計入力エラー、入力ＣＲＣエラー、および入力無効エラーの数を含む入力エラー情報を含む。出力エラー情報は、合計出力エラー、出力遅延衝突、事前に選択されている数を上回る出力衝突、出力無効エラー、および出力キャリヤ損失エラーを含む。それ以外のカウントは、受信パケット、送信パケット、受信バイト、送信バイト、受信一斉送信パケット、送信一斉送信パケット、受信未知プロトコルメッセージ、伝送延期、単一衝突伝送、および複数衝突伝送の数を含む。

通信診断プログラム２２１０は、ある特定のデバイスのある特定のデバイス接続に関する詳細な診断情報も監視、表示する。ユーザがデバイス接続統計を要求すると、通信診断プログラム２２１０は接続のために宛先デバイスＩＤを指定する。デバイス接続統計は、デバイス接続状態（Ready、Synching，ＡＣＫPending、Closed）、リモート一次アドレス（宛先デバイスのPrimary ACN Address）、リモート二次アドレス（このデバイスの二次ＡＣＮIP Addressまたは０）、Primary Link Status（Good（良好）／Bad（不良））、二次リンクステータス（Good／Bad）を含む、指定されたデバイス接続のリンクステータス情報および統計情報を包含する。統計は、一次リンクで受信されたメッセージ、二次リンクで受信されたメッセージ、一次リンクで送信されたメッセージ、二次リンクで送信されたメッセージ、同期送信、同期受信、一次リンクでのＡＣＫタイムアウト、および二次リンクでのＡＣＫタイムアウトのカウントも含む。

通信診断２２１０は、ネットワーク内の２つのデバイス間の通信経路のチェックもサポートする。第１デバイスは、リモートデバイスへ、指定された通信リンク上で喚起メッセージなどのメッセージを送信する。リモートデバイスは、そのメッセージを送信者にエコーして戻す。無事完了した喚起メッセージおよびエコーは、リモートデバイスで通信サブシステムが機能していることを示す。この対話は、完全にイーサネットハードウエアドライバによって取り扱われている通常のＴＣＰ／ＩＰピーン（ping）とは異なる。

図２３を参照すると、オブジェクト通信図が、あるデバイスが、別のデバイスがネットワーク上に存在するかどうかをチェックする方法を示している。プロセス制御環境の一部またはスタンドアロンアプリケーションのどちらかである、診断アプリケーションプログラムが、リモートデバイスがＡＣＮネットワーク上に存在するかどうか、存在する場合には、リモートデバイスが通信できるかどうかを突き止める。診断アプリケーションプログラムはリモートデバイスにメッセージを送信し、リモートデバイスからエコーされるメッセージまたはタイムアウトを受信することを期待する。

ステップ２３１０では、診断アプリケーションプログラムは、オブジェクト（RtcommDiag）に、通信問い合わせ（ピーン）が指定されているデバイス名またはアドレスに対し実行されることを要求するＰｉｎｇメッセージを送信する。ステップ２３１２では、オブジェクト（RtCommDiag）が通信ソケットを作成し、問い合わせを実行する。ステップ２３１４では、オブジェクト（RtCommDiag）がメッセージ（RtEchoMessage）を作成し、リモートデバイスに送信する。ステップ２３１６では、オブジェクト（RtCommDiag）が、RtCommSendToを使用し、指定されているデバイスにメッセージ（RtEchoMessage）を送信し、メッセージがリモートデバイスからエコーバックされるのを待機する。ステップ２３１８では、リモートデバイス内のオブジェクト（RtDeviceConnection）がメッセージ（RtEchoMessage）を受信し、ハンドル診断メッセージ方法を使用してそのメッセージを処理する。ステップ２３２０では、オブジェクト（RtDeviceConnection）が、メッセージ（RtCommSentToMessage）を使用して、ソースデバイス内のオブジェクト（RtCommDiag）へのエコー応答の診断符号付きメッセージ（RtEchoMessage）を即座に戻す。ステップ２３２２では、オブジェクト（RtCommD）が、エコー応答メッセージを受信し、診断アプリケーションに無事完了ステータスを戻す。リモートデバイスから応答が受信されない場合、ステップ２３２４で、オブジェクト（RtCommDiag）が診断アプリケーションに故障ステータスを戻す。ステップ２３２６では、オブジェクト（RtCommDiag）が、問い合わせを実行するために作成されたソケットを閉じる。

図２４を参照すると、オブジェクト通信図が、デバイス通信診断を要求するための方法を示している。診断アプリケーションプログラムは、リモートデバイス内のすべてのデバイス接続のステータスを要求、アクセス、表示する。診断アプリケーションプログラムは、リモートデバイスに必要とされている診断情報に対する要求を送信し、応答を待機する。いったん応答が受信されると、リモートデバイス内でのすべてのデバイス接続およびデバイスステータスがユーザに表示される。この情報は、診断アプリケーションプログラムが診断データに対する複数の要求を行うように、複数のメッセージで通信してよい。

ステップ２４１０では、診断アプリケーションプログラムが、オブジェクト（RtComjmDiag）に（GetDeviceCommDiags）要求メッセージを送信し、リモートデバイスでのデバイス接続の通信診断を要求する。ステップ２４１２では、オブジェクト（RtCommDiag）が、オブジェクト（RtDeviceConnection）に（GetDeviceConnectionIndex）メッセージを送信し、リモートデバイスのデバイス接続テーブルインデックスを要求する。ステップ２４１４では、オブジェクト（RtCommDiag）が、オブジェクト（RtRocMessage）に対しCreateを発行し、診断情報を要求するために使用されるメッセージを作成する。ステップ２４１６では、オブジェクト（RtRocMessage）が、診断要求に使用される（aRtRocMessage）の新規インスタンスを作成する。ステップ２４１８では、オブジェクト（RtCommDiag）が送信されるメッセージを構築し、オブジェクト（RtRocReqRespService）にメッセージ（SendRequest）を発行し、メッセージをリモートデバイスに送信する。ステップ２４２０では、オブジェクト（RtcommDiag）が、診断要求メッセージ用に作成されている（aRtRocMessage）インスタンスにメッセージ（waitForResponse）を発行する。ステップ２４２２では、オブジェクト（RtRockReqRespService）が、リモートデバイスに関連付けられている（aRtDeviceConnection）インスタンスでsend_msgを実行する。ステップ２４２４では、（aRtDeviceConnection）インスタンスが、要求メッセージをリモートデバイスに伝送する。ステップ２４２６では、リモートデバイス内のオブジェクト（RtDeviceConection）が、メッセージを受信し、送信側デバイスに関連付けられている（aRtDeviceConnection）インスタンスに、メッセージ（handleInboundMessage）を発行する。ステップ２４２８では、（aRtDeviceConnection）インスタンスが、処理のために、Route方法を介してオブジェクト（RtRocRouter）にメッセージを渡す。ステップ２４３０では、オブジェクト（RtRocRouter）が、オブジェクト（RtRocReqRespService）にProcessnboundReqRespを発行することによってメッセージに応答する。ステップ２４３２では、オブジェクト（RtRocReqRespService）が、要求メッセージＩＤからメッセージ型を求め、（RtRocDevConDiagListMsg）メッセージに関するperformコマンドを発行する。ステップ２４３４では、（RtRocDevConDiagListMsg）が、オブジェクト（RtDeviceConnection）に（GetDiagList）メッセージを送信し、このデバイスでのデバイス接続のためにデバイス接続診断データを取得する。ステップ２４３６では、オブジェクト（RtDeviceConnection）が、ユーティリティクラス（RtDevConDiagListData）によって提供されている多様な塗りつぶし（ｆｉｌｌ）ルーチンを使用して、診断データを出たバッファの中に入れる。ステップ２４３８では、オブジェクト（RtRocDevConDiagListMsg）が、CreateResponseを実行し、診断データを包含する応答メッセージを作成する。ステップ２４４０では、（RtRocDevConDiagListMsg）が、（RtDevConDiagListData）に（storeOn）メッセージを発行し、診断データを応答メッセージの中に入れる。ステップ２４４２では、（RtRocDevConDiagListMsg）が、SendResponse方法を使用して、（RtRocReqRespService）を通して要求側デバイスに応答メッセージを送り返す。ステップ２４４４では、（RtRocReqRespService）が、要求側デバイスに関連付けられている（aRtDeviceConnection）インスタンスに対しsend＿msgを実行する。ステップ２４４６では、（aRtDeviceConnection）インスタンスが、要求側デバイスに応答メッセージを送り返す。ステップ２４４８では、要求側デバイス内の（aRtDeviceConnection）インスタンスが、handleInboundMessageを介して、（RtDeviceConnection）から応答メッセージを受信する。それから、応答メッセージは、Route方法を使用して（RtRocRouter）に送信する。ステップ２４５０では、（RtRocRouter）が、（RtRocReqRespService）に対し（ProcessInboundReqResp）を実行する。ステップ２４５２では、（RtRocReqRespService）が、（aRtRocMessage）インスタンスに、診断データに対する元の要求への応答が入手できることを知らせる。ステップ２４５４では、（RtCommDiag）が、（RtDevConDiagListData）に対し（readFrom）を発行し、応答メッセージから診断データを検索する。ステップ２４５６では、（RtCommDiag）が、（RtDevConDiagListData）に対し（getData）メッセージを発行し、表示のために診断データを検索する診断アプリケーションにデータを戻す。要求側デバイスは、すべてのデバイス接続活動の一般的な診断を適所に包含しているバッファを戻す。

図２５を参照すると、オブジェクト通信図が、デバイス接続通信診断を要求するための方法を示している。診断アプリケーションプログラムは、リモートデバイスに存在している単一デバイスの詳細なステータスを要求、アクセス、および表示する。診断アプリケーションプログラムは、リモートデバイスに、デバイス接続統計情報に対する要求を送信し、応答を待機する。いったん応答が受け取られると、デバイス接続に関するデバイス接続統計がユーザに表示される。ステップ２５１０では、診断アプリケーションプログラムが、（RtCommDiag）に（GetDeviceConDiags）要求を送信し、リモートデバイスでの特定のデバイス接続に関するデバイス接続統計を取得する。ステップ２５１２では、（RtCommDiag）が、（RtDeviceConnection）に（GetDeviceConnectionIndex）メッセージを送信し、リモートデバイスのデバイス接続テーブルインデックスを取得する。ステップ２５１４では、（RtCommDiag）が、（RtRocMessage）に対しCreateを発行し、診断情報を要求するために使用されるメッセージを作成する。ステップ２５１６では、（RRocMessage）が、診断要求のために使用される（aRtRocMessage）の新規インスタンスを作成する。ステップ２５１８では、（RtCommDiag）が、送信されるメッセージを構築し、（RtRocReqRespService）に（SendRequest）を発行し、メッセージをリモートデバイスに送信する。ステップ２５２０では、（RtCommDiag）が、診断要求メッセージのために作成されている（aRtRocMessage）インスタンスに（waitForResponse）を発行する。ステップ２５２２では、（RtRocReqRespService）が、リモートデバイスに関連付けられている（aRtDeviceConnection）のインスタンスに対しsend＿msgを実行する。ステップ２５２４では、（ａRtDeviceConnection）インスタンスが、リモートデバイスに要求メッセージを伝送する。ステップ２５２６では、リモートデバイス内の（RtDeviceConnection）がメッセージを受信し、送信側デバイスに関連付けられている（aRtDeviceConnection）インスタンスに（handleInboundMessage）を発行する。ステップ２５２８では、（RtDeviceConnection）インスタンスが、処理のためにRouterメッセージを介して、（RtRocRouter）にメッセージを渡す。ステップ２５３０では、（RtRocRouter）が、メッセージが要求応答型メッセージであることを突き止め、（RtRocReqRespService）に対し（ProcessInboundReqResp）を発行する。ステップ２５３２では、（RtRocReqRespService）が、要求メッセージＩＤからメッセージ型を突き止め、（RtRocDevConDiagDetailMsg）メッセージに対するperform（実行）コマンドを発行する。ステップ２５３４では、（RtRocDevConDiagdetailMsg）が、（RtDeviceConnection）に（GetDiagDetail）メッセージを送信し、要求されているデバイス接続に関するデバイス接続統計を取得する。ステップ２５３６では、（RtDeviceConnection）が、ユーティリティクラス（RtDevConDiagDetailData）によって提供される多様な塗りつぶしルーチンを使用して、データバッファの中に診断データを入れる。ステップ２５３８では、（RtRocDevConDiagDetailMsg）が、（CreateResponse）を実行し、診断データを包含している応答メッセージを作成する。ステップ２５４０では、（RtRocDevConDiagDetailMsg）が、（RtDevConDiagDetailData）に対し、（storeOn）メッセージを発行し、診断データを応答メッセージの中に入れる。ステップ２５４２では、（RtRocDevConDiagDetailMsg）が、（SendResponse）方法を使用して（RtRocReqrespService）を通して要求側デバイスに応答メッセージを送り返す。ステップ２５４４では、（RtRocReqRespService）が、要求側デバイスに関連付けられている（aRtDeviceConnection）インスタンスに対し（send＿msg）を実行する。ステップ２５４６では、（aRtDeviceConnection）インスタンスが、要求側デバイスに応答メッセージを送り返す。ステップ２５４８では、要求側デバイス内の（aRtDeviceConnection）インスタンスが、（handleInboundMessage）を介して、（RtDeviceConnection）から応答メッセージを受け取る。応答メッセージは、Route方法を使用して（RtRocRouter）に送信される。ステップ２５５０では、（RtRocRouter）が、（RtRocReqRespService）に対し（ProcessInboundReqResp）を実行する。ステップ２５５２では、（RtRocReqRespService）が、（aRtRocMessager）に対し、診断データを求める元の要求に対する応答が入手できることを知らせる。ステップ２５５４では、（RtCommDiag）が、（RtDevConDiagDetailData）に対し（readFrom）を発行し、応答メッセージから診断データを検索する。ステップ２５５６では、（RtCommDiag）が、（getData）メッセージを（RtDevConDiagDetailData）に発行し、表示のために診断データを検索する診断アプリケーションにデータを戻す。

以下、参考形態として、デバイス接続自動検知の実施形態を図２６乃至３７を用いて例示する。
一般的には、制御装置／マルチプレクサ１１０は、手動でネットワークに追加される。例えば、デバイスは、典型的には、ユーザが、デバイスが接続されることになるＡＣＮ Segmentを選択し、「New Device（新規デバイス）」コマンドを発行するとネットワークに追加される。ユーザは、ワークステーションまたは制御装置／マルチプレクサのデバイス型、デバイス名、およびコマンドフィールドを入力するようにプロンプトを出される。構成システムは、自動的にデバイスに次のデバイスＩＤを割り当て、そのデバイスＩＤに基づきデフォルト名を構築する。構成システムは、オプションで、ＰＣＮ番号および過去に割り当てられたデバイスＩＤに基づき、デバイスに対し一次と二次ＩＰアドレスおよびサブネットマスクを自動的に生成する。

代わりに、制御装置／マルチプレクサは、自動的に検知され、図２６に図示されるように実行時システムの中に組み込まれる。ステップ２６１０では、制御装置／マルチプレクサは、ＡＣＮへの接続時、および電力が適用されると、識別またはＩＰアドレス割当て検証を求める要求を自動的に送信する。要求メッセージは、制御装置／マルチプレクサのＭＡＣアドレスを含む。要求は、ステップ２６１２で、マスタ構成制御装置／マルチプレクサで、オペレーティングシステム技術で知られている「プラグアンドプレイネットワーク構成サービス」によって取り扱われる。ステップ２６１４では、「プラグアンドプレイネットワーク構成サービス」が、ネットワークから、ＩＰアドレスを割り当てる／検証するための要求を受け取り、ＭＡＣアドレス一致を求めて構成済みデバイスのテーブルを検証する。一致が発見されると、ステップ２６１６で、「プラグアンドプレイネットワーク構成サービス」が、デバイス名、デバイスＩＤ、ＩＰアドレス情報、サブネットマスク情報、ＡＣＮセグメント番号およびデバイステーブルに含まれているその他のアイテムをもって応答する。一致が発見されない場合、ステップ２６１８で、「プラグアンドプレイネットワーク構成サービス」は、制御装置／マルチプレクサＭＡＣアドレス（例えば、Controller−０００００１）に基づきデバイスのデフォルト名を自動的に生成する。新規デバイスは、ステップ２６２０でDevice Scratch領域内のデータベースに追加される。

ステップ２６２２では、ユーザはエクスプローラ（登録商標）を使用して、Device Scratch領域内の各未割当て済み制御装置／マルチプレクサを選択し、適切なＡＣＮセグメントまで選択をドラッグし、新規デバイスとして選択をシステムに追加するか、あるいは事前に存在していたデバイス構成に選択をドロップする。未割当て済み制御装置／マルチプレクサが、新規デバイスとして追加される場合、構成処理は、デバイスの手動組込みのやり方で進む。ステップ２６２４では、ユーザは、過去に割り当てられていた名称「Controller−０００００１」をデフォルトとして使用し、本当のデバイス名を入力するようにプロンプトが出される。自動アドレス割当てが設定されている場合、新規デバイスには次のデバイスＩＤと関連付けられているＩＰアドレスが割り当てられ、サブネットマスクは、ステップ２６２６で自動的に割り当てられる。手動アドレス割当てが設定されている場合、デバイスは、自動的に、次のデバイスＩＤを割り当てられ、ユーザは、ステップ２６２８でＩＰアドレスとサブネットマスクを入力するようにプロンプトを出される。制御装置／マルチプレクサのＭＡＣアドレスは、ＡＣＮセグメントの中にドラッグされるように、「Controller−０００００１」のＭＡＣアドレスに設定される。新規制御装置／マルチプレクサ名、デバイスＩＤ、ＩＰアドレス、サブネットマスクおよびＡＣＮ番号が、データベース内のデバイステーブルに追加される。未構成制御装置／マルチプレクサによる次の要求は、「プラグアンドプレイネットワーク構成サービス」によって回答される。

新規制御装置／マルチプレクサが既存のデバイス上でドラッグアンドドロップされる場合、そのデバイスは、制御装置／マルチプレクサ型のデバイスであり、未割当てＭＡＣアドレスを有していなければならない。したがって、過去に入力された制御装置／マルチプレクサのＭＡＣアドレスは、ドロップされた「Controller−０００００１」でバイアスのＭＡＣアドレスに設定される。新規制御装置／マルチプレクサ名、デバイスＩＤ、ＩＰアドレス、サブネットマスクおよびＡＣＮ番号が、「プラグアンドプレイネットワーク構成サービス」によって要求側制御装置／マルチプレクサに対し送信するために入手できる。

デジタル制御システムプログラム（図示されていない）は、ユーザによる「自動構成」コマンドに応えて、あるいは新規制御装置／マルチプレクサの検出に応えて、入出力（Ｉ／Ｏ）サブシステムを自動的に構成するための自動構成ルーチンを含む。

図２７を参照すると、フローチャートが、物理Ｉ／Ｏ装置を構成するための自動構成ルーチンのステップを示している。自動構成コマンドは、制御装置／マルチプレクサ１１０に命令され、制御装置／マルチプレクサ１１０内の各Ｉ／Ｏサブシステムに自動構成させる。自動構成コマンドは、Ｉ／Ｏサブシステムに命令され、Ｉ／Ｏサブシステム内の各Ｉ／Ｏカードに自動構成させる。自動構成コマンドは、Ｉ／Ｏカードに命令されることもある。

Ｉ／Ｏカードの自動構成動作は、まず最初に、ある特定のカード位置でＩ／Ｏカードに応答指令信号を送り、ステップ２７１０でカードタイプ、および暗にいくつかのＩ／Ｏカードでは、Ｉ／Ｏカード内のＩ／Ｏポートの数を突き止める。Ｉ／Ｏカードがそのカード位置に関してエンジニアリングデータベースで過去に作成されていなかった場合、ステップ２７１２で適切な型のＩ／Ｏカードが定義され、適切な数のＩ／Ｏポートが作成される。Ｉ／Ｏカードが、そのカード位置に関してエンジニアリングデータベース内に存在しないが、エンジニアリングデータベース内のカードタイプがカード位置で検知されたカードタイプと一致しない場合、自動構成動作が、ステップ２７１４で不一致のグラフィック通知を作成し、ユーザに応答指令信号を送り、エンジニアリングデータベースが、カードタイプを含むように変更されなければならないかどうかを判断する。エンジニアリングデータベース内のカードタイプは、ユーザによって要求される場合、検知済みカードタイプに変更される。

一旦カードタイプが知られると、自動構成プログラムは、ステップ２７１８でカードタイプに従って各Ｉ／Ｏ Portに応答指令信号を送り、ポートタイプおよび情報が入手できる場合には、Ｉ／Ｏポート上でのＩ／Ｏデバイスの数を突き止める。Ｉ／Ｏポートが、そのポートアドレスに関し、エンジニアリングデータベース内で過去に作成されなかった場合、適切な型のＩ／Ｏポートが定義され、ステップ２７２０で適切な数のＩ／Ｏデバイスが作成される。Ｉ／Ｏポートが、そのポートアドレスに関しエンジニアリングデータベース内に存在するが、ポートタイプが検知されたＩ／Ｏポートの型と一致しない場合、ユーザは、ステップ２７２２で不一致を通知され、ステップ２７２４で検知されたＩ／Ｏポートに一致するようにエンジニアリングデータベースを変更するかどうか尋ねられる。エンジニアリングデータベース内のポートタイプは、ユーザによって要求される場合、ステップ２７２６で検知されたポートタイプに変更される。

一旦ポートタイプが知られると、自動構成プログラムは、ステップ２７２８でポートタイプに従って各Ｉ／Ｏデバイスに応答指令信号を送り、デバイスタイプを突き止める。Ｉ／Ｏデバイスが、そのデバイスアドレスに関し、エンジニアリングデータベース内で過去に作成されなかった場合、適切な型のＩ／Ｏデバイスがステップ２７３０で定義される。Ｉ／Ｏデバイスが、そのデバイスアドレスに関しエンジニアリングデータベースに存在するが、デバイスタイプが検知されたＩ／Ｏデバイスと一致しない場合、ユーザは、ステップ２７３２で不一致を通知され、ステップ２７３４で、検知されたＩ／Ｏデバイスに一致するようにエンジニアリングデバイスを変更するかどうかを尋ねられる。エンジニアリングデータベース内のデバイスタイプは、ユーザによって要求される場合、ステップ２７３６で検知されたデバイスに変更される。

ステップ２７３８では、同一の信号ソース経路とともにＩＳＴがすでに存在しない限り、計測器信号タグ（ＩＳＴ）が、Ｉ／ＯポートおよびＩ／Ｏデバイス上の一次信号ソースに関して自動的に作成される。

図２８を参照すると、グラフィックユーザインタフェース（ＧＵＩ）用の「画面」２８００とも呼ばれている画面前面表示が、システム構成のディスプレイを描いている。画面２８００は、プロセス制御環境を選択、構築および動作するためにユーザによって操作されるナビゲーション選択を描いている。ナビゲーションプログラムは、ネットワーク中の多様なツールおよびプロセッサを横切ってナビゲーションするための初期状態を供給する。ユーザは、ナビゲーションプログラムを制御し、ライブラリ、領域、プロセス制御環境、および機密保護動作にアクセスする。

実例となるシステム構成は、制御システムセットアップ２８０２、コントロールストラテジー２８０４、および物理セットアップ２８０６に関して記述され、制御される。制御システムを自動的に検知し、自動的に構成する機能は、物理セットアップ２８０６に関係する。特に、制御システムにおける物理デバイスを自動的に検知し、自動的に構成する機能は、制御ネットワーク２８０８内でのデバイスの作動および起動、制御装置２８１０の使用中止に関係する。

実例となる実施態様においては、プロセス制御システムは、フィールドバス規格プロトコルに従ってプロセス制御ネットワークに接続されている多様なデバイスを制御する。フィールドバスプロトコルでは、標準ユーザアプリケーションがブロックに基づいて定義される。ブロックは、多様な異なる種類のアプリケーション関数の表現である。ブロックの種類には、リソースブロック、ファンクションブロック、および変換器ブロックを含む。

リソースブロックは、デバイス名、製造業者、および連続番号などのフィールドバスデバイスの特徴を記述する。デバイスは、単一リソースブロックしか含まない。

ファンクションブロックは、制御システムの動作を定義する。ファンクションブロックの入力パラメータおよび出力パラメータは、フィールドバス上でリンクしてよい。各ファンクションブロックの実行は、正確に予定を立てられる。ユーザアプリケーションは、多数のファンクションブロックを含んでよい。標準ファンクションブロックの例は、アナログ入力（ＡＩ）、アナログ出力（ＡＯ）、バイアス（Ｂ）、制御セレクター（ＣＳ）、離散入力（ＤＩ）、離散出力（ＤＯ）、手動操作器（ＭＬ）、比例／微分（ＰＤ）、比例／積分／微分（ＰＩＤ）、および比率（ＲＡ）を含むことがある。ファンクションブロックは、フィールドバスデバイスの中に構築され、選択されているデバイス機能性を定義する。１つの例では、簡略温度送信機が、ＡＪファンクションブロックを包含してよい。多くの場合、制御弁は、ＰＩＤファンクションブロックおよびＡＯブロックを含む。

変換機ブロックは、センサを読み取り、出力ハードウエアに命令を出すために、ローカル入力関数および出力関数からファンクションブロックを分離する。変換器ブロックは、校正データおよびセンサ型などの情報を包含する。典型的には、ユーザアプリケーションは、入力または出力ファンクションブロックごとに１つの変換器ブロックを使用する。

ユーザアプリケーションで定義されている別のオブジェクトは、デバイスにとって内部で、フィールドバスネットワーク全体でのファンクションブロック入力と出力の間のリンクを定義するためのリンクオブジェクトを含む。傾向オブジェクトにより、他のデバイスによるアクセスのために、ファンクションブロックパラメータの局所的な傾斜（trending）が可能になる。警報オブジェクトは、フィールドバス上での警報およびイベントの報告を可能にするために使用される。ビューオブジェクトは、人間／機械インタフェースで使用されているブロックパラメータセットの既定義分類である。ファンクションブロック指定は、ブロックの型ごとに４つのビューを定義する。

図２９を参照すると、状態遷移図が、フィールドデバイスの多様な状態を示している。フィールドデバイス状態は、オフライン状態２９０２、未認識状態２９０４、スタンバイ状態２９０６、作動済み状態２９０８、および未結合状態２９１０を含む。フィールドデバイスの状態は、システム管理状態（ＳＭ−Ｓｔａｔｅ）、物理デバイスタグ（ＰＤ−Ｔaｇ）、デバイスアドレス、デバイス改訂情報（Ｒｅｖ＊)、およびデバイス識別（Device−ＩＤ）を含む複数のパラメータにより判断される。実例となる実施態様においては、作動済み状態２９０８にあるデバイスは、コントロールストラテジーの構成およびインストールに利用できるフィールドバスデバイスである。使用が中止されたデバイスとは、作動済み状態２９０８から削除されたデバイスのことである。

Ｔ１からＴ１４の複数の状態遷移の内の１つの状態遷移を生じさせる複数のイベントが発生する。各状態遷移中には、１つまたは複数の動作が実行される。

状態遷移Ｔ１は、一時アドレスに常駐しているフィールドデバイスが、システム管理特定サービス（SM-IDENTIFY）により照会されるイベントによって引き起こされ、問い合わせが、デバイスがクリアされた物理デバイスタグを有していると判断する。状態遷移Ｔ１は、フィールドデバイスにスタンバイアドレスを割り当てることによって、ヌル状態からオフライン状態に変化する。典型的にはファームウエア、ソフトウエア、またはハードウエアという形で論理を実行することにより、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）が実行され、フィールドデバイスのデバイス識別に同一の物理デバイスタグが設定される。論理の実行はデバイスアドレス設定サービス（ＳＥＴ−ＡＤＤＲＥＳＳ）も使用し、スタンバイアドレスをフィールドデバイスに送信する。

状態遷移Ｔ２は、一時アドレスに常駐しているフィールドデバイスが、システム管理特定サービス（ＳＭ−ＩＤＥＮＴＩＦＹ）により照会されるイベントにより引き起こされ、問い合わせが、デバイスが、デバイスのデバイス識別に同一である物理デバイスタグを有していると判断する。状態遷移Ｔ２は、フィールドデバイスにスタンバイアドレスを割り当てることにより、ヌル(NULL）状態からオフライン状態に変化する。論理の実行は、デバイスアドレス設定サービス（ＳＥＴ−ＡＤＤＲＥＳＳ）を使用し、スタンバイアドレスをフィールドデバイスに送信する。

状態遷移Ｔ３は、一時アドレスに常駐しているフィールドデバイスが、システム管理特定サービス（ＳＭ−ＩＤＥＮＴＩＦＹ）により照会されるイベントにより引き起こされ、問い合わせが、デバイスが現在のプロセス制御システムネットワーク回線に構成されている物理デバイスタグおよびデバイス識別を有していると判断する。状態遷移Ｔ３は、割り当てられているアドレスをフィールドデバイスに送信するためにデバイスアドレス設定サービス（ＳＥＴ−ＡＤＤＲＥＳＳ）を利用する論理の実行を使用して、ヌル（ＮＵＬＬ）状態からオフライン状態に変化する。

状態遷移Ｔ４は、一時アドレスに常駐しているフィールドデバイスが、システム管理特性サービス（ＳＭ−ＩＤＥＮＴＩＦＹ）により照会されるイベントにより引き起こされ、問い合わせが、デバイスが現在のプロセス制御システムネットワーク回線に構成されている物理デバイスタグおよびデバイス識別を有していると判断する。状態遷移Ｔ４は、ヌル（NULL）状態から未認識状態に変化する。

状態遷移Ｔ５は、デバイスが一時アドレスに表示され、デバイスがユーザによって作動されているイベントにより引き起こされる。状態遷移Ｔ５は、オフライン状態から、フィールドデバイスの物理デバイスタグをクリアするために物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を実行する、典型的にはファームウエア、ソフトウエア、またはハードウエアの形を取る、論理の実行を使用するオフライン状態に変化する。論理の実行は、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）も実行し、割り当てられている物理デバイスタグをフィールドデバイスに送信する。論理の実行は、さらに、デバイスアドレス設定サービス（ＳＥＴ−ＡＤＤＲＥＳＳ）を使用して、割り当てられているアドレスをフィールドデバイスに送信する。

状態遷移Ｔ６は、デバイスが一時アドレスで表示され、デバイスの使用がユーザによって中止されているイベントによって引き起こされる。状態遷移Ｔ６は、オフライン状態から、フィールドデバイスの物理デバイスタグをクリアするために物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を実行する論理の実行を使用する、オフライン状態に変化する。

状態遷移Ｔ７は、ユーザが、使用が中止されたデバイスをスタンバイにすることを要求するイベントにより引き起こされる。状態遷移Ｔ７は、フィールドデバイスにスタンバイアドレスを割り当てることによって、オフライン状態からオフライン状態に変化する。論理の実行は、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を実行し、フィールドデバイスのデバイス識別に同一である物理デバイスを設定する。論理の実行は、スタンバイアドレスをフィールドデバイスに送信するためにデバイスアドレス設定サービス（SET−ADDRESS）も使用する。

状態遷移Ｔ８は、フィールドデバイスがスタンバイアドレスに表示されるイベントによって引き起こされる。状態遷移Ｔ８は、オフライン状態から、デバイス改訂情報をリソースブロックから読み取る論理の実行を通してスタンバイ状態に変化する。

状態遷移Ｔ９は、フィールドデバイスが割り当てられているアドレスで表示されるイベントにより引き起こされる。状態遷移Ｔ９は、オフライン状態から作動済み状態に変化する。

状態遷移Ｔ１０は、スタンバイ状態にあるデバイスを作動することを要求するユーザにより引き起こされる。状態遷移Ｔ１０は、スタンバイ状態から、デバイスアドレスをクリアするためにアドレスクリアサービス（CLEAR−ADDRESS）を使用する論理の実行を通してオフライン状態に変化する。

状態遷移Ｔ１１は、スタンバイ状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移Ｔ１１は、スタンバイ状態から、デバイスアドレスをクリアするためにアドレスクリアサービス（CLEAR−ADDRESS）を使用する論理の実行を通してオフライン状態に変化する。

状態遷移Ｔ１２は、作動済み状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移Ｔ１２は、作動済み状態から、デバイスアドレスをクリアするためにアドレスクリアサービス（CLEAR−ADDRESS）を使用する論理の実行を通してオフライン状態に変化する。

状態遷移Ｔ１３は、フィールドバスシステム管理状態の初期化されている（INITIALIZED）状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移Ｔ１３は、未認識状態から、フィールドデバイスの物理デバイスタグをクリアするために物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を実行する論理の実行を通して、オフライン状態に変化する。

状態遷移Ｔ１４は、フィールドバスシステム管理状態のシステム管理稼動（ＳＭ−OPERATIONAL）状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移Ｔ１４は、未認識状態から、デバイスアドレスをクリアするためにアドレスクリアサービスを使用する論理の実行を通して、オフライン状態に変化する。

フィールドバス規格に従って、適切に動作するためには、フィールドバスデバイスは、一意のデバイスアドレス（ネットワークアドレス）および位置の物理デバイスタグを有している。プロセス制御システムネットワークリンクに接続されている各デバイスは、一意のノード指名子を有している。データリンク仕様は、恒久デバイスの範囲、一時アドレスの範囲、および訪問者（visitor）デバイスの範囲を含む、ノード指名子の許容値の範囲を指定する。一時アドレスは、現在、システム管理稼動（ＳＭ−OPERATIONAL）状態にないデバイスによって使用される。フィールドバスインタフェースは、恒久デバイス用のアドレス空間の３つのセットへの区分化を維持する。「割当て済みアドレス」と呼ばれている１つのセットは、デバイスがバス上に存在するのかどうかに関係なく、特定物理デバイスタグ付きのデバイスに割当て済みアドレスを含む。割当て済みアドレスは、Link−Active−Scheduler管理権取得（takeover）優先順位に関係する、ユーザにより入力される情報に基づいてソフトウエアエンジニアリングツールを使用して割り当てられる。「スタンバイアドレス」と呼ばれている第２セットは、システム管理稼動（ＳＭ−OPERATIONAL）状態にあるデバイスを記述するが、デバイスアドレスは割り当てられていない。スタンバイアドレスは、フィールドバスインタフェースによって管理される。アドレスの第３セットは、第１セットと第２セットの外側のアドレスであり、未使用アドレスを参照する。

少数の一時アドレスが自動検出およびオンラインアドレス割当てを複雑にする。スタンバイアドレスは、自動検出およびオンラインアドレス割当て動作の機能性をサポートするために定義され、活用される。割当て済みアドレスセットおよびスタンバイアドレスセットは、プロセス制御システムネットワークリンクへ接続されている潜在的なデバイスの数に等しく設定される。例えば、１６のデバイスが、潜在的にプロセス制御システムネットワークに接続されると、１６の割当て済みアドレスが定義され、１６のスタンバイアドレスが定義される。

デバイス改訂情報は、製造業社の識別（MANUFAC−ＩＤ）、デバイス型（ＤＥＶ−ＴＹＰＥ）、デバイス改訂（ＤＥＶ−ＲＥＶ）、およびデバイス記述改訂（ＤＤ−ＲＥＶ）を含む。

オフライン状態２９０２では、フィールドデバイスは、最近、プロセス制御システムネットワークに接続されるか、あるいは作動されているまたは使用が中止されている過程にある。オフライン状態２９０２は、複数のパラメータ組み合わせを有しているデバイス状態を含む。第１オフライン状態２９０２では、システム管理状態は初期化されていない（UNITIALIZED）状態であり、物理デバイスタグがクリアされる。第２オフライン状態２９０２では、システム管理状態は初期化されている（INITIALIZED）状態であり、物理デバイスタグが物理デバイスから読み取られ、画面上で表示できる。オフライン状態２９０２のどちらにおいても、デバイスアドレスは一時アドレスであり、改訂情報は入手可能ではなく、デバイス識別はデバイスから読み取られ、画面上に表示可能である。

未認識状態２９０４では、フィールドデバイス物理デバイスタグおよびデバイス識別は、プロセス制御システムネットワークに接続されているデバイスのために作動されている（commissioned）値と一致しない。第１未認識状態２９０４では、システム管理状態は、一時アドレスであるデバイスアドレスによる初期化されている（INITIALIZED）状態である。第２未認識状態２９０４では、システム管理状態は、スタンバイアドレスまたは割当て済みアドレスであるデバイスアドレスによりシステム管理稼動（ＳＭ−OPERATIONAL）状態である。どちらの未認識状態２９０４においても、物理デバイスタグは、デバイスから読み取られ、画面に表示することができ、デバイス改訂は使用可能ではなく、デバイス識別はデバイスから読み取られ、画面上に表示可能である。

スタンバイ状態２９０６では、フィールドデバイスは、まだ自動検知されておらず、したがってコントロールストラテジーでの構成には使用できない、あるいはリンクアクティブスケジューラ（ＬＡＳ）スケジュールの中に含まれていない。スタンバイ状態２９０６では、ファンクションブロック実行およびリンク通信がディスエーブルされている。リンクアクティブスケジューラは、周期的に伝送されなければならない全デバイス内でのすべてのデータバッファの伝送時間のリストを含む、決定的な集中バススケジューラである。デバイスがデータバッファを送ることになっているとき、リンクアクティブスケジューラはデバイスにデータ強制（ＣＤ）メッセージを発行する。ＣＤメッセージの受領時、デバイスはバッファ内のデータを一斉送信するか、フィールドデバイスバス上のすべてのデバイスに公表し、一斉送信デバイスは「公表者」であるように定義される。データを受信するように構成されているデバイスは「加入者」である。予定を立てられているデータ転送は、典型的には、フィールドバス上のデバイス間での制御ループデータの定期的、周期的な転送に使用される。

スタンバイ状態２９０６では、システム管理状態はシステム管理稼動（ＳＭ−OPERATIONAL）状態であリ、物理デバイスタグはデバイス識別に等しく、デバイスアドレスはスタンバイアドレスである。デバイス改訂情報は、フィールドデバイスから読み取られ、表示することができる。

未結合状態２９１０は、その後、物理的に接続されることになるフィールドデバイス用の構成位置設定記号である。未結合状態２９１０は、まだ接続されていないフィールドデバイス内でファンクションブロックを活用するコントロールストラテジーの構成をサポートする。未結合状態２９１０では、システム管理状態は、まだ適用できないが、物理デバイスタグはユーザによって指定されており、デバイスアドレスはユーザによって指定される。デバイス改訂情報は、最近の作動または構成に従って設定される。デバイス識別はクリアされる。

作動済み状態２９０８では、フィールドデバイスは、コントロールストラテジー構成およびインストールに利用できる。システム管理状態はシステム管理稼動（ＳＭ−OPERATIONAL）状態であり、物理デバイスタグはユーザによって指定されており、デバイスアドレスはユーザにより割り当てられる。デバイス改訂情報は、フィールドデバイスから読み取られ、画面上に表示できる。デバイス識別はフィールドデバイスから読み取られ、フィールド構成データベースに記憶され、表示画面で表示できる。

複数の動作または「使用ケース」が、フィールドデバイスの作動および使用の中止を制御するために定義される。

図３０を参照すると、フローチャートが、第1動作、つまり新規デバイス３０００の作動の動作を記述する「使用ケース」を示している。新規デバイスの作動の前に、フィールドバスインタフェースは稼動中である。デバイスはプロセス制御システムネットワークに接続されている。デバイスは、物理デバイスタグを有していないか、デバイス識別に等しい物理デバイスタグを有しているのどちらかである。

新規デバイス３０００を作動する動作の結果、デバイスに新規物理デバイスタグとデバイスアドレスが割り当てられ、デバイスがファンクションブロック構成に準備完了している状態を生じさせる。新規フィールドデバイスは、プロセス制御システムネットワークデータベースに入力され、デバイス識別は結合され、デバイス改訂情報は設定されている。プロセス制御システムネットワークステータスを表示するエンジニアリングソフトウエアツールは、作動済み（COMMISSIONED）デバイスとして新規デバイスを表示する。

第1ステップ３００２では、フィールドデバイスは、一時アドレスで「ライブリスト」中に表示される。「ライブリスト」とは、パストークン（ＰＴ）メッセージに適切に応答しているすべてのデバイスのリストのことである。フィールドバス上のすべてのデバイスは、予定されているメッセージの伝送の間に予定されていないメッセージを送信することが許されている。リンクアクティブスケジューラは、デバイスにパストークン（ＰＴ）メッセージを発行することにより、デバイスにフィールドバスを使用する許可を与える。デバイスは、ＰＴを受け取ると、メッセージが完了するまで、あるいは最大配信（allotted）トークン保持時間が時間切れになるまでメッセージを送信することを許される。最高優先順位活動として、リンクアクティブスケジューラが、周期的に発生するように設定される動作のリストを包含しているＣＤスケジュールにアクセスする。予定された時刻に、リンクアクティブスケジューラは、フィールドバスデバイス内の特定のデータバッファにデータ強制（ＣＤ）メッセージを送信する。デバイスは、ただちにメッセージをフィールドバス上のすべてのデバイスに一斉送信する。リンクアクティブスケジューラは、予定されている転送の間に残りの動作を実行する。リンクアクティブスケジューラは、ライブリストに記載されていないアドレスに定期的にプローブノード（ＰＮ）メッセージを送信することにより、継続して新しいデバイスをフィールドバスに追加する。デバイスがアドレスに存在し、ＰＮを受信すると、デバイスはただちにプローブ応答（ＰＲ）メッセージを返す。デバイスがＰＲメッセージで応答すると、リンクアクティブスケジューラはデバイスをライブリストに追加し、デバイスにノード起動（ＮＡ）メッセージを送信することにより確認する。デバイスは、ＰＴに適切に応答する限りライブリストに残る。デバイスが追加されたり、ライブリストから削除されると、リンクアクティブスケジューラは、ライブリストに対する変更をすべてのデバイスに一斉送信し、各デバイスがライブリストの最新のコピーを保持できるようにする。

第２ステップ３００４では、インタフェースは、システム管理識別サービス（ＳＭ−IDENTIFY）を使用してフィールドデバイスを照会し、フィールドデバイスが物理デバイスタグが設定されている初期化されていない（UNINITIALIZED）状態にあるのか、あるいはデバイス識別に等しい物理デバイスタグを有している、初期化されている（INITIALIZED）状態にあるのかを判断する。それから、インタフェースは、フィールドデバイスにスタンバイアドレスを割り当てる（ステップ３００６）。

論理ステップ３００８は、過去に初期化されていない未初期化（UNITIALIZED）デバイスが、ステップ３０１０で、設定されている物理デバイスタグサービス（ＳＥＴ−ＰＤ−ＴＡＧ）を使用してデバイス識別に同一のフィールドデバイスの物理デバイスタグを設定し、それによりフィールドデバイスを初期化されている（INITIALIZED）状態にすることを命令する。スタンバイアドレスは、アドレス設定サービス（ＳＥＴ−ADDRESS）を使用してフィールドデバイス３０１２に送信され、フィールドデバイスを初期化されている状態（INITIALIZED状態）からシステム管理稼動（ＳＭ−OPERATIONAL）状態に進める。この時点で、フィールドデバイスは、スタンバイアドレス３０１４で「ライブリスト」に表示される。デバイス改訂情報は、リソースブロック３０１６から読み取られる。ステップ３０１８では、実行中のソフトウエアエンジニアリングツールがフィールドデバイスをスタンバイ（STANDBY）デバイスとして表示する。

ステップ３０２０では、新規ユーザが、新規物理デバイスタグをフィールドデバイスに割り当てる。物理デバイスタグは、一意であり、デバイス識別とは同じではないように制約される。物理デバイスタグの割当て中、デバイスアドレスは、ソフトウエアエンジニアリングツールを使用してフィールドデバイスに割り当てられ、リンクアクティブスケジューラ管理権取得優先順位は「選択可能」に設定される。デバイス改訂情報は、フィールドデバイスから読み取られ、プロセス制御システムネットワークデータベースに書込まれる。インタフェースは、アドレスクリアサービス（ＣLEAR−ADDRESS）を使用して、フィールドデバイス３０２２の状態を初期化されている（INITIALIZED）状態に変更する。フィールドデバイスは、一時アドレス３０２４で「ライブリスト」に表示される。

ステップ３０２６では、インタフェースは、システム管理識別サービス（ＳＭ−IDENTIFY）を使用してフィールドデバイスを照会し、デバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を使用し、物理デバイスタグ３０２８をクリアし、それによってフィールドデバイス状態を初期化されていない（UNINITIALIZED状態に変更する。それから物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）が使用され、割当て済み物理デバイスタグをフィールドデバイス３０３０に送信し、フィールドデバイス状態を初期化されている（INITIALIZED）状態に変更する。アドレス設定サービス（ＳＥＴ−ADDRESS）が呼び出され、割当て済みアドレスをフィールドデバイス３０３２に送信し、フィールドデバイスをシステム管理稼動（ＳＭ−OPERATIONAL）状態にする。フィールドデバイスは、割当て済みアドレス３０３４で「ライブリスト」に表示される。プロセス制御システムネットワークデータベースでは、デバイス識別はデバイスに結合される（ステップ３０３６）。ソフトウエアエンジニアリングツールは、フィールドデバイスを作動済み（COMMISSIONED）デバイスとして表示する。

図３１を参照すると、フローチャートは、第２動作、つまり未結合デバイス３１００を作動する動作を記述する「使用ケース」を示している。未結合デバイスの作動前、フィールドバスインタフェースは稼動中である。フィールドデバイスがプロセス制御システムネットワークデータベースで作成され、物理デバイスタグおよびデバイスアドレスがフィールドデバイスに割り当てられる。ただし、フィールドデバイスはデバイス識別には結合されていない。プロセス制御システムネットワークデータベースも、フィールドデバイスから読み取られるデバイス改訂情報を記憶するために初期化される。ソフトウエアエンジニアリングツールは、フィールドデバイスを未結合デバイスとして表示する。作動される未結合デバイスは、物理デバイスタグが設定されていないフィールドデバイス、あるいはデバイス識別に同一である物理デバイスを有しているフィールドデバイスのどちらかである。未結合デバイスが作動され、プロセス制御システムネットワークリンクにフィールドデバイスを配置する。

未結合デバイス３１００を作動する動作の結果、デバイスが物理デバイスタグおよび割当て済みデバイスアドレスを設定され、デバイスがファンクションブロック構成に準備完了している状態が生じる。新規フィールドデバイスは、デバイス識別が結合している状態でプロセス制御システムネットワークデータベースに入れられる。プロセス制御システムネットワークステータスを表示するエンジニアリングソフトウエアツールは、デバイスを作動済み（COMMISSIONED）デバイスとして表示する。

第1ステップ３１０２では、フィールドデバイスは、一時アドレスで「ライブリスト」に表示される。第２ステップ３１０４では、インタフェースは、システム管理識別サービス（ＳＭ−IDENTIFY）を使用してフィールドデバイスを照会し、フィールドデバイスが、物理デバイスタグが設定されていない初期化されていない状態にあるのか、それともデバイス識別に等しい物理デバイスを有している初期化されている状態にあるのかを判断する。それから、インタフェースは、３１０６にフィールドデバイスのスタンバイアドレスを割り当てる。

論理ステップ３１０８は、過去に初期化されていないデバイスが、ステップ３１１０で、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を使用して、デバイス識別に同一のフィールドデバイスの物理デバイスタグを設定し、それにより、フィールドデバイスを初期化されている状態にすることを命令する。スタンバイアドレスが、アドレス設定サービス（ＳＥＴ−ADDRESS）を使用してフィールドデバイス３１１２に送信され、フィールドデバイスを初期化されている状態からシステム管理稼動状態に進める。この時点で、フィールドデバイスは、スタンバイアドレス３１１４で「ライブリスト」に表示される。デバイス改訂情報は、リソースブロック３１１６から読み取られる。ステップ３１１８では、実行中のソフトウエアエンジニアリングツールがフィールドデバイスをスタンバイ（STANDBY）デバイスとして表示する。

ステップ３１２０では、ユーザは、フィールドデバイスを事前構成デバイスと関連付けることにより、物理デバイスタグをフィールドデバイスに割り当てる。デバイス改訂情報はフィールドデバイスから読み取られ、情報が、事前構成デバイス用のプロセス制御システムネットワークデータベース内のデバイス改訂情報と一致することを確かめる。デバイスのデバイス改訂情報がデータベースと一致しない場合、ユーザは、データベースを無効にし、デバイス改訂情報をフィールドデバイスから読み取り、情報をプロセス制御システムデータベースに書き込んでよい。代わりに、未結合デバイスのデバイス改訂情報は、ブランクのままにされ、任意の物理デバイスを未結合デバイスと結合できるようにする。インタフェースは、アドレスクリアサービス（CLEAR−ADDRESS）を使用して、フィールドデバイス３１２２の状態を初期化されている（INITIALIZED）状態に変更する。フィールドデバイスは、一時アドレス３１２４で、「ライブリスト」に表示される。

ステップ３１２６では、インタフェースは、システム管理識別サービス（ＳＭ−IDENTIFY）を使用して、フィールドデバイスを照会し、デバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を使用し、物理デバイスタグ３１２８をクリアし、それによってフィールドデバイス状態を初期化されていない（UNITIALIZED）状態に変更する。それから、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）が使用され、割当て済み物理デバイスタグをフィールドデバイス３１３０に送信し、フィールドデバイス状態を初期化されている（INITIALIZED）状態に変更する。アドレス設定サービス（ＳＥＴ−ADDRESS）が呼び出され、割当て済みアドレスをフィールドデバイス３１３２に送信し、フィールドデバイスをシステム管理稼動（ＳＭ−OPERATIONAL）状態にする。フィールドデバイスは、割り当てられているアドレス３１３４で「ライブリスト」に表示される。プロセス制御システムネットワークデータベースでは、デバイス識別は、デバイスに結合される３１３６。ソフトウエアエンジニアリングツールは、フィールドデバイスを作動済み（COMMISSIONED）デバイスとして表示する。

図３２を参照すると、フローチャートは、第３動作、つまりデバイス３２００の使用を中止する動作を記述する「使用ケース」を示している。フィールドデバイスは、複数の理由から使用が中止される。例えば、フィールドバスデバイスが時代遅れであるとき、プロセス制御システムがもはや時代遅れのデバイス上でリソースを使い尽くさないように、ユーザが、機能していない分岐のネットワーク相互接続構造のクリアを希望することがある。また、ユーザが、フィールドバスデバイスが誤動作しており、ネットワーク相互接続構造のセグメントの動作を劣化させていると疑っていることがある。ユーザは、プロセス制御システムに疑われているフィールドバスデバイスを一次的に無視させ、セグメント内の残りのデバイスが適切に動作するかどうかを確認することにより、問題を診断することがある。

デバイスの使用を中止する動作の前に、フィールドバスインタフェースおよびフィールドデバイスは稼動中であり、フィールドデバイスは、割当て済みアドレスまたはスタンバイアドレスでライブリストに表示される。ソフトウエアエンジニアリングツールは、フィールドデバイスを作動済み（COMMISSIONED）またはスタンバイ（STANDBY）デバイスとして表示する。ソフトウエアエンジニアリングツールは、例えば、ファンクションブロックタグをクリアし、OPERATIONAL−POWERUPフラグをクリアすることによって、フィールドデバイスを使用中止に備えるルーチンを実行する。

デバイスの使用を中止する動作の結果、フィールドデバイスの物理デバイスタグがクリアされ、フィールドデバイスがプロセス制御システムネットワークリンクからの削除に備えている状態が生じる。フィールドデバイスのプロセス制御システムネットワークデータベースエントリは、デバイス識別を、未結合状態にあるとして示す。ソフトウエアエンジニアリングツールは、デバイス識別を未結合デバイスとして表示し、物理デバイスをOFFLINEデバイスとして表示する。

ユーザが、フィールドデバイス３２０２の「使用中止」動作を選択すると、デバイス３２００の使用を中止する動作が開始する。グラフィックユーザインタフェースは、プロセス制御システム内の適切な制御装置に「使用中止（Decommission）」コマンドを発行するソフトウエアエンジニアリングツールを含む。使用中止コマンドは、ターゲットＩ／Ｏサブシステム、カードとポートの識別子、および使用中止されるフィールドデバイスのデバイス識別を指定する。同じ物理デバイスタグが設定されている別のデバイスが、未識別（UNRECOGNIZED）状態で存在することがあるため、デバイス識別が指定される。インタフェースは、アドレスクリアサービス（CLEAR−ADDRESS）を使用して、フィールドデバイス３２０４の状態を初期化されていない（INITIALIZED）状態に変更する。フィールドデバイスは、一時アドレス３２０６で「ライブリスト」に表示される。

ステップ３２０８では、インタフェースは、システム管理識別サービス（ＳＭ−IDENTIFY）を使用してフィールドデバイスを照会し、物理デバイスタグおよびデバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を使用し、物理デバイスタグ３２１０をクリアし、それによってフィールドデバイス状態を初期化されていない（UNITIALIZED）状態に変更する。

プロセス制御システムネットワークデータベースでは、デバイス識別は未結合であり、ソフトウエアエンジニアリングツールはフィールドデバイスを未結合デバイス３２１２として表示する。次のステップ３２１４では、ソフトウエアエンジニアリングツールは、フィールドデバイスをオフライン（OFFLINE）デバイスとして表示する。

ネットワークインタフェースカードは、フィールドデバイスの使用が中止された旨の指示を記憶し（ステップ３２１６）、ユーザによって命令されない限り、フィールドデバイスをスタンバイ（STANDBY）状態に移さない。使用中止されたデバイスがスタンバイ（STANDBY）アドレスに移動されない場合、インタフェースカードは、フィールドデバイスがライブリストから離れて進む（advances off）まで、フィールドデバイスを追跡調査する。

図３３を参照すると、フローチャートは、第４動作、つまり稼動電源投入を使用可能（enablement）としないで作動済みデバイス３３００を接続する動作を記述する「使用ケース」を示している。作動済みデバイス３３００を接続する動作の前、フィールドバスインタフェースは稼動中である。フィールドバスインタフェースの構成は、接続されている状態にあるフィールドデバイスを含む。フィールドデバイスの物理デバイスタグおよびデバイス識別が付き合わされる。作動済みデバイス３３００を接続する動作の後、フィールドデバイスには割当て済みアドレスがある。

フィールドデバイスは、一時アドレス３３０２で「ライブリスト」に表示される。ステップ３３０４では、インタフェースが、システム管理識別サービス（ＳＭ−IDENTIFY）を使用してフィールドデバイスを照会し、フィールドバスインタフェース構成の一部としての物理デバイスタグおよびデバイス識別によりフィールドデバイスを認識する。アドレス設定サービス（ＳＥＴ−ADDRESS）が呼び出され、割当て済みアドレスをフィールドデバイス３３０６に送信し、フィールドデバイスをシステム管理稼動（ＳＭ−OPERATIONAL）状態にする。フィールドデバイスは、割当て済みアドレス３３０８で「ライブリスト」に表示される。

図３４を参照すると、フローチャートは、第５動作、つまりデバイス３４００を置換する動作を記述する「使用ケース」を示している。デバイスは、可能であるならば、プロセス制御システムネットワークリンクに接続されているカレントフィールドデバイス３４０２の使用を中止し、未結合デバイス３４０４への置換を作動することにより置換される。カレントフィールドデバイス３４０２の使用を中止するステップは、図３２に関して詳細に記述される。未結合デバイス３４０４への置換を作動するステップは、図３１に関して記述される。

図３５を参照すると、フローチャートは、第６動作、つまり未認識デバイス３５００を接続する動作を記述する「使用ケース」を示している。作動済みデバイス３３００を接続する動作の前、フィールドバスインタフェースは稼動中である。現在のプロセス制御システムネットワークリンク用に構成されていない物理デバイスタグおよびデバイス識別を有しているフィールドデバイスが接続される。未認識デバイス３５００を接続する動作の後、フィールドデバイスは識別され、ソフトウエアエンジニアリングツールはデバイスを未認識デバイスとして表示する。未認識デバイス３５００を接続する動作は、ソフトウエアエンジニアリングツールを使用しなくても実行してよい。

フィールドデバイスは、「ライブリスト」３５０２に表示される。ステップ３５０４では、インタフェースは、システム管理識別サービス（ＳＭ−ＩＤＥＮＴＩＦＹ）を使用してフィールドデバイスを照会し、物理デバイスタグおよびデバイス識別が、現在の構成でのフィールドデバイスに一致しないと判断する。

図３６を参照すると、フローチャートは、第７動作、つまり未認識デバイス３６００の使用を中止する動作を記述する「使用ケース」を示している。未認識デバイスの使用を中止する動作の前、フィールドバスインタフェースは稼動中である。現在のプロセス制御システムネットワークリンク用に構成されていない物理デバイスタグおよびデバイス識別を有しているフィールドデバイスが識別される。ソフトウエアエンジニアリングツールは、未識別デバイスとしてフィールドデバイスを表示する。

未認識デバイス３６００の使用を中止する動作の結果、フィールドデバイスの物理デバイスタグがクリアされ、フィールドデバイスが、プロセス制御システムネットワークリンクからの削除に備えている状態が生じる。ソフトウエアエンジニアリングツールは、フィールドデバイスをオフラインデバイスとして表示する。

ユーザがフィールドデバイス３６０２に「使用中止」動作を選択すると、未認識デバイス３６００の使用を中止する動作が開始する。グラフィックユーザインタフェースは、プロセス制御システム内の適切な制御装置に「使用中止」コマンドを発行するソフトウエアエンジニアリングツールを含む。使用中止コマンドは、ターゲットＩ／Ｏサブシステム、カードとポートの識別子、および使用中止されるフィールドデバイスのデバイス識別を指定する。

フィールドデバイスが初期化されている状態にある場合、論理ステップ３６０４は、物理デバイスタグクリアステップ３６１２に対し、使用中止動作３６００を命令する。それ以外の場合、インタフェースは、アドレスクリアサービス（CLEAR−ADDRESS）を使用して、フィールドデバイス３６０６の状態を初期化されている状態に変更する。フィールドデバイスは、一時アドレス３６０８で「ライブリスト」に表示される。

ステップ３６１０では、インタフェースは、システム管理識別サービス（ＳＭ−IDENTIFY）を使用してフィールドデバイスを照会し、物理デバイスタグおよびデバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）を使用し、物理デバイスタグ３６１２をクリアし、それによって、フィールドデバイス状態を初期化されていない状態に変更する。次のステップ３６１４では、ソフトウエアエンジニアリングツールが、フィールドデバイスをオフライン（OFFLINE）デバイスとして表示する。

ネットワークインタフェースカードは、フィールドデバイスの使用が中止された旨の指示を記憶し（ステップ３６１６）、ユーザにより命令されない限り、フィールドデバイスデバイスをスタンバイ状態に移さない。使用が中止されたデバイスがスタンバイアドレスに移動されない場合、インタフェースカードは、フィールドデバイスがライブリストから離れて進む（advances off）までフィールドデバイスを追跡調査する。

図３７を参照すると、フローチャートは、第８動作、つまり使用が中止されたデバイスをスタンバイ状態にする動作３７００を記述する「使用ケース」を示している。使用が中止されたデバイスをスタンバイ状態にする動作３７００の前、フィールドバスインタフェースは稼動中である。フィールドデバイスの使用は中止され、オフライン状態にある。

使用が中止されたデバイスをスタンバイにする動作３７００の結果、フィールドバスが、フィールドデバイスの物理デバイスタグがデバイス識別に同一に設定され、スタンバイアドレスに配置される状態が生じる。ソフトウエアエンジニアリングツールは、フィールドデバイスをスタンバイデバイスとして表示する。

ユーザがフィールドデバイス３７０２に「スタンバイにする」動作を選択すると、使用が中止されたデバイスをスタンバイ３７００にする動作が開始する。グラフィックユーザインタフェースは、プロセス制御システム３７０４内で適切な制御装置に「スタンバイにする」コマンドを発行するソフトウエアエンジニアリングツールを含む。使用中止コマンドは、ターゲットＩ／Ｏサブシステム、カードとポートの識別子、およびスタンバイにされるフィールドデバイスのデバイス識別を指定する。

インタフェースは、フィールドデバイスにスタンバイアドレス３７０６を割り当てる。それから、物理デバイスタグ設定サービス（ＳＥＴ−ＰＤ−ＴＡＧ）が使用され、デバイス識別３７０８と同一の物理デバイスタグを設定し、フィールドデバイス状態を初期化されている状態に変更する。アドレス設定サービス（ＳＥＴ−ADDRESS）が呼び出され、スタンバイアドレスをフィールドデバイス３７１０に送信し、フィールドデバイスをシステム管理稼動（ＳＭ−OPERATIONAL）状態にする。フィールドデバイスは、スタンバイアドレス３７１２で「ライブリスト」に表示される。デバイス改訂情報は、リソースブロック３７１４から読み取られる。ステップ３７１６では、実行中のソフトウエアエンジニアリングツールが、フィールドデバイスをスタンバイデバイスとして表示する。

ユーザは、それ以降、新規デバイスを作成するか、あるいはフィールドデバイスをプロセス制御システムネットワークデータベース内の未結合デバイスに結合することによって、フィールドデバイス３７１８を作動してよい。デバイスを作動する技法は、図３０および図３１に関して説明される。

以下、本発明の他の実施形態として、構成プログラムに関する実施形態を図３８乃至図３９Ｅを例示する。
図３８を参照すると、概略ブロック図が、複数の制御言語を使用してプロセス構成を定義するためのプロセス制御構成プログラムのプログラム構造を示している。モジュールエディタ３８２０は、エンジニアリングワークステーション１０６などのワークステーション内のＣＰＵ１１６で実行するソフトウエアプログラムである。モジュールエディタ３８２０を使用して、ユーザは、属性エディタプログラム３８３０、ファンクションブロック編集／閲覧／デバッグプログラム３８４０、シーケンシャルファンクションチャートプログラム３８５０、はしご型論理プログラム３８７０、およびストラクチャードテキストプログラム３８９０を含む、複数の制御言語の１つの言語エディタを起動する。複数の制御言語エディタは、異なる制御言語エディタを使用して、１つの共通したコントロールストラテジーが定義されるように、互換性のあるデータベースおよびインタフェースとともに動作する。異なる制御言語エディタの画面表示の外観は、ユーザが、容易にかつ効率的に異なる目的のためにさまざまなエディタを使用し、言語のさまざまな態様を最大限に活用できるように類似している。

モジュールエディタ３８２０は、構成エントリ用の根本的なルーチンであり、ＳＰ８８規格により定義されている制御モジュールインスタンスおよび装置モジュールインスタンス、およびライブラリモジュールを作成、編集、および再利用するために使用される。モジュールエディタ３８２０は、コントロールストラテジーを形成する複数のモジュールを構成、視覚化、およびナビゲーションするためのグラフィック技法を供給する。モジュールエディタ３８２０は、モジュールリンクおよびモジュール包含（containment）を定義するためにも使用される。

モジュールエディタ３８２０は、警報、イベント、履歴、状態、ヘルプ、構成要素および属性に関する情報収集だけではなく、アルゴリズム定義に対するサポートを含むモジュールの構成のすべての側面へのアクセスを供給する。

モジュールエディタ３８２０は、制御システムを通してナビゲーションを容易にする多様な機能を含む。例えば、モジュールエディタ３８２０は、ユーザ定義キーワードに関する属性をフィルタリングし、焦点が定められた属性構成ビューを供給する。さらに、モジュールエディタ３８２０は、デフォルトで、モジュールに対する変更によって影響を受けるすべてのデバイスへのインストールを実行する高速インストール機能を含む。コントロールストラテジーは、インストールスクリプトを使用して、エディタから実行時エンジンの中に転送される。複数の制御言語実行エンジンが、１つまたは複数の制御装置／マルチプレクサ１１０でコントロールストラテジーを実現する。

オフライン構成は、既存のモジュールのコントロールストラテジーに対する「進行中の作業（work in progress）」をサポートする。新規ストラテジーが完了すると、それは既存のモジュールにインストールできる。この「進行中の作業」は、そのインストールを許可しないためにフラグを立てることができる。

属性エディタプログラム３８３０は、ファンクションブロック、はしご、複合物等を含む、制御モジュールまたは制御アルゴリズムの要素に関連付けられているパラメータ値を表示し、編集するために、ユーザによって操作される制御プログラムである。属性エディタプログラム３８３０は、オンラインで使用され、制御モジュールを構成する。オンラインでは、属性エディタプログラム３８３０は、データを表示し、編集するために使用される。属性は、モジュールレベルアクセスをモジュール内に包含されているパラメータに与えるように定義される。属性エディタプログラム３８３０は、モジュールエディタ３８２０およびそれ以外の制御言語エディタによって起動される。属性エディタプログラム３８３０は、グラフィックナビゲーションツリー経路ディスプレイを使用して、簡略属性構成ビューを提示し、モジュールのために構成されるパラメータを整理統合する（consolidate）。ユーザは、属性エディタプログラム３８３０を起動し、グラフィックナビゲーションツリーを通してナビゲーションし、ある特定の属性を発見する。属性が選択されると、属性は、ディスプレイが喚起されるコンテキストに応じて、アプリケーションウィンドウを使用して、あるいはダイアログとして表示される。属性エディタプログラム３８３０は、ドラッグアンドドロップ技法を使用して、属性のコピー、貼り付け、およびバルク（bulk）変更をサポートすることにより構成を容易にする。属性を包含しているモジュールがインストールされると、属性がインストールされるため、属性エディタプログラム３８３０は、属性パラメータ値を定義するためには使用されるが、属性をインストールするためには使用されない。属性パラメータ値は、ユーザにより入力されるに従って、属性エディタプログラム３８３０がエラーチェックを実行する。属性エディタプログラム３８３０によって、ユーザは、列の数の拡大と削減を含む典型的なスプレッドシート機能をもって、あるいは包含によってデータを並べ替え、表示できるようになる。

ファンクションブロック（エディタ／ビュー／デバッグ）プログラム３８４０は、フィールドバス財団（Fieldbus Foundation）およびＩＥＣ１１３１−３規格の元で指定されているファンクションブロック要素をアセンブルすることによりコントロールストラテジーを定義するためにユーザにより操作される制御プログラムである。ファンクションブロックプログラム３８４０は、制御装置／マルチプレクサ１１０内で動作するファンクションブロック実行エンジン内で実現される。ファンクションブロック実行エンジンは、ファンクションブロックライブラリ（Function Block Library）３８４２を使用してファンクションブロック制御アルゴリズムを実行する。ファンクションブロックプログラム３８４０は、ファンクションブロックライブラリ（Function Block Library）３８４２内に記憶されているファンクションブロック、およびそれ以外の定義済み制御モジュール、例えば他のアプリケーションプログラムによる使用のために定義されている制御モジュールを使用して、コントロールストラテジーを作成、編集および再利用するためのグラフィックエディタを供給する。作成されるコントロールストラテジーは、それ以降の使用、または別のアプリケーションプログラムによる使用のために、再利用可能ライブラリ構成要素としてファンクションブロックライブラリ（Function Block Library）３８４２内に保存される。ファンクションブロックプログラム３８４０は、HARTおよびＦＦタイミングフィールドデバイス用の制御構造も作成、編集、および再利用する。コントロールストラテジーのファンクションブロックおよびモジュール構成要素は、ある特定のデバイスに限られるのではなく、ＨＡＲＴおよびＦＦタイミングフィールドデバイスを含む、複数の制御デバイス全体でむしろ区切られている。

ファンクションブロックまたはモジュールは、ファンクションブロックプログラム３８４０を使用して修正される属性を含む。システム内の属性は、機密保護されていない限り、その属性のためのナビゲーションツリー経路を通してアクセスされ、ファンクションブロックエディタから書き出される。

ファンクションブロック（エディタ）プログラム３８４０は、モジュールおよび再利用可能なライブラリ構成要素のコントロールストラテジーのために、オフライン作成およびデバッグ機能をサポートする。オフライン動作中、制御装置はネットワークに接続されていない。オフライン動作中、複数のコントロールストラテジーが開かれ、構成がストラテジー間でコピーされ、貼り付けられることがあるため、オフライン動作は、制御装置が、ファンクションブロック（エディタ）プログラム３８４０の属性エディタ３８４２を使用して接続される前に、属性およびパラメータを初期化するのに有効である。

ファンクションブロックエディタプログラム３８４０は、ブロック入力値および出力値の表示を含む、動作中のファンクションブロックのオンライングラフィック編集、表示およびデバッグもサポートする。選択式オンライン編集およびデバッグモードオプションは、例えば、単一ステップ、強制入力、およびブレークポイントオプションを含む。ユーザが適所にある矛盾しているパラメータ値を訂正できるように、オンライン編集およびデバッグには１つのウィンドウが使用される。オンライン編集中の入力値は、オフライン編集値との一貫性があるかチェックされ、矛盾する場合には却下される。

ファンクションブロックエディタプログラム３８４０により作成されるハードコピー出力情報は、ブロック属性およびパラメータ値のようなグラフィック表記および構成情報を含む。

ファンクションブロックプログラム３８４０の複数の機能は、再利用可能ライブラリ構成要素、ユーザ返還サポート、および入力エラーチェックを含む、ユーザサポートを容易にする。ステップ動作内でのユーザ変換サポートは、ユーザが、応答が設定されるポップアップダイアログを構成できるようにする。再利用可能ライブラリ構成要素は、単一ファンクションブロックダイアグラム（ＦＢＤ）が、実行中に、複数のモジュールまたはＦＢＤに対するサブルーチンとして動作するように、構成および実行の間のエンジニアリングを簡略化するために開発される。

シーケンシャルファンクションチャート（編集／閲覧／デバッグ）プログラム３８５０は、ＩＥＣ１１３１−３規格の元で指定されているステップ、ステップ動作、および遷移をアセンブルすることによりコントロールストラテジーを定義するために、ユーザにより操作される制御プログラムである。シーケンシャルファンクションチャートプログラム３８５０は、制御装置／マルチプレクサ１１０内で動作する、ＳＦＣ実行エンジン内で実現される。ＳＦＣ実行エンジンは、ステップ、動作、および遷移を含む、シーケンシャルファンクションチャート制御アルゴリズムを実行する。シーケンシャルファンクションチャートプログラム３８５０は、シーケンシャルファンクションチャートを使用してコントロールストラテジーを作成、編集および再利用するためのグラフィックエディタを供給する。シーケンシャルファンクションチャートプログラム３８５０は、並行論理経路の実行をサポートする。シーケンシャルファンクションチャートの実行は、少なくともＳＦＣ実行の期間中、１つのモジュールと関連付けられている。

シーケンシャルファンクションチャートは、シーケンシャルファンクションチャートプログラム３８５０を使用して修正される属性を含む。システム内の属性は、機密保護されていない限り、シーケンシャルファンクションチャート実行でのステップからアクセスされる。

シーケンシャルファンクションチャートプログラム３８５０は、モジュールのコントロールストラテジーのためにオフライン作成デバッグ機能をサポートする。オフライン動作中、制御装置は、ネットワークに接続されていない。オフライン動作中、複数のコントロールストラテジーが開かれ、構成がストラテジー間でコピーされ、貼り付けられることがあるため、オフライン動作は、制御装置が、シーケンシャルファンクションチャートプログラム３８５０の属性エディタ（不図示）を使用して接続される前に、属性およびパラメータを初期化するのに有効である。

シーケンシャルファンクションチャート（エディタ）プログラム３８５０は、属性値「ライブ」表示を含む、動作中のャートのオンライングラフィック編集、表示およびデバッグもサポートする。選択式オンライン編集およびデバッグモードオプションは、例えば、単一ステップ、強制入力、およびブレークポイントオプションを含む。オンライン編集は、ストラテジーで変更が行われている間に、コントロールストラテジーを実現するためのブレークポイントの設定を含む。ユーザが適所にある矛盾するパラメータ値を訂正できるように、１つのウィンドウがオンライン編集およびデバッグに使用される。オンライン編集中の入力値は、オフライン編集値との一貫性があるかチェックされ、矛盾している場合には却下される。シーケンシャルファンクションチャートプログラム３８５０は、ステップ、動作、現在実行中のトランザクションおよび属性値の表示を含む実行時ビューをサポートする。

シーケンシャルファンクションチャートプログラム３８５０により作成されるハードコピー出力情報は、グラフィック表記およびステップ動作などの構成情報を含む。

シーケンシャルファンクションチャートプログラム３８５０複数の特徴は、再利用可能ライブラリ構成要素、ユーザ変換サポート、および入力エラーチェックを含むユーザサポートを容易にする。ステップ動作内でのユーザ変換サポートにより、ユーザは応答のあるポップアップダイアログを構成できる。再利用可能ライブラリ構成要素は、単一のシーケンシャルファンクションチャート（ＳＦＣ）が、実行中、複数のモジュールまたはＳＦＣ用のサブルーチンとして動作するように、構成および実行中のエンジニアリングを簡略化するために開発される。

はしご形論理プログラム３８７０は、はしご形論理図で、組み合わされるはしご形要素およびファンクションブロックを使用してコントロールストラテジーを定義するためにユーザにより操作される制御プログラムである。はしご形論理プログラム３８７０は、制御装置／マルチプレクサ１１０内で動作するはしご形論理エンジン内に実現される。はしご形論理エンジンは、コイル、接触子、および複数の標準ファンクションブロックを含むはしご形制御アルゴリズムを実行する。はしご形論理プログラム３８７０は、基本離散制御動作を解決するための構成要素を含む基本離散制御はしご形論理ライブラリ３８７２を含む。

これらの動作は、はしごの横木ごとに１つの接続が定義されている、コイル、接触子、タイマ、フリップ／フロップ、エッジトリガ、およびカウンタなどの要素を含む、ＩＥＣ１１３１−３規格の論理拡張部である。はしご形論理プログラム３８７０は、はしご形論理図内でのユーザ定義ブロックの配置もサポートする。はしご形論理図は、「電力」がはしご内の「横木」を通して流れているかどうかにより実行の状態が決定される電力フローをサポートするファンクションブロックに適用できる。電力フローは、論理図でのデータフローにいくぶん類似している。適用可能なファンクションブロックだけが、はしご形論理パレット上にはしご形論理プログラム３８７０により表示される。

はしご形論理プログラム３８７０は、コントロールストラテジーを構成、デバッグするためにユーザにより独占的に使用されるか、あるいは論理図シートが別のはしご形論理図シート、ファンクションブロックダイアグラムシート、またはシーケンシャルファンクションチャートシート内での複合物として使用されることがある。はしご形論理シートは、複合はしご形論理図、ファンクションブロックダイアグラム、またはシーケンシャルファンクションチャートシートを含むことがある。はしご形論理要素は、他のシートおよび他のモジュールで属性を読み書きできる。

はしご形論理図は、オンラインとオフライン両方の編集をサポートする。ユーザは、特定のはしご形論理図でデバッグ機能モードから編集モードに切り替え、コントロールストラテジーに構造上の変更を加えることができる。ユーザは、デバッグビューまたは編集ビューのどちらかからパラメータを変更してよい。

はしご形論理プログラム３８７０は、電力フロー、パラメータ値、および通電状態または電力供給が止められている状態のディスプレイを含むデバッグ機能性を含む。はしご形論理デバッグ機能性とは、実質的には、ユーザが入力値を強制し、ブレークポイント等を設定するシーケンシャルファンクションチャート（編集）プログラム３８５０のデバッグ機能性と同じである。はしご形論理プログラム３８７０は、はしご形論理シミュレーション、履歴データ収集とモード、警報およびステータスレポート生成をサポートする。

図３９Ａを参照すると、ファンクションブロック（エディタ）プログラム３８４０を使用して構成プログラムにより作成される構成画面３９００の画面提示が描かれている。構成画面３９００は、ナビゲーション部分３９０２および画面特定部分３９０４を含む。ナビゲーション部分３９０２は、ユーザが構成プログラムの特定のセクションにアクセスできるようにするナビゲーションタブ３９１０を含む。構成画面３９００の実例となる状態では、構成プログラムは、構成コマンドのユーザエントリを待機している。ナビゲーションタブ３９１０は、簡略セット優勢（dominant）（ＳＲ）フリップフロップを選択するためのナビゲーションタブ３９１２、簡略減算ブロックを選択するためのナビゲーションタブ３９１４、簡略時間付きパルスブロックを選択するためのナビゲーションタブ３９１６、簡略転送ブロックを選択するためのナビゲーションタブ３９１８、および簡略排他的論理和（ＸＯＲ）ブロックを選択するためのナビゲーションタブ３９２０を含むファンクションブロックの中へのエントリ用の複数のプリミティブ関数を示す。ナビゲーションタブ３９１０は、ファンクションブロックを挿入するためのブロックアシスタントタブ３９２２も含む。画面特定部分３９０４は、属性の構成および他のファンクションブロックとの接続を含む、構成されるファンクションブロック３９２４を示している。

ブロックアシスタントタブ３９２２は、ファンクションブロックを挿入するために選択される。

図３９Ｂを参照すると、選択画面３９３０が、ファンクションブロック挿入の選択に応えて表示されている。選択画面３９３０は、選択部分３９３２および画面特定部分３９３４も含む。画面特定部分３９３４は、作成される新規ブロックの名称を入力するためのエントリブロック３９３６を含む。選択部分３９３２は、ファンクションブロックタブ３９４０、埋め込みブロックタブ３９４２、リンク済み複合タブ３９４４、およびモジュールブロックタブ３９４６を含む複数の選択タブ３９３８を含む。選択部分３９３２は、Backボタン３９４８、Nextボタン３９５０、および取消しボタン３９５２を含む、ナビゲーション機能を供給する多岐に渡るボタンも含む。Backボタン３９４８により、ユーザは、厳密な履歴順での過去の画面表示に移動する。Nextボタン３９５０により、ユーザは、現在の画面提示で行われる選択に適切な画面提示に移動する。取消しボタン３９５２は選択を終了する。

埋め込みブロックタブ３９４２は、埋め込みブロックを挿入するために選択される。

図３９Ｃを参照すると、Choice画面３９６０が喚起され、ユーザが埋め込みブロック、選択３９６２を使用しているファンクションブロックエディタ、または選択３９６４を使用しているシーケンシャルファンクションチャートエディタのどちらかを構成するための制御言語エディタを選択できるようにする。

選択３９６４は、シーケンシャルファンクションチャートエディタを活用するために選ばれる。

図３９Ｄを参照すると、ファンクションブロック３９２４がファンクションブロック（エディタ）プログラム３８４０を使用して構成され、新規に作成されるブロック３９７２がシーケンシャルファンクションチャートエディタ３８５０を使用して構成される、構成画面３９７０の画面提示が示されている。

新規に作成されるブロック３９７２の編集は、シーケンシャルファンクションチャートエディタ３８５０が呼び出されるように選択される。

図３９Ｅを参照すると、新規に作成されたブロック３９７２の詳細が、属性３９８２およびステップ３９８４を含め、構成画面３９８０の画面特定部分３９３４に示されている。構成画面３９８０のナビゲーション部分３９８６は、ファンクションブロックに関係するナビゲーションタブを一覧表示しているのではなく、むしろステップ３９９０、遷移３９９２、終了３９９４、およびシーケンシャルファンクションのステップおよび遷移を定義するための入力端末３９９６と出力端末３９９８に関係するナビゲーションタブ（不図示）を含む。

以下、他の参考形態として、警報に関する実施形態を図４０乃至図４３を用いて例示する。
図４０を参照すると、オブジェクトも出るが、警報およびイベント関数を取り扱うための多様なオブジェクトのオブジェクト関係を示している。多様な状態は、アラーム、アラーム肯定応答、ユーザ変更（属性書込み、方法呼出し、ログイン／アウト）、「実行時システム」に対する構成変更（インストール、インストール解除（de−installs）等）、シーケンシャルファンクションチャート（ＳＦＣ）状態変更、オペレータ注意要求（ＯＡＲ）、およびその他の装置状態変化を含む非警報状態遷移を含む「イベント」であるように定義される。

すべての種類のイベントにとって１つの共通した特徴は、イベントの発生または状態遷移が、イベントジャーナル内に記録できるという点である。すべてのイベントは、１つ（または複数の）プラント領域と関連付けられている。イベント発生記録（RtEventOccurenceRecord４０４０）は、関連付けられているプラント領域（RtPlantArea４０１０）のために指定されているイベントジャーナル、ジャーナル（RtEventJournal４０２０）に捕捉される。

ユーザは、起動されているイベントジャーナルがイベントを捕捉する１つまたは複数のプラントエリアを構成することにより、典型的にはワークステーションを使用してイベントジャーナルを起動する。イベントジャーナルのオンライン動作は、記録されるイベントの指定されるクラスを無効にするまたは有効にすることにより、ユーザ制御下で修正される。

ユーザは、制御モジュールまたは装置モジュール（RtModule４０３０）内でアラーム属性（RtAttribute４０３２）を作成することによりアラーム動作を構成する。アラーム属性は、属性を包含している、制御モジュールまたは装置モジュール内の任意の論理的属性に対する参照を与える。アラーム属性は、モジュールレベルだけで作成される。アラーム属性は、複合されたファンクションブロックでは作成されない。

図４１を参照すると、状態遷移図が、警報属性状態を示している。ユーザは、アラーム属性を無効にするか、有効にする。ディスエーブル４１１０されると、アラーム属性は、「非アクティブな（Inactive）および認証された（Acknowledged）」状態と呼ばれる「正常」な状態で表示される。アラーム属性のディセイブルド／イネイブルド状態は、オペレータによりオンラインで、あるいはシステム内の制御アルゴリズムによって自動的に変更される。初期のディセイブルド／イネイブルド状態は、構成時に設定される。有効にされているアラーム属性は、アクティブになった状態４１１６または４１１８、あるいは非アクティブな状態４１１２または４１１４のどちらかを有している。参照されている論理的属性が真（TRUE）であるとき、アラームはActive（「警報中」）である。アラーム属性は、オプションで、警報状態の意味を反転させるように構成されるため、．ＩＮＶ特性ＴＲＵＥが設定されるアラーム属性は、あたかも参照される属性のFALSE値が「警報中」状態を示すように動作する。アクティブ／非アクティブな状態は、アクティブ／非アクティブな状態が、オペレータまたは別の制御アルゴリズムによって直接変更されないように、参照されてい属性の状態により駆動される。

ディセイブルドである間に、アラーム属性は、認証状態４１１２または４１１６、あるいは未認証状態４１１４または４１１８のどちらかを有している。アラーム属性は、自動的に肯定応答されない限り、アラーム属性が非アクティブからアクティブ状態に遷移を行う場合にだけ未認証状態にされる。オペレータまたは別の制御アルゴリズムが、アラームを肯定応答し、アラーム属性をAcknowledged状態に変更することがある。

アラーム属性は、自動的に肯定応答されるか（ＡＡＣＫ‘ｄ）または自動的ではなく肯定応答される。ＡＡＣＫは、現在のアラームの優先順位から決定される。ユーザにより構成されているシステム全体のテーブルがＡＡＣＫ動作を決定する。例えば、テーブルは、すべての「ＬＯＷ」優先順位のアラームが自動的に肯定応答され（ＡＡＣＫがTRUEである）、すべての「MEDIUM」および「HIGH」優先順位のアラームが自動的に肯定応答されない（ＡＡＣＫがFALSEである）と指定することがある。ＡＡＣＫがTRUEであるとき、警報は絶対にUnacknowledged状態にされない。

ディセイブルド／イネイブルド、アクティブ／非アクティブ、および認証／未認証状態の組み合わされた動作の結果、図４１に示されているアラーム属性のユーザ可視状態が生じる。

有効にされているアラーム属性は、当初、Inactive／Ack`d State４１１２に移行し、ただちにActive／Unack'd４１１４またはActive／Ack`d４１１６のどちらかに遷移する可能性がある。Acive／Ack'd４１１６への遷移には、例えば、遷移にタイムスタンプが押され、イベントがイベントジャーナルに記録される、Alarmの標準「遷移」動作が伴われる。

アラーム属性は、ユーザ可視インタフェースを提供する複数のフィールドを有している。CUALM「カレント警報フィールドは、アラーム属性がDisabled状態４１１０、Inactive／Ack`d状態４１１２またはInactive／Unack'd状態４１１４にあるときに「ＯＫ」である。それ以外の場合、ＣＵＡＬＭは、構成されている属性のタイプに関連付けられているワード／値である。ＤＥＳＣ「記述」フィールドは、アラーム属性が状態を変化するときに作成される警報記述を有している。ＤＥＳＣフィールドは、空の文字列に初期化される。ＬＡＡＬＭ「ラッチ済み警報」フィールドは、アラーム属性がディセイブルド状態４１１０またはInactive／Ack`d状態４１１２にあるときに「ＯＫ」である。それ以外の場合、ＬＡＡＬＭフィールドは、構成されているアラームタイプに関連付けられているワード／値である。ＬＡＡＬＭフィールドは、「ラッチされている」警報起動を提示し、Activeである期間中が非常に短い場合にも認証を有効にする。ＮＡＬＭ「未肯定応答警報」フィールドは、アラーム属性のAcknowledged／Unacknowledged状態を示す。ＮＡＬＭフィールドは、警報要約エントリを削除できるときを突き止めるために使用される。ＥＮＡＢ「警報有効済み」フィールドは、アラーム属性の現在のEnabled状態を示す。IENAB「警報初期有効済み」フィールドは、Alarm Attributeの構成済みEnabled状態を示す。ＩＮＶ「反転入力」フィールドは、関連付けられている論理的属性が警報処理の前に反転されるかどうかを示す。ＩＮＶ構成可能特性は、アラーム属性基準、通常は、離散入力を保持している属性などのTRUEブールAttributeを許す。ＰＲＩ「警報優先順位」フィールドは、アラーム属性の現在の優先順位（高／中／低）を示す。テーブルＩＩは、論理的属性を以下のように示す。

プロセス制御システム１００は、多くの潜在的なアクティブなアラーム状態を［最高優先順位］警報の１つの短いリストの中に整理統合する。選択基準は、整理統合のために最高の優先順位の警報を選択するために使用される。選択基準は、優先順位が下がっている順序での分析、Unacknowledged状態がAcknowledged状態より優先されているAcknowledged状態、高それから中それから低の優先順位の順序でのアラーム優先度、および最新タイムスタンプが優先順位を獲得している検出の時間を含む。

Alarm Consolidationは、ＳＰ８８ ModuleレベルおよびPlant Areaレベルで使用できる。警報整理統合は、ＳＰ８８ MODULE（ControlおよびEquipment）Plant Areasで使用できる既定義されている属性名「ＡＬＡＲＭ」を介してアクセスされる。ALARMSとは、インデックス付きAttributeであり、指数は、整理統合でのＮ番目に高い優先順位警報（例えば、ALARMS［１］は最高の優先順位Alarmにアクセスし、ALARM［２］は２番目に高い優先順位のAlarmにアクセスする等）を選択する。したがって、例えば、「ＡＲＥＡ１／ＦＩＣ１０１／ＡＬＡＲＭＳ［１］」は、Module FIC１０１の最高優先順位のAlarmを参照し、「ＡＲＥＡ１／ＡＬＡＲＭ［２］」は、Plant AreaのＡＲＥＡ１での２番目に高い優先順位Alarmを参照する。ALARMS Attributesでサポートされている最大指数は５である。

ＡＬＡＲＭＳ［Ｎ］AtributeでサポートされているFieldsは、Ｎ番目の優先順位のアラーム属性のActive Or Unacknowledged状態を示すＬＡＡＬＭ「ラッチ済み警報」フィールドを含む。ＬＡＡＬＭ Fieldは、ACTIVE／UNACK`D、ACTIVE／ACK'D、またはINACTIVE／UNACK`D状態の間のＮ番目の優先順位のAlarm Attributeの警報ワード、つまり警報型値内にある。ＮＡＬＭ「未肯定応答警報」フィールドは、Ｎ番目の優先順位のAcknoeldged／Unacknowledged状態を示す。ＰＲＩ「警報優先順位」フィールドは、Ｎ番目の優先順位のアラーム属性の構成済み優先順位（High／Medium／Low）を示す。ＴＡＧ「警報Ｔａｇ」フィールドは、Ｎ番目のアラーム属性に対する（Fieldを除く）完全に修飾されている属性基準文字列を返す。ＭＯＤＵＬＥ「警報Ｍｏｄｕｌｅ」フィールドは、Ｎ番目の優先順位アラームを有しているＳＰ８８ＭＯＤＵＬＥを示す。MODULEタグは、そのModuleの「一次制御ディスプレイ」属性にアクセスするために使用できるModule基準文字列を戻す。

いくつかのフィールドが、ＳＰ８８モジュールレベルだけでのアラーム属性上でサポートされている。指数値がこれらのフィールドに適用されると、指数値は無視される。ＳＰ８８モジュールレベルアラーム属性フィールドは、モジュールの現在のAlarm Enabled状態を示すＥＮＡＢ「警報有効済み」フィールドを含む。ＰＲＩＡＤ「優先順位調整」フィールドは、アラームの有効優先度を求めるときにモジュール内の各アラーム属性の現在の優先度に追加される数（通常は０）である。PRIAD Module全体での調整は、モジュール内の全警報のアラーム優先度を下げ、アラーム可視性の減少を可能にするために使用される。テーブルＩＩＩは、以下のように、詳細にアラーム属性を説明する。

User−Level Alarm Consolidationは、グラフィックユーザインタフェースで「Alarm Banner」を使用して達成される。警報整理統合は、「カレントユーザ」に対しサポートされる。各ユーザは、１つまたは複数のPlant Areaでの権限を許可されている。「カレントユーザ」警報整理統合は、現在、ユーザの制御スパン内にあるプラントエリアの最高優先順位の警報を提示する能力を提供する。「THISUSER」と呼ばれている、ALAFRMS［Ｎ］属性をサポートする既定義「属性コンテナ」が存在する。ユーザは、オプションで、「THISUSER／ALARMS「Ｎ」．フィールド」を参照するディスプレイを構築し、カレントユーザに対する最高優先順位警報へのクイックアクセスを可能にする。

警報特権が許可されている場合、ユーザは、アラームをイネイブルし、ディセイブルする。警報特権を使用し、ユーザは、．ENABフィールドに書き込むことによって単一のアラーム属性をイネイブルまたはディセイブルしてよい（例えば、「ＡＲＥＡ１／ＦＩＣ１０１／ＨＩＡＬＭ．ＥＮＡＢ」にＴＲＵＥを書き込む）。プロセス制御システムの各アラーム属性は、単一Enable／Disable状態を含む。一人のユーザが状態を変更すると、アラームはすべてのユーザに対しEnabled／Disabledされる。警報特権を使用し、ユーザは、ＡＬＡＲＭＳＡｔｔｒｉｂｕｔｅのＥＮＡＢフィールドに書き込むことによって、ＳＰ８８ Module Alarm内のすべての警報をEnableまたはDisableしてよい（例えば、「ＡＲＥＡ１／ＦＩＣ１０１／ＡＬＡＲＭＳ．ＥＮＡＢ」にTRUEを書き込む）。アラームをモジュールレベルでDisablingすると、個々のアラームのＥＮＡＢ状態を無効とするが、それに上書きしない。アラームがモジュールレベルでEnabledされると、個々のAlarmnoENAB状態により決定されるアラーム処理が復元される。

システム中の各ＳＰ８８モジュールは、単一Enable／Disable状態を含む。一人のユーザが状態を変化すると、そのモジュール内のすべてのAlarmsは、すべてのユーザに対してEnabled／Disabledされる。

動作特権を有しているユーザは、アラームを認証できる。動作権限を使用し、ユーザは、FALSEを．ＮＡＬＭフィールドに書き込むことによって単一アラーム属性を認証する（例えば、「ＡＲＥＡ１／ＦＩＣ１０１／HIALM．NALM」にFALSEを書き込む）。．NALMにTRUEを書き込もうとする試みは無視される。プロセス制御システム中の各アラーム属性は、単一の認証状態を有している。一人のユーザが状態を変更すると、Alarmはすべてのユーザに対し認証される。動作特権を使用し、ユーザは、モジュール内のすべてのアラーム属性の．NALMフィールドにFALSEを書き込むのと実質的には同じ効果を出す動作である、アラーム属性の．NALMフィールドにFALSEを書き込むことによってSP Module Alarm内のすべての警報を認証してよい（例えば、「AREA１／FIC十１／ALARMS．NALM」にFALSEを書き込む）。．NALMにTRUEを書き込もうとする試みは無視される。

警報特権を有しているユーザは、警報優先順位を変更することができる。警報特権を使用し、ユーザは、．ＰＲＩフィールドに書き込むことによって単一アラーム属性上のＰＲＩを変更してよい（例えば、「AreA１／FC１０１／HIALMPRI」に０を書き込み、それを「HIGH」優先順位警報にする）。自動認証動作は、アラーム優先度により決定されるので、アラーム優先度を変更すると、アラームに肯定応答ステータスを変更させる可能性がある。例えば、AutoAck FALSEが設定されている優先順位から、AutoAck TRUEが設定されている優先順位に変更すると、未応答確認警報が肯定応答されるはずである。また、AutoAck TRUEが設定されている優先順位から、AutoAck FALSEが設定されている優先順位に変更すると、肯定応答済み警報が未応答確認になるはずである。

システム中の各アラーム属性は、単一．ＰＲＩ状態を有している。一人のユーザが状態を変更すると、．ＰＲＩはすべてのユーザに対して変更される。

警報特権を使用し、ユーザは、アラーム属性の．PRIADフィールドに書き込むことによって、ＳＰ８８モジュールアラーム内のすべての警報の有効優先順位を調整してよい。例えば、「ＡＲＥＡ１／ＦＩＣ１０１／ＡＬＡＲＭＳ．ＰＲＩＡＤ」に１を書き込むユーザは、現在のアラーム優先度値を増加し、それによってHIGH優先順位がMEDIUM優先順位になり、LOW優先順位がLOGになるように１つの「段（step）」づつ動作を削減する。ユーザは、PRIADを正の数に設定するだけなので、通常の予告動作を減少するためにだけ使用される。PRIADを０に設定すると、アラーム属性ごとに求められる「通常の」優先順位が再確立される。有効警報優先順位は、ＬＯＧ「下では」調整されない。Auto Acknowledgement動作はアラームポリシーにより決定されるので、モジュールレベルでPRIADを変更すると、個々のアラームが肯定応答ステータスを変更する可能性がある。

システム中の各ＳＰ８８ Moduleは、単一．ＰＲＩＡＤ値を有している。一人のユーザが状態を変更すると、すべてのユーザに対して、そのモジュール内のすべてのアラームが影響を受ける。

警報は、標準ＦＩＸＴＭ警報要約の元でのディスプレイを使用して表示される。マサチューセッツ州、ノーウッド（Norwood、MA）のインテルーション（Intellution）によって販売されているＦＩＸＴＭク゛ラフィックディスプレイプログラムは、コンピューティング技術ではよく知られている。ＦＩＸＴＭ警報要約リンクは、アクティブアラームのフィルタ済みの、並べ替えられているリストを表示するための主要な方法である。警報要約リンクのすべての機能は、以下の例外または拡張部分はあるが、サポートされている。第１に、「タグ名」欄は、フィールド名を除く、アラーム属性（例えば、「AREA／FIC１０１／HIALRM」）のプロセス制御システム属性基準経路を示している。第２に、「説明」には、アラームが最初に検出された時点で、アラームが最高２つの属性の値を捕捉するように、アラームが検出される時点で構築されるユーザ構成文字列が記載されている。複数のアラームが、警報要約の各ＳＰ８８ Moduleごとに表示出切る様に、「Ｔａｇ」あたり１つの「アラーム」dakega可能である。第３に、「最終時刻」項目には、肯定応答の時刻、または未応答確認警報のActive／Inactive間の最後の遷移の時間である場合がある、アクティブアラームの最後の状態遷移の時間が記載されている。第４に、アラームのFIX SCADA Nodeソースを示す「ノード」欄項目は、エリアごとに、フィルタおよびソート機能が失われるように、プロセス制御システムアラームには無意味である。第５に、すべてのアラームは、アラームタイプに基づき文字表示色を達成するためにFIX Alarm型の内の１つにマッピングされる。

ユーザは、Alarm State Transition Journalingレコードにアクセスできる。警報状態遷移は、プラントエリアに割り当てられているイベントジャーナルに記録される。Inactive／Unack`d４１１４とActive／Unack'd状態４１１８の間の遷移を含む、図４１に示されているすべての警報状態遷移がイベントジャーナルに記録される。したがって、ＬＡＡＬＭフィールドをディスプレイまたは警報要約で表示しているオペレータは、未肯定応答警報間の遷移を確かめず、これらの遷移はイベントジャーナルに記録される。

警報遷移のイベントジャーナルエントリは、以下を含む。（１）警報状態を検出するデバイス（例えば、制御装置）により判断される警報状態遷移のタイムスタンプ、（２）他のイベントジャーナルエントリから区別する「警報」イベント型、（３）ユーザ定義警報カテゴリ、（４）現在の警報優先順位、（５）システムアラームタイプテーブルで構成される警報ワード文字列、（７）警告されている属性の属性基準文字列または経路、および（８）構成済みの（２つまでの）属性値が文字列に挿入される、アラームタイプテーブルで構成されている記述文字列からアセンブルされる記述文字列。

イベントジャーナルブラウザアプリケーションは、一般的には、タイムスタンプにより並べ替えられ、イベントタイプ＝「ＡＬＡＲＭ」および属性基準文字列＝「ＦＣ１０１／ＰＩＤ１／ＨＩＡＬＭ」でフィルタリングされる、テーブルＩＶに示されるようにデータを提示する。

オペレータ変更は、対応する警報状態の変更を引き起こすが、Event Journalでの警報状態遷移イベントは、オペレータ変更ジャーナルエントリとは別個である。例えば、以下の通りであるテーブルＶに示されるようである。

Alarm Attributesが構成され、それによりAlarm動作および提示を設定し、説明されている動作のシーケンスを使用する。第１に、「警報型」テーブルおよび「警報予告」テーブルが構成される。第２に、オプションステップで、ユーザ定義警報状態が構成され、ブール属性を設定する。第３に、Alarm Attributesは、ブールAttributesを参照するために作成され、それによりSystem「Alarm Type」、優先順位等を識別する。第４に、モジュール「インスタンス」は、Alarmsを包含するModule Definitionsに基づき作成される。第５に、Alarm情報の提示は、データベースリンク、ダイナミックカラーリンク、およびAlarm Summaryリンクを介してディスプレイ（絵）の中に挿入される。第６に、「Alarm Tyes」および「警報予告」テーブルが構成される。

「警報型」テーブルには、（１）AlarmごとのAlarm構成プロセスを加速するために１つの共通したAlarm提示動作を定義する、システム（サイト）全体で共通したリソースとして動作すること、（２）SummariesおよびHistory Journalsでの標準警報メッセージ通信を奨励し、その情報の問い合わせおよび分析を改善すること、（３）警報をFIX Alarm Statesにマッピングすることを含む複数の機能がある。

「警報型」テーブルには、警報タイプ、警報ワード、カテゴリ、および記述文字列欄を含む欄がある。警報型欄には、アラーム属性を作成するときに適切なTypeを選択するために使用される警報型の簡略な記述が記載される。警報ワード欄には、AlarmがActiveであるときにＡ＿ＣＵＡＬＭまたはＡ＿ＬＡＡＬＭ Fieldを読み取るときに返される文字列を含む。カテゴリ欄には、問い合わせのフィルタリング／並べ替えを補助するために使用される、Event Journalに記録されているユーザ定義ワードを記述する。記述文字列は、警報要約リンクに表示され、Alarm Detection時でのAttribute値置換のために最高２つの位置設定記号を包含する。

「警報型」テーブルデフォルト内容は、以下に示すようにテーブルＶＩに示されている。

標準警報は、ＦＩＸＴＭでサポートされている警報型に一致する。

「警報予告」テーブルとは、アラームごとのアラーム構成プロセスを加速するためにアラーム予告動作の１つの共通して定義を供給するシステム（サイト）全体での共通したリソースである。

「警報型」テーブルには、警報優先順位、自動肯定応答、ＷＡＶファイルおよびＰＣスピーカ周波数欄を含む欄がある。警報優先順位は、アラーム優先順位ワード（ＨＩＧＨ／ＭＥＤＩＵＭ／ＬＯＷ／ＬＯＧ）を指定する。自動肯定応答の欄には、この優先順位の警報が、検出時に自動的に肯定応答される必要があるのかを示し、重要度が低い警報をより「注意をそらす（distracting）」とする機械を提供するＹＥＳ／ＮＯ値が記載される。ＷＡＶファイルには、サウンドカード付きワークステーションで（カレントユーザの範囲内で）アラームが検出されるときに再生される（ループ計算）ＮＴ互換の．ＷＡＶファイルのファイル名が指定される。このファイル名の省略は、この優先順位が設定される警報には．ＷＡＶファイルが再生される必要が内ことを示す。ＰＣスピーカ周波数は、サウンドカードが付かないワークステーションで、カレントユーザの範囲内で、アラームが検出されるときにＰＣスピーカでトーンを再生するために使用される値を設定する。０という値は、ＰＣスピーカをこの優先順位が設定される警報に使用してはならないことを示す。．ＷＡＶファイルおよび０以外のスピーカ周波数が同じ警報優先順位に指定される場合、ＰＣスピーカは、サウンドカードが存在する場合にだけ使用される。

「警報予告」テーブルデフォルト内容は、以下に示すようにテーブルＶＩＩに示されている。

ユーザは、同じモジュール内の別の論理的属性を参照するＳＰ８８ MODULE DEFINITIONに従って、アラーム属性をAlarm（動作）を論理的属性に付与する。

ユーザは、以下を入力することによりアラーム属性を作成する。（１）例えば、経路による、またはドラッグアンドドロップによるターゲット属性、（２）警報状態を定義する論理的属性、（３）システム全体でのアラームタイプリストから選択されるアラームタイプ、（４）アラーム優先度（Ｈｉｇｈ／Ｍｅｄｉｕｍ／Ｌｏｗ／Ｌｏｇ）、（５）初期Alarm Enable状態（イエス／ノー）、（６）Invert Input（イエス／ノー）、（７）％Ｐ１の代わりに使用される値を有している属性のオプションのＮａｍｅ、（８）％Ｐ２の代わりに使用される値を有している属性のオプションのName アイテム７と８の属性の名称は、同じＳＰ８８ MODULE内の属性に制限され、「モジュール相対」属性基準として指定される（例えば、「ＦＩＣ１０１／ＳＰ」や「ＦＩＣ１０１／ＰＩＤ１／ＰＶ」よりむしろ「ＳＰ」および［ＰＩＤ１／ＰＶ］）。

ユーザは、アラームを記載するモジュール定義に基づいてモジュール「インスタンス」も作成する。モジュールインスタンスが作成されると、モジュール定義に指定されているすべてのアラーム動作はモジュールインスタンスに適用する。．ＰＲＩフィールドおよび．ＥＮＡＢフィールドは、Moduleインスタンスが作成されるとAlarm`d Attributesで無効にされることがある。例えば、「ＨＩＧＨＬＩＭＩＴＥＤ」という名前が付けられているAlarm Attributeに対し、モジュール定義が構築されるとき、それからModuleインスタンスが作成されるときに．ＰＲＩがMEDIUMである場合、「ＨＩＧＨＬＩＭＩＴＥＤ．ＰＲＩ」はこのインスタンスに対しＬＯＷであるために無効とされることがある。

警報は、ControllersでのDevice／Subsystem Attributesに関しサポートされている。属性は、制御システムの動作および他のシステムへの接続についての情報へのアクセスを提供するためにデバイスおよびデバイスサブシステムに対し定義される。属性には、診断ツールを介して、および既定義またはユーザ定義のディスプレイを介してアクセスすることができる。アラームシステムに関与し、制御システムでの異常な状態に注意を引き付けることは、これらの属性のいくつか、特に「整理統合」属性にとっては貴重である。

ユーザは、Control Modules（インスタンス）を作成し、プロセッサ、通信、Ｉ／Ｏ、冗長性等を含むControllersおよびSubsystemsnoために所望の「Device Alarm」ストラテジーを実現する。

Function Ｂｌｏｃｋアルゴリズムを使用して、Device／Subsystem Attributesは、同じデバイス内でもっとも効率よくアクセスされるが、他のControllersおよびWorkstationにもサポートされている。DeviceとSubsystemのAttributesは、後で警報制限をこれらのAttributesに適用すること、これらの値をブールAttributesに変換することに対し構成できるFunction Blocksへの入力として使用される。それから、AlarmAttributesは、ブールAttributesを参照する。一般的には、Function Blockシステムの完全アルゴリズム定義機能は、簡略な、または複雑なDevice Alarming体系を構築するために使用される。

ＦＩＸＴＭ警報型と矛盾しない多くの既定義Alarm Typesは、「Device Alarm」の提示と動作を区別するために適している。既定義Control ModuleDefinitions（制御モジュール定義）が供給され、かなり包括的なDevice Alarm「モジュール」をControllersおよび各種のＩ／Ｏシステムに提供する。ユーザは、オプションで、これらの標準モジュールをディスエーブルまたは拡張する。

ユーザは、例えば小型システムストラテジー、「分離（segregation）」ストラテジー、および「区分化責任」ストラテジーを含む、Device ＡｌａｒｍモジュールをPlant Areasに配置するための複数のストラテジーを選択してよい。小型システムにおいては、Plant Area概念が適用されていない「一式（all in one）」ストラテジーが課される。各Controller内の１つまたは複数のDevice Alarm Modulesが、DeviceとＳＰ８８ MODULE警報の一体化された提示を形成する。分離ストラテジーは、Alarm要約に対するAreaフィルタリング／並べ替えを有効にし、Device Alarmに焦点を当てるために、OperatorsがＳＰ８８ MODULE警報およびプロセス／保守エンジニアに集中できるようにする。区分化責任ストラテジーは、システムがPlant Areaごとの責任の範囲を制御するほど十分に大きくなると使用される。Device Alarm Modulesは、Device Alarm Modulesによって影響を受けているＳＰ８８ MODULEと同じPlant Area内に配置される。区分化責任ストラテジーは、責任範囲内でのPlants Areaに対するDeviceおよびＳＰＰモジュール警報の一体化した提示を形成する。

警報は、Workstation内のDevice／Subsystem Attributesにサポートされている。Draw、View、エンジニアリングツール等のユーザ起動アプリケーションは、適切なコンテキストで、個々に、異常な状態または遭遇されたエラーについて情報を提示する。Workstation Servicesは、ユーザがログオンする前にワークステーションで起動され、ログオフ／ログオンサイクルを通して実行し続けるWorkstation Servicesは、無人のWorkstationにとっても、問題に対する注意を引き付けるための技法を実現する。１つの実施態様においては、Workstation Servicesは、１つまたは複数のControllersで実行しているDevice Alarm Modulesにより監視される。Servicesは、ユーザ定義Device Alarmingストラテジーを制御するDevice Alarm Modulesのインスタンスを実行しているController（複数の場合がある）によってアクセスされる、ステータスと完全性Attributesのセットを構築する。既定義Control Module Definitionsが供給され、かなり包括的なDevice Alarm「モジュール」をWorkstationsおよび各主要Services（例えば、通信、履歴ジャーナルなど）に提供する。ユーザは、これらの標準モジュールをディスエーブルまたは拡大してよい。

プロセス制御システムの１つの態様では、「Alarm」ステータスを与えられていないイベント状態には、「ＬＯＧ」という優先順位が指定される。LOG AlarmsはALARMS Attributesでは整理統合されず、Alarm Summaryには表示されず、状態変化の可聴警報を提供せず、型「ＡＬＡＲＭ」よりむしろ型「ＥＶＥＮＴ」としてEvent Journalに表示される。他の点では、ＬＯＧ優先順位のAlarmは、イベント（１）が個別に有効／無効にされ、（２）他の警報が設定されているModuleレベルではディスエーブルされ、（３）個々のAlarmが、その優先順位を「ＬＯＧ」に変更する（．ＰＲＩに３を書き込む）ことによって「Ｅｖｅｎｔに合わせられる」ように、ＨＩＧＨ／ＭＥＤＩＵＭ／ＬＯＷ優先順位Alarmとして動作する。

Moduleレベルに．ＰＲＩＡＤを設定することにより、Alarmの１つまたは複数ｎレベルをEventsに変換できる（例えば、．ＰＲＩＡＤに２を書き込むと、Module内のすべてのAlarm優先順位が２段低下する。つまりHIGH優先順位はLOWになり、MEDIUMとLOW優先順位はＬＯＧになり、ＬＯＧはＬＯＧのままとなる）。．ＰＲＩＡＤを３に設定すると、Module内のすべてのAlarmは、強制的にカレントステータスを表示する（未肯定応答の場合には点滅もする）ためにサポートされている「Events」．ＣＵＡＬＭ、ＬＡＡＬＭ、ＮＡＬＭフィールドになる。

ＬＯＧイベントは、また（４）入力ブールを反転し、使用状況のためのＯＫイベント状態の意味をDiscrete Inputsの状態でのログ変化に逆転し、（５）ユーザ定義「警報ワード」をAlarm Typesテーブルに追加し、イベント状態有効名を指定し、（６）Event JournalにＬＯＧ優先順位警報に関するすべての状態変化を記録することができる。

システムイベント検出のユーザ選択可能「強度」（例えば、「デバッグ強度」、「通常強度」、「停止強度」）は、ユーザ定義の「強度」Attributeの設定値に基づきControl Moduleアルゴリズム内で構成される。したがって、System Eventsは１つ（またはおそらく複数の）Plant Ａｒｅａと一致させ、そのため１つまたは複数のPlant AreaのためにWorkstationでEvent Journalを有効にすると、すべての「System Event」レコードの宛先が自動的に設定される。

System ObjectでAttributeを変更している、または方法を呼び出しているユーザは、イベントと見なされ、適切なEvent Journalに記録される。制御階層（Control Module、Equipment Module、Plant Areaなど）に対する変更は、そのPlant Areaに指定されているEvent Journal（複数のことがある）に記録される。Device／Subsystem Attributesに対する変更は、そのDeviceのために指定される「一次Plant Areas」のEvent Journal（複数のことがある）に記録される。

図４２を参照すると、コンテキスト図が、制御モジュールに関して警報イベントを定義するためのコンテキストを示している。Alarmは「Plant Area範囲」アクティブ警報リスト提示に表示される。複合モジュール（ＣＭ）４２１０のインスタンスは、ＰＩＤファンクションブロック４２１２、出力属性４２１４および高警報属性４２１６を含む。構成エンジニアなどのユーザは、編集のために複合モジュール４２１０を選択し、Attribute「ＨＩＨＩ」で「警報追加」４２２０を選択する。また、ユーザは、「Advisory」４２３２と名前が付けられているイベント優先順位定義、および「ＨＩＡＬＡＲＭ」４２３４と名前が付けられているイベント型定義も選択する。それから、ユーザは、複合モジュール４２１０に対する変更を保存する。

再び図４０を参照すると、警報イベント管理が説明されている。ＬＯＧ優先順位Alarmとして構成されている警報およびユーザ定義「イベント」は、複数の動作をプロセス制御システムに導入する。

これ以降RtAlarmAttribute４０３４と呼ばれている特定の種類のRtAttributeは、読書きができるCUALM、NALM等のAlarmに特定のフィールドをサポートしている別個の「データ型」を有している。フィールドに対する読取りアクセスは、個々のAlarmの状態の提示を可能にする。選択されているフィールドに対する書込みアクセスは、AlarmをAcknowledge
する能力を与え、一定の警報動作を変更する。

Disabled動作、ＡＵＴＯＡＫ動作などのAlarm動作の複数の特性は、ＳＰ８８ＭＯＤＵＬＥレベルでオンラインで無効にされることがある。Enabled／Disabled、およびNoAutoAck／AutoAckという個々のAlarm状態への逆転は、Moduleレベル無効が削除されると発生する。Moduleレベル無効の変更は、「ただちに」個々のAlarm状態に影響を及ぼすはずである。したがって、Moduleレベル無効での変更は、新しい条件下のモジュール内のすべてのＡｌａｒｍ状態の再評価を強制する。

レベルのそれぞれでの「最高優先順位の警報」が提示されるように、アクティブ警報は、Module（RtModule ４０３０）、Plant Area（RtPlantArea ４０１０）、およびUser Sessionで整理統合される。この整理統合は、Moduleオブジェクト、Plant Areaオブジェクト、およびUser SessionオブジェクトによりサポートされているＡＬＡＲＭＳ属性を通してアクセスされる。

ＦＩＸＴＭ警報要約リンクは、「カレント」警報のリストを提示するために、ＦＩＸＴＭヒ゜クチャ（ディスプレイ）で使用される。形容要約リンクのコンテンツは、（ＦＩＸＴＭ停止時に停止し、ＮＴユーザがログオンすると必ずＦＩＸＴＭは停止し、ＮＴユーザは新規ユーザが「ログイン」できるようにログオフする）ＡＬＭＳＵＭ．ＥＸＥプロセスにより維持される。したがって、システムは、ＡＬＭＳＵＭプロセスを（カレントユーザの責任範囲の対象となる）すべてのカレント警報で「満たし（prime）」、新規ユーザログオン時にそれを起動させなければならず、それは新規警報発生および警報肯定応答についてのＡＬＭＳＵＭプロセス情報を供給しなければならないため、最新の要約が提示できる。

すべての警報状態遷移は、RtAlarmAttribute ４０３４を「包含する」Plant Areaに対する適切なEvent Journal（複数の場合がある）（RtEventJournal ４０２０）に向けられる。複数のEvent Journalターゲットが供給されるため、Event Journalsの内の１つを実行している１つのワークステーションがある時間期間オフラインである場合、完全なEventJournalが再構築できる。

Alarmエントリ状態遷移の可聴警報は、Alarm Summarizationを実行している（ＦＩＸＡＬＭＳＵＭ．ＥＸＥプロセスを供給する）ワークステーションで実行する。可聴警報は、ＰＣスピーカ上での連続トーン（ユーザ構成周波数）、および／またはＰＣ内にインストールされている互換サウンドカードで再生される連続（ループ計算）．ＷＡＶファイルから成り立っている。プログラムは、スピーカとサウンドカードの両方をオフにするために実行されるので、音は、任意のＦＩＸＴＭ(ビューボタンまたはキーボード）スクリプト、またはＦＩＸＶＩＥＷが実行していない場合にはプログラムＧｒｏｕｐのＩＣＯＮによってオフにできる。

図４３を参照すると、オブジェクト通信図が、「警報中」ステータスを喚起する属性書込み動作を実行するための方法を示している。

属性書込み動作の前に、RtAlarmAttributeが構成、インストールされ、警報はAttributeとModuleレベルの両方でENABLEDされ、警報AUTOACKはAttributeとModuleレベルの両方で偽であり、カレントAlarm状態は「Inactive／Acknowledged」である。

「属性書込み」方法により、Alarm Attributeの状態は警報状態になる。新しいAlarm状態を反映するために、Alarm Attributeの警報フィールドは更新される。イベント発生レ
コードが構築され、必要に応じて、Module、Plant Area、およびワークステーションアプ
リケーション（Alarm Summary、Event Journal）に送信される。

属性書込み動作が完了すると、カレントAlarm状態は「Active／Unacknoeldged」であり、アクティブ警報がModuleにより記録され、イベント発生レコードが構築され、このDevice内のこのPlant Areaを監視しているデバイスへの伝送のために待ち行列に入れられた。

属性書込み方法のステップ４３１０では、RtAlarmAttributeはwriteAtributeを受け取り、それによりブールAttributeでの状態遷移が警報状態に入れられる。ステップ４３１２では、RtAlarmAttributeは、AttributeとModule Alarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ４３１４では、RtAlarmAttributeは、AttributeとModule Alarm AUTOACKの両方がDISABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmAutoackステータスを得る。ステップ４３１６では、RtAlarmAttributeが、新規警報状態、「Active／Unacknowledged」状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ４３１８では、RtAlarmAttributeは、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ４３２０では、RtAlarmAttributeが、新規RtEventOccurenceRecordを構築する。新規警報が作成されるため、RtAlarmAttributeは、その包含しているRtModuleに、ステップ４３２２で、addEventOccurenceするように命令する。ステップ４３２４では、RtModuleが、そのRtActiveAlarmListに、addeventOccurrenceするように命令し、新規エントリをリストに追加し、将来エントリにアクセスできるようにするハンドルを戻す。このハンドルは、究極的には、RtAlarmAttributeにより記憶される。ステップ４３２６では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送信する。ステップ４３２８では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogは、少なくとも１つのワークステーションクライアントがEventlogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。

図４３も参照すると、オブジェクト通信図は、カレント警報状態を「Active／Acknowledged」にする、AlarmのAcknowledgementにも適用できる。既存の警報の新規警報状態がＭｏｄｕｌｅにより記録され、新規イベント発生レコードが構築され、このDevice内のこのPlantAreaを監視しているデバイスへの伝送のために待ち行列に入れられた。方法は、Alarm Attributeの状態を肯定応答させるための「Attribute書込み」方法（NALM FieldにFALSを書き込む）の適用を含む。Alarm AttributeのAlarmフィールドは、新しいAlarm状態を反映するために更新される。イベント発生レコードが構築され、必要に応じてModule、Plant Area、およびワークステーションアプリケーション（Alarm Summary，Event Journal）に送信される。

ステップ４３１０では、RtAlarmAttributeが、writeAttributeを受け取り、NALM Fieldに状態をFALSEに変更させる。ステップ４３１２では、RtAlarmAttributeが、AttributeとModule Alarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ４３１６では、RtAlarmAttributeが、新しい警報状態、「Active／Unacknowledged」状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ４３１８では、RtAlarmAttributeが、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ４３２０では、RtAlarmAttributeが、新規RtEventOccurrenceRecordを構築する。既存の警報は更新されるため、RtAlarmAttributeは、RtAlarmAttributeを包含しているRtModuleに、updateEventOccurrenceするように命令し、ステップ４３２２でupdateEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ４３２４では、RtModuleが、RtActiveAlarmListに、updateEventOccurrenceするように命令し、それにより、リスト内の既存のエントリを更新する。ステップ４３２７では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送信する。ステップ４３２８では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogは、少なくとも１つのワークステーションクライアントがEventLogレコードの受信に対する監視を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RteventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。

図４３も参照すると、オブジェクト通信図は、「Attribute書込み」方法により、Alarm Attributeの状態が警報状態ではなくなる、警報状態のクリアの肯定応答にも適用できる。Alarm Attributeの警報フィールドは、新しいAlarm状態を反映するために更新され、イベント発生レコードが構築され、必要に応じて、Module、Plant Area、およびワークステーションアプリケーション（Alarm Summary、Event Journal）に送信される。Attribute書込み方法が完了すると、現在のAlarm状態は「Inactive／Acknowledged」である。この警報に関するカレント警報情報は、Moduleにより削除された。新規イベント発生レコードが構築され、このDevice内のこのPlant Areaを監視しているデバイスへの伝送のために待ち行列に入れられた。

ステップ４３１０では、RtAlarmAttributeが、writeAttributeを受け取り、それによりブールAttributeの状態遷移は警報状態ではなくなる。ステップ４３１２では、RtAlarmAttributeが、AttributeとModule Alarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ４３１６では、RtAlarmAttributeが、新しい警報状態、「Active／Unacknowledged」状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ４３１８では、RtAlarmAttributeが、RtEventOCcurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ４３２０では、RtAlarmAttributeが、新しいRtEventOCcurrenceRecordを構築する。既存の警報がクリアされるため、RtAlarmAttributeは、RtAlarmAttributeを包含しているRtModuleに、updateEventOccurrenceするように命令し、updateEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ４３２２では、RtModuleが、RtActiveAlarmListに、updateEventOccurrenceするように命令し、それによりリスト中の既存のエントリを更新する．ステップ４３２６では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaにRtEventOccurrenceRecordを送信する。ステップ４３２８では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogが、少なくとも１つのワークステーションクライアントが、EventLogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogrecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。

また、図４３を参照すると、オブジェクト通信図は、Alarm AttributeのENABフィールドをFALSEにさせることによって、警報を使用不能にすること（disablement）にも適用できる。Alarm Attributeの警報フィールドは、新しいAlarm状態を反映する為に更新され、イベント発生レコードが構築され、必要に応じて、Module，Plant Area、およびワークステーションアプリケーション（Alarm Sumaary，Event Journal）に送信される。警報が使用不能にされた後、カレントAlarm状態は「Inactive／Acknowledged」であり、ENABフィールドはFALSである。この警報のカレント警報情報は、Moduleによって削除された。新規イベント発生レコード（警報DISABLE）が構築され、このDevice内のこのPlant Areaを監視しているデバイスへの伝送のために待ち行列に入れられた。

ステップ４３１０では、ENAB FieldをFALSEにさせる、RtalarmAttributeが、writeAttributeを受け取る。ステップ４３１６では、RtAlarmAttributeが、新しい警報状態、「Active／Unacknowledged」状態を計算し、指数としてAlarmTypeを使用してRteventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ４３１８では、RtAlarmAttributeが、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ４３２０では、RtAlarmAttributeが、新しいRtEvedntOccurrenceRecordを構築し、このイベントを警報ディスエーブルイベントとして識別する。過去にアクティブであるときに警報がディスエーブルされるため、このイベントは、既存の警報をクリアすることであり、RtAlarmAtributeは、RtAlarmAttributeを包含しているRtModuleに、clearEventOccurrenceするように命令し、clearEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ４３２２では、RtModuleが、RtActiveAlarmListに、clearEventOccurrenceするように命令し、それによって既存のエントリをリストから削除する。ステップ４３２６では、ＲｔＭｏｄｕｌｅが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送信する。ステップ４３２８では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogは、少なくとも１つのワークステーションクライアントが、EventLogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。

図４３も参照すると、オブジェクト通信図は、Alarm AttributeのENAB FieldをTRUEにさせることにより警報を使用可能にすること（enablement）にも適用できる。警報
が使用可能になる（enablement）前、ブールAttributeのカレント状態は、Enabledされて
いるのであれば、警報がActiveとなるだろうことを示しており、AutoAckは、AttributeとModuleレベルでFalseである。Alarm Attributeの警報フィールドは、新しいAlarm状態を反映するために更新され、イベント発生レコードが構築され、必要に応じて、Module、Plant Area、およびワークステーションアプリケーション（Alarm Summary、Event Journal
）に送信される。警報が使用不能にされた（disablement）後、カレントAlarm状態は「Ac
tive／Unaknowledged」であり、ＥＮＡＢフィールドはＴＲＵＥである。この警報のカレント警報情報は、Moduleにより記憶される。新規イベント発生レコード（警報Active／Un
acknowledged）が構築され、このDevice内のこのPlant Areaを監視しているデバイスへの伝送のために待ち行列に入れられる。

ステップ４３１０では、RtAlarmAttributeは、writeAttributeを受け取り、それによってENAB FieldはTRUEになる。ステップ４３１２では、RtAlarmAttributeが、AttriguteとModule Alarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ４３１４では、RtAlarmAttributeが、AttributeとModule Alarm］の両方にとって、AUTOACKがDISABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmAutoackステータスを得る。ステップ４３１６では、RtAlarmAttributeは、新しい警報状態、「Active／Unacknowledged」状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ４３１８では、RtAlarmAttributeが、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ４３２０では、RtAlarmAttributeが、新しいRtEventOccurrenceRecordを構築する．警報は新しいため、RtAlarmAttributeは、RtAlarmAttributeを包含しているRtModuleに、addEventOccurrenceするように命令し、addEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ４３２２では、RtModuleが、RtactiveAlarmListに、addEventOccurrenceするように命令し、それによって、新しいエントリをリストに追加する。ステップ４３２６では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送る。ステップ４３２８では、RtPlantAreaが、そのRtAreaEventLogに、addeventするように命令し、RtAreaEventLogが、少なくとも１つのワークステーションクライアントが、EventLogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。

本発明は、多様な態様に関して説明されてきたが、これらの態様が実例となり、本発明の範囲がそれらに制限されていないことが理解されるだろう。説明されている実施態様の多くの変化、修正、追加、および改善が可能である。

２パーソナルコンピュータ
３イーサネット
４、５ローカル制御装置
６〜１１フィールドデバイス
１２〜１５非プロトコルフィールドデバイス
１００プロセス制御システム
１０２、１０４、１０６ワークステーション
１０８ＬＡＮ
１１０コントローラ
１１２プロセス
１２０制御テンプレートシステム
１２３制御テンプレートライブラリ
１２４テンプレートジェネレータ
１２６属性方法言語ジェネレータ
１２８グラフィックジェネレータ
１３２スマートタイプフィールドデバイス
１３６非スマートタイプフィールドデバイス
４４０制御モジュール

Claims

スマートタイプフィールドデバイス（６）及び非スマートタイプフィールドデバイス（１２）を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム（１００）であって、
前記プロセス制御システムは：フィールドデバイスに接続される複数の分散型コントローラ（１１０）と；
前記複数の分散型コントローラのいくつかに対して選択的にインストールすることができ、当該分散型コントローラのいくつかの上で動作することができる複数の制御ソフトェアであって、前記スマートタイプ及び前記非スマートタイプのフィールドデバイスを組み合わせて制御するための複数の制御ソフトェア（４００）と、
前記プロセス制御システムのために診断監視及び表示プログラムを実行する第１ソフトウエアシステム（４００）と、を備え、
前記診断監視及び表示プログラムは：前記診断監視及び表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義及び作成される複数の診断モジュール（４４０）を含み、
複数の診断モジュールは作成と同時に前記フィールドデバイス及び前記分散型コントローラ間に選択的に配置され、前記診断モジュールは相互に独立して、また並列して動作して診断情報の源（以下、診断情報源という）にアクセスし；
更に、前記複数の診断モジュールから診断情報にアクセスし、前記分散型コントローラ及び前記フィールドデバイスの両方上において動作するプロセスに関する診断情報が診断情報源に関わらず同じように表示されるように、複数の診断モジュールからアクセスされた診断情報を、プロセス制御システム内の全ての診断モジュールのために一様に表示するための表示ルーチンを含むことを特徴とするプロセス制御システム。
前記プロセス制御システムは、第２ソフトウエアシステム（４００）を更に備え、
前記第２ソフトウエアシステムは、前記スマートタイプ及び前記非スマートタイプのフィールドデバイスの間を通信するためのものであるとともに、前記スマートタイプ及び前記非スマートタイプのフィールドデバイスを制御するためのものである、請求項１に記載のプロセス制御システム。
前記第２ソフトウエアシステムは、標準プロトコルにおいて定義される複数のファンクションブロック（５２２）を含み、
前記ファンクションブロックはスマートタイプのフィールドデバイスと非スマートタイプのフィールドデバイスを選択的に制御するために、前記複数の分散型コントローラのいくつかに選択的にインストールすることができ、当該分散型コントローラのいくつかの上で動作することができることを特徴とする請求項２に記載のプロセス制御システム。
前記ファンクションブロックは、スマートタイプのフィールドデバイスと非スマートタイプのフィールドデバイスを選択的に制御するために、複数の分散型コントローラのいくつかの上で動作することができる制御モジュール（４４０）として、選択的に定義可能、作成可能、修正可能、及びインストール可能であることを特徴とする請求項３に記載のプロセス制御システム。
前記第２ソフトウエアシステムは更に：
前記ファンクションブロックを構成し、前記ファンクションブロックを複数の分散型コントローラにインストールするための構成プログラムを含み、当該分散型コントローラは再構成されるまでその構成を保持することを特徴とする請求項３および４のいずれかに記載のプロセス制御システム。
前記複数のファンクションブロックが、通信サービス階層に構成され、前記通信サービス階層は：
同じコントローラの２つのファンクションブロック間、及び異なるコントローラの２つのファンクションブロック間でメッセージを伝達するためのリモートオブジェクト通信（ＲＯＣ）レベルと、インターフェイスを介して通信ハードウエアと接続し、通信ハードウエアを通してメッセージを伝達するための低レベル通信レベルとを含むことを特徴とする請求項３、４及び５のいずれか１項に記載のプロセス制御システム。
前記複数の分散型コントローラに接続されるワークステーション（１０２）を更に含み、前記ワークステーションはユーザインターフェイス（３００）を含み；
前記第２ソフトウエアシステムは、プロセス制御システム用のコントロールストラテジーを実現し、前記コントロールストラテジーは前記ユーザインターフェイスを介して前記複数の制御モジュールに選択的に定義、作成、修正され、また割り当てられ、前記複数の制御モジュールは前記スマートタイプ及び前記非スマートタイプのフィールドデバイス、前記複数の分散型コントローラ及びワークステーション間に選択的に配置され、前記制御モジュールは相互に独立して、また並列して機能することを特徴とする請求項２、３、４、５及び６のいずれか１項に記載のプロセス制御システム。
プロセス制御システムとユーザを接続するために、前記制御ソフトウエアに接続されるインターフェイス手段（３００）と；
前記ユーザの指示のもとにプロセス制御コントロールストラテジーを定義、作成、修正、及び実行するためのコントロールストラテジー手段（３８２０）とを更に備え、
前記ユーザは前記コントロールストラテジーを複数のコントロールストラテジーモジュールに選択的に割り当て、また前記ユーザは前記フィールドデバイス、制御手段及びインターフェイス手段間にコントロールストラテジーモジュールを選択的に配置し、コントロールストラテジーモジュールは相互に独立して、また並列して機能することを特徴とする請求項１、２、３、４、５及び６のいずれか１項に記載のプロセス制御システム。
ユーザとインターフェイスを介して接続するためのユーザインターフェイス（３００）を更に備え；
前記スマートタイプのフィールドデバイスと前記非スマートタイプのフィールドデバイスが、定義されたバスベースのアーキテクチャ規格に従って動作し、
前記第２ソフトウエアシステムが前記ユーザインターフェイスを通して前記ユーザにとってトランスペアレントである、標準プロトコルの制御操作及び非標準プロトコルの制御操作を実施することを特徴とする請求項１、２、３、４、５，６，７、及び８のいずれか１項に記載のプロセス制御システム。
前記定義されたバスベースのアーキテクチャ規格は、定義されたフィールドバスアーキテクチャ規格を含むことを特徴とする請求項９に記載のプロセス制御システム。
前記フィールドデバイスは、スマートタイプのフィールドデバイス（１３２）を含み、前記フィールドデバイスは、非スマートタイプのフィールドデバイス（１３６）を含むことを特徴とする請求項１、２、３、４、５，６，７、８，９及び１０のいずれか１項に記載のプロセス制御システム。
プロセス制御システム（１００）であって、
診断情報の源（以下、診断情報源という）を含むフィールドデバイス（１３２、１３６）と；
前記フィールドデバイスに接続されるコントローラ（１１０）と；
前記コントローラに接続され、ユーザインターフェイス（３００）を含むワークステーション（１０２）と；
プロセス制御システムのために診断監視及び表示プログラムを実行するソフトウエアシステム（４００）とを備え、
前記診断監視及び表示プログラムは：前記診断監視及び表示プログラムを使用してアクセスするために、前記ユーザインターフェイスを介して選択的に定義・作成される複数の診断モジュール（４４０）を含み、
複数の診断モジュールは作成と同時に前記フィールドデバイス、前記コントローラ及び前記ワークステーション間に選択的に配置され、前記診断モジュールは相互に独立して、また並列して動作して前記診断情報源にアクセスし；
更に、前記複数の診断モジュールから診断情報にアクセスし、前記コントローラ及び前記フィールドデバイスの両方上において動作するプロセスに関する診断情報が診断情報源に関わらず同じように表示されるように、複数の診断モジュールからアクセスされた診断情報を、プロセス制御システム内の全ての診断モジュールのために一様に表示するための表示ルーチンを含むことを特徴とするプロセス制御システム。
前記ソフトウエアシステムは、プロセスコントロールストラテジーを選択的に実現するための複数の制御モジュール（４４０）を更に備え、
前記表示ルーチンは、複数の制御モジュールからコントロールストラテジーにアクセスし、更に診断情報と制御情報が同じようにアクセスされるように、複数の診断モジュールからアクセスされた診断情報と、複数の制御モジュールからアクセスされたコントロールストラテジーを各々表示するための表示ルーチンを含むことを特徴とする請求項１２に記載のプロセス制御システム。
前記表示ルーチンは、複数の診断モジュールから診断情報にアクセスし、コントローラ及びフィールドデバイスの両方上において動作するプロセスに関する診断情報が一箇所で発生されたものとして表示されるように、コントロールストラテジーと複数の診断モジュールからアクセスされた診断情報とを一様に表示することを特徴とする請求項１３に記載のプロセス制御システム。
前記複数の診断モジュールが、ユーザによって選択的に定義及び作成され、選択的に配置される、請求項１２、１３、及び１４のいずれか１項に記載のプロセス制御システム。
前記フィールドデバイスが制御要素を含み；また
複数の診断モジュールの内の１つの診断モジュールが前記フィールドデバイスに配置され、前記制御要素の状態またはステータスを監視する、請求項１２、１３、及び１４のいずれか１項に記載のプロセス制御システム。
更に、コントローラに接続されるネットワーク（１０８）と；
実時間のデータ、履歴情報、イベント統計表、構成データ及び診断情報を含むデバイス情報が、ネットワーク標準通信機関を使用してアクセスされるように、前記ネットワークを通してコントローラに接続される外部ノードとを備える、請求項１２、１３、及び１４のいずれか１項に記載のプロセス制御システム。
プロセスを制御するためのプロセス制御システム（１００）であって、前記プロセス制御システムは：
前記プロセスに接続されるコントローラ（１１０）；及び
前記コントローラで実行され、前記プロセスを制御するためのコントロールストラテジーを実現するソフトウエアシステム（４００）を備え、前記コントロールストラテジーは１以上のプリミティブのみを含む要素モジュールと複合モジュールとを含むモジュールの階層によって定義されることを特徴とするプロセス制御システム。
前記コントロールストラテジーは、コンテナクラスのオブジェクトである複数の制御モジュール（４４０）によって定義され、複数の制御モジュールの内の１つの制御モジュールが指定されたタスクと既定義された外部インターフェイス（３００）とを有し、制御モジュールはソフトウエアシステム内に含まれ、既定義された外部インターフェイスを通してアクセスされるので、制御モジュールがユーザ修正可能となることを特徴とする請求項１８に記載のプロセス制御システム。
前記プロセスがフィールドデバイスを含み、また
要素モジュールがフィールドバス標準プロトコルに従って定義される基本的なフンクションブロックである、請求項１８又は１９のいずれかに記載のプロセス制御システム。
更に、コントロールストラテジーを指定するためにコントローラに接続されるユーザインターフェイス（３００）を備え、コントロールストラテジーは構成要素モジュール間の相互接続により、また構成要素モジュールの入力／出力接続により、構成要素のモジュールと複合モジュールのモジュールタイプによってユーザにより指定される、請求項１８又は１９のいずれかに記載のプロセス制御システム。
コントロールストラテジーを修正するためのユーザインターフェイスが複数のプロセス制御プログラミング言語で実行される、請求項２１に記載のプロセス制御システム。
前記ソフトウエアシステムは更に、コントロールストラテジーを定義し、コントローラに対してコントロールストラテジーをインストールするための構成プログラムを含み、コントローラは再構成されるまでその構成を保持する、請求項１８又は１９のいずれかに記載のプロセス制御システム。