Designing Your UNS Semantic Information Hierarchy

In our previous article, Foundations of the Unified Namespace Architecture for IIoT, we explored the fundamentals of a Unified Namespace (UNS) architecture for IIoT. In this article, we will discuss UNS semantic data hierarchy design using MQTT.

To succeed in digital transformation, manufacturers should embrace an architecture that ensures seamless data access and integration across diverse platforms and applications within specific areas and throughout the organization. Establishing a clear semantic hierarchy, which includes layers of structured data, is crucial for intuitive and open access to this data. This is essential for leveraging data effectively to enhance intelligence in manufacturing operations. Structured data is important for several reasons, including the ones listed below.

• Analysis and Insight: Structured data is more easily analyzed. This means businesses can gain actionable insights quicker, leading to improved decision-making and optimization of processes.

• Machine Learning and AI: Structured data is essential for training machine learning models and deploying AI solutions, which can lead to further automation and efficiency gains.

• Real-time Processing: IIoT often requires real-time data processing. Structured information can be processed more quickly, which is critical for real-time applications.

• User Experience: Well-structured data can improve the user experience by providing easier access to relevant information and more intuitive interfaces.

• Interoperability: Structured information ensures that data from different sources can be integrated and used across different platforms and applications.

• Scalability: As businesses grow, so does the amount of data. Structured information ensures that systems can scale without losing performance or data integrity.

• Data Management: Structuring data helps in organizing, storing, and managing it efficiently, enabling faster access and analysis.

Let us explore how the MQTT protocol can be used to build a semantic data hierarchy for your UNS.

UNS Semantic Data Hierarchy Design Using MQTT 

In an MQTT-based publish-subscribe system, the MQTT broker organizes data using a topic hierarchy, which acts as a structured framework for data access. This hierarchical organization enables precise control over data sources within a Unified Namespace (UNS). Participants within the network can efficiently access required data by subscribing to specific levels of this hierarchy. Additionally, they can use wildcard characters such as '+' and '#' in their subscriptions to receive messages from multiple topics simultaneously instead of subscribing to each topic separately. This structure streamlines the process of data distribution and access within the network.

The structured nature of MQTT topics enables the creation of a comprehensive data access hierarchy within an organization: the UNS hierarchy. This hierarchy comprises numerous namespaces from various data sources arranged under the main topic namespace. Some namespaces may hold unprocessed data from devices and applications while others may contain data that is processed, normalized, and contextualized for local use or for feeding into external systems for further analysis. Keeping a consistent topic structure is essential for a predictable and organized namespace. 

Above is an oversimplified example of the Unified Namespace structure to give you an idea. Here, manufacturing/ is the root topic and represents the entire scope of the organization's manufacturing data. plantA/ and plantB/ are sub-topics under the root, representing different manufacturing plants within the organization. Under each plant, there are further subdivisions such as sensors/, machines/, robotics/, inventory/, and quality_control/ which categorize the types of data and operational areas. 

This structure allows participants in the MQTT network to subscribe to specific levels of data as needed. For example, a supervisor might subscribe to manufacturing/plantA/machines/+/# to receive all messages related to machines in Plant A, while a quality control analyst might only subscribe to manufacturing/plantB/quality_control/testing/# to receive data on all tests conducted in Plant B. We look at UNS namespace design in detail in a later section.

Regardless of the specific setup, it's essential to establish and document the categories and relationships within your Unified Namespace (UNS) beforehand. The organization's semantic structure should be embedded within the topic namespace, ensuring that information about data access is available independently of the actual data content. While the UNS operates as a decentralized and dynamic system where individual constituent namespaces may alter or cease to exist, the primary namespace structure should stay constant, only changing when transitioning to a new version.

Best Practices for MQTT Topic Namespace Structuring for UNS

Using ISA-95 Common Data Model

When organizing your MQTT topic namespace for the UNS, it's largely up to the system architect to determine the layout. However, following best practices, such as adopting the ISA-95 common data model, can prove beneficial. This model helps you reflect your organizational hierarchy within the MQTT topic structure, effectively organizing data streams between producers and consumers in a manufacturing environment.

The hierarchy typically follows this pattern:

Applying this model, your primary MQTT topic namespace for the UNS might be structured like this:

Versioning Your UNS MQTT Topic Namespace 

