Project Title: Intelligent Urban Water Management...

Project Title: Intelligent Urban Water Management System

Project Acronym:

Seventh Framework Programme Collaborative Project

Grant Agreement Number 318602

Subject:

D1.2 - User Requirements in the Water Market

Dissemination Level: Public Lead Beneficiary: Scottish Water

Revision Preparation date Period covered Project start date Project Duration DRAFT/v01-v08 Month 04 - 06 Months 02 to 06 Month 12-2012 30 Months

FINAL Month 08 Months 02 to 08 Month 12-2012 30 Months

2

URBAN-WATER Grant Agreement: 318602

Table of Contents 1 Introduction ...................................................................................................................................3 2 Research Method...........................................................................................................................4 3 Water Utility User Requirements.......................................................................................................6

3.1 Water Resources: Sustainable, effective and efficient management of water resources ......7 3.2 Raw Water Transfers: Effective and efficient transfer of raw water from source to treatment to deliver optimal supply management ...........................................................................9 3.3 Water Treatment: Utilising the most effective and efficient treatment works / process streams to deliver optimal supply management ............................................................................ 10 3.4 Transmission System: Effective and efficient transmission of potable water from treatment works to consumption points to deliver optimal supply management ............................................ 11 3.5 Demand: Monitor and forecast demand to inform Integrated Water Resources Management System to facilitate optimal supply management .................................................... 12 3.5.1 District Meter Areas (DMAs): To inform current and historic consumption demand profiles and provide data for leakage management ................................................................................... 13 3.5.2 Per Capita / Household Consumption (PCC / PHC): To inform current and historic Household consumption demand profiles ...................................................................................... 15 3.5.3 Leakage: To monitor and report leakage to facilitate leakage management at the Economic Level of Leakage to facilitate optimal supply management ............................................ 16 3.6 Systems Requirements ..................................................................................................... 17

4 Public Authority User Requirements ................................................................................................ 19 4.1 Public Authority Models ....................................................................................................... 19 4.2 Online Survey Response From Public Authorities .................................................................. 19

5 Customer User Requirements ........................................................................................................ 22 5.1 Accessing the System ........................................................................................................... 22 5.2 Gaming ................................................................................................................................ 23 5.3 Adaptive Pricing ................................................................................................................... 23 5.4 Automatic Billing .................................................................................................................. 24 5.5 Customer Segmentation ................................................................................................... 24 5.6 Customer User Requirements - Pull ...................................................................................... 24 5.7 Customer User Requirements - Push .................................................................................... 26 5.8 Water Efficiency ............................................................................................................... 26 5.9 User Requirements – Survey Findings ............................................................................... 28

6 Software Provider User Requirements............................................................................................. 30 6.1 Section 1: Secure Access to the Required Data-sets .......................................................... 30 6.2 Section 2: Query the Data-sets Effectively and Efficiently ..................................................... 30 6.3 Section 3: Using Open Standards .......................................................................................... 30 6.4 Section 4: Scalability and Reliability ...................................................................................... 32 6.5 Use Cases ............................................................................................................................. 32 6.6 Urban Water Platform Use Cases.......................................................................................... 34 6.6.1 Secure Data Access Use Case ............................................................................................ 34 6.6.2 Query the Data-sets Effectively and Efficiently ................................................................. 35 6.6.3 Open Standards Use Case ................................................................................................. 36 6.7 Requirements ....................................................................................................................... 37 6.7.1 Software Provider Requirements...................................................................................... 38

3


1 Introduction

The need for water poses a series of challenges world-wide, including many areas of Europe. Water scarcity and the occurrence of droughts (WS&D) are increasingly becoming a concern in the European Union (EU) as already recognized by the European Environmental Council (EEC): ‘water scarcity and drought are already a very serious problem in many European regions and the situation is expected to worsen as a consequence of climate change and, if not appropriately addressed, increasing water demand’. As part of the Resource Efficiency Flagship Initiative of the Europe 2020 strategy, the European Commission (EC) planned to review the EU Water Policy by 2012 in order to address these tremendous challenges and promote efficient and sustainable management of water resources. In line with this, the EEC has stressed the need to ‘promote tools and solutions for Member States to cope with water scarcity and hydrological extreme events, such as drought’, inviting the EC “to consider the right mix of measures and financial instruments needed to tackle water scarcity and drought events and to present relevant proposals if appropriate”. Water management enabled by ICT (Information Communications Technology) is a new and promising area with the objective to integrate real-time knowledge on demand and supply across water distribution networks and water sources. The objective of this project is to develop ICT for effective and efficient water resources management. The project will be delivered by partnerships between ICT equipment providers, software companies, water utilities and water utility companies. The partner organisations are;

Centre de Recerca i Innovació de Catalunya S.A. CRIC Scottish Water SW Sagemcom SAGEM Hydrometeorological Innovative Solutions HYDS University of Zagreb UNIZG-FER Red Skies Software RED Orga Systems ORGA Serious Games Interactive SGAMES AQUALOGUS Engenharia e Ambiente AQUA

The targeted outcome is to develop ICT-enabled solutions for integrated water resources management (IWRM), involving as key building blocks: innovative demand management systems, decision support systems and data management technologies. The proposed ICT solutions shall involve robust and proven technologies permitting a holistic approach towards IWRM, and possibly include new data management technologies with real-time predictive capability demand forecasting, advanced metering, real-time communication of consumption patterns, adaptive pricing, and/or combined energy and water management schemes.

4


2 Research Method

The purpose of Task 1.2 (User Requirements Collection) is to explore users’ requirements in relation to the use of an ICT system for integrated water resources management. The main research method used was a specifically designed on-line survey that targeted the four agreed User Groups, namely;

Customers, Water Utilities, Public Authorities, and Software Providers.

Figure 1 below presents the % of responses from each of the User Groups.

