Alarm dead-time filtering is the technique of putting two independent timers on an alarm, a delay before it activates and a delay before it clears, and tuning each one separately to suppress a different kind of nuisance. The on-delay makes a condition prove itself by lasting a while before the alarm sets, so momentary transients that cross the threshold and vanish are ignored. The off-delay makes the alarm hold on through brief recoveries before it clears, so a condition that dips in and out around the threshold does not flicker the alarm off and on. The two delays do opposite jobs and are chosen for different reasons, which is why treating them as one setting misses the point. This page focuses on how to tune the on-delay and off-delay together as a deliberate nuisance-reduction technique, with worked timing examples.
Alarm dead-time filtering in one line: Alarm dead-time filtering applies two independent timers to an alarm: an on-delay that the condition must outlast before the alarm activates, and an off-delay that the alarm holds through before it clears. The on-delay ignores brief transients that cross the threshold and vanish, while the off-delay prevents flicker when a condition dips in and out around the limit. Tuning the two separately against the process settling time is a core nuisance-alarm reduction technique.
Dead-time filtering gives an alarm two separate timers, and the key to using it well is understanding that the two do opposite things and answer different questions. The on-delay, the delay-on-activate, sits between the moment the condition first becomes true and the moment the alarm is allowed to set. It asks how long a condition must last before it is worth annunciating, and its job is to swallow transients: a brief spike across the threshold that returns before the on-delay expires never sets the alarm. The off-delay, the delay-on-clear, sits between the moment the condition returns to normal and the moment the alarm is allowed to clear. It asks how long a recovery must last before the alarm believes the problem is really over, and its job is to prevent flicker by holding the alarm on through short dips back to normal.
Because the two delays act on opposite edges, they are tuned for opposite concerns and there is no reason for them to be equal. The on-delay is about not crying wolf: set it long enough to reject the momentary crossings that plague the signal, and a longer on-delay ignores more transient activity but also delays a genuine alarm by that same amount, so it is bounded by how much delay a real event can tolerate. The off-delay is about not flickering: set it long enough that a condition oscillating around the threshold, dipping briefly to normal and back, is seen as one continuous alarm rather than a rapid string of clears and re-sets. Neither delay does the other's job, and choosing them independently is what lets one alarm be both slow to cry wolf and slow to declare victory.
It helps to see why using a single symmetric delay for both would be a compromise. A signal that spikes across the threshold and then oscillates around it during a genuine excursion needs a generous on-delay to ignore the initial spikes but may need a different off-delay to ride through the oscillation without flickering, and forcing the two to the same value means either the on-delay is too short to reject spikes or the off-delay is longer than the situation warrants, keeping the alarm active well past a clean recovery. Independence is the whole value of dead-time filtering: it lets the alarm's behavior on the way up and on the way down be tuned to the actual shape of the signal, which a single delay cannot do.
The reference point for tuning both delays is the process settling time, meaning how long the variable naturally takes to move and stabilize in response to real changes. The on-delay should be set long enough to reject the transients you have observed, which are typically much shorter than a real excursion, but short enough that it is only a small fraction of the time a genuine excursion takes to develop, so the alarm is still timely. If the process settles slowly, real excursions build over a long period, and a longer on-delay costs little because there is ample time before action is needed; if the process is fast, the on-delay must be short so that a real, rapid excursion still annunciates in time to matter. In both cases the on-delay is set relative to the timescales of the transients and the true events, not to a fixed habit.
The off-delay is tuned against the timescale of the oscillation or dipping you are trying to ride through, which is often related to how the variable behaves near the threshold during a real excursion. If a genuine excursion causes the variable to bob across the threshold every few seconds as it settles, the off-delay needs to be at least as long as those dips so the alarm does not clear during them and re-set immediately after, which would produce exactly the flicker the off-delay exists to prevent. But the off-delay should not be so long that the alarm lingers well past a clean, sustained recovery, because that leaves a stale alarm on the summary and can mask a genuine re-excursion, so it is bounded above by how long you are willing to keep the alarm active after the condition truly ends.
A pair of worked timing examples makes the interaction concrete. Suppose a pressure occasionally spikes above its threshold for about a second on valve operations, and a real high-pressure event takes tens of seconds to develop; setting the on-delay to a few seconds cleanly rejects the one-second spikes while barely delaying a real event that takes far longer to matter. Now suppose that during a genuine high-pressure event the pressure oscillates, dipping back below the threshold for two to three seconds at a time before rising again as the loop hunts; an off-delay of several seconds holds the alarm continuously through those dips so the operator sees one steady alarm instead of a stuttering one, and once the pressure stays below the threshold for longer than the off-delay, the alarm clears cleanly. Chosen this way, the on-delay and off-delay are set by different features of the same signal, the spike duration and the dip duration, which is exactly why they are tuned independently.
Seen as a whole, dead-time filtering is one of the most effective nuisance-alarm reduction techniques available during rationalization, because between them the two delays cover the two most common ways an otherwise-valid alarm misbehaves: firing on transients and flickering on recovery. Reaching for delays is often better than the cruder alternative of moving the setpoint, because a delay removes the timing-related nuisance without desensitizing the alarm to real excursions of normal magnitude; the alarm still fires at the right value, it just refuses to react to events that are too brief to matter or to recoveries that are too brief to trust. Recording the chosen on-delay and off-delay in the alarm's rationalization record keeps the filtering deliberate and reviewable rather than a hidden tweak.
The technique is especially valuable in SCADA and cloud-monitoring systems, where alarms are frequently delivered as notifications and where an alarm that sets and clears repeatedly does not merely clutter a screen but can generate a burst of messages to an on-call operator. An alarm that flickers ten times as a remote variable hunts around its threshold could fire ten notifications, or ten pairs of set-and-clear notifications, none of which add information beyond the first. A properly tuned off-delay collapses that flicker into a single sustained alarm, so the operator gets one notification for one episode, and a properly tuned on-delay ensures the initial transients that never mattered never generate a notification at all. This is what keeps a remote notification stream trustworthy rather than something the operator learns to silence.
Tuning both delays well requires seeing the actual signal behavior, which is where a trending platform is essential, because good timer values come from measured spike and dip durations, not from guesses. When a cloud SCADA system such as Merobix records the underlying variable at fine resolution, an engineer can look at exactly how long the nuisance transients last and how long the recovery dips last during real events, then set the on-delay just past the transient duration and the off-delay just past the dip duration. The same trend history validates the result: if real alarms are being delayed too much or flicker is still leaking through, the recorded data shows it and the timers can be adjusted with evidence. Grounding the two delays in observed timing is what turns dead-time filtering from a pair of arbitrary numbers into a targeted, defensible nuisance-reduction measure for each alarm.
The on-delay is the time a condition must remain true before the alarm activates, which lets it ignore brief transients that cross the threshold and vanish. The off-delay is the time the alarm holds on after the condition returns to normal before it clears, which prevents flicker when a condition dips in and out around the limit. They act on opposite edges of the alarm and are tuned for opposite concerns, so there is usually no reason for them to be equal.
Set the on-delay just longer than the duration of the transient spikes you want to reject, but only a small fraction of how long a genuine excursion takes to develop, so real alarms stay timely. Set the off-delay just longer than the brief dips the variable makes back to normal while a real excursion settles, so the alarm rides through them without flickering, but not so long that it lingers after a clean recovery. Both are set from measured spike and dip durations on the trended signal.
Moving the setpoint desensitizes the alarm to real excursions of normal magnitude, whereas dead-time filtering removes only the timing-related nuisance while the alarm still fires at the correct value. The on-delay rejects events too brief to matter and the off-delay prevents flicker on brief recoveries, without changing what value counts as an alarm. This makes delays the better fix when the problem is transients and flicker rather than the setpoint being in the wrong place.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.