(57)【特許請求の範囲】
【請求項１】
バスを介して通信可能にリンクされた複数の装置を有するプロセス制御ネットワークで用いられる診断システムであって、前記複数の装置の各々が、プロセス制御機能を実行できるとともにスケジュールされた周期的通信を用いて前記バス上で通信を行うことができ、これにより前記プロセス制御ネットワークの通常の動作中にプロセス制御を実行し、
前記複数の装置のうちの第１の装置内に配置されると共に診断信号を生成する診断信号発生器と、
前記診断信号発生器に結合され、前記バスがプロセス制御に用いられていない間に前記複数の装置のうちの第２の装置の入力に前記バスを通じて前記診断信号を送るため、前記スケジュールされた周期的通信を用いるように構成されるコミュニケータであって、前記プロセス制御ネットワークの通常の動作中に前記複数の装置のうちの一つに含まれる信号源からプロセス制御信号を前記第２の装置に受信させるように構成されているコミュニケータと、
前記コミュニケータによって前記第２の装置に送られる前記診断信号に応答して前記第２の装置が生成した出力信号を受信する信号受信器と
を備えてなる診断システム。
【請求項２】
受信された前記出力信号を記憶する記憶ユニットをさらに備えてなる請求項１に記載の診断システム。
【請求項３】
記憶された前記出力信号を、該記憶された出力信号を用いて診断解析活動を行うことが出来る複数の装置のうちの第３の装置に送る手段をさらに備えてなる請求項２に記載の診断システム。
【請求項４】
前記信号受信器は、前記スケジュールされた周期的通信を用いて前記出力信号を受信する手段を備えてなる請求項１に記載の診断システム。
【請求項５】
前記診断信号はディジタル信号であり、前記信号発生器は、前記ディジタル信号を記憶するメモリを備えてなる請求項１に記載の診断システム。
【請求項６】
前記信号源が生成した前記プロセス制御信号を受信するよう結合されるように適合される制御信号入力と、前記制御信号入力と前記診断信号発生器とに結合されて前記プロセス制御信号および前記診断信号のうちの一方を前記第２の装置に送るスイッチとをさらに備えてなる請求項１に記載の診断システム。
【請求項７】
前記第２の装置が前記信号源を含んでいる請求項６に記載の診断システム。
【請求項８】
受信された前記出力信号を前記信号源に送るフィードバックユニットをさらに備えてなる請求項６に記載の診断システム。
【請求項９】
前記フィードバックユニットは、前記スケジュールされた周期的通信を用いて、受信された前記出力信号を前記信号源に送る手段を備えてなる請求項８に記載の診断システム。
【請求項１０】
前記第２の装置が、ひとつ以上の前記プロセス制御信号を受信するように適合されるプロセス信号受信器と、ひとつ以上の前記プロセス制御信号を記憶する記憶ユニットとを有してなる請求項６に記載の診断システム。
【請求項１１】
記憶された前記プロセス制御信号を、該プロセス制御信号を用いて診断解析活動を行うことが出来るさらなる装置に送る手段をさらに備えてなる請求項１０に記載の診断システム。
【請求項１２】
プロセス制御装置内で診断を実行し、バスに通信可能に結合された複数の装置を有するプロセス制御ネットワーク内で用いられる診断機能ブロックであって、
該複数の装置の各々は、前記プロセス制御ネットワーク内で入力機能、出力機能、または制御機能を実行することができ、これにより前記プロセス制御ネットワークの通常の動作中にプロセス制御を実行するひとつ以上の機能ブロックを含んでおり、
診断信号を生成する診断信号発生器と、
前記バスがプロセス制御のために用いられていない間に前記プロセス制御ネットワーク内の第２の機能ブロックに前記バスを通じて前記診断信号を送るため、スケジュールされた周期的通信を用いるように構成されるコミュニケータであって、前記プロセス制御ネットワークの通常の動作中に第３の機能ブロックからプロセス制御信号を前記第２の機能ブロックに受信させるように構成されているコミュニケータと、
前記コミュニケータによって前記第２の機能ブロックに送られる前記診断信号に応答して前記第２の機能ブロックが生成した出力信号を受信する信号受信器と
を備えてなる診断機能ブロック。
【請求項１３】
受信された前記出力信号を記憶する記憶ユニットをさらに備えてなる請求項１２に記載の診断機能ブロック。
【請求項１４】
前記診断信号はディジタル信号であり、前記診断信号発生器は、前記ディジタル信号を記憶するメモリを備えてなる請求項１２に記載の診断機能ブロック。
【請求項１５】
前記スケジュールされた周期的通信を用いて、前記第３の機能ブロックの出力に結合されるように適合される制御信号入力と、前記制御信号入力と前記信号発生器とに結合され、前記第３の機能ブロックから出力される前記プロセス制御信号および前記診断信号のうちの一方を前記第２の機能ブロックに選択的に与えるスイッチとをさらに備えてなる請求項１２に記載の診断機能ブロック。
【請求項１６】
受信された前記出力信号を前記第３の機能ブロックに送るフィードバックネットワークをさらに備えてなる請求項１５に記載の診断機能ブロック。
【請求項１７】
前記プロセス制御ネットワーク内で他の機能ブロックからひとつ以上のプロセス制御信号を受信するように適合されるプロセス制御信号受信器と、ひとつ以上のプロセス制御信号を記憶する記憶ユニットとをさらに備えてなる請求項１５に記載の診断機能ブロック。
【請求項１８】
バス上に通信可能にリンクされた複数の装置を有するプロセス制御ネットワーク内で診断を行う方法であって、該複数の装置の各々は、前記プロセス制御ネットワーク内でプロセス制御機能を実行するとともにスケジュールされた周期的通信を用いて前記バス上で通信を行うことができ、これにより前記プロセス制御ネットワークの通常の動作中にプロセス制御を実行するひとつ以上の機能ブロックを含んでおり、診断信号を生成する診断信号発生器を有する診断機能ブロックを含んだ第１の装置が前記バスに接続されており、
前記バスが前記プロセス制御に用いられていない間において前記スケジュールされた周期的通信を用いて、前記診断機能ブロックの出力を第２の装置内の第２の機能ブロックに前記バス上で通信可能にリンクするステップであって、前記第２の機能ブロックは、前記プロセス制御ネットワークの通常の動作中に第３の機能ブロックからプロセス制御信号を受信するステップと、
前記診断機能ブロックの入力を前記第２の装置内の前記第２の機能ブロックの出力に通信可能にリンクして、前記診断信号に応答して該機能ブロックが生成した出力信号を受信するステップと、
前記スケジュールされた周期的通信を用いて前記診断信号を前記第２の機能ブロックに送り、それにより前記診断信号に従って前記第２の機能ブロックの動作を制御するステップと
を含むプロセス制御ネットワーク内で診断を行う方法。
【請求項１９】
受信された前記出力信号を前記診断機能ブロック内に記憶するステップをさらに含む請求項１８に記載のプロセス制御ネットワーク内で診断を行う方法。
【請求項２０】
前記第３の機能ブロックの出力を前記診断機能ブロックの前記プロセス制御信号入力に通信可能にリンクするステップと、
前記診断機能ブロックが前記第３の機能ブロックが出力する前記プロセス制御信号を前記第２の機能ブロックに送る第１の動作状態と、前記診断機能ブロックが前記診断信号を前記第２の機能ブロックに送る第２の動作状態との間で切り替えさせるように前記診断機能ブロックを動作させるステップとをさらに含む請求項１８に記載のプロセス制御ネットワーク内で診断を行う方法。
【請求項２１】
前記診断機能ブロックのフィードバック出力を前記第３の機能ブロックのフィードバック入力に通信可能にリンクして、前記第２の装置内の前記第２の機能ブロックから受信された前記出力信号を前記第３の機能ブロックに伝えるステップをさらに含む請求項２０に記載のプロセス制御ネットワーク内で診断を行う方法。
【請求項２２】
前記診断機能ブロックのひとつ以上の信号入力をひとつ以上の他の機能ブロックに通信可能にリンクして、該ひとつ以上の他の機能ブロックが生成したひとつ以上のプロセスパラメータ信号を受信するステップと、
受信された前記ひとつ以上のプロセスパラメータ信号を前記診断機能ブロック内に記憶するステップとをさらに含む請求項２１に記載のプロセス制御ネットワーク内で診断を行う方法。
【請求項２３】
前記診断機能ブロック内に記憶された前記ひとつ以上のプロセスパラメータ信号を用いてプロセス診断を行うステップを含む請求項２２に記載のプロセス制御ネットワーク内で診断を行う方法。
【請求項２４】
前記診断機能ブロック内に前記出力信号を記憶するステップと、
前記診断機能ブロック内に記憶された前記出力信号を用いてプロセス診断を行うステップとを含む請求項１８に記載のプロセス制御ネットワーク内で診断を行う方法。
【発明の詳細な説明】
発明の分野
本発明は一般にプロセス制御ネットワークに関し、より特定的には、分散制御機能を有するプロセス制御ネットワーク内で遠隔装置診断およびプロセス診断を行なう方法および装置に関する。
【０００１】
関連技術の説明
化学プロセス、石油プロセス、ならびに他の製造プロセスおよび精製プロセスのような大規模プロセスは、様々な位置に配置されプロセスのパラメータを測定するとともに制御して、それによりプロセスの制御を実行する多数のフィールド装置を含む。これらのフィールド装置は、例えば、弁およびスイッチのような制御要素だけでなく、温度センサ、圧力センサ、および流量センサであってよい。昔から、プロセス制御産業は、手動でレベルゲージおよび圧力ゲージを読取ったり、弁のハンドルを回転させたりするなどのような手動操作を用いて、プロセス内で測定および制御フィールド装置を動作させていた。２０世紀になり、プロセス制御産業は局所空圧制御を用い始めたが、この場合、局所空圧制御器、送信器、および弁ポジショナがプロセスプラント内で様々な位置に配置され、プラントのその位置の制御を実行していた。１９７０年代のマイクロプロセッサベースの分散制御システム（ＤＣＳ）の出現で、分散電子プロセス制御がプロセス制御産業において流行した。
【０００２】
公知であるように、ＤＣＳは、プロセス中に位置した電子センサ、送信器、電流対圧力トランスデューサ、弁ポジショナのような多数の電子監視装置および制御装置に接続されたプログラマブル論理制御器のような、アナログまたはディジタルコンピュータを含む。ＤＣＳコンピュータは、集中型、そしてしばしば複雑な制御方式を記憶し、実行して、プロセス内で装置の測定値を測定することおよびその制御を行ない、それにより全体の制御方式に従ってプロセスパラメータを制御する。しかしながら、通常は、ＤＣＳにより実行される制御方式は、ＤＣＳ制御器製造業者に所有権があるので、ＤＣＳを拡張、更新、再プログラム、および使用するのに困難かつ高価なものにしている。なぜならば、これらの活動を実行する際にＤＣＳプロバイダが関わることは不可欠であるからだ。さらに、特定のＤＣＳにより用いられるかまたはこのＤＣＳ内で接続される機器は、ＤＣＳ制御器の所有権の性質と、ＤＣＳ制御器プロバイダがある装置または他の小売業者により製造される装置の機能を支援してはいけないという事実とによって制限されるかもしれない。
【０００３】
所有権を主張できるＤＣＳの使用に固有の問題の幾つかを克服するために、プロセス制御産業は、例えば、ＨＡＲＴ（登録商標）、ＰＲＯＶＩＢＵＳ（登録商標）、ＷＯＲＬＤＦＩＰ（登録商標）、Ｄｅｖｉｃｅ−Ｎｅｔ（登録商標）、およびＣＡＮプロトコルを含む、多くの標準的な、開放的通信プロトコルを発展させて来たが、これにより、異なる製造業者により製造されたフィールド装置を同じプロセス制御内で一緒に用いることが可能となる。事実、フィールド装置がＤＣＳ制御器の製造業者とは異なる製造業者により製造されているとしても、これらのプロトコルのひとつに従うフィールド装置であれば、ＤＣＳ制御器と通信するとともにＤＣＳ制御器により制御されるようにプロセス内で用いることができる。
【０００４】
さらに、現在、プロセス制御を非集中化（分散）するために、そしてそれによりＤＣＳ制御器を簡単化するかまたはＤＣＳ制御器をほとんど必要としなくなるように、プロセス制御産業内で動きがある。非集中制御は、弁ポジショナ、送信器などのようなフィールド装着プロセス制御装置にひとつ以上の制御機能を実行させること、および他の制御機能を実行する際に他のプロセス制御装置により用いられるバス構造によってデータ通信を行うことにより得られる。これらの制御機能を実行するには、各プロセス制御装置は、標準のかつ開放的な通信プロトコルを用いて、制御機能を実行する能力（ケイパビリティ）と他のプロセス制御装置と通信する能力とを有するマイクロプロセッサを含む。このようにして、様々な製造業者により製造されたフィールド装置はプロセス制御ネットワーク内で相互接続され、互いに通信し、ＤＣＳ制御器の介入なしに、制御ループを形成するひとつ以上の機能を実行する。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、およびＰＩＤLOOP3(異なるブロックの各々に対し異なる）の実行時間を示し、一方、垂直バー８２、８４、８６、８９は、それぞれＰＩＤLOOP1、ＡＩLOOP2、ＡＯLOOP1、ＳＳLOOP2、およびＰＩＤLOOP3がバスセグメント３４ｂ上にデータを発する時間を示す。
【００５３】
明らかに、図５のタイミング図は、非同期通信活動に利用される時間も示しているが、この非同期通信活動は、機能ブロックのいずれかの実行時間の間と、機能ブロックが実行されていない間のマクロサイクルの終わりの時間の間と、同期通信がバスセグメント３４ｂ上で行われていない時に、おこなわれてよい。当然、所望であれば、異なる機能ブロックが、同じ時間で実行されるように意図的にスケジュールされることも可能であり、もし、例えば、ある機能ブロックにより生成されたデータに他の装置が加入して（ subscribe）いないならば、機能ブロックすべてがバス上でデータを発する必要があるわけではない。
【００５４】
フィールド装置は、各フィールド装置のスタックのフィールドバスアクセスサブレイヤにおいて規定された３つの仮想通信関係（ＶＣＲ）のひとつを用いてバス３４によってデータおよびメッセージを発するかまたはこれを送信することが出来る。クランアイント／サーバＶＣＲは、バス３４上の装置間でキューに入れられた、未スケジュールの、ユーザ起動の、１対１通信のために用いられる。このようなキューに入れられたメッセージは、前のメッセージに上書きすることなくそれらの優先順位に従って、送信用に提示された順序で送られ、受信される。このように、フィールド装置は、それがＬＡＳからパストークンメッセージを受け取って要求メッセージをバス３４上の別の装置送るときに、クライアント／サーバＶＣＲを用いてよい。要求者は「クライアント」と呼ばれ、要求を受け取る装置は「サーバ」と呼ばれる。サーバは、それがＬＡＳからパストークンメッセージを受け取るときに、応答を送る。クライアント／サーバＶＣＲは、設定点変化、チューニングアクセスおよび変化、警報肯定応答、および装置アップロードおよびダウンロードのような操作員起動の要求を実行するために用いられる。
【００５５】
報告配布（ report distribution）ＶＣＲは、キューに入れられた、未スケジュールの、ユーザ起動の１対多の通信のために用いられる。例えば、事象またはトレンド報告を有するフィールド装置はＬＡＳからパストークンを受け取り、そのフィールド装置は、その装置の通信スタックのフィールドバスアクセスサブレイヤにおいて規定された「グループアドレス」にそのメッセージを送る。そのＶＣＲを聴くように構成される装置は報告を受け取るであろう。報告配布ＶＣＲタイプは典型的には、通知または操作員コンソールに警報を通知を送るのにフィールドバス装置により用いられる。
【００５６】
発行者／加入者(publisher／ subscriber)ＶＣＲタイプは、バッファされた１対多通信のために用いられる。バッファされた通信は、データの最新のバージョンだけを記憶し、送り、従って、新たなデータが完全に前のデータに上書きされる。機能ブロック出力は、例えば、バッファされたデータを含む。「発行者」フィールド装置は、発行者装置がＬＡＳからまたは加入者装置からコンペルデータメッセージを受けとると、バス３４上の全ての「加入者」フィールド装置に発行者／加入者ＶＣＲタイプを用いてメッセージを発するかまたはブロードキャストする。発行者／加入者関係は予め定められており、各フィールド装置の通信スタックのフィールドバスアクセスサブレイヤ内に規定され記憶される。
【００５７】
確実にバス３４上で正しい通信活動を行うには、各ＬＡＳは、バス３４のセグメントに接続されたフィールド装置全てに時間配布メッセージを周期的に送り、これにより、受信装置は、その局所的アプリケーション時間を互いに同期するように調節することが可能となる。これらの同期メッセージ間で、クロック時間は、それ自身の内部クロックに基づいて各装置内で独立して維持される。例えば、いつデータが生成されたかを示すために、クロックの同期により、フィールド装置がフィールドネットワーク中のデータにタイムスタンプを押すことが可能となる。
【００５８】
さらに、各バスセグメント上の各ＬＡＳ（および他のリンクマスタ装置）は、「生（live）リスト」を記憶するが、これは、バス３４のそのセグメントに接続された装置全てのリストであり、即ち、パストークンメッセージに正しく応答する装置全てである。ＬＡＳは継続的に、生リストに載っていないアドレスにプローブノードメッセージを周期的に送ることにより、バスセグメントに付加された新たな装置を認識する。事実、各ＬＡＳは、生リスト内のフィールド装置全てにパストークンメッセージを送るサイクルを終了した後に、少なくともひとつのアドレスを探査する必要がある。フィールド装置が、探査されたアドレスに存在し、プローブノードメッセージを受け取るならば、装置はすぐにプローブ応答メッセージを戻す。プローブ応答メッセージを受け取ると、ＬＡＳは、その装置を生リストに付加し、探査されたフィールド装置にノード活性化メッセージを送ることで確認を取る。フィールド装置は、そのフィールド装置はパストークンメッセージに正しく応答する限りは、生リスト上にあるままである。しかしながら、フィールド装置が３回連続して試みた後で、トークンを用いないかまたはすぐにトークンをＬＡＳに戻してしまう場合は、ＬＡＳは、そのフィールド装置を生リストから除く。フィールド装置が生リストに付加されるかまたは生リストから除かれるとき、ＬＡＳは、バス３４の適切なセグメント上の全ての他のリンクマスタ装置にブロードキャストし、これにより、各リンクマスタ装置は、生リストの現在のコピーを維持する。
【００５９】
上で述べたように、フィールド装置とその機能ブロックとの間の通信相互接続はユーザにより決定され、例えば、ホスト１２内に位置した構成アプリケーションを用いて、プロセス制御ネットワーク１０内で実行される。しかしながら、構成された後、プロセスセネットワーク１０は、装置診断またはプロセス診断を考慮することなく動作し、従って、ホスト１２とインターフェースして標準的なＩ／Ｏ機能を実行するが、診断機能を実行しない。
【００６０】
ユーザが診断を行いたいとき、ユーザは、ホスト１２に、例えば、制御ループ１のＡＯ機能ブロック６３に設定点変化を送らせ、ＡＯ機能ブロック６３と関連するトレンドオブジェクトを用いてＡＯ機能ブロック６３内にフィードバックを記録させる。しかしながら、この種類の通信を行うには、ホスト１２は非同期通信を用いなければならないが、この非同期通信により、ホスト１２がＬＡＳからパストークンメッセージを受け取って始めて、ホスト１２がバス３４にアクセスすることが可能となる。その結果、ホスト１２により生成された診断信号の異なる部分は、正確に決定された時間（または正確にスケジュールされた時間）にＡＯ機能ブロック６３に到着しないかもしれない。これは、ＡＯ機能ブロック６３で受信された診断信号は、特定の時間にバス３４上の通信バックログ（backlog）により少なくとも部分的に決定される形状を有することを意味する。この理由で、非同期通信を用いて送られる診断信号は、厳密に確定的ではなく、従って、装置またはプロセス上で診断を行う際にあまり効果的ではないかもしれない。さらに、ホスト１２は、トレンドオブジェクトにより集められたフィードバックデータは、オーバーライトなどにより喪失されないということを保証する方法はない。また、ホスト１２は、ブロックのモードを特に変更することなく、ＰＩＤ機能ブロックのようなＬＯＯＰ１内の機能ブロック６４のモードを制御する方法はない。
【００６１】
今まで、プロセス内で確実に完全でかつ厳密に確定的な診断を行うには、同期通信よって、ホスト１２が適切な装置に設定点変化を送り、適切な装置により測定されたデータを受信することが出来るように、ユーザはプロセス制御ネットーク１０をオフラインにして通信インターフェースを再構成しなけらばならなかった。しかしながら、上で述べたように、診断が行われるべきときはいつでも、この手続きはプロセスを遮断し、オペレータにプロセスを再構成するように要求する。これら両方は望ましくはない。さらに、この診断手続きの間にホスト１２により実行される制御は、プロセスの通常動作の間に、通信可能にリンクされた機能ブロックにより実行される制御とは異なり、したがって、プロセスが通常に制御されている間に、集められたプロセスデータはプロセスの動作を示さないかもしれない。その結果、ホスト装置は典型的には、ユーザが通常動作と診断動作との間で切り替えしてそれにより診断を可能化することができる能力を有していない。
【００６２】
例えば、フィールドバスプロセス制御ネットワークにおいてこれらの問題を克服するには、新たな診断ブロックが位置している装置以外の装置に関してまたはこの装置を用いて装置診断および／またはプロセス診断を行うために、本発明に従って新たな種類の機能ブロックが与えられる。本発明の遠隔診断機能ブロックは、同期周期的通信を用いて（例えばフィールドバスプロトコルの発行者／加入者ＶＣＲ）バス３４上で他の装置機能ブロックと通信するように構成され、同期周期的通信を用いて装置パラメータまたは他のプロセスパラメータの測定値のようなデータを受信するように構成される。このように、本発明の遠隔診断機能ブロックは、異なる機能ブロックに確定的な診断制御機能ブロックを送るとともに、周期的に装置またはプロセスパラメータに関するデータを受信し、記憶する。さらに、本発明の遠隔診断機能ブロックは、診断が行われている装置以外の装置内に記憶されてよく、これにより、プロセス制御内ネットワーク内ででどんな数の異なる装置に関してでもまたはこれを用いて、診断機能ブロックを診断を行うのに用いることができる。このように、例えば、本発明に従った遠隔診断機能ブロックは、図３のポジショナ／弁装置１８のポジショナ内に記憶され、ポジショナ／弁１６、１８、２４のいずれかに関して診断を行うのに用いられてよい。同様に、本発明に従った診断機能ブロックは、その機能ブロックをバス３４のセグメント内のいずれかの装置に関して用いることができるようにホスト１２内に記憶可能である。
【００６３】
一般的に言って、本発明の遠隔診断機能ブロックは、装置診断が行われている時間に別の装置（または同じ装置）のある機能ブロックに通信可能にリンクされ、装置診断が行われていない時間にその他の機能ブロックから結合が絶たれる。代替的には、本発明の遠隔診断機能ブロックは、装置診断またはプロセス診断のような診断が行われていないときでさえ制御ループ内の他の機能ブロックに通信可能に結合されたままであるように制御ループ内に配置されてよい。
【００６４】
さて図６を参照して、診断機能ブロック９０の出力がＡＯ機能ブロック６３の入力に接続され、ＡＯ機能ブロック６３の出力が診断機能ブロック９０のフィードバック入力に接続されるように、診断機能ブロック９０は、ポジショナ／弁１６（図３）のＡＯ機能ブロック６３に通信可能にリンクされるかまたは結合されるものとして示される。動作の間に、診断機能ブロック９０は、規則的にスケジュールされた周期的通信（例えば発行者／加入者ＶＣＲを用いて）によりバスセグメント３４ｂ（図３）によってＡＯ機能ブロック６３の設定点の変化を特定する診断制御信号を送り、規則的にスケジュールされた周期的通信によりバスセグメント３４ｂによって弁１６の弁部材の位置を示すＡＯ機能ブロック６３からフィードバック信号を受信する。診断機能ブロック９０は、ＡＯ機能ブロックにより生成された受信されたフィードバック信号を記憶し、全体の診断信号がＡＯ機能ブロック６３にまたは診断の間のひとつ以上の中間的な時間に送られた後に、受信されたフィードバック信号と、そして所望であれば、ＡＯ機能部ブロック６３を制御するのに用いられる診断制御信号の指標を、ホスト１２に処理のために送る。当然、所望であれば、診断機能ブロック９０は、診断制御信号とＡＯ機能ブロックから受信されたフィードバック信号とを用いて装置診断を行うプロセッサまたは他の装置も有することができる。
【００６５】
上で述べたように、図６の診断制御ループにより示される相互装置通信接続は、同期周期的通信を用いて実行され、従って、機能ブロック９０により生成された診断制御信号は、ＡＯ機能ブロック６３の入力で受信された同じ信号であることが保証される。同様に、これらの同期通信により、ＡＯ機能ブロック６３により生じさせられた出力データが確実に周期的に追跡され記録される。
【００６６】
当然、図６の診断制御ループを実現するには、ホスト１２のようなホストは、図６に示される方法で診断機能ブロック９０をＡＯ機能ブロック６３に接続するようにプロセス制御ネットワーク１０を再構成しなければならず、その後、診断機能ブロック９０にＡＯ機能ブロック６３に関して診断テストを実行するように命令しなければならない。診断テストが完了し、機能ブロック９０が、記憶されたデータ全てを処理のためにホスト１２（または他の装置）に送った後、ホスト１２はプロセス制御ネットワーク１０の通常動作の間に用いられる制御方式を再インストールするようにプロセス制御ネットワーク１０を再構成しなければならない。好ましくは、ホスト１２（または他の構成装置）は、図６に示される診断ループが実行されている間は通常のまたは既存の制御方式を記憶する。
【００６７】
図６の診断機能ブロックは、ポジショナ／弁装置１６に関し装置診断を行うように装置１８内に位置するものとして示されるが、この機能ブロックはプロセス制御ネットワーク１０内の他の装置内に位置することもできるし、ポジショナ、ポジショナ／弁装置、ダンパ、ファンなどのような出力装置を含め、プロセス制御ネットワーク１０内の装置に関し診断を行うのに用いられる。
【００６８】
しかしながら、上で述べたように、本発明に従った診断機能ブロックは、プロセス制御ネットワークを再構成することなく、装置診断およびプロセス診断を実行するか行うことができるように、そのプロセス制御ループの動作の間に終始プロセス制御ループ構成内で接続可能である。さて図７を参照して、ＡＩ機能ブロック６６と、ＰＩＤ機能ブロック６４と、ＡＯ機能ブロック６３と、診断機能ブロック９２とを含む制御ループ９１が示される。図７からわかるように、ＡＯ機能ブロック６３とＰＩＤ機能ブロック６４との間の制御ループ９１内に、診断機能ブロック９２が挿入される（通信可能にリンクされる）。
【００６９】
プロセス制御ループ９１の通常動作の間に、ＡＩ機能ブロック６６は、プロセス測定値またはプロセスパラメータをＰＩＤ機能ブロック６４に送り、このＰＩＤ機能ブロック６４は次いで、生じたプロセス制御信号を診断機能ブロック９２に送る。診断機能ブロック９２は、このプロセス制御信号をポジショナ／弁装置１６内のＡＯ機能ブロック６３の入力に送り、例えば、ＡＯ機能ブロック６３から弁位置を示すフィードバック信号を受信する。診断機能ブロック９２はフィードバック信号をＰＩＤ機能ブロック６４の入力に送り、ＰＩＤ機能ブロック６４はこのフィードバック信号を（ＡＩ機能ブロック６６からの入力とともに）用いて、新たなプロセス制御信号を計算する。このように、プロセス制御ループ９１の通常動作の間、診断機能ブロック９２は、ＰＩＤ機能ブロック６４とＡＯ機能ブロック６３との間で信号を通過させるだけで、図４の制御ループ内で接続されたときと本質的に同じ方法でこれらの機能ブロックが動作できるようになる。
【００７０】
しかしながら、ユーザが装置診断またはプロセス診断を実行したいときに、ホスト１２は診断機能ブロック９２に（非同期通信によって）開始信号を送り、これにより、診断機能ブロック９２は、ＰＩＤ機能ブロック６４に生じさせられたプロセス制御信号をＡＯ機能ブロック６３の入力から切断し、診断制御信号をＡＯ機能ブロック６３の入力に送る。当然、診断制御信号は、装置診断またはプロセス診断を実行するように用いられる所望の信号であってよい。同時に、診断機能ブロック９２は、ＡＯ機能ブロック６３から受信したフィードバックデータを記憶し始め、および／または、ＡＩ機能ブロック６６および／または、ブロック９４により図７に示される、プロセス内の他のプロセス測定装置または他の機能ブロックから受け取った他のサンプリングされたプロセス測定値を記憶し始める。当然、ブロック９４およびＡＩ機能ブロック６６からのプロセスパラメータは、診断解析を行う際に用いられるべくホスト１２に最終的に送られるように、トレンドオブジェクトまたは所望の記憶ユニットを用いて診断機能ブロック９２内に記憶されてよい。
【００７１】
装置診断またはプロセス診断の間に、診断機能ブロック９２はフィードバックデータをＰＩＤ機能ブロック６４に送ってよく、所望であれば、診断実行されていることをＰＩＤ機能ブロック６４に示すためにこのフィードバック信号を変更してよい。この方法で、診断機能ブロック９２は、ＰＩＤ機能ブロック６４の場合と同様にワインドアップ（windup）を防ぐのを助ける装置診断またはプロセス診断を行いながら、ＰＩＤ機能ブロック６４の動作（モード）および／または制御ループ９１内で他の機能ブロックの動作（モード）を制御する。
【００７２】
診断機能ブロック９２がＡＯ機能ブロック６３に診断信号を送り終えると、診断機能ブロック９２は、ＰＩＤ機能ブロック６４により生じさせられるプロセス制御信号をＡＯ機能ブロック６３に再び送るように、ＡＯ機能ブロック６３から不変更のフィードバック信号をＰＩＤ機能ブロック６４に与えるように切り替えを行う。さらに、診断の間のひとつ以上の中間的な時間に、または診断が完了した後に、診断機能ブロック９２は、例えば、非同期通信を用いてバス３４によって、ホスト１２（または他の装置）に、集められたフィードバック、プロセスパラメータおよび／または診断制御信号情報を送ってよい。
【００７３】
理解されるように、診断機能ブロック９２は、スケジュールされた周期的通信によってＰＩＤ機能ブロック６４とＡＯ機能ブロック６３とに通信可能にリンクされ、従って、制御ループ９１の動作は制御ループ９１と関連する各マクロサイクルの間にもう少し長く時間をとるようになる。つまり、制御ループ９１の各マクロサイクルは、診断機能ブロック９２に必要な付加的な周期的スケジューリングにより、図４の制御ループのマクロサイクルよりもより多くの時間を同期通信および機能部ブロックの実行にかけなければならない。事実、診断機能ブロック９２を図４の制御ループ内に正しく挿入するには、機能ブロック９２の実行機関は、図５のバー８２の（ＰＩＤ機能ブロック６４と関連するスケジュールされた通信）後に図５のタイミングスケジュール内に挿入されなければならず、診断機能ブロック９２とＡＯ機能ブロック６３との間のスケジュールされた通信（発行（publishing））期間は、機能ブロック９２の挿入された実行期間の後でかつ図５のボックス７８（ＡＯ機能ブロック６３の実行期間）の前で図５のタイミングスケジュール内に挿入されなければならない。同様に、診断機能ブロック９２とＰＩＤ機能部ブロック６４との間のフィードバック通信を実行するためのスケジュールされた実行および通信期間は、図５のバー８６（ＡＯ機能ブロック６３の実行期間）の後で図５のタイミングスケジュール内に挿入されなければならない。当然、ＡＯ機能ブロック６３およびＰＩＤ機能ブロック６４のＶＣＲは、これらの機能ブロックと診断機能ブロック９２との間でスケジュールされた通信を正しく実行するように変更されてよい。
【００７４】
プロセス制御ネットワーク１０の通常動作の間に（即ち診断が行われていないとき）診断機能ブロック９２は制御ループ９１内にとどまっているが、所望であれば、診断機能ブロック９２は、診断が行われていないときにプロセス制御ネットワーク１０の制御ループができるだけ早く実行されるように構成されるように診断が行われる時間のみ、制御ループ９１のような制御ループのスケジュール内に挿入可能である。しかしながら、この動作は、プロセス診断が実行されようとするときはいつでも、新たなプロセス制御構成がネットワーク内にダウンロードされることを必要とする。
【００７５】
図８により詳細に示される診断機能ブロック９２は、ホスト１２からの開始信号および停止信号を受信して復合化し、集められたデータを解析のためにホスト１２に送り、診断機能ブロック９２の残りの動作を制御する診断エンジン９５を含む。診断エンジン９５が開始信号を受信して復号化するとき、診断エンジン９５は、診断信号発生器９６に、記憶された診断制御信号をスイッチ９７に送らせる。同時に、診断信号発生器９６により与えられた診断制御信号が機能ブロック９２の制御信号出力に与えられ、これが例えばＡＯ機能ブロック６３の入力に送られるように、診断エンジン９５は、信号コミュニケータを有するスイッチ９７に、その出力を診断信号発生器９６に接続させる。制御信号出力を診断信号発生器９６に接続されように指示される前に、スイッチ９７は、プロセス制御信号入力（例えばＰＩＤ機能ブロック６４からプロセス制御信号を受信するように接続される）を制御信号出力に結合する。当然、スイッチ９７は典型的には、ソフトウェアで実行され、従って、診断制御信号が診断機能ブロック９２の制御信号出力に送られるのかまたはプロセス制御信号（制御信号入力で）がそこに送られるのかを制御するように設計された切り替え論理を有していてよい。
【００７６】
装置診断またはプロセス診断を行うように動作しているとき、診断エンジン９５によって、データキャプチャユニット９８は、プロセス制御ネットワーク１０内の他の機能ブロックにより集められ、スケジュールされた周期的通信を用いて診断機能ブロック９２に送られるプロセス測定値信号またはプロセスパラメータ信号を集め記憶できるようになる。理解されるように、行われている診断の種類に依って、どんな数のプロセスパラメータでもデータキャプチャユニット９８に送られてよい。
【００７７】
フィードバックユニット９９は、ＡＯ機能ブロック６３（または診断機能ブロック９２により制御されている他の機能ブロック）により生じさせられたフィードバック信号を受信し、診断エンジン９５によりそうするように指示されたら、これらの信号をメモリ内に記憶する。同様に、フィードバックユニット９９は、受信されたフィードバック信号をＰＩＤ機能ブロック６４（またはＡＯ機能ブロック６３を制御するのに用いられるプロセス制御信号を生成するブロックのような他の機能ブロック）に送ってよい。
【００７８】
典型的には、フィールドバス環境においては、フィードバックユニット９９により受信された信号は値および状態を含み、状態は、受信されたフィードバック信号と関連する制御ループ９１のさまざまな状態を示す。所望であれば、フィードバックユニット９９は、ＡＯ機能ブロック６３から受信された信号の状態を、例えば、制御ループ９１の通常動作を示す「良好・カスケード・不特定（good - cascade - nonspecific）」状態から、局所オーバーライドが行われたとと示す「良好・カスケード・オーバーライド（ good-cascade-override）」状態に変更してよく、したがって、信号は、制御ループ９１の通常動作に従って生成されていない。変更された状態のフィードバック信号が、例えば、ＰＩＤ機能ブロック６４に送られると、ＰＩＤ機能ブロック６４は、その信号の状態を復合化し、ＰＩＤ機能ブロック６４の出力がもはやＡＯ機能ブロック６３を制御するために用いられないことを認識する。ＰＩＤ機能ブロック６４は、その後、例えば手動モードにモードを換えるか変更し、この手動モードでは、ＰＩＤ機能ブロック６４はその出力をロックし、ＡＯフィードバック信号とＡＩ機能ブロック６６の出力とから新たなプロセス制御信号を計算するのを停止する。このモード変更プロセスは、ＰＩＤ機能ブロック６４が暴走（ runaway）状態に入らないようにするものである。この暴走状態においては、ＰＩＤ機能ブロック６４より生成された制御信号はすぐに極端な状態になってしまう。なぜならＰＩＤ機能ブロック６４がフィードバック信号を制御された値に効果もないのに強制しようとするからである。理解されるように、ＰＩＤ機能ブロック６４のモード変更により、制御ループ９１またはプロセス制御ネットワーク１０内の他の機能ブロックもモードを変更するようになる。当然、診断が完了し、ＰＩＤ機能ブロック６４がＡＯ機能ブロック６３を制御できるように制御ループ９１が動作しているときは、フィードバックユニット９９は、フィードバック信号の状態を変更することなく、この信号を通過させる。
【００７９】
正しいモード処理を実行するには、モード処理ユニット１００は、フィードバック信号または他の制御された信号に加えられた正しい状態変更に関する論理およびデータを記憶して他の機能ブロックの所望のモード変更を実行し、この情報を診断エンジン９５に伝達する。
【００８０】
当然、診断エンジン９５は、診断テストを実行する際に、診断を開始および停止しても、所望の基準に基づいて診断機能ブロック９２の制御信号出力で生成されるべき多数の異なる診断制御信号のひとつを制御しても、例えば、ＡＯ機能ブロック６３からのフィードバック信号とデータキャプチャユニット９８により集められたプロセスパラメータ信号のうちのひとつ以上を制限要因として用いてもよい。さらに、フィールドバスネットワークにおいては、診断制御信号は好ましくは、ディジタル信号として記憶されるかまたは診断信号発生器９６内に記憶された機能に従って生成される。しかしながら、診断制御信号は、所望の方法で診断機能ブロック９２内に記憶されても生成されてもよい。
【００８１】
理解されるように、ここで述べられた診断機能ブロック９０、９２により、診断手続きの間に確実に確定的信号が装置に送られるように同期的スケジュールされた通信を用いて装置診断および／またはプロセス診断を実行することができる。同様に、ここで述べられた診断機能ブロック９２により、プロセスの通常動作の間に実行されるものと同じプロセス制御構成を用いて、装置診断およびプロセス診断が実行可能となり、これにより、ユーザはあまりプロセス制御ネットワークを再スケジュールするかまたは再構成する必要はなく装置診断またはプロセス診断を行うことができ、診断の間に正確にプロセスの測定値を測定することができる。
【００８２】
診断機能ブロック９０および／または９２は、下流側のＡＯ機能ブロック６３（出力機能ブロック）に関してまたはこれを用いて診断を行うとともに、単純な制御ループ構成で接続された上流側のＰＩＤ機能ブロック６４（制御機能ブロック）から入力を受け取りフィードバックをそこに与えるものとして説明されたが、本発明も診断機能ブロックまたは他の診断機能ルーチンは、所望のごとく他の出力機能または機能ブロックおよび他の制御機能または機能ブロックと関連して用いられ、図７に示されるもの以外の構成を有する制御ループにおいて実行される。このように、例えば、診断機能ブロック９２は、ある機能ブロックを制御し、ことなる機能ブロックからフィードバック信号を受信し、さらなる機能ブロックからプロセス制御信号を受信するように構成される。
【００８３】
さらに、ここで述べられた診断機能ブロックはフィールドバス「機能ブロック」の形で実行されたが、本発明の診断は、他の種類の制御システムおよび／または通信プロトコルと関連する他の種類のブロック、プログラム、ハードウェア、ファームウェアなどを用いて実行可能である。事実、フィールドバスプロトコルはプロセス制御機能を実行できる特定の種類のエンティティを説明するのに、「機能ブロック」という表現を用いるが、ここで用いられる機能ブロックという表現は限定的ではなく、プロセス制御ネットワーク内の分散した位置でなんらかの方法でプロセス制御機能を実行することが出来るなんらかの種類の装置、プログラム、ルーチン、または他のエンティティを含む。このように、ここで説明されクレームされる診断機能ブロックは、ネットワークまたはプロトコルがプロセス内の分散位置で制御機能を与えるかまたはこれを可能とする限りは、フィールドバスプロトコルが厳密に「機能ブロック」として特定するものを用いない他のプロセス制御ネットワーク内で、またはこれを用いない他のプロセス制御通信プロトコルまたはプロセス制御通信方式（既存のものでも将来において開発されるものでも）を用いて実行可能である。
【００８４】
さらに、プロセス診断機能ブロックおよび装置診断機能ブロックはポジショナ／弁装置に関して診断を行う際に用いられるものとして説明されたが、これらの機能ブロックは、ダンパ、ファンなどのような移動可能な要素を有するもののような他の種類の装置に関して（またはこれを用いて）診断を行うのに用いられる。
【００８５】
さらに、ここで説明される診断機能ブロックは好ましくはプロセス制御内に記憶されたソフトウェアで実行されるが、代替的にはまたは付加的には所望のごとくハードウェア、ファームウェアなどで実行可能である。ソフトウェアで実行される場合は、本発明の診断は、磁気ディスク、レーザーディスク、または他の記憶媒体上のようなコンピュータ読み取り可能なメモリ内で、コンピュータのＲＡＭまたはＲＯＭ内などで記憶されてよい。同様に、このソフトウェアは、例えば、電話回線、インターネットなどのような通信チャネルによるものを含め公知のまたは所望の送り方法によって、ユーザまたは装置に送られてもよい。
【００８６】
本発明は、具体例を参照して説明されたが、これらは、あくまでも例示的であり、本発明を限定するものではないが、本発明の精神および範囲を逸脱することなく、開示された実施例に、変更、追加、およびまたは消去を加えてよいことは当業者には明らかである。
【図面の簡単な説明】
【図１】  フィールドバスプロトコルを用いるプロセス制御ネットワークの例の概略的なブロック図である。
【図２】  一組の３つの機能ブロックを有するフィールドバス装置の概略的なブロック図である。
【図３】  図１のプロセス制御ネットワークの装置内で機能ブロックを示す概略的なブロック図である。
【図４】  図１のプロセス制御ネットワーク内のプロセス制御ループの制御ループを示す概略図である。
【図５】  図１のプロセス制御ネットワークのバスのセグメントのマクロサイクルのタイミング図である。
【図６】  本発明に従った遠隔装置診断機能ブロックを含む制御ループを示す概略図である。
【図７】  本発明に従った遠隔装置機能ブロックまたはプロセス診断機能ブロックを含む制御ループを示す概略図である。
【図８】  図７の診断機能ブロックの概略的なブロック図である。
【図１】
0004739515.tif 000002
【図２】
0004739515.tif 000003
【図３】
0004739515.tif 000004
【図４】
0004739515.tif 000005
【図５】
0004739515.tif 000006
【図６】
0004739515.tif 000007
【図７】
0004739515.tif 000008
【図８】
0004739515.tif 000009