Water analytics and Intelligent Sensing for Demand Optimised Management · 2017-05-24 · Small or...

Small or medium-scale focused research project (STREP) FP7-ICT-2013-11

Water analytics and Intelligent Sensing for Demand Optimised Management

WISDOM

Project Duration: 2014.02.01 – 2017.01.31 Grant Agreement number: 619795 Collaborative Project WP.5

D5.5 ADV Project impact on standardisation

and liaison activities (Final report)

Submission Date (intermediate version):

01.02.2016 Submission Date (final version):

31.01.2017

Due Date (final version): 31.01.2017

Status of Deliverable (final version):

Project Coordinator: Daniela BELZITI Tel: +33 4 93 95 64 14 Fax: +33 4 93 95 67 33 E-mail: [email protected] Project website: www.wisdom-project

DrA WoD ReL DeL AppR

Nature of Deliverable: R P D O

Dissemination Level: PU PP RE CO

WISDOM D5.5 – Project impact on standardisation and liaison activities 2

Small or medium-scale focused research project (STREP) FP7-ICT-2013-11 – GA: 619795

DOCUMENT INFORMATION

Submission Date: 31.01.2017

Version: V2.5 (final report)

Author(s): Manuel Ramiro [ADV], Keith Ellis [INTEL], Shaun Howell, Tom Beach [CU], Contributor(s): Gaëlle Bulteau [CSTB]

Reviewer(s): Eugene Ryan [INTEL], Julie McCann [ICL], Manuel Fernández [ADV], Daniela Belziti [CSTB], Anna Taliana [DCWW]

Submission Date: 01.02.2016

Version: V1.0 (intermediate report)

Author(s): Keith A Ellis [INTEL] Contributor(s): Shaun Howell [CU], Gaëlle Bulteau [CSTB], Daniela Belziti [CSTB]

Reviewer(s): Eugene Ryan [INTEL], Tom Beach [CU], Julie McCann [ICL], Gerardo Glorioso [ADV]



DOCUMENT HISTORY

Date Version Name1 Remark 23.12.15 V0.1 K.A.Ellis (INTEL) Table of Content & initial proposed structure / approach

10.01.16 V0.2 K.A.Ellis (INTEL) Updated ToC, Initial content section 2 & 3

18.01.16 V0.3 S.Howell (CU) Ontology content contribution

20.01.16 V0.4 K.A.Ellis (INTEL) Overall read-through & edits

25.01.16 V0.5 G.BULTEAU (CSTB) French standards input

25.01.16 V0.6 K.A.Ellis (INTEL) Input integration. Overall read-through & edits

26.01.16 V0.7 E.Ryan (INTEL) Read-through & edits

27.01.16 V0.8 D.BELZITI (CSTB) Content to Section 5, small edits

28.01.16 V0.9 K.A.Ellis (INTEL) Final read-through & edits

1.02.16 V1.0 PSC PSC review / Intermediate version

4.11.16 V.1.1 M. Ramiro (ADV) Table of Content

11.11.16 V1.2 M. Ramiro (ADV) Proposed structure / initial approach

11.11.16 V1.3 Tom Beach (CU) ToC review & content integration

14.11.16 V1.4 M.Ramiro (ADV) ToC adjustment & content integration

15.11.16 V1.5 Anna Taliana (DCWW) ToC/Content comments

1.12.16 V1.6 M.Ramiro (ADV) ToC/approach validated by PSC

27.12.16 V1.7 K.Ellis (INTEL) Section 1 edits

8.01.17 V1.8 T. Beach, Shaun Howell (CU) Section 1 & 2 contribution

13.01.17 V1.9 M.Ramiro (ADV) Consolidated version (CU/Intel contributions)

23.01.17 V2.0 M.Ramiro (ADV) V2.0 release

25.01.17 V2.1 K.Ellis (INTEL) Section 1 edits, Section 3 edits to SOTA

25.01.17 V2.2 M.Ramiro (ADV) V2.2 release (format & editing)

26.01.17 V2.3 T. Beach (CU) Section 1 & 2 edits

26.01.17 V2.4 M. Ramiro (ADV) Final version

27.01.17 V2.5 PSC PSC review / Final version

1 Main Contributor and Partner



COPYRIGHT

© Copyright 2014 WISDOM Consortium consisting of CSTB, DAPP, CU, CCC, ASP, SAT, INTEL, ICL, ADV, IDRAN

and DCWW.

This document may not be copied, reproduced, or modified in whole or in part for any purpose without

written permission from the WISDOM Consortium. In addition to such written permission to copy, reproduce,

or modify this document in whole or part, an acknowledgement of the authors of the document and all

applicable portions of the copyright notice must be clearly referenced.

All rights reserved.



TABLE OF CONTENTS

Document Information .................................................................................................................... 2

Document History ........................................................................................................................... 3

Copyright ........................................................................................................................................ 4

Table of Contents ............................................................................................................................ 5

List of Figures .................................................................................................................................. 7

List of Tables ................................................................................................................................... 8

Abbreviations ................................................................................................................................. 9

1. Introduction ........................................................................................................................... 10

1.1 The proposed value of the work ........................................................................................................... 10

1.2 Analysis of progress against objectives ................................................................................................. 11

1.3 Proposed approach to standardisation ................................................................................................. 12

2. WISDOM ontology as main impact on contribution to standardisation activities ..................... 14

2.1 Initial Consensus building ...................................................................................................................... 14

2.2 Standardisation efforts within the project ............................................................................................ 15

2.2.1. Presentation to Environment Agency and EIP-Water ................................................................... 15

2.2.2. Presentations to Hypercat ............................................................................................................. 15

2.2.3. Work with W3C .............................................................................................................................. 16

2.2.4. WIDEST roadmap ........................................................................................................................... 16

2.2.5. ICT4Water roadmap ...................................................................................................................... 16

2.2.6. Semanticwater.com & W3C SWIM group ..................................................................................... 16

2.2.7. Papers & presentations ................................................................................................................. 17

2.2.8. Liaison with SAREF project ............................................................................................................ 18

2.3 Plan going forward ................................................................................................................................ 18

2.3.1 Leveraging existing initiatives ................................................................................................................ 20

2.3.2 Contribution to semantic model standardisation ................................................................................. 20

3. Annex (A) ICT and Water domain standards and activities of interest ..................................... 21

3.1 Introduction ........................................................................................................................................... 21

3.2 Information technology standards and activities of Interest ................................................................ 23

3.2.1. Edge tier / Proximity network ....................................................................................................... 24



3.2.2. Platform tier / Access network ...................................................................................................... 28

3.2.3. Enterprise tier / Service network .................................................................................................. 32

3.2.4. Security & Privacy .......................................................................................................................... 33

3.2.5. Semantics, data models and ontologies ........................................................................................ 36

3.3 Water Domain specific standards & activities of Interest ..................................................................... 38

3.3.1. Standardization on Smart Water in France ................................................................................... 38

3.4 ICT4WATER Cluster recommendations on standards and standardisation activities ........................... 39

4. References ............................................................................................................................. 42



LIST OF FIGURES

Figure 1 Breakdown of organisations which have validated the WISDOM ontology, by type .............................. 14 Figure 2 Illustration of the consensus built between WISDOM and other relevant models .................................. 15 Figure 3 IoT alliance round-up ............................................................................................................................... 22 Figure 4 IoT reference architecture exemplars ...................................................................................................... 22 Figure 5 the IIC 3-tier reference architecture ........................................................................................................ 23 Figure 6 communication protocol exemplars Source the Butler project [20] ........................................................ 25 Figure 7 IoT protocol landscape from sensors to business value [22] ................................................................... 26 Figure 8 LPWA target characteristics [41] ............................................................................................................. 29



LIST OF TABLES

Table 1-1 Objectives vs Actions ............................................................................................................................. 11 Table 2-1 Papers and presentations ...................................................................................................................... 18 Table 3-1 Edge hardware exemplars ..................................................................................................................... 27 Table 3-2 examples of device abstraction layer software frameworks ................................................................. 28 Table 3-3 big data analytical infrastructure and frameworks ............................................................................... 29 Table 3-4 DR security considerations ..................................................................................................................... 34 Table 3-5 Communication / data Security standards ............................................................................................ 34 Table 3-6 First items to be dealt with .................................................................................................................... 38 Table 3-7 Challenges identified ............................................................................................................................. 41



ABBREVIATIONS

Acronym Full name

AFNOR Association Française de Normalisation (French standards organisation -)

CityGML city geography mark-up language

CIM common information model

DoW description of work

EIP European Innovation Partnership

GML geography mark-up language

IAD integrated access devices

ICT Information & communication Technology

IEC International Electrotechnical Commission

IFC Industrial Foundation Class

IIC Industrial Internet Consortium

IoT Internet of Things

ISO International standards organisation

LPWA(N) Low Power Wide Area (Network)

M2M Machine to machine

MAN metropolitan area network

OGC Open geospatial consortium

OIC Open Interconnect Consortium

OSGI Open Service Gateway Initive

OSI Open Systems Interconnection

OWL web ontology language

RDF resource description framework

SCADA Supervisory Control and Data Acquisition

SCCM Smart City Concept Model

SDO Standards Development Organisations

SPARQL SPARQL Protocol and RDF Query Language)

SSN semantic senor network

SWEET semantic web for earth and environmental terminology

SWIM Smart water interoperability model

SWRL semantic web rule language

UML universal mark-up language

WAN Wide area Network

XML extensible mark-up language



1. INTRODUCTION

