1 Scope

This document specifies the representation of Alarms and Conditions in the OPC Unified Architecture. Included is the Information Model representation of Alarms and Conditions in the OPC UA address space. Other aspects of alarm systems like alarm philosophy, life cycle, alarm response times, alarm types and many other details are captured in standards such as IEC 62682 and ISA 18.2. The Alarms and Conditions Information Model in this document, is designed in accordance with IEC 62682 and ISA 18.2. Annex C specifies how the model described in this document maps to EEMUA Publication 191. Annex D specifies a recommended mapping between OPC Classic Alarm & Events (A&E) servers to the model described in this document.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application.

10000-1: OPC UA Specification: Part 1 – Concepts

3 Terms, definitions, and abbreviations

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in 10000-1, 10000-3, 10000-4, and 10000-5 as well as the following apply.

3.1.1 Acknowledge

Operator action that confirms recognition of an Alarm

3.1.2 Active

alarm state in which the alarm condition is true

3.1.3 AdaptiveAlarm

Alarm for which the setpoint or limits are changed by an algorithm.

3.1.4 AlarmFlood

condition during which the alarm rate is greater than the Operator can effectively manage

3.1.5 AlarmManager

application that manages alarms in a system

3.1.6 AlarmSuppressionGroup

group of Alarms that is used to suppress other Alarms.

3.1.7 ConditionClass

Condition grouping that indicates in which domain or for what purpose a certain Condition is used

3.1.8 ConditionBranch

specific state of a Condition

3.1.9 ConditionSource

element which a specific Condition is based upon or related to

3.1.10 Confirm

Operator action informing the Server that a corrective action has been taken to address the cause of the Alarm

3.1.11 Disable

system is configured such that the Alarm will not be generated even though the base Alarm Condition is present

3.1.12 HighlyManagedAlarm

alarm belonging to a class with additional requirements above general alarms

3.1.13 LatchingAlarm

alarm that remains in alarm state after the process condition has returned to normal and requires an Operator reset before the alarm returns to normal

3.1.14 Operator

person who monitors and makes changes to the process

3.1.15 RateOfChangeAlarm

alarm generated when the change in process variable per unit time (dPV/dt) exceeds a defined setpoint

3.1.16 Refresh

act of providing an update to an Event Subscription that provides all Alarms which are considered to be Retained

3.1.17 Retain

Alarm in a state that is interesting for a Client wishing to synchronize its state of Conditions with the Server’s state

3.1.18 Shelving

facility where the Operator is able to temporarily prevent an Alarm from being displayed to the Operator when it is causing the Operator a nuisance

3.1.19 Suppress

act of determining whether an Alarm should not occur

3.2 Abbreviations and symbols

• A&E Alarm & Event (as used for OPC COM)

• COM (Microsoft Windows) Component Object Model

• DA Data Access

• MIME Multipurpose Internet Mail Extensions

• UA Unified Architecture

4 Concepts

4.1 General

This document defines an Information Model for Conditions, Dialog Conditions, and Alarms including acknowledgement capabilities. It is built upon and extends base Event handling which is defined in 10000-3, 10000-4 and 10000-5. This Information Model can also be extended to support the additional needs of specific domains. The details of what aspects of the Information Model are supported are defined via Profiles (see 10000-7 for Profile definitions). Some systems may expose historical Events and Conditions via the standard Historical Access framework (see 10000-11 for Historical Event definitions).

4.2 Conditions

Conditions are used to represent the state of a system or one of its components. Some common examples are:

• a temperature exceeding a configured limit

• a device needing maintenance

• a batch process that requires a user to confirm some step in the process before proceeding

Each Condition instance is of a specific ConditionType. The ConditionType and derived types are sub-types of the BaseEventType (see 10000-3 and 10000-5). This part defines types that are common across many industries. It is expected that vendors or other standardisation groups will define additional ConditionTypes deriving from the common base types defined in this part. The ConditionTypes supported by a Server are exposed in the AddressSpace of the Server.

Condition instances are specific implementations of a ConditionType. It is up to the Server whether such instances are also exposed in the Server’s AddressSpace. Clause 4.10 provides additional background about Condition instances. Condition instances shall have a unique identifier to differentiate them from other instances. This is independent of whether they are exposed in the AddressSpace.

