OT/IT Integration: Unified Namespace and MQTT Sparkplug B in Manufacturing

The OT/IT bridge is manufacturing's quietest problem: a CNC machine from 1995 generating data, a PLC speaking Modbus, and an ERP that needs that information but never receives it clean. The unified namespace (UNS) solves that bridge with an architectural idea, not another product: a single tree of MQTT topics where every plant and business system publishes and consumes data in the same language. We will look at how a unified namespace is designed with MQTT Sparkplug B, what role the edge plays, how the naming hierarchy is organised and which mistakes are worth avoiding.

Why OT and IT are still separate continents

IT and OT do not clash out of stubbornness: they optimise for different things. IT optimises for speed and flexibility. A server can be rebooted, a microservice can be redeployed ten times a day, and if a piece of data is lost there is usually a copy or a way to regenerate it. OT optimises for continuity. A machine is not restarted mid-batch, a PLC has been running the same program for fifteen years without blinking, and if a process value is lost nobody will ever know what happened in that interval.

That difference in priorities shows in the protocols. The ones IT uses (HTTP, REST APIs, corporate message queues) presume stable networks and clients that can retry. The ones OT uses (Modbus, PROFINET, OPC UA in its classic role) were born for determinism on the local network and fit poorly when they have to cross a WAN or scale to thousands of devices. When an IT engineer proposes centralising plant equipment authentication in a corporate directory, the OT engineer sees the immediate risk: if that server fails, the machine stops talking.

The usual outcome is that each side builds its own silo. IT deploys its data platform and its dashboards; OT keeps its SCADA systems and its local historians. Between the two, point-to-point integrations: a connector from the MES to the ERP, a script exporting CSVs from the historian, an API reading from the SCADA. Every new integration multiplies the coupling, and the data the business needs for decisions arrives late, incomplete or with undocumented units. That pattern of direct connections between pairs of systems is what the architecture literature calls integration spaghetti, and it is exactly what the unified namespace comes to replace.

What the unified namespace is: architecture, not product

The unified namespace is an architectural decision with a simple statement: all the organisation's relevant data is published into a single hierarchical namespace, in real time, and any system that needs a value subscribes to it instead of asking whoever produces it directly. In practice, that namespace is almost always implemented as a topic tree on an MQTT broker. Here we approach it from the perspective of the integration project; the concept in depth, with its principles and comparisons, is developed in our guide to the Unified Namespace (UNS).

The underlying change is in the direction of the integrations. In the point-to-point model, every consumer knows every producer: the dashboard knows the SCADA's IP address, the ERP knows which MES table to read. In the UNS model, producers and consumers only know the namespace. The machine publishes its state on its branch of the tree; whoever needs it subscribes. Adding a new consumer touches nothing that already exists. Adding a new machine does not either: it publishes on its branch and subscribers listening with wildcards discover it.

The UNS being architecture rather than product has practical consequences:

• Old machines do not change. The PLC keeps speaking Modbus at its own pace. An edge gateway listens, translates and publishes on its behalf.
• The data travels once. It is captured and normalised at source, and from then on every consumer sees the same version.
• The current state is queryable. With retained messages or with Sparkplug's birth certificate mechanism, a system that connects obtains the complete picture of the plant without polling anyone.
• It scales by design. A well-dimensioned MQTT broker handles tens of thousands of clients; the publish-subscribe pattern does not degrade as consumers are added.

How the namespace is organised: hierarchy and naming

The hardest part of a UNS is not the broker: it is the agreement on names. An ungoverned namespace degenerates into the same chaos it set out to solve, only inside a broker. The usual starting point is the ISA-95 equipment hierarchy: enterprise, site, area, line, cell or unit. The signals hang from that backbone:

captia/valencia/mecanizado/linea-2/cnc-07/estado
captia/valencia/mecanizado/linea-2/cnc-07/piezas/contador
captia/valencia/mecanizado/linea-2/cnc-07/husillo/temperatura
captia/valencia/energia/cuadro-general/potencia-activa

