How it works¶
It is a challenge to evaluate the effect of a control approach meant for real-time application, even with a running operational pilot. If the real-world system does not follow the optimised set-points, then the system is not brought forward to the state expected by the controller, instead it moves to the state that the actual regulation takes it to. This means that we cannot evaluate the full effect of the recurring optimisation, because each time the optimisation starts over, it starts out from a state which was not a product of the previous optimisation but a result of the actual control.
What we can evaluate from the operational pilot is how robust the RTC robot is in operation, how long time it takes to finish a computational cycle, and how the demand forecast and the proposed set-points evolve over time.
Evaluation of the effect of the repeated optimisation without sending the set-points to the real-world system requires an emulated real-time environment, where a detailed model is used to simulate the real-world response and provide initial conditions for the next optimisation. In the project we chose not to follow this path in favour of getting the operational pilot running.
Performance measures of the RTC robot¶
The RTC robot is evaluated with respect to the below qualitative measures
- Robust in operation - how often does the RTC robot's calculation fail, and what triggers failure?
- Speed - is the RTC robot fast enough to use in an operational system?
- Advantage over simpler control approaches - what is the gain of a more advanced control approach?
Robust in operation¶
To evaluate the robustness, we have watched the operational pilot during three months (April to June 2021), where it has been set up to execute the RTC robot hourly. The RTC robot is based on a chain of data acquisition, preparation of data and models for demand and for optimisation of the set-points. If any of the components fails, then in the "best case" no optimised set-points are calculated - in the worst case set-points are calculated based on erroneous input. During the three months we have experienced
- A sensor, which changed name in Aarhus Vand's operational system, and therefore stopped delivering data to the pilot. This was not detected by the RTC robot, which kept on calibrating the network model's resistance parameters daily, using zeros for the flawed pressure sensor. The consequences were that the resistance in links connected to this sensor slowly but steadily decreased, even to (unphysical) negative values. The steady deterioration of the calibration happens because the calibration uses the latest 30 days to estimate the network resistances. And this 30-day window advanced one day every day, including more and more of the erroneous data.
- The database underlying the DIMS.CORE on CHAINvm ran full. This could happen, because no archiving policy had been set up for the database. The consequence was a gap in the data collected in the operational pilot. The gap is about two days long - the time it took from discovering that "something is wrong" to having made a fix.
The first incidence taught us that the established guarding against anomalies needs to be improved. The current work-flow caters for data missing now and then - but not for sensors completely stopping data delivery. From the second incidence we learned that even for an environment set up for experimental purposes we need an archiving policy. This applies for the database as well as for files written to disk during simulation.
Speed¶
It has been a goal of the project to show that it is possible to create models for demand prognosis and and optimisation, which are fast enough to embed in an operational system. The hourly computational cycle on CHAINvm takes 35 min, counted from the last time stamp in the observed data to the time the optimised set-points are returned. So the current configuration of the computational cycle is not "fast enough" to directly use in the operational system, because the optimisation, which has a time resolution of 15 minutes will calculate set-points for minute 00, 15 and 30 that are outdated even before they reach Aarhus Vand's operational system.
However, as most of the 35 minutes is idle time inserted to comfort the development environment that CHAINvm is, we believe that the list of actions can be squeezed to fit within the first 15 minutes after the last time stamp of the observations. This leaves only the set-point at minute 00 as "old news". As the optimisation horizon is 48h long (and thus the optimisation calculates a 48 hour time series of set-points), the natural solution in the operational system is to keep on using the set-points from the previous optimisation until the current optimisation has delivered new set-points. This acting should be taken into account by the current optimisation. In future versions of the RTC robot, we plan to fix the set-point of the first time step in the current optimisation to the value calculated by the previous optimisation.
Advantage over simpler control approaches¶
The RTC robot's advantage over simpler control approaches lies both in the ability to react pro-actively (due to forecasting of the demands), and in the promise of the ability to coordinate flows from waterworks and volumes in elevated storages across pressure zones. The proactive set-point calculation will help stabilising the flow and level variations even if applied only to a single pressure zone. Another advantage of the RTC robot is that the pressure zones can be tested and added individually.
The drawback lies in the increased complexity. The RTC robot is not so easy understandable as rule-based control, and it requires knowledge of the specific site to configure it, even though the models to some extent are data-driven. Furthermore, the approach is sensible to missing data, so precautions must be taken to "ensure the health" of the RTC robot, and report the "health status" back to the operational environment, which must have a fall-back strategy in case the RTC robot fails.
| Advantages | Drawbacks |
|---|---|
| Stabilises the flow from the waterworks with same or less variation in the elevated storage | Not so easy understandable as rule-based control |
| Can be tested and added zone by zone | Necessary with deep site knowledge to configure models |
| Promise of coordination across pressure zones | Sensible to missing data |
Visualisation of the RTC robot¶
A video showing the recurring optimisation¶
This video is an animation of the RTC robot's proposed control of Østerby Waterworks in the pressure zone z80 - as run on CHAINvm. Blue shows the observed waterworks flow (upper panel) and elevated storage level (lower panel) during a period in August 2021. Orange shows how the RTC robot's proposed set-point of the waterworks flow progresses, and how this is predicted to affect the level in the elevated storage. The optimisation clearly seeks to stabilise the flow in the vicinity of 120 m^3/h, and to do so it needs to store more water in the elevated storage on the "declining part" of the daily cycle than historical operation did.
The green line is a target level which the optimisation tries to achieve by penalising deviation from it. This competes another penalty on changing the waterworks flow, and the ratio between the two penalties determine if we get a very smooth flow on behalf of variation in the elevated storage, or we get a stable level in the elevated storage at the cost of a larger flow variation.
The minimum and maximum of the allowed variation range of the elevated storage are shown as green dashed lines. From the level observations we see that the preferred operation range is a much more narrow band. The RTC robot achieves a level, which varies in the same range as the historical operation, but with less variation in the flow from the waterworks.
Note that as the proposed control is NOT carried out in the operational system, the optimisation is initialised from the historical state each time (the orange line coincides with the blue in the first time stamp).
Emulated real-time environment¶
In the beginning of the CHAIN-project, it was the aim to use Aarhus Vand's detailed AQUIS model to simulate an emulated real-time environment. In such a setting, the optimised set-points from the RTC robot are enforced in the detailed model, which calculates the best estimate of the real-world response. However, the possibilities to interact with AQUIS "from outside" were judged insufficient to fulfill the needs for repeatedly manipulating flow set-points and boundary conditions of a running simulation.
The AQUIS simulation (as well as the real-world response) will have an inherent deviation from the optimisation's expectation. This is due to
- inaccurate model - the controller's optimisation is based on simplified dynamics
- imperfect initial conditions - the controller's initial condition is estimated from measurements
- imperfect boundary conditions - the actual demand will deviate from the forecast
- imperfect control - the actuators are not always able to follow the set-points minutely