The Unified Namespace – how to build one?

The Unified Namespace (UNS) is a logical representation of the production organization, to which devices and applications can connect. This setup allows applications to obtain information about the current state of the manufacturing system at any point in time. The information can be employed to keep operators posted or perform calculations, or it can be stored for later use or analysis.

To make this work, we need a few technical building blocks. First of all, we need a network. We could say that the network is already there; otherwise, our factory wouldn’t be running. Still, we need to mention it because it’s a key element of the UNS architecture. Typically, it’s a TCP/IP network connecting all the architecture parts.

Second, since we’re interested in what’s going on in the production line, we want to include the machines, sensors and other devices that make up the line. These have to be connected to the network, and because they’re at the outmost edge of it, the UNS architecture either calls them Edge of Network (EON) devices or EON nodes. There’s a subtle difference between the two. An EON device is network enabled and connects to the network directly. An EON node, more common in most factories, groups together a number of devices that aren’t network enabled themselves and makes their information available on the network.

A simple temperature sensor, for example, may have an analog voltage connection or a digital serial connection that can be used to connect it to the I/O of a PLC, but it isn’t usually network enabled in itself. If the PLC is network enabled, it could become an EON node, grouping a number of such devices. Similarly, if a PLC is network enabled but doesn’t support the protocols we use for our UNS, we could put something in place that connects to one or more PLCs and make them into an EON node that provides access to the data of those PLCs.

This introduces a third component of our architecture: the protocol. As we need to establish communications to exchange the information we’re interested in, we need a protocol. That protocol will have to allow us to send messages from EON nodes to the applications.

Since we can’t know upfront which application is interested in what data, it makes sense to set up a mechanism for applications to subscribe to the information they want to receive, and push that data to them when it becomes available. This is called publish-subscribe (or pub-sub), and it requires a fourth component: the message broker. The message broker will offer the possibility for EON nodes to publish their messages in a designated place and allow clients to subscribe to them.

A possible technology stack

The Unified Namespace has been around for quite a while, and companies and people in the Industrial Internet of Things and Industry 4.0 domains have been working with it for over ten years now. Over this period, many alternative technology stacks have developed, partly because the UNS is specific for a factory or a group of factories run by the same enterprise and not something that’s exported to the outside world. Here, we’ll look at a common stack that’s being used more and more often.

For the network, we’ve already established the TCP/IP network as the basis. It’s the de facto standard for internal networks, making it the logical choice. Also, a lot of useful technology stacks have been built on TCP/IP and internet technology already.

For information exchange, the de facto standard nowadays is Message Queue Telemetry Transport (MQTT). Despite its name, this lightweight communication protocol is used for much more than telemetry – it also underlies Facebook Messenger, for example. MQTT combines the publish-subscribe mechanism, which is exactly what we need for the UNS architecture, with a broker, which allows clients to publish data in so-called topics, to which other clients can subscribe. Thus, it brings us two components at the same time.

Because MQTT is lightweight, it has limited network overhead. It also makes it possible to only communicate changes in data. In traditional PLC applications, clients would have to poll data structures on the PLC to look for changes, while with MQTT-based EON nodes, they can simply subscribe to the data they need and they only receive a message when that data changes. The protocol itself doesn’t include security features, but as it’s based on TCP/IP, it can be combined with TLS to implement secure transfers.

Being so lightweight, MQTT also lacks a few other important elements. This gap is filled by the Sparkplug B extension. Originally developed by the company Cirrus-Link, it was transferred to the Eclipse Foundation, which now maintains it as an open standard. Sparkplug B extends MQTT version 3.1.1 with elements like state awareness, topic naming standard, payload format and templates, which are crucial for easy integration with a UNS in an industrial context.

For example, MQTT doesn’t provide any information about whether or not clients or message sources (our EON nodes) are connected or even alive. If we want to monitor the current status of a system, that’s important information. A Sparkplug-enabled broker retrieves so-called birth and death certificates from EON nodes whenever they start up or break their connection. This allows clients to monitor the presence of these nodes, thus enabling state awareness.

Furthermore, MQTT allows almost complete freedom in naming topics, which can be useful but also makes it hard to build a Unified Namespace. Sparkplug B defines a naming convention that makes this easier and also ensures that clients can distinguish easily between Sparkplug and regular MQTT topics. While an MQTT topic can have any structure, a Sparkplug B topic always has a fixed format.

MQTT not only allows full freedom in topic naming but also in payload (ie message data) structuring. For this, Sparkplug defines a fixed format as well, consisting of a time stamp, the data itself (including its type) and a sequence number. The extension also allows the definition of custom payloads, for which an EON node can register a so-called template when it starts up. Templates define custom datatypes but are still required to follow the Sparkplug messaging type.

Sparkplug B doesn’t require a Sparkplug B-compliant broker. Because the extension is built on top of MQTT, any MQTT 3.1.1 or later broker can work. Sparkplug B does require the message payload to be encoded using Google Protocol Buffers (Google Protobuf), which isn’t automatically decoded by a standard MQTT broker. In that case, clients will have to decode the messages they receive themselves.

What about SCADA, MES and ERP?

Next to the devices, the broker relaying their data and the applications consuming it, the stack also contains the traditional building blocks of the factory IT structure: SCADA, MES and ERP. What’s being built with a UNS on MQTT and Sparkplug B originally comes from the SCADA world. There, people wanted a bit more flexibility in connecting devices and making the data more easily available to the data-consuming applications.

The MES and ERP determine what’s going on in the factory. They control the manufacturing or work orders, the bill of materials and the production schedule. To be able to fully analyze and monitor what happens in a factory and why, we need to combine the orders and schedule with the data they’re based on. It therefore makes sense for the MES and ERP to not only send their instructions to the relevant parts of the production system but also to the UNS, so cause and effect can be related whenever something happens. This way, operators can monitor in real-time how a production line is behaving and which order it’s running – all from a single source of truth.

In most production systems, to implement future improvements, there will be a need to analyze historical data. Using the Unified Namespace, all data gets published every time it changes – including time stamps – so everything is available in real-time. By saving the data to a database, which is typically what an application called a “historian” does, we can easily analyze the full timelines afterward and even feed them to machine learning algorithms.

The MES and ERP (or one of the two) may send information to the production system to get the production going or instructions to warehouse management to prevent the production line from running out of materials. This is typically point-to-point communication, which doesn’t go through the UNS system. Sending it also to the UNS might mean putting a double load on the network. Alternatively, we could use the command options in Sparkplug B and let the relevant EON nodes subscribe to commands. This would make the UNS fully part of both production management (MES and ERP) and monitoring (SCADA), while at the same time having all data available centrally. For this to work, the messages have to arrive at the EON node on time, which is a bit harder to guarantee in a messaging system than with a MES system that connects to a PLC directly – a challenge we’ll address in the third and final article of this series.