DNP3

A Little History

The DNP3 protocol was developed in 1990 by Westronic (now GE Harris) and published in 1993. At that time, the development of IEC 60870-5 standards was all the rage, the most well-known were the IEC 60870-5-101 for point-to-point master-slave serial link communication and the IEC 60870-5-104 for TCP networks. Before the IEC 60870-5 standardization was completed, DNP3 became particularly popular in the United States and Asia, but less popular in Europe, which largely used IEC 60870-5.

Object Model

DNP3 is based on an Object Model. This model reduces the bit mapping of data that is traditionally required by other less object-oriented protocols. It also reduces the wide disparity of status monitoring and control paradigms generally found in protocols that provide virtually no pre-defined objects.

Purists of these alternate protocols would insist that any required object can be ‘built’ from existing objects. Having some pre-defined objects, though, makes DNP3 a somewhat more comfortable design and deployment framework for SCADA engineers and technicians.

Master/Remote Model

DNP3 is typically used between centrally located masters and distributed remotes. The master provides the interface between the human network manager and the monitoring system. The remote (RTUs and intelligent electronic devices) provides the interface between the master and the physical device(s) being monitored and/or controlled.

The master and remote both use a library of common objects to exchange information. The DNP3 protocol contains carefully designed capabilities. These capabilities enable it to be used reliably even over media that may be subject to noisy interference.

The DNP3 protocol is a polled protocol. When the master station connects to a remote, an integrity poll is performed. Integrity polls are important for DNP3 addressing because they return all buffered values for a data point and include the current value of the point as well.

A typical DNP3 master/remote monitoring system architecture.

Main Capabilities

As an intelligent and robust SCADA protocol, DNP3 gives you many capabilities.

• DNP3 can request and respond with multiple data types in single messages
• Response without request (unsolicited messages)
• It allows multiple masters and peer-to-peer operations
• It supports time synchronization and a standard time format
• It includes only changed data in response messages

Medium

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. As for IEC standards, IEC 101 is used wrapped in UDP or TCP (for example, by conversion using Moxa NPort serial servers) and IEC 104 is directly designed for TCP networks.

DNP3 implementation in D2000 COM process supports the following types of lines.

• Serial
• Serial over UDP (used with Moxa NPort serial servers in UDP mode)
• MOXA IP Serial Library (used with Moxa NPort serial servers with manufacturer’s communication library)
• TCP/IP-TCP (DNP3 wrapped in TCP)
• TCP/IP-UDP (DNP3 in UDP packets)

Number of Devices

DNP3 protocol can be used in point-to-point and point-to-multipoint communications (e.g., RS-485 bus) with one master station (mostly SCADA) and multiple slave stations (in DNP3 terminology they are called outstation and are PLC, RTU or other IEDs – Intelligent Electronic Devices). Note: DNP3 supports sending spontaneous changes by outstations by using the Unsolicited Response (130) application function. If there are multiple stations on the bus, there may be collisions when using this functionality.

Both master and slave stations are identified by a 2-byte number from 0-65,519. Higher addresses are reserved for broadcasts, for “self-address” or for future extensions.

Both IEC-101 and IEC-104 protocols are for point-to-point communication only – one master, one slave. There is a so-called “Common address of ASDU” that maps to a station address (1 or 2 bytes for IEC-101 and 2 bytes for IEC-104) in D2000.

Communication

DNP3 uses 27 basic function codes to exchange information between masters (think control center) and remotes (think pump yard). Some of those function codes enable a master to request and receive status information from a remote. Other function codes enable a master to determine or adjust the configuration of a remote.

Several function codes are defined for a DNP3 master to control the remote itself or equipment co-located with the remote. One function code is provided to enable the remote to respond autonomously with an Unsolicited Message to particular events that occur in its installation space. Here are examples of what function codes can enable.

• Master to request and receive status info from a remote
• Master to change a remote’s settings
• Master to control the remote
• Remote to send an unsolicited response about particular events that occur in its area

