Alarm Systems

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 motors

P - A one second pressure spike may be enough to destroy a piece of equipment.

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.

Walter.

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 alarm conditions.

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 condition.
2. Useless Information - no action required, no actual process problem likely
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 most important.

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....) .

Michael

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 approval.

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.

mk

mk

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.

Walter.