DNP3: what happens when a remote site loses its connection?

A healthy reading after a communications outage does not tell you whether the equipment stayed healthy throughout it. DNP3 (Distributed Network Protocol 3) addresses that problem by supporting current values and recorded events between field equipment and a control centre. It is an open telecontrol protocol standardized under IEEE 1815, used in power networks, substations, water systems and other SCADA applications.

With suitable configuration and available buffer space, a field device can retain changes while its link is down and report them later. The useful question is therefore “Can we reconstruct what happened?”, as well as “Can we read the value?” That distinction matters when planning industrial communications across remote sites.

Who talks to whom?

The master is the control-centre side that requests information and issues commands. It may run on a SCADA server or an industrial PC. An outstation is the field-side endpoint supplying measurements and events. An RTU, IED or PLC can serve as an outstation if it implements DNP3. RTU means remote terminal unit; IED means intelligent electronic device.

A physical RTU is a different concept from the RTU encoding named in Modbus RTU. Likewise, remote I/O hardware is not automatically a DNP3 outstation. Check its supported protocols. The relationship between PLC control and SCADA supervision also matters: deciding where control runs is separate from deciding how the centre receives information.

Start with a point list, not just an address

DNP3 represents information using typed data objects. Binary inputs describe two-state indications; analog inputs carry measurements such as pressure or current; counters report accumulated counts. Supported binary and analog output objects handle control operations and setpoints.

A usable point list identifies the point index, object group, variation, units, scaling and quality information. For example, Group 30 identifies static analog inputs, while the variation specifies their representation. A working connection is not proof that the displayed number has the correct units or scale.

A current value can hide an entire alarm

Static data means the present value; it does not mean a value that never changes. Event data reports changes or other configured occurrences. Consider a remote alarm where 0 means normal and 1 means alarm. This example assumes event generation and timestamps are enabled, with enough buffer capacity.

Reading only the latest value would miss the alarm. The event history distinguishes “normal now” from “normal throughout the outage”. However, event buffers are finite. Overflow can lose records, and retention across a restart depends on the device implementation. Treat buffering as a communications feature, rather than a replacement for a data logger or a long-term archive.

Classes, polling and unsolicited reporting

Class 0 is used for static data. Classes 1, 2 and 3 organize events. They are not universally fixed alarm priorities: the standard does not require Class 1 to mean “critical.” Agree on class assignments when configuring the system.

With polling, the master requests data. With unsolicited responses enabled, an outstation can send an event report without waiting for a separate data request. Both endpoints must agree on enabled classes, confirmations and retry behaviour. Unsolicited reporting does not remove every need for periodic polling. On a shared half-duplex serial bus, assess contention before enabling spontaneous reports.

Event time is not arrival time

The time an event occurred can differ substantially from the time SCADA received it. DNP3 provides event variations with and without timestamps; g2v2, for example, carries binary input events with time. Validate the outstation clock and synchronization status before relying on timestamps to reconstruct a sequence.

For analog measurements, a configured deadband limits event generation from small changes. Too little deadband can consume bandwidth and buffer space; too much can hide useful changes. Choose it against the measurement units and the purpose of real-time data monitoring.

How does DNP3 compare with Modbus?

A Modbus device can still maintain an event archive and expose it through manufacturer-specific mappings. Choose by required functions and actual endpoint support. Our Modbus communication guide and Modbus FAQ cover the alternative. DNP3 also serves a different purpose from EtherCAT networks used for precise cyclic control; it is not a substitute for that motion-control role.

Keep the addressing layers separate

DNP3 can operate over supported serial links or IP networks. Ethernet, IP and TCP/UDP describe different layers. IANA registers port 20000 for DNP over TCP and UDP; check the actual endpoint settings rather than assuming the registered port is always used.

An IP address, transport port, DNP3 link address and point index identify different things. An open communication port will not fix mismatched station addresses or an incorrect point map.

Control operations and security

Select Before Operate (SBO) uses a selection followed by an operate request within a configured time window. Direct Operate omits the separate selection. Neither approach provides encryption. Assess command responses alongside actual equipment feedback, rather than treating a protocol reply as the whole outcome.

CRC error detection is not cryptographic authentication. DNP3 Secure Authentication, particularly SAv5, authenticates critical operations and protects their integrity; it does not encrypt message contents. Supported TLS or VPN protections address confidentiality separately.

Newer DNP3 Security Layer (DNP3-SL) work includes encryption support. That does not make encryption a feature of every installed DNP3 device. Verify versions, firmware and compatible security capabilities at both ends. Industrial cybersecurity and Ethernet network security also require appropriate access permissions and key management.