An alarm limit that is correct while a process is running normally can be nonsense while that process is starting up, shutting down, or offline for maintenance. A low-flow alarm screams the whole time a pump is stopped; a low-pressure alarm floods the operator during every startup until the system comes up to pressure. Mode-based alarm suppression fixes this automatically by teaching the system which alarms are expected to be off-normal in each operating mode and suppressing exactly those, so the operator is not buried in alarms that everyone already knows are coming. The suppression follows the mode by itself, without anyone shelving alarms one at a time.
Mode-Based Alarm Suppression in one line: Mode-based alarm suppression is the automatic hiding of alarms that are irrelevant in the current operating mode, such as startup, shutdown, maintenance, or offline, so operators are not flooded with off-normal readings that are entirely expected in that mode. The system defines the modes, maps which alarms belong to which mode, and suppresses those alarms automatically as the mode changes, rather than relying on an operator to manually shelve each nuisance alarm.
Alarm limits are usually set for one condition: the process running at its normal operating point. That is the right reference for most of an asset's life, but a process spends real time in other states, and in those states the same limits describe an off-normal condition that is completely expected. When a compressor is deliberately shut down, its low-suction-pressure, low-flow, and low-discharge-temperature alarms are all true and all meaningless, because of course they are low, it is off. The limits are not wrong; they are simply answering the wrong question for the current state of the asset.
The consequence is an alarm flood at exactly the moments an operator most needs a clear picture. A startup sequence walks the process up through conditions that trip a cascade of low alarms until each variable comes into range, and a shutdown does the same on the way down. During those transitions the operator is doing careful, deliberate work, and drowning that work in a torrent of predictable alarms is worse than useless: it hides any genuine problem in the noise and trains the operator to ignore the annunciator. The alarms that are supposed to protect the process become an obstacle to running it.
The manual answer, shelving each nuisance alarm by hand as the mode changes, does not scale and is fragile. It relies on the operator remembering to shelve the right alarms at the start of a transition and to unshelve them afterward, during a busy sequence when attention is scarce, and a forgotten unshelve leaves a real alarm silently disabled long after the mode has passed. What is needed is not per-alarm handling by a human but a rule that knows, for each mode, which alarms are expected and suppresses precisely those, automatically, appearing and disappearing as the mode does.
Mode-based suppression begins by defining the operating modes an asset actually has and giving the system a way to know which mode it is currently in. Typical modes are running, starting up, shutting down, in maintenance, and offline, and the current mode is derived from real signals, a run status, an equipment permissive, a maintenance flag set by an operator, or a sequence step from a controller. The mode is a first-class piece of state that the alarm system can read, not a vague notion in the operator's head, which is what lets the suppression logic act on it deterministically.
With modes defined, each alarm is mapped to the modes in which it is meaningful or, equivalently, the modes in which it should be suppressed. The low-flow alarm on a pump is meaningful only when the pump is supposed to be running, so it is suppressed in the stopped, maintenance, and offline modes. A startup-specific alarm is suppressed everywhere except during startup. This mapping is the design content of the scheme, and it is worth doing deliberately, because it encodes the operational knowledge of which off-normal readings are expected in which state, turning that knowledge into automatic behavior instead of tribal memory.
The key distinction from manual shelving is that this is state-driven and automatic, not a per-alarm human action taken in the moment. Once the mapping exists, the operator does not decide which alarms to hide; the system suppresses the mapped alarms whenever the asset is in the relevant mode and restores them the instant the mode changes back. There is no risk of forgetting to unshelve, because nothing was shelved by hand in the first place, the suppression is a property of the mode. That automatic, self-reversing behavior is what makes mode-based suppression reliable in a way that leaning on operators to shelve and unshelve can never be.
The transitions between modes are where mode-based suppression proves its worth, because transitions are when both the expected off-normals and the operator's need for a clear board peak at the same time. During a controlled startup, the scheme suppresses the alarms known to be off-normal until the process reaches operating conditions, then lifts the suppression as the asset settles into its running mode, so the operator sees only genuine deviations from the expected startup path rather than the entire predictable cascade. The same logic runs a shutdown in reverse, keeping the annunciator quiet through a maneuver that would otherwise bury it.
In a cloud SCADA platform such as Merobix, mode-based suppression keeps remote and unmanned assets from generating storms of meaningless alarms whenever they cycle through their operating states. A remote pump station that starts and stops on demand, or a well that is taken offline for maintenance, would otherwise fire the same expected low alarms every cycle, filling notification queues and desensitizing whoever is on call. Tying the suppression to the asset's mode means those cycles pass quietly, and a notification that does get through is far more likely to represent something that genuinely deserves attention, which is exactly what an operator watching many remote sites needs.
Critically, mode-based suppression narrows what is hidden without going blind, and that boundary is what separates it from crude alarm silencing. Only the alarms mapped as expected in the current mode are suppressed; every other alarm remains fully active, so a real, unexpected problem that occurs during a shutdown or while an asset is offline still gets through. Suppressing the predictable off-normals of a mode is not the same as muting the asset, and preserving that distinction is the whole point. The operator gets a quiet board during expected transitions and full protection against the unexpected at all times, rather than trading one for the other.
Manual shelving is an operator hiding individual alarms by hand, usually to quiet a nuisance for a while, and it depends on someone remembering to unshelve them later. Mode-based suppression is automatic and state-driven: the system knows which alarms are expected in each operating mode and suppresses exactly those whenever the asset is in that mode, restoring them the moment the mode changes. Nothing was hidden by a human, so nothing can be forgotten and left disabled.
Only the alarms mapped as expected in the current mode are suppressed; every alarm not on that mode's list stays fully active. So a genuine, unexpected problem during a shutdown or while an asset is offline still gets through, because it was never part of the expected off-normals for that mode. The scheme narrows what is hidden to the predictable readings of a mode rather than muting the asset, which is what keeps it safe.
The mode is derived from real signals rather than guessed. A run status, an equipment permissive, a maintenance flag an operator sets, or a sequence step from a controller can each indicate the current mode, and the alarm system reads that as a defined piece of state. Because the mode is explicit and machine-readable, the suppression logic can act on it deterministically, suppressing the mapped alarms and restoring them automatically as the mode changes.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.