Alarm Help Text That Survives 02:00: Cause, Consequence, and the Action You Actually Want

The alarm summary says P-204 FAULT. It is 02:10, the line is down, the day-shift engineer is asleep, and the operator has two choices: press reset and see what happens, or call somebody. Both are bad, and both happen because the alarm carries no information beyond the fact that something is unhappy.

Help text is supposed to fix this. Usually it doesn't, because it gets written in a rationalization workshop by people who already know the plant, and it is never read by anyone under pressure. The test I apply is simple: hand the text to an operator who has been on shift for nine hours and see whether they know what to touch first. If they have to ask a follow-up question, the text failed.

Three fields, and one of them is usually missing

ANSI/ISA-18.2 (and its international twin IEC 62682) asks the rationalization step to record cause, consequence, corrective action, and the time available to respond. Nearly every alarm database I have opened has the first three in some form. The fourth — time to respond — is almost always empty, and it is the field that changes operator behaviour most.

"Check downstream valve position" reads very differently when it is followed by "you have about 90 seconds before the relief lifts" versus "this can wait until the end of the batch." Without it, every alarm feels like it needs an immediate answer, which is exactly how you get panicked resets.

So the split I push for:

Field	Example
Alarm label	P-204 Discharge Pressure High
Cause	PT-204 above 7.5 bar for 10 s. Normal running band is 4.8–5.6 bar.
Consequence	Pump trips on high-pressure interlock at 8.2 bar; PSV-204 lifts at 9 bar.
Time to respond	~2 minutes before trip at typical ramp rate.
Operator response	Check XV-208 downstream position, strainer dP, and pump running state. Do not restart until the discharge path is confirmed open.
Escalation	Utilities technician if pressure stays high with valve lineup correct.

None of that belongs in the alarm name. Long alarm names wrap in the banner and push the state indication off the visible part of the summary row — which is the one thing the operator needed to see from across the room.

Write for the equipment, not the tag

Engineers respond to tags. Operators respond to things they can walk up to and look at.

Weak:

LSH_310 active. Check input.

Better:

Day tank high-level switch active. Stop transfer if it is still running. Check inlet valve XV-310 and level transmitter LT-310 before acknowledging.

Keep the tag in the text — troubleshooting needs it, and the maintenance tech reading over the operator's shoulder will want it. Just don't make it the subject of the sentence.

State the trigger rule, including the delay

Operators guess at alarm behaviour constantly, and they guess wrong in a predictable direction: they assume everything latches. If it doesn't, they wait for a state that never comes.

Put the trigger rule in plain terms — threshold and units, delay or debounce, whether it latches, what clears it, and where the condition is evaluated. That last one matters more than people expect. An alarm computed in the SCADA layer from a polled value at 5-second scan has a completely different meaning from the same alarm asserted by the PLC at 10 ms. When the operator says "it flickered", knowing which side generated it tells you whether you are chasing a process oscillation or a scan-rate artefact.

For analog alarms, show the normal operating band next to the limit. High at 85 °C alone is nearly useless; High at 85 °C, normally runs 72–78 °C tells you at a glance whether this is a slow drift or something broke.

For discrete alarms, if the wiring convention is at all confusing — and on retrofits it always is — say whether closed means healthy or faulted. I have watched two experienced operators argue about this in front of a running reactor.

Don't write a button sequence

The most dangerous help text I have seen was also the most confident. It read, in full: Reset at panel, restart pump. No condition, no check, no mention that the pump had tripped on a bearing temperature that was still climbing.

Help text written as an instruction sequence gets followed as an instruction sequence. Prefer verbs that leave the operator in the loop — verify, check, confirm, stop if safe, contact maintenance, follow the local operating procedure. Where a reset or bypass genuinely is the right action, state the condition that must be true first, and say plainly if it needs a permit or a supervisor.

Say when the alarm is hidden

If an alarm is suppressed during startup, CIP, or a grade change, the help text has to say so. Otherwise the absence of an alarm gets read as evidence of a healthy process, and eventually someone builds an operating practice on top of that assumption.

Worth recording: which modes enable the alarm, which suppress it by design, the maximum shelving duration, who is allowed to shelve it, and what gets checked before it comes back into service. ISA-18.2 draws a hard line between shelving (operator-initiated, time-bound) and suppression-by-design (engineered, documented) — if your help text blurs the two, so will your operators.

How this rots

Alarm help text goes stale for boring reasons, and it goes stale silently. The ones I keep finding:

• The threshold was retuned during commissioning; the help text still quotes the design value.
• A PLC tag was reused for different equipment after a project copy, and the help text came along for the ride.
• The escalation path names a team that was reorganised out of existence two years ago.
• The response assumes a bypass valve that only exists on skids 1 and 2.
• The text was lifted from a P&ID note and uses drawing nomenclature the HMI doesn't.
• The alarm is disabled in startup mode; the help text says it is always active.
• The Korean and English variants tell the operator to do different things. This one is worse than having no help text at all.

Treat the alarm database as controlled configuration, versioned and reviewed with an owner and a review date, not as HMI decoration. It changes with the process, not with the screen refresh.

Validate it in the field, not the conference room

Reviewing help text at a desk catches wording. It cannot catch wrong assumptions, because the assumptions are shared by everyone at the desk.

What works: pick the high-priority alarms and the top ten nuisance alarms by frequency, open each one from the real HMI client rather than the engineering export, and walk to the equipment with the text in hand. Check that the valve numbers, panel labels, and local indicators actually read the way the text claims. Then ask an operator — not an engineer — what they would do next, and compare that with the approved procedure.

You will find the mismatches in the first hour. The valve tag on the skid is stencilled differently from the P&ID, the local gauge reads in psi while the alarm is in bar, the "reset pushbutton" is inside a locked panel.

If the text can't be understood while someone is reading it out loud during a shift handover, it is too abstract to be useful during an upset.

What to store

Beyond the message string: alarm ID and source tag, equipment name and area, priority, cause, consequence, time to respond, operator response, return-to-normal condition, shelving rule, reference procedure number, owner, review date, and every language variant the site uses.

Those fields are what make a rationalization review or an audit tractable a year later. They are also the reason the help text survives an HMI rebuild — screens get thrown away, the alarm database usually doesn't.

One caveat on length. Help text competes with the operator's attention during the worst five minutes of their shift. If it runs past a short screenful, they stop opening it, and you are back to P-204 FAULT. Put the long procedure in a linked work instruction and keep the help text down to the condition, the consequence, and the first two things to check.