The Unified Namespace - to boldly go where we should have gone before

So we’ve entered a new year, and we are going to face some new challenges. I’ve been talking about Industry 4.0 a lot last year, but always a quite a high level.  Yes, Industry 4.0 should help us become more effective, efficient, sustainable, etc. That’s clear, but how can we do that? Through technology, obviously, otherwise the whole technology world wouldn’t be talking about it. So, it’s time to dive in deeper and have a look at technology.

As a sort of carrier, I will start with the Unified Namespace, a concept that is based on new technology as well as the shortcomings of existing technology, and is slowly becoming a carrier for really smart solutions.

In this article I’ll focus on the concept, in two follow up articles I’ll go deeper into how it works from technology perspective, and some follow up questions, like whether UN is a good model for every type of manufacturing.

The stack
In the manufacturing world, we have build stacks of software. We have ERP systems that are put on top of MES systems, which in turn are on top of SCADA, and SCADA is on top of PLCs. At the bottom, below the PLC you find the actual sensors and actuators that run a production line.
That was also the basis of a picture that I used to explain the idea of ERP+ (or ERP in the cloud) a few years ago. In this stack, commands go down, and information, like statuses and errors,  would go down.
This means that there is a lot of so called point-to-point communication between the layers of the stack - and a lot of information is not shared at all between the layers because it would require too much communication. Also, storing all data in all layers would take up a lot of space - while most layers wouldn’t use it.
That is a pity, because in an Industry 4.0 environment, all data is important. All data from all layers combined is what potentially gives us most insight into what is going on in a factory, or even in a group of factories. With that combined data, it becomes possible to analyse issues on all levels.
A very basic example: in the ERP system we can see that orders of certain products often are not produced on time, or take longer to produce than planned. If we want to know why, we need information that is often only available in the MES system, and if it’s historical data probably not even there, once again because of storage limitations.

Figure 1 - the ‘stack’

Sharing to move forward
Without all these data items being shared, it becomes harder to realise continuous improvement of (production) processes, which is one aspect of Industry 4.0. The figure below shows a continuous improvement loop, where the stack we just looked at is depicted on the left. Right of that is data gathering, which provides the data for analysis. Finally, the analysis should lead to process and technological improvements. This loop is hard to implement if we need to get data from all layers of the stack, through all layers. To avoid this, the data gathering should be done in a different way, allow analysis (and possible) other applications access to data on all layers, whenever needed.

Figure 2 - the continuous improvement loop

This is where the Unified Namespace comes in. The Unified Namespace is actually a combination of two things. First of all, a storage facility, that contains all data that is made available to all (analysis) applications. Second, it’s an API that allows the applications to access the data, and third, a mechanism to gather the data from data sources that are unaware of the Unified Namespace.

As an example, let’s use the same products we used before - that is, the ones that were not produced according to plan. In order to collect data for analysis of what is wrong with the production of these products, we need to have a look at the following items:

1. From ERP:
   1. The planning
   2. The actual reported delays in the planning
2. From MES:
   1. The translation of planning into scheduling
   2. The reported feedback on each production step
3. From PLC and sensors
   1. The timings of data received from MES
   2. The data send back to MES
   3. The sensor values that change between receiving and sending data

The reason we talk about sending and receiving data on the PLC is because MES or SCADA typically write to or read from a PLC, the PLC itself doesn’t actively push or pull commands.

If we only have the point to point connections between the layers, which is ‘traditionally’ the case, that would mean we have to transfer all data from MES and PLC up to ERP before we can access it for analysis.
With the Unified Namespace, we introduce a mechanism that allows data to be collected from all layers at the same time. This means that the data from ERP is stored in the Unified Namespace, the data from MES and the data from the PLCs.
This data is then stored in a hierarchical model, that resembles the structure of the factory. Through the interface, applications can traverse that hierarchy, and get data from the exact point they are interested in. In this hierarchy, the whole business is represented, from enterprise level down to the sensors and actuators. This allows to connect everything in analysis and improvement activities.

Walker Reynolds of Solutions 4.0, who is one of the inventors of the Unified Namespace architecture, gives the following example of this hierarchy in one of many videos he created to explain the concept. This is depicted in Figure 3.
The structure resembles the whole company, and at each level the relevant data is stored. In the example it is based on ISA-95, a standard that a lot of manufacturing systems are based on.

Figure 3 - hierarchy structured in line with ISA-95

In this hierarchy, we can collect the ERP information on Site level, and the MES and PLC data on Line and Cell level. When we have that, we can use that combined data to figure out if there is a reason these orders are apparently always late. We can for example feed it to a machine learning algorithm to do that for us, or perform some statistical analysis.

Figure 4 - UN in context

Getting the right data at the right time
In figure 4, the Unified Namespace is shown as the center piece between the traditional stack and the Industry 4.0 applications that use the data. This is all that is needed to use the example application above work.

However, we may also have more real-time applications that we want to implement. After all, Industry 4.0 should make things more effective, and in production there are many cases where being effective means taking immediate action when something happens.
That brings us to a key issue that is addressed in the Unified Namespace architecture: getting the right data in at the right time. What is stored in the Unified Namespace is not the state of data at any given point in time, but data collected over time, with full history. To do this, in the Unified Namespace we define what data needs to be collected, which data items should be there. After that, during operation, every time the value of a data item changes (or it is created) it is stored in the Unified Namespace, including the time stamp of when the change occurred. In other words, the Unified Namespace stores all changes to data, which we call events.

This gives us the opportunity to have operators and managers in a factory have a full overview of everything that is going on - or just the subset that has relevance for them.
At the same time, this mechanism makes that the Unified Namespace contains all data about the business, the enterprise, representing not only the current state, but also every previous state.
With those two things in place, we can have a real time view of whatever is relevant for someone in the organisation  and replay or analyse parts of what happened in the past as well to find causes, effects and possible optimisations.

The technology
A key technology item in Unified Namespace is the MQTT (Message Queue Telemetry Transport) protocol. It is a message exchange mechanism based on publish-subscribed - the possibility for applications to subscribe to certain message queues, which are filled nay other applications. This mechanism, plus some other that are build on top of It make Unified Namespace possible. The technical details of that I will go into in the next article in this series