0. HMI/SCADA to RTU Connectivity for Water & Utilities via DNP 3.0
Using the TOP Server DNP Driver Presenter: Boyce Baine, Sr. Applications Engineer
Welcome to today’s presentation, Connecting Your HMI or SCADA to an RTU via DNP3. My name is Boyce Baine and I’m one of the Applications Engineers here at software toolbox. I will be your presenter today. <CLICK>

1. Agenda Introduction DNP Drivers Overview Q & A & other Resources
What is TOP Server
DNP Drivers Overview
Overview of DNP and how it differs from normal “polling” PLC drivers & protocols
Overview of Driver settings & configuration
Testing your configuration
Q & A & other Resources
Today we will give you a brief overview of TOP Server and the basics of DNP and how it differs from other “polling” drivers. We will then review how to configure the driver and explain what the settings are and how they relate to the DNP protocol. Finally we will take a brief look at testing your configuration and other resources we offer before opening up for your questions.

2. What is TOP Server?
First, for those of you who may not have seen or used TOP Server previously, TOP Server is a Data Acquistion or I/O Server. (click)
It allows your Client Software connect using OPC DA, Suitelink, iFix native interface or DDE. These can be used individually or in combination (click)
so all of these different types of Clients can get the data they need. (Click)
The TOP Server driver plug-ins let you gather data though over a 100 different protocols depending on the licenses you have, giving you an enormous number of potential data sources. (Click)

3. TOP Server Gets You Connected!
This is a partial listing of the drivers and driver suites available for TOP Server. The complete listing of drivers and suites can be found at the url on the screen or by <Click>
clicking on the Drivers List tab at the toolboxopc.com website. Just click on the link to get all the detailed information about the item for which you are interested . <Click>

4. What is DNP and Who Uses It?
DNP3 (Distributed Network Protocol) is a set of communications protocols used between components in process automation systems
It is primarily used for communications between a master station and RTUs or IEDs.
Originally designed for power distribution and transmission, DNP has found a home in water/wastewater, oil/gas and transportation.
The DNP3 protocol, first developed by GE Harris in 1993, was a comprehensive effort to achieve open, standards-based interoperability between master stations and substation computers, RTUs, and IEDs (Intelligent Electronic Devices) for the electric utility industry. It is based on the work of the IEC Tech committee 57 that also resulted in the IEC protocol. GE Harris later turned over ownership and responsibility for further development and evolution to the DNP3 users group. It is publicly open protocol available through the DNP users group. Since it’s the inception of DNP, the protocol has also become widely utilized in adjacent industries such as water / waste water, transportation and the oil and gas industry. <CLICK>

5. TOP Server DNP Master Driver Suite Overview
Plugs in like any other TOP Server Driver
Licensed as an individual suite based on number of RTUs (10, 50, unlimited)
Will be included in the Power Distribution Suite (Coming in 2010)
Serial RS-232/422/485 or Ethernet connections
Supports DNP 3.0 Level 3 compliant slave devices
Ethernet Encapsulation supported which allows use of Cellular Radios & other encapsulation devices
Supports standard TOP Server protocol diagnostics
Serial driver supports Dial-Up Modems
As you can see on the slide, the DNP drivers plug in like any other driver available in TOP Server. It is licensed as a suite, including the serial and ethernet drivers. It will be including in the new vertical industry suite for Power Distribution when it is released in 2010.
Currently the driver is undergoing extensive engineering to make it even better when it is added to version 5. Currently you can only get this driver suite for version
The server supports both serial and ethernet connections as well as ethernet encapsulation and dial-up modem connectivity in the serial driver.
Finally, it supports the standard TOP Server protocol diagnostics which are particularly useful in troubleshooting DNP related issues.
Now, let’s look at how the DNP drivers differ from other drivers. <CLICK>

6. Key Differences from other TOP Server Drivers
DNP is a Synchronous Protocol
Unsolicited Messages & report by exception really helps efficiency with remote devices.
In proper DNP3 usage
Decoupled scan rates & separate scan loops for client/server and DNP master/slave
No relation between client items configured and what gets scanned by the driver layer
Demand Polling option
Allows for operation like a regular polling driver – however, you give up the benefits of the DNP protocol in terms of bandwidth utilization and report by exception.
Ethernet Encapsulation done at Channel level, not device level
Restart requirements
Dependency on proper slave device configuration is greater
Important to Understand
Timeout Settings
DNP Polling Settings
Your slave device configuration
Naming syntax of items and correlation with DNP slave documentation
The DNP drivers, due in large part to the protocol, is a different creature than most other TOP Server drivers. <CLICK>
DNP in nature is a synchronous protocol <CLICK>
It uses both unsolicited messages and report by exception communications to increase efficiency in bandwidth utilization. <CLICK>
When used properly, DNP decouples the scan rates between the client/server and the master/slave meaning there is no relation between your client items that are configured and what gets scanned by the driver.<CLICK>
Supports a demand polling option to allow it to operate like most other drivers, but in using this option you give up the benefits of DNP <CLICK> The following is very important, ethernet settings or ethernet encapsulation are done at the channel level, not the device level. <CLICK>
Due to the nature of the driver, you may have to restart the server for a full reinitialization <CLICK>
There is also a greater dependency on how the slave is configured, and understanding that configuration as well <CLICK>
There are several items that are crucial to fully understand to implement successful DNP communications with TOP Server <CLICK>
The timeout settings, and how these differ from other drivers, the DNP polling settings and how they are different, as well as the slave device configuration. <CLICK>
It is also essential to understand how naming Syntax differs in format from most drivers and how that correlates to your DNP slave documentation.
Transition – Now let’s look at some of these differences in a bit more detail. <CLICK>

