JP2004303247A - プロセス安全システムで使用するための原因結果マトリックスの機能ブロック実装 - Google Patents

Abstract

【課題】プラントの安全システムのテストを容易にする。
【解決手段】プラント安全システムの機能ブロックダイヤグラムプログラミング環境に容易に組み込んで、原因結果ロジックを実装するための原因結果機能ブロックは、原因入力の集合と結果出力の集合とを含んでいる。原因結果機能ブロック内のマルチプレクサは、各原因入力と各結果出力に対して存在する別々の状態マシンに接続する。マルチプレクサは原因入力のそれぞれをデコードし、原因入力及び原因結果マトリックスロジックに基づいて、状態マシンにトリップ信号を提供する。トリップ信号の受け取りに際して、状態マシンは、関連する結果出力をトリップした又は安全な状態に強制する。必要に応じて、状態マシンは、例えばユーザ又はプロセスからの信号のような信号を使用して、トリップした又は安全な状態から正常な状態にプロセスプラントを安全に戻すために使用される異なる状態の集合の間で遷移する。
【選択図】図２

Description

本発明は、概略的にはプロセスプラントに於いて使用される安全システムに関し、より詳細には、プロセスプラント内で使用される安全システムの動作の制御に使用される原因結果マトリックスの機能ブロック実装に関する。

化学、石油等のプロセスで使用されるプロセス制御システムは、少なくとも一つのホスト又はオペレータワークステーション及び一又はそれ以上のフィールドデバイスに、アナログ、デジタル又はアナログ／デジタル複合バス又はラインを介して接続された、一又はそれ以上のプロセスコントローラを典型的に含んでいる。例えば、バルブ、バルブポジショナ、スイッチ及びトランスミッタ（例えば、温度、圧力及び流速センサ）であり得るフィールドデバイスは、バルブの開又は閉やプロセスパラメータの測定のようなプロセス内の機能を実行する。プロセスコントローラは、フィールドデバイス及び／又はそのフィールドデバイスに関連する他の情報によって生成されるプロセス測定値を表す信号を受領し、この情報を、制御ルーチンを実装し次にプロセスのオペレーションを制御するためにバス又はライン上をフィールドデバイスに送信される制御信号を生成するのに使用する。フィールドデバイス及びコントローラからの情報は、オペレータが、プロセスを構成したり、プロセスの現状を見たり、プロセスのオペレーションを修正する等のプロセスに関する何れの所望の機能を実行するのも可能とする等のために、オペレーションワークステーションによって実行される一又はそれ以上のアプリケーションに典型的に利用可能とされ得る。

更に、多くのプロセスでは、毒性の薬物の漏洩、爆発等のプラント内の深刻な災害を生じ又は導くような問題が生じたときに、プロセスプラント内の問題に関連する重大な安全性を検出し、自動的にバルブを閉じ、デバイスから電源を取り去り、プラント内の流れをスイッチする等のために分離した安全性が導入されている。これらの安全システムは、標準のプロセス制御コントローラとは別の、ロジックソルバと呼ばれる一又はそれ以上のコントローラを典型的に有し、これは、プロセス制御プラント内に設けられた別のバス又は通信ラインを介して安全なフィールドデバイスに接続されている。ロジックソルバは、特定の安全スイッチ又は遮断バルブの位置、プロセスに於けるオーバーフロー若しくはアンダーフロー、重要な発電若しくは制御デバイスの動作、顕官検出デバイスの動作などの重要なイベントに関連するプロセス状態を検出するために、安全フィールドデバイスを使用し、これによってプロセスプラント内の「イベント」を検出する。イベント（典型的には「原因」と称される）が検出されると、安全コントローラは、バルブを閉じる、デバイスのスイッチを切る、プラントのセクションの電源を切る等、イベントの有害な性質を制限するための幾つかのアクション（典型的には「結果」と称される）を起こす。一般的には、これらのアクション又は結果は、プロセスプラント内の深刻な又は災害の状態を避けるように設計された安全デバイスをトリップした又は動作の「安全」モードに切り替えることを含んでいる。

過去には、安全システムは、伝統的に原因結果マトリックスと称されるものを使用してプログラムされており、これは、原因（典型的には検出されたプロセス状態）の集合のそれぞれを、一又はそれ以上の達成されるべき結果（例えば、安全デバイスの安全モードへのスイッチング）に関連づける。特に、原因結果マトリックスは、原因のセットのそれぞれがプロセスプラント内に存在するとして検出されたときに現れる一又はそれ以上の結果を特定する。何れかの特定の原因の存在は、一又はそれ以上の結果、即ち、安全システム内の一又はそれ以上の異なる安全デバイスの動作をもたらす。安全システムの動作を明らかにするために、通所、安全技師が原因結果マトリックスを生成し、それは、原因の全てが２次元のマトリックスの一方の側にリストされ（即ち、マトリックスの行に対応する）、そして、結果の全てがマトリックスのもう一方の側にリストされている（即ち、マトリックスの列に対応する）。行と列とによって定義されるマトリックスの要素は、そのマトリックス要素に関連する原因が、そのマトリックス要素に関連する結果の動作を結果としてもたらすべきであるかどうかを特定するのに使用される。一般的には、構成又は安全技師は、（マトリックス要素の行によって特定される）その要素の原因の検出は、（マトリックス要素の列によって特定される）その要素の結果の動作をもたらすことを示すために、マトリックス要素をチェックする。このように、例えば、第２行目と第３列は、第２行に関連する原因の存在がマトリックスの第３列に関連する結果の動作をもたらすべきことを意味している。このように、各結果は、一又はそれ以上の原因の結末として現れるように特定され得る。

一度構成又は安全技師が安全システム又はその一部の適当な原因結果マトリックスを決定すると、安全システムの制御ルーチンが原因結果マトリックスによって定義されるロジックを実装するために生成されなければならない。過去に於いては、構成又は安全技師は、異なるプログラム言語を使用して、原因結果マトリックスを安全システムコントローラに手動で翻訳していたが、このプログラムステップは、不幸にも単調で、時間を要し、誤りを伴い、これは、適切に運転される安全システムの欠陥が深刻な損害又は一部のプラント要員の死にさえ繋がり、プラント内の装置及び材料の何百万ドルにも及ぶ潜在的な破滅に繋がるので、深刻である。

更に近年、原因結果マトリックスを、ラダー・ロジック使用するような高レベル制御プログラムに自動的に翻訳するプログラムが開発されている。役には立つけれども、この自動プログラム生成は、特定の言語で書かれたプログラムを生成し、これは安全システムの制御計画に統合され、テストされデバグされなければならない。このような方法で翻訳された安全ロジックは非常に複雑なプログラムを生じるので、これらのプログラムは、テストしデバグするのにまだ困難で時間を要するものであり、多くの書類を必要としている。更に、制御機能を実装するために機能ブロックプログラム計画を使用する制御ルーチンにこれらのタイプのプログラムを使用することは困難である。

プロセスプラント内の安全システムは、従来の原因結果マトリックスによって特定された原因結果ロジックを実装するために、機能ブロックダイヤグラムプログラミング環境に容易に統合され得る一又はそれ以上の原因結果機能ブロックを使用する。このような原因結果機能ブロックは、容易に生成され、使用され、テストされ、デバグされ及び記録され、一又はそれ以上の原因入力と一又はそれ以上の結果出力とを含み、原因入力の一つへの原因信号の到着がトリップした又は安全な状態に設定されている一又はそれ以上の結果出力を生ずるようにプログラムされている。原因入力は、選択機能ブロックのような原因の存在を決定する他の機能ブロックに接続され得るが、結果出力はアナログ又はデジタル出力機能ブロックのような、プロセスプラント内の安全装置又は他のデバイスを制御する他の機能ブロックに接続されている。

原因結果機能ブロックは、原因結果マトリックスロジック又は一又はそれ以上の状態マシンに接続されたマルチプレクサを含み、個別の状態マシンは各結果出力に対して存在している。マルチプレクサは原因入力のそれぞれを受け取り及びデコードし、そして、原因入力及び先に特定された原因結果マトリックスロジックに基づいて、一又はそれ以上の状態マシンにトリップ信号を提供する。トリップ信号を受け取ると、状態マシンはトリップした又は安全な状態に、関連する結果出力を強制する。所望なら、次に、状態マシンは、例えば、安全システムをトリップした又は安全な状態から通常の状態（プロセスが正常に動作している）に安全に戻すことに関連する状態の集合の間の遷移のユーザ又はプロセスからのリセット信号のような、一又はそれ以上の他の信号を要求し得る。更に、各状態マシンは、その関連する結果出力信号をトリップした又は安全な状態に強制するような状態マシンを生ずる第１の原因を表す信号と同様に、状態マシンの現在の状態を表す信号を提供し得る。

