JP2001519564A - 分散制御機能を有するプロセス制御ネットワークにおける遠隔診断 - Google Patents

Abstract

(57)【要約】 診断システムは、複数のプロセス制御装置がバスによって通信可能にリンクされたプロセス制御ネットワーク内で装置診断およびプロセス診断を行うように適合され、装置の各々はプロセス制御機能を実行するとともにスケジュールされた周期的通信を用いてバスによって通信を行うことができる。診断システムは、複数のうちの第１の装置内に配置され、診断制御信号を生成する信号発生器と、スケジュールされた周期的通信を用いて複数の装置うちの第２の装置に診断制御信号を送るように構成されたコミュニケータと、診断制御信号に応答して第２の装置により生じさせられた出力信号を受信するように適合される出力信号受信器とを備える。診断システムは、受信した出力信号を用いて診断を行っても、この信号を診断解析のためにホスト装置に送ってもよい。

Description

【発明の詳細な説明】

発明の分野 本発明は一般にプロセス制御ネットワークに関し、より特定的には、分散制御
機能を有するプロセス制御ネットワーク内で遠隔装置診断およびプロセス診断を
行なう方法および装置に関する。

【０００１】 関連技術の説明 化学プロセス、石油プロセス、ならびに他の製造プロセスおよび精製プロセス
のような大規模プロセスは、様々な位置に配置されプロセスのパラメータを測定
するとともに制御して、それによりプロセスの制御を実行する多数のフィールド
装置を含む。これらのフィールド装置は、例えば、弁およびスイッチのような制
御要素だけでなく、温度センサ、圧力センサ、および流量センサであってよい。
昔から、プロセス制御産業は、手動でレベルゲージおよび圧力ゲージを読取った
り、弁のハンドルを回転させたりするなどのような手動操作を用いて、プロセス
内で測定および制御フィールド装置を動作させていた。２０世紀になり、プロセ
ス制御産業は局所空圧制御を用い始めたが、この場合、局所空圧制御器、送信器
、および弁ポジショナがプロセスプラント内で様々な位置に配置され、プラント
のその位置の制御を実行していた。１９７０年代のマイクロプロセッサベースの
分散制御システム（ＤＣＳ）の出現で、分散電子プロセス制御がプロセス制御産
業において流行した。

【０００２】 公知であるように、ＤＣＳは、プロセス中に位置した電子センサ、送信器、電
流対圧力トランスデューサ、弁ポジショナのような多数の電子監視装置および制
御装置に接続されたプログラマブル論理制御器のような、アナログまたはディジ
タルコンピュータを含む。ＤＣＳコンピュータは、集中型、そしてしばしば複雑
な制御方式を記憶し、実行して、プロセス内で装置の測定値を測定することおよ
びその制御を行ない、それにより全体の制御方式に従ってプロセスパラメータを
制御する。しかしながら、通常は、ＤＣＳにより実行される制御方式は、ＤＣＳ
制御器製造業者に所有権があるので、ＤＣＳを拡張、更新、再プログラム、およ
び使用するのに困難かつ高価なものにしている。なぜならば、これらの活動を実
行する際にＤＣＳプロバイダが関わることは不可欠であるからだ。さらに、特定
のＤＣＳにより用いられるかまたはこのＤＣＳ内で接続される機器は、ＤＣＳ制
御器の所有権の性質と、ＤＣＳ制御器プロバイダがある装置または他の小売業者
により製造される装置の機能を支援してはいけないという事実とによって制限さ
れるかもしれない。

【０００３】 所有権を主張できるＤＣＳの使用に固有の問題の幾つかを克服するために、プ
ロセス制御産業は、例えば、ＨＡＲＴ（登録商標）、ＰＲＯＶＩＢＵＳ（登録商
標）、ＷＯＲＬＤＦＩＰ（登録商標）、Ｄｅｖｉｃｅ−Ｎｅｔ（登録商標）、お
よびＣＡＮプロトコルを含む、多くの標準的な、開放的通信プロトコルを発展さ
せて来たが、これにより、異なる製造業者により製造されたフィールド装置を同
じプロセス制御内で一緒に用いることが可能となる。事実、フィールド装置がＤ
ＣＳ制御器の製造業者とは異なる製造業者により製造されているとしても、これ
らのプロトコルのひとつに従うフィールド装置であれば、ＤＣＳ制御器と通信す
るとともにＤＣＳ制御器により制御されるようにプロセス内で用いることができ
る。

【０００４】 さらに、現在、プロセス制御を非集中化（分散）するために、そしてそれによ
りＤＣＳ制御器を簡単化するかまたはＤＣＳ制御器をほとんど必要としなくなる
ように、プロセス制御産業内で動きがある。非集中制御は、弁ポジショナ、送信
器などのようなフィールド装着プロセス制御装置にひとつ以上の制御機能を実行
させること、および他の制御機能を実行する際に他のプロセス制御装置により用
いられるバス構造によってデータ通信を行うことにより得られる。これらの制御
機能を実行するには、各プロセス制御装置は、標準のかつ開放的な通信プロトコ
ルを用いて、制御機能を実行する能力（ケイパビリティ）と他のプロセス制御装
置と通信する能力とを有するマイクロプロセッサを含む。このようにして、様々
な製造業者により製造されたフィールド装置はプロセス制御ネットワーク内で相
互接続され、互いに通信し、ＤＣＳ制御器の介入なしに、制御ループを形成する
ひとつ以上の機能を実行する。FOUNDATION（登録商標） Fieldbus（以下"フィー
ルドバス" ）プロトコルとして知られているフィールドバスファウンデーション
（Fieldbus Foundation） により現在広められている全ディジタル、２線式バス
プロトコルは、様々な製造業者により製造された装置が標準的なバスによって相
互動作するとともに互いに通信し、それによりプロセス内で非集中制御を行なう
ことが可能なひとつの開放的な通信プロトコルである。

【０００５】 上で述べたように、プロセス制御機能の非集中によって、所有権を主張するＤ
ＣＳ制御器を簡単化し、場合によってはこのＤＣＳ制御器が必要でなくなり、こ
れにより、プロセス操作員が、ＤＣＳ制御器により実行される制御方式を変更す
るか更新するためにＤＣＳ制御器の製造業者に頼る必要がなくなる。しかしなが
ら、非集中制御によって、典型的にはＤＣＳ制御器により行なわれていたプロセ
ス診断のような診断を実行しにくくなる。

【０００６】 標準的なＤＣＳ環境においては、コンピュータ（パソコンのような）はネット
ワークに結合され、診断制御信号をポジショナに送ることにより、弁またはポジ
ショナ／弁組み合わせに関して装置診断を行ない、ポジショナは次いで弁に診断
制御信号と関連するテストストロークまたはテストサイクルを経させる。この間
、コンピュータは、診断制御信号に応答して生じる弁位置の変化のようなポジシ
ョナおよび／または弁の出力を測定し、その後、測定された出力に関して解析を
行なって弁またはポジショナ／弁装置の動作状況を決定する。標準的なＤＣＳ制
御器または他のコンピュータ装置は一般に、ポジショナのような装置に診断制御
信号を送ることによりプロセス内に制御による変化を生じさせ、プロセス内でそ
のまたは他の位置でひとつ以上のプロセスパラメータを測定し、次いで、測定さ
れたプロセスパラメータを解析してプロセスの動作状況を決定することによりプ
ロセス診断を行う。

【０００７】 標準的なＤＣＳ環境においては、システムを再配線するかまたは再構成せずに
診断を行うことが出来る。なぜなら、ＤＳＣ制御器（または他のコンピュータ）
は、プロセス内で様々な装置の設定点（または他の入力）を制御し、装置出力お
よび他のプロセスパラメータを測定し、これによりプロセスの通常動作と関連す
る制御戦略を実行するようにもうすでに構成されている。その結果、標準的なＤ
ＣＳ環境において診断を行なう際、そうすべく構成されている通り、わずかに異
なる方法でＤＣＳ制御器または特別に構成されたコンピュータを用いてプロセス
内でひとつ以上の装置を制御すること、ＤＣＳ制御器またはコンピュータを用い
てプロセスまたは装置パラメータを読取ることが問題となる。その結果、標準的
なＤＣＳ環境においては、診断ルーチンは、装置診断またはプロセス診断を行う
ように集中型ＤＣＳ制御器または他のコンピュータ内に記憶され用いられ、これ
らの診断ルーチンは、実質的にプロセス制御ネットワークを再構成することなく
用いられる。残念なことに、これらの診断ルーチンの集中化された性質のために
、これらルーチンは個々のフィールド装置について詳細な情報をあまり与えるこ
とはできない。

【０００８】 しかしながら、分散制御機能を有するプロセス制御ネットワークにおいては、
既存の集中システム制御器は、プロセス内でフィールド装置全てを個々に制御す
るようには構成されておらず、装置診断およびプロセス診断を行なうのに必要な
適切な装置またはプロセスパラメータの全てに関するデータを受信するようには
構成されていない。その代わりに、制御戦略を有する様々なプロセス制御ループ
が、プロセス制御ネットワーク内で分散した個所に位置した多くの通信可能にリ
ンクされた装置により実行される。典型的には、これらの装置は、スケジュール
された周期的な通信を用いて、プロセス制御ループと関連する具体的な制御機能
の実行に必要なデータの通信を行うと共に、非周期または非同期通信を用いて他
のデータ（設定点変化のような）の通信を行うように構成されている。その結果
、スケジュールされた周期的通信を用いて実行される分散制御機能を有するプロ
セス制御ネットワークにおいては、システムが通常の制御戦略を実行するように
構成されている間は、ホストは、厳密に確定的な診断制御信号をプロセス制御装
置に送ることできない。なぜなら、ホストは、非同期通信を用いて診断制御信号
を送らねばならず、従って、診断制御信号（またはその異なる部分）が、テスト
されているかまたは制御されている装置に到着する正確な時間を制御する方法は
ない。事実、非同期通信を用いると、ホストは、制御されている装置の入力にい
つ診断制御信号（またはその異なる部分）が実際に到着するのかを知ることは出
来ない。その結果、確定的な診断制御信号を、分散制御機能を有するプロセス制
御ネットワーク内の装置に送るホストのために、ネットワークの制御構成は再構
成されねばならず、これにはプロセスがオフラインになることが必要である。代
替的には、分散制御機能を有するプロセス制御ネットワーク内の装置には自己診
断を行うことができるものもあり、従って、診断を行うのにホストにより制御さ
れる必要はない。しかしながら、これらの装置は典型的には高価であり、他の装
置に関する診断を行なうことはできない。

【０００９】 このように、分散制御機能を有するプロセス制御ネットワーク内で装置診断を
行なうには、プロセス操作員は、診断が行なわれるべきあらゆる位置に対して自
己診断力を備えた装置を購入しなければならず、これは高価であり、またはプロ
セス操作員は、装置診断またはプロセス診断が行なわれるべきときはいつでも、
ホストがスケジュールされた通信を用いて診断制御信号を被テスト装置に送るこ
とができるように、プロセス操作員はネットワークの通信相互接続を再構成しな
ければならず、これは望ましくないことである。なぜならばネットワークの制御
戦略を再構成しなければならないからである。

