AlarmsとConditions
AlarmsとConditionsはEventTypeの拡張です。Conditionは、システムまたはその構成要素の状態を表現します。OPC UAのEventは、データが一時的で、Eventは発生後、ヒストリEventを除きOPC UA Serverの中に残りません。これに対し、Conditionは状態を示す情報を持ち、それを表す構成要素のConditionがある条件を満たすまでEventデータがUA Serverに残り続けるモデルをいいます。
ConditionType
ConditionTypeはBaseEventTypeのSubTypeです。ベンダーは、ConditionTypeから派生した追加のConditionTypeを定義することが期待されています。ServerでサポートされているConditionTypeは、ServerのAddressSpaceで公開されます。ConditionTypeのDefinitionは以下の通りです。
ConditionTypeの構成要素の説明
ConditionTypeの構成要素の説明は下記の通りです。
ConditionClassId
ConditionClassIdはこの条件が使用されるドメインを指定します。 これは、BaseConditionClassTypeの対応するサブタイプのNodeIdです。このPropertyをフィルタリングに使用する場合、ClientはBaseConditionClassTypeNodeIdsのすべての個別のサブタイプを指定する必要があります。OfType演算子（指定した型のオブジェクトだけを抽出するフィルタ）は適用できません。BaseConditionClassTypeは条件をより具体的なクラスに割り当てることができない場合は常にクラスとして使用されます
ConditionClassName
ConditionClassNameはBaseConditionClassTypeのサブタイプの表示名を提供します。
ConditionSubClassId
ConditionSubClassIdは条件に適用される追加のクラスを指定します。 これは、BaseConditionClassTypeの対応するサブタイプのNodeIdです。この Propertyをフィルタリングに使用する場合、ClientはBaseConditionClassTypeNodeIdのすべての個別のサブタイプを指定する必要があります。Clientは、サブクラスが適用されていない条件を返すために、フィルターにNULLを指定します。条件を返すときに、このオプションのフィールドが条件で使用できない場合、フィールドに対してNULLが返されます。
ConditionName
ConditionNameは、Eventの発生元であるConditionインスタンスを識別します。 ユーザー表示でSourceNameと一緒に使用し、異なるインスタンスを区別できます。ConditionSourceにConditionTypeのインスタンスが1つだけあり、Serverにインスタンス名がない場合、ServerはConditionTypeブラウズ名を提供する必要があります。条件インスタンスの現在の状態に関連するすべてのEvent通知のBranchIdはNULLです。
BranchId
現在のConditionBranchが、以前のConditionBranchに変換された場合、ServerはNULL以外のBranchIdを割り当てる必要があります。ブランチの初期Eventは、ConditionBranchと新しいBranchIdの値で生成されます。 ConditionBranchは、不要になる前に何度も更新できます。ConditionBranchでオペレーターの入力が不要になると、最終Eventの保持がFalseに設定されます。ConditionBrancheがOperator入力を必要とする限り、現在のEventの保持を表すビットはTrueです。BranchIdDataTypeはNodeIdですが、ServerのAddressSpaceにConditionBranchesがある必要はありません。NodeIdを使用すると、Serverは単純な数値識別子、文字列、またはバイトの配列を使用できます。
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、EventType、SourceNode、SourceName、Timeは、EnabledStateは、無効状態でも引き続き有効な値を持ちます。他のPropertyは、現在の有効な値を提供しなくなる可能性があります。 提供されなくなったすべてのVariableは、Bad_ConditionDisabledのステータスを返します。 無効状態を報告するEventは、PropertyをNULLまたはステータスBad_ConditionDisabledとして報告する必要があります。
・品質
・重大度（基本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に通知します。次に、オペレーターは、温度を下げるためにモーターの負荷を下げるなどのアクションを実行します。次に、オペレーターはConfirmed Methodを呼び出し修正措置が取られたことをServerに通知します。
