Project Title: Intelligent Urban Water Management System ...urbanwater-ict.eu › wp-content ›...

Project Title: Intelligent Urban Water Management System

Project Acronym: URBANWATER

Seventh Framework Programme Collaborative Project

Grant Agreement Number 318602

Subject:

D4.9 – Spatial Decision Support System implementation – WP4

Dissemination Level: PUBLIC Lead beneficiary: Hydrometeorological Innovative Solutions

Revision Preparation date Period covered Project start date Project Duration

FINAL May 2015 Months 09 to 25 December 2012 33 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 author's v iews and the European Union is not liable for any use that may he made of the information contained therein.

Deliverable D4.9 – Spatial Decision Support System implementation

2

URBANWATER PUBLIC Grant Agreement: 318602

Abstract

The deliverable D4.9 “Spatial Decision Support System implementation” describes the development of the Spatia l Decision Support System (SDSS) module prototype of the UrbanWater platform. The prototype has been developed according to the requirements and design defined in UrbanWater Deliverables D4.1 “Decision supporting tools requirements” and D4.2 “Decision supporting tools design”. This document describes the development of the prototype and performs a functional validation of the module. The integration of the module will be presented in Deliverable D6.5, and the validation results will be presented once the va lidation is finished in Deliverables D7.2, D7.3 and D7.4. The document begins with a general description of the prototype that has been developed, how it is related and interacts with the other modules of the UrbanWater platform, which are the offered services and the known limitations. Next, a detailed technical description of the prototype development is provided, including details of the SDSS architecture, the technologies used, the interaction with the UrbanWater platform, and the front-end and back-end development as well as the integration with the database. Finally, a description of the functional validation tests performed on the SDSS module is provided together with the validation results, showing the prototype performance within the expected bounds. The results of the validation of the supplied services to other UrbanWater modules has been moved to UrbanWater Deliverable 6.5.


3


List of Acronyms

AMQP Advanced Message Queuing Protocol

APS Adaptive Pricing System

BRMS Business Rule Management System

CMS Content Management System

CSS Cascade Style Sheets

DBMS Database Management System

DOM Document Object Model

DRL Drools Rule Language

Dx.y UrbanWater Deliverable x.y

GUI Graphical User Interface

HTML Hypertext Markup Language

ICT Information & Communication Technology

JSON JavaScript Object Notation

JVM Java Virtual Machine

LDS Leakage Detection System

MIT Massachusetts Institute of Technology

MVC Model-View-Controller

OGC Open Geospatial Consortium

ORM Object-Relational Mapping

SDSS Spatial Decision Support System

SQL Structured Query Language

UI User Interface

UML Unified Modeling Language

WAPS Water Availability Prediction System

WDN Water Distribution Network

WDPS Water demand prediction system

WMS Web Map Service

WPx Work Package x

WTP Water Treatment Plant

XML eXtensible Markup Language


4


Table of Contents Abstract........................................................................................................................................................................................ 2 List of Acronyms......................................................................................................................................................................... 3 Table of Contents....................................................................................................................................................................... 4 List of Figures ............................................................................................................................................................................. 6 List of Tables .............................................................................................................................................................................. 7 List of Listings ............................................................................................................................................................................. 8 1 Introduction........................................................................................................................................................................ 9

1.1 Objectives of UrbanWater ........................................................................................................................................ 9 1.2 Objectives of WP 4 (Decision supporting tools).................................................................................................... 9 1.3 Objectives of this document ...................................................................................................................................10 1.4 Structure of this document .....................................................................................................................................10

2 The SDSS as an UrbanWater component .................................................................................................................12 2.1 General description..................................................................................................................................................12 2.2 Supplied services .....................................................................................................................................................13 2.3 Known limitations .....................................................................................................................................................14

3 Prototype development .................................................................................................................................................15 3.1 Overview....................................................................................................................................................................15

3.1.1 SDSS architecture ...........................................................................................................................................15 3.1.2 Technologies used ..........................................................................................................................................16 3.1.3 Required interfaces .........................................................................................................................................18 3.1.4 Required data...................................................................................................................................................18

3.2 Internal database development .............................................................................................................................19 3.2.1 Water supply system data..............................................................................................................................19 3.2.2 User interface data ..........................................................................................................................................20

3.3 Front-end development...........................................................................................................................................21 3.3.1 User interface components developed for the SDSS prototype ..............................................................21 3.3.2 Interaction with the internal database ..........................................................................................................23

3.4 Back-end development ...........................................................................................................................................24 3.4.1 SDSS service ...................................................................................................................................................26 3.4.2 Data parsers and inference engine ..............................................................................................................30

4 Prototype functional validation .....................................................................................................................................34 4.1 Inference engine validation ....................................................................................................................................34

4.1.1 Validation water supply system .....................................................................................................................34 4.1.2 Input data parser..............................................................................................................................................36 4.1.3 Inference engine ..............................................................................................................................................37 4.1.4 Output data parser...........................................................................................................................................39

4.2 Results .......................................................................................................................................................................39 5 Conclusion and Outlook ................................................................................................................................................41

5.1 Conclusions ..............................................................................................................................................................41 5.2 Outlook.......................................................................................................................................................................41

6 References ......................................................................................................................................................................43 7 Annex I: Graphical User Interface ...............................................................................................................................44

7.1 SDSS sub-module ...................................................................................................................................................45 7.1.1 Logical view ......................................................................................................................................................46 7.1.2 Physical view ....................................................................................................................................................46

7.2 Administration sub-module.....................................................................................................................................47 7.2.1 Elements administration .................................................................................................................................47 7.2.2 Rules administration........................................................................................................................................50

8 Annex II: Requirements compliance in the implementation ....................................................................................52 8.1 Retrieve demand prediction ...................................................................................................................................52 8.2 Retrieve availability prediction ...............................................................................................................................52 8.3 Retrieve leakages detection...................................................................................................................................52


5


8.4 Retrieve water utility data .......................................................................................................................................52 8.5 Modify the topology of the water supply system representation ......................................................................53 8.6 Modify SDSS configuration ....................................................................................................................................53 8.7 Compute SDSS status (online mode)...................................................................................................................53 8.8 Compute SDSS status (offline mode)...................................................................................................................53 8.9 Store SDSS status ...................................................................................................................................................53 8.10 Provide SDSS status..........................................................................................................................................53 8.11 Display the topology of the water supply system representation ...............................................................54 8.12 Display the topology of the water supply system ..........................................................................................54 8.13 Send notifications through the platform ..........................................................................................................54

9 Annex III: Elements and rules used for the validation ..............................................................................................55 9.1 Water supply system elements..............................................................................................................................55 9.2 Water supply system operational rules ................................................................................................................57


6


List of Figures

Figure 1: Framework and main interactions of the SDSS module in the UrbanWater architecture...........................13

Figure 2: General architecture of the SDSS module. ........................................................................................................15

Figure 3: Water supply system data UML diagram. ...........................................................................................................19

Figure 4: User interface data UML diagram. .......................................................................................................................20

Figure 5: Example of a water supply system logical map. Boxes represent the elements of the system, and black arrows indicate how water is transferred from one element to the other........................................................................22

Figure 6: Rule builder component floating window, with one operational rule loaded in order to be modified. .......23

Figure 7: Physical map example of part of the Algarve water supply system. Each icon (WTPs, reservoirs and urban areas) represents an element of the water supply system....................................................................................23

Figure 8: External and internal interactions of the SDSS module. ..................................................................................25

Figure 9: Class diagram of the SDSS platform service. ....................................................................................................27

Figure 10: Java classes defined for the data parsers and the inference engine SDSS components........................31

Figure 11: Validation water supply system. .........................................................................................................................35

Figure 12: SDSS user interface sample window. The three sections composing each view (sub-modules selector, view selector and content) are highlighted with red boxes. ..............................................................................................44

Figure 13: Detail of the sub-modules selector section.......................................................................................................44

Figure 14: Example of the views selector section. In this case it presents the available views in the SDSS module. ....................................................................................................................................................................................................44

Figure 15: SDSS sub-module component that presents calculated information of the selected element. A selector is available in the top part, and the element information is available below. .................................................................45

Figure 16: Element menu unfold, with all the available elements in the water supply system. ..................................45

Figure 17: Logical map of a water supply system. In this map, reservoirs are represented as blue boxes, WTPs are black boxes and urban areas are white boxes. Arrows indicate how water is distributed from one element to another.......................................................................................................................................................................................46

Figure 18: Physical map presenting three reservoirs, two WTPs and an urban area in the area of Algarve (Portugal)...................................................................................................................................................................................46

Figure 19: SDSS administration sub-module view.............................................................................................................47

Figure 20: Available views in the Administration sub-module. .........................................................................................47

Figure 21: Example of the elements table with the available elements in the water supply system. ........................48

Figure 22: Window to add, edit or remove an element......................................................................................................48

Figure 23: Example of a dialog window to set or modify the element parameters. ......................................................49

Figure 24: Example of a dialog window to set or modify the element variables. ..........................................................49

Figure 25: Example of the dialog window to set the logical relationships between a given element and other water supply system elements. ........................................................................................................................................................50

Figure 26: Example of operational rules table. ...................................................................................................................50

Figure 27: Example of the rules edition window. In this case, the rule means “if consumption in the east region is less or equal than Alcantarilha WTP max outflow, then Alcantarilha WTP inflow is the sum of Odeleite and Arade reservoirs outflow”. ..................................................................................................................................................................51


7


List of Tables

Table 1: Technologies used in the front-end of the SDSS module. ................................................................................17

Table 2: Properties included in the configuration file of the SDSS service. ...................................................................28

Table 3: ALC WTP parameters and variables. ...................................................................................................................35

Table 4: Validation table template presenting the validation results in a computer......................................................39

Table 5: Requirements compliance template......................................................................................................................52

Table 6: BRA reservoir parameters and variables. ............................................................................................................55

Table 7: ODE reservoir parameters and variables.............................................................................................................55

Table 8: SIL borehole parameters and variables. ..............................................................................................................55

Table 9: GUA reservoir parameters and variables.............................................................................................................56

Table 10: FON WTP parameters and variables. ................................................................................................................56

Table 11: ALC WTP parameters and variables. .................................................................................................................56

Table 12: TAV WTP parameters and variables. .................................................................................................................56

Table 13: BEL WTP parameters and variables. .................................................................................................................56

Table 14: LVDB consumer parameters and variables.......................................................................................................56

Table 15: Silves-Portimão consumer parameters and variables. ....................................................................................56

Table 16: Faro-Olhão consumer parameters and variables. ............................................................................................56

Table 17: TVRSAA consumer parameters and variables. ................................................................................................57

Table 18: REV pump station parameters and variables....................................................................................................57


8


List of Listings

Listing 1: Example of a JSON file with results calculated by the inference engine. .....................................................24

Listing 2: Example response to a request to uw.service.monitoring.xml........................................................................29

Listing 3: Example request to uw.service.sdss.sdss.getelements...................................................................................29

Listing 4: Example response to a request to uw.service.sdss.sdss.getelements. ........................................................29

Listing 5: Example request to uw.service.sdss.sdss.getstatus. .......................................................................................29

Listing 6: Example response to a request to uw.service.sdss.sdss.getstatus...............................................................30

