Why MQTT is Always Associated with Unified Namespace (UNS)?

The concept of the digital economy is now familiar to us, whether in traditional manufacturing or the streaming era.

However, why are many companies in the industrial manufacturing sector still not implementing digitalization? This is certainly related to the owners’ understanding of it and their lack of deep comprehension of how it can generate actual benefits. Additionally, there is the issue that once digitalization is implemented, costs remain high and maintenance becomes exceedingly troublesome.

Therefore, adopting a good digital framework and communication technology is crucial. For the IIoT industry, the MQTT-SN we introduced last time can greatly solve the potential energy consumption and unstable communication issues that may arise from the massive data interactions between numerous sensors and devices: MQTT? No! MQTT-SN is the smart choice for industrial IoT!

If data is one of your company’s strategies, this issue is worth focusing on. A data-centric approach can help you address long-standing industrial goals, such as improving production efficiency and equipment maintenance, while providing a foundation for comprehensive connectivity within the enterprise. The success of such a digital transformation strategy largely depends on the degree of integration of organizational data across business units and technical domains.

In this article, I will introduce you to an advanced architectural approach suitable for achieving digital transformation in manufacturing—Unified Namespace (UNS). To truly understand the importance of UNS, we must first point out the shortcomings of traditional industrial architectures.

Traditional industrial architecture

Most existing industrial systems adopt a traditional pyramid network and system architecture structure (ISA 95 functional model). As shown in the figure, this architectural approach features a technology stack, from factory floor components to enterprise/cloud components. In this stack, each layer is connected and communicates only with its directly adjacent layers. Therefore, data can only move point-to-point between two adjacent layers at a time.Although this data architecture was effective when PC-based control and enterprise integration were introduced in the mid-1990s, blindly adopting it as the foundation for digital transformation strategies poses significant risks. A lack of visionary support often leads to unfulfilled promises, and many digital transformation efforts fail.Let’s look at an example. Suppose you want to provide data from a Programmable Logic Controller (PLC) to a smart platform in the cloud. Using the old ISA 95 functional model, you would need dedicated engineering personnel to import the data into the SCADA system, and then additional engineering resources to transfer the data from SCADA to MES, until the data finally reaches the cloud. Worse still, industrial systems use incompatible data formats, meaning that each device or software requiring integrated data needs specialized efforts from different professionals.Now, in addition to the astronomical costs and greed associated with this data integration, there are several other reasons why traditional industrial data architectures can lead to failed or ineffective digital transformation efforts:

Not Scalable

Digital transformation strategies based on traditional industrial architecture involve many specialized stakeholders and a large amount of manual point-to-point data integration checks. Therefore, it is difficult to achieve scalability or meet the needs of modern data-driven manufacturing organizations.

Stifling Innovation

Innovation requires all participants in the enterprise network (whether human or other entities) to have immediate access to data. However, traditional architectures store data in centralized data lakes, where access is restricted and can only address a limited number of issues. Additionally, this limits the organization’s ability to cope with the flood of data sources.Specific Personnel CostsTraditional data integration only uses proprietary application interfaces that can only be accessed by specific technology vendors. This leaves companies facing hundreds or even thousands of point-to-point connections that only specialized personnel can understand.Data Difficult to CollectThis layered architecture limits the range of data you can collect. This means you cannot provide meaningful data to smart platforms because request-response data consumes a lot of bandwidth, is cumbersome to set up, and is prone to errors. These data gaps adversely affect business operations.

UNS（Unified Namespace） Introduction

To address the failures of traditional industrial data architectures, you need to turn to a paradigm derived from modern distributed architectures. Instead of allowing data to exist in isolation across various levels of the technology stack and across layers, it should be made accessible in a unified manner, making it appear as if all data is in one place. This provides all your enterprise systems with a centralized location to obtain the data they need to achieve their goals.

The definition of Unified Namespace (UNS) remains controversial. From an automation perspective, UNS is a common naming convention organized based on attributes of devices, data points, and services (such as location, function, and type). However, according to Walker Reynolds, UNS is not just a naming convention but an architecture that meets five requirements.

• UNS is a semantic hierarchy of business data and events.
• UNS is a hub that connects all smart devices and IT infrastructure.

• UNS is the single source of truth for all data and information in the business.

• UNS is the foundation for future digital transformation.

• UNS is the location of the current state of the business, enabling real-time imaging of the business.

The common view is that Unified Namespace (UNS) is an ontology communication layer that connects every component in the Industrial Internet of Things (IIoT). It provides a shared data intersection that enables communication and collaboration between different systems and stakeholders, regardless of their underlying technology or vendor.

Why is MQTT Always Associated with Unified Namespace (UNS)?

