Multi-Protocol Industrial Gateway
Devices on different protocols all come in, and upper systems see one interface.
Bring OPC UA, Modbus, BACnet/IP, and MQTT devices into one point model, then read and control them through one MQTT interface.
Intermediate15minIndustrial Control & Automation
Reusable Site Templates
Sites where the data already exists but sits behind several different protocols.
Building energy roll-up
Office chiller rooms, mall switchrooms. Air handlers and meters become one feed.
HVAC retrofit
Older fan-coil systems in schools and hospitals. Keep the controller, add sensors, read one table.
Multi-vendor line integration
Workshops where PLCs and meters come from different makers. The gateway absorbs the protocol differences.
Not a fit: systems that require Sparkplug B, or certified safety control. Keep Modbus RTU production writes off until your adapter and controller pass commissioning.
How it works
The controllers and meters already installed connect to one gateway host (reComputer R1000 / R1100 Series, or reTerminal DM), which serves the system you already run.
Three things: the field devices that are already installed, one host that holds the point registry and both directions of traffic, and whoever consumes the result. The host is a plain Docker workload, so an existing Linux machine on the controller network is as valid a target as a purpose-bought gateway. Nothing leaves the site unless you switch on northbound publishing.
Field Devices
Nothing on the plant side is replaced. What changes is where the protocol differences get resolved.
| Field side | How it arrives | What you must have |
|---|---|---|
| OPC UA controller | An OPC UA endpoint reachable from the host | The endpoint address and its credentials |
| Modbus device | Modbus TCP on the local network, or Modbus RTU over a USB-to-RS-485 adapter | Unit id, register map, byte and word order |
| BACnet/IP equipment | The BACnet subnet reachable from the selected network interface | Broadcasts must reach that interface; BBMD boundaries and MS-TP are out of scope |
| MQTT source | An existing broker | Explicit topic-to-point mappings |
Discovery only proposes candidates. A user confirms each one before it becomes a managed point, and manual entry covers whatever discovery misses. Modbus RTU needs the serial-device deployment profile, and production writes stay off until your adapter and controller pass hardware-in-the-loop validation.
Data Hub Host
One box holds the point registry, the protocol adapters, the embedded MQTT broker, the northbound publisher and the web console. Any x86-64 or arm64 Docker host works.
| Requirement | |
|---|---|
| Runtime | Docker Engine 20.10 or newer |
| Disk | At least 4 GB free |
| Ports | 8280 (console) and 1883 (embedded broker) free, or pick other host ports before deploying |
| Network | Reachable from each protocol network; the remote Linux target uses host networking so BACnet/IP discovery reaches the physical subnet |
| Serial | Modbus RTU requires the serial-device profile |
| Registry ceiling | 2,000 points, of which 50 may be writable — enforced in code |
Three reference hosts run the same services: reComputer R1000 Series (RS-485, Ethernet), reComputer R1100 Series (adds RS-232, DI/DO, Gigabit Ethernet, CAN) and reTerminal DM Series (adds a 10.1-inch touch display for on-device setup).
Data Outputs
Local systems subscribe to the embedded MQTT broker and operators open the console in a browser, both on the data-hub host and neither needing internet. Northbound publishing to an external or cloud broker is opt-in and buffers to disk, so a broker outage queues samples instead of dropping them. Plain MQTT is telemetry-only; enable TLS and an authorised control identity before allowing remote commands. The data interface is listed under “What you get out of it” below.
How well it works
What the site engineer connects, watches and audits in the browser console once it is running.
Measured results
The design's capability boundary — not a site measurement.
The full chain has not yet been measured on the package hosts (reComputer R1000 / R1100 Series, reTerminal DM), so no figures are given here. Refresh-cycle and outage-backfill results measured against protocol simulators on developer hardware are in the engineering wiki.
The 2,000-point ceiling, 50 of them writable, is a design limit enforced in code, not a device limit. Size a site with your own load run on the chosen host, and keep Modbus RTU production writes off until your adapter and controller pass commissioning. For detailed benchmark records and outage backfill measurements, see Engineering Wiki · Industrial Protocol Gateway (available upon documentation release).
What you get out of it
Three interfaces, all on the data-hub host. Which ones you open decides whether anything leaves the site.
| Port / endpoint | Payload | Needs internet |
|---|---|---|
HTTP 8280 / | Browser console — source management, the point table, command receipts, plugin management | No |
MQTT 1883 missionpack/v1/{gateway}/points/{point_id} | Versioned point telemetry from the embedded broker, plus presence, command and receipt topics on the same contract | No |
MQTT 8883 missionpack/v1/{gateway}/telemetry | Northbound batched telemetry (QoS 1), with per-source health, last-will status and a heartbeat; each sample carries a source revision and a point revision | Yes, if the broker is off-site |
Each sample carries two revision numbers, so a consumer can tell a value change from a configuration change. Store-and-forward is on disk and needs the image tag named in the deployment guide. The contract is native MissionPack v1, not Sparkplug B.
Porting It to Your Own System
The reusable unit is not "industrial gateway" — it is the chain protocol adapter → confirmed point registry → one versioned MQTT contract → command receipt. Only the first link is bound to a specific protocol. Everything downstream of the registry carries over when a new protocol is added.
| Layer | What porting costs you |
|---|---|
| Point registry, revisions, quality model, 2,000/50 ceiling | reuse as-is |
| Discovery-proposes, user-confirms workflow | reuse as-is; a new adapter supplies the candidates |
| Embedded broker, MissionPack v1 topic contract, presence and receipts | reuse as-is |
| Northbound publisher and on-disk store-and-forward | reuse as-is |
| Browser console, source and point management | reuse as-is |
| Protocol adapter itself (transport, addressing, data types) | write a new one per protocol |
| Write semantics for that protocol (priority, release, readback) | define per protocol |
Same-shape sources fit: anything that exposes addressable values over a network or serial link, can be polled at a fixed interval, and reports enough for a quality judgement.
Where this shape does not fit
- Sparkplug B host applications. The contract is native MissionPack v1, and this release provides no translation layer.
- BACnet across a BBMD boundary or on MS-TP. Not implemented; discovery and reads depend on broadcasts reaching the selected interface.
- Sub-second control loops. This is a polling data hub with confirmed writes; fast closed loops belong in the controller.
How to deploy
Tell us about your site — we work out the hardware, then you connect the data and follow the steps.
Operation Mode
Where is the system operated from? This decides whether the host needs a screen, not what it can connect to.
Or compare them yourself: preset specificationsDeployment Guide · 15min →
| Setup | Role | Device | Qty |
|---|---|---|---|
| Multi-Protocol Data Hub | Data Hub Host | reComputer R1000 Series / reComputer R1100 Series / reTerminal DM Series(either one) | 1 |
One package. The hardware question is which host sits on the controller network; everything else is decided during commissioning.
| Package | Data hub host | What it deploys | Control on day one |
|---|---|---|---|
| Multi-Protocol Data Hub | reComputer R1000 Series, reComputer R1100 Series or reTerminal DM Series — or any x86-64 / arm64 Docker host on the controller network | Protocol adapters, the 2,000-point registry, embedded MQTT broker on 1883, northbound publisher, browser console on 8280, optional prediction plugin | Reads yes, writes with care — confirm permissions and data quality per point first, and keep Modbus RTU production writes disabled until hardware-in-the-loop validation |
The edge device is optional in the package: the local Docker target deploys onto the machine you are already using, and the remote target over SSH is what you use when the controller network is not reachable from your workstation. Docker Desktop's bridged local target may need manual BACnet addressing, because BACnet/IP broadcast discovery does not reliably cross that bridge.
Difficulty is rated intermediate; the estimate is 15 minutes to a running console. Bringing the first controller in — discovery, confirming candidates, verifying quality, then granting write access — takes longer and is what decides whether the deployment is trustworthy.
FAQ
OPC UA, Modbus TCP and RTU, BACnet/IP, and MQTT as a source. BACnet COV subscription, BBMD / Foreign-Device registration and MS-TP are not implemented. Modbus RTU needs the serial-device deployment profile.
No. It uses the native MissionPack v1 contract, so a Sparkplug host application needs a translation step. Each sample carries a source revision and a point revision, which lets a consumer tell a value change from a configuration change.
Northbound publishing spools to disk and replays after reconnect, so readings queue instead of dropping. Use a persistent broker with a durable subscriber session if every replayed reading must arrive. This path needs the image tag named in the deployment guide.
The registry ceiling is 2,000 points with 50 writable, enforced in code. That is a design limit, not a measured device ceiling. Run your own load test on the chosen host before sizing a site.
No. A Linux machine you already have on the controller network is a supported target. The reference hosts differ in on-board interfaces — R1000 Series RS-485 and Ethernet, R1100 Series adds RS-232, DI/DO and CAN, reTerminal DM adds a touch display.
Both. Writes pass permission and data-quality checks and are traceable through the effective value, the device readback and the command receipt. Remote commands need TLS and an authorised control identity, and Modbus RTU production writes stay off until hardware-in-the-loop validation.
Almost always the network interface — BACnet/IP discovery is broadcast-based, so the host needs an interface on the BACnet subnet. Docker Desktop's bridged local target may not pass those broadcasts. In that case enter the BACnet addresses manually.
Didn't find your answer?
Contact Us
We Are Glad to Be Your Hardware Partner !