Smart Water Systems: The Software Stack Behind Them

What Smart Water Systems Actually Are

Smart water systems is one of those phrases that means something different depending on who is selling it. To a hardware vendor it means meters. To a utility operations director it means not sending a crew out to find a leak. To a city council it means a chart in a presentation. To the engineers who have to make it work, a smart water system is a closed loop: instruments that measure what the water is doing, a network that moves those measurements somewhere useful, software that decides what the measurements mean, and an operational process that acts on the decision.

The loop is the definition, and the loop is also where projects fail. Deploying sensors is a procurement exercise with a known cost and a known timeline. Closing the loop, getting from a pressure anomaly to a work order to a repaired pipe automatically at three in the morning, is a software problem, and it is the part that routinely goes unspecified in the business case.

This article is about that software: the architecture, the AI that actually earns its place in it, the integration constraints that come with operational technology, and how to phase a build so that you discover whether it works before committing a capital budget to it. It is written for the person who has to approve the architecture, not for a procurement checklist.

The Three Layers, and Which One to Worry About

Every smart water deployment decomposes into the same three layers, and it is worth naming them before arguing about vendors.

Sensing. Flow meters, pressure transducers, acoustic leak loggers, reservoir level sensors, and quality probes measuring pH, turbidity, chlorine residual, conductivity and dissolved oxygen.
Transport. The connectivity that gets readings off the asset: LoRaWAN, NB-IoT, LTE-M, cellular, or existing SCADA telemetry at major sites.
Decision. Ingestion, storage, modelling, alerting, and the workflows that turn a number into a dispatched task.

Budgets are usually allocated in almost exactly the reverse of where the difficulty sits. Sensing is the biggest line item and the best understood. Transport is a set of well-documented trade-offs with four sensible answers. The decision layer is where the value is, where the uncertainty is, and where the smallest proportion of the budget tends to go.

If you take one thing from this article: specify the decision layer first, then buy sensors that can feed it. Every project we have been brought in to rescue did it the other way round.

Why Most Water Telemetry Projects Stall at the Dashboard

A recognisable pattern: a utility installs several thousand instruments, commissions a dashboard, and eighteen months later the dashboard is open on one screen in the control room and nobody is looking at it. The data is real. The hardware works. The project is dead.

It stalls for three reasons, and none of them is a technical failure of the sensors. The first is alert volume. Raw threshold alarms on thousands of noisy instruments generate hundreds of alerts a day, operators learn to ignore them, and the system has effectively trained its own users to distrust it. The second is that an alert is not an action. There is no defined path from pressure dropped in zone fourteen to a scheduled crew with a location, an access note and a priority. The third is that nobody owns the number. Unless a named person's performance is measured on water loss, the insight has no internal customer.

The fix for all three is the same, and it is a design decision rather than a technology choice: design backwards from the operational decision. What do you want a specific human to do differently on Tuesday morning? Build the system that produces exactly that, and nothing else, first. Breadth can come later and will be cheaper once something is trusted.

Non-Revenue Water: The Number That Pays for the Project

The business case for smart water almost always reduces to non-revenue water, meaning water that is produced and treated but never billed. It splits into real losses such as leaks, bursts and overflows, apparent losses such as meter under-registration, data errors and theft, and unbilled authorised consumption.

The reason this number funds projects is its scale. Global averages for non-revenue water sit around a third of supply, and plenty of networks run well above that. Treated water that leaks out of a pipe has already consumed energy, chemicals and pumping capacity, so reducing it is simultaneously a revenue gain, an operating cost reduction and a sustainability metric. That combination is rare in infrastructure and it is why these projects get approved when others do not.

For software design this matters because it tells you what to instrument. Real losses need pressure and flow at district metered area boundaries. Apparent losses need meter-level consumption data and consumption profile analysis against expected demand. Those are different sensor deployments feeding different models, and a project that has not decided which loss it is attacking tends to under-deliver on both.

How AI Changes Leak Detection

This is the clearest AI win in water, and it is worth being specific about why, because AI-powered leak detection is marketed considerably more broadly than it actually works.

Traditional detection is threshold-based. If flow at a district boundary exceeds a configured limit, raise an alarm. The problem is that normal flow varies enormously by hour, weekday, season, weather and local events. A threshold loose enough to avoid false alarms at seven on a Monday morning will miss a substantial leak at three on a Sunday morning. Utilities compensate by having an analyst watch minimum night flow manually, which works and does not scale past a few dozen districts.

