A historian rarely stores only what it collected. It also stores derived values, calculated tags computed from other tags, and pre-computed rollups such as hourly and daily summaries, all built from the raw data as it arrived. That works cleanly until the raw data changes after the fact, when a gap is backfilled or a bad value is corrected, because then the derived values were computed from information that is now different. Historian data reprocessing is how the system catches those derived values up: it re-runs the affected calculations and rollups over the changed window so everything downstream matches the corrected raw data. This page explains when reprocessing is needed, how the recompute follows the dependencies, and how to trigger it.
Historian data reprocessing in one line: Historian data reprocessing is the act of re-running calculated tags and pre-computed rollups over a time window after the raw data feeding them was backfilled or corrected, so the derived values stay consistent with the new raw data. When late or corrected samples land in a past window, the calculations and summaries that were computed earlier are now stale, and reprocessing recomputes them across the affected range. It can happen automatically when the historian detects late data, or be triggered manually for a specific window and set of tags.
Calculated tags and rollups are computed forward as raw data arrives. An hourly average is calculated once the hour's samples are in; a calculated tag that multiplies flow by a factor is evaluated as each flow sample lands; a daily total is summed from the hours. All of these assume the raw data for their window was complete and correct at the time they were computed. When that assumption breaks, and it often does, the derived values silently become wrong. A collector that was offline for two hours delivers its buffered samples later, filling a gap that the hourly average for those hours had already been computed without. The average is now stale, calculated over fewer points than actually exist.
Corrections cause the same problem. If a bad sensor reading is fixed, or a manually entered value is revised, any calculated tag or rollup that used the old value is now inconsistent with the corrected raw data. The historian faithfully stored the corrected raw value, but the summary that fed a report still reflects the old one, so the report and the raw trend disagree. Without reprocessing, this inconsistency lingers, and it is exactly the kind of discrepancy that erodes trust in the data when someone notices that the daily total does not match the sum of the raw samples.
The scope of the staleness follows the data flow. A change to a raw tag affects every calculated tag that depends on it and every rollup that aggregates it, but only over the window that changed. A backfilled two-hour gap does not require recomputing a whole month; it requires recomputing the derived values for those two hours and any coarser rollups, such as the affected day, that summarize them. Understanding this bounded, dependency-driven scope is what keeps reprocessing efficient rather than a brute-force recomputation of everything.
Reprocessing is essentially a dependency recompute over a window. The historian knows, or is told, which derived tags and rollups depend on the raw tags that changed, and it recomputes them in order from the raw data upward. First it re-evaluates the calculated tags that read the changed raw tags over the affected window, producing corrected derived samples. Then it recomputes the pre-computed aggregates and rollups that summarize those tags for the same window, and if there are tiers of rollups, hours feeding days feeding months, it rolls the change up through each tier so every level agrees with the one below it.
Getting the order right matters, because a rollup computed before its inputs are corrected would just re-enshrine the stale numbers. A sound reprocessing pass therefore respects the dependency graph, refreshing the lowest-level derived values first and only then the summaries built on them. It also has to bound the window correctly at each level: a change within one hour dirties that hour's rollup and the day that contains it, so the recompute walks up the calendar hierarchy from the changed range, expanding the window just enough to cover the coarser buckets that included the changed time.
Because reprocessing writes corrected derived values into past windows, it is a form of controlled rewriting of computed history, and it should preserve provenance the same way any correction does. The corrected derived values replace the stale ones, but a well-run system records that a reprocessing occurred, over what window, and why, so an auditor can see that a report's numbers changed because of a legitimate backfill rather than an unexplained edit. This keeps the corrected data trustworthy and distinguishes a proper reprocessing from tampering.
Some historians detect late or corrected raw data and reprocess automatically, marking the affected derived tags and rollups as dirty and recomputing them in the background. This is convenient for the common case of a collector draining its buffer after a brief outage, since the gap fills and the summaries quietly correct themselves without anyone intervening. When it works, the raw trend and the reports stay in agreement even though the data arrived out of order, which is exactly the behavior a downstream consumer wants.
There are cases where a manual trigger is the right tool. After a large or unusual backfill, a bulk correction of a bad sensor's history, or an import of data from another source, an operator may need to explicitly reprocess a stated window and set of tags to be sure the derived layer was refreshed. Manual reprocessing is also the remedy when someone discovers that a report and the raw data disagree and traces it to a past change that never triggered an automatic recompute. Being able to say recompute these calculated tags and these rollups from this date to that date is a valuable operational control, and it should be safe to re-run, producing the same result each time.
In a SCADA and cloud monitoring pipeline, reprocessing is what keeps the layered data consistent as it moves outward from the field. Remote sites with intermittent links deliver data late as a matter of course, so backfill is routine, and without reprocessing the summaries that a central team relies on would chronically under-report the periods a site was disconnected. Treating reprocessing as a normal, monitored part of the pipeline, automatic where it can be and manually triggerable where it must be, is what ensures that calculated tags, rollups, and the reports built on them always tell the same story as the corrected raw data underneath them.
Reprocessing is needed whenever raw data in a past window changes after the derived values were already computed, which happens when a gap is backfilled with late-arriving samples or when a bad value is corrected. The calculated tags and rollups built from that raw data were computed with the old information and are now stale. Reprocessing recomputes them over the affected window so the derived values match the corrected raw data.
No. Reprocessing is bounded to the window that changed and follows the dependency graph from there. A backfilled two-hour gap requires recomputing the derived values for those hours and the coarser rollups that include them, such as the affected day, not a whole month. The scope expands only as far up the calendar hierarchy as needed to cover the buckets that contained the changed time.
Yes. While many historians reprocess automatically when they detect late or corrected data, you can usually trigger a recompute explicitly for a stated window and set of calculated tags and rollups. This is the right approach after a large backfill, a bulk correction, or an import, and it is the remedy when a report disagrees with the raw data because of a past change that never triggered an automatic recompute. A well-designed reprocessing is safe to re-run and produces the same result each time.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.