【００１０】 さらに、分散制御機能を有する制御ネットワーク内でホストが正確なプロセス
診断を行なうことは非常に困難である。なぜならば、上で述べたように、ホスト
が確定的に装置を制御して、これにより、測定されたプロセス変数が生成される
方法を変更することが出来るように、プロセスの通常の制御戦略は再構成されね
ばならない。言いかえれば、ホストが確定的に装置を制御することができるよう
にプロセス制御方式が再構成されるときは、診断の間に測定されたプロセス変数
は、通常動作下ではプロセスをもはや示さないが、その代わりに、診断制御方式
下ではプロセスを示すだけである。その結果、プロセス診断の結果は、プロセス
の通常動作の間はプロセスの性能を示していないかもしれないという結論に至る
。

【００１１】 発明の概要 本発明は、分散制御機能を有するプロセス制御ネットワーク内で別の装置上で
またはこれを用いて装置診断およびプロセス診断を行なう方法および装置と、プ
ロセスの通常動作の間に実行されるものと本質的に同じ制御戦略下でプロセスが
制御されている間にプロセス診断を行なう方法および装置とに関する。本発明の
方法および装置は、自己診断機能を有しない装置に関して診断を行なうためにプ
ロセス保守者により用いられるが、これによりプロセス保守者は、プロセス制御
ネットワーク内の多くの位置で安価な装置を用いることができる。さらに、本発
明の方法および装置は、プロセス制御ネットワークの制御戦略またはその動作に
影響を与えることなく、プロセス制御ネットワーク内で実行可能な装置診断およ
びプロセス診断能力を与える。

【００１２】 本発明のある態様によれば、複数の装置がバスによって通信可能にリンクされ
たプロセス制御ネットワークにおいて用いられる診断システムは、装置のうちの
第１の装置内に配置され、診断制御信号を生成する信号発生器と、スケジュール
された周期的な通信を用いて、診断制御信号を装置のうちの第２のものの入力に
送るコミュニケータと、診断制御信号に応答して、第２の装置のような別の装置
により生じさせられた出力信号を受信する信号受信器とを備える。

【００１３】 この診断テストシステムは、他のプロセス制御装置からひとつ以上のプロセス
信号を受信するように適合されるプロセス信号受信器と、ひとつ以上のプロセス
信号、受信された出力信号、および／または診断制御信号を記憶する記憶ユニッ
トとを備える。診断システムは、プロセスまたは装置診断が実行された後に、記
憶されたプロセス、出力、および／または制御信号を用いて診断解析活動を行な
うことができる装置のうちの第３のものに、記憶されたプロセス、出力、および
／または制御信号を送ってよい。

【００１４】 さらに、診断システムは、装置のうちの第４のものにより生じさせられたプロ
セス制御信号を受信するように適合される制御信号入力と、制御信号入力と信号
発生器とに結合され、第２の装置にプロセス制御信号および診断制御信号のうち
のひとつを送るスイッチとを備える。この場合、診断システム内のフィードバッ
クユニットは、プロセス制御信号を作成する際に第４の装置により用いられるた
めに、第４の装置に受信された信号を送る。

【００１５】 フィードバック信号を受信する装置（即ち第４の装置）が、異なるモードで動
作することが可能な制御機能を有する場合、診断システムは好ましくは、診断制
御信号を第２の装置に送る間に第４の装置内で制御機能のモードを少なくとも間
接的に制御するモード処理ユニットを含む。

【００１６】 本発明の別の態様によれば、複数の装置がバスに通信可能に結合されたプロセ
ス制御ネットワークにおいて用いられるように診断機能ブロックが与えられ、装
置の各々は、プロセス制御ネットワーク内で入力機能、出力機能、または制御機
能を実行することのできるひとつ以上の機能ブロックを含み、装置の各々は、ス
ケジュールされた周期的通信を用いてバス上で通信を行うことができる。本発明
に従った診断機能ブロックは、診断制御信号を生成する信号発生器と、スケジュ
ールされた周期的な通信を用いて、異なるプロセス制御装置内の第２の機能ブロ
ックに診断制御信号を伝達するように構成されたコミュニケータと、診断制御信
号応答して、第２の機能ブロックのような別の機能ブロックにより生じさせられ
た出力信号を受信する信号受信器とを含む。

【００１７】 本発明のさらに別の態様によれば、複数の装置がバス上で通信可能にリンクさ
れたプロセス制御ネットワークにおいて用いられるように、診断を行なう方法が
提供され、装置の各々は、プロセス制御ネットワーク内でプロセス制御機能を実
行することができ、スケジュールされた周期的通信を用いてバス上で通信を行う
ことが可能なひとつ以上の機能ブロックを含む。本発明に従った診断方法は、診
断制御信号を生成する診断機能ブロックを有する第１の装置をプロセス制御ネッ
トワークのバスに接続するステップと、スケジュールされた周期的通信を用いて
、診断機能ブロックの出力を第２の装置内の機能ブロックに通信可能にリンクす
るステップと、第２の機能ブロックのような別の機能ブロックの出力に診断機能
ブロックの入力を通信可能にリンクして、診断制御信号に応答して、別の機能ブ
ロックにより生じさせられた出力信号を受信するステップとを含む。この方法は
、スケジュールされた周期的通信を用いて診断制御信号を第２の機能ブロックを
送り、それにより診断制御信号に従って第２の機能ブロックの動作を制御するス
テップを含む。

【００１８】 好ましい実施例の説明 本発明の遠隔診断は、一組のフィールドバス装置を用いて非集中的にすなわち
分散的にプロセス制御機能を実行するプロセス制御ネットワークと関連して説明
されるが、本発明の遠隔診断は、他の種類のフィールド装置と、２線式バス以外
に依存するプロトコルとアナログおよびディジタル通信を支援するプロトコルと
を含む通信プロトコルとを用いて、分散制御機能を実行するプロセス制御ネット
ワークと共に用いることが出来る。このように、例えば、本発明の遠隔通信は、
プロセス制御ネットワークがＨＡＲＴ、ＰＲＯＦＩＢＵＳなどの通信プロトコル
または、既存であるか将来において開発される他の通信プロトコルを用いる場合
でも、分散制御機能を実行するプロセス制御ネットワークにおいて用いることが
出来る。

【００１９】 本発明の遠隔診断を詳しく説明する前に、フィールドバスプロトコルと、この
プロトコルに従って構成されるフィールド装置と、フィールドプロトコルを用い
るプロセス制御ネットワークで通信が行われる方法とを説明する。しかしながら
、フィールドバスプロトコルはプロセス制御ネットワークで用いられるために開
発された比較的新しい全ディジタル通信プロトコルであるが、このプロトコルは
当該技術では公知であり、とりわけ、テキサス州、オースチンに本社のある営利
団体ではないフィールドバスファウンデーション（ Fieldbus Foundation）によ
り出版され、流通され、そこから入手できる多くの記事、パンフレットおよび仕
様書に詳細に記載されているということを理解されたい。特に、フィールドバス
プロトコルと、フィールドバスプロトコルを用いて装置と通信するとともに装置
内にデータを記憶する方法とは、「フィールドバスファデーションからの通信技
術仕様およびユーザ層技術仕様“Communications Technical Specification and
User Layer Technical Specification from the Fieldbus Foundation" 」と題
されたマニュアルに説明されており、これをここに引用により援用する。

【００２０】 フィールドバスプロトコルは、例えば、２線式ループか、または、ファクトリ
またはプラントの器械またはプロセス制御環境において位置しているセンサ、ア
クチュエータ、制御器、弁などのようなバス相互接続「フィールド」機器に標準
化された物理インターフェースを与える、全ディジタル、シリアル、双方向通信
プロトコルである。フィールドバスプロトコルは、事実上、プロセス内でフィー
ルド計器（フィールド装置）のためにローカルエリアネットワークを与え、これ
により、これらのフィールド装置が、プロセス機関中で分散した位置で制御機能
を実行し、これらの制御機能を実行した前後に互いに通信して全体の制御戦略を
実行することが可能となる。フィールドバスプロトコルにより、制御機能をプロ
セス制御ネットワーク中に分散させることが可能となるので、フィールドバスプ
ロトコルは、ＤＣＳと典型的には関連する集中型プロセス制御器の作業負荷を低
減するかまたはこの制御器を完全に必要としない。

【００２１】 図１を参照して、フィールドバスプロトコルを用いるプロセス制御ネットワー
ク１０は、２線式フィールドループまたはバス３４によって、プログラム論理制
御器（ＰＬＣ）１３と、多数の制御器１４と、別のホスト装置１５と、一組のフ
ィールド装置１６、１８、２０、２２、２４、２６、２８、３０、３２とに接続
されたホスト１２を含む。バス３４は、異なるセクションまたはセグメント３４
ａ、３４ｂ、３４ｃを含み、これらはブリッジ装置３０、３２により分離されて
いる。セクション３４ａ、３４ｂ、３４ｃの各々は、バス３４に接続された装置
の部分集合分を相互接続し、これにより以下に述べる方法で装置間の通信を可能
とする。当然、図１のネットワークはあくまで例示であり、フィールドバスプロ
トコルを用いてプロセス制御ネットワークが構成される方法は他にも多くある。
典型的には、構成装置はホスト１２のような装置のひとつ内に位置しており、い
つ新たなフィールド装置がバス３４に接続されるのか、いつフィールド装置がバ
ス３４から外されるのか認識すること、フィールド装置１６−３２により生成さ
れるデータを認識すること、ひとつ以上のユーザ端末とインターフェースするこ
とだけでなく、装置の各々をセットアップするかまたは構成すること（これらの
装置は、それらの各々が通信を行うことが出来るマイクロプロセッサを含むとい
う点でかしこい（ smart）装置である）に対し責任を負うが、これは、ホスト１
２内に位置してもよいし、なんらかの方法でホスト１２に接続された他の装置内
に位置していてもよい。

【００２２】 バス３４は、双方向の、純粋にディジタル通信を支援するかまたは許容し、フ
ィールド装置１６−３２のようなそこに接続された装置のいずれかまたは全てに
電力信号を与えてよい。代替的には、装置１２―３２のいずれかまたは全ては、
それら自身の電源を有してもよいし、別個の電線（図示せず）によって、外部電
源に接続されてもよい。装置１２−３２は、標準的なバスタイプ接続でバス３４
に接続されているものとして図１に示されおり、ここでは多数の装置がバスセグ
メント３４ａ、３４ｂ、３４ｃを構成する同じペアの電線に接続されているが、
フィールドバスプロトコルにより他の装置／電線接続形態（トポロジー）も可能
となるが、これらには、別個の２線式ペア（典型的には４−２０ｍＡアナログＤ
ＣＳシステム）によって制御器またはホストに接続される二地点間接続と、各装
置が２線式バスにおいて共通の点（例えば、ジャンクションボックスまたはプロ
セス制御ネットワーク内でフィールド装置のひとつ内の終端領域であってよい）
に接続される木（ツリー）型または「スパー（spur）」接続とが含まれる。

【００２３】 データは、フィールドバスプロトコルに従って、同じまたは異なる通信ボーレ
ートまたは速度で異なるバスセグメント３４ａ、３４ｂ、３４ｃによって送られ
てよい。例えば、フィールドバスプロトコルは、図１のバスセグメント３４ｂ、
３４ｃにより用いられているものとして示される３１．２５Ｋｂｉｔｓ／ｓ通信
速度（Ｈ１）、および１．０Ｍｂｉｔｓ／ｓおよび／または２．５Ｍｂｉｔ／ｓ
（Ｈ２）通信速度を与え、これは典型的には、高度のプロセス制御、遠隔入力／
出力、および高速工場自動化アプリケーションのために用いられ、図１のバスセ
グメント３４ａにより用いられるものとして示される。同様に、電圧モード信号
方式または電流モード信号方式を用いてフィールドバスプロトコルに従ってバス
セグメント３４ａ、３４ｂ、３４ｃによって送られてよい。当然、バス３４の各
セグメントの最大長は厳密には制限されないが、その代わりに、そのセクション
の通信速度、ケーブルの種類、電線のサイズ、バス電力オプションなどにより決
定される。

