Distributed Network Protocol (DNP3) - Learn the fundamentals and how to understand this industry-standard SCADA protocol to get started with DNP3 today!
This DNP3 tutorial was written for the professional who needs to monitor SCADA equipment with DNP3. Most DNP3 books go way too deep and just aren't practical. Who has time for all that? We've written this DNP3 tutorial to give you the information you need to successfully implement and maintain DNP3 monitoring in your SCADA system. It's an introduction to SCADA from your own perspective, and it has the fast, specific answers you need to make DNP3 work for you.
Since its introduction in 1993 as an immediately deployable solution for monitoring critical infrastructure status and allowing reliable remote control, Distributed Network Protocol (DNP or DNP3) has achieved widespread acceptance. GE-Harris Canada (formerly Westronic, Inc.) is generally credited with the seminal work on the protocol but it is now implemented by an extensive range of manufacturers in a variety of industrial applications.
DNP3 is 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. Having some pre-defined objects though, makes DNP3 a somewhat more comfortable design and deployment framework for SCADA engineers and technicians.
A typical DNP3 master/remote monitoring system architecture
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 data between Masters and Remotes. For example, function codes can:
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 is typically used to report alarms. This notifies the DNP3 Master as soon as an alarm condition occurs, instead of waiting for the next request.
The DNP3 framework includes a library of objects that are used in SCADA systems. This library is available for downloading to members of the DNP Users Group. Visit www.dnp.org for more information. These objects include such things as Binary Inputs that are used to report equipment characteristics that have two states; power is on or off, an access panel is open or closed. Another common object is an Analog Input that is used to report characteristics that have a range of values. Exhaust fan speed can be anywhere from 40 to 400 RPM. Main power can vary from 110 to 128 VAC.
This library makes it easy for the manufacturer to design the DNP3 Remote responder to use these common objects to report to upstream Masters. It also makes it easier for Masters to integrate the data collected from Remotes and present it for decision making.
Without this framework of common objects, manufacturers must develop their own model for reporting status and providing control capability. These models, frequently quite different one from another, must then be 'compiled' into the Masters and usually converted into some kind of common objects for efficient management. Another tool often found in these more 'open' frameworks is a proprietary interface or translation module to access and control the Remote. Objects in the DNP3 library are divided into Groups and Variations. For example, the Analog Input group has six variations to provide 16 or 32 bit integer or floating point values with or without a status bitmap. The Analog Event group has eight variations to provide 16 or 32 bit integer or floating point values with a status bitmap and with or without a timestamp. Note that the Analog Event group does not include variations without a status bitmap.
Let's examine the structure of the messages exchanged between masters and remotes. Basic serial telemetry protocols, like TBOS, are byte-oriented, with a single byte exchanged to communicate. Expanded serial telemetry protocols, like TABS, are packet oriented with packets of bytes exchanged to communicate. The packets contain header, data and checksum bytes. DNP3 is also packet oriented and uses the packet structure (element sizes in bits) shown in the illustrated figure below.
The Master sends a Read request for an object or objects and the Remote's response contains the requested information if available. The Master sends an Operate command to produce the output actions associated with the selected object reference. The Remote sends an Unsolicited Message when a specific event occurs.
The DNP3 application service data unit (ASDU) is worthy of special note for the clever content adjustment that is controlled by the qualifier and indexSize fields. This design makes application data available in an impressively flexible number of configurations or omitted all together if desired.
The last section focused on the structure of DNP3 messages and illustrated the first few layers of the message. Let's continue examining DNP3, focusing specifically on the layered communication model used to exchange information.
The application layer combines an application service data unit (ASDU), a packaged object in itself, with an application protocol control info (APCI) block to make an application protocol data unit (APDU).
The transport layer breaks the APDU into segments with a maximum size of 16 bytes and packages them with an 8-bit transport control header and 16-bit segment CRC separators into a transportFrame.
The link layer adds a header the control and addressing information to prepare the packet for delivery to a specific destination.
These layers can be mapped to the four-layer model developed by the Department of Defense (you may recall the DoD origins of the Internet) with the DoD Internet Layer omitted.
If the serial transport is used, the packet assembly is completed and placed on the transport media for delivery.
If the packet will be sent over a LAN/WAN, the three DNP3 layers are rolled up into the application layer. The assembled packet is wrapped in the Transmission Control Protocol (TCP) by the transport layer, which in turn is wrapped in the Internet Protocol (IP) by the (somewhat obvious) internet layer. The User Datagram Protocol (UDP) can also be used but presents some additional issues related to reliable delivery in congested networks.
The fourth layer is the Network Interface layer where the assembled packet is actually interfaced to some kind of transport media (for example, twisted pair copper, RG58 co-axial or fiber). While this multi-layer model may seem a bit confusing, it effectively isolates the tasks of communication and ultimately assists in designing and implementing a network.
To illustrate the function of this layered model, let's look at a single DNP3 Read request over a LAN. The DNP3 Master wants to know the current status of the Remote's power and prepares a Read request message for the appropriate object. After passing through all three DNP3 layers, the message is passed to the TCP/UDP transport layer. The transport layer adds a data block that identifies the Master port from which the request is sent and the port on which it expects the Remote DNP3 process to be listening for messages. The packet thus formed is then passed to the IP layer. Here a data block containing the IP and Media Access addresses of the Master and the Remote is added before the entire assembled packet gets passed to the Network Interface layer. The Network Interface layer verifies media access and availability and places the packet on the media for transmission.
After working its way across bridges and through routers (the modern equivalent of over the rivers and through the woods) based on the IP information, the packet finally arrives at the Remote. Here it passes through the same four layers in exactly the opposite order as it did at the Master. First, it is pulled off the media by the Network Interface layer. After confirming that the packet is intact and valid, the Network Interface layer simply passes it to the IP layer. The IP layer verifies the Media Access and IP address and passes it on to the TCP/UDP layer where the target port is checked for connected applications. If an application is listening at the target port, the packet is passed to the Application layer. If the listening application is the Remote DNP3 process, the Read request is passed through its three layers to validate the request and identify what information needs to be collected. The Remote response then follows the identical path in reverse to reach the Master.
A DNP3 message passes through the protocol layers at both the manager and the agent. Each layer addresses a specific communication task.
Using DNP3 in a contemporary SCADA system is an easy decision. DNP3 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-theshelf DNP3 Master or Remote will be a best fit for you.
Before you commit to an SCADA monitoring solution for either your operating center or your remote sites, you need to consider a multitude of factors.
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, summary graphical presentation can make detail an inconvenient click or two away when a decision needs to be made.
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.
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 continuing 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 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.
Make sure your master support 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.
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 or additional modules.
It is 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?
If your remote is powered from a single source, then your critical monitoring is vulnerable to a single event. 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 uninterruptable power supply. Also insure that the primary power is one of the points monitored at each location.
If a network failure compromises the collection of data, 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 insuring that they will be able to browse to your remote units and have local SCADA until the network is restored.
Before you make a decision about your SCADA DNP3 monitoring, there's a lot more you need to know. 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.
Get the information you need. Check out our Introduction to SCADA for a practical, step-by-step tutorial on how to implement SCADA monitoring in your network. You can also call us today at 1-800-693-0351 if you have questions or if you'd like to schedule a free Web demo of DNP3 monitoring solutions.
There is no other network on the planet that is exactly like yours. For that reason, you need to build a monitoring system that's the right fit for you.
"Buying more than you need" and "buying less than you need" are real risks. You also have to think about training, tech support, and upgrade availability.
Send me a quick online message about what you're trying to accomplish. I'll work with you to build a custom PDF application diagram that's a perfect fit for your network.
Join over 17,0000 customers and receive a personalized quote and virtual model. Then let our consumer vetted products and 30 years of industry experience do the rest.