As mentioned above, Conditions represent the state of a system or one of its components. In certain cases, however, previous states that still need attention are also maintained. ConditionBranches are introduced to deal with this requirement and distinguish current state and previous states. Each ConditionBranch has a BranchId that differentiates it from other branches of the same Condition instance. The ConditionBranch which represents the current state of the Condition (the trunk) has a NULL BranchId. Servers can generate separate Event Notifications for each branch. When the state represented by a ConditionBranch does not need further attention, a final Event Notification for this branch will have the Retain Property set to False. Clause 5.5 provides more information and use cases. Maintaining previous states and therefore the support of multiple branches is optional for Servers.

Conceptually, the lifetime of the Condition instance is independent of its state. However, Servers may provide access to Condition instances only while ConditionBranches exist.

The base Condition state model is illustrated in Figure 1. It is extended by the various Condition subtypes defined in this document and may be further extended by vendors or other standardisation groups. The primary states of a Condition are disabled and enabled. The Disabled state is intended to allow Conditions to be turned off at the Server or below the Server (in a device or some underlying system). The Enabled state is normally extended with the addition of sub-states.

A transition into the Disabled state results in a Condition Event however no subsequent Event Notifications are generated until the Condition returns to the Enabled state.

ISA 18.2 and IEC 62682, which are the basis for this information model, no longer support enabling and disabling of alarms. As a result, even though this feature is still supported for backward compatibility it is recommended that alarms never be disabled.

When a Condition enters the Enabled state, that transition and all subsequent transitions result in Condition Events being generated by the Server.

If Auditing is supported by a Server, the following Auditing related action shall be performed. The Server will generate AuditEvents for Enable and Disable operations (either through a Method call or some Server / vendor – specific means), rather than generating an AuditEvent Notification for each Condition instance being enabled or disabled. For more information, see the definition of AuditConditionEnableEventType in 5.10.2. AuditEvents are also generated for any other Operator action that results in changes to the Conditions.

4.3 Acknowledgeable Conditions

AcknowledgeableConditions are sub-types of the base ConditionType. AcknowledgeableConditions expose states related to acknowledged or confirmed in a Condition.

An AckedState and a ConfirmedState extend the EnabledState defined by the Condition. The state model is illustrated in Figure 2. The enabled state is extended by adding the AckedState and (optionally) the ConfirmedState.

Acknowledgment of the transition may come from the Client or may be due to some logic internal to the Server. For example, acknowledgment of a related Condition may result in this Condition becoming acknowledged, or the Condition may be set up to automatically Acknowledge itself when the acknowledgeable situation disappears.

Two Acknowledge state models are supported by this document. Either of these state models can be extended to support more complex acknowledgement situations.

The basic Acknowledge state model is illustrated in Figure 3. This model defines an AckedState. The specific state changes that result in a change to the state depend on a Server’s implementation. For example, in typical Alarm models the change is limited to a transition to the Active state or transitions within the Active state. More complex models however can also allow for changes to the AckedState when the Condition transitions to an inactive state.

A more complex state model which adds a confirmation to the basic Acknowledge is illustrated in Figure 4. The Confirmed Acknowledge model is typically used to differentiate between acknowledging the presence of a Condition and having done something to address the Condition. For example, an Operator receiving a motor high temperature Notification calls the Acknowledge Method to inform the Server that the high temperature has been observed. The Operator then takes some action such as lowering the load on the motor in order to reduce the temperature. The Operator then calls the Confirm Method to inform the Server that a corrective action has been taken.

The AcknowledgeableConditions model can also be used for a simple Condition that requires a confirmation. For example, a motor start event is not an alarm, just an action that is to be acknowledged by the operator. It could also be an event that is generated for an operator change of a process input (grade of paper being made) that needs to be acknowledged. It is not something that requires an anwser like a question, for this there are DialogCondition. It is just an acknowledge that the operator observed the change.

4.4 Previous states of Conditions

Some systems require that previous states of a Condition are preserved for some time. A common use case is the acknowledgement process. In certain environments, it is required to acknowledge both the transition into Active state and the transition into an Inactive state. Systems with strict safety rules sometimes require that every transition into Active state is acknowledged. In situations where state changes occur in short succession there can be multiple unacknowledged states and the Server maintains ConditionBranches for all previous unacknowledged states. These branches will be deleted after they have been acknowledged or if they reached their final state.

Multiple ConditionBranches can also be used for other use cases where snapshots of previous states of a Condition require additional actions.

4.5 Condition state synchronization

When a Client subscribes for Events, the Notification of transitions will begin at the time of the Subscription. The currently existing state will not be reported. This means for example that Clients are not informed of currently Active Alarms until a new state change occurs.

