JP4072975B2 - 分散型制御機能を有するプロセス制御ネットワークに於けるローカルデバイスおよびプロセス診断 - Google Patents

Description

関連出願
これは、１９９６年１０月４日に出願された米国特許出願連続番号第０８／７２６，２６２号の一部継続出願である。
発明の分野
本発明は、概してプロセス制御ネットワークに関し、特に分散型制御機能を有するプロセス制御ネットワークに於けるローカルデバイス及びプロセスを診断に使用するための方法および機器に関する。
関連する技術
化学プロセス、石油プロセス、およびその他の製造プロセスおよび精製プロセスのような大型プロセスは、プロセスパラメータを測定、制御し、それによってプロセスの制御を達成するために、多様な場所に配置される多数のフィールドデバイスを含んでいる。これらのフィールドデバイスとは、例えば、弁およびスイッチなどの制御部品だけではなく温度センサ、圧力センサおよび流量センサのようなセンサであることもある。歴史的に、プロセス制御産業は、液位計および圧力計を手作業で読み取ったり、バルブホイールを回すなどの手作業の動作を使用し、プロセス内の測定フィールドデバイスおよび制御フィールドデバイスを運転してきた。２０世紀に始まったプロセス制御産業は、局所的な空気式調節計の使用を開始し、局所的な空気式調節計、送信機、および弁位置決め装置が、一定のプラント配置の制御を達成するためにプロセスプラント内のさまざまな場所に配置された。マイクロプロセッサをベースにした分散型制御システム（ＤＣＳ）が１９７０年代に出現し、分散型電子プロセス制御が、プロセス制御産業で一般的になった。
知られているように、ＤＣＳは、プロセス中に配置される電子センサ、送信機、電流・圧力変換器、弁位置決め器などの多数の電子監視制御装置に接続されるプログラマブル論理コントローラのようなアナログコンピュータまたはデジタルコンピュータを含む。ＤＣＳコンピュータは、いくつかの総合的な制御スキームに従ってプロセス内の装置の測定および制御しこれによりコントロールパラメータを達成するために、集中化された、および頻繁に複雑な制御スキームを記憶し、実現する。しかしながら、通常、ＤＣＳによって実現される制御スキームは、同様にＤＣＳの拡大、アップグレード、再プログラムおよび保守を、ＤＣＳのコントローラがこれらの活動のどれかを実行するためには一体となって関与しなければならないという理由から、困難かつ高価にするＤＣＳ製造メーカに独占的なものになっている。さらに、特定のＤＣＳ内で使用または接続され得る装置は、ＤＣＳコントローラの独占的な性質、およびＤＣＳコントローラが、一定のデバイスや他のベンダにより製造されるデバイスの機能をサポートしない可能性があるという事実のために制限されることがある。
独占的なＤＣＳの使用に固有な問題点のいくつかを克服するために、プロセス制御産業は、さまざまな製造メーカにより製造されたフィールドデバイスを同じプロセス制御ネットワーク内で一緒に使用できるようにする、例えばHARTプロトコル、PROFIBUSプロトコル、WORLDFIPプロトコル、LONWORKSプロトコル、Device-Netプロトコル、およびCANプロトコルのような多数の標準開放通信プロトコルを開発してきた。実際、これらのプロトコルの内の１つに準拠するフィールドデバイスは、たとえそのフィールドデバイスがＤＣＳコントローラ製造メーカ以外の製造メーカによって製造されていても、ＤＣＳコントローラまたはそのプロトコルをサポートする他のコントローラと通信し、それにより制御されるためにプロセスで使用することができる。
さらに、いまでは、プロセス制御業界内には、プロセス制御を分散し、それによってＤＣＳコントローラを簡略化するか、ＤＣＳコントローラに対するニーズを大きく排除する動きが出てきている。分散化制御は、弁位置決め装置、送信機などのプロセス制御装置に１つまたは複数のプロセス制御機能を実行させ、他のコントロール機能に於いて他のプロセス制御装置によって使用されるバス構造全体でデータを通信することにより得られる。制御機能を実現するために、各プロセス制御装置は、標準開放通信プロトコルを使用して他のプロセス制御装置と通信する能力だけではなく、１つまたは複数の基本制御機能を実行することができるマイクロプロセッサを含む。このようにして、さまざまな製造メーカによって製造されたフィールドデバイスは、互いに通信し、ＤＣＳコントローラの介入を受けずにコントロールループを形成する１つまたは複数のプロセス制御機能を実行するためにプロセス制御ネットワーク内で相互接続することができる。現在、FOUNDATIONTM Fieldbus（これ以降「Fieldbusプロトコル」）として知られているフィールドバス財団（Fieldbus Foundation）によって公表されているデジタル二線式ループプロトコルは、さまざまな製造メーカによって製造されるデバイスが、１つのプロセス内で分散化制御を達成するために標準バスを介して相互運用し、互いと通信できるようにする１つの開放通信プロトコルである。
前記に注記されたように、プロセス制御機能の分散化は、代わりに、ＤＣＳコントローラによって実現される制御スキームを変更またはアップグレードするために、製造メーカがＤＣＳコントローラに依存する必要性を削減する独占的なコントローラの必要性を簡略化し、場合によっては、排除する。しかしながら、また、分散化された制御は、ＤＣＳコントローラにより通常実行される、プロセス診断のような診断を実行することをさらに困難にする。しかし、例えば温度および圧力の範囲が大きく可変である厳しい環境で、流体制御弁のようなフィールドデバイスを使用するときには、デバイス診断およびプロセス診断のような定期的な診断を実行することは非常に重要である。このような環境では、定期的な予防保守、弁破壊のための保守、および弁が適切に機能していることを検証するためのテストを含むかなりの保守が必要である。
標準的なＤＣＳ環境では、（パーソナルコンピュータのような）コンピュータがネットワークに結合され、例えば弁または位置決め装置／弁の組み合わせ上で、弁に、診断制御信号に関連するテストストロークまたはテストサイクルを強制的に受けさせる診断制御信号を位置決め装置に送信することにより、デバイス診断を実行する。この時間中、コンピュータは、診断制御信号に応えて発生する弁位置の変化のような位置決め装置および／または弁の出力を測定し、その後に測定された出力に対する分析を実行し、弁または位置決め装置／弁デバイスの可動状態を判断する。
空気作動弁のような流体制御弁用の１つの既知の診断システムにおいては、弁の入力時点での変化する圧力を検知するために圧力センサが具備され、弁プラグの移動を検知するために位置センサが具備される。弁は、制御された可変空気圧を空気弁の入力端末に供給することによりテスト運転サイクルを通して操作される。例えば、動的走査のテスト運転サイクル中、弁プラグは、希望の範囲で、通常は完全開放位置から完全閉鎖位置まで動かされ、完全閉鎖位置から完全開放位置まで戻される。代わりに、ステップテストは、一定の弁パラメータを試験するために一連の個々のステップで弁プラグを移動してよい。
テスト運転サイクル中、圧力センサは、弁入力時の変化する圧力に相当する出力信号を提供し、位置センサは、弁プラグの移動に相当する入力信号を提供する。それから、アクチュエータ、および弁プラグまたは弁ステム位置での空気圧の各入力信号または出力信号が処理され、弁入力時の圧力の変動を表すデータを、テスト運転サイクル中の弁プラグの移動の関数として引き出す。弁ステム負荷は、空気圧をアクチュエータダイヤフラムの有効面積で乗算することにより得られる。
診断システムは診断コマンドを受け取り、通信回線を介してセンサから得られる診断情報を外部制御コンソールまたはプロセッサ／コンピュータに通信する。外部制御コンソールまたはプロセッサ／コンピュータは単一診断テストを要求し、診断システムがテストを実行する間、結果を待機する。テストが完了すると、診断システムはテスト結果を外部制御コンソールに送信する。弁ごとに多くの多様な診断テストが実行され、制御システムは、通常診断テスト時間が冗長になるように多くの弁を含む。
また、知られているように、標準的なＤＣＳ環境においては、ＤＣＳコントローラのようなコンピュータは、弁にテストシーケンスを強制的に受けさせる診断制御信号を送信することにより、例えば、弁または位置決め装置／弁の組み合わせを使用してプロセス診断を実行する。
標準的なＤＣＳ環境においては、ＤＣＳコントローラまたは外部コンピュータはプロセス内の多様なデバイスの設定ポイント（またはそれ以外の入力）を制御し、デバイス出力および他のプロセスパラメータを測定し、プロセスの通常の運転と関連する制御戦略を実現するようにすでに構成されているため、デバイス診断またはプロセス診断は、システムを大きく作成し直したり、構成し直したりしなくても実行することができる。その結果、標準的なＤＣＳ環境で診断を実行することは、実際には、プロセス内で１つまたは複数のデバイスを制御するためにわずかに異なった方式でＤＣＳコントローラやその他の外部コンピュータを使用し、プロセスパラメータまたはデバイスパラメータを測定するためにＤＣＳコントローラや他の外部コンピュータを使用することである。したがって、標準的なＤＣＳ環境においては、診断ルーチンは、ほぼあらゆるデバイス診断またはプロセス診断を実行するために、集中型ＤＣＳコントローラまたはその他の集中型外部コンピュータに記憶され、それらによって使用することができ、これらの診断ルーチンは、かなりプロセス制御ネットワークを構成し直さなくても使用することができる。残念なことに、これらの診断ルーチンの集中化された性質のため、それらの診断ルーチンはフィールドデバイスについてほとんど詳細な情報を提供しない。
しかしながら、分散型制御機能を有するプロセス制御ネットワークにおいては、集中型システムコントローラは、それが存在する範囲では、プロセス内のフィールドデバイスのすべてを個々に制御するように構成されず、デバイス診断およびプロセス診断を実行するために必要な適切なデバイスパラメータまたはプロセスパラメータのすべてに関するデータを受け取るように構成されていない。代わりに、制御戦略の異なるプロセス制御ループは、プロセス制御ネットワーク内の分散された場所に位置する数多くの通信可能となるようにリンクされたデバイスにより実現される。典型的には、これらのデバイスは、スケジュールされた定期的な通信を使用し、プロセス制御ループに関連する特殊な制御機能のインプリメンテーションに必要なデータを通信し、非周期的なまたは非同期の通信を使用し（設定ポイント変更などの）他のデータを通信するように構成される。その結果、スケジュールされた定期的な通信を使用して実現された分散型制御機能を有するプロセス制御ネットワークでは、ホストデバイスは、厳密に決定的な診断制御信号をプロセス制御デバイスに送信できないが、ホストデバイスが非同期通信を使用し、診断制御信号を送達しなければならないので、診断制御信号（またはその異なる部分）が試験されているデバイスに到達する正確な時間を制御することはできないため、システムは、通常の制御戦略を実現するように構成されている。事実上、非同期通信を使用すると、ホストデバイスは、診断制御信号（またはその任意の特定の部分）が制御されているデバイスの入力に実際に到達するときを知ることができない。その結果、ホストデバイスが決定的な診断制御信号を分散型制御機能を有するプロセス制御ネットワーク内のデバイスに送信するには、ネットワークの制御構成は、構成し直されなければならず、それにはプロセスをオフラインにする必要がある。
さらに、フィッシャー・コントロールズ・インターナショナル社（Fisher Controls International Inc.）により製造販売されるFieldvueおよびFlowscannerデバイスなどのいくつかのプロセス制御デバイスは、自己診断を実行することができるが、これらのデバイスは、アナログ通信プロトコルまたはアナログ／デジタルが組み合わされた通信プロトコルを使用し、さまざまなデバイス間の通信を達成するプロセス制御システムでの使用に限られている。現在では、Fieldbusシステムのような全デジタルシステムで、または分散型制御機能を実行する通信システム内で自己診断を実行できるプロセス制御フィールドデバイスはない。
さらに、自己診断を実行できるプロセス制御デバイスは、通常、デバイス製造メーカによりデバイスの中にハードコードされた（hardcoded）診断だけの実行に限られるため、（別のデバイス製造メーカによって開発されたルーチンを含むことがある）ホストやユーザによって作成された診断ルーチンやテストを実行することはできない。この状態のために、ユーザは、プラント内のさまざまなタイプのデバイスのすべてで同じテストを実行することはできない。
さらに、自己診断を実行するプロセス制御デバイスは、一般的には、プロセス診断を実行することができない。したがって、ホストデバイスは、いくつかの自己診断（つまり、デバイス診断）を実行することができるフィールドデバイスを有するシステム内においてもプロセス診断を実行するためにセットアップされなければならない。ただし、注記されたように、制御構成は、ホストがデバイスを同期して制御できるように構成し直されなければならないため、ホストデバイスが分散型機能を有するプロセス制御システムでプロセス診断を実行することは困難である。さらに、プロセス診断中で異なる制御スキームを使用することにより、プロセスの正常な動作中の制御スキーム実行に関して誤ったまたは正確ではない結果が生じることがある。また、診断機能を備えたフィールドデバイスは、ローカル診断機能を持たない他のフィールドデバイスを診断することはできなかった。
発明の概要
本発明は、プロセス制御ネットワーク内の、および好ましくは分散型制御機能を有するプロセス制御ネットワーク内の、ある特定のプロセス制御デバイス上で、およびある特定のプロセス制御デバイスからデバイス診断およびプロセス診断を実行する方法および実行するためのデバイスを目的としている。本発明に従って、（デバイス診断テストルーチンまたはプロセス診断テストルーチンである場合がある）診断テストルーチンは、プロセス制御ネットワークに関連する制御スキームを構成し直す必要なしに、そのプロセス制御デバイス上で診断を実行するために、プロセス制御デバイスに記憶され、それにより実現される。その結果、診断テストルーチンは、本発明に従って実現されるが、プロセスは、本質的にはプロセスの通常の動作中に実現されるものと同じ制御戦略の元で制御されている。さらに、本発明に従ったプロセス制御デバイスにより実現されるデバイス診断テストルーチンまたはプロセス診断テストルーチンは、ユーザまたはホストデバイスにより作成され、診断テストルーチンが実行される前にプロセス制御デバイスに送達されることがあり、それによりプロセス制御デバイスは、他のデバイス製造メーカにより供給されるルーチンを含む希望の診断テストルーチンを実現できるようになる。
本発明の１つの態様に従って、ニ線式デジタル動力式バスにより手動で結合される複数のフィールドデバイスを有するプロセス制御システムで使用されることが可能なフィールドデバイスは、空気圧流体制御弁、流体制御弁を開放位置から閉鎖位置までの範囲の位置に移動させる空気圧を作成するために空気圧配管により流体制御弁に結合される位置決め装置、および流体制御弁の位置を検知するために位置決め装置および流体制御弁に結合される位置センサを含む。圧力センサは、流体制御弁にかけられる空気圧を検知するために空気圧配管に結合され、電気から空気への変換器は、空気圧配管内の空気圧を電気信号の関数として制御するために空気圧配管により位置決め装置に結合される。電子コントローラは、電気から空気への変換器、圧力センサ、および位置センサに結合され、圧力センサにより検知される圧力、および位置センサにより検知される位置を示すフィードバック信号に基づいて、およびフィールドデバイス制御信号に基づいて電気信号を決定する制御論理回路を含む。さらに、デジタルインタフェースは、ニ線式デジタル動力式バスと電子コントローラに結合され、動力式バスから得られる電力をフィールドデバイスに供給するための回路、およびフィールドデバイス制御信号を含む信号をバスから受信し、フィールドデバイスのステータスを示す信号をバスに伝送する両方向通信回路を含む。
本発明の別の態様に従って、ニ線式全デジタル通信バスにより通信可能となるように結合される複数のデバイスを有するプロセス制御ネットワークで使用するためのフィールドデバイスは、ニ線式全デジタルバスに接続し、バス上での全デジタル通信を可能にするコントローラ、一連の診断テスト命令を有する診断テストルーチンを記憶するメモリ、およびフィールドデバイスを使用して診断テストを実現するためにメモリに記憶される診断テスト命令を実行するコントローラとを含む。フィールドデバイスは、診断テスト中に作成された診断データを収集するデータ収集ユニット、および収集された診断データを全デジタルフォーマットでバス上で通信する通信ユニットも含む。
好ましくは、コントローラは、プログラム言語を解釈するように適応されたプログラム言語インタプリタを含み、診断テスト命令はプログラム言語で記憶され、バスを介して複数のデバイスの内の第２デバイスからフィールドデバイスのコントローラに送達される。同様に、診断テスト命令は、希望されるようにデバイスおよび／またはプロセス診断を実行することができる。診断テスト命令がプロセス診断を指定する場合、データ収集ユニットは、診断テスト中に他のデバイスにより作成されるデータを受信するように適応される。
本発明の更なる態様に従えば、バスによって通信可能に結合された複数のデバイスを有するプロセスコントロールネットワークで使用されるフィールドデバイスは、一連の診断テスト命令を有する診断テストルーチンを格納するメモリと、メモリ内に格納された診断テスト命令を実行して診断テストを行うデバイスコントローラと、診断テストの間に生成された診断データを収集するデータ収集ユニットと、バスを介して複数の装置の第２のそれから診断テスト命令を受け取り、メモリ内の診断テスト命令を受け取り格納し、そして、バス上の収集された診断データを伝送する通信ユニットとを含んでいる。
本発明の更なるもう一つの態様に従えば、バスによって通信可能に結合された複数のデバイスを有するプロセスコントロールネットワークでプロセス診断テストを行うために使用されるフィールドデバイスは、フィールドデバイスによって実行されるべき一連の診断テスト命令を有するプロセス診断テストルーチンを格納するメモリと、メモリ内に格納されたプロセス診断テスト命令を実行してプロセス診断テストを行うデバイスコントローラとを含んでいる。また、フィールドデバイスは、プロセス診断テストの間にフィールドデバイスによって生成された診断データを収集し、そして、バスを介して複数の装置の第２のそれから更なるプロセス診断テスト命令を受け取るデータ収集ユニットを有している。フィールドデバイス内の通信ユニットは、プロセス診断テストが完了した後、収集された診断データとバス上の収集された更なるプロセス診断データを伝送する。
【図面の簡単な説明】
図１は、Fieldbusプロトコルを使用する例のプロセス制御ネットワークの概略ブロック図である。
図２は、その中の３つの機能ブロックのセットを有するFieldbusデバイスの概略ブロック図である。
図３は、図１のプロセス制御ネットワークのデバイスのいくつかの中での機能ブロックを示す概略ブロック図である。
図４は、図１のプロセス制御ネットワーク内のプロセス制御ループの制御ループ概略図である。
図５は、図１のプロセス制御ネットワークのバスのセグメントのマクロサイクルのタイミング概略図である。
図６は、二線式、ループ動力式、二通りの、デジタル通信ポジショナーを示す概略ブロック図である。
図７は、図６のデジタルフィールドデバイスの制御に於いて使用される適当なフィールドデバイスコントローラを表すブロック図である。
図８は、診断テストを実行するための技術を示すフローチャートである。
図９は、図６のデジタルフィールドデバイスをテストするための診断テストプロトコルを示すフローチャートである。
図１０Ａ、図１０Ｂ及び図１０は、本発明によるデバイス診断を実行するのに使用される異なる診断テスト信号を表すグラフである。
図１１Ａ及び図１１Ｂは、本発明による診断データ収集機能ブロックを含むコントロールループの概略図である。
図１２は、図１１の診断データ収集機能ブロックを使用するプロセス診断テストを実行するための診断テストプロトコルを表すフローチャートである。
好ましい実施例の説明
本発明の装置及びプロセス診断は、Fieldbusデバイスのセットを使用し、分散化または分散型手法でプロセス制御機能を実現するプロセス制御ネットワークといっしょに詳細に説明されるが、本発明の診断が、二線式バス以外に依存するプロトコル、およびアナログ通信だけ、またはアナログ通信とデジタル通信の両方をサポートするプロトコルを含む、それ以外のタイプのフィールドデバイスと通信プロトコルを使用して、分散型制御機能を実行するプロセス制御ネットワークとともに使用できることが注記されなければならない。したがって、このプロセス制御ネットワークがHART、PROFIBUSなどの通信プロトコル、または現在存在するか、将来開発される可能性のあるそれ以外の任意の通信プロトコルを使用するとしても、例えば、本発明の診断の装置又は、分散型制御機能を実行する任意の制御プロセスネットワークで使用することができる。更に、本発明の診断は、HARTネットワークのような分散コントロール機能を実行しない標準のプロセスコントロールネットワークとともに使用され得、そして、バルブ、ポジショナーを含むどのような所望のプロセスコントロール装置内でも使用され得る。
本発明の診断の詳細を説明する前に、Fieldbusプロトコル、このプロトコルに従って構成されたフィールドデバイス、およびFieldbusプロトコルを使用するプロセス制御ネットワーク内で通信がどのように発生するのかについての一般的な説明が示される。ただし、Fieldbusプロトコルはプロセス制御ネットワーク内で使用するために開発された比較的新しい全デジタル通信プロトコルである一方で、このプロトコルが技術で既知であり、出版、配布され、とりわけテキサス州オースティン（Austin,Texas）に本拠がある非営利団体であるFieldbus財団から入手できる多数の記事、パンフレット、および仕様書に詳細に説明されていることを理解する必要がある。特に、Fieldbusプロトコル、およびFieldbusプロトコルを使用するデバイスと通信し、そのデバイスにデータを記憶する手法は、ここに全体的に参照して組み込まれる、フィールドバス財団の通信技術仕様書およびユーザレイヤ技術仕様書として題されるマニュアルに詳しく説明される。
Fieldbusプロトコルは、計器または例えば工場やプラントなどのプロセス制御環境に位置するセンサ、アクチュエータ、コントローラ、弁などの「フィールド」装置を相互接続する二線式ループつまりバスへの標準化された物理インタフェースを提供する、全デジタル、シリアル両方向通信プロトコルである。Fieldbusプロトコルは、実質的には、プロセス設備内にフィールド計器（フィールドデバイス）用ローカルエリアネットワークを提供し、これらのフィールドデバイスがプロセス全体で分散された場所にある制御機能を実行し、総合的な制御戦略を実現するためにこれらの制御機能が実行される前後に互いに通信できるようにする。Fieldbusプロトコルは制御機能をプロセス制御ネットワーク全体に分散できるようにするため、それは典型的にはＤＣＳと対応する集中プロセスコントローラの複雑度を削減するか、その必要性をまったく排除する。
図１を参照すると、Fieldbusプロトコルを使用するプロセス制御ネットワーク１０は、プログラム論理コントローラ（ＰＬＣ）１３、多くのコントローラ１４、別のホストデバイス１５、およびフィールドデバイス１６，１８，２０，２２，２４，２６，２８，３０、および３２のセットなどの多くのそれ以外のデバイスに、二線式Fieldbusループつまりバス３４を介して接続されるホスト１２を含むことがある。バス３４は、ブリッジデバイス３０および３２によって分離される、さまざまなセクションまたはセグメント３４ａ、３４ｂ、および３４ｃを含む。セクション３４ａ、３４ｂ、および３４ｃのそれぞれは、バス３４に接続されるデバイスのサブセットを相互接続し、後述されるようにデバイス間の通信を可能にする。言うまでもなく、図１のネットワークは説明のためだけであり、プロセス制御ネットワークをFieldbusプロトコルを使用して構成できるそれ以外の多くの方法がある。典型的には、構成者は、フィールドデバイスがバス３４から取り除かれるときに新しいフィールドデバイスがバス３４に接続される時点を認識し、フィールドデバイス１６〜３２により生成されるデータを受け取り、ホスト１２または何らかの手法でホスト１２に接続されるそれ以外のデバイス内に位置することがある１つまたは複数のユーザ端末とインタフェースするだけではなく、（そのそれぞれが通信、および場合によっては制御機能を実行することができるマイクロプロセッサを含むという点で「スマート」なデバイスである）デバイスのそれぞれをセットアップしたり、構成する責任を負うホスト１２のようなデバイスの内の１つに位置する。
バス３４は、二線式の、純粋にデジタルな通信をサポートするか、可能にし、フィールドデバイス１６〜３２のようなそれに接続されるデバイスの任意のものまたはすべてに電力信号を提供することがある。代わりに、デバイス１２〜３２のどれかまたはすべてが専用の電源を備えたり、別個のワイヤ（図示されていない）を介して外部電源に接続されることがある。デバイス１２〜３２は、複数のデバイスがバスセグメント３４ａ、３４ｂ、および３４ｃを構成する同じワイヤの組に接続される標準型バスタイプコネクションでバス３４に接続されているとして図１に説明されているが、Fieldbusプロトコルは、各デバイスが（通常４〜２０ｍＡのアナログＤＣＳシステムに類似する）別個の二線式組を介してコントローラまたはホストに接続される２地点間通信、および各デバイスが、例えばプロセス制御ネットワーク内のフィールドデバイスの内の１つでのジャンクションボックスや端末領域である場合がある二線式バスでの１つの共通ポイントに接続されるツリー、つまり「支線」コネクションを含むその他のデバイス／ワイヤトポロジを可能にする。
データは、Fieldbusプロトコルに従って同じまたは異なる通信ボーレートつまり速度で、異なるバスセグメント３４ａ、３４ｂ、および３４ｃ上を送信されることがある。例えば、Fieldbusプロトコルは、図１のバスセグメント３４ｂと３４ｃによって使用されているとして示される毎秒３１．２５Ｋｂｉｔの通信速度（Ｈ１）、および通常、高度プロセス制御、遠隔入出力、および高速工場自動化用途に使用され、図１のバスセグメント３４ａによって使用されているとして示される毎秒１．０Ｍｂｉｔおよび／または毎秒２．５Ｍｂｉｔ（Ｈ２）通信速度を提供する。同様に、データは、電圧モードシグナリングまたは電流モードシグナリングを使用して、Fieldbusプロトコルに従ったバスセグメント３４ａ、３４ｂ、および３４ｃ上で送信されることがある。言うまでもなく、バス３４の各セグメントの最大長は、厳密に制限されていないが、代わりにそのセクションの通信速度、ケーブル種類、ワイヤサイズ、バス電力オプションなどによって決定される。
Fieldbusプロトコルは、バス３４に接続できるデバイスを３つのカテゴリ、つまり基本デバイス、リンクマスタデバイス、およびブリッジデバイスに分類する。（図１のデバイス１８，２０，２４、および２８などの）基本デバイスは通信する、つまりバス３４上でまたはバス３４から通信信号を送受することができるが、バス３４で発生する通信の順序またはタイミングを制御することはできない。（図１のホスト１２だけではなく、デバイス１６、２２および２６などの）リンクマスタデバイスは、バス３４上で通信し、バス３４上で通信信号のフローおよびタイミングを制御することができるデバイスである。（図１のデバイス３０および３２などの）ブリッジデバイスは、さらに大きなプロセス制御ネットワークを作成するために、Fieldbusの個々のセグメントや分岐で通信し、相互接続するように構成されたデバイスである。希望される場合、ブリッジデバイスは、バス３４の異なるセグメント上で使用される異なるデータ速度および／または異なるデータシグナリングフォーマットの間で変換し、バス３４のセグメントの間で移動する信号を増幅し、バス３４のさまざまなセグメントの間で流れる信号を濾波し、ブリッジが結合される先のバスセグメントの１つでデバイスによって受信されるように当てられたそれらの信号だけを通す、および／またはバス３４の異なるセグメントをリンクするために必要なそれ以外の処置を講じることがある。異なる速度で動作するバスセグメントを接続するブリッジデバイスは、ブリッジのさらに低速のセグメント側でリンクマスタ機能を備えなければならない。ホスト１２と１５、ＰＬＣ１３、およびコントローラ１４は、任意のタイプのフィールドバスデバイスでよいが、通常はリンクマスタデバイスとなる。
デバイス１２〜３２のそれぞれはバス３４で通信する機能を備え、重要なことに、バス３４上での通信信号を介してプロセスから、または別のデバイスから、デバイスによって取得されるデータを使用して１つまたは複数のプロセス制御機能を独立して実行する機能を備える。したがって、Fieldbusデバイスは、過去においてはＤＣＳの集中デジタルコントローラにより実行されていた総合的な制御戦略の部分を直接実現することができる。制御機能を実行するために、各Fieldbusデバイスは、デバイス内のマイクロプロセッサで実現される１つまたは複数の標準化された「ブロック」を含む。特に、各Fieldbusデバイスは、１つのリソースブロック、ゼロ個または１個以上の機能ブロック、およびゼロ個または１個以上の変換器ブロックを含む。これらのブロックはブロックオブジェクトと呼ばれる。
リソースブロックは、例えばデバイスタイプ、デバイス改訂表示、他のデバイスに特殊な情報がデバイスのメモリ内で入手できる場所の表示などを含むFieldbusデバイスの特性のいくつかに関するデバイスに特殊なデータを記憶し、通信する。さまざまなデバイス製造メーカが異なるタイプのデータをフィールドデバイスのリソースブロックに記憶するが、Fieldbusプロトコルに準拠する各フィールドデバイスはデータを記憶するリソースブロックを含む。
機能ブロックは、フィールドデバイスに関連する入力機能、出力機能、または制御機能を定義し、実現するので、機能ブロックは、通常、入力機能ブロック、出力機能ブロック、および制御機能ブロックと呼ばれる。しかし、ハイブリッド機能ブロックのようなそれ以外のカテゴリの機能ブロックが存在、または将来開発される可能性がある。各入力または出力機能ブロックは、（プロセス測定デバイスからのプロセス変数のような）少なくとも１つのプロセス制御入力または（作動デバイスに送信される弁位置のような）プロセス制御出力を作成するが、各制御機能ブロックは（性質が独占的である可能性がある）アルゴリズムを使用し、１つまたは複数のプロセス入力および制御入力から、１つまたは複数のプロセス出力を作成する。標準的な機能ブロックの例は、アナログ入力（ＡＩ）、アナログ出力（ＡＯ）、バイアス（Ｂ）、制御セレクタ（ＣＳ）、分離入力（ＤＩ）、分離出力（ＤＯ）、手動ローダ（ＭＬ）、比例／導関数（ＰＤ）、比例／積分／導関数（ＰＩＤ）、率（ＲＡ）、および信号セレクタ（ＳＳ）機能ブロックを含む。ただし、他の種類の機能ブロックが存在し、新しいタイプの機能ブロックが定義または作成され、Fieldbus環境で動作する可能性がある。
変換器ブロックは、機能ブロックの入力および出力を、センサおよびデバイスアクチュエータのようなローカルハードウェアデバイスを結合し、機能ブロックが、ローカルセンサの出力を読み取り、ローカルデバイスに弁部材を移動するなどの１つまたは複数の機能を実行するように命令する。変換器ブロックは、通常、ローカルデバイスによって送達される信号を解釈し、ローカルデバイスのタイプ、ローカルデバイスに関連する較正情報などを識別する情報などの、ローカルハードウェアデバイスを適切に制御するために必要な情報を記憶する。
大部分の機能ブロックは、所定の基準に基づいて警報やイベント表示を作成することができ、さまざまなモードで異なるように動作することができる。一般的には、機能ブロックは、例えば、ある機能ブロックのアルゴリズムが自動的に動作する自動モードで、例えば、機能ブロックの入力または出力が手動で制御されるオペレータモードで、ブロックが動作しない休止モード、ブロックの動作が別のブロックの出力から影響を受ける（によって決定される）カスケードモードで、およびリモートコンピュータがブロックのモードを決定する１つまたは複数のリモートモードで動作することがある。
重要なことには、各ブロックは、Fieldbusプロトコルによって定義される標準的なメッセージフォーマットを使用して、Fieldbusバス３４上で同じまたは異なるフィールドデバイス内の他のブロックと通信することができる。その結果、（同じデバイスまたは別のデバイスの）機能ブロックの組み合わせは、１つまたは複数の分散化制御ループを作成するために互いに通信できる。したがって、例えば、１つのフィールドデバイスでのＰＩＤ機能ブロックは、第２フィールドデバイス内のＡＩ機能ブロックの出力を受け取り、データを第３フィールドデバイス内のＡＯ機能ブロックに送達し、フィードバックとしてＡＯ機能ブロックの出力を受け取り、ＤＣＳコントローラとは別個で、それから離れたプロセス制御ループを作成するために、バスを介して接続されることがある。このようにして、機能ブロックの組み合わせは、集中ＤＣＳ環境から制御機能を移動し、ＤＣＳマルチ機能コントローラが監督機能または調整機能を実行できるようにしたり、それらを完全に全体で排除できるようにする。さらに、機能ブロックは、プロセスの容易な構成のためのグラフィックによるブロック指向型構造を提供し、これらのブロックは１つの一貫した通信プロトコルを使用できるため、異なる供給業者のフィールドデバイスの間での機能の分散を可能にする。
ブロックオブジェクトを含み、実現することに加え、各フィールドデバイスは、リンクオブジェクト、傾向オブジェクト、警報オブジェクト、およびビューオブジェクトを含む１つまたは複数のオブジェクトを含む。リンクオブジェクトは、フィールドデバイスの内部で、およびFieldbusバス３４全体の両方で（機能ブロックのような）ブロックの入力と出力の間のリンクを定義する。
傾向オブジェクトは、図１のホスト１２やコントローラ１４のような他のデバイスによるアクセスのための機能ブロックパラメータの局所的な傾向変動を可能にする。傾向オブジェクトは、例えば機能ブロックパラメータなどに関する短期履歴データを保持し、このデータを非同期でバス３４を経由して他のデバイスや機能ブロックに報告する。警報オブジェクトは、バス３４上で警報およびイベントを報告する。これらの警報またはイベントは、デバイスまたはデバイスのブロックの内の１つで発生するイベントに関係することがある。ビューオブジェクトは、標準的な人間／機械インタフェースで使用されるブロックパラメータの事前に定義されるグループ分けであり、ときどき表示するために他のデバイスに送信できる。
図２を参照すると、例えば図１のフィールドデバイス１６〜２８の内のどれかである可能性がある３つのFieldbusデバイスが、リソースブロック４８、機能ブロック５０，５１または５２、および変換器ブロック５３と５４を含むとして示されている。フィールドデバイスでは、（入力機能ブロックである場合がある）機能ブロック５０が、変換器ブロック５３を通して、例えば温度センサ、設定ポイント表示センタなどである場合があるセンサ５５に結合される。第２デバイスでは、（出力機能ブロックである場合がある）機能ブロック５１が、変換器ブロック５４を通して、弁５６のような出力装置に結合される。第３デバイスでは、（制御機能ブロックである場合がある）機能ブロック５２は、機能ブロック５２の入力パラメータの傾向を変動する（trending）ためにそれと関連する傾向オブジェクト５７を有する。
リンクオブジェクト５８は、関連するブロックのそれぞれのブロックパラメータを定義し、警報オブジェクト５９は関連するブロックのそれぞれに警報またはイベント通知を提供する。ビューオブジェクト６０は、機能ブロック５０，５１、および５２のそれぞれに関連し、それらが関連する機能ブロックのデータリストを含むまたは分類する。これらのリストには、さまざまな定義されたビューのセットのそれぞれに必要な情報が含まれている。言うまでもなく、図２のデバイスは単に例示的であり、ブロックオブジェクト、リンクオブジェクト、警報オブジェクト、傾向オブジェクト、およびビューオブジェクトなどの他の数の、および他のタイプのブロックオブジェクトが任意のフィールドデバイスで提供されることがある。
図３を参照すると、デバイス１６，１８および２４を位置決め装置／弁デバイスとして、およびデバイス２０，２２，２６および２８を送信機として描くブロック図は、位置決め装置／弁１６、送信機２０、およびブリッジ３０に関連する機能ブロックも示す。図３に示されるように、位置決め装置／弁１６は、リソース（ＲＳＣ）ブロック６１、変換器（ＸＤＣＲ）ブロック６２、および１個のアナログ出力（ＡＯ）機能ブロック６３、２個のＰＩＤ機能ブロック６４と６５、および１個の信号選択（ＳＳ）機能ブロック６９を含む多くの機能ブロックを含む。送信機２０は、１個のリソースブロック６１、２個の変換器ブロック６２、２個のアナログ入力（ＡＩ）機能ブロック６６と６７を含む。また、ブリッジ３０は、リソースブロック６１およびＰＩＤ機能ブロック６８を含む。
理解されるように、図３のさまざまな機能ブロックは、多くの制御ループで（バス３４上で通信することによって）いっしょに動作し、位置決め装置／弁１６、送信機２０、およびブリッジ３０の機能ブロックが位置する制御ループは、これらの機能ブロックのそれぞれに接続されるループ識別ブロックにより図３で識別される。このようにして、図３に示されるように、位置決め装置／弁１６のＡＯ機能ブロック６３およびＰＩＤ機能ブロック６４、および送信機２０のＡＩ機能ブロック６６は、ＬＯＯＰ１として示される制御ループ内で接続されるが、位置決め装置／弁１６のＳＳ機能ブロック６９、送信機２０のＡＩ機能ブロック６７、およびブリッジ３０のＰＩＤ機能ブロック６８は、ＬＯＯＰ２として示される制御ループでされる。位置決め装置／弁１６の他のＰＩＤ機能ブロック６５は、ＬＯＯＰ３として示される制御ループ内で接続される。
図３のＬＯＯＰ１として示される制御ループを構成する相互接続された機能ブロックは、図４に描かれるこの制御ループの概略図でさらに詳細に示される。図４からわかるように、制御ループＬＯＯＰ１は、位置決め装置／弁１６のＡＯ機能ブロック６３とＰＩＤ機能ブロック６４、および送信機２０のＡＩ機能ブロック６６の間の通信リンクにより完全に形成されている。図４の制御ループ図は、これらの機能ブロックのプロセスおよび制御の入力と出力を接続する回線を使用するこれらの機能ブロックの間の通信相互接続を示す。したがって、プロセス測定またはプロセスパラメータ信号を含むことがあるＡＩ機能ブロック６６の出力は、バスセグメント３４ｂを介して、ＡＯ機能ブロック６３の入力に通信可能となるように（communicatively）結合される制御信号を含む出力を有するＰＩＤ機能ブロック６４の入力に通信可能となるように結合される。例えば、弁１６の位置を示すフィードバック信号を含む、ＡＯ機能ブロック６３の出力は、ＰＩＤ機能ブロック６４の制御入力に接続される。ＰＩＤ機能ブロック６４は、ＡＩ機能ブロック６６からのプロセス測定信号とともにこのフィードバック信号を使用し、ＡＯ機能ブロック６３の適切な制御を実現する。言うまでもなく、図４の制御ループ図で回線によって示されるコネクションは、ＡＯ機能ブロックおよびＰＩＤ機能ブロック６３と６４の場合でのように、機能ブロックが同じフィールドデバイス（例えば、位置決め装置／弁１６）内にあるときに、フィールドデバイス内で内部的に実行されることがあるか、これらの機能は標準的なFieldbus同期通信を使用して二線式通信バス３４で実現されることがある。言うまでもなく、他の制御ループは、他の構成で通信可能となるように相互接続される他の機能ブロックにより実現される。
通信と制御の活動を実現し、実行するために、Fieldbusプロトコルは、物理層、通信「スタック」、およびユーザ層として識別される技術の３つの一般的なカテゴリを使用する。ユーザ層は、（機能ブロックのような）ブロックおよび特定のプロセス制御デバイスつまりフィールドデバイス内のオブジェクトという形で提供される制御機能および構成機能を含む。ユーザ層は、典型的にはデバイス製造メーカによって独占的に設計されるが、Fieldbusプロトコルによって定義される標準メッセージフォーマットに従ってメッセージを送受信し、標準的にユーザによって構成されることができなければならない。物理層および通信スタックは、二線式ワイヤバス３４を使用して標準化された手法でさまざまなフィールドデバイスのさまざまなブロックの間で通信を達成するために必要とされ、よく知られている開放型システム間相互接続（ＯＳＩ）で層化された通信モデルによってモデル化される可能性がある。
ＯＳＩ層１に相当する物理層は、各フィールドデバイスおよびバス３４に埋め込まれ、Fieldbus伝送媒体（二線式バス３４）から受け取られる電磁信号を、フィールドデバイスの通信スタックによる使用が可能なメッセージに変換するために動作する。物理層は、バス３４、およびフィールドデバイスの入力と出力でバス３４に存在する電磁信号と見なしてよい。
各Fieldbusデバイスに存在する通信スタックは、ＯＳＩ層２に相当するデータリンク層、Fieldbusアクセスサブレイヤ（sublayer）、およびＯＳＩ層６に相当するFieldbusメッセージ指定層を含む。FieldbusプロトコルではＯＳＩ層３〜５用の対応する構造はない。ただし、フィールドバスデバイスのアプリケーションは層７を含むが、ユーザ層はＯＳＩプロトコルでは定義されていない層８である。通信スタック内の各層が、Fieldbusバス３４で送信されるメッセージまたは信号の一部を符号化または復号かする責任を負う。その結果、通信スタックの層は、プリアンブル、フレーム開始デリミタとフレーム終了デリミタのようなFieldbus信号の一定の部分を追加または削除し、場合によってはFieldbus信号のフレーム除去（stripped）部分を復号化し、信号やメッセージの残りがどこで送信されなければならないのか、または信号が、例えば受信フィールドデバイス内にない機能ブロックのメッセージやデータを含んでいるために廃棄されなければならないかどうかを特定する。
データリンク層は、さらに詳細に後述されるリンクアクティブスケジューラと呼ばれる集中化バススケジューラに従って、バス３４へのメッセージの伝送を制御し、バス３４へのアクセスを管理する。データリンク層は、伝送媒体上の信号からプリアンブルを削除し、受信されたプリアンブルを使用し、入信Fieldbus信号とフィールドデバイスの内蔵クロックを同期することができる。同様に、データリンク層は、通信スタック上のメッセージを物理的なFieldbus信号に変換し、これらの信号をクロック情報で符号化し、二線式バス３４での伝送のための適切なプリアンブルを有する「同期シリアル」信号を作成する。復号化プロセスの間に、データリンク層は、フレーム開始デリミタとフレーム終了デリミタのようなプリアンブル内の特殊符号を認識し、特定のFieldbusメッセージの始まりと終わりを識別し、バス３４から受信される信号またはメッセージの完全性を検証するためにチェックサムを実行することがある。同様に、データリンク層は、フレーム開始デリミタとフレーム終了デリミタを通信スタックで追加し、これらの信号を適切なときに伝送媒体に配置することによって、バス３４上でFieldbus信号を送信する。
Fieldbusメッセージ仕様層は、ユーザ層（つまり、フィールドデバイスの機能ブロック、オブジェクトなど）が、メッセージフォーマットの標準セットを使用しバス３４全体で通信できるようにし、通信サービス、メッセージフォーマット、および通信スタック上に置かれ、ユーザ層に提供されるメッセージを構築するために必要とされるプロトコル動作を記述する。Fieldbusメッセージ仕様層は、ユーザ層用の標準化された通信を供給するため、特定のFieldbusメッセージ仕様通信サービスが、前述の目的のタイプごとに定義される。例えば、Fieldbusメッセージ仕様層は、ユーザがデバイスのオブジェクトディショナリを読み取ることができるようにするオブジェクトディクショナリサービスを含む。オブジェクトディクショナリは、デバイスの（ブロックオブジェクトのような）オブジェクトのそれぞれを記述するか、識別するオブジェクト記述を記憶する。Fieldbusメッセージ仕様層は、ユーザが、デバイスの１つまたは複数のオブジェクトに関連して、この後に記述される仮想通信関係（ＶＣＲ）として知られる通信関係を読み取り、変更することができるようにするコンテキスト管理サービスも提供する。さらに、依然として、Fieldbusメッセージ仕様層は、そのすべてがFieldbusプロトコルではよく知られており、したがってここではさらに詳細に説明されない可変アクセスサービス、イベントサービス、アップロードサービスとダウンロードサービス、およびプログラム呼出しサービスを提供する。Fieldbusアクセスサブレイヤは、Fieldbusメッセージ仕様層をデータリンク層にマッピングする。
これらの層の動作を許す、つまり可能にするために、各Fieldbusデバイスは、ＶＣＲ、動的変数、統計、リンクアクティブスケジューラタイミングスケジュール、機能ブロック実行タイミングスケジュール、およびデバイスタグとアドレス情報を記憶するデータベースである管理情報ベース（ＭＩＢ）を含む。言うまでもなく、ＭＩＢ内の情報は、標準的なFieldbusメッセージやコマンドを使用して任意の時点でアクセスまたは変更することができる。さらに、デバイス記述が、通常、各デバイスで提供され、ユーザやホストにＶＦＤ内の情報の拡張図を提供する。ホストによって使用されるために、典型的にはトークン化されなければならないデバイス記述は、ホストがデバイスのＶＦＤ内のデータの意味を理解するために必要とされる情報を記憶する。
理解されるように、プロセス制御ネットワーク全体で分散される機能ブロックを使用して任意の制御戦略を実現するためには、機能ブロックの実行は、特定の制御ループ内の他の機能ブロックの実行に関して正確にスケジュールされなければならない。同様に、さまざまな機能ブロックの間の通信は、適切なデータが、そのブロックが実行する前に各機能ブロックに提供されるように、バス３４上で正確にスケジュールされなければならない。
さまざまなフィールドデバイス（およびフィールドデバイス内のさまざまなブロック）がFieldbus伝送媒体上でどのように通信するのかは、ここで図１に関して説明される。通信が発生するために、バス３４の各セグメントでのリンクマスタデバイスの１つ（例えば、デバイス１２，１６、および２６）が、バス３４の関連するセグメント上での通信をアクティブにスケジュールし、制御するリンクアクティブスケジューラ（ＬＡＳ）として動作する。バス３４の各セグメントごとのＬＡＳは、各デバイスの各機能ブロックがバス３４で定期的な通信活動を開始することがスケジュールされている時間、およびこの通信活動が発生する時間の長さを含む通信スケジュール（リンクアクティブスケジュール）を記憶し、更新する。バス３４のセグメントごとに一方の１つだけのアクティブＬＡＳしかない場合があるが、（セグメント３４ｂでのデバイス２２のような）他方のリンクマスタデバイスはバックアップＬＡＳとして役立ち、例えば現在のＬＡＳが失敗するとアクティブになる。基本デバイスは、任意の時点でＬＡＳになる機能は備えていない。
一般的には、バス３４での通信活動は、そのそれぞれがバス３４の特定のセグメントでアクティブな機能ブロックごとに１つの同期通信、およびバス３４のセグメントでアクティブな１つまたは複数の機能ブロックに１つまたは複数の非同期通信を含む、繰り返されたマクロサイクルに分けられる。デバイスは、たとえそれが物理的にバス３４の別のセグメントに接続されていても、バス３４上でのブリッジおよびＬＡＳの調整された動作により、アクティブとなる、つまりバス３４の任意のセグメントにデータを送信し、そこからデータを受信することができる。
各マクロサイクルの間、バス３４の特定のセグメントでアクティブである機能ブロックのそれぞれは、通常、別であるが正確にスケジュールされた（同期）時間で、および別の正確にスケジュールされた時間で実行し、適切なＬＡＳにより作成される強制データコマンドに応えてバス３４のそのセグメントでその出力データを公表する。好ましくは、各機能ブロックは、機能ブロックの実行期間の終了直後にその出力データを公表するようにスケジュールされる。さらに、さまざまな機能ブロックのデータ公表時間は、バス３４のある特定のセグメントでの２つの機能ブロックが同時にデータを発表しないように、連続してスケジュールされる。同期通信が発生していない時間中、各フィールドデバイスは、同様に、警報データ、表示データなどを、トークン駆動型通信を使用して非同期で伝送することが許される。実行時間および各機能ブロックの実行を完了するために必要な時間の量は、機能ブロックが常駐するデバイスの管理情報ベース（ＭＩＢ）に記憶されるが、前記に注記されるようにバス３４のセグメント上のデバイスのそれぞれに強制データコマンドを送信するための時間はそのセグメントのＬＡＳデバイスのＭＩＢに記憶される。これらの時間は、機能ブロックが、バス３４に接続されるデバイスのすべてによって知られている「絶対リンクスケジュール開始時間」の開始からのオフセットとして、データを実行または送信する時間を特定するため、通常、オフセット時間として記憶される。
各マクロサイクルの間に通信を達成するには、ＬＡＳ、例えば、バスセグメント３４ｂのＬＡＳ１６は、リンクアクティブスケジュールに記憶される伝送時間のリストに従ってバスセグメント３４ｂのデバイスのそれぞれに強制データコマンドを送信する。強制データコマンドを受信すると、デバイスの機能ブロックは、特定の時間量の間、その出力データをバス３４で公表する。機能ブロックのそれぞれは、通常、そのブロックの実行がブロックが強制データコマンド受信することがスケジュールされる直前に完了されるようにスケジュールされるため、強制データコマンドに応えて公表されるデータは、機能ブロックのもっとも最近の出力データでなければならない。ただし、機能ブロックがゆっくりと実行しており、強制データコマンドを受信したときに新しい出力をラッチしていない場合には、機能ブロックは、機能ブロックの前回の実行中に生成された出力データを発表し、タイムスタンプを使用して、発表されたデータが古いデータであることを示す。
ＬＡＳがバス３４の特定のセグメント上の機能ブロックのそれぞれに強制データコマンドを送信した後、損機能ブロックが実行している時間の間、ＬＡＳは、非同期通信活動を発生させる可能性がある。非同期通信を達成するためには、ＬＡＳはパストークンメッセージをある特定のフィールドデバイスに送信する。フィールドデバイスがパストークンメッセージを受信すると、そのフィールドデバイスはバス３４（またはそのセグメント）に完全なアクセスを得て、警報メッセージ、傾向データ、オペレータ設定ポイント変更などの非同期メッセージを、メッセージが完了するまで、または割り当てられた最大「トークン保持時間」が満了するまで送信することができる。その後で、フィールドデバイスはバス３４（またはその特定のセグメント）をリリースし、ＬＡＳはパストークンメッセージを別のデバイスに送信する。このプロセスは、マクロサイクルの最後まで、またはＬＡＳが強制データコマンドを送信し、同期通信を達成するようにスケジュールされるまで繰り返す。言うまでもなく、メッセージトラフィックの量およびバスの特定のセグメントに結合されるデバイスとブロックの数に応じて、必ずしもすべてのデバイスが各マクロサイクル中にパストークンメッセージを受け取らない可能性がある。
図５は、図１のバスセグメント３４ｂの機能ブロックが、バスセグメント３４ｂの各マクロサイクルの間に実行する時間、および同期通信が、バスセグメント３４ｂと対応する各マクロサイクルの間に発生する時間を描くタイミング概略図を示す。図５のタイミングスケジュールでは、時間は水平軸に示され、（図３の）位置決め装置／弁１６および送信機２０の異なった機能ブロックに対応する活動は垂直軸に示される。機能ブロックのそれぞれが動作する制御ループは、サブスクリプト名称として図５に特定される。したがって、ＡＩＬＯＯＰ１は送信機２０のＡＩ機能ブロック６６を指し、ＰＩＤＬＯＯＰ１は位置決め装置／弁１６などのＰＩＤ機能ブロック６４を指す。示された機能ブロックのそれぞれのブロック実行期間はクロスハッチされたボックスによって描かれるが、スケジュールされた各同期通信は図５の垂直バーによって特定される。
このようにして、セグメント３４ｂ（図１）の特定のマクロサイクル中に、図５のタイミングスケジュールに従い、ＡＩＬＯＯＰ1機能ブロックがまずボックス７０により指定される時間期間実行する。それから、垂直バー７２によって示される時間期間中、ＡＩＬＯＯＰ１機能ブロックの出力は、バスセグメント３４ｂのＬＡＳからの強制データコマンドに応えてバスセグメント３４ｂ上で公表される。同様に、ボックス７４，７６，７８，８０および８１が、（異なるブロックのそれぞれに対し異なる）機能ブロックＰＩＤＬＯＯＰ１，ＡＩＬＯＯＰ２、ＡＯＬＯＯＰＩ、ＳＳＬＯＯＰ２およびＰＩＤＬＯＯＰ３それぞれの実行時間を示す一方、垂直バー８２、８４、８６、８８および８９が、機能ブロックＰＩＤＬＯＯＰ１、ＡＩＬＯＯＰ２、ＡＯＬＯＯＰ１、ＳＳＬＯＯＰ２、およびＰＩＤＬＯＯＰ３それぞれがバスセグメント３４ｂ上でデータを公表する時間を示す。
明らかとなるように、図５のタイミング概略図は、機能ブロックのどれかの実行時間中、および機能ブロックが実行していないマクロサイクルの最後での時間中、および同期通信がバスセグメント３４ｂで発生しているときに発生する可能性のある、非同期通信活動に使用できる時間も示す。言うまでもなく、希望される場合には、さまざまな機能ブロックを同時に実行するように意図的にスケジュールすることが可能であり、例えば他のデバイスが機能ブロックによって作成されるデータに加入していない場合、すべてのブロックがバスでデータを公表しなければならないわけではない。
フィールドデバイスは、各フィールドデバイスのスタックのFieldbusアクセスサブレイヤに定義される仮想通信関係（ＶＣＲ）を使用して、データおよびメッセージをバス３４上で公表または伝送することができる。クライアント／サーバＶＣＲは、バス３４上のデバイス間の待ち行列に入れられた、スケジュールされていないユーザによって始動される1対１の通信に使用される。このような待ち行列に入れられたメッセージは、過去のメッセージを上書きすることなく、その優先順位に従い、伝送のために提出された順序で送受される。したがって、フィールドデバイスは、ＬＡＳからパストークンメッセージを受信し、リクエストメッセージをバス３４上の別のデバイスに送信するときにクライアント／サーバＶＣＲを使用することができる。要求者が「クライアント」と呼ばれ、リクエストを受け取るデバイスが「サーバ」と呼ばれる。サーバは、ＬＡＳからパストークンメッセージを受け取ると応答を送信する。クライアント／サーバＶＣＲは、例えば、設定ポイント変更、チューニングパラメータのアクセスと変更、警報肯定応答、およびデバイスアップロードとダウンロードなどのオペレータが始動するリクエストを達成するために使用される。
レポート分配ＶＣＲは、待ち行列に入れられ、スケジュールされず、ユーザによって始動される1対多通信に使用される。例えば、イベントまたは傾向レポートを持つフィールドデバイスがＬＡＳからパストークンを受信すると、そのフィールドデバイスはそのメッセージをそのデバイスの通信スタックのFieldbusアクセスサブレイヤに定義される「グループアドレス」に送信する。そのＶＣＲ上で傾聴するように構成されるデバイスがレポートを受け取る。レポート分配ＶＣＲタイプは、通常、オペレータコンソールに警報通知を送信するためにFieldbusデバイスによって使用される。
公表者／加入者ＶＣＲタイプは、バッファに入れられる１対多通信に使用される。バッファに入れられた通信とは、データの最新バージョンだけを記憶、送信する通信であるため、新しいデータは過去のデータを完全に上書きする。機能ブロック出力は、例えばバッファに入れられるデータを含む。「公表者」フィールドデバイスは、公表者／加入者ＶＣＲタイプ使用して、公表者デバイスがＬＡＳからまたは加入者デバイスから強制データメッセージを受信すると、バス３４上の「加入者」フィールドデバイスのすべてにメッセージを公表または一斉送信する。公表者／加入者関係は事前に決められ、各フィールドデバイスの通信スタックのFieldbusアクセスサブレイヤ内に定義、記憶される。
バス３４上で適切の通信活動を保証するために、各ＬＡＳは定期的に時間分配メッセージをバス３４のセグメントに接続されるフィールドデバイスのすべてに送信し、受信側デバイスが互いに同期するようにそのローカルアプリケーション時間を調整できるようにする。これらの同期メッセージの間、クロック時間は、それ自体の内蔵クロックに基づき各デバイス内で独自に維持される。クロック同期により、フィールドデバイスは、例えば、データが作成された時間を示すためにFieldbusネットワーク全体でデータにタイムスタンプを付けることができる。
さらに、各バスセグメント上の各ＬＡＳ（およびそれ以外のリンクマスタデバイス）は、バス３４のそのセグメントに接続されているすべてのデバイス、つまりパストークンメッセージに適切に応答しているデバイスのすべてのリストである「ライブリスト」を記憶する。ＬＡＳは、ライブリスト上にないプローブノードメッセージを定期的に送信することによって、継続的にバスセグメントに追加される新しいデバイスを認識する。実際、各ＬＡＳは、それが、パストークンメッセージをライブリスト中のフィールドデバイスのすべてに送信するサイクルを完了した後に、少なくとも１つのアドレスを調べるように要求される。フィールドデバイスが調べられたアドレスに存在し、プローブノードメッセージを受信すると、デバイスはただちにプローブ応答メッセージを返す。プローブ応答メッセージを受信すると、ＬＡＳはそのデバイスをライブリストに追加し、ノード起動メッセージを調べられたフィールドデバイスに送信することによって確認する。フィールドデバイスは、そのフィールドデバイスがパストークンメッセージに適切に応答する限り、ライブリストにとどまる。ただし、ＬＡＳは、フィールドデバイスが、３回連続して試した後に、トークンを使用しないか、またはただちにトークンをＬＡＳに返さない場合、フィールドデバイスをライブリストから削除する。フィールドデバイスがライブリストに追加されたり、ライブリストから削除されると、ＬＡＳはライブリスト中の変更をバス３４の適切なセグメント上の他のすべてのリンクマスタデバイスに一斉送信し、各リンクマスタデバイスが、ライブリストのカレントコピーを維持できるようにする。
前記に注記されたように、フィールドデバイスとその機能ブロック間の通信相互接続は、ユーザにより決定され、例えばホスト１２に位置する構成アプリケーションを使用してプロセス制御ネットワーク１０内で実現される。しかし、構成された後、プロセス制御ネットワーク１０は、デバイス診断やプロセス診断に対していっさい考慮せずに動作するため、診断機能ではなく標準的なＩ／Ｏ機能を実行するためにホスト１２とインタフェースする。
ユーザが診断の実行を希望するとき、ユーザは、ホスト１２に設定ポイント変更を、例えばＬＯＯＰ１のＡＯ機能ブロック６３に送信させ、ＡＯ機能ブロック６３に関連する傾向オブジェクトを使用し、ＡＯ機能ブロック６３内のフィードバックを記録することがある。しかし、この種の通信を実行するためには、ホスト１２は、ホスト１２がＬＡＳからパストークンメッセージを受信したときだけホスト１２にバス３４へのアクセスを許す非同期（未公表）通信を使用しなければならない。その結果、ホスト１２により作成される診断信号の異なる部分が、正確に決定された時間（または正確にスケジュールされた時間）にＡＯ機能ブロック６３に到達しない可能性があり、これは、ＡＯ機能ブロック６３で受信される診断信号が、任意の特定の時間にバス３４上での通信積滞により、少なくとも部分的に決定される形状を有することを意味する。このため、非同期通信を使用して送信された診断信号は、厳密には決定的ではなく、したがって、デバイスまたはプロセスで診断を実行する上で非常に有効でない可能性がある。さらに、ホスト１２は、傾向オブジェクト（複数の場合がある）により収集されるフィードバックデータが上書きなどのために失われないことを保証することはできない。また、ホスト１２は、ＰＩＤ機能ブロック６４のようなＬＯＯＰ１内の他の機能ブロックのモードを、そのブロックのモードを特に変更することなく制御することはできない。
現在まで、プロセス内の完全かつ厳密に決定的な診断を保証するためには、ユーザはプロセス制御ネットワーク１０をオフラインにし、ホスト１２が設定ポイント変更を適切なデバイスに送信し、同期通信を介して適切なデバイスにより測定されるデータを受信できるように、その中の通信インタフェースを構成し直さなければならなかった。しかしながら、前記に注記されたように、この手順はプロセスを停止させ、オペレータが、診断が実行されなければならないときは必ずプロセス制御ネットワークを構成し直すことを要求し、その両方とも望ましくない。さらに、ホスト１２によりこの診断手順中に実現される制御は、プロセスの正常な動作中に通信可能となるようにリンクされた機能ブロックに実行されている制御とは異なるため、収集されたプロセスデータは、プロセスが正常に制御されている間のプロセスの動作を示さない可能性がある。
以上の不利な点を、例えばFieldbusプロセス制御ネットワークで克服するために、デバイス診断手順またはプロセス診断手順がフィールドデバイス内に記憶され、それから実現され、そのデバイス上でまたはそのデバイスを使用してデバイスおよび／またはプロセス診断を実行するために使用されることがある。機能ブロックとして実現される可能性のある診断手順は、機能ブロックまたはそれがその中に位置するデバイスの、および（例えば、Fieldbusプロトコルの公表者／加入者ＶＣＲなどの）同期定期通信を使用するバス３４などでデバイスパラメータや他のプロセスパラメータの測定値などのデータを受け取るその他の構成要素と通信するように構成される。このようにして、診断ルーチンは、それがその中に位置するデバイスを決定的に制御し、定期的にデバイスパラメータまたはプロセスパラメータに関するデータを受け取り、記憶することができる。
ここでは図６を参照すると、概略ブロック図が、ニ線式ループ動力式の両方向デジタル通信を行う位置決め装置／弁の組み合わせである（図３の）デジタルフィールドデバイス１６を示す。デジタルフィールドデバイス１６は、多様な空気配管および電気配管により相互接続される、フィールドデバイスコントローラ１０２、Ｉ／Ｐ変換器１０４、空気リレー１０６、アクチュエータ１０８、および弁１０９を含む。
フィールドデバイス１６は、好ましくはFieldbus基準に従って、動作信号を受信し、ニ線式バスセグメント３４ｂを介してデジタル形式でステータス情報およびデータを伝送するため、ニ線式位置決め装置である。同様に、フィールドデバイス１６は、おもにデバイスコントローラ１０２およびＩ／Ｐ変換器１０４を駆動するために、ニ線式連続ループバスセグメント３４ｂを介して動力を受け取るため、ループ動力式デバイスである。
図６に示されるように、Ｉ／Ｐ変換器１０４は、Ｉ／Ｐ変換器制御配管１１０によりデバイスコントローラ１０２に電気的に接続され、示された実施例においては、アナログ制御信号を使用してデバイスコントローラ１０２と通信する。
Ｉ／Ｐ変換器１０４は、弁１０９の作動を引き起こし、電気信号を空気位置決め装置用の空気圧に変換するための電子機械デバイスできわめて有効である。アクチュエータ１０８は、弁１０９の（弁ステムである可能性がある）弁部材１１４の位置を制御するが、位置センサ１１６は、弁部材１１４の位置を検出し、デバイスコントローラ１０２に信号線路１１７を介して通信されるフィードバック信号を作成する。この位置信号は、Ｉ／Ｐ変換器１０４が、弁部材１１４を希望される位置に位置させるように空気圧を駆動するように、フィールドデバイス１６の動作を制御するために、デバイスコントローラ１０２により使用されることがある。位置および他のフィードバック情報は、デバイスコントローラ１０２の記憶装置またはメモリ内に記憶され、バス３４を介して外部でアクセスされることがある。
標準であるように、フィールドデバイス１６は、Ｉ／Ｐ変換器１０４および空気リレー１０６に接続される空気配管１１８を介して外部ソース（図示されていない）からの加圧空気の供給を受ける。通常、外部空気ソースとＩ／Ｐ変換器１０４の間に配置される入力センサ１２０は、空気配管１１８内の入力空気供給圧力を測定し、この測定値をデバイスコントローラ１０２に送達する。Ｉ／Ｐ変換器１０４は空気制御配管１２２を介して空気リレー１０６に接続され、Ｉ／Ｐセンサ１２４は、Ｉ／Ｐ変換機１０４と空気リレー１０６の間に配置され、配管１２２内の空気供給圧力を測定する。同様に、空気リレー１０６は、空気作動配管１２６を介してアクチュエータ１０８に接続され、リレーセンサ１２８は空気リレー１０６とアクチュエータ１０８の間に配置され、配管１２６内の空気供給圧力を測定する。空気配管１１８，１２２および１２６は、変換器１０４および弁１０９を相互接続する単一の空気配管の一部と考えられる。
運転中、デバイスコントローラ１０２は、Ｉ／Ｐ変換器１０４を制御し、空気制御配管１２６内の制御された弁動作圧を設定することにより、弁１０９の作動を制御する。デバイスコントローラ１０２は、Ｉ／Ｐ変換機制御配管１１０を介して、制御信号をＩ／Ｐ変換器１０４に送信し、Ｉ／Ｐ変換器１０４とリレー１０６の組み合わせの出力圧力が、アクチュエータ１０８の制御入力に適用される約３〜１００ｐｓｉ（０．２１〜７．０６ ｋｓｃｍ）の間となるように制御する。アクチュエータ１０８は、弁１０９を動作するために適用される出力圧力を作成する。
このようにして、既知であるように、Ｉ／Ｐ変換器１０４は、電気信号を空気圧信号に変換する。適切なＩ／Ｐ変換器１０４の一例は、参照してここに全体として組み込まれる、１９９５年８月５日にB.J.Burlageらに発行された「電子・空気コンバータ（Electro-Pneumatic Converter）」と題する米国特許第５，４３９，０２１号に説明される。同様に、空気増幅器として役立つ空気リレー１０６は、デバイスコントローラ１０２により命令されるようにＩ／Ｐ変換器１０４により制御され、空気作動信号線路１２６の空気圧を制御された量まで増加する。このようにして、一般的には、空気リレー１０６は、制御された出力圧力を、デバイスコントローラ１０２からの制御信号に応えて、アクチュエータやピストンなどの負荷または活用デバイスに供給する。適切なリレーは、参照してここに全体として組み込まれる、１９９０年１２月４日にS.B.Paullusらに発行された「４モード空気リレー（Four Mode Pneumatic Relay）」と題する米国特許第４，９７４，６２５号に説明される。図解された実施例では、リレー１０６は、直接／スナップ、直接／比例、逆転／スナップ、または逆転／比例動作に構成可能である多機能４モード空気リレーである。比例モードでは、空気リレー１０６は、圧力または力入力に比例する圧力出力を開発する。オン／オフまたはスナップモードでは、空気リレー１０６は、通常はかけられる供給の圧力に等しい一定の圧力出力を、定義された範囲の力または圧力制御入力の適用に応えて作成する。直接運転モードでは、空気リレー１０６の出力圧力は、増大する入力信号とともに上昇する。逆転運転モードでは、リレー出力圧力は、増大する入力信号とともに減少する。
入力センサ１２０、Ｉ／Ｐセンサ１２４、およびリレーセンサ１２８は、圧力信号を電気信号に変換するための電圧から圧力への信号コンバータを備え、フィードバック信号を、配管１３０を介してデバイスコントローラ１０２に供給する圧力変換器である。Ｉ／Ｐセンサ１２４は、Ｉ／Ｐ変換器１０４または空気リレー１０６のどちらかの故障を検出し、例えば、故障が機械的な故障であるのか、電気的な故障であるのかを判断するために診断上有効である。Ｉ／Ｐセンサ１２４は、デジタルフィールドデバイス１６への空気圧力入力が十分である旨の決定を含むいくつかのシステムの問題点を検出するためにも有効である。その結果、Ｉ／Ｐセンサ１２４を使用すると、これらのデバイスを必要ならば素早く交換できるように、Ｉ／Ｐ変換器１０４および空気リレー１０６のステータスを迅速に診断できるようにする。
１つの実施例においては、デジタルフィールドデバイス１６で使用するための適切な弁１０９は、参照してここにその全体として組み込まれる、１９９０年１２月１１日にW.V.Fitzgeraldに発行される「流体制御弁用の診断機器および方法（Diagnostic Apparatus and Method for Fluid Control Valves）」と題する米国特許第４，９７６，１４４号に説明されるアナログデバイスで使用されるスライド式ステム弁上で、ばねおよびダイヤフラムアクチュエータを使用する弁アクチュエータアセンブリである。この例示的な実施例においては、約３ｐｓｉ（０．２１ ｋｓｃｍ）という圧力信号が、デバイスコントローラ１０２によりＩ／Ｐ変換器１０４に適用される約４ｍＡ信号に応えてアクチュエータ１０８に提供され、弁１０９を完全開放位置から移動するには不充分である空気作動信号線路１２６内での対応する圧力を生じさせる。フィールドデバイスコントローラ１０２がＩ／Ｐ変換器１０４にかけられる制御電流を約２０ｍＡに変更すると、Ｉ／Ｐ変換器１０４は、弁１０９を完全閉鎖位置に押しやる、約１５ｐｓｉ（１．０６ ｋｓｃｍ）という空気作動配管１２６内での圧力を生じさせる。完全開放位置と完全閉鎖位置の間での弁１０９の多様な位置は、４ｍＡから２０ｍＡまでの範囲でＩ／Ｐ変換器１０４にかけられる入力電流を制御するデバイスコントローラ１０２の動作により達成される。
デバイスコントローラ１０２は、相対的に高速のデジタル通信を実行し、制御信号を受信し、バス３４を介してプロセッサ制御ネットワーク１０内の外部プロセッサまたはワークステーションに位置および圧力の情報を伝送する。デバイスコントローラ１０２は、関連データが分析に利用できるように、複数の診断テストの結果を記憶するための記憶域つまりメモリを含む。デバイス診断のような診断動作は、通常はソフトウェアプログラムコードの形を取り、典型的には、プロセッサやホストワークステーション１２のような外部デバイス内で実行するプログラムコードと組み合わせて、フィールドデバイス１６のデバイスコントローラ１０２内で符号化、記憶、および実行される。
弁１０９のデバイス診断評価は、完全開放位置と完全閉鎖位置の間で弁１０９を試験するのに十分な範囲でＩ／Ｐ変換器１０４にかかる入力電流を制御するデバイスコントローラ１０２の動作を通して実行されることがある。デバイス診断評価中、入力センサ１２０、Ｉ／Ｐセンサ１２４、およびリレーセンサ１２８の出力が、デバイスコントローラ１０２により監視され、分析に使用される空気配管１１８，１２２、および１２６それぞれでの空気圧を検出する。位置センサ１１６の出力も監視され、弁１０９内のバルブプラグ（図示されていない）の位置または移動に相当する、弁ステム１１４の位置または移動を検出する。
このようにして、弁１０９のテスト動作サイクルは、制御された可変電流をＩ／Ｐ変換器１０４に適用し、空気配管１１８，１２２、および１２６内の圧力を検知し、位置センサ１１６を使用して弁ステム１１４の位置を検出することにより、デバイスコントローラ１０２の制御下で実行される。このようにして、デバイスコントローラ１０２は、例示的な場所、および弁１０９の位置での圧力を示す時間変化電気信号を受信し、既知のまたは希望される方式で任意の数のデバイス診断パラメータを決定するために、これらの信号を使用することがある。
従来のフィールドデバイスは、典型的には、センサ１１６のような位置センサを含まず、診断評価に位置センサの結果を使用しない。また、従来のフィールドデバイスは、空気制御での圧力を測定し、圧力信号を電気信号に変換し、診断評価を容易にするために、入力センサ１２０、Ｉ／Ｐセンサ１２４、およびリレーセンサ１２８のようなセンサを含まない。ただし、これらのセンサ、および特にＩ／Ｐセンサ１２４は、フィールドデバイス１６内の故障、エラー、または障害の状態の局所化を容易にすることによって診断機能を高める。特に、Ｉ／Ｐセンサ１２４は、弁１０９の故障、フィールドデバイス１６内のその他の故障、およびフィールドデバイス１６に供給する空気配管の故障を含むフィールドデバイス１６にとって外部の故障の間の区別を補助する。Ｉ／Ｐセンサ１２４は、診断テストを実行し、Ｉ／Ｐ変換器１０４、空気リレー１０６、フィールドデバイス１６、および一般的にプロセス制御システム１０の動作状態を判断するためにも有効である。１つの実施例では、Ｉ／Ｐ変換器１０４および空気リレー１０６は、Ｉ／Ｐ変換器１０４を完全開放に動かし、弁１０９に提供される完全空気圧を測定する診断テスト手順を使用し、試験される。Ｉ／Ｐ変換器１０４が開放に動かされる間、Ｉ／Ｐセンサ１２４は、空気制御配管１２２内の圧力を絶えず測定する。圧力が降下し始めると、テストは、空気供給が不充分な可能性があることを示す。空気供給の十分な数量のさらなる診断テストは、弁１０９が空気供給に関して吸い込み動作を開始するように振動信号をＩ／Ｐ変換器１０４に適用して弁１０９をポンピングしてから、Ｉ／Ｐセンサ１２４を使用して最大流量および最大圧力の値を測定することにより実行される。
図７に示されるように、デバイスコントローラ１０２は、マイクロプロセッサ１４０、インタフェース１４２、バス分離回路１４４、ランダムアクセスメモリ（ＲＡＭ）１４６、読取り専用メモリ（ＲＯＭ）１４８、および不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）１５０のような複数の記憶装置、およびＡ／Ｄコンバータ１５２、Ｄ／Ａコンバータ１５４、およびマルチプレクサ１５６のような複数の信号処理装置を含む。（バスコネクタである）インタフェース１４２は、直列から並列へのプロトコル変換および並列から直列へのプロトコル変換を実行する回路であり、Fieldbusプロトコルのような希望されるプロトコル定義に従ってデータパケットにフレーム指示情報を追加するために使用される。バス分離回路１４４は、バス３４上のニ線式媒体通信信号を通信信号のデジタル表記に変換し、バス３４から受け取られる動力をＩ／Ｐ変換器１０４に対してだけではなく、デバイスコントローラ１０２内の他の回路に供給する回路である。バス分離回路１４４は、バス３４で波形整形およびシグナリングも実行することがある。
Ａ／Ｄコンバータ１５２は、それ以外の希望されるアナログ入力装置に対してだけではなく、図６の位置センサ１１６および圧力センサ１２０，１２４および１２８の位置変換器および圧力変換器などの変換器に接続される。Ａ／Ｄコンバータ１５２は、限られた数の入力チャネルを有することがあり、マルチプレクサ１５６は、複数の信号がサンプリングできるようにするために使用されることがある。希望される場合、マルチプレクサ１５６は、信号線路１１７と１３０（図６）の間で接続される増幅器のバンクを含み、それに送達される位置、圧力、およびその他のフィードバック信号を増幅する。Ｄ／Ａコンバータ１５４は、Ｉ／Ｐ変換器１０４などのアナログ構成要素へ送達される、マイクロプロセッサ１４０により作成される信号でデジタルからアナログへの変換を実行する。
典型的な診断テストアプリケーションでは、コントローラ１０２は、例えば、プログラムされたランプ（ramp）、ステップ変更、オン／オフという形式（または任意のそれ以外の希望される方法）でＩ／Ｐ変換器１０４へ０〜３０ｍＡの出力テスト信号を作成し、空気圧の所定の範囲で弁１０９を動作し、圧力入力センサ１２０、Ｉ／Ｐセンサ１２４、リレーセンサ１２８および位置センサ１１６により作成される診断テスト出力信号を受信する。手順（およびそれに関連した必要な情報）もキーボードなどの入力装置を使用してコントローラ１０２に直接的に入力できるが、特定のテスト手順は、ワークステーションなどの入出力装置を使用して、フィールドデバイス１６で指定され、一般的にはフィールドデバイス１６にとって外部で始動される。しかしながら、希望される場合、テスト手順は、コントローラ１０２に記憶されることがある。同様に、このような情報は、ＣＲＴディスプレイやプリンタなどを使用してデバイスコントローラ１０２から直接的に表示されることもあるが、フィールドデバイスコントローラ１０２によって収集されるか、そこで作成される診断テスト結果情報は、通常、外部入出力装置に転送される。
フィールドデバイス１６は、診断プロセスステップの実行を要求するコマンドのようなコマンドを解釈するコントローラ１０２内に埋め込まれたプログラム言語インタプリタを使用して、デバイス診断およびプロセス診断のような診断テスト動作を実行する。言語インタプリタは、好ましくは、ＰＲＯＭ１４８内に記憶されるプログラムコードで実現され、マイクロプロセッサ１４０内で実行する。いくつかの実施例では、テスト（診断）定義または手順は、ＰＲＯＭ１４８に符号化され、したがってフィールドデバイス１６の中に事前ロードされる。他の実施例では、テスト（診断）定義または手順は、手順が実行されなければならない時間にまたはその前にダウンロードされ、マイクロプロセッサ１４０によって実行されるために、例えばＲＡＭ１４６内に記憶される。典型的な実施例においては、いくつかの診断機能はＰＲＯＭ１４８内にハードコードされ、他の機能はダウンロードされ、デバイス１６内の恒久的な、つまりハードコードされたソフトウェアを修正しなくても、新しい診断テストの設計およびインプリメンテーションを可能にする。言語インタプリタは（Fieldbus弁のような）Fieldbus型デバイスでのプロセス診断またはデバイス診断の性能というコンテキストで説明されるが、言語インタプリタは、任意の型の埋め込まれたコントローラで実現され、それによって、他の型の埋め込まれたコントローラでの共通した診断テスト動作の使用を可能にする。
運転中、フィールドデバイス１６は、プロセス制御ネットワーク１０内のオペレータコンソールまたはホストワークステーション１２からバス３４を介して命令を受け取る。デバイスコントローラ１０２内で実行する言語インタプリタは命令を解釈し、命令により定義される動作を実行する。示された実施例では、言語の定義は、以下に示す表１に示されるユーザインタフェースコマンドテーブルに描かれる。

