Alarm ManagementTips, Tricks, Traps

Standards

Certification

Education & Training

Publishing

Conferences & Exhibits

Alarm ManagementTips, Tricks, Traps

ISA Automation Week 2012

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

Agree? Disagree?NO!


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


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?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?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

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


Alarm?Alarm?A quality alarm that is

relevant during plant operation at max rates 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


Forgotten modes of operation

• Most alarm system configurations are optimized for a single process state. (Run)

• Critical modes of operation are compromised. (S/D and Startup)

• Alarm floods are generated on a change of state.

• Operator’s time is monopolized by useless alarms during the most critical operational situations.

With Dynamic Configuration, all modes of operation are handled.

• Dynamic alarming optimally configures alarms for each process operating state.

• Critical modes of operation are optimized.

• Changes of state are managed.

• Operator is only given the information he requires depending on the operational state.


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

TI213

LI010

AC013

PC022


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


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

TI213

LI010

AC013

PC022

LI010PVHI

AC013PVHI

TI213PVLO

PC022PVLO

Heater S/D


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

Time for Group Exercises


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

Point SummaryISA 18.2 Metrics

DynamicRationalization

Static Rationalization

Bad Actor Management

Number of Areas 2 2 2

Points 3641 3327 2552

3rd Qtr 2010 Avg Alarm Rate per 10 min.

1 0.67 0.83 2

4th Qtr 2010 Avg Alarm Rate per 10 min.

1 0.67 1 4.3

3rd Qtr 2010 Peak Alarm Rate per 10 min.

<=10 6.5 211 67

4th Qtr 2010 Peak Alarm Rate per 10 min.

<=10 7 117 159

Blocks in Yellow do not meet ISA 18.2 performance metricsBlocks 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

Standards

Certification

Education & Training

Publishing

Conferences & Exhibits

Questions?

Documents

Alarm ManagementTips, Tricks, Traps