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.
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 uses the layered communication model:
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.
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.
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.
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 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.
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.
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.
Your network isn't off-the-shelf.
Your monitoring system shouldn't be, either.
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