Foundations of the Unified Namespace Architecture for IIoT

In the manufacturing sector, a significant shift is underway. It's a movement that many are aware of — the rapid expansion of digitalization. Organizations are transforming themselves to use digital technology not just to support their existing operations but also to drive and transform their business outcomes by augmenting their operations with data-driven intelligence. 

However, a persistent challenge remains amidst this evolution. The prevailing view is that to extract value from data, it must be consolidated from various business divisions into a central repository, such as a data warehouse or data lake. And then leveraged to drive an organization's innovation strategy.

This strategy is especially problematic in manufacturing due to the wide variety of Operational Technology (OT) and Information Technology (IT) systems with different meanings and definitions of data. That is, as more data is collected and stored centrally, the inconsistencies make it increasingly difficult to make sense of the data, which is detrimental to advanced analytics that organizations need for intelligent decision-making. 

But that’s just part of the story: more varying data-generating sources are being connected rapidly across OT and IT domains, and manufacturing businesses are growing in organizational complexity, and with it, the need to address more specific advanced analytics use cases has never been more essential.

Consequently, to successfully achieve digital transformation on an enterprise scale, manufacturers need an architectural approach that facilitates seamless data integration and the extraction of value, scales effectively with the addition of new data sources and varying contexts, and enables rapid responses to data-driven use cases in manufacturing.

The Unified Namespace (UNS) offers an alternative approach to traditional industrial data architecture. Traditional methods typically follow the ISA 95 pyramidal network-and-system architectural model, which relies on propagating data upwards for centralized storage and subsequent analysis. In contrast, the Unified Namespace (UNS) approach externalizes contextualized data across various functional domains into a real-time semantic hierarchy, establishing a hub and spoke model that serves as a single source of truth for your business's current state and events. 

This article starts by solidifying the core principles of a Unified Namespace (UNS) architecture for manufacturing enterprises. It then explores the essential elements of the UNS architecture and their interconnections and concludes by introducing a UNS Reference Architecture. In subsequent articles, we'll look more in-depth at designing information mapping for your UNS semantic hierarchical structure and data modelling. 

The core ideas behind the UNS architecture draw heavily from contemporary IT data architecture practices, specifically Zhamak Dehghani's Data Mesh concept and Eric Evans' Domain-Driven Design. Thus, we'll use some of their terminologies in this article to illustrate UNS principles.

Principles of a Unified Namespace Architecture

Edge Driven & Domain Ownership

The fundamental concept to grasp with the UNS architecture is that for a manufacturing enterprise to fully leverage decentralized real-time data sharing, the various components within a specific functional domain must push data from its source at the edge into a common data infrastructure. In manufacturing, these functional domains typically include Control, Operations, Information, Applications, and Business. The data exchanged may include sensor updates, events, alarms, status changes, commands, and configuration updates. In the Edge-Driven principle, the data may only be shared when a change has been detected in the monitored item, Report-by-Exception. 

By channeling data straight from the originating systems at the edge into a common data infrastructure — abstaining from the traditional, tiered approach — Edge-Driven architecture creates the notion of a perpetual, real-time representation of your enterprise's current state and events, effectively creating a singular, authoritative reference point for your business model. This architecture model therefore serves as a single source of truth, where all components participate as Nodes in the ecosystem from which they equally consume information as much as they publish it. Furthermore, an Edge-Driven architecture enhances reliability by eliminating the fragility of the need for synchronization in systems that rely on request-response interactions. For example, during communication disruptions, this design allows data that would otherwise be missed through request-response models to be stored temporarily and then resent once the network connection is reestablished.

Furthermore, the fact is that components in each functional domain in manufacturing are really about one concept of the business, and therefore, share a common interpretation of data semantics. For instance, within the Control domain, you find systems like Programmable Logic Controllers (PLCs), Supervisory Control and Data Acquisition Systems (SCADA), and robotic controls, whose interpretation of data centers around controlling and monitoring production processes.

Given that, it makes sense to allow each functional domain in your architecture and teams therein a considerable amount of sovereignty in how they package the data, albeit following the guidelines of federated data governance. This autonomy allows the tailoring of data models to address advanced analytics use cases specific to that domain, which empowers regular users, who may not have specialized skills, to analyze data without relying on data scientists to sift through data that has been gathered and organized centrally.

Following this, the data can be transformed and mapped into an enterprise-wide namespace to ensure consistent and integrated use across different business areas. In Part 2 of this series, we explore how to accomplish this by employing namespaces to organize information segments within a cohesive, overarching structural design.

This approach helps to manage complexity by creating clear interfaces and interactions between different parts of your architecture, which can evolve independently while still integrating with one another as necessary. It enables the effective distribution of data while maintaining flexibility, security, oversight, and separating concerns on an enterprise scale.

