OPC UA PubSub over MQTT: A Minimal Implementation

When developing a standard there are two conflicting requirements that need to be constantly balanced:

1. The standard needs to be simple to implement;
2. The standard needs to specify enough to allow plug and play interoperability between the majority of real-world applications.

For example, any coder can write a “standard” that takes a protocol like MQTT, defines a message envelope with an encoding and says applications can put whatever they want in the envelope. However, there would be no real-world interoperability because every application would need custom code to define and interpret the contents the messages.

On the other hand, it is very easy for standards committees to add so many features that it makes implementation difficult for people with simple problems to solve.

OPC UA addresses these conflicting requirements with a tiered model. In this model, it is possible to create a basic implementations with little effort that can still interoperate with fully featured applications that need and use the more advanced features. The UA-IIoT-StarterKit has been updated to support the 1.05.03 release of the OPC UA specification and includes a series of Quickstarts that illustrate the layering that is built into OPC UA PubSub over MQTT.

Tier 1 - Minimal Interoperable Application

Publishing

Take a simple sensor, which only has a few values it needs to publish to the Cloud. It can represent its data in JSON like this:

{
   "CalculationPeriod": 3600,
   "Consumption": 42.40980168903136,
   "DutyCycle": 0.9716110204934759
}        

This message can be published by adding some logic to periodically send JSON messages with updated values to the 'data' topic defined by OPC UA.

The Publisher also reports its presence to the broker using the ‘status’ topic with a message like this:

{
   "MessageId": "dcaaf73d-0c1c-4d14-9ed1-7475e7776a3f",
   "MessageType": "ua-status",
   "PublisherId": "(Quickstart001)",
   "Status": 2
}        

This message may be sent periodically or take advantage of the WILL message feature in MQTT that sends a message when the broker detects that a publisher has gone offline.

The 'status' message allows any Subscriber to discover all of the Publishers that exist in the system and to automatically update its configuration as Publishers come and go.

The Quickstart_001 implements the basic Publisher in C# with 47 lines code and requires no dependencies other than a MQTT client library. Similar trivial implementations are possible in any language with built-in class to JSON serialization such as JavaScript or Python.

Subscribing

A basic Subscriber wants to consume data from all Publishers. It understands JSON and can treat data it does not understand as name-value pairs that are stored in a Cloud database for future processing.

The basic Subscriber uses MQTT wildcards to subscribe to the OPC UA defined 'status' topic which has the form:

opcua/json/status/<publisher-id>        

where the <publisher-id> is an identifier for the Publisher that is unique in the system. The 'status' topic allows the Subscriber to discover the Publishers in the system. It could use this information to select specific Publishers that it is interested in or it can again use MQTT wildcards to select all data published to the OPC UA defined 'data' topic which has the form:

opcua/json/data/<publisher-id>/<group-name>/<writer-name>        

where the <publisher-id> is an identifier for the Publisher that is unique in the system. The <group-name> represents a logical grouping of published datasets

The Quickstart 001 implements the basic Subscriber in C# with 50 lines code and requires no dependencies other than a MQTT client library. Similar trivial implementations are possible in any language with built in class to JSON serialization such as JavaScript or Python.

The Limitations of the Tier 1 Applications

The minimal Publisher produces messages that can be processed by any OPC UA Subscriber, however, the Subscribers need to either infer the meaning of the data from the JSON or rely on out-of-band knowledge. This makes Tier 1 applications only useful for very simple devices or devices that comply with a well known OPC UA Information Model such as Robotics. That said, most small Publishers should find it easy to provide static data that allows them to implement a Tier 2 or Tier 3 application and maximize the usefulness of their application.

The minimal Subscriber is limited to messages that do not have any of the additional headers defined by OPC UA. However, OPC UA Publishers that support more features can be configured to omit the headers which means the minimal Subscriber can interoperate with any other OPC UA application that supports MQTT using the JSON encoding. That said, it is straightforward to create a Subscriber that can handle all three standard header profiles which would maximize the usefulness of their application and not require that other applications be configured to deal with the limitations of a Tier 1 implementation.

The next article will dig into Tier 2: Describing the Message Content.