What is UNS-O?
Technical definition
Operational Unified Namespace – the operational tier in a two-tier UNS (HubMind’s model). UNS-O is the facility’s real-time namespace at Purdue levels 2-3, assembled from sources already normalised at the machine boundary through interface contracts, via OPC UA or MQTT.
In brief
UNS-O is where seven machines with seven different OPC UA dialects become seven instances of one type – a namespace born normalised instead of cleaned afterwards.
The Challenge
Order seven machines and you get seven OPC UA servers with seven different information models: different tag names for the same thing, different units, different state machines. All protocol compliant – and mutually incomprehensible. Protocol compliance guarantees nothing about semantics. The classic UNS answer is to connect everything and contextualise in the middleware – but that only relocates the cleanup cost, and it returns with every new machine.
HubMind’s Methodology
In our two-tier model, UNS-O is built bottom-up from contracted sources: every machine and system connects through a machine interface data contract (level 1.5) defining identities, states, units and update rates – acceptance-tested before the machine is approved. The namespace is structured along the ISA-95 hierarchy with IEC 81346 as the identity backbone.
Domains are branches in the namespace – production, facility, energy – not separate architectures. An air handling unit is “machine number eight”: same contract logic, same type/instance pattern. Upwards, UNS-O is projected into UNS-E for aggregated, multidisciplinary sharing. The technology can be OPC UA, MQTT or both – the pattern is the same.
Warnings & Pitfalls
“Connect everything, clean up later”: A UNS built on unnormalised sources is a landfill with a good search function. Normalise at the source – through contracts.
Control through the namespace: UNS-O distributes data – control loops and safety functions stay below level 1.5, in the machine’s own control system.
One flat mega-namespace: Without tiers, the cloud can see the valve – unnecessary from both an architecture and an IEC 62443 perspective. The UNS-O/UNS-E boundary is a natural zone/conduit boundary.
💡Our Recommendation
Define the machine contract first: One canonical information model per machine type – before procurement.
Structure by ISA-95, identify by IEC 81346: The hierarchy gives the location, the reference designation gives the identity.
Treat domains as branches: Facility and energy go into the same namespace – not into silos of their own.
Acceptance-test every connection: No source enters UNS-O without a passed contract test.
FAQ
Is UNS-O the same as a regular UNS? UNS-O is the operational tier of a UNS split into two tiers. The difference from “one big UNS” is that UNS-O only contains contracted sources, and enterprise sharing happens through a governed projection (UNS-E) – not by letting everyone see everything.
OPC UA or MQTT? Both work. OPC UA gives stronger semantics close to the machines; MQTT gives simpler distribution. A common hybrid: OPC UA at the machine boundary, MQTT as the distribution hub.
Where is the line against SCADA? SCADA becomes a consumer and producer in UNS-O – not the gatekeeper everything must pass through. Existing SCADA systems connect through the same contract logic.
HubMind’s related pages:
UNS, UNS-E and Machine Interface Data Contract
ISA-95, IEC 81346, OPC UA, MQTT and Sparkplug B
Industry resources:
Seven machines, seven dialects – or one namespace?
HubMind helps asset owners build UNS-O from contracted sources – so the integration cost per new machine approaches zero.
Scope note: The UNS pattern is domain-agnostic. It applies across industry, buildings, energy, logistics, laboratories and other digitalised operations that need shared structure and governance for operational data.
« Back to Glossary Index