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