It seems many companies think that Message Queuing Telemetry Transport (short MQTT) can solve all their data integration issues. And there has been a lot of industry chats about this topic. But can it really do that?

The  MQTT has been successfully used to communicate data for over 20 years. It is by design lightweight and has fared well when benchmarked against other competing protocols (e.g. OPC-UA). The central component of the MQTT architecture is the message broker, which allows devices to subscribe to or publish data to a central repository. This architecture makes MQTT very attractive as a central data exchange in manufacturing to integrate different components such as Automation Layer, Historians, MES, ERP and others.

The MQTT message has two components:

  1. Topic
  2. Payload

The MQTT topic is used to route message and allow subscribers to filter messages. The routing by topic requires a design that specifies the location of the data source. If the MQTT broker is used on the enterprise level, it is recommended to use the ISA-95 standard to define the MQTT topic which is often referred to as Unified Name Space (UNS). The following shows the topic as unified names space:

Enterprise A/Site A/Area A/Process Cell A/Bio Reactor 0

MQTT by itself does not specify a message structure and in many IOT applications the payload is simply a JSON string. The JSON is deserialized by the MQTT subscriber (here Ignition) into a tree structure:

OSIsoft AF provides an extensive class or type system for assets (equipment), frames (batch, alarms, OEE) and transfers (traceability and genealogy), where enterprise level equipment structures are either manually created or autogenerated by interface specific connectors.

To publish OSIsoft AF data into the MQTT unified name space is simply to serialize the AF structure into the MQTT topic and attach the attribute values as JSON payloads. As any other MQTT component, OSIsoft AF can be a subscriber, publisher, or both. As a subscriber OSIsoft AF can deserialize the MQTT message and the resulting AF structure can be contextualized by templating (inheritance), categorizing, and referencing.

MQTT with the unified name space is a very elegant way of routing structured data, but the JSON payload is not an ideal solution for several reasons:

(1) There is no clear definition how to structure industrial sensor\time series data.
(2) JSON structures are bulky.
(3) There is no standard way of compressing the payloads.

Is there an alternative?

The SparkplugB standard was developed to address both the data structure and throughput requirements for industrial sending sensor data. There are a couple of key mechanism to accomplish this:

It has exactly five components:

Structuring the unified name space, requires splitting the asset definition between the topic and payload and can lead to an identical structure as described above in the JSON example:

The SparkplugB payload can also be used to serialize (publish) or deserialize (subscribe) OSIsoft AF structure. To subscribe to MQTT SparkplugB, OSIsoft offers a compliant MQTT connector.


The MQTT SparkplugB standard together with the unified name space concept is an efficient way to exchange sensor or other time series data. There are, however, a few limitations that need to be considered:

Despite above limitations, an edge node can readily publish an ISA-95 compliant OSISoft AF asset structure into the unified namespace. The time-consuming task of mapping OCP or PLC into human readable asset paths has already been concluded when the OSIsosft AF system was setup and configured. An additional benefit shows equipment centric calculations that can be streamed to the MQTT broker and be consumed by MES or ERP systems.

When MQTT SparkplugB data are consumed by the OSIsoft AF system, the equipment centric data stream can be deserialized into an asset structure.

This can lead to significant savings in the integration task, which normally requires the tedious step of mapping the automation layer into the IT layer.

There is an added effort to contextualize the data and add additional abstraction layers such as base classes\inheritance. Frames and transfers must also be configured to allow for the modeling of time-based models (MVA or ML). These steps are essential to rollout MVA\ML models at scale.

MQTT SparkplugB is a real step forward in the Level 1,2 and 3 integration. Level 3+ system as well as MVA\ML models require an extensive type system that can’t readily be flattened into the MQTT SparkplugB standard.

For now, Level 3+ and MVA\ML systems still require a fair amount of integration and configuration.

For information, please contact us.

© All rights reserved.