Can a modern RTU run the same logic as a PLC?

Yes, in most current-generation hardware. Many RTUs support the same IEC 61131-3 languages (ladder logic, structured text, function block diagram) as a PLC and can run local interlocks or sequencing at the remote site. What still distinguishes them is the communications and power architecture built around that logic engine, not whether logic execution is possible at all.

Is DNP3 the protocol that makes something an RTU?

DNP3 (and to a lesser extent Modbus RTU over serial/radio) is strongly associated with RTU applications because it was designed for exactly this problem — polled, wide-area telemetry with time-stamped events and unsolicited reporting. But protocol support alone doesn't define the category; plenty of PLCs now speak DNP3 as well. The protocol is a symptom of the wide-area design center, not the defining feature itself.

Why do RTUs often run on solar power when PLCs almost never do?

Because of where each is typically deployed. PLCs live in powered facilities — plants, pump houses, control panels with utility power already present. RTUs are frequently installed at unmanned remote sites (wellheads, pipeline valve stations, remote tank farms) with no utility power nearby, so solar-plus-battery becomes the default, which in turn drives the RTU's low-power sampling and reporting design.

Does "hybrid RTU/PLC" hardware mean the distinction no longer matters?

It means the product category and the design distinction have partly decoupled, not that the distinction is meaningless. Even hybrid hardware still has to be configured toward one design center or the other for a given installation — fast deterministic local scanning for a plant, or buffered wide-area telemetry for a remote site. Understanding both design centers is exactly what lets an engineer configure hybrid hardware correctly for either role.

In the Purdue model, where do RTUs and PLCs sit?

Both typically sit at Level 1 (basic control) or Level 0/1 boundary, directly interfacing field instruments and actuators. The difference shows up in what sits between them and Level 2/3 — a PLC usually connects over a fast local plant network directly into the control room, while an RTU usually connects over a wide-area communications link to a master station that may itself be aggregating dozens of remote RTU sites before that data reaches the SCADA server.

← SCADA & Industrial Controls Studio

Concept Explainer · SCADA

RTU vs. PLC

Two controllers that both read inputs and drive outputs — but were originally built to solve opposite problems: staying alive on a low-bandwidth link 200 km from anyone, versus finishing a deterministic logic scan in milliseconds on a factory floor.

Ask most people what the difference is between an RTU (remote terminal unit) and a PLC (programmable logic controller) and you'll usually get "an RTU is a smaller or cheaper PLC." That's not it. Both devices read field I/O and can execute logic, and modern hardware increasingly does both jobs in one chassis — which is exactly why the distinction gets muddled. The real difference is what each was originally designed around. A PLC was designed around a deterministic scan cycle driving local, hardwired I/O in real time. An RTU was designed around surviving a low-bandwidth, high-latency, sometimes-unreliable wide-area link back to a master station — buffering data, conserving power, and reporting in on a schedule. Same building blocks, opposite design center.