TiPS TechDoc - White Paper

A Practical Approach to Alarm Management

Part One: Crawling Your Way into Alarm Management

Steve Apple: Sales Director, TiPS, Incorporated

I've heard it dozens of times - perhaps a hundred. "Alarm Rationalization just doesn't work" (or "didn't for us"). "Yeah, we
tried that alarm management stuff and it didn't do what it was supposed to, so now we're looking into other things like APC
and predictive alarming." As someone who is supposed to make his living off of alarm management, every time I heard
something like this, I did a double-take, but I asked enough questions to start understanding why.

A lot of papers have been published about rationalization - each professing to relieve the confusion and to have "the
answer" (I guess it's a good thing everybody did not jump on the advice of the first one.). Interestingly, one cause of the
confusion seems to be deliberate obfuscation by vendors who hope to instill a sense of fear. Apparently, they want to create
a desperate need for their assistance in attempting to resolve the fearsome issue of alarm management. Another reason for
the confusion is the myriad of conflicting and convoluted definitions of the terms surrounding alarm management, and the
prevailing assumptions made by those who try to make sense of the rhetoric.

The traditional approach to alarm rationalization assumes that if an alarm system is properly designed, then it should
perform properly. That means that you assign only alarms that MATTER - or have a defined operator action. You design
those alarms to be observant of process timing, safety issues, environmental consideration, maintenance, and other potential
costs or risks associated with each alarm. To accomplish a traditional rationalization, you download the current tag and alarm
configuration from the control system, take it into a back room, and beat it up. This is very similar to a HAZOPS study, and
entails the same type of committee - formed of all concerned parties.

So. How about a paradigm shift? Alarm management is NOT rocket science. Alarm management and rationalization of
alarms is not complex. It requires no proprietary algorithms or special education. It is structured application of basic
operations skills. The reason alarms have become a problem is because we never stopped to ask, "Why?" Why do we need
to add this alarm? Why here? Why set this way? Why don't you react to this alarm? Why is it so active? Why does it stay on
for two days? Why do we need so many alarms in the configuration? Is there a shortcoming or problem somewhere else
creating the need for this alarm? (hint, hint)

Most of the information you need to build a successful alarm management effort is contained in your head, in recollection
and application of basic engineering processes, and available technical articles and guidelines including those from EEMUA,
the ASM Consortium, and ISA. ANYBODY WHO CAN CREATE AN ALARM OR CHANGE AN ALARM SETTING CAN
RATIONALIZE AN ALARM. In fact, they are doing so each time they take an action. Wow - That means my operators should
be able to do it… shazaam.

So - you might ask - how can your ordinary, run of the mill, operations type dude make my alarm system run better? In this
paper, I will address a method of approaching alarm rationalization that will curl the hair of most alarm management purists.
In fact, I may lose my keys to the alarm management washroom. Problem is that it works, and it can be used successfully
with the right software packages by almost any organization.

-1-
Traditional Alarm Rationalization
As pointed out, traditional alarm rationalization has been viewed as an approach that most nearly resembled a HAZOPS
analysis on a unit-by-unit basis around the plant. All that was necessary to perform the rationalization was to download the
current configuration data, call together a team of your favorite engineers from the plant, and sit in a room for several weeks
as you hashed out the RATIONALE for each alarm on each tag. There were rules of thumb, but for the most part, it required
a pretty good knowledge of the unit, how it was designed to operate, and how it actually operates. Of course, you needed a
good philosophy to get started, and post-rationalization, you needed a good management of change program to sustain the
results.

I do not advocate that this approach is wrong, it's just very costly and demanding, and often leads to irrational reduction of
alarms just for the sake of reduction. Too few alarms is worse than too many. And, without naming names, some
companies have adopted alarm reduction methodologies that I would not necessarily agree with. Furthermore, this approach
prompts a company to seek outside assistance to offset the workload demand. The problem with outsourcing this type of
activity is loss of ownership. An alarm system design is under dynamic stress. If not monitored and managed properly it will
get out of hand, as demonstrated by the interest in alarm management to begin with.

Recall outsourced optimization. There was a time in the early 90's when optimization became a big word, and there were
those who would come visit you and optimize your plant. It ran fine for a few weeks, then began to degrade as the dynamics
of the operation slowly crept outside the boundaries of the optimization models. The alarm system is subject to those same
dynamics, and outsourced rationalizations suffer the same degradation over time. Six weeks after you eat it, you're hungry
again.

Another reason plants choose to outsource alarm rationalization is because it "is not rocket science." As a result, it is
also not very interesting to the engineering mind. There are no big challenges. If you do it, you don't really learn anything new
(actually, you do, but it's not exciting), or get to play with fancy new algorithms, and you don't receive any accolades for
making new production targets (actually you do, but it is rarely credited to better alarms). So, it is an issue that is not - on its
surface - appealing to engineers. It is accounting, bookkeeping, data tracking. Engineers hate accounting - the very courses
we avoided in school. Boring! Engineers would rather move on to the next advanced controller project, so when it comes to
alarms, we'd prefer to just sign a PO and put it behind us.

Traditional rationalization was the brainchild of the ASM Consortium and the refining and petrochemical community. In
those types of operations, it can be argued that every unit deserves a HAZOPS-style rationalization, as there is such a unit
inter-dependence that downtime in ANY unit could be disastrous to operations. That "knock-on" effect increased the risk that
petrochemical and refinery plants assumed. Therefore, this was the initial line of thinking among those to whom alarm
rationalization showed the greatest value, and who entered the game in its earliest stages because of their glaring need.

The largest drawback of the HAZOPS-style rationalization is the "manpower bump". See the graph below as an illustration
of the required manpower to accomplish a complete rationalization. The difficulty is that this is a one-time manpower demand
that will not repeat unless you have other projects over which you can deploy the additional work force. If so, you might just
hire the personnel to do the alarm management project, and retain them on staff. Few operations have this luxury.

-2-
Traditional Alarm Rationalization (continued)

Alarm Management Investment

So, it was attractive to think that you could just bring in an outside firm, and they would do a one-off project for you. They'd
clean the system up, and things would be fine from that point onward. Problem is that if you don't have a maintenance
program in effect the situation will trend right back to where it started. (i.e. the tail of the investment curve shown above
actually returned to $0 - as no continued investment was placed in the system). And the next time around it will be just as
boring. And still expensive.

So, how do you go about rationalizing an alarm system at a lower cost and without involving a disinterested engineering
staff? Several months back, we issued a short paper on a risk-based approach to alarm management. We did not expound
greatly on the details of this approach, just that risk should be considered before you jump into rationalization with both feet
and your money and your time.

-3-
Why do I rationalize?
Let's examine the reasons for your need to rationalize. It always gets down to the fact that you have more alarms than an
operator, or group of operators can deal with in a given amount of time. Therefore, your goal is to reduce the alarms that are
bothering your operators but still retain those that are important.

If you strike the right balance from an alarm system design standpoint, then any additional loading means you have too
few operators. Given staff reductions in the past few years, this is quite possible. At that point, the only answer lies in hiring
more operators, or finding other operating efficiencies that can help the current staff to deal with the prevailing load. For more
on this, I recommend a visit to www.mycontrolroom.com. There is a wealth of information on that site to help you in this situation.

Your goal then is to reduce the alarms that you know are bothersome. How do you do that?

Start with Your Data

The first place to start is with an analysis of your alarm history. You should find out HOW alarms are interfering with normal
operations. This is often referred to as "bad actor analysis" or "nuisance analysis". A review of the EEMUA 191 document, will
give you many methods and ideas for reviewing your data. While your exact target levels may differ from their
recommendations, the methods are valid and transferable.

You will need a minimum of 60-90 days of data to begin to address any alarm problems that have a statistical relevance.
However, many problems are so glaring that they can be seen shortly after system installation.

Immediately upon examining their data, most people can find a handful of things that simply need to be fixed. Fix those
things. We continually have clients who clean up 50+% of their alarm problem by fixing a handful of alarms. Now - here's the
secret - just keep doing this. Keep crawling. New things will pop up, and you will discover and fix them as they occur.

Each time you fix an alarm, you should record for posterity (and auditing purposes) what was done to it, and the logic
behind its change. In other words - do a complete rationalization on that particular alarm so that its design fits with its
purpose. Establish a proper RATIONALE for its existence (or non-existence if that is the case). Pay particular attention to
setting its priority correctly, as this will pay off in the future. If you discover that the proper alarm settings for a point are "it
depends", then this particular alarm may be a candidate for dynamic alarm handling, and that should be noted within the
alarm documentation for future reference which we can discuss in a later paper.

Immediately upon reducing some of the noise in your system, you will be considered a local hero. It's surprising how much
noise can be removed by just a little effort. The problem here is that this does not resolve your problems from an ideal
standpoint. Yes, if you keep doing this long enough you can potentially get to the point where you have seen every alarm
activate, and secured its rationale within a management of change (MOC) documentation procedure.

-4-
Start with Your Data (continued)
Note that this does add a small amount of work load, but if performed entirely within the operations arena, then the work
returns the investment through reduced operator loading. It is essentially a work-for-work trade, with the added bonus that
the reduction in operator loading makes for a safer plant, more efficient operations, fewer shut-downs, etc. Note that I am not
advocating that the work load is lessened - though others have claimed it can be, and I do not doubt their claims. This is just
not a value I am personally trying to obtain or claim for this effort. See the graph below to witness the difference in overall
loading accomplished by using this approach. My point is that the "bump" in this curve is now balanced by an equivalent
reduction in manpower demand via operator loading. Many simply repeat this process, and consider their alarm management
needs as being met. Although that is not ideal from a RISK standpoint it does have the statistical potential of servicing the
needs of an under-staffed plant.

Reducing the Alarm Management Investment

-5-
Start with Your Data (continued)
See the graph below of what one person did by simply tracking alarm frequency and dumping the numbers to a
spreadsheet. This is not our recommended approach, but the point is that he had great success using what he had available
(numbers are total alarms per day across several units).

Per Day Alarm Count Reduction

-6-
Consider Formal Rationalization Exercises
Somewhere in this process, you will be learning the PHILOSOPHY behind determining the rationale for these alarms. At
this point - if you haven't already - you should begin to record this philosophy into a formal document. If you do not, then all
you have achieved will be lost the very next time somebody questions the alarm. Share this document with others. It should
be closely guarded, but evergreen.

If you need assistance in this area, I would recommend you visit www.d-roth.com for experts in the area of helping you to
get a reasonable philosophy document, and also to better understand what alarm management is all about, and to start down
the formal path. D-RoTH are experts in helping your team to get on a common communication ground about what alarm
management is all about. Communication commonality in alarm design philosophy offers an excellent basis on which to
begin a plant-wide or corporate alarm management effort. It is important that all parties are speaking the same language, and
accessing the same buzz-word dictionary.

The Risk of Stopping at Nuisance Alarms

If you follow these recommendations, you have successfully begun to resolve nuisance alarms around your plant. What
you have not done is to drastically reduce your risk from unforeseen events. Over time, as alarm activations occur (and
perhaps incidents?), you have the statistical possibility of eliminating alarm related risk if every potentially active alarm rears
its head to be scrutinized and rationalized in the aforementioned fashion. However, there is a better way to go about
balancing the alarm system in a way that considers both the risk, and the cost of doing so. Now that is the kind of project that
can get an engineer's interest.

Stay tuned for part two of this series where we discuss Rationalization Based on Need and Risk.

-7-