The AcknowledgeableConditionType extends the ConditionType by defining acknowledgement characteristics. The AcknowledgeableConditionType is illustrated in Figure 13 and formally defined in Table 34 and Table 35.

image016.png

Figure 13 – AcknowledgeableConditionType overview

Table 34 – AcknowledgeableConditionType definition

Attribute

Value

BrowseName

AcknowledgeableConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the ConditionType defined in clause 5.5.2.

HasSubtype

ObjectType

AlarmConditionType

Defined in Clause 5.8.2

HasComponent

Variable

AckedState

LocalizedText

TwoStateVariableType

Mandatory

HasComponent

Variable

ConfirmedState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Method

Acknowledge

Defined in Clause 5.7.3

Mandatory

HasComponent

Method

Confirm

Defined in Clause 5.7.4

Optional

ConformanceUnits

A & C Acknowledge

Table 35 – AcknowledgeableConditionType Additional Subcomponents

BrowsePath

References

NodeClass

BrowseName

DataType

TypeDefinition

Others

AckedState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

AckedState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

ConfirmedState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

ConfirmedState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

The empty Others” column indicates that no ModellingRule applies.

The AcknowledgeableConditionType inherits all Properties of the ConditionType.

AckedState when False indicates that the Condition instance requires acknowledgement for the reported Condition state. When the Condition instance is acknowledged the AckedState is set to True. ConfirmedState indicates whether it requires confirmation. Recommended state names are described in A.1. The two states are sub-states of the True EnabledState. See 4.3 for more information about acknowledgement and confirmation models. The EventId used in the Event Notification is considered the identifier of this state and has to be used when calling the Methods for acknowledgement or confirmation.

A Server may require that previous states be acknowledged. If the acknowledgement of a previous state is still open and a new state also requires acknowledgement, the Server shall create a branch of the Condition instance as specified in 4.2. Clients are expected to keep track of all ConditionBranches where AckedState/Id is False to allow acknowledgement of those. See also 5.5.2 for more information about ConditionBranches and the examples in Clause B.1. The handling of the AckedState and branches also applies to the ConfirmedState.

In the event of a restart of an AlarmManager, the AlarmManager should recover the AckedState and ConfirmedState (if supported) of all current conditions. If the system can not determine if the condition is Acknowledged or Confirmed, they shall be set to false (not Acknowledged and not Confirmed).