Averaging compressed historian data with a plain arithmetic mean gives the wrong answer, and the reason is that the stored points are not evenly spaced in time. Compression keeps points where the signal turns, so a value that held steady for an hour may be represented by a single point while a busy minute holds ten. A time-weighted average fixes this by weighting each value by how long it applied, which is the only honest way to average unevenly stored data.
Time-Weighted Average in one line: A time-weighted average weights each value by the length of time it was in effect rather than counting every stored point equally, so it equals the area under the trend curve divided by the total time span. It is the correct average for compressed historian data because points are stored unevenly, wherever the signal changed. A plain mean of the stored points, called an event-weighted average, over-counts the busy periods and under-counts the long steady stretches.
Imagine a pressure that sat at a steady value for fifty-nine minutes and then swung wildly for one minute. Compression stores one point for the calm hour and a cluster of points for the turbulent minute, because that is where the signal changed. If you average all the stored points equally, the turbulent minute, with its many points, dominates the result, even though it represented only a small slice of the real time. The plain mean answers a question nobody asked: the average of the stored points, not the average over time.
The correct question is what value the signal held on average across the whole interval, and that requires weighting each value by its duration. A reading that persisted for fifty-nine minutes should count fifty-nine times as heavily as a reading that lasted one minute. Counting stored points equally throws that duration information away, and on compressed data, where the number of points is decoupled from elapsed time, the error can be large.
This is the difference between an event-weighted average, which treats every stored point as one equal event, and a time-weighted average, which respects how long each value applied. Event-weighted averaging is fine when samples are evenly spaced, because then duration and count line up. On compressed historian data they never line up by design, so event-weighted averaging is systematically biased toward whatever the signal was doing when it was changing fastest.
A time-weighted average is really the area under the trend curve divided by the width of the interval. To compute the area, the historian walks the stored points in order and, for each gap between consecutive points, multiplies the value by the time it lasted, summing these contributions across the whole span. Dividing that total area by the total time gives the average height of the curve, which is the time-weighted average by definition.
How the area of each gap is computed depends on the tag's interpolation mode, which is why time-weighted averaging and interpolation are linked. For an interpolated continuous tag, each gap is a trapezoid, because the value sloped from one point to the next, so the contribution uses the average of the two endpoint values. For a stepped state tag, each gap is a rectangle, because the value held flat at the earlier point until it jumped. Using the wrong shape produces a wrong average even when the data is correct.
This trapezoidal, area-based approach is what makes averaging robust to compression. Because the average depends on durations and the shape of the curve rather than on how many points happened to be stored, aggressively compressed data and lightly compressed data of the same signal yield essentially the same time-weighted average. That stability is exactly what you want: the reported average should describe the process, not the compression settings.
Daily and monthly reports in oil and gas lean heavily on averages of exactly the kind of data that defeats a plain mean: pressures, temperatures, and rates recorded at irregular times through compression. An average tubing pressure for the day, a mean separator temperature, or an average injection rate all need to be time-weighted to be defensible, because the equipment spent unequal amounts of time at each value and the report is meant to describe time, not stored events.
Getting this wrong quietly biases operational and regulatory numbers. A well that ran steady most of the day but cycled hard for an hour will report a misleadingly high or low average if the cycling hour's dense points are counted equally with the steady hours. When those averages feed allocation, emissions estimates, or performance tracking, the event-weighted error propagates into figures people make decisions and file reports on.
Merobix computes time-weighted averages over compressed history so a daily or shift report reflects how long the process actually held each value, not how many points the historian happened to store. Because the calculation honours each tag's interpolation mode, continuous measurements are integrated as sloped trapezoids and state tags as flat steps, so the averages a remote operator pulls in the browser stay faithful whether the underlying data was heavily or lightly compressed.
Because compression stores points unevenly in time, keeping many where the signal changes and few where it held steady, so a plain mean over-counts the busy periods and under-counts the calm ones. That answers the average of the stored points rather than the average over time. A time-weighted average weights each value by how long it applied, which is the honest result.
Time-weighted averaging weights each value by its duration, equal to the area under the curve divided by the total time. Event-weighted averaging counts every stored point equally regardless of how long it lasted. The two agree only when samples are evenly spaced; on compressed data, where spacing is irregular by design, event-weighted averages are systematically biased.
Yes. For a continuous interpolated tag each interval between points is a trapezoid, so its contribution uses the average of the two endpoint values, while for a stepped state tag each interval is a rectangle holding the earlier value flat. Using the wrong shape produces a wrong average even from correct data, which is why the tag's mode must be respected in the calculation.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.