(Distributed Network Protocol) is a set of communications protocols used between components in process automation systems. Its main use is in utilities such as electric and water companies. Usage in other industries is not common, although technically possible. Specifically, it was developed to facilitate communications between various types of data acquisition and control equipment. It plays a crucial role in SCADA systems, where it is used by SCADA Master Stations (Control Centers), Remote Terminal Units (RTUs), and Intelligent Electronic Devices (IEDs). It is used only for communications between a master station and RTUs or IEDs. ICCP, the Inter-Control Centre Protocol, is used for inter-master station communications.

While IEC 60870-5 was still under development and had not been standardized, there was a need to create a standard that would allow interoperability between various vendors SCADA components for the electrical powergrid. Thus, in 1993, GE-Harris Canada used the partially completed IEC 60870-5 protocol specifications as the basis for an open and immediately implementable protocol that specifically catered to North American requirements. The protocol is designed to allow reliable communications in the adverse environments that electric utility automation systems are subjected to, being specifically designed to overcome distortion induced by EMI, aging components (their expected lifetimes may stretch into decades), and poor transmission mediums. The DNP3 protocol is also referenced in IEEE Std. 1379-2000, which recommends a set of best practices for implementing modern SCADA Master-RTU/IED communication links.

Figure 3.21. DNP3 protocol stack

Although the protocol was designed to be reliable, it was not designed to be secure from attacks by hackers and other malevolent forces that could potentially wish to disrupt control systems to disable critical infrastructure. Thus, much work is currently being done to provide security for the systems that use the DNP3 protocol.

DNP3 consists of, in standard networking terms, a layer 7 (application) and a layer 2 (data link) protocol. It provides multiplexing, data fragmentation, error checking, link control, prioritization, and layer 2 addressing services for user data. It makes particularly heavy use of Cyclic Redundancy Checks (CRCs) embedded in its data packets, in an attempt to deal with the very noisy environments in which it is typically used.

Many modern applications can now carry DNP3 messages over TCP/IP.

Figure 3.22. DNP3 architecture

Common DNP3 network architectures are depicted in Figure 3.21, “DNP3 protocol stack”. At the top is a simple one-on-one system having one master station and one outstation deployed on a RS232 physical layer typically over dial-up telephone line. The second figure shows a configuration known as a multi-drop design over RS485 physical layer. One master station communicates with multiple outstation devices with a master-slave polling communication routine.

A DNP3 frame consists of a header and data section. The header specifies the frame size, contains data link control information and identifies the DNP3 source and destination device addresses. The data section contains data or payload passed down from the application layers above.

Figure 3.23. DNP3 data frame

The link layer has the responsibility of making the physical link reliable by providing error detection and duplicate frame detection. The link layer sends and receives frames. A frame begins with two sync bytes that help the receiver determine where the frame begins. The length specifies the number of octets in the remainder of the frame, not including CRC check octets.

The destination address specifies which DNP3 device should process the data, and the source address identifies which DNP3 device sent the message. Having both destination and source addresses satisfies at least one requirement for peer-to-peer communications because the receiver knows where to direct its responses. 65520 individual addresses are available. Every DNP3 device must have a unique address within the collection of devices sending and receiving messages to and from each other. Three destination addresses are reserved by DNP3 to denote a broadcast message; that is, the frame should be processed by all receiving DNP3 devices.

The data payload in the link frame contains a pair of CRC octets for every 16 data octets. This provides high resolution in detecting errors. The maximum number of octets in the data payload is 250, not including CRC octets. The maximum length link layer frame is 292 octets if all the CRC and header octets are counted.

An important feature of DNP3's link layer is the ability for the transmitter of the frame to request the receiver to confirm that the frame arrived. Using this feature is optional, and it is often not employed because there are other methods for confirming receipt of data. It provides an extra degree of assurance of reliable communications. If a confirmation is not received, the link layer may retry the transmission. Some disadvantages to using link layer confirmation are the extra time required for handshaking over slow data links and waiting for multiple timeouts when retries are configured.

