IIoT architectural choice: Sparkplug B vs. proprietary MQTT taxonomy for standardization and state management

MQTT fundamentals in IIoT: Why topic taxonomy is critical

MQTT (Message Queuing Telemetry Transport) has become the de-facto standard for message exchange in the Industrial Internet of Things (IIoT) due to its lightweight nature, efficiency, and publish/subscribe (pub/sub) model [1]. In this model, publishers send messages to specific "topics," and subscribers receive these messages by expressing interest in relevant topics. However, the MQTT protocol itself does not define the structure of these topics or the payload format.

This flexibility becomes a significant challenge in large IIoT deployments. Without a standardized topic taxonomy and data format, issues arise with device discovery, state management, and integration. Each manufacturer or team may create its own conventions, leading to a "zoo" of incompatible structures that require individual integration logic for every new device or system. This complicates scaling, maintenance, and data analysis, and hinders interoperability between systems from different vendors without significant effort.

Sparkplug B: Standardization for industrial interoperability

Sparkplug B is an open specification from the Eclipse Foundation, designed to address the problems of fragmentation and lack of context in industrial MQTT deployments. It extends MQTT by adding three key elements: a standardized topic namespace, a strictly typed Protobuf payload format, and a device lifecycle state management model based on "birth" and "death" certificates.

The Sparkplug B topic namespace has a clear hierarchical structure: spBv1.0/{GROUP_ID}/{MESSAGETYPE}/{EON_ID}/{DEVICE_ID}. This standardization allows any Sparkplug-compliant application to automatically discover and subscribe to data from devices without prior knowledge of their configuration.

For payload encoding, Sparkplug B uses Google Protocol Buffers (Protobuf) – a compact binary serialization format. Unlike JSON, Protobuf significantly reduces message size (by 60–80% compared to JSON for the same data) [2], which is critical for bandwidth-constrained networks. Furthermore, Protobuf ensures strictly typed data fields, eliminating parsing ambiguities and making data self-describing, including metadata such as metric names, data types, units of measurement, and timestamps.

One of the most significant advantages of Sparkplug B is its device state management mechanism. When a device or Edge of Network (EoN) node connects to the broker, it publishes an NBIRTH message (or DBIRTH for a connected device), containing a complete list of all metrics it will publish, with all metadata and initial values. Upon disconnection, an NDEATH (or DDEATH) message is sent. This ensures that subscribers always have up-to-date information about device connection status and available data, solving the fundamental problem of a lack of built-in state management in pure MQTT. Sparkplug B also supports metric aliases for further bandwidth optimization.

Proprietary topic taxonomy: Flexibility vs. complexity

An alternative to Sparkplug B is to develop a proprietary topic taxonomy and payload formats for MQTT. This approach offers maximum flexibility, allowing architects to fully adapt the topic structure to specific project needs, for example, by location, device type, function, or other criteria (e.g., {site}/{area}/{line}/{cell}/{device}/{data-type}). This can be attractive for small, isolated systems or prototypes where development speed and complete control are priorities.

However, as the system scales, flexibility turns into complexity. Developing a proprietary taxonomy requires significant effort to document, maintain, and ensure consistency. Without standardized rules, there is a risk of topic "sprawl" and incompatible data formats, which complicates the integration of new devices or systems from different vendors. Each new component will require the development of individual parsers and adapters, increasing development and maintenance costs.

Moreover, a proprietary taxonomy does not include built-in device state management mechanisms, such as birth/death certificates. This means architects must develop their own solutions for tracking device connectivity and data freshness, for example, using heartbeat mechanisms or MQTT Last Will and Testament (LWT) messages [3]. This adds an additional layer of complexity and potential points of failure.

Comparison: Interoperability, state management, and migration cost

To make an informed decision, let's consider a comparative matrix based on key criteria:

Application scenarios:

• Sparkplug B is more advantageous: For large IIoT deployments involving integration with SCADA, MES, ERP systems, where high interoperability between different vendors, automatic device discovery, reliable state management, and bandwidth optimization are required. This is ideal for building a Unified Namespace.
• Proprietary taxonomy may be justified: For small, isolated projects where all components are developed by a single team, or for very specific cases where complete control over every aspect is needed, and where potential future scaling and integration costs are acceptable.

Practical recommendations for selection

When deciding between MQTT Sparkplug B and a proprietary topic taxonomy, the automation architect should follow this checklist:

1. System scale and complexity:
   • Small, isolated system (up to 10-20 devices, one vendor): A proprietary taxonomy might be simpler for initial implementation.
   • Large, multi-component system (hundreds/thousands of devices, many vendors): Sparkplug B will provide the necessary standardization and scalability.
2. Interoperability requirements:
   • Need for seamless integration with SCADA, MES, ERP: Sparkplug B is the optimal choice due to its standardization.
   • Limited need for external integration: A proprietary taxonomy may be sufficient, but with the risk of future complications.
3. Device state management:
   • Critical need for automatic device state tracking: Sparkplug B offers built-in mechanisms.
   • Willingness to develop custom state management logic: A proprietary taxonomy will require additional effort.
4. Network bandwidth:
   • Limited bandwidth (e.g., cellular networks): Sparkplug B's compact Protobuf messages are a significant advantage.
   • High bandwidth, less sensitive to packet size: A proprietary taxonomy with JSON may be acceptable.
5. Long-term development plans:
   • Plans for expansion, integration of new technologies and vendors: Sparkplug B will provide flexibility and reduce future costs.
   • No plans for significant expansion: A proprietary taxonomy may be sufficient, but with potential limitations.
6. Priority for data delivery reliability (QoS):
   • While Sparkplug B often uses QoS 0 ("fire and forget") for telemetry for maximum speed, the specification allows for other QoS levels. If guaranteed delivery (QoS 1 or 2) is critical, this should be considered during design, as it is not standard practice for all Sparkplug telemetry implementations.

The AZIOT platform is designed to support the architectural solutions discussed in this article, providing tools for integrating both Sparkplug B-compliant devices and systems with custom topic taxonomies, allowing architects to flexibly implement their IIoT projects while maintaining centralized management and analytics capabilities.

In conclusion, the choice between Sparkplug B and a proprietary MQTT taxonomy for IIoT projects is a strategic decision. It requires a thorough analysis of current needs and future ambitions. For most industrial deployments aiming for scalability, interoperability, and efficient state management, Sparkplug B offers significant advantages, despite the initial complexity. A proprietary taxonomy remains an option for niche or controlled environments where flexibility outweighs unification.