The Special Interest Groups (SIGs) for OPC UA are doing a lot of interesting work. Probably the most interesting is the development of what’s called “PubSub.” The name is not advantageous. OPC UA was originally released with something called Publish–Subscribe and the PubSub name leads to a lot of confusion.
The original Publish–Subscribe is a feature of OPC UA that allows an OPC UA Client to request a Server device to publish some variable(s) to it on a schedule requested by the Client. The key to this feature is that it is one Client to one Server.
That feature is unlike IoT (Internet of Things) devices which can publish data that can be read by many devices. To make OPC UA compatible with IoT applications, the PubSub features was born. Its mission is to provide a mechanism for publishing Server data to many Clients. With PubSub, OPC UA applications do not directly exchange requests and responses. Instead, Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what Publishers there are.
Among other things, PubSub allows peer to peer communication between controllers and between controllers and HMIs. The peers are not directly connected and do not even need to know about the existence of each other. It also allows things like asynchronous workflows and OPC UA Servers to stream data to applications hosted in the Cloud.
OPC UA PubSub is new technology that is NOT yet in general release. It is still under development. Here’s some key information about this development:
1. PubSub is described in Part 14 of the OPC UA specification. That Part is in preliminary release but is continuing to undergo revision.
2. PubSub groups Server variables into something called Datasets. Datasets form the packet data that is transmitted in the selected transport.
3. PubSub, just like other OPC UA features, will support JSON, binary, and other encodings. One of the real powers of OPC UA is the ability to easily plug in different encodings, transports, and security.
4. PubSub will be compatible with AMQP and will work (let’s hope it’s seamless) with Microsoft’s Azure IoT Hub. Microsoft will most likely have gateway technology that will connect a dataset to the IoT hub.
5. PubSub will also be compatible with an OPC UA defined transport called UADP (Unified Architecture Datagram Packet) and many other transports like MQTT and others. These transports would most likely be used in applications where small packets of data are frequently transported to a set of Clients.
6. The elephant in the room is configuration. How do the datasets get defined? Will there be a tool to define these datasets? Can a Client define the dataset? Can an application read that configuration to understand the data transmitted in the packet? There is a ton of work to do on the configuration part of PubSub.
7. PubSub technology is now being revised to accommodate the new TSN technology.
8. Some demonstration applications have been built, but to date, configuration for those systems has been done manually.
Don’t expect to start using this technology anytime soon. PubSub is still under development, and I wouldn’t expect widespread use until 2018.