The Unified Namespace — to boldly go where we should have gone before
This is the first in a series of three posts on Unified Namespace, a concept for Industry 4.0 — to be published between end of March and end of May 2023.
In the manufacturing world, we’ve built stacks of software. We have ERP systems that are put on top of MES systems, which in turn are on top of Scada, which itself rests on PLCs. At the bottom, below the PLCs, you find the actual sensors and actuators that run a production line. Such was also the picture I used a few years ago to explain the idea of ERP+ (or ERP in the cloud).
In these stacks, commands go down and information, like statuses and errors, goes up. Between the different layers, there’s a lot of point-to-point communication. A lot of information isn’t even shared at all because it would require too much communication. Also, storing all data in all layers would take up a lot of space — while most layers don’t use it.
That’s a pity because, in an Industry 4.0 environment, all data is important. All data from all layers combined is what potentially gives us the most insight into what’s going on in a factory, or even in a group of factories. With that combined data, it becomes possible to analyze issues on all levels.
A very basic example. In the ERP system, we can see that orders of certain products often aren’t produced on time, or take longer to produce than planned. If we want to know why, we need information that’s often only available in the MES system. If it’s historical data, it’s probably not even there, once again because of storage limitations.
Hierarchical model
Without all these data being shared, it becomes harder to realize continuous improvement of (production) processes — which is one aspect of Industry 4.0. In a continuous improvement loop, we gather data from the stack and analyze it to find process and technological improvements. This loop is hard to implement if we need to get data from all layers, through all layers. Instead, the data gathering should be done differently and our analysis (and possibly other applications) should have access to data on all layers, whenever needed.
This is where the Unified Namespace comes in. The Unified Namespace is actually a combination of three things. First of all, it’s a storage facility, containing all data made available to all (analysis) applications. Second, it’s an API that allows the applications to access the data. Third, it’s 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 as before, ie those that weren’t produced according to plan. To collect data for our analysis of the problem, we need to look at a couple of items. From the ERP, we need to have the planning and the actual reported delays in the planning. From the MES, we need the translation of planning into scheduling and the reported feedback on each production step. From the PLCs and sensors, we need the timings of the data received from the MES, the data sent back to the MES and the sensor values that change between receiving and sending data — we talk about sending and receiving data on the PLC because the MES or Scada typically writes to or reads from a PLC; the PLC itself doesn’t actively push or pull commands.
With only point-to-point connections between the layers, which is ‘traditionally’ the case, we’d have to transfer all data from the MES and the PLCs up to the ERP before we can access it for analysis. With the Unified Namespace, we have a mechanism that allows data to be collected from all layers at the same time. The data from the ERP, the MES and the PLCs are all in there.
The data is stored in a hierarchical model, resembling the structure of the factory. Through the interface, applications can traverse the hierarchy and get data from the exact point they’re interested in. In this hierarchy, the whole business is represented, from the enterprise level down to the sensors and actuators. This makes it possible to connect everything in analysis and improvement activities.
The right data at the right time
To get this to work, we just have to put the Unified Namespace in between the traditional stack and the Industry 4.0 applications that use the data. However, we may also want to implement more real-time applications. 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 also addressed in the Unified Namespace architecture: getting the right data in at the right time. The Unified Namespace doesn’t store the state of data at any given point in time but actual data collected over time, with full history. We only have to define what data needs to be collected. After that, during operation, every time a data item is created or the value of an item changes, it’s stored in the Unified Namespace, including the time stamp of the change. In other words, the Unified Namespace stores all changes to data, which are called events.
This gives factory operators and managers a full overview of everything that’s going on — or just the subset relevant to them. At the same time, the Unified Namespace contains all data about the business, representing not only the current state but also every previous state. With these two things in place, we have real-time insight into whatever is relevant for someone in the organization and we can replay or analyze parts of what happened in the past to find causes, effects and possible optimizations.
