Rationalisation: deciding which alarms deserve to exist

Rationalisation is the process of examining each configured alarm against a documented set of criteria and deciding whether it should exist, at what threshold, with what priority, and what the operator is expected to do about it. It is the core activity of alarm management and it is almost entirely a matter of discipline rather than technology.

It is also slow. A rationalisation session covering a well-instrumented unit will manage somewhere between fifteen and forty alarms an hour with a competent team, and a large plant may have twenty thousand configured alarms. That arithmetic is why most rationalisation efforts stall, and planning around it is the difference between a project that finishes and one that becomes a permanent background activity.

The test each alarm has to pass

The criterion is narrow and it is the whole method. An alarm is justified only if all of the following are true.

Shared routines and timing can improve coordination between operators, engineers and support teams. For a related reference, see interpersonal synchrony.

The wider alarm-management lifecycle is described in the ISA-18 alarm management standards.

• There is an abnormal condition that the alarm detects reliably.
• There is a consequence if the operator does not act — to safety, to the environment, to equipment, or to production.
• There is a specific action the operator can take, and they can take it from where they are.
• There is enough time between the alarm and the consequence for that action to have an effect.

The third and fourth conditions are the ones that eliminate most of what fails. An alarm announcing a condition the operator cannot influence is an indication. An alarm that annunciates thirty seconds before an automatic trip, where the operator cannot realistically intervene, is a notification that something is about to happen — useful in a log, not useful as an interrupt.

What gets documented

The output of rationalisation is not just a configuration change; it is a record — commonly called the master alarm database — that captures the reasoning. For each alarm: the condition, the threshold and why that value, the priority and the basis for it, the consequence of inaction, the expected operator response, the allowable response time, and any state-based conditions under which the alarm should be suppressed.

This record is what makes the alarm system maintainable. Without it, the next engineer to be asked why a threshold is where it is has no answer, and the safest-seeming response — leave it alone, or add another alarm — is what caused the current condition.

It is also the document that supports the operator response procedure. An alarm with a documented expected action can be trained against and audited; an alarm with no documented action is one where each operator has developed their own interpretation.

Who has to be in the room

Rationalisation done by a control engineer alone produces a technically coherent database that does not match how the plant is actually run. The sessions need, at minimum, an experienced operator, a process engineer and a control systems engineer, with maintenance available for instrument questions.

The operator is the most important participant and the one most often omitted, because taking an experienced operator off shift is expensive. Their contribution is specific and irreplaceable: which alarms they currently ignore and why, what they actually do when a given alarm annunciates, and which conditions they would want to know about that the system does not currently tell them.

That last category matters. Rationalisation is not only about removal. Most exercises identify a small number of genuinely useful alarms that do not exist, usually covering conditions that operators currently detect by watching a trend.

Setting the threshold

Thresholds set at round numbers are a reliable indicator that no analysis was done. A high level alarm at eighty percent exists because eighty is a comfortable number, not because eighty is where action becomes necessary.

The analytical basis is the response time. Work backwards: at what point does the condition become a consequence, how long does the operator's corrective action take to have an effect, and how much margin does the process dynamic require. The threshold is the point at which those add up.

For a slow-moving variable in a large vessel, that can be a long way from the trip point. For a fast one, the honest conclusion is sometimes that no alarm is useful because there is no time to act, and the correct answer is an automatic protective function rather than an alarm.

Deadbands and delays

Two settings account for most nuisance repetition and both are routinely left at defaults.

The deadband is how far the measurement must return below the threshold before the alarm clears. Set smaller than the process noise, it produces chattering: an alarm that annunciates and clears repeatedly while the variable sits near the limit. A deadband of a few percent of range is a common starting point, and the correct value is derived from the observed noise on that specific measurement.

The on-delay requires the condition to persist for a defined period before annunciating. This eliminates transient excursions that are not worth an operator's attention. It has to be set against the response time available, and it is the wrong tool where the excursion itself is the hazard.

Both are configuration changes rather than engineering work, and on most plants they alone will remove a large share of alarm volume.

Making the arithmetic survivable

The full-database approach — start at tag one and work through — is thorough and frequently fails, because the effort is front-loaded and the benefit arrives at the end. Several alternatives get results sooner.

Bad-actor rationalisation takes the twenty most frequent alarms and rationalises only those. On most plants this removes a large fraction of the volume within days and creates the credibility to fund the rest.

Unit-by-unit rationalisation completes one operating area fully before moving on, so that one console sees the full benefit and can be used to demonstrate it.

Rationalisation on change treats every future modification as a trigger: any alarm touched for any reason is rationalised at that point. This does not fix the existing database but it stops it getting worse, and over years it converts a large share of it.

In practice a combination works best: bad actors immediately, unit-by-unit for the critical areas, and on-change permanently.

The documentation trap

Rationalisation sessions generate a large volume of documentation and it is easy for the recording to become the bottleneck. Teams that attempt to capture every discussion produce beautiful records slowly.

The pragmatic position is to capture the fields that will be used — threshold, priority, consequence, response, time available — in a structured form, and to keep the discussion notes short. A database with complete structured fields and terse commentary is more useful than one with rich narrative and gaps.

Implementing the decisions

A rationalised database that is not implemented in the control system is an expensive document. The implementation step is frequently delayed because it requires a change window, testing, and operator notification.

Plan it as part of the exercise rather than afterwards. Batch the changes, implement them under the normal management of change process, and — importantly — tell the operators what has changed and why before it happens. Alarms disappearing without explanation undermines confidence in the system as much as the noise did.

Measuring whether it worked

Re-run the benchmark after implementation, over a comparable period. The expected results are a lower average rate, a shorter top-twenty tail, fewer standing alarms and a better flood profile during the next upset.

Where the rate has fallen but the flood profile has not, the remaining problem is usually consequential alarms during a single event, which rationalisation of individual alarms does not address. That requires state-based suppression or dynamic alarming, which is a different technique and a later step.