7. Differences DNP is a Synchronous Protocol
Only one thing at a time can happen
Each command requires an acknowledgement, confirmed failure, or timeout before the master can move on to the next command
So things may never be as fast as other protocols!
Most serial protocols are this way- but DNP more so
The DNP stack queues up messages to be sent, so a command can spend time waiting in a queue inside the DNP stack- this is in addition to any internal TOP Server queues
Asking for too much too fast can be painful
However, due to the report by exception nature of DNP when properly used, it is very efficient for bandwidth utilization – only changes are sent
Proper use is:
Avoiding demand polling
Reasonable Integrity and Event Poll intervals for the amount of data your device sends and your connection speed
DNP is a synchronous protocol, requiring an acknowledgement, timeout or confirmed failure for the current command before the next one in queue is transmitted. <CLICK>
This means, it will never be as fast as some other protocols. <CLICK>
The OPC driver will often queue multiple commands within a typical DNP timeout period. The DNP stack must dispose of these commands in the order received. Outstanding commands for still-responsive slave devices can be blocked until the command queue empties<CLICK>
…which in practice means that requesting too much data, too fast can be painful. <CLICK>
This being said, due to the report by exception and unsolicited messaging features, it is very efficient in bandwidth usage which is important with wireless or cellular communications. <CLICK>
To reap the benefits of the DNP protocol, avoid demand polling and use reasonable integrity and event poll intervals given your transmission method and amount of data needed. We will discuss this more in-depth later. <CLICK>
Transition – The next difference we need to review is the decoupled nature of the scan rates.

8. Important Learning Topic: Decoupling of Scan Rates – How Normal PLC drivers work
How things work with most drivers
Topic/Group scan rate drives the device polling rate
Topic or Group Update Rate : 100 ms
Driver to PLC Scan Rate: 100 ms
Tag
PLCAddr
Tag1
40001
Tag2
40002
Tag3
40003
Tag4
40004
Tag5
40005
Tag6
40006
Tag7
40007
Tag8
40008
Tag9
40009
HMI or Client App.
As we said, DNP decouples the scan rates in proper usage. In a normal driver, the topic or group scan rate in the HMI or client drives the device polling rate..
With most drivers, the client, will send a request for data at a given update interval <CLICK>
And this is passed through to the driver layer causing a scan of the device at this same rate.
This is how it works for most drivers, now let’s see how DNP does it. <CLICK>
Driver Scan of PLC

9. Driver Layer Data Buffer
Important Learning Topic: Decoupling of Scan Rates – How it works in DNP if used properly
Scan Rates are Independent – Completely!
If you use Demand Polling in DNP, then you end up making it work like a regular driver (see prior slide) and give up the report by exception efficiency of DNP!
No linkage!
Topic or Group Update Rate: 100 ms
Driver to DNP Slave Scan Rates determined by Driver configuration
Driver Layer Data Buffer
Client Interface Layer
Tag
PLCAddr
Tag1
40001
Tag2
40002
Tag3
40003
Tag4
40004
Tag5
40005
Tag6
40006
Tag7
40007
Tag8
40008
Tag9
40009
PLCAddr
40001
40002
40003
40004
40005
40006
40007
40008
40009
With proper DNP usage, the scan rate between the client and server and DNP master and slave are completely independent.
The client sends a data update request at one interval. <CLICK>
This causes the client to poll the driver data buffer at this rate. All the while, the driver is performing integrity and event polls at the rate specified in the driver and updates the buffer at this rate. <CLICK>
Driver does integrity and event polls of the DNP Slave or receives unsolicited messages and updates data buffer
Topic Group Update rate determines how fast data buffer is checked for changes

10. Differences To insure full restart of driver stack, restart the server
Title says it all
Nature of the beast with the separate polling cycles between driver and OPC side which is very different from the closer coupling that exists with other drivers
There can be outgoing messages queued that have not been sent, which means if you only reinitialize the client, the DNP stack will not be reinitialized.
A MUST to keep in mind item if you are troubleshooting an issue!
The other important difference that we must discuss outside of the configuration of the driver, is the need to restart the server. The title says it all.
If you want to insure that you have full re-initialization of the DNP driver stack, restart the server. Earlier we mentioned that the DNP stack may queue outgoing messages. If there are messages in this queue and you simply reinitialize the client, this will not flush the queue, allowing for a re-initialization of the stack. This is why it is a good idea just to restart the server, especially when troubleshooting a communication issue.

