The Alarm and Condition model extends the OPC UA base Event model by defining various Event Types based on the BaseEventType. All of the Event Types defined in this standard can be further extended to form domain or Server specific Alarm and Condition Types.

Instances of Alarm and Condition Types may be optionally exposed in the AddressSpace in order to allow direct access to the state of an Alarm or Condition. Instances not exposed in the AddressSpace still have a ConditionId (NodeId). This NodeId can be the target of references in the AddressSpace even though the target node does not exist in the AddressSpace. For example, an AlarmGroup might reference a number of Conditions that do not exist in the AddressSpace.

The following sub clauses define the OPC UA Alarm and Condition Types. Figure 8 informally describes the hierarchy of these Types. Subtypes of the LimitAlarmType and the DiscreteAlarmType are not shown.

image011.png

Figure 8 – ConditionType hierarchy

Most states defined in this standard are simple – i.e. they are either True or False. The TwoStateVariableType is introduced specifically for this use case. More complex states are modelled by using a StateMachineType defined in 10000-16.

The TwoStateVariableType is derived from the StateVariableType defined in 10000-16. and formally defined in Table 3.

Table 3 – TwoStateVariableType definition

Attribute

Value

BrowseName

TwoStateVariableType

DataType

LocalizedText

ValueRank

-1 (-1 = Scalar)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the StateVariableType defined in 10000-16.

Note that a Reference to this subtype is not shown in the definition of the StateVariableType

HasProperty

Variable

Id

Boolean

PropertyType

Mandatory

HasProperty

Variable

TransitionTime

UtcTime

PropertyType

Optional

HasProperty

Variable

EffectiveTransitionTime

UtcTime

PropertyType

Optional

HasProperty

Variable

TrueState

LocalizedText

PropertyType

Optional

HasProperty

Variable

FalseState

LocalizedText

PropertyType

Optional

ConformanceUnits

A & C Basic

The Value Attribute of an instance of TwoStateVariableType contains the current state as a human readable name. The EnabledState for example, might contain the name “Enabled” when True and “Disabled” when False.

Id is inherited from the StateVariableType and overridden to reflect the required DataType (Boolean). The value shall be the current state, i.e. either True or False.

TransitionTime specifies the time when the current state was entered.

EffectiveTransitionTime specifies the time when the current state or one of its sub states was entered. If, for example, a LevelAlarm is active and – while active – switches several times between High and HighHigh, then the TransitionTime stays at the point in time where the Alarm became active whereas the EffectiveTransitionTime changes with each shift of a sub state.

The optional Property EffectiveDisplayName from the StateVariableType is used if a state has sub states. It contains a human readable name for the current state after taking the state of any SubStateMachines in account. As an example, the EffectiveDisplayName of the EnabledState could contain “Active/HighHigh” to specify that the Condition is active and has exceeded the HighHigh limit.

Other optional Properties of the StateVariableType have no defined meaning for TwoStateVariableType.

TrueState and FalseState contain the localized string for the TwoStateVariableType value when its Id Property has the value True or False, respectively. Since the two Properties provide meta-data for the Type, Servers shall not allow these Properties to be selected in the Event filter for a MonitoredItem. The TrueState Property and FalseState Property shall only exist on InstanceDeclarations. See Figure 9 for an illustration. Clients can use the Read Service to get the values of the TrueState and FalseState Property.

A HasTrueSubState Reference is used to indicate that the True state has sub states.

A HasFalseSubState Reference is used to indicate that the False state has sub states.

image012.png

Figure 9 - TwoStateVariable Illustration

Various information elements of a Condition are not considered to be states. However, a change in their value is considered important and supposed to trigger an Event Notification. These information elements are called ConditionVariable.

ConditionVariables are represented by a ConditionVariableType, formally defined in Table 4.

Table 4 – ConditionVariableType definition

Attribute

Value

BrowseName

ConditionVariableType

DataType

BaseDataType

ValueRank

-2 (-2 = Any)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseDataVariableType defined in 10000-5.

HasProperty

Variable

SourceTimestamp

UtcTime

PropertyType

Mandatory

ConformanceUnits

A & C Basic

SourceTimestamp indicates the time of the last change of the Value of this ConditionVariable. It shall be the same time that would be returned from the Read Service inside the DataValue structure for the ConditionVariable Value Attribute.

This Clause defines ReferenceTypes that are needed beyond those already specified as part of 10000-3 and 10000-5. This includes extending TwoStateVariableType state machines with sub states and the addition of Alarm grouping.

The TwoStateVariableType References will only exist when sub states are available. For example, if a TwoStateVariableType machine is in a False State, then any sub states referenced from the True state will not be available. If an Event is generated while in the False state and information from the True state sub state is part of the data that is to be reported than this data would be reported as a NULL. With this approach, TwoStateVariableTypes can be extended with subordinate state machines in a similar fashion to the StateMachineType defined in 10000-16.

The HasTrueSubState ReferenceType is a concrete ReferenceType that can be used directly. It is a subtype of the NonHierarchicalReferences ReferenceType.

The semantics indicate that the sub state (the target Node) is a subordinate state of the True super state. If more than one state within a Condition is a sub state of the same super state (i.e. several HasTrueSubState References exist for the same super state) they are all treated as independent sub states. The representation in the AddressSpace is specified in Table 5.

The SourceNode of the Reference shall be an instance of a TwoStateVariableType and the TargetNode shall be either an instance of a TwoStateVariableType or an instance of a subtype of a StateMachineType.

It is not required to provide the HasTrueSubState Reference from super state to sub state, but it is required that the sub state provides the inverse Reference (IsTrueSubStateOf) to its super state.

Table 5 – HasTrueSubState ReferenceType

Attributes

Value

BrowseName

HasTrueSubState

InverseName

IsTrueSubStateOf

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

ConformanceUnits

A & C Basic

The HasFalseSubState ReferenceType is a concrete ReferenceType that can be used directly. It is a subtype of the NonHierarchicalReferences ReferenceType.

The semantics indicate that the sub state (the target Node) is a subordinate state of the False super state. If more than one state within a Condition is a sub state of the same super state (i.e. several HasFalseSubState References exist for the same super state) they are all treated as independent sub states. The representation in the AddressSpace is specified in Table 6.

The SourceNode of the Reference shall be an instance of a TwoStateVariableType and the TargetNode shall be either an instance of a TwoStateVariableType or an instance of a subtype of a StateMachineType.

It is not required to provide the HasFalseSubState Reference from super state to sub state, but it is required that the sub state provides the inverse Reference (IsFalseSubStateOf) to its super state.

Table 6 – HasFalseSubState ReferenceType

Attributes

Value

BrowseName

HasFalseSubState

InverseName

IsFalseSubStateOf

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

ConformanceUnits

A & C Basic

The HasAlarmSuppressionGroup ReferenceType is a concrete ReferenceType that can be used directly. It is a subtype of the HasComponent ReferenceType. The representation in the AddressSpace is specified in Table 7

This ReferenceType binds an AlarmSuppressionGroup to an Alarm.

The SourceNode of the Reference shall be an instance of an AlarmConditionType or sub type. The TargetNode shall be an instance of an AlarmGroupType.

Table 7 – HasAlarmSuppressionGroup ReferenceType

Attributes

Value

BrowseName

HasAlarmSuppressionGroup

InverseName

IsAlarmSuppressionGroupOf

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

ConformanceUnits

A & C Suppression Group

The AlarmGroupMember ReferenceType is a concrete ReferenceType that can be used directly. It is a subtype of the Organizes Reference Type.

This ReferenceType is used to indicate the Alarm instances that are part of an Alarm Group. The representation in the AddressSpace is specified in Table 8

The SourceNode of the Reference shall be an instance of an AlarmGroupType or sub type of it. The TargetNode shall be an instance of an AlarmConditionType or a subtype of it.

Table 8 – AlarmGroupMember ReferenceType

Attributes

Value

BrowseName

AlarmGroupMember

InverseName

MemberOfAlarmGroup

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

ConformanceUnits

A & C Suppression Group

A & C First in Group Alarm

The Alarm SuppressionGroupMember ReferenceType is a concrete ReferenceType that can be used directly. It is a subtype of the AlarmGroupMember ReferenceType.

This ReferenceType is used to indicate the Alarm instances or Boolean Variables that are part of an Alarm Group. The representation in the AddressSpace is specified in Table 9

The SourceNode of the Reference shall be an instance of an AlarmGroupType or sub type of it. The TargetNode shall be an instance of an AlarmConditionType or a subtype of it, or an instance of BaseDataVariableType that has a DataType of Boolean.

Table 9 – AlarmSuppressionGroupMember ReferenceType

Attributes

Value

BrowseName

AlarmSuppressionGroupMember

InverseName

MemberOfAlarmSuppressionGroup

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

ConformanceUnits

A & C Suppression Group

The Condition model extends the Event model by defining the ConditionType. The ConditionType introduces the concept of states differentiating it from the base Event model. Unlike the BaseEventType, Conditions are not transient. The ConditionType is further extended into Dialog and AcknowledgeableConditionType, each of which has their own sub-types.

The Condition model is illustrated in Figure 10 and formally defined in the subsequent tables. It is worth noting that this figure, like all figures in this document, is not intended to be complete. Rather, the figures only illustrate information provided by the formal definitions.

image013.png

Figure 10 – Condition model

The ConditionType defines all general characteristics of a Condition. All other ConditionTypes derive from it. It is formally defined in Table 10 and Table 11. The False state of the EnabledState shall not be extended with a sub state machine.

Table 10 – ConditionType definition

Attribute

Value

BrowseName

ConditionType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in 10000-5

HasSubtype

ObjectType

DialogConditionType

Defined in Clause 5.6.2

HasSubtype

ObjectType

AcknowledgeableConditionType

Defined in Clause 5.7.2

HasProperty

Variable

ConditionClassId

NodeId

PropertyType

Mandatory

HasProperty

Variable

ConditionClassName

LocalizedText

PropertyType

Mandatory

HasProperty

Variable

ConditionName

String

PropertyType

Mandatory

HasProperty

Variable

BranchId

NodeId

PropertyType

Mandatory

HasProperty

Variable

Retain

Boolean

PropertyType

Mandatory

HasProperty

Variable

SupportsFilteredRetain

Boolean

PropertyType

HasComponent

Variable

EnabledState

LocalizedText

TwoStateVariableType

Mandatory

HasComponent

Variable

Quality

StatusCode

ConditionVariableType

Mandatory

HasComponent

Variable

LastSeverity

UInt16

ConditionVariableType

Mandatory

HasComponent

Variable

Comment

LocalizedText

ConditionVariableType

Mandatory

HasProperty

Variable

ClientUserId

String

PropertyType

Mandatory

HasComponent

Method

Disable

Defined in Clause 5.5.4

Mandatory

HasComponent

Method

Enable

Defined in Clause 5.5.5

Mandatory

HasComponent

Method

AddComment

Defined in Clause 5.5.6

Mandatory

HasComponent

Method

ConditionRefresh

Defined in Clause 5.5.7

HasComponent

Method

ConditionRefresh2

Defined in Clause 5.5.8

ConformanceUnits

A & C Basic

Table 11 – ConditionType Additional Subcomponents

BrowsePath

References

NodeClass

BrowseName

DataType

TypeDefinition

Others

EnabledState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

EnabledState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

The empty “Others” column indicates that no ModellingRule applies.

The ConditionType inherits all Properties of the BaseEventType. Their semantic is defined in 10000-5. SourceNode Property identifies the ConditionSource. See 5.12 for more details. If the ConditionSource is not a Node in the AddressSpace, the NodeId is set to NULL. The SourceNode Property is the Node, which the Condition is associated with, it may be the same as the InputNode for an Alarm, but it may be a separate node. For example, a motor, which is a Variable with a Value that is an RPM, may be the ConditionSource for Conditions that are related to the motor as well as a temperature sensor associated with the motor. In the former the InputNode for the High RPM Alarm is the value of the Motor RPM, while in the later the InputNode of the High Alarm would be the value of the temperature sensor that is associated with the motor.

ConditionClassId, ConditionClassName, ConditionSubClassId and ConditionSubClassName originally defined in ConditionType are now defined in the BaseEventType (from which this type is derived). They are optional in the BaseEventType, but ConditionClassId, and ConditionClassName are Mandatory in ConditionType and thus listed(to update the modelling rule).

ConditionName identifies the Condition instance that the Event originated from. It can be used together with the SourceName in a user display to distinguish between different Condition instances. If a ConditionSource has only one instance of a ConditionType, and the Server has no instance name, the Server shall supply the name element of the BrowseName of the ConditionType.

BranchId is NULL for all Event Notifications that relate to the current state of the Condition instance. If BranchId is not NULL, it identifies a previous state of this Condition instance that still needs attention by an Operator. If the current ConditionBranch is transformed into a previous ConditionBranch then the Server needs to assign a non-NULL BranchId. An initial Event for the branch will generated with the values of the ConditionBranch and the new BranchId. The ConditionBranch can be updated many times before it is no longer needed. When the ConditionBranch no longer requires Operator input the final Event will have Retain set to False. The retain bit on the current Event is True, as long as any ConditionBranches require Operator input. See 4.2 for more information about the need for creating and maintaining previous ConditionBranches and Clause B.1 for an example using branches. The BranchId DataType is NodeId although the Server is not required to have ConditionBranches in the AddressSpace. The use of a NodeId allows the Server to use simple numeric identifiers, strings or arrays of bytes.

Retain when True describes a Condition (or ConditionBranch) as being in a state that is interesting for a Client wishing to synchronize its state with the Server’s state. The logic to determine how this flag is set is Server specific. Typically, all Active Alarms would have the Retain flag set; however, it is also possible for inactive Alarms to have their Retain flag set to True.

In normal processing when a Client receives an Event with the Retain flag set to False, the Client should consider this as a ConditionBranch that is no longer of interest, in the case of a “current Alarm display” the ConditionBranch would be removed from the display.