この原因結果機能ブロックは、基本的な形式で容易に生成され、それは、原因結果マトリックスロジックをそれに供給するために、及び原因結果機能ブロックの所望の動作を定義するためのパラメータの集合に対する値を特定するために、構成又は安全技師を必要とするもにである。この原因結果機能ブロックはまた、原因結果機能ブロックの入力及び出力を制御計画内の他の機能ブロック又は要素に相互接続することにより、原因結果機能ブロックが他の機能ブロックと同様の方法で統合され得るのと同様に、機能ブロックロジックを使用するコントローラ又はロジックソルバに容易に統合される。結果として、この原因結果機能ブロックはまた、容易に記録され、テストされ及びデバグされる。更に、この原因結果機能ブロックは、安全システムが特定の安全デバイスをトリップした又は安全な状態から通常の動作の状態に戻す前に一連の状態を介してサイクルするのを可能とするなどのような、通常では安全システムに提供されていない付加的な機能を提供し得る。

図１を参照すれば、プロセスプラント１０は、安全システム１４（破線で表されている）を統合したプロセス制御システム１２を含み、これは、一般的には、プロセスプラント１０の好ましい安全動作を最大化させるためにプロセス制御システム１２によって提供される制御をモニタしより優位に立つ安全装備システム（ＳＩＳ）として動作する。また、プロセスプラント１０は、一又はそれ以上のホストワークステーション、コンピュータ又はユーザインターフェイス１６（これはどのようなタイプのパーソナルコンピュータ、ワークステーション、ＰＤＡ等でもよい）を含み、これらは、プロセス制御要員、保守要員、安全技師などのプラント要員によってアクセス可能である。図１に示されている実施例では、２つのユーザインターフェイス１６が、共通の通信ライン又はバス２２を介して２つの別々のプロセス制御／安全制御ノード１８及び２０と構成データベース２１とに接続されているものとして示されている。通信ネットワーク２２は、どのような所望のバス基盤の又は非バス基盤のハードウエアを用いても、どのような所望の有線又は無線の通信機構を用いても、及びどのような所望のイーサネット（Ｒ）のような通信プロトコルを使用しても実装され得る。

一般的に言えば、プロセスプラント１０のノード１８及び２０のそれぞれは、異なるデバイスが取り付けられるバックプレーン上に設けられるバス構造を介して相互接続されるプロセス制御システムデバイス及び安全システムデバイスの両方を含んでいる。ノード１８は、一又はそれ以上のプロセス制御システム入力／出力（Ｉ／Ｏ）デバイス２８，３０及び３２と同様に、プロセスコントローラ２４（これはコントローラの冗長ペアでもよい）を含んでいるように図１に示されており、一方、ノード２０は、一又はそれ以上のプロセス制御システムＩ／Ｏデバイス３４及び３６と同様に、プロセスコントローラ２６（これはコントローラの冗長ペアでもよい）を含んでいるように示されている。プロセス制御システムＩ／Ｏデバイス２８，３０,３２,３４及び３６のそれぞれは、図１にフィールドデバイス４０及び４２として示されているプロセス制御関連のフィールドデバイスに関連するプロセス制御の集合に通信可能に接続されている。プロセスコントローラ２４及び２６、Ｉ／Ｏデバイス２８−３６、並びにコントローラフィールドデバイス４０及び４２は、図１のプロセス制御システム１２を構成している。

同様に、ノード１８は、一又はそれ以上の安全システムロジックソルバ５０，５２を含み、一方、ノード２０は、安全システムロジックソルバ５４及び５６を含んでいる。各ロジックソルバ５０−５６は、メモリに格納されている安全ロジックモジュール５８を実行するプロセッサ５７を有するＩ／Ｏデバイスであり、安全システムフィールドデバイス６０及び６２へ制御信号を供給し及びこれらからの信号を受け取るように通信可能に接続されている。加えて、ノード１８及び２０のそれぞれは、少なくとも一つのメッセージ伝達デバイス（ＭＰＤ）７０又は７２を含み、これらは、リングタイプのバス接続７４（図１ではその一部のみが画かれている）を介して互いに通信可能に接続されている。安全システムロジックソルバ５０−５６、安全システムフィールドデバイス６０及び６２、ＭＰＤ７０及び７２、並びにバス７４は、一般的に、図１の安全システムを構成している。

プロセスコントローラ２４及び２６は、例示としてのみ述べるが、Fisher-Rosemount Systems, Inc.によって販売されているＤｅｌｔａＶ（登録商標）コントローラか、又は他の所望のタイプのプロセスコントローラであり得、Ｉ／Ｏデバイス２８，３０及び３２（コントローラ２４に対して）、Ｉ／Ｏデバイス３４及び３６（コントローラ２６に対して）、及びフィールドデバイス４０及び４２を使用してプロセス制御機能を（制御モジュールと一般的に称される何れをも使用して）提供するようにプログラムされる。特に、コントローラ２４及び２６のそれぞれは、その中か、さもなくばそれに関連するどこかに格納されている一又はそれ以上のプロセス制御ルーチンを実装し又は監視し、及びプロセス１０又はプロセス１０の一部を所望の方法で制御するためにフィールドデバイス４０及び４２並びにワークステーション１６と通信する。フィールドデバイス４０及び４２は、センサ、バルブ、トランスミッタ、ポジショナなどのようなどのような所望のタイプのフィールドデバイスであってもよく、所望の開放され、専用の又は他の通信若しくはプログラミングプロトコルに適合し得、このプロトコルには、例えば、ほんの２，３の例を挙げると、ＨＡＲＴ若しくは４−２０ｍＡプロトコル（フィールドデバイス４０について例示されているように）、FOUNDATION（Ｒ） Fieldbus protocolのようなフィールドバスプロトコル（フィールドデバイス４２について例示されているように）、又はCAN、Profibus、AS-Interface protocolsなどである。同様に、Ｉ／Ｏデバイス２８−３６は、どのような適切な通信プロトコルを使用する公知のタイプのプロセス制御Ｉ／Ｏデバイスでってもよい。

図１の安全システムロジックソルバ５０−５６は、プロセッサ５７と、フィールドデバイス６０及び６２を使用して安全システム１４に関連する制御機能を提供するためにプロセッサ５７上で実行されるように構成されている安全ロジックモジュール５８を格納するメモリとを含むどのような安全システム制御デバイスであってもよい。もちろん、安全システムフィールドデバイス６０及び６２は、上述のような何れの公知又は所望の通信プロトコルに従う若しくは使用するどのような所望のタイプのフィールドデバイスであってもよい。特に、フィールドデバイス６０及び６２は、独立した、専用の安全関連の制御システムによって従来のように制御されるタイプの安全−関連のフィールドデバイスであり得る。図１に示されているプロセスプラント１０では、安全フィールドデバイス６０は、ＨＡＲＴ若しくは４−２０ｍＡプロトコルのような専用の又は２地点間通信プロトコルを使用するとして画かれ、一方、安全フィールドデバイス６２は、Fieldbus protocolのようなバス通信プロトコルを使用するとして画かれている。安全フィールドデバイス６０は、バルブのシャットダウン、スイッチのシャットオフなどの所望の機能を実行し得る。

共通のバックプレーン７６（コントローラ２４,２６、Ｉ／Ｏデバイス２８−３６、安全システムロジックソルバ５０−５６、並びにＭＰＤ７０及び７２を通過して破線で表されている）が、コントローラ２４及び２６を、安全システムロジックソルバ５０，５２，５４又は５６並びにＭＰＤ７０及び７２と同様に、プロセス制御Ｉ／Ｏカード２８,３０，及び３２又は３４及び３６に接続するためにノード１８及び２０のそれぞれに於いて使用されている。コントローラ２４及び２６はまた、Ｉ／Ｏデバイス２８−３６、ロジックソルバ５０−５６、並びにＭＰＤ７０及び７２のそれぞれに、バス２２を介してワークステーション１６の何れかと通信することを可能とするために、バス２２のためのバスアービットレータとして動作する。

理解されるであろうが、ワークステーション１６のそれぞれは、プロセッサ７７と、プロセッサ７７上で実行されるように構成されている一又はそれ以上の構成及び／又は表示アプリケーションを格納するメモリ７８とを含んでいる。構成アプリケーション８０及び表示アプリケーション８２は、ワークステーション１６の一つに格納されて図１に開いて示されている。しかしながら、所望なら、これらのアプリケーションは、ワークステーション１６の異なる一つ又はプロセスプラント１０に関連する他のコンピュータに於いて格納され実行され得る。一般的に言えば、構成アプリケーション８０は構成情報を安全技師に提供し、そして安全技師が、プロセスプラント１０の幾つか又は全ての要素を構成し及びその構成を構成データベース２１に格納するのを可能とする。構成アプリケーション８０によって実行される構成アクティビティの一部として、安全技師は、プロセスコントローラ２４及び２６のための制御ルーチン又は制御モジュールを生成し得、ロジックソルバ５０−５６の何れか若しくは全てのための安全ロジックモジュール５８（安全ロジックソルバ５０−５６で使用するための原因結果機能ブロックの生成及びプログラミングを含む）を生成し得、並びにこれらの異なる制御及び安全モジュールをプロセスコントローラ２４及び２６並びに安全システムロジックソルバ５０−５６の適当な一つに、バス２２及びコントローラ２４及び２６を介してダウンロードし得る。同様に、構成アプリケーション８０は、他のプログラム及びロジックを、Ｉ／Ｏデバイス２８−３６、フィールドデバイス４０，４２，６０及び６２等の何れかに生成し又はダウンロードするのに使用され得る。

