Industry 4.0
Product News
AI
Why Unified Namespace scales poorly
The Unified Namespace (UNS) is often presented as a natural and easy-to-implement way to achieve unified semantics for machine and sensor data.
UNS realizes this model with a single event-driven backbone, typically built on MQTT and Sparkplug B, connecting factory devices (OT) to enterprise applications (IT) using a topic structure with a specific naming convention and ISA-95 style hierarchy.
For a single plant or a pilot deployment, with a limited number of machines and applications, this proposition holds up in most cases.
Context - The thesis of this document is that UNS introduces limitations, constraints, and over time real complexity and costs when used at enterprise scale, and these costs grow continuously as the OT/IT implementation expands.
This document does not claim that the basic concept of UNS is wrong in principle. Rather, it claims that the underlying mechanism (MQTT topics and naming conventions, optionally structured via Sparkplug B) on which most "UNS" implementations are based, carries a complexity, an operational model, and a cost that scales unfavorably precisely when it matters most — that is, when the number of sites, machines, legacy systems, business units, and organizational boundaries increases.
The root cause: application semantics pushed down to the transport layer
The real contribution of ISA-95 (Parts 1, 2, and 4) is a transport-independent semantic model: a hierarchy (Enterprise → Site → Area → Line → Cell) and a set of object relationships (Equipment, Material, Process Segment) designed to retain their meaning regardless of how they are conveyed.
(img- 1) The ISA-95 functional hierarchy (Purdue Model): from the physical process to enterprise planning, with the typical time scales of each level.
Part 5 of ISA-95 (B2MML) defines a reference XML serialization, but nothing in the standard privileges a specific transport protocol.
Most UNS implementations do not preserve this separation between "model" and "communication." Naming and hierarchy are expressed as MQTT topics [2]. Sparkplug B is considered for greater rigor, with a fixed and constrained topic string, with a limited number of elements [1].
This is clearly a "downgrade", from a semantic model to an "address" within a specific transport [7]. It works at limited scale, but its cost and constraints grow with the size of the implementation and the organization.
Five categories of UNS cost and how they grow
1. Governance cost
MQTT enforces no schema: topic strings are conventions, not specifications, so consistency depends entirely on documentation discipline and provides no structural guarantee [2]. Analyses of enterprise UNS rollouts are clear about where this fails: UNS is insufficient to guarantee data portability between enterprise applications, precisely because of limited governance, the absence of standardized data contracts, and "shared" ownership between IT (which "governs" infrastructure and therefore MQTT brokers) and OT (which "governs" machines and therefore their data) [4]. A pilot at a single site, perhaps involving a single department, involves one team and limited naming requirements. An enterprise with twenty sites has twenty different histories and no structural mechanism forcing them to converge. The reconciliation cost is combinatorial, not linear, with respect to the number of sites.
2. MQTT-based UNS" requires additional integrations.
A rigorous analysis of what a UNS actually requires identifies five necessary capabilities: a hierarchical namespace, real-time publish/subscribe, persistence and replay, request/reply, and secure multi-site federation — and states clearly that a simple standard MQTT broker covers only the first two solidly. Secure multi-site federation in particular is identified as the capability that determines whether a UNS remains a single-plant project or becomes a true enterprise capability, and is explicitly noted as the element most commonly deferred until it becomes costly. In other words, the simple, inexpensive parts of "UNS" are exactly those that do not scale at the enterprise level, while the parts that do scale at the enterprise level are not available out of the box and are particularly costly to implement [5].
3. Multiplication of broker topology and infrastructure costs.
Enterprise deployments typically require local brokers at each site, selectively bridged to a central enterprise broker — an approach that in turn requires a platform to manage republication between tiers, explicitly introduced as an additional operational burden. Adding high-availability broker clustering, OT/DMZ network segmentation for each site, and cross-site authentication and encryption, infrastructure spend scales with the number of sites, independently of any data modeling work. The honestly reported symptom when this is not budgeted for: topic collisions, inconsistent site models, and fragile broker bridges [6].
4. Organizational cost grows with the number of teams and legacy systems involved.
Enterprise UNS governance requires cross-functional ownership, because neither IT nor OT can define and manage it alone: OT understands machines and processes, IT brings network, identity, and security expertise, and business owners define which data must flow and why [3]. This coordination cost is roughly proportional to the number of business units, plants, and legacy systems involved — exactly where larger organizations are structurally disadvantaged compared to a single-site pilot.
5. Structural constraints of Sparkplug.
The Sparkplug topic space has a fixed and limited number of elements, and developer guidelines already warn that the available space for mapping the full ISA-95 hierarchy a specific company requires can run out. The documented workaround (the "Parris method") compresses multiple hierarchy levels into a single string field using a custom delimiter. It works, but every subscriber must then parse that string and republish it into an expanded topic structure to recover the hierarchy; without a standardized delimiter convention, every application would otherwise have to be hard-coded to the specific hierarchy exposed by the broker it connects to. A shallow deployment barely notices this. An enterprise with deep hierarchies (Enterprise → Business Unit → Site → Area → Line → Cell → Equipment → Variable) exhausts the native topic elements sooner, requires the workaround sooner, and pays the parsing and republication cost at every additional level and for every additional consumer application.
Why we are talking about UNS costs, not ISA-95 costs
None of the five cost categories above is required by ISA-95 itself. ISA-95 does not mandate a broker, a federation topology, a payload schema specification, or a governance model. It defines exclusively a semantic hierarchy and a set of object relationships, leaving the communication mechanism and implementation completely open. The cost categories described above are a consequence of the specific choice of MQTT and Sparkplug B as the mechanism for expressing that hierarchy, not a consequence of pursuing ISA-95 alignment as such.
A large enterprise adopting "UNS to be ISA-95 aligned" is therefore subscribing to a technology- and protocol-specific infrastructure and governance program that ISA-95 has never required. The cost curve of that program becomes steeper exactly as enterprise size, number of sites, and hierarchy depth increase. This is the opposite of what should happen with a standard whose stated purpose is enterprise-level integration: the mechanism chosen to implement it should not become more costly, more fragile, and more dependent on workarounds as the enterprise it is meant to serve grows.
The alternative: protocol-independent semantics
A straightforward reading of ISA-95 suggests a different architecture: keep the naming and semantic model in a protocol-independent object layer (a registry or schema with stable identifiers and relationships, possibly governed by a single business function, e.g., OT) and treat any specific OT/IT transport (MQTT, OPC-UA PubSub, Kafka, REST, or whatever comes next) as one of the possible projections of that model, not as its source of truth. With this architecture, adding a new site does not multiply governance requirements; changing or adding an application with a different interface does not require rebuilding the naming layer; and hierarchy depth is not constrained by a single protocol's limitations, because the semantic model is expressed in other elements.
How avoids these costs
Alleantia Core's approach to device and variable identity is a practical instance of the alternative described above, and it is worth explaining concretely, because it maps directly onto the five cost categories rather than merely asserting a different philosophy.
Alleantia Core establishes identity once, in a protocol-independent configuration layer, not within the addressing scheme of a transport. Each connected device carries a unique Device ID, each gateway/machine instance carries a globally unique Machine ID, and each variable carries a Var ID defined by the machine driver. Crucially, these identifiers, together with free-text descriptions and device aliases, are configurable, so that the customer's ISA-95-style hierarchy (Enterprise, Site, Area, Line, Cell) can be embedded directly in device names, aliases, and gateway naming at configuration time, rather than being reconstructed after the fact from a topic string.
Because this identity resides in the data model itself, the same fully-contextualized payload (carrying Var ID, Device ID, Machine ID, and any configured hierarchy metadata) is delivered identically across every API exposed by Core: MQTT, REST, SQL/database access, Kafka, Azure Event Hub, and others. Semantic identity travels with the data, not with the transport.
Mapped against the five cost categories above, this changes the economics at scale, not just the philosophy:
- Governance burden does not worsen with the number of sites.
The hierarchy is configured once per device/gateway at connection time, not reconstructed retroactively from topic conventions that diverge across sites. Adding a twenty-first site does not require reconciling twenty different naming histories, it requires configuring identifiers consistently with the first twenty.
- No topic element ceiling.
Because hierarchy and identity reside in structured payload fields rather than in concatenated string segments within a transport-specific topic path, there is no Sparkplug-style limit on the number of representable hierarchy levels, and no delimiter-based workaround is needed as depth increases.
- No federation required to preserve identity across sites.
Because each gateway already carries a globally unique Machine ID and each device a unique Device ID, moving or aggregating data across brokers, sites, or transports does not risk overlaps or collisions the way linking independently-governed local topic trees does.
- Adding or changing transport does not require rebuilding naming.
Whether the customer's architecture requires MQTT, Kafka, Azure Event Hub, direct SQL access, or a REST integration, device identity and semantics remain unchanged. This is the practical, direct difference between treating a topic string as the semantic model, and treating it as one of the possible projections of a model that exists independently.
In short: where UNS implementations typically pay a recurring cost to keep naming consistent within a transport-bound convention, Alleantia Core's model avoids this cost structurally — by keeping the convention outside the transport from the outset.
Souces
1. HiveMQ — Implementing Unified Namespace (UNS) With MQTT Sparkplug
2. FlowFuse — MQTT vs OPC UA: Which One Should You Use?
3. IIoT World — How to Standardize a Unified Namespace
