A deviation alarm and an absolute alarm answer two different questions about the same measured variable. An absolute alarm asks whether the value has crossed a fixed threshold, a specific number that does not move, so it fires whenever the variable is simply too high or too low regardless of what the process is trying to do. A deviation alarm asks whether the value has strayed too far from its setpoint, so its trip point moves with the setpoint and it fires when the process fails to track a target that may itself be changing. Choosing between them is a real design decision, not a preference, because the wrong choice can either nuisance during normal setpoint changes or, more dangerously, stay silent while the process drifts toward a genuine physical limit. This page compares the two and gives a guide for which to use where.
Deviation vs absolute alarm in one line: An absolute alarm trips when a variable crosses a fixed value that never moves, catching the variable being too high or too low in absolute terms. A deviation alarm trips when the variable strays too far from its setpoint, so its trip point moves with the setpoint and it catches the process failing to track its target. Use absolute alarms for safety limits and physical constraints and deviation alarms for loops whose setpoints change often, but watch that a deviation alarm can mask a genuine absolute-limit excursion.
An absolute alarm is the familiar kind, a threshold pinned to a specific value in engineering units that stays put no matter what the process is doing. A high absolute alarm at a given pressure fires whenever the pressure exceeds that value, full stop, whether the operator meant to run there or not. Its virtue is that it is anchored to reality: the number represents a real limit, a pressure the vessel should not exceed, a temperature the product cannot survive, a level the tank cannot hold, and the alarm defends that limit unconditionally. Because it does not move, an absolute alarm always means the same thing, and it always fires when the variable reaches the value the design decided was too far, which is exactly what you want for protecting a fixed physical or safety constraint.
A deviation alarm is defined relative to the loop's setpoint rather than to a fixed number. It trips when the difference between the measured value and the setpoint, the control error, grows larger than an allowed amount, in one or both directions. What makes it distinctive is that its effective trip point moves as the setpoint moves: if the setpoint is raised, the deviation alarm's high and low trip values slide up with it, because the alarm cares about how far the process is from wherever the setpoint currently sits, not about any fixed value. This makes a deviation alarm a monitor of control performance. It is essentially asking whether the loop is doing its job of keeping the variable near its target, and it fires when the process is failing to track.
The consequence of this difference is that the two alarms detect fundamentally different failures. An absolute alarm detects the variable reaching a specific dangerous or unacceptable value; it does not care why or whether the setpoint moved. A deviation alarm detects the variable and its setpoint pulling apart; it does not care what absolute value they are at, only that they disagree by too much. A loop could be sitting exactly on a very high setpoint, well-controlled, with zero deviation and no deviation alarm, while an absolute high alarm is screaming because the setpoint itself is at a value the absolute limit forbids. Conversely a loop could have a large deviation, triggering the deviation alarm, while the absolute value is nowhere near any fixed limit. They are watching for different things.
The guiding principle is to use absolute alarms for limits that are about the value itself and deviation alarms for situations that are about tracking a target. Anything that is a safety limit, an equipment rating, or a physical constraint should be an absolute alarm, because those limits do not care about the setpoint; a vessel's maximum pressure is dangerous at that pressure no matter what the loop was aiming for, so it must be defended by a fixed threshold that cannot slide out from under it. Tying such protection to a moving setpoint would be a serious error, because raising the setpoint would raise the alarm and let the variable climb toward the physical limit without ever tripping. Fixed constraints demand fixed alarms.
Deviation alarms come into their own on loops whose setpoints change frequently and where the operational concern is that the process should follow the setpoint. Consider a temperature loop that is ramped through different targets during a batch, or a loop whose setpoint is driven by another controller in a cascade. An absolute alarm on such a variable is awkward, because any fixed threshold either nuisances when the setpoint is legitimately in one part of its range or fails to protect when it is in another. A deviation alarm sidesteps this by moving with the setpoint, so it stays quiet as long as the loop tracks its target through all the setpoint changes and fires only when the process falls behind, which is the actual condition of concern for a tracking loop.
In many real designs the answer is both, layered so each covers what the other cannot. The absolute alarms sit at the fixed physical and safety limits, guaranteeing the variable is defended against genuinely dangerous values regardless of setpoint, while a deviation alarm rides along to catch poor control performance, the process failing to track, within the safe operating range. Used together this way, the deviation alarm gives an early, setpoint-aware indication that control is degrading, and the absolute alarms stand as the fixed backstops that fire if the variable ever reaches a value that is unacceptable in its own right. The decision is therefore less often deviation or absolute than it is which of them, or both, and at what values, for this particular variable.
The most important pitfall with deviation alarms is that, used alone, they can mask a genuine absolute-limit excursion. Because a deviation alarm only cares about the gap between the value and the setpoint, a variable that is tracking its setpoint perfectly produces no deviation alarm even if that setpoint has been placed at, or driven to, a value that is itself dangerous. If someone sets or ramps the setpoint into unsafe territory, the loop dutifully follows it, the deviation stays near zero, and a deviation alarm never fires, even as the actual variable crosses a value that an absolute alarm would have caught immediately. Relying on deviation alarming without absolute backstops leaves the process exposed exactly when the setpoint itself is the problem.
This is precisely why safety and physical limits are never entrusted to deviation alarms alone. The masking is not a rare edge case; it is the direct consequence of what a deviation alarm measures, and it applies whenever the setpoint can reach or approach a real limit. The standard remedy is the layered approach: let the deviation alarm watch control performance, but always keep absolute alarms guarding the fixed limits underneath it, so that no matter where the setpoint goes, the variable reaching an unacceptable value trips a fixed alarm that the setpoint cannot move. An absolute alarm cannot be fooled by a moving target, which is exactly the property you need for a hard limit.
In SCADA and cloud-monitoring practice, where many loops across many sites are alarmed and their setpoints may be changed remotely, being deliberate about alarm type is especially important, because a remote setpoint change can quietly shift what a deviation alarm is effectively watching. A platform that can host both kinds of alarm lets a designer put absolute alarms on the fixed limits and deviation alarms on the tracking behavior, and trending both the value and its setpoint together makes the relationship visible. A cloud SCADA system such as Merobix that records the measured value alongside the setpoint lets an operator see whether an alarm reflects a real absolute excursion or merely a control deviation, and it makes the masking risk auditable, because a reviewer can confirm that every variable with a moving setpoint still has fixed absolute alarms defending its genuine limits rather than relying on deviation alone.
Use a deviation alarm on loops whose setpoints change frequently and where the concern is that the process should track its target, such as a temperature ramped through a batch or a cascaded loop. Its trip point moves with the setpoint, so it stays quiet through legitimate setpoint changes and fires only when the loop fails to follow. Use an absolute alarm instead for safety limits, equipment ratings, and physical constraints, where the concern is the value itself regardless of setpoint.
Yes, and this is its main pitfall. Because a deviation alarm only watches the gap between the value and its setpoint, a loop that tracks its setpoint perfectly produces no deviation alarm even if that setpoint has been driven to a value that is itself unsafe. The variable can cross a real physical limit with near-zero deviation and no deviation alarm, which is why safety and physical limits should always be guarded by absolute alarms that a moving setpoint cannot slide out of the way.
Yes, and layering both is common and often the right answer. The absolute alarms sit at the fixed safety and physical limits, defending the variable against dangerous values no matter where the setpoint is, while a deviation alarm rides along inside the safe range to catch degrading control performance early. Used together, the deviation alarm gives a setpoint-aware early warning of poor tracking and the absolute alarms remain the fixed backstops for genuinely unacceptable values.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.