この診断言語仕様では、ユーザは、コマンド各を使用して、実行のためにコマンドを指定することができる。コマンド行は、標準Ｃ／Ｃ＋＋規約に従い、２つのスラッシュ（／／）で始まる任意の行である。ラベルは、コロンが後に続く任意のワードである。
診断テスト手順は、診断テスト手順を実現するために設計された言語定義に従って命令のシーケンスを作成する、ホスト１２内のようなオペレータコンソールで定義されることがある。それから、オペレータコンソールは解釈言語で符号化された命令にシーケンスを、例えばFieldbusプロトコルの非同期通信を使用して、デジタルフィールドデバイス１６にバス３４を介して伝送する。デバイスコントローラ１０２で実行する言語インタプリタは、受け取られた命令を記憶し、順番に命令を解釈し、命令により指示されるように弁１０９を制御し、それによって診断テストを実行する。診断テスト手順は、例えば、フィールドデバイス１６を制御し、弁１０９を繰り返しステップし、弁１０９を上または下へ移動し、弁１０９を選択された方向で選択された量移動するなどしてよい。診断テスト手順は、（他のデバイスからだけではなく）フィールドデバイス１６内のセンサからのデータの収集も制御し、バス３４を介して制御コンソールまたはホストワークステーション１２に対するデータの伝送を制御する。また、言うまでもなく、希望される場合、コントローラ１０２に提供される命令により実現される診断テスト手順は、診断結果を決定するために受信されたデータを処理し、これらの結果をホスト１２またはその他のディスプレイデバイスに送信することがある。
したがって、デバイスコントローラ１０２内の診断言語インタプリタは、プログラムされた命令に従ってフィールドデバイス１６の動作を制御し、診断テスト手順が、診断テストが、フィールドデバイス１６の修正を行わなくても自由に定義、修正されるように、デジタルフィールドデバイス１６の外部で定義できるようにする。同様に、新規診断制御手順は、フィールドデバイス１６がプロセス制御ネットワーク１０にインストールされた後に、作成され、フィールドデバイス１６に送信されることがある。しかしながら、希望される場合、デバイス１６は、また、あるいは代わりに、製造の時点あるいはそれ以外の時点でデバイスに記憶されたデバイスおよび／またはプロセス診断テスト命令を実現することがある。
（ホスト１２のような）制御コンソールは、通常、言語エディタのような診断作成ツール、およびフィールドデバイス１６により実行するために、診断言語で制御ルーチンを作成するためのシミュレータを含む。制御コンソールは、典型的には、バス３４を介してフィールドデバイス１６から受け取られるデータ用の分析ツールを含む。
完全性のため、解釈言語での例の診断プログラムコードは、弁１０９を制御するために、以下のように示される。
プログラムコード
（１）ＳＡＭＡ静的テスト定義
／／ＣＹＣＬＥ ０ ＴＯ １００％ ＴＩＭＥＳ
Ｄａｔａ Ｒａｔｅ １
ＣＹＣＬＥ： Ｌｏｏｐ ３
Ｍｏｖｅ Ａｂｓｏｌｕｔｅ ０．０
Ｐａｕｓｅ １００００
Ｍｏｖｅ Ａｂｓｏｌｕｔｅ １００．０
Ｐａｕｓｅ １００００
Ｌｏｏｐ Ｅｎｄ
／／Ｍｏｖｅ ＴＯ ５０％ ＳＴＥＰ ＵＰ ４ ＴＩＭＥＳ Ｍｏｖｅ Ａｂｓｏｌｕｔｅ ５０．０
Ｐａｕｓｅ １００００
Ｓｅｔ Ｉｎｃｒｅｍｅｎｔ １０．０
ＵＰ： ＬＯＯＰ ４
Ｉｎｃｒｅｍｅｎｔ Ｕｐ
Ｐａｕｓｅ １００００
Ｌｏｏｐ Ｅｎｄ
／／ＳＴＥＰ ＤＯＷＮ ８ ＴＩＭＥＳ
ＤＯＷＮ： Ｌｏｏｐ ８
Ｉｎｃｒｅｍｅｎｔ Ｄｏｗｎ
Ｐａｕｓｅ １００００
Ｌｏｏｐ Ｅｎｄ
／／ＳＴＥＰ ＵＰ ４ ＴＩＭＥＳ
ＵＰ２： Ｌｏｏｐ ４
Ｉｎｃｒｅｍｅｎｔ Ｕｐ
Ｐａｕｓｅ １００００
Ｌｏｏｐ Ｅｎｄ
Ｓｔｏｐ
（２）ステップ変更テスト定義
Ｄａｔａ Ｒａｔｅ １
Ｍｏｖｅ Ａｂｓｏｌｕｔｅ ５０．０
Ｐａｕｓｅ １００００
Ｍｏｖｅ Ａｂｓｏｌｕｔｅ ６０．０
Ｐａｕｓｅ １００００
Ｓｔｏｐ
（３）ステップ付きランプ（ｓｔｅｐｐｅｄ ｒａｍｐ）テスト定義
Ｄａｔａ Ｒａｔｅ １
Ｍｏｖｅ Ａｂｓｏｌｕｔｅ ５０．０
Ｓｅｔ Ｉｎｃｒｅｍｅｎｔ ０．５
／／ＳＴＥＰ ＵＰ ＢＹ ０．５ ＦＯＲ １０ ＴＩＭＥＳ
ＵＰ１： Ｌｏｏｐ １０
Ｉｎｃｒｅｍｅｎｔ ＵＰ
Ｐａｕｓｅ １０００
Ｌｏｏｐ Ｅｎｄ
／／ＳＴＥＰ ＤＯＷＮ ＢＹ ０．５ ＦＯＲ １０ ＴＩＭＥＳ
ＤＯＷＮ １： Ｌｏｏｐ １０
Ｉｎｃｒｅｍｅｎｔ Ｄｏｗｎ
Ｐａｕｓｅ １０００
Ｌｏｏｐ Ｅｎｄ
Ｓｅｔ Ｉｎｃｒｅｍｅｎｔ １．０
／／ＳＴＥＰ ＵＰ ＢＹ ０．５ ＦＯＲ １０ ＴＩＭＥＳ
ＵＰ２： Ｌｏｏｐ １０
Ｉｎｃｒｅｍｅｎｔ Ｕｐ
Ｐａｕｓｅ １０００
Ｌｏｏｐ Ｅｎｄ
／／ＳＴＥＰ ＤＯＷＮ ＢＹ ０．５ ＦＯＲ １０ ＴＩＭＥＳ
ＤＯＷＮ ２： Ｌｏｏｐ １０
Ｉｎｃｒｅｍｅｎｔ Ｄｏｗｎ
Ｐａｕｓｅ １０００
Ｌｏｏｐ Ｅｎｄ
Ｓｅｔ Ｉｎｃｒｅｍｅｎｔ ２．０
／／ＳＴＥＰ ＵＰ ＢＹ ０．５ ＦＯＲ １０ ＴＩＭＥＳ
ＵＰ３： Ｌｏｏｐ １０
Ｉｎｃｒｅｍｅｎｔ Ｕｐ
Ｐａｕｓｅ １０００
Ｌｏｏｐ Ｅｎｄ
／／ＳＴＥＰ ＤＯＷＮ ＢＹ ０．５ ＦＯＲ １０ ＴＩＭＥＳ
ＤＯＷＮ ３： Ｌｏｏｐ １０
Ｉｎｃｒｅｍｅｎｔ Ｄｏｗｎ
Ｐａｕｓｅ １０００
Ｌｏｏｐ Ｅｎｄ
Ｓｔｏｐ
（４）ステップ研究テスト定義
Ｄａｔａ Ｒａｔｅ １
／／ＳＴＥＰ ＵＰ， ＤＯＷＮ， ＤＯＷＮ， ＵＰ， ＴＨＥＮ ＩＮＣＲＥＭＥＮＴ ＳＴＥＰ ＳＩＺＥ ＡＮＤ
／／ＲＥＰＥＡＴ ＵＮＴＩＬ ＣＨＡＮＧＥＳ ＤＥＴＥＣＴＥＤ．
Ｓｅｔ Ｉｎｃｒｅｍｅｎｔ ０．５
Ｉｎｃｒｅｍｅｎｔ Ｕｐ
Ｐａｕｓｅ １００
Ｉｎｃｒｅｍｅｎｔ Ｄｏｗｎ
Ｐａｕｓｅ １００
これらのルーチンでは、フィールドデバイスコントローラ１０２は、記録を停止するためにConditional休止を実現し、どこでテストが停止されるのかを示すために記憶域の場所にビットを設定する。フィールドデバイスコントローラ１０２は、Branch/GOTO文、Loop永遠文、および休止フラグがセットされるときには強制停止を実現する。休止は、サーボ実行時間により、テストが弁との同期から外れない時間に同期される。
例示的なプログラムコードは、フィールドデバイス１６により実行されることがある診断テストの種類のいくつかの例だけを示しており、例えば、弁１０９が１０％上に、１０％下に、１０％上に、１０％下になど複数のサイクルの間に移動される静的サイクルテストを含むフィールドデバイス１６に提供されるプログラム命令によって実行されることがあるそれ以外の多くの診断がある。同様に、センサ１１６，１２０，１２４および１２８、および／または例えば（１）移動（例えば、位置センサ１１６の出力）対入力（例えば、コントローラ１０２に送達される制御信号）のプロットである動的エラーバンド、（２）（Ｉ／Ｐ変換器１０４に送達されるようなコントローラ１０２の出力である）駆動信号対圧力測定のプロット、（３）駆動信号対入力信号のプロット、（４）移動タイ駆動信号のプロットである出力信号、（５）圧力対移動などのプロットである弁シグナチャなどの、これらのまたはその他の測定から引き出される希望されるパラメータにより作成されるように、例えば、弁の移動やデバイス１６内の圧力の単純な測定を含むあらゆるデバイス診断測定が行われることがある。言うまでもなく、これらのテストに指定される圧力信号は、センサ１２０，１２４および／または１２８のどれかにより測定されるもののようなあらゆる希望される圧力信号である場合がある。
診断言語および診断言語インタプリタは、ニ線式ループ動力式両方向デジタル通信位置決め装置の形式でデジタルフィールドデバイス１６に通信するためにFieldbus通信を使用してプロセス制御ネットワーク１０内で有利に実現されるが、言語インタプリタは、他の実施例で実現してよい。例えば、診断言語インタプリタは、デジタル、アナログ、および光などの希望の通信技術を使用して通信する、埋め込まれたコントローラ内で実現してよい。さらに、示された診断言語インタプリタは、Fieldbus標準プロトコルに従って通信するが、診断言語インタプリタの代替実施例は、例えば、HART、Profibusなどのプロトコルを含む他の通信プロトコルを使用して通信する埋め込まれたコントローラ内で、および四線バスを使用するシステムなどのニ線バス以外を使用するシステムで実現してよい。同様に、診断言語インタプリタは、弁デバイスの他にも、他の種類のデバイスだけではなく、電子弁および油圧弁などを含むそれ以外の種類の弁で実現、使用してよい。
さらに、診断言語および診断言語インタプリタは、ある特定の命令セットを定義するとして説明されるが、それ以外の命令セットは、言語およびインタプリタがその中で定義される埋め込まれたコントローラの仕様に従って実現してよい。
言うまでもなく、デバイス診断テストおよびプロセス診断テストは、ホストワークステーション１２のようなオペレータコンソールで１つまたは複数の特定の診断テスト手順を要求するコマンドを発行することによって実行してよい。示された実施例では、診断テスト手順は２つのソフトウェアプログラムコードで実現される。第１コードは、例えばホストワークステーション１２内のフィールドデバイス１６に外部にあるプロセッサで実行し、診断テストを作成または始動し、収集されたデータを受け取り、それに関する分析を実行するが、第２コードはデバイスコントローラ１０２内で実行し、その中に記憶される、またはプログラム命令という形でホスト１２により提供される診断テストを実現する。対照的に、従来の制御システムネットワークでの診断は、制御コンソールのプロセッサ内で実行するソフトウェアによってだけ実行される。多くの利点は、制御コンソールレベルではなくむしろフィールドデバイスレベルで診断テストを実行することにより得られる。例えば、診断テストは、並列で実行されることがあり、デバイスレベルでこれらのテストを実行することにより多くのフィールドデバイスの中で分散されることがある。同様に、さらに正確なテストは、ホストが非同期でフィールドデバイスと通信し、診断テストを実行しなければならないという事実のために、ホストがフィールドデバイスの動作を決定的に制御できない可能性がある、Fieldbusプロトコルでのように分散制御機能を備えるプロセス制御ネットワークで実行されることがある。
Fieldbusプロトコルによって定義される両方向デジタル通信の実現は、データスループットの上昇により、および複数のフィールドデバイス間での診断の並列性能を助長することにより、診断の速度を加速するためにきわめて有利である。Fieldbusプロトコルを使用すると、定期的にスケジュールされるメッセージは、事前にスケジュールされるときに転送され、診断メッセージとデータ、ステータス表示のような校正情報と他の情報を含むスケジュールされていないメッセージは、メッセージまたはデータが準備完了であり、フィールドデバイスバス３４がそうでなければビジーではないときに、転送される。診断リクエストメッセージは、ターゲットフィールドデバイスによって受け取られ、診断テストはその他のフィールドデバイスの動作に関して非同期でフィールドデバイスにより実行される。診断テスト動作が完了すると、フィールドデバイスは、フィールドデバイスバス３４が使用できるときに、結果データのような応答を返す。したがって、前記に注記されたように、複数のフィールドデバイスは、診断テストを並列で実行できる。
ここでは図８を参照すると、フローチャート２００は、フィールドデバイス１６内で診断テストを実行するための技法を示す。ステップ２０２では、フィールドデバイス１６は、１つまたは複数の診断テストを実現する命令のシーケンスを実行するようにというリクエストを受け取る。言うまでもなく、ホストワークステーション１２は、同時に、このようなリクエストを任意の１つまたは非常に多数のフィールドデバイスに発行し、各フィールドデバイスが並列で診断データを収集するのを可能にする。非常に多数のフィールドデバイスがテストを同時に実行すると、ワークステーション１２は、診断テストが実行されるのと同じ程度迅速に長い時間間隔でデータを収集し、結果は、個々のフィールドデバイスによりバス３４上で使用できるようにされる。各フィールドデバイスと通信するために一意のワイヤのセットを使用する従来のデバイスは、一度に単一フィールドデバイスにアクセスするだけで、一度に単一のフィールドデバイスに単一テストを実行するだけである。
ステップ２０４では、フィールドデバイス１６は、一連の命令を実行し、リクエストによって指示されるように１つまたは複数の診断テストを実現する。言うまでもなく、前記に注記されたように、命令はフィールドデバイス１６のメモリに記憶されるか、例えば非同期通信を介してホスト１２によりフィールドデバイスに提供されることがある。テストが実現されている間、弁移動、圧力などの１つまたは複数のパラメータは、並列で測定される。したがって、従来のフィールドデバイスは通常単一の診断テスト測定に１つのコマンドを受け取り、測定を逐次実行し、これらのフィールドデバイスでの限られた通信帯域幅および記憶機能の欠如のために単一の測定値でリクエストに応答するが、フィールドデバイス１６は、柔軟なテストプロトコルを使用して複数のテストに対するリクエストを受け取り、複数のテストを実行してから、テスト中に収集された結果で応答する。
ステップ２０６では、フィールドデバイス１６は、メモリ内で診断テストのそれぞれに測定される複数のテストのパラメトリック（parametric）結果を記憶し、ステップ２０８でデータを外部要求デバイスに伝送する。Fieldbus標準に従ったニ線式両方向デジタル通信は、実質的には、デジタルフィールドデバイス１６の試験結果スループットを改善する。実際、Fieldbusプロトコルを使用するデジタル通信は、Fieldbusプロトコルが並列で複数のフィールドデバイスで診断テストを実行するために使用されるとき、多くのフィールドデバイスを含むプロセス制御ネットワークの診断テスト時間の量が大きく削減されるように、ＨＡＲＴシステムの約３０倍、データ伝送時間を改善する。
従来のフィールドデバイスは、各フィールドデバイスがワイヤに対する独占的なアクセスを持つように、通常、各フィールドデバイスをネットワークに接続する別個の組のワイヤを有するが、示された実施例では、診断テストの結果は、ホスト１２と通信するために必要とされるワイヤの量を削減するFieldbus標準プロトコルを使用して、バス３４上でオペレータ・コンソールまたはホスト・ワークステーション１２に伝送される。
理解されるように、診断テスト手順中、マイクロプロセッサ１４０は、Ｄ／Ａコンバータ１５４を制御し、変化する制御信号をＩ／Ｐ変換器１０４に供給する。各制御信号値およびサンプル時間ごとに、マイクロプロセッサ１０４は、Ａ／Ｄコンバータ１５２に、（他のセンサからの他の信号だけではなく）センサ１１６、１２０、１２４、および１２８により作成される圧力および／または位置に関係する電気信号を測定するように命令する。マイクロプロセッサ１０４は、動作測定サイクルを通してフィールドデバイスコントローラ１０２に命令するので、圧力および弁移動情報はデバイスコントローラ１０２によってアクセスされ、処理または記憶される。収集されたデータは、多くの場合、一時的にＲＡＭ１４６に記憶され、多くの場合、それ以降の処理、分析および表示のために、ホストワークステーション１２のような外部デバイスに通信される。言うまでもなく、マイクロプロセッサ１４０は、希望される場合分析も実行することがある。
例えば、リレーセンサ１２８によって測定される圧力情報、および位置センサ１１６によって測定される位置情報は、弁位置の関数として、弁ダイヤフラム圧力での変化を求めるために組み合わされて分析されることがある。同様に、入力センサ１２０、Ｉ／Ｐセンサ１２４、およびリレーセンサ１２８によって測定される圧力は、それぞれ位置センサ１１６によって測定される位置に結び付けて分析され、直線性、ヒステリシス、および範囲の特性を含む弁１０９の動作の完全な分析を示す偏差サイクルを作成する。
図９を参照すると、フローチャート３００は、診断テストを実行するためにフィールドデバイス１６で実現される診断テストプロトコルを示す。オペレータは、ワークステーション１２などのオペレータコンソールで診断命令のシーケンスを作成し、診断命令を、これらの命令をメモリに記憶するフィールドデバイス１６に伝送する。代わりに、またはさらに、診断命令は、デバイスの製造中、フィールドでバイアス１６のメモリに記憶されることがある。
ステップ３０２では、フィールドデバイス１６は、フィールドデバイスバス３４を介して診断コマンドを受け取る。希望される場合、診断コマンドは、フィールドデバイスコントローラ１０２で実行するために符号化される解釈診断言語の命令の形を取ることもあれば、デバイス１６内にすでに記憶される命令を指導するための命令である場合もある。デバイスコントローラ１０２は、Ｉ／Ｐ変換器１０４およびアクチュエータ１０８などのデジタルフィールドデバイス１６内の制御要素に弁１０９を操作させ、入力センサ１２０、Ｉ／Ｐセンサ１２４、リレーセンサ１２８、および位置センサ１１６などのセンサに測定を実行させるために多様な命令を実行する。また、制御命令は、測定を処理するため、およびユーザに提示するためにデータをフォーマットするための命令も含む。追加命令は、フィールドデバイスコントローラ１１２に、処理済みまたはフォーマット済みのデータを、フィールドデバイスバス３４を介して要求者に送信させることがある。
ステップ３０４では、デジタルフィールドデバイス１６が、要求時に、例えば、弁１０９が完全閉鎖ステータスから完全開放に運動され、それから完全閉鎖ステータスに戻されるテスト手順を実行する。同様に、デジタルフィールドデバイス１６は、要求時に、例えば、単一ステップ移動と分析、および１０ステップ移動と応答測定を含む、複数のステップテストを実行することがある。ステップ付きランプ（stepped ramp）テストも使用されることがあり、例えば１０％の増分というステップで１０％から９０％までの範囲のランプのような、弁のわずかな開放から大きな開放までの一連のステップを含む。ステップ付き研究は、１％、２％、５％および１０％のような事前に定義されたステップでの弁の開放、弁を指定されたステップサイズで第１方向に移動すること、安定化すること、およびそれから弁を指定されたステップサイズで第２方向に移動することを含む。
ステップ３０６では、診断テストの物理的な構成が、デジタルフィールドデバイス１６に通信されるコマンドにより設定される。物理構成変数は、アクチュエータ圧力と弁移動読取り値だけではなく、アクチュエータ１０８に適用される駆動信号、Ｉ／Ｐ変換器１０４に適用される圧力設定値を含む。物理構成変数は、いくつかの診断テストでは独立テスト変数として設定され、それ以外のテストで依存パラメータとして監視されることがある。
ステップ３０８では、フィールドデバイス１６は、特定の物理テスト構成の所定のパラメータを測定する。多くの診断テストの場合、複数のパラメータが単一テスト構成に関して測定される。単一テスト構成を使用して測定される典型的なパラメータは、弁位置、プロセス変数、アクチュエータ空気圧、供給圧力、駆動信号、変換器設定ポイント、およびＩ／Ｐ空気圧を含み、例えば、弁シグナチャ、出力信号、動的エラーバンド、駆動対圧力、移動タイ入力信号振幅などの決定を可能にする。
ステップ３１０では、フィールドデバイス１６が、デバイスコントローラ１０２の動作を通して、例えばＲＡＭ１４６内に単一テスト構成用の複数のパラメータを記憶する。ステップ３１２では、データはホスト１２またはそれ以外のデバイスに通信される。試験が別の診断テスト構成を使用して実行されなければならない場合、フィールドデバイス１６は、条件付きステップ３１４でのデバイスコントローラ１０２の動作を通して、ステップ３０６にループバックし、テスト構成を修正する。
示されたフィールドデバイス１６内の診断テストは、部分的には診断プロトコル構造の改善によって、部分的には通信の改善によって、および部分的にはフィールドデバイス１６内での追加センサの実現によって、規約フィールドデバイスに比較して大幅に改善される。診断プロトコル構造での改善によって、フィールドデバイス１６は、単一テスト構成の複数のパラメータを測定できるようになる。診断制御動作のフィールドデバイスへの分散によって、複数のリクエストが複数のフィールドデバイスに対して行われ、個々のフィールドデバイスが独立しておよび互いに並列で診断テストを制御できるように、診断テストは、フィールドデバイス内で、要求時に完全に制御できるようになる。また、診断プロトコル構造の改善によって、テスト手順をプログラミング変更によってフィールドデバイスの外部で有利に修正できるようにする。したがって、新しい診断機能が追加され、診断動作での大規模な変更が、フィールドデバイスを修正しなくても加えられる。フィールドデバイスの修正は、プロセス線路を停止する多大な費用のためにきわめて不利である。通信の改善により、フィールドデバイス１６は、単一テスト構成の複数のパラメータを測定できるようになる。従来のフィールドデバイスは、特定のフィールドデバイス専用である通信回線でリクエストを受信し、リクエストの仕様に従ってテスト構成を設定し、リクエストに従って単一テスト測定を返す。同じテスト構成の元でのそれ以降の測定は、テスト構成を設定する冗長なステップを含む、ステップを繰り返すことによって行われる。示されているフィールドデバイス１６の改善された通信は、並列での複数のデバイスの診断試験を有利に可能にし、診断テストスループットを高める。さらに、改善されたデジタル通信は、（従来のフィールドデバイスの）アナログ通信が備えない、複数のデータタイプに備える。
本発明は、多様な実施例に関して説明されてきたが、これらの実施例が例示的であり、発明の範囲がそれらに制限されないことが理解されるだろう。説明された実施例の多くの変化、修正、追加および改善が考えられる。例えば、フィールドデバイス１６は適切な制御弁とアクチュエータの組み合わせの１つの例にすぎない。その他の適切な弁の型は、その他の既知の弁の型だけではなく、スライド式ステム、回転プラグ、回転ボール、バタフライ、偏心ディスク弁を含む。他の適切なアクチュエータは、ばねとダイヤフラム、ばねとピストン、二重動作ピストン、油圧、電気水力学的、電気または回転弁またはスライド式ステム弁のどちらを使用するその他の既知のアクチュエータ型を含む。このようにして、フィールドデバイス１６は、単に、多様な種類の位置決め装置やアクチュエータおよび弁を制御し、動力を調節するためのそれ以外のデバイスを示すだけである。さらに、本発明の診断が使用されるか、位置するフィールドデバイスは、例えば、ポンプコントローラ、可変速度ドライブなどを含む弁以外のデバイスである場合がある。さらに、フィールドデバイス１６は、Fieldbus標準に準拠した動作に制限されるのではなく、HART、WORLDFIP、LONWORKS、Profibusおよび類似物などのその他のデジタル通信にも適用することができる。
言うまでもなく、デバイス診断テストおよびプロセス診断テストは、機能ブロックまたはその他のソフトウェアの形でコントローラ１０２に記憶され、パーソナルコンピュータのようなホストデバイスを使用して一般社会によってアクセス可能となるように、これらのテストがユーザの側での多くの知識を必要としなくても実現できるように、これらの診断は行われる。１つの実施例においては、１つまたは複数の容易にアクセス可能な診断ルーチンがデバイス（例えば、デバイス１６）に記憶され、どのテストが実行されるのかを指定する単一コマンドをホストから発行することによって実行されることがある。テストに必要なデータのすべては、デバイスに記憶され、テストのために収集されたすべての出力データは、テスト完了後にホストに送信される。
一般的に、このような「公開」デバイスおよびプロセス診断は、変換器ブロックに書き込み、例えば弁構成要素の移動を達成するように、およびFieldbusプロトコルで傾向変動ブロックを使用してセンサによって作成されるデータを読み取って、記憶するように命令される。ホストにより要求される情報のすべてがフィールドデバイスのデバイス記述内に位置するため、これらの公開診断のどれかを実現するために独占的な知識は必要とされない。このような公開診断を使用すると、フィールドデバイスの動作は、同じ診断をその中に有する他の製造メーカにより製作される任意の他のフィールドデバイスの動作と比較されることがある。
このような公開診断で使用される例の波形は図１０Ａから１０Ｃに示される。図１０Ａによって示されるように、公開診断は、弁１０９を、例えばある特定の数のステップ（例えば、５ステップ）に１パーセントという個別ステップで開放方向で、ステップ様式でランプ（step-wise ramping）するように移動させてから、弁の初期の値つまり位置に達するまで、１パーセントという個別ステップで閉鎖方向でステップ様式でランプ（step-wise ramping）するように移動される。好ましくは、新規設定ポイントへのステップは瞬時である。つまり、速度制限は有効ではなく、各新規設定ポイントでの遅延時間は固定され、弁／アクチュエータデバイスのサイズおよび応答の特性により決定される。代わりに、図１０Ｂによって示されるように、公開診断は、開放方向で５パーセントというランプで弁を移動させてから、ただちに弁を閉鎖方向で５パーセントというランプで移動させることがある。ランプの速度は、好ましくは固定され、弁／アクチュエータサイズにより決定される速度に設定される。もっとも好ましくは、ランプ速度は、デバイスの速度の最大速度のほぼ２分の１である。さらに図１０Ｃによって示されるように、公開診断は、単一の、例えば、５パーセントステップで現在の弁位置から開放（または閉鎖）方向で弁を移動することがあり、瞬時のステップ時間は、速度制限が有効でないように設定される。このテストは、弁が初期ポイントを５パーセント上回る（下回る）新しい弁ベースライン位置にある状態で終了する。
Fieldbusプロトコルを使用して図１０Ａから１０Ｃに示される公開診断を実現するために、ホスト１２は、デバイス（例えば、デバイス１６）内で傾向リストを設定してから、傾向変動のためにデバイス１６で適切なＶＣを設定する公開診断を記憶するデバイスに実行コマンドを送信する。次に、デバイス１６のリンクオブジェクトが傾向変動に設定され、その後で診断テストが進行する。この時点で、ホストは、診断がプロセス内にあることを示すメッセージをユーザに表示し、ホストは、診断のステータスまたは進行を読み取って、エラー状態が発生するかどうかを判断することがある。デバイス１６が診断を完了した後に、ホストは傾向変動されたデータを読み取り、記憶し、傾向変動をオフにする。それから、ホストは検索されたデータで分析を実行することがある。例えば、２００％以上のステータスがデバイス１６から受け取られると、診断でのエラーが発生しており、ホストはこのようなエラーをユーザに示すことがある。受け取られたデータを分析してから、ホストは、記憶された傾向またはそれから判断された結果から作成される診断データをユーザに表示することがある。例えば、ホスト１２は、デバイス１６の波形への応答を描くために、入力波形とともに前記公開診断波形の１つまたはすべてに応えた弁の実際の移動を図表を用いて描くことがある。
公開診断またはその他の診断を実行するとき、デバイス１６は、最初に、診断コマンド信号が受け取られたかどうかを判断し、受け取られている場合には、デバイスの変換器デバイスが満足行くように動作しているかどうか検証する。満足行くように動作している場合は、デバイス１６は、傾向データの更新されたポインタを設定し、どのデータを傾向ブロックに記憶しなければならないのかを示し、十分な設定ポイント範囲が診断の実行に使用できることか検証する。例えば、開放方向での弁の５パーセントの移動を必要とするテストを実行するためには、弁は、その最大移動の９５パーセント以下でなければならない。この範囲が使用できない場合、デバイス１６はホスト１２にエラーメッセージを送り返すことがある。
エラーが発生した場合、デバイス１６は、デバイス１６に記憶される（弁／アクチュエータのサイズの基づいて）ルックアップテーブルから求められたテスト時間とランプ速度を使用して、選択されたテストを実行し、弁の位置のような希望される測定を採取する。テスト中、弁は、０〜１００パーセントから完了するパーセントでテストステータスを更新し、エラーが検出される場合、２００パーセントを超えるエラーコードを、ホスト１２によって読み取られる診断ステータス変数に書き込む。テストの最後では、エラーに達さなかったと仮定し、診断テストは診断テストステータス変数に１００パーセントステータスを書き込み、その後で標準Fieldbusプロトコルに従って傾向変動を実行するようにセットアップされた通常のスタック動作を使用して、収集された傾向データをホストに報告する。好ましくは、診断テストのループ速度は、十分な傾向データが診断波形に対するデバイス１６の応答を適切にモデル化するために収集されるように、入力波形内での変化に比較して相対的に高くなるように設定される。したがって、傾向オブジェクトのデータサンプリングの頻度が機能ブロックの実行速度に結び付けられているFieldbusプロトコルでは、傾向オブジェクトが、その中の各重要変化の後での入力波形に対するデバイス１６の応答を観測するほど十分なデータを収集できるようにするために、ループ実行速度は入力波形内の変化率よりはるかに高くなければならない。
言うまでもなく、例えば図１０に示される公開診断は、それらが、ある特定のデバイスに１つまたは複数の診断ステップ、あるいはデバイス内の変換器の出力がそのデバイスの特性を決定するためにその間に測定される動作を通過させるために、有利に使用できるという点で、デバイス診断を実行するためにもっとも適している。デバイス診断用のFieldbusプロトコルで使用されるとき、これらのテストは、追加機能ブロックの使用は必要としないが、代わりにデバイス内で動作する機能ブロックと関連する通常の動作から離れて変換器ブロックを制御するために（図６のコントローラ１０２のような）個々のデバイスコントローラによって実行できる。言うまでもなく、希望される場合、機能ブロックは、収集されたデータをなんらかの方式で分析するため、および分析されたデータをホストに提供するために使用されることがある。
ここでは図１１Ａを参照すると、Fieldbusプロセス制御ネットワーク内のデバイスから、局所的にデバイス診断またはプロセス診断を実行することができるプロセス制御ループ４００が詳細に示されている。ループ４００は、制御ループ、つまりＰＩＤ機能ブロック６４とバス３４を介して通信可能となるように接続されたデバイス２０のＡＩ機能ブロック６６およびデバイス１６のＡＯ機能ブロック６３の両方を有する図４のＬＯＯＰ１を含む。ループ４００は、ＡＯ機能ブロック６３、ＡＩ機能ブロック６６、および希望される場合、プロセス制御ネットワーク１０内で接続される他のフィールドデバイス内に位置することがあるＡＩ機能ブロック４０２と４０４などの他の機能ブロックからデータを受け取るように構成されるデータ収集機能ブロック４０１も含む。言うまでもなく、機能ブロック６６、４０２および４０４は、Fieldbusプロトコル内で定義される公表者／加入者のような、標準同期通信を使用してデータ収集機能ブロック４０１と通信するように構成される。
運転中、フィールドデバイス１６内のコントローラ１０２は、機能ブロック６６，６４および６３によって形成されるループの通常の動作を中断し、診断波形をＡＯ機能ブロック６３の入力に送達する。その時点で、ＡＯ機能ブロック６３はそのステータスモードを、例えば、ＰＩＤ機能ブロック６４をカスケードし、ＰＩＤ機能ブロック６４がそのモードステータスを、代わりにＰＩＤ機能ブロック６４がそれにより受け取られた入力に基づいて出力信号を作成しないようにする、例えばマニュアルに流させる、ローカル制御モードに変化させる。前記に注記されたように、診断波形は、デバイス１６のコントローラ１０２に記憶されることもあれば、診断テストの実現前にホスト１２によって提供されることもある。言うまでもなく、波形またはその他の命令は、デバイス１６に関連する弁にデバイス診断テストまたはプロセス診断テストに関連した一連移動を経験させる。
デバイス診断中、データ収集機能ブロック４０１は、位置センサに関連した変換器および／または図６に示されるセンサのような圧力センサのどれかなどの、デバイス１６内の他の変換器からのデータだけではなく、ＡＯ機能ブロック６３からのデータを受け取る。プロセス診断中、データ収集機能ブロック４０１は、また、あるいは代わりに、プロセス制御ネットワーク１０内の他の機能ブロックだけではなく、ＡＩ機能ブロック６６，４０２、４０４によって作成されるようなプロセス変数に関するデータを受け取る。データ収集機能ブロック４０１は、このデータを、ＡＯ機能ブロック６３に送達される診断波形のタイミングおよび規模に関するデータとともに収集し、このデータを、それが処理され、ユーザに示されることがあるホスト１２への将来の送達のために記憶することがある。
デバイス診断テストまたはプロセス診断テストが完了した後に、機能ブロック４０１によって収集されたデータは、ホスト１２に送達され、コントローラ１０２は、ＡＯ機能ブロック６３の制御をＰＩＤ機能ブロック６４にリリースして戻し、ブロック６６，６４、および６３を構成するループを通常の動作に戻す。言うまでもなく、この時点では、ブロック６４および６３のステータスモードは、通常の動作に戻される。
データ収集機能ブロック４０１が、必ずしもスケジュールされた同期実行時間を必要としない一方、プロセス制御ループ４００を構成するときには、機能ブロック４０１の通信相互接続が設立されなければならず、したがってこれらの通信相互接続が、診断が実行していないときにも存在することに注意する必要がある。言い替えると、データ収集機能ブロック４０１がバス３４でそれに対しデータを公表させる必要があるときは、それは、ユーザに単に診断を実行するためにネットワーク１０を構成し直すことを要求することを回避するために、プロセス制御ネットワークの初期化時に、そのデータ（つまり、その他のデバイスによって公表されるデータ）を受け取るように構成されなければならない。ただし、前記に注記されたように、データ収集機能ブロック４０１は、通常、すでにバス３４で公表されているプロセス変数データだけを収集するか、あるいはデータ収集機能ブロック４０１がその中に存在するデバイス内で内部的に生成されたデータを収集するため、データ収集機能ブロック４０１の動作は、通常、バス３４での同期通信の量を増やしたり、プロセス制御ネットワーク１０に追加でスケジュールされる実行時間を必要としたりしないだろう。しかしながら、希望される場合には、データ収集機能ブロック４０１は、公表ブロックがプロセス制御ネットワーク１０の起動時にそのデータを公表するように構成されることを必要とする、通常はバスで公表されないデータを受け取るように構成することができる。
ここでは、図１１Ｂを参照すると、Fieldbusプロセス制御ネットワークのデバイス内でローカル診断を実現できるプロセス制御ループ４０６が、詳細に示されている。図１１Ａのループ４００と同様に、ループ４０６は、制御ループ、つまりデバイス１６のＰＩＤ機能ブロック６４とＡ／Ｏ機能ブロック６３両方とバス３４を介して通信可能となるように接続されるデバイス２０のＡＩ機能ブロック６６を持つ、図４のＬＯＯＰ１を含む。ループ４０６は、それが、例えばＡＯ機能ブロック６３、ＰＩＤ機能ブロック６４、または昇圧センサ、位置センサなどのデバイス内のそれ以外の変換器やセンサから局所的にデータを受け取るようにだけ構成されるという点を除き、データ収集機能ブロック４０１と本質的に同じに動作する（デバイス１６内に位置する）データ収集機能ブロック４０８も含む。データ収集機能ブロック４０８は、特に、必要とされるデータがデバイス内で局所的に作成されるデバイス診断を実行する上で有効である。ブロック４０８は、バス３４からデータを受け取る必要はないため、それはプロセス制御ネットワークの起動時に最初に構成される必要はない。
言うまでもなく、データ収集機能ブロック４０１と４０８は、プロセス制御デバイス内で診断データを収集する２つの方法にすぎず、このようなデータを異なる種類のプロセス制御ネットワークおよびデバイスで収集する多くのそれ以外の方法がある。例えば、デバイスまたはプロセス用のデータが、フィールドバス機能ブロックの定義に準拠しないデバイスに位置するほかの寄生ソフトウェアによって収集されることがある。
ここでは図１２を参照すると、フローチャート５００が、例えば図１１のループ４００を使用して典型的なプロセス診断によって実行されるステップを示す。ステップ５０２では、データ収集セットアップは、データ収集機能ブロック４０１に提供され、診断テストに必要なその他のデータは、診断が実行されなければならないデバイス１６にホスト（例えばホスト１２）から送達される。その後、診断は、ユーザによって初期化され、試験されているループをプロセス制御ネットワークの残りから分離させる。初期化時に、デバイス１６は、例えば、ＰＩＤ機能ブロック６４（またはその他の上流機能ブロック）にFieldbus制御基準に従って自動的にモードを変更させる、ローカル制御モードにＡＯ機能ブロック６３のステータスを変更させる。その後に、ブロック５０６は、デバイス１６のメモリの中に記憶される診断命令を実行し、データ収集機能ブロック４０１はブロック５０８で診断データおよびプロセスデータを収集する。ブロック５１０は、テストが完了したかどうかを判断し、完了していない場合は、制御を、次の診断命令を実行するブロック５０６に戻す。言うまでもなく、次の命令は、例えば、デバイスを、限度に達するまで単一方向で移動させる前の命令の繰り返しである場合がある。
ブロック５０６，５０８および５１０によって実行されるループは、テストが完了するまで、または何らかのエラーが発生するか、ブロック５１０で検出されるまで繰り返し、その時点でブロック５１２は診断テストを終了し、ブロック５１４は通常の動作ステータスを、例えば、ＰＩＤ機能ブロック６４に再びそのステータスを変更させ、通常の制御動作に従ってＡＯ機能ブロック６３を制御させるＡＯ機能ブロック６３に復元する。
データ収集機能ブロック４０１によって収集されるデータは、データを分析および／または表示するホスト１２に提供される。希望される場合、分析はデバイス１６で実行することができ、分析の結果は、ホスト１２によって表示のためにディスプレイ装置に提供されることがある。
本発明に従ってデバイス診断方法を使用すると、デバイス１６は、データを実現または受信するために、ホストによる別個の制御を必要としないでデバイスデータとプロセスデータの両方を収集する。診断は、デバイス内で実行され、別個のホストデバイスの代わりにそのデバイスのコントローラによって制御されるため、テストのタイミングは正確に制御することができ、診断テスト中に収集されるデータは、デバイスによって実行される動作と容易に時間調整でき、テスト波形とテスト結果の間の正確な一致を提供する。プロセス診断を実行するために実現されると、ループ４００（または１つまたは複数のプロセス制御ループからデータを収集するように構成されたデータ収集機能ブロックを有する任意の類似したループ）のデータ収集機能ブロック４０１は、単にデバイス性能だけではなくむしろループ性能を目標にするために使用でき、弁がループに適切であるかどうかを示すため、またはその総体的な性能を制限するループと他の問題があるかどうかを示すために、使用することができる。プロセスおよび／またはデバイスの試験は、プロセスを停止させたり、非運転状態にすることを要求しないで、定期的に実現できる。言うまでもなく、データ収集機能ブロック４０１が、ループですでに公表されているデータだけを収集するように構成されるとき、それは診断のために収集、使用できるデータに関して制御スケジュールによって制限される。
診断機能はここに、診断を（出力機能ブロックである）下流ＡＯ機能ブロック６３で実行したり、それを使用するとして、および単純な制御ループ構成で接続される（制御機能ブロックである）上流ＰＩＤ機能ブロック６４から入力を受け取り、それにフィードバックを送達するとして説明されてきたが、本発明のデータ収集機能ブロック４０１またはその他の診断機能ルーチンは、他の出力機能や機能ブロックおよび他の制御機能や機能ブロックといっしょに使用することができ、図１１に示される構成以外の構成を有する制御ループで実現できる。
さらに、ここに説明された診断のいくつかはFieldbus「機能ブロック」の形で実現されてきたが、本発明の診断は、他の種類の制御システムおよび／または通信プロトコルと関連する他の種類のブロック、プログラム、ハードウェア、ファームウェアなどを使用して実現することができることが注意される。実際、Fieldbusプロトコルは、プロセス制御機能を実行することができるある特定の型のエンティティを説明するために用語「機能ブロック」を使用するが、ここに使用される機能ブロックという用語がそのように制限されず、プロセス制御ネットワーク内の分散された場所で任意の方式でプロセス制御機能を実行することができる任意の種類のデバイス、プログラム、ルーチンまたはその端エンティティを含むことが注意される。したがって、ここに説明、請求される診断機能ブロックは、他のプロセス制御ネットワークで、またはFieldbusプロトコルが厳密に「機能ブロック」として識別することを使用しない、他のプロセス通信プロトコルや（現在存在しているか、あるいは将来開発される可能性がある）スキームを使用して実現することができる。
依然として、プロセス診断およびデバイス診断はここに位置決め装置／弁デバイスで（またはそれらを使用して）診断を実行する上で使用されるとして説明されるが、これらの診断が、ダンパー、ファンなどの可動部品を有するデバイスのような他の種類のデバイスで（またはそれらを使用して）実行できることが注意される。同様に、ここに説明された診断は、好ましくはプロセス制御デバイスに記憶されるソフトウェアで実現されるが、それらは、希望されるように、代わりにまたは追加でハードウェア、ファームウェアなどで実現されることがある。ソフトウェアで実現される場合、本発明の診断は、磁気ディスク、レーザディスク、またはその他の記憶媒体などのコンピュータ読取り可能メモリで、コンピュータのＲＡＭ、ＲＯＭ、ＥＰＲＯＭおよび類似物で記憶されることがある。同様に、このソフトウェアは、例えば、電話回線、インターネットなどの通信チャネル上でを含む既知のまたは希望される方法によってユーザまたはデバイスに送達されることがある。
したがって、本発明は、例示的であることだけが意図され、本発明の制限であることは意図されない特定の例に関して説明されてきたが、本発明の精神および範囲から逸脱することなく、変更、追加または削除を開示された実施例に加えることができることは、当業者には明らかであろう。

