Unified Namespace - how to build one?

In my previous article I introduced briefly the concept of the Unified Namespace (UNS). In this article, I’m going to dive deeper into a possible technical implementation. At the end of this article, I will also have a look at if and how unified can be used for other things than just monitoring the current and past state of a manufacturing system. What about controlling it - can UNS replace MES?

The technical building blocks of the UNS

In the previous article, I explained that the Unified Namespace is a logical representation of the production organisation, to which devices and applications can connect. This is shown in figure 1. This setup allows applications to obtain information about he current state of the production system at any point in time, and use that information to inform operators, perform calculations or store it for later use and analysis.

In order to make this work, we need a few technical building blocks. First of a all, we need a network. Now we could say that the network is already there, otherwise our factory would not be running, but we need to mention it because it is a key element of the Unified Namespace architecture. The network typically a TCP/IP network connects all the parts of the architecture so we can really build our UNS

Figure 1: Unified Namespace in Context

Second, since we are interested in what is going on in the production line, we want to connect the machines, sensors and other devies that make up the production line. These have to be connected to the network, and because they are at the outmost edge of it, the UNS architecture calls them End of Network Devices (EoD), or End of Network Nodes. There is a subtle difference between these two terms though. An End of Network Device refers to a device that is network enabled and connects to the network directly. An End of Network Node, which is more common in most factories at the moment groups together a number of devices that are not network enabled themselves, and makes their information available on the network.

As an example: a simple temperature sensor may have an analog voltage connection, or a digital serial connection that can be used to connect it to the IO of a PLC, but is not network enable in itself. If the PLC is network enabled, it could become an Edge of Network Node, grouping a number of such devices.

Similarly, if a PLC is network enabled but does not support the protocols we use for our UNS, we could put a something else in place that connects to one or more PLCs and make that into an Edge of Network (EoN) node that we groups data access to those PLCs.

This explanation introduce a third component of our architecture: the protocol. Since we need to establish communications in order to exchange the information we are interested in, we need a protocol for the exchange. That protocol will have to allow us to send messages from EoN to the applications.

Since we cannot know up front which application is interested in, it makes sense to set up a mechanism in which applications can subscribe to the information they are interested in, and push that data towards them when its available. This is a mechanism called publish-subscribed (or pub-sub) , an it requires another component, a message broker.

The message broker will offer the possibility for EoN to publish their messages in a designated place, and allow clients to subscribe to them.

This leads to the core architecture shown in figure 2.

Figure 2: Basic UNS Architecture

A possible technology stack
Unified Namespace has been around for quite a while, and companies and people in the IIoT and Industry 4.0 domain have been working with it for over 10 years now. There is a common technology stack that appeared over this period that is used more and more often, which I’ll describe here. However, it is only one possible stack, there are many options, also because the UNS is something specific for a factory or a group factories run by the same enterprise, it’s not something that is exported to the outside world. In a video on YouTube that was published in March, Walker Reynolds, who came up with the UNS architecture, explained that he implemented it for the first time already in 2005, using spreadsheets and EDI (Electronic Data Interchange) as the core technology.

The technology most commonly used at this time consists of the following technologies.

For the network I already established that the TCP/IP network is the basis. Since every company nowadays has an internal network based on this, that’s a logical choice. Also because a lot of usable technology stack have been build on TCP/IP and internet technology already.

For the communication protocol, the de facto standard nowadays is MQTT ()Message Queue Telemetry Transport), a light weight communications protocol. This protocol, despite it’s original name, is used for much more than telemetry - it is also the underlying communications protocol for Facebook Messenger for example. MQTT is a protocol that is based on the publish-subscribe mechanism, which is exactly what we need for the UNS architecture, and it has only a very minimal communications overhead in terms of metadata.

MQTT is also base on a broker architecture, which allows clients to publish data in so called topics, to which other clients can subscribed. So, MQTT basically brings two components at the same time: the broker (with its pub-sub mechanism) and the protocol for communications.

Because MQTT is lightweight, it has limited network overhead. It also allows EoNs to only communicate changes in data. In traditional PLC applications, clients would halve to poll data structures on the PLC to look for changes, while with MQTT based EoNs, they can simply subscribe to the data they need and only receive a message when that data changes (a mechanism called Report by Exception).

The protocol itself does not include security features, but because it is based on the TCP/IP stack, it can be combined with TLS to implement secure transfers.

Because it is so lightweight, MQTT also misses a few important elements. This can be resolve by adding SparkPlug B, an extension to MQTT developed specifically to resolve these shortcomings in an industrial context.. The standard was originally developed by the company Cirrus-Link, but the standards was transferred to the Eclipse Foundation, which ow maintains it as an open standard.

SparkPlug B builds on top of MQTT version 3.1.1 and adds among others the following elements 

• State awareness
• Topic naming standard
• Payload format
• Templates

These were added because they are needed to use MQTT in the context of UNS.