Clients can obtain the current state of all Condition instances that are in an interesting state, by requesting a Refresh for a Subscription. It should be noted that Refresh is not a general replay capability since the Server is not required to maintain an Event history.

Clients request a Refresh by calling the ConditionRefresh Method. The Server will respond with a RefreshStartEventType Event. This Event is followed by the Retained Conditions. The Server may also send new Event Notifications interspersed with the Refresh related Event Notifications. After the Server is done with the Refresh, a RefreshEndEvent is issued marking the completion of the Refresh. 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. If a ConditionBranch exists, then the current Condition shall be reported. This is True even if the only interesting item regarding the Condition is that ConditionBranches exist. This allows a Client to accurately represent the current Condition state.

A Client that wishes to display the current status of Alarms and Conditions (known as a “current Alarm display”) would use the following logic to process Refresh Event Notifications. The Client flags all Retained Conditions as suspect on reception of the Event of the RefreshStartEventType. The Client adds any new Events that are received during the Refresh without flagging them as suspect. The Client also removes the suspect flag from any Retained Conditions that are returned as part of the Refresh. When the Client receives a RefreshEndEvent, the Client removes any remaining suspect Events, since they no longer apply.

The following items should be noted with regard to ConditionRefresh:

• As described in 4.4 some systems require that previous states of a Condition are preserved for some time. Some Servers – in particular if they require acknowledgement of previous states – will maintain separate ConditionBranches for prior states that still need attention.

ConditionRefresh shall issue Event Notifications for all interesting states (current and previous) of a Condition instance and Clients can therefore receive more than one Event for a Condition instance with different BranchIds.

• It is possible under some circumstances a Server is not capable of ensuring the Client is fully in sync with the current state of Condition instances. For example, if the underlying system represented by the Server is reset or communications are lost for some period of time it can be necessary for the Server to resynchronize itself with the underlying system. In these cases, the Server sends an Event of the RefreshRequiredEventType to advise the Client that a Refresh may be necessary. A Client receiving this special Event should initiate a ConditionRefresh as noted in this clause.

• To ensure a Client is always informed, the three special EventTypes (RefreshEndEventType, RefreshStartEventType and RefreshRequiredEventType) ignore the Event content filtering associated with a Subscription and will always be delivered to the Client.

• ConditionRefresh applies to a Subscription. If multiple Event Notifiers are included in the same Subscription, all Event Notifiers are refreshed.

4.6 Severity, quality, and comment

Comment, Severity and Quality are important elements of Conditions and any change to them will cause Event Notifications.

The severity of a Condition is inherited from the base Event model defined in 10000-5. It indicates the urgency of the Condition and is also commonly called alarm priority or ‘priority’, especially in relation to Alarms in the ProcessConditionClassType. Severity is defined to have a range of 1-1000, but this range includes Alarms and other events that are not considered Alarms. For Alarms it is recommended that Severities above 400 be used. The 400-1000 range for Alarms should be further subdivided based on the severity of the Alarm. For an example of how Severity ranges are subdivided for diagnostics see 10000-26 LogRecord Severity Mapping.

A Comment is a user generated string that is associated with a certain state of a Condition.

Quality refers to the quality of the data value(s) upon which this Condition is based. Since a Condition is usually based on one or more Variables, the Condition inherits the quality of these Variables. E.g., if the process value is “Uncertain”, the “Level Alarm” Condition is also questionable. If more than one variable is represented by a given condition or if the condition is from an underlining system and no direct mapping to a variable is available, it is up to the application to determine what quality is displayed as part of the condition.

4.7 Dialogs

Dialogs are ConditionTypes used by a Server to request user input. They are typically used when a Server has entered some state that requires intervention by a Client. For example, a Server monitoring a paper machine indicates that a roll of paper has been wound and is ready for inspection. The Server would activate a Dialog Condition indicating to the user that an inspection is required. Once the inspection has taken place the user responds by informing the Server of an accepted or unaccepted inspection allowing the process to continue.

4.8 Alarms

Alarms are specializations of AcknowledgeableConditions that add the concepts of an Active state and other states like Shelving state and Suppressed state to a Condition. The state model is illustrated in Figure 5. The complete model with all states is defined in 5.8.

An Alarm in the Active state indicates that the situation the Condition is representing currently exists. When an Alarm is an inactive state it is representing a situation that has returned to a normal state.

