Four stacked infinitii flowworks panels: observed depth and flow against modelled expected values, velocity, and the calculated blockage index and flags.
A real event graphed in infinitii flowworks. Top two panels: observed depth and flow (filled) against their modelled expected values (red dashed). Third panel: velocity. Bottom panel: the calculated blockage channels — none of which came from a sensor.

Every depth and velocity record already in your infinitii flowworks account carries the signature of a developing restriction. The problem has never been the data — it is that a raw depth channel and a raw velocity channel, viewed separately against fixed thresholds, do not tell an operator anything actionable until the manhole is already surcharged.

The FACE Pro scripting engine inside infinitii flowworks lets you build calculated channels on top of that raw data using Python and R. Not a report you run monthly. Continuously updating channels that live in your account exactly like sensor channels: graph them, alarm on them, put them on a dashboard, feed them into other calculations.

What it looks like in your graphs

Shortly after 10:30 on 19 January, depth steps up and pulls away from its expected envelope while velocity collapses from 0.45 to 0.25 — the classic restriction signature. The blockage index climbs and the composite flag escalates, holding at level 2 through the middle of the event and staying raised into the early evening. The following 36 hours sit clean, with no flags.

Nothing in that bottom panel came from a sensor. Every one of those channels was calculated, from data your meters were already sending.

Four independent index channels, not one rule

A single threshold rule is why most blockage alarms get ignored. The approach here is to build four separate calculated index channels, each targeting a different failure signature, then blend them. When several fire on the same timestamp, confidence is high. When only one fires, the composite stays below the alert threshold.

The composite channel

The four indexes blend into a single weighted composite index, and flag levels are derived from it with hysteresis — a flag must be sustained for at least 60 minutes before it is recorded as an event. Single spikes never reach an operator. That one design choice is the difference between a channel your team trusts and the one they mute.

The part that matters most — the sensor integrity rating

The single largest source of false blockage alarms is not hydraulics. It is malfunctioning sensors: velocity probes stuck at zero, depth transducers drifting, one sensor in a paired installation dropping offline.

A velocity signal of zero under rising depth is, on paper, indistinguishable from a severe blockage. Any detection scheme that does not solve this will bury your crews in bad truck rolls.

Why this beats a threshold alarm

It is self-calibrating, site by site

Baselines come from each site's own history — IQR normalization, hour-of-week envelopes, rolling medians. No engineer sitting down to hand-tune a depth setpoint for every meter in the network, and no re-tuning when seasons shift.

It requires agreement before it escalates

Four methods looking for four different signatures. One firing alone stays below the alert threshold. Convergence — plus 60 minutes of persistence — is what produces an alert, which is why the alert means something when it arrives.

It knows when not to trust itself

Sensor integrity flags gate the detection output. A stuck probe surfaces as a maintenance ticket for the meter, not a crew dispatched to a pipe that is perfectly clear.

You can see exactly why it fired

Because every index is its own visible channel, an operator can graph the composite, see which methods contributed, and answer “why did the system tell me that?” without opening a black box. That is a defensible position in front of a regulator.

Blockage detection is a worked example, not a fixed product. The same FACE Pro engine that produces these index channels can author any calculated channel your team can define, in Python or R, against your own data and on your own schedule. New analytics do not wait for a platform release or a custom development project. They are a script.

If your team already has an analyst who writes Python or R, they can build in infinitii flowworks. If they do not, we can author it for you.

First published on the infinitii ai blog. infinitii ai is the company behind infinitii flowworks.

Related

FACE and FACE Pro

Calculated channels, in no-code formulas or in Python and R.

Read more →

Wastewater collection

Blockages, overflows, I&I and the analysis behind them.

Read more →

Alarming

Who gets told, how, and what stops an alarm being ignored.

Read more →

Ready to begin?

See it on your own data

A walkthrough on your own sites answers the questions an article cannot.