What you will learn
- How combined and separate sewer systems overflow differently
- What level sensors and rain gauges each contribute
- How an overflow event is defined, recorded, and closed
- What regulators require in overflow reporting
- How monitoring data supports overflow reduction planning
What the project is
In a combined sewer system, one pipe carries sewage and stormwater. In heavy rain, the flow exceeds the pipe and treatment capacity, and the excess discharges through designed overflow points to a watercourse. In a separate system, overflows usually mean a blockage, a pump failure, or inflow overwhelming a foul sewer. Monitoring software watches level sensors at overflow points, rain gauges across the catchment, and pump and flow data, and records each overflow event with its start, end, duration, and estimated volume.
The record serves two purposes. Operationally, it tells crews which overflows are happening now and which points overflow most often, which is where capital work should go. For compliance, it produces the event reports regulators require, with the evidence behind each event. A system that only alarms, without building an auditable event record, solves half the problem.
Core features
Event records are the feature. An alarm without a start time, end time, and volume estimate cannot become a report.
- Level sensor ingestion at overflow points, with health monitoring so a dead sensor is not mistaken for a dry chamber.
- Rain gauge data by catchment, so overflow events can be correlated with rainfall intensity and duration.
- Event detection: automatic start and end times from level thresholds, with manual correction by operators.
- Volume estimation from level, duration, and flow data, labelled as estimates with the method stated.
- Pump and blockage alerts that distinguish rain-driven overflows from failures, because the response differs.
- Regulator reporting: event summaries by point and period, generated from the event records.
- Hotspot analysis showing which points overflow most often and under what rainfall, to prioritise capital work.
How it is built
Start with the overflow points that already have sensors, and build the event record there. Adding sensors to unmonitored points comes after the record works.
- Point inventory: list overflow points, their sensors, and their reporting duties, and identify the points with no monitoring.
- Event model: define how an event starts, ends, and is corrected, with input from operators and compliance staff.
- Platform build: sensor ingestion, event detection, rain correlation, and volume estimation, validated against known past events.
- Reporting: regulator event reports generated from event records, checked against a past filing.
- Expansion and planning: add sensors to unmonitored points, and use hotspot analysis to build the overflow reduction plan.
Tech considerations
The technical core is time-series event detection and honest volume estimation. The reporting layer follows from the event record.
- Time-series ingestion from level sensors, rain gauges, and flow meters, with gap handling that does not invent data.
- Event detection rules with thresholds, debouncing, and manual override, because a flickering sensor must not create ten events.
- Volume estimation methods documented per point, with the uncertainty stated rather than hidden.
- GIS display of overflow points, catchments, and event history, for operations and planning.
- Role-based access and immutable event history, so a corrected event keeps its original record.
Challenges to plan for
Overflow monitoring fails on sensor reliability and on volume estimates presented as facts. Both undermine the reports the system exists to produce.
- Sensor fouling: level sensors in sewers foul and drift, and a fouled sensor produces false events or misses real ones.
- Volume uncertainty: estimating overflow volume from level alone is approximate, and reporting it without that caveat misleads everyone.
- Rain data gaps: a catchment without a nearby gauge cannot correlate events with rainfall, weakening both operations and reporting.
- Event definition disputes: operators and regulators may define an event differently, and the system must record raw data so either definition can be derived.
Who it is for, and honest limits
This fits utilities with combined sewer systems, systems with overflow reporting duties, and any operator planning overflow reduction capital work. It fits less well for a small separate system with no overflow points and no reporting duty, where a pump alarm and a logbook cover the need.
It does not reduce overflows. It records them accurately and shows where reduction work pays most. The reduction itself comes from storage, separation, or capacity work, and the monitoring record is what justifies that spend.
Frequently asked questions
What is a combined sewer overflow?
In a combined system, heavy rain can exceed pipe and treatment capacity, and the excess discharges through a designed overflow point. It is a permitted relief mechanism in many systems, but it must be monitored and reported.
How is overflow volume estimated?
From level and duration data, sometimes with flow measurements, using a method documented per point. Estimates carry uncertainty, and reports should state the method rather than presenting a single precise number as fact.
What triggers an overflow alert?
A level sensor crossing its threshold at an overflow point, sustained long enough to rule out a transient spike. Operators can correct start and end times where the sensor record is ambiguous.
Can it distinguish a blockage from rain-driven overflow?
Partly: a dry-weather overflow points to a blockage or pump failure, while a wet-weather overflow during heavy rain points to capacity. Rain data and pump status together make the distinction much more reliable.
What do regulators require?
Event reporting by point and period, typically including start, end, duration, and estimated volume, with the format and frequency set by the permit. Check current requirements for the operating system rather than assuming a standard.