Alarms and Conditions

Alarms and ConditionsはEventTypeの拡張です。Conditionはシステムまたはその構成要素の状態を表現します。OPC UAのEventはデータが一時的でEventの発生後はヒストリEventを除きOPC UA Serverの中に残りません。これに対しConditionは状態を示す情報を持ち、それを表す構成要素の状態がある条件を満たすまでEventデータがUA Serverに残り続けるモデルをいいます。

ConditionType

ConditionTypeはBaseEventTypeのSubTypeです。ベンダーはベースタイプから派生した追加のConditionTypeを定義することが期待されています。ServerでサポートされているConditionTypeはServerのAddressSpaceで公開されます。ConditionTypeのDefinitionは以下の通りです。

ConditionTypeはBaseEventTypeのすべての Propertyを継承します。それらのセマンティクスはOPC10000-5で定義されています。

SourceNode PropertyはConditionSourceを識別します。 ConditionSourceがAddressSpaceのNodeでない場合、NodeIdはNULLに設定されます。

SourceNode Propertyは条件が関連付けられているNodeで、AlarmのInputNodeと同じである場合がありますが別個のNodeである場合もあります。たとえば、RPMである値を持つVariableであるモーターは次の条件のConditionSourceである可能性があります。モーターおよびモーターに関連する温度センサーに関連します。前者では、高RPMAlarmのInputNodeはモーターRPMの値であり、後者では、高AlarmのInputNodeはモーターに関連付けられている温度センサーの値になります。

ConditionTypeの構成要素の説明

ConditionTypeの構成要素の説明は下記の通りです。

ConditionClassId

ConditionClassIdはこの条件が使用されるドメインを指定します。 これは、BaseConditionClassTypeの対応するサブタイプのNodeIdです。このPropertyをフィルタリングに使用する場合、ClientはBaseConditionClassTypeNodeIdsのすべての個別のサブタイプを指定する必要があります。OfType演算子(指定した型のオブジェクトだけを抽出するフィルタ)は適用できません。BaseConditionClassTypeは条件をより具体的なクラスに割り当てることができない場合は常にクラスとして使用されます

ConditionClassName

ConditionClassNameはBaseConditionClassTypeのサブタイプの表示名を提供します。

ConditionSubClassId

ConditionSubClassIdは条件に適用される追加のクラスを指定します。 これは、BaseConditionClassTypeの対応するサブタイプのNodeIdです。この Propertyをフィルタリングに使用する場合、ClientはBaseConditionClassTypeNodeIdのすべての個別のサブタイプを指定する必要があります。OfType演算子(指定した型のオブジェクトだけを抽出するフィルタ)は適用できません。 Clientはサブクラスが適用されていない条件を返すために、フィルターにNULLを指定します。条件を返すときに、このオプションのフィールドが条件で使用できない場合、フィールドに対してNULLが返されます。

ConditionName

ConditionNameはEventの発生元であるConditionインスタンスを識別します。 ユーザー表示でSourceNameと一緒に使用して、異なるインスタンスを区別できます。ConditionSourceにConditionTypeのインスタンスが1つだけあり、Serverにインスタンス名がない場合、ServerはConditionTypeブラウズ名を提供する必要があります。条件インスタンスの現在の状態に関連するすべてのEvent通知のBranchIdはNULLです。

BranchId

BranchIdがNULLでない場合は、オペレーターによる注意が必要なこのConditionインスタンスの以前の状態を識別します。現在のConditionBranchが以前のConditionBranchに変換された場合、ServerはNULL以外のBranchIdを割り当てる必要があります。ブランチの初期Eventは、ConditionBranchと新しいBranchIdの値で生成されます。 ConditionBranchは、不要になる前に何度も更新できます。ConditionBranchでオペレーターの入力が不要になると、最終Eventの保持がFalseに設定されます。ConditionBranchesがOperator入力を必要とする限り、現在のEventの保持ビットはTrueです。BranchIdDataTypeはNodeIdですが、ServerのAddressSpaceにConditionBranchesがある必要はありません。NodeIdを使用すると、Serverは単純な数値識別子、文字列、またはバイトの配列を使用できます。。

Retain

Trueが条件(またはConditionBranch)を、その状態をServerの状態と同期させたいClientにとって興味深い状態にあると説明する場合に保持します。このフラグの設定方法を決定するロジックはServer固有です。 通常、すべてのアクティブなアラームには保持フラグが設定されています。 ただし、非アクティブなアラームの保持フラグをTrueに設定することもできます。Clientの保持フラグがFalseに設定されたEventを受信した場合の通常の処理は、Clientはこれを対象ではなくなったConditionBranchと見なす必要があります。「現在のアラーム表示」はConditionBranchが表示から削除されます。

EnabledState

EnabledStateは条件が有効かどうかを示します。 EnabledState / Idは有効な場合はTrue、それ以外の場合はFalseです。 EnabledState / TransitionTimeは、EnabledStateが最後に変更された日時を定義します。条件のEnabledStateは、Event通知の生成に影響を与えるため、次のようになります。

次の特定の動作:

・条件インスタンスが無効状態に入るとServerによってこの条件の保持PropertyがFalseに設定され、条件インスタンスが現在Clientに関心がないことをServerに示します。 ブランチが存在する場合、これにはすべてのConditionBranchesが含まれます。