The machine learning approach inverts the logic. You train a model per district on that district's own historical flow and pressure, conditioned on time of day, day of week, temperature and rainfall, and you alert on deviation from the forecast rather than on an absolute number. A leak that represents eight percent of peak demand is invisible to a threshold and completely obvious as a persistent positive residual during the overnight minimum. In practice this moves detection from weeks to days, and the number of days is what determines how much water is lost.

Acoustic data takes it further. Correlating acoustic logger signatures against confirmed repairs produces a classifier that distinguishes a genuine leak from a pump, a passing vehicle or a domestic appliance, which is the difference between a crew finding something and a crew wasting a shift. This is standard supervised learning on a well-labelled dataset, and it is the kind of problem our machine learning development services work is built around.

Demand Forecasting and Pump Scheduling

The second durable AI application sits on the cost side rather than the loss side. Pumping is typically the largest electricity consumer a water utility has, and frequently the largest in an entire municipality's portfolio.

A demand forecast that is accurate at hourly granularity over a twenty-four to forty-eight hour horizon lets you solve a fairly straightforward optimisation: fill reservoirs during cheap, low-carbon periods and draw down during expensive ones, while respecting minimum levels, maximum pressures and pump start limits. The model itself is unremarkable. Gradient boosting on weather, calendar features and recent consumption usually beats anything exotic. The value is in the constraint handling and in being trusted enough to actually run.

Match the forecast horizon to the reservoir's buffering capacity. Forecasting further ahead than you can store is academic.
Encode asset protection constraints such as maximum starts per hour and ramp rates as hard limits rather than soft penalties, or the optimiser will happily trade pump life for electricity savings.
Expose the recommended schedule to operators with its reasoning before letting it actuate anything. Trust is earned in advisory mode and lost permanently by one bad automated decision.
Measure the gain against the operator's own schedule, not against a naive baseline, or you will overstate the benefit and get found out.

Done properly this is a double-digit percentage reduction in pumping energy cost on a lot of networks, achieved with no new capital assets at all. It is the easiest payback in the whole category and it is consistently under-pursued because it is less visible than leak detection.

Water Quality Monitoring and the Sensor Drift Problem

Continuous quality monitoring is where smart water earns its public health justification, and it carries a specific technical trap that catches most first-time builds. Quality probes drift. A chlorine residual sensor, a turbidity probe, a pH electrode: all of them slowly diverge from truth as membranes foul and electrodes age.

A naive system treats a drifting sensor as a water quality event, which produces false alarms and, worse, eventual desensitisation to real ones. A system that models drift does the opposite. It tracks each instrument's residual against its neighbours and against laboratory grab samples, flags the instrument rather than the water when the pattern is instrument-shaped, and schedules calibration based on observed drift rather than a fixed interval.

This is unglamorous data engineering and it determines whether anybody believes the quality data at all. Build sensor health as a first-class model alongside water quality, not as an afterthought. The same principle applies across industrial sensing. In computer vision development for business the equivalent problem is camera drift and lens contamination, and the equivalent mistake is treating a dirty lens as a detection.

Edge or Cloud: Where the Model Should Run

The honest answer is both, and the dividing line is easy to draw once you say it out loud: latency and bandwidth decide placement, not architectural fashion.

At the edge: anything safety-critical or adjacent to a control loop, such as burst detection that closes a valve or pump protection logic. Anything that must keep working when the network does not. And anything where raw sampling rates are too high to transmit, which means acoustic and vibration data in particular.
In the cloud: model training, network-wide hydraulic modelling, demand forecasting, long-horizon trend analysis, regulatory reporting, and anything that needs data from more than one asset to make sense.

Practically this means edge devices run small, fixed, well-tested inference, often a model measured in kilobytes, while the cloud retrains and pushes updated parameters down. Treat model deployment to the edge as a release process with staged rollout and rollback, because that is exactly what it is. A bad model pushed to three thousand battery-powered devices on a low-bandwidth network is not something you fix in an afternoon.

The platform side of this, including how to handle staged rollout and version pinning across a fleet, is covered in more depth in our cloud application development guide.

Choosing the Connectivity Layer

Connectivity is a solved problem. You simply need to match it to the asset, and there are four options that cover essentially everything.

