Unified Namespace Architecture: HiveMQ + Sparkplug B (2026)

By May 2026, a quiet consensus has settled across the industrial data community: the question is no longer whether to deploy a Unified Namespace, it is which broker and which topic spec to standardize on. Walker Reynolds’ original 4.0 Solutions thesis from 2020 — that every plant should publish state to a single namespace and every consumer should subscribe — has matured into a reference pattern that runs in Krones bottling lines, Fortune-500 pharma sites, and a long tail of contract manufacturers. The dominant 2026 stack for this pattern is a Unified Namespace architecture built on HiveMQ as the broker substrate and Eclipse Sparkplug B as the payload and topic specification.

This post is the production reference architecture, not the manifesto. The manifesto has been written enough times. What follows is the layered architecture diagram you can defend in a design review, the HiveMQ cluster topology you can operate, the Sparkplug B topic tree that maps cleanly to ISA-95, the multi-site federation pattern that survives a WAN outage, and an honest catalog of the trade-offs that bite teams six months into deployment. The aim is to leave you able to draw the diagrams from memory, defend the choices to a sceptical platform architect, and identify the failure modes before they find you.

Why Unified Namespace Is the Default in 2026

Answer-first summary: A Unified Namespace is a single, semantically structured, real-time message broker that holds the current state of every asset, signal, and event in a plant or enterprise — and to which every producer publishes and every consumer subscribes by topic rather than by point-to-point integration. In 2026 it has become the default industrial data architecture because point-to-point integrations scale as N-squared, lakes are too slow for control-room consumers, and event-driven brokers with retained state finally have credible vendors, specs, and reference deployments to point at.

The case for UNS rests on three observations that took the IIoT community a decade to internalize. The first is that the industrial data integration problem is fundamentally combinatorial. A site with thirty source systems and twenty consuming applications can require up to six hundred bespoke point-to-point integrations under the old pattern; the same site, under UNS, requires fifty client connections to one broker. The maintenance load collapses by an order of magnitude. The second is that lakes and warehouses are excellent for analytics but architecturally wrong for operations — a control-room visualization that takes thirty seconds to refresh because a query has to traverse a Snowflake stage is not a control-room visualization, it is a postmortem. The third is that the broker pattern, specifically MQTT with retained messages, gives consumers a real-time stream and a current-state snapshot in the same primitive, which is exactly what an operational data plane needs.

The 2026 inflection is that the supporting ecosystem has finally caught up. HiveMQ shipped its Enterprise Distributed Tracing extension and matured its Kafka extension into a production-grade two-way bridge. Eclipse Sparkplug 3.0 is stable and widely implemented across Ignition, HiveMQ Edge, Cirrus Link transmission modules, and an expanding set of native PLC firmware. ISA-95 vocabulary — Enterprise/Site/Area/Line/Cell — has become the de facto naming convention for the Sparkplug group_id field. And the NAMUR Open Architecture work in process industries, which we cover in our NAMUR NOA process-industry adoption analysis, explicitly references MQTT/Sparkplug as the second-channel transport. Put together, the architecture is no longer aspirational; it is shippable.

What still trips teams up is treating UNS as a data architecture rather than as an operational architecture. The broker is the substrate, but the discipline is the schema — the Sparkplug topic tree, the metric naming conventions, the unit-of-measure handling, the rebirth protocol. Get the schema wrong and you have built a fast message bus around a still-incoherent data model. Get it right and the broker layer becomes nearly invisible — exactly what good infrastructure should be.

The UNS Reference Architecture

Answer-first summary: A production UNS architecture has four planes — an Edge/OT plane of PLCs, DCS controllers, and field instruments; an Edge-of-Network plane of gateways that bridge OT protocols (OPC UA, Modbus, EtherNet/IP) into Sparkplug B; a Broker plane built on a HiveMQ cluster with retained messages and bridging; and an IT/Cloud Consumer plane of historians, analytics engines, MES, and digital twins. The architectural unit of design is the topic, not the connection, and every signal in the plant has exactly one canonical address.

The diagram above is intentionally vendor-flavoured but pattern-neutral. The choices that change from site to site are the gateway product (Ignition Edge, HiveMQ Edge, FlowFuse, Litmus, Cirrus Link MQTT Transmission modules, or a Telit Cinterion deviceWISE appliance) and the consumer mix (InfluxDB, TimescaleDB, AVEVA PI, Snowflake, Databricks, Omniverse-anchored twins, SAP). What does not change is the layering and the rule that every cross-plane hop is mediated by the broker.

