Architecting OPC UA Systems

As most of you know, I’m a huge fan of OPC UA. Have been since I first started to study it six or seven years ago. I’ve always been impressed with its object modeling capabilities, the built-in security, the way that the protocol is separated from the transport layers, and everything else.

OPC UA is being deployed in a lot of systems in Europe and it’s starting to get some traction in the U.S. But what I don’t understand is why the people who want to deploy it are now in such a rush to deploy it everywhere and on everything. I know it’s the new thing and engineers love new technology – way too much in my opinion – but I see people going overboard (I once bought a DEC Rainbow because it was hot and new! It had both DOS and CPM. What a deal that was!)

I like the OPC UA technology. I like what it offers to an Ethernet-enabled industrial device, but like every other technology, it not right for every application.

I’m seeing complicated closed systems where people think that every device should be OPC UA-enabled. Typically they have their own proprietary Ethernet network to pass application-specific data from device to device, and for some reason they want to replace it with OPC UA.
In these applications OPC UA add’s Little value and a lot of configuration overhead. I see a lot of problems with it:

For one, it’s going to be more difficult for the Clients to access and keep track of all the devices in the manufacturing system. This is especially true if you have the kind of system that gets reconfigured on a regular basis. There are subscription lists, access lists, and more to update every time the system gets reconfigured. You’ve built in a lot of configuration overhead with no can upside in value.

Security is certainly more difficult the more devices you have that are OPC UA-enabled. If you have a lot of devices interfacing through the firewall, there is a lot more security overhead, many more certificates to deal with, and hence a lot more chances that one of your devices is configured improperly and you have a security hole you don’t know about.

It simply costs more. You not only have to buy more licenses, but you also have to maintain that software and keep more staff trained on it.

I’ve talked to power systems people, machine builders, and others who have this wrong. The right way to do it in many cases (not all) is to have one OPC UA device that is the interface to the outside world. That device collects factory floor data (an aggregator) and transforms it into OPC UA data. OPC UA has data aggregation capabilities built into it. If you have multiple OPC UA devices, it wouldn’t be hard to make that aggregation work for non-OPC UA-enabled devices.
A multi-protocol cloud communication proxy thingamajig is the right approach. I hope that more people adopt that way of architecting these systems that connect factory floor devices to the enterprise and the cloud.