UNS Semantic Data Hierarchy with MQTT: Explained with an Example

The Unified Namespace (UNS) aims to facilitate real-time information sharing across Control, Operations, Information, Applications, and Business domains in manufacturing organisations. Putting crucial data and information in the hands of both people and systems that need it. This enables informed decision-making about optimizing and automating processes, with the ultimate goal of fully automating business processes.

Namespaces in a UNS serve as containers for specific types of information within a unified structure. They allow users or systems to subscribe to relevant data in real-time, whether it's key performance indicators (KPIs) for asset efficiency, quality and traceability metrics, production orders, inventory tracking from the ERP, or raw data from PLCs.

This article will guide you through the process of designing a Namespace for your UNS data structure using an example.

Designing a Namespace for UNS

Although namespaces in UNS will evolve as you continuously add and remove them, the first step is to map out the core structure of your namespace. This requires a structured approach, which the ISA-95 standards and models can help you achieve. The ISA-95 framework includes the equipment and hierarchy model, the object model, and the activity model, enabling information exchange between business and control domains.

To illustrate the concept, we'll create a namespace for an automotive manufacturing company called Auto Industries. This example is simplified to give you a starting point for building your own UNS namespace. Keep in mind that every company, even within the same industry, is organized differently.

Building the UNS Semantic Hierachy: An Example

The first step is to define the physical structure of your organization following the role-based equipment hierarchy model as outlined in ISA-95 Part 1. This model helps organize production equipment as viewed by top-level business systems, such as planning and logistics. Many manufacturing companies already follow this model, either strictly or with customizations to meet their unique needs. While this structure is not a rigid rule for UNS namespace creation, it is a strong recommendation with some flexibility for variation.

Example MQTT topic:

Equipment Hierarchy Namespace for UNS

Let’s build a namespace for an automotive manufacturing company following the equipment hierarchy model.

Enterprise Level

The root namespace will use the company name, AutoIndustries, as the highest level of data access. Example MQTT topic:

Site Level  

The organization operates two assembly plants: one in Munich and the other in Texas. Therefore, under our AutoIndustries namespace, we will establish two separate namespaces, one for each site. This will result in the following MQTT topic namespaces for data access.

Area Level

At each of our sites, we have three assembly areas: PressShopArea, BodyShopArea, and PaintShopArea. Consequently, we will create three corresponding namespaces for these areas.

At this stage, we will have the following Unified Namespace structure:

Production Line Level

Next, let's focus on the PressShopArea at both sites, which includes the Door Press and Hood Press production lines. We will create namespaces for each corresponding production line.

Work Cell Level

Let’s zoom in further on our Door Press Production Line. This line includes two Work Cells: Cutting and Forming. Therefore, we will need to create namespaces to hold information related to these work cells.

Process Segmentation Namespace for UNS

Now that we have defined our equipment hierarchy namespace down to the Work Cells, we can focus on the physical machines and processes within these cells. While most processes involve machines, some can be manual, such as inspections or preparing a machine for changeover. The next step is to break down the overall process of producing goods in a work cell into smaller process segments. These segments are used to group resources for specific tasks within the Work Cell or Process Cell in continuous production. They represent how manufacturing operations are viewed by Level 4 business processes from a logistics perspective.

For example, we can divide our CuttingWorkCell into segments like Cutting and Material Handling, and our FormingWorkCell into Pressing and Material Handling.

Resources Namespaces for UNS

Next, we will define namespaces for holding information about the production resources executing jobs within the work cells. These resources may include physical assets, personnel, and sometimes even the product itself. In our case, we will create a namespace to store the machine's definition, including time series data or parameters, the machine's state or heartbeat, and additional namespaces for capturing job-related and non-job-related events.

The namespaces you create under a resource will naturally depend on the specific events for which you want information to be published to the Unified Namespace, allowing for customization as needed.

In addition to the namespaces associated with a machine, you could also create an Edge namespace for holding data that can be used to calculate machine reliability metrics, such as OEE (Overall Equipment Effectiveness) and MTTR (Mean Time to Repair), among other things. For example, this could include data like Scrap Count, Production Count, Operating Time, and Total Down Time.

At this point, our Unified Namespace hierarchy will look like the picture shown below.

Enterprise-to-Control Namespaces for UNS

Now that we’ve created namespaces to bring data from edge resources into the Unified Namespace (UNS), the next step is to establish namespaces for moving data from Level 4 business systems to the control domain. In this and the following sections, I will reference the ISA-95 Functional Hierarchy Model by mentioning levels like Level 4 and Level 3. However, it's important to note that this is purely a way to describe physical segments. In the UNS, all communication occurs through a central MQTT broker via the namespaces.

For example, orders received from clients and entered into the ERP system will need to be reflected in the UNS so that they are accessible to systems in the control domain.

While there may be various business systems at Level 4, in this example, we’ll focus on the ERP system. We will create an ERP namespace to hold the information that needs to be exchanged between business and control systems. Additionally, namespaces are typically structured to enable bidirectional information exchange. For instance, an ERP namespace could be used to move information from the control domain to the business domain to report on the inventory status of an ongoing order.

The ERP namespace can exist at different levels of your hierarchy, or it can be present at every level, depending on your operations. For example, you might choose to publish your OperationSchedule at a site level, line level, etc.

For now, we'll focus on the ERP namespace at the Production Line level. Within this ERP namespace, you can create sub-namespaces to hold information about Operations Requests sent to the shop floor from the ERP system. These requests can be categorized into Production, Maintenance, Quality, and Inventory requests.

To facilitate the flow of information from Level 4 systems to Level 3 systems through the UNS, operational systems at the production line subscribe to these namespaces. For example, an MES system, which handles detailed planning, assembly instruction management, and production reporting, would subscribe to the namespaces containing the schedules.

Control-to-Enterprise Namespaces for UNS

Next, let's discuss namespaces for creating an interface to move data from Level 3 systems to Level 4 systems. These namespaces are typically used to publish information at the end of production, at intermediate stages, or on a regular schedule etc. Level 3 systems typically perform one or more MES functions, so their information is generally organized under the MES namespace in the UNS. Similar to the ERP namespace, the MES namespace can exist at one or multiple levels within the namespace hierarchy.

Within the MES namespace, information is further categorized into different sub-namespaces to organize related data, typically including Production, Maintenance, Quality, and Inventory.

For example, within the Quality namespace, you could publish responses to quality inspection requests, while in the Maintenance namespace, you could publish calibration results in response to a calibration request, and so on.

Use Case Based Namespaces for UNS

The strength of the UNS lies in its ability to provide not only data and information reflecting the current state of your operations but also data that has been transformed to meet the needs of specific use cases. This transformed data is often referred to as "fit-for-purpose" domain data. To make this type of data available for consuming applications, namespaces must be created at the appropriate levels within the UNS.

For example, you might create a fit-for-purpose namespace called "Predictive Maintenance," which holds data specifically designed for use by systems focused on training or inference purposes.

This namespace would typically aggregate data from multiple namespaces to create contextualized information tailored to the needs of the consuming application.

Conclusion

As you implement and evolve your UNS, remember that it should be adaptable to your organization’s ongoing changes and growth. While the examples provided offer a starting point, the true power of UNS lies in its customization to fit your specific operational requirements. By thoughtfully designing and continuously refining your namespace, you can unlock the full potential of real-time data exchange, driving innovation and value throughout your enterprise.