JP2010537513A - タイプデバイスのデバイスタイプマネージャ内におけるネットワークスキャニングおよびマネージメント - Google Patents

Abstract

フィールドデバイスツール（ＦＤＴ）フレームワークを使用して、デバイスと通信する方法において、デバイスは、プロセス制御環境内で動作し、通信リンクと通信可能に結合され、この方法は、ＦＤＴフレームワーク内のデバイスを表すタイプデバイスのスキャン可能なデバイスタイプマネージャ（ＤＴＭ）のインスタンスを生成するステップと、スキャン可能なＤＴＭのインスタンスを、通信リンクに対応する通信チャネルに通信可能に接続するステップと、スキャン可能なＤＴＭのインスタンスを使用して、デバイスを発見するために、通信リンクをスキャンするステップと、スキャン可能なＤＴＭにおける発見されたデバイスのアドレスを取得するステップとを含む。
【選択図】図３

Description

本発明は、２００７年８月１６日に出願された、「Ｎｅｔｗｏｒｋ Ｓｃａｎｎｉｎｇ ａ ｎｄ Ｍａｎａｇｅｍｅｎｔ ｉｎ ａ Ｄｅｖｉｃｅ Ｔｙｐｅ Ｍａｎａｇｅｒ ｏｆ Ｔｙｐｅ Ｄｅｖｉｃｅ」と題する米国特許仮出願第６０／９５６，３２８号に基づく優先権を主張し、当該米国特許仮出願の開示は、本明細書に明示的に参照として組み込まれる。

本開示は、一般には、プロセス制御環境でデバイスを管理することに関し、具体的には、フィールドデバイスツール（ＦＤＴ）のフレームワークで動作するデバイスタイプマネージャ（ＤＴＭ）のスキャン機能に関する。

化学プロセス、石油プロセスまたはその他のプロセスで使用されるようなプロセス制御システムは、典型的には、１つまたは複数の集中型プロセスコントローラまたは非集中型プロセスコントローラを含み、これらのプロセスコントローラは、アナログバス、デジタルバスまたは結合型アナログ／デジタルバスを介して、少なくとも１つのホストまたはオペレータワークステーション、ならびに、たとえばフィールドデバイスなどの１つまたは複数のプロセス制御装置および計装装置に通信可能に結合される。たとえば、バルブ、バルブポジショナ、スイッチ、トランスミッタ、およびセンサ（たとえば、温度センサ、圧力センサ、および流量センサ）とすることができるフィールドデバイスは、プロセスプラント環境内に配置され、バルブの開閉、プロセスパラメータの測定、流体流れの増減などのプロセスにおいて機能を実行する。また、ＦＯＵＮＤＡＴＩＯＮ（商標）Ｆｉｅｌｄｂｕｓ、Ｄｅｖｉｃｅ−Ｎｅｔ（商標）またはＨＡＲＴ（登録商標）などの周知のプロトコルに適合するフィールドデバイスなどのスマートフィールドデバイスは、通常はプロセスコントローラ内で実施されるコントロール計算、アラーム機能およびその他のコントロール機能を実行できる場合もある。

典型的にはプロセスプラント環境内に配置されるプロセスコントローラは、プロセス計測値またはフィールドデバイスによるもしくはフィールドデバイスと関連付けられるプロセス変動値を示す信号および／あるいはフィールドデバイスに関係するその他の情報を受信し、コントローラアプリケーションを実行する。このコントローラアプリケーションは、たとえばプロセス制御決定を行う様々なコントロールモジュールを実施し、受信された情報に基づいてコントロール信号を発生し、ＨＡＲＴ（登録商標）およびＦｉｅｌｄｂｕｓフィールドデバイスなどのコントロールモジュールまたはブロックと連携する。プロセスコントローラ内のコントロールモジュールは、制御信号を、通信線または信号経路を介してフィールドデバイスに送信し、それによりプロセスのオペレーションが制御される。

フィールドデバイスおよびプロセスコントローラからの情報を、典型的には、たとえば、オペレータワークステーション、メンテナンスワークステーション、パーソナルコンピュータ、ハンドヘルドデバイス、データヒストリアン、レポートジェネレータ、集中型データベースなどの１つまたは複数のその他のハードウェアデバイスに利用できるようにして、オペレータまたはメンテナンス担当者が，たとえば、プロセス制御ルーチンの設定を変更する、プロセスコントローラまたはスマートフィールドデバイス内のコントロールモジュールのオペレーションを修正する、プロセスプラント内の特定のデバイスのプロセスまたはステータスの現在の状態を閲覧する、フィールドデバイスおよびプロセスコントローラによって発生されたアラームを閲覧する、担当者の訓練またはプロセス制御ソフトウェアのテストを目的としてプロセスのオペレーションをシミュレーションする、あるいはプロセスプラント内の問題またはハードウェア故障を診断するなど、プロセスに関する所望の機能を実行できるようになる。

プロセス制御産業に対してＦｉｅｌｄｂｕｓ技術および関連する規格が最近導入された
ことにより、フィールドデバイス、プロセスコントローラ、マルチプレクサ、ワークステ
ーション、およびプラントのその他の設備を、単一のネットワーク中に接続することが可能になった。概して、Ｆｉｅｌｄｂｕｓは、複数のデバイスをワイヤの単一の対に接続できるようにすることによって、実時間分散制御に関する基礎を提供するが、このワイヤの単一の対は、次いで、コントローラ、コンピュータホスト、またはその他のインテリジェントホストに接続することができる。しかしながら、Ｆｉｅｌｄｂｕｓの効果は、Ｆｉｅ ｌｄｂｕｓ通信を指定する数多くのプロトコル規格によって大幅に制限される。たとえば、ＨＡＲＴ（登録商標）またはＣＡＮなどのその他のタイプの通信プロトコルに加えて、現在、Ｆｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓ（ＦＦ）およびＰＲＯＦＩＢＵＳのような競合するＦｉｅｌｄｂｕｓプロトコルが存在する。さらに、Ｆｉｅｌｄｂｕｓ線に接続するために追加のハードウェアを必要とする数多くのオペレーションで従前から使用されてきた４−２０ｍＡデバイスが存在する。

数多くの製造業者が、フィールドデバイスおよび典型的には一部の既存のプロトコルにのみ適合するその他のプロセス制御ハードウェアコンポーネントを製造する。さらに、デバイスは、特定の構成およびパラメータ表示を必要とすることが多く、各製造業者は、さらなる構成上の要件を課されることがある。したがって、オペレータおよびメンテナンス担当者は、多くの場合、これらのデバイスと通信し、構成機能、診断機能およびメンテナンス機能を実行するために、数多くのプロトコル特有のツール、製造者特有のツールおよびデバイス特有のツールを必要とする。その結果、オペレータワークステーションまたはポータブルデバイスは、多くの互換性のないツールを含むことがあり、オペレータが、これらのツールを習得し、プロセス制御ネットワークの特定の限定された部分またはネットワークのオペレーションの限定された態様にこれらのツールを選択的に適用するために費やす時間は、かなりの量になる場合がある。

近年、フィールドデバイスツール（ＦＤＴ）仕様を導入することによって、プロセスデータ、文書、デバイス構成およびヒューマン−マシンインターフェース（ＨＭＩ）の不一致の問題に対処するための動きがあった。ＦＤＴは、様々なインターフェースおよび単一のソフトウェアフレームワークを規定することによって、エンドユーザに、異機種環境にあるフィールドデバイスおよびその他のプロセス制御コンポーネントと通信する統合された方法を提供することを目的とする。具体的には、多くの主要製造業者を含む共同出資グループは、公に利用できる一連のインターフェース定義に同意し、様々な高レベルアプリケーションの開発のためにソフトウェアプラットフォームを選択してきた。ＦＤＴに関する追加の情報は、ｗｗｗ．ｆｄｔ−ｊｉｇ．ｏｒｇで見出すことができる。ＦＤＴ自体は、いずれの既製のツールも提供しないが、ＦＤＴは、アセットマネージメント、デバイス構成、あるいはプロセス制御のシミュレーションおよび診断のような多種多様な目的のために、いわゆるフレームワークアプリケーションを開発するためのツールセットを提供する。

ＦＤＴは、フレームワークアプリケーションがＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ベースのコンピュータで動作できるようにするための複数の安定した規格および技術に依拠する。具体的には、ＦＤＴは、Ｍｉｃｒｏｓｏｆｔの言語非依存型でオブジェクト指向の開発に関するコンポーネントオブジェクトモデル（ＣＯＭ）、データ交換に関する拡張マークアップ言語（ＸＭＬ）および、グラフィカルインターフェース定義に関するＡｃｔｉｖｅＸ技術に依拠する。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）環境に精通した人にはわかるように、ＣＯＭにより、プログラミング言語にかかわりなく、動的オブジェクト作成が可能になり、かつ、プロセス間通信できるようになる。さらに、ＣＯＭオブジェクトは、明確に定義されたインターフェースを通じて、自身の機能および属性を明らかにする。グラフィカルユーザインターフェース（ＧＵＩ）を提供することを目的として、ＦＤＴ規格は、強制的にＡｃｔｉｖｅＸを使用する。ある態様では、ＭｉｃｒｏｓｏｆｔのＡｃｔｉｖｅＸは、Ｗｉｎｄｏｗｓ（登録商標）環境におけるグラフィカルインターフェース、ユーザインプットインターフェースおよびデータ交換インターフェースを具体的には指向するＣＯＭ規格の拡張である。最終的には、ＦＤＴは、データ定義のために多くの産業およびアプリケーションで幅広く使用されるオープンスタンダードであるＸＭＬを使用する。ＸＭＬは、タグのセットを通じて、データ構造のタイプおよび境界を規定する語彙規則を提供する。ウェブ開発のような関連分野に精通した人にはわかるように、適切に形成されたＸＭＬドキュメントは、人間と機械の両方で読み取り可能である。ＸＭＬにより、ユーザ指定のタグを利用して簡単に拡張できるようにもなることが重要である。