逆に、表示アプリケーション８２は、プロセス制御オペレータ、安全オペレータ等のユーザに一又はそれ以上の画像を提供するために使用され得、これは、プロセス制御システム１２及び安全システム１４の状態に関する情報を、所望されるとおりに別々又は同じ画像に含んでいる。例えば、表示アプリケーション８２は、オペレータへのアラームの指示を受け取り及び表示するアラーム表示アプリケーションであり得る。所望なら、このようなアラーム表示アプリケーションは、「アラーム優先調製を含むプロセス制御システム」と題された米国特許第５，７６８，１１９号、及び「プロセス制御ネットワークに於ける統合されたアラーム表示」と題された米国特許出願第０９／７０７，５８０号に開示されており、何れも本願の譲受人に帰属し、ここに明確に取り入れられる。しかしながら、システム１２及び１４の両方からのアラームがアラーム表示アプリケーションを実行しているオペレータワークステーション１４に送られ、異なるデバイスからのアラームであると認識されたときに、これらの特許のアラーム表示又はアラームバナーは、プロセス制御システム１２及び安全システム１４の両方からのアラームを統合されたアラーム表示に受け取り及び表示することが理解されるであろう。同様に、オペレータは、プロセス制御アラームと同様の方法でアラームバナーに表示されている安全アラームを取り扱い得る。例えば、オペレータ又はユーザは、安全アラーム、安全アラームの停止等をアラームディスプレイを使用して認識し得、これは、安全システム１４内の適当なプロセスコントローラ２４及び２６に、その安全アラームに関連する対応するアクションを採るために、バス２２及びバックプレーン７６上の通信を使用してメッセージを送るであろう。同様の方法で、他の表示アプリケーションは、システム１２及び１４の一つからのどのようなデータも従来のようにプロセス制御システムに提供されるディスプレイ又は表示に統合されるように、これらのシステムが同じタイプ及び種類のパラメータ、安全性及び参照性を使用するときに、これらのシステム１２及び安全システム１４の両方からの情報又はデータを表示し得る。

いずれにせよ、アプリケーション８０及び８２は、安全システムロジックソルバ５０−５６のそれぞれからと同様に、別々の構成及び他の信号をプロセスコントローラ２４及び２６のそれぞれに送り及びこれらからデータを受け取り得る。これらの信号は、フィールドデバイス４０及び４２の動作パラメータの制御に関連するプロセス−レベルのメッセージを含み、安全−関連のフィールドデバイス６０−６２の動作パラメータの制御に関連する安全−レベルのメッセージを含み得る。安全システムロジックソルバ５０−５６は、プロセス−レベルのメッセージと安全−レベルのメッセージとの両方を認識するが、安全システムロジックソルバ５０−５６は、メッセージの２つのタイプを識別することができ、そして、プロセス−レベルの構成信号によってプログラムされ又は実行されることはできない。一つの実施形態に於いては、プロセス制御システムデバイスに送られるプログラミングメッセージは、安全システムによって識別される特定のフィールド又はアドレスを含み、そして、それらの信号が安全システムデバイスをプログラムするのに使用されないようにする。

所望なら、安全システムロジックソルバ５０−５６は、プロセス制御Ｉ／Ｏカード２８−３６に使用されるハードウエア及びソフトウエア設計に比較して、同じか又は異なるハードウエア又はソフトウエア設計を採用し得る。プロセス制御システム１２内のデバイス及び安全システム１４内のデバイスに対するもう一つの技術の使用は、ハードウエア及びソフトウエアの欠陥の共通の原因を減少させ又は排除する。

更に、ロジックソルバ５０−５６を含む安全システムデバイスは、それによって実装されている安全−関連の機能に為されている認知されない変更の機会を減少させ又は排除する所望の孤立した及び安全な技術を採用し得る。例えば、安全ロジックソルバ５０−５６及び構成アプリケーション８０は、ロジックソルバ５０−５６内の安全モジュールへの変更を行う特定の権限レベルを有する人又は特定のワークステーションに位置する人を必要とし、その権限レベル又は位置は、コントローラ２４及び２６並びにＩ／Ｏデバイス２８−３６によって達成されるプロセス制御機能への変更に必要な権限又はアクセスレベル若しくは位置とは異なっている。この場合には、安全システム１４に変更を加える権限を与えられた安全ソフトウエア内又はワークステーションの位置で指定され人のみが、安全−関連の機能を変更する権限を有し、これにより、安全システム１４の運転に対する不正行為の機会が減少する。後に理解されるように、このような安全性を実装するために、安全ロジックソルバ５０−５６内のプロセッサは、適正なフォーム及び安全性のために、到来するメッセージにアクセスし、安全ロジックソルバ５０−５６内で実行される安全−関連の制御モジュール５８に為される変更のゲートキーパーとして動作する。

更に、所望なら、一度安全−関連機能がロジックソルバ５０−５６内で有効にされると、安全機能への状態変更は、適切なアクセス権なしにオペレータワークステーション１６を介して行われ得ず、このことは、プロセス制御システム１２に関連する通信構成が、安全システム１４に対する初期化を提供するために使用されること、及び安全システム１４の動作の実行時間の報告を提供するのに使用されることを可能とするが、しかし、まだ、プロセス制御システム１２への変更が安全システム１４の動作に衝撃を与えることができないと言う意味で、プロセス制御システム１２を安全システム１４から分離することを可能としている。

後に理解されるように、ノード１８及び２０のそれぞれに於けるバックプレーン７６の使用は、安全ロジックソルバ５０及び５２並びに安全ロジックソルバ５４及び５６が、これらのデバイスのそれぞれによって実装された安全機能を調整するために互いに局所的に通信を行い、互いにデータ通信を行い、又は他の統合機能を果たすことを可能とする。他方、ＭＰＤ７０及び７２は、プラント１０の広大な各所に配置された安全システム１４の各部が、それでもプロセスプラント１０の異なるノードでの安全動作の調整を提供するために互いに通信することを可能とするように動作する。特に、バス７４に関連するＭＰＤ７０及び７２は、プロセスプラント１０の異なるノード１８及び２０に関連する安全ロジックソルバが、割り当てられた優先度に従ってプロセスプラント１０内の安全−関連機能のカスケード接続を許容するために互いに通信可能にカスケードされるのを可能とする。あるいは、プロセスプラント１０内の異なる位置にある２つ又はそれ以上の安全−関連機能は、プラント１０の別々の領域又はノード内の個々の安全フィールドデバイスに向けて専用線を走らせることなくインターロックされ又は相互接続され得る。換言すれば、ＭＰＤ７０及び７２並びにバス７４の使用は、プロセスプラント１０の実質的に全体に亘って分布するが異なる安全関連のハードウエアが要求に応じて互いに通信するのを可能とするために通信可能に相互接続されたその異なる構成要素を有する安全システム１４を、安全技師が設計し及び構成することを可能とする。この特徴はまた、追加の安全システムロジックソルバが、それらが必要とされるに応じて又は新たなプロセス制御ノードがプロセスプラント１０に追加されるのに応じて、安全システム１４に付加されることを可能とするような安全システム１４の拡張性を提供する。

ロジックソルバ５０−５６は安全デバイス６０及び６２に関連する制御アクティビティを実行するように、機能ブロックプログラミングパラダイムを使用してプログラムされ得ることが理解されるであろう。特に、ロジックソルバ５４一つの安全制御モジュール５８ａ（メモリ７９に格納されている）の拡大図に示されているように、安全制御モジュールは、プラント１０の動作の間の実装のためにロジックソルバ５４に生成され及びダウンロードされ得る通信可能に相互接続された機能ブロックの集合を含んでいる。図１に示すように、制御モジュール５８ａは、他の機能ブロック９６と通信可能に相互接続された入力（原因入力と称される）を有する２つの原因結果（ＣＥ）機能ブロック９２及び９４を有し、機能ブロック９６は、例えば、アナログ入力（ＡＩ）、デジタル入力（ＤＩ）機能ブロック、選択機能ブロック、又は原因結果機能ブロック９２及び９４への原因信号を提供するように設計された他の機能ブロックであり得る。原因結果機能ブロック９２及び９４は、出力機能ブロック９８に接続された出力（結果出力と称される）を有し、出力機能ブロック９８は、アナログ出力（ＡＯ）、デジタル出力（ＤＯ）、又はスイッチ、バルブ等の安全デバイス６０及び６２の動作を制御するために原因結果機能ブロック９２及び９４からの結果信号を受け取る他の機能ブロックであり得る。もちろん、安全制御モジュール５８ａは、どのような機能をも実行するように所望された又は有用な方法で構成された一又はそれ以上の原因結果機能ブロックに従うどのようなタイプの機能ブロックをも含むどのような所望の方法でもプログラムされ得る。

