Tutorial on DNP3: Intro, Communication, and Objects - Part 1

What is DNP3?

DNP3 is a communications protocol used in SCADA and remote monitoring systems. It is widely used because it is an open protocol, meaning any manufacturer can develop DNP3 equipment that is compatible with other DNP3 equipment.

DNP3 used in a master/remote architecture

In a typical DNP3 network, information is passed from the Remote up to the Master. Usually the Master requests the information from the remote, but in the case of alarms, the remote will initiate an exchange rather than wait for a request from the Master. This assures that alarms are attended to in a timely manner.

DNP3 uses a Master/Remote Model.

DNP3 is typically used for communication between central Masters and Remotes. In a typical network, the Remotes gather status information from mission critical gear. Any time there is an alarm, that information is pushed up to the Master via DNP3 for appropriate action.

How do 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. 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.

Understanding the DNP3 Object Library.

The DNP3 framework includes a library of objects that are used in many SCADA systems. This library is free for DNP Users Group members. Visit www.dnp.org for more. These standard objects include Binary Inputs. These will report things 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 things 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 you.

Without this framework of common objects, manufacturers must develop their own model for reporting status and providing control capability. These models, often very different, must then be 'compiled' into the Masters and 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 time stamp. Note that the Analog Event group does not include variations without a status bitmap.

Part 2: Messages, Layers, and Considerations

Get a Custom Application Diagram of Your Perfect-Fit Monitoring System

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.

Make an Informed Decision

Your network isn't off-the-shelf.

Your monitoring system shouldn't be, either.

Customized monitoring application drawing

We'll walk you through this with a customized monitoring diagram.

Just tell us what you're trying to accomplish with remote monitoring.

Get a Custom Diagram