Skip to content

Summary

Why - how - what

Water utilities operating water distribution networks need an advance in control tools to obtain a more stable regulation than by rule-based control, and to increase the efficiency. In this context, a more stable regulation means decreasing the variation of the flow pumped from the waterworks and/or decreasing the level variation in elevated storages. Increased efficiency covers better coordination between subsystems, upholding supply liability at lower system pressure and increasing supply liability at remote locations.

This can be achieved by making use of mathematical models to predict future demands, and to coordinate flows from waterworks with stored volume in elevated storages across pressure zones. The mathematical models must be computationally light-weight in order to be relevant to an operational system. The optimised control plan should not be "old news" before the calculation is finished.

We have developed an advanced controller, which is based on Model Predictive Control (MPC) and Machine Learning (ML). The overall concept of MPC is plan-execute-replan:

  • The plan step calculates time series of future set-points for the waterworks by an optimisation model. The optimisation model is build on top of a model of the network dynamics and fed by a demand prognosis, which in the present case is calculated by an ML model.
  • The execute step starts carrying the plan out by sending the set-points to the actuators of the waterworks' pumps.
  • After a while, the plan is re-calculated based on newest demand prognosis and current operating point.

Going forward, we will refer to the controller as the RTC robot. The RTC robot is embedded in an operational environment, which every hour receives data from Aarhus Vand and returns the optimised set-points. The operational environment is installed on a virtual machine outside of Aarhus Vand's network, and exchanges data with Aarhus Vand's operational system via sftp. The virtual machine serves as a playground, where different configurations of the RTC robot can be tested in an operation-like environment. At the end of the project two configurations of the RTC robot are running: one configuration is dedicated to Aarhus Vand's experiments, and another one dedicated for DHI's.

Take-home messages

The take-home messages condense our experiences from developing and configuring the RTC robot, and from running it in an operation-like environment for three months. With the operational pilot we have achieved a prototype environment for testing the RTC robot in a close-to-operational setting. The RTC robot is build of configurable components, and we have demonstrated how to configure it for a single pressure zone. This is a solid step towards the vision of the CHAIN project.

Some details:

  • The models developed for the RTC robot are fast enough to be used for real-time control.

    • The execution time of the demand prognosis and the following optimisation is of the order of tens of seconds, and definitely less than one minute.

  • Training/calibration of the coefficients of both ML models and network model can be carried out on-line, based on latest data.

    • The most time-consuming part is the training of the ML models for the demand prognoses.
    • Calibration of the network model runs in tens of seconds.
    • The automatic update is not self-learning, so the models do not "get smarter" the longer time they have been in operation - they are trained/calibrated based on data from a "look-back window" which is a fixed number of days up to the time where the calibration starts.

  • Start out small and simple. Configure the RTC robot for one part of the water distribution network and hook it up to exchange data with the operational system. Then proceed to other subsystems.

    • The optimisation-based control is not as easy understandable as rule-based control, and it takes a close dialogue between the RTC robot modellers and the utility's tech staff to obtain a common understanding of inputs and outputs, and how manipulating the configuration of the RTC robot affects the output.
    • The network model is a physics-based (though simplified) description of the network dynamics. Therefore, insight in the specific site is needed to determine the network layout. Again, a close dialogue between the RTC robot modellers and the utility's tech staff is needed.
    • Understanding sensor data, and setting up work-flows to clean and prepare them for modelling is a big task in itself.

  • Even a single pressure zone with one waterworks and one elevated storage can benefit from being controlled by the RTC robot.

  • With advanced approaches comes increased risk of failure, because a large chain of actions have to be executed in order to calculate the optimised regulation plan.

    • The automatic update of model coefficients (in both ML and network models) is susceptible to missing data, and we need to improve handling of these events, which occur more often than you would think.
    • A utility using the RTC robot needs to implement a fall-back strategy if the RTC robot fails (for instance: fall back to rule-based control if a specified number of attempts to calculate a control plan fails).
    • We need to develop methods to detect "the health of the RTC robot", so a flag for failure can be returned to the operational system.