A calculated alarm, sometimes called a derived or expression alarm, is an alarm whose trigger is an expression built from more than one tag rather than a single measured point crossing a threshold. Instead of alarming simply because a pressure is high, a calculated alarm can alarm on a combination, such as flow being high at the same time downstream pressure is low, or on a value computed from several inputs, such as an efficiency or a mass balance. This lets the alarm capture a meaningful condition that no single measurement expresses on its own. The power of combining inputs comes with a specific risk: the alarm is only as trustworthy as its worst input, so if any tag feeding the expression goes bad, the calculated alarm can go bad with it. This page explains how calculated alarms work, how quality propagates, and where they are useful.
Calculated alarm in one line: A calculated alarm is an alarm whose trigger is an expression combining several tags or a value computed from them, rather than a single measured point crossing a limit. It lets you alarm on a meaningful condition that no one measurement captures, such as high flow together with low downstream pressure, or a derived efficiency falling below a target. Because it depends on multiple inputs, its quality is only as good as its worst input, so the alarm can become invalid if any feeding tag goes bad.
A conventional alarm has one input and one threshold: this value, above this number. A calculated alarm replaces that single input with an expression, a formula or logical combination of several tags, and alarms based on the result of evaluating it. The expression can be logical, combining conditions with and, or, and comparisons, so that the alarm fires only when a particular pattern of conditions is simultaneously true. It can be arithmetic, computing a new quantity from several measurements and then comparing that computed quantity to a limit. Either way, the alarm is no longer tied to a single sensor reading; it is tied to a relationship or a derived quantity that the individual sensors only imply.
The reason to do this is that many conditions worth alarming on are not visible in any single measurement, only in the relationship between several. High flow by itself might be perfectly normal, and low downstream pressure by itself might be perfectly normal, but the two together can indicate a specific problem such as a break or an open path that neither reading reveals alone. A calculated alarm on the combination fires precisely on that meaningful pattern and stays quiet when only one of the conditions is present, which a pair of independent single-point alarms cannot do as cleanly. The expression encodes the operator's or engineer's understanding of what combination of conditions actually constitutes a problem.
The arithmetic case is just as useful and often more so, because it lets an alarm watch a quantity that is never directly measured. Efficiency, a mass or energy balance, a ratio between two flows, a difference between two temperatures, a rate of change computed from a value over time: these are all derived quantities that carry real diagnostic meaning but exist only as calculations over measured tags. A calculated alarm can compute such a quantity continuously and alarm when it leaves an acceptable range, giving the operator an early, direct indication of a condition, a falling efficiency, a drifting balance, that they would otherwise have to infer by mentally combining several raw readings. This turns a pattern the operator used to have to notice into an alarm the system raises on its own.
The defining risk of a calculated alarm is that its validity depends on the validity of every tag in its expression, and that dependency has to be handled deliberately or the alarm becomes untrustworthy. Each input tag carries not just a value but a quality, an indication of whether that value is currently good, and those qualities have to propagate into the calculated result. If one of the inputs to a calculated alarm has gone bad, its comms dropped, its sensor failed, its value went stale, then the expression is being evaluated on at least one meaningless number, and the result of that evaluation is meaningless too. A calculated alarm that ignores input quality and just crunches whatever numbers are present can fire spuriously on garbage or, worse, stay silent when a real condition exists because a bad input skewed the computation.
Handling this correctly means the calculated alarm must inherit the worst quality among its inputs. If every input is good, the calculation is trustworthy and the alarm behaves normally. If any input is bad, the calculated result should itself be marked bad, and the alarm should reflect that its computation can no longer be trusted rather than pretending the derived value is valid. This is the same principle that governs any derived value assembled from multiple tags: quality flows from the inputs to the output, and a single bad input taints the result. A well-built calculated alarm therefore does not just compute a value; it also tracks the combined quality and refuses to assert a good alarm state when the data underneath it is not sound.
This bad-input sensitivity is the main cost of the extra expressive power, and it grows with the number of inputs. A single-point alarm can only go bad if its one input goes bad, but a calculated alarm with several inputs can be knocked out by any one of them going bad, so it is statistically more exposed to input failures than a simple alarm. That does not make calculated alarms a bad idea; it makes quality handling non-negotiable when you use them. The condition a calculated alarm watches is often important precisely because it is not visible any other way, so the right response to the bad-input risk is to propagate quality carefully and make the alarm's bad-quality state visible, not to avoid calculated alarms and lose the diagnostic value they provide.
Calculated alarms earn their place wherever a meaningful condition lives in a combination or a computed quantity rather than a single reading. Multi-condition logic alarms are common: alarm when a pump is commanded on but flow is absent, alarm when a tank is filling while its outlet valve is supposedly open, alarm when two readings that should agree have diverged. Computed-quantity alarms are equally common: alarm on a falling separation efficiency, on a heat balance that no longer closes, on a ratio drifting out of tolerance, on a computed rate of change that indicates a runaway trend. In each case the calculated alarm surfaces a condition the operator cares about directly, instead of leaving them to spot it by combining several raw trends in their head.
There is a practical discipline that comes with using calculated alarms, which is that the expression itself becomes part of the alarm and has to be understood, documented, and maintained. Unlike a single-point alarm where the meaning is obvious, a calculated alarm's meaning is encoded in a formula that a future engineer has to be able to read and trust, so the expression, its inputs, and its intent belong in the alarm's rationalization record. When an input tag is renamed, rescaled, or decommissioned, every calculated alarm that references it has to be revisited, because a change to an input silently changes what the alarm computes. This maintenance burden is real, and it is the counterpart to the flexibility that expressions provide.
Cloud SCADA platforms are a natural home for calculated alarms because they already aggregate tags from across a site or a fleet and can evaluate expressions over them centrally. When a platform such as Merobix is receiving flow, pressure, level, and status from many points, it can compute derived quantities and multi-condition expressions across those tags and raise a calculated alarm on the result without any additional field hardware, which is especially valuable for conditions that span several remote measurements. Because the platform also tracks the quality of each incoming tag, it is well positioned to propagate that quality into the calculation, so a calculated alarm can be marked bad when any of its remote inputs goes stale or loses comms, rather than firing on or hiding behind a value computed from data that was never sound. Evaluating and quality-checking derived alarms at the aggregation point is what makes them dependable across a distributed operation.
A normal alarm has a single input and a single threshold, firing when one measured value crosses a limit. A calculated alarm replaces that single input with an expression combining several tags, so it can fire on a pattern such as high flow together with low pressure, or on a value computed from several measurements such as an efficiency. This lets it capture a meaningful condition that no single reading expresses, at the cost of depending on multiple inputs rather than one.
If quality is handled correctly, the calculated alarm inherits the worst quality among its inputs, so a single bad input marks the whole calculation bad and the alarm reflects that its result can no longer be trusted. If quality is not propagated, the expression is evaluated on at least one meaningless number, and the alarm can fire spuriously on garbage or stay silent when a real condition exists. This is why careful quality propagation is non-negotiable for calculated alarms.
Use one when the condition worth alarming on lives in a combination of tags or a computed quantity rather than a single measurement, such as two readings that should agree having diverged, a pump commanded on with no flow, or a derived efficiency falling below target. In those cases a calculated alarm surfaces the condition directly instead of leaving the operator to infer it from several raw trends. Just plan to document the expression and propagate input quality, since the alarm depends on every tag it references.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.