Water utility SCADA: overflow, flooding, and faults that still arrive as complaints

Water-utility alarms differ from factory alarms in the discovery path, not in screen colour

When a tank level goes out of range in a factory, the operator is usually still in the control room and can walk to the equipment in minutes. Water-utility pump stations sit across the urban area; at night a site often has a reduced crew or no one on site. Ranking messages only by the factory scheme of shutdown, quality and safety misses what a utility actually has to handle: sewage overflow, street flooding, and a silent station in its own right.

The sharper difference is how the fault is found. Many utilities are still complaint-driven: the call centre hears about ponding, odour or a spill, and only then does dispatch send a crew. SCADA here is not a factory alarm list moved onto a pump station. It is a way for overflow and flooding to be reported from the site before a resident calls.

• Geography: alarms come from lift stations, sewage stations and booster stations across the city; the dispatcher cannot see the site and decides on a crew from the signals alone
• Public impact comes before output: overflow and flooding hit the municipal environment and residents, not minutes of line downtime
• Complaints remain a discovery channel: when a hotline ticket does not match a field signal, a measurement is usually missing or communications have already dropped
• Rain raises many stations at once: one storm lifts wet-well levels together; a single-machine cascade model from a factory does not apply
• Lost communications is an event: in a factory a down network still lets someone walk to the panel; on a utility, dispatch cannot tell whether the silent station is already overflowing

So the first design question is not how many severity bands to create. It is whether this signal can tell dispatch to send a crew before a resident phones in.

Overflow, flooding, lost comms, unit failure: rank by consequence, not by tag count

How to assign colour, sound and deadband is covered in a separate factory-alarm article. A water utility needs to rank by consequence first: overflow and flooding leave a response window measured in minutes; a unit failure depends on whether a standby pump is available and whether it is raining; lost communications means one thing on a dry day and another in a storm.

The four types below are what a utility dispatch desk actually sees. Treat them as separate event types rather than folding everything into a single “high level” message.

• Overflow: wet-well high-high, overflow weir, unusual discharge — once true, send a repair crew and notify drainage operations; this is an environmental event, not a maintenance reminder
• Flooding: water outside the station, rain coinciding with a pump stop, a road sensor out of range — compare with the rainfall event and decide whether this station cannot pump enough or upstream inflow has exceeded rated capacity
• Lost communications: gateway heartbeat gone, MQTT to the cloud interrupted — on a dry day, check the link on the inspection round; during rain, escalate as “overflow status unknown”, confirm power and the path first, and do not wait for a complaint
• Unit failure: overload, VFD trip, unusual discharge pressure — if a standby pump exists, switch and schedule repair; if the last pump is down and level is rising, escalate as overflow risk rather than closing it as a single-machine fault

Push and duty cover for scattered sites: target outcomes to verify on the project

Once sites are scattered, a full crew cannot stay at every station. Push and duty have to be designed together: which events stay on the dispatch wall, which also go to the on-call phone, and whether the recipient list is the same in rain and dry weather. Manning (reduced crew or no permanent staff on site) and the time from alarm to work order are target outcomes. They need to be verified on the specific project and must not be written as results already achieved everywhere.

• Split by event type: overflow and flooding go on the duty instant channel; unit failure with a standby pump goes to the maintenance crew; lost communications switches channel according to rainfall
• Change the list by time of day: at night and on holidays keep only people who can actually go out, rather than sending every event to the same phone
• Escalate if unconfirmed: overflow and lost comms that are neither acknowledged nor dispatched, raise to the duty lead or the backup shift instead of repeating the same row
• Feed complaints back: if the hotline already reported standing water but SCADA has no matching signal, log a coverage gap, then add a sensor or check communications — do not only close the ticket

The channel can be SMS, a messenger or voice; the choice follows local duty practice and the available carriers. More channels do not by themselves speed the response. A blast that is not split by event type is how the duty phone ends up muted.

Event type, signal source, dispatch action

Dispatch does not need a colour chart. It needs “where this event came from” and “what to do”. The table lists events common on water-utility sites. Use it as a draft to check signals and duties on a single-station pilot; it is not a universal standard.

The confirmed site scope is IoT gateway connection of one pump station, ModbusTCP acquisition and MQTT to the cloud. Work-order timing, multi-channel push and reduced manning in the table are target outcomes; they need to be verified on the specific project against station type, communications conditions and the duty roster.

Joining the group-control template: define the events on one station first

Multi-site group control is covered in a separate article: the standard station template, address-table export, gateway connection and platform aggregation. This piece adds only one requirement: the four event types — overflow, flooding, lost communications, unit failure — and the complaint-feedback rule belong in the alarm definitions of the single-station template, not as a later patch in the dispatch centre once more sites are online.

What the template can carry forward is the event type, the agreed signal source and the wording of the dispatch action, so that “high level” does not mean something different on the next station. What it cannot replace is a station-by-station check: whether the overflow weir has a signal, whether there is a flood sensor outside the station, whether a hotline ticket can return into the same event record.

Keep the capability boundary explicit. The confirmed delivery scope is one pump-station gateway, ModbusTCP, MQTT to the cloud and address-table planning. Group-control templates and cross-site aggregation are engineering assets and solution capabilities; they are not evidence of rollout in several cities. Treating archive material as multi-city deployment already completed misleads a purchasing decision.