The overall goal of this deliverable “Project impact on standardisation and liaison activities” is to identify how WISDOM can positively contribute to standards and initiatives in the ICT for Water Resource Management domain. Given this goal, an initial work focused on examining the various standards and technologies that had potential synergies with the WISDOM project, both ICT centric and domain specific. The resulting review formed the majority of the work delivered in the intermediate version of this report (January 2016). This work is now placed as an annex (A) of this report A refined assessment followed and the most likely path to impact was established and is outlined in the body of this report. Progress against DoW (Description of Work) objectives is discussed in section 1.2 while the strategy itself is explained in section 1.3, but first the proposed value of the strategy is outlined in section 1.1.

1.1 The proposed value of the work

Compared with other city infrastructures the water industries are much more conservative. This is because water is of core importance to a civil society and distribution downtimes are not tolerated lightly. It is for this reason that water industries are not as fast as, say, some of the energy suppliers, in the uptake of leading edge technology. In parallel sensing and control technologies are becoming more mature and are being used in anger in other fields from transport to precision agriculture. Yet with this maturity there is a reluctance of water companies to take on board this technology as it is not tested in their domain. That is, sensing and control technologies that use modern telemetry and computer networks has not been tested on real water networks and on pipes both over and underground with all the challenges those environments bring. Such technologies, which have great potential to provide step-changes in the sustainability of water resources, are relatively new and one cannot imagine stopping water distribution just so that experimenters can test equipment. The process for developing smart cities and communities’ standards should ensure interoperability of solutions, i.e. adaptability of solutions to new user requirements and technological change as well as avoidance of entry barriers or vendor lock-in through promoting common metadata structures and interoperable (open) interfaces instead of proprietary ones; open and consistent data, i.e. making relevant data as widely available as possible – including to third parties for the purpose of applications development – whilst using common, transparent measurement and data collection standards to ensure meaningfulness and comparability of performance/outcome measurements. Special attention have to be put into better real‐time operations decision‐support, improved customer relationships and communications citizen involvement in infrastructure management, improvement of preparedness, and management of conjunctive use of surface and groundwater for water supply.

The review of annex (A) outlines the complexity of the ICT and IoT domain in terms of available standards, technologies and alliances. From this review it became apparent that if the WISDOM project was to have any reasonable chance of impacting standard then it needed to concentrate of specific areas where it would



provide a contribution. The consortium felt it had a narrower domain specific scope and that impacting on the bourgeoning ICT and IoT standards landscape was unrealistic. The view of the consortium was that the most rational option related to promoting the WISDOM ontology described in brief in annex (A) and in full in deliverable D2.2. This strategy was presented at the second review to the reviewers and EC; quote from the Technical Review Report (Section 2c) “[..] From what presented it seems that both contribution to IoT technologies and semantics standardisation can be of interest.”

This work was seen as answering a specific gap whereby the water domain lagged initiatives in the built environment and smart grids where the role of semantics in underpinning unambiguous shared meaning at scale was well established.

Such ‘shared meaning’ is paramount in any communication system as interoperability stands as one of the single biggest issues impacting the adoption of ICT and IoT solutions. The WISDOM ontology aimed to address that very issue within the project by enabling information sharing amongst cooperating systems of the WISDOM system-of-systems linking domain assets and the services developed as an outcome of the analytical research of WP3.

This view is backed up by the ICT4Water cluster reports (annex (A)) which have stated as one of the key challenges is “Adopting/developing water vocabularies and ontologies so that there is semantic clarity”.

1.2 Analysis of progress against objectives

The following table outlines how the consortium has addressed the DoW objectives.

Table 1-1 Objectives vs Actions

Proposed Objectives (DoW) Actions (project activities)

Obj 1) “[…] the goal of this task is to ensure a significant contribution of the project to relevant Standards Development Organisations (SDOs) in Europe and worldwide”

Direct interaction with SDOs was deemed an unrealistic strategy. The consortium opted to build consensus first amongst the ICT4Water cluster & through initiatives like the H2020 WIDEST, an approach ratified by the Special Interest Group (SIG)2. Additionally, via the SIG the project is in direct contact with FATHOM providers of a Utility-to-Utility, cloud-based software-as-a-service platform for the water industry

Obj 2) “[…] through Project partners, white papers and submissions will be contributed, to influence and speed up the standardisation process, promoting the standardisation of specifications developed within each work package.”

WISDOM has engaged with various groups e.g. (EIP-Water, W3C, SemanticWater, WIDEST), and presented at different conferences. This has been done in an attempt to build consensus and to promote the WISDOM Ontology value proposition, with a view to then approaching SDOs.

Obj 3) “ […]the task will organise, stimulate and control contribution activities and their

Obj 3-4 were combined and aligned with the watch list exercise of WP6. This exercise focused on

2 http://www.wisdom-project.eu/project#p_56_INSTANCE_GQEmFUXpSz0h

http://www.wisdom-project.eu/project#p_56_INSTANCE_GQEmFUXpSz0h



submission (the content itself being taken care of by the related work packages), namely through quarterly internal meetings.”

1) reviewing standards & initiatives of potential interest and; 2) scanned the environment for potential landing zones for WISDOM outputs. However, to consider that in-flight workings of an FP7 project could be submitted directly into SDO activities was not realistic and the strategy chosen as above was to leverage water related projects and initiatives in building consensus ahead of any SDO approach.

Obj 4) “[…]for this purpose the task will set-up a controlling and scheduling system that enables other WPs to keep track with related standardisation activities in order to submit contributions at the right time and right place.

Obj 5) “[…]this task is also closely related to task 6.3: representative of relevant industry standards will be invited to take an active role in the project through their involvement in the Special Interest Group as specified below.”

Experts of both the Water and ICT domain were invited onto the SIG. Those of the water domain ratified the need for a means of domain wide interoperability / shared meaning, while ICT member’s sanity checked the approach to ontology development. An ontology which itself leveraged known W3C standards e.g. OWL, RDF, SPARQL etc. Again the SIG have suggested possible industrial channels of enquiry

Obj 7) “[…]links with EU-funded projects in the field will also be established, in order to evaluate potential synergies but above all to assess if joint – thus more powerful – contributions can be submitted to SDOs.”

As per Obj 2 the WISDOM project as engaged with multiple initiatives in order to build consensus ahead of an SDO approach.

1.3 Proposed approach to standardisation

As has been briefly outlined the agreed strategy was to focus not on Standards Development Organisations (SDOs) directly but on building consensus and support for the WISDOM ontology before approaching any SDOs. This was decided upon for the following reasons:

- The ontology was seen as addressing a specific gap in the market, as the water domain lacked any

established semantic taxonomy, and as such potential impact was greater. - Having the support of a community that transcended specific projects was seen as an advantage for

championing the ontology. - Many of the members of initiatives like the ICT4Water cluster were also members of study groups etc.

in SDOs and as such offered a means of taking the proposal forward. - Targeting the water cluster also offered the opportunity to disseminate other aspects of the project

and test their suitability for wider adoption and or further collaboration. - The ICT / IoT standards landscape was a burgeoning myriad of options and as such establishing impact

in that space would be very difficult without very specific specialisation. - It was deemed unrealistic given the timelines and the typical timings involved in establishing standards

that an FP7 project could maintain the effort required or could have established a proposal quickly enough to take forward. The consortium had no experience of a Coordinate Special Action (CSA) achieving such an impact and as such it was deemed unrealistic for a research project.

The following two organisations where the initial liaison targets:



ICT4Water [1] is a hub project for the 15 sister projects on ICT and Water Management funded by the EC. Its objective is outlined in the following statement - “ICT and water efficiency is a key policy issue with potential for new research area that includes decision supporting system for the measurement of water quality and quantity including the recycling and water reuse processes. This necessitates increased interoperability between water information systems at EU and national levels and efficiency of water resources management.” WIDEST [2] is a European Commission (H2020 Coordination and Support Action) project that started in 2015. The vision of WIDEST is to establish and support a thriving and interconnected Information and Communication Technology (ICT) for the Water Community with the main objective of promoting the dissemination and exploitation of the results of European Union (EU) funded activities in this area:

1- Advance the consolidation of ICT for the Water Community resulting in a better informed, defined and integrated community than today;

2- Assist current research projects by improving their exploitation plans and increasing their dissemination potential by facilitating sharing to a wide range of stakeholders and actors within the water community.



2. WISDOM ONTOLOGY AS MAIN IMPACT ON CONTRIBUTION TO

STANDARDISATION ACTIVITIES

As described previously, the WISDOM ontology has been defined as the primary mean for the project to achieve standardisation. This section will document the progress that has been made in this area and our future plans to impact on standardisation.

2.1 Initial Consensus building

A key stage in the early development of a standards process is building an appetite for that new standard, and

beginning to establish a consensus on the nature of the standard. The WISDOM ontology development,

validation, and dissemination activities have prioritised these aspects, leading to the ontology being validated

by 25 organisations, which is broken down by type in Figure 1. This validation represents the genesis of

consensus. Furthermore, significant effort has been made towards getting consensus in this domain by aligning

the most relevant standards, which is illustrated in Figure 2. This has elicited the areas that overlap and show

similarity between existing standards and models, which is key in developing a standard which adequately

meets the needs of both the Industry and the existing standards landscape.

Figure 1 Breakdown of organisations which have validated the WISDOM ontology, by type



Figure 2 Illustration of the consensus built between WISDOM and other relevant models

2.2 Standardisation efforts within the project

2.2.1. Presentation to Environment Agency and EIP-Water

CU was invited to present the WISDOM ontology to the Environment Agency and discuss both the need for

such an ontology, and their use of standards in this space. CU was also invited to present the WISDOM

