Y2.05.1State-based alarm suppressiondesign

An alarm that means nothing in the equipment's current state should be suppressed automatically, not muted

Aliases: state-based alarm suppression · mode-based suppression

What it is

State-based suppression automatically keeps an alarm out of the live channel when it has no meaning in the equipment's current state or operating mode — a pump that has been deliberately shut down, for instance, should not keep generating a "no flow" alarm. This changes the applicability logic itself, i.e. whether a rule should fire at all in the current state, which is different from the other two leaves in this group: those cover how an alarm that has already been decided against is manually hidden, for a bounded period, without quietly becoming a hazard. Suppression here is automatic and tied to state; shelving is a manual, time-bounded action.

Why it happens

An alarm threshold's meaning depends on the process state it is evaluated in: the same "flow below X" condition is abnormal during normal operation but expected during a planned shutdown. If every mode shares one logic set, then every start-up, shutdown, or transition to maintenance mechanically fires a whole batch of entirely predictable alarms the operator does not need to see. A state-based approach first builds a model of which mode the equipment is in, then only lets a rule reach the live channel if both a real consequence and a real required operator action still apply in that mode.

Where it stops holding

This depends on the state signal itself being accurate and timely; a wrong reading, or one that lags behind an actual transition, can suppress a genuinely abnormal condition exactly when it matters most. Event records required by a safety instrumented system or a regulator must not disappear along with the operator alarm just because that alarm was state-suppressed — the record obligation and the decision not to disturb the operator are separate matters. If the suppression mechanism itself fails to behave as designed, that failure must be visible to the operator rather than silently doing nothing.

Applying it

For every alarm subject to state-based suppression, document its applicable modes, the exact entry and exit conditions for suppression, and the default behavior when the state signal is missing, wrong, or delayed, and log every suppression action so it can be audited. Validate by injecting incorrect state signals and delayed transitions, and check whether the system falls back to a visible, conservative default under that uncertainty — for instance, firing an unnecessary alarm rather than silently hiding a real one.

Related

  • Same group: Y2.05.2 Risks of prolonged alarm shelving · Y2.05.3 Visible and reviewable alarm suppression
  • Nearby: Y2.09 Alarm fatigue and false-alarm cost · Y2.08 Alarm-system performance metrics
  • Search terms: state-based alarm suppression · alarm rationalization · mode-dependent alarming

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y2.05.1