ＦＤＴは、たとえばＦＤＴフレームワークアプリケーションおよびデバイスタイプマネージャ（ＤＴＭ）などのオブジェクト間の通信ルールを規定するために、ＸＭＬを使用する。ＤＴＭは、デバイス特有のアプリケーションソフトウェアを含むソフトウェアコンポーネントである。一般的なＣＯＭ原理にしたがって、ＤＴＭは、ＦＤＴフレームワークのルールに適合するインターフェースのセットを有するバイナリオブジェクトである。典型的には、デバイス製造業者は、特定のデバイスタイプに関するＤＴＭを提供し、それによりＤＴＭはプロセス制御アプリケーション、アセットコントロールマネージメントソフトウェア、またはその他のタイプの開発中のＦＤＴアプリケーションにプラグインできる。このＤＴＭは、ユーザダイアログおよびインターフェース、ならびに対応するデバイスに関するルールを含み、また多くの場合にはデバイスを参照できるアプリケーションに関するヘルプコンテンツを含む。

ＤＴＭは、デバイスのタイプまたはＦＤＴ環境でＤＴＭが表すハードウェアタイプにしたがって、複雑に変化する。各製造業者は、ＤＴＭを別々に実施することを選択できるが、最低でも、各ＤＴＭが必須のインターフェースを実装する。一部の製造業者は、それに加えて、高度な較正機能、診断機能、テスト機能およびメンテナンス機能を、ＤＴＭの一部として提供する。さらに、一部の製造業者は、多言語サポートをＤＴＭに提供して、ＤＴＭを任意のＦＤＴフレームワークアプリケーションに容易に統合できるようにする。

ＦＤＴフレームワークアプリケーションによって使用される複数のタイプのＤＴＭオブジェクトが存在する。たとえば、タイプデバイスのＤＴＭ（本明細書では、「デバイスＤＴＭ」と呼ばれる）は、フィールドデバイスを示し、通信ＤＴＭは、通信リソースへの直接アクセスを有するモジュールに対応する。したがって、Ｅｍｅｒｓｏｎ ＰｒｏｃｅｓｓＭａｎａｇｅｍｅｎｔ（商標）によって販売されるＤＶＣ６０００シリーズのデジタルバルブコントローラは、ＦＤＴインターフェースを介してＨＡＲＴモデムを示す通信ＤＴＭと通信するデバイスＤＴＭによって示すことができる。より具体的には、たとえばオペレータワークステーションで動作するフレームワークアプリケーションは、特定のデバイスＤＴＭクラスのオブジェクトおよび特定の通信ＤＴＭクラスのオブジェクトをインスタンス化する。ＦＤＴ環境では、デバイスＤＴＭは、ある特定の通信ＤＴＭでサポートされるプロトコルの仕様を「認知」しておらず、一方その通信ＤＴＭは、デバイスＤＴＭの詳細を「認知」していない。構成、診断またはその他のタイプのオペレーションの間、デバイスＤＴＭは、対応するコマンドパラメータを有するコマンドを通信ＤＴＭに送信することができ、通信ＤＴＭは、次いで、プロトコル要件にしたがってコマンドをフォーマットし、データをオペレータワークステーションの適切なインターフェースに伝播する。つまり、デバイスＤＴＭは、デバイス特有の機能を包含し、通信ＤＴＭは、プロトコル特有の機能を包含する。また、デバイスＤＴＭは、フレームワークアプリケーションのビルトインチャネルを使用して、対応する物理デバイスと通信し、あるいは、ビルトインチャネルおよび１つまたは複数の通信ＤＴＭによって提供されるチャネル機能の両方を使用することができる。

さらに、ゲートウェイＤＴＭは、異なるプロトコル間のルーティングを提供する。たとえば、ゲートウェイＤＴＭは、ＰＲＯＦＩＢＵＳからＨＡＲＴへの変換を提供することができる。いくつかの場合、ゲートウェイＤＴＭは、プロトコル変換に加えて、またはそれに代えて、フィールドデバイスと通信ハードウェアとが容易に協働できるようにするその他の機能を提供することができる。ある特定の実施形態において、ゲートウェイＤＴＭを、デバイスＤＴＭおよび通信ＤＴＭに接続することができる。その他の実施形態では、ゲートウェイＤＴＭは、異なるプロトコルまたは通信スキームをそれぞれがサポートする２つの通信ＤＴＭを接続することができる。さらに、たとえばＦＤＴアプリケーションを外部アプリケーションに接続するような必要性のために、その他のＤＴＭタイプを開発することができる。

既存のＦＤＴ／ＤＴＭ環境によって提供されるインターフェースおよび機能は、典型的には、別個のＤＴＭが各物理デバイスのためにインスタンス化されることを必要とする。さらに、デバイスＤＴＭは、通信ＤＴＭの１つの通信チャネルにのみ接続することができる。したがって、ＦＤＴ仕様は、技術者およびオペレータにソフトウェアツールの強力なセットを提供し、大型プロセス制御システムに関するＦＤＴフレームワークアプリケーションの開発および構成は、時間がかかり難しいタスクとなる場合がある。具体的には、オペレータは、対応する物理デバイスのアドレスを有する各デバイスＤＴＭを構成しなければならない。さらに、複数のデバイスが構成パラメータの多くを共有する場合であっても、各デバイスの構成は、別々にプロセスを実行しなければならない。たとえば、複数の類似のデバイスが単一のＦＦ Ｈ１接続に常駐する場合、各デバイスＤＴＭは別々にインスタンス化され、適切な物理アドレスで構成され、かつ、動作する前にさらに構成されなければならない。

スキャン可能なデバイスＤＴＭモジュールは、ＦＤＴ環境内のデバイスを示し、ＤＴＭにより、所与の通信チャネル上の特定のタイプの１つまたは複数のデバイスを識別および管理できるようになるスキャン機能を含む。スキャン可能なデバイスＤＴＭは、通信ＤＴＭに接続し通信ＤＴＭによってサポートされるプロトコルの既知のコマンドを使用して標的アドレス範囲をポーリングする。一実施形態において、スキャン可能なデバイスＤＴＭ は、特定のアドレスにおけるデバイスの有無を検出する。別の実施形態では、スキャン可能なデバイスＤＴＭはさらに、発見されたデバイスのそれぞれから、デバイス特有の情報を取得する。スキャン可能なデバイスＤＴＭにより、物理デバイスのアドレスを手動で入力する必要がなくなる。その代わり、スキャン可能なデバイスＤＴＭは、１つまたは複数の通信ＤＴＭを介して、許容可能なアドレス範囲をスキャンすることによって、マッチング物理デバイスを自動的に発見する。

別の態様において、スキャン可能なデバイスＤＴＭの単一のインスタンスを使用し、複数の物理デバイスを同時にサポートすることができる。スキャン可能なデバイスＤＴＭは単一の物理アドレスに限定されないので、スキャン可能なデバイスＤＴＭは、いくつかのデバイスアドレスを発見および保存することができ、同じタイプの複数の別個のデバイスとの通信を維持することができる。具体的に、ＦＤＴの外部であるが、特定のＦＤＴフレームワークアプリケーションと協働するアプリケーションは、スキャン可能なデバイスＤＴＭの単一のインスタンスを使用して、いくつかのフィールドデバイスとの通信を確立することができる。

１つの態様において、スキャン可能なデバイスＤＴＭは、共同出資グループによって規定されるＦＤＴ仕様に適合する。これに関して、スキャン可能なデバイスＤＴＭは、ＦＤＴフレームワークアプリケーションと完全に互換性がある。一実施形態において、スキャン可能なデバイスＤＴＭは、デバイスＤＴＭを特定のデバイスに交換し、デバイス製造業者によって、特定のデバイスに対する交換ＤＴＭとして提供され得る。交換ＤＴＭは、対応するデバイスに対するデバイスＤＴＭの全機能を、さらに本開示の教示にしたがって実施されるスキャン機能を含むことができる。別の実施形態では、スキャン可能なデバイスＤＴＭは、ＦＤＴフレームワークの外部で動作するアプリケーションを、ＦＤＴフレームワーク内部の通信ＤＴＭに接続する。外部アプリケーションは、デバイス特有の機能を既にサポートすることができ、スキャン可能なデバイスＤＴＭは、発見機能を外部アプリケーションに提供している場合があり、外部アプリケーションとＦＤＴフレームワークとの間の接続としても機能することができる。

