What is DNP3?
DNP3 is an open, published communication protocol designed specifically for SCADA systems communicating with geographically distributed field devices over serial, radio, and TCP/IP links. It was developed by Westronic in 1990 for electric utility applications, donated to public use, and is now maintained by the DNP Users Group. Unlike Modbus — which was designed for short-range, reliable serial links in a controlled factory environment — DNP3 was designed from the ground up to work in the harsh, long-distance, intermittently connected environment of utility infrastructure.
The protocol is built on a three-layer architecture modeled on the OSI stack: a Data Link Layer that handles framing, error detection, and link-level acknowledgment; a Transport Layer that reassembles multi-frame messages; and an Application Layer that defines the data objects, function codes, and request-response semantics that SCADA masters and field devices exchange. This layering gives DNP3 a degree of robustness over unreliable links that simpler protocols like Modbus do not have.
DNP3 is the protocol of critical infrastructure. If a SCADA system is monitoring electric grid substations, water treatment plants, wastewater lift stations, oil and gas pipelines, or remote wellheads, there is a high probability it is speaking DNP3. The protocol is specified by NERC, IEEE, and numerous utility regulatory bodies as a standard or preferred interface for these applications. Engineers who work in utilities, municipalities, or oil and gas pipeline operations will encounter it routinely.
Where DNP3 is used
⚡
Electric Power & Substations
The primary use case. SCADA masters at control centers communicate with RTUs and IEDs (Intelligent Electronic Devices) at substations over serial radio, leased lines, and TCP/IP. DNP3 provides the breaker status, meter readings, and control commands that grid operators depend on.
💧
Water & Wastewater
Water utilities use DNP3 to communicate with remote pump stations, storage tanks, pressure sensors, and treatment plant instrumentation — often over radio or cellular links that are intermittently available. The protocol's store-and-forward capability makes it well suited to these environments.
🛢️
Oil & Gas Pipelines
Pipeline SCADA systems use DNP3 to communicate with RTUs at compressor stations, meter runs, valve sites, and tank farms spread over hundreds of miles. Satellite and cellular links with high latency and occasional outages are common, and DNP3's unsolicited reporting and integrity polling handle them gracefully.
🌬️
Renewable Energy
Wind farms, solar sites, and battery energy storage systems increasingly use DNP3 for communication with grid operators and SCADA masters. The protocol's alignment with NERC reliability standards makes it a natural choice for grid-connected generation assets.
🏗️
Mining & Remote Operations
Remote mine sites, tailings pond monitoring systems, and dewatering operations use DNP3 over satellite links where Modbus polling would produce unacceptable response times and data gaps during connectivity interruptions.
🌡️
District Energy & Steam
District heating, cooling, and steam distribution systems communicating with remote substations and metering points frequently use DNP3, particularly in municipal utility environments where the protocol was standardized alongside electric and water SCADA systems.
DNP3 vs. Modbus: why utilities chose a different protocol
Engineers coming from a manufacturing background sometimes ask why utilities didn't just use Modbus for SCADA communication. The answer is that Modbus was designed for a fundamentally different problem, and the differences matter significantly at scale over unreliable infrastructure links.
Designed for
Factory floor, short serial links, controlled environment
SCADA over long-distance, unreliable links (radio, satellite, cellular)
Data model
Register tables (coils, holding registers) — 16-bit words
Typed data objects (binary input/output, analog input/output, counters, time)
Timestamps
None — no native timestamping
Built-in — millisecond-resolution source timestamps on every data point
Unsolicited reporting
No — master must poll for every value
Yes — outstations send data when it changes without being asked
Event buffering
No — missed polls mean missed data
Yes — outstations buffer events during link outages, deliver when reconnected
Data integrity
CRC per frame only
CRC per frame + application-layer CRC + integrity polling mechanism
Security (native)
None
DNP3 SAv5 — challenge-response authentication (optional)
Time synchronization
No native support
Yes — master can send time sync to outstation; DNP3 defines a time object
DNP3 data objects
Unlike Modbus's generic register model, DNP3 defines a set of typed data objects that correspond directly to the kinds of data that field devices and SCADA systems exchange. Each object group has a specific meaning and a set of variations that refine how the data is represented. Understanding the most common object groups is essential for configuring an OPC server to read DNP3 data correctly.
| Group (Variation) | Data type | Typical use |
|---|
| Group 1 — Binary Input | 1-bit boolean, current state | Breaker status, valve position, pump run/stop state, digital sensor states |
| Group 2 — Binary Input Change | 1-bit boolean with timestamp | State change events with millisecond source timestamps — essential for sequence-of-events analysis |
| Group 10 — Binary Output | 1-bit boolean, current state | Output relay status as read back from the outstation |
| Group 12 — Control Relay Output Block | Control command | CROB — the mechanism for issuing operate commands (open/close breaker, start/stop pump) with SBO or direct execute control |
| Group 20 — Counter | 32-bit or 16-bit unsigned integer | Accumulated pulse counts — energy meter pulses, flow meter totalizers, runtime hours |
| Group 22 — Counter Change | Counter value with timestamp | Counter value at the time of a change event, timestamped at the source |
| Group 30 — Analog Input | 32-bit or 16-bit integer or float | Current analog measurement values — voltage, current, pressure, flow, temperature |
| Group 32 — Analog Input Change | Analog value with timestamp | Analog deadband change events — value sent when it changes by more than the configured deadband |
| Group 40 — Analog Output Status | 32-bit or 16-bit value | Current setpoint or analog output value read back from the outstation |
| Group 41 — Analog Output Block | Control command | Mechanism for writing analog setpoints to the outstation (e.g., regulator setpoint, speed command) |
| Group 50 — Time and Date | 48-bit absolute time (ms since epoch) | Time synchronization from master to outstation; absolute timestamp in event objects |
Unsolicited reporting and event buffering
Two of DNP3's most important capabilities for utility SCADA — and the ones most different from Modbus — are unsolicited reporting and event buffering. Together, they make DNP3 practical over links that are expensive, slow, or intermittently unavailable.
Unsolicited reporting
In Modbus, the master is responsible for requesting every data point explicitly. If a breaker trips at 2:47:33.412 AM, a Modbus master only learns about it on the next polling cycle — which might be seconds or minutes later, and with no timestamp indicating when it actually happened.
In DNP3, outstations can be configured to send unsolicited messages to the master whenever a data point changes by more than a configured deadband (for analogs) or changes state (for digitals). When the breaker trips, the outstation immediately transmits a Binary Input Change event (Group 2) with a millisecond-resolution timestamp from its own clock, without waiting to be asked. The master receives the event, acknowledges it, and stores it with the original source timestamp. The sequence of events is accurate to the millisecond, regardless of polling latency.
Event buffering
When the communication link to a remote outstation is unavailable — the radio link is down, the cellular session has dropped, the satellite is blocked — Modbus polls simply fail. Any state changes that occur during the outage are lost. The master resumes polling when the link recovers and sees the current state, with no knowledge of what happened in between.
DNP3 outstations maintain an internal event buffer. Every state change, analog change, and counter change is stored in the buffer with its source timestamp, regardless of whether there is an active link to the master. When the link recovers, the outstation delivers the buffered events to the master in chronological order, with original timestamps intact. The SCADA historian receives a complete, accurate sequence of events spanning the outage period, not a gap.
Why event buffering matters for regulatory compliance. Electric utilities subject to NERC reliability standards, water utilities under EPA reporting requirements, and pipeline operators under PHMSA regulations are frequently required to maintain auditable records of equipment state changes and control actions. DNP3's event buffer and source timestamps provide this record automatically. With Modbus, engineers have to build the same capability in the SCADA application layer — and it is much harder to do correctly at the millisecond precision that post-event analysis requires.
Communication modes
DNP3 communication modes — master/outstation interaction patterns
Master →Integrity Poll (Class 0+1+2+3)On startup or after link recovery — requests all current data + buffered events
Outstation →Response: current data + all buffered events with timestampsDelivers complete state including anything missed during outage
Outstation →Unsolicited Response (Class 1/2/3 events)Sent immediately when new events occur — no master request needed
Master →ConfirmMaster acknowledges receipt; outstation removes events from buffer
Master →Select (Group 12, Var 1) — CROB commandSelect-Before-Operate control: first select to confirm intent
Outstation →Select Response (echo + status OK)Confirms the outstation received and is ready to execute
Master →Operate (same CROB)Execute the control action — must follow select within timeout window
Outstation →Operate Response (status OK)Control executed; master records control action with timestamp
DNP3 Secure Authentication (SAv5)
🔒
DNP3 Secure Authentication version 5 (IEEE 1815-2012)
DNP3 has historically had no security — any device on the network could send commands to any outstation. DNP3 SAv5 adds challenge-response authentication to the application layer, requiring both parties to prove they hold a shared secret key before critical messages are accepted. It is designed to work over the same serial and TCP links as standard DNP3 without requiring TLS or PKI infrastructure, making it practical for the brownfield utility environments where DNP3 is deployed. NERC CIP standards reference SAv5 as a method for meeting authentication requirements on communications to field devices in certain asset categories.
DNP3 and OPC: how they work together
DNP3 is a field protocol — it defines how a SCADA master talks to an outstation. OPC is a data access interface — it defines how a client application reads data from a server. The two are not alternatives; they occupy different layers of the architecture and are typically deployed together.
An OPC server like TOP Server acts as a DNP3 master. It connects to one or more DNP3 outstations using the DNP3 protocol — establishing the link, handling unsolicited messages, performing integrity polls on startup, and buffering events. It then exposes all of that data to OPC clients (SCADA, historian, HMI, analytics platforms) through the OPC DA or OPC UA interface. The OPC clients never speak DNP3; they just subscribe to named tags, and TOP Server handles all DNP3 communication on their behalf.
This architecture means a SCADA application that supports OPC can connect to DNP3 field devices without needing a native DNP3 driver of its own. The OPC server handles the protocol translation. Adding a historian, an HMI, or an analytics platform to the same data does not require additional DNP3 master sessions to each outstation — they all subscribe to TOP Server via OPC, sharing the single DNP3 master connection.
Connecting DNP3 devices with Software Toolbox
DNP3 master
TOP Server — DNP3 Master Driver
TOP Server's DNP3 Master driver implements the DNP3 master role, communicating with outstation devices over serial (RS-232/RS-485) and TCP/IP links. It handles all DNP3 object groups — binary inputs and outputs, analog inputs and outputs, counters, time objects — with full support for unsolicited reporting, event class polling (Class 0, 1, 2, 3), integrity polling on startup and link recovery, and the Select-Before-Operate (SBO) control sequence. Source timestamps from outstation event objects are preserved through the OPC tag data and surfaced to historians, preserving the millisecond event sequence that utility applications require.
OPC to SCADA
TOP Server — OPC DA / OPC UA server
Once TOP Server has established DNP3 connections to outstations, it presents all DNP3 data to any OPC DA or OPC UA client application — SCADA, historian, HMI, or analytics platform — through standard OPC interfaces. Multiple OPC clients can subscribe to the same DNP3 tag data simultaneously. This eliminates the need for each application to maintain its own DNP3 master connection to every outstation, which simplifies outstation configuration and reduces communication load.
Edge + contextualization
N3uron
For organizations building modern IIoT or UNS architectures on top of DNP3-based infrastructure, N3uron subscribes to DNP3 data via TOP Server's OPC UA interface, contextualizes raw outstation point addresses into ISA-95-structured tag names, and publishes the result as a Sparkplug B MQTT stream. This is the bridge between legacy utility SCADA infrastructure and modern cloud analytics, AI, and enterprise data platforms — without replacing any of the existing DNP3 outstations or SCADA systems.
Frequently asked questions
What is the difference between DNP3 and IEC 60870-5-101/104?+−
DNP3 and IEC 60870-5 are parallel protocol families that solve the same problem — reliable SCADA communication over WAN links with critical infrastructure field devices. They were developed independently at roughly the same time and share many architectural concepts: both have typed data objects, both support unsolicited reporting, both include event buffering with timestamps, and both define specific object types for binary inputs/outputs, analog inputs/outputs, and counters.
The primary geographic divide is North American vs. European adoption. DNP3 dominates in North America, Australia, and parts of Asia-Pacific. IEC 60870-5-101 (serial) and IEC 60870-5-104 (TCP/IP) dominate in Europe, South America, and much of Asia. If you are working with a utility in the US or Canada, you will encounter DNP3. If you are working with a European utility or a grid operator in South America, you will encounter IEC 60870-5-104. TOP Server has dedicated drivers for both protocol families.
What does "Class 0, 1, 2, 3" mean in DNP3?+−
DNP3 defines four data classes that control how data points are prioritized for transmission:
- Class 0 (Static data): Current value of all data points — the equivalent of a full poll. Read with an integrity poll on startup or on request.
- Class 1 (Events, highest priority): Data points assigned Class 1 generate events that are transmitted first. Typically used for the most critical state changes — breaker trips, loss of communication.
- Class 2 (Events, medium priority): Important but non-critical events. Typically used for process alarms, threshold crossings.
- Class 3 (Events, lowest priority): Non-urgent events. Typically used for diagnostic information, periodic counters.
Each data point in an outstation's configuration is assigned to a class. The master can poll for specific classes independently — polling Class 1 only retrieves the highest-priority events without requiring a full Class 0 integrity poll. On link recovery, a master typically performs an integrity poll (Class 0+1+2+3) to retrieve both the current state and all buffered events at all priority levels.
What is Select-Before-Operate (SBO) and when is it required?+−
Select-Before-Operate (SBO) is a two-step control mechanism that prevents accidental or erroneous commands from being executed by a field device. Before issuing an operate command, the master first sends a select message to the outstation specifying the control point and the intended action. The outstation responds with a confirmation that it is ready to execute. The master then sends the operate command. The outstation only executes the operation if the operate arrives within the configured timeout window after the select, and if the operate exactly matches the select.
SBO is typically required for controls with significant operational or safety consequences — breaker open/close commands, valve actuations, pump start/stop in critical applications. Direct Operate mode, which executes without the select step, is available for less critical controls where the additional round-trip time is not acceptable. Utility SCADA applications typically configure critical control points as SBO; TOP Server supports both modes.
How does TOP Server handle DNP3 outstations that go offline?+−
When a DNP3 outstation becomes unreachable, TOP Server marks all tags from that outstation with Bad quality status — the OPC quality value that indicates the data is not trustworthy. Historian and SCADA clients that respect OPC quality will exclude Bad-quality values from calculations and display them as offline rather than showing stale values as current.
When the outstation reconnects, TOP Server automatically performs an integrity poll (Class 0+1+2+3) to retrieve the current state and all events that accumulated in the outstation's event buffer during the outage. These events are delivered to OPC clients with their original source timestamps, so the historian receives a complete record of what happened during the disconnection period rather than a gap.
Can DNP3 work over TCP/IP, or only serial?+−
DNP3 works over both serial and TCP/IP. The original specification was designed for serial links (RS-232, RS-485, radio modems), and serial deployments remain common in older utility infrastructure. DNP3/TCP, defined as part of the IEEE 1815 standard, encapsulates the same DNP3 application layer inside TCP packets on port 20000. The protocol behavior — object types, function codes, unsolicited reporting, event buffering — is identical; only the physical transport changes.
Serial-to-Ethernet converters are commonly used to connect legacy serial DNP3 outstations to IP networks without replacing the outstation hardware. TOP Server supports both native serial DNP3 and DNP3/TCP, and can simultaneously communicate with serial and TCP-connected outstations in the same deployment.
What is the difference between a DNP3 Master and a DNP3 Outstation?+−
In DNP3 terminology, the Master is the SCADA control center — the system that initiates communication, issues commands, and collects data. The Outstation (also called a Remote Terminal Unit or RTU, or an Intelligent Electronic Device/IED in substation contexts) is the field device that responds to master requests, generates unsolicited reports, and executes control commands.
TOP Server implements the DNP3 Master role. It connects to DNP3 Outstations — RTUs at pump stations, IEDs at substations, flow computers at meter runs — and collects their data for presentation to OPC client applications. TOP Server does not implement the Outstation role (it cannot be polled by another DNP3 Master), but the OmniServer product can implement custom protocols including outstation-side communication for specialized integration scenarios.
Connecting DNP3 infrastructure to your SCADA or data platform?
Software Toolbox's engineers have been implementing DNP3 master connectivity for utilities, municipalities, and pipeline operators since the protocol was young. TOP Server's DNP3 driver handles every object type, both serial and TCP transports, and the full event class model.
