How to Set a Historian Backfill Policy Before Late Data Rewrites Your Reports

Tuesday's production report said 41,200 units. Somebody reopened it on Thursday and it said 43,700. The report engine was fine. A remote line's edge gateway had been off the network Tuesday afternoon, drained its store-and-forward queue at 23:40 Wednesday, and the report recalculated silently on the next read. Nobody had ever decided whether that was allowed to happen — which is the actual defect. The historian did exactly what it was configured to do.

Backfill is writing samples after their collection time has passed. Writing old values with old timestamps is the easy part and every product on the market does it. The arguments are about which timestamp is authoritative, what a late value may overwrite, whether anyone can tell afterwards that it was late, and what happens to numbers already sent to somebody's inbox.

Two timestamps, and only one of them is the process

Every sample has a source time — when the device says the value was measured — and an arrival time, when the historian committed it. For process analysis the source time is the one you want: if the pump tripped at 10:04, the trend has to show 10:04. For comms forensics you want arrival time, because the two-hour gap between them is the finding.

What the protocol gives you varies more than people expect:

OPC UA carries both in every DataValue: SourceTimestamp and ServerTimestamp (Part 4). Worth verifying rather than assuming — plenty of servers just copy the server time into SourceTimestamp when the underlying device offers no time of its own, and then the distinction is cosmetic.
DNP3 (IEEE 1815) timestamps events at the outstation, either absolutely (g2v2) or relative to a Common Time of Occurrence record (g51 plus g2v3). That is why buffered events land at the correct process time when the radio comes back. Watch IIN2.3, though: event buffer overflow means events were dropped, not delayed, and no backfill policy recovers those.
Modbus has no timestamp field at all. The historian stamps at poll time, full stop. A Modbus device behind a gateway that buffers during an outage will hand you values that look like they happened at reconnect unless the gateway itself adds time.

Write down, per collector type, where the timestamp is generated and whether the historian is configured to accept it. Ten minutes at commissioning, and it settles an argument two years later that nobody will otherwise be able to resolve.

Late data is four different problems wearing the same coat

A remote asset buffering across a cellular or radio outage. Expected, and bounded by the device's buffer depth — know that number. An RTU holding 20,000 events at five events per second fills in about an hour, and everything past that is gone.
An edge gateway queue draining after reconnect. If you are on Sparkplug B, buffered metrics should carry is_historical = true so subscribers don't treat two-hour-old values as current state. Gateways that skip this cause more trouble than the outage did.
An OPC UA client reconnecting. Queued values replay only if the monitored item's QueueSize is greater than 1 and the subscription survived the disconnect. If the session actually died, you get nothing back unless something performs a HistoryRead.
A collector service that stopped during patching. This is the one that hurts, and it is not late data — it is missing data until someone notices. It needs a heartbeat alarm, not a backfill rule.

Lab and manual quality values are their own category: hours to days late, and the only case where a human types the timestamp.

The overwrite rule is the one nobody writes down

OPC UA Part 11 spells the decision out cleanly enough to borrow even on non-UA systems. HistoryUpdate takes a PerformUpdateType: Insert, Replace, Update (insert-or-replace), or Remove. Insert against a timestamp that already holds data returns Bad_EntryExists; Replace against an empty slot returns Bad_NoEntryExists.

Configure collectors for Insert. A duplicate then surfaces as a visible error instead of quietly clobbering a good sample, and duplicates at a restart boundary are common. Reserve Update and Replace for the manual correction path, with an audit trail behind it and a named person allowed to use it.

The rest of the policy is four lines:

Automatic window. I default to 24–48 hours and let the process argue me out of it. Utility metering genuinely needs days. A high-speed packaging line needs minutes, and a value arriving three days late there is a fault report, not data.
Outside the window. Approval plus audit log. Not "blocked" — blocked means someone edits the database directly at 2am.
Bad quality never overwrites good. This single rule kills most of the "the trend got worse overnight" tickets.
Keep the original. If a value is replaced, the prior value survives somewhere. Otherwise you cannot answer the only question anyone will ask.

Backfilled data must not look identical to live data

If a trend line is continuous and unmarked across a two-hour comms outage, the marking failed, whatever the quality column says internally. Test it that way: open the outage window in the same trend client an operator uses and see whether they could tell.

OPC UA Part 11 defines historian info bits inside the StatusCode — raw versus calculated versus interpolated, plus a Partial bit — and some products surface them properly in trends. Many don't. When the platform can't distinguish a backfilled good value from a live good value, use an annotation or a companion status tag rather than accepting the gap. The states worth separating are: live good, backfilled good, bad or unavailable during the outage, estimated or manually entered, and replaced after validation. Five states covers almost everything.

Settle the report question before you enable backfill

One question: is the published number allowed to change?

Freeze on approval, with late data visible only in engineering trends. My default for anything that leaves the plant.
Recalculate automatically inside a fixed window, frozen after. Reasonable for internal dashboards, and the window has to be written down.
Recalculate only after supervisor review. Correct wherever a person signs the record.

The bad case is the second option with no window and no marker — which is where the 41,200/43,700 report came from. Any report that can change needs "generated at" and "data complete through" printed on its face. In GxP work this isn't a style preference: 21 CFR Part 11 expects an audit trail on record changes, including who changed it and why.

Break it on purpose during commissioning

Do not learn buffer behaviour during the first real outage.

Pick four tags: an analog on a fast scan, a discrete, a totalizer, and an alarm-related status. Drive the analog as a slow ramp — a ramp is the easiest shape to eyeball for gaps, duplicates, and time shifts. Confirm normal collection, then pull the uplink or stop the forwarding service for a solid 30 minutes while the source keeps changing. Restore, watch the queue drain, then check:

Timestamps land inside the outage window, not bunched at the reconnect minute.
No duplicate samples at the restart boundary.
The totalizer sums once. Test this one specifically — if the historian computes deltas in arrival order rather than timestamp order, replayed counter values double-count, and the error looks like a real production increase.
The trend and the quality flags both show the outage.
Reports behave the way the policy says they should.
Replayed values do not raise live alarms.

That last one deserves its own look. A historian storing old alarm-related values is correct behaviour; the live alarm system re-announcing an event that ended two hours ago is a nuisance storm at exactly the wrong moment. Nothing in a normal IEC 62682 / ISA-18.2 alarm philosophy asks for that, so if it happens it's a configuration accident.

Before the next outage, go find out how deep each remote buffer actually is and how long it takes to drain over the real link. A gateway holding eight hours of data on a connection that needs six hours to push it back isn't a historian problem yet, but it will be, and the long outage is when you find out.