intelligent urban water management...

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


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


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


3

URBAN-WATER PUBLIC


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.


4

URBAN-WATER PUBLIC


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


5

URBAN-WATER PUBLIC


WDPS Water Demand Prediction System

WFS Web Feature Service

WMS Web Map Server

WRZ Water Resource Zone

WTP Water Treatment Plant


6

URBAN-WATER PUBLIC


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


7

URBAN-WATER PUBLIC


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


8

URBAN-WATER PUBLIC


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


9

URBAN-WATER PUBLIC


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


10

URBAN-WATER PUBLIC


9.1.1 Solutions / amendments ................................................................................................................ 134

9.2 Second review comments (May 2014) .................................................................................................. 134

9.2.1 Solutions / amendments ................................................................................................................ 135


11

URBAN-WATER PUBLIC


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


12

URBAN-WATER PUBLIC


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.

http://urbanwater-ict.eu/


13

URBAN-WATER PUBLIC


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


14

URBAN-WATER PUBLIC


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.


15

URBAN-WATER PUBLIC


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.


16

URBAN-WATER PUBLIC


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


17

URBAN-WATER PUBLIC


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


18

URBAN-WATER PUBLIC


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:


19

URBAN-WATER PUBLIC


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:


20

URBAN-WATER PUBLIC


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.


21

URBAN-WATER PUBLIC


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


22

URBAN-WATER PUBLIC


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


23

URBAN-WATER PUBLIC


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


24

URBAN-WATER PUBLIC


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.


25

URBAN-WATER PUBLIC


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.


26

URBAN-WATER PUBLIC


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


27

URBAN-WATER PUBLIC


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.


28

URBAN-WATER PUBLIC


Figure 5: Scheme of main concepts related to consumption management


29

URBAN-WATER PUBLIC


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:


30

URBAN-WATER PUBLIC


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.


31

URBAN-WATER PUBLIC


Figure 6: Schema of main concepts related to integrated water system management


32

URBAN-WATER PUBLIC


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:


33

URBAN-WATER PUBLIC


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.


34

URBAN-WATER PUBLIC


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:


35

URBAN-WATER PUBLIC


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.


36

URBAN-WATER PUBLIC


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).


37

URBAN-WATER PUBLIC


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


38

URBAN-WATER PUBLIC


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


39

URBAN-WATER PUBLIC


Adaptive pricing service

Service provider

Subscribed service

(Serious) gaming service

Subscribed service

Table 2: UrbanWater decision supporting tools actors


40

URBAN-WATER PUBLIC


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):


41

URBAN-WATER PUBLIC


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.


42

URBAN-WATER PUBLIC


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.


43

URBAN-WATER PUBLIC


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


44

URBAN-WATER PUBLIC


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)


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


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


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


45

URBAN-WATER PUBLIC


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.


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


UW platform


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


5.2.6 Display the topology of the water supply system representation

Identifier UC-SDSS-DisplayLogicalModel


46

URBAN-WATER PUBLIC


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



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



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


47

URBAN-WATER PUBLIC


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



48

URBAN-WATER PUBLIC


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-


Remark

5.3.3 Retrieve leakages detection


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-


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-


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 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


49

URBAN-WATER PUBLIC


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 The SDSS should be able to modify its configuration


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 The SDSS must be able to calculate a new SDSS status


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 SDSS should be able to calculate a new status based on a testing configuration




50

URBAN-WATER PUBLIC


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 The SDSS must be able to locally store its status within the SDSS


ComputeOnlineStatus

UC-SDSS-


Remark -

5.3.10 Provide SDSS status


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


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 The SDSS must be able to display the water supply system physical model


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.


51

URBAN-WATER PUBLIC


5.3.13 Send notifications through the platform


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-


Remark -


52

URBAN-WATER PUBLIC


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.


53

URBAN-WATER PUBLIC


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


54

URBAN-WATER PUBLIC


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.


55

URBAN-WATER PUBLIC


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


UW platform notification service.


56

URBAN-WATER PUBLIC


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


Use Cases All use cases


57

URBAN-WATER PUBLIC


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 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



Remark -

6.1.3.3 Adaptation to demand changes


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


Remark -

6.1.3.5 Ability of automated initialisation


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 -


58

URBAN-WATER PUBLIC


6.1.3.6 Cooperation with other modules


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



Remark The subsequent designs must well encompass these interactions.

6.1.3.7 Responsive to other modules’ outputs


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


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


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.


59

URBAN-WATER PUBLIC


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


60

URBAN-WATER PUBLIC


Actors DICM


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


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


Remark -


61

URBAN-WATER PUBLIC


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


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.