Claims (40)

1. 全デジタル通信バスにより通信可能となるように結合される複数のデバイスを有するプロセス制御ネットワークで使用するためのフィールドデバイスであって、前記全デジタル通信バスにおける全ての通信がデジタル信号を使用し、前記フィールドデバイスは、
   全デジタルバスに接続し、バスで全デジタル通信を可能にするコネクタと、
   一連の診断テスト命令を有する診断テストルーチンを記憶するメモリと、
   メモリに記憶される診断テスト命令を実行し、フィールドデバイスを使用して診断テストを実現するコントローラと、
   診断テスト中に作成される診断データを収集するデータ収集ユニットと、
   全デジタルフォーマットでバス上で収集された診断データを通信する通信ユニットと、
   を備える、フィールドデバイス。
2. さらに、可動弁部材を有する弁に結合される位置決め装置を備え、診断テスト命令が弁部材の移動を指定する、請求項１に記載のフィールドデバイス。
3. さらに、診断テスト中の可動弁部材の位置を検出し、弁部材位置のを示す位置信号をデータ収集ユニットに送達する位置センサを含む、請求項２に記載のフィールドデバイス。
4. 位置決め装置が、電流から圧力への変換器に結合される空気圧配管を含み、さらに空気圧配管の圧力を検知し、空気圧配管内の圧力を示す圧力信号をデータ収集ユニットに送達する空気圧配管に結合される圧力センサを含む、請求項３に記載のフィールドデバイス。
5. 電気から空気への変換器と弁の間の空気圧配管に結合される空気リレーをさらに含み、圧力センサが電気から空気への変換器と空気リレーの間の空気圧配管に結合される、請求項４に記載のフィールドデバイス。
6. 電気から空気への変換機と弁の間の空気圧配管で結合される空気リレーをさらに含み、圧力センサが空気リレーと弁の間の空気圧配管に結合される、請求項４に記載のフィールドデバイス。
7. 空気圧配管が、電気から空気への変換器の入力に結合される圧力供給配管を含み、圧力センサが空気圧供給に結合され、電気から空気への変換器の入力に供給される圧力を測定するための空気圧供給配管に結合される、請求項４に記載のフィールドデバイス。
8. コントローラが、プログラム言語を解釈するように適応されたプログラム言語インタプリタを含み、診断テスト命令がプログラム言語に記憶される請求項２に記載のフィールドデバイス。
9. 通信ユニットがバスを介して複数のデバイスの内の第２のデバイスからプログラム言語での診断テスト命令を受け取り、受け取られた診断テスト命令をメモリに記憶するように適応される、請求項８に記載のフィールドデバイス。
10. フィールドデバイスが、開放方向と閉鎖方向で可動である部材を含み、診断テスト命令が、部材を開放方向と閉鎖方向でステップ様式のランプを通って移動させる、請求項２に記載のフィールドデバイス。
11. ステップ様式のランプが、部材の移動の範囲の約１パーセントに等しいステップを含む、請求項１０に記載のフィールドデバイス。
12. フィールドデバイスが、開放方向と閉鎖方向で可動である部材を含み、診断テスト命令が、部材を開放方向と閉鎖方向で直線上のランプを通って移動させる、請求項２に記載のフィールドデバイス。
13. 診断テスト命令が、部材を部材の移動の最大速度の約２分の１に等しいランプ速度で移動させる、請求項１２に記載のフィールドデバイス。
14. フィールドデバイスが、可動である部材を含み、診断テスト命令が、部材をステップで移動させる、請求項２に記載のフィールドデバイス。
15. ステップが、部材の移動範囲の約５パーセントの振幅を有する、請求項１４に記載のフィールドデバイス。
16. バスにより通信可能となるように結合される複数のデバイスを有するプロセス制御ネットワークで使用するためのフィールドデバイスであって、
    一連の診断テスト命令を有する診断テストルーチンを記憶するメモリと、
    メモリに記憶される診断テスト命令を実行し、診断テストを実現するデバイスコントローラと、
    診断テスト中に作成される診断データを収集するデータ収集ユニットと、
    バスを介して複数のデバイスの内の第２のそれから診断テスト命令を受け取り、受け取られた診断テスト命令をメモリに記憶し、収集された診断データをバスで通信する通信ユニットと、
    を備えるフィールドデバイス。