LoRaWAN. Long range, very low power, tiny payloads, unlicensed spectrum. The right answer for battery-powered meters and loggers reporting a few times a day with a ten-year battery life target. The wrong answer for anything high-frequency.
NB-IoT and LTE-M. Carrier-managed, good building and basement penetration, slightly more power and payload budget. Right where you do not want to own and maintain gateways. LTE-M where you need more throughput or mobility.
Cellular 4G or 5G. Right for treatment works, pumping stations and anywhere mains power exists and data volume is high enough to matter.
Existing SCADA telemetry. Already installed at major assets. Do not replace it. Read from it.

The decision rule that saves the most money: battery-powered and remote means LoRaWAN or NB-IoT with a payload budget measured in bytes, and mains-powered means cellular and stop optimising. The expensive mistake is committing to a low-power network and then discovering that your anomaly model needs minute-level data from it, at which point you are replacing hardware you have already installed.

The Data Platform: Time Series at Utility Scale

Volume here is modest by consumer internet standards and awkward by relational database standards. A hundred thousand meters reporting hourly is around two and a half million points a day, which is trivial for a time-series database and genuinely painful in a plain relational schema.

Use a purpose-built time-series store such as TimescaleDB, InfluxDB or ClickHouse, or a managed equivalent. Downsample aggressively. Keep raw data at full resolution for a bounded window and roll up beyond it.
Expect late and out-of-order arrivals as a normal operating condition rather than an error. A battery logger that was out of coverage for two days will deliver two days of history in one burst, and your aggregates have to correct themselves when it does.
Keep an asset registry as a separate, versioned source of truth: which meter sits on which pipe, in which district, serving which properties. Most analytical errors in water projects are registry errors, not model errors.
Store every reading with both the device clock and the server receipt time. You will need both the first time you have to debug a timing anomaly, and you cannot reconstruct it later.

None of this is exotic. It is simply the difference between a platform that still works in year three and one that gets rebuilt. The same patterns apply to any custom software development project ingesting machine data at scale.

SCADA Integration Without Breaking OT Security

Every utility of any size already has SCADA, and that system is correctly treated as safety-critical. Integrating with it is the point where a smart water project meets operational technology security, and getting this wrong is how projects get cancelled rather than merely delayed.

The non-negotiable principle is directionality. Data flows out of the OT network into the analytics platform. Control does not flow back in without a human and a documented process. Implement it with a data diode or a one-way gateway in a DMZ, read via OPC UA or Modbus into a broker, and treat any write path as a separate project with its own risk assessment and its own sign-off.

In practice the architecture that actually gets approved looks like this: a historian or OPC UA server inside the OT zone, unidirectional replication to a DMZ broker, cloud ingestion from the DMZ, and recommendations returned as work orders in the maintenance system rather than as setpoints in SCADA. It is less satisfying than closed-loop control and it is what a security team will sign. Design for it from the start rather than discovering it at the security review.

From Alert to Work Order: Agentic Operations

This is the newest layer in the stack and the one that directly addresses why dashboards fail. The gap in most deployments sits between a detection and a dispatched crew, and that gap is currently filled by a person reading alerts and making judgement calls they do not have time to make well.

An agentic workflow can take a defined subset of that triage. Given an anomaly, it can pull the asset's maintenance history, check whether a crew has already been dispatched nearby, look up the pipe's material and age in the registry, estimate a loss rate from the flow residual, assign a priority, draft the work order with an access note, and route it to the right team in the maintenance system. The human approves or redirects, and that approval takes seconds rather than the twenty minutes the correlation would have taken.

Let the agent gather and assemble. Keep the dispatch decision with a person until the false positive rate has been measured and is demonstrably low.
Give it read access to the asset registry, work order history and GIS, because most of its value is correlation a human would not have time to perform.
Log every action with its reasoning. When a crew is sent to the wrong street, you need to be able to explain why, both internally and to a regulator.
Measure it on crew hours per confirmed leak, not on alerts processed. Alerts processed is a vanity metric that rewards exactly the wrong behaviour.

We build these as constrained agentic workflows rather than open-ended assistants: a fixed tool set, a bounded action space, and an approval gate on anything that costs money or sends a vehicle.

What a Smart Water Build Costs and How to Phase It

Software cost scales with integration count and model count, not with sensor count, which is counter-intuitive to anyone who has spent time pricing hardware. Adding ten thousand more identical meters barely moves the software estimate. Adding one more upstream system moves it considerably.