As you can see, most of the messages are issued by the DNP3 master to the DNP3 remote. However, because the Unsolicited Message is capable of being initiated by a remote, it is typically used to report alarms. This notifies the DNP3 master as soon as an alarm condition occurs, instead of waiting for the next request.

Unsolicited Response Limitations

Be sure you understand the key limitation of all unsolicited (“asynchronous”) alerts: there’s no “keep alive” function. For polled (“synchronous”) protocols, the manager polls the agent. This guarantees that a disabled agent will be promptly identified at the next polling cycle.

Contrast this with what happens in an unsolicited-message protocol: a disabled agent remains silent. This silence is identical to an active agent reporting that “I have no problems right now.” That’s why, whenever possible, you should look for a DNP3 master that has some ability to routinely query agents for their status. This mitigates one of the major threats from using DNP3.

Object Classes

DNP3 protocol allows you to include objects in one of four classes.

• Class 0 – static data (objects whose changes are not recorded)
• Class 1 – dynamic data, priority 1 (usually high)
• Class 2 – dynamic data, priority 2 (usually middle)
• Class 3 – dynamic data, priority 3 (usually low)

According to the standard, the request for reading (so-called Poll request) data from Class 0 returns the current values for objects from all Class 0-3 classes. Request for data from Class 1-3 returns events (value changes) of the appropriate class.

Therefore, in the implementation of DNP3, we supported four station parameters to independently configure four types of Poll requests. For example, in a particular configuration, a Poll request for Class 1-3 can be generated every 10 seconds and a so-called “integrity poll” – Poll request for Class 0, returning the current values of objects in all Classes 0-3, once every 10 minutes.

Both IEC-101 and IEC-104 protocols allow to assign objects to as many as 16 groups and counters to another 4 groups. In practice, it was so far sufficient for us to send a general “station interrogation” to find out the current values of all objects when establishing a connection. Subsequently, only changes are transmitted.

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.

Message Structure

Basic serial telemetry protocols, like TBOS, are byte-oriented, with a single byte exchanged to communicate. Expanded serial telemetry protocols, like TABS, are packet oriented with packets of bytes exchanged to communicate. The packets contain a header, data and checksum bytes. DNP3 is also packet oriented and uses the packet structure (element sizes in bits) shown in the illustrated figure below.

DNP3 Packet Structure

The master sends a Read request for an object or objects and the remote’s response contains the requested information if available. The master sends an Operate command to produce the output actions associated with the selected object reference. The remote sends an Unsolicited Message when a specific event occurs.

The preceding figure shows the message packet format. The DNP3 application service data unit (ASDU) is worthy of special note for the clever content adjustment that is controlled by the qualifier and index size fields. This design makes application data available in an impressively flexible number of configurations or omitted all together if desired.

Packet Layers

The last section focused on the structure of DNP3 messages and illustrated the first few layers of the message. The Application layer combines an ASDU, a packaged object in itself, with an application protocol control info (APCI) block to make an application protocol data unit (APDU). The Transport layer breaks the APDU into segments with a maximum size of 16 bytes and packages them with an 8-bit transport control header and 16-bit segment CRC separators into a Transport Frame. The Link layer adds a header the control and addressing information to prepare the packet for delivery to a specific destination. 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.

DNP3 Packet Structure

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.

Security

DNP3 supports Secure Authentication using a key pre-shared by both parties. This allows the master to verify that it is actually communicating with a particular outstation and the outstation can verify that the master is authorized to use the services of outstation. If the master requests the functionality that the outstation considers privileged, the outstation will initiate identity verification.

Besides secure authentication, the DNP3 protocol does not implement data encryption or other security features, IEC protocols have no built-in security, and secure authentication is currently not supported in D2000 KOM process.

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.

Conclusion

Its greater variability and expression abilities make it worth investigating. In other respects, (for example, for oversized data consistency control or complications with pseudo-transport layer), the design of IEC protocols may be more beneficial. However, for deploying the D2000 outside Europe, DNP3 support is imperative.