Unified namespace (UNS) has the potential to solve many problems for industry. Where digital transformations have been slow and siloed, UNS holds power in scalability and plug-and-play integration with an overall simplified architecture. With a centralized data hub and a single source of truth across all machines and processes, UNS can untangle rigid infrastructure and help solve the long-standing challenges around data and system interoperability.
No more digital thread: UNS provides centralized communication
“UNS is the single source of truth for data events in a business,” says Jacob Clodfelter, solutions architect at Flexware Innovation. “UNS is not a technology but an architecture. UNS is primarily a single data backplane for all data transactions in a business.”
UNS solves a problem with traditional industrial architecture and the “digital thread” philosophy, Clodfelter says. The digital thread in industrial automation is the idea of creating a continuous flow of digital data across the entire manufacturing process lifecycle, from design to production to service. Sounds great, right? But it doesn’t always translate so well in industry, where systems can be dynamic, parallel and even messy. Those dynamic environments aren’t really a thread or a single, linear flow of data either, and oversimplification can lead to rigid architectures. Industrial data moves in all directions, not along one thread, and the digital-thread concept also struggles with real-time and event-driven data, which is core to optimizing machine data system-wide.
“By having a single intermediary data backplane, the number of integrations can be reduced exponentially in a system,” Clodfelter says. “Specifically, the math is (n-1)2 connections via digital thread to n connections with unified namespace.”
Traditional architectures chasing the digital thread need a direct integration for each application to connect to another one. “This means that any system will have integrations between all applications directly. By instead using UNS, applications communicate via a centralized service, meaning all applications only have one connection, to the central service,” Clodfelter says. This is incredibly powerful, he says, for reducing integration cost and labor in industrial automation.
“It also has advantages in security and network efficiency. As the number of connected devices increases rapidly, these architectures will be critical to efficiency, scalability, cost and reliability,” Clodfelter says.
With UNS, data no longer travels from point to point. “A centralized data architecture acts as a central hub,” says Luciano Tarabocchia, presales solutions consultant at Mitsubishi Electric Iconics Digital Solutions. More traditional supervisory control and data acquisition (SCADA), manufacturing execution system (MES), enterprise resource planning (ERP) or other industrial architectures are often siloed or organized by hierarchy.
“When looking at a small system, the traditional setting may work fine, but, once you start growing the digital ecosystem throughout the organization, there are going to be many different owners of assets and the data that comes from them,” says Tarabocchia. “A UNS architecture enables these different owners to publish their data models to a centralized space and access the various other data models that are published from other areas of the ecosystem to unify all layers of the business.” A UNS architecture essentially allows SCADA or MES assets to access real-time data from each other “without the concerns of duplication and inconsistencies,” he adds.
Why is UNS often used with Sparkplug and MQTT?
Sparkplug and message queuing telemetry transport (MQTT) are often used to build a UNS, with MQTT serving as the communication protocol and Sparkplug as the format or language that carries the payload specification or data. If MQTT is the delivery truck, the payload or data is the box of goods, and the payload specification is the packing list and labeling, explaining what’s in the box, how much is in there and what to do with it. UNS doesn’t have to be used with MQTT and Sparkplug, but the three are well-suited to work together.
“If you use UNS on top of plain MQTT, you will bump into what I call the fundamental problem of MQTT, which is: what’s great about MQTT is that you can publish anything, any data on any topic. And then what’s bad about MQTT is that you can publish any data on any topic,” says Frédéric Desbiens, senior manager of embedded and IoT at Eclipse Foundation. “You have no idea in advance what the payroll format will be or what the topic structure would be.”
Instead, the way in which Sparkplug is structured means that the topic structure is not fixed, and it’s customizable up to a point yet still predictable, Desbiens says. “Sparkplug provides a generic payload format that can express any arbitrary set of metrics. Sparkplug clients in a system or Sparkplug applications or edge nodes will be able to encode and decode that format, and then it’s up to them to figure out what the metrics mean in a specific industrial context.” In general, this provides flexibility.
“You publish not only data, but metadata about what’s in there and what units of measurement are used, or any arbitrary metadata that you need in order to contextualize that data,” Desbiens says. “That’s really the important notion about Sparkplug. This is not just about publishing metrics, but publishing metrics in a structured way and with all the information that you need to make sense of that data.”
Sparkplug also adds other benefits on top of the namespace, like stateful session management, so you don’t need to poll devices to know whether they are online. Sparkplug issues a birth certificate when a device connects to the system and a death certificate when it disconnects. “You save a lot of useless polling in your architecture because of that,” he adds.
Eclipse Foundation was created in 2004 and serves as a vendor-neutral nonprofit steward of open-source projects. “We are a code-first organization,” Desbiens says. “What we do at the Eclipse Foundation is really to provide this vendor-neutral level playing field where everyone can come and essentially collaborate around what are essentially commodities, and then this gives them resources and the time that they need in order to compete meaningfully in the commercial space,” Desbiens says.
Eclipse Foundation supports more than 425 different open-source projects around software collaboration and innovation, and Sparkplug is included among those projects. “We own the Sparkplug logo on behalf of the community to ensure that no one runs with it and closes it from an open-source perspective,” Desbiens says.
You may see Sparkplug or Sparkplug B, and, as Desbiens explains, the “B” refers to the current payload format. The original Sparkplug version had a short-lived A version, but it was updated a few months later. “It was modified to version B because there were weaknesses identified by end users,” Desbiens says, and most use Sparkplug and Sparkplug B interchangeably now. He also notes that, eventually, Sparkplug will be upgraded to version C, which members are working on now.
Will a formal UNS standard or guidelines solve the industry challenges for adoption?
The MQTT/Sparkplug combo is popular but not the only way to deploy UNS. Randy Armstrong, director of IT operations at OPC Foundation, also sees UNS and OPC UA as complementary. “OPC UA has been built on the foundation of interoperability via a common information model. UNS provides a mechanism to centralize access to information but leaves the details of the information model to the implementor,” Armstrong says. “We see UNS as an excellent way to distribute OT data published by OPC UA sources and described with OPC UA information models.”
OPC UA provides a payload format but also a framework for providing complete context for the information in the payload, says Armstrong. “OPC UA also supports multiple protocols, such as HTTP or Kafka and is not tied to MQTT,” he adds.
Armstrong says OPC UA will be an essential component of UNS architectures, specifically for common, reuseable information models. “OPC UA publishers will provide OT data in payloads that are well-understood by off-the-shell products and can be combined with references to various industry-wide standard information models to provide proper context for the data,” Armstrong says.
Industry knowledge and authority for UNS are still challenges to its adoption, Desbiens says. It’s a bit of a “soft concept,” he adds. “The main challenge is agreeing on what it means and what it means to implement it properly. Maybe there would be a need for a more formal way to describe it, and the Eclipse Foundation would be interested in having a very lightweight short spec that would define the UNS architecture,” Desbiens says.
The other challenge that Desbiens points is that UNS can be implemented with a varied set of technologies and approaches. “If we don’t agree on a clear definition, then of course there’s the risk of fragmentation,” he adds.
Get your subscription to Control Design’s daily newsletter.
As UNS continues to evolve toward a “dynamic digital backbone,” then edge and cloud-based AI designs will continuously consume and update data streams across an organization, Tarabocchia says. “I could possibly see more standards coming into play around metadata and real-time streaming capabilities that evolve the landscape even further,” he adds.
With advances in AI, Clodfelter thinks that a standard might not even be necessary. “Unfortunately, because of the wild-west nature of OT, I’m less convinced that a standard will materialize. I think it’s much more likely that AI will infer data models and standards natively, such that standardization is no longer necessary,” he adds.
The future of UNS
UNS will play a big role in the next wave of generative AI deployment, Tarabocchia says. “UNS architecture is scalable, real-time and vendor-agnostic and enables what is known across the industry as data democratization,“ he says. Without the back-end architecture that UNS provides, connecting to systems across an organization in the way that generative AI needs would be difficult. Without clear data access and organization, AI models would likely fail from inconsistent training or data quality concerns, Tarabocchia says.
Clodfelter attended Proveit, a conference focused on UNS, produced by 4.0 Solutions, and what he saw there around the application of artificial intelligence, he called “groundbreaking.”
“I see that agentic systems will be able to deploy UNS automatically at scale without the involvement of integration engineers,” Clodfelter says. “I think you’ll also see model inference running at the edge on Linux soft PLCs. I imagine that agentic systems will also configure and deploy these edge models that run inference directly on the PLC/soft PLC.” He is seeing some interesting work being done under UNS with automatic data modeling and semantic contextualization using AI and graph databases, which will guide the next steps in UNS deployment.
5 UNS Dos and Don’ts for machine builders and system integrators
1. Don’t wait to start UNS.
Clodfelter says to start UNS sooner, rather than later. There’s no standard or requirements for getting started. “While it is true that hierarchy and data modeling are important, they are neither a standard nor required to start using UNS. I would recommend that everyone implement a UNS, even if they don’t have a perfect hierarchy or data model. It will change over time,” he adds.
2. Do standardize and align.
Tarabocchia has the following advice about how to set up UNS:
- Don’t treat UNS as a data lake or as a messaging layer.
- Do standardize naming conventions, tags and topic hierarchies throughout the organization.
- When retrofitting into legacy designs, be sure to align to the overall enterprise architecture.
3. Don’t count out OPC UA.
Armstrong says don’t think of OPC UA in the context of modern architectures like UNS as mutually exclusive. “OPC UA provides a common information modeling framework that can be used to provide data with context information plus a mechanism for serializing it for exchange via different protocols such as MQTT, Kafka or HTTPS/representational state transfer (REST),” he says.
4. Do design with edge gateways and documented data schema.
“Design equipment with edge gateways in mind that have the ability to support MQTT and OPC UA connectivity. Machines should be modeled semantically and come with a documented data schema to have a good starting point for publishing to a UNS from Day One,” Tarabocchia adds.
5. Don’t forget protocol translation hardware or software.
“What is wonderful is that there are a number of products that help any number of machines communicate via UNS,” says Clodfelter. “These technologies are in the form of protocol translation hardware or software. The best technologies I currently know of are Litmus and Kepware. There are many others like Anybus that can be rack-mounted. The basic idea is that you try to get to MQTT as the protocol as soon after your layer 0/1 as possible. This doesn’t require that you rip and replace hardware,” he adds.