SupportsFilteredRetain Property is only provided on the ConditionType. When this Property is set to True on the Type, then the Server provides a Client specific Retain flag value taking into account any Client provided filter. When the property is False on the ConditionType then the Server does not provide a Client specific the value of the Retain flag. For example, if a Client applies a filter to exclude Alarms that are shelved, and the SupportsFilteredRetain is set to True, the Client receives an Alarm (it is not shelved, Retain is true). The Client (or another Client) shelves the Alarm. At this point the Alarm no longer passes the filter, but since the previous event was sent, this event is transmitted with Retain = False. For an example see B.1.4

image014.png

Figure 11 - SupportsFilteredRetain process

Figure 11 provides an illustration of the processing a Server shall follow for processing Retain flag when SupportsFilteredRetain flag is set to True.

EnabledState indicates whether the Condition is enabled. EnabledState/Id is True if enabled, False otherwise. EnabledState/TransitionTime defines when the EnabledState last changed. Recommended state names are described in A.1.

A Condition’s EnabledState effects the generation of Event Notifications and as such results in the following specific behaviour:

When enabled, changes to the following Variables shall cause a ConditionType Event Notification:

This may not be the complete list. Subtypes of ConditionType may define additional Variables that trigger Event Notifications. In general, changes to Variables of the types TwoStateVariableType, ConditionVariableType, StateMachineType or any of their subtypes trigger Event Notifications and are not explicitly described in subtypes.

In the event of a restart of an AlarmManager, the AlarmManager shall recover the Enabled/Disabled states of all current conditions. If the system can not determine if the Condition is Enabled or Disabled, it shall be Enabled.

Quality reveals the status of process values or other resources that this Condition instance is based upon. If, for example, a process value is “Uncertain”, the associated “LevelAlarm” Condition is also questionable. Values for the Quality can be any of the OPC StatusCodes defined in 10000-8 as well as Good, Uncertain and Bad as defined in 10000-4. These StatusCodes are similar to but slightly more generic than the description of data quality in the various field bus specifications. It is the responsibility of the Server to map internal status information to these codes. A Server that supports no quality information shall return Good. This quality can also reflect the communication status associated with the system that this value or resource is based on and from which this Alarm was received. For communication errors to the underlying system, especially those that result in some unavailable Event fields, the quality shall be Bad_NoCommunication error.

Events are only generated for Conditions that have their Retain field set to True and for the initial transition of the Retain field from True to False.

LastSeverity provides the previous severity of the ConditionBranch. Initially this Variable contains a zero value; it will return a value only after a severity change. The new severity is supplied via the Severity Property, which is inherited from the BaseEventType.

Comment contains the last comment provided for a certain state (ConditionBranch) of a Condition. It may have been provided by an AddComment Method, some other Method or in some other manner. Any change in this field, shall trigger a new event to be generated. The initial value of this Variable is NULL, unless it is provided in some other manner.

ClientUserId is related to the Comment field and contains the identity of the user who inserted the most recent Comment. The logic to obtain the ClientUserId is defined in 10000-5.

The NodeId of the Condition instance is used as ConditionId. It is not explicitly modelled as a component of the ConditionType. However, it can be requested with the following SimpleAttributeOperand (see Table 12) in the SelectClause of the EventFilter: See 10000-4 for a detailed definition of the SelectClause in an Event Subscription.

Table 12 – ConditionId SimpleAttributeOperand Illustration

Name

Type

Description

SimpleAttributeOperand

typeId

NodeId

NodeId of the ConditionType Node

browsePath[]

QualifiedName

empty

attributeId

IntegerId

Id of the NodeId Attribute

Conditions are Objects which have a state which changes over time. Each Condition instance has a ConditionId as an identifier which uniquely identifies it within the Server. This Condition (and it representative ConditionId) follows the same rules associated with Nodes (and their representative NodeIds) in the AddressSpace (see 10000-3). Therefore, once a Condition is created in a system that does not expose instances, any time that Condition is active it shall always have the same ConditionId. This allows higher level alarm management systems to operate on Conditions and to perform analysis of them.

A Condition instance may be an Object that appears in the Server Address Space. If this is the case the ConditionId shall be the NodeId for the Object.

The state of a Condition instance at any given time is the set values for the Variables that belong to the Condition instance. If one or more Variable values change the Server generates an Event with a unique EventId.

If a Client calls Refresh the Server will report the current state of a Condition instance by re-sending the last Event (i.e. the same EventId and Time is sent).

A ConditionBranch is a copy of the Condition instance state that can change independently of the current Condition instance state. Each Branch has an identifier called a BranchId which is unique among all active Branches for a Condition instance. Branches are typically not visible in the Address Space and this standard does not define a standard way to make them visible.

The Disable Method is used to change a Condition instance to the Disabled state. Normally, the NodeId of the object instance as the ObjectId is passed to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall allow Clients to call the Disable Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the ConditionType Node. Since Condition instances may not be defined in the AddressSpace, the MethodId that is passed in the Call Service shall be the NodeId of the Disable Method on the ConditionType.

Signature

Disable();

Method Result Codes in Table 13 (defined in Call Serv ice)

Table 13 – Disable result codes

Result Code

Description

Bad_ConditionAlreadyDisabled

See Table 137 for the description of this result code.

Table 14 specifies the AddressSpace representation for the Disable Method.

Table 14 – Disable Method AddressSpace definition

Attribute

Value

BrowseName

Disable

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionEnableEventType

Defined in 5.10.2

ConformanceUnits

A & C Enable

If Auditing is supported, this Method shall generate an Event of AuditConditionEnableEventType for all invocations of the Method.

The Enable Method is used to change a Condition instance to the enabled state. Normally, the NodeId of the object instance as the ObjectId is passed to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall allow Clients to call the Enable Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the ConditionType Node. If the Condition instance is not exposed, then it may be difficult for a Client to determine the ConditionId for a disabled Condition. Since Condition instances may not be defined in the AddressSpace, the MethodId that is passed in the Call Service shall be the NodeId of the Enable Method on the ConditionType.

Signature

Enable();

Method result codes in Table 15 (defined in Call Serv ice)

Table 15 – Enable result codes

Result Code

Description

Bad_ConditionAlreadyEnabled

See Table 137 for the description of this result code.

Table 16 specifies the AddressSpace representation for the Enable Method.

Table 16 – Enable Method AddressSpace definition

Attribute

Value

BrowseName

Enable

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionEnableEventType

Defined in 5.10.2

ConformanceUnits

A & C Enable

If Auditing is supported, this Method shall generate an Event of AuditConditionEnableEventType for all invocations of the Method.

The AddComment Method is used to apply a comment to a specific state of a Condition instance. 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, all Servers shall also allow Clients to call the AddComment Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the ConditionType Node.

Signature

AddComment(

[in] ByteString EventId

[in] LocalizedText Comment

);

The parameters are defined in Table 17

Table 17 – AddComment arguments

Argument

Description

EventId

EventId identifying a particular Event Notification where a state was reported for a Condition.

Comment

A localized text to be applied to the Condition.

Method result codes in Table 18 (defined in Call Service)

Table 18 – AddComment result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general description of this result code.

Bad_EventIdUnknown

See Table 137 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 ConditionType Node.

See 10000-4 for the general description of this result code.

Comments

Comments are added to Event occurrences identified via an EventId. EventIds where the related EventType is not a ConditionType (or subtype of it) and thus does not support Comments are rejected.

A ConditionEvent – where the Comment Variable contains this text – will be sent for the identified state. If a comment is added to a previous state (i.e. a state for which the Server has created a branch), the BranchId and all Condition values of this branch will be reported. 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.

Table 19 specifies the AddressSpace representation for the AddComment Method.

Table 19 – AddComment Method AddressSpace definition

Attribute

Value

BrowseName

AddComment

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionCommentEventType

Defined in 5.10.4

ConformanceUnits

A & C Comment

If Auditing is supported, this Method shall generate an Event of AuditConditionCommentEventType for all invocations of the Method.

ConditionRefresh allows a Client to request a Refresh of all Condition instances that currently are in an interesting state (they have the Retain flag set). This includes previous states of a Condition instance for which the Server maintains Branches. A Client would typically invoke this Method when it initially connects to a Server and following any situations, such as communication disruptions, in which it would require resynchronization with the Server. This Method is only available on the ConditionType. To invoke this Method, the call shall pass the well-known MethodId of the Method on the ConditionType and the ObjectId shall be the well-known NodeId of the ConditionType ObjectType.

Signature

ConditionRefresh(

[in] IntegerId SubscriptionId

);

The parameters are defined in Table 20

Table 20 – ConditionRefresh parameters

Argument

Description

SubscriptionId

A valid Subscription Id of the Subscription to be refreshed. The Server shall verify that the SubscriptionId provided is part of the Session that is invoking the Method.

Method result codes in Table 21 (defined in Call Serv ice)

Table 21 – ConditionRefresh result codes

Result Code

Description

Bad_SubscriptionIdInvalid

See 10000-4 for the description of this result code

Bad_NothingToDo

The ConditionRefresh Method was called on a SubscriptionId that has no event MonitoredItems.

Bad_RefreshInProgress

See Table 137 for the description of this result code

Bad_UserAccessDenied

The Method was not called in the context of the Session that owns the Subscription

See 10000-4 for the general description of this result code.

Comments

Sub clause 4.5 describes the concept, use cases and information flow in more detail.

The input argument provides a Subscription identifier indicating which Client Subscription shall be refreshed. If the Subscription is accepted the Server will react as follows:

  1. The Server issues an event of RefreshStartEventType (defined in 5.11.2) marking the start of Refresh. A copy of the instance of RefreshStartEventType is queued into the Event stream for every Notifier MonitoredItem in the Subscription. Each of the Event copies shall contain the same EventId.
  2. The Server issues Event Notifications of any Retained Conditions and Retained Branches of Conditions that meet the Subscriptions content filter criteria. Note that the EventId for such a refreshed Notification shall be identical to the one for the original Notification, the values of the other Properties are Server specific, in that some Servers may be able to replay the exact Events with all Properties/Variables maintaining the same values as originally sent, but other Servers might only be able to regenerate the Event. The regenerated Event might contain some updated Property/Variable values. For example, if the Alarm limits associated with a Variable were changed after the generation of the Event without generating a change in the Alarm state, the new limit might be reported. In another example, if the HighLimit was 100 and the Variable is 120. If the limit were changed to 90 no new Event would be generated since no change to the StateMachine, but the limit on a Refresh would indicate 90, when the original Event had indicated 100.
  3. The Server may intersperse new Event Notifications that have not been previously issued to the Notifier along with those being sent as part of the Refresh request. Clients shall check for multiple Event Notifications for a ConditionBranch to avoid overwriting a new state delivered together with an older state from the Refresh process.
  4. The Server issues an instance of RefreshEndEventType (defined in 5.11.3) to signal the end of the Refresh. A copy of the instance of RefreshEndEventType is queued into the Event stream for every Notifier MonitoredItem in the Subscription. Each of the Events copies shall contain the same EventId.

It is important to note that if multiple Event Notifiers are in a Subscription all Event Notifiers are processed. If a Client does not want all MonitoredItems refreshed, then the Client should place each MonitoredItem in a separate Subscription or call ConditionRefresh2 if the Server supports it.

If more than one Subscription is to be refreshed, then the standard call Service array processing can be used.

As mentioned above, ConditionRefresh shall also issue Event Notifications for prior states if they still need attention. In particular, this is True for Condition instances where previous states still need acknowledgement or confirmation.

Table 22 specifies the AddressSpace representation for the ConditionRefresh Method.

Table 22 – ConditionRefresh Method AddressSpace definition

Attribute

Value

BrowseName

ConditionRefresh

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

RefreshStartEventType

Defined in 5.11.2

AlwaysGeneratesEvent

ObjectType

RefreshEndEventType

Defined in 5.11.3

ConformanceUnits

A & C Refresh

ConditionRefresh2 allows a Client to request a Refresh of all Condition instances that currently are in an interesting state (they have the Retain flag set) that are associated with the given Monitored item. In all other respects it functions as ConditionRefresh. A Client would typically invoke this Method when it initially connects to a Server and following any situations, such as communication disruptions where only a single MonitoredItem is to be resynchronized with the Server. This Method is only available on the ConditionType. To invoke this Method, the call shall pass the well-known MethodId of the Method on the ConditionType and the ObjectId shall be the well-known NodeId of the ConditionType ObjectType.

This Method is optional and as such Clients must be prepared to handle Servers which do not provide the Method. If the Method returns Bad_MethodInvalid, the Client shall revert to ConditionRefresh.

Signature

ConditionRefresh2(

[in] IntegerId SubscriptionId

[in] IntegerId MonitoredItemId

);

The parameters are defined in Table 23

Table 23 – ConditionRefresh2 parameters

Argument

Description

SubscriptionId

The identifier of the Subscription containing the MonitoredItem to be refreshed. The Server shall verify that the SubscriptionId provided is part of the Session that is invoking the Method.

MonitoredItemId

The identifier of the MonitoredItem to be refreshed. The MonitoredItemId shall be in the provided Subscription.

Method result codes in Table 24(defined in Call Serv ice)

Table 24 – ConditionRefresh2 result codes

Result Code

Description

Bad_SubscriptionIdInvalid

See 10000-4 for the description of this result code

Bad_MonitoredItemIdInvalid

See 10000-4 for the description of this result code

Bad_RefreshInProgress

See Table 137 for the description of this result code

Bad_UserAccessDenied

The Method was not called in the context of the Session that owns the Subscription

See 10000-4 for the general description of this result code.

Bad_MethodInvalid

See 10000-4 for the description of this result code

Comments

Sub clause 4.5 describes the concept, use cases and information flow in more detail.