ontology to EIP-Water to discuss the work conducted, the need for standards in this space, and the potential

for further funding to pursue this agenda. This included the preparation of a short paper outlining the proposal.

This presentation served as general awareness raising of the WISDOM ontology, its functionality and how it has

been used. Presenting to these groups has also enabled networking and high level consensus building that will

be required to take the ontology forward for standardization.

2.2.2. Presentations to Hypercat

Hypercat is both an Innovate UK project and a BSI PAS: it is a standard JSON file format and API specification for

automated discovery of IoT resources and interoperability signposting. CU was invited to present the WISDOM

ontology to the Hypercat consortium at two of their quarterly review meetings. The semantic water standards

work was also invited for presentation at the Hypercat final event to an audience of ~200 industry

professionals. As previously, this was primarily for awareness raising purposes, but, additionally, this

presentation allows us to build a contact with Hypercat enabling the alignment of our ontology with their

existing semantic resources, enhancing the bredth of our support for IoT related devices that can be used for

sensing/control within a water network.



2.2.3. Work with W3C

As a key player in web standards, W3C is a highly relevant organisation for liaison activities. Following a good

reception of the water ontology work at the Hypercat meetings, and following the agreement between the

Hypercat Alliance and W3C to collaborate on a shared vision for IoT standards, contact was established with

the W3C Web of Things Interest Group. Following dissemination of the WISDOM ontology work to W3C, W3C

requested a web demonstration be produced to showcase the value of the WISDOM semantic inference

capabilities described in D2.2 alongside IoT standards.

A review of the standards and SDO landscape has been conducted. The most promising avenues are: UKWIR,

which may provide further funding for pursuing standardisation activities, the Water Industry Telemetry

Standard (WITS), which has recently announced work on a specific IoT adaptation of its SCADA-based standard,

and ETSI (through the OneM2M standards, whom ETSI is working closely with given alignment to SmartM2M).

The scope of WITS-IoT is predominantly lower layers of the IoT stack (networking, communication etc), but

they may be receptive to collaborating on higher layer standardisation based on the work conducted in

WISDOM. However, the most promising avenue is likely to be pursuing a water standardisation task force

within ETSI-OneM2M, as they have demonstrated an appetite for standardising application-layer ontologies,

given their standardisation of the SAREF ontology. This has been pursued and is discussed as a plan going

forward.

2.2.4. WIDEST roadmap

The WISDOM ontology was referenced in the WIDEST roadmap on semantic interoperability and ontologies,

following liaison and collaboration with partners in the WIDEST project.

2.2.5. ICT4Water roadmap

WISDOM has also shared his vision on standardisation for the 2016 update of the ICT4Water Roadmap [11] " The ontologies might be based on already developed semantic tools, like WatERP, or WISDOM ontologies to overcome the existing gap regarding syntactic and semantic interoperability".

2.2.6. Semanticwater.com & W3C SWIM group

As no ideal SDO was observed for a smart water ontology, an initiative was launched and disseminated by CU

to promote standardisation activities in this space. This is relatively common in the IoT space due to the

required pace of standardisation. A website3 was developed to introduce the need for such activities, progress

to date, and the value of the WISDOM ontology. A community and business group was also launched through

W3C.

3 semanticwater.com



2.2.7. Papers & presentations

Several academic and industrial papers and conference presentation have been delivered with a clear message

of requiring standards activities in this space. Below is the list of these references:



Table 2-1 Papers and presentations

Lead Partner

Publication

CU Howell, S. Beach, T. Rezgui, Y. Towards Robust Requirements for Ontologies in Urban Cybernetic Applications: Smart Water Case Study – under review in Journal of Requirements Engineering

CU Howell, S. Rezgui, Y. Beach, T. Integrating Building and Urban Semantics to Empower Smart Water Solutions – under review Journal of Automation in Construction.

CU Howell, S. Rezgui, Y. Beach, T. Water Utility Decision Support through the Semantic Web of Things – - under review in Journal of Computing in Civil Engineering

CU Howell, S. Rezgui, Y. Beach, T. Zhao, W. Terlet, J. and Li, H. 2016. Smart Water System Interoperability: Integrating Data and Analytics for Demand Optimized Management through Semantics. ICCCBE.

CU Howell, S. Beach, T. and Gluhak, A. 2016. Semantic Models for Enabling Smart Management of Urban Water Systems. IWA Leading Edge Conference on Water and Wastewater Technologies.

CU Howell, S. July 2016. Smart Water Semantics: Meaningful Interoperability beyond Data and Syntax. WIPAC Monthly July 2016.

CU Howell, S. 2016. Integrating Intelligent Water Sensing, Optimisation and Decision Support through the Semantic Web. Cardiff University Water Research Institute Start-up Workshop.

2.2.8. Liaison with SAREF project

The Smart Appliance REFerence ontology (SAREF) project was identified as a key strategic avenue for pursuing

standards activities in the smart water space, as it has been standardised by ETSI and is actively being

developed and extended through a dedicated standards development task force. Contact was made with the

creator of the ontology, who was interested in the WISDOM ontology and pursuing smart water as an

application domain for the extension of SAREF. This represents part of the plan going forward, which is now

discussed.

2.3 Plan going forward

The main avenues being pursued after the end of the project are: i) smart water standardisation activities

through ETSI, ii) continued growth of the SemanticWater.com initiative, iii) continued dissemination and liaison

activities, and iv) continued engagement with W3C and Hypercat.

In discussions with the SAREF creator, it was agreed that smart water represents an important application

domain for SAREF. The intended route to standardisation is to:

1. Prepare a document outlining the proposed extension of SAREF for the water domain,



2. Share this document with the SAREF project, who have agreed to then liaise with their ETSI project

officer about the potential for further funding,

3. Build appetite within ETSI for the proposed extension to secure funding,

4. Complete a process of iteratively revising the relevant parts of the WISDOM ontology to best suit

standardisation as ‘SAREF for Water’,

5. Deliver the proposed standard to ETSI for review, complete the required procedures and revisions

6. Publish ‘SAREF for Water’ through ETSI.

If funding is not secured, the work will still be conducted based on CU’s appetite for activities in this space.

Close collaboration is envisaged with the SAREF project due to a previous professional relationship with them,

and the openness of the semantic web community. Beyond the extension of the SAREF ontology, it is CU’s

intention to pursue further semantic water standardisation activities through ETSI at the utility network level.

The SemanticWater.com initative was launched in collaboration with Aquamatix, an IoT-based water service

provider, who also has significant appetite for semantic modelling standardisation activities in the water space.

The next stage for pursuing this avenue is building strategic industrial interest, to ultimately reach a ‘critical

mass’ whereby formal activities can be pursued and a management structure can be put in place. The initiative

has used BuildingSmart as a reference point for the nature of such an organisation and its growth.

Pragmatically, the next activities being undertaken are:

1. The production of white papers, marketing materials and web resources,

2. Securing further funding for activities;

3. Further strategic liaison activities;

4. Dissemination activities;

5. Further standards development work such as technological alignment, demonstration, consensus

building, and further use case specifications.

The 4 activities listed at the start of section 2.2 - Standardization efforts within the project - have the potential

to significantly impact standards in the smart water modelling space. To speculate where these may lead:

ideally the engagement with ETSI would result in a ‘SAREF for water’ ontology, followed by a standardised

ontology for smart water networks. The SemanticWater.com intiative has the potential to grow into an

organisation with similarities to both buildingSMART and WITS, as a not-for-profit steward of water modelling

standards for application layer interoperability. Continuing the dissemination and liaison activities has the

potential to open a number of opportunities for engagement with existing standards bodies, companies,

alliances, and existing standards. Finally, continuing the engagement with W3C and Hypercat may also lead to

further strategic liaison activities and impact towards applied IoT standards.

Regarding the potential for the WISDOM ontology to contribute to industry standards; the modelling approach

adopted in Smart water interoperability model (SWIM) appears to have several similarities with the WISDOM

ontology, and significant value could be derived from the input of the WISDOM project towards standardising a



model. Liaisons towards this effect are described in section 2.3.2. The CityGML Utility Network ADE is an ‘in

progress’ extension of the CityGML schema to facilitate the visualisation and exchange of city data relevant to

utility networks such as water, gas and electricity. The potential for input to this effort is also discussed in this

section. Finally, the mandate of the IFC to contribute to a ‘digital built Britain’ requires their extension into

several industries neighbouring the AEC industry in terms of buildings connected to their surrounding urban

and natural environment, of which water is a critical area. The scope for contributing towards the development

of the IFC openBIM standards into the water area is discussed in section 2.3.2.

2.3.1 Leveraging existing initiatives

A primary aspect of the WISDOM standardisation strategy to is to reach out and leverage existing work. Specifically in leveraging and actively participating in the EC supported ICT4Water cluster [1]. This process started in October 2014 with the Consortium taking part to a survey conducted by i-WIDGET project notably about their experience of using standards (which one, for what purpose, associated costs, benefits, etc.), their understanding of the advantages and disadvantages of standards and of the aims of the EC regarding the standards. The results of the survey were used during a special session on standardization held at the WaterIdeas conference [3]. ICL has contributed to the report on initial ‘Recommendations for Standards and Standardisation in the European SMART Water Market’ [4]. Two partner organisations [DCWW, ICL] have engaged with the Smart Water Networks Forum (SWAN) [5]. SWAN is a “collection of data-driven components helping to operate the data-less physical layer of pipes, pumps, reservoirs and valves. Water utilities are gradually deploying more data-enabled components. Itis up to us to make the most out of them, by turning the discrete elements into a cohesive 'overlay network'”. Additional, initiatives of interest include WISE – The Water Information System for Europe [6], the European Innovation Partnership (EIP) on Water [7] and WIDEST [2]. Amongst the ICT4Water Cluster project, i-WIDGET (ended October 2015) took a particular leading role on promotion of standards. University of Exeter, the i-WIDGET coordinator, will continue activities on standardization as a partner of the WIDEST project group, with the intention of developing a roadmap on these issues. The WISDOM Consortium will certainly contribute to these actions as two WISDOM partners [CU and ADV] were appointed as members of the WIDEST Advisory Board.

2.3.2 Contribution to semantic model standardisation

Towards promoting the standardisation of a semantic model for the water industry, synergies were established with the WatERP [8] and Waternomics [9] projects from the ICT4Water cluster, and with Aquamatix towards a collaboration between the WISDOM ontology and SWIM. During the project duration knowledge interchange aimed to identify similarities and differences between each project’s models and identify contributions towards ongoing standardisation efforts. Further, a meeting was held between WISDOM and SWIM, and the contact established with the W3C SWIM group will be pursued fully. Finally, existing contacts with the OGC and BuildingSmart will be leveraged to pursue a contribution towards the CityGML Utility Network ADE and IFC standards, respectively.



3. ANNEX (A) ICT AND WATER DOMAIN STANDARDS AND ACTIVITIES OF

INTEREST

3.1 Introduction

Initial step was oriented towards examining the various standards and technologies, both ICT centric (section 3.2) and domain specific (section 3.3), and to assess which standards are most relevant as part of any WISDOM specific standardisation strategy and associated activities. Given the centrality of information technology this analysis primarily focuses on assessing the IoT domain, which as Figure 3 and Figure 4 suggests is a bourgeoning standards landscape, and how WISDOM could make an impact. Figure 33 [12] gives a pertinent example illustrating the myriad of IoT alliances that traverse the various communication layers and potential domain verticals. Considering the water domain, data acquisition for ‘smart’ water metering and approaches for appropriate backhaul communications are immediately relevant as is some of the vertical focused alliances in the ‘industrial IoT’ and ‘connected home’ space. For example, if communication is not robust enough, or not perceived to be robust enough, to offer an adequate quality of service then sensing and/or actuation services may not be adopted in the water distribution network. If residential solutions are not accurate enough, or interoperable or extensible then service adoption by end customers will be laboured [19], meaning inefficiency and flexibility will go unidentified and unexploited. As per [13]–[18] there are multiple posited IoT reference models and architectures. The myriad of posited IoT architectures again pose uncertainty, especially when viewed from the domain perspective. Will centralised cloud based solutions offer required rates of response? Or acceptable levels of security and privacy? Would decentralised approaches offer holistic visibility or scalability? Is a hybrid approach the most appropriate, option. What Figure 3 and Figure 4 quite clearly illustrate is that it can be arduous for potential end-users (industrial, energy, transport, built environment, agriculture, water etc.) to navigate and select appropriate computational and communication solutions which can stifle any sort of investment decision. Hence uncertainty regarding which standards will ultimately prevail act as a barrier to adoption of IoT and thus any envisaged domain services. Set against this context this deliverable aims to understand those standards most relevant to the project context and to determine where and how the project can have impact as per the stated goal.



Figure 3 IoT alliance round-up

Figure 4 IoT reference architecture exemplars



3.2 Information technology standards and activities of Interest

This section examines the various information technology standards, protocols and alliances that have relevance for the IoT and the domain verticals it underpins. There are five main subsections with multiple subsections within each. The first three subsections align to the IIC [18] ‘Edge, Platform and Enterprise tiers’ and the ‘proximity, access and service networks’ that connect them. Within these subsections the layers of the ‘IoT World Forum reference model’ [19] are loosely used as a nomenclature, thus offering more granular structure. It is envisaged this structure will assist in collating a comprehensive review of the various aspects for consideration and in honing areas of focus. Additionally, it should aid general readability and appreciation of the complexity of options available, although it should not be confused as purporting a specific industrial vertical focus.

Figure 5 the IIC 3-tier reference architecture

It is useful to begin with a short description of the communications networks, as described above in Figure 5, which the IIC reference architecture described as follows:

The proximity network connects the sensors, actuators, devices, control systems and assets, collectively called edge nodes. It typically connects these edge nodes, as one or more clusters related to a gateway that bridges to other networks.



As per section 3.2.2, the edge level of data exchange is a virtual jungle of protocols. But the proximity network can be simplistically viewed as any network that connects an edge device to an internet enabled compute device.

The access network enables connectivity for data and control flows between the edge and the platform tiers. It may be a corporate network, or an overlay private network over the public Internet or a 4G/5G network.

As will be discussed in section 3.2.2, the access network bridges edge compute and greater compute capacity, storage and analytical tools. Non-cellular backhaul communications not explicit in the IIC disruption are also discussed.

The service network enables connectivity between the services in the platform tier and the enterprise tier. It may be an overlay private network over the public Internet or the Internet itself, allowing the enterprise grade of security between end-users and various services.

As will be outlined in section 3.2.3 the service network can be thought of as any internet / intranet based user interface, service or application used for business update, decision and control type services.

3.2.1. Edge tier / Proximity network

The scenario depicted in Figure 5 largely assumes a gateway-centric view of the IoT. What this means is that ‘edge nodes’ i.e. sensors and actuators need not be so ‘smart’ as the gateway provides much of the required functionality and compute capacity. There are other views for example a cloud-centric view whereby individual edge sensors and controllers are more intelligent, communicating directly into a cloud backend, or a distributed edge-centric view which effectively sees backend compute and edge nodes localized ‘on-premises’ e.g. in a manufacturing or agricultural scenario. Not one view is likely to dominate but in the medium it is deemed within this project that a gateway-centric view is the most likely scenario especially given a built environment / water network context. Based on this assertion the Edge tier is conceptually sub-divided and discussed as follows:

- Physical devices & low level connectivity - Edge gateways - Abstraction layer technologies

3.2.1.1 PHYSICAL DEVICES & LOW LEVEL CONNECTIVITY The Internet of Things unsurprisingly involves ‘physical things / devices’ e.g. cars, motors, fridges, TVs, fans, locks, lights, boilers etc. For these things to be observed, controlled and connected they must have some form of sensor, actuator and means of communication. Such things are defined here as ‘edge nodes’.



Such edge nodes are varied and voluminous and as per Figure 3 there are numerous alliance all of which utilise various communication protocols for connection / communication. Examples include Ethernet, Wi-Fi, IEEE 802.15.4 (Z-wave, Zigbee, WirelessHart, 6LoWPAN), LoRa, DASH 7, Modbus, Profibus, RS232 & RS485 etc. Figure 6 [20] outlines example protocols utilised by the alliances of Figure 3 and architectures of Figure 4 superimposed over the OSI 7 layer stack [21]. Some like Zigbee are full stacks which in this case is built on the IEEE 802.15.2 standard, but are commonly understood to relate to the connection of sensor and actuators.

Figure 6 communication protocol exemplars Source the Butler project [20]

Figure 6 and Figure 7 [22] highlights just how onerous a task it is to select an IoT solution. The number of lower-level protocols for communicating with physical things is reflective of the multitude of things to be connected, monitored and controlled. To date, the approach to complexity has typically been to adopt a leading standard for the respective domain. However, IoT type services increasingly look to leverage multiple data observations to infer knowledge and insights. A WISDOM specific example of this would be the residential use-case which looks to utilise sensed data regarding water usage, energy consumption, occupancy, comfort (temperature and humidity) etc. in order to provide insight to customers and the water utility. One could push for a solution that utilises one protocol



e.g. Zigbee or Z-Wave. But if a user wants to connect another device to the proposed solution that does not utilise the chosen protocol, they cannot easily do so. This impacts adoption of such offerings because the user may need different supporting technology; think of the traditional scenario of multiple remote controls for TV, DVD, sound system etc.

Figure 7 IoT protocol landscape from sensors to business value [22]

As described in section 3.2.1, one could adopt a cloud-centric, gateway-centric or distributed edge-centric approach but invariably there will be a requirement to enable interoperability between various low-level communication protocols i.e. data translation / exchange needs to happen at some point. Whether that happens in a data centre, more locally or in a truly distributed fashion is at the crux of the various approaches. Section 3.2.1.2 ‘edge gateways’ and 3.2.1.3 ‘abstraction layer technologies’ that follow outline a gateway-centric view.



3.2.1.2 EDGE GATEWAYS An edge device/gateway is a device which provides an entry point into enterprise or service provider core networks. Examples include routers, routing switches, integrated access devices (IADs), multiplexers, and a variety of metropolitan area network (MAN) and wide area network (WAN) access devices. Edge devices also provide connections into carrier and service provider networks [23]. Put simply, an edge gateway is a device that bridges two networks. It is considered to be at the edge of the network(s) because data must flow through it before entering either network. Edge gateways in this context are not data-centre hosted. They are in-the-field devices, which as Figure 5 illustrates, connects the proximity network of the lower level wired/wireless edge node devices and the access network linking to larger scale compute, storage and data analytics services. What this means is that the gateway provides much of the required functionality and compute capacity for connected edge node sensors and actuators. It acts as the ‘gate keeper’, routing data as required / permitted between edge nodes and platform services hosted in remote or local cloud platforms. Based on that assessment Table 3-1 lists examples of hardware devices that can act as gateways. The gateway itself is tasked with providing the requisite compute, memory, RF and other interfaces required to link edge nodes and the internet.

Table 3-1 Edge hardware exemplars

x86 micro-PC Raspberry Pi

Intel Galileo, Edison, Building Automation Gateways

Intel DK series Alcatel-Lucent HSG(Home Sensor Gateway)

Honeywell XYR300G Lantiq GRX family

However, it is a combination of hardware and software that enables what is essentially a translation or abstraction functionality, whereby the gateway, on a one-to-one or one-to-many basis, links the data protocol(s) of edge nodes and higher order compute. As such, the technologies discussed in section 4.2.1.3 form an integral element of the gateway function.

3.2.1.3 DATA ABSTRACTION LAYER TECHNOLOGIES As discussed previously, in IoT-enabled scenarios, invariably there is the requirement to enable interoperability between heterogeneous low level communication protocols. For example, in the built environment one might want to convert from Modbus RTU and say BACnet IP whereas in residential settings one might have Zigbee, Z-Wave and Bluetooth sensors; ideally one would want a gateway that could communicate / connect all three. As discussed, a combination of hardware and software is required, and the gateway requires the RF hardware to receive wired/wireless data from the various protocols. From a software perspective, some means of parsing the various data formats is required, as is logic to decide what to do with the data. This can, of course, be done on a case by case basis, but is not ideal.



One means of addressing the issue is to utilise a ‘devise abstraction layer’ type technology which handles data translation / exchange from different connecting protocols. Table 3-2 identifies examples, many of which are OSGI [24] java compliant.

Table 3-2 examples of device abstraction layer software frameworks

Residential / Building

CSTBox http://cstbox.github.io/executive-summary.html

OIC - IoTivity https://www.iotivity.org/

OpenHab Eclipse SmartHome

http://www.openhab.org/ http://www.eclipse.org/smarthome/

Thread http://threadgroup.org/

ProSyst http://www.prosyst.com/what-we-do/

Kuru gateway http://www.eclipse.org/kura/

HGI http://www.homegatewayinitiative.org/

Building / Industrial

OPC-UA https://opcfoundation.org/about/opc-technologies/opc-ua/

oBIX http://www.obix.org/

3.2.2. Platform tier / Access network

3.2.2.1 NETWORK COMMUNICATION Some proximity network communication protocols (section 3.2.1.1) e.g. Zigbee are meshed technologies and can cover reasonable range, however, the ‘access network’, linking the edge tier and the platform tier, typically utilise cellular based technologies such as GPRS, EDGE, HSPA, LTE, LTE+ or wireless metropolitan area network (MAN) technologies such as WiFi (wireless mesh) and WiMAX. However, increasingly Low-power wide-area technologies (LPWA) include Adaptrum, IEEE 802.22, LoRA, SigFox, and WEIGHTLESS are being seen as alternatives for IoT machine-to-Machine (M2M) based communications. LPWA technologies are aimed at addressing high coverage and very low power. The technology is particularly suited to M2M use cases, where data rates can be low and infrequent. While cellular based solutions play an important role in today’s M2M networks, they often have power requirements which needs constant recharging or them to be plugged into electrical outlets. Cellular communications are considered very chatty, with a significant amount of signalling occurring between the device and the network. Clearly this type of overhead is unsuitable for many M2M applications where the data may be infrequent, such as tamper alarms, or smoke alarms. Moreover the current capacity limitations reduces the number of concurrent connections available at macro cells [9]. LPWA networks generally operate at the Sub-1GHz spectrum, enabling longer range and penetration of buildings, from the basement to the roof. Moreover LPWA solutions which operate at lower frequencies can cover significant geographic distances when compared to cellular offerings.



Figure 8, [9] shows how LPWA technologies (SigFox, Neul and LoRa) compare to classical cellular technologies (3G/4G/5G) and to mesh technologies (ZigBee) in terms of latency, cost, power consumption and geographical coverage.

Figure 8 LPWA target characteristics [41]

Again the number of standards options at the access network compound the solution selection headache for domain actors. As Figure 8 suggests, there is much that needs to be considered, but understanding the characteristics most important to ones given context is essential to the best technological fit.

3.2.2.2 DATA ACCUMULATION & ABSTRACTION Technologies and standards in the Platform tier are essentially tasked with providing access to what is typically described as ‘data analytics’ or ‘big data analytics’ infrastructure and frameworks. As can be seen from Table 3-3, this tier is a myriad of some well-established and some emerging technologies / standards. Some of the same technologies are utilised in respect of the WISDOM approach detailed in ‘Data acquisition, Fusion and Analytics’ of deliverable D2.3 and ‘data storage and security’ deliverable D2.4.

Table 3-3 big data analytical infrastructure and frameworks

Hadoop

HDFS

for storing large datasets. Hadoop utilises inexpensive hard drives in a very large cluster of servers. While one can expect failure on these drives, the Mean time to Failure (MTTF) is well understood. HDFS divides data into blocks and copies these blocks of data across nodes in the cluster, thus embedding built-in fault-tolerance and fault compensation within Hadoop



MapReduce

for processing large data sets. MapReduce is a model of programming for processing and generating large data sets utilising a parallel, distributed algorithm on a cluster. The MapReduce framework marshals the distributed servers, running the various tasks in parallel, manages all communications and data transfers between the various parts of the system, and provides for redundancy and fault tolerance.

Pig

for analysing large data sets. Is a platform for analysing large data sets. It consists of a high-level language for expressing data analysis programs, coupled with infrastructure for evaluating these programs. The salient property of Pig programs is that their structure is amenable to substantial parallelization, which in turns enables them to handle very large data sets. Pig also allows the user to dfine their own user defined functions (UDFs).

Yet Another Resource Negotiator (YARN)

supporting multiple processing models in addition to Map Reduce. Designed to address the tendency of MapReduce to be I/O intensive, with high latency not suitable for interactive analysis. Additionally, MapReduce was constrained in support for graph, machine learning (ML) & other memory intensive algorithms.

Zookeeper

is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. Distributed applications utilize these kinds of services and they are typically difficult to implement. Zookeeper combines these services into a interface to a centralized coordination service. The coordinated service itself is distributed and highly reliable.

Apache Mesos

is a cluster manager that abstracts CPU, memory, storage, and compute resources away from machines this enables fault-tolerant and elastic distributed systems to be managed. It is built similarly to the Linux kernel, but at a different level of abstraction. The Mesos kernel runs on every machine and provides applications with APIs for resource management and scheduling across cloud environments. It can be used by Hadoop, Spark , Kafka and Elastic Search

Cloudera Enterprise, IBM big Insights, EMS/Pivotal HD, Hotonworks

Enterprise distributions of Hadoop

Big data storage

HBase, Cassandra NOSQL Big table stores

CouchDB, MongoDB NOSQL Document Based

Riak, Redis, HANA RDBMS, VoltDB RDBMS, OpenTSDB, KairosDB

Key Value and In-Memory Databases (both RDMS & NOSQL)

Neo4j Graph Databases

Big Data Processing & Querying

Hive is a data warehouse software which supports querying and management of large datasets residing in distributed storage. Hive provides a mechanism to project structure onto this data and query the data using a SQL-like language called HiveQL (HQL).

Apache Shark

is a port of Apache Hive designed to run on Spark. It is still compatible with existing Hive data, megastores and queries like HiveQL. The reason for the port is that MapReduce has simplified big data analysis but users want more   complex analysis capabilities and multi-¬‐stage applications.

Apache Tajo data warehousing system on top of HDFS. Designed for low-latency and scalable ad-hoc queries, online aggregation, and ETL (extract-transform-load process) on large-data sets stored on HDFS and other data sources.



Apache Drill

is a low latency SQL query engine for Hadoop and NoSQL. Drill provides direct queries on self-describing and semi-structured data in files (such as JSON, Parquet) and HBase tables without needing to define and maintain schemas in a centralized store such as Hive metastore.

Cloudera Impala

is an open-source interactive SQL query engine for Hadoop. Built by Cloudera, it provides a way to write SQL queries against your existing Hadoop data. It does not use Map-Reduce to execute the queries, but instead uses its own set of execution daemons which need to be installed alongside your data nodes.

Apache Phoenix (for HBase)

provides a relational database layer over HBase for low latency applications via an embeddable JDBC driver. It offers both read and write operations on HBase data.

Presto by Facebook is a distributed SQL query engine optimized for ad-hoc analysis. It supports standard ANSI SQL, including complex queries, aggregations, joins, and window functions.

Big Data Acquisition & Distributed Stream Processing

Apache Samza is a distributed stream processing framework. It uses Apache Kafka for messaging, and apache Hadoop Yarn which provides fault tolerance, processor isolation, security and resource management

Apache Storm is a distributed real-time computation system for processing large volumes of high-velocity data. Storm on YARN provides real-time analytics, machine learning and continuous monitoring of operations

Apache Spark Streaming

uses the core Apache Spark API which provides data consistency, a programming API and fault tolerance. Spark treats streaming as a series of deterministic batch operations. It groups the stream into batches of a fixed duration called a Resilient Distributed Dataset (RDD). This continuous stream of RDDs is referred to as Discretized Stream (DStream).

Apache Spark Bagel is a Spark implementation of Google’s Prgel A System for Large- Scale Graph Processing. Bagel currently supports basic graph computation, combiners, and aggregators

Typesafe ConductR and Akka Stream processing

ConductR is a Reactive Application Manager that lets Operations conveniently deploy and manage distributed systems. It utilises Reactive Akka stream processing which is an open source implementation of the reactive streams draft specification. Reactive Streams provides a standard for asynchronous stream processing with non-blocking back pressure on the Java Virtual Machine (JVM)

Big Data Analytics Frameworks & Tools

Apache Spark

is a fast and general engine for large-scale processing. It provides in-memory processing for efficient data streaming applications while retaining the Hadoop’s MapReduce capabilities. It has built-in modules for machine learning, graph processing, streaming and SQL. Spark needs a distributed storage system & a cluster manager. Spark is quick and runs programs up to 100x faster than Hadoop MapReduce in memory, or 10x faster on disk

Apache Flink

is an open source system for data analytics in clusters. It supports batch and streaming analytics, in one system. Analytical programs can be written in APIs in Java and Scala. It has native support for iterations, incremental iterations, and programs consisting of large Directed acyclic graphs (DAG) operations

H2O

is an open source big data analysis offering. Using the increased power of large data sets, analytical algorithms like the generalized linear model (GLM) or K-means clustering, are available and utilise parallel computing power, rather than by truncating data. Efficiency is achieved by dividing data into subsets & then analysing each subset simultaneously using the same algorithm. Iteratively results from these independent analysis are compared, eventually convergence produces the estimated statistical parameters of interest



Weka This is a collection of data mining tasks algorithms that provide machine learning. It has tools for visualisation, for data pre-processing, for classification, for regression, for clustering and for association rules. It facilitates the development of new machine learning schemes

Massive Online Analysis (MOA)

Branched from Weka, designed for data streams and concept drift. It has APIs to interact with Scala and R.

RapidMiner & RapidMiner Radoop

The Rapidminer platform provides an integrated environment for machine learning, data mining, text mining, predictive analytics and business analytics. Rapidminer Radoop is a big data analytics system it provides visualization, analysis, scripting and advanced predictive analytics of big data. It is integrated into RapidMiner on top of apache Hadoop.

Apache SAMOA

enables development of new machine learning (ML) by abstracting from the complexity of underlying distributed stream processing engines (DSPE). Development of distributed streaming ML algorithms can be done once & then can be executed on DSPEs. Such as Apache Storm, Apache S4, and Apache Samza.

Apache Spark Mlib is a scalable machine learning library. It consists of common learning algorithms & utilities, such as classification, dimensionality reduction, regression, clustering, collaborative filtering & optimization primitives.

Apache Spark SparkR SparkR is an R package that provides a light-weight frontend to use Apache Spark from R. Through the RDD class SparkR exposes the Spark API. Users can interactively run jobs from the R shell on a cluster.

Amazon, AWS ML, Microsoft Azure ML, Google prediction ML

Commercial machine Learning (ML) solutions

3.2.3. Enterprise tier / Service network

3.2.3.1 APPLICATIONS (REPORTING, ANALYTICS, CONTROL) In the pre-IoT era, SCADA (Supervisory Control and Data Acquisition) systems were the predominant approach taken to remote monitoring and control of automated cyber-physical systems. Traditional SCADA involves Programmable Logic Controllers, Telemetry Systems, Remote Terminal Units and Human Machine Interfaces. These systems require custom design and deployment to a specific domain and the Human Machine Interfaces tended to be desktop native applications. Traditional SCADA is still widely used in industrial processes and facilities management, however the growth of IOT as well as advances in predictive analytics and cloud computing has created demand for more flexible solutions. Modern commercial IoT SCADA systems make better use of data modelling techniques to map sensed data back to control interfaces and take advantage of scalable cloud-hosted software-as-a-service (SaaS) to run more complex control algorithms. At the same time there has been growing demand for frameworks and software solutions that can merge traditional Business Intelligence functionality with that of SCADA systems. New trends are starting to emerge including:

Broader device support: Most reporting tools have been designed as native desktop applications but there is an increasing demand for mobile and touch screen support. While it seems unlikely that complex queries will be developed on mobile phone screens, the consumption of reports on mobile is a common request. Furthermore, trends around increasing self-service business intelligence (BI) and Visual improvements open up possibilities for touchscreen and gestural query composition.



Improved Visualization: Many solutions include charting components that allow users to generate basic charts from their query results, however users often struggled to get the views they required due to limited chart libraries and clumsy configuration GUI’s. Extended charting libraries with improved composition capabilities are expected.

Agile self-service Reporting: Traditionally data querying and analysis was carried out by the IT department or more recently by data scientists. There is an increasing demand from business users to be able to query data directly. Many advanced analytics platforms include visual query builders that support drag and drop query workflow building and charting. This codeless development will become more widespread.

A range of new reporting and visualization solutions have appeared over the last decade. These range from programming libraries to dashboarding technologies to off the shelf applications. While off the shelf applications tend to provide simpler development and deployment lower level programming libraries provide greater customization and integration capabilities. Solutions providers should consider their choices accordingly.

Programming Libraries

In order to satisfy the trends of broad device support and self-service graphics many browser based javascript frameworks have emerged examples including:

- D3.js http://d3js.org/ - Processing.js http://processingjs.org/ - AM charts https://www.amcharts.com/

Dashboard Solutions

- Freeboard.io https://freeboard.io/ - Dashing.io http://dashing.io/ - Finalboard.io http://finalboard.com/

Commercial Applications

- Tableau http://www.tableau.com/ - Birst https://www.birst.com/

3.2.4. Security & Privacy

3.2.4.1 SECURITY APPROACHES & STANDARDS

IoT systems are unique because they are:

- physically distributed - a mixture of very small to very large devices - use open or untrusted networks



- large scale deployments, which may extend to tens of thousands of components

They also have complex attributes of other systems, such as:

- different parts of the system may be created by different vendors (multi-tenancy) - use and functionality changes over the duration of the system’s lifecycle

Table 3-4 outlines elements that should be incorporated at the development stage i.e., security by design. As can be seen security needs a holistic approach from the physical up to network level and then service level authentication.

Table 3-4 DR security considerations

Network aspects Other aspects

- Firewall - Virtual private networks - Authentication

- Key management - Device attestation - Runtime controls - Stack simplification - Integrity measurement - Data encryption - Data authentication

Physical aspects

- Device-specific cert - Trusted Platform Module Platform Configuration Registers - Secure boot - Physical access

Table 3-5 outlines some of the many standards that are used in ICT communications. Any solution needs to utilise best practise incorporating aspects outline din Table 3-4 and the standards as outlined in Table 3-5. Again this can be arduous for domain actors in understanding the best approach.

Table 3-5 Communication / data Security standards

Encryption standards

- Triple-DES data encryption standard Symmetric-key block cipher, which applies the original Data Encryption Standard (DES), which is now obsolete, cipher algorithm three times to each data block.

- Advanced Encryption Standard (AES) AES also known as Rijndael, is a specification for the encryption of electronic data established by the U.S. National Institute of Standards & Technology (NIST) in 2001. AES is based on the Rijndael cipher

developed by

two Belgian cryptographers, Joan Daemen & Vincent Rijmen, who proposed it to NIST. Rijndael is a family of ciphers with different key & block sizes.

- RSA Named after Ron Rivest, Adi Shamir, & Leonard Adleman at MIT, RSA s one of the first practical public-key cryptosystems & is widely used for secure data transmission. In such a cryptosystem, the encryption key is public & differs from



the decryption key which is kept secret.

- OpenPGP Pretty Good Privacy (PGP) is a data encryption & decryption computer program that provides cryptographic privacy & authentication for data communication. PGP is often used for signing, encrypting, & decrypting texts, e-mails, files, directories, & whole disk partitions & to increase the security of e-mail communications. It was created by Phil Zimmermann in 1991. PGP & similar software follow the OpenPGP standard (RFC 4880) for encrypting & decrypting data.

Wireless standards

- Wi-Fi Protected Access (WPA) Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access II (WPA2) are two security protocols & security certification programs developed by the Wi-Fi Alliance to secure wireless computer networks. The Alliance defined these in response to serious weaknesses researchers had found in the previous system, Wired Equivalent Privacy (WEP). WPA2 became available in 2004 & is a common shorthand for the full IEEE 802.11i-2004 standard.

- WPA2 / 802.11i uses AES

- A5/1 cell phone encryption for GSM A5/1 is a stream cipher used to provide over-the-air communication privacy in the GSM cellular telephone standard. It is one of seven algorithms which were specified for GSM use.

It was initially kept secret, but became public knowledge through leaks & reverse engineering. A number of serious weaknesses in the cipher have been identified.

Transport Security

- Secure Socket layer Cryptographic protocol designed to provide communications security over a computer.

- Transport Layer Security Evolved from SSL cryptographic protocol used to provide privacy & data integrity between two communicating computer applications. Symmetric cryptography is used to encrypt the data transmitted

3.2.4.2 PRIVACY APPROACHES & STANDARDS Aside from technical security as outlined in section 3.2.4, ‘privacy by design’ should also be considered as a standardised practise. Incorporating privacy aspects at the data model level should help with appropriate data lifecycle management. Additionally, developing interfaces and mechanism for allowing users to tag data in intuitive ways could offer a means of mitigating uncertainty regarding privacy legislation which can be a barrier to investment in IoT infrastructure. Some relevant standards include:



- P3P - is a protocol allowing websites to declare their intended use of information they collect about web browser users. Designed to give users more control of their personal information when browsing, P3P was developed by the World Wide Web Consortium (W3C). However, it is not widely adopted.

- XACML - The Extensible Access Control Mark-up Language together with its Privacy Profile is a standard for expressing privacy policies in a machine-readable language which a software system can use to enforce the policy in enterprise IT systems.

- EPAL - The Enterprise Privacy Authorization Language is very similar to XACML. It is s a formal language for writing enterprise privacy policies to govern data handling practices in IT systems according to fine-grained positive and negative authorization rights. It has been submitted by IBM to the World Wide Web Consortium (W3C) to be considered for recommendation.

- WS-Privacy - "Web Service Privacy" will be a specification for communicating privacy policy in web services. For example, it may specify how privacy policy information can be embedded in the SOAP envelope of a web service message.

3.2.5. Semantics, data models and ontologies

The role of semantic models in the water industry has been presented in D2.2, alongside a brief discussion of existing models and standards, and the need for open and standardised semantic models of the domain. Whilst D2.2 also highlights how the WISDOM ontology may extend the state of the art, this section extends that to identify the specific standards to be targeted by WISDOM and discusses these choices. This intended contribution to standards is based on the artefacts, knowledge and processes presented in D2.2, and the knowledge and experience gained in developing the WISDOM ontology. The relevant standards can be divided into those which support the modelling and deployment of knowledge in cloud-based systems, and those which capture knowledge regarding the water and intelligent sensing domains. Within the former category, the standards which form the semantic web stack are the most relevant. These primarily include the web ontology language (OWL) [25], the resource description framework (RDF) [26], the SPARQL protocol and RDF query language [27] (SPARQL) and the semantic web rule language (SWRL) [28]. These standards exist within the ‘pure’ ICT field: they are not specific to WISDOM’s domain. For this reason, and as they are mature and accepted international standards, the WISDOM project doesn’t aim to contribute to these. The existing standards which capture knowledge in the water and intelligent sensing domains form a plethora of languages, data models and taxonomies, towards a variety of different purposes, and within different parts of a broad domain. However, the most relevant examples are discussed here; firstly regarding domains which aren’t water specific and secondly regarding the range of smart water languages and models which currently exists. The requirement for further standardisation specific to WISDOM’s domain will then be highlighted, and WISDOM’s contribution identified.

3.2.5.1 SEMANTIC MODELS IN RELEVANT NEIGHBOURING FIELDS Semantic models which serve a similar purpose to the WISDOM semantic model, but within different fields include the common information model (CIM) [29], the industry foundation classes (IFC) [30, p. 4], the city geography mark-up language (CityGML) [31], the smart city concept model (SSCM) [32] and the semantic senor network (SSN) ontology [33].



The CIM has been adopted by the International Electrotechnical Commission (IEC) [34], and aims to allow the interoperation of software in electrical networks by facilitating data exchange. The CIM is natively expressed as a universal mark-up language (UML) model, but further IEC standards define extensible mark-up language (XML) serialisations of the model, to allow their federation into an RDF format [35, p. 61]. This is relevant as it acts as a benchmark for information models within utility companies, and whilst it is arguably not sufficient for next generation smart grids, much can be learnt from the CIM in developing a similar standard for the water industry. The industrial foundation class (IFC) is the data model which facilitates open building information modelling (openBIM), and has been accepted as an ISO standard [30, p. 4]. This was primarily developed to facilitate information exchange between the design and construction phase of buildings. IFC is based on the EXPRESS schema, but can also be expressed in XML [35], and ongoing research is enriching the IFC to an OWL model [36]. This model is also undergoing development to describe data and concepts from the broader role of connected buildings within urban environments, including water network concepts. CityGML has foundations in the geospatial field, and facilitates the visualisation and exchange of data at the city level [31]. CityGML is an extension of the geography mark-up language (GML) for the purposes of specifically modelling cities to various levels of detail, where GML is an extension of XML for the purposes of modelling geospatial data. Several domain extensions are under development for CityGML, to allow standardised descriptions of data related to various ‘city domains’, including utility networks. The smart city concept model (SCCM) is a conceptual model presented in BSI:PAS 182 [32], and outlines the concepts and relationships deemed most critical to the smart city field. The SCCM is somewhat domain neutral, in that it aims to remain a middle-level conceptual model, suitable for further development as the smart city modelling field matures. The SCCM also isn’t serialized in a normative manner; it is officially termed a ‘guide’ rather than an actual model, so establishing the described model would be a prerequisite of aligning the WISDOM ontology. Finally, the SSN ontology is an OWL model formalising a language for the description of intelligent sensor networks, and utilises significant abstraction and domain neutrality. As the SSN ontology is not specific to the water domain, WISDOM will not aim to contribute to this, but has utilized it extensively, as described in D2.2.

3.2.5.2 SEMANTIC MODELS IN THE WATER INDUSTRY Within the water domain, the key standard of note is WaterML2 [37, p. 2], although several other models are also highly significant: - Smart water interoperability model (SWIM) [38] - CityGML Utility Network application domain extension [39] - The Hydrologic Information Model, from the Consortium of Universities for the Advancement of Hydrologic

Science, Inc [40] - The semantic web for earth and environmental terminology (SWEET) ontology [41] - Aquo [42]

Of these, WaterML2 is an XML extension to facilitate the exchange of hydrological data. As the target domain of the WISDOM project is primarily the application of ICT to water systems, rather than natural water body or water cycle management, SWIM is by far the most relevant of these models, although the CityGML ADE also



exhibits significant overlap with the WISDOM ontology. SWIM is a model developed by Aquamatix and a W3C community & business group to promote interoperability in ‘smart water systems’; drawing a parallel to the ‘smart grid’ movement observed in the power industry. Further, the nature of WaterML2 is inherently different to the WISDOM or SWIM semantic models, as the former contributes a means of representing time series data, and the latter facilitates model-based interoperability of software systems via the ‘software as a service’ concept.

3.3 Water Domain specific standards & activities of Interest

3.3.1. Standardization on Smart Water in France

Several actions were initiated since 2013 by the French organization for Standardization (AFNOR) on the topic “Smart Water”. A national survey was conducted among 150 French water stakeholders in order to collect their expectations on standardization in this field. Stakeholders have shown great interest in services to end-users, water operators and local authorities. Consequently, a working group called “GE3 – Smart Water” is in preparation since December 2015 to start working on the services provided by Smart Water. The main objective is to provide the specifications of a “smart service” in the water sector. Stakeholders experience difficulties to specify these services and their needs. The description of the possible services is also heterogeneous and hard to implement. It is necessary to establish a common standard between the end-user demand and the service reality. The following use cases were firstly identified according to the survey results: - Terminology - Leakage alert - Backflow - Water networks supervision - Quality supervision Some of the questions raised by stakeholders for each item are indicated in Table 3-6.

Table 3-6 First items to be dealt with

Item Questions raised

Terminology What is a smart water service? What are the specifications? How to assess its performance?

Leakage alert How to evaluate a service for leakage alert? How to define performance indicators for benchmarking? (Some common indicators would allow to unify the service and to explain its benefit to the end-user)

Backflow Which information can be given to the end-user? Which services can be offered to the end-user?



Water networks supervision What are the specifications for this supervision? How to evaluate the supervision performance?

Quality supervision Which services can be offered to the end-user? Which services can be offered to the water operator?

Note: Water metering is not considered in the GE3 working group because this topic is included in the standard EN 14154-4:2014 “Water meters – Part 4: Additional functionalities” of the European Technical Committee CEN/TC 92 “Water meters”. During their first meeting, the GE3 has decided to focus on the following use cases for preliminary work in the upcoming months: - Leakage alert - Over-consumption detection - Alert in case of backflow - Water networks supervision These four topics were selected because technical solutions exist in the industry, and authorities responsible for water management have shown their interest in such items. Moreover the end-user is also concerned by these topics, and economic issues are real and well-known. The following criteria have been raised by the experts for future works: - Performance of smart service and measurement tools - Data spatiality - Data temporality - Data representativity Some use cases identified by the GE3 experts are clearly in the scope of the Wisdom project. Consequently it should be interesting to suggest a presentation of the WISDOM results to the GE3.

3.4 ICT4WATER Cluster recommendations on standards and

standardisation activities

The document ‘Emerging Topics and technology Roadmap for Information and Communication Technologies for water Management’ [11] is based on the deliverables of the ongoing and finished project grouped in ICT4Water cluster, ICT4Water Cluster report on Recommendations for Standards and Standardisation in the European SMART Water Market, Societal Challenges 5 (SC5) Expert Advisory Group Report and other documents. As part of the work carried out by the cluster to identify the main actors, challenges, issues and gaps in the usage of ICT for water management, Standardisation is one of the topics identified as critically relevant in order to obtain widely accepted market solutions for the water domain.



