Alarm Rationalization Workshop - Tips, Tricks and Traps

Alarm Management
Tips, Tricks, Traps
ISA Automation Week 2012

Standards
Certification
Education & Training
Publishing
Conferences & Exhibits

Presentation Agenda

• Why Alarm Management?
• Objective of Alarm Management
• Alarm Management Philosophy
• Dynamic Alarming and Rationalization
• Exercises
• Alarm Metrics
• Potential Pitfalls
• Q & A – as we go

Why Alarm Management?

In the Old Days (pneumatic controls), alarms cost money
and hence numbers were limited

With DCS systems, alarms can be configured with a few
keystrokes, cheap and easy, hence many more alarms
configured


Each new advance in control systems technology results in
increasing sophistication & complexity of systems, more
points, more alarmable parameters, and many more
alarms

Information overload, especially during upsets, is the
natural result of excess alarm numbers


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

Why have alarms failed?

The fundamental objective of alarms has been
overwhelmed by the capabilities of the modern
distributed control system design

• Easy, “cost free” alarms
• Increased operator loads

Why have alarms failed?

Acceptance of a single point, static alarm configuration
for all possible operating modes

Logically inconsistent with the obvious fact that there is
no single operating state in a process unit

Objective of Alarm Management

The objective of alarm management is to reduce the
number of alarms annunciated to the operator

NO!
Agree? Disagree?


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

So, What is It About?

It’s about the QUALITY of the alarms


The objective of alarm management is to provide
operators with a consistent and reliable action event
notification interface that supports their efforts to
safely and efficiently operate the process

What is a Quality Alarm?

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


Every alarm should:
• Be clear and relevant to
the operator
• Indicate an abnormal
Alarm
process condition that
has consequences of
?
inaction and defined
response
• Be unique

Normal and Abnormal

Normal - That which is both planned and expected
• Startup/shutdown
• Mode switching
• Equipment swapping
• Other planned operating procedures

Abnormal - That which is unplanned or unexpected
• Emergency shutdown
• Equipment failures
• Upstream problems
• Downstream problems
• Other unplanned process transitions


A quality alarm that is
relevant during plant
operation at max rates
Alarm
may NOT be a quality
alarm during other
?
conditions

How to Achieve Quality Alarms?

To Achieve Consistency
• Review all alarms - Rationalization
• What is alarmed?
• Alarm Priorities, Trip Points, Digital Alarm States

To Achieve Reliability
• Add Dynamic Behavior

Reliability | Dynamic Behavior

Plant operation is not static

Alarm configuration shouldn’t be either


With Dynamic Configuration, all Forgotten modes of operation
modes of operation are handled.
• Dynamic alarming optimally
• Most alarm system configurations
configures alarms for each process
operating state. are optimized for a single process
state. (Run)
• Critical modes of operation are
optimized. • Critical modes of operation are
• Changes of state are managed. compromised. (S/D and Startup)
• Operator is only given the • Alarm floods are generated on a
information he requires depending change of state.
on the operational state. • Operator’s time is monopolized by
useless alarms during the most
critical operational situations.


Dynamic Alarm Management
• Uses key process parameters to determine operating state
for a section of the plant (system)
• Alarm configuration is customized for the detected
operating state
• Alarm floods minimized


Case transition management

• Case logic includes indeterminacy rules and deadbands
to prevent chattering (rapid switches between cases)

• Should not have a large quantity of alarms activated
simultaneously when entering run case – enable alarms
intelligently


Without Dynamic Alarming
• Each alarm is stand alone and does not have knowledge of
current plant status
• Normal and abnormal conditions alarmed

PC022
PVLO

AC013
PVHI
Heater S/D
TI213
PVLO
LI010
PVHI


With Dynamic Alarming
• Change of process state is managed
• Only abnormal conditions alarmed

PC022
PVLO

AC013
PVHI
Heater S/D
TI213
PVLO
LI010
PVHI


Number
of Total
Alarms

Consistency | Alarm Rationalization

Practical steps for implementation

•Assemble Rationalization Team
• Operations
• Process Engineering
• Controls Engineering
• Facilitating Engineer