The Edge of Network is where most of the work lives

In the academic version of UNS the broker is the star. In production the Edge of Network layer eats most of the engineering time and risk. This is the layer that connects to PLCs over OPC UA, Modbus TCP, EtherNet/IP, S7, and Profinet; subscribes to OPC UA address spaces with sensible polling and dead-band settings; folds in protocol gateways for legacy serial buses; and republishes the result as Sparkplug B over MQTT 5. Three forces converge here. The first is that OT protocol coverage is uneven — every gateway product handles OPC UA and Modbus well, but obscure legacy dialects (Modicon Quantum, GE SRTP, antique DH+) push you toward Ignition with a paid driver or a Kepware/Kepserver predecessor. The second is that the gateway is also the publish policy enforcement point — what gets reported, at what frequency, on what change, with what dead-band — and that policy must be authored by people who understand both the process and the messaging cost. The third is that the gateway is the security boundary between OT and IT, and most regulated industries will not let you collapse that boundary even if the broker is on-prem.

The broker plane is the contract

The broker plane in a production UNS is a clustered HiveMQ deployment with persistent sessions, retained messages, and explicit QoS choices per topic family. The cluster is sized for peak concurrent client count rather than message rate, because Sparkplug’s report-by-exception discipline keeps message rate well below what an unstructured “publish everything every second” architecture would generate. A single HiveMQ Enterprise broker cluster comfortably handles north of ten million concurrent MQTT clients with appropriate sizing, per HiveMQ’s own published benchmarks, and the practical bottleneck for most industrial sites is bridge throughput to downstream consumers rather than broker capacity. The broker layer is also where the enterprise security boundary lives — OAuth2/OIDC for IT-side consumers, mutual TLS with client certificates for edge gateways, fine-grained topic ACLs that mirror the ISA-95 hierarchy.

The conceptual move that takes the broker from “fast queue” to “operational data plane” is the retained-message contract. Every Sparkplug NBIRTH and DBIRTH message is retained. When a new consumer subscribes, it receives the current state of every metric on every device in the namespace before it sees a single live update. That property — current-state-on-subscribe — is what makes the broker behave like a database for the operational layer. It is also what kills naive deployments that disable retention to save memory and then wonder why dashboards start blank.

The consumer plane subscribes; it does not pull

The fourth plane, the IT and cloud consumer layer, is where the cost savings from UNS show up on a spreadsheet. Historians (InfluxDB, TimescaleDB, AVEVA PI), analytics platforms (Snowflake, Databricks, Microsoft Fabric Real-Time Intelligence), MES and ERP systems, and digital-twin substrates all become subscribers to the namespace rather than pollers of source systems. The Kafka extension to HiveMQ is the heavy-traffic on-ramp for lakehouse consumers; native MQTT clients work fine for lighter-weight consumers like custom dashboards or twin engines. The architectural rule that earns its keep here is simple: no consumer reaches across the broker to a source system. Everything flows through the namespace.

The classical anti-pattern is the consumer that “supplements” its UNS subscription with a direct pull from a historian because the team did not trust the broker to carry everything. That choice quietly resurrects the N-squared integration problem the architecture was meant to retire. The mitigation is to make the namespace genuinely complete from day one and to publish the metric inventory as a first-class artifact engineers can browse — the namespace is the contract, and if it is not complete, you do not have a UNS, you have an additional integration.

A practical companion read for the OT-side protocol choices is our analysis of OPC UA FX field-level communications in 2026, which covers the deterministic transport layer below the broker.

HiveMQ as the UNS Broker

Answer-first summary: HiveMQ is the dominant 2026 broker choice for an industrial UNS because it is the only MQTT broker that combines a clustered architecture with persistent state replication, native MQTT 5 and Sparkplug B awareness, a production-grade Kafka extension, enterprise security (OAuth2, OIDC, fine-grained ACLs), and operational tooling (distributed tracing, Prometheus metrics, OpenTelemetry, control-center UI) at the scale industrial sites actually run. Open-source alternatives (Mosquitto, EMQX, VerneMQ) have their place but lose on at least one of those dimensions for sites above a few hundred clients.

