Engineering

Timestamps and quality: the two things that decide whether the data is believable

2026-10-29 · 8 min read

Two devices can report the same voltage and mean completely different things: one measured it a second ago with a synchronised clock, the other is replaying a value from before the last restart. What separates them is not the number — it is the timestamp and the quality attached to it. Both are easy to set to something plausible and hard to get right.

Why the timestamp is not decoration

Sequence-of-events analysis is the reason substation protocols carry timestamps at all: an operator needs to know which of two operations happened first, often to a millisecond. Our published figure for the 104 package is 1 ms timestamp accuracy — a number that is meaningless without a time source good enough to support it.

The failure mode is subtle. A free-running clock drifts; timestamps look sane, events look ordered, and the ordering is wrong by more than the process can tolerate. Nothing alarms, because nothing is checking.

SNTP versus PTP, in terms of what you can promise

• SNTP over a LAN typically holds within a few milliseconds and can be worse across a congested network. It is adequate for sequence-of-events at the millisecond scale only if the network is quiet and the server is close.
• PTP with hardware timestamping reaches sub-microsecond, and is what sampled values need. It also demands switch support and careful configuration; a PTP deployment that falls back to software timestamping silently loses its advantage.
• Whatever you use, monitor the offset. A device that reports its clock offset lets you find the problem before an event analysis does.

Quality bits: who sets them, who propagates them

Quality is not a single flag. It describes validity, whether the value overflowed its range, whether it was derived rather than measured, and whether it is being held while the source is unavailable. A device that sets quality to good at the output has thrown away the only information the control room had about trust.

• Set quality at the source of the measurement, where you know whether the sample was valid.
• Propagate it through every layer: internal bus, gateway, protocol encoding. Conversion to another protocol must map it explicitly, not drop it.
• Never substitute a value. Zero is a valid measurement; a substitute zero on comms loss is a lie the operator cannot detect.
• Mark held values as such, with the time of the last real update.

The practical checks

• Step the clock backwards by an hour and confirm the device does not produce events with timestamps that appear to come from the future.
• Disconnect the time source and leave the device running for a day; measure the drift and confirm the device reports that it is unsynchronised.
• Inject an out-of-range value and confirm the quality bit changes all the way to the client.
• Compare a captured sequence of events against both devices' local logs; if the ordering differs, the time base differs.

Questions that come up

Is a millisecond timestamp achievable without PTP?

Within a single substation LAN with a good SNTP source, yes, in the sense that the error stays near a millisecond. Across a wide area with an unreliable path, no — and claiming otherwise is how acceptance tests fail.

What should a gateway do with quality when converting to Modbus?

Expose it explicitly in a companion status word. Modbus has no quality concept, so the choice is either to carry it in a defined register or to lose it; losing it silently is the worst of the three.

Do timestamps need to be in UTC?

Store and transmit in a defined, unambiguous time base — UTC is the safe choice — and convert for display only. Local time with daylight saving transitions produces duplicated and missing hours, and someone will eventually hit one during an incident.

Keep reading