First of all, MQTT does not provide any information about whether or not clients or sources of messages (our EoNs) are connected or even alive. If you want to monitor the current status of a system, that is important information. For this purpose, SparkPlug enabled brokers work with so called birth and death certificates, which are communicated to the broker by the EoN whenever they start up or break their connection. This allows clients to monitor also the presences of EoNs, and thus enables state awareness.

Then, MQTT allows almost complete freedom in naming topics, which can be useful, but it also makes it hard to build a unified namespace. Sparkplug.B defines a naming convention that makes this easier, and also makes sure that clients can distinguish easily between Sparkplug and regular MQTT topics. Where an MQTT topic can have any structure, a SparkPlug B topic always has the following fixed format: spBv1.0/group_id/message_type/edge_node_id/[device_id]

Here, spBv1.0 indicates that it is a Sparkplug B topic. Group_id indicates a group of devices - here we can use the names we need in our UNS hierarchy. Message_type is the type of message. I’m not going to explain all of them in this article, but the most commonly used ones are NDATA and DDATA for node data and device data respectively, and NCMD and DCMD for node command and device command. These are used to send data from an EoN to its clients, or send commands from an application to an EoN.

Because MQTT not only allows full freedom in topic naming, but also in payload (i.e. message data) structuring, SparkPlug defines a fixed format for this payload, consisting of a timestamp, the data itself (including its type) and a sequence number.

It also allows definition of custom payloads, for which an EoN can register a so called template, when it starts up. A template defines custom datatypes but is still required to follow the Sparkplug messaging type.

One thing is important to keep in mind: although Sparkplug B is based on MQTT, it does not require a Sparkplug B compliant broker. Any MQTT 3.1.1 or later broker can work, because Sparkplug B is build on top of MQTT. However, Sparkplug B requires message payload to be encoded using Google Protocol Buffers (Google Protobuf), which is not automatically decoded by a standard MQTT Broker. So, when using a normal MQTT Broker, clients will have to decode the message they receive themselves.

Connecting applications
With the components in place, let’s look at a simple example of how this could work. Let’s say that we have a production line that includes a cutting machine. For the cutting machine, we want to monitor the temperature and the speed of the cutting wheel. Neither the thermometer nor the motor are network enabled, so we put an EoN in front of them in the form of a PLC.

Then we let the EoN publish the two values every 5 seconds to the broker, and we have a dashboard application to monitor the status.

Figure 3 and 4 show what that looks like, including the structure of the message (in text format in this case) and the name of the topic on which the information is published.

The figure also shows that the machine is part of a production line in our UNS hierarchy, which in turn is part of our factory. The hierarchy is ‘encoded’ in the gorup_id, because also SparkPlug does not fully support the hierarchical naming required by the UNS. This might be addressed in a future specification, but what is shown here is the most common solution for this issue.

Figure 3: The example setup

Figure 4: Topic and message

Note that I haven’t mentioned any specific products in this description, there are many implementations of MQTT and Sparkplug B available, both commercial and Open Source. Mentioning them would not add much to this explanation.

What SCADA, MES and ERP in this story?
So far I talked mainly about the devices, the broker and applications that consume the data they generate. In our stack however we also hav SCADA, MES and ERP as traditional building blocks of the factory IT structure. How do these fit in with what I described here?

What is being built with UNS on MQTT and Sparkplug B originally comes from the SCADA world, where people wanted a bit more flexibility in connecting devices to the SCADA world, and making data more easily available to the data consuming applications. However, MES and ERP fit in here as well - in two different ways.

First of all, ERP and MES determine what is going on in the factory. They control the manufacturing or works orders, the bill of materials and the produciton schedule. The orders and the schedule, when they are executed in the factory, are in a certain way the source of the data we’ve been talking about. However, for full analysis and monitoring of what happens in a factory and why things happen, we need to combine the orders and schedule with the data they result from. So, it makes sense for ERP and MES to not only send their instructions to the relevant parts of the production system, but also to the UNS, so that real time monitoring can combine cause and effect whenever something happens. This way operators can monitor in real time not only how a production line is behaving, but also which order it is running - all from one single source of truth.

This brings up two additional issue to address: are we going to send instructions to two places, and how are we going to keep a history of what happened?

Let’s start with the second one. In most production systems, in order to implement future improvements, there will be a need to analyse historical data. By having all data published to the unified namespace, it is available in real-time, data gets published every time it changes - including a time stamp. If we save this data to a database, which is typically what an application called a ‘historian’ does, we can later analyse the full time lines afterwards and even feed them to machine learning algorithms for that. Having everything published in the UNS, which is also easily extended when we add new data times, this becomes an easy task.

The first is slightly more complex. An ERP and MES (or one of the two) may send information to the production system in order to get production going, or send instructions to warehouse management to prevent the production line from running out of materials. This is typically point to point communication, which does not go through the UNS system. Sending it also to the UNS might mean that we put a double load on the network for these things. On the other hand, we could also make use of the command options in Sparkplug B and let the relevant EoNs 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.

This however can only work if we can guarantee that the messages arrive at the EoN on time, which is a bit harder to guarantee in a messaging system than with a MES system that connects to a PLC directly. This is one of the items in the final article of this series, which is due next month.