A HiveMQ cluster for a single-site UNS is typically three to five nodes behind a layer-4 network load balancer in TLS-passthrough mode, with persistent sessions and retained messages replicated across nodes. The cluster uses an embedded distributed key-value store for session and message state; the operational model is a single logical broker presented through a single endpoint, with node failures transparent to clients. Node sizing is driven by the concurrent-client peak, queue depth for offline clients, and the bridge or Kafka extension throughput; HiveMQ’s own sizing guidance suggests roughly 8 vCPU / 32 GB RAM per node as a sensible starting point for a site handling tens of thousands of clients, scaling up for retained-message-heavy workloads.

The decisive feature for industrial deployments is the extension framework. The Kafka extension provides a bidirectional bridge between MQTT topics and Kafka topics, with topic mapping rules, partition routing, and exactly-once semantics in the Kafka direction — the on-ramp for Snowflake, Databricks, and Confluent-based event platforms. The Enterprise Security extension wires the broker to OAuth2/OIDC providers (Azure AD, Okta, Keycloak) and supports fine-grained topic ACLs that can match Sparkplug topic patterns. The Distributed Tracing extension emits OpenTelemetry spans for client connect/publish/subscribe events, which is the difference between a broker you can debug and one you cannot. The control-center UI gives operations teams a real view of cluster health, queue depths, and client activity — the kind of operational affordance that is almost free in IT systems and almost absent from many OT vendors’ MQTT offerings.

Two implementation choices repay attention. The first is the persistent session decision. Sparkplug B edge nodes use MQTT 5’s clean_start=false with a non-zero session expiry interval, so the broker holds queued messages while the edge is offline and replays them on reconnect — but only up to a configurable queue depth. Sizing the per-client queue is a judgement call between memory cost and acceptable replay window; a starting point is enough capacity for a one-hour outage of the worst-case edge node. The second is the QoS choice. Sparkplug 3.0 mandates QoS 0 for NDATA/DDATA messages (because the seq number and rebirth protocol provide stronger ordering and detection than QoS 1 would) and QoS 1 for STATE messages. Teams who override these settings to get “more reliability” usually break the rebirth protocol without realizing it.

HiveMQ’s competition deserves an honest mention. Mosquitto is excellent for a single-node test bench but is not a cluster; it falls over the moment a site needs HA. EMQX Enterprise is a credible competitor with strong clustering and Sparkplug awareness, frequently chosen by APAC sites and by teams who want an open-core option. VerneMQ has fans for its Erlang-based concurrency model but is thinner on industrial-specific extensions. AWS IoT Core is appropriate when the entire UNS is in the cloud and the customer is already AWS-centric, but the operational model and pricing diverge from on-prem norms in ways that surprise teams. For most regulated on-prem deployments in 2026, HiveMQ Enterprise has become the safe default, in the same way that PostgreSQL became the safe default RDBMS a decade ago — not always the best on any single axis, reliably best on the weighted average.

Sparkplug B Topic Design and ISA-95 Mapping

Answer-first summary: Sparkplug B prescribes a fixed-shape topic namespace of the form spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id} and a binary protobuf payload with a strict session lifecycle (NBIRTH, DBIRTH, NDATA, DDATA, NDEATH, DDEATH, NCMD, DCMD). The architectural decision is what to put in the group_id — and the right answer in 2026 is the ISA-95 hierarchy, encoded as Enterprise_Site_Area, with edge_node_id typically representing a Line or Cell controller and device_id the individual asset. This mapping is what makes the namespace queryable by anyone who has ever read ISA-95-3.

The Sparkplug topic namespace is one of the most opinionated parts of the spec, and that opinionatedness is a feature. Every Sparkplug-aware tool — Ignition, HiveMQ, Cirrus Link, FlowFuse — can parse the topic and reason about the message type without inspecting the payload. The fixed shape is the contract that makes interoperability possible. The room for site-level decision is in the group_id, the edge_node_id choice, and the metric naming inside the payload — and that is exactly where ISA-95 mapping pays off.

A typical 2026 convention encodes the upper ISA-95 levels into the group_id as a delimited string: AcmeCorp_Munich_Packaging for the Packaging area of the Munich site of the Acme enterprise. The edge_node_id then represents an ISA-95 Work Center or Line — Line03_CellController — and the device_id represents an Equipment Module or unit asset within that line — Filler_F101. The Sparkplug metric names inside the protobuf payload encode the lower ISA-95 levels and the data point itself — Motor/Drive/Current_A, Tank/Level/Pct, Recipe/CurrentStep/Index. The result is a fully-qualified address — spBv1.0/AcmeCorp_Munich_Packaging/DDATA/Line03_CellController/Filler_F101 + metric Tank/Level/Pct — that a downstream consumer can parse mechanically into ISA-95 levels with no out-of-band knowledge.