11. TOP Server – User Interface Review, Configuring the DNP Driver
So let’s see how to configure the driver – we’ll highlight other key differences as we get to them in configuration
Transition – now we have reviewed some key differences in the DNP drivers, let’s see how to configure them.

12. Configuration – Add a Channel
When you open a blank configuration, you will see in the left-hand pane of the interface “Clcik to add a channel”. This is where we begin. This launches the channel configuration wizard. <CLICK>
The first thing we must do is to give the channel a name. It can be any name that is useful or meaningful to the project being worked. Click Next to select your driver. <CLICK>
There are two Drivers, DNP Master Serial <CLICK> and DNP Master Ethernet.
Transition to next slide: We will start with an Ethernet setup but also show you serial, serial with modem, and serial with ethernet encapsulation along the way. <CLICK>

13. Configuration – Channel Setup Ethernet Driver
In systems with more than one network card and subnet, you can pick which card & subnet to bind to using this combo box
Write Optimization settings and why you might change them are covered in detail in the product help file – best to leave at default in most cases
The next channel parameters are for network interface and write optimizations. In systems with more than one network card or IP address, you can pick which card or IP address to bind to using the dropdown. If you have a single NIC or IP address, default is acceptable. <CLICK>
Write optimization settings and why you may need to change them are covered in the help file, but it is best to leave these at the default in most cases.<CLICK>

14. Configuration – Channel Setup Ethernet Example
Master Node Address must be configured at the slave as well and these must match.
Must be unique for each channel.
IP Address, Slave Port and Connection type are also configurable at the slave and must match these settings.
This is where we begin to see the differences in the configuration for the DNP drivers. Here we see the ethernet settings on the channel level.<CLICK>
The master node must also be configured at the slave and must match the setting here. <CLICK>
The IP Address, slave port and connection type are also configurable at the slave and must match the master settings. This is due to the point-to-point nature of the protocol. <CLICK>
If using UDP then you must also configure the UDP Listener port to match at both the master and slave.
Transition to next slide: So that’s the basic start of configuring Ethernet settings, lets have a look at some serial configurations and then we’ll finish up the channel with the settings common to both serial and ethernet. <CLICK>
If DNP Connection is set to UDP, you also must configure the UDP Listener port at the slave and master.

15. Configuration – Channel Setup Serial Example
Pick your com port – any standard Windows com port will work. COM1 through COM100 supported
Set remaining serial port settings to match your device
If your PC has a modem installed (internal or external) this checkbox will be available
After selecting the Serial driver as we showed earlier in this presentation, you would configure your serial comm. parameters.
Pick the appropriate COM port. COM 1 through 100 are supported. <CLICK>
Configure the remaining parameters to match your slave device. <CLICK>.
If your PC has a mode installed, whether it be internal or extenral, this checkbox will be available for selection if you wish to use dial-up modems for communications. <CLICK>
As we said, the driver also supports ethernet encapsulation. Enable this feature for use with serial/ethernet converters, terminal server devices and some cellular radios
Transition to next slide: Now let’s have a look at the two special cases of a serial connection, modem and ethernet encapsulation. <CLICK>
For use with serial/ethernet converters, terminal server devices, and also with some cellular radios

16. Configuration – Channel Setup Serial Example w/Modems
This checkbox can only be enabled if you have a Windows TAPI compliant Modem installed in the computer. If enabled you can check it to use your modem
You can choose which modem you want to use here
See product help file for full details on how to configure phonebook entries, special dial,hangup tags, etc
First let’s look at the use case of dial-up modems. I had to go to my laptop where I have a modem installed to make these screenshots so that’s why they look a little different in the window style.
As I mentioned on the previous slide, you must check the checkbox to enable dial-up communications if you have a modem installed. <CLICK>
Now choose the modem you wish to use <CLICK>
Configure the appropriate entries here. See the product help file for full details on how to configure phonebook entries, special dial and hangup tags, etc.<CLICK>
Transition to next slide: Now lets have a look at the case of Ethernet Encapsulation

17. Configuration – Channel Setup Serial Ethernet Encapsulated Example
If the Ethernet Connection on your DNP Slave device is provided by a serial/ethernet encapsulation device/terminal server and the actual end device is a DNP serial device you’ll check this box
In systems with more than one network card and subnet, you can pick which card & subnet to bind to using this combo box
IP Address, Port and Protocol type must match the settings in the encapsulation device.
If the ethernet connection is routed through a serial to ethernet converter, terminal server or ethernet radio, but the end device is connected serially, enable ethernet encapsulation by checking the box.<CLICK>
Much like the ethernet driver, as clicking next, you will configure the ethernet encapsulation settings at the channel level. In systems with more than one network card or IP address, you can pick which card or IP address to bind to using the dropdown. If you have a single NIC or IP address, default is acceptable. <CLICK>
The IP Address, slave port and connection type are also configurable at the slave and must match the master settings. This is due to the point-to-point nature of the protocol. <CLICK>
You will also notice a Connect Timeout here. This is the amount of time we wait for a socket connection to be established or in the case of UDP, how long we wait for the first response before timing out.<CLICK>
Transition to next slide: Now there are some special considerations to keep in mind when using the DNP driver (CLICK)
The amount of time allowed for a TCP socket connection to initially be established to the device. Non-relevant/ignored when using UDP connections.

