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:

• The MQTT topic is well defined:
  namespace/group_id/message_type/edge_node_id/[device_id]

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 Payload is standardized and uses the “Google Protocol Buffers” (short protobuf) encoding, which leads to very small payload sizes. Sensor data are sent using well-structured time series formats that include UTC timestamps, value, data type and unit or measure.
• The SparkplugB standard also added a limited command set to allow the subscriber to trigger for example, a reboot of the publisher, a failover or initialization.

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.

Summary

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:

• The unified name space using the ISA-95 standard is an equipment centric encoding using the parent-child relationship. It is missing references to the OSIsoft type system such as templates, categories, frames, and transfers. Once the data have been serialized into MQTT SparkplugB, this information will be stripped away.
• SparkplugB has only a limited command set. Operations such as backfilling historical data or data configuration updates which are often used are missing.
• Topic filtering and retuning is limited in SparkplugB due to the strict naming conventions.
• SparkplugB has no specification about time series compression. This leads to too many or worse still, not enough data.

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 data 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.