Three rules prevent most of the later problems. First: the hierarchy describes where the data lives and what it represents, never who consumes it (no branches called dashboard or erp). Second: the names are agreed in writing before the second machine is connected, in a short document defining levels, language and capitalisation convention. Third: the value travels with its metadata, such as engineering unit, origin timestamp and reading quality, so the consumer never has to guess whether that temperature is in degrees or tenths of a degree.

It is also useful to distinguish between the device's raw data and the business's functional data. Many organisations publish both in separate branches: a low-level branch with the signals exactly as they leave the gateway, and a functional branch with indicators already worked up (line status, per-shift counters, OEE). Business consumers subscribe to the functional branch and do not depend on the details of each controller.

MQTT and Sparkplug B: the common language

MQTT is a publish-subscribe protocol born in the late nineties for telemetry over precarious links, later standardised by OASIS. Its virtue is sobriety: a message is a topic and a payload, the connection is lightweight and tolerates bad networks, and mechanisms like the last will let you know when a client has dropped. Precisely because of that sobriety, MQTT says nothing about what is inside the payload, and that is where industry needed more structure.

Sparkplug B is an open specification, today under the umbrella of the Eclipse Foundation, that lives on top of MQTT and defines what MQTT lacks for industrial use:

• Topic and payload structure: a predictable namespace and an efficient binary format with typed metrics, instead of improvised JSON that differs at every plant.
• State management: each edge node announces its birth (birth certificate) with the complete list of its metrics and values, and the broker publishes its death if the node disappears. Any consumer knows at all times whether a value is live or stale.
• Report by exception: after the birth, only the metrics that change travel. On slow or metered links, that difference matters.
• Strong typing: a value is not free text, it is a declared integer, float or boolean. That eliminates a whole family of silent interpretation errors.

Sparkplug B is not the only way to build a UNS (some organisations define their own payload schema over plain MQTT), but it is the standard with the broadest support among gateway, broker and platform vendors, and it solves out of the box the state problem that plain MQTT forces you to reinvent. The detail of the specification, with its topic structure, its birth and death certificates and its metric aliases, is in our dedicated article on Sparkplug B.

Three-layer reference architecture

An OT/IT integration over a unified namespace has three well-separated layers.

Layer 1: protocol translation (edge)

The edge gateway lives close to the machines, on the OT network. It reads Modbus, PROFINET, OPC UA or hardwired signals, each protocol at its own pace. It validates the readings, adds an origin timestamp and unit, stores them in a persistent local buffer in case the network fails, and publishes them as Sparkplug B into the namespace. It is the piece that lets the machines from 1995 take part without being touched. This layer maps to what our catalogue calls edge ingestion and PLC connectivity.

Layer 2: MQTT broker (backbone)

A broker with support for persistent sessions and, ideally, high availability. It can run on a plant server, in a private cloud or in a public cloud behind a VPN; what matters is that edge and consumers connect only to it. If the broker goes down, the edge keeps capturing and buffering; when it comes back, it drains the backlog. The specific choice (hardened Mosquitto, HiveMQ, EMQX or others) depends on volume and operational requirements, not on the pattern.

Layer 3: consumers (IT)

The historian, the data warehouse, the dashboards, the MES, the AI models and, with a suitable connector, the ERP: all subscribe to the branches that interest them. There is no polling and there are no fragile system-to-system APIs; there are asynchronous subscriptions to a stable namespace. Each consumer's MQTT integration with the broker and the ERP integration are bounded projects because the contract is always the same: the namespace. To see how these three layers fit within a complete acquisition, storage and analytics architecture, we develop it in our industrial data platform.

The edge as producer: buffering and data quality

The unified namespace is only as good as the data entering it, and the data enters through the edge. Two properties of the gateway condition everything else. The first is store-and-forward: capture and publication must be independent processes, with a persistent on-disk buffer between them, so a WAN outage lasting hours opens no gaps in the history. The second is normalisation at source: translating register addresses into business names, applying scales and units, and flagging the quality of each reading once, at the gateway, instead of repeating that translation in every consumer.

Sizing the buffer, choosing the right MQTT QoS level for each signal and avoiding the typical failures (RAM-only buffers, arrival timestamps instead of origin timestamps, undisciplined clocks) deserves a guide of its own. We have written it: the pillar on industrial edge with buffering and QoS walks that entire chain, from sensor to cloud, with concrete sizing criteria.

