"外部アプリケーションを分散制御システムDCSに接続するためのインタフェースシステムにおいて、前記DCSの構成を決定するために前記DCSをスキャンすることと、前記DCSのトポロジーモデルを構築するために、前記DCSの前記決定された構成を使用することと、前記外部アプリケーションから、前記DCS中のモジュールからのデータの外部要求を受信することと、前記DCSの前記トポロジーモデルを使用して、前記モジュールが前記要求されたデータを提供できるか否かを決定することと、を備える方法をコンピュータに実行させるための命令を有するコンピュータ可読媒体を含むインタフェースシステム。前記方法は、前記モジュールが前記要求されたデータを提供できるであろうと決定される場合、データの内部要求を生成することと、前記データの内部要求を前記モジュールに送信することと、をさらに含む、請求項2記載のインタフェースシステム。前記データの外部要求は、前記モジュールのアドレスを含む、請求項2記載のインタフェースシステム。前記決定することのステップは、前記データの外部要求中のアドレスが前記トポロジーモデル中の有効なアドレスであるか否かを判断することと、前記トポロジーモデル中の前記アドレスにおけるモジュールのタイプを決定することと、前記決定されたモジュールのタイプが前記要求されたデータを提供できるか否かを判断することと、を含む、請求項3記載のインタフェースシステム。前記方法は、前記データの外部要求中の前記アドレスが前記トポロジーモデル中の有効なアドレスであり、前記トポロジーモデル中の前記アドレスにおける前記モジュールのタイプが前記要求されたデータを提供できる場合、前記モジュールが前記要求されたテータを提供できる、と判断する、請求項4記載のインタフェースシステム。前記データの外部要求はデータの第1の外部要求であり、前記データの内部要求はデータの第2の内部要求であり、前記方法は、前記外部アプリケーションから、前記DCSからのデータの第2の外部要求を受信することと、前記DCSの前記トポロジーモデルを使用して、前記DCSが前記データの第2の外部要求中で要求された前記データを提供できるか否かを判断することと、前記DCSが前記データの第2の外部要求中で要求された前記データを提供できるであろうと判断される場合、データの第2の内部要求を生成することと、前記データの第1の外部要求が受信されたときから予め定めされた期間が経過したか否かを判断することと、前記予め定められた期間が経過していない場合、前記生成されたデータの第2の内部要求を維持することと、をさらに含む、請求項2記載のインタフェースシステム。前記方法は、前記データの第1の内部要求が前記モジュールに送信されたか否かを判断することと、前記データの第1の内部要求が前記モジュールに送信されていない場合、前記生成されたデータの第2の内部要求を維持することと、をさらに含む、請求項6記載のインタフェースシステム。前記方法は、複数のクラス中で前記トポロジーモデルを保持することをさらに含み、読み出し/書き込みロックは、前記クラスそれぞれ中のオブジェクトに置かれており、オブジェクトにおける各読み出し/書き込みロックは、前記オブジェクトに対して変更がなされている間、前記オブジェクトからのデータの読み出しを防ぎ、逆もまた同様である、請求項1記載のインタフェースシステム。前記クラスは、ループクラス、ノードクラス及びモジュールクラスを含み、前記DCSは、ループ、前記ループでの複数のノード及び各ノード中の複数のモジュールを含み、前記ループについてのオブジェクトは、前記ループクラス中に保存され、前記ノードについてのオブジェクトは、前記ノードクラス中に保存され、前記モジュールについてのオブジェクトは、前記モジュールクラス中に保存される、請求項8記載のインタフェースシステム。前記インタフェースシステムは、前記外部アプリケーションを複数の分散制御システムに接続可能である、請求項1記載のインタフェースシステム。前記データの外部要求は、前記モジュールからの診断データの要求を含む、請求項1記載のインタフェースシステム。前記診断データは、メモリ使用量、エラーカウンタ、通信メトリック、ファームウェアレベル、プログラム実行メトリック、エラー状態及びこれらの組み合わせからなるグループから選択されたデータを含む、請求項11記載のインタフェースシステム。前記DCSは、接続された複数のノードを備えるループを含み、前記ノードは、通信バスに接続されたマイクロプロセッサベースの複数のコントローラを含み、前記ループは、一方向の高速シリアルデータネットワークを含む、請求項1記載のインタフェースシステム。前記データの外部要求は、SOAPメッセージである、請求項13記載のインタフェースシステム。外部アプリケーションを分散制御システムDCSに接続する方法において、前記DCSの構成を決定するために前記DCSをスキャンすることと、前記DCSのトポロジーモデルを構築するために、前記DCSの前記決定された構成を使用することと、前記外部アプリケーションから、前記DCS中のモジュールからのデータの外部要求を受信することと、前記DCSの前記トポロジーモデルを使用して、前記モジュールが前記要求されたデータを提供できるか否かを決定することと、を備える方法。前記モジュールが前記要求されたデータを提供できるであろうと決定される場合、データの内部要求を生成することと、前記データの内部要求を前記モジュールに送信することと、をさらに含む、請求項15記載の方法。前記データの外部要求は、前記モジュールのアドレスを含む、請求項16記載の方法。前記決定することのステップは、前記データの外部要求中のアドレスが前記トポロジーモデル中の有効なアドレスであるか否かを判断することと、前記トポロジーモデル中の前記アドレスにおけるモジュールのタイプを決定することと、前記決定されたモジュールのタイプが前記要求されたデータを提供できるか否かを判断することと、を含む、請求項17記載の方法。前記方法は、前記データの外部要求中の前記アドレスが前記トポロジーモデル中の有効なアドレスであり、前記トポロジーモデル中の前記アドレスにおける前記モジュールのタイプが前記要求されたデータを提供できる場合、前記モジュールが前記要求されたテータを提供できる、と判断する、請求項18記載の方法。前記方法は、複数のクラス中で前記トポロジーモデルを保持することをさらに含み、読み出し/書き込みロックは、前記クラスそれぞれ中のオブジェクトに置かれており、オブジェクトにおける各読み出し/書き込みロックは、前記オブジェクトに対して変更がなされている間、前記オブジェクトからのデータの読み出しを防ぎ、逆もまた同様である、請求項15記載の方法。以下の詳細な説明では、本発明の別個の実施形態中で示されるか否かに関わらず、同一の構成要素が同一の参照番号であることは、留意されるべきである。さらに、明確かつ簡潔に本発明を開示するために、図面が必ずしも一定の比率で拡大されてないかもしれず、発明のある特徴が多少は略図形式で示されるかもしれないことは、留意されるべきである。ここで図1を参照すると、本発明が使用されうるDCS10概略図が示される。DCS10は、複数のノード16、18、20、22、24が接続される1以上のネットワークケーブル14を備えるループを含む。各ノードは、ループ12上で他のノードと通信するためのループ12と接続される1つの電子機器または複数の電子機器を含む。各ノードは、ループの上で一意のアドレスを有し、終端ユニットTU28によってループ12と接続される。1つのループだけが図1に示されているが、DCS10が図2に示されるように、DCS10が複数のループを含みうることは理解されるべきである。1つの実施形態では、ループ12は、10メガヘルツまたは2メガヘルツの通信レートで作動する一方向の高速シリアルデータネットワークである。ノード16、20は、プロセス制御ユニットPCUs30、32それぞれを含む。以下でより詳細に説明されるように、各PCU30、32は、発電所、製紙工場、化学プラントあるいは製造プラントのような工業設備中のプロセスまたはサブプロセスを制御するためのネットワーク通信マネージャNCMモジュール35及び1以上のコントローラを含む。NCMモジュール35は、パッケージ化するべき出力データについてコントローラを監視し、コントローラに入力データをルーティングし、配信する。各コントローラは、余分かもしれないし、PCUは、第2のTU28上のネットワークに付けられた余分のNCMモジュール35を含むかもしれない。ノード16、20の各々は、TU28及び1以上のNCMモジュール35を通じてループ12に接続されている。ノード18、22は、接続されたオペレーションワークステーション36、38それぞれと共にコンピュータインタフェースユニットCIUs34を含む。各ワークステーション36、38は、オペレータが設備中のプロセス及びサブプロセスを監視し、手動で制御できるグラフィカルユーザインタフェースGUIを表示するためのモニタだけでなく、プロセッサ及び関連するメモリを備える。各ワークステーション36、38は、それぞれCIU34及びTU28を通じてループ12に接続されている。CIU34は、ワークステーションから分離されているかもしれず、ワークステーション内に一体化されているかもしれないが、DCS10の一部である。図を簡略化するために、ワークステーション36、38と関連付けられたCIU34は、ワークステーション36、38に一体化されている。以下により詳細に説明されてるように、スマートインタフェースシステム44は、ワークステーション38のメモリに格納され、ワークステーション38の1以上のプロセッサによって実行される。PCU32は、イーサネット登録商標のようなプロトコルを備えたシリアル通信システムでありうる通信バス52に接続された複数のマイクロプロセッサベースコントローラ50を含むことができる。各コントローラ50は、工業設備の1以上のサブプロセスまたはループを制御するための1以上の制御プログラムまたは構成を含む。制御プログラムは、1以上のI/Oサブシステム54を通じたフィールドデバイスから受信される動作値を利用する。各単一のコントローラ50または余分なコントローラ50対は、個別のI/Oサブシステム54を有することができる。制御プログラムは、5つのIEC61131-3規格言語:ラダーダイアグラム、ストラクチャードテキスト、ファンクションブロックダイアグラム、インストラクションリスト及びシーケンシャルファンクションチャートの1以上の中で記述されることができる。さらに、制御プログラムは、Cのような従来のプログラム言語で記述されることができる。本発明の1つの実施形態では、制御プログラムは、ファンクションブロックダイアグラム中で記述される。制御プログラムからの出力は、I/Oサブシステム54を通じてフィールドデバイスの制御装置に送信される。I/Oサブシステム54は、I/Oバス58に接続された複数のI/Oモジュール56を含む。コントローラ50も、I/Oモジュール56から動作値を受信するために、I/Oバス58に接続される。一般的に、PCU30は、PCU32に類似した構成を有する。つまり、PCU30は、複数のコントローラ、通信バス及びI/Oサブシステムを有する。ここで図2を参照すると、本発明の実施形態が示される。ここで、事業体は、第1のDCS10及び第2のDCS70を有する。さらに、第1のDCS10は、第1のループ12と類似した構成を有する第2のループ60を備えて示される。つまり、第2のループ60は、1以上のPCUを有し、それぞれが複数のコントローラ、通信バス及びI/Oサブシステムを備える。第1及び第2のループ12、60は、ブリッジモジュール62によって接続される。第2のDCS70は、DCS10と類似した構成を有する。つまり、DCSは、1以上のループを有し、それぞれが複数のコントローラ、通信バス及びI/Oサブシステムを備える。示されるように、ワークステーション38及びその上で動作するスマートインタフェースシステム44は、DCS10及びDCS70の両方に接続される。ここで図3を参照すると、1以上の外部アプリケーションとDCS10、70との間のインタフェースを自動的に提供するように動作するソフトウェアシステムであるスマートインタフェースシステム44の概略的な絵が示される。示されるように、スマートインタフェースシステム44は、一般的にソフトウェアアプリケーションインタフェースAPI80、システムデータアクセスSDAサーバ82及びOPCサーバ84を備える。API80は、CIU34中のネイティブ言語コマンドセットへのアクセスを提供するC言語サブルーチンのセットを含むローレベルインタフェースである。各CIU34は、ワークステーション36または38のようなマイクロプロセサベース機器またはPCU例えば、PCU30または32をループ例えば、ループ12に接続する1以上のハードウェアモジュールで構成される。1つの実施形態では、各CIU34は、ネットワークインタフェースモジュール及びコンピュータ転送モジュールへのネットワークを含む。この実施形態では、各CIU34は、ブロードキャスト、時間同期、マルチキャスト及びポーリングの4つのメッセージタイプを扱うことができる。さらに、全てのメッセージは、データの完全性を保障するための循環冗長検査符号及びチェックサムを含む。SDAサーバ82は、非常に適合性があり、1または複数のDCS例えば、2つ、3つ、4つなどのDCSと共に使用されうる。SDAサーバ82に接続される各DCSについて、APIアクセス、APIコネクタ、CIUモニタ及びトポロジーファインダの例が作成される。さらに、SDAサーバ82は、APIラッパ196及びトポロジーモデルデータベース88を含む。図3に示される実施形態において、SDAサーバ82は、2つのDCS、すなわち、DCS10及びDCS70をインタフェースで連結し、DCS10のためのトポロジーファインダ85及びDCS70のためのトポロジーファインダ86を含む。各トポロジーファインダは、それに関連するDCSのトポロジーを発見するために、SDAサーバ82の起動により作動し、DCSのトポロジーモデルを生成する。これらのトポロジーモデルは、トポロジーモデルデータベース88に保存される。トポロジーモデルデータベース88は、SDAサーバ82が接続された全てのDCSのモデルを含む。DCSは、この場合、DCS10及びDCS70を含む。以下により十分に説明されるように、トポロジーモデルデータベース88は、任意の接続されたDCSと共に生じうる通信のタイプを制御する内部基準として使用される。トポロジーファインダのメインルーチン92は、図4に示される。ステップ96において、メインルーチン92は、スマートインタフェースシステム44が属するループつまり、ローカルループであって、図3の実施形態におけるループ12であるループを最初にスキャンするための図5に示されるループスキャンサブルーチンを引き起こす。ステップ96の終了後、メインルーチン92は、ステップ98に進む。ここで、メインルーチン92は、ローカルループ例えば、ループ12のノード例えば、ノード16-24をスキャンするための図6に示されるノードスキャンサブルーチン112を引き起こす。ローカルループ及びローカルループのノードがスキャンされた後、メインルーチン92は、ステップ100に進む。ここで、スキャンすべき他のループがあるか否かチェックがなされる。スキャンすべき他のループがある場合、メインサブルーチンは、次のループ例えば、ループ60に進み、ステップ102において、次のループをスキャンするためのループスキャンサブルーチンを引き起こす。ステップ102の後、メインルーチン92は、ステップ104に進む、メインルーチン92は、次のループのノードをスキャンするためのノードスキャンサブルーチンを引き起こす。切断されていると判断されるスキャンすべきループまたはAPIがなくなるまで、ステップ100-104は、繰り返される。いったんDCS中のループの全てがスキャンされると、DCSのトポロジーモデルは、完了し、メインルーチン92は、ステップ106に戻る。メインルーチン92のループスキャン手順及びノードスキャン手順は、DCSのトポロジーモデルを更新するために周期的に実行される。予め定められた期間が経過したことをタイマーが示す場合、メインルーチン92は、上記説明されたループスキャンステップ及びノードスキャンステップを再び実行するために、複数のステップを通じてステップ106から、ステップ96に戻って実行する。ここで図5を参照すると、ループスキャンサブルーチン110のフローチャートが示される。ステップ112において、ループスキャンサブルーチン110は、本ループについてのループトポロジーレポートを生成する。ループトポロジーレポートは、本ループにおけるノードの全てのリストを含み、各ノードについての識別情報を含む。例えば、識別情報は、ループ上の各ノードノード順のノードのアドレス、ノードのタイプ例えば、プロセス制御、コンピュータインタフェース、ブリッジインタフェース、イベントのシーケンスまたは他のもの及び電気的/論理的位置を含むことができる。ステップ114において、ループスキャンサブルーチン110は、診断動作を実行する。ここで、有効な診断情報は、任意のループに通信問題があるか否かを判断するために検討される。ループの1つに通信問題がある場合、問題は、接続された外部アプリケーションにおけるディスプレイでこの問題が視覚的に確認されうるように、マークが付されるフラグがたてられる。ステップ114の後、ループスキャンルーチンは、トポロジーモデルがループトポロジーレポートを使用してスキャンが初期スキャンか更新スキャンかに応じて生成されるまたは更新される一連のステップに進む。既存のトポロジーモデルにおいて対応するオブジェクトをすでに有していないループトポロジーレポートにおいて任意のノードが発見された場合、新たなオブジェクトは、ノードを表わすために生成され、トポロジーモデルに加えられる。ノードがリモートループへのブリッジである場合、新たなループオブジェクトも生成され、トポロジーモデルに加えられる。既存のトポロジーモデルにおいて既に表わされているループトポロジーレポートにおいてノードが発見された場合、発見されたノードのタイプは、既存のトポロジーモデルにおけるノードオブジェクトと比較されるでしょう。ノードタイプが一致しない場合、既存のノードオブジェクトは、廃棄され、現在のトポロジーを表わすループトポロジーレポートによって表わされるような新しいノードオブジェクトと置き換えられる。既存のトポロジーモデルにおけるノードオブジェクトに対応するノードが現在のループトポロジーレポート中にもはや存在しない場合、ステップ124において、ノードは、オフラインとしてマークが付される。ユーザ選択可能期間よりも長いオフラインの任意のノードは、永久にDCSから取り除かれるとみなされ、その対応するノードオブジェクトは、ステップ126においてトポロジーモデルから取り除かれる。この期間は、プラント条件、つまり、週かもしれないメンテナンス中、通常10分未満またはノードをリセットするのに必要な時間である通常動作中、によって調節されうる。ノードオブジェクトがトポロジーモデルから取り除かれる場合、以前にそのノードオブジェクトの一部だった全てのモジュールオブジェクトも削除される。ここで、図6を参照すると、ノードスキャンサブルーチン112のフローチャートが示される。ノードスキャンサブルーチン112は、そのノードに関連した全てのモジュールについての特定のノードをスキャンする。このスキャンから取得される情報は、スキャンが初期スキャンか更新スキャンかに応じて、トポロジーモデルを生成するまたは更新するために使用される。ノードスキャンサブルーチン112は、ノードにおける考えうる各モジュールアドレスにステータス要求メッセージを送信することによって特定のノードをスキャンする。良い応答が特定のアドレスのモジュールから受信される場合、その後、モジュールは、存在し、かつオンラインであると知られる。応答がないまたは悪い応答が受信される場合、その後、ターゲットとされたモジュールは、存在しないと判断される。ノードスキャンサブルーチン112によって発見されるモジュールと同じアドレスのトポロジーモデルにおけるモジュールオブジェクトがある場合、その後、オブジェクト及び発見されたモジュールのモジュールタイプは、比較される。オブジェクトのモジュールタイプが発見されたモジュールと一致しない場合、その後、オブジェクトは、ステップ130において削除され、発見されたモジュールを表わすために、ステップ132において新たなオブジェクトと取り替えられる。ステップ132の一部として、ノードスキャンサブルーチン112は、そのモジュールタイプの既知の能力を決定するために、ハードウェア能力データベース215中で、発見されたモジュールのモジュールタイプを調べ、トポロジーモジュールデータベース88中に、トポロジーモデルにおけるモジュールオブジェクトと共に、この情報を保存する。ステータス要求メッセージがトポロジーモデル中のモジュールオブジェクトと同じアドレスでモジュールに送信され、応答がないまたは悪い応答が返信される場合、その後、そのアドレスのモジュールは、ステップ134においてオフラインとマークが付されるでしょう。モジュールがユーザ選択可能期間よりも長いオフラインのままである場合、その後、モジュールは、DCSから永久に取り除かれるとみなされ、その対応するモジュールオブジェクトは、ステップ136においてトポロジーモデルから取り除かれる。この期間は、プラント条件、つまり、週かもしれないメンテナンス中、通常5分未満またはモジュールをリセットするのに必要な時間である通常動作中、によって調節されうる。新たなモジュールオブジェクトがステップ132で生成された後、ノードスキャンサブルーチン112は、ステップ140に進む。ここで、サブルーチンは、モジュールステータス例外レポートタグをサポートできるモジュールが提供され、新たに生成されたモジュールオブジェクトに対応するモジュールについて、CIU34におけるModStatXRtagを生成する。ノードスキャンサブルーチン112は、モジュールがモジュールのタイプに基づくModStatXRtagを安全にサポートすることができるか否か判断する。例えば、コントローラ50のようなメインコントローラは、ModStatXRtagをサポートできるが、バックアップコントローラ、いくつかの通信モジュール及びI/Oモジュールはできない。しかしながら、メインコントローラ用のModStatXRからの例外レポートは、コントローラに関連したバックアップコントローラ及びI/Oモジュールについての情報を含むでしょう。そして、インテリジェント通信モジュールからのModStatXRは、そのペアになったネットワークインタフェースモジュールについての情報を含むでしょう。ModStatXRtagは、重要な情報量がモジュールから集められ、例外レポート中で報告されることを可能にする。そのような情報は、モジュールのタイプ、モジュールの動作状態例えば、構成する、実行するなど、モジュールによって使用される様々な通信チャンネルの誤り状態及びモジュールの電源部に関する問題を含む。モジュールからの例外レポートは、接続されているCIU34に一時的に保存され、次に集められ、トポロジーモデルに保存される。CIU34において、プロセス値またはモジュールステータスタグのいずれかのポイントからの例外レポートが受信されるとき、以前の例外レポートは、上書きされる。したがって、CIU34は、迅速な状態変化を得るために頻繁にポーリングされる。いくつかの実施形態では、状態とプロセス情報は、例外レポートの代わりにポーリングによって得られる。トポロジーモデルデータベース88は、異なるクラスのオブジェクトを使用して、生成され、保存される。ここで、図7を参照すると、トポロジーモデルデータベース88を保存するために使用されるクラス構造150が示される。示されるように、クラス構造150は、モデルクラス152、ループリストクラス154、ノードリストクラス156及びモジュールリストクラス158を含む。モデルクラス152は、事業体のために全てのトポロジーモデルについての情報を提供し、これらのトポロジーモデルの改良を可能にする。モデルクラス152は、事業体における全てのDCS、ノード及びモジュールについての情報を提供することができ、トポロジーモデルからの先のオブジェクトの追加及び削除を可能にする。モデルクラス152は、DCSクラス162への呼を使用してDCSについての情報を取得し、ループリストクラス154への呼を使用して、ループ、ノード及びモジュールについての情報を取得する。ループリストクラス154は、事業体における全てのループ、ノード及びモジュールについての情報を提供し、トポロジーモデルからのループについてのオブジェクトの追加及び削除を可能にする。ループリストクラス154は、エンティティリストベースクラス160への呼を使用して、ループについての情報を取得し、ノードリストクラス156への呼を使用して、ノード及びモジュールについての情報を取得する。ノードリストクラス156は、事業体における全てのノード及びモジュールについての情報を提供し、トポロジーモデルからのノードについてのオブジェクトの追加及び削除を可能にする。ノードリストクラス156は、エンティティリストベースクラス160への呼を使用して、ノードについての情報を取得し、モジュールリストクラス158への呼を使用して、モジュールについての情報を取得する。モジュールリストクラス158は、事業体における全てのモジュールについての情報を提供し、トポロジーモデルからのモジュールについてのオブジェクトの追加および削除を可能にする。モジュールリストクラス158は、エンティティリストベースクラス160への呼を使用して、モジュールについての情報を取得する。エンティティリストベースクラス160は、エンティティベースクラス162を通じて、ループ、ループクラス164、ノードクラス166及びモジュールクラス168それぞれから、ループ、ノード及びモジュールについての情報を取得する。モジュールクラス168は、次々に、モジュール定義クラス170及びモジュール識別子クラス172からモジュールについての詳細な情報を取得する。トポロジーモジュールは、スレッドセーフである。つまり、データは、データに影響を及ぼす変更がなされた場合、データは、読み出されることが許可されず、その逆もまた同様である。クラス構造150の構造は、段階的かつ粒状の方法で実施されるようにこのスレッドセーフを可能にする。より具体的には、読出し/書き込みロックは、クラス構造150の各クラスで実施される。したがって、読み出し/書き込みロックは、1DCオブジェクトが事業体のトポロジーモデルに対して加えられている、または、削除されている場合、DCSオブジェクトについての任意の情報が読み出されることを防ぐために、2情報がDCSオブジェクトから読み出されている場合、DCSオブジェクトがトポロジーモデルに対して加えられている、または、削除されていることを防ぐために、モデルクラス152におけるDCSオブジェクトで実行される。同様に、読み出し/書き込みロックは、1ループオブジェクトが事業体のトポロジーモデルに対して加えられている、変更されている、または、削除されている場合、ループオブジェクトについての情報が読み出されていることを防ぐために、2情報がループオブジェクトから読み出されている場合、ループオブジェクトがトポロジーモデルに対して加えられている、変更されている、または、削除されていることを防ぐために、ループリストクラス154におけるループオブジェクト上で実施される。クラスの階層の下の方まで続け、同様の読み出し/書き込みロックは、ノードリストクラス156、及びモジュールリストクラス158それぞれにおけるノードオブジェクト及びモジュールオブジェクトに置かれる。ループクラス164、ノードクラス166及びモジュールクラス168における読み出し/書き込みロックは、より一層の粒状のロック能力を提供する。例えば、読み出し/書き込みロックは、1モジュールが構成されているまたは更新されている場合、モジュールについての任意の情報が読み出されることを防ぐために、2モジュールが読み出されている場合、モジュールが構成されている、更新されているまたは削除されていることを防ぐために、モジュールクラス168の各オブジェクトの例で実行される。前述から、クラス構造150の構成がSDAサーバ82の動作を不当に妨害することなしに、スレッドセーフティを提供することは、理解されるべきである。より詳細には、構成は、ロックされる必要のあるDCSのその部分にのみ向けられるべき読み出し/書き込みロックを可能にする。例えば、DCSのループにおける2つの異なるノードにおける2つのモジュールのみがロックされる必要がある場合、例えば、これらが構成されているので、ロックは、両方のノードの代わりにこれら2つのモジュールで、ループ全体でまたはDCS全体でのみ実施される。これは、モデルオブジェクトが単純な階層手法で配置されている場合のケースであろう。図3に戻って参照すると、トポロジーモデルデータベース88及びトポロジーファインダ85、86に加えて、DCS10,70についてのSDAサーバ82の実施形態は、APIコネクタ180、CIU34aについてのAPIアクセス182及びCIUモニタ184、及びCIU34bDCS170についてのAPIコネクタ188、APIアクセス、CIUモニタ192を備える。各APIコネクタ180、188は、API80を介してその関連するCIU34への接続を確立し、閉じる。さらに、各APIコネクタ180、188は、その関連付けられたCIU34におけるポイントデータベースについて使用されるインデックスを割り当てて追跡するポイントマネージャオブジェクトを含む。CIU34が再開されるときはいつでも、その関連付けられたAPIコネクタにおけるポイントマネージャオブジェクトが削除され、ポイントデータベースをクリアするCIU34を再開して以来新たなものが生成される。各CIUモニタ182、192は、その関連付けられたCIU34中での接続を確立し、維持し、再開するように、その関連付けられたコネクタと相互作用する。さらに、CIUモニタは、設定された間隔で、接続の状態をチェックする。各実行サイクル中に、CIUモニタは、その関連付けられたCIU34から例外レポートを検索し、その関連付けられたAPIコネクタの状態をチェックするでしょう。その関連付けられたAPIコネクタがオフラインまたは分離されているとして見つけられる場合、CIUモニタは、APIコネクタとCIU34との間の接続を再確立しようとするでしょう。各APIアクセス182、190は、制御される方式で、その関連付けられたCIU34及びAPI80を通じて、要求を送信し、その関連付けられたDCSから応答を受信する。APIアクセスは、CIU34以外の通信モジュール及びAPI80以外のソフトウェアアプリケーションインタフェースと使用可能となるように容易に改良できうる。さらに、APIアクセスも、CIU34及びAPI80を介して、DCSから診断データを取り出し可能である。診断データは、メモリ使用量、エラーカウンタ、通信メトリック、ファームウェアレベル、プログラム実行メトリック、エラー状態を含む。APIアクセスは、関連付けられたAPIコネクタに対する参照ポインタを有するが、APIコネクタ上でステータス読み出し及び更新のみを実行する。APIアクセスは、通信のレートを制御するスロットリングメカニズムを使用して、要求を送信する。スロットリングメカニズムは、要求の開始の間に必要な時間であるポーリング期間を使用する。APIアクセスに対する呼が開始された時から計測して以前の第1の呼のポーリング期間が経過する前に、第2の呼が第2の要求を発するAPIアクセスに対してなされる場合、第2の要求は、第1の呼のポーリング期間が経過するまで遅延されるでしょう。さらに、以前の第1の要求が完了する前に第2の要求についての第2の呼がAPIアクセスに対してなされる場合、読み出し/書き込みロックは、第1の要求が完了するまで、第2の要求及び任意の後の要求が送信されることを防ぐ。第1の要求が完了するとき、読み出し/書き込みロックは、ポーリング期間が経過する時に解除され、次のインラインスレッドへ有効にされるでしょう。SDAサーバ82の要素クラスは、マイクロソフトのNETイニシアチブのコア要素である共通言語ランタイムを利用する。CLRにおいて、コードは、共通中間言語と呼ばれるバイトコードの形式で表される。SDAサーバと対照的に、API80は、従来のCライブラリを使用する。したがって、APIラッパ196は、提供され、APIコネクタ180、188及びAPIアクセス182、190に接続されている。APIラッパ196は、SDAサーバ82の要素からの要求をAPI80への伝達のために従来Cの呼に翻訳し、API80から受信された従来のC構造、アレイ及びポインタを、SDAサーバ82の要素によって使用される従来のNETデータタイプに翻訳する。ウェブサーバアプリケーション200は、シンプルオブジェクトアクセスプロトコルを使用して、SDAサーバ82を任意のウェブクライアントに接続するために提供される。しかしながら、ウェブサーバアプリケーション200とクライアントとの間の通信は、暗号化される。さらに、ウェブサーバへのクライアントの接続は、SDAサーバ82をホストするサーバ例えば、ワークステーション上のローカルアカウントとして接続することにより認証されるべきである。SDAサーバ82は、ウェブサーバアプリケーション200によって受信されるデータ要求を扱うことができ、DCSにおける多数のターゲットからの情報を要求できる。そのようなマルチターゲットデータ要求は、通常は、診断であり、各ターゲット例えば、ブロック読み出しからの単一のフロート値からの少量のデータのみを必要とする。要求された動作は、各ターゲット用に実行され、全ての要求された動作の結果は、同時に、関係するAPIアクセス182または190に戻される。要求中に複数のターゲットを指定することは、要求が完了し、結果が戻されうる前に、時間を延長するでしょう。しかし、それは、より少ない往復及びそれによるオーバヘッドに帰着するでしょう。これは、さもなければ多くの読み出しがとても短い時間に必要とされるであろう、及び結果として生じるデータがとても小さいであろう例えば、コントローラモジュールからの要求されるブロック読み出しが複数のリクエストに代えてウェブサーバアプリケーション200への単一の要求でなされうるという場合に有益である。指定されうるターゲットの数は限られておらず、合理的な要求をなすことは、クライアントアプリケーション次第である。スロットリングが適切なAPIアクセスによって実行されるので、多数のターゲットを備える要求は、CIU34をフロードさせないでしょう。大量のデータ例えば、ループトポロジーレポートを要求するウェブサーバアプリケーション200対する診断データ要求は、概して、DCS中の単一のターゲットにのみ向けられる。OPCサーバ84は、OPCUAを介したSDAサーバ82からのデータを公表するように動作可能であり、TCPとHTTPOPCUA通信スタックとの両方を使用して接続をサポートする。OPCサーバ84は、読み出しを実行し、動作を実行するのに必要な呼を機能させ、サブスクリプション206を提供する。OPCサーバ84は、カスタムノードマネージャ210及びカスタムオブジェクトタイプ、カスタム複合変数タイプ、カスタム一覧及び方法を含むカスタムOPCデータモデル212を実施する。OPCサーバ84は、2つのインタフェースを通じてSDAサーバ82に接続する。自発的に発見され、SDAサーバ82によって監視された例外レポートのようなデータは、ランタイムメインインタフェース214を通じてOPCサーバ84に押し出される。SDAサーバ82からポーリングされるべきデータは、ウェブサーバアプリケーション200を通じて取り出される。OPCサーバのカスタムノードマネージャ210は、随意的に、ヒストリアンのために、データを記録するためのIXデータハンドラースレッドを立ち上げることができる。記録された情報は、OPCサーバ84またはクライアントサブスクリプションに対する読み出し要求を満たすために、必要とされる任意の診断データだけでなく、全ての発見されたトポロジー情報及び変更、例外レポートを含むであろう。OPCサーバのカスタムノードマネージャ210は、随意的に、ユーザが明らかにさらされることを望むプロセスタグを安全に構成することを可能にするユーザタグマネージャ87コンポーネントを利用できる。ユーザタグマネージャ87は、データベースからユーザ定義タグ情報をロードする。DCS例えば、DCS10または70におけるモジュールが発見されるので、プロセスデータについてのタグをサポートするいくつかのモジュールは、見つけられることができ、識別されることができる。このような場合において、ノードマネージャ210は、発見されたモジュール中にユーザがタグを明らかに設定したか否かを判断するために、ユーザタグマネージャ87をチェックする。もしそうであれば、これらのタグは、ポーリングまたは例外レポートの何れかにより、OPCサーバ84を通じて、ユーザにさらされる。OPCノードマネージャ210は、DCSにおけるポイントをセットするために、または、ユーザ定義タグについてモジュールから値を集めるために、それに命令するために、SDAサーバ82に要求をする必要があるでしょう。これらの要求の各々は、ターゲットモジュールが要求された動作の能力があること、及びそれがその動作をサービスできる状態にあることを確実にするために、SDAサーバ82によって選別されるでしょう。したがって、ユーザは、システム中で通信問題を引き起こすであろう無効なタグを構成できない。DCSが全てのデータを単一のCIU34にルーティングできないかもしれない、または、適時に単一のCIU34に全てのプロセスデータについての更新を提供できないかもしれないので、ユーザは、プロセスデータが外部アプリケーションに配信されることを確実にするために、特定の外部アプリケーションに、重要なプロセスデータについてのタグを手動で設定する。ここで、スマートインタフェースシステム44の動作は、DS10に関して説明されるでしょう。スマートインタフェースシステム44及び特定のSDAサーバ82の開始により、トポロジーファインダ85は、DCS10のトポロジーを発見し、それをトポロジーモデルデータベース88に加える。構造化可能なトポロジーモデルデータベース88は、所定間隔に応じて、周期的に更新される。ウェブサーバアプリケーション200がDCS10における特定のアドレスの特定のモジュールデータについての要求を受信したとき、この要求は、アドレスループ、ノード、モジュールなどが有効か否か、及び要求されたそのデータがアドレスにおける特定のモジュール及び/またはノードから取得されうるすなわち、それによってサポートされるか否かを決定するために、トポロジーモデルデータベース88に送られる。トポロジーモデルデータベース88がそのアドレスが有効で、要求されたデータがそのアドレスのモジュールから取得されうると判断する場合、要求は、APIラッパ196、API80及びCIU34aを通じて、任意の必要とされるスロットリングの対象となるモジュールからデータを取得するための要求で動作するAPIアクセス182に送られる。モジュールからの要求されたデータは、その後、CIU34a、API80、APIラッパ196及びAPIアクセス182を通じて、ウェブサーバアプリケーション200に返送される。スマートインタフェースシステム44は、多くの利益をもたらす。有効なDCS構成がインタフェースに存在することを保証することをユーザに頼る代わりに、スマートインタフェースシステム44は、ランタイムで自己構築するために、DCS構成要素の自動発見を使用する。このことは、スマートインタフェースシステム44に置かれるDCS機器が識別され、実際に存在することを意味する。ユーザは、存在しない機器またはアクセスされた場合にシステム混乱を引き起こすであろう機器にタグを設定する、または、コマンドを発するオプションを有していない。これは、さらに、手動でDCS構成を確認することの困難なタスクからユーザを開放し、スマートインタフェースシステム44が存在するシステムで早期に配置されることを可能にする。さらに、DCSの発見及び自己構築は、DCSにおける任意のターゲット機器によってサポートされていないブロックコマンドに使用されうる。さらに、いくつかのコマンドが機器の特定のモジュールでのみサポートされているので、これは、ユーザが機器にサポートされていないコマンドを発することを防ぐことにより、DCSを保護する。ユーザ要求をサービスするための任意のコマンドがDCSに出される前に、検査は、発見された構成におけるターゲット機器について実行され、それは、各機器の能力の知識を含む。コマンドがターゲット機器によってサポートされていない場合、ユーザは、要求を中断する。スマートインタフェースシステム44のさらなる利益は、スマートインタフェースシステム44がDCSで置かれているロードに帰着する要求を調節することである。DCSに発せられているコマンドに帰着し、確認要求を渡す全ての要求は、DCSへの際立ったユーザ要求を制限し、最大の要求レートを実行するスロットリングメカニズムの対象とされている。起こされた新たな要求は、これらの必要条件を満たすためにスロットリングメカニズムによって保持され、遅延させられうる。これは、不正を働くクライアントアプリケーション、または、さもなければ膨大なサポートされたコマンドを備えるDCSを混乱させるクライアントアプリケーションを偶発的にまたは故意に構成し、または使用しようとするユーザに対してさらに強固にされるインタフェースシステムに帰着する。先の例示的な実施形態の記載が完全なものではなく本発明の単なる例証となるように意図されることは、理解されるべきである。当業者は、添付された請求項によって定義されているように、発明の趣旨またはその範囲を逸脱することなく、開示された内容の実施形態に対する特定の追加、削除及び/または改良をすることができるであろう。"