For a remote monitoring project, the choice of edge gateway vs PLC vs RTU comes down to one question first: do you need to control a process or only to observe and transport its data? A PLC is a deterministic controller built to close loops in milliseconds, an RTU is a ruggedized field unit built to acquire and telemeter data over long distances, and an edge gateway is a protocol-and-network bridge built to normalize field data and push it to MQTT, a SCADA historian, or the cloud. The three overlap at the edges, and on many sites the right answer is a combination rather than a single box.
This guide breaks down each device by primary purpose, protocol support, processing capability, connectivity, power, environment, and cost, then gives you a decision matrix and clear rules for when each one wins.
What Each Device Is Actually For
PLC (Programmable Logic Controller)
A PLC is a hardened industrial computer whose entire design centers on a deterministic scan cycle: read inputs, execute logic, write outputs, repeat. Scan times of 1 to 10 ms are typical, which is why PLCs run interlocks, motor sequencing, PID loops, and safety-adjacent logic. They are programmed in IEC 61131-3 languages (Ladder, Structured Text, Function Block) and expose digital and analog I/O directly to field wiring. A PLC can publish data upstream (many now speak Modbus TCP, EtherNet/IP, PROFINET, and even OPC-UA), but transport is a secondary job bolted onto a control-first device.
RTU (Remote Terminal Unit)
An RTU is purpose-built for geographically dispersed telemetry: oil and gas wellheads, water and wastewater lift stations, pipeline cathodic protection, electrical substations. Its strengths are wide operating temperature, low power draw (often solar or battery friendly), local data buffering when the link drops, and native telemetry protocols such as DNP3 and IEC 60870-5-101/104. Many modern RTUs include modest PLC-style logic, so the line between RTU and PLC has blurred, but an RTU prioritizes reliable acquisition and store-and-forward over fast control.
Edge Gateway (Industrial IoT Gateway)
An edge gateway does not control anything. It connects to existing field devices (PLCs, meters, sensors, RTUs), reads their registers, optionally runs edge logic such as filtering, scaling, alarming, or analytics, and republishes the data to an upstream system over MQTT, REST, or OPC-UA. The classic job is bridging serial Modbus RTU on RS-485 to Modbus TCP or MQTT over Ethernet or cellular. SURIOTA’s SRT-MGATE-1210 Modbus-to-MQTT gateway is this category of device: it polls Modbus RTU and Modbus TCP slaves and publishes structured payloads to an MQTT broker, which is exactly what you want when the field already has controllers and meters but no clean path to the cloud. If you are weighing the two serial transports, see our breakdown of Modbus RTU vs Modbus TCP.
Decision Matrix: Edge Gateway vs PLC vs RTU
| Dimension | Edge Gateway | PLC | RTU |
|---|---|---|---|
| Primary purpose | Protocol bridge and data transport | Deterministic real-time control | Remote telemetry and acquisition |
| Control vs telemetry | Telemetry only (no closed-loop) | Control first, telemetry second | Telemetry first, light control |
| Typical cycle/latency | Poll interval 100 ms to seconds | Scan 1 to 10 ms, hard real-time | Acquisition seconds to minutes |
| Native protocols | Modbus, MQTT, OPC-UA, REST/HTTP | Modbus, EtherNet/IP, PROFINET, OPC-UA | DNP3, IEC 60870-5-101/104, Modbus |
| Edge compute | High (Linux, containers, scripts, ML) | Low to moderate (control logic only) | Low (buffering, basic logic) |
| I/O wiring | None or minimal; reads other devices | Rich DI/DO/AI/AO, expandable racks | Moderate field I/O |
| Connectivity | Ethernet, Wi-Fi, 4G/5G cellular | Ethernet, fieldbus | Cellular, radio, satellite, serial |
| Power profile | Low (5 to 24 VDC) | Moderate to high (24 VDC) | Very low; solar/battery friendly |
| Environment | Panel/DIN, often -20 to +60 C | Panel/DIN, industrial range | Wide temp, outdoor, hazardous-rated |
| Relative cost | $ low to moderate | $$ moderate to high | $$$ high (ruggedized, certified) |
How to Decide
Choose a PLC when you must close a loop
If the device has to make a control decision faster than a human or a network round-trip can react (stop a pump on high pressure, sequence a conveyor, run a PID temperature loop, drive a safety interlock), you need the deterministic scan and direct I/O of a PLC. Cloud or MQTT latency is irrelevant to a hard real-time loop, so transport-only devices cannot do this job. PLC selection and integration sit at the core of our industrial engineering and automation practice.
Choose an RTU when the site is remote, harsh, and power-constrained
For a wellhead 40 km from the nearest cabinet, a substation requiring DNP3, or a solar-powered lift station, an RTU’s wide temperature range, low power draw, store-and-forward buffering, and native telemetry protocols are decisive. A consumer-grade gateway will not survive the environment, and a PLC is overkill for slow acquisition that mostly just needs to reach a control center reliably over radio or cellular.
Choose an edge gateway when the field already works and you only need data out
This is the most common modern scenario. The PLCs, energy meters, and sensors are already running; what is missing is a clean, secure path from RS-485 or Modbus TCP to a broker, historian, or analytics platform. An edge gateway reads those existing registers and republishes them without touching the control layer, which means zero risk to the running process. If you are mapping holding versus input registers before configuring polls, our guide on Modbus register mapping covers the addressing details, and our Internet of Things services cover the end-to-end pipeline.
The Most Common Answer: A Combination
On real sites these devices are layered, not mutually exclusive. A typical architecture looks like this:
- PLC handles all control logic and direct I/O on the machine or skid.
- RTU covers any geographically remote outstation that needs ruggedized, low-power telemetry over cellular or radio.
- Edge gateway sits beside the PLC or meter bank, polls their Modbus registers, performs edge scaling and alarming, and publishes to MQTT for dashboards, historians, and the cloud.
A practical example: a plant has three PLC-controlled production lines plus a row of PM1611-WD energy meters on RS-485. The PLCs keep running the process untouched. An SRT-MGATE-1210 polls the PLCs over Modbus TCP and the meters over Modbus RTU, then publishes a structured JSON payload per topic to the broker. To design that MQTT layer well (topic hierarchy, QoS levels, retained messages), see our notes on MQTT topics and QoS for industrial IoT and the full Modbus RTU to MQTT gateway guide.
Quick selection logic
- Does it need fast, deterministic control? Yes, PLC.
- Is the site remote, off-grid, or hazardous-rated, needing DNP3/IEC 60870? Yes, RTU.
- Does the field already control itself and you only need data normalized and shipped upstream? Yes, edge gateway.
- Most plants need two or all three working together.
Frequently Asked Questions
Can an edge gateway replace a PLC?
No. An edge gateway has no deterministic scan cycle and is not designed to drive outputs in hard real time, so it cannot run interlocks, PID loops, or safety logic. It complements a PLC by reading its registers and transporting data upstream, leaving the control layer untouched.
What is the difference between an RTU and a PLC?
A PLC is optimized for fast, deterministic control with rich local I/O, usually inside a panel. An RTU is optimized for remote telemetry: wide temperature range, low power, store-and-forward buffering, and protocols like DNP3 or IEC 60870-5-104. Modern devices blur the line, but the design priority (control vs reliable remote acquisition) is the real distinction.
Do I need a gateway if my PLC already supports MQTT?
Sometimes not. If a single modern PLC natively publishes clean MQTT, you may not need a separate box. But a dedicated gateway is still useful when you have mixed legacy serial devices, multiple vendors, energy meters, or want to keep transport and analytics off the control CPU so a network issue never affects the running process.
Which device is cheapest for a simple remote monitoring job?
For monitoring only, an edge gateway is usually the lowest-cost option because it carries no expensive rugged certifications or large I/O racks. A ruggedized, certified RTU is typically the most expensive due to its environmental and protocol requirements, while a PLC sits in between but is hard to justify if you are not controlling anything.