As your UNS systems develop, incorporating new features might necessitate alterations in the MQTT topic structure. Versioning these topic structures enables developers and operators to handle updates more efficiently, reducing the risk of system failures due to incompatible updates and providing a better experience for end-users by maintaining service continuity. This approach allows older clients to operate reliably on their existing topic structures without the immediate need for updates.

Moreover, versioning accommodates the diverse capabilities and feature support across different clients by allowing them to interact with the specific topic structure version they are compatible with. Developers can leverage newer versions for testing purposes, enabling them to refine changes in isolation from the live system. Additionally, versioned topic structures simplify documentation and maintenance, providing a clear framework for systematic change tracking and management.

Here's an example of creating a versioned MQTT topic namespace that incorporates both your specific naming convention ('spec') and a version identifier ('version'). In this structure, you also include the 'Client ID' within the topic path itself.

Pattern for Versioned Topic Namespace:

For instance, if your specification is named 'mySpec' and you are working with version 1, the topic namespace might be:

Designing Unified Namespace Data Structure

In establishing a Unified Namespace (UNS), after defining the primary MQTT topic namespace, you'll need to devise a scheme to organize raw and processed data across your hierarchical structure systematically. Each level should have its own detailed namespaces essential for defining your UNS data architecture. The organization of these namespaces affects the distribution and accessibility of analytical data within the functional domain of its originator (data producer) and how it is packaged for cross-domain integration and actionable analysis.

To achieve this, begin with a strategic plan that identifies the specific namespaces within your UNS and standardize them. Consider the different types of namespaces that will be integrated into your UNS, ensuring they facilitate clear and efficient data communication and analysis across your organization.

Establishing an Edge Namespace for All Your UNS Data

The foundational concept of the Unified Namespace (UNS) architecture is to avoid preconceptions about the future utility of data, recognizing that the value and relevance of data evolve as digital transformation progresses. In alignment with this philosophy, it's recommended to map every piece of data — especially PLC tags — to the UNS. This includes maintaining a distinct namespace for raw data, which you might refer to as the 'edge' or 'raw' namespace. The importance of consistent documentation and implementation of this namespace across your organization cannot be overstated, as it should align with your data governance strategy.

The structure of the topic for this edge namespace would follow the format:

Within this namespace, you will find models representing physical assets or equipment. These models primarily consist of tags from your PLCs or control systems, capturing the unprocessed, dynamic data streams from your machinery and processes. If you have multiple PLCs in your production line, then you can split up your edge namespace by PLCs. The raw data namespace is crucial as it allows you to start collecting data from day one and have it available in your UNS while you still figure out how to package it for external consumption.

Establishing a Functional Namespace for Your UNS

After collecting raw data into an edge namespace, the next step is to process this data, making it suitable for various applications within a specific functional domain and across your enterprise. This involves processes such as modeling, normalizing, contextualizing, transforming, and implementing uniform naming conventions. Once processed, this data should be kept on a separate namespace, known as the functional namespace.

The functional namespace is organized in a hierarchical format, typically as follows: 

As discussed in our previous article, Foundations of the Unified Namespace Architecture for IIoT, an IIoT platform is essential for the creation of a functional namespace. It is used to subscribe to data points ('tags') within the edge namespace, apply context and modeling, and then republish the processed data into the functional namespace of your Unified Namespace (UNS).

This structured approach allows for the creation of functions and visualizations based on the standardized data within the UNS. For instance, an Overall Equipment Effectiveness (OEE) namespace might calculate OEE values from the edge data and present this in a dedicated OEE functional namespace. Ideally, your functional namespace should encompass various Key Performance Indicators (KPIs) related to production, quality control, and maintenance, like OEE, First Pass Yield, and Mean Time to Repair. 

Besides these universal KPIs, you might have ad-hoc functions tailored to address specific analytical challenges within a particular domain, such as a production line, area, or site. Functional namespaces can also be published and consumed at different organizational levels, such as profit and loss figures at the site level or batch records at the line level.

Below is an example of a UNS semantic hierarchy to give you an idea of what it would look like.

The number and granularity of the namespaces to incorporate into your UNS are subject to the architect's discretion. You might also consider creating Informative Namespaces (which contain data abstracted for software, data lakes, and other systems) and Definitional Namespaces (which hold rarely changing parameters like installation dates, calibration records, etc.). 

