Industrial MQTT gateway checklist for a brownfield plant

An MQTT gateway is often sold as a quick bridge between old equipment and a modern data platform. The bridge is easy to demo. The hard part is making the data trustworthy when a controller reboots, a network link disappears, a tag changes meaning, or two engineers choose different names for the same motor.

Start at the southbound boundary

List the equipment and protocols the gateway must speak: Modbus registers, OPC UA nodes, vendor APIs, files, or a machine-tool adapter. For each source, record polling limits, scan rates, quality flags, units, timestamps, and what happens when a value is unavailable. A gateway should not silently turn “bad quality” or “stale” into a fresh-looking number.

Decide where normalization happens. Small transformations such as unit conversion, deadbanding, and status mapping belong close to the source when they reduce bandwidth without hiding evidence. Business calculations and cross-site joins usually belong farther north where they can be governed and versioned.

Design the namespace before the topics

Use a stable hierarchy that names the site, area, line, cell, and asset before the individual metric. The hierarchy should be boring enough that a new consumer can predict where to subscribe. Define casing, separators, identifiers, units, and lifecycle rules. Do not let a vendor product name become the only description of a physical asset.

MQTT supplies transport semantics; Sparkplug B or an equally explicit contract supplies state and payload meaning. The unified namespace guide explains why the broker should not become an ungoverned database of arbitrary topics.

Buffering and quality

Size store-and-forward for the longest credible outage, not the average one. Define what happens when the buffer is full: oldest data dropped, newest data dropped, or the gateway raises a critical alarm. Preserve original timestamps and sequence information so downstream users can tell delayed data from live data. On reconnect, replay at a rate that does not starve live traffic.

Use explicit state for connected, stale, bad quality, and retired assets. Retained messages can advertise current state, but they should not be mistaken for a historical record. Set QoS per use case and test duplicate delivery, because “at least once” means consumers must be idempotent.

Security and operations

Keep the gateway in the intended OT zone, use mutually authenticated TLS where supported, and restrict outbound destinations. Patch and back up the configuration without copying credentials. Monitor CPU, disk, queue depth, clock drift, driver errors, reconnects, and the age of the newest source value. Assign one owner for the gateway and one owner for the namespace; otherwise both become nobody’s problem.

The MQTT QoS and sessions guide fills in the delivery details. For a systems-level view, Understanding the Shop Floor is a useful practical ebook companion.