18. Configuration - Channel Important Considerations
DNP Master ID is at the channel level and must be unique for each Channel
If you want unsolicited messaging to work, you have to get this right so the Slaves know where the master is!
Encapsulation or Ethernet parameters are set at the channel level
If you have > 1 serial slave device but are using Ethernet/Serial convertors, each with it’s own Encapsulation device or if the slave is Ethernet capable, each device will be under it’s OWN channel
Probably a good thing for performance since each channel is a unique thread
Before we move on with our configuration, I want to make sure you remember a few key things to help insure your success:
The Channel defines your computer as a DNP Master device in a DNP Master/Slave conversation. Many DNP slaves require that you configure in the slave what the address of the Master device it will talking to. You may not be used to doing this in typical PLC communications but it is very important for DNP. The biggest place this is important in DNP is when you are using Unsolicted Messaging, which we’ll talk more about later. If your DNP Master ID set at the channel level does not match what is configured in your slave device, at best your unsolicited messages from the slave won’t arrive. At worst, you will have no successful communications!
<CLICK>
If you have used other TOP Server serial drivers before with serial to ethernet converters, you might be used to setting the ethernet encapsulation parameters at the device level. In the DNP driver they are set at the channel level as you saw on the previous slide.
Also, with the DNP drivers each device will need to go under it’s own channel. This is a recommended performance optimization anyway to insure that one device being offline doesn’t slow down other devices polling. Just realize that you must use one device/channel for Ethernet and Ethernet Encapsulated DNP devices. Pure serial DNP connections don’t have this restriction.
Now that we’re clear on these details, lets move on to some important timeout settings in the channel configuration. <CLICK>

19. Configuration – Channel Setup
NOTE – resist the urge to explain these here – the next 2 slides explain them in detail.
There are two timeout settings at the channel level, <CLICK> DNP Channel Timeout and <CLICK> DNP Connection Timeout. These are common to both the serial and ethernet drivers.
Let’s delve a little deeper into these settings.

20. Understanding Timeout Settings
DNP Channel Timeout (Channel Properties)
Channel Level
Controls timeout for the time on the wire between Master & Slave only – no queue time
DNP Connection Timeout – used with TCP only – non-relevant with UDP
Time to get the TCP connection up and going
DNP Command Timeout (Device Properties)
Device Level
Time On Wire + Time In Queue
Should generally be > DNP Channel Timeout!
In DNP, there are several timeout settings that we do not see in any other driver.
The DNP Channel Timeout is simply the time we wait for a response once the message has been sent.
The DNP Connection Timeout is used with TCP only, and is irrelevant with UDP. This is the time we wait to establish the TCP Connection.
The DNP Command Timeout, which is set at the device level, is the timeout period that includes both time on the wire and time in the queue. This should be > the DNP Channel Timeout.
<CLICK>

