What Is DNP3 Time Synchronization?

Back to Blog

How a Master Sets Outstation Time

The outstation asks, and the master answers. An outstation signals that it wants its clock set by setting the need-time bit in the internal indication (IIN) field it returns on responses. The master notices that flag on its next poll and writes the current time to the outstation using a time-and-date object in group 50. Once written, the need-time bit clears until the outstation decides its clock has drifted again.

The write can account for link delay so the outstation applies a corrected time rather than the moment the master composed the message. There are also record-based time-sync variants for higher accuracy. The core loop, though, is simple: the outstation requests time via a flag, and the master supplies it via a write - the same flag whose lingering presence is what a technician chases when clearing a need-time IIN flag.

Why Time Sync Underpins the Event Model

DNP3's whole value proposition for disturbances rests on time. Because events are timestamped at the outstation, a DNP3 sequence of events can reconstruct the order and timing of changes after the fact. But that only works if the outstation clock is correct. An unset or drifted clock produces events whose relative order is fine but whose absolute times are wrong, so they cannot be lined up against events from other outstations.

This is why DNP3 time sync often rides alongside a facility time source. A master may itself be disciplined by NTP and then propagate time down to outstations over DNP3, so the whole system shares one reference. Where sub-millisecond alignment across devices is required, a dedicated time distribution is used instead. The design principle is the same either way: no time source, no trustworthy sequence of events, and DNP3's timestamps are only as good as the clock behind them.

Serial Versus Networked Links: Picking the Sync Procedure

The standard offers more than one way to deliver time, and the link decides which one fits. On a serial channel with predictable latency, the master can first issue delay measurement (function code 23), timing a round trip so it knows roughly how long a message takes to arrive, and then write the group 50 time corrected for that delay. On routed networks the round trip varies from message to message, so a measured delay is already stale by the time it is applied; the record-current-time procedure (function code 24) addresses this by having the outstation latch the arrival moment of a specific frame, which the master then references when it writes the time. Using the serial-style procedure over a routed network is a classic way to end up with confidently wrong clocks.

There is also the option of not using DNP3 for time at all. An outstation that can discipline its clock from a local or network time source independently of the protocol removes the master from the loop entirely, and many modern devices support this. Whichever way a site goes, the design rule is the same: pick exactly one authoritative time source per outstation and disable the rest, because two writers fighting over one clock produce timestamp steps and reversals that are far harder to interpret afterward than steady, predictable drift would have been.

Sync Interval, Drift, and Events Already in the Buffer

How often to sync is a site-specific decision driven by two things: how fast the outstation's oscillator drifts, and how much timestamp error the application can tolerate. A system reconstructing cause and effect across multiple outstations needs much tighter alignment than one that only cares about same-day trending. The outstation raises its need-time flag on whatever schedule its configuration sets, but a master does not have to wait for the flag - many also sync on their own schedule as insurance. Drift behavior is per the device's documentation and worth verifying empirically: watch how far the clock walks between syncs during commissioning, and set the interval from that evidence rather than from habit.

One subtlety catches people repeatedly: a time write fixes the clock going forward, never backward. Events waiting in the event buffer were stamped at the moment they were captured, so events generated while the clock was wrong keep their wrong timestamps even after the master syncs. After an outstation restart, everything recorded before the first time write carries suspect times, which is one reason the restart sequence - the null unsolicited response announcing the restart, then the master clearing the restart indication and writing time promptly - deserves to be fast and automatic rather than waiting on the next scheduled poll cycle to come around.

Verifying Time Sync in the Field

A short verification pass during commissioning saves a great deal of confusion later:

1. Force a test event at a known moment against a trusted reference clock, and compare the outstation's event timestamp with the reference.
2. Capture the exchange and confirm the group 50 write is present, along with the delay measurement or record-current-time step if the design calls for one.
3. Watch the need-time indication clear after the write, and note how long the device runs before raising it again.
4. Repeat the test event across several outstations and check that their timestamps line up with each other, since cross-device alignment is the entire point of the exercise.
5. Document which source disciplines each clock, so nobody quietly adds a second one later.

The cross-device check in step four is the one that finds real problems. Each outstation can pass a solo check while the population disagrees with itself, because different devices may be synced by different masters, on different schedules, or through different procedures. Lining up one physical event across every outstation that saw it is the closest thing to a ground-truth test the field offers, and it takes minutes while the crew is already on site.

Frequently Asked Questions