Not OPC UA’s Time in the Sun

I try very hard to not write anything controversial. It’s not that I shy away from controversy but the fact is, I don’t answer the phone. When I write stuff that makes people mad, and you can imagine how easy that is in 2016, they call. And when they call I don’t answer the phone. The inbound sales people have to take the phone calls. And they get yelled at and sometimes worse. So I avoid the obvious issues like religion, politics, and sex.(mostly)

But today I am going to step in it. I am going to get into it deep and some people aren’t going to like this. It’s about OPC UA and it isn’t going to be flattering, but my responsibility here is to give you, the automation engineer, wise counsel. My job is to provide information you can use, not advertising fluff that is going to mislead you. Last week I told a potential customer to not implement OPC UA. I said it wasn’t a good time to move forward with it. That’s not what some people want me to say but I have my reasons.

On a technical level, I don’t think OPC UA is ready. Let me explain.

Over-engineered

The initial revisions of the architecture – it is an architecture and not a protocol – were designed with very elegant publish-subscribe services. These services were, as a lot of things designed by committee are, designed to meet everybody’s needs and “over engineered” (if you’ll allow me a charitable way to express it). The result being that only the most resource-rich devices could possibly implement the Pub-Sub services in any meaningful way.

In the rush to get product to market, Client devices, usually Microsoft PCs, implemented that technology as did Server vendors with the bandwidth and RAM. And then there was the great, “Uh Oh – How is this going to work for small embedded devices?” Truth is, the design was so resource-intensive that it couldn’t be implemented in small devices. So that’s being thrown out and a new Pub-Sub design is underway.

If that wasn’t bad enough, the first vendors that rushed product to market didn’t support the standard read/write attribute services that are the core of technologies like BACnet, Modbus, and CIP. Low- resource devices that could be OPC UA compliant were now out in the cold because there weren’t any Client devices that supported the services they offered. YUCK is the technical term for the situation.

Multiple generations of OPC UA

So now, once the new Pub-Sub is released (2017-ish) we are going to have multiple generations of OPC UA. Some Clients in applications using the old Publish-Subscribe, some using the new Publish-Subscribe, some small resources devices that are compatible with neither, and newer clients that may do this, that, or the other thing.

Another OPC UA issue that troubles me is the messaging of OPC UA to the market. A technology needs a simple message so that the market can assign it properly to the hierarchy in their mind. EtherNet/IP had a position in the head of the customer: as the Ethernet I/O technology for Allen-Bradley PLCs. Simple and straightforward. Not a lot of thinking involved.

What’s architecture to the control engineer?

With OPC UA it’s not that simple. In fact, it’s not simple at all. OPC UA is an architecture. Software guys – people with degrees in software engineering and such – know what that means. The average control engineer, not so much. He wants a slot to stick OPC UA in. Is it the slot for moving factory floor data to the Cloud, it is a real time factory floor I/O protocol, or is it an IoT technology? The architects say it’s all those things. But anything that’s everything to everybody is nothing to nobody. And that worries me.

If the customer can’t really figure out what it is, the technology is in trouble. I support OPC UA. I’ve written two books on it. I love how it’s designed (mostly). But, to tell you the truth, I don’t know where the technology is headed.

And that’s why I advised my client to wait and let OPC UA sort itself out for a while.