The input argument provides a Subscription identifier and MonitoredItem identifier indicating which MonitoredItem in the selected Client Subscription shall be refreshed. If the Subscription and MonitoredItem is accepted the Server will react as follows:

  1. The Server issues a RefreshStartEvent (defined in 5.11.2) marking the start of Refresh. The RefreshStartEvent is queued into the Event stream for the Notifier MonitoredItem in the Subscription.
  2. The Server issues Event Notifications of any Retained Conditions and Retained Branches of Conditions that meet the Subscriptions content filter criteria. Note that the EventId for such a refreshed Notification shall be identical to the one for the original Notification, the values of the other Properties are Server specific, in that some Servers may be able to replay the exact Events with all Properties/Variables maintaining the same values as originally sent, but other Servers might only be able to regenerate the Event. The regenerated Event might contain some updated Property/Variable values. For example, if the Alarm limits associated with a Variable were changed after the generation of the Event without generating a change in the Alarm state, the new limit might be reported. In another example, if the HighLimit was 100 and the Variable is 120. If the limit were changed to 90 no new Event would be generated since no change to the StateMachine, but the limit on a Refresh would indicate 90, when the original Event had indicated 100.
  3. The Server may intersperse new Event Notifications that have not been previously issued to the notifier along with those being sent as part of the Refresh request. Clients shall check for multiple Event Notifications for a ConditionBranch to avoid overwriting a new state delivered together with an older state from the Refresh process.
  4. The Server issues a RefreshEndEvent (defined in 5.11.3) to signal the end of the Refresh. The RefreshEndEvent is queued into the Event stream for the Notifier MonitoredItem in the Subscription.

If more than one MonitoredItem or Subscription is to be refreshed, then the standard call Service array processing can be used.

As mentioned above, ConditionRefresh2 shall also issue Event Notifications for prior states if those states still need attention. In particular, this is True for Condition instances where previous states still need acknowledgement or confirmation.

Table 25 specifies the AddressSpace representation for the ConditionRefresh2 Method.

Table 25 – ConditionRefresh2 Method AddressSpace definition

Attribute

Value

BrowseName

ConditionRefresh2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

RefreshStartEventType

Defined in 5.11.2

AlwaysGeneratesEvent

ObjectType

RefreshEndEventType

Defined in 5.11.3

ConformanceUnits

A & C Refresh2

The Dialog Model is an extension of the Condition model used by a Server to request user input. It provides functionality similar to the standard Message dialogs found in most operating systems. The model can easily be customized by providing Server specific response options in the ResponseOptionSet and by adding additional functionality to derived Condition Types.

The DialogConditionType is used to represent Conditions as dialogs. It is illustrated in Figure 12 and formally defined in Table 26 and Table 27.

image015.png

Figure 12 – DialogConditionType Overview

Table 26 – DialogConditionType definition

Attribute

Value

BrowseName

DialogConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the ConditionType defined in clause 5.5.2

HasComponent

Variable

DialogState

LocalizedText

TwoStateVariableType

Mandatory

HasProperty

Variable

Prompt

LocalizedText

PropertyType

Mandatory

HasProperty

Variable

ResponseOptionSet

LocalizedText [ ]

PropertyType

Mandatory

HasProperty

Variable

DefaultResponse

Int32

PropertyType

Mandatory

HasProperty

Variable

LastResponse

Int32

PropertyType

Mandatory

HasProperty

Variable

OkResponse

Int32

PropertyType

Mandatory

HasProperty

Variable

CancelResponse

Int32

PropertyType

Mandatory

HasComponent

Method

Respond

Defined in Clause 5.6.3.

Mandatory

HasComponent

Method

Respond2

Defined in Clause 5.6.4.

Optional

ConformanceUnits

A & C Dialog

Table 27 – DialogConditionType Additional Subcomponents

BrowsePath

References

NodeClass

BrowseName

DataType

TypeDefinition

Others

DialogState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

DialogState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

The empty Others” column indicates that no ModellingRule applies.

The DialogConditionType inherits all Properties of the ConditionType.

DialogState/Id when set to True indicates that the Dialog is active and waiting for a response. Recommended state names are described in A.2.

Prompt is a dialog prompt to be shown to the user.

ResponseOptionSet specifies the desired set of responses as array of LocalizedText. The index in this array is used for the corresponding fields like DefaultResponse, LastResponse and SelectedOption in the Respond Method. The recommended localized names for the common options are described in A.1.

Typical combinations of response options are

  • OK
  • OK, Cancel
  • Yes, No, Cancel
  • Abort, Retry, Ignore
  • Retry, Cancel
  • Yes, No

DefaultResponse identifies the response option that should be shown as default to the user. It is the index in the ResponseOptionSet array. If no response option is the default, the value of the Property is -1.

LastResponse contains the last response provided by a Client in the Respond Method. If no previous response exists, then the value of the Property is -1.

OkResponse provides the index of the OK option in the ResponseOptionSet array. This choice is the response that will allow the system to proceed with the operation described by the prompt. This allows a Client to identify the OK option if a special handling for this option is available. If no OK option is available, the value of this Property is -1.

CancelResponse provides the index of the response in the ResponseOptionSet array that will cause the Dialog to go into the inactive state without proceeding with the operation described by the prompt. This allows a Client to identify the Cancel option if a special handling for this option is available. If no Cancel option is available, the value of this Property is -1.

Respond is used to pass the selected response option and end the dialog. DialogState/Id will return to False.

Signature

Respond(

[in] Int32 SelectedResponse

);

The parameters are defined in Table 28

Table 28 – Respond parameters

Argument

Description

SelectedResponse

Selected index of the ResponseOptionSet array.

Method result codes in Table 29 (defined in Call Serv ice)

Table 29 – Respond Result Codes

Result Code

Description

Bad_DialogNotActive

See Table 137 for the description of this result code.

Bad_DialogResponseInvalid

See Table 137 for the description of this result code.

Table 30 specifies the AddressSpace representation for the Respond Method.

Table 30 – Respond Method AddressSpace definition

Attribute

Value

BrowseName

Respond

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionRespondEventType

Defined in 5.10.5

ConformanceUnits

A & C Dialog

If Auditing is supported, this Method shall generate an Event of AuditConditionRespondEventType for all invocations of the Method.

Respond2 Method extends the respond method by adding a comment field. For other functionality see the Respond Method definition.

Signature

Respond2(

[in] Int32 SelectedResponse

[in] LocalizedTextComment

);

The parameters are defined in Table 31

Table 31 – Respond2 parameters

Argument

Description

SelectedResponse

Selected index of the ResponseOptionSet array.

Comment

A localized text to be applied to the Dialog.

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.

Method result codes in Table 32 (defined in Call Serv ice)

Table 32 – Respond2 Result Codes

Result Code

Description

Bad_DialogNotActive

See Table 137 for the description of this result code.

Bad_DialogResponseInvalid

See Table 137 for the description of this result code.

Table 33 specifies the AddressSpace representation for the Respond2 Method.

Table 33 – Respond2 Method AddressSpace definition

Attribute

Value

BrowseName

Respond2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionRespondEventType

Defined in 5.10.5

ConformanceUnits

A & C Dialog2

If Auditing is supported, this Method shall generate an Event of AuditConditionRespondEventType for all invocations of the Method.

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 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).

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 36

Table 36 – 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 to be applied to the Condition.

Method result codes in Table 37 (defined in Call Service)

Table 37 – Acknowledge result codes

Result Code

Description

Bad_ConditionBranchAlreadyAcked

See Table 137 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 137 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.

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 where 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 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 38 specifies the AddressSpace representation for the Acknowledge Method.

Table 38 – Acknowledge Method AddressSpace definition

Attribute

Value

BrowseName

Acknowledge

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

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 39

Table 39 – 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 to be applied to the Conditions.

Method result codes in Table 40 (defined in Call Service)

Table 40 – Confirm result codes

Result Code

Description

Bad_ConditionBranchAlreadyConfirmed

See Table 137 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 137 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.

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 where a state to be confirmed was reported. A Comment can be provided which 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 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 41 specifies the AddressSpace representation for the Confirm Method.

Table 41 – Confirm Method AddressSpace definition

Attribute

Value

BrowseName

Confirm

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

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.

Figure 14 informally describes the AlarmConditionType, its sub-types and where it is in the hierarchy of Event Types.

image017.png

Figure 14 – AlarmConditionType Hierarchy Model

The AlarmConditionType extends the AcknowledgeableConditionType by introducing an ActiveState, SuppressedState and ShelvingState. It also adds the ability to set a delay time, re-alarm time, Alarm groups and audible Alarm settings. The Alarm model is illustrated in Figure 15. This illustration is not intended to be a complete definition. It is formally defined in Table 42 and Table 43.

image018.png

Figure 15 – Alarm Model

Table 42 – AlarmConditionType definition

Attribute

Value

BrowseName

AlarmConditionType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the AcknowledgeableConditionType defined in clause 5.7.2

HasComponent

Variable

ActiveState

LocalizedText

TwoStateVariableType

Mandatory

HasProperty

Variable

InputNode

NodeId

PropertyType

Mandatory

HasComponent

Variable

SuppressedState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

OutOfServiceState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Object

ShelvingState

ShelvedStateMachineType

Optional

HasProperty

Variable

SuppressedOrShelved

Boolean

PropertyType

Mandatory

HasProperty

Variable

MaxTimeShelved

Duration

PropertyType

Optional

HasProperty

Variable

AudibleEnabled

Boolean

PropertyType

Optional

HasComponent

Variable

AudibleSound

AudioDataType

AudioVariableType

Optional

HasComponent

Variable

SilenceState

LocalizedText

TwoStateVariableType

Optional

HasProperty

Variable

OnDelay

Duration

PropertyType

Optional

HasProperty

Variable

OffDelay

Duration

PropertyType

Optional

HasComponent

Variable

FirstInGroupFlag

Boolean

BaseDataVariableType

Optional

HasComponent

Object

FirstInGroup

AlarmGroupType

Optional

HasComponent

Variable

LatchedState

LocalizedText

TwoStateVariableType

Optional

HasAlarmSuppressionGroup

Object

<AlarmGroup>

AlarmGroupType

OptionalPlaceholder

HasProperty

Variable

ReAlarmTime

Duration

PropertyType

Optional

HasComponent

Variable

ReAlarmRepeatCount

Int16

BaseDataVariableType

Optional

HasComponent

Method

Reset

Defined in 5.8.5

Optional

HasComponent

Method

Reset2

Defined in 5.8.65.8.5

Optional

HasComponent

Method

Silence

Defined in 5.8.7

Optional

HasComponent

Method

Suppress

Defined in 5.8.8

Optional

HasComponent

Method

Suppress2

Defined in 5.8.9

Optional

HasComponent

Method

Unsuppress

Defined in 5.8.10

Optional

HasComponent

Method

Unsuppress2

Defined in 5.8.11

Optional

HasComponent

Method

RemoveFromService

Defined in 5.8.12

Optional

HasComponent

Method

RemoveFromService2

Defined in 5.8.13

Optional

HasComponent

Method

PlaceInService

Defined in 5.8.14

Optional

HasComponent

Method

PlaceInService2

Defined in 5.8.15

Optional

HasComponent

Method

GetGroupMemberships

Defined in 5.8.16

Optional

HasSubtype

ObjectType

DiscreteAlarmType

HasSubtype

ObjectType

LimitAlarmType

HasSubtype

ObjectType

DiscrepancyAlarmType

ConformanceUnits

A & C Alarm

Table 43 – AlarmConditionType Additional Subcomponents

BrowsePath

References

NodeClass

BrowseName

DataType

TypeDefinition

Others

ActiveState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

ActiveState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

SuppressedState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

SuppressedState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

OutOfServiceState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

OutOfServiceState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

SilenceState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

SilenceState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

LatchedState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

LatchedState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

The empty Others” column indicates that no ModellingRule applies.

The AlarmConditionType inherits all Properties of the AcknowledgeableConditionType. The following states are sub-states of the True EnabledState.

ActiveState/Id when set to True indicates that the situation the Condition is representing currently exists. When a Condition instance is in the inactive state (ActiveState/Id when set to False) it is representing a situation that has returned to a normal state. The transitions of Conditions to the inactive and Active states are triggered by Server specific actions. Subtypes of the AlarmConditionType specified later in this document will have sub-state models that further define the Active state. Recommended state names are described inA.1. In the event of a restart of an AlarmManager, the AlarmManager shall recover the ActiveState.

The InputNode Property provides the NodeId of the Variable the Value of which is used as primary input in the calculation of the Alarm state. If this Variable is not in the AddressSpace, a NULL NodeId shall be provided. In some systems, an Alarm may be calculated based on multiple Variables Values; it is up to the system to determine which Variable’s NodeId is used.

SuppressedState, OutOfServiceState and ShelvingState together allow the suppression of Alarms on display systems. These three suppressions are generally used by different personnel or systems at a plant, i.e. automatic systems, maintenance personnel and Operators.

SuppressedState is used internally by a Server to automatically suppress Alarms due to system specific reasons. For example, a system may be configured to suppress Alarms that are associated with machinery that is in a state such as shutdown. For example, a low level Alarm for a tank that is currently not in use might be suppressed. Recommended state names are described in A.1. In the event of a restart of an AlarmManager, the AlarmManager should recover the SuppressedState. If the system cannot determine if the alarm is Suppressed, the state shall be set to false (not Suppressed).

OutOfServiceState is used by maintenance personnel to suppress Alarms due to a maintenance issue. For example, if an instrument is taken out of service for maintenance or is removed temporarily while it is being replaced or serviced the item would have the OutOfServiceState set. Recommended state names are described in A.1. In the event of a restart of an AlarmManager, the AlarmManager should recover the OutOfServiceState. If the system cannot determine if the alarm is OutOfService, the state shall be set to false (not OutOfService).

ShelvingState suggests whether an Alarm shall (temporarily) be prevented from being displayed to the user. It is quite often used by Operators to block nuisance Alarms. The ShelvingState is defined in 5.8.17.

When an Alarm has any or all of the SuppressedState, OutOfServiceState or ShelvingState set to True, the SuppressedOrShelved property shall be set True and this Alarm is then typically not displayed by the Client. State transitions associated with the Alarm do occur, but they are not typically displayed by the Clients as long as the Alarm remains in any of the SuppressedState, OutOfServiceState or Shelved state.