また、図１の安全制御モジュール５８ａの拡大図は、その中の２つの原因結果機能ブロックを含んでいるけれども、任意の数の異なる安全ロジックモジュール５８が、異なるロジックソルバ５０−５６のそれぞれについて生成され及びその中で使用され、これらのモジュールのそれぞれは、任意の所望の方法によって他の機能ブロックに通信可能に接続された任意の数の原因結果機能ブロックを含み得ることが理解されるであろう。同様に、例えば、もしＦｉｅｌｄｂｕｓネットワークで使用されるなら、任意のフィールドバスタイプの機能ブロックであり得る原因結果機能ブロック９２及び９４、又はそれに接続された他の任意の他の機能ブロックは、フィールドデバイス６２のような他のデバイス内に配置され実装され得る。もし安全システムの外側で使用されたなら、原因結果機能ブロックは、プロセスコントローラ２４,２６、Ｉ／Ｏデバイス２８−３６、フィールドデバイス４２等に実装され得る。

図２は、図１の原因結果機能ブロック９２の構成要素を示すブロックダイヤグラムである。原因結果機能ブロック９２は、この場合には、それぞれＣａｕｓｅ１、Ｃａｕｓｅ２、Ｃａｕｓｅ３等のようにマークされた７つの原因入力１００を含み、図１の入力機能ブロック９６のような異なるソースから配送される原因信号を受け取るように構成されている。あるいは、原因信号は、機能ブロックに加えてそのプロセス内の他のアプリケーション又は他の要素によって供給され得る。原因入力１００のそれぞれは、ここではマルチプレクサ１０２として参照されるマトリックスロジックブロックに供給され、これは、入力１０６で安全技師によって提供される典型的な原因結果マトリックスのような原因結果マトリックス（ＣＥＭ）ロジック１０５を使用し、必要なら、プロセス１０内の特定された安全でない状態の検出を示す状況を変更する何れかの特定の原因入力の結果として、どの結果が活性化され又はトリップされるべきかを決定する。

典型的な原因結果ロジックを示す例示の原因結果マトリックス１０５は、図３により詳細に示されている。原因結果機能ブロック９２で使用される原因結果マトリックス１０５は、マトリックスの左側の７つの原因（マトリックス１０５の異なる列に関連する各原因とともに）を含んでおり、そして、そのマトリックスの先頭に沿ってリストされた２つの結果（マトリックス１０５の異なる欄に関連する各結果とともに）を有している。原因は複雑なデータ変数、又はＤＥＳＣ＿ＣＡＵＳＥ１ Ｓｔｒｉｎｇ、ＤＥＳＣ＿ＣＡＵＳＥ２ Ｓｔｒｉｎｇ等の名前を付けられた信号として特定され、そのそれぞれは、それに関連する値と状態を有し、結果は複雑なデータ変数又はＤＥＳＣ＿ＥＦＦＥＣＴ１ Ｓｔｒｉｎｇ、ＤＥＳＣ＿ＥＦＦＥＣＴ２ Ｓｔｒｉｎｇ等の名前を付けられた信号として特定され、そのそれぞれは、それに関連する値と状態を有している。マトリックス１０５は１６の原因及び１６の結果を提供することが可能なように記載されているが、それは例示の原因結果機能ブロック９２が構成されている方法なので、この場合は７つの原因と２つの結果のみが使用されている。しかしながら、ここで検討している原因結果機能ブロックは、妥当な数の原因及び結果（入力及び出力）を有し得、そして、原因結果マトリックスは一般的には原因結果機能ブロックの原因入力と結果出力が存在するのと同じ数の原因及び結果を含んでいることが理解されるであろう。更に、マトリックス１０５は、図３に示されている１６×１６以外のどのような所望のサイズでもあってもよい。

マトリックス１０５は、安全技師が原因結果機能ブロック９２を構成し又は生成しているときに、例えば、安全技師に表示され得るような方法で図３に示されている。マトリックスロジック１０５の適切なプログラミングを可能とするために、原因及び結果のそれぞれに対して提供されるストリングは、安全技師が、どの原因及び結果がマトリックス１０５で実際に表示されているのかを確実に理解するように原因又は結果を一意的に確認し又は命名し得る。同様に、垂直線１０６及び水平線１０７は、マトリックス１０５の左側及び先頭側にリストされている特定の原因及び結果にマトリックス１０５のボックス又は要素が並ぶように安全技師によって使用され及び操作される。このように、安全技師は、どのボックスがどの原因及び結果に関係するかを明確に確認することができる。同様に、マトリックス１０５のボックス又は要素は、もしそれらが使用されないなら、灰色にされる。

後に理解されるように、原因結果マトリックス１０５の特定のボックスのチェックは、そのボックスに関連する原因がそのボックスに関連する結果をもたらすであろうことを示しており、チェックがないことは原因が結果を生じていないであろうことを示している。従って、第１の原因ＤＥＳＣ＿ＣＡＵＳＥ１は、トリップされ又は活性化されているＤＥＳＣ＿ＥＦＦＥＣＴ１及びＤＥＳＣ ＥＦＦＥＣＴ２の両方の結果を生じるであろう。しかし、第２の原因ＤＥＳＣ＿ＣＡＵＳＥ２は、トリップされている第１の結果ＤＥＳＣ＿ＥＦＦＥＣＴ１のみを生じるであろう。もちろん、安全技師は、マウス又はキーボードを使用して、チェックをボックス上にドラッグし、ボックスにそれをドロップし、又は他の所望の方法により、ボックスを選択し得る。原因結果マトリックス１０５は、図２のマルチプレクサ１０２の特性であり、原因結果機能ブロック９２の動作に先立ってこれに提供される。

図２を再び参照すると、一又はそれ以上の原因入力を受け取ると、マルチプレクサ１０２は、トリップ信号ライン１０８及び１１０の適当な一つに、原因結果マトリックス１０５によって定義されるように、２つの結果のそれぞれに対してマルチプレクサ１０２の入力で現存する活性なアクティビティを表す出力を生成する。トリップ信号ライン１０８及び１１０のそれぞれは、原因結果機能ブロック９２内の２つの状態マシン１１２及び１１４の一つに接続されている。異なる状態マシン１１２及び１１４は、異なる結果出力に関連し、原因結果機能ブロック９２によって作成される異なる結果信号を生成する。特に、状態マシン１１２及び１１４は、（Ｅｆｆｅｃｔ１及びＥｆｆｅｃｔ２とラベルされた）それぞれ結果出力１１６及び１１８を、それぞれライン１０８及び／又は１１０上の原因表示の存在に応答して、安全な又はトリップした状態にトリップされ又は設定されるようにする。この実施形態では、図３のマトリックス１０５を使用するとき、並びにＣａｕｓｅ１及びＣａｕｓｅ２の入力１００が適当な原因入力１００が同時にアクティブ（一方、他のＣａｕｓｅ３からＣａｕｓｅ７のそれぞれは不活性のままである）となったときに、マルチプレクサ１０２は、これらの両方の場合とも図３のマトリックスロジック１０５に従ってＥｆｆｅｃｔ１の動作又はトリップ化をもたらすので、Ｃａｕｓｅ１及びＣａｕｓｅ２の表示を含む信号をトリップ信号ライン１０８上に置くであろう。同様に、マルチプレクサ１０２は、図３のマトリックス１０５に従って設定され又はトリップされたＥｆｆｅｃｔ２を生ずる活性なただ一つの原因であるＣａｕｓｅ１のみを示すトリップ信号ライン１０８及び１１０上に置くであろう。

一般的に言えば、結果の原因結果機能ブロックに関連するそれぞれの結果又は結果出力に対する単一のそして異なる状態マシンが存在する。図２のこの場合には、原因結果機能ブロック９２は２つの結果出力のみを含んでいるので、２つの状態マシン１１２及び１１４のみを含んでいる。しかしながら、もし、原因結果機能ブロック９２が例えば１０個又は１２個のようなより多くの結果出力を含んでいるなら、それぞれ原因結果機能ブロック９２は１０個又は１２個の状態マシンを含むであろう。同様に、マルチプレクサ１０２は、マルチプレクサ１０２に設けられる原因入力１００及びマトリックス１０５に基づいてこれらの状態マシンに活性な原因ストリングを提供するために、例えば、異なるトリップ信号ラインを介してこれらの状態マシンに接続されるであろう。

Ｅｆｆｅｃｔ１状態マシンの動作を説明すると、原因結果機能ブロック９２内の他の状態マシンが同様の方法で動作することが理解される。特に、Ｅｆｆｅｃｔ１に対する状態マシン１１２は、Ｒｅｑｕｉｒｅ＿Ｒｅｓｅｔ１信号１２２、Ｒｅｓｅｔ＿Ｐｅｒｍｉｔ１信号１２４、Ｒｅｓｅｔ１信号１２６及びＳｔａｒｔ＿Ｐｅｒｍｉｔ１１２８を含む状態入力の集合と同様に、ライン１２０上のＴｒｉｐ＿Ｔｙｐｅの入力信号、トリップ信号ライン１０８上の活性な原因入力又は信号（Ａｃｔｉｖｅ＿Ｃａｕｓｅｓ１とラベルされる）を受け取る。トリップ信号入力及び状態入力は、状態マシン１１２を更にここで述べるような異なる状態の間の遷移を引き起こし、結果機能ブロック９２の出力でのＥｆｆｅｃｔ１信号１１６の変更が、正常又はトリップされていない値とトリップされた又は安全な値との間、及びその逆のトリップされた又は安全な値と正常又はトリップされていない値との間での変更を引き起こす。

