Alarmsare specializations of AcknowledgeableConditionsthat add the concepts of an Activestate and other states like Shelvingstate and Suppressedstate to a Condition. The state model is illustrated in Figure 5. The complete model with all states is defined in 5.8.

image008.png

Figure 5– Alarm state machine model

An Alarmin the Activestate indicates that the situation the Conditionis representing currently exists. When an Alarmis an inactive state it is representing a situation that has returned to a normal state.

Some Alarm subtypes introduce sub-states of the Activestate. For example, an Alarmrepresenting 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 Operatorvia OPC UA Methods. The suppressed state is set internally by the Serverdue to system specific reasons. Alarmsystems typically implement the suppress, out of service and shelve features to help keep Operatorsfrom being overwhelmed during Alarm “storms” by limiting the number of Alarms an Operatorsees on a current Alarm display. This is accomplished by setting the SuppressedOrShelvedflag on second order dependent Alarms and/or Alarms of less severity, leading the Operatorto 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 might 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 Disabledstate in that Alarmsare still fully functional and can be included in Subscription Notificationsto 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 Operatorto take some action before some consequences occur. The consequences may be economic (product is not usable and must be 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 Alarmmodel describes these states, delays and actions.

image009.png

Figure 6– Typical Alarm Timeline example