The digitalization of industrial production has been driven forward for years with ever-increasing investment. However, comprehensive factory-wide or even company-wide digitalization is still the exception. According to McKinsey, there is a value creation potential of USD 3.7 trillion, but more than 70% of companies are unable to exploit this potential (source). Even on factory tours through so-called lighthouse factories, the production lines presented are often lighthouses themselves. So what is stopping the industry from making the breakthrough? And can the implementation of the Unified Namespace (UNS) in manufacturing help?
The data problem in manufacturing
To identify the central problem in the industry, let’s first take a look at the value creation potential of USD 3.7 trillion. Where does this immense potential come from? The simple answer: data. Industry 4.0 strives to use all available data to gain comprehensive insights into the past, current and future business situation. This includes:
-
- analyzing past business processes to create transparency for key performance indicators such as OEE
- Monitoring and analyzing current processes (e.g. through the implementation of condition monitoring)
- the prediction of future business processes (e.g. by predicting machine failures).
Although the effective use of data is crucial to remaining competitive, the industry has not yet managed to achieve a breakthrough. In addition to general challenges such as data silos, data quality and data security, the following two specific problems exist within the manufacturing industry.
1. Application-centric architecture
Today’s system architectures are very complex. Every system provider, whether in the OT or IT sector, sees its own application as the central pivotal point. The applications are integrated with all other applications on the neighboring levels of the automation pyramid. Thereby, each integration is created individually. This essentially means that protocols, data types and semantics have to be mapped, copied back and forth and integrated each time. Each new integration increases the overall complexity of the system architecture. And with increasing complexity, data acquisition and the system integration is becoming more and more complicated. 
In addition, the dependency on an OT or IT system increases with every integration. The dependency does not usually arise from the application itself, but from the non-transparent network of integrations that are built around it. This is exactly what makes it difficult to switch providers. While systems should actually be interchangeable, they are at the center of the architecture (application-centric architecture).
2. Extreme system heterogeneity in OT and IT
The integration of OT/IT (e.g. machines, Historian, MES) usually takes place in the brownfield, with considerable differences between production lines and factories. Numerous generations of systems exist side by side, some of which may have been in operation for decades. This heterogeneity of the systems generally increases with the size of the company. The lack of standards in the systems, their interfaces and their data semantics makes data connection and system integration considerably more difficult.
The Unified Namespace (UNS) – Overview
In contrast to an application-centric architecture, a data-centric architecture focuses on the data. The idea is that systems and applications should be built around the data and be interchangeable. This is precisely where the concept of the Unified Namespace (UNS) comes in. The UNS is an architectural concept that aims to make all of a company’s data centrally accessible in real time. Thereby, all data is accessible via a standardized naming convention and data structure in a central message broker. Systems that are connected to the US act as both data producers and consumers. You publish and subscribe to data via the central message broker and adhere to plant or company-wide data standards. 
This enables simple organization and access to data across different systems and locations. A more detailed introduction to the UNS concept can be found here.
The Unified Namespace (UNS) in Manufacturing
While the concept of a UNS can be used in various industries, there are some specific questions that need to be answered in the manufacturing industry. Examples of this include the question of the appropriate architecture level for the UNS implementation (e.g. factory edge, cloud) or the question of integrating OT systems (e.g. machines) into the UNS. Often dozens or even hundreds of factories and thousands of plants, systems and technologies have to be integrated. It should also be borne in mind that although a UNS in production can bring the aforementioned benefits, the costs of implementing and maintaining such an architecture must also be taken into account. Careful evaluation and consideration of the benefits in advance are crucial for success.
Advantages of the Unified Namespace (UNS)
The Unified Namespace (UNS) concept has significant advantages over the classic automation pyramid. It increases the data availability, scalability and dynamic exchangeability of the systems involved. Further advantages are:
- A flexible architecture that can adapt to changing business requirements (e.g. scale-up or scale-down scenarios)
- A central location for sharing and managing factory data (single source of truth), regardless of source, protocol or format
- Interoperability across departments, processes, systems and technologies
- Improved data accessibility and transparency for all users
- Independence from OT/IT system providers
Implementation challenges
The UNS is a concept for the architectural design of a scalable data infrastructure. It is not a “one-size-fits-all” solution that is simply installed and ready for immediate use. Rather, it requires the right tools, organization, processes and approach to successfully implement a UNS. Two key challenges are:
1. Single Point of Failure: A UNS can be a single point of failure. If the UNS fails, this can have serious consequences for all connected systems. To avoid this, robust redundancy strategies are implemented in practice. These include, for example, distributed architectures and automatic failovers. Tools such as i-flow support the implementation of redundancies.
2. Integration of OT and IT systems into the Unified Namespace (UNS): To connect heterogeneous OT and IT systems (e.g. PLCs, SAP) to the broker, a gateway is often used in practice to integrate these systems. This component provides the corresponding OT/IT connectors and structures all data according to the defined naming conventions and data structures. 
This ensures that the connected data sources publish the data to the broker in accordance with a defined standard so that every system or user can retrieve and use this data directly without any additional effort. Standardization, especially of the heterogeneous machine landscape, is the key to a scalable application of the Unified Namespace (UNS) in the manufacturing industry. Further information on the main components of a UNS architecture can be found here.
Step-by-step guide for successful implementation
The following steps are required to implement the Unified Namespace (UNS) in the manufacturing industry (detailed step-by-step instructions can be found here).
1. Define your goals in the area of data management
Identify the most important requirements of your business units (e.g. increasing transparency in operational processes) in order to derive objectives for data management at company, business unit and operational level (e.g. increasing data accessibility). Define priorities and set measurable goals (e.g. make data from system X accessible to department Y). This is important in order to monitor and check your UNS Pilot use case at a later stage.
2. Define your data architecture
A prerequisite for the successful implementation of the Unified Namespace (UNS) in the manufacturing industry is the definition of a standardized data architecture. This includes a blueprint on how factory data is organized and managed. defining how data is published, transformed, stored and accessed by different users in the UNS. The blueprint also includes the definition of a data model that describes the representation of OT systems in the broker. A data model is an abstract archetype for describing the properties of real objects (e.g. machines, test benches) and their relationship to each other. It essentially defines the structure of the data (e.g. how data is received or displayed in an application). Defining a common data model can be challenging because you may not yet have a complete picture of all the use cases in your factories. Therefore:
- Use general standards as a basis (e.g. ISA95, OPC UA Companions, specifications from consortia)
- Start with your first pilot use-case (e.g. company-wide OEE analysis)
- Develop your data models further if there are extensions or changes in the use-cases.
3. Identify relevant OT and IT systems
Identify the most important and relevant OT/IT systems for integration into the UNS. Examples include PLCs, sensors, SCADA, historians, databases, MES and ERP systems. Also determine the key stakeholders who are responsible for the systems or need to access these resources (e.g. business users, data analysts). Involve the stakeholders in the project.
4. Define your infrastructure
The data infrastructure should be derived from your objectives from point 1. The infrastructure ensures that the data architecture defined in point 2 can be rolled out across all factories. Remember that you may have real-time or closed-loop requirements in your factories that need to be considered when defining the server infrastructure and networks for your UNS. The rule of thumb is to pre-process and harmonize factory data as close to the data source as possible. In this way, you can make factory data available in your network as early as possible and minimize cloud costs at the same time. They also enable closed-loop use-cases with lower latencies and higher security requirements. In most cases, the implementation of a well-coordinated edge-to-cloud UNS architecture is most effective (see the example with i-flow as a factory UNS combined with Azure IoT). 
In addition to the definition of servers, networks, etc., this step also includes the selection of suitable middleware for your UNS. The middleware takes care of the integration of the various systems and provides a message broker as a central location for your factory data. At best, a search mechanism makes finding your factory resources as easy as possible. The more intuitive the UNS middleware is designed, the less training is required for your employees (e.g. for accessing resources within the UNS).
5. Start with the pilot use-case
Prioritize potential use cases based on their cost-benefit ratio to define a pilot use case. Monitor and review your pilot use case with regard to your data management goals from point 1.
Summary
Data is crucial for the competitiveness of the manufacturing industry. The effective use of data in different factories enables efficiency and quality improvements as well as cost reductions on a global level. However, one key mistake is holding the industry back: application-centric architectures. Why do many OT and IT system providers believe that their application is the center of all things? Why is data often the property of the system provider or the application? This approach is fundamentally wrong! The concept of the Unified Namespace (UNS) corrects this error. A UNS places the data at the center of the system architecture and manufacturing companies become the real owners of their data. Applications are then integrated around this data. The result is greater flexibility, interoperability and data availability. When implementing a UNS in the manufacturing industry, there are some challenges that should be considered in the evaluation process. By defining clear steps in the evaluation (such as defining data management goals), you can minimize the risk of not simply putting another application (instead of your data) at the center of your architecture with the UNS.
