Fewer Bells, Better Signals: Designing Water Treatment Telemetry Around the Response Model

There is a familiar pattern in UK plant rooms. A water treatment system is upgraded, a telemetry package is bundled in, and six months later the facilities team has stopped looking at it. The dashboard is still there, blinking on a wall-mounted screen or buried in a browser tab. The alerts still arrive. They are simply routed to an inbox nobody owns, because the people receiving them learned early that nine out of ten were noise.

This is not a technology failure. It is a design failure, and it happens because telemetry is usually specified from the sensor upwards rather than from the response downwards.

Begin with the response, not the sensor

The first question in any telemetry project should not be 'what can we measure?' It should be 'who is on site at three in the morning, and what are they empowered to do?'

Answer that honestly and the design largely writes itself. A site with no overnight presence cannot meaningfully act on a same-hour alarm, so a system that generates them is generating guilt rather than action. A site with a 24-hour security desk can absorb a small number of tier-one notifications, provided the desk has a written instruction and a phone number. A site with a visiting maintenance contractor three days a week should be commissioning alerts that mature over three days, not three minutes.

The response model is therefore a document, not a setting. It should set out, in plain terms, who receives which class of alert, what they are expected to do, how quickly, and what closes the loop. It belongs in the water safety plan and in the maintenance contract, and it should be agreed before the purchase order for the sensors.

Tier the alarms deliberately

Telemetry works when alarms are few and their meaning is unambiguous. A four-tier structure serves most UK facilities well.

• Tier zero — record only. Trending data with no notification: flow totals, differential pressure, run hours, regeneration counts. This is where most of the value sits, and it should never wake anybody.
• Tier one — next working day. Drift that matters over weeks: a softening performance trend, a slow fall in salt consumption, a pump running marginally long.
• Tier two — same day. Conditions that will become a problem inside the week: differential pressure past a change-out threshold, an empty chemical drum with no delivery booked, a regeneration cycle missed.
• Tier three — immediate. Genuine loss of control: no flow where flow is required, dosing failure with the plant running, a tank level at the low cut-off, a temperature excursion in a system within scope of the site's legionella risk assessment.

The discipline lies in resisting tier three. If a site receives more than a handful of immediate alerts a month, the thresholds are wrong or the plant is genuinely unstable, and both need attention rather than a wider distribution list.

What is actually worth monitoring

Where budget or network capacity is limited, weight the instrumentation towards the things that fail silently.

Differential pressure across filters earns its place because it degrades gradually and predictably. Softener performance — whether measured directly or inferred from regeneration behaviour and salt consumption — is worth more than any single hardness sample. Dosing pump status, run hours and chemical consumption together provide a reliable proxy for dose delivered, which is what actually matters. Tank and drum levels prevent the most avoidable callouts of all. Temperature monitoring at calorifiers, sentinels and little-used outlets supports the site's control regime far more usefully than a weekly manual check of a single tap.

What is usually not worth continuous monitoring: parameters you cannot act on, points that duplicate a contractor's calibrated test, and anything whose only outcome is a graph someone admires once a quarter.

Killing the nuisance alert

Nuisance alerts are the single biggest cause of abandoned telemetry, and most are avoidable with a little engineering discipline.

Use debounce so that a momentary condition does not trigger a message. Use hysteresis so that a value hovering at a threshold does not generate a stream of raised-and-cleared events. Use rate-of-change logic where absolute values are less informative than speed of movement. Use suppression windows during backwash, dosing cycles and planned maintenance, so that normal process behaviour does not look like a fault. And use escalation ladders rather than broadcast lists: one recipient, then a second, then a manager, on a defined clock.

A useful test before go-live is to sit with the previous twelve months of manual records and ask whether the proposed alarm set would have produced a genuine, actionable message in each case where a person had to intervene. If it would have produced a hundred others besides, the design is not finished.

Ownership, contracts and the exit door

Telemetry generates data, and data has a way of becoming a commercial asset held by somebody else. Before signing, establish who owns the historian, whether the site can export raw data without charge or permission, how long records are retained, and what happens at contract end. A system whose history disappears when a maintenance agreement lapses leaves the site unable to demonstrate continuity the next time it is asked.

Insist on an export in a non-proprietary format, at a defined frequency. Ask where the data physically resides and under which jurisdiction. Confirm that firmware updates, SIM or connectivity costs and any per-point licensing are visible rather than absorbed into an opaque annual charge.

Basic cyber hygiene, without drama

A telemetry gateway is a small computer on your network, and it should be treated as one. Segregate it onto a dedicated VLAN with no route to the corporate estate and no direct path to the building management system beyond what is strictly required. Change default credentials before commissioning, and record who holds them. Disable remote access when it is not in use, and require multi-factor authentication where the platform supports it. Keep firmware patched on a schedule written into the maintenance contract. Ask the supplier how they access the system remotely, and get the answer in writing.

None of this is exotic. It is the same baseline expected of any connected device, and it is far easier to agree at procurement than to retrofit after an incident.

Commission it like a control system

Allow a tuning period — ninety days is realistic — during which thresholds are adjusted against real plant behaviour, recipients are confirmed, and false positives are logged and eliminated. Then review annually, alongside the water safety plan and the legionella risk assessment, because a site's occupancy, staffing and plant all change while the alarm configuration quietly stays as it was on day one.

The measure of good telemetry is not the volume of data it produces. It is the proportion of alerts that resulted in someone doing something useful. If that proportion is high, the system is doing its job. If it is not, the problem was never the sensors.