OPC UA Isn’t the Complete Answer

As many of you know, I am a proponent of OPC UA. Have been for almost ten years now. Once I learned about its Discovery functionality, ability to model just about anything, “lego block” implementation and how a Client can browse through the object model to find data it might request, I was hooked.

So my saying that OPC UA isn’t the complete answer is probably surprising to a number of you. If you’ve been reading my articles over the years, you remember the disagreements I had with certain ODVA and Profinet International members who were claiming that EtherNet/IP and PROFINET IO were IoT protocols. You’ve seen the scores of articles and books I’ve written (available on Amazon) about OPC UA. Given all that, it’s unusual to have me saying anything negative.

But I’m actually not writing anything negative today. I am simply saying that OPC UA isn’t the complete answer in every application. I still firmly believe that the I/O protocols, EtherNet/IP and PROFINET IO, are superior for moving I/O data into and out of programmable controllers. I now think OPC UA probably isn’t the best answer for moving data to the Cloud. But unquestionably, OPC UA is the right answer for moving non-control data and information around the factory floor.

In that arena, what OPC UA lacks is an easy-to-use and implement application layer. Now, I can hear the howling already; the OPC UA proponents are jumping out of their chairs to argue this point with me and I hear them. Yes, OPC UA supports well-defined object models. Those object models can be made available to HMIs and other clients to easily implement communications to the OPC UA servers. Yes, that’s all true, but it doesn’t always go far enough, and that’s my point today.

OPC UA on every server of a production machine certainly means connectivity to HMIs and Server applications is easier than ever. In the kind of application where programmable controllers are controlling the I/O and OPC UA is offering the data connectivity, HMIs and server applications can easily use the object models of those devices to move information out of those devices without spending all the hours to tediously get the documentation on each device and enter the addresses or tag names. OPC UA simplifies the job.

But it doesn’t always go far enough. There might, for example, be three sections to a machine built by three different companies using three different motor drives. Each motor drive has a slightly different object model so there is some effort needed to know where the speed reference is on each motor drive. Certainly light years ahead of what we had before—but not perfect.

What would be even better is to use a mechanism for standardizing the application layer of the devices so that they look exactly the same. I’m seeing more and more of that these days. PackML is the standard for packaging machines. The cigarette machine manufacturers have another one and several other trade associations are building similar implementations.

What PackML does for the packaging industry is completely standardize the application layer implementation. Every device interacting with a PackML enabled machine component knows exactly what the tag is to get the machine operating state, what the tag is to get the machine speed, and so on. It takes the standard OPC UA object model implementation, which is extremely good, and makes it even better.

No. OPC UA isn’t the complete answer. But by adding an application layer like PackML, it becomes much closer to that complete answer.