HMI and Historian Readings Differ: Reconcile Them
An operator reads one number on the live HMI and the historian trend shows a different value for what looks like the same moment. Before anyone concludes the data is wrong, it is worth knowing that the live display and the stored history are produced by different mechanisms and are allowed to differ for legitimate reasons. This page is a symptom-first tree that walks the real causes - compression, timing and aggregation, and a stale display - and helps you decide which source to trust for the question you are asking.
HMI vs Historian Mismatch in one line: When the HMI and historian readings differ, the two are not measuring different things, they are presenting the same data through different mechanisms. The live HMI shows the latest received value; the historian shows stored samples that may be compressed, time-averaged, or aggregated into buckets. Most mismatches are compression thinning the stored points, timestamp or aggregation differences, or a stale HMI showing an old value. Identify which mechanism differs before deciding which source is correct.
First Checks: Are You Comparing the Same Instant?
The most common mismatch is not a mismatch at all - the two views are showing different moments. The live HMI updates to the newest value the instant it arrives, while a historian trend plots samples at their stored timestamps, and a trend zoomed out shows aggregated points rather than raw ones. Confirm you are reading the same instant on both: hover the exact timestamp on the trend and compare it to when the HMI value was captured. A live value that is a few seconds newer than the last stored sample is not a discrepancy, it is just fresher.
Check the quality and freshness of the HMI value itself. A live display that has stopped updating shows an old value that looks current, and comparing that stale number to a still-advancing historian creates an apparent mismatch that is really a frozen display. If the HMI value has a stale or bad quality flag, or if it has not changed while the historian trend clearly has, the display is the problem, not the data. This is the same frozen-client symptom that drives part of the all-tags-flatlined tree, seen from the angle of one value that will not agree with the record.
Look at how far apart the two numbers actually are and in what direction. A small difference is usually compression or timing. A large difference, or the HMI showing a value the historian never recorded at all, suggests either a stale display or that the two are reading different tags or different scaling. Confirm both views point at the same tag with the same engineering units and range, because a duplicated or mis-scaled tag can make two honest values look like a contradiction when they are simply two different points.
Compression, Timing, and Aggregation
Compression is the leading legitimate cause of a trend that does not match the live value. Historians commonly store only samples that differ from the last stored one by more than a deadband, discarding values that fall on a straight line between kept points, which is how deadband compression saves space. The result is that the trend is reconstructed from fewer points than the HMI ever displayed, so a value the operator saw live may not be stored exactly, only implied by interpolation between the points that were kept. The stored trend is faithful within the deadband but is not a sample-for-sample copy of the live feed.
Timing and aggregation cause the next tier of differences. When a trend is viewed over a long window, the historian returns aggregated points - averages, minimums, or maximums over each time bucket - rather than raw samples, so a bucket's plotted value is a summary, not the instantaneous reading the HMI showed. A time-weighted average over a bucket will differ from any single live value inside it, by design. Zooming the trend to raw resolution usually collapses this difference, and it is the first thing to try when a long-window trend disagrees with a live number.
Clock and timestamp differences produce subtler mismatches. If the device, the poll engine, and the historian do not share a synchronized clock, a value can be stored under a slightly different timestamp than the one the HMI associates with it, shifting the trend relative to the live view. This is usually small but it matters when you are correlating events tightly, and it is a reason to keep time synchronization healthy across the chain. A trend that looks shifted in time rather than wrong in value is often a clock problem, not a data problem.
Deciding Which Source to Trust
Choose the source by the question. For what is happening right now - an operator making a control decision - the live HMI value is authoritative, because it is the newest reading and is not thinned by compression or summarized by aggregation. For what happened over time - analysis, reports, correlation of events - the historian is authoritative, because it is the durable record designed for exactly that use, provided you view it at appropriate resolution. Neither is simply right; each is right for its purpose, and confusing the two is the root of most of these disputes.
When the two genuinely cannot be reconciled - the numbers differ by more than compression and timing can explain, and the HMI is confirmed live - suspect a real fault in one path: a stale display, a mis-scaled tag, a duplicated point, or a collection problem. At that point the reconciliation becomes a normal single-tag diagnosis: prove which value matches an independent reference such as a local gauge or a redundant measurement, and fix the path that is wrong. Most mismatches never reach this stage because compression and timing explain them, but the ones that do are real faults worth chasing.
In a cloud SCADA such as Merobix, the live value and the historical trend come from the same collected data and carry the same quality flags, so an engineer can hover a trend point, read its exact timestamp and quality, and compare it against the live value in the same interface. Viewing the trend at raw resolution to strip out aggregation, and checking the timestamp alignment, resolves the great majority of apparent HMI-versus-history disputes without touching the field at all, because the difference is almost always mechanism, not error.
When to Escalate
Escalate to a historian or configuration review when the mismatch survives after you have ruled out timing, aggregation, and a stale display - that is, when the same instant, viewed at raw resolution, genuinely stores a different value than the confirmed-live HMI showed. That points at a collection, scaling, or mapping problem in one path, and someone needs to check the tag configuration and the collector on both sides.
Escalate to time synchronization owners when trends appear consistently shifted in time relative to the live view across many tags, because a systemic clock offset between devices, the poll engine, and the historian is an infrastructure issue, not a per-tag one. In both cases, bring the exact timestamps and values you compared, because a reconciliation dispute is only resolvable with the specific instants in hand rather than a general complaint that the numbers do not match.
Frequently Asked Questions
Why doesn't my historian trend match the live HMI value?
Because the two are produced by different mechanisms showing the same data. The live HMI displays the newest received value, while the historian stores samples that may be compressed to a deadband, summarized into time-bucket averages when viewed over a long window, or timestamped slightly differently. Most mismatches disappear when you compare the exact same instant at raw trend resolution. If a real difference survives that, suspect a stale display, a mis-scaled or duplicated tag, or a collection fault in one of the two paths.
Which should I trust, the HMI or the historian?
It depends on the question. For a live control decision about what is happening right now, trust the HMI, because it shows the newest reading and is not thinned by compression or summarized by aggregation. For analysis of what happened over time, trust the historian, because it is the durable record built for that purpose, viewed at appropriate resolution. Neither is simply more correct; each is authoritative for its own use, and most disputes come from applying one to the other's job.
The trend looks shifted in time compared to the display. What causes that?
A trend that looks correct in value but offset in time usually points at a clock difference between the device, the poll engine, and the historian. If those clocks are not synchronized, a value can be stored under a slightly different timestamp than the one the HMI associates with it, shifting the trend relative to the live view. The value is right, its time label is off. Keeping time synchronization healthy across the collection chain removes this, and a consistent shift across many tags points at a systemic clock offset rather than a per-tag fault.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.