Some Alarm subtypes introduce sub-states of the Active state. For example, an Alarm representing a temperature may provide a high level state as well as a critically high state (see following Clause).

The shelving state can be set by an Operator via OPC UA Methods. The suppressed state is set internally by the Server due to system specific reasons. Alarm systems typically implement the suppress, out of service and shelve features to help keep Operators from being overwhelmed during Alarm “storms” by limiting the number of Alarms an Operator sees on a current Alarm display. This is accomplished by setting the SuppressedOrShelved flag on second order dependent Alarms and/or Alarms of less severity, leading the Operator to concentrate on the most critical issues.

The LatchedState is a state that is added to any alarm that requires additional processing, once it goes active it does not clear until it is explicitly reset, even if the value that triggered the alarm returns to normal. This can be an alarm that requires a physical inspection once it has occurred to ensure it is no longer in alarm, or a series of tests that might be required to ensure the alarm is no longer active or some other actions. Any AlarmType can become a latched alarm by the addition of this optional sub-state.

The shelved, out of service and suppressed states differ from the Disabled state in that Alarms are still fully functional and can be included in Subscription Notifications to a Client. A disabled Alarm is not processed in any manner, and is not supported as part of the active Alarm model defined in ISA 18.2.

Alarms follow a typical timeline that is illustrated in Figure 6. They have a number of delay times associated with them and a number of states that they might occupy. The goal of an alarming system is to inform Operators about conditions in a timely manner and allow the Operator to take some action before some consequences occur. The consequences may be economic (product is not usable and is discard), may be physical (tank overflows), may safety (fire or explosion could occur) or any of a number of other possibilities. Typically, if no action is taken related to an alarm for some period of time the process will cross some threshold at which point consequences will start to occur. The OPC UA Alarm model describes these states, delays and actions.

4.9 Multiple active states

In some cases, it is desirable to further define the Active state of an Alarm by providing a sub-state machine for the Active State. For example, a multi-state level Alarm when in the Active state may be in one of the following sub-states: LowLow, Low, High or HighHigh. The state model is illustrated in Figure 7.

With the multi-state Alarm model, state transitions among the sub-states of Active are allowed without causing a transition out of the Active state.

To accommodate different use cases both a (mutually) exclusive and a non-exclusive model are supported.

Exclusive means that the Alarm can only be in one sub-state at a time. If for example a temperature exceeds the HighHigh limit the associated exclusive level Alarm will be in the HighHigh sub-state and not in the High sub-state.

Some Alarm systems, however, allow multiple sub-states to exist in parallel. This is called non-exclusive. In the previous example where the temperature exceeds the HighHigh limit a non-exclusive level Alarm will be both in the High and the HighHigh sub-state.

4.10 Condition instances in the AddressSpace

Because Conditions always have a state (Enabled or Disabled) and possibly many sub-states it makes sense to have instances of Conditions present in the AddressSpace. If the Server exposes Condition instances they usually will appear in the AddressSpace as components of the Objects that “own” them. For example, a temperature transmitter that has a built-in high temperature Alarm would appear in the AddressSpace as an instance of some temperature transmitter Object with a HasComponent Reference to an instance of a LimitAlarmType.

The availability of instances allows Data Access Clients to monitor the current Condition state by subscribing to the Attribute values of Variable Nodes. It is possible that the value of a node may not always correspond with the value that appears in the Event. The value could be more recent than the value in the Event.

While exposing Condition instances in the AddressSpace is not always possible, doing so allows for direct interaction (read, write and Method invocation) with a specific Condition instance. For example, if a Condition instance is not exposed, there is no way to invoke the Enable or Disable Method for the specific Condition instance.

4.11 Alarm and Condition auditing

The OPC UA Standards include provisions for auditing. Auditing is an important security and tracking concept. Audit records provide the “Who”, “When” and “What” information regarding user interactions with a system. These audit records are especially important when Alarm management is considered. Alarms are the typical instrument for providing information to a user that something needs the user’s attention. A record of how the user reacts to this information is required in many cases. Audit records are generated for all Method calls that affect the state of the system, for example, an Acknowledge Method call would generate an AuditConditionAcknowledgeEventType Event.

The standard AuditEventTypes defined in 10000-5 already include the fields required for Condition related audit records. To allow for filtering and grouping, this document defines a number of sub-types of the AuditEventTypes but without adding new fields to them.