より詳細には、ライン１０８上のＡｃｔｉｖｅ＿Ｃａｕｓｅｓ１ Ｓｔｒｉｎｇが一又はそれ以上の原因（これらは安全な又はトリップされた状態に移行するＥｆｆｅｃｔ１信号を生成すると思われる）が現在アクティブであることを示しているなら、状態マシン１１２はＥｆｆｅｃｔ１出力信号をトリップされた又は安全な状態に移行するように強制するであろう。トリップされた又は安全な状態の定義はライン１２０上のＴｒｉｐ＿Ｔｙｐｅ信号に依存し又はこれによって定義される。特に、ライン１２０上のＴｒｉｐ＿Ｔｙｐｅ信号は、Ｅｆｆｅｃｔ１信号の安全に動作している状態又は値を、１又は０の何れか、高又は低等として定義する。同時に、Ｔｒｉｐ＿Ｔｙｐｅ信号１２０は、原因入力１００の状態又は値を定義し、これは、マルチプレクサ１０２へ入力されると、原因が存在するかしないかを示す。換言すれば、原因入力１００は同様に１又は０、高又は低等として定義され、プロセス内に検出された原因が存在するかしないかを示す。ライン１２０上のＴｒｉｐ＿Ｔｙｐｅ信号は、検出された原因及び結果機能ブロック９２の適正な動作に対する安全な結果の状態に関連する原因及び結果の値を定義し得る。一般的に言えば、原因入力１００のそれぞれは、同様の方法で原因の存在を定義し（即ち、１又は０の何れかとして）、出力信号１１６及び１１８のそれぞれは、同様の方法で結果の存在を定義（即ち、１又は０の何れかとして）する。この場合には、ライン１２０上の同じＴｒｉｐ＿Ｔｙｐｅ信号が原因結果機能ブロック９２内の各状態マシンに供給される。もしこのような場合でないなら、別々のＴｒｉｐ＿Ｔｙｐｅ信号が定義され、原因結果機能ブロック９２内の異なる状態マシンのそれぞれに別々に供給される。

いずれにせよ、ライン１０８上のＡｃｔｉｖｅ＿Ｃａｕｓｅｓ１信号がプロセス内の一又はそれ以上の原因の検出に関連する値又は状態を示すとき、状態マシン１１２はＥｆｆｅｃｔ１出力信号１１６にそのトリップ又は安全値になるように強制する。しかしながら、一度Ｅｆｆｅｃｔ１出力信号１１６が安全状態になると、状態マシン１１２は、Ｅｆｆｅｃｔ１出力信号１１６が通常の又はトリップしていない状態に戻るよう強制し又は変更するために、一連の追加の状態の間で動作し又は移動するようにさせる。状態マシン１１２の動作は、状態マシン１１２の状態入力Ｒｅｑｕｉｒｅ＿Ｒｅｓｅｔ１ １２２、Ｒｅｓｅｔ＿Ｐｅｒｍｉｔ１ １２４、Ｒｅｓｅｔ１ １２６及びＳｔａｒｔ＿Ｐｅｒｍｉｔ１ １２８に存在する信号によって大部分決定され、これらは、後に理解されるように、トリップされた及び正常な状態の間の移行に使用される自由なロジックを特定するために安全技師又は他のユーザによってそれぞれの異なる状態マシン上で個別に構成可能であり、その逆も可能である。状態入力は状態マシンから状態マシンへと変化するので、原因結果機能ブロック９２の各結果出力は、それに関連する異なる過渡的挙動を有している。

図４は、状態マシン１１２がトリップした又は安全なモードからトリップしていない正常なモードへと、又はその逆にサイクルする異なる状態を表す状態ダイヤグラム１３０を表している。図４の状態ダイヤグラム１３０は、トリップ状態１３２、リセット許容待ち状態１３４、リセット可能状態１３６、スタート許容状態待ち１３８、正常動作状態１４０，及びトリップ開始−遅延状態１４２として定義される６つの状態を含んでいる。状態ダイヤグラム１３０中の状態間の矢印は、状態１３２−１４２間の可能な状態遷移を示している。

状態ダイヤグラム１３０から理解されるように、状態マシン１１２は、トリップ信号入力１０８で活性な原因を受け取った状態マシン１１２に応答して現時点で居る位置である１３４，１３６,１３８,１４０及び１４２の何れの状態からも、トリップ状態１３２に入ることができる。従って、状態マシン１１２が正常動作状態１４０にありＥｆｆｅｃｔ１信号１１６が正常動作状態のとき、トリップ信号ライン１０８上の一又はそれ以上の活性な原因の存在は、状態マシン１１２をトリップ状態１３２に入らせる。同様に、トリップ信号入力１０８上の活性な原因の表示の存在は、状態マシン１１２が他の状態１３４，１３６,１３８,１４０及び１４２の何れかにあるとき、状態マシン１１２をトリップ状態１３２に入らせる。

一度トリップ状態１３２に入ると、状態マシン１１２は、ライン１２０上のＴｒｉｐ＿Ｔｙｐｅ信号によって定義されるように、Ｅｆｆｅｃｔ１信号１１６をトリップされた又は安全な状態値になるように強制する。状態マシン１１２は、ライン１０８上の活性な原因信号の全てが除去されるまで、即ち、Ｅｆｆｅｃｔ１を生ずる入力１００での原因信号の全てが「原因が存在しない」値に設定されるまで、トリップされた状態にとどまるであろう（これにより、Ｅｆｆｅｃｔ１出力信号１１６を維持する）。状態マシン１１２は、状態マシン１１２への状態入力１２２,１２４,１２６及び１２８に存在する信号に依存して、トリップ状態１３２から状態１３４，１３６,１３８,１４０及び１４２の何れかに入る。例えば、もし、Ｒｅｑｕｉｒｅ＿Ｒｅｓｅｔ１ １２２が高又は活性に設定され、Ｒｅｓｅｔ＿Ｐｅｒｍｉｔ１信号１２４が低又は不活性に設定されると、状態マシン１１２はトリップ状態１３２からリセット許容待ち状態１３４に移行しなければならず、他の状態の何れへも直接入ることはできないであろう。一度リセット許容待ち状態１３４に入ると、状態マシン１１２はＲｅｓｅｔ＿Ｐｅｒｍｉｔ１信号１２４をチェックする。この信号が高又は活性になり、それによってリセット許容（これは、例えばオペレータ又はがプロセス制御システム１０内の他の人によって図１のユーザインターフェイス１６を使用して発行され得る）を示す信号が状態マシン１１２によって受け取られたとき、状態マシン１１２はリセット可能状態１３６に入る。あるいは、もし、Ｒｅｑｕｉｒｅ＿Ｒｅｓｅｔ１信号１２２が低（これにより、リセット許容は不要であることを示す）、であるなら、状態マシン１１２はトリップ状態１３２からリセット可能状態１３６に直接移行する。

リセット可能状態１３６では、Ｒｅｑｕｉｒｅ＿Ｒｅｓｅｔ１信号１２２が活性のときのＲｅｓｅｔ＿Ｐｅｒｍｉｔ１信号１２４の除去は、状態マシン１１２をリセット許容待ち状態１３４に戻すこととなる。あるいは、リセット可能状態１３６では、状態マシン１１２はＲｅｓｅｔ１信号１２６を待ち、これは、オペレータ又はバッチ実行アプリケーションのようなアプリケーションからのキーストローク又はコマンドによって生成され、状態マシン１１２への状態入力１２６上に現れる。Ｒｅｓｅｔ１信号１２６が受け取られると、状態マシン１１２は、もし、Ｓｔａｒｔ＿Ｐｅｒｍｉｔ１信号１２８が状態マシン１１２への入力で存在するか若しくは活性であるなら正常動作状態１４０に入り、又は、もし、Ｓｔａｒｔ＿Ｐｅｒｍｉｔ１信号が状態マシン１１２の状態入力１２８で存在せず若しくは活性であるなら状態待ち１３８へ入る。あるいは、状態マシン１１２は、リセット許容が要求されず又は要求され存在するとき（即ちＲｅｑｕｉｒｅ＿Ｒｅｓｅｔ１信号１２２が不活性又は活性のときで、Ｒｅｓｅｔ＿Ｐｅｒｍｉｔ１信号１２４が存在し又は活性のとき）、及びＲｅｓｅｔ１信号１２６が存在し又は活性のとき、トリップ状態１３２からスタート許容状態待ち１３８へ直接入る。