The session lifecycle is the part of Sparkplug that teams underestimate until they get it wrong. When an edge node connects to the broker it registers a Last Will and Testament that the broker will publish on its behalf if the connection drops — the NDEATH. It then publishes an NBIRTH with seq=0 and a fresh bdSeq (birth/death sequence counter) carrying the full inventory of every metric the node will report. For each device under the node it publishes a DBIRTH containing the device-level metric inventory and metric aliases. Only after birth is established do NDATA and DDATA messages start flowing, each carrying an incrementing seq so that consumers can detect gaps. A host application that detects a gap — or that observes an NDEATH followed by a reconnect with a mismatched bdSeq — issues a Node Control/Rebirth command, which forces the edge to re-publish its full state. The protocol’s correctness depends entirely on this dance being implemented faithfully on both sides.

Three implementation realities are worth surfacing. First, the protobuf payload uses metric aliases — short integer IDs assigned during BIRTH that replace the full metric name in DATA messages — for wire efficiency. Teams who turn aliases off “for readability” pay a real bandwidth cost; teams who turn them on without verifying their consumers handle them get cryptic decoding errors in production. Second, command messages (NCMD, DCMD) are how host applications write setpoints back to the edge, and they require a deliberate authorization model — most sites restrict command-issuing identities through topic ACLs and require an audit trail. Third, state messages for Sparkplug Host Applications (spBv1.0/STATE/{host_id}) are how consumers signal their own liveness to edges; this is often forgotten in custom subscribers, which then look “dead” to edges that implement primary-host failover correctly.

A deeper protocol-level comparison with the alternative — OPC UA PubSub over MQTT — lives in our Sparkplug B vs OPC UA PubSub comparison for 2026. For most discrete and hybrid sites the Sparkplug topic discipline beats OPC UA PubSub’s looser conventions; for process plants with NAMUR NOA influence, the calculus shifts.

Scaling, HA, and Cross-Site Federation

Answer-first summary: A multi-site UNS federates plant-level HiveMQ clusters into a corporate-level core cluster via MQTT bridges, with carefully scoped topic filters that send only the metrics the enterprise needs upward and that send only commands and recipes downward. The pattern preserves plant autonomy during WAN outages, keeps the corporate UNS bounded, and provides a single subscription endpoint for enterprise consumers like SAP S/4HANA, Snowflake, and the digital twin.

The architectural pattern that 2026 has settled on is hub-and-spoke MQTT bridging, not full-mesh. Each plant operates its own HiveMQ cluster as the authoritative UNS for that site — operations runs on local state, survives WAN cuts, and never depends on a cloud round trip for control-room responsiveness. A unidirectional or bidirectional MQTT bridge then forwards a filtered subset of topics to a corporate core cluster in a cloud region. The filter is the key design parameter. A typical filter forwards all NBIRTH/NDEATH/DBIRTH/DDEATH state messages (these are essential for enterprise visibility into edge liveness), forwards a curated set of KPI metrics (production counts, energy, OEE inputs), and excludes high-frequency control loop telemetry that the enterprise does not need to see.

The corporate cluster sits behind a Kafka extension that fans the filtered stream out to Snowflake, Databricks, Microsoft Fabric Real-Time Intelligence, or whatever the enterprise lakehouse looks like. It also exposes a clean subscription endpoint to SAP S/4HANA’s event-driven interfaces, to the enterprise digital twin (whether Omniverse-anchored, AAS-based, or vendor-specific), and to any cross-site analytics applications. Critically, the bridge runs in both directions for command and recipe topics — NCMD/DCMD flowing from the corporate plane back to a specific edge node at a specific site, mediated by topic ACLs that ensure recipes for the Pune site cannot accidentally land at the Munich site.

Two scaling realities deserve a flag. The first is that bridge throughput is the bottleneck most teams hit first, not broker capacity. A WAN link with sub-100 Mbps headroom or sub-50 ms tolerance for jitter will throttle the bridge long before either cluster runs out of CPU. Sites in regions with thinner connectivity (parts of LATAM, SE Asia, sub-Saharan Africa) often size the filter more aggressively for this reason. The second is that persistent queue depth on the bridge is your insurance against WAN cuts. A bridge configured for QoS 1 with a generous persistent queue will buffer hours of traffic and drain in order when connectivity returns; a bridge with no queue or QoS 0 silently loses data during outages. The right starting point is a queue sized for the longest WAN outage your site has historically experienced, multiplied by a safety factor of three.

