A protocol gateway is a hardware device that translates industrial communication protocols between two networks for example, converting Modbus RTU (Remote Terminal Unit) over RS-485 serial into Modbus TCP over Ethernet. The gateway receives data frames from one protocol, re-encodes them in the format required by the destination network, and forwards them in real time. No PC, no software license, and no modification to the connected equipment is required. The device operates autonomously at the network edge.
The problem it solves is one every plant engineer knows: equipment from different vendors, installed across different decades, speaking protocols that cannot talk to each other directly. A SCADA system that speaks Modbus TCP cannot read data from a PLC that only speaks Modbus RTU on RS-485 unless something in the middle translates. Protocol gateways are that translator.
This guide covers how protocol gateways work, how they differ from serial servers, the main gateway types available, and how to size and select the right unit for a given project.
How Does a Protocol Gateway Work?
A protocol gateway operates at the application layer of the network stack not just the physical layer. This is the key distinction that separates it from simpler devices like serial servers.
When a Modbus TCP master (typically a SCADA or HMI system) sends a read request, the gateway receives it on its Ethernet port, strips the TCP/IP headers, interprets the Modbus function code and register address, then re-issues the equivalent Modbus RTU query on its RS-485 serial port. The RTU slave responds, the gateway captures the serial response, wraps it back into a Modbus TCP frame, and sends it back to the SCADA system over Ethernet. From the SCADA's perspective, it is talking directly to a Modbus TCP device. From the PLC's perspective, it is receiving a standard serial Modbus request.
This translation happens in firmware on a purpose-built embedded processor. Latency from the conversion itself is typically under 5 ms, with total round-trip time determined primarily by serial baud rate and the slave's response time.
Three things happen inside every gateway transaction
- Parse - The gateway fully decodes the incoming frame according to the source protocol's specification, including address, function code, data, and error checking.
- Map - The gateway translates address space, data types, and timing rules from the source protocol to the destination protocol's requirements.
- Transmit - The gateway constructs a valid frame in the destination protocol and sends it, managing all timing, retry, and error handling according to that protocol's standard.
Protocol Gateway vs. Serial Server: What Is the Actual Difference?
This distinction matters in practice, and getting it wrong means buying the wrong product.
A serial server (also called a device server) extends the physical reach of a serial port over a network. It takes RS-232 or RS-485 traffic and tunnels it through a TCP connection. The data inside the tunnel is unchanged it is still a raw Modbus RTU frame, CRC and all. The receiving system must understand Modbus RTU natively to make use of it. A serial server changes the transport, not the protocol.
A protocol gateway changes the protocol itself. After the gateway processes the data, the receiving system sees a completely different protocol Modbus TCP, BACnet/IP, OPC UA, or whatever the destination requires. The source protocol is invisible to the receiving system.
According to Phoenix Contact's technical documentation, a serial device server connects serial-only devices to a local area network, while a gateway converts the protocol of one device to the protocol suitable for interoperability with another sometimes called a protocol converter.
| Characteristic | Serial Server | Protocol Gateway |
|---|---|---|
| Extends physical interface | ✓ | ✓ |
| Translates protocol at application layer | ✗ | ✓ |
| Destination system must understand source protocol | Yes | No |
| Typical use case | Extend RS-485 reach over LAN | Connect incompatible protocol ecosystems |
| Configuration complexity | Low | Medium |
| Cost | Lower | Higher |
| Choose when... | SCADA already supports the source protocol | SCADA and field devices speak different protocols |
The decision rule is simple: if the SCADA system natively supports Modbus RTU and you just need to extend the physical reach, a serial server is sufficient. If the SCADA speaks only Modbus TCP and the field devices speak only Modbus RTU, a protocol gateway is required.
Why Modbus RTU Still Exists Everywhere in 2025
Understanding why gateways are needed requires understanding the scale of the Modbus installed base.
Modbus was introduced in 1979 by Modicon (now Schneider Electric) and became the first widely adopted open industrial communication protocol. Because it was royalty-free and simple to implement, every major PLC, VFD, energy meter, and sensor manufacturer in the world built Modbus support into their products. Decades of equipment now exist in factories, substations, water treatment plants, and commercial buildings across Asia all communicating on Modbus RTU over RS-485.
According to the HMS Networks Annual Industrial Network Report 2025, Industrial Ethernet now accounts for 76% of newly installed nodes in factory automation globally. PROFINET leads at 27% and EtherNet/IP follows at 23%. However, the same report shows that fieldbus technologies which includes Modbus RTU still represent 17% of new nodes installed, and the Modbus TCP market alone was valued at USD 1.35 billion in 2024 with projections reaching USD 2.55 billion by 2032.
The critical insight is the difference between new installations and installed base. Engineers are not replacing Modbus equipment that works. A PLC installed in 2005 running production reliably has already been depreciated and continues operating with zero business justification for replacement. The only change is the need to connect it to a modern SCADA, EMS, or cloud platform and that is exactly what a protocol gateway enables.
What Types of Protocol Gateways Are Available?
Modbus Serial <-> Modbus TCP Gateway
The most common gateway type in Thai factories. Converts between Modbus RTU/ASCII on RS-232, RS-422, or RS-485 and Modbus TCP on Ethernet. The gateway presents itself as a Modbus TCP server to the SCADA system, while polling the serial field devices as a Modbus RTU master.
Products in this category include the Moxa MGate MB series: the MB3180 (1 serial port), MB3280 (2 serial ports), and MB3480 (4 serial ports). Each serial port on these gateways supports up to 31 RTU/ASCII slave devices, and the Ethernet side supports up to 16 simultaneous TCP master connections, meaning a single gateway can serve multiple SCADA systems or historians at once.
When to use: Any project connecting legacy PLC, VFD, or energy meter on RS-485 Modbus RTU to a modern SCADA, DCS, or EMS that communicates via Modbus TCP.
Multi-Protocol Gateway (Modbus <-> PROFIBUS / PROFINET / EtherNet/IP)
Converts between Modbus and the proprietary industrial Ethernet or fieldbus protocols used by major PLC vendors. For example, a Siemens S7 PLC communicating on PROFINET can read data from Modbus RTU field devices through a Modbus-to-PROFINET gateway, without any modification to either end.
When to use: Plants using Siemens TIA Portal, Rockwell Studio 5000, or similar environments that need to incorporate Modbus legacy devices without changing the PLC program's native communication protocol.
Modbus <-> DNP3 / IEC 60870-5-104 Gateway
Converts Modbus RTU from field devices into DNP3 or IEC 60870-5-104 the protocols used in utility SCADA for power, water, and gas systems. Required when a substation or treatment plant SCADA runs on utility standards but the field equipment uses Modbus.
When to use: Water treatment, power substations, remote pump stations, and any utility application where the control center SCADA uses DNP3 or IEC 60870 but field RTUs communicate over Modbus.
Modbus <-> BACnet Gateway
Converts Modbus RTU and TCP from HVAC controllers, energy meters, and building devices into BACnet/IP or BACnet MS/TP for use with Building Management Systems (BMS). BACnet (Building Automation and Control Network) is the dominant protocol in commercial building automation; Modbus remains common in the equipment underneath.
When to use: Commercial buildings, hotels, hospitals, and data centers where the BMS communicates in BACnet but chillers, AHUs, meters, or lighting controllers use Modbus.
IIoT Gateway (Modbus <-> MQTT / OPC UA)
Converts Modbus RTU data from field devices into MQTT or OPC UA (Unified Architecture) for cloud platforms and industrial data systems. This category enables legacy Modbus devices to send data directly to AWS IoT, Azure IoT Hub, or on-premises MES/ERP systems without replacing the devices.
When to use: Industry 4.0 projects, cloud-based energy monitoring dashboards, predictive maintenance platforms, and any use case requiring field device data in a modern IT/cloud architecture.
Key Terms Every Engineer Should Know Before Specifying a Gateway
Modbus RTU - The binary serial implementation of the Modbus protocol. Transmitted over RS-232, RS-422, or RS-485. Uses CRC-16 error detection. Efficient for serial communication due to minimal overhead. Maximum 247 device addresses per bus (Slave IDs 1–247).
Modbus TCP - Modbus encapsulated in TCP/IP packets for Ethernet transmission. Replaces CRC with TCP's own error management. Supports multiple simultaneous master connections. Standard port is 502.
RS-485 - A differential signaling physical layer standard for serial communication. Supports bus topology, distances up to 1,200 meters, and up to 32 unit loads per segment without repeaters (typically 32 devices). Commonly used 2-wire (half-duplex) or 4-wire (full-duplex) configurations.
Slave ID / Unit ID - The address that identifies a specific Modbus device on the bus, ranging from 1 to 247. Every device on the same RS-485 bus must have a unique Slave ID.
Auto Device Routing - A feature in some gateways, including the Moxa MGate series, that automatically builds routing tables by scanning the RS-485 bus. Eliminates manual Slave ID configuration for large deployments.
ADDC (Automatic Data Direction Control) - Hardware feature that automatically controls the RS-485 transmit/receive direction, eliminating the need for software-controlled RTS toggling. Standard in purpose-built industrial gateways.
How Many Serial Ports Does a Gateway Need for a Given Project?
The most common sizing error is counting devices when the correct unit to count is buses.
An RS-485 bus is a single continuous wiring segment. Every device physically wired to that segment shares one gateway serial port - regardless of how many devices are on it. Two buildings with 30 energy meters each, both wired on a single RS-485 run per building, require two serial ports total - not 60.
The correct approach is to count the number of independent RS-485 bus segments in the project, then add one serial port per segment.
| Model | Serial Ports | Max Serial Slaves (total) | Typical Application |
|---|---|---|---|
| MGate MB3180 | 1 | 31 | Single bus, one device group |
| MGate MB3280 | 2 | 62 (31 × 2) | Two separate bus zones, or RS-232 + RS-485 combined |
| MGate MB3480 | 4 | 124 (31 × 4) | Plant-wide, multiple zones, high-density installations |
For a factory with energy meters distributed across four production zones, each zone wired on its own RS-485 bus, the MB3480 covers the entire factory from a single DIN-rail unit. For a simple application with one serial instrument bus, the MB3180 is the appropriate choice.
A full comparison of these models - including decision criteria for specific scenarios - is available in the MB3180 vs MB3280 vs MB3480 Selector Guide.
Why Industrial Gateways Must Be Hardware, Not Software
The question arises increasingly as software-defined networking and cloud platforms mature. The answer lies in three fundamental requirements of industrial environments.
Determinism. SCADA polling must complete within a predictable time window. A general-purpose PC running Windows introduces variable OS scheduling latency sometimes milliseconds, sometimes hundreds of milliseconds. A dedicated gateway firmware processes requests in deterministic order with fixed timing, which is essential when polling dozens of devices on a defined scan cycle.
Reliability. A gateway running on a PC creates a dependency on the PC operating system updates, driver conflicts, hard drive failures, and reboot cycles all become failure modes for the process. A purpose-built gateway with no moving parts and embedded firmware has no equivalent vulnerabilities. The Moxa MGate MB3180 carries a published MTBF of 908,440 hours per Telcordia SR332 standards. The MB3480 is rated at 1,242,173 hours. Both carry a 5-year manufacturer warranty.
Environment. Industrial control panels are not office environments. The MGate MB series operates at 0 to 60°C, features IP30 metal housing, and provides 15 kV ESD protection on all serial signals. A 1.5 kV galvanic isolation barrier between the serial port and the Ethernet port prevents ground loops a common and destructive problem in plants with large motor loads.
Frequently Asked Questions
What is the difference between a protocol gateway and a PLC?
A PLC (Programmable Logic Controller) executes user-programmed logic, reads physical inputs, and drives physical outputs. A protocol gateway does none of this. It has no logic program, no I/O connections to physical signals, and makes no control decisions. It exists solely to translate data between two network protocols. A gateway is a passive translator; a PLC is an active controller.
Does adding a gateway slow down my Modbus communication?
Yes, by a small and predictable amount. The gateway adds one serial round-trip time per SCADA request: it must send the RTU query on the serial bus and wait for the slave to respond before returning the TCP response. At 9,600 baud with a 15-device bus, this adds approximately 20–50 ms per poll cycle. For SCADA applications polling on 1-second or longer intervals, this is insignificant.
Can multiple SCADA systems read from the same gateway simultaneously?
Yes. The Moxa MGate MB series supports up to 16 simultaneous TCP master connections per gateway unit. A SCADA server, a historian, and an HMI can all poll the same gateway at the same time and receive data from the same RS-485 slave devices without conflicts.
Does a protocol gateway store data if communication drops?
Standard Modbus gateways, including the MGate MB series, do not buffer data. If the Ethernet connection to the SCADA is interrupted, data from that period is not stored and cannot be recovered from the gateway. Data buffering and historical storage must be implemented at the SCADA historian level.
What happens if the gateway loses power?
All active communication stops. Most industrial gateways, including the MGate series, restore full operation within seconds of power being restored, using the configuration stored in non-volatile memory. No manual reconfiguration is required after a power cycle.
Can one gateway handle both RS-232 and RS-485 devices at the same time?
Yes, on multi-port models. Each serial port on the MGate MB3280 and MB3480 can be individually configured for RS-232, RS-422, or RS-485 operation and for independent baud rates. One port can run RS-232 at 115,200 bps for a local PLC while another runs RS-485 at 9,600 bps for a legacy meter bus.
Is a gateway suitable for safety-critical applications?
Standard Modbus gateways are not rated for functional safety (IEC 61508 / SIL) applications. For control loops where a communication failure could result in a safety incident, a dedicated safety-rated communication architecture is required. Gateways in safety environments are typically limited to monitoring and data acquisition, not control.