17. 診断テスト命令がプログラム言語で作成され、デバイスコントローラが、診断テスト命令を解釈し、診断テストを実行するプログラム言語インタプリタを含む、請求項１６に記載のフィールドデバイス。
18. 可動弁部材を有する弁に結合される位置決め装置をさらに備え、診断テスト命令が弁部材の移動を指定する、請求項１７に記載のフィールドデバイス。
19. 診断テスト中に弁部材の位置を検知し、弁部材の位置を示す位置信号をデータ収集ユニットに送達する位置センサをさらに含む、請求項１８に記載のフィールドデバイス。
20. 位置決め装置は、電流から圧力への変換器に結合される空気圧配管を含み、さらに、空気圧配管での圧力を検知し、空気圧配管での圧力を示す圧力信号をデータ収集ユニットに送達する空気圧配管に結合される圧力センサを含む、請求項１９に記載のフィールドデバイス。
21. 通信ユニットは、Fieldbusプロトコルを使用してバスで通信するように構成される、請求項１６に記載のフィールドデバイス。
22. 診断テスト命令がプロセス診断を実現し、通信ユニットが複数のデバイスの内の他のデバイスにより測定されるプロセス変数に関するバスを介してデータを受け取るように適応される、請求項１６に記載のフィールドデバイス。
23. バスにより通信可能となるように結合される複数のデバイスを有するプロセス制御ネットワークでプロセス診断テストを実行する際に使用するためのフィールドデバイスであって、
    フィールドデバイスにより実現される一連の診断テスト命令を有するプロセス診断テストルーチンを記憶するメモリと、
    プロセス診断テストを実現するためにメモリに記憶されるプロセス診断テスト命令を実行するデバイスコントローラと、
    プロセス診断テスト中にフィールドデバイスにより作成される診断データを収集し、バスを介して複数のデバイスの内の第２のそれからさらなるプロセス診断データを受信するデータ収集ユニットと、
    プロセス診断テスト完了後に、収集された診断データおよびさらなるプロセス診断データをバス上に伝送する通信ユニットと、
    を備えるフィールドデバイス。
