A remote wellsite spends most of its life out of touch. Radios drop, cellular coverage flickers, and the SCADA host cannot be counted on to be reachable every second of every day. That reality is the reason the wellhead RTU runs its own control logic instead of waiting for instructions from the control room. This guide draws the line between local control that lives in the RTU and supervisory control that comes from the host, and explains what the well does when the link between them goes silent.
RTU Local Control in one line: RTU local control means the well's real-time logic - the pump-off cycle, plunger timing, shut-in trips - runs in the RTU at the wellhead itself, so the well keeps operating with no host connection. Supervisory control is the higher layer where a SCADA host sends setpoints, targets, and start/stop commands to the RTU. Local control decides moment to moment; supervisory control adjusts the rules the RTU follows.
Local control is edge logic: it executes inside the RTU, on the RTU's own clock, using the RTU's own I/O. A plunger-lift routine timing the fall and rise of the plunger, a pump-off controller reading the dynamometer card and cycling the unit, a high-pressure shut-in that closes a valve when flow-line pressure exceeds a limit - these are decisions that must happen in real time and cannot tolerate a round trip to a distant server. Because the logic and the measurements it depends on are in the same box a few feet from the wellhead, the response is immediate and does not depend on any network being up.
Supervisory control operates on a slower, human timescale. From the SCADA host an engineer pushes the numbers the local logic uses - the pump-off fillage setpoint, the plunger arrival window, a shut-in pressure limit, a runtime target - and issues occasional discrete commands like start, stop, or reset. The host does not stroke the pump or trip the valve itself; it hands the RTU the rules and lets the RTU enforce them. This division is deliberate: the host is authoritative over what the well should be trying to do, and the RTU is authoritative over doing it correctly every moment, whether or not the host is watching.
The test of a good field design is what the well does when the link fails, and the intended answer is: nothing dramatic. Because the control logic is local, a comms outage does not stop the well from being controlled. The RTU keeps running the pump-off cycle, keeps timing the plunger, keeps honoring its shut-in limits, and holds the last setpoints the host gave it. It buffers its data - trends, events, alarms - in onboard memory so the record is intact, then uploads the backlog when the link returns. From the well's point of view, losing the host is a reporting outage, not a control outage.
Contrast that with a design that leaned on the host for real-time decisions. If the actual stroking or valve logic lived on a central server and the RTU were only a dumb I/O concentrator, a comms loss would leave the well without a controller - forced to a fixed fail-safe state, or worse, uncontrolled until someone drives out. That is why field practice keeps the safety-critical and production-critical logic at the edge and treats fail-safe behavior as a deliberate choice: on a genuine fault the RTU can hold the last valve state, or de-energize an actuator to close a safety valve, depending on what the specific loop requires. Local control is what lets an unmanned well behave sensibly through the outages that are certain to happen.
Moving the supervisory layer to the cloud does not change where the real-time logic belongs - it stays in the RTU - but it changes how the supervisory relationship is delivered. With a cloud SCADA platform such as Merobix, the host that pushes setpoints and reads back data is a service reachable over the internet rather than a server in a control room. The RTU still runs the well autonomously; the cloud is the place an engineer adjusts the fillage setpoint, changes a plunger window, or issues a shut-in, and the place every well's live state and history are gathered. The autonomy at the edge and the reach of the supervisory tier are complementary, not competing.
This split is exactly why cloud supervision is safe for remote wells. Because the RTU holds its logic and its last setpoints locally, an interruption in the cloud connection - or in the operator's internet - never leaves a well uncontrolled; it only delays the reporting and the next supervisory adjustment. When the connection recovers, buffered data flows up and any new setpoints flow down. The operator gets a single, always-current view of a whole field and the ability to retune any well from anywhere, while each well retains the local intelligence to keep producing and stay safe on its own between those adjustments.
Yes, when it is properly designed. The real-time control logic - pump-off cycling, plunger timing, shut-in trips - runs locally in the RTU, so it keeps controlling the well on its own during a comms outage. It holds the last setpoints the host provided and buffers data in onboard memory, then uploads the backlog when the link returns. Losing the host is a reporting gap, not a control gap.
Local control is the moment-to-moment logic executing inside the RTU using its own I/O, deciding when to cycle the pump or trip a valve in real time. Supervisory control is the higher layer where a SCADA host sends setpoints, targets, and occasional start/stop commands. The host defines what the well should try to do; the RTU is responsible for doing it correctly every instant, with or without the host connected.
It depends on the loop. For many production functions the RTU holds its last valid state and last setpoints so the well keeps running as it was. For safety functions the design is deliberately fail-safe - for example de-energizing an actuator so a surface safety valve closes when the RTU detects a fault. Which behavior applies to each output is an engineering decision made when the site logic is configured.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.