MQTT Integration
We implement MQTT brokers and data flows to connect sensors and industrial devices at scale, with topic hierarchies designed around the plant and options such as Sparkplug B when several systems consume the same data.
Industrial MQTT integration: what the service covers
We implement MQTT brokers and data flows to connect sensors and industrial devices at scale. MQTT is a lightweight publish/subscribe protocol that has become the de facto standard for moving plant data upwards: devices publish their data to a central broker, and any system that needs them simply subscribes. That decoupling removes the tangle of point-to-point connections of classic integrations, so new consumers can be added without touching plant equipment or loading PLCs with extra read clients.
The design work covers the topic hierarchy, the QoS level per data type (from fire-and-forget signals to exactly-once delivery for production counters), device state handling through last-will messages, and, where several systems consume the same data, the Sparkplug B specification, which adds a normalized topic structure and payload format on top of MQTT. Direct polling remains valid for small cases; MQTT pays off when consumers, devices or network unreliability grow. The reference architecture has three layers: edge gateways reading equipment through native protocols (see PLC connectivity), a secured central broker, and subscribing consumers. Our scope is data connectivity, delivered as part of the Captia Connect offering.
How it connects to the system
Connect enables data flow to AI and Energy and supports execution that Service digitises in the business layer.
Key concepts
Other solutions
- Edge Ingestion
We capture data at the edge of the operation, where it is generated, without depending on central connectivity. We deploy edge ingestion software on plant equipment that reads signals locally, holds them through network outages and forwards them once the connection is restored.
- PLC Connectivity
We connect PLCs from any manufacturer and protocol to the Captia unified data layer, making control-layer information reliably available to the rest of your systems, from process historians to dashboards, without altering the control programs.
- OT/IT Integration
We build the bridge between the operational world (OT) and the information systems world (IT): a data layer that reads plant information and delivers it to business systems, with an architecture designed not to interfere with production.
Frequently asked questions
- What is an MQTT broker and why does a plant need one?
- The MQTT broker is the central server every device connects to, both data publishers and consumers. Each device keeps a single connection to the broker instead of talking to everyone else, which simplifies the network and lets you add new consumers without touching plant equipment. Without a broker there is no MQTT: it is the piece that decouples data producers from consumers.
- Does MQTT replace OPC UA or PLC protocols?
- It complements them rather than replacing them. PLCs keep speaking their native protocol (S7, Modbus, EtherNet/IP, OPC UA) with the gateway or edge software that reads their variables. MQTT comes in afterwards, as the transport layer that distributes that data to the rest of the systems. Architectures often combine OPC UA for machine reads and MQTT for upward distribution.
- What is Sparkplug B?
- Sparkplug B is an open specification that adds a common topic structure, a defined message format and device state management (birth and death of each node) on top of MQTT. With plain MQTT every project invents its own topics and formats; with Sparkplug B, any compatible application understands the data without prior agreements. It is a sensible choice when several systems will consume the same plant data.
- What happens to the data if the network or the broker goes down?
- MQTT is designed with these failures in mind. QoS levels allow delivery confirmation per message, and clients can buffer data at the edge while offline and resend it on reconnection. The broker itself can run in high-availability configurations. The exact design depends on how critical each data stream is: not everything needs the same guarantee level.