OPC UA Pub Sub Under Construction

There are a lot of things I like about tradeshows. I like seeing friends I don’t often see, finding really cool and innovate products (and saying wish I had thought of that), and getting energized from all the lights, machines chunking along, and sales people trying to sell. It’s invigorating.

What I don’t like is how sometimes you find products that aren’t quite what they are advertised to be. It’s been done forever. A vendor is in a competitive market so they rush a demo to the tradeshow that seems to indicate that the product or technology is a bit further along than it really is. Sometimes it’s just pre-released, but other times it’s really very early in the development cycle.

In my estimation, OPC UA with Pub Sub is one of those products that is still early in the development cycle. After Hannover Fair I took some calls from people asking me for advice about deploying it. I had to tell them that, in my opinion, it’s just not quite ready yet. There are a number of reasons why:

1. TRANSPORT ISSUES – There are two transports for Pub Sub: AMQP and UDP Multicast. If you are going to use AMQP, there isn’t any problem. But UDP Multicast still has issues. UDP Multicast is unreliable—packets can and do get lost. How do we overcome that? Do we send the packet twice? Three times? Dozens of times? Or do we live with the fact that a device receiving OPC UA Pub Sub packets over a multicast link is unreliable? There are more applications than not where that unreliability is not tolerable. I’m not sure how, when, or if this will be solved.

2. PACKET CONFIGURATION – A more important question regards the contents of a Pub Sub data packet. “How does the receiver decode the Pub Sub packet?” The packet is just a series of bytes. Does it contain I/O, a drive speed, energy data, or temperatures? The demos to date, as far as I know, use a vendor defined, hardcoded data mapping. Both sides are manually configured with the data mapping. I’m pretty confident that the tradeshow demos use that kind of preconfigured packet mapping or some vendor-specific mapping. That’s really not a long term solution. We need a way for a device to specify some set of specific data it wants to receive—a dataset in OPC UA Pub Sub terminology.

The Pub Sub working group has defined configuration models that can be used by a Client to define datasets to include in the packet. Unfortunately, there is no configuration tool that can provide a configuration to devices and no mechanism for one device to send that data definition to a publisher device. Yes, an off-the-shelf Client can set this configuration and there is data to indicate which version of the dataset is being transmitted but it is not trivial for a new subscriber to get access to the configuration model, determine if a model exists with the desired data and then subscribe to it.

I do not believe this is completely workable as it exists today.

3. SECURITY – It’s also not clear how to secure Pub Sub data. The packets can be encrypted, but how do we make the keys available to all the receivers so they can decode the data? How often do we send new keys out? How do we make that key delivery reliable? What happens if the key server goes down? Do we just continue unsecured, or does the process go down? There is discussion of multiple, redundant key servers but that raises issues about synchronizing all those key servers.

4. Footprint Some of the work to define this means that an OPC UA device must be both a Client and a Server. That increases the size of the software footprint meaning that low end devices are less able to support OPC UA, and that’s not a design goal of the technology.

5. FLEXIBILITY – There is also no consensus on how Pub Sub must change to support TSN (Time Sensitive Networking). Is it going to market with how it’s been designed, or is it going to change to support TSN? The big discussion is between making Pub Sub data completely flexible vs. making it fast to decode. FPGA implementations want speed and little flexibility. Most software implementations want complete flexibility.

These are all significant issues that need to be sorted out. Yes, vendors are showing live Pub Sub demonstrations, but is the technology ready to be deployed? The answer I gave to the folks who called me is “not yet.” There are lots of very serious, hard problems to solve before we get the benefits of this really important, ground breaking technology.

This is very contrary to what you are going to hear from various members of the OPC UA community but though I fully support OPC UA my first loyalty is to our customers and providing as much accurate and factual information as I can.