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