From topic to data contract

Once the namespace starts gaining business consumers, a new question appears: what exactly does each topic promise? The fact that cnc-07/husillo/temperatura exists says nothing about how often it updates, what unit it is in, what happens when the machine is off or who answers if the data stops arriving. While the only consumer is a dashboard watched by someone on the shop floor, the ambiguity is tolerated. When the consumer is a production settlement or a predictive maintenance model, it is not.

The mature answer is to treat each published branch as a data contract: an explicit agreement on schema, units, frequency, quality and ownership, versioned when it changes. The unified namespace puts every system on the same channel; the contracts define what can be expected of what is said on that channel. We develop that next step in the guide to industrial data contracts, which naturally continues this one.

Three scenarios where it works

Scenario 1: a factory with dozens of veteran machines

PLCs from the late nineties, analogue energy meters, no industrial network worthy of the name. One or several edge gateways translate everything into Sparkplug B and publish it into the namespace. The machines are untouched; the plant goes from having no data to seeing status and counters in real time, and the history starts accumulating from day one.

Scenario 2: a plant with OPC UA but no reliable data at corporate level

OPC UA works well on the local network, but the client-server link suffers with latency and intermittency when crossing the WAN, and every corporate application that wants data opens its own session against the server. The solution is a gateway acting as a local OPC UA client, validating, and publishing via Sparkplug B. The OPC UA server serves a single stable client; the rest of the world consumes from the broker.

Scenario 3: non-production systems that are also part of the plant

A machine vision camera with a REST API, a weighbridge with a serial output, an energy management system with its own software. The edge consumes each peculiar interface, translates it and publishes the result as namespace topics. The inspection result or the batch weight becomes available to any system without coupling to the equipment that produces it, just like the signals from sensors or from machine vision.

Implementation: typical roadmap

Phase 1: mapping and architecture

Inventory of devices and protocols, definition of the naming hierarchy, choice of gateway and broker. It is the cheap phase where the expensive mistakes are avoided: a badly named namespace is paid for over years.

Phase 2: building the translation

Configuration of per-protocol drivers, signal mapping, validation, buffering and laboratory testing against the target broker.

Phase 3: gradual rollout

First one machine, then groups. The namespace runs in parallel with the old systems, which are not switched off until the new data is validated. There is no production downtime: the gateway only listens.

Phase 4: consumption and operation

Dashboards and the first business consumers, health alerts for the namespace itself (nodes down, stale data), topic documentation and training so the IT team can operate broker and gateways.

Return and justification

The cost of an OT/IT integration depends on the number of machines, the variety of protocols and the state of the network, so any general figure would be smoke. What is general is where the return comes from:

• Time to detection: process problems go from being discovered in the next day's report to being seen in minutes.
• Data quality: a single version of the data, normalised at source, instead of three extracts that do not reconcile.
• Decreasing marginal cost: connecting machine number twenty costs a fraction of what the first one cost, because the architecture already exists. In the point-to-point model the opposite happens.
• Optionality: dashboards, MES, AI models and ERP consume the same namespace. Every new data initiative starts from a foundation already built, not from scratch.

What the OT/IT bridge is not

It is not machine replacement. The machines remain what they are; the gateway represents them in the namespace without modifying them.

It is not forced centralisation. The data is shared, the control is not. The machine remains autonomous: if the broker, the WAN or the entire IT building disappears, production continues.

It is not a data lake. The UNS is the circulatory system for real-time data; historical storage is just one more consumer that subscribes and persists. Confusing the two leads to designs that serve neither purpose well.

It is not added complexity. MQTT and Sparkplug B are sober specifications that a maintenance team and an IT team can operate together. The real complexity, the integration spaghetti, is what gets removed.

Frequently asked questions about the unified namespace

If you are weighing up how to take the data from your machines to your business systems without building another integration spaghetti, at Captia Connect we work exactly this pattern: from OT/IT integration and shop floor connectivity to the MQTT integration with your data platform. The first step is a mapping of what you have and where the first value lies.