An Alarming Trend in Process Control Systems

Summary

In process automation, an alarm is defined as an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring an operator response. But how many of today’s current alarms meet this definition? Not many.
 
Is the alarm system a useful tool, or a nuisance and a distraction? When there are too many alarms, too many notifications, operators begin to tune them out.
 
Unfortunately, poorly performing alarm systems remain contributing factors in major accidents. Poorly designed and maintained alarm management systems can overwhelm operators with chattering and nuisance alarms under normal conditions, and debilitating alarm floods when abnormal states emerge. When this occurs, it can be difficult for operators to ascertain and act on the most critical alarms, contributing to abnormal situations, lost production, and even serious accidents.
 
If you read reports about industrial accidents that were blamed on alarm systems, quite often it is described as the operator had [many] alarms coming in every minute and the one [critical] alarm that really required attention was buried under all the others.
 
Part of the challenge has been establishing standardized good alarm management practices throughout the industry. However, with organizations like ANSI (American National Standards Institute) and ISA (International Society of Automation) releasing updated guidelines in recent years, along with leading process automation companies incorporating more of a standards-based approach to application development, the focus is increasingly on differentiating alarms that require immediate attention from less urgent notifications, alerts, and messaging.
 

ANSI/ISA 18.2 Standards: Definition of alarm

The ANSI/ISA 18.2 Standard addresses the entire life cycle of alarm management from design and configuration through performance monitoring, auditing, and enforcing for the life of the control application.
 
According to the standard, alarms should be reserved for those events that require an operator response. In other words, if the event does not require that an operator act, it should not trigger an alarm. Alarms should not be used to inform the production staff of normal events.
 
When ISA 18.2 came out, one of the key features that had the biggest impact was their definition of ‘what is an alarm?.’ Basically, what the ISA committee determined was that an alarm should only be used if it requires an operator’s response. And that is probably the number one thing that most processing plants violate. They use alarms for all kinds of notifications, alerts, and reminders.
 
In fact, many engineers essentially design their control system around response to alarms, instead of letting the control system function as it should.
 
My question is, why is the control system relying on the operator to [function]? The control system should be handling that. Rather than create an alarm and rely on the operator to make an adjustment, if it is possible for the control system to make that adjustment, we automate that procedure. That eliminates the generation of the alarm, and the operator doesn’t have to do anything.

Prioritizing alarms

NovaTech’s D/3 Distributed Control System (DCS) is designed to meet or exceed the requirements outlined in the ISA-18.2, albeit with slightly different terminology.
 
In the DCS, alarms are limited to loop tags, or External Point Name (EPN) events. EPN alarms set on-screen indicators to flash and sound an audible indicator. A “silence” key is available to silence the audible indication without acknowledging the alarm.
 
The S18.2 standard also outlines “alarm priority” based on the severity of the alarm. The DCS supports two alarm priorities, critical and non-critical. However, the company goes a step further by assigning a priority number from 0 to 99 to further sort alarms in the alarm summary display.
 
The S18.2 standard also allows for the prioritization of alarms based on classification, which is a grouping of alarms associated with specific equipment, locations, or alarm purpose. The DCS assigns “categories” to each EPN, which meets the intent of alarm classification. The wording of the S18.2 standard suggests that individual alarms can be assigned more than one classification, if appropriate.
 

Dynamic alarming

On the DCS, the alarm priority and alarm category (classification) can also be dynamically changed to meet specific process conditions. Dynamic alarming is defined as the automated altering of alarm setpoints, priorities, and suppression based on the current process state.
 
Without dynamic alarming, for example, an alarm flood can occur during normal equipment shut down. However, most of those alarms are irrelevant to the operator in that situation and obscure more important alarms from the rest of the process.
 
In the example of a low-pressure indication alarm in a batch reactor, if there is no current reaction running the reactor, a low-pressure alarm may not mean much. However, if there is activity in the reactor, then a low-pressure alarm is very significant. With dynamic alarm management, the low-pressure alarm can be disabled if nothing is happening in the reactor.
 
The company approaches dynamic alarming based on the current “state” of the equipment.
 
When brewing beer, for example, the first steps occur in a mash mixer, where various types of milled grains are soaked in warm water. The empty vessel begins in an “empty and ready” state. As the recipe amount of water, enzymes, and other ingredients are loaded, the state changes to “foundation water.” Once the water reaches a precise temperature, various milled grains are added and sparged with some additional water, in the “grain and sparge” state.
 
As we transition from each ‘state’ to the next, we can enable and disable alarms, change alarm limits, and even assign new alarm categories and prioritization based on the current process conditions.

Non-alarm messages

For all other notifications such as alerts, prompts, and notices that do not meet the definition of an alarm, the company utilizes its proprietary SABL (Sequential and Batch Language) program to post messages to the operator console, HMI, and/or the alarm history file.
 
There are five types of messages generated by the DCS: system messages generated by various tasks that identify the health and status of various components and their subsystems; operator logger messages to record process changes made by operators, including changes to setpoints, outputs, tuning parameters and alarm acknowledgement.; process alarm messages when an EPN exceeds a predefined alarm limit; SABL programs can print batch and debug information into the Alarm History Files and Batch History Files; SABL programs can query operators at their consoles to request information or confirmation.
 
Some people refer to messages sent by a SABL program as an ‘alarm,’ but they do not meet the definition of the ISA 18.2 standard for alarms, we do not assign priorities to them, and they are not acknowledgeable.

 Keeping the process under control

Of course, alarm management is just one aspect of a larger overall process control philosophy that begins with robust, predictable control under all process conditions. Properly conceived and executed, alarm management contributes to operator effectiveness and performance, and is essential to efficient operations.
 
If you keep the process under control [with a properly designed DCS], you really don’t generate that many alarms. The goal is to focus on actual operator actionable alarms, per the definition outlined in the ISA 18.2 Standard, and leave the rest to the control system to handle on its own.