Approximately since the end of February, I was working on implementation of the DNP3 protocol into the Ipesoft D2000 real-time application server. So what can DNP3 do, what can it be used for and what are its advantages and disadvantages?
DNP3 stands for Distributed Network Protocol, version 3. Despite its lavish name, it is basically a standard master-slave protocol used in control systems and automation.
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 (the most well-known of which are IEC 60870-5-101 for point-to-point master-slave serial link communication and 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. In Europe, IEC 60870-5 is largely used. But for example, Simatic S7 supports DNP3. Similar to Rockwell ControlLogix or Modicon M340. Beware- support is mostly through physical communication modules or communication processors that need to be purchased and connected to the PLC.
So - what's so interesting about DNP3? I will try to mention some features and compare them with the IEC 60870-5-101 and IEC 60870-5-104 protocols.
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.
Pseudo-transport layer
The DNP3 protocol is able to transfer large messages - its so-called pseudo-transport layer divides them into frames with a maximum of 249 data bytes. According to the standard, a device must be able to limit the size of messages to a maximum of 2048 bytes in order not to overwhelm the buffers of a less powerful partner.
The IEC-101 and IEC-104 protocols do not have similar capabilities since only one byte is reserved for data size and each frame can contain not more than 253 bytes. So the demands for processing such messages are lower.
Data model
DNP3 defines groups of objects defined by a 1-byte group number, e.g. Binary Input (1), Binary Input Event (2), Double-bit Binary Input (3), ..
Within a group, the object is identified by an index. An index is a non-negative number, depending on its size it can be transmitted as a 1, 2, or 4-byte number.
Each group of objects has several formats called Variations. For example, Counter (20) group has variations:
· 32-bit with flag (1)
· 16-bit with flag (2)
· 32-bit with flag, delta (obsolete) (3)
· 16-bit with flag, delta (obsolete) (4)
· 32-bit without flag (5)
· 16-bit without flag (6)
· 32-bit without flag, delta (obsolete) (7)
· 16-bit without flag, delta (obsolete) (8)
Some object groups are used to read values, others to write them. In addition, beside "value groups", there are "event groups" that are used to transfer changes of values. For example, the variations of the Counter (20) group are used in requests to read objects from this group, but the variations of the Counter Event (22) group are used in reports of spontaneous value changes - the above-mentioned Unsolicited Response (130) messages as well as replies for reading values of the whole class of objects (polling, see below).
With explicit reading, the master can request a specific variation within the group. If it uses variation 0, it means that it does not have the preferred format and leaves it to be selected by the outstation.
How about IEC protocols?
Object addresses (mapped to I/O tag addresses in D2000) are 1-3 bytes for IEC-101 and 3 bytes for IEC-104.
Both IEC-101 and IEC-104 are more „modest“ in value representation — they define Application Service Data Unit (ASDU) types only depending on their numerical characteristics. For value transfer, they define a set of ASDUs without timestamps (single point, double point, 32-bit floating number, 32-bit bitstring, and others) and another set with a short timestamp (milliseconds to minutes within hour) and yet another set with a long timestamp (milliseconds to years within a century). In addition, they have two similar sets of ASDUs for commands (single command, double command, 32-bit floating point set, 32-bit bitstring) - this time without a timestamp and with a long timestamp.
From this perspective, DNP3 is more implementation-demanding; on the other hand, I like that it also provides variations for 64-bit values (both integer and floating point) that we missed in practice in the IEC-104 protocol (so we implemented them beyond the standard - see ASDU 241 and 243 in IEC 60870-5-104).
A short note abou strings - IEC protocols have no ASDU type usable for transfer of strings. DNP3 has an Octet String (110) group that can transfer byte strings of up to 255 bytes in length.
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.
Communication - request-response and others
DNP3 therefore supports sending Poll requests to individual classes. But at the same time, the standard says that some objects may not be included in any class - so the protocol must also support explicit querying of values.
In order to set the individual period for generating read requests for various objects in the D2000, you can specify the Read Period parameter in the I/O tag configuration. If the parameter is not specified, the time parameters configured on the station that is the parent of the I/O tag are applied.
In addition to the group and variation, the range of objects (parameter Range) can be specified in the read request. It is possible to read a particular object, range (by specifying 1, 2 or 4-byte From/To identifiers), or use the No range option to read all objects of the selected group. This feature of DNP3 protocol allows you to optimize the number of read requests. The values of the objects that come in the response will be written to the I/O tags based on the match of Group+Index parameters.
The third method of communication is to send changes of values by the outstation spontaneously, i.e. without a request from the master – using the Unsolicited Response (130) function mentioned above. This method is suitable where a full-duplex line is available and only one outstation communicates, or the communication is "intermittent". Otherwise, there would be collisions between spontaneous messages and messages from another substation or master station.
In addition, each DNP3 protocol response includes a 16-bit Internal indications field, which informs the master not only of the request result but also of the station's status. Three of these attributes indicate that Class 1-3 events are available and can be read by the appropriate Poll request. D2000 KOM process automatically generates Poll requests (even outside configured periodicity) when receiving such indications.
The IEC-101 and IEC-104 protocols do not have such abundant capabilities – they can manage with the aforementioned "interrogation" mechanism to request the values of all objects, and afterwards only the changes are transmitted.
Robustness
The DNP3 protocol is designed also for environment with a high level of interference. It implements separate polynomial CRC checks for both header and data, splitting data into 16-byte packages, each of which has a separate CRC safeguard.
I can say that DNP3 has the most thorough integrity check of all the protocols I have implemented or met. This fact makes me very suspicious of the quality of serial lines in the US...
But this is not all about the robustness of DNP3. In addition to the simple Write function (returning only the Internal indications field), it also offers a safe sequence of Select + Operate functions. The response to each of the requests contains all request data (group, index, written value) so that the master can double-check that his command has gone undamaged there and back. The slave will again execute the command after it receives both Select and Operate requests, and after verifying that the data in them is identical. The probability that a wrong command could be executed due to undetected data corruption on the link is practically zero.
There is also "something between" the Write function and the Select + Operate functions – if a function Direct Operate is used, write is performed immediately and the answer contains all the request data so the master can check it. And finally, there is a Direct Operate Non Return function that performs write and does not return anything (so the master has no information about whether the writing was successful or not).
The IEC-101 and IEC-104 protocols offer roughly equivalent of Direct Operate funcion - write is confirmed by the same ASDU.
As for data consistency control, IEC-101 has a simple byte check sum (sum of data byte values), IEC-104 relies on TCP layer checks.
Time synchronization
DNP3 as well as IEC-101 and IEC-104 have support for synchronization of slave stations by the master. Implementation of these protocols in the D2000 KOM process can synchronize the time of the slave stations - the configuration is standard in the time parameters of the station. As described above, an outstation can indicate that its time needs to be synchronizd using one bit from the Internal indications field.
Security
DNP3 supports Secure Authentication using a key pre-shared by both parties so that:
· the master can verify that it is actually communicating with a particular outstation
· 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.
Secure authentication is currently not supported in D2000 KOM process.
The icing on the cake– 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
DNP3 is the American „cousin“ of IEC-101 and IEC-104 protocols. In some aspects, I like it for its greater variability and expression abilities. In others (for example, for oversized data consistency control or complications with pseudo-transport layer), I prefer the design of IEC protocols. Anyway, for deploying the D2000 outside Europe, DNP3 support is imperative.
Currently, the implementation of DNP3 in the real-time application server D2000 has been completed and testing against two DNP3 software servers has also taken place. The next release (12.1) will already contain this protocol.
