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

Abstract

(57)【要約】 通信可能となるように二線式全デジタル通信バスによって結合される、複数のデバイスを有するプロセス制御ネットワーク内で使用するためのフィールドデバイスは、フィールドデバイスを二線式全デジタルバスに接続し、バスで全デジタル通信を可能にするコネクタ、一連のデバイス診断テスト命令またはプロセス診断テスト命令を有する診断テストルーチンを記憶するメモリ、およびメモリに記憶されるデバイス診断テスト命令またはプロセス診断テスト命令を実行し、フィールドデバイスを使用してデバイスまたはプロセス診断テストを実現するコントローラを含む。フィールドデバイス内のデータ収集ユニットは、診断テスト中に作成される診断データを収集し、通信ユニットが収集された診断データを処理のためにバス上でホストデバイスに通信する。コントローラは、バスを介してデバイスの内のもう１つからフィールドデバイスに提供されることがある診断テストルーチンを解釈するために適応されるプログラム言語インタプリタを備えることがある。

Description

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

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ， ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，Ｆ Ｉ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ， ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，Ｍ Ｗ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ， ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 ブラウン，ラリー，ケー. アメリカ合衆国 50158 アイオワ マー シャルタウン イースト サウスリッジ ロード 211

Claims (1)

1. 【特許請求の範囲】 １．二線式デジタル動力式バスにより相互に結合される複数のフィールドデバ イスを含むプロセス制御システム内で使用するためのフィールドデバイスであっ て、 空気圧配管に接続されるアクチュエータを有し、流体制御弁を、開放位置から 閉鎖位置の範囲となる位置に移動させる空気圧流体制御弁と、 流体制御弁の位置を検出するために流体制御弁に結合される位置センサと、 空気圧配管内の空気圧を検知するために空気圧配管に結合される圧力センサと 、 電気信号の関数として空気圧配管内の空気圧を制御するために、空気圧配管に よりアクチュエータに結合される電気から空気への変換器と、 電気から空気への変換器、圧力センサ、および位置センサに結合される電子コ ントローラであって、圧力センサにより検知される圧力、および位置センサによ り検知される位置を示すフィードバック信号に基づき、およびフィールドデバイ ス制御信号に基づき電気信号を決定する制御論理回路を含む電子コントローラと 、 二線式デジタル動力式バスに結合され、電子コントローラに結合されるデジタ ルインタフェースであって、 動力式バスから引き出される電力を、電子コントローラおよび電気から空気へ の変換器を含むフィールドデバイスに供給するための回路と、 バスからフィールドデバイス制御信号を含む信号を受信し、フィールドデバイ スのステータスを示す信号をバスに伝送するための両方向通信回路と、 を含むデジタルインタフェースと、 を備えるフィールドデバイス。 ２．さらに、電気から空気への変換器と弁の間に空気圧配管上で結合される空 気リレーを含み、空気センサが電気から空気への変換器と空気リレーの間の空気 圧配管に結合される、請求項１に記載のフィールドデバイス。 ３．空気リレーと弁の間の空気圧配管に結合されるさらなる圧力センサを含む 、請求項２に記載のフィールドデバイス。 ４．さらに、電気から空気への変換器と弁の間の空気圧配管で結合される空気 リレーを含み、圧力センサが空気リレーと弁の間の空気圧配管に結合される、請 求項１に記載のフィールドデバイス。 ５．空気圧配管が、電気から空気への変換器の入力に結合される圧力供給配管 を含み、圧力センサが空気圧供給配管に結合され、電気から空気への変換器の入 力に供給される圧力を測定する、請求項１に記載のフィールドデバイス。 ６．バスから受け取られる診断テストリクエストに応えて、診断弁テストプロ トコルを実行、制御するため、および圧力センサにより測定される圧力の変動お よび位置センサによって測定される弁位置の変動に相当する弁診断データを作成 するための電子コントローラで実行するための第２制御論理回路、および弁診断 データを記憶するための電子コントローラに結合される記憶装置とをさらに備え る、請求項１に記載のフィールドデバイス。 ７．弁診断データをバスにデジタルで伝送するための電子コントローラ内で実 行するための第３制御論理回路をさらに備える、請求項６に記載のフィールドデ バイス。 ８．フィールドデバイスが、バス上の他のフィールドデバイ スの動作とは関係なく、診断テストプロトコルを実行する、請求項７に記載のフ ィールドデバイス。 ９．デジタルインタフェースが、Fieldbus標準通信プロトコルを使用し、二線 式デジタル動力式バスを介して通信する、請求項１に記載のフィールドデバイス 。 １０．コマンドを作成し、データを受け取るための制御コンソールと、 制御コンソールに結合される二線式デジタル動力式バスと、 二線式デジタル動力式バスに相互に結合される複数のフィールドデバイスと、 前記バスは、フィールドデバイスに対するフィールドデバイス制御信号を含む コマンドを供給し、前記フィールドデバイスの内の１つが 流体制御弁を開放位置から閉鎖位置までの範囲の位置に移動させるために、空 気圧配管に結合されるアクチュエータを有する空気圧流体制御弁と、 流体制御弁の位置を検知するために流体制御弁に結合される位置センサと、 圧力配管内の空気圧を検知するための空気圧配管に結合される圧力センサと、 空気圧配管内の空気圧を電気信号の関数として制御するための空気圧配管によ り弁に結合される電気から空気への変換器と、 電気から空気への変換器、圧力センサ、および位置センサに結合される電子コ ントローラであって、圧力センサにより検知される圧力および位置センサにより 検知される位置を示すフィードバック信号に基づき、およびフィールドデバイス 制御信号に基づき電気信号を決定する制御論理回路を含む電子コントローラと、 二線式デジタル動力式バスに結合され、電子コントローラに結合されるデジタ ルインタフェースと を含み、前記デジタルインタフェースは、 動力式バスから得られる動力を、電子コントローラおよび電気から空気への変 換器を含むフィールドデバイスに供給するための回路と、 バスからフィールドデバイス制御信号を含む信号を受信し、フィールドデバイ スのステータスを示す信号をバスに伝送するための二線式通信回路とを含む、 プロセス制御システム。 １１．電気から空気への変換器と弁の間の空気圧配管で結合される空気リレー をさらに含み、圧力センサが電気から空気への変換器と空気リレーの間の空気圧 配管に結合される、請求項１０に記載のプロセス制御システム。 １２．電気から空気への変換器と弁の間の空気圧配管で結合される空気リレー をさらに含み、圧力センサが空気リレーと弁の間の空気圧配管に結合される、請 求項１０に記載のプロセス制御システム。 １３．空気圧配管が、電気から空気への変換器の入力に結合される圧力供給配 管を含み、圧力センサが電気から空気への変換器の入力に供給される圧力を測定 するために圧力供給配管に結合される、請求項１０に記載のプロセス制御システ ム。 １４．バスから受け取られる診断テストリクエストに応えて診断弁テストプロ トコルを実行、制御し、圧力センサにより測定される圧力の変動および位置セン サにより測定される弁位置の変動に対応する弁診断データを作成するための電子 コントローラ内での実行のための第２制御論理回路、および弁診断データを記憶 するために電子コントローラに結合される記憶装置と をさらに備える、請求項１０に記載のプロセス制御システム。 １５．弁診断データをバスにデジタルで伝送するための電子コントローラ内で の実行のための第３制御論理回路をさらに備える、請求項１４に記載のプロセス 制御システム。 １６．フィールドデバイスが、バス上の他のフィールドデバイスの動作に無関 係に診断テストプロトコルを実行する、請求項１５に記載のプロセス制御システ ム。 １７．制御コンソールが、複数のフィールドデバイスに複数の診断テストコマ ンドを作成、伝送するための動作論理回路を含み、 複数のフィールドデバイスのそれぞれが、動作が並列で実行されるように、バ ス上での他のフィールドデバイスの動作に関係なく診断テストコマンドを実行す るための動作論理回路を備える、 請求項１０に記載のプロセス制御システム。 １８．全デジタル通信バスにより通信可能となるように結合される複数のデバ イスを有するプロセス制御ネットワークで使用するためのフィールドデバイスで あって、 全デジタルバスに接続し、バスで全デジタル通信を可能にするコネクタと、 一連の診断テスト命令を有する診断テストルーチンを記憶するメモリと、 メモリに記憶される診断テスト命令を実行し、フィールドデバイスを使用して 診断テストを実現するコントローラと、 診断テスト中に作成される診断データを収集するデータ収集ユニットと、 全デジタルフォーマットでバス上で収集された診断データを通信する通信ユニ ットと、 を備える、フィールドデバイス。 １９．さらに、可動弁部材を有する弁に結合される位置決め装置を備え、診断 テスト命令が弁部材の移動を指定する、請求項１８に記載のフィールドデバイス 。 ２０．さらに、診断テスト中の可動弁部材の位置を検出し、弁部材位置のを示 す位置信号をデータ収集ユニットに送達する位置センサを含む、請求項１９に記 載のフィールドデバイス。 ２１．位置決め装置が、電流から圧力への変換器に結合される空気圧配管を含 み、さらに空気圧配管の圧力を検知し、空気圧配管内の圧力を示す圧力信号をデ ータ収集ユニットに送達する空気圧配管に結合される圧力センサを含む、請求項 ２０に記載のフィールドデバイス。 ２２．電気から空気への変換器と弁の間の空気圧配管に結合される空気リレー をさらに含み、圧力センサが電気から空気への変換器と空気リレーの間の空気圧 配管に結合される、請求項２１に記載のフィールドデバイス。 ２３．電気から空気への変換機と弁の間の空気圧配管で結合される空気リレー をさらに含み、圧力センサが空気リレーと弁の間の空気圧配管に結合される、請 求項２１に記載のフィールドデバイス。 ２４．空気圧配管が、電気から空気への変換器の入力に結合される圧力供給配 管を含み、圧力センサが空気圧供給に結合され、電気から空気への変換器の入力 に供給される圧力を測定するための空気圧供給配管に結合される、請求項２１に 記載のフィールドデバイス。 ２５．コントローラが、プログラム言語を解釈するように適応されたプログラ ム言語インタプリタを含み、診断テスト命令がプログラム言語に記憶される請求 項１８に記載のフィールド デバイス。 ２６．通信ユニットがバスを介して複数のデバイスの内の第２のデバイスから プログラム言語での診断テスト命令を受け取り、受け取られた診断テスト命令を メモリに記憶するように適応される、請求項２５に記載のフィールドデバイス。 ２７．フィールドデバイスが、開放方向と閉鎖方向で可動である部材を含み、 診断テスト命令が、部材を開放方向と閉鎖方向でステップ様式の傾斜を通って移 動させる、請求項１８に記載のフィールドデバイス。 ２８．ステップ様式の傾斜が、部材の移動の範囲の約１パーセントに等しいス テップを含む、請求項２７に記載のフィールドデバイス。 ２９．フィールドデバイスが、開放方向と閉鎖方向で可動である部材を含み、 診断テスト命令が、部材を開放方向と閉鎖方向で直線上の傾斜を通って移動させ る、請求項１８に記載のフィールドデバイス。 ３０．診断テスト命令が、部材を部材の移動の最大速度の約２分の１に等しい 傾斜速度で移動させる、請求項２９に記載のフィールドデバイス。 ３１．フィールドデバイスが、可動である部材を含み、診断テスト命令が、部 材をステップで移動させる、請求項１８に記載のフィールドデバイス。 ３２．ステップが、部材の移動範囲の約５パーセントの振幅を有する、請求項 ３１に記載のフィールドデバイス。 ３３．バスにより通信可能となるように結合される複数のデバイスを有するプ ロセス制御ネットワークで使用するためのフィールドデバイスであって、 一連の診断テスト命令を有する診断テストルーチンを記憶す るメモリと、 メモリに記憶される診断テスト命令を実行し、診断テストを実現するデバイス コントローラと、 診断テスト中に作成される診断データを収集するデータ収集ユニットと、 バスを介して複数のデバイスの内の第２のそれから診断テスト命令を受け取り 、受け取られた診断テスト命令をメモリに記憶し、収集された診断データをバス で通信する通信ユニットと、 を備えるフィールドデバイス。 ３４．診断テスト命令がプログラム言語で作成され、デバイスコントローラが 、診断テスト命令を解釈し、診断テストを実行するプログラム言語インタプリタ を含む、請求項３３に記載のフィールドデバイス。 ３５．可動弁部材を有する弁に結合される位置決め装置をさらに備え、診断テ スト命令が弁部材の移動を指定する、請求項３４に記載のフィールドデバイス。 ３６．診断テスト中に弁部材の位置を検知し、弁部材の位置を示す位置信号を データ収集ユニットに送達する位置センサをさらに含む、請求項３５に記載のフ ィールドデバイス。 ３７．位置決め装置は、電流から圧力への変換器に結合される空気圧配管を含 み、さらに、空気圧配管での圧力を検知し、空気圧配管での圧力を示す圧力信号 をデータ収集ユニットに送達する空気圧配管に結合される圧力センサを含む、請 求項３６に記載のフィールドデバイス。 ３８．通信ユニットは、Fieldbusプロトコルを使用してバスで通信するように 構成される、請求項３３に記載のフィールドデバイス。 ３９．診断テスト命令かプロセス診断を実現し、通信ユニッ トが複数のデバイスの内の他のデバイスにより測定されるプロセス変数に関する バスを介してデータを受け取るように適応される、請求項３３に記載のフィール ドデバイス。 ４０．バスにより通信可能となるように結合される複数のデバイスを有するプ ロセス制御ネットワークでプロセス診断テストを実行する際に使用するためのフ ィールドデバイスであって、 フィールドデバイスにより実現される一連の診断テスト命令を有するプロセス 診断テストルーチンを記憶するメモリと、 プロセス診断テストを実現するためにメモリに記憶されるプロセス診断テスト 命令を実行するデバイスコントローラと、 プロセス診断テスト中にフィールドデバイスにより作成される診断データを収 集し、バスを介して複数のデバイスの内の第２のそれからさらなるプロセス診断 データを受信するデータ収集ユニットと、 プロセス診断テスト完了後に、収集された診断データおよびさらなるプロセス 診断データをバス上に伝送する通信ユニットと、 を備えるフィールドデバイス。 ４１．通信ユニットが、Fieldbus通信プロトコルを使用してバスで通信するよ うに構成され、データ収集ユニットが、バス上で複数のデバイスの内の第２のデ バイスからさらなるプロセス診断データを受け取るように構成される機能ブロッ クである、請求項４０に記載のフィールドデバイス。 ４２．機能ブロックは、同期通信を使用してパス上でさらなるプロセス診断デ ータを受け取るように構成される、請求項４１に記載のフィールドデバイス。 ４３．デバイスコントローラが、プロセス診断テストを実行するプロセス制御 ループ内で構成要素のモードを制御するモー ド処理装置を含む、請求項４０に記載のフィールドデバイス。 ４４．コマンドを作成し、データを受信するホストデバイスと、 複数のフィールドデバイスと、 ホストデバイスと複数のフィールドデバイスを通信可能となるように相互接続 するバスと、 を含み、 複数のフィールドデバイスの一つが、１つのデバイスにより一連の診断テスト 命令を実現させる診断テストルーチンを記憶するメモリと、診断テストを実現す るためにメモリに記憶される診断テスト命令を実行するデバイスコントローラと 、診断テスト中に１つのデバイスにより作成される診断データを収集するデータ 収集ユニットと、診断テスト完了後にホストデバイスにバス上で収集された診断 データを通信する通信ユニット とを含む、プロセス制御ネットワーク。 ４５．診断テストルーチンがプロセス診断テストルーチンであり、データ収集 ユニットが、バスを介して複数のフィールドデバイスの内の第２のデバイスから プロセス診断データを受信する、請求項４４に記載のプロセス制御ネットワーク 。 ４６．コントローラが、プログラム言語を解釈するように適応されるプログラ ム言語インタプリタと、診断テスト命令がプログラム言語で記憶される、請求項 ４４に記載のプロセス制御ネットワーク。 ４７．通信ユニットが、バスを介してホストデバイスからプログラム言語での 診断テスト命令を受け取り、受け取られた診断テスト命令を診断テストの実現前 にメモリに記憶するように適応される、請求項４６に記載のプロセス制御ネット ワーク。 ４８．複数のフィールドデバイスのそれぞれが、プロセス制 御機能を実行し、スケジュールされた定期的な通信および不定期通信を使用して バス上で通信することができる、請求項４４に記載のプロセス制御ネットワーク 。 ４９．複数のフィールドデバイスの内の１つが、開放方向と閉鎖方向で可動で ある部材を含み、診断テスト命令が、部材を、開放方向と閉鎖方向でステップ方 式の傾斜を通して移動させる、請求項４４に記載のプロセス制御ネットワーク。 ５０．ステップ方式の傾斜が、部材の移動の範囲の約１パーセントに等しいス テップを含む、請求項４９に記載のプロセス制御ネットワーク。 ５１．複数のフィールドデバイスの１つが、開放方向と閉鎖方向で可動である 部材を含み、診断テスト命令が、部材を、開放方向と閉鎖方向で直線傾斜を通し て移動させる、請求項４４に記載のプロセス制御ネットワーク。 ５２．診断テスト命令が、部材を、部材の移動最大速度の約２分の１に等しい 傾斜速度で移動させる、請求項５１に記載のプロセス制御ネットワーク。 ５３．複数のフィールドデバイスの内の１つが、可動である部材を含み、診断 テスト命令が、部材をステップで移動させる、請求項４４に記載のプロセス制御 ネットワーク。 ５４．ステップが、部材の移動範囲の約5パーセントの振幅を有する、請求項 ５３に記載のプロセス制御ネットワーク。 ５５．バスにより通信可能となるように結合される複数のデバイスを有するプ ロセス制御ネットワークで診断テストを実行し、Fieldbus通信プロトコルを使用 する際に使用するためのフィールドデバイスであって、 フィールドデバイスによって実現される一連の診断テスト命令を有する診断テ ストルーチンを記憶するメモリと、 メモリに記憶される診断テスト命令を実行し、診断テストを実現するデバイス コントローラと、 診断テスト中に生成される診断データを収集するデータ収集機能ブロックと、 診断テスト完了後にバス上で収集された診断データを通信する通信ユニットと 、 を備えるフィールドデバイス。 ５６．診断テストがデバイス診断テストであり、データ収集機能ブロックがフ ィールドデバイスからデータを収集する、請求項５５に記載のフィールドデバイ ス。 ５７．診断テストがプロセス診断テストであり、データ収集機能ブロックが、 バス上での通信を介してさらなるフィールドデバイスから診断データの少なくと も一部を収集する、請求項５５に記載のフィールドデバイス。