The Unified Namespace in Manufacturing

Industry 4.0 and the digitalization of industrial production have been driven forward for years with ever higher investments. But comprehensive factory or even company-wide digitalization is still the exception. In fact, while there is a 3.7 trillion USD value creation potential, more than 70% of companies cannot capture this potential at scale. Even on tours through so-called lighthouse factories, the production lines you pass are usually lighthouses themselves. So, what is preventing industry from making the breakthrough?

To answer this question, one must understand where the potential of USD 3.7 trillion actually comes from. In very general terms: data. Industry 4.0 aims to leverage all available data to get the most accurate picture of how business has been in the past (e.g., by creating visibility into KPIs like OEE), how it is performing in the present (e.g., by implementing use-cases like condition monitoring), and how it is likely to be in the future (e.g., by predicting machine failures with predictive maintenance). Whether the decisions are made by those responsible in the company or automatically by the machines.

Now – if data creates the potential, what is holding the industry back?

In addition to industry agnostic challenges related to data and its management (e.g., data silos, data quality, data security), there are two industry-specific hurdles that must be overcome to effectively use data in manufacturing.

1. Extreme System Heterogeneity

The OT/IT system landscape (e.g., machines, historians, MES) is usually a brownfield scenario with large differences between production lines and factories. Many different generations of systems operate side by side, and some of them may have been in operation for decades. Usually, the heterogeneity of the systems increases with the size of the company. The lack of standards in the systems, their interfaces and data semantics make data acquisition and system interconnection for command execution very painful.

2. Application Centric Architectures

Today’s system architectures have become complex. Every system provider – whether OT or IT – sees its application as the center of the universe. As the center of the universe, systems are integrated with all other systems of adjacent levels of the automation pyramid. Each integration is built individually to essentially copy data, mapping protocols and data semantics, which adds complexity to the overall system architecture. As complexity increases, data collection and interconnection between systems become more difficult.

n addition, dependency on a particular system increases with each integration. In fact, the dependency on an application comes not so much from the application itself, but from the various integrations built around it – making it difficult to switch vendors. The point is that while systems and applications should be interchangeable, the data remains and is important. Therefore, it’s the data that should be at the center of the universe – not applications.

As a result, although leveraging data is critical for manufacturers to remain competitive, industry is failing to make the breakthrough. To change this, it is time to introduce a data-centric architecture approach that addresses the industry’s specific challenges: the concept of a Unified Namespace (UNS).

The Unified Namespace – an overview

A Unified Namespace (UNS) is a non-hierarchical system architecture in which all data is accessible through a consistent naming convention and data structure from a central message broker. Systems connected to the UNS serve as data producers and consumers. They publish and subscribe data from a central message broker, following factory or company-wide data standards. The message broker provides the data of integrated OT and IT systems via a central plant-wide network protocol (typically MQTT and / or Kafka are used as brokers in the manufacturing industry). This enables easy organization and access to resources, as well as sharing and linking resources across different systems and locations. For the integration of heterogeneous OT and IT systems (e.g., PLC, SAP) into the broker, the most suitable component is one that provides appropriate OT/IT connectors and can harmonize all data according to the defined naming conventions and data structure. This ensures that the connected data sources publish the data to the broker in a standardized way so that any other system or user can retrieve this data directly. In this way, a UNS ensures fast data availability, scalability and dynamic interchangeability of the systems involved.

In general, implementing a UNS in manufacturing has the following advantages:

• Flexible architecture that can adapt to changing business requirements (e.g., scale up or down scenarios, reallocation of manufacturing resources)
• A centralized location for sharing and managing all factory data, regardless of its source, protocol or format
• Improved data integration and interoperability across departments, processes, systems and technologies
• Enhanced data accessibility and transparency for all users
• Independence from OT / IT system vendors

While the concept of a UNS can be used in different industries, there are some specific questions that need to be answered in a manufacturing environment. Examples are the question of the appropriate architecture layer for UNS implementation (e.g., factory edge, cloud) or how OT systems (e.g., machines, sensors, test benches) can be integrated into the UNS. Also keep in mind that, while a unified namespace in manufacturing brings a lot of benefits, the costs for implementing and maintaining such a system must also be considered.

