Pump Scheduling Is the Cheapest Win in Water

Smart water conversations are dominated by leak detection, and understandably — losing a third of what you produce is a striking statistic.

But there is a second lever that is easier to implement, quicker to prove, and consistently under-pursued. It involves no new sensors and no new capital assets, and it attacks the largest electricity bill the utility has.

The setup

Three facts, each unremarkable alone.

Pumping is typically the biggest electricity consumer a water utility has. In some municipalities it is the biggest electricity consumer of any kind, across all departments.

Reservoirs are storage. Water pumped at one time can be consumed at another, which makes a reservoir functionally a battery that the utility already owns and has already paid for.

Electricity prices and carbon intensity vary substantially across a day — by a factor of several in many markets, driven by demand and by how much wind and solar is on the system.

Put those together and the opportunity is obvious: pump when power is cheap and clean, draw down when it is expensive and dirty. The utility already owns the storage. It is simply not being used as storage.

Why it is not already done

Mostly because the decision is made by a human on a schedule that was reasonable when it was written.

Operators run pumps on patterns established years ago, tuned to keep levels safe and avoid running out. Those patterns are conservative by design — the cost of an empty reservoir is enormous and the cost of pumping at a bad hour is diffuse. Faced with that asymmetry, any sensible operator over-pumps early.

What is missing is a reliable forecast of demand. Without one, you cannot safely cut the margin, because you do not know how much you will need. With one, the optimisation is straightforward.

What the model actually is

Unexciting, which is the good news.

Predict hourly demand over the next twenty-four to forty-eight hours from calendar features, weather, and recent consumption. Gradient boosting on those inputs generally beats anything more elaborate. This is a well-understood forecasting problem with strong daily and weekly seasonality and a large, clean training set, which is about the most favourable setup a forecasting problem can have.

Then solve a constrained optimisation: minimise energy cost subject to reservoir levels staying within bounds, network pressure staying within bounds, and pump start limits being respected.

Four things matter in practice, and they are all about constraints rather than about the model:

• Match the forecast horizon to the reservoir's buffering capacity. Forecasting further ahead than you can store is academic.
• Encode asset protection limits — maximum pump starts per hour, ramp rates — as hard constraints, not soft penalties. Give an optimiser a penalty and it will happily trade pump life for electricity savings, and pumps are expensive.
• Run in advisory mode first. Show operators the recommended schedule with its reasoning before it actuates anything. Trust is earned slowly and lost permanently by one bad automated decision.
• Measure against the operator's own schedule, not against a naive baseline. Benchmarking against a strawman overstates the gain and gets found out at review.

Why I think it is the better first project

It is a cleaner proof than leak detection, for a few reasons.

It is measurable immediately. Energy consumption is metered and billed, so the saving shows up in a bill within a month. A leak programme's benefit shows up as water not lost, which is a counterfactual and therefore arguable.

It has no field dependency. No new sensors, no installation programme, no procurement cycle. The data — reservoir levels, pump run times, flows — is already in SCADA at the major assets, because those are the best-instrumented parts of any network.

And the downside is bounded. Running in advisory mode costs nothing and risks nothing; the worst outcome is that operators keep their existing schedule.

Done properly this is typically a double-digit percentage reduction in pumping energy cost. For a utility where pumping is the largest electricity line, that is a substantial number appearing with no capital expenditure attached to it.

The catch

It needs SCADA data, and getting data out of an operational technology network is a security conversation rather than an engineering one.

The architecture that gets approved is unidirectional: read from the historian or an OPC UA server inside the OT zone, replicate one-way through a DMZ, ingest into the analytics platform, and return the recommended schedule as information to an operator rather than as setpoints written back into SCADA.

That last part is non-negotiable and it is also fine. Pump scheduling does not need closed-loop control; it needs a better schedule in front of the person who sets it.

Full technical version, including architecture and phasing: TechCirkle's guide to smart water systems. The modelling and delivery side is our AI development services work.

Frequently Asked Questions

Why is pump scheduling a good first smart water project?

Because the saving is metered and billed, so it appears within a month rather than as a counterfactual. It needs no new sensors, uses data already present in SCADA at major assets, and can run in advisory mode where the downside is bounded.

How much can optimised pump scheduling save?

Typically a double-digit percentage of pumping energy cost, which for most water utilities is their largest electricity line. The saving comes from shifting pumping into cheaper, lower-carbon hours using the reservoir capacity the utility already owns.

What model is needed for pump scheduling?

An hourly demand forecast over twenty-four to forty-eight hours, built from calendar features, weather and recent consumption. Gradient boosting usually suffices. The forecast then feeds a constrained optimisation over energy cost subject to level, pressure and pump start limits.

Why encode pump start limits as hard constraints?

Because an optimiser given a soft penalty will trade pump wear for electricity savings whenever the arithmetic favours it. Pumps are expensive capital assets, so their protection limits need to be inviolable rather than priced.

Should pump scheduling actuate automatically?

Not initially. Run advisory first, showing operators the recommended schedule and its reasoning, and measure against their existing schedule rather than a naive baseline. Automation can follow once the recommendations have been trusted over a sustained period.

Does this require writing back into SCADA?

No, and it should not. Read one-way from the historian through a DMZ into the analytics platform, and return the recommended schedule as information to an operator. Pump scheduling does not need closed-loop control to deliver the saving.