Some of the most useful numbers in a historian were never measured by any instrument. An efficiency, a unit conversion, a running total, a gas-to-oil ratio - these are computed from other tags. A calculated tag is a historian point whose value is produced by an equation rather than a sensor. This guide explains how calculated tags work, when they evaluate, and the tricky problem of what happens to them when the source data they depend on is corrected or backfilled after the fact.
Calculated Tags in one line: A calculated tag, also called a derived or analysis tag, is a historian point whose value is computed from an expression over one or more other tags rather than read from a device. It evaluates on a schedule or on demand - producing conversions, ratios, efficiencies, and totals - and stores its results like any other tag, which makes stale source data and backfills a recalculation challenge.
A calculated tag is defined by an expression that references other tags. A simple one converts units - say pressure from one scale to another - or applies a linear correction. More involved ones combine several inputs: a compressor efficiency from suction and discharge conditions, a gas-to-oil ratio from separate gas and oil flow tags, a mass rate from a volumetric flow and a density. The historian evaluates the expression, pulling the current or historical values of the referenced tags, and stores the result as the calculated tag's value at that timestamp.
Evaluation happens in one of two modes. A scheduled calculation runs on a fixed cadence - every minute, every hour, at the top of each gas day - and writes a stored value each time, building a real archived history the same way a scanned tag would. An on-demand calculation is evaluated only when someone queries the tag, computing the result from the source tags at that moment and not necessarily storing it. Scheduled calculations give a durable trend you can trend and aggregate; on-demand ones stay perfectly consistent with their inputs but exist only when asked for.
Because a calculated tag reads other tags, it inherits their timing and quality. If a source tag has a gap or a bad-quality value at the evaluation time, the calculation has to decide what to do - propagate bad quality to the result, skip the evaluation, or substitute a last known value. A well-designed calculated tag carries the worst quality of its inputs forward, so a result computed from suspect data is itself marked suspect rather than presented as trustworthy.
The hardest issue with scheduled calculated tags is what happens when the source data changes after the calculation already ran. Suppose an hourly efficiency was computed and stored, and then hours later a comms outage clears and the underlying flow and pressure tags are backfilled with the real readings for that period. The stored efficiency was computed from incomplete or missing data and is now wrong, but it is sitting in the archive as if it were correct.
Resolving this requires recalculation: re-evaluating the calculated tag over the time range whose source data changed, and overwriting the previously stored results. Historians that take derived data seriously provide a way to trigger this, either automatically when a backfill touches a source tag or manually over a chosen interval. Without it, every corrected outage leaves a trail of stale computed values that quietly disagree with the raw data they were supposedly derived from.
This is exactly why calculated tags and backfill have to be thought about together. A raw tag can be backfilled cleanly, but any calculated tag downstream of it is only as current as its last evaluation. The same reasoning applies to a corrected manual value or an edited lab result - anything that changes an input to a calculation invalidates the results that already consumed it, and a complete data pipeline recomputes rather than leaving the contradiction in place.
In oil and gas monitoring, calculated tags turn raw telemetry into the numbers operators actually manage by. A wellpad reports individual pressures and flows, but the engineer wants gas-to-oil ratio, specific gravity, corrected volumes, and unit runtime - all derived. Computing these as calculated tags in the historian means they are archived, trendable, and comparable across sites, instead of being re-derived by hand every time someone opens a report.
A cloud SCADA platform is well suited to this because the calculation runs centrally, where every source tag from every site already lands. A single consistent definition of, say, corrected flow can be applied uniformly, rather than each site's controller computing it slightly differently. And when a remote site's link recovers and backfills its raw tags, the platform is the natural place to recompute the affected calculated tags so the derived numbers catch up with the corrected reality.
Merobix treats derived values as first-class historian points that live alongside the raw telemetry. Calculations evaluate on schedule to build a durable trend, carry the quality of their weakest input, and can be recomputed over a range when backfilled or corrected source data lands - so an efficiency or a ratio in a Merobix trend stays honest to the raw data underneath it.
A raw scanned tag holds values read directly from a device by a collector. A calculated tag holds values produced by an expression over one or more other tags - a conversion, ratio, efficiency, or total - so no instrument ever measured it. The calculated tag depends entirely on its source tags, which means it inherits their quality and has to be re-evaluated whenever those sources change.
The previously stored calculated values become stale, because they were computed from incomplete or missing source data. To fix this the historian must recalculate the tag over the affected time range and overwrite the old results. Systems that handle derived data well trigger this recomputation when a backfill touches a source tag; without it, corrected outages leave stored calculations that silently disagree with the raw data.
It depends on how the tag is defined. A scheduled calculated tag evaluates on a fixed cadence and stores each result, building an archived trend you can aggregate. An on-demand calculated tag is evaluated only when queried and may not be stored, so it always matches its current inputs but has no independent history. Scheduled calculations are common when the derived value needs to be trended or reported; on-demand ones suit values that must always reflect the latest source data.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.