OPC UA, MQTT and Modbus, implemented properly.

Protocols are a means, not a goal

Nobody sets out to implement MQTT. They set out to see what a machine is doing from somewhere that is not next to the machine. The protocol work is what stands between those two states, and doing it badly produces a system that technically transfers data while remaining difficult to extend and impossible to trust.

We have written a detailed comparison of the three protocols you are most likely to encounter in OPC UA vs MQTT vs Modbus. This page is about the implementation work itself.

What we implement

• Modbus, RTU and TCP, as client or server, including recovering undocumented register maps from equipment whose manual has been lost or was never accurate.
• OPC UA, client and server, including information modelling so your data is browsable and typed rather than a flat list, and certificate handling that your team can actually operate.
• MQTT, including topic namespace design, quality-of-service selection, retained messages, last will handling and broker architecture.
• Sparkplug B, where multiple systems or vendors publish to a shared broker and a common convention is needed.
• Translation between them, which is the most common request: reading Modbus or OPC UA at the machine and publishing MQTT northbound.
• Serial and vendor protocols, where equipment speaks something proprietary and documentation is partial.

The parts that decide whether it works

Behaviour when things fail

A protocol implementation is easy to write for the case where everything is connected. What separates a system that survives a year in production is what it does when a device stops responding, when the network drops, when the broker restarts, or when a buffer fills. Those behaviours should be decided deliberately and tested by causing them, not discovered.

The data model

Whether it is an OPC UA address space or an MQTT topic namespace, the structure you choose will be depended upon by every consumer that follows. A structure that describes physical location survives; one that encodes wiring, vendor names or IP addresses breaks the first time anything is replaced.

Rate and volume

Polling faster than a value changes costs bus time, bandwidth and storage without producing information. Publishing on change with a heartbeat routinely reduces volume by an order of magnitude on slow-moving industrial signals, and on metered connections that is directly a monthly cost.

Security that is actually enabled

OPC UA supports certificates and encryption; MQTT supports TLS and access control. Both are regularly deployed with those features switched off because it made commissioning easier. We treat the secure configuration as part of the deliverable rather than as a later hardening exercise.

How we help

• Assessment. What each device exposes, what upstream expects, and where translation should happen.
• Gateway development. Firmware and software for acquisition, buffering, translation and publishing, on hardware suited to the environment.
• Register map recovery. Establishing empirically what undocumented registers contain, including scaling, signedness and word order, verified against values you can independently confirm.
• Namespace and model design. A structure that will still make sense when the estate has doubled.
• Broker architecture. Local, cloud or both, with a considered position on persistence, access control and what happens during an outage.
• Commissioning and testing. Including deliberately interrupting connections to confirm the system behaves as designed.

What you receive

The implementation and its source, the documented data model and mapping, the security configuration, and test evidence covering the failure behaviours that were specified.