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.

Operator action that indicates recognition of an Alarm

Note 1 to entry: This definition is copied from EEMUA. The term “Accept” is another common term used to describe Acknowledge. They can be used interchangeably. This document will use Acknowledge.

state for an Alarm that indicates that the situation the Alarm is representing currently exists

Note 1 to entry: Other common terms defined by EEMUA are “Standing” for an Active Alarm and “Cleared” when the Condition has returned to normal and is no longer Active.

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

Note 1 to entry:  AdaptiveAlarms are alarms that are adjusted automatically by algorithms. These algorithms might detect conditions in a plant and change setpoints or limits to keep alarms from occurring. These changes occur, in many cases, without Operator interactions.

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

Note 1 to entry:  OPC UA does not define the conditions that would be considered alarm flooding, these conditions are defined in other specification such as IEC 62682 or ISA 18.2

application that manages alarms in a system

Note 1 An AlarmManager usually includes higher level functionality like intelligent alarm suppression or dynamic adjustment of limits or other alarm management functionality. It will still act on the alarm model associated with the actual alarm source.

group of Alarms that is used to suppress other Alarms.

Note 1 to entry:  An AlarmSuppressionGroup is an instance of an AlarmGroupType that is used to suppress other Alarms. If any Alarm in the group is active, then the AlarmSuppressionGroup is active. If all Alarms in the AlarmSuppressionGroup are inactive then the AlarmSuppressionGroup is inactive.

Note 2 to entry: The Alarm to be affected references AlarmSuppressionGroups with a HasAlarmSuppressionGroup ReferenceType.

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

Note 1 to entry: Some top-level ConditionClasses are defined in this specification. Vendors or organisations may derive more concrete classes or define different top-level classes.

specific state of a Condition

Note 1 to entry: The Server can maintain ConditionBranches for the current state as well as for previous states.

element which a specific Condition is based upon or related to

Note 1 to entry: Typically, it will be a Variable representing a process tag (e.g. FIC101) or an Object representing a device or subsystem.

In Events generated for Conditions, the SourceNode Property (inherited from the BaseEventType) will contain the NodeId of the ConditionSource.

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

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

Note 1 to entry:  This definition is copied from EEMUA and is further defined in EEMUA.

In IEC 62682 disable has been replaced with “Out of Service”.

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

Note 1 to entry: Latching alarms are typically discrepancy alarms, where an action does not occur within a specific time. Once the action occurs the alarm stays active until it is reset.

special user who is assigned to monitor and control a portion of a process

Note 1 to entry: “A Member of the operations team who is assigned to monitor and control a portion of the process and is working at the control system’s Console” as defined in EEMUA. In this standard an Operator is a special user. All descriptions that apply to general users also apply to Operators.

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

Note 1 to entry: This concept is further defined in EEMUA.

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

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

Note 1 to entry ”A Shelved Alarm will be removed from the list and will not re-annunciate until un-shelved.” as defined in EEMUA.

act of determining whether an Alarm should not occur

Note 1 to entry: “An Alarm is suppressed when logical criteria are applied to determine that the Alarm should not occur, even though the base Alarm Condition (e.g. Alarm setting exceeded) is present” as defined in EEMUA. In IEC 62682 Suppressed Alarms are also described as being “Suppressed by Design”, in that the system is designed with logic to Suppress an Alarm when certain criteria exist. For example, if a process unit is taken off line then low level alarms are Suppressed for all equipment in the off-line unit.

A&EAlarm & Event (as used for OPC COM)

COM(Microsoft Windows) Component Object Model

DAData Access

MIMEMultipurpose Internet Mail Extensions

UA Unified Architecture

The following tables describe the data types that are used throughout this document. These types are separated into two tables. Base data types defined in 10000-3 are given in Table 1. The base types and data types defined in 10000-4 are given in Table 2.

Table 1 – Parameter types defined in 10000-3

Parameter Type

Argument

BaseDataType

NodeId

LocalizedText

Boolean

ByteString

Double

Duration

String

UInt16

Int32

UtcTime

Table 2 – Parameter types defined in 10000-4

Parameter Type

IntegerId

StatusCode