A summary extracted from the ICT4 Water management roadmap document is presented below to stress the main conclusions obtained from the analysis of the work done by this hub, grouping 15 sister projects on ICT and Water Management. “..One of the reasons for the slowness of the market is the absence of standards in the water domain. One of the lessons learned, from EU funded WatERP project, is that by using current OGC standards it is possible to provide interoperability among different systems, but it requires the participation of all stakeholders. As yet the emerging products and services are the result of uncoordinated individual initiatives. They do not join up and neither do their developers use a common terminology. Assembling a system from the available components has not yet reached the level of ease and reliability required by service providers and value added resellers for them to start setting up such services for end users. The absence of standards is a major factor inhibiting the participation of public bodies. For them, following standards means they can demonstrate that they have endeavoured to follow best practice. This again highlights the importance of initiating action in this area now. The need for global data sets driven by climate change, the fact that many water issues are transboundary and the need to understand the earth as a system of interacting processes can only lead to stronger pressures for standards that will make water datasets, tools and models implementations interoperable. There is a need for plant and networks description guidelines – to allow partitioning of the data based on their usage and their cost. Regarding ontologies, especially in the Asset Management area, one question is about the existence of a common language for people who have different views from very different business processes. Another question is about the capability to “navigate” inside this semantic model to see what the relationships are, what are the assets which are upstream or downstream in the network. In spite of the above, the conclusions from the ICT4Water cluster’s meetings, which are supported both by the industry and the research partners, suggest that the new technologies and the products and services arising from them have reached the point where they can contribute to achieving the EC’s energy policy goals and that a market for their delivery could form. From experience within ICT4Water cluster projects and outside, it is clear that standards which enable interoperability between products (e.g. the definition of key terms and specification of connecting interfaces) will be of value to all the market players and will create further opportunities for innovation. Lack of standardisation in the SMART Water Market is seen as one of the biggest obstacles in realising the full potential that the adoption of this technology has in making SMART Water Networks standard practice.” EU wide Domestic Water Audits Water demand management from water utilities strongly depends on the availability of detailed water consumption data, which allow accurate forecasting and thus effective management of water resources to ensure demand is met within specified cost, quality, and security constraints. With only one in two water consumers metered in Europe, and at best with an aggregated knowledge of total water demand (ranging from 3 months to 1 day), water demand management is based on crude assumptions about consumers and their typical water uses. On an international setting, this missing knowledge is partly provided from Water Audits, i.e. in-situ studies of consumers, water fixtures, and typical water uses. Such studies provide data needed from water utilities, as well as goods manufacturers (e.g. faucets, washing machines) for anticipating demand and the parameters that influence it, the provision of water calculators, the targeting of retrofit and rebate programs for water efficiency, the tuning and calibration of water related products for different markets, etc. Unfortunately, the results of international water audits cannot be transferred in EU, and not even between different countries in EU. This is a result of the highly localized and evolving water use profiles across different populations.



ICT4Water Cluster indicated that the new SMART technologies can lead to more efficient delivery and use of water and hence a reduction in the demand for energy. Then in the context of standards and creating a marketplace the identified challenges are shown in the table below:

Table 3-7 Challenges identified

Adopting/developing water vocabularies and ontologies so that there is semantic clarity;

Developing a common architecture for SMART water;

Identifying/adopting/developing critical interface standards so that:

o users can confidently and easily assemble systems from interconnecting,

o components sourced from multiple suppliers,

o barriers to new entrants joining the marketplace are reduced,

o competition is increased,

o new opportunities for innovation are created,

o synergies and coordination among stakeholders can be improved,

o easy connection and exchanging data and metadata between other sectors involved: geographical data, meteorological data, earth observation data, citizen science data, etc… can be provided;

Identifying where quality (accuracy, reliability, resilience, etc.) standards are required, especially in relation to attaining the EC’s objectives but also in relation to the formation of the market;

Harmonising energy and water monitoring practices sufficiently that it becomes practical to demonstrate to users through the metering or billing system how their water use is impacting their energy use, thereby giving water users the incentive to be efficient;

Setting up a governance structure, one of whose terms of reference would be the introduction of standards.

Technology changes should end in better applications for customers and citizens in order to benefit their day to day life and contribute to raise the awareness over water constraints. Taking into consideration ICT4Water inquiry, the creation of a borderless ‘digital single market’ for water services should be preceded by creation of digital public-private-partnerships (PPP) as an innovation Hub that aims to foster innovative technology and entrepreneurial talent for water services. The Hub should be supported with a significant funding so as to foster the transition of ICT technologies in water sector from pilot scale to wide market uptake.



4. REFERENCES

[1] http://www.ict4water.eu/ [2] http://www.widest.eu/ [3] http://www.waterideas2014.com/?lang=en [4] http://issewatus.eu/pluginfile.php/902/mod_resource/content/1/CCWI_iWIDGET_ICT4Water

_Standards_report_v2.pdf [5] http://www.swan-forum.com/ [6] http://water.europa.eu/ [7] http://www.eip-water.eu/ [8] WatERP, “Water Enhanced Resouce Planning (WatERP),” 2013.

[9] “Waternomics.” [Online]. Available: http://waternomics.eu/. [Accessed: 25-Feb-2015].

[10] 'Survey on clean slate Cellular-IoT standard proposals', Guibane, Wael; Nolan Keith E; Kelly, Mark Y. Computer and Information Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and Secure Computing; Pervasive Intelligence and Computing (CIT/IUCC/DASC/PICOM), Pages: 1596 - 1599, DOI: 10.1109/CIT/IUCC/DASC/PICOM.2015.240 IEEE Conference Publications

[11] http://www.ict4water.eu/wp-content/uploads/2015/10/ICT4WaterRoadmap2016_final.pdf [12] Postscapes, “IoT Alliances round-up,” 2015. .

[13] F. Carrez, M. Bauer, M. Boussard, N. Bui, C. Jardak, J. De Loof, C. Magerkurth, S. Meissner, A. Nettsträter, A. Olivereau, M. Thoma, J. W. Walewski, J. Stefa, and A. Salinas, “Internet of Things – Architecture IoT - A Final architectural reference model for the IoT v3.0,” 2013.

[14] Cisco, “Building the Internet of Things.” pp. 2013–2014, 2013.

[15] ITU-T, “SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS,” 2012.

[16] Intel, “Intel IoT Reference Model.” [Online]. Available: http://download.intel.com/newsroom/kits/iot/insights/2014/gallery/images/INTEL_04_iot-01-1-01.jpg. [Accessed: 22-Dec-2015].

[17] Open Interconnect Consortium, “OIC CORE CANDIDATE SPECIFICATION PROJECT B,” 2015.

[18] Industrial Internet Consortium, “Industrial Internet Reference Architecture.” [Online]. Available: http://www.iiconsortium.org/IIRA.htm.



[19] N. Balta-Ozkan, R. Davidson, M. Bicket, and L. Whitmarsh, “Social barriers to the adoption of smart homes,” Energy Policy, vol. 63, pp. 363–374, 2013.

[20] http://www.slideshare.net/butler-iot/butler-project-overview-13603599

[21] H. Zimmermann, OS1 Reference Model - The IS0 Model of Architecture for Open Systems Interconnection, IEEE Transactions on Communications COM-28, No. 4: April 1980.

[22] https://entrepreneurshiptalk.wordpress.com/2014/01/29/the-internet-of-thing-protocol-stack-from-sensors-to-business-value/

[23] https://en.wikipedia.org/wiki/Edge_device

[24] https://www.osgi.org/

[25] “OWL 2 Web Ontology Language Document Overview.” [Online]. Available: http://www.w3.org/TR/2009/WD-owl2-overview-20090327/. [Accessed: 28-Apr-2015].

[26] “RDF Schema 1.1.” [Online]. Available: https://www.w3.org/TR/2014/REC-rdf-schema-20140225/. [ Accessed: 18-Jan-2016].

[27] “SPARQL Query Language for RDF.” [Online]. Available: http://www.w3.org/TR/rdf-sparql-query/#basicpatterns. [Accessed: 24-Feb-2015].

[28] “SWRL: A Semantic Web Rule Language Combining OWL and RuleML.” [Online]. Available: https://www.w3.org/Submission/SWRL/. [Accessed: 18-Jan-2016].

[29] International Electrochemical Commission, “CIM Standards.”

[30] BuildingSmart, “IFC4 Add1 Release.” [Online]. Available: http://www.buildingsmart-tech.org/specifications/ifc-releases/ifc4-add1-release. [Accessed: 18-Jan-2016].

[31] “CityGML | OGC.” [Online]. Available: http://www.opengeospatial.org/standards/citygml. [Accessed: 18-Jan-2016].

[32] BSI, “Smart city concept model- guide to establishing a model for data interoperability.” 2014.

[33] M. Compton, P. Barnaghi, L. Bermudez, R. García-Castro, O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, D. Le Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, and K. Taylor, “The SSN ontology of the W3C semantic sensor network incubator group,” Web Semant. Sci. Serv. Agents World Wide Web, vol. 17, pp. 25–32, Dec. 2012.

[34] “IEC 61970-501:2006 | IEC Webstore.” [Online]. Available: https://webstore.iec.ch/publication/6215. [ Accessed: 18-Jan-2016].

[35] BuildingSmart, “ifcXML releases.” [Online]. Available: http://www.buildingsmart-tech.org/specifications/ifcxml-releases. [Accessed: 18-Jan-2016].

[36] BuildingSmart, “ifcOWL.” [Online]. Available: http://www.buildingsmart-tech.org/future/linked-data/ifcowl. [Accessed: 18-Jan-2016].



[37] OGC, “WaterML2 - A Global Standard for Hydrological Time Series.” [Online]. Available: http://www.waterml2.org/. [Accessed: 18-Jan-2016].

[38] Laurie Reynolds, “SWIM – a semantic ontology for interoperability.” 2014.

[39] OGC, “CityGML UtilityNetworkADE - Citygml.” [Online]. Available: http://www.citygmlwiki.org/index.php/CityGML_UtilityNetworkADE. [Accessed: 18-Jan-2016].

[40] “CUAHSI hydrological information system,” 2004.

[41] SWEET, “SWEET Overview.” [Online]. Available: https://sweet.jpl.nasa.gov/. [Accessed: 23-Oct-2015].

[42] INFORMATIEHUIS WATER, “Welcome to Aquo - The Aquo standard,” 2013. [Online]. Available: http://www.aquo.nl/. [Accessed: 18-Jan-2016].

[43] http://digital-built-britain.com/DigitalBuiltBritainLevel3BuildingInformationModellingStrategicPlan.pdf

Water analytics and Intelligent Sensing for Demand Optimised Management · 2017-05-24 · Small or...

Documents

Transcript of Water analytics and Intelligent Sensing for Demand Optimised Management · 2017-05-24 · Small or...