Emerson’s Tim Olsen presented Best Practices with Alarm Management at the 2025 Ovation Users’ Conference. Tim highlighted the reasons behind effective alarm management and common missteps that are made. Tim opened the presentation by highlighting an ARC Research study showing the causes of unscheduled shutdowns and slowdowns. Operator error accounted for 42%, equipment failure accounted for 36%, and process upset conditions accounted for 22%.
Alarm flooding, chattering alarms, and nuisance alarms significantly contribute to operator errors. Other causes include displays with incorrect content or poor organization, inadequate control room lighting and noise levels, excessive span of operator control, outdated standard operating procedures, and infrequent operator training.
The ANSI/ISA 18.2 alarm management standard defines an alarm flood as exceeding 10 alarms within a 10-minute period. The key is to present quality alarms. These should highlight conditions that are abnormal, actionable, have a consequence, are relevant, and unique.
Abnormal refers to a condition that has a consequence. Actionable refers to a situation where the operator has enough time to take action to prevent the consequence from occurring. It must have a clear, defined response that meets a predetermined threshold. The alarm must be relevant to the current process conditions and be unique.
The ISA 18.2 / IEC 62682 alarm safety encompasses a comprehensive process, including philosophy, identification, rationalization, detailed design, implementation, operation, maintenance, monitoring & assessment, and management of change, which in turn informs identification. Auditing occurs throughout the lifecycle.
These are some common missteps with alarm management.
With a “check the box” mentality, alarm management is often viewed as a top-down requirement. Concentrate on the base goal to provide a reliable and consistent alarm system for the target audience, the operators. If there are no consequences for an alarm, it should be suppressed. An example is a low-level alarm on a sump that is routinely empty. Everyday situations should not be alarmed. Duplication of alarms on an abnormal event can be confusing. It’s best to provide only one alarm for the event. Alarms can be combined using techniques such as min or max value, median value, or average value.
Alarms must be clear and relevant to the operators. They are useless if the operators don’t understand the alarms. Alarms and interlocks exist for different reasons, and generally, it is not a good practice to force both at the same time. This makes it difficult to manage changes to the alarm or suppress it without disabling the interlock. Rationalize tags with alarms, and it is best to include all tags in the control system as candidates for alarming.
ISA 18.2 does not recommend focusing on only the bad actor alarms. They should be considered holistically, not singularly. This process could remove worthwhile alarms, but often fails to address alarm flood conditions. It’s also challenging to sustain long-term, always manually chasing bad actors. Dynamic alarming changes alarm settings based on the process state. Only abnormal conditions should be alarmed.
A really bad idea is to let operators modify alarms, and this practice is strongly discouraged in ISA 18.2. It’s better to focus on solid rationalization principles and use dynamic alarming so the operators don’t see the need to change alarms. A competent facilitator should be used to lead the alarm management lifecycle process.
Tim described how AgileOps can enable performance analytics that display alarm system monitoring and metrics reporting. Some displays include top 10 alarms, chattering and fleeting alarms, related alarms, alarms in the AgileOps database that compare against the alarms in the control system, and static alarming. Static alarming is effective when the process is running normally, but it is not suitable for abnormal operations or changing states, such as shutdowns.
In the run state, the operator can usually safely manage the unit after static rationalization, but in conditions like a shutdown state, an alarm flood will likely occur.
Dynamic management, or state-based alarming, to which it is often referred, is a technique employed to ensure that alarms are annunciated only when they are needed. Dynamics of the process and potential process operating states are evaluated and incorporated into the alarm management design. Dynamic rationalization is an integral part of the overall alarm management process.
It’s essential to determine the process causes, define process measurements and logic to detect a state change, and evaluate alarm conditions for the state. Ask, “When is this alarm really needed?”
Tim shared some project examples where a boiler unit was unexpectedly shut down. Without dynamic alarm management, the site experienced 176 alarms in 10 minutes. After applying dynamic alarm management, they reduced the number of alarms to 14 in 45 minutes.
He closed the presentation by showing how the AgileOps Dynamics application enables alarm configuration changes based on the dynamic logic of the operating state and process conditions. Built-in transition management ensures smooth alarm transitions from one operating state to another.
AgileOps includes advanced shelving capabilities beyond what is offered in the standard control system platform in a module called AgileOps Alarm Shelving. Advanced capabilities include multiple lists for maintenance as well as nuisance alarms. Using this capability, alarms that are active due to malfunctioning instrumentation or equipment can be managed by different work processes than short-term nuisance alarms.
Visit the links above for more information on how to optimize your alarms to enable your operators to perform at their best in abnormal situations or operational state changes.
