How to Fix IEC 60870-5-104 Timestamp Problems

Back to Blog

First Checks

Determine where each timestamp is born before judging it. A time-tagged ASDU carries the outstation's clock reading from the moment of the event; an untimed one arrives bare, and whatever time it shows downstream was stamped by the gateway, master, or historian on arrival. Pull one wrong event and trace which case it is - the answer forks the whole diagnosis, and mixed fleets routinely contain both. This is the protocol-level version of the distinction drawn in source versus server timestamps.

Then characterize the error against a reference: exact and constant, drifting, epoch-vintage, or inconsistent between points. Each shape maps to one section below, and the mapping is reliable enough that the shape usually is the diagnosis - the remaining work is confirming and fixing it.

Offsets of Exactly a Timezone: the Local-vs-UTC Mismatch

The most common cause by far: the outstation writes its timestamps in local time while the master interprets them as UTC, or the reverse. The 104 time tag structure has no timezone field doing that work for you - the convention is a profile agreement, and when the two ends assume differently, every timestamp lands wrong by exactly the offset, flipping by an hour at daylight-saving transitions. That seasonal flip is the confirming fingerprint: an offset that changed by one hour in spring is a timezone convention problem, full stop.

Fix it by declaring one convention - UTC end to end is the strongly preferable one, leaving local time to the display layer - and configuring every station, gateway, and master to it explicitly rather than by default. During the migration, expect a one-time step in historical continuity and annotate it; the alternative, correcting old data in place, is rarely worth the risk. Daylight-saving handling deserves its own test at the next transition, because devices with local-time firmware take their DST rules from tables that age badly.

Drifting or Epoch Times: the Clock Is Not Being Synced

An offset that grows over days is an unsynchronized device clock free-running on its oscillator; times from the distant past are a clock that restarted and was never set at all. Either way the question is how this station's clock is supposed to be disciplined - and over routed, variable-latency networks the honest answer should usually be NTP or an equivalent network time service at the station, since a time written across a jittery path arrives already wrong by an unpredictable transit delay. The reasoning and setup are covered in NTP time synchronization for SCADA.

Where the protocol's own clock-synchronization command is in use - the master periodically writing time to the station - verify it is actually configured, actually accepted, and actually sufficient for your accuracy needs given the path's latency variation. It serves adequately on consistent low-latency links and disappoints on congested ones. Whichever mechanism is chosen, alarm on its failure: a station whose sync silently stopped is manufacturing subtle timestamp corruption daily, and the drift is far cheaper to catch as a sync alarm than to discover during a disturbance investigation.

Inconsistent Ordering: Mixed Time Sources per Point

When timestamps look individually plausible but the sequence is impossible - the consequence recorded before its cause - suspect mixed provenance: some points arriving time-tagged with field time, others untimed and stamped minutes later on arrival or at the next cyclic transmission. The audit is mechanical: from a capture, list which ASDU types each point actually uses; every untimed type in the event path is a point whose true event time is being discarded and replaced downstream.

Fix by configuring time-tagged ASDU types for every point where sequence matters - the with-time variants exist for indications and measurements precisely for this - and reserving untimed types for values where arrival time is honestly good enough. Where a legacy device simply cannot tag, document that its events carry arrival time so no one builds a sequence argument on them. The stakes are the same as in any sequence-of-events record: ordering is the product, and mixed clocks quietly ruin it.

When to Escalate

Escalate to the device vendor when the capture proves the outstation itself misbehaves: emitting timestamps that disagree with its own synced clock, mangling the daylight-saving transition despite correct configuration, or reverting to epoch after brief power dips that its documentation claims to ride through. Attach the capture, the device's clock configuration, and the sync evidence - the triad that turns a times-are-weird complaint into a firmware ticket.

Escalate internally when wrong timestamps have already contaminated analyses: disturbance reports, regulatory submissions, or billing determinations built on affected intervals deserve a documented correction rather than a quiet fix-forward. Identify the affected window, state the systematic offset where one is known, and annotate the historian - the same discipline as any data-quality incident, applied to time itself.

Frequently Asked Questions