Listing 7: Basic structure of a DRL rule................................................................................................................................32

Listing 8: Example DRL rule. .................................................................................................................................................32

Listing 9: Water supply system initial conditions. ...............................................................................................................36

Listing 10: Rule – 6 logical definition. ...................................................................................................................................36

Listing 11: Rule – 6 represented in DRL format. ................................................................................................................37

Listing 12: ALC WTP java object before running the inference engine. .........................................................................38

Listing 13: Test results calculated by the inference engine. .............................................................................................38

Listing 14: ALC WTP Java object after running the inference engine. ...........................................................................38

Listing 15: JSON file generated by the inference engine once simulation is finished. .................................................39

Listing 16: XML response file generated for the ALC element.........................................................................................39

Listing 17: Rule - 1...................................................................................................................................................................57

Listing 18: Rule - 2...................................................................................................................................................................57

Listing 19: Rule - 3...................................................................................................................................................................57

Listing 20: Rule - 4...................................................................................................................................................................57

Listing 21: Rule - 5...................................................................................................................................................................57

Listing 22: Rule - 6...................................................................................................................................................................58

Listing 23: Rule - 7...................................................................................................................................................................58

Listing 24: Rule - 8...................................................................................................................................................................58

Listing 25: Rule - 9...................................................................................................................................................................58

Listing 26: Rule - 10.................................................................................................................................................................58

Listing 27: Rule - 11.................................................................................................................................................................58

Listing 28: Rule - 12.................................................................................................................................................................58

Listing 29: Rule - 13.................................................................................................................................................................58

Listing 30: Rule - 14.................................................................................................................................................................59


9


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 developed regions, which accounts for 17% of freshwater demand in the European Union. 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 reducing overall consumption

Helping water utilities to meet demand at reduced costs 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 UrbanWater system will likely incorporate the following:

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.

1.2 Objectives of WP 4 (Decision supporting tools)

The goal of WP4 is to provide a Spatial Decision Support System (SDSS) 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 one hand, to provide the water management authorities 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 forecasted 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

http://urbanwater-ict.eu/


10


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 three basic modules:

The Water Availability Prediction System (WAPS), which based on current and forecasted 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 as dams/reservoirs. The major objective of the WAPS is to deliver real-time continuous and detailed information of current and future dams’ storage conditions that could be integrated in the SDSS.

The water demand prediction system (WDPS) aims to provide real-time information about forecasted demand conditions in the following days using historical data as well as current information (about demand trends and weather information). It will also feature a novel detailed indoor consumption model to support both utilities in understanding demand and customers for behavior change. The resulting models will be integrated in the SDSS to work in conjunction with the WAPS system.

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, and Hydraulic Model).

In essence each of the previous modules/systems will require input information to provide a forecast of the future state, and will output information that the decision support system will use to propose the expert/user possible future scenarios and ideally the optimal decisions to take. In addition, the SDSS and the WDPS will also provide input information to the Adaptive Pricing System module.

1.3 Objectives of this document

This deliverable D4.9 “Spatial Decision Support System implementation” describes the development of the Spatial Decision Support System module prototype. The development process includes a general description of the prototype, its architecture, technologies used, user interface, integration works into the UrbanWater project framework (which includes the development of services to supply information to other modules and the user interface presentation into the UrbanWater platform) and validation tests passed during the prototype development. The prototype presented in this document has been developed according to the requirements presented in Deliverable D4.1 “Decision supporting tools requirements” and the design documented in Deliverable D4.2 “Decision supporting tools design”.

1.4 Structure of this document

This document is organized in the following sections:

Section 2 “The SDSS as an UrbanWater component” provides a general description of the SDSS prototype development to have a general view of the prototype itself.

Section 3 “Prototype development” provides the technical description of the prototype implementation. This section includes the prototype architecture, technologies used, a detailed description of the inference engine development and all the integration works done to deploy the prototype into the UrbanWater project framework.

Section 4 “Prototype functional validation” describes the validation tests executed to verify that all the features provided work as expected, focusing on the inference engine results.


11


Section 5 “Conclusion and outlook” refers to the conclusions and future work regarding the SDSS module.

Annex I “Graphical User Interface” (Section 7) presents the user manual of the SDSS graphical user interface.

Annex II “Requirements compliance in the implementation” (Section 8) summarizes for reference the requirements list presented in Deliverable D4.1 and how the prototype presented in this document satisfies all of them.

Annex III “Elements and rules used for the validation” (Section 9) includes the set of rules and elements used for the functional validation of the SDSS.


12


2 The SDSS as an UrbanWater component

This section presents general information about the SDSS prototype from the UrbanWater project perspective. It presents the services that are supplied to other UrbanWater modules and the known limitations of the prototype, which should be taken into account during the validation on the pilot sites and on further SDSS developments.

2.1 General description

The Spatial Decision Support System (SDSS) is a tool that suggests a set of actions to the operators of water utilities based on the current status of the water distribution system and the management procedures defined with the aim of helping them in the decision-making process. In the context of the SDSS, the current status of the water supply system is defined by the measurements taken within the system, like the Water Treatment Plant (WTP) current inflow and outflow, the current reservoir level, or the pressure at a specific point of the Water Distribution Network (WDN). The management procedures (which consist on the knowledge generated by the water utility regarding the operation of the system under certain conditions based on procedures defined by them and their own experience) are introduced in the module in the form of logical rules. In fact, the logical rules are not built using only the knowledge transferred from the water utility. The power of the UrbanWater SDSS relies on the capability of combining the information provided by other modules of the platform in addition to the base rules derived from the current operation of the site. Despite the SDSS acting as a central element that combines information coming from various sources, from the point of view of the UrbanWater platform it is yet another module that uses and provides services, like the Water Availability Prediction System (WAPS), the Monitoring Service, or the Smart Metering Gateway, for example. Figure 1 shows the framework of the SDSS module within the general architecture of the UrbanWater platform. In the diagram, the potential relations of the SDSS with other modules and services of the platform as well as the SDSS module itself are highlighted. The SDSS module (emphasized with a red circle) belongs to the Decision Supporting Tools group of elements in the architecture of UrbanWater. The arrows in red color represent the interactions that will occur regardless of the information used to build the rules:

Since the SDSS module has a user interface that permits the users to manage the rules defined and view the results of the rules’ execution, it is connected to the UrbanWater platform part of the Visualization Services group.

Independently of the purpose of the rules, the SDSS module needs at least to retrieve measured data from the sites stored in the cloud database, thus it is surely connected to the Cloud database service.

Finally, like any other module of the UrbanWater platform, the SDSS communicates with other modules through the Service Bus provided in the Core Platform services, and provides an internal service to the Monitoring service (as specified in UrbanWater Deliverables D6.2 and D6.4).

On the other hand, the figure also highlights some other relations (arrows in green color). These are the possible interactions foreseen with other modules that generate information that could be useful and therefore taken into account when building the rules (see Section 3 of UrbanWater Deliverable D4.1 for examples of these interactions).


13


Figure 1: Framework and main interactions of the SDSS module in the UrbanWater architecture.

The next sections describe in detail how the SDSS works, from the data acquisition to the generation of the suggestions on the operation of the site.

2.2 Supplied services

The SDSS module supplies three services to the UrbanWater platform, as specified in Section 7.1 of Deliverable D4.2 (Annex I on page 111). These services can provide all the information (knowledge) generated by the SDSS to any other module requiring it. For instance, these services could be used to develop alternative user interfaces to explore the results obtained from the SDSS, or to take into account the status calculated by the SDSS in the billing system. The list of services supplied by the SDSS is the following (the detailed information of these services can be found in Section 3.4.1.2):

uw.service.monitoring.xml: provides information regarding the module itself. uw.service.sdss.sdss.getelements: provides the list of elements in the water supply system of the

specified water utility.


14


uw.service.sdss.sdss.getstatus: provides the calculated status of a given element. The status consists of the list of variables and parameters and their values calculated by the SDSS taking into account the current status of the water supply system and the rules defined by the operator.

2.3 Known limitations

The prototype presented in this document has the following known limitations, taking into account the requirements and the design presented in Deliverables D4.1 and D4.2 respectively:

Currently it is not possible to create integer fields through the user interface, thus the numeric fields will always be stored as floats. This limitation will be solved in next iterations of the front-end development.

The prototype does not check if element fields match with their field type definition. For instance, it is possible to assign a text string to a variable defined as float. This will be solved in future versions.

The user is not allowed to create, modify or remove the elements defined in the water supply system. Currently only the elements already included in Deliverable D7.1 for each test site are available, although the user interface developed is prepared to allow the modification of the water supply system model. It is foreseen to enable this feature in future releases of the SDSS module before the end of the project.

The current prototype does not provide an off-line mode, and therefore only the real water supply system can be simulated (that is, it is not possible to set out “what if” scenarios at the moment). The implementation of the off-line mode will be included in next iterations of the SDSS developments.

None of the above mentioned limitations limit the usefulness of the developed SDSS within UrbanWater platform.


15


3 Prototype development

This section presents the development of the SDSS prototype. First, a general overview of the prototype (architecture, technologies used, UrbanWater services offered and needed, etc.) is done prior to presenting the development of each one of the layers or sections defined in the architecture

3.1 Overview

3.1.1 SDSS architecture

The implementation of the SDSS module is based on a three-tier architecture. Thus, the module is divided into front-end, back-end and the internal database, which corresponds to the presentation tier, the logic tier, and the data tier respectively in the software design pattern. Figure 2 illustrates the general architecture of the SDSS module.

Figure 2: General architecture of the SDSS module.

The presentation tier (front-end part) has a single element, which is the Graphical User Interface (GUI) of the SDSS module. Essentially, the GUI permits the interaction of the user with the module through the corresponding section of the UrbanWater platform. The main actions the users can do are: (i) to check and retrieve the status of the elements in the water supply system (that is, the values assigned to the variables and parameters); and (ii) to view, modify, create and remove the rules defined for the site. The implementation of the front-end part is described in Section 3.2, and the detailed description of the different views available in the SDSS GUI as a user’s manual can be found in Annex I (Section 7). The logic tier (back-end part) is where the SDSS processes take place. It is made up of the SDSS platform service, the input and output data parsers, and the inference engine:

The SDSS platform service is the piece of software that implements the processes needed to let the SDSS communicate with the UrbanWater platform through the Service Bus (following the guidelines and requirements defined in UrbanWater Deliverable D6.1 “UrbanWater platform requirements definition”), offering the interfaces to retrieve the elements that constitute the water supply system (e.g. site) and to


16


get the status of the elements after the simulation made by the SDSS. The detailed description of the interfaces can be found in Section 3.4.1.2.

The input and output data parsers are in charge of transforming the data received from and sent to the UrbanWater platform. An in-depth explanation of the input and output data parsing processes is offered in Section 3.4.2.

The inference engine is the core component of the SDSS back-end. It is implemented using Drools, which exploits the knowledge introduced in the form of logical rules. Moreover, since the SDSS module was designed to allow for a high flexibility (see Section 3 of D4.2 on page 23), the rules could include and take into account information provided by any other module of the UrbanWater platform. Section 3.4.2 contains the detailed description of the implementation of the inference engine.

