Practical Applications of Unified Namespace for IIoT Use Cases

The term Unified Namespace (UNS) was coined by Walker Reynolds from Industry 4.0 Solutions. UNS defines the structure of the company’s business and all of the events and acts as:

• The single source of truth for all data and information of the business

• The place where the current state of the business lives

• The hub through which the smart things in the company’s business communicate with one another

• The architectural foundation of the company’s Industry 4.0 and Digital Transformation initiative.

HiveMQ has created a whole essentials guide and eBook for UNS which has built on what Walker has created and goes over details like what it is, how it works, how to implement UNS with MQTT Sparkplug, key considerations for selecting an MQTT Broker for UNS, and integrating SCADA, MES, Historian, ERP, and advanced analytics into UNS.

The typical Operations Technology (OT) systems, that industrial manufacturing companies in various verticals like Pharmaceuticals, Automotive, Food & Beverage and others use, are Programming Logic Controllers (PLC) along with Human Machine Interface (HMI) to gather data, monitor and control machines; Supervisory Control and Data Acquisition (SCADA) systems to monitor and control plants; and Manufacturing Execution System (MES) for executing manufacturing. The typical Information Technology (IT) systems are Enterprise Resource Planning (ERP) systems for planning production, Customer Relationship Management (CRM) systems for selling goods and Advanced Applications like Dashboards, Machine Learning (ML), and Artificial Intelligence (AI) to provide long-term optimizations and efficiencies. UNS is able to unify the data from all of these systems (details of which can be found in the eBook referenced above) and make it look like it is coming from the same source. UNS can be maintained at the cell, line, area, site, and enterprise level with nesting of information at each level. Figure 1 below shows all of this information.

 Figure 1: Representation of UNS | Image Courtesy: Walker Reynolds

Although there are multiple ways to set up a UNS, given the complicated nature of manufacturing and how the data is organized in different systems across different locations, an MQTT broker is most suited for setting up the UNS as it supports broker federation for UNS structuring (Figure 2). In this example of a bottling plant of a beverage manufacturing company with multiple systems and multiple locations, an MQTT broker can help set up UNS across different locations which can then be federated to the enterprise UNS location. Depending on the complexity of the operations, UNS can be set up at the production line or machine level through the broker and federated up the levels. 

Figure 2: UNS structuring using an example of a bottling plant of a beverage manufacturing company

HiveMQ’s MQTT broker and HiveMQ Edge are ideal for implementing broker federation from various factory sub system UNS to the Enterprise UNS.

IIoT Use Cases for the Various UNS Namespaces 

The actual namespace in the various UNS’s could be functional, informative, definitional, or ad hoc. The below Figure 3 shows how a UNS semantic hierarchy can be set up with these namespaces along with how to view the latest values of data that is relevant for the organization. 

Functional Namespace

A functional namespace refers to the organization of data parameters in an industrial system based on their function or purpose. This means that the parameters are grouped together based on the specific task they perform, rather than their physical location or network. For example, all of the production data could be in one namespace and all of the maintenance data could be in another namespace. A use case for using a functional namespace is for a medical devices manufacturing company to calculate the Overall Equipment Efficiency (OEE) which is a Key Performance Indicator (KPI) used to measure the performance of the manufacturing machines. OEE is an important KPI in manufacturing to ensure that production schedules are met. By combining different data sources and contextualizing via a functional namespace, this manufacturer can easily measure OEE, identify areas where machines are underperforming, and take steps to improve efficiency and productivity. 

Informative Namespace 

An informative namespace organizes abstracted data parameters in an industrial system on their informational content solely for the consumption by software, data lakes, and other systems. This means that the parameters are grouped together based on the type of information they provide rather than their physical location or function. A use case for using informative namespace would be for an Automotive Tier 1 supplier Manufacturing company to have a namespace specific to all temperature data parameters or pressure data parameters from the various factory locations specifically designed for consumption by an Energy Tracking application. This allows the application to easily access and analyze all temperature and pressure data from all machines so that it can use that to track the electrical usage at various levels of their factories at various locations. By grouping data based on informational content, it becomes easier for the application to identify patterns and trends in electrical usage so that it can make better and informed decisions about how to optimize their operations to reduce electrical consumption.

Definitional Namespace

A definitional namespace organizes data parameters based on their definitions or attributes. This means that parameters are grouped based on their characteristics, such as type, size, or function. These parameters seldom or never change, such as an asset’s installation date, firmware version, date of calibration etc. A use case for this is to combine all of the data parameters related to high-value equipment (like a bioreactor in the case of a pharma manufacturing company) into one namespace so that the latest alarms, alerts, and other data points related to that can be seen in one location. This allows them to compare and contrast the various bioreactors in operation, how effective they are, and how to optimize them to get the best results. The definitional namespace ensures that the comparisons of the various bioreactors are effective as the asset parameters can be easily compared.

Ad Hoc Namespace

A fourth type of namespace is an ad hoc namespace. It is typically a temporary or ad hoc way of organizing data. However in some cases, the ad hoc namespace could be permanent as well. This might be used when a more formal namespace is not yet set up or where data must be grouped together quickly for a specific purpose like maybe trying to solve a problem for which the parameters need to be localized. A use case is for an Upstream Oil and Gas customer, that is experiencing sudden equipment failures, to set up an ad hoc namespace around that failure event that could pull together the data from all of the equipment, systems and processes that are related to that event in order to quickly diagnose and fix the problem. Although this could be a temporary namespace, it could also be a permanent one to allow this namespace to be exported to solve the same or similar problem elsewhere in the organization.

