When a historian compresses a tag, it keeps only selected points and later draws a straight line between them to represent everything in between. Reconstruction error is the honest measure of how much that drawn line can differ from what the signal actually did. It is the number that tells you the worst-case cost of compression, and it is what lets you verify, after the fact, that a compressed tag is still accurate enough to trust for reports and analysis. This page explains what reconstruction error is, why it bounds the worst-case reporting error a compressed tag can introduce, and how to audit a tag by replaying its raw data against the archived values.
Compression reconstruction error in one line: Compression reconstruction error is the maximum difference between the interpolated line a historian draws between its stored points and the actual raw signal at any moment in between. It bounds the worst-case error that compression can introduce into any value read back from the archive, so it sets an upper limit on how far a report or calculation drawn from the historian can be wrong because of compression. You audit it by replaying captured raw data against the archived points.
A compressing historian does not store a continuous signal; it stores a sparse set of points chosen because the value moved enough between them to matter. To answer a query for a time that falls between two stored points, the historian interpolates, usually by drawing a straight line from one stored point to the next and reading the value off that line. Reconstruction error is the difference between that interpolated value and the value the raw signal actually held at that instant. Because the interpolation is a simplification of whatever the signal really did between the stored points, there is always some gap, and reconstruction error quantifies the largest such gap over a period.
The reason to focus on the maximum, rather than an average, is that the worst case is what governs whether the compressed data can mislead. An average error can look reassuringly small even when a brief but sharp excursion was flattened out and misrepresented by a large amount at one moment. For a tag used in reporting or in any calculation where a single moment can matter, the meaningful question is how far off the reconstruction could ever be, not how far off it is on average. Reconstruction error, taken as the maximum deviation, answers exactly that question and is the honest figure to hold a compressed tag to.
It is worth connecting reconstruction error back to the deviation limit that produced it, because the two are closely related but not the same. The deviation limit controls when a new point is stored, and a well-designed swinging-door compression keeps the reconstruction within the deviation limit by construction, so in principle the error should not exceed the limit. Reconstruction error is the after-the-fact verification that this actually held for real data, which matters because instrument behaviour, timing, and edge cases can produce surprises that the nominal limit alone does not guarantee. Measuring the error is how you confirm the promise the limit was supposed to make.
Everything read from a historian for a time between stored points is a reconstruction, which means the reconstruction error propagates directly into anything computed from that data. A daily average, a totalized volume, a peak value, or a compliance figure drawn from a compressed tag inherits the reconstruction error as an inherent uncertainty, because the underlying values it was built from could each be off by up to the reconstruction error. Knowing the maximum reconstruction error therefore lets you state an upper bound on how far a reported number could be wrong purely because of compression, separate from any instrument or process uncertainty.
This bounding property is what makes reconstruction error the right metric for anyone who has to defend the numbers a historian produces. If a tag's reconstruction error is comfortably smaller than the tolerance a report requires, then compression cannot be the thing that pushes that report out of tolerance, and you can say so with confidence. If the reconstruction error is comparable to or larger than the reporting tolerance, then compression is a live risk to the accuracy of the report, and the tag needs a tighter deviation limit. The error turns a vague worry about lossy compression into a concrete comparison against a required accuracy.
The distinction matters most for measurements where accuracy has consequences, such as those feeding custody transfer, environmental reporting, or performance calculations. For those tags, a small reconstruction error is not a nicety but a requirement, and it justifies a tight deviation limit even at the cost of storing more points, because the alternative is a report whose accuracy cannot be guaranteed. For a purely indicative utility signal, a larger reconstruction error is perfectly acceptable, which is why the tolerable error, and therefore the appropriate compression, is a per-tag decision driven by what the data is used for.
To verify reconstruction error you need the raw signal to compare against, which means capturing the tag at high resolution before or alongside compression, or logging it uncompressed for an audit period. With that raw record in hand, the audit is straightforward in principle: take the archived, compressed points for the same period, reconstruct the interpolated values at every raw sample time, and measure the difference at each. The largest of those differences is the observed reconstruction error, and comparing it to the tag's tolerance tells you immediately whether the compression is fit for purpose. Doing this on a representative sample of tags gives real evidence about compression quality rather than assumptions.
This kind of audit is valuable precisely because compression can degrade quietly. A tag whose deviation limit was set generously years ago may be flattening excursions that no one notices, because the compressed trend looks perfectly smooth and plausible on its own. Only by replaying the raw signal against the archive does the flattening become visible as a reconstruction error that exceeds what the tag should tolerate. Periodic audits, especially on measurements that feed important reports, are how you catch over-compression before it undermines a number that someone relies on.
In a SCADA and cloud monitoring context, this audit discipline extends across many sites where no one is watching each tag directly. A remote flow or pressure measurement from a distant site could be over-compressed for a long time without anyone realizing, because the only view most people ever see is the already-compressed trend. A platform such as Merobix can retain high-resolution data for verification and compare archived values against the raw signal so that reconstruction error becomes a checkable quality metric rather than an unexamined assumption. Treating reconstruction accuracy as something you audit, rather than something you hope for, is what keeps a large historian's numbers defensible when they are used for reporting, billing, or performance decisions.
The deviation limit controls when the historian stores a new point, while reconstruction error is the actual measured gap between the interpolated line between stored points and the real signal. A well-designed compression keeps the reconstruction within the deviation limit by construction, so in principle the error should not exceed the limit. Reconstruction error is the after-the-fact verification that this actually held for real data, catching any surprises the nominal limit alone does not guarantee.
Because the worst case is what determines whether the compressed data can mislead. An average error can look small even when a brief, sharp excursion was flattened and misrepresented by a large amount at one moment. For tags used in reporting or in any calculation where a single moment can matter, the meaningful question is how far off the reconstruction could ever be, which is exactly what the maximum deviation captures.
Capture the tag's raw signal at high resolution for an audit period, then take the archived compressed points for the same period, reconstruct the interpolated values at every raw sample time, and measure the difference at each. The largest difference is the observed reconstruction error, and comparing it to the tag's tolerance shows whether the compression is fit for purpose. Doing this reveals quiet over-compression that a smooth-looking compressed trend would otherwise hide.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.