Finally, the data tier consists of the internal database, which in turn is composed of a Database Management System (DBMS) – PostgreSQL in this case - and several data files. As it will be explained in Section 3.3.2, using data files instead of storing the information in the database permits to improve the performance of the data retrieving process, especially in the case of large sets of time-series information that is read sequentially.

3.1.2 Technologies used

In this section a brief overview of the main technologies used to develop the SDSS module is offered. The technologies used in the development of the front-end, the back-end, and the internal database are summarized in Table 1.

Technology Used in… Description

PHP programming

language

Front-end and

Back-end

PHP: Hypertext Preprocessor 1 (PHP) is a scripting language designed for web development but can be also used as a general-purpose programming language. It can be mixed with HTML or combined with web frameworks when it is used for web development. It is widely used, since as of 2013 almost 40% of total web sites used PHP for their development (Ide, 2013).

Symfony framework

Front-end

Symfony2 is a PHP web application framework for Model-View-Controller (MVC) applications that aims at speeding up the creation and maintenance of web applications and replacing repetitive coding tasks. Symfony is free software released under the MIT license.

HTML5, JavaScript, and

CSS3

Front-end

HTML53 is a core technology markup language of the Internet used for structuring and presenting content for the World Wide Web that adds many new syntactic features (like the “video”, “audio”, and “canvas” elements) with respect to prior versions. Additionally, when used together with JavaScript and CSS34, HTML elements can be animated to provide richer and more dynamic user interfaces.

jQuery library

Front-end

jQuery5 is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML. It is the most popular library in use today, and as of 2015 almost 50% of all web sites around the world use this technology (“JavaSc ript Technologies Market Share” 2015). The syntax of jQuery is designed to make it easier to

1 PHP official web site: http://www.php.net 2 Symfony official web site: http://www.symfony.com 3 HTML 5 in the W3C official web site: http://www.w3.org/TR/html5 4 CSS in the W3C official web site: http://www.w3.org/TR/CSS 5 jQuery official web site: http://www.jquery.com


17


Technology Used in… Description

navigate a document, select DOM elements, create animations, handle events, and develop Ajax applications.

MapServer WMS server

Front-end

MapServer 6 is an open source development environment for building spatially enabled Internet applications. It can run as a CGI program or via MapScript, which is a set of functions and classes supplied by MapServer and supported on several programming languages. MapServer was developed by the University of Minnesota and was released under the MIT license.

Java programming

language

Back-end

Java 7 is a general-purpose, concurrent, class-based and object-oriented computer programming language specifically designed to have as few implementation dependencies as possible. It is intended that compiled Java code (bytecode in Java argot) can run on all platforms that support Java through the Java Virtual Machine (JVM) without the need for recompilation.

Drools inference engine

Back-end

Drools8 is a business rule management system (BRMS) with a forward and backward chaining inference based rules engine (that is, a production rule system), using an enhanced implementation of the Rete algorithm. Drools is supporting the JSR-94 standard for its business rule engine and enterprise framework for the construction, maintenance, and enforcement of business policies in an organization, application, or service.

PostgreSQL DBMS

Internal database

PostgreSQL9 is an object-relational database management system used to store data securely and retrieve it lately. It is usually installed in a dedicated database server that can be accessed from other computers and server through the network. PostgreSQL is open-source and widely used, and implements the majority of the ISO/IEC 9075:2011 SQL standards10. It also has several extensions available, with special mention to PostGIS11, which adds geospatial capabilities to the database.

Table 1: Technologies used in the front-end of the SDSS module.

On the one hand, the front-end part consists of the graphical user interface that has been implemented in a web application using the Symfony framework. Since Symfony is programmed in PHP, the business logic is also coded using this language. The visualization interface uses HTML5 and CSS3 for the design of the elements and the jQuery library (which in turn is programmed using JavaScript) to enhance the user experience through the animation of the web elements. Finally, MapServer is used to provide maps services using the OGC WMS12 standard. On the other hand, three different technologies are mixed in the back-end layer. Specifically, the SDSS service is implemented using PHP, whereas the input and output data parsers and the inference engine are implemented using Java. The initial idea was to implement all parts of the back-end using PHP due to its light memory footprint, ease of programming and seamless integration with other remote services (such as the message queuing server or the database). However, it was necessary to use Java for the Inference engine because Drools (which is the selected rule-based inference engine) requires Java to run. Finally, PostgreSQL is the DBMS picked to implement the Internal database due to the geospatial capabilities provided by the PostGIS extension.

6 MapServer official web site: http://www.mapserver.org 7 Java official web site: http://www.java.com 8 Drools official web site: http://www.drools.org 9 PostgreSQL official web site: http://www.postgresql.org 10 ISO/IEC 9075:2011 specification: http://www.iso.org/iso/home/search.htm?qt=9075&sort=rel&type=simple&published=on 11 PostGIS official web site: http://www.postgis.net 12 OGC WMS standard web site: http://www.opengeospatial.org/standards/wms


18


3.1.3 Required interfaces

The SDSS module retrieves all input data from the Cloud database through the service bus. There are two sources for the data: (i) measured information supplied by the water utility (e.g. pressure, level, flow measurements), and (ii) information generated by other UrbanWater modules (e.g. demand predictions, water availability on reservoirs, leakages on WDN, etc.). Thus, it is expected that each one of the UrbanWater modules providing data used in the rules has implemented a service to upload them to the Cloud database. The list of services required by the SDSS module is the following:

uw.service.cds.meteorological.list: provides the list of available variables (e.g. volume of a reservoir, outflow of a WTP, etc.) for a water utility. This information will be used in the SDSS to link these variables to elements’ variables.

uw.service.cds.meteorological.get: provides the values corresponding to a given element (e.g. a WTP or a pump station) and variable (e.g. volumes or flows) in the given time interval. This service will be used to retrieve data supplied by the water utilities and by other modules such as the WAPS, the WDPS, or the LDS.

In addition to these services, the prototype will be subscribed to the following events to be informed when new data is available in the platform:

uw.event.cds.newdemandprediction: This event is sent every time a demand prediction (calculated by

the WDPS module) is stored in the database.

uw.event.cds.newavailabilityprediction: This event is sent every time a new availability prediction

(calculated by the WAPS module) is stored in the database.

uw.event.cds.newleakagedetection: This event is sent every time the LDS makes a new calculation.

uw.event.cds.newutilitydata: This event is sent every time that new data from the water utilities is

stored in the database.

The reference for the description of these services can be found in Section 2.8.3 of UrbanWater Deliverable D6.5. The description of the implementation of the cloud database prototype and specifically the services it offers is available in UrbanWater Deliverable D3.4 “Data management cloud platform implementation”.

3.1.4 Required data

In order to deploy the SDSS in a water utility, the first task is to understand how the water utility operates its water supply system. The result of this task is a set of operational rules that represent the management decisions made. From these operational rules, a set of elements (reservoirs, WTPs, urban areas, boreholes, etc.) has to be considered to operate the supply system. For each of these elements several variables (inflows, outflows, current level, consumption, etc.) are then taken into account in these rules. Thus, the required data to validate the SDSS in a water supply system depend on the operational rules defined to operate the system and the information used by them. In conclusion, the data needed by the SDSS has been defined based on the operational rules that represent how a water utility operates its water supply system. The list of operational rules defined to validate the prototype on each pilot site is detailed in Deliverable D7.1. From these rules, the list of data required is also specified.


19


3.2 Internal database development

The SDSS prototype presented in this document includes an internal database to store all the necessary information used by the SDSS module. This information can be divided into information related to the water supply system (elements and operational rules), and user interface information. For each of them a database diagram is detailed and the description of each table is provided.

3.2.1 Water supply system data

These data define how each water utility operates the water supply system, and basically consists of the logical information (description of each element within the water supply system and their relationships with other elements) and the operational rules that define how the water supply system is operated. Figure 3 presents the UML diagram corresponding to the part of the internal SDSS database that stores this information. The diagram is a simplified version of the one presented in Section 3.4 of the UrbanWater Deliverable D4.2, where it is assumed that the user interface does some additional checks that were not envisaged in the design stage.

Figure 3: Water supply system data UML diagram.

The tables integrating the internal database can be divided into two groups: tables related to define water supply system model and tables related to define operational rules. The tables that define water supply system (e.g. elements, fields and logical relationships) are the following:

ElementDefinition: This table contains the definition of the different type of elements available in a water supply system (e.g. reservoir, WTP, urban area, borehole, etc.).

ElementInstance: This table defines the different elements existing in a water supply system (e.g. Odelouca reservoir, Bernal1 borehole, etc.).

FieldDefinition: This table contains the list of fields (variables and parameters) of a type of element defined in ElementDefinition table (e.g. max_volume, current_level, total_demand, coordinates, etc.).

FieldInstance: This table defines the different fields existing for a specific element of the water supply system (e.g. max_volume of Odelouca reservoir, current_level in Bernal1 borehole, etc.).


20


Regarding the operational rules part, a rule can be described as a condition (defined in the “Operation” table) and a set of operations or actions (each of them defined in “RuleConsequent” table) that would be performed in case the condition is true. According to this, the tables used to define the rules are:

Rule: This table defines a concrete rule to operate the water supply system. The SDSS allows defining several rules that represent the knowledge regarding how water utilities operate their supply systems.

Operation: This table defines an operation, that can be: o A logical (and, or, not) or mathematical comparison (e.g. less or equal, different, greater than,

etc.). o A mathematical operation (e.g. sum, subtraction, division, etc.). o A mathematical function (e.g. maximum, minimum, mean, etc.). o A field instance. o A constant value. o An assignment of an operation to a field instance.

RuleConsequent: This table defines the list of operations (defined in the Operation table) to perform in case rule conditions are true.

The rows of the “Operation” table represent different type of operations that can be between two elements or applied to one single element. In addition, there are some restrictions to define these operations (e.g. an assignment operation cannot be applied to a constant value). All these restrictions that were considered in the initial database design proposed in UrbanWater Deliverable D4.2 are taken into account in the SDSS user interface.

3.2.2 User interface data

These data defines the structure of the user interface. The aim of storing the user interface structure in the database is to follow the Content Management System (CMS) philosophy, used in several web solutions like Drupal or Joomla. In this case, the user interface is divided into modules, views and components, where:

A module is composed of a set of views. There are two modules in this prototype: the SDSS itself and the administration module.

A view is a user interface composed of several components. For example, in the case of the SDSS module, it is composed of two views: the physical view and the logical view.

A component is the minimum element integrating the views. T ables, drop-down menus, buttons, etc. are examples of components.

Figure 4 presents the database UML diagram that stores the user interface data in the SDSS internal database

Figure 4: User interface data UML diagram.


21


In this diagram, tables “Module”, “View” and “Component” correspond to the user interface elements described before, while table “Account” stores the information related to the water utilities. Thus, it is possible to assign only certain modules to each water utility creating the appropriate relationships.

3.3 Front-end development

