JP4390858B2 - 分散型制御機能を有するプロセス制御ネットワークをデバッグし、チューニングする方法および機器 - Google Patents

Description

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

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. トレースチューン機能ブロックが、プロセス制御スキームが表示されたロケーションに到達したときに、バスを介して第１機能ブロックからプロセスデータを通信するための手段を含む、請求項２０に記載のデバイス。

Images