【００２４】 フィールドバスプロトコルは、バス３４に接続され得る装置を、３つの主要な
カテゴリ、即ち、基本装置と、リンクマスタ装置と、ブリッジ装置とに分類され
る。基本装置（図１の装置１８、２０、２４、２８のような）は通信を行うこと
ができ、即ち、バス３４上でまたはそこから通信信号を送受信するが、バス３４
で生じる通信の順序またはタイミングを制御することができない。リンクマスタ
装置（図１のホスト１２だけでなく装置１６、２２、２６のような）は、バス３
４によって通信を行い、バス３４上で通信信号の流れおよびタイミングを制御す
ることが出来る。ブリッジ装置（図１の装置３０、３２のような）は、より大き
なプロセス制御ネットワークを作成すべくフィールドバスの個々のセグメントま
たはその分岐上で通信を行うとともにこれらを相互接続するように構成された装
置である。所望であれば、ブリッジ装置は、バス３４上の異なるセグメント上で
用いられる異なるデータ速度および／または異なるデータ信号フォーマット間で
変換を行ってもよく、バス３４のセグメント間で行き来する信号を増幅してもよ
く、バス３４の異なるセグメント間で流れる信号をフィルタ処理するとともにブ
リッジが結合されているバスセグメントのひとつ上で装置により受信されるべき
信号だけを通過させてもよく、および／またはバス３４の異なるセグメントをリ
ンクするのに必要な他の活動を行ってもよい。異なる速度で動作するバスセグメ
ントを接続するブリッジ装置は、ブリッジの低速度セグメント側でマスタ能力（
ケイパビリティ）を有しなければならない。ホスト１２、１５、ＰＬＣ１３、お
よび制御器１４はどんな種類のフィールドバスであってよいが、典型的にはリン
クマスタ装置である。

【００２５】 装置１２−３２の各々は、バス３４によって通信を行うことができ、そして、
重要なことには、プロセスからまたはバス３４上で通信信号によって異なる装置
から、装置により獲得されたデータを用いて、ひとつ以上のプロセス制御機能を
独立して実行することが出来る。フィールドバスは従って全体の制御戦略の何ら
かの部分を直接実行することができるが、これは、従来は、ＤＣＳの集中ディジ
タル制御器により行われていた。制御機能を実行するには、各フィールド装置は
、装置内のマイクロプロセッサ内で実行されるひとつ以上の標準化された「ブロ
ック」を含む。特に、各フィールド装置は、ひとつの資源ブロックと、ゼロ以上
の機能ブロックと、ゼロ以上のトランスデューサブロックとを含む。これらのブ
ロックはブロックオブジェクトと称される。

【００２６】 資源ブロックは、例えば、装置の種類と、装置修正指示と、どこで他の装置特
定情報が装置のメモリ内で得られるのかを示す指示を含め、フィールド装置の特
性の幾つかに関する装置特有データを記憶し、その通信を行う。様々な製造業者
はフィールド装置の資源ブロック内に異なる種類のデータを記憶してもよいが、
フィールドバスプロトコルに従う各フィールド装置は、データを記憶する資源ブ
ロックを含む。

【００２７】 機能ブロックは、フィールド装置と関連する入力機能、出力機能、または制御
機能を規定し、実行する。従って、機能ブロックは、入力、出力、制御機能ブロ
ックと一般に称される。

【００２８】 しかしながら、ハイブリッド機能ブロックのような機能ブロックの他のカテゴ
リが既存してもよいし、将来において開発されてもよい。各入力または出力機能
ブロックは、少なくともひとつのプロセス制御入力（プロセス測定装置からのプ
ロセス変数のような）またはプロセス制御出力（起動装置に送られる弁位置のよ
うな）を生成し、各制御機能ブロックは、あるアルゴリズム（事実上所有権を有
してよい）を用いて、ひとつ以上のプロセス入力および制御入力からひとつ以上
のプロセス出力を生成する。標準的な機能ブロックの例は、アナログ入力（ＡＩ
）、アナログ出力（ＡＯ）、バイアス（Ｂ）、制御セレクタ（ＣＳ）、離散入力
（ＤＩ）、離散出力（ＤＯ）、手動ローダ（ＭＬ）、比例微分（ＰＤ）、比例／
積分／微分（ＰＩＤ）、比（ＲＡ）、および信号セレクタ（ＳＳ）機能ブロック
を含む。しかしながら、他の種類の機能ブロックも存在するし、新たな種類の機
能ブロックは、フィールドバス環境において動作するように規定されるかまたは
作成される。

【００２９】 トランスデューサブロックは、機能ブロックの入力および出力を、センサおよ
び装置アクチュエータのような局所ハードウェア装置に結合し、これにより、機
能ブロックが局所センサの出力を読取り、局所装置に、弁部材を移動させるよう
なひとつ以上の機能を実行させることが可能となる。トランスデューサブロック
は典型的には、例えば、局所装置の種類を特定する情報、局所装置と関連する較
正情報などを含め、局所装置により送られた信号を解釈することと、この装置を
正しく制御することが必要な情報を含む。単一の信号トランスデューサブロック
は典型的には、各入力または出力機能ブロックと関連する。

【００３０】 たいていの機能ブロックは、予め定められた基準に基づいて警報または事象指
標を生成すること、異なるモードで異なった方法で動作することができる。一般
的に、機能ブロックは、例えば、機能ブロックのアルゴリズムが自動的に動作す
る自動モードと、機能ブロックの入力または出力が手動で制御される操作員モー
ドと、ブロックが動作しない不使用（out―of―service）モードと、ブロックの
動作が異なるブロックの出力から影響を受ける（により決定される）カスケード
モードと、リモートコンピュータがブロックのモードを決定するひとつ以上のリ
モートモードとで動作する。しかしながら、他の動作モードもフィールドバスプ
ロトコルにおいては存在する。

【００３１】 重要なことに、各ブロックは、フィールドバスプロトコルにより規定される標
準的なメッセージフォーマットを用いて、フィールドバス３４によって同じまた
は異なるフィールド装置内で他のブロックと通信することができる。その結果、
機能ブロック（同じまたは異なる装置内で）を組み合わせて、互いに通信し、ひ
とつ以上の非集中制御ループを生成してよい。このように、例えば、あるフィー
ルド装置内のＰＩＤ機能ブロックは、バス３４によって接続されて、第２のフィ
ールド装置内のＡＩ機能ブロックの出力を受け取り、第３のフィールド装置内の
ＡＯ機能ブロックにデータを送り、フィードバックとしてＡＯ機能ブロックの出
力を受け取って、ＤＣＳ制御器とは別個のかつこれから離れたプロセス制御ルー
プを作成する。このようにして、機能ブロックを組み合わせて制御機能を集中Ｄ
ＣＳ環境外に移動させ、これにより、ＤＣＳ多機能制御器が監督機能または調整
機能を実行するか、またはこれらの制御器を全くなくすことが可能となる。さら
に、機能ブロックは、プロセスの容易な構成のために、図形の、ブロック志向の
構造を与え、様々な提供者（サプライヤ）からのフィールド装置の間で機能の分
散を可能とする。なぜならばこれらのブロックは、無矛盾の通信プロトコルを用
いているからである。

【００３２】 ブロックオブジェクトを含むことと実行することに加えて、各フィールド装置
は、リンクオブジェクト、トレンド（trend）オブジェクト、警報オブジェクト 、およびビュー（view）オブジェクトを含むひとつ以上の他のオブジェクトを含
む、リンクオブジェクトは、フィールド装置の内部およびフィールドバス３４を
介して、ブロック（機能ブロックのような）の入力と出力との間のリンクを規定
する。

【００３３】 トレンドオブジェクトにより、図１のホスト１２または制御器１４のような他
の装置によりアクセスされるために機能ブロックパラメータを局所的に傾向を取
る（trending）ことができる。トレンドオブジェクトは、例えば機能ブロックパ
ラメータに関する短期履歴データを保持し、このデータを、バス３４によって他
の装置または機能ブロックに非同期的に報告する。警報オブジェクトは、バス３
４によって警報および事象を報告する。これらの警報または事象は、装置内でま
たは装置のブロック内で生じる事象に関してもよい。ビューオブジェクトは、標
準的な人間／機械インターフェーシングで用いられるブロックパラメータの予め
定められたグループ化であり、時々視聴用に他の装置に送られてよい。

【００３４】 さて図２を参照して、図１のフィールド装置１６−２８のいずれかであってよ
い３つのフィールドバス装置は、資源ブロック４８、機能ブロック５０、５１、
または５２、およびトランスデューサブロック５３、５４を含むものとして示さ
れる。第１の装置においては、機能ブロック５０（入力機能ブロックであってよ
い）は、トランスデューサブロック５３を介してセンサ５５に結合される。セン
サ５５は、例えば、温度センサ、設定点指標センサなどであってよい。第２の装
置においては、機能ブロック５１（出力機能ブロックであってよい）は、トラン
スデューサブロック５４を介して弁５６のような出力装置に結合される。第３の
装置においては、機能ブロック５２（制御機能ブロックであってよい）は、機能
ブロック５２の入力パラメータの傾向を取るためのそれと関連する傾向オブジェ
クト５７を有する。

【００３５】 リンクオブジェクト５８は、関連するブロックの各々のブロックパラメータを
規定し、警報オブジェクト５９は、関連するブロックの各々に対して警報または
事象通知を与える。ビューオブジェクト６０は、機能ブロック５０、５１、５２
の各々と関連し、それらが関連する機能ブロックのためのデータリストを含むか
またはグループ化する。これらのリストは、一組の異なる規定されたビューの各
々に必要な情報を含む。当然、図２の装置は単に例示であり、他の数のおよび種
類のブロックオブジェクト、リンクオブジェクト、警報オブジェクト、トレンド
オブジェクト、およびビューオブジェクトが、フィールド装置で与えられよい。

【００３６】 さて図３を参照して、ポジショナ／弁装置としての装置１６、１８、２４と、
送信器として装置２０、２２、２６、２８を示すブロック図は、ポジショナ／弁
１６、送信器２０、およびブリッジ３０と関連する機能ブロックを示す。図３に
示されるように、ポジショナ／弁１６は、資源（ＲＳＣ）ブロック６１と、トラ
ンスデューサ（ＸＤＣＲ）機能ブロック６２と、アナログ出力（ＡＯ）機能ブロ
ック６３、２つのＰＩＤ機能ブロック６４、６５、および信号セレクト（ＳＳ）
機能ブロック６９を含む多数の機能ブロックとを含む。送信器２０は、資源ブロ
ック６１と、２つのトランスデューサブロック６２と、２つのアナログ入力（Ａ
Ｉ）機能ブロック６６、６７とを含む。また、ブリッジ３０は、資源ブロック６
１とＰＩＤ機能ブロック６８とを含む。

