DNP3 Slave

Try out the online RTU configurator. It calculates it all, even the power consumption so you dont have to worry about it. Get a complete BOM list, and never forget anything.

Whats not to like 🙂

DNP3 Protocol is used in utility industry SCADA systems because of its vendor independence, range of data transfer methods and ability to ensure data security through use of time stamped events, data priority and data quality. The Brodersen implementation of DNP3 slave protocol is developed and tested using the latest Triangle MicroWorks code libraries and tools to ensure conformance and interoperability.

DNP3 Slave – Object/Data Types

There are six DNP3 object types that include; Analog In, Analog Out, Binary In, Binary Out, Counters and Strings.

Each DNP3 point has a range of object variations eg. 16bit and 32bit integers, 32bit and 64bit floats, with/without time stamps and with/without point quality information that includes on line, forced, out of range and comms lost status flags. Status flags are able to be mapped directly from points on RTU32M I/O modules directly to DNP points ie. remove the module from the backplane and all points associated to that module will have their ‘comms lost’ DNP point status flags set.

DNP3 Slave – Data Transfer Methods

There are four data transfer methods used to move data in a DNP3 network.

1– Polled. Master requests static data values (after restart and less frequently).
2 – Exception Reporting. Master requests event data ie. what has changed since I called you last?
3 – Unsolicited Response. Slave RTU sends unread events to the master (because of their age, number of events and/or priority).
4 – Peer to Peer. Slave RTUs can also send and request a range of static data values from each other (independent of the master).

Setup of the DNP3 slave in a Brodersen RTU is in two parts.

First, the application layer settings (default point variations, event buffer sizes, event reporting rules, device attributes etc), channel (serial, TCP or UDP) and session (slave and master address) are defined using the fieldbus configurator.

Second, the RTU variables that need to be ‘exposed’ as DNP3 slave points are dragged in to the Profile Editor where they can be associated to the required DNP object type, point address, event class (0, 1, 2, 3), static variation (eg. 32bit float with status information), event variation (with/without timestamp), threshold mode/value (how much an analog value must change), debounce on/off period (how long must a digital be changed) and reference to one or master RTUs (a point can reference one/all sessions).

The logic application is able to interact with the DNP3 points

The pictures below show examples of function blocks that can be used to monitor the status of unread events (by point class and object type), get and set data values, interact with point quality, timestamps, message header etc.

Internal DNP3 Slave Setup – allows ‘unique’ RTU configuration

Internal DNP3 slave setup means that all of the DNP3 application layer and point setup information is ‘inside’ the RTU logic application ie. if you want to change the size of the class 2 event buffer, or the class of a point, you need to use the WorkSuite logic tools to edit the logic and download an updated logic file.

External DNP3 Slave Setup – allows ‘host managed’ RTU configuration

Large utility companies with many RTUs to manage typically avoid having unique logic applications in each RTU – they prefer instead to have a common logic configuration and manage the unique requirements of each site using external configuration files (that are exported/sync’d with their host database) ie. the DNP point/RTU setup is ‘outside’ of the logic application.

The Brodersen DNP3 slave implementation allows multiple ways to achieve external setup – host managed (transferring textual configuration files from the SCADA host) and via the RTU web interface (user can set slave address, size of event buffers etc).

Host Managed (All Setup) – use of DNP file transfer (or Secure SFTP) allows the SCADA host to send configuration files to the RTU that may contain full/partial lists of point configuration information (point name, point number, point class, reporting limits etc) and RTU configuration information (slave address, application layer settings such as event buffer size, event quantity and delay period before initiating an unsolicited response etc). The RTU uses logic function blocks to detect the presence of new configuration files and parses the files to create/modify the complete DNP3 setup.

Host Managed (Partial) – a less complicated alternative. Some users do not need/want all of the slave configuration to be managed by the SCADA host ie. they may prefer to have all of the points defined in the logic application and only pass parameters to the RTU that update point attributes such as event class, thresholds etc. They may include/exclude portions of the setup, as required.

Web Interface (Partial) – the RTU web interface controls whether the RTU uses the web page setup or logic settings for Link Settings (master and slave addresses), Connection Settings (TCP/UDP IP port or serial port settings), and a subset of the Application Layer Settings (site details, event buffer sizes and unsolicited response reporting rules).

This makes it easier to manage and deploy RTUs in systems where sites may have a mix of common/unique logic applications eg. all pump stations run the same logic application, so the web interface is sufficient for setup of the few/unique site parameters such as DNP slave address, site name etc.