This document describes the AuditEventType that each Method shall generate if Audit Events are supported by the Server. For example, the Disable Method has an AlwaysGeneratesEvent Reference to an AuditConditionEnableEventType. An Event of this type shall be generated for every invocation of the Method if audit events are supported. The audit Event describes the user interaction with the system, in some cases this interaction may affect more than one Condition or be related to more than one state.

4.12 Alarms in a system

In a system, alarms might be managed at different levels and by different applications. An alarm might be detected in an instrument, but the full alarm model for that alarm instance might be maintained in a higher level Server. This can cause issues in cases where the instrument is restarted or the UA Server that is acting as an alarm server is restarted. It is desirable that the state of alarms is maintained and that after any restart of either application all alarms recover their same state as before the restart. But it is acceptable if an alarm might require some management actions again following a restart. It is not acceptable that a device that is in alarm is no longer reported as being in alarm. For example, if the AlarmManager is restarted, when it recovers, can detect that the device has an alarm, but possibly not be able to recover that the alarm has a comment or that it was acknowledged. The individual Objects models provide details about Alarm states and recovery.

5 Model

5.1 General

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 document can be further extended from domain to 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.

5.2 Two-state state machines

Most states defined in this document 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 1.

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.

5.3 ConditionVariable

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

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.

5.4 ReferenceTypes

5.4.1 General

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. TwoStateVariableTypes can be extended with subordinate state machines in a similar fashion to the StateMachineType defined in 10000-16.

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 and will be reported as a NULL.

5.4.2 HasTrueSubState ReferenceType

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

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.

5.4.3 HasFalseSubState ReferenceType

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

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.

5.4.4 HasAlarmSuppressionGroup ReferenceType

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 5

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.

5.4.5 AlarmGroupMember ReferenceType

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 6

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.

5.4.6 AlarmSuppressionGroupMember ReferenceType

The AlarmSuppressionGroupMember 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 7

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.

5.5 Condition Model

5.5.1 General

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.

5.5.2 ConditionType

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

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 shall assign a non-NULL BranchId. An initial Event for the branch shall be 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

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 the Condition instance enters the Disabled state, the Retain Property of this Condition shall be set to False by the Server to indicate to the Client that the Condition instance is currently not of interest to Clients. This includes all ConditionBranches if any branches exist.

• When the Condition instance enters the enabled state, the Condition shall be evaluated and all of its Properties updated to reflect the current values. If this evaluation causes the Retain Property to transition to True for any ConditionBranch, then an Event Notification shall be generated for that ConditionBranch.

• The Server may choose to continue to test for a Condition instance while it is Disabled. However, no Event Notifications will be generated while the Condition instance is disabled.

• For any Condition that exists in the AddressSpace the Attributes and the following Variables will continue to have valid values even in the Disabled state; EventId, Event Type, SourceNode, SourceName, Time, and EnabledState. Other Properties may no longer provide current valid values. All Variables that are no longer provided shall return a status of Bad_ConditionDisabled. The Event that reports the Disabled state should report the Properties as NULL or with a status of Bad_ConditionDisabled.

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

• Quality

• Severity (inherited from BaseEventType)

• Comment

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. The Comment field may reference a MaxStringLength Property which would limit the length of the string. This MaxStringLength may be added to the individual Alarm instance, in which case it would apply only to that Alarm instance, but it can also be added to the Comment Variable in the ConditionType, which would limit the size of the Comment string for all Alarm instances. If the Property is provided on both the instance and the type, the instance takes precedence over the type. All Methods that can provide a Comment argument shall restrict Comment to this limit. If a Comment is provided that exceeds this limit, a Bad_InvalidArgument shall be returned from the Method.

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 10) in the SelectClause of the EventFilter: See 10000-4 for a detailed definition of the SelectClause in an Event Subscription.

5.5.3 Condition and branch instances

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 document does not define a standard way to make them visible.

5.5.4 Disable Method

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 are not required to 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 11 (defined in Call Service)

Table 12 specifies the AddressSpace representation for the Disable Method.

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

5.5.5 Enable 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 are not required to 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 13 (defined in Call Service)

Table 14 specifies the AddressSpace representation for the Enable Method.

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

5.5.6 AddComment 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 15

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

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.

If the Comment field is NULL (both locale and text are empty) it shall be ignored, and any existing comments will remain unchanged, and an error (Bad_InvalidArgument) shall be returned. To reset the Comment an empty text with a locale shall be provided.

A ConditionEvent with all Condition values, where the Comment Variable contains the added text, will be sent for the \state identified by the EventId. 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 sent.