The front-end part corresponds to the development of the SDSS User Interface (UI). This user interface has been developed according to the design presented in section 3.5 “SDSS Use cases” of the UrbanWater Deliverable 4.2 (page 44). In order to integrate the SDSS module into the UrbanWater platform, the user interface look and feel has been adapted to UrbanWater’s platform style guidelines. Therefore, its design slightly differs from the design presented in Deliverable D4.2. Currently the SDSS prototype front-end is fully integrated into the UrbanWater platform. The User Interface is presented in detail in Annex I (Section 7) as a user manual explaining how to interact with the module. The user interface has been developed using Symfony PHP framework. This framework uses the Model-View-Controller (MVC) architecture, and is divided into several elements that reduce and optimize the source code to be written, allowing a high scalability and source code re-use. The elements involved in the Symfony framework are: Object-Relational Mapping (ORM): Symfony is able to communicate with the database using an ORM

engine. From the developer point of view, the database abstraction is totally invisible because it is handled natively by PHP Data Objects. So if any change is done into the database engine, the developer has no code to refactor. This engine helps the developer to translate the stored data in something comprehensible.

Model: the model is a set of pre-generated classes that help the developer to deal with the data. It’s just a simple way of representing raw data with objects. It’s always easier to work with objects than arrays or any other raw data type.

Services: this layer is a set of functions defined by the developer. It contains the logic and operations the application is going to execute.

Controller: the controller is in charge of receiving and sending the requests from and to the graphic interface. It receives the user’s inputs and events and redirects the requests to the right part of the system.

UI elements: These elements are the source code related to the visualization.

Each one of the user interface elements (that is, the modules, views and components presented in section 3.2.2) has its single source code file. Thus, it is possible to add a new view creating the view instance in the database and assigning there the components that represent the view. The developer should write then the source code of the components that are not already created.

Within the UrbanWater project the components used by the SDSS have been developed using PHP, following the styling rules defined in the Katniss13 template Cascade Style Sheets (CSS).

3.3.1 User interface components developed for the SDSS prototype

Several components have been developed to implement the SDSS user interface. This section presents in detail the development of the more specific components developed for the prototype, named: the logical map, the rule builder and the physical map.

13 Katniss Premium Admin Template: http://themeforest.net/item/katniss-premium-admin-template/3878281


22


3.3.1.1 Logical map

In order to display a water supply system logical map, a component has been developed. This component has to retrieve from the internal database all the water supply system elements defined by the water utilities and the relationships between them. T hus, the component presents the logical map depicting how water is supplied from one element to others. Figure 5 presents an example of a logical map:

Figure 5: Example of a water supply system logical map. Boxes represent the elements of the system, and black arrows indicate how water is transferred from one element to the other.

This component has been developed using JointJS14 library. This library, written in Javascript, is a complete tool to create advanced visual diagrams. It allows creating diagrams like organization charts, UML class diagrams, logic circuits, etc. In addition, styling and new elements (boxes, circles, or even a new one) can be easily added to our diagrams. A jQuery plugin has been developed to display water supply system logical map using the information supplied by the internal database.

3.3.1.2 Rule builder

In order to modify operational rules defined in a water supply system, a component has been developed to add, modify or remove the operational rules defined by water utility operators. This component is able to create the rules and add all the restrictions that are behind the operational rules. These restrictions, for instance, have to consider that elements within mathematical comparisons are not able to include logical operators (and, or, not); or assignments can only be applied to variables defined in the water supply system elements. A jQuery plugin has been developed considering all the restrictions to be taken into account when defining the operational rules. This component is able to load all the information of one rule that is stored in the internal database and display it, and store this rule again in the database if needed once modified. Figure 6 presents the floating window that allows editing operational rules.

14 JointJS webpage: http://www.jointjs.com/


23


Figure 6: Rule builder component floating window, with one operational rule loaded in order to be modified.

3.3.1.3 Physical map

The physical map component, which has been developed in JavaScript using the OpenLayers15 library, consists on a geo-referenced map where different elements (mainly raster images and points) are overlapped, displaying different icons according to the type of the elements (e.g. reservoirs, WTPs, urban areas, etc.). Figure 7 illustrates an example of a physical map, in this case representing part of the Algarve water supply system:

Figure 7: Physical map example of part of the Algarve water supply system. Each icon (WTPs, reservoirs and urban areas) represents an element of the water supply system.

3.3.2 Interaction with the internal database

The front-end layer interacts with the SDSS internal database in two ways: (i) to acquire information related to modules, views and components to display, and (ii) to acquire information regarding the last SDSS simulation results. Typically all this information is stored in a SQL database like MySQL or Oracle. In the case of the SDSS calculations, this prototype stores this information in JSON files, while the rest of the information (water supply system topology and operational rules) is stored in a PostgreSQL database. This allows reducing the response time when retrieving this information, because the access to a specific file is usually faster than to the query a database. Moreover, these files are structured in folders to reduce its access time. The JSON storing the results of the SDSS calculations are generated according to the structure of the example presented in Listing 1.

15 OpenLayers webpage: http://openlayers.org/


24


[

{

"id": "858d86d9-0a34-4237-8e63-03761ceb9f97",

"name": "Odelouca",

"type": "reservoir",

"parameters":

[

{

"name": "lon",

"unit": "º",

"value": "-7.782692"

},

{

"name": "lat",

"unit": "º",

"value": "37.047594"

},

{

"name": "storage_capacity",

"unit": "m3",

"value": "0"

}

],

"variables":

[

{

"name": "level",

"unit": "m",

"value": "0.89"

},

{

"name": "outflow",

"unit": "m3/s",

"value": "15.3"

},

{

"name": "volume",

"unit": "m3",

"value": "1.2"

}

]

}

]

Listing 1: Example of a JSON file with results calculated by the inference engine.

This structured format consists of an array of elements, where each element is an object composed of several fields: identifier, name, type, parameters and variables. The parameters and variables are arrays of objects, where each of them is composed of the name of the parameter or object, the unit and the value. With this structure, the front-end is able to retrieve this information each file and prepare it to display this information in the user interface. This information is populated according to water supply system elements available in the internal database.

3.4 Back-end development

This section explains the development of the back-end elements of the SDSS, which are the SDSS service, the input and output data parsers, and the inference engine. For a general overlook, Figure 8 illustrates the paths followed by the interactions foreseen between the UrbanWater platform and the SDSS module, and also between the internal elements of the module like a pseudo sequence diagram. This figure puts into context the individual elements that are depicted in this section. The SDSS module is designed to hold three different types of interaction with the UrbanWater platform: (i) requests to the services, (ii) acknowledgement of events, and (iii) graphical content through the user interface. On the one hand, the requests addressed to the interfaces offered by the SDSS module (purple path in the figure) as well as the events and the request of data (green path in the figure) are managed through the


25


platform’s Service bus and managed by the SDSS service component. On the other hand, the specific GUI of the SDSS module communicates directly with the UrbanWater platform front-end (red path in the figure).

Figure 8: External and internal interactions of the SDSS module.

Manage and incorporate new data (green path) When new data coming from the LDS, the WAPS, the WDPS or the water utilities is available, the Cloud database sends an event to the Service Bus, which will forward the event to the services subscribed including the SDSS. When the SDSS service receives the event informing that there are new data available, it immediately retrieves them from the Cloud database through the corresponding service, and makes it available to the Input data parser. Next, the Input data parser retrieves the essential information (e.g. elements and rules) from the Internal database, and transforms this knowledge into an understandable format for the Inference engine. Subsequently, the Inference engine computes the new status of every site (water supply system) registered in the SDSS module and sends the results to the Output data parser, which stores them in the Internal database so that they can be provided to any UrbanWater module upon request. In the last step, the SDSS service sends an event to the Service Bus to inform that a new simulation has been run. Process the requests to the services (purple path) Any UrbanWater module can make requests to the interfaces offered by the SDSS module. Such requests must be sent through a message in the Service bus addressed to the SDSS service component. Next, the SDSS service asks the Internal database for the data requested. Finally, the XML structure containing the information requested is returned to the UrbanWater module that accessed the interface. User interface (red path) The SDSS module provides its own graphical user interface, implemented through a web page that is integrated in the UrbanWater’s platform common user interface. When the user selects the SDSS section in the UrbanWater


26


platform web site, it generates a request to the SDSS module to load the specific GUI. Internally, the SDSS GUI retrieves the data needed from the Internal database, and displays them.

3.4.1 SDSS service

The SDSS service component is in charge of listening to the platform’s Service bus and capturing the messages addressed to the SDSS module. As it was explained in the introduction, the SDSS service is prepared to process two types of messages: (i) requests to the interfaces (services) offered; and (ii) events received from the platform (for example, regarding the availability of new data in the Cloud database). RabbitMQ16 is the message queuing server used in the Service Bus (see Section 3.1 of UrbanWater Deliverable D6.2 “UrbanWater Platform Architecture Design” on page 17) that complies with AMQP (Advanced Message Queuing Protocol), which is a protocol standard for messaging middleware. In the case of the SDSS service, PHP is the language chosen for the implementation (see Section 3.1.2), thus a suitable PHP client for AMQP messaging protocol was needed. The php-ampqlib17 PHP library was selected to carry out the communication with the RabbitMQ message queue server as suggested in the official RabbitMQ tutorials page18. The basic steps to establish a connection with the message queuing server and receive the messages are the following:

1. Connect to the RabbitMQ server. Several pieces of information are needed by a client to establish an AMQP connection and put it into a ready state for normal use (“AMQP URI Specification” 2015). These connection parameters include:

a. Host address and port, which are the parameters needed to establish the underlying TCP/IP connection to the server.

b. Information to authenticate the client. AMQP uses SASL (Simple Authentication and Security Layer, see IANA 2014 for further information). Typically the PLAIN mechanism is used, and therefore the authentication parameters consist of a username and a password.

c. The name of the virtual host (or vhost) that specifies the namespace for entities (exchanges and queues) referred to by the protocol.

2. Create a channel and bind it to the desired queue and exchange , which are necessary for the RabbitMQ broker to forward the messages from the publishers to the consumers.

3. Start listening to the queue, indicating which is the function that will process the messages. Next sections offer a summary of the SDSS service implementation using PHP and the description of the offered interfaces.

3.4.1.1 PHP implementation of the SDSS service

With the objective of managing the messages received through the Service Bus, a PHP application has been designed and implemented, leading to the class diagram shown in Figure 9.

16 RabbitMQ official site: http://www.rabbitmq.com 17 php-amqplib web page: https://github.com/videlalvaro/php-amqplib 18 RabbitMQ tutorials: http://www.rabbitmq.com/getstar ted.html


27


Figure 9: Class diagram of the SDSS platform service.

The entry point to the SDSS service is a main file that creates an instance of the UWServiceManager class and invokes the “run()” method. The UWServiceManager class implements the Application interface, which together with the Properties and the Log class constitute an internal framework that provides basic utilities such as ensuring that only one instance of the process is running at the same time, a manager of configuration files, or a logging utility. The constructor of the UWServiceManager class is in charge of loading the configuration files through the Properties class and creating an instance of the Log class. Table 2 describes the properties currently included in the configuration file.

Property Description log_file Full path of the file where the Log class will store all messages

sb_service_name Informative name of the service that will not be used as an identifier (e.g. SpatialDecisionSupportSystemService).

sb_service_id Identifier of the service (e.g. uw.service.sdss) sb_host Host of the RabbitMQ message queuing server

sb_port Port that the host of the RabbitMQ message queuing server is listening to sb_user Username used to access to the RabbitMQ message queuing server

sb_password Password corresponding to the username sb_vhost Virtual host assigned (e.g. /UW-DEV)

