5 Model ToC Previous Next

5.7 Acknowledgeable Condition Model ToC Previous Next

5.7.2 AcknowledgeableConditionType ToC Previous Next index

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

readme_files/image015.png Figure 12 – AcknowledgeableConditionType overview

Table 33 – AcknowledgeableConditionType definition

Attribute Value
BrowseName AcknowledgeableConditionType
IsAbstract False

Subtype of the ConditionType defined in clause 5.5.2.

References NodeClass BrowseName DataType TypeDefinition ModellingRule
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  
A & C Acknowledge          

Table 34 – AcknowledgeableConditionType Additional Subcomponents

BrowsePath References NodeClass BrowseName DataType TypeDefinition Others
AckedState HasProperty Variable TrueState LocalizedText PropertyType X
AckedState HasProperty Variable FalseState LocalizedText PropertyType X
ConfirmedState HasProperty Variable TrueState LocalizedText PropertyType X
ConfirmedState HasProperty Variable FalseState LocalizedText PropertyType X

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 Ackednowledged or Confirmed, they shall be set to false (not Acknowledged and not Confirmed).

Previous Next