"スマートタイプのフィールドデバイス132及び非スマートタイプのフィールドデバイス136を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100であって、前記プロセス制御システムは:フィールドデバイスに接続される複数の配置されたコントローラ110と;複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができる複数の制御モジュール440を含むソフトウエアシステムとを備え、前記ソフトウエアシステムはスマートタイプ及び非スマートタイプのフィールドデバイスと通信し、またスマートタイプ及び非スマートタイプのフィールドデバイスを制御するためのものであることを特徴とするプロセス制御システム。前記ソフトウエアシステムは更に:制御モジュールを構成し、制御モジュールを複数の配置されたコントローラにインストールするための構成プログラムを含み、配置されたコントローラは再構成されるまでその構成を保持する、請求項1に記載のプロセス制御システム。請求項1に記載のプロセス制御システムであって、複数の制御モジュールが通信サービスハイアラーキーに構成され、前記通信サービスハイアラーキーは:同じコントローラの2つの制御モジュール間、及び異なるコントローラの2つの制御モジュール間でメッセージを伝達するためのリモートオブジェクト通信ROCレベルと、通信ハードウエアとインターフェイスを介して接続し、通信ハードウエアを通してメッセージを伝達するための低レベル通信レベルとを含むことを特徴とするプロセス制御システム。スマートタイプのフィールドデバイス132及び非スマートタイプのフィールドデバイス136を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100であって、前記プロセス制御システムは:フィールドデバイスに接続される複数の配置されたコントローラと;組み合わせて、スマートタイプ及び非スマートタイプのフィールドデバイスを制御するために、複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができる複数の制御手段とを備えることを特徴とするプロセス制御システム。プロセス制御システム100であって、スマートタイプのフィールドデバイス132及び非スマートタイプのフィールドデバイス136を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイス;フィールドデバイスに接続される複数の配置されたコントローラ110;配置されたコントローラに接続されるワークステーション102;及び組み合わせて、スマートタイプ及び非スマートタイプのフィールドデバイスを制御するために、複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができる複数の制御手段を備えることを特徴とするプロセス制御システム。コンピュータプログラム製品であって:スマートタイプのフィールドデバイス132及び非スマートタイプのフィールドデバイス136を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御ソフトウエアシステムを含む、その中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、前記プロセス制御システム100はフィールドデバイスに接続される複数の配置されたコントローラ110を含み、実行できるプログラムコードは:複数の配置されたコントローラの1つに選択的にインストールすることができ、影響を及ぼすことができる複数の制御モジュール440を含むソフトウエアシステムと;スマートタイプ及び非スマートタイプのフィールドデバイスと通信し、スマートタイプ及び非スマートタイプのフィールドデバイスを制御するための通信制御ルーチンとを含むことを特徴とするコンピュータプログラム製品。請求項6に記載のコンピュータプログラム製品であって、実行できるプログラムコードは更に:ユーザとインターフェイスを介して接続するためのユーザインターフェイスを備え、スマートタイプと非スマートタイプのフィールドデバイスがバスベースのアーキテクチャ規格に従って動作し、ソフトウエアシステムがユーザインターフェイスを通してユーザにとってトランスペアレントである、スマートタイプの制御操作と非スマートタイプの制御操作を実施することを特徴とするコンピュータプログラム製品。ソフトウエアシステムがスマートタイプのフィールドデバイスに作用する複数の配置されたコントローラに配置された複数の制御モジュールを使用して、スマートタイプの制御操作を実施し、また独立して、また同時に、並列に非スマートタイプのフィールドデバイスに作用する非スマートタイプの操作を実施する、請求項6に記載のコンピュータプログラム製品。ソフトウエアシステムは更に:制御モジュールを構成し、制御モジュールを複数の配置されたコントローラに設置するための構成プログラムを含み、配置されたコントローラは再構成されるまでその構成を保持する、請求項6に記載のコンピュータプログラム製品。請求項6に記載のコンピュータプログラム製品であって、複数の制御モジュールが通信サービスハイアラーキーに構成され、前記通信サービスハイアラーキーは:同じコントローラの2つの制御モジュール間、及び異なるコントローラの2つの制御モジュール間でメッセージを伝達するためのリモートオブジェクト通信ROCレベルと、通信ハードウエアとインターフェイスを介して接続し、通信ハードウエアを通してメッセージを伝達するための低レベル通信レベルとを含むことを特徴とするコンピュータプログラム製品。標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100であって、前記プロセス制御システムは:フィールドデバイスに接続される複数の配置されたコントローラ110と;標準プロトコールにおいて定義される複数の機能ブロック522を含むソフトウエアシステムとを備え、機能ブロックは標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスを選択的に制御するために、複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができることを特徴とするプロセス制御システム。標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100であって、前記プロセス制御システムは:フィールドデバイスに接続される複数の配置されたコントローラ110と;組み合わせて、標準プロトコール及び非標準プロトコールのフィールドデバイスを制御する複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができる複数の制御手段とを備えることを特徴とするプロセス制御システム。プロセス制御システム100であって、標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイス;フィールドデバイスに接続される複数の配置されたコントローラ110;配置されたコントローラに接続されるワークステーション102;及び標準プロトコールにおいて定義される複数の機能ブロック522を含むソフトウエアシステムとを備え、機能ブロックは標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスを選択的に制御するために、複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができることを特徴とするプロセス制御システム。標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100であって、前記プロセス制御システムは:フィールドデバイスに接続される複数の配置されたコントローラ110と;標準プロトコールにおいて定義される複数の機能ブロック522を含むソフトウエアシステムとを備え、機能ブロックは標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスを選択的に制御するために、複数の配置されたコントローラの1つに対して影響を及ぼすことができる制御モジュールとして、選択的に定義可能、作成可能、修正可能、及びインストール可能であることを特徴とするプロセス制御システム。プロセス制御システム100であって、標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイス;フィールドデバイスに接続される複数の配置されたコントローラ110;配置されたコントローラに接続されるワークステーション102;及び標準プロトコールにおいて定義される複数の機能ブロック522を含むソフトウエアシステムとを備え、機能ブロックは標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスを選択的に制御するために、複数の配置されたコントローラの1つに対して影響を及ぼすことができる制御モジュールとして、選択的に定義可能、作成可能、修正可能、及びインストール可能であることを特徴とするプロセス制御システム。標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100であって、前記プロセス制御システムは:フィールドデバイスに接続される複数の配置されたコントローラ110と;組み合わせて、標準プロトコール及び非標準プロトコールのフィールドデバイスを制御する複数の配置されたコントローラの1つに対して選択的に定義可能、作成可能、修正可能、及びインストール可能である複数の制御手段440とを備えることを特徴とするプロセス制御システム。請求項11、12、13、14、15及び16のいずれか1項に記載のプロセス制御システムであって、更に:ユーザとインターフェイスを介して接続するためのユーザインターフェイス300を備え;標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスが定義されたフィールドバスアーキテクチャ規格に従って動作し、ソフトウエアシステムがユーザインターフェイスを通してユーザにとってトランスペアレントである、標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスに対する標準プロトコールの制御操作を実施することを特徴とするプロセス制御システム。ソフトウエアシステムは更に:機能ブロックを構成し、機能ブロックを複数の配置されたコントローラにインストールするための構成プログラムを含み、配置されたコントローラは再構成されるまでその構成を保持する、請求項11、12、13、14、15及び16のいずれか1項に記載のプロセス制御システム。請求項11、12、13、14、15及び16のいずれか1項に記載のプロセス制御システムであって、複数の機能ブロックが通信サービスハイアラーキーに構成され、前記通信サービスハイアラーキーは:同じコントローラの2つの機能ブロック間、及び異なるコントローラの2つの機能ブロック間でメッセージを伝達するためのリモートオブジェクト通信ROCレベルと、通信ハードウエアとインターフェイスを介して接続し、通信ハードウエアを通してメッセージを伝達するための低レベル通信レベルとを含むことを特徴とするプロセス制御システム。コンピュータプログラム製品であって:標準プロトコールのフィールドデバイス6及び非標準プロトコールのフィールドデバイス12を含む、多数の異なるフィールドデバイスタイプの複数のフィールドデバイスを制御するためのプロセス制御システム100を含む、その中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、前記プロセス制御システムはフィールドデバイスに接続される複数の配置されたコントローラ110を含み、実行できるプログラムコードは:標準プロトコールにおいて定義される複数の機能ブロック522を含むソフトウエアシステムを備え、機能ブロックは標準プロトコールのフィールドデバイスと非標準プロトコールのフィールドデバイスを選択的に制御するために、複数の配置されたコントローラの1つに対して選択的にインストールすることができ、影響を及ぼすことができることを特徴とするコンピュータプログラム製品。プロセス制御システム100であって、フィールドデバイス;フィールドデバイスに接続されるコントローラ110;コントローラに接続されるワークステーション102、ワークステーションはユーザインターフェイス300を含み;及びプロセス制御システム用の制御戦略を実行するソフトウエアシステムとを備え、制御戦略はユーザインターフェイスを介して複数の制御戦略モジュールに選択的に定義、作成、修正され、また割り当てられ、複数の制御戦略モジュールはフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、制御戦略モジュールは相互に独立して、また並列して機能することを特徴とするプロセス制御システム。プロセス制御システム100であって、フィールドデバイスと;フィールドデバイスを制御するためにフィールドデバイスに接続される制御手段と;インターフェイスを介して制御プロセスシステムとユーザを接続するために、制御手段に接続されるインターフェイス手段と;ユーザの指示のもとにプロセス制御戦略を定義、作成、修正、及び実行するための制御戦略手段とを備え、ユーザは制御戦略手段を複数の制御戦略モジュールに選択的に割り当て、またユーザはフィールドデバイス、制御手段及びインターフェイス手段間に制御戦略モジュールを選択的に配置し、制御戦略モジュールは相互に独立して、また並列して機能することを特徴とするプロセス制御システム。請求項21または22に記載のプロセス制御システムであって:ソフトウエアシステムが更に、プロセス制御システムとユーザとをインターフェイスを介して接続するためのユーザインターフェイスを含み;また制御戦略が選択的に定義、作成、修正され、また割り当てられ、複数の制御戦略モジュールがユーザによって選択的に配置されることを特徴とするプロセス制御システム。請求項21または22に記載のプロセス制御システムであって:フィールドデバイスが制御要素を含み;また制御戦略がフィールドデバイス制御要素に対して配置される制御戦略モジュールを含むことを特徴とするプロセス制御システム。請求項21または22に記載のプロセス制御システムであって:フィールドデバイスが制御要素を含むフィールドバス標準デバイスであり;また制御戦略モジュールが制御要素に対して配置され、Fieldbus標準機能ブロック、または注文のユーザが定義する制御モジュールとして、選択的に動作することを特徴とするプロセス制御システム。請求項21または22に記載のプロセス制御システムであって、ソフトウエアシステムが更に:制御戦略モジュールを定義、作成、構成し、制御戦略モジュールをフィールドデバイス、コントローラ及びワークステーション間にインストールするための構成プログラムを含み、配置されたコントローラが再構成されるまでその構成を保持することを特徴とするプロセス制御システム。請求項21または22に記載のプロセス制御システムであって:ユーザが作成する注文制御戦略モジュールによって、制御戦略モジュールが選択的に定義、修正及び作成され;またフィールドデバイス、コントローラ及びワークステーションのうち選択された1つに対して選択された制御戦略モジュールを転送することによって、制御戦略モジュールが選択的に配置されることを特徴とするプロセス制御システム。請求項21または22に記載のプロセス制御システムであって:複数の制御戦略モジュールが通信サービスハイアラーキーに構成され、前記通信サービスハイアラーキーは:同じコントローラの2つの制御戦略モジュール間、及び異なるコントローラの2つの制御戦略モジュール間でメッセージを伝達するためのリモートオブジェクト通信ROCレベルと、通信ハードウエアとインターフェイスを介して接続し、通信ハードウエアを通してメッセージを伝達するための低レベル通信レベルとを含むことを特徴とするプロセス制御システム。配置されたコントローラ110と配置されたフィールドデバイスを含むプロセス制御システム100を操作する方法であって:プロセス制御操作を実行するステップ;プロセス制御システム操作の実行中に編集プログラムを実行するステップ;編集プログラムを使用して、制御戦略を限定するステップ、前記ステップは;複数の機能ブロック522と制御モジュール440を構築するステップと;配置されたコントローラと配置されたフィールドデバイスの中で、ユーザが指定する機能ブロックと制御モジュールを選択的にダウンロードするステップを含み;コントローラ及びフィールドデバイスに配置された機能ブロックと制御モジュールを、相互に独立して、また並列に実行するステップを備えることを特徴とする方法。フィールドデバイスと、フィールドデバイスに接続されたコントローラ110と、コントローラに接続されたワークステーション102を含むプロセス制御システム100において使用するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品は:プロセス制御ソフトウエアシステム用の制御戦略を実行するソフトウエアシステムを含む、その中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、制御戦略は複数の制御戦略モジュールに選択的に定義可能、作成可能、修正可能及び割り当て可能であり、複数の制御戦略モジュールはフィールドデバイス、コントローラ及びワークステーション間に選択的に配置可能であり、制御戦略モジュールは相互に独立して、また並列に動作することを特徴とするコンピュータプログラム製品。プロセス制御システム100であって、診断情報源を含むフィールドデバイスと;フィールドデバイスに接続されるコントローラ110と;コントローラに接続され、ユーザインターフェイス300を含むワークステーション102と;プロセス制御システムのために診断監視表示プログラムを実行するソフトウエアシステムとを備え、診断監視表示プログラムは:診断監視表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義作成される複数の診断モジュールを含み、複数の診断モジュールは作成と同時にフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作して診断情報源にアクセスし;更に複数の診断モジュールから診断情報にアクセスし、コントローラ及びフィールドデバイスの両方において動作するプロセスに関する診断情報が診断情報源に関わらず同じように表示されるように、複数の診断モジュールからアクセスされた診断情報を、プロセス制御システム内の全ての診断モジュールのために一様に表示するための表示ルーチンを含むことを特徴とするプロセス制御システム。プロセス制御システム100であって、診断情報源を含むフィールドデバイスと;フィールドデバイスに接続されるコントローラ110と;コントローラに接続され、ユーザインターフェイス300を含むワークステーション102と;プロセス制御システムのために診断監視表示プログラムを実行するソフトウエアシステムとを備え、診断監視表示プログラムは:プロセス制御システムを選択的に実施するための複数の制御モジュール440;診断監視表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義作成される複数の診断モジュール、複数の診断モジュールは作成と同時にフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作して診断情報源にアクセスし;及び複数の診断モジュールから診断情報にアクセスし、また複数の制御モジュールから制御計画にアクセスし、更に診断情報と制御情報が同じようにアクセスされるように、複数の診断モジューからアクセスされた診断情報と、複数の制御モジュールからアクセスされた制御戦略を各々表示するための表示ルーチンを含むことを特徴とするプロセス制御システム。プロセス制御システム100であって、複数のフィールドデバイス、複数のフィールドデバイスの内の1つのフィールドデバイスが診断情報源を含み;複数のコントローラ110、複数のコントローラの内の1つのコントローラが複数のフィールドデバイスの内の1つのフィールドデバイスに接続され;コントローラに接続され、ユーザインターフェイス300を含むワークステーション102;及びプロセス制御システムのために診断監視表示プログラムを実行するソフトウエアシステムとを備え、診断監視表示プログラムは:診断監視表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義され、作成される複数の診断モジュールを含み、複数の診断モジュールは作成と同時にフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作し;更にフィールドデバイス、コントローラ及びワークステーションに対して相互に独立して動作する複数の診断モジュールから診断情報にアクセスし、1つ以上のフィールドデバイス、コントローラ及びワークステーションを操作するプロセスに関する診断情報が一箇所で発生されたものとして表示されるように、複数の診断モジュールからアクセスされた診断情報を一様に表示するための表示ルーチンを含むことを特徴とするプロセス制御システム。プロセス制御システム100であって、複数のフィールドデバイス、複数のフィールドデバイスの内の1つのフィールドデバイスが診断情報源を含み;フィールドデバイスを制御するための複数の制御手段、複数の制御手段の内の1つの制御手段が複数のフィールドデバイスの内の1つのフィールドデバイスに接続され;インターフェイスを介して制御プロセスシステムとユーザを接続するために複数の制御手段に接続されるインターフェイス手段;プロセス制御戦略を実行するための診断手段、診断手段は複数の診断モジュールとして選択的に定義作成され、複数の診断モジュールは作成と同時にフィールドデバイス、制御手段及びインターフェイス手段間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作し;更にフィールドデバイス、制御手段及びインターフェイス手段に対して相互に独立して動作する複数の診断モジュールから診断情報にアクセスし、1つ以上のフィールドデバイス、制御手段及びインターフェイス手段を操作するプロセスに関する診断情報が一箇所で発生されたものとして表示されるように、複数の診断モジュールからアクセスされた診断情報を一様に表示するための表示手段を含むことを特徴とするプロセス制御システム。プロセス制御システム100であって、診断情報源を含むフィールドデバイスと;フィールドデバイスに接続されるコントローラ110と;コントローラに接続され、ユーザインターフェイス300を含むワークステーション102と;プロセス制御システムのために診断監視表示プログラムを実行するソフトウエアシステムとを備え、診断監視表示プログラムは:プロセス制御システム用の制御戦略、前記制御戦略は複数の制御戦略モジュールに選択的に割り当てられ、またフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、制御戦略モジュールは相互に独立して、また並列して動作し;診断監視表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義作成される複数の診断モジュール、複数の診断モジュールは作成と同時にフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作して、診断情報源にアクセスし;及び複数の診断モジュールから診断情報にアクセスし、コントローラ及びフィールドデバイスの両方において動作するプロセスに関する診断情報が一箇所で発生されたものとして表示されるように、制御戦略と複数の診断モジューからアクセスされた診断情報とを一様に表示するための表示ルーチンを含むことを特徴とするプロセス制御システム。ユーザによって複数の診断モジュールが選択的に定義作成され、選択的に配置される、請求項31、32、33、34、及び35のいずれか1項に記載のプロセス制御システム。フィールドデバイスが制御要素を含み;また複数の診断モジュールの内の1つの診断モジュールがフィールドデバイスに配置され、制御要素の状態またはステータスを監視する、請求項31、32、33、34、及び35のいずれか1項に記載のプロセス制御システム。更に、コントローラに接続されるネットワークと;実時間のデータ、履歴情報、イベント統計表、構成データ及び診断情報を含むデバイス情報が、ネットワーク標準通信機関を使用してアクセスされるように、ネットワークを通してコントローラに接続される外部ノードとを備える、請求項31、32、33、34、及び35のいずれか1項に記載のプロセス制御システム。コンピュータプログラム製品であって:診断情報源、フィールドデバイスに接続されるコントローラ、及びコントローラに接続され、ユーザインターフェイス300を含むワークステーション102を含むプロセス制御システム100を制御するためにその中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、実行プログラムコードがプロセス制御システム用の診断監視表示プログラムを実行し、診断監視表示プログラムは:診断監視表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義作成される複数の診断モジュール、複数の診断モジュールは作成と同時にフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作して、診断情報源にアクセスし;及び複数の診断モジュールから診断情報にアクセスし、コントローラ及びフィールドデバイスの両方において動作するプロセスに関する診断情報が、診断情報源に関わらず同じように表示されるように、複数の診断モジュールからアクセスされた診断情報を、プロセス制御システム内の全ての診断モジュールのために一様に表示するための表示ルーチンを含むことを特徴とするコンピュータプログラム製品。コンピュータプログラム製品であって:診断情報源を有するフィールドデバイス、フィールドデバイスに接続されるコントローラ、コントローラに接続されるを含むワークステーション102、及びユーザインターフェイス300を含むプロセス制御システム100を制御するために、その中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、計算可能、読取り可能なコードがプロセス制御システム用の診断監視表示プログラムを実行し、診断監視表示プログラムは:プロセス制御戦略を選択的に実行するための複数の制御モジュール440;診断監視表示プログラムを使用してアクセスするために、ユーザインターフェイスを介して選択的に定義作成される複数の診断モジュール、複数の診断モジュールは作成と同時にフィールドデバイス、コントローラ及びワークステーション間に選択的に配置され、診断モジュールは相互に独立して、また並列して動作して、診断情報源にアクセスし;及び複数の診断モジュールから診断情報にアクセスし、また複数の制御モジュールから制御計画にアクセスし、更に診断情報と制御情報が同じようにアクセスされるように、複数の診断モジューからアクセスされた診断情報と、複数の制御モジュールからアクセスされた制御戦略を各々表示するための表示ルーチンを含むことを特徴とするコンピュータプログラム製品。プロセスを制御するための制御システムであって、前記制御システムは:プロセッサに接続されるコントローラ;及びコントローラに対して実行し、プロセスを制御するための制御戦略を実行するソフトウエアシステムを備え、制御戦略は独占的に1つまたはそれ以上の基本要素と複合モジュールを包含する本質的なモジュールを含むモジュールの階層ハイアラーキーによって定義されることを特徴とする制御システム。複数のフィールドデバイスを制御するためのプロセス制御システム100であって、プロセス制御システムは:プロセスを制御するためにフィールドデバイスに接続される複数の配置されたコントローラ110;及び複数の配置されたコントローラに対して実行し、プロセスを制御するための制御戦略を実行するソフトウエアシステムを備え、制御戦略は実行のために複数の配置されたコントローラ間に配置されたモジュールの階層ハイアラーキーによって定義され、モジュールのハイアラーキーは独占的に1つまたはそれ以上の基本要素と複合モジュールを包含する本質的なモジュールを含むことを特徴とするプロセス制御システム。プロセス制御システム100であって、複数のフィールドデバイスと;プロセスを制御するためにフィールドデバイスに接続される複数のコントローラ110と;複数の配置されたコントローラに対して実行し、プロセスを制御するための制御戦略を実行するソフトウエアシステムを備え、制御戦略は実行のために複数の配置されたコントローラと複数のフィールドデバイスの間に配置されたモジュールの階層ハイアラーキーによって定義され、モジュールのハイアラーキーは独占的に1つまたはそれ以上の基本要素と複合モジュールを包含する本質的なモジュールを含むことを特徴とするプロセス制御システム。ユーザの指示のもとにプロセスを制御するための制御システムであって、前記制御システムは:プロセッサに接続されるコントローラ110と;コントローラに対して実行し、プロセスを制御するための制御戦略を実行するソフトウエアシステムとを備え、制御戦略はコンテナクラスのオブジェクトである複数の制御モジュール440によって定義され、複数の制御モジュールの内の1つの制御モジュールが指定されたタスクと既定義された外部インターフェイスとを有し、制御モジュールはソフトウエアシステム内に含まれ、既定義された外部インターフェイスを通してアクセスされるので、制御モジュールがユーザ修正可能となることを特徴とする制御システム。プロセスがフィールドデバイスを含み、また本質的なモジュールがフィールドバス標準プロトコールに従って定義される本質的な機能ブロックである、請求項41、42、43及び44のいずれか1項に記載の制御システム。更に、制御戦略を指定するためにコントローラに接続されるユーザインターフェイスを備え、制御戦略は構成要素モジュール間の相互接続により、また構成要素モジュールの入力/出力接続により、構成要素のモジュールと複合モジュールのモジュールタイプによってユーザにより指定される、請求項41、42、43及び44のいずれか1項に記載の制御システム。制御戦略を修正するためのユーザインターフェイスが複数のプロセス制御プログラミング言語で実行される、請求項46に記載の制御システム。更に、制御戦略を定義し、コントローラに対して制御戦略をインストールするための構成プログラムを含み、コントローラは再構成されるまでその構成を保持する、請求項41、42、43及び44のいずれか1項に記載の制御システム。コンピュータプログラム製品であって:複数のフィールドデバイスを制御するプロセス制御システム100を制御するために、その中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、プロセス制御システムはプロセスを制御するためにフィールドデバイスに接続される複数の配置されたコントローラ110を含み、計算可能、読取り可能なコードは:複数の配置されたコントローラに対して実行し、プロセスを制御するための制御戦略を実行する配置されたソフトウエアシステムを含み、制御戦略は実行のために複数の配置されたコントローラ間に配置されたモジュールの階層ハイアラーキーによって定義され、モジュールのハイアラーキーは独占的に1つまたはそれ以上の基本要素と複合モジュールを包含する本質的なモジュールを含むことを特徴とするコンピュータプログラム製品。コンピュータプログラム製品であって:複数のフィールドデバイスと、プロセスを制御するためにフィールドデバイスに接続される複数の配置されたコントローラ110を含むプロセス制御システム100を制御するために、その中に具体化される計算可能、読取り可能なコードを有するコンピュータで使用できる媒体を備え、計算可能、読取り可能なコードは:複数の配置されたコントローラに対して実行し、プロセスを制御するための制御戦略を実行する配置されたソフトウエアシステムを含み、制御戦略は実行のために複数の配置されたコントローラと複数のフィールドデバイス間に配置されたモジュールの階層ハイアラーキーによって定義され、モジュールのハイアラーキーは独占的に1つまたはそれ以上の基本要素と複合モジュールを包含する本質的なモジュールを含むことを特徴とするコンピュータプログラム製品。プロセス制御システム1必要とされているのは、既存のソリューションをカスタマイズし、自分の特定のプロセス制御機能の開発に対するニーズを満たすために、デザイナーや製造業者だけではなく、ユーザも容易に使用することができる統一、つまり汎用の設計環境である。さらに必要とされているのは、新規および異なる制御機能を実行するために、実質的には任意のサイズのプロセス内で容易に実現され、制御システムデザイナーに補助してもらわなくてもユーザによって更新されるパーソナルコンピュータをベースにしたプロセス制御システムである。多くのプロセス制御システムは、多様な制御機能ルーチンを実現するために、Profibus、Fieldbus、CAN等の特定の制御プロトコルに反応する、弁、モータ、調整器等などのローカルフィールドデバイスを含んでいる。したがって、これらの制御装置は、フィールド内で制御機能性を実現するために一定の標準制御プロトコルに反応する。このような標準制御信号プロトコルを使用することにより、デザイナーはその制御プロトコルに反応するすべてのデバイスから同じ型の制御信号を使用できるため、制御システムを開発する時間および労力を削減することができる。ただし、一定の制御装置は標準制御プロトコルには反応しない。これらのデバイスは、多くの場合、デジタルON/OFF信号、アナログ電流信号、またはアナログ電圧信号などのそれ以外の型の制御信号に反応する。システムデザイナーは、インストールされているプロトコルに無反応であるフィールドデバイスの使用を回避するか、あるいは1つまたは複数のプロトコルの元で動作するシステムを開発しなければならない。したがって、今日の処理システムが、標準プロトコル制御装置と、標準プロトコルの元で定義されている制御信号に反応しないデバイスの両方を活用する能力に欠けているのが不利である。必要とされているのは、1つの標準プロトコルを使用して定義されているデバイスと、それ以外の非プロトコルデバイスの両方を、プロセス制御システムのユーザにとってトランスペアレントに制御するプロセス制御システムである。プロセス制御環境で機能を実行、監視、制御およびフィードバックするシステムは、典型的には、Basic、FortranまたはCなどの高級コンピュータプログラミング言語で作成され、コンピュータまたは制御装置で実行されているソフトウェアにより実現されされる。これらの高級言語は、プロセス制御プログラミングにとって有効ではあるが、通常は、プロセスエンジニア、保守エンジニア、制御エンジニア、オペレータ、および監督者により使用されたり、理解されていない。このような職員のためには、連続機能ブロックおよびはしご型論理などの高級グラフィックディスプレイが開発されてきた。したがって、エンジニア、保守職員、オペレータ、研究所職員等の各人は、自分達が自らの責任に関連した用語でシステムを表示できるようにするプロセス制御システムの要素のグラフィックビューを必要とする。例えば、プロセス制御プログラムがFortranで作成され、2つの入力を必要とし、入力の平均値を計算し、この2つの入力の平均値に等しい出力値を作り出すことがある。このプログラムは、AVERAGE機能と呼ばれ、制御エンジニア向けのグラフィックディスプレイを通して呼び出され、参照されることがある。典型的なグラフィックディスプレイは、2つの入力、1つの出力、およびそのブロックをAVERAGEと指定しているラベルを有している1つの矩形ブロックから成り立っている可能性がある。この同じ関数functionのグラフィック表示を作成し、オペレータが平均値を表示するためには、異なるプログラムが使用されてよい。システムがカスタマに納品される前、これらのソフトウェアプログラムは、既定義ユーザ選択可能機能featuresのライブラリの中に格納される。プログラムは機能ブロックにより特定されている。したがって、ユーザは任意の機能を呼び出し、既定義グラフィック表記を選択し、例えばFortranなどのまったく新しいプログラムを作成するよりはむしろ、プロセス制御ソリューションを定義する上で使用するためのライブラリから複数の機能ブロックの内の1つを選択することにより、オペレータ、エンジニアなど向けのさまざまなビューを作成する。それぞれが関連機能ブロックにより指定されている標準化した機能のグループは、制御ライブラリの中に記憶されてよい。このようなライブラリを備えているデザイナーは、特定のタスクを実行するために、選択されている多様な機能または要素を機能ブロックと、コンピュータディスプレイ画面上で相互接続するころによりプロセス制御ソリューションを設計することができる。マイクロプロセッサまたはコンピュータは、機能ブロックにより定義されている機能または要素を、ライブラリ内に記憶されている既存定義テンプレートと対応させ、プログラム機能または要素のそれぞれをデザイナーにより希望されている相互接続に従って互いに関係付ける。理想的には、デザイナーは、Fortranやその他の高級プログラミング言語で1行のコードも作成しないで、既定義関数のグラフィックビューを使用し、完全なプロセス制御プログラムを設計することができるだろう。プロセス制御プログラミングのためにグラフィックビューを使用することにまつわる1つの問題点とは、既存のシステムを使用すると、この装置のユーザではなく装置製造業者だけが、対応するグラフィックビューとともに独自の制御関数を作成したり、提供されているライブラリ内で既定義機能を修正することができるという点である。新規プロセス制御関数は、おもに、企業により供給されている機能の標準セットの一部ではない機能に対する特定のニーズを持っている可能性のあるエンドユーザによってではなく、設計システムを販売する企業によって設計される。標準化した機能は、エンドユーザに対しシステムに備えられている制御ライブラリ内に記憶されている。エンドユーザは、設計環境に付随している既存の機能を活用するか、あるいは自分達のために所望の特定のカスタマイズされている機能を開発するための設計環境を供給する企業に依存しなければならない。デザイナーがエンジニアのビューのパラメータを修正するように依頼される場合、多くの場合機能プログラムおよびビュープログラムは独立して開発されており、1つの統合されている開発環境の一部ではないため、それらのパラメータを使用している他のすべてのビューも相応して作成し直され、修正されなければならない。このような手順が非常に厄介で、高価、かつ時間を要することは明らかである。既存のプロセス制御システムでの別の問題点とは、典型的には、ネットワーク内で中央制御装置を利用し、専門化されているユーザ定義制御タスク用にカスタマイズされているプログラムコードを実行する、集中制御の使用である。その結果、プロセス制御システムは、典型的にはある特定のサイズに制約され、発生してくるニーズに経時的に適応することが困難である。同様に、従来のプロセス制御システムは、構成という点で柔軟性に欠けており、多くの場合、新しいデバイスが組み込まれるとシステム全体に対する完全なソフトウェア改訂を必要とする。さらに、従来のプロセス制御システムは高価で、通常、制御システム全体の構成とプログラミングに精通している専門家によって新規機能を実行するために改変または再プログラミングされているだけである、当初ユーザまたはシステムデザイナーにより特定される機能上で実行する傾向がある。既存のプロセス制御システムでのさらなる問題点とは、幅広い範囲の知能を有している制御装置およびフィールドデバイスを含む、異なるシステムの物理的なインプリメンテーションがきわめて可変であるという点である。例えば、弁、モータ、および調整器などの、計算能力や制御能力を備えていないフィールドデバイスもある。高水準の制御自立性autonomyを備えている可能性のあるフィールドデバイスもある。所望の制御タスクを達成するほど十分な量ではないが、ある程度のコンピュータ使用の長所を備えている可能性のあるそれ以外のデバイスもある。必要とされているのは、プロセスの物理的な制約まで制御プロセスをカスタマイズし、多様な制御装置とデバイスの制御機能を活用し、希望時にこれらの制御機能を補足し、プロセス制御システム全体で制御機能性を分散させ、プロセス制御機能の開発に対する特定のニーズを満たすために、デザイナーや製造業者だけではなくユーザも容易に使用することができる統一、つまり汎用の設計環境である。さらに必要とされているのは、新規および異なった制御機能を、これらの制御機能を中心レベル、中間レベルおよび周辺レベルすべてを含む制御システム全体に分散させることにより実行するために、実質的には任意のサイズのプロセス内で容易に実現され、制御システムデザイナーに補助してもらわなくてもユーザによって更新されるパーソナルコンピュータをベースにしたプロセス制御システムである。診断情報とは、あるプロセス制御システム内で監視し、表示するために有用である1つのタイプの情報である。しかしながら、プロセス制御システム内では多岐に渡るフィールドデバイスを含む多様な型のデバイスが使用されており、診断情報は、通常、あるデバイスから次のデバイスで一貫して監視されていない。さらに、診断情報は、典型的には、制御装置とデバイス、または複数のデバイスと制御装置の組み合わされた動作などの、制御システムの複数の部分の相互作用に関係する。1つのシステム中の複数の回路に関係している診断情報は、典型的には、既存のプロセス制御システムにより取り扱われない。診断情報は、診断情報監視時に発生している多様な制御動作に関係付けられるときにもっとも有用である。従来のプロセス制御システムは、典型的には、診断試験中に機能している制御動作や制御体系とは関係なく診断情報にアクセスし、表示する。診断ディスプレイ用グラフィックビューの使用にまつわる1つの問題点とは、既存のシステムを使用すると、この装置のユーザではなく装置の製造業者だけが、対応するグラフィックビューとともに監視される診断情報を定義したり、提供されているライブラリ内で既定義診断機能を修正できるという点である。必要とされているのは、プロセス制御システムの可変数のおよび可変型のデバイスと構成要素向けに診断動作の監視およびディスプレイをカスタマイズするために、デザイナーや製造業者だけではなくユーザも使用することのできる統一、つまり汎用の設計環境である。さらに必要とされているのは、プロセスフィールドデバイスの多様な組み合わせのために診断情報を監視し、表示するために、実質的には任意のサイズのプロセス内で容易に実現され、制御システムデザイナーに補助してもらわなくてもユーザによって更新される柔軟な診断監視表示機能性を含むパーソナルコンピュータをベースにしたプロセス制御システムである。従来のプロセス制御システムにおいては、典型的には、ローカルフィールドデバイスは、多くの場合、携帯フィールドプログラマを使用して、ローカルフィールドデバイスを個別にプログラミングすることにより、フィールド内で構成される。フィールドデバイスの個別プログラミングは時間を要し、非効率であり、多くの場合、個々のデバイスが独立してプログラミングされているときシステムのグローバルビューを持続させることはさらに困難であるため、デバイス構成と、プロセス制御システム内のその他のデバイスと制御装置の構成の間での非互換性につながる。複数の異なるプログラミングデバイスは、典型的には、それぞれ異なるフィールドデバイスをプログラミングするために使用されなければならないので、個々のプログラミングデバイスの使用は不便である。さらに、一時的な故障や局所的な停電powerdisruptionsを含むローカルデバイスの故障は、それぞれの故障中のデバイスを局所的に構成し直す必要があるため、制御システム全体の動作を中断し、ダウンタイムの延長を引き起こすこともある。必要とされているのは、個々のフィールドデバイスをローカルな独立したプログラミングを行わないで構成できるようにするプロセス制御システムである。さらに必要とされているのは、適切にグローバルに構成されている周辺要素が、制御機能性を達成するために独立して動作できるようにする一方、互換性のあるグローバルな構成が達成されるようにローカルフィールドデバイスから離れた場所からのグローバルシステムの構成を可能にするプロセス制御システムである。グローバルシステムの構成は、システムを構成する特定のフィールドデバイスを記述するパラメータに基づく。しかしながら、フィールドデバイスと通信するための制御プロトコルが、システムを構成するのに十分であるパラメータを伝達するには不十分である場合がある。例えば、フィールドバスプロトコルのシステム管理仕様は、INITIALIZED状態、UNINITIALIZED状態、およびシステム管理稼動SMOPERATIONAL状態を含む、デバイスにとっての3つの状態を定義する。この3つの定義された状態は、システム管理の観点からデバイスの動作を記述するには十分であるが、フィールドバスインタフェースまたはデバイスのステータスを分析、制御または表示するためのソフトウェアエンジニアリングツールのどちらかの観点からデバイスを記述するには不適当である。この不十分さは、構成が、UNINITIALIZED状態でフィールドバスリンクに接続されているデバイスを作動させるという動作を含むときにきわめて顕著である。さらに必要とされているのは、フィールドバスデバイスの状態を区別し、デバイスの自動検知をサポートし、デバイスのアドレス割当てを概略する、プロセス制御システムである。複数の制御言語が、ユーザが制御戦略を実現するのを補助するIEC-1131規格の元で開発されてきた。これらの制御言語は、機能ブロック、順次機能チャート、はしご型論理、および構造化テキストを含む。これらの言語のそれぞれは、制御エンジニア、制御システムデザイナー、技術者、オペレータ、および保守作業員を含む、ある特定の種類のユーザに向けられている。これらのユーザは、大きく異なるレベルと経験領域、訓練、および専門知識を持つ。典型的には、さまざまなユーザは、大きく異なる観点から制御システムを表示し、さまざまに表現されている、非常に異なっている問題に対する1つのソリューションを求める。例えば、制御システムデザイナーの制御構成ビューは、保守作業員には無意味である可能性もあれば、その逆の可能性もある。必要とされているのは、ある特定の種類のユーザにとって、もっとも理解でき、かつ有益である様式で構成を柔軟に提示するユーザインタフェースである。警報イベント情報は、プロセス制御システムで監視、表示するには非常に重大である1つの種類の情報である。しかしながら、プロセス制御システムで内では、多岐に渡るフィールドデバイスを含む多様な型のデバイスが使用されており、警報情報は、通常、有効に監視されていない。例えば、特定の警報に関して非常に異なった緊急性が存在することがある。緊急性のないなんらかの日常的な点検が行われなければならないことをただ示しているだけの警報状態もある。即座の注意を必要とする警報状態もある。プロセス制御システム内の一定のデバイスは、きわめて重大な状態を測定することもあるが、それ以外のデバイスははるかに緊急性のない情報を監視する。さらに、制御システムの複数の部分の相互作用、例えば、制御装置とデバイスあるいは複数のデバイスと制御装置の組み合わされた動作の情報に関係がある重要な警報状態もある。1つのシステム中の複数の回路およびデバイスの関係する警報状態は、典型的には、既存のプロセス制御システムによって取り扱われていない。警報イベント情報は、状態監視時に発生する多様な制御動作に関係付けられるときにもっとも有用である。従来のプロセス制御システムは、典型的には、診断試験中に機能している制御動作や制御体系に関係なく警報情報にアクセスし、表示する。従来のプロセス制御システムは、通常、さまざまな警報状態とイベントの優先順位を設定するための一貫したシステムを有していない。警報イベントディスプレイのためにグラフィックビューを使用することにまつわる1つの問題点とは、既存のシステムを使用すると、この装置のユーザではなく装置製造業者だけが、関連グラフィックビューとともに、監視されなければならない警報とイベントを定義したり、既定義イベント優先順位を修正できるという点である。異なる種類のユーザが、プロセス制御システムのさまざまな態様を視覚化する必要がある可能性がある。例えば、制御システムのいくつかの動作態様だけを変更する能力のあるユーザもいる。別のユーザにより制御される可能性のあるそれ以外のイベントに対しては、警報情報が緊急に必要とされていないが、これらのユーザは、自分達が制御できる状態情報に対するアクセスを必要とする。必要とされているのは、警報イベント情報の表示に優先順位を設定するために、デザイナーや製造業者だけではなく、ユーザも容易に使用することのできる統一、つまり汎用の設計環境である。本発明の開示に従って、プロセス制御装置は、デバイス間での通信および制御が、標準制御動作がユーザにとってトランスペアレントであるように実行されるように、スマートフィールドデバイス規格および他のバスベースアーキテクチャ規格を実現する。プロセス制御装置を使用すると、スマートデバイスおよび従来の非スマートデバイスを含む、理論的にかつ実質的には無制限の数および型のフィールドデバイスに対する接続が可能になる。多様な数および型のデバイスの制御動作および通信動作は、同時に、並行して実行される。説明された設計環境は、プロセス制御デザイナーまたはユーザが、標準プロセス制御機能を修正したり、一意のカスタマイズされたプロセス制御機能を作成し、すべて1つの共通した環境内にある修正済みのまたは新規に作成されたプロセス制御機能に対応するグラフィックビューを作成できるようにする。設計環境は、機能の作成、およびエンジニアの機能が修正されたり、作成されると、修正または作成が機能のそれ以外のすべてのグラフィックビューにそれ自体を明示するように、それに関連するエンジニア、オペレータ、研究所職員と保守職員またはその他の希望されるユーザの両方にとって1つの共通したインタフェースを含む。さらに、設計環境は、属性と方法の1つの共通したデータベース構造を有しており、グラフィックは、修正済みまたは作成済みのプロセス制御機能を、他の希望されるグラフィックビューのような多様なエンジニア、オペレータ、研究所職員および保守職員により必要とされる、はしご型論理、連続機能ブロックまたはその他の設計言語などによってであろうと、デザイナーが希望するか、あるいは必要とするどんなグラフィック方法論においても表現できるようにするためのプロセス制御関数に関連している。多くの利点は、前記システムおよび操作方法により達成される。1つの利点は、制御動作が、制御システムを通して分散されており、集中制御から生じる柔軟性の欠如を回避するという点である。別の利点は、制御システムがパーソナルコンピュータPCベースであるため、メインフレームベースのシステムに比較して安価であり、追加プロセスがシステムに追加されるにつれて容易にアップグレードされ、便利に複数ユーザによって操作されるという点である。PCベースの制御は、さらに、Windows95TMおよびWindowsNTTMなどのユーザフレンドリなプログラミングとディスプレイプラットホームを可能にする点で有利である。本発明に従って、プロセス制御装置は、標準型制御が非標準型デバイスに関して達成されるように、標準プロトコルにより定義されている機能ブロックまたは制御機能の標準セットを実現、実行する。そのプロセス制御装置により、標準デバイスは、関数ブロックおよび制御関数の標準セットを実現できる。プロセス制御装置は、機能ブロックを制御構造用の根本的なビルディングブロックとして使用することにより、すべての接続されているデバイスが標準デバイスであるかのように相対的な戦略を実現する。これらの機能ブロックは、すべての型のデバイス向けの制御構造を作成するように定義される。多くの利点が、説明されるシステムおよび方法により得られる。1つの利点とは、接続されているデバイスが標準プロトコルデバイスであるのか、非標準デバイスであるのかに関係なく、システムがきわめて統一されており、それによりシステム信頼性を高めるという点である。追加利点は、多様なデバイスを統一して取り扱うことにより、システム開発費用が大幅に削減されるという点である。別の利点とは、インテリジェントデバイスがインテリジェント機能を活用し、ダムデバイスがそれ以外の制御装置により制御されるように、幅広い異なるフィールドデバイスがサポートされているという点である。追加の利点は、ある特定のルーチンを実行しているソフトウェアルーチンが、きわめて再利用可能であり、ソフトウェア信頼性を高めるという点である。本発明に従って、プロセス制御装置は、フィールドバスデバイスおよび非フィールドバスデバイスなどの分散型制御装置およびフィールドデバイスを含むプロセス制御ネットワーク内で、総体的な、ユーザにより作成された制御戦略を実現する。ユーザは、複数の機能ブロックおよび制御モジュールを構築し、フィールドバスデバイスおよび非フィールドバスデバイスの中に制御戦略のユーザにより指定される部分をダウンロードまたはインストールすることにより、制御戦略を定義する。それ以降、フィールドバスデバイスは、制御戦略のその他の部分に関係なく、総体的な戦略のダウンロードされた部分を自動的に実行する。例えば、フィールドデバイス、制御装置およびワークステーションを含むプロセス制御システム内では、、フィールドデバイスの中にダウンロードまたはインストールされた制御戦略の部分は、制御装置およびワークステーションの制御動作とは無関係に、およびそれらに並行して動作するが、他の制御動作がフィールドバスデバイスを管理し、制御戦略のその他の部分を実現する。説明されるプロセス制御システムおよび操作方法には、多くの利点がある。1つの利点とは、プロセスの物理的な制約まで制御プロセスをカスタマイズするために、多くの多様な専門知識レベル、経験レベルおよび訓練レベルのユーザに対しシステムが統一された汎用設計環境を供給するという点である。追加利点とは、説明されるシステムが、多様な制御装置およびデバイスの制御機能を使用し、希望されるときにこれらの制御機能を補足し、必要に応じて、プロセス制御システム全体に柔軟に制御機能性を分散するという点である。別の利点とは、プロセス制御システムが、新規のおよび異なった制御機能を実行するために、実質的には任意のサイズのプロセス内で容易に実現され、ユーザにより更新されるパーソナルコンピュータをベースにした設計に容易に基づいているという点である。この柔軟性は、すべての中心レベル、中間レベル、および周辺レベルを含む制御システム全体に制御機能を分散することにより達成される。本発明に従って、プロセス制御システムは、複数のデバイスおよびシステム構成要素上で動作するプロセスに関係する診断情報を首尾一貫して表示するための診断監視表示機能性を含む。複数のデバイスおよびシステム構成要素は、典型的には、大幅に異なるデバイス型および操作基準を包含し、プロセス制御システムは、すべてのデバイスに関する診断情報を組み込み、動作制御戦略および診断情報が、あたかもすべての制御動作および診断情報が単一のロケーションで実行されたか、生成されたかのように、この情報を統一した様式でシステムユーザに提示する。ユーザ定義診断プログラムは、機能ブロックと制御モジュールのセットとしてアセンブルされ、属性としてアクセスされている情報構造を含むモジュールとして特定されている相互接続された制御オブジェクトの層のセットとして表現される。情報は、デバイスハイアラーキー属性アドレス指定を使用し、モジュールからのI/O信号の直接アドレス指定をサポートし、I/O機能の使用をバイパスし、I/O機能ブロック動作を回避してアクセスされる。多くの利点は、説明されるプロセス制御方法を使用して達成される。1つの利点は、制御体系および診断監視が同じようにシステム内で構成され、システムリソースを節約し、システム信頼性を高めるという点である。別の利点とは、診断の構成がきわめて用途が広く、広範囲の診断動作を達成するという点である。追加利点とは、同じ表示オブジェクトおよび手順が、構成情報、ステータス情報、診断、および事実上システム内で生成または記憶されているあらゆる他の情報を含む全種類の情報を表示するために使用されるという点である。本発明に従って、デジタル制御システムは、新規制御装置がネットワークに接続されるときを自動的に検知し、新規制御装置に接続されているI/Oポートの数および型を突き止める。デジタル制御システムは、I/Oポート情報をフォーマットし、ユーザによって要求されると表示する。デジタル制御システムプログラムは、入出力I/Oサブシステムを自動的に構成することにより、新規制御装置の検知に応える自動構成プログラムも含む。ユーザは、物理的なスイッチやノードを設定しなくても新規制御装置を追加する。ユーザは、オプションで、デバイスの接続の前に、デバイスに関する構成情報をデータベースに供給する。デバイスの接続時、デバイスは、デバイスで物理的なスイッチを設定しなくても、データベース構成情報を使用して自動的に検知、構成される。本発明の別の態様に従って、制御装置のネットワークへの接続を自動的に検知し、制御装置をネットワークオペレーティングシステムの中に組み込むことは、制御装置をネットワークに接続するステップと、制御装置から要求を送信し、ネットワークアドレス割当てを確認するステップとを含み、要求には、制御装置メディアアクセス制御MACアドレスが付随し、ネットワーク構成サービスは確認のために要求を受信し、応答する。ネットワーク構成サービスは、一致するMACアドレスを求めて構成済みデバイスのテーブルを検索するステップと、MACアドレスが一致すると、デバイスおよびネットワーク情報を生成する作成するステップとを実行することにより応答する。デバイスおよびネットワーク情報は、デバイステーブルからのネットワークアドレスを含む。MACアドレスが一致しないと、ネットワーク構成サービスは、MACアドレスをベースにしたデフォルト情報からのネットワークアドレスを含むデバイスおよびネットワーク情報を作成し、デフォルト情報をデバイステーブルに追加する。MACアドレスが一致しないと、ネットワーク構成サービスは、さらに、ユーザ制御下にある接続されている制御装置を、デバイステーブルに追加された新規デバイスとして、または過去にデバイステーブルに存在していたデバイス構成として割り当てるステップを実行する。多くの利点は、説明されるシステムおよび方法により達成される。1つの利点とは、ローカル設定デバイスを使用する、デバイスの個々のフィールド設定が必要ないように、フィールドデバイスが離れた場所からプログラミングされるという点である。集中プログラム可能性programmabilityは、システム管理費用を削減するため、およびプロセス制御システムのダウンタイムを短縮するためにきわめて有効である。追加利点とは、個々のデバイスの設定よりむしろ、システム全体を構成する方が、個々のシステム設定がきわめて互換性があるシステムにつながるという点である。本発明の態様に従って、制御システムは、定義された制御構成に従って1つまたは複数の相互接続されているデバイスを制御する。制御システムは、制御システムに接続されているが、制御構成定義に含まれていないデバイスを自動的に検知する。制御システムは、デバイスから制御システムまで構成パラメータをアップロードするのに十分な初期相互接続情報を、接続されているデバイスに供給する。本発明の追加態様に従って、所定の構成のデジタル制御システムは、所定の構成に含まれていないデジタルデバイスのネットワークへの接続を自動的に検知する。デジタルデバイスは、一時アドレス情報を割り当てられ、スタンバイ状態と呼ばれている一時状態に置かれ、その場合デジタルデバイスがデジタル制御システムに情報を供給し、ユーザがデバイス情報および構成パラメータのアクセスを含むデジタルデバイスへアクセスできるようにする。デバイス情報および構成パラメータを使用して、ユーザは、物理デバイスタグおよびデバイスアドレスを割り当て、制御戦略をデジタルデバイスにインストールし、それによりデジタルデバイスを、デジタル制御システムとの通信で稼動状態にすることによって、デジタルデバイスを選択式に作動する。スタンバイ状態においては、ユーザは応答指令信号を送り、接続されているデバイスの型を突き止め、デジタル制御システムのコンテキストでのデバイスの役割を突き止め、突き止められた役割をデバイスに割り当てる物理デバイスタグを割り当て、ネットワークへのデバイスの接続を検証する。やはりスタンバイ状態において、ユーザは、デバイスの校正を含み、デジタル制御システムの総体的な制御体系内でデバイスを構成する、デバイスに適用されているそれ以外のアプリケーションを始動する。本発明の別の態様に従って、制御システムは、Fieldbasu規格仕様に従って定義されている状態を越えたフィールドバスデバイス状態を区別する。制御システムは、タグを持たないデバイスのデバイス識別IDに等しい物理デバイスを設定するが、デバイスは自動検出される。デバイスIDに等しい物理デバイスタグセットとのフィールドバスリンクに接続されているデバイスは、UNINITIALIZEDデバイスの様式で制御される。本発明の態様に従って、フィールドデバイスの自動検知は、デジタル制御システムにより、従来の入/出力レベルを越えて、フィールドバスデバイスの構成まで拡張される。説明されるシステムおよび方法により多くの利点が達成される。1つの利点とは、制御システムの構成が大幅に容易にされるという点である。デバイスのネットワークへの物理的な接続により、接続されているデバイスの制御システムの中への包含が始動する。説明されるシステムおよび方法は、構成の基礎として役立つ、ネットワークの構成とネットワークの物理的な相互接続の間の準拠を容易にする。説明されるシステムおよび方法は、ローカル設定デバイスを使用するデバイスの個々のフィールド設定が必要ないように、離れた場所からのフィールドデバイスのプログラミングを補助する。システムおよび方法は、システム管理費用を削減するため、およびプロセス制御システムのダウンタイムを短縮するためにきわめて有効である中央プログラム可能性をサポートする。追加利点とは、個々のデバイスの設定よりむしろ、システム全体を構成することの方が、個々のシステム設定がきわめて適合しているシステムにつながるという点である。本発明に従って、プロセス制御システムは、複数のIEC-1131規格制御言語、および制御言語の中からのユーザ選択をサポートするユーザインタフェースを含んでいる。単一アプリケーションルーチンから、ユーザは、制御戦略を実現するために、例えば、FunctionBlocks、SequentialFunctionCharts,LadderLogicおよびStructuredTextを含む複数の制御言語の中から1つの制御言語を選択する。本発明の別の態様に従って、表示装置に接続されているプロセッサを備えているプロセス制御環境を構成するための方法は、複数の命令セクションを提供するステップを含む。命令セクションは、プロセス制御環境の構成に関する情報を述べる。方法は、プロセス制御環境構成を定義するために制御言語エディタを選択するステップと、選択されている制御言語エディタに関して指示されるように、命令セクションに関する構成画面提示のシーケンスを表示装置上に表示するステップと、構成画面提示のシーケンスを介してプロセス制御環境の構成を通してユーザを誘導するステップとも含む。説明されるシステムおよび方法によって、多くの利点が達成される。1つの利点とは、広範囲の専門知識と経験を備えているユーザがシステムを容易に使用できるように、多くの異なるユーザがシステムによってサポートされているという点である。さらに、システムは、単一ユーザが、ある特定のシステム態様に対しもっとも適切な言語を使用して多様なシステムの態様を調整するのにきわめて有用である。本発明に従って、プロセス制御システムは、システムの多様なユーザが、表示されている警報イベント情報に容易に優先順位を設定できるように、警報イベント監視表示システムを含む。警報およびイベント構成はきわめて柔軟であり、ユーザにより命令されるように、階層構造で特定のイベントを表示するためにユーザにより構成される。ユーザは、所望の警報優先順位を設定し、より緊急な表示と予告のために高い重要性の警報を選択し、緊急性が低いイベントにはより低い表示ステータスを渡すrendering。ログオン時、ある特定のシステムユーザは、そのユーザに関連している警報イベント情報を表示するための表示構成と対応し、プロセス制御システムは、現在の警報を自動的に提供されており、新規警報イベント派生についてのプロセス情報を始動する。多くの利点が、説明されるプロセス制御方法を使用して達成される。1つの利点とは、警報情報が、ユーザによって命令される様式でその情報を最良に使用できるユーザに提示されるという点である。別の利点とは、ユーザが、ログオン時に自動的に適切な情報へのアクセスを達成するという点である。追加利点とは、関連する警報イベントがそのユーザのために即座蓄積を開始するように、ユーザがログオン時に、情報ストリームが提供されるという点である。新規であると考えられている本発明の特徴は、貼付請求項に明確に述べられている。しかしながら、発明自体は、その構造と動作の方法の両方に関して、以下の説明および添付図面を参照することによりもっともよく理解できる。図1Aを参照すると、制御システムが図示されている。一般的には、システム1は、ローカルエリアネットワークカードを介してローカルエリアネットワークLAN3に接続されているパーソナルコンピュータ2のようなメイン処理装置を含む。どのローカルエリアネットワークプロトコルも使用してよいが、ローカルエリアネットワーク3との通信を可能とするため、多くのアプリケーションでは所有権を主張できないnonproprietaryイーサネットプロトコルが有益である。ローカルエリアネットワーク3は、プロセス制御システム内で関係している制御パラメータ、制御データ、およびその他の関連情報を搬送する専用である。そのようなものとして、LAN3は、エリア制御ネットワークつまりACN3と呼ばれてよい。ACN3は、ACN3の専用の性質に影響を及ぼさないでハブまたはゲートウェイを介して情報およびデータを共用するために他のLANに接続されてよい。標準イーサネットプロトコルに従って、複数の物理デバイスが、多様なノードでACN3に接続されてよい。ACN3に接続されている各物理デバイスは、ノードで接続されており、各ノードは、ACN3を実現するために使用されているLANプロトコルに従って別個にアドレス指定可能である。冗長システムを確立するためには、単一イーサネットまたはLANシステムの故障の結果、システム全体の故障が生じないように、2つまたは3つ以上のイーサネットシステムからACN3を構築することが望ましいことがある。このような冗長イーサネットが使用されているとき、1つのイーサネットLANの故障は検出され、代わりのイーサネットLANが、ACN3の所望の機能性を提供するためにマッピングすることができる。メインパーソナルコンピュータPCAは、ACN3上でノードを形成する。PC2は、例えば、MicrosoftのWindowNTシステムなどの標準オペレーティングシステムを実行している標準パーソナルコンピュータであってよい。メインPC2は、ユーザ入力コマンドに応えて、ACN3を介して、メインPC2内で選択、確立されている制御ルーチンにより定義されている制御戦略を実現する要素4と5として特定されている1つまたは複数のローカル制御装置に提供され、多様な制御ルーチンを生成するように構成される。メインPC2は、ローカル制御装置4または5を介してよりむしろ、ACN3全体での伝達を介して、ポンプ、弁、モータ等のフィールドデバイス上で直接制御ルーチンを実現するように構成されてもよい。ローカル制御装置4と5は、PC2からACN3を通して制御ルーチンおよびその他の構成データを受け取る。それから、ローカル制御装置は、PC2により提供されているルーチンにより確立されている制御システムを実現するために、フィールド内で物理ステップを実際に実現し、実行する、ポンプ、モータ、調整器弁などの多様なフィールドデバイス6から15に対する多様な種類の信号を生成する。2つの型のフィールドデバイスが、FieldBus、Profitbus等などの特定の制御プロトコルに反応するデバイス6から10を含むローカル制御装置4と5に接続されてよい。当業者が理解するように、それらに従って特殊プロトコル命令がフィールドバスフィールドデバイスなどのプロトコルフレンドリなデバイスに提供され、フィールドデバイス内に位置している制御装置に、プロトコル機能に対応するある特殊な機能を実現させる、フィールドバスなどの標準制御プロトコルがある。したがって、フィールドデバイス6から11は、プロトコルに特殊な例えばFieldBus制御コマンドを、ローカル制御装置4と5、またはパーソナルコンピュータ2のどちらかから受け取り、フィールドデバイスに特殊な機能を実現する。やはりローカル制御装置4と5に接続されているのは、それらは局所的な処理力を含まず、直接制御信号に応えることができるため、非プロトコルと呼ばれている非プロトコルフィールドデバイス12から15である。したがって、フィールドデバイス12から15は、FieldBus制御プロトコルなどの特殊制御プロトコルにより定義されるだろう機能を実現することができない。非プロトコルフィールドデバイス12から15を、プロトコルフレンドリ例えば、FieldBusに特殊なデバイス6から11として動作できるようにするために、機能性が供給される。さらに、この同じ機能性により、ローカルフィールドデバイス6から11、ローカル制御装置4と5、およびパーソナルコンピュータ2の間で、プロトコルに特殊な制御ルーチンのインプリメンテーションを分散できるようになる。プロトコルに特殊な制御ルーチンの分散は、図1Bに詳細に示されている。図1Bは、図1Aに図示されているシステム、特にパーソナルコンピュータ2、イーサネット3、ローカル制御装置4、スマートフィールドデバイス6、およびダムデバイス12の一部分をさらに詳細に参照している。パーソナルコンピュータ2は、FieldBusプロトコルなどの標準制御プロトコルの標準機能ルーチンを実現するためのプログラムソフトウェアルーチンを含む。したがって、パーソナルコンピュータ2は、FieldBusコマンドを受け取り、フィールドバス機能を備えているローカルフィールドデバイスが実現できるだろう機能ルーチンのすべてを実現するようにプログラミングされる。FieldBusブロック機能性を実現するためにパーソナルコンピュータ2をプログラミングする能力およびステップは、技術で通常の技能を持つ人にとっては明確に明らかであろう。イーサネット3によりパーソナルコンピュータ2に接続されているのは、ローカル制御装置4である。ローカル制御装置4は、中央演算処理装置を構成し、適切な実用可能なoperational機能を実現するために制御信号を提供するランダムアクセスメモリに接続されている中央演算処理装置を含む。読取り専用メモリは、ランダムアクセスメモリに接続されている。読取り専用メモリは、FieldBusのような標準制御プロトコルの機能ルーチンのすべてを実現するように中央演算処理装置を構成することができる制御ルーチンを含むようにプログラミングされる。パーソナルコンピュータ2は、読取り専用メモリ内のプログラマルーチンの1つ、2つ以上、あるいはすべてを、FieldBUsルーチンなどの標準制御プロトコルルーチンの1つ、2つ以上、またはすべてを実現するようにCPUを構成するために、ランダムアクセスメモリに転送させる、ローカル制御装置4にイーサネット3を通して信号を送信する。スマートフィールドデバイス6は、一定の制御機能を実現する中央演算処理装置を含む。デバイスが、例えばFieldBusデバイスである場合には、フィールドデバイス6に結び付いている中央演算処理装置は、FieldBus機能性要件のすべてを実現できる。ローカル制御装置4には、FieldBusに特殊な制御を実現する能力があるため、制御装置4は、非プロトコルデバイス12がFieldBusデバイスとして動作し、操作されるように動作する。例えば、制御ルーチンがパーソナルコンピュータ2内で、またはローカル制御装置4のCPUで実行している場合、その制御ルーチンは、FieldBusコマンドを実現し、FieldBusデバイス6とフィールドバスデバイスとして動作している非プロトコルデバイス12に提供することができる。フィールドデバイス6はFieldBusデバイスであるため、デバイス6は、これらのコマンドを受け取り、それによりそれらのコマンドによって命令される制御機能性を実現する。しかしながら、非プロトコルデバイス12は、ローカル制御装置4の中央演算処理装置とともに動作し、フィールドデバイスと組み合わされているローカル制御装置がFieldBusコマンドを実現し、層さするように、FieldBus要件を実現する。非FieldBusデバイス12が、FieldBusデバイスとして行動actし、動作できるようにすることに加えて、説明された態様は、図1Aに図示されているシステム1全体でのFieldBus制御ルーチンの分散を可能にする。例えば、制御ルーチンが、当初、フィールドデバイス6に複数のFieldBus制御ルーチンを実現するように要求する範囲まで、システム1は、FieldBus制御ルーチンの一部がローカル制御装置5により実現されており、それ以外のFieldBusルーチンがローカル制御装置4に記憶されているFieldBusルーチンの使用により実現されるように、制御をローカル制御装置4とローカル制御装置5の間で分けることを可能にする。FieldBusルーチンインプリメンテーションの分割は、さらに精密でさらに高速な制御、およびシステムの総体的な処理力のさらに効率的な活用を可能にすることがある。さらに、パーソナルコンピュータ2に、FieldBus制御ルーチンを実現する能力があるという事実、FieldBusルーチンは、ローカル制御装置4とパーソナルコンピュータ2の間でさらに分散される。このようにして、システムは、パーソナルコンピュータ2が、ある特定の制御アルゴリズムに対してFieldBusルーチンの1つまたはすべてを実現できるようにする。さらに、システムは、FieldBusルーチンが、ローカル制御装置4で記憶されているFieldBusルーチンで使用することにより、非FieldBusデバイス12で実現されるのと同じように、パーソナルコンピュータ2に記憶されているFieldBus制御ルーチンを使用することにより、イーサネット3に直接接続されている非FieldBusデバイスに対するFieldBus制御のインプリメンテーションを可能にする。プロセス制御環境100は図1Cに図示され、デジタル制御システム、プロセス制御装置等を実現するための制御環境を図解する。プロセス制御環境100は、多様なワークステーションと複数の制御装置/マルチプレクサ110の間でデータおよび制御信号を転送、受信するために、ローカルエリアネットワークLAN108によって電気的に相互接続されている、オペレータワークステーション102、実験室ワークステーション104、およびエンジニアリングワークステーション106を含む。ワークステーション102、104、106は、LAN108により、ワークステーションと複数のプロセス112の間で電気的に接続して機能するinterface複数の制御装置/マルチプレクサ110に接続されていると図示されている。複数の多様な実施態様においては、LAN108は、制御装置/マルチプレクサ110に直接的に接続されている単一のワークステーションを含むか、あるいは代わりに、プロセス制御環境100の目的および要件に応じて、複数のワークステーション、例えば3つのワークステーション102,104,106および多くの制御装置/マルチプレクサ110を含む。単一プロセス制御装置/マルチプレクサ110が複数のプロセス112を制御するか、あるいは代わりに単一プロセスの一部を制御する実施態様もある。プロセス制御環境100においては、プロセス制御戦略は、例えば、エンジニアリングワークステーション106でソフトウェア制御ソリューションを作成し、実行のために、LAN108を介してソリューションをオペレータワークステーション102、実験室ワークステーション104、および制御装置/マルチプレクサ110に転送することにより作成される。オペレータワークステーション102および実験室ワークステーション104供給インタフェースは、制御装置/マルチプレクサ110内で実現されている制御/監視戦略に表示し、プロセス112を表示し、設計されているソリューションの要件に従って、属性値を変更するために、制御装置/マルチプレクサ110の1つまたは複数に通信する。プロセス112は、スマートフィールドデバイスまたは従来の非スマートフィールドデバイスであってよい、1つまたは複数のフィールドデバイスから形成されている。プロセス112は、2つのフィールドバスデバイス132、HARTハイウェイアドレス指定可能リモート変換器highwayaddressableremotetransducerデバイス134、および従来のフィールドデバイス136として実例として描かれている。加えて、オペレータワークステーション102および実験室ワークステーション104は、制御されているプロセス112のステータスおよび状態に関してオペレータに視覚フィードバックおよび音声フィードバックを通信する。エンジニアリングワークステーション106は、中央演算処理装置CPU16とディスプレイ、およびキーボード、ライトペン等の入/出力装置またはユーザインタフェースデバイス118を含む。CPU116は、典型的には専用メモリ117を含む。専用メモリ117は、図1Cに図示されているプロセス制御環境100の制御動作および機能を実現するためにCPU116上で実行する、デジタル制御システムプログラム図示されていないを含む。プロセス制御環境100内でのオペレータワークステーション102、実験室ワークステーション104、および他のワークステーション図示されていないは、ユーザとCPUの間での対話を可能とするために、ディスプレイ図示されていないおよびユーザインタフェースデバイス図示されていないに電気的に接続されている少なくとも1つの中央演算処理装置図示されていないを含む。1つの実施態様においては、プロセス制御環境100は、68360プロセッサにより動かされている一次イーサネットポートと二次イーサネットポートそれぞれSCSIとSCC3のある68040とのコンパニオンcompanionモードで実行している、Motorola68040プロセッサおよびMotorola68360通信プロセッサを使用して実現されているワークステーションを含む。プロセス制御環境100は、組み合わされて制御テンプレートシステム120を形成している、テンプレートジェネレータ124および制御テンプレートライブラリ123も含む。制御テンプレートは、プロセス、およびある特定のプロセス制御機能、制御属性、変数、および特定の機能に対する出力、および必要に応じて、エンジニアビューとオペレータビューなどの機能のグラフィックビューに使用されている方法論を制御するために使用される属性関数のグルーピングとして定義される。制御テンプレートシステム120は、テンプレートジェネレータ124と通信する制御テンプレートライブラリ123を含む。制御テンプレートライブラリ123は、プロセス制御プログラムで使用するための、事前に定義されたまたは既存の制御テンプレート機能のセットを表すデータを記憶する。制御テンプレート機能とは、一般的にシステムデザイナーからユーザへとシステムに付属スsルテンプレートである。テンプレートジェネレータ124とは、有利に、ユーザが、制御テンプレート機能を作成したり、既存の制御テンプレート機能を修正できるようにするインタフェースのことである。作成され、修正されたテンプレート機能は、制御テンプレートライブラリ123内に選択式で記憶される。テンプレートジェネレータ124は、属性方法言語ジェネレータ126、およびグラフィックジェネレータ128を含む。属性方法言語ジェネレータ126は、ユーザが特定の制御テンプレートのために新しい、または修正済みの機能を実行する方法またはプログラムを選択できるようにするために表示画面を提供することだけではなく、ユーザが、新しい制御テンプレート機能の作成、またはある特定の既存の制御テンプレート機能の修正に関連している複数の属性機能を定義できるようにする表示画面を供給する。グラフィックジェネレータ128は、特定の制御テンプレートに対応しているグラフィックビューを設計する能力をユーザに与える。ユーザは、属性方法言語ジェネレータ126およびグラフィックジェネレータ128によって記憶されているデータを活用し、制御テンプレートに対し属性方法およびグラフィックビューを完全に定義する。作成済みの制御テンプレート機能を表すデータは、通常、制御テンプレートライブラリ123に記憶され、それ以降、プロセス制御ソリューションを設計するためにエンジニアが選択および使用する場合に利用できる。プロセス制御環境100は、オブジェクト指向フレームワークを使用して実現される。オブジェクト指向フレームワークは、クラスハイアラーキー、オブジェクト状態、およびオブジェクト動作などのオブジェクト指向概念を使用する。以下に簡略に説明されているこれらの概念は、技術においてよく知られている。さらに、オブジェクト指向フレームワークは、技術でよく知られている、Cプログラミング言語などのオブジェクト指向プログラミング言語を使用して作成されるか、あるいは好まれている実施態様での場合のように、Cなどの非オブジェクト言語を使用し、その言語でオブジェクト指向フレームワークを実現して作成されてよい。オブジェクト指向フレームワークのビルディングブロックは、オブジェクトである。オブジェクトは状態および動作により定義される。オブジェクトの状態は、オブジェクトのフィールドにより述べられる。オブジェクトの動作は、オブジェクトの方法により述べられる。各オブジェクトは、オブジェクトにテンプレートを提供するクラスのインスタンスである。クラスは、ゼロまたはそれ以上のフィールド、およびゼロまたはそれ以上の方法を定義する。フィールドとは、オブジェクトの状態の一部を定義している情報を含むデータ構造である。同じクラスのインスタンスであるオブジェクトは、同じフィールドを持つ。ただし、オブジェクトのフィールド内に記憶されている特定の情報は、オブジェクトごとに変わることがある。各フィールドには、整数値などの直接的である、あるいは別のオブジェクトに対する参照などの間接的である情報が記憶できる。方法とは、コンピュータシステムソフトウェアによりCPU116内で実行できるコンピュータ命令の集合体である。ソフトウェアが、方法が定義されているオブジェクトが方法を達成するように要求すると、方法の命令は実行され、つまり方法は達成される。方法は、方法を含むクラスのメンバーである任意のオブジェクトにより達成できる。その方法を達成しているその特定のオブジェクトは、応答者、つまり応答しているオブジェクトである。方法を達成する時に、応答者は1つまたは複数の引数、つまり入力データを消費し、ゼロまたは1つの結果、つまり出力データとして戻されるオブジェクトを作成する。ある特定のオブジェクトに対する方法が、そのオブジェクトの動作を定義する。オブジェクト指向フレームワークのクラスは、クラスハイアラーキーで編成される。クラスハイアラーキーにおいては、クラスは、そのクラスのスーパークラスにより定義されるフィールドと方法を継承する。さらに、クラスによって定義されているフィールドおよび方法は、そのクラスのサブクラスによって継承される。すなわち、サブクラスのインスタンスは、スーパークラスによって定義されているフィールドを含み、スーパークラスによって定義されている方法を達成することができる。したがって、オブジェクトの方法が呼び出されると、アクセスされる方法は、オブジェクトがそのメンバーであるクラスで、あるいはオブジェクトがメンバーであるクラスのスーパークラスの任意の1つで定義されることがある。オブジェクトの方法が呼び出されると、プロセス制御環境100は、オブジェクトのクラス、および必要な場合にはオブジェクトのあらゆるスーパークラスを調べることによって、実行する方法を選択する。サブクラスは、サブクラスの動作を改善または変更するために、スーパークラスから継承される方法定義を無効にしたり、取って代わることがある。ただし、サブクラスは、方法のシグナチャに取って代わることができない。方法のシグナチャは、方法の識別子、引数の数と型、結果が戻されるかどうか、および戻される場合には結果の種類を含む。サブクラスは、方法の性能という点で、実行されるコンピュータ命令を定義し直すことにより継承されている方法定義に取って代わることがある。インスタンスを持つことができるクラスは、具象クラスである。インスタンスを持つことができないクラスは、抽象クラスである。抽象クラスは、抽象クラスのサブクラスによって継承されるフィールドおよび方法を定義してよい。ただし、抽象クラスのサブクラスは、他の抽象クラスであることがある。ただし、究極的には、クラスハイアラーキー内では、サブクラスは具象クラスである。以下に説明される混合mixinクラスを除いては、開示されている好まれる実施態様に定義されているすべてのクラスは、クラスのサブクラス、Objectである。したがって、ここに説明されており、混合クラスではない各クラスは、クラスObjectの方法およびフィールドを継承する。プロセス制御環境100は、図2に図示されている、構成モデル、つまり構成インプリメンテーション210の、および実行時モデル、つまり実行時インプリメンテーション220の中に存在する。構成インプリメンテーション210においては、プロセス制御環境100内の構成要素デバイス、オブジェクト、相互接続、および相互関係が定義される。実行時インプリメンテーション220においては、多様な構成要素デバイス、オブジェクト、相互接続、および相互関係の動作が実行される。構成インプリメンテーション210および実行時インプリメンテーション220は、ダウンロードすることにより相互接続される。ダウンロードされた言語は、ユーザによって供給されている定義に従ってシステムオブジェクトを作成し、供給されている定義からインスタンスを作成する。具体的には、各デバイスに関係する完全に構成されているDeviceTableが、起動時に、およびDeviceTableが変更されると、すべてのWorkstationsにダウンロードされる。制御装置/マルチプレクサ110の場合、ダウンロードされたDeviceTableは、制御装置/マルチプレクサ110が、特殊な制御装置/マルチプレクサ110内で構成され、使用されている遠隔モジュールデータに基づいて通信を始動しなければならないデバイスのためのデータだけを含んでいる。他の構成データがダウンロードされるときに、DeviceTableが制御装置/マルチプレクサ110にダウンロードされる。定義をダウンロードすることに加えて、ダウンロード言語は、インスタンスおよびインスタンス値もアップロードする。構成インプリメンテーション210は、インストール手順を使用して実行時インプリメンテーション220内で実行するために起動される。また、ネットワーク通信パラメータは、構成データがダウンロードされるとき、および値が変更されるときに各デバイスにダウンロードされる。プロセス制御環境100は、複数のサブシステムを含んでおり、サブシステムの内のいくつかは構成インプリメンテーションと実行時インプリメンテーションの両方を備えている。例えば、プロセスグラフィックサブシステム230は、ユーザ定義ビューおよびオペレータ接続interfacingをプロセス制御環境100のアーキテクチャに供給する。プロセスグラフィックサブシステム230は、構成インプリメンテーション210の一部であるプロセスグラフィックエディタ232、および実行時インプリメンテーション220の部分であるプロセスグラフィックビューア234を有している。プロセスグラフィックエディタ232は、ダウンロードされた言語での相互サブシステムインタフェース236によりプロセスグラフィックビューア234に接続されている。プロセス制御環境100は、制御モジュールおよび装置モジュールを構成し、定義モジュールエディタ242の中にインストールし、実行時制御装置244の中で制御モジュールおよび装置モジュールを実行する制御サブシステム240も含む。定義モジュールエディタ242は、構成インプリメンテーション210内で動作し、実行時制御装置244は実行時インプリメンテーション220内で動作し、連続順序制御機能を供給する。定義モジュールエディタ242は、ダウンロードされた言語で相互サブシステムインタフェース246によって実行時制御装置244に接続される。複数のサブシステムが、サブシステムインタフェース250によって相互接続される。構成インプリメンテーション210および実行時インプリメンテーション220は、マスタデータベース260に接続しinterface、共通のデータ構造をサポートする。多様なローカル非マスタデータベース262は、マスタデータベースにインターフェイスし、例えば、ユーザによって命令されるように、構成データをマスタデータベース260からローカルデータベース262に転送する。マスターデータベース260の一部は、永続データベース270である。永続データベース270とは、データベースの作成者が存在しなくなってもデータベースが存在し続けるように時間の限界を超えtranscends、データベースが、それが作成されたアドレス空間とは異なるアドレス空間へ削除可能であるように空間の限界を超えるtranscendsオブジェクトのことである。構成インプリメンテーション210の全体は、永続データベース270に記憶される。マスタデータベース260およびローカルデータベース262は、構成、統計、および診断の文書が文書化目的で利用できるようにアクセス可能である。実行時インタフェース220は、永続データベース270およびローカルデータベース262にインターフェイスし、構成インプリメンテーション210により形成されているデータ構造にアクセスする。特に、実行時インプリメンテーション220は、選択されている装置モジュール、ディスプレイ等をローカルデータベース262および永続データベース270からフェッチする。実行時インプリメンテーション220は、それ以外のサブシステムにインターフェイスし、定義をインストールし、それにより定義がまだ存在していないときにインスタンスを作成するために使用されるオブジェクトをインストールし、実行時インスタンスを具体化し、多様なソースからの情報を宛先オブジェクトに転送する。DeviceTablesは、デバイスにとってローカルであり、組み合わせて構成インプリメンテーション210を定義する構成データベースの要素である。DeviceTableには、プロセス制御環境100内のデバイスに関する情報が包含されている。DeviceTable内の情報アイテムは、デバイスID、デバイス名、デバイス型、PCNネットワーク番号、ACNセグメント番号、シンプレックス/冗長通信フラグ、制御装置MACアドレス、コメントフィールド、一次インターネットプロトコルIPアドレス、一次サブネットマスク、二次IPアドレス、および二次サブネットマスクを含む。図3を参照すると、ブロック図が、プロセス制御環境100の構成モデルと実行時モデルの両方とともに使用するためのユーザインタフェース300を示している。ユーザインタフェース300の一部は、デバイスをベースにした構成アプローチを特徴とするWindowsNTTMオペレーティングシステムで定義されているインターフェイスプログラムであるExplorerTM310である。ユーザインタフェース300の別の一部は、制御ベースの構成アプローチを使用してインターフェイスするためのモジュール定義エディタ320である。ExplorerTM310は、構成を選択、構築および操作するためにユーザにより操作される。さらに、ExplorerTM310は、ネットワーク内の多様なツールおよびプロセッサを横切ってナビゲーションするための初期状態を供給する。ユーザは、ExplorerTM310を制御し、ライブラリ、領域、プロセス制御装置、およびに時動作にアクセスする。図3は、プロセス制御環境100内で動作しているタスクによりアクセスされてよい多様なツールの間の関係、およびライブラリ、領域、プロセス制御環境および機密保護などのプロセス制御環境100の構成要素間の関係を示している。例えば、ユーザがタグ表示機能を領域内から選択すると、タグリストビルダーbuilderが表示され、制御フラグおよびI/Oフラグのリストを示す。タグリストビルダーから、ユーザはタグ追加機能を使用して、リストにモジュールを追加し、それによりモジュールエディタを呼び出すことができる。図4を参照すると、概略ブロック図が、構成モデル400のシステムオブジェクト間の階層構造関係を示している。構成モデル400は、制御、I/O、プロセスグラフィックス、プロセス装置、警報、履歴およびイベントを含む多くの構成態様を含む。構成モデル400は、デバイス説明およびネットワークトポロジーレイアウトも含む。構成モデル階層400は、システムオブジェクトの関係およびロケーションを視覚化し、多様なシステムオブジェクト間の保守情報を通信またはナビゲーションするためにある特定のユーザによって使用されるために定義される。例えば、1つの構成モデル階層400、具体的には物理プラントハイアラーキーは、物理的なプラント関係およびロケーションを視覚化し、物理的なプラント内の多様な計器および装置間で保守情報を通信またはナビゲーションするために、保守エンジニアおよび技術者によって使用されるために定義される。物理プラントハイアラーキーを形成する構成モデルハイアラーキー400の実施態様は、SP88物理装置規格ハイアラーキーのサブセットをサポートし、構成モデルサイト410、1つまたは複数の物理プラント領域420、装置モジュール430、および制御モジュール440を含む。構成モデルハイアラーキー400は、構成モデルハイアラーキー400内で定義されている1つまたは複数の指定済み物理プラント領域に分割される単一のプロセスサイト410に定義されている。物理プラント領域420はオプションでタグ付きの複数のモジュールを包含し、そのそれぞれは構成モデルハイアラーキー400内で一意に具体化される。物理プラント領域420は、オプションで1つまたは複数の装置モジュール430を包含する。装置モジュール430は、オプションでその他の装置モジュール430、制御モジュール440、および機能ブロックを包含する。装置モジュール430は、連続機能ブロック、はしご形論理、または逐次機能チャートSFCを含む多くの異なったグラフィックプロセス制御プログラミングテンプレートに従って作成される制御テンプレートを含み、それにより制御される。構成モデルハイアラーキー400は、オプションで1つまたは複数の制御モジュール440を包含する。制御モジュール440は、物理プラント領域420、装置モジュール430、または別の制御モジュール440などのオブジェクトに包含される。制御モジュール440は、オプションで、その他の制御モジュール440または機能ブロックを包含する。制御モジュール444は、制御モジュールの方法のコンテンツおよびインプリメンテーションのすべてが非表示となるようにカプセル化される。図5を参照すると、概略ブロック図が、図4に示されている構成モデルハイアラーキー400内で動作する構成アーキテクチャ500を示している。構成アーキテクチャ500は、抽象の複数のレベルでの複数のオブジェクトおよびクラスを含む。抽象510の組織上のレベルでは、構成アーキテクチャ500が、構成アーキテクチャ500内で名前が付けられているオブジェクトおよびクラスを包含するサイトクラス512を含む。名前が付けられているオブジェクトおよびクラスとは、定義、画面とグラフィックスなどの表示構成要素、およびそれ以外のアイテムである。指定されているオブジェクトおよびクラスは機能ブロック、ユーザアカウント、モジュール、プラント領域、イベント、ライブラリ、およびその他のサイト全体での情報を含む。名前が付けられているアイテムの例とは、ブロック定義、装置モジュール定義、制御モジュール定義、プラント領域名等である。抽象520のプリミティブレベルでは、構成アーキテクチャ500が、などのハードコーディングhardcodedされている機能を含む、構成アーキテクチャ500内での機能に対するインタフェースを定義するプリミティブを含む。抽象520のプリミティブレベルは、機能522およびパラメータ524のクラスを含む。機能522は、構成アーキテクチャ500の抽象の最低レベルでの稼動operational機能である。機能522は、通常、CまたはC言語で符号化されている。構成アーキテクチャ500の1つの実施態様においては、実現されている機能ブロック522の完全なセットはプリミティブである。抽象520のプリミティブレベルでのオブジェクトおよびクラスは、サイトクラス512全体で定義される。パラメータ524は、構成アーキテクチャの最低抽象レベルでのクラスおよびオブジェクトである。パラメータ524は、整数、実数、ベクタ、アレイ等を含む。属性値は、機能ブロック522内で使用するためにパラメータ524にマッピングされる。1つの実施態様において、抽象520のプリミティブレベルにある機能ブロック522が、以下に示すように表1~3に一覧表示されている機能ブロックプリミティブを含む。抽象530の定義使用レベルでは、構成アーキテクチャ500は、定義532および使用状況を含む。定義532および使用状況は、組み合わされて、機能ブロック、制御モジュール、装置モジュール、リンクおよび属性を含むオブジェクト用のアルゴリズムおよびインタフェースを定義する。定義532は、機能ブロック、モジュール、リンクおよび属性用のアルゴリズムおよびインタフェースを定義する。使用状況とは、別の定義内でのある定義の使用状況を表す抽象の定義使用状況レベルでのオブジェクトおよびクラスである。抽象540のインスタンスレベルでは、構成アーキテクチャ500は、構成内のタグ付きアイテムであるインスタンスを含む。プラント領域542、モジュール544、属性546、およびPIOブロック548がタグ付きインスタンスである。インスタンスは、定義532に従って定義される。プラント領域542は、プロセスサイトクラス512の地理学上の、または論理的なセグメンテーションを表す。抽象540のインスタンスレベルでのすべてのオブジェクトおよびクラスは、すべてのモジュールインスタンスがプラント領域542との0または1つの関連付けを有するように、プラント領域レベル全体で定義されている。実行時システムでインストールされるためには、モジュールインスタンスは、モジュールが、プラント領域というこのコンテキストでによって包含されているまたはよく見られているとして表示されることを意味する、1つの関連付けを有さなければならない。モジュールインスタンス544は、プラント装置の特殊なオブジェクトに関連付けられているインストール可能オブジェクトである。属性インスタンス546とは、モジュールインスタンス544、プラント領域インスタンス542、またはそれ以外のデバイスでの可視パラメータである。属性インスタンス546は、入力信号、出力信号、データ記憶装置等に使用されてよい。抽象550のデバイスレベルでは、構成アーキテクチャ500は、実際のプラント内の物理的なプロセス制御装置を表す、制御装置、スマートデバイスとコンソール、およびPIOブロックなどの入出力装置I/O560等のようなデバイス552を含む。プロセス入出力PIOブロックとは、Hart、FieldBus、および構成アーキテクチャ500の中に接続されているそれ以外の入出力装置を含む、高密度と低密度の従来の入出力装置を表す抽象である。高密度または低密度は、I/Oカードでのチャネル数に関係する。例えば、高密度カードには32のチャネルがあるが、典型的には8つのチャネルが低密度カード上にある。デバイス522は、構成アーキテクチャ500内でのプロセス制御装置であり、制御装置、入出力装置、コンソール等のオブジェクトを含む。入出力装置IO560は、構成アーキテクチャ500内の物理的なプロセス入出力装置である。スマートデバイスとは、デバイス校正、構成、診断および保守に関係するデータを含む、デバイスに関連するデジタルデータを送受するために実現されるフィールドデバイスである。典型的には、スマートデバイスは、例えば、フィールドデバイスにより測定されているプロセス値を含む多様な情報を示す標準アナログ信号を伝送するためにも適応される。スマートフィールドデバイスの例は、HARTハイウェイアドレス指定可能リモート変換器プロトコル、フィールドバスプロトコル、Modbusプロトコル、およびデバイスネットプロトコルに従うフィールドデバイスを含む。システムオブジェクト間の多様な階層構造関係は、異なるユーザによって図1Cに図示されているプロセス制御環境100を通してのナビゲーションを容易にするため、およびさまざまなタスクを達成するために実現される。制御ハイアラーキー、制御システムハイアラーキー、動作ハイアラーキー、および物理プラントハイアラーキーを含む4つの異なる階層構造関係が定義される。特殊システムオブジェクトは、複数の階層構造システム内で実現されてよい。制御ハイアラーキーとは、標準SPハイアラーキーのサブセットであり、サイトオブジェクト、物理領域オブジェクト、装置モジュールオブジェクト、制御モジュールオブジェクトおよび制御要素オブジェクトを含む、システムオブジェクトを有している。制御ハイアラーキーは、制御動作を編成し、指定済みオブジェクトの範囲を定義するために使用される。ユーザは、信号タグを有している、サイトインスタンス、装置モジュール定義、制御モジュール定義、プラント領域インスタンス、装置モジュールインスタンス、制御モジュールインスタンス、表示モジュールインスタンス、およびプロセスI/Oモジュール/ブロックインスタンスに基づき、制御ハイアラーキーと対話する。制御システムハイアラーキーは、領域制御ネットワークACN、プロセス制御ネットワークPCNおよびその他のI/Oネットワークの規格を含む多様なネットワーク規格を使用して関連付けられている、オペレータ/構成ステーション、ホストコンピュータ、制御装置、I/O装置、スマートデバイス、ゲートウェイ等を含む。1つの実施態様においては、ACNハードウェアが、標準10ベースTイーサネット通信ポートを含み、ワークステーションが標準イーサネット10ベースTインタフェースカードとソフトウェアドライバを具備する。ユーザは、定義されているサイトインスタンス、ネットワーク定義、定義されているネットワークインスタンス、デバイス、およびファイル、カード、チャネル、制御装置、動作ステーション、およびフィールドバスセグメントなどのサブシステムに基づいて制御システムハイアラーキーと対話する。領域制御ネットワークACNは、リモートオブジェクト通信ROCレベルと低レベル通信レベルという2つのレベルでの通信機能性を含む。ROCレベルは、Programmedプログラミング済みアプリケーションとACN通信システム間のインタフェースを制御する。低レベル通信は、TCP/IPソケットとのインタフェースおよび実際のメッセージの伝送をサポートする。リモートオブジェクト通信ROCとは、図1Cに図示されているプロセス制御環境100内でのオブジェクトの通信をサポートしている、特に、オブジェクトが同じデバイス内に常駐しているのか、リモートデバイスに常駐しているのかに関係なく、オブジェクト間の通信をサポートしているシステム動作である。ROC通信レベルは、要求/応答、要求に基づかない報告、イベント/警報報告を含む通信メッセージサービス、および一斉送信メッセージサービスをサポートする。要求/応答は、それによりアプリケーションがメッセージをリモートデバイスに送信し、そのデバイスから応答を受信するサービスである。要求に基づかない報告とは、定期的に更新済みデータをリモートデバイスに送信するためのサービスである。未変更データは報告されない。イベント/警報報告は、リモートデバイスへの送達のためにイベント、警報およびそれ以外のきわめて重大な情報の伝送に使用される保証済み送達メッセージサービスである。一斉送信メッセージサービスは、通信ネットワーク上のすべてのプログラムアプリケーションデバイスにメッセージを送信するために使用される。ROCレベルは、通信サブシステムの通信方針も設定する。つまり、ROCレベルは、入信メッセージがどのように処理されるのかだけではなく、どのメッセージがいつ送られるのかを管理する担当である。通信フロー制御も、ROC部分の責任となるだろう。低レベル通信サポートは、デバイス接続管理、ACN冗長性、および通信システム診断のために含まれる。デバイス接続管理は、2つのデバイス間の通信接続を確立し、その2つのデバイス間でのメッセージの伝送を管理する。ACN冗長性は、通信リンク故障の検出を取り扱い、あるリンクから別のリンクへの切替えを制御し、ホストデバイスと接続されているリモートデバイス間の通信リンクのステータスを追跡調査する。通信サブシステム診断は、通信完全性と統計情報を追跡調査し、通信診断データに対する要求に応答する。ACN通信システムでのデバイス接続管理は、UDP型とTCP型両方のデバイス接続をサポートする。UDP接続は、デバイス間での通常リアルタイムデータ転送に使用される。TCP接続は、ファイル転送、デバイスフラッシュ、ダウンロード等のストリームプロトコルを使用する特殊アプリケーションに使用される。デバイス間の通信は、DeviceConnectionObjectによって管理される。DeviceConnectionObjectは、データを伝送し、2つの通信装置間の通信リンクのステータスを維持する。すべての通常デバイス接続メッセージトラフィックは、単一UDP通信ポートを通して向けられる。DeviceConnectionObjectは、デバイス通信メッセージトラフィックの管理に必要とされている待ち行列を作成することだけではなく、このUDPポートに関連付けられいている通信ソケットを作成することによって通信システムを起動する。DeviceConnectionObjectは、DeviceConnection通信ソケット上ですべての入信メッセージを受信し、処理のためにメッセージを適切なデバイス接続インスタンスに送る。DeviceConnectionObjectは、デバイス接続インスタンスに、肯定応答されるのを待機しているメッセージがいつタイムアウトになるのか、いつ通信リンクチェックが期限切れになるのか、およびいつデバイス接続再同期resyncsがタイムアウトしたのかを通知することを含む、デバイス接続のタイミング機能を取り扱う。UDP型通信は、デバイス間でのリアルタイムデータの転送に使用される。リモートオブジェクト通信ROCサブシステムは、宛先デバイスまでの伝送のためにメッセージをUDPDeviceConnectionUDPデバイス接続に渡す。各デバイスの起動時に、メッセージバッファのプールが作成される。メッセージプールは、デバイス間で伝送されている全データに使用され、通信サブシステムが、メモリを使い尽くすのを妨げ、それ以外のタスクがメモリを使い尽くさないことを確実にし、それにより、通信サブシステムが実行するのを妨げる。通信フロー制御は、DeviceConnectionObjectで実現される。通信バッファプールのメッセージバッファ数が所定の低レベルに達すると、すべてのリモートデバイスは、低バッファ問題が、影響を受けているデバイスで解決され、メッセージの損失を妨げるまで、メッセージの送信を禁止される。TCP型通信は、ファイル転送およびデバイスフラッシュダウンロードなどのストリーム型プロトコルを使用するアプリケーションに使用される。TCP型接続は、アプリケーションのニーズの期間、確立されている一時的な接続であり、アプリケーションがいったん通信タスクを完了すると終了される。インタオペラビリティー、互換性、可用性のため、TCP/IPプロトコルスタックが利用される。TCP/IPスタックは、接続指向型バイとストリームプロトコルTCPおよびコネクションレスメッセージ指向型プロトコルUDPを供給する。デバイス接続は、要求/応答メッセージ、応答不要のデータ、およびデバイス間のイベントと警報データをサポートする。通信システムは、単一の通信故障、典型的にはケーブル障害が発生した場合に2つの利用可能な通信リンクの内の1つを通してデバイス接続を維持する。障害の検出および代替通信経路への切替えは、短期の決定的な時間スパンで明らかになる。動作ハイアラーキーは、一般的には、ディスプレイ、レポート、およびその他の情報を提供するアイテムにアクセスするために、ユーザのある特定のセット、具体的にはオペレータおよび保守エンジニア向けに定義される。ユーザは、サイトインスタンス、UserGroupユーザグループ定義、プラント領域インスタンス、装置モジュールインスタンス、制御モジュールインスタンス、ディスプレイインスタンス、およびレポートインスタンスに基づいて動作ハイアラーキーと対話する。物理プラントハイアラーキーは、典型的には、オブジェクト間の物理的な関係を突き止め、プラント計測器および装置についての保守情報をナビゲーションする目的で、ユーザのある特定のセット、具体的には保守エンジニアと技術者向けに定義される。ユーザは、サイトインスタンス、保守領域インスタンス、プラント領域インスタンス、部屋インスタンス、キャビネットインスタンス、ノード/でバイすインスタンス、およびディスプレインスタンスに基づいて物理プラントハイアラーキーと対話する。複数の階層構造システム内で実現されるシステムオブジェクトは、制御サブシステム、プロセスI/Oサブシステム、制御システムハードウェアサブシステム、冗長性管理サブシステム、イベント/警報管理サブシステム、履歴サービスサブシステム、プロセスグラフィックサブシステム、診断提示サブシステム、ユーザ環境サブシステム、管理組織サブシステム、およびフィールド管理システムFMSサブシステムを含む、複数のサブシステムの中に配列される。制御サブシステムは、制御モジュールおよび装置モジュールを構成、インストール、および実行するためのルーチンを含む。プロセスI/Oサブシステムは、HART、フィールドバス、従来のI/O、およびその他の入出力システムを含むデバイスへの統一インタフェースである。制御システムハードウェアサブシステムは、制御システムトポロジー、トポロジー内でのデバイス、およびデバイスの能力と機能を定義する。制御システムハードウェアサブシステムは、ステータスおよび診断を示すデバイスレベルの情報にアクセスするためのオブジェクトおよびデータ構造も含む。冗長性管理サブシステムは、一次制御アプリケーションと二次制御制御アプリケーション間の冗長なコンテクストを確立し、一次制御アプリケーションと二次制御アプリケーションの間のコンテキストで切替えを管理する。冗長性管理サブシステムは、サイト情報およびデータ待ち時間情報を含む冗長なコンテキスト診断情報も監視する。ネットワーク冗長性は、2つの別個のイーサネット通信リンクまたはネットワークを使用して達成される。一次通信リンクとは、好まれている通信経路である。二次リンクは、一次リンク故障時にだけ使用される。通信切替えは、デバイス単位で実行される。例えば、デバイスAがデバイスBとCと通信しており、デバイスCへの一次リンクが故障すると、デバイスAは、一次リンク上でデバイスBとの通信し続けるが、二次リンクをデバイスCとの通信に切り替える。各イーサネットリンクは、IPアドレスとサブネットマスクの専用セットを有している、別個の専用ネットワークである。デバイス接続オブジェクトは、二次リンクにいつ切り替えるのか、および一次リンクにいつ戻すのかを制御すること含む、冗長通信を管理する。プロセス制御システムの各デバイスは、他の通信が発生していないときにリンクテストメッセージを定期的に送信することにより、リモートデバイスへの現在の全リンクの通信ステータスを追跡調査し、各デバイスへの通信リンクのステータスをチェックする。冗長性切り替えは、デバイス接続に基づいて実行される。イベント/警報管理サブシステムは、重要なシステム状態、肯定応答および優先順位計算の通知を構成し、監視し、供給する。履歴サービスサブシステムは、プロセスイベント情報を記憶し、検索する。プロセスグラフィックサブシステムは、表示および定義済みシステムアーキテクチャへのオペレータインターフェイスのためにユーザ定義ビューを供給する。診断提示サブシステムは、通常はユーザの要求で診断情報のディスプレイを供給する。ユーザ環境サブシステムは、ユーザインタフェースを供給し、ユーザが図1Cに図示されているプロセス制御環境の動作を制御するためのコマンドを入力できるようにする。管理組織サブシステムは、サイト、領域、プリミティブ、ユーザライブラリへのアクセス、および定義済みオブジェクトとインスタンスのロケーションの指定を含むプロセス制御環境100の組織的な構造を設定する。FMSは、HARTデバイスおよびフィールドバスデバイスの構成、インストール、および監視のためのユーザインタフェース、ビュー、および組織構造を供給する。フィールドバスデバイスは、デバイス機能をメインまたは集中化デジタル制御システムから制御するという、さらに長く使用され、さらに型にはまったアプローチとは対照的に、プロセス内でのプロセスの局所化されている制御を実現する。Fieldbusデバイスは、フィールドバスデバイス内のフィールドデバイスと密接に関連付けられている、小型局所化隅制御装置/マルチプレクサ110を含むことにより局所化制御を達成する。フィールドバスの小型局所化制御装置は、フィールドバスデバイス内のフィールドデバイス上で動作し、フィールドバスデバイスに接続されているそれ以外のスマートフィールドデバイスでも動作する、標準化した制御機能または制御ブロックを実現する。したがって、プロセス制御環境100は、デバイス、特にFieldbusデバイス間での通信および制御が、Firldbus型制御動作がユーザにトランスペアレントになるように実行されるように、フィールドバスH1規格、Profibus規格、CAN規格およびそれ以外のバスをベースにしたアーキテクチャ企画などのスマートフィールドデバイス規格を実現する。プロセス制御環境100は、フィールドバスデバイスとHARTデバイスなどのスマートデバイス、および従来の非スマートデバイスを含む、実質的には無制限の数および型のフィールドデバイスへの接続を可能にする。多様な数と型のデバイスの制御および通信の動作は、同時に並行して実行されるのが有利である。プロセス制御環境100は、スマート型制御が、HARTデバイス134と従来のデバイス136などの非スマート型デバイスに関して達成されるように、フィールドバスH1規格などの標準フィールドバスプロトコルによって定義されている機能ブロックまたは制御機能の標準セットを実現し、実行する。さらに、プロセス制御環境100によって、スマートデバイスは、機能ブロックと制御機能の標準セットを実現できるようになる。有利なことに、プロセス制御環境100は、まるですべての接続されているデバイスがスマートデバイスであるかのように、総体的な戦略を実現する。このインプリメンテーションは、部分的には、制御構造に根本的なビルディングブロックとして機能ブロックを使用することにより達成される。これらの機能ブロックは、すべての型のデバイス用の制御構造を作成するために定義される。機能ブロックの根本的なビルディングブロックの使用は、図6、図7、図8、および図9に説明されている。プロセス制御環境100は、制御戦略の特殊部分をスマートデバイスおよび非スマートデバイスの中にダウンロードまたはインストールすることによって、機能ブロックおよび制御モジュールの定義を通して総体的な、ユーザによって作成された制御戦略を実現する。それ以降、スマートデバイスは、他の制御システム動作とは無関係に、総体的な戦略のダウンロードされた部分を自動的に実行する。例えば、デバイスの中にダウンロードされた、またはインストールされた制御戦略の部分は、制御装置/マルチプレクサ110およびワークステーションの制御動作とは無関係に、およびそれと並行して動作するが、他の制御動作は、スマートデバイスを管理し、制御戦略のそれ以外の部分を実現する。事実上、プロセス制御環境100は、スマートデバイス内で制御装置/マルチプレクサ110を使用して、制御戦略を実現する。図5に図示されている機能522の機能ブロックを定義するブロック図の例が、図6に示されている。具体的には、図6は、プリミティブオブジェクトだけを包含するように定義されている要素別処理機能ブロック定義600を描いている。要素別処理機能ブロック定義600は、合計機能を定義し、プリミティブ610、プリミティブ610に適用されている第1パラメータ614である第1入力属性612、およびプリミティブ610に適用されている第2パラメータ624である第2入力属性622を含む。プリミティブ610は、出力属性630として供給される結果を作り出す。この例では、要素別処理機能ブロック定義600は、作成され、SUMと名前が付けられるブロック定義である。図5に図示されている機能522の機能ブロックを定義しているブロック図の第2の例は、図7に示されている。具体的には、図7は、1つまたは複数の要素別処理機能ブロック600、およびオプションで1つまたは複数のプリミティブオブジェクトを包含するように定義される複合機能ブロック定義700を描いている。複合機能ブロック定義700は、複合合計機能を定義し、そのそれぞれが、図6に示されているSUM要素別処理機能ブロック600と同じである、第1SUM要素別処理機能ブロック710と第2SUM要素別処理機能ブロック712を含む。複合機能ブロック700は、それぞれ、第1SUM要素別処理機能ブロック710に適用されている第1パラメータ724と第2パラメータ726である、第1入力属性720および第2入力属性722を有している。第1要素別処理機能ブロック710は、第2SUM要素別処理機能ブロック712に第1パラメータ730として適用される結果を生じさせる。複合機能ブロック700は、第2SUM要素別処理機能ブロック712に適用されている第2パラメータである、第3入力属性728を有している。第2SUM要素別処理機能ブロック712は、出力属性734として供給される結果を生じさせる。この例では、複合機能ブロック定義700は、作成され、SUM3と名付けられているブロック定義である。図4に図示されている制御モジュール440の制御モジュールを定義しているブロック定義の例が、図8に示されている。具体的には、図8は、定義されており、多様な入力属性810、要素別処理機能ブロック820、第1SUM3複合機能ブロック830、および第2SUM3複合機能ブロック832を包含する、制御モジュール定義800を描いている。例示的な制御モジュール440は、その内の3つが第1SUM3複合機能ブロック830に適用されている、5つの各要素別処理機能ブロック820に接続されている5つの入力属性810を含む。第1SUM3複合機能ブロック830は、残りの2つの要素別処理機能ブロック820によって供給されているパラメータと組み合わせて第2SUM3複合機能ブロック832へのパラメータとして供給される結果を生じさせる。第2SUM3複合機能ブロック832は、出力属性840として供給される結果を生じさせる。この例では、制御モジュール800は、作成され、CMIと名前が付けられている制御モジュール定義である。図5に図示されているモジュールインスタンス544、具体的には制御モジュールインスタンスのモジュールインスタンスを定義しているブロック図の例が、図9に図示されている。制御モジュールインスタンス910と920は、各制御モジュールインスタンス910と920が、図8に図示されている5つの入力属性810に一致する、それぞれ5つの入力属性912と922を含むように、CM1制御モジュール定義に従って作成される。各制御モジュールインスタンス910と920は、図8に図示されている出力属性840に一致する、それぞれ1つの出力属性914と924も含む。この例では、制御モジュールインスタンス910と920は、作成され、それぞれCALC1とCALC2とタグが付けられている制御モジュールインスタンスである。システムユーザは、定義エディタを使用して、SUM3要素別処理機能ブロック定義、SUM3複合機能ブロック定義、およびCM1制御モジュール定義などの定義を作成し、名前を付ける。それから、モジュールエディタを使用し、システムユーザは、インスタンスを作成し、CALC1とCALC2制御モジュールインスタンスなどのタグを付ける。図10を参照すると、フローチャートは、実行時の制御モジュール実行の一例を示している。実行時プログラムは、スケジューラルーチンを含む。スケジューラルーチンは、コンピューティング技術でよく知られている。スケジューラルーチンは、複合制御モジュール、例えば図8に図示されているタグCM1付きの複合制御モジュール440の実行1010を要求する。CM1複合制御モジュール440は、入力属性820の転送を始動し、あらゆる関連付けられいてるリンク、つまり属性関連付けを転送させる1014。データベース定義は、典型的には、関連付けを参照するが、実行時定義はリンクに関係する。ステップ1016から1056では、CM1複合制御モジュール440が各要素別処理機能ブロック820、第2SUM3複合機能ブロック830および第2SUM3複合ブロック832に、代わりに実行するように要求する。具体的には、ステップ1016では、CM1複合制御モジュール440が、各要素別処理機能ブロック820に実行するように要求する。要素別処理機能ブロック820は、入力属性、例えば図6に図示されている第1入力属性612の転送1018を始動する。要素別処理機能ブロック820の入力属性は、ステップ1014で転送されているリンクからの値のロードを要求する1020。リンクは、ソース属性から宛先属性へ値をコピーする1022。要素別処理機能ブロック820は、ブロックアルゴリズム1024を実行する。ブロックアルゴリズムの実行完了時、要素別処理機能ブロック820は、出力属性1026、例えば、図6に図示さえている出力属性630の転送を始動する。ステップ1028では、CM1複合制御モジュール440が、第1SUM3複合機能ブロック830に実行するように要求する。第1SUM3複合機能ブロック830は、入力属性、例えば図7に図示されている入力属性722,724、およb726要素別処理機能ブロック820からの転送1030を始動する。ステップ1032では、第1SUM3複合機能ブロック830は、内部機能ブロック、例えば、図7に図示されている第1SUM要素別処理機能ブロック710と第2SUM要素別処理機能ブロック712に、代わりに実行するように要求する。第1SUM要素別処理機能ブロック710は、ステップ1034で、入力属性を読み取り、ブロックアルゴリズムを実行し、出力属性を設定する。第2SUM要素別処理機能ブロック712は、ステップ1036で、入力属性を読み取り、ブロック図を実行し、出力属性を設定する。第1SUM3複合機能ブロック830は、ステップ1038で出力属性の転送を始動する。第1SUM3複合機能ブロック830の出力属性は、ステップ1040で、関連付けられているリンクに、出力属性から値をコピーするように要求する。ステップ1042では、CM1複合制御モジュール440が、第2SUM3複合機能ブロック832に実行するように要求する。第2SUM3複合機能ブロック832は、第1SUM3F複合機能ブロック830出力属性に接続されているリンクから入力属性の転送1044を始動する。ステップ1046においては、第2SUM3複合機能ブロック832が、内部機能ブロック、例えば、図7に図示されている第1SUM要素別処理機能ブロック710と第2SUM要素別処理機能ブロック712に、代わりに実行するように要求する。第2SUM要素別処理機能ブロック710は、ステップ1048で、入力属性を読み取り、ブロックアルゴリズムを実行し、出力属性を設定する。第2SUM要素別処理機能ブロック712は、ステップ1050で、入力属性を読み取り、ブロックアルゴリズムを実行し、出力属性を設定する。第2SUM3複合機能ブロック832は、ステップ1052で出力属性の転送を始動する。第2SUM複合機能ブロック832の出力属性は、ステップ1054で、関連付けられているリンクに、出力属性からの値をコピーするように要求する。ステップ1056では、CM1複合制御モジュール440が、出力属性の転送を始動し、出力属性840が、第2SUM3複合機能ブロック832からのリンクに、第2SUM3複合機能ブロック832出力属性の値をコピーするように要求する。いくつかの実施態様においては、出力機能ブロックは、出力値をユーザ構成PIOブロック属性図示されていないに押しつける。このようにして、PIO属性は、出力機能ブロックが出力値をPIOブロック属性に押しつける間に、機能ブロックによって引っ張られる。同様にして、入力機能ブロックは、PIOブロック属性から入力属性値を引っ張る。ユーザは、制御モジュールを構成し、制御戦略を決定する機能ブロックを指定することにより、モジュール制御戦略を定義する。ユーザは、機能ブロックを追加、修正および削除し、機能ブロックに関連付けられているパラメータを構成し、新規属性に対するビューを作成することによって、モジュール制御戦略を修正するか、デバッグする。機能ブロックおよび制御モジュールを定義することによって、ユーザ定義制御戦略、アプリケーションプログラムまたは診断プログラムは、モジュールとして識別されている相互接続済み制御オブジェクトの層のセットとして表される。制御戦略の層は、ユーザによって指定されるように相互接続されているモジュールのセットを含む。モジュールは、典型的には、特殊機能、および情報をユーザに表示するために使用される表示構成要素を実行するためのアルゴリズムを含む。モジュールは、オプションで、他のモジュールに接続するための入力接続と出力接続のセットを含むように表記される。モジュールは、指定されている機能を実行し、指定されている入力接続と出力接続を介して他のモジュールに接続されているブラックボックスと考えてよい。図11を参照すると、表示画面が、制御構造のさらに高い層でのモジュールまたはアプrケーションプログラムLOOPSUMの一例を示すフローチャートとして役立つ。LOOPSIM1060のアプリケーションプログラムの示されている層は、AI1と呼ばれている入力属性AINモジュール1062、不感時間モジュール1064、比例積分微分PID制御モジュール1066、出力属性AOUTモジュール1068、およびシミュレーションモジュール1070を含む。実例となるモジュールのそれぞれは、回線を介して他のモジュールに接続されている、名前が付けられている入力接続および出力接続を含む。モジュールのセット、モジュールのセットの入力接続および出力接続、およびモジュールの間の相互接続が、LOOPSIM1060アプリケーションの動作を定義する。最低レベルでは、モジュールは、相互接続されている機能ブロックのセットである。さらに高いレベルでは、モジュールでは、代わりにサブモジュールの追加セットを含んでよい相互接続されているサブモジュールのセットである。例えば、PID制御モジュール1066は、典型的には、PID機能性に含まれているさまざまな機能を実行する、相互接続されているサブモジュールのセットである。PIDモジュール1066の入力接続および出力接続は、PIDモジュール1066の次に低い層内の1つまたは複数のサブモジュールの入力接続および出力接続である。PIDモジュール1066のサブモジュールは、オプションで、サブモジュール間での相互接続を定義するほど十分なそれ以外の入力接続および出力接続を含む。任意のモジュールレベルでのアプリケーション、モジュールまたはサブモジュールは、わずかに異なる機能を実行するため、あるいは異なるやり方で同じ機能を実行するためにユーザによりオプションで修正される。したがって、ユーザは、オプションでモジュールを修正し、それにより、制御構造を希望されるように修正する。具体的には、ユーザは、オプションで、モジュールに入力接続と出力接続を追加し、モジュールの入力接続および出力接続をさらに高いレベルのモジュールまで拡大し、そのため多様なアプリケーション用のモジュールをカスタマイズする。例えば、入力接続および出力接続をするユーザモジュール1066は、PIDモジュール1066に対する入力接続および出力接続として表示される。プロセス制御環境は、FieldBlocks、SequentialFunctionChartsSFC、LadderLogicおよびStructuredTextなどのIEC-1131標準言語を含む複数の制御言語で編集動作を供給することにより、制御構造の定義および修正を容易にする。したがって、異なった制御背景のさまざまな種類のユーザがさまざまな言語を使用し、同じアプリケーションまたは異なったアプリケーションを実現するためのさまざまなモジュールを書き込む。制御モジュールは、複数の有利な特性を有するように指定される。属性への直接アクセスを可能にする制御モジュールもある。例えば、直接最大性能通信をサポートする重いheavy属性と呼ばれている属性がある。直接通信は、例えば、機能ブロックおよびControlModules制御モジュールを接続するため、イベント/警報検出および高性能傾斜trendingをサポートするために有利に使用される。制御モジュールの定義時に自動的に作成され、ユーザがControlModuleの属性として露呈されるパラメータを促進または強制するオプションを持つ、いくつかの属性がある。パラメータを包含しているが、この性能を供給する上で生じるオーバヘッドを保証しない、属性の直接的な通信性能がControlModule,EquipmentModule,PIOBlock,またはDeviceなどのモジュールを通してアクセスできるようになるパラメータもある。これらのパラメータは、制御システムチューニング、デバッギング、および保守に関係する情報を供給するために有利にアクセスされる。いくつかの実施態様においては、これらのパラメータは、コンテナ内の属性、呼出し可能サービス、およびサブコンポーネントを明らかにするためにタグ付きコンテナによって提供されているサービスを使用する、汎用パラメータブラウザアプリケーションによってアクセスされる。図12を参照すると、ブロック図が、制御サブシステムの動作を通してPIOデバイスの中にプロセスI/O属性ブロックをインストールするためのオブジェクト指向方法を説明している。定義済みオブジェクトのブロック1110は、サイトオブジェクト1112、制御装置デバイス1114、制御装置I/Oサブシステム1116、PIOインタフェースデバイス1118、およびPIOデバイス1120を含む。PIOデバイスのインストール前に、制御装置I/Oサブシステム1116が、以前に作成される。PIOデバイス1120も、インストールまたはダウンロードのどちらかにより以前作成されている。定義済みオブジェクトのブロック1110は、詳細ポインタ1112をブロック定義のリスト1124に向け、ブロック作成の1128を命令する作成ポインタ1126によって作成される特定の型のオブジェクトを指定する。ブロック定義1124は、配線によるインストールとして、または過去のインストールによって、PIO入力属性AINブロック定義を含む。指定されているオブジェクトの属性は、エディタ1130の動作を通してユーザによって設定される。PIOデバイスのインストールの前に、入力属性AINブロック1132は存在しない。ユーザは、AINブロック1132をインストールする前に、PIOデバイス1120を作成し、それからエディタ1130を使用して、AINブロック属性の初期値をセットアップする。ユーザは、ビューパラメータ取得のための期間も設定する。AINブロック1132が保存されてから、インストールされる。図13を参照すると、ブロック図は、ControlModule入力属性をプロセスI/O属性にリンクするためのオブジェクト指向方法を説明している。制御モジュール入力属性をPIO属性にリンクする前に、PIOブロックAIN1220は過去にインストールされ、制御モジュール1210もインストールされる。ユーザは、制御モジュール1210のPIOIN属性1212が属性入力プロセス変数PV1214に接続されていることを指定し、リンクが行われることを要求する。制御モジュールがPIOIN属性を発見して対応する属性インデックスを返し、プラント領域にPIOAINを配置し、プロセス変数PV属性を発見して対応する属性インデックスを返し、実行時リンカーlinker1216にプロセス変数PV1214でのソースおよびPIOIN属性1212とのリンクを作成するように指示し、リンクを作成し、リンク1216を接続すると、リンク1216が行われる。ダウンロードの最後で、リンクは連結オブジェクトにより分離されるresolved。図14を参照すると、ブロック図が、制御モジュール出力属性AOUT1312属性をPIO出力属性PIOAOUT1320にリンクするためのオブジェクト指向方法を示している。制御モジュール1310が過去にインストールされ、制御モジュール出力属性AOUT1312が制御モジュール1310内にインストールされる。ユーザは、制御モジュール出力属性AOUT1312が、PIO出力属性PIOAOUT1320に接続されることを指定する。制御モジュール1310の実行時インプリメンテーションがメッセージに送信され、接続を形成し、制御モジュール1310がAOUT属性を発見し、PIOAOUT属性1320のロケーションを要求し、リンク1322を作成し、AOUT属性1312およびPIOAOUT属性1320をリンク1322に接続すると、リンクが行われる。図15を参照すると、ブロック図が、包含されているPIO属性の値を読み取るためのオブジェクト指向方法を示す。PIOブロック141は、過去にインストールされ、出力属性AOUT1412がPIOブロック1410内で過去にインストールされている。ユーザ、例えばエンジニアは、すべての属性値が表示されているブロックの詳細なビューを要求する。詳細なディスプレイは、PIOブロック1410と関連付けられている、ビュー定義とも呼ばれる表示グループの1つまたは複数のセットを含む。AOUTブロックの属性名および値は、プロキシクライアントルーチンに、ビューにアクセスするように要求するアプリケーションプログラムによって提示され、AOUTプロキシクライアントが戻りビュー定義を設定し、属性プロキシオブジェクトを作成し、アプリケーションプログラムがAOUTプロキシクライアントに許可されている特権で名前が付けられている属性の値を読み出すように要求する。アプリケーションプログラムはデータをフォーマットし、表示する。表示グループパラメータは、I/Oブロック定義の一部であり、したがって構成可能ではない。表示グループは、属性のために定義される。表示グループおよびビューグループがブロックに関連付けられている非リンクPIO属性の更新を制御するため、PIOブロックがリンクされていない間に、情報は有利に更新される。図1Cに図示されているプロセス制御環境100は、制御構造のための根本的なビルディングブロックとして関数ブロックを使用することによってだけではなく、フィールドバスおよび非フィールドバスデバイスを同じように処理する入出力アーキテクチャを実現することによって、あたかもすべての接続されているデバイスがフィールドバスデバイスであるかのように、総体的な戦略を実現する。入出力アーキテクチャの根本的な特徴は、フィールドバス信号および非フィールドバス信号を含むすべてのI/O信号にユーザ構成可能名を与える計測器信号タグISTに基づいている。ユーザの観点からは、ISTはユーザ定義名を単一型に、I/Oサブシステム内の特殊な信号に、属性を含む信号毛色に、および信号特性設定値のセットに結合する。ISTは、他のシステムオブジェクトのようにインストールされない。代わりに、ISTタグに固有な信号特性が、I/Oカードインストール時に利用できるようになる、I/OPortI/OポートおよびI/ODeviceI/Oデバイス特性と結合される。IST、I/OPortおよびI/ODevice特性の組み合わせは、実行時システムでPIO機能ブロックを作成するための情報を供給する。ISTからの信号毛色は、モジュールのインストール中にI/OFunctionBlocks機能ブロックを定義するスクリプト内に含まれる。プロセス制御環境100全体で通信するため、I/O型FunctionBlocksは、I/O基準定義を使用する。ISTは、I/O基準の仕様を満たす。英国の測定技術社MeasurementTechnologiesLimitedにより供給されるMTLデバイスなどの従来のI/Oデバイスは、チャネルごとにISTを有している。HartデバイスおよびフィールドバスI/Oデバイスは、Portポート上、またはフィールドDeviceデバイスでの別個のI/O信号ごとにISTを含んでよい。IST名は、システム全体の範囲を有し、Modulesモジュール、DevicesデバイスおよびAreas領域の名称空間を共用する。大型システムにおいては、ISTは、典型的には、計装図面上の測定器信号名に一致する。小型システムでは、公式計測器図面は存在しないことがあるため、明白なIST名は推論されない。典型的には、任意のIST名が回避されるように、カードが、制御装置ノード、I/Oサブシステム、カードおよびポートを表すデバイスハイアラーキーに基づいて構成されると、ISTが自動的に生成される。典型的には大部分のISTは、新規I/Oカードが定義されると自動的に作成される。複数-単一I/Oデバイスの場合、ISTは、単一の一次信号のためだけに自動的に作成される。自動IST作成に加えて、ユーザは、PortまたはDeviceが選択されている、ExplorerNodeIOsubsysPortDeviceツリーから利用できるAssignメニューを使用して、あるいはExplorerISTツリーから利用できるNewメニューを使用して、ISTを作成してもよい。ISTは、I/O信号にアクセスするI/O信号とIOFunctionBlockの間での互換性を確実にするために信号型特性を持っている。信号型は、AIN、AOUT、DIN、DOUT、PCIN、PCOUTの内の1つである。ISTは、信号型に特殊な信号関係属性のセット例えば、DOUTなどのAIN、MOMENTARYまたはLATCHEDの場合、EU0とEU100を有している。同じ信号型のすべての信号ソースが、同じ信号属性のセットを有している。I/Oサブシステムオブジェクトのすべての他の特性は、カード、ポート、またはデバイスの属性に保持される。完全に構成されているISTは、I/Oシステム、例えばCON1/IO1/S01/C01/FIELD_VAL内の対応する信号への完全に修飾されている経路を有している。ISTは、I/O構造詳細が完全に定義される前にモジュール構成が完了されるように、定義済み経路を定義しないで作成してよい。定義済み経路のないISTを使用するIOFunctionBlocksのあるモジュールは、構成、インストールされてよいが、実行時システムは、IOFunctionsブロック上で見失われているISTの見失われているI/O経路に適切に対処しなければならない。信号ソースはわずかISTしか有していない。同じ経路のある複数のISTを構成しようとすると拒絶される。ユーザは、ISTを削除し、それによって関連付けられている信号特性を削除し、おそらくいくつかの分離不可能なIST基準をIOFunctionBlocksに残すことによってISTを削除してよい。削除されたISTは、関連付けられているISTを示さないExplorerツリーでのPortDevice上のISTの通常のディスプレイのあるカード/ポート/デバイス特性に影響を及ぼさない。I/OインタフェースFunctionBlocksは、少なくとも1つのIST-Reference特性を有している。IST-Reference特性は、機能ブロックがISTに接続していないことを示すためにブランクのままにされるか、あるいは有効なIST名で指定される。IOFunctionBlocksのIST-Reference特性は、まったく1つのIST信号型と互換性がある。例えば、AIFunctionBlockのIST-Referenceは、信号型AINだけのあるIStを有している。複数のIOFunctionBlocksは同じIST信号型と互換性がある。フィールドバスIOFunctionBlock定義との互換性のため、フィールドバスIOFunctionBlocksは、ISTの単一特性のいくつかと重複するXD_SCALE,OUT_SCALEなどの属性を有している。有効なIST-Referenceが作成されると、これらの重複されているFunctionBlock属性の構成済み値は、Runtimeシステムで無視され、ISTからの対応する特性が代わりに使用される。フィールドバスIOFunctionBlocksを構成するエンジニアは、IST基準が適所にあるときに無視されている属性の表示を使用する。このような表示は、典型的には、値がISTからコピーされている、淡色表示されているgrayedout編集不可テキストとして表示装置で提示される。IOFunctionBlockは、典型的にはダウンロードされ、迅速に無効にされる無視されている属性の非公開設定値を保持する。IST-Referenceが削除されると、これらの属性の設定値がユーティリティを保持する。IOCards、PortsおよびDevicesは、ExplorerTMまたはModuleDefinitionEditorのどちらかである、ユーザインタフェースを動作しているユーザによって構成の中に組み込まれる。従来のI/Oカード上のチャネルは、従来のI/O用の特殊ケースの専門用語が回避されるように、ポートと呼ばれ、I/Oポートとして処理される。また、ユーザインタフェースは、ユーザが、IOCards、PortsまたはDevicesを削除できるようにする。例えば、8-チャネル8chanMTLAI、8-チャネルMTLAO、8-チャネルMTLDI、8-チャネルMTLDO、4-チャネルMTL熱伝対/RTD、8チャネルHART入力、8-チャネルHART出力、および4-chanSolenoidを含む複数のIOCard型がサポートされている。IOCard型は、同じIOCard上でのIOPort型の組み合わせを有している。IOCardの削除は、すべての従属Portsを削除する。I/Oポートの削除は、すべての従属Devicesを削除する。IOPortsまたはIODevicesの削除は、関係する計測器信号タグISTを削除しないが、関連付けられているI/O信号へのIST経路の経路はもはや実施可能ではない。同じ経路を有している別のIOPortまたはIODevicesが作成されると、信号型が互換性がある限り、ISTは自動的にIOPortsまたはIODeviceへ再結合する。ユーザは、Subsystemで定義されているIOCardをインストールまたはインストールし直す、I/Oサブシステムのインストールを始動する。ユーザは、カード特性およびIOPortsおよびIODevicesのすべての特性をインストールする、単一IOCardのインストールを始動することができる。ExplorerTMおよびModuleDefinitionEditorは、現在の信号値、ステータス、およびI/Oサブシステム内でAttributesとして直接アドレス指定することができる選択されている特性にアクセスすることによってI/Oサブシステムを構成する。ユーザは、各カード、ポート、デバイスおよび信号値、およびデバイスハイアラーキー属性経路アドレス指定例えば、CON1/IOI1/C01/P01/FIELD_VALを使用するステータスにアクセスすることによって、カード、ポート、デバイス、および信号値とステータスを示すグラフィックを表示する。I/Oサブシステム属性は、デバイス間での通信でアドレス指定するために物理デバイス経路例えば、CON1/IO1/C01/P01/FIELD_VALを使用して通信される。I/Oサブシステム属性の通信は、表示のために図1Cに図示されるように、制御装置/マルチプレクサ110からワークステーション102,104,106へ、および仮想I/O取扱いのために第1から第2制御装置/マルチプレクサに属性を伝送するために有利に使用される。図16を参照すると、ブロック図は、計測器信号タグISTの情報の構成を示している。システムISTテーブル1510は、経路情報およびシステムオブジェクトへのポインタを含む、ISTに関係する情報を記載している。第1ポインタ1512は、属性信号テーブル1520を指す信号型を指定する。第2ポインタ1514は、属性信号テーブル1520でのエントリを指定する。有利にアドレス指定するデバイスハイアラーキー属性を使用して情報にアクセスすることにより、ControlModule作業が完了する前にシステム統合チェックアウトのために、システム診断表示を設計、構築することができる。デバイスハイアラーキー属性アドレス指定は、ModulesからのI/O信号の直接アドレス指定、I/O機能ブロックの使用のバイパス、およびI/O機能ブロック動作の回避もサポートする。一般鉄器には、IOCard、IOPortおよびIODeviceの識別子は、スロット位置情報等に従って自動的に定義される。図17を参照すると、フローチャートが、制御装置/マルチプレクサ110をIPアドレス、ノード名、および制御装置/マルチプレクサ110のフラッシュROMに記憶されていないその他の起動情報のセットに割り当てる動作を含む、プロセス制御環境100内でのネットワーク全体で制御システムをブートストラップロードする方法を説明している。インターネットプロトコルIPアドレスを、その初期ブートアップ時に制御装置に割り当てるためのプロセス1600は、Bootサーバ、WindowsNTTMワークステーションのMACアドレスを制御装置/マルチプレクサ名1610に関連付けるステップを含む。MACアドレスだけが、制御装置/マルチプレクサアイデンティティを指定する。ステップ1612では、制御装置/マルチプレクサの名前には、属性デバイスID、および制御装置/マルチプレクサに接続されているケーブルによって決定されるACNリンク番号とPCNネットワーク番号が割り当てられる。ステップ1614では、デバイスのIPアドレスがデバイスID、ACNリンク番号およびPCNネットワーク番号から計算される。ステップ1616では、ノードをブートするために確保されているデフォルトの一次IPアドレスと二次IPアドレスを指定し、UDPユーザデータの制御装置/マルチプレクサMACアドレスを含むUDPデータグラムが、一次インタフェース上のソースアドレスのためにデフォルトの一次IPアドレスを使用する特殊UDP確保ブートポートに一斉送信される。ステップ1618では、ブートサーバがMACアドレスを割り当てられている名前とIPアドレスに照会し、割り当てられている名前とIPアドレスを、MACアドレスのエコーとともに、UDPブートポートに一斉送信する。一斉送信することにより、ルーティングまたはARP静的入力操作を実行するという問題は回避される。ステップ1620では、制御装置/マルチプレクサがデータグラムを受信し、MACアドレスをチェックし、MACアドレスが一致する場合にはIPアドレスを設定し、ノード名および絵倍すIDを保存する。データグラムが受信されないと、分岐ステップ1622の動作を通して二次インタフェースを使用して、手順が繰り返される。ステップ1624では、制御装置/マルチプレクサが、新しい住所を使用して、制御装置/マルチプレクサが稼動中であることを示していると述べているブートサーバにメッセージを送信する。ステップ1626では、ユーザは、DeviceName、DeviceMACAddress、ACNLinkNumberおよびPCNNetworkNumberを入力する。デバイスIDは、構成ソフトウェアにより自動的に割り当てることができる。通信サブシステムは、構成済みACNリンク番号、PCNネットワーク番号、および割り当てられているデバイスIDからのデバイスの3つのIPアドレスを計算する。ステップ1628では、制御装置/マルチプレクサ、またはI/Oカードソフトウェアが、メッセージおよびS-RecordファイルをACN上のデバイス間で受け渡すことによって、ACNネットワーク上でフラッシュダウンロードされる。図18を参照すると、オブジェクト通信図が、接続のアクティブな発信側に対してデバイス接続を作成するための方法を示している。ワークステーションまたは制御装置/マルチプレクサのどちらかのアプリケーションプログラムは、別のデバイスに包含されている属性へのアクセスを要求する。他のデバイスへのUDP通信接続は、属性にアクセスできるように通信サービスによって確立される。デバイス接続の作成は、2つのアプリケーションプログラムに及ぶ。別のデバイス内に位置しているデータを要求することにより接続を始動するアプリケーションプログラム、およびリモートオブジェクト通信ROCサービスアプリケーションプログラムは実際に他のデバイスにメッセージを送信する。ROCサービスプロセスがあるデバイスにメッセージを送信する準備ができているときに接続が存在しない場合、ROCサービスはそのデバイスに対する接続を作成する。デバイス接続の前に、接続されるデバイスはソースデバイスを記載している有効なDeviceTableを有しており、動作しており、直接接続ポートでメッセージを監視するオブジェクトRtDeviceConnectionを含む。デバイス接続が作成された後、2つのデバイスの間で接続が確立され、RtDeviceconnectionインスタンスがアクティブデバイスの中に作成され、接続を取り扱う。ステップ1710では、アプリケーションプログラムが、メッセージgetContainerを、発見されたまたは作成されたモジュールのオブジェクトIDを戻すオブジェクトRtSiteに送信する。ステップ1712では、オブジェクトRtSiteが、モジュールの位置を見つけ出し、そのオブジェクトIDを戻すオブジェクトRtPlantAreaにLocateメッセージを送信する。ステップ1714では、オブジェクトRtSiteが、モジュールを包含しているデバイスのオブジェクトIDを戻すオブジェクトRtDeviceに、GetDeviceメッセージを送信する。ステップ1716では、リモートデバイスのプロキシが存在しないと仮定して、オブジェクトRtDeviceが、オブジェクトRtDeviceProxyにCreateメッセージを送信する。ステップ1718では、オブジェクトRtDeviceProxyが、テンプレートRtNewを使用してオブジェクトRtDeviceProxyのインスタンスを作成する。ステップ1720では、オブジェクトRtDeviceProxyが、オブジェクトRtDeviceConnectionに、どれが、オブジェクトRtDeviceConnectionによって管理されているデバイス接続テーブル内のデバイス名のインデックスを戻すのかをGetDeviceConnectionIndexするように依頼する。ステップ1722では、オブジェクトRtDeviceProxyが、RegisterPointerメッセージをオブジェクトRtRegistryに送信することにより、接続されているデバイスのRtDeviceProxyインスタンスに対するポインタを登録し、オブジェクトRtDeviceにデバイスプロキシObjectIDを戻す。ステップ1724においては、オブジェクトRtPlantAreaが、オブジェクトRtModuleProxyClientにCreateメッセージを送信し、リモートモジュールに対するプロキシクライアントを作成する。ステップ1726では、オブジェクトRtModuleProxyClientが、オブジェクトRtModuleProxyServerにCreateメッセージを送信し、リモートデバイス内のモジュール用のプロキシサーバを作成する。ステップ1728では、オブジェクトRtModuleProxyServerが、プロキシサーバ作成メッセージを構築し、オブジェクトRtRocReqRespServiceに、リモートデバイスにSendRequestするように依頼する。ステップ1730では、オブジェクトRtRocReqRespServiceが、ROC通信サービスプロセスがリモートデバイスに送信するために、メッセージをOutboundMessageQueueにAppends付加する。ステップ1732では、ROC通信サービスプロセス内のオブジェクトRtRocReqRespServiceが、RemoveFirstコマンドをOutboundMessageQueueに発効し、プロキシサーバ作成メッセージを取得する。ステップ1734では、RtRocReqRespSericeが、sendMsgコマンドを、宛先デバイスのaRtDeviceProxyインスタンスに発行することによりメッセージを送信する。ステップ1736では、aRtDeviceProxyインスタンスが、GetDeviceConnectionコマンドをRtDeviceConectionコマンドに発行し、宛先デバイスのRtDevceConnectionインスタンスのオブジェクトIDを取得する。ステップ1738では、デバイス接続がすでに存在しないと仮定し、オブジェクトRtDeviceConnectionがcreateDeviceConnectionを実行する。ステップ1740では、オブジェクトRtDeviceConnectionが、テンプレートRtNewを使用して、RtDeviceConnectionのインスタンスを作成する。ステップ1742では、オブジェクトRtDeviceConnectionが、RegisterPointerメッセージをオブジェクトRtRegistryに送信することによりRtDeviceConnectionインスタンスに対するポインタを登録し、デバイス接続ObjectIDをオブジェクトRtDeviceConnectionに戻す。ステップ1744では、オブジェクトRtDeviceConnectionが、startActiveConnectionメッセージをaRtDeviceConnectionインスタンスに送信する。aRtDeviceConnectionインスタンスは、他のデバイスに対する接続を確立するために必要なステップを実行する。ステップ1746では、RtDeviceProxyインスタンスが、sendMsgをaRtDeviceConnectionに発行し、サーバ作成メッセージをリモートデバイスに送信する。ステップ1748では、aRtDeviceConnectionインスタンスが、新規に作成されている接続でリモートデバイスにメッセージを送信する。図19を参照すると、オブジェクト通信図が、接続の受動リスン側にデバイス接続を作成する方法を示している。デバイス接続を確立するための要求は、別のワークステーションまたは制御装置/マルチプレクサから受け取られる。通信サービスは、要求側デバイスとUDP通信接続を確立する。接続の作成以前に、接続されるデバイスは動作中であり、接続を確立する準備ができているオブジェクトaRtDeviceConnectionを包含している。オブジェクトRtDeviceConnectionは、デバイスの中に存在し、同期要求をいう形の入力メッセージを求めて傾聴しているlistening。接続が作成されてから、接続は2つのデバイスの間で確立され、RtDeviceConnectionインスタンスが受動的なデバイス内に作成され、その接続を取り扱う。ステップ1810では、オブジェクトRtDeviceConnectionはリモートデバイスから同期要求メッセージを受け取る。ステップ1812では、オブジェクトRtDeviceConnectionは、オブジェクトRtDeviceConnectionにCreateメッセージを送信し、要求側デバイスへの接続を作成する。オブジェクトRtDeviceConnectionは、デバイス接続がすでに存在していないと仮定し、ステップ1814でcreateDevoceConnectionを実行する。ステップ1816では、オブジェクトRtDevoceConnectionは、テンプレートRtNewを使用してRtDeviceConnectionのインスタンスを作成する。ステップ1818においては、オブジェクトRtDeviceConnectionは、RegisterPointerメッセージをRtRegistryに送信することによってRtDeviceConnectionインスタンスに対するポインタを登録し、デバイス接続オブジェクトIDをオブジェクトRtDeviceConnectionに戻す。ステップ1820では、オブジェクトRtDeviceConnectionが、オブジェクトRtDeviceProxyにCreateメッセージを送信し、要求側デバイスのためのデバイスプロキシを作成する。ステップ1822では、オブジェクトRtDeviceProxyが、テンプレートRtNewを使用してRtDeviceProxyのインスタンスを作成する。ステップ1824では、オブジェクトRtDeviceProxyが、オブジェクトRtDeviceConnectionにGetDeviceConnectionIndexメッセージを送信し、後で使用するために、デバイス接続テーブル内のデバイスのインデックスをRtDeviceConnectionによって管理させる。ステップ1826では、オブジェクトRtDeviceProxyが、RegisterPointerメッセージをRtregistryに送信することによりRtDeviceProxyに対するポインタを登録し、デバイスプロキシオブジェクトIDをRtDeviceConnectionに戻す。ステップ1828では、オブジェクトRtDeviceConnectionは、handleInboundMessage方法を介して処理するために、RtDeviceConnectionインスタンスに同期要求メッセージを渡す。ステップ1830では、オブジェクトaRtDeviceConnectionが、リモートデバイスに同期応答メッセージを送り返し、DeviceConnection作成の無事完了を示す。図20を参照すると、オブジェクト通信図が、デバイス間で要求/応答メッセージを送信するための方法を示している。あるデバイスでのリモートオブジェクト通信ROCサービスは、別のデバイス内のROCサービスに対し要求メッセージを送信する。要求メッセージは処理され、応答メッセージが発信側デバイスに送り返される。メッセージを送信する前に、デバイス間でUDPデバイス接続が確立される。デバイス間での要求/応答メッセージの送信に続き、リモートデバイスからの応答メッセージが、ROCサービスによる処理のために準備完了している。ステップ1910では、読取り属性要求が、アプリケーションプログラムによってリモートデバイスに関連付けられているRtDeviceProxyインスタンスに対し発行される。ステップ1912では、aRtDeviceProxyインスタンスが、属性値を読み取るために、リモートデバイスに対し送信される要求メッセージを構築し、RtRocReqRespServiceにSendRequest方法を使用してメッセージを送信するように依頼する。ステップ1914では、オブジェクトRtRocReqRespServiceが、リモートデバイスへの接続に関連付けられているRtDeviceConnectionのインスタンスに対し、sendmsg方法を使用してメッセージを送信する。ステップ1916では、RtDeviceConnectionのインスタンスが、デバイス接続でリモートデバイスに対しメッセージを伝送する。ステップ1918では、リモートデバイス内のRtDeviceConnectionのインスタンスがメッセージを受け取り、RtRocRouterクラスにメッセージを正しい到着メッセージサービスにメッセージを送るように要求する。ステップ1920では、オブジェクトRtRocRouterが、メッセージが要求/応答メッセージであると判断し、オブジェクトRtRocreqRespServiceに、ProcessInboundRepRespするように要求する。メッセージがROCサービスおよびメッセージ消費者によって処理された後、応答メッセージが構築され、ステップ1922では、オブジェクトRtRocRqstRespServiceが、SendResponse方法を使用して応答メッセージを発信側デバイスに送信する。ステップ1924では、RtRocReqRespServiceの出発メッセージ待ち行列処理が、send_msg方法を使用して、ソースデバイスに対する接続に関連付けられているRtDeviceConnectionのインスタンスに応答メッセージを送信する。ステップ1926では、RtDeviceConnectionのインスタンスが、オリジナルデバイスに対し応答メッセージを送り返す。ステップ1928では、オリジナルデバイスのRtDeviceConnectionのインスタンスがメッセージを受け取り、RtRocRouterクラスにメッセージを正しい到着メッセージサービスに送るように要求する。ステップ1930では、オブジェクトRtRocRouterが、メッセージが要求/応答メッセージであると判断し、RtRocReqRespServiceにProcessInboundreqRespするように要求する。図21を参照すると、オブジェクト通信図が、ネットワーク構成をダウンロードする方法を示している。ユーザは、システム用のデバイス構成の完了に続き、制御装置/マルチプレクサへのダウンロードを始動する。構成アプリケーションによってデバイステーブル構成スクリプトが構築される。通信サービスを使用して、構成アプリケーションは、ダウンロードを受信するために、制御装置/マルチプレクサとのデバイス接続を確立し、ダウンロードスクリプトを制御装置デバイスに送信する。制御装置/マルチプレクサは、ダウンロードスクリプトメッセージを受信し、デバイステーブルを処理する。ステップ2010では、構成ダウンロードアプリケーションプログラムが、デバイステーブルダウンロードスクリプトを包含するリモートオブジェクト通信ROCスクリプトダウンロードメッセージを構築する。ステップ2012では、Downloadアプリケーションが、RtDeviceに対しGetDeviceメッセージを発行し、リモートデバイスのRtDeviceProxyのObjectIDを取得する。ステップ2014では、RtDeviceProxyは、存在していないため、Createメッセージが必要なデバイスプロキシオブジェクトを作成するために、RtDeviceProxyCに送信される。ステップ2016では、RtDeviceProxyCが、RtDeviceConnectionにGetDeviceConnIndexメッセージを送信し、デバイス接続テーブル内のリモートデバイスのデバイス接続のインデックスを取得する。ステップ2018では、デバイス接続は、まだ存在していないため、aRtDeviceConnectionオブジェクトが作成され、リモートデバイスへの接続を管理する。ルックアップは、リモートデバイスエントリを発見するためにデータベースで実行される。デバイス通信データ例えば、IDおよびIPAddressesがデータベースから検索され、新規エントリが構成デバイス接続テーブルに追加される。デバイスが接続を始動したので、接続は接続テーブルで恒久と記される。ステップ2020では、startActiveconnectionメッセージがRtDeviceConnectionに送信され、リモートデバイスへの接続を確立する。ステップ2022では、aRtDeviceConnectionがリモートデバイスにRtSyncMessageを送信する。ステップ2024では、リモートデバイスがRtSyncMessageを受け取り、送信側デバイスのためのデバイス接続テーブル内でエントリを発見しようとする。ステップ2026では、エントリは発見されないため、新規エントリが送信側デバイスのためのデバイス接続テーブルに追加され、aRtDeviceConnectionオブジェクトが作成され、受信側デバイスで接続を取り扱う。ステップ2028では、RtSyncreplyMessageが作成され、デバイステーブルからのデバイス接続インデックスを包含している送信側デバイスに送り返される。デバイス接続は、現在、確立され、メッセージの送受を行う準備が完了している。ステップ2030では、RtDeviceProxyCが、リモートデバイスのRtDeviceProxyS作成メッセージを送信する。ステップ2032では、RtDeviceProxySがリモートデバイスで作成される。ステップ2034では、DownloadApplicationが、SendMsg呼出しを使用してRtRocReqRespServicesを介してリモートデバイスにダウンロードスクリプトを送信する。ステップ2036では、RtCommScriptDownloadが、DeviceTableを受信し、各デバイステーブルアイテムを処理し、そのデータを構成データを保持するために使用されているデータベースRegistryに記憶する。制御装置/マルチプレクサにとって、この処理はRtDeviceConnectionオブジェクトを作成し、そのオブジェクトをデバイス接続テーブルに追加するために使用され、それ以降より、むしろダウンロード時にメモリを取得できるようにする。デジタル制御システムプログラム115は、診断情報がフィールドバスデバイスから引き出されているか、非フィールドバスデバイスから引き出されているかには関係なく、首尾一貫したやり方でプロセスに関する診断情報を表示するための診断プログラムおよび表示ルーチンを含む。デジタル制御システムプログラム115は、プロセス制御環境100内のすべてのデバイスに関する診断情報を有利に組み込み、すべての制御動作および診断情報があたかも単一ロケーションで実行または作成されるかのように制御戦略および診断情報がユーザに提示されるように、この情報を、診断表示ルーチンを使用して統一してユーザに提示する。図22を参照すると、画面前面の絵入り図が、通信診断プログラム2210を含む診断表示ルーチン2200の動作のフローチャートを示している。ユーザは、容易に認識されているアイコンを使用して、プロセス制御環境100内のワークステーション、制御装置、およびネットワークリンクのステータスおよび完全性をグラフィックで表示する。診断表示ルーチン2200は、デバイスまたはネットワークリンクセグメントを求めて要約ステータス情報も作成する。診断表示ルーチン2200は、送受されたパケット、接続数等を含む、ネットワークに接続されているデバイスに関する詳細な内部完全性情報を表示する。リモート診断機能性を実現するために、モデムを介してアクセスされる診断情報もある。ワークステーション102または104、および制御装置/マルチプレクサ110は、ACN通信リンクのステータス、デバイス接続、イーサネット統計についての詳細な完全性情報、および通信スタック診断情報を含む、接続されているデバイス内の通信サブシステムのステータスについての詳細な診断情報を供給するために組み合わされて機能する。通信機能性の診断チェックもサポートされる。通信診断2210は、ネットワーク全体の基本診断、単一デバイスの診断情報、および単一デバイス接続の診断情報を含む、3つのレベルの診断情報をサポートする。基本的なネットワーク診断レベルでは、通信診断2210が、すべてのネットワークデバイスから情報を収集し、その情報をユーザに提示する。通信診断2210は、要求に応じてまたは定期的に実行しているバックグラウンドタスクとして、リモート制御装置/マルチプレクサ110から情報を収集する。通信診断2210はネットワーク通信ステータス要求をある特定のデバイスの診断ポートに送信し、そのデバイスに対する通信経路の完全性を確認する。ネットワーク通信ステータスに対する応答は、デバイスが制御装置であるのか、あるいはワークステーションであるのかを示すデバイス型情報を含む通信完全性情報、および一次と二次ステータス要約情報を包含する。エラーがリンク上に存在する場合には不良に設定されるConnectionStatusSummaryが、属性としてCommunicationsSubsystemModuleに追加され、ユーザが、要求があると、これらの値をオペレータインタフェースで表示できるようにする。通信診断2210は、デバイスとリモートデバイスの間の通信リンクのステータスが表示されるように、プロセス制御環境100に接続されている各デバイスから診断情報を要求する。通信診断2210は、デバイス接続に関するリンクステータス情報、およびデバイス内のイーサネットインタフェースに関するイーサネット統計を含む、ある特定のデバイスの通信についての詳細な情報を供給するために、単一デバイスの診断情報を監視、表示する。通信診断2210は、適切な診断リモートオブジェクト通信ROCメッセージを使用して、デバイス通信ステータスを要求する。デバイス通信ステータスは、DeviceTableIndex、DeviceID、DeviceConnectionStateReady準備完了、Synching同期中、ACKPendingACK未決、Closed閉鎖済み、PrimaryDeviceAddress、SecondaryDeviceAddress、LinkStatus、および単一デバイス接続の診断情報などの情報を含む。イーサネット統計情報は、デバイスブート時に計数を開始し、デバイスのリブートまでリセットされないカウンタに保持される。カウントは、モジュール属性の一部としてCommunicationsサブシステムモジュールに対する属性として実現され、合計入力エラー、入力CRCエラー、および入力無効エラーの数を含む入力エラー情報を含む。出力エラー情報は、合計出力エラー、出力遅延衝突、事前に選択されている数を上回る出力衝突、出力無効エラー、および出力キャリヤ損失エラーを含む。それ以外のカウントは、受信パケット、送信パケット、受信バイと、送信バイト、受信一斉送信パケット、送信一斉送信パケット、受信未知プロトコルメッセージ、伝送延期、単一衝突伝送、および複数衝突伝送の数を含む。通信診断2210は、ある特定のデバイスのある特定のデバイス接続に関する詳細な診断情報も監視、表示する。ユーザがデバイス接続統計を要求すると、通信診断2210は接続のために宛先デバイスIDを指定する。デバイス接続統計は、DeviceConnectionStateReady、Synching,ACKPending、Closed、RemotePrimaryAddress宛先デバイスのPrimaryACNAddress、RemoteSecondaryAddressこのデバイスの二次ACNIPAddressまたは0、PrimaryLinkStatusGood良好/Bad不良、SecondaryLinkStatusGood/Badを含む、指定されたデバイス接続のリンクステータス情報および統計情報を包含する。統計は、PrimaryLinkで受信されたメッセージ、SecondaryLinkで受信されたメッセージ、PrimaryLinkde送信されたメッセージ、SecondaryLinkで送信されたメッセージ、SynchsSent、SynchsReceived,PrimaryLinkでのACKTime-outs、およびSecondaryLinkでのACKTime-outsのカウントも含む。通信診断2210は、ネットワーク内の2つのデバイス間の通信経路のチェックもサポートする。第1デバイスは、リモートデバイスへ、指定された通信リンク上で喚起メッセージなどのメッセージを送信する。リモートデバイスは、そのメッセージを送信者にエコーして戻す。無事完了した喚起メッセージおよびエコーは、リモートデバイスで通信サブシステムが機能していることを示す。この対話は、完全にイーサネットハードウェアドライバによって取り扱われている通常のTCP/IPピーンpingとは異なる。図23を参照すると、オブジェクト通信図が、あるデバイスが、別のデバイスがネットワーク上に存在するかどうかをチェックする方法を示している。プロセス制御環境の一部またはスタンドアロンアプリケーションのどちらかである、診断アプリケーションプログラムが、リモートデバイスがACNネットワーク上に存在するかどうか、存在する場合には、リモートデバイスが通信できるかどうかを突き止める。診断アプリケーションプログラムはリモートデバイスにメッセージを送信し、リモートデバイスからエコーされるメッセージまたはタイムアウトを受信することを期待する。ステップ2310では、診断アプリケーションプログラムは、オブジェクトRtcommDiagに、通信問い合わせピーンが指定されているデバイス名またはアドレスに対し実行されることを要求するPingメッセージを送信する。ステップ2312では、オブジェクトRtCommDiagが通信ソケットを作成し、問い合わせを実行する。ステップ2314では、オブジェクトRtCommDiagがRtEchoMessageを作成し、リモートデバイスに送信する。ステップ2316では、オブジェクトRtCommDiagが、RtCommSendToを使用し、指定されているデバイスにRtEchoMessageを送信し、メッセージがリモートデバイスからエコーバックされるのを待機する。ステップ2318では、リモートデバイス内のオブジェクトRtDeviceConnectionがRtEchoMessageを受信し、HandleDiagnosticMessage方法を使用してそのメッセージを処理する。ステップ2320では、オブジェクトRtDeviceConnectionが、RtCommSentToMessageを使用して、ソースデバイス内のオブジェクトRtCommDiagへのエコー応答の診断符号付きRtEchoMessageを即座に戻す。ステップ2322では、オブジェクトRtCommDが、エコー応答メッセージを受信し、診断アプリケーションに無事完了ステータスを戻す。リモートデバイスから応答が受信されない場合、ステップ2324で、オブジェクトRtCommDiagが診断アプリケーションに故障ステータスを戻す。ステップ2326では、オブジェクトRtCommDiagが、問い合わせを実行するために作成されたソケットを閉じる。図24を参照すると、オブジェクト通信図が、デバイス通信診断を要求するための方法を示している。診断アプリケーションプログラムは、リモートデバイス内のすべてのデバイス接続のステータスを要求、アクセス、表示する。診断アプリケーションプログラムは、リモートデバイスに必要とされている診断情報に対する要求を送信し、応答を待機する。いったん応答が受信されると、リモートデバイス内でのすべてのデバイス接続およびデバイスステータスがユーザに表示される。この情報は、診断アプリケーションプログラムが診断データに対する複数の要求を行うように、複数のメッセージで通信してよい。ステップ2410では、DiagnosticApplicationプログラムが、オブジェクトRtComjmDiagにGetDeviceCommDiags要求を送信し、リモートデバイスでのデバイス接続の通信診断を要求する。ステップ2412では、オブジェクトRtCommDiagが、オブジェクトRtDeviceConnectionにGetDeviceConnectionIndexメッセージを送信し、リモートデバイスのデバイス接続テーブルインデックスを要求する。ステップ2414では、オブジェクトRtCommDiagが、オブジェクトRtRocMessageに対しCreateを発行し、診断情報を要求するために使用されるメッセージを作成する。ステップ2416では、オブジェクトRtRocMessageが、診断要求に使用されるaRtRocMessageの新規インスタンスを作成する。ステップ2418では、オブジェクトRtCommDiagが送信されるメッセージを構築し、RtRocReqRespServiceにSendRequestを発行し、メッセージをリモートデバイスに送信する。ステップ2420では、オブジェクトRtcommDiagが、診断要求メッセージ用に作成されているaRtRocMessageインスタンスにwaitForResponseを発行する。ステップ2422では、オブジェクトRtRockReqRespServiceが、リモートデバイスに関連付けられているaRtDeviceConnectionのインスタンスでsendmsgを実行する。ステップ2424では、aRtDeviceConnectionインスタンスが、要求メッセージをリモートデバイスに伝送する。ステップ2426では、リモートデバイス内のオブジェクトRtDeviceConectionが、メッセージを受信し、送信側デバイスに関連付けられているaRtDeviceConnectionインスタンスに、handleInboundMessageを発行する。ステップ2428では、aRtDeviceConnectionインスタンスが、処理のために、Route方法を介してRtRocRouterにメッセージを渡す。ステップ2430では、オブジェクトRtRocRouterが、RtRocReqRespServiceにProcessnboundReqRespを発行することによってメッセージに応答する。ステップ2432では、RtRocReqRespServiceが、要求メッセージIDからメッセージ型を求め、RtRocDevConDiagListMsgメッセージに関するperformコマンドを発行する。ステップ2434では、RtRocDevConDiagListMsgが、オブジェクトRtDeviceConnectionにGetDiagListメッセージを送信し、このデバイスでのデバイス接続のためにデバイス接続診断データを取得する。ステップ2436では、オブジェクトRtDeviceConnectionが、ユーティリティクラスRtDevConDiagListDataによって提供されている多様な塗りつぶしfillルーチンを使用して、診断データを出たバッファの中に入れる。ステップ2438では、RtRocDevConDiagLisMsgが、CreateResponseを実行し、診断データを包含する応答メッセージを作成する。ステップ2440では、RtRocDevConDiagListMsgが、RtDevConDiagListDataにstoreOnメッセージを発行し、診断データを応答メッセージの中に入れる。ステップ2442では、RtRocDevConDiagListMsgが、SendResponse方法を使用して、RtRocReqRespServiceを通して要求側デバイスに応答メッセージを送り返す。ステップ2444では、RtRocReqRespServiceが、要求側デバイスに関連付けられているaRtDeviceConnectionインスタンスに対しsend_msgを実行する。ステップ2446では、aRtDeviceConnectionインスタンスが、要求側デバイスに応答メッセージを送り返す。ステップ2448では、要求側デバイス内のaRtDeviceConnectionインスタンスが、handleInboundMessageを介して、RtDeviceConnectionから応答メッセージを受信する。それから、応答メッセージは、Route方法を使用してRtRocRouterに送信する。ステップ2450では、RtRocRouterが、RtRocReqRespServiceに対しProcessInboundReqRespを実行する。ステップ2452では、RtRocReqRespServiceが、aRtRocMessageインスタンスに、診断データに対する元の要求への応答が入手できることを知らせる。ステップ2454では、RtCommDiagが、RtDevConDiagListDataに対しreadFromを発行し、応答メッセージから診断データを検索する。ステップ2456では、RtCommDiagが、RtDevConDiagListDataに対しgetDataメッセージを発行し、表示のために診断データを検索するDiagnosticApplicationにデータを戻す。要求側デバイスは、すべてのデバイス接続活動の一般的な診断を適所に包含しているバッファを戻す。図25を参照すると、オブジェクト通信図が、デバイス接続通信診断を要求するための方法を示している。診断アプリケーションプログラムは、リモートデバイスに存在している単一デバイスの詳細なステータスを要求、アクセス、および表示する。診断アプリケーションプログラムは、リモートデバイスに、デバイス接続統計情報に対する要求を送信し、応答を待機する。いったん応答が受け取られると、デバイス接続に関するデバイス接続統計がユーザに表示される。ステップ2510では、DiagnosticApplicationプログラムが、RtCommDiagにGetDeviceConDiags要求を送信し、リモートデバイスでの特定のデバイス接続に関するデバイス接続統計を取得する。ステップ2512では、RtCommDiagが、RtDeviceConnectionにGetDeviceConnectionIndexメッセージを送信し、リモートデバイスのデバイス接続テーブルインデックスを取得する。ステップ2514では、RtCommDiagが、RtRocMessageに対しCreateを発行し、診断情報を要求するために使用されるメッセージを作成する。ステップ2516では、RRocMessageが、診断要求のために使用されるaRtRocMessageの新規インスタンスを作成する。ステップ2518では、RtCommDiagが、送信されるメッセージを構築し、RtRocReqRespServiceにSendRequestを発行し、メッセージをリモートデバイスに送信する。ステップ2520では、RtCommDiagが、診断要求メッセージのために作成されているaRtRocMessageインスタンスにwaitForResponseを発行する。ステップ2522では、RtRocReqRespServiceが、リモートデバイスに関連付けられているaRtDeviceConnectionのインスタンスに対しsend_msgを実行する。ステップ2524では、aRtDeviceConnectionインスタンスが、リモートデバイスに要求メッセージを伝送する。ステップ2526では、リモートデバイス内のRtDeviceConnectionがメッセージを受信し、送信側デバイスに関連付けられているaRtDeviceConnectionインスタンスにhandleInboundMessageを発行する。ステップ2528では、RtDeviceConnectionインスタンスが、処理のためにRouterメッセージを介して、RtRocRouterにメッセージを渡す。ステップ2530では、RtRocRouterが、メッセージが要求応答型メッセージであることを突き止め、RtRocReqRespServiceに対しProcessInboundReqRespを発行する。ステップ2532では、RtRocReqRespServiceが、要求メッセージIDからメッセージ型を突き止め、RtRocDevConDiagDetailMsgメッセージに対するperform実行コマンドを発行する。ステップ2534では、RtRocDevConDiagdetailMsgが、RtDeviceConnectionにGetDiagDetailメッセージを送信し、要求されているデバイス接続に関するデバイス接続統計を取得する。ステップ2536では、RtDeviceConnectionが、ユーティリティクラスRtDevConDiagDetailDataによって提供される多様な塗りつぶしルーチンを使用して、データバッファの中に診断データを入れる。ステップ2538では、RtRocDevConDiagDetailMsgが、CreateResponseを実行し、診断データを包含している応答メッセージを作成する。ステップ2540では、RtRocDevConDiagDetailMsgが、RtDevConDiagDetailDataに対し、storeOnメッセージを発行し、診断データを応答メッセージの中に入れる。ステップ2542では、RtRocDevConDiagDetailMsgが、SendResponse方法を使用してRtRocReqrespServiceを通して要求側デバイスに応答メッセージを送り返す。ステップ2544では、RtRocReqRespServiceが、要求側デバイスに関連付けられているaRtDeviceConnectionインスタンスに対しsend_msgを実行する。ステップ2546では、aRtDeviceConnectionインスタンスが、要求側デバイスに応答メッセージを送り返す。ステップ2548では、要求側デバイス内のaRtDeviceConnectionインスタンスが、handleInboundMessageを介して、RtDeviceConnectionから応答メッセージを受け取る。応答メッセージは、Route方法を使用してRtRocRouterに送信される。ステップ2550では、RtRocRouterが、RtRocReqRespServiceに対しProcessInboundReqRespを実行する。ステップ2552では、RtRocReqRespServiceが、aRtRocMessagerに対し、診断データを求める元の要求に対する応答が入手できることを知らせる。ステップ2554では、RtCommDiagが、RtDevConDiagDetailDataに対しreadFromを発行し、応答メッセージから診断データを検索する。ステップ2556では、RtCommDiagが、getDataメッセージをRtDevConDiagDetailDataに発行し、表示のために診断データを検索するDiagnosticApplicationにデータを戻す。一般的には、制御装置/マルチプレクサ110は、手動でネットワークに追加される。例えば、デバイスは、典型的には、ユーザが、デバイスが接続されることになるACNSegmentを選択し、NewDevice新規デバイスコマンドを発行するとネットワークに追加される。ユーザは、ワークステーションまたは制御装置/マルチプレクサのデバイス型、デバイス名、およびコマンドフィールドを入力するようにプロンプトを出される。構成システムは、自動的にデバイスに次のDeviceIDを割り当て、そのDeviceIDに基づきデフォルト名を構築する。構成システムは、オプションで、PCN番号および過去に割り当てられたDeviceIDに基づき、デバイスに対し一次と二次IPアドレスおよびサブネットマスクを自動的に生成する。代わりに、制御装置/マルチプレクサは、自動的に検知され、図26に図示されるように実行時システムの中に組み込まれる。ステップ2610では、制御装置/マルチプレクサは、ACNへの接続時、および電力が適用されると、識別またはIPアドレス割当て検証を求める要求を自動的に送信する。要求メッセージは、制御装置/マルチプレクサのMACアドレスを含む。要求は、ステップ2612で、マスタ構成制御装置/マルチプレクサで、オペレーティングシステム技術で知られているプラグアンドプレイネットワーク構成サービスによって取り扱われる。ステップ2614では、プラグアンドプレイネットワーク構成サービスが、ネットワークから、IPアドレスを割り当てる/検証するあめの要求を受け取り、MACアドレス一致を求めて構成済みデバイスのテーブルを検証する。一致が発見されると、ステップ2616で、プラグアンドプレイネットワーク構成サービスが、DeviceName、DeviceID、IPAddressInformation、SubnetMaskInformation、ACNSegmentNumber、およびDeviceTableに含まれているその他のアイテムをもって応答する。一致が発見されない場合、ステップ2618で、プラグアンドプレイネットワーク構成サービスは、制御装置/マルチプレクサMACアドレス例えば、Controller-000001に基づきデバイスのデフォルト名を自動的に生成する。新規デバイスは、ステップ2620でDeviceScratch領域内のデータベースに追加される。ステップ2622では、ユーザはExplorerTMを使用して、DeviceScratch領域内の各未割当て済み制御装置/マルチプレクサを選択し、適切なACNセグメントまで選択をドラッグし、新規デバイスとして選択をシステムに追加するか、あるいは事前に存在していたデバイス構成に選択をドロップする。未割当て済み制御装置/マルチプレクサが、新規デバイスとして追加される場合、構成処理は、デバイスの手動組込みのやり方で進む。ステップ2624では、ユーザは、過去に割り当てられていた名称Controller-000001をデフォルトとして使用し、本当のデバイス命を入力するようにプロンプトが出される。自動アドレス割当てが設定されている場合、新規デバイスには次のDeviceIDと関連付けられているIPアドレスが割り当てられ、Subnetマスクは、ステップ2626で自動的に割り当てられる。手動アドレス割当てが設定されている場合、デバイスは、自動的に、次のDeviceIDを割り当てられ、ユーザは、ステップ2628でIPAddressesとSubnetMasksを入力するようにプロンプトを出される。制御装置/マルチプレクサのMACアドレスは、ACNセグメントの中にドラッグされるように、Controller-000001のMACアドレスに設定される。新規制御装置/マルチプレクサName、DeviceID、IPAddress、SubnetMasksおよびACN番号が、データベース内のデバイステーブルに追加される。未構成制御装置/マルチプレクサによる次の要求は、プラグアンドプレイネットワーク構成サービスによって回答される。新規制御装置/マルチプレクサが既存のデバイス上でドラッグアンドドロップされる場合、そのデバイスは、制御装置/マルチプレクサ型のデバイスであり、見割当てMACアドレスを有していなければならない。したがって、過去に入力された制御装置/マルチプレクサのMACアドレスは、ドロップされたController-000001でバイアスのMACアドレスに設定される。新規制御装置/マルチプレクサName、DeviceID,IPAddresses、SubnetMasksおよびACN番号が、プラグアンドプレイネットワーク構成サービスによって要求側制御装置/マルチプレクサに対し送信するために入手できる。デジタル制御システムプログラム115は、ユーザによる自動構成コマンドに応えて、あるいは新規制御装置/マルチプレクサの検出に応えて、入出力I/Oサブシステムを自動的に構成するための自動構成ルーチンを含む。図27を参照すると、フローチャートが、物理I/O装置を構成するための自動構成ルーチンのステップを示している。自動構成コマンドは、Controller/Multiplexer110に命令され、Controller/Multiplexer110内の各I/Oサブシステムに自動構成させる。自動構成コマンドは、I/Oサブシステムに命令され、I/Oサブシステム内の各I/Oカードに自動構成させる。自動構成コマンドは、I/Oカードに命令されることもある。I/OCardの自動構成動作は、まず最初に、ある特定のカード位置でI/Oカードに応答指令信号を送り、ステップ2710でCardType、および暗にいくつかのI/Oカードでは、I/OCard内のI/OPortの数を突き止める。I/OCardがそのカード位置に関してエンジニアリングデータベースで過去に作成されていなかった場合、ステップ2712で適切な型のI/OCardが定義され、適切な数のI/OPortが作成される。I/OCardが、そのカード位置に関してエンジニアリングデータベース内に存在しないが、エンジニアリングデータベース内のCardTypeがカード位置で検知されたCardTypeと一致しない場合、自動構成動作が、ステップ2714で不一致のグラフィック通知を作成し、ユーザに応答指令信号を送り、エンジニアリングデータベースが、CardTypeを含むように変更されなければならないかどうかを判断する。エンジニアリングデータベース内のCardTypeは、ユーザによって要求される場合、検知済みCardTypeに変更される。一端CardTypeが知られると、自動構成プログラムは、ステップ2718でCardTypeに従って各I/OPortに応答指令信号を送り、Porttypeおよび情報が入手できる場合には、I/OPort上でのI/ODevicesの数を突き止める。I/Oポートが、そのポートアドレスに関し、エンジニアリングデータベース内で過去に作成されなかった場合、適切な型のI/Oポートが定義され、ステップ2720で適切な数のI/ODevicesnが作成される。I/OPortが、そのPortアドレスに関しエンジニアリングデータベース内に存在するが、PortTypeが検知されたI/OPortの型と一致しない場合、ユーザは、ステップ2722で不一致を通知され、ステップ2724で検知されたI/Oポートに一致するようにエンジニアリングデータベースを変更するかどうか尋ねられる。エンジニアリングデータベース内のPortTypeは、ユーザによって要求される場合、ステップ2726で検知されたPortTypeに変更される。一端PortTypeが知られると、自動構成プログラムは、ステップ2728でPortTypeに従って各I/ODeviceに応答指令信号をくり、DeviceTypeを突き止める。I/ODeviceが、そのデバイスアドレスに関し、エンジニアリングデータベース内で過去に作成されなかった場合、適切な型のI/ODeviceがステップ2730で定義される。I/ODeviceが、そのDeviceアドレスに関しエンジニアリングデータベースに存在するが、DeviceTypeが検知されたI/ODeviceと一致しない場合、ユーザは、ステップ2732で不一致を通知され、ステップ2734で、検知されたI/ODeviceに一致するようにエンジニアリングデバイスを変更するかどうかを尋ねられる。エンジニアリングデータベース内のDeviceTypeは、ユーザによって要求される場合、ステップ2736で検知されたDeviceに変更される。ステップ2738では、同一の信号ソース経路とともにISTがすでに存在しない限り、計測器信号タグISTが、I/OPortおよびI/ODevice上の一次信号ソースに関して自動的に作成される。図28を参照すると、グラフィックユーザインタフェースGUI用の画面2800とも呼ばれている画面前面表示が、システム構成のディスプレイを描いている。画面2800は、プロセス制御環境を選択、構築および動作するためにユーザによって層さされるナビゲーション選択を描いている。ナビゲーションプログラムは、ネットワーク中の多様なツールおよびプロセッサを横切ってナビゲーションするための初期状態を供給する。ユーザは、ナビゲーションプログラムを制御し、ライブラリ、領域、プロセス制御環境、および機密保護動作にアクセスする。実例となるシステム構成は、制御システムセットアップ2802、制御戦略2804、および物理セットアップ2806に関して記述され、制御される。制御システムを自動的に検知し、自動的に構成する機能は、物理セットアップ2806に関係する。特に、制御システムにおける物理デバイスを自動的に検知し、自動的に構成する機能は、制御ネットワーク2808内でのデバイスの作動および起動、制御装置2810の使用中止に関係する。実例となる実施態様においては、プロセス制御システムは、フィールドバス規格プロトコルに従ってプロセス制御ネットワークに接続されている多様なデバイスを制御する。フィールドバスプロトコルでは、標準ユーザアプリケーションがブロックに基づいて定義される。ブロックは、多様な異なる種類のアプリケーション機能の表現である。ブロックの種類には、リソースブロック、機能ブロック、および変換器ブロックを含む。リソースブロックは、デバイス名、製造業者、および連続番号などのフィールドバスデバイスの特徴を記述する。デバイスは、単一リソースブロックしか含まない。機能ブロックは、制御システムの動作を定義する。機能ブロックの入力パラメータおよび出力パラメータは、フィールドバス上でリンクしてよい。各機能ブロックの実行は、正確に予定を立てられる。ユーザアプリケーションは、多数の機能ブロックを含んでよい。標準機能ブロックの例は、アナログ入力AI、アナログ出力AO、バイアスB、ControlSelectorCS、DiscreteInputDI、DiscreteOutputDO、ManualLoaderML、Proportional/DerivativePD、Proportional/Integral/DerivativePID、および率RAを含むことがある。機能ブロックは、フィールドバスデバイスの中に構築され、選択されているデバイス機能性を定義する。1つの例では、簡略温度送信機が、AJ機能ブロックを包含してよい。多くの場合、制御弁は、PID機能ブロックおよびAOブロックを含む。変換機ブロックは、センサを読み取り、出力ハードウェアに命令を出すために、ローカル入力機能および出力機能から機能ブロックを減結合する。変換器ブロックは、校正データおよびセンサ型などの情報を包含する。典型的には、ユーザアプリケーションは、入力または出力機能ブロックごとに1つの変換器ブロックを使用する。ユーザアプリケーションで定義されている別のオブジェクトは、デバイスにとって内部で、フィールドバスネットワーク全体での機能ブロック入力と出力の間のリンクを定義するためのリンクオブジェクトを含む。傾向オブジェクトにより、他のデバイスによるアクセスのために、機能ブロックパラメータの局所的な傾斜trendingが可能になる。警報オブジェクトは、フィールドバス上での警報およびイベントの報告を可能にするために使用される。ビューオブジェクトは、人間/機械インタフェースで使用されているブロックパラメータセットの既定義分類である。機能ブロック指定は、ブロックの型ごとに4つのビューを定義する。図29を参照すると、状態遷移図が、フィールドデバイスの多様な状態を示している。フィールドデバイス状態は、オフライン状態2902、未認知状態2904、スタンバイ状態2906、作動済み状態2908、および未結合状態2910を含む。フィールドデバイスの状態は、システム管理状態SM-State、物理デバイスタグPD-Tag、デバイスアドレス、デバイス改訂情報Rev、およびデバイス識別Device-IDを含む複数のパラメータにより判断される。実例となる実施態様においては、作動済み状態2908にあるデバイスは、制御戦略の構成およびインストールに利用できるフィールドバスデバイスである。使用が中止されたデバイスとは、作動済み状態2908から削除されたデバイスのことである。T1からT14の複数の状態遷移の内の1つの状態遷移を生じさせる複数のイベントが発生する。各状態遷移中には、1つまたは複数の動作が実行される。状態遷移T1は、一時アドレスに常駐しているフィールドデバイスが、システム管理特定サービスSMIDENTIFYにより照会されるイベントによって引き起こされ、問い合わせが、デバイスがクリアされた物理デバイスタグを有していると判断する。状態遷移T1は、フィールドデバイスにスタンバイアドレスを割り当てることによって、NULL状態からOFFLINE状態に変化する。典型的にはファームウェア、ソフトウェア、またはハードウェアという形で論理を実行することにより、物理デバイスタグ設定サービスSET-PD-TAGが実行され、フィールドデバイスのデバイス識別に同一の物理デバイスタグが設定される。論理の実行はデバイスアドレス設定サービスSET-ADDRESSも使用し、スタンバイアドレスをフィールドデバイスに送信する。状態遷移T2は、一時アドレスに常駐しているフィールドデバイスが、システム管理特定サービスSM-IDENTIFYにより照会されるイベントにより引き起こされ、問い合わせが、デバイスが、デバイスのデバイス識別に同一である物理デバイスタグを有していると判断する。状態遷移T2は、フィールドデバイスにス端だバイアドレスを割り当てることにより、NULL状態からOFFLINE状態に変化する。論理の実行は、デバイスアドレス設定サービスSET-ADDRESSを使用し、スタンバイアドレスをフィールドデバイスに送信する。状態遷移T3は、一時アドレスに常駐しているフィールドデバイスが、システム管理特定サービスSM-IDENTIFYにより照会されるイベントにより引き起こされ、問い合わせが、デバイスが現在のプロセス制御システムネットワーク回線に構成されている物理デバイスタグおよびデバイス識別を有していると判断する。状態遷移T3は、割り当てられているアドレスをフィールドデバイスに送信するためにデバイスアドレス設定サービスSET-ADDRESSを利用する論理の実行を使用して、NULL状態からOFFLINE状態に変化する。状態遷移T4は、一時アドレスに常駐しているフィールドデバイスが、システム管理特性サービスSM-IDENTIFYにより照会されるイベントにより引き起こされ、問い合わせが、デバイスが現在のプロセス制御システムネットワーク回線に構成されている物理デバイスタグおよびデバイス識別を有していると判断する。状態遷移T4は、NULL状態からUNRECOGNIZED状態に変化する。状態遷移T5は、デバイスが一時アドレスに表示され、デバイスがユーザによって作動されているイベントにより引き起こされる。状態遷移T5は、OFFLINE状態から、フィールドデバイスの物理デバイスタグをクリアするために物理デバイスタグ設定サービスSET-PD-TAGを実行する、典型的にはファームウェア、ソフトウェア、またはハードウェアの形を取る、論理の実行を使用するOFFLINE状態に変化する。論理の実行は、物理デバイスタグ設定サービスSET-PD-TAGも実行し、割り当てられている物理デバイスタグをフィールドデバイスに送信する。論理の実行は、さらに、デバイスアドレス設定サービスSET-ADDRESSを使用して、割り当てられているアドレスをフィールドデバイスに送信する。状態遷移T6は、デバイスが一時アドレスで表示され、デバイスの使用がユーザによって中止されているイベントによって引き起こされる。状態遷移T6は、OFFLINE状態から、フィールドデバイスの物理デバイスタグをクリアするために物理デバイスタグ設定サービスSET-PD-TAGを実行する論理の実行を使用する、OFFLINE状態に変化する。状態遷移T7は、ユーザが、使用が中止されたデバイスをスタンバイにすることを要求するイベントにより引き起こされる。状態遷移T7は、フィールドデバイスにスタンバイアドレスを割り当てることによって、OFFLINE状態からOFFLINE状態に変化する。論理の実行は、物理デバイスタグ設定サービスSET-PD-TAGを実行し、フィールドデバイスのデバイス識別に同一である物理デバイスを設定する。論理の実行は、スタンバイアドレスをフィールドデバイスに送信するためにデバイスアドレス設定サービスSET-ADDRESSも使用する。状態遷移T8は、フィールドデバイスがスタンバイアドレスに表示されるイベントによって引き起こされる。状態遷移T8は、OFFLINE状態から、デバイス改訂情報をリソースブロックから読み取る論理の実行を通してSTANDBY状態に変化する。状態遷移T9は、フィールドデバイスが割り当てられているアドレスで表示されるイベントにより引き起こされる。状態遷移T9は、OFFLINE状態からCOMMISSIONEDに変化する。状態遷移T10は、STANDBY状態にあるデバイスを作動することを要求するユーザにより引き起こされる。状態遷移T10は、STANDBY状態から、デバイスアドレスをクリアするためにアドレスクリアサービスCLEAR-ADDRESSを使用する論理の実行を通してOFFLINE状態に変化する。状態遷移T11は、STANDBY状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移T11は、STANDBY状態から、デバイスアドレスをクリアするためにアドレスクリアサービスCLEAR-ADDRESSを使用する論理の実行を通してOFFLINE状態に変化する。状態遷移T12は、COMMOISSIONED状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移T12は、COMMISSIONED状態から、デバイスアドレスをクリアするためにアドレスクリアサービスCLEAR-ADDRESSを使用する論理の実行を通してOFFLINE状態に変化する。状態遷移T13は、フィールドバスシステム管理状態のINITIALIZED状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移T13は、UNRECOGNIZED状態から、フィールドデバイスの物理デバイスタグをクリアするために物理デバイスタグ設定サービスSET-PD-TAGを実行する論理の実行を通して、OFFLINE状態に変化する。状態遷移T14は、フィールドバスシステム管理状態のSM-OPERATIONAL状態にあるデバイスの使用を中止することを要求するユーザにより引き起こされる。状態遷移T14は、UNRECOGNIZED状態から、デバイスアドレスをクリアするためにアドレスクリアサービスを使用する論理の実行を通して、OFFLINE状態に変化する。フィールドバス規格に従って、適切に動作するためには、フィールドバスデバイスは、一意のデバイスアドレスネットワークアドレスおよび位置の物理デバイスタグを有している。プロセス制御システムネットワークリンクに接続されている各デバイスは、一意のノード指名子を有している。データリンク仕様は、恒久デバイスの範囲、一時アドレスの範囲、および訪問者visitorデバイスの範囲を含む、ノード指名子の許容値の範囲を指定する。一時アドレスは、現在、SM-OPERATIONAL状態にないデバイスによって私用される。フィールドバスインタフェースは、恒久デバイス用のアドレス空間の3つのセットへの区分化を維持する。割当て済みアドレスと呼ばれている1つのセットは、デバイスがバス上に存在するのかどうかに関係なく、特殊物理デバイスタグ付きのデバイスに割当て済みアドレスを含む。割当て済みアドレスは、Link-Active-Scheduler管理権取得takeover優先順位に関係する、ユーザにより入力される情報に基づいてソフトウェアエンジニアリングツールを使用して割り当てられる。スタンバイアドレスと呼ばれている第2セットは、SM-OPERATIONAL状態にあるデバイスを記述するが、デバイスアドレスは割り当てられていない。スタンバイアドレスは、フィールドバスインタフェースによって管理される。アドレスの第3セットは、第1セットと第2セットの外側のアドレスであり、未使用アドレスを参照する。少数の一時アドレスが自動検出およびオンラインアドレス割当てを複雑にする。スタンバイアドレスは、自動検出およびオンラインアドレス割当て動作の機能性をサポートするために定義され、活用される。割当て済みアドレスセットおよびスタンバイアドレスセットは、プロセス制御システムネットワークリンクへ接続されている潜在的なデバイスの数に等しく設定される。例えば、16のデバイスが、潜在的にプロセス制御システムネットワークに接続されると、16の割当て済みアドレスが定義され、16のスタンバイアドレスが定義される。デバイス改訂情報は、製造業社の識別MANUFAC-ID、デバイス型DEV-TYPE、デバイス改訂DEV-REV、およびデバイス記述改訂DD-REVを含む。オフライン状態2902では、フィールドデバイスは、最近、プロセス制御システムネットワークに接続されるか、あるいは作動されているまたは使用が中止されている過程にある。オフライン状態2902は、複数のパラメータ組み合わせを有しているデバイス状態を含む。第1オフライン状態2902では、システム管理状態はUNITIALIZEDであり、物理デバイスタグがクリアされる。第2オフライン状態2902では、システム管理状態はINITIALIZEDであり、物理デバイスタグが物理デバイスから読み取られ、画面上で表示できる。オフライン状態2902のどちらにおいても、デバイスアドレスは一時アドレスであり、改訂情報は入手可能ではなく、デバイス識別はデバイスから読み取られ、画面上に表示可能である。未認識状態2904では、フィールドデバイス物理デバイスタグおよびデバイス識別は、プロセス制御システムネットワークに接続されているデバイスのために作動されているcommissioned値と一致しない。第1未認識状態2904では、システム管理状態は、一時アドレスであるデバイスアドレスによるINITIALIZEDである。第2未認識状態2904では、システム管理状態は、スタンバイアドレスまたは割当て済みアドレスであるデバイスアドレスによりSM-OPERATIONALである。どちらの未認識状態2904においても、物理デバイスタグは、デバイスから読みぼられ、画面に表示することができ、デバイス改訂は使用可能ではなく、デバイス識別はデバイスから読み取られ、画面上に表示可能である。スタンバイ状態2906では、フィールドデバイスは、まだ自動検知されておらず、したがって制御戦略での構成には使用できない、あるいはLink-Active-SchedulerLASスケジュールの中に含まれていない。スタンバイ状態2909では、機能ブロック実行およびリンク通信がディスエーブルされている。Link-Active-Schedulerは、周期的に伝送されなければならない全デバイス内でのすべてのデータバッファの伝送時間のリストを含む、決定的な集中バススケジューラである。デバイスがデータバッファを送ることになっているとき、Link-Actove-Schedulerはデバイスにデータ強制CDメッセージを発行する。CDメッセージの受領時、デバイスはバッファ内のデータを一斉送信するか、フィールドデバイスバス上のすべてのデバイスに公表し、一斉送信デバイスは公表者であるように定義される。データを受信するように構成されているデバイスは加入者である。予定を立てられているデータ転送は、典型的には、フィールドバス上のデバイス間での制御ループデータの定期的、周期的な転送に使用される。スタンバイ状態2906では、システム管理状態はSM-OPERATIONALであリ、物理デバイスタグはデバイス識別に等しく、デバイスアドレスはスタンバイアドレスである。デバイス改訂情報は、フィールドデバイスから読み取られ、表示することができる。未結合状態2910は、その後、物理的に接続されることになるフィールドデバイス用の構成位置設定記号である。未結合状態2910は、まだ接続されていないフィールドデバイス内で機能ブロックを活用する制御戦略の構成をサポートする。未結合状態2910では、システム管理状態は、まだ適用できないが、物理デバイスタグはユーザによって指定されており、デバイスアドレスはユーザによって指定される。デバイス改訂情報は、もっとも最近の作動または構成に従って設定される。デバイス識別はクリアされる。作動済み状態2908では、フィールドデバイスは、制御戦略構成およびインストールに利用できる。システム管理状態はSM-OPERATIONALであり、物理デバイスタグはユーザによって指定されており、デバイスアドレスはユーザにより割り当てられる。デバイス改訂情報は、フィールドデバイスから読み取られ、画面上に表示できる。デバイス識別はフィールドデバイスから読み取られ、フィールド構成データベースに記憶され、表示画面で表示できる。複数の動作または使用ケースが、フィールドデバイスの作動および使用の中止を制御するために定義される。図30を参照すると、フローチャートが、第1動作、つまり新規デバイス3000の作動の動作を記述する使用ケースを示している。新規デバイスの作動の前に、フィールドバスインタフェースは稼動中である。デバイスはプロセス制御システムネットワークに接続されている。デバイスは、物理デバイスタグを有していないか、デバイス識別に等しい物理デバイスタグを有しているのどちらかである。新規デバイス3000を作動する動作の結果、デバイスに新規物理デバイスタグとデバイスアドレスが割り当てられ、デバイスが機能ブロック構成に準備完了している状態を生じさせる。新規フィールドデバイスは、プロセス制御システムネットワークデータベースに入力され、デバイス識別は結合され、デバイス改訂情報は設定されている。プロセス制御システムネットワークステータスを表示するエンジニアリングソフトウェアツールは、COMMISSIONEDデバイスとして新規デバイスを表示する。第1ステップ3002では、フィールドデバイスは、一時アドレスでライブリスト中に表示される。ライブリストとは、パストークンPTメッセージに適切に応答しているすべてのデバイスのリストのことである。フィールドバス上のすべてのデバイスは、予定されているメッセージの伝送の間に予定されていないメッセージを送信することが許されている。Link-Active-Schedulerは、デバイスにパストークンPTメッセージを発行することにより、デバイスにフィールドバスを使用する許可を与える。デバイスは、PTを受け取ると、メッセージが完了するまで、あるいは最大配信allottedトークン保持時間が時間切れになるまでメッセージを送信することを許される。最高優先順位活動として、Link-Active-Schedulerが、周期的に発生するように設定される動作のリストを包含しているCDスケジュールにアクセスする。予定された時刻に、Link-Active-Schedulerは、フィールドバスデバイス内の特定のデータバッファにデータ強制CDメッセージを送信する。デバイスは、ただちにメッセージをフィールドバス上のすべてのデバイスに一斉送信する。Link-Active-Schedulerは、予定されている転送の間に残りの動作を実行する。Link-Active-Schedulerは、ライブリストに記載されていないアドレスに定期的にプローブノードPNメッセージを送信することにより、継続して新しいデバイスをフィールドバスに追加する。デバイスがアドレスに存在し、PNを受信すると、デバイスはただちにプローブ応答PRメッセージを返す。デバイスがPRメッセージで応答すると、Link-Active-Schedulerはデバイスをライブリストに追加し、デバイスにノード起動NAメッセージを送信することにより確認する。デバイスは、PTに適切に応答する限りライブリストに残る。デバイスが追加されたり、ライブリストから削除されると、Link-Active-Schedulerは、ライブリストに対する変更をすべてのデバイスに一斉送信し、各デバイスがライブリストの最新のコピーを保持できるようにする。第2ステップ3004では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを照会し、フィールドデバイスが物理デバイスタグが設定されているUNINITIALIZED状態にあるのか、あるいはデバイス識別に等しい物理デバイスタグを有しているINITIALIZED状態にあるのかを判断する。それから、インタフェースは、フィールドデバイスにスタンバイアドレスを割り当てる3006。論理ステップ3008は、過去にUNITIALIZEDデバイスが、ステップ3010で、設定されている物理デバイスタグサービスSET-PD-TAGを使用してデバイス識別に同一のフィールドデバイスの物理デバイスタグを設定し、それによりフィールドデバイスをINITIALIZED状態にすることを命令する。スタンバイアドレスは、アドレス設定サービスSET-ADDRESSを使用してフィールドデバイス3012に送信され、フィールドデバイスをINITIALIZED状態からSM-OPERATIONAL状態に進める。この時点で、フィールドデバイスは、スタンバイアドレス3014でライブリストに表示される。デバイス改訂情報は、リソースブロック3016から読み取られる。ステップ3018では、実行中のソフトウェアエンジニアリングツールがフィールドデバイスをSTANDBYデバイスとして表示する。ステップ3020では、新規ユーザが、新規物理デバイスタグをフィールドデバイスに割り当てる。物理デバイスタグは、一意であり、デバイス識別とは同じではないように制約される。物理デバイスタグの割当て中、デバイスアドレスは、ソフトウェアエンジニアリングツールを使用してフィールドデバイスに割り当てられ、Link-Active-Scheduler管理権取得優先順位は選択可能に設定される。デバイス改訂情報は、フィールドデバイスから読み取られ、プロセス制御システムネットワークデータベースに書込まれる。インタフェースは、アドレスクリアサービスCLEAR-ADDRESSを使用して、フィールドデバイス3022の状態をINITIALIZED状態に変更する。フィールドデバイスは、一時アドレス3024でライブリストに表示される。ステップ3026では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを紹介し、デバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービスSET-PD-TAGを使用し、物理デバイスタグ3028をクリアし、それによってフィールドデバイス状態をUNINITIALIZED状態に変更する。それから物理デバイスタグ設定サービスSET-PD-TAGが使用され、割当て済み物理デバイスタグをフィールドデバイス3030に送信し、フィールドデバイス状態をINITIALIZED状態に変更する。アドレス設定サービスSET-ADDRESSが呼び出され、割当て済みアドレスをフィールドデバイス3032に送信し、フィールドデバイスをシステム管理稼動状態SM-OPERATIONALにする。フィールドデバイスは、割当て済みアドレス3034でライブリストに表示される。プロセス制御システムネットワークデータベースでは、デバイス識別はデバイスに結合される3036。ソフトウェアエンジニアリングツールは、フィールドデバイスをCOMMISSIONEDデバイスとして表示する。図31を参照すると、フローチャートは、第2動作、つまり未結合デバイス3100を作動する動作を記述する使用ケースを示している。未結合デバイスの作動前、フィールドバスインタフェースは稼動中である。フィールドデバイスがプロセス制御システムネットワークデータベースで作成され、物理デバイスタグおよびデバイスアドレスがフィールドデバイスに割り当てられる。ただし、フィールドデバイスはデバイス識別には結合されていない。プロセス制御システムネットワークデータベースも、フィールドデバイスから読み取られるデバイス改訂情報を記憶するために初期化される。ソフトウェアエンジニアリングツールは、フィールドデバイスをUNBOUNDデバイスとして表示する。作動されるUNBOUNDデバイスは、物理デバイスタグが設定されていないフィールドデバイス、あるいはデバイス識別に同一である物理デバイスを有しているフィールドデバイスのどちらかである。UNBOUNDデバイスが作動され、プロセス制御システムネットワークリンクにフィールドデバイスを配置する。UNBOUNDデバイス3100を作動する動作の結果、デバイスが物理デバイスタグおよび割当て済みデバイスアドレスを設定され構成され、デバイスが機能ブロック構成に準備完了している状態が生じる。新規フィールドデバイスは、デバイス識別が結合している状態でプロセス制御システムネットワークデータベースに入れられる。プロセス制御システムネットワークステータスを表示するエンジニアリングソフトウェアツールは、デバイスをCOMMISSIONEDデバイスとして表示する。第1ステップ3102では、フィールドデバイスは、一時アドレスでライブリストに表示される。第2ステップ3104では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを照会し、フィールドデバイスが、物理デバイスタグが設定されていないUNINITIALIZED状態にあるのか、それともデバイス識別に等しい物理デバイスを有しているINITIALIZED状態にあるのかを判断する。それから、インタフェースは、3106にフィールドデバイスのスタンバイアドレスを割り当てる。論理ステップ3108は、過去にUNINITIALIZEDデバイスが、ステップ3110で、物理デバイスタグ設定サービスSET-PD-TAGを使用して、デバイス識別に同一のフィールドデバイスの物理デバイスタグを設定し、それにより、フィールドデバイスをINITIALIZED状態にすることを命令する。スタンバイアドレスが、アドレス設定サービスSET-ADDRESSを使用してフィールドデバイス3112に送信され、フィールドデバイスをINITIALIZED状態からSM-OPERATIONAL状態に進める。この時点で、フィールドデバイスは、スタンバイアドレス3114でライブリストに表示される。デバイス改訂情報は、リソースブロック3116から読み取られる。ステップ3118では、実行中のソフトウェアエンジニアリングツールがフィールドデバイスをSTANDBYデバイスとして表示する。ステップ3120では、ユーザは、フィールドデバイスを事前構成デバイスと関連付けることにより、物理デバイスタグをフィールドデバイスに割り当てる。デバイス改訂情報はフィールドデバイスから読み取られ、情報が、事前構成デバイス用のプロセス制御システムネットワークデータベース内のデバイス改訂情報と一致することを確かめる。デバイスのデバイス改訂情報がデータベースと一致しない場合、ユーザは、データベースを無効にし、デバイス改訂情報をフィールドデバイスから読み取り、情報をプロセス制御システムデータベースに書き込んでよい。代わりに、UNBOUNDデバイスのデバイス改訂情報は、ブランクのままにされ、任意の物理デバイスをUNBOUNDデバイスと結合できるようにする。インタフェースは、アドレスクリアサービスCLEAR-ADDRESSを使用して、フィールドデバイス3122の状態をINITIALIZED状態に変更する。フィールドデバイスは、一時アドレス3124で、ライブリストに表示される。ステップ3126では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用して、フィールドデバイスを照会し、デバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービスSET-PD-TAGを使用し、物理デバイスタグ3128をクリアし、それによってフィールドデバイス状態をUNITIALIZED状態に変更する。それから、物理デバイスタグ設定サービスSET-PD-TAGが使用され、割当て済み物理デバイスタグをフィールドデバイス3130に送信し、フィールドデバイス状態をINITIALIZED状態に変更する。アドレス設定サービスSET-ADDRESSが呼び出され、割当て済みアドレスをフィールドデバイス3132に送信し、フィールドデバイスをシステム管理稼動状態SM-OPERATIONALにする。フィールドデバイスは、割り当てられているアドレス3134でライブリストに表示される。プロセス制御システムネットワークデータベースでは、デバイス識別は、デバイスに結合される3136。ソフトウェアエンジニアリングツールは、フィールドデバイスをCOMMISSIONEDデバイスとして表示する。図32を参照すると、フローチャートは、第3動作、つまりデバイス3200の使用を中止する動作を記述する使用ケースを示している。フィールドデバイスは、複数の理由から使用が中止される。例えば、フィールドバスデバイスが時代遅れであるとき、プロセス制御システムがもはや時代遅れのデバイス上でリソースを使い尽くさないように、ユーザが、機能していない分岐のネットワーク相互接続構造のクリアを希望することがある。また、ユーザが、フィールドバスデバイスが誤動作しており、ネットワーク相互接続構造のセグメントの動作を劣化させていると疑っていることがある。ユーザは、プロセス制御システムに疑われているフィールドバスデバイスを一次的に無視させ、セグメント内の残りのデバイスが適切に動作するかどうかを確認することにより、問題を診断することがある。デバイスの使用を中止する動作の前に、フィールドバスインタフェースおよびフィールドデバイスは稼動中であり、フィールドデバイスは、割当て済みアドレスまたはスタンバイアドレスでライブリストに表示される。ソフトウェアエンジニアリングツールは、フィールドデバイスをCOMMISSIONEDまたはSTANDBYデバイスとして表示する。ソフトウェアエンジニアリングツールは、例えば、機能ブロックタグをクリアし、OPERATIONAL-POWERUPフラグをクリアすることによって、フィールドデバイスを使用中止に備えるルーチンを実行する。デバイスの使用を中止する動作の結果、フィールドデバイスの物理デバイスタグがクリアされ、フィールドデバイスがプロセス制御システムネットワークリンクからの削除に備えている状態が生じる。フィールドデバイスのプロセス制御システムネットワークデータベースエントリは、デバイス識別を、未結合状態にあるとして示す。ソフトウェアエンジニアリングツールは、デバイス識別をUNBOUNDデバイスとして表示し、物理デバイスをOFFLINEデバイスとして表示する。ユーザが、フィールドデバイス3202の使用中止動作を選択すると、デバイス3200の使用を中止する動作が開始する。グラフィックユーザインタフェースは、プロセス制御システム内の適切な制御装置にDecommissionコマンドを発行するソフトウェアエンジニアリングツールを含む。使用中止コマンドは、ターゲットI/Oサブシステム、カードとポートの識別子、および使用中止されるフィールドデバイスのデバイス識別を指定する。同じ物理デバイスタグが設定されている別のデバイスが、UNRECOGNIZED状態で存在することがあるため、デバイス識別が指定される。インタフェースは、アドレスクリアサービスCLEAR-ADDRESSを使用して、フィールドデバイス3204の状態をINITIALIZED状態に変更する。フィールドデバイスは、一時アドレス3206でライブリストに表示される。ステップ3208では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを照会し、物理デバイスタグおよびデバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービスSET-PD-TAGを使用し、物理デバイスタグ3210をクリアし、それによってフィールドデバイス状態をUNITIALIZED状態に変更する。プロセス制御システムネットワークデータベースでは、デバイス識別は未結合であり、ソフトウェアエンジニアリングツールはフィールドデバイスをUNBOUNDデバイス3212として表示する。次のステップ3214では、ソフトウェアエンジニアリングツールは、フィールドデバイスをOFFLINEデバイスとして表示する。ネットワークインタフェースカードは、フィールドデバイスの使用が中止された3216旨の指示を記憶し、ユーザによって命令されない限り、フィールドデバイスをSTANDBY状態に移さない。使用中止されたデバイスがSTANDBYアドレスに移動されない場合、インタフェースカードは、フィールドデバイスがライブリストから離れて進むadvancesoffまで、フィールドデバイスを追跡調査する。図33を参照すると、フローチャートは、第4動作、つまり稼動電源投入3300を使用可能enablementとしないで作動済みデバイスを接続する動作を記述する使用ケースを示している。作動済みでバイアス3300を接続する動作の前、フィールドバスインタフェースは稼動中である。フィールドバスインタフェースの構成は、接続されている状態にあるフィールドデバイスを含む。フィールドデバイスの物理デバイスタグおよびデバイス識別が付き合わされる。作動済みデバイス3300を接続する動作の後、フィールドデバイスには割当て済みアドレスがある。フィールドデバイスは、一時アドレス3302でライブリストに表示される。ステップ3304では、インタフェースが、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを照会し、フィールドバスインタフェース構成の一部としての物理デバイスタグおよびデバイス識別によりフィールドデバイスを認識する。アドレス設定サービスSET-ADDRESSが呼び出され、割当て済みアドレスをフィールドデバイス3306に送信し、フィールドデバイスをシステム管理稼動状態SM-OPERATIONALにする。フィールドデバイスは、割当て済みアドレス3308でライブリストに表示される。図34を参照すると、フローチャートは、第5動作、つまりデバイス3400を置換する動作を記述する使用ケースを示している。デバイスは、可能であるならば、プロセス制御システムネットワークリンクに接続されているカレントフィールドデバイス3402の使用を中止し、UNBOUNDデバイス3404への置換を作動することにより置換される。カレントフィールドデバイス3402の使用を中止するステップは、図32に関して詳細に記述される。UNBOUNDデバイス3404への置換を作動するステップは、図31に関して記述される。図35を参照すると、フローチャートは、第6動作、つまりUNRECOGNIZEDデバイス3500を接続する動作を記述する使用ケースを示している。作動済みデバイス3300を接続する動作の前、フィールドバスインタフェースは稼動中である。現在のプロセス制御システムネットワークリンク用に構成されていない物理デバイスタグおよびデバイス識別を有しているフィールドデバイスが接続される。UNRECOGNIZEDデバイス3500を接続する動作の後、フィールドデバイスは識別され、ソフトウェアエンジニアリングツールはデバイスをUNRECOGNIZEDデバイスとして表示する。UNRECOGNIZEDデバイス3500を接続する動作は、ソフトウェア演じアリングツールを使用しなくても実行してよい。フィールドデバイスは、ライブリスト3502に表示される。ステップ3504では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを照会し、物理デバイスタグおよびデバイス識別が、現在の構成でのフィールドデバイスに一致しないと判断する。図36を参照すると、フローチャートは、第7動作、つまり未認識デバイス3600の使用を中止する動作を記述する使用ケースを示している。未認識デバイスの使用を中止する動作の前、フィールドバスインタフェースは稼動中である。現在のプロセス制御システムネットワークリンク用に構成されていない物理デバイスタグおよびデバイス識別を有しているフィールドデバイスが識別される。ソフトウェアエンジニアリングツールは、UNRECOGNIZEDデバイスとしてフィールドデバイスを表示する。未認識デバイス3600の使用を中止する動作の結果、フィールドデバイスの物理デバイスタグがクリアされ、フィールドデバイスが、プロセス制御システムネットワークリンクからの削除に備えている状態が生じる。ソフトウェアエンジニアリングツールは、フィールドデバイスをOFFLINEデバイスとして表示する。ユーザがフィールドデバイス3602にDecommission動作を選択すると、未認識デバイス3600の使用を中止する動作が開始する。グラフィックユーザインタフェースは、プロセス制御システム内の適切な制御装置にDecommissionコマンドを発行するソフトウェアエンジニアリングツールを含む。使用中止コマンドは、ターゲットI/Oサブシステム、カードとポートの識別子、および使用中止されるフィールドデバイスのデバイス識別を指定する。フィールドデバイスがINITIALIZED状態にある場合、論理ステップ3604は、物理デバイスタグクリアステップ3612に対し、使用中止動作3600を命令する。それ以外の場合、インタフェースは、アドレスクリアサービスCLEAR-ADDRESSを使用して、フィールドデバイス3606の状態をINITIALIZED状態に変更する。フィールドデバイスは、一時アドレス3608でライブリストに表示される。ステップ3610では、インタフェースは、システム管理識別サービスSM-IDENTIFYを使用してフィールドデバイスを照会し、物理デバイスタグおよびデバイス識別によりフィールドデバイスを認識する。インタフェースは、物理デバイスタグ設定サービスSET-PD-TAGを使用し、物理デバイスタグ3612をクリアし、それによって、フィールドデバイス状態をUNINITIALIZED状態に変更する。次のステップ3614では、ソフトウェアエンジニアリングツールが、フィールドデバイスをOFFLINEデバイスとして表示する。ネットワークインタフェースカードは、フィールドデバイスの使用が中止された3616旨の指示を記憶し、ユーザにより命令されない限り、フィールドデバイスデバイスをSTANDBY状態に移さない。使用が中止されたデバイスがSTANDBYアドレスに移動されない場合、インタフェースカードは、フィールドデバイスがライブリストから離れて進むadvancesoffまでフィールドデバイスを追跡調査する。図37を参照すると、フローチャートは、第8動作、つまり使用が中止されたデバイスをスタンバイ状態3700にする動作を記述する使用ケースを示している。使用が中止されたデバイスをスタンバイ状態3700にする動作の前、フィールドバスインタフェースは稼動中である。フィールドデバイスの使用は中止され、OFFLINE状態にある。使用が中止されたデバイスをスタンバイ3700にする動作の結果、フィールドバスが、フィールドデバイスの物理デバイスタグがデバイス識別に同一に設定され、スタンバイアドレスに配置される状態が生じる。ソフトウェアエンジニアリングツールは、フィールドデバイスをSTANDBYデバイスとして表示する。ユーザがフィールドデバイス3702にPlaceinStandbyスタンバイにする動作を選択すると、使用が中止されたデバイスをスタンバイ3700にする動作が開始する。グラフィックユーザインタフェースは、プロセス制御システム3704内で適切な制御装置にPlaceinStandbyコマンドを発行するソフトウェアエンジニアリングツールを含む。使用中止コマンドは、ターゲットI/Oサブシステム、カードとポートの識別子、およびスタンバイにされるフィールドデバイスのデバイス識別を指定する。インタフェースは、フィールドデバイスにスタンバイアドレス3706を割り当てる。それあkら、物理デバイスタグ設定サービスSET-PD-TAGが使用され、デバイス識別3708と同一の物理デバイスタグを設定し、フィールドデバイス状態をINITIALIZED状態に変更する。アドレス設定サービスSET-ADDRESSが呼び出され、スタンバイアドレスをフィールドデバイス3710に送信し、フィールドデバイスをシステム管理稼動状態SM-OPERATIONALにする。フィールドデバイスは、スタンバイアドレス3712でライブリストに表示される。デバイス改訂情報は、リソースブロック3714から読み取られる。ステップ3716では、実行中のソフトウェアエンジニアリングツールが、フィールドデバイスをSTANDBYデバイスとして表示する。ユーザは、それ以降、新規デバイスを作成するか、あるいはフィールドデバイスをプロセス制御システムネットワークデータベース内のUNBOUNDデバイスに結合することによって、フィールドデバイス3718を作動してよい。デバイスを作動する技法は、図30および図31に関して説明される。図38を参照すると、概略ブロック図が、複数の制御言語を使用してプロセス構成を定義するためのプロセス制御構成プログラムのプログラム構造を示している。モジュールエディタ3820は、エンジニアリングワークステーション106などのワークステーション内のCPU116で実行するソフトウェアプログラムである。モジュールエディタ3820を使用して、ユーザは、属性エディタプログラム3830、FunctionBlockEdit/View/Debugプログラム3840、SequentialFunctionChartプログラム3850、LadderLogicプログラム3870、およびStructuredTextプログラム3890を含む、複数の制御言語の1つの言語エディタを起動する。複数の制御言語エディタは、異なる制御言語エディタを使用して、1つの共通した制御戦略が定義されるように、互換性のあるデータベースおよびインタフェースとともに動作する。異なる制御言語エディタのルックアンドフィールは、ユーザが、容易にかつ効率的に異なる目的のためにさまざまなエディタを使用し、言語のさまざまな態様を最大限に活用できるように類似している。モジュールエディタ3820は、構成エントリ用の根本的なルーチンであり、SP88規格により定義されている制御モジュールインスタンスおよび装置モジュールインスタンス、およびライブラリモジュールを作成、編集、および再利用するために使用される。モジュールエディタ3820は、制御戦略を形成する複数のモジュールを構成、視覚化、およびナビゲーションするためのグラフィック技法を供給する。モジュールエディタ3820は、モジュールリンクおよびモジュール包含containmentを定義するためにも使用される。モジュールエディタ3820は、警報、イベント、履歴、状態、ヘルプ、構成要素および属性に関する情報収集だけではなく、アルゴリズム定義に対するサポートを含むモジュールの構成のすべての側面へのアクセスを供給する。モジュールエディタ3820は、制御システムを通してナビゲーションを容易にする多様な機能を含む。例えば、モジュールエディタ3820は、ユーザ定義キーワードに関する属性をフィルタリングし、焦点が定められた属性構成ビューを供給する。さらに、モジュールエディタ3820は、デフォルトで、モジュールに対する変更によって影響を受けるすべてのデバイスへのインストールを実行する高速インストール機能を含む。制御戦略は、インストールスクリプトを使用して、エディタから実行時エンジンの中に転送される。複数の制御言語実行エンジンが、1つまたは複数の制御装置/マルチプレクサ110で制御戦略を実行する。オフライン構成は、既存のモジュールの制御戦略に対する進行中の作業workinprogressをサポートする。新規戦略が完了すると、それは既存のモジュールにインストールできる。この進行中の作業は、そのインストールを許可しないためにフラグを立てることができる。属性エディタプログラム3830は、機能ブロック、はしご、複合物等を含む、制御モジュールまたは制御アルゴリズムの要素に関連付けられているパラメータ値を表示し、編集するために、ユーザによって操作される制御プログラムである。属性エディタプログラム3830は、オンラインで使用され、制御モジュールを構成する。オンラインでは、属性エディタプログラム3830は、データを表示し、編集するためにし様去れウ。属性は、モジュールレベルアクセスをモジュール内に包含されているパラメータに与えるように定義される。属性エディタプログラム3830は、モジュールエディタ3820およびそれ以外の制御言語エディタによって起動される。属性エディタプログラム3830は、グラフィックナビゲーションツリー経路ディスプレイを使用して、簡略属性構成ビューを提示し、モジュールのために構成されるパラメータを整理統合するconsolidate。ユーザは、属性エディタプログラム3830を起動し、グラフィックナビゲーションツリーを通してナビゲーションし、ある特定の属性を発見する。属性が選択されると、属性は、ディスプレイが喚起されるコンテキストに応じて、アプリケーションウィンドウを使用して、あるいはダイアログとして表示される。属性エディタプログラム3830は、ドラッグアンドドロップ技法を使用して、属性のコピー、貼り付け、およびバルクbulk変更をサポートすることにより構成を容易にする。属性を包含しているモジュールがインストールされると、属性がインストールされるため、属性エディタプログラム3830は、属性パラメータ値を定義するためは使用されうが、属性をインストールするためには使用されない。属性パラメータ値は、ユーザにより入力されるに従って、属性エディタプログラム3830がエラーチェックを実行する。属性エディタプログラム3830によって、ユーザは、列の数の拡大と削減を含む典型的なスプレッドシート機能をもって、あるいは包含によってデータを並べ替え、表示できるようになる。FunctionBlockEdit/View/Debugプログラム3840は、フィールドバス財団FieldbusFoundationおよびIEC1131-3規格の元で指定されている機能ブロック要素をアセンブルすることにより制御戦略を定義するためにユーザにより操作される制御プログラムである。機能ブロックプログラム3840は、制御装置/マルチプレクサ110内で動作する機能ブロック実行エンジン内で実現される。機能ブロック実行エンジンは、FunctionBlockLibrary3842を使用して機能ブロック制御アルゴリズムを実行する。機能ブロックプログラム3840は、FunctionBlockLibrary3802内に記憶されている機能ブロック、およびそれ以外の定義済み制御モジュール、例えば他のアプリケーションプログラムによる使用のために定義されている制御モジュールを使用して、制御戦略を作成、編集および再利用すsるためのグラフィックエディタを供給する。作成される制御戦略は、それ以降の使用、または別のアプリケーションプログラムによる使用のために、再利用可能ライブラリ構成要素としてFunctionBlockLibrary3802内に保存される。機能ブロックプログラム3840は、HARTおよびFFタイミングフィールドデバイス用の制御構造も作成、編集、および再利用する。制御戦略の機能ブロックおよびモジュール構成要素は、ある特定のデバイスに限られるのではなく、HARTおよびFFタイミングフィールドデバイスを含む、複数の制御デバイス全体でむしろ区切られている。機能ブロックまたはモジュールは、機能ブロックプログラム3840を使用して修正される属性を含む。システム内の属性は、機密保護されていない限り、その属性のためのナビゲーションツリー経路を通してアクセスされ、機能ブロックエディタから書き出される。機能ブロックエディタプログラム3840は、モジュールおよび再利用可能なライブラリ構成要素の制御戦略のために、オフライン作成およびデバッグ機能をサポートする。オフライン動作中、制御装置はネットワークに接続されていない。オフライン動作中、複数の制御戦略が開かれ、構成が戦略間でコピーされ、貼り付けられることがあるため、オフライン動作は、制御装置が、機能ブロックエディタプログラム3840の属性エディタ3842を使用して接続される前に、属性およびパラメータを初期化するのに有効である。機能ブロックエディタプログラム3840は、ブロック入力値および出力値の表示を含む、動作中の機能ブロックのオンライングラフィック編集、表示およびデバッグもサポートする。選択式オンライン編集およびデバッグモードオプションは、例えば、単一ステップ、強制入力、およびブレークポイントオプションを含む。ユーザが適所にある矛盾しているパラメータ値を訂正できるように、オンライン編集およびデバッグには1つのウィンドウが使用される。オンライン編集中の入力値は、オフライン編集値との一貫性があるかチェックされ、矛盾する場合には却下される。機能ブロックエディタプログラム3840により作成されるハードコピー出力情報は、ブロック属性およびパラメータ値のようなグラフィック表記および構成情報を含む。機能ブロックプログラム3840の複数の機能は、再利用可能ライブラリ構成要素、ユーザ返還サポート、および入力エラーチェックを含む、ユーザサポートを容易にする。ステップ動作内でのユーザ変換サポートは、ユーザが、応答が設定されるポップアップダイアログを構成できるようにする。再利用可能ライブラリ構成要素は、単一機能ブロック図FBDが、実行中に、複数のモジュールまたはFBDに対するサブルーチンとして動作するように、構成および実行の間のエンジニアリングを簡略化するために開発される。SequentialFunctionChartSFCEdit/View/Debugプログラム3850は、IEC1131-3規格の元で指定されているステップ、ステップ動作、および遷移をアセンブルすることにより制御戦略を定義するために、ユーザにより操作される制御プログラムである。順次機能チャートプログラム3850は、制御装置/マルチプレクサ110内で動作する、SFC実行エンジン内で実現される。SFC実行エンジンは、ステップ、動作、および遷移を含む、順次機能チャート制御アルゴリズムを実行する。順次機能チャートプログラム3850は、順次機能チャートを使用して制御戦略を作成、編集および再利用するためのグラフィックエディタを供給する。順次機能チャートプログラム3850は、並行論理経路の実行をサポートする。順次機能チャートの実行は、少なくともSFC実行の期間中、1つのモジュールと関連付けられている。順次機能チャートは、順次機能チャートプログラム3850を使用して修正される属性を含む。システム内の属性は、機密保護されていない限り、順次機能チャート実行でのステップからアクセスされる。順次機能チャートプログラム3850は、モジュールの制御戦略のためにオフライン作成デバッグ機能をサポートする。オフライン動作中、制御装置は、ネットワークに接続されていない。オフライン動作中、複数の制御戦略が開かれ、構成が戦略間でコピーされ、貼り付けられることがあるため、オフライン動作は、制御装置が、順次機能チャートプログラム3850の属性エディタ3842を使用して接続される前に、属性およびパラメータを初期化するのに有効である。順次機能チャートエディタプログラム3850は、属性値ライブ表示を含む、動作中のャートのオンライングラフィック編集、表示およびデバッグもサポートする。選択式オンライン編集およびデバッグモードオプションは、例えば、単一ステップ、強制入力、およびブレークポイントオプションを含む。オンライン編集は、戦略で変更が行われている間に、制御戦略を実行するためのブレークポイントの設定を含む。ユーザが適所にある矛盾するパラメータ値を訂正できるように、1つのウィンドウがオンライン編集およびデバッグに使用される。オンライン編集中の入力値は、オフライン編集値との一貫性があるかチェックされ、矛盾している場合には却下される。順次機能チャートプログラム3850は、ステップ、動作、現在実行中のトランザクションおよび属性値の表示を含む実行時ビューをサポートする。順次機能チャートプログラム3850により作成されるハードコピー出力情報は、グラフィック表記およびステップ動作などの構成情報を含む。順次機能チャートプログラム3850複数の特徴は、再利用可能ライブラリ構成要素、ユーザ変換サポート、および入力エラーチェックを含むユーザサポートを容易にする。ステップ動作内でのユーザ変換サポートにより、ユーザは応答のあるポップアップダイアログを構成できる。再利用可能ライブラリ構成要素は、単一のSequentialFunctionChartSFCが、実行中、複数のモジュールまたはSFC用のサブルーチンとして動作するように、構成および実行中のエンジニアリングを簡略化するために開発される。LadderLogicプログラム3870は、はしご形論理図で、組み合わされるはしご形要素および機能ブロックを使用して制御戦略を定義するためにユーザにより操作される制御プログラムである。はしご形論理プログラム3870は、制御装置/マルチプレクサ110内で動作するLadderLogicエンジン内に実現される。はしご形論理エンジンは、コイル、接触子、および複数の標準機能ブロックを含むはしご形制御アルゴリズムを実行する。LadderLogicプログラム3870は、基本離散制御動作を解決するための構成要素を含む基本離散制御はしご形論理ライブラリ3872を含む。これらの動作は、はしごの横木ごとに1つの接続が定義されている、コイル、接触子、タイマ、フリップ/フロップ、エッジトリガ、およびカウンタなどの要素を含む、IEC1131-3規格の論理拡張部である。LadderLogicプログラム3870は、はしご形論理図内でのユーザ定義ブロックの配置もサポートする。はしご形論理図は、電力がはしご内の横木を通して流れているかどうかにより実行の状態が決定される電力フローをサポートする機能ブロックに適用できる。電力フローは、論理図でのデータフローにいくぶん類似している。適用可能な機能ブロックだけが、はしご形論理パレット上にLadderLogicプログラム3870により表示される。LadderLogicプログラム3870は、制御戦略を構成、デバッグするためにユーザにより独占的に使用されるか、あるいは論理図用紙が別のはしご形論理図用紙、機能ブロック図用紙、または順次機能チャート用紙内での複合物として使用されることがある。はしご形論理用紙は、複合はしご形論理図、機能ブロック図、または順次機能チャート用紙を含むことがある。はしご形論理要素は、他の用紙および他のモジュールで属性を読み書きできる。はしご形論理図は、オンラインとオフライン両方の編集をサポートする。ユーザは、特定のはしご形論理図でデバッグ機能性から編集モードに切り替え、制御戦略に構造上の変更を加えることができる。ユーザは、デバッグビューまたは編集ビューのどちらかからパラメータを変更してよい。LadderLogicプログラム3870は、電力フロー、パラメータ値、および通電状態または電力供給が止められている状態のディスプレイを含むデバッグ機能性を含む。はしご形論理デバッグ機能性とは、実質的には、ユーザが入力値を強制し、ブレークポイント等を設定するSeqentialFunctionChartエディタプログラム3850のデバッグ機能性と同じである。LadderLogicプログラム3870は、はしご形論理シミュレーション、履歴データ収集とモード、警報およびステータスレポート生成をサポートする。図39Aを参照すると、機能ブロックエディタ3840を使用して構成プログラムにより作成される構成画面3900の画面提示が描かれている。構成画面3900は、ナビゲーション部分3902および画面特殊部分3904を含む。ナビゲーション部分3902は、ユーザが構成プログラムの特定のセクションにアクセスできるようにするナビゲーションテーブル3910を含む。構成画面3900の実例となる状態では、構成プログラムは、構成コマンドのユーザエントリを待機している。ナビゲーションタブ3910は、簡略セット優勢dominantSRフリップフロップを選択するためのナビゲーションタブ3912、簡略減算ブロックを選択するためのナビゲーションタブ3914、簡略時間付きパルスブロックを選択するためのナビゲーションタブ3916、簡略転送ブロックを選択するためのナビゲーションタブ3918、および簡略排他的論理和XORブロックを選択するためのナビゲーションタブ3920を含む機能ブロックの中へのエントリ用の複数のプリミティブ機能を示す。ナビゲーションタブ3910は、機能ブロックを挿入するためのブロックアシスタント3922タブも含む。画面特殊部分3904は、属性の構成および他の機能ブロックとの接続を含む、構成される機能ブロック3924を示している。ブロックアシスタント3922タブは、機能ブロックを挿入するために選択される。図39Bを参照すると、Selection画面3930が、機能ブロック挿入の選択に応えて表示されている。選択画面3930は、選択部分3932および画面特殊部分3934も含む。画面特殊部分3934は、作成される新規ブロックの名称を入力するためのエントリブロック3936を含む。選択部分3932は、機能ブロック3940タブ、埋め込みブロック3942タブ、リンク済み複合3944タブ、およびモジュールブロック3946タブを含む複数の選択タブ3938を含む。選択タブ3932は、Backボタン3948、Nextボタン3950、およびCancelボタン3952を含む、ナビゲーション機能を供給する多岐に渡るボタンも含む。Backボタン3948により、ユーザは、厳密な履歴順での過去の画面表示に移動する。Nextボタン3950により、ユーザは、現在の画面提示で行われる選択に適切な画面提示に移動する。取消しボタン3952は選択を終了する。埋め込みブロック3942タブは、埋め込みブロックを挿入するために選択される。図39Cを参照すると、Choice画面3960が喚起され、ユーザが埋め込みブロック、選択3962を使用している機能ブロックエディタ、または選択3964を使用している順次機能チャートエディタのどちらかを構成するための制御言語エディタを選択できるようにする。選択3964は、順次機能チャートエディタを活用するために選ばれる。図39Dを参照すると、機能ブロック3924が機能エディタ3840を使用して構成され、新規に作成されるブロック3972が順次機能チャートエディタ3850を使用して構成される、構成画面3970の画面提示が示されている。新規に作成されるブロック3972の編集は、順次機能チャートエディタ3850が呼び出されるように選択される。図39Eを参照すると、新規に作成されたブロック3972の詳細が、属性3982およびステップ3984を含め、構成画面3980の画面特殊部分3934に示されている。構成画面3970のナビゲーション部分3986は、機能ブロックに関係するナビゲーションタブを一覧表示しているのではなく、むしろステップ3990、遷移3992、終了3994、および順次機能のステップおよび遷移を定義するための入力端末3996と出力端末3998に関係するナビゲーションタブ3988を含む。図40を参照すると、オブジェクトも出るが、警報およびイベント機能を取り扱うための多様なオブジェクトのオブジェクト関係を示している。多様な状態は、Alarms、Alarm肯定応答、ユーザ変更属性書込み、方法呼出し、ログイン/アウト、実行時システムに対する構成変更インストール、インストール解除de-installs等、SequentialFunctionChartSFC状態変更、オペレータ注意要求OAR,およびその他のEvents装置状態変化を含む非警報状態遷移を含むイベントであるように定義される。すべての種類のイベントにとって1つの共通した特徴は、イベントの発生または状態遷移が、EventJournal内に記録できるという点である。すべてのイベントは、1つまたは複数のプラント領域と関連付けられている。イベント発生記録RtEventOccurenceRecord4040は、関連付けられているプラント領域RtPlantArea4010のために指定されているEventJournal、JournalsRtEventJournal4020に捕捉される。ユーザは、起動されているEventJournalがイベントを捕捉する1つまたは複数のPlantAreasを構成することにより、典型的にはワークステーションを使用してEventJournalを起動する。EventoJournalのオンライン動作は、記録されるイベントの指定されるクラスをディスエーブルまたはイネーブルすることにより、ユーザ制御下で修正される。ユーザは、ControlModulesまたはEquipmentModulesRtModule4030内でAlarmAttributesRtAttribute4032を作成することによりAlarm動作を構成する。AlarmAttributeは、Attributeを包含している、ControlModuleまたはEquipmentModule内の任意のブールAttributeに対する参照を与える。AlarmAttributesは、Moduleレベルだけで作成される。AlarmAttributesは、CompositeFunctionBlocksでは作成されない。図41を参照すると、状態遷移図が、警報属性状態を示している。ユーザは、AlarmAttributeをディスエーブルするか、イネーブルする。ディスエーブル4110されると、AlarmAttributeは、InactiveおよびAcknowledged状態と呼ばれる正常な状態で表示される。AlarmAttributeのDisabled/Enabled状態は、Operatorによりオンラインで、あるいはシステム内の制御アルゴリズムによって自動的に変更される。初期のDisabled/Enabled状態は、構成時に設定される。イネーブルされているAlarmAttributeは、Actived状態4116または4118、あるいはInactive状態4112または4114のどちらかを有している。参照されているブールAttributeがTRUEであるとき、AlarmはActive警報中である。AlarmAttributeは、オプションで、警報状態の意味を反転させるように構成されるため、.INV特性TRUEが設定されるAlarmAttributeは、あたかも参照されるAttributeのFALSE値が警報中状態を示すように動作する。Acgtive/Inactive状態は、Active/Inactive状態が、Operatorまたは別の制御アルゴリズムによって直接へ項されないように、参照されているAttributeの状態により駆動される。Enabled中、AlarmAttributeは、Acknowledged4112または4116、あるいはUnacknowledged状態4114または4118のどちらかを有している。AlarmAttributeは、自動的に肯定応答されない限り、AlarmAttributeがInactiveからActive状態に遷移を行う場合にだけUnacknowledged状態にされる。Operatorまたは別の制御アルゴリズムが、Alarmを肯定応答し、AlarmAttribugteをAcknowledged状態に変更することがある。AlarmAttributeは、自動的に肯定応答されるかAACK‘dまたは自動的ではなく肯定応答される。AACKは、現在のAlarmの優先順位から決定される。ユーザにより構成されているシステム全体のテーブルがAACK動作を決定する。例えば、テーブルは、すべてのLOW優先順位のAlarmsが自動的に肯定応答されAACKがTRUEである、すべてのMEDIUMおよびHIGH優先順位のAlarmsが自動的に肯定応答されないAACKがFALSEであると指定することがある。AACKがTRUEであるとき、警報は絶対にUnacknowledged状態にされない。Enable/Disabled、Active/Inactive、およびAcknowledged/Unacknowledge状態の組み合わされた動作の結果、図41に示されているAlarmAttributeのユーザ可視状態が生じる。イネーブルされているAlarmAttributeは、当初、Inactive/AckdState4112に移行し、ただちにActive/Unackd4114またはActive/Ackd4116のどちらかに遷移する可能性がある。Acive/Ackd4116への遷移には、例えば、遷移にタイムスタンプが押され、イベントがイベントジャーナルに記録される、Alarmの標準遷移動作が伴われる。AlarmAttributeは、ユーザ可視インタフェースを提供する複数のフィールドを有している。CUALMカレント警報フィールドは、AlarmAttributeがDisabled状態4110、Inactive/Ackd状態4112またはInactive/Unackd状態4114にあるときにOKである。それ以外の場合、CUALMは、構成されているAlarmTypeに関連付けられているワード/値である。DESC記述フィールドは、AlarmAttributeが状態を変化するときに作成される警報記述を有している。DESCフィールドは、空の文字列に初期化される。LAALMラッチ済み警報フィールドは、AlarmAttributeがDisabled状態4110またはInactive/Ackd状態4112にあるときにOKである。それ以外の場合、LAALMフィールドは、構成されているAlarmTypeに関連付けられているワード/値である。LAALMフィールドは、ラッチされいてる警報起動を提示し、Activeである期間中が非常に短い場合にもAcknowledgementをイネーブルする。NALM未肯定応答警報フィールドは、AlarmAttributeのAcknowledged/Unacknowledged状態を示す。NALMフィールドは、警報要約エントリを削除できるときを突き止めるために使用される。ENAB警報イネーブル済みフィールドは、AlarmAttributeの現在のEnabled状態を示す。IENAB警報初期イネーブル済みフィールドは、AlarmAttributeの構成済みEnabled状態を示す。INV反転入力フィールドは、関連付けられているブールAttributeが警報処理の前に反転されるかどうかを示す。INV構成可能特性は、AlarmAttribute基準、通常は、離散入力を保持しているAttributeなどのTRUEブールAttributeを許す。PRI警報優先順位フィールドは、AlarmAttributeの現在の優先順位High/Medium/Lowを示す。テーブルIIは、ブールAttributeを以下のように示す。プロセス制御システム100は、多くの潜在的なActiveAlarm状態を[最高勇背順位]警報の1つの短いリストの中に整理統合する。選択基準は、整理統合のために最高の優先順位の警報を選択するために使用される。選択基準は、優先順位が下がっている順序での分析、Unacknowledged状態がAcknowledged状態より優先されているAcknowledged状態、HighそれからMediumそれからLawの優先順位の順序でのAlarmPriority、および最新タイムスタンプが優先順位を獲得しているDetectionのTimeを含む。AlarmConsolidationは、SP88ModuleレベルおよびPlantAreaレベルで使用できる。警報整理統合は、SP88MODULEControlおよびEquipmentPlantAreasで使用できる既定義されている属性名ALARMを介してアクセスされる。ALARMSとは、インデックス付きAttributeであり、指数は、整理統合でのN番目に高い優先順位警報例えば、ALARMS[1]は最高の優先順位Alarmにアクセスし、ALARM[2]は2番目に高い優先順位のAlarmにアクセスする等を選択する。したがって、例えば、AREA1/FIC101/ALARMS[1]は、ModuleFIC101の最高優先順位のAlarmを参照し、AREA1/ALARM[2]は、PlantAreaのAREA1での2番目に高い優先順位Alarmを参照する。ALARMSAttributesでサポートされている最大指数は5である。ALARMS[N]AtributeでサポートされているFieldsは、N番目の優先順位のAlarmAttributeのActiveOrUnacknowledged状態を示すLAALMラッチ済み警報フィールドを含む。LAALMFieldは、ACTIVE/UNACKD、ACTIVE/ACKD、またはINACTIVE/UNACKD状態の間のN番目の優先順位のAlarmAttributeの警報ワード、つまり警報型値内にある。NALM未肯定応答警報フィールドは、N番目の優先順位のAcknoeldged/Unacknowledged状態を示す。PRI警報優先順位フィールドは、N番目の優先順位のAlarmAttributeの構成済み優先順位High/Medium/Lowを示す。TAG警報Tagフィールドは、N番目のAlarmAttributeに対するFieldを除く完全に修飾されているAttribute基準文字列を返す。MODULE警報Moduleフィールドは、N番目の優先順位Alarmを有しているSP88MODULEを示す。MODULEタグは、そのModuleの一次制御ディスプレイ属性にアクセスするために使用できるModule基準文字列を戻す。いくつかのFieldsが、SP88ModuleレベルだけでのALARMSAttribute上でサポートされている。指数値がこれらのフィールドに適用されると、指数値は無視される。SP88ModuleレベルALARMSAttributeフィールドは、Moduleの現在のAlarmEnabled状態を示すENAB警報イネーブル済みフィールドを含む。PRIAD優先順位調整フィールドは、Alarmの有効Priorityを求めるときにModule内の各AlarmAttributeの現在のPriorityに追加される数通常は0である。PRIADModule全体での調整は、Module内の全警報のAlarmPrioirtiesを下げ、Alarm可視性の減少を可能にするために使用される。テーブルIIIは、以下のように、詳細にALARMS属性を説明する。User-LevelAlarmConsolidationは、グラフィックユーザインタフェースでAlarmBannerを使用して達成される。警報整理統合は、カレントユーザに対しサポートされる。各ユーザは、1つまたは複数のPlantAreaでの権限を許可されている。カレントユーザ警報整理統合は、現在、ユーザの制御スパン内にあるPlantAreasの最高優先順位の警報を提示する能力を提供する。THISUSERと呼ばれている、ALAFRMS[N]Attributeをサポートする既定義属性コンテナが存在する。ユーザは、オプションで、THISUSER/ALARMSN.フィールドを参照するディスプレイを構築し、カレントユーザに対する最高優先順位警報へのクイックアクセスを可能にする。警報特権が許可されている場合、ユーザは、AlarmsをEnablesし、Disableする。警報特権を使用し、ユーザは、.ENABフィールドに書き込むことによって単一のAlarmAttributeをEnableまたはDisableしてよい例えば、AREA1/FIC101/HIALM.ENABにTRUEを書き込む。プロセス制御システムの各AlarmAttributeは、単一Enable/Disable状態を含む。一人のユーザが状態を変更すると、Alarmsはすべてのユーザに対しEnabled/Disabledされる。警報特権を使用し、ユーザは、ALARMSAttributeのENABフィールドに書き込むことによって、SP88ModuleAlarm内のすべての警報をEnableまたはDisableしてよい例えば、AREA1/FIC101/ALARMS.ENABにTRUEを書き込む。AlarmsをModulerベルでDisablingすると、個々のAlarmのENAB状態を無効とするが、それに上書きしない。AlarmsがModuleレベルでEnabledされると、個々のAlarmnoENAB状態により決定されるAlarm処理が復元される。システム中の各SP88Moduleは、単一Enable/Disable状態を含む。一人のユーザが状態を変化すると、そのModule内のすべてのAlarmsは、すべてのユーザに対してEnabled/Disabledされる。動作特権を有しているユーザは、AlarmsをAcknowledgeできる。動作権限を使用し、ユーザは、FALSEを.NALMフィールドに書き込むことによって単一AlarmAttributeをAcknowledgeする例えば、AREA1/FIC101/HIALM.NALMにFALSEを書き込む。.NALMにTRUEを書き込もうとする試みは無視される。プロセス制御システム中の各AlarmAttributeは、単一のAcknowledge状態を有している。一人のユーザが状態を変更すると、Alarmはすべてのユーザに対しAcknowledgedされる。動作特権を使用し、ユーザは、Module内のすべてのAlarmAttributesの.NALMフィールドにFALSEを書き込むのと実質的には同じ効果を出す動作である、ALARMSAttriuteの.NALMフィールドにFALSEを書き込むことによってSPModuleAlarm内のすべての警報をAcknowledgeしてよい例えば、AREA1/FIC十1/ALARMS.NALMにFALSEを書き込む。.NALMにTRUEを書き込もうとする試みは無視される。警報特権を有しているユーザは、警報優先順位を変更することができる。警報特権を使用し、ユーザは、.PRIフィールドに書き込むことによって単一AlarmAttribute上のPRIを変更してよい例えば、AreA1/FC101/HIALMPRIに0を書き込み、それをHIGH優先順位警報にする。AutoAcknowledgement動作は、AlarmPriorityにより決定されるので、AlarmPrioirtyを変更すると、Alarmに肯定応答ステータスを変更させる可能性がある。例えば、AutoAckFALSEが設定されている優先順位から、AutoAckTRUEが設定されている優先順位に変更すると、未応答確認警報が肯定応答されるはずである。また、AutoAckTRUEが設定されている優先順位から、AutoAckFALSEが設定されている優先順位に変更すると、肯定応答済み警報が未応答確認になるはずである。システム中の各AlarmAttributeは、単一.PRI状態を有している。一人のユーザが状態を変更すると、.PRIはすべてのユーザに対して変更される。警報特権を使用し、ユーザは、ALARMSAttributeの.PRIADフィールドに書き込むことによって、SP88ModuleAlarm内のすべての警報の有効優先順位を調整してよい。例えば、AREA1/FIC101/ALARMS.PRIADに1を書き込むユーザは、現在のAlarmPriority値を増加し、それによってHIGH優先順位がMEDIUM優先順位になり、LOW優先順位がLOGになるように1つの段stepづつ動作を削減する。ユーザは、PRIADを正の数に設定するだけなので、通常の予告動作を減少するためにだけ使用される。PRIADを0に設定すると、AlarmAttributeごとに求められる通常の優先順位が再確立される。有効警報優先順位は、LOG下では調整されない。AutoAcknowledgement動作はAlarmPolicyにより決定されるので、ModuleレベルでPRIADを変更すると、個々のAlarmが肯定応答ステータスを変更する可能性がある。システム中の各SP88Moduleは、単一.PRIAD値を有している。一人のユーザが状態を変更すると、すべてのユーザに対して、そのModule内のすべてのAlarmsが影響を受ける。警報は、標準FIXTM警報要約の元でのディスプレイを使用して表示される。マサチューセッツ州、ノーウッドNorwood、MAのインテルーションIntellutionによって販売されているFIXTMク ゙ラフィックディスプレイプログラムは、コンピューティング技術ではよく知られている。FIXTM警報要約リンクは、ActiveAlarmのフィルタ済みの、並べ替えられているリストを表示するための主要な方法である。警報要約リンクのすべての機能は、以下の例外または拡張部分はあるが、サポートされている。第1に、タグ名欄は、Field名を除く、AlarmAttribute例えば、AREA/FIC101/HIALRMのプロセス制御システムAttribute基準経路を示している。第2に、説明には、Alarmが最初に検出された時点で、Alarmが最高2つのAttributesの値を捕捉するように、ALarmが検出される時点で構築されるユーザ構成文字列が記載されている。複数のAlarmが、警報要約の各SP88Moduleごとに表示出切る様に、Tagあたり1つのAlarmdakega可能である。第3に、最終時刻項目には、肯定応答の時刻、または未応答確認警報のActive/Inactive間の最後の遷移の時間である場合がある、ActiveAlarmの最後の状態遷移の時間が記載されている。第4に、AlarmのFIXSCADANodeソースを示すノード欄項目は、Areaことに、FilterおよびSort機能が失われるように、プロセス制御システムAlarmsには無意味である。第5に、すべてのAlarmsは、AlarmTypeに基づき前景色を達成するためにFIXAlarm型の内の1つにマッピングされる。ユーザは、AlarmStateTransitionJournalingレコードにアクセスできる。警報状態遷移は、PlantAreaに割り当てられているEventJournalに記録される。Inactive/Unackd4114とActive/Unackd状態4118の間の遷移を含む、図41に示されているすべての警報状態遷移がEventJournalに記録される。したがって、LAALMフィールドをディスプレイまたは警報要約で表示しているオペレータは、未肯定応答警報間の遷移を確かめず、これらの遷移はEventJournalに記録される。警報遷移のイベントジャーナルエントリは、以下を含む。1警報状態を検出するデバイス例えば、制御装置により判断される警報状態遷移のタイムスタンプ、2他のイベントジャーナルエントリから区別する警報イベント型、3ユーザ定義警報カテゴリ、4現在の警報優先順位、5システムAlarmTypeテーブルで構成される警報ワード文字列、7警告されている属性の属性基準文字列または経路、および8構成済みの2つまでのAttributes値が文字列に挿入される、AlarmTypeテーブルで構成されている記述文字列からアセンブルされる記述文字列。イベントジャーナルブラウザアプリケーションは、一般的には、タイムスタンプにより並べ替えられ、イベントタイプ=ALARMおよび属性基準文字列=FC101/PID1/HIALMでフィルタリングされる、テーブルIVに示されるようにデータを提示する。オペレータ変更は、対応する警報状態の変更を引き起こすが、EventJournalでの警報状態遷移イベントは、オペレータ変更ジャーナルエントリとは別個である。例えば、以下の通りであるテーブルVに示されるようである。AlarmAttributesが構成され、それによりAlarm動作および提示を設定し、説明されている動作のシーケンスを使用する。第1に、警報型テーブルおよび警報予告テーブルが構成される。第2に、オプションステップで、ユーザ定義警報状態が構成され、ブール属性を設定する。第3に、AlarmAttributesは、ブールAttributesを参照するために作成され、それによりSystemAlarmType、優先順位等を識別する。第4に、Moduleインスタンスは、Alarmsを包含するModuleDefinitionsに基づき作成される。第5に、Alarm情報の提示は、データベースリンク、ダイナミックカラーリンク、およびAlarmSummaryリンクを介してディスプレイ絵の中に挿入される。第6に、AlarmTyesおよび警報予告テーブルが構成される。警報型テーブルには、1AlarmごとのAlarm構成プロセスを加速するために1つの共通したAlarm提示動作を定義する、システムサイト全体で共通したリソースとして動作すること、2SummariesおよびHistoryJournalsでの標準警報メッセージ通信を奨励し、その情報の問い合わせおよび分析を改善すること、3警報をFIXAlarmStatesにマッピングすることを含む複数の機能がある。警報型テーブルには、警報タイプ、警報ワード、カテゴリ、および記述文字列欄を含む欄がある。警報型欄には、AlarmAttributeを作成するときに適切なTypeを選択するために使用される警報型の簡略な記述が記載される。警報ワード欄には、AlarmがActiveであるときにA_CUALMまたはA_LAALMFieldを読み取るときに返される文字列を含む。カテゴリ欄には、問い合わせのフィルタリング/並べ替えを補助するために使用される、EventJournalに記録されているユーザ定義ワードを記述する。記述文字列は、警報要約リンクに表示され、AlarmDetection時でのAttribute値置換のために最高2つの位置設定記号を包含する。警報型テーブルデフォルト内容は、以下に示すようにテーブルVIに示されいてる。標準警報は、FIXTMでサポートされている警報型に一致する。警報予告テーブルとは、AlarmごとのAlarm構成プロセスを加速するためにAlarm予告動作の1つの共通して定義を供給するシステムサイト全体での共通したリソースである。警報型テーブルには、警報優先順位、自動肯定応答、WAVファイルおよびPCスピーカ周波数欄を含む欄がある。警報優先順位は、Alarm優先順位ワードHIGH/MEDIUM/LOW/LOGを指定する。AutoAcknowledgement欄には、この優先順位の警報が、検出時に自動的に肯定応答される必要があるのかを示し、重要度が低い警報をより注意をそらすdistractingとする機械を提供するYES/NO値が記載される。WAVファイルには、サウンドカード付きWorkstationでカレントユーザの範囲内でAlarmが検出されるときに再生されるループ計算NT互換の.WAVファイルのファイル名が指定される。このファイル名の省略は、この優先順位が設定される警報には.WAVファイルが再生される必要が内ことを示す。PCスピーカ周波数は、サウンドカードが付かないWorkstationで、カレントユーザの範囲内で、Alarmが検出されるときにPCスピーカでトーンを再生するために使用される値を設定する。0という値は、PCスピーカをこの優先順位が設定される警報に使用してはならないことを示す。.WAVファイルおよび0以外のスピーカ周波数が同じ警報優先順位に指定される場合、PCスピーカは、サウンドカードが存在する場合にだけ使用される。警報予告テーブルデフォルト内容は、以下に示すようにテーブルVIIに示されいてる。ユーザは、同じModule内の別のブールAttributeを参照するSP88MODULEDEFINITIONに従って、AlarmAttributesをAlarm動作をブールAttributesに付与する。ユーザは、以下を入力することによりAlarmAttributeを作成する。1例えば、経路による、またはドラッグアンドドロップによるターゲットAttribute、2警報状態を定義するブールAttribute、3システム全体でのAlarmTypesリストから選択されるAlarmType、4AlarmPriorityHigh/Medium/Low/Log、5初期AlarmEnable状態イエス/ノー、6InvertInputイエス/ノー、7P1の代わりに使用される値を有しているAttributeのオプションのName、8P2の代わりに使用される値を有しているAttributeのオプションのNameアイテム7と8のAttributeの名称は、同じSP88MODULE内のAttributesに制限され、モジュール相対属性基準として指定される例えば、FIC101/SPやFIC101/PID1/PVよりむしろSPおよび[PID1/PV]。ユーザは、Alarmを記載するモジュール定義に基づいてModuleインスタンスも作成する。Moduleインスタンスが作成されると、モジュール定義に指定されているすべてのAlarm動作はModuleインスタンスに適用する。.PRIフィールドおよび.ENABフィールドは、Moduleインスタンスが作成されるとAlarmdAttributesで無効にされることがある。例えば、HIGHLIMITEDという名前が付けられているAlarmAttributeに対し、モジュール定義が構築されるとき、それからModuleインスタンスが作成されるときに.PRIがMEDIUMである場合、HIGHLIMITED.PRIはこのインスタンスに対しLOWであるために無効とされることがある。警報は、ControllersでのDevice/SubsystemAttributesに関しサポートされている。属性は、制御システムの動作および他のシステムへの接続についての情報へのアクセスを提供するためにデバイスおよびデバイスサブシステムに対し定義される。Attributesには、診断ツールを介して、および既定義またはユーザ定義のディスプレイを介してアクセスすることができる。Alarmシステムに関与し、制御システムでの異常な状態に注意を引き付けることは、これらのAttributesのいくつか、特に整理統合Attributesにとっては貴重である。ユーザは、ControlModulesインスタンスを作成し、プロセッサ、通信、I/O、冗長性等を含むControllersおよびSubsystemsnoために所望のDeviceAlarm戦略を実現する。FunctionBlockアルゴリズムを使用して、Device/SubsystemAttributesは、同じデバイス内でもっとも効率よくアクセスされるが、他のControllersおよびWorkstationにもサポートされている。DeviceとSubsystemのAttributesは、後で警報制限をこれらのAttributesに適用すること、これらの値をブールAttributesに変換することに対し構成できるFunctionBlocksへの入力として使用される。それから、AlarmAttributesは、ブールAttributesを参照する。一般的には、FunctionBlockシステムの完全アルゴリズム定義機能は、簡略な、または複雑なDeviceAlarming体系を構築するために使用される。FIXTM警報型と矛盾しない多くの既定義AlarmTypesは、DeviceAlarmの提示と動作を区別するために適している。既定義ControlModuleDefinitions制御モジュール定義が供給され、かなり包括的なDeviceAlarmモジュールをControllersおよび各種のI/Oシステムに提供する。ユーザは、オプションで、これらの標準モジュールをディスエーブルまたは拡張する。ユーザは、例えば小型システム戦略、分離segregation戦略、および区分化責任戦略を含む、DeviceAlarmモジュールをPlantAreasに配置するための複数の戦略を選択してよい。小型システムにおいては、PlantArea概念が適用されていない一式allinone戦略が課される。各Controller内の1つまたは複数のDeviceAlarmModulesが、DeviceとSP88MODULE警報の一体化された提示を形成する。分離戦略は、Alarm要約に対するAreaフィルタリング/並べ替えをイネーブルし、DeviceAlarmに焦点を当てるために、OperatorsがSP88MODULE警報およびプロセス/保守エンジニアに集中できるようにする。区分化責任戦略は、システムがPlantAreaごとの責任の範囲を制御するほど十分に大きくなると使用される。DeviceAlarmModulesは、DeviceAlarmModulesによって影響を受けているSP88MODULEと同じPlantArea内に配置される。区分化責任戦略は、責任範囲なおでのPlantsAreaに対するDeviceおよびSPPモジュール警報の一体化した提示を形成する。警報は、Workstation内のDevice/SubsystemAttributesにサポートされている。Draw、View、エンジニアリングツール等のユーザ起動アプリケーションは、適切なコンテキストで、個々に、異常な状態または遭遇されたエラーについて情報を提示する。WorkstationServicesは、ユーザがログオンする前にワークステーションで起動され、ログオフ/ログオンサイクルを通して実行し続けるWorkstationServicesは、無人のWorkstationにとっても、問題に対する注意を引き付けるための技法を実現する。1つの実施態様においては、WorkstationServicesは、1つまたは複数のControllersで実行しているDeviceAlarmModulesにより監視される。Servicesは、ユーザ定義DeviceAlarming戦略を制御するDeviceAlarmModulesのインスタンスを実行しているController複数の場合があるによってアクセスされる、ステータスと完全性Attributesのセットを構築する。既定義ControlModuleDefinitionsが供給され、かなり包括的なDeviceAlarmモジュールをWorkstationsおよび各主要Services例えば、通信、履歴ジャーナルなどに提供する。ユーザは、これらの標準モジュールをディスエーブルまたは拡大してよい。プロセス制御システムの1つの態様では、Alarmステータスを与えられていないイベント状態には、LOGという優先順位が指定される。LOGAlarmsはALARMSAttributesでは整理統合されず、AlarmSummaryには表示されず、状態変化の可聴予告を提供せず、型ALARMよりむしろ型EVENTとしてEventJournalに表示される。他の点では、LOG優先順位のAlarmは、イベント1が個別にイネーブル/でリスエーブルされ、2他の警報が設定されているModuleレベルではディスエーブルされ、3個々のAlarmが、その優先順位をLOGに変更する.PRIに3を書き込むことによってEventに合わせられるように、HIGH/MEDIUM/LOW優先順位Alarmとして動作する。Moduleレベルに.PRIADを設定することにより、Alarmの1つまたは複数nレベルをEventsに変換できる例えば、.PRIADに2を書き込むと、Module内のすべてのAlarm優先順位が2段低下する。つまりHIGH優先順位はLOWになり、MEDIUMとLOW優先順位はLOGになり、LOGはLOGのままとなる。.PRIADを3に設定すると、Module内のすべてのAlarmは、強制的にカレントステータスを表示する未肯定応答の場合には点滅もするためにサポートされているEvents.CUALM、LAALM、NALMフィールドになる。LOGイベントは、また4入力ブールを反転し、使用状況のためのOKイベント状態の意味をDiscreteInputsの状態でのログ変化に逆転し、5ユーザ定義警報ワードをAlarmTypesテーブルに追加し、イベント状態有効名を指定し、6EventJournalにLOG優先順位警報に関するすべての状態変化を記録することができる。システムイベント検出のユーザ選択可能強度例えば、デバッグ強度、通常強度、停止強度は、ユーザ定義の強度Attributeの設定値に基づきControlModuleアルゴリズム内で構成される。したがって、SystemEventsは1つまたはおそらく複数のPlantAreaと一直線にされ、そのため1つまたは複数のPlantAreaのためにWorkstationでEventJournalをイネーブルすると、すべてのSystemEventレコードの宛先が自動的に設定される。SystemObjectでAttributeを変更している、または方法を呼び出しているユーザは、イベントと見なされ、適切なEventJournalに記録される。制御ハイアラーキーControlModule、EquipmentModule、PlantAreaなどに対する変更は、そのPlantAreaに指定されているEventJournal複数のことがあるに記録される。Device/SubsystemAttributesに対する変更は、そのDeviceのために指定される一次PlantAreasのEventJournal複数のことがあるに記録される。図42を参照すると、コンテキスト図が、制御モジュールに関して警報イベントを定義するためのコンテキストを示している。AlarmはPlantArea範囲アクティブ警報リスト提示に表示される。複合モジュールCMインスタ成す4210は、PID機能ブロック4212、出力属性4214および高警報属性4216を含む。構成エンジニアなどのユーザは、編集のために複合モジュール4210を選択し、AttributeHIHIで警報追加4220を選択する。また、ユーザは、Advisory4232と名前が付けられているイベント優先順位定義、およびHIALARM4234と名前が付けられているイベント型定義も選択する。それから、ユーザは、制御mジュール4210に対する変更を保存する。再び図40を参照すると、警報イベント管理が説明されている。LOG優先順位Alarmとして構成されている警報およびユーザ定義イベントは、複数の動作をプロセス制御システムに導入する。これ以降RtAlarmAttribute4034と呼ばれている特殊な種類のRtAttributeは、読書きができるCUALM、NALM等のAlarmに特殊なフィールドをサポートしている別個のデータ型を有している。フィールドに対する読取りアクセスは、っこのAlarmの状態の提示を可能にする。選択されているフィールドに対する書込みアクセスは、AlarmをAcknowledgeする能力を与え、一定の警報動作を変更する。Disabled動作、AUTOAK動作などのAlarm動作の複数の特性は、SP88MODULEレベルでオンラインで無効にされることがある。Enabled/Disabled、およびNoAutoAck/AutoAckという個々のAlarm状態への逆転は、Moduleレベル無効が削除されると発生する。Moduleレベル無効の変更は、ただちに個々のAlarm状態に影響を及ぼすはずである。したがって、Moduleレベル無効での変更は、新しい条件下のモジュール内のすべてのAlarm状態の再評価を強制する。レベルのそれぞれでの最高優先順位の警報が提示されるように、アクティブ警報は、ModuleRtModule4030、PlantAreaRtPlantArea4010、およびUserSessionで整理統合される。この整理統合は、Moduleオブジェクト、PlantAreaオブジェクト、およびUserSessionオブジェクトによりサポートされているALARMS[]属性を通してアクセスされる。FIXTM警報要約リンクは、カレント警報のリストを提示するために、FIXTMヒ ゚クチャディスプレイで使用される。形容要約リンクのコンテンツは、FIXTM停止時に停止し、NTユーザがログオンすると必ずFIXTMは停止し、NTユーザは新規ユーザがログインできるようにログオフするALMSUM.EXEプロセスにより維持される。したがって、システムは、ALMSUMプロセスをカレントユーザの責任範囲の対象となるすべてのカレント警報で満たしprime、新規ユーザログオン時にそれを起動させなければならず、それは新規警報発生および警報肯定応答についてのALMSUMプロセス情報を供給しなければならないため、最新の要約が提示できる。すべての警報状態遷移は、RtAlarmAttribute4034を包含するPlantAreaに対する適切なEventJournal複数の場合があるRtEventJournal4020に向けられる。複数のEventJournalターゲットが供給されるため、EventJournalsの内の1つを実行している1つのワークステーションがある時間期間オフラインである場合、完全なEventJournalが再構築できる。Alarmエントリ状態遷移の可聴予告は、AlarmSummarizationを実行しているFIXALMSUM.EXEプロセスを供給するワークステーションで実行する。可聴予告は、PCスピーカ上での連続トーンユーザ構成周波数、および/またはPC内にインストールされている互換サウンドカードで再生される連続ループ計算.WAVファイルから成り立っている。プログラムは、スピーカとサウンドカードの両方をオフにするために実行されるので、音は、任意のFIXTMビューボタンまたはキーボードスクリプト、またはFIXVIEWが実行していない場合にはプログラムGroupのICONによってオフにできる。図43を参照すると、オブジェクト通信図が、警報中ステータスを喚起する属性書込み動作を実行するための方法を示している。属性書込み動作の前に、RtAlarmAttributeが構成、インストールされ、警報はAttributeとModuleレベルの両方でENABLEDされ、警報AUTOACKはAttributeとModuleレベルの両方で偽であり、カレントAlarm状態はInactive/Acknowledgedである。属性書込み方法により、AlarmAttributeの状態は警報状態になる。新しいAlarm状態を反映するために、AlarmAttributeの警報フィールドは更新される。イベント発生レコードが構築され、必要に応じて、Module、PlantArea、およびワークステーションアプリケーションAlarmSummary、EventJournalに送信される。属性書込み動作が完了すると、カレントAlarm状態はActive/Unacknoeldgedであり、アクティブ警報がModuleにより記録され、イベント発生レコードが構築され、このDevice内のこのPlantAreaを監視しているデバイスへの伝送のために待ち行列に入れられた。属性書込み方法のステップ4310では、RtAlarmAttributeはwriteAtributeを受け取り、それによりブールAttributeでの状態遷移が警報状態に入れられる。ステップ4312では、RtAlarmAttributeは、AttributeとModuleAlarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ4314では、RtAlarmAttributeは、AttributeとModuleAlarmAUTOACKの両方がDISABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmAutoackステータスを得る。ステップ4316では、RtAlarmAttributeが、新規警報状態、Active/Unacknowledged状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ4318では、RtAlarmAttributeは、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ4320では、RtAlarmAttributeが、新規RtEventOccurenceRecordを構築する。新規警報が作成されるため、RtAlarmAttributeは、その包含しているRtModuleに、ステップ4322で、addEventOccurenceするように命令する。ステップ4324では、RtModuleが、そのRtActiveAlarmListに、addeventOccurrenceするように命令し、新規エントリをリストに追加し、将来エントリにアクセスできるようにするハンドルを戻す。このハンドルは、究極的には、RtAlarmAttributeにより記憶される。ステップ4326では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送信する。ステップ4328では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogは、少なくとも1つのワークステーションクライアントがEventlogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。やはり図43を参照すると、オブジェクト通信図は、カレント警報状態をActive/Acknowledgedにする、AlarmのAcknowledgementにも適用できる。既存の警報の新規警報状態がModuleにより記録され、新規イベント発生レコードが構築され、このDevice内のこのPlantAreaを監視しているデバイスへの伝送のために待ち行列に入れられた。方法は、AlarmAttributeの状態を肯定応答させるためのAttribute書込み方法NALMFieldにFALSを書き込むの適用を含む。AlarmAttributeのAlarmフィールドは、新しいAlarm状態を反映するために更新される。イベント発生レコードが構築され、必要に応じてModule、PlantArea、およびワークステーションアプリケーションAlarmSummary,EventJournalに送信される。ステップ4310では、RtAlarmAttributeが、writeAttributeを受け取り、NALMFieldに状態をFALSEに変更させる。ステップ4312では、RtAlarmAttributeが、AttributeとModuleAlarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ4316では、RtAlarmAttributeが、新しい警報状態、Active/Unacknowledged状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ4318では、RtAlarmAttributeが、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ4320では、RtAlarmAttributeが、新規RtEventOccurrenceRecordを構築する。既存の警報は更新されるため、RtAlarmAttributeは、RtAlarmAttributeを包含しているRtModuleに、updateEventOccurrenceするように命令し、ステップ4322でupdateEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ4324では、RtModuleが、RtActiveAlarmListに、updateEventOccurrenceするように命令し、それにより、リスト内の既存のエントリを更新する。ステップ4327では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送信する。ステップ4328では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogは、少なくとも1つのワークステーションクライアントがEventLogレコードの受信に対する監視を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RteventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。やはり図43を参照すると、オブジェクト通信図は、Attribute書込み方法により、AlarmAttributeの状態が警報状態ではなくなる、警報状態のクリアの肯定応答にも適用できる。AlarmAttributeの警報フィールドは、新しいAlarm状態を反映するために更新され、イベント発生レコードが構築され、必要に応じて、Module、PlantArea、およびワークステーションアプリケーションAlarmSummary、EventJournalに送信される。Attribute書込み方法が完了すると、現在のAlarm状態はInactive/Acknowledgedである。この警報に関するカレント警報情報は、Moduleにより削除された。新規イベント発生レコードが構築され、このDevice内のこのPlantAreaを監視しているデバイスへの伝送のために待ち行列に入れられた。ステップ4310では、RtAlarmAttributeが、writeAttributeを受け取り、それによりブールAttributeの状態遷移は警報状態ではなくなる。ステップ4312では、RtAlarmAttributeが、AttributeとModuleAlarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ4316では、RtAlarmAttributeが、新しい警報状態、Active/Unacknowledged状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ4318では、RtAlarmAttributeが、RtEventOCcurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ4320では、RtAlarmAttributeが、新しいRtEventOCcurrenceRecordを構築する。既存の警報がクリアされるため、RtAlarmAttributeは、RtAlarmAttributeを包含しているRtModuleに、updateEventOccurrenceするように命令し,updateEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ4322では、RtModuleが、RtActiveAlarmListに、updateEventOccurrenceするように命令し、それによりリスト中の既存のエントリを更新する.ステップ4326では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaにRtEventOccurrenceRecordを送信する。ステップ4328では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogが、少なくとも1つのワークステーションクライアントが、EventLogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogrecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。また、図43を参照すると、オブジェクト通信図は、AlarmAttributeのENABフィールドをFALSEにさせることによって、警報を使用不能にすることdisablementにも適用できる。AlarmAttributeの警報フィールドは、新しいAlarm状態をはね胃する為に更新され、イベント発生レコードが構築され、必要に応じて、Module,PlantArea、およびワークステーションアプリケーションAlarmSumaary,EventJournalに送信される。警報が使用不能にされた後、カレントAlarm状態はInactive/Acknowledgedであり、ENABフィールドはFALSである。この警報のカレント警報情報は、Moduleによって削除された。新規イベント発生レコード警報DISABLEが構築され、このDevice内のこのPlantAreaを監視しているデバイスへの伝送のために待ち行列に入れられた。ステップ4310では、ENABFieldをFALSEにさせる、RtalarmAttributeが、writeAttributeを受け取る。ステップ4316では、RtAlarmAttributeが、新しい警報状態、Active/Unacknowledged状態を計算し、指数としてAlarmTypeを使用してRteventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ4318では、RtAlarmAttributeが、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ4320では、RtAlarmAttributeが、新しいRtEvedntOccurrenceRecordを構築し、このイベントを警報ディスエーブルイベントとして識別する。過去にアクティブであるときに警報がディスエーブルされるため、このイベントは、既存の警報をクリアすることであり、RtAlarmAtributeは、RtAlarmAttributeを包含しているRtModuleに、clearEventOccurrenceするように命令し、clearEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ4322では、RtModuleが、RtActiveAlarmListに、clearEventOccurrenceするように命令し、それによって既存のエントリをリストから削除する。ステップ4326では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送信する。ステップ4328では、RtPlantAreaが、そのRtAreaEventLogに、addEventするように命令し、RtAreaEventLogは、少なくとも1つのワークステーションクライアントが、EventLogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。やはり図43を参照すると、オブジェクト通信図は、AlarmAttributeのENABFieldをTRUEにさせることにより警報を使用可能にすることenablementにも適用できる。警報が使用可能になるenablement前、ブールAttributeのカレント状態は、Enabledされているのであれば、警報がActiveとなるだろうことを示しており、AutoAckは、AttributeとModuleレベルでFalseである。AlarmAttributeの警報フィールドは、新しいAlarm状態を反映するために更新され、イベント発生レコードが構築され、必要に応じて、Module、PlantArea、およびワークステーションアプリケーションAlarmSummary、EventJournalに送信される。警報が使用不能にされたdisablement後、カレントAlarm状態はActive/Unaknowledgedであり、ENABフィールドはTRUEである。この警報のカレント警報情報は、Moduleにより記憶される。新規イベント発生レコード警報Active/Unacknowledgedが構築され、このDevice内のこのPlantAreaを監視しているデバイスへの伝送のために待ち行列に入れられる。ステップ4310では、RtAlarmAttributeは、writeAttributeを受け取り、それによってENABFieldはTRUEになる。ステップ4312では、RtAlarmAttributeが、AttriguteとModuleAlarm動作の両方がENABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmDisableステータスを得る。ステップ4314では、RtAlarmAttributeが、AttributeとModuleAlarm]の両方にとって、AUTOACKがDISABLEDされるように、RtAlarmAttributeを包含しているRtModuleからalarmAutoackステータスを得る。ステップ4316では、RtAlarmAttributeは、新しい警報状態、Active/Unacknowledged状態を計算し、指数としてAlarmTypeを使用して、RtEventTypeDefinitionからプロトタイプイベント記述子文字列を読み取る。ステップ4318では、RtAlarmAttributeが、RtEventOccurrenceRecordのdescriptionStringを構築し、必要ならば、包含しているRtModuleからカレント属性値を読み取る。ステップ4320では、RtAlarmAttributeが、新しいRtEventOccurrenceRecordを構築する.警報は新しいため、RtAlarmAttributeは、RtAlarmAttributeを包含しているRtModuleに、addEventOccurrenceするように命令し、addEventOccurrenceから戻されるハンドルでRtModuleを識別する。ステップ4322では、RtModuleが、RtactiveAlarmListに、addEventOccurrenceするように命令し、それによって、新しいエントリをリストに追加する。ステップ4326では、RtModuleが、recordEventOccurrenceを介して、RtModuleのRtPlantAreaに、RtEventOccurrenceRecordを送る。ステップ4328では、RtPlantAreaが、そのRtAreaEventLogに、addeventするように命令し,RtAreaEventLogが、少なくとも1つのワークステーションクライアントが、EventLogレコードの受信に対する関心を登録したことを確かめ、RtEventOccurrenceRecordからRtEventLogRecordを作成し、RtEventLogRecordを待ち行列に入れ、それによってRtEventOccurrenceRecordを破壊する。本発明は、多様な態様に関して説明されてきたが、これらの態様が実例となり、本発明の範囲がそれらに制限されていないことが理解されるだろう。説明されている実施態様の多くの変化、修正、追加、および改善が可能である。"