The AcknowledgeableConditionType extends the ConditionType by defining acknowledgement characteristics. It is an abstract type. The AcknowledgeableConditionType is illustrated in Figure 11 and formally defined in Table 28.
Figure 11 – AcknowledgeableConditionType overview
Table 28 – AcknowledgeableConditionType definition
Subtype of the ConditionType defined in clause 5.5.2.
|HasSubtype||ObjectType||AlarmConditionType||Defined in Clause 5.8.2|
|HasComponent||Method||Acknowledge||Defined in Clause 5.7.3||Mandatory|
|HasComponent||Method||Confirm||Defined in Clause 5.7.4||Optional|
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 Annex A. 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.4. 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.