The pseudo transport layer (level 7) has the responsibility of breaking long application layer messages into smaller packets sized for the link layer to transmit, and, when receiving, to reassemble frames into longer application layer messages. In DNP3 the transport layer is incorporated into the application layer. The transport layer requires only a single octet of overhead data to perform its duty. The link layer can handle only 250 data octets, and one of those is used for the transport function, each link layer frame can therefore hold as many as 249 application layer octets.

Application layer messages are broken into fragments. Maximum fragment size is determined by the size of the receiving device’s buffer. The normal range is 2048 to 4096 bytes. Fragmenting messages is the responsibility of the application layer. Note that an application layer fragment of size 2048 must be broken into 9 frames by the transport layer, and a fragment size of 4096 needs 17 frames. Communications in noisy environments are more successful if the fragment size is significantly reduced.

The application layer works together with the pseudo transport and link layers to enable reliable communications. It provides standardized functions and data formatting with which the user layer above can interact. The term "static" is used with data and refers to the "current value". Thus static binary input data refers to the present on or off state of a bi-state device. Static analog input data contains the value of an analog at the instant it is transmitted. DNP3 allows requests for some or all of the static data in an outstation device.

DNP3 events are also supported for state changes, values exceeding some threshold, snapshots of varying data, transient data and newly available information. For example, an event is triggered when a binary input changes from an on to an off state or when an analog value changes by more than its configured deadband limit. Events can be generated with and without time stamps so that the master will have the information to generate a time sequence report. The user layer can be configured to request events. Data updates are more rapidly when the master spends most of its time polling for events from the outstation and only occasionally asks for static data as an integrity measure. Updates are faster because the number of events generated between outstation interrogations is small and, therefore less data needs to be send back to the master station. Events are classified into three classes. The user layer can request the application layer to poll for class 1, 2 or 3 events or any combination of them.

DNP3 data is represented in various formats. As an example: analog data can be represented as follows:

The flag referred to is a single octet describing the state or quality of the data i.e. whether the source is on-line, the data source restarted, communications are lost with a downstream source, the data is forced or the value is over range.

Data values are assigning by group numbers. Static analog values are assigned as group 30, and event analog values are assigned as group 32. Static analog values, group 30, can be formatted in one of 6 variations, and event analog values, group 32, can be formatted in one of 8 variations. When an outstation transmits a message containing response data, the message identifies the group number and variation of every value within the message. Group and variation numbers are also assigned for counters, binary inputs, controls and analog outputs. All valid data types and formats are identified by group and variation numbers.

When data from an index is transmitted the sender must encode the information to enable a receiving device to parse and interpret the data. The data for each index appearing in the message are encoded as binary objects i.e. the objects are classified according to the group and variation number chosen. The user layer formulates requests for data from outstations by specifying what function to perform, such as reading, and by specifying the data types required. The user layer specifies the amount of objects required as a range of objects from index number X through index number Y. The application layer then passes the request down through the transport layer to the link layer for transmission to the out stations.

Besides the reading of data the DNP3 protocol is designed to handle other functions. For example: the master can set the time in the outstation, transmit requests for control operations and setting of analog output values.

DNP3 supports slave initiated responses i.e. a slave sends information without being polled for it - also referred to as unsolicited messages. Rather than waiting for a master station polling cycle to get around to it, the outstation simply transmits the change. Before configuring a system for unsolicited messages special attention must be paid to bus contention issues such as the following:

The DNP3 organization recognizes that supporting every feature of DNP3 is not necessary for every device. Some devices are limited in memory and speed and do not need specific features, while other devices must have more advanced features to accomplish their task. DNP3 provides for complexity levels. At the lowest level, level 1, only very basic functions must be provided and all others are optional. Level 2 handles more functions, groups and variations, and level 3 is more sophisticated. Within each level a minimal subset of request formats and response formats is specified.