An alarm limit that is exactly right while a unit is running full and steady can be completely wrong while that same unit is starting up, shutting down, or sitting idle for maintenance. Fixed alarms that ignore this generate torrents of meaningless alerts during every transition. State-based alarming removes that problem by letting the operating state of the equipment decide which alarms are live. This guide explains what state-based alarming is, how it differs from an operator manually shelving alarms, and why designing alarms around process state tames the floods that transitions would otherwise cause.
State-based alarming in one line: State-based alarming, also called mode-based alarming, is an alarm design in which alarms are automatically enabled or disabled according to the current operating state of the equipment, such as running, starting up, shutting down, or under maintenance. Alarms that only make sense in one state are activated in that state and suppressed in the others, so a plant transition does not produce a flood of alarms that are irrelevant to what the equipment is actually doing. Because the process state drives it automatically, it is applied by design rather than by manual operator action.
Most equipment does not have a single normal condition; it has several, one for each way it operates. A pump or a compressor that is running steadily has one set of expected values. The same machine during startup passes through pressures, temperatures, and flows that would be alarm-worthy at steady state but are entirely normal for a machine spooling up. When it is shut down, many of its measurements sit at values that would look like faults if judged against running limits, yet they are exactly right for a stopped machine. A fixed alarm that knows nothing of state will fire constantly during startup and while idle.
State-based alarming makes the alarm configuration aware of these operating states. The system tracks which state a unit is in, often derived from equipment status, permissives, or operator selection, and enables the alarms appropriate to that state while disabling the ones that are not. A low-flow alarm that is essential while running is simply not armed while the unit is stopped, because zero flow in a stopped pump is not a fault. When the unit transitions to running, the running-state alarms arm and the shutdown-state suppressions lift. The alarm set effectively moves with the equipment through its operating cycle.
The key characteristic is that this happens automatically as a designed behaviour, not as something an operator remembers to do. The rules for which alarms belong to which state are worked out in advance during alarm rationalization and built into the configuration. From then on, the transitions handle themselves: the system recognises the change of state and adjusts the active alarm set without anyone intervening. This is what makes it a design technique for whole classes of transition, rather than a reaction to one specific event.
State-based alarming can look similar to suppression or shelving because all of them result in certain alarms not annunciating, but the driver is fundamentally different. Shelving is a manual, operator-initiated action taken against a specific nuisance alarm for a period of time, a deliberate human decision to quiet something that is bothering them right now. Generic suppression likewise is usually a manual or condition-specific act aimed at a particular alarm. In both, a person is deciding, case by case, to silence an alarm they have judged unhelpful at that moment.
State-based alarming, by contrast, is anticipated in the design and driven by the process itself. Nobody has to decide during a startup to silence the dozens of running-state alarms that a startup would trip, because the design already knows that those alarms do not apply in the startup state and disarms them as part of entering that state. The operator is not managing individual nuisances under pressure; the correct alarm set for the situation is presented to them automatically. This removes the burden, and the risk, of relying on a busy operator to suppress the right alarms at the right time.
The distinction matters for safety and auditability. Because state-based suppression is engineered rather than improvised, it is documented, reviewable, and consistent: the same startup always disarms the same defined alarms and re-arms them the same way afterwards. Manual shelving, being ad hoc, carries the standing risk that an alarm is shelved and forgotten, left silenced long after the reason has passed. State-based alarming avoids that failure mode entirely, because the alarms re-arm automatically when the equipment leaves the state, with no reliance on anyone remembering to un-suppress them.
The problem state-based alarming solves is acute in distributed field operations, where equipment is routinely and remotely started, stopped, and cycled. A remote well being brought back online, a compressor cycling on a control loop, or a facility taken down for maintenance each pass through states in which the running alarm set is meaningless. If a fixed alarm configuration governs these assets, every routine start or stop showers the operators, and the on-call phones, with alarms that describe nothing wrong, training people to ignore the alerts that eventually do matter.
On a cloud SCADA platform such as Merobix, the operating state of each remote asset is already visible in the telemetry, which is the input state-based alarming needs. Because the platform knows whether a unit is running, stopped, or in a transition, the alarm and notification logic can be tied to that state, so alarms that only apply while running are simply not raised, and not sent to anyone's phone, while the asset is stopped or starting. A planned shutdown of a remote site can therefore be a quiet event rather than a burst of pointless notifications to on-call staff.
Applying this across a fleet also keeps the meaning of an alarm consistent no matter where it comes from. When state defines which alarms are live, an alarm that does arrive from a remote site carries weight, because it was not suppressed by the current operating state and is therefore genuinely relevant to what that asset is doing. This preserves trust in the notification stream: responders learn that an alarm reaching them during a startup is a real, state-appropriate exception rather than the usual transition noise, which is precisely the confidence a distributed operation needs when nobody is on site to look.
Shelving is a manual, operator-initiated action to silence a specific nuisance alarm for a time, decided case by case under the pressure of the moment. State-based alarming is designed in advance and driven automatically by the equipment's operating state, so the correct alarm set for running, startup, or shutdown is applied without anyone intervening. State-based alarming also re-arms alarms automatically when the state changes, avoiding the risk of a shelved alarm being forgotten.
During startup, pressures, temperatures, and flows pass through values that are perfectly normal for a machine spooling up but would be alarm-worthy at steady state. A fixed alarm limit set for running conditions judges the startup against the wrong benchmark and fires repeatedly. State-based alarming disarms those running-state alarms during startup so the transition is not buried under irrelevant alerts.
The state is usually derived from equipment status signals, permissives, running feedback, or an operator's mode selection, and in distributed operations it is visible directly in the telemetry. The alarm system uses that state to enable the alarms appropriate to it and disable the rest. When the equipment transitions to a new state, the active alarm set changes automatically to match.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.