A practical roadmap to digital water: start with the problem, not the platform

Why start with the problem

Digital water is the digitization of water assets and processes: sensors, communications, data platforms and analytics that make their data accessible for faster analysis, remote monitoring and easier decisions. The technology is mature and widely available. The hard parts are deciding what to measure, trusting what is measured, and putting the result in front of the person who can act on it.

A useful test is whether you can state the problem in one sentence, in operational terms. "We learn about reservoir overflows from customers." "We cannot say which pumps are drifting away from their duty point." "Non-revenue water is high, but we do not know where it is lost." Each sentence implies different measurements, different connectivity and a different dashboard. A platform purchased before that sentence exists tends to collect data nobody asked for.

A phased approach

The sequence below works for a single treatment plant, a pumping network or an industrial facility. The phases overlap in practice, but the order matters: each one depends on the quality of the one before it.

Phase 1: Assess

Start with an inventory of what already exists: instruments, PLCs, RTUs, SCADA, historians and communications links. Many Canadian systems combine equipment from several decades, from relay panels and chart recorders to modern PLCs, so expect a mixed picture and plan to integrate it rather than replace it. Then talk to the people who run the system. Operators and maintenance staff know which readings they trust and which they ignore, and that is information no drawing contains.

From those conversations, pick three to five use cases and define the KPI each one should move, such as specific energy in kWh/m³, unplanned downtime, non-revenue water or alarms per operator per hour. Record the current value first. Without a baseline, no later improvement can be shown. The deliverables are a ranked list of use cases, a gap analysis and a sketch of the target architecture.

Phase 2: Instrumentation quality and connectivity

A dashboard is only as good as the sensor behind it. Before adding anything, check that existing instruments are right for the application, correctly installed, scaled in the right units and calibrated on a schedule. Electromagnetic flow meters need a full pipe and adequate straight run. Ultrasonic level sensors struggle with foam and condensation. A pressure transmitter ranged for 100 m will give coarse readings on a 20 m system. Mark suspect data with quality flags (out of range, stuck, spiking) instead of letting it flow silently into reports.

Then match the communications link to the data:

• Existing SCADA links (fibre, licensed radio, cellular) for control and fast-changing data.
• Low-power wide-area networks such as LoRaWAN for battery-powered, low-rate monitoring at distributed sites. See LoRaWAN for water utilities.
• Cellular where a site has power but no other link.

Weigh update rate, latency, power availability, coverage, who owns the network and the recurring cost. In Canada, long distances between sites and patchy cellular coverage in rural and remote areas often decide the question, and winter conditions affect both instruments (frost, ice, condensation) and battery life. Standard protocols such as Modbus, DNP3, OPC UA and MQTT keep the options open.

Phase 3: Data platform, dashboards and KPIs

The platform can be an extension of the existing SCADA and historian, a time-series database, a cloud service or a combination. Whatever the choice, a few principles hold:

• Keep one authoritative model of assets and tags, with units, engineering ranges and hierarchy.
• Store raw, time-stamped data, and document how every KPI is calculated.
• Insist on open interfaces and on the right to export your data.
• Decide where the data will be hosted. Many Canadian utilities and industrial operators prefer, or are required by their own policies, to keep operational data in Canada, so ask any platform vendor which hosting regions they offer.
• Make the path from control systems to the platform read-only, so analytics cannot disturb operations.

Design dashboards for roles, not for completeness. Operators need live status and clear alarms. Maintenance supervisors need a prioritized work picture. Managers need a small set of trends. Alarm design deserves particular care: a system that raises hundreds of low-value alarms trains people to ignore all of them. The ISA-18.2 and EEMUA 191 guidance on alarm management is a sound reference for rationalizing alarms.

Phase 4: Analytics

Begin with simple, explainable logic: thresholds, rate-of-change checks and mass balances such as inflow against outflow. Move to statistical baselines once data quality is proven. Use machine learning where there is enough data and enough recorded outcomes to justify it. Our article on condition monitoring for pumps shows how that progression looks in practice.

People, training and cybersecurity

Two threads run through every phase. The first is people. Someone must own data quality, someone must own sensor calibration, and operating procedures must say who responds to what. Operators who understand how to read a trend will trust the system; those who were not involved will work around it. Training is part of the budget, not an afterthought.

The second is cybersecurity. Connecting assets adds exposure, so design for it from the start: separate operational technology from corporate IT, use least-privilege remote access with multi-factor authentication, keep an asset inventory, plan for patching and backups, and manage wireless device keys properly. IEC 62443 is the main international series of standards for the security of industrial automation and control systems.

Common pitfalls

• Buying the platform first. The use case should select the tool, not the reverse.
• Building dashboards instead of decisions. Every screen should answer a question someone actually asks.
• Trusting unverified sensors. Bad data on a good dashboard is worse than no dashboard.
• No data owner. Data quality decays without a named person responsible.
• Ignoring what already works. Existing PLCs and SCADA often hold most of the data you need. Connect them before replacing them.
• Counting only capital cost. Connectivity, licences, calibration and support recur every year.
• A pilot with no path to scale. Decide in advance how a successful pilot would be extended.
• Security as a later phase. It is far cheaper to design in than to retrofit.

Start small and agree on the finish line

Choose one site or one problem. Agree on three to five measurements, the success criteria and a review date before any hardware is ordered. Run the pilot long enough to see normal variation, including a seasonal or demand change if possible, then decide whether to extend, adjust or stop. A small pilot that is measured honestly is worth more than a broad rollout that is not.