Tutorial on DNP3: Messages, Layers, and Considerations - Part 2

DNP3 Tutorial Part 4: Understanding DNP3 Message Structure.
The fourth article in the DNP3 tutorial explores the packet structure of DNP3 communication. Helpful exploded packet diagrams will help you diagnose communication between DNP3 elements.

DNP3 Tutorial Part 5: Understanding DNP3 Layered Communication.
The fifth section of the DNP3 tutorial reviews the layered model of the protocol. This includes a description of the various layers, and what takes place in each. You will find a helpful review of a DNP3 packet assembly, transmission, receipt, disassembly in "Traversing the Layers".

DNP3 Tutorial Part 6: 8 Important Considerations in DNP3 SCADA Systems.
What about the when the rubber meets the road? The final DNP3 Tutorial section offers 8 important aspects in order to design and deploy a SCADA system. This module is particularly important for network operators and engineers. Don't be caught off guard by common but largely ignored features.

DNP3 Tutorial Part 4: Understanding DNP3 Message Structure.

Let's review the structure of messages sent between masters and remotes. Basic serial protocols, like TBOS, are byte-oriented. A single byte is exchanged per message. Expanded protocols, like TABS, use packets to communicate. The packets contain header, data, and checksum bytes. DNP3 is also packet oriented and uses the following structure (element sizes in bits):

The Master sends a Read request for an object or objects and the Remote's response contains the info, if available. The Master sends an Operate command to control an agent. The Remote sends an Unsolicited Message when a specific event occurs. The Master sends a Read request for an object(s). The Remote's response contains the info, 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 figure above shows the message packet format. The DNP3 application service data unit (ASDU) does something clever with the qualifier and indexSize fields. This design makes app data available in many configs or simply ignored.

DNP3 Tutorial Part 5: Understanding DNP3 Layered Communication.

DNP3 uses the layered communication model:

• The application layer combines several parts. Ther's an application service data unit (ASDU). Then there's the packaged object. An application protocol control info (APCI) block is added to make an application protocol data unit (APDU).
• The transport layer breaks the APDU into segments with a max size of 16 bytes and combines them with an 8-bit transport control header and 16-bit segment CRC separators into a transportFrame.
• The link layer adds a header to the control and address information. The packet is now ready for delivery.

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 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 show this layered model, let's look at a single DNP3 Read request over a LAN. The DNP3 Master wants to know the status of the Remote's power and prepares a Read request message for that 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 IDs the Master port and the port where it expects the Remote DNP3 process to be listening for messages. The packet is then passed to the IP layer. Here, a data block holding the IP and Media Access addresses of the Master and the Remote is added. Then, the full packet gets passed to the Network Interface layer. The Network Interface layer checks media access and availability. It then places the packet on the media for transmission.

After working its way across bridges and through routers (something like "over the river and through the woods") based on the IP info, the packet arrives at the Remote. Here, it passes through the same four layers in the opposite order as it did at the Master. First, it is pulled off the media by the Network Interface layer. After checking that the packet is intact and valid, the Network Interface layer passes it to the IP layer. The IP layer checks 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 app is listening at the target port, the packet is passed to the Application layer. If the listening app is the Remote DNP3 process, the Read request is passed. It moves through its three layers to check the request and see what info needs to be collected. The Remote response then follows the same path in reverse to reach the Master.

An Aid for Troubleshooting.

Knowing this layered model of DNP3 makes it easier to find and fix network problems. When there is a problem, you can simply trace it down, out one end, into, and up the other. LAN/WAN link and status lights provide show you to the Network Interface layer. ICMP echo requests and responses (Pings) provide some information regarding the proper functioning of the IP layer. DNP3 processing indicators can be used to verify the passage of the DNP3 packet through the TCP/UDP layer and the functioning of the Application layer. Each step can be verified independently until all steps are working correctly for end-to-end communication.

DNP3 Tutorial Part 6: 8 Important Considerations in DNP3 SCADA Systems.

Using DNP3 in a new SCADA system is an easy choice. DNP3 is a standard that has wide use in the industry and is useful for almost any application. DNP3 has its place in a good monitoring solution. Still, not any off-the-shelf DNP3 Master or Remote will be a best fit for you.

Before you commit to an SCADA solution for your operating center or your remote sites, you need to think about many factors:.

Before you buy - check for these 8 important features:

1. Masters should provide concise alarm info.
   Masters sometimes present data in such a pretty interface that you can't see the forest for the trees. Make sure that you have access to a list view. You need a good view of event and alarm detail for more than a single site or region. Sometimes, summary graphics can make detail a costly click or two away when a decision needs to be made.
2. Masters should be able to identify cleared alarms.
   If you will be using Unsolicited Messages in your system, make sure you have a clear event for each alarm. Creating this association can involve expensive custom development on your Master system.
3. Masters should maintain a history of standing alarms.
   Avoid the allure of keeping only an event log of new alarms and a history log of acknowledged ones. If a message means an alarm condition, there should be continuing visibility to the alarm even if the Unsolicited Message is acknowledged. Think what might happen to your network if someone acknowledges an alarm message, and then, for whatever reason, fails to correct the alarm condition. Who would know the alarm is still standing?
4. Remotes should support redundant power.
   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.
5. Remotes should provide local SCADA.
   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.
6. 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.
7. Masters should support flexible and powerful notification.
   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.
8. Masters should do more than 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 or additional modules.
   
   It is always difficult and uncomfortable to justify significant dev 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?

What to Do Next

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.

DPS Telecom Guarantees Your Success - or Your Money Back.

When you're choosing a network monitoring vendor, don't take chances. Be picky. Ask the hard questions. Above all, look for experience. Don't take a sales rep's word that his company can do custom work. Ask how many systems they've worked with, how many protocols they can integrate with DNP3, and check for client testimonials. DPS Telecom has created hundreds of successful monitoring implementations for telecoms, utilities, and transportation companies. (Check out http://www.dpstelecom.com/dpsnews/success_stories for some examples.) DPS Telecom monitoring solutions are proven performers under real-world conditions. You're never taking any risk when you work with DPS Telecom. Your SCADA monitoring solution is backed by a 30-day, no-risk, money-back guarantee. Test your DPS monitoring solution at your site for 30 days. If you're dissatisfied for any reason, just send it back for a full refund.

Get the information you need. Send an e-mail to support@dpstelecom.com for "A Practical, Step-by-Step Guide" on how to implement SCADA monitoring in your network. You can also call us today at 1-800-622-3314 to schedule your free Web demo of SCADA monitoring solutions, or register on the Web at www.dpstelecom.com/tmon-webdemo.

---

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.

---