Designing a multi-protocol gateway for brownfield industrial sites

Brownfield industrial sites do not hand you a clean protocol. A single renewable-energy site can have inverters speaking Modbus RTU over RS-485, meters speaking DL/T 698, a grid uplink that wants IEC 60870-5-104, and a cloud platform expecting MQTT. The gateway in the middle has to make all of them coexist, on hardware that may sit in a field cabinet for a decade. These are the design decisions that decide whether it ages well.

One internal model, many protocol adapters

The mistake that does not scale is writing per-device parsing into the forwarding path, so that every new inverter brand becomes a copy-paste change with its own regression risk. The design that scales puts a protocol adaptation layer in front of a single normalized internal model. Each protocol (Modbus RTU and TCP, IEC-104, DL/T 645/698, vendor APIs) is a driver that maps into the same data points, and everything downstream reads that one model. Adding a brand becomes a new driver, not a new fork of the whole firmware.

Address planning is the hidden work

The protocols are the easy part. The work nobody budgets for is address management. On a shared RS-485 bus you have to allocate device addresses without collisions and read registers in batches that respect each device's quirks, because some devices stop responding when you ask for too many registers in one request. On an IEC-104 uplink you have to plan the Information Object Address space across a site that might carry dozens of inverters, so the SCADA side gets a stable, documented map rather than a moving target. Get this wrong and the symptoms look like flaky devices rather than what they are: an addressing problem.

Filter at the gateway, not in the cloud

A site can produce a few hundred measurement points per device, and most of them are diagnostic noise that nobody graphs. Forwarding all of it inflates cloud-compute and bandwidth cost for no benefit. The gateway should let you select which points each device forwards, set the forwarding frequency, and override those rules per device. Pushing that decision to the edge keeps the data volume proportional to what the platform actually uses.

Why control decisions live at the edge

There is a hard reason the gateway cannot be a thin pipe to the cloud. Real-time control loops, the kind that adjust setpoints on a sub-second cadence, cannot tolerate a cloud round-trip, and cloud APIs often rate-limit reads to a level that makes fast control impossible anyway. Anything time-critical has to run on the gateway, with the cloud orchestrating rather than commanding. Designing as if the cloud were always reachable and fast is how you build a system that fails exactly when the grid needs it most.

Auto-identification cuts commissioning

Field commissioning is expensive because someone has to be on site. A gateway that identifies devices on power-up, by reading a serial number or model register and loading the matching point map, lets a technician swap an inverter brand without re-flashing or hand-configuring anything. The device announces what it is, and the gateway adapts. That single capability removes a category of truck rolls.

The physical layer still bites you

None of the protocol work matters if the RS-485 wiring is wrong. Terminal resistance, hand-to-hand bus topology rather than a star, and isolation against ground loops are the difference between a bus that reads cleanly and one that throws intermittent CRC errors you will spend a week chasing. The gateway design has to assume a noisy electrical environment, because the field is one.

Where AgentKick fits

We design and build edge gateways and the firmware that runs them, for sites where multiple legacy protocols, real-time control, and a decade of field life all have to hold together. If you are consolidating a fragmented device fleet onto one platform, that is the work we do, typically as a short scoping engagement into a phased build.