Stop alarm floods before they start

An operator who receives ninety alarms in four seconds receives zero alarms. The information is there; the ability to act on it is not.

Alarm floods are almost always a modelling failure rather than a tuning failure, and they are fixable with three mechanisms that most systems already have and most deployments never configure.

Dependency suppression

When a header valve closes, every downstream flow transmitter reads zero and every downstream low-flow alarm activates. All of them are true. Only one is useful.

Dependency suppression lets you declare that the low-flow alarms are children of the valve-closed condition. When the parent is active, the children are suppressed — still evaluated, still logged, not annunciated.

Because QUBIQ alarms attach to namespace nodes and the namespace already encodes the physical hierarchy, the dependency is usually the parent relationship you have already modelled. That is most of the argument for modelling the process rather than the org chart.

Deadbands and delays are different tools

Deadband stops chattering around the threshold. A level alarm at 80% with a 2% deadband clears at 78%, so a level sitting at 80.0 ± 0.3 produces one alarm, not forty.

On-delay stops transients. A pressure that briefly touches the limit during a valve stroke is not an event; requiring the condition to persist for five seconds removes it.

Off-delay stops flapping on clear. Useful when the clear condition is noisier than the alarm condition.

Most floods we see are cured by a deadband alone. It is the single highest-leverage setting in an alarm system and it is very often left at zero.

The rationalisation nobody wants to do

The uncomfortable truth from ISA-18.2: if an alarm has no defined operator response, it is not an alarm. It is a log entry wearing a high-visibility jacket.

Rationalisation means going through every alarm and answering three questions:

1. What should the operator do when this activates?
2. How much time do they have to do it?
3. What happens if they do nothing?

If question 1 has no answer, delete the alarm. It is generating noise that makes the real alarms harder to see.

This is a tedious workshop, and it pays for itself the first time a genuine event is not buried under ninety that did not matter. The usual outcome is that a large fraction of the alarm list turns out to have no defined response at all.

A target worth aiming at

ISA-18.2 suggests roughly 150 alarms per operator per day as manageable, with under 10 during an upset. Measure yours before you tune anything. Most sites are surprised, and the number itself is often enough to get the rationalisation workshop scheduled.