the factory floor

Introduction

Adaptive, responsive and connected manufacturing only happens when there are consistent, standard mechanisms for accessing OT devices and describing data and its metadata characteristics. Information models are what make that possible.
For too many years, many of us in industrial automation focused on the wire protocol, the merits, features and functions of which were debated endlessly. That was relevant in the past but now, with today’s new requirements for more and more data especially what’s needed for Industry 4.0 applications, the data model (a.k.a. “information model”) is of critical importance. It is unquestioningly where the value in industrial automation is created and thus, the component of a manufacturing system that deserves significant attention.

An information model is the representation of concepts, relationships, constraints, rules and operations that capture the characteristics of a device, a process or other entity. It provides a sharable, stable and organized structure for communicating information about that system or entity. It defines a component of the process, devoid of any information on how those characteristics captured by the model can be stored or accessed.

An information model can be as complex or as straightforward as its architect desires. It has infinite flexibility to describe a device or process in whatever way serves best. When complete, it documents that component using a standard language and symbology that conveys to everyone exactly what each entity is and what relationship exists between those entities.

But if it’s customized for a particular application, it’s relevant to that application and only to that application. A pump may be modeled with the characteristics speed and RPM. Someone else might have defined a pump model that includes the current flow rate. The RPM value might be an integer in one system and a float in another. Since both modeled the pump differently, there is no saving in labor or productivity for any of your customers. They might have the model and an open standard communications interface (like MQTT, for example) but they still must incorporate those proprietary characterizations of the pump. That leaves manufacturers where they’ve always been, repeating an integration again when different pumps are used in different applications.

It’s actually worse than that. This discussion hasn’t even considered common transports, data encoding and access to the data contained in the information model. It’s one thing to define a nice information model for a device, a machine or production line, but if there isn’t any standardized way for others to know that you are using that model, to know what’s in it and to easily access it, it doesn’t save anybody any time or money. It creates no value.

And that’s the problem that many of us have faced over the years. A lot of the models were tightly integrated with a specific technology or communication protocol. In other cases, the information model was designed specifically to solve problems in one particular application domain. And when there was a mechanism to create a flexible information model, there wasn’t a standardized way to deploy the model in an actual system.

Connecting Information Models to Applications

The two most popular methods for moving information models from factory floor devices to enterprise and cloud applications are OPC UA and MQTT. Obviously, OPC UA is a good choice if you are using OPC UA defined information models. OPC UA not only provides system architects with a common infrastructure for modeling data, but it also provides the transport, encoding and security necessary to use it effectively.

MQTT is a fundamentally different kind of architecture from OPC UA and from everything we’ve ever used on the factory floor. The publish/subscribe architecture is unique. There have been other publish/subscribe architectures proposed and implemented previously, but MQTT is the first, widespread technology using that architecture to achieve common acceptance on the factory floor.

The publish/subscribe architecture allows a message to be published once and any number of clients can receive it with complete message decoupling between the producer of the data/events and the consumer(s) of those messages/events. Data is arranged by topic in a hierarchy with as many levels of subtopics as needed. Clients can subscribe to a topic or a subtopic.

The other fascinating facet of MQTT is that it utilizes a central server, known as a broker, to facilitate communications between devices. A broker receives the information from ”publishers” and organizes the information by topic subscriptions. The information is then distributed to every subscriber that requested to receive messages regarding that particular topic. If no consumer requires the information, the information is discarded.

The MQTT Sparkplug enhancement vastly improved MQTT, particularly in manufacturing applications.
1. It standardized how publishers and subscribers name topics, reducing confusion
2. It defined a schema for the payload of a message
3. It allowed subscribers to get status from the end devices generating data

Standardized topic names expedite system integration. The content definition allows interpretation of MQTT message data without the need for additional metadata. With state management, clients can have accurate state data on the data generators, improving the ability of clients to manage data.

MQTT is a good a solution for many small, non-closed loop IoT applications. It has a large number of adherents because of its small footprint, simplicity and “push” architecture. Many of the same large automation vendors and cloud vendors that support OPC UA also support MQTT. It is a reasonable solution for IoT prototyping, small, in-house applications but may not be the right solution in the era of open, widely available data models for all automation devices.

OPC UA is a good solution for many Industry 4.0 systems not requiring massive data transfers to many different clients. Manufacturers who anticipate a future with downloadable data models will find that OPC UA is the only solution that promises support for all the data model architectures being developed to ease integration in the future. Manufacturers must ensure that their vendors have well-implemented, certified and supported OPC UA implementations.

Like all other automation battles that have been fought over the years, there is not going to be a clear winner. Both technologies will grow and prosper. Developers, integrators and system architects will eventually come to learn where they have the best success with OPC UA and the best success with MQTT. Neither will be the sole solution, and that is a loss for manufacturers who are going to have to understand, support and work with both technologies and figure out which works best for which applications.

Connecting Traditional Industrial Equipment with MQTT