sb_exchange Exchange where the queue is matched (e.g. UW-DEFAULT-EXCHANGE) sb_queue Queue assigned to the service (e.g. decisionSupportSystem)

resources List of resource-class pairs indicating which class is appropriate to handle the requests addressed to a specific resource. For example, “monitoring:MonitoringResource;sdss:SDSSResource;event:EventResource” means


28


Property Description

that class MonitoringResource will attend to the petitions of resource “monitoring”, class SDSSResource will attend to the petitions of resource “sdss”, and class EventResource will attend to the events subscribed.

Table 2: Properties included in the configuration file of the SDSS service.

The “run()” method is responsible for connecting to the RabbitMQ server, creating a channel and binding it to the corresponding queue and the exchange, and start listening to the queue, which correspond to the basic steps described in Section 3.4.1. The connection is created with an instance of class AMQPConnection using the user-configured parameters (e.g. properties “sb_host”, “sb_port”, “sb_user”, “sb_password”, and “sb_vhost”). Next, the channel is obtained through the connection, and is bound the queue and the exchange. The last step is done through the function basic_consume, which makes the channel listen to the specified queue, and also indicates which method (callback) will process the incoming messages. In this case, this callback function is “processRequest”. Function “processRequest” determines which is the correct Resource subclass to address the petition (that can be an event or a request to a service), creates a RoutingKey object, and forwards the petition. From this point and onward, the responsibility of doing the specific tasks needed to attend to the request falls on the corresponding resource – EventResource, MonitoringResource or SDSSResource in this case, which at the end of the process sends the response message to the queue using the routing key provided using function basic_publish of class AMQPMessage if necessary.

3.4.1.2 Offered interfaces

The SDSS module offers in total three services: one related to the Monitoring resource, and the other two related to the SDSS resource. The resource ID (which is necessary to invoke the interface), and the inputs and outputs as well as a description are provided in next sections for each service.

3.4.1.2.1 Interfaces of the Monitoring resource XML This service provides information regarding the service itself, like the service ID, the service name, the service version, the number of seconds that the service has been running, the system local time, the percent of CPU usage, the amount of memory used, and the number of bytes transmitted and received through the network interface. This information is packaged into an XML structure following the specifications provided in the “Monitoring Service” section of the UrbanWater development wiki19.

Resource ID: uw.service.monitoring.xml Inputs:

o This service does not require any input parameter.

Outputs: o XML structure with the information regarding the service itself (service ID, service name,

service version, seconds of up time, system local time, percent of CPU usage, amount of memory used, and number of bytes transmitted and received through the network interface) as specified in the UrbanWater development wiki.

o Response example: <ServiceInformation>

<ID>uw.service.sdss</ID>

<Name>SpatialDecisionSupportSystemService</Name>

<Version>0.0.1</Version>

19 http://dev.urbanwater-ict.eu/wiki/PlatformServices/MonitoringServices/MonitoringService


29


<Uptime>28</Uptime>

<LocalTime>2015-02-24T14:38:01+01:00</LocalTime>

<UsageOfCpu>29.3</UsageOfCpu>

<UsageOfRam>1.25</UsageOfRam>

<NetworkRxBytes>3754321</NetworkRxBytes>

<NetworkTxBytes>1422596</NetworkTxBytes>

</ServiceInformation>

Listing 2: Example response to a request to uw.service.monitoring.xml.

3.4.1.2.2 Interfaces of the SDSS resource Get elements This service provides the list of elements (e.g. reservoirs, water treatment plants, urban areas, etc.) that belong to the specified water supply system. It is important to remark that in the SDSS prototype presented in this document it is assumed that a water utility operates only one water supply system. The input of the service is the identifier of the water utility and the output is an XML structure with the list of elements.

Resource ID: uw.service.sdss.sdss.getelements Inputs:

o systemID (String), which is the identifier of the water utility. o Request example:

<request>

<systemID>

tavira_verde

</systemID>

</request>

Listing 3: Example request to uw.service.sdss.sdss.getelements.

Outputs:

o Set of element (XML) containing the list of elements that belong to the specified water utility. o Response example:

<response>

<element>

<name>Odelouca</name>

<type>reservoir</type>

<elementID>odelouca_res</elementID>

</element>

<element>

<name>Tavira WTP</name>

<type>wtp</type>

<elementID>tavira_wtp</elementID>

</element>

</response>

Listing 4: Example response to a request to uw.service.sdss.sdss.getelements.

Get status Given an element identifier, this service provides the list of parameters and variables and the values currently assigned for a given element.

Resource ID: uw.service.sdss.sdss.getstatus Inputs:

o elementID (String), which is the identifier of the element. o Request example:

<request>

<elementID>odelouca_res</elementID>

</request>

Listing 5: Example request to uw.service.sdss.sdss.getstatus.


30


Outputs: o XML structure containing the name and type of the element, and the set of parameters and

variables. Moreover, the name, type, unit, and value are returned for each parameter or variable.

o Response example: <response>

<name>Odelouca</name>

<type>reservoir</type>

<parameterSet>

<parameter>

<name>max_capacity</name>

<type>float</type>

<unit>hm³</unit>

<value>102.4</value>

</parameter>

<parameter>

<name>max_outflow </name>

<type>float</type>

<unit>m³/s</unit>

<value>12.5</value>

</parameter>

</parameterSet>

<variableSet>

<variable>

<name>capacity</name>

<type>float</type>

<unit>hm³</unit>

<value>74.5</value>

</variable>

<variable>

<name>outflow </name>

<type>float</type>

<unit>m³/s</unit>

<value>8.9</value>

</variable>

</variableSet>

</response>

Listing 6: Example response to a request to uw.service.sdss.sdss.getstatus.

3.4.2 Data parsers and inference engine

The Input data parser component is in charge of preparing all necessary information so that the Inference engine can process it. The Inference engine is the main component of the SDSS back-end as it combines the rules defined for each site with the information provided (e.g. measured data, metering data, forecasted data, etc.) coming from various sources in order to calculate the value of the element’s variables according to the rules defined. The Output data parser component collects the results of the execution of the inference engine, and transforms and stores them in the Internal database. Those three components of the SDSS back-end have been implemented in a single Java application (Java is the programming language used in this part as explained in Section 3.1.2), where classes SDSSInferenceEngine, DataManager, Element, DataUnit, and DataType have been defined (see Figure 10).


31


Figure 10: Java classes defined for the data parsers and the inference engine SDSS components.

Class SDSSInferenceEngine contains the “main()” function, thus is the entry point to the application. After the initialization of the basic resources (like the connection to the PostgreSQL Internal database or the configuration of the logging utility for debugging and error tracking purposes), the tasks related to the Input data parser are the first to be done before running the Inference engine.

3.4.2.1 Implementation of the input data parser

The implementation of the tasks corresponding to the Input data parser is described in the next subsections. Basically, the tasks consists on (i) retrieving the SDSS elements stored in the Internal database into Java objects, (ii) populating the variables of the SDSS elements with the external data supplied by the Cloud database, and (iii) retrieving the SDSS rules stored in the Internal database and translating them to DRL (Drools Rules Language). Retrieve the elements of the SDSS In order to retrieve the elements of the SDSS, the method “loadElements()” of class DataManager is called from the “main()” function of the SDSSInferenceEngine. Such method follows the following main flow:

1. Execute the query that retrieves the entire collection of SDSS elements stored in the PostgreSQL Internal database.

2. For each SDSS element retrieved, create an instance of class Element using the information previously read, which essentially is the database identifiers and the name and type (e.g. reservoir, WTP, borehole, etc.) of the element, and execute the query that retrieves the parameters and variables defined for the element from the Internal database. As a reminder, the difference between parameters and variables is that the value assigned to the variables can be modified through the rules, whereas the value of the parameters cannot (see Section 3.1 of UrbanWater Deliverable D4.2 on page 23 for a detailed explanation of the SDSS elements, parameters, and variables).

3. Next, for each parameter retrieved the function addParameter of class Element is called. This function creates a DataUnit instance (setting “is_adjustable” to false) and adds it to the “parameters” dictionary using the parameter identifier as the key. Analogously, function addVariable is called for each variable retrieved, which creates an instance of DataUnit (setting “is_adjustable” to true) and adds it to the “variables” dictionary.


32


Populate the variables of the SDSS elements Once the elements have been instantiated, the data coming from the Cloud database can be introduced to the corresponding variables. At the introduction of Section 3.4 it was said that the SDSS service retrieves the new data and makes it available to the Input data parser component. Specifically, the XML structures containing the data are stored in files into a data input folder created with this purpose. Therefore, the population process consists on reading and decoding each one of the XML files and calling the function “setVariableValue(id, value)” of the corresponding element. Retrieve and parse the SDSS rules In the last task, the Input data parser executes the query to retrieve the different parts that make up the rules (e.g. the corresponding rows from the “Rule”, “RuleConsequent”, and “Operation” tables) from the Internal database. Next, the rules are built in DRL format. Essentially, a DRL rule consists of the Left-Hand Side (LHS) and Right-Hand Side (RHS) blocks (see Listing 7). In an “if-then” condition-action rule, LHS corresponds to the “if” part and follows certain special syntax, whereas RHS corresponds to the “then” part and allows specific semantic code to be executed. LHS block is composed of patterns, which are Java classes with restrictions applied (see “Drools Documentation Version 6.0.1” for a complete reference of the DRL). rule “name”

when

LHS

then RHS

end

Listing 7: Basic structure of a DRL rule.

For example, the translation of the rule IF reservoir1.level LT 10 THEN reservoir1.outflow = 0 would result in the code shown in Listing 8. rule “rule1”

when

res1 : Element( name == “reservoir1” )

level1 : DataUnit( id_element == res1.getId(), name == “level”, value < 10.0f )

outflow1 : DataUnit( id_element == res1.getId(), name == “outflow” )

then

res1.setVariableValue(outflow1.getId(), 0.0f)

end

Listing 8: Example DRL rule.

The inference engine looks for all objects of type “Element” where the value of the “name” attribute is “reservoir1”. In the same way, the inference engine looks for all objects of type “DataUnit” named “level” where the related element is “res1” and whose “value” is lower than 10, and also the objects of type “DataUnit” named “outflow” where the related element is “res1”. Notice that although the “outflow” variable does not appear in the “if” part, it is necessary to find the reference because it will be used in the “then” part. If all conditions of the LHS are met, Drools will execute the code in RHS, which in the example consists on using the references created in the RHS to assign the new value to the “outflow” variable. The process described in the previous example is applied to all rules, creating a set of DRL rules sui table for the Drools inference engine.


33


3.4.2.2 Inference engine

The implementation of the Inference engine component consists on the execution of the Drools rule-based inference engine. The Elements, DataUnits and the rules previously prepared must be incorporated to the knowledge base; otherwise Drools would have nothing to work on. Drools provides the appropriate classes and methods to do this. Schematically, the following steps must be done:

1. Create an instance of the KnowledgeBase object. 2. Load the rules in the knowledge base. 3. Create an instance of the KnowledgeSession object for the knowledge base. 4. Insert the elements, parameters, and variables into the knowledge session. 5. Launch Drools.

Once the execution finishes, the Element and DataUnit object instances will have been modified according to the rules.

3.4.2.3 Output data parser