Open Architecture and Standard Data Infrastructure

For the Unified Namespace (UNS) to function effectively, it’s essential to establish a data infrastructure that supports an open architecture. This means using a standardized method for exchanging information that is openly accessible and widely adopted. Moreover, the infrastructure should incorporate a "Publish-Subscribe" model, which enables a flexible and decoupled way of sharing data within a functional domain and across functional domains within your enterprise. This setup must be efficient in terms of bandwidth use and reliability. In addition, a UNS-based system must be self-aware: it should seamlessly integrate new participants and their data into the existing communication network without manual intervention.

The MQTT protocol has emerged as the de facto communication standard in a UNS architecture, as it embodies the core qualities needed for a robust data infrastructure highlighted above. It facilitates the sharing of data — and therefore value — among all entities within the UNS architecture and reduces the complexity and cognitive load in data exchange. You can download our MQTT Essentials Guide to learn more about how MQTT works.

An open architecture plays a crucial role in fostering a culture of innovation within a manufacturing organization. It allows teams to formulate hypotheses about data applications and promptly access the necessary tools to test these ideas. With an open architecture, these tools can be effortlessly integrated into the existing data infrastructure, eliminating the need for specialized connectors or converters to handle proprietary interfaces. This streamlined integration accelerates the innovation process, as teams can focus on testing and developing ideas rather than navigating technical compatibility issues.

Moreover, embracing an open architecture avoids the accumulation of technical debt that often comes with custom-built connections for proprietary interfaces. Not being locked into vendor-specific solutions allows the organization to adapt more swiftly to technological advancements. This adaptability means that future integrations, upgrades, or changes can be implemented without the need to overhaul the existing infrastructure or rewrite custom code, saving time and resources and achieving faster time to market. 

Federated Data Governance

Finally, let's address a principle designed to bring order and clarity to the distributed, domain-oriented architecture advocated by the Unified Namespace: Federated Data Governance. This management system is designed to maintain data quality and ensure interoperability within a distributed domain-oriented environment. The principle behind this approach is to manage and govern data across various domains or business areas, aiming to achieve consistent integrity, interoperability, accessibility, security, and privacy. 

This form of governance promotes the development of universal standards, practices, and policies for data handling and use while also honoring the individual governance of different functional domains. It encourages different data custodians across a manufacturing enterprise to collaborate on maintaining data quality and interoperability by establishing common data standards, formats, and protocols.

In the context of UNS, governance must balance the need for localized control and optimization within autonomous domains with the need for overarching harmony across all domains. This balance acknowledges that the system is dynamic and cannot be rigidly controlled. Furthermore, Governance in UNS favors empowering teams close to the data, as they are the most informed and, hence, most capable of managing and sharing their data and ensuring that it is usable, valuable, and feasible to generate. 

Core Components of a UNS

MQTT Broker for the Unified Namespace

At the heart of the Unified Namespace (UNS) architecture is the MQTT broker, a pivotal piece that acts as the central hub for data communication. When planning your UNS, your setup will likely involve multiple MQTT brokers tailored to specific needs within your architecture. These may include robust enterprise MQTT broker clusters for high availability, such as HiveMQ Enterprise, and machine connectivity solutions with embedded MQTT brokers like HiveMQ Edge. 

The critical factor is ensuring that your broker fully adheres to the OASIS Standard MQTT Specifications to stay true to the UNS principles of an Open Architecture, which empowers you to select best-in-class tools to plug into your MQTT data infrastructure.

Furthermore, your architecture requirements will determine which version to choose between MQTT versions 3 and 5. Most industrial devices and applications support MQTT 3. However, MQTT version 5 brings advanced capabilities, such as user properties and shared subscriptions, which can streamline certain processes more efficiently than version 3. On the other hand, MQTT 5 includes several optional features, which means a broker can be considered MQTT 5 compliant without supporting every feature. This is significant regarding features like persisting retained messages, which are optional in MQTT 5 but were given in MQTT 3.

For your UNS, retained messages are critical; they ensure that the latest information on any topic is available for new participants, allowing them to access the current state and events within the UNS immediately upon joining without the need to wait, or in the case of MQTT Sparkplug, query devices and applications across the network. We’ll discuss MQTT Sparkplug's role in your architecture later in this article.

When specifying your UNS data infrastructure requirements, it's crucial to define which MQTT features are necessary for your use case, including which ones the broker must support to fulfill your UNS's goals effectively.

IIoT Platform for the Unified Namespace

In industrial settings, which are often composed of a mix of modern and older equipment with proprietary interfaces, there exists a challenge in integrating this diverse technology into a homogenous data ecosystem. This is where an Industrial Internet of Things (IIoT) platform becomes essential. It serves as a bridge, connecting older, 'legacy' systems that cannot directly communicate using the MQTT protocol, which is central to a Unified Namespace (UNS) ecosystem. The IIoT platform facilitates the collection of data from these varied sources — ranging from PLCs to SQL databases — and publishes it to the MQTT network.