62

URBAN-WATER PUBLIC


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.


63

URBAN-WATER PUBLIC


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


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.


64

URBAN-WATER PUBLIC


Trigger Every time new data is available

Priority Mandatory



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


65

URBAN-WATER PUBLIC


Remark -

6.3.3.3 Retrieve precipitation from NWP data


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 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 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 WAPS should be able to quality control radar precipitation estimates


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


66

URBAN-WATER PUBLIC


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 The WAPS must calculate 6 hours of radar nowcasting (precipitation forecasting).


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 The WAPS must be able to calculate rainfall accumulation fields using radar

instantaneous estimates (both observed and forecasted by nowcasting techniques).


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.


67

URBAN-WATER PUBLIC


6.3.3.9 Calculate accumulations from rain gauges


Requirement The module should be able to calculate 1hour accumulations using rainfall

information from rain gauges


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 The module should be able to combine radar precipitation fields and rain gauges

information to generate more accurate precipitation fields


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 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


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


68

URBAN-WATER PUBLIC


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 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.


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 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 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.


69

URBAN-WATER PUBLIC


6.3.3.15 Send notification: new short-term water availability prediction available


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 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.


70

URBAN-WATER PUBLIC


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”.


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.



71

URBAN-WATER PUBLIC


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.


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).


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).


72

URBAN-WATER PUBLIC


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


73

URBAN-WATER PUBLIC


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


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)


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


UW platform

Cloud database


74

URBAN-WATER PUBLIC


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


Trigger Periodical routine OR

Water distributor decision

Priority Optional

Actors LDS


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


UW platform


75

URBAN-WATER PUBLIC


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)


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


Trigger WD decision

Priority Optional

Actors LDS


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


Remark -

6.4.3.2 Retrieve pressure data


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


Remark -

6.4.3.3 Retrieve topology data



76

URBAN-WATER PUBLIC


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 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 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 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


Remark -

6.4.3.7 Calculate and provide leakage with Mass Balance


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.


77

URBAN-WATER PUBLIC


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 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 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 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 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.


78

URBAN-WATER PUBLIC


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 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


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 -


79

URBAN-WATER PUBLIC


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.


80

URBAN-WATER PUBLIC


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


81

URBAN-WATER PUBLIC


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.

http://www.apambiente.pt/


82

URBAN-WATER PUBLIC


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


83

URBAN-WATER PUBLIC


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


o Tave:



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


84

URBAN-WATER PUBLIC


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:


EPANET model with hydraulic rules incorporated



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.


85

URBAN-WATER PUBLIC


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:


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:


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:

http://www.jbug.jp/trans/jboss-rules3.0.2/ja/html/ch01s02.html

http://www.jbug.jp/trans/jboss-rules3.0.2/ja/html/ch01s02.html

http://herzberg.ca.sandia.gov/

http://www.jboss.org/drools

http://openrules.com/


86

URBAN-WATER PUBLIC


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:


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


87

URBAN-WATER PUBLIC


(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:


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


88

URBAN-WATER PUBLIC


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:


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.

http://www.wrcplc.co.uk/

http://wrcplc.co.uk/Data/Sites/1/GalleryImages/WebImages/pdfs/identiflowflyer08.pdf


89

URBAN-WATER PUBLIC


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.

http://www.nist.gov/itl/


90

URBAN-WATER PUBLIC


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


o Tavira Verde:

Contributive basins

Distribution network topology

Existing public information from web pages:

o SW:

SW home page (http://www.scottishwater.co.uk/)


o Tavira Verde:

Tavira Verde home page (http://www.taviraverde.pt/)



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.


91

URBAN-WATER PUBLIC


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:


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


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:


o Tavira Verde:

Instituto Portuguès do Mar e da Atmosfera (IPMA) (http://www.ipma.pt/)



92

URBAN-WATER PUBLIC


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:




0 WAPS requirements

Type of requirements Water availability calculation requirements

Used information

INPUT:


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:



93

URBAN-WATER PUBLIC




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


94

URBAN-WATER PUBLIC


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


95

URBAN-WATER PUBLIC


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


96

URBAN-WATER PUBLIC


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.


Name Company



António Chaves Ramos [AC] Tavira Verde [Tave]

Helena Lucas [HL] Águas do Algarve [AdA]


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.


97

URBAN-WATER PUBLIC


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.


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.


Name Company



Albert Rodriguez [AL] Ateknea Solutions Catalonia [ASC]

Andrés Cisneros [AC] Ateknea Solutions Catalonia [ASC]


98

URBAN-WATER PUBLIC



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.


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:


99

URBAN-WATER PUBLIC


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.


Name Company



Rafael Sanchez-Diezma [RS] HYDS


Caroline Olbert [CO] Scottish Water [SW]

Owen Bramwell [OB] Scottish Water [SW]


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.


100

URBAN-WATER PUBLIC


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.


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


101

URBAN-WATER PUBLIC


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.


Name Company


Rafael Sanchez-Diezma [RS] HYDS

Antonio Chaves [AC] Tavira Verde [Tave]

Pedro Coelho [PC] Agencia Portuguesa de Ambiente [APA]


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.


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


102

URBAN-WATER PUBLIC


8.6.1.6 2013/01/24 – Meeting with Tavira Verde


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


Name Company

António Chaves Ramos [AC] Tavira Verde [TAVE]

José Florentino [JF] Tavira Verde [TAVE]




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


103

URBAN-WATER PUBLIC


8.6.1.8 2013/11/04-05 – Meeting with Scottish Water


Name Company


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]



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


104

URBAN-WATER PUBLIC


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.


105

URBAN-WATER PUBLIC


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.


106

URBAN-WATER PUBLIC


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?


107

URBAN-WATER PUBLIC


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?


108

URBAN-WATER PUBLIC


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?)


109

URBAN-WATER PUBLIC


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.


8.6.3.3.2 Rivers

8.6.3.3.2.1 Current status of the river

Which variables do you measure?


110

URBAN-WATER PUBLIC


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.


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.


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?


111

URBAN-WATER PUBLIC



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)?


112

URBAN-WATER PUBLIC


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)



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...


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...




