Compression throws away most of a historian's incoming samples, so when someone later asks for the value at a specific instant, that exact reading usually was never stored. Linear interpolation is how the historian answers anyway: it finds the two stored points on either side of the requested time and reads a value off the straight line between them. It is the retrieval-side counterpart to compression, and it is where a stored corner turns back into a smooth curve on demand.
Linear Interpolation in one line: Linear interpolation is the method a historian uses at query time to reconstruct a value for a timestamp that was never actually stored. It locates the two compressed points that bracket the requested time and computes the value by weighting them according to how far the requested time sits between their timestamps. This straight-line reconstruction is the natural partner to swinging door compression, which stored only the points needed to keep that line within tolerance of the real signal.
Ask a compressed historian for the value at a particular second and, most of the time, no point was stored at that second, because compression only kept the corners of the signal. Rather than return nothing, the historian finds the last stored point before the requested time and the first stored point after it, and treats the signal as a straight line running between them. The requested value is then simply the height of that line at the requested time.
The calculation is a weighted blend of the two bracketing points. If the requested time sits a quarter of the way from the earlier point to the later one, the result is the earlier value plus a quarter of the difference to the later value; halfway between gives the average of the two; and so on. The closer the requested time is to one stored point, the more that point dominates the answer, which is exactly what a straight-line reconstruction should do.
This is why interpolated retrieval and compression are two halves of the same design. Swinging door compression discarded a point only after proving that the straight line between the surrounding stored points stayed within the compression deviation of it. So when retrieval draws that same straight line and reads a value off it, the reconstructed number is guaranteed to be within the deviation of whatever the real signal was. The store side and the retrieval side agree on the same line.
Linear interpolation is what makes evenly sampled retrieval possible from unevenly stored data. A report or a chart often wants a value every minute or every hour on a clean grid, but the archive holds points at irregular times wherever the signal turned. The historian satisfies the request by interpolating a value at each grid time from the surrounding stored points, handing back a tidy regular series that never actually existed in storage in that form.
The reconstruction is only as good as the compression that fed it and the assumption that the signal was linear between points. For continuous measurements compressed with a sensible deviation, that assumption holds within the known error bound and interpolated retrieval is trustworthy. It breaks down when the tag is not really continuous: interpolating across a gap where the signal was genuinely discontinuous, or across a stepped state tag, invents intermediate values that never occurred, which is why interpolation mode has to be respected at retrieval time too.
There is also a boundary case at the edges of the data. If the requested time falls before the first stored point or after the last, there is no pair to interpolate between, so the historian either returns nothing, holds the nearest value, or flags the result as an extrapolation depending on its configuration. Understanding how a given historian handles these edges matters whenever a query reaches the start or end of an archive, or lands inside a gap where the tag was offline.
Interpolated retrieval is quietly at work behind almost every trend and export a SCADA user sees. When an operator drags a trend to a specific moment and reads a cursor value, when a report pulls a reading at the top of each hour, or when two tags recorded at different times are compared at the same instant, the historian is interpolating stored points to answer. The user experiences smooth, aligned data without ever knowing which points were real and which were reconstructed.
For oil and gas reporting this alignment is essential, because measurements from different instruments and sites rarely share timestamps. Interpolating each tag to a common set of times lets an allocation calculation or a daily report combine flows, pressures, and levels that were never sampled together, producing consistent figures at consistent times. Without interpolation, every cross-tag calculation would stumble on mismatched clocks.
Merobix reconstructs values at requested timestamps from the compressed points it holds, so operators can scrub a trend to any instant, export a clean regular series, and line up tags from different remote sites on the same time grid. Because the interpolation respects each tag's mode, continuous measurements are reconstructed along their slope while state tags hold their last value, keeping the reconstructed data faithful to what the equipment actually did rather than a straight line drawn through a jump.
It finds the two stored points that bracket the requested time and draws a straight line between them, then reads the value off that line at the requested moment. The result is a weighted blend of the two points based on how close the requested time is to each. This is linear interpolation, the retrieval-side counterpart to compression.
For continuous tags compressed with a swinging door style algorithm, yes, because the compression only discarded points that already lay within the deviation of the straight line, so the interpolated value stays within that same known error bound. It is not appropriate across genuine discontinuities or for stepped state tags, where a straight line would invent values that never occurred. Accuracy depends on the signal being truly continuous between the stored points.
If the time falls before the first stored point or after the last, there is no pair to interpolate between, so behaviour depends on the historian: it may return no value, hold the nearest stored value, or extrapolate and flag the result. The same care applies to gaps where a tag was offline. Knowing how your historian handles these edges prevents misreading queries at the start, end, or gaps of an archive.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.