Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayAre you researching the best practices for remote monitoring at your sites? Or are you involved in migrating legacy gear? Whatever your case is, if you're considering the purchase of DNP3 equipment, it's important to go through this process with your eyes open, knowing all the benefits as well as the disadvantages of this protocol.
With more information, you'll be able to take full advantage of your purchase, gaining superior visibility and control over the equipment. All while getting the most functionality for your money.
Let's dive into some facts about DNP3 so we can talk about some of its pros and cons, as well as some considerations that you should keep in mind if you're planning on purchasing a SCADA system with DNP3 capabilities.
Since its introduction in 1993 as an immediately deployable solution for monitoring critical infrastructure statuses and allowing reliable remote control, the Distributed Network Protocol has grown to global usage. GE-Harris Canada (formerly Westronic, Inc.) is generally credited with the seminal work on the protocol, but it's now implemented by an extensive range of manufacturers in a variety of industrial applications.
DNP3 is a communication protocol based on an object model that greatly reduces the bit mapping of data that is traditionally required by other less-object-oriented protocols. It also reduces the wide disparity of status monitoring and control paradigms generally found in protocols that provide virtually no pre-defined objects. Purists of these alternate protocols would insist that any required object can be "built" from existing objects. However, having some pre-defined objects makes DNP3 a somewhat more comfortable design and deployment framework for SCADA engineers and technicians.
DNP3 is typically used between centrally located masters and distributed remotes. The master provides the interface between the human network manager and the monitoring system. The remote provides the interface between the master and the physical device(s) being monitored and/or controlled.
The master and remote both use a library of common objects to exchange information. The DNP3 protocol contains carefully designed capabilities that enable it to be used reliably even over media that may be subject to noisy interference.
DNP3 uses 27 basic function codes to exchange information between masters and remotes. Some of those function codes enable a master to request and receive status information from a remote. Other function codes enable a master to determine or adjust the configuration of a remote.
Several function codes are defined for a DNP3 master to control the remote itself or equipment co-located with the remote. One function code is provided to enable the remote to respond autonomously with an Unsolicited Message to particular events that occur in its installation space.
As you can see, most of the messages are issued by the DNP3 master to the DNP3 remote. However, because the Unsolicited Message is capable of being initiated by a remote, it's typically used to report alarms. This notifies the DNP3 master as soon as an alarm condition occurs, instead of waiting for the next request.
A remote can report by exception or event
This DNP3 feature is useful to reduce transmission frequency, instead of regularly polling for information, new information - power line malfunctions or significant current changes, for example - can be reported by the remote as soon as it's observed.
Native TCP/IP Compatibility
The use of DNP3 is not limited to serial wire communications using a modem and phone lines. The DNP3 functionality contributes to the protocol's widespread use in local area networks using TCP/IP through Ethernet.
Security
DNP3 security has been relevant especially since communication over TCP/IP has become common and different methods are used. Data radio suppliers use their own encryption schemes, but vendors implement security as well. The messages in the DNP3 protocol are encrypted, time-limited, and key-protected with keys that change regularly. The reason is obvious, if somebody records a control action, and transmits it into the cloud, even if this message was a valid action thirty minutes ago, it'll have expired.
One of the latest developments in DNP3 is DNP3 Secure Authentication, which defines a protocol mechanism that: (1) enables a DNP3 outstation to unambiguously determine it's communicating with a user who is authorized to access the services of the outstation, and (2) enables a DNP3 master to unambiguously determine that it's communicating with the correct outstation.
DNP3 supports multiple masters
Another strong point of the DNP3 protocol is that it supports peer-to-peer along with the traditional master/slave relationships. The master/slave principle is also extended by allowing multiple masters, multiple slaves per master, and the possibility of a slave station being the master of other slave stations. Although peer-to-peer communication is provided by allowing slave stations to initiate communication, one of the stations is always designated as a master station. Moreover, only the master station can request data or send commands.
DNP3 protocol has been designed to work reliably over low-bandwidth links using a range of communications media like radios, dial-up modems, PSTN-lines and satellite-links.
This aspect is one of the pitfalls often encountered in the industry by users that upgrade their system from the serial-based DNP3 to Ethernet DNP3. They will take a serial RTU, and upgrade it with an Ethernet RTU. If the bandwidth of the communication channel to that station is not also increased, the user will have a slower link due to the overhead implemented of wrapping the DNP3 with TCP/IP.
DNP3 has significant features that make it more robust, efficient, and interoperable - at the cost of higher complexity.
Even though DNP3 is robust, efficient, and compatible with a wide range of equipment, it has become more complex over time.
The DNP3 protocol is indeed powerful and highly configurable. However, you need to be careful and plan ahead - prior to the purchase of DNP3 remote monitoring equipment - and understand how this protocol is going to be used in your network. This way you can make sure its features and capabilities will match your requirements and expectations. This caution not only applies to DNP3 gear, but to any remote monitoring equipment you might buy, so you're certain that the reliability and efficiency is no less than what you need.
Using DNP3 in a contemporary SCADA system sounds like an easy decision - after all, this is a standard protocol that has wide acceptance in the industry and is flexible enough for almost any application.
DNP3 certainly has its place in an effective monitoring solution, but this doesn't mean that any off-the-shelf DNP3 master or remote will be the best fit for you. Before you commit to a SCADA monitoring solution for either your operating center or your remote sites, you need to consider a multitude of key factors.
Keep the following 8 important features in mind when looking for your DNP3 device.
Masters should provide concise alarm information
Masters sometimes present data in such an attractive, graphical interface that you can't see the forest for the trees. Make sure that you have access to a list view that provides a good presentation of event and alarm detail for more than a single site or region. Sometimes, a summary graphical presentation can make details an inconvenient click or two away when a decision needs to be made.
Masters should be able to identify "clear" alarm events
If you will be relying on Unsolicited Messages in your system, make sure there is a clear event for each alarm. Creating this association can involve expensive custom development on your master system.
Masters should maintain a history of standing alarms
Avoid the allure of maintaining only an event log of newly reported Unsolicited Messages and a history log of acknowledged Unsolicited Messages. If an Unsolicited Message represents an alarm condition, there should be continued visibility to the alarm even if the Unsolicited Message is acknowledged. Imagine what might happen to your network if a system operator acknowledges an alarm message, and then, for whatever reason, fails to correct the alarm condition. Who would know the alarm is still standing?
Masters should sort and filter alarms
Masters should support organizing alarms by a wide variety of characteristics. Location, equipment type and severity are just a few possibilities that may make sense for organizing your alarms. The same alarm should be able to be posted to multiple categories. The presentation of sorted and filtered alarms should depend on the user logged on; the team responsible for generator maintenance doesn't need to wade through lists looking for generator events and alarms.
Masters should support flexible and powerful notification
Make sure your master supports the advanced features necessary for premium status monitoring, such as notification escalation, nuisance alarm silencing, automatic control relay operation, and automatic notifications by e-mail, text, or pager.
Masters should not be limited to DNP3
If you're like most companies, you have a variety of equipment of different ages and technologies. Integrating this diversity into a SCADA Master can sometimes involve surprisingly expensive customization and additional modules. It's always difficult and uncomfortable to justify significant development costs after purchasing an already expensive SCADA Master. Why take the time, trouble, and expense to recreate capabilities that are already present in a high-quality, multi-protocol Master that is DNP3-capable?
Remotes should support redundant power
If your remote is powered from a single source, then your critical monitoring is vulnerable to a single power loss. Losing that single source of power effectively compromises the continuous monitoring of your revenue-generating equipment. If your installation does not have dual power sources, make sure the equipment is compatible with an external power supply that can't be interrupted. Also, insure that the primary power is one of the points monitored at each location.
Remotes should provide local SCADA
If a network failure compromises the collection of data between your remotes and central console (HMI in SCADA terms), your remote equipment should provide for local visibility. Turn the worst case of having to dispatch techs to critical remote sites into a much better case by ensuring that they'll be able to browse to your remote units and have local SCADA until the network is restored.
Now you know the main pros and cons of DNP protocol. But, before you make a decision about your SCADA DNP3 monitoring, there's a lot more you need to know - especially if you have a rather unique network. There are dangers you want to avoid, and there are also opportunities to improve your remote site maintenance that you don't want to miss.
If you want more information about the DNP3 protocol or are ready to start your remote monitoring project, you can contact me today. I'll be happy to help you.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
