The DNP3 protocol: advantages for water and wastewater telemetry systems

DNP3, or Distributed Network Protocol, has been around for close to two decades now. It was developed by Westronic in 1993, primarily for the power industry.

From its inception, DNP3 has been an open protocol, allowing end users to use a common protocol across many hardware platforms. It has a number of features and advantages, however, the features described below are particularly useful for water and wastewater applications.

Open protocol

The guardian of the DNP3 protocol is the DNP3 Users Group Technical Committee, which was formed in 1995 and is vendor independent. The committee’s charter not only includes specifying protocol enhancements and new functionality called 'DNP Subset Definitions,' but ensures there is backward compatibility and absolutely makes sure there are no vendor specific variants of the protocol. The firm compliance requirement ensures that hardware and software manufacturers who do support DNP3 do so within very well defined parameters. It should be noted that a vendor need not support all DNP3 protocol functionality. The compliance to DNP3 can be via three different levels - 1, 2 and 3. All vendors who support DNP3 must make available a device profile document that clearly lists the DNP3 features supported by the product and thus the compliance level.

Classification of field data

In a water or wastewater system there are various assets that require monitoring and control. These include treatment plants, pump stations, valve sites, canals, weirs, tanks, ponds, dams, reservoirs, pipelines and much more. At these locations, a great deal of normal day-to-day activity exists. For example, at a pump station, it is very normal for the pump to go ON or OFF when the configured conditions are true or false.

The question is - do you want every event reported to the top end? The answer is no, because this will take up bandwidth and, possibly, prevent information on critical events from getting through to the DNP3 master device.

To prevent this scenario, DNP3 protocol allows users to classify their data into different groups called ‘class’. The protocol currently supports four classes of data - 0, 1, 2 and 3. Class 0 data is real-time data. Classes 1, 2 and are reserved for objects that require timestamp information (event data). Each class of data is independent from the other. A class of data also has variation parameters which allow the user to select the type of value, time and diagnostic information to be recorded.

DNPAI0	IOPOINT_D	Class 1, 32-bit analog input (variation 1) AI Object, Class 1, Static Var. 1 (with flags), Event Var. 3 (with time)
DNPAI1	IOPOINT_D	Class 2, 32-bit analog input without flag (variation 3) AI Object, Class 2, Static Var. 3 (NO flags), Event Var. 1 (NO time)
DNPAI2	IOPOINT_D	Class 0, 32-bit analog input (variation 1)
DNPAO0	IOPOINT_D	Class 0, 32-bit analog output status (variation 1) Analog Output Object, Real Time Data Point (Class 0)
DNPBC0	IOPOINT_D	Class 1, 32-bit binary counter (variation 1) Binary Input Counter
DNPBI0	IOPOINT_B	Class 1, Binary input with status (variation 2) BI Object, Class 1, Static Var. 2 (diagnostic flags), Event Var. 2 (with time)
DNPBI1	IOPOINT_B	Class 0, Single bit binary input (variation 1)
DNPBI2	IOPOINT_B	Class 0, Single bit binary input (variation 1)
DNPBO0	IOPOINT_B	Class 3, Binary output (variation 1) BO Object, Class 3; Static Var. 1 (with flags); Event Var. 1 (NO time)
DNPFC0	IOPOINT_D	Real Time Value (Class 0), Frozen Counter 1
DNPFC1	IOPOINT_D

Table 1: Various DNP3 objects and their different classifications - 0, 1, 2 and 3.

This DNP3 protocol feature is extremely useful, especially in multilayered systems as it allows the user to categorise field data. For example, normal conditions at a pump station site, like pumps starting and stopping, may be configured as Class 2 type events. Thus, when the pump changes state, an event will be created as a Class 2 type event and stored in memory. Since this is normal operation, an unsolicited report (or Report by exception) need not be initiated to a DNP3 master device. When the master device performs a routine background poll, it can recover all Class 2 events.

But assume at the same pump station site there is a pump fault indication. This is, in most cases, a critical alarm of which the DNP3 master needs to be aware, so that appropriate action can be taken. Thus, the pump fault status indication can be configured as a Class 1 event, thereby triggering an unsolicited report to the DNP3 master device.

DNP3 protocol’s fundamental support for data classification allows the end user to design and operate an efficient telemetry system irrespective of the type of communications media being used.

Report by exception (unsolicited reporting)

Report by exception refers to a remote device’s ability to initiate communications to a top-end master. Traditional telemetry systems are typically poll-only systems. In medium-to-large systems, a polling protocol can lead to loss of data. To prevent the loss of data, communications bandwidth would have to be increased constantly.

Taking the example described above, with DNP3 protocol’s inherent support for unsolicited reporting, the pump fault alarm can be sent to the DNP3 master immediately upon occurrence. If the telemetry system were a poll-only system using a different communications protocol, the alarm information would only be seen at the top-end after the outstation has been polled by the master. And even when the master sees the pump fault status indication, it will not have the event timestamp information.

Timestamped data

Timestamped data is also known as event-logged or event-based data. It is, basically, where an event such as a pump changing its status from ON to OFF, or a change in the tank level by a certain percentage within a specified time period, will be recorded in the device with a time and date stamp. Sounds simple … well, it is simple, because the DNP3 protocol specification dictates how the timestamping is to be done and which parameters are to be recorded. This standard has to be maintained by all vendors that claim to support DNP3 protocol.

Figure 1: An example multilayered telemetry system

Having access to time-stamped data for an end user is hugely valuable:

