Unified Namespaces in manufacturing and operational excellence

The emergence of the Industrial Internet of Things (IIoT) over the last couple of decades has been seen as a key enabler in improving industrial operations. By leveraging a combination of machines, devices, IT systems and operators-in-the-loop, the promise of IIoT is to provide the critical data that manufacturers need, to be able to make core operational decisions to drive efficiency & profitability.

The reality is that utilising IIoT in modern industrial operations is incredibly challenging. Fragmentation and heterogeneity across industrial control systems, sensors, edge devices, protocols & more have resulted in complex, multi-hierarchical infrastructure systems. The resulting high overhead and technical skills required to both stitch together and monitor such infrastructure has meant that the ROI from such digitisation efforts often does not make sense for manufacturers to pursue.

In this article, we explore what Unified Namespaces (UNs) are, how they can serve as a significant improvement to existing IIoT architectures, and how manufacturers make use of them in the pursuit of operational excellence.

A (brief) history of industrial automation

The IIoT architecture of a standard factory operation can often look like this:

To understand why such a common architecture like this has emerged, there is benefit in going back in time in and understanding the history of industrial automation.

Over 40 years ago, PLCs (standing for programmable logic controllers) emerged. Now very common today, these are machines - provided by vendors such as Siemens, Rockwell Automation, ABB & more - that interface with industrial equipment. Their role is to serve as a physical conduit between industrial equipment and other systems, passing data & instructions from one to the other. This hardware is not inexpensive, and manufacturers undergo significant capital expenditures to implement this automation equipment into their production lines.

The challenge with most PLCs, even today, is that at the core they focus on reliability - after all a production process needs to minimise all points of failure - which made interfacing with them, storing data, and performing analysis difficult. In response to these challenges, different software providers built varying solutions to help build downstream data workflows & storage from PLCs.

Data historians (such as AVEVA) provide on-premise time-series databases that serve as a local storage of all the data PLCs generate. SCADA software (standing for Supervisory Control and Data Acquisition) interface closely with PLCs to enhance data collection, monitoring, control, and often human-machine interface interactions (HMI systems).

With low-level operational data collection, manufacturers next tried to piece together this data with the rest of their production operations. Manufacturing execution systems (MES) were designed to help track the production process end-to-end. ERPs then came in as a layer above to provide broader visibility across production schedules, resource management & more.

This layering of infrastructure and the resulting technical debt - a natural evolution as a result of ever improving technology - leads to a series of challenges that impede speed, flexibility & efficiency:

• Point-to-point integration. At each layer, automation engineers & IT teams need to connect together differing systems. Unfortunately there is a wide fragmentation across connection methods & protocols from the PLC layer upwards which multiplies the integration efforts required.

• Different data models. Each separate provider often has their own data model. This can make it very difficult to build standardised metrics and a view on the production process. It can also lead to data gaps where it is too difficult or cumbersome to record, process and store data due to integration challenges.

  • Certain organisations and companies are trying to push for a common data model at different layers in the stack, in particular the OPC foundation.

• Lack of infrastructure flexibility. Say you wanted to switch out one SCADA system for another. Or add a new PLC to a production line. This would require substantial time & cost investment ensuring that these services & hardware seamlessly speak with the layers above and below in the infrastructure.

• Lack of operational flexibility. Production challenges happen frequently, and process engineers with production personnel can spend a good portion of their time digging into root cause analysis. Finding out that certain pieces of data have not been collected or are inaccessible can be incredibly frustrating when trying to diagnose issues. Often manufacturers have limited options to track production operations in real-time which means that problems can go undiagnosed.

• Infrastructure overhead. Managing multiple different systems and ensure that point-to-point integrations work as expected takes up a lot of time for already stretched IT and automation teams.

• Cost. It is not uncommon for smaller manufacturers to spend millions of dollars over years building out their automation stack. For larger companies this can stretch into hundreds of millions.

What is a Unified Namespace?

Originally coined by Walker Reynolds, Unified Namespaces are designed to be the equivalent of a data highway: all data flowing from any machine, device or IT system communicates to the Unified Namespace. They can subscribe (to receive data) to the unified namespace, and publish data to it, which other services or hardware can receive.

The premise is to condense the layers of the industrial automation infrastructure into a hub-and-spoke model. The Unified Namespace is the central communication piece for which all other industrial automation and IT systems connect to.

There are different flavours of Unified Namespace, as the concept has been developed over the last few years. Some practitioners see Unified Namespaces as an instantaneous view of events that are happening in a factory at a given point in time. Others see it also being a source of truth for all information about a factory - that is, it is a record of historical information in addition to being a record of the present.

We prefer seeing a Unified Namespace in the more simpler formation: as an event-driven data broker that captures events occurring in a factory at a given point in time, with some additional context (or metadata) for each data point. This additional metadata usually encapsulates some structural information about the organisation.