The Output data parser goes across all the Element instances and creates two outputs:

A XML and a JSON file for each element following the structure described in Section 3.4.1.2.2. The resulting XML files are ready to be served to any UrbanWater module requesting the status of an element, whereas the JSON files are used in the SDSS GUI as explained in Section 3.3.2.

A XML file containing the list of elements available in the Internal database following the structure described in Section 3.4.1.2.2.


34


4 Prototype functional validation

This section presents the functional tests performed over the SDSS module in order to validate its development. The user interface testing will be done in the validation phase of the project, and this preliminary prototype validation is mainly focused on the inference engine performance. Specifically, this section aims to validate the data parsers and the inference engine, testing each part separately and then as a whole. The validation of the supplied services has also been passed and is presented in UrbanWater Deliverable 6.5. The goal of this validation is to show that the prototype performs as expected and that all the features are working correctly. However, the goodness of the results and their alignment to the expected values in a real site is left for Deliverables D7.2, D7.3 and D7.4. The tests have been run in a desktop computer with the following specifications:

Apple OSX Yosemite (10.10.2)

Intel Core i5 2.4GHz CPU. 16GB RAM DDR3.

SSD 256GB disk. The following sections will present each one of the validation points (e.g. inference engine), and a summary table is provided at the end with the results of each test.

4.1 Inference engine validation

The inference engine validation covers the process that acquires all the information from the water utilities and other UrbanWater modules, retrieves the available rules from the internal database, convert these rules into Drools format, performs the inference engine, stores this calculation into the internal database and finally notifies to other UrbanWater modules a new calculation is available. Each of these steps has been validated individually.

4.1.1 Validation water supply system

In order to validate the inference engine, a water supply system has been defined. This water supply system has been defined using one of the pilot sites that will be used in the validation as a reference. Thus, the elements involved in this water supply have been specified and the operational rules that define how it is operated are listed. The logical map of the water supply system is presented in Figure 11, describing how water is supplied between elements:


35


Figure 11: Validation water supply system.

The description of all these elements is available in Annex III (Section 9). From all of them, the validation will be focused only on the WTP defined with the “ALC” acronym in the figure above. This element corresponds to the Alcantarilha WTP of the Algarve water supply system that is operated by Águas do Algarve. This element will be used to present an example of the Java objects used by the inference engine and the XML results of the services. Table 3 presents the variables and parameters of this element:

Name Type Value

Max_flow Parameter 259.000 m3/day

Min_flow Parameter 40.000 m3/day Flow Variable

Table 3: ALC WTP parameters and variables.

The operational rules defined to operate this water supply system aim to determine the amount of water each WTP has to produce to meet the predicted demand. In addition, there are some preferred WTPs to be used than others, and restrictions regarding elements maximum capacity must be taken into account. Finally, these rules must calculate the how water is supplied from reservoirs to WTPs considering reservoirs volume and their predicted evolution. The list of rules defined to validate the SDSS prototype is available in Annex III (section 9.2). This test will simply validate the water supply system under normal circumstances, where WTPs are able to produce water to meet predicted demand and reservoirs are able to supply this water to the WTPs. The initial conditions are then as follow: BRA.predicted_contribution := 0

BRA.volume = 22.325.000

ODE.predicted_contribution := 0

ODE.volume = 94.000.000

GUA.predicted_contribution := 0

GUA.volume = 104.600.000

LVDB.predicted_demand := 20.000

SP.predicted_demand := 45.000

FO.predicted_demand := 200.000


36


TVRSAA.predicted_demand := 37.000

Listing 9: Water supply system initial conditions.

4.1.2 Input data parser

This test is oriented to verify rules presented in the previous section are properly written in Drools Rule Language (DRL) format. Each of these rules has been generated as expected with the correct syntax. The performance of this process is available in the summary table presented in Section 4.2. The result of converting one rule to the DRL format is presented in the following listings, where Rule – 6 (that is defined in Annex III section 9.2) is converted to Drools DRL format: IF (FO.predicted_demand + TVSAA.predicted_demand) > TAV.max_flow AND (FO.predicted_demand +

TVSAA.predicted_demand) – TAV.max_flow > (ALC.max_flow – (LVDB.predicted_demand +

SP.predicted_demand)) AND (FO.predicted_demand + TVSAA.predicted_demand) – TAV.max_flow <=

REV.max_flow THEN

REV.flow = ALC.max_flow - (LVDB.predicted_demand + SP.predicted_demand)

TAV.flow = TAV.max_flow

ALC.flow = (LVDB.predicted_demand + SP.predicted_demand) + REV.flow

BEL.flow = (FO.predicted_demand + TVSAA.predicted_demand) – TAV.flow – REV.flow

FI

Listing 10: Rule – 6 logical definition.

rule "Rule - 6"

when

// Added due to antecedent

elem_1 : Element( name == "FO" )

v_predicted_demand_elem_1 : DataUnit( idElementInstance == elem_1.getId(), name ==

"predicted_demand" )

elem_3 : Element( name == "TVRSAA" )



elem_5 : Element( name == "TAV" )

v_max_flow_elem_5 : DataUnit( idElementInstance == elem_5.getId(), name == "max_flow" )








v_max_flow_elem_11 : DataUnit( idElementInstance == elem_11.getId(), name == "max_flow"

)

elem_13 : Element( name == "ALC" )


)















)

elem_25 : Element( name == "REV" )


)


37


eval( ((Float)v_predicted_demand_elem_1.getValue() +

(Float)v_predicted_demand_elem_3.getValue()) > (Float)v_max_flow_elem_5.getValue() &&

(((Float)v_predicted_demand_elem_7.getValue() + (Float)v_predicted_demand_elem_9.getValue()) -

(Float)v_max_flow_elem_11.getValue()) > ((Float)v_max_flow_elem_13.getValue() -

((Float)v_predicted_demand_elem_15.getValue() + (Float)v_predicted_demand_elem_17.getValue()))

&& (((Float)v_predicted_demand_elem_19.getValue() +

(Float)v_predicted_demand_elem_21.getValue()) - (Float)v_max_flow_elem_23.getValue()) <=

(Float)v_max_flow_elem_25.getValue() )

// Added due to consequent


v_flow_elem_29 : DataUnit( idElementInstance == elem_29.getId(), name == "flow" )



)

elem_33 : Element( name == "LVDB" )



elem_35 : Element( name == "SP" )







)



elem_43 : Element( name == "LVDB" )



elem_45 : Element( name == "SP" )





elem_49 : Element( name == "BEL" )










)



then

v_flow_elem_29.setValue(((Float)v_max_flow_elem_31.getValue() -

((Float)v_predicted_demand_elem_33.getValue() +

(Float)v_predicted_demand_elem_35.getValue())));

v_flow_elem_37.setValue((Float)v_max_flow_elem_39.getValue());

v_flow_elem_41.setValue((((Float)v_predicted_demand_elem_43.getValue() +

(Float)v_predicted_demand_elem_45.getValue()) + (Float)v_flow_elem_47.getValue()));

v_flow_elem_49.setValue(((((Float)v_predicted_demand_elem_51.getValue() +

(Float)v_predicted_demand_elem_53.getValue()) - (Float)v_max_flow_elem_55.getValue()) -

(Float)v_flow_elem_57.getValue()));

end

Listing 11: Rule – 6 represented in DRL format.

4.1.3 Inference engine

The aim of this validation is to verify the inference engine calculates a result using the configuration previously generated. As described in sections above, the inference engine creates Java objects from each water supply element. An example of how each element is created by the inference engine is: Element: ALC (wtp) [0b968dff-83cd-42f4-9d93-e2b6555e5b1b]

Parameters:

min_flow (FLOAT) 40000.0 m3/day [127efe84-c24d-11e4-b3c7-5f23d3bbfe0c]


38


max_flow (FLOAT) 259000.0 m3/day [127e7b62-c24d-11e4-b3c6-e3fa28f83ecc]

Variables:

flow (FLOAT) null m3/day [127f8840-c24d-11e4-b3c8-076c67cbdb2d]

Listing 12: ALC WTP java object before running the inference engine.

Under the conditions explained before and taking into account the operational rules defined, the results calculated by the inference engine are: FON.flow := 0

ALC.flow := 105.000

REV.flow := 40.000

TAV.flow := 190.000

BEL.flow := 7.000

BRA.outflow := 0

SIL.outflow := 5.250

ODE.outflow := 99.750

GUA.outflow := 197.000

Listing 13: Test results calculated by the inference engine.

These results consist on the elements fields that have been modified on each of the Java objects used by the inference engine. Once the inference engine has been executed, the Java object state is as follows: Element: ALC (wtp) [0b968dff-83cd-42f4-9d93-e2b6555e5b1b]

Parameters:

min_flow (FLOAT) 40000.0 m3/day [127efe84-c24d-11e4-b3c7-5f23d3bbfe0c]

max_flow (FLOAT) 259000.0 m3/day [127e7b62-c24d-11e4-b3c6-e3fa28f83ecc]

Variables:

flow (FLOAT) 105000.0 m3/day [127f8840-c24d-11e4-b3c8-076c67cbdb2d]

Listing 14: ALC WTP Java object after running the inference engine.

As seen, the flow field of the ALC Java object has been modified when running the inference engine. In conclusion, the inference engine works as expected, creating Java objects from each water supply system element, running Drools and finally modifying these Java objects. Last step of the process is to generate a JSON file from these objects. The JSON file generated from this example is as follow: [

{

“id”: “0b968dff-83cd-42f4-9d93-e2b6555e5b1b”,

“name”: “ALC”

“type”: “wtp”

“parameters”:

[

{

“name”: “min_flow”,

“unit”: “m3/day”,

“value”: “40000.0”

},

{

“name”: “max_flow”,


“value”: “259000.0”

}

],

“variables”:

[

{


39


“name”: “flow”,


“value”: “105000.0”

}

]

},

…

]

Listing 15: JSON file generated by the inference engine once simulation is finished.

4.1.4 Output data parser

The aim of this validation is to test that XML file results are generated for each Java object used by the inference engine. These XML files are the response messages to be sent every time the uw.service.sdss.sdss.getstatus service is invoked. The XML generated with the results for the ALC WTP is: <name>ALC</name>

<type>WTP</type>

<parameterSet>

<parameter>

<name>max_flow</name>

<type>float</type>

<unit>m³/day</unit>

<value>259000</value>

</parameter>

<parameter>

<name>min_flow</name>

<type>float</type>



</parameter>

</parameterSet>

<variableSet>

<variable>

<name>flow</name>

<type>float</type>



</variable>

</variableSet>

Listing 16: XML response file generated for the ALC element.

4.2 Results

Each of the validations has been passed 50 times and the results were automatically stored. In addition, performance results were stored in log files. Table 4 summarizes the average results of all the tests previously presented:

Test Computation time (s)

CPU usage (%) Memory usage (%)

Input data parser 4.2 s 10 % 5 %

Inference engine 3.5 s 40 % 7 %

Output data parser 0.6 s 5 % 5 %

Table 4: Validation table template presenting the validation results in a computer.

These results demonstrate that the developed SDSS prototype is able to perform all the features using low resources within the expected time. This confirms the prototype can be used in real time for the validation in the pilot sites as expected.


40


