Modbus, OPC UA & EtherNet/IP in One Binary: Unifying Six Protocols
A modern plant doesn't run one protocol. It runs Modbus on the power meters, OPC UA on the newer PLCs, EtherNet/IP on the Allen-Bradley gear, S7 on the Siemens line, DNP3 on the SCADA outstations, and BACnet on the building automation. Reaching all of them used to mean six clients, six mental models, and six sets of edge-case bugs.
Voltrus Gateway puts all six behind a single gRPC API, driven by one Rust binary. This piece walks through what "unified" actually means in practice.
The Six Protocols, One Mental Model
Every protocol in the gateway answers the same questions the same way: how do I connect, how do I read, how do I write, how do I subscribe, how do I discover tags. The docs describe the five RPCs in full, but the shape is uniform:
| Protocol | Read | Write | Subscribe | Typical Port |
|---|---|---|---|---|
| Modbus TCP | ✓ | ✓ | ✓ (gateway-polled) | 502 |
| OPC UA | ✓ | ✓ | ✓ (native) | 4840 |
| EtherNet/IP (CIP) | ✓ | ✓ | ✓ | 44818 |
| Siemens S7 | ✓ | ✓ | ✓ | 102 |
| BACnet/IP | ✓ | ✓ | ✓ | 47808 |
| DNP3 | ✓ | ✓ | ✓ | 20000 |
For protocols with native subscriptions (OPC UA most prominently), the gateway bridges them straight through. For protocols without — Modbus, BACnet — the gateway runs the poll internally and streams only changes, so your client code looks identical either way.
The mt-* Engines
Each protocol is implemented in its own mt-* Rust crate: mt-modbus, mt-opcua, mt-enip, mt-s7, mt-dnp3, mt-bacnet. These are the same engines that power the Voltrus explorer apps. The gateway isn't a second implementation — it's the canonical one, exposed over gRPC.
mt-enip is fixed for the EtherNet/IP Explorer desktop app, for the gateway, and for anything else built on the engine. Protocol complexity lives in one place per protocol, audited and battle-tested by both surfaces.
Read / Write / Subscribe Parity
"Unified" only means something if the parity is real. Voltrus Gateway ships full read, write, and subscribe on all six protocols — not "read on most, write on a few." A holding-register write on Modbus, a tag write on OPC UA, and a coil write on a CIP controller all go through the same WriteTag RPC with a typed value. The gateway encodes the value correctly for the target protocol; your client doesn't know or care which one.
Discover, Don't Guess
Half the work in talking to a new device is figuring out what tags it actually exposes. Discover browses the device's tag namespace over the same gRPC surface — OPC UA's address space, a CIP controller's symbol table, an S7 CPU's data blocks — so you don't need a separate browsing tool to map out a PLC before you can read it.
What's Next: MQTT
An MQTT broker is on the roadmap, and it joins the same gRPC surface — publish and subscribe bridged into the unified tag model. The point of the architecture is that adding a protocol doesn't add a client; it adds a connect option.
Six Protocols, One Binary
Voltrus Gateway drives Modbus, OPC UA, EtherNet/IP, S7, DNP3, and BACnet behind one typed gRPC API. Cross-platform, self-hosted, one-time per host.
Explore Voltrus Gateway →The Bottom Line
Unifying six industrial protocols in one binary isn't a marketing claim — it's a consequence of sharing one set of mt-* engines behind one gRPC API. Read, write, subscribe, and discover are uniform across Modbus, OPC UA, EtherNet/IP, S7, DNP3, and BACnet. Protocol bugs get fixed once; your application code stays the same no matter which device it's talking to.