【００３７】 理解されるように、図３の様々な機能ブロックは、多くの制御ループ内で（バ
ス３４によって通信を行うことにより）一緒に動作してもよく、ポジショナ／弁
１６、 送信器２０およびブリッジ３０の機能ブロックが位置している制御ルー
プは、図３において、これらの機能ブロックの各々に接続されたループ識別ブロ
ックにより特定される。このように、図３に示されるように、ポジショナ／弁１
６のＡＯ機能ブロック６３およびＰＩＤ機能ブロック６４と送信器２０のＡＩ機
能ブロック６６とは、ＬＯＯＰ１として示される制御ループ内で接続され、一方
、ポジショナ／弁１６のＳＳ機能ブロック６９と、送信器２０のＡＩ機能ブロッ
ク６７と、ブリッジ３０のＰＩＤ機能ブロック６８とは、ＬＯＯＰ２として示さ
れる制御ループ内で接続される。ポジショナ／弁１６の他のＰＩＤ機能ブロック
６５は、ＬＯＯＰ３として示される制御ループ内で接続される。

【００３８】 図３でＬＯＯＰ１として示される制御ループを構成する相互接続された機能ブ
ロックは、図４で示されるこの制御ループの概略図においてより詳細に示される
。図４からわかるように、制御ループＬＯＯＰ１は、ポジショナ／弁１６のＡＯ
機能ブロック６３およびＰＩＤ機能ブロック６４と送信器２０のＡＩ機能ブロッ
ク６６（図３）との間の通信リンクにより完全に形成される。図４の制御ループ
図は、これらの機能ブロックのプロセスおよび制御入力と出力とを接続する線を
用いて、これらの機能ブロック間の通信相互接続を示す。プロセス測定値または
プロセスパラメータ信号を含んでよいＡＩ機能ブロック６６の出力は、バスセグ
メント３４ｂによって、ＰＩＤ機能ブロック６４の入力に通信可能に結合され、
ブロック６４は、ＡＯ機能ブロック６３の入力に通信可能に結合される制御信号
を含む出力を有する。ＡＯ機能ブロック６３の出力は、例えば、弁１６の位置を
示すフィードバック信号を含み、ＰＩＤ機能ブロック６４の制御入力に接続され
る。ＰＩＤ機能ブロック６４は、このフィードバック信号を、ＡＩ機能ブロック
６６からのプロセス測定値信号と一緒に用いて、ＡＯ機能ブロック６３の正しい
制御を実行する。当然のことながら、ＡＯ機能ブロック６３およびＰＩＤ機能ブ
ロック６４の場合と同様に、機能ブロックが同じフィールド装置（例えばポジシ
ョナ／弁１６）内にある場合、または標準的なフィールドバス同期通信を用いて
２線式通信バス３４によって実行されてよい場合に、図４の制御ループ図内で線
により示される接続は、フィールド装置内で内的に行われてよい。当然、他の制
御ループは、他の構成で通信可能に相互接続される他の機能ブロックにより実行
される。

【００３９】 通信および制御活動を実行し、行なうには、フィールドバスプロトコルは、物
理層、通信「スタック（ stack）」、およびユーザ層として特定される技術の３
つのカテゴリを用いる。ユーザ層は、ブロック（機能ブロックのような）の形で
与えられた制御および構成機能と、特定のプロセス制御装置またはフィールド装
置内のオブジェクトとを含む。ユーザ層は典型的には装置製造者により所有権を
主張するように設計されるが、フィールドバスプロトコルにより規定される標準
的なメッセージフォーマットに従ってメッセージを受信送信することができ、標
準的な方法でユーザにより構成可能でなければならない。物理層および通信スタ
ックは、２線式バス３４を用いて標準化された方法で様々なフィールド装置の様
々なフィールドブロック間で通信を実行する必要があり、周知の開放型システム
間相互接続（ＯＳＩ）層通信モデルとしてモデル化されてよい。

【００４０】 ＯＳＩ層１に相当する物理層は、各フィールド装置およびバス３４内に埋めこ
まれ、フィールドバス送信媒体（２線式バス３４）から受信した電磁信号を、フ
ィールド装置の通信スタックにより用いられるメッセージに変換することができ
る。物理層は、バス３４および、フィールド装置の入出力でバス３４上に存在す
る電磁信号と考えられる。

【００４１】 通信スタックは、各フィールドバス装置内に存在し、ＯＳＩ層２に相当するデ
ータリンク層と、フィールドバスアクセスサブレイヤと、ＯＳＩ層６に相当する
フィールドバスメッセージ仕様（ specification）層とを含む。フィールドバス
プロトコルにおいてＯＳＩ層３−５の対応する構造はない。しかしながら、フィ
ールドバス装置のアプリケーションは層７を含み、一方、ユーザ層は層８であり
、これはＯＳＩプロトコルにおいては規定されていない。通信スタックの各層は
、フィールドバス３４上に送信されるメッセージまたは信号のある部分を符号化
または復号化する役割をする。その結果、通信スタックの各層は、プリアンブル
、開始区切り（デリミタ）、および終了区切り（デリミタ）を付加するかまたは
除き、場合によっては、フィールドバス信号の除かれた（stripped）部分を復号
化して、信号またはメッセージの残り部分がどこに送られるべきか、または、例
えば、受信フィールド装置内にはない機能ブロックのメッセージまたはデータを
含むという理由でその信号が破棄されるべきかどうか特定する。

【００４２】 データリンク層は、バス３４へのメッセージの送信を制御し、リンクアクティ
ブスケデューラ（ link active scheduler）と呼ばれる確定的集中型バススケデ
ューラに従ってバス３４にアクセスするが、これを以下に詳細に述べる。データ
リンク層は、送信媒体上の信号からプリアンブルを取り除き、受信されたプリア
ンブルを用いて、フィールド装置の内部クロックを入来するフィールドバス信号
と同期させる。同様に、データリンク層は、通信スタック上のメッセージを物理
フィールドバス信号に変換し、これらの信号をクロック情報で符号化して、２線
式バス３４上の送信のための適切なプリアンブルを有する「同期シリアル」信号
を生成する。複号化プロセスの間、データリンク層は、開始区切りおよび終了区
切りのような、プリアンブル内の特殊コードを認識して特定のフィールドバスメ
ッセージの始まりおよび終わりを特定し、チエックサムを行って、バス３４から
受信した信号またはメッセージの完全性を確認する。同様に、データリンク層は
、通信スタック上のメッセージに開始および終了区切りを付加することにより、
適切な時間に送信媒体上にこれらの信号を配置することにより、バス３４上にフ
ィールドバス信号を送信する。

【００４３】 フィールドバスメッセージ指定層によって、標準的な一組のメッセージフォー
マットを用いて、ユーザ層（即ちフィールド装置の機能ブロック、オブジェクト
など）が、バス３４によって通信を行い、通信スタックに置かれるべきかつユー
ザ層に与えられるべきメッセージを組み立てるのに必要な通信サービス、メッセ
ージフォーマット、およびプロトコルふるまい（behavior）を記述するのが可能
となる。フィールドバスメッセージ指定層は、ユーザ層のために標準化された通
信を供給し、具体的なフィールドバスメッセージ仕様通信サービスは、上で説明
されたオブジェクトの各種類ごとに規定される。例えば、フィールドバスメッセ
ージ指定層は、ユーザが装置のオブジェクトディクショナリを読むことができる
ようなオブジェクトディクショナリサービスを含む。オブジェクトディクショナ
リは、装置のオブジェクト（ブロックオブジェクトのような）を記述するか特定
するオブジェクト記述を記憶する。フィールドバスメッセージ指定層は、装置の
ひとつ以上のオブジェクトと関連する、以下に説明される仮想通信関係（ＶＣＲ
）として知られる、通信関係をユーザが読むとともに変更することができる文脈
管理サービスを与える。さらに、フィールドバスメッセージ指定層は、可変アク
セスサービス、事象サービス、アップロードおよびダウンロードサービス、プロ
グラム呼び出しサービスを与えるが、これらすべてはフィールドバスプロトコル
では周知であり、従ってここではあまり詳細に述べない。フィールドバスアクセ
スサブレイヤは、フィルドバスメッセージ指定層をデータリンク層にマップする
。

【００４４】 これらの層の動作を可能とするには、各フィールド装置は、管理情報ベース（
ＭＩＢ）を含み、これは、ＶＣＲと、動的変数と、統計と、リンクアクティブス
ケジューラタイミングスケジュールと、機能ブロック実行タイミングスケジュー
ルと、装置タグおよびアドレス情報とを記憶するデータベースである。当然、Ｍ
ＩＢ内の情報は、標準的なメッセージまたはコマンドを用いて、どんなときでも
アクセスされても、変更されてもよい。さらに、ユーザまたはホストにＶＦＤに
おける情報の拡大されたビューを与えるべく、各装置には通常、装置記述が与え
られている。装置記述は典型的には、ホストにより用いられるべくトークンを与
えられなければならないが、装置のＶＦＤにおけるデータの意味をホストが理解
するために必要な情報を記憶する。

【００４５】 理解されるように、プロセス制御ネットワーク中に分散された機能ブロックを
用いて制御戦略を実行するには、機能ブロックの実行は、特定の制御ループ内の
他の機能ブロックの実行に対して正確にスケジュールされなければならない。同
様に、様々な機能ブロック間の通信は、各機能ブロックが実行される前に適切な
データがその機能ブロックに与えられるようにバス３４上で正確にスケジュール
されなければならない。

【００４６】 様々なフィールド装置（およびフィールド装置内の様々な機能ブロック）がフ
ィールドバス送信媒体によって通信を行う方法を、図１を参照して今から述べる
。通信を行うには、バス３４の各セグメント上のリンクマスタ装置（例えば装置
１２、１６、および２６）のひとつは、バス３４の関連のセグメント上でアクテ
ィブに通信をスケジュールし、制御するリンクアクティブスケジューラ（ＬＡＳ
）として動作する。バス３４の各セグメントごとのＬＡＳは、各装置の各機能ブ
ロックがバス３４上で周期的な通信活動を開始するようスケジュールされた時間
と、この通信活動が生じる時間の長さとを含む通信スケジュール（リンクアクテ
ィブスケジュール）を記憶し、更新する。バス３４の各セグメント上ではひとつ
のアクティブＬＡＳ装置だけがあってもよいが、他のリンクマスタ装置（セグメ
ント３４ｂ上の装置２２のような）は、バックアップＬＡＳとして機能してもよ
く、例えば、現行のＬＡＳが故障するとアクティブになる。基本装置は、どんな
時でもＬＡＳになる能力は有していない。

【００４７】 一般に、バス３４による通信活動は、繰り返しマクロサイクルに分割され、こ
れらの各々は、バス３４の特定のセグメント上でアクティブな各機能ブロックご
とのひとつの同期通信と、バス３４上のセグメント上でアクティブなひとつ以上
の機能ブロックまたは装置のひとつ以上の非同期通信とを含む。装置は、バス３
４上のブリッジおよびＬＡＳの調整された動作によって、バス３４の異なるセグ
メントに物理的に接続されたとしても、アクティブであってよい、即ち、バス３
４の何らかのセグメントにデータを送信しまたはそこからデータを受信してもよ
い。

