The Unified Namespace — the remaining questions
Having built our Unified Namespace (UNS) on MQTT and Sparkplug B, we have the infrastructure in place to enable bidirectional communication between any node in our system. This applies to edge nodes as well as devices, and also to any connected MES or ERP system. In that sense, it should be possible to have a MES send instructions to an edge node or device to initiate an action. In return, the results could be sent back to the MES.
However, some issues prevent us from doing that. The first issue is the Sparkplug B specification showing a one-directional arrow from the Sparkplug B broker to the MES, implying that messages go from the broker to the MES, but the MES never sends anything back. Could this be a flaw? While many MES systems communicate directly with PLCs, Sparkplug B was designed to collect data from devices and send them to Scada or MES systems, not the other way around. In essence, the Unified Namespace and the enabling technology Sparkplug B are intended for collecting data to support a data-driven approach to manufacturing and manufacturing improvement.
That immediately brings us to the second and most important reason why a MES can’t be replaced by a Unified Namespace. MES systems are about much more than collecting and communicating data. They cover scheduling, production order management, visualization, more or less limited implementations of stock management, operator guidance in production, alarm handling and more. This goes far beyond data gathering and communication.
‘Inline’ command and control
With that out of the way, we could still reason that it should be possible to send instructions to edge nodes and devices from the MES, using the Unified Namespace. This would allow us to keep full track of the history of each order or instruction and their executions. What’s blocking us from doing that, apart from a one-way arrow, is that MES commands, and to a lesser extent results, are often complex data structures, at least in the systems I’ve seen the past nine years. While Sparkplug B does offer support for defining such complex datatypes, it’s not a good idea to use them for sending instructions and receiving results. PLCs are often unable to receive MQTT messages and handle them atomically, although those that can are starting to appear on the market.
Instead, in cases where PLCs send or receive such structures, they have to be written to PLC tags, one field at a time. This requires synchronization of the PLC and the MES, to make sure that while one party is writing these tags, the other doesn’t already read them. If that happened, the receiver would be dealing with incorrect or incomplete data. We would need to put in front of every PLC an edge node that can handle this for each of the individual message types, which is quite cumbersome to implement while not bringing many benefits. Just as easily, we could send a copy of the MES instructions (or results) to the Unified Namespace in parallel to the inline command and control messages.
Other opportunities
Apart from these technical ‘limitations,’ there are a lot of possible applications for the Unified Namespace, as well as interesting opportunities arising from using it. For example, a lot of manufacturers are making steps in digitalization and moving toward smarter manufacturing in a data-driven way. Collecting data from production is part of that, and implementing a Unified Namespace makes that very easy. Setting up the initial UNS structure for a specific organization is a one-time hurdle, after which in principle all data that can be gathered from the production lines and IT systems is centrally available, in real-time. We could then collect data for historical analysis by hooking up a historian that stores it in any type of database and we could set up dashboards that may be used to display information that wasn’t available before.
It may also help solve some things that are only partly technical. The amount of data collected may become very big, or the computation power needed to perform certain types of data analysis (eg through machine learning) may only be available at a cloud provider. Having a Unified Namespace doesn’t solve these issues, but it does make it easier to collect data and offload it to cloud storage and computation platforms.
Furthermore, it might provide a solution for an issue I’ve encountered a few times in the past years. Manufacturers don’t want to offload operational calculations (ie the tasks of a MES system) to the cloud, partly because they don’t want their operational data to be in someone else’s hands and partly because they fear a network outage, for example through a broken internet connection, will stop their production. One manufacturer we worked with put dedicated fiber connections in the ground between three sites to avoid being dependent on external network providers.
With the Unified Namespace, there’s no risk of production stopping because of a broken connection. There’s still the risk of data theft when pushing data to the cloud. However, all data in the UNS is only there for monitoring and analysis and only the historical data goes to the cloud.
Endless possibilities
The power of the Unified Namespace is that every single data item in a factory can be made available in the namespace and used by any client of that namespace. This makes it possible to build applications for monitoring, analysis, feedback and so on a lot faster and without having to write dedicated interfaces between individual systems. The number of applications that can be thought of is endless, from the already existing dashboards to optimizers that monitor and correct the behavior of individual machines, to full-blown digital twins that connect in real-time.
Walker Reynolds and his company introduced the concept of the Unified Namespace some years ago. They first used it in an automation project they had won for only 1.5 million dollars. With this bid, they had blown away their two main competitors, who had put in quotations of 35 and 50 million dollars for following the ‘traditional approach’ — making modifications to ERP, MES and PLC code and writing custom software.
This was the third in a series of three articles on Unified Namespace. A tool, not a goal in itself for smart industry solutions. We can help put the tool to work, if you want to know more, contact us at info@shinchoku.eu.