• Many telemetry systems are poll-only systems for a number of reasons - geographical, or by virtue of design, which means that without timestamping, if an event occurs and the device is not polled at that instant in time, the event will be lost. Now, an event like a change of pump status can be stored as the number of times the pump has come ON and the number of times the pump has gone to the OFF state. This is useful information, but it does not provide the time the pumps went ON and OFF. The time information is useful for analysis such as the times during the day the pumps start.
• In the event of a communications failure, a device can continue to record the events and store them in memory. Once the communication system has recovered, a top-end master will be able to retrieve these events and graphically display, accurately, the events that occurred during the communications failure.

Time synchronisation

The DNP3 protocol supports time synchronisation. A DNP3 outstation device can be configured to send a time sync request to the master or a DNP3 master can periodically send a time sync command to DNP3 outstation devices. Time sync is part of the DNP3 protocol specification. Key advantages of the time sync function include:

• Accurate and reliable time-based alarm information from a remote device.
• Scheduling accuracy - for example, when to switch over from duty to standby pump; generate test unsolicited messages at a particular time.

Secure authentication

As critical infrastructure, water and wastewater systems must be secured. There have also been a few well publicised and documented instances of SCADA security breaches that have affected the performance of the systems.

The DNP3 protocol includes IEC62351 version 2 authentication. DNP3 secure authentication allows a DNP3 slave or master device to unambiguously determine if it is communicating with the correct DNP3 master or slave.

In water and wastewater systems it is common to issue pump/valve (or similar) operate commands from the top-end master. Without authentication, it is completely possible for someone to intercept a message and relay with modified settings. DNP3 Secure Authentication overcomes this issue, as the DNP3 outstation challenges the DNP3 master to see if the command to operate comes from a legitimate source. The authentication key is updated regularly between a DNP3 master and outstation. This communication is separate and not part of standard DNP3 data transfer messages. If an outstation does not receive an updated key within a specified period of time, or if the key is invalid, then the control commands from the DNP3 Master, even if valid, will not be executed by the outstation device.

The DNP3 protocol also uses a more basic form to ensure control commands are executed correctly. This is called 'select-before-operate.' In this case, a DNP3 Master will first send a 'select' command, to which the outstation device will respond, and then, if the outstation device does not receive the 'operate' command within a specified amount of time, it will not execute the control action.

Figure 2: DNP3 Secure Authentication using dynamic keys, that are updated, automatically and periodically, between a DNP3 Master and outstation RTU.

Diagnostic information for each I/O point

Another inherent feature of the DNP3 protocol is associating diagnostic information for each field object - whether it’s pump status, tank level, current flow rate, etc.

The diagnostic information answers questions such as, is the point online or offline, was it locally forced, chatter-detected, has it been restarted, is the value out of range and much more.

Again, in typical systems, a status indication for a pump will only show it is ON or OFF, in FAULT, or OK. But when using DNP3 protocol, one can detect if the information regarding the status of the pump is coming from the correct location. This is useful because, remotely, one can tell if wiring is correct. Another example is if the chatter filter bit is SET, then if a field device is going ON/OFF continuously, spurious event logs will not be created.

Communication to multiple masters

This is a particularly useful feature, especially in water and wastewater systems, since it is typical for a water or wastewater telemetry system to be spread over large areas. This is especially true in countries like the US, Australia, China and Brazil. When systems are spread over a large area, it is important for the local operators of the telemetry system to know what is happening, as it will allow them to respond quickly. At the same time, the same data needs to be made available at the system-wide, top-end DNP3 master.

Figure 3: A DNP3 outstation device communicating with several DNP3 master devices.

Advanced communications features for DNP3-based telemetry systems

As stated above, one of the cornerstones of DNP3 protocol is that it is an open protocol with no vendor-dependent variations. Any RTU that claims to support DNP3 protocol must adhere strictly to this rule.

However, the more capable and advanced RTUs have managed to include additional features that do not relate to the actual protocol features/properties or the manner in which DNP3 data in a message is transferred. These additional features focus on the communications itself, which is, getting data from one location to another, effectively and efficiently.

• Peer-to-peer communications: This allows for local communications between two DNP3 devices. If communications to a top-end DNP3 SCADA master is lost, then local RTU systems (like a booster pump station and tank) can continue to operate with all data logged.
• DNP3 message pass-through: The DNP3 protocol is primarily a point-to-point protocol. Point-to-point type communication architecture is not always feasible in a water and wastewater telemetry system. As such, the more advanced RTUs have the ability to receive a DNP3 message on one port and resend via a second port, allowing for more advanced communication options.
• Data concentration: In a multilayered telemetry system, there are inevitably going to be sub-master RTUs. DNP3 does not have the ability to request local and outstation data from a single RTU. As such, a submaster RTU would have the ability to map data received from an outstation DNP3 device to a new DNP3 object (address), while maintaining all of the original values and properties as provided by the outstation RTU.

Conclusion

DNP3 is a modern, robust, intelligent and truly open protocol. While it has been around for close to two decades now, and thus a truly tried and tested protocol, it is still an evolving protocol. This is illustrated by the addition of secure authentication.

A water and wastewater telemetry system is a complex system with a number of assets and locations to monitor and control. From a communications perspective, it can be a multilayered system using a variety of communications media such as radio, cellular, PSTN and fibre to interconnect sites.

The DNP3 protocol, with its many features, helps enormously in implementing such a complex system and it does help in reducing the complexity of a system. This in turn will help reduce operational and maintenance costs for the end user.