Unified Namespace (UNS) for manufacturing 2027: MQTT, Sparkplug B, ISA-95 flattening — IIoT architecture guide

Écrit par Équipe TEEPTRAK

May 20, 2026

lire

TL;DR — Unified Namespace for manufacturing in 60 words
Unified Namespace (UNS) uses an MQTT broker as central hub for all plant data: OT (PLC, SCADA, OEE), IT (ERP, MES, CRM), and engineering (CAD, PLM). Sparkplug B provides standardized payload (birth/death certificates, metrics, state). ISA-95 topic hierarchy (Enterprise/Site/Area/Line/Cell). Replaces point-to-point integration spaghetti. Brokers: HiveMQ, EMQX, Mosquitto, AWS IoT Core.

For manufacturing IIoT architects in 2027, the Unified Namespace (UNS) has emerged as the dominant architectural pattern for industrial data integration. Popularized by Walker Reynolds (4.0 Solutions) and adopted by organizations like Litmus, HighByte, HiveMQ, and Cirrus Link, UNS fundamentally changes how manufacturing data flows: from point-to-point spaghetti (every system connected to every other system via custom integrations) to hub-and-spoke (every system publishes and subscribes to a central MQTT broker with standardized topic hierarchy). This guide details UNS architecture, MQTT broker selection, Sparkplug B payload specification, ISA-95 topic hierarchy design, report-by-exception patterns, and integration with OEE platforms. If you’re designing or modernizing your manufacturing data architecture in 2027, UNS is likely the right foundation.

The problem UNS solves: integration spaghetti

Traditional manufacturing data integration is point-to-point:

  • PLC → SCADA (OPC DA/UA)
  • SCADA → Historian (proprietary protocol)
  • Historian → MES (SQL queries or API)
  • MES → ERP (batch interface, flat files, EDI)
  • OEE platform → PLC (separate OPC UA connection)
  • Predictive maintenance → PLC (yet another connection)
  • Quality system → MES (yet another API)
  • Energy management → meters (yet another protocol)

For N systems, point-to-point creates N×(N-1)/2 connections. At 10 systems = 45 connections. At 20 systems = 190 connections. Each connection: custom integration code, different protocols, different data formats, different maintenance burden. Adding one new system requires connecting to ALL existing systems.

UNS reduces this to N connections (one per system to the central broker). Adding a new system = one connection to the broker, instant access to all data from all other systems. Data producers publish; data consumers subscribe. No bilateral integration. The broker is the single source of truth for current state of the entire plant.

UNS architecture: components

MQTT broker — the central hub

MQTT (Message Queuing Telemetry Transport, ISO/IEC 20922) is the transport protocol. The MQTT broker is the central message router:

Broker Type Strengths Best for
HiveMQ Commercial (Java) Enterprise features (clustering, RBAC, audit trail, Kubernetes), Sparkplug B aware, extensions API, 24/7 support Enterprise manufacturing, multi-site, IEC 62443 compliance
EMQX Commercial + OSS (Erlang/OTP) High performance (100M connections), rule engine, data integration hooks, MQTT 5.0 native High-volume IIoT, cloud-native, Asian market strong
Eclipse Mosquitto Open-source (C) Lightweight, simple, widely deployed, reference implementation Single-site, edge gateway, development/testing, cost-sensitive
AWS IoT Core Managed (AWS) Serverless, auto-scaling, AWS integration (Lambda, S3, SiteWise, SageMaker) AWS-centric cloud UNS, multi-site aggregation
Azure Event Grid MQTT Managed (Azure) Azure-native, Event Grid integration, Functions triggers Azure-centric cloud UNS
Cirrus Link Chariot Commercial Sparkplug B inventors, SCADA integration (Ignition), Chariot MQTT Server Ignition SCADA deployments, Sparkplug-centric
VerneMQ Open-source (Erlang) Clustering, plugin architecture, high concurrency Self-hosted, clustered edge deployments

Sparkplug B — the payload specification

Sparkplug B (Eclipse Foundation, now Sparkplug 3.0) standardizes MQTT payload format for industrial applications:

  • Birth certificates (NBIRTH, DBIRTH): when a node or device comes online, it publishes a birth certificate listing all metrics it provides (name, datatype, value, timestamp) — consumers instantly discover what data is available
  • Death certificates (NDEATH, DDEATH): when a node/device disconnects (or broker detects via Last Will and Testament), death certificate is published — consumers know data is stale
  • Data messages (NDATA, DDATA): report-by-exception — only changed metrics are published (not full dataset every cycle), reducing bandwidth by 80-95%
  • Command messages (NCMD, DCMD): write commands from consumers back to producers (e.g., recipe download, parameter change)
  • State message (STATE): SCADA/application online/offline status

