Time synchronization for industrial data: NTP, PTP and timestamp discipline

Why timestamps decide whether data can be trusted

A value without a trustworthy time is only half a measurement. Wrong clocks quietly break things that look unrelated:

• Event order. Which alarm came first? Root-cause analysis depends on sequence.
• Joining data. OEE counters, energy meters and quality results from different systems only line up if their clocks do.
• Historian backfill and replay. A gateway replaying buffered data after an outage must carry the original time, not the time of replay.
• Security. Certificates and tokens have validity periods; a clock that is hours off makes connections fail (see OPC UA security basics), and logs with unreliable times are of little use in an investigation.

Know where the timestamp is applied

A sample can be stamped at several points: in the sensor or PLC, in the edge gateway when it receives the value, in the broker, or when the historian ingests it. Each choice has consequences:

• A source timestamp reflects when the value was measured but depends on the source’s clock.
• An ingest timestamp is consistent but includes delivery delay and wrongly dates replayed data.

The robust approach is to keep both, clearly named, and to document which one each system uses.

NTP: enough for most plants

The Network Time Protocol keeps clocks aligned over ordinary networks. Typical accuracy is a few milliseconds on a well-managed local network and tens of milliseconds across the internet, which is more than enough for dashboards, OEE and historians sampling in seconds. Good practice for an OT environment:

• Run one or two local time servers inside the plant network, ideally disciplined by a GNSS receiver or a trusted upstream source, rather than letting every device reach public servers from the control network.
• Configure each device with more than one source where it allows.
• Monitor the offset, because an unmonitored clock drifts until someone notices.

PTP: when milliseconds are not enough

The Precision Time Protocol (IEEE 1588) can reach sub-microsecond alignment, but only with hardware timestamping in the devices and network equipment that understands PTP, using boundary or transparent clocks in the switches. It is the right tool for sequence-of-events recording, coordinated motion and some power-system applications, where industry-specific profiles exist. It is not necessary for typical OEE or historian use, and it adds design and commissioning effort, so adopt it when a requirement demands it, not because it is more precise.

Time zones, daylight saving and formats

• Store UTC. Convert to local time only for display.
• Write ISO 8601 with an explicit offset or a Z, for example 2026-10-03T09:15:00Z. A local time without an offset occurs twice when clocks go back and not at all when they go forward.
• Know your epoch unit. Seconds versus milliseconds is a classic factor-of-1,000 error.
• Do not rely on the PLC’s local clock setting as the source of truth unless it is synchronized and its time zone is documented.

Detecting drift

Compare each device’s reported timestamp with the receipt time at a trusted collector. A consistent difference is the device’s offset; one that grows over days is drift. Plot the offset per device, set an alert threshold that matches your use case and review the worst devices regularly. The checks described for sensor files also catch time jumps and duplicated samples.

A simple policy to write down

1. One authoritative time source per site, documented.
2. Every device synchronized to it, or flagged as unable to synchronize.
3. All stored timestamps in UTC, with the source and ingest times kept apart.
4. For devices that cannot synchronize, stamp at the gateway and mark the quality as gateway time.
5. Offsets monitored, with an owner for the alert.

Time source, time zone and timestamp convention belong in the industrial data contract, and “is data quality measured?” is question 9 of the readiness worksheet.