Table 17 specifies the AddressSpace representation for the AddComment Method.

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

5.5.7 ConditionRefresh 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 18

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

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 could replay the exact Events with all Properties/Variables maintaining the same values as originally sent, but other Servers would only 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 could 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 there is 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 the refresh of more than one Subscription is desired, 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 20 specifies the AddressSpace representation for the ConditionRefresh Method.

5.5.8 ConditionRefresh2 Method

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 resynchronization is only for a single MonitoredItem in 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 shall 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 21

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

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 could replay the exact Events with all Properties/Variables maintaining the same values as originally sent, but other Servers would only 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 could 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 the refresh of more than one MonitoredItem or Subscription is desired, 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 23 specifies the AddressSpace representation for the ConditionRefresh2 Method.

5.6 Dialog Model

5.6.1 General

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.

5.6.2 DialogConditionType

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

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.

5.6.3 Respond Method

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 26

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

Table 28 specifies the AddressSpace representation for the Respond Method.

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

5.6.4 Respond2 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] LocalizedText	Comment
		);

The parameters are defined in Table 29

If the Comment argument is NULL (both locale and text are empty) it shall be ignored and any existing comments will remain unchanged. To reset the comment, an empty text with a locale shall be provided.

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

Table 31 specifies the AddressSpace representation for the Respond2 Method.

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

5.7 Acknowledgeable Condition Model

5.7.1 General

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.

5.7.2 AcknowledgeableConditionType

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

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

5.7.3 Acknowledge Method

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 34

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

Comments

A Server is responsible to ensure that each Event has a unique EventId. This allows Clients to identify and acknowledge a particular Event Notification.

The EventId identifies a specific Event Notification with an acknowledgeable state was reported. Acknowledgement and the optional comment will be applied to the state identified with the EventId. If the comment field is NULL (both locale and text are empty) it will be ignored and any existing comments will remain unchanged. To reset the comment, an empty text with a locale shall be provided.

A valid EventId will result in an Event Notification where AckedState/Id is set to True and the Comment Property contains the text of the optional comment argument. If a previous state is acknowledged, the BranchId and all Condition values of this branch will be reported. Table 36 specifies the AddressSpace representation for the Acknowledge Method.

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

5.7.4 Confirm 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] LocalizedText	Comment
		);
The parameters are defined in Table 37

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

Comments

A Server is responsible to ensure that each Event has a unique EventId. This allows Clients to identify and confirm a particular Event Notification.

The EventId identifies a specific Event Notification with a confirmable state was reported.

A Comment can be provided which will be applied to the state identified with the EventId. If the comment argument is NULL (both locale and text are empty) it will be ignored and any existing comments will remain unchanged. If the comment is to be reset, an empty text with a locale shall be provided.

A valid EventId will result in an Event Notification where ConfirmedState/Id is set to True and the Comment Property contains the text of the optional comment argument. If a previous state is confirmed, the BranchId and all Condition values of this branch will be reported. A Client can confirm only events that have a ConfirmedState/Id set to False. The logic for setting ConfirmedState/Id to False is Server specific and may even be event or condition specific.

Table 39 specifies the AddressSpace representation for the Confirm Method.

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

5.8 Alarm model

5.8.1 General

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

5.8.2 AlarmConditionType

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 40 and Table 41.

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 in A.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 shall be played when an audible Alarm is 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 the audible sound. Typically, it is used when an Operator silences all Alarms on a screen, but will 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 shall 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.

5.8.3 AlarmGroupType

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.

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 instance of AlarmConditionType (or a subtype of it) shall be present in an instance of an AlarmGroupType.

5.8.4 AlarmSuppressionGroupType

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.

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 BaseDataVariableType with a DataType of Boolean referenced by AlarmSuppressionGroupMember references. At least one these instances shall be present in an instance of an AlarmSupressionGroupType.

5.8.5 Reset Method

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 44 (defined in Call service)

Table 45 specifies the AddressSpace representation for the Reset Method.

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

5.8.6 Reset2 Method

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

Signature

	Reset2(
		[in] LocalizedText	Comment
		);

The parameters are defined in Table 46.

If the Comment argument is NULL (both locale and text are empty) it shall be ignored and any existing comments will remain unchanged. To reset the comment, an empty text with a locale shall be provided.

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

Table 48 specifies the AddressSpace representation for the Reset2 Method.

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

5.8.7 Silence 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 49 (defined in Call service)