Emerson’s Milton Pollard, Darwin Logerot & Vinay Bhasker shared common misconceptions and pitfalls in alarm management and rationalization at the 2019 Emerson Exchange conference.
Vinay opened with addressing the why’s of alarm management. With DCSs, adding alarms is very easy. Often sufficient planning is not properly performed when it comes to alarms. Too many alarms are more harmful than helpful. The 5 keywords for alarm rationalization are abnormal, actionable, consequence, relevant and unique.
Since plant operations are dynamic with many operating states such as startup, running and shutdown, alarm configuration should be relevant for the states that they are in. Alarm configurations are customized to detect the operating states and be set accordingly.
The ISA 18.2 alarm performance standard sets limits for effective performance. Average alarm rate should be less than 1 alarm per 10 minutes. Maximum alarm rate should be less than 10 alarms per 10 minutes. And, the percentage of time alarm rate is outside the limit is less than 1%.
Managing bad acting alarms and performing static rationalization helps but does handle transition states well. Dynamic alarm management provides a much more effective approach to attain the ISA 18.2 performance standard.
Vinay described the AgileOps software to help perform dynamic alarm rationalization. It performs alarm performance monitoring, maintains an online master alarm database, dynamic alarm management, alarm shelving and safety instrumented function trip & interlock monitoring. If AgileOps is used with a DeltaV DCS, the native DeltaV DCS shelving should be disabled.
Common practices include the following:
- Ignore dynamic behavior (changing alarm action by operating state
- Making alarm count reduction or metrics the goal
- “Check the Box” mentality
- No consequences for an alarm
- Alarming normal events or status messages
- Multiple alarms for a single event
- Alarm messages not clear or relevant
- Using alarm settings to trigger interlocks or other automatic actions
- We only need to rationalize tags with alarms
- Only doing bad actors
- Eliminating startup and shutdown from alarm metrics
- Tying PHA/HAZOPS to specific alarms rather than process conditions
- Reluctance to change DCS functionality (selectors/current control configuration)
- Operator ability to change alarms
- Not using external Alarm Management software—extensive programming required for dynamics
Avoiding alarm floods puts producers and manufacturers on the path to safer, more efficient operations. It’s critical to make sure each and every alarm brings visibility to abnormal conditions, is actionable, will result in a consequence if not addressed, is relevant to the situation and unique/non-duplicative to another alarm.