Sparkplug B uses Protocol Buffers (protobuf) for efficient binary serialization — 3-10× smaller than JSON for same data.

Topic hierarchy — ISA-95 alignment

UNS topic structure follows ISA-95 hierarchy:

spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}

Mapped to ISA-95:

spBv1.0/{Enterprise}/{NBIRTH|NDATA|...}/{Site/Area/Line}/{Machine}

Practical example for a multi-site manufacturing group:

spBv1.0/TeepTrak/NDATA/Paris-Plant1/Area-Assembly/Line-3/Machine-CNC-07
  └── Metrics: OEE=0.72, State="Execute", CycleCount=1547, ...

spBv1.0/TeepTrak/NDATA/Chicago-Plant2/Area-Packaging/Line-1/Machine-Filler-02
  └── Metrics: OEE=0.85, State="Held", StopReason="Material Waiting", ...

spBv1.0/TeepTrak/NDATA/Shenzhen-Plant3/Area-SMT/Line-2/Machine-PickPlace-01
  └── Metrics: OEE=0.68, State="Execute", CycleTime=4.2s, ...

Any subscriber (OEE dashboard, digital twin, MES, energy system, maintenance system) can subscribe to any level: `spBv1.0/TeepTrak/#` (all data enterprise-wide), `spBv1.0/TeepTrak/NDATA/Paris-Plant1/#` (all data from Paris plant), `spBv1.0/TeepTrak/NDATA/+/+/Line-3/#` (all Line 3 data across all plants).

ISA-95 hierarchy flattening

Traditional ISA-95 mandates strict hierarchical data flow: L0 (process) → L1 (sensing) → L2 (control) → L3 (MES) → L4 (ERP). Data travels up layer by layer. UNS flattens this hierarchy: any layer can publish directly to the broker, any layer can subscribe directly. The hierarchy is preserved in the topic structure (organizational taxonomy) but not in the data flow (communication path).

Benefits of flattening:

  • Latency reduction: OEE platform subscribes directly to machine data — no hop through SCADA → Historian → MES
  • Flexibility: new analytics application subscribes to existing topics — zero integration effort
  • Resilience: if MES goes down, OEE platform still receives machine data (independent path via broker)
  • Context enrichment: ERP publishes work order context to broker → machine data is enriched with order/product information automatically (both available on broker)

Download the white paper

Enter your email address to receive our White Paper

Report-by-exception: bandwidth efficiency

Sparkplug B report-by-exception means: a device publishes a metric only when its value changes (or on periodic heartbeat). Compared to polling:

Approach Messages for 1000 metrics at 1 Hz, 10% change rate Bandwidth
Polling (request all every second) 1000 messages/second ~100 KB/s (JSON) or ~30 KB/s (protobuf)
Report-by-exception (Sparkplug B) 100 messages/second (only changed) ~3 KB/s (protobuf, only changed metrics)
Reduction 90% fewer messages 97% bandwidth reduction

At multi-site scale (40 plants × 100 machines × 50 metrics = 200K metrics), report-by-exception is essential for manageable bandwidth and broker load.

UNS implementation roadmap

Phase Duration Activities
1. Topic namespace design 2-4 weeks Define ISA-95-aligned topic hierarchy for your organization. Document naming conventions, metric names, data types. Get consensus from IT + OT teams.
2. Broker deployment 2-4 weeks Deploy MQTT broker (HiveMQ/EMQX for enterprise, Mosquitto for pilot). Configure authentication (TLS + username/password or certificates), authorization (topic-level ACLs), clustering (if multi-site).
3. Edge node pilot 4-8 weeks Connect 5-10 machines to UNS via edge gateway (Sparkplug B client). Use: Cirrus Link Sparkplug modules for Ignition, HighByte Intelligence Hub, or custom MQTT client on edge gateway (Litmus Edge, Siemens Industrial Edge).
4. Consumer applications 4-8 weeks Connect OEE platform (TeepTrak Pulse), historian (InfluxDB), dashboards (Grafana, Power BI) as subscribers. Validate data flow: machine → broker → consumers.
5. IT system integration 8-16 weeks Connect ERP (SAP, Oracle, Dynamics 365) and MES as both publishers (work orders, recipes) and subscribers (production performance, OEE). This is the full UNS vision: OT + IT on same broker.
6. Multi-site rollout 3-12 months Replicate to additional plants. Options: local broker per plant + cloud broker for enterprise aggregation (federated UNS), or single cloud broker for all sites (centralized UNS).