24. 通信ユニットが、Fieldbus通信プロトコルを使用してバスで通信するように構成され、データ収集ユニットが、バス上で複数のデバイスの内の第２のデバイスからさらなるプロセス診断データを受け取るように構成される機能ブロックである、請求項２３に記載のフィールドデバイス。
25. 機能ブロックは、同期通信を使用してバス上でさらなるプロセス診断データを受け取るように構成される、請求項２４に記載のフィールドデバイス。
26. デバイスコントローラが、プロセス診断テストを実行するプロセス制御ループ内で構成要素のモードを制御するモード処理装置を含む、請求項２３に記載のフィールドデバイス。
27. コマンドを作成し、データを受信するホストデバイスと、
    複数のフィールドデバイスと、
    ホストデバイスと複数のフィールドデバイスを通信可能となるように相互接続するバスと、
    を含み、
    複数のフィールドデバイスの一つが、１つのデバイスにより一連の診断テスト命令を実現させる診断テストルーチンを記憶するメモリと、診断テストを実現するためにメモリに記憶される診断テスト命令を実行するデバイスコントローラと、診断テスト中に１つのデバイスにより作成される診断データを収集するデータ収集ユニットと、診断テスト完了後にホストデバイスにバス上で収集された診断データを通信する通信ユニット
    とを含む、プロセス制御ネットワーク。
