The Odd Couple: OPC UA and Modbus

If you’ve been around this planet for a while I’m sure you’ve run into the couple that you just can’t figure out. She’s incredibly outgoing, and fun with an enormous group of friends, while he’s a complete introvert who hardly ever says a word. Or she’s barely 5 feet tall while he’s a gigantic 6 foot ten. If you’ve met couples like this you’ve probably thought, “How does that work?”

Well, that’s what I heard on a conference call recently when I mentioned that OPC UA and Modbus actually can work very well together. “What?” I heard from the other end of the line. “They’re completely different;they’re incompatible.” Well, not so much.

You have to remember that OPC UA is designed for components. More than any technology I’ve ever seen, you can think of it as if it has pieces that you can pull out and replace. For example, if your application only uses binary encoding, you don’t have to have the XML encoding piece. But if you wanted XML, you could add a module that did the XML encoding. Or if you were really adventurous, you could create your own encoding and stick that in instead of, or even side-by-side with, XML and binary. No one else could decode your messages, but that might be OK.

LEGO for industrial automation

The whole OPC UA architecture is designed like this. It doesn’t have just one transport; it currently has HTTP, HTTPS, Web Services and others. You could add another if there is one you’re particularly partial to. Security is a component, too. If you don’t like TLS security, replace it with another security component. OPC UA is a LEGO system for industrial automation. You can build it anyway you want.
You can even change the messaging that is used. Instead of the messaging defined in the spec to access OPC UA objects, you can use another kind of messaging, Modbus messaging for example. The following drawing illustrates this. An OPC UA device might be composed of a system component, an OPC UA software component and the user application component.

The application component is normally going to be composed of the OPC UA object model for the device and the component that knows how to process commands against the set of objects that compose the object model. The Service Set component decodes a command from a client like Read Attribute 5 of Object 319. That gets passed to the user application which knows what Object 319 is and how to locate attribute 5.

Why have a Modbus command delivered by OPC UA? But, because OPC UA is flexible, you can replace the Server set and the user application with Modbus. Now the software stack deliver a Modbus command like Read Register 41010. And the user application processes that command just like it came in over RS485 or over Modbus TCP. Same command, same structure – it’s just that OPC UA delivered it.

Why would you want to do this? Well, now those Modbus operations can benefit from all that the OPC UA architecture offers. They can use Security. The commands can be signed and encrypted. Your Modbus application could know that only authorized and authenticated users can send those commands. Or, in a different kind of environment, your Modbus commands could be delivered using a transport not supported for Modbus.

Your Modbus application code now doesn’t change but it gets the full power of the OPC UA architecture. And even though this “odd couple” may not, at first glance, seem to belong together, they actually are quite a good pairing.