The optional Property MaxTimeShelved is used to set the maximum time that an Alarm Condition may be shelved. The value is expressed as duration. Systems can use this Property to prevent permanent Shelving of an Alarm. If this Property is present, it will be an upper limit on the duration passed into a TimedShelve Method call. If a value that exceeds the value of this Property is passed to the TimedShelve Method, then a Bad_ShelvingTimeOutOfRange error code is returned on the call. If this Property is present, it will also be enforced for the OneShotShelved state, in that an Alarm Condition will transition to the Unshelved state from the OneShotShelved state if the duration specified in this Property expires following a OneShotShelve operation without a change of any of the other items associated with the Condition.

The optional Property AudibleEnabled is a Boolean that indicates if the current state of this Alarm includes an audible Alarm.

The optional Property AudibleSound contains the sound file that is to be played if an audible Alarm is to be generated. This file would be play/generated as long as the Alarm is active and unacknowledged, unless the silence StateMachine is included, in which case it may also be silenced by this StateMachine.

The SilenceState is used to suppress the generation of audible Alarms. Typically, it is used when an Operator silences all Alarms on a screen, but needs to acknowledge the Alarms individually. Silencing an Alarm shall silence the Alarm on all systems (screens) that it is being reported on. Not all Clients will make use of this StateMachine, but it allows multiple Clients to synchronize audible Alarm states. Acknowledging an Alarm shall automatically silence an Alarm. In the event of a restart of an AlarmManager, the AlarmManager should recover the SilenceState. If the system cannot determine if the Alarm is silenced, it shall set the SilenceState, based on the AcknowledgeState. If it is Acknowledged, it is silenced, If it has not been Acknowledged, it shall not be silenced.

The OnDelay and OffDelay Properties can be used to eliminate nuisance Alarms. The OnDelay is used to avoid unnecessary Alarms when a signal temporarily overshoots its setpoint, thus preventing the Alarm from being triggered until the signal remains in the Alarm state continuously for a specified length of time (OnDelay time). The OffDelay is used to reduce chattering Alarms by locking the Alarm indication for a certain holding period after the condition has returned to normal. I.e., the Alarm shall stay active for the OffDelay time and shall not regenerate if it returns to active in that period. If the Alarm remains in the inactive zone for OffDelay it will then become inactive.

The optional variable FirstInGroupFlag is used together with the FirstInGroup object. The FirstInGroup Object is an instance of an AlarmGroupType that groups a number of related Alarms. The FirstInGroupFlag is set on the Alarm instance that was the first Alarm to trigger in a FirstInGroup. If this variable is present, then the FirstInGroup shall also be present. These two nodes allow an alarming system to determine which Alarm in the list was the trigger. It is commonly used in situations where Alarms are interrelated and usually multiple Alarms occur. For example, vibration sensors in a turbine, usually all sensors trigger if any one triggers, but what is important for an Operator is the first sensor that triggered.

The LatchedState Object, if present, indicates that this Alarm supports being latched. The Alarm will remain with a retain bit of True until it is no longer active, is acknowledged, is confirmed (if ConfirmedState is provided) and is reset. The Reset Method, if called while active has no effect on the Alarm and is ignored and an error of Bad_InvalidState is return on the call. The Object indicates the current state, latched or not latched. Recommended state names are described in A.1. If this Object is provided the Reset Method must also be provided. In the event of a restart of an AlarmManager, the AlarmManager shall recover the LatchedState.

An Alarm instance may contain HasAlarmSuppressionGroup reference(s) to instance(s) of AlarmGroupType (or subtype of it). Each instance is an AlarmSuppressionGroup. When an AlarmSuppressionGroup goes active, the Server shall set the SuppressedState of the Alarm containing the HasAlarmSuppressionGroup reference to True. When all of referenced AlarmSuppressionGroups are no longer active, then the Server shall set SuppressedState to False. A single AlarmSuppressionGroup can manage multiple Alarms. AlarmSuppressionGroups are used to control Alarm floods and to help manage Alarms.

ReAlarmTime if present sets a time that is used to bring an Alarm back to the top of an Alarm list. If an Alarm has not returned to normal within the provided time (from when it last was alarmed), the Server will generate a new Alarm for it (as if it just went into alarm). If it has been silenced it shall return to an un-silenced state, if it has been acknowledged it shall return to unacknowledged. The Alarm active time is set to the time of the re-alarm.

ReAlarmRepeatCount if present counts the number times an Alarm was re-alarmed. Some smart alarming system would use this count to raise the priority or otherwise generate additional or different annunciations for the given Alarm. The count is reset when an Alarm returns to normal.

Silence Method can be used to silence an instance of an Alarm. It is defined in 5.8.7.

Suppress and Suppress2 Method can be used to suppress an instance of an Alarm. Most Alarm suppression occurs via advanced alarming, but this method allows additional access to suppress a particular Alarm instance. Additional details are provided in the definition in 5.8.8 and 5.8.9

Unsuppress and Unsuppress2 Method can be used to remove an instance of an Alarm from SuppressedState. Additional details are provided in the definition in 5.8.10 and 5.8.11.

PlaceInService and PlaceInService2 Method can be used to remove an instance of an Alarm from OutOfServiceState. It is defined in 5.8.14 and 5.8.15.

RemoveFromService and RemoveFromService2 Method can be used to place an instance of an Alarm in OutOfServiceState. It is defined in 5.8.12 and 5.8.13.

Reset Method is used to clear a latched Alarm. It is defined in 5.8.5. If this Object is provided the LatchedState Object shall also be provided.

More details about the Alarm Model and the various states can be found in Sub clause 4.8. and in Annex E.

The AlarmGroupType provides a simple manner of grouping Alarms. This grouping can be used for Alarm suppression or for identifying related Alarms. The actual usage of the AlarmGroupType is specified where it is used.

Table 44 – AlarmGroupType definition

Attribute

Value

BrowseName

AlarmGroupType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FolderType defined in 10000-5

AlarmGroupMember

Object

<AlarmConditionInstance>

AlarmConditionType

OptionalPlaceholder

ConformanceUnits

A & C First in Group Alarm

A & C Suppression Group

The instance of an AlarmGroupType should be given a name and description that describes the purpose of the Alarm group.

The AlarmGroupType instance will contain a list of instances of AlarmConditionType or sub type of AlarmConditionType referenced by AlarmGroupMember references. At least one Alarm must be present in an instance of an AlarmGroupType.

This is a subtype of AlarmGroupType that can be used to suppress other alarms. This subtype of AlarmGroup extends the AlarmGroupType to allow the addition of Variables that have a Boolean DataType. The Variable can be thought of as representing the Id of the ActiveState of an Alarm, i.e. when any of the included Variables have a value of true the AlarmSuppressionGroup is active.

Table 45 – AlarmSuppressionGroupType definition

Attribute

Value

BrowseName

AlarmSuppressionGroupType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AlarmGroupType

AlarmSuppressionGroupMember

Variable

<DigitalVariable>

Boolean

BaseDataVariableType

OptionalPlaceholder

ConformanceUnits

A & C Suppression Group

The instance of an AlarmSuppressionGroupType should be given a name and description that describes the purpose of the Alarm group.

The AlarmSuppressionGroupType instance will contain a list of instances of AlarmConditionType or sub type of AlarmConditionType or BaseDataVaribleType with a DataType of Boolean referenced by AlarmSuppressionGroupMember references. At least one Node must be present in an instance of an AlarmGroupType.

The Reset Method is used reset a latched Alarm instance. It is only available on an instance of an AlarmConditionType that exposes the LatchedState. 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 Reset Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.

Signature

Reset();

This method has no arguments.

Method result codes in Table 46 (defined in Call service)

Table 46 – Reset result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Bad_InvalidState

The Alarm instance was not latched or is still active or still requires acknowledgement / confirmation. For an Alarm Instance to be reset it must have been in Alarm, and returned to normal and have been acknowledged/confirmed prior to being reset.

Table 47 specifies the AddressSpace representation for the Reset Method.

Table 47 – Reset Method AddressSpace definition

Attribute

Value

BrowseName

Reset

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionResetEventType

Defined in 5.10.11

ConformanceUnits

A & C Latched State

If Auditing is supported, this Method shall generate an Event of AuditConditionResetEventType for all invocations of the Method.

The Reset2 Method extends the Reset Method, by adding an optional Comment. For other functionality see the Reset Method definition.

Signature

Reset2(

[in] LocalizedTextComment

);

The parameters are defined in Table 48.

Table 48 – Reset2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Condition.

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.

Method result codes in Table 49 (defined in Call service)

Table 49 – Reset2 result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Bad_InvalidState

The Alarm instance was not latched or is still active or still requires acknowledgement / confirmation. For an Alarm Instance to be reset it must have been in Alarm, and returned to normal and have been acknowledged/confirmed prior to being reset.

Table 50 specifies the AddressSpace representation for the Reset2 Method.

Table 50 – Reset2 Method AddressSpace definition

Attribute

Value

BrowseName

Reset2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionResetEventType

Defined in 5.10.11

ConformanceUnits

A & C Latched State

If Auditing is supported, this Method shall generate an Event of AuditConditionResetEventType for all invocations of the Method.

The Silence Method is used silence a specific Alarm instance. It is only available on an instance of an AlarmConditionType that also exposes the SilenceState. 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 Silence Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.

Signature

Silence();

This method has no arguments.

Method result codes in Table 51 (defined in Call service)

Table 51 – Silence result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

If the instance is not currently in an audible state, the command is ignored.

Table 52 specifies the AddressSpace representation for the Silence Method.

Table 52 – Silence Method AddressSpace definition

Attribute

Value

BrowseName

Silence

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionSilenceEventType

Defined in 5.10.10

ConformanceUnits

A & C Silencing

If Auditing is supported, this Method shall generate an Event of AuditConditionSilenceEventType for all invocations of the Method.

The Suppress Method is used to suppress a specific Alarm instance. It is only available on an instance of an AlarmConditionType that also exposes the SuppressedState. This Method can be used to change the SuppressedState of an Alarm and overwrite any suppression caused by an associated AlarmSuppressionGroup. This Method works in parallel with any suppression triggered by an AlarmSuppressionGroup, in that if the Method is used to suppress an Alarm, an AlarmSuppressionGroup might clear the suppression.

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 Suppress Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.

Signature

Suppress();

Method Result Codes in Table 53 (defined in Call Service)

Table 53 – Suppress result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

Suppress Method applies to an Alarm instance, even if it is not currently active.

Table 54 specifies the AddressSpace representation for the Suppress Method.

Table 54 – Suppress Method AddressSpace definition

Attribute

Value

BrowseName

Suppress

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

ConformanceUnits

A & C Suppression by Operator

If Auditing is supported, this Method shall generate an Event of AuditConditionSuppressionEventType for all invocations of the Method.

The Suppress2 Method extends the Suppress Method, by adding an optional Comment. For other functionality see the Suppress Method definition.

Signature

Suppress2(

[in] LocalizedTextComment

);

The parameters are defined in Table 55

Table 55 – Suppress2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Condition.

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.

Table 56 specifies the AddressSpace representation for the Suppress2 Method.

Table 56 – Suppress2 Method AddressSpace definition

Attribute

Value

BrowseName

Suppress2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

ConformanceUnits

A & C Suppression2 by Operator

If Auditing is supported, this Method shall generate an Event of AuditConditionSuppressionEventType for all invocations of the Method.

The Unsuppress Method is used to clear the SuppressedState of a specific Alarm instance. It is only available on an instance of an AlarmConditionType that also exposes the SuppressedState. This Method can be used to overwrite any suppression cause by an associated AlarmSuppressionGroup. This Method works in parallel with any suppression triggered by an AlarmSuppressionGroup, in that if the Method is used to clear the SuppressedState of an Alarm, any change in an AlarmSuppressionGroup might again suppress the Alarm.

Normally, the NodeId of the ObjectInstance 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 Unsuppress Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.

Signature

Unsuppress();

Method Result Codes in Table 57 (defined in Call Service).

Table 57 – Unsuppress result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

Unsuppress Method applies to an Alarm instance, even if it is not currently active.

Table 58 specifies the AddressSpace representation for the Suppress Method.

Table 58 – Unsuppress Method AddressSpace definition

Attribute

Value

BrowseName

Unsuppress

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

ConformanceUnits

A & C Suppression by Operator

If Auditing is supported, this Method shall generate and event of AuditConditionSuppressionEventType for all invocations of the Method.

The Unsuppress2 Method extends the Suppress Method, by adding an optional Comment. For other functionality see the Unsuppress Method definition.

Signature

Unsuppress2(

[in] LocalizedTextComment

);

The parameters are defined in Table 59.

Table 59 – Unsuppress2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Condition.

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.

Unsuppress2 Method applies to an Alarm instance, even if it is not currently active.

Table 60 specifies the AddressSpace representation for the Unsuppress2 Method.

Table 60 – Unsuppress2 Method AddressSpace definition

Attribute

Value

BrowseName

Unsuppress2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionSuppressionEventType

Defined in 5.10.4

ConformanceUnits

A & C Suppression2 by Operator

If Auditing is supported, this Method shall generate an Event of AuditConditionSuppressionEventType for all invocations of the Method.

The RemoveFromService Method is used to suppress a specific Alarm instance. It is only available on an instance of an AlarmConditionType that also exposes the OutOfServiceState. 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 RemoveFromService Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.

Signature

RemoveFromService();

Method result codes in Table 61 (defined in Call Service).

Table 61 – RemoveFromService result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

Instances that do not expose the OutOfService State shall reject RemoveFromService calls. RemoveFromService Method applies to an Alarm instance, even if it is not currently in the Active State.

Table 62 specifies the AddressSpace representation for the RemoveFromService Method.

Table 62 – RemoveFromService Method AddressSpace definition

Attribute

Value

BrowseName