スタート許容状態待ち１３８にあるとき、状態マシン１１２がＳｔａｒｔ＿Ｐｅｒｍｉｔ１信号が状態入力１２８で高又は活性になるまで待ち、次に、Ｓｔａｒｔ＿Ｐｅｒｍｉｔ１信号は、正常動作状態１４０に入る。オペレータによって、例えば図１のユーザインターフェイス１６の一つを介して、プロセス制御ネットワーク１０内のコントローラ又は何れかのコンピュータに於けるアプリケーションによって、プロセス変数又は他のプロセス信号によって、又は他のどのような方法によっても、生成され得る。しかしながら、スタート許容信号は、原因結果機能ブロックに正常モードで操作するサイクルを開始するように命令するため、オペレータ又はバッチソフトウエアアプリケーションのような他のプログラムによって、典型的に生成される。

リセット許容信号が要求されず又は要求されそして存在し（即ち、Ｒｅｑｕｉｒｅ＿Ｒｅｓｅｔ１信号１２２が不活性又は活性でＲｅｓｅｔ＿Ｐｅｒｍｉｔ１信号１２４が存在し又は活性のとき）、そしてＲｅｓｅｔ１信号１２６及びＳｔａｒｔ＿Ｐｅｒｍｉｔ１信号１２８の両方が存在し又は活性のとき、状態マシン１１２は、トリップ状態１３２から直接正常動作状態１４０に入り得る。いずれにしても、一度正常動作状態１４０になると、状態マシン１１２は、Ｔｒｉｐ＿Ｔｙｐｅ信号１２０によって定義されるように、Ｅｆｆｅｃｔ１信号１１６をその正常又はトリップしていない状態に強制し、それによて、状態マシン１１２によって制御されているＥｆｆｅｃｔ１に関する正常動作を許容する。

後に理解されるであろうように、状態マシン１１２の許容ロジックは、原因結果機能ブロック９２への状態入力として顕在化され得る内部パラメータの操作によって達成され又は定義され得る。安全技師は、各結果信号に対して、結果信号が正常動作状態に遷移するであろう前に、何の状態信号が要求されているかを決定し得る。例えば、図４の状態ダイヤグラムに於いて、もし、オペレータリセットが要求されているなら、オペレータリセットそれ自身とスタート許容が正常動作状態への遷移に必要である。もし、オペレータリセットが必要でないなら、全ての関連する原因信号が不活性になった後、スタート許容のみが存在することが必要である。

状態マシン１１２は、図２のトリップ信号ライン１０８上の一又はそれ以上の活性な原因を受け取ると、速やかに正常動作状態１４０からトリップ状態１３２に移行する。しかしながら、所望なら、状態マシン１１２はまた、状態マシン１１２がトリップ信号ライン１０８上の一又はそれ以上の活性な原因を受け取ったとき、正常動作状態１４０からトリップ開始−遅延状態１４２に入るようにセットアップされ得る。別々の入力が状態マシン１１２及び１１４のそれぞれに、これらのマシンがトリップ開始−遅延状態１４２を使用すべきであるか、又は状態マシン１１２及び１１４がトリップ開始−遅延状態を使用するか又は使用しないかを生成するように構成され得るかを示すために提供されている。トリップ開始−遅延状態１４２内にあるとき、状態マシン１１２は、クロック又は他のカウンタをセットし、予め決められた値までカウントダウン（又はアップ）し、それによってトリップ状態１３２に入る前に特定の時間の間待つ。その時間がタイムアウトとなった後、状態マシン１１２はトリップ状態１３２に入る。しかし、トリップ開始−遅延状態１４２の間、状態マシン１１２は、正常又はトリップされていない状態に於いて、図２のＥｆｆｅｃｔ１信号１１６を維持する。所望なら、もし、トリップ信号ライン１０８上の原因表示の全てがタイマーカウントアウト前に除去されならと、又は、もし（オペレータによって発行されるような）中止信号がタイマーカウントアウト前に状態マシン１１２によって受け取られならと、状態マシン１１２は、正常動作状態１４０に再入することができるように設計され得る。あるいは、状態マシン１１２は、トリップ開始−遅延状態１４２を出てトリップ状態１３２に入ることができるのみであるように設計され得る。トリップ開始−遅延状態１４２は、原因信号１００に於けるノイズ又は小さい変動が、シャットダウン（これは、時間、工数及び材料の無駄という観点から非常に高価となり得る）を生ずるのを防止するのに、又はオペレータ若しくは他のユーザがシャットダウンを中止する機会を可能とするのに使用される。

図４の状態ダイヤグラム１３０は、正常動作及びトリップされた状態、又はその逆の間の遷移を行う原因結果機能ブロック９２の状態マシンを可能とする一つの方法を示しているが、状態マシンはこれらの状態のより少ない使用又は追加の状態又はこれらの２つの幾つかの組み合わせを使用するように設計され得ることを理解すべきである。更に、状態マシン１１２及び１１４の動作は、原因結果機能ブロック９２が、他のプログラミング環境で生成される公知の原因及び結果ロジックに於いて通常提供されるものを超えて、追加の機能を提供することを可能とする。

所望なら、状態マシン１１２は、例えば、オペレータ又は他のユーザに情報を提供するために、又はプロセス１０内の他のアプリケーション又は制御ルーチンによる使用のために、多くの他の出力を生成し得る。例えば、状態マシン１１２は、状態マシン１１２が現在位置している状態（図４の状態１３２−１４２の一つ等）を確認するストリング又は他の信号を提供するＳｔａｔｅ１出力１４０を生成し得る。更にまた、状態マシン１１２は、状態マシン１１２をトリップ状態１３２に入らせる原因入力１００の最初の原因を示すＦｉｒｓｔ＿Ｏｕｔ１信号１４２を生成し得る。Ｆｉｒｓｔ＿Ｏｕｔ１信号１４２は、そのプロセスプラント又はその部分がシャットダウンして、状態マシン１１２が（図４の）トリップ状態１３２に入るようにするために、どの原因が状態マシン１１２の入力に存在する第１の原因であるかを決定する。この信号は、一般的には状態マシンが正常動作モードに入ったときにリセットされるが、有用であり、ときには、トリップされた状態にＥｆｆｅｃｔ１信号１１６を置くことは、トリップされている同じ又は異なってさえいる結果出力を生ずる、活性になり又は高にセットされる他の原因信号１００をもたらすので、必要ある。その時点で、最初の原因出力なしには、何の原因が一連のシャットダウンを引き起こしたかを言うことは困難である。

原因結果機能ブロック９２のマルチプレクサ１０２は、原因信号の値に基づいて動作し又は原因を検出することができるが、マルチプレクサ１０２は、それに加えて又はその代わりに、原因が存在するかどうかを決定するのに一又はそれ以上の原因信号１００に関連する状態信号を使用し得る。この場合、図２のマルチプレクサ１０２は、原因入力及び原因結果マトリックス１０５に基づいて、トリップ信号ライン１０８及び１１０をどのようにして何時生成したか決定するための状態論理ブロック１５０を含み得る。例えば、動作の一つのモードでは、上述のように、状態論理ブロック１５０は、原因信号の状態が何であろうと、適当な原因信号の値がプラント１０内の原因の存在を示すとき、マルチプレクサ１０２に、トリップ信号ライン１０８及び１１０の一又はそれ以上に原因の表示を生成じさせ得る。もう一つの動作モードでは、マルチプレクサ１０２の状態論理ブロック１５０は、もし原因信号の値が検出された原因信号の条件又は状態の存在を示すか、又は原因信号が不良の状態なら、たとえ原因信号の値が良好又は「原因不存在」状態のままであっても、原因結果マトリックス１０５によって定義されるような特定の原因に対する結果状態マシンのそれぞれのトリッピングを引き起こす。更にもう一つの動作モードでは、マルチプレクサ１０２の状態論理ブロック１５０は、良好又は正常を有する最後の実際の原因信号（特定の原因信号１００に対するもの）を使用し及び不良の状態を有するその後の全ての原因信号を無視し得る。この場合、もし原因信号の条件又は状態が不良状態になれば、マルチプレクサ１０２は、良好又は正常の状態を有する原因信号の条件又は状態信号に関連する最後の値を他に使用する（それによって、不良原因信号を基本的に無視する）。もちろん、マルチプレクサ１０２の状態論理ブロック１５０は、プロセスプラント１０内の原因の存在又は不存在を検出する各原因信号に対する値と状態の表示若しくは他のパラメータとの他の組み合わせを使用し得る。

ここでは、状態マシン１１２の動作のみが記述されているが、原因結果機能ブロック９２の状態マシン１１４等の他の状態マシンのそれぞれについても、状態マシン１１２に関連して記述したのと同様の方法で動作することが理解されるであろう。同様に、原因結果機能ブロックによって生成され又は制御される多くの結果によって決定される数のどのような特定の原因結果機能ブロックに於いても、どのような異なる数の状態マシンも提供され得る。

所望なら、原因結果機能ブロック９２は、他のパラメータ及び状態の特徴づけも含み得る。例えば、原因結果機能ブロック９２は、一又はそれ以上の結果出力をトリップした又は安全な状態に強制する、ユーザ、他のアプリケーションなどによって設定される強制結果パラメータ含み得る。このようなパラメータは、シャットダウン状態を生成し又はシャットダウン状態でシステムを維持するのに使用され得る。強制結果パラメータの動作は、たとえトリップした状態に強制されている結果に関連する状態マシンが図４のトリップ開始−遅延状態１４２にあっても、トリップした状態に強制されている結果によって定義されるように、即座のシャットダウン手法を引き起こす。同様に、強制パラメータと同じ又は異なるパラメータであり得る強制正常パラメータは、原因結果機能ブロックの入力に原因結果が存在しても、結果を正常の状態又は値に強制し得る。

