common misconceptions and pitfalls in alarm management
DESCRIPTION
Common misconceptions and pitfalls in alarm managmentTRANSCRIPT
Standards
Certification
Education & Training
Publishing
Conferences & Exhibits
Common Misconceptions and Pitfalls in Alarm
Management
By Darwin Logerot, P.E.
ProSys, Inc.
Presentation Overview
• Why Alarm Management?– Objective– Definition of an alarm
• Common Pitfalls and Misconceptions
2
Why Alarm Management?
With DCS systems, alarms can be configured with a few keystrokes, cheap and easy
Proper consideration is seldom given to alarm configuration during initial design
Hence, many more alarms configured than needed
Information overload, especially during upsets, is the natural result of excess alarm numbers
3
Why Alarm Management?
In a number of industrial incidents, alarm floods were identified as a significant contributing cause to the incident…
As found by EEMUA in 1999 and CSB
The connection of alarm floods to incidents has been well known for over 12 years with very little progress made in industry
4
NO!
5
Objective of Alarm Management
The objective of alarm management is to reduce the number of alarms annunciated to the operator
Agree? Disagree?
6
Objective of Alarm Management
The objective of alarm management is to reduce the number of alarms annunciated to the operator
NO!
Although reduction in annunciated alarm count will almost always be a result of a well-conceived and executed AM
project, this is NOT the primary objective
7
So, What is It About?
It’s about the QUALITY of the alarms
What is a Quality Alarm?
• An annunciated abnormal process condition to which the operator can and must take corrective action in order to return the process to normal and safe operation
Alarm?
8
What is a Quality Alarm?
Alarm?
Every alarm should:
• Be clear and relevant to the operator
• Indicate an abnormal process condition that has consequences of inaction and defined response
• Be unique
9
What is a Quality Alarm?
Alarm?
Every alarm should:
• Be clear and relevant to the operator
• Indicate an abnormal process condition that has consequences of inaction and defined response
• Be unique
10
Misconceptions and Pitfalls Summary
• Making alarm count reduction 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
11
Misconceptions and Pitfalls Summary
• Using alarm settings to trigger interlocks or other automatic actions
• We only need to rationalize tags with alarms
• Only doing bad actors
• Ignoring dynamic behavior
• Eliminating start-up and shutdown from alarm metrics
• Over-reliance on metrics
12
“Check the Box” Mentality
• Too often, alarm management is seen as a top down requirement.
• It’s easy to just go through the motions
• It’s easy to rush the project
• Concentrate on the base goal to provide a reliable and consistent alarm system
• Target audience for AM is the operator, not upper management!
13
No Consequences for an Alarm
• Too often, alarms configured for conditions which have no consequences if ignored
• Examples– High flow where flow is controlled by cascade from level– Low temperature alarms on heater tube skin– Low level in a sump that is routinely empty
14
Alarming Normal EventsUsing Alarms as Status Messages
• Normal means planned and expected. Alarming normal events means alerting the operator that
“the control system is working just fine!”
• Examples– One pump not running where two pumps are installed– Sump pump starting / stopping from level signal– Alarming board operator actions– Change of state alarms– Stack damper open when heater switches to natural draft– Alarming every step of a sequence controller
15
Multiple Alarms for One Event
• Best to only provide one alarm for any given abnormal event
• Exception, if there are two transmitters in a critical service
• Example – Shutdown systems– High/Low measurement (at shutdown point)– First out alarm– Shutdown alarm– Command to close shutdown valve– Shutdown valve closed
16
Alarm Messages Not Clear or Relevant to Operator
• If the operator does not understand the alarm message, the alarm will be useless
16E20-2 LSR AIR COOLER • This description was used for six different points
16E18 BTMS EXCHANGER BYPASS • Operators in that plant don’t speak the equip number language
17
Alarm Messages Not Clear or Relevant to Operator
HDR PNL 17LP3N-1B-C• Operators have no clue what this means
Naptha Stripper (16-V-3) Overhead Pressure PT-3032 Maintenance Bypass
18
Triggering Interlocks from Alarms
• Alarms and interlocks exist for different reasons
• Not generally a good practice to force both at same setting
• This ties the AM Team’s hands
• Can’t change the alarm without changing the interlock
• Suppressing the alarm can disable the interlock
19
Only Rationalize Tags with Alarms
• Approach sometimes used to minimize the project scope (cost)
• Optimum alarm configuration can be masked
• Best to include all tags in the control system as candidates for alarming
20
Only Do Bad Actors
• Not Recommended by ISA 18.2
• Alarms considered singularly, not holistically
• The process can remove worthwhile process alarms
• When does it stop???
• Never really gets anywhere to solve alarm floods
21
Ignoring Dynamic Behavior
Plant operation is not static
Alarm configuration shouldn’t be either
22
Ignoring Dynamic Behavior
• Rationalizing only the expected run condition seldom adequately addresses alarm floods
• Dynamic or state-based alarming addresses identified operating modes
• Modifies alarm configuration accordingly
23
TI213
LI010
AC013
PC022
Dynamic Alarming
Without Dynamic Alarming – Each alarm is stand alone and does not have knowledge
of current plant status– Normal and abnormal conditions alarmed
LI010PVHI
AC013PVHI
TI213PVLO
PC022PVLO
Heater S/D
24
Dynamic Alarming
With Dynamic Alarming– Change of process state is managed– Only abnormal conditions alarmed
TI213
LI010
AC013
PC022
LI010PVHI
AC013PVHI
TI213PVLO
PC022PVLO
Heater S/D
25
26
Ignoring Dynamic Behavior
ASM Consortium finding:• Study of 37 consoles / 90 months of
data overall• Static Rationalization – “peak alarm
rate is not closely correlated with the degree of rationalization”
Zapata and Andow – HUG 2008 – Highlights from the ASM Consortium
Eliminate Startups and Shutdowns from Alarm Metric Calculations
• Edits actual data to conceal floods during startup and shutdown
• Keeps management in the dark
• Eliminates potential investment to fix problem
• Doesn’t help the operator
27
Over-Reliance on Metrics
Typical metrics
• Average alarm rate
• Peak alarm rate
• Time in flood (>10 /10 min)
• No. of chattering alarms
• Number of stale alarms
ISA Recommended value
< 1 per 10 min
< 10 per 10 min
< 1%
0
< 5
28
Over-Reliance on Metrics
• Best not go overboard with alarm metrics
• Focus on providing a reliable and consistent interface for the operator
• Numbers will take care of themselves
Effective alarm management is not a numbers game!
29
Over Reliance on Metrics
• Numbers can indicate a problem
• Numbers cannot indicate that there is not a problem
Metrics do not replace Alarm System Design
30
Over-Reliance on Metrics
• What is the solution to pure numbers?
Zero configured alarms
31
Summary
• Remember the Goal - AM is not a numbers game
• Operator is the target audience
• Do more than check the box
• Review all tags
• Include dynamic behavior
• Don’t go overboard on metrics
32
Summary
Five alarm keywords
• Abnormal
• Consequences
• Actions
• Relevant
• Unique
33
Standards
Certification
Education & Training
Publishing
Conferences & Exhibits
Questions ?
225-291-9591 x225
www.prosys.comSales @prosys.com