The Acknowledgeable Condition Model extends the Condition model. States for acknowledgement and confirmation are added to the Condition model.
AcknowledgeableConditions are represented by the AcknowledgeableConditionType which is a subtype of the ConditionType. The model is formally defined in the following sub clauses.
The AcknowledgeableConditionType extends the ConditionType by defining acknowledgement characteristics. The AcknowledgeableConditionType is illustrated in Figure 1313 and formally defined in Table 3232 and Table 3333.
Figure 1313 – AcknowledgeableConditionType overview
Table 3232 – 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 3333 – 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).
The Acknowledge Method is used to acknowledge an Event Notification for a Condition instance state where AckedState is False. Normally, the NodeId of the object instance is passed as the ObjectId to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, Servers shall allow Clients to call the Acknowledge Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AcknowledgeableConditionType Node.
Signature
Acknowledge(
[in] ByteString EventId
[in] LocalizedText Comment
);
The parameters are defined in Table 3434
Table 3434 – Acknowledge parameters
|
Argument |
Description |
|
EventId |
EventId identifying a particular Event Notification. Only Event Notifications where AckedState/Id was False can be acknowledged. |
|
Comment |
A localized text that shall be applied to the Condition. |
Method result codes in Table 3535 (defined in Call Service)
Table 3535 – Acknowledge result codes
|
Result Code |
Description |
|
Bad_ConditionBranchAlreadyAcked |
See Table 137137 for the description of this result code. |
|
Bad_MethodInvalid |
The MethodId is not the well-known method of the AcknowledgeableConditionType or MethodId does not refer to a Method for the specified Object or ConditionId. |
|
Bad_EventIdUnknown |
See Table 137137 for the description of this result code. |
|
Bad_NodeIdInvalid |
Used to indicate that the specified ObjectId is not valid or that the Method was called on the AcknowledgeableConditionType Node. See 10000-4 for the general description of this result code. |
|
Bad_InvalidArgument |
The Comment string provided exceeds the allowed length for the comment or is invalid in some other manner. |
Comments
A Server is responsible to ensure that each Event has a unique EventId. This allows Clients to identify and acknowledge a particular Event Notification.
The EventId identifies a specific Event Notification with an acknowledgeable state 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. To reset the comment, an empty text with a locale shall be provided.
A valid EventId will result in an Event Notification where AckedState/Id is set to True and the Comment Property contains the text of the optional comment argument. If a previous state is acknowledged, the BranchId and all Condition values of this branch will be reported. Table 3636 specifies the AddressSpace representation for the Acknowledge Method.
Table 3636 – 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 |
||
|
ConformanceUnits |
|||||
|
A & C Acknowledge |
|||||
If Auditing is supported, this Method shall generate an Event of AuditConditionAcknowledgeEventType for all invocations of the Method.
The Confirm Method is used to confirm an Event Notifications for a Condition instance state where ConfirmedState is False. Normally, the NodeId of the object instance is passed as the ObjectId to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, Servers shall allow Clients to call the Confirm Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AcknowledgeableConditionType Node.
Signature
Confirm(
[in] ByteString EventId
[in] LocalizedTextComment
);
The parameters are defined in Table 3737
Table 3737 – Confirm Method parameters
|
Argument |
Description |
|
EventId |
EventId identifying a particular Event Notification. Only Event Notifications where the Id property of the ConfirmedState is False can be confirmed. |
|
Comment |
A localized text that shall be applied to the Conditions. |
Method result codes in Table 3838 (defined in Call Service)
Table 3838 – Confirm result codes
|
Result Code |
Description |
|
Bad_ConditionBranchAlreadyConfirmed |
See Table 137137 for the description of this result code. |
|
Bad_MethodInvalid |
The method id does not refer to a method for the specified object or ConditionId. See 10000-4 for the general description of this result code. |
|
Bad_EventIdUnknown |
See Table 137137 for the description of this result code. |
|
Bad_NodeIdInvalid |
Used to indicate that the specified ObjectId is not valid or that the Method was called on the AcknowledgeableConditionType Node. See 10000-4 for the general description of this result code. |
|
Bad_InvalidArgument |
The Comment string provided exceeds the allowed length for the comment or is invalid in some other manner. |
Comments
A Server is responsible to ensure that each Event has a unique EventId. This allows Clients to identify and confirm a particular Event Notification.
The EventId identifies a specific Event Notification with a confirmable state was reported.
A Comment can be provided which will be applied to the state identified with the EventId. If the comment argument 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 EventId will result in an Event Notification where ConfirmedState/Id is set to True and the Comment Property contains the text of the optional comment argument. If a previous state is confirmed, the BranchId and all Condition values of this branch will be reported. A Client can confirm only events that have a ConfirmedState/Id set to False. The logic for setting ConfirmedState/Id to False is Server specific and may even be event or condition specific.
Table 3939 specifies the AddressSpace representation for the Confirm Method.
Table 3939 – 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
|
||
|
ConformanceUnits |
|||||
|
A & C Confirm |
|||||
If Auditing is supported, this Method shall generate an Event of AuditConditionConfirmEventType for all invocations of the Method.