(57)【要約】インテリジェントインタフェースシステムは、外部アプリケーションを分散制御システム（ＤＣＳ）に接続することで提供される。インタフェースシステムは、ＤＣＳの構成を決定するためにＤＣＳを自動的にスキャンすることが可能であり、ＤＣＳのトポロジーモデルを構築することが可能である。トポロジーモデルは、ＤＣＳ中のモジュールから要求されるデータがモジュールによって提供されうるか否かを決定するために、使用される。トポロジーモデルは、スレッドセーフとなりうるように構築される。インタフェースシステム中のスロットリングメカニズムは、過度なデータ要求にさらされることからＤＣＳを保護する。
2013542524.tif 000002
【特許請求の範囲】
【請求項１】
外部アプリケーションを分散制御システム（ＤＣＳ）に接続するためのインタフェースシステムにおいて、
前記ＤＣＳの構成を決定するために前記ＤＣＳをスキャンすることと、
前記ＤＣＳのトポロジーモデルを構築するために、前記ＤＣＳの前記決定された構成を使用することと、
前記外部アプリケーションから、前記ＤＣＳ中のモジュールからのデータの外部要求を受信することと、
前記ＤＣＳの前記トポロジーモデルを使用して、前記モジュールが前記要求されたデータを提供できるか否かを決定することと、
を備える方法をコンピュータに実行させるための命令を有するコンピュータ可読媒体を含むインタフェースシステム。
【請求項２】
前記方法は、
前記モジュールが前記要求されたデータを提供できるであろうと決定される場合、データの内部要求を生成することと、
前記データの内部要求を前記モジュールに送信することと、
をさらに含む、請求項２記載のインタフェースシステム。
【請求項３】
前記データの外部要求は、前記モジュールのアドレスを含む、請求項２記載のインタフェースシステム。
【請求項４】
前記決定することのステップは、
前記データの外部要求中のアドレスが前記トポロジーモデル中の有効なアドレスであるか否かを判断することと、
前記トポロジーモデル中の前記アドレスにおけるモジュールのタイプを決定することと、
前記決定されたモジュールのタイプが前記要求されたデータを提供できるか否かを判断することと、
を含む、請求項３記載のインタフェースシステム。
【請求項５】
前記方法は、前記データの外部要求中の前記アドレスが前記トポロジーモデル中の有効なアドレスであり、前記トポロジーモデル中の前記アドレスにおける前記モジュールのタイプが前記要求されたデータを提供できる場合、前記モジュールが前記要求されたテータを提供できる、と判断する、請求項４記載のインタフェースシステム。
【請求項６】
前記データの外部要求はデータの第１の外部要求であり、前記データの内部要求はデータの第２の内部要求であり、
前記方法は、
前記外部アプリケーションから、前記ＤＣＳからのデータの第２の外部要求を受信することと、
前記ＤＣＳの前記トポロジーモデルを使用して、前記ＤＣＳが前記データの第２の外部要求中で要求された前記データを提供できるか否かを判断することと、
前記ＤＣＳが前記データの第２の外部要求中で要求された前記データを提供できるであろうと判断される場合、データの第２の内部要求を生成することと、
前記データの第１の外部要求が受信されたときから予め定めされた期間が経過したか否かを判断することと、
前記予め定められた期間が経過していない場合、前記生成されたデータの第２の内部要求を維持することと、
をさらに含む、請求項２記載のインタフェースシステム。
【請求項７】
前記方法は、
前記データの第１の内部要求が前記モジュールに送信されたか否かを判断することと、
前記データの第１の内部要求が前記モジュールに送信されていない場合、前記生成されたデータの第２の内部要求を維持することと、
をさらに含む、請求項６記載のインタフェースシステム。
【請求項８】
前記方法は、複数のクラス中で前記トポロジーモデルを保持することをさらに含み、
読み出し／書き込みロックは、前記クラスそれぞれ中のオブジェクトに置かれており、オブジェクトにおける各読み出し／書き込みロックは、前記オブジェクトに対して変更がなされている間、前記オブジェクトからのデータの読み出しを防ぎ、逆もまた同様である、請求項１記載のインタフェースシステム。
【請求項９】
前記クラスは、ループクラス、ノードクラス及びモジュールクラスを含み、前記ＤＣＳは、ループ、前記ループでの複数のノード及び各ノード中の複数のモジュールを含み、
前記ループについてのオブジェクトは、前記ループクラス中に保存され、前記ノードについてのオブジェクトは、前記ノードクラス中に保存され、前記モジュールについてのオブジェクトは、前記モジュールクラス中に保存される、請求項８記載のインタフェースシステム。
【請求項１０】
前記インタフェースシステムは、前記外部アプリケーションを複数の分散制御システムに接続可能である、請求項１記載のインタフェースシステム。
【請求項１１】
前記データの外部要求は、前記モジュールからの診断データの要求を含む、請求項１記載のインタフェースシステム。
【請求項１２】
前記診断データは、メモリ使用量、エラーカウンタ、通信メトリック、ファームウェアレベル、プログラム実行メトリック、エラー状態及びこれらの組み合わせからなるグループから選択されたデータを含む、請求項１１記載のインタフェースシステム。
【請求項１３】
前記ＤＣＳは、接続された複数のノードを備えるループを含み、前記ノードは、通信バスに接続されたマイクロプロセッサベースの複数のコントローラを含み、前記ループは、一方向の高速シリアルデータネットワークを含む、請求項１記載のインタフェースシステム。
【請求項１４】
前記データの外部要求は、ＳＯＡＰメッセージである、請求項１３記載のインタフェースシステム。
【請求項１５】
外部アプリケーションを分散制御システム（ＤＣＳ）に接続する方法において、
前記ＤＣＳの構成を決定するために前記ＤＣＳをスキャンすることと、
前記ＤＣＳのトポロジーモデルを構築するために、前記ＤＣＳの前記決定された構成を使用することと、
前記外部アプリケーションから、前記ＤＣＳ中のモジュールからのデータの外部要求を受信することと、
前記ＤＣＳの前記トポロジーモデルを使用して、前記モジュールが前記要求されたデータを提供できるか否かを決定することと、
を備える方法。
【請求項１６】
前記モジュールが前記要求されたデータを提供できるであろうと決定される場合、データの内部要求を生成することと、
前記データの内部要求を前記モジュールに送信することと、
をさらに含む、請求項１５記載の方法。
【請求項１７】
前記データの外部要求は、前記モジュールのアドレスを含む、請求項１６記載の方法。
【請求項１８】
前記決定することのステップは、
前記データの外部要求中のアドレスが前記トポロジーモデル中の有効なアドレスであるか否かを判断することと、
前記トポロジーモデル中の前記アドレスにおけるモジュールのタイプを決定することと、
前記決定されたモジュールのタイプが前記要求されたデータを提供できるか否かを判断することと、
を含む、請求項１７記載の方法。
【請求項１９】
前記方法は、前記データの外部要求中の前記アドレスが前記トポロジーモデル中の有効なアドレスであり、前記トポロジーモデル中の前記アドレスにおける前記モジュールのタイプが前記要求されたデータを提供できる場合、前記モジュールが前記要求されたテータを提供できる、と判断する、請求項１８記載の方法。
【請求項２０】
前記方法は、複数のクラス中で前記トポロジーモデルを保持することをさらに含み、
読み出し／書き込みロックは、前記クラスそれぞれ中のオブジェクトに置かれており、オブジェクトにおける各読み出し／書き込みロックは、前記オブジェクトに対して変更がなされている間、前記オブジェクトからのデータの読み出しを防ぎ、逆もまた同様である、請求項１５記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、分散制御システム（ＤＣＳ）のためのインタフェースに関し、より具体的には、ＤＣＳのためのインテリジェントインタフェースに関する。
【背景技術】
【０００２】
ＤＣＳは、工業プロセスの制御に専心的なシステムである。システムは、中心に位置しないがその代わりに、プロセス全体にわたって、１以上の制御モジュールによって制御される工業プロセスの各サブプロセスに分散される制御モジュールで構成される。ＤＣＳの他のコンポーネントは、入出力（Ｉ／Ｏ）モジュール及び通信モジュールを含む。ＤＣＳの内のモジュール間の通信は、しばしば所有者のプロトコルを利用する。
【０００３】
所有者の通信プロトコルを備えるＤＣＳに関して、インタフェースは、メンテナンス管理システムまたは監視システムのような外部アプリケーションまたはシステムが、ＤＣＳから情報を得ることができる、及び、そうでなければＤＣＳと通信できるように、しばしば提供される。従来のＤＣＳインタフェースは、ＤＣＳの静的モデルまたは構成を利用する。この構成は、通常「タグ」と呼ばれるデータポイントを使用して手動で構築される。タグは、入力、出力、セットポイント、測定された変数、コントローラ利得、モジュールステータスなどを含む。ＤＣＳ構成のためのタグは、２つの方法のうちの１つで手動で入力される。タグは、直接インタフェースに入力されうる、または、タグは、手動で構築され確認されるエンジニアリングワークステーションデータベースからインタフェースに入力されうる。どちらの方法でも、ユーザは手動でタグを入力し、構成が正確で最新であることを保証しなければならない。構成におけるエラーは制御システムの不適切な動作を引き起こしうるので、このことは、重要である。
【０００４】
前述に加えて、従来のＤＣＳインタフェースは、不適当または無効なコマンドがＤＣＳに送信されることを防ぐ特徴を通常は有していない。したがって、そのようなインタフェースを通じて送信される不適当または無効なコマンドは、ＤＣＳの混乱またはＤＣＳの一部である特定の機器の故障でさえ引き起こすかもしれない。
【０００５】
前述に基づいて、よりＤＣＳを構築しやすく、よりよくＤＣＳを保護する改良されたＤＣＳインタフェースの必要性がある。本発明は、そのようなインタフェースに向けられている。
【発明の概要】
【０００６】
本発明にしたがうと、方法及びインタフェースシステムは、外部アプリケーションを分散制御システム（ＤＣＳ）に接続することで提供される。インタフェースシステムは、コンピュータに方法を実行させるための命令を有するコンピュータ可読媒体を含む。方法にしたがうと、ＤＣＳは、その構成を決定するためにスキャンされる。決定されたＤＣＳの構成は、ＤＣＳのトポロジーモデルを構築するために使用される。ＤＣＳ中のモジュールからのデータの外部要求は、外部アプリケーションから受信される。トポロジーモデルは、モジュールが要求されたデータを提供できるか否かを決定するために使用される。
【０００７】
本発明の特徴、態様及び利点は、以下の記載、添付の請求項及び添付図面に関してよりよく理解されるようになるでしょう。
【図面の簡単な説明】
【０００８】
【図１】図１は、複数の処理制御部を有する第１の分散制御システム（ＤＣＳ）の概略図である。
【図２】図２は、本発明にしたがって具体化され、スマートインタフェースをホストするワークステーションに接続された第１のＤＣＳ及び第２のＤＣＳの概略図である。
【図３】図３は、スマートインタフェースの概略図である。
【図４】図４は、スマートインタフェースのメインルーチンのフローチャートである。
【図５】図５は、スマートインタフェースのループスキャンのサブルーチンのフローチャートである。
【図６】図６は、スマートインタフェースのノードスキャンのサブルーチンのフローチャートである。
【図７】図７は、スマートインタフェースのトポロジーモデルを保存するために使用されるクラス構造である。
【発明を実施するための形態】
【０００９】
以下の詳細な説明では、本発明の別個の実施形態中で示されるか否かに関わらず、同一の構成要素が同一の参照番号であることは、留意されるべきである。さらに、明確かつ簡潔に本発明を開示するために、図面が必ずしも一定の比率で拡大されてないかもしれず、発明のある特徴が多少は略図形式で示されるかもしれないことは、留意されるべきである。
【００１０】
ここで図１を参照すると、本発明が使用されうるＤＣＳ１０概略図が示される。ＤＣＳ１０は、複数のノード１６、１８、２０、２２、２４が接続される１以上のネットワークケーブル１４を備えるループを含む。各ノードは、ループ１２上で他のノードと通信するためのループ１２と接続される１つの電子機器または複数の電子機器を含む。各ノードは、ループの上で一意のアドレスを有し、終端ユニット(termination unit)（ＴＵ）２８によってループ１２と接続される。１つのループだけが図１に示されているが、ＤＣＳ１０が図２に示されるように、ＤＣＳ１０が複数のループを含みうることは理解されるべきである。１つの実施形態では、ループ１２は、１０メガヘルツまたは２メガヘルツの通信レートで作動する一方向の高速シリアルデータネットワークである。
【００１１】
ノード１６、２０は、プロセス制御ユニット(process control units)（ＰＣＵｓ）３０、３２それぞれを含む。以下でより詳細に説明されるように、各ＰＣＵ３０、３２は、発電所、製紙工場、化学プラントあるいは製造プラントのような工業設備中のプロセスまたはサブプロセスを制御するためのネットワーク通信マネージャ（ＮＣＭ）モジュール３５及び１以上のコントローラを含む。ＮＣＭモジュール３５は、パッケージ化するべき出力データについてコントローラを監視し、コントローラに入力データをルーティングし、配信する。各コントローラは、余分かもしれないし、ＰＣＵは、第２のＴＵ２８上のネットワークに付けられた余分のＮＣＭモジュール３５を含むかもしれない。ノード１６、２０の各々は、ＴＵ２８及び１以上のＮＣＭモジュール３５を通じてループ１２に接続されている。
【００１２】
ノード１８、２２は、接続されたオペレーションワークステーション３６、３８それぞれと共にコンピュータインタフェースユニット（ＣＩＵｓ）３４を含む。各ワークステーション３６、３８は、オペレータが設備中のプロセス及びサブプロセスを監視し、手動で制御できるグラフィカルユーザインタフェース（ＧＵＩ）を表示するためのモニタだけでなく、プロセッサ及び関連するメモリを備える。各ワークステーション３６、３８は、それぞれＣＩＵ３４及びＴＵ２８を通じてループ１２に接続されている。ＣＩＵ３４は、ワークステーションから分離されているかもしれず、ワークステーション内に一体化されているかもしれないが、ＤＣＳ１０の一部である。図を簡略化するために、ワークステーション３６、３８と関連付けられたＣＩＵ３４は、ワークステーション３６、３８に一体化されている。以下により詳細に説明されてるように、スマートインタフェースシステム４４は、ワークステーション３８のメモリに格納され、ワークステーション３８の１以上のプロセッサによって実行される。
【００１３】
ＰＣＵ３２は、イーサネット（登録商標）のようなプロトコルを備えたシリアル通信システムでありうる通信バス５２に接続された複数のマイクロプロセッサベースコントローラ５０を含むことができる。各コントローラ５０は、工業設備の１以上のサブプロセス（またはループ）を制御するための１以上の制御プログラム（または構成）を含む。制御プログラムは、１以上のＩ／Ｏサブシステム５４を通じたフィールドデバイスから受信される動作値(operating values)を利用する。各単一のコントローラ５０または余分なコントローラ５０対は、個別のＩ／Ｏサブシステム５４を有することができる。制御プログラムは、５つのＩＥＣ６１１３１−３規格言語：ラダーダイアグラム(Ladder Diagram)、ストラクチャードテキスト(Structured Text)、ファンクションブロックダイアグラム(Function Block Diagram)、インストラクションリスト(Instruction List)及びシーケンシャルファンクションチャート(Sequential Function Chart)の１以上の中で記述されることができる。さらに、制御プログラムは、Ｃのような従来のプログラム言語で記述されることができる。本発明の１つの実施形態では、制御プログラムは、ファンクションブロックダイアグラム中で記述される。制御プログラムからの出力は、Ｉ／Ｏサブシステム５４を通じてフィールドデバイスの制御装置に送信される。Ｉ／Ｏサブシステム５４は、Ｉ／Ｏバス５８に接続された複数のＩ／Ｏモジュール５６を含む。コントローラ５０も、Ｉ／Ｏモジュール５６から動作値を受信するために、Ｉ／Ｏバス５８に接続される。
【００１４】
一般的に、ＰＣＵ３０は、ＰＣＵ３２に類似した構成を有する。つまり、ＰＣＵ３０は、複数のコントローラ、通信バス及びＩ／Ｏサブシステムを有する。
【００１５】
ここで図２を参照すると、本発明の実施形態が示される。ここで、事業体は、（第１の）ＤＣＳ１０及び第２のＤＣＳ７０を有する。さらに、第１のＤＣＳ１０は、（第１の）ループ１２と類似した構成を有する第２のループ６０を備えて示される。つまり、第２のループ６０は、１以上のＰＣＵを有し、それぞれが複数のコントローラ、通信バス及びＩ／Ｏサブシステムを備える。第１及び第２のループ１２、６０は、ブリッジモジュール６２によって接続される。第２のＤＣＳ７０は、ＤＣＳ１０と類似した構成を有する。つまり、ＤＣＳは、１以上のループを有し、それぞれが複数のコントローラ、通信バス及びＩ／Ｏサブシステムを備える。示されるように、ワークステーション３８及びその上で動作するスマートインタフェースシステム４４は、ＤＣＳ１０及びＤＣＳ７０の両方に接続される。
【００１６】
ここで図３を参照すると、１以上の外部アプリケーションとＤＣＳ１０、７０との間のインタフェースを自動的に提供するように動作するソフトウェアシステムであるスマートインタフェースシステム４４の概略的な絵が示される。示されるように、スマートインタフェースシステム４４は、一般的にソフトウェアアプリケーションインタフェース（ＡＰＩ）８０、システムデータアクセス（ＳＤＡ）サーバ８２及びＯＰＣサーバ８４を備える。ＡＰＩ８０は、ＣＩＵ３４中のネイティブ言語コマンドセットへのアクセスを提供するＣ言語サブルーチンのセットを含むローレベルインタフェースである。各ＣＩＵ３４は、（ワークステーション３６または３８のような）マイクロプロセサベース機器またはＰＣＵ（例えば、ＰＣＵ３０または３２）をループ（例えば、ループ１２）に接続する１以上のハードウェアモジュールで構成される。１つの実施形態では、各ＣＩＵ３４は、ネットワークインタフェースモジュール及びコンピュータ転送モジュール(computer transfer module)へのネットワークを含む。この実施形態では、各ＣＩＵ３４は、ブロードキャスト、時間同期、マルチキャスト及びポーリングの４つのメッセージタイプを扱うことができる。さらに、全てのメッセージは、データの完全性を保障するための循環冗長検査符号及びチェックサムを含む。
【００１７】
ＳＤＡサーバ８２は、非常に適合性があり、１または複数のＤＣＳ（例えば、２つ、３つ、４つなどのＤＣＳ）と共に使用されうる。ＳＤＡサーバ８２に接続される各ＤＣＳについて、ＡＰＩアクセス、ＡＰＩコネクタ、ＣＩＵモニタ及びトポロジーファインダ(topology finder)の例が作成される。さらに、ＳＤＡサーバ８２は、ＡＰＩラッパ１９６及びトポロジーモデルデータベース８８を含む。
【００１８】
図３に示される実施形態において、ＳＤＡサーバ８２は、２つのＤＣＳ、すなわち、ＤＣＳ１０及びＤＣＳ７０をインタフェースで連結し、ＤＣＳ１０のためのトポロジーファインダ８５及びＤＣＳ７０のためのトポロジーファインダ８６を含む。各トポロジーファインダは、それに関連するＤＣＳのトポロジーを発見するために、ＳＤＡサーバ８２の起動により作動し、ＤＣＳのトポロジーモデルを生成する。これらのトポロジーモデルは、トポロジーモデルデータベース８８に保存される。トポロジーモデルデータベース８８は、ＳＤＡサーバ８２が接続された全てのＤＣＳのモデルを含む。ＤＣＳは、この場合、ＤＣＳ１０及びＤＣＳ７０を含む。以下により十分に説明されるように、トポロジーモデルデータベース８８は、任意の接続されたＤＣＳと共に生じうる通信のタイプを制御する内部基準として使用される。
【００１９】
トポロジーファインダのメインルーチン９２は、図４に示される。ステップ９６において、メインルーチン９２は、スマートインタフェースシステム４４が属するループ（つまり、ローカルループ）であって、図３の実施形態におけるループ１２であるループを最初にスキャンするための（図５に示される）ループスキャンサブルーチンを引き起こす。ステップ９６の終了後、メインルーチン９２は、ステップ９８に進む。ここで、メインルーチン９２は、ローカルループ（例えば、ループ１２）のノード（例えば、ノード１６−２４）をスキャンするための（図６に示される）ノードスキャンサブルーチン１１２を引き起こす。ローカルループ及びローカルループのノードがスキャンされた後、メインルーチン９２は、ステップ１００に進む。ここで、スキャンすべき他のループがあるか否かチェックがなされる。スキャンすべき他のループがある場合、メインサブルーチンは、次のループ（例えば、ループ６０）に進み、ステップ１０２において、次のループをスキャンするためのループスキャンサブルーチンを引き起こす。ステップ１０２の後、メインルーチン９２は、ステップ１０４に進む、メインルーチン９２は、次のループのノードをスキャンするためのノードスキャンサブルーチンを引き起こす。切断されていると判断されるスキャンすべきループまたはＡＰＩがなくなるまで、ステップ１００−１０４は、繰り返される。いったんＤＣＳ中のループの全てがスキャンされると、ＤＣＳのトポロジーモデルは、完了し、メインルーチン９２は、ステップ１０６に戻る。
【００２０】
メインルーチン９２のループスキャン手順及びノードスキャン手順は、ＤＣＳのトポロジーモデルを更新するために周期的に実行される。予め定められた期間が経過したことをタイマーが示す場合、メインルーチン９２は、上記説明されたループスキャンステップ及びノードスキャンステップを再び実行するために、複数のステップを通じてステップ１０６から、ステップ９６に戻って実行する。
【００２１】
ここで図５を参照すると、ループスキャンサブルーチン１１０のフローチャートが示される。ステップ１１２において、ループスキャンサブルーチン１１０は、本ループについてのループトポロジーレポートを生成する。ループトポロジーレポートは、本ループにおけるノードの全てのリストを含み、各ノードについての識別情報を含む。例えば、識別情報は、ループ上の各ノード（ノード順）のノードのアドレス、ノードのタイプ（例えば、プロセス制御、コンピュータインタフェース、ブリッジインタフェース、イベントのシーケンスまたは他のもの）及び電気的／論理的位置を含むことができる。ステップ１１４において、ループスキャンサブルーチン１１０は、診断動作を実行する。ここで、有効な診断情報は、任意のループに通信問題があるか否かを判断するために検討される。ループの１つに通信問題がある場合、問題は、接続された外部アプリケーションにおけるディスプレイでこの問題が視覚的に確認されうるように、マークが付される（フラグがたてられる）。ステップ１１４の後、ループスキャンルーチンは、トポロジーモデルがループトポロジーレポートを使用して（スキャンが初期スキャンか更新スキャンかに応じて）生成されるまたは更新される一連のステップに進む。
【００２２】
既存のトポロジーモデルにおいて対応するオブジェクトをすでに有していないループトポロジーレポートにおいて任意のノードが発見された場合、新たなオブジェクトは、ノードを表わすために生成され、トポロジーモデルに加えられる。ノードがリモートループへのブリッジである場合、新たなループオブジェクトも生成され、トポロジーモデルに加えられる。
【００２３】
既存のトポロジーモデルにおいて既に表わされているループトポロジーレポートにおいてノードが発見された場合、発見されたノードのタイプは、既存のトポロジーモデルにおけるノードオブジェクトと比較されるでしょう。ノードタイプが一致しない場合、既存のノードオブジェクトは、廃棄され、現在のトポロジーを表わす（ループトポロジーレポートによって表わされるような）新しいノードオブジェクトと置き換えられる。
【００２４】
既存のトポロジーモデルにおけるノードオブジェクトに対応するノードが現在のループトポロジーレポート中にもはや存在しない場合、ステップ１２４において、ノードは、オフラインとしてマークが付される。ユーザ選択可能期間よりも長いオフラインの任意のノードは、永久にＤＣＳから取り除かれるとみなされ、その対応するノードオブジェクトは、ステップ１２６においてトポロジーモデルから取り除かれる。この期間は、プラント条件、つまり、週かもしれないメンテナンス中、通常１０分未満またはノードをリセットするのに必要な時間である通常動作中、によって調節されうる。ノードオブジェクトがトポロジーモデルから取り除かれる場合、以前にそのノードオブジェクトの一部だった全てのモジュールオブジェクトも削除される。
【００２５】
ここで、図６を参照すると、ノードスキャンサブルーチン１１２のフローチャートが示される。ノードスキャンサブルーチン１１２は、そのノードに関連した全てのモジュールについての特定のノードをスキャンする。このスキャンから取得される情報は、スキャンが初期スキャンか更新スキャンかに応じて、トポロジーモデルを生成するまたは更新するために使用される。ノードスキャンサブルーチン１１２は、ノードにおける考えうる各モジュールアドレスにステータス要求メッセージを送信することによって特定のノードをスキャンする。良い応答が特定のアドレスのモジュールから受信される場合、その後、モジュールは、存在し、かつオンラインであると知られる。応答がないまたは悪い応答が受信される場合、その後、ターゲットとされたモジュールは、存在しないと判断される。
【００２６】
ノードスキャンサブルーチン１１２によって発見されるモジュールと同じアドレスのトポロジーモデルにおけるモジュールオブジェクトがある場合、その後、オブジェクト及び発見されたモジュールのモジュールタイプは、比較される。オブジェクトのモジュールタイプが発見されたモジュールと一致しない場合、その後、オブジェクトは、ステップ１３０において削除され、発見されたモジュールを表わすために、ステップ１３２において新たなオブジェクトと取り替えられる。ステップ１３２の一部として、ノードスキャンサブルーチン１１２は、そのモジュールタイプの既知の能力を決定するために、ハードウェア能力データベース２１５中で、発見されたモジュールのモジュールタイプを調べ、トポロジーモジュールデータベース８８中に、トポロジーモデルにおけるモジュールオブジェクトと共に、この情報を保存する。ステータス要求メッセージがトポロジーモデル中のモジュールオブジェクトと同じアドレスでモジュールに送信され、応答がないまたは悪い応答が返信される場合、その後、そのアドレスのモジュールは、ステップ１３４において「オフライン」とマークが付されるでしょう。モジュールがユーザ選択可能期間よりも長いオフラインのままである場合、その後、モジュールは、ＤＣＳから永久に取り除かれるとみなされ、その対応するモジュールオブジェクトは、ステップ１３６においてトポロジーモデルから取り除かれる。この期間は、プラント条件、つまり、週かもしれないメンテナンス中、通常５分未満またはモジュールをリセットするのに必要な時間である通常動作中、によって調節されうる。
【００２７】
新たなモジュールオブジェクトがステップ１３２で生成された後、ノードスキャンサブルーチン１１２は、ステップ１４０に進む。ここで、サブルーチンは、モジュールステータス例外レポートタグ(module status exception report tag) (ModStat XR tag)をサポートできるモジュールが提供され、新たに生成されたモジュールオブジェクトに対応するモジュールについて、ＣＩＵ３４におけるModStat XR tagを生成する。ノードスキャンサブルーチン１１２は、モジュールがモジュールのタイプに基づくModStat XR tagを安全にサポートすることができるか否か判断する。例えば、（コントローラ５０のような）メインコントローラは、ModStat XR tagをサポートできるが、バックアップコントローラ、いくつかの通信モジュール及びＩ／Ｏモジュールはできない。しかしながら、メインコントローラ用のModStat XRからの例外レポートは、コントローラに関連したバックアップコントローラ及びＩ／Ｏモジュールについての情報を含むでしょう。そして、インテリジェント通信モジュールからのModStat XRは、そのペアになったネットワークインタフェースモジュールについての情報を含むでしょう。ModStat XR tagは、重要な情報量がモジュールから集められ、例外レポート中で報告されることを可能にする。そのような情報は、モジュールのタイプ、モジュールの動作状態（例えば、構成する、実行するなど）、モジュールによって使用される様々な通信チャンネルの誤り状態及びモジュールの電源部に関する問題を含む。モジュールからの例外レポートは、接続されているＣＩＵ３４に一時的に保存され、次に集められ、トポロジーモデルに保存される。ＣＩＵ３４において、（プロセス値またはモジュールステータスタグのいずれかの）ポイントからの例外レポートが受信されるとき、以前の例外レポートは、上書きされる。したがって、ＣＩＵ３４は、迅速な状態変化を得るために頻繁にポーリングされる。いくつかの実施形態では、状態とプロセス情報は、例外レポートの代わりにポーリングによって得られる。
【００２８】
トポロジーモデルデータベース８８は、異なるクラスのオブジェクトを使用して、生成され、保存される。ここで、図７を参照すると、トポロジーモデルデータベース８８を保存するために使用されるクラス構造１５０が示される。示されるように、クラス構造１５０は、モデルクラス１５２、ループリストクラス１５４、ノードリストクラス１５６及びモジュールリストクラス１５８を含む。
【００２９】
モデルクラス１５２は、事業体のために全てのトポロジーモデルについての情報を提供し、これらのトポロジーモデルの改良を可能にする。モデルクラス１５２は、事業体における全てのＤＣＳ、ノード及びモジュールについての情報を提供することができ、トポロジーモデルからの先のオブジェクトの追加及び削除を可能にする。モデルクラス１５２は、ＤＣＳクラス１６２への呼(calls)を使用してＤＣＳについての情報を取得し、ループリストクラス１５４への呼を使用して、ループ、ノード及びモジュールについての情報を取得する。
【００３０】
ループリストクラス１５４は、事業体における全てのループ、ノード及びモジュールについての情報を提供し、トポロジーモデルからのループについてのオブジェクトの追加及び削除を可能にする。ループリストクラス１５４は、エンティティリストベースクラス１６０への呼を使用して、ループについての情報を取得し、ノードリストクラス１５６への呼を使用して、ノード及びモジュールについての情報を取得する。
【００３１】
ノードリストクラス１５６は、事業体における全てのノード及びモジュールについての情報を提供し、トポロジーモデルからのノードについてのオブジェクトの追加及び削除を可能にする。ノードリストクラス１５６は、エンティティリストベースクラス１６０への呼を使用して、ノードについての情報を取得し、モジュールリストクラス１５８への呼を使用して、モジュールについての情報を取得する。
【００３２】
モジュールリストクラス１５８は、事業体における全てのモジュールについての情報を提供し、トポロジーモデルからのモジュールについてのオブジェクトの追加および削除を可能にする。モジュールリストクラス１５８は、エンティティリストベースクラス１６０への呼を使用して、モジュールについての情報を取得する。
【００３３】
エンティティリストベースクラス１６０は、エンティティベースクラス１６２を通じて、ループ、ループクラス１６４、ノードクラス１６６及びモジュールクラス１６８それぞれから、ループ、ノード及びモジュールについての情報を取得する。モジュールクラス１６８は、次々に、モジュール定義クラス１７０及びモジュール識別子クラス１７２からモジュールについての詳細な情報を取得する。
【００３４】
トポロジーモジュールは、スレッドセーフ(thread-safe)である。つまり、データは、データに影響を及ぼす変更がなされた場合、データは、読み出されることが許可されず、その逆もまた同様である。クラス構造１５０の構造は、段階的かつ粒状の方法(graduated and granular manner)で実施されるようにこのスレッドセーフを可能にする。より具体的には、読出し／書き込みロックは、クラス構造１５０の各クラスで実施される。したがって、読み出し／書き込みロックは、（１）ＤＣオブジェクトが事業体のトポロジーモデルに対して加えられている、または、削除されている場合、ＤＣＳオブジェクトについての任意の情報が読み出されることを防ぐために、（２）情報がＤＣＳオブジェクトから読み出されている場合、ＤＣＳオブジェクトがトポロジーモデルに対して加えられている、または、削除されていることを防ぐために、モデルクラス１５２におけるＤＣＳオブジェクトで実行される。同様に、読み出し／書き込みロックは、（１）ループオブジェクトが事業体のトポロジーモデルに対して加えられている、変更されている、または、削除されている場合、ループオブジェクトについての情報が読み出されていることを防ぐために、（２）情報がループオブジェクトから読み出されている場合、ループオブジェクトがトポロジーモデルに対して加えられている、変更されている、または、削除されていることを防ぐために、ループリストクラス１５４におけるループオブジェクト上で実施される。クラスの階層の下の方まで続け、同様の読み出し／書き込みロックは、ノードリストクラス１５６、及びモジュールリストクラス１５８それぞれにおけるノードオブジェクト及びモジュールオブジェクトに置かれる。ループクラス１６４、ノードクラス１６６及びモジュールクラス１６８における読み出し／書き込みロックは、より一層の粒状のロック能力(granular locking capabilities)を提供する。例えば、読み出し／書き込みロックは、（１）モジュールが構成されているまたは更新されている場合、モジュールについての任意の情報が読み出されることを防ぐために、（２）モジュールが読み出されている場合、モジュールが構成されている、更新されているまたは削除されていることを防ぐために、モジュールクラス１６８の各オブジェクトの例で実行される。
【００３５】
前述から、クラス構造１５０の構成がＳＤＡサーバ８２の動作を不当に妨害することなしに、スレッドセーフティを提供することは、理解されるべきである。より詳細には、構成は、ロックされる必要のあるＤＣＳのその部分にのみ向けられるべき読み出し／書き込みロックを可能にする。例えば、ＤＣＳのループにおける２つの異なるノードにおける２つのモジュールのみがロックされる必要がある場合、例えば、これらが構成されているので、ロックは、両方のノードの代わりにこれら２つのモジュールで、ループ全体でまたはＤＣＳ全体でのみ実施される。これは、モデルオブジェクトが単純な階層手法で配置されている場合のケースであろう。
【００３６】
図３に戻って参照すると、トポロジーモデルデータベース８８及びトポロジーファインダ８５、８６に加えて、ＤＣＳ１０，７０についてのＳＤＡサーバ８２の実施形態は、ＡＰＩコネクタ１８０、ＣＩＵ３４ａについてのＡＰＩアクセス１８２及びＣＩＵモニタ１８４、及びＣＩＵ３４ｂ（ＤＣＳ１７０）についてのＡＰＩコネクタ１８８、ＡＰＩアクセス、ＣＩＵモニタ１９２を備える。
【００３７】
各ＡＰＩコネクタ１８０、１８８は、ＡＰＩ８０を介してその関連するＣＩＵ３４への接続を確立し、閉じる。さらに、各ＡＰＩコネクタ１８０、１８８は、その関連付けられたＣＩＵ３４におけるポイントデータベースについて使用されるインデックスを割り当てて追跡するポイントマネージャオブジェクトを含む。ＣＩＵ３４が再開されるときはいつでも、その関連付けられたＡＰＩコネクタにおけるポイントマネージャオブジェクトが削除され、ポイントデータベースをクリアするＣＩＵ３４を再開して以来新たなものが生成される。
【００３８】
各ＣＩＵモニタ１８２、１９２は、その関連付けられたＣＩＵ３４中での接続を確立し、維持し、再開するように、その関連付けられたコネクタと相互作用する。さらに、ＣＩＵモニタは、設定された間隔で、接続の状態をチェックする。各実行サイクル中に、ＣＩＵモニタは、その関連付けられたＣＩＵ３４から例外レポートを検索し、その関連付けられたＡＰＩコネクタの状態をチェックするでしょう。その関連付けられたＡＰＩコネクタがオフラインまたは分離されているとして見つけられる場合、ＣＩＵモニタは、ＡＰＩコネクタとＣＩＵ３４との間の接続を再確立しようとするでしょう。
【００３９】
各ＡＰＩアクセス１８２、１９０は、制御される方式で、その関連付けられたＣＩＵ３４及びＡＰＩ８０を通じて、要求を送信し、その関連付けられたＤＣＳから応答を受信する。ＡＰＩアクセスは、ＣＩＵ３４以外の通信モジュール及びＡＰＩ８０以外のソフトウェアアプリケーションインタフェースと使用可能となるように容易に改良できうる。さらに、ＡＰＩアクセスも、ＣＩＵ３４及びＡＰＩ８０を介して、ＤＣＳから診断データを取り出し可能である。診断データは、メモリ使用量、エラーカウンタ、通信メトリック、ファームウェアレベル、プログラム実行メトリック、エラー状態を含む。ＡＰＩアクセスは、関連付けられたＡＰＩコネクタに対する参照（ポインタ）を有するが、ＡＰＩコネクタ上でステータス読み出し及び更新のみを実行する。ＡＰＩアクセスは、通信のレートを制御するスロットリングメカニズム(throttling mechanism)を使用して、要求を送信する。スロットリングメカニズムは、要求の開始の間に必要な時間であるポーリング期間を使用する。（ＡＰＩアクセスに対する呼が開始された時から計測して）以前の第１の呼のポーリング期間が経過する前に、第２の呼が第２の要求を発するＡＰＩアクセスに対してなされる場合、第２の要求は、第１の呼のポーリング期間が経過するまで遅延されるでしょう。さらに、以前の第１の要求が完了する前に第２の要求についての第２の呼がＡＰＩアクセスに対してなされる場合、読み出し／書き込みロックは、第１の要求が完了するまで、第２の要求（及び任意の後の要求）が送信されることを防ぐ。第１の要求が完了するとき、読み出し／書き込みロックは、ポーリング期間が経過する時に解除され、次のインラインスレッド(in line thread)へ有効にされるでしょう。
【００４０】
ＳＤＡサーバ８２の要素（クラス）は、マイクロソフトの.NETイニシアチブのコア要素である共通言語ランタイム(Common Language Runtime)(CLR)を利用する。ＣＬＲにおいて、コードは、共通中間言語(Common Intermediate Language)(CIL)と呼ばれるバイトコードの形式で表される。ＳＤＡサーバと対照的に、ＡＰＩ８０は、従来の「Ｃ」ライブラリを使用する。したがって、ＡＰＩラッパ(API wrapper)１９６は、提供され、ＡＰＩコネクタ１８０、１８８及びＡＰＩアクセス１８２、１９０に接続されている。ＡＰＩラッパ１９６は、ＳＤＡサーバ８２の要素からの要求をＡＰＩ８０への伝達のために従来「Ｃ」の呼に翻訳し、ＡＰＩ８０から受信された従来の「Ｃ」構造、アレイ及びポインタを、ＳＤＡサーバ８２の要素によって使用される従来の.NETデータタイプに翻訳する。
【００４１】
ウェブサーバアプリケーション２００は、シンプルオブジェクトアクセスプロトコル(Simple Object Access Protocol)(SOAP)を使用して、ＳＤＡサーバ８２を任意のウェブクライアントに接続するために提供される。しかしながら、ウェブサーバアプリケーション２００とクライアントとの間の通信は、暗号化される。さらに、ウェブサーバへのクライアントの接続は、ＳＤＡサーバ８２をホストするサーバ（例えば、ワークステーション）上のローカルアカウントとして接続することにより認証されるべきである。
【００４２】
ＳＤＡサーバ８２は、ウェブサーバアプリケーション２００によって受信されるデータ要求を扱うことができ、ＤＣＳにおける多数のターゲットからの情報を要求できる。そのようなマルチターゲットデータ要求は、通常は、診断であり、各ターゲット（例えば、ブロック読み出し(block read)からの単一のフロート値(single float value)）からの少量のデータのみを必要とする。要求された動作は、各ターゲット用に実行され、全ての要求された動作の結果は、同時に、関係するＡＰＩアクセス（１８２または１９０）に戻される。要求中に複数のターゲットを指定することは、要求が完了し、結果が戻されうる前に、時間を延長するでしょう。しかし、それは、より少ない往復及びそれによるオーバヘッドに帰着するでしょう。これは、さもなければ多くの読み出しがとても短い時間に必要とされるであろう、及び結果として生じるデータがとても小さいであろう（例えば、コントローラモジュールからの要求されるブロック読み出しが複数のリクエストに代えてウェブサーバアプリケーション２００への単一の要求でなされうる）という場合に有益である。指定されうるターゲットの数は限られておらず、合理的な要求をなすことは、クライアントアプリケーション次第である。スロットリングが適切なＡＰＩアクセスによって実行されるので、多数のターゲットを備える要求は、ＣＩＵ３４をフロードさせないでしょう。
【００４３】
大量のデータ（例えば、ループトポロジーレポート）を要求するウェブサーバアプリケーション２００対する診断データ要求は、概して、ＤＣＳ中の単一のターゲットにのみ向けられる。
【００４４】
ＯＰＣサーバ８４は、ＯＰＣ  ＵＡを介したＳＤＡサーバ８２からのデータを公表するように動作可能であり、ＴＣＰとＨＴＴＰ  ＯＰＣ  ＵＡ通信スタックとの両方を使用して接続をサポートする。ＯＰＣサーバ８４は、読み出しを実行し、（動作を実行するのに必要な）呼を機能させ、サブスクリプション(subscription)２０６を提供する。ＯＰＣサーバ８４は、カスタムノードマネージャ２１０及びカスタムオブジェクトタイプ(custom object types)、カスタム複合変数タイプ(custom complex variable types)、カスタム一覧(custom enumerations)及び方法を含むカスタムＯＰＣデータモデル２１２を実施する。
【００４５】
ＯＰＣサーバ８４は、２つのインタフェースを通じてＳＤＡサーバ８２に接続する。自発的に発見され、ＳＤＡサーバ８２によって監視された（例外レポートのような）データは、ランタイムメインインタフェース２１４を通じてＯＰＣサーバ８４に押し出される。ＳＤＡサーバ８２からポーリングされるべきデータは、ウェブサーバアプリケーション２００を通じて取り出される。
【００４６】
ＯＰＣサーバのカスタムノードマネージャ２１０は、随意的に、ヒストリアン(historian)のために、データを記録するためのＩＸデータハンドラースレッド(IX data handler thread)を立ち上げることができる。記録された情報は、ＯＰＣサーバ８４またはクライアントサブスクリプションに対する読み出し要求を満たすために、必要とされる任意の診断データだけでなく、全ての発見されたトポロジー情報及び変更、例外レポートを含むであろう。
【００４７】
ＯＰＣサーバのカスタムノードマネージャ２１０は、随意的に、ユーザが明らかにさらされることを望むプロセスタグを安全に構成することを可能にするユーザタグマネージャ８７コンポーネントを利用できる。ユーザタグマネージャ８７は、データベースからユーザ定義タグ情報をロードする。ＤＣＳ（例えば、ＤＣＳ１０または７０）におけるモジュールが発見されるので、プロセスデータについてのタグをサポートするいくつかのモジュールは、見つけられることができ、識別されることができる。このような場合において、ノードマネージャ２１０は、発見されたモジュール中にユーザがタグを明らかに設定したか否かを判断するために、ユーザタグマネージャ８７をチェックする。もしそうであれば、これらのタグは、ポーリングまたは例外レポートの何れかにより、ＯＰＣサーバ８４を通じて、ユーザにさらされる。ＯＰＣノードマネージャ２１０は、ＤＣＳにおけるポイントをセットするために、または、ユーザ定義タグについてモジュールから値を集めるために、それに命令するために、ＳＤＡサーバ８２に要求をする必要があるでしょう。これらの要求の各々は、ターゲットモジュールが要求された動作の能力があること、及びそれがその動作をサービスできる状態にあることを確実にするために、ＳＤＡサーバ８２によって選別されるでしょう。したがって、ユーザは、システム中で通信問題を引き起こすであろう無効なタグを構成できない。ＤＣＳが全てのデータを単一のＣＩＵ３４にルーティングできないかもしれない、または、適時に単一のＣＩＵ３４に全てのプロセスデータについての更新を提供できないかもしれないので、ユーザは、プロセスデータが外部アプリケーションに配信されることを確実にするために、特定の外部アプリケーションに、重要なプロセスデータについてのタグを手動で設定する。
【００４８】
ここで、スマートインタフェースシステム４４の動作は、ＤＳ１０に関して説明されるでしょう。スマートインタフェースシステム４４（及び特定のＳＤＡサーバ８２）の開始により、トポロジーファインダ８５は、ＤＣＳ１０のトポロジーを発見し、それをトポロジーモデルデータベース８８に加える。構造化可能なトポロジーモデルデータベース８８は、所定間隔に応じて、周期的に更新される。ウェブサーバアプリケーション２００がＤＣＳ１０における（特定のアドレスの）特定のモジュールデータについての要求を受信したとき、この要求は、アドレス（ループ、ノード、モジュールなど）が有効か否か、及び要求されたそのデータがアドレスにおける特定のモジュール及び／またはノードから取得されうる（すなわち、それによってサポートされる）か否かを決定するために、トポロジーモデルデータベース８８に送られる。トポロジーモデルデータベース８８がそのアドレスが有効で、要求されたデータがそのアドレスのモジュールから取得されうると判断する場合、要求は、ＡＰＩラッパ１９６、ＡＰＩ８０及びＣＩＵ３４ａを通じて、任意の必要とされるスロットリングの対象となるモジュールからデータを取得するための要求で動作するＡＰＩアクセス１８２に送られる。モジュールからの要求されたデータは、その後、ＣＩＵ３４ａ、ＡＰＩ８０、ＡＰＩラッパ１９６及びＡＰＩアクセス１８２を通じて、ウェブサーバアプリケーション２００に返送される。
【００４９】
スマートインタフェースシステム４４は、多くの利益をもたらす。有効なＤＣＳ構成がインタフェースに存在することを保証することをユーザに頼る代わりに、スマートインタフェースシステム４４は、ランタイムで自己構築するために、ＤＣＳ構成要素の自動発見を使用する。このことは、スマートインタフェースシステム４４に置かれるＤＣＳ機器が識別され、実際に存在することを意味する。ユーザは、存在しない機器またはアクセスされた場合にシステム混乱を引き起こすであろう機器にタグを設定する、または、コマンドを発するオプションを有していない。これは、さらに、手動でＤＣＳ構成を確認することの困難なタスクからユーザを開放し、スマートインタフェースシステム４４が存在するシステムで早期に配置されることを可能にする。
【００５０】
さらに、ＤＣＳの発見及び自己構築は、ＤＣＳにおける任意のターゲット機器によってサポートされていないブロックコマンドに使用されうる。さらに、いくつかのコマンドが機器の特定のモジュールでのみサポートされているので、これは、ユーザが機器にサポートされていないコマンドを発することを防ぐことにより、ＤＣＳを保護する。ユーザ要求をサービスするための任意のコマンドがＤＣＳに出される前に、検査は、発見された構成におけるターゲット機器について実行され、それは、各機器の能力の知識を含む。コマンドがターゲット機器によってサポートされていない場合、ユーザは、要求を中断する。
【００５１】
スマートインタフェースシステム４４のさらなる利益は、スマートインタフェースシステム４４がＤＣＳで置かれているロードに帰着する要求を調節することである。ＤＣＳに発せられているコマンドに帰着し、確認要求(validation requirements)を渡す全ての要求は、ＤＣＳへの際立ったユーザ要求を制限し、最大の要求レートを実行するスロットリングメカニズムの対象とされている。起こされた新たな要求は、これらの必要条件を満たすためにスロットリングメカニズムによって保持され、遅延させられうる。これは、不正を働くクライアントアプリケーション、または、さもなければ膨大なサポートされたコマンドを備えるＤＣＳを混乱させるクライアントアプリケーションを偶発的にまたは故意に構成し、または使用しようとするユーザに対してさらに強固にされるインタフェースシステムに帰着する。
【００５２】
先の例示的な実施形態の記載が完全なものではなく本発明の単なる例証となるように意図されることは、理解されるべきである。当業者は、添付された請求項によって定義されているように、発明の趣旨またはその範囲を逸脱することなく、開示された内容の実施形態に対する特定の追加、削除及び／または改良をすることができるであろう。
【図１】
2013542524.tif 000003
【図２】
2013542524.tif 000004
【図３】
2013542524.tif 000005
【図４】
2013542524.tif 000006
【図５】
2013542524.tif 000007
【図６】
2013542524.tif 000008
【図７】
2013542524.tif 000009
【国際調査報告】
2013542524.tif 000010
2013542524.tif 000011
2013542524.tif 000012