3753

DNP3 Introduction

Distributed Network Protocol (DNP3) - Learn the fundamentals and how to understand this industry-standard SCADA protocol to get started with DNP3 today!


1. How This Tutorial Will Help You

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.


2. An Introduction to DNP3

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.

DNP3 uses a Master/Remote Model

DNP3 used in a master/remote architecture

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.


3. How DNP3 Elements Communicate

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.


4. Understanding the DNP3 Object Library.

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.


5. Understanding DNP3 Message Structure

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 following figure shows the message packet format. 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.


6. Understanding Layered Communication

A Critical Tool for Troubleshooting Communication Problems

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.

Traversing the Layers

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.

DNP3 message

A DNP3 message passes through the protocol layers at both the manager and the agent. Each layer addresses a specific communication task.


7. Eight Important Considerations in DNP3 SCADA Systems

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.

  1. Masters should provide concise alarm information
  2. 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.

  3. Masters should be able to identify cleared alarms
  4. 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.

  5. Masters should maintain a history of standing alarms
  6. 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?

  7. Masters should sort and filter alarms
  8. 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.

  9. Masters should support flexible and powerful notification
  10. 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.

  11. Masters should not be limited to DNP3
  12. 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?

  13. Remotes should support redundant power
  14. 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.

  15. Remotes should provide local SCADA
  16. 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.