HA at the broker layer is handled by the cluster; HA at the bridge layer is handled by running the bridge endpoint on more than one node in each cluster with active/standby semantics. Disaster recovery — the case where an entire site’s cluster is lost — is handled by the corporate cluster’s retained-message store, which holds the last-known-good state of every bridged topic and can serve a freshly-stood-up replacement.

Trade-offs, Gotchas, and What Goes Wrong

Answer-first summary: UNS deployments fail in five distinctive ways: incomplete namespaces that quietly preserve the old N-squared integrations, broken rebirth handling that leaves stale state in consumers, payload chaos when Sparkplug metric naming is undisciplined, bridge backpressure that silently drops enterprise data during WAN outages, and security models that treat topic ACLs as an afterthought.

The incomplete-namespace failure is the most common and the most insidious. A team ships UNS for a pilot line, the executives nod approvingly, and three months later a new consumer needs three signals the pilot did not publish — and instead of extending the namespace, the consumer reaches around the broker to a historian. Repeat that twice and the architecture is back to point-to-point with extra steps. The mitigation is to publish and govern a namespace inventory — every metric, on every device, with semantic metadata — as a first-class artifact reviewed in change control.

The rebirth-handling failure manifests as ghost state. An edge node loses its connection, reconnects with a new bdSeq, and republishes — but a consumer that does not implement the bdSeq mismatch check goes on believing the pre-outage state was current. Dashboards show stale numbers; analytics fits models to phantom values. The mitigation is to test every custom subscriber against a forced rebirth scenario before it goes near production, and to use Sparkplug-aware libraries (HiveMQ Sparkplug client, Tahu reference implementation, Ignition’s Sparkplug module) wherever feasible rather than rolling raw MQTT subscribers.

The payload-chaos failure is what happens when Sparkplug metric naming is not governed. One edge node publishes Tank/Level/Percent, another publishes tankLevel_pct, a third publishes LT-101.PV. The topic tree is clean but the payload is incoherent, and downstream consumers have to do exactly the kind of cross-source mapping the UNS was supposed to eliminate. The mitigation is a metric-naming standard, enforced at the gateway publishing layer with linting rules.

The bridge-backpressure failure is the silent one. A WAN cut backs the queue up; the queue hits its configured cap; new messages are dropped; the bridge resumes after the cut without ever logging that it lost data. The mitigation is generous queue sizing, explicit dead-letter handling, and proactive monitoring of bridge queue depth as a first-class metric.