Inflow (m³/s)

Outflow (m³/s)


113

URBAN-WATER PUBLIC


Water quality (ph) (inflow and outflow)

Raw water storage volume (m³)

Drinking water storage volume (m³)

Energy used (w)



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...


8.6.3.5.3 Wastewater treatment plants

General description, variables measured, variables predicted, how are them predicted


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



Pressure (hPa)

Flow (l/s)

Level (cm)


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...


114

URBAN-WATER PUBLIC



Is there a hydraulic model (like EPANET) or distribution model to predict future status of the pipes?


Pressure

Flow

Level


8.6.3.6.2 Valves


Inflow

Outflow

Pressure

Level?


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)



Level

Pressure

Storage volume

Inflow

Discharge/outflow




Level

Pressure

Storage volume

Inflow

Discharge/outflow

How are these variables measured? Hydraulic models (EPANET), distribution model, excel tables...



115

URBAN-WATER PUBLIC


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)



Water diversion rate (m³/s)

Energy produced (watt)

Efficiency (%)

Energy used (watt)




Water diversion rate

Energy produced

Efficiency

Energy used

How are these variables predicted? Hydraulic models, efficiency curves, cost curves, excel files, hydrological

models...


8.6.3.8 Water consumption

8.6.3.8.1 Domestic use


Which information is measured?

Current consumption (m³/h)

Cost (€/h)

What is the benefit of this information? Just billing?


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


116

URBAN-WATER PUBLIC


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?




Cost (€/h)




Consumption

Cost

How is this demand predicted? Using excel tables, a model, historical information...


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?




Cost (€/h)




Consumption

Cost

How is this demand predicted? Using excel tables, a model, historical information...



117

URBAN-WATER PUBLIC


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.


118

URBAN-WATER PUBLIC


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-


119

URBAN-WATER PUBLIC




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


120

URBAN-WATER PUBLIC




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


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


121

URBAN-WATER PUBLIC




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.)


questions

Primarily levels at the

reservoirs and water

transfer between reservoirs

Forecasted conditions of rainfall, humidity,

temperature, using numerical weather

prediction models?


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.


122

URBAN-WATER PUBLIC




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



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


123

URBAN-WATER PUBLIC




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


124

URBAN-WATER PUBLIC




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


125

URBAN-WATER PUBLIC




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)



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


126

URBAN-WATER PUBLIC




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:


127

URBAN-WATER PUBLIC


The following pictures describe EPANET hydraulic model:


128

URBAN-WATER PUBLIC


Figure 13: Sotavento WDN

Figure 14: Barlovento WDN


129

URBAN-WATER PUBLIC


Figure 15: EPANET model detail in Tavira WTP

The following picture describes Tavira water distribution network topology and meters location:


130

URBAN-WATER PUBLIC


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).


131

URBAN-WATER PUBLIC


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?


132

URBAN-WATER PUBLIC


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


133

URBAN-WATER PUBLIC


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)


134

URBAN-WATER PUBLIC


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.


135

URBAN-WATER PUBLIC


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.

intelligent urban water management...

Documents