•Develop Alarm Philosophy
• Start with enterprise or site alarm management standard
• Alarm definition / criteria
• Design principles
• Rationalization procedures
• Metrics / performance monitoring



•Develop Alarm Philosophy
• Develop specific plan based on alarm type – critical variables, SIS,
digital types, etc.
• Finalize priority setting guideline
• Bad PV alarm guidelines
• MOC / continuing improvements
• Repeat and escalating alarms


Setting Priorities

• Usually based on
• Available response time
• Severity of the potential event

• Develop guidelines at start of the project

• EEMUA and ISA provide guidance



• Collect required information
• Dump control system database
• Acquire recent S/D or abnormal event alarm journals and
process data
• Current P&IDs and PFDs
• Operating procedures / troubleshooting guides
• Have process schematics & operator groups available



•Break process units into systems
• A system is a set of process alarms whose process state can
be determined by a set of common logic
• Systems too small - cause unnecessary overhead
• Systems too large - cause lack of flexibility, agility, and
configurability



• Determine the detectable operating states
• Review process knowledge and operating procedures to
determine all modes of operation
• Decide which process readings best indicate each
process state
• Build a logic structure for each of the process states



• Build management lists
• Review every point included in a system
• Which alarm (PV Hi/Lo, All, Bad PV, Dev Hi/Lo)
• Determine alarm priority
• When needed? (Which state, delay desired)
• Document causes, consequences, actions for each alarm



• Causes, Consequences, Actions (CCA)

• For each alarmed parameter, document
CCAs as an aid for the operator
• Make available from the operator
station
• If no consequences, or no operator
actions, an alarm is not needed


Master Alarms Database

• Rationalize alarm and control system settings

• Review trip points, priorities, deadbands

• Propose Revisions

• Capture causes, consequences, and actions

Alarm Rationalization Workshop - Tips, Tricks and Traps


Rationalization Methodologies

•Bad Actor Management- focus is to reduce rates not
evaluate or enable legit alarms
•Static Rationalization – centers on a single state of the
process – the run state
•Dynamic Rationalization – adds the question “when” into
the discussion for each point. Considers all process
states.

Comparison of Methodologies

ISA 18.2 Dynamic Static Bad Actor
Point Summary Metrics Rationalization Rationalization Management
Number of Areas 2 2 2
Points 3641 3327 2552
3rd Qtr 2010
Avg Alarm Rate per 1 0.67 0.83 2
10 min.

4th Qtr 2010
Avg Alarm Rate per 1 0.67 1 4.3
10 min.

3rd Qtr 2010
Peak Alarm Rate per <=10 6.5 211 67
10 min.

4th Qtr 2010
Peak Alarm Rate per <=10 7 117 159
10 min.

Blocks in Yellow do not meet ISA 18.2 performance metrics

Alarm Rationalization

• 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

Alarm Performance Metrics

Typical measures of alarm performance

• Average alarm rate
• Peak alarm rate
• Time in flood (>10 /10 min)
• Number of chattering alarms
• Number of stale alarms
• Annunciated priority distribution


Best not go overboard with alarm metrics

Focus on providing a reliable and consistent interface for the
operator

Effective alarm management is not a numbers game!


What is the solution to pure numbers?

Zero configured alarms


• Numbers can indicate a problem

• Numbers cannot indicate that there is not a problem

Metrics do not replace Alarm System Design

Potential Pitfalls

• Over-reliance on metrics
• “Let’s just handle the bad actors”
• Just minimize configured alarms
• “Check the Box” mentality

Potential Pitfalls

• Ignoring dynamic behavior
• Ignoring case transition management
• Inappropriate point descriptions
• Allowing Operator changes to alarms

Summary

Effective AM will aid operators in safely and efficiently
running the plant
Quality alarms
Detailed rationalization
Incorporate dynamics
AM is not a numbers game
Avoid the pitfalls

Questions?

Standards
Certification
Education & Training
Publishing
Conferences & Exhibits

Alarm Rationalization Workshop - Tips, Tricks and Traps

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to Alarm Rationalization Workshop - Tips, Tricks and Traps (20)

Recently uploaded (20)

Alarm Rationalization Workshop - Tips, Tricks and Traps

Editor's Notes