Phase one, a single district pilot: ingestion, time-series platform, one anomaly model, one alert workflow. Typically ten to fourteen weeks.
Phase two, operational rollout: asset registry, SCADA read integration, work order integration, operator interface, sensor health modelling. Usually four to six months.
Phase three, optimisation: demand forecasting, pump scheduling, hydraulic model coupling, agentic triage. Scoped per utility, because it depends heavily on what already exists.

The phasing matters considerably more than the numbers. Phase one should be small enough to fund without a capital process and real enough to produce a confirmed, repaired leak that nobody would otherwise have found. That single verified physical outcome does more for the business case than any vendor projection, and it is the thing that unlocks the rest of the budget. Our broader AI development services work follows the same phasing logic for the same reason.

How to Pilot Without Buying a Platform

If you are currently evaluating this, the structure of the pilot determines what you actually learn. Four rules we would insist on before starting one.

Pick one district with known problems and an engaged operations lead. A pilot in a well-behaved district with a disinterested sponsor proves nothing either way.
Define success as a physical outcome: leaks found and repaired, or pumping cost reduced, with a baseline measured before you start. Not a dashboard delivered, and not alerts generated.
Keep the data in a store you own, in an open format. The entire point of a pilot is to be able to change your mind about the vendor afterwards without losing the history.
Timebox it to a single quarter. If an anomaly model trained on a district's own history cannot find anything in three months, either that district is unusually tight or the approach is wrong, and both of those are worth discovering cheaply.

If you want help designing that pilot, or an opinion on whether your existing telemetry already contains enough signal to skip new hardware entirely, talk to us. We would rather look at a month of your flow data than send you a capability deck.

Frequently Asked Questions

What are smart water systems?

Smart water systems combine instrumentation such as flow, pressure, level and quality sensors with a connectivity layer and software that interprets the readings and drives operational action. The defining feature is the closed loop: a measurement leads to a decision and a dispatched task. Sensors and a dashboard on their own are telemetry, not a smart water system, and the distinction is the main reason projects disappoint.

How does AI detect water leaks?

Rather than alarming when flow crosses a fixed threshold, a model is trained on each district's own historical flow and pressure, conditioned on time of day, day of week, weather and season. It then alerts on persistent deviation from the forecast. This surfaces small leaks of a few percent of demand that are invisible to thresholds, particularly during the overnight minimum when background consumption is lowest.

What is non-revenue water and why does it matter?

Non-revenue water is water that is produced and treated but never billed. It comprises real losses such as leaks and bursts, apparent losses such as meter under-registration and theft, and unbilled authorised use. It typically runs around a third of supply globally. Because that water has already consumed energy and chemicals, reducing it improves revenue, operating cost and sustainability metrics at the same time.

Should smart water analytics run at the edge or in the cloud?

Both, split by latency and bandwidth. Safety-critical detection, control-adjacent logic and high-sample-rate processing such as acoustic analysis belong at the edge so they keep working without connectivity. Model training, network-wide hydraulic modelling, demand forecasting and reporting belong in the cloud. Treat pushing models to edge devices as a staged release process with rollback, not as a configuration change.

Which connectivity should a smart water deployment use?

For battery-powered remote assets reporting infrequently, LoRaWAN or NB-IoT, with payloads budgeted in bytes to protect battery life. For mains-powered sites such as treatment works and pumping stations, cellular. At major assets with existing SCADA telemetry, read from that rather than replacing it. Choose the network after deciding what data rate your models need, not before.

How do you integrate smart water analytics with SCADA safely?

Keep the data flow unidirectional. Read from the historian or an OPC UA server inside the OT zone, replicate one-way to a DMZ broker, and ingest from there. Return results as work orders in the maintenance system rather than as setpoints in SCADA. Any write path back into the OT network should be a separate project with its own risk assessment and explicit human approval.

How long does a smart water software project take?

A single-district pilot covering ingestion, a time-series platform, one anomaly model and one alert workflow is typically ten to fourteen weeks. Operational rollout with asset registry, SCADA read integration, work order routing and operator tooling usually runs four to six months. Optimisation work such as demand forecasting and pump scheduling is scoped separately because it depends on existing hydraulic models.

Why do smart water projects fail after the sensors are installed?

Three recurring causes. Alert volume from raw thresholds trains operators to ignore the system. There is no defined path from an alert to a dispatched crew. And no individual's performance is measured on the loss number the project was meant to improve. All three are addressed by designing backwards from a specific operational decision rather than forwards from whatever data happens to be available.