21. Understanding Timeout Settings
Talking to multiple devices will take time if you have multiple slaves off of one channel
In Ethernet or Encapsulated Cellular radio scenarios, a non-issue since it’s 1 device per channel
Rule for timeouts if multiple devices under one channel:
DNP Command Timeout = (# Devices under Channel +1 ) * DNP Channel Timeout
Example:
DNP Channel timeout = 10 seconds ( default )
1 Device, 1 Channel
DNP Command timeout = (1+1) * 10 = 20 seconds
If we have multiple slave devices in a single channel, this will take some extra time. This is not an issue in ethernet or encapsulated serial settings because it’s one device per channel.
The general rule is that the DNP Command timeout should be greater than or equal to, the number of devices in the channel + 1 multiplied by the DNP Channel Timeout.
In the example, if we take 1 channel with a single device and use the default channel timeout of 10 seconds, then 1 device + 1, so 2 * 10, then the DNP Command Timeout should be at least 20 seconds.
Transition to next slide: Now that we know more about the Timeout settings, lets finish our channel. <CLICK>

22. Configuration – Channel Summary
Now that all parameters are configured, you have the opportunity to review and go back to make changes if necessary. Click Finish to complete.
Transition to next slide: Now that we have our channel setup, lets get the device configured.

23. Configuration – Device Settings
You’ll see this under the channel you just configured – click it to start the Device Configuration Wizard
Give your device a name that is useful to you.
This is the DNP Slave ID of your device – it is required for Ethernet or Serial Device. This MUST match your slave device!
Now you see your channel you have just configured and underneath you see Click to add device. <CLICK>
Click to start the device configuration wizard. <CLICK>
Just as with the channel configuration, the first thing you will do is provide a meaningful name to the device. <CLICK>.
After naming the channel, you will enter the DNP slave ID. This is required for both ethernet and serial drivers and must match what is set in the slve device. In the slave device, this could be called slave address, outstation address or any number of other titles, depending on the semantics of your slave documentation.
Transition to next slide: Before we go further, we need to talk a bit about the unique types of polled and non-polled communications that you can have with a DNP device.
<CLICK>

24. DNP Polling Types Integrity Event Unsolicited
Gets All the data from the device – usually done at startup and infrequently
Event
Supplies changes since last Event or Integrity Poll, including buffered events if configured on slave
Make sure your slave is configured to send timestamps! Many are by default, but if you aren’t getting the timestamps you expect….check the slave device settings
Unsolicited
Slave sends changes to Master based on policy configured in slave
What is sent and when, plus retry policy & timing is set on the slave
If you depend on unsolicited messages, beware of your firewall! Unsolicited TCP/IP and UDP packets will be rejected unless you’ve planned for them
Demand (configured at the tag/item level)
Traditional master polling of slave – gets data whether changed or not.
Bypasses DNP efficiencies.
Not recommended unless you have to!
Polling rate driven by Topic or Group Update Rate
There are four types of communications, three polling types + unsolicited messaging.
An integrity poll requests all data from the slave regardless of data changes and what the client is asking for. This is usually done at start up and then is performed very infrequently after startup. <CLICK>
Event polls request all data changes since the last event or integrity poll, regardless of what the client is polling. Make sure that the slave is confiugred to send timestamps so that you have the correct event time stamp in your application. <CLICK>
Unsolicited messages are sent by the slave on an event or data change, if it is configured to do so, without a poll request from the master. How these are handled in regards to timing, deadband, etc. are handled by the slave. Please note the importance of firewall settings. If you use unsolicited messages and your firewall does not have the proper exceptions, your unsolicited packets will be rejected.<CLICK>
Demand polling allows the driver to work in a traditional master/slave polling method. This will retrieve data for points defined for demand polling whether the data has changed or not, which removes the efficiencies of the DNP protocol. This is not recommended unless you absolutely must use this.
Transition to next slide: So lets look at how a typical DNP system setup might work with respect to polling .<CLICK>

25. DNP Polling Typical Use Cases
With DNP you can connect and initialize the session and:
Do an Integrity Poll,
Then sit and listen for unsolicited messages
and never do an Event Poll
Or…Most Commonly…. after the initial Integrity Poll
You can do an Event Poll at some interval to get just items changed since last report from the slave & change history if enabled at slave and master
You can do an Integrity Poll at a regular interval to ask for an update of ALL items
And receive unsolicited messages, if configured in slave
Sometimes devices have data that can only be read by doing explicit reads (“Demand Polling”)
There are a few standard use cases that we encounter regularly.
First, you can connect HMI or SCADA, causing the DNP stack to initialize the session. Then, during initialization an integrity poll is performed. After the integrity poll, only listen for unsolicited messages, never performing an event poll. <CLICK>
More commonly we see the event poll and unsolicited messaging mixed. After the initial integrity poll you will perform event polls at regular intervals, perform integrity polls at infrequent intervals and listen for unsolicited messages if the slave is configured for such. <CLICK>
Sometimes devices have some data points that can only be read explicitly from the device. This is the demand polling option. The only other use case we have encountered for demand polling is regulatory reporting requirements that require a point or points to be reported at specific intervals, regardless of value change.
Transition to next slide: Now we’ll look at how to setup the polling at the device level and finish the timeout settings that we started earlier with the DNP Channel Timeout when we setup the channel <CLICK>

26. Configuration – Device Settings Polling Settings
Controls how often driver will ask DNP Slave for a report of all changes since last Event Poll or last Unsolicited Message. Three event classes in DNP can be configured with different event poll rates. See your DNP slave documentation for what points are in each class – it may be configurable.
0 = do no Event Polls, ever, rely on period integrity polls, unsolicited messages or explicit reads only for updates.
Max value = 86,400 seconds (24 hours)
Controls how often driver will ask DNP slave for values of ALL items in the slave, regardless of whether you have OPC items setup for them, regardless of whether values have changes
0 = do no Integrity polls, ever – not recommended
Max Value = 2,592,000 seconds (30 days)
We recommend no more than once per hour, especially in radio or wireless networks. Most applications even less frequent, every 8 hours or 24 hours is sufficient. The max is 30 days.
DNP Command Timeout should be greater than the channel timeout
The DNP Command timeout covers time on the wire (Channel timeout) and time in the queue
Formula:
DNP Command Timeout should be >=
(# of DNP Devices Under a Channel + 1) * DNP Channel Timeout Setting
(set on your channel properties)
As you can see, there are a number of options to configure here. <Click>
First you will configure the event polling. DNP has different event classes that you may use to classify points. You can configure each event class poll time separately. You may set this to a maximum of 24 hours, in seconds or set it to 0 to turn off event polls. <CLICK>
Then you will configure your integrity poll time. You can set this to a maximum of 30 days. Setting this to 0 turns off integrity polling, but we do not recommend this. We recommend this to be no more than once per hour. However, for most applications, very infrequent times of 8 to 24 hours or more is sufficient. <CLICK>
Earlier we discussed the DNP Command Timeout. This is where it is configured. Remember, the recommended setting is greater than or equal to the # of DnP devices in the channel + 1, then multiply the sum by the DNP Channel Timeout.
Transition: Now that we have set the polling options, there are some advanced settings as well as unsolicited settings left to configure.
<CLICK>

27. Configuration – Device Settings Advanced Settings
Two Options:
LAN
Serial
Two Options:
Direct Operate
Select then Operate
Two Options:
UTC
Local Time
Determines action after write from Master to Slave
If the slave can report an I/O point as offline, this allows the server to set the quality to bad for the .Value and .Explicit subtypes
There are a number of advanced DNP settings to configure. Let’s look at each of these. <CLICK>
In the DNP protocol, the slave may send a synchronization request to the master to synchronize it’s clock. There are two options LAN and Serial. Only use LAN for a hardwired ethernet connection. To get the true time for serial, radio, dial-up, or even wireless ethernet use Serial. When you use serial, the master will make a delay measurement, meaning it calculates lag time then sets the time in object 50, variation 1 to the lag corrected time. <CLICK>
The Default Operate Mode defines how writes occur. There are two options, Direct Operate and Select then operate. If your device has points defined as select then operate, you must first write a boolean true to the .SO subtype for that point before writing to the Value subtype of the point. With Direct Operate you write directly to the Value subtype. We will discuss subtypes in a few minutes when we discuss DNP addressing. The default behavior is Direct Operate, which many if not most slaves support.<CLICK>
Each DNP point has .timestamp subtype that stores the timestamp of an associated event. You can choose to display this in UTC notation or in your local time format. <CLICK>
In normal operation, after writing to a slave, a DNP master will perform a feedback poll of the slave. We have found that this causes problems with some slaves. We have added this checkbox to allow you to turn off this feature. <CLICK>
Some slaves can also report when an I/O point is offline. This checkbox allows the server to set the quality to bad for the .Value and .Explicit subtypes if the slave reports the point offline.
Transition: Now that we’ve set our advanced configuration options, we need to look at unsolicited messaging in DNP. <CLICK>

28. Unsolicited messages update master with changes in the device
Configuration – Device Settings Unsolicited Messaging Setup and Considerations
Unsolicited messages update master with changes in the device
Slave device controls settings on item deadbands and Unsolicited messages (number and frequency), NOT THE MASTER!
Deadband settings in a slave can prevent you from receiving EVERY change – a good or bad thing based on your needs
Our Master CAN control which classes of Unsolicited Messages get sent, IF the SLAVE will accept our command messages… they aren’t required to!
But the Master can’t control unsolicited message settings at the slave any more granurally than this
If the slave accepts unsolicited setting commands from the master, this tells the slave to disable unsolicited messaging.
If the slave accepts unsolicited setting commands from the master, this tells the slave to enable unsolicited messaging.
No Action accepts the settings from the slave. If the slave does not accept unsolicited messaging commands from the master, the other two settings are irrelevant.
First, let’s discuss a few considerations to keep in mind when setting up unsolicited messaging in DNP.
The DNP protocol allows the slave to update the master with data changes without a poll from the master. <CLICK>
This is fully controlled by the slave and most slaves allow you to configure any delays or item deadbands for unsolicited messages. <CLICK>
The deadband settings, can prevent you from receiving every data change, which can be good or bad based on data reporting needs and bandwidth limitations. <CLICK>
The TOP Server takes advantage of a part of the DNP spec that allows the master to send commands to the slave regarding unsolicited message behavior. The slaves, however are not required to accept these messages. Now let’s look at the configuration options available. <CLICK>
For each event class, you can set the action for unsolicited messaging. The TOP Server will send commands to the slave, based on these settings, but as we just said, the slave is not required by protocol specifications to accept these commands. <CLICK>
If you set this to enable, and the slave accepts these commands, this will enable unsolicited messaging for that event class on the slave. <CLICK>
Likewise, setting Disable for the class will disable unsolicited messages for that class on the slave if the slave accepts these command. <CLICK>
Setting the class to No Action means we do not send commands to the slave and accept what it action it sets for unsolicited messaging. If you know the slave does not allow these commands, or you do not want the master to have control, set this to no action. <CLICK>
However, the master cannot control any other unsolicited settings such as deadband and delays.
Now, we understand polling and how to set it up a little better, let’s look at the event buffering feature.

29. Configuration – Device Settings DNP Event Buffering: Overview
What happens when communications are lost?
Most non DNP devices/protocols miss out on that data.
DNP slaves can buffer data and then send the events when communications are established.
Whether or not your slave buffers, how much it buffers, how it handles a buffer overrun, are all your slave hardware’s settings outside the scope of the TOP Server and it’s support.
When communications comes back
A properly configured DNP system will have the slave replay the old events with the timestamps of when the event happened!
TOP Server can
Buffer up to a specified # of events
Play them back at a user configurable rate that your client/Historian can handle for logging
The events play back in the same order we receive them from the slave – provided the slave delivers them in FIFO timestamp order, then our delivery to HMI/SCADA will be the same.
So, what happens when communications fail between the master and slave? Most of the time you would lose that data.
However, DNP slaves can store event data for each point and then send the data when communications are re-established. Your slave determines if it can buffer, how much data it can buffer, and all other buffering settings. Configuration of these slave hardware settings is outside of the scope of TOP Server support.
Once we have good communications what happens? A properly configured DNP slave that fully supports the DNP protocol specification will send the events with timestamps to the master in the sequence with oldest timestamps sent First.
The TOP Server can then buffer these events, up to it’s configurable maximum per tag and play these out to the client application at a user configurable playback rate.
Please do note, that we replay these events in the order we receive them from the slave, so if the slave provides the events in the correct, first in first out, timestamp order, the events will be sent to the client, HMI or SCADA, in the same order.
<CLICK>

30. Configuration – Device Settings DNP Event Buffering: Supported Objects
Event Buffering applies to DNP objects
1 – Binary Input
3 – Double Bit Input
10 – Binary Output
20 – Binary Counter
21 – Frozen Counter
30 – Analog Input
See driver help file for more details
The event buffering feature applies to the DNP objects you see here. This is covered in the help file along with other useful details about the feature.
Transition: Now let’s look at some other important considerations about the event buffering feature. <CLICK>

31. Configuration – Device Settings DNP Event Buffering: Important Considerations
Event Buffering introduces latency into the tags for those affected objects.
Even after the initial burst of events is played out of the buffer, newly incoming updates will only be reported at the Playback Rate.
Buffering should only be used when preservation of the event stream is more important than timely delivery of point updates.
Event Buffering is enabled at the device level
If a tag's event buffer should fill up, new reports will displace the oldest reports in the queue.
Using event buffering does come at some opportunity cost. When enabled, it will introduce latency into the tags of the affected objects. After the initial group of events are sent, new updates from the slave will only be released to the client at the playback rate. Therefore, it is wise to use this feature only when capturing all events is more important than fast delivery of the events to the client.
Transition: Now we know about this feature, let’s see how it is configured. <CLICK>

32. Configuration – Device Settings DNP Event Buffering: Configuration
There are three settings to configure when you use event buffering.
First, we must enable event buffering.
In this example the buffer will retain 100 updates per tag and make the next update available to the client once every 2000 milliseconds.
To insure retrieval of all the buffered events, the client must have an update rate at least twice as fast as the Playback Rate (less than 1000 milliseconds in this example).
Configure the max events per tag,
In our example we will set the buffer to retain 100 events per tag, and make the next update available to the client every 2000 milliseconds. There are three settings related to event buffering. <Click>
First you must enable the feature using the checkbox. <Click>
Then you will configure the maximum events per tag to be buffered. The range available is 1 to <Click>
Finally you will configure the rate at which events are played out to the client. <Click>
It is important to note that if you want to insure retrieval of all events, the client scan rate must be at least twice as fast as the playback rate configured here. Click next to finish your driver configuration. <CLICK>
Configure the playback rate.

33. Configuration – Device Settings
Before finalizing your device configuration, just like at the channel level, you have the opportunity to review your settings and go back and change any you may need to change.
Transition to next slide: Now that we’ve completed our device configuration, lets look at how you address memory in your DNP device. <CLICK>
Click “Finish” and you’re Done!

34. Configuration Setting up DNP Tags/Items
Must have DNP slave profile document
Slave profile is not some file you load into the driver!
But it is a key document that a DNP3 compliant slave device must provide!
User must read over it and be responsible for interfacing with their h/w vendor on questions about their document
Understand the basics of the DNP standard item naming syntax
When setting up DNP tags that are some important differences. It is essential to have the DNP slave profile document for your device. This will let you know what the DNP addresses are used for, what event class they belong to and how to access them. To use this document, you also need to understand the bascis naming syntax for DNP standard items.
<CLICK>

35. Configuration Addressing DNP Items
Address follows OBJ.VAR.IDX.SUB syntax:
OBJ=Data object group (i.e. analog inputs, analog outputs, etc)
VAR=Variation (equates to data type)
IDX=Data object within a group (OBJ) – i.e. IDX 4 would be the 5th point in a group
SUB=Specific attribute of a point
Most commonly used is “Value”
Use “Explicit” to cause the tag to be “Demand Polled” – makes that tag work just like traditional polling PLC driver – use with care!
DNP items are addressed with a four part address object.variation.index.subtype or subattribute.
The object is the data object group to which the item belongs.
Variation defines the default data type for the item.
Index is the data object within the group. For example, the 5th point in the group would have an index of 4, because indexing as well as variations start at 0.
The subattribute or subtype is the attribute you wish to read for the specific index or point. Most often, you will use .Value to read the index value, but, depending on the object and variation, there are a number of attributes available such as .Timestamp, .Explicit and .Restart.
Alternative to .Value, you would use the .Explict subattribute to cause the tag to become demand polled, which as we discussed earlier will cause the tag to work like tags in traditional polling PLC drivers.
Now let’s take a quick look at an example DNP slave profile to see how this is used.<CLICK>

36. Configuration Setting up DNP Tags/Items: Example
Example – Multitrode Multismart
Chapter 3 gives you list of Object #s (OBJ)
Chapter 4 gives you the IDX but they call it “Default DNP ID”
Depending on the quality of your DNP slave documentation, this might take some trial & error or you may have to ask the hardware supplier for clarification
We will use the slave profile for a MultiTrode MultiSmart pump controller. <CLICK>
Chapter three lists the object numbers <CLICK>, the various available variations <CLICK> and their descriptions. <CLICK>
Chapter four gives you the IDX, though they call it the DNP ID <CLICK>
It also shows a TagID, which could be used for the tag name in the TOP Server <CLICK>
Conditions when set and clear <CLICK>
And the event class for the point. <CLICK>
Transition: Let’s look at a couple of examples. <CLICK>

37. Configuration DNP Addressing Examples
Analog Input
Value
30 = Analog inputs object
0 = Variation = default data type
3 = index, sometimes called Default DNP ID
Value = report the value of the input
Binary Input
1.0.2.Timestamp
1 = Binary inputs object
42 = index, sometimes called Default DNP ID
Timestamp = report the time of the event currently reported by the .Value sub-attribute
For example, if we wish to address the value of the 52 analog input. It would be as follows Value.
30 defines the Analog Input object
0 defines the default variation, or data type,
51 is the index of the 52nd analog input, remembering that indexing starts at 0 and
Value reports the value of the input . In relation to the Multismart controller slave profile, this would report the current level of Well 1.<CLICK>
Likewise if we wish to know the timestamp of the event reported on the 3rd binary input we would define the address Timestamp where
1 defines the binary input object
0 defines the default variation or datatype, in this case, date
3 indicates the fourth binary input, once again, with indexing starting at 0
And Timestamp tells us to report the date/time of the event value currently reported by the .Value subattribute. In the Multismart, this would give us the time of the last station overvoltage fault status change, where .Value would show us the status of the fault.
Transition: There are some other subleties to DNP Addressing we need to understand. <CLICK>

38. Configuration: DNP Addressing Important Subtleties to Know
In proper DNP implementation, the # of tags or OPC items you configure in the OPC server has no effect on what gets scanned or updated from the DNP slave – that’s how DNP works!
The driver abstracts a lot of DNP Slave profile details for you – so try not to get bogged down in the details.
Focus on finding the OBJ.VAR.IDX.SUB lists for the tags you want in the DNP Slave profile
If you don’t see an object # from your slave profile listed in the driver help file, does not mean it’s not supported – some object #s are implied when you use the base object.
Change Event objects are used “under the hood” automatically
Same with writing objects
See “Address Descriptions->Object Definitions” in help file – a list of objects whose data is reflected in other objects is provided there!
Example:
Object 30 – Analog Inputs – using object 30 will also cause object 32 to be used “under the hood” for analog input change events.
When in doubt, try the base object # for the Object Group (i.e analog ins, analog outs, etc) for the OBJ part of the address and try the things you want to do
In a proper DNP implementation your # of tags in the client or server will have no effect on what points are scanned or updated from the DNP slave. <CLICK>
The driver abstracts a lot of the DNP protocol and slave profile details so you don’t have to get caught up in those. <CLICK>
The important part is to focus on finding the addressing lists in your slave profile. This process could take some time. If you understand DNP addressing and your DNP slave device vendor has provided a clear and concise document, this process will not be too difficult.
<CLICK>
If you don’t see an object number from your slave profile list in the addresses supported by the server, this does not mean it isn’t supported. Some objects are “reflected” or addressed under the hood using a base objet. There is great detail in the help file about these objects. For example, if you wish to read from object 32, you would address that by using the correct variation for object 30 to cause object 32 to be used.<CLICK>
Transition to next slide. Now that we’ve covered the configuration and DNP addressing – what about testing to make sure your configuration works? <CLICK>

39. Testing Communications OPC Quick Client
If launched from the Server, it will auto-populate all tags configured in the Server
Tag detail view
Server connection and OPC Group tree
For testing device communications we include our OPC Quick Client.
If launched from the server, it will auto-populate any tags you have configured in the TOP Server. <CLICK>
There are three parts…
Tree <click>
Tag Detail <click>
Event log which shows any OPC connection related messages.
OPC Quick Client Event Log

40. Tips & Tricks
Loads of free help at:
Quick Start Guide
Training Videos
Papers and Utilities – Trouble Shooting Guide
More information on the Product Details tab
Contact Software Toolbox while you are in the planning stage, so we can help
Now that we have seen a quick overview of our free testing tool, I also wanted to make you aware that we have a large volume of free documentation to help make connectivity easier, including our Trouble Shooting Guide. You can see some of the links on the screen.
Please do send us s and get us involved at the beginning of your project, we love to help you find solutions.
(Click)

41. Contact Information & Other Learning Opportunities
Questions later?
Boyce Baine or
Other learning opportunities
Visit
Now I’ll answer any questions you may have.