Organizing of UNS Data

The below figure shows how the UNS data is organized and grouped together into the various namespaces that would make it easy for manufacturers to see the latest values based on the various topics and messages. As illustrated, the underlying data that feeds into the various namespaces could be coming from different locations: the infeed could be coming from MES; the temperature and pressure information could be coming from the PLC; and the material name and manufacturer could be coming from the ERP system. While this figure is meant to show the comprehensive nature of what a UNS can do, typically manufacturers starting on this journey start off very small and have a simple UNS for the use case that matters to them the most. They then build on it to add in other use cases that make sense for them. As can be seen from the tree structure below, this is the ISA 95 model of organizing data on the plant floor. An MQTT broker is able to take that ISA 95 and map that into topic namespace to create the UNS structure.

Figure 3: Illustration of what data to publish to the UNS

How to Get Started on the UNS Journey

To get started on the UNS journey, the first steps would be to get some process and data alignment that would ensure the maximum benefits from UNS structuring. Some of the key considerations are:

Data Governance 

It is always recommended to have a data governance team with specific goals around data management and governance. First, the team needs to audit and record the current state of the data which includes what the different data sources are, where they are located, what their formats are etc. Next would be to classify the data in terms of its sensitivity levels so that the right access controls can be set up. The next step is understanding the life cycle of the data in the organization. As data continues to flow through, it needs to be managed effectively at every stage, through policies and procedures. Establishing who needs to be the data stewards across the organization that approves the life cycle of the data is important. 

The next step would be to make the business case for data governance to key stakeholders across departments, getting their buy-in to ensure that these policies are circulated and followed throughout key areas of the organization. The last step would be to keep mechanisms and metrics in place to monitor, evaluate, and improve the governance processes over time. Having goals for the data governance program’s effectiveness is a good way to benchmark the organization’s progress. The metrics used need to be clear indicators of the performance of the data governance policies and processes, to avoid the trap of metrics for the sake of metrics.  

UNS Topic Structure

A continuation of the data governance process would be to ensure that the data is ready for UNS. Given that different plants within the organization need to come together for UNS, it is important to standardize on the topic structure that mirrors how the organization would like to structure the data. Some of the layers could be governed by a central entity which is in charge of the overall data strategy/governance and others could be ungoverned to allow individual teams to manage themselves to provide some flexibility. For example in the case of a dairy farm in Figure 4 below, they want only the physical locations in the topic structure tree below to be governed by their central data team and all the logical structuring is left ungoverned to allow individual teams to build their own namespaces as they see fit. 

Figure 4: UNS Topic Structure

UNS Security

Security is the most important aspect of ensuring that the UNS and data governance is effective. When it comes to applying security policies, one of the best practices in industrial use cases is to provide the highest level of security and reliability when authenticating and authorizing a client access to a UNS. The most preferred way is to utilize an advanced Identity and Access Management solution like Azure Active Directory, OpenLDAP, Jump Cloud or other authentication mechanisms whenever possible. However there would be scenarios, especially initially when migrating systems over to UNS, where that is not feasible. In those scenarios, an alternative would be certificate-based authentication. This can be done by using digital certificates to validate client identity which adds an extra layer of trust and encryption. If neither of these options are available in rare scenarios, the fallback option could be a simple username and password authentication.

One of the best practices that HiveMQ offers in client authentication and authorization to a UNS is through our Enterprise Security Extension (ESE). When a client tries to connect to HiveMQ, the client runs through a pipeline of the ESE before the connection is accepted. The pipeline can consist of any of the above-mentioned authenticating and authorizing mentioned based on the customer situation. This pipeline contains the individual steps that are required to authenticate and authorize the client. It is possible to configure multiple pipelines to authenticate or authorize different types of clients with different mechanisms as preferred by the customer as illustrated in Figure 5 below.

Figure 5: UNS Security

UNS Data Encoding and Formatting

Data Encoding essentially is publishing data with the standard topic structure and payload format so that it can be published correctly to the UNS and so that the other subscribing clients can interpret it. This is where the Sparkplug standard really helps as it has defined topic structure and payload format that can be easily understood. However, if there are systems within the UNS especially on the IT side that cannot interpret this format, then that could be a limitation. This is where some data conversions from Sparkplug Google ProtoBuf encoded format to JSON format would help. The overall best practice is that if a producer is not able to publish data with the standard topic structure and payload format, then the producer must publish to a separate namespace and a middleware will be required to convert. HiveMQ’s Data Hub is an example of such a middleware that can do this conversion. The Data Hub also enables formatting of the data to ensure that high-quality, normalized, and contextualized data gets to the UNS.

Ready to Reap the Benefits of a UNS?

Getting started on the UNS journey for Industrial companies is all about the introspection of where they are, what they would like to achieve, and what cultural and process barriers they need to overcome. The good news is that the journey with UNS is totally customizable to any company in any industry as seen in some of the examples mentioned above. Are you ready to reap the benefits of a UNS? If you are, please reach out to us and we can help. You can also download and try our software for free.