Many manufacturing companies are working with a massive amount of data. And as manufacturing operations become more automated, this data can spread across the entire company.

• Process control data and SCADA system integrations allow operators to control production lines, monitor for alarms, and manage setpoints and trends.

• Manufacturing Execution Systems (MES) integrate with the Enterprise Resource Planning (ERP) system to retrieve work orders and product codes along with the production schedule so that the plant floor knows when and what to make. The process feeds data back into the MES System to monitor Optimal Equipment Effectiveness (OEE).

• Quality Control checks to see if the products made are in spec, and QC can also integrate with the other systems to track how production conditions impact product quality.

All of this data can be sent to the customer service and logistics systems so that customers are kept up to date with the progress of their orders. Likewise, the entire business can know when an order is scheduled when it comes in from sales.

This highly integrated approach can weave a tangled web between systems to get the data it needs to be successful. The Point to Point integrations of the last few decades are no longer capable of managing modern manufacturing.

Luckily, there is a better way.

Enter the Unified Namespace Architecture

In the example above, a Unified Namespace Architecture connects plant floor devices, manufacturing-related technology, and business systems into a single source of truth. This will provide access to all the data and the current status of the business in one place. In this implementation, a Unified Namespace is a high level, human readable, representation of the current state of a business.

Unified Namespace Architecture abstracts domain-specific knowledge and information into a normalized framework. It is built on two core concepts:

1. Building out a semantic hierarchy of your business and processes.

2. Specifying, implementing, and enforcing naming conventions across the Unified Namespace Architecture so users can find and integrate the data they need to do their jobs successfully.

Semantic hierarchy (a common term in Computer Science) can basically describe the relationships between different aspects of your business. This includes the "language" of the business or how things interact with one another. It also can include the hierarchy of various production components.

To lean into ISA-95 as an example, a semantic hierarchy would describe the manufacturing process as follows:

• Enterprise

  • Site

    • Area

      • Line

        • Equipment

This example shows the various items in your business as well as the relationship between them. A line can have many pieces of equipment, and the equipment can be siblings of each other on a line.

The naming convention is also important, although the specifics you choose don't necessarily matter—as long as everyone agrees to use them. For example you could choose to use "Running" and "Stopped" for the status of various equipment. You could also choose "Flubernuf" and "Glabernaf" as long as everyone understands what they mean.

It’s easier than ever to build a Unified Namespace for your company by combining these concepts with modern industrial communication technology (such as MQTT) to streamline the flow of information across the enterprise—and by definition help build the semantic hierarchy with MQTT's topic structure.

Benefits of a Unified Namespace Architecture

The major benefits of using a Unified Namespace are:

• A drastically reduced cost for integrating with new systems and technologies since you will already have standardized and normalized models of your business and data.

• Unified Namespace Architectures are much more scalable than traditional point to point integrations which havebeen the norm in manufacturing for the past few decades.

• With all the information from your entire business at your immediate disposal, you can be much more agile when building and testing hypotheses and improving your operations—with data to back up your findings.

• Anyone in your organization can easily find the data they need across the entire business.

A Unified Namespace is considered a "single source of truth" for your data. The idea behind is that by using a Unified Namespace, you eliminate data silos and stagnant data common with "typical" system integration strategies. You don't need to know anything about the data coming in from field devices, I/O points, or tag naming conventions in the PLC (or any business systems in the Unified Namespace) to integrate data from a PLC into any system where you need data.

You can almost think of a Unified Namespace in the context of a SCADA system communicating with a PLC. The Unified Namespace acts similarly to any device (like a PLC), and contains information on all aspects of any system you have integrated into it for the entire business. Now, any other system (in this case a SCADA system), can connect to the Unified Namespace and have access to any of the data it needs.

This is in contrast to the "old" way, 1:1 connections between various parts of the technology stack such as:

PLCs <-> SCADA Systems <-> MES Systems <-> ERP Systems

Each of these connections might have different names for data at each layer, which would make it difficult to integrate your ERP system directly with your SCADA system for example.

Using a Unified Namespace forces you to separate the layers of your tech stack and removes massive amounts of complexity from a typical integration strategy. The controls team manages PLCs and SCADA systems, providing data to the Unified Namespace without needing to share specific PLC tag addresses. Maintenance has access to data from every field devices and manages them. Using modern technology like MQTT can free up the IT department from worrying about security implications since security is built into the architecture. By using a Unified Namespace, you won't need to send your MES team digging into PLCs for the specific tags they need for calculating OEE. Likewise, your PLC team will make those tags available through the Unified Namespace so the MES team can easily find what they need.

How To Easily Understand Unified Namespace Architecture

Everyone in the manufacturing world has used Excel. Some people even use it for most of their day-to-day tasks. So, for a fairly crude analogy, imagine tracking all he data for an entire business in Excel—this is similar to a Unified Namespace.

Each function of the business would have its own tab, equivalent to a node in the Unified Namespace graph. Process Data, MES, QA/QC, the ERP system, Customer Service, Shipping, etc., would each have a dedicated tab with all of their relevant data.

The Unified Namespace could be represented by a main tab with data populated from each and every other tab. The main tab’s data would be formatted in a semantic hierarchy, so you could easily look it up to see the entire picture of the business in one place.

If you needed to drill down into a calculation, or wanted more specific information, you could easily open up the relevant tab and find it there. For example take the OEE value on the main tab along with the Availability, Performance, and Quality metrics—but now you want to see which downtime events happened during the current shift. You could then open the MES tab and see a list of all of the downtime events and any relevant data for them on that tab.

This is just like seeing the values come across into the Unified Namespace via MQTT, and then opening up the MES system to dig into the specific downtime events behind your Availability number.

