(57)【特許請求の範囲】
【請求項１】
プロセス制御システムにおいてＨＡＲＴ（Highway Addressable Remote Transducer Protocol）デバイスに関するアラートメッセージを生成する方法であって、
前記ＨＡＲＴデバイスに関連する複数のデバイス状態のうち当てはまる少なくとも１つを検出するステップと、
検出された前記ＨＡＲＴデバイスに関連するデバイス状態を、１つ以上のものがプロセス制御システム内の複数のＦｉｅｌｄｂｕｓデバイスが生成するＦｉｅｌｄｂｕｓアラートメッセージに含まれている複数のデバイスステータス状態のうちの１つに関連付けするステップと、
前記ＨＡＲＴデバイスに関連する複数のデバイス状態のうちの１つと、前記複数のデバイスステータス状態のうちの１つとに関連付けられた情報を含むＨＡＲＴデバイスに関するアラートメッセージを生成するステップとを有し、
前記複数のデバイスステータス状態は、前記ＨＡＲＴデバイスの故障に関連するステータス状態、前記ＨＡＲＴデバイスの保守に関連するステータス状態、及び前記ＨＡＲＴデバイスに関する勧告ステータスに関連するステータス状態を含む方法。
【請求項２】
前記ＨＡＲＴデバイスに関連する複数のデバイス状態は、デバイス機能不良状態、追加ステータス使用可能状態、コンフィギュレーション変更状態、ＰＶ飽和状態、ＰＶ固定状態、ＰＶリミット範囲外状態、非ＰＶリミット範囲外状態、及びコールドスタート状態を含む、請求項１記載の方法。
【請求項３】
検出された前記ＨＡＲＴデバイスに関連するデバイス状態を、複数の前記デバイスステータス状態のうちの１つに関連付けする前記ステップでは、複数のデバイスステータス状態のうちの少なくとも２つの異なるデバイスステータス状態に複数のＨＡＲＴステータス状態が夫々関連付けられた表を用いて関連付けしている、請求項１記載の方法。
【請求項４】
検出されたデバイス状態を、前記故障に関連するステータス状態、前記保守に関連するステータス状態、及び前記勧告に関連するステータス状態のうちのいずれかに関連付けするために前記表を用いるステップを有している、請求項３記載の方法。
【請求項５】
検出された前記ＨＡＲＴデバイスに関連する前記デバイス状態を、複数の前記デバイスステータス状態のうちの１つに関連付けする前記ステップは、前記検出したデバイス状態が追加ステータス使用可能状態である場合、前記検出したデバイス状態を前記勧告ステータス状態に関連付けするステップを有している、請求項１記載の方法。
【請求項６】
前記検出されたデバイス状態に応じて表示される第１表示部と共に、複数の前記デバイスステータス状態のうちの一つのデバイスステータス状態に応じて表示される第２表示部を表示するステップをさらに有している、請求項１記載の方法。
【請求項７】
ＨＡＲＴ（Highway Addressable Remote Transducer Protocol）に関するアラートメッセージを生成するプロセッサを有するプロセス制御システムにおいて利用されるシステムであって、
コンピュータで読取り可能な媒体と、
ＨＡＲＴデバイスにて、それに関連する複数のデバイスステータス状態のうち当てはまる１つを検出するために前記プロセッサにより実行されるように構成され、且つ前記コンピュータで読取り可能な媒体に格納された第一のルーチンと、
検出された前記ＨＡＲＴデバイスに関連する複数のデバイス状態と、１つ以上のものがプロセス制御システム内の複数のＦｉｅｌｄｂｕｓデバイスが生成するＦｉｅｌｄｂｕｓアラートメッセージに含まれている複数のデバイスステータス状態との関連付けが前記プロセッサにより実行されるように構成され、且つ前記コンピュータ読取り可能媒体に格納される第二のルーチンと、
検出された前記ＨＡＲＴデバイスに関連するデバイス状態、及び前記複数のデバイスステータス状態のうちの１つに関連付けられた情報を含む前記ＨＡＲＴデバイスに関するアラートメッセージの生成が前記プロセッサにより実行されるように構成され、且つ前記コンピュータ読取り可能媒体に格納された第三のルーチンとを備え、
複数のデバイス状態は、前記ＨＡＲＴデバイスの故障に関連するステータス状態、前記ＨＡＲＴデバイスの保守に関連するステータス状態、及び前記ＨＡＲＴデバイスに関する勧告に関連するステータス状態を含むシステム。
【請求項８】
前記ＨＡＲＴデバイスに関するデバイス状態は、デバイス機能不良状態、追加ステータス使用可能状態、コンフィギュレーション変更状態、ＰＶ飽和状態、ＰＶ固定状態、ＰＶリミット範囲外状態、非ＰＶリミット範囲外状態、及びコールドスタート状態を含む、請求項７記載の方法。
【請求項９】
前記第二のルーチンは、複数のデバイスステータス状態のうち少なくとも２つの異なるデバイスステータス状態に複数のＨＡＲＴステータス状態が夫々関連付けられた表を用いて関連付けするように構成されている、請求項７記載のシステム。
【請求項１０】
前記第二のルーチンは、前記故障に関連するステータス状態、前記保守に関連するステータス状態、及び前記勧告に関連するステータス状態のうちのいずれかに前記検出したデバイス状態を対応付けるために前記表を利用するように構成されている、請求項９記載のシステム。
【請求項１１】
前記第二のルーチンは、前記検出したデバイス状態が追加ステータス使用可能状態である場合、前記検出したデバイス状態を前記勧告ステータス状態に関連付けするようにさらに構成されている、請求項７記載のシステム。
【請求項１２】
ユーザインターフェイス表示画面を有するプロセス制御システムにおいてフィールドデバイスアラートメッセージを報告する方法であって、
フィールドデバイス内の状態を検出するステップと、
検出されたデバイス状態を、各々が異なるレベルの重要度を表し、また各々が相まって複数のデバイスステータス状態を成し、更に１つ以上のものがプロセス制御システム内の複数のＦｉｅｌｄｂｕｓデバイスが生成するＦｉｅｌｄｂｕｓアラートメッセージに含まれている、デバイスの故障に関連するステータス状態、デバイスの保守に関連するステータス状態、及び勧告に関連するステータス状態のうちの一つに関連付けするステップと、
前記検出されたデバイス状態を、前記デバイス故障ステータス状態、前記デバイス保守ステータス状態、および前記勧告ステータス状態のうちの関連する一つと共に、前記ユーザインターフェイス表示画面を介して報告するステップとを有している、方法。
【請求項１３】
前記フィールドデバイス内の状態を検出するステップは、ＦｉｅｌｄｂｕｓデバイスおよびＨＡＲＴ（Highway Addressable Remote Transducer）デバイスのうちの１つの内の状態を検出するステップを有している、請求項１２記載の方法。
【請求項１４】
前記デバイス故障ステータス状態、前記デバイス保守ステータス状態、および前記勧告ステータス状態のうちの一つを前記検出されたデバイス状態に関連付けする前記ステップは、前記検出されたデバイス状態を前記デバイス故障ステータス状態、前記デバイス保守ステータス状態、および前記勧告ステータス状態のうちの一つにマッピングするために表を用いるステップを有している、請求項１２記載の方法。
【請求項１５】
前記検出されたデバイス状態を前記デバイス故障ステータス状態、前記デバイス保守ステータス状態、および前記勧告ステータス状態のうちの一つにマッピングするために前記表を用いる前記ステップは、前記デバイスおよび前記プロセス制御システムに通信可能に接続されているコンピュータのうちの一つに格納された表を利用するステップを有している、請求項１４記載の方法。
【請求項１６】
プロセス制御システム内のアラートメッセージを生成する方法であって、
標準ＨＡＲＴ（Highway Addressable Remote Transducer Protocol）のデバイスステータス状態を含む第１の複数の可能性のあるデバイスステータス状態の中の各デバイスステータス状態と、少なくともデバイスの故障を示すステータス状態、デバイスに保守が必要なことを示すステータス状態、及び勧告を示すステータス状態を含み、プロセス制御システム内の複数のＦｉｅｌｄｂｕｓデバイスが生成するＦｉｅｌｄｂｕｓアラートメッセージに含まれている複数の第２の可能性のあるデバイスステータス状態の中の１つのデバイスステータス状態とを関連付けするステップと、
プロセス制御システム内のＨＡＲＴデバイスから、前記第１の複数の可能性のあるデバイスステータス状態のうちの１つのデバイスステータス状態であるＨＡＲＴのデバイスステータス状態を示すデバイスステータスデータを受け取るステップと、
ＨＡＲＴのデバイスステータス状態に関連する第２の複数の可能性のあるデバイスステータス状態から１つのデバイスステータス状態を検出するステップと、
前記ＨＡＲＴのデバイスステータス状態に関連付けられた前記第２の複数の可能性のあるデバイスステータス状態から提供されるＨＡＲＴデバイスを示すデータ、ＨＡＲＴのデバイスステータス状態を示すデータ、及び前記デバイスステータス状態を示すデータが含まれる前記アラートメッセージを生成するステップとを有している、方法。
【請求項１７】
前記アラートメッセージの生成は、Ｆｉｅｌｄｂｕｓに関するアラートメッセージの型式でアラートメッセージを生成するようになっている、請求項１６記載の方法。
【請求項１８】
前記複数の第２の可能性のデバイスステータス状態のうちの１つのデバイスステータス状態と、前記複数の第１の可能性のデバイスステータス状態のうちの各デバイスステータス状態とを関連付けられており、
デバイスの機能不良は、前記デバイス故障を示すステータス状態に関連付けられ、
追加ステータス使用可能は、前記勧告を示すステータス状態に関連付けられ、
コンフィギュレーション変更は、前記勧告を示すステータス状態に関連付けられ、
ＰＶ飽和状態は、前記デバイスに保守が必要なことを示すステータス状態に関連付けられ、
ＰＶ固定状態は、前記デバイスに保守が必要なことを示すステータス状態に関連付けられ、
ＰＶリミット範囲外状態は、前記デバイスに保守が必要なことを示すステータス状態に関連付けられ、
非ＰＶリミット範囲外状態は、前記デバイスに保守が必要なことを示すステータス状態に関連付けられ、
コールドスタートは、勧告を示すステータス状態関連付けられている、請求項１６記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にプロセス制御システムに関するものであり、より詳細にはプロセス制御システムにおけるＨＡＲＴデバイス用のアラートまたはアラームの機能強化に関するものである。
【背景技術】
【０００２】
本出願は、２００１年５月２１日に出願された、表題が「プロセス制御システムにおけるＦｉｅｌｄｂｕｓデバイス用機能強化型アラート」である米国特許出願番号第09/861,790号の一部継続出願である。また、米国特許出願番号第09/861,790号は、２００１年３月１日に出願された、表題が「プロセス制御システムにおける資産活用エキスパート」である米国特許仮出願番号第60/273,164号の出願日の恩恵を主張するものである。
【０００３】
化学プロセス、石油プロセス、または他のプロセスにおいて利用されるプロセス制御システムは、アナログバス、デジタルバス、またはアナログとデジタルを組み合わせたバスを介して、少なくとも一つのホストワークステーションまたはオペレータワークステーションと一または複数のフィールドデバイスとに通信可能に接続された一つまたは複数の中央集中型プロセスコントローラを備えていることが一般的である。フィールドデバイスは、たとえば、バルブ、バルブポジショナ、スイッチ、およびトランスミッタ（たとえば、温度センサ、圧力センサ、および流量センサ）などであり、バルブの開閉や、プロセスパラメータの測定の如きプロセス内の機能を実行する。また、プロセスコントローラは、フィールドデバイスにより測定されたプロセスの測定結果を示す信号および／またはそのフィールドデバイスに関する情報を受信し、この情報を用いて制御ルーチンを実行し、次いで、制御信号を発生する。その信号は、プロセス動作を制御するために、上述のバスまたは他の通信回線を通って、フィールドデバイスに送信される。これらのフィールドデバイスおよびコントローラからの情報は、オペレータワークステーションにより実行される一つまたは複数のアプリケーションに提供されてもよく、その結果、たとえばプロセスの現行状態の閲覧や、プロセス動作の修正などの如き、プロセスに関する所望の機能をオペレータが実行することができるようになる。
【０００４】
フィッシャーローズマウント社から販売されているＤｅｌｔａＶプロセス制御システムは、コントローラまたはさまざまなフィールドデバイス内に設置または搭載された機能ブロックを利用して制御動作を実行する。これらのコントローラおよび、場合によっては、フィールドデバイスは一または複数の機能ブロックを格納・実行することが可能である。各機能ブロックは、他の機能ブロックからの入力を受信し、および／または出力を他の機能ブロック（同一のデバイス内か、または異なるデバイス内の機能ブロック）に提供するとともに、プロセスパラメータの測定もしくは検出、デバイス制御、または比例微分積分（ＰＩＤ）制御ルーチンの実行のような制御動作の実行の如きなんらかのプロセス制御動作を実行する。プロセス制御システム内のさまざまな機能ブロックは、一または複数のプロセス制御ループを形成するために、（たとえば、単一デバイス内で、またはバスを利用して）相互に通信するように構築されており、プロセス制御ループの個々の動作は、プロセス制御システム全体に亘って分散されてもよい。また、公知のように、機能ブロックに加えて、ＦＯＵＮＤＡＴＩＯＮ  Ｆｉｅｌｄｂｕｓ（以下、Ｆｉｅｌｄｂｕｓと呼ぶ）デバイスは、該デバイスのさまざまな能力を表す一または複数の関連するリソースブロックおよび／またはトランデューサブロックを備えている。たとえば、二つの温度感知エレメントを備えたＦｉｅｌｄｂｕｓ温度トランスミッタは、平均温度の値を提供するために、二つのトランデューサブロック（すなわち、各感知エレメントに対して一つブロック）と、二つの感知エレメントの出力を（該トランスデューサブロックを介して）読み取る一つの機能ブロックとを備えている。
【０００５】
一般的に、機能ブロック、トランスデューサブロック、およびリソースブロック、またはこれらの機能ブロックが実装されたデバイスは、プロセス制御ループ、ユニット、デバイスの内において発生するエラー、故障、または問題を検出し、プロセス制御システム内またはプロセス制御システムの制御ループ内に望ましくない状態が存在することを、オペレータワークステーションまたはその他のユーザインターフェイスのオペレータに通知するアラームメッセージまたはアラートメッセージの如き信号を、（Ｆｉｅｌｄｂｕｓデバイスの場合のように自動的に、またはＨＡＲＴデバイスの場合のようにポーリングに応答して、）送信するように構成されている。そのようなアラームは、たとえば、機能ブロックが通信不能であること、範囲外の入力または出力を機能ブロックが受信または生成していること、または機能ブロックが障害またはその他の望ましくない状態なっていることなどを指摘しうる。現行のアラーム処理および表示システムにおいては、たとえばオペレータインターフェイス／ワークステーションで実行されるアプリケーションは、プロセスオペレーションに関するプロセスアラームを有するメッセージを受信し、これらのプロセスアラームを整合性のある管理可能な方法で表示し、それにより、オペレータがある体系だった論理的な方法でアラームを処理することができるように構築されうる。そのようなオペレータインターフェイスシステムが、「アラーム優先順位調節を含むプロセス制御システム」という表題を有する米国特許番号第5,768,119号において記載されており、本明細書においてその特許を引用することにより援用する。
【０００６】
従来、慣用フィールドデバイスは、プロセス制御システム内で利用され、たとえば、４〜２０ミリアンペア（ｍＡ）信号の如きアナログ信号を、アナログバスまたはアナログ回線を利用して、プロセスコントローラへの送信およびプロセスコントローラからの受信を行っていた。しかしながら、これらの４〜２０ミリアンペア信号には本質的に限界がある。その理由は、４〜２０ミリアンペア信号は、デバイスにより行われるプロセス測定中または実行時間中においてそのデバイスの動作を制御するために必要な、コントローラにより生成されるプロセス制御信号を示すのみであるからである。その結果、４〜２０ミリアンペアデバイスでは、そのデバイス自体の動作機能または動作状況に関するアラームまたはアラートを生成することは可能ではない。結局のところ、プロセス制御システム内においてデバイスの状態または状況に関連するアラームを利用することは一般的に可能ではなかった。
【０００７】
ここ数年、マイクロプロセッサとメモリとを備えたスマートフィールドデバイスがプロセス制御産業において普及してきている。また、さまざまな製造会社により製造されたスマートフィールドデバイスを同一のプロセス制御ネットワーク内で一緒に用いることを可能にするために、Ｆｉｅｌｄｂｕｓプロトコル、ＨＡＲＴ（登録商標）プロトコル、ＰＲＯＦＩＢＵＳ（登録商標）プロトコル、ＷＯＲＬＤＦＩＰ（登録商標）プロトコル、Ｄｅｖｉｃｅ−Ｎｅｔ（登録商標）プロトコル、およびＣＡＮプロトコルの如き多くのオープンスマートデバイス通信プロトコルが開発されてきている。スマートフィールドデバイスは、プロセス内において主機能を実行することに加えて、そのデバイスに関連するデータを格納し、コントローラおよび／または他のデバイスとデジタル形式またはデジタルとアナログとを組み合わせた形式で通信し、自己校正、識別、診断などの如き二次的機能を実行することが可能である。重要なことには、これらのプロトコル（ＨＡＲＴプロトコルおよびＦｉｅｌｄｂｕｓプロトコル）の少なくともいくつかに準拠するデバイスは、そのデバイス自体の問題を検出することが可能であり、検出した問題を表すアラームメッセージまたはアラートメッセージを生成してプロセス制御システムの動作に責任を有する適切なオペレータ、保守作業員、または技術者に送信することが可能である。
【０００８】
たとえば、Ｆｉｅｌｄｂｕｓデバイスは、周知のメッセージ形式を用いてアラーム情報またはアラート情報を通信する。Ｆｉｅｌｄｂｕｓデバイスアラームメッセージは、ブロック識別領域と、相対識別別領域と、サブコード領域と、浮動小数点数領域とを有している。一般的にいえば、Ｆｉｅｌｄｂｕｓデバイスアラームメッセージ内に設けられたこれらの領域は、詳細レベルが上昇する方向で、アラームメッセージの発生源と、その発生源により伝達されるアラームまたはアラートの性格とを明確に示す。具体的には、Ｆｉｅｌｄｂｕｓデバイスアラームメッセージ内のブロック識別領域は、アラームメッセージが発生したＦｉｅｌｄｂｕｓデバイス内のブロックを特定する。したがって、コントローラ、ワークステーションなどは、Ｆｉｅｌｄｂｕｓデバイスアラームメッセージ内のブロック識別領域を利用することにより、そのアラームメッセージがいずれのブロックにより生成されたのかを判別するとともに、そのアラームメッセージが機能ブロック、リソースブロック、またはトランスデューサブロックにより生成されたのか否かを判別する。
【０００９】
Ｆｉｅｌｄｂｕｓデバイスアラームメッセージ内の相対識別領域は、そのアラームメッセージの発生の原因になった特定ブロック内（たとえば、機能ブロック、リソースブロック、またはトランスデューサブロック）のパラメータを特定する。所与のブロックは、相対識別領域内の異なる数値を利用して互いに区別することができかつブロックに付属する二つ以上のパラメータ有しうる。たとえば、機能ブロックは、複数の入出力を有しており、その各々は異なる相対識別領域値に一意に関連付けされている。
【００１０】
サブコード領域は、一般的に、デバイスにより伝送されるアラームメッセージの性格を表す、製造業者により予め決められた数値を提供する。たとえば、センサ読取り値が正常動作範囲外にあること、完全にセンサが故障してしまっていること、またはＦｉｅｌｄｂｕｓデバイス内で発生しうるその他の異常を示すためにサブコード領域を利用することが可能である。
【００１１】
Ｆｉｅｌｄｂｕｓデバイスにおいて、サブコード領域はデバイスおよび製造業者により固有のものであるため、所与のＦｉｅｌｄｂｕｓデバイスの特定の一つのブロック内における異なるタイプの故障が一つのアラームメッセージ内に異なるサブコード領域値を送ることもあれば、異なる製造業者により製造された異なるデバイスおよび／または同様なデバイスの内の同一のタイプの故障が一つのアラームメッセージ内に異なるサブコード領域値を送ることもある。ユーザがサブコード領域を構築することは可能ではなく、また特定のタイプの故障に対するサブコード領域値がデバイスおよび／または製造業者により特有なものであるので、製造業者は、サブコード値が故障タイプに翻訳されうるように、サブコードとそのコードに対応する故障タイプとの一覧を提供していることが一般的である。
【００１２】
浮動小数点領域は、アラームメッセージ内で報告されるサブコードに関連付けされた浮動小数点数を有していることが一般的である。したがって、特定のトランスデューサブロック内のセンサ読取り値が正常動作範囲外にあることがサブコード領域により示された場合には、浮動小数点領域は、実際の範囲外センサ読取り値を表す浮動小数点値を含みうる。
【００１３】
一般的に知られているように、Ｆｉｅｌｄｂｕｓデバイス内のブロック（すなわち、トランスデューサブロック、リソースブロック、および機能ブロック）は、アラーム通知または報告パラメータＢＬＯＣＫ＿ＡＬＭと、アラーム記述または状態パラメータＢＬＯＣＫ＿ＥＲＲとを提供することが可能である。一般的にいえば、ＢＬＯＣＫ＿ＡＬＭは、Ｆｉｅｌｄｂｕｓデバイス内にアラーム状態が存在することをそのＦｉｅｌｄｂｕｓデバイスがコントローラおよびオペレータワークステーションを利用してシステムユーザまたはシステムオペレータへ報告することを可能にする。一方、ＢＬＯＣＫ＿ＥＲＲは、ＢＬＯＣＫ＿ＡＬＭを利用してアクティブアラーム状態を報告しているＦｉｅｌｄｂｕｓデバイスが、異なるかつ発生しうる１６のアラーム状態またはアラート状態のうちのいずれの状態を検出したのかを明確にする。公知のように、ＢＬＯＣＫ＿ＥＲＲは１６ビットを有しており、その各々は、特定のＦｉｅｌｄｂｕｓデバイス内の特定のブロックに関連して発生することが可能でありかつ事前定義されている、発生しうる１６のアラーム状態またはアラート状態のうちの一つを表している。これら事前定義された１６のアラーム状態またはアラート状態は、デバイスは早急に保守が必要状態、デバイスは今すぐ保守が必要状態、入力不良状態、出力不良状態、メモリ不良状態、静的データ損失状態、その他状態などを有している。事前定義された検出可能な１６のアラーム状態またはアラート状態に加えて、Ｆｉｅｌｄｂｕｓデバイス製造業者の中には、他の状態を検出するための診断を含むＦｉｅｌｄｂｕｓデバイスを提供する製造業者もいる。たとえば、あるＦｉｅｌｄｂｕｓデバイスは、バルブラインの詰まりまたはバルブドライブ故障を検出することが可能であり、移動アラームなどを生成することが可能であり、ＢＬＯＣＫ＿ＥＲＲパラメータの「その他」用のビットを設定するとともにＢＬＯＣＫ＿ＡＬＭパラメータを利用してその他の状態を報告することにより、これらその他のタイプの状態を報告することが可能である。これに代えてまたはこれに加えて、Ｆｉｅｌｄｂｕｓデバイス製造業者の中には、これらその他のタイプの状態（すなわち、１６の事前に定義された状態のうちの一つではない状態）を報告するために、ベンダ指定のアラームおよび／またはパラメータを利用する業者がいる。該ベンダ指定のアラームおよび／またはパラメータはデバイス製造業者により幅広く異なりうる。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
残念なことには、事前に定義された１６のＦｉｅｌｄｂｕｓ用アラーム状態またはアラート状態は、ＢＬＯＣＫ＿ＥＲＲパラメータ下で一つにグループ化され、いずれの一つでもアクティブ状態（すなわち、デバイスにより検出されたアラート状態またはアラーム状態）になると、ＢＬＯＣＫ＿ＡＬＭパラメータは、そのデバイスがアクティブアラームまたはアクティブアラートを有していることを報告することになる。したがって、従来のＦｉｅｌｄｂｕｓデバイス内において第一のアラーム状態またはアラート状態がアクティブになると、ＢＬＯＣＫ＿ＡＬＭパラメータはその第一のアラームまたはアラートを報告し、その第一のアラームのあとでアクティブになるアラーム状態またはアラート状態は、報告された第一のアラームまたはアラートが消去されるかまたはそれに対して受信了承がなされるまでは報告されないことになる。その結果、システムユーザまたはシステムオペレータがこの優先度の低い、報告済みの第一の状態を消去または受信了承しない限りは、優先順位の比較的低いアラーム状態またはアラート状態が、さらに重要な状態の報告をマスキングすることになる。一例としては、Ｆｉｅｌｄｂｕｓデバイス内のブロックは、「デバイスは早急に保守が必要」状態を検出し、ＢＬＯＣＫ＿ＥＲＲパラメータおよびＢＬＯＣＫ＿ＡＬＭパラメータを利用してそのことを報告し、次いで、同一のデバイスが「デバイスは今すぐ保守が必要」状態を検出した場合には、その引き続き検出された状態はＢＬＯＣＫ＿ＥＲＲパラメータ内に（すなわち、適切なビットを設定することにより）反映されうる。しかしながら、ＢＬＯＣＫ＿ＡＬＭは、「デバイスは早急に保守が必要」状態に関連した報告アラーム状態またはアラート状態がシステムユーザにより消去または受信了承されない限りは、より重要な「デバイスは今すぐ保守が必要」状態を報告することができない。
【００１５】
さらに、スマートフィールドデバイスのアラームまたはアラートの整合性のある方法での監視、処理、および報告は、単一のプロセス制御システム内で複数のタイプのスマートフィールドデバイスが統合される場合にはさらに複雑になる。たとえば、ＨＡＲＴプロトコルに準拠するデバイス（すなわち、ＨＡＲＴデバイス）は、プロセスを運転するためにＦｉｅｌｄｂｕｓデバイスと共同して用いられることが多い。
【００１６】
いずれの場合であっても、すべてのＨＡＲＴデバイスは、８つの標準状態を用いてデバイスのステータスを報告するように（ＨＡＲＴプロトコルに従って）構築されている。残念なことには、ＨＡＲＴプロトコルにより定義されかつＨＡＲＴと互換性のあるデバイスにより提供される８つの標準ステータス状態は、Ｆｉｅｌｄｂｕｓと互換性のあるデバイスにより提供されるステータス状態と整合性がないことが一般的である。その結果、ＦｉｅｌｄｂｕｓデバイスとＨＡＲＴデバイスとを組み合わせたものから受信しているアラーム情報またはアラート情報を整合性のある方法でシステムオペレータまたはシステムユーザへ報告・編成することは不可能ではないとしても非常に複雑である。さらに、公知のように、ＨＡＲＴデバイスは、デバイスの製造業者により規定される、一または複数の非標準ステータス状態またはデバイス特有ステータス状態をも有していることが一般的である。これらの非標準ステータス状態はデバイスのタイプ間および製造業者間において変わる可能性があるために、その結果として、さまざまな製造業者により製造された特定のタイプのデバイスまたは単一の製造業者により製造されたさまざまなタイプのデバイスは、デバイス特有ステータス状態の相異なるセットを提供しうる。いずれの場合であっても、これらの非標準ＨＡＲＴデバイスステータス状態は、ＨＡＲＴデバイスステータスとＦｉｅｌｄｂｕｓデバイスステータスとが統合化される監視、処理、および表示をさらに複雑にしている。
【課題を解決するための手段】
【００１７】
本明細書において記載されるＨＡＲＴデバイス用機能強化型アラートを利用することにより、プロセス制御システム内のＨＡＲＴデバイスは、Ｆｉｅｌｄｂｕｓデバイス、とくに本明細書において記載されるＦｉｅｌｄｂｕｓ用機能強化形アラートを使用するＦｉｅｌｄｂｕｓデバイスにより報告されるアラームのタイプに一致する複数のステータス状態を利用して、該デバイス内で検出されるアラーム状態またはアラート状態をシステムユーザまたはシステムオペレータへ報告することが可能になる。これらのステータス状態の各々は異なるレベルの重要度に対応し、各タイプのステータス状態は、システムユーザまたはシステムオペレータによる異なるタイプの応答を必要としうる。
【００１８】
本発明の一つの態様では、プロセス制御システムにおいてＨＡＲＴアラートメッセージを生成する方法は、各々が異なるレベルの重要度を表す複数のデバイスステータス状態にＨＡＲＴデバイスの複数のデバイス状態を一意に関連付けするステップと、前記ＨＡＲＴデバイスに関連する複数のデバイス状態のうちの１つのデバイス状態を検出するステップと、前記ＨＡＲＴデバイスに関連する検出した前記デバイス状態を複数の前記デバイスステータス状態のうちの一つにマッピングするステップと、前記検出したデバイス状態の重要度を示すための、前記ＨＡＲＴデバイスに関連する前記検出したデバイス状態と複数の前記デバイスステータス状態のうちの一つとに関連する情報を含む前記ＨＡＲＴアラートメッセージを生成するステップとを有している。
【００１９】
本発明の他の態様では、ユーザインターフェイス表示画面を有するプロセス制御システムにおいてフィールドデバイスアラートメッセージを報告する方法は、フィールドデバイス内の状態を検出するステップと、前記検出されたデバイス状態を、各々が異なるレベルの重要度を表しているデバイス故障ステータス状態、デバイス保守ステータス状態、および勧告ステータス状態のうちの一つに関連付けするステップと、前記検出されたデバイス状態を、前記デバイス故障ステータス状態、前記デバイス保守ステータス状態、および前記勧告ステータス状態のうちの関連する一つと共に、前記ユーザインターフェイス表示画面を介して報告するステップとを有している。
【発明を実施するための最良の形態】
【００２０】
図１を参照すると、プロセス制御ネットワークまたはプロセス制御システム10は、一または複数のホストワークステーションまたはホストコンピュータ14（いかなるタイプのパーソナルコンピュータまたはワークステーション）と、一または複数のフィールドデバイス25〜39に各々が接続された何列もの入力／出力（Ｉ／Ｏ）デバイス20, 22とに接続された一または複数のプロセスコントローラ12を有する。プロセスコントローラ12は、たとえば、フィッシャーローズマウント社から販売されているＤｅｌｔａＶ（登録商標）プロセス制御システムであってもよいが、たとえばイーサネット接続40またはその他の適切な通信リンクを利用してホストコンピュータ14に通信可能に接続されている。同様に、プロセスコントローラ12は、たとえば標準型４〜２０ｍＡデバイスおよび／またはＦｉｅｌｄｂｕｓプロトコルもしくはＨＡＲＴプロトコルの如き任意のスマート通信プロトコルに関連する所望の任意のハードウェアおよびソフトウェアを用いて、フィールドデバイス25〜39に通信可能に接続されている。一般的に公知であるように、プロセスコントローラ12は、その内部に格納されているかまたはそうでなければそれと関連付けられているプロセス制御ルーチンを実行または監督し、フィールドデバイス25〜39と通信し、任意の所望の方法でプロセスを制御する。
【００２１】
フィールドデバイス25〜39は、センサ、バルブ、トランスミッタ、ポジショナなどの如き任意のタイプのデバイスであってもよく、上記デバイスの列20、22内のＩ／Ｏカードは、ＨＡＲＴ、Ｆｉｅｌｄｂｕｓ、Ｐｒｏｆｉｂｕｓなど如きの所望の任意の通信プロトコルまたはコントローラプロトコルに準拠するならばどのようなタイプのＩ／Ｏデバイスであってもよい。図１に例示されている実施例においては、フィールドデバイス25〜27は、アナログ回線を利用してＩ／Ｏカード22Aと通信する標準型４〜２０ｍＡデバイスであるものとして、フィールドデバイス28〜31は、ＨＡＲＴ互換性のあるＩ／Ｏデバイス20Aに接続されているＨＡＲＴデバイスであるものとして例示されており、フィールドデバイス32〜39は、たとえばＦｉｅｌｄｂｕｓプロトコルを用いてかつデジタルバス42または44を利用してＩ／Ｏカード20B、22Bと通信するＦｉｅｌｄｂｕｓフィールドデバイスであるものとして例示されている。
【００２２】
各コントローラ12は、機能ブロック、トランスデューサブロック、およびリソースブロックを利用して制御戦略を実行するように構築されている。周知のように、各ブロックは、制御ルーチン全体の一部（たとえば、サブルーチン）であり、プロセス制御システム10内でプロセス制御ループを実行するために他のブロックと（リンクと呼ばれる通信を利用して）協働して動作する。機能ブロックおよびトランスデューサブロックは、プロセス制御システム10内において、センサもしくは他のパラメータ測定デバイスに関連するような入力機能や、ＰＩＤ制御、ファジー論理制御などを実行する制御ルーチンに関連するような制御機能、またはある物理的機能を実行するためにバルブのようなあるデバイスの動作を制御する出力機能を実行することが一般的である。もちろん、ハイブリッドおよび他のタイプの機能ブロックも存在する。
【００２３】
機能ブロックは、標準型４〜２０ｍＡデバイスおよびなんらかのタイプのスマートフィールドデバイスのために利用されるかまたはそれらのデバイスに関連付けされる場合、一般的にコントローラ12内に格納され、コントローラ12により実行されることが可能である。あるいは、機能ブロックは、フィールドデバイスに格納され、フィールドデバイスにより実行されてもよい。機能ブロック・トランスデューサブロック・リソースブロック制御戦略を用いて、プロセス制御システム10の説明が本明細書において提供されているが、ラダー論理やシーケンシャルフローチャートなどの如き他の技術を利用して、また所望の任意の、所有権の主張が可能なプログラム言語または通常のプログラム言語を利用して、制御戦略を実行することも可能である。
【００２４】
図１のシステムにおいて、ホストデバイス14のうちの一または複数は、オペレータワークステーションとして機能し、その内部に格納されたアラーム処理ソフトウェア50を有している。一般的にいえば、アラーム処理ソフトウェア50は、システム内に存在するアラームに関する現行のプロセス動作状態をシステムオペレータまたはシステムユーザが理解または監視するために必要かつ適切なプロセス制御システム10の情報を表示する。たとえば、アラーム処理ソフトウェア50は、アラーム指標を内部に有するアラームバナーと、プロセス制御システム10の一区画を示す主制御表示画面とを表示することが可能であり、該主制御表示画面は、アラームバナー内に表示されたアラームのうちの一または複数に関連したデバイスおよび他の装置を有している。主制御表示画面は、たとえば、タンク内の流体レベル、バルブおよび他の流体用配管の流れ特性、装置の設定値、センサの読取り値、デバイスのステータスなどの如き、プロセス制御システム10の現行の状態に関する情報を提供することが可能である。そのような表示画面の一例が図３に示されている。オペレータは、プロセス制御システム10のさまざまな部分を閲覧するためにまたはプロセス制御システム10内の装置を閲覧するためにアラーム処理ソフトウェア50を利用しうる。もちろん、アラーム処理ソフトウェア50は、ワークステーション14のオペレータ表示画面上にインターフェイススクリーンを作成するために必要な、プロセス制御システム10に関連するまたはプロセス制御システム10内で作成される数値、設定値、および測定値を取得するために、コントローラ12と、必要ならば、フィールドデバイス25〜39、Ｉ／Ｏデバイス列20, 22のうちのいずれか、またはその他のデバイスと通信してもよい。
【００２５】
アラーム処理ソフトウェア50は、コントローラ12、Ｉ／Ｏデバイス20、22、および／またはフィールドデバイス25〜39のうちの一部または全部の内のアラーム生成ソフトウェアにより作成されたアラームメッセージを受信するように構築されている。このアラーム処理ソフトウェア50が、一例としてのみ、ソフトウェアエレメント51, 52, 53として図１に概して示されている。一般的にいえば、アラーム処理ソフトウェア50は、たとえばプロセスアラーム（プロセスの稼動中に利用されるプロセス制御ルーチンを形成しかつ通信可能に相互に接続された機能ブロックからなるモジュールの如きプロセス制御ソフトウェアモジュールにより一般的に生成されるプロセスアラーム）と、コントローラ12、Ｉ／Ｏデバイス20、22、または他のワークステーション14により生成されかつこれらのデバイスの状態または機能状態に関連するアラームの如きハードウェアアラームと、フィールドデバイス25〜39のうちの一部または全部に関連する問題または発生しうる問題を示すためにフィールドデバイス25〜39のうちの一部または全部により生成されるデバイスアラームとを含むさまざまなカテゴリのアラームを受信する。これらまたはその他のカテゴリのアラームは任意の所望の方法において生成することが可能である。たとえば、プロセス制御機能の実行に利用される機能ブロックまたはソフトウェアモジュールにプロセスアラームを生成させることは周知のことであり、これらのプロセスアラームが一般的にアラームメッセージの形態でオペレータインターフェイスに表示するために送信される。また、スマートデバイスの一部、コントローラ、Ｉ／Ｏデバイス、データベース、サーバ、ワークステーションなども、所望の任意の所有権の主張可能なソフトウェアまたは通常のソフトウェアを利用して、問題、エラー、保守アラートなどを検出し、これらの状態を示すアラームまたはアラートをワークステーション14内のオペレータインターフェイスに送信することが可能である。具体的には、コントローラ、Ｉ／Ｏデバイス、およびスマートフィールドデバイスの如きデバイスのほとんどは、固着したバルブプラグ、壊れた部品、保守課題などの如きハードウェア問題を検出するソフトウェアおよび／またはセンサが搭載され、これらの状態を示す信号またはメッセージを生成すること可能である。
【００２６】
所望の場合には、アラーム処理ソフトウェア50は複数の因子に基づいてアラームを受信し、フィルタリングすることが可能である。具体的には、アラーム処理ソフトウェア50は、該ソフトウェア50が内部で実行されているワークステーションと、そのワークステーションにログインした作業員の身分と、そのアラームのカテゴリ、タイプ、優先順位、ステータス、発生時間などの如きオペレータにより設定可能な設定とに基づいてアラームをフィルタリングしうる。たとえば、アラーム処理ソフトウェア50は、該アラーム処理ソフトウェア50を実行するワークステーションが受信するように構築されている、プラントの領域または区域からのアラームを選択的に表示するためにアラームをフィルタリングすることが可能である。換言すれば、プラントのある領域または区域に対するアラームは特定のワークステーションでは表示されない場合があり、その代わりに、各ワークステーションは、そのプラントの一または複数の特定の領域に対するアラームのみを表示するように制限されうる。同様に、アラームはオペレータの身分によりフィルタリングされうる。その結果、個々のオペレータは、特定のカテゴリ、タイプ、優先順位レベルなどのアラームのみを閲覧するように制限されるか、またはそのプラントの区域または副区域（たとえば、領域）からのアラームのみを閲覧するように制限されうる。また、アラーム処理ソフトウェア50は、オペレータの利用許可に基づいてもアラームをフィルタリングし、表示しうる。これらのワークステーション・オペレータフィルタリング設定値のことは、本明細書では、一様に、ワークステーションおよびオペレータの制限範囲と呼ぶこととする。
【００２７】
また、アラーム処理ソフトウェア50は、たとえば、アラームカテゴリ（たとえば、プロセスアラーム、デバイスアラーム、またはハードウェアアラーム）、アラームタイプ（通信、故障、勧告、保守など）、アラーム優先順位、モジュール、デバイス、ハードウェア、アラームが属するノードまたは領域、アラームの受信了承または抑制、アラームがアクティブかそうでないかなどを含むオペレータによる設定可能な設定値に基づいても、閲覧可能なアラーム（すなわち、ワークステーションおよびオペレータ制限範囲内のアラーム）をフィルタリングすることが可能である。
【００２８】
Ｆｉｅｌｄｂｕｓデバイス32〜39のうちの一部または全部は、Ｆｉｅｌｄｂｕｓデバイスとの関連では以前には利用されていなかった、独立して報告可能な三つのデバイスアラームカテゴリまたはデバイスアラートカテゴリを有すことが可能である。一般的にいえば、これらの独立して報告可能な三つのデバイスアラームカテゴリの各々は、異なるレベルの重要度に対応し、したがって、システムユーザまたはシステムオペレータは、各カテゴリ内のアラームまたはアラートに応じて異なるタイプの応答をする必要がありうる。
【００２９】
具体的には、Ｆｉｅｌｄｂｕｓデバイス32〜39は、適切な動作が停止してしまったかまたは動作が完全に停止する恐れがあり、その結果、デバイスそれ自体の正常な感知機能および／または制御機能の実行が妨げられる可能性のあるデバイスの内の問題を一般的に示すアラームパラメータＦＡＩＬＥＤ＿ＡＬＭを提供することが可能である。たとえば、デバイス内のメモリ不良、デバイス内のドライブ故障、または今すぐに対処（すなわち、保守、修理など）を必要としているその他のデバイスの故障は、ＦＡＩＬＥＤ＿ＡＬＭパラメータを用いて報告されうる。また、Ｆｉｅｌｄｂｕｓデバイス32〜39は、なんらかのタイプのデバイス保守の必要項目に関連しているがＦＡＩＬＥＤ＿ＡＬＭパラメータを利用して報告するのに値する充分なメリットを提供するほどは重要ではない、デバイス内で検出された状態を一般的に示すアラームパラメータＭＡＩＮＴ＿ＡＬＭも提供しうる。ＭＡＩＮＴ＿ＡＬＭパラメータを用いて報告するデバイス状態とは、最終的にはデバイスが故障するような結果となりうるが、感知、制御、またはその他の必要な機能を実行するようなデバイス能力には必ずしも影響を与えるとは限らない、デバイス内のなんらかのタイプの劣化、磨耗、疲労などにより生じる状態であることが好ましいが、それに限定されるわけではない。たとえば、バルブの固着、インパルスラインの詰まりなどは、ＭＡＩＮＴ＿ＡＬＭパラメータを用いてアラームまたはアラートを報告する結果になりうるデバイス状態である。さらに、Ｆｉｅｌｄｂｕｓデバイス32〜39は、勧告の性格を有するアラートまたはアラームのメリットしかない、デバイス内で検出された状態を一般的に示すアラームパラメータＡＤＶＩＳＥ＿ＡＬＭを提供しうる。一般的にいえば、ＡＤＶＩＳＥ＿ＡＬＭパラメータを利用して報告されるアラームまたはアラートは、デバイスの動作またはそのデバイスを用いて制御および／または監視されているプロセスに対してなんらの影響をも与えない。たとえば、マグメータにより検出された接地問題、センサにより検出された過渡温度または過渡圧力などはＡＤＶＩＳＥ＿ＡＬＭパラメータを利用して報告されうる。
【００３０】
したがって、従来のＦｉｅｌｄｂｕｓデバイスにより利用されているＢＬＯＣＫ＿ＡＬＭパラメータおよびＢＬＯＣＫ＿ＥＲＲパラメータとは対照的に、本明細書において記載される、独立して報告可能なＦＡＩＬＥＤ＿ＡＬＭパラメータ，ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータを利用することにより、Ｆｉｅｌｄｂｕｓデバイスは、さまざまなレベルの重要度を有する複数のアラームまたはアラートを同時に報告することが可能になる。換言すれば、単一のＦｉｅｌｄｂｕｓデバイスは、本明細書において記載される独立して報告可能なアラームにより、ＡＤＶＩＳＥ＿ＡＬＭを利用して今すぐには対処を必要としないような接地問題を報告し、同時に、システムオペレータによりＦＡＩＬＥＤ＿ＡＬＭが受信了承または消去されたかには関係なく、ＦＡＩＬＥＤ＿ＡＬＭパラメータを利用して、たとえば、今すぐに対処が必要なセンサ故障の如きさらに重要な状態を報告することが可能である。
【００３１】
本明細書において記載されるＦＡＩＬＥＤ＿ＡＬＭパラメータ，ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータの各々は、たとえばＤＳ−７２またはＤＳ−７１の如き所望の任意のデータ形式またデータタイプに基づいて３２ビット長のデータを利用して形成されることが可能である。ＤＳ−７２またはＤＳ−７１の両方は、周知のＩＥＥＥ標準であるので本明細書においては詳細には説明しない。各３２ビット長データ内の各ビットは、その３２ビット長データに対応するアラームパラメータを利用して報告される固有のデバイス状態を表現することが可能である。したがって、三つの異なるレベルの重要度（すなわち、ＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭ）の各々に対して３２のデバイス状態が存在するので、全体としては、９６の固有のアラーム状態またはアラート状態が各Ｆｉｅｌｄｂｕｓデバイスにより報告されうることになる。所望の場合には、独立して報告可能なアラームであるＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭの各々内の一つのビットは、とくに定義されていない「その他」状態のために利用されることが可能であり、それにより、デバイスは、該デバイスの設計中には予測されえなかったさまざまなデバイス状態および／または特定のユーザにより必要とされうるさまざまなデバイス状態の検出に対してより柔軟に対応することが可能になる。
【００３２】
一般的には、低重要度のアラームまたはアラートは、ＡＤＶＩＳＥ＿ＡＬＭパラメータまたはＭＡＩＮＴ＿ＡＬＭパラメータを用いて報告され、ＦＡＩＬＥＤ＿ＡＬＭパラメータを用いてそれと同時に高重要度のアラームを報告するＦｉｅｌｄｂｕｓデバイスの能力に影響を与えることはないが、特定のアラームパラメータ内の複数のアクティブ状態（すなわち、検出された複数のデバイス状態）が、最終的に複数のアラームイベントを生成し、オペレータワークステーション14に送信されることになるわけではない。たとえば、Ｆｉｅｌｄｂｕｓデバイスのうちの一つが過度の圧力および過度の温度を検出した場合には、そのデバイスのＡＤＶＩＳＥ＿ＡＬＭパラメータ内でこれらの状態に対応するビットが設定される。しかしながら、最初に検出された状態はアラームイベントを生成させ、オペレータワークステーション14に送信させるが、その一方、その次に検出された状態は、初期または最初に検出された状態に関連するアラームイベントがシステムオペレータまたはシステムユーザにより消去または受信了承されたあとにのみ、もう一つのアラームイベントを生成させ、ワークステーションに送信させる。その結果、Ｆｉｅｌｄｂｕｓデバイスが最初に過度の圧力状態を検出した場合には、その次に検出された過度の温度状態は、システムユーザまたはオペレータが過度圧力アラームまたは過度圧力アラートを消去または受信了承するまではアラームイベントを生成させない。
【００３３】
ＦＡＩＬＥＤ＿ＡＬＭパラメータ、ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータは、上述のＦｉｅｌｄｂｕｓアラームメッセージ形式（すなわち、ブロック識別フィールド、サブコードフィールドなどを有するメッセージ形式）を利用してワークステーション14のうちの一つを介してシステムユーザまたはシステムオペレータに独立して報告されることが可能である。さらに、ＦＡＩＬＥＤ＿ＡＬＭパラメータ，ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータの各々に関連する３２の起こりうる状態の各々は、これらのアラームがＦｉｅｌｄｂｕｓアラームメッセージ形式を利用してシステムワークステーションに送信される場合には、固有のサブコードを用いて表現されることが好ましい、しかし、そのことに限定されるわけではない。各Ｆｉｅｌｄｂｕｓデバイスは、ＦＡＩＬＥＤ＿ＡＬＭパラメータ，ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータの各々の起こりうる状態の各々に関連するサブコードの定義を有している。また、各Ｆｉｅｌｄｂｕｓデバイスは、サブコードの各々に関連する状態の記述である固有のテキストメッセージを定義しうる。各サブコードは、固有のデバイス状態、たとえば固有のテキストメッセージに対応していることが好ましいが、複数のデバイス状態に対して単一のテキストメッセージを利用することが望ましい場合もある。
【００３４】
本明細書において記載される、独立して報告可能なデバイスアラームパラメータは、起こりうるデバイス状態（すなわち、９６の起こりうる状態）のうちの一または複数に応答するアラームまたはアラートの報告を実行可能または実行不能にするために、各デバイスによりフィルタリングされうる。本明細書において記載される、独立して報告可能なＦＡＩＬＥＤ＿ＡＬＭパラメータ，ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータを利用してアラームを報告することが可能なＦｉｅｌｄｂｕｓデバイス32〜39の各々は、独立して報告可能なアラームパラメータの各々に対してアクティブアラームパラメータとマスクパラメータとをさらに有している。具体的には、Ｆｉｅｌｄｂｕｓデバイス32〜39の各々は、報告可能なＦＡＩＬＥＤ＿ＡＬＭパラメータに対応するＦＡＩＬＥＤ＿ＡＣＴＩＶＥパラメータおよびＦＡＩＬＥＤ＿ＭＡＳＫパラメータと、報告可能なＭＡＩＮＴ＿ＡＬＭパラメータに対応するＭＡＩＮＴ＿ＡＣＴＩＶＥパラメータおよびＭＡＩＮＴ＿ＭＡＳＫパラメータと、報告可能なＡＤＶＩＳＥ＿ＡＬＭパラメータに対応するＡＤＶＩＳＥ＿ＡＣＴＩＶＥパラメータおよびＡＤＶＩＳＥ＿ＭＡＳＫパラメータとを有しうる。これらマスクパラメータおよびアクティブパラメータは符号なしの３２ビットのデータ形式またはデータタイプを用いて実現されることが好ましい、しかしそれに制限されるわけではない。もちろん、その他の適切なデータタイプまたはデータ形式がそれらの代りに利用されてもよい。
【００３５】
マスクパラメータおよびアクティブパラメータの内の３２ビットの各々は、それに対応する報告可能なアラームパラメータ（すなわち、ＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭ）内の状態に一意に対応している。一般的に、たとえば、各デバイスのマスクパラメータのビットをコンフィギュレーション中に設定または再設定することが可能であり、それにより、そのデバイスのＦＡＩＬＥＤ＿ＡＬＭパラメータまたはＦＡＩＬＥＤ＿ＡＬＭアラーム，ＭＡＩＮＴ＿ＡＬＭパラメータまたはＭＡＩＮＴ＿ＡＬＭアラーム、およびＡＤＶＩＳＥ＿ＡＬＭパラメータまたはＡＤＶＩＳＥ＿ＡＬＭアラームに関連する状態の検出に応答してアラームを報告するデバイスの機能を動作可能または動作不能にすることができる。この方法で、システムユーザまたはシステムオペレータは、各デバイスがＦｉｅｌｄｂｕｓアラートメッセージまたはＦｉｅｌｄｂｕｓアラームメッセージを生成する状態を選択的に有効または無効にすることができる。もちろん、システムユーザまたはシステムオペレータは、所望ならば、どのような多くの数のデバイス状態でもまたはどのように少ない数のデバイス状態でも有効または無効にすることができる。
【００３６】
動作状態では、Ｆｉｅｌｄｂｕｓデバイスがある状態を検出すると、その検出された状態に対応するビットが適切なアクティブパラメータ内に設定されうる。たとえば、Ｆｉｅｌｄｂｕｓデバイスが不良センサを検出した場合、そのデバイス内のトランスデューサブロックのＦＡＩＬＥＤ＿ＡＣＴＩＶＥパラメータ内のその状態に対応するビットが不良センサを示すために設定または再設定されうる。さらに追加して検出されるデバイス状態に関しては、それらのデバイス状態が検出された場合（そして、それらの状態が受信了承、キャンセル、または消去されていない場合）でも、またはそれらのデバイス状態がいかなる時間において検出された場合でも、それらの追加の状態の存在を示すためにアクティブパラメータ内のビットが設定または再設定される結果となりうる。しかしながら、以下でさらに詳細に説明するとおり、受信了承はまだ実行されていないが報告は済んでいる状態（すなわち、Ｆｉｅｌｄｂｕｓアラームメッセージがシステムオペレータに送信された状態）のあとで検出された状態は、その報告が済んでいる状態がシステムユーザまたはシステムオペレータにより受信了承、キャンセル、または、そうでなければ、消去が行われない限りは報告されないことがある。そのときには、Ｆｉｅｌｄｂｕｓデバイスは、そのトランスデューサブロックのＦＡＩＬＥＤ＿ＭＡＳＫパラメータを利用し、ユーザまたはシステムオペレータがアラームまたはアラートを受信したくない、そのトランスデューサブロックに関連するデバイス状態をフィルタリングすることが可能である。システムユーザまたはシステムオペレータは、所望のフィルタリングを達成するためにＦＡＩＬＥＤ＿ＭＡＳＫパラメータ内のいずれのビットを設定または再設定するのかをシステム構築の時点において定義することが可能である。一例としては、ＦＡＩＬＥＤ＿ＭＡＳＫパラメータとＦＡＩＬＥＤ＿ＡＣＴＩＶＥパラメータとを用いて論理ＡＮＤ操作を実行することにより、現在アクティブ（すなわち、検出されている状態）でありかつマスクパラメータによりマスキングされなかったデバイス状態の存在を示すように設定または再設定されたビットを有するＦＡＩＬＥＤ＿ＡＬＭパラメータを生成することが可能になる。
【００３７】
一般的に、独立して報告可能なパラメータＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭの各々は、（アクティブかつマスキングされていない状態に対する）ＦｉｅｌｄｂｕｓアラームメッセージまたはＦｉｅｌｄｂｕｓアラートメッセージを、それらの状態が検出された順番に、システムユーザまたはシステムオペレータにそれ自体が報告してもよくまたはＦｉｅｌｄｂｕｓデバイスに送信させるようにしてもよい。換言すれば、特定のデバイスに対する独立して報告可能なアラームパラメータのうちの特定の一つ内の検出された状態は、該状態が検出された順番で（すなわち、先入れ先出し方法により）システムユーザまたはシステムオペレータに報告されうる。もちろん、検出された状態は、所望ならば、その他の優先順位付け機構またはシーケンス機構を用いてシステムユーザまたはシステムオペレータに報告されてもよい。たとえば、マスキングされていない検出された状態は、その検出された状態のタイプなどに基づいて発生順とは逆の順番で（すなわち、後入れ先出し方法で）報告されうる。さらに、Ｆｉｅｌｄｂｕｓデバイスは、特定のアラームパラメータに関連するすべてのアラームメッセージが消去されている場合には、消去アラームメッセージを提供しうる。さらに、特定のアラームに対するマスクパラメータが変更されているがそのアラームパラメータに関連する状態がアクティブである場合には、デバイスは、そのアラームを消去し、上述のマスクパラメータに行われた変更に基づいてそのアラームを再評価することが可能である。
【００３８】
また、Ｆｉｅｌｄｂｕｓデバイス32〜39の各々は、ＦＡＩＬＥＤ＿ＡＬＭパラメータ，ＭＡＩＮＴ＿ＡＬＭパラメータ、およびＡＤＶＩＳＥ＿ＡＬＭパラメータに対応する優先順位パラメータであるＦＡＩＬＥＤ＿ＰＲＩ、ＭＡＩＮＴ＿ＰＲＩ、およびＡＤＶＩＳＥ＿ＰＲＩも有しうる。これらの優先順位パラメータは、２５６の優先順位レベルを提供することが可能な符号なしの８ビット数値を用いて実現されてもよく、また、たとえば、デフォルトレベルまたはデフォルト値として２が割り当てられてもよい。アラームの優先順位レベルを零に設定すると、そのアラームの報告が実行不能になり、アラームの優先順位レベルを１と２５５との間の任意の数値に設定すると、システムワイドでアラームまたはアラートをアラーム処理ソフトウェア50が管理する方法を、ユーザまたはシステムオペレータが制御できるようになる。具体的には、どのデバイスのアラームまたはアラートが他のデバイスのアラームまたはアラートより優先するのかを決定するために複数の可能な優先順位レベルが利用されうる。このように、システムユーザまたはシステムオペレータは、多数の起こりうるアクティブアラームをシステムが管理および処理する方法を事前に規定することができる。
【００３９】
また、Ｆｉｅｌｄｂｕｓデバイス32〜39の各々は、ワークステーション14内に格納されうるデバイス説明情報内のテキスト情報にマッピングされうるＲＥＣＯＭＭＥＮＤＥＤ＿ＡＣＴＩＯＮパラメータも有しうる。このＲＥＣＯＭＭＥＮＤＥＤ＿ＡＣＴＩＯＮパラメータにより参照されるテキスト情報は、アラームが発生されたデバイスの調整、修理などを補助するためにシステムオペレータまたはシステムユーザのために表示されうる。報告されたアラームが複数のアクティブ状態を有している場合には、システムユーザまたはシステムオペレータのために表示される勧告は、最も重要なまたは最高優先順位の状態に対するものでありうる。
【００４０】
上述のように、Ｆｉｅｌｄｂｕｓデバイス32〜39により生成されたさまざまなタイプのアラートおよびアラームは、デバイスレベルで、複数の独立して報告可能アラームパラメータ（たとえば、ＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭ）にマッピングされうる。この方法で、複数のＦｉｅｌｄｂｕｓデバイスからのアラートまたはアラームが、監視され、処理され、ワークステーション14を介してシステムオペレータまたはシステムユーザに整合性のある論理的な方法で表示されることが可能になる。さらに、所与のＦｉｅｌｄｂｕｓデバイス内においては、本明細書において記載される独立して報告可能なアラームパラメータの独立性のおかげで、重要度タイプの高いアラートまたはアラームのシステムオペレータまたはシステムユーザへの通信または表示が重要度タイプの低いアラートによりマスキングされてしまうことが防止される。
【００４１】
ＨＡＲＴデバイス28〜31は、各々、８つの標準ステータス状態と、可能ならば、一または複数のデバイス特有ステータス状態とを提供する。しかし、これらの標準ステータス状態およびデバイス特有ステータス状態は、Ｆｉｅｌｄｂｕｓデバイス32〜39により報告されるステータス状態と整合性が取れていない。具体的には、ＨＡＲＴデバイス28〜31は、本明細書において記載される独立して報告可能なアラームパラメータであるＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭと整合性の取れた方法ではステータス状態を報告しない。
【００４２】
本明細書において記載される独立して報告可能なアラームパラメータを利用して、ＨＡＲＴデバイス28〜31により報告されるステータス状態に関連するアラートまたはアラームと、Ｆｉｅｌｄｂｕｓデバイス32〜39により報告されるアラートまたはアラームとを統合して監視し、処理し、表示することを促進するために、アラーム処理ソフトウェア50は、ＨＡＲＴに準拠するステータス情報を、上述の独立して報告可能なアラームパラメータであるＦＡＩＬＥＤ＿ＡＬＭ，ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭと整合性の取れるアラートカテゴリまたはアラームカテゴリにマッピングまたは分類する。一例としてのみであるが、八つの標準ＨＡＲＴデバイスステータス状態が以下で表１により示されているとおりにマッピングされうる。
【００４３】
【表１】
0004436046.tif 000002
【００４４】
したがって、上記表１に示されているように、アラーム処理ソフトウェア50は、ＨＡＲＴデバイスステータス状態をＦＡＩＬＥＤと，ＭＡＩＮＴと、ＡＤＶＩＳＥとのカテゴリにマッピングまたは分類することにより、従来のシステムで可能であった方法よりもさらに整合性の取れた論理的な方法で、Ｆｉｅｌｄｂｕｓデバイスアラート情報またはＦｉｅｌｄｂｕｓデバイスアラーム情報とともにこれらの標準ＨＡＲＴステータス状態をシステムオペレータまたはシステムユーザへ報告または表示することを可能にする。
【００４５】
周知のように、Ｆｉｅｌｄｂｕｓデバイスとは対照的に、ＨＡＲＴデバイスは、現行のデバイス状態を取得するためにポーリングされなければならない。したがって、アラーム処理ソフトウェア50、コントローラ12、および／またはＩ／Ｏデバイス20Aは、ステータス情報を得るためにＨＡＲＴデバイス28〜31を周期的にポーリングするように構築されうる。ＨＡＲＴデバイスにより送信されるすべての応答メッセージは、８つの標準ステータス状態の現在の状態を有しているので、アラーム処理ソフトウェア50は、コントローラ12によりＨＡＲＴデバイス28〜31へＩ／Ｏデバイス20Aを介して一般的に送信される命令に対する応答からステータス情報を抽出することにより、このステータス情報を効率的に取得することが可能である。換言すれば、アラーム処理ソフトウェア50は、本来は必要なプロセス制御活動またはプロセス監視活動を実行する目的でコントローラ12により周期的にＨＡＲＴデバイス28〜31へ送信されている命令に対する応答からステータス情報を取得するので、必要だとしても、通信オーバヘッドをわずかに追加するだけですむ。たとえば、コントローラ12がＤｅｌｔａＶタイプのコントローラである場合、ＨＡＲＴ命令＃０、＃３は、周期的に、ＨＡＲＴデバイス28〜31へ送信される。したがって、アラーム処理ソフトウェア50は、これらの命令に応答して送信されたメッセージからデバイス28〜31に関連する標準ＨＡＲＴステータス状態情報を抽出することが可能である。もちろん、所望ならば、標準ＨＡＲＴステータス情報を含む応答メッセージをＨＡＲＴデバイス28〜31に送信させるために、コントローラ12およびアラーム処理ソフトウェア50により他のいかなる命令が利用されてもよい。
【００４６】
周知のように、標準外のＨＡＲＴステータス（すなわち、デバイス特有ステータス）状態は、ＨＡＲＴ命令＃４８をＨＡＲＴデバイス28〜31へ送信することにより取得されうる。また、周知のように、ＨＡＲＴ通信プロトコルは、「デバイス機能不良」状態または「追加ステータス使用可能」状態のうちのいずれかが真である（すなわち、それらのビットが論理数１に設定されている）場合にはデバイス特有ステータス情報を使用することが可能であると規定している。したがって、アラーム処理ソフトウェア50がＨＡＲＴデバイス28〜31のうちの一つに対する上述の「デバイス機能不良」状態または「追加ステータス使用可能」状態のうちの一方が真であると検出した場合には、アラーム処理ソフトウェア50はＨＡＲＴ命令＃４８をそのデバイスに送信する。その命令＃４８に応答して、ポーリングされたデバイスは、そのデバイス特有状態またはデバイス特有ステータスの性格に関連するさらに詳細な情報を提供する。次いで、アラーム処理ソフトウェア50は、（命令＃４８に応答して提供される）デバイス特有ステータス状態を以下のように分類しうる：（１）「デバイス機能不良」ビットが設定されている場合には、アラーム処理ソフトウェア50はそのデバイス特有ステータス状態を「ＦＡＩＬＥＤ」アラートカテゴリまたは「ＦＡＩＬＥＤ」アラームカテゴリにマッピングする。（２）「追加ステータス使用可能」ビットが設定されている場合には、アラーム処理ソフトウェア50はそのデバイス特有ステータス状態を「ＡＤＶＩＳＯＲＹ」アラートカテゴリまたは「ＡＤＶＩＳＯＲＹ」アラームカテゴリにマッピングする。
【００４７】
図２を参照すると、アラーム表示・インターフェイスシステムを実現するワークステーション14のうちの一つの構成がより詳細に示されている。図２に示されているとおり、ワークステーション14は、イーサネット接続40を介してコントローラ12と通信する、通信層またはスタック62の如き通信ソフトウェアを格納・実行し,  コントローラ12、バンク20、22内のＩ／Ｏデバイス、フィールドデバイス25〜39、および／または他のワークステーションにより送信される信号を受信する。また、通信層62は、コントローラ、Ｉ／Ｏデバイス、フィールドデバイス25〜39、およびその他のワークステーションに送信されるアラーム受信了承メッセージまたはアラーム受信了承信号などの如きメッセージを正確にフォーマットもする。通信層を実現するために利用される通信ソフトウェアとしては、たとえば、イーサネット通信に最近利用されている通信ソフトウェアであるならば公知のものであってもまたは所望のものであってもよい。もちろん、通信スタック62は、ワークステーション14内で実行される、コンフィギュレーションアプリケーション、診断スアプリケーションまたは他のプロセスアプリケーション、データベース管理アプリケーションなどの如き他の機能を実行する他のソフトウェアに接続されている。
【００４８】
アラーム表示・インターフェイスシステムは、通信層62からアラームと他のイベント情報とをメッセージの形式で受信するアラーム処理ユニット64を有し、アラームまたは他のイベント情報を含むそれらのメッセージを逆符号化し、アラームまたは他のイベント情報をデータベース66に格納することが可能である。通信層62とデータベース66とに接続するアラーム処理ユニット64の前端部はアラームレシーバであってよい。また、アラーム処理ソフトウェア50は、ワークステーション14に関連するユーザインターフェイス69（たとえば、ＣＲＴ、ＬＣＤ、ＬＥＤ、プラズマディスプレイ、プリンタなど）上にどのアラームを表示するのかを決定するためのアラーム処理ユニット64により利用されるアラームフィルタ68を有している。アラームフィルタ68は、データベース66内にその設定値を格納することが可能であり、これらのフィルタ設定値は、ユーザの必要性に基づいてユーザにより事前に設定されてもよくおよび／または変更されてもよい。なお、フィルタ68およびその設定は、本明細書において記載したとおりＦｉｅｌｄｂｕｓデバイスとともに使用しうる、デバイスレベルでのマスクパラメータであるＦＡＩＬＥＤ＿ＭＡＳＫ、ＭＡＩＮＴ＿ＭＡＳＫ，およびＡＤＶＩＳＥ＿ＭＡＳＫとは区別されるものである。すなわち、システムユーザまたはシステムオペレータは、デバイスマスクパラメータを利用して、特定のデバイス内の特定の状態により生成された特定のアラームをフィルタリングすることが可能である。これに代えてまたはこれに加えて、本明細書において記載したとおり、システムユーザまたはシステムオペレータは、上述のフィルタ68を利用して、アラームのタイプまたはカテゴリに基づいて、プロセス制御システム内の特定のプラント、領域、ユニット、ループなどに関連するアラーム別にフィルタリングすることが可能である。たとえば、アラーム処理ソフトウェア50が、ＨＡＲＴデバイス28〜31のうちの一または複数により送信されているアラート情報またはアラーム情報を処理する場合、所望の任意の方法でそのアラート情報またはアラーム情報を選択的に表示するためにアラームフィルタ68を利用しうる。もちろん、ＨＡＲＴデバイス28〜31は、たとえば、Ｆｉｅｌｄｂｕｓ32〜39に関連して上述したデバイスレベルのマスクパラメータの如き内部アラームフィルタリング機構または内部アラートフィルタリング機構を有していない。
【００４９】
一般的に、アラームフィルタ68のフィルタ設定値は、アラームのカテゴリおよび優先順位を制御してもよく、所望ならば、複数の異なる判断基準を利用して表示するアラームの順番を確立してもよい。ワークステーションおよびオペレータの制限範囲は、オペレータ身分とそのオペレータがログオンするワークステーションとに基づいて、特定のオペレータが何を閲覧できるか（たとえば、どのアラームが特定のワークステーションにおいて表示されうるか）に影響を与える。この場合、操作ライセンスが各ワークステーションに割り当てられてもよく、操作ライセンスなしでは、アラーム情報および全てのアラームリスト／要約表示画面が空の状態になるようにしてもよい。換言すれば、いかなるカテゴリ（すなわち、プロセス、ハードウェア、またはデバイス）のアクティブアラームまたは抑制アラームもアラーム処理ユニット64により表示されない。さらに、現行のオペレータ権限範囲においては（オペレータは通常少なくともそのプラント領域の一つのセキュリティキーが与えられている）、プラント領域からのアラームのみがそのワークステーションアラーム表示画面に表示されることが許される。また、プラント領域またはユニットフィルタリング表示画面（以下で説明される）を用いてオフ状態になっていないプラント領域およびユニットからのアラームのみがアラーム表示画面に表示されることが許される。この方法で、フィルタ68は、ワークステーション・オペレータ権限範囲以外からのアラームと、オペレータによりオフ状態になっているプラント領域またはユニットからのアラームとが表示されることを防いでいる。
【００５０】
上述のワークステーションおよびオペレータの制限範囲に適合させるためにアラームを試験したあと、フィルタ68はアラームをフィルタリングし、オペレータの設定値に基づいてそのアラームの表示順位を決定する。オペレータ設定値には、たとえば、アラームカテゴリ、アラーム優先順位、アラームタイプ、アラームの受信了承ステータス、アラーム抑制ステータス、アラーム時間、アラームのアクティブステータスなどが含まれる。この受信されたアラームは、アラームメッセージ（たとえば、Ｆｉｅｌｄｂｕｓアラームメッセージ）を利用してアラーム処理ソフトウェア50に送信されるが、上述の数値の各々に対するパラメータを有してもよい。フィルタ68は、そのアラームの適切なパラメータ値とフィルタ設定値とを比較することにより、アラームをフィルタリングして表示してもよい。たとえば、オペレータはどのカテゴリのアラームおよびどの優先順位レベルのアラームをスクリーンに表示する必要があるかを示しうる。所望ならば、オペレータは、製造業者により設定されたアラームの事前設定優先順位レベルから優先順位をオフセットすることによりアラームの所定の優先順位を調整することが可能である。ＤｅｌｔａＶシステムにおいては、各アラームに対して約３から１５の優先順位レベルの間で優先順位レベルが選択され、オペレータは、フィルタ68から見た場合の、高優先順位を低優先順位にまたは低優先順位を高優先順位にするためにこの優先順位レベルをいくつの数のレベルでもオフセットすることができる。オペレータはフィルタ68を通過したアラームの表示順位を設定しうるが、さまざまなタイプのアラームを整合性の取れた方法で表示するために、事前に設定されている設定によりその順番が決定されてもよい。
【００５１】
いずれの場合であっても、オペレータは、ユーザが最も興味を有するアラームのカテゴリまたはタイプに基づいてアラームが表示される様式をカスタマイズすることができる。その様式とは、プロセスアラーム、デバイスアラーム、ハードウェアアラームの如き全てが一つのカテゴリまたはタイプのアラームであってもよく、または二つ以上のカテゴリのアラームを任意に組み合わせたものであってもよい。さらに、ユーザは、異なる重要度のアラームまたはアラートが表示されうるようにまたは表示されないようにアラームの表示を設定しうる。たとえば、ユーザは、ＦＡＩＬＥＤ＿ＡＬＭパラメータおよびＭＡＩＮＴ＿ＡＬＭパラメータ内に包含されているアラームまたはアラートのみを閲覧することを欲し、ＡＤＶＩＳＥ＿ＡＬＭパラメータ内に包含されているアラームまたはアラートを閲覧することを欲しない場合がある。さらに詳細にいえば、システムユーザまたはシステムオペレータは、デバイス故障、保守が必要なデバイス、および／またはデバイスに関する勧告に関連するアラートまたはアラームを閲覧するようにアラーム表示を設定することが可能である。また、ユーザは、アラームの提示方法およびアラームとともに提供される情報を制御しうる。このような方法で、アラーム処理ソフトウェア50を利用することにより、本来ならばプラント内のさまざまな場所においてさまざまな作業員により対処されるアラームを同一のスクリーン上で閲覧・対処ことにより、オペレータ、技師または保守作業員、および技術者の作業を一人の作業員が実行することが可能になる。あるいは、同一のシステムにおいて、さまざまな時間に、保守要員はその同一のシステムを利用して保守アラームのみを閲覧し、それと同時に、技術者はそのデバイスに影響を与えている他のタイプのアラームを閲覧することができる。この方法により、アラーム処理ソフトウェア50は、同一の時間に、異なるワークステーションにおいて、プロセス制御システム10に関連するアラームのさまざまな様態を閲覧するためにさまざまなタイプの人によって用いられることが可能である。さらに、アラーム処理ソフトウェア50を利用しているときに、閲覧・受信了承しているアラーム機能を、ある個人が、同一のソフトウェアを有しうる別の個人に引き渡すことは比較的容易である。これに代えてまたはこれに加えて、ある個人は、他の個人が通常閲覧しているアラームを受け入れるようにフィルタを設定することが可能である。このような方法により、一人の作業者は、いくつかのフィルタ設定値を再設定しなおすことにより、他のワークステーションにいる他の作業者にアラーム閲覧機能を引き渡して昼食に行くことができる。昼食から戻ると、その作業者はそれらの機能の制御を再び取得することが可能である。また、アラームの情報量が余りにも大きくなり、一人の作業員では取り扱えなくなった場合には、その作業員は、プロセスアラーム、デバイスアラーム、またはハードウェアアラームの如きアラームの特定のカテゴリの負担を減らすために、他のターミナルの他の作業員達にこれらのアラーム取り扱ってもらうことが可能である。
【００５２】
アラーム処理ユニット64が、フィルタ68を利用してユーザに対して表示画面69に表示されるべきアラーム（すなわち、マスキングされていない状態）とそれらのアラームの表示順番とを決定したあと、アラーム処理ユニット64はこの情報をユーザ表示インターフェイス70に提供する。該ユーザ表示インターフェイス70は、任意の標準オペレーティングシステムまたは所望のオペレーティングシステムを利用して所望の任意の方法によりアラーム表示画面69上にアラーム情報を表示する。もちろん、ユーザ表示インターフェイス70は、プロセス制御システム10に関する配置情報または設定情報、そのシステム内のパラメータ値または信号などの如き他の必要な情報を、データベース66から、または通信レイヤ62を介してプロセス制御システム10から受信される他の通信信号から取得する。また、ユーザ表示インターフェイス70は、たとえば、特定アラームに関連するさらなる情報、アラーム設定またはフィルタ設定への変更、新しいアラーム表示画面などを要求するユーザからの命令を受信し、この情報をアラーム処理ユニット64に提供する。次いで、アラーム処理ユニット64は、要求された行動をとり、データベース66を調査してアラーム情報を取得し、表示画面69を介してユーザに新しいアラームビューを提供する。
【００５３】
一般的にいえば、たとえばプロセスアラーム、デバイスアラーム、ハードウェアアラームを含む、表示画面69上に発生・表示することが可能なアラームにはさまざまなカテゴリがある。公知でありかつコントローラまたはフィールドデバイスにより実行されるプロセス制御ルーチン内の機能ブロックまたはモジュールにより一般的に生成されるプロセスアラームは、従来、オペレータインターフェイスに送信・表示されていた。プロセスアラームは、プロセス制御ソフトウェアの機能的動作の問題、すなわち制限範囲外の測定値、プロセスパラメータ値と設定値との間の異常な偏差値などの如きプロセス制御ルーチンそれ自体に関連する問題を示すことが一般的である。プロセスアラームは、通常、プロセス制御モジュールの構成要素としてユーザにより構築されかつモジュール名ととともにオペレータインターフェイス上に提供されるコンフィギュレーション情報内に表示されうる。プロセスアラームのタイプのうちの一部には、不正入力／不正出力、測定範囲外測定値、超過しきい値などを含むものもある。プロセスアラームは当該技術分野において周知のことなので、本明細書においてはこれ以上詳細には説明しない。
【００５４】
デバイス不良、デバイス保守、および／または勧告に関連するアラームの如きデバイスアラームは、プロセス内のフィールドデバイスの動作に関連するアラームであり、プロセス制御システム10内で接続されているフィールドデバイスまたは他のデバイス内のソフトウェア（たとえば、図１のソフトウェア53）により検出され、フィールドデバイスの動作問題または動作エラーを示すことが可能である。デバイスアラームは、本明細書において記載されるシステムのオペレータインターフェイスに現れうる。デバイスアラームは、たとえば、バルブ内の圧力が大き過ぎまたは小さ過ぎるためにバルブが正確な動作ができないこと、バルブ内のモータ電流が大き過ぎるかまたは小さ過ぎること、デバイス内の電圧レベルが同期されていないこと、バルブ内のバルブプラグが固着していること、デバイスが正確に通信していないこと、デバイスが、たとえばある一定の時間が経過したという理由で、またはデバイスのバルブ部品が前回の保守点検以来ある一定量移動したという理由で保守の計画を立てる必要があることなどを示しうる。デバイスアラームは所望の任意の方法で生成されることが可能である。たとえば、その方法には、デバイスの問題を認識・検出しかつそれに関するアラームを生成するために、デバイスそれ自体に搭載されるか、またはアラームが生成されたデバイスに接続されている他のデバイスに搭載される、所有権主張可能なソフトウェアまたは通常のソフトウェアを利用することが含まれる。
【００５５】
以上のように、たとえば、デバイス内に故障状態または故障が進行している状態が存在することを示す故障アラーム、ある種の保守点検が必要であることを示す保守アラーム、デバイスが正確にまたは全く通信していないことを示す通信アラーム、勧告アラームなどを含む複数のさまざまなタイプのデバイスアラームが存在しうる。故障（たとえば、故障してしまった状態）アラームは、デバイスが重要な機能を実行することが可能でないことを示す一または複数の状態が検出されており、したがって今すぐの保守を必要としていることを示す。故障アラーム状態が真のときはいつでも、そのデバイスの保全性が悪いと考えられ、それはコントローラに及び、その結果そのデバイスが接続されているコントローラのノードの保全性も悪くする。一方、保守アラームは、デバイスが重要な機能を実行することができるが、対処しないでおけば、故障につながる可能性のある一または複数の状態を有しており、したがって、そのデバイスが早急に保守点検を受ける必要があることを示す。通信（たとえば、「通信不能」）アラームはデバイスが通信することを停止するとアクティブになる。通信不能アラームが真のときはいつでも、そのデバイスの保全性が悪いと考えられ、そのデバイスが接続されているコントローラのノードの保全性をも悪くする結果となる。勧告アラームは、デバイスが、その他のアラームカテゴリに分類されない状態を検出したことを示す。通常、勧告アラームは、たとえば、流量信号の変動を追跡する流量メータの如きデバイスのタイプに一意に関連する、個々のデバイスにより提供されるアラームである。この場合、デバイスは、該デバイスに関連するなんらかの信号の変動が大き過ぎるかまたは小さ過ぎ、このことが、なにか異常なことが発生しており調査をする必要があることを意味していることを認識しうる。デバイスに応じて、勧告アラームは保守アラームよりもより緊急度の高いまたは低い点検を必要とし、たとえば、ユーザは、勧告アラームの優先順位を保守アラームの優先順位よりも低く設定してもよい。もちろん、故障アラーム、保守アラーム、および勧告アラームは、デバイス全てにサポートされているわけではなく、上述の故障アラーム、保守アラーム、そして勧告アラームに代わりに、汎用デバイス用の「異常アラーム」の如き単一で全てを包括するようなアラームが用いられてもよく、この場合には、通信不能アラームと異常アラームとの全部で二つのアラームが存在することになる。もちろん、以上で説明したアラームの代わりにまたはそれらに付け加えて、他のタイプのデバイスアラームを作成または利用してもよい。
【００５６】
一つの実施例では、統合化されたアラーム情報を、たとえば、表示スクリーンの一つの端縁部においてアラームバナーの形態でユーザに提供することが可能である。図３を参照すると、アラームバナ−73がスクリーン71の下部に設けられている。該アラームバナ−73は、プロセス制御システム10により生成されかつフィルタ68を通過して表示画面69に至ったさまざまなアラームを表示する第一のラインを有している。アラームバナー73内に示されたアラームのうちの少なくとも一つは、スクリーン71の主要部に示されたプロセス制御システム10の一部と関連付けされうる。アラームバナー73内に表示された特定のアラームおよびこれらのアラームの順番は、マスクパラメータおよび優先順位パラメータの設定とフィルタ68のフィルタ設定とに従って決定される。一般的にいえば、受信了承、抑制、またはマスキングされていない最も優先順位の高いアラームが最初に表示され、次いで、その次に優先順位の高いアラームが表示され、以下同様に表示されていく。図３の例示のスクリーンでは、最も優先順位の高いアラーム74は、ＰＩＤ１０１制御ルーチンに関連しているものとして例示されているプロセスアラームである。このアラーム74はその優先順位が重要であることを示すために赤色で表示されている。アラームバナ−73の第二のライン上では、アラーム情報フィールド76が、アラームバナー73内の現時点で選択されているアラームと関連するアラーム情報を表示している。アラーム74が選択されている図３の例では、アラーム情報フィールド76は、アラーム74が金曜日１２時５２分１９秒に生成され、「タンク１６レベル制御」に関連しており、ＰＩＤ１０１／ＨＩ＿ＨＩ＿ＡＬＭの記号表示または名前を有し、高―高レベルの最優先順位を有し、かつ重要なアラームであることを表示している。アラーム74が点滅している場合は、アラーム74が受信了承されおらず、その一方、アラームバナ−73内の不変（点滅していない）のアラームの表示は、そのアラームがあるオペレータまたはあるユーザにより受信了承されたことを示す。もちろん、他のタイプのアラーム情報をアラーム情報フィールド76内に表示してもよい。
【００５７】
また、アラーム表示78の如き、アラームバナー73内のその他のアラーム表示は、そのアラームに関連する重要度または優先順位の他のレベルを示すために、黄色、紫色、またはその他の色彩であってもよい。アラーム78, 80, 81、82の如き他のアラームが選択された場合、そのアラームに属しているアラーム情報がアラーム情報フィールド76内に表示されうる。アラームバナ−73内のアラームを閲覧しているとき、ユーザは、そのアラームを受信了承し、保守作業員または技術者にそのアラームに至った状態を訂正するための適切なアクションを取るように警告すること、あるいは、そのアラーム状態を避けるために特定の設定値を再設定するが如き他のステップを取ることが可能である。
【００５８】
以上のように、アラーム74の如き、アラームバナ−73内のアラームのうちの一つを選択することにより、そのアラームの主制御表示画面がスクリーン71に提示される。さらに詳細にいうと、図３に示されるように、スクリーン71の主要部は、プロセス制御システム10内の特定のアラーム（選択されたアラーム）に関係する適切なハードウェアの主制御表示画面または主制御画像を有する。図３の例では、ハードウェアは、さまざまなセンサが取り付けられた三つのタンクを有しており、それらのタンクの全てはさまざまなバルブと流体のフローラインにより相互に接続されている。このハードウェア画像はプロセス制御システム10の一部の内の装置を表現したものであり、タンク、センサなどに関連する数値またはパラメータの如き、その装置の一部の動作についての情報を提供している。もちろん、この情報の一部は、データベース66内のコンフィギュレーション情報と、コントローラ12およびイーサネット接続40を介して、プロセス制御システム内のセンサからの信号とにより提供されてもよい。この場合には、そのような情報は、通信層62を介して送信され、公知または所望の任意のソフトウェアを利用してユーザ表示インターフェイス70へ提供される。
【００５９】
図４〜図６は、アラーム表示画面およびインターフェイスソフトウェア50を用いてシステムユーザまたはシステムオペレータによる利用のために提供されうるグラフィカル表示画面の一例である。図４は、システムユーザまたはシステムオペレータが図３に示されているアラームバナー73からアラームのうちの一つを選択すると、アラーム処理ソフトウェア50により表示されうるポップアップウインドウ100の一例を示している。具体的には、ユーザがフローバルブＦＶ１０１に関連するアラーム80を（たとえば、その上でダブルクリックすることにより）選択した場合、ポップアップウインドウ100が表示されうる。図４に示されるように、ポップアップウインドウ100はアラームバーまたはアラートバー１０２を有しており、そのバーのうちの一または複数は、Ｆｉｅｌｄｂｕｓデバイス32〜39のうちの一または複数（この例の場合にはフローバルブＦＶ１０１）に対する、独立して報告可能なアラームパラメータ（すなわち、ＦＡＩＬＥＤ＿ＡＬＭ、ＭＡＩＮＴ＿ＡＬＭ、およびＡＤＶＩＳＥ＿ＡＬＭ）のうちの一または複数の内のアクティブ状態を示すために強調表示されてもよい。さらに、それらのアラートバーのうちの一または複数は、ＨＡＲＴデバイス28〜31のうちの一または複数からのデバイス不良アラートもしくはデバイス不良アラーム、保守アラートもしくは保守アラーム、または勧告アラートもしくは勧告アラームに関連するアクティブ状態を示してもよい。もちろん、「故障」アラームバーは、ＦＡＩＬＥＤ＿ＡＬＭパラメータ内のアクティブ状態の結果として強調表示されてもよく、「保守が早急に必要」バーは、「ＭＡＩＮＴ＿ＡＬＭ」パラメータ内のアクティブ状態の結果として強調表示されてもよく、「勧告」バーは、「ＡＤＶＩＳＥ＿ＡＬＭ」内のアクティブ状態の結果として強調表示されてもよい。さらに、図４に示されるように、アラームバーまたはアラートバー102は、フィールドデバイス25〜39のうちのいずれか一つ内における通信不良の存在を示すために「通信不良」バーを有してもよい。
【００６０】
システムユーザまたはシステムオペレータは、ウインドウ100内の強調表示アラームまたは強調表示アラートを受信了承するために受信了承ボタン104を選択するか、あるいはこれに代えて、一または複数のアクティブアラームまたはアクティブアラートをキャンセルするためにキャンセルボックス106のうちの一つを選択しうる。さらに、所望ならば、システムユーザまたはシステムオペレータは、ウインドウ100内で現在アクティブなアラームに関連したさらなる情報を提供する他のポップアップウインドウを起動させるために「詳細」ボタン108を選択しうる。他のポップアップウインドウに関しては以下でさらに詳細に説明する。
【００６１】
また、図４は、フローバルブＦＶ１０１に関連するさらに詳細なステータス情報を有する他のポップアップウインドウ110も例示している。このステータスウインドウ110は、アイコン112、詳細ボタン108、またはアラームバーもしくはアラートバー106のうちの強調表示された一つを選択するか、あるいはその他の所望の方法によりウインドウ100から起動させることが可能である。いずれの場合であっても、ステータスウインドウ110はバー114、116、118を有しており、これらのバーの各々は、独立して報告可能なアラームまたはアラートのうちの一つに対応する。この例では、フローバルブＦＶ１０１が該フローバルブＦＶ１０１のＦＡＩＬＥＤ＿ＡＬＭパラメータ内にアクティブな状態を現在有しているので「不良」バーが強調表示されている。また、ステータスウインドウ110は、フローバルブＦＶ１０１内における故障報告に関連する、起こりうる状態の一覧表120も有している。なお、５つの状態のみがこの例においては示されているが、所望ならば、５を超える状態または５未満の状態が提供されてもよい。ウインドウ110内に示された、起こりうる状態120の各々は、そのデバイスのＦＡＩＬＥＤ＿ＡＬＭまたはデバイス不良パラメータにより報告されうる、マスキングされていないアクティブ状態に一意に対応している。さらに、ウインドウ110は勧告バー122を提供しており、該勧告バー122は、デバイスのＲＥＣＯＭＭＥＮＤＥＤ＿ＡＣＴＩＯＮパラメータに関連しかつデバイスのデバイス記述内に格納されうるテキスト情報を表示する。これに加えて、ウインドウ110は、ヘルプボタン124を有している。該へルプボタン124は、システムユーザまたはシステムオペレータにより選択されると、現在閲覧中のアラームまたはアラートを発生したデバイスの障害追跡、修理などを行うユーザまたはシステムオペレータを補助するテキスト情報を有する他のポップアップウインドウ（たとえば、図６に示され、以下で説明するヘルプウインドウ144）を起動させることが可能である。
【００６２】
図５は、圧力トランスミッタＰＴ１０１に関連するステータス情報を提供するポップアップウインドウ130の一例を示す他の図である。図５に示されるウインドウ130の一般的な形式は図４に示されたものと同一であるが、ただし、ウインドウ130は、圧力トランスミッタＰＴ１０１に保守アラートまたは保守アラームを発生させうる状態132を有している。なお、この例では、保守ボタン116が強調表示、すなわちアクティブ状態になっているが、これは、圧力トランスミッタＰＴ１０１のＭＡＩＮＴ＿ＡＬＭパラメータまたはデバイスは保守が必要パラメータに関連するマスキングされていない状態が現時点においてアクティブであることを示している。
【００６３】
図６は、フロートランスミッタＦＴ１０１に関連するステータス情報を提供するとともにフロートランスミッタＦＴ１０１のＭＡＩＮＴ＿ＡＬＭパラメータまたは「デバイスは保守が必要」パラメータにより報告されうる状態と同等または同一の状態群142を含むポップアップウインドウ140の一例を示す他の例である。また、図６は、ヘルプボタン124を選択することにより起動されうるポップアップヘルプウインドウ144も例示している。図６に示されているように、ヘルプウインドウ144は詳細のテキスト情報を有している。該テキスト情報は、フロートランスミッタＦＴ１０１のデバイス記述により提供され、アラーム表示ソフトウェア50を用いてワークステーション14に送信・表示されてもよい。
【００６４】
アラーム表示・インターフェイスソフトウェア50はＦｉｅｌｄｂｕｓデバイス、ＨＡＲＴデバイス、および４〜２０ｍＡデバイスと協働して利用されるものとして説明されてきたが、その他の外部のプロセス制御通信プロトコルを利用して実現されることも可能であり、その他のタイプのコントローラソフトウェアとともに利用されてもよい。本明細書に記載されているアラーム表示・インターフェイスソフトウェア50はソフトウェアとして実現されることが好ましいが、ハードウェア、ファームウェアなどにより実現されてもよく、プロセス制御システム10に関連するその他のプロセッサにより実行されてもよい。したがって、本明細書に記載されているルーチン50は、標準型多目的プロセッサにより実行されてもよく、所望に応じて、特定用途向けに設計されたハードウェアまたはファームウェアを利用して実行されてもよい。ソフトウェアにより実現される場合には、上述のソフトウェアルーチンは、磁気ディスク、レーザディスク、または他の格納媒体の如き任意のコンピュータ読取り可能メモリに、コンピュータまたはプロセッサのＲＡＭまたはＲＯＭなどに格納されうる。同様に、このソフトウェアは、任意の公知または所望の配送方法を利用して、ユーザまたはプロセス制御システムに配送されうる。上述の任意の公知または所望の配送方法には、たとえば、コンピュータ読取り可能ディスクもしくは他の移送可能コンピュータ格納機構による方法、または電話回線、インターネットなどの如き通信チャネルを利用する方法が含まれる。（該電話回線、インターネットなどの如き通信チャネルを利用する方法での配送は、移送可能格納媒体を介してかかるソフトウェアを提供することと同一または相互変換可能であると考えられる。）
もちろん、いうまでもなく、本明細書において記載されている独立して報告可能なアラームが三つのレベルの重要度またはタイプのアラーム（すなわち、デバイス不良、デバイス保守、および勧告）を有するものとして記載されてきたが、それの代えて、本発明の精神及び範疇から逸脱することなく三つのレベルの重要度よりも二つ以上上回る重要度レベルを用いてもよい。
【００６５】
以上のように、本発明は特定の例を参照して記載されてきたが、それらは、例示のみを意図したものであり、本発明を制限することを意図したものではない。したがって、本発明の精神および範疇から逸脱することなく開示された実施例に変更、追加、または削除を加えうることは当業者にとり明らかである。
【図面の簡単な説明】
【００６６】
【図１】機能強化アラート機能または機能強化アラーム機能を有するＦｉｅｌｄｂｕｓデバイスおよびＨＡＲＴデバイスが利用されるプロセス制御システムのブロック線図である。
【図２】図１に示されたプロセス制御システムにおいて利用されうる、内部で実行されるアラーム表示・インターフェイスシステムを有するワークステーションのブロック線図である。
【図３】図１のプロセス制御システムにおいて利用されるアラーム表示・インターフェイスシステムにより生成されうるユーザインターフェイススクリーンの一例である。
【図４】図１のプロセス制御システムにおいて利用されるアラーム表示・インターフェイスシステムにより生成されうるユーザインターフェイススクリーンの他の一例である。
【図５】図１のプロセス制御システムにおいて利用されるアラーム表示・インターフェイスシステムにより生成されうるユーザインターフェイススクリーンの他の一例である。
【図６】図１のプロセス制御システムにおいて利用されるアラーム表示・インターフェイスシステムにより生成されうるユーザインターフェイススクリーンの他の一例である。
【符号の説明】
【００６７】
10 プロセス制御ネットワークまたはプロセス制御システム
12 プロセスコントローラ
14 ホストワークステーションまたはホストコンピュータ
20, 22 入力／出力デバイス
20B、22A、22B Ｉ／Ｏカード
21 コントローラ
25~39 フィールドデバイス
40 イーサネット（登録商標）接続
42, 44 デジタルバス
50 アラーム処理ソフトウェア
51, 52, 53 ソフトウェアエレメント
62 通信層
64 アラーム処理ユニット
66 データベース
68 アラームフィルタ
69 ユーザインターフェイス
70 ユーザ表示インターフェイス
71 スクリーン
73 アラームバナー
74 最も優先順位に高いアラーム
76 アラーム情報フィールド
78、80、81、82 アラーム
90 デバイスアラーム
92 デバイスアラーム
100 ポップアップウインドウ
101 バルブ
104 受信了承ボタン
106 キャンセルボックス
108 詳細ボタン
110 ステータスウインドウ
114、116、118 バー
116 保守ボタン
120 一覧表
122 勧告バー
124 ヘルプボタン
130 ポップアップウインドウ
144 ヘルプウインドウ
【図１】
0004436046.tif 000003
【図２】
0004436046.tif 000004
【図３】
0004436046.tif 000005
【図４】
0004436046.tif 000006
【図５】
0004436046.tif 000007
【図６】
0004436046.tif 000008