The dynamic world of alarms

A conversation with Prosys' Darwin Logerot on what does and doesn't work with alarm systems management

By Greg McMillan & Stan Weiner

1 of 2 < 1 | 2 View on one page

Stan: Last month, Nick Sands, co-chair of the ANSI/ISA-18.2-2016, “Management of Alarm Systems for the Process Industry” standard and DuPont’s global alarm management leader, gave us an insightful perspective on what’s really needed. Here we benefit from examples and an accounting of what works and doesn’t work, courtesy of Darwin Logerot, alarm management specialist and senior consulting engineer at ProSys and member of the ISA 18.2 committee.

Greg: What were the results of a recent project?

Darwin: A refinery had 12 consoles with 1,000 standing alarms. In less than the expected project time frame of 1½ years, we were able to reduce the number of alarms to less than 55, exceeding the goal of less than five alarms per console. This reduced the alarm standing summary from five to six pages per console to less than a quarter of a page. Furthermore and most importantly, all of the alarms in the alarm summary were relevant.

Stan: What makes an alarm relevant?

Darwin: A relevant alarm must give notification of the action required by the operator to prevent or correct a detrimental consequence in terms of safety and/or process performance. The alarm must be unique (only one per situation), and the operator must be able to understand what’s needed and have the time to make the correction. When the fix is done, the alarm clears.

We have additional metrics of average alarm rate and peak alarm rate. While metrics are generally useful in providing feedback, there’s a danger from focusing on alarm rates and not on relevance. Rates can be reduced by just deleting alarms. What’s needed is to make sure each and every operator-preventable consequence has one alarm with the right priority and a clear understanding of the correction required. The alarm is only activated when the problem occurs, and clears when the problem is solved. It just so happens that software features and techniques that improve alarm relevance coincidently reduce the number of standing alarms and alarm rates.

Download: A New Look at  Automation Project Execution

Greg: What is the key functionality?

Darwin: Alarm rationalization must be in agreement with ISA18.2 and the customer philosophy. A key question to ask is, “What if the operator does nothing?” If there is no appreciable detrimental consequence, there should be no alarm. In the analysis process, we document causes, consequences and needed operator responses that can be shown on a help screen.

To achieve this in a way consistent with the process requires “dynamic alarms” and more specifically “state based” alarms. Conventional alarm systems tend to have “static alarms.” Industrial process conditions are not static or independent of operating state, especially when there is an impending operator-preventable detrimental consequence. 

Greg: I can appreciate this underlying principle in that my focus throughout my career has been on process dynamics and on incorporating this and other process knowledge, including the cause-and-effect interactions between unit operations and operating states to make control loops smarter.

Darwin: We can detect the operating state to determine what alarms are valid. For example, if the low-flow alarm was only needed to protect the pump and the pump is not running, you turn off the alarm.

1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments