An Internet of Things-based model for smart water management Tomás Robles1, Ramón Alcarria2, Diego Martín1,

Augusto Morales1 (1) Dep. de Ingeniería de Sistemas Telemáticos

(2) Dep. de Ingeniería Topográfica y Cartografía Universidad Politécnica de Madrid, Spain

{tomas.robles,ramon.alcarria,diego.martin,augusto.morales}@upm.es

Mariano Navarro, Rodrigo Calero, Sofía Iglesias, Manuel López

Innovation and R&D unit Tragsa Group, Spain

{mnc,rcalero,siglesias,mlopez}@tragsa.es

Abstract— Water is a vital resource for life, and for the economy. Nowadays, one of the most serious challenges to solve is to manage the water scarcity. Current water management ICT systems are supported by specific vendor equipment, without considering any interoperability standards. The lack of standardization among producer’s water ICT equipment hinders proper monitoring and control systems, resulting in low efficiency in water distribution and consumption, system’s maintenance and improvement, and failure identification. In this paper we propose a smart water management model integrating Internet of Things technologies for decoupling decision support systems and monitoring from business processes coordination and subsystem implementation. The proposed smart water management model makes specific vendor equipment interoperable and manageable in a water management domain in a homogeneous way.

Keywords-water management; architecture model; interoperability; irrigation; water distribution networks

I. INTRODUCTION Water management impacts on several key issues [1] of

human lives, such as environment, water consumption, food production, sewage treatment, purification, irrigation, energy balance, etc.

There is a lack of water management ICT standards, preventing an effective interoperability, and also increasing the cost of new products and its maintenance. Nowadays there are many small and local producers of specific solutions in a weak and fragmented market. This is a very serious problem because there is no monitoring and control for complex high scale systems, jeopardizing the efficiency in water distribution networks in terms of an effective water-energy balance, preventing also its evolution and necessary improvements, as an adoption of Internet of Things paradigms.

Current ICT systems for water management are proprietary, hindering its maintenance and sustainability Without a standardized model of interoperability the water management ICT system producers have to support all production levels from the product development to the communication with management systems; this cause the SMEs that develop water management ICT systems may not enter the market due to difficulty of developing a complete system.

In this paper we propose a smart water management model integrating Internet of Things (IoT) technologies for decoupling decision support systems and monitoring from business processes coordination and subsystem

implementation. The rest of the paper is as follows: Section II describes open challenges in the definition of water management models, Section III and IV define the requirements taken into account for our architecture proposal and a high level architecture respectively. Section V introduces the integration of IoT into the water management system and Section VI describes in detail the proposed MEGA model, followed by a discussion.

II. CHALLENGES FOR DEFINING INDUSTRIAL STANDARDS FOR WATER MANAGEMENT

The water sector operates in a complex interaction between water resources and the socio-economic and environmental systems. The range of stakeholders is large, with public and private, including local, regional, national and global companies, and also governments promoting the development of water resources where scale is a crucial factor. The diversity of stakeholders is one of the reasons for the actual market fragmentation in water control and management solutions. Another factor is the different schemes for water governance, which is continuously evolving in every country. The excessive market fragmentation becomes a severe barrier for innovation under the paradigm on Integrated Water Resources Management (IWRM), by slowing down the adoption of open reference architecture and standards. These solutions could enable interoperability, easy extension and update of actual solutions, paving the way for early adopters and developers of innovative solutions.

A. Insufficient implementation and integration of solutions Although the challenges facing the water industry are

global and there are many global vendors, solutions are increasingly locally based, as local companies can anticipate to unexpected changes and provide a dynamic solution for intra-regional issues. However, small businesses do not have the resources or the power to develop a reference system on their own. In this context it is urgently required the definition of a common framework to canalize these efforts, not only to reinforce synergies among different players, but also to enable the integration and widespread adoption of partial solutions.

All vendors, global or local, use different standards, methods and communication media for their solutions. As the result of multiple vendors in the market, the complete system solutions are very complicated and economically not efficient. This barrier leads to monitoring issues and states

2014 28th International Conference on Advanced Information Networking and Applications Workshops

978-1-4799-2652-7/14 $31.00 © 2014 IEEE

DOI 10.1109/WAINA.2014.129

821

2014 28th International Conference on Advanced Information Networking and Applications Workshops

978-1-4799-2652-7/14 $31.00 © 2014 IEEE

DOI 10.1109/WAINA.2014.129

821

the need for proper datasets and consistent methodology for calculating water balances along with energy concerns.

B. Lack of ICT model for water management process Currently there are many companies involved in water

management activities, such as location, extraction, conduction and treatment. Many knowledge areas are required for supporting and providing suitable technologies, from soil management to chemistry.

This diversity of focus and technologies requires different skills and then thousands of companies are involved in those processes. For instance, approximately 1.500 companies are directly active in water technology in the Netherlands [9]. In USA, water technologies are supported by an international trade association representing over 500 companies that specialize in water treatment systems [10]. In Europe, the European Union of Water Management Associations represents over 8.600 individual organizations.

The relatively recent deployment of Information and Communication Technologies in the area of water management, combined with the variety of knowledge areas required to understand the water management process, result in the lack of a reference model for the use of ICT. There are European initiatives [5] for defining common frameworks for water policies, but there is not any international organization promoting the definition of ICT standards in order to foster effective interworking of water management infrastructures and components. Nor there is any clear leader on providing ICT technologies that covers the complete water management process. This is mainly due to two reasons:

Local base for water management companies: although there are very large companies actively participating in the area of water management, most of those solutions are provided by small and local companies. Those companies provide simple solutions for the specific problems of water management for local clients, but usually they are not able to expand the business to other areas, countries or continents, due to the lack of a common standard for equipment interworking, finding only specific solutions for control and management. The problem for the end-users is that they are engaged with local providers which can even disappear and the existing infrastructure cannot be maintained and updated by any other.

Lack of interconnection demand: water management companies use specific technologies for the processes they are performing. Those technologies come from other sectors, such as production or electricity, and the control and management of such technologies are provided by proprietary closed solutions. There is not any requirement, demand or legal regulation that imposes the interconnection of such systems, thus, the pressure for working on open standards and solutions is very low.

To overcome these problems, Tragsa [3] is promoting the MEGA [4] model as one specific initiative for Spain that can be translated to European and International levels. The MEGA model considers a functional decoupled architecture to allow interoperability between specific vendor equipment.

III. REQUIREMENTS In order to define a standard architecture that covers

current and future needs in the area of water management we identified the following requirements:

REQ #1: The system should cover functionalities required by water management such as: remote management of physical elements; management and operation of suitable basic units; integration of the definition of a water network; integration of the definition of operations over the network

REQ #2: It should be able to interoperate with other architectures and applications such as GIS based applications dealing with information about soils, meteorology, environment, farming, etc.

REQ #3: It should provide a flexible and extensible architecture isolating different management problems and enabling the integration of different systems based on specific technologies. Thus, it is required to define Open Standard interfaces among different layers to support Communication and Process Control, and to integrate IoT standards and technologies which are very relevant for the sector.

REQ #4: It should be suited for integration with current equipment. The systems deployed in the countryside are not usually composed by single elements to be managed individually. The individual elements are part of a subsystem with a single point for external managing and control. Those subsystems integrate internal communication functions which depend on the more suitable technology for the specific environment or by the specific technology of the manufacturer.

IV. HIGH LEVEL ARCHITECTURE FOR EFFECTIVE WATER MANAGEMENT

The MEGA architecture is described in Fig. 1. The proposed high level model identifies three layers (from bottom to top): the Subsystems layer, the Coordination layer and the Management and Exploitation layer. These layers deal with a common Water Management Model that is built based on two key elements: the Physical Model, which includes the component model, and the Process Model. The water management model is the key element for enabling MEGA to provide a common behavior framework. Between the Subsystem layer and the Coordination layer there is a Coordination interface and between the Coordination and the Management and exploitation layer there is a Common Communication interface.

Management and Exploitation layer: this layer hosts the main applications and services responsible for the efficient management of water infrastructures, and supports the definition and management for the processes applied to those infrastructures. In this layer the Operators (big service companies, and end-users associations among others) drive management processes abstracting from the specific final systems deployed in the real environment. Services can be executed on local hosts, cloud services or whatever other service environment provided by today’s state of the art technologies.

822822

Coordination layer: this layer supports the interoperability among different management and exploitation systems and the underlying hardware and software subsystems. Based on the definition of a water management model, the Coordination layer maps the processes defined by the management layer to the subsystems and collect information from those subsystems and provides them to the management and exploitation layers that require them. Typically this application is located close to the physical system in the real environment, but it can also be deployed as a service in Cloud environments or deployed on central servers. The coordination layer interacts with the subsystems taking into account the topology of the water system, and the interface of each subsystem.

Subsystems layer: the subsystems layer contains the different subsystems integrated into the Water Management System. Each subsystem is defined as a single control system.

Two main interfaces are defined in this high level architecture, the Common Communication Interface and the Coordination-Subsystems Interface:

Common Communication Interface: This bidirectional interface provides a common solution in order to handle messages from business processes in the management and exploitation layer and process them in the coordination layer by using industry driven standards such as ISA-95/88 and OPC UA, as explained in Section VI.B.

Coordination-Subsystems Interface: this interface enables the monitoring of the elements located at the subsystems. The Coordination layer does not know precisely the internal structure of each subsystem (which is implemented by each company), but can delegate processes and monitor their execution and the status of the physical systems requesting relevant information. This information is collected, processed and further translated to the Management and Exploitation layer.

The whole proposal is based on a water management model, which includes a physical model and a process model. This model supports a smart behavior of the system,

including process distribution and data collection and analysis.

Physical Model: The physical model enables the definition of the equipment integrated in the water management systems in a hierarchical way. The physical model identifies the entities of the water system, how they are connected, and how they are grouped into subsystems. Subsystem definition allows small businesses, which do not have the resources to develop a whole reference system on their own, to develop o reuse a subsystem.

Process Model: based on the physical model and knowing the process each subsystem is able to perform, the operator of the water management system defines complex water management processes that are (i) loaded into the system; (ii) validated according to internal information; (iii) distributed to the suitable subsystems; (iv) executed and monitored; and finally (v) stopped.

V. IOT FOR SMART WATER MANAGEMENT The integration of IoT into the water management system

could prove to be very beneficial for both ICT areas and their business. In the rest of this section we analyze how IoT and Smart Environments are defined, their key characteristics in order to understand how they can be used in the definition of the reference model for Smart Water Management, taking advantage of the new advances on ICT technologies, for creating feasible and commercial systems [2].

Mark Weiser defined a ”Smart Environment” [6] as ―the physical world that is richly and invisibly interwoven with sensors, actuators, displays, and computational elements, embedded seamlessly in the everyday objects of our lives, and connected through a continuous network. Atzori et. al. [7] explained how IoT can be realized in three paradigms – internet-oriented (middleware), things oriented (sensors) and semantic-oriented (knowledge). Although this type of delineation is required due to the interdisciplinary nature of the subject, the usefulness of IoT can be unleashed only in an application domain where the three paradigms intersect.

A. IoT for Water Management In the field of water management the previously

described concepts of IoT have to be addressed for technical, business and social considerations. The main benefits of adopting an IoT approach for water management systems are:

Productivity increase: IoT allows real-time control, process optimization, service time reduction, new business models, resource conservations, and the capability to do all of this globally.

Efficiency increase, the first step of efficiency is to measure, with an environment based on IoT, all the elements can be tracked and monitored enabling continuous improvement techniques, saving resources, money and time.

Expansion of new and existing business models: IoT opens new markets in any of the three layers proposed in this paper, i.e. subsystem layer, creating new IoT subsystems that execute processes and communicate using a standard communication interface; coordination layer, allowing

Figure 1. MEGA High level Functional Structure

Wat

er M

anag

emen

t Mod

el

Physical Model

Subsystem Model

Process Model

Common Communication

Interface

Coordination-Subsystems

Interface

Management and Exploitation

Coordination

Subsystems

Systems

InterfacesModels

823823

SMEs based on ICT to design new coordination applications, able to orchestrate the management and exploitation layer with the subsystem layers; and management and exploitation layer, where the SMEs can create tailored information services for an specific water distribution network community.

IoT builds on three pillars [8], linked to the ability of objects to (i) be identifiable (anything identifies itself), (ii) communicate (anything communicates) and (iii) to interact (anything interacts), either among themselves, building networks of interconnected objects, or with end-users or other entities in the network. The proposed MEGA model considers these properties:

Thing-oriented: In the specific case of water management, and due to the previous experience of many companies building systems for water management, the single element to be deployed as a unit is the subsystem. It is expected higher granularity in the coming years thanks to IoT and water management nexus although at current stage this is the maximum granularity level it can be raised. A Smart Object is an object that can describe its own possible interactions. Information that is provided by a Smart Object includes: Object properties (physical properties and a text description), interaction information (current state of dials, gauges, switches), and finally, object behavior (different behaviors based on state variables).

In this point it is important to define how these subsystems (behaving as object containers) meet the characteristics identified by [8]. Subsystems publish the following information through their interfaces:

� Subsystem and object identification. Unique system identification must be defined.

� Subsystem capabilities, as each one of the functions the subsystem supports in an autonomous way, based on local capabilities and objects.

Internet-oriented: the proposed MEGA model identifies three layers communicated by two interfaces (see Fig. 1). These interfaces are supported by Internet protocols and technologies, enabling the definition of a flexible and scalable communication system for controlling the huge amount of subsystems to be required for a complete water management system involving the entire water management cycle.

Coordination, Management and Exploitation Layers are defined as Cloud services, and based on common standards such as SOA and Web Services, as the composing systems rely on affordable operation and communication channels.

Furthermore, subsystems are deployed on the field and their capabilities, computing, sensing, actuating and communication technologies depend on the local conditions. Subsystem heterogeneity will require that the Subsystems layer includes a large diversity of communication paradigms and higher granularity, to deal with many communication technologies.

Smart behavior: the water management reference model provides a physical model and a process model. Water management processes are defined at the Management and

Exploitation layer, and can be defined with two main purposes.

The first purpose is to perform water management actions and control over the water distribution system, in order to get some useful functionalities. This implies the execution of actions over the subsystems, while monitoring the correct execution of the processes. Actions over actuators are directly performed inside the subsystems, whereas the control of the whole process is shared by internal knowledge of each subsystem combined with the global knowledge performed by the Coordination layer. Based on this model, smart execution of water management processes is supported through collaboration between subsystems and the Coordination layer, based on the interchange of information among them (see Fig. 1).

The second purpose is related to system monitoring. A key capability of these IoT-based systems is that they can be monitored for internal control, but also it enables public bodies to monitor the fulfillment of public regulations. Information to be monitored is autonomously provided by the subsystems based on the sensors available for each one, and requires intensive usage of semantic technologies for identifying, collecting and translating relevant information to one unified report that includes information of the tree layers.

VI. REFERENCE MODEL FOR SMART WATER MANAGEMENT

The MEGA model for smart water management is currently being developed. Three main elements are under definition and prototyping: Water Management Model, Common Communication Interface and Coordination-Subsystems (C-S) Interface.

A. Water Management Model The water management model includes the physical

model and the process model. The physical model follows standards EN 61512 [11] and

EN 62264 [12]. As proposed by EN 61512 a layered structure is defined. Fig. 2 represents this layered structure. The three upper layers (Company, Location and Area) are structured according to companies’ organization (EN62264). The physical entities of these layers are responsible for the design of the involved water management processes. The Process Cell and Unit represent entities in which processes are executed. Examples of process cells and units are an Irrigation Sector and a Pump Management Station (PMS) respectively. Finally, the Equipment Module and Control Module are elements that are internally managed by the subsystem and are not directly accessed by the Coordination layer. Examples of equipment modules are hydrants, pumping lines or filtering stations. Examples of control modules are valves, meters and engines.

The process model describes and organizes, by following a predefined strategy, the execution of particular processes in water management subsystems, such as irrigation, tank filling, or water consumption measurement processes. The process model identifies the Procedure, as the basic element to be executed by the Process Cell. Procedures are composed

824824

by Unit Procedures, as the basic element to be executed by one unit, and finally, the Operations, which are the atomic instructions to be executed inside units. The definitions of elements and operations provided by the physical and functional models enable the remote management and operation of physical elements, as REQ #1 demands.

B. Common Communication Interface This interface is defined as a set of Web Services used by