結果信号又は原因結果機能ブロックの出力のそれぞれは、これに関連する、例えば結果信号が位置する状態又は（マルチプレクサ１０２に於いて使用されるマトリックスロジックによって定義される）状態が結果信号に関連する原因の状態等によって決定される状態を有している。特に、もし、原因信号が不良のときにマルチプレクサ１０２の状態論理ブロック１５０が原因信号の状態を無視し又は原因の存在を検知すると、その結果信号の状態が不良に設定されているその結果信号に（原因結果マトリックス１０５によって定義されるように）関連する原因信号のそれぞれの状態が不良でなければ、結果信号の状態は良好に設定され得る。結果信号の状態は、状態論理ブロック１５０が原因信号の最後の良好な値を使用したときに良好に設定され得る。もちろん、他の状態もそれぞれの結果信号に対して定義され得る。

原因マスクパラメータは、一又はそれ以上の原因信号が特定の条件下でアクティブになるのを妨げるように、原因結果機能ブロックに提供され得る。例えば、バッチ実行プログラミングは、バッチが実行されていないときに原因結果機能ブロックに入力されている一又はそれ以上の原因信号に対して原因マスクパラメータを設定し、これにより、問題が存在しないと予想されるときに結果のトリッピングを妨げる。

オーバーライドパラメータは、原因結果機能ブロックの正常なロジックが使用されていない時を特定するために、原因結果機能ブロックによって使用され又は出力され得る。これは、例えば、原因マスクパラメータが設定されたとき、強制正常又は強制結果パラメータが設定されたとき等に現れる。このパラメータは、例えば、ユーザ、例えばオペレータに、状態又はアラーム情報を提供するために、ユーザインターフェイスで使用される。もちろん、原因結果機能ブロックは、不良状態、強制された結果若しくは強制された正常状態、一又はそれ以上の結果上のトリップされた状態を示すアラーム等、所望のアラーム信号を提供し得る。以下に記述されるように、上記と同様又はここに記載したものに加えて、他の所望のアラームが使用され得る。

上記から理解されるように、ここで記載した原因結果機能ブロックの使用は、公知のフォーマットを有する機能ブロックを生成するのを容易にし、従って、一度生成されると、適正な動作を提供するように適当なマトリックス及びパラメータの設定でプログラムされることを必要とするのみある。機能ブロックプログラミング環境内の原因結果機能ブロックの実装は、原因結果機能ブロックが生成され他の機能ブロックに公知又は所望の方法で通信可能に接続され得るので容易である。同様に、原因結果機能ブロックは、それがプログラミング環境及びそれに送られる構成パラメータ内でどのように接続されるかという関係内で容易にデバグされ得ることだけを典型的に必要とするので、原因結果機能ブロックのデバグも他のプログラミング言語で生成される原因結果マトリックスロジックよりも一層容易となる。更に、原因結果機能ブロックの文書化は、それが個々のパラメータ及びそれに提供されるマトリックスの設定によってのみ変更される標準の文書を有する典型的な機能ブロックであるので、容易である。

図１では、原因結果機能ブロック９２及び９４が、ＡＩ、ＤＩ、選択機能ブロック又は他の機能ブロックからの入力を受け取るように記載されているけれども、原因入力は、他のタイプの機能ブロックから来るか、又はプロセスプラント１０内の他の信号として生成される。更に、原因結果機能ブロック９２及び９４の結果出力は、ＡＯ、ＤＯ又は他の機能ブロック等の出力機能ブロックに接続されているように画かれているが、これらの出力は、シーケンサ機能ブロック、ステージング機能ブロック等の他のどのような所望のタイプの機能ブロックにも接続され得、又はプロセスプラント１０内の他のアプリケーション若しくはプログラミング環境に直接接続され得る。同様に、ここに記載されているロジックは、機能ブロックプログラミングパラダイムを使用して実行されるが、同様のロジックが他のプログラミング環境に提供され得、ここで使用されている機能ブロックと同様に考えられる。更に、ここに記載されている原因結果機能ブロックは、プロセスプラント又はプロセス制御環境の安全システムでの使用のために記載されているけれども、これらの又は同様の機能ブロックは、標準のプロセス制御環境で、又は安全システム内での使用より他の所望の使用のために、使用され得る。

また、原因結果機能ブロックは状態マシンを含むように記載されているが、これらの状態マシンは、ハードウエア又は何れかのプログラミング言語で書かれたソフトウエアを介する等によりどのような形式でも実装され得ることが理解されるであろう。このような状態マシンであるためには、ソフトウエアプログラム、ルーチン、オブジェクトなどの要素は、機能ブロックを機能ブロックの出力によって表されるようにここで説明され又は定義されたような状態間を遷移するようにし、それによって安全又はトリップした状態から正常若しくは非トリップ状態へ又はその逆への結果出力の遷移を引き起こすことが必要である。

実装されたとき、マルチプレクサ、ブロック、状態マシン、信号接続などのここで記載したような要素の何れもが、磁気ディスク、レーザ若しくは光ディスク、又は他の記録媒体、コンピュータ又はプロセッサ内のＲＡＭ若しくはＲＯＭ等、何れのコンピュータ読み取り可能なメモリにでも格納されているソフトウエアに実装され得る。ここに記載した信号及び信号ラインは、実際のワイヤ、データレジスタ、メモリの位置など、何れの形状も採り得る。このソフトウエアは、一般的な目的のコンピュータ又はプロセッサで実行され得るアプリケーションソフトウエア、例えば特定用途向け集積回路（ＡＳＩＣ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、又は他のファームウエアデバイスに焼き付けたハードコードされたソフトウエアを含む、何れの形状をも採り得る。同様に、このソフトウエアは、ユーザ、プロセスプラント、オペレータワークステーション、コントローラ、ロジックソルバ又は他のどのようなコンピューティングデバイスにも、例えばコンピュータ読み取り可能なディスク又は他の可搬のコンピュータ格納媒体、又は電話回線、インターネット、ワールドワイドウエブ、どのようなローカルエリアネットワーク若しくはワイドエリアネットワーク等を含む何れの公知の又は所望の供給方法を使用して、供給され得る（この供給は、可搬な格納媒体を介するソフトウエアの提供と同じ又は交換可能であると見られている）。更に、このソフトウエアは、変調若しくは暗号化なしに、又は通信チャネル上を伝送される前に変調伝送波及び／又は暗号化技術を使用して変調され若しくは暗号化されて、特設提供され得る。

もちろん、ここに記載されている原因結果機能ブロックは、どのような外部プロセス制御通信プロトコル（とりわけ、Ｆｉｅｌｄｂｕｓプロトコル又はＤｅｌｔａＶプロトコル）を使用しても実装され得、そして、Ｆｉｅｌｄｂｕｓプロトコルによって特に特定され及びサポートされる異なる機能ブロックと同様の又は同じどのような機能ブロックをも含むどのような機能ブロックのタイプとも通信するのに使用され得る。更に、その一実施形態に於ける原因結果機能ブロックはＦｉｅｌｄｂｕｓの「機能ブロック」として記載されているが、ここでの「機能ブロック」という表現の使用は、Ｆｉｅｌｄｂｕｓプロトコルが何を機能ブロックとして特定するかに限定されるのではなく、他の何れのブロック、プログラム、ハードウエア、ファームウエア等、幾つかの制御ルーチン機能を実装するのに使用される又は他のこのような機能ブロックへの幾つかのプロセス情報又はデータを実装するのに使用され得る制御システム及び／又は通信プロトコルのどのようなタイプのエンティティをも含むことに注意しなければならない。このように、機能ブロックはオブジェクト指向プログラミング環境内のオブジェクトの形式を典型的に採るが、これは、必ずではないが、所望のプログラミング構造又はパラダイムを使用して、プロセスプラント又は制御環境内の特定の制御（入力及び出力を含む）機能を実行するのに使用される他の論理ユニットであり得る。

本発明について特定の実施形態を参照して記述したが、それらは例示のみを意図し、本発明を限定するものではなく、本発明の精神及び範囲から逸脱することなく、開示された実施形態に為され得る変更、付加又は削除が当業者に明らかであろう。

図１はプロセス制御システムに統合され、プロセスプラント内の安全装置に関連する制御アクティビティを実行するための一又はそれ以上の原因結果機能ブロックを使用する安全システムを有する例示的なプロセスプラントのブロックダイヤグラムである。 図２は、図１の原因結果機能ブロックの一つのブロックダイヤグラムである。 図３は、例示の原因結果マトリックスの図式的な描写である。 図４は、図２の原因結果機能ブロックに於ける各状態マシンに潜在的に関連する状態の集合を表す状態ダイヤグラムである。

符号の説明