【００４８】 各マクロサイクルの間、バス３４上の特定のセグメント上でアクティブな機能
ブロックの各々は、異なるが、正確にスケジュールされる（同期）時間で通常は
実行され、そして別の正確にスケジュールされる時間では、適切なＬＡＳにより
生成されたコンペル（compel）データコマンドに応答して、バス３４のそのセグ
メント上でその出力データを発する。好ましくは、各機能ブロックは、その機能
ブロックの実行期間の終了後まもなくその出力データを発するようにスケジュー
ルされる。さらに、様々な機能ブロックのデータを発する時間は、バス３４の特
定のセグメント上の２つの機能ブロックが同時にデータを発しないようにシリア
ルにスケジュールされる。同期通信が生じていない間、各フィールド装置は、ト
ークン駆動通信を用いて非同期的に警報データ、ビューデータなどを送信するこ
とが許可される。実行時間と各機能ブロックの実行を完了するのに必要な時間量
が、機能ブロックが常駐している装置の管理情報ベース（ＭＩＢ）内に記憶され
、一方、上で述べたように、バス３４のセグメント上の装置の各々にコンペルデ
ータコマンドを送る時間が、そのセグメントに対するＬＡＳ装置のＭＩＢ内に記
憶される。これらの時間は典型的にはオフセット時間として記憶される。なぜな
ら、機能ブロックが、バス３４に接続された装置全てがわかっている「絶対リン
クスケジュール開始時間」の始まりからのオフセットとしてデータを実行するか
または送る予定の時間を特定するからである。

【００４９】 各マクロサイクルの間に通信を実行するには、ＬＡＳ、例えば、バスセグメン
ト３４ｂのＬＡＳ１６は、リンクアクティブスケジュール内に記憶された送信時
間のリストに従って、バスセグメント３４ｂ上の装置の各々にコンペルデータコ
マンドを送る。コンペルデータコマンドを受信すると、装置の機能ブロックは、
ある特定時間バス３４上にその出力データを発する。機能ブロックの各々は典型
的には、ブロックがコンペルデータコマンドを受け取るようにスケジュールされ
る少し前にその機能ブロックの実行が完了するようにスケジュールされているの
で、コンペルデータコマンドに応答して発せられたデータは、機能ブロックの最
新の出力データであるべきである。しかしながら、機能ブロックがゆっくりと実
行されていて、コンペルデータコマンドを受信するときに新たな出力をラッチし
ないならば、機能ブロックは、機能ブロックの最後の実行の間に生成された出力
データを発し、発せられたデータがタイムスタンプを用いる古いデータであると
示す。

【００５０】 ＬＡＳが、バス３４の特定のセグメント上の機能ブロックの各々にコンペルデ
ータコマンドを送った後、そしてその機能ブロックが実行している間、ＬＡＳは
非同期通通信を行ってよい。非同期通信を実行するには、ＬＡＳは、パストーク
ンメッセージを特定のフィールド装置に送る。フィールド装置がパストークンメ
ッセージを受け取ると、そのフィールド装置はバス３４（またはそのセグメント
）に完全なアクセスを有し、警報メッセージ、トレンドデータ、操作員設定点変
化などの非同期メッセージを、そのメッセージが終了するかまたは最大の割り当
てられた「トークン保持時間」が満了になるまで送ることが出来る。その後、フ
ィールド装置はバス３４（特にその特定のセグメント）を解放し、ＬＡＳは、べ
つの装置にパストークンメッセージを送る。このプロセスは、マクロサイクルの
終わりまで、または同期通信を実行するためにＬＡＳがコンペルデータコマンド
を送るようにスケジュールされるまで繰り返される。当然、メッセージ通信量と
、バス３４の特定のセグメントに結合された装置およびブロックの数に依って、
各マクロサイクルの間にあらゆる装置がパストークンメッセージを受信してよい
わけではない。

【００５１】 図５は、図１のバスセグメント３４ｂ上の機能ブロックがバスセグメント３４
ｂの各サイクルの間に実行される時間と、バスセグメント３４ｂと関連する各マ
クロサイクルの間に同期通信が行われる時間とを示すタイミング該略図である。
図５のタイミングスケジュールにおいては、時間は水平軸上に示され、ポジショ
ナ／弁１６および送信器２０（図３の）様々な機能ブロックと関連する活動は垂
直軸上に示される。機能ブロックの各々が動作する制御ループが、図５に下付き
文字で識別される。ＡＩLOOP1 は、送信器２０のＡＩ機能ブロック６６を参照し
、ＰＩＤLOOP1 は、ポジショナ／弁１６のＰＩＤ機能ブロック６４を参照する。
示される機能ブロックの各々のブロック実行期間は、網状の陰影をつけられたボ
ックスにより示され、各のスケジュールされた同期通信は、図５において垂直バ
ーで識別される。

