· Manie Maritz
Updated
OPC-UA and MQTT in South African telemetry projects
When to use OPC-UA, MQTT, or the protocol already on the PLC — and where a gateway with buffering belongs when the link drops.
Telemetry projects fail when protocols are chosen for fashion instead of fit. OPC-UA and MQTT both have roles on South African plants — often together, and often next to Modbus or DNP3 that is already on the PLC. The link will drop. Design for that first.
OPC-UA where structure matters
OPC-UA fits when tags need a typed model — units, alarms, structured objects — and SCADA or a gateway will browse them instead of remapping Modbus registers on every change. Use certificate-based client/server on the plant network. Keep deterministic control in the PLC; OPC-UA is how the rest of the system reads the plant, not how the loop is closed.
MQTT where the wide-area link is the constraint
MQTT fits pub/sub over slow or intermittent links — pump stations, reservoirs and skids publishing to a broker, with QoS where delivery matters, TLS on the wire, and SCADA subscribing downstream. It is for monitoring and selected setpoints, not sub-second closed-loop control. Buffer on the gateway so a lost radio or SIM does not lose the last hours of tags.
A pattern that works
A practical pattern we often recommend:
- Keep deterministic control in the PLC
- Expose selected process data via OPC-UA, Modbus, DNP3 or the native PLC protocol already on site
- Use a gateway to poll those locally, buffer on link loss, then publish MQTT only across the wide-area link
- Land the data in SCADA for operations and alarms first; add historian storage when you need multi-site trending, long retention, or reporting the SCADA archive cannot carry
Security, buffering and store-and-forward matter more than the logo on the protocol slide. Design for link loss, not for perfect coverage.
This is the architecture behind our telemetry work, most often on water and wastewater and mining sites where the links are the hard part.