・Conditionインスタンスが有効状態に入ると、Conditionが評価され、そのすべてのPropertyが現在の値を反映するように更新されます。 この評価が原因である場合任意のConditionBranchに対してRetainPropertyをTrueに移行するとConditionBranchに対してEvent通知が生成されます。

・条件インスタンスが無効状態に入るとServerによってこの条件の保持PropertyがFalseに設定され、条件インスタンスが現在Clientに関心がないことをClientに示します。 ブランチが存在する場合、これにはすべてのConditionBranchesが含まれます。 ・Serverは、無効になっている間、Conditionインスタンスのテストを続行することを選択できます。ただし、Conditionインスタンスが無効になっている間のEvent通知は生成されません。

・AddressSpaceに存在する条件の場合、Attributeとそれに続くVariableは、無効状態でも引き続き有効な値を持ちます。EventId、Eventタイプ、ソースノード、ソース名、時間、およびEnabledState。 他のPropertyは、現在の有効な値を提供しなくなる可能性があります。 提供されなくなったすべてのVariableは、Bad_ConditionDisabledのステータスを返します。 無効状態を報告するEventは、PropertyをNULLまたはステータスBad_ConditionDisabledとして報告する必要があります。

有効にすると次のコンポーネントを変更するとConditionTypeEvent通知が発生します。

・品質
・重大度(基本Eventタイプから継承)
・共通

Quality

これは完全なリストではない可能性があります。 サブタイプはEvent通知をトリガーする追加のVariableを定義する場合があります。 一般に、タイプTwoStateVariableTypeまたはConditionVariableTypeのVariableへの変更は、Event通知をトリガーします。品質は、この条件インスタンスが基づいているプロセス値またはその他のリソースのステータスを明らかにします。 たとえば、プロセス値が「不確実」である場合、関連する「LevelAlarm」条件も疑わしいです。Qualityの値は、OPC10000-8で定義されているOPCStatusCodes のいずれか、およびOPC 10000-4で定義されているGood、Uncertain、Badのいずれかです。これらのStatusCodeは、さまざまなフィールドバス仕様のデータ品質の説明と似ていますが少し一般的です。 内部ステータス情報をこれらのコードにマッピングするのはServerの責任です。 品質情報をサポートしないServerはGoodを返します。この品質はこの値またはリソースに基づいており、このアラームが受信されたシステムに関連付けられた通信ステータスを反映することもできます。基盤となるシステムへの通信エラー、特に一部の使用できないEventフィールドが発生するエラーの場合、品質、Bad_NoCommunicationエラーになります。

Events

Eventは、RetainフィールドがTrueに設定されている条件、およびRetainフィールドのTrueからFalseへの最初の遷移に対してのみ生成されます。

LastSeverity

LastSeverityはConditionBranchの以前の重大度を提供します。 最初、このVariableにはゼロ値が含まれています。 重大度が変更された後にのみ値を返します。新しい重大度はBaseEventTypeから継承されるSeverityPropertyを介して提供されます。

Comment

コメントには、特定の状態(ConditionBranch)に対して提供された最後のコメントが含まれます。AddCommentMethod、他のMethod、または他の方法で提供された可能性があります。このVariableの初期値は他の方法で提供されない限りNULLです。Methodがオプションとしてコメントを設定する機能を提供する場合、オプションのコメントが提供されていなければこのVariableの値はNULLにリセットされます。

ClientUserId

ClientUserIdはコメントフィールドに関連しており、最新のコメントを挿入したユーザーのIDが含まれています。 ClientUserIdを取得するロジックは、OPC10000-5で定義されています。ConditionインスタンスのNodeIdがConditionIdとして使用されます。 ConditionTypeのコンポーネントとして明示的にモデル化されていません。

条件状態モデル

条件状態モデルは下記のように遷移します。

基本条件状態モデル

基本条件状態モデルは次の図の通りです。ServerまたはSeverの下のデバイスまたは基盤となるシステム内で条件をオフにできるようにすることを目的としています。 Enabled Stateは通常、サブ状態を追加することで拡張されます。

Acknowledgeable Conditions

AcknowledgeableConditionはConditionTypeのサブタイプです。AcknowledgeableConditionは状態を公開し、Conditionを確認または確認する必要があるかどうかを示します。AckedStateとConfirmedStateは条件で定義されたEnabledStateを拡張します。EnabledStateはAckedStateとオプションによりConfirmedStateを追加することによって拡張されます。

基本的なAcknowledge Stateモデルを図に示します。このモデルはAckedStateを定義しますが、状態の変化をもたらす特定の状態の変化はServerの実装によって異なります。一般的なAlarmモデルでは変更はアクティブ状態への遷移またはアクティブ状態内の遷移に制限されます。ただし、より複雑なモデルでは条件が非アクティブ状態に移行したときにAckedStateを変更することもできます。

基本的な確認応答に確認を追加することにより複雑な状態モデルを図に示します。確認済み確認応答モデルは通常、区別するために使用されます。条件の存在を認め、条件に対処するために何かをしたこと、たとえば、モーターの高温通知を受信したオペレーターは、Acknowledge Methodを呼び出し高温が観測されたことをSeverに通知します。次に、オペレーターは、温度を下げるためにモーターの負荷を下げるなどのアクションを実行します。次に、オペレーターはComfiremed Methodを呼び出し修正措置が取られたことをServerに通知します。