An Introduction to
DNP3
What is DNP3?
Distributed Network Protocol (DNP, DNP3 or DNP 3.0) is a communications protocol used in Supervisory Control and Data Acquisition (SCADA) and remote monitoring systems. It’s an open standard protocol, which means any manufacturer can develop DNP3-compatibile equipment that natively interoperates with other DNP3 devices. The protocol has achieved large-scale adoption in electric utilities and water/wastewater systems, and is also prominent in the gas and oil sectors. DNP3 is formally standardized as IEEE 1815.
A Brief History of DNP3
DNP3 was originally developed by Westronic, Inc. (later GE Harris, now part of GE Digital Energy) starting in 1990, with the “DNP 3.0 Basic 4” specification released into the public domain in 1993. Ownership was subsequently handed to the DNP Users Group, which still maintains the standard today.
At the time, the IEC 60870-5 series of standards, including IEC 60870-5-101 (point-to-point serial) and IEC 60870-5-104 (TCP/IP networks), was still being finalized. Because DNP3 was ready before that standardization process wrapped up, it gained early, strong traction in North America, Asia, and Latin America, while much of Europe standardized around IEC 60870-5 instead.
The name “DNP3” comes from the original version designation, “DNP V3.00.” The DNP Users Group later shortened this to “DNP3” specifically to drop the “software version” implication and signal that the protocol wouldn’t keep incrementing. There was never a DNP 3.1 or DNP 4.0 released.
A common but inaccurate explanation for the “3” in DNP3 is that it refers to the protocol’s three functional layers. While the protocol does happen to rely on a streamlined three-layer model, that’s a separate fact from where the name came from.
Main Capabilities
As an intelligent and robust SCADA protocol, DNP3 gives you many capabilities:
- Request and response messages that can carry multiple data types in a single exchange
- Unsolicited messaging (response without request) so outstations can report events without waiting to be polled
- Support for multiple masters and peer-to-peer communication
- Standardized time synchronization
- Event-based reporting that transmits only changes data, reducing bandwidth use
DNP3 Communication Model: Master/Slave
DNP3 typically connects a centrally located master to distributed field devices called outstations. The master is the interface between the human operator (or upstream system) and the monitored network. The outstation, commonly a PLC, RTUor intelligent electronic device (IED), is the interface between the master and the physical equipment being monitored or controlled.
DNP3 is fundamentally a polled protocol. When a master connects to an outstation, it typically performs an integrity poll: a combined request for Class 0 (static/current) data along with any buffered Class 1, 2 and 3 event data. This gives the master a complete picture of the outstation’s state at connection time. After that, only changes need to be reported.
Master and outstation devices draw from the same library of predefined DNP3 objects to exchange information, which is a big part of why devices from different manufacturers can interoperate without custom translation layers.
DNP3 Physical Layer
The DNP3 protocol was originally engineered for serial communication lines, but modern industrial networks widely deploy it over IP-based infrastructure. The standard natively supports:
- Standard Serial: Native transmission over RS-232, RS-422 and RS-485 serial networks
- DNP3 over TCP/IP: Direct encapsulation where standard DNP3 application data is wrapped inside a TCP frame
- DNP3 over UDP/IP: Encapsulation inside UDP packets for connectionless broadcasting across networks
Number of Devices
DNP3 supports both point-to-point and point-to-multipoint topologies, for example, multiple outstations sharing an RS-485 bus with a single master. Master and outstation devices are each identified by a 2-byte address, giving a usable range of roughly 0–65,519. The highest addresses in the range are reserved for broadcast addressing, self-addressing and future use.
Outstations can also send spontaneous data using the Unsolicited Response function (function code 130 in a response context). This is efficient on point-to-point or Ethernet links, but on a shared multi-drop serial bus it introduces collision risk if multiple outstations try to transmit unsolicited data at the same time. On shared serial buses, it’s generally best practice to limit or disable unsolicited responses and rely on the master’s polling or move that segment of the network to Ethernet.
DNP3 Data Representation
Object Model
DNP3 is built around a predefined object model rather than requiring engineers to hand-map bits and registers, which is common in less structured protocols. This model also reduces the wide disparity of status monitoring and control paradigms generally found in protocols that provide virtually no pre-defined objects.
Objects in the library are organized into Groups and Variations. For example, the Analog Input group includes variations for 16-bit or 32-bit integers and floating-point values, with or without a status flag. This shared object library is what lets a master integrate data from outstations built by different vendors without a proprietary translation layer.
The Object Library
The DNP3 framework includes a library of objects that are typically used in SCADA systems. This library is available for downloading to members of the DNP Users Group (visit dnp.org for more information). These objects include such things as Binary Inputs that are used to report equipment characteristics that have two states: power is on or off, an access panel is open or closed, etc. Another common object is an Analog Input that is used to report characteristics that have a range of values: exhaust fan speed between 40 and 400 RPM, main power can between 110 and 128 VAC.
This library makes it easy for the manufacturer to design the DNP3 remote responder to use these common objects to report to upstream masters. It also makes it easier for masters to integrate the data collected from remotes and present it for decision making.
Without this framework of common objects, manufacturers must develop their own model for reporting status and providing control capability. These models, frequently quite different one from another, must then be ‘compiled’ into the masters and usually converted into some kind of common object for efficient management. Another tool often found in these more ‘open’ frameworks is a proprietary interface or translation module to access and control the remote.
Objects in the DNP3 library are divided into Groups and Variations. For example, the Analog Input group has six variations to provide 16- or 32-bit integer or floating point values with or without a status bitmap. The Analog Event group has eight variations to provide 16- or 32-bit integer or floating point values with a status bitmap and with or without a timestamp. Note that the Analog Event group does not include variations without a status bitmap.
Object Classes
The DNP3 protocol organizes data into 4 classes:
- Class 0: Static data, the current value of a point, independent of whether it has changed
- Class 1: Dynamic/event data, priority 1 (usually high)
- Class 2: Dynamic/event data, priority 2 (usually middle)
- Class 3: Dynamic/event data, priority 3 (usually low)
A Class 0 read returns current values across all points. A Class 1–3 read returns only the events (value changes) buffered for that class since the last read. This lets a master poll high-priority alarm data (Class 1) frequently while polling slower-changing or lower-priority data (Class 2/3) less often, and reserve full integrity polls (Class 0) for periodic reconciliation. For example, a Class 1-3 poll every few seconds alongside a Class 0 integrity poll every 10 minutes.
DNP3 Message Structure
DNP3 is a packet-oriented protocol, structured in layers:
- The Application layer combines an Application Service Data Unit (ASDU) with application control information to form an Application Protocol Data Unit (APDU).
- The Transport function breaks the APDU into segments sized to fit within a single link-layer frame (up to roughly 249 data bytes per segment, based on the link layer’s 250-byte data field) and adds a single-byte transport header to each segment for sequencing and reassembly. (Note: this is distinct from the link layer’s own error-checking scheme, which inserts a 16-bit CRC after every 16 bytes of frame data, a different mechanism that’s sometimes confused with transport segmentation).
- The Link layer adds addressing and frame-control information for delivery to a specific destination.
When an application-layer message is larger than a single fragment, it’s broken into multiple fragments; typical maximum fragment sizes fall in the 2,048–4,096 byte range, depending on the receiving device’s buffer capacity.
On serial links, the assembled packet goes directly onto the transport media. On LAN/WAN links, the three DNP3 layers are treated as a single Application layer payload, which is then wrapped in TCP (or UDP) by the transport layer and in IP by the internet layer before hitting the network interface.
Communication
DNP3 defines roughly two dozen application-layer function codes governing how masters (think control center) and outstations (think pump yard) exchange information. Broadly, these fall into a few categories:
- Requesting and receiving status information from an outstation
- Changing an outstation’s configuration
- Controlling the outstation or co-located equipment (for example, operating a breaker)
- Enabling an outstation to send an Unsolicited Response for events like alarms
Most traffic is master-initiated, but because outstations can send Unsolicited Responses, DNP3 supports near-real-time alarm reporting instead of waiting for the next scheduled poll.
Packet Layers
The last section focused on the structure of DNP3 messages and illustrated the first few layers of the message: the Application layer, Transport layer and Link layer. These layers can be mapped to the four-layer model with the Internet Layer omitted. If the serial transport is used, the packet assembly is completed and placed on the transport media for delivery.
If the packet will be sent over a LAN/WAN, the three DNP3 layers are rolled up into the Application layer. The assembled packet is wrapped in the Transport Control Protocol (TCP) by the transport layer, which in turn is wrapped in the Internet Protocol (IP) by the Internet layer. The User Datagram Protocol (UDP) can also be used but presents some additional issues related to reliable delivery in congested networks.
The fourth layer is the Network Interface layer where the assembled packet is actually interfaced to some kind of transport media (for example, twisted pair copper, RG58 co-axial or fiber). While this multi-layer model may seem a bit confusing, it effectively isolates the tasks of communication and ultimately assists in designing and implementing a network.
Traversing the Layers
To illustrate the function of this layered model, let’s look at a single DNP3 Read request over a LAN.
A DNP3 message passes through the protocol layers at both the manager and the agent. Each layer addresses a specific communication task.
The DNP3 master wants to know the current status of the remote’s power and prepares a Read request message for the appropriate object. After passing through all three DNP3 layers, the message is passed to the TCP/UDP Transport layer. The Transport layer adds a data block that identifies the master port from which the request is sent and the port on which it expects the remote DNP3 process to be listening for messages. The packet thus formed is then passed to the IP layer. Here a data block containing the IP and Media Access addresses of the master and the remote is added before the entire assembled packet gets passed to the Network Interface layer. The Network Interface layer verifies media access and availability and places the packet on the media for transmission.
After working its way across bridges and through routers, based on the IP information, the packet finally arrives at the remote. Here it passes through the same four layers in exactly the opposite order as it did at the master. First, it is pulled off the media by the Network Interface layer. After confirming that the packet is intact and valid, the Network Interface layer simply passes it to the IP layer. The IP layer verifies the Media Access and IP address and passes it on to the TCP/UDP layer where the target port is checked for connected applications. If an application is listening at the target port, the packet is passed to the Application layer. If the listening application is the remote DNP3 process, the Read request is passed through its three layers to validate the request and identify what information needs to be collected. The remote response then follows the identical path in reverse to reach the master.
DNP3 Device Browsing
If the communication with the DNP3 station is functional, the D2000 KOM process can provide the list of objects received and their values. In addition, it can send requests for reading of objects to all supported groups. This is useful for configuring I/O tags: just select a specific row from the object list and the appropriate group and index will be inserted into the I/O tag configuration.
The Source column is also displayed, indicating how the value came.
- READ – result of explicit reading
- POLLED – result of response to Poll request
- SPONTANEOUS – spontaneous message via Unsolicited Response (130) function
The implementation continuously updates the Value column so that the user sees the instantaneous values of the objects.
DNP3 Data Encoding and Transmission Rules
Unsolicited Response Limitations
Unsolicited (event-driven) messaging is efficient, but it has a blind spot: there’s no built-in “keep-alive.” A polled protocol will promptly detect a disabled outstation at the next poll cycle. An unsolicited-only setup can’t make that distinction: a silent, failed outstation looks identical to a healthy one with nothing new to report. For that reason, DNP3 masters typically still perform periodic status polling even when unsolicited responses are enabled, so device health can be actively verified rather than assumed.
Security
DNP3 supports Secure Authentication, which uses pre-shared keys (or, in newer implementations, certificate-based authentication) so a master and outstation can verify each other’s identity before privileged operations are permitted.
Outside of Secure Authentication, however, the base DNP3 standard does not include built-in encryption. As with IEC 60870-5, additional protections, such as running DNP3 over TLS, or using bump-in-the-wire encryption for serial links, are typically layered on separately where confidentiality is required.
DNP3 FAQs
Distributed Network Protocol (DNP3) is a communications protocol used in Supervisory Control and Data Acquisition (SCADA) and remote monitoring systems, and is widely used in electric, water and oil and gas utilities.
Unlike traditional master-slave protocols that require extensive bitmapping and constant, aggressive polling, DNP3 uses an open, object-oriented framework. This pre-defined object structure drastically reduces the manual bit-mapping required by integrators. Additionally, DNP3 natively supports event-driven data reporting (unsolicited responses), allowing outstations to report critical data changes only when they happen, rather than waiting to be asked.
DNP3 is primarily designed for serial lines (as well as IEC 101) but is also usable on IP networks when wrapped in TCP or UDP packets.
DNP3 organizes its object library into four distinct data classes to manage network bandwidth effectively:
- Class 0: Static data representing the current, instantaneous state of a point.
- Class 1 (High Priority): Urgent dynamic events and alarms that require immediate transmission.
- Class 2 (Medium Priority): Standard dynamic event data.
- Class 3 (Low Priority): Non-critical or slow-changing dynamic event records. By performing quick class-based polls, a SCADA master can instantly pull high-priority Class 1 events without wasting network bandwidth fetching unchanged static data
To optimize performance over low-bandwidth or high-latency telemetry lines (like radio or cellular links), DNP3 relies on a collapsed version of the OSI model called the Enhanced Performance Architecture (EPA).
The EPA framework utilizes only the Application Layer, the Data Link Layer, and the Physical Layer, along with a subtle, pseudo-transport function that handles the segmentation and reassembly of large data packets. This keeps protocol overhead down to an absolute minimum while maintaining robust error checking.
While DNP3’s unsolicited response feature is highly efficient for remote telemetry, deploying it on a shared multi-drop physical medium (like an RS-485 serial bus) introduces the risk of data collisions. If multiple outstations attempt to spontaneously dump event data onto the wire simultaneously, packets will corrupt. In multi-drop serial topologies, it is typically best practice to limit or disable unsolicited responses and rely on the master’s integrity polling or migrate the network to an Ethernet-based infrastructure.
While both standards serve the electrical utility and SCADA markets, they have distinct structural differences:
- Geographic Dominance: DNP3 is the preferred standard across North American utility networks, while IEC 101 (Serial) and IEC 104 (Ethernet) are primarily deployed in European markets.
- Data Packetization: DNP3 features a pseudo-transport layer that allows it to segment large datasets into sequential frames up to 2,048 bytes. IEC 101 and 104 lack this native segmentation capacity, limiting individual frame sizes to 253 bytes.
- Network Topologies: DNP3 natively supports complex point-to-multipoint networks out of the box using addressing for over 65,000 individual nodes, whereas basic IEC 101/104 implementations are traditionally optimized for point-to-point master-to-remote layouts.
