Today I would like to reflect a little on the concept of Unified Namespace (UNS). Is it just another buzzword or is there something more behind it – something worth considering?
First, let's talk about what UNS supporters say about it. Google will find several blogs and presentations, e.g. on hivemq.com, emqx.com, clarify.io or inductiveautomation.com. On Youtube, the most famous UNS evangelist is probably Walker Reynolds on his 4.0 Solutions channel.
So – what are the basic theses of the UNS concept and what problem does it solve?
- Communication between individual layers in the classic automation "pyramid" requires configuring point-to-point communications at individual levels (PLC, SCADA, MES, ERP, Cloud). This is best expressed in the figure:
2. Adding new data sources and publishing them to the upper layers of the pyramid requires the collaboration of experts at all lower levels of the pyramid (some of whom may be external contractors), making the process slow, expensive, and unreliable.
3. Therefore, it is necessary to move from point-to-point communication to a qualitatively higher communication, represented by the MQTT protocol and the hub-spoke architecture (here it becomes clearer why MQTT server manufacturers such as hivemq.com and emqx.com are among the UNS proponents). The center of the architecture is the MQTT server, to which are connected both information producers (PLC, RTU and other devices from the process level), as well as systems from higher levels of the automation pyramid (SCADA, MES, ERP), which are consumers of this information, but can also be producers (e.g. of aggregated data).
4. The great advantage of the hub-spoke architecture is that to connect another system (or replace one SCADA system with another, for example), it is enough to create a connection between it and the central hub (MQTT broker). This central hub is perceived as the "single source of truth" for all data and information in the enterprise.
5. In addition, the data must be structured – organized (hierarchically). For example, emqx.com lists four types of UNS:
a. Functional Namespace – organization of devices and data points by function or purpose. Devices and data points are grouped based on the specific task they perform, rather than their physical location or network.
b. Informative Namespace – organization of devices and data points by information context – for example, in a manufacturing plant, devices and data points related to temperature are grouped in one namespace, points related to pressure in another.
c. Definitional Namespace – organization of devices and data points by their definitions and characteristics (type, size, function) – for example, in a manufacturing plant, devices and data points related to motors are in one namespace, points related to sensors in a separate namespace.
d. Ad-Hoc Namespace – a temporary or informal organization of devices and data points, used when a formal namespace has not yet been established, or when devices and data points need to be quickly grouped together for a specific purpose (e.g., in the event of a device failure, an ad-hoc namespace will be created for all devices and data points related to the failed device for rapid diagnosis and resolution of the problem).
Walker Reynolds uses a hierarchical structure according to the ISA-95 Part 2 standard (Enterprise/Site/Area/Line/Cell) - this directly copies the physical location of devices within a manufacturing plant.
So, this is an interesting and attractive concept. Who wouldn't want to have easily accessible data that can be simply connected to a SCADA or MES system, or sent to the cloud for analysis and archiving? And given the openness and simplicity of the MQTT protocol, it is certainly better than proprietary protocols ... or complicated OPC UA. Moreover, once the data is on the MQTT server, it is available to any of the clients - on the other hand, if the PLC also implements an OPC UA server, the performance limits of the PLC (and possibly licensing) can significantly limit the number of connected OPC UA clients.
And now the objections:
- Most manufacturing companies have a history of several years or decades. They use devices from different manufacturers, with different communication protocols. It is unrealistic to expect that each of these devices will support MQTT. A workaround could be to deploy “edge devices” that would communicate with the PLC using proprietary protocols and publish data via the MQTT protocol. Deploying these devices would of course require additional costs (in addition, they must not interfere with existing communication between the PLC and local SCADA systems).
- When we talk about local SCADA systems: in manufacturing companies, small SCADA systems are often part of the technology. Their supplier is the supplier of the technology and the PLC. They are often the only interface through which it is possible to obtain information from the PLC, because that is how the supplier designed it and interference with the communication is not allowed and would cause the loss of warranty. For example, if we implement an EMS (Energy Management System), it is necessary to agree with individual suppliers how they will publish energy data for the EMS.
- When we implement an EMS or a large SCADA/MES system in a manufacturing company, we often create our own "hub", into which we bring dozens of different communications (PLC, RTU, local SCADA systems, data from electricity meters and others). Such systems then serve (usually for decades) and over the years new technological units are connected to them. If our "hub" has sufficient communication capabilities and can publish data in a way that is compatible with other systems (MES, ERP) - e.g. via OPC server, OPC UA server, communication protocols such as Modbus Server, IEC-104 server, ICCP/TASE-2 server, via REST API, ODBC interface, or using plugins (MS Excel) or can copy them to databases for ERP systems using data pumps - then the demand for an independent MQTT hub, which would also serve everyone - but only on the condition that they support the MQTT protocol, is significantly reduced!
Additionally, if we use Ipesoft D2000 technology to implement both SCADA and MES systems, it is possible to connect them using a transparent gateway and add additional data points to the MES system by simple XML export from SCADA and import to the MES system - and the Sysmirror module can be used to compare configurations, XML export and import. - In my experience, higher levels of the automation pyramid are often not interested in raw data from the lowest levels (e.g. data on consumption of individual electricity meters), but in aggregated data generated by a higher level (e.g. total consumption of technological units/production halls/the entire enterprise, which is aggregated by the EMS system). In such a case, it is also possible to use a hub-spoke architecture implemented by an MQTT server, but the thesis about a large number of parties interested in the data will probably not apply.
- Different approaches to organizing data points within the UNS (functional, informative, definitive, ad-hoc or hierarchically organized) can cause additional complications when integrating new devices into an existing UNS.
- Finally, in addition to existing systems, it is necessary to manage a new system – MQTT server. Configure access rights for individual clients, maintain it (update software). If it becomes an important communication center, it will be necessary to deal with its outages (planned and unplanned) by implementing redundancy. In short, nothing is free.
Don't get me wrong – I acknowledge that UNS is an interesting concept and in specific cases also useful and beneficial. On the other hand, there are a large number of communication protocols and solutions – from proprietary to open protocols like OPC UA. Will UNS and MQTT find their place under the sun? Definitely yes – our systems already communicate with MQTT servers at several customers (e.g. PowerShaper battery storage).
As for MQTT support from manufacturers, there are already MQTT libraries for Simatic S7-1500 as well as for PLCs from Rockwell, WAGO, Beckhoff and others.
That is why I see the UNS concept as an interesting alternative to the classic automation pyramid. Personally, I would welcome the expansion of MQTT - since this protocol is already implemented in Ipesoft D2000, we support work with both text and JSON payloads, we even support the MQTT Sparkplug-B standard, which defines a binary payload. But will serial protocols like Modbus or proprietary protocols of PLC manufacturers be pushed out in the foreseeable future? I can hardly imagine that. As the 2011 xkcd.com webcomic shows, standards (which protocols are among) die hard and slowly.
But lest we be accused that our control systems built on the Ipesoft D2000 real-time application server are being anti-UNS: a few days ago, our implementation of the MQTT communication protocol added the option for the D2000 to function as an "Edge Node" client (and possibly several subordinate "Devices"/"Sensors"), i.e. to be a producer of data processed by "Host Application" clients.
And one final note: Walker Reynolds calls UNS “ the single source of truth”, because all data and information in the enterprise is collected in one place, hierarchically organized and available to all consumers who need it. However, these are only the current values of individual datapoints and it is implicitly assumed that consumers support the MQTT protocol. I wonder what one would call the situation when all (relevant) data is available to their users in our MES systems – not only current values but also history (some applications have over 20 years of primary and aggregated data in archive and depository databases), organized also visually in diagrams, with graphs, tables and technology drawings? With support for historical mode of schemes allowing data playback over time, with the ability to export data to multiple formats, current and historical data available not only for MS Excel but also for various other products and systems using the above-mentioned interfaces (OPC, OPC UA, REST API, ODBC and others) ... no, I don't want to invent new terminology, just to point out that our users often already receive all the necessary data with a visual presentation and a broader technical context.
As for creating a hierarchy - using so-called Logical Groups, it is possible to create any number of hierarchies in Ipesoft D2000 and include D2000 objects in them (even within a hierarchy, an object can be included in multiple places, if necessary).
April 29, 2025, Ing. Peter Humaj, www.ipesoft.com