UNS + OEE integration

OEE platform in a UNS architecture operates as both subscriber and publisher:

  • Subscriber: OEE platform subscribes to machine state, cycle count, reject count, stop reason topics from edge nodes → computes real-time A × P × Q per machine per shift
  • Publisher: OEE platform publishes computed KPIs (OEE %, Availability %, Performance %, Quality %, Six Big Losses breakdown, shift totals) back to UNS broker → available to any other consumer (digital twin, MES, VP dashboard, energy system)

TeepTrak Pulse in UNS architecture: TeepTrak Box edge sensor can publish directly to UNS broker via MQTT (Sparkplug B compatible) while simultaneously feeding TeepTrak Pulse cloud platform. The UNS broker becomes the data distribution layer; TeepTrak Pulse provides the OEE-specific computation, dashboards, and analytics. For plants without UNS (brownfield, legacy), TeepTrak Box operates standalone — no dependency on UNS infrastructure.

Security: MQTT broker for manufacturing

Security layer Implementation Standard
Transport encryption TLS 1.3 (mandatory for manufacturing UNS) IEC 62443 SR 4.1
Authentication X.509 certificates (mutual TLS) preferred, username/password as fallback IEC 62443 SR 1.1
Authorization Topic-level ACLs (who can publish/subscribe to which topics) IEC 62443 SR 2.1
Audit trail Broker logs all connections, publishes, subscribes with timestamps IEC 62443 SR 2.8
Network segmentation Broker in DMZ between OT and IT/cloud networks IEC 62443 zones and conduits
Rate limiting Per-client publish rate limits to prevent DoS Operational best practice
Payload validation Broker validates Sparkplug B protobuf structure Data integrity

FAQ: Unified Namespace for manufacturing

What is a Unified Namespace?

UNS is an architectural pattern using an MQTT broker as central hub for all plant data: OT (PLC, SCADA, OEE), IT (ERP, MES, CRM), engineering (CAD, PLM). Every system publishes to and subscribes from the broker using a standardized ISA-95 topic hierarchy. Replaces point-to-point integration (N×(N-1)/2 connections) with hub-and-spoke (N connections). Sparkplug B provides standardized payload format with birth/death certificates and report-by-exception.

What is Sparkplug B?

Sparkplug B (Eclipse Foundation, now v3.0): MQTT payload specification for industrial applications. Key features: birth certificates (NBIRTH/DBIRTH — device announces available metrics on connect), death certificates (NDEATH/DDEATH — stale data notification on disconnect), report-by-exception (only changed values published — 90% message reduction), protobuf serialization (3-10× smaller than JSON). Invented by Cirrus Link, standardized by Eclipse Foundation.

Which MQTT broker for manufacturing?

Enterprise: HiveMQ (clustering, RBAC, IEC 62443, Sparkplug aware, Kubernetes) or EMQX (high performance 100M connections, rule engine). Single-site/pilot: Eclipse Mosquitto (free, lightweight, simple). Cloud UNS: AWS IoT Core (AWS ecosystem) or Azure Event Grid MQTT (Azure ecosystem). Sparkplug-centric with Ignition SCADA: Cirrus Link Chariot. Choice depends on scale, existing infrastructure, and enterprise requirements.

How does UNS differ from traditional SCADA architecture?

Traditional SCADA: hierarchical data flow L0→L1→L2→L3→L4, data locked in each layer’s proprietary system, adding consumers requires custom integration at each layer. UNS: flat data access via broker, any system subscribes to any data directly, ISA-95 hierarchy preserved in topic structure (organizational) not in data flow (communication). SCADA becomes one of many equal participants on the broker, not the gatekeeper of all plant data.

What is ISA-95 hierarchy flattening?

Traditional ISA-95 enforces data flow through layers: process→sensing→control→MES→ERP. UNS flattens: all layers publish/subscribe directly to MQTT broker. Hierarchy preserved in topic names (Enterprise/Site/Area/Line/Machine) for organization, not in communication path. Benefits: reduced latency, any-to-any data access, resilience (if MES down, OEE still works), context enrichment (ERP work order + machine data both on broker).

How much bandwidth does UNS use?

Sparkplug B report-by-exception: 90% fewer messages vs polling (only changed values). Protobuf: 3-10× smaller than JSON. Example: 1000 metrics at 1 Hz with 10% change rate = ~3 KB/s (vs 100 KB/s polling JSON). At scale (40 plants × 100 machines × 50 metrics): ~600 KB/s with report-by-exception vs ~200 MB/s polling — essential for manageable multi-site bandwidth.