The security-afterthought failure is the most embarrassing. Teams deploy UNS with permissive topic ACLs (“everyone can subscribe to spBv1.0/#”) and discover during a pen test that a compromised IT laptop can issue DCMD setpoint changes against safety-relevant equipment. The mitigation is to design topic ACLs alongside the namespace from day one — read scopes by ISA-95 area, write scopes restricted to a small audited identity set, and command topics behind a deliberate authorization workflow.

Practical Recommendations

Answer-first summary: Start with the namespace, not the broker. Standardize on Sparkplug 3.0 and HiveMQ Enterprise unless you have a specific reason not to. Bridge plant clusters to a corporate core, do not collapse to one cluster. Treat the metric inventory and the rebirth protocol as production artifacts with owners.

A concrete checklist that has held up across the deployments we have reviewed:

For architects
– Draw the four-plane diagram (Edge/OT, Edge of Network, Broker, Consumer) for your specific site before you write a single line of configuration.
– Map ISA-95 levels to group_id/edge_node_id/device_id and document the convention.
– Pick HiveMQ Enterprise unless a specific constraint (heavy cloud-only deployment, AWS lock-in by mandate, open-core requirement) pushes you to EMQX or AWS IoT Core.
– Mandate Sparkplug 3.0 for all new edges; allow legacy MQTT only behind a Sparkplug-emitting gateway.

For platform engineers
– Size the cluster for concurrent clients and retained-message memory, not raw message rate.
– Configure persistent sessions with clean_start=false and a session expiry interval matched to your worst-case outage.
– Wire OpenTelemetry tracing through the broker from day one; you cannot debug what you cannot trace.
– Test every subscriber against a forced rebirth before promotion to production.

For OT engineers
– Govern the metric inventory like you would a tag database — naming standards, units of measure, change control.
– Configure dead-bands and report-by-exception thresholds at the gateway, not at the broker.
– Audit topic ACLs against ISA-95 areas; never deploy with spBv1.0/# as a default subscribe scope.
– Maintain a published catalog of what the namespace covers so consumers can self-serve.

The teams that get to a productive UNS in 2026 are the ones who treat the architecture as a contract — the namespace, the topic shape, the lifecycle, the security model — and the broker as a faithful, monitored, but ultimately unremarkable implementation of that contract.

FAQ

What exactly is a Unified Namespace?
A Unified Namespace is a single, real-time, semantically structured message broker that holds the current state of every asset, signal, and event in a plant or enterprise, and to which every producer publishes and every consumer subscribes by topic. It is operational data infrastructure, not an analytics store. The defining properties are real-time delivery, retained current state, a hierarchical topic schema (usually ISA-95-aligned in industrial contexts), and a publish-subscribe pattern that replaces point-to-point integrations. In 2026 the dominant industrial implementation is MQTT-based, with HiveMQ as the broker and Sparkplug B as the payload and topic specification.

Why HiveMQ instead of Mosquitto or EMQX?
HiveMQ wins for enterprise industrial deployments on the combination of clustered HA, replicated persistent sessions, native Sparkplug B awareness, a production-grade Kafka extension, enterprise security extensions (OAuth2, OIDC, fine-grained ACLs), and operational tooling (distributed tracing, OpenTelemetry, control-center UI). Mosquitto is excellent for development and single-node scenarios but cannot cluster. EMQX is a credible competitor — its open-core model fits some teams better — but in the typical regulated on-prem deployment the operational maturity and Sparkplug-specific features push HiveMQ ahead.

How does Sparkplug B relate to MQTT?
Sparkplug B is an Eclipse Foundation specification layered on top of MQTT 3.1.1 or MQTT 5. It does not replace MQTT — it constrains it. Sparkplug defines a fixed topic namespace shape (spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}), a protobuf binary payload, a strict session lifecycle (NBIRTH/DBIRTH/NDATA/DDATA/NDEATH/DDEATH), a metric alias scheme for wire efficiency, and a rebirth protocol for state recovery. The result is an interoperable convention that any Sparkplug-aware tool can parse and reason about without bespoke per-vendor adapters.

Where does ISA-95 fit into the UNS topic design?
ISA-95 provides the hierarchical vocabulary (Enterprise, Site, Area, Work Center / Line, Work Unit / Cell, Equipment Module) that maps cleanly onto Sparkplug’s group_id, edge_node_id, and device_id fields. The 2026 convention encodes Enterprise/Site/Area into group_id, Line or Cell into edge_node_id, and individual asset into device_id, with the lower ISA-95 levels surfaced inside metric names in the payload. The result is a namespace any operations engineer who has read ISA-95-3 can navigate without a translation guide.

What is the rebirth protocol and why does it matter?
The Sparkplug rebirth protocol is the mechanism by which a host application can force an edge node to republish its full inventory of metrics. The host sends a Node Control/Rebirth command on the NCMD topic; the edge responds by publishing a fresh NBIRTH with seq=0 and a new bdSeq, followed by DBIRTH messages for each device. The protocol matters because it is the recovery primitive after any state-loss event — an edge restart, a consumer joining late, a missed sequence number. Without correct rebirth handling on both sides, the namespace silently accumulates stale state and the architecture’s correctness guarantees evaporate.

Further Reading

Internal:

• IIoT pillar overview — the broader context for industrial data architecture choices.
• OPC UA FX field-level communications analysis (2026) — the deterministic transport layer below the UNS broker.
• Sparkplug B vs OPC UA PubSub comparison (2026) — head-to-head on the two competing IIoT messaging specs.
• NAMUR NOA process-industry adoption architecture (2026) — second-channel data architecture in process plants, with MQTT/Sparkplug as a key transport.

External:

• HiveMQ documentation — broker configuration, clustering, extensions, and Sparkplug guidance (docs.hivemq.com).
• Eclipse Sparkplug 3.0 specification — topic namespace and state management (eclipse.org/tahu).
• ISA-95 standards committee — Enterprise-Control System Integration standards series (isa.org).
• Walker Reynolds and the 4.0 Solutions Unified Namespace material — the original IIoT articulation of the pattern.