How to Verify Plunger Lift Cycle Telemetry in SCADA
Monitoring a plunger-lift well remotely only works if the SCADA faithfully reflects what the well and controller are actually doing, and the plunger cycle has several moving parts to get right: valve state, arrivals, and pressures all changing through each cycle. This procedure verifies that the plunger-lift cycle telemetry in SCADA is trustworthy: it confirms the reported valve state matches the controller, that arrivals are counted correctly, and that the pressures tell a coherent cycle story. It is done after the individual sensors are verified, to prove the remote picture as a whole.
Verify Plunger Cycle Telemetry in one line: To verify plunger lift cycle telemetry in SCADA, confirm the reported valve open and closed state matches what the controller and well are actually doing, that arrival events are counted and timestamped correctly against real arrivals, and that casing and tubing pressures move through each cycle in the expected pattern - casing building while shut in, drawing down while open. Check the whole cycle tells a coherent story remotely. Telemetry that shows an impossible cycle or lags the real well must be corrected before it is trusted for monitoring.
Confirm Valve State and Arrivals Are Reported Correctly
The backbone of plunger-lift telemetry is the well's open and closed state, so confirm the SCADA reports it correctly. When the controller opens the well, the SCADA should show open within a sensible time, and likewise for closing. Compare the reported state against the controller's actual state and the well's behavior; a SCADA that shows the well open when it is closed, or lags the real transitions badly, will mislead anyone watching remotely and must be reconciled before the telemetry is trusted.
Verify arrival events are captured and counted correctly. Each genuine plunger arrival should register as an arrival in the SCADA with a sensible timestamp, and the arrival count should match the real number of arrivals over a period. A SCADA missing arrivals or logging phantom ones has an arrival telemetry problem that undermines any remote diagnosis of the well. Confirming the arrival record matches reality is essential because arrivals are how you judge whether the well is cycling healthily.
Check that non-arrivals and missed cycles show up in the telemetry too. A well that failed to arrive should be visible remotely as a non-arrival event, not silently absent from the record. Confirming that both successful and failed arrivals are faithfully reported gives you a complete remote picture, and it connects to how the controller applies logic like adjust-on-arrival control, which itself depends on accurate arrival data.
Verify the Pressures Move With the Cycle
A plunger-lift well has a characteristic pressure signature through its cycle, and the telemetry should show it. While the well is shut in, casing pressure builds as gas accumulates; when the well opens, the casing pressure drives the plunger and liquid up and then draws down as the well produces. Confirm the telemetered casing and tubing pressures move through this pattern in step with the valve state. Pressures that do not respond to the open and close transitions are stale, mis-scaled, or disconnected from the cycle.
Confirm the timing lines up. The pressure changes should coincide with the valve transitions and arrivals in a way that makes physical sense - casing pressure peaking near the end of the shut-in, drawing down after opening, the plunger arriving during the open period. If the telemetered pressures and events do not line up in time, either a timestamp or a polling issue is smearing the cycle, and the remote picture will not match reality. Coherent timing across the signals is what makes the telemetry usable.
Read the whole cycle as a story. When the valve state, the arrivals, and the pressures all move together in the pattern a plunger-lift cycle should follow, the telemetry is coherent and trustworthy. When one signal contradicts the others - pressures building while the well reads open, or an arrival with no pressure response - something in the telemetry is wrong. This whole-cycle coherence check catches problems that verifying any single tag would miss, and it rests on solid trending in SCADA.
Check for Lag and Stale Data
Remote telemetry can be correct in value but wrong in time. Confirm the SCADA updates the cycle signals promptly enough to represent the well, so a valve transition or an arrival shows up without excessive delay. A polling interval that is too slow relative to the cycle can miss short events or blur the sequence, making a fast-cycling well look different remotely than it is. Confirm the update rate is fast enough to capture the cycle's key transitions.
Watch for stale tags that stop updating while the rest of the telemetry moves. A single frozen pressure or a stuck valve state, with the other signals live, indicates a hung tag or a communication issue on that point rather than a real well condition. Watching all the cycle signals together through several cycles exposes a stale tag, because it stands still while its neighbors move. Catching this prevents a frozen value from being read as a real cycle event.
Once the valve state matches the well, arrivals are counted and timestamped correctly, the pressures move through the cycle coherently, and nothing is stale or badly lagged, the plunger-lift cycle telemetry is verified. Record a baseline of a normal cycle - its pressures, timing, and arrival pattern - as the reference for spotting future changes remotely. Verified cycle telemetry is what lets you diagnose a plunger-lift well from the office instead of the wellsite, which is the point of instrumenting it.
Common Mistakes
The most common mistake is verifying each tag in isolation and never checking that the whole cycle tells a coherent story. A valve state, an arrival, and the pressures can each be individually plausible yet contradict one another, which only a whole-cycle read reveals.
The second is ignoring timing, so a slow poll rate or a timestamp offset smears the cycle and makes the remote picture disagree with the real well. The third is missing a stale tag that has frozen while the others update, which is caught only by watching all the cycle signals together through several cycles rather than glancing at one value.
Frequently Asked Questions
What should plunger lift telemetry show through a cycle?
It should show the well's valve state transitioning between shut-in and open, arrival events registered and counted as the plunger reaches surface, and casing and tubing pressures moving in the characteristic pattern - casing building during shut-in, drawing down after opening as the well produces. All three should move together coherently, with the pressure changes and arrivals timed sensibly against the valve transitions. That coherent whole-cycle picture is what makes the telemetry trustworthy for remote monitoring.
How do I catch a stale tag in plunger lift telemetry?
Watch all the cycle signals together through several cycles. A stale tag stands still while its neighbors move, so a frozen pressure or a stuck valve state stands out against the live signals around it. A frozen value can look like a real, unchanging condition, so the contrast with the moving signals is how you expose it. Verifying tags in isolation misses this; only watching the whole cycle together reveals a single point that has stopped updating.
Why does polling rate matter for plunger lift telemetry?
Because a plunger-lift cycle has short, meaningful transitions - the well opening, the plunger arriving, the pressures drawing down - and a polling interval that is too slow relative to the cycle can miss or blur them. That makes a fast-cycling well look different remotely than it actually is and can hide brief events. Confirm the update rate is fast enough to capture the cycle's key transitions so the remote picture faithfully represents the real well.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.