RemoveFromService

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

ConformanceUnits

A & C OutOfService

If Auditing is supported, this Method shall generate an Event of AuditConditionOutOfServiceEventType for all invocations of the Method.

The RemoveFromService2 Method extends the RemoveFromService Method, by adding an optional Comment. For other functionality see the RemoveFromService Method definition.

Signature

RemoveFromService2(

[in] LocalizedTextComment

);

The parameters are defined in Table 63

Table 63 – RemoveFromService2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Condition.

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.

Method result codes in Table 64 (defined in Call Service)

Table 64 – RemoveFromService2 result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

Instances that do not expose the OutOfService State shall reject RemoveFromService2 calls. RemoveFromService2 Method applies to an Alarm instance, even if it is not currently in the Active State.

Table 65 specifies the AddressSpace representation for the RemoveFromService2 Method.

Table 65 – RemoveFromService2 Method AddressSpace definition

Attribute

Value

BrowseName

RemoveFromService2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

ConformanceUnits

A & C OutOfService2

If Auditing is supported, this Method shall generate an Event of AuditConditionOutOfServiceEventType for all invocations of the Method.

The PlaceInService Method is used to set the OutOfServiceState to False of a specific Alarm instance. It is only available on an instance of an AlarmConditionType that also exposes the OutOfServiceState. Normally, the NodeId of the ObjectInstance 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 PlaceInService Method by specifying ConditionId as the ObjectId. The Method cannot be called with an ObjectId of the AlarmConditionType Node.

Signature

PlaceInService();

Method result codes in Table 66 (defined in Call Service).

Table 66 – PlaceInService result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

The PlaceInService Method applies to an Alarm instance, even if it is not currently in the Active State.

Table 67 specifies the AddressSpace representation for the PlaceInService Method.

Table 67 – PlaceInService Method AddressSpace definition

Attribute

Value

BrowseName

PlaceInService

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

ConformanceUnits

A & C OutOfService

If Auditing is supported, this Method shall generate an Event of AuditConditionOutOfServiceEventType for all invocations of the Method.

The PlaceInService2 Method extends the PlaceInService Method, by adding an optional Comment. For other functionality see the PlaceInService Method definition.

Signature

PlaceInService2(

[in] LocalizedTextComment

);

The parameters are defined in Table 68.

Table 68 – PlaceInService2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Condition.

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.

Method result codes in Table 69 (defined in Call Service)

Table 69 – PlaceInService2 result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

The PlaceInService2 Method applies to an Alarm instance, even if it is not currently in the Active State.

Table 70 specifies the AddressSpace representation for the PlaceInService2 Method.

Table 70 – PlaceInService2 Method AddressSpace definition

Attribute

Value

BrowseName

PlaceInService2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionOutOfServiceEventType

Defined in 5.10.12

ConformanceUnits

A & C OutOfService2

If Auditing is supported, this Method shall generate an Event of AuditConditionOutOfServiceEventType for all invocations of the Method.

The GetGroupMemberships Method is used to find the list of AlarmGroups that this alarm is in.

Signature

GetGroupMemberships(

[out] NodeId[] Group

);

Method result codes in Table 71 (defined in Call Service)

Table 71 – GetGroupMemberships result codes

Result Code

Description

Bad_MethodInvalid

The MethodId provided does not correspond to the ObjectId provided. See 10000-4 for the general 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 AlarmConditionType Node.

See 10000-4 for the general description of this result code.

Comments

The GetGroupMemberships Method applies to an Alarm instance, even if it is not currently in the Active State.

Table 72 specifies the AddressSpace representation for the GetGroupMemberships Method.

Table 72 – GetGroupMemberships Method AddressSpace definition

Attribute

Value

BrowseName

GetGroupMemberships

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

ConformanceUnits

A & C GetGroupMemberships

The ShelvedStateMachineType defines a sub-state machine that represents an advanced Alarm filtering model. This model is illustrated in Figure 17.

The state model supports two types of Shelving: OneShotShelving and TimedShelving. They are illustrated in Figure 16. The illustration includes the allowed transitions between the various sub-states. Shelving is an Operator initiated activity.

In OneShotShelving, a user requests that an Alarm be Shelved for its current Active state or if not Active its next Active state. This type of Shelving is typically used when an Alarm is continually occurring on a boundary (i.e. a Condition is jumping between High Alarm and HighHigh Alarm, always in the Active state). The OneShotShelving will automatically clear when an Alarm returns to an inactive state. Another use for this type of Shelving is for a plant area that is shutdown i.e. a long running Alarm such as a low level Alarm for a tank that is not in use. When the tank starts operation again the Shelving state will automatically clear.

In TimedShelving, a user specifies that an Alarm be shelved for a fixed time period. This type of Shelving is quite often used to block nuisance Alarms. For example, an Alarm that occurs more than 10 times in a minute may get shelved for a few minutes. The Alarm is shelved for the time period, no matter how many transitions the Alarm has between Active state and Inactive state.

In all states, the Unshelve can be called to cause a transition to the Unshelve state; this includes Un-shelving an Alarm that is in the TimedShelve state before the time has expired and the OneShotShelve state without a transition to an inactive state. In the event of a restart of an AlarmManager, the AlarmManager should recover the ShelvedStateMachine. If the system cannot determine if the state of the ShelvedStateMachine for a given alarm instance, the ShelvedStateMachine shall be set to Unshelved.

All but two transitions are caused by Method calls as illustrated in Figure 16. The “Time Expired” transition is simply a system generated transition that occurs when the time value defined as part of the “Timed Shelved Call” has expired. The “Any Transition Occurs” transition is also a system generated transition; this transition is generated when the Condition goes to an inactive state.

image019.png

Figure 16 – Shelve state transitions

The ShelvedStateMachineType includes a hierarchy of sub-states. It supports all transitions between Unshelved, OneShotShelved and TimedShelved.

The state machine is illustrated in Figure 17 and formally defined in Table 73.

image020.png

Figure 17 – ShelvedStateMachineType model

Table 73 – ShelvedStateMachineType definition

Attribute

Value

BrowseName

ShelvedStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType defined in 10000-16

HasProperty

Variable

UnshelveTime

Duration

PropertyType

Mandatory

HasComponent

Object

Unshelved

StateType

HasComponent

Object

TimedShelved

StateType

HasComponent

Object

OneShotShelved

StateType

HasComponent

Object

UnshelvedToTimedShelved

TransitionType

HasComponent

Object

TimedShelvedToUnshelved

TransitionType

HasComponent

Object

TimedShelvedToOneShotShelved

TransitionType

HasComponent

Object

UnshelvedToOneShotShelved

TransitionType

HasComponent

Object

OneShotShelvedToUnshelved

TransitionType

HasComponent

Object

OneShotShelvedToTimedShelved

TransitionType

HasComponent

Method

TimedShelve

Defined in Clause 5.8.17.4

Mandatory

HasComponent

Method

OneShotShelve

Defined in Clause 5.8.17.6

Mandatory

HasComponent

Method

Unshelve

Defined in Clause 5.8.17.2

Mandatory

HasComponent

Method

TimedShelve2

Defined in Clause 5.8.17.5

Optional

HasComponent

Method

OneShotShelve2

Defined in Clause 5.8.17.7

Optional

HasComponent

Method

Unshelve2

Defined in Clause 5.8.17.3

Optional

ConformanceUnits

A & C Shelving

UnshelveTime specifies the remaining time in milliseconds until the Alarm automatically transitions into the Un-shelved state. For the TimedShelved state this time is initialised with the ShelvingTime argument of the TimedShelve Method call. For the OneShotShelved state the UnshelveTime will be initialized to the Value of MaxTimeShelved Property if it is present otherwise it is initialized to the maximum Duration.

This FiniteStateMachine supports three Active states; Unshelved, TimedShelved and OneShotShelved. It also supports six transitions. The states and transitions are described in Table 74. This FiniteStateMachine also supports three Methods; TimedShelve, OneShotShelve and Unshelve.

Table 74 – ShelvedStateMachineType Additional References

SourceBrowsePath

References

IsForward

TargetBrowsePath

UnshelvedToTimedShelved

FromState

True

Unshelved

ToState

True

TimedShelved

HasEffect

True

AlarmConditionType

HasCause

True

TimedShelve

HasCause

True

TimedShelve2

UnshelvedToOneShotShelved

FromState

True

Unshelved

ToState

True

OneShotShelved

HasEffect

True

AlarmConditionType

HasCause

True

OneShotShelve

HasCause

True

OneShotShelve2

TimedShelvedToUnshelved

FromState

True

TimedShelved

ToState

True

Unshelved

HasEffect

True

AlarmConditionType

TimedShelvedToOneShotShelved

FromState

True

TimedShelved

ToState

True

OneShotShelved

HasEffect

True

AlarmConditionType

HasCause

True

OneShotShelve

HasCause

True

OneShotShelve2

OneShotShelvedToUnshelved

FromState

True

OneShotShelved

ToState

True

Unshelved

HasEffect

True

AlarmConditionType

OneShotShelvedToTimedShelved

FromState

True

OneShotShelved

ToState

True

TimedShelved

HasEffect

True

AlarmConditionType

HasCause

True

TimedShelve

HasCause

True

TimedShelve2

The component Variables of the ShelvedStateMachineType have additional Attributes defined in Table 75.

Table 75 ShelvedStateMachineType Attribute values for child Nodes

BrowsePath

Value Attribute

Unshelved

0:StateNumber

1

TimedShelved

0:StateNumber

2

OneShotShelved

0:StateNumber

3

UnshelvedToTimedShelved

0:TransitionNumber

12

TimedShelvedToUnshelved

0:TransitionNumber

21

TimedShelvedToOneShotShelved

0:TransitionNumber

23

UnshelvedToOneShotShelved

0:TransitionNumber

13

OneShotShelvedToUnshelved

0:TransitionNumber

31

OneShotShelvedToTimedShelved

0:TransitionNumber

32

The Unshelve Method sets the instance of AlarmConditionType to the Unshelved state. Normally, the MethodId found in the Shelving child of the Condition instance and the NodeId of the Shelving object as the ObjectId are passed to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall also allow Clients to call the Unshelve Method by specifying ConditionId as the ObjectId where the ConditionId is the Condition that has Shelving child. The Method cannot be called with an ObjectId of the ShelvedStateMachineType Node.

Signature

Unshelve();

Method Result Codes in Table 76 (defined in Call Service)

Table 76 – Unshelve result codes

Result Code

Description

Bad_ConditionNotShelved

See Table 137 for the description of this result code.

Table 77 specifies the AddressSpace representation for the Unshelve Method.

Table 77 – Unshelve Method AddressSpace definition

Attribute

Value

BrowseName

Unshelve

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

ConformanceUnits

A & C Shelving

If Auditing is supported, this Method shall generate an Event of AuditConditionShelvingEventType for all invocations of the Method.

The Unshelve2 Method extends the Unshelve Method, by adding an optional Comment. For other functionality see the Unshelve Method definition.

Signature

Unshelve2(

[in] LocalizedTextComment

);

The parameters are defined in Table 78

Table 78 – Unshelve2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Conditions.

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.

Method Result Codes in Table 79 (defined in Call Service)

Table 79 – Unshelve2 result codes

Result Code

Description

Bad_ConditionNotShelved

See Table 137 for the description of this result code.

Table 80 specifies the AddressSpace representation for the Unshelve2 Method.

Table 80 – Unshelve2 Method AddressSpace definition

Attribute

Value

BrowseName

Unshelve2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

ConformanceUnits

A & C Shelving2

If Auditing is supported, this Method shall generate an Event of AuditConditionShelvingEventType for all invocations of the Method.

The TimedShelve Method sets the instance of AlarmConditionType to the TimedShelved state (parameters are defined in Table 81 and result codes are described in Table 82). Normally, the MethodId found in the Shelving child of the Condition instance and the NodeId of the Shelving object as the ObjectId are passed to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall also allow Clients to call the TimedShelve Method by specifying ConditionId as the ObjectId where the ConditionId is the Condition that has the Shelving child. The Method cannot be called with an ObjectId of the ShelvedStateMachineType Node.

This Method can be called on any ConditionId, even if it is not active. The timer will start on Method invocation. The Alarm may go active and inactive multiple times during this Duration, but it will remain shelved for the Duration, unless it is changed to a different Shelving State.

Signature

TimedShelve(

[in] Duration ShelvingTime

);

The parameters are defined in Table 81

Table 81 – TimedShelve parameters

Argument

Description

ShelvingTime

Specifies a fixed time for which the Alarm is to be shelved. The Server may refuse the provided duration. If a MaxTimeShelved Property exist on the Alarm than the Shelving time shall be less than or equal to the value of this Property.

Method Result Codes (defined in Call Service)

Table 82 – TimedShelve result codes

Result Code

Description

Bad_ConditionAlreadyShelved

See Table 137 for the description of this result code.

The Alarm is already in TimedShelved state and the system does not allow a reset of the shelved timer.

Bad_ShelvingTimeOutOfRange

See Table 137 for the description of this result code.

Comments

Shelving for some time is quite often used to block nuisance Alarms. For example, an Alarm that occurs more than 10 times in a minute may get shelved for a few minutes.

In some systems the length of time covered by this duration may be limited and the Server may generate an error refusing the provided duration. This limit may be exposed as the MaxTimeShelved Property.

Table 83 specifies the AddressSpace representation for the TimedShelve Method.

Table 83 – TimedShelve Method AddressSpace definition

Attribute

Value

BrowseName

TimedShelve

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

ConformanceUnits

A & C Shelving

If Auditing is supported, this Method shall generate an Event of AuditConditionShelvingEventType for all invocations of the Method.

The TimedShelve Method extends the TimedShelve Method, by adding an optional Comment. For other functionality see the TimedShelve Method definition.

Signature

TimedShelve2(

[in] Duration ShelvingTime

[in] LocalizedTextComment

);

The parameters are defined in Table 84.

Table 84 – TimedShelve2 parameters