１つの態様において、スキャン可能なデバイスＤＴＭのスキャン機能は、特定のチャネルに関連付けられたデバイスアドレスの許容可能な範囲でプログラムされる。スキャン可能なＤＴＭは、さらに、デバイス特有のポーリングコマンドまたはプロトコル特有のポーリングコマンドでプログラムされる。一実施形態では、スキャン可能なデバイスＤＴＭは、コマンドを、有効アドレスのそれぞれに送信し、応答を聞く。別の実施形態では、スキャン可能なデバイスＤＴＭは、ブロードキャストコマンドまたはマルチキャストコマンドを使用して、特定のアドレス範囲を目的とする。一実施形態では、スキャン可能なデバイスＤＴＭは、特定のチャネルに接続される全てのデバイスをポーリングする。別の実施形態では、スキャン可能なデバイスＤＴＭは、たとえば、バルブコントローラＤＶＣ６０００などの特定のデバイスタイプについてポーリングする。さらに別の実施形態にしたがって、スキャン可能なデバイスＤＴＭは、外部アプリケーションを介して、またはＦＤＴフレームワーク内のユーザダイアログを介して、ユーザ入力を受け入れることができ、ユーザによって入力されたアドレス範囲をスキャンすることができる。また、スキャン可能なデバイスＤＴＭは、ＦＤＴフレームワーク内の、および／または外部アプリケーションを介して、スキャンの結果も表示することができる。

別の態様において、スキャン可能なデバイスＤＴＭは、外部アプリケーションへの再接続機能を提供する。物理デバイスとの接続が途切れた場合、スキャン可能なデバイスＤＴＭは、外部アプリケーションが物理デバイスに到達しようとした後に、接続を回復しようとすることができる。より具体的には、スキャン可能なデバイスＤＴＭは、発見されたデバイスのそれぞれのアドレスを保存し、接続の状況を示す変数を維持することができる。

ＦＤＴフレームアプリケーションを使用して構成および管理することできるプロセス制御システムを概略的に示す図である。 ＦＤＴフレームワークアプリケーションで相互作用する既知のタイプのいくつかのＤＴＭオブジェクトの概略図である。 ＦＤＴフレームワークの外部で動作するソフトウェアアプリケーションと相互作用するスキャン可能なデバイスＤＴＭおよびＦＤＴフレームワーク内の通信ＤＴＭオブジェクト概略図である。 通信ＤＴＭを介していくつかの物理デバイスを管理する単一のスキャン可能なデバイスＤＴＭの概略図である。 ＦＤＴフレームワークの外部で動作するソフトウェアアプリケーションと相互作用するスキャン可能なデバイスＤＴＭおよびＦＤＴフレームワーク内のいくつかの別個の通信ＤＴＭオブジェクトの概略図である。 ＦＤＴフレームワークの外部で動作し、別個のＦＤＴフレームアプリケーションでインスタンス化される複数のスキャン可能なデバイスＤＴＭオブジェクトと相互作用するソフトウェアアプリケーションの概略図である。 スキャン可能なデバイスＤＴＭがデバイススキャンプロセスの一部として実行できる例示的なプロシージャを示す図である。 特定のタイプのデバイスを見つけるために、スキャン可能なデバイスＤＴＭがデバイススキャン機能の一部として実行できる別の例示的なプロシージャを示す図である。

図１は、ＦＤＴフレームワーク上で開発されたソフトウェアツールにより、オペレータが、特定のエレメントの製造業者特有のまたはモデル特有のパラメータと関わりなく、プロセス制御システムの複数のエレメントを閲覧し、構成し、あるいはプロセス制御システムの複数のエレメントと通信できるようになるプロセス制御システムの概略図である。より具体的には、プロセス制御システム１００は、１つまたは複数のプロセスコントローラ１１０を含み、このプロセスコントローラは、少なくとも１つが表示画面を有する１つまたは複数のホストワークステーションまたはコンピュータ１２０〜１２２（任意のタイプのパーソナルコンピュータ、ワークステーションなどとすることができる）と通信可能に接続される。これらのコントローラ１１０は、出入力（Ｉ／Ｏ）カード１４０を介してフィールドデバイス１３０にも接続される。データヒストリアン１４５は、データを保存するための任意の所望のタイプのメモリおよび任意の所望のまたは既知のソフトウェア、ハードウェアもしくはファームウェアを有する任意の所望のタイプのデータコレクションユニットとすることができ、ワークステーション１２０〜１２２とは別個でもワークステーション１２０〜１２２のうち１つの一部でもよい。コントローラ１１０は、例としてＦｉｓｈｅｒ-Ｒｏｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ，Ｉｎｃ．によって販売されるＤｅｌｔａＶ（商標）コントローラとすることができるが、たとえばイーサネット（登録商標）接続またはその他の所望の通信ネットワーク１５０を介して、ホストコンピュータ１２０〜１２２に通信可能に接続される。通信ネットワーク１５０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、電気通信ネットワークなどの形態とすることができ、有線技術または無線技術を使用して実施することができる。コントローラ１１０は、たとえば標準的な４〜２０ｍＡデバイスおよび／またはＦＯＵＮＤＡＴＩＯＮ Ｆｉｅｌｄｂｕｓプロトコル（Ｆｉｅｌｄｂｕｓ）、ＨＡＲＴプロトコルなどの任意のスマート通信プロトコルと関連付けられた任意の所望のハードウェアおよびソフトウェア使用して、フィールドデバイス１３０と通信可能に接続される。

フィールドデバイス１３０は、センサ、バルブ、トランスミッタ、ポジショナなどの任意のタイプのデバイスとすることができ、Ｉ／Ｏカード１４０は、任意の所望の通信またはコントローラプロトコルに適合する任意のタイプのＩ／Ｏデバイスとすることができる。図１に示される実施形態では、フィールドデバイス１３０は、標準的なアナログ４〜２０ｍＡ線１３１を介してＨＡＲＴモデム１４０と通信するＨＡＲＴデバイスであり、一方フィールドデバイス１３３は、Ｆｉｅｌｄｂｕｓプロトコル通信を使用して、デジタルバス１３５を介してＩ／Ｏカード１４０と通信するＦｉｅｌｄｂｕｓフィールドデバイスなどのスマートデバイスである。当然ながら、フィールドデバイス１３０および１３３は、将来開発される任意の規格（もしくは複数の規格）またはプロトコルを含む、任意のその他の所望の規格またはプロトコルに適合し得る。

さらに、ゲートウェイ１４３を介して、フィールドデバイス１４２をデジタルデータバス１３５に接続することができる。たとえば、フィールドデバイス１４２は、ＨＡＲＴコマンドのみを理解することができ、デジタルデータバス１３５は、ＰＲＯＦＩＢＵＳプロトコルを実施することができる。このため、ゲートウェイ１４３は、双方向のＰＲＯＦＩＢＵＳ／ＨＡＲＴ変換を提供することができる。

コントローラ１１０は、少なくとも１つのプロセッサをその中に有するプラント内の多くの分散型コントローラのうちの１つとすることができ、１つまたは複数のプロセス制御ルーチンを実施または監督する。そのプロセス制御ルーチンは、その中に保存されたまたはそれと関連付けられた制御ループを含むことができる。また、コントローラ１１０は、デバイス１３０または１３３、ホストコンピュータ１２０〜１２２およびデータヒストリアン１４５と通信して、任意の所望の方法でプロセスを制御する。本明細書に記載される任意の制御ルーチンまたはエレメントは、所望に応じて、様々なコントローラまたはその他のデバイスによって実施または実行される部分を有することができることに留意されたい。同様に、プロセス制御システム１００内で実施されるべき本明細書に記載される任意の制御ルーチンまたはエレメントは、ソフトウェア、ファームウェア、ハードウェアなどを含む任意の形態をとることができる。この議論を目的として、プロセス制御エレメントは、たとえば、任意のコンピュータ可読媒体上に保存されたルーチン、ブロックまたはモジュールを含む、プロセス制御システムの任意の一部または部分とすることができる。サブルーチン、（コードのラインのような）サブルーチンの一部などの制御プロシージャのモジュールまたは任意の部分とすることができる制御ルーチンは、ラダーロジック、シーケンシャルファンクションチャート、ファンクションブロックダイアグラム、オブジェクト指向プログラミングまたはその他のソフトウェアプログラミング言語、あるいは設計パラダイムを使用するなど、任意の所望のソフトウェア形式で実施することができる。同様に、制御ルーチンは、たとえば、１つまたは複数のＥＰＲＯＭ、ＥＥＰＲＯＭ、特定用途向け集積回路（ＡＳＩＣ）、または任意のその他のハードウェアもしくはファームウェアエレメント中にハードコード化することができる。さらに、グラフィカルデザインツールあるいは任意のその他のタイプのソフトウェア／ハードウェア／ファームウェアプログラミングまたはデザインツールを含む、任意のデザインツールを使用して、制御ルーチンを設計することができる。したがって、任意の所望の方法で、制御戦略または制御ルーチンを実施するように、コントローラ１１０を構成することができる。

