Manufacturing plants have spent decades connecting systems in a point-to-point fashion: SCADA to MES, MES to ERP, PLC to historian, historian to dashboard. Each new connection required custom code, a dedicated integration project, and a maintenance burden that grows quadratically with every added system. The unified namespace model, built on MQTT, replaces this integration mesh with a single central data hub where every system publishes data once and every consumer subscribes to exactly what it needs. Adding a new data consumer goes from a months-long integration project to a five-minute subscription configuration. To explore how a unified namespace would transform your plant data architecture, book a demo with our team.
Article · Legacy Systems and Data Silos
Unified Namespace with MQTT: Manufacturing Data Hub
Replace point-to-point integration mesh with a single event-driven data hub. Topic hierarchy design, publisher-subscriber architecture, and real-time data distribution for the connected factory.
SCADA
ERP
MQTT Broker
PLC
MES
Historian
Every system publishes once. Every consumer subscribes to what it needs.
Point-to-Point Mesh vs. Unified Namespace Hub
The fundamental difference between traditional integration and a unified namespace is the topology. Point-to-point creates a mesh where every system connects directly to every system it needs data from. A unified namespace creates a hub-and-spoke model where every system connects to exactly one broker, and data discovery happens through topic subscriptions rather than direct connections.
Point-to-Point Mesh
SCADA
MES
ERP
PLC
CMMS
Historian
6 systems = 15 custom integrations
Each integration requires custom code and mapping
Adding one system requires N new connections
Single change cascades across all dependent links
No standardized data model across connections
Unified Namespace Hub
SCADA
ERP
MQTT Broker
PLC
MES
Historian
6 systems + 1 broker = 6 connections
Every system uses one standard protocol: MQTT
Adding a consumer requires zero changes to publishers
Publisher changes are invisible to all subscribers
Standardized topic hierarchy enforces data structure
Topic Hierarchy Design: The Structure of a Unified Namespace
The topic hierarchy is the most critical design decision in a unified namespace deployment. It defines how data is organized, discovered, and secured. A well-designed hierarchy mirrors the physical plant structure so that any engineer can find any data point by navigating the topic tree the same way they would walk the plant floor. A poorly designed hierarchy creates confusion, duplication, and fragmentation that defeats the purpose of unification.
enterprise
site
/Springfield
area
/Assembly
line
/Line3
cell
/Robot1
status
temperature
vibration
cycle_count
cmd/start
Topic Hierarchy Design Rules
Mirror Physical Structure
Each level in the topic tree corresponds to a real physical or organizational boundary: enterprise, site, area, line, cell. Never invent abstract levels that do not map to something an operator can point to on the floor.
Use Lowercase and Underscores
All topic segments are lowercase with underscores separating words. No spaces, no camelCase, no special characters. This eliminates ambiguity and ensures consistent wildcard matching across all MQTT clients.
Separate State from Events from Commands
State data like temperature lives under the cell path. Events like alarms use an event segment. Commands like start/stop use a cmd segment. Mixing these in the same namespace creates security and routing confusion.
Leaf Nodes Are Data Points
The deepest level in the hierarchy is always a specific measurable or controllable data point. A topic path should resolve to exactly one value or one command, never a collection of undifferentiated data.
Publisher-Broker-Subscriber Architecture
The MQTT protocol implements a decoupled publisher-broker-subscriber model where data producers and data consumers never know about each other. The broker is the only component that has visibility into both sides. This decoupling is what makes the unified namespace scalable, because adding a new consumer never requires any change to the publisher.
Publishers
PLC Edge Gateways
Translate Modbus, EtherNet/IP, Profinet to MQTT and publish at 100ms-10s intervals depending on data criticality
SCADA Systems
Publish aggregated KPIs, alarm states, and calculated metrics that SCADA computes from raw field data
MES Applications
Publish order status, production counts, quality results, and labor events as they occur on the shop floor
Quality Systems
Publish inspection results, SPC calculations, and compliance events tied to specific batches and work centers
MQTT Broker
Topic routing and wildcard matching
TLS encryption and ACL enforcement
Session persistence and QoS levels
Last will and testament messages
Shared subscriptions for scaling
Message retained state for new subscribers
Subscribers
ERP System
Subscribes to enterprise/site/area/line/order status and material consumption topics for real-time cost and schedule updates
Dashboards
Subscribe to wildcard topics like enterprise/site/area/+/line/+/cell/+/status for real-time floor overview displays
Historian
Subscribes to all state data topics with QoS 1 to ensure no data points are lost for time-series storage and compliance records
Analytics Engine
Subscribes to specific high-frequency topics for predictive maintenance models, quality correlation, and energy optimization algorithms
Sparkplug B: The Payload Standard for Manufacturing
Raw MQTT messages carry opaque byte payloads. Without a payload standard, every publisher and subscriber must negotiate their own data format, which recreates the integration problem at the payload level. Sparkplug B is an open specification that defines a standardized payload structure for industrial data, ensuring that every MQTT message carries not just a value but the metadata required to interpret that value correctly.
Metrics Array
Value72.4
Quality192 (Good)
TimestampInherited from payload
Value4.21
Quality192 (Good)
TimestampInherited from payload
Machine Status
Int32 / Enum
Value1 (Running)
Quality192 (Good)
TimestampInherited from payload
Self-Describing
Every metric includes its name, datatype, and quality in the payload. Subscribers do not need external documentation to interpret the data.
Birth-Death Model
Publishers send a NBIRTH message with all metrics on connect and NDEATH on disconnect. Subscribers always know the full state of every device.
Bulk Metrics
Multiple metrics travel in a single MQTT message, reducing network overhead compared to one-topic-per-value approaches by 5-10x.
Alias Support
After the first message, metrics can be referenced by integer alias instead of string name, further reducing payload size for high-frequency data.
Data Distribution Layers: From Edge to Consumer
Data flows through the unified namespace in distinct layers, each with a specific role in the journey from physical sensor to analytics consumer. Understanding these layers is essential for sizing the broker, designing the network, and assigning responsibilities across IT and OT teams.
Layer 1
Edge / Field Layer
Sensors, actuators, and PLCs generate raw signals. Edge gateways convert native protocols to MQTT Sparkplug B and publish to the local broker. This layer operates on plant-floor networks with sub-second latency requirements.
PLCs, Sensors, I/O Blocks, VFDs, Edge Gateways
Layer 2
Site Broker Layer
Local MQTT Broker
The site-level MQTT broker receives all published data from edge gateways and local applications. It enforces topic-based ACLs, manages retained messages for state data, and provides the local subscribe endpoint for on-site consumers like SCADA and local historians.
Site MQTT Broker, Local Historian, SCADA, Local Dashboards
Layer 3
Bridge / Federation Layer
Inter-Site Bridge
For multi-site operations, site brokers are federated through MQTT bridge connections. Selected topics are forwarded from site brokers to a central enterprise broker. Topic prefixes are preserved so enterprise consumers can distinguish data origin by site name in the hierarchy.
MQTT Bridges, Enterprise Broker, Firewall Rules, VPN Tunnels
Layer 4
Enterprise Consumer Layer
Analytics and Planning
ERP, analytics platforms, and executive dashboards subscribe to the enterprise broker. These consumers operate on aggregated and derived data, not raw sensor values. Latency tolerance is measured in seconds to minutes, not milliseconds.
ERP, Analytics Engine, Executive Dashboards, Data Lake
Ready to Design Your Unified Namespace?
Our team will map your current system landscape, design a topic hierarchy that mirrors your plant structure, and build a deployment plan that connects your first data producers to the broker within weeks.
Migration Path: From Point-to-Point to Unified Namespace
Migrating to a unified namespace does not require a big-bang cutover. The most successful deployments follow an incremental path that adds the MQTT broker alongside existing integrations, migrates data producers one tier at a time, and decommissions legacy connections only after the new path is validated and stable.
Step 1
Deploy the Broker
Provision the site MQTT broker on-premise within the plant network DMZ. Configure TLS, authentication, and the initial topic namespace structure. At this stage, the broker is running but empty. No existing connections are changed.
Weeks 1-2
Step 2
Onboard Edge Publishers
Deploy edge gateways on the highest-value production lines. Configure them to publish Sparkplug B payloads to the broker in parallel with existing SCADA connections. Validate data fidelity by comparing broker data with SCADA data for two full production shifts.
Weeks 3-6
Step 3
Migrate First Consumer
Switch one data consumer, typically the historian or a dashboard, from its existing direct connection to subscribing to the broker. This is the moment of truth: if the broker data matches the legacy data, confidence in the architecture is established.
Weeks 7-8
Step 4
Expand and Decommission
Onboard remaining edge publishers and consumers in priority order. As each consumer migrates to the broker, the legacy point-to-point connection feeding that consumer is decommissioned. By the end of this phase, the broker is the sole data backbone for the site.
Weeks 9-16
Frequently Asked Questions
Does a unified namespace replace our existing SCADA, MES, and ERP systems?
No. The unified namespace does not replace any existing system. It is a data distribution layer that sits between your existing systems and provides a standardized way for them to share data. Your SCADA system continues to perform its real-time monitoring and control functions. Your MES continues to manage production execution. Your ERP continues to handle planning and costing. The unified namespace simply changes how these systems exchange data, replacing custom point-to-point integrations with a single publish-subscribe model. Existing systems become publishers, subscribers, or both, without any modification to their core functionality. To understand how UNS would layer onto your current stack,
book a consultation with our team.
Is MQTT secure enough for manufacturing floor data?
MQTT 5.0 provides enterprise-grade security when configured correctly. Transport Layer Security encrypts all data in transit between publishers, the broker, and subscribers. X.509 certificate-based authentication ensures that only authorized devices and applications can connect. Topic-based Access Control Lists restrict each client to publishing or subscribing only to the specific topic branches relevant to its role, so a PLC gateway cannot publish to ERP topics and a dashboard cannot publish command topics. The broker itself runs in the plant network DMZ with no direct internet exposure. This security model has been approved for use in pharmaceutical, food and beverage, and automotive manufacturing environments subject to IEC 62443 and NIST cybersecurity frameworks.
What happens when the MQTT broker goes down?
A production-grade MQTT deployment uses broker clustering for high availability. In a clustered configuration, two or more broker instances share the same data and client connections. If the primary broker fails, clients automatically reconnect to a standby broker within seconds, and the standby has full visibility into all retained messages and active subscriptions. For scenarios where even brief interruptions are unacceptable, edge gateways buffer data locally during broker outages and replay it when connectivity is restored, similar to the edge buffering pattern used in OPC UA deployments. The last will and testament feature in MQTT also ensures that if a publisher loses its connection, the broker automatically publishes a predefined death message so all subscribers know the data source is offline rather than just silent.
How does a unified namespace handle high-frequency sensor data without overwhelming the network?
Not all data needs to flow through the broker at raw sensor frequency. The edge gateway layer applies filtering, aggregation, and dead-banding before publishing to the broker. A temperature sensor generating 100 readings per second can be dead-banded to publish only when the value changes by more than 0.5 degrees, which typically reduces the publish rate to once every 5-30 seconds while preserving all meaningful state changes. Vibration data for predictive maintenance may need higher frequency and is often published as a compressed batch at one-second intervals rather than individual readings. The Sparkplug B bulk metric format further reduces network overhead by packing multiple data points into a single MQTT message. This tiered approach ensures that the broker carries only the data that consumers actually need, not the raw firehose from field devices.
Can we run a unified namespace across multiple manufacturing sites?
Yes, and this is where the unified namespace model delivers its highest value. Each site runs its own local MQTT broker within its plant network for low-latency local data distribution. Site brokers are then federated to a central enterprise broker through MQTT bridge connections. The topic hierarchy inherently supports multi-site operations because the site name is a segment in every topic path. When the enterprise broker receives data from multiple sites, consumers can subscribe to specific sites by name, aggregate across sites using wildcards, or filter by area or line regardless of which site it belongs to. This architecture eliminates the need for custom site-to-site integrations and provides a single pane of glass for portfolio-level analytics, cross-site benchmarking, and centralized compliance reporting. To plan your multi-site UNS rollout,
schedule a strategy session with our architects.
Stop Building Integrations. Start Building a Namespace.
Every point-to-point connection you maintain today is a liability that grows with every new system. The unified namespace model, built on MQTT and Sparkplug B, gives you a data architecture that scales by addition instead of multiplication. The broker technology is mature, the payload standard is open, and the design patterns are proven across hundreds of manufacturing sites.
