DNP3 vs IEC 60870-5-101/104 Compared

Back to Blog

Common Roots, Different Data Models

DNP3 and IEC 60870-5 both grew out of the same foundational IEC telecontrol standard, which is why they feel so similar. Both split data into static current values and time-tagged events, both support unsolicited reporting so an outstation can push changes, and both carry timestamps so a sequence of events can be reconstructed. An engineer who understands DNP3's class model finds the IEC concepts familiar and vice versa.

Where they part is in encoding. DNP3 organizes data with object groups and variations, while IEC 60870-5 uses ASDU type identifiers and information object addresses - a different way of naming what a value is and where it lives. IEC 60870-5-104 in particular runs over TCP with its own connection management, covered under what is IEC 60870-5-104, and it uses a cause-of-transmission field to explain why each message was sent, whereas DNP3 leans on its function codes and internal indication field.

How the Choice Usually Gets Made

In practice the decision is rarely about protocol merit and mostly about ecosystem. DNP3 is the default across North American electric, water, and oil-and-gas SCADA, so a new outstation there almost always speaks DNP3 to match the master and the neighbors. IEC 60870-5-104 is the common choice across much of Europe and in many international utility networks. The connecting utility or the existing master usually dictates which one a new device must support.

When a site has to bridge both - a common situation at an interconnection or when a device only speaks one - a protocol gateway translates between them, mapping DNP3 points to IEC ASDUs and back. The comparison table below summarizes the practical differences, but the guiding principle is simple: match the installed base first. Both protocols are capable telecontrol standards, so the deciding factor is what the rest of the system already speaks, not a feature scorecard.

DNP3 vs IEC 60870-5 at a Glance

The table sets the two families side by side on the points that matter to an integrator.

Criterion	DNP3 (IEEE 1815)	IEC 60870-5-101/104
Data model	Object groups and variations	ASDU type IDs and information object addresses
Networked form	DNP3 over TCP, port 20000	IEC 60870-5-104 over TCP
Why-sent field	Function code and IIN status	Cause of transmission
Event and time model	Classes, time-tagged events	Time-tagged ASDUs, general interrogation
Typical region	North America	Europe and much of the world
Security	Secure Authentication (SAv5)	Companion security standards

The Paperwork That Makes Interoperability Real

Both protocol families solve the same practical problem - no two devices implement everything - with a capability document. On the DNP3 side that is the device profile, backed by the subset levels the standard defines so a master and outstation can agree on a minimum common set of function codes and objects. On the IEC 60870-5 side it is the interoperability list, a checklist in the standard itself marking which ASDU types, causes of transmission, and command forms a device actually supports. Before any integration work, get this document from the vendor and set it beside the master's own profile.

Read the two documents for the things that bite during commissioning: whether unsolicited reporting is supported and in which mode, which time-tag formats the device sends, whether commands are direct-operate or select-before-operate, and how counters are frozen and read. A mismatch here does not fail loudly; it shows up later as a point that never updates or a control the outstation quietly rejects. An hour spent comparing profiles is the cheapest debugging you will ever do on a telecontrol link.

Serial Variants and Migration Paths

Both families started on serial links and both still run there. IEC 60870-5-101 is the serial member of its family, with balanced and unbalanced link modes - unbalanced for multidrop channels where the master polls each outstation in turn, balanced for point-to-point links where either end may transmit. DNP3 likewise runs over serial with its own data-link addressing, and the same point database moves unchanged when the transport later becomes TCP. That continuity is the main reason migrations are usually less painful than they look.

A common upgrade path swaps the transport while keeping the application layer: 101 outstations move to 104 over the network, and serial DNP3 outstations move to DNP3 over TCP on port 20000, while IEC 60870-5-104 uses its registered port 2404. Firewall and routing work therefore differs between the two, which matters when the link eventually terminates in a hosted master - the plumbing is covered in the guides on bringing DNP3 into a cloud SCADA and connecting IEC 60870-5 to a cloud master.

A Commissioning Checklist That Works for Either

The protocols differ in vocabulary but the commissioning sequence is nearly identical, which is convenient for crews that maintain both. A workable order:

1. Collect the device profile or interoperability list and reconcile it against the master's capabilities before anyone drives to site.
2. Agree the addressing plan in writing: DNP3 point indexes per object group, or the IEC common address plus information object addresses.
3. Decide the reporting scheme: which points are event-class or cyclic, and whether unsolicited reporting is enabled from day one.
4. Agree the time synchronization method and confirm the outstation's time tags after a sync, not before.
5. Run a full integrity poll or general interrogation and walk the returned values against known field states.
6. Exercise each control end to end, with the field device confirmed safe to operate by site procedures and qualified personnel.

Security deserves a line of its own in that plan. DNP3 has Secure Authentication version 5 for challenging critical operations, while the IEC family leans on the IEC 62351 companion standards; on either protocol, an unauthenticated control path across a routable network is a finding, not a preference.

Frequently Asked Questions