How to Baseline a Pump-Off Controller Runtime

Back to Blog

Stabilize the Well and Settings First

A baseline is only useful if it captures normal behavior, so do not baseline a well that is still being tuned or is recovering from a workover. Confirm the pump-off logic is verified, the pump-off setpoint is set to a sensible value, and the well has run for enough cycles that its run-and-idle pattern has settled into a rhythm. If someone is still adjusting the setpoint or the pump-fillage threshold day to day, the runtime will move for those reasons and the baseline will be meaningless.

Record the settings that shape runtime so the baseline is interpretable later. Note the pump-off setpoint, the fillage or load threshold that triggers shutdown, the minimum idle time, and the pumping speed. Runtime is a function of these settings and the reservoir together, so a baseline without the settings recorded cannot be compared honestly to a future reading taken under different settings. Keeping the settings alongside the numbers is what makes the baseline durable.

Confirm the shutdowns during the baseline period are genuine pump-off events, not nuisance trips or faults. Look at the cards that triggered each shutdown and confirm they show real incomplete fill, and check that the controller is not idling on a bad signal or a spurious alarm. A baseline built on nuisance shutdowns records noise rather than the well, so clean up the trip cause before you trust the runtime pattern - the same discipline you would apply to any nuisance alarm.

Capture the Normal Run-and-Idle Pattern

With the well stable, record its behavior over several representative days, ideally covering a normal range of ambient and operating conditions. The core numbers are daily runtime, daily idle time, the runtime percentage of the day, and the number of pump-off cycles per day. Together these describe how hard the well is being pumped relative to what the reservoir can supply. A well running a modest fraction of the day is being cycled off frequently because inflow cannot keep the pump full; a well running most of the day is close to being inflow-limited.

Trend these values rather than storing a single day. A continuous record of runtime, captured by the monitoring system, shows the normal day-to-day scatter as well as the average, which is what you need to judge later whether a change is real or just normal variation. Storing the runtime as a trended tag alongside the well's other data lets you overlay it later against production and pressures. Treat runtime as a first-class monitored value, the same way you would treat any point you rely on for trending in SCADA.

Also record the cards and pressures that accompany the baseline runtime. The dynamometer cards during the baseline period establish what a normal shutdown looks like on this well, and the casing and tubing pressures at the time set the pressure context. When runtime later changes, having the baseline cards and pressures lets you tell whether the pump, the inflow, or the wellhead conditions moved. The runtime number is the headline; the cards and pressures are the supporting evidence.

Use the Baseline to Catch Changes

Once the baseline exists, the runtime becomes a diagnostic. A steady, gradual decline in daily runtime on an unchanged setup usually means the reservoir is supplying less liquid over time, so the pump fills more slowly and the controller idles it sooner and longer. This is the normal decline signature and it tells you the well may be a candidate for a speed reduction or a different lift strategy, not a repair. Reading it against the baseline is what distinguishes decline from a fault.

A sudden change points elsewhere. Runtime that drops abruptly, or cycling that becomes erratic and short, often means a mechanical or downhole problem: a sticking pump, a hole in tubing, sanding, or increasing gas. Compare the current cards and pressures against the baseline cards and pressures to localize it. An abrupt runtime change with normal-looking cards suggests a surface or controller issue; an abrupt change with degraded cards points downhole.

The checklist below captures the minimum you should record to make a runtime baseline useful. Store each item as trended data where you can, so the comparison later is a matter of overlaying live values on the baseline rather than hunting for old notes.

• Well is stable and pump-off logic verified before baselining.
• Pump-off setpoint, fillage threshold, minimum idle time, and speed recorded.
• Daily runtime, idle time, runtime percentage, and cycle count over several representative days.
• Representative dynamometer cards that triggered shutdowns during the period.
• Casing and tubing pressures during the baseline period.
• Confirmation that baseline shutdowns are genuine pump-off events, not nuisance trips.

Common Mistakes

The most common mistake is baselining an unsettled well, so the reference captures tuning noise rather than normal behavior. Wait until the run-and-idle rhythm has stabilized and the settings have stopped changing before you record the baseline.

The second is recording runtime without the settings that drive it, which makes any later comparison ambiguous because you cannot tell whether runtime moved due to the reservoir or a settings change. The third is treating a single day as a baseline; runtime varies day to day, and only a trend over several representative days captures the normal scatter you need to judge future changes against.

Frequently Asked Questions