The short answer
Protocol Gateways
A protocol gateway is a device that speaks one protocol on one side and another on the other, holding a mapping table between them, so that a controller polling Modbus TCP can read a drive that speaks a serial protocol, or a DNP3 master can reach a Modbus RTU. It adds a device, a configuration, a delay, and a failure mode to every path it sits on, which is acceptable when no native interface exists and a poor choice when one does. Its mapping table is the document that matters, and its diagnostics are what tell you whether the data behind it is live.
Key points
- A gateway converts protocol and holds a mapping table. The table is the configuration and the documentation.
- Use one when there is no native interface. Do not use one to avoid buying the right card.
- Data through a gateway is only as fresh as the gateway poll. Watch the timestamp and the status.
- A gateway that keeps serving old data when its serial side dies is the classic hidden failure.
- One gateway per function, labeled, backed up, and on the network drawing.
What a gateway does
Control systems accumulate devices that speak different protocols: a controller on EtherNet/IP, drives on Modbus RTU, a power meter on Modbus TCP, an older RTU on DNP3 serial, a packaged system with a proprietary link. A gateway sits between two of them, polls or serves one side in its protocol, and presents the data on the other side in the other protocol, according to a table that says which register or point on one side corresponds to which on the other. The controller then sees the devices behind the gateway as if they spoke its protocol.
That convenience is real, and so is the cost. The gateway is a device that can fail, a configuration that must be maintained, a poll cycle that adds delay, and a place where a data value can go stale without anyone noticing. Every gateway in a system should be able to justify itself against the alternative of a native interface: a communication card in the controller, a device with the right protocol built in, or a SCADA driver that speaks to the device directly.
Common pairings
| From | To | Typical use | Note |
|---|---|---|---|
| Modbus TCP (controller or SCADA) | Modbus RTU (drives, meters, analyzers) | The most common gateway in a utility; a serial device bus made reachable from Ethernet | The unit ID on the TCP side selects the serial device; a serial device that stops answering must be reported, not cached |
| EtherNet/IP (controller) | Modbus TCP or RTU | A Rockwell controller reading Modbus devices without a Modbus-capable card | The gateway maps registers into an assembly the controller reads as I/O; data types must be aligned |
| DNP3 (SCADA master) | Modbus (RTU or devices) | A telemetry system standardized on DNP3 talking to Modbus devices at a site | The gateway supplies the DNP3 event and timestamp behavior the Modbus device cannot |
| OPC UA (SCADA or historian) | Any | A server that publishes many devices as one address space | Often software on a server rather than a hardware gateway |
| Serial (RS-232) to Ethernet | The same protocol, a different medium | A device serial console or a serial protocol carried over the network | A terminal server, not a protocol converter; the protocol is unchanged |
| Proprietary packaged system | Modbus TCP | A membrane skid or generator controller exposed to SCADA | The vendor supplies the gateway and the map; the utility owns a copy |
The mapping table
The configuration of a gateway is a table: on one side the device, the address, the register or point, the data type, and the poll rate; on the other side the register or point where that value is presented. Everything the controller reads through the gateway is one row of that table. The table is exported from the gateway, kept with the project documentation and the register maps of the devices behind it, and updated whenever a device or a point is added. A gateway whose table exists only inside the gateway is a gateway whose failure takes the documentation with it.
Delay and rate
A value read through a gateway goes through two polls: the gateway polls the device at its own rate, and the controller polls the gateway at its rate. The age of a value at the controller is up to the sum of the two intervals plus the response times. On a serial bus with a dozen drives at 9600 baud behind a gateway, the gateway cycle alone can be several seconds. That is fine for a drive current display and not fine for an interlock. Anything the controller acts on quickly does not belong behind a gateway, or the gateway and the poll rates are designed for it and the age is checked in the logic.
Selecting and installing one
- Match the protocols and the variants exactly: Modbus RTU with the framing the devices use, DNP3 with the level the master expects, EtherNet/IP with the assembly sizes the controller can read.
- Enough serial ports and enough capacity for the device count and the poll rates, with headroom.
- A diagnostic interface: a web page or a tool that shows each device, its status, its counters, and the last error. A gateway without diagnostics is a black box that will one day be the suspect in every communication problem.
- Status registers per device that the controller reads, so that a device failure behind the gateway is an alarm and its data is invalidated.
- Configuration export and import, so that the table is backed up and a replacement gateway is loaded from the file.
- Power from the panel DC supply on its own fuse, an Ethernet port on the control switch with its address on the network drawing, and a label with its name and its addresses.
- Firmware current, default credentials changed, and unused services disabled, because it is a network device with a web server.
When not to use one
A native interface exists on the controller for most protocols a utility meets: Modbus TCP is built into nearly every current controller, DNP3 into most RTUs and many controllers, EtherNet/IP and PROFINET into their families. A communication card costs more than a gateway and removes a device, a poll, a delay, and a failure mode; over the life of the system it is usually the better purchase. A gateway earns its place where the device protocol has no native option, where a legacy device bus must be reached from a new controller, or where a vendor package exposes its data only that way.
Frequently asked questions
- The controller reads good data from the gateway but the values never change. What is wrong?
- The gateway has lost the device and is serving cached values. Check the gateway diagnostics for the device, then configure the gateway to invalidate or flag data on device failure, and read that flag in the controller.
- Can one gateway serve two masters?
- Many can, within their connection limits, and it is common for SCADA and a controller to both read a gateway. Each master adds load to the Ethernet side but not to the serial side, which the gateway polls once. Writes from two masters to one device are a design problem the gateway does not solve.
- What is the difference between a gateway and a terminal server?
- A terminal server carries a serial protocol over Ethernet without changing it; the master still speaks the serial protocol, encapsulated. A gateway changes the protocol. A Modbus RTU device behind a terminal server is still polled as Modbus RTU over TCP; behind a gateway it is polled as Modbus TCP.
- How do I document a gateway?
- On the network drawing with its addresses and ports; in the project files with its exported configuration and the register maps of the devices behind it; on the I/O list as network points with the gateway as the path. A gateway that is not on the network drawing is the device nobody can find when it fails.
Related topics
- Modbus TCPModbus over Ethernet: what the MBAP header changes, why the CRC disappears, how the unit identifier works, and what does not get easier just because it is on Ethernet.
- Modbus RTUSerial Modbus over RS-485: function codes, register addressing, the off-by-one that catches everyone, and the physical layer details that decide whether a bus is stable.
- DNP3The protocol built for utility telemetry: master and outstation, static and event data classes, unsolicited reporting, time-stamped events, and why it suits slow links that Modbus does not.
- EtherNet/IPHow EtherNet/IP moves control data: CIP over standard Ethernet, implicit I/O connections on a requested packet interval, explicit messaging, producer and consumer tags, and what the network has to provide.
- How to Configure a Modbus ConnectionSet up a Modbus RTU or TCP link between a controller and a device: get the register map, match the physical and protocol settings, build the reads and writes, handle data types and the addressing offset, and verify with a protocol tool before trusting a value.
- Device Times OutA polled device that answers late or not at all: how to read the driver counters, tell a dead device from a slow one, and find the timeout setting, the bus loading, the radio latency, the duplicate address, or the device that is simply too busy to answer.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.