I Want OPC UA…

I don’t know how many of you remember any of the old Windows products back when Bill Gates was in charge. Two that I recall (not fondly) were Windows 2.0 and Windows 3.0 – also called Windows for Workgroups. What was nice about these products was the lack of complexity. You simply stuck a floppy disk in the drive and rebooted your computer. It would boot up and transfer that Windows version to your computer. If you wanted to install an application, you just copied it into a directory and clicked it. Of course, along with the simplicity was a lack of functionality and no security, but it was easy to manage your computer in those days.

We had the same kind of simplicity in the early days with things like Modbus TCP and EtherNet/IP. I had a lot of calls from control vendors who needed to enable their device with one of these technologies. All I really needed to know was if they wanted to be a Client or Server on Modbus TCP, or a Scanner or Adapter on EtherNet/IP. Once I knew, I would describe how they could achieve connectivity by using our royalty free source code.

Now with OPC UA, it’s much more difficult. Even the base decision of whether you want to be a Client or a Server isn’t all that clear. There are reasons for end devices to be Servers and there are reasons for end devices to be Clients. There are reasons for a device to be both. It’s not clear without some thoughtful discussion which of those makes the most sense.

Once we’re past that discussion, we can move on to the question of hardware compatibility. OPC UA requires 8K buffers for the send and receive channels. Does the target hardware support that? And if not, what are we going to do about it? The questions are endless:

Security – OPC UA provides the security infrastructure, but how will your device handle certificates, if you choose to use certificate based security? Where will you store your certificate? Will it be self-certified? How will you validate certificates received from Client devices?

Encodings – OPC UA supports multiple types of encodings. What kind of encodings do you want to support?

Endpoints – How many endpoints will you support? What kind of security, encodings and functionality are supported on each of the endpoints?

Clock functionality – OPC UA requires messages to be timestamped. Does your device have a Real Time Clock (RTC)? If not, how will your device get and maintain the current time?

Object Model – How does your data map into an OPC UA object model? Will you map the data straight or will you add metadata tags to the data?

Messaging – How will your device message other devices? Should you support the Publisher–Subscriber communication model, the Read–Write Attributes communication model or the new, horribly named, Pub–Sub communication model?

PackML – PackML is an application layer protocol for machine control being widely adopted. Is PackML right for you?

There are many possibilities and many questions to answer with OPC UA. You’ll want a partner that’s experienced, that’s implemented OPC UA products and has demonstrable expertise in the technology. That’s the partner RTA can be for you.

To get started, it’s time to get familiar with this technology. A good place to begin is “OPC UA – Unified Architecture: The Everyman’s Guide to the Most Important Information Technology in Industrial Automation.” This book provides a deep dive into a lot of the technology behind OPC UA.