Core concept
What is a Unified Namespace (UNS)?
A Unified Namespace (UNS) is a shared, continuously updated view of operational information. It lets people, applications, and services discover current data through predictable names while retaining the meaning needed to use that data correctly.
Why use a UNS?
Replace repeated point-to-point work with a shared contract
Industrial data often begins in PLCs, SCADA systems, databases, MES applications, ERP systems, and specialist services. Without a shared structure, every new consumer needs another mapping to every source. Those connections become difficult to discover, govern, and change safely.
A UNS gives producers and consumers an agreed place to exchange operational state and events. A producer publishes once to a known contract; authorized consumers can subscribe without the producer knowing every application that will use the data. This decoupling helps OT and IT teams add consumers without rebuilding the source integration each time.
How it works
Publish once, discover by contract, consume many times
A practical Unified Namespace separates four responsibilities. Source adapters or applications publish operational information; a transport distributes it; consumers subscribe to the parts they need; and governance keeps names, payloads, access, and meaning understandable as the system grows.
PLCs, edge services, databases, and applications publish data through stable contracts.
MQTT is commonly used to route messages from publishers to interested subscribers.
Operations, analytics, storage, APIs, and automation consume the contracts they understand.
Schema, identity, ownership, authorization, and lifecycle rules keep the namespace usable.
MQTT and UNS
Is a Unified Namespace just an MQTT broker?
No. MQTT is a strong transport for a UNS, but the broker alone does not define the shared operational model. The MQTT 5.0 standard defines Topic Names, Topic Filters, publish and subscribe behavior, quality of service, retained messages, and sessions. A forward slash can introduce hierarchy into a topic name, which makes operational data easy to route and browse.
MQTT does not decide what a topic means, whether two payloads use compatible units, who owns a contract, or whether a renamed path still refers to the same physical object. Those are modeling and governance decisions around the transport. A useful UNS combines reliable distribution with conventions, data contracts, authorization, and enough context for consumers to interpret the messages consistently.
The article Is MQTT the same as a Unified Namespace? follows one machine through new consumers and a changed line to show where transport ends and the shared operational contract begins.
UNS and ISA-95
ISA-95 can inform the structure without defining every path
ISA-95, also published as IEC 62264, provides models and terminology for integrating manufacturing control and enterprise functions. Its equipment hierarchy and functional levels give industrial teams a familiar way to discuss sites, areas, work centers, equipment, manufacturing operations, and business systems.
A UNS can use that vocabulary where it matches the real domain, but it does not have to encode every ISA-95 level into every topic. A smaller operation may need only a few useful levels; another domain may need a different vocabulary entirely. The important part is that publishers and consumers agree on an understandable contract rather than copying a hierarchy that does not fit.
Path vs identity
A namespace path tells you where to look, not everything an object is
Consider a mold publishing temperature beneath factory-a/line-1/mold-47/temperature. If the same mold moves to another factory, its useful operational path may become factory-b/line-3/mold-47/temperature. The new topic correctly describes its current placement, but treating the topic as the mold's only identity can split its maintenance, quality, and production history into two apparent assets.
A stable entity identifier lets the path change while the object remains the same. Placement records where it belongs now and where it belonged before. External identifiers can also change without silently creating a new governed object.
Context model
Keep placement, identity, history, and relationships distinct
A browsable placement such as site, line, asset, and measurement.
A stable identifier that survives a rename, move, or integration change.
Timestamped values, events, and changes retained for later use.
Typed links that explain lifecycle, provenance, and operational dependencies.
Relationships preserve lineage across change
Operational questions often cross more than one topic: which material came from a batch, which process produced it, where an asset was installed at the time, or which source supplied a measurement. Typed relationships make those connections explicit; validity periods preserve the answer that was true at a particular time.
Governed context also improves retrieval and analysis
Analytics and AI systems work with less ambiguity when measurements, documents, and events resolve to stable entities with explicit meaning and provenance. That context does not make generated answers automatically correct. Source quality, access control, evidence, and human review remain necessary.
Existing systems
Does a UNS replace PLC, SCADA, MES, ERP, or a historian?
Usually not. A UNS provides a shared exchange and context layer between systems that retain their specialist responsibilities. Control remains close to equipment, transactional workflows stay in the applications that own them, and historical stores remain responsible for durable query workloads.
Own deterministic control, supervision, alarms, and safe local operation.
Own operational workflows, records, scheduling, and domain-specific decisions.
Own planning, logistics, finance, and other business transactions.
Distribute messages or persist data for the access patterns they support.
OpenHub approach
How UNS OpenHub approaches a Unified Namespace
UNS OpenHub combines a self-hosted Unified Namespace Runtime with open TypeScript and Python SDKs. The Runtime keeps stable entity identity separate from namespace placement, records typed and time-aware relationships, and makes governed context available to applications and operators.
The generic core is domain-neutral. Domain packs add reusable object types, attributes, units, and relationship rules without hard-coding one industry into the platform. The complete Runtime remains in private preview while the bootstrap, SDKs, and selected components are available publicly.
Start small
Begin with one useful producer-to-consumer path
Choose a small set of assets, measurements, or events that one real consumer already needs. Agree on their names, payloads, units, ownership, and stable identity. Publish the current state, connect one consumer, and verify that another team can discover and interpret the contract without inspecting the source code. Expand from that understandable slice instead of attempting to model every system at once.
Primary references: OASIS MQTT Version 5.0 and the ISA-95 series overview.