ワークステーション１２０〜１２２は、分散型または非分散型の方式でそれぞれ動作する１つまたは複数のＦＤＴフレームアプリケーションを実行することができる。たとえば、ワークステーション１２０は、特定のＦＤＴアセットマネージメントアプリケーションの保存機能を実行することができ、一方コンピュータ１２２は、同じアプリケーションのクエリ機能を実行することができる。再び図１を参照すると、ＦＤＴフレームアプリケーション２００は、ワークステーション１２０上で動作することができ、アセットマネージメントを担うことができる。同様に、ＦＤＴフレームアプリケーション２００は、エンジニアリング（開発、シミュレーションなど）、設置、コミッショニング、製造またはメンテナンスなどのプラントの自動化のその他の側面のうち１つを制御することもできる。ＦＤＴフレームアプリケーション２００は、先に列挙された機能のいずれかに限定される必要はなく、ＦＤＴフレームワークによって可能となる１つまたは複数の機能を実行できることを、さらに理解されたい。

図２を参照すると、分散型または非分散型の方式で、ＦＤＴフレームアプリケーション２００をプラットフォーム２０２上で動作させることができる。上述の実施例において、プラットフォーム２０２は、ワークステーション１２２によって提供されるＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムとすることができる。しかしながら、いくつかの実施形態では、プラットフォーム２０２は、当技術分野で知られる分散型ソフトウェアアーキテクチャに対する多くの手法のうち１つを使用して、ワークステーション１２０および１２２などのいくつかのコンピュータホストにまたがり得る。図２に示された実施例において、ＦＤＴフレームアプリケーション２００は、利用可能な方法を用いて実施することができ、本明細書では例として提供される。

ＦＤＴフレームアプリケーション２００は、メニューバー２０４、ツールバー２０６および様々なナビゲーションキー２０８を有する表示画面を示すことができる。上述のように、ＦＤＴフレームアプリケーション２００は、ＭｉｃｒｏｓｏｆｔのＣＯＭおよびＡｃｔｉｖｅＸ技術に依拠して、標準のＷｉｎｄｏｗｓ（登録商標）グラフィックインターフェースにアクセスし、それにより、キーボード、マウス、またはその他のポインティングもしくはデータエントリデバイスからのユーザインプットが可能になる。また、ＦＤＴフレームアプリケーション２００は、ＦＤＴ仕様によって提供されるインターフェースを使用して様々なＦＤＴオブジェクトと相互作用するデータベース２１０を含むことができる。さらに、ＦＤＴフレームアプリケーション２００は、ＤＴＭオブジェクトのいくつかのインスタンスを含むことができる。具体的には、通信ＤＴＭ２２０は、プラットフォーム２０２の物理ＦＦインターフェース２２２に利用できる特定のセグメント上のＦｏｕｎｄａｔｉｏｎ Ｆｉｅｌｄｂｕｓ（ＦＦ）Ｈ１通信を担うことができる。図２に示されるように、ＦＦインターフェース２２２は、たとえばＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｕｔｅｒ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）規格と互換性のあるコンピュータカードなどのいくつかのモジュールまたは独立型ハードウェアモジュールを含むことができる。代替的には、一般的には通信ＤＴＭ、具体的にはＤＴＭ２２０が、通信デバイスまたはモジュールの任意の物理的な実施形態に対応することができる。本明細書で記述された実施形態では、通信ＤＴＭ２２０は、特定のＨ１セグメントを担うハードウェアモジュール２２４に対応する。

オペレーションにおいて、通信ＤＴＭ２２０は、ＦＦ Ｈ１プロトコルに適合するコマンドを生成し、接続２３０を介してハードウェアモジュール２２４にリレーする。接続２３０は、オペレーティングシステムによって提供される標準的なインターフェース、ＲＳ２３２などのシリアルインターフェース、および周辺機器と通信するその他の既知の手段を含むことができる。ハードウェアモジュール２２４は、１つまたは複数のフィールドデバイス２４０〜２４４と、バス１３５と同様のものとすることができるデジタルデータバス２３５を介して通信することができる。具体的には、フィールドデバイス２４０はアドレスＡ１を有することができ、フィールドデバイス２４２はアドレスＡ２を有することができ、フィールドデバイス２４４は、アドレスＡ３を有することができる。コマンドおよびデータを送受信するとき、ＦＤＴアプリケーション２００は、標的デバイスを明白に識別するために、一般的には、固有のアドレスＡ１〜Ａ３を参照する。既知のＦＤＴ環境において、通信ＤＴＭ２２０は、コマンドとデジタルデータバス２３５に接続された標的デバイスアドレスとを、標的デバイスに対応するデバイスＤＴＭから受信する。したがって、ＦＤＴフレームアプリケーション２００は、フィールドデバイス２４０に対応するデバイスＤＴＭオブジェクト２５０、フィールドデバイス２４２に対応するデバイスＤＴＭオブジェクト２５２、およびフィールドデバイス２４４に対応するデバイスＤＴＭオブジェクト２５４をインスタンス化する。

従来のデバイスＤＴＭオブジェクト２５０〜２５４のそれぞれは、対応するフィールドデバイスのアドレスで構成される。たとえば、デバイスＤＴＭ２５０は、明示的な構成を介してアドレスＡ１を取得するまで、対応する物理デバイス２４０と通信できない。したがって、現在の技術水準では、ある特定のシステムが、各Ｈ１セグメントに常駐するある特定のタイプの８個のデバイスを有する５つのＦＦ Ｈ１セグメントを有する場合、ＦＤＴアプリケーションは、各フィールドデバイスを動作または監視できるようにするために、このタイプのデバイスＤＴＭのインスタンスを少なくとも４０個必要とする。再び図２を参照すると、通信ＤＴＭ２６０は、ＨＡＲＴモデム２６２に対応することができ、同様に、ＨＡＲＴモデム２６２に結合されたフィールドデバイス２６８と同じ数のデバイスＤＴＭ２６６インスタンスを必要とする場合がある。通信ＤＴＭ２６０は、通信チャネル２６３を介して、ＨＡＲＴモデム２６２と通信することができる。

上述の実施例では、具体的には、従来のデバイスＤＴＭ２５０〜２５４および２６６のそれぞれは、デバイスＤＴＭが取り付けられた通信ＤＴＭによってサポートされるプロトコルのためにインスタンス化される。先に示したように、デバイスＤＴＭは、プロトコル変換をサポートするゲートウェイＤＴＭにも接続することができる。図２を参照すると、ＰＲＯＦＩＢＵＳのみをサポートするフィールドデバイスに対応するデバイスＤＴＭ２７０を、ＰＲＯＦＩＢＵＳ／ＨＡＲＴ変換を提供するゲートウェイＤＴＭ２７２に接続することができる。次いで、ゲートウェイＤＴＭ２７２は、ＨＡＲＴ通信を提供する通信ＤＴＭ２６０に接続される。

次に図３を参照すると、ＦＤＴフレームアプリケーション３０２で動作する本開示のスキャン可能なデバイスＤＴＭ３００は、現在のＦＤＴ定義に適合するインターフェースを介して、外部ソフトウェアモジュール３１０と相互作用することができる。別の実施形態では、スキャン可能なデバイスＤＴＭ３００と外部ソフトウェアモジュール３１０との間の接続はＦＤＴ仕様を拡張し、あるいは、ＦＤＴの範囲外の通信スキームに依拠する。しかしながら、ＦＤＴフレームアプリケーション３０２内におけるスキャン可能なデバイスＤＴＭ３００のオペレーションは、ＦＤＴ仕様に適合するのが好ましい。外部ソフトウェアモジュール３１０は、たとえば、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ（商標）によってＰｌａｎｔＷｅｂ（登録商標）スイートの一部として提案されるＡＭＳ ＶａｌｖｅＬｉｎｋ（登録商標）ソフトウェアアプリケーションとすることができる。図３は、プラットフォーム２０２に属する外部ソフトウェアモジュール３１０を示すが、外部ソフトウェアのこの実施例および以下に論じるその他の実施例は、分散型の方式で、異なるプラットフォームまたはいくつかのプラットフォーム上で動作することもできることに留意されたい。外部ソフトウェアモジュール３１０は、ＦＤＴフレームアプリケーション３０２の一部ではないので、ソフトウェアモジュール３１０は、通信ＤＴＭのいずれかに直接アクセスすることはできない。一般的には、ＦＤＴフレームアプリケーション３０２は、標準的なＦＤＴインターフェースに依拠する点でＦＤＴフレームアプリケーション２００に類似し、同じＯＳプラットフォーム２０２上で動作することができる。さらに、ＦＤＴフレームアプリケーション２００および３０２は、フィールドデバイスおよびモデムなどの同じ構成の物理デバイスに対応する。再び図３を参照すると、スキャン可能なデバイスＤＴＭ３００は、ある特定のＦＦ Ｈ１セグメントを担う通信ＤＴＭ２２０に接続することができる。