Argument

Description

ShelvingTime

Specifies a fixed time for which the Alarm is to be shelved. The Server may refuse the provided duration. If a MaxTimeShelved Property exist on the Alarm than the Shelving time shall be less than or equal to the value of this Property.

Comment

A localized text to be applied to the Condition.

Method Result Codes in Table 85 (defined in Call Service)

Table 85 – TimedShelve2 result codes

Result Code

Description

Bad_ConditionAlreadyShelved

See Table 137 for the description of this result code.

The Alarm is already in TimedShelved state and the system does not allow a reset of the shelved timer.

Bad_ShelvingTimeOutOfRange

See Table 137 for the description of this result code.

Table 86 specifies the AddressSpace representation for the TimedShelve2 Method.

Table 86 – TimedShelve2 Method AddressSpace definition

Attribute

Value

BrowseName

TimedShelve2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

ConformanceUnits

A & C Shelving2

If Auditing is supported, this Method shall generate an Event of AuditConditionShelvingEventType for all invocations of the Method.

The OneShotShelve Method sets the instance of AlarmConditionType to the OneShotShelved state. Normally, the MethodId found in the Shelving child of the Condition instance and the NodeId of the Shelving object as the ObjectId are passed to the Call Service. However, some Servers do not expose Condition instances in the AddressSpace. Therefore, all Servers shall also allow Clients to call the OneShotShelve Method by specifying ConditionId as the ObjectId where the ConditionId is the Condition that has the Shelving child. The Method cannot be called with an ObjectId of the ShelvedStateMachineType Node. This Method can be called on any ConditionId, even if it is not active.

Signature

OneShotShelve( );

Method Result Codes are defined in Table 87 (status code field is defined in Call Serv ice)

Table 87 – OneShotShelve result codes

Result Code

Description

Bad_ConditionAlreadyShelved

See Table 137 for the description of this result code.

The Alarm is already in OneShotShelved state.

Table 88 specifies the AddressSpace representation for the OneShotShelve Method.

Table 88 – OneShotShelve Method AddressSpace definition

Attribute

Value

BrowseName

OneShotShelve

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

ConformanceUnits

A & C Shelving

If Auditing is supported, this Method shall generate an Event of AuditConditionShelvingEventType for all invocations of the Method.

The OneShotShelve2 Method

Signature

OneShotShelve2(

[in] LocalizedTextComment

);

The parameters are defined in Table 89.

Table 89 – OneShotShelve2 Method parameters

Argument

Description

Comment

A localized text to be applied to the Conditions.

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.

Method Result Codes are defined in Table 90 (status code field is defined in Call Serv ice)

Table 90 – OneShotShelve2 result codes

Result Code

Description

Bad_ConditionAlreadyShelved

See Table 137 for the description of this result code.

The Alarm is already in OneShotShelved state.

Table 91 specifies the AddressSpace representation for the OneShotShelve2 Method.

Table 91 – OneShotShelve2 Method AddressSpace definition

Attribute

Value

BrowseName

OneShotShelve2

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

AuditConditionShelvingEventType

Defined in 5.10.7

ConformanceUnits

A & C Shelving2

If Auditing is supported, this Method shall generate an Event of AuditConditionShelvingEventType for all invocations of the Method.

Alarms can be modelled with multiple exclusive sub-states and assigned limits or they may be modelled with nonexclusive limits that can be used to group multiple states together.

The LimitAlarmType is used to provide a base Type for AlarmConditionTypes with multiple limits. The LimitAlarmType is illustrated in Figure 18.

image021.png

Figure 18 – LimitAlarmType

The LimitAlarmType is formally defined in Table 92.

Table 92 – LimitAlarmType definition

Attribute

Value

BrowseName

LimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AlarmConditionType defined in clause 5.8.2.

HasSubtype

ObjectType

ExclusiveLimitAlarmType

Defined in Clause 5.8.19.3

HasSubtype

ObjectType

NonExclusiveLimitAlarmType

Defined in Clause 5.8.20

HasProperty

Variable

HighHighLimit

Double

PropertyType

Optional

HasProperty

Variable

HighLimit

Double

PropertyType

Optional

HasProperty

Variable

LowLimit

Double

PropertyType

Optional

HasProperty

Variable

LowLowLimit

Double

PropertyType

Optional

HasProperty

Variable

BaseHighHighLimit

Double

PropertyType

Optional

HasProperty

Variable

BaseHighLimit

Double

PropertyType

Optional

HasProperty

Variable

BaseLowLimit

Double

PropertyType

Optional

HasProperty

Variable

BaseLowLowLimit

Double

PropertyType

Optional

HasProperty

Variable

SeverityHighHigh

UInt16

PropertyType

Optional

HasProperty

Variable

SeverityHigh

UInt16

PropertyType

Optional

HasProperty

Variable

SeverityLow

UInt16

PropertyType

Optional

HasProperty

Variable

SeverityLowLow

UInt16

PropertyType

Optional

HasProperty

Variable

HighHighDeadband

Double

PropertyType

Optional

HasProperty

Variable

HighDeadband

Double

PropertyType

Optional

HasProperty

Variable

LowDeadband

Double

PropertyType

Optional

HasProperty

Variable

LowLowDeadband

Double

PropertyType

Optional

ConformanceUnits

A & C Exclusive Limit

A & C Non-Exclusive Limit

Four optional limits are defined that configure the states of the derived limit Alarm Types. These Properties shall be set for any Alarm limits that are exposed by the derived limit Alarm types. These Properties are listed as optional but at least one is required. For cases where an underlying system cannot provide the actual value of a limit, the limit Property shall still be provided, but will have its AccessLevel set to not readable. It is assumed that the limits are described using the same Engineering Unit that is assigned to the variable that is the source of the Alarm. For Rate of change limit Alarms, it is assumed this rate is units per second unless otherwise specified. The limits shall follow the following inequality HighHigh > High > Low > LowLow. If Deadband properties are provided then:

  • HighHighLimit - HighHighDeadband > HighLimit
  • HighLimit – HighDeadband > LowLimit
  • LowLimit + LowDeadband < HighLimit
  • LowLowLimit + LowLowDeadband < LowLimit

image022.png

Four optional base limits are defined that are used for AdaptiveAlarming. They contain the configured Alarm limit. If a Server supports AdaptiveAlarming for Alarm limits, the corresponding base Alarm limit shall be provided for any limits that are exposed by the derived limit Alarm types. The value of this property is the value of the limit to which an AdaptiveAlarm can be reset if any algorithmic changes need to be discarded.

The Alarm limits listed may cause an Alarm to be generated when a value equals the limit or it may generate the Alarm when the limit is exceeded, (i.e. the Value is above the limit for HighLimit and below the limit for LowLimit). The exact behaviour when the value is equal to the limit is Server specific.

The Variable that is the source of the LimitAlarmType Alarm shall be a scalar. This LimitAlarmType can be subtyped if the Variable that is the source is an array. The subtype shall describe the expected behaviour with respect to limits and the array values. Some possible options:

  • if any element of the array exceeds the limit an Alarm is generated,
  • if all elements exceed the limit an Alarm is generated,
  • the limits may also be an array, in which case if any array limit is exceeded by the corresponding source array element, an Alarm is generated.

The four optional severity Properties, if defined, provided the severity for each of the limits.

The four optional deadband Properties, if they are defined, are used to delay the return to normal until the value is within the limit by the value of the deadband. For example, if a Value exceeds a HighLimit of 20, and there is a HighDeadband define of 1, the value will remain in alarm until the Value drops below 19. An Alarm deadband can be used to limit Alarms in a system where values may bounce or have some noise (i.e. the value is jumping up and down by 0.2). They keep the Alarm from being reactivated until it has dropped enough to not retrigger by noise.

In the event of a restart of an AlarmManager, the AlarmManager shall recover the LimitAlarm state, this also applies to all subtypes.

This clause describes the state machine and the base Alarm Type behaviour for AlarmConditionTypes with multiple mutually exclusive limits.

The ExclusiveLimitStateMachineType defines the state machine used by AlarmConditionTypes that handle multiple mutually exclusive limits. It is illustrated in Figure 19.

image023.png

Figure 19 – ExclusiveLimitStateMachineType

It is created by extending the FiniteStateMachineType. It is formally defined in Table 93 and the state transitions are described in Table 94.

Table 93 – ExclusiveLimitStateMachineType definition

Attribute

Value

BrowseName

ExclusiveLimitStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType

HasComponent

Object

HighHigh

StateType

HasComponent

Object

High

StateType

HasComponent

Object

Low

StateType

HasComponent

Object

LowLow

StateType

HasComponent

Object

LowToLowLow

TransitionType

HasComponent

Object

LowLowToLow

TransitionType

HasComponent

Object

HighToHighHigh

TransitionType

HasComponent

Object

HighHighToHigh

TransitionType

ConformanceUnits

A & C Exclusive Limit

Table 94 – ExclusiveLimitStateMachineType Additional References

SourceBrowsePath

References

IsForward

TargetBrowsePath

HighHighToHigh

FromState

True

HighHigh

ToState

True

High

HasEffect

True

AlarmConditionType

HighToHighHigh

FromState

True

High

ToState

True

HighHigh

HasEffect

True

AlarmConditionType

LowLowToLow

FromState

True

LowLow

ToState

True

Low

HasEffect

True

AlarmConditionType

LowToLowLow

FromState

True

Low

ToState

True

LowLow

HasEffect

True

AlarmConditionType

The component Variables of the ExclusiveLimitStateMachineType have additional Attributes defined in Table 95.

Table 95 ExclusiveLimitStateMachineType Attribute values for child Nodes

BrowsePath

Value Attribute

HighHigh

0:StateNumber

1

High

0:StateNumber

2

Low

0:StateNumber

3

LowLow

0:StateNumber

4

LowToLowLow

0:TransitionNumber

34

LowLowToLow

0:TransitionNumber

43

HighToHighHigh

0:TransitionNumber

21

HighHighToHigh

0:TransitionNumber

12

The ExclusiveLimitStateMachineType defines the sub state machine that represents the actual level of a multilevel Alarm when it is in the Active state. The sub state machine defined here includes High, Low, HighHigh and LowLow states. This model also includes in its transition state a series of transition to and from a parent state, the inactive state. This state machine as it is defined shall be used as a sub state machine for a state machine which has an Active state. This Active state could be part of a “level” Alarm or “deviation” Alarm or any other Alarm state machine.

The LowLow, Low, High, HighHigh are typical for many industries. Vendors can introduce sub-state models that include additional limits; they may also omit limits in an instance. If a model omits states or transitions in the StateMachine, it is recommended that they provide the optional Property AvailableStates and/or AvailableTransitions (see 10000-16).

The ExclusiveLimitAlarmType is used to specify the common behaviour for Alarm Types with multiple mutually exclusive limits. The ExclusiveLimitAlarmType is illustrated in Figure 20.

image024.png

Figure 20 – ExclusiveLimitAlarmType

The ExclusiveLimitAlarmType is formally defined in Table 96.

Table 96 – ExclusiveLimitAlarmType definition

Attribute

Value

BrowseName

ExclusiveLimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the LimitAlarmType defined in clause 5.8.18.

HasSubtype

ObjectType

ExclusiveLevelAlarmType

Defined in Clause 5.8.21.3

HasSubtype

ObjectType

ExclusiveDeviationAlarmType

Defined in Clause 5.8.22.3

HasSubtype

ObjectType

ExclusiveRateOfChangeAlarmType

Defined in Clause 5.8.23.3

HasComponent

Object

LimitState

ExclusiveLimitStateMachineType

Mandatory

ConformanceUnits

A & C Exclusive Limit

The LimitState is a sub state of the ActiveState and has an IsTrueSubStateOf reference to the ActiveState. The LimitState represents the actual limit that is violated in an instance of ExclusiveLimitAlarmType. When the ActiveState of the AlarmConditionType is inactive the LimitState shall not be available and shall return NULL on read. Any Events that subscribe for fields from the LimitState when the ActiveState is inactive shall return a NULL for these unavailable fields.

The NonExclusiveLimitAlarmType is used to specify the common behaviour for Alarm Types with multiple non-exclusive limits. The NonExclusiveLimitAlarmType is illustrated in Figure 21.

image025.png

Figure 21 – NonExclusiveLimitAlarmType

The NonExclusiveLimitAlarmType is formally defined in Table 97 and Table 98.

Table 97 – NonExclusiveLimitAlarmType definition

Attribute

Value

BrowseName

NonExclusiveLimitAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the LimitAlarmType defined in clause 5.8.18.

HasSubtype

ObjectType

NonExclusiveLevelAlarmType

Defined in Clause 5.8.21.2

HasSubtype

ObjectType

NonExclusiveDeviationAlarmType

Defined in Clause 5.8.22.2

HasSubtype

ObjectType

NonExclusiveRateOfChangeAlarmType

Defined in Clause 5.8.23.2

HasComponent

Variable

HighHighState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

HighState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

LowState

LocalizedText

TwoStateVariableType

Optional

HasComponent

Variable

LowLowState

LocalizedText

TwoStateVariableType

Optional

ConformanceUnits

A & C Non-Exclusive Limit

Table 98 – NonExclusiveLimitAlarmType Additional Subcomponents

BrowsePath

References

NodeClass

BrowseName

DataType

TypeDefinition

Others

HighHighState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

HighHighState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

HighState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

HighState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

LowState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

LowState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

LowLowState

HasProperty

Variable

TrueState

LocalizedText

PropertyType

LowLowState

HasProperty

Variable

FalseState

LocalizedText

PropertyType

The empty Others” column indicates that no ModellingRule applies.

HighHighState, HighState, LowState, and LowLowState represent the non-exclusive states. As an example, it is possible that both HighState and HighHighState are in their True state. Vendors may choose to support any subset of these states. Recommended state names are described in A.1.

Four optional limits are defined that configure these states. At least the HighState or the LowState shall be provided even though all states are optional. It is implied by the definition of a HighState and a LowState, that these groupings are mutually exclusive. A value cannot exceed both a HighState value and a LowState value simultaneously.

