Implementing Unified Namespace (UNS) using MQTT
Implementing Unified Namespace (UNS) provides a company-wide view of system and data integration, allowing you to take thousands of actions and data points into a clear and actionable framework.
Many companies base their system architecture according to ISA-95, the international standard for integrating enterprise and control systems. ISA-95 defines hierarchical models that connect business, manufacturing, and control systems layers down to the sensor level—making it a natural fit for structuring UNS. For a deeper explanation, check out this previous UNS article and its role in Industry 4.0.
As a core concept in the Industrial Internet of Things (IIoT), UNS aims to centralize and structure an organization’s data architecture—with MQTT emerging as a key protocol for its implementation. MQTT can determine which information to exchange between systems for sales, finance, and logistics, as well as systems for production, maintenance, and quality.
This article explores two primary approaches to implementing MQTT with UNS:
- First, using standard MQTT features without any additional plugins. This approach will utilize a custom topic hierarchy (company-wide hierarchical topic structure for all MQTT brokers).
- Second, using the Sparkplug B specification for MQTT.
Examining both methods will help developers and architects determine which approach is best for their specific needs. It also highlights the inherent advantages MQTT brings to building a truly unified data architecture.
Standard hierarchical UNS MQTT implementation: Non-Sparkplug
One way to implement a Unified Namespace (UNS) is by leveraging the core features inherent in the MQTT protocol without relying on additional specifications like Sparkplug B. This approach offers significant flexibility but places the burden of structure and governance squarely on the implementing organization.
To ensure company-wide and multi-broker data exchange, clear documentation and alignment on payload schemes are crucial for implementing this concept. Organizations should consider incorporating additional features like payload scheme validation and separating IT / OT convergence levels. This can help increase transparency for both data producers and subscribers.
It is common in MQTT-based UNS architectures to classify topics as “red” or “blue,” to denote their usage and flexibility upfront. Typically, red namespaces are managed at the enterprise level and represent standardized, reusable data structures. In contrast, individual users or teams can create blue namespaces to meet specific or unique requirements. This approach enables flexibility and customization while maintaining a structured, shared data model.
As always, clear documentation and communication of payload and topic schemas are essential for maintaining consistency across the architecture.
The topic structure: The foundation of Unified Namespace (UNS)
The cornerstone of any standard MQTT-based UNS is the design of its topic hierarchy. Since MQTT itself imposes minimal restrictions on topic naming, aside from basic syntax rules, developers have the freedom to create a structure that logically represents their operational environment.
Figure 1 illustrates the hierarchical structure, comprising levels of the ISA-95 standard. An example topic structure might look like: enterprise/site/area/line/machine/control/sensor.
This hierarchical topic design is crucial because it enables data consumers to subscribe precisely to the information they need, using MQTT’s wildcard features. Various information can be transferred through payloads arranged in hierarchical topics, including event-driven data, metrics like OEE, or even binary payloads such as images taken by cameras.
For instance, a plant manager might subscribe to enterprise/site/area/+/+/+/state to receive status updates from all machines across all production lines, using the single-level wildcard +. An analytics application that focuses on a specific production line could subscribe to enterprise/site/area/line/machine/control/# to receive all data points from that line, using the multi-level wildcard #.
The effectiveness of UNS hinges on a well-designed, consistent, and documented topic structure that provides context and enables efficient data discovery and filtering.
To prevent data leaks, tampering, or malfunctions, it is essential to establish and clearly communicate access rules. You can utilize the Pro Edition for Mosquitto™ broker via the Cedalo MQTT Platform trial, to create accounts and assign fine-grained access control rules to clients and topics. You can also leverage wildcard topic operators # and +.
Payload considerations: The rise of JSON
UNS implementations typically use a hierarchical topic structure and specified access control lists. However, because MQTT is payload-agnostic, it’s essential to standardize the payload format.
The Pro Edition for Mosquitto™ broker can support this implementation with the scheme verification functionality, ensuring correct payload parsing. While you can design topic structures with full flexibility, Javascript Object Notation (JSON) has become the de facto standard for many UNS implementations using this approach. JSON’s human-readable format simplifies debugging and development, while its widespread support across various programming languages makes integration with web services, databases, and applications straightforward.
A typical JSON payload for a sensor reading from the topic enterprise/site/area/line/machine/control/sensor might look like:
JSON
{
"timestamp": 1643763722,
"value": 25.5,
"unit": "Celsius",
"quality": "Good"
}Of course, every level within the hierarchical topic structure can define and use its own payload scheme.
While using JSON is convenient, it requires consumers to parse text-based format, which can consume more CPU resources compared to binary formats. Additionally, JSON tends to be more verbose, leading to higher bandwidth consumption. This becomes a concern in massive-scale or constrained network environments. Therefore, it is vital to establish clear, consistent JSON schemas (even if informally defined and documented) across all data producers to ensure consumers can reliably interpret the payloads.
State management with core MQTT features
Implementing UNS goes beyond exchanging transient data, it must also represent the current state of the system. The MQTT protocol provides fundamental mechanisms to support this:
In particular, the functionality to retain and send last will messages after a client disconnects. This helps maintain robust state management even in large and global information architectures.
By combining a well-defined hierarchical topic structure according to the given entities within a company (refer to Figure 1), a standardized JSON payload scheme, and the strategic use of LWT and retained messages, organizations can build a functional UNS architecture using standard MQTT.
To support the specification and implementation phases, the Cedalo MQTT Platform trial provides tools to inspect and debug operations. You can observe broker, topic and client insights all from one web application. The topic tree view in Figure 2 is especially beneficial for checking the topic structure and monitoring the latest payloads.
Using the MQTT Sparkplug B specification for UNS implementation
To implement UNS using the Sparkplug specification some restrictions according to the specification have to be considered. This is driven by the given strict topic structure defined by the Sparkplug specification. Before explaining the major two concepts let’s have a look at the basic specification for the topic structure.
The Sparkplug MQTT topic structure
As mentioned in this Sparkplug for Mosquitto article, the Sparkplug B specification defines a clear architecture involving several key components that interact via an MQTT broker. Data consumers or producers are classified as either:
- Edge nodes
- Devices
- Host Applications
Unlike the free-form topic design of standard MQTT as shown before, Sparkplug B mandates a strict topic namespace structure: spBv1.0/group_id/message_type/node_id/[device_id].
Custom strings define the group_id, node_id, and the optional device_id. The message_type must be selected from a predefined list of standardized types:
- NBIRTH: Announces all possible node metrics when (re-)connecting to the broker.
- NDATA: Node Data, publishes changes for metrics owned by the node.
- NDEATH: Node Death message (via LWT) indicates the node has gone offline.
- DBIRTH: Announces all possible metrics for a device attached to a specific node.
- DDATA: Device Data, publishes changes for metrics owned by a specific device.
- DDEATH: Device Death message (via LWT) indicates the device has gone offline.
- NCMD / DCMD: Commands sent to nodes or devices.
This prescriptive structure immediately enforces consistency across all compliant devices and applications, forming a predictable foundation for the UNS. It eliminates the ambiguity and potential for fragmentation inherent in the flexible standard MQTT approach. Figure 1 illustrates that, regardless of the ISA-95 level, the nodes, including optional devices, are grouped with different identifiers.
The Parris Method
To realize UNS within Sparkplug there is an option to introduce the hierarchical topic structure within the custom strings. As stated before the topic consists of three customizable strings: group_id, node_id, and device_id. Defining a custom delimiter e.g., : the group_id can be written for example as:
Plant_EMEA1:Area3:Line3:Cell4and the node_id as
PLC:Count2resulting in a Sparkplug topic for DDATA from device_id 4711::
spBv1.0/Plant_EMEA1:Area3:Line3:Cell4/DDATA/PLC:Count2/4711Using a custom delimiter in the Sparkplug topic strings to can realize an hierarchical UNS and is often named as Parris method in relation with the UNS advocate Matthew Parris. The draw back of that approach is that additional topic parsing needs to be in place on the MQTT client site.
The Schultz Method
In contrast, the so-called “Schultz Method” – named after David Schultz, an advocate for industry-wide standardization – takes the approach of using multiple brokers for different parts of the complete enterprise UNS.
For example, you can use a Sparkplug-enabled broker with the group_id area1 and another one with group_id area2. All published metrics from nodes and devices in each area are then republished via a MQTT bridge to a superordinate broker. This broker uses a Sparkplug group_id with the name enterprise and a node_id area1 / area2.
You can implement the hierarchical architecture of UNS using the Sparkplug specification. This approach avoids delimiters, which might require complex parsing mechanisms but introduces considerable effort and operational overhead.
Generally speaking, choosing the right method for implementing UNS on top of the Sparkplug specification depends on several factors:
- The total number of devices/assets you need to connect.
- Location and separation of production plants.
- Existing architectures and structures.
The Sparkplug state management
Sparkplug B enhances MQTT for state management using a session state awareness model. This model relies on specific message types exchanged between Nodes and Host Applications through the broker. Unlike standard UNS implementations, realizing the Sparkplug specification requires the MQTT broker to have additional capabilities.
For example, the Pro Edition for Mosquitto™ utilizes the Sparkplug plugin to ensure specification conformance and Sparkplug awareness. You can verify the plugin’s functionality by observing the messages it publishes on the standard Sparkplug namespace topics. The retained messages have the following path:
$sparkplug/certificates/spBv1.0/+/NBIRTH/#
$sparkplug/certificates/spBv1.0/+/DBIRTH/#The Management Center for Mosquitto™ allows you to examine the topic tree (Figure 3) and verify retained messages using its integrated client simulation.
To do this, click the icon in the actions column to connect a temporary client. Once connected, the retained birth messages will appear, and you can inspect its payload. This capability is valuable for debugging and developing Sparkplug implementations, as understanding the different message types within the topic tree is essential.
Payload considerations: Google Protocol Buffers (Protobufs)
Sparkplug B uses Google Protocol Buffers (Protobufs) for encoding message payloads. Protobufs are a binary format that is both language- and platform-neutral, offering an extensible way to serialize structured data. Compared to JSON, Protobufs are smaller and faster to parse. The user does not need to define the payload structure as the specification provides a standard Protobuf schema. It is built from:
- A unix timestamp in epoch format.
- A sequence number (for ordering messages).
- A list of metrics. Each metric typically includes:
- A name (identifying the data point).
- An optional alias (a numeric identifier for efficiency).
- A timestamp (specific to the metric, if needed).
- A data type (e.g., integer, float, string, boolean, etc.).
- The actual value.
- Optional metadata or properties (e.g., engineering units, documentation strings).
- An optional UUID and body for extensions.
Beyond performance benefits, Protobuf schemas also provide strong typing, which enforces data types and minimizes errors from inconsistent data formats. Additionally, they provide schema evolution, which allows adding new fields to messages without causing compatibility issues with older applications.
State management: Birth and Death messages
Sparkplug significantly enhances MQTT’s state management capabilities by defining explicit mechanisms for retained last will and birth messages. When a node or attached device comes online, it must publish a comprehensive BIRTH message. This message lists all the metrics the node/device is capable of publishing, including their names, data types, and optional metadata like engineering units or descriptions. This allows consuming applications (like SCADA) to automatically discover new devices and understand their data without prior configuration.
Sparkplug utilizes MQTT’s LWT mechanism by standardizing its use. The LWT message becomes a standard DEATH certificate payload, clearly indicating to all subscribers that a node or device has disconnected unexpectedly. This removes ambiguous offline state notifications.
Formalizing the approach to state management provides a more robust and predictable understanding of device lifecycle and data validity compared to relying solely on standard MQTT LWT and retained messages.
Standard MQTT provides the foundation for a Unified Namespace (UNS), while the Sparkplug B specification builds on it with structure and standardization specifically for Industrial IoT (IIoT).
Rather than replacing MQTT, Sparkplug B defines how devices and applications should use MQTT to achieve plug-and-play interoperability and reliable state management.
Comparing the two UNS implementation approaches
Choosing between implementing a UNS using standard MQTT features (Non-Sparkplug) or the Sparkplug B specification involves weighing several trade-offs. Neither approach is universally superior; the optimal choice depends heavily on the specific use case, context, and project constraints.
Below is a comparison of key criteria to help guide your decision:
| Feature | Standard MQTT Implementation | Sparkplug B Implementation |
| Flexibility | High: Full control over topic structure and payload format. | Low: Prescribed topic namespace and payload format (Protobuf). |
| Standardization | Low: Requires internal definition and enforcement of standards. | High: Built-in via the specification, promoting consistency. |
| Interoperability | Low (by default): Requires custom agreements or adapters between different systems/vendors. | High (if compliant): Designed for plug-and-play interoperability between vendors. |
| Implementation Complexity | Lower initial barrier for simple cases. Complexity grows with scale and governance needs. | Higher initial learning curve (spec, Protobufs). Needs Sparkplug aware broker |
| Payload Efficiency | Variable: JSON (common) is verbose. Binary formats are possible but need definition. | High: Protobufs are compact binary format. Payload format is standardized |
| Network Bandwidth Usage | Potentially High: Verbose payloads (JSON), may send unchanged data. | Optimized: Efficient Protobufs, report-by-exception minimizes traffic. |
| State Management | Good: Uses LWT and Retained Messages effectively. | Excellent: Formalized BIRTH/DEATH certificates provide explicit, robust lifecycle tracking. |
| Discoverability | Low (by default): Requires external mechanisms or strict topic/payload conventions. | High: Built-in via BIRTH certificates enabling auto-discovery. |
| Human Readability/Debugging | High (with JSON). | Low: Requires tools to decode binary Protobuf payloads. |
Standard MQTT offers adaptable tools, whereas Sparkplug B provides a comprehensive framework tailored for IIoT Unified Namespace deployments. The subsequent section explores practical applications of these approaches through real-world scenarios. This comparison reveals a core philosophical distinction between the two methods.
Real-life use cases for each approach
In industrial production systems, Sparkplug often proves advantageous due to the dynamic nature of these environments. Assets and facilities are configured for specific production runs, potentially involving defined locations and sequences. When production changes-–whether in location, sequence, or production line capabilities—the data architecture must adapt accordingly. Sparkplug’s use of identities independent of their hierarchical level offers a significant benefit. It helps minimize reconfiguration efforts due to its plug-and-play nature, negating the need to announce or modify topic structures for other clients.
Conversely, implementing standard MQTT features excels in terms of time and simplicity. Employing JSON payload formatting and readily available client libraries facilitates rapid deployment for small to medium-scale use cases with fewer clients. The availability of simple, interpretable script-based adaptations for data consumption and production further supports this. Consequently, use cases categorized as retrofits or extensions often favor the standard MQTT Non-Sparkplug implementation.
Conclusion
Regardless of the chosen Unified Namespace (UNS) implementation method, the Pro Edition for Mosquitto™ and Management Center for Mosquitto™ offers a strong foundation for production-grade MQTT-based solutions.
A critical factor in selecting a UNS implementation approach is the maturity and availability of supporting tools and libraries. The standard MQTT approach benefits from extensive support with numerous mature client libraries available across various programming languages and platforms. Furthermore, tools for interacting with MQTT and common payload formats like JSON are widely accessible and well-documented.
While the Sparkplug B ecosystem, primarily for Industrial IoT (IIoT), is smaller but growing, libraries supporting its specific functions (such as BIRTH/DEATH messages, Sparkplug Protobuf encoding/decoding) are less common than general MQTT libraries. Nonetheless, a Sparkplug-aware broker enables robust, plug-and-play data exchange that has proven effective in industrial applications.
About the author
Dr. Andreas Schiffler is a research professor at the Technical University of Wuerzburg-Schweinfurt in the field of production and data technology in mechanical engineering. In addition to research topics related to 3D metal printing, Dr. Schiffler developed a Kubernetes cluster for the practice-oriented basics of IoT and Industry 4.0 as part of the student training. Before joining the university, he worked in different product development-related positions for Siemens AG and Schaeffler AG.
His hobbies and private activities are mixed to share practical knowledge on topics like home automation driven by MQTT protocol or using open-source CNC controllers for machine tools.
Subscribe for monthly updates