This platform does more than merely collect and transmit data. It organizes and refines the data by categorizing it, defining its structure and properties, and enhancing its readability and reliability. This process may include aggregating data, performing calculations, or converting data formats, all of which add valuable context that aids in identifying patterns, trends, and anomalies. This ensures that the data is not only accessible and understandable within its local domain but is also prepared for integration and analysis across different functional domains.

At its core, the Unified Namespace is the combination of an MQTT broker and the IIoT platform. The underlying principle is straightforward: any new data that is generated behind the IIoT platform using point-to-point should be published to the UNS, ensuring that it's shared across the network as the current state and events. Additionally, current data might be a snapshot of historical records pertinent to the present moment, but ultimately, the approach taken should be tailored to the problem being addressed.

Users can bypass the UNS and access data directly from the IIoT platform for localized or immediate data requirements. While direct connections, like linking a Historian to a SCADA system, are sometimes beneficial, the decision to use such connections depends on the specific issue. 

Data Persistence for the Unified Namespace

For an effective Unified Namespace (UNS) architecture, relying solely on an MQTT broker's real-time data-sharing capabilities and an IIoT platform is insufficient. Data persistence is crucial, meaning you need the ability to store and access historical data. This requires incorporating both a historian (or time-series database) and a structured database, such as SQL, into your UNS architecture.

The historian plays a pivotal role by subscribing to the UNS and archiving data over time, allowing for retrospective analysis and insight. This historical data should be easily accessible through the same IIoT platform managing the UNS. Additionally, the SQL database, typically integrated with the IIoT platform, holds structured data essential for operational management and analysis.

The historian mirrors the live data model of the UNS but with the key difference of maintaining a historical record. From there, REST endpoints can be established to query historical data, and these queries are made relevant within the UNS by publishing them back to an appropriate level of the semantic hierarchy.

Furthermore, transactional operations on stored data may be facilitated through the IIoT platform acting as a bridge between the UNS and a data store. For example, a machine's downtime event captured by the MQTT broker can prompt an update to an SQL table used for Manufacturing Execution Systems (MES). The MES might use historical SQL data to calculate current Key Performance Indicators (KPIs), which are then fed back to the MQTT broker. Similarly, current work on a machine could be informed by historical data on similar past work orders, allowing operators to compare and improve performance based on this historical context. These comparisons can be published back to the MQTT broker, effectively bringing historical performance benchmarks into the present analysis.

For recurring data queries, it's more efficient to directly connect to the historian through the IIoT platform or set up specific request/response topics within the UNS. However, the UNS should not be used as a primary API for ad-hoc data queries. Instead, queries should be directed through the native tools that manage the databases, ensuring efficiency and effectiveness. 

Unified Namespace Reference Architecture with MQTT

Below is the UNS Reference Architecture based on the core components we discussed in the previous section. Again, as you can see, the MQTT broker and IIoT platform play a significant role in architecting a Unified Namespace.

The reference architecture also includes HiveMQ Edge to facilitate data conversion from point-to-point protocols to MQTT for simplified integration. HiveMQ Edge also embeds an MQTT broker, which allows the data to be mapped into a local namespace within a Production Area or Line. 

Data can also be gathered from devices with MQTT capabilities and connectivity solutions like KepserverEX. This data is then fed into a dedicated "raw MQTT namespace." From there, the IIoT platform processes this data to give it context and a consistent format before redistributing it into the Unified Namespace.

The use of MQTT Bridges enables the multiple MQTT brokers and different levels of a manufacturing enterprise to share information, creating a distributed network of data brokers that ensures data consistency and availability across the network. This is crucial for large-scale, geographically distributed industrial environments.

Unified Namespace Reference Architecture with MQTT Sparkplug

For additional interoperability within the MQTT network, MQTT Sparkplug is used. It standardizes MQTT Topic Namespace, State Management, and Payload Structure, offering benefits for Enterprise UNS architecture. MQTT Sparkplug can be used up to Level 2, where a Sparkplug consumer, typically an IIoT platform, can be used to subscribe to the Sparkplug namespace and perform some transformation that could make it easier to integrate data into enterprise systems that are not Sparkplug compliant.

Conclusion

In conclusion, the Unified Namespace (UNS) represents a groundbreaking architectural approach to digital transformation in the manufacturing sector. Organizations can effectively manage complexity and enhance data interoperability by adopting an Edge-Driven architecture and leveraging an open architecture that utilizes a standard data infrastructure like MQTT. In the next article, we will discuss how to design your UNS semantic hierarchy with information mapping. Do check it out.