How does OEE integrate with UNS?

OEE platform as subscriber: receives machine state, cycle count, reject count, stop reason from UNS broker → computes A × P × Q. OEE as publisher: publishes computed KPIs (OEE%, availability, performance, quality, Six Big Losses) back to broker → available to digital twin, MES, VP dashboard. TeepTrak Pulse: supports MQTT Sparkplug B + standalone TeepTrak Box for brownfield without UNS.

UNS vs OPC UA — are they competing?

Complementary, not competing. OPC UA: semantic information model (Companion Specifications define what data means). MQTT/Sparkplug B: efficient transport + payload serialization (how data moves). Best practice 2027: OPC UA at machine level (PLC exposes Companion Spec data) → edge gateway converts OPC UA to MQTT/Sparkplug B → publishes to UNS broker. OPC UA Pub/Sub MQTT transport is the convergence point: OPC UA semantics transported over MQTT broker.

How long to implement UNS?

Pilot (1 plant, 10-20 machines): 3-6 months. Production (1 plant, full): 6-12 months. Multi-site enterprise: 12-24 months. Phases: topic namespace design (2-4 weeks), broker deployment (2-4 weeks), edge pilot (4-8 weeks), consumer integration (4-8 weeks), IT system integration (8-16 weeks), multi-site rollout (3-12 months). Fastest if existing edge gateways support MQTT (Litmus Edge, Siemens Industrial Edge).

What about UNS for legacy plants?

Legacy plants (old PLCs, no OPC UA, no MQTT): edge gateway with protocol conversion (Kepware, Litmus Edge 250+ drivers, Ignition + Cirrus Link modules). Convert Modbus/S7/EtherNet/IP → MQTT Sparkplug B at edge. Or: TeepTrak Box edge sensor (clamp-on, no PLC dependency) publishes directly to UNS broker via MQTT. UNS doesn’t require modern PLCs — gateway layer handles protocol conversion. Start UNS with 5-10 machines pilot, expand as ROI proven.

What is HighByte Intelligence Hub?

HighByte Intelligence Hub: industrial DataOps platform that sits between OT data sources and UNS broker. Provides: data modeling (create standardized data models from diverse sources), context enrichment (merge machine data with ERP/MES context), data quality (validation, cleansing, transformation), multi-protocol input (OPC UA, MQTT, REST, SQL) → standardized MQTT/Sparkplug B output to UNS. Useful when data normalization is needed before publishing to UNS. Microsoft partner.

Conclusion

The Unified Namespace (UNS) is the dominant IIoT architecture pattern for manufacturing in 2027, replacing point-to-point integration spaghetti with a hub-and-spoke MQTT broker model. Sparkplug B provides standardized payload (birth/death certificates, report-by-exception, protobuf serialization — 90% message reduction, 97% bandwidth reduction). ISA-95 topic hierarchy (Enterprise/Site/Area/Line/Machine) organizes data while flattening communication (any system publishes/subscribes directly). Leading brokers: HiveMQ (enterprise, IEC 62443), EMQX (high performance), Mosquitto (OSS simple), AWS IoT Core / Azure Event Grid MQTT (cloud-native). UNS + OPC UA are complementary: OPC UA for semantic machine data model, MQTT/Sparkplug B for efficient transport via UNS broker. OEE platform (TeepTrak Pulse) integrates as both subscriber (raw machine data → OEE computation) and publisher (OEE KPIs back to broker for digital twin, MES, dashboards). Implementation: 3-6 months pilot to 12-24 months enterprise. For plants without UNS: TeepTrak Box operates standalone (no UNS dependency) while being UNS-ready (MQTT Sparkplug B compatible) for future integration.

Next step: download the TeepTrak UNS architecture guide or request a free UNS readiness assessment for your manufacturing data infrastructure.

Request a demo

Recevez les dernières mises à jour

Pour rester informé(e) des dernières actualités de TEEPTRAK et de l’Industrie 4.0, suivez-nous sur LinkedIn et YouTube. Vous pouvez également vous abonner à notre newsletter pour recevoir notre récapitulatif mensuel !

Optimisation éprouvée. Impact mesurable.

Découvrez comment les principaux fabricants ont amélioré leur TRS, minimisé les temps d’arrêt et réalisé de réels gains de performance grâce à des solutions éprouvées et axées sur les résultats.

Vous pourriez aussi aimer…

0 Comments