Alarm rationalisation worksheet
The seven questions ISA-18.2 asks of every alarm — the discipline that turns a flood the operator ignores into a short list they act on.
What to record for every alarm.
Rationalisation is not deleting alarms at random — it is answering the same questions for each one and writing the answers down. An alarm that cannot pass these is the alarm causing your floods.
| Field | What to decide |
|---|---|
| Is the alarm necessary? | Does it signal an abnormal condition that needs a specific operator response? If there is no action, it is not an alarm — make it an indication or remove it. |
| Cause | The single condition that triggers it. If one event sets several alarms, that is a rationalisation target, not five separate alarms. |
| Consequence | What happens if the operator does nothing — to safety, environment, equipment, and production. This sizes the priority. |
| Operator response | The specific corrective action. If you cannot write one sentence, the alarm is not actionable and should not exist. |
| Time to respond | How long the operator has between the alarm and the consequence. Short time plus severe consequence drives high priority. |
| Priority | Assigned from consequence severity against time to respond — not from how the vendor shipped it. Most plants need only three or four priorities, heavily weighted to low. |
| Setpoint & class | The trip value with enough margin to act, and the class (e.g. safety, environmental, regulatory) that governs testing and change control. |
Six steps, bad actors first.
- 01
Pull the alarm performance data first — the bad-actor list of the top tags by frequency usually drives most of the load.
- 02
For each alarm, decide whether it is necessary: a real abnormal condition with a defined operator action.
- 03
Record cause, consequence, and the one-sentence operator response. No response means no alarm.
- 04
Estimate time to respond, then assign priority from consequence severity against that time — using a documented priority matrix, not habit.
- 05
Set the trip value with enough margin for the operator to act, and tag the alarm class for change control.
- 06
Capture every decision in the master alarm database so the rationale survives staff changes and audits.
Questions teams ask about rationalisation
What is alarm rationalisation?
It is the ISA-18.2 lifecycle stage where every alarm is reviewed against the alarm philosophy: is it necessary, what is its cause and consequence, what must the operator do, how long do they have, and what priority and class does that justify. The output is a documented master alarm database — the record of why each alarm exists and how it was set.
How do you prioritise alarms?
Priority comes from the consequence of inaction weighed against the time the operator has to respond: severe consequence with little time is high priority; minor consequence with ample time is low. ISA-18.2 expects a documented priority matrix and a distribution heavily weighted to low priority — typically on the order of roughly 80% low, 15% medium, 5% high. A flat distribution where everything is high is itself a symptom of an un-rationalised system.
Where do you start with too many alarms?
With the bad actors. A small number of tags — often the top ten to twenty — usually generate most of the alarm load through chattering, fleeting, or stale-standing alarms. Rationalising and correcting those first delivers the fastest reduction before you work systematically through the rest.