Implementation of the UNS in Manufacturing

Implementing a Unified Namespace for the first time in a manufacturing environment can be a bit more challenging than in other contexts, as it often involves integrating dozens or hundreds of factories, thousands of assets, systems, and technologies. Therefore, plan ahead and follow the steps below.

Define your data management goals

Identify and understand the key business needs of your business units (e.g., increase transparency in factory operations) to derive data management goals on corporate, business unit and factory level (e.g., increasing data accessibility). Prioritize your goals and set measurable targets (e.g., make data of system X accessible to department Y). This is important to monitor and review your UNS pilot use-case in a later stage.

Define your data architecture

A well-defined data architecture includes a blueprint on how your factory data is organized and managed. In addition to defining how data is moved to the UNS, transformed, persisted, and accessed by different users, the blueprint includes the definition of standard data models that can be shared across assets and factories. A data model is an abstract archetype for describing data and 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 can be received or displayed in an application). When implementing a UNS for the first time, defining of a common data model can be challenging because you may not yet have a full picture of all the use-cases in your factories. Although strategic thinking is very useful when modeling data, don’t start lengthy discussions to find the best possible and most generic data model. You may never create your first model. Instead:

1. Use common standards as a foundation (e.g., ISA95, MQTT Sparkplug, consortia specifications)
2. Start small and with your first pilot use-case in mind (e.g., company-wide process monitoring)
3. From there, evolve your data models whenever you make changes in the use-case.

Identify key OT/IT systems and stakeholders

Identify key OT/IT systems and technologies that need to be integrated in the UNS such as PLCs, sensors, SCADA, historians, databases, MES and ERP systems. Also determine the key stakeholders that need to access these resources (e.g., business users, data scientists).

Define your infrastructure

The data infrastructure should be derived from your data management objectives and ensure that the defined data architecture can scale across factories. Keep in mind that you may have real-time or closed-loop requirements in your factories that need to be considered when defining server infrastructure and networks for your UNS (e.g., physical, virtual, edge, cloud). As a rule of thumb, pre-processing and harmonization of factory data should be done as close to the source as possible. This way, you make factory data usable and available in your network as early as possible, while minimizing cloud costs. In addition, you enable closed-loop use- cases with lower latency and higher security requirements. In most cases, implementing a well-aligned edge-to-cloud UNS architecture is most effective (see example in picture 3 with i-flow as factory UNS combined with Azure IoT).

In addition to defining servers, network, etc., this step also includes selecting an appropriate middleware for your UNS. The middleware takes care of integrating the various systems into the UNS and provides the message broker as a central location for your factory data. In the best case, a search mechanism makes finding your factory resources as easy as possible. The more intuitive the UNS middleware is built, the less training is required for your corporate and factory employees (e.g., on how to access resources through the UNS).

Start with your UNS pilot use-case

Prioritize potential use-cases based on their benefit-cost-ratio to identify the first pilot. Monitor and review your pilot regarding your data management goals and targets.

Conclusion

Data and its effective management are essential to the competitiveness of today’s manufacturers. Leveraging data across factories enables efficiency and quality improvements as well as cost reductions on a global scale. However, there is a key misconception in today’s architecture that is holding the industry back: application- centric architectures. Why does every OT or IT system provider believe that their application is the center of everything? Why is the data owned by the system provider or the application (e.g., by storing data in individual data structures in inaccessible application databases)? This is wrong. Data is the essential asset and must be placed at the center of the architecture. It is the manufacturers who should own this asset, not the vendors or their applications. A unified namespace (UNS) eliminates this misconception by putting data at the center so that applications can be built and integrated around it. The result is greater flexibility, interoperability and data availability. However, effectively implementing a UNS comes with a number of challenges that should be considered during the evaluation process. By following a few steps, such as defining your data management goals to derive an appropriate data architecture and infrastructure, you can mitigate the risk of placing just another system (and not your data) at the center of your architecture.

Get in touch now!