The AcknowledgeableConditionModel extends the Conditionmodel. States for acknowledgement and confirmation are added to the Conditionmodel.
AcknowledgeableConditionsare represented by the AcknowledgeableConditionTypewhich is a subtype of the ConditionType. The model is formally defined in the following sub clauses.
The AcknowledgeableConditionTypeextends the ConditionTypeby defining acknowledgement characteristics. It is an abstract type. The AcknowledgeableConditionTypeis illustrated in Figure 11and formally defined in Table 28.
Figure 11– AcknowledgeableConditionType overview
Table 28– AcknowledgeableConditionType definition
Attribute |
Value |
||||
BrowseName |
AcknowledgeableConditionType |
||||
IsAbstract |
False |
||||
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
Subtype of the ConditionType defined inclause 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 |
The AcknowledgeableConditionTypeinherits all Propertiesof the ConditionType.
AckedStatewhen False indicates that the Conditioninstance requires acknowledgement for the reported Conditionstate. When the Conditioninstance is acknowledged the AckedStateis set to True. ConfirmedStateindicates whether it requires confirmation. Recommended state names are described in Annex A. The two states are sub-states of the True EnabledState. See 4.3for more information about acknowledgement and confirmation models. The EventIdused in the Event Notificationis considered the identifier of this state and has to be used when calling the Methodsfor acknowledgement or confirmation.
A Servermay require that previous states be acknowledged. If the acknowledgement of a previous state is still open and a new state also requires acknowledgement, the Servershall create a branch of the Conditioninstance as specified in 4.4.Clientsare expected to keep track of all ConditionBrancheswhere AckedState/Id is False to allow acknowledgement of those. See also 5.5.2for more information about ConditionBranchesand the examples in Clause B.1. The handling of the AckedStateand branches also applies to the ConfirmedState.
TheAcknowledge Methodis used to acknowledge an Event Notificationfor a Conditioninstance state where AckedStateis False. Normally, the NodeIdof the object instance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the Acknowledge Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AcknowledgeableConditionType Node.
Signature
Acknowledge(
[in] ByteString EventId
[in] LocalizedText Comment
);
The parameters are defined in Table 29
Table 29– Acknowledge parameters
Argument |
Description |
EventId |
EventId identifying a particular Event Notification. Only Event Notificationswhere AckedState/Id was False can be acknowledged. |
Comment |
A localized text to be applied to the Condition. |
Methodresult codes in Table 30(defined in Call Service)
Table 30– Acknowledge result codes
Result Code |
Description |
Bad_ConditionBranchAlreadyAcked |
See Table 103for the description of this result code. |
Bad_MethodInvalid |
The method id does not refer to a method for the specified object or ConditionId. |
Bad_EventIdUnknown |
See Table 103for the description of this result code. |
Bad_NodeIdInvalid |
Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node. See OPC 10000-4for the general description of this result code. |
Comments
A Serveris responsible to ensure that each Eventhas a unique EventId. This allows Clientsto identify and acknowledge a particular Event Notification.
The EventIdidentifies a specific Event Notificationwhere a state to be acknowledged was reported. Acknowledgement and the optional comment will be applied to the state identified with the EventId. If the comment field is NULL (both locale and text are empty) it will be ignored and any existing comments will remain unchanged. If the comment is to be reset, an empty text with a locale shall be provided.
A valid EventIdwill result in an Event Notificationwhere AckedState/Id is set to True and the Comment Propertycontains the text of the optional comment argument. If a previous state is acknowledged, the BranchIdand all Conditionvalues of this branch will be reported. Table 31specifies the AddressSpacerepresentation for the Acknowledge Method.
Table 31– Acknowledge Method AddressSpace definition
Attribute |
Value |
||||||
BrowseName |
Acknowledge |
||||||
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
||
HasProperty |
InputArguments |
Argument[] |
PropertyType |
Mandatory |
|||
AlwaysGeneratesEvent |
ObjectType |
AuditConditionAcknowledge EventType |
Defined in 5.10.5 |
TheConfirm Methodis used to confirm an Event Notificationsfor a Conditioninstance state where ConfirmedStateis False. Normally, the NodeIdof the object instance is passed as the ObjectIdto the Call Service. However, some Serversdo not expose Conditioninstances in the AddressSpace. Therefore, Serversshall allow Clientsto call the Confirm Methodby specifying ConditionIdas the ObjectId.The Methodcannot be called with an ObjectIdof the AcknowledgeableConditionType Node.
Signature
Confirm(
[in] ByteString EventId
[in] LocalizedTextComment
);
The parameters are defined in Table 32
Table 32– Confirm Method parameters
Argument |
Description |
EventId |
EventIdidentifying a particular Event Notification. Only Event Notificationswhere the Id property of the ConfirmedState is False can be confirmed. |
Comment |
A localized text to be applied to the Conditions. |
Methodresult codes in Table 33(defined in Call Service)
Table 33– Confirm result codes
Result Code |
Description |
Bad_ConditionBranchAlreadyConfirmed |
See Table 103for the description of this result code. |
Bad_MethodInvalid |
The method id does not refer to a method for the specified object or ConditionId. See OPC 10000-4for the general description of this result code. |
Bad_EventIdUnknown |
See Table 103for the description of this result code. |
Bad_NodeIdUnknown |
Used to indicate that the specified ObjectIdis not valid or that the Methodwas called on the ConditionType Node. See OPC 10000-4for the general description of this result code. |
Comments
A Serveris responsible to ensure that each Eventhas a unique EventId. This allows Clientsto identify and confirm a particular Event Notification.
The EventIdidentifies a specific Event Notificationwhere a state to be confirmed was reported. A Commentcan be provided which will be applied to the state identified with the EventId.
A valid EventIdwill result in an Event Notificationwhere ConfirmedState/Id is set to True and the Comment Propertycontains the text of the optional comment argument. If a previous state is confirmed, the BranchIdand all Conditionvalues of this branch will be reported. A Clientcan confirm only events that have a ConfirmedState/Id set to False. The logic for setting ConfirmedState/Id to False is Serverspecific and may even be event or condition specific.
Table 34specifies the AddressSpacerepresentation for the Confirm Method.
Table 34– Confirm Method AddressSpace definition
Attribute |
Value |
||||
BrowseName |
Confirm |
||||
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
HasProperty |
InputArguments |
Argument[] |
PropertyType |
Mandatory |
|
AlwaysGeneratesEvent |
ObjectType |
AuditConditionConfirmEventType |
Defined in 5.10.7
|