オペレーションにおいて、外部ソフトウェアモジュール３１０は、デバイス固有のコマンドを送信することによって、フィールドデバイス２４０と通信することができる。一実施形態では、外部ソフトウェアモジュール３１０は、デバイス固有のパラメータおよびコマンドを認識し、通信チャネルにフィールドデバイス２４０を作動させることを求めるに過ぎない。たとえば、フィールドデバイス２４０は、デジタルバルブコントローラＤＶＣ６０００とすることができ、ソフトウェアモジュール３１０は、ＤＶＣ６０００コントローラによってバルブのオペレーションを管理し、グラフィック表示およびテキスト表示をユーザに提供するＡＭＳ ＶａｌｖｅＬｉｎｋソフトウェアとすることができる。スキャン可能なデバイスＤＴＭ３００は、特定の通信チャネルをスキャンし、デバイスのアドレスを外部ソフトウェアモジュール３１０に報告するようにプログラムされる。別の実施形態では、スキャン可能なデバイスＤＴＭ３００は、発見されたデバイスのアドレスを保存し、論理識別子（または、ニックネーム）を発見されたデバイスのそれぞれに割り当て、その識別子をソフトウェアモジュール３１０に報告し、ソフトウェアモジュール３１０の代わりにデータをルーティングすることができる。この場合、ソフトウェアモジュール３１０は、所望のタイプの任意のデバイスが正常に配置されたかどうかを、依然として知る必要があり得るが、デバイスの物理アドレスまたはネットワークトポロジーのその他の詳細は必要としない場合がある。換言すると、スキャン可能なデバイスＤＴＭ３００は、１つまたは複数のフィールドデバイスとソフトウェアモジュール３１０との間にデータをルーティングすることができる。

図３を詳しく参照すると、スキャン可能なデバイスＤＴＭ３００は、特定のプロトコルタイプの通信ＤＴＭと相互作用するようにプログラミングされたスキャン可能なデバイスＤＴＭクラスのインスタンスとすることができる。スキャン可能なデバイスＤＴＭ３００は、具体的にはＦＦ Ｈ１プロトコルと作用するようにインスタンス化することができ、一方スキャン可能なデバイスＤＴＭ３０４は、ＨＡＲＴプロトコルで作用するようにインスタンス化された同じクラスのインスタンスとすることができる。別の実施形態では、スキャン可能なデバイスＤＴＭ３００および３０４は、ある特定のプロトコル専用にそれぞれ開発された別々のクラスからインスタンス化することができる。このため、スキャン可能なデバイスＤＴＭ３００または３０４は、特定の通信リンク（たとえば、電気線、論理チャネル、バスなど）上で１つまたは複数のスキャニングの実行を担う、またはオペレーションを「発見」するスキャン機能を含むことができる。スキャン可能なデバイスＤＴＭ ３００または３０４の対応するデバイス製造業者またはその他の供給者は、ＤＴＭ３００または３０４の統合されたコンポーネントとして、スキャン機能を提供することができる。代替的には、ある特定のデバイスＤＴＭと互換性のあるプラグインコンポーネントとしてスキャン機能を提供することができ、それによりデバイスＤＴＭは、プラグインコンポーネントの含むことによって、スキャン能力を取得できる。

スキャン機能は、スキャン可能なＤＴＭの対応するインスタンスがそれを介してスキャニングオペレーションを実行するプロトコルのある特定の態様を知るようになされ得る。たとえば、ＨＡＲＴコマンド０を通信ＤＴＭ２６０に送信するように、スキャン可能なデバイスＤＴＭ３０４のスキャン機能をプログラムすることができる。ＨＡＲＴに精通する人にはわかるように、このコマンドは、短いＨＡＲＴアドレスまたは長いＨＡＲＴアドレスのいずれかを容認でき、ＨＡＲＴデバイスに適切に配信される場合、ＨＡＲＴデバイス識別で応答させることができる。その他の実施形態では、スキャン機能は、通信チャネル２６３などの特定のチャネル上でＨＡＲＴデバイスを発見するために、別のコマンドまたは一連のコマンドを送信することができる。一般的には、スキャン機能は、フィールドデバイスを発見するために、アラートをスキャンし、センサ（たとえば、プライマリセンサ）をポーリングし、ステート情報を要求し、あるいは、類似の非侵入型のまたは侵入性が最小限のオペレーションを実行することができる。いくつかの実施形態では、スキャン機能は、同時に、デバイスをポーリングし、デバイスのステータスなどのさらなる有用な情報を得る。さらに他の諸実施形態では、スキャン機能には、通信ＤＴＭ２６０によってサポートされる１つまたは複数のプロトコルの知識がほとんどない、または全くない場合があり、高レベルのコマンドを通信ＤＴＭ２６０に送信することによって、通信リンクまたはチャネルをスキャンすることができる。したがって、通信ＤＴＭは、これらのコマンドを物理デバイスに転送できるだけでなく、対応する応答をスキャン可能なデバイスＤＴＭ３０４に転送することができる。

再び図３を参照すると、スキャン可能なＤＴＭ３０４は、スキャン機能によるデバイス発見オペレーションが完了すると、デバイスのリストを外部ソフトウェアモジュール３１０に報告することができる。スキャン可能なＤＴＭ３０４は、特定のチャネル上の任意のタイプのデバイスを発見するようにプログラムすることができる。外部ソフトウェアモジュール３１０は、デバイスのリスト、および任意選択では発見されたデバイスのそれぞれのステータスをユーザに表示することができ、続いて、特定のデバイスに関するコマンドを容認することができる。上述のように、外部ソフトウェアモジュール３１０は、ＤＴＭ ３００または３０４から報告されたデバイスのアドレスあるいはＤＴＭ３００または３０４によって割り当てられたニックネームを特定することによって、スキャン可能なデバイスＤＴＭ３００または３０４を介して、データを発見されたフィールドデバイスのそれぞれと交換することができる。同じように、ＤＴＭ３０４などのスキャン可能なデバイスＤ ＴＭの単一のインスタンスは、通信チャネル２６３上で利用可能なデバイスを自動的に発見することができ、さらに、複数のデバイス２６８のそれぞれと通信できるようにすることができる。したがって、本開示の教示にしたがって実施されるスキャン可能なデバイスＤＴＭは、各デバイスに対して別個のデバイスＤＴＭオブジェクトをインスタンス化する必要性ならびにユーザからのアドレス情報を要求する必要性を取り除くことができる。

それに代えて、あるいはそれに加えて、外部ソフトウェアモジュール３１０は、デバイスタイプ、製造業者アイデンティティおよびその他の類似のパラメータを、スキャン可能なＤＴＭ３０４または３００に特定することができる。ＨＡＲＴ通信プロトコルでは、たとえば、各デバイスは、Ｆｉｓｈｅｒ Ｃｏｎｔｒｏｌｓなどの製造業者識別子およびＤＶＣ５０００などのデバイスタイプと関連付けられる。次いで、スキャン可能なＤＴＭ３０４または３００は、上述の実施形態と同様の方法で通信チャネルのスキャンを実行することができ、さらに、デバイスタイプ、製造業者タイプ、またはそれらの組合せにしたがって発見されたデバイスのリストをフィルタリングすることができる。１つの意図される実施形態では、スキャン可能なＤＴＭ３０４または３００は、ある特定のタイプの全てのデバイスを検索し、各デバイスと関連付けられる製造業者アイデンティティパラメータにかかわりなく、発見されたデバイスを外部ソフトウェアモジュール３１０に報告することができる。別の実施形態では、スキャン可能なＤＴＭ３０４または３００は、外部ソフトウェアモジュール３１０によって特定されるパラメータに整合する製造業者アイデンティティを有する全てのデバイスを発見することができる。さらに別の代替形態では、製造業者アイデンティティまたはデバイスタイプなどの検索基準を、スキャン可能なＤＴＭ３００または３０４内に直接プログラムすることができる。この場合、外部ソフトウェアモジュール３１０は、任意のパラメータをスキャン可能なデバイスＤＴＭ３００または３０４に通信する必要はない。

図４は、スキャン可能なデバイスＤＴＭの別の意図された実施形態を示す。ＦＤＴフレームアプリケーション３１１に関するこの例示的な実施形態では、スキャン可能なデバイスＤＴＭ３１２は、任意のＦＤＴフレームワーク内のデバイスＤＴＭと関連付けられた全ての機能を実行する。具体的には、スキャン可能なＤＴＭ３１２は、フィールドデバイス２４２および２４４に特有のデータおよび機能を含むことができ、ＦＤＴフレームアプリケーション３１１によって提供されるグラフィック環境と相互作用することができる。同様に、スキャン可能なデバイスＤＴＭ３１４は、ＨＡＲＴモデム２６２を介して接続される１つまたは複数のデバイスに対応するデバイス特有の情報を含むことができる。スキャン可能なＤＴＭ３１２は、フィールドデバイス２４２および２４４のアドレスが、明示的に提供されることを必要としない。その代わりに、スキャン可能なＤＴＭ３１２は、ＤＴ Ｍ３００または３０４と同様の方法で通信チャネルをスキャンし、マッチングタイプのフィールドデバイスを自動的に発見する。発見が完了すると、スキャン可能なＤＴＭ３１２は、フィールドデバイス２４２および２４４の両方と通信することができる。しかしながら、その他の実施形態では、たとえばＦＤＴ環境におけるデバイスマネージメントを単純化するために、デバイス毎にスキャン可能なＤＴＭ３１２の別個のインスタンスを生成することが望まれる場合がある。１つの意図された実施形態では、スキャン可能なＤＴＭ３１２の別個のインスタンスを、自動的に発見されたフィールドデバイス毎に生成することができ、発見されたフィールドデバイスのアドレスと関連付けることができる。ＦＤＴフレームアプリケーション３１１は、発見されたデバイス毎に、デバイス記述、物理アドレス、およびその他の関連情報を標準的なＦＤＴインターフェースを介してユーザに表示することができる。

