OPC UA PubSub is defined in part 14 of the OPC UA specification and introduces publish and subscribe capabilities in addition to the client server model. This article reviews the current state of PubSub in open62541 and shows how it can be used to connect an OPC UA server directly with an Azure IoT Hub.
As always in OPC UA, the data mapping and transport mechanisms are very flexible. In case of PubSub, this means that messages can be transmitted directly into a network (for example as multicast via UDP or raw ethernet frames via TSN) or through a message broker using protocols like MQTT or AMQP.
Having one-to-many messaging in OPC UA is interesting for use cases where data is only sent sporadically (sensors) or where large amounts of values must be sent with a high frequency or on a fixed schedule. The ability to reach multiple consumers with just one publish also reduces the processing power and network bandwidth required by the producer.
The introduction of broker based messaging in combination with the JSON mapping is an important step in simplifying the integration of OPC UA with cloud based services.
OPC UA PubSub support in open62541
The PubSub implementation in open62541 is progressing rapidly.
So far, open62541 supports UDP, raw Ethernet and MQTT transports with UADP (binary) or JSON encoding.
Publishers can publish values of node attributes. If the publisher application is also an OPC UA server, it can optionally provide clients with meta information on the data it publishes.
A subscriber can receive messages. If the subscriber application is also an OPC UA server, it is able to expose the most recent received values in its address space.
The implementation is also real time capable.
Publishing to Azure IoT Hub via MQTT
In our “basysKom industrial automation showcase”, we use an open62541 based OPC UA server to provide data to different clients like HMIs or the cloud connector. The current cloud connector reads the data from the OPC UA server and then sends them to an IoT Hub using the Azure IoT SDK.
As mentioned in our IoT Hub article, an IoT Hub can also be used directly via MQTT. This requires a TLS capable MQTT client. For authentication, it must be able to login at the MQTT broker using username and password. Iot Hub Devices with X.509 certificate authentication must present a client certificate. In this case, only the username must be used during login. An exact description of the credentials, client id and topics the client must use are described here.
After a basic evaluation of the PubSub implementation in open62541, we wanted to replace the current cloud connector by publishing PubSub messages with JSON mapping directly to the MQTT broker of our IoT Hub.
Our contribution to open62541
The MQTT transport plugin has been extended with five new connection options:
|mqttUseTLS||Set this to true to use TLS for the connection|
|mqttCaFilePath||The path to the file containing CA certificates in PEM format|
|mqttCaPath||The path to a directory containing CA certificate files in PEM format|
|mqttClientCertPath||The path to the client certificate in PEM or DER format|
|mqttClientKeyPath||The path to the private key for the client certificate in PEM or DER format|
mqttCaPath are available, the system’s default location will be used. To use a client certificate, both of the
mqttClientKeyPath options must be specified.
TLS support has only been implemented for OpenSSL for now. It is activated by building open62541 with the CMake option
UA_ENABLE_MQTT_TLS set to
With this implementation, we were able to publish telemetry data directly to the IoT Hub using the username / password as well as the client certificate approach. We were able to remove the external Azure IoT Hub client from our “industrial automation showcase” resulting in a more streamlined implementation.