【００５２】 このように、セグメント３４ｂ（図１）のいずれかの特定のマクロサイクルの
間に、図５のタイミングスケジュールに従って、ＡＩLOOP1機能ブロックはまず 、ボックス７０により特定された時間期間に実行される。次いで、垂直バー７２
により示される時間的な期間の間、ＡＩLOOP1 機能ブロックの出力は、バスセグ
メント３４ｂのＬＡＳからのコンペルデータコマンドに応答して、バス３４ｂ上
に発せられる。同様に、ボックス７４、７６、７８、８０、８１は、それぞれ機
能ブロックＰＩＤLOOP1、ＡＩLOOP2、ＡＯLOOP1、ＳＳLOOP2、およびＰＩＤLOOP
3(異なるブロックの各々に対し異なる）の実行時間を示し、一方、垂直バー８２
、８４、８６、８９は、それぞれＰＩＤLOOP1、ＡＩLOOP2、ＡＯLOOP1、ＳＳLOO
P2、およびＰＩＤLOOP3がバスセグメント３４ｂ上にデータを発する時間を示す 。

【００５３】 明らかに、図５のタイミング図は、非同期通信活動に利用される時間も示して
いるが、この非同期通信活動は、機能ブロックのいずれかの実行時間の間と、機
能ブロックが実行されていない間のマクロサイクルの終わりの時間の間と、同期
通信がバスセグメント３４ｂ上で行われていない時に、おこなわれてよい。当然
、所望であれば、異なる機能ブロックが、同じ時間で実行されるように意図的に
スケジュールされることも可能であり、もし、例えば、ある機能ブロックにより
生成されたデータに他の装置が加入して（ subscribe）いないならば、機能ブロ
ックすべてがバス上でデータを発する必要があるわけではない。

【００５４】 フィールド装置は、各フィールド装置のスタックのフィールドバスアクセスサ
ブレイヤにおいて規定された３つの仮想通信関係（ＶＣＲ）のひとつを用いてバ
ス３４によってデータおよびメッセージを発するかまたはこれを送信することが
出来る。クランアイント／サーバＶＣＲは、バス３４上の装置間でキューに入れ
られた、未スケジュールの、ユーザ起動の、１対１通信のために用いられる。こ
のようなキューに入れられたメッセージは、前のメッセージに上書きすることな
くそれらの優先順位に従って、送信用に提示された順序で送られ、受信される。
このように、フィールド装置は、それがＬＡＳからパストークンメッセージを受
け取って要求メッセージをバス３４上の別の装置送るときに、クライアント／サ
ーバＶＣＲを用いてよい。要求者は「クライアント」と呼ばれ、要求を受け取る
装置は「サーバ」と呼ばれる。サーバは、それがＬＡＳからパストークンメッセ
ージを受け取るときに、応答を送る。クライアント／サーバＶＣＲは、設定点変
化、チューニングアクセスおよび変化、警報肯定応答、および装置アップロード
およびダウンロードのような操作員起動の要求を実行するために用いられる。

【００５５】 報告配布（ report distribution）ＶＣＲは、キューに入れられた、未スケジ
ュールの、ユーザ起動の１対多の通信のために用いられる。例えば、事象または
トレンド報告を有するフィールド装置はＬＡＳからパストークンを受け取り、そ
のフィールド装置は、その装置の通信スタックのフィールドバスアクセスサブレ
イヤにおいて規定された「グループアドレス」にそのメッセージを送る。そのＶ
ＣＲを聴くように構成される装置は報告を受け取るであろう。報告配布ＶＣＲタ
イプは典型的には、通知または操作員コンソールに警報を通知を送るのにフィー
ルドバス装置により用いられる。

【００５６】 発行者／加入者(publisher／ subscriber)ＶＣＲタイプは、バッファされた１
対多通信のために用いられる。バッファされた通信は、データの最新のバージョ
ンだけを記憶し、送り、従って、新たなデータが完全に前のデータに上書きされ
る。機能ブロック出力は、例えば、バッファされたデータを含む。「発行者」フ
ィールド装置は、発行者装置がＬＡＳからまたは加入者装置からコンペルデータ
メッセージを受けとると、バス３４上の全ての「加入者」フィールド装置に発行
者／加入者ＶＣＲタイプを用いてメッセージを発するかまたはブロードキャスト
する。発行者／加入者関係は予め定められており、各フィールド装置の通信スタ
ックのフィールドバスアクセスサブレイヤ内に規定され記憶される。

【００５７】 確実にバス３４上で正しい通信活動を行うには、各ＬＡＳは、バス３４のセグ
メントに接続されたフィールド装置全てに時間配布メッセージを周期的に送り、
これにより、受信装置は、その局所的アプリケーション時間を互いに同期するよ
うに調節することが可能となる。これらの同期メッセージ間で、クロック時間は
、それ自身の内部クロックに基づいて各装置内で独立して維持される。例えば、
いつデータが生成されたかを示すために、クロックの同期により、フィールド装
置がフィールドネットワーク中のデータにタイムスタンプを押すことが可能とな
る。

【００５８】 さらに、各バスセグメント上の各ＬＡＳ（および他のリンクマスタ装置）は、
「生（live）リスト」を記憶するが、これは、バス３４のそのセグメントに接続
された装置全てのリストであり、即ち、パストークンメッセージに正しく応答す
る装置全てである。ＬＡＳは継続的に、生リストに載っていないアドレスにプロ
ーブノードメッセージを周期的に送ることにより、バスセグメントに付加された
新たな装置を認識する。事実、各ＬＡＳは、生リスト内のフィールド装置全てに
パストークンメッセージを送るサイクルを終了した後に、少なくともひとつのア
ドレスを探査する必要がある。フィールド装置が、探査されたアドレスに存在し
、プローブノードメッセージを受け取るならば、装置はすぐにプローブ応答メッ
セージを戻す。プローブ応答メッセージを受け取ると、ＬＡＳは、その装置を生
リストに付加し、探査されたフィールド装置にノード活性化メッセージを送るこ
とで確認を取る。フィールド装置は、そのフィールド装置はパストークンメッセ
ージに正しく応答する限りは、生リスト上にあるままである。しかしながら、フ
ィールド装置が３回連続して試みた後で、トークンを用いないかまたはすぐにト
ークンをＬＡＳに戻してしまう場合は、ＬＡＳは、そのフィールド装置を生リス
トから除く。フィールド装置が生リストに付加されるかまたは生リストから除か
れるとき、ＬＡＳは、バス３４の適切なセグメント上の全ての他のリンクマスタ
装置にブロードキャストし、これにより、各リンクマスタ装置は、生リストの現
在のコピーを維持する。

【００５９】 上で述べたように、フィールド装置とその機能ブロックとの間の通信相互接続
はユーザにより決定され、例えば、ホスト１２内に位置した構成アプリケーショ
ンを用いて、プロセス制御ネットワーク１０内で実行される。しかしながら、構
成された後、プロセスセネットワーク１０は、装置診断またはプロセス診断を考
慮することなく動作し、従って、ホスト１２とインターフェースして標準的なＩ
／Ｏ機能を実行するが、診断機能を実行しない。

【００６０】 ユーザが診断を行いたいとき、ユーザは、ホスト１２に、例えば、制御ループ
１のＡＯ機能ブロック６３に設定点変化を送らせ、ＡＯ機能ブロック６３と関連
するトレンドオブジェクトを用いてＡＯ機能ブロック６３内にフィードバックを
記録させる。しかしながら、この種類の通信を行うには、ホスト１２は非同期通
信を用いなければならないが、この非同期通信により、ホスト１２がＬＡＳから
パストークンメッセージを受け取って始めて、ホスト１２がバス３４にアクセス
することが可能となる。その結果、ホスト１２により生成された診断信号の異な
る部分は、正確に決定された時間（または正確にスケジュールされた時間）にＡ
Ｏ機能ブロック６３に到着しないかもしれない。これは、ＡＯ機能ブロック６３
で受信された診断信号は、特定の時間にバス３４上の通信バックログ（backlog ）により少なくとも部分的に決定される形状を有することを意味する。この理由
で、非同期通信を用いて送られる診断信号は、厳密に確定的ではなく、従って、
装置またはプロセス上で診断を行う際にあまり効果的ではないかもしれない。さ
らに、ホスト１２は、トレンドオブジェクトにより集められたフィードバックデ
ータは、オーバーライトなどにより喪失されないということを保証する方法はな
い。また、ホスト１２は、ブロックのモードを特に変更することなく、ＰＩＤ機
能ブロックのようなＬＯＯＰ１内の機能ブロック６４のモードを制御する方法は
ない。

【００６１】 今まで、プロセス内で確実に完全でかつ厳密に確定的な診断を行うには、同期
通信よって、ホスト１２が適切な装置に設定点変化を送り、適切な装置により測
定されたデータを受信することが出来るように、ユーザはプロセス制御ネットー
ク１０をオフラインにして通信インターフェースを再構成しなけらばならなかっ
た。しかしながら、上で述べたように、診断が行われるべきときはいつでも、こ
の手続きはプロセスを遮断し、オペレータにプロセスを再構成するように要求す
る。これら両方は望ましくはない。さらに、この診断手続きの間にホスト１２に
より実行される制御は、プロセスの通常動作の間に、通信可能にリンクされた機
能ブロックにより実行される制御とは異なり、したがって、プロセスが通常に制
御されている間に、集められたプロセスデータはプロセスの動作を示さないかも
しれない。その結果、ホスト装置は典型的には、ユーザが通常動作と診断動作と
の間で切り替えしてそれにより診断を可能化することができる能力を有していな
い。

【００６２】 例えば、フィールドバスプロセス制御ネットワークにおいてこれらの問題を克
服するには、新たな診断ブロックが位置している装置以外の装置に関してまたは
この装置を用いて装置診断および／またはプロセス診断を行うために、本発明に
従って新たな種類の機能ブロックが与えられる。本発明の遠隔診断機能ブロック
は、同期周期的通信を用いて（例えばフィールドバスプロトコルの発行者／加入
者ＶＣＲ）バス３４上で他の装置機能ブロックと通信するように構成され、同期
周期的通信を用いて装置パラメータまたは他のプロセスパラメータの測定値のよ
うなデータを受信するように構成される。このように、本発明の遠隔診断機能ブ
ロックは、異なる機能ブロックに確定的な診断制御機能ブロックを送るとともに
、周期的に装置またはプロセスパラメータに関するデータを受信し、記憶する。
さらに、本発明の遠隔診断機能ブロックは、診断が行われている装置以外の装置
内に記憶されてよく、これにより、プロセス制御内ネットワーク内ででどんな数
の異なる装置に関してでもまたはこれを用いて、診断機能ブロックを診断を行う
のに用いることができる。このように、例えば、本発明に従った遠隔診断機能ブ
ロックは、図３のポジショナ／弁装置１８のポジショナ内に記憶され、ポジショ
ナ／弁１６、１８、２４のいずれかに関して診断を行うのに用いられてよい。同
様に、本発明に従った診断機能ブロックは、その機能ブロックをバス３４のセグ
メント内のいずれかの装置に関して用いることができるようにホスト１２内に記
憶可能である。

【００６３】 一般的に言って、本発明の遠隔診断機能ブロックは、装置診断が行われている
時間に別の装置（または同じ装置）のある機能ブロックに通信可能にリンクされ
、装置診断が行われていない時間にその他の機能ブロックから結合が絶たれる。
代替的には、本発明の遠隔診断機能ブロックは、装置診断またはプロセス診断の
ような診断が行われていないときでさえ制御ループ内の他の機能ブロックに通信
可能に結合されたままであるように制御ループ内に配置されてよい。

【００６４】 さて図６を参照して、診断機能ブロック９０の出力がＡＯ機能ブロック６３の
入力に接続され、ＡＯ機能ブロック６３の出力が診断機能ブロック９０のフィー
ドバック入力に接続されるように、診断機能ブロック９０は、ポジショナ／弁１
６（図３）のＡＯ機能ブロック６３に通信可能にリンクされるかまたは結合され
るものとして示される。動作の間に、診断機能ブロック９０は、規則的にスケジ
ュールされた周期的通信（例えば発行者／加入者ＶＣＲを用いて）によりバスセ
グメント３４ｂ（図３）によってＡＯ機能ブロック６３の設定点の変化を特定す
る診断制御信号を送り、規則的にスケジュールされた周期的通信によりバスセグ
メント３４ｂによって弁１６の弁部材の位置を示すＡＯ機能ブロック６３からフ
ィードバック信号を受信する。診断機能ブロック９０は、ＡＯ機能ブロックによ
り生成された受信されたフィードバック信号を記憶し、全体の診断信号がＡＯ機
能ブロック６３にまたは診断の間のひとつ以上の中間的な時間に送られた後に、
受信されたフィードバック信号と、そして所望であれば、ＡＯ機能部ブロック６
３を制御するのに用いられる診断制御信号の指標を、ホスト１２に処理のために
送る。当然、所望であれば、診断機能ブロック９０は、診断制御信号とＡＯ機能
ブロックから受信されたフィードバック信号とを用いて装置診断を行うプロセッ
サまたは他の装置も有することができる。

【００６５】 上で述べたように、図６の診断制御ループにより示される相互装置通信接続は
、同期周期的通信を用いて実行され、従って、機能ブロック９０により生成され
た診断制御信号は、ＡＯ機能ブロック６３の入力で受信された同じ信号であるこ
とが保証される。同様に、これらの同期通信により、ＡＯ機能ブロック６３によ
り生じさせられた出力データが確実に周期的に追跡され記録される。

【００６６】 当然、図６の診断制御ループを実現するには、ホスト１２のようなホストは、
図６に示される方法で診断機能ブロック９０をＡＯ機能ブロック６３に接続する
ようにプロセス制御ネットワーク１０を再構成しなければならず、その後、診断
機能ブロック９０にＡＯ機能ブロック６３に関して診断テストを実行するように
命令しなければならない。診断テストが完了し、機能ブロック９０が、記憶され
たデータ全てを処理のためにホスト１２（または他の装置）に送った後、ホスト
１２はプロセス制御ネットワーク１０の通常動作の間に用いられる制御方式を再
インストールするようにプロセス制御ネットワーク１０を再構成しなければなら
ない。好ましくは、ホスト１２（または他の構成装置）は、図６に示される診断
ループが実行されている間は通常のまたは既存の制御方式を記憶する。

【００６７】 図６の診断機能ブロックは、ポジショナ／弁装置１６に関し装置診断を行うよ
うに装置１８内に位置するものとして示されるが、この機能ブロックはプロセス
制御ネットワーク１０内の他の装置内に位置することもできるし、ポジショナ、
ポジショナ／弁装置、ダンパ、ファンなどのような出力装置を含め、プロセス制
御ネットワーク１０内の装置に関し診断を行うのに用いられる。

【００６８】 しかしながら、上で述べたように、本発明に従った診断機能ブロックは、プロ
セス制御ネットワークを再構成することなく、装置診断およびプロセス診断を実
行するか行うことができるように、そのプロセス制御ループの動作の間に終始プ
ロセス制御ループ構成内で接続可能である。さて図７を参照して、ＡＩ機能ブロ
ック６６と、ＰＩＤ機能ブロック６４と、ＡＯ機能ブロック６３と、診断機能ブ
ロック９２とを含む制御ループ９１が示される。図７からわかるように、ＡＯ機
能ブロック６３とＰＩＤ機能ブロック６４との間の制御ループ９１内に、診断機
能ブロック９２が挿入される（通信可能にリンクされる）。

【００６９】 プロセス制御ループ９１の通常動作の間に、ＡＩ機能ブロック６６は、プロセ
ス測定値またはプロセスパラメータをＰＩＤ機能ブロック６４に送り、このＰＩ
Ｄ機能ブロック６４は次いで、生じたプロセス制御信号を診断機能ブロック９２
に送る。診断機能ブロック９２は、このプロセス制御信号をポジショナ／弁装置
１６内のＡＯ機能ブロック６３の入力に送り、例えば、ＡＯ機能ブロック６３か
ら弁位置を示すフィードバック信号を受信する。診断機能ブロック９２はフィー
ドバック信号をＰＩＤ機能ブロック６４の入力に送り、ＰＩＤ機能ブロック６４
はこのフィードバック信号を（ＡＩ機能ブロック６６からの入力とともに）用い
て、新たなプロセス制御信号を計算する。このように、プロセス制御ループ９１
の通常動作の間、診断機能ブロック９２は、ＰＩＤ機能ブロック６４とＡＯ機能
ブロック６３との間で信号を通過させるだけで、図４の制御ループ内で接続され
たときと本質的に同じ方法でこれらの機能ブロックが動作できるようになる。

【００７０】 しかしながら、ユーザが装置診断またはプロセス診断を実行したいときに、ホ
スト１２は診断機能ブロック９２に（非同期通信によって）開始信号を送り、こ
れにより、診断機能ブロック９２は、ＰＩＤ機能ブロック６４に生じさせられた
プロセス制御信号をＡＯ機能ブロック６３の入力から切断し、診断制御信号をＡ
Ｏ機能ブロック６３の入力に送る。当然、診断制御信号は、装置診断またはプロ
セス診断を実行するように用いられる所望の信号であってよい。同時に、診断機
能ブロック９２は、ＡＯ機能ブロック６３から受信したフィードバックデータを
記憶し始め、および／または、ＡＩ機能ブロック６６および／または、ブロック
９４により図７に示される、プロセス内の他のプロセス測定装置または他の機能
ブロックから受け取った他のサンプリングされたプロセス測定値を記憶し始める
。当然、ブロック９４およびＡＩ機能ブロック６６からのプロセスパラメータは
、診断解析を行う際に用いられるべくホスト１２に最終的に送られるように、ト
レンドオブジェクトまたは所望の記憶ユニットを用いて診断機能ブロック９２内
に記憶されてよい。

【００７１】 装置診断またはプロセス診断の間に、診断機能ブロック９２はフィードバック
データをＰＩＤ機能ブロック６４に送ってよく、所望であれば、診断実行されて
いることをＰＩＤ機能ブロック６４に示すためにこのフィードバック信号を変更
してよい。この方法で、診断機能ブロック９２は、ＰＩＤ機能ブロック６４の場
合と同様にワインドアップ（windup）を防ぐのを助ける装置診断またはプロセス
診断を行いながら、ＰＩＤ機能ブロック６４の動作（モード）および／または制
御ループ９１内で他の機能ブロックの動作（モード）を制御する。

【００７２】 診断機能ブロック９２がＡＯ機能ブロック６３に診断信号を送り終えると、診
断機能ブロック９２は、ＰＩＤ機能ブロック６４により生じさせられるプロセス
制御信号をＡＯ機能ブロック６３に再び送るように、ＡＯ機能ブロック６３から
不変更のフィードバック信号をＰＩＤ機能ブロック６４に与えるように切り替え
を行う。さらに、診断の間のひとつ以上の中間的な時間に、または診断が完了し
た後に、診断機能ブロック９２は、例えば、非同期通信を用いてバス３４によっ
て、ホスト１２（または他の装置）に、集められたフィードバック、プロセスパ
ラメータおよび／または診断制御信号情報を送ってよい。

【００７３】 理解されるように、診断機能ブロック９２は、スケジュールされた周期的通信
によってＰＩＤ機能ブロック６４とＡＯ機能ブロック６３とに通信可能にリンク
され、従って、制御ループ９１の動作は制御ループ９１と関連する各マクロサイ
クルの間にもう少し長く時間をとるようになる。つまり、制御ループ９１の各マ
クロサイクルは、診断機能ブロック９２に必要な付加的な周期的スケジューリン
グにより、図４の制御ループのマクロサイクルよりもより多くの時間を同期通信
および機能部ブロックの実行にかけなければならない。事実、診断機能ブロック
９２を図４の制御ループ内に正しく挿入するには、機能ブロック９２の実行機関
は、図５のバー８２の（ＰＩＤ機能ブロック６４と関連するスケジュールされた
通信）後に図５のタイミングスケジュール内に挿入されなければならず、診断機
能ブロック９２とＡＯ機能ブロック６３との間のスケジュールされた通信（発行
（publishing））期間は、機能ブロック９２の挿入された実行期間の後でかつ図
５のボックス７８（ＡＯ機能ブロック６３の実行期間）の前で図５のタイミング
スケジュール内に挿入されなければならない。同様に、診断機能ブロック９２と
ＰＩＤ機能部ブロック６４との間のフィードバック通信を実行するためのスケジ
ュールされた実行および通信期間は、図５のバー８６（ＡＯ機能ブロック６３の
実行期間）の後で図５のタイミングスケジュール内に挿入されなければならない
。当然、ＡＯ機能ブロック６３およびＰＩＤ機能ブロック６４のＶＣＲは、これ
らの機能ブロックと診断機能ブロック９２との間でスケジュールされた通信を正
しく実行するように変更されてよい。

【００７４】 プロセス制御ネットワーク１０の通常動作の間に（即ち診断が行われていない
とき）診断機能ブロック９２は制御ループ９１内にとどまっているが、所望であ
れば、診断機能ブロック９２は、診断が行われていないときにプロセス制御ネッ
トワーク１０の制御ループができるだけ早く実行されるように構成されるように
診断が行われる時間のみ、制御ループ９１のような制御ループのスケジュール内
に挿入可能である。しかしながら、この動作は、プロセス診断が実行されようと
するときはいつでも、新たなプロセス制御構成がネットワーク内にダウンロード
されることを必要とする。

【００７５】 図８により詳細に示される診断機能ブロック９２は、ホスト１２からの開始信
号および停止信号を受信して復合化し、集められたデータを解析のためにホスト
１２に送り、診断機能ブロック９２の残りの動作を制御する診断エンジン９５を
含む。診断エンジン９５が開始信号を受信して複号化するとき、診断エンジン９
５は、診断信号発生器９６に、記憶された診断制御信号をスイッチ９７に送らせ
る。同時に、診断信号発生器９６により与えられた診断制御信号が機能ブロック
９２の制御信号信号出力に与えられ、これが例えばＡＯ機能ブロック６３の入力
に送られるように、診断エンジン９５は、信号コミュニケータを有するスイッチ
９７に、その出力を診断信号発生器９６に接続させる。制御信号出力を診断信号
発生器９６に接続させる。制御信号出力を診断信号発生器９６に接続されように
指示される前に、スイッチ９７は、プロセス制御信号入力（例えばＰＩＤ機能ブ
ロック６４からプロセス制御信号を受信するように接続される）を制御信号出力
に結合する。当然、スイッチ９７は典型的は、ソフトウェアで実行され、従って
、診断制御信号が診断機能ブロック９２の制御信号出力に送られるのかまたはプ
ロセス制御信号（制御信号入力で）がそこに送られるのかを制御するように設計
された切り替え論理を有していてよい。

【００７６】 装置診断またはプロセス診断を行うように動作しているとき、診断エンジン９
５によって、データキャプチャユニット９８は、プロセス制御ネットワーク１０
内の他の機能ブロックにより集められ、スケジュールされた周期的通信を用いて
診断機能ブロック９２に送られるプロセス測定値信号またはプロセスパラメータ
信号を集め記憶できるようになる。理解されるように、行われている診断の種類
に依って、どんな数のプロセスパラメータでもデータキャプチャユニット９８に
送られてよい。

【００７７】 フィードバックユニット９９は、ＡＯ機能ブロック６３（または診断機能ブロ
ック９２により制御されている他の機能ブロック）により生じさせられたフィー
ドバック信号を受信し、診断エンジン９５によりそうするように指示されたら、
これらの信号をメモリ内に記憶する。同様に、フィードバックユニット９９は、
受信されたフィードバック信号をＰＩＤ機能ブロック６４（またはＡＯ機能ブロ
ック６３を制御するのに用いられるプロセス制御信号を生成するブロックのよう
な他の機能ブロック）に送ってよい。

【００７８】 典型的には、フィールドバス環境においては、フィードバックユニット９９に
より受信された信号は値および状態を含み、状態は、受信されたフィードバック
信号と関連する制御ループ９１のさまざまな状態を示す。所望であれば、フィー
ドバックユニット９９は、ＡＯ機能ブロック６３から受信された信号の状態を、
例えば、制御ループ９１の通常動作を示す「良好・カスケード・不特定（good -
cascade - nonspecific）」状態から、局所オーバーライドが行われたとと示す
「良好・カスケード・オーバーライド（ good-cascade-override）」状態に変更
してよく、したがって、信号は、制御ループ９１の通常動作に従って生成されて
いない。変更された状態のフィードバック信号が、例えば、ＰＩＤ機能ブロック
６４に送られると、ＰＩＤ機能ブロック６４は、その信号の状態を復合化し、Ｐ
ＩＤ機能ブロック６４の出力がもはやＡＯ機能ブロック６３を制御するために用
いられないことを認識する。ＰＩＤ機能ブロック６４は、その後、例えば手動モ
ードにモードを換えるか変更し、この手動モードでは、ＰＩＤ機能ブロック６４
はその出力をロックし、ＡＯフィードバック信号とＡＩ機能ブロック６６の出力
とから新たなプロセス制御信号を計算するのを停止する。このモード変更プロセ
スは、ＰＩＤ機能ブロック６４が暴走（ runaway）状態に入らないようにするも
のである。この暴走状態においては、ＰＩＤ機能ブロック６４より生成された制
御信号はすぐに極端な状態になってしまう。なぜならＰＩＤ機能ブロック６４が
フィードバック信号を制御された値に効果もないのに強制しようとするからであ
る。理解されるように、ＰＩＤ機能ブロック６４のモード変更により、制御ルー
プ９１またはプロセス制御ネットワーク１０内の他の機能ブロックもモードを変
更するようになる。当然、診断が完了し、ＰＩＤ機能ブロック６４がＡＯ機能ブ
ロック６３を制御できるように制御ループ９１が動作しているときは、フィード
バックユニット９９は、フィードバック信号の状態を変更することなく、この信
号を通過させる。

【００７９】 正しいモード処理を実行するには、モード処理ユニット１００は、フィードバ
ック信号または他の制御された信号に加えられた正しい状態変更に関する論理お
よびデータを記憶して他の機能ブロックの所望のモード変更を実行し、この情報
を診断エンジン９５に伝達する。

【００８０】 当然、診断エンジン９５は、診断テストを実行する際に、診断を開始および停
止しても、所望の基準に基づいて診断機能ブロック９２の制御信号出力で生成さ
れるべき多数の異なる診断制御信号のひとつを制御しても、例えば、ＡＯ機能ブ
ロック６３からのフィードバック信号とデータキャプチャユニット９８により集
められたプロセスパラメータ信号のうちのひとつ以上を制限要因として用いても
よい。さらに、フィールドバスネットワークにおいては、診断制御信号は好まし
くは、ディジタル信号として記憶されるかまたは診断信号発生器９６内に記憶さ
れた機能に従って生成される。しかしながら、診断制御信号は、所望の方法で診
断機能ブロック９２内に記憶されても生成されてもよい。

【００８１】 理解されるように、ここで述べられた診断機能ブロック９０、９２により、診
断手続きの間に確実に確定的信号が装置に送られるように同期的スケジュールさ
れた通信を用いて装置診断および／またはプロセス診断を実行することができる
。同様に、ここで述べられた診断機能ブロック９２により、プロセスの通常動作
の間に実行されるものと同じプロセス制御構成を用いて、装置診断およびプロセ
ス診断が実行可能となり、これにより、ユーザはあまりプロセス制御ネットワー
クを再スケジュールするかまたは再構成する必要はなく装置診断またはプロセス
診断を行うことができ、診断の間に正確にプロセスの測定値を測定することがで
きる。

【００８２】 診断機能ブロック９０および／または９２は、下流側のＡＯ機能ブロック６３
（出力機能ブロック）に関してまたはこれを用いて診断を行うとともに、単純な
制御ループ構成で接続された上流側のＰＩＤ機能ブロック６４（制御機能ブロッ
ク）から入力を受け取りフィードバックをそこに与えるものとして説明されたが
、本発明も診断機能ブロックまたは他の診断機能ルーチンは、所望のごとく他の
出力機能または機能ブロックおよび他の制御機能または機能ブロックと関連して
用いられ、図７に示されるもの以外の構成を有する制御ループにおいて実行され
る。このように、例えば、診断機能ブロック９２は、ある機能ブロックを制御し
、ことなる機能ブロックからフィードバック信号を受信し、さらなる機能ブロッ
クからプロセス制御信号を受信するように構成される。

【００８３】 さらに、ここで述べられた診断機能ブロックはフィールドバス「機能ブロック
」の形で実行されたが、本発明の診断は、他の種類の制御システムおよび／また
は通信プロトコルと関連する他の種類のブロック、プログラム、ハードウェア、
ファームウェアなどを用いて実行可能である。事実、フィールドバスプロトコル
はプロセス制御機能を実行できる特定の種類のエンティティを説明するのに、「
機能ブロック」という表現を用いるが、ここで用いられる機能ブロックという表
現は限定的ではなく、プロセス制御ネットワーク内の分散した位置でなんらかの
方法でプロセス制御機能を実行することが出来るなんらかの種類の装置、プログ
ラム、ルーチン、または他のエンティティを含む。このように、ここで説明され
クレームされる診断機能ブロックは、ネットワークまたはプロトコルがプロセス
内の分散位置で制御機能を与えるかまたはこれを可能とする限りは、フィールド
バスプロトコルが厳密に「機能ブロック」として特定するものを用いない他のプ
ロセス制御ネットワーク内で、またはこれを用いない他のプロセス制御通信プロ
トコルまたはプロセス制御通信方式（既存のものでも将来において開発されるも
のでも）を用いて実行可能である。

【００８４】 さらに、プロセス診断機能ブロックおよび装置診断機能ブロックはポジショナ
／弁装置に関して診断を行う際に用いられるものとして説明されたが、これらの
機能ブロックは、ダンパ、ファンなどのような移動可能な要素を有するもののよ
うな他の種類の装置に関して（またはこれを用いて）診断を行うのに用いられる
。

【００８５】 さらに、ここで説明される診断機能ブロックは好ましくはプロセス制御内に記
憶されたソフトウェアで実行されるが、代替的にはまたは付加的には所望のごと
くハードウェア、ファームウェアなどで実行可能である。ソフトウェアで実行さ
れる場合は、本発明の診断は、磁気ディスク、レーザーディスク、または他の記
憶媒体上のようなコンピュータ読み取り可能なメモリ内で、コンピュータのＲＡ
ＭまたはＲＯＭ内などで記憶されてよい。同様に、このソフトウェアは、例えば
、電話回線、インターネットなどのような通信チャネルによるものを含め公知の
または所望の送り方法によって、ユーザまたは装置に送られてもよい。

【００８６】 本発明は、具体例を参照して説明されたが、これらは、あくまでも例示的であ
り、本発明を限定するものではないが、本発明の精神および範囲を逸脱すること
なく、開示された実施例に、変更、追加、およびまたは消去を加えてよいことは
当業者には明らかである。

【図面の簡単な説明】

【図１】 フィールドバスプロトコルを用いるプロセス制御ネットワークの例の概略的な
ブロック図である。

【図２】 一組の３つの機能ブロックを有するフィールドバス装置の概略的なブロック図
である。

【図３】 図１のプロセス制御ネットワークの装置内で機能ブロックを示す概略的なブロ
ック図である。

【図４】 図１のプロセス制御ネットワーク内のプロセス制御ループの制御ループを示す
概略図である。

【図５】 図１のプロセス制御ネットワークのバスのセグメントのマクロサイクルのタイ
ミング図である。

【図６】 本発明に従った遠隔装置診断機能ブロックを含む制御ループを示す概略図であ
る。

【図７】 本発明に従った遠隔装置機能ブロックまたはプロセス診断機能ブロックを含む
制御ループを示す概略図である。

【図８】 図７の診断機能ブロックの概略的なブロック図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＨＲ ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ， ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，Ｌ Ｖ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ， ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，Ｕ Ｚ，ＶＮ，ＹＵ，ＺＷ (72)発明者 ブラウン， ラリー ケー. アメリカ合衆国 50158 アイオワ マー シャルタウン イースト サウスリッジ ロード 211 Ｆターム(参考） 5B045 AA05 BB12 BB28 BB49 GG01 JJ02 5B048 AA18 CC05 CC14 CC15 FF01 5H223 AA01 BB02 CC01 CC03 CC08 DD03 DD07 EE30

Claims (28)

【特許請求の範囲】
1. 【請求項１】 複数の装置がバスによって通信可能にリンクされ、該複数の
   装置の各々がプロセス制御機能を実行できるとともにスケジュールされた周期的
   通信を用いてバス上で通信を行うことができるプロセス制御ネットワークで用い
   られる診断システムであって、 複数の装置のうちの第１の装置内に配置され、診断制御信号を生成する信号発
   生器と、 前記信号発生器に結合され、スケジュールされた周期的通信を用いて複数の装
   置のうちの第２の装置の入力に診断制御信号を送るように構成されるコミュニケ
   ータと、 診断信号に応答して、別の装置により生じさせられた出力信号を受信する信号
   受信器と を備えてなる診断システム。
2. 【請求項２】 受信された出力信号を記憶する記憶ユニットをさらに備えて
   なる請求項１に記載の診断システム。
3. 【請求項３】 記憶された出力信号を、該記憶された出力信号を用いて診断
   解析活動を行うことが出来る複数の装置のうちの第３の装置に送る手段をさらに
   備えてなる請求項２に記載の診断システム。
4. 【請求項４】 前記信号受信器は、スケジュールされた周期的通信を用いて
   出力信号を受信する手段を備えてなる請求項１に記載の診断システム。
5. 【請求項５】 診断制御信号はディジタル信号であり、前記信号発生器は、
   ディジタル診断制御信号を記憶するメモリを備えてなる請求項１に記載の診断シ
   ステム。
6. 【請求項６】 複数の装置のうちの第３の装置により生じさせられたプロセ
   ス制御信号を受信するよう結合されるように適合される制御信号入力をさらに備
   えており、前記コミュニケータは、前記制御信号入力と前記信号発生器とに結合
   されてプロセス制御信号および診断制御信号のうちの一方を第２の装置に送るス
   イッチを備えてなる請求項１に記載の診断システム。
7. 【請求項７】 前記第２の装置は前記第３の装置と同じ装置である請求項６
   に記載の診断システム。
8. 【請求項８】 受信された出力信号を前記第３の装置に送るフィードバック
   ユニットをさらに備えてなる請求項６に記載の診断システム。
9. 【請求項９】 前記フィードバックユニットは、スケジュールされた周期的
   通信を用いて、受信された出力信号を前記第３の装置に送る手段を備えてなる請
   求項８に記載の診断システム。
10. 【請求項１０】 前記第３のプロセス制御装置により実行されるプロセス制
    御機能は異なるモードで動作することができ、前記第３の装置内でプロセス制御
    機能のモードを制御するモード処理ユニットをさらに備えてなる請求項８に記載
    の診断システム。
11. 【請求項１１】 ひとつ以上のプロセス信号を受信するように適合されるプ
    ロセス信号受信器と、ひとつ以上プロセス信号を記憶する記憶ユニットとをさら
    に備えてなる請求項６に記載の診断システム。
12. 【請求項１２】 記憶されたプロセス信号を、プロセス信号を用いて診断解
    析活動を行うことが出来る第４の装置に送る手段をさらに備えてなる請求項１１
    に記載の診断システム。
13. 【請求項１３】 前記べつの装置は第２の装置である請求項１に記載の診断
    システム。
14. 【請求項１４】 プロセス制御装置内で実行される診断機能ブロックであり
    、複数の装置がバスに通信可能に結合され、該複数の装置の各々は、前記プロセ
    ス制御ネットワーク内で入力機能、出力機能、または制御機能を実行することが
    できるとともにスケジュールされた周期的通信を用いてバス上で通信をおこなう
    ことができるひとつ以上の機能ブロックを含むプロセス制御ネットワークにおい
    て用いられる診断機能ブロックであって、 診断制御信号を生成する信号発生器と、、 スケジュールされた周期的通信を用いてプロセス制御ネットワーク内の第２の
    機能ブロックに診断制御信号を送るように構成されるコミュニケータと、 診断制御信号に応答して、別の機能ブロックにより生じさせられた出力信号を
    受信する信号受信器と を備えてなる診断機能ブロック。
15. 【請求項１５】 受信された出力信号を記憶する記憶ユニットをさらに備え
    てなる請求項１４に記載の診断機能ブロック。
16. 【請求項１６】 診断制御信号はディジタル信号であり、前記信号発生器は
    、ディジタル診断制御信号を記憶するメモリを備えてなる請求項１４に記載の診
    断機能ブロック。
17. 【請求項１７】 スケジュールされた周期的通信を用いて、第３の機能ブロ
    ックの出力に結合されるように適合される制御信号入力と、前記制御信号入力と
    前記信号発生器とに結合され、第３の機能ブロックの出力および診断制御信号の
    うちの一方を第２の機能ブロックに選択的に与えるスイッチとをさらにを備えて
    なる請求項１４に記載の診断機能ブロック。
18. 【請求項１８】 受信された出力信号を第３の機能ブロックに送るフィード
    バックネットワークをさらに備えてなる請求項１７に記載の診断機能ブロック。
19. 【請求項１９】 前記第３の機能ブロックは異なるモードで動作することが
    可能であり、前記スイッチが診断制御信号を前記第２の機能ブロックに送る場合
    に、前記第３の機能ブロックのモードを制御するモード処理ユニットをさらに備
    えてなる請求項１８に記載の診断機能ブロック。
20. 【請求項２０】 前記プロセス制御ネットワーク内で他の機能ブロックから
    ひとつ以上のプロセス信号を受信するように適合されるプロセス信号受信器と、
    ひとつ以上のプロセス信号を記憶する記憶ユニットとをさらに備えてなる請求項
    １７に記載の診断機能ブロック。
21. 【請求項２１】 複数の装置がバスによって通信可能にリンクされ、該複数
    の装置の各々が、前記プロセス制御ネットワーク内でプロセス制御機能を実行す
    るとともにスケジュールされた周期的通信を用いてバス上で通信を行うことがで
    きるひとつ以上の機能ブロックを含むプロセス制御ネットワークで診断を行う方
    法であって、 診断制御信号を生成する信号発生器を有する診断機能ブロックを含む第１の装
    置を前記プロセス制御ネットワークのバスに接続するステップと、 スケジュールされた周期的通信を用いて、診断機能ブロックの出力を第２の装
    置内の第２の機能ブロックに通信可能にリンクするステップと、 診断機能ブロックの入力をべつの機能ブロックの出力に通信可能にリンクして
    、診断制御信号に応答して、べつの機能ブロックにより生じさせられた出力信号
    を受信するステップと、 スケジュールされた周期的通信を用いて診断制御信号を前記第２の機能ブロッ
    クに送り、それにより診断制御信号に従って前記第２の機能ブロックの動作を制
    御するステップと を含むプロセス制御ネットワーク内で診断を行う方法。
22. 【請求項２２】 受信された出力信号を診断機能ブロック内に記憶するステ
    ップをさらに含む請求項２１に記載のプロセス制御ネットワーク内で診断を行う
    方法。
23. 【請求項２３】 第３の機能ブロックの出力を診断機能ブロックのプロセス
    制御信号入力に通信可能にリンクするステップと、診断機能ブロックが前記第３
    の機能ブロックの出力を前記第２の機能ブロックに送る第１の動作状態と、診断
    機能ブロックが診断制御信号を前記第２の機能ブロックに送る第２の動作状態と
    の間で切り替えさせるように診断機能ブロックを動作させるステップとをさらに
    含む請求項２１に記載のプロセス制御ネットワーク内で診断を行う方法。
24. 【請求項２４】 診断機能ブロックのフィードバック出力を第３の機能ブロ
    ックのフィードバック入力に通信可能にリンクして、別の機能ブロックから受信
    された出力信号を前記第３の機能ブロックに伝えるステップをさらに含む請求項
    ２３に記載のプロセス制御ネットワーク内で診断を行う方法。
25. 【請求項２５】 診断機能ブロックが診断制御信号を前記第２の機能ブロッ
    クに送るときに、診断機能ブロックに前記第３のブロックの動作のモードを制御
    させるステップをさらに含む請求項２４に記載のプロセス制御ネットワーク内で
    診断を行う方法。
26. 【請求項２６】 診断機能ブロックのひとつ以上の信号入力をひとつ以上の
    他の機能ブロックに通信可能にリンクして、ひとつ以上の他の機能ブロックによ
    り生じさせられたひとつ以上のプロセスパラメータ信号を受信するステップと、
    受信されたひとつ以上のプロセス信号を診断機能ブロック内に記憶するステップ
    とをさらに含む請求項２４に記載のプロセス制御ネットワーク内で診断を行う方
    法。
27. 【請求項２７】 診断機能ブロック内に記憶されたひとつ以上のプロセス信
    号を検索するステップと、検索されたひとつ以上のプロセス信号を用いてプロセ
    ス診断を行うステップとを含む請求項２６に記載のプロセス制御ネットワーク内
    で診断を行う方法。
28. 【請求項２８】 診断機能ブロック内に出力信号を記憶するステップと、診
    断機能ブロック内に記憶された出力信号を検索するステップと、検索された出力
    信号を用いて装置診断を行うステップとを含む請求項２１に記載のプロセス制御
    ネットワーク内で診断を行う方法。