図３に示された実施形態と同様に、製造業者アイデンティティおよびデバイスタイプなどのデバイス発見に関連する選択肢を、ユーザにさらに提供することができる。ＦＤＴフレームアプリケーション３１１は、これらのおよびその他の選択肢を標準的なＦＤＴグラフィカルインターフェースまたはユーザインターフェースを介して提供することができる。当業者は、アセットマネージメントなどのいくつかのアプリケーションの場合、専用の通信ラインまたはバスに取り付けられた全てのデバイスの完全なリストは対象のものとすることができるが、バルブ制御などのその他のアプリケーションは、特定のデバイスタイプを対象とすることができることを理解されたい。したがって、様々なデバイス発見の選択肢は、異なるＦＤＴフレームアプリケーション３０２もしくは３１１または外部ソフトウェアアプリケーション３１０に好適であり得る。

次に図５を参照すると、ＦＤＴフレームアプリケーション３２０は、外部ソフトウェア３２４と相互作用するマルチスキャン可能なＤＴＭ３２２を含むことができる。既存のＦＤＴ仕様の可能な拡張にしたがって、デバイスＤＴＭの単一のインスタンスが、通信ＤＴＭの複数のインスタンスと相互作用でき得ることが意図される。図５に示されるように、マルチスキャン可能なＤＴＭ３２２は、ＨＡＲＴ通信ＤＴＭ２６０およびＦＦ Ｈ１通信ＤＴＭ２２０と通信する。この意図された実施形態によると、ＤＴＭ３２２は、ＨＡＲＴ、ＦＦ、ＰＲＯＦＩＢＵＳ、またはその他のプロトコルをサポートするその他の通信ＤＴＭとも通信することができる。この実施形態において、ＤＴＭ３２２は、ネスト検索を行うスキャン機能を含むことができる。具体的には、ＤＴＭ３２２のスキャン機能は、ＤＴＭ３２２と接続される通信ＤＴＭのそれぞれを介して進み、利用可能なフィールドデバイスとの通信を識別および確立し、発見の結果を外部ソフトウェア３２４へ報告することができる。

図５Ａは、複数のＦＤＴフレームアプリケーション３２６および３２８がプラットフォーム２０２上で同時に動作する別の意図された実施形態を示す。ＦＤＴフレームアプリケーション３２６および３２８は両方とも、外部ソフトウェアモジュール３１０と相互作用することができる。ＦＤＴフレームアプリケーション３２６および３２８は両方とも、独立することができ、たとえば、別個のデータベース２１０および３３０を維持することができる。ＦＤＴフレームアプリケーション３２６は、初めに、ＦＦ通信をサポートすることができ、次いで、通信ＤＴＭ２２０を介するＦＦ Ｈ１セグメント２２４の管理を担うことができる。一方、ＦＤＴフレームアプリケーション３２８は、ＨＡＲＴ通信を担うことができ、通信ＤＴＭ２６０を介してＨＡＲＴモデム２６２を管理することができる。図３を参照して上述された実施形態と同様に、スキャン可能なデバイスＤＴＭ３００は、通信ＤＴＭ２２０を介して、フィールドデバイスを発見、報告および管理することができ、スキャン可能なデバイスＤＴＭ３０４は、通信ＤＴＭ２６０を介してＨＡＲＴデバイスを管理することができる。当然ながら、ＦＤＴフレームアプリケーション３２６および３２８のそれぞれは、別個のＦＦ Ｈ１セグメント、ＨＡＲＴモデムおよびその他の通信チャネルを担う複数のスキャン可能なＤＴＭを有することができる。さらに、外部ソフトウェアモジュール３１０を、異なるまたは類似の通信線を担う単一または複数のＦＤＴフレームアプリケーションに等しく互換性があるように適合することができる。この意味において、外部ソフトウェアモジュール３１０の設置、構成またはオペレーションの間、ＦＤＴフレームアプリケーションとソフトウェアモジュール３１０などの外部ソフトウェアとの間の接続をユーザに対して明らかにすることができる。

さらに別の実施形態では、外部ソフトウェアモジュール３１０またはＦＤＴフレームワークの外部で動作する同様のソフトウェアアプリケーションは、別個の物理ホスト上で動作するいくつかのＦＤＴフレームアプリケーションと通信することができる。たとえば、ワークステーション１２０は、ＦＤＴフレームアプリケーション３２６を作動させることができ、一方ワークステーション１２２は、ＦＤＴフレームアプリケーション３２８を作動させることができる。ワークステーション３２６および３２８のそれぞれは、Ｗｉｎｄｏｗｓ（登録商標） ＯＳの、またはＦＤＴの可能な拡張においてＦＤＴ仕様をサポートするようになされたその他のオペレーティングシステムの異なるバージョンを実行させることができる。外部ソフトウェアモジュール３１０は、ワークステーション１２０および１２２上で分散型の方式で動作することができる。別の実施形態では、外部ソフトウェアは、単一のインテリジェントホストまたはワークステーション１２０などのワークステーション上で動作することができる。この場合および同様の場合、外部ソフトウェアモジュール３１０は、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰソケット、リモートプロシージャコール（ＲＰＣ）あるいは遠隔プロセス間通信のその他の好適な手段を使用して、ＦＤＴフレームアプリケーションと通信することができる。別の実施形態では、外部ソフトウェアモジュール３１０もＦＤＴフレームアプリケーション３２６および２３８も両方とも、分散コンポーネントオブジェクトモデル（ＤＣＯＭ）技術に依拠して、データを交換することができる。

図３、図５および図５Ａに関して一般的には、スキャン可能なデバイスＤＴＭ３００または３０４ならびにマルチスキャン可能なデバイスＤＴＭ３２２は、さらに、スキャン可能なＤＴＭを介する接続が途切れると、外部ソフトウェアモジュール３１０または３２４を対応するフィールドデバイスに再接続するようになされ得る。より詳細には、スキャン可能なデバイスＤＴＭは、それぞれの発見されたデバイスのアドレスを保存することができ、したがって、１つまたは複数のデバイス接続がなくなる度に、スキャン機能を再実行する必要性が取り除かれる。また図３から図５Ａを全体的に参照すると、スキャン可能なデバイスＤＴＭまたはマルチスキャン可能なデバイスＤＴＭは、ゲートウェイＤＴＭを介して通信ＤＴＭに接続できることに留意されたい。たとえば、スキャン可能なデバイスＤＴＭ３００は、ＰＲＯＦＩＢＵＳ／ＦＦ Ｈ１変換を提供するタイプゲートウェイのＤＴＭを介して、通信ＤＴＭ２２０に接続することができる。

図６は、スキャン可能なデバイスＤＴＭ３００、３０４、３１２または３１４によって実行することができるプロシージャ３５０のブロック図を示す。ブロック３５２において、スキャン可能なデバイスＤＴＭのインスタンスは、ＦＤＴフレームアプリケーションの内部で生成され、初期化される。上述されたように、スキャン可能なデバイスＤＴＭの単一のインスタンスは、スキャン可能なデバイスＤＴＭが十分なデバイス専用の情報でプログラムまたは構成される場合、いくつかのフィールドデバイスを同時にサポートすることができる。インスタンス化されたスキャン可能なデバイスＤＴＭは、ブロック３５２で実行される初期化シーケンスの一部として、適当な通信ＤＴＭに接続することができる。ブロック３５４において、プロシージャ３５０により、特定のマルチプレクサ、ＦＦ Ｈ１セグメントまたは同様の接続と関連付けられるアドレス範囲の境界が得られる。プロシージャ３５０は、ＦＤＴフレームアプリケーションの外部で動作する外部ソフトウェアから、アドレス境界を受信することができる。代替的には、プロシージャ３５０は、ＦＤＴフレームアプリケーションから、標準的なＦＤＴインターフェースを介してアドレス境界を得ることができる。さらに別の代替形態として、デバイス境界をリストとして供給することができ、そのデバイス境界は、いくつかの重複しないアドレス範囲を含むことができる。しかしながら、例示的なプロシージャ３５０は、２つのアドレスのみによって境界を定められたアドレスの単一の範囲をサポートする実施形態を参照する。

次に、プロシージャ３５０は、アドレス毎に物理デバイスに到達しようとして、特定の範囲内の各アドレスを通じて進めることができる。ブロック３５６において、プロシージャ３５０は、たとえば、先に試みたアドレスまたはその範囲の下側境界をインクリメントすることによって、次のアドレスを生成することができる。ブロック３５８では、プロシージャ３５０は、次のアドレスが、特定のアドレス範囲の上側境界を超えたかどうかをチェックすることができる。次のアドレスが特定の範囲内にある場合、プロシージャ３５０は、次のアドレスにおける物理デバイスの有無を検出することができる。具体的には、プロシージャ３５０は、上述の実施形態のうち１つにしたがって、ポーリンク機能を実行することができる。

