The DNP3 protocol is commonly used in water/wastewater and other utilities related industries. It's common for RTUs used in these industries to support both DNP3 and Modbus (and possibly other communications protocols). DNP3 has many features compared to Modbus (and other more traditional protocols) that make it desirable for such remote telemetry applications including buffered event history and unsolicited (or Report-By-Exception).
But if you're new to working with DNP3 (it's common for users in such industries to be quite familiar with Modbus but not so familiar with the quirks of DNP3), it's important to understand how differently it behaves with respect to polling frequency, polling composition and considerations when configuring the DNP3 outstation/device itself.
Continuing our Tech Support Corner blog series, this post discusses what drives the polling behavior for DNP3 drivers in TOP Server and how the configuration on the device itself can impact what data is returned when a poll is issued.
So in this post, we'll focus on a few key differences related to polling specifically between DNP3 and a more traditional driver like Modbus. While we can't focus on all of the deep functions available with DNP3 in this post, we'll discus the following with the goal of a basic understanding to help if you're new to DNP3:
- DNP3 Class and Integrity Polling
- DNP3 Explicit Reads
- DNP3 Buffered Events Playback
- DNP3 Unsolicited (Report-By-Exception or RBE)
How Does DNP3 Class and Integrity Polling Differ from Other Drivers?
So, if you're familiar with Modbus or other traditional polling drivers in TOP Server, you may be aware that it is the client application (your HMI, SCADA or other application needing the data that is being requested) that causes TOP Server to send requests to your devices (this default behavior can be modified, though, using the TOP Server device-level Scan Modes or if you're using the TOP Server Scheduler plug-in). The client update rate determines the frequency of those device requests, as well as, which actual data items/points/tags get requested from the device.
With DNP3, however, polling of the device is completely decoupled from that client update rate. DNP3 defines the following types of polling:
- DNP3 Class Polls - There are 3 different classes that the TOP Server DNP3 drivers can request - Classes 1, 2 and 3. Each has a separately configured Class Poll Interval defined in TOP Server for each device. Classes are configured in the device/outstation with respect to which DNP3 points/items are assigned to each Class.
- DNP3 Integrity Polls - Integrity Polls return Classes 0, 1, 2 and 3 (with Class 0 being current/static values for the points defined in all classes).
Class and Integrity poll intervals determine the frequency that TOP Server requests any and all points assigned to those Classes in the devices. The client update rate has NOTHING to do with that polling frequency. Any addresses requested by TOP Server with a .Value sub-type (there is also a .Explicit sub-type, which we'll get to shortly) will be updated by those Class and/or Integrity Polls of the driver.
The Class and/or Integrity Polls update the TOP Server cache (based on the polling intervals defined in the device properties) and any connected client applications read from that cache at the requested update rate since the requested updated rate does not drive polling frequency.
Another important difference is that Class and Integrity Poll requests by TOP Server do NOT actually request specific points/items/tags. A Class 1 Poll, for instance, literally just asks the DNP3 outstation/device for all Class 1 data. Which points are actually returned in the Class 1 Poll response fully depends on how the outstation/device has been configured (it has nothing to do with which points/items/tags your client is requesting).
As such, if your outstation/device has no points assigned to Classes 1, 2 or 3, then only an Integrity Poll will actually update the points/items/tags requested by your client application (and only with the static/current value). So it's important to carefully assign only the points you actually need/want to each Class to avoid Class Polls returning points that aren't required each time.
Additionally, even if you have points assigned to one or more Classes, if a point's Online state is set to Offline, it won't be available for DNP3 Client drivers like TOP Server to receive updates. So you can see that how the outstation/device is configure has a large impact on how TOP Server can access the points in that device.
What are DNP3 Explicit Reads?
So earlier, I mentioned the .Explicit sub-type for a DNP3 point (as opposed to .Value). Points being referenced using that sub-type actually will be polled in similar fashion to Modbus - the client update rate will determine the polling frequency of those items and those .Explicit points will be blocked together in Explicit read requests rather than the more efficient use of Class Polling.
While TOP Server supports Explicit Reads for DNP3, it's important to understand that this is a less efficient means of DNP3 communication and should only be used if absolutely necessary (i.e. in situations where you need the client to have the ability to explicitly demand reads from the device, for instance).
What are DNP3 Buffered Events?
A concept that is unique to DNP3 when compared to Modbus are DNP3 Buffered Events. As part of the configuration of the DNP3 outstation/device, it is typically possible to enable event buffering for the points in the different Classes such that a specified number of value changes with timestamp for each point are stored in the outstation's buffer.
This can be enabled or disabled in TOP Server for each device, depending on whether the device has this enabled and whether or not you want to consume those buffered events. When enabled in TOP Server, it's important to understand how that affects the current value displayed for your items in a client application.
When enabled, Buffered Events are played back to your client applications accessing the .Value sub-type of those points and those Buffered Events are retried with Class Polls. The value and timestamp of each buffered event are played back to your client (your client will see these as live values).
The playback rate is configured for each device in TOP Server and should always be half the speed of the update rate requested by your client application to ensure no values are missed (for instance, if your client application is requesting an update rate of 1000 ms, your Playback Rate for DNP3 Events in TOP Server for that device should be no faster than 2000 ms).
And you also configured the Max Events Per Point which determines how many events are requested for each point, so if there are more events than the specified amount in the device only the most current events up to that number will be requested (for instance, if this is set to 10,000 in TOP Server but the device has 11,000 events for a point in its buffer, then the oldest 1,000 events wouldn't be requested).
It's important to understand that, with Buffered Events enabled in TOP Server, your .Value items won't display the actual current value (it will be a buffered event) so Buffered Events should only be enabled if preservation of historical data is more important than visualization of the current values.
What is DNP3 Unsolicited Mode?
Another configurable option that is unique to DNP3 when compared to Modbus is DNP3 Unsolicited Mode. This can generally be turned on or off by Class in the DNP3 outstation/device. It's entirely possible to have your DNP3 outstation configured to use Unsolicited or Report-By-Exception updates for all points in all classes and to have Class Polling turned off in TOP Server (you can turn off polling for any Class or for Integrity polls by simply setting the Poll Interval to 0 in TOP Server) such that .Value sub-types are only ever updated by unsolicited updates.
Essentially, the device will send updates as they occur, eliminating the need to periodically send Class Poll requests that may or may not returned changed data. This is the most efficient method of communication, when possible. It's not uncommon to rely on unsolicited mode with a periodic Integrity Poll.
By default, TOP Server has Unsolicited Mode set to "Automatic" for all three classes, meaning TOP Server will confirm with the DNP3 outstation/device whether or not the device has unsolicited mode enabled - if it does, it will also be enabled in TOP Server. If it does not, then it will be disabled in TOP Server. This is best if you're not sure whether or not your DNP3 outstation/device has unsolicited mode enabled or not.
Now there are certainly many more differences between DNP3 and other communications protocols but these are the most common with respect solely to polling behavior. Hopefully this post provides you with a basic understanding to help you get started with DNP3 communications with your outstation devices.
If you have questions or need further guidance, we suggest you start with our DNP3 Best Practices Guide as a great place to get started. And as always, please feel free to contact our team to discuss your project needs and determine whether we have the right solution for you.
And don't forget to subscribe to our blog to find out about the latest updates to TOP Server and for other useful tutorials and resources.
Ready to put try out TOP Server for integrating your DNP3 outstation devices?