28. 診断テストルーチンがプロセス診断テストルーチンであり、データ収集ユニットが、バスを介して複数のフィールドデバイスの内の第２のデバイスからプロセス診断データを受信する、請求項２７に記載のプロセス制御ネットワーク。
29. コントローラが、プログラム言語を解釈するように適応されるプログラム言語インタプリタと、診断テスト命令がプログラム言語で記憶される、請求項２７に記載のプロセス制御ネットワーク。
30. 通信ユニットが、バスを介してホストデバイスからプログラム言語での診断テスト命令を受け取り、受け取られた診断テスト命令を診断テストの実現前にメモリに記憶するように適応される、請求項２９に記載のプロセス制御ネットワーク。
31. 複数のフィールドデバイスのそれぞれが、プロセス制御機能を実行し、スケジュールされた定期的な通信および不定期通信を使用してバス上で通信することができる、請求項２７に記載のプロセス制御ネットワーク。
32. 複数のフィールドデバイスの内の１つが、開放方向と閉鎖方向で可動である部材を含み、診断テスト命令が、部材を、開放方向と閉鎖方向でステップ方式のランプを通して移動させる、請求項２７に記載のプロセス制御ネットワーク。
33. ステップ方式のランプが、部材の移動の範囲の約１パーセントに等しいステップを含む、請求項３２に記載のプロセス制御ネットワーク。
34. 複数のフィールドデバイスの１つが、開放方向と閉鎖方向で可動である部材を含み、診断テスト命令が、部材を、開放方向と閉鎖方向で直線上のランプを通して移動させる、請求項２７に記載のプロセス制御ネットワーク。
35. 診断テスト命令が、部材を、部材の移動最大速度の約２分の１に等しいランプ速度で移動させる、請求項５１に記載のプロセス制御ネットワーク。
36. 複数のフィールドデバイスの内の１つが、可動である部材を含み、診断テスト命令が、部材をステップで移動させる、請求項２７に記載のプロセス制御ネットワーク。
37. ステップが、部材の移動範囲の約5パーセントの振幅を有する、請求項３６に記載のプロセス制御ネットワーク。
38. バスにより通信可能となるように結合される複数のデバイスを有するプロセス制御ネットワークで診断テストを実行し、Fieldbus通信プロトコルを使用する際に使用するためのフィールドデバイスであって、
    フィールドデバイスによって実現される一連の診断テスト命令を有する診断テストルーチンを記憶するメモリと、
    メモリに記憶される診断テスト命令を実行し、診断テストを実現するデバイスコントローラと、
    診断テスト中に生成される診断データを収集するデータ収集機能ブロックと、
    診断テスト完了後にバス上で収集された診断データを通信する通信ユニットと、
    を備えるフィールドデバイス。
39. 診断テストがデバイス診断テストであり、データ収集機能ブロックがフィールドデバイスからデータを収集する、請求項３８に記載のフィールドデバイス。
40. 診断テストがプロセス診断テストであり、データ収集機能ブロックが、バス上での通信を介してさらなるフィールドデバイスから診断データの少なくとも一部を収集する、請求項３８に記載のフィールドデバイス。

Images