ブロック３６２において、プロシージャ３５０が物理デバイスを発見した場合、プロシージャ３５０は、発見されたデバイスのアドレスをリストに加えることができる。このステップは、ブロック３６４に示される。先に示したように、プロシージャ３５０は、デバイスの動作状態、デバイスによって生成された際立ったアラームのリスト、デバイスによって集められた際立った測定値および同様のデータのような追加の情報を得ることもできる。プロシージャ３５０は、この情報を、発見されたデバイスの物理アドレスとともに、発見されたデバイス毎に保存することができる。プロシージャ３５０を実行するスキャン可能なデバイスＤＴＭは次いで、この集められた情報を、外部ソフトウェアアプリケーションまたはＦＤＴフレームアプリケーションで利用可能にすることができ、次いで、この情報をグラフィックでまたはテキストで表示することができる。最終的には、プロシージャ３５０は、ブロック３６６において、スキャンの完了をＦＤＴフレームアプリケーションで動作する外部ソフトウェアまたはユーザに報告することができる。

図７に目を移すと、プロシージャ３８０は、スキャン可能なデバイスＤＴＭの別の意図された実施形態に対応することができる。ブロック３８２において、スキャン可能なデバイスＤＴＭを同様にインスタンス化することができる。ブロック３８４において、プロシージャ３８０は、製造業者アイデンティティを取得することができるが、これは、その製造業者アイデンティティをある特定の通信チャネル上に存在する各物理デバイスによって報告された情報とマッチングすることを目的とするものである。次に、プロシージャ３８０は、１つまたは複数のマッチングデバイスの検索をさらに限定するためにデバイスタイプを取得する。当然ながら、プロシージャ３８０のその他の実施形態は、製造業者アイデンティティまたはデバイスタイプの一方のみを取得してもよい。

ブロック３８８において、プロシージャ３８０は、通信チャネルをスキャンして、物理デバイスを発見することができる。この実施形態では、プロシージャ３８０は、ブロック３９０において、物理デバイスの完全なリストを取得し、その取得したリストからフィルタリングする。換言すると、プロシージャ３８０は、スキャン可能なＤＴＭが取り付けられる通信ＤＴＭを介して、ジェネリックコマンドを送信することができ、各利用可能なデバイスが十分なアイデンティおよびタイプ情報を伴って応答すると、プロシージャ３８０ は、各デバイスからの情報を、ブロック３８４およびブロック３８６で得られた基準と比較することができる。代替的には、少なくともいくつかの場合に、プロシージャ３８０は、ブロック３８４およびブロック３８６において特定されたデバイスタイプに特有のコマンドまたは製造業者に特有のコマンドを知ることができる。この場合、プロシージャ３８０は、特定のデバイスタイプまたは製造業者アイデンティティにマッチングする、応答する複数のデバイスのみを予測する可能なアドレスのそれぞれに、コマンドをブロードキャスト、マルチキャストまたは反復的に送信することによって、通信チャネル上のトラフィック量を低減させることができる。最終的には、ブロック３９２において、プロシージャ３８０は、発見されたデバイスのそれぞれに関して利用できる情報を、外部ソフトウェアまたはＦＤＴフレームアプリケーションに報告することができる。

上述の諸実施形態において、スキャン機能を、インスタンス化または初期化した後にスキャン可能なＤＴＭによって自動的に、あるいは、ＦＤＴフレームアプリケーションまたは外部ソフトウェアと相互作用するユーザによって、トリガすることができる。具体的には、外部ソフトウェアモジュール３１０は、「ＳＣＡＮ ＡＬＬ」機能をユーザに提示することができる。ラジオボタン、テキストプロンプトから入力されたコマンド、ボイスコマンド、またはユーザインターフェースを提示する任意のその他の手段によって、「ＳＣＡＮＡＬＬ」機能をトリガすることができる。選択後、外部ソフトウェアモジュール３１０がこのスキャン可能なデバイスＤＴＭとの接続を確立した場合、「ＳＣＡＮ ＡＬＬ」機能は、それぞれのホスト上のそれぞれのＦＤＴフレームアプリケーションの各スキャン可能なデバイスＤＴＭにおけるスキャンをトリガすることができる。外部ソフトウェアモジュール３１０は、次いで、スキャン可能なＤＴＭのそれぞれから所望の情報を集めることができる。

本開示の教示に適合するその他の実施形態は、たとえば、特定のタイプで、特定のアドレス範囲にも属するデバイスを検索するために、プロシージャ３５０および３８０のエレメントのうちいくつかを組み合わせることができることを理解されたい。また、先に論じられた諸実施形態は、現在のＦＤＴ仕様を参照しているが、先に概説された原理およびアルゴリズムは、将来開発される可能性があるバージョンを含むＦＤＴのその他のバージョンにも、またソフトウェアモジュールと物理デバイスとの間の通信をサポートするための類似のフレームワークにも当てはまることに留意されたい。具合的には、ＦＤＴフレームワークは、Ｗｉｎｄｏｗｓ（登録商標） ＯＳ以外のプラットフォームを採用することができる。したがって、ＦＤＴは、ＣＯＭおよびＡｃｔｉｖｅＸの代わりに、またはそれらに加えて、その他の技術を利用することができ、フレームアプリケーションおよびＤＴＭによって使用されるインターフェースのうちいくつかを再定義することができる。先に論じられた諸実施形態は、その他のプラットフォームおよびインターフェースの定義に適合することに留意されたい。

上述の議論から、当業者は、スキャン可能なデバイスＤＴＭ（スキャン可能なデバイスＤＴＭ３００、３０４、３１２、３１４または３２２など）により、ＦＤＴフレームアプリケーションの開発者またはユーザが、特定のデバイスに特有の機能を包含すると同時に、デバイスのアドレスを有するＤＴＭオブジェクトの明示的な構成なしに、このデバイスとソフトウェアモジュールとの通信を提供するＤＴＭオブジェクトをインスタンス化できるようになることを理解されたい。換言すると、スキャン可能なデバイスＤＴＭは、ＦＤＴフレームワーク内のデバイスの構成および管理を飛躍的に単純にし、かつ、対応するアドレスを有するデバイスＤＴＭを構成するステップを完全になくすこと、またはその他のシナリオもしくは実施形態において、発見されたデバイスのリストおよび／またはアドレスをユーザに提示することのいずれかによって、人的エラーの可能性を低くする。さらに、スキャン可能なデバイスＤＴＭのいくつかの実施形態により、ソフトウェアモジュールは、複数の物理デバイスとスキャン可能なデバイスＤＴＭの単一のインスタンスを介して通信できるようになる。したがって、ソフトウェアフレームワーク内の１つまたは複数の物理デバイスを代表することによって、スキャン可能なデバイスＤＴＭは、複雑なシステム（たとえば、何百ものフィールドデバイスを有するプロセス制御プラント）を効果的に管理するのに特に便利な高レベルの抽象化を提供する。

さらに、スキャン可能なデバイスＤＴＭのいくつかの実施形態により、スキャン可能なデバイスＤＴＭの単一のインスタンスは、ソフトウェア（ＦＤＴフレームワークの内部または外部に１つまたは複数のモジュールを含むことができる）と様々なタイプの複数の通信リンクに接続される複数のデバイスとの間の通信をサポートできるようになる。この機能を含むＤＴＭは、マルチスキャン可能なＤＴＭとも称することができる。上述のように、マルチスキャン可能なＤＴＭはさらに、ＦＤＴフレームアプリケーション内のＤＴＭオブジェクトの数を少なくすることができる。さらに、マルチスキャン可能なＤＴＭは、単一の通信リンクに限定されず、単一の通信プロトコルにも限定されないディスカバリ機能を提供する。

数多くの異なる諸実施形態を含む、発明を実施するための形態の上述の文章に記載したが、特許権の範囲は、本特許出願の最後に記載される特許請求の範囲の表現およびその均等物によって規定されることを理解されたい。発明を実施するための形態は、単なる例示として解釈されるべきであり、可能な実施形態の全てを記載することは、不可能でないにせよ実務的ではないので、可能な実施形態の全てを記載するものではない。現在の技術または本特許出願の出願後に開発された技術のいずれかを使用して、数多くの代替実施形態を実施することができ、これは、依然として本願の特許請求の範囲に属する。

Claims (27)

1. フィールドデバイスツール（ＦＤＴ）フレームワークを使用して、デバイスと通信する方法において、
   前記デバイスがプロセス制御環境において動作し、かつ、通信リンクに通信可能に結合され、
   前記方法が、タイプデバイスのスキャン可能なデバイスタイプマネージャ（ＤＴＭ）のインスタンスを生成するステップであって、
   前記タイプデバイスのスキャン可能なＤＴＭが、前記ＦＤＴフレームワーク内の前記デバイスを表すステップと、
   前記スキャン可能なＤＴＭの前記インスタンスを通信チャネルに通信可能に接続するステップであって、前記通信チャネルが、前記通信リンクに対応するステップと、
   前記スキャン可能なＤＴＭの前記インスタンスを使用して、前記デバイスを発見するために、前記通信リンクをスキャンするステップと、
   前記スキャン可能なＤＴＭにおける前記発見されたデバイスのアドレスを取得するステップと、を含む方法。
