Unified Namespace
for Industrial Operations
Replace scattered tag lists and brittle point-to-point integrations with a shared operational model. Proxus Unified Namespace gives teams, applications, and AI the same real-time view of sites, assets, equipment, and metrics through a governed UNS software layer.
The Reality: Spaghetti Integration The Solution: Unified Namespace
Watch how UNS transforms point-to-point chaos into a real-time data fabric.
What is a Unified Namespace?
A Unified Namespace (UNS) is a single, well-structured topic hierarchy where all operational data lives: events, metrics, states, alarms. Instead of every system talking directly to every other system, each one:
- Publishes what it knows to the UNS once
- Subscribes to what it needs from the UNS when required
This eliminates point-to-point integrations, breaks data silos, and gives IT and OT teams a shared, real-time view of the factory. In Proxus, the UNS is not a slide in a presentation – it is the core runtime architecture behind the industrial data platform. See how Proxus implements UNS.
From Point-to-Point Sprawl to a Shared Operational Model
- Publish once, consume everywhereDevices, SCADA, MES, ERP and analytics all connect to the same hub.
- Security by designEdge Gateways initiate outbound connections; no inbound PLC ports.
- Real-time, event-drivenMQTT and the message-bus layer support governed live streams; final delivery behavior depends on persistence, acknowledgements, capacity, and target-system health.
UNS software and UNS architecture in one layer
A Unified Namespace is an architecture pattern. To run it in production, teams also need software for protocol ingestion, topic governance, permissions, buffering, dashboards, history, and integration. Proxus combines those requirements so UNS moves from a whiteboard model into a live operating layer.
- UNS architecture for ISA-95-aligned topic design across sites, lines, assets, and metrics.
- UNS software for live topic browsing, permissions, routing, storage, dashboards, and AI access.
- Industrial connectivity through edge gateways, OPC UA, Modbus, MQTT, Siemens S7, and other field protocols.
Where UNS fits
Structured Data, Not Chaos
Proxus supports the ISA-95 standard hierarchy. This ensures that any application, AI model, or human knows exactly where to find data without asking the original integrator.
- Self-aware Data Topics
- Sparkplug B Payload Compression
- Automatic Birth/Death Certificates
How Proxus Implements UNS
Proxus is built from the ground up around the UNS concept. Instead of bolting MQTT on top of a legacy platform, Proxus uses an actor-based architecture where every major component speaks the same language. Review key benefits or the UNS docs.
- Edge GatewaysStateless Gateways collect data from PLCs and fieldbuses, normalise tags and publish them into the UNS. If connectivity drops, the internal backbone buffers every event.
- Central UNS BrokerA designed MQTT and topic-governance layer provides a shared operational model for plants, sites, and applications.
- Central Data Pipeline & StorageOn the central server, the data pipeline consumes UNS streams and persists telemetry to PostgreSQL and ClickHouse without impacting the broker.
- UNS Tree & DashboardsThe UNS Tree Monitor and real-time dashboards read from a high-performance in-memory cache, not directly from PLCs, ensuring real-time UI without extra load on the plant network.
End-to-End Data Flow
Devices & PLCs
Raw telemetry generation from industrial assets
Edge Gateway
Protocol translation, buffering, and secure transmission
UNS (MQTT)
Central real-time broker for all operational topics
Rules & Functions
Stream processing, alerts, and anomaly detection
DB & Analytics
Long-term storage in ClickHouse and PostgreSQL
Dashboards & AI
Real-time visualizations and integrations
All of this is configured from a single place: the Proxus central server. Gateways remain stateless and can be redeployed or replaced without losing their role in the UNS.
Why UNS with Proxus?
Whether you are modernizing a single line or rolling out across multiple plants, a Unified Namespace dramatically reduces integration cost and accelerates digital projects.
1. Real-Time Visibility
Operators, maintenance and management all see the same live data set: OEE, alarms, energy metrics and more – without building yet another custom dashboard per system.
2. Lower Integration Cost
New applications (MES, CMMS, AI platforms) subscribe to existing topics instead of requiring new point-to-point connectors. Projects move from months to weeks.
3. Future-Proof Data Model
A clean, ISA-95-aligned topic structure means AI, digital twins and analytics teams can explore data without constantly touching production systems.
Ready to make UNS your shared operational model?
Learn how Proxus implements UNS in real factories and how you can roll it out step by step – from a single line to a multi-site architecture.
Technical and Commercial Evaluation
Unified Namespace Software evaluation guide
Operational problem it addresses
Point-to-point integrations copy raw tags into separate systems and allow names, units, and asset meaning to drift. UNS software establishes a governed topic and context model that publishers and consumers can share without treating the broker itself as a complete governance strategy.
Data sources it connects
- PLC and edge telemetry published through industrial connectors
- OPC UA, MQTT, Sparkplug B, and supported operational sources
- MES, quality, maintenance, and reference data used to enrich asset context
How the data is processed
- 1.Define the asset hierarchy, naming rules, ownership, and topic contract.
- 2.Map source-specific signals to contextualized operational entities.
- 3.Publish governed live state and events through the configured messaging layer.
- 4.Version and monitor the model as sites, assets, and consuming applications change.
Edge and outage behavior
Local publishers can buffer supported outbound data when central messaging is unavailable. Replay and ordering depend on configured persistence, capacity, acknowledgement behavior, publisher state, and outage duration. Retained MQTT state is not a substitute for a historian or full event history.
Systems that consume the data
- SCADA
- Dashboards
- MES
- ERP
- CMMS
- Analytics
- Data platforms
- AI consumers
Security and deployment boundary
A UNS crosses OT and IT trust zones, so broker identity, topic authorization, certificates, publisher ownership, consumer permissions, remote access, and data classification must be designed explicitly. A shared namespace does not remove network segmentation or safety boundaries.
Technical validation and next step
When it is a good fit
- Several publishers and consumers need a stable operational contract.
- Asset naming and context must remain consistent across sites.
- Teams are prepared to own topic governance and schema lifecycle.
When it is not a good fit
- A broker is being added without a governed asset and topic model.
- The project expects retained messages to replace all historical storage.
- Safety control or deterministic interlocking would depend on enterprise messaging.
Evaluation FAQ
Is a Unified Namespace just an MQTT broker?
No. The broker transports messages. A usable UNS also requires a governed asset hierarchy, topic contract, context model, identity and authorization rules, ownership, and lifecycle management.
Does UNS replace a historian?
Not by itself. Retained state and message persistence serve different purposes from long-term time-series storage, audit history, retention policies, and analytical queries.
Does every application need to publish directly to the UNS?
No. Publishing and consumption boundaries should follow ownership, security zones, data quality, and operational risk. Gateways or integration services can mediate systems that should not connect directly.