Figure 1 – % of Responses for Each User Group In addition, the expertise of the partner organisations and individual experts within the partner organisations was sought to add further value to the review. Although all partners had the opportunity to input expertise, the input from Red Skies (Software Providers) and Scottish Water (Customer, Water Utility and Public Authority) was of particular value as both organisations are well integrated into their respective sectors and have undertaken or been involved in a number of relevant research activities. The aim of the task is to record users’ patterns in water usage / service requirements (customers), best practice in water resources management / water / supply / distribution (water utilities and public authorities) and software services out-sourced by water utilities (software providers). This builds on a preliminary analysis on data requirements which had been previously been performed (Annex A of UrbanWater proposal). The on-line survey was designed and implemented by the consortium, led by Scottish Water, with significant input from CRIC and Red Skies. Following a reasonable period of investigation and survey development, Scottish Water procured the online survey services of Survey Gizmo, a recognised on-line survey company with the appropriate data security agreements and processes and who could provide a fully integrated survey / data collation service. The on-line survey went live in mid-February 2013 and was closed down early July 2013. Throughout the “live” period, the incoming survey returns were monitored continuously, with a high level analysis shared with all consortium partners. Following closure of the online survey, a detailed analysis was undertaken and presented to the consortium

5


partners. Responses were received from respondees in a number of Countries (Figure 2) and the results of the survey inform the major content of this report.

Figure 2 – % of Responses for Each Country At the point when the online survey was closed down the consortium were satisfied with the levels of response for Customers, Water Utilities and Software Providers, although it is acknowledged that increased confidence in the survey results for the Public Authorities User Group would be likely if more users within this group had responded to the survey. Although not thought critical as there was a relatively consistent response from the respondees within this group, as indicated in the proposal, follow-up interviews may be held by telephone if it is felt necessary to do so. This report (User Requirements in the Water Market - Deliverable 1.2) is the output from this task.

6


3 Water Utility User Requirements

The Water Utility requires the system to allow water resources to be managed effectively and efficiently. The Water Utility is responsible for ensuring all customer consumption is supplied at the least cost, balancing serviceability, cost and risk, and is responsible for ensuring the supply demand balance is managed pro-actively. Leakage is to be managed at the Sustainable Economic Level of Leakage (SELL), considering both short-run and long-run costs and the value placed on social and environmental elements of the communities supplied. Ideally, Water Utilities would look for fail-safe, automated, integrated water resources management systems, however as both the network and users are dynamic, and can be accidentally impacted by outside agents, there is a need for interactive use of any system to allow for planning of network changes e.g. treatments work outage, transmission main repairs etc., and also for scenario testing e.g. sensitivity testing of weather / demand relationships, consumption growth forecasts etc. The following Figures (Figs 3, 4 & 5), indicate the variation in demand parameters over different time periods as determined by water utility respondees.

Figure 3 – Responses to Survey Question 19


7


Figure 5 – Responses to Survey Question 21 As such, in addition to running on-line with “real-time” data inputs, the UrbanWater Integrated Water Resources Management System will need to be able to be run “off-line”, with the facility to change key input parameters and modelling assumptions to test planning and scenario options. The water utilities requirements have been split into the different stages of water production from “Source to Tap” because they require a platform that encompasses all of these stages. As outlined in the Research Method (Section 2), the Water Utilities Requirements have been built up using the expertise of Scottish Water and the feedback of the Water Utilities User Requirements Survey.

3.1 Water Resources: Sustainable, effective and efficient management of water

resources

Water resources are managed by water utilities to ensure there is an available supply ready for treatment, storage and distribution to supply customers. They include;

Impounding Reservoirs Rivers Groundwater / Boreholes Seawater (for desalination) Other / temporary resources e.g. tankering

In addition to ensuring there is sufficient volume of water available, in the short, medium and long-term, the quality of the raw water is also important as this will impact on water treatment capability and cost. The catchment areas from which the raw water is collected need to be managed to ensure optimum collection rates and storage, and also minimal risk of contamination e.g. agricultural spillage, vegetation / animal carcass infestation etc. The data / information used to manage water resources, includes, but may not be limited to;

Impounding Reservoirs Capacity Level (max, min, actual) Bathometric information

8


