Northgate Water Authority: Scoping a Leak-Detection Pilot
Northgate Water Authority is planning a 9-month pilot to cut non-revenue water from 22% to 18% using 1,200 acoustic leak sensors across a 40 km² district with 310 km of mains. The district has 62 pressure-reducing valves, 14 legacy SCADA outstations on licensed UHF, and no cellular coverage in three of its nine zones. Finance has approved USD 380,000, which must cover gateways, installation, backhaul and three years of network fees. Operations wants leak alerts within 30 minutes; the asset team wants a five-year battery life; IT insists all telemetry terminates in the existing Azure tenant under the corporate security baseline. The vendor quotes a LoRaWAN design at 15-minute sampling with 42 gateways, but prices only two years of backhaul and assumes mains power at every gateway site. Field crews can install at most 40 sensors per week, and the rainy season closes two zones for six weeks. The board wants approval at the next meeting.
1. Assess whether the pilot as scoped can meet its objectives. Identify the planning gaps and state what you would change before approving it.
Read the worked answer
The scope as written cannot be approved; four gaps are material.
Budget completeness. Backhaul is priced for two years against a three-year requirement, leaving a known funding hole that surfaces mid-pilot. More seriously, 'mains power at every gateway' is an assumption, not a survey result. If roughly a quarter of the 42 sites need solar plus battery, capex rises and the 9-month schedule slips.
Coverage. Three zones have no cellular. Every gateway there needs an alternative path (fibre, point-to-point radio, satellite), which changes both cost and worst-case latency - and latency is what determines whether the 30-minute alert target is achievable.
Throughput and schedule. 1,200 sensors at 40 per week is 30 weeks of installation before the 6-week rainy-season closure is considered. There is almost no observation time left before evaluation.
Measurement. Cutting district non-revenue water from 22% to 18% is a district-level outcome a partial rollout may not move in nine months.
I would narrow the pilot to four district metered areas (about 400 sensors) with a matched control area, extend to 12 months, fund three years of backhaul, commission an RF and energy site survey before the PO, and add a month-6 go/no-go gate with pre-agreed kill criteria.
2. Write three measurable acceptance criteria the pilot contract should include, and explain what each one protects against.
Read the worked answer
1. Detection performance, not just uptime. 'For each injected test leak of 2 L/s or greater on a hydrant, the system raises an alert within 30 minutes in at least 80% of trials, with no more than one false positive per district metered area per month.' Uptime alone proves the radios talk; this proves the analytics work. The false-positive ceiling matters because crews stop trusting alerts after a noisy pilot, and a rejected system is a failed pilot regardless of sensor health.
2. Battery end-of-pilot evidence. 'At least 95% of installed sensors show a measured energy consumption consistent with five years of life, extrapolated from 12 months of logged transmit counts, retransmission rates and spreading factors.' This forces the vendor to expose the energy model and the actual SF distribution, rather than a datasheet claim based on ideal SF7 conditions.
3. Data availability and security conformance. 'At least 98% of installed sensors deliver a valid reading in each 24-hour window, and 100% of telemetry reaches the Azure tenant over TLS 1.2 or higher with unique per-device credentials - no shared keys or default passwords.' Availability is the metric operations actually feels, and the credential clause prevents a pilot that passes technically but cannot pass the corporate security baseline at scale.
Each criterion should name the measurement method, the data source and the remedy (credit or rework) if missed.
3. The vendor's 42 gateways cover 40 km². Is gateway density driven by coverage or capacity here? Explain how you would validate the number and what you would do with any savings.
Read the worked answer
Coverage, not capacity, dominates here.
Capacity check. 1,200 sensors at one uplink per 15 minutes is 80 uplinks per minute, about 1.3 per second. A LoRaWAN gateway with eight channels handles far more than that, so capacity is not the constraint. 42 gateways over 40 km² averages about 0.95 km² per gateway - roughly 1 km spacing, which is reasonable for above-ground urban and suburban coverage but is not evidence of an RF survey.
What actually drives the count. Underground chambers, metal covers, valve pits and building clutter. A sensor in a buried chamber can lose 20 dB or more, and that is what forces tighter spacing or better antenna placement, not throughput. The right validation is a site survey: place 10-15 temporary gateways or a test transmitter at candidate points, record RSSI and SNR from representative sensor locations, and confirm that the worst 10% still clear the link budget at the spreading factor the energy model assumes.
Energy coupling. Higher spreading factors extend range but multiply radio-on time, which directly erodes the five-year battery target. Density and battery life trade against each other; the survey must optimise both.
Use of savings. If coverage holds at 24-28 gateways, redirect the delta into three years of backhaul and solar power at the off-grid sites - both of which are currently underfunded - rather than into more gateways.