applications for collecting all the required information in order to control the water consume, to operate on actuators and other entities of the physical system, to identify the state of the system, and to send them water management operations to be executed.

The Common communication interface provides a middleware solution to handle messages from the business processes (GIS-based applications, services providing information about soils, meteorology, as REQ #2 demands), in XML format, and to convert them to ISA-95/88-compliant OPC UA information models. OPC UA (IEC 62541) is an industry driven standard which is already implemented in many controllers. OPC UA has been designed for providing unified communication and interaction means for SOA and is therefore well suited for implementing different views on an automation system [13] such as water management systems. OPC UA enables the integration of different systems based on specific technologies, as REQ #3 demands.

The physical model is implemented as an OPC UA information model, containing all device instances of interest and corresponding device types. Control messages are defined in the management and exploitation layer and are executed in the coordination layer. In order to be compliant to ISA-95/88, these control messages contain recipes, which specify the sequence of activities in the form of procedural steps, which have to be performed by the physical components of the irrigation subsystems. The utilization of recipes is the way to manage individual elements from the point of view of the whole subsystem, decoupling the sequence of activities from the specific subsystem technology, as REQ #4 demands.

The serialization approach for recipes is described in Fig. 3. The header of a control recipe identifies the general procedure in which the recipe is included (ProceduralID), the entity the recipe aims at (EntityID), and the type of recipe to execute (RecipeType). The recipe Formula includes the set of actions to be performed over the entity. Depending on the recipe type, the formula can act on all the active elements (monitoring recipe), irrigation elements (irrigation recipe), hydrants of the entity (hydrant recipe), etc.

C. Coordination-Subsystems interface The coordination-subsystems (C-S) interface defines an

API to exchange OPC-UA service requests and responses. The API provides an internal interface that isolates the application code from the OPC-UA communication stack. The previously defined MEGA physical model, as a hierarchical set of physical elements (Process Cells, Units, etc.), is represented as nodes, and is accessible by the OPC-UA clients as a set of monitored items. These items reflect the changes in attributes and behavior of virtual elements against their real-world counterparts, when they perform a change, resulting from the execution of a recipe formula.

Recipe formulas can be executed if the coordination layer has the knowledge to operate the proprietary subsystem. We use the functionality of OPC-UA, which support the definition of Profiles, to describe which features are supported by an OPC-UA compliant product. These profiles define mandatory functionalities which must be supported by OPC-UA clients and servers, and other optional functionalities, which can be negotiated between entities. Up to now, the OPC Foundation has released more than 60 OPC-UA profiles [14].

Fig. 4 shows an interaction diagram reflecting how

Location

Area

Process Cell

Unit

Equipment Module

Control Module

Company

Physical Model

• Loading• Checking• Sending to

subsystems• Monitoring

Procedure

Unit Procedure• Operations

Process Model

Process Design

Process Execution

Figure 2. Layers of the physical and process models

ControlRecipe

RecipeID

RecipeType

Header

ProceduralID

EntityID

Formula

MonitoringIrrigationHydrant

StartDate

<ControlRecipe> <RecipeID>r1</RecipeID> <Header> <ProceduralID>Monitoring</ProceduralID> <EntityID>Monitoring</EntityID> <RecipeType>Monitoring</RecipeType> </Header> <Formula> <StartDate>2008-06-15 21:15:07Z

</StartDate> </Formula> <…….></ControlRecipe>

OPC-UA to XML

Figure 3. OPC UA conversion to XML

Coordination OPC-UA Server OPC-UA

ClientSubsystem controller

invoke ControlRecipe

discovery: getEndpoints

CreateSecureChannel()

Coordination-Subsystems

interface

EndpointDescription[]

Get Node Attributes

Set valve1 to OPEN

Write (nodepath,value) Set valve1 to OPEN

Subsystem 1

resultdataChange(nodepath,value,status)DONE

Figure 4. Invoking a simple control recipe

825825

coordination and subsystem layers interact when executing a control recipe. The coordination layer includes an OPC-UA Server, and the Subsystems layer an OPC-UA Client. Supported profiles are implemented in the OPC-UA server as specific endpoints. Thus, subsystems must discover supported profiles by getting the server endpoints. Then, they create a secure communication channel with the server. A modification of a property in a subsystem device (such as opening a valve) is transmitted through the C-S interface using the OCP Get Node Attributes command, to retrieve the name, type, description and permissions (read and/or write) of the node, and finally, using the OCP write command to change the node value. The subsystem then performs the change in the physical element (set valve to open) and responds with a dataChange event to the coordination layer, with the status of action result.

VII. WATER MANAGEMENT SCENARIO AND DISCUSSION Typical scenarios for water management (Fig. 5) imply

new operational models for system deployment in many places, ranging from cities to natural environments or rural regions. These systems can be controlled by control applications, which use standard protocols and interfaces, providing easy, uniform and universal access to all the subsystems through the set of component of the Control Layer.

There are an increasing number of stakeholders interested in the capabilities of the resulting system: water usage for agriculture, cities, natural areas, etc., public organizations monitoring the use of resources and the fulfillment of policy regulations and, ultimately, anyone interested in the Open Data movement supporting, among others, the PSI Directive [15], which focuses on information reuse.

This new scenario considers key characteristics, such as the huge number of subsystems that can be deployed, the massive information coming from their sensors, the challenging technologies for controlling these subsystems, and finally, the novel business models for providing

management and exploitation services, which exchange information with several people and institutions.

Due to these considerations, we think it is mandatory to integrate the new IoT paradigm in the development of MEGA in order to have a feasible, scalable and industrial system. Its adoption clearly opens a wider global market to water management companies, mainly ICT companies, paving the way for all key points and priority areas addressed in [16], specially water-energy nexus, water governance, decision and support systems and monitoring, and smart technologies involved in the IoT.

ACKNOWLEDGMENT This work is partially supported by the CALISTA

project, TEC2012-32457, awarded by the Ministry of Economy and Competitiveness in Spain.

REFERENCES [1] Global Sustainable Development Report: “Building the Common

Future We Want”. United Nations Department of Economic and Social Affairs. September 2013.

[2] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A vision, architectural elements, and future directions,” Future Gener. Comput. Syst. vol. 29, no. 7, pp. 1645-1660, Sept. 2013.

[3] TRAGSA Group homepage: http://www.tragsa.es/en/ [4] MEGA project homepage: http://www.gestiondelagua.es/en/ [5] EU Water Framework Directive (Directive 2000/60/EC), 23 October

2000. [6] M. Weiser, R. Gold, and J.S. Brown, “The origins of ubiquitous

computing research at PARC in the late 1980s,” IBM Systems Journal, vol. 38, no. 4, 1999, pp. 693-696.

[7] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Computer Networks, vol. 54, no. 15, 2010, pp. 2787–2805.

[8] D. Miorandi, S. Sicari, F. De Pellegrini, I. Chlamtac, “Internet of things: Vision, applications and research challenges,” Ad Hoc Networks, vol. 10, no. 7, Sept. 2012, pp. 1497-1516.

[9] HollandTrade homepage: http://www.hollandtrade.com/, Netherlands Enterprise Agency, 20013.

[10] Association of Water Technologies homepage: http://www.awt.org/ [11] EN 61512: Batch control -- Part 2: Data structures and guidelines for

languages. EN 61512-2:2002. [12] EN 62264: Enterprise-control system integration - Part 1: Models and

terminology. EN 62264-1:2013 [13] M. Melik-Merkumians, T. Baier, M. Steinegger, W. Lepuschitz, I.

Hegny, and A. Zoitl, “Towards OPC UA as portable SOA middleware between control software and external added value applications,” 17th IEEE Conference on Emerging Technologies & Factory Automation (ETFA), pp. 1-8, 17-21 Sept. 2012

[14] J. Imtiaz, and J. Jasperneite, “Scalability of OPC-UA down to the chip level enables “Internet of Things,” 11th IEEE International Conference on Industrial Informatics (INDIN), pp. 500-505, 29-31 July 2013.

[15] The Directive on the re-use of public sector information (Directive 2003/98/EC, known as the 'PSI Directive') entered into force on 31 December 2003.

[16] Strategic Implementation Plan of the European Innovation Partnership on Water. http://ec.europa.eu/environment/water/innovationpartnership/pdf/sip.pdf

Figure 5. Sample scenario for Water Management

826826