Use event timestamps according to their documented meaning, not simply the order in which messages reach a dashboard. Source time, server time and a gateway’s receive time can describe different points in a record’s life. Clock offsets and uncertainty can also reverse an apparent event order. This fictional two-sensor example reconstructs the sequence only when the offset evidence permits it, and keeps the order unresolved when the timing uncertainty is too large.
Distinguish machine event order from message arrival order.
Apply a documented clock correction with its sign visible.
Avoid claiming causality from uncertain timestamp differences.
Name each clock and what its timestamp means
OPC UA defines a source timestamp for the value at its source and a separate server timestamp. The server semantics should be read from the specification, not assumed to mean a universal network arrival time. A gateway can also record its own explicit receivedAt field.
Retain all relevant fields instead of overwriting one with another. Store UTC or another unambiguous time representation and preserve the display time zone separately. A timestamp’s many decimal places do not establish clock accuracy.
Read the fictional arrival-order reversal
Suppose the actual source events occur within the same second: A at 10:00:00.200 and B at 10:00:00.500. A reaches the gateway at 10:00:00.900, while B reaches it at 10:00:00.700. The arrival order is B then A, even though A occurred first.
The 700 ms and 200 ms transport delays in this teaching example are known by construction. A real system needs synchronized or bounded clock evidence before subtracting timestamps on different devices to report network latency.
| Event | Corrected source time | Gateway receive time | Delay in this constructed example |
|---|---|---|---|
| A | 10:00:00.200 | 10:00:00.900 | 700 ms |
| B | 10:00:00.500 | 10:00:00.700 | 200 ms |
Correct a known offset without hiding it
Now suppose A’s device clock is 400 ms ahead. Its raw timestamp is 10:00:00.600. With a documented positive 400 ms offset, corrected time is raw time minus offset, returning 10:00:00.200. B’s raw time is 10:00:00.500 with a stated zero offset.
Keep raw time, correction, evidence date and uncertainty. Do not change historical records silently when clock synchronization changes. If offset varies during the observation, one fixed correction may be inadequate.
A:.600−.400 =.200. A positive offset means the device clock is ahead of the reference. The corrected A-to-B separation is 300 ms.
Check whether the time difference exceeds uncertainty
If each corrected timestamp has uncertainty of±200 ms, the relative A-to-B separation can range from−100 to 700 ms under simple worst-case bounds. Its sign is not established. The nominal 300 ms gap is insufficient to prove which event occurred first.
A bounded sequence number from the same source may establish local ordering even when cross-device order remains unclear. Sequence, batch and unit identity also help distinguish late delivery from a different production event. Lot traceability needs meaningful identity as well as time.
- Preserve timestamp provenance
Record the physical clock, field meaning, raw value and receive time.
- Apply justified corrections
Retain offset sign, source and validity period with uncertainty.
- Reconstruct the required order
Use source identity, sequence and timing bounds rather than arrival alone.
- Flag unresolved comparisons
Keep ambiguous cross-device order out of causal claims and calculated durations.
Keep unchanged values and clock steps out of false alarms
An OPC UA source timestamp can remain unchanged when the value has not changed. Use status and connection evidence to assess freshness. A poll timestamp cannot recreate the moment of an unobserved machine transition.
Check clock steps, daylight-saving display changes, device reboot, missing offsets and replayed messages. Counter-reset handling addresses a related discontinuity; real-time monitoring should expose these data limits rather than smooth them away.
Use a timing record before building a causal story
A stop at one machine followed by a message from another does not prove causation. Establish the event definition, identity, corrected order and plausible process mechanism. Timing can rule out an explanation without proving its replacement.
The download keeps the raw and corrected fictional events side by side. Use the blank timing fields to record what each clock means, how its offset was checked and which event pairs remain too close to order.
A related example from Abolfazl
Check event time, late arrivals and duplicates before trusting a live count.
In English, on founder Abolfazl’s personal blog. This is related reading, not an independent technical source.
Practical checklist
- Define each timestamp field.
- Identify the physical clock.
- Keep raw and receive times separately.
- Use an unambiguous time basis.
- Retain offset sign and validity.
- Compare differences with uncertainty.
- Use sequence and unit identity where available.
- Leave ambiguous order and causality unresolved.
FAQ
FAQ
Sources and further reading
Authoritative references used to research and verify this guide.