What is UNS-E?
Technical definition
Enterprise Unified Namespace – the enterprise tier in a two-tier UNS (HubMind’s model). UNS-E is a governed, schema-controlled 1:1 projection of UNS-O: aggregated and structured data for multidisciplinary sharing across production, facility, energy and business systems.
In brief
UNS-E holds the same objects as UNS-O – same identity, different purpose. Curated, aggregated and shareable across domain boundaries, without the cloud ever needing to see the valve.
The Challenge
The enterprise level wants answers – OEE, energy performance, availability – not ten thousand raw signals. When the business side connects directly to operational systems, two problems appear at once: consumers drown in unnormalised real-time data, and the OT environment is exposed to networks it should never see. The result is either shadow solutions (spreadsheet exports again) or a security architecture nobody dares to audit.
HubMind’s Methodology
UNS-E is built as a governed projection of UNS-O – not as a parallel structure. Every object keeps its identity 1:1 (through IEC 81346 reference designations), but the representation changes: aggregated instead of raw, schema-controlled instead of free-form, curated instead of complete. Publication is unidirectional by default and crosses a defined zone boundary per IEC 62443.
This is where the multidisciplinary value appears: production, facility and energy data share a namespace and an identity backbone – so an energy analysis can connect a compressor’s consumption to both the production order and the building’s operating mode. At the enterprise tier, event streaming (Kafka) and schema registries fit naturally – UNS-E is the pattern, not a specific protocol.
Warnings & Pitfalls
The parallel build: If UNS-E is modelled independently of UNS-O, you get two truths that diverge. UNS-E is earned from UNS-O – it is not built separately.
Identity without an owner: The 1:1 mapping between the tiers is master data and needs designated ownership – otherwise it drifts.
Schema-free sharing: Without data contracts at the enterprise tier, every consumer inherits the interpretation work – and the reports stop agreeing again.
💡Our Recommendation
Project – do not build in parallel: Every UNS-E object must derive 1:1 from UNS-O.
Data contracts at the boundary: Schema, units, quality flags and update rate – defined and version-controlled.
Unidirectional by default: Writes downwards are exceptions with their own risk assessment – not the norm.
Think multidisciplinary from day one: Reserve room for facility and energy in the structure even if you start with production.
FAQ
Is UNS-E just a data platform? No. A data lake stores; UNS-E shares current state and events with identity and structure preserved. They complement each other – UNS-E happily feeds the platform.
Must UNS-E be MQTT? No. The pattern is protocol-neutral: MQTT, Kafka or a combination. The choice follows the consumers’ needs for history, replay and scaling.
What separates UNS-E from an integration platform? The platform is technology; UNS-E is structure and governance: namespace, identities, contracts and ownership. A platform can implement UNS-E – it does not replace it.
HubMind’s related pages:
UNS, UNS-O and Machine Interface Data Contract
IEC 81346, Master data ownership and Single Source of Truth
Industry resources:
RealEstateCore and Brick Schema – semantics for the facility domain
Do you want to share facility data across domains – without exposing OT?
HubMind helps you design UNS-E as a governed projection – with identity, contracts and ownership in place.
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