Unified Namespace requires a data hub as a single source of truth to connect all manufacturing links, including PLC, SCADA, MES, and ERP. The volume of real-time data is enormous. Typically, data hubs in large-scale solutions face thousands or even millions of concurrent connections.

MQTT, due to its binary format, has very low overhead and bandwidth consumption. This lightweight design reduces the size of messages and lowers network traffic. This feature perfectly aligns with Unified Namespace and the Industrial Internet of Things.

For an introduction to MQTT, you can refer to the recent 20+ articles, and by following, you can view the latest historical articles.

In fact, in the industrial field, besides MQTT, OPC UA also has the capability to centralize all device data:

Since no single technology or product can fit all situations, you cannot rely solely on OPC UA to build a Unified Namespace, nor can you depend on a single protocol, especially when considering cloud integration. The Unified Namespace must combine different technologies, and MQTT serves as the adapter and coordinator that unifies them.

Strictly speaking, MQTT is the best partner for building a Unified Namespace. However, this is not mandatory. Therefore, you can use other protocols to construct a Unified Namespace, such as OPC UA and HTTP, or even simple Modbus + TCP/UDP. Among the many options, due to strong commercial support and standard persistence, OPC UA remains one of the popular approaches in the Industrial Internet of Things.

Of course, we can combine various communication methods to achieve this, such as bridging data through Modbus or OPC UA to MQTT, and then using MQTT to upload to the cloud. A good solution does not sacrifice one for the other but rather leverages each one’s strengths to form the optimal solution.

MQTT can help you define metadata in the Unified Namespace (UNS), ensuring consistency and accuracy between different systems.

UNS Framework V1

Finally, I will introduce a UNS framework, which is an open-source project that provides a technology-driven approach to handling MQTT and Unified Namespace (UNS) using YAML files.

In the early design phase, the UNS framework emphasizes describing what you have without changing what you do or how you do it, ensuring seamless integration with existing systems. Inspired by standards like Docker and Kubernetes, the UNS framework establishes a universal standard that is both human-readable and machine-readable.

By integrating your UNS with our framework, you can achieve seamless integration and understanding between documentation, applications, analytics, security tools, and AI systems.

At the end of the article, here is a segment of site.yaml code:

version: '1.0'
template_equipment: &template_equipment
  dataops:
    normalization:
      units: 'mm'
    transformation:
      timezone: 'utc'
template_sensor_cnc: &template_sensor_cnc
  information_model:
    x-axis:
      machine: float
      relative: float
    z-axis:
      machine: float
      relative: float
    status:
      data_type: string
    program:
      data_type: string
    tool:
      data_type: float
template_sensor_enviroment: &template_sensor_enviroment
  information_model:
    temperature:
      data_type: float
site:
  - name: UK
    id: UK
    location: string
    description: string
    area:
      - name: Area 1
        id: A1
        location: string
        description: string
        line:
          - name: Line 1
            id: L1
            location: string
            description: string
            cell:
              - name: Cell 1
                id: C1
                location: string
                description: string
                equipment:
                  - id: 'M1'
                    name: Machine1
                    <<: *template_equipment
                    sensors:
                      - id: 'S1'
                        <<: *template_sensor_cnc
                      - id: 'S2'
                        <<: *template_sensor_cnc
                  - id: 'M2'
                    name: MC2
                    <<: *template_equipment
                    sensors:
                      - id: 'S3'
                        <<: *template_sensor_enviroment
                      - id: 'S4'
                        <<: *template_sensor_enviroment

For detailed introductions, please refer to the links【4】.

Reference Links:

1. https://www.emqx.com/en/blog/unified-namespace-next-generation-data-fabric-for-iiot

2. https://www.hivemq.com/blog/what-is-unified-namespace-uns-iiot-industry-40/

3. https://www.emqx.com/en/blog/four-reasons-why-you-should-adopt-mqtt-in-unified-namespace

4. https://www.unsframework.com/example

• 【Video Course】Codesys V3.5 Series Introduction Course(141 people have learned）
• 【Video Course】Codesys SoftMotion Basic Course(42 people have learned）
• 【Video Course】Codesys SoftMotion Electronic Gear Course(15 people have learned）
• 【Video Course】Codesys SoftMotion Electronic Cam Course(10 people have learned）
• 【Video Course】Codesys Library Custom Library Creation(23 people have learned）

• Comprehensive Free Resources for Codesys V3.5 Series

• Top Ten Common Filtering Algorithms (ST Language)

• What Does a PLC Integrated with Chat GPT Look Like?

• Sharing of the Top 10 PLC Programming Books of 2023

• Customize Your CODESYS Motion Controller

• MC_Power.status = FALSE, Can the Axis Still Move?

• ST Language Learning Resource Compilation

——–END——–

Like this article? Please share and “like” it and “keep watching”