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.

The OPC UA Information Model is the Standard

OPC UA1 is an open technology that provides the most well-known and comprehensive solution for defining information models. Information modeling in OPC UA provides enhanced organization, flexibility and scalability. It enables models that integrate with other enterprise applications, improve asset performance and reliability and act on your available data with greater agility and confidence.

    OPC UA information modeling is different than other technologies in several ways:

  • There is a consistent structure and standardized definitions that are flexible and adaptable for many application domains
  • There is a consistent and standardized structure to the documentation of the model (XML)
  • There is a mechanism for translating the information model into a real time data model (also called an address space)
  • There is a standard mechanism for clients to identify the model and access component definitions and type information at run time
  • The encoding, securing and transporting of values in the real time address space are entirely disconnected from the information model development

The OPC UA information model is being leveraged and adopted by many leading organizations working to promote smart manufacturing and streamline the implementation of Industry 4.0. CESMII being one of these organizations using OPC UA, sees smart manufacturing as the ability to better collect, contextualize, process and model data and allow more intelligent decisions about the manufacturing process.

Figure 1 – The CESMII Building Blocks for Smart Manufacturing (Used with Permission)

    The kinds of systems that these oversight organizations are building around OPC UA information models offer significant advantages to manufacturers:

  • Faster, open and reliable communication between devices, people and partners from an open and interoperable ecosystem
  • Optimization of process and material flows
  • Faster, more informed decision making
  • More rapid product changes with minimal intervention and easy reconfiguration
  • Proactive and semi-autonomous processes that act on near real time information

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

Real Time Automation is uniquely positioned to support manufacturers in this environment. Their communication gateways support both OPC UA and MQTT . That means that control engineers and operations staff now have the ability to reach into a Siemens S7, an Allen-Bradley Logix controller, an Allen-Bradley PLC5 and other controllers and devices to extract information and publish it to an MQTT broker or present it using our OPC UA Server.

Like all RTA gateways, the unit is extremely configurable. You can pick single tags, user-defined tags (A-B), data space blocks (Siemens) and other data using any one of the many protocol drivers in the RTA protocol suite. And on the MQTT side, the gateway publishes that data using topics that you define to the brokers you identify

1Part 5 of the OPC UA specification describes the OPC UA Information Model in detail..

For detailed information on moving data from a PLC or other network to a broker over MQTT or to an OPC UA client, contact us:

John Rinaldi
Chief Strategist and Director of WOW!


John S. Rinaldi is Chief Strategist and Director of WOW! for Real Time Automation (RTA) in Pewaukee, WI. With a focus on simplicity, support, expert consulting and tailoring for specific customer applications, RTA is meeting customer needs in applications worldwide. John is not only a recognized expert in industrial networks and an automation strategist but a speaker, blogger, the author of over 100 articles on industrial networking and the author of six books including: