D1.3 State of the art review of ICT for wastewater ...

Grant Agreement No.: 689817

Project acronym: INNOQUA

Project title: Innovative Ecological on-site Sanitation System for

Water and Resource Savings

Innovation Action

Topic: Water-1b-2015: Water Innovation: Boosting its value for

Europe – Demonstration/pilot activities

Starting date of project: 1st of June 2016

Duration: 48 months

D1.3 – State of the art review of ICT for wastewater

management focusing on biological on-site

systems

Organisation name of lead contractor for this deliverable: EUT

Version 1 –

Rev.0

Due Date 31/05/2017

Submission

Date

31/05/2017

Author Edgar Rubión Soler (EUT)

Dissemination Level

PU Public X

CO Confidential, only for members of the consortium (including

the Commission Services)

INNOQUA – D1.3 “State of the art review of ICT for wastewater management focusing on biological

on-site systems” M12 2/55

Document history

History

Version Date Author Comment

1 25.07.2016 EUT 1st draft version of the index

2 15.05.2017 EUT 1st version of the document

3 22.05.2017 R2M, UDG,

SUEZ Review of the document

4 30.05.2017 EUT New version of the document

5 30.05.2017 EUT Final review and minor changes



Table of Contents

Executive Summary ...................................................................................................................... 5

1 Introduction ........................................................................................................................... 6

1.1 Work Package 1 Objectives .............................................................................................. 6

1.2 Purpose of the Deliverable D1.3 ....................................................................................... 6

1.3 Relations to Other Activities in the Project ........................................................................ 7

1.4 Document Outline ............................................................................................................. 7

2 State of the Art ...................................................................................................................... 9

3 Technologies ....................................................................................................................... 13

3.1 Sensorization technologies ............................................................................................. 13

3.2 IoT Data link protocols .................................................................................................... 20

3.2.1 Bluetooth Low Energy (BLE) .................................................................................... 20

3.2.2 IEE 802.15.4 ............................................................................................................ 20

3.2.3 ZigBee ..................................................................................................................... 21

3.2.4 LoRaWAN ................................................................................................................ 21

3.2.5 IEE 802.11 (WiFi) .................................................................................................... 22

3.2.6 Sigfox ...................................................................................................................... 22

3.2.7 Conclusions ............................................................................................................. 22

3.3 Devices ........................................................................................................................... 26

3.3.1 Conclusions ............................................................................................................. 31

3.4 Operative systems .......................................................................................................... 31

3.4.1 Contiki ..................................................................................................................... 31

3.4.2 TinyOS .................................................................................................................... 32

3.4.3 RIOT OS .................................................................................................................. 32

3.4.4 OpenWSN ............................................................................................................... 32

3.4.5 OpenEmbedeed....................................................................................................... 33

3.4.6 Conclusions ............................................................................................................. 33

3.5 Data integration technologies .......................................................................................... 35

3.5.1 Conclusions ............................................................................................................. 37

4 Regulation in force, certification and standardisation issues of the interoperability .... 38

4.1 Consortiums and standardisation bodies ........................................................................ 38

4.2 Standards ....................................................................................................................... 41

4.2.1 Data Distribution Service (DDS) ............................................................................... 41

4.2.2 Message Queuing Telemetry Transport (MQTT) ...................................................... 41

4.2.3 Advanced Message Queuing Protocol (AMQP) ....................................................... 42

4.2.4 Java Message Service (JMS) .................................................................................. 42

4.2.5 REST/HTTP ............................................................................................................. 42



4.2.6 Constrained Application Protocol (CoAP)................................................................. 42

4.2.7 Conclusions ............................................................................................................. 43

5 IoT architectures ................................................................................................................. 47

5.1 Three Level Architecture with IoT Elements without IP Protocol ..................................... 47

5.2 Two Level Architecture with IoT Elements with IP Protocol ............................................. 48

5.3 Two Level Architecture with IoT Elements without IP Protocol ........................................ 49

5.4 Conclusions .................................................................................................................... 49

6 Conclusions......................................................................................................................... 50

7 Bibliography ........................................................................................................................ 51



Executive Summary

The aim of the INNOQUA Project is to progress, towards commercialisation, the development of a

fully ecological modular sanitation system that integrates individual low cost, sustainable and

biologically based technologies. The system will offer flexible waste water treatment solutions to suit

a variety of target markets in developed and developing countries.

This report, Deliverable 1.3 (D1.3), is the last from the Project’s Work Package (WP) 1 – Pre-market

analysis and end-users requirements. It corresponds with the outcome of Task 1.4 “ICT for Water

Management”.

The aim of this document is to provide a comprehensive review of existing water quality monitoring

modules, sensors and systems in particular when implemented in on-site and/or biological sanitation

systems taking advantage of the ICT4Water cluster, EIP action group and literature. Moreover, the

enabling technologies such as sensors, communication technologies, open hardware devices,

operative systems, and data integration technologies will be identified and evaluated. It will serve as

a guide for design the Monitoring and Control Unit (MCU) and its architecture. The document also

presents a description of the most relevant standards and IoT (Internet Of Things) architectures for

remote metering.

Some of the key information points highlighted within this report include the following:

From the literature study:

o Most commonly qualitative parameters of water are chlorophyll-a, pH, Secchi Disk

Depth (SDD), temperature, Coloured Dissolved Organic Matters (CDOM), Total

Organic Carbon (TOC), Dissolved Organic Carbon (DOC), Total Suspended Matters

(TSM), Turbidity, Total Phosphorus (TP), Ortho-Phosphate, Chemical Oxygen

Demand (COD) , Biochemical Oxygen Demand (BOD), Electrical Conductivity (EC)

and Ammonia Nitrogen (NH3-N).

o Two level architecture with objects connected with IP protocol and two level

architecture with objects connected without IP protocol are used on deployments

where there is a large distance between IoT Elements.

Bluetooth Low Energy (BLE) communication technology allows to build low-cost, low-energy

and low-range IoT architectures based on star-bus topology.

Arduino open hardware is a low-cost device which is able to integrate multiples sensors and

actuators thanks to on-board GPIOs and the huge variety of expansion-cards to enhance its

capabilities (e.g. 4-20mA inputs…).

Raspberry Pi 3 is a low-cost device which is able to route the data through mobile

communications by using SIM expansion-boards and deploy an IoT platform to manage,

analyse and visualise the water quality data.

MQTT communication protocol is addressed to low-power communications and is widely

supported by the major part of OS and IoT platforms.



1 Introduction

The aim of the INNOQUA project is to design and develop a strongly market focused modular set of

innovative, scalable, fully ecological sanitation solutions for rural communities worldwide. The types

of technologies selected and their proposed application provides a novel approach to on-site

sanitation with the potential for near zero waste production and the opportunity to produce re-usable

water. The INNOQUA project commenced in June 2016 (M01) and this report, Deliverable 1.3 ”State

of the art review of ICT (Information and Communication Technologies) for wastewater management

focusing on biological on-site systems” (D1.3), is the last from the project’s Work Package 1 (WP1)

– Pre-market analysis and end-users requirements.

1.1 Work Package 1 Objectives

The goal of WP1 is to identify, quantify and prioritise target markets according to their market

potential and associated end-user requirements. This WP will also tackle the social acceptance of

both treatment systems and treated water and will study how ICT can act to facilitate this acceptance.

All of them are aligned to satisfy the following Project Milestones such as MS1 “System specifications

and requirements” and MS2 “First prototypes available”.

1.2 Purpose of the Deliverable D1.3

On one hand, in the INNOQUA project the Task 1.4 “ICT for Water Management” is associated with

the review of existing water quality monitoring modules, sensors and systems in particular when

implemented in on-site and/or biological sanitation systems. On the other hand, this deliverable will

aim to identify which are the most suitable technologies and system architecture for the ICT module

responsible of the INNOQUA global process management and water quality metering. Moreover,

the document is also focused on standardisation issues that affects directly the interoperability and

information exchange. Then, the Deliverable 1.3 provides a detailed report reviewing the state of the

art of water quality monitoring systems, the enabling technologies, the IoT standards and IoT

architectures.



1.3 Relations to Other Activities in the Project

Figure 1: Relation with other WPs and Deliverables

Figure 1 illustrates the relations of this deliverable to other activities in the INNOQUA project. These

relations are represented as links numbered from 1 to 2 and are described as follows:

Link 1: The D2.2 takes advantage of the current deliverable information in order to propose the

standardised INNOQUA ICT architecture for the Monitoring and Control Unit (MCU).

Link 2: The content of this deliverable provides essential information for the definition &

implementation of the INNOQUA ICT architecture performed throughout the WP3.

1.4 Document Outline

The remainder of this document is organised as follows:

Chapter 2 shows the state-of-the-art of water quality monitoring systems taking advantage

of the ICT4Water cluster, EIP action group and literature.

Chapter 3 describes the key enabling technologies for MCU including sensors for monitoring

the water quality of the INNOQUA modules, communication technologies for a wireless

transfer of gathered measures and operational directions, open hardware devices for

managing, centralizing, analysing and routing the information, operative systems for

facilitating the development in open hardware devices, and data integration technologies for

WP 2 – Technical Specifications and Technology Optimisation

D2.1 Effluent physico-chemical and microbiological specifications

D2.2 – Engineering and structural specifications

D2.3 – Technical specifications report including design and engineering

requirements…

WP 1 – Pre-market Analysis and End-Users Requirements

D1.1 – Regulation, certification and standard review report

D1.2 – Pre-Market study, including partial market surveys, social and

acceptance…

D1.3 – State-of-the-art review of ICT for wastewater management

focusing on…

WP 3 – Technology Integration, Eco-Design and Pre-Industrial Scale-Up

D3.1 – Test Plan

D3.2 Implementation Guidelines

1

D3.3 Report on final design assessment including LCA and LCC

assessment

2



exchanging the information following well-knowledge standards and guidelines.

Chapter 4 presents a description of the relevant standardisation bodies and communication

standards for exchanging the information following well-knowledge standards and guidelines

for an interoperable INNOQUA ICT system.

Chapter 5 shows the relevant ICT architectures for IoT deployments.

Chapter 6 is the conclusions.



2 State of the Art

The biological sanitation systems require of a regular and continuous monitoring of water quality that

is based on the chemical, physical, and microbiological characteristics of water. Because of this,

there is a need for screening and monitoring water quality by measuring the concentration of

chemical species including: (i) inorganic species such as nitrogen and phosphorous species (i.e.

nutrients), metals (calcium, magnesium, sodium, potassium), inorganic carbon species, chlorine, or

sulphur among others; (ii) organic compounds derived from decaying biological materials, and (iii)

micropollutants from anthropogenic origin such as pesticides, pharmaceuticals, industry-by products

and transition metals… However, traditional monitoring techniques are mainly based on laboratory

analyses of the collected samples (Korostynska, Mason, & Al-Shamma’a, 2013) and (Lambrou,

Anastasiou, Panayiotou, & Polycarpou, 2014). This approach requires a considerable effort and

hence, it is expensive. Moreover, it requires of a strict protocol to ensure that the composition of the

sample do not change during transportation and before analysis.

Then, there is a need for more efficient monitoring methods based on in-situ measurements by using

sensors. Several studies involving the implementation of water quality monitoring systems using

wireless sensor network (WSN) technology can be found in literature. Table 1 presents some of

these studies.

Table 1: Distributed systems for measuring water quality parameters

Distributed systems for measuring water quality parameters

(Postolache, Girao, Pereira, & Ramos, 2003)

(Jiang, Xia, He, & Wang, 2009)

(Yifan & Peng, 2008)

(Wang, Wang, & Hao, 2009)

(Kotamäki, 2009)

(Chung, Chen, & Chen, 2011)

(Prasad, Mamun, Islam, & Haqva, 2015)

(Raut & Shelke, 2016)

(Cloete, Malekian, & Nair, 2016)

In (Postolache, Girao, Pereira, & Ramos, 2003), the parameters are monitored and sent to a land

based station by using GSM (Global System for Mobile communication) network. An enhanced

Wireless Sensor Network (WSN) to monitor temperature, turbidity, pH, dissolved oxygen and

conductivity, and also video of key areas is depicted in (Yifan & Peng, 2008). The Water Monitoring

System implemented in (Jiang, Xia, He, & Wang, 2009) analyses and processes water quality

parameters which are transferred to the base station via GPRS (General Packet Radio Service).

(Wang, Wang, & Hao, 2009) is Zigbee-based WSN for real-time water quality monitoring. WSN for

agriculture and water monitoring that uses GSM and GPRS technology for transmission is defined

in (Kotamäki, 2009). DEPLOY project introduces a water quality and environmental monitoring with

an autonomous network of sensors to measure pH, temperature, depth, conductivity, turbidity and

dissolved oxygen. (Chung, Chen, & Chen, 2011) proposes a microcontroller-based WSN to measure



water quality parameters and transmit them by using GSM. In (Prasad, Mamun, Islam, & Haqva,

2015), the seawater quality is monitored by using remote sensing technologies. The data are

transferred though GSM to the Cloud. Other study, (Raut & Shelke, 2016), monitors the pH, turbidity

and temperature to measure the water quality. The IoT Elements are led by a PIC microcontroller

(PIC18F4550) that takes advantage the UART protocol to send data through Zigbee. Finally, in

(Cloete, Malekian, & Nair, 2016) there is also a PIC microcontroller with Zigbee communication but

in this case, quality measurements such pH, temperature, conductivity, flow and ORP are gathered.

On the other hand, these previous IoT architectures extracted from literature can be classified as is

described on Section 5: (i) three level architecture with objects connected without IP protocol; (ii) two

level architecture with objects connected with IP protocol and (iii) two level architecture with objects

connected without IP protocol. Then, (Yifan & Peng, 2008), (Jiang, Xia, He, & Wang, 2009), (Wang,

Wang, & Hao, 2009), (Raut & Shelke, 2016) and (Raut & Shelke, 2016) WSN are based on three

layer architectures, where there are gateway to route the data from sensors to base station. Instead,

(Postolache, Girao, Pereira, & Ramos, 2003) (Kotamäki, 2009) (Chung, Chen, & Chen, 2011) and

(Prasad, Mamun, Islam, & Haqva, 2015) WSNs are based on two layer architectures (see Section

5.2), where the network uses GSM or GPRS technology for transmission of sensor data. It is

important to note that two level architecture with objects connected with IP protocol and two level

architecture with objects connected without IP protocol are used on deployments where there is a

large distance between IoT Elements.

As can be observed from the literature study, most water quality monitoring systems that have

sensing nodes, are able to perform wireless communication and process the data from the sensors

(Jin, Shao, Zhang, An, & Malekian, 2016) to achieve meaningful results.

Concerning the most commonly measured water quality parameters, the Table 2 presents a list of

the common qualitative parameter and examples where they are monitored:

Table 2: Most commonly qualitative parameters of water

Qualitative parameter of

water

Literature

chlorophyll-a (Giardino, et al., 2014) (Lim & Choi, 2015) (Santini, Alberotanza,

Cavalli, & Pignatti, 2010) (Tilstone, et al., 2013)

pH (Postolache, Girao, Pereira, & Ramos, 2003) (Yifan & Peng,

2008) (Jiang, Xia, He, & Wang, 2009) (Chung, Chen, & Chen,

2011) (Prasad, Mamun, Islam, & Haqva, 2015) (Raut & Shelke,

2016) (Cloete, Malekian, & Nair, 2016)

Secchi Disk Depth (SDD) (Allan, Hamilton, Hicks, & Brabyn, 2011)

(Bhatti, Nasu, Takagi, & Nojiri, 2008) (Wang, et al., 2005)

(Brezonik, Menken, & Bauer, 2005)

temperature (Ahn, Shanmugam, Lee, & Kang, 2006) (Casey, Brandon,

Cornillon, & Evans, 2010) (Handcock, et al., 2006) (Syariz, et al.,

2014) (Postolache, Girao, Pereira, & Ramos, 2003) (Yifan &

Peng, 2008) (Jiang, Xia, He, & Wang, 2009) (Chung, Chen, &

Chen, 2011) (Raut & Shelke, 2016) (Cloete, Malekian, & Nair,

2016)



Coloured Dissolved

Organic Matters (CDOM)

(Giardino, et al., 2014) (Braga, et al., 2013) (Fiorani, et al., 2006)

(Zhu, Yu, Tian, Chen, & Gardner, 2011);

Total Organic Carbon (TOC) (Imen, Chang, & Yang, 2014) (Chang N.-B. , Vannah, Yang, &

Elovitz, 2014) (Chang & Vannah, Monitoring the total organic

carbon concentrations in a lake with the integrated data fusion

and machine-learning (IDFM) technique., 2012)

Dissolved Organic Carbon

(DOC)

(Ferrari, Dowell, Grossi, & Targa, 1996) (Del Castillo & Miller,

2008) (Karaska, et al., 2004)

Total Suspended Matters

(TSM)

(Bhatti, Nasu, Takagi, & Nojiri, 2008) (Onderka) (Sudheer,

Chaubey, & Garg, 2006) (Wu G. , 2009)

Turbidity (Brezonik, Olmanson, Bauer, & Kloiber, 2007) (Alparslan,

Coskun, & Alganci, 2009) (He, Oki, Wang, & Oki, 2009)

(Postolache, Girao, Pereira, & Ramos, 2003) (Yifan & Peng,

2008) (Raut & Shelke, 2016),

Total Phosphorus (TP) (Shafique, Fulk, Autrey, & Flotemersch, 2003) (Lim & Choi, 2015)

(Nas, Karabork, Ekercin, & Berktay, 2007) (Song, et al., 2012)

(Wu, et al., 2010)

Ortho-Phosphate (El Saadi, Yousry, & Jahin, 2014)

Chemical Oxygen Demand

(COD)

(Somvanshi, Kunwar, Singh, Shukla, & Pathak, 2012) (Chen, et

al., 2007) (He, Chen, Liu, & Chen, 2008) (Huang, Xing, Qi, Yu, &

Zhang, 2007) (Yifan & Peng, 2008) (Jiang, Xia, He, & Wang,

2009)

Biochemical Oxygen

Demand (BOD)

(He, Chen, Liu, & Chen, 2008) (Whistler, 1996) (Ramasamy,

Venkatasubramanian, Sam, Chandrasekhar, & Ramasamy,

2005) (Qiu, Zhang, Tong, Zhang, & Zhao, 2006) (Yifan & Peng,

2008) (Jiang, Xia, He, & Wang, 2009)

Electrical Conductivity (EC) (Choubey, 2994) (Gürsoy, Birdal, Özyonar, & Kasaka, 2015)

(Mallick, Hasan, Alashker, & Ahmed, 2014) (Postolache, Girao,

Pereira, & Ramos, 2003) (Yifan & Peng, 2008) (Jiang, Xia, He, &

Wang, 2009) (Cloete, Malekian, & Nair, 2016)

Ammonia Nitrogen (NH3-N) (He, Chen, Liu, & Chen, 2008) (Wang, Fu, & He, 2011)

(Hamylton, Silverman, & Shaw, 2013)

On the other hand, the microbiological sensors for water quality are a key topic in the literature.

Basically, they are addressed to identify the presence of indicator microorganisms such as E. coli

and total coliforms that indicates contamination. Currently, the literature collects different approaches

of microbiological sensors to assess the water quality such as: (i) technology based on enzymatic

activity fluorescence and states to detect several gram negative and positive bacteria, thus providing

a measure of total bacteria levels in the water (Nikou, Mohamad, Absar, & Morteza, 2013); (ii)

microfluidic device based on impedance flow cytometry (detects cells through their dielectric

properties) to measure total bacterial levels in drinking water (Jian, et al., 2015); (iii) automated

immunoassays integrated in lab‐on‐a‐chip systems (Bridle, Miller, & Desmulliez, 2014) (Yoon & Kim,



2012); (iv) immunoassays combination with ATP analyses in water and food (Squirrel, Price, &

Murphy, 2002) (Qiu, Zhou, Chen, & Lin, 2009) (Casini, et al., 2014) (Bushon, Likirdopulos, & Brady,

Comparison of immunomagnedic separation/adenosine triphosphate rapid method to traditional

culture‐based method for E. coli and enterococci enumeration in wastewater, 2009) (Bushon, Brady,

Likirdopulos, & Cireddu, 2009) (Lee & Deininger, 2004), and in combination with other electrical

(Yoon & Kim, 2012) (Wojciechowski, et al., 2009) (Ricciardi, et al., 2010) and optical (Yoon & Kim,

2012) (Knauer, Ivleva, Niessner, & Haisch, 2012) detection methods; (v) on-chip Polymerase chain

reaction (PCR) to detect Cryptosporidium in water samples (Bridle, Miller, & Desmulliez, 2014); (vi)

microfluidic device followed by flow cytometry to detect E. coli (Liu, et al., 2011) requiring a previous

pre‐concentration due to low concentration in drinking water; (vii) electrical impedance biosensors

to measure microbial metabolism via an increase in both conductance and capacitance causing a

decrease in impedance (Ivnitski, Abdel‐Hamid, Atanasov, & Wilkins, 1999) and (viii) piezoelectric

biosensors to immobilise antibodies in the sensor surface detecting the mass and resonance

frequency of oscillation variation (Ivnitski, Abdel‐Hamid, Atanasov, & Wilkins, 1999).



3 Technologies

This section is focused on reviewing the technologies involved on IoT solutions. These technologies

include five different scopes: (i) sensorization technologies for measuring water quality; (ii) IoT Data

link protocols for a wireless transfer of gathered measures and operational directions; (iii) open

hardware devices for managing, centralising, analysing and routing the information; (iv) operative

systems for facilitating the development in open hardware devices; and (v) data integration

technologies for exchanging the information following well-knowledge standards and guidelines.

3.1 Sensorization technologies

Sensors are a key part in the Internet of Things and their goal is to react to a specific physic or

chemical event (e.g. temperature, humidity, volumetric flow, etc.). Moreover, sensors are often

attached to an small electronic device in charge of collecting the data generated, transforming it to

a digital value and communicating it to its consumer using some kind of communication (i2c,

wireless, Bluetooth, radio, etc.).

Below, concrete sensors from different manufacturers, which are available in the market and are

suitable for water quality control in the INNOQUA solution, are identified listing the measurement

range, accuracy, average consumption, response time, supply voltage, additional electronic

components, maintenance, price… These parameters will allow to refine the MCU requirements

referring to sensors integration defined in WP2 Task 2.4 “Monitoring and Control Unit Specifications”.

Additionally, at a later stage of the INNOQUA project the most suitable sensors for INNOQUA MCU

will be identified taking advantage of this initial list.

It is important to note that the research will be concentrated on portable and low cost sensors due to

the project objectives.

INNOQUA – D1.3 “State of the art review of ICT for wastewater management focusing on biological on-site systems” M12 14/55

Table 3: Comparison of water quality sensors

Ph

eno

men

on

Des

crip

tio

n a

nd

Co

mp

any

Co

st

Acc

ura

cy

Ran

ge

of

Mea

sure

men

t

Tim

e o

f R

esp

on

se

Tim

e b

efo

re

reca

libra

tio

n

(yea

r)

Lif

e E

xpec

tan

cy (

year

)

Co

nsu

mp

tio

n

(S-S

enso

r/E

H-E

xtra

Har

dw

are)

Co

mm

un

icat

ion

Pro

toco

l (A

–

An

alo

gic

al, D

- D

igit

al)

Op

erat

ing

vo

ltag

e (V

)

Req

uir

e ex

tra

har

dw

are

UR

L

Physical measurements

pH

pH industrial

sensor

Atlas Scientific

170€ - 0 to 14 pH 1s ~1 ~4 - D(UART/I2C) 3.3-5 Y

http://atlas-

scientific.com/product_pages/p

robes/industrial_ph_probe.html

pH kit sensor

Atlas Scientific 135€ - 0 to 14 pH 1s ~1

~2.

5

max(14.5mA)

sleep(0.995m

A)

D(UART/I2C) 3.3-5 Y

http://atlas-

scientific.com/product_pages/ki

ts/ph-kit.html

SP10T

Consort 155€ 0.1%+1di

git 0 to 14 pH 2-3s ~0.25 ~1 - A - Y

http://www.consort.be/electroch

emistry/electrodes/ph-

electrode/

SP10T3S

Consort 176€

0.1%+1di

git 0 to 14 pH 2-3s ~0.25 ~1 - A - Y


emistry/electrodes/ph-

electrode/

HI1001

Hanna

instruments

130€ - 0 to 14 pH - - - - A - Y

http://hannainst.com/products/p

rocess/probes/hi1001-ph-

electrode-for-continuous-flow-

thru-monitoring.html


Ph

eno

men

on

Des

crip

tio

n a

nd

Co

mp

any

Co

st

Acc

ura

cy

Ran

ge

of

Mea

sure

men

t

Tim

e o

f R

esp

on

se

Tim

e b

efo

re

reca

libra

tio

n

(yea

r)

Lif

e E

xpec

tan

cy (

year

)

Co

nsu

mp

tio

n

(S-S

enso

r/E

H-E

xtra

Har

dw

are)

Co

mm

un

icat

ion

Pro

toco

l (A

–

An

alo

gic

al, D

- D

igit

al)

Op

erat

ing

vo

ltag

e (V

)

Req

uir

e ex

tra

har

dw

are

UR

L

Tem

per

atu

re PT-1000 Probe

Atlas Scientific 55€ ±0.10ºC -200 to 850 ºC 1s - -

max(14.3mA)

sleep(1.46m

A)

D(UART/I2C) 3.3-5 Y

http://atlas-


ts/temp_kit.html

ENV-TMP

Atlas Scientific 23€ ±1ºC -20 to 133 ºC 1ms n/a - 6µa(S) A

3.1-

5.5 N

http://atlas-

scientific.com/product_pages/p

robes/env-tmp.html

Dis

solv

ed o

xyg

en

DO Probe

Atlas Scientific 230€ ±0.2 0 to 35 mg/L 1s ~1 ~5

max(14.5mA)

sleep(0.995m

A)

A

D(UART/I2C) 3.3-5 N

http://atlas-scientific.com/product_pages/kits/do_kit.html

SZ10T

Consort 309€

1% ± 1 digit

0 to 60 mg/L ~2 - - - - Y

http://gentaurshop.com/product

/1264031/oxygen-electrode-

3m-cable-sz10t

SZ12T

Consort 360€

-

0 to 60 mg/L - - - - - - Y


/1264052/oxygen-electrode-

cable-15m-sz12t

Co

nd

uct

ivit

y

K 0.1

Atlas Scientific 200€ -

0.07 to 50000

µs/cm 1s ~10 ~10

max(20mA)

sleep(0.4mA) D(UART/I2C) 3.3-5 Y

http://atlas-scientific.com/product_pages/kits/ec_k0_1_kit.html

SK10B, K 1

Consort 139€ -

0.01 μS/cm -

200mS/cm - - - - A - Y


/1263920/conductivity-

electrode-1m-cable-sk10b

http://atlas-scientific.com/product_pages/kits/temp_kit.html



http://atlas-scientific.com/product_pages/probes/env-tmp.html










Ph

eno

men

on

Des

crip

tio

n a

nd

Co

mp

any

Co

st

Acc

ura

cy

Ran

ge

of

Mea

sure

men

t

Tim

e o

f R

esp

on

se

Tim

e b

efo

re

reca

libra

tio

n

(yea

r)

Lif

e E

xpec

tan

cy (

year

)

Co

nsu

mp

tio

n

(S-S

enso

r/E

H-E

xtra

Har

dw

are)

Co

mm

un

icat

ion

Pro

toco

l (A

–

An

alo

gic

al, D

- D

igit

al)

Op

erat

ing

vo

ltag

e (V

)

Req

uir

e ex

tra

har

dw

are

UR

L

SK10T, K 1

Consort 182€ -

0.01 μS/cm -

200mS/cm - - - - A - Y


/2330551/sk10t-ec-electrode-

3m-cable-sk10t3s

SK12T, K 0.1

Consort 236€ -

0.001 μS/cm -

20mS/cm - - - - A - Y


/1263973/conduct.-electrode-

0.1-cm-1-1m-cable-SK21T

SK21T, K 0.1

Consort 265€ -

0.001 μS/cm -

20mS/cm - - - - A - Y


/2330590/sk21t-conductivity-

electrode-3m-cable-sk21t

Tu

rbid

ityy

WQ730

Global Water - 1% 0 to 1000 NTU 8s ~0.5 20mA A 10-36 N

http://www.globalw.com/produc

ts/turbidity.html

850

Confab

Instrumentation

2300€

2% of

Full

Scale

0 to 2 NTU

0 to 20 NTU

0 to 200 NTU

0 to 2000 NTU

- n/a - 350mA A (0-5V) 12-24 Y

http://www.confabinstrumentati

on.com/850/850specs.htm

Operational measurements

Vo

lum

et

ric

Flo

w

3/4'' Flow Meter

Atlas Scientific 170€ ±5%

19 to 114 L/min

5 to 30 GPM - n/a -

No

load(8mA)

max(70mA)

D (Pulsed) 3-24 Y

http://atlas-scientific.com/product_pages/probes/3-4_flow_meter.html

http://www.globalw.com/products/turbidity.html

http://www.globalw.com/products/turbidity.html





Ph

eno

men

on

Des

crip

tio

n a

nd

Co

mp

any

Co

st

Acc

ura

cy

Ran

ge

of

Mea

sure

men

t

Tim

e o

f R

esp

on

se

Tim

e b

efo

re

reca

libra

tio

n

(yea

r)

Lif

e E

xpec

tan

cy (

year

)

Co

nsu

mp

tio

n

(S-S

enso

r/E

H-E

xtra

Har

dw

are)

Co

mm

un

icat

ion

Pro

toco

l (A

–

An

alo

gic

al, D

- D

igit

al)

Op

erat

ing

vo

ltag

e (V

)

Req

uir

e ex

tra

har

dw

are

UR

L

FPB1404

Omega 245€

±1% FS

3.8 to 38 L/min

(1 to 10 GPM) 1s 2mA (S) D (Pulsed) 5-24V Y

http://www.omega.com/pptst/F

PB1400.html

FPR303

Omega 275€ 1% FS

0.8 to 76 L/min (0.2 to 20 GPM)

- n/a - 2mA (S)

D (Pulsed) 5-24V Y

http://www.omega.com/pptst/dp

f700.html

Chemical measurements

Nit

rate

DX262-NO3

Mettler Toledo 1143.45€ -

1.0 to 1.0E-05

mol/L - n/a - - A - N

http://www.mt.com/es/es/home/

products/Laboratory_Analytics_

Browse/pH/sensor_electrode/Io

n-

selective_Electrodes/ISE_Half-

Cell/DX262-NO3.html

9707BNWP

Cole-Parmer 1100€ - 0.10 to 14000

ppm as N - n/a ~1 - A - Y

https://www.coleparmer.com/i/t

hermo-scientific-orion-

9707bnwp-sure-flow-ion-

selective-electrode-

nitrate/0571315

Nitrate Ion-

Selective

Vernier

215€ ±10% of

full scale

1 to 10000

mg/L - n/a - - A - Y

http://www.vernier.com/product

s/sensors/ion-selective-

electrodes/no3-bta

http://www.mt.com/es/es/home/products/Laboratory_Analytics_Browse/pH/sensor_electrode/Ion-selective_Electrodes/ISE_Half-Cell/DX262-NO3.html






http://www.vernier.com/products/sensors/ion-selective-electrodes/no3-bta




Ph

eno

men

on

Des

crip

tio

n a

nd

Co

mp

any

Co

st

Acc

ura

cy

Ran

ge

of

Mea

sure

men

t

Tim

e o

f R

esp

on

se

Tim

e b

efo

re

reca

libra

tio

n

(yea

r)

Lif

e E

xpec

tan

cy (

year

)

Co

nsu

mp

tio

n

(S-S

enso

r/E

H-E

xtra

Har

dw

are)

Co

mm

un

icat

ion

Pro

toco

l (A

–

An

alo

gic

al, D

- D

igit

al)

Op

erat

ing

vo

ltag

e (V

)

Req

uir

e ex

tra

har

dw

are

UR

L

Am

mo

niu

m NH4 BTA

Vernier 220€

±10% of

full scale

1 to 18000

mg/L - n/a - - A - Y

http://www.vernier.com/product

s/sensors/ion-selective-

electrodes/nh4-bta/

ISE20B 461€ - 1 to 18000

mg/L - - - - A - Y


/1264068/ammonium-

electrode-ise20b

Co

pp

er

ISE25B 461€ - - - - - - A - Y


/1264071/copper-electrode-

ise25b

HI4108

Hanna

Instruments

746€ - 0.065 to 6,355 mg/L Cu2+

- - - - A - Y

http://hannainst.com/products/e

lectrodes-and-probes/hi4108-

cupric-combination-ion-

selective-electrode.html

Cal

ciu

m

ISE23B 412€ - 0.2 to 40000 ppm

- - - - A - Y

http://www.gentaurshop.com/pr

oduct/1264070/calcium-

electrode-ise23b

OR

P ORP Probe

Atlas Scientific 155€ ±1mV -1019.9 to

1019.9 mV 1s ~1 ~2

max(20mA)

sleep(0.4mA)

A

D(UART/I2C) 3.3-5 N

http://atlas-


ts/orp_kit.html

http://atlas-scientific.com/product_pages/kits/orp_kit.html




Ph

eno

men

on

Des

crip

tio

n a

nd

Co

mp

any

Co

st

Acc

ura

cy

Ran

ge

of

Mea

sure

men

t

Tim

e o

f R

esp

on

se

Tim

e b

efo

re

reca

libra

tio

n

(yea

r)

Lif

e E

xpec

tan

cy (

year

)

Co

nsu

mp

tio

n

(S-S

enso

r/E

H-E

xtra

Har

dw

are)

Co

mm

un

icat

ion

Pro

toco

l (A

–

An

alo

gic

al, D

- D

igit

al)

Op

erat

ing

vo

ltag

e (V

)

Req

uir

e ex

tra

har

dw

are

UR

L

SP50X

Consort 168€ - -2000 to 2000

mV - ~1 ~1 0mA A Y


emistry/electrodes/orp-

electrode/

HI2002

Hanna

instruments

214€ - - - - - - - - Y

https://hannainst.de/1908-

hi2002/x-redox-

industrieelektrode-flow-thru-

monitoring.html?number=HI200

2-3

https://hannainst.de/1908-hi2002/x-redox-industrieelektrode-flow-thru-monitoring.html?number=HI2002-3







3.2 IoT Data link protocols

This section is aimed at identifying the most relevant IoT Data Link protocols which can be used on

INNOQUA ICT Architecture.

3.2.1 Bluetooth Low Energy (BLE)

BLE1 is one the most important short range communications technology that is commercialized by

the Bluetooth Special Interest Group. Its low energy can reach ten times less than the classic

Bluetooth while its latency can reach 15 times higher and the cost is similar. It follows master/slave

architecture and offers two types of frames: (i) adverting which is used for discovery and (ii) data

frames which are used to transfer the information. Nodes are usually awake only when they are

communicating, otherwise they go to sleep otherwise to save power.

All Bluetooth Smart devices use the Generic Attribute Profile (GATT). The application programming

interface offered by a Bluetooth Smart aware operating system will typically be based around GATT

concepts including: (i) discover UUIDs for all primary services; (ii) find a service with a given UUID;

(iii) find secondary services for a given primary service; (iv) discover all characteristics for a given

service; (v) find characteristics matching a given UUID; and (vi) read all descriptors for a particular

characteristic.

Commands are also provided to read (data transfer from server to client) and write (from client to

server) the values of characteristics: (i) a value may be read either by specifying the characteristic's

UUID, or by a handle value (which is returned by the information discovery commands above); (ii)

write operations always identify the characteristic by handle, but have a choice of whether or not a

response from the server is required; (iii) 'Long read' and 'Long write' operations can be used when

the length of the characteristic's data exceeds the MTU of the radio link.

Finally, GATT offers notifications and indications. The client may request a notification for a particular

characteristic from the server. The server can then send the value to the client whenever it becomes

available. For instance, a temperature sensor server may notify its client every time it takes a

measurement. This avoids the need for the client to poll the server, which would require the server's

radio circuitry to be constantly operational.

An indication is similar to a notification, except that it requires a response from the client, as

confirmation that it has received the message.

3.2.2 IEE 802.15.4

The 802.15.42 is supported by the Institute of Electrical and Electronics Engineers (IEEE) and is

probably the largest standard for low-data-rate WPANs. It was developed for low-data-rate monitor

1 https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/low-energy 2 http://www.ieee802.org/15/pub/TG4.html

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/low-energy

http://www.ieee802.org/15/pub/TG4.html



and control applications and extended-life low-power-consumption uses. The basic standard with

the most recent updates and enhancements is 802.15.4a/b. It defines a frame format, headers

including source and destination addresses, and how nodes can communicate with each other. It

uses time synchronisation and channel hopping to enable high reliability, low cost and meet IoT

communications requirements. Its specific Media Access Control (MAC) features can be

summarised as follows: (i) slot frame structure which is based on three nodes states (sleep, send

and receive) saving power; (ii) synchronisation to maintain the connectivity to their neighbours and

to the gateways; (iii) channel hopping to reduce the effect of interference and multi-path fading; and

(iv) network formation based on the advertisement and joining messages between nodes.

Under the best conditions the range can be as great as 1000 meters with a clear outdoor path, but

most applications cover a shorter range of 10 to 75 meters. On the other hand, 802.15.4 defines two

topologies. One of them is a basic star where all communications between nodes must pass through

the central coordinator node. And other is peer-to-peer (P2P) topology, where any device may then

talk to any other device.

3.2.3 ZigBee

ZigBee3 is designed for a large range of IoT applications including smart homes, remote controls

and healthcare systems. It is a standard of the ZigBee Alliance that maintains, supports, and

develops more sophisticated protocols for advanced applications. It supports a wide range of

network topologies including star, peer-to-peer, or cluster-tree. A coordinator controls the network

and is the central node in a star topology, the root in a tree or cluster topology and may be located

anywhere in peer-to-peer. ZigBee standard defines two stack profiles: ZigBee and ZigBee Pro.

These stack profiles support full mesh networking whose main benefit is that any node can

communicate with any other node, if not directly within range, but indirectly by relaying the

transmission through multiple additional nodes. ZigBee Pro offers more features including security

using symmetric-key exchange, scalability using stochastic address assignment, and better

performance using efficient many-to-one routing mechanisms. Furthermore, it increases network

reliability because if one node is disabled, there are usually alternate paths through the network.

Other important feature is that ZigBee is also available in a version that supports energy harvesting.

3.2.4 LoRaWAN

LoRaWAN4 is a wireless technology designed for low-power WAN networks with low cost, mobility,

security, and bidirectional communication for IoT applications. It is a low-power consumption

optimised protocol designed for scalable wireless networks with millions of devices which are able

to cover entire cities or hundreds of square kilometres. It supports redundant operation, location free,

low cost, low power and energy harvesting technologies. LoRaWAN is based star-of-stars topology

in which the gateway is a transparent bridge relaying messages between end devices and a central

3 http://www.zigbee.org/ 4 https://www.lora-alliance.org/What-Is-LoRa/Technology

http://www.zigbee.org/

https://www.lora-alliance.org/What-Is-LoRa/Technology



network server. Moreover, the communication between end devices and gateways is spread out on

different frequency channels and data rates to not interfere with each other and create a set of

“virtual” channels increasing the capacity of the gateway. LoRaWAN data rates range from 0.3 to 50

kilobits per second.

LoRaWAN networks can be classified on three different types: (i) bidirectional end-devices (Class

A); (ii) bidirectional end devices with scheduled receive slots (Class B); and (iii) bidirectional end

devices with maximal receive slots (Class C).

3.2.5 IEE 802.11 (WiFi)

IEE 802.115, which is created and maintained by the Institute of Electrical and Electronics Engineers

(IEEE) LAN/MAN Standards Committee (IEEE 802), is a set of specifications for implementing

wireless local networks (WLAN). It works on 900MHz, 2.4, 3.6, 5 and 60GHz frequency bands and

allows to create wireless local area networks at high speed. In practice, the WiFi can connect devices

to a broadband connection (300 Mbps) over a radius of several meters indoors (usually between 20

and 50 meters). In an open environment, the range can reach over several hundred of meters in

optimal conditions. Basically, there are two connection modes: (i) infrastructure mode that allows to

connect computers equipped with a wireless network adapter with each other via one or more access

points (AP), and (ii) ad-hoc mode that is used to connect (directly) devices equipped with wireless

network card. On the other hand, several topologies are supported by IEE 802.11 which are star,

tree, line and mesh.

3.2.6 Sigfox

Sigfox6 deploys wireless networks designed to connect to low-energy devices. It uses ultra-narrow

band, unlicensed sub-1 GHz bands and standard radio transmission methods. Sigfox transmits data

using a standard radio transmission method called binary phase-shift keying (BPSK). Its modulation

rate (300 bps) is extremely slow but it is able to get great range with fewer base stations. Moreover,

it offers a great resistance to jamming and standard interferers.

This technology is a good fit for any application that needs to send small, infrequent bursts of data.

Things like basic alarm systems, location monitoring, and simple metering are all examples of one-

way systems that might make sense for this network.

The network is based on one-hop star topology and requires a mobile operator to carry the generated

traffic

3.2.7 Conclusions

Below, the most relevant features of each IoT Data link are reviewed.

5 http://www.ieee802.org/11/

6 https://www.sigfox.com/en

http://www.ieee802.org/11/


Pro

toco

l

To

po

log

y

Co

nsu

mp

tio

n

No

des

Sec

uri

ty

Dat

a ra

tes

Fre

qu

ency

Ro

bu

stn

ess

Ran

ge

*

Ser

vice

Dis

cove

ry

Pro

file

Co

nce

pt

Co

st

IEEE

802.15.4

Tree

Mesh

Peer2Peer

Low - AES 128 bits

encryption

250kbps 868.0–868.6

MHz: Europe

902–928

MHz: North

America

2400–2483.5

MHz:

worldwide

use

Channel hopping

strategy

ACK

~750 m N N Low

ZigBee Star

Tree

Mesh

Low 65535 AES 128 bits

encryption

250kbps 868 MHz

Europe

915 MHz

North

America

2.4 GHz

MHz:

worldwide

use

Channel hopping

strategy

ACK

~100 m Y Y Medium

LoRaWAN Star-of-

stars

Low AES 128 bits

encryption

Unique

Network key

(EUI64)

50kbps 868/900/433

MHz band

Channel hopping

strategy

20 miles away

in

unobstructed

environments,

N N Medium


Pro

toco

l

To

po

log

y

Co

nsu

mp

tio

n

No

des

Sec

uri

ty

Dat

a ra

tes

Fre

qu

ency

Ro

bu

stn

ess

Ran

ge

*

Ser

vice

Dis

cove

ry

Pro

file

Co

nce

pt

Co

st

Unique

Application

key (EUI64)

Device

specific key

(EUI128)

in a city

several miles

Bluetooth

v2.1

Peer2Peer

Scatternet

Medium 8 56 / 128-bit

and

application

layer user

defined

1-3Mbit/s 2.4GhZ Adaptive fast

frequency hopping

FEC

Fast ACK

~100m Y Y Low

BLE Peer2Peer

Mesh

Star-bus

Low Not defined,

implementation

dependency

128-bit AES

with Counter

Mode CBC-

MAC and

application

layer user

defined

1Mbit/s

2.4GhZ Adaptive frequency

hopping

Lazy

Acknowledgement

24-bit CRC

32-bit Message

Integrity Check

~50m Y Y Low

Sigfox Peer2Peer

Star

Low - - 100bits/s 868MHz

Europe

902MHz US

50km rural

areas

10km urban

areas

N N High


Pro

toco

l

To

po

log

y

Co

nsu

mp

tio

n

No

des

Sec

uri

ty

Dat

a ra

tes

Fre

qu

ency

Ro

bu

stn

ess

Ran

ge

*

Ser

vice

Dis

cove

ry

Pro

file

Co

nce

pt

Co

st

WiFi BSS

ESS

High 2007 SSL3/TLS1,

HTTPS,

RSA, AES-

128/256,

3DES, RC-4,

SHA-1, MD-

5, WEP,

WPA and

WPA2

54 Mb/s 2.4GHz, 3.6

and 5 GHz

50m-500m N N Medium

LoRaWan, Sigfox and 802.15.4 is focused on low-density, infrequently-transmitting and uplink focused use cases and hence, they are better

when downlink and acknowledgements are not required. For example, in the case of automatic meter reading (AMR) which do not need to be

read too often. Moreover, LoRaWAN is a lossy protocol, due to its uncoordinated, asynchronous nature. Therefore, they are not suitable to be

used on INNOQUA ICT infrastructure where there are low-distances and the downlink communication is essential to perform actions through

the actuators. Instead, the main issue of the WiFi communication is the required high consumption power which is too high for battery-powered

solutions. Finally, BLE and Zigbee are very similar, both are robust, secure and reach similar range but the cost of BLE is more adjusted which

is suitable to build a low-cost MCU. Therefore it is likely that BLE option is applicable to the INNOQUA ICT architecture because: (i) low-

consumption facilitates the self-powered solutions; (ii) star-bus topology is appropriate for deployments based on a gateway; (iii) AES

encryption allows to secure the communications; (iv) range fits with the INNOQUA deployments characteristics; and (v) low-cost of BLE

modules allows to offer a competitive solution from economic point of view.



3.3 Devices

This section is aimed at identifying available open hardware solutions in the market from different

manufacturers (Adafruit, Arduino, Intel, Cypress, NXP, STMicroelectronics…) which can be useful

to deploy the INNOQUA ICT architecture. For each device is listed the most relevant parameters

such as processor, processor speed, cores, Flash memory, RAM, communication (Wifi, Bluetooth,

Ethernet, 802.15.4 radio… on board or possible using expansion cards), UART, SPI, I2C, number

of digital I/O, number of analog inputs, PWM, prize…

It is important to note that the devices listed in the table are very heterogeneous in reference to the

processor speed and RAM because the INNOQUA ICT architecture will require two differentiated

devices, one for managing the sensors and actuators and another for centralizing the data and

control and managing the communications. See Section 5 for more information.

Below, table presents the devices where:

‘OB’ means that is available in the board without add extra hardware

‘EC’ means that is available by using expansion cards and therefore the efforts are

minor

‘-’ means that is not supported on the board. This does not mean it is impossible to

do, just that it will require more effort.


Table 4: Open Hardware Specifications Comparison (OB: On Board, EC: Expansion Card, and -: Not supported)

Man

ufa

ctu

rer/

Bo

ard

Pro

cess

or

Bit

Wid

th

Pro

cess

or

Sp

eed

Co

res

Fla

sh

RA

M

SD

Car

d S

lot

802.

15.4

rad

io

WiF

i

Blu

eto

oth

10/1

00 E

ther

net

US

B H

ost

US

B C

lien

t

UA

RT

SP

I

I2C

Dig

ital

I/O

An

alo

g In

pu

ts

PW

M

Rea

l Tim

e C

lock

Pri

ze (€)

Adafruit Flora

ATmega32U4-AU

8 16

MHz 1

32 KB

2.5 KB

— — — — — — OB — OB — 8 4 OB — 37.9

Adafruit Gemma

ATtiny85 8 20

MHz 1

8 KB

0.5 KB

— — — — — OB OB — OB OB 5 1 OB — 11.9

Adafruit Metro 328 Mini

ATmega328 8 16

MHz 1

32 KB

2 KB

— — — — — — OB OB OB OB 20 6 OB — 11.79

Adafruit Metro 328

ATmega328 8 16

MHz 1

32 KB

2 KB

— — — — — — OB OB OB OB 20 6 OB — 18.39

Arduino Arduino Uno

Atmel ATmega328

8 16

MHz 1

32 KB

2 KB

EC EC EC

— EC

— — OB OB OB 14 6 OB — 21.42

Arduino Arduino Mega

2560

Atmel ATmega2560

8 16

MHz 1

256 KB

8 KB

EC EC EC

— EC

— — OB OB OB 54 16 OB — 35.06

Gravitech Arduino Nano 3.0

Atmel ATmega328

8 16

MHz 1

32 KB

2 KB

— — — — — — — OB OB OB 14 8 OB — 26.14

Intel Arduino 101

Intel® Curie Module

32 32

MHz 2

196 KB

24 KB

EC — EC

OB

EC

— OB OB OB OB 14 6 OB OB 40

Intel Edison

Intel® Edison SoC

32 500 MHz

2 400

0 MB

1000

MB OB EC

OB

OB

— — — OB OB OB 20 6 OB — 90.69

Intel Galileo

Intel® Quark SoC X1000

32 400 MHz

1 8

MB 256 MB

OB EC EC

— OB

OB OB OB OB OB 14 6 OB OB 89.95

Cypress Cypress CY8CKIT-

042-BLE

Cypress PSoC4 BLE

32 48

MHz 1

128 KB

1 MB

EC — EC

OB

— — OB OB OB OB 14 6 OB — 27.14


Man

ufa

ctu

rer/

Bo

ard

Pro

cess

or

Bit

Wid

th

Pro

cess

or

Sp

eed

Co

res

Fla

sh

RA

M

SD

Car

d S

lot

802.

15.4

rad

io

WiF

i

Blu

eto

oth

10/1

00 E

ther

net

US

B H

ost

US

B C

lien

t

UA

RT

SP

I

I2C

Dig

ital

I/O

An

alo

g In

pu

ts

PW

M

Rea

l Tim

e C

lock

Pri

ze (€)

NXP FRDM-K64F

Freedom

Kinetis MK64FN1M0

VLL12 32

120 MHz

1 1

MB 256 KB

OB EC EC

EC

OB

OB OB OB OB OB 16 6 EC OB 38.33

Digilent chipKIT uC32

PIC32MX340F512H

32 80

MHz 1

512 KB

32 KB

EC — EC

EC

EC

— — OB OB OB 42 12 OB OB 50.03

UDOO UDOO Neo

Freescale i.MX 6SoloX

32 1000 MHz

2 — 512 MB

OB — OB

OB

OB

OB — OB OB OB 36 6 OB — 50.44

STMicroelectronics

STM32F103 Nucleo

STMicroelectronics

STM32F103 32

72 MHz

1 128 KB

20 KB

EC — EC

— EC

— OB OB OB OB 38 14 OB OB 10.13

STMicroelectronics

STM32 Nucleo

STMicroelectronics STM32L

32 32

MHz 1

512 KB

96 KB

EC — EC

— EC

— OB OB OB OB 32 20 OB OB 18.83

Texas Instruments MSP432

LaunchPad

Texas Instruments

MSP432P401R

32 48

MHz 1

256 KB

4 KB

— — EC

— — OB — OB OB OB 48 24 EC OB 15.32


LaunchPad

Texas Instruments MSP430G2

16 16

MHz 1

16 KB

0.5 KB

— — EC

EC

— — OB OB OB OB 18 12 EC — 11.93


LaunchPad USB

Texas Instruments

MSP430F5529

16 25

MHz 1

128 KB

8 KB

— — EC

EC

— OB OB OB OB OB 17 8 EC — 11.51

Texas Instruments C2000 LaunchPad

Texas Instruments

C2000 TMS320F280

27

32 60

MHz 1

128 KB

64 KB

— — EC

EC

— — OB OB OB OB 22 13 OB — 20.22


Man

ufa

ctu

rer/

Bo

ard

Pro

cess

or

Bit

Wid

th

Pro

cess

or

Sp

eed

Co

res

Fla

sh

RA

M

SD

Car

d S

lot

802.

15.4

rad

io

WiF

i

Blu

eto

oth

10/1

00 E

ther

net

US

B H

ost

US

B C

lien

t

UA

RT

SP

I

I2C

Dig

ital

I/O

An

alo

g In

pu

ts

PW

M

Rea

l Tim

e C

lock

Pri

ze (€)

Texas Instruments C2000 LaunchPad - InstaSPIN-FOC

Texas Instruments

C2000 TMS320F280

27F

32 60

MHz 1

64 KB

12 KB

— — EC

EC

— — OB OB OB OB 22 13 OB — 28.83

Texas Instruments Tiva C LaunchPad

Texas Instruments

Tiva C TM4C123GH

6PM

16 80

MHz 1

256 KB

32 KB

— — EC

EC

— OB OB OB OB OB 43 8 OB — 23.49

Texas Instruments Hercules TMS570

LaunchPad

Texas Instruments

Hercules TMS570

16 80

MHz 2

384 KB

32 KB

— — EC

EC

— — OB OB OB OB 16 11 — OB 22.70

Texas Instruments Hercules RM4

LaunchPad

Texas Instruments

Hercules RM4 32

100 MHz

2 384 KB

32 KB

— — EC

EC

— — OB OB OB OB 16 11 — OB 41.50

BeagleBoard.org BeagleBoard-xM

Texas Instruments OMAP3530

32 1000 MHz

1 — 512 MB

OB — EC

EC

OB


BeagleBoard.org BeagleBone Black

Texas Instruments

AM3358 32

1000 MHz

1 204

8 MB

512 MB

OB — EC

EC

OB

OB OB OB OB OB 65 7 OB — 55.37

Seeed Studio Beaglebone Green

TI AM3358 32 1000 MHz

1 400

0 MB

512 MB

OB — EC

EC

OB


Netduino Netduino Go

STmicroelectronics

STM32F405 32

168 MHz

1 1

MB 100 KB

EC EC — — OB



Man

ufa

ctu

rer/

Bo

ard

Pro

cess

or

Bit

Wid

th

Pro

cess

or

Sp

eed

Co

res

Fla

sh

RA

M

SD

Car

d S

lot

802.

15.4

rad

io

WiF

i

Blu

eto

oth

10/1

00 E

ther

net

US

B H

ost

US

B C

lien

t

UA

RT

SP

I

I2C

Dig

ital

I/O

An

alo

g In

pu

ts

PW

M

Rea

l Tim

e C

lock

Pri

ze (€)

Netduino Netduino 2

STmicroelectronics

STM32F2 32

120 MHz

1 1

MB 60 KB

EC — EC

— — — OB OB OB OB 14 6 OB — 37.75

Netduino Netduino Mini

Atmel AT91SAM7

32 48

MHz 1

512 KB

64 KB

— — — — — — OB OB OB OB 4 4 OB — -

Netduino Netduino Plus

Atmel AT91SAM7

32 48

MHz 1

512 KB

42 KB

OB EC EC

— OB

— OB OB OB OB 14 6 OB — 53.95

Netduino Netduino Plus 2

STmicroelectronics

STM32F4 32

168 MHz

1 1

MB 192 KB

OB EC EC

— OB

— OB OB OB OB 14 6 OB — 64.75

Zolertia Re-MOTE

CC2538 ARM Cortex-M3

32 32

MHz 1

512 Kb

32KB

OB OB OB

— — OB OB OB OB OB — 5 OB OB 75.95

Raspberry Pi / Raspberry Pi 3

Model B

ARM Cortex-A53

64 1.2

GHz 4 n/a

1 GB

OB EC OB

OB

OB

OB OB EC OB OB 26 — OB — 36.30



3.3.1 Conclusions

Currently, there is a huge number of available devices in the market with similar physical

characteristics, therefore the community that supports these devices will be a key factor in the

choice.

Arduino has one of the most large and active communities in the open hardware world. Moreover,

there are available a large quantity of expansion-cards which facilitate the addition of the features

(e.g. Bluetooth Low Energy, 4-20mA inputs…) minimizing the electronical design and hence,

reducing future fails. This heterogeneity of expansion-cards also provides flexibility to Arduino

devices because they are easily customisable for multiple use cases. Arduino has a wide catalogue

of products and Arduino Mega 2560 fits the INNOQUA needs to develop an IoT Entity. It is capable

to: (i) manage sensors and actuators by using the on-board GPIOs (General Purpose Input/Output)

including digital, analogical and PWM (Pulse-Width Modulation) signal, and UART, I2C and SPI

communication interfaces; (ii) transfer the relevant data to a central device by using BLE technology

thanks to the expansion-cards; and (iii) be powered by batteries thanks to its low-power design.

Additionally, Arduino provides newly functionalities referring secure-element based on the private

key management in a safe way.

On the other hand, Raspberry Pi 3 is a more powerful device that is able to embed a Linux

distribution. It uses software which are either free or open source achieving a low-cost device. There

are other products having equal or better CPU capabilities but lacks somewhere in other support

(like software integration with the hardware). Moreover, it has easy availability and its Linux

distributions are in continuous improvement. It fits with the INNOQUA needs to develop a Gateway

because is capable to: (i) communicate with IoT Elements by using on-board BLE; (ii) routing the

data through mobile communications by using SIM expansion-cards or on-board WiFi/Ethernet; (iii)

centralize the data taking advantage of SD Card Slot; and (iv) deploy an IoT platform to manage,

analyse and visualise the water quality data.

3.4 Operative systems

This section is aimed at identifying and evaluating the multiples operative systems to support open

hardware solutions. Firstly, this OS are identified and described briefly and later for each are

reviewed its capabilities (application layer protocols, power awareness…), community support,

scientific community acceptance, open hardware support…

3.4.1 Contiki

Contiki7 is an open source, highly portable, multi-tasking operating system for memory-efficient

networked embedded systems and wireless sensor networks. Contiki provides three network

mechanisms: (i) the uIP TCP/IP stack, which provides IPv4 networking; (ii) the uIPv6 stack, which

7 http://www.contiki-os.org/



provides IPv6 networking; (iii) and the Rime stack, which is a set of custom lightweight networking

protocols designed specifically for low-power wireless networks. Moreover, it is designed for

microcontrollers with small amounts of memory. A typical Contiki configuration is 2 kilobytes of RAM

and 40 kilobytes of ROM. Contiki has been used is a variety of projects, such as road tunnel fire

monitoring, intrusion detection, wildlife monitoring, and in surveillance networks.

3.4.2 TinyOS

TinyOS8 is an open source, BSD-licensed operating system designed for low-power wireless

devices, such as those used in sensor networks, ubiquitious computing, personal area networks,

smart buildings, and smart meters. It is an embedded operating system written in the C programming

language as a set of cooperating tasks and processes. TinyOS provides interfaces and components

for common abstractions such as packet communication, routing, sensing, actuation and storage. A

worldwide community from academia and industry use, develop, and support the operating system

as well as its associated tools, averaging 35,000 downloads a year.

3.4.3 RIOT OS

Riot9 is a real-time multi-threading operating system that explicitly considers devices with minimal

resources but eases development across the wide range of devices that are typically found in the

Internet of Things. RIOT is based on design objectives including energy-efficiency, reliability, real-

time capabilities, small memory footprint, modularity, and uniform API access, independent of the

underlying hardware (this API offers partial POSIX compliance). Several libraries (e.g. Wiselib) are

already available on RIOT, as well as a full IPv6 network protocol stack including the latest standards

of the IETF for connecting constrained systems to the Internet (6LoWPAN, IPv6, RPL, TCP and

UDP).

3.4.4 OpenWSN

The OpenWSN10 project is an open-source implementation of a fully standards-based protocol stack

for capillary networks, rooted in the new IEEE802.15.4e Timeslotter Channel Hopping standard.

IEEE802.15.4e, coupled with Internet-of-Things standards, such as 6LoWPAN, RPL and CoAP,

enables ultra-low power and highly reliable mesh networks which are fully integrated into the Internet.

The resulting protocol stack will be cornerstone to the Internet of (Important) Things.

8 http://tinyos.stanford.edu/tinyos-wiki/index.php/Main_Page

9 https://www.riot-os.org/ 10 https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187



3.4.5 OpenEmbedeed

OpenEmbedded11 is a build framework for embedded Linux. OpenEmbedded offers a cross-compile

environment that allows to develop complete Linux Distributions for embedded systems. Only A8

nodes are powerful enough to support an embedded Linux.

3.4.6 Conclusions

An OS for IoT Elements should fulfil requirements such as reliability, real-time behaviour and the

support to communication stack. Moreover, it is also important that the OS run on a wide spectrum

of hardware. Currently, none of the existing OS is capable to fulfil all these requirements (see Table

5), hence the selection of OS should to be addressed by the MCU requirements.

Contiki, TinyOS and RIOT OS are examples of OS with low memory requirements, instead Open

Embedded has more restrictive memory requirements.

Concerning C support, Contiki and OpenWSN takes advantage of a subset of the C programing

language and hence, some keywords cannot be used. Instead, Open Embedded is written in

standard C, and offers support for a wide range of different programming and scripting languages.

Finally, TinyOS is written in a C sublanguage with different notation. The use of non-standard C on

TinyOS, Contiki and Open Embedded penalizes some key features such as C++ programmability,

standard multi-threading, and real-time support. Nevertheless, RIOT adds support for C++, enabling

powerful libraries and provides a TCP/IP network stack.

Referring the application layer standards, Contiki is the most relevant solution because it provides

support to HTTP, CoAP, MQTT, XMPP and DDS. On the other, the support of the rest of OS is most

restrictive. Similarly to the standards, Contiki supports the most heterogeneous hardware ranged

from CC2530 to PICs of Microchip.

All OS support the power awareness providing mechanisms for managing the power consumption

of the implementations. It allows to develop low-power solutions that can be battery-operated.

Last but not least, Contiki and RIOT OS are the OS with higher scientific community acceptance and

hence, they have available more documentation and a major community support. It is a key issue to

adopt these OS in the devices.

Finally, in reference to the INNOQUA ICT Solution, the presented OS are not suitable to be installed

on proposed open hardware solutions (see Section 3.3 - Raspberry Pi 3 Model B and Arduino Mega

2560 rev.3). The main reason is that their chipset are not supported but these enhanced OS.

Therefore, both open hardware solutions will take advantage of default OS or firmware to develop

ICT INNOQUA solution. It is important to note that the open hardware capabilities will not be

prejudiced. Arduino firmware has a well-designed, complete and widely used API. On the other hand,

Raspbian is a Debian-based OS provided by the Raspberry Pi Foundation. Therefore, it is totally

optimiz

sed to be used on a Raspberry Pi providing an easy-to-use, easy-to-maintain, fast and light distro

with a broad and active community (tutorials, projects, packages, updates…).

11 http://www.openembedded.org/wiki/Main_Page


Table 5: Comparison of Operative Systems for IoT devices (Legend: F-Full support/P-Partial Support/N-No Support)

Min

RA

M

Min

RO

M

C S

up

po

rt

C+

+ S

up

po

rt

Mu

lti-

Th

read

ing

MC

U w

/o M

MU

Mo

du

lato

ry

Rea

l-T

ime

IP N

etw

ork

ing

Po

wer

Man

agem

ent

Do

cum

enta

tio

n/

Co

mm

un

ity

Ap

plic

atio

n

laye

r P

roto

cols

MC

U S

up

po

rted

Contiki <2kB <30kB P N P F P P F F F HTTP, CoAP,

MQTT, XMPP,

DDS

TI CC2530, TI CC2538, TI MSP430, TI

MSP430x, nRF52832, RL78, Atmel AVR,

Atmel Atmega128 RFA1, Freescale

MC1322x, Microchip pic32mx795f512l,

6502

TinyOS <1kB ~1MB N N P F N N P F P HTTP, CoAP Atmel Atmega128, TI MSP430, Intel

XScale PXA271

RIOT OS ~1.5kB ~5kB F F F F F F F F F HTTP, CoAP,

DDS, MQTT(in

process)

ARM Cortex M0, ARM Cortex M3, ARM

Cortex M4, TI MSP430, ARM7, MIPS32,

X86

OpenEmbedded ~1MB ~1MB F F F N P P P OMAP2420, OMAP3530, ARM cortex A8,

ARM920T, ARM926EJ, Marvel PXA270,

MX31, Freescale i.MX6, PowerPC,

AT91SAM9263

OpenWSN - - P P N F F P HTTP, CoAP TI MSP430, TI CC2538, MC13213,

STM32F103RE



3.5 Data integration technologies

IoT data integration technologies focus on transform and load data coming from heterogeneous data

sources and integrating them in a known format ready to be used for the application layer of a

solution. In this section, we will focus on IoT software platforms which can be useful in the INNOQUA

context.

Generally speaking, an IoT platform provides a comprehensive set of generic application

independent functionalities which can be used to build IoT applications. Although there is a wide

range of different services and functionalities existing IoT platforms offer, the most common ones

are:

Connectivity & normalisation: Harmonizes the inherent dispersion of protocols and data

formats of the connected devices and services.

Device management: Ensures the connected IoT Elements are working properly,

seamlessly running patches and updates for software and applications running on the device

or edge gateways.

Database: Offers a scalable storage solution.

Processing & action management: Allows to define rule-based event-action-triggers.

Analytics: Integrates some sort of analytic tools to extract information from the collected

data.

Visualisation: Includes data visualisation tools.

These technologies offer multiples benefits such as facilitate the interoperability between systems,

make use of standardised information representation and communication protocols. Instead, they

also provides some handicap as the overhead addition in the solution.

Some interesting solutions are listed below these lines.

IoT-TICKET

https://www.iot-ticket.com/data-acquisition

IoT-Ticket easily integrates with existing ecosystems, either using electronics which

act as a data gateway to the IoT-Ticket Big-Data server or through software powered

with the IoT API.

Kaa IoT Platform

http://www.kaaproject.org

Kaa is a production-ready, multi-purpose platform for building complete end-to-end

IoT solutions, connected applications, and smart products. The Kaa platform

provides an open, feature-rich toolkit for the IoT product development and thus

http://www.kaaproject.org/



dramatically reduces associated cost, risks, and time-to-market. For a quick start,

Kaa offers a set of out-of-the-box enterprise-grade IoT features that can be easily

plugged in and used to implement a large majority of the IoT use cases.

OpenIoT

http://github.com/OpenIotOrg/openiot/wiki

First-of-kind open source IoT platform enabling the semantic interoperability of IoT

services in the cloud. The platform offers: a middleware for sensors and sensor

networks; Ontologies, semantic models and annotations for representing internet-

connected objects, along with semantic open-linked data techniques; Cloud/Utility

computing, including utility based security and privacy schemes.

OpenIoT is a joint effort of prominent open source contributors towards enabling a

new range of open large scale intelligent Internet of things applications according to

a utility cloud computing delivery model.

FIWARE

http://www.fiware.org

The FIWARE platform provides a rather simple yet powerful set of APIs (Application

Programming Interfaces) that ease the development of Smart Applications in multiple

vertical sectors. The specifications of these APIs are public and royalty-free. Besides,

an open source reference implementation of each of the FIWARE components is

publicly available so that multiple FIWARE providers can emerge faster in the market

with a low-cost proposition.

ThingWorx

http://www.thingworx.com

ThingWorx is a proprietary cloud-based M2M designed to build and run connected

world applications. ThingWorx focuses on building innovative Machine-to-Machine

(M2M) and Internet of Things (IoT) applications. It provides a variety of tools and

services to support end-to-end solutions. The devices and data are accessible via a

REST API.

Microsoft Azure IoT Suite

https://azure.microsoft.com/en-us/solutions/iot-suite/

http://github.com/OpenIotOrg/openiot/wiki

http://www.fiware.org/

http://www.thingworx.com/




The Microsoft Azure IoT Suite is an enterprise-grade solution that enables to get

started quickly through a set of extensible preconfigured solutions that address

common IoT scenarios, such as remote monitoring and predictive maintenance.

These solutions are implementations of the IoT solution architecture described

previously. The platform offers services such as: Azure IoT Hub, Azure Event Hubs,

Azure Stream Analytics, Azure Machine Learning, and Azure storage, and solution

specific management consoles.

CISCO Jasper Control Center Platform


The Jasper Control Center Platform is a cloud-based solution for enterprises to

launch, manage and monetize an IoT deployment using a single turnkey solution.

Jasper’s platform operates on a single base of code that can be configured to meet

specialised enterprise needs across a wide range of business models, technologies,

and industries. Through one, turnkey, and globally-compatible platform solution, the

Jasper Control Center delivers visibility and real-time control for connected service

businesses, along with IoT/ Machine to Machine (M2M) capabilities like provisioning,

mobile service management, real-time engagement, support diagnostics, billing and

business automation.

openHAB2

http://docs.openhab.org/

The open Home Automation Bus is an open source, technology agnostic home

automation platform based on Eclipse SmartHome. openHAB2 offers bindings for

different devices (Qualcomm AllPlay, Anel NET-PwrCtrl, DMX…), technologies

(Bluetooth, WiFi…) and protocols (Modbus, MQTT, ESC/VP21, RIO…) facilitating

the integration of third parties. Also, openHAB2 provides a customisable Graphical

User Interface (GUI), helper functions to transform the gathered data, heterogeneous

persistence services to store data over time and automation logic by using rulers.

3.5.1 Conclusions

One of the main aims of INNOQUA is to develop an extensible and user-friendly open-source

solution for controlling and monitoring the INNOQUA modules. OpenHAB is suitable as base data

integration technology because of its support for various technologies, devices and standard

protocols. Moreover, it is compatible with Raspberry Pi and hence, it can be deployed in the Gateway

achieving an autonomous INNOQUA solution. Also, OpenHAB provides multiples connectors to

transfer the data to third party cloud solutions or use its owner cloud solution.




4 Regulation in force, certification and standardisation

issues of the interoperability

4.1 Consortiums and standardisation bodies

This section will identify and review the most relevant consortiums and standardization bodies

involved on interoperability matters of the IoT architectures.

AllSeen Alliance

https://allseenalliance.org/

Alliance of companies led by Qualcomm and with members like Cisco, Microsoft, LG,

IBM, Canon, Panasonic, Philips, Sharp, Sony and HTC. They are focused on

providing an agnostic and simple architecture to connect the IoT Elements which is

supported by the Linux Foundation. Mainly, it is oriented to the domotic environment,

but its application is intended for all IoT applications.

Open Interconnect Consortium (OIC)

http://openinterconnect.org/

Consortium of companies led by Intel and with members like Samsung, Atmel,

WindRiver, Cisco, GE, MediaTek and Dell. The aim of OIC is provide a set of

standards and open codes for the interconnection of connected objects.

Thread Group (OIC)

http://threadgroup.org/

Consortium of companies led by Google with members like Freescale, Atmel,

Samsung, Silicon Labs. It is focused on improving the interconnection of objects in

the home. Thread proposes the use of 6LowPAN technologies through IEEE

802.15.4.

Internet of Things Consortium

http://iofthings.org/

IoTC is a non-profit organisation backed by companies in the IoT sector such as

SmartThings, NXP, Logitech, Sigfox, Synapse o Evrythng. Its objective is to support

its members in the world of IoT, representation in work groups, support in business





development and dissemination of IoT among consumers, sales channels and

investors.

Industrial Internet Consortium (IIC)

http://www.iiconsortium.org/

IIC is an organisation created by AT&T, Cisco, GE, IBM and Intel whose aim is to

ensure the rapid and interoperable development of IoT within the industrial world. It

has more than 200 members and the most relevant are Schneider, Siemens,

Honeywell, Oracle, ABB, BOSCH and SAP. A reference architecture for Industry 4.0

focused on interoperability was presented by this consortium.

Internet Protocol for Smart Objects (IPSO) Alliance

http://www.ipso-alliance.org/

IPSO is an alliance that was created in 2008. Intel, ARM, Atmel, BOSCH, Freescale,

Oracle, ST and Silicon Labs are the most prominent members. Moreover, Google,

Cisco and Texas Instruments are among their contributors. Its aim is to promote the

use of IP technologies in the objects connected and support the adoption of existing

standards created by other organisms (IETF, IEEE, ISA…) through publications,

testbeds…

Eclipse Foundation

http://iot.eclipse.org/

The Eclipse Foundation, which is led by IBM, has project focused on IoT. It maintains

open source solutions in a multitude of platforms of several key IoT protocols such

as MQTT, LWM2M, ESTI M2M and CoAP.

Open Mobile Alliance (OMA)

http://openmobilealliance.org/

The Open Mobile Alliance is an organisation created on 2002 by mobile

manufacturers, operators and software companies to create applicable open

standards to the mobile industry. The most relevant outcomes is the LWM2M

(Lightweight M2M) that is a network management protocol.

FI-WARE

https://www.fiware.org



FI-WARE was initiated by a project of 7th Framework Programme in the FI-PPP

(Future Internet Public-Private Partnership). FI-WARE is a platform that provides a

standards-based common framework to integrate IoT data. Initially, it was led by

Telefonica, Atos, Orange and Engineering. Once the project was finished, the

development of the open API continued. FI-WATE implements a platform based on

connectors with applications and other solutions taking advantage of open standards

such as ;MQTT, LWM2M, HTTP or OMA NGSI.

Bluetooth SIG

https://www.bluetooth.org/

The Bluetooth SIG (Special Interest Group) is the industrial consortium that provided

the Bluetooth standard which is widely used in low-ranges. The new Bluetooth

versions are being key in the development of low-cost and low-size IoT Elements

thanks to the BLE (Bluetooth Low Energy) communication technology.

LoRa Alliance

https://www.lora-alliance.org/

LoRa alliance is an alliance of companies that lead the uniformisation of the LPWA

LoRA standard. LoRa allows deploying large-range IoT networks. The most

remarkable members of the LoRa alliance are IBM, Cisco, Sagemcom, KPN,

Proximus, Bouygues and Semtech.

ZigBee Alliance

http://www.zigbee.org/

ZigBee Alliance provided ZigBee protocol which was the basis of the IoT elements

growth. Nevertheless, this protocol has lost weight in recent times due to the

appearance of low-power and low-range protocols like LPWA and the popularisation

of the IP protocols like 6LowPAN.

Apple HomeKit

https://developer.apple.com/homekit/

Apple is not related with the previous consortiums because it goes its own way in the

IoT sector. Basically, its domotic approach is focused on its devices. Then, Apple has

created the Apple Homekit that is a restricted environment to control IoT elements

through WiFi and BLE, program actions and also interact with the system by suing

Siri.



4.2 Standards

This section presents a review of the most relevant standards involved on IoT solutions such as

DDS, MQTT, AMQP, JMS, REST/HTTP and CoAP. Each of them will be analysed identifying the

type of abstraction used (Publish/Subscribe or Request/Reply), performance, real-time support,

serialisation, licensing model, dynamic discovery and security.

4.2.1 Data Distribution Service (DDS)

The DDS standard (OMG, 2007) is a data-centric publish-and-subscribe technology that emerged

from the Aerospace and Defence community to address the data distribution requirements of

mission-critical systems. It enables scalable, real-time, reliable, high performance and interoperable

data exchanges between publishers and subscribers. Moreover, it is both language and OS

independent. DDS is used on business-critical applications like financial trading, air traffic control,

smart grid management, and other big data applications. Also, it is used in a wide range of Industrial

Internet applications.

The DDS specification defines: (i) a Data Centric Publish Subscribe (DCPS) layer; (ii) a DDS

Interoperability Wire Protocol (DDSI); and (iii) an Extensible and Dynamic Topic Types for DDS

standard.

DCPS provides a set of APIs that present a set of standardised “profiles” targeting real-time

information-availability for any domain. Moreover, these APIs have been implemented in a range of

different programming languages (Ada, C, C++, C#, Java, JavaScript, CofeeScript, Scala, Lua, and

Ruby) and helps to ensure that DDS applications can be ported easily between different vendor’s

implementations.

The DDS Interoperability Wire Protocol (DDSI) is a wire-level protocol refers to the mechanism for

transmitting data from point-to-point which is needed if more than one application has to interoperate.

The protocol also supports automatic “Discovery” that allows DDS participants to declare the

information that they can provide or what data they would like to receive, in terms of topic, type and

QoS.

Extensible and Dynamic Topic Types defines how Topic data types can be extended dynamically

while ensuring application portability and interoperability.

4.2.2 Message Queuing Telemetry Transport (MQTT)

MQTT (IBM, 2010) is a message-centric wire protocol designed for M2M communications that

enables the transfer of telemetry-style data in the form of messages from devices, along high latency

or constrained networks, to a server or small message broker. Devices may range from sensors and

actuators, to mobile phones, embedded systems on vehicles, or laptops and full scale computers. It

supports publish-and-subscribe style communications and is extremely simple.

MQTT defines methods to indicate the action to be performed on the identified resource. These

methods are: (i) connect; (ii) disconnect; (iii) subscribe; (iv) unsubscribe and (v) publish. MQTT is

widely used and there are several projects that implement MQTT such as Microsoft Azure IoT Hub,

OpenStack, Amazon Web Services, EVRYTHNG…



4.2.3 Advanced Message Queuing Protocol (AMQP)

AMQP (OASIS, 2012) is a message-centric protocol for sending interoperable messages between

two or more clients that emerged from the Financial sector with the aim of freeing users from

proprietary and non-interoperable messaging systems. AMQP depicts the behaviour of the

messaging provider and client ensuring that implementations from different vendors are truly

interoperable.

AMQP is a binary, application layer protocol, designed to efficiently support a wide variety of

messaging applications and communication patterns. It provides flow controlled, message-oriented

communication with message-delivery guarantees such as at-most-once (where each message is

delivered once or never), at-least-once (where each message is certain to be delivered, but may do

so multiple times) and exactly-once (where the message will always arrive and do so only once),

and authentication and/or encryption based on SASL and/or TLS It assumes an underlying reliable

transport layer protocol such as Transmission Control Protocol (TCP).

4.2.4 Java Message Service (JMS)

JMS (Oracle, 2013) is a message-centric protocol for sending messages between two or more

clients. It is one of the most widely used publish-and-subscribe messaging technologies, but it also

allows point-to-point messaging. Its specification, JSR 914, was developed under the Java

Community Process and it is part of the Java Platform Enterprise Edition (Java EE). Mainly, JMS

offers capabilities to create, send, receive and read messages to application components based on

Java EE encouraging the coupling loss, the reliability and the synchrony. It is important to note that

JMS is only a Java API and does not define a wire protocol, hence JMS implementations from

different vendors will not interoperate.

4.2.5 REST/HTTP

REST has emerged as the predominant Web API design model. RESTful style architectures

conventionally consist of clients and servers. Clients initiate requests to servers; servers process

requests and return appropriate responses. Requests and responses are built around the transfer of

representations of resources. A resource can be essentially any coherent and meaningful concept

that may be addressed. A representation of a resource is typically a document that captures the

current or intended state of a resource.

REST was initially described in the context of HTTP, but it is not limited to that protocol. RESTful

architectures may be based on other Application Layer protocols if they already provide a rich and

uniform vocabulary for applications based on the transfer of meaningful representational state.

4.2.6 Constrained Application Protocol (CoAP)

CoAP (IETF, 2014) is a document transfer protocol. Mainly, it was designed to communicate over

the Internet very simple electronic devices. CoAP is being standardised by the Internet Engineering

Task Force (IETF) Constrained Restful Environments (CoRE) Working Group.



CoAP is focused on providing communication capabilities to small low power sensors, switches,

valves and resource constrained internet devices such as Wireless Sensor Networks (WSNs).

Moreover, it is designed to easily translate to HTPP for simplified RESTful web integration. CoAP is

lightweight, simple and runs over UDP (not TCP) with support for multicast addressing.

CoAP is based on RESTful architecture and hence, it supports a client/server programming model

where the resources are server controlled abstractions made available by an application process

and identified by Universal Resource Identifiers (URIs). Clients initiate requests to resources using

HTTP request methods such as GET, PUT, POST and DELETE. It is important to note that CoAP

supports resource discovery.

4.2.7 Conclusions

The messaging technologies presented in previous sections can be used to connect multiple devices

in a distributed network though wired and wireless communication technologies (e.g. Ethernet, Wi-

Fi, RFID, NFC, Zigbee, Bluetooth, GSM, GPRS, GPS, 3G, 4G). They are available for free thanks

to open source licences.

Each messaging technology is suited to addressing different use cases. Below, the most relevant

characteristics of each technology are evaluated.

AMQP, MQTT, JMS are brokered-based architecture. Therefore, publishers post messages to a

trusted message routing and delivery service, or broker, and subscribers register subscriptions with

the broker which also performs any message filtering. Moreover, they facilitate the networks’

scalability deploying more instances of the broker. Instead, REST/HTTP and CoAP are based on a

typical Client-Server architecture where client invokes the methods of the server.

DDS, REST/HTTP, CoAP are interoperable, hence their messages can be exchanged and

understood by different implementations. DDS enables interoperable data sharing thanks to the

DDSI that specifies wire protocol to exchange messages. RESTFul is interoperable because it is

needed to support message exchanges in a HTTP stack. CoAP supports content negotiation, the

clients can express a preferred representation and servers can inform the clients what they will

receive through “Content-Type”. Instead, MQTT, AMQP and JMS are not completely interoperable.

MQTT is agnostic to the content of the payload and does not specify the layout or how data is

represented in the message. Therefore, the exchange of the messages is sure, but the serialisation

of the content requires a shared scheme. AMQP messages adds information about the layout in the

“content-type” and “content-encoding”, but it is only a convention. Therefore, the data serialisation

scheme should to be understood by the publisher and subscriber to ensure that the data payload is

interpreted. JMS does not provide a standard for interoperability outside of the Java platform.

All messaging technologies have a comparable performance in a simple point-to-point configuration,

although broker-based architectures (MQTT, AMQP and JMS) adds an additional overhead in the

communications. On the other hand, DDS is the only messaging technology capable of ensuring

lower latencies that is the key requirement for real-time systems.

MQTT, AMQP and JMS do not provide automatic discovery, unlike DDS, This means that

configuring a distributed system that uses one of these technologies is through the broker.

CoAP supports a client/server programming model based on a RESTful architecture in which

resources are server controlled abstractions made available by an application process and



identified by Universal Resource Identifiers (URIs). Clients can manipulate resource using

HTPP: GET, PUT, POST and DELETE methods. It also provides in built support for resource

discovery as part of the protocol.

Both AMQP and JMS provide transactional modes of operation due to their financial origin, hence

they can take part in a multi-phase commit sequence.

The trusted and fault-tolerance of the messaging technologies is also important. JMS does not

provide an API for controlling the privacy and integrity of messages. Then, the security is provided

by the JMS vendors with proprietary security. MQTT v3.1 and AMQP provides authentication

facilities and the encryption of data exchanged can be handled using SSL or TLS. DDS defines the

Security Model and Service Plugin Interface (SPI). It customizes the behaviour and technologies that

the DDS implementations use for Information Assurance, specifically allowing customization of

Authentication, Access Control, Encryption, Message Authentication, Digital Signing, Logging and

Data Tagging. RESTful uses asymmetric cryptography for authentication of key exchange and

symmetric encryption for confidentiality through SSL or TLS. CoAP uses Datagram Transport Layer

Security (DTLS) that is equivalent to SSL/TLS over UDP.

Table 4 presents a summary of the findings from the review of standards.

Concerning INNOQUA project, the most suitable communication standard is MQTT because it: (i) is

widely supported by the major part of OS and IoT platforms; (ii) has a limited bandwidth consumption;

(iii) does not require a continues connectivity; (iv) is addressed to low-power communications; (v)

supports authentication and SSL encryption.


Table 6: Summary of messaging technologies

DDS MQTT AMQP JMS REST/HTTP CoAP

Abstraction Pub/Sub Pub/Sub Pub/Sub Pub/Sub Request/Reply Request/Reply

Architecture Global Data Space Brokered Non-

centralised

P2P or Brokered Brokered Client-Server Client-Server

Interoperability Yes Partial Partial No Yes Yes

Performance 10s of 1000s of

messages per

second.

Typically 100s to

1000+ messages per

second per broker

Typically 100s to

1000+ messages per

second per broker

Typically 100s to

1000+ messages per

second per broker

Typically 100s of

requests per second

Typically 100s of

requests per second

Real-time Yes No No No No No

Subscription

Control

Partitions, Topics with

message filtering

Topics with

hierarchical matching

Exchanges, Queues

and bindings in v0.9.1

standard, undefined

in latest v1.0 standard

Topics and Queues

with message filtering

N/A Provides support for

Multicast addressing

Data Serialisation CDR Undefined AMQP type system or

user defined

Undefined No Configurable

Standards OMG’s RTPS and

DDSI standards

Proposed OASIS

MQTT standard M

O

OASIS AMQP JCP JMS standard Is an architectural

style rather than a

standard

Proposed IETF CoAP

standard

Licencing Model Open Source &

Commercially

Licenced

Open Source &

Commercially

Licenced

Open Source &

Commercially

Licenced

Open Source &

Commercially

Licenced

HTTP available for

free on most

platforms

Open Source &

Commercially

Licenced

Dynamic Discovery Yes No No No No Yes

Multi-phase

Transactions

No No Yes Yes No No

Security Vendor specific but

typically based on

SSL or TLS with

Simple

Username/Password

Authentication, SSL

SASL authentication,

TLS for data

encryption

Vendor specific but

typically based on

SSL or TLS.

Typically based on

SSL or TLS

DTLS


proprietary access

control

or TLS for data

encryption

Commonly used with

JAAS API



5 IoT architectures

This section is aimed at evaluating the current architectures used on IoT solutions (Cruz Vega, et

al., 2015). Basically, they can be classified in three groups: (i) three level architecture with IoT

Elements without IP protocol; (ii) two level architecture with IoT Elements with IP protocol; and (iii)

two level architecture with IoT Elements without IP protocol.

First architecture corresponds to the deployments with low-power radios and one repeated or

gateway to be able to connect to an IP network. The second is the one that incorporates technology

with IP connectivity directly such as WiFi or modem 2G. The third is the architecture that uses new

specific network protocols for IoT with its own non-IP network.

All architectures includes a common bottom-level to interact with the physical device (sensor,

actuator or complex device with processing capacity to integrate intelligence).

In the second level appears different IoT approaches which will depends of the application, available

network or cost.

5.1 Three Level Architecture with IoT Elements without IP Protocol

This architecture is the most widespread architecture in recent years, especially in cases where a

significant number of low-cost, low-capacity devices are required, such as simple counters or battery-

powered sensors. The main reason is that the technologies without IP protocol stack are more

expensive and has a higher consumption.

It is based on three layers: (i) IoT Element layer; (ii) Gateway layer and (iii) Cloud layer.

Figure 2: Three level architecture with objects connected without IP protocol

IoT Application

IoT Platform

IoT Element

IoT Element

IoT Element

IoT Element

IoT Element

...

GatewayGateway

ZigBee, 6LowPAN, BLE, IEEE 802.15.4...IoT Element

Layer

2G/3G/4G, GPRS, Wifi, Ethernet...

MQTT, HTTP, CoAP...

MQTT, HTTP...

Gateway Layer

Cloud Layer



In the connectivity layer, the IoT elements are able to route the data to the gateway layer that

provides IP connectivity. The routing can be done following a point-to-point connectivity between IoT

elements and IP Gateway or a mesh network.

The gateway layer provides routing, data aggregation and, in some cases, network management

capabilities. Basically, it contains a gateway which provides IP connectivity by using common

technologies such as WiFi (IEEE 802.11), Ethernet (IEEE 802.3) o cellular communications (GPRS,

EDGE, UMTS, HSxPA or LTE). Other technologies like WiMax (IEEE 802.18), PLC (Power Line

Communications), optical fiber or xDSL can be used but they are less popular on IoT solutions. The

IP connectivity allows to establish UDP or TCP connections with the third layer, cloud layer.

Moreover, these communications are performed through RESTful or SOAP specifications, using

JSON, XML or other formats to encapsulate the data. Also, IoT protocols such as MQTT, CoAP…

to perform this communication.

The third layer, cloud layer, contains the cloud platform which is able to collect the data, route the

commands and manage the devices. Moreover, it offers the services that enables the presentation

of data and the interaction with the implemented system.

5.2 Two Level Architecture with IoT Elements with IP Protocol

In this this IoT architecture, the IoT Elements are equipped with IP connectivity, for example WiFi or

cellular connectivity (2G/3G/4G, GPRS…). Therefore, it is not necessary to have an intermediate

layer with gateway to route the information because these IoT elements with IP connectivity are able

to communicate directly with the next level which is equivalent to the Cloud layer presented in

previous section. Moreover, the protocols required in the IoT Elements (MQTT, CoAP, DDS…) are

more complex than in the previous case (three level architecture) and hence, they require more

processing capacity and integrated memory. Then, this architecture is suitable to connect IoT

Elements with: (i) properly supplied; (ii) equipped with batteries of very high capacity; (iii) little amount

of daily transmissions; and (iv) devices with capacity of recharge.

Figure 3: Two level architecture with objects connected with IP protocol

IoT Application

IoT Platform

IoT Element

IoT Element

IoT Element

IoT Element

IoT Element

...

2G/3G/4G, GPRS, Wifi, Ethernet...IoT Element

Layer

MQTT, HTTP, CoAP...

MQTT, HTTP...Cloud Layer



5.3 Two Level Architecture with IoT Elements without IP Protocol

This IoT architecture is the evolution of the previous architecture with the aim of simplifying

deployments, gaining network coverage and reducing the energy consumption of objects or their

cost. This architecture are based on approaches much more basic (without IP stack) by using

proprietary protocols capable of offering a direct or quasi-direct interaction between the cloud and

connected objects. Sigfox and LoRa are capable to provide IoT Elements connected directly to

Internet and hence to the Cloud avoiding the use of repeaters and gateways.

Figure 4: Two level architecture with objects connected without IP protocol

5.4 Conclusions

Initially, the most suitable IoT architecture for INNOQUA project is the three level architecture with

scope IoT Elements without IP protocol. The main benefits of this architecture for INNOQUA solution

are: (i) low-cost, the IoT Elements do not require IP protocol stack management minimizing the cost

of communication technologies and the cloud layer is optional reducing the deployment costs; (ii)

low-power, IoT Elements without IP protocol stack reduce the complexity and hence, the power

consumption; (iii) autonomous, gateway layer provides operational capabilities allowing deployments

without cloud layer if necessary; and (iv) range, three level architectures are centred on narrow

deployments (less than thousands of meters) like INNOQUA project.

IoT Application

IoT Platform

IoT Element

IoT Element

IoT Element

IoT Element

IoT Element

...

Long Range IoT Network TechnologyIoT Element

Layer

MQTT, HTTP...

MQTT, HTTP...Cloud Layer



6 Conclusions

This deliverable presents a state of the art of ICT for wastewater management focusing on biological

on-site systems including sensorisation, communication technologies, open hardware devices,

operative systems for open hardware devices, data integration technologies, communication

standards and ICT architectures.

This information has helped to derive the ICT requirements for INNOQUA and ICT architecture

described in the D2.2 throughout WP2.

The state of the art collects various studies involving the implementation of water quality monitoring

systems using Wireless Sensor Network (WSN) technology and the most used water quality

measurements on WSNs.

Referring the technologies, the most relevant sensorisation technologies, IoT Data link protocols,

open hardware devices, operative systems and data integration technologies have been identified

and characterised in order to support the design and implementation of the ICT architecture in the

WP3 of INNOQUA project.

Additionally, the most relevant consortiums and standardisation bodies related with WSN have been

identified. They will be followed throughout the INNOQUA project and taken into account if

necessary. On the other hand, the most significant IoT standards to exchange data are described

and analysed proving the basis to be selected in the WP3.

Concerning the IoT architectures, the current architectures used on IoT solutions are identified which

are: (i) three level architecture with objects connected without IP protocol; (ii) two level architecture

with objects connected with IP protocol; and (iii) two level architecture with objects connected without

IP protocol. This information has been used to define the MCU architecture in the D2.2.



7 Bibliography

Ahn, Y.-H., Shanmugam, P., Lee, J.-H., & Kang, Y. (2006). Application of satellite infrared data for

mapping of thermal plume contamination in coastal ecosystem of Korea. Mar. Environ. Res.,

61, 186-201.

Allan, M., Hamilton, D., Hicks, B., & Brabyn, L. (2011). Landsat remote sensing of chlorophyll a

concentrations in central north island lakes of new zealand. Int. J. Remote Sens., 32, 2037-

2055.

Alparslan, E., Coskun, H., & Alganci, U. (2009). Water quality determination of Küçükçekmece Lake,

Turkey by using multispectral satellite data. Sci. World J., 9, 1215-1229.

Bhatti, A., Nasu, S., Takagi, M., & Nojiri, Y. (2008). Assessing the potential of remotely sensed data

for water quality monitoring of coastal and inland waters. Res. Bull. Kochi Univ. Technol., 5,

201-207.

Braga, F., Giardino, C., Bassani, C., Matta, E., Candiani, G., Strömbeck, N., . . . Bresciani, M. (2013).

Assessing water quality in the northern adriatic sea from HICO data. Remote Sens. Lett., 4,

1028-1037.

Brezonik, P., Menken, K., & Bauer, M. (2005). Landsat-based remote sensing of lake water quality

characteristics, including chlorophyll and colored dissolved organic matter (CDOM). Lake

Reserv. Manag., 21, 273-383.

Brezonik, P., Olmanson, L., Bauer, M., & Kloiber, S. (2007). Measuring water clarity and quality in

minnesota lakes and rivers: A census-based approach using remote-sensing techniques.

Cura Rep., 37, 310-313.

Bridle, H., Miller, B., & Desmulliez, M. (2014). Application of microfluidics in waterborne pathogen

monitoring: A review. Water Research 2014, 55, 256‐271.

Bushon, R., Brady, A., Likirdopulos, C., & Cireddu, J. (2009). Rapid detection of Escherichia coli and

enterococci in recreational water using an immunomagnetic separation/adenosine

triphosphate technique. Journal of Applied Microbiology, 106(2), 432‐41.

Bushon, R., Likirdopulos, C., & Brady, A. (2009). Comparison of immunomagnedic

separation/adenosine triphosphate rapid method to traditional culture‐based method for E.

coli and enterococci enumeration in wastewater. Water Research, 43(19), 4940‐46.

Casey, K., Brandon, T., Cornillon, P., & Evans, R. (2010). The past, present, and future of the

AVHRR Pathfinder SST program. In Oceanography from Space, 273-287.

Casini, B., Buzzigoli, A., Cristina, M., Spagnolo, A., Del Giudice, P., & Brusaferro, S. (2014). Long‐

Term Effects of Hospital Water Network Disinfection on Legionella and Other Waterborne

Bacteria in an Italian University Hospital. Infection Control and Hospital Epidemiology, 35(3),

293‐99.

Chang, N.-B., & Vannah, B. (2012). Monitoring the total organic carbon concentrations in a lake with

the integrated data fusion and machine-learning (IDFM) technique. SPIE Opt. Eng. Appl. Int.

Soc. Opt. Photonics.

Chang, N.-B., Vannah, B., Yang, Y., & Elovitz, M. (2014). Integrated data fusion and mining

techniques for monitoring total organic carbon concentrations in a lake. Int. J. Remote Sens.,

35, 1064-1093.



Chen, C., Tang, S., Pan, Z., Zhan, H., Larson, M., & Jönsson, L. (2007). Remotely sensed

assessment of water quality levels in the Pearl River Estuary, China. Mar. Pollut. Bull., 54,

pp. 1267-1272.

Choubey, V. (2994). Monitoring surface water conductivity with Indian remote sensing satellite data:

A case study from central India. IAHS Publ. Ser. Proc. Rep. Intern. Assoc. Hydrol. Sci., 219,

pp. 317-326.

Chung, W. Y., Chen, C. L., & Chen, J. B. (2011). Design and implementation of low power wireless

sensor system for water quality monitoring. Proc. 5th Int. Conf. Bioinform. Biomed. Eng.

(ICBBE), pp. 1-4.

Cloete, N. A., Malekian, R., & Nair, L. (2016). Design of Smart Sensors for Real-Time Water Quality

Monitoring. IEEE Access, 3975-3990.

Cruz Vega, M., Oliete Vivas, P., Morales Ríos, C., González Luis, C., Cendón Martín, B., &

Hernández Seco, A. (2015). Las tecnologías IoT dentro de la industria conectada 4.0.

Fundación EOI.

Del Castillo, C., & Miller, R. (2008). On the use of ocean color remote sensing to measure the

transport of dissolved organic carbon by the Mississippi River Plume. Remote Sens. Environ.,

112, 836-844.

El Saadi, A., Yousry, M., & Jahin, H. (2014). Statistical estimation of rosetta branch water quality

using multi-spectral data. Water Sci., 28, pp. 18-30.

Ferrari, G., Dowell, M., Grossi, S., & Targa, C. (1996). Relationship between the optical properties

of chromophoric dissolved organic matter and total concentration of dissolved organic carbon

in the southern baltic sea region. Mar. Chem., 55, 299-316.

Fiorani, L., Fantoni, R., Lazzara, L., Nardello, I., Okladnikov, I., & Palucci, A. (2006). Lidar calibration

of satellite sensed CDOM in the southern ocean. EARSeL eProc, 5, 89-99.

Giardino, C., Bresciani, M., Cazzaniga, I., Schenk, K., Rieger, P., Braga, F., . . . Brando, V. (2014).

Evaluation of multi-resolution satellite sensors for assessing water quality and bottom depth

of lake garda. Sensors, 14, 24116–24131.

Gürsoy, Ö., Birdal, A., Özyonar, F., & Kasaka, E. (2015). Determining and monitoring the water

quality of Kizilirmak River of Turkey: First results. Int. Arch. Photogramm. Remote Sens. Spat.

Inform. Sci., 40, pp. 1469–1474.

Hamylton, S., Silverman, J., & Shaw, E. (2013). The use of remote sensing to scale up measures of

carbonate production on reef systems: A comparison of hydrochemical and census-based

estimation methods. Int. J. Remote Sens., 34, 6451–6465.

Handcock, R., Gillespie, A., Cherkauer, K., Kay, J., Burges, S., & Kampf, S. (2006). Accuracy and

uncertainty of thermal-infrared remote sensing of stream temperatures at multiple spatial

scales. Remote Sens. Environ., 100, 427-440.

He, B., Oki, K., Wang, Y., & Oki, T. (2009). Using remotely sensed imagery to estimate potential

annual pollutant loads in river basins. Water Sci. Technol., 60, 2009-2015.

He, W., Chen, S., Liu, X., & Chen, J. (2008). Water quality monitoring in a slightly-polluted inland

water body through remote sensing—Case study of the Guanting Reservoir in Beijing, China.

Front- Environ. Sci. Eng., 2, pp. 163-171.



Huang, M., Xing, X., Qi, X., Yu, W., & Zhang, Y. (2007). Identification mode of chemical oxygen

demand in water based on remotely sensing technique and its application. In Proceedings of

the 2007 IEEE International Geoscience and Remote Sensing Symposium, pp. 1738-1741.

IBM. (2010). MQTT V3.1 Protocol Specification.

IETF. (2014). The Constrained Application Protocol (CoAP).

Imen, S., Chang, N.-B., & Yang, Y. (2014). Monitoring spatiotemporal total organic carbon

concentrations in lake mead with integrated data fusion and mining (IDFM) technique. In

Proceedings of the 11th International Conference on Hydroinformatics, 17-21.

Ivnitski, D., Abdel‐Hamid, I., Atanasov, P., & Wilkins, E. (1999). iosensors for detection of pathogenic

bacteria. Biosensors & Bioelectronics, 14(7), 599‐624.

Jian, C., Chengcheng, X., Yang, Z., Deyong, C., Min-Hsien, W., & Junbo, W. (2015). Microfluidic

Impedance Flow Cytometry Enabling High-Throughput Single-Cell Electrical Property

Characterization. International Journal of Molecular Sciences, 16, 9804-9830.

Jiang, P., Xia, H., He, Z., & Wang, Z. (2009). Design of a water environment monitoring system

based on wireless sensor networks. Sensors, 9(8), pp. 6411–6434.

Jin, X., Shao, J., Zhang, X., An, W., & Malekian, R. (2016). Modeling of nonlinear system based on

deep learning framework. Nonlinear Dyn., 84(3), pp. 1327–1340.

Karaska, M., Huguenin, R., Beacham, J., Wang, M.-H., Jensen, J., & Kaufmann, R. (2004). AVIRIS

measurements of chlorophyll, suspended minerals, dissolved organic carbon, and turbidity

in the Neuse River, North Carolina. Photogramm. Eng. Remote Sens., 70, 125-133.

Knauer, M., Ivleva, N., Niessner, R., & Haisch, C. (2012). A flow‐through microarray cell for the online

SERS detection of antibody‐captured E. coli bacteria. Analytical and Bioanalytical Chemistry,

402(8), 2663‐67.

Korostynska, O., Mason, A., & Al-Shamma’a, A. (2013). Monitoring pollutants in wastewater:

Traditional lab based versus modern real-time approaches. Smart Sensors for Real-Time

Water Quality Monitoring, 4.

Kotamäki, N. (2009). Wireless in-situ sensor network for agriculture and water monitoring on a river

basin scale in Southern Finland: Evaluation from a data users perspective. Sensors, 9(4),

pp. 2862–2883.

Lambrou, T., Anastasiou, C., Panayiotou, C., & Polycarpou, M. (2014). A low-cost sensor network

for real-time monitoring and contamination detection in drinking water distribution systems.

IEEE Sensors J., 14(8), pp. 2765–2772.

Lee, J., & Deininger, R. (2004). Detection of E‐coli in beach water within 1 hour using

immunomagnetic separation and ATP bioluminescence. Luminescence, 19(1), 31-36.

Lim, J., & Choi, M. (2015). Assessment of water quality based on Landsat 8 operational land imager

associated with human activities in Korea. Environ. Monit. Assess, 1-17.

Liu, P., Meagher, R., Light, Y., Yilmaz, S., Chakraborty, R., & Arkin, A. (2011). Microfluidic

fluorescence in situ hybridization and flow cytometry. Lab on a Chip, 11(16), 2673‐79.

Mallick, J., Hasan, M., Alashker, Y., & Ahmed, M. (2014). Bathymetric and geochemical analysis of

lake al-saad, abha, kingdom of saudi arabia using geoinformatics technology. J. Geograph.

Inform. Syst., 6, p. 440.



Nas, B., Karabork, H., Ekercin, S., & Berktay, A. (2007). Assessing water quality in the Beysehir

Lake (Turkey) by the application of GIS, geostatistics and remote sensing. In Proceedings of

the 12th World Lake Conference, p. 646.

Nikou, H., Mohamad, E., Absar, A., & Morteza, A. (2013). A biosensor platform for rapid detection of

E. coli in water. In 2013 Water Quality Technology Conference and Exposition, WQTC 2013.

OASIS. (2012). Advanced Message Queuing Protocol (AMQP) Version 1.0 Specification.

OMG. (2007). Data Distribution Service for Real-Time Systems Version 1.2. OMG.

Onderka, M. (n.d.). Remote Sensing and Identification of Places Susceptible to Sedimentation in the

Danube River. Retrieved from

citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.537.9539&rep=rep1&type=pdf

Oracle. (2013). Java Message Service Version 2.0.

Postolache, O., Girao, P., Pereira, J. M., & Ramos, H. (2003). Wireless water quality monitoring

system based on field point technology and Kohonen maps. roc. IEEE Can. Conf. Elect.

Comput. Eng. (CCECE), 3, pp. 1873–1876.

Prasad, A. N., Mamun, K. A., Islam, F. R., & Haqva, H. (2015). Smart water quality monitoring

system. 2nd Asia-Pacific World Congress on Computer Science and Engineering (APWC on

CSE), 1-6.

Qiu, J., Zhou, Y., Chen, H., & Lin, J.-M. (2009). Immunomagnetic separation and rapid detection of

bacteria using bioluminescence and microfluidics. Talanta, 79(3), 787‐95.

Qiu, Y., Zhang, H.-E., Tong, X., Zhang, Y., & Zhao, J. (2006). Monitoring the water quality of water

resources reservation area in upper region of Huangpu River using remote sensing.

Proceedings of the 2006 IEEE International Symposium on Geoscience and Remote

Sensing, pp. 1082-1085.

Ramasamy, S., Venkatasubramanian, V., Sam, K., Chandrasekhar, G., & Ramasamy, S. (2005).

Remote sensing in pollution monitoring in Cauvery River. In Remote Sensing in Water

Resources.

Raut, V., & Shelke, S. (2016). Wireless acquisition system for water quality monitoring. Conference

on Advances in Signal Processing (CASP), 371-374.

Ricciardi, C., Canavese, G., R., C., Digregorio, G., Ferrante, I., & Marasso, S. (2010). Online Portable

Microcantilever Biosensors for Salmonella enterica Serotype Enteritidis Detection. Food and

Bioprocess Technology, 3(6), 956‐60.

Santini, F., Alberotanza, L., Cavalli, R., & Pignatti, S. (2010). A two-step optimization procedure for

assessing water constituent concentrations by hyperspectral remote sensing techniques: An

application to the highly turbid Venice lagoon waters. Remote Sens. Environ., 114, 887-898.

Shafique, N., Fulk, F., Autrey, B., & Flotemersch, J. (2003). Hyperspectral Remote Sensing of Water

Quality Parameters for Large Rivers in the Ohio River Basin. In Proceedings of the 1st

Interagency Conference on Research in the Watersheds, 27-30.

Somvanshi, S., Kunwar, P., Singh, N., Shukla, S., & Pathak, V. (2012). Integrated remote sensing

and GIS approach for water quality analysis of gomti river, Uttar Pradesh. Int. J. Environ. Sci.,

3, pp. 62-74.

Song, K., Li, L., Li, S., Tedesco, L., Hall, B., & Li, L. (2012). Hyperspectral remote sensing of total

phosphorus (TP) in three central Indiana water supply reservoirs. Water Air Soil Pollut., 223,

pp. 1481–1502.



Squirrel, D., Price, R., & Murphy, M. (2002). Rapid and specific detection of bacteria using

bioluminescence. Analytica Chimica Acta 2002, 457(1), 109‐14.

Sudheer, K., Chaubey, I., & Garg, V. (2006). Lake Water Quality Assessment from Landsat Thematic

Mapper Data Using Neural Network: An Approach to Optimal Band Combination Selection.

(W. O. Library, Ed.)

Syariz, M., Jaelani, L., Subehi, L., Pamungkas, A., Koenhardono, E., & Sulisetyono, A. (2014).

Retrieval of sea surface temperature over poteran island water of indonesia with Landsat 8

tirs image: A preliminary algorithm. Int. Arch. Photogramm. Remote Sens. Spat. Inform. Sci.,

1, 87-90.

Tilstone, G., Lotliker, A., Miller, P., Ashraf, P., Kumar, T., Suresh, T., . . . Menon, H. (2013).

Assessment of MODIS-Aqua chlorophyll-a algorithms in coastal and shelf waters of the

eastern arabian sea. Cont. Shelf Ress, 14-26.

Wang, K., Wan, Z., Wang, P., Sparrow, M., Liu, J., Zhou, X., & Haginoya, S. (2005). Estimation of

surface long wave radiation and broadband emissivity using moderate resolution imaging

spectroradiometer (MODIS) land surface temperature/emissivity products. J. Geophys. Res.

Atmos., 110.

Wang, X., Fu, L., & He, C. (2011). Applying support vector regression to water quality modelling by

remote sensing data. 32, 8615–8627.

Wang, Z., Wang, Q., & Hao, X. (2009). The design of the remote water quality monitoring system

based on WSN. Proc. 5th Int. Conf. Wireless Commun., pp. 1-4.

Whistler, J. (1996). A phenological approach to land cover characterization using Landsat MSS data

for analysis of nonpoint source pollution. KARS Rep., 96, pp. 1-59.

Wojciechowski, J., Shriver‐Lake, L., Yamaguchi, M., Fuereder, E., Pieler, R., & Schamesberger, M.

(2009). Organic Photodiodes for Biosensor Miniaturization. Analytical Chemistry, 81(9),

3455‐61.

Wu, C., Wu, J., Qi, J., Zhang, L., Huang, H., Lou, L., & Chen, Y. (2010). Empirical estimation of total

phosphorus concentration in the mainstream of the Qiantang River in China using Landsat

TM data. Int. J. Remote Sens., 31, pp. 2309-2324.

Wu, G. (2009). Seasonal Change Detection of Water Quality in Texas Gulf Coast Using MODIS

Remote Sensing Data. Sci. World J., 9, pp. 1215-1229.

Yifan, K., & Peng, J. (2008). Development of data video base station in water environment monitoring

oriented wireless sensor networks. Proc. Int. Conf. Embedded Softw. Syst. Symp., pp. 281-

286.

Yoon, J., & Kim, B. (2012). Lab‐on‐a‐Chip Pathogen Sensors for Food Safety. Sensors 2012, 12(8),

10713‐41.

Zhu, W., Yu, Q., Tian, Y., Chen, R., & Gardner, G. (2011). Estimation of chromophoric dissolved

organic matter in the Mississippi and Atchafalaya river plume regions using above-surface

hyperspectral remote sensing. J. Geophys. Res. Oceans, 116.

D1.3 State of the art review of ICT for wastewater ...

Documents

Transcript of D1.3 State of the art review of ICT for wastewater ...