Why Alarm Acknowledge, Latch, and Reset Must Stay Separate Signals
One shared bit for acknowledge and reset is how alarms vanish while the fault is live. Separating active, latch, ack, return-to-normal and reset.
Latch, reset, and acknowledgement are different signals
An operator hits Acknowledge, the red banner clears, the screen goes quiet — and the conveyor is still tripped, still blocked, still waiting on a reset nobody pressed. Nine times out of ten the cause is the same: one bit was made to mean acknowledge and reset, so the ack silently cleared the latch. The alarm condition, the latched memory, the operator acknowledgement, and the reset command are four separate signals, and the moment any two of them share a bit you get this class of failure.
ISA-18.2 (and EEMUA 191 before it) models this as a state machine for a reason — Normal, Unacknowledged, Acknowledged, and Return-to-Normal-Unacknowledged are distinct states precisely because acknowledgement and return-to-normal are independent axes. You don't have to implement the full standard, but the alarm should be able to sit in "returned to normal but still unacknowledged" without collapsing to Normal.
A typical path looks like this:
- A process condition becomes abnormal.
- The alarm active bit turns on.
- The alarm may be latched so it stays visible after the input clears.
- The operator acknowledges that the alarm was seen.
- The process condition returns to normal.
- A reset clears the latch if the reset permissive is satisfied.
- The alarm record keeps the active, acknowledge, return-to-normal, and reset timestamps.
Do not use acknowledgement as a hidden reset. An operator can acknowledge an alarm while the fault is still physically present. If acknowledgement clears the alarm banner, the screen may look healthy while the machine is still blocked.
Define the alarm state model before building screens
Write the state model in plain language before configuring the alarm server or PLC logic.
| State item | Meaning | Typical source |
|---|---|---|
| Active | The abnormal condition is true right now. | PLC comparison, safety relay, device diagnostic |
| Latched | The alarm is remembered until a reset rule clears it. | PLC logic or alarm system setting |
| Acknowledged | An operator or supervisor confirmed awareness. | HMI/SCADA alarm server |
| Returned to normal | The abnormal condition cleared. | Alarm server event derived from active bit |
| Reset requested | Someone pressed reset or a sequence requested reset. | HMI command, PLC command, maintenance action |
For critical equipment trips, latching usually belongs close to the control logic. For advisory alarms, alarm-server latching may be enough. The important part is that the project decides deliberately, not after operators complain that alarms disappear too quickly.
Choose where the latch lives
There are two common places to latch an alarm.
PLC or controller latch
Use this when the latch affects machine recovery, sequence permissives, or safety-related operator action. Examples include motor overload trips, emergency-stop chain faults, burner trips, hydraulic pressure faults, or robot cell interlock faults.
Field checks:
- Power cycle behavior is defined.
- The latch survives communication loss if that is required.
- Reset is blocked while the active condition is still true.
- Maintenance bypasses do not clear the latch silently.
- The HMI shows the same latch state that the sequence uses.
SCADA alarm-server latch
Use this when the main need is visibility and event history. Examples include short communication dropouts, high process deviations, or instrument diagnostic alarms that should stay in the alarm list until seen.
Field checks:
- The alarm server records active, acknowledge, and return-to-normal events.
- Alarm summary filters do not hide unacknowledged returned alarms.
- Redundant servers handle latch state consistently after failover.
- Historical reports can show how long the alarm was active, not just how long it stayed in the banner.
Reset should have a permissive
A reset button should not be a magic eraser. It should have clear conditions.
Common reset permissives include:
- The active fault input is off.
- The related equipment is stopped or in a safe state.
- No automatic start command is pending.
- Local maintenance mode is not blocking remote reset.
- Required field device feedback has returned.
- The operator has the required role if the reset is high consequence.
Show the blocked reason near the reset button. A greyed-out button without explanation creates repeated clicking and nuisance maintenance calls.
One implementation detail that bites people: make the reset a level command latched in the PLC for a fixed window, not a bare momentary pulse from the HMI. A single-scan HMI pulse crossing a 500 ms OPC update or a slow gateway gets swallowed, and the operator swears the reset "doesn't work." I hold the reset request true for a couple of PLC scans (or ~500 ms) and let the controller consume it, rather than trusting one round-trip through the SCADA layer.
Example HMI text is better when it names the reason:
| Poor display | Better display |
|---|---|
RESET DISABLED | Reset blocked: discharge pressure still high |
FAULT | Drive fault active. Reset after drive ready feedback returns. |
NOT READY | Reset blocked: guard door input is open |
Acknowledge is evidence, not repair
Acknowledgement should answer one question: who saw the alarm, and when?
For each alarm class, decide whether acknowledgement is required before reset, after reset, or independent of reset. There is no universal answer.
Examples:
- A compressor trip may require the fault to clear and the alarm to be acknowledged before restart.
- A tank high-high alarm may remain latched until the level drops below a reset threshold, even if acknowledged.
- A communication alarm may return to normal automatically but remain unacknowledged in the list until an operator reviews it.
Avoid global acknowledge buttons that clear too much context. If a global acknowledge is allowed, log it clearly and keep unreturned active alarms visible.
Handle return-to-normal carefully
Return-to-normal is not the same as reset. It only means the active condition is no longer true.
Watch for these cases:
- A vibration alarm clears because the sensor failed low.
- A pressure alarm clears because the transmitter went bad quality.
- A motor overload active bit clears after power loss, but the starter still requires a local reset.
- A network alarm clears after reconnect, but buffered data is missing.
If quality is available, include it in the alarm condition. An analog high alarm should not quietly become normal when the input quality is bad. Use a separate bad-quality alarm or a quality-aware alarm expression.
Commissioning tests that catch confusion
Test the alarm with a small state table, not only by forcing one bit.
| Test | Expected result |
|---|---|
| Active turns on | Alarm appears as active and unacknowledged. |
| Operator acknowledges while still active | Alarm remains active, acknowledgement timestamp is recorded. |
| Active clears before acknowledgement | Alarm becomes returned-to-normal but still unacknowledged if policy requires review. |
| Reset pressed while active | Latch does not clear; blocked reason is visible. |
| Reset pressed after active clears | Latch clears; reset event is recorded. |
| HMI reconnects after alarm | Alarm state matches controller and alarm server history. |
During FAT, capture screenshots of the banner, detail view, and event log for each step. During SAT, repeat at least one test through the real field device, not only through software simulation.
Common failure modes
- Ack bit is wired to reset logic, so alarms vanish while the fault is still active.
- The PLC latch clears on warm restart, but the alarm server still shows old active state.
- Reset command is momentary and missed because the scan, gateway, or OPC update rate is slow.
- The alarm list hides returned-to-normal unacknowledged alarms, so short trips are never reviewed.
- Multiple alarms share one reset bit, causing unrelated faults to clear together.
- Alarm text says "reset required" but does not identify which device or interlock is blocking reset.
Four lines per latched alarm
For every latched alarm, write down four things before anyone touches the HMI: what sets it, what keeps it latched, what allows reset, and what the operator must see while it is blocked. It fits on one row of a spreadsheet. Skip it and the commissioning team learns the alarm's behavior by tripping over it — usually during SAT, usually with the customer watching.