How MQTT Enables Unified Namespace Architectures

If you examine the topic structure in an MQTT system, you’ll see how to easily build topics which match your semantic hierarchy. (This gets complicated a bit if you are using Sparkplug B, which we cover in our MQTT and Sparkplug B Simplified post, so we will leave that discussion for another time.)

By using MQTT as the communication method for getting data into and out of your Unified Namespace, it’s easy (and essentially free) to plan your MQTT topic structure for a majority of your semantic hierarchy.

For example, if you map your topic structure to match your ISA-95 production model, you will get the semantic hierarchy of your process equipment directly from your MQTT Topics:

Using this approach, you can also add other nodes to the topic structure for places to store your OEE data at each line, along with any data from your ERP, Quality Control, Shipping, or any other domain specific systems with metrics you want to integrate into the Unified Namespace.

While the Unified Namespace can grow very quickly, it will remain very well organized and you can easily access any information you need from any level in the hierarchy at any time.

You will need to manage and build conversion tools for many Domain Namespaces to interact with MQTT. As an example with the "Enterprise/Site/ERP/Production Schedule" node, most ERP systems will not support MQTT directly. Getting this information into the Unified Namespace will require a tool to either query the ERP system directly, or read in data from an API call in the ERP system, then converting it to an MQTT topic before sending it to the broker. You can find a more detailed example of how to map this data in our post: Integrating MES and ERP Data Through a Unified Namespace.

In the above example, you can see how we are converting what is likely a tag in a PLC with a flat tag structure with a potentially non-human relevant address like B18:15.0 for the Machine A Running status. By converting the value from the Domain Specific Namespace to the Unified Namespace, this value is much more accessible to anyone outside the Controls team.

Domain Namespaces in Unified Namespace Architectures

A key idea to note in a Unified Namespace Architecture is that while you want to know the status of the business and all of your processes using the Unified Namespace, you probably won’t want ALL of the data possible from every system to go into the Unified Namespace.

We like to think of the various nodes interacting with the Unified Namespace as specific domains, as in “Domain Expertise.” The people who spend most of their workday in these specific areas of the architecture will have much more complex data requirements than the rest of the business. This is where we separate the Unified Namespace and the Domain Namespaces.

This division allows you to maintain the granularity that people on the domain side need to make sense of their worlds. And it also translates the relevant data into the Unified Namespace to fit the semantic hierarchy and naming convention for the business-specific data.

For example, in a typical PLC program, a number of timers will handle various tasks. If you were to pull every tag in the PLC into your Unified Namespace, you will have a handful of tags for each timer, many of which no one accessing the Unified Namespace ever needs to see. But, maintenance folks and controls engineers may care very deeply about these timers while they are troubleshooting a process and need to keep track of each one.

Using their Domain Namespace and PLC programming tools, they will have access to all of the data they need to troubleshoot issues with process equipment—and this data won't clutter up the Unified Namespace for the vast majority of the team.

Stated another way, a Unified Namespace contains the results from all of your Domain tools relevant to the business at large. It gives you visibility into the business and your processes, while leaving many of the details which generate those results behind the curtain. If you need to peek behind the curtain, it is easily available to you using the Domain Namespace tools across your company.

The Limitation of Unified Namespaces

While Unified Namespaces expose data to the entirety of the business in a very easy to understand way, they do have one limitation.

For anyone who doesn’t need a detailed understanding of a specific Domain Namespace, a Unified Namespace is a great tool. They can easily find what they need without having to fully understand things outside their area of expertise. The limitation arises when something goes wrong. Let's say we’re observing the OEE value for Machine A in the example above and notice the production counts are not changing over time. This might be a bottling line with a photo eye on the exit which counts how many bottles have passed, and you are not seeing it trigger at all.

While you know the value you’re seeing in the Unified Namespace, you still need to go work with the domain level subject matter experts to troubleshoot the problem.

When you explain that the value is not changing, they will need to figure out where that value is in the overall hierarchy. Then they’ll dig into where it comes from in the Domain Namespace, they’ll figure out which PLC it comes from, the I/O point, and dig into it from there.

However, you could overcome this at the Unified Namespace level by mapping additional data to fully document the system, or add in a Maintenance node to the Unified Namespace for providing an additional data map for where the values originate at the domain level. The problem is that the overwhelming amount of data you will then need to parse through and manage.

This example also applies to ERP systems. While the "Production Schedule" may pull in data from multiple tables in the ERP system, you’ll need knowledge of the ERP system's data model, or to work with a subject matter expert on the ERP team to fully understand any problems or information if you need to dig deeper into it from the Unified Namespace.

While this isn't necessarily a problem when using a Unified Namespace Architecture, the pros far outweigh the cons. However a Unified Namespace is not a silver bullet for solving every data problem in a company. You will still need to rely on your team and their areas of expertise to get the full value from your business systems.

Wrapping Up

A Unified Namespace can solve significant hurdles for your company and remove many obstacles on the journey of Digital Transformation.

Using a Unified Namespace Architecture will save you a significant amount of time on a project determining tag names and when understanding how to integrate a new piece of equipment into your process. You can give your OEM suppliers, your team, and anyone involved with the actual integration of new technology the naming spec for your business and they can plug their systems into the Unified Namespace's semantic hierarchy. As part of their commissioning scope, you can work through their UNS integration and verify that everything matches your expectations.

While a Unified Namespace won't solve every problem your business faces, it will set you up for success by giving you an easier way to understand the current state of your company from top floor to shop floor without needing to fully understand the intricacies of every piece of technology running your company.

If you have questions about Unified Namespaces, or would like more information on how to integrate a Unified Namespace for your business please reach out and let us know!