Connecting SCADA to a Water Digital Twin

A water digital twin is a hydraulic model that reads the network's own measurements, so the connection to SCADA is what turns a model into a twin. Making that connection is mostly data work. You decide which signals the model needs, match each SCADA tag to the right pipe, pump or tank in the model, read the values without touching the control system, and reject bad readings before the model uses them.

How do you connect SCADA to a hydraulic model?

In five steps. List the measurements the model needs and check which already exist. Map each SCADA tag to an element in the model. Read the values from the historian on a schedule, not from the control network. Check and clean them. Then run the model on them and compare what it predicts with what was measured. The software at each step can be commercial or open source, and the steps are the same either way.

What SCADA data does a hydraulic model need?

• Boundary conditions, which drive the model: reservoir and tank levels, flows out of treatment works and into each district, pump states or speeds, and valve settings.
• Check points, which the model is compared against rather than fed with: pressures and flows inside the network. A twin with no independent pressure readings has nothing to test itself against.
• Demand, usually district inlet flows shared out over customers using billing records, and smart meter readings where a utility has them.

SCADA is usually designed to run treatment works and pump stations, so it often measures the edges of the network well and the inside poorly. Finding that gap early, and adding pressure loggers where the model is least certain, is part of the job.

Why does tag mapping take the longest?

A SCADA tag is a name such as PS03_P2_RUN with a value and a timestamp. The model knows the same pump by an element ID in a different system, often named by a different team years apart. Someone has to build the table that links each tag to its element, with units, the flow direction that counts as positive, and the periods when the tag can be trusted. That table also has to be maintained. When a pump station is upgraded and its tags are renamed, the twin stops matching the network without any error unless someone updates it.

Keep the mapping as a file under version control with a named owner, not inside one engineer's project file.

Should a digital twin read from SCADA directly?

No. The twin should read from the SCADA historian, or a copy of it, through a one way connection, and never connect to the PLCs or the control network. Operators are right to refuse anything that could write to a live control system, and the historian already holds the timestamped record the model needs. Common routes are a database query against the historian, a scheduled export, or OPC UA, the industrial standard for reading plant data. Under IEC 62443, the standards for industrial control system security, the usual design places that copy in a separate network zone between the control system and the office network.

Sending settings back, such as a pump schedule, is a separate decision with its own approval and fail safe limits, which we cover in digital twin vs digital shadow. Start read only.

What data checks does a twin need?

Raw SCADA data has faults a hydraulic model cannot recognise, and each needs an automatic check:

• Gaps from lost communications, which must be filled or flagged, never read as zero.
• Flatlines, where a failed instrument keeps reporting its last value.
• Spikes, and values outside the range the instrument can measure.
• Clock faults: time zones, daylight saving changes and outstation clocks that have drifted.
• Units and datums, such as a tank level in metres above the tank floor fed to a model that works in metres above sea level.

When a check fails, the twin should report which reading it rejected and carry on with the rest. A model that accepts a flatlined tank level will produce a confident, wrong pressure map.

How often should the model run?

As often as the decision it supports. Every 15 minutes to an hour is common for network twins, since many network loggers record at 15 minute intervals, and it is fast enough for most operational questions. Pump scheduling against electricity tariffs needs a forecast run a day or a few hours ahead. Burst response needs a run on demand, while someone is deciding which valves to close.

How do you compare digital twin platforms for SCADA integration?

Ask each vendor to connect to a copy of your own historian during the evaluation and to show you the tag mapping, not a demonstration network. Then ask:

• Which historians and protocols can it read from, and is the connection read only?
• Where is the tag mapping kept, and can your own staff edit it when tags change?
• What does it do with a gap, a flatline or a wrong timestamp, and does it tell anyone?
• Does it run on your servers or in the vendor's cloud, and where is the data stored?
• Which hydraulic model sits inside it, and can your engineers open that model in software they already use?
• If the contract ends, do you keep the mapping, the cleaned data and the calibrated model?

The products are compared in digital twin software for water utilities compared.

Can you build the SCADA link with open source tools?

Yes. A scheduled script can read from the historian or an OPC UA server, apply the checks above, store the results in a timeseries database and run EPANET through WNTR or EPyT with the cleaned values. The storage choice is covered in timeseries databases for water telemetry. The code is the smaller part of the work. Tag mapping, data checks and calibration take most of the effort whichever software you choose.

Smart Bhujal builds this layer: the tag mapping, the read only connection, the data checks and the calibrated model they feed. Where live sensors exist we connect them, and where they do not yet, the twin starts from the data a utility already holds. See our water digital twins and water distribution modeling pages.