The input data parser presents the highest execution time. The reason is that it has to read the information from the database. The CPU and memory usage values are also reasonable taking into account that a ll the information has to be read from a database and loaded into memory. As expected, the inference engine is the back-end component that requires more CPU and memory resources. However, the peak CPU consumption registered did not reach 50% of the computer’s capacity, which is a good result taking into account that a realistic water distribution system has been used and that the tests have been run on a desktop computer and not on a server. The output data parser, which generates JSON and XML from the results of the inference engine, only has to write text files. Thus, the computation time and CPU and memory usage is very low, and the computation time depends more on writing the files on disk than on calculations.


41


5 Conclusion and Outlook

5.1 Conclusions

The goal of UrbanWater Task 4.4 “Decision support system”, led by HYDS within WP4 is to develop a system that supports and optimizes water utilities decisions based on real measurements taken within the water supply system and other modules information (demand prediction, prediction of water available on reservoirs, possible leakages that could appear, etc.). This is achieved by defining operational rules that explain how a water utility operates its water supply system. The result of the module is a set of instructions or actions the operator should perform to operate the water supply system. The creation of the Decision Support System, and the rest of the Decision Supporting Tools developed in WP4, follows the software engineering process, which involves three main steps:

1. Requirements definition 2. Software design 3. Prototype development

Accordingly, UrbanWater Deliverable 4.1 covers the first step – requirements definition, where some scenarios and a set of use cases derived from them are presented. These use cases represent all the actions the modules are expected to support; thus, requirements explain what the module should do. UrbanWater Deliverable 4.2 covers the second step – software design, where the design of the WAPS module is described. This design consists of the definition of the architecture, the components, the interfaces, and the module behavior. Summarizing, it describes how the module does what it is expected to do. The design is presented using a small example as a reference, making easier the explanation of the presented design. The present document (UrbanWater Deliverable D4.9) covers the final step – the development of a prototype that fulfills both requirements and design presented, and tasks done to integrate the module within UrbanWater platform. As this document explains, a prototype of a Spatial Decision Support System has been successfully developed, according to requirements and design presented in UrbanWater Deliverables D4.1 and D4.2. This prototype has been totally integrated into the UrbanWater platform and is able to communicate with other UrbanWater through the UrbanWater service bus. In addition, the user interface is also integrated into the UrbanWater platform visualization service. All the functional tests performed with the prototype demonstrate it works as expected and performance is within expected values. The results of these tests stated that it is possible to run the module on real time during the validation phase of the UrbanWater platform and its components.

5.2 Outlook

The actions foreseen regarding the Spatial Decision Support System include the following:

Validation in the UrbanWater validation sites. The prototype will be validated in Portugal, Spain and Czech Republic during the validation phase of the platform. The validation consists of four steps: (i) define the water supply system operational rules of each pilot site; (ii) integrate the water utilities’ data used by the module; (iii) validate the module; and finally (iv) analyze the results.

Module improvements. Due to the interaction with water utilities during the validation in the demo sites several improvements or refinements could be implemented. These may appear because of the interaction with water utilities during the validation, and could be aesthetical refinements or function


42


improvements of the prototype. Several meetings are expected with water utilities to discuss and define possible improvements of the prototype. In addition, it is expected to solve some of the limitations presented in Section 2.3 with these improvements.

It is expected to perform the validation of the module and the continuous improvements during the validation phase. Thus, the results of the validation and the improvements will be included in UrbanWater Deliverables 7.2 “Validation in Almeria”, 7.3 “Validation in Algarve” and 7.4 “Validation in Czech Republic”. These deliverables are due on month 33 (November 2015).


43


6 References

AMQP URI Specification. (n.d.). Retrieved February 19, 2015, from https://www.rabbitmq.com/uri-spec.html

IANA. (2014, November 10). Simple Authentication and Security Layer (SASL) Mechanisms. Retrieved February

26, 2015, from http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Ide, A. (2013, January 31). PHP just grows & grows [Web log post]. Retrieved February 19, 2015 from

http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html

JavaScript Technologies Market Share and Web Usage Statistics. (n.d.). Retrieved February 19, 2015, from

https://www.similartech.com/categories/javascript

Drools Documentation Version 6.0.1.Final. (n.d.) Retrieved February 27, 2015, from

http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/

UrbanWater Deliverable 3.4, 2014: “Data management cloud platform implementation”. European Commission.

UrbanWater Deliverable 4.1, 2014: “Decision supporting tools system requirements”. European Commission.

UrbanWater Deliverable 4.2, 2014: “Decision supporting tools design”. European Commission.

UrbanWater Deliverable 6.1, 2014: “UrbanWater platform requirements definition”. European Commission.

UrbanWater Deliverable 6.2, 2014: “UrbanWater platform architecture design”. European Commission.

UrbanWater Deliverable 6.4, 2014: “UrbanWater platform prototype”. European Commission.

UrbanWater Deliverable 6.5, 2015: “UrbanWater platform demonstrator”. European Commission.

UrbanWater Deliverable 7.1, 2015: “Validation plan”. European Commission.

https://www.rabbitmq.com/uri-spec.html

http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html

https://www.similartech.com/categories/javascript

http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/


44


7 Annex I: Graphical User Interface

This section explains how the SDSS module user interface has been implemented and works, as a user manual, and is divided into three sections: a general description of the user interface, the general view and the SDSS administration view. In general, the SDSS UI is divided into three sections: (i) the sub-modules selector, located in the top part of the screen, (ii) the views selector, located below the sub-modules selector, and finally (iiii) the page content, located in the bottom part. All the views of the SDSS UI share the same module and view selector, and the page contents will differ depending on the selected view. Figure 12 depicts the SDSS UI, highlighting the three sections described above with red boxes.

Figure 12: SDSS user interface sample window. The three sections composing each view (sub-modules selector, view selector

and content) are highlighted with red boxes.

The sub-modules selector section consists of a horizontal menu with the available sub-modules within the SDSS. The SDSS has been divided into two sub-modules: the SDSS itself, where the user analyzes calculations done by the inference engine and logical or physical maps, and the administration menu, where the user modifies the list of the available elements within the water supply system and the logical rules applied to operate the water supply system. When the user clicks on each of the sub-modules, the UI automatically reloads all its contents based on the selected sub-module. Figure 13 presents in detail the sub-modules selector with the two SDSS available sub-modules.

Figure 13: Detail of the sub-modules selector section.

Below the sub-modules selector section, a views selector section is available. This section consists of another horizontal menu where the different views of the current sub-module can be selected. These views are different interfaces allowing the user to perform different features within the module. When clicking on each view the UI automatically reloads itself to display necessary information. Figure 14 provides an example of the views selector.

Figure 14: Example of the views selector section. In this case it presents the available views in the SDSS module.


45


7.1 SDSS sub-module

This module presents all the information related to the calculations done by the SDSS inference engine. This module is divided into two views, logical view and physical view. The only difference is how the water supply system is displayed: either the logical map or physically over a map. The UI component for displaying SDSS calculated information is available below the view selector. This component displays the information calculated by the SDSS of a selected water supply system element (selected from either the drop-down menu, the logical map or the physical map). The component is divided into two sub-components: an element drop-down menu and selected element information. Figure 15 presents this component with its two sub-components.

Figure 15: SDSS sub-module component that presents calculated information of the selected element. A selector is available in

the top part, and the element information is available below.

The element menu consists of a drop-down menu. When pressed it lists all the available elements within the water supply system, indicating its type for each of them.

Figure 16: Element menu unfold, with all the available elements in the water supply system.

When an element is selected, its parameters and variables are shown in a table below. Parameters are static features that do not vary (e.g. maximum capacity, coordinates of the element, etc.), while variables are features that could be modified based on the operational rules defined and current status of the elements. Messages are also shown in case they are added to the element by the SDSS calculations. With all this information, the user is able to understand the future status of the water supply system and actions to be performed (e.g. the amount of water a reservoir has to supply to the WTPs or how drinking water is distributed from a WTP to the urban areas).


46


7.1.1 Logical view

The logical view presents water supply system in form of a logical schema. Each different type of elements (WTPs, reservoirs, consumers, tanks, etc.) has a different style (circles, triangles, boxes, etc.). In addition, element are linked through arrows, indicating how water is distributed between elements. When clicking on each element the information sub-component shows the information related to the selected element. Figure 17 presents a logical map view example.

Figure 17: Logical map of a water supply system. In this map, reservoirs are represented as blue boxes, WTPs are black boxes

and urban areas are white boxes. Arrows indicate how water is distributed from one element to another.

7.1.2 Physical view

The physical map presents how the different elements of the water supply system are distributed over the region. In order to allow an easy interpretation, each element has a different and representative icon according to its element type. Figure 18 presents an example of the physical view of a water supply system.

Figure 18: Physical map presenting three reservoirs, two WTPs and an urban area in the area of Algarve (Portugal).


47


7.2 Administration sub-module

The administration sub-module allows configuring all the information related to the water supply system. As previously said, the module is divided into three sections: sub-modules selector, views selector and the page contents. In the case of the administration sub-module, the contents page is a table with the elements or rules defined and a button to add new elements or rules. Figure 19 presents a general view of the sub-module.

Figure 19: SDSS administration sub-module view.

This sub-module is divided into two different views: elements and rules. The elements view allows adding/deleting/modifying existing elements in the water supply system, while rules view allows adding/deleting/modifying the operational rules defined to operate the water supply system.

Figure 20: Available views in the Administration sub-module.

The following sections present these two views presented in Figure 20.

7.2.1 Elements administration

Elements administration view allows adding/deleting/modifying the list of elements within the water supply system. The contents section of the view consists of a table where all the elements currently defined are listed along with their type, and an edit- and remove button for each of them. It is important to remark that, in order to avoid inconsistencies with the defined rules, only elements that are not involved in operational rules can be removed.. In case an element can’t be removed (because it is involved in defined rules), the remove button of this element is blocked. At the bottom of this table there is a button to add new elements to the water supply system. Thus, the SDSS UI is fully flexible to modify the elements operated in the water supply system. Figure 21 presents an example of this view.


48


Figure 21: Example of the elements table with the available elements in the water supply system.

If the user wants to remove, a confirmation dialog window is shown, displaying the name and type the element to remove. Figure 22 presents an example of this window. This element will be removed when clicking in the “next” button.

Figure 22: Window to add, edit or remove an element.

If the user is adding or modifying the element, a dialog window (see Figure 22 for an example) is shown to set/modify the name of the element and to specify the type of element in case of adding. If the user clicks in the “next” button, the new information will be saved, and another dialog window presenting the element parameters associated with the type of element will be shown. It is important to remark that all the parameter fields must be filled. Figure 23 presents a window example with parameters of an element.


49


Figure 23: Example of a dialog window to set or modify the element parameters.

Next, the user must specify the element variables. Variables can be set to blank, to a specific value, or linked to an available variable in the cloud database. All these variables are the non-static data of the elements. In case of linking a variable field to a cloud database variable, a dropdown menu will be displayed with all the list of available variables in the cloud database. Figure 24 presents an example of a window where element variables can be modified.

Figure 24: Example of a dialog window to set or modify the element variables.


50


