“Should I use OPC UA or MQTT or AMQP?”

“What is the difference between Pub/Sub and Client/Server architectures?”

These are some frequently asked questions that have a need of addressing.

Disclaimer: Rather than a comprehensive guide, this post is intended to give an overview about the referred protocols.

Definitions

So that you can judge, follows a brief description of each term/topic:

OPC AU

OPC Unified Architecture (OPC UA) is a cross-platform, open-source, IEC62541 standard for data exchange from sensors to cloud applications developed by the OPC Foundation

BacNet

BACnet is a communication protocol for building automation and control (BAC) networks that use the ASHRAE, ANSI, and ISO 16484–5 standards protocol.

MQTT

MQTT (originally an initialism of MQ Telemetry Transport) is a lightweight, publish-subscribe, machine to machine network protocol for message queue/message queuing service. It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth, such as in the Internet of Things (IoT). It must run over a transport protocol that provides ordered, lossless, bi-directional connections — typically, TCP/IP. It is an open OASIS standard and an ISO recommendation (ISO/IEC 20922).

AMQP

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.

What now?

MQTT and AMQP are message queue protocols that take care of providing better ways to transport the data, it does not care about the structure of its payload.

In short, when aiming at high performance with minimal bandwidth, Publish/Subscribe is more efficient than hand shaking based protocols like Client/Server.

OPC UA and BACNET are two of the most widely used protocols for defining data structure by providing a standardized way of modelling data so that it can be easily accessed and understood by different systems. One way or another, both can ensure that the data communication is secure, accurate, and up-to-date.

BacNet provide a rigid object model with it’s pro and cons while OPC provides a framework with generic objects where the user is in charge to create the model. The big plus of OPC UA is that one case encapsulate BacNet data into OPC UA to make the transport more flexible and secure, on top of that to add another layer of flexibility a message queue base protocol can be used to transport the data, in this case MQTT or AMQP can be used.

Below is the way to map BacNet into OPC UA:

MAPPING BACNET ➞ OPC UA

– BACnet Objects / Properties ➞ OPC UA Object Types

– BACnet Events ➞ OPC UA Alarms & Conditions

– BACnet Logging ➞ OPC UA Historical Access

– BACnet Data Structures ➞ OPC UA Structure Data Types

– BACnet Units ➞ OPC UA Engineering Units

While BACnet uses a flat model (structured objects providing their properties) OPC UA allows for inheritance. Wherever possible, the mapping combines functional items in re-usable groups. E.g. alarm parameters are collected as a group of properties and can be used for different object types.

Rather than competing with BACnet, OPC complements it by coming into play where BACnet leaves off.

The premise of OPC is simple: it introduces an abstraction layer between devices and applications to allow data to pass between them without them being aware of each other’s internal data representations.

OPC UA Part 14 defines a Pub/Sub architecture for both LAN and WAN based communications.

The difference between the two is what type of transport is used, since there are different challenges to overcome in different environments:

– For lateral connectivity (subnets, LANs): UDP

– For vertical connectivity (cloud environments, WANs): MQTT or AMQP

In other words: It is not a question of OPC UA vs. MQTT vs. AMQP vs. BacNet…

It is a question of if there a need of translate BacNet into OPC UA and what transport is best. MQTT and AMQP are options.

Client/Server vs. Pub/Sub

From a data speed perspective, there are different reasons for using one data connectivity method over another. Client/Server is great for working with low-frequency data (10 ms and above, e.g. supervisory control). Pub/Sub is great for working with high-frequency data (1–10 ms range, e.g. streaming real-time data).

Why use OPC UA?

The key here is with the OPC UA PubSub specification (Part 14) you can choose whichever method works best for you without giving up the power of what OPC UA delivers:

1. Proven Security

Using OPC UA over MQTT gives you END-TO-END encryption. This means encryption is established between the OPC UA publisher and OPC UA subscriber so data remains encrypted regardless of how many hops there are between the publisher and subscriber. This is in contrast to MQTT-only security which relies on each broker along the route not being compromised.

2. Data Context

People often get side-tracked in data connectivity standards discussions by the idea that ‘context’ (metadata) can simply be preserved by sending the complex data encoded in JSON or XML.

While you can encode data using whatever custom scheme you want (e.g. defined contract between edge based publisher and cloud based ingester subscribing to it) this does not solve the massive problem of getting all vendors, from all industrial and commercial sectors to agree to use the same schema.

This ultimately leads to data lakes full of data based on countless schema encodings, each of which the ‘big data’ applications need to be aware of to make any sense of the data.

What OPC UA provides is a de-facto method of expressing simple or incredibly complex data relationships in a standardized format which, can be understood by all OPC UA compliant components. For applications where PubSub transport is better suited, OPC UA uses the PubSub transport but still retains the original data relationships because it uses OPC UA object encoding.

3. Industrie 4.0 / IIoT Readiness

Using standards-based data connectivity is essential to ensure we are building a truly ubiquitous, connected world.

With regard to Industry 4.0 in Germany, after extensive independent testing, the BSI identified OPC UA as the data connectivity standard for making Industry 4.0 a reality.

This is one reason why all major vendors are pushing forward with OPC UA implementation in their products.

Taken as a whole, the conversation about ‘data connectivity’ also needs to extend to how that data is used.

OPC UA also allows for its components to securely send commands to each other, allowing them to directly act/react to data rather than just passively send it back and forth and rely on other applications to make it actionable.