As your understanding of data mapping and modeling evolves, the functional namespace will expand. Therefore, it is a continuous process of refinement to ensure the data remains clear, interoperable, and, most importantly, useful.

It's crucial to recognize that while the Unified Namespace (UNS) is a recommended approach, it isn't a one-size-fits-all solution. Different organizations will naturally develop their own unique UNS data structures. The essential principle is to arrange the namespaces within the UNS in a way that mirrors the organizational structure. This alignment ensures that the data is logically organized, making it straightforward for both users and systems to find and access the necessary information. 

Additionally, it's of utmost importance to meticulously document the specifications of your namespaces. This documentation ensures uniformity in how the namespaces are implemented within your organization and is vital when sharing data with external partners to guarantee clarity, consistency, and the ability to work together seamlessly.

Removing Inactive Elements from Unified Namespace

Finally, given the dynamic and expansive nature of the Unified Namespace (UNS), it's common for certain elements — such as devices, sensors, and namespaces originally established for temporary issues — to become obsolete. These elements might linger in the UNS even after their data sources or the problems they were meant to address no longer exist. It's therefore essential to regularly audit and clean your UNS to eliminate these inactive components.

If you're adhering to best practices by setting the 'retain' flag to true when publishing to your UNS, you can simply publish an empty payload. This action will effectively remove the inactive parts from the UNS.

The Role of MQTT Sparkplug in UNS Data Structure

Sparkplug enhances MQTT networks by providing a standardized format for topic namespaces, which helps organize and identify devices and nodes within the network. This standardization simplifies the process of data discovery across the network.

Below is the standardized Sparkplug topic namespace where group_id identifies a logical grouping of Edge Nodes, edge-node_id uniquely identifies a specific edge node within the same group, and device_id identifies a specific device controlled by the edge node.

You can learn more about Sparkplug from our Sparkplug Essentials Series.

However, Sparkplug's design presents two main challenges for creating a semantic data hierarchy in enterprise Unified Namespace (UNS) systems:

1. The topic namespace in Sparkplug is inflexible, with only three levels for addressing. This limitation can hinder the representation of complex organizational structures.

2. Sparkplug messages contain multiple values, which prevents subscribing to individual data points within these messages.

Despite these challenges, MQTT Sparkplug is popular for its dynamic capabilities and efficient device management in the Controls domain. To overcome its limitations, many architects use a combination of Sparkplug and Flat MQTT. The recommended practice is to use Sparkplug for the Controls domain, particularly for real-time SCADA implementations, and then switch to Flat MQTT for higher levels or cross-domain integration.

One method to achieve this is by incorporating the entire semantic hierarchy into the group_id using delimiters within the Controls domain and then translating that into a Flat MQTT topic namespace for broader UNS integration. For example:

This transition can be handled by an IIoT platform, MQTT broker extensions, or custom programming. The chosen method will also be used to separate Sparkplug's combined metrics into individual MQTT topics for enterprise-level applications.

Ultimately, the decision to integrate MQTT Sparkplug into a Unified Namespace (UNS) architecture or to use flat MQTT exclusively rests with the discretion of the system architect.

Conclusion

In conclusion, the practical implementation of a Unified Namespace (UNS) through an MQTT-based semantic data hierarchy is a transformative strategy for digital manufacturing. It enables seamless data integration and real-time access, thereby fostering a more agile, intelligent, and efficient manufacturing environment. The hierarchical structure of MQTT topics facilitates precision in data distribution and offers flexibility for scale. By adhering to best practices such as the ISA-95 model and incorporating versioning, manufacturers can ensure a robust and scalable infrastructure that aligns with their organizational needs.

Furthermore, the differentiation between edge and functional namespaces is a critical step in managing the lifecycle of data from its raw state to a context-rich, actionable format. Regular auditing and cleansing of the UNS ensure its relevance and efficiency, preventing data obsolescence from hindering operational capabilities. As manufacturers journey through digital transformation, the UNS becomes more than just a technical architecture; it embodies the confluence of data governance, system interoperability, and organizational knowledge, ultimately defining the backbone of a smart manufacturing enterprise.

In the next article, we will discuss data and functional modeling for Unified Namespace (UNS). Do check it out.