Unified Namespace: the data layer beneath AI and digital twins

On 28 August 2026, IIoT World published an article by Paul Viorel arguing that the common cause of many failed AI and digitalization projects is the data layer, and that the answer is the Unified Namespace (UNS). It is not news in the strict sense but an opinion piece with a strong vendor presence: many figures are second-hand citations or vendor-reported data. The topic, however, is a practical one for anyone running plants.

The problem: data that doesn't arrive in a usable form

The article cites three numbers to describe the state of projects:

• 57% of manufacturing executives say poor data quality is holding back the development of AI use cases (MIT Technology Review);
• 85% of digital transformation projects fail to deliver ROI because of integration problems (a claim attributed to the CEO of ServiceNow);
• more than 70% of projects remain stuck in the pilot phase (McKinsey).

These figures are quoted, not independently verified, but the qualitative point is familiar: projects stall on data plumbing long before they stall on models.

The N-squared problem

In the traditional ISA-95-inspired architecture, systems (PLC, SCADA, MES, ERP, CMMS, quality, energy) are connected point to point. With 50 systems you can reach up to 2,450 connections, each with its own protocol mapping and maintenance burden.

The UNS proposes a hub-and-spoke model built on an MQTT broker. Each system publishes into a hierarchical namespace, for example Enterprise/Site/Area/Line/Asset, and the others consume from it. With 50 systems, connections become 50. In addition, data keeps its context, such as units of measure and asset hierarchy, from source to consumer, and new sensors can be discovered without manual configuration.

From up to 2,450 point-to-point connections to 50 connections into a single namespace.

What the UNS is not

The article makes clear that the UNS does not replace MES or ERP: it sits alongside them as a communication layer. It also complements a historian or data lake, which continue to hold training and trend data. Nor is it a protocol: it is an architectural pattern. The most common stack is MQTT with Sparkplug B, though OPC UA aggregation is also used.

Results and timelines: read with caution

The reported results come largely from vendors:

• HighByte: 448% ROI over three years and integration 4 times faster (vendor-stated data);
• Anexee: 40–70% less integration effort;
• Dallas-Fort Worth airport (HiveMQ case): energy consumption -20%, workforce efficiency +25%, water losses from 25% to 10%, communication intervals from 6 hours to 15 minutes. It is, however, an infrastructure case, not a manufacturing one.

On timelines, Anexee, whose implementations are mainly in heavy industry in India, indicates 8–14 weeks for the first plant, 4–8 weeks for each subsequent one, and 6–18 months for a federated multi-site UNS. Hierarchical asset modeling absorbs 40–60% of the effort.

What to do in practice

For production and IT/OT managers, the most useful takeaway is the order of work. Before an AI project or an OEE analysis, it makes sense to:

• define the asset hierarchy and naming convention, which is the most demanding part;
• contextualize data at the source, with units, state, and line and area membership;
• identify which systems, including MES and line-monitoring platforms, will act as both publisher and consumer;
• start with a single plant or line and replicate the model;
• treat vendor ROI and timelines as hypotheses to validate in a pilot.

The UNS does not by itself solve data quality or governance, but it makes explicit the modeling work that point-to-point projects tend to postpone. That is where, according to the article, it is decided whether AI and digital twins will move beyond the pilot phase.