Last step when adding or modifying an element is to establish the logical relationships of this element with other water supply system elements. A window with a table of all the other current elements defined within the water supply system will be shown. For each of these elements, the user will be able to indicate whether these elements supply water to the element that is being added or modified, or if the element supplies water to the rest of the elements. This will imply that the logical model of the water supply system will be modified. Figure 25 provides an example of how logical relationships can be defined.

Figure 25: Example of the dialog window to set the logical relationships between a given element and other water supply system

elements.

7.2.2 Rules administration

The rules administration view allows modifying the operational rules defined to operate the water supply system. The contents section of the view consists of a table listing all the operational rules currently defined with an edit and remove button for each of them. At the bottom of this table there is a button to add new operational rules to the system. Thus, the SDSS UI is fully flexible to modify how water supply system is operated. Figure 26 presents a general view of this view.

Figure 26: Example of operational rules table.

A generic dialog window is shown when the user wants to create a new rule or modify or remove and existing one. In this window, the user must specify the rule name for reference, the condition to be validated and the list of


51


actions to perform in case the condition is true. At least one action to perform must be specified, and there is no limit in the number of actions specified. The conditions and the actions can be specified using different drop-down menus, where element variables and parameters are available, and operations (logical comparisons, mathematical comparisons, functions and operators, etc.) can be selected. Actions can be added or removed by clicking in the corresponding button. Figure 27 presents this window, with an example of a defined rule.

Figure 27: Example of the rules edition window. In this case, the rule means “if consumption in the east region is less or equal

than Alcantarilha WTP max outflow, then Alcantarilha WTP inflow is the sum of Odeleite and Arade reservoirs outflow”.


52


8 Annex II: Requirements compliance in the implementation

This section shows how SDSS requirements identified in deliverable UrbanWater Deliverable 4.1 (section 5.3 “Requirements”, page 47) have been accomplished through the proposed prototype. For each of them a filled table is presented using the following template:

Requirement# Code of the requirement used in UrbanWater Deliverable 4.1 Requirement Description of the requirement according to UrbanWater Deliverable 4.1

Comment Brief comment describing how this requirement is accomplished through the proposed prototype

Related section Link to section of this deliverable were the compliance of the requirement is explained.

Table 5: Requirements compliance template.

8.1 Retrieve demand prediction

Requirement# REQ-SDSS-1 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.

Comment The current module prototype is able to connect to the necessary service to acquire this information.

Related section Section 3.1.3

8.2 Retrieve availability prediction

Requirement# REQ-SDSS-2

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.

Comment The current module prototype acquires these data using other UrbanWater module services offered for this purpose.


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

Comment The prototype is able to connect to other UrbanWater modules through their services to acquire this information


8.4 Retrieve water utility data

Requirement# REQ-SDSS-4 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.


53


Comment The current prototype uses UrbanWater cloud database services to acquire these data.


8.5 Modify the topology of the water supply system representation

Requirement# REQ-SDSS-5 Requirement The SDSS should be able to change water supply system logical model

Comment The module prototype has disabled to possibility of modifying the logical model, so in this version is not possible to add, create or modify the topology of the water supply system. A new version of the prototype will allow it.


8.6 Modify SDSS configuration


Requirement The SDSS should be able to modify its configuration Comment The prototype permits to modify the operational rules defined for the water

supply system, as explained in this document. Related section Section 7.2.1

8.7 Compute SDSS status (online mode)

Requirement# REQ-SDSS-7 Requirement The SDSS must be able to calculate a new SDSS status

Comment The inference engine used by this prototype is able to combine all the water utilities information with the operational rules to calculate a new status of the water supply system.


8.8 Compute SDSS status (offline mode)


Requirement SDSS should be able to calculate a new status based on a testing configuration

Comment Currently it is not possible to modify the operational rules and the elements to set up an offline mode. This feature is left for future developments.


8.9 Store SDSS status


Requirement The SDSS must be able to locally store its status within the SDSS Comment Calculations done by the prototype are stored locally in JSON and XML files,

as this document explains.


8.10 Provide SDSS status



54


Requirement The SDSS must be able to provide its current status to other modules

Comment Two services were developed to provide this information to other UrbanWater modules through the service bus.

Related section Section 3.4.1.2

8.11 Display the topology of the water supply system representation


Requirement SDSS should be able to display the water supply system logical model Comment The user interface developed for this prototype presents the water distribution

system representing its topology, displaying the elements and how water is distributed from one element to another.


8.12 Display the topology of the water supply system


Requirement The SDSS must be able to display the water supply system physical model Comment A map that presents the water supply system elements over a background

map has been developed within this prototype.


8.13 Send notifications through the platform

Requirement# REQ-SDSS-13 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

Comment Notifications are sent every a new calculation is done, using the uw.event.sdss.newcalculation

Related section Section 3.4.1.2


55


9 Annex III: Elements and rules used for the validation

This section presents auxiliary information of the water supply system used for the validation of the prototype. This section is divided in the list of elements within the water supply system and the list of rules defining how the system is operated.

9.1 Water supply system elements

A list of elements has been defined in the water supply system for the validation. These elements were defined using the Algarve water supply system as a reference. Thus, the elements are: BRA reservoir

Name Type Value Storage_capacity Parameter 32.325.000 m3

Max_outflow Parameter 29.000 m3/day Min_outflow Parameter 7.250 m3/day Min_volume Parameter 8.000.000 m3

Volume Variable m3 Predicted_contribution

Variable m3/day

Outflow Variable m3/day Table 6: BRA reservoir parameters and variables.

ODE reservoir

Name Type Value

Storage_capacity Parameter 134.000 m3 Max_outflow Parameter -259.000 m3/day

Min_outflow Parameter 40.000 m3/day Min_volume Parameter 50.000.000 m3

Volume Variable m³ Predicted_contribution

Variable m³ /day

Outflow Variable m³ /day Table 7: ODE reservoir parameters and variables.

ODE borehole

Name Type Value

Max_outflow Parameter m³ /day Min_outflow Parameter m³ /day

Outflow Variable m³ /day Table 8: SIL borehole parameters and variables.

GUA reservoir Name Type Value

Storage_capacity Parameter 164.600.000 m3 Max_outflow Parameter 203.000 m3/day

Min_outflow Parameter 40.000 m3/day Min_volume Parameter 40.000.000 m3

Volume Variable m³ Predicted_contribution

Variable m³ /day

Outflow Variable m³ /day


56


Table 9: GUA reservoir parameters and variables.

FON WTP

Name Type Value

Max_flow Parameter 29.000 m3/day Min_flow Parameter 7.250 m3/day

Flow Variable m³ /day Table 10: FON WTP parameters and variables.

ALC WTP

Name Type Value Max_flow Parameter 259.000

m3/day Min_flow Parameter 40.000 m3/day

Flow Variable Table 11: ALC WTP parameters and variables.

TAV WTP

Name Type Value

Max_flow Parameter 190.00 m3/day Min_flow Parameter 40.000 m3/day

Flow Variable m³ /day Table 12: TAV WTP parameters and variables.

BEL WTP

Name Type Value Max_flow Parameter 13.000 m3/day

Min_flow Parameter 3.250 m3/day Flow Variable m³ /day

Table 13: BEL WTP parameters and variables.

LVDB consumer

Name Type Value Predicted_demand

Variable m3/day

Table 14: LVDB consumer parameters and variables.

SP consumer

Name Type Value Predicted_demand

Variable m3/day

Table 15: Silves-Portimão consumer parameters and variables.

FO consumer

Name Type Value

Predicted_demand

Variable m3/day

Table 16: Faro-Olhão consumer parameters and variables.

TVRSAA consumer

Name Type Value

Predicted_demand

Variable m3/day


57


Table 17: TVRSAA consumer parameters and variables.

REV pump station

Name Type Value

Max_flow Parameter 40.000 m3/day Min_flow Parameter 0 m3/day

Flow Variable m3/day Table 18: REV pump station parameters and variables.

9.2 Water supply system operational rules

The aim of this section is to present the rules that define how water supply system used for the validation is operated. Rule - 1 IF (LVDB.predicted_demand + SP.predicted_demand) <= ALC.max_flow THEN

ALC.flow = LVDB.predicted_demand + SP.predicted_demand

FON.flow = 0

FI

Listing 17: Rule - 1.

Rule – 2 IF (LVDB.predicted_demand + SP.predicted_demand) > ALC.max_flow THEN

ALC.flow = ALC.max_flow

FON.flow = (LVDB.predicted_demand + SP.predicted_demand) – ALC.flow

FI


Rule – 3 IF FON.flow > FON.max_flow THEN

FON.message = “Predicted demand is higher than total capacity of the WTPs”

FON.flow = FON.max_flow

FI


Rule – 4 IF (FO.predicted_demand + TVSAA.predicted_demand) > TAV.max_flow AND (FO.predicted_demand +

TVSAA.predicted_demand) – TAV.max_flow <= (ALC.max_flow – (LVDB.predicted_demand +


REV.max_flow THEN

REV.flow = (FO.predicted_demand + TVSAA.predicted_demand) – TAV.max_flow



FI



TVSAA.predicted_demand) – TAV.max_flow <= (ALC.max_flow – (LVDB.predicted_demand +

SP.predicted_demand)) AND (FO.predicted_demand + TVSAA.predicted_demand) – TAV.max_flow >

REV.max_flow THEN

REV.flow = REV.max_flow




FI


Rule – 6


58


IF (FO.predicted_demand + TVSAA.predicted_demand) > TAV.max_flow AND (FO.predicted_demand +



REV.max_flow THEN

REV.flow = ALC.max_flow - (LVDB.predicted_demand + SP.predicted_demand)




FI




SP.predicted_demand)) AND (FO.predicted_demand + TVSAA.predicted_demand) – TAV.max_flow >

REV.max_flow THEN

REV.flow = REV.max_flow




FI


Rule – 8 IF BEL.flow > BEL.max_flow THEN

BEL.message = “Predicted demand is higher than total capacity of the WTPs”

BEL.flow = max_flow

FI


Rule – 9 IF BRA.volume < FON.flow THEN

BRA.message = “Reservoir is not able to supply all the raw water”

BRA.outflow = BRA.volume

FI


Rule – 10 IF BRA.volume + BRA.predicted_contribution – FON.flow < BRA.min_volume THEN

BRA.message = “Reservoir is in a scarcity scenario, check its evolution next days”

FI


Rule – 11 IF ODE.volume < (0.95 * ALC.flow) THEN

ODE.message = “Reservoir is not able to supply all the raw water”

ODE.outflow = ODE.volume

FI


Rule – 12 IF ODE.volume + ODE.predicted_contribution – (0.95 * ALC.flow) < ODE.min_volume THEN

ODE.message = “Reservoir is in a scarcity scenario, check its evolution next days”

FI


Rule – 13 IF GUA.volume < (TAV.flow + BEL.flow) THEN

GUA.message = “Reservoir is not able to supply all the raw water”

GUA.outflow = GUA.volume

FI


Rule – 14


59


IF GUA.volume + GUA.predicted_contribution – TAV.flow – BEL.flow < GUA.min_volume THEN

GUA.message = “Reservoir is in a scarcity scenario, check its evolution next days”

FI


Project Title: Intelligent Urban Water Management System ...urbanwater-ict.eu › wp-content ›...

Documents

Transcript of Project Title: Intelligent Urban Water Management System ...urbanwater-ict.eu › wp-content ›...