2. 前記スキャン可能なＤＴＭの前記インスタンスをフレームアプリケーションに接続するステップと、
   前記発見されたデバイスの前記取得されたアドレスを使用して、前記スキャン可能なＤＴＭの前記インスタンスを介する前記発見されたデバイスと前記フレームアプリケーションとの間の通信を可能にするステップと、をさらに含む請求項１に記載される方法。
3. 前記発見されたデバイスの前記アドレスを、メモリ内に保存するステップと、
   前記通信リンクが利用不可能になる場合、前記保存されたアドレスを前記メモリ内に保持するステップと、
   前記通信リンクが利用可能になるのに応答して、前記保存されたアドレスを使用して、前記デバイスと前記フレームアプリケーションとの間の前記通信リンクを復元するステップと、をさらに含む請求項２に記載される方法。
4. 前記スキャン可能なＤＴＭの前記インスタンスを通信チャネルに接続するステップが、
   前記スキャン可能なＤＴＭの前記インスタンスを、前記通信リンクに関連付けられた通信プロトコルをサポートする通信ＤＴＭに接続するステップを含む、請求項１に記載される方法。
5. 前記通信リンクをスキャンするステップが、
   メッセージを前記通信ＤＴＭに送信するステップであって、前記メッセージが前記デバ
   イスにアドレス指定するコマンドを含むステップと、
   前記デバイスからの応答を受信するステップであって、前記通信ＤＴＭが、前記デバイ
   スから前記スキャン可能なＤＴＭへ前記応答を転送するステップと、
   を含む請求項４に記載される方法。
6. 前記通信リンクをスキャンするステップの前に、デバイスタイプまたは製造業者アイデンティティのうち少なくとも１つを取得するステップをさらに含み、
   前記通信リンクをスキャンするステップが、前記デバイスタイプまたは前記製造業者アイデンティティのうち前記少なくとも１つにしたがって、デバイスを発見するステップを含む、請求項１に記載される方法。
7. 前記通信リンクをスキャンするステップが、アドレス範囲を取得するステップを含み、
   前記通信リンクをスキャンするステップが、前記アドレス範囲内のアドレスを有する前記デバイスを発見するステップを含む、請求項１に記載される方法。
8. 前記通信リンクをスキャンするステップが、センサをポーリングするステップまたは前記通信リンク上で利用できるアドレスのそれぞれにおいてアラートをスキャンするステップの少なくとも１つを含む、請求項１に記載される方法。
9. 前記通信リンクをスキャンするステップが、ブロードキャストメッセージまたはマルチキャストメッセージのうち少なくとも１つを、前記通信リンクに関連付けられた複数のアドレスに送信するステップを含む、請求項１に記載される方法。
10. 前記通信リンクが、ＨＡＲＴ（登録商標）通信プロトコルをサポートし、前記通信リンクをスキャンするステップが、ＨＡＲＴコマンド０を利用可能なアドレスそれぞれに送信するステップを含む、請求項１に記載される方法。
11. 前記発見されたデバイスのステータスを取得するステップをさらに含む、請求項１に記載される方法。
12. 第２のデバイスを発見するために、前記通信リンクをスキャンするステップと、
    前記スキャン可能なＤＴＭにおける前記第２のデバイスのアドレスを決定するステップであって、前記第１のデバイスの前記アドレスが、前記第２のデバイスの前記アドレスと区別されるステップと、をさらに含む、請求項１に記載される方法。
13. 前記スキャン可能なＤＴＭの前記インスタンスを、第２の通信チャネルに接続するステップであって、前記第２の通信チャネルが、第２の通信リンクに対応するステップと、
    前記第２の通信リンクに通信可能に結合される第２のデバイスを発見するために、前記第２の通信リンクをスキャンするステップと
    前記スキャン可能なＤＴＭにおける前記第２のデバイスのアドレスを取り出すステップとを、さらに含む請求項１に記載される方法。
14. 前記デバイスの前記アドレスを有する前記スキャン可能なＤＴＭの前記インスタンスを構成することなしに、前記スキャン可能なＤＴＭの前記インスタンスを介する前記発見されたデバイスと前記ソフトウェアモジュールとの間の通信を可能にするステップをさらに含む、請求項１に記載される方法。
15. フィールドデバイスツール（ＦＤＴ）アプリケーションフレームワーク内で動作するタイプデバイスのスキャン可能なデバイスタイプマネージャ（ＤＴＭ）であって、前記ＤＴＭがプロセス制御環境で動作する少なくとも１つのデバイスを表し、
    前記スキャン可能なＤＴＭが、
    前記少なくとも１つのデバイスに特有の機能をサポートするための機能モジュールと、
    前記アプリケーションフレームワークと相互作用するために、前記機能モジュールに結合される第１のインターフェースと、
    通信チャネルと相互作用するために、前記機能モジュールに結合される第２のインターフェースであって、前記通信チャネルが、前記少なくとも１つのデバイスが通信可能に結合される前記通信リンクに対応する第２のインターフェースと、
    前記通信リンクに結合された前記少なくとも１つのデバイスを発見するために、および前記スキャン可能なＤＴＭを介する前記アプリケーションネットワークと前記発見された少なくとも１つのデバイスとの間の通信を可能にするために、前記第２のインターフェースに結合されるスキャン機能と、を備えるＤＴＭ。
16. 前記少なくとも１つの発見されたデバイスのアドレスを保存するために、永続性メモリを、さらに備える請求項１５に記載されるＤＴＭ。
17. 前記ＦＤＴアプリケーションフレームワーク内で動作する通信ＤＴＭが前記通信チャネルを提供する、請求項１５に記載されるＤＴＭ。
18. 前記第２のインターフェースが、少なくとも１つのデバイスが結合される第２の通信リンクに対応する第２の通信チャネルにさらに結合され、前記第１の通信リンクが第１の通信プロトコルをサポートし、前記第２の通信リンクが第２の通信プロトコルをサポートし、
    前記スキャン機能が、前記第２の通信リンクに結合される前記少なくとも１つのデバイスをさらに発見するために、前記第２のインターフェースに結合される、請求項１５に記載されるＤＴＭ。
19. 前記第１の通信リンクが、ＨＡＲＴ（登録商標）通信プロトコルをサポートし、前記第２の通信リンクが、Ｆｏｕｎｄａｔｉｏｎ（商標）Ｆｉｅｌｄｂｕｓ Ｈ１通信プロトコルをサポートする、請求項１８に記載されるＤＴＭ。
20. 前記機能モジュールが、較正機能、診断機能、メンテナンス機能較正、またはテスト機能のうち少なくとも１つを実行する、請求項１５に記載されるＤＴＭ。
21. デバイスタイプ、製造業者アイデンティティ、またはアドレス範囲のうち少なくとも１つを保存するためのメモリをさらに備え、前記スキャン機能が、前記デバイスタイプ、前記製造業者アイデンティティまたは前記アドレス範囲のうち前記保管された少なくとも１つをマッチングする前記少なくとも１つのデバイスを発見する、請求項１５に記載されるＤＴＭ。
22. プロセス制御ネットワーク内で動作するデバイスと通信する方法であって、
    タイプデバイスのスキャン可能なデバイスタイプマネージャ（ＤＴＭ）のインスタンスを、通信プロトコルに関連付けられた通信チャネルに接続するステップであって、前記スキャン可能なＤＴＭが、フィールドデバイスツール（ＦＤＴ）アプリケーションフレームワーク内で動作するステップと、
    前記通信チャネルに関連付けられた複数のアドレスをスキャンするために、前記スキャン可能なＤＴＭを使用するステップと、
    前記スキャン可能なＤＴＭと互換性があり、前記通信チャネルに関連付けられた１つまたは複数のデバイスを発見するステップと、を含む方法。
23. 前記１つまたは複数の発見されたデバイスとプロセス制御アプリケーションまたは前記ＦＤＴアプリケーションフレームワークに関連付けられたアセットマネージメントアプリケーションのうち少なくとも１つとの間の通信を可能にするステップをさらに含む、請求項２２に記載される方法。
24. 発見されたデバイスのリストを生成するステップであって、各リストエントリが、少なくとも、発見されたデバイスのアドレスを含むステップと、
    前記リストを、ＦＤＴアプリケーションネットワークを介して、ユーザインターフェースに送信するステップとをさらに含む、請求項２２に記載される方法。
25. ユーザインターフェースからアドレス範囲を受信するステップをさらに含み、前記スキャン可能なＤＴＭによってスキャンされた前記複数のアドレスのそれぞれが、前記アドレス範囲内にある、請求項２２に記載される方法。
26. 前記ユーザインターフェースから製造業者アイデンティティを受信するステップをさらに含み、１つまたは複数のデバイスを発見するステップが、前記受信した製造業者アイデンティティを、前記アドレス範囲内のデバイスのそれぞれによって報告された製造業者アイデンティティと比較するステップを含む、請求項２５に記載される方法。
27. 発見されたデバイスのそれぞれに、ニックネームを割り当てるステップと、
    発見されたデバイスのそれぞれの前記ニックネームを、前記ＦＤＴアプリケーションフレームワークと関連付けられたアプリケーションに提供するステップと、
    前記アプリケーションと発見されたデバイスのそれぞれの間に、前記割り当てられたニックネームに基づいてデータをルーティングするステップとをさらに含む、請求項２２に記載される方法。

Images