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

An Internet of Things-based model for smart water management

Toms Robles1, Ramn Alcarria2, Diego Martn1,
Augusto Morales1

Mariano Navarro, Rodrigo Calero, Sofa Iglesias,

Manuel Lpez

(1)
(2)

Innovation and R&D unit

Tragsa Group, Spain

Dep. de Ingeniera de Sistemas Telemticos

Dep. de Ingeniera Topogrfica y Cartografa
Universidad Politcnica de Madrid, Spain

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

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

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.

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 producers water ICT equipment
hinders proper monitoring and control systems, resulting in
low efficiency in water distribution and consumption, systems
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
interoperability; irrigation; water distribution networks

I.

II.

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.

model;

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 waterenergy 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
978-1-4799-2652-7/14 $31.00 2014 IEEE
DOI 10.1109/WAINA.2014.129

CHALLENGES FOR DEFINING INDUSTRIAL STANDARDS

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

821

the need for proper datasets and consistent methodology for

calculating water balances along with energy concerns.

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.

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.

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 todays state of the art
technologies.

822

Water Management Model

Process
Model

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.

Management and Exploitation

Common
Communication
Interface

Coordination
Physical
Model
CoordinationSubsystems
Interface

Subsystem
Model

Subsystems

Systems
Interfaces
Models

Figure 1. MEGA High level Functional Structure

V.

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,

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

823

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.

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:
x Subsystem and object identification. Unique
system identification must be defined.
x 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

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

824

Physical Model

ControlRecipe

Process Model

Company

Process Design

Location

Loading
Checking
Sending to
subsystems
Monitoring

RecipeID
Header
ProceduralID
EntityID
RecipeType

Area
Process Execution

Process Cell

Procedure

Unit

Unit Procedure
Operations

Formula
StartDate

<ControlRecipe>
<RecipeID>r1</RecipeID>
<Header>
<ProceduralID>Monitoring</ProceduralID>
OPC-UA
<EntityID>Monitoring</EntityID>
to XML
<RecipeType>Monitoring</RecipeType>
</Header>
<Formula>
Monitoring
<StartDate>2008-06-15 21:15:07Z
Irrigation
</StartDate>
Hydrant
</Formula>
<.>
</ControlRecipe>

Figure 3. OPC UA conversion to XML

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.

Equipment Module

Control Module

Figure 2. Layers of the physical and process models

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.

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

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.

OPC-UA
Server

Coordination

CoordinationSubsystems
interface

Subsystem 1
OPC-UA
Subsystem
Client
controller

discovery: getEndpoints
invoke
ControlRecipe
Set valve1 to
OPEN

EndpointDescription[]
CreateSecureChannel()
Get Node Attributes

DONE

Write (nodepath,value)

Set valve1
to OPEN

dataChange(nodepath,value,status)

result

Figure 4. Invoking a simple control recipe

825

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]
Figure 5. Sample scenario for Water Management

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.

[2]

[3]
[4]
[5]
[6]

[7]
[8]

[9]

VII. WATER MANAGEMENT SCENARIO AND DISCUSSION

[10]
[11]

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

[12]
[13]

[14]

[15]

[16]

826

Global Sustainable Development Report: Building the Common

Future We Want. United Nations Department of Economic and
Social Affairs. September 2013.
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.
TRAGSA Group homepage: http://www.tragsa.es/en/
MEGA project homepage: http://www.gestiondelagua.es/en/
EU Water Framework Directive (Directive 2000/60/EC), 23 October
2000.
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.
L. Atzori, A. Iera, and G. Morabito, The Internet of Things: A
survey, Computer Networks, vol. 54, no. 15, 2010, pp. 27872805.
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.
HollandTrade homepage: http://www.hollandtrade.com/, Netherlands
Enterprise Agency, 20013.
Association of Water Technologies homepage: http://www.awt.org/
EN 61512: Batch control -- Part 2: Data structures and guidelines for
languages. EN 61512-2:2002.
EN 62264: Enterprise-control system integration - Part 1: Models and
terminology. EN 62264-1:2013
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
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.
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.
Strategic Implementation Plan of the European Innovation
Partnership on Water.
http://ec.europa.eu/environment/water/innovationpartnership/pdf/sip.
pdf