Inflows (max, min, actual) Outflows (max, min, actual Reservoir Control Curves Rainfall (max, min, actual) Temperature (evaporation) Water Quality Costs Historic performance, constraints, rules and guidelines

Rivers River Flows (max, min, actual) Compensation flows Inflows (max, min, actual) Outflows (max, min, actual) Abstraction flows (max, min, actual) Rainfall Water Quality Costs Historic performance, constraints, rules and guidelines

Groundwater / Boreholes Level (max, min, actual) Pump duties (lift / flow rates) Flows (max, min, actual) Inflows (max, min, actual) Outflows (max, min, actual) Water Quality Disinfection options / needs Disinfection costs Costs Historic performance, constraints, rules and guidelines

Seawater (Desalination) Plant capacity Throughput rates (min, max, actual) Throughput costs (all costs to “Water into Supply” point e.g. works output meter) Historic performance, constraints, rules and guidelines

Other / Temporary Input volumes (max, min, actual) Input costs Input options e.g. tankering, temporary boreholes, bulk supplies from 3rd Parties, Cross

Border transfers etc. Historic performance, constraints, rules and guidelines

Figure 6 below presents the water utilities assessment of the potential to improve water supply management due to an improved understanding of water supply capacity.

9



3.2 Raw Water Transfers: Effective and efficient transfer of raw water from source

to treatment to deliver optimal supply management

Raw Water is transferred from the water resource sites by pipelines / conduits, either under gravity or with the aid of pumping. At this stage it is not essential that the transfer pipelines are closed / fully pressurised as the water is yet to be treated. For example, river transfers and open aqueducts are sometimes used for raw water transfer. However, it is important that the raw water quality is not unduly affected e.g. contamination, as this may make treatment difficult or impossible. The data / information used to manage raw water transfers, includes, but may not be limited to;

Abstraction Point Flow (max, min, actual) Historic performance, constraints, rules and guidelines

Transfer type Pipe (gravity) Pipe (pumped) Aqueduct River transfer Open channel

Flow rates Maximum Minimum Constraints

Pumps Lift / flows Energy costs

10


3.3 Water Treatment: Utilising the most effective and efficient treatment works /

process streams to deliver optimal supply management

Water Utilities are responsible for ensuring that all water supplied by them is potable and meets the appropriate water quality standards at all times. As such, before being put into supply, water utilities treat the raw water to the appropriate standard. Dependent upon the source and quality of the raw water, the water utility will apply one or more of a number of different / collaborative treatment processes, ranging from simple disinfection for some groundwater / borehole supplies to complex filtration / clarification processes for some river waters.

Each of these processes will be carefully applied and managed to ensure the end product meets all necessary standards. Potable water supply treatment is now seen my many as a health / food product process, needing to meet the highest standards of quality for the product as it leaves the treatment site.

The data / information used to manage the treatment process, includes, but may not be limited to;

Raw Water Availability (max, min, actual) Raw Water Quality (a), (b) etc. Throughput

Process A Process B ………….

Costs (Operational) Constraints e.g. rate of change of treatment rate Waste/Losses (Process Losses) Sludge Management options Energy

Consumption Rates Profiles Costs

Chemicals Consumption Rates Profiles Costs

Sludge Production rates Profiles Costs

Clear Water Tanks Maximum Level Actual Level Actual level Max Capacity Volume / level cords

From the survey water utilities have indicated they have approximately 90% of their production system metered, which could be utilised by an IWRM system.

11


3.4 Transmission System: Effective and efficient transmission of potable water

from treatment works to consumption points to deliver optimal supply

management

Once treated, the water either goes directly into supply to meet demand or replenish service reservoir stock in the system, or it may go into a Clear Water Tank (on-site treated water reservoir) at the treatment site to be available to meet future demand.

Leaving the site, the water can either go into a gravity fed system i.e. to feed demand that is at a lower elevation than the water treatment works, or it can go into a pumped system i.e. to feed demand that is at a higher elevation than the water treatment works.

Once it has left the works the water is never open to open atmosphere, remaining in a pressurised, close-pipe system to meet the hydraulic requirements of the system and to ensure there is no / minimal risk of ingress which could impact on water quality. When stored in service reservoirs, they are also protected e.g. sealed roofs and access chambers, so as to also minimise any risk of contamination.

Being in a pressurised network which will consist of aged pipes with flexible joints and fittings, there is a risk of leakage from the transmission system, although this tends to be relatively small when compared with the level of leakage from the distribution network (in this model – pipework within DMAs). Leakage is monitored and managed so as to maintain an economic level of leakage. This will require speedy fix of reported / known bursts and Active Leakage Control (ALC) to find and fix otherwise invisible, underground leaks which are economic to repair. At such times the network shut-offs are so managed to retain the integrity of the network.

The data / information used to manage the transmission system, includes, but may not be limited to;

Supplied by Water Treatment Works A, B, C, ,,,,,, Links between transmission lines / systems In Network Service Reservoirs

Location Maximum Capacity Levels / Volumes Link with transmission line(s) / systems Ref Number / Name

DMAs supplied by transmission lines / systems / service reservoirs Location Ref Number / Name

Type of transmission line / system Gravity Pumped

Capacity of transmission line / system Maximum Minimum Constraints

Pumps Lift / flows

12


Energy costs Links with transmission line(s) / systems

From the survey water utilities have indicated they have approximately 85% of their transmission system and 90% of their distribution system metered, which could be utilised by an IWRM system.

3.5 Demand: Monitor and forecast demand to inform Integrated Water Resources

Management System to facilitate optimal supply management

Of the Water Utilities who responded to the survey, on average each company has approximately 85% of their consumption metered. Throughout Europe, it is claimed that 100% of customers are metered, but in the UK while 100% of non-household customers are metered, there is a wide variation of metering of household customers. For unmetered households, the water utilities have Household Consumption monitors, which inform them of demand to the unmetered customers. As such, in general water utilities are aware of the demand from their customers, which is a fundamental requirement of the system to be developed for the Urban Water Project. Figure 7 below presents the water utilities belief that better understanding demand has the potential to improve water supply management.

Figure 7 – Responses to Survey Question 23 Water utilities should use demand data / information to inform management decisions to reduce demand and to optimise water supply management. The survey indicated the major element of demand came from household use, followed by leakage and then non-household. For a system to help water authorities reduce demand it would therefore require a focus on household demand, leakage and then non-household demand. From the survey, the water utility respondees have indicated they believe the biggest potential reduction in demand from an ICT based system would come from Leakage (average 21% reduction), household (16% reduction) and non-household (15% reduction) which aligns well with split of demand. The importance in reducing demand to Water Utilities cannot be under estimated with half of Water Utilities surveyed saying that they experience some water shortages during the season of peak demand (Figure 8).

13


Figure 8 – Responses to Survey Question 22 In addition to these significant elements of consumption, as referenced above, all water utilities will have leakage within their water supply system, which will typically be in the range of 15% to 30% of the water put into supply. In certain circumstances leakage might be outwith this range. Leakage management is covered elsewhere in the project team (WP 4).

3.5.1 District Meter Areas (DMAs): To inform current and historic consumption

demand profiles and provide data for leakage management

In Scotland (UK in general), DMAs are used for leakage monitoring and reporting and the targeting of leakage management activities. DMAs are hydraulically defined areas of the distribution network, supplied by one or more meters. The number and type of users in each DMA are known and their demand / night use is known, either from measurement or modelling / estimation. Analysing the Night flows and night-use allowances, the water utility is able to calculate leakage for that defined area.

15 minute flow and pressure data is provided from the meters via loggers into servers using wireless communications and for this project (Intelligent Urban Water Management System), this data and other network flow and pressure data is to be used to inform historic, current and future demand from customers (Scotland Validation).

Scottish Water has c. 95% of all customers covered by DMAs and c. 90% of customers are within fully operational DMAs (operational for leakage management) at any time. There are c. 3,200 meters supplying c. 2,800 DMAs in Scotland.

DMA Logger Set-up

Loggers are programmed in the office & Radcom database entry created which contains the logger sim card phone no.

Loggers are installed on site, connected to flow meter & start recording flow readings at pre-determined intervals, usually every 15mins.

Logger memory holds values recorded, at 15min sample frequency a typical Radcom logger will hold approx 500days of data before either re-writing over early data or stopping record process.

Loggers dial into Radcom server at pre-determined intervals, usually every night, and upload the data contained within the logger, usually in .SLI format.

14


Depending on logger type they can communicate either by GSM, GPRS or SMS. Loggers are usually tied to one mobile network operator although there are loggers which can select the network with best signal.

Data is stored on Radcom servers at which point it can be viewed in many formats, the most common format being .CSV.

Depending on the system, this data is then imported into a leakage management program (SW has a few more stages due to legacy systems) which can use the flow data to generate net flow balances (inflows minus outflows) & make an assessment on leakage levels (net flow minus demand components)

The above is the ideal scenario, although there may be issues e.g. in rural areas there can be poor network signal strength, although this can sometimes be overcome by using larger aerials, network hopping loggers & above ground logger kiosks.

Loggers typically have two batteries, one which is used to power the logger memory & the other which powers the modem, generally the modem battery will die first and the logger will no longer upload any data. The data is still being recorded however as the memory battery usually still has charge, the logger then needs to be removed from site, the data downloaded in the office & uploaded to the Radcom system. The logger is then sent off for repair / replacement of the battery. Batteries tend to last around 4-5years although this can be reduced by factors such as low temperature & poor network signal.

The other scenario used in data collection for DMAs is having a telemetry outstation collect the data. This is performed in a similar fashion but generally outstations send the raw data through phone lines. Outstations tend to be more reliable but are more expensive and as such are usually used at large installations e.g. Service Reservoirs, Water Treatment Works etc. The added reliability stems from the fact most are powered by mains electricity and don’t have to rely on good mobile phone signal strength.

Once the data from the many DMA meters has been imported into a leakage management program there are numerous calculations performed on it. Demand components are removed from the netflow e.g. household demand, non-household (industry/commerce) demand, Distribution System Operational Use (water used by the water utility to maintain supply / quality etc.), legitimate network use (fire service etc), illegal network use (illegal connections, hydrant blow outs etc). Once these components are stripped away from the netflow derived from the loggers / telemetry all that is left is leakage (burst losses & background leakage). Due to the massive amount of data streams coming into the leakage programme it cannot be expected they will all function. When a meter & logger become inoperable the DMA is no longer reportable, estimated / extrapolated data is used until it is brought online again.

The data / information used to manage the DMA system, includes, but may not be limited to;

Flow (15 minute data) Pressure (15 minute data) Demographic profiles (Household) Commercial Profile (Non-Household) Demand Historic Input Qty – Historic Leakage/Variance Weather

Temp (max, min, mean)

15


Rainfall Number of days without rain Season

3.5.2 Per Capita / Household Consumption (PCC / PHC): To inform current and

historic Household consumption demand profiles

Scottish Water does not meter household customers. Scottish Water applies a fixed charge based upon the Council Tax / Rateable Value banding of the property. To assess the volume of demand for households, Scottish Water has established a PCC / PHC Monitor in Scotland. The Monitor is used to derive an estimate of PCC / PHC at both a national and regional level. The unmeasured domestic PCC rate (litres/head/day) is a key factor used by Scottish Water to calculate the gross monthly and annual domestic consumption volume of all connected domestic customers [PCC x Number of Persons living in unmeasured households]. The Monitor has been set up in accordance with UKWIR ‘Best Practice for Unmeasured Per Capita Consumption Monitors’ (Ref: 99/WM/08/25) and updates set out in the 2007 Tynemarch report entitled “Leakage Methodology Review: Variation in Per Capita Consumption Estimates”. The Monitor was established in 2008/09 and provides national coverage on a representative basis. The Monitor contains c. 6,800 households grouped within c. 100 defined hydraulic zones, ranging in size from c. 20 to c. 280 households. The households within these zones have been chosen to be representative of discrete socio economic groupings using ACORN classification. The Monitor was designed on best-practice principles for an Area PCC Monitor, with all PCC zones having:

A single hydraulic feed No boundary valves Homogeneous socio-economic grouping No non-domestic users Continuous Monitoring No metered domestic users Pressure Monitoring of all zones Low leakage

In order to be able to extrapolate the PCC from the Monitor a suitable stratification method was needed. After consideration, it was decided to stratify using the CACI ACORN Group profile of unmeasured (un-metered) houses as referenced in UKWIR ‘Best Practice for Unmeasured Per Capita Consumption Monitors’ (Ref: 99/WM/08/25). The PCC of the sample set comprising the Monitor is used to provide a representation of the full population (stratified by ACORN socio economic grouping) connected to the Scottish Water network. ACORN (A Classification Of Residential Neighbourhoods) is a geo-demographic segmentation of the UK’s population which groups residential properties (neighbourhoods) by an evaluation of socio economic factors common to their owners. ACORN profiling is based on census data and ongoing research into the socio-demographics of the UK's c. 46 million adults and c. 23 million households. Within the Scottish ACORN classification there are 10 major groups ranging from ACORN Group A,

16


typically households occupied by affluent, large families to ACORN Group J, typically households occupied by single people. The meters used throughout the Monitor are ABB Aquamaster electromagnetic flow meters; chosen due to their overall performance and increased accuracy at low flow over a traditional mechanical meter. The meters themselves are capable of accuracies of +/- 0.5% at certain flows, however it is predicted that the majority of flow data will be within +/- 2%. The meters range from 15 mm to 80 mm diameter, but are typically 25 mm diameter. The meter sizes within the Monitor have been separately sized for the estimated flow range in each PCC zone. Careful consideration was also given to ensuring correct sizing of meters to maintain adequate flow and pressure to customers and accurate recording of flow across the flow range. The meters are installed in a chamber adjacent a local road or footpath. Each meter has a short, valved by-pass which can be used to facilitate meter maintenance. Each meter has a calibration certificate. Similar to the DMAs, Radcom data loggers are used which record the continuous flow and pressure data over 15 minute intervals. Data is fed back using either SMS or GSM transmissions to the RADWIN server from where it is fed into PSP for analysis. During the design of the monitor, the signal strength available from the major Mobile Networks was monitored and the provider was selected according to performance. The loggers have a pseudo channel which allows for secondary logging of the data at a faster interval. This facility is able to support household night use studies and to further inform our understanding of legitimate night use.

3.5.3 Leakage: To monitor and report leakage to facilitate leakage management at

the Economic Level of Leakage to facilitate optimal supply management

Water Utilities have an economic, social and environmental responsibility to manage leakage at the Sustainable Economic Level of Leakage (SELL). To do this they must understand the volume of water being put into supply, consumption of all users, including “illegal” connections, operational usage etc., night-use patterns of users and be able to assimilate all such data as to inform the likely level of leakage at any time. Typically water utilities undertake a Total Integrated Flow Analysis (Top-down) and / or a Night-use Analysis (Bottom-up) to estimate leakage. If both methods can be carried out, then the Maximum Likelihood Estimation (MLE) statistical technique can be applied to estimate the most likely level of leakage in the network (see Figure 9). In addition, mass water balances allow estimates of raw water transfer and potable water transmission systems allow leakage on such systems to be estimated. Further still, water utilities need to understand the costs and cost / benefit relationships of key parameters such as the Marginal Cost of Water (MCoW), Active Leakage Control (ALC), Natural Rate of Rise (NRR) of Leakage, and the social and environmental value propositions of alternative levels of leakage.

17


Figure 9 – Estimating Leakage (Key Components) Monitoring the network via DMAs (see 2.5.1); they become aware of leakage on the network and then implement the necessary ALC activities e.g. leak noise correlation, step tests etc. to find and then fix the leak. Water risings, which are visible on the surface, tend to be reported by 3rd parties and such leaks are repaired as soon as is practicable This project is limited to the monitoring of the network to understand the level of leakage and it impact on effective / efficient water resources management. As such, ALC activities and leakage asset investment e.g. capital maintenance expenditure for meters and control valves is not covered.

3.6 Systems Requirements

The water utility respondees gave a clear response that they see the reduction of metered consumption as a positive outcome of the implementation of IWRM (Figure 10).

Figure 10 – Reduction of Metered Consumption – Positive Outcome

DistributionInput

Householdconsumption

NonHousehold

consumption

Other

TIFTop DownLeakage

Night-useBottom UpLeakage

MLE Leakage

DMALeakage

TM / SR

18


They also indicated their belief that real time, synchronised demand and supply data could assist in their challenge of optimising water supply management (Figure 11)

Figure 11 – Importance of Synchronised, Real-time Knowledge Figure 12 below indicates the importance the respondee water utilities placed on the use of a Decision Support Systems (DSS) to assist optimising water supply management and Figure 13 below indicates their prioritisation of the major IWRM elements to improve the economic operating point.

Figure 12 – Importance of Decision Support Systems

Figure 13 – Improving the Economic Operating Point

19


4 Public Authority User Requirements

4.1 Public Authority Models

Public Authorities include Governments, Municipalities, Regulators etc. In general they set high level legal and strategic direction and / or establish frameworks which the sector stakeholders have to recognise. These frameworks vary throughout Europe, with the UK predominantly following a unique privatised model, with the private companies (PLCs) fully responsible and accountable for all aspects of the business. Some aspects of the service are contracted out, but the private companies remain responsible to the various public authorities. There are well established regulators for customer service and pricing (Ofwat) and potable water (Drinking Water Inspectorate - DWI) and environmental issues (Environment Agency). Dwr Cymru (Welsh Water) is a mutualised company with the same regulators as the PLCs in England. In Scotland, water and wastewater services are provided by Scottish Water, a Government owned Public Service organisation. The Scottish equivalent regulators are The Water Industry Commission for Scotland (WICS), the Drinking Water Quality Regulator (DWQR) and the Scottish Environmental Protection Agency (SEPA). Northern Ireland Water (NIW) operates in a similar environment to Scottish Water. The more typical model for the water industry in the rest of Europe is the Municipal Model, where local regions, Municipalities, contract the water and wastewater services to private organisations, or enter into joint ventures with such organisations to deliver the services. These contracts can vary dependent upon the service being provided, and typically include, Build Own Operate contracts, Operations / Service contracts etc. and typically run for periods up to 25 years. The service providers are generally responsible for maintaining serviceability of the relevant elements of the water supply system and meter reading, billing and revenue collection from customers. Regulation in the rest of Europe is generally not as extensive as regulation in the UK, with some countries having small regulatory representation. However, there is clear accountability to the Municipalities for service provision, with contractual arrangements, which can be seen as implicit regulation in some areas. This is covered more fully in D1.1, European Water Market Analysis.

4.2 Online Survey Response From Public Authorities

The response to the On-line Survey from the Public Authorities has not been as extensive as from the other User Groups e.g. Customers, however the responses received align very much with the overall aim of the project i.e. effective and efficient management of a finite resource. The public authority responses indicate that the most important behavioural changes they would like to see as a result of a platform like Urban Water for each of the stakeholders is as follows:

Customers - an increase in environmental awareness and a behavioural change in terms of water efficiency.

Water Utilities - efficient water management and agility to respond to events Public Authorities - prioritise water allocation / consumption within catchments and adaptive

legislation

20


Software Companies - intelligent software (e.g. dynamic, real-time, predictive) and affordable software.

The most important factors identified by public authorities to minimise the use of water resources are:

Informing customers of water efficiency measures, and Comparative information on consumption

The Public Authorities highlight the above points as a fundamental requirement of the Urban Water platform. The most important factors identified by public authorities to meet demand are also

Comparative information on consumption, and Inform customers of water efficiency measures

It should be noted that the two points are switched in terms of order of importance The most important factors identified by public authorities to help in minimising the cost of water resources management are:

Water supply costs (including forecasts), and Comparative information on consumption

It should also be noted that a significant majority of those surveyed indicated that they believe that adaptive pricing is a viable option for inclusion in the Water Utilities operating principles (see Figure 14 below.

Figure 14 – Response to Survey Question 52 In addition, The Public Authorities’ responses indicated the most important requirements of an IT platform were;

Real time customer demand data (73%) Real time water supply data (64%), and Understanding water supply costs (36%)

21


See Figure 15 below.

Figure 15 – Response to Survey Question 53

22


5 Customer User Requirements

A customer is the end-user within the utility supply chain. The customer essentially contracts with the water utility to provide them with water and wastewater services. The most regular classifications of customer-types for water services are;

Household – Residential customers Non-Household

Commercial – Offices, shops etc. Industrial – Factories, manufacturing, process industries

Social Schools Hospitals Public Service organisations

Agricultural As outlined in the Research Method, the Customer Requirements have been built up using the expertise of Scottish Water and the feedback of the Customer Requirements Survey.

5.1 Accessing the System

Customers will need to access the on-line system for a number of reasons. They will need to register / be registered in the system as a customer where they will be recorded as a contract holder with the water utility provider. They will need to access billing, gaming and any other service that is offered to that customer via the platform. They will need to access the system on-line to monitor their real-time consumption as well as to see their water consumption forecasts, billing etc., through different devices with different interfaces, for example;

Computer Smart phone Tablet Telephone etc.

This on-line system will not only allow customers to have improved communication options with their water utility provider to show customers statistics and patterns, but it will also allow the water utility provider to collect customers’ requirements and queries etc. In addition the on-line system will facilitate increased customer empowerment, assisted by gaming tools embedded in the system. Figure 16 below presents a summary of the response to question 11 in the On-line Survey; “If an ICT system was introduced, how would you prefer to access such a service?”

23



5.2 Gaming

The on-line system will present gaming tools to customers to enable them to understand basic water systems in the urban environment and to inform and educate them about water consumption and sustainable water resources management to ultimately change user behaviour. The gaming tools will use consumption data, demand and weather predictions and other data sources to inform the game play and to connect the game experience to the real world. The game will use detailed information about the users’ household water obtained from the system and compare this to similar households. It will then enable competition as well as collaboration between customers / communities, advising them on a number of variables relevant for water consumption. Figure 17 below presents a summary of the response to question 10 of the On-line Survey; “If there was a facility for interactive guidelines and simulation on managing your household water consumptions, would you use them?”


5.3 Adaptive Pricing

Embedded in the on-line system will be an element recognising a strategy for adaptive water pricing that will use water demand forecasting and water supply prediction tools together with 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 by the water utility provider. Central to this will be a

24


model of end-user consumption response to a certain water supply price and to the price profile. This will all be reflected in the gaming tool so customers will be able to test consumption scenarios that are of interest to them. 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.

5.4 Automatic Billing

The on-line system will include an automatic and dynamic billing system with innovative price plans (or: tariffs) and real-time notifications for the customers’ water consumption. Dynamic billing will encompass variable water rating and charging for water consumption based on in regular intervals (e.g. every 15 min) and utilize innovative, dynamic price plans, which will be built on the User Requirements as determined for the project. In addition to the embedded adaptive pricing mechanism, more advanced pricing schemes that consider further context parameters, which could offer discounts and bonuses will be included. For example, customers could be offered a prepayment tariff offering a discount on the water price or a tariff that allows a daily basic allowance of water at a fixed price but with fees for additional water consumption charged at a dynamically changing, most probably higher price. Furthermore, real-time threshold notification mechanisms via different communication channels could be offered as part of a price plan or sold as value-added services to customers. The dynamic billing system will consider the adaptive pricing system and as indicated above, will have interfaces with other components to automatically obtain data concerning water consumption and provide information about even the most recent water consumption and related costs as part of bill previews via the on-line system.

5.5 Customer Segmentation

Customers are a diverse group, from different socio-economic, ethnic, religious, cultural etc. groups and within such groups there will be different understanding and values of the various aspects of management of water resources and supply, Water Utilities, Public Authorities etc. For example, in the UK it is not uncommon to group customers in socio-economic groupings such as ACORN (A Classification Of Residential Neighbourhoods). ACORN is a geo-demographic segmentation of the UK’s population which segments small neighbourhoods, postcodes, or customer households into 5 categories, 17 groups and 56 types. The ACORN profile is based on census data and ongoing research into the socio-demographics of the UK's c. 46 million adults and c. 23 million households. This variability across the customer base will be evident for all water utilities’ customer bases. It will be increasingly variable the larger the company and/or diversity of population within a region. This diversity of customer will lead to different behaviours with regard to water consumption even with the same stimulants e.g. water rates and billing options, data / information etc. In addition, such stimulants will lead to either a “pull” or a “push” engagement between the customers and the other key stakeholders i.e. Water Utilities, Public Authorities, Software Providers.

5.6 Customer User Requirements - Pull

A “pull” for User Requirements is when the customer wishes to influence the thinking behind decision making, options etc. and is pro-active in making things happen for their benefit. They will wish to be kept informed on;

25


Historic / current consumption profiles Period - hourly/daily/weekly/monthly/seasonal/yearly Units – litres and/or £/€

Future consumption prediction profiles Period - hourly/daily/weekly/monthly/seasonal/yearly Units – litres and/or £/€

Exceptional consumption points / durations – informing and detailing above average (threshold

to be able to be set dynamically) or based upon exceptionally high usage – amount and duration. In future it may be that we could link to specific consumption points, taps/washing machine/etc. so balance can be used to predict a leak within customer property.

Historic / current water resources availability / constraints Period - daily/weekly/monthly/seasonal/yearly Units – litres and/or £/€

Future water resources availability / constraints Period - daily/weekly/monthly/seasonal/yearly Units – litres and/or £/€

Exceptional water resource events e.g. restrictions, droughts etc. – informing and detailing

below average (threshold to be able to be set dynamically) or based upon exceptionally low resources, rainfall – amount and duration. In future it may be that we could link to specific resource types e.g. reservoirs, boreholes, rivers etc.

Historic / current water quality profiles Period - daily/weekly/monthly/seasonal/yearly Subset of parameters – likely to be dynamic and change through time

Future water quality profiles – climate change factors and their impact upon WQ Period - hourly/daily/weekly/monthly/seasonal/yearly Subset of parameters – likely to be dynamic and change through time

Exceptional water quality events e.g. contamination, discolouration, odour etc. – informing and

detailing extremes (threshold to be able to be set dynamically) or based upon exceptional hydraulic events in the network. In future it may be that we could link to specific quality parameters / events.

Historic / current number of bursts – Defined at local DMA zones and above Historic / current leakage Levels – Defined at local DMA zones and above

Exceptional water resource events e.g. restrictions, droughts etc. – informing and detailing

below average (threshold to be able to be set dynamically) or based upon exceptionally low resources, rainfall – amount and duration. In future it may be that we could link to specific resource types e.g. reservoirs, boreholes, rivers etc.

26


Bills – Historic / current billing amounts, billing profiles, account balance, payment methods, incentives / penalties, contact information

Tariffs – Tariff options, associated rates, contractual arrangements

Gaming perspective – Gamification of consumption to reduce water consumption overall, to flat-

line peaks in the consumption profile and to reduce consumption during higher risk events such as reduced supply.

5.7 Customer User Requirements - Push

A “push” for User Requirements is when the stakeholders are wanting to influence the customers’ thinking behind decision making, options etc. and the customer is more reactive to events, information etc. The various stakeholders i.e. Water Utilities, Public Authorities, Software Providers will need to engage with customers to;

Encourage changes in consumption behaviours / patterns that result in reductions in peak consumption and reductions at times of low availability

Provide water resource availability information – how much currently available, RAG status, current supply availability given current consumption profiles and predictions on future supply

Provide exceptional weather information and impact assessment Provide water efficiency suggestions and behavioural change requests Provide Incident information on planned and unplanned activities (warnings and advice notices) Make them aware of local, national and European Directives and Legislation Encourage the use of the on-line system, including providing updates / guidance on the use of

relevant communications technology / options e.g. smart phone etc. They will also need to be pro-active in providing comparative information/knowledge, both historic and current and relative comparisons – across streets/villages/areas/cities etc.

5.8 Water Efficiency

Water Efficiency is a key area where the Urban Water Platform can support customers. Central to all of this will be a need for customers to be informed and incentivised to be efficient in the use of water in the household. Customer engagement programmes in Scotland have identified the key points as;

Water needs to be valued as precious resource – particularly challenging if it is viewed as abundant by customers

Key drivers for efficiency focus on environment and cost impacts rather than actual need to do it Water efficiency is seen as one of the key areas to be tackled in terms of climate change

(alongside surface water management) Water Utilities should strive to be carbon neutral, and should also support householders to

become more carbon neutral. Improving water efficiency in existing properties is generally regarded as a practical and

important strategy that should be encouraged. It was acknowledged by customers that implementation could be difficult as motivating the public could prove problematic. Possibility to incentive by savings on bill costs or free efficiency measures

27


There was unanimous acceptance respondents that they would consider using rainwater for their households’ use, such as for flushing toilets

Showering and washing clothes with rainwater would also be acceptable by a majority of customers. The proviso was that such water should be easily accessible i.e. that it should be piped directly into their homes.

It was felt that the issue of water efficiency needed to follow a similar path to waste recycling, starting with raising awareness of the consequences, providing good access to information and data, establishing acceptable levels of behaviour in terms of how much water is ‘too much’, providing the ability to save water (access to facilities, devices or hints and tips) and therefore achieving the culture shift that water waste is unacceptable

Respondents were generally happy to look at how they could be more water efficient, but they felt that they needed more information about how to be (and why), along with a context for assessing how well they were already doing.

The following Figures (Figures 18 to 21 Inclusive) present a summary of the response to questions 5, 6, 7 and 12 of the On-line Survey.



28




These responses show clearly that if the customer is provided with the necessary tools through the platform they have an appetite to change their behaviour. This has the potential to offer significant benefits not only to the customer but also water utilities and public authorities.

5.9 User Requirements – Survey Findings

As indicated in the various Figures throughout this section, the results from the On-line Survey developed for the project provide additional insight into the User Requirements of customers. As the survey was targeted at eliciting answers to questions which were specifically designed to inform the project of User Requirements relative to a real-time integrated Water Resources Management System, the responses provide significant value to assist in developing the system. The following figures present some further findings following analysis of the returns.

29




30


6 Software Provider User Requirements

The User Requirements for software providers to the Urban-Water Platform has been produced using the results of the online survey and also the expertise of consortium partner, Red Skies. It can be broken into four main sections: Section 1: Secure Access to the Required Data-sets Section 2: Query the Data-sets Effectively and Efficiently Section 3: Using Open Standards Section 4: Scalability and Reliability

6.1 Section 1: Secure Access to the Required Data-sets

Secure access to commercially sensitive data-sets is extremely important and the following data-sets will likely need to be made available to software providers to the Urban-Water platform;

Meteorological data Water treatment data Raw water sources data Water network data WDN topology data Metering data Calendar data

6.2 Section 2: Query the Data-sets Effectively and Efficiently

The Urban-Water Platform will have to provide the ability for the user to query the data-sets based on their own unique queries. This will allow the software provider to effectively and efficiently access the data they require from the data-sets.

6.3 Section 3: Using Open Standards

The ability to build an application independent to that of the technology used to construct the Urban-Water Platform is critical to software providers as this allows existing applications to be tailored to the platform and not be constrained for any new applications to use specific language or technology. The following Figures (Figures 24, 25 & 26) present a summary of some of the relevant responses from the Software Providers who completed the online survey.

31





32


6.4 Section 4: Scalability and Reliability

Given the scale and complexity of the different data-sets to be stored on the Urban-Water platform, when acquiring data, a software provider can not be constrained by the complexity and the scale of the data-sets. The platform must have the ability to scale up in times of peak demand for data and be able to cope with hardware failures / outages in the system.

6.5 Use Cases

The described scenario descriptions are at a high abstraction level. Therefore, for the next step it is recommended that use cases are developed to determine more specific requirements. Use cases show the different steps of the various scenarios in more detail, which makes it easier to identify main actors, dependencies to other use cases and preconditions etc. It is also helpful to have such documentation for interdisciplinary developing teams to have a well-founded basis for discussions. This section contains a list of the use cases structured by the scenarios from which they have been derived. Sometimes the use cases in one scenario are quite similar to others in another scenario. For the sake of completeness and to be able to analyse each scenario more or less on its own, these are described, but the similarity is mentioned and referenced in the remark sections of the relevant use cases. For the description of the use cases the following template has been used:

33


1. Identifier and Name

<A unique identifier, e.g. UC1.3, and a short active verb phrase>

1. Scope

<A reference to the scenario this use case belongs to and a description of the use case>

2. Priority

<The priority of the use case, i.e. either ‘mandatory’, ‘expected’ or ‘optional’>

3. Dependencies

<E.g.: ‘Primary Task’ without dependency or ‘Sub-function’ with dependency to another use case (in the latter case, a reference to the corresponding use case ID should be provided)>

4. Components & Description

<A role name for the primary actor and a concrete actor name if applicable>

< Put here the description and/or interest of the primary actor>

5. Pre-requisites

< The preconditions of the use case states what is required before the use case starts >

6. Variables

< Invariants that describe conditions that must not change by the execution of the use case, even in the case of failure (failures can be described in “Alternative Flows”, see item 13 below>

7. Post conditions

< The post conditions of the use case state what is expected after the use case has ended>

8. Trigger

<The action and/or event that is the reason for starting this use case>

9. Flow of Events

Step Actor and/or System Action

1 <Put here one step of the use case>



10. Remarks

< Further hints or explanations to enhance the comprehensibility of the use case, e.g., open issues, still unknown aspects, references to other documents, or additional diagrams>

Table 1: Use Case description Template

34


6.6 Urban Water Platform Use Cases

6.6.1 Secure Data Access Use Case


Software provider can access data securely

2. Scope

Urban-Water Platform

3. Priority

Mandatory.

4. Dependencies

None.


Urban-Water Platform Secure data access.

6. Pre-requisites

7. Post conditions

Software provider can access data from the platform securely.

8. Trigger

9. Flow of Events

Step System Action

1 The Gateway system being developed in WP2 will be responsible for acquiring data from the Smart Meters. These readings will be accumulated trough out the day in the Head end System.

2 The cloud data management system being developed in WP3 will be responsible for secure storage of data and data access

3 Software providers to the platform will connect with the data

10. Remarks

This data will have to be encrypted as it will be stored in the “cloud“.

35


6.6.2 Query the Data-sets Effectively and Efficiently


Easily query and manipulate data

2. Scope


3. Priority

Mandatory.

4. Dependencies

None.


Urban-Water Platform Easy access to data

6. Pre-requisites

Data to be stored in the Urban-Water Platform

7. Post conditions

Software provider can access data easily from the cloud platform.

8. Trigger

Software provider attempts to access data

9. Flow of Events

Step System Action

1 Software provider would like to query information of several of the data-sets being stored by the Urban-Water Platform

2 Software provider would like to access and manipulate data accessed from the Urban-Water Platform.

10. Remarks

36


6.6.3 Open Standards Use Case


Using Open Standards

2. Scope


3. Priority

Mandatory.

4. Dependencies

None.


Urban-Water Platform The Urban-Water Platform must use open standards for communication allowing software providers implement there solution not constrained by the technology provided by the Platform.

6. Pre-requisites

7. Post conditions

Software provider can access data from the platform independent of the technology used to develop the platform

8. Trigger

9. Flow of Events

Step System Action

1 Data is stored in the Urban-Water Platform

2 Software provider attempts access and customer data being released by the platform.

10. Remarks

37


6.7 Requirements

This Chapter contains a list of requirements that have been derived from use cases. The requirements are intentionally not structured by the scenarios or use cases they have been derived from. The idea is to find a common agreed set of requirements valid for the whole project and to avoid duplicate requirements. Nevertheless for each requirement, a priority as well as the related use cases and scenarios are specified. For the description of the requirements, the following template has been used:

Requirement # <A unique identifier>

Priority

<The priority of the requirement, i.e. either ‘mandatory’, ‘expected’ or ‘optional’>

Conflicts < List potential conflicts with other requirements>

Requirement <Description of the requirement>

Component <References to the components affected by this requirement>

Use Cases <References to the use cases and their steps relevant for this requirement>

Remark < Further hints or explanations to enhance the comprehensibility of the requirement, e.g., open issues, still unknown aspects, references to other documents, or additional diagrams>

Table 2: Requirement description Template

38


6.7.1 Software Provider Requirements

Requirement PS-1: Secure access to data from the Urban-Water Platform

Requirement # SP-1 Priority Mandatory Conflicts -

Requirement Secure access to data

Component Urban-Water Platform Use Cases Security use cases

Remark

Requirement PS-2: The ability to query multiple data-sets stored on the Platform


Requirement The ability to query and manipulate the data-sets

Component Data Management Platform

Use Cases All use cases

Remark This is very important considering the scale of data.

Requirement PS-3: Open Standards


Requirement The platform must release data using open standards.

Component Urban-Water Platform Use Cases Open Standards use cases

Remark Platform must not restrict or constrain software provider’s solutions.

Requirement PS-4: Scalability and Resilience


Requirement The platform must be available to provide access to data and be able to accommodate a large number of requests during a peak load period.

Component Urban-Water Platform Use Cases Scalability use cases

Remark

Requirement PS-5: Sample Code for integration


Requirement The platform must provide reference code to enable software providers to integrate with the Urban-Water Platform

Component Urban-Water Platform Use Cases Survey Requirements

Remark

Project Title: Intelligent Urban Water Management...

Documents

Transcript of Project Title: Intelligent Urban Water Management...