A level Alarm is commonly used to report when a limit is exceeded. It typically relates to an instrument – e.g. a temperature meter. The level Alarm becomes active when the observed value is above a high limit or below a low limit.

The NonExclusiveLevelAlarmType is a special level Alarm utilized with one or more non-exclusive states. If for example both the High and HighHigh states need to be maintained as active at the same time then an instance of NonExclusiveLevelAlarmType should be used.

The NonExclusiveLevelAlarmType is based on the NonExclusiveLimitAlarmType. It is formally defined in Table 99.

Table 99 – NonExclusiveLevelAlarmType definition

Attribute

Value

BrowseName

NonExclusiveLevelAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.20.

ConformanceUnits

A & C Non-Exclusive Level

No additional Properties to the NonExclusiveLimitAlarmType are defined.

The ExclusiveLevelAlarmType is a special level Alarm utilized with multiple mutually exclusive limits. It is formally defined in Table 100.

Table 100 – ExclusiveLevelAlarmType definition

Attribute

Value

BrowseName

ExclusiveLevelAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.19.3.

ConformanceUnits

A & C Exclusive Level

No additional Properties to the ExclusiveLimitAlarmType are defined.

A deviation Alarm is commonly used to report an excess deviation between a desired set point level of a process value and an actual measurement of that value. The deviation Alarm becomes active when the deviation exceeds or drops below a defined limit.

For example, if a set point had a value of 10, a high deviation Alarm limit of 2 and a low deviation Alarm limit of -1 then the low sub state is entered if the process value drops below 9; the high sub state is entered if the process value raises above 12. If the set point were changed to 11 then the new deviation values would be 10 and 13 respectively. The set point can be fixed by a configuration, adjusted by an Operator or it can be adjusted by an algorithm, the actual functionality exposed by the set point is application specific. The deviation Alarm can also be used to report a problem between a redundant data source where the difference between the primary source and the secondary source exceeds the included limit. In this case, the SetpointNode would point to the secondary source.

The LowLimit and LowLowLimit shall be negative, indicating a number below the target value and the HighLimit and HighHighLimit shall be positive, indicating a number above the target value. If provided, the limits shall not be zero and shall follow these rules:

For example, if the LowLimit is -2 then a LowLowLimit of -1 would not be allowed, but a LowLowLimit of -3 would be allowed.

The NonExclusiveDeviationAlarmType is a special level Alarm utilized with one or more non-exclusive states. If for example both the High and HighHigh states need to be maintained as active at the same time then an instance of NonExclusiveDeviationAlarmType should be used.

The NonExclusiveDeviationAlarmType is based on the NonExclusiveLimitAlarmType. It is formally defined in Table 101.

Table 101 – NonExclusiveDeviationAlarmType definition

Attribute

Value

BrowseName

NonExclusiveDeviationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.20.

HasProperty

Variable

SetpointNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

BaseSetpointNode

NodeId

PropertyType

Optional

ConformanceUnits

A & C Non-Exclusive Deviation

The SetpointNode Property provides the NodeId of the set point used in the deviation calculation. In cases where the Alarm is generated by an underlying system and if the Variable is not in the AddressSpace, a NULL NodeId shall be provided.

The BaseSetpointNode Property provides the NodeId of the original or base setpoint. The value of this node is the value of the setpoint to which an AdaptiveAlarm can be reset if any algorithmic changes need to be discarded. The value of this node usually contains the originally configured set point.

The ExclusiveDeviationAlarmType is utilized with multiple mutually exclusive limits. It is formally defined in Table 102.

Table 102 – ExclusiveDeviationAlarmType definition

Attribute

Value

BrowseName

ExclusiveDeviationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.19.3.

HasProperty

Variable

SetpointNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

BaseSetpointNode

NodeId

PropertyType

Optional

ConformanceUnits

A & C Exclusive Deviation

The SetpointNode Property provides the NodeId of the set point used in the Deviation calculation. If this Variable is not in the AddressSpace, a NULL NodeId shall be provided.

The BaseSetpointNode Property provides the NodeId of the original or base setpoint. The value of this node is the value of the set point to which an AdaptiveAlarm can be reset if any algorithmic changes need to be discarded. The value of this node usually contains the originally configured set point.

A Rate of Change Alarm is commonly used to report an unusual change or lack of change in a measured value related to the speed at which the value has changed. The Rate of Change Alarm becomes active when the rate at which the value changes exceeds or drops below a defined limit.

A Rate of Change is measured in some time unit, such as seconds or minutes and some unit of measure such as percent or meter. For example, a tank may have a High limit for the Rate of Change of its level (measured in meters) which would be 4 meters per minute. If the tank level changes at a rate that is greater than 4 meters per minute then the High sub state is entered.

The NonExclusiveRateOfChangeAlarmType is a special level Alarm utilized with one or more non-exclusive states. If for example both the High and HighHigh states need to be maintained as active at the same time this AlarmConditionType should be used

The NonExclusiveRateOfChangeAlarmType is based on the NonExclusiveLimitAlarmType. It is formally defined in Table 103.

Table 103 – NonExclusiveRateOfChangeAlarmType definition

Attribute

Value

BrowseName

NonExclusiveRateOfChangeAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the NonExclusiveLimitAlarmType defined in clause 5.8.20.

HasProperty

Variable

EngineeringUnits

EUInformation

PropertyType

Optional

ConformanceUnits

A & C Non-Exclusive RateOfChange

EngineeringUnits provides the engineering units associated with the limits values. If this is not provided the assumed Engineering Unit is the same as the EU associated with the parent variable per second e.g. if parent is meters, this unit is meters/second.

ExclusiveRateOfChangeAlarmType is utilized with multiple mutually exclusive limits. It is formally defined in Table 104.

Table 104 – ExclusiveRateOfChangeAlarmType definition

Attribute

Value

BrowseName

ExclusiveRateOfChangeAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Inherits the Properties of the ExclusiveLimitAlarmType defined in clause 5.8.19.3.

HasProperty

Variable

EngineeringUnits

EUInformation

PropertyType

Optional

ConformanceUnits

A & C Exclusive RateOfChange

EngineeringUnits provides the engineering units associated with the limits values. If this is not provided the assumed Engineering Unit is the same as the EU associated with the parent variable per second e.g. if parent is meters, this unit is meters/second.

The DiscreteAlarmType is used to classify Types into Alarm Conditions where the input for the Alarm may take on only a certain number of possible values (e.g. True/False, running/stopped/terminating). The DiscreteAlarmType with sub types defined in this standard is illustrated in Figure 22. It is formally defined in Table 105.

image026.png

Figure 22 – DiscreteAlarmType Hierarchy

Table 105 – DiscreteAlarmType definition

Attribute

Value

BrowseName

DiscreteAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AlarmConditionType defined in clause 5.8.2.

HasSubtype

ObjectType

OffNormalAlarmType

Defined in Clause 5.8.22

ConformanceUnits

A & C Discrete

The OffNormalAlarmType is a specialization of the DiscreteAlarmType intended to represent a discrete Condition that is considered to be not normal. It is formally defined in Table 106. This sub type is usually used to indicate that a discrete value is in an Alarm state, it is active as long as a non-normal value is present.

Table 106 – OffNormalAlarmType definition

Attribute

Value

BrowseName

OffNormalAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the DiscreteAlarmType defined in clause 5.8.24.1

HasSubtype

ObjectType

TripAlarmType

Defined in Clause 5.8.24.4

HasSubtype

ObjectType

SystemOffNormalAlarmType

Defined in Clause 5.8.24.3

HasProperty

Variable

NormalState

NodeId

PropertyType

Mandatory

ConformanceUnits

A & C OffNormal

The NormalState Property is a Property that points to a Variable which has a value that corresponds to one of the possible values of the Variable pointed to by the InputNode Property where the NormalState Property Variable value is the value that is considered to be the normal state of the Variable pointed to by the InputNode Property. When the value of the Variable referenced by the InputNode Property is not equal to the value of the NormalState Property the Alarm is Active. If this Variable is not in the AddressSpace, a NULL NodeId shall be provided.

This Condition is used by a Server to indicate that an underlying system that is providing Alarm information is having a communication problem and that the Server may have invalid or incomplete Condition state in the Subscription. Its representation in the AddressSpace is formally defined in Table 107.

Table 107 – SystemOffNormalAlarmType definition

Attribute

Value

BrowseName

SystemOffNormalAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasSubtype

ObjectType

CertificateExpirationAlarmType

Defined in Clause 5.8.24.7

Subtype of the OffNormalAlarmType, i.e. it has HasProperty References to the same Nodes.

ConformanceUnits

A & C SystemOffNormal

The TripAlarmType is a specialization of the OffNormalAlarmType intended to represent an equipment trip Condition. The Alarm becomes active when the monitored piece of equipment experiences some abnormal fault such as a motor shutting down due to an overload condition. It is formally defined in Table 108. This Type is mainly used for categorization.

Table 108 – TripAlarmType definition

Attribute

Value

BrowseName

TripAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the OffNormalAlarmType defined in clause 5.8.24.2.

ConformanceUnits

A & C Trip

The InstrumentDiagnosticAlarmType is a specialization of the OffNormalAlarmType intended to represent a fault in a field device. The Alarm becomes active when the monitored device experiences a fault such as a sensor failure. It is formally defined in Table 108. This Type is mainly used for categorization.

Table 109 – InstrumentDiagnosticAlarmType definition

Attribute

Value

BrowseName

InstrumentDiagnosticAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the OffNormalAlarmType defined in clause 5.8.24.2.

ConformanceUnits

A & C InstrumentDiagnostic

The SystemDiagnosticAlarmType is a specialization of the OffNormalAlarmType intended to represent a fault in a system or sub-system. The Alarm becomes active when the monitored system experiences a fault. It is formally defined in Table 108. This Type is mainly used for categorization.

Table 110 – SystemDiagnosticAlarmType definition

Attribute

Value

BrowseName

SystemDiagnosticAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the OffNormalAlarmType defined in clause 5.8.24.2.

ConformanceUnits

A & C SystemDiagnostic

This SystemOffNormalAlarmType is raised by the Server when the Server’s Certificate is within the ExpirationLimit of expiration. This Alarm automatically returns to normal when the certificate is updated.

Table 111 – CertificateExpirationAlarmType definition

Attribute

Value

BrowseName

CertificateExpirationAlarmType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the SystemOffNormalAlarmType defined in clause 5.8.24.3

HasProperty

Variable

ExpirationDate

DateTime

PropertyType

Mandatory

HasProperty

Variable

ExpirationLimit

Duration

PropertyType

Optional

HasProperty

Variable

CertificateType

NodeId

PropertyType

Mandatory

HasProperty

Variable

Certificate

ByteString

PropertyType

Mandatory

ConformanceUnits

A & C CertificateExpiration

ExpirationDate is the date and time this certificate will expire.

ExpirationLimit is the time interval before the ExpirationDate at which this Alarm will trigger. This shall be a positive number. If the property is not provided, a default of 2 weeks shall be used.

CertificateType – See Part 12 for definition of CertificateType.

Certificate is the certificate that is about to expire.

The DiscrepancyAlarmType is commonly used to report an action that did not occur within an expected time range.

The DiscrepancyAlarmType is based on the AlarmConditionType. It is formally defined in Table 112.

Table 112 – DiscrepancyAlarmType definition

Attribute

Value

BrowseName

DiscrepancyAlarmType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AlarmConditionType defined in 5.8.2.

HasProperty

Variable

TargetValueNode

NodeId

PropertyType

Mandatory

HasProperty

Variable

ExpectedTime

Duration

PropertyType

Mandatory

HasProperty

Variable

Tolerance

Double

PropertyType

Optional

ConformanceUnits

A & C Discrepancy

The TargetValueNode Property provides the NodeId of the Variable that is used for the target value.

The ExpectedTime Property provides the Duration within which the value pointed to by the InputNode shall equal the value specified by the TargetValueNode (or be within the Tolerance range, if specified).

The Tolerance Property is a value that can be added to or subtracted from the TargetValueNode’s value, providing a range that the value can be in without generating the Alarm.

A DiscrepancyAlarmType can be used to indicate a motor has not responded to a start request within a given time, or that a process value has not reached a given value after a setpoint change within a given time interval.

The DiscrepancyAlarmType shall return to normal when the value has reached the target value.

Conditions are used in specific application domains like Maintenance, System or Process. The ConditionClass hierarchy is used to specify domains and is orthogonal to the ConditionType hierarchy. The ConditionClassId Property of the ConditionType is used to assign a Condition to a ConditionClass. Clients can use this Property to filter out essential classes. OPC UA defines the base ObjectType for all ConditionClasses and a set of common classes used across many industries. Figure 23 informally describes the hierarchy of ConditionClass Types defined in this standard.

image027.png

Figure 23 – ConditionClass type hierarchy

ConditionClasses are not representations of Objects in the underlying system and, therefore, only exist as Type Nodes in the Address Space.

BaseConditionClassType is used as class whenever a Condition cannot be assigned to a more concrete class. Servers should use a more specific ConditionClass, if possible. All ConditionClass Types derive from BaseConditionClassType. It is formally defined in Table 113.

Table 113 – BaseConditionClassType definition

Attribute

Value

BrowseName

BaseConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseObjectType defined in 10000-5.

ConformanceUnits

A & C ConditionClasses

The ProcessConditionClassType is used to classify Conditions related to the process itself. Examples of a process would be a control system in a boiler or the instrumentation associated with a chemical plant or paper machine. The ProcessConditionClassType is formally defined in Table 114.

Table 114 – ProcessConditionClassType definition

Attribute

Value

BrowseName

ProcessConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause 5.9.2.

ConformanceUnits

A & C ConditionClasses