１０ プロセスプラント
１２ プロセス制御システム
１４ 安全システム
１６ ユーザインターフェイス
１８ プロセス制御／安全制御ノード
２０ プロセス制御／安全制御ノード
２１ 構成データベース
２２ バス
２４ プロセスコントローラ
２６ プロセスコントローラ
２８ プロセス制御システムＩ／Ｏデバイス
３０ プロセス制御システムＩ／Ｏデバイス
３２ プロセス制御システムＩ／Ｏデバイス
３４ プロセス制御システムＩ／Ｏデバイス
３６ プロセス制御システムＩ／Ｏデバイス
４０ コントローラフィールドデバイス
４２ フィールドデバイス
５０ 安全システムロジックソルバ
５２ 安全システムロジックソルバ
５４ 安全システムロジックソルバ
５６ 安全システムロジックソルバ
５７ プロセッサ
５８ 安全ロジックモジュール
６０ 安全システムフィールドデバイス
６２ 安全システムフィールドデバイス
７０ ＭＰＤ
７２ ＭＰＤ
８０ 構成アプリケーション
８２ 表示アプリケーション
９２ 原因結果機能ブロック
９４ 原因結果機能ブロック
９６ 入力機能ブロック
９８ 出力機能ブロック
１００ 原因入力
１０２ マルチプレクサ
１０５ 原因結果マトリックス
１０６ 入力
１０８ トリップ信号ライン
１１０ トリップ信号ライン
１１２ 状態マシン
１１４ 状態マシン
１１６ 結果出力
１２０ ライン
１３０ 状態ダイヤグラム
１３２ トリップ状態
１３４ 状態
１３６ リセット可能状態
１３８ スタート許容状態待ち
１４０ 正常動作状態
１４２ トリップ開始−遅延状態

Claims (47)

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. 請求項２５記載の制御システムであって、前記状態入力の一つは、前記状態マシンの一つが、関連する結果出力が正常値に強制される第２の状態に入るべきことを表すスタート許容入力であり、前記一又はそれ以上の追加の状態の一つは、前記状態マシンの一つがスタート許容入力でスタート許容信号を待つスタート状態である、制御システム。
29. 請求項２５記載の制御システムであって、前記状態マシンの一つは、前記第２の状態から第１の状態へ移行するときに更なる状態に入るように構成され、該更なる状態は、前記状態入力の一つに、前記第１の状態に入る前の予め決められた時間待たせる、制御システム。
30. 請求項２５記載の制御システムであって、前記状態マシンの一つは、前記状態入力の一つが位置している特定の状態を表す更なる出力を生成する、制御システム。
31. 請求項２２記載の制御システムであって、前記原因信号の一つは値及び状態を含み、前記マルチプレクサは、前記一又はそれ以上のトリップ信号を生成するために、前記原因結果マトリックスロジックに従って前記原因信号の一つの状態及び値を使用するように構成されている状態ロジックを含んでいる、制御システム。
32. 請求項３１記載の制御システムであって、前記マルチプレクサの前記状態ロジックは、前記原因信号の一つの状態が不良であるときに、前記原因結果マトリックスロジックに従って一又はそれ以上のトリップ信号の一つを生成する、制御システム。
33. 請求項３１記載の制御システムであって、前記マルチプレクサの前記状態ロジックは、その状態が良好であるその原因信号の一つの最後の値を使用して、前記原因結果マトリックスロジックに従って一又はそれ以上のトリップ信号の一つを生成する、制御システム。
34. 請求項２２記載の制御システムであって、前記状態マシンの一つは、関連する結果出力をトリップした値に強制する前記状態マシンの一つをもたらす第１の原因入力を表す更なる出力を生成する、制御システム。
35. 請求項２２記載の制御システムであって、前記制御ブロックは第１の機能ブロックであり、前記原因入力又は結果出力を介して前記第１の機能ブロックに通信可能に接続された追加の機能ブロックを更に有している、制御システム。
36. プロセスプラント内で使用される一又はそれ以上の結果信号に、正常値とトリップした値との間でフィールドデバイスを制御するように強制する方法であって、該方法は、
    それぞれ検出された原因状態の存在又は不存在を表す、前記プロセスプラント内からの原因信号の集合を受け取るステップと、
    前記原因信号のそれぞれを前記結果信号に関連づける原因結果マトリックスロジックを格納するステップと、
    前記原因信号に基づいてトリップ信号の集合を生成するために、前記原因結果マトリックスロジックを使用するステップと、
    前記トリップ信号のそれぞれを、それぞれ前記結果信号の異なる一つに関連する状態マシンのそれぞれに別々に配送するステップと、
    前記トリップ信号に応答して、正常値にあるか又はトリップした値となるよに前記結果信号を生成するように前記状態マシンを使用するステップと
    を包含している方法。
37. 請求項３６記載の方法であって、前記状態マシンを使用するステップは、前記トリップ信号の一つに基づいて前記状態マシンの一つが第１の状態にあるときに前記結果信号の一つを前記トリップした値に強制することと、前記トリップ信号の一つに基づいて前記状態マシンの一つが第２の状態にあるときに前記結果信号の一つを正常な値に強制することとを含み、前記一又はそれ以上の状態信号の値に基づいて前記第１の状態から前記第２の状態に移行するときに、前記状態入力の一つに一又はそれ以上の状態信号を提供することと、一又はそれ以上の追加の状態を介して状態マシンの一つをサイクルさせることとを更に含む、方法。
38. 請求項３７記載の方法であって、前記一又はそれ以上の状態信号を提供することは、前記結果信号の一つのリセットの許容を特定するリセット許容状態信号を提供することを含み、前記一又はそれ以上の追加の状態を介して状態マシンの一つをサイクルさせることは、前記状態マシンの一つが、該状態マシンの一つがリセット許容信号を待つリセット状態に入るようにすることを含んでいる、方法。
39. 請求項３７記載の方法であって、前記一又はそれ以上の状態信号を提供することは、前記結果信号の一つをリセットするコマンドを特定するリセット信号を提供することを含み、前記一又はそれ以上の追加の状態を介して状態マシンの一つをサイクルさせることは、前記状態マシンの一つが、該状態マシンの一つがリセット信号を待つリセット状態に入るようにすることを含んでいる、方法。
40. 請求項３７記載の方法であって、前記一又はそれ以上の状態信号を提供することは、前記結果信号の一つによって実行されるプロセスのスタートの許容を特定するスタート許容信号を提供することを含み、前記一又はそれ以上の追加の状態を介して状態マシンの一つをサイクルさせることは、前記状態マシンの一つが、該状態マシンの一つがスタート許容信号を待つスタート状態に入るようにすることを含んでいる、方法。
41. 請求項３７記載の方法であって、前記状態マシンの一つが位置する特定の状態を表す出力信号を生成することを含んでいる、方法。
42. 請求項３６記載の方法であって、前記状態マシンを使用するステップは、前記トリップ信号の一つに基づいて前記状態マシンの一つが第１の状態にあるときに前記結果信号の一つを前記トリップした値に強制することと、前記トリップ信号の一つに基づいて前記状態マシンの一つが第２の状態にあるときに前記結果信号の一つを正常な値に強制することとを含み、前記第２の状態から前記第１の状態に移行する第３の状態を介して状態マシンの一つをサイクルさせることとを更に含み、前記第３の状態は、前記状態マシンの一つに、前記第１の状態に入る前の予め決められた時間の期間待たせる、方法。
43. 請求項３６記載の方法であって、前記原因信号に基づいてトリップ信号の集合を生成するために、前記原因結果マトリックスロジックを使用するステップが、前記トリップ信号を生成するために、前記原因結果マトリックスロジックに従って前記原因信号の一つの値を使用することを含んでいる、方法。
44. 請求項３６記載の方法であって、前記前記プロセスプラント内からの原因信号の集合を受け取るステップは、前記原因信号の少なくとも一つに関連する値及び状態を受け取ることを含み、前記原因信号に基づいて前記トリップ信号の集合を生成するために、前記原因結果マトリックスロジックを使用するステップが、前記トリップ信号を生成するために、前記原因結果マトリックスロジックに従って前記原因信号の少なくとも一つの値及び状態を使用することを含んでいる、方法。
45. 請求項４４記載の方法であって、前記トリップ信号を生成するために、前記原因結果マトリックスロジックに従って前記原因信号の少なくとも一つの値及び状態を使用することは、前記原因信号の少なくとも一つの状態が不良であるときに、前記原因結果マトリックスロジック従って前記一又はそれ以上のトリップ信号を生成することを含んでいる、方法。
46. 請求項４４記載の方法であって、前記トリップ信号を生成するために、前記原因結果マトリックスロジックに従って前記原因信号の少なくとも一つの値及び状態を使用することは、その状態が良好であるその原因信号の少なくとも一つの最後の値を使用して、前記原因結果マトリックスロジックに従って前記一又はそれ以上のトリップ信号を生成することを含んでいる、方法。
47. 請求項３６記載の方法であって、結果出力信号の一つをトリップした値に強制する前記状態マシンの一つをもたらす第１の原因信号を表す更なる出力を提供することを包含している、方法。
    

Images