Project Title:
Intelligent Urban Water Management System
Project Acronym:
URBANWATER
Seventh Framework Programme
Collaborative Project
Grant Agreement Number 318602
Subject:
D4.1 – Decision supporting tools system requirements– WP4
Dissemination Level: PUBLIC
Lead beneficiary: Hydrometeorological Innovative Solutions
Revision Preparation date Period covered Project start date Project Duration
FINAL September 2014 Months 02 to 18 December 2012 30 Months
This project has received funding from the European Union’s Seventh Framework Programme for research, technological development
and demonstration under grant agreement no. 318602.
This publication reflects only the authors’ views and the European Union is not liable for any use that may be made of the information
contained therein.
Deliverable D4.1 – Decision supporting tools system requirements
2
URBAN-WATER PUBLIC
Grant Agreement: 318602
History of Changes
Version Author, Institution Changes
0.1 Alvaro Rodriguez,HYDS
Markus Koch, ORGA
Stephan Flake, ORGA
Contents definition, some information on each
section, apply changes provided by Markus Koch
and Stephan Flake, use v2 template, add new
scenarios, use cases and requirements for WAPS
0.2 Mario Vasak, UNIZG-FER Changes on some sections, added WDPS content
0.3 Carla Silva, AQUA
Francisco Freire de Carvalho, AQUA
Added LDS scenarios
0.4 Mario Vasak, UNIZG-FER
Goran Banjac, UNIZG-FER
Rafael Sanchez-Diezma, HYDS
Included WDPS and DICM information, and
sections 2 and 3
0.5 David Sancho, HYDS
Rafael Sanchez-Diezma, HYDS
Alvaro Rodriguez, HYDS
Complete section 5, include information of
annexes
0.6 Alvaro Rodriguez, HYDS First draft version to be reviewed
1.0 Stephan Flake, ORGA Added comments from ORGA
1.1 Mario Vasak, UNIZG-FER Added comments from UNIZG-FER
Added DICM requirements
1.2 Carla Silva, AQUA Modifications on LDS by AQUA
1.3 Alvaro Rodriguez, HYDS
Rafael Sanchez-Diezma, HYDS
Complete sites information
1.4 Alvaro Rodriguez, HYDS Sites description removed
SW information removed
Modifications taking into account issues raised by
the EC reviewers
Some missing requirements have been added
1.5 Mario Vasak, UNIZG-FER
Alvaro Rodriguez, HYDS
Minor modifications made
Added UNIZG-FER’s contributions
Added HYDS’ contributions
1.6 Carla Silva, AQUA
Stephan Flake, ORGA
Markus Koch, ORGA
Added AQUA contributions
Modifications according to ORGA review
Deliverable D4.1 – Decision supporting tools system requirements
3
URBAN-WATER PUBLIC
Grant Agreement: 318602
Abstract
This document contains the users’ requirements description for the Spatial Decision Support System (SDSS) as
well as for the other four modules that support the SDSS: the water availability prediction system (WAPS), the water
demand prediction system (WDPS), the detailed indoor consumption model (DICM) and the leakage detection
system (LDS). The requirements have been developed through the definition of several scenarios in order to identify
the context of functioning of each module. Specifically for the SDSS, some scenarios have been proposed that
account for the interaction not only with the other WP4 supporting tools but also with other elements of the
UrbanWater platform in order to provide a more integrated approach. As a previous step to develop such scenarios
a review of concepts related to water resources and water management practices has been performed, as well as
a compilation of current practices used by the stakeholders of the project (Aqualia and Tavira Verde).
According to reviewers’ comments, this version of the document contains a complete description of the
documentation and procedures done to define the scenarios, use cases and requirements of each module. This
information is available in section 8, and the comments raised by the reviewers can be found at section 9.
Deliverable D4.1 – Decision supporting tools system requirements
4
URBAN-WATER PUBLIC
Grant Agreement: 318602
List of Acronyms
Acronym Full Name
AdA Águas do Algarve
AdP Águas de Portugal
AMR Automatic Meter Reading
APA Agència Portuguesa do Ambiente
APS Adaptive Pricing System
AQ Aqualia
DICM Detailed Indoor Consumption Model
DMA District Meter Area
ERSAR Entidade Reguladora dos Serviços de Águas e Resíduos
GIS Geographic Information System
HGT Height
HMB Hydraulic Model Builder
IPMA Instituto Portugués do Mar e da Atmosfera
LDS Leakage Detection System
MB Mass Balance
NASA National Aeronautics and Space Administration
NFA Night Flow Analyzer
NWP Numerical Weather Prediction
OGC Open Geospatial Consortium
SCADA Supervisory Control and Data Acquisition
SDSS Spatial Decision Support System
SW Scottish Water
Tave Tavira Verde
UW UrbanWater
WAPS Water Availability Prediction System
WD Water Distributor
WDN Water Distribution Network
Deliverable D4.1 – Decision supporting tools system requirements
5
URBAN-WATER PUBLIC
Grant Agreement: 318602
WDPS Water Demand Prediction System
WFS Web Feature Service
WMS Web Map Server
WRZ Water Resource Zone
WTP Water Treatment Plant
Deliverable D4.1 – Decision supporting tools system requirements
6
URBAN-WATER PUBLIC
Grant Agreement: 318602
Table of Contents
History of Changes .................................................................................................................................................. 2
Abstract ................................................................................................................................................................... 3
List of Acronyms ...................................................................................................................................................... 4
Table of Contents .................................................................................................................................................... 6
List of Figures ........................................................................................................................................................ 11
List of Tables ......................................................................................................................................................... 11
1 Introduction ................................................................................................................................................... 12
1.1 Objectives of UrbanWater ....................................................................................................................... 12
1.2 Objectives of WP 4 (Decision supporting tools) ...................................................................................... 13
1.3 Objectives of this document .................................................................................................................... 14
1.4 Structure of this document ...................................................................................................................... 14
2 Water supply system .................................................................................................................................... 15
2.1 Generic description of water supply elements and management activities ............................................. 18
2.1.1 Reservoirs........................................................................................................................................ 18
2.1.2 Groundwater – water boreholes ...................................................................................................... 21
2.1.3 Water treatment plants .................................................................................................................... 23
2.1.4 Distribution systems ......................................................................................................................... 25
2.1.5 Consumption.................................................................................................................................... 27
3 Approach of the UrbanWater SDSS ............................................................................................................. 29
3.1 SDSS configuration and usage example ................................................................................................. 32
4 Roles and actors ........................................................................................................................................... 36
4.1 Roles ....................................................................................................................................................... 37
4.2 Actors ...................................................................................................................................................... 37
5 Spatial decision support system ................................................................................................................... 40
5.1 Scenarios ................................................................................................................................................ 40
5.1.1 Normal operation ............................................................................................................................. 40
5.1.2 A new reservoir has been built in the site ........................................................................................ 42
5.2 Use cases ............................................................................................................................................... 42
5.2.1 Modify SDSS configuration .............................................................................................................. 43
5.2.2 Modify the topology of the water supply system representation ...................................................... 43
5.2.3 Compute new status (online mode) ................................................................................................. 44
5.2.4 Compute new status (offline mode) ................................................................................................. 44
5.2.5 Display configuration ....................................................................................................................... 45
5.2.6 Display the topology of the water supply system representation ..................................................... 45
5.2.7 Display the topology of the water supply system ............................................................................. 46
5.2.8 Retrieve status ................................................................................................................................. 46
5.3 Requirements .......................................................................................................................................... 47
5.3.1 Retrieve demand prediction ............................................................................................................. 47
5.3.2 Retrieve availability prediction ......................................................................................................... 47
5.3.3 Retrieve leakages detection ............................................................................................................ 48
5.3.4 Retrieve water utility data ................................................................................................................ 48
5.3.5 Modify the topology of the water supply system representation ...................................................... 48
5.3.6 Modify SDSS configuration .............................................................................................................. 49
Deliverable D4.1 – Decision supporting tools system requirements
7
URBAN-WATER PUBLIC
Grant Agreement: 318602
5.3.7 Compute SDSS status (online mode) .............................................................................................. 49
5.3.8 Compute SDSS status (offline mode) .............................................................................................. 49
5.3.9 Store SDSS status ........................................................................................................................... 50
5.3.10 Provide SDSS status ................................................................................................................ 50
5.3.11 Display the topology of the water supply system representation .............................................. 50
5.3.12 Display the topology of the water supply system ...................................................................... 50
5.3.13 Send notifications through the platform..................................................................................... 51
6 Decision supporting tools .............................................................................................................................. 52
6.1 Water demand prediction system ............................................................................................................ 52
6.1.1 Scenarios ......................................................................................................................................... 52
6.1.1.1 Leakage detection system ................................................................................................... 53
6.1.1.2 Adaptive pricing system ....................................................................................................... 53
6.1.1.3 SDSS ................................................................................................................................... 54
6.1.1.4 UrbanWater Cloud Database ............................................................................................... 54
6.1.1.5 Detailed indoor consumption module ................................................................................... 54
6.1.2 Use cases ........................................................................................................................................ 55
6.1.2.1 Compute water demand prediction for the required water distribution network point ........... 55
6.1.2.2 Initialize water demand prediction model for the required water distribution network point .. 56
6.1.3 Requirements .................................................................................................................................. 56
6.1.3.1 Sampling time and prediction horizon length ....................................................................... 56
6.1.3.2 Accuracy .............................................................................................................................. 57
6.1.3.3 Adaptation to demand changes............................................................................................ 57
6.1.3.4 Estimation of the prediction uncertainty ............................................................................... 57
6.1.3.5 Ability of automated initialisation .......................................................................................... 57
6.1.3.6 Cooperation with other modules ........................................................................................... 58
6.1.3.7 Responsive to other modules’ outputs ................................................................................. 58
6.1.3.8 Immunity to outliers in the recorder flow data and to false measurements .......................... 58
6.2 Detailed indoor consumption module ...................................................................................................... 58
6.2.1 Scenarios ......................................................................................................................................... 59
6.2.2 Use cases ........................................................................................................................................ 59
6.2.2.1 Perform characterisation of the water meter signature......................................................... 59
6.2.2.2 Update characterisation model for a particular household ................................................... 60
6.2.3 Requirements .................................................................................................................................. 60
6.2.3.1 Ability to interpret commercial smart water meter signature as a sequence of usages of water
devices 60
6.2.3.2 Ability to adapt to the individual household .......................................................................... 61
6.3 Water availability prediction system ........................................................................................................ 61
6.3.1 Scenarios ......................................................................................................................................... 62
6.3.1.1 Water availability prediction system ..................................................................................... 62
6.3.1.2 SDSS ................................................................................................................................... 62
6.3.2 Use cases ........................................................................................................................................ 63
6.3.2.1 Compute short-term water availability prediction for the reservoirs ...................................... 63
6.3.2.2 Compute long-term water availability prediction for the reservoirs ....................................... 63
6.3.2.3 Display availability for reservoir ............................................................................................ 64
6.3.3 Requirements .................................................................................................................................. 64
Deliverable D4.1 – Decision supporting tools system requirements
8
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.3.3.1 Retrieve radar data .............................................................................................................. 64
6.3.3.2 Retrieve rain gauges data .................................................................................................... 64
6.3.3.3 Retrieve precipitation from NWP data .................................................................................. 65
6.3.3.4 Retrieve aggregated hydrological model description of a basin ........................................... 65
6.3.3.5 Retrieve reservoir volumes’ historical data ........................................................................... 65
6.3.3.6 Quality control of radar precipitation estimations ................................................................. 65
6.3.3.7 Calculate radar nowcast ....................................................................................................... 66
6.3.3.8 Calculate rainfall accumulation from radar instantaneous precipitation fields ...................... 66
6.3.3.9 Calculate accumulations from rain gauges .......................................................................... 67
6.3.3.10 Combine radar and rain gauges ........................................................................................... 67
6.3.3.11 Combine radar nowcast with NWP models .......................................................................... 67
6.3.3.12 Calculate short-term water predicted volumes using aggregated hydrological model .......... 68
6.3.3.13 Calculate long-term seasonal forecasting ............................................................................ 68
6.3.3.14 Display water availability information ................................................................................... 68
6.3.3.15 Send notification: new short-term water availability prediction available .............................. 69
6.3.3.16 Send notification: new long-term water availability prediction available ............................... 69
6.4 Leakage detection system....................................................................................................................... 69
6.4.1 Scenarios ......................................................................................................................................... 69
6.4.1.1 Normal and maintenance operation ..................................................................................... 69
6.4.1.2 The water supply system topology has changed ................................................................. 71
6.4.1.3 Normal operation of the water supply system (Extreme events) .......................................... 71
6.4.2 Use cases ........................................................................................................................................ 72
6.4.2.1 Check raw data quality, perform correction and validation ................................................... 72
6.4.2.2 Evaluate past leakage level with Mass Balance ................................................................... 72
6.4.2.3 Evaluate past leakage level with Minimum Night Flow Analysis .......................................... 73
6.4.2.4 Set up Hydraulic Model for leakage analysis ....................................................................... 73
6.4.2.5 Monitor leakage in near real-time ......................................................................................... 74
6.4.2.6 Set up automated monitoring and alerts .............................................................................. 74
6.4.2.7 Perform network leakage simulation (prospective)............................................................... 75
6.4.3 Requirements .................................................................................................................................. 75
6.4.3.1 Retrieve flow data ................................................................................................................ 75
6.4.3.2 Retrieve pressure data ......................................................................................................... 75
6.4.3.3 Retrieve topology data ......................................................................................................... 75
6.4.3.4 Retrieve terrain elevation data ............................................................................................. 76
6.4.3.5 Retrieve water demand prediction data ................................................................................ 76
6.4.3.6 Provide data series (flow/pressure) validation ...................................................................... 76
6.4.3.7 Calculate and provide leakage with Mass Balance .............................................................. 76
6.4.3.8 Calculate and provide leakage with Minimum Night Flow Analysis ...................................... 77
6.4.3.9 Build and provide a Hydraulic Model of the network ............................................................ 77
6.4.3.10 Display Mass Balance information ....................................................................................... 77
6.4.3.11 Display Minimum Night Flow analysis .................................................................................. 77
6.4.3.12 Display a Hydraulic Model of the network ............................................................................ 78
6.4.3.13 Send a notification ................................................................................................................ 78
6.4.3.14 Send an alert ........................................................................................................................ 78
7 Conclusion and Outlook ................................................................................................................................ 79
Deliverable D4.1 – Decision supporting tools system requirements
9
URBAN-WATER PUBLIC
Grant Agreement: 318602
8 Annex I: Requirements collection methodology ............................................................................................ 80
8.1 SDSS requirements................................................................................................................................. 80
8.2 WDPS requirements................................................................................................................................ 86
8.3 DICM requirements ................................................................................................................................. 87
8.4 LDS requirements ................................................................................................................................... 88
8.5 WAPS requirements ................................................................................................................................ 90
8.6 Included documentation .......................................................................................................................... 93
8.6.1 Minutes meetings ............................................................................................................................. 94
8.6.1.1 2013/07/09 – Meeting with Scottish Water ........................................................................... 94
8.6.1.2 2013/07/22 – Meeting with Tavira Verde .............................................................................. 96
8.6.1.3 2013/12/13 – Meeting with Ateknea ..................................................................................... 97
8.6.1.4 2014/02/11 - Meeting with Scottish Water ............................................................................ 98
8.6.1.5 2014/03/18 - Meeting with Tavira Verde and APA ............................................................. 100
8.6.1.6 2013/01/24 – Meeting with Tavira Verde ............................................................................ 102
8.6.1.7 2013/05/08 – Meeting with Scottish Water and Tavira Verde ............................................ 102
8.6.1.8 2013/11/04-05 – Meeting with Scottish Water .................................................................... 103
8.6.2 Follow up template reference to discuss operational rules ............................................................ 103
8.6.2.1 Introduction ........................................................................................................................ 103
8.6.2.2 Scenarios ........................................................................................................................... 106
8.6.2.3 Strategies ........................................................................................................................... 107
8.6.2.4 Reservoirs .......................................................................................................................... 107
8.6.2.5 Water tanks ........................................................................................................................ 108
8.6.3 Follow up template reference to complete discussions ................................................................. 108
8.6.3.1 General considerations ...................................................................................................... 108
8.6.3.2 Water sources .................................................................................................................... 108
8.6.3.3 Raw water sources ............................................................................................................. 109
8.6.3.4 Water allocation ................................................................................................................. 111
8.6.3.5 Drinking water producers ................................................................................................... 111
8.6.3.6 Distribution elements .......................................................................................................... 113
8.6.3.7 Other elements ................................................................................................................... 115
8.6.3.8 Water consumption ............................................................................................................ 115
8.6.3.9 Raw water suppliers management ..................................................................................... 117
8.6.3.10 Drinking water suppliers management ............................................................................... 117
8.6.4 Stakeholder’ surveys ..................................................................................................................... 117
8.6.4.1 General documentation about the water supply system:.................................................... 117
8.6.4.2 Information/description about the stakeholders/roles involved in the supply chain and
responsibilities ....................................................................................................................................... 118
8.6.4.3 Information about the general management processes ..................................................... 118
8.6.4.4 Specific information about the management of each of the elements ................................ 120
8.6.5 Tavira Verde documentation .......................................................................................................... 126
8.6.6 Scottish Water documentation ....................................................................................................... 130
8.6.7 Others ............................................................................................................................................ 130
8.6.7.1 Data needs for identification of water demand & detailed indoor consumption .................. 130
9 Annex III: reviewers comments ................................................................................................................... 134
9.1 First review comments (January 2014) ................................................................................................. 134
Deliverable D4.1 – Decision supporting tools system requirements
10
URBAN-WATER PUBLIC
Grant Agreement: 318602
9.1.1 Solutions / amendments ................................................................................................................ 134
9.2 Second review comments (May 2014) .................................................................................................. 134
9.2.1 Solutions / amendments ................................................................................................................ 135
Deliverable D4.1 – Decision supporting tools system requirements
11
URBAN-WATER PUBLIC
Grant Agreement: 318602
List of Figures
Figure 1: Scheme of main concepts related to reservoirs management .......................................................... 21
Figure 2: Scheme of main concepts related to groundwater management ...................................................... 23
Figure 3: Scheme of main concepts related to WTPs management ............................................................... 25
Figure 4: Scheme of main concepts related to distribution systems management ........................................... 26
Figure 5: Scheme of main concepts related to consumption management ..................................................... 28
Figure 6: Schema of main concepts related to integrated water system management ..................................... 31
Figure 7: Topology of the water supply system used in the example .............................................................. 32
Figure 8: How the SDSS configuration is built ............................................................................................. 34
Figure 9: Normal operation scenario diagram .............................................................................................. 41
Figure 10: New reservoir scenario diagram ................................................................................................. 42
Figure 11: Envisaged modules’ outputs flow on the UrbanWater platform with respect to WDPS ...................... 53
Figure 12: UW modules interaction with WAPS ........................................................................................... 62
Figure 13: Sotavento WDN ...................................................................................................................... 128
Figure 14: Barlovento WDN ..................................................................................................................... 128
Figure 15: EPANET model detail in Tavira WTP ........................................................................................ 129
List of Tables
Table 1: UrbanWater decision supporting tools roles .................................................................................... 37
Table 2: UrbanWater decision supporting tools actors .................................................................................. 39
Table 3: Use case template ....................................................................................................................... 43
Table 4: Requirements definition template .................................................................................................. 47
Deliverable D4.1 – Decision supporting tools system requirements
12
URBAN-WATER PUBLIC
Grant Agreement: 318602
1 Introduction
1.1 Objectives of UrbanWater
Improving the efficiency of water management in Europe is recognized as essential for overcoming the growing
exposure of European countries to increasing populations and water scarcity and droughts.
The objective of the UrbanWater Project (http://urbanwater-ict.eu/) is to enable better end-to-end water
management in urban regions, where “17% of the abstracted water is used for public water supply (including
households, the public sector and small businesses) and 15% for industry” (see [1] for more details).
The project will develop an innovative Information & Communication Technology (ICT) based platform for the
efficient, integrated management of water resources.
The system will benefit consumers, water utilities, public authorities, the environment and the general public in
terms of:
• Providing consumers with comprehensive tools enabling them to use water more efficiently, thereby better
adapting overall consumption to the supply possibilities.
• Helping water utilities to meet demand at the right price, according to its pattern of consumption.
• Fostering new partnerships between stakeholders so as to ensure the successful development of the system
and the evolution of the European Water Sector as a global leader.
The IUWMS will likely incorporate:
• advanced metering solutions;
• real-time communication of supply / demand data;
• new data management technologies with real-time predictive capability;
• supply / demand forecasting;
• demand pattern interpretation;
• decision support systems;
• adaptive pricing;
• user empowerment solutions.
The UrbanWater consortium includes ICT companies, research organizations, water utilities and authorities with
complementary capacities and know-how. Two water utilities included in the group will undertake large-scale
validations on their water supply systems, thus promoting a final outcome that is close to the market and to the
consumers. The final outcome of the project will remain open and interoperable with energy and water management
schemes, thus positively impacting not only water consumption, but overall usage of natural resources throughout
Europe.
Deliverable D4.1 – Decision supporting tools system requirements
13
URBAN-WATER PUBLIC
Grant Agreement: 318602
1.2 Objectives of WP 4 (Decision supporting tools)
The goal of WP4 is to provide a spatial decision support system (SDSS) and decisional supporting tools to the
integrated UrbanWater platform proposed by the project, considering present and future conditions that could affect
the management strategies related to the existing water resources in a given region. The SDSS has two main
targets:
On the one hand, to provide the water management authorities with potential decisions to take in order to
improve the quality/efficiency of the procedures that they currently perform. As a general approach the
SDSS will be oriented to improve the existing management strategies but also be focused on creating a
decision context focused on providing a balance between water supply and demand considering real-time
data and forecast data.
On the other hand, an additional aim is that the decision support system will provide utilities the estimation
of technical costs of water distribution with respect to the amount of water delivered under the current
conditions, as well as the interfacing costs of water distribution with systems leaned to it – water sourcing
and treatment from one side, and sewage/used water treatment from the other side. This information
should be then forwarded to the Adaptive Pricing System (APS) module to assess the optimal water
distribution price profile for near future.
In the context of UrbanWater this decision support system will integrate four basic modules:
The water demand prediction system (WDPS) aims to provide real-time information about forecast
demand conditions in a certain point of the water distribution network in the following days using historical
data as well as current information (about demand trends and weather information). It will be integrated
into the SDSS to work in conjunction with the water availability prediction system (WAPS) and also provide
demand data to other modules of the platform.
Detailed indoor consumption model (DICM) will be used to interpret individual users’ consumption profiles,
i.e. their water meter signatures, as a sequence of different household water devices usages (pipes or
appliances). It will adapt to a particular household through a simple and non-invasive interaction with the
end-user. Applied across many households it will be used as a source of data how much and when
different household devices are used in order to better understand the demand drivers from the utility side.
Furthermore DICM will enable to introduce competitions between end-users as a basis for users’
behaviour change with respect to water consumption. DICM thus borders between the decision support
and the user empowerment tools.
The water availability prediction system (WAPS), that is based on current and forecast
hydrometeorological conditions (rain gauges, river level sensors, weather radar data, numerical weather
prediction models, hydrological and hydraulic models, etc.) will provide a forecast of water availability in
upstream elements such as dams or reservoirs. The major objective of WAPS is to deliver real-time
continuous and detailed information of current and future dams’ storage conditions that could be integrated
into the SDSS.
The leakage detection system (LDS), that will integrate information from historical and real-time
measurements from the distribution network, will be able to evaluate water losses based on different
approaches (Mass Balance, Minimum Night Flow Analysis, Hydraulic Model) In relation to WP4 a major
objective will be to integrate the leakage detection system as a real-time module of the SDSS.
In essence each of the previous modules/systems will require input information to provide a forecast of the future
state or interpretation of the provided input in a new sense (e.g. detected leak or assessed detailed household
Deliverable D4.1 – Decision supporting tools system requirements
14
URBAN-WATER PUBLIC
Grant Agreement: 318602
water usage). The spatial decision support system will combine that information and the forecasts to propose the
water utilities’ operators possible future scenarios and ideally the optimal decisions to take. In addition, the modules
can deliver information to the Adaptive Pricing System module (developed within UrbanWater Work package 5).
1.3 Objectives of this document
This deliverable D4.1 “Decision supporting tools system requirements” describes the requirements posed on the
decision supporting tools of the UrbanWater platform. Requirements define what the decision supporting tools and
the spatial decision support system should be able to perform within the platform.
The decision supporting tools are WDPS, WAPS and LDS, and also DICM which is shared between decision
support and user empowerment. The requirements on each are elaborated through set-ups of module users
(scenarios) and within each such set-up through various situations that might arise (use cases). The different
scenarios and use-cases finally yield a set of requirements for the tools.
1.4 Structure of this document
Following this introduction, the report includes the following sections:
Section 2 describes management activities performed in the context of operating systems that integrate
elements related to the water processing chain (pooling, storing, treatment, distribution, etc.).
Section 3 presents the approach of the UW SDSS in the context of the information described in section 2,
and specifically the importance of the four supporting tools to be integrated in WP4.
Section 4 describes the roles and actors used for generation of the scenarios.
Sections 5 and 6 describe scenarios, use cases and requirements for the SDSS and the four supporting
tools (WDPS, DICM, WAPS and LDS). Presented requirements are the more technical and
implementation-specific according to the identified scenarios and use cases.
Finally in the annex the methodology to collect the requirements is explained.
Deliverable D4.1 – Decision supporting tools system requirements
15
URBAN-WATER PUBLIC
Grant Agreement: 318602
2 Water supply system
Water supply systems are integrated by a group of infrastructures that allows for the collection, transmission,
treatment, storage and distribution of water to users (households, commercial establishment, industry, irrigation,
hydropower, etc.). The basic objective of the supply system is to manage water availability to satisfy the demand
(both in terms of quantity and quality) that is shaped by the different users and that can have very different
requirements.
Basic sources of fresh water are surface water, under river flow water, groundwater and desalination. Water supply
systems integrate these sources into elements that aim to capture and manage their water reducing as much as
possible those aspects that limit their availability.
The availability of surface water (which is water that is present in rivers, lakes or wetlands), is affected by the cycle
of replenishing, by precipitation and loss, and by discharge to the oceans. From the point of view of the management
of this source it is important to notice that the total amount (and quality) of surface water depends on many factors:
storage capacity in lakes, artificial reservoirs, wetlands, the permeability of the soil in the context of these storages,
the runoff characteristics of the land in the watershed, the variability of precipitation and evaporation rates. As a
result availability of surface water in many areas is strongly dependent on the construction and management of
artificial reservoirs that can ensure a certain degree of continuity for the resource.
Under river flow is the main contribution to flows in many rivers, which additionally might include the surface water
flow. Under river flow is the water flowing through sub-surface rocks and gravels that underlie the river. In this case
direct river water extraction for water management supply is not rare in areas with large basins or areas, where
rainfall regimes allow for a continuous supply from the river.
Ground water is fresh water located in the pore space of soil and rocks. It is also water that is flowing within aquifers
below the groundwater level. Ground water generation implies a slow rate of reposition so one of the major problems
is the exhaustion of these sources due to over-exploitation, which in coastal locations can be aggravated by saline
intrusions. From the point of view of a supply system groundwater is highly appreciated since it has a superior
quality in front of surface water and in many cases no additional treatment is required. On the contrary this water
source is highly sensible to recharges so many management strategies limit its exploitation or preserve its use for
dry or scarcity periods. Moreover, it is supplied using pumps, which implies higher energy costs.
Finally, desalination is an artificial process by which saline water (generally sea water) is converted to fresh water.
The most common desalination processes are distillation and reverse osmosis. Nowadays desalination is
expensive compared to most alternative sources of water and it is only economically practical for high-valued uses
(such as household and industrial uses) and in areas with severe constraints in other water sources (e.g. due to
persistent drought conditions).
From the point of view of the demand we can differentiate several users with specific requirements concerning the
impact on the management of the supply system:
Agricultural: it is estimated that 70% of total worldwide water use is for irrigation, with 15-35% of irrigation
withdrawals being unsustainable. Irrigation is extending as a common agricultural process since it allows
for high levels of productivity, initially, regardless the precipitation conditions of a specific area. This growth
has required the construction of additional hydraulic infrastructures (channels, retention tanks, reservoirs)
but also has introduced a new stress factor in the management in those areas with potential scarcity
conditions where irrigation has to compete with other users such as households.
Deliverable D4.1 – Decision supporting tools system requirements
16
URBAN-WATER PUBLIC
Grant Agreement: 318602
Industrial: it is estimated that 22% of worldwide water is used in industry. Major consumers are related to
hydroelectric dams, thermoelectric power plants (where water is used for cooling), ore and oil refineries,
which use water in chemical processes, and manufacturing plants, which use water as a solvent. In this
sector water withdrawal can be very high for certain industries, but consumption is generally much lower
than in the agriculture sector. A good example of efficient consumption is hydroelectric power that derives
energy from the force of water flowing downhill, driving a turbine connected to a generator. This
hydroelectricity is a low-cost, non-polluting, renewable energy source. Significantly, hydroelectric power
can also be used to supply peak electricity demand unlike most renewable energy sources that are
intermittent. Reverse pumped-storage hydroelectric plants also exist, which use grid electricity to pump
water uphill when demand is low, and use the stored water to produce electricity when demand is high.
Nevertheless hydroelectric plants can be a competing element with other users when water availability in
reservoirs is very low and specific management protocols are required.
Household consumption is estimated as 8% of worldwide water use, but its supply is the most pressing
condition above the other potential users in case of scarcity. Household water includes all the human
water consuming activities (drinking water, bathing, cooking, sanitation, and gardening). Basic household
water requirements have been estimated around 150 litres per person per day, excluding water for
gardens. Drinking water requires a specific treatment (usually accomplished in water treatment plants) to
ensure that its quality is acceptable to allow for human consumption. In most developed countries, the
water supplied to households, commerce and industry is all of drinking water standard even though only
a very small proportion is actually consumed or used in food preparation. Household water demand is
highly variable in time (knowing daily consumption patterns is a key factor for the design of the distribution
network) and space (local regions in coastal areas can have a peak seasonal demand during touristic
periods, that might incorporate an additional pressure in the allocation of water from the supply sources).
Recreational: although in general water consumption for recreational purposes represents a very small
percentage of global use, it is starting to increase its impact. A significant example is the growth of golf
courses, which are increasing their presence in regions with good weather all the year but where water
scarcity is also an issue. A recent alternative for the sustainability of these facilities is the use of either
primarily or exclusively treated effluent water, which has little impact on potable water availability.
Finally a key in the water use is related to ensure the natural water flow, in order to minimise the impact of artificial
water storage or withdrawal. This use is referred to as environment water use, that usually accounts for a small
fraction of water but that has a significant impact in terms of sustainability. In many cases water managers are in
charge of ensuring environment flows as one of their duties (derived from a specific policy from the water authority).
In the context of the previous supply-demand requirements nowadays a water supply network can be described as
a system of engineered hydrologic and hydraulic components that provide water supply. A water supply system
typically includes the following elements grouped in levels of the supply chain:
Upper part chain (raw water collection):
o A drainage basin (which is the source for water collection from precipitation).
o A raw water collection point where the water accumulates, such as a lake, a river, or
groundwater from an underground aquifer. Usually raw water from rivers is stored in reservoirs,
although direct extraction from a river is also usual in some areas where continuous flows allow
this type of operation.
o Raw water may be transferred using uncovered ground-level aqueducts, covered tunnels or
underground water pipes to water treatment plants. Additionally specific connections between
Deliverable D4.1 – Decision supporting tools system requirements
17
URBAN-WATER PUBLIC
Grant Agreement: 318602
reservoirs can help to transfer water between them in order to better manage availability in
different areas.
Middle part chain (raw water treatment):
o Water treatment plant (WTP). Treated water is transferred using water pipes (usually
underground). Usually WTPs have small storage facilities before and after the treatment process
to allow for a continuous and regulated inflow and outflow.
o Water storage facilities, water tanks, or water towers. Smaller water systems may store the
water in cisterns or pressure vessels. Tall buildings may also need to store water locally in
pressure vessels in order to push the water to reach the upper floors.
o Additional water pressurizing components such as pumping stations may need to be situated
at the outlet of underground or above ground reservoirs or cisterns (if gravity flow is not possible).
Bottom part chain (treated water distribution):
o A pipe network for distribution of water to the consumers (which may be private houses or
industrial, commercial or institution establishments) and other usage points (such as fire
hydrants).
o Water consuming devices and consumers
o Connections to the sewers (underground pipes, or aboveground ditches in some developing
countries) are generally found downstream of the water consumers, but the sewer system is
considered to be a separate system, rather than part of the water supply system.
The previous elements are combined in order to satisfy the demand in a given area, considering a set of specific
characteristics:
Characteristics related to water availability:
o Orography, which defines the type of available basins and the potential to build reservoirs.
o Ground water availability and restoring capacities, which informs about dimension and refill rates.
o Climatology, essential to understand and design the capabilities of the system in order to confront
seasonal or long-term water availability variations (e.g. drought periods).
Characteristics related to water demand:
o Existing urban development and required daily necessities.
o Industrial consumption in the area.
o Irrigation needs.
o Other consumption.
It is important to remark that the operational relation between the different parts of a water supply system is
intrinsically defined during the planning of the system that has a long-term approach in terms of managing water
resources in one region. Usually in this planning phase all the elements of the water supply system are defined
considering the following basic aspects:
Expected demand requirements for the planned period from all the potential users.
Water sources availability in the area, by available infrastructures (such as dams) or to be built.
Requirements in terms of WTP and distribution networks.
Simulations of scenarios to define a management strategy coherent with existing resources and demand,
both current and future.
The process of simulation might consider in detail all the complexity of the planned water supply system (control or
storage elements both superficial and subterranean, and elements for collection, transport, use and/or
Deliverable D4.1 – Decision supporting tools system requirements
18
URBAN-WATER PUBLIC
Grant Agreement: 318602
consumption). Simulations are usually performed at a monthly scale and can reproduce the water flow through the
system and identify potential mismatching between availability and demand that might need to redefine the system.
Historical rainfall and flow information from several years and even future trends are incorporated into the simulation
process to evaluate the feasibility of the different scenarios, including specific risk scenarios such as drought or
flooding.
The outcome of the planning process is in principle a water supply system that has a well-conditioned integration
between the different elements (tested through the simulation process) and that can provide a base for the definition
of real-time operational protocols for each of them.
2.1 Generic description of water supply elements and management activities
The objective of this section is to provide information about the purpose, operation routines, and management
strategies for each of the key elements of a water supply system. This information will facilitate the development of
requirements for the SDSS and the other supporting tools of WP4. The elements to be described in the section are
reservoirs, groundwater / water boreholes, water treatment plants, water distribution systems and water
consumption.
Essentially each water supply system element will be described using the following points:
Objective.
Data used for the operation.
Supporting tools.
Specific management strategies.
Implications to other elements of the system.
2.1.1 Reservoirs
Reservoirs are complex systems that have to accomplish a significant variety of objectives. Although the main
purpose from the point of view of the water supply system is to ensure a safe supply of drinking water, they might
have other objectives too. The preservation of the aquatic ecosystems, health and quality issues (preventing debris,
sedimentation, litter, chemicals, or other pollutants, from entering a reservoir) are crucial to reduce the amount of
treatment necessary for the water to meet drinking water standards. In fact, current understanding of the physical,
chemical, and microbiological processes controlling water quality reservoirs has improved considerably during the
last decades, and the new scientific advancement provides new strategies to improve water quality in lakes and
reservoirs as a first step in the water treatment process.
Reservoirs integrate a large variety of sensors:
Meteorological sensors: automatic stations that allow measuring several parameters as precipitation,
temperature, pressure, humidity, radiation, wind intensity and direction, etc.
Quality sensors: cyanobacteria levels, dissolved oxygen concentrations, dissolved organic carbon, water
temperature, electrical conductivity, turbidity, pH (potential of Hydrogen), chlorophyll-a concentration, etc.
Hydrological/Hydraulic sensors: flow/level sensors, pressure sensors, power generation, etc.
Reservoirs integrate several basic types of supporting tools to help the operation and management:
Monitoring systems:
Deliverable D4.1 – Decision supporting tools system requirements
19
URBAN-WATER PUBLIC
Grant Agreement: 318602
Monitoring systems usually integrate the previous sensors in thematic dashboards that help to determine
in real-time the status of variables of interest and their temporal evolution. Additionally it is a common
practice to set automatic alarms in specific levels, abrupt variations, or combinations of them. The use of
these simple rules facilitates the decision making process and the management strategies adoption.
Modelling supporting tools:
These are essential elements for the management of the various aspects involved in the operation of
reservoirs. The main objective of the models is to integrate current measures and a physical approach to
describe the current and future evolution of variables of interest. In the context of reservoir operation,
models are key elements that can provide the capability to perform anticipated management strategies.
Quality models
Quality models may span from reservoir ecosystem models; river water quality, ecosystem, and fish
bioenergetics models; and aeration system models for several aeration methods and combinations of
methods. The issues addressed by models include revising reservoir pool level rule curves, linking nutrient
levels to algal growths and dissolved oxygen levels, in-lake aeration systems, striped bass habitat, anoxic
products, turbine aeration systems, tailrace aeration systems, temperature control methods for
hydropower releases from reservoirs, optimizing hydropower unit operations as well as whole hydro plant
operations for aeration and electric generation, and development of water quality standards for dissolved
oxygen and chlorophyll-a.
Specific water management/availability models are usually hydro-meteorological models:
Weather forecast models: usually based in numerical weather prediction (NWP) models that,
using as input current meteorological information, provide an evolution of the atmospheric
condition in the next days (usually up to 7-14 days in advance). Information from these models
(as rainfall or temperature) can be used as input in other models in order to extend the prediction
of other variables.
Hydrological models: allow simulating flows in watershed usually considering superficial and sub-
superficial flow. There is a large variety of hydrological models, with different complexity that also
can model additional parameters. They are essential tools for reservoir operation in order to know
the evolution of flows in the next hours (using current sensors information) or days (in case of
information from NWP models is used as input).
Hydraulic models: usually used in combination with hydrological models, allowing modelling the
hydraulic flow into main water-course.
The combination of these three models will provide information about water availability for different
horizons: short-term information (next hours) from Hydrological/Hydraulic models using current sensor
information, and mid-term information (7-14 days) from Hydrological/Hydraulic models using current
sensors and NWP models data. Models information tend to be used more in a qualitative than quantitative
way when horizon is increased, since NWP model consistency for some parameters, as precipitation,
decreases as lead-time increases.
Current practices in the operation of reservoirs uses the previous elements (sensors and supporting tools, i.e.,
monitoring systems and models) in a more or less integrated way. The variety of solutions is significant since the
relative importance of existing local problems could require a more sophisticated solution for one specific problem
(e.g. some reservoirs can put the operation effort in quality issues and others in water availability).
From the point of view of the water supply, management activities at the level of the reservoir are focused on the
following aspects:
Deliverable D4.1 – Decision supporting tools system requirements
20
URBAN-WATER PUBLIC
Grant Agreement: 318602
Determine current water availability and quality, usually provided through the previously described
monitoring systems. These systems can operate specific warning thresholds for one variable or a
combination of them that in case of reaching predefined thresholds can activate present management
protocols.
Monitor that current distributions to other parts of the system agree with expected allocations
(again, monitoring systems usually provide information about current outflows from the different outputs
of the reservoir that are delivered to satisfy specific demands). These allocations are related to the required
daily water volumes from WTPs, irrigation needs, recreation, environmental flows, etc.
Define/operate current distribution of allocations for the users. Basic water allocations are usually
defined at the level of the general supply system management; since in many cases it requires an
integrated approach (e.g. a WTP should receive water from several reservoirs). Then later they are
implemented at the reservoir operation level. In any case daily reservoir operation can modify allocations
depending on current conditions. Usually these modifications are based on decisions taken by an expert
operator relying on past experience or simplified protocols. An alternative approach is to implement more
complex real-time optimization systems that allow for the optimization of water use depending on various
requirements and priorities (drinking water production, irrigation, hydropower exploitation, etc.). This
approach is usually applied when the water supply system has only one water source (e.g. a reservoir).
Define the current status of the reservoir. A common practice in reservoir management is to define the
current status, usually based on available volumes (although other variables could be considered, such
as water quality). A typical methodology is to define the current status using status curves defined from
the statistical analysis of historical volumes and water demand. Status curves can define different
scenarios (close monitoring is required, drought watch, drought warning, emergency situation, etc.) that
usually have associated protocols with specific predefined actions (related to water allocations, balance
operations in case of chained or connected reservoirs, use of alternative water sources, etc.). These
protocols have been developed through previous studies that analyze general management strategies
that consider the whole supply system.
Determine expected water availability and manage current and future water allocation. Common
approaches are focused on short-term water availability (which could be provided by the combined use of
hydro-meteorological models) and long-term availability. In the latter case usual methodologies employ
historical monthly information from water volumes evolution and expected demand to provide potential
scenarios in the evolution of water availability in the next months. That information can be associated to
specific scenarios and warning levels that activate preventive protocols that can affect current water
allocation.
Figure 1 summarizes all the main concepts related to reservoirs management previously explained.
Deliverable D4.1 – Decision supporting tools system requirements
21
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 1: Scheme of main concepts related to reservoirs management
2.1.2 Groundwater – water boreholes
Groundwater is the water located beneath the earth's surface in soil pore spaces and in the fractures of rock
formations. Exploitable water deposits are called aquifers and the depth at which soil pore spaces or fractures and
voids in rock become completely saturated with water is called the water table. Groundwater is naturally replenished
by surface water from precipitation, streams, and rivers when this recharge reaches the water table. Groundwater
aquifers are often exploited for agricultural, municipal, and industrial use by constructing and operating extraction
wells.
The characteristics of aquifers vary with the geology and structure of the substrate and topography in which they
are located. In general, the more productive aquifers are located in sedimentary geologic formations.
Unconsolidated to poorly cemented alluvial materials that have accumulated as valley-filling sediments in major
river valleys and geologically subsiding structural basins are included among the most productive sources of
groundwater.
Groundwater is generally cheaper, more convenient and less vulnerable to pollution than surface water. Therefore,
it is commonly used for public water supplies. For example, groundwater provides the largest source of usable
water storage in the United States and many municipal water supplies are derived solely from groundwater.
The volume of groundwater in an aquifer can be estimated by measuring water levels in local wells and by
examining geologic records from well drilling to determine the extent, depth and thickness of water-bearing
sediments and rocks. Pumping tests can be performed in test wells to determine flow characteristics of the aquifer.
Major problems affecting the availability of water from aquifers are related to pollution and over-use. Pollution often
comes from industrial and household chemicals and garbage landfills, industrial waste lagoons, etc. (thus, in many
cases pollution comes from polluted natural flows that inflow to the aquifer). Over-use lowers the water table beyond
Deliverable D4.1 – Decision supporting tools system requirements
22
URBAN-WATER PUBLIC
Grant Agreement: 318602
the reach of existing wells. As a consequence, wells must be drilled deeper to reach the groundwater. Over-use is
common in areas where withdraws are not integrated in a management plan, so long-term replenish of the aquifer
or a balance control is not considered. Specifically over-use in coastal locations may induce seawater to reverse
the flow toward the land, and effect known as saltwater intrusion.
Nowadays groundwater exploitation strategies require a previous management plan that analyse in detail how the
operation of the aquifers should be performed in order to ensure sustainability in terms of water quality and quantity.
Groundwater management plans are basically focused on:
Developing a complete understanding of the basin’s hydro-geologic characteristics. It is important
to know the recent evolution of the related aquifers, and the interrelation with existing inflows (infiltration
from direct precipitation, surface water infiltration, etc.) and outflows (groundwater pumping, flow to surface
water, underflow out of basin, etc.).
Defining an exploitation protocol/strategy that accounts for groundwater as a supply source in
conjunction with other available sources in order to secure the yield and reliability of the groundwater
supply in current and future conditions. That strategy would likely include rules for the exploitation of
existing boreholes, incorporation of specific sensors to provide information about the evolution of the
aquifer and its quality, performing specific actions to eliminate or limit potential sources of contamination.
Groundwater exploitation
Groundwater exploitation follows a similar scheme to the one described for reservoirs and a combination of
information provided by sensors and supporting tools (monitoring systems and models) is used to perform most of
the management activities.
Typically information measured by sensors is related to groundwater level, groundwater withdrawals, water quality
(pH, conductivity, temperature, dissolved oxygen, dissolved ammonium, etc.).
On the other hand groundwater models provide very useful information about the natural groundwater flow and
future evolution and also in some cases include quality aspects of the groundwater. Since groundwater models can
incorporate information as hydrological inputs (rainfall, evapotranspiration and surface runoff, which determine the
recharge) and operational uses (related to withdrawals operated in boreholes), they can be fundamental tools to
apply predictive management actions. In this sense these models can provide very useful information in areas
where reservoirs and groundwater are exploited together, since both sources are fundamentally linked.
Groundwater models can then provide a reliable information about the constraints in the exploitation of groundwater
in scarcity periods (as substitutions of reservoirs), since groundwater models can show to what extent scarcity
periods (reduction of water flows to the aquifer) could reduce the replenish capacity of the aquifer.
Using this information and from the point of view of the water supply, management activities at the level of the
groundwater supply are focused on the following aspects:
Determine current aquifer water level/volume and quality (provided through monitoring systems that
can provide warnings and have related protocols).
Monitor that current withdrawals in boreholes agree with established allocations. In some areas
some boreholes can be attached to the main supply system and others related to private use, as for
irrigation purposes. A well-defined management plan should specify the allowed allocation for each of
them under the objective of sustainability. In the context of that management plan, an expert operator can
decide daily withdrawals based on past experience or simplified protocols. This is a common process
Deliverable D4.1 – Decision supporting tools system requirements
23
URBAN-WATER PUBLIC
Grant Agreement: 318602
when groundwater and reservoirs are operated together to satisfy a given demand, and then daily
adjustments are required as a function of the current conditions of both supply sources.
Define the current status of the aquifer usually based on current levels and water quality information.
Studies performed during the elaboration of the management plan can provide scenarios related to the
current information (close monitoring is required, over-exploitation warning, etc.) and activate predefined
protocols.
Determine the expected status of the aquifer in order to manage current and future withdrawals. In this
context groundwater models can provide information about the expected evolution of the aquifer
conditions in the next weeks and this information might be related to predefined scenarios, warning levels,
and preventive protocols.
Figure 2 summarizes the main concepts related to groundwater management previously explained.
Figure 2: Scheme of main concepts related to groundwater management
2.1.3 Water treatment plants
Water treatment plants (WTP) perform the industrial process of producing water for drinking purposes. The water
treatment process removes existing water contaminants or reduces their concentration so that the water becomes
acceptable for its desired end-use. The processes involved in treating water for drinking purposes may be solids
separation using physical processes such as settling and filtration, and chemical processes such as disinfection
and coagulation. Biological processes are employed in the treatment of wastewater and these processes may
include, for example, aerated lagoons, activated sludge or slow sand filters.
Usually physical and biological processes are monitored, controlled and operated by a Supervisory Control and
Data Acquisition (SCADA) system that facilitates the semi-automation of the treatment process. SCADA systems
monitor and control an important number of variables in each of the key treatment processes and can adjust the
intensity of each treatment as a function of the inflow characteristics.
From the point of view of the water supply system, it is fundamental to monitor the following aspects in the WTP:
Quality and quantity of inflows arriving at the WTP. The WTP can receive water from different sources
(from connected or disaggregated reservoirs, from direct in-takes of the river, from boreholes that need
Deliverable D4.1 – Decision supporting tools system requirements
24
URBAN-WATER PUBLIC
Grant Agreement: 318602
an additional treatment, etc.). Information on water at the output of the source is required as well at the
input point to the WTP. Information about flows, pressure, quality parameters (turbidity, conductivity, etc.)
measured at the source point but also at the WTP is usually incorporated into the SCADA system that can
issue warnings in case that certain conditions are not met.
Process of treatment that should be accomplished with the required quality in any of the steps of the
treatment process (this monitoring and control is usually performed by the SCADA).
Water treatment outflow quality. The water treatment outflow quality has to agree with expected
standards and the quantity has to satisfy the demand.
Supporting tools for the operation of the WTP are the ones related to the operation of inflows (e.g. information about
availability and quality expected in reservoirs or groundwater) and specifically demand prediction models. Demand
prediction modelling can be based on historical consumption information, which can provide average demand, and
daily average consumption patterns. Additionally historical information can be used to describe extreme cases
(weekends, national holidays) or seasonal variations. More sophisticated models can model future water demand
(at the level of hourly steps) as a function of variables (such as meteorological) that can have an impact on
consumption.
WTPs usually operate in a buffer approach: a pre-treatment tank is filled with inflows from water sources (ensuring
a continuous available volume of raw water). On the other hand, the treated water generation rate keeps a
continuous available volume at an output tank that ensures water demand. Additionally WTPs usually operate
below their maximum capacity so that higher treatment regimes are possible in case that the demand increases.
Management activities at the WTP are focused on the following aspects:
Define inflow quantities from the different sources and expected quality. Basic allocation of inflows can be
defined in a normal operation protocol of the WTP but many factors can affect the daily decision. Usually
an expert operator uses simplified protocols that can employ information from current water levels at the
different sources, but also constraint conditions related to the status of each of them (e.g. drought warning
in reservoirs, or over-exploitation in boreholes).
Monitor and anticipate potential modification of the treatment process depending on conditions, such as:
o The quality of inflows (in the next hours as a function of current quality in the inflows or days, as
a result of information provided by models in the water sources)
o The necessity to perform maintenance tasks on parts of the WTP
o Current state of the parts of the WTP
o The necessity to increase the treatment flow due to increasing demand (as a result of the
predicted demand or seasonal effects, such as increasing of population in the tourism season)
Figure 3 summarizes main concepts related to WTPs management.
Deliverable D4.1 – Decision supporting tools system requirements
25
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 3: Scheme of main concepts related to WTPs management
2.1.4 Distribution systems
Water distribution refers to the infrastructure that allows transporting water from WTPs (that are usually located at
significant distance from final consumption points), store it, and distribute it to the final consumers ensuring key
variables for final consumption, such as convenient pressure, chlorine levels and temperature. Basic elements of
the water distribution are tanks, pumping stations, water tower, and valves. Usually management processes are
semi-automatic and integrated in a SCADA system that controls and optimizes basic methods of transfer of the
treated water to distribution tanks, operating pumping stations, and valves to ensure levels in tanks or elevated
towers. Furthermore the SCADA system centralizes all the information about the status of the network register by
several sensors (levels at tanks, pressure at different zones of the network, flow in tanks, pumps operation rates).
Monitoring and maintenance activities in the distribution network are essential to keep standard conditions.
Distribution networks are designed and dimensioned to allow reasonable tolerance conditions in all parts of the
network:
Acceptable pressure levels are available at the point of supply to provide an adequate flow to the
consumer.
Tanks (service reservoirs) allow fluctuations in demand to be accommodated without a loss of hydraulic
integrity. They can also guarantee a supply, at least for part of the day, while the inflow into the network
is stopped (e.g. for maintenance of the treatment works or upstream pipe, or a contamination incident).
This strategy can help to minimize network transit times, maintaining microbial quality.
Pump stations are designed to operate at intermediate rates so that maintenance routines (stopping pump
elements) do not interfere in keeping the operational rates.
Supporting tools for the operation of the network can provide very useful information:
Hydraulic models of the network can allow to simulate the operation in normal and exceptional conditions
and optimize its performance in real-time. Nowadays the complexity of these models prevents their real-
time use, so using predefined scenarios or simplified models (where only part of the network is simulated)
are a more feasible strategy. In many cases the main objective of these simulations is to optimize the
network performance towards ensuring water pressure, reduction of pumping consumption, or identifying
network areas of low performance.
Deliverable D4.1 – Decision supporting tools system requirements
26
URBAN-WATER PUBLIC
Grant Agreement: 318602
Leakage models can also be very useful to provide information about potential leakages identifying zones
where this problem could be present. Continuous operation of these models can help to identify degrading
condition of the network and to activate more effective preventive maintenance tasks.
As for WTPs, demand prediction models can provide information about the required volumes and demand
evolution in the next days. This information can be used to anticipate potential temporal service quality
reduction due to network elements with limited capabilities (e.g. if some pumping stations are not able to
provide the expected performance in extreme peak demand conditions) or can be used to plan when
maintenance activities can be performed in order to have the minimum impact in the functioning of the
network.
As for management of different distribution network segments, demand prediction for the corresponding
segment can provide useful information for anticipation of conditions in that segment and the needed
control/regulation activities in it (including adaptive pricing towards end-users on this segment).
Management activities in the distribution networks are focused on the following aspects:
- Monitor inflows to the system, in terms of quantity (anticipate potential shortages due to maintenance
activities in the WTP) and quality.
- Monitor network functioning to anticipate specific problems (pumping station failures, leakages) and use
supporting tools to anticipate these problems (as leakage models).
- Ensure that maintenance activities do not interfere with the normal performance of the system and
collaborate with consumer services to keep consumers fully informed of activities on the network and any
emergency advice in the case of a water quality problem.
- Anticipate demand conditions (e.g. through demand prediction models) to verify that the expected system
performance can be accomplished and to impose advanced demand management procedures, like
adaptive pricing.
In general terms distribution network operation requires an overall strategy adapted to local circumstances and
applicable to all water quality issues, not just microbial quality. Figure 4 summarizes the main concepts related to
distribution systems management.
Figure 4: Scheme of main concepts related to distribution systems management
Deliverable D4.1 – Decision supporting tools system requirements
27
URBAN-WATER PUBLIC
Grant Agreement: 318602
2.1.5 Consumption
Consumption is the last stage of the water supply chain, and traditionally is linked to a metering system that allows
measuring flows or volumes used by the users (households, industrial, irrigation, etc.). Traditional infrastructures
integrate non-telemetered devices, thus information is retrieved by meter reading methods in which readings are
entered into a handheld device by meter reading staff. The information registered is usually total accumulated
consumption (water volume). Additional information about flow evolution is usually registered by meters located in
district meter areas (DMA) that only provide integrated information of their related points of supply.
This approach has serious limitations, such as personnel and transport costs, infrequency of readings, and possible
reading errors. In this sense water utilities are increasingly looking for alternatives as investments to reach reduced
reading costs, enhanced management capabilities and improvement of water resources efficiency. In this context
smart metering, allowing for a continuous measuring of consumption and transfer of such information could
represent a significant improvement in many aspects:
Consumption can be integrated in automatic billing systems that can provide more optimized, sustainable
and efficient tariff procedures (allowing for daily cost variations – adaptive water pricing - that can modify
the users’ water consumption patterns and for example reduce peak demands, or integrating additional
parameters to water tariffs, such as treatment costs, water availability, etc.)
Better consumption patterns can be derived, allowing improving demand prediction models.
Improve customer awareness of water consumption and increase its involvement in policies addressed to
improve cost-efficiency and sustainability of water resources, e.g. through detailed indoor consumption
modelling, i.e. revealing customers when and how the water was used in an interactive way or through
serious gaming that are both capable to change behaviour on both financial and sociological bases
Based on real-time information from smart meters and based on assessed detailed consumption habits
real-time management of wastewater treatment plants can be established (e.g. the amount of water used
and percentage of the used water that enters the sewage system).
Despite these promising improvements current infrastructures have limited management capabilities and main
tasks are focused on keeping readings updated as much as possible, as well as maintaining the meter infrastructure
and matching readings information with flows/volumes in DMA to keep track of possible deviations that could be
related with leakages.
Figure 5: Scheme of main concepts related to consumption management summarizes main concepts related to
consumption management.
Deliverable D4.1 – Decision supporting tools system requirements
28
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 5: Scheme of main concepts related to consumption management
Deliverable D4.1 – Decision supporting tools system requirements
29
URBAN-WATER PUBLIC
Grant Agreement: 318602
3 Approach of the UrbanWater SDSS
The management processes described in Section 2 involve decisions that in many cases are limited to the operation
of a given element. The objective of this section is to show that the management and decision process (including
the key elements of the UrbanWater system in order to provide a more integrated approach) can be used later not
only in the formulation of the SDSS requirements but also for the other SDSS supporting tools.
The SDSS approach in the context of UW is as follows:
The SDSS will allow integrating the supporting tools related to water demand prediction, water availability
prediction, detailed indoor consumption and leakage detection into the decision process.
The SDSS will provide a framework to incorporate additional decisions based on the use of information
available or generated in the context of the UW platform.
The basic approach to define decisions in the SDSS will be the integration of concepts presented previously in the
management practices presented in section 2, where in essence decisions are derived from a combination of:
Information obtained from a set of sensors (sensors that usually are attached to the elements of the water
supply system, but can also be external).
New information generated from the supporting tools. Supporting tools provide additional capabilities
combining existing variables or modelling new ones and also provide a forecast of these variables.
Supporting tools are in many cases related to expert systems that can operate complex models for specific
purposes.
Existing additional historical information or reference information that help to come to a decision or relate
specific actions to this information (that could be the case of predefined warning levels and associated
protocols).
From this point of view Figure 6 shows the integrated scheme of element sensors, supporting tools, information,
and decisions that integrate a conceptual water supply system where UW specific modules have been included,
namely:
The water availability prediction;
The water demand prediction;
The leakage detection system;
The billing system;
The smart meters (including detailed indoor consumption model);
The serious games.
In Figure 6 main connections between boxes show the flow of processes and information used by a given box. In
particular this provides a good illustration about:
How decisions are built using a combination of other parts of the scheme.
How elements from different levels of the water chain are interrelated in order to provide a more integrated
knowledge of the status and information of the system.
How the UW modules are used in the context to the water supply system and how they participate in the
definition of decisions.
In the figure the following codes have been used:
Deliverable D4.1 – Decision supporting tools system requirements
30
URBAN-WATER PUBLIC
Grant Agreement: 318602
Dotted arrows indicate relations between modules at different parts of the water supply chain.
Blue boxes represent water related amounts derived from the SDSS at the different parts of the water
supply chain.
Yellow boxes represent questions than can be answered by the SDSS.
White boxes with bold text indicate modules present in the UW platform.
In the next section an example is presented to describe how specific decisions involving UW modules can be
defined in order to better illustrate that process. In any case the detailed process to build decisions by means of
the SDSS will be further elaborated in the deliverable D4.2 where the design of the SDSS is presented and will be
explicitly implemented and deployed for the sites during the implementation and validation phase of the project.
Deliverable D4.1 – Decision supporting tools system requirements
31
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 6: Schema of main concepts related to integrated water system management
Deliverable D4.1 – Decision supporting tools system requirements
32
URBAN-WATER PUBLIC
Grant Agreement: 318602
3.1 SDSS configuration and usage example
In this section an example based on a supply system with a simple topology is presented. The basic decisions to
be implemented are:
What is the required supply for tomorrow from the different water sources?
What is the expected supply in the next 6 days from the different water sources?
Does the WTP process need to be modified because of quality of water sources?
Is there any potential leakage?
What are the costs related to water sourcing, treatment, distribution and recycling of used water?
The supply system comprises the following elements:
1. Water sources:
Two reservoirs with very different maximum capacities (R1 = R2*3).
One groundwater system.
One direct river extraction point.
2. Water processing:
One WTP
3. Users:
One urban area with a distribution network integrated by 10 DMAs and a consumption system with
smart metering.
One irrigation area.
In order to define the exploitation process, standard current practices employed in many supply systems have been
used. In any case, when the UW SDSS will need to be deployed on the UW sites, specific local conditions need to
be considered.
Figure 7: Topology of the water supply system used in the example
The basic steps to define a corresponding SDSS configuration are as follows:
Deliverable D4.1 – Decision supporting tools system requirements
33
URBAN-WATER PUBLIC
Grant Agreement: 318602
Current context:
1. Parameters describing the elements:
a. Water sources: basic information such as max volume, max output flow, etc.
b. WTP: max treatment capacity, etc.
2. Current water sources status. It could be derived from the current volume (or % of total volume) plus
additional conditions (as expected long-term availability) that could be used to extend a given status.
Usually the status (or scenario) can be one of abundance, normal, monitoring, scarcity or drought.
3. Current inflow status of the water sources.
4. Operational rules of water sources. Standard practices in the operation of water sources define operational
rules that provide:
Max daily water volumes that can be delivered depending on the scenario and other variables (the
current available volume, the long-term forecast volume). Usually these rules are defined using
historical information and in some cases simulation scenarios with similar tools to the ones used
during the planning phase of the system.
The environmental minimum discharge as a function of the scenario.
5. Current WTP volume balance: not consumed water volume derived from a mismatch between expected
demand and actual demand. In theory the required demand could be reduced by the amount of this
balance.
6. DMA current inflows.
7. Cost function for the extraction or processing for each element.
Supporting tools information:
1. Forecast volumes entering the water sources (in the short term and long term).
2. Forecast status in the next days from the forecast volumes.
3. Forecast demand for the next days (e.g. next week hourly expected demand). It would be also possible to
provide a specific irrigation demand based on real requirements (e.g. based on used and future required
water volumes depending on weather conditions: expected evapotranspiration, expected rainfall, etc.).
4. Leakage potential from DMAs (mass balance and night flow information).
Integrated rules and priorities:
Usually these rules describe how the various sources are exploited together. It might include:
1. Weighted rules related to the volumes to be extracted by the reservoirs (a common strategy is to keep as
much as possible the balance between reservoirs so that the hydrological status of the various sources
are identical, e.g. in our example both R1 and R2 should keep the same % in capacity). This strategy will
tend to consume water from those sources that have a better status.
2. A degree of priority. It indicates which sources are primarily to be used to satisfy the demand. A clear
example in our case is the use of boreholes. They require the use of pumping stations (which imply an
additional cost) and usually are kept as much as possible for drought periods. This way, if the demand
can be satisfied by sources with a higher priority (such as reservoirs), boreholes are discarded.
3. Additional conditions can be included, such as the quality of the sources (since low water quality would
require higher treatment processes in the WTP) or the cost of exploitation.
Figure 8 displays the water supply system topology, SDSS inputs and SDSS workflow to calculate management
decisions.
Deliverable D4.1 – Decision supporting tools system requirements
34
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 8: How the SDSS configuration is built
Applying the decision process:
On a daily basis the SDSS operates the following processes:
1. SDSS retrieves the current context information.
2. SDSS retrieves the forecast context information.
3. SDSS determines the required supply from water sources for the next day.
The SDSS calculates the water contribution from the different sources in order to satisfy the demand. In
general the daily expected demand is solved using the previous information, rules and priorities. Usually
it can be accomplished through a simple iterative process, e.g:
First, demand is attempted to be satisfied by reservoirs (using the weighted rules), and water
from the direct river extraction point. Contributing volumes are calculated using the forecast
status for the next day.
If not sufficient, the remaining required contribution is obtained from the borehole.
If no additional iterations could relax the max volume delivered by water sources, and a demand
restriction would have to be activated (e.g. reduction of volumes for irrigation purposes).
A more complex and rich process can be considered including additional cost of production from all the
sources, quality information, etc.
4. SDSS determines the required supply from water source next 6 days
The previous process is repeated using the forecast context for the next 6 days (for water volumes and
demand).
5. SDSS determines whether WTP process needs to be modified because of quality of water sources
The SDSS retrieves water quality of each water source, and specific formulas (considering the contribution
of each source) are used to determine if the WTP needs to alter the treatment process.
6. SDSS determines whether there is a potential leakage
The SDSS uses LDS information for each DMA to activate warnings of potential leakages.
7. Water sourcing and technical costs for distribution for the next 7 days?
SDSS calculates the prices for the next 7 days as follows:
Deliverable D4.1 – Decision supporting tools system requirements
35
URBAN-WATER PUBLIC
Grant Agreement: 318602
Cost of extraction is calculated from the cost extraction function of each source weighted by the
extracted volume of each one (cost extraction function of each source could also consider
“punitive” conditions based on the current scenario).
Cost of production is calculated from the cost function of the WTP (that also could consider the
influence of the current quality of the flows from the different sources) or its optimizer function if
cost optimisation is already performed on the WTP level.
Distribution costs in general and those based on the different hours are calculated
Costs provided to the billing system (adaptive pricing module)
As a result, the SDSS set up or configuration could be referred to as the process that implies the three-layered
process of defining the context of the elements integrated in the decision, retrieving information from the supporting
tools (e.g. information about the forecast conditions) and defining the integrated rules and priorities. Finally the
“questions” to be solved by the SDSS are defined combining the previous information/rules. Although in this
example a simplified water supply topology is used, it provides a concrete illustration about how the SDSS
configuration process might work.
Deliverable D4.1 – Decision supporting tools system requirements
36
URBAN-WATER PUBLIC
Grant Agreement: 318602
4 Roles and actors
In the preceding sections a description of the water supply system and the usual water supply system management
strategies were explained from a generic point of view. Moreover, an approach to implement those management
strategies into the UrbanWater SDSS was presented. Once the context and scope of the Spatial Decision Support
System have been set, the next step is to define the requirements.
The approach used to define the requirements of the Spatial Decision Support System is based on best practices
regarding software requirements specification and consists of the following steps:
(i) identification of the roles and actors;
(ii) construction of potential scenarios;
(iii) definition of the use cases; and
(iv) definition of the requirements.
(v)
This section will cover the first step of the process, which is the identification of the roles and actors. Roles and
actors are common for the Spatial Decision Support System and all decision supporting tools (Water Availability
Prediction System, Water Demand Prediction System, Detailed Indoor Consumption Model and Leakage Detection
System), while scenarios, use cases, and requirements are specific for each module and will be depicted in
corresponding sections.
A practical definition of the actors and roles is that an actor specifies a role played by a user or any other system
that interacts with the subject (water-related management in this case). In other words, roles are the conceptual
categories in which the people/entities are classified depending on their specific tasks. Actors, on the other hand,
are concrete instances of persons/entities playing a specific role. For example, we could define the role “Water
manager”, who is in charge of the global management of the water supply chain and defines the operational tasks
and strategies. Next, we can introduce the actor “Goodwater” as a fictitious water utility who plays the “Water
manager” role previously defined. It is “Goodwater” and not “Water manager” who will take part in the water
management process, that is, only actors interact with the system but the role they play delimits those interactions.
Furthermore, more than one actor can play one role and one actor can play more than one role. Following the
previous examples, suppose that “Goodwater” does also provide water to end users. Then it would also play the
“Water distributor” role. An example of a role played by many actors would be a meteorological services company
and a metering services company. Both companies would be playing the “Service provider” role.
As it was stated before, actors interact with the system, and the interactions in a specific context are explained
through scenarios and use cases. Scenarios are stories explaining the potential ways in which a user interacts with
the system, while use cases represent major categories of functionality as perceived by the users, derived from the
stories of the scenarios. Use cases model a system from the users’ point of view by defining possible event flows
through the system, and describing the interaction between objects.
Finally, the functional requirements of the system will be defined on the basis of the information generated while
defining the use cases. The requirements definition process described will be applied to the Spatial Decision
Support System module (see Section 5) , the Water Demand Prediction System module (see Section 6.1), the
Detailed Indoor Consumption module (see Section 0), the Water Availability Prediction System module (see Section
0), and the Leakage Detection System module (see Section 0).
Deliverable D4.1 – Decision supporting tools system requirements
37
URBAN-WATER PUBLIC
Grant Agreement: 318602
The following list contains the roles that an actor can play as well as the description of actors. Actors should be
identified in order to specify the use cases and requirements. The main actors that will interact with the SDSS are
the water managers, who will modify the SDSS configuration; and water operators, who will operate water supply
system taking into account the information provided by the SDSS. It is important to remark that end users of the
water supply system, generally water consumers, are not considered as actors of the SDSS. End users cannot
modify the behaviour of the system; they can only access parts of the information provided by the platform (to be
developed in WP5 and WP6). Which information of the SDSS is available through UrbanWater platform dashboards
for end users will be specified by each water utility in the platform configuration.
4.1 Roles
Table 1 contains the list of the identified roles related to the water management domain.
Role Description
Legal authority A legal authority regulates all the processes from acquiring water to delivering it to
costumers.
Water manager A water manager is in charge of the water management from upstream to
downstream, defining how the whole system is operated and delimiting tasks in case
of emergency situations like drought periods, all in accordance with the legal
framework put in place.
Water operator An operator analyzes all the information, decides which actions to be taken and
notifies these actions to be performed to raw water suppliers, water suppliers and
water distributors. These operators are mostly related with water managers.
Raw water supplier An entity in charge of providing raw water to the system. These raw water sources
are typically reservoirs, boreholes or rivers.
Water supplier An entity in charge of converting raw water provided by raw water suppliers into
drinking water. They are mainly in charge of treatment plants, wastewater plants and
desalination plants management.
Water distributor An entity in charge of providing drinking water to costumers. Their main tasks are:
distribution network maintenance, monitoring and improvement;
possible leakages detection;
billing costumers’ water consumption
Service provider A service provider is providing services to any of the actors involved in the water
supply system. Mostly these services are for providing data.
Subscribed service A subscribed service in the context of this document is a service which receives
information generated by the SDSS.
Water consumer Water consumers are drinking water consumers, placed at the end of the water
supply chain. These consumers could be divided in household, industrial,
agricultural and recreational usage.
Table 1: UrbanWater decision supporting tools roles
4.2 Actors
Table 2 contains the list of the actors playing the roles defined in the previous section. Notice that in a real
environment, the roles adopted by the actor “Goodwater” would probably be distributed among several
organizations (e.g. one organization would be in charge of the water upstream management, another one would
Deliverable D4.1 – Decision supporting tools system requirements
38
URBAN-WATER PUBLIC
Grant Agreement: 318602
be in charge of the treatment and distribution of water to consumers, etc.). All roles regarding water management
and distribution have been grouped in a single actor to facilitate the understanding of the scenarios presented in
the next sub-sections.
It is also important to remark that the “Water legal authority” role have not actors that play them. Although this role
is essential in the water supply distribution chain domain, it does not hold any relevant interaction with any other
actor in the scope of the SDSS or the supporting tools. For example, if the water legal authority issues a law to
increase the minimum flow of a river due to environmental reasons, one might think it is the water legal authority
that performs the action, but in fact it will be the operator that will modify the behavior of the system to adapt it to
the law. Although it is true that the water legal authority will inform the operator of the new law, this interaction is
not taken into account since it is not relevant from the point of view of the spatial decision support system and the
decision supporting tools.
Actor Icon Roles
Goodwater
Water Manager
Water operator
Raw water supplier
Water supplier
Water distributor
Peter Liquid
Water consumer
UrbanWater platform
Subscribed service
Cloud database service
Service provider
Spatial decision support system
service
Service provider
Water availability prediction
service
Service provider
Water demand prediction service
Service provider
Detailed Indoor Consumption
Model service
Service provider
Leakage detection service
Service provider
Deliverable D4.1 – Decision supporting tools system requirements
39
URBAN-WATER PUBLIC
Grant Agreement: 318602
Adaptive pricing service
Service provider
Subscribed service
(Serious) gaming service
Subscribed service
Table 2: UrbanWater decision supporting tools actors
Deliverable D4.1 – Decision supporting tools system requirements
40
URBAN-WATER PUBLIC
Grant Agreement: 318602
5 Spatial decision support system
The Spatial Decision Support System module plays an important role in the UrbanWater platform centralising all
decision-making activities. Any module processing information that helps the water utility to make decisions could
be connected to the SDSS module and contribute with new information, combine it with the existing data from the
database or other modules, and generate new knowledge.
The key idea behind the SDSS design process is to obtain a highly flexible module that is able to connect manifold
data sources and data processing modules in order to achieve some of the main scientific and technologic
challenges defined for the UrbanWater project:
Effectively estimate water demand in urban water areas in order to efficiently manage water supply chains.
Reduce waste of water and economic losses associated to leakages in the urban water distribution
network.
Smoothen daily water demand peaks in order to allow distributors to save costs related to the urban water
distribution networks’ management.
Provide an off-line and on-line operation framework that allows to define/test scenarios of availability and
demand, for testing specific strategies for the operation of the water system.
As presented in section 3, the process of building a set of decisions for a given water supply system (with a related
topology) has been referred to as the configuration of a SDSS, which involves
a) the definition of the current context of the water supply elements,
b) their derived supporting tools information,
c) the integrated operational rules and properties for these elements and
d) the construction of decisions based on the combination of the previous concepts.
This section will cover steps (ii), (iii) and (iv) of the requirements definition process described in the introductory
part of Section 4, applied to the Spatial Decision Support System designed for UrbanWater. First, two potential
scenarios illustrating common situations that could occur during water resources management are explained in
Section 5.1. Second, a comprehensive list of use cases derived from the scenarios is described in Section 5.2.
Finally, the set of functional requirements deduced on the basis of the use cases as well as a list of non-functional
requirements is presented in Section 0.
5.1 Scenarios
This section describes two possible scenarios that represent common applications of the UrbanWater platform. The
first scenario (see Section 5.1.1) refers to the habitual usage of the platform during day-to-day tasks of a water
operator, while the second scenario (see Section 5.1.2) describes how the water operator would interact with the
platform in order to introduce a new element on the site.
5.1.1 Normal operation
Normal operation refers to the state where the UrbanWater platform is operated on a site and the water manager
and operators do their daily tasks as usual. In this case, they simply analyse the outcomes of the SDSS and the
proposed decisions, and take corrective actions if needed. The flow of events is as follows (see Figure 9):
Deliverable D4.1 – Decision supporting tools system requirements
41
URBAN-WATER PUBLIC
Grant Agreement: 318602
1. The spatial decision support system service retrieves the most recent information available from the cloud
database service. This information will likely include data provided by the water availability prediction
service, the water demand prediction service, and the leakage detection service.
2. The spatial decision support system service computes the new status of the system using the information
retrieved, applying the current configuration.
3. The spatial decision support system service notifies Goodwater’s operator that a new status is available.
4. Goodwater’s operator accesses the UrbanWater platform and analyses the information retrieved from
spatial decision support system in order to decide which management operations should be carried out
and validates or not the computed status.
5. If Goodwater’s operator validates the new status, the spatial decision support system marks this
computation as validated and stores it locally.
6. Finally the spatial decision support system notifies to all subscribed services (which will likely include the
serious gaming services and the adaptive pricing service) that a new validated status is available. At this
point each service could ask the spatial decision support system for the decision supporting related
information and use it for its own convenience, but this process is out of the scope of this scenario.
Figure 9: Normal operation scenario diagram
In reality, the data storage and retrieval and notification processes used in this scenario include additional steps:
As it is explained in deliverable D6.1 “UrbanWater platform requirements definition” in Section 5.1 (“Access to cloud
Data”), the SDSS module would not access directly the cloud database service. Instead, the SDSS module would
ask the UW platform for the data and then the platform would provide a communication channel between the SDSS
module and cloud storage service over the platform bus. Similarly, the SDSS module would not directly send
notifications to other modules. Instead, notifications are routed through message queues managed by the UW
platform to modules that have been previously subscribed to certain kinds of decisions. However, it was preferred
to omit these steps and keep the diagram simple to facilitate the understanding, since the differences with the real
operation is more of an implementation issue.
Deliverable D4.1 – Decision supporting tools system requirements
42
URBAN-WATER PUBLIC
Grant Agreement: 318602
5.1.2 A new reservoir has been built in the site
This scenario illustrates the situation when a new reservoir that was being constructed in the last year has been
finished. The reservoir is located in a basin that has two more reservoirs and the objective is that all three could be
operated in an integrated way. Moreover, new sensors have been implemented in the last reservoir of the chain to
measure the quality (e.g. turbidity) of the water that will be withdrawn. The flow of the events is as follows (see
Figure 10):
1. Goodwater’s operator indicates to the spatial decision support system service that there is a new reservoir
in the water supply chain and introduces its characteristics (e.g. location, name, minimum and maximum
capacity, current level, etc.).
2. Goodwater’s operator indicates to the cloud database service that a new data source is available (the new
sensor), and introduces its characteristics (e.g. data type, units, frequency of acquisition, etc.).
3. Goodwater’s operator changes the configuration of the SDSS through the spatial decision support system
service, so that the new reservoir is taken into account and the new sensor’s data is used to calculate the
turbidity of the water. From now on this new configuration will be used to compute the status of the system.
4. Goodwater’s operator asks the UrbanWater platform to display the current status of the system to check
that all modifications are correct.
5. The UrbanWater platform retrieves the current status from the spatial decision support system service and
displays it.
Figure 10: New reservoir scenario diagram
In fact, all interactions between the operator and the spatial decision support system service as well as the cloud
database service would have occurred through the UrbanWater platform (as it happens in steps 4 and 5), but they
were represented as a direct interaction for a better understanding of the actions sequence.
This scenario would be also valid for example if an authority issued a law to restrict water usage due to a severe
drought situation or if a new service was incorporated to the system. The background of all those examples
(including the scenario proposed) is the same, that is, to modify the configuration of the SDSS so that it behaves in
a different way adapted to the new situation.
5.2 Use cases
This section depicts the use cases derived from the scenarios explained in the previous sections. The set of use
cases represents some possible interactions an actor can have with the Spatial Decision Support System module.
Deliverable D4.1 – Decision supporting tools system requirements
43
URBAN-WATER PUBLIC
Grant Agreement: 318602
Use cases will be described using a table. Table 3 contains the use case template table including a description of
each field.
Identifier A unique character string (e.g. code, name)
Goal A brief description of the use case’s purpose, that is its goal
Preconditions A textual description that defines any constraints on the system at the time the use case
may start
Flow of events A textual description of what the system does with regard to the use case
Post conditions A textual description that defines any constraints on the system at the time the use case
will terminate
Trigger A textual description of the circumstances under which the use case may be initiated
Priority One of Mandatory, Expected or Optional. The priority indicates how critical it is to
implement the use case from the customer’s and the system’s point of view
Actors A comprehensive list of the actors involved in the use case
Table 3: Use case template
Below are presented the use cases for the Spatial Decision Support System, consisting on modifying the current
configuration, modifying the representation of the water supply system, performing computations to obtain new
SDSS status, display different information about the SDSS, and to retrieve computed SDSS status to other
modules.
5.2.1 Modify SDSS configuration
Identifier UC-SDSS-ModifyConfiguration
Goal Modify the configuration of the SDSS. The configuration will drive the behaviour of the
SDSS regarding the management of the different elements in the site
Preconditions The topology of the water supply system is defined
The SDSS configuration is being displayed at this moment
Flow of events 1. The water manager modifies the configuration of the SDSS through the spatial
decision support system service according to his/her needs
2. The new configuration is saved
Post conditions The modifications over the SDSS configuration have been stored into the SDSS
itself
Trigger Every time the water manager needs to change the behaviour of the SDSS
Priority Expected
Actors Goodwater (water utility managing the water supply distribution chain)
Spatial decision support system service
5.2.2 Modify the topology of the water supply system representation
Identifier UC-SDSS-ModifyLogicalModel
Goal Modify the topology of the water supply system representation in the SDSS. In order to
obtain useful results from the SDSS, a faithful representation of the real water supply
system present in the site must be available
Deliverable D4.1 – Decision supporting tools system requirements
44
URBAN-WATER PUBLIC
Grant Agreement: 318602
Preconditions The topology of the water supply system representation is being displayed at this
moment
Flow of events 1. The water manager modifies the representation of the water supply system
through the spatial decision support system service
2. The new representation of the water supply system is saved into the SDSS
Post conditions The modifications for the topology of the water supply system representation have
been stored into the SDSS
Trigger Every time the water manager needs to modify the representation of the water supply
system
Priority Expected
Actors Goodwater’s manager (water utility managing the water supply distribution chain)
Spatial decision support system service
5.2.3 Compute new status (online mode)
Identifier UC-SDSS-ComputeOnlineStatus
Goal Compute the status of the system with the last information available and taking into
account the current configuration of the SDSS as well as the current topology of the
water supply system
Preconditions The topology of the water supply system is defined
The configuration of the SDSS for the online mode is available
Flow of events 1. The spatial decision support system service retrieves the last information
available for the items represented in the topology of the water supply system
from the cloud database service
2. The spatial decision support system service retrieves the configuration for the
online mode
3. The spatial decision support system service calculates its new status using the
current configuration and the information retrieved
4. The new status is stored into the SDSS
5. The spatial decision support system service sends a notification to all
subscribed services through the UrbanWater platform telling that a new status
has been calculated and is available
Post conditions The new SDSS status has been computed and stored
Subscribed have been notified that new status has been calculated
Trigger Periodically or every time that new information is available
Priority Mandatory
Actors Spatial decision support system service
Cloud database service
UW platform
UW platform notification service
all services subscribed to the spatial decision support system service
5.2.4 Compute new status (offline mode)
Identifier UC-SDSS-ComputeOfflineStatus
Deliverable D4.1 – Decision supporting tools system requirements
45
URBAN-WATER PUBLIC
Grant Agreement: 318602
Goal Compute the status of the system with the last information available and taking into
account the specified configuration of the SDSS as well as the specified topology of the
water supply system. This use case is useful to answer what-if questions that need
special boundary conditions, usually different from the actual ones.
Preconditions The topology of the water supply system is defined
A configuration of the SDSS is available and specified. More than one configuration
may be available, for example to test different parameters over the elements of the
site
Flow of events 1. The spatial decision support system service retrieves the last information
available for the items represented in the topology of the water supply system
from the cloud database service
2. The spatial decision support system service retrieves the specified
configuration
3. The spatial decision support system service calculates its new status using the
specified configuration and the information retrieved
4. The computed status is stored into SDSS
Post conditions The new SDSS status has been computed and stored
Trigger Every time the water manager wants to run the SDSS with a special configuration and
topology representation
Priority Mandatory
Actors Goodwater’s manager
Spatial decision support system service
UW platform
Cloud database service
5.2.5 Display configuration
Identifier UC-SDSS-DisplayConfiguration
Goal Display a specified SDSS configuration
Preconditions (none)
Flow of events 1. The water manager/operator chooses the configuration to be displayed
2. The spatial decision support system service retrieves the specified
configuration from itself
3. The spatial decision support system service displays the configuration
Post conditions The specified configuration is displayed
Trigger Every time the water manager wants to display a SDSS configuration
Priority Expected
Actors Goodwater’s manager/operator
Spatial decision support system
5.2.6 Display the topology of the water supply system representation
Identifier UC-SDSS-DisplayLogicalModel
Deliverable D4.1 – Decision supporting tools system requirements
46
URBAN-WATER PUBLIC
Grant Agreement: 318602
Goal Display the topology of the specified water supply system representation. This topology
representation corresponds to an abstraction of the physical topology of a site.
Preconditions At least the topology of one water supply system is defined
Flow of events 1. The water manager/operator chooses the water supply system representation
to be displayed
2. The spatial decision support system service retrieves the topology of the
specified water supply system representation from itself
3. The spatial decision support system displays the topology retrieved
Post conditions The topology of the specified water supply system representation is displayed
Trigger Every time the water manager wants to display the topology of a water supply system
representation
Priority Expected
Actors Goodwater’s manager/operator
Spatial decision support system
5.2.7 Display the topology of the water supply system
Identifier UC-SDSS-DisplayPhysicalModel
Goal Display the topology of the water supply system. This topology corresponds to the
physical distribution of the elements on the site.
Preconditions Water supply system physical model has been defined
Flow of events 1. The spatial decision support system retrieves the topology of the water supply
system from itself
2. The spatial decision support system displays the topology retrieved
Post conditions The topology of the water supply system has been displayed
Trigger Every time the water manager/operator wants to display the topology of the water supply
system
Priority Mandatory
Actors Goodwater’s manager/operator
Spatial decision support system
5.2.8 Retrieve status
Identifier UC-SDSS-RetrieveStatus
Goal Provide the current status of the SDSS (online mode) to any interested module
Preconditions The SDSS status has been computed
Flow of events 1. The spatial decision support system service retrieves the current SDSS status
for the online mode from itself
2. The spatial decision support system service provides the information to the
requesting module through the UrbanWater platform
Post conditions The current status information has been provided
Trigger Every time a module requires the SDSS status information
Priority Mandatory
Actors Spatial decision support system service
Deliverable D4.1 – Decision supporting tools system requirements
47
URBAN-WATER PUBLIC
Grant Agreement: 318602
UW platform
Any UW module that needs the current SDSS status information
5.3 Requirements
This section presents the functional requirements derived from the use cases explained previously. Intuitively,
functional requirements refer to what does the system do, and can be expressed with the form “system must do
<requirement>”.
Table 4 contains the template used to describe each requirement, including a unique identifier, the priority, a textual
description of the requirement, a list of components of the UW platform affected by the requirement, the list of use
cases affected by the requirement and, finally, a remark section where appropriate clarifications could be included.
Requirement# A unique characters
string (e.g. code, name)
Priority One of Mandatory,
Expected or Optional.
Indicates how critical it is
to implement the
requirement from the
customer’s and the
system’s point of view
Requirement A brief description of the requirement
Component Components of the UW
platform affected by the
requirement
Use Cases Use cases affected by the
requirement
Remark Any other relevant comment regarding the requirement
Table 4: Requirements definition template
As previously defined, requirements priority can be mandatory, expected or optional. The differentiation between
mandatory and expected is done depending how critical each requirement is compared to other requirements. Thus
mandatory requirements are critical for the SDSS and expected requirements are less critical but should be fulfilled.
It is important to remark that SDSS can be used even if expected requirements are not accomplished.
5.3.1 Retrieve demand prediction
Requirement# REQ-SDSS-1 Priority Expected
Requirement The SDSS should be able to acquire water demand prediction data from cloud
database service using the UW platform’s built-in services for message exchange.
Component SDSS
UW platform
Cloud database
Use Cases UC-SDSS-
ComputeOnlineStatus
UC-SDSS-
ComputeOfflineStatus
Remark
5.3.2 Retrieve availability prediction
Requirement# REQ-SDSS-2 Priority Expected
Deliverable D4.1 – Decision supporting tools system requirements
48
URBAN-WATER PUBLIC
Grant Agreement: 318602
Requirement The SDSS should be able to acquire water availability prediction data from cloud
database service using the UW platform’s built-in services for message exchange.
Component SDSS
UW platform
Cloud database
Use Cases UC-SDSS-
ComputeOnlineStatus
UC-SDSS-
ComputeOfflineStatus
Remark
5.3.3 Retrieve leakages detection
Requirement# REQ-SDSS-3 Priority Expected
Requirement The SDSS should be able to acquire leakages detection data from cloud database
service using the UW platform’s built-in services for message exchange.
Component SDSS
UW platform
Cloud database
Use Cases UC-SDSS-
ComputeOnlineStatus
UC-SDSS-
ComputeOfflineStatus
Remark
5.3.4 Retrieve water utility data
Requirement# REQ-SDSS-4 Priority Mandatory
Requirement The SDSS must be able to acquire water utilities data from cloud database service
using the UW platform’s built-in services for message exchange.
Component SDSS
UW platform
Cloud database
Use Cases UC-SDSS-
ComputeOnlineStatus
UC-SDSS-
ComputeOfflineStatus
Remark This information will vary depending on the validation site. Examples of this
information are:
Volumes on reservoirs
Consumption measurements
Flow in the WDN
5.3.5 Modify the topology of the water supply system representation
Requirement# REQ-SDSS-5 Priority Expected
Requirement The SDSS should be able to change water supply system logical model
Component SDSS Use Cases UC-SDSS-
ModifyLogicalModel
Remark This requirement includes the following sub-requirements to modify the water
supply system representation:
The SDSS should be able to add a new element to the existing topology
Deliverable D4.1 – Decision supporting tools system requirements
49
URBAN-WATER PUBLIC
Grant Agreement: 318602
The SDSS should be able to edit the values of the parameters or variables
of an existing element
The SDSS should be able to modify the relationships between elements
The SDSS should be able to link each element variable with a data source
supplied by UW platform
The SDSS should be able to remove an existing element of the topology
The SDSS should only remove an element when is not used in any rule
5.3.6 Modify SDSS configuration
Requirement# REQ-SDSS-6 Priority Expected
Requirement The SDSS should be able to modify its configuration
Component SDSS Use Cases UC-SDSS-
ModifyConfiguration
Remark This configuration is used to determine what is the new SDSS status. An open and
modular interface will be developed to allow water managers to modify the SDSS
configuration. A domain expert from each water utility will be trained during the
validation period to configure the SDSS and validate computation results provided
from the SDSS status.
This requirement includes the following sub-requirements:
The SDSS should be able to add a new rule, specifying the name of the
rule, the conditions and the actions to perform when conditions are true
The SDSS should be able to modify an existing rule (the name, conditions
and actions to perform)
The SDSS should be able to remove an existing rule
5.3.7 Compute SDSS status (online mode)
Requirement# REQ-SDSS-7 Priority Mandatory
Requirement The SDSS must be able to calculate a new SDSS status
Component SDSS Use Cases UC-SDSS-
ComputeOnlineStatus
Remark This new status will be calculated using the water supply system logical model,
SDSS configuration, and data acquired from the cloud database through the UW
platform
5.3.8 Compute SDSS status (offline mode)
Requirement# REQ-SDSS-8 Priority Expected
Requirement SDSS should be able to calculate a new status based on a testing configuration
Component SDSS Use Cases UC-SDSS-
ComputeOfflineStatus
Deliverable D4.1 – Decision supporting tools system requirements
50
URBAN-WATER PUBLIC
Grant Agreement: 318602
Remark This new status will be calculated in the same way as in requirement REQ-SDSS-
7, but using a different configuration defined by the water manager
5.3.9 Store SDSS status
Requirement# REQ-SDSS-9 Priority Mandatory
Requirement The SDSS must be able to locally store its status within the SDSS
Component SDSS Use Cases UC-SDSS-
ComputeOnlineStatus
UC-SDSS-
ComputeOfflineStatus
Remark -
5.3.10 Provide SDSS status
Requirement# REQ-SDSS-10 Priority Mandatory
Requirement The SDSS must be able to provide its current status to other modules
Component SDSS
UW platform
Use Cases UC-SDSS-RetrieveStatus
Remark Status information will be provided using UW platform’s event concept.
5.3.11 Display the topology of the water supply system representation
Requirement# REQ-SDSS-11 Priority Optional
Requirement SDSS should be able to display the water supply system logical model
Component SDSS Use Cases UC-SDSS-
DisplayLogicalModel
Remark This requirement is considered as optional because it only provides water operator
and water manager a better understanding of the water supply system.
5.3.12 Display the topology of the water supply system
Requirement# REQ-SDSS-12 Priority Mandatory
Requirement The SDSS must be able to display the water supply system physical model
Component SDSS Use Cases UC-SDSS-
DisplayPhysicalModel
Remark This physical model should be displayed over a map similar to Google maps, to
understand the elements distribution. The display of the system will be done using
a Geographic Information System (GIS) system and some technologies like Web
Map Server (WMS) for displaying maps and Web Feature Service (WFS) for
displaying the elements. All these technologies are considered as standards by the
Open Geospatial Consortium (OGC), a standards organization composed by more
than 400 organizations.
Deliverable D4.1 – Decision supporting tools system requirements
51
URBAN-WATER PUBLIC
Grant Agreement: 318602
5.3.13 Send notifications through the platform
Requirement# REQ-SDSS-13 Priority Mandatory
Requirement The SDSS must be able to send notifications through the platform, for example to
indicate to other subscribed modules that a new execution has been performed
Component SDSS
UW platform
Subscribed modules
Use Cases UC-SDSS-
ComputeOnlineStatus
UC-SDSS-
ComputeOfflineStatus
Remark -
Deliverable D4.1 – Decision supporting tools system requirements
52
URBAN-WATER PUBLIC
Grant Agreement: 318602
6 Decision supporting tools
In the context of UrbanWater four decision supporting tools will be developed and integrated as core modules that
will provide added value information to the platform and specifically to the SDSS. The next sections describe the
scenarios, uses cases and requirements related to these tools.
6.1 Water demand prediction system
The main purpose of the water demand prediction system (WDPS) is to provide information to different modules
on the platform of the predicted water demand related to a certain flow metering point in the water distribution
network. Water demand relates to the overall amount of water flowing through a certain point in the network between
two flow meter sampling instances. An equivalent quantity may be the mean flow of water between two sampling
instances, being the overall water amount flown divided by the sampling time.
Besides the usage of demand predictions in the SDSS, also other modules of the UrbanWater platform, like leakage
detection system or adaptive pricing, will need a water demand prediction.
The water demand prediction will be generated based on data provided by the water distributor and service
providers (weather data, historical data on weather and demand, other data), and will be used by the water
distributor itself and by the other roles in the upstream water chain: water supplier, raw water supplier, water
manager, foremost through the SDSS.
Taking into account also a number of other modules in the UW platform that will use the water demand prediction
data, different prediction horizons might be required. Moreover, some modules might require also the
characterisation of the prediction error alongside with the prediction.
In general, demand prediction needs to be able to accept various time-series of possibly relevant data for demand
at a certain water distribution network point, be able to deduce what data are relevant (influential) for the demand,
and provide predictions of the demand with respect to these data.
6.1.1 Scenarios
Several scenarios of the water demand prediction module are envisaged, foremost based on the current status of
two other relevant modules of the platform: Leakage Detection System (LDS) and Adaptive Pricing System (APS).
For both of these modules the interactions are bidirectional – i.e, both modules will require the prediction itself or
prediction models for water demand, while also their outputs – leak detected or consumer price profiles issued –
will have consequences on the demand and thus need to be considered in demand prediction. Several relevant
scenarios are denoted: (i) normal operation without leaks detected downstream the point of demand prediction and
with fixed prices, (ii) leak detected downstream the point of demand prediction and (iii) adaptive pricing applied to
users downstream the point of demand prediction in the water distribution network.
Naturally, it is envisaged that the SDSS is also the user of water demand prediction issued by the WDPS module
in its various decision support rules.
Deliverable D4.1 – Decision supporting tools system requirements
53
URBAN-WATER PUBLIC
Grant Agreement: 318602
The WDPS will use the data stored in the UrbanWater cloud-based data storage (data requirements will be defined
in Work Package 3, D3.1). The corresponding cloud-based database system will also provide other data, like
meteorological or possibly in a more futuristic scenario that of other urban utility systems with dynamic distribution
prices fluctuation (the UW platform will remain open for that). The data on predicted demand and on demand
prediction model parameterisation will be communicated to the data storage such that recent predictions and
demand prediction models themselves may be available from the database on demand to different modules.
Figure 11 summarizes the basic relations between the modules.
Figure 11: Envisaged modules’ outputs flow on the UrbanWater platform with respect to WDPS
6.1.1.1 Leakage detection system
In the event of a detected leak downstream the demand prediction point, the WDPS will need to be notified so that
it can send a notification that the demand prediction has less accuracy. The actual demand data that will be
uploaded to the cloud database service to constitute historical data for future predictions will have to be
accompanied with this notification.
A differentiation will be performed between suddenly detected leaks / bursts and detected long-lasting leaks – while
the first ones will be used to correct the demand predicted by the model, the latter ones will be inherently contained
in the demand. Plans of leak repairing interventions should also be added to the platform to provide better demand
prediction possibilities.
Vice versa, sudden significant deviations between prediction and actual demand realisation should be quality
information for the LDS.
6.1.1.2 Adaptive pricing system
When the APS is active, the future demand is also affected by varying water distribution prices. For such a case
the inputs of the water demand prediction model will have to be extended with the price fluctuations. Vice versa –
the APS will have to use the information on the users’ price responsiveness to be able to optimise for the best water
Deliverable D4.1 – Decision supporting tools system requirements
54
URBAN-WATER PUBLIC
Grant Agreement: 318602
price profile over time – it will reconstruct such responsiveness from the demand prediction model that will be also
stored on the cloud database through the UW platform.
6.1.1.3 SDSS
The SDSS module will be in the position to require demand predictions from the WDPS for different water
distribution network points and prediction horizons.
6.1.1.4 UrbanWater Cloud Database
Time-series of potentially relevant data for demand prediction will be stored in the cloud database. These might
include:
demand time-series from various points in the distribution network (e.g. higher consumption in one part
of the city may very well correlate with lower consumption at the other part due to daily migrations),
weather data time series,
water distribution prices,
date that have occurred leaks,
calendar data with notion of special events,
other utility prices.
The cloud database stores the demand prediction model parameterisation if the on-line adaptation procedure of
the demand prediction model is applied. This is to enable easier retrieval of previous model parameters, as well as
to be able to debug the self-tuning module part behaviour based on the historical logs. The current demand
prediction model will be relevant for adaptive pricing module in order to deduce the users’ price responsiveness in
the current conditions.
The cloud database also stores relevant output data of LDS and APS modules, both current and history logs. For
a detected leak downstream the point of demand prediction, the WDPS should be informed about the leak amount
and estimated time of repair. Historical information about leaks is obtained from the cloud database to exclude leak-
corrupted data from prediction models tuning in the future. Data on leaks need to be matched with those DMA
points whose flow is affected by the leak, such that future demand prediction model tuning based on that data can
take these leaks into account – an additional requirement posed on the cloud database. For the APS, applied prices
for the users downstream the prediction point are stored via the cloud database to allow the demand prediction
model to also take price responsiveness of users into account when providing demand predictions and performing
self-tuning.
6.1.1.5 Detailed indoor consumption module
It is also expected that the detailed indoor consumption module will support the demand prediction and
understanding of the demand drivers on the users level. Its effects on demand through communication with the
user, as well as through information amplification via serious gaming remain to be validated in a long term.
Deliverable D4.1 – Decision supporting tools system requirements
55
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.1.2 Use cases
The following two use cases have been detected within the WDPS. Demand prediction display will be done through
UW platform’s dashboards, so this use case is omitted because it is considered as a generic use case of the UW
platform, described in deliverables D6.1 and D6.2.
6.1.2.1 Compute water demand prediction for the required water distribution network point
Identifier UC-WDPS-ComputeWaterDemandPrediction
Goal Calculate the water demand prediction for the water distribution network point.
Preconditions Historical data logs with a suitable sampling time for the particular point are
available
Currently applied prices for downstream water distribution (or the info that the
price is fixed) are available
Dates of leakage events are available
An initial model calibration has been performed for the particular water
distribution network point
One or several modules have issued their requests for prediction and required
prediction intervals for a network point
Flow of events 1. Prediction is initiated at the multiple of the sampling time
2. The WDPS fetches the prediction time horizon requirements from the cloud
database service.
3. The WDPS fetches the specified data in the preconditions from the cloud
database service.
4. The WDPS computes the demand prediction for the network point on the union
of required prediction intervals
5. The WDPS stores demand prediction into cloud database service through the
UW platform
6. The WDPS computes the estimate of the demand prediction error along the
prediction horizon
7. The WDPS updates the demand prediction model configuration and stores the
new configuration on the cloud database service through the UW platform
(adaptation is not performed at every sampling instant).
Post conditions New demand predictions are available with prediction errors estimates
New prediction model parameters are available (not every sampling instant)
Trigger At the multiple of the sampling time for prediction
Priority Mandatory
Actors WDPS
Goodwater’s manager /operator (through SDSS).
LDS
APS
Cloud database service
UW platform notification service.
Deliverable D4.1 – Decision supporting tools system requirements
56
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.1.2.2 Initialize water demand prediction model for the required water distribution network point
Identifier UC-WDPS-InitializeModel
Goal Calculate the initial water demand prediction model for a water distribution network point
and the corresponding set of relevant data.
Preconditions Historical data logs on the UrbanWater platform for the required point, with a
suitable sampling time are available
Cloud database service is subscribed to prediction events at the UW platform
Required prediction horizon is provided
Flow of events 1. The WDPS collects potential candidate data series for model development
from history logs from cloud database service and determines relevant
variables for prediction of the demand in the corresponding water distribution
network point.
2. The WDPS computes an initial prediction model based on history logs of the
relevant variables.
3. Initial prediction has been performed for the prediction horizon required –
obtained prediction time series and estimated prediction error
4. Notion on relevant variables and initial model parameters are stored on the
cloud database service via the UW platform
5. The initial prediction is provided to the UW platform (and the subscribed cloud
database service will store the initial prediction)
Post conditions Selected relevant variables for future demand prediction and initial model for
prediction have been computed and provided
Trigger An UrbanWater platform module requests a prediction for a point in the water network
for which the prediction model so far does not exist
Priority Mandatory
Actors WDPS
Goodwater’s manager/operator (through SDSS).
LDS
APS
Cloud database service through UW platform
6.1.3 Requirements
6.1.3.1 Sampling time and prediction horizon length
Requirement# REQ-WDPS-1 Priority Mandatory
Requirement The prediction sampling time, taking into account the different requirements of
SDSS, LDS and adaptive pricing, must be an integer multiple of the sampling time
for the flow meters in the water distribution network. The length of the prediction
horizon must be determined on-line based on the standing prediction needs of the
other modules.
Component WDPS
UW platform
Cloud database service
Use Cases All use cases
Deliverable D4.1 – Decision supporting tools system requirements
57
URBAN-WATER PUBLIC
Grant Agreement: 318602
Remark Sampling times between 15 minutes and 1 hour seem appropriate for all the
purposes of the demand prediction.
6.1.3.2 Accuracy
Requirement# REQ-WDPS-2 Priority Mandatory
Requirement The WDPS must be as accurate as possible in providing predictions of water
demand for other modules, taking advantage of the available historical data for the
demand at the given water distribution network point, as well as the current and
past relevant outputs of other modules, like leakage detection or adaptive pricing.
Component WDPS
UW platform
Cloud database service
Use Cases All use cases
Remark -
6.1.3.3 Adaptation to demand changes
Requirement# REQ-WDPS-3 Priority Mandatory
Requirement Taking into account that the demand changes over time due to migrations, distribution
network changes, new users etc., the demand prediction model (for any WDN point)
must be able to perform periodic adaptation of its parameters.
Component WDPS
UW platform
Use Cases UC-WDPS-
ComputeWaterDemandPr
ediction
Remark -
6.1.3.4 Estimation of the prediction uncertainty
Requirement# REQ-WDPS-4 Priority Expected
Requirement In order to provide information about the uncertainty of the on-line provided demand
prediction, the WDPS should also issue an estimate of the prediction error, in terms
of its covariance.
Component WDPS
UW platform
Use Cases All use cases
Remark -
6.1.3.5 Ability of automated initialisation
Requirement# REQ-WDPS-5 Priority Mandatory
Requirement The prediction model initialisation for a certain point in the network and later on
model tuning must be fully automated.
Component WDPS
UW platform
Use Cases UC-WDPS-
InitializeModel
Remark -
Deliverable D4.1 – Decision supporting tools system requirements
58
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.1.3.6 Cooperation with other modules
Requirement# REQ-WDPS-6 Priority Mandatory
Requirement The WDPS must be well integrated with the cloud database service, LDS and APS
by using the UW platform as a common message brokering and event-/subscription
platform.
Component WDPS
UW platform
LDS
APS
Cloud database service
Use Cases All use cases
Remark The subsequent designs must well encompass these interactions.
6.1.3.7 Responsive to other modules’ outputs
Requirement# REQ-WDPS-7 Priority Mandatory
Requirement The WDPS should be responsive to detected leaks downstream the point of
demand prediction as well as to the applied distribution prices to the users
downstream the prediction point.
Component WDPS
LDS
APS
UW platform
Use Cases All use cases
Remark -
6.1.3.8 Immunity to outliers in the recorder flow data and to false measurements
Requirement# REQ-WDPS-8 Priority Expected
Requirement WDPS must be able to detect outliers and false measurements in the recorded flow
sequence, based on past data, the identified model and the estimated prediction
error. It should however be adaptable to accept radically different flow patterns if
they tend to repeat.
Component WDPS
UW platform
Use Cases All use cases
Remark -
6.2 Detailed indoor consumption module
The main purpose of the Detailed Indoor Consumption Module (DICM) is to interpret the full consumption signature
of the commercial water meter (with usually no better resolution than 1 pulse per litre) with respect to individual
usages of water use devices in the household (kitchen tap, shower, garden tap, etc.).
The idea is to perform this characterisation with a metering resolution of commercially available smart meters to
enable a mass deployment of such a service. Furthermore, the characterisation models will need to adapt to water
usages in individual households.
Deliverable D4.1 – Decision supporting tools system requirements
59
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.2.1 Scenarios
Two scenarios are envisaged. One is to inform the utilities of which devices are used in households and when, in
order to better understand the drivers of demand and trace how the users’ behaviour changes over time. This
information will prove valuable for preparing strategic decisions for water regulators. Furthermore, this information
can be used in order to determine the percentage of the consumed water that enters the sewage system and needs
to be treated within the wastewater treatment system.
In another scenario that is related to users’ empowerment (WP5) the module produces information for the on-line
user platform where the user can compare his behaviour with respect to individual water usages of groups of
citizens, whereas such dashboards are envisaged to be strong drivers for behavioural change. For instance, typical
information served to users might be: “Your washing machine consumes 2.3 times more water than the average
washing machine in the neighbourhood”. Adaptation of the characterisation procedure is here envisaged as well.
6.2.2 Use cases
Two main use cases will be considered for the DICM. In one use case based on the recorded data from the water
meter a sequence of different usages will be produced. In the other use case the user will be confronted with the
characterised usages and asked to either confirm or decline and optionally change them to something else or
disregard them. In such a way data for adaptation of the initial detailed indoor consumption model to the individual
household will be obtained. Users will be also offered the possibility to add or remove certain water use devices
from their model setup.
6.2.2.1 Perform characterisation of the water meter signature
Identifier UC-DICM-Characterise
Goal Characterise performed consumptions on individual water use devices in the house for
the past hour.
Preconditions Available recorded consumption profile from the water meter for the previous
hour
Available detailed indoor consumption model for the particular household
Flow of events 1. Fetch the detailed characterisation model for the household (water consumer)
and the detailed smart water meter signature from the previous hour
2. Calculate pre-defined features from the recorded consumption data in the last
hour
3. Classify the features in different clusters that correspond to individual usage
devices
4. Assign start/stop time and consumption amount to individual usages
5. Return the performed characterisation (characterised usage, start/stop time,
consumed amount) back to the cloud database system
6. Water consumer is informed on the characterisation results
Post conditions -
Trigger Time trigger at the full-hour time stamp
Priority Optional
Deliverable D4.1 – Decision supporting tools system requirements
60
URBAN-WATER PUBLIC
Grant Agreement: 318602
Actors DICM
Cloud database service through UW platform
Peter Liquid
6.2.2.2 Update characterisation model for a particular household
Identifier UC-DICM-Update
Goal Update the detailed characterisation model for a particular household based on the
feedback received from the household (water consumer).
Preconditions Available consumption profiles from the database
Available performed characterisations with provided feedback from the
household
Flow of events 1. Fetch the consumption profiles recorded on the household water meter for the
available past period from the cloud database through the UW platform
2. Calculate pre-defined features from the recorded consumption data
3. Assign the features to different usages as provided in the feedback from the
household
4. Recompute the boundaries between features, i.e. the new detailed indoor
consumption model for the household
5. Put the new model on the cloud database through the UW platform
Post conditions -
Trigger Enough feedback data from the household available
Priority Optional
Actors DICM
Cloud database service through UW platform
Peter Liquid
6.2.3 Requirements
6.2.3.1 Ability to interpret commercial smart water meter signature as a sequence of usages of water devices
Requirement# REQ-DICM-1 Priority Expected
Requirement The demand prediction module should be able to interpret the recorded waveform
on the household meter as a sequence of individual water devices usages, as well
as to provide the start/stop time of the usage event together with the water
consumption related with that usage; for viability of commercial deployment the
model should be able to operate with water meters of resolution of 1 pulse per litre
or worse.
Component DICM
UW platform
Cloud database
Use Cases All use cases
Remark -
Deliverable D4.1 – Decision supporting tools system requirements
61
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.2.3.2 Ability to adapt to the individual household
Requirement# REQ-DICM-2 Priority Expected
Requirement The demand prediction module should be able to adapt the characterisation model
according to the feedback of usage characterisation received from the household.
Component DICM
UW platform
Cloud database
Use Cases All use cases
Remark -
6.3 Water availability prediction system
The main purpose of the water availability prediction system (WAPS) is to provide information for the water utilities
about the predicted water availability related to reservoirs.
Besides the contribution of this information to the water utility’s management tasks, WAPS outputs will be used by
the SDSS as an input to be combined with other information to propose some management and operation tasks to
be held.
The water availability prediction will be generated based on data provided by raw water suppliers and service
providers (weather data, historical records, etc.), and will support both raw water supplier and water manager
operations. In addition, water suppliers and water distributors could use this information as a support in order to
know the current and future status of water sources. All these actors could access this information in the module
itself or indirectly through the SDSS.
For those purposes, different water availability predictions are required. On the one hand, a short-term prediction
is necessary to know more precisely the availability for the next days. On the other hand, a long-term prediction is
needed to have an availability trend for the next months using historical records and current status. This information
will allow raw water suppliers having an idea about the future water sources’ evolution.
Short-term availability prediction will be calculated in two steps. The first one is to calculate the potential amount of
accumulated precipitation within a reservoir’s contributing basin for the next days. This precipitation could be
converted to the potential water volume reaching the reservoir, but no losses, infiltration, evaporation or
transportation time would be taken into account. Thus, in a second step, running a hydrological model will allow
converting the forecast precipitation to water inflow to the reservoir taking into account the stated factors.
Hydrological models calculate water inflow every determined time step in the reservoir, and a conversion to water
volume can be done.
Long-term prediction will take into account historical records of the reservoir volume to calculate the reservoir year-
around evolution. This evolution will be combined with the current reservoir volume to provide a prediction of how
reservoir volume will vary using historical trends. This prediction provides raw water suppliers a long-term prediction
of how the reservoir volume could evolve for the next months.
Deliverable D4.1 – Decision supporting tools system requirements
62
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.3.1 Scenarios
Two scenarios for the water availability prediction module are envisaged, mainly based on the current status of the
UW platform modules: the WAPS itself and the SDSS. Thus two relevant scenarios are denoted: (i) water availability
prediction on a reservoir and (ii) calculating possible decisions to be taken by water managers.
The WAPS will use the data stored in the UW platform data storage, and its outputs will be stored there too. The
cloud database service will provide hydrological data (volumes on reservoirs, sensors data, basin information, etc.
for the hydrological model) and meteorological data (e.g. precipitation data).
Figure 12 shows the interaction between the modules.
Figure 12: UW modules interaction with WAPS
6.3.1.1 Water availability prediction system
Water availability prediction will provide the availability predictions (based on its calculations) for each reservoir to
raw water suppliers and water manager. Three options are considered regarding which module could display this
information:
UW platform creating a specific dashboard: This option integrates WAPS information into the UW platform,
and permits a validation of communication between modules and the platform. In addition it could provide
a similar look and feel as the other UW platform’s dashboards.
SDSS displaying the information in the physical model display: The SDSS physical model will display all
the current information used by the SDSS to calculate its status. Thus water availability prediction will be
displayed as well. This option allows an integrated view of all the information that the water manager and
water operator use in their management tasks.
WAPS module creating its own dashboard: This option gives the WAPS module an independency to the
rest of the UW modules. This dashboard would display all the reservoirs a raw water supplier operations
and its current and predicted volume for the next days and months for each of them.
Since other modules like WDPS will display their information using UW platform dashboards, the WAPS will be
implemented using external dashboards, in order to test the capability of the UW platform of displaying different
external dashboards.
6.3.1.2 SDSS
The SDSS will use availability predictions from the WAPS module to calculate possible management tasks to be
held within the water supply system. The WAPS will be one of the four modules providing input information to the
SDSS, together with information directly provided by water utilities. The SDSS will display not only its status but
also different inputs provided by other modules and water utilities. Availability prediction in the reservoirs can be
used by water managers to establish policies for reducing water consumption in case of risk of water scarcity or to
calculate the water volume for the next days in the reservoirs taking into account demand prediction.
Deliverable D4.1 – Decision supporting tools system requirements
63
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.3.2 Use cases
6.3.2.1 Compute short-term water availability prediction for the reservoirs
Identifier UC-WAPS-ComputeShortTerm
Goal Calculate water availability prediction for the next week (short-term) for all the modelled
reservoirs.
Preconditions Water manager has configured WAPS for at least one reservoir (model
configuration file with basin model description and execution properties is
available).
WAPS is subscribed to cloud database service to acquire information
Flow of events 1. The WAPS acquires all the needed information from cloud database service
through UW platform.
2. The WAPS calculates the short-term availability prediction of all the reservoirs
using previously acquired data
3. WAPS stores into the cloud database service the new calculated availability
predictions into cloud database
4. The WAPS notifies to subscribed modules through the UW platform new
calculation has been held.
Post conditions There is a new availability prediction calculated for each reservoir.
The WAPS has informed other UW platform modules that new information is
available.
Trigger Every time new data is available
Priority Mandatory
Actors Goodwater’s manager / operator
UW platform notification service.
Any UW module subscribed to the module (spatial decision support system
service)
6.3.2.2 Compute long-term water availability prediction for the reservoirs
Identifier UC-WAPS-ComputeLongTerm
Goal Calculate water availability prediction for all the modelled reservoirs for the next months.
Preconditions The water manager has implemented in the reservoirs the long-term
availability forecast methodology (based on the use of historical information).
Flow of events 1. The WAPS acquires all the needed information from cloud database service
through UW platform.
2. The WAPS calculates the long-term availability prediction of all the reservoirs
for the next months.
3. The WAPS stores the new calculated long-term availability predictions into
cloud database service through the UW platform.
4. The WAPS notifies to the subscribed modules through the UW platform that
new calculation has been performed.
Post conditions There is a new availability prediction calculated for each reservoir.
The WAPS has informed other UW modules that new information is available.
Deliverable D4.1 – Decision supporting tools system requirements
64
URBAN-WATER PUBLIC
Grant Agreement: 318602
Trigger Every time new data is available
Priority Mandatory
Actors Goodwater’s manager/operator
UW platform notification service.
SDSS
Cloud database
6.3.2.3 Display availability for reservoir
Identifier UC-WAPS-DisplayAvailability
Goal Display the availability prediction of the indicated reservoir.
Preconditions A reservoir is specified to display its availability prediction and this reservoir
exists in the water supply logical model
Flow of events 1. WAPS platform shows a list of all the reservoirs.
2. Water manager selects a reservoir to analyse its availability prediction.
3. WAPS retrieves the information from cloud database.
4. WAPS displays this information to water manager.
Post conditions None
Trigger Every time water manager wants to analyse water availability prediction of one reservoir
Priority Mandatory
Actors Goodwater’s operator
UW platform.
Specific UW modules: cloud database
6.3.3 Requirements
6.3.3.1 Retrieve radar data
Requirement# REQ-WAPS-1 Priority Mandatory
Requirement The WAPS must be able to acquire radar data from cloud database service through
UW platform
Component WAPS
UW platform
Cloud database
Use Cases UC-WAPS-
ComputeShortTerm
Remark -
6.3.3.2 Retrieve rain gauges data
Requirement# REQ-WAPS-2 Priority Expected
Requirement The WAPS should be able to acquire rain gauges data from cloud database service
through UW platform
Component WAPS
UW platform
Cloud database
Use Cases UC-WAPS-
ComputeShortTerm
Deliverable D4.1 – Decision supporting tools system requirements
65
URBAN-WATER PUBLIC
Grant Agreement: 318602
Remark -
6.3.3.3 Retrieve precipitation from NWP data
Requirement# REQ-WAPS-3 Priority Mandatory
Requirement The WAPS must be able to acquire NWP data from cloud database service through
UW platform
Component WAPS
UW platform
Cloud database
Use Cases UC-WAPS-
ComputeShortTerm
Remark -
6.3.3.4 Retrieve aggregated hydrological model description of a basin
Requirement# REQ-WAPS-4 Priority Expected
Requirement The WAPS should be able to use aggregated hydrological models from each basin
of a reservoir to calculate their water availability.
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark -
6.3.3.5 Retrieve reservoir volumes’ historical data
Requirement# REQ-WAPS-5 Priority Mandatory
Requirement The WAPS must be able to acquire reservoir volumes used for the seasonal
forecasting. This information will be retrieved through UW platform’s services
Component WAPS
UW platform
Cloud database
Use Cases UC-WAPS-
ComputeLongTerm
Remark -
6.3.3.6 Quality control of radar precipitation estimations
Requirement# REQ-WAPS-6 Priority Expected
Requirement WAPS should be able to quality control radar precipitation estimates
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark Due to different errors affecting radar precipitation estimates, there is a need of
perform a quality control process in order to improve its quality. This process should
take into account at least:
The calibration of the radars
The correction of the non-meteorological echoes
Deliverable D4.1 – Decision supporting tools system requirements
66
URBAN-WATER PUBLIC
Grant Agreement: 318602
The underestimation due to beam blockages (interaction of the radar
measurement process with the topography and other elements).
The quality control process is necessary both to provide realistic precipitation
estimates and to eliminate artefacts on the precipitation estimated that might affect
algorithms using them.
The radar reflectivity should be then transformed into rain rate using a climatological
Z-R relationship.
6.3.3.7 Calculate radar nowcast
Requirement# REQ-WAPS-7 Priority Mandatory
Requirement The WAPS must calculate 6 hours of radar nowcasting (precipitation forecasting).
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark The precipitation’s movement field should be calculated from the last radar
observations (by means of cross correlation techniques, for instance). This
movement field should be used to extrapolate the last observations in order to
provide forecast precipitation fields for the next hours.
Forecasting of precipitation with radar nowcasting techniques cannot be used for
large leadtimes (forecasting abilities decay quickly) but provides the best
precipitation forecasting for the next 1-6 hours that can be obtained, and the rapid
update of the techniques allows keeping the forecasting updated with the lastest
observations.
6.3.3.8 Calculate rainfall accumulation from radar instantaneous precipitation fields
Requirement# REQ-WAPS-8 Priority Mandatory
Requirement The WAPS must be able to calculate rainfall accumulation fields using radar
instantaneous estimates (both observed and forecasted by nowcasting techniques).
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark In order to calculate rainfall accumulation form the radar instantaneous precipitation
estimates, the movement of the precipitation field should be taken into account. A
direct sum of the instantaneous precipitation fields will not provide realistic
accumulations, because the precipitation between radar scans would not be taken
into account.
Thus, the movement field between each couple of observations should be
estimated and then used to calculate all the intermediate states between
observations by interpolation techniques that take into account the movement of the
field (minute by minute rainfall fields, for instance). The final accumulation field
should then be computed taking into account all the intermediate information.
Deliverable D4.1 – Decision supporting tools system requirements
67
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.3.3.9 Calculate accumulations from rain gauges
Requirement# REQ-WAPS-9 Priority Expected
Requirement The module should be able to calculate 1hour accumulations using rainfall
information from rain gauges
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark The rainfall information from rain gauges should be quality controlled before its use
in order to discard values that are not correctly measured. In this sense, a set of
quality control algorithms should be applied to filter the data. The controls should
include, at least:
Identification of missing values.
Identification of out of range values.
Check of consecutive values slope in a certain range, in order to avoid
both a big variability between values and a too small variability (sensor
stuck).
After the quality control check, the rain gauges rainfall should be accumulated
taking into account the gaps that the records might have.
6.3.3.10 Combine radar and rain gauges
Requirement# REQ-WAPS-10 Priority Expected
Requirement The module should be able to combine radar precipitation fields and rain gauges
information to generate more accurate precipitation fields
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark Rain gauges information should be used to improve measured radar accumulation
fields with geoestadistical merging techniques. These techniques make use of each
source of data (punctually observed values in the case of rain gauges and the high
resolution spatial distribution of the precipitation in the case of radar fields) to
provide a blended precipitation field.
6.3.3.11 Combine radar nowcast with NWP models
Requirement# REQ-WAPS-11 Priority Mandatory
Requirement The WAPS must be able to combine NWP models with radar nowcast accumulation
fields to generate more accurate accumulation fields for the next 6 hours
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark Radar nowcasting provides the best precipitation forecasting that can be obtained
for the first 1-6 hours, and NWP models provide a precipitation forecasting for the
following days. Blending techniques should combine both sources of precipitation
Deliverable D4.1 – Decision supporting tools system requirements
68
URBAN-WATER PUBLIC
Grant Agreement: 318602
forecasting to provide an optimum forecast for the first 6 hours. The combination
should be done taking into account the performance of each source of precipitation
forecasting in the past (comparing with real observations) dynamically.
6.3.3.12 Calculate short-term water predicted volumes using aggregated hydrological model
Requirement# REQ-WAPS-12 Priority Mandatory
Requirement The WAPS must calculate water predicted volumes using an aggregated
hydrological model. It will use measured and forecasted accumulated precipitation
fields as input of the hydrological model.
Component WAPS Use Cases UC-WAPS-
ComputeShortTerm
Remark With the requirements WAPS-8/9/10/11 a continuous precipitation field’s time
series should be created that have at each time the best rainfall
estimation/forecasting than can be obtained. This should be composed by radar-
rain gauge merging in the past; radar observation from the nearly past where the
rain gauges are still not available, radar nowcasting-NWP models blending for the
first hours of forecast; and NWP model forecast for long term forecasts.
This precipitation field’s time series should be used as input of an aggregated
hydrological model deployed and calibrated for the catchment of interest.
6.3.3.13 Calculate long-term seasonal forecasting
Requirement# REQ-WAPS-13 Priority Mandatory
Requirement The WAPS must provide a seasonal forecasting for the next months based on
historical information of reservoir’s volumes.
Component WAPS
UW platform
Cloud database
Use Cases UC-WAPS-
ComputeLongTerm
Remark Long-term historical records of the reservoir’s volumes provide a year around time
series of the mean volumes observed in the past.
This yearly evolutions should be adjusted to the current registered reservoir’s
volume observations in order to provide long-term volumes’ forecasting based on
average evolutions in the past.
6.3.3.14 Display water availability information
Requirement# REQ-WAPS-14 Priority Mandatory
Requirement The WAPS must be able display all the water availability prediction of all the
reservoirs.
Component WAPS
Use Cases UC-WAPS-
DisplayAvailability
Remark The WAPS must display both short and long-term predictions for each reservoir of
the system.
Deliverable D4.1 – Decision supporting tools system requirements
69
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.3.3.15 Send notification: new short-term water availability prediction available
Requirement# REQ-WAPS-15 Priority Mandatory
Requirement The WAPS must be able to send notifications to the UW platform in order to let it
know one new short-term prediction is available to be retrieved.
Component WAPS
UW platform
Use Cases UC-WAPS-
ComputeShortTerm
Remark -
6.3.3.16 Send notification: new long-term water availability prediction available
Requirement# REQ-WAPS-16 Priority Mandatory
Requirement The WAPS must be able to send notifications to the UW platform in order to let it
know one new long-term prediction is available to be retrieved.
Component WAPS
UW platform
Use Cases UC-WAPS-
ComputeLongTerm
Remark -
6.4 Leakage detection system
6.4.1 Scenarios
The quantity of water loss is an important indicator of the positive or negative water management practice. The
LDS allows a water distributor to perform a systematic approach to the distribution network based on two types of
functioning modes, an offline operation and a continuous operating mode. Each operating mode will return the
network’s behaviour and the water distributor will be able to implement a strategy to control water losses.
This section presents the most relevant scenarios to the operational management of the water distribution network,
concerning LDS.
6.4.1.1 Normal and maintenance operation
In a normal situation, a water distributor checks the network behaviour with two main objectives:
Identify small leaks that are not easy to detect in the water volume consumed by end users;
Identify bursts and medium size leaks and act as soon as possible to control the volume of water loss and
to prevent contamination.
To achieve these objectives it is possible to distinguish three sub-scenarios:
Historical Analysis
The water distributor analyzes scenarios or past events, in a given time frame, in order to better understand the
performance of the network, to identify potential or suspected leaks events and to conclude why they occurred.
This analysis allows the water distributor to produce statistical data and a leakage report of the network to deliver
to the Legal Authority.
Deliverable D4.1 – Decision supporting tools system requirements
70
URBAN-WATER PUBLIC
Grant Agreement: 318602
In this type of operation the water distributor will use the leakage detection tools as follows:
With the Mass Balance (MB) the water distributor will attempt to evaluate non-revenue water (NRW) and
real leakage with a top-down approach, by selecting a suitable time window and the concerned control
zone (a single DMA or the entire water supply system). The output is a “Mass Balance” dashboard and
the Leakage estimate;
The Minimum Night Flow Analysis (NFA) will provide a comparison of predicted consumption and metered
consumption. The water distributor can visually access the parameter behaviour and make a judgment on
potential abnormalities. In case of classification as leakage events, the NFA will return the leakage volume;
The Hydraulic Model Builder (HMB) will allow the water distributor to more easily build and maintain a
hydraulic model. The hydraulic model can be used with metered flows and estimated leakage flows for the
identification of hot zones for leakage.
This scenario can be described by the following steps:
The water distributor analyzes the water distribution network and produces a leakage report for a certain
period, with general information and particularly for each DMA.
The water distributor informs the water manager that new information is available.
Near real time analysis
In this scenario the water distributor maintains the system in a continuous operating mode; the water distributor
sets the NFA and/or the MB modules to run continuously within predefined time intervals and will establish threshold
limits that trigger alerts. The water distributor is able to follow the network performance and define a maintenance
plan.
The Alert System then analyzes the results of the periodical running and emits the alerts in the case of
“irregularities”.
This scenario can be described by the following steps:
The water distributor sets which tool should be performed, the periodic running time interval and configure
the threshold parameter;
The water distributor and SDSS are informed that new information is available each time the tool has new
results;
The water distributor and SDSS are informed that there is a potential leak; each time the alert system
emits an alert.
The water distributor defines a maintenance plan and alerts the SDSS that new information is available.
Prospective Analysis
The water distributor analyzes future scenarios. Based on the historical behaviour of the network (topology and
consumptions) the water distributor is able to use HMB to simulate the network operation for a different pattern of
consumptions or other new scenarios.
This knowledge will allow the water distributor to define a strategy to implement possible changes in the network
that leads to its improvement.
This scenario can be described by the following steps:
Deliverable D4.1 – Decision supporting tools system requirements
71
URBAN-WATER PUBLIC
Grant Agreement: 318602
The water distributor analyzes future scenarios of the network and assesses the benefits that a particular
change introduces;
The water distributor defines a strategic plan and informs the SDSS that new information is available.
6.4.1.2 The water supply system topology has changed
Although the change of the water supply system is a scenario of the SDSS, this section presents its particular
application to the distribution network.
The reduction of water losses is directly related to the reduction of pressure in the network. The pressure
management is a constant concern of the water distributor, and sometimes the re-definition of a DMA is crucial to
improve the reduction of water losses and the performance of the network. In the next paragraph this scenario is
presented in more detail.
The water distributor intends to change DMA boundaries so that he can reduce pressure in a certain part of the
network. He informs the water manager that it will be necessary to adjust the water stored in certain tanks and the
operating point of a pump station.
This scenario can be described by the following steps:
The water distributor informs the water manager that a change in the water distribution network will be
necessary;
The water manager analyzes the influence in the water supply system due to the distribution network
changes;
The water distributor implements changes in the distribution network;
The water manager implements new SDSS elements (if needed);
The water manager defines new rules or updates existing rules that should be corrected considering the
new strategy;
The SDSS operates over the new model.
6.4.1.3 Normal operation of the water supply system (Extreme events)
Like the previous scenario this section presents a particular application of a scenario of the SDSS to the distribution
network.
The legal authority decrees a state of drought in a certain region. A campaign is launched near the population in
order to save water and to inform about partial restrictions during the day. The water distributor informs the water
manager about the impact of the campaign (consumptions and leaks reduction).
This scenario can be described by the following steps:
The legal authority activates an exceptional situation;
The water manager implements rules due to the exceptional situation and the water distributor is informed;
The water distributor notifies the SDSS that new information is available (new consumptions and leakage
behaviours).
Deliverable D4.1 – Decision supporting tools system requirements
72
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.4.2 Use cases
6.4.2.1 Check raw data quality, perform correction and validation
Identifier UC-LDS-ValidateData
Goal Validation of flow/pressure data series quality
Preconditions Availability of network flow/pressure data
Flow of events 1. Water distributor wants to validate a data series OR external service is
requiring validated data
2. LDS performs data analysis and correction routine
3. LDS displays validated data series OR exports validated data series
Post conditions Validated data series available and sent to the service that required them
Trigger Every time new data is available OR
Periodical routine OR
Request from another module
Priority Mandatory
Actors LDS
Goodwter’s water distributor
UW platform
6.4.2.2 Evaluate past leakage level with Mass Balance
Identifier UC-LDS-ComputeMassBalance
Goal Compute and display system Mass Balance (MB) to evaluate real losses or other MB
variable
Preconditions Correctly defined network and DMA’s
Boundary conditions (e.g. input flow)
Availability of network flow data
Consumption pattern characterization
Flow of events 1. Water distributor sets time-frame for the analysis
2. Water distributor selects the area to analyse
3. The LDS module acquires validated network flow data from UW platform
4. Water distributor checks and adjusts different MB parameters
5. The LDS computes and displays MB results
Post conditions MB results are available
Trigger Periodical based on a predefined schedule OR
Water distributor decision (on demand)
Priority Optional
Actors LDS
Goodwater’s water distributor
UW platform
Deliverable D4.1 – Decision supporting tools system requirements
73
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.4.2.3 Evaluate past leakage level with Minimum Night Flow Analysis
Identifier UC-LDS-ComputeMinimumNightFlow
Goal Compute and display Minimum Night Flow analysis (NFA) to evaluate real-losses
Preconditions Correctly defined network and DMA’s
Boundary conditions (e.g. input flow)
Availability of validated network flow data
Availability of validated network pressure data
Nightline characterization (night consumption)
Flow of events 1. Water distributor sets time-frame for the analysis
2. The NFA module acquires validated network flow data from UW platform
3. Water distributor checks and adjusts NFA module parameters
4. The LDS computes loss volume and displays NFA analysis results
Post conditions NFA analysis results available
Trigger Periodical based on a predefined schedule OR
Water distributor decision (on demand)
Priority Optional
Actors LDS
Goodwater’s water distributor
UW platform
Cloud database
6.4.2.4 Set up Hydraulic Model for leakage analysis
Identifier UC-LDS-SetupHydraulicModel
Goal Build a network input data file to run Hydraulic Model
Preconditions Availability of network topology
Availability of terrain elevation
Availability of network pressure data (optional)
Consumption pattern characterization
Leakage flow estimate
Flow of events 1. HMB acquires necessary data from local data source
2. HMB acquires consumption data from the cloud database
3. Water distributor enters additional external data in the HMB to complete input
information
4. Water distributor validates aggregated input information and the HMB
produces input file
Post conditions Input data file created for leakage event analysis and scenarios evaluation.
Trigger Water distributor decision
Priority Optional
Actors LDS
Goodwater’s water distributor
UW platform
Cloud database
Deliverable D4.1 – Decision supporting tools system requirements
74
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.4.2.5 Monitor leakage in near real-time
Identifier UC-LDS-MonitorLeakages
Goal Graphical analysis of NFA or/and MB (only with AMR data available, in this case)
Preconditions Availability of network flow data
Availability of estimated nightline (night consumption)
Availability of AMR consumption data (optional)
Flow of events 1. Water distributor starts LDS in real-time data acquisition mode
2. Water distributor analyses NFA display or/and MB display/results
3. Water distributor annotates suspected leakage events
Post conditions None
Trigger Periodical routine OR
Water distributor decision
Priority Optional
Actors LDS
Goodwater’s water distributor
UW platform
6.4.2.6 Set up automated monitoring and alerts
Identifier UC-LDS-SetupMonitoringAlerts
Goal Definition of alert thresholds to automatically detect suspected leakage events based
on near real-time monitoring
Preconditions Availability of network flow data
Availability of estimated nightline (night consumption)
Availability of AMR consumption data (optional)
Flow of events 1. Water distributor defines threshold values for nightline intersection (NFA) and
balance check (MB) in the LDS
2. Water distributor defines which alerts should be notified to UW platform
Post conditions New alert notification rule is configured
Trigger Water distributor decision
Priority Optional
Actors LDS
Goodwater’s water distributor
UW platform
Deliverable D4.1 – Decision supporting tools system requirements
75
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.4.2.7 Perform network leakage simulation (prospective)
Identifier UC-LDS-PerformSimulation
Goal Analyse different scenarios to estimate impact on leakage (e.g. different network
pressure)
Preconditions Availability of network topology
Availability of forecast flow data (from Water Demand Prediction)
Availability of network pressure data (optional)
Consumption pattern characterization
Flow of events 1. Water distributor defines scenarios to be tested
2. Water distributor adjusts LDS parameter accordingly
3. Water distributor performs simulation analysis with Hydraulic Model
Post conditions None
Trigger WD decision
Priority Optional
Actors LDS
Goodwater’s water distributor
UW platform (WDPS)
Cloud database
6.4.3 Requirements
6.4.3.1 Retrieve flow data
Requirement# REQ-LDS-1 Priority Mandatory
Requirement The LDS must be able to acquire flow data from the cloud database through the
UW platform
Component LDS
UW platform
Cloud database
Use Cases All use cases
Remark -
6.4.3.2 Retrieve pressure data
Requirement# REQ-LDS-2 Priority Mandatory
Requirement The LDS must be able to acquire pressure data from the cloud database through
UW platform’s services
Component LDS
UW platform
Cloud database
Use Cases All use cases
Remark -
6.4.3.3 Retrieve topology data
Requirement# REQ-LDS-3 Priority Mandatory
Deliverable D4.1 – Decision supporting tools system requirements
76
URBAN-WATER PUBLIC
Grant Agreement: 318602
Requirement The LDS must be able to acquire topology (or node correspondence) data from the
cloud database through UW platform’s services
Component LDS
UW platform
Cloud database
Use Cases UC-LDS-
SetupHydraulicModel
UC-LDS-
PerformSimulation
Remark -
6.4.3.4 Retrieve terrain elevation data
Requirement# REQ-LDS-4 Priority Mandatory
Requirement The LDS must be able to acquire terrain elevation data from the cloud database
through UW platform’s services or from NASA’s HGT global data set
Component LDS
UW platform
Cloud database
Use Cases UC-LDS-
SetupHydraulicModel
UC-LDS-
PerformSimulation
Remark -
6.4.3.5 Retrieve water demand prediction data
Requirement# REQ-LDS-7 Priority Mandatory
Requirement The LDS must be able to acquire water demand prediction data from the cloud
database through UW platform’s services.
Component LDS
UW platform
Cloud database
Use Cases UC-LDS-
PerformSimulation
Remark -
6.4.3.6 Provide data series (flow/pressure) validation
Requirement# REQ-LDS-8 Priority Mandatory
Requirement The LDS must be able to validate flow and pressure data series and provide it to
the UW platform to make it available to the service that required it.
Component LDS
UW platform
Cloud database
Use Cases All use cases
Remark -
6.4.3.7 Calculate and provide leakage with Mass Balance
Requirement# REQ-LDS-9 Priority Mandatory
Requirement The LDS must be able to calculate and provide the mass balance of the system,
per DMA, to evaluate real losses or other MB variables.
Deliverable D4.1 – Decision supporting tools system requirements
77
URBAN-WATER PUBLIC
Grant Agreement: 318602
Component LDS (MB)
UW platform
Use Cases UC-LDS-
ComputeMassBalance
UC-LDS-
MonitorLeakages
Remark This module has the possibility of calculation of performance indicators
6.4.3.8 Calculate and provide leakage with Minimum Night Flow Analysis
Requirement# REQ-LDS-10 Priority Mandatory
Requirement The LDS must be able to compute and provide minimum night flow analysis to
evaluate real losses.
Component LDS (NFA)
UW platform
Use Cases UC-LDS-
ComputeMinimumNightFlow
UC-LDS-MonitorLeakages
Remark -
6.4.3.9 Build and provide a Hydraulic Model of the network
Requirement# REQ-LDS-11 Priority Mandatory
Requirement The LDS must be able to build a network input data file to run hydraulic models.
Component LDS (HMB)
UW platform
Use Cases UC-LDS-
SetupHydraulicModel
UC-LDS-
PerformSimulation
Remark The input data file will be defined in accordance with Epanet Software.
6.4.3.10 Display Mass Balance information
Requirement# REQ-LDS-15 Priority Mandatory
Requirement The LDS must be able to display all information of the mass balance and send
notification to UW platform that new mass balance is available.
Component LDS (MB) Use Cases UC-LDS-
ComputeMassBalance
UC-LDS-
MonitorLeakages
Remark -
6.4.3.11 Display Minimum Night Flow analysis
Requirement# REQ-LDS-16 Priority Mandatory
Requirement The LDS must be able to display all information of the minimum night flow analysis
and send a notification to the UW platform that a new analysis is available.
Deliverable D4.1 – Decision supporting tools system requirements
78
URBAN-WATER PUBLIC
Grant Agreement: 318602
Component LDS (NFA) Use Cases UC-LDS-
ComputeMinimumNightFlow
UC-LDS-MonitorLeakages
Remark -
6.4.3.12 Display a Hydraulic Model of the network
Requirement# REQ-LDS-17 Priority Expected
Requirement The LDS should display a hydraulic model of the water distribution network.
Component LDS (HMB) Use Cases UC-LDS-
SetupHydraulicModel
UC-LDS-PerformSimulation
Remark Epanet software must be available.
6.4.3.13 Send a notification
Requirement# REQ-LDS-18 Priority Mandatory
Requirement The LDS must be able to send notifications to the UW platform to let it know that
new information is available.
Component LDS
UW platform
UW notifications service
Use Cases All use cases
Remark -
6.4.3.14 Send an alert
Requirement# REQ-LDS-19 Priority Optional
Requirement The LDS should be able to send an alert to UW platform to let it know that a potential
leak event was detected.
Component LDS
UW platform
UW alerts service
Use Cases UC-LDS-
SetupMonitoringAlerts
Remark -
Deliverable D4.1 – Decision supporting tools system requirements
79
URBAN-WATER PUBLIC
Grant Agreement: 318602
7 Conclusion and Outlook
This document provides the requirements of the Spatial Decision Support System and the Decision Supporting
Tools to be developed in the UrbanWater project within Work package 4. A detailed description of water utilities,
which kind of elements they typically operate and which information they use to process and make decisions has
been provided.
Five main modules have been identified and described in detail, i.e.:
1. Spatial Decision Support System as the tool to combine information from other modules and water utilities
data in order to propose to water utilities some management actions under certain situations;
2. Water demand prediction system that predicts future demand at certain points of a water distribution
network;
3. Detailed indoor consumption model that interprets water meter consumption with respect to individual
usages of each device in the household (shower, watering gardens, wash machine, etc.);
4. Water availability prediction that predicts future water volumes on each reservoir;
5. Leakage detection system that calculates the amount of current leakage in a water distribution network.
The partners responsible of each tasks of WP4 (HYDS, AQUA, UNIZG-FER) have jointly contributed to this
deliverable D4.1 with the description, scenarios, use cases and requirements of each of their modules. Moreover,
AQ and Tave (with the help of AdA, AdP and APA) as partners of the projectprovided information regarding how
they operate the validation sites to understand how the UrbanWater project could help them and which
requirements the presented modules should accomplish.
Following the tasks done in this deliverable, deliverable D4.2 “Decision Supporting Tools design” will describe the
design of each of the modules. For each of them, a sequence diagram of each use case will show the interactions
with other UrbanWater modules. In addition, a user interface design will be supplied where necessary to facilitate
its understanding. Finally, a state of the art of spatial decision support systems will be included.
Deliverable D4.1 – Decision supporting tools system requirements
80
URBAN-WATER PUBLIC
Grant Agreement: 318602
8 Annex I: Requirements collection methodology
The aim of this section is to provide information about the requirement collection process for developing the
requirements in deliverable D4.1. That process has combined the following sources of information:
A survey addressed to the water utilities of the project in order to compile first level information about
several aspects, such as the actors/roles in their context, management processes in general and of the
elements of the water supply system.
Several meetings with the stakeholders of the project with the aim to clarify and collect specific
requirements and documentation to complete the requirements.
Collection of information from similar systems, usually accessible from scientific or applied publications.
Specialized scientific publications presenting methodologies devoted to address specific needs of the
project.
The following information summarizes the main blocks of related information used to define the scenarios, use
cases and requirements for the five modules of WP4 (SDSS, WDPS, DICM, WAPS, LDS). The following sections
compile the acquired information regarding meetings, the surveys and other not confidential information
documentation provided by the stakeholders to develop the scenarios, use cases and requirements, and which
sections of the deliverable were prepared using this information. It is important to remark that the presented
documentation intends to provide a global overview of the used sources, not a specific link between each
requirement and related information.
8.1 SDSS requirements
This section describes how DSS requirements have been derived. The requirements are categorized into several
types, and a table for each type is provided describing which information has been used and which sections were
produced based on this information.
Type of requirements Current stakeholders context: administrative, management, operation, existing
elements, etc.
Used information
INPUT:
Stakeholders’ survey. Aspects related to:
o Information/description about the stakeholders/roles involved in the supply chain and
responsibilities
o Information about how the general water management process is organized
o Description of the water supply system and information about the management of each of the
elements
Meetings
o 2013/07/09 – SW
Specific information about operation of SW water supply system
Description of common elements and integration
Decisions depending on scenarios
o 2013/07/22 – Tave
Description of water system and elements and how they are operated
Deliverable D4.1 – Decision supporting tools system requirements
81
URBAN-WATER PUBLIC
Grant Agreement: 318602
Description of defined scenarios and related conditions
Management strategies based on scenarios or current conditions
o 2014/02/11 – SW
Very detailed information about demo sites related to water sources, allocations
management, distribution elements, suppliers management, etc.
o 2014/03/18 – Tave
Very detailed information about demo sites related to water sources, allocations
management, distribution elements, suppliers management, etc.
Stakeholders’ additional provided documentation:
o SW:
Water Resource Plan draft
Basic WRZ description
Presentation about Loch Katrine system plan operation
Loch Katrine system operational rules
o Tave:
Contingency plan for Barlovento and Sotavento regions
Distribution network topology, meters location and areas
Contributive basins of the Algarve reservoirs
General description of the water distribution network contained in an EPANET
hydraulic model
Existing public information from web sites:
o SW:
SW home page (http://www.scottishwater.co.uk/)
Water Industry Commission for Scotland home page
(http://www.watercommission.co.uk/)
Scottish Environment Protection Agency (SEPA) (http://www.sepa.org.uk/)
Center for Ecology&Hydrology home page
(http://www.ceh.ac.uk/sites/wallingford.html)
MetOffice home page (http://www.metoffice.gov.uk/)
o Tave:
Tavira Verde home page (http://www.taviraverde.pt/)
Aguas do Algarve home page (http://www.aguasdoalgarve.pt)
Aguas de Portugal home page (http://www.adp.pt/)
Agencia Portugesa do Ambiente home page (http://www.apambiente.pt/)
Sistema Nacional de Informaçao de Recursos Hidricos home page (http://snirh.pt)
Research and other published material:
o General description of water supply systems and management:
Water Resources Systems Planning and Management: An Introduction to Methods,
Models and Applications by Daniel P. Loucks and Eelco van Beek with contributions
from Jery R. Stedinger, Jozef P.M. Dijkman, Monique T. Villars - part of Studies and
Reports in Hydrology from UNESCO PUBLISHING, 2005.
Development of Decision Support Frameworks for Water Resource Management in
the South East by Gibbs, MS, Maier, HR and Dandy GC. Goyder Institute for Water
Research Technical Report Series No. 12/3, 2012.
Deliverable D4.1 – Decision supporting tools system requirements
82
URBAN-WATER PUBLIC
Grant Agreement: 318602
The role of decision support systems and models in integrated river basin
management, Global Water Partnership, 2013.
Urban Water Cycle Processes and Interactions: Urban Water Series - UNESCO-IHP.
By Jiri Marsalek, Blanca Jimenez Cisneros, Mohammad Karamouz, Per-Arne
Malmquist, Joel Avruch Goldenfum, Bernard Chocat, CRC Press, Jan 7, 2008.
"water supply system." Encyclopaedia Britannica. Encyclopaedia Britannica Online.
Encyclopædia Britannica Inc., 2013.
Integrated Water Resources Management in Practice: Better Water Management for
Development by R. L. Lenton, Mike Muller. Earthscan, 2009.
Decision support systems for large dam planning and operation in Africa, by
McCartney, M. P. Colombo, Sri Lanka: International Water Management Institute. 47
p. (IWMI Working Paper 119), 2007.
o Specific documentation providing information about management activities in water supply
elements:
Decision Support Systems For Integrated Water Resources Management With An
Application To The Nile Basin, by Georgakakos, A. P. Atlanta, Georgia, USA: Georgia
Water Resources Institute, 2004.
Decision Support System for Adaptive Water Supply Management by Westphal, K.,
Vogel, R., Kirshen, P., and Chapra, S. J. Water Resour. Plann. Manage., 129(3), 165–
177, 2003.
Application to the Development of Water Management Strategies in Ribeiras do
Algarve River Basin, by Rodrigo Maia, Andreas H. Schumann. Water Resources
Management, Volume 21, Number 5, Page 897, 2007.
The Application of a Real-Time Operational Water Resources Decision Support
System (DSS) for the Orange-Fish-Sundays Water Transfer Scheme, by Greaves KR,
JS Hallowes, PG Retief, JM Viljoen, EA Pashkin. DHI – internal report, 2010.
Analysis of existing previously developed solutions that cover certain aspects of
interest for UrbanWater: MIKE BASIN from the Danish Hydraulic Institute (DHI),
BASINS, developed by the U.S.- Environmental Protection Agency, AQUATOOL –
developed by the Universidad Politécnica de Valencia, The Integrated Quality and
Quantity Model (IQQM) developed by the New South Wales Department of Land &
Water Conservation, Ribasim, developed by Delft Hydraulics, WATERWARE
developed in the framework of the EU program Eureka-EU487.
OUTPUT:
The previous information has been used to complete the following sections of D4.1:
2.1 Generic description of water supply elements and management activities
3 Approach of the UrbanWater SDSS
4 Roles and actors
Type of requirements Functional requirements (general requirements of the SDSS module)
Used information
INPUT:
Meetings:
o 2013/07/09 – SW
Deliverable D4.1 – Decision supporting tools system requirements
83
URBAN-WATER PUBLIC
Grant Agreement: 318602
Routines of operation of the water supply system in normal conditions (i.e. with
different climatic scenarios but with the same topology of elements)
Process of modification of the system based on long-term planning activities or other
causes. Process of definition/modification of the management strategy based on new
studies, information, rules, etc.
Tools/information used to describe or define the system or its elements (SCADA, GIS,
etc.)
o 2013/07/22 – Tave
Routines of operation of the water supply system in normal conditions (i.e. with
different climatic scenarios but with the same topology of elements)
Process of modification of the system based on long term planning activities or other
causes. Process of definition/modification of the management strategy based in new
studies, information, rules, etc.
Tools/information used to describe or define the system or its elements (SCADA, GIS,
etc.)
Stakeholders used additional documentation:
o SW:
Basic WRZ description
Presentation about Loch Katrine system plan operation
Loch Katrine system operational rules
o Tave:
Contingency plan for Barlovento and Sotavento regions
Distribution network topology, meters location and areas
General description of the water distribution network contained in an EPANET
hydraulic model
Information from similar operational systems (in particular analysing how operation routines and system
modifications are translated to requirements and specific options in developed tools):
o BASINS, developed by the U.S.- Environmental Protection Agency, specifically for
requirements related to establishing and modifying system topology.
o AQUATOOL – developed by the Universidad Politécnica de Valencia, specifically for the
modular approach and data and display solutions and scenario management.
o The Integrated Quality and Quantity Model (IQQM) developed by the New South Wales
Department of Land & Water Conservation
o Ribasim, developed by Delft Hydraulics, requirements related to simulation of scenarios and
display.
o WEAP (Water Evaluation And Planning System), developed by the Stockholm Environment
Institute's Boston Center at the Tellus Institute, USA, definition of topology and related display.
o WATERWARE developed in the framework of the EU program Eureka-EU487, several models
integration and definition of platform modules.
OUTPUT:
That information has been used to complete the following sections in deliverable D4.1:
5.1 SDSS Scenarios
5.2 SDSS Use cases
5.3 SDSS Requirements
Deliverable D4.1 – Decision supporting tools system requirements
84
URBAN-WATER PUBLIC
Grant Agreement: 318602
Type of requirements Inference engine requirements (specific requirements of the inference engine)
Used information
INPUT:
Meetings (to decide whether rule-based inference engine operational rules fit with the requirements)
o 2013/07/09 – SW
Routines of operation of the elements of the water supply system
Examples rules/protocols related to the operation of the whole system and in particular
for the operation of the reservoirs.
Discussion about control curves in reservoirs (criteria for their development and current
use).
o 2013/07/22 - Tave
Description of the distribution network and rules/protocols applied for their operation.
Example of contingency plans used in the different water regions in the area
Discussion about hydraulic rules incorporated in the EPANET model used for the
distribution of water
Stakeholders provided additional documentation:
o SW:
Water Resource Plan draft: This document includes the following information:
Water resource zones (description, distribution, rationalization)
Level of service
Water available for use
Components of demand and demand forecast
Supply demand balance methodology
Zonal prioritization
Action plan
Examples of the control curves used to operate Pateshill reservoir and Loch Katrine
o Tave:
Contingency plan for Barlovento and Sotavento regions
EPANET model with hydraulic rules incorporated
Distribution network topology, meters location and areas
Research and other published material:
o Decentralising The Codification Of Rules In A Decision Support Expert Knowledge Base, by De
Kock, E. South Africa: University of Pretoria, 2003.
o An expert system approach for water management in case of drought, Intelligent Information
Systems, by Chang T.J.; Moore, D. IIS ’97. Proceedings, vol., no., pp. 332,339.1997
o An experimental expert system for management of water distribution networks, by Sandeep
Kulshrestha and Rakesh Khosa. International Journal of Engineering Science and Technology
Vol. 2 (12), 7401-7412. 2010.
o EXPLORE - Hybrid expert system for water networks management, by Leon C., S. Martín, J.
Elena, and J. Luque. Journal of Water Resources Planning and Management, 126(2):65–74,
2000.
o Water-supply system operations: Critiquing expert-system approach, by Shepherd, A. and
Ortolano. Journal of Water Resources Planning and Management, 122(5), 348–355. 1996.
Deliverable D4.1 – Decision supporting tools system requirements
85
URBAN-WATER PUBLIC
Grant Agreement: 318602
o A Comparative Study Of Inference Engines, by Singh, S., & Karwayun, R. International
Conference on Information Technology, (pp. 53-57). 2010.
Existing public information from web pages
o Discussion about inference engine use: http://www.jbug.jp/trans/jboss-
rules3.0.2/ja/html/ch01s02.html
o Jess inference engine official site: http://herzberg.ca.sandia.gov/
o Drools inference engine official site: http://www.jboss.org/drools
o Openrules inference engine official site: http://openrules.com
OUTPUT:
That information has been used to complete the following sections in deliverable D4.1:
5.2 Computation and status-related use cases.
5.3 Computation and status-related requirements.
Type of requirements Demo site requirements (operational rules)
Used information
INPUT:
Meetings
o 2013/07/09 – SW
o 2013/07/22 – Tave
o 2014/02/11 – SW
o 2014/03/18 – Tave
o 2014/06/06 – ASC
o Compilation of operational rules from the several meetings with SW and Tave. In particular the
following provided documentation has been used:
SW Water Resource Plan draft
SW Excel file example of daily procedures to operate the WRZ
SW description of the methodology used to define the WRZ operational rules
Tave contingency plan for the Barlovento and Sotavento regions. Specifically
information on the logical model schema where water flows supplied from WTP and
groundwater to the different municipalities are specified.
Tave EPANET model
Compilation of information from stakeholders regarding integration of the different
management processes into a general framework.
OUTPUT:
That information has been used to complete the following sections in deliverable D4.1:
5.1 SDSS Scenarios
5.2 SDSS Use cases
5.3 SDSS Requirements
Type of requirements General design (database, user interface, services, integration)
Used information
INPUT:
Deliverable D4.1 – Decision supporting tools system requirements
86
URBAN-WATER PUBLIC
Grant Agreement: 318602
Meetings
o 2013/07/09 – SW
Information from water supply system elements (reservoirs, water tanks, water
treatment plants, others), data available and storage, frontend elements,
display/SCADA capabilities, etc.
o 2013/07/22 – Tave
Information from water supply system elements (reservoirs, water tanks, water
treatment plants, others), data available and storage, frontend elements,
display/SCADA capabilities, etc.
o 2013/12/13 - ASC
UW proposed platform, user interface and service bus description.
o 2014/02/11 – SW
Additional information about specific tools and interfaces used to monitor the water
supply system and elements.
Additional information about key data used as reference for the monitoring and
decision process and sources providing that data.
o 2014/03/18 – Tave
Additional information about specific tools and interfaces used to monitor the water
supply system and elements.
Additional information about key data used as reference for the monitoring and
decision process and sources providing that data.
OUTPUT:
That information has been used to complete the following sections in deliverable D4.1:
5.2 SDSS Display use cases
0 SDSS Display requirements
8.2 WDPS requirements
Type of requirements Technical requirements for WDPS
Used information
INPUT:
UrbanWater material:
o UrbanWater survey in provided responses from water utilities and water authorities
o Consortium meetings where connection between different modules concerning individual
modules needs were discussed, e.g. SDSS-WDPS, LDS-WDPS
o Written discussion via the UrbanWater management platform concerning availability of different
data sources from utilities for different modules developed by UNIZG-FER, and from all partners
concerning their inputs and connections with the modules they develop (Data needs for
identification of water demand & detailed indoor consumption)
External meetings with stakeholders:
o Meeting with stakeholders for widening the approach regarding demand prediction on rural
water distribution and management, especially in view of its use for dynamic water pricing
Deliverable D4.1 – Decision supporting tools system requirements
87
URBAN-WATER PUBLIC
Grant Agreement: 318602
(Bruxelles 16-17/01/2013; Wallingford 11-12/03/2013): Vodni zdroje (CZ), Bioforsk (NO), HR
Wallingford (UK)
Scientific literature (listed in D4.3 and D4.5):
o M. Bakker, J. H. G. Vreeburg, L. J. Palmen, V. Sperber, G. Bakker, and L. C. Rietvald, “Better
water quality and higher energy efficiency by using model predictive flow control at water supply
systems,” Journal of Water Supply: Research and Technology – AQUA, vol. 62, no. 1, pp. 1 –
13, 2013.
o M. Ghiassi, D. K. Zimbra, and H. Saidane, “Urban water demand forecasting with a dynamic
artificial neural network model,” Journal of Water Resources Planning and Management, vol.
134, no. 2, pp. 138–146, 2008.
o T. Yalcinoz and U. Eminoglu, “Short Term and Medium Term Power Distribution Load
Forecasting by Neural Networks,” Energy Conversion and Management, vol. 46, pp. 1393–
1405, June 2005.
o Jain, A. Kumar Varshney, and U. Chandra Joshi, “Short-term water demand forecast modelling
at iit kanpur using artificial neural networks,” Water Resources Management, vol. 15, no. 5, pp.
299–321, 2001.
o F. Arbues, M. A. Garcia-Valinas, and R. Martinez-Espineira, “Estimation of residential water
demand: a state-of-the-art review,” The Journal of Socio-Economics, vol. 32, no. 1, pp. 81 –
102, 2003.
o H. R. Maier and G. C. Dandy, “Neural networks for the prediction and forecasting of water
resources variables: a review of modelling issues and applications,” Environmental Modelling &
Software, vol. 15, no. 1, pp. 101 – 124, 2000.
o H. R. Maier, A. Jain, G. C. Dandy, and K. Sudheer, “Methods used for the development of neural
networks for the prediction of water resource variables in river systems: Current status and
future directions,” Environmental Modelling & Software, vol. 25, no. 8, pp. 891 – 909, 2010.
o Sharma, “Seasonal to interannual rainfall probabilistic forecasts for improved water supply
management: Part 1 — a strategy for system predictor identification,” Journal of Hydrology, vol.
239, no. 1–4, pp. 232 – 239, 2000.
o H. Cigizoglu and O. Kisi, “Flow prediction by three back propagation techniques using k-fold
partitioning of neural network training data”, Nordic Hydrology, vol. 36, no. 1, pp. 49–64, 2005.
OUTPUT:
6.1.1 WDPS scenarios
6.1.2 WDPS use cases
0 WDPS requirements
8.3 DICM requirements
Type of requirements Technical requirements for DICM
Used information
INPUT:
UrbanWater material:
o UrbanWater survey in provided responses from consumers and water utilities
o Consortium meetings where connections between different modules were discussed, e.g.
DICM-Serious games
Deliverable D4.1 – Decision supporting tools system requirements
88
URBAN-WATER PUBLIC
Grant Agreement: 318602
o Written discussion via the UrbanWater management platform concerning availability of different
data sources from utilities for different modules developed by UNIZG-FER, and from all partners
concerning their inputs and connections with the modules they develop (Data needs for
identification of water demand & detailed indoor consumption)
External meetings with stakeholders:
o Meeting with stakeholders for discussing opportunities of improving interaction between water
utilities and consumers (Barcelona 22/03/2013): Cetaqua (ES), Aqualogy solutions (ES),
Zapcarbon (UK), EXASOL Europa Vetriebs (DE), CRIC (ES), ASW Inzenjering d.o.o. (RS), SGI
(DK), Águas da Região de Aveiro (PT), Empresa Municipal Mixta d’Aigües de Tarragona (ES)
o E-mail discussion on data needs regarding detailed indoor consumption assessment with Water
Research Centre (UK), resulting in provision of data for initial tuning of the DICM
On-line resources:
o Web page of the Water Research Centre (UK): http://www.wrcplc.co.uk/
o Documentation on the Identiflow product of the Water Research Centre:
http://wrcplc.co.uk/Data/Sites/1/GalleryImages/WebImages/pdfs/identiflowflyer08.pdf
o Scientific literature (a broader set of references will be available in D4.8):
o AWWA: Residential End Uses of Water, AWWA Research Foundation and American Water
Works Association, Denver, 1999.
o Y. Otaki, M. Otaki, P. Pengchai, Y. Ohta, and T. Aramaki: Micro-components survey of
residential indoor water consumption in Chiang Mai, Drink. Water Eng. Sci., 1, 17–25, 2008
OUTPUT:
6.2.1 DICM scenarios
6.2.2 DICM use cases
6.2.3 DICM requirements
8.4 LDS requirements
Type of requirements Technical requirements for LDS
Used information
INPUT:
UrbanWater material:
o UrbanWater survey in provided responses from consumers and water utilities
o Consortium meetings
Meetings:
o Meetings with the Portuguese National Laboratory of Civil Engineering. Two meetings were held
with the technicians of the Sanitary Engineering Sector of the Hydraulic and Environmental
Department of the Portuguese National Laboratory of Civil Engineering. The main goals of these
meetings were to obtain information regarding current and expected procedures for control of
water losses, nationally and internationally. These meetings took place on 19/04/2013 and
02/05/2013.
o Meetings with consortium’s water utilities (Scottish Water and Tavira Verde) to obtain
information about the methods and methodologies used in the control of water losses in their
distribution networks (office and field work and its relationships) and data available.
Deliverable D4.1 – Decision supporting tools system requirements
89
URBAN-WATER PUBLIC
Grant Agreement: 318602
o Meetings with utilities to share experiences and gather information about the implemented
methodologies on leakage detection and available data to apply those methodologies; several
meetings were held (in parallel with other projects meetings) and are still being held (AQUA is
participating in a joint training and capacitation approach through which water utilities develop
their own water-energy losses programme).
On-line resources:
o Leys, C., Klein, O., Bernard, P., & Licata, L. (2013). Detecting outliers: Do not use standard
deviation around the mean, use absolute deviation around the median. Journal of
Experimental Social Psychology , 49(4), 764–766.
o Mamade, Aisha Zulquifal. “Profiling Consumption Patterns using Extensive Measurements: A
spatial and temporal forecasting approach for water distribution systems.” Master's thesis,
Técnico Lisboa, 2013.
o NIST (National Institute of Standards Technology Information Technology Laboratory). (n.d.).
Detection of Outliers: Exploratory Data Analysis - Quantitative Techniques. URL:
http://www.nist.gov/itl/, Accessed: 2013-11-25.
o Seo, S. (2006). A review and comparison of methods for detecting outliers in univariate data
sets. Master's thesis, University of Pittsburgh.
o Thornton J., Sturm R., Kunkel G., Mc Graw Hill (2008). Water Loss Control, Second edition.
o Alegre, H., Coelho, S. T., Almeida, M., Vieira, P. (2005). Guia Técnico 3: Controlo de perdas
de água em sistemas públicos de adução e distribuição. Instituto Regulador de Águas e
Resíduos (IRAR), Instituto da Água (INAG) e Laboratório Nacional de Engenharia Civil
(LNEC), Lisboa.
o IWA (October 2000). Losses from Water Supply Systems: Standard Terminology and
Recommended Performance Measures.
o Choi T., Koizumi A., Koo J. Analysis of customer night use and night flow losses using
minimum night flow analysis.
o Cheung P. B., Girol G. V., Abe N., Propato M. Night flow analysis and modeling for leakage
estimation in a water distribution system.
o Gomes, R.J. Modelação matemática como ferramenta de gestão e exploração de sistemas de
distribuição de água. Tese de Doutoramento, Universidade de Coimbra, 2011
Feature analysis of some commercial systems for leakage detection, like:
o Monitor developed by Addition, Lda.
o Wone – water optimization for network efficiency developed by EPAL, S.A.
o WaterNet developed by RPS Group Plc.
o Netbase developed by Crowder Consulting Ltd
Compilation and systemization of the information collected.
OUTPUT:
6.4.1 LDS scenarios
6.4.2 LDS use cases
6.4.3 LDS requirements
After analyzing the referred information, considerable differences were detected on data available in each utility
and the way of obtain it. The methodologies used to prevent losses can be more or less accurate depending on the
available data and its accuracy.
Deliverable D4.1 – Decision supporting tools system requirements
90
URBAN-WATER PUBLIC
Grant Agreement: 318602
Given the project objective of evaluating the advantages of smart metering, the system will be designed to work
with the best available data (like AMR flows), but shall also allow the use of data with less quality and quantity, to
appeal to a broader range of utilities.
The described approach has contributed to the definition of the LDS scenarios, use cases and requirements.
8.5 WAPS requirements
Type of requirements General context and state of the art
Used information
INPUT:
Meetings
o 2013/07/09 – SW
Specific information about reservoirs management
Decisions depending on reservoir status
o 2014/02/11 – SW
Detailed information about information available when operating the reservoirs (data
from reservoirs and external data: meteorological forecasts and others.)
o 2014/03/18 – Tave
Very detailed information regarding how reservoirs are operated, water allocations,
available data, etc.
Stakeholders additional provided documentation:
o SW:
Water Resource Plan Draft
Loch Katrine system operational rules
o Tavira Verde:
Contributive basins
Distribution network topology
Existing public information from web pages:
o SW:
SW home page (http://www.scottishwater.co.uk/)
Scottish Environment Protection Agency (SEPA) (http://www.sepa.org.uk/)
o Tavira Verde:
Tavira Verde home page (http://www.taviraverde.pt/)
Sistema Nacional de Informaçao de Recursos Hidricos home page (http://snirh.pt)
Research and other published material:
o General description of water supply systems and management, needs for a water availability
forecasting:
Daniel P. Loucks, Eelco van Beek, Jery R. Stedinger, Jozef P.M. Dijkman, Monique T.
Villars. (2005). Water Resources Systems Planning and Management: An Introduction
to Methods, Models and Applications.. Studies and Reports in Hydrology from
UNESCO Publishing.
Lenton R. L., Mike Muller. Earthscan. (2009). Integrated Water Resources
Management in Practice: Better Water Management for Development.
Deliverable D4.1 – Decision supporting tools system requirements
91
URBAN-WATER PUBLIC
Grant Agreement: 318602
Water Services Management and Governance. Tapio Katko, Petri S. Juuti, and Klaas
Schwartz. 2012. IWA Publishing.
Information from similar operational systems:
o Confederación hidrográfica del Ebro: http://www.chebro.es/
o Confederación hidrográfica del Tajo: http://www.chtajo.es/
o Confederación hidrográfica del Duero: http://www.chduero.es/
o Agència catalane de l’aigua: http://aca-web.gencat.cat/aca/appmanager/aca/aca
OUTPUT:
The previous information has been used to complete the following sections of D4.1:
6.3.1 WAPS scenarios
6.3.2 WAPS use cases
0 WAPS requirements
Type of requirements Functional requirements (general requirements of the WAPS module)
Used information
INPUT:
Meetings
o 2013/07/09 – SW
List of available data and how they use them
o 2014/02/11 – SW
Detailed list of available data and how they use them
Examples of auxiliary files used by SW to operate the reservoirs
Explanation about how they predict future water available
o 2014/03/18 – Tave
List of available data used to operate the reservoirs
Explanation about how they use and display the information
Research and other published material:
o Delrieu G., I. Braud, A. Berne, M. Borga, B. Boudevillain (2009). Weather radar and hydrology.
Advances in Water Resources, 32, 969–974.
o Hydrologic Engineering Center (1990). HEC-1. Flood Hydrograph package User's manual.
Hydrologic Engineering Center, Davis, CA (USA).
o Joss, J., Waldvogel, A. (1990). Precipitation measurements and hydrology. A: Battan memorial
and 40th anniversary of the radar meteorology. AMS, 577-606.
Stakeholders additional provided documentation:
o SW:
Excel file example of daily procedures to operate the WRZ
Existing public information from web pages:
o SW:
Scottish Environment Protection Agency (SEPA) (http://www.sepa.org.uk/)
o Tavira Verde:
Instituto Portuguès do Mar e da Atmosfera (IPMA) (http://www.ipma.pt/)
Sistema Nacional de Informaçao de Recursos Hidricos home page (http://snirh.pt)
Deliverable D4.1 – Decision supporting tools system requirements
92
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information from similar operational systems:
o L’Aigua en temps real. Real Time system at the Catalan Water Agency: http://aca-
web.gencat.cat/aetr/aetr2/
OUTPUT:
The previous information has been used to complete the following sections of D4.1:
6.3.1 WAPS scenarios
6.3.2 WAPS use cases
0 WAPS requirements
Type of requirements Water availability calculation requirements
Used information
INPUT:
Research and other published material:
o Atencia A., B. Rigo, A Sairouni, J Moré, J. Bech, E. Vilaclara, J. Cunillera, C. Llasat, L Garrote.
(2010). Improving QPF by blending techniques at the Meteorological Service of Catalonia.
Natural Hazards and Earth System Sciences, 2010, 10, 1443-1455.
o Austin, G.L., Bellon, A. (1974). The use of digital weather records for short-term precipitation
forecasting. Quarterly Journal of the Royal Meteorological Society, 100, 658-664.
o Battan, L.J. (1973). Radar Observation of the Atmosphere. Ed, University of Chicago Press,
Chicago (USA), 324 pp.
o Cassiraga, E.F., Gomez-Herna ndez, J.J. (1996). Improved rainfall estimation by integration of
radar data: A geostatistical approach. A: First European Conference on Geostatistics for
Environmental Applications, Lisboa, Portugal.
o Corral, C. (2004). Desenvolupament d’un model hidrolo gic per incorporar informacio del radar
meteorologic. PhD Theses. Universitat Politecnica de Catalunya, 203 pp.
o Garrote, L., Bras, R.L. (1995). A distributed model for real-time flood forecasting using digital
elevation models. Journal of Hydrology, 167, 279-306.
o Krajewski, W.F. (1987). Cokriging radar-rainfall and rain gage data. Journal of Geophysical
Research, 92(D8), 9571-9580.
o Sa nchez-Diezma, R. (2001). Optimizacion de la medida de lluvia por radar meteorologico para
su aplicacion hidrologica. PhD Theses, Universitat Politecnica de Catalunya, Barcelona, 313
pp.
o Sinclair S., G. Pegram (2005). Combining radar and rain gauge rainfall estimates using
conditional merging. Atmospheric Science Letters, 6, 19-22.
o Velasco-Forero C., D. Sempere-Torres, E. F. Cassiraga, J. Gómez-Hernández. (2009). A non-
parametric automatic blending methodology to estimate rainfall fields from rain gauge and radar
data. Advances in Water Resources. 32, 986–1002.
o Zawadzki, I. (1984). Factors affecting the precision of radar measurement of rain. A: 22
Conference on radar meteorology, Zurich, Switzerland, Ed: AMS, 251-256.
OUTPUT:
The previous information has been used to complete the following sections of D4.1:
Deliverable D4.1 – Decision supporting tools system requirements
93
URBAN-WATER PUBLIC
Grant Agreement: 318602
6.3.1 WAPS scenarios
6.3.2 WAPS use cases
0 WAPS requirements
8.6 Included documentation
In this section the following documentation is included:
Minutes meetings:
o 2013/07/09 – Meeting with Scottish Water
o 2013/07/22 – Meeting with Tavira Verde
o 2013/12/13 – Meeting with Ateknea
o 2014/02/11 - Meeting with Scottish Water
o 2014/03/18 - Meeting with Tavira Verde and APA
o 2013/01/24 – Meeting with Tavira Verde
o 2013/05/08 – Meeting with Scottish Water and Tavira Verde
o 2013/11/04-05 – Meeting with Scottish Water
Follow up template reference to discuss operational rules
o Support document to have a first definition of water utilities’ operational rules
Follow-up template reference to complete discussions.
o Support document to check the required information with the stakeholders
Stakeholders’ surveys.
o Initial survey collecting information from the stakeholders.
Tavira Verde documentation:
o Contingency plan for the Barlovento and Sotavento regions
o EPANET hydraulic model
o Information regarding Tavira water distribution network topology, meters location and areas
o Contributive basins of the Algarve reservoirs
Scottish Water Documentation:
o Water Resource Plan draft (Not included, confidential information).
o Pateshill reservoir and Loch Katrine control curves examples (Not included, confidential
information).
o Excel – engine to WRZ management (Not included, confidential information).
o Report on control curves calculation methodology (Not included, confidential information).
o Fife WRZ logical model schema (Not included, confidential information).
Others:
o Data needs for identification of water demand & detailed indoor consumption
Deliverable D4.1 – Decision supporting tools system requirements
94
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.1 Minutes meetings
8.6.1.1 2013/07/09 – Meeting with Scottish Water
8.6.1.1.1 Context
Previously HYDS prepared deliverable D4.1 “Decision supporting tools requirements”, where DSS requirements
were partially presented. This information was compiled through a requirements survey prepared by HYDS and
answered by both water utilities. These answers were incomplete (some missing answers and others not fully
explained). A phone conference was decided during the Tavira meeting to continue working in this issue.
In addition, and to define the DSS design, HYDS is analyzing possible inference engine solutions. One of them
consists on using a rule-based inference engine, based on logical rules. Thus, in this meeting HYDS wants to
understand how SW operates their water supply systems to validate whether logical rules could be sufficient to
define how they operate the system.
Finally, HYDS wants to have preliminary talks regarding the potential demo site for the validation in Scotland. The
idea is to know which water supply and distribution elements SW typically has, how they operate them and which
information is available. An introductory document has been prepared by HYDS and sent to SW to have a first idea
of the points to discuss. The key points of this document are:
Scenarios: definition of possible scenarios, conditions to choose one over the others
Strategies: definition of different strategies based and current conditions
Water supply system elements (reservoirs, water tanks, water treatment plants, others): how are them
operated, is there documentation regarding management operations, etc.
All this information will be part of the deliverable D4.2 “Decision supporting tools design” to be prepared for month
M9.
8.6.1.1.2 Participants
Name Company
Alvaro Rodriguez [AR] HYDS
David Sancho [DS] HYDS
Bill Brydon [BB] Scottish Water [SW]
Caroline Olbert [CO] Scottish Water [SW]
8.6.1.1.3 Points to discuss
1. Discuss points that weren’t answered by SW in the requirements survey prepared by HYDS
2. Understand how SW typically operates the reservoirs and the water supply systems to define the
operational rules of the demo site (yet to be decided)
3. First discussions about potential demo sites on the validation
4. Explain the document sent and answer possible doubts regarding which information is needed from SW
Deliverable D4.1 – Decision supporting tools system requirements
95
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.1.1.4 Memory
SW made a general presentation about them: how water is processed and distributed in Scotland, the
elements they have in the water supply systems, typical problems and challenges they have, etc. SW has
defined 190 Water Resource Zones (WRZ).
A WRZ is the largest possible zone in which all customers experience the same risk of supply failure from
a resource shortfall. Typically a WRZ covers a small area with small demand and with just one water
source and one water treatment plant.
The validation is expected to be held in one of these WRZ. All this information is included in the Water
Resource Plan draft that will be sent to HYDS, with a presentation summarizing the key issues.
Water sources consist in Scotland in reservoir and boreholes (groundwater). Reservoirs are operated with
control curves, indicating the supplied water of each reservoir depending on the storage water.
Every month the level of the reservoirs is analyzed to set the supplied for the next month. In case leakages
were reduced, these control curves would change less frequently. In some cases were the storage water
is low, restrictions actions are held to guarantee water supply.
Finally, regarding the demo site selection, SW will analyze all the information
8.6.1.1.5 Agreements
Complete the document sent by HYDS: BB, CO
Send examples of the control curves used to operate the reservoirs: CO (Pateshill reservoir and Loch
Katrine control curves already sent)
Send Water Resource Plan draft: BB. This document has the following contents:
o Water resource zones (description, distribution, rationalization)
o Level of service
o Water available for use
o Components of demand and demand forecast
o Supply demand balance methodology
o Zonal prioritization
o Action plan
Prepare other additional information that could be interesting for HYDS in order to define the operational
rules: BB
Prepare a first document describing how SW operates reservoirs and the water supply systems in general:
AR, DS. This document will have the following contents:
o SW presentation (general information, WRZ description, presentation of the Loch Katrine system)
o Operational rules in the Loch Katrine system
o Demo sites candidates (analysis and proposal)
NOTE: Most of the information sent by SW is considered confidential and is used only as a reference, thus it cannot
be included in the deliverable or shared with other UrbanWater partners
Deliverable D4.1 – Decision supporting tools system requirements
96
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.1.2 2013/07/22 – Meeting with Tavira Verde
8.6.1.2.1 Context
Previously HYDS prepared deliverable D4.1 “Decision supporting tools requirements”, where DSS requirements
were partially presented. This information was prepared through a requirements survey done by HYDS and
answered by both water utilities. These answers were incomplete (some missing answers and other not fully
explained). During Tavira meeting, a phone conference was decided to be held continue working in this issue.
In addition, and to define the DSS design, HYDS is analyzing possible inference engine solutions. One of them
consists on using a rule-based inference engine, based on logical rules. Thus, in this meeting HYDS wants to
understand how Tavira Verde (Tave) and Aguas do Algarve (AdA) operates their water supply systems to validate
whether logical rules could be sufficient to define how they operate the system.
Finally, HYDS wants to have preliminary talks regarding the potential demo site for the validation in Scotland. The
idea is to know which water supply and distribution elements Tave and AdA typically have, how they operate them
and which information is available. An introductory document has been prepared by HYDS and sent to Tave and
AdA to have a first idea of the points to discuss. The key points of this document are:
Scenarios: definition of possible scenarios, conditions to choose one over the others
Strategies: definition of different strategies based and current conditions
Water supply system elements (reservoirs, water tanks, water treatment plants, others): how are them
operated, is there documentation regarding management operations, etc.
All this information will be part of the deliverable D4.2 “Decision supporting tools design” to be prepared for month
M9.
8.6.1.2.2 Participants
Name Company
Alvaro Rodriguez [AR] HYDS
David Sancho [DS] HYDS
António Chaves Ramos [AC] Tavira Verde [Tave]
Helena Lucas [HL] Águas do Algarve [AdA]
8.6.1.2.3 Points to discuss
1. Discuss points that weren’t answered by Tave and AdA in the requirements survey prepared by HYDS
2. Understand how AdA typically operates the reservoirs and the water supply in Algarve
3. Explain the document sent and answer possible doubts regarding which information is needed from Tave
and AdA
8.6.1.2.4 Memory
AdA has divided Algarve region into two water distribution networks.
These two regions are connected through a pump station which supplies water from one region to the
other and vice versa. Water sources in the Algarve region consist on reservoirs and groundwater.
Deliverable D4.1 – Decision supporting tools system requirements
97
URBAN-WATER PUBLIC
Grant Agreement: 318602
A contingency plan is defined on each region to decide which source is supplying water to the system. HL
will send these contingency plans to HYDS.
AdA is in charge to supply water to Tave tanks, based on water demand estimations. They operate the
system from the water treatment plants to the water tanks. Upper part of the system (reservoirs) is
operated by Agencia Portuguesa do Ambiente (APA), and downstream part (from the water tanks to the
end-users) by Tave in the case of Tavira municipality.
Water tanks are filled by AdA following some operational rules. These rules and the general description
of the water distribution network is contained in an EPANET hydraulic model. HL will send these models
to HYDS.
8.6.1.2.5 Agreements
Complete the document sent by HYDS: AC, HL
Send the contingency plan for the Barlovento and Sotavento regions: HL. These documents consist on a
logical model schema where water flows supplied from WTP and groundwater to the different
municipalities are specified.
Prepare and send information regarding Tavira water distribution network topology, meters location and
areas: AC
Send contributive basins of the Algarve reservoirs: HL (basins of Bravura, Arade, Funcho and Odelouca
reservoirs already received)
Prepare a first document describing how Tave and AdA operates reservoirs and the water supply systems
in general: AR, DS. This document will have the following contents:
o Algarve and Tavira region description
o Description of the water supply system
o Scenarios and operational rules description
8.6.1.3 2013/12/13 – Meeting with Ateknea
8.6.1.3.1 Context
Part of the works on the development of the Decision support system (DSS) and the Water availability prediction
system (WAPS) is the integration of these two modules in the UrbanWater platform (developed by ASC). This
integration will affect the development of both modules, so a meeting was planned to understand the integration
works to be done by HYDS and to make a first integration planning.
8.6.1.3.2 Participants
Name Company
Alvaro Rodriguez [AR] HYDS
David Sancho [DS] HYDS
Albert Rodriguez [AL] Ateknea Solutions Catalonia [ASC]
Andrés Cisneros [AC] Ateknea Solutions Catalonia [ASC]
Deliverable D4.1 – Decision supporting tools system requirements
98
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.1.3.3 Points to discuss
Explain UrbanWater service bus
Explain proposed services to be offered by HYDS modules (WAPS and DSS)
Discuss HYDS modules and integration planning
8.6.1.3.4 Memory
ACS explained how works RabbitMQ, the technology used to communicate the different UrbanWater
modules with the platform
ACS presented UrbanWater user interface, developed with Katniss and how HYDS modules can be
integrated
HYDS presented a summary of the DSS and WAPS requirements and design, and the list of services both
modules will supply through the service bus. Both parts agreed that the services are enough but in the
future new services could be added if needed.
HYDS explained how their modules user interface will be developed and first thoughts about integration
works
ACS and HYDS agreed a first integration planning to show WAPS user interface integrated into the
platform (using dummy data) for demonstration purposes. This demonstration will be done during first
periodic report to be done in February 2014 in Brussels with the PO and the reviewers.
8.6.1.3.5 Agreements
Prepare an email with all the needed information to work with RabbitMQ and to connect with UrbanWater
platform services: AC
Work on user interface integration and try to have a dummy Water Availability Prediction System (WAPS)
module to be presented in Brussels meeting as a module integration example: AR, DS
8.6.1.4 2014/02/11 - Meeting with Scottish Water
8.6.1.4.1 Context
In the last months SW decided that Fife WRZ will be the demo site within the validation phase of the UrbanWater
project. In the meeting held in Paris a consortium meeting in SW facilities with HYDS was decided to be done in
the next months. The main goal of the meeting is to understand how SW operates the WRZ, to know which
information they have available and to clarify some points regarding the DSS requirements and design.
In addition, EC reviewers rejected both deliverables, and HYDS decided to extend the water utilities description
and to rework on the requirements and design definition of both DSS and WAPS modules. In the meeting is
expected to talk about how they operate the reservoirs in order to validate WAPS requirements and design to verify
it covers SW needs.
In order to follow this meeting, HYDS has prepared meeting guidelines to follow with the following points to define
the Fife demo site requirements:
Deliverable D4.1 – Decision supporting tools system requirements
99
URBAN-WATER PUBLIC
Grant Agreement: 318602
Water sources: precipitation, snow, groundwater, sea water, urban storm water, wastewater, drainage
system
Raw water sources: reservoirs, rivers, and groundwater
Water allocation: domestic, agricultural, industrial, recreational, hydropower and environment flows
Drinking water producers: WTP, desalination plants, and wastewater plants
Distribution elements: pipes, valves, tanks
Other elements: hydropower
Water consumption: domestic, irrigation, industrial, recreational
Raw water suppliers management
Drinking water suppliers management
The idea of these points is to know which information is available regarding the current and future status of each
element and how SW uses this information. This information will be included in deliverable D4.1 and additional
requirements and design can be added to deliverables D4.1 and D4.2.
8.6.1.4.2 Participants
Name Company
Alvaro Rodriguez [AR] HYDS
David Sancho [DS] HYDS
Rafael Sanchez-Diezma [RS] HYDS
Bill Brydon [BB] Scottish Water [SW]
Caroline Olbert [CO] Scottish Water [SW]
Owen Bramwell [OB] Scottish Water [SW]
8.6.1.4.3 Points to discuss
Review DSS and WAPS requirements and design
Fife Water Resource Zone (WRZ) presentation and explanation about how is operated by SW
Talk about the points presented in the guideline document
8.6.1.4.4 Memory
HYDS presented a summary of the key points regarding the requirements and design proposed for the
DSS and WAPS. SW agreed that this information was correct and will review the new version of the
deliverables D4.1 and D4.2 to validate that both modules fulfill their needs.
SW presented a general description regarding how they operate in general a WRZ. Each of them is based
in a water source and an urban area where water is consumed. Each WRZ has an individual management
and can’t be connected, because of the geographical distance and the cost. Each WRZ has its own
drought contingency plan (or water scarcity plan).
Reservoirs are managed using control curves. They have different levels, and contingency actions are
taken depending on the level. These control curves are calculated combining historical information with
demands.
SW produces weekly reports indicating measured reservoir levels and the control curves.
Deliverable D4.1 – Decision supporting tools system requirements
100
URBAN-WATER PUBLIC
Grant Agreement: 318602
SW has an excel file summarizing Scotland WRZ scenarios displaying the worst scenario for each mega-
zone (group of WRZs). It has one tab for each reservoir, indicating the raw demand and the supply, and
other interesting parameters. With this information SW is able to calculate how many days the reservoir is
able to keep serving water.
SW also gathers meteorological information supplied by MetOffice in their webpage.
Another dashboard is generated by SW summarizing water flows and levels in the rivers in the last 5
months. This information is supplied by SEPA and is very interesting to evaluate the current hydrological
status of each basin.
8.6.1.4.5 Agreements
Prepare a demo site description using all the information supplied by SW: AR, DS, RS. This document will
have the following contents:
General information
Water sources management
Water allocation and distribution
Water treatment works (WTP)
Fife demo site description
Glendevon disaggregated system description
Available data
Review the document: OB, CO
Send links to the websites from where SW gathers information regarding meteorological and hydrological
current status of the WRZ: OB
Send an excel file example displaying the global status of the WRZs and the available information: OB
Prepare a document regarding control curves calculation methodology: OB, CO
8.6.1.5 2014/03/18 - Meeting with Tavira Verde and APA
8.6.1.5.1 Context
During the first periodic review, EC reviewers rejected both deliverables, and HYDS decided to extent the water
utilities description and to rework on the requirements and design definition of both DSS and WAPS modules. In
the case of Tave, it is expected to increase the available information regarding how reservoirs are operated. Thus,
a meeting with APA will held in order to better understand how water supply system is operated. This will imply that
new requirements could appear (especially in the WAPS module, which predicts future availability in reservoirs),
so deliverables D4.1 and D4.2 could change in order to include water utilities feedback.
In order to follow this meeting, HYDS has prepared meeting guidelines to follow with the following points to define
the demo site requirements:
Water sources: precipitation, snow, groundwater, sea water, urban storm water, wastewater, drainage
system
Raw water sources: reservoirs, rivers, and groundwater
Drinking water producers: WTP, desalination plants, and wastewater plants
Distribution elements: pipes, valves, tanks
Deliverable D4.1 – Decision supporting tools system requirements
101
URBAN-WATER PUBLIC
Grant Agreement: 318602
Other elements: hydropower
Water consumption: domestic, irrigation, industrial, recreational
Raw water suppliers management
Drinking water suppliers management
The idea of these points is to know which information is available regarding the current and future status of each
element and how APA uses this information. This information will be included in deliverable D4.1 and additional
requirements and design can be added to deliverables D4.1 and D4.2.
8.6.1.5.2 Participants
Name Company
Alvaro Rodriguez [AR] HYDS
Rafael Sanchez-Diezma [RS] HYDS
Antonio Chaves [AC] Tavira Verde [Tave]
Pedro Coelho [PC] Agencia Portuguesa de Ambiente [APA]
8.6.1.5.3 Points to discuss
1. To understand how APA operates the reservoirs and how raw water reaches Water Treatment Plants
operated by Aguas do Algarve (AdA)
8.6.1.5.4 Memory
Algarve region is characterized as a region where water scarcity commonly occurs, especially in summer
when population is increased due to the tourism. To solve these scarcity problems, the government built
a reservoir with a capacity enough to solve these problems. Odelouca reservoir has solved all the water
scarcity problems in the region and now reservoirs are able to supply raw water for over one year.
Reservoirs are operated as passive elements where water is supplied downstream depending on the
expected demand. There are a minimum and maximum flow thresholds defined by a contract signed
between APA and AdA and APA has to maintain supplied flows within the thresholds. Thus, reservoirs
can be considered as huge raw water tanks that always are able to supply raw water to the water treatment
plants. Then this WTP supply water to water distribution inflow tanks and from this point Tave distribute
water to end-users
All the supplied flows are fixed by several contracts signed by the involved entities.
8.6.1.5.5 Agreements
Complete the demo site description using information explained by APA: AR, RS
Review the demo site description extended with reservoir management operations explained by APA: AC
Deliverable D4.1 – Decision supporting tools system requirements
102
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.1.6 2013/01/24 – Meeting with Tavira Verde
8.6.1.6.1 Participants
Name Company
António Chaves Ramos [AC] Tavira Verde [TAVE]
José Florentino [JF] Tavira Verde [TAVE]
Carla Silva [CS] Aqualogus [AQ]
Francisco Carvalho [FC] Aqualogus [AQ]
8.6.1.6.2 Memory
In this meeting TAVE made a general presentation of the company regarding its structure, commitment and policies. The water
distribution network was described with detail as well as the water management of the network and particularly the procedures
involved in the control of water losses.
8.6.1.7 2013/05/08 – Meeting with Scottish Water and Tavira Verde
8.6.1.7.1 Participants
Name Company
António Chaves Ramos [AC] Tavira Verde [TAVE]
José Florentino [JF] Tavira Verde [TAVE]
Bill Brydon [BB] Scottish Water [SW]
Carla Silva [CS] Aqualogus [AQ]
Francisco Carvalho [FC] Aqualogus [AQ]
8.6.1.7.2 Memory
In this meeting there were two main subjects discussed, the possible validation sites and their structure and stakeholders, and
the interest and advantages expected from the leakage detection system.
Concerning the LDS the issues discussed were:
Exposure of AQUA’s understanding on the philosophy of the leakage module
Discussion of the adequacy of the proposed philosophy, taking into account practices, models, methods, etc... in SW
/ TAVE
Required/desired information for model development (site selection / what information can be made available)
Criteria for data treatment /cleaning (time series)
Hydraulic model (EPANET) – interest in using and limitations
Discuss interest in the pressure measurement of in some consumption points
Validation: AMR coverage that will be available, task assignment/distribution, validation criteria
Possible access to historical AMR information from other DMAs / water operators
Deliverable D4.1 – Decision supporting tools system requirements
103
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.1.8 2013/11/04-05 – Meeting with Scottish Water
8.6.1.8.1 Participants
Name Company
Bill Brydon [BB] Scottish Water [SW]
Kenny Milligan [KM] Scottish Water [SW]
Andrew McGregor [AMG] Scottish Water [SW]
Rory Pamphilon [RP] Scottish Water [SW]
Rory Pamphilon [RP] Scottish Water [SW]
Laura Burnett [LB] Scottish Water [SW]
Carla Silva [CS] Aqualogus [AQ]
Francisco Carvalho [FC] Aqualogus [AQ]
8.6.1.8.2 Memory
SW made a detailed presentation of the methodologies and procedures applied in the company to control water
losses. The issues of the meeting were:
Distribution Input (DI): Overview of how SW calculates a DI volume for the whole of Scotland. A look at
the system used, data streams, site volumes and meters reads
Per Household Consumption (PHC): Overview of how SW calculates a DI volume for the whole of
Scotland. A look at the system used, data streams, site volumes and meters reads
Districted Meter Area (DMA) Leakage: Theory - An overview of how DMA leakage is calculated
across Scotland for use in the Water Balance
Districted Meter Area (DMA) Leakage: Practical - Time with an Analyst looking at the
techniques they use to identify leakage
Site visit with squad to see Leakage Detection in action
Non Household Consumption (NHH): Overview of Scottish Waters process for calculating NHH
Consumption
Water Balance: Overview of the Water Balance (mass balance) which is used to report leakage across
Scotland
8.6.2 Follow up template reference to discuss operational rules
8.6.2.1 Introduction
Within UrbanWater, the work in WP4 is to implement decision support tools for water utilities. These tools are:
Water demand prediction system, led by UNIZG-FER
Water availability prediction system, led by HYDS
Spatial Decision Support System (SDSS), led by HYDS
Leakages detection system, led by AQUA
Deliverable D4.1 – Decision supporting tools system requirements
104
URBAN-WATER PUBLIC
Grant Agreement: 318602
Following the schedule of the next months, the next milestone within the work package is to define the Decision
Support System (DSS) design. The DSS will combine operational rules defined by water utilities and the situation
of the system (water levels, hydrological forecasts, NWP models, radar nowcasting, …) to help the operators in the
decision-making process looking for an optimal solution.
Figure: Elements within Tavira basin (font: Aguas do Algarve)
Once the validation site is defined, we will define logical elements for managing each site’s elements. These logical
elements could have measured data, forecasted data from hydrological and meteorological models, forecasted
demand from the water demand system, and leakages from the leakages detection system. Combining all this
information and the rules defined for the logical elements, an optimal solution will be provided to the decision-
makers.
Deliverable D4.1 – Decision supporting tools system requirements
105
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure: Relation between logical elements of the basin and their data to define operation rules
This task of combining all the information to propose an optimal solution is performed by the inference engine. Thus,
we need to choose an inference engine that allows us to integrate the operational rules the water utilities will use.
In order to make this choice, first we need to acquire information from water utilities regarding how they operate
the different elements in their basins such as:
Reservoirs
Water treatment plants
Deposits
Wastewater systems
Underground water plants
Water distribution system
Figure: Elements within a basin (Font: Agència catalana de l’aigua – ACA)
With this information regarding the elements operation, some operational rules will be defined. Using these rules,
we will determine the rules’ complexity requirements the inference engine will have to satisfy.
Deliverable D4.1 – Decision supporting tools system requirements
106
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure: General schema of the DSS interactions
At this stage of the project, the test sites have not been selected. Anyway, what we need at this point is to gather
examples of how water utilities operate each element. The goal of the meetings is to compile information of the
operation tasks from a couple of sites of each type. This meeting is focused on two elements type: reservoirs and
deposits. Once the meeting is done we will proceed in the same way with the other elements, or if we consider
water utilities understand which information we need and there is no need to make a meeting, then this information
will directly be sent via email.
8.6.2.2 Scenarios
In some situations, the operations taken in an element are different depending on the scenario. Thus, the DSS
should be able to define different scenarios and define different rules for each of them. Here are some definitions
of possible scenarios:
If the level of the reservoirs is above 90%, then the scenario is “abundance”.
If the level of the reservoirs is below 40%, then the scenario is “scarcity”.
Other cases, the scenario is “normality”.
If the level of the reservoirs is above 75% and season is “winter”, then the scenario is “abundance”.
If the level of the reservoirs is below 50% and season is “summer”, then the scenario is “scarcity”.
Other cases, the scenario is “normality”.
Does your water utility consider these scenarios on the operation decisions process? Which?
Deliverable D4.1 – Decision supporting tools system requirements
107
URBAN-WATER PUBLIC
Grant Agreement: 318602
Are they used as general situations or are different depending the element?
What kind of data do you use to take the decisions (measured data, forecasted data from models, etc)?
8.6.2.3 Strategies
A strategy is the goal a water utility wants to achieve operating the elements. These strategies can be:
Flow-flood control
Hydropower generation
Sediments control
Pollution/water quality
Reduction of network losses
Meeting availability and demand
Irrigation needs
Water allocation
Saving resources
Balance of water resources
Water pricing
Environmental measurements
Of all these strategies, we want to know if:
Does your water utility use different strategies operating the elements?
Do you combine these strategies or use just one in the whole site?
Do you change the strategy to use depending on the scenario? I.e.:
o If scenario is “abundance” then strategies are “pollution/water quality” and “flow-flood control”.
o If scenario is “scarcity” then strategies are “meeting availability and demand”, “saving resources”
and “water pricing”.
What kind conditions you take into account to modify the strategy (forecasts, season of the year, etc)?
8.6.2.4 Reservoirs
The goal of this section is to understand how you operate some reservoirs to define the complexity of the rules the
DSS will use. Here are some examples of rules your water utility could use:
If the level of the reservoir is above 90%, scenario is “abundance” and forecast of the next days indicates
reservoir’s level will reach 95%, then open gate G1
If day of the week is “Saturday” or “Sunday” and season is “summer”, then open gate G1
If time is between “21:00” and “06:00” then close gate G1
We need (for a couple of reservoirs or if there are general rules):
List of some operations you normally take in long, mid and short-term planning
For each operation, based on which conditions you take these operations?
What kind of data do you use in the conditions (radar data, sensors data, models, …)
Do you have in your water utility specific documentation defining the procedures to operate the reservoirs?
If affirmative, is it possible to send us this?
Deliverable D4.1 – Decision supporting tools system requirements
108
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.2.5 Water tanks
The goal of this section is to understand how you operate some water tanks to define the complexity of the rules
the DSS will use. Here are some examples of rules your water utility could use:
If time is between “07:00” and “10:00”, outflow = 10m³/s
If predicted demand of next 3 hours is 25m³/s then outflow = 27m³/s
If season is “summer” and scenario is not “scarcity”, then increase daily outflow curve 25%
If level of reservoir R1 is above 90% and time is between “21:00” and “06:00”, then empty the tank
We need (for a couple of tanks or if there are general rules):
List of some operations you normally take in long, mid and short-term planning (probably in this case
only short-term has sense)
For each operation, based on which conditions you take these operations?
What kind of data is used by the conditions (radar data, sensors data, forecast models, demand
prediction, …)?
Do you have in your water utility specific documentation defining the procedures to operate the tanks? If
affirmative, is it possible to send us this?
8.6.3 Follow up template reference to complete discussions
8.6.3.1 General considerations
If you have support information to take decisions / operate the systems (like excel spreadsheets or public
website information) and it’s possible, send these files/links
In case of models, specify which these models are, if they are automatically executed, if they are
periodically executed or just under certain scenarios. A brief explanation will be helpful in order to not have
to come back to you.
8.6.3.2 Water sources
8.6.3.2.1 Precipitation
How is calculated the run-off, infiltration, evaporation and transportation (e.g. hydrological models)?
8.6.3.2.2 Snow
How is calculated the run-off, infiltration, evaporation and transportation (e.g. hydrological models)?
8.6.3.2.3 Groundwater
Do you have groundwater models?
8.6.3.2.4 Sea water
Seawater used in desalination plants to convert it to drinking water (or water for irrigation/other uses?)
Deliverable D4.1 – Decision supporting tools system requirements
109
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.3.2.5 Urban stormwater
Water accumulated by the sewer network in storms in the urban areas
8.6.3.2.6 Wastewater
Water from sewerage system
8.6.3.2.7 Drainage water
Drainage water is the unused water for irrigation.
8.6.3.3 Raw water sources
8.6.3.3.1 Reservoirs
8.6.3.3.1.1 Current status of the reservoir
Which variables do you measure?
o Water level (m)
o Storage volume (hm³)
o Storage capacity (hm³)
o Inflow (m³/s)
o Outflow (m³/s)
o Others... (Specify)
Do you calculate evaporation in the reservoir? A combination of temperature, humidity, wind and
evaporation rate could calculate the amount of water lost per hour in a reservoir
Do you calculate infiltrations of the stored water in the reservoir? A combination of soil type, land cover,
soil moisture, soil water capacity, soil temperature and soil infiltration capacity could current calculate
water loss by infiltrations.
What is the benefit of this information? How is it used and for which purpose?
8.6.3.3.1.2 Future status
Which parameters do you predict?
Do you calculate future water received by precipitations? By simple calculations using prediction models
or using these models as inputs into hydrological models which predict future reservoir inflows...
Do you calculate water will lose by evaporation in the next days? Using prediction models combining
variables previously listed.
Do you calculate water lost by infiltrations in the future? By using variables previously listed.
What is the benefit of this information? How is it used and for which purpose?
8.6.3.3.2 Rivers
8.6.3.3.2.1 Current status of the river
Which variables do you measure?
Deliverable D4.1 – Decision supporting tools system requirements
110
URBAN-WATER PUBLIC
Grant Agreement: 318602
o Water level
o Flow
o Water quality
Do you calculate evaporation in the river? A combination of temperature, humidity, wind and evaporation
rate could calculate the amount of water lost per hour in a river
Do you calculate infiltrations of the stored water in the river? A combination of soil type, land cover, soil
moisture, soil water capacity, soil temperature and soil infiltration capacity could current calculate water
loss by infiltrations.
What is the benefit of this information? How is it used and for which purpose?
8.6.3.3.2.2 Future status of the river
Which parameters do you predict?
o Future water level (m)
o Future flow (m³/s)
o Future drinking quality
Do you calculate future flow received by water released from reservoirs or other points?
Do you calculate future water received by precipitations? By simple calculations using prediction models
or using these models as inputs into hydrological models which predict future reservoir inflows...
Do you calculate water will lose by evapotranspiration in the next days? Using prediction models
combining variables previously listed.
Do you calculate water lost by infiltrations in the future? By using variables previously listed.
What is the benefit of this information? How is it used and for which purpose?
8.6.3.3.3 Groundwater/aquifer/boreholes
Which is the usage of boreholes? Irrigation/Drinking water/...
Processes done to treat water depending in the usage
8.6.3.3.3.1 Current status of groundwater
Which parameters you measure in a borehole/aquifer?
o Groundwater level (m)
o Groundwater storage volume (m³)
o Groundwater storage capacity (m³)
o Recharge rate (m³/s)
o Outflow (m³/s)
Do you calculate infiltrations? (Recharge rate)
What is the benefit of this information?
8.6.3.3.3.2 Future status of groundwater
Do you calculate future recharge rate, level and volume? (Inflow) How (e.g. through a hydrological
Do you calculate future outflow?
Do you calculate infiltrations?
Deliverable D4.1 – Decision supporting tools system requirements
111
URBAN-WATER PUBLIC
Grant Agreement: 318602
What is the benefit of this information?
8.6.3.4 Water allocation
8.6.3.4.1 Domestic
Households, bathing, cooking, sanitation, gardening...
Is there any seasonal variation (mainly due to tourism)?
8.6.3.4.2 Agricultural
Is there a minimum constant flow?
How often is decided the provided flow (monthly, daily, seasonally...)? Who decides this flow (e.g. water
authority together with irrigation associations, a signed contract specifies it...)?
8.6.3.4.3 Industrial
Some industries like thermoelectric power plants (for cooling), ore and oil refineries (chemical processes),
manufacturing plants. Is it considered?
8.6.3.4.4 Recreational
Maintain specific volume in a lake or reservoir, recreational events... (Generally non-consumptive) . Is it
considered?
8.6.3.4.5 Hydropower
Water is not consumed but flow is needed
8.6.3.4.6 Environment flows
Water is not consumed, but it requires a constant minimum flow (e.g. in water retained in a river to maintain
waterway health, fishing farms ...)
8.6.3.5 Drinking water producers
8.6.3.5.1 Water treatment plant
For each WTP:
Raw water storage capacity (m³)
Drinking water capacity (m³)
Treatment production (m³/s)
All the WTP have the same process?
Water treatment has the same cost in every plant?
Is there a minimum flow the plant needs in their works (just for maintenance)?
Deliverable D4.1 – Decision supporting tools system requirements
112
URBAN-WATER PUBLIC
Grant Agreement: 318602
Is there a minimum/maximum water quality raw water needs? (e.g. when water is too pure/dirty it could spoil the
filters)
8.6.3.5.1.1 Current status
Which variables are measured?
Inflow (m³/s)
Outflow (m³/s)
Water quality (ph?) (inflow and outflow)
Raw water storage volume (m³)
Drinking water storage volume (m³)
Energy used (w)
What is the benefit of this information?
8.6.3.5.1.2 Future status
Do you have models to predict?
Inflow
Outflow
Water quality (inflow and outflow)
Raw water storage volume
Drinking water storage volume
Energy used
Energy cost curve (based on demand)
How is it calculated? By hydrological models, hydraulic models, excel tables...
What is the benefit of this information?
8.6.3.5.2 Desalination plants
For each plant:
Seawater storage capacity (m³)
Drinking water storage capacity (m³)
Treatment production (m³/s)
Production cost (w/m³)
All the plants do the same process?
Same treatment cost on each plant?
How is it calculated? Through models, excel tables...
What is the benefit of this information?
8.6.3.5.2.1 Current status
Which variables are measured?
Inflow (m³/s)
Outflow (m³/s)
Deliverable D4.1 – Decision supporting tools system requirements
113
URBAN-WATER PUBLIC
Grant Agreement: 318602
Water quality (ph) (inflow and outflow)
Raw water storage volume (m³)
Drinking water storage volume (m³)
Energy used (w)
What is the benefit of this information?
8.6.3.5.2.2 Future status
Which variables are predicted?
Inflow
Outflow
Water quality
Raw water storage volume
Drinking water storage volume
Energy used
Energy cost curve (based on future demand)
How is it calculated? Hydrological models, hydraulic models, sea models...
What is the benefit of this information?
8.6.3.5.3 Wastewater treatment plants
General description, variables measured, variables predicted, how are them predicted
What is the benefit of this information?
8.6.3.6 Distribution elements
Do you take into account distribution times? Time spent from WTP to arrive to a costumer, time to arrive from a
reservoir to a WTP...
How is it done? Through excel files, hydraulic models, hydrological models...
8.6.3.6.1 Pipes
Brief description
8.6.3.6.1.1 Current status
Which variables are measured?
Pressure (hPa)
Flow (l/s)
Level (cm)
What is the benefit of this information?
How are leakages detected? (Hydraulic models, comparing inflows and outflows, analyzing the pressure...)
What are the corrective actions when a leakage is detected? Just fix it, change water distribution chain...
Deliverable D4.1 – Decision supporting tools system requirements
114
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.3.6.1.2 Future status
Is there a hydraulic model (like EPANET) or distribution model to predict future status of the pipes?
Which variables are predicted?
Pressure
Flow
Level
What is the benefit of this information?
8.6.3.6.2 Valves
Which variables are measured?
Inflow
Outflow
Pressure
Level?
What is the benefit of this information?
What type of valves you have?
8.6.3.6.3 Tanks
Type of tanks you have (gravity / ground). Are they operated in the same way?
Description of each tank:
Storage capacity
Maximum outflow
How much time could be providing (e.g. it could store water to provide water for 2 days without inflows)
8.6.3.6.3.1 Current status
Which variables are measured?
Level
Pressure
Storage volume
Inflow
Discharge/outflow
What is the benefit of this information?
8.6.3.6.3.2 Future status
Which variables are measured?
Level
Pressure
Storage volume
Inflow
Discharge/outflow
How are these variables measured? Hydraulic models (EPANET), distribution model, excel tables...
What is the benefit of this information?
Deliverable D4.1 – Decision supporting tools system requirements
115
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.3.7 Other elements
8.6.3.7.1 Hydropower plants
Description of each hydropower plant:
Maximum flow (m3/s)
Power generation capacity (watts)
8.6.3.7.1.1 Current status
Which variables are measured?
Water diversion rate (m³/s)
Energy produced (watt)
Efficiency (%)
Energy used (watt)
What is the benefit of this information?
8.6.3.7.1.2 Future status
Which variables are predicted?
Water diversion rate
Energy produced
Efficiency
Energy used
How are these variables predicted? Hydraulic models, efficiency curves, cost curves, excel files, hydrological
models...
What is the benefit of this information? How is it used and for which purpose?
8.6.3.8 Water consumption
8.6.3.8.1 Domestic use
8.6.3.8.1.1 Current status
Which information is measured?
Current consumption (m³/h)
Cost (€/h)
What is the benefit of this information? Just billing?
8.6.3.8.1.2 Future status
Which information do you predict?
Consumption
Cost
How is this demand predicted? Using excel tables, a model, historical information, ...
What is the benefit of this information? Water sources management
Deliverable D4.1 – Decision supporting tools system requirements
116
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.3.8.2 Irrigation use
For irrigation, demand is more constant, do you speak with irrigation associations to negotiate supplied water? How
often? In case of water scarcity water provided is less?
8.6.3.8.2.1 Current status
Which information is measured?
Current consumption (m³/h)
Cost (€/h)
What is the benefit of this information? Just billing?
8.6.3.8.2.2 Future status
Which information do you predict?
Consumption
Cost
How is this demand predicted? Using excel tables, a model, historical information...
What is the benefit of this information? Water sources management
8.6.3.8.3 Industrial use
For industrial use, demand is more constant, do you speak with irrigation associations to negotiate supplied water?
How often? In case of water scarcity water provided is less?
Probably they just consume 8 hours per day in weekdays, and in summer less due to vacation, are these facts
taken into account?
8.6.3.8.3.1 Current status
Which information is measured?
Current consumption (m³/h)
Cost (€/h)
What is the benefit of this information? Just billing?
8.6.3.8.3.2 Future status
Which information do you predict?
Consumption
Cost
How is this demand predicted? Using excel tables, a model, historical information...
What is the benefit of this information? Water sources management
Deliverable D4.1 – Decision supporting tools system requirements
117
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.3.8.4 Recreational use
Do you have recreational use in the site? Description, current situation analysis and future scenarios, negotiation
with them...
8.6.3.9 Raw water suppliers management
How are they managed to provide water? Separately, all as a system...
Water consumers are taken into account? Is water distributed depending on the type of users (e.g. giving more
priority to domestic use than recreational)?
Are these suppliers interconnected (e.g. through channels, so they are counted as a system)
8.6.3.10 Drinking water suppliers management
Are drinking water suppliers managed together? If so, are all the WTP working at the same time? Which is the
priority to use one WTP or another one?
8.6.4 Stakeholder’ surveys
The collection of information has been concentrated on three basic aspects:
1. General information about the water supply, that should provide an overview about water governance,
structure of stakeholders, a description of the system and facilities currently associated with the water
management activity.
2. Information about the management strategies, considering long-term planning and short-term planning
and in particular the existence of integrated management strategies.
3. Information about the management rules for each of the elements of the system that could have an impact
over the objectives of the urban water system. The idea is to collect information about processes involved
in the running decision of key elements as dams, water treatment plants, distribution networks, etc.
The next sections describe in more detail the previous concepts and present the main conclusions and first ideas
related to the design of the SDSS.
8.6.4.1 General documentation about the water supply system:
The development/implementation of the SDSS Information should consider the existing structure of water
governance in a certain region and develop a way to adopt a generic approach that could be adaptive to several
potential scenarios/locations. The SDSS should provide information to several levels of decision makers,
stakeholders groups, and water uses. Over these specific requirements there is a set of existing polices and
legislation that define the roles and management strategies in a certain area and that are key elements to the
implementation of the SDSS.
The integration of the varied levels of users’ interests and existing policies makes the development and deployment
of a SDSS a complex task, thus its fundamental definition should be based on a generic and flexible approach that
allows for east adaptability.
Deliverable D4.1 – Decision supporting tools system requirements
118
URBAN-WATER PUBLIC
Grant Agreement: 318602
Finally is important to know the infrastructure related to the water management, which lately will be the components
over which decisions could be applied: water sources as aquifers and storage reservoirs, water quality nodes as
water treatment plants and wastewater treatment plants, water-related elements of infrastructures as pipelines,
canals and reservoirs. In a certain way the topology of these elements and their interconnections support and reflect
the current array of policies, user requirements, and management strategies.
In order to clarify the previous concepts several questions were presented to Scottish Water and Tavira Verde and
the answers are summarized in the following tables.
8.6.4.2 Information/description about the stakeholders/roles involved in the supply chain and responsibilities
Information/description about the stakeholders/roles involved in the supply chain and
responsibilities
Scottish Water Tavira Verde*
water suppliers, e.g. in charge of
reservoirs or ground water facilities
Scottish Water in Scotland Aguas do Algarve, integrated in
Aguas do Portugal
water utilities, in charge of water
distribution and treatment
Scottish Water in Scotland Aguas do Algarve (reservoirs,
water treatment plants), Tavira
Verde local network distribution
policy regulators Government, WICS, SEPA,
DWQR in Scotland **
ERSAR. State regulators
specific subcontractors for facilities
(water treatment plant, network
maintenance, etc.)
Scottish Water in Scotland Tavira Verde in Tavira
Municipality
consumers, consumers associations,
irrigation associations, etc.
Household, Non-household
(consisting of offices, shops,
factories, farms etc.) SW
provides Wholesale service to
Licensed Providers who
provide retail services to Non-
households (Business
Separation - Wholesale /
Retail)
There is one irrigation
association that gets the water
from the dams + Household,
Non-household in urban areas.
8.6.4.3 Information about the general management processes
The purpose of this section is to gather information about processes involved in the water management activities,
both in general terms (long and medium term planning) and specifically in the sort-term. The next table provides
the collected information.
Information about how is the general water management process organized
Scottish Water Tavira Verde
Long term: is there a long term planning
related to large infrastructures needs, design,
and future construction?
SW has 25 year strategic
plans and current future
Regulatory Period Plans i.e.
Mayor developments have
been focused in the the
Algarve Water Multi-
Deliverable D4.1 – Decision supporting tools system requirements
119
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about how is the general water management process organized
Scottish Water Tavira Verde
2010 to 2015 (current Reg
Period and 2015 to 2021 (next
Reg Period – Business
Planning currently underway)
municipal Water Supply and
Sanitation Systems was
launched at the end of 2002.
Medium term: is there a medium term
planning depending on:
Future general demand (next months?) In SW based on annual
planning assumption
Demand is analysed but is
quite stable and the system
was designed (2002) to
allow for the current and
future expected demand
Is seasonal demand considered? In SW more implicitly – e.g.
peak week / peak day
Yes , de to significant
differences between normal
and touristic season
(population is multiplied by
3)
Does the medium term management demand
consider requirements from different sectors
(urban, industrial, agriculture)?
In SW not explicitly Not Agriculture integrated
for TaviraVerde .
Information pending from
Aguas do Algarve
Does medium term management include
planning of which water sources will be used,
their contribution to the requirements and their
allocations?
In SW yes A protocol of exploitation of
water from reservoirs and
groundwater is established.
The plan and developments
sice 2002 has allowed to
concentrate resources in
damps (capacity to provide
water for various year with
no new water contribution)
Are maintenance activities included in this
management?
In SW yes Yes, primarily in WTW
How often is the medium term planning
updated? (monthly, seasonal, annually?)
“medium term planning” is
more over 5 / 6 year period –
in SW as Reg Periods
Anually Aguas do Algarve
Short-term: this is probably the aspect where
the SDSS can have the most significant
impact. Usually short-term management
implies a week or day-to-day analysis of
requirements from all the elements of the
water supply chain in order to match/optimize
the expected demand. It would be necessary
to have information about all the general
processes involved in the short-term
In SW currently not an explicit
integrated management, but
there are guidelines /
constraints dependent upon
water resources / Water
treatment systems etc.
In SW all of the areas are
taken into consideration when
managing the supply demand
Not an established protocol.
ADA motorize the level of
reservoirs and Tave the
WTW operation and daily
distribution of water. There
are automatic elements
(SCADA + EPANET) that
ensure the correct
Deliverable D4.1 – Decision supporting tools system requirements
120
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about how is the general water management process organized
Scottish Water Tavira Verde
management as for example an integrated
management that considers?
expected water requirements (urban,
industrial, hydropower, agricultural, etc.)
water extractions from collectors points
(reservoirs, underground, others).
water treatment activities.
water storage.
water distribution.
monitoring of leakages and planned actions.
situation – but there is not an
explicit IWRM system
currently in place.
SW refreshes the SDB yearly
and carry out updates to yields
etc. throughout the year such
that it always contains the best
information we have.
functioning of the
distribution.
In case of extraordinary
conditions (eg. Scarcity)
specific contingency plans
are applied together with
meetings of a decision
committee.
8.6.4.4 Specific information about the management of each of the elements
The definition of the SDSS requires a certain degree of information describing the basic process of decision
currently applied at each element of the water supply chain. Although the objective in WP4 is to develop a generic
SDSS that could allow a flexible implementation of processes that information might provide very useful material
about the nature and complexity of the present processes. The main collected information is presented in the next
table (some information from Aguas de Algarve I still pending to complete the scenario in the Tave site. It is
expected to be completed in the next months).
Information about the management of each of the elements
Scottish Water Tavira Verde
Reservoirs
General description of reservoirs available In SW will be made available
once validation site(s)
determined
Tavira Verder receives
water coming from the
Odeleite and Beliche
lagoons. Its maximum daily
production capacity is
190,000 m3, divided into two
95,000 m3 phases. These
reservoirs, consititute the
Odeleite-Beliche System,
interlinked since 1998, to
obtain an increased ability to
face water scarcity
situations and high demand
situations, supplying both
urban sector needs of
Algarve’s eastern area
(including tourism) and the
irrigation demand of an
important irrigation
Deliverable D4.1 – Decision supporting tools system requirements
121
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about the management of each of the elements
Scottish Water Tavira Verde
perimeter located outside
the Guadiana basin.
Are reserves evolution monitored and
forecasted?
In SW yes (see comments
below)
Yes, local measurements
(levels and precipitation)
Which kind of information is used to forecast
availability?
Specific historical statistical
trend and current
information from CEH
Wallingford and MetOffice
Basic information from the
Met office and the Agencia
Portugesa do Ambiente
Current meteorological information (evolution of
temperature, humidity, rainfall, other variables?)
In SW yes to most / all of the
questions
Yes, level and
meteorological stations from
the Agencia Portugesa do
Ambiente
Current hydrological information (measurement
of levels and flows into the reservoir basin, etc.)
In SW yes to most / all of the
questions
Primarily levels at the
reservoirs and water
transfer between reservoirs
Forecasted conditions of rainfall, humidity,
temperature, using numerical weather
prediction models?
In SW yes to most / all of the
questions
Basic information from the
National Met Office
Are there specific models to predict current and
forecasted conditions?:
In SW predictive models,
with some forecasting, but
some quite “generic” e.g.
weather forecasting
No models are used
Water balance due to temperature and humidity
evolution?
In SW – currently implicit,
but looking for UrbanWater
(Zagreb Uni) to help develop
more explicit model
No such model is runing
Hydrologic or hydraulic models to predict water
level evolution due to rainfall, snow melting, etc.
In SW yes – we have Water
Resources Mgt team who
have hydrology experts in
the team
No such model is running.
Water distribution uses an
Epanet model to define rules
operation of the netwrok
Are future forecasts of demand used as input to
asses water availability?
In Scotland yes In general term seasonal
demand is included in the
operation of the WTW
Is water allocation decided depending on the
demand source (urban, industrial, hydropower,
agriculture, others)? (sometimes large water
users as industrial and agriculture have special
rules/allocations negotiated in advance for the
whole year…)
SW is a Public Service
organisation, with an
obligation to make sure all
customers’ demands are
met – there maybe some
specific agreements – there
are certainly a number of
serviceability measures e.g.
water quality, pressure,
interruptions to supply etc.
Yes allocations are defined
in advance. Moreover in
case of scarcity a priority
system is applied for the
consumers.
Deliverable D4.1 – Decision supporting tools system requirements
122
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about the management of each of the elements
Scottish Water Tavira Verde
Are there specific usage allocations depending
on:
The state of reserves (urban water might have
priority over agricultural use).
The complementary use with other sources of
water (underground water, others).
The season of the year.
In SW only when there is a
supply demand imbalance –
in such instances, a process
is agreed with regulators and
all stakeholders are assisted
in using less water e.g. water
efficiency devices / support,
further leakage reduction,
information / guidance etc.
There is a list with the water
allocations ordered
depending on the priority
(drinking water, industrial,
irrigation, etc.). Thus
restrictions are first applied
to the last allocations of the
list. The amount of the
applied restrictions is
decided together between
reservoirs management
commission and other
stakeholders (WTP
manager, irrigation
associations, etc.). On the
other hand WTPs have their
own plan of contingencies
that could activate the use of
alternative sources as
existing boreholes
Are there specific protocols depending on
seasonal conditions:
Droughts periods.
Rainy periods.
General seasonal periods (winter, spring,
summer, etc.)
In SW yes – as comment
above
In SW if a severe winter then
there can be significant
increase in leakage – this
happened in 2009/10 and
2010/11 – such events lead
to Emergency Planning
procedures being introduced
e.g. increased human
resources, assisting
customers with private
incidents, delivering bottled
water etc.
Yes, droughts /seasonal
conditions are specifically
motorized through reports to
the ministry and (as
explained before)
contingency plans or
specific protocols in WTW.
Are environmental flows considered in the
reservoir?
Not available information Yes, environmental flows
defined for each reservoir
Information about the management of each of the elements
Scottish Water Tavira Verde
Underground water
General description of underground water
systems available
Some zones are a
combination of ground and
Tave underground water is
only used as a reserve
Deliverable D4.1 – Decision supporting tools system requirements
123
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about the management of each of the elements
Scottish Water Tavira Verde
surface water but there are
some areas wholly reliant on
groundwater. Most
operational borehole sites
are fundamental parts of the
yield for those zones and are
not just supporting in times
of need. Some sites have
good monitoring of levels,
some do not have any. We
do not have our own
groundwater models,
generally BGS do modelling
work on our behalf.
In general, how is underground water
regulated?
In SW generally not a big
element of water
resource – more used to
support resources when
resources are low /
demand is high
The responsible state
department
Are reserves evolution/inflows
monitored?
In SW yes
Yes, basically ground
water level
Which kind of hydrogeological information
is used to monitor and forecast reserves?
In SW records, models
etc.
basically ground water
level and comparison
with previous studies
Are there specific models to
monitor/forecast reserves?
SW do not have their own
models
No models are operated
Are there specific protocols depending on
seasonal conditions?
used to support
resources when
resources are low /
demand is high
Basically groud water is
used in case of scarcity
Is underground water allocation decided in
conjunction with reservoirs? (e.g. under
reservoirs low lever underground water is
used instead…)
In SW yes, as commented
above
Basically groud water is
used in case of scarcity
Unregulated flows
how unregulated flows are managed?
(flows not regulated by reservoirs are used
by agricultural use, industrial,
municipalities?)?
In SW – this is not SW
issue – SEPA will be
looking for all flows to be
regulated
There is no control of
unregulated flow but
they are very small
Deliverable D4.1 – Decision supporting tools system requirements
124
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about the management of each of the elements
Scottish Water Tavira Verde
Water treatment plant
General description of available water treatment
plants
In SW they vary – including
full treatment process, e.g.
filtration, clarification,
sedimentation, disinfection
etc. and also membrane
technology at some
locations. WQ leaving the
works is highly regulated /
tested – Regulator is DWQR
The water treatment plant at
TV includes full treatment
(biological, microbiological
and chemical nature), with
advanced processes during
the mud treatment line and
water treatment line (see
description and scheme of
the main elements at the
end of this section.
General description of daily inflow-outflow
management
Some treatment sites will
have storage on site so
works throughput can be
more steady state than
demand profile. Others use
in network storage to meet
variable demand
The water treated of TV is
for high-level distribution to
several counties that belong
to the Algarve Multi-
municipal Water Supply
System. In some scenarios
of scarcity the Reversible
Pumping Station is used to
obtain water from the
Sotavento Algarvio
How demand is considered in the general
operation of the plant
Regular conditions are
quite stable and seasonal
changes are absorbed
activating new production
lines in the WTW
Is demand forecasted or historical average
information is used?
In SW currently more the
latter – forecasting is more
implicit
Yes, it was used to define
WTW capacities
How is daily demand variations managed? In SW Water Treatment
Works on site clear water
tanks (storage reservoirs)
and/or in network service
reservoirs – usually capable
of holding 24 / 48 hours
storage to meet demand
Tanks and elevated tanks
and daily production are
programmed in order to
absorb daily variations
Is there a general reservoir/deposit to control
the demand requirements? Is its capacity
oriented to buffer several days of demand?
In SW - yes
Yes, several as explained
before
Is that reservoir oriented to fulfil the demand or
meet other requirements (e.g. provide a specific
pressure level for the distribution)?
In SW primarily meet
demand, but also to manage
pressure
Both
Deliverable D4.1 – Decision supporting tools system requirements
125
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about the management of each of the elements
Scottish Water Tavira Verde
Are there additional elevated deposits in the
urban area, or pumping systems to perform the
distribution?
In SW – on occasions e.g.
local elevated towers
Yes
How maintenance activities (filters maintenance
or others) could affect water treatment plant
operation.
In SW works are managed to
meet demand
Maintenance activities are
planned n order to avoid
restrictions
How water treatment plant water requirements
are connected to the water collector point status
(levels in reservoirs, underground water
availability)?
WTP are directly connected
to reservoirs so all required
water is allocated (unless
restriction conditions are
decided)
Is there a strategy in case of limitation of
allocations in the reservoir (low reserves,
drought, etc.)?
In Scotland yes
Yes, Aguas do Algarve
(summarized before)
Could varying characteristics of the water
coming from the reservoir (as turbidity, or
others) affect the performance of the water
treatment plant?
In Scotland yes – can be
more of a problem if water
resources are coming direct
from a river
WTPs include specific
treatment in such case
(applied through the SCADA
system)
Information about the management of each of the elements
Scottish Water Tavira Verde
Urban distribution
General description of the distribution
network (in the potential testing urban
environments: Edinburgh?, Tavira?):
deposits-reservoirs, pumping stations,
specific sectors of the network by districts,
etc.
In SW – validation sites still
to be determined – but will be
selected to include all / most
aspects of distribution. Will
have monitoring throughout
including District Meters
Areas – SW has 95%
coverage of DMAs
Reservoir connected to a
network
Existing management rules/routines on a
daily, weekly basis…
In SW, currently driven by
low risk of failing
serviceability e.g. generally
reservoirs kept “high”
Rules are extracted from the
EPANET simulation.
Is information from demand (historical or
from previous days) used as a base for the
operation of the network?
In SW implicitly
Yes in Tave implicitly
How water requirements are connected with
the water treatment plant:
EPANET simulation
Deliverable D4.1 – Decision supporting tools system requirements
126
URBAN-WATER PUBLIC
Grant Agreement: 318602
Information about the management of each of the elements
Scottish Water Tavira Verde
Are demand requirements transmitted to the
water treatment plant in order to modify the
treatment regime?
In SW currently know but it
has been acknowledged that
with 95% DMA coverage we
could use DMA data for
production planning, incident
mgt etc.
Not by Tave
In case of shortage due to problems in the
water treatment plant, are there specific
elements (large capacity of existing
deposits) or actions planned that allow to
prevent the situation?
In SW generally yes, but
explicitly for all systems
NO specifically, but
allocations can be modified
General management of pressure
distribution
In SW pressure
management is used
extensively to reduce /
maintain leakage – 50% of
network covered by PRVs –
now also installing PRVs on
trunk mains – AZP in SW c.
45 metres
Not general
General management of leakages (is there a
procedure to detect them and activate
specific protocols?).
In SW yes, full Active
Leakage Control Policy and
Procedures – SW now at
ELL
Yes
8.6.5 Tavira Verde documentation
The following pictures depict contingency plans defined by AdA:
Deliverable D4.1 – Decision supporting tools system requirements
127
URBAN-WATER PUBLIC
Grant Agreement: 318602
The following pictures describe EPANET hydraulic model:
Deliverable D4.1 – Decision supporting tools system requirements
128
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 13: Sotavento WDN
Figure 14: Barlovento WDN
Deliverable D4.1 – Decision supporting tools system requirements
129
URBAN-WATER PUBLIC
Grant Agreement: 318602
Figure 15: EPANET model detail in Tavira WTP
The following picture describes Tavira water distribution network topology and meters location:
Deliverable D4.1 – Decision supporting tools system requirements
130
URBAN-WATER PUBLIC
Grant Agreement: 318602
The following picture contains contributive basins of Funcho, Arada and Bravura reservoirs:
8.6.6 Scottish Water documentation
No information from SW is included because it is considered as confidential for SW and can therefore not be
included in the deliverable.
8.6.7 Others
This section includes other documents used to prepare the modules’ use cases, scenarios and requirements.
8.6.7.1 Data needs for identification of water demand & detailed indoor consumption
This document contains first ideas regarding WDPS and LDS.
Author: Mario Vasak (UNIZG-FER).
8.6.7.1.1 Task 4.1 – Water demand prediction system
Task 4.1 aims to develop a water demand prediction system for urban areas and to determine a novel detailed
indoor consumption model. Accordingly, Task 4.1 will focus on determining possible inputs that may be used in the
identification procedure of the water demand model, as well as on availability of historical data-bases for particular
inputs in the case-studies considered. Furthermore, it will combine correlation analysis and system identification
techniques on historical data bases to obtain a series of water demand prediction models that shall fulfil assessed
requirements on the decision support system. It will implement procedures for on-line model implementation and
for computation of prediction uncertainty based on varying input-data uncertainty. The task will yield algorithms for
on-line tuning of water demand models in selected model forms, based on newly coming water consumption and
other input data, and procedures for the detailed indoor consumption model on-line identification.
The outputs of this task will be: the demand prediction system requirements and design delivered jointly with all
decision supporting tools task in D4.1 (Month 6) and D4.2 (Month 9), D4.3 – Identification procedures for water
demand prediction models (Month 12) in D4.5 – On-line water demand prediction model implementation (Month
15) and in D4.8 – On-line identification procedure for the detailed indoor consumption model (Month 21).
Deliverable D4.1 – Decision supporting tools system requirements
131
URBAN-WATER PUBLIC
Grant Agreement: 318602
8.6.7.1.1.1 Data for water demand model for urban areas
Which data?
Water flow averaged over the period between two consecutive data records, with time stamps (detailed
below on the issues “which consumption?” and “how often?”)
Weather data profile with respect to time (temperature, precipitation, pressure, humidity, and possibly
other that is readily available without additional cost)
Electricity prices profile with respect to time
Data about public holidays in the calendar
Times of downstream flow incidents (e.g. times when certain pipe in the system was broken and under
repair).
Experience of water utilities should be used here – if they maybe spotted some other data not listed that strongly
correlates with water consumption.
For the touristic site very useful information would be the profile of registered touristic arrivals through the year –
however it is questionable would that historical data be available from the local tourist office and even more
questionable of whether such data would be available on-line. Without these data we can rely on pure time-
dependence of consumption, but tourism is very unpredictable business and variations from season to season
could be considerable and influential on the consumption – here a special emphasis would have to be put on on-
line model tuning to “learn” the current touristic site occupancy from recent past consumptions.
Which consumption?
Flow measurements should be done on entry points into disconnected branches of the distribution system. Their
number depends on which area we would like to use as test-site and should be discussed with water utilities asap.
How often?
Modelling can be done on various time-scales, but the most important question is what the model will be used for.
I see two possible uses:
matching water demand with water consumption to operate the distribution system (in terms of water
pumping and water buffering in distribution system storages) in an optimal way with the aid of spatial
decision support system in WP4,
using predicted water demand profiles for adaptive pricing in WP5,
and both of them would roughly require an hour time-scale as we currently see it, but this should be discussed with
WP leaders (HYDS for WP4 and ORGA for WP5). For an hour time-scale model we of course need data on a time-
scale of an hour or less.
Obviously we cannot influence the historical data bases – what is already in them cannot be made now denser in
time, but it should be given at our disposal. I presume that even denser time-stamps than hour time-scales are
available since the water utilities presumably monitor the flows on key points in the system via SCADAs and store
them.
How long in time?
The longer the better. A minimum would be to have one full year, but in touristic sites, as discussed above, this
could be problematic.
8.6.7.1.1.2 Data for detailed indoor consumption model
Detailed indoor consumption model should match the profile of water flow on the household water meter to the
characterisation of water usage (e.g. washing the dishes, toilet flushing, washing machine operation, watering the
garden, etc.). The major application of this model should be in serious games development in WP5 to facilitate
communication with the end-user – we should discuss this with SGI – do they need it and do they count on it?
Deliverable D4.1 – Decision supporting tools system requirements
132
URBAN-WATER PUBLIC
Grant Agreement: 318602
Which data and How often?
Water flow in individual household sampled very fast (e.g. every second or at least every 10 seconds)
Description of individual water uses with respect to time, matched with the water flow
Number of households considered
Presumably 10 in Scotland, 10 in Portugal, for a period of several months, would be enough. This would give large
enough base of data from which classification techniques could be developed. But, this seems to involve final users
for several months, meaning they would have to annotate the water usage with respect to time, which might be
very problematic and even if performed we cannot fully trust these data. The alternative would be to employ some
kind of non-invasive flow presence sensors (does such thing exist?) on all branches of the water distribution system
in the house, that is time-synchronised with the water meter and able to send information (presumably wirelessly)
when flow is detected and when is it not detected any more.
Frank (Orga) mentioned that individual water use profiles from some other project might be available (subject to
approval of the data owner) – this data may be interesting if it is accompanied with the usage characterisation, for
the approach of water usage characterisation. Otherwise, just time series of water flow won’t do much good.
Maybe there exists a misunderstanding that a detailed indoor consumption model represents the model for
prediction of water consumption of the individual household with respect to time and varying input parameters like
e.g. weather – Bill (SW) suggested on KOM to identify water consumption by different consumer categories
whereas data to support this could be gathered (the claim on such data availability should be cleared out with SW
and Tavira). The prediction abilities of such a model for one individual household would be very limited since on
the level of individual household a large uncertainty is present. The usage of such a model for that purpose would
also be questionable.
However, if this proves much more easily feasible and more useful in WP5 (see the comment below under adaptive
pricing), a get-away could be that we proclaim the model of consumption by consumer categories as “detailed
indoor consumption model”, but it’s a bit stretched. Perhaps, we should clear out this issue first – what we mean
under the detailed indoor consumption model and what would turn out to be the most useful for us in the project.
8.6.7.1.2 Task 4.3 – Adaptive Pricing System
Task 5.3 aims to develop a specification of a strategy for the adaptive water pricing that will use the water demand
forecast (Task 4.1) and water supply prediction (Task 4.2) together with the time of use (TOU), critical peak pricing
(CPP) and a set of charging mechanisms such as real-time rating and charging, interval billing and revenue,
requirements provided in Task 1.2 by the water utilities. A model of end-user consumption response to a certain
water supply price and to the price profile will be assessed as well. Optimization methods will then be put in place
to compute the water prices profiles that will ensure correct water supply system functioning and water savings.
Task 5.3 will also focus on determining input and output data formats as well as functional interfaces for adaptive
pricing, and a rule-based mechanism for notifications to enhance the transparency for end-customers.
The output of Task 5.3 is the adaptive pricing system requirements and design to be delivered jointly with all
customer empowerment tools task in D5.1 (Month 6) and D5.2 (Month 9), as well as D5.5 – Adaptive price system
implementation (Month 18) to be delivered in M18.
Data requirements to fulfil task 5.3 resides on the following issues to be discussed:
What should be the guiding principle in adaptive water pricing:
o assess the water price based on economic criteria, e.g. by quantification of energy-related cost
for system functioning with certain water consumption profile and of benefit of influence of
flattened water flow profile on the pipes and the environment
Deliverable D4.1 – Decision supporting tools system requirements
133
URBAN-WATER PUBLIC
Grant Agreement: 318602
o assess the water price based on a-priori determined favourable water flow (by SDSS?) where
prices are iteratively set through days until the desired water flow is not enforced
can the a-priori favourable water flow be defined based on water-energy nexus, the
preferable pressure profile through time etc.?
o Very different issues stem in the following two cases (is there an overarching principle to make
the water pricing developments in UrbanWater applicable to both?)
there is enough water in source of sufficient quality – water utility is not interested in
reducing water consumption
economic balance in terms of influence of more flat water consumption profile,
enforced by adaptive pricing, on the water distribution system should come on
top
water shortage endangers the source or not enough water of sufficient quality – water
utility is interested in reducing water consumption to evade water delivery problems and
related penalties
then there might arise the need to enforce certain a-priori given water profile through
adaptive pricing
Mode 1 – The same water price applied to all consumers in the test-site area?
o Applicable if currently water is priced in the same way to everybody
o The issue of end-user consumption with respect to water price profile mentioned in the DoW
should be moved to the cumulative consumption of the whole distribution area – and this sounds
more reasonable since the consumption of the individual user is subject to large uncertainty
Mode 2 – The same water price is applied to all consumers of the same type (household, industry...) in
the test-site area
o Requires to identify consumption by consumer types (this could be an alternative to detailed
indoor consumption as discussed on the Kick-Off Meeting – this one I think Bill suggested)
o The issue of end-user consumption with respect to water price profile mentioned in the DoW
should be moved to the cumulative consumption of certain category – and again this sounds
more reasonable since the consumption of the individual user is subject to large uncertainty
Mode 3 – Water price is applied individually to each end-user in the test-site area
o I believe this is out of the question, since it would lead to discrimination between “neighbouring
users” in the same usage category
o Individual consumption by end-users is subject to large uncertainty
o Each user would have to be equipped with water meter
o The scalability of the water pricing implementation comes into question since the water price
profile is computed separately for each user
Last but not least, for all modes -- how to enable adaptive water pricing in any form on test-sites from the
legal side, if currently fixed water price per m3 is in force (per user category?)?
o Arrangements should be agreed well on time with all stakeholders (user, utility, water authority,
local authorities... in fact all that are (financially) influenced with this)
o Especially for that reason the adaptive pricing should stem from economic criteria since we would
need to show that we are attaining better economic solution to all stakeholders (or for some of
them at least not worse)
Deliverable D4.1 – Decision supporting tools system requirements
134
URBAN-WATER PUBLIC
Grant Agreement: 318602
9 Annex III: reviewers comments
This section presents all the comments raised by the EC reviewers related to this deliverable in both revisions. For
each of their comments, a solution is proposed and the corrective action has been applied to this document.
9.1 First review comments (January 2014)
WP4 focuses on decision support system (DSS) focusing on tool design as well as demand prediction and leakage
detection procedures. (Review Comment RC_1) There is a great delay in submitting the first deliverable (4 months
later delivery). (RC_1) No explanation is provided explaining this serious delay. (RC_2) The quality of some
deliverables is not sufficient and 2 of 4 are rejected (D4.1 and D4.2). (RC_2) The approach taken is unsatisfactory
(e.g. requirements defined based on 2 questionnaires filled in) as well as number of significant information is
missing (e.g. tool architecture and dependencies, requirements are vague). So the objectives of this WP are not
met.
(RC_3) This deliverable was expected to provide system requirements for the decision support tool. Instead, the
deliverable provides an insight on the current status of the business requirements of pilot leaders. (RC_2) This
document by no means describes what the decision support tool should do. It just discusses what the pilot leaders
would like to do in the case of demand prediction, water availability prediction etc. (RC_3) There is no information
about availability of historical data-bases (see DOW, page 14), or supporting tools. (RC_2) No requirements are
listed.
9.1.1 Solutions / amendments
RC_1: The reason of the delay on submitting the deliverable was that the planning to define the
requirements was not realistic and water utilities didn’t give on time the necessary information to prepare
the deliverable.
RC_2: Deliverable D4.1 has been rewritten to include a complete analysis and more detailed information
from SW and Tave, including also which information is available currently for initial tuning of different
modules and their prospective on-line usage.
RC_3: New sections have been included in the deliverable D4.1 to specify all the requirements the
decision supporting tools should fulfill using a table template for each of them (see Sections 5, 6.1, 0, 0
and 0).
9.2 Second review comments (May 2014)
D4.1 identifies the requirements and the actors, and defines use cases of the decision support tool. Apart from that,
the deliverable provides a detailed description of the pilots with respect to decision support, which is very useful.
(Review Comment RC_1) This description is lacking the validation phase of the tool, and should be added.
(RC_1) ...based on the DSS requirements and design presented (D4.1 and D4.2) it is not clear how, and if,
validation is going to include adaptive pricing, demand estimation and management. It seems that information
required for this purposes will not be available at demo sites.
(RC_2) There is no information about the methodology to collect the requirements. (RC_3) A lot of requirements
are missing comparing to the design proposed in D4.2. (RC_1) Validation site in Portugal is not clearly presented.
Deliverable D4.1 – Decision supporting tools system requirements
135
URBAN-WATER PUBLIC
Grant Agreement: 318602
It seems that validation will only take into account upper part of water distribution network and will not deal with
lower parts – district areas and households. As a result it is not clear how UrbanWater aims to achieve objectives
on adaptive pricing, demand management and introducing changes to user behavior (it seems, that DSS will not
have access to household water consumption not to mention more detailed information on water usage).
9.2.1 Solutions / amendments
RC_1: A separate validation description document is provided in parallel to this revised version of D4.1.
Information regarding the site description that was included in the previous version of D4.1 has been
moved to the validation description document and will be part of deliverable D7.1. The validation
description document includes Tavira’s and Aqualia’s validation sites, which answers the doubts
concerning the validation exposed by the reviewers.
RC_2: Information regarding the methodology to collect the requirements has been added (see section
8). All the existing material (research articles, documentation, web pages, etc.) and meeting minutes used
to define the scenarios, use cases and requirements of each module are listed and part of this information
is included.
RC_3: A complete review of deliverable D4.2 has been done and missing requirements have been added
in this deliverable. It is important to remark that only the most relevant functional requirements are
described in this document. Other requirements (e.g. The WAPS module should be able to read csv files,
the WAPS module should be able to generate precipitation field images, the DSS physical view should
contain a viewer with water supply system elements placed over a Google maps layer, etc.) are not listed,
as the focus of this deliverable is not on detailed implementation-specific requirements.
Top Related