An example may be: Organisation → Site → Area → Line → Cell

This type of metadata attached to each data point helps create a degree of uniformity for all events handled by the broker, to provide additional context (via the embedded namespace) for other services that consume the data.

We believe that storage should be considered separately as part of a data lake / data warehouse architectural decision. The sheer volume of data that PLCs and data historians can generate can easily scale to terrabytes and above: a naive implementation of a data lake can incur spiralling cloud costs. We dug into this topic in one of our previous articles here.

There are a series of benefits that come with a Unified Namespace over the traditional model:

• System flexibility. Manufacturers can easily bring in new pieces of industrial automation equipment and new software solutions, and remove less-effective services. As long as the Unified Namespace supports protocols and communication methods, integration efforts can be reduced.

• Communication standardisation. Services publishing to a Unified Namespace no longer have to be concerned with which other services are consuming their data by removing point-to-point integrations. Unified Namespaces allow for ‘fire-and-forget’ event processing. A service can publish data to a Unified Namespace that can be consumed by multiple other services with one integration rather than many.

• Reduce data gaps. If a plant manager wants to start collecting new data points or metrics they previously did not have access to, they can now direct automation & IT teams to expand the data being generated at source (i.e. PLCs etc). This can be fed straight into the Unified Namespace which can be consumed by other services.

• Scalability. Because everything connects to a central hub, it is now possible to add a larger number of additional devices & services, without causing failure points (as long as the Unified Namespace can scale with its own underlying infrastructure).

How does this help operational excellence?

Operational excellence in manufacturing refers to the process of improving plant performance, reducing costs & waste, and increasing production profitability. Commonly, it involves comparing best practices across production processes across different sites, and sharing & implementing learnings between them. Many manufacturers have dedicated professionals with deep experience in their domains whose focus is on this.

Implementing a Unified Namespace architecture can help operational excellence teams to accelerate their initiatives. It allows them to build & benefit from standardisation of key metrics & performance indicators in a way that gives a unified view of production processes - both within a site across different production lines, and also across sites as well - as a means of identifying best practices.

With a Unified Namespace, operational excellence teams - working in tandem with the rest of the organisation - can develop a common ontology that represents the key data types and models that are relevant for multiple teams within a company. This allows teams to more effectively collaborate on a common understanding of metrics over and above the already present metadata; and also serves as unified input into other business / IT systems (i.e. finance, management reporting, procurement etc).

As with all important architectural decisions, there are a few considerations that need to be taken when implementing a Unified Namespace architecture:

• Scalable reliable infrastructure for the (central) data broker. If the underlying data broker for the unified namespace is managed with a central piece of infrastructure (i.e. server), it can serve as a single point of failure. It may also additionally be hard to scale out with data volume. There are ways of having the data broker operate with a distributed infrastructure with embedded high availability to solve this issue (we at Ferry for example, follow this distributed approach).

• Data volume management. It is tempting to push all generated data to the Unified Namespace. The reality is that not all data is equal in terms of value. Processing raw data closer to the source into useful metrics that can be consumed by other services reduces cost and load on the central data broker.

• Overcomplicating data ontology too early. When designing & implementing a Unified Namespace architecture, it is equally tempting to start with a data model containing everything you want to track. It is more effective to start with a given use case, process, or even machine: bringing them into the Unified Namespace architecture first to solve a core pain point before bringing other systems in.

• Connections to IT systems. Integrating systems such as an ERP or an MES is often much more difficult due to the complexity of the integrations. Depending on the case it might be that the manufacturer needs to procure an integration layer for these systems that can then connect to the Unified Namespace. Our advice is to start with the operational technology (OT) systems (i.e. PLCs, historians etc) and then work to integrating other IT systems in to the broader architecture.

How can manufacturers get started?

From our experience, the best way of moving to a Unified Namespace architecture from the traditional IIoT set-up is gradually and over time. It is best to identify a critical use case with clear ROI (i.e. predictive maintenance for a given machine) in a single process (ideally with a single machine), and bring that into an event-driven architecture. Subsequently, manufacturers can connect other devices, sensors, and IT systems into the broader unified namespace as additional use cases are identified, building up across the process level and then on a site level.

At the beginning, it is helpful also to focus on setting up the core connectivity between the ‘hub’ (the data broker) and a ‘spoke’ (PLC, historian, local SQL server), without too much emphasis on an embedded data model or ontology. This does not preclude adding base metadata we described above - but going beyond on defining data models around particular assets within the Unified Namespace architecture does not have to be the first port of call. This gradual approach helps companies to assess what data is actually helpful, and what is not - and allows the right metrics, data models & more to be weaved into the Unified Namespace architecture over time.

In our next article, we’ll dive into different ways of implementing a Unified Namespace in an industrial context.