Retrofitting Legacy PLCs with MQTT: A Practical Field Guide

The biggest misconception in industrial IIoT is that you need new PLCs to participate. The reality is that most factories run controllers that are 10-25 years old — Siemens S7-300/400, Allen-Bradley SLC 500, Mitsubishi FX series, Modicon Quantum — and they work perfectly fine for control. Replacing them just to get MQTT connectivity is expensive, risky, and unnecessary. The right approach is a protocol gateway that reads data from the existing PLC and publishes it over MQTT without modifying the control program. This post covers the exact hardware, software, and configuration patterns we use in the field.

The Gateway Architecture

The core concept is simple: a small industrial PC or dedicated gateway device sits on the same network as the legacy PLC. It runs a protocol driver (Modbus TCP/RTU, S7 Ethernet, EtherNet/IP CIP) that polls the PLC for data at a configurable interval. The driver extracts raw register values, applies scaling and engineering unit conversions, and publishes the results as MQTT messages to a broker. The PLC control program is not modified. The PLC does not even know the gateway exists — it simply responds to read requests as it always has. This is a passive, non-invasive integration that carries zero risk to the running process.

Hardware Selection

For small deployments (1-2 PLCs, fewer than 100 data points), a Raspberry Pi 4 with an industrial HAT (Hardware Attached on Top) for serial communication is sufficient and costs under 200 dollars. For production environments, we recommend industrial-grade gateways: HMS Anybus X-gateway, Softing edgeConnector, Kepware Edge, or a fanless x86 PC running Linux. The key requirements are: DIN-rail mountable, 24VDC power supply, operating temperature range of 0-60 degrees Celsius, and no moving parts (fanless). Avoid consumer hardware — it will fail in a factory environment within months.

Protocol Drivers: Talking to Legacy PLCs

Each PLC family has its own communication protocol. The gateway needs a driver that speaks the native protocol of the target PLC. For Siemens S7-300/400, the S7 Ethernet protocol (RFC 1006) provides direct access to data blocks, inputs, outputs, and markers. For Allen-Bradley, EtherNet/IP CIP read services access tags in the controller. For Modbus-based PLCs (Modicon, many Chinese PLCs), Modbus TCP or Modbus RTU over serial provides register-level access. Open-source libraries like libplctag (Allen-Bradley), nodes7 (Siemens), and pymodbus (Modbus) handle the protocol details. The gateway polls the PLC at a configurable rate — typically 100ms to 5s depending on the data type — and caches the latest values.

MQTT Publishing Strategy

How you structure MQTT topics matters for downstream consumers. The recommended pattern is hierarchical: site/area/line/device/signal. For example, plant1/packaging/filler01/motor/current publishes the filler motor current. Use JSON payloads with a consistent schema: timestamp, value, quality (good/bad/uncertain), and unit. Publish on change (deadband-based) rather than on interval — this dramatically reduces broker load and network bandwidth. A temperature that changes by 0.1 degrees every second does not need to publish 10 messages; it should only publish when the change exceeds a configurable threshold (e.g., 0.5 degrees).

Data Mapping and Scaling

Raw PLC register values are integers — a temperature might be stored as 2345 representing 23.45 degrees Celsius. The gateway must apply scaling (multiply by 0.01), offset, and engineering unit conversion before publishing. This mapping is configured in the gateway's data model, not in the PLC. The gateway also handles data type conversions: a 32-bit float stored in two consecutive Modbus registers needs to be reassembled and byte-swapped. Getting this wrong is the most common source of incorrect data in IIoT deployments — always validate scaled values against the HMI display before trusting the MQTT output.

Security Considerations

The gateway adds a new network device between the PLC and the enterprise. It must be segmented properly: the PLC-facing interface connects to the OT network, the MQTT-facing interface connects to the IT network or DMZ. Use MQTT over TLS (port 8883) with mutual authentication. The gateway should support certificate-based authentication to the broker — username/password is acceptable for initial deployments but should be replaced with X.509 certificates for production. Firewall rules should allow only outbound MQTT connections from the gateway to the broker — never inbound connections from the IT network to the OT network.

Deployment Checklist

• Inventory all legacy PLCs — model, protocol, IP address, data points to expose.
• Select gateway hardware appropriate for the environment (temperature, vibration, power).
• Define the MQTT topic hierarchy and payload schema before configuring the gateway.
• Map PLC registers to MQTT topics with proper scaling and engineering units.
• Validate every data point against the HMI before going live.
• Implement TLS and certificate-based authentication to the MQTT broker.
• Segment the gateway between OT and IT networks with strict firewall rules.
• Document the mapping for future maintenance — the engineer who replaces you will need it.

Retrofitting legacy PLCs with MQTT is one of the highest-value, lowest-risk IIoT projects you can undertake. It requires no changes to the control program, no production downtime, and delivers immediate visibility into processes that were previously data deserts. Start with one machine, prove the value, then scale across the plant.