The MaintenanceConditionClassType is used to classify Conditions related to maintenance. Examples of maintenance would be Asset Management systems or conditions, which occur in process control systems, which are related to calibration of equipment. The MaintenanceConditionClassType is formally defined in Table 115. No further definition is provided here. It is expected that other standards groups will define domain-specific sub-types.

Table 115 – MaintenanceConditionClassType definition

Attribute

Value

BrowseName

MaintenanceConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause 5.9.2.

ConformanceUnits

A & C ConditionClasses

The SystemConditionClassType is used to classify Conditions related to the System. It is formally defined in Table 116. System Conditions occur in the controlling or monitoring system process. Examples of System related items could include available disk space on a computer, Archive media availability, network loading issues or a controller error. It is expected that other standards groups or vendors will define domain-specific sub-types.

Table 116 – SystemConditionClassType definition

Attribute

Value

BrowseName

SystemConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause 5.9.2.

ConformanceUnits

A & C ConditionClasses

The SafetyConditionClassType is used to classify Conditions related to safety. It is formally defined in Table 117.

Safety Conditions occur in the controlling or monitoring system process. Examples of safety related items could include, emergency shutdown systems or fire suppression systems.

Table 117 – SafetyConditionClassType definition

Attribute

Value

BrowseName

SafetyConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause 5.9.2.

ConformanceUnits

A & C ConditionClasses

In Alarm systems some Alarms may be classified as highly managed Alarms. This class of Alarm requires special handling that varies according to the individual requirements. It might require individual acknowledgement or not allow suppression or any of a number of other special behaviours. The HighlyManagedAlarmConditionClassType is used to classify Conditions as highly managed Alarms. It is formally defined in Table 118.

Table 118 – HighlyManagedAlarmConditionClassType definition

Attribute

Value

BrowseName

HighlyManagedAlarmConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause 5.9.2.

ConformanceUnits

A & C ConditionClasses

The TrainingConditionClassType is used to classify Conditions related to training system or training exercises. It is formally defined in Table 119. These Conditions typically occur in a training system or are generated as part of a simulation for a training exercise. Training Conditions might be process or system conditions. It is expected that other standards groups or vendors will define domain-specific sub-types.

Table 119 – TrainingConditionClassType definition

Attribute

Value

BrowseName

TrainingConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause.

ConformanceUnits

A & C ConditionClasses

The StatisticalConditionClassType is used to classify Conditions related that are based on statistical calculations. It is formally defined in Table 120. These Conditions are generated as part of a statistical analysis. They might be any of an Alarm number of types.

Table 120 – StatisticalConditionClassType definition

Attribute

Value

BrowseName

StatisticalConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause.

ConformanceUnits

A & C ConditionClasses

The TestingConditionClassType is used to classify Conditions related to testing of an Alarm system or Alarm function. It is formally defined in Table 121. Testing Conditions might include a condition to test an alarm annunciation such as a horn or other panel. It might also be used to temporarily reclassify a Condition to check response times or suppression logic. It is expected that other standards groups or vendors will define domain-specific sub-types.

Table 121 – TestingConditionClassType definition

Attribute

Value

BrowseName

TestingConditionClassType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseConditionClassType defined in clause 5.9.2.

ConformanceUnits

A & C ConditionClasses

If Auditing is supported by a Server, Events of AuditConditionEventType shall be generated. Following are the sub-types of AuditUpdateMethodEventType that will be generated in response to the Methods defined in this document. They are illustrated in Figure 24.

image028.png

Figure 24 – AuditEvent hierarchy

AuditConditionEventTypes are normally used in response to a Method call. However, these Events shall also be notified if the functionality of such a Method is performed by some other Server-specific means. In this case, the SourceName Property shall contain a proper description of this internal means and the other Properties should be filled in as described for the given EventType.

This EventType is used to subsume all AuditConditionEventTypes. It is formally defined in Table 122.

Table 122 – AuditConditionEventType definition

Attribute

Value

BrowseName

AuditConditionEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AuditUpdateMethodEventType defined in 10000-5

ConformanceUnits

A & C Auditing

AuditConditionEventTypes inherit all Properties of the AuditUpdateMethodEventType defined in 10000-5. Unless a subtype overrides the definition, the inherited Properties of the Condition will be used as defined.

This EventType can be further customized to reflect particular Condition related actions.

This EventType is used to indicate a change in the enabled state of a Condition instance. It is formally defined in Table 123.

Table 123 – AuditConditionEnableEventType definition

Attribute

Value

BrowseName

AuditConditionEnableEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Auditing

The SourceName shall indicate Method/Enable or Method/Disable. If the audit Event is not the result of a Method call, but due to an internal action of the Server, the SourceName shall reflect Enable or Disable, it may be preceded by an appropriate description such as “Internal/Enable” or “Remote/Enable”.

This EventType is used to report an AddComment action. It is formally defined in Table 124.

Table 124 – AuditConditionCommentEventType definition

Attribute

Value

BrowseName

AuditConditionCommentEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

ConditionEventId

ByteString

PropertyType

Mandatory

HasProperty

Variable

Comment

LocalizedText

PropertyType

Mandatory

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Auditing

The ConditionEventId field shall contain the id of the event for which the comment was added.

The Comment contains the actual comment that was added.

This EventType is used to report a Respond action (see 5.6). It is formally defined in Table 125.

Table 125 – AuditConditionRespondEventType definition

Attribute

Value

BrowseName

AuditConditionRespondEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

SelectedResponse

UInt32

PropertyType

Mandatory

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Dialog Auditing

The SelectedResponse field shall contain the response that was selected.

This EventType is used to indicate acknowledgement or confirmation of one or more Conditions. It is formally defined in Table 126.

Table 126 – AuditConditionAcknowledgeEventType definition

Attribute

Value

BrowseName

AuditConditionAcknowledgeEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

ConditionEventId

ByteString

PropertyType

Mandatory

HasProperty

Variable

Comment

LocalizedText

PropertyType

Mandatory

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Acknowledge Auditing

The ConditionEventId field shall contain the id of the Event that was acknowledged.

The Comment contains the actual comment that was added, it may be a blank comment or a NULL.

This EventType is used to report a Confirm action. It is formally defined in Table 127.

Table 127 – AuditConditionConfirmEventType definition

Attribute

Value

BrowseName

AuditConditionConfirmEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

ConditionEventId

ByteString

PropertyType

Mandatory

HasProperty

Variable

Comment

LocalizedText

PropertyType

Mandatory

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Confirm Auditing

The ConditionEventId field shall contain the id of the Event that was confirmed.

The Comment contains the actual comment that was added, it may be a blank comment or a NULL.

This EventType is used to indicate a change to the Shelving state of a Condition instance. It is formally defined in Table 128.

Table 128 – AuditConditionShelvingEventType definition

Attribute

Value

BrowseName

AuditConditionShelvingEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

ShelvingTime

Duration

PropertyType

Optional

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Shelving Auditing

If the Method indicates a TimedShelve operation, the ShelvingTime field shall contain duration for which the Alarm is to be shelved. For other Shelving Methods, this parameter may be omitted or NULL.

This EventType is used to indicate a change to the Suppression state of a Condition instance. It is formally defined in Table 129.

Table 129 – AuditConditionSuppressionEventType definition

Attribute

Value

BrowseName

AuditConditionSuppressionEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Suppression Auditing

This Event indicates an Alarm suppression operation. An audit Event of this type shall be generated, if audit events are supported for any suppression action, including automatic system based suppression.

This EventType is used to indicate a change to the Silence state of a Condition instance. It is formally defined in Table 130.

Table 130 – AuditConditionSilenceEventType definition

Attribute

Value

BrowseName

AuditConditionSilenceEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Silencing Auditing

This event indicates that an Alarm was silenced, but not acknowledged. An audit event of this type shall be generated, if Audit events are supported for any silence action, including automatic system based silence.

This EventType is used to indicate a change to the Latched state of a Condition instance. It is formally defined in Table 130.

Table 131 – AuditConditionResetEventType definition

Attribute

Value

BrowseName

AuditConditionResetEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C Latching Auditing

This event indicates that an Alarm was reset. An audit event of this type shall be generated, if Audit events are supported for any Alarm action.

This EventType is used to indicate a change to the OutOfService State of a Condition instance. It is formally defined in Table 132.

Table 132 – AuditConditionOutOfServiceEventType definition

Attribute

Value

BrowseName

AuditConditionOutOfServiceEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AuditConditionEventType defined in 5.10.2 that is, inheriting the InstanceDeclarations of that Node.

ConformanceUnits

A & C OutOfService Auditing

An audit Event of this type shall be generated if audit Events are supported.

Following are sub-types of SystemEventType that will be generated in response to a Refresh Methods call. They are illustrated in Figure 25.

image029.png

Figure 25 – Refresh Related Event Hierarchy

This EventType is used by a Server to mark the beginning of a Refresh Notification cycle. Its representation in the AddressSpace is formally defined in Table 133.

Table 133 – RefreshStartEventType definition

Attribute

Value

BrowseName

RefreshStartEventType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the SystemEventType defined in 10000-5, i.e. it has HasProperty References to the same Nodes.

ConformanceUnits

A & C Refresh

A & C Refresh2

This EventType is used by a Server to mark the end of a Refresh Notification cycle. Its representation in the AddressSpace is formally defined in Table 134.

Table 134 – RefreshEndEventType definition

Attribute

Value

BrowseName

RefreshEndEventType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the SystemEventType defined in 10000-5, i.e. it has HasProperty References to the same Nodes.

ConformanceUnits

A & C Refresh

A & C Refresh2

This EventType is used by a Server to indicate that a significant change has occurred in the Server or in the subsystem below the Server that may or does invalidate the Condition state of a Subscription. Its representation in the AddressSpace is formally defined in Table 135.

Table 135 – RefreshRequiredEventType definition

Attribute

Value

BrowseName

RefreshRequiredEventType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the SystemEventType defined in 10000-5, i.e. it has HasProperty References to the same Nodes.

ConformanceUnits

A & C Refresh

A & C Refresh2

When a Server detects an Event queue overflow, it shall track if any Condition Events have been lost, if any Condition Events were lost, it shall issue a RefreshRequiredEventType Event to the Client after the Event queue is no longer in an overflow state.

The HasCondition ReferenceType is a concrete ReferenceType and can be used directly. It is a subtype of NonHierarchicalReferences. The representation in the AddressSpace is specified in Table 136.

The semantic of this ReferenceType is to specify the relationship between a ConditionSource and its Conditions. Each ConditionSource shall be the target of a HasEventSource Reference or a sub type of HasEventSource. The AddressSpace organisation that shall be provided for Clients to detect Conditions and ConditionSources is defined in Clause 6. Various examples for the use of this ReferenceType can be found in B.2.

HasCondition References can be used in the Type definition of an Object or a Variable. In this case, the SourceNode of this ReferenceType shall be an ObjectType or VariableType Node or one of their InstanceDeclaration Nodes. The TargetNode shall be a Condition instance declaration or a ConditionType. The following rules for instantiation apply:

HasCondition References may be used solely in the instance space when they are not available in Type definitions. In this case the SourceNode of this ReferenceType shall be an Object, Variable or Method Node. The TargetNode shall be a Condition instance or a ConditionType.

Table 136 – HasCondition ReferenceType Definition

Attributes

Value

BrowseName

HasCondition

InverseName

IsConditionOf

Symmetric

False

IsAbstract

False

References

NodeClass

BrowseName

Comment

ConformanceUnits

A & C Basic

Table 137 defines the StatusCodes defined for Alarm & Conditions.

Table 137 – Alarm & Condition result codes

Symbolic Id

Description

Bad_ConditionAlreadyEnabled

The addressed Condition is already enabled.

Bad_ConditionAlreadyDisabled

The addressed Condition is already disabled.

Bad_ConditionAlreadyShelved

The Alarm is already in a shelved state.

Bad_ConditionBranchAlreadyAcked

The EventId does not refer to a state that needs acknowledgement.

Bad_ConditionBranchAlreadyConfirmed

The EventId does not refer to a state that needs confirmation.

Bad_ConditionNotShelved

The Alarm is not in the requested shelved state.

Bad_DialogNotActive

The DialogConditionType instance is not in Active state.

Bad_DialogResponseInvalid

The selected option is not a valid index in the ResponseOptionSet array.

Bad_EventIdUnknown

The specified EventId is not known to the Server.

Bad_RefreshInProgress

A ConditionRefresh operation is already in progress.

Bad_ShelvingTimeOutOfRange

The provided Shelving time is outside the range allowed by the Server for Shelving

This section describes behaviour that is expected from an OPC UA Server that is implementing the A & C Information Model. In particular this section describes specific behaviours that apply to various aspect of the A & C Information Model.

In some implementation of an OPC UA A & C Server, the Alarms and Condition are provided by an underlying system. The expected behaviour of an A & C Server when it is encountering communication problems with the underlying system is:

  • If communication fails to the underlying system,
  • For any Event field related information that is exposed in the address space, the Value/StatusCode obtained when reading the Event fields that are associated with the communication failure shall have a value of NULL and a StatusCode of Bad_CommunicationError.
  • For Subscriptions that contain Conditions for which the failure applies, the effected Conditions generate an Event, if the Retain field is set to True. These Events shall have their Event fields that are associated with the communication failure contain a StatusCode of Bad_CommunicationError for the value.
  • A Condition of the SystemOffNormalAlarmType shall be used to report the communication failure to Alarm Clients. The NormalState field shall contain the NodeId of the Variable that indicates the status of the underlying system.
  • For start-up of an A & C Server that is obtaining A & C information from an already running underlying system:
  • If a value is unavailable for an Event field that is being reported due to a start-up of the UA Server (i.e. the information is just not available for the Event) the Event field shall contain a StatusCode set to Bad_WaitingForInitialData for the value.
  • If the Time field is normally provided by the underlying system and is unavailable, the Time shall be reported as a StatusCode with a value of Bad_WaitingForInitialData.

In an OPC UA Server that is implementing the A & C Information Model and that is configured to be a redundant OPC UA Server the following behaviour is expected: