Just wondering what different opinions people have about the following:
In our company we have a couple of different philosophies on alarms.
One option is to put a 1 second delay on all alarms with the feeling that if
the alarm is not up for at least 1 second we can ignore it.
Another option is to seal in every alarm for at least 1 second to ensure
that the HMI picks it up so none are missed. Delays could be placed on
certain alarms if they are a problem.
This really depends on the application:
F - A one second flow spike is normal noise.
L - A one second level spike is a wave. As level increases it will become
more and more frequent until it is continuous.
M - A one second spike on motor status indicates serious abuse of electric
P - A one second pressure spike may be enough to destroy a piece of
T - A one second temperature spike is nonsense.
Z - A one second spike of valve position indicates misadjusted switches.
What I prefer in noisy applications is a first order smoothing filter on the
analog signal. Putting a snubber on a pressure switch has a similar effect.
I agree with Walter, and would like to add that there some systems allow a
definition of alarm level, as well as the use of ladder logic to process
I've also noticed that in some facilities, the alarm system is way over
used. It seems some systems are designed to go off with even minor Some
operators tend to get more use out of the alarm system than others.
In practical terms, the alarms I've seen fall into a few categories:
1. Nuisance alarms - the operator is more concerned with turning off the
(insert kindhearted words here) noise again than they are with the alarm
2. Useless Information - no action required, no actual process problem
3. Useful process information, but not worthy of an alarm - the motor
stopped (after the operator shut it down)
4. Moderate alarm conditions - The tank level is too high
5. Severe alarm conditions - The tank is (or will soon be) missing.
It would be nice if someone would put together a system which understood and
actually used these levels. Many systems have just "warning", and "alarm".
I wish some systems I had gave the opportunity for a "process note", which
didn't require any intervention or acknowledgment.
Consider looking at a system which examines each "alarm" condition, decides
if it is worth worrying about, and then either presents it to the operator
or takes immediate action and notifies (or not) the operator.
The motor spike would shut down the motor and tell you about it.
The pressure spike might shut down the process and those around it, and tell
you about it.
The temperature spike, unless it was sustained or greater than a particular
level would do nothing and wouldn't tell you anything
Other alarms would be prioritized and present the operator with those deemed
It is just frustrating for operators to deal with systems which require
acknowledgements every few minutes for run of the mill process variances or
events. They eventually clip the wires on the horn (must be those rats), or
stuff pennies into the acknowledge button (why, how did that get there....)
I've seen a number of systems where this is true. It's easy to
understand why this is the case. On a DCS system it is extremely easy
to add any number of alarms (hi, lo, hihi, lolo, hi deviation, low
deviation, hi output, lo output). When setting up a system for a new
plant it is not always evident which alarms will be important. It is
probably better to risk adding a nuisance alarm than missing an
important one. Unfortunately once the alarm is in, it is dificult to
take it out. Who wants to take responsability for removing an alarm
that might be important.
It is also fairly easy to adjust alarm priorities based on operating
states of the process. For example if a pump fails, who cares about
the low flow alarm. The biggest obstace to doing this kind of work is
finding a commited and experienced operator and getting management
I think industry is slowly starting to recognize the importance of
functional alarm systems, as there are a number of DCS vendors, and
third parties pushing Alarm Management/Optimization software. Alarm
systems have traditionally been looked at as an operator's tool, but
I think that alarm information can also be extremely useful to
management. Hope I'm not getting too far off topic.
In my illustrious career at Bridgestone/Firestone of 11 years, 98% of
the time an alarm happened, the sensor was the malfunction rather than
the quantity being "measured". After a while, people ignore the
alarms, with human nature being what it is. The BS plant I worked in
at that time, IMO, was chock-full of misapplied, misadjusted, and
generally shitty sensors.
Works well with Allen-Bradley button operators. Others require a
toothpick from the cafeteria, driven in by a suitable weight. Harder
for the tech to undo, especially when broken off level with the
mounting ring. :)
Honeywell is leading a study on alarm management, among other things, call
the ASM (Abnormal Situation Management) Consortium. It's a complex process
that seems to generate a lot of billable hours for Honeywell but the basis
of it is this: Every alarm configured in the system must have a written
operator action associated with it. If a clear operator action cannot be
defined, then the alarm is eliminated as being useless. My personal way of
reducing useless alarms is to force the process engineers to give me the
setpoint for